From 2269c78a720479f3d74c153a8170ce3d32f15a18 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 14 Dec 2024 05:17:26 -0500
Subject: [PATCH 0001/3820] New translations indexing.mdx (Russian)

---
 website/pages/ru/network/indexing.mdx | 38 +++++++++++++--------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/website/pages/ru/network/indexing.mdx b/website/pages/ru/network/indexing.mdx
index be34140f88fa..978878e51f41 100644
--- a/website/pages/ru/network/indexing.mdx
+++ b/website/pages/ru/network/indexing.mdx
@@ -113,11 +113,11 @@ Once an allocation has been closed the rebates are available to be claimed by th
 - **Large** – готовность индексировать все используемые в настоящее время подграфы и обслуживать запросы на соответствующий трафик.
 
 | Настройка | Postgres<br />(ЦП) | Postgres<br />(память в ГБ) | Postgres<br />(диск в ТБ) | VMs<br />(ЦП) | VMs<br />(память в ГБ) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Small | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 | 184 |
+| --------- |:------------------------:|:---------------------------------:|:-------------------------------:|:-------------------:|:----------------------------:|
+| Small     |            4             |                 8                 |                1                |          4          |              16              |
+| Standard  |            8             |                30                 |                1                |         12          |              48              |
+| Medium    |            16            |                64                 |                2                |         32          |              64              |
+| Large     |            72            |                468                |               3.5               |         48          |             184              |
 
 ### Какие основные меры безопасности следует предпринять индексатору?
 
@@ -149,26 +149,26 @@ Once an allocation has been closed the rebates are available to be claimed by th
 
 #### Graph Node
 
-| Порт | Назначение | Расположение | CLI-аргумент | Переменная среды |
-| --- | --- | --- | --- | --- |
-| 8000 | HTTP-сервер GraphQL<br />(для запросов подграфов) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(для подписок на подграфы) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(для управления процессом развертывания) | / | --admin-port | - |
-| 8030 | API для определения статуса индексирования подграфов | /graphql | --index-node-port | - |
-| 8040 | Показатели Prometheus | /metrics | --metrics-port | - |
+| Порт | Назначение                                                   | Расположение                                         | CLI-аргумент      | Переменная среды |
+| ---- | ------------------------------------------------------------ | ---------------------------------------------------- | ----------------- | ---------------- |
+| 8000 | HTTP-сервер GraphQL<br />(для запросов подграфов)      | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                |
+| 8001 | GraphQL WS<br />(для подписок на подграфы)             | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                |
+| 8020 | JSON-RPC<br />(для управления процессом развертывания) | /                                                    | --admin-port      | -                |
+| 8030 | API для определения статуса индексирования подграфов         | /graphql                                             | --index-node-port | -                |
+| 8040 | Показатели Prometheus                                        | /metrics                                             | --metrics-port    | -                |
 
 #### Indexer Service
 
-| Порт | Назначение | Расположение | CLI-аргумент | Переменная среды |
-| --- | --- | --- | --- | --- |
-| 7600 | HTTP-сервер GraphQL<br />(для платных запросов к подграфам) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Показатели Prometheus | /metrics | --metrics-port | - |
+| Порт | Назначение                                                        | Расположение                                                            | CLI-аргумент   | Переменная среды       |
+| ---- | ----------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | HTTP-сервер GraphQL<br />(для платных запросов к подграфам) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Показатели Prometheus                                             | /metrics                                                                | --metrics-port | -                      |
 
 #### Indexer Agent
 
-| Порт | Назначение | Расположение | CLI-аргумент | Переменная среды |
-| --- | --- | --- | --- | --- |
-| 8000 | API для управления индексатором | / | --indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+| Порт | Назначение                      | Расположение | CLI-аргумент              | Переменная среды                        |
+| ---- | ------------------------------- | ------------ | ------------------------- | --------------------------------------- |
+| 8000 | API для управления индексатором | /            | --indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
 
 ### Настройка серверной инфраструктуры с помощью Terraform в Google Cloud
 

From a71f3bdf8cff447c10102793e2a9598f3d95ff0e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:20 -0500
Subject: [PATCH 0002/3820] New translations publishing-a-subgraph.mdx (French)

---
 website/pages/fr/publishing/publishing-a-subgraph.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/publishing/publishing-a-subgraph.mdx b/website/pages/fr/publishing/publishing-a-subgraph.mdx
index fba2c9221675..c66f02c0b12f 100644
--- a/website/pages/fr/publishing/publishing-a-subgraph.mdx
+++ b/website/pages/fr/publishing/publishing-a-subgraph.mdx
@@ -47,15 +47,15 @@ Vous pouvez uploader votre build de subgraph sur un nœud IPFS spécifique et pe
 
 ```
 USAGE
-  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url 
      <value>]
 
 FLAGS
   -h, --help Afficher l'aide du CLI.
   -i, --ipfs=<value>      [default: https://api.thegraph.com/ipfs/api/v0] Téléchargez les résultats du build sur un nœud IPFS.
-  --ipfs-hash=<value>       Hash IPFS du manifeste du subgraph à déployer.
+  --ipfs-hash=<value>       Hash IPFS du manifeste du subgraph à déployer. 
   --protocol-network=<option> [default: arbitrum-one] Le réseau à utiliser pour le déploiement du subgraph.
-                                <options: arbitrum-one|arbitrum-sepolia>
+                                <options: arbitrum-one|arbitrum-sepolia> 
   --subgraph-id=<value>         ID du subgraph à publier.
   --webapp-url=<value>        [default: https://cli.thegraph.com/publish] URL de l'interface web que vous souhaitez utiliser pour déployer.
 

From f0410e276e5d7ca5bc5a8f2178206814e44d6216 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:22 -0500
Subject: [PATCH 0003/3820] New translations delegating.mdx (French)

---
 website/pages/fr/network/delegating.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/network/delegating.mdx b/website/pages/fr/network/delegating.mdx
index a67c4240c3f9..de7d6558d89c 100644
--- a/website/pages/fr/network/delegating.mdx
+++ b/website/pages/fr/network/delegating.mdx
@@ -49,8 +49,8 @@ Chaque fois qu'un Délégateur veut se désengager, ses jetons sont soumis à un
 Si vous choisissez un Indexeur qui n'est pas fiable ou qui ne fait pas du bon travail, vous voudrez vous désengager. Cela signifie que vous perdrez beaucoup d'opportunités de gagner des récompenses, ce qui peut être aussi mauvais que de brûler des GRT. Par conséquent, il est recommandé de choisir judicieusement un Indexeur.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  !Délégation débondage](/img/Delegation-Unbonding.png) _Notez la commission de 0,5% dans l'interface utilisateur de la
-  délégation, ainsi que la période de débondage de 28 jours. de 28 jours
+  !Délégation débondage](/img/Delegation-Unbonding.png) _Notez la commission de 0,5% dans l'interface utilisateur de la délégation, ainsi que la période de débondage de 28 jours.
+  de 28 jours
 </div>
 
 ### Choisir un indexeur digne de confiance avec une rémunération équitable pour les délégués
@@ -65,7 +65,7 @@ Pour comprendre comment choisir un Indexeur fiable, vous devez comprendre les pa
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
   ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *Le meilleur indexeur donne aux délégués 90 % des récompenses. Le
-  celui du milieu donne 20 % aux délégués. Celui du bas donne aux délégués environ 83 %.*
+   celui du milieu donne 20 % aux délégués. Celui du bas donne aux délégués environ 83 %.*
 </div>
 
 - **Part de Frais de Requête** - C'est comme la part de récompense d'indexation, mais elle s'applique aux gains sur les frais de requête que l'Indexeur collecte.

From 7bd47ad4c21f7f0e614e5daf207f4f50965f8467 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:23 -0500
Subject: [PATCH 0004/3820] New translations indexing.mdx (French)

---
 website/pages/fr/network/indexing.mdx | 32 +++++++++++++--------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/fr/network/indexing.mdx b/website/pages/fr/network/indexing.mdx
index cb42d6d859be..55955d4a56b9 100644
--- a/website/pages/fr/network/indexing.mdx
+++ b/website/pages/fr/network/indexing.mdx
@@ -113,11 +113,11 @@ Les indexeurs peuvent se différencier en appliquant des techniques avancées po
 - **Large** : Prêt à indexer tous les subgraphs actuellement utilisés et à répondre aux demandes pour le trafic associé.
 
 | Installation | Postgres<br />(CPUs) | Postgres<br />(mémoire en Gbs) | Postgres<br />(disque en TB) | VMs<br />(CPUs) | VMs<br />(mémoire en Gbs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Petit | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 11 | 12 | 48 |
-| Moyen | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 |  |
+| ------------ |:--------------------------:|:------------------------------------:|:----------------------------------:|:---------------------:|:-------------------------------:|
+| Petit        |             4              |                  8                   |                 1                  |           4           |               16                |
+| Standard     |             8              |                  30                  |                 11                 |          12           |               48                |
+| Moyen        |             16             |                  64                  |                 2                  |          32           |               64                |
+| Large        |             72             |                 468                  |                3.5                 |          48           |                                 |
 
 ### Quelles sont les précautions de sécurité de base qu’un indexeur doit prendre ?
 
@@ -149,20 +149,20 @@ Remarque : Pour prendre en charge la mise à l'échelle agile, il est recommand
 
 #### Nœud de The Graph
 
-| Port | Objectif | Routes | Argument CLI | Variable d'environnement |
-| --- | --- | --- | --- | --- |
-| 8000 | Serveur HTTP GraphQL<br />(pour les requêtes de subgraphs) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(pour les abonnements aux subgraphs) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(pour gérer les déploiements) | / | --admin-port | - |
-| 8030 | API de statut d'indexation des subgraphs | /graphq | --index-node-port | - |
-| 8040 | Métriques Prometheus | /metrics | --metrics-port | - |
+| Port | Objectif                                                         | Routes                                               | Argument CLI      | Variable d'environnement |
+| ---- | ---------------------------------------------------------------- | ---------------------------------------------------- | ----------------- | ------------------------ |
+| 8000 | Serveur HTTP GraphQL<br />(pour les requêtes de subgraphs) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                        |
+| 8001 | GraphQL WS<br />(pour les abonnements aux subgraphs)       | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                        |
+| 8020 | JSON-RPC<br />(pour gérer les déploiements)                | /                                                    | --admin-port      | -                        |
+| 8030 | API de statut d'indexation des subgraphs                         | /graphq                                              | --index-node-port | -                        |
+| 8040 | Métriques Prometheus                                             | /metrics                                             | --metrics-port    | -                        |
 
 #### Service d'indexation
 
-| Port | Objectif | Routes | Argument CLI | Variable d'environnement |
-| --- | --- | --- | --- | --- |
-| 7600 | Serveur HTTP GraphQL<br />(pour les requêtes payantes de subgraphs) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Métriques Prometheus | /metrics | --metrics-port | - |
+| Port | Objectif                                                                  | Routes                                                                  | Argument CLI   | Variable d'environnement |
+| ---- | ------------------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ------------------------ |
+| 7600 | Serveur HTTP GraphQL<br />(pour les requêtes payantes de subgraphs) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT`   |
+| 7300 | Métriques Prometheus                                                      | /metrics                                                                | --metrics-port | -                        |
 
 #### Agent indexeur
 

From ba48fda66bde3d205fbfddcccac446396fb0d475 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:29 -0500
Subject: [PATCH 0005/3820] New translations quick-start.mdx (Polish)

---
 website/pages/pl/quick-start.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/quick-start.mdx b/website/pages/pl/quick-start.mdx
index 6953408d9420..9a4ebfc960d3 100644
--- a/website/pages/pl/quick-start.mdx
+++ b/website/pages/pl/quick-start.mdx
@@ -1,5 +1,5 @@
 ---
-title: ' Na start'
+title: " Na start"
 ---
 
 Learn how to easily build, publish and query a [subgraph](/developing/developer-faqs/#1-what-is-a-subgraph) on The Graph.

From 589a56e06483053fd14d870fc825af0376e4bdd9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:33 -0500
Subject: [PATCH 0006/3820] New translations api.mdx (Russian)

---
 website/pages/ru/developing/graph-ts/api.mdx | 106 ++++++++++---------
 1 file changed, 54 insertions(+), 52 deletions(-)

diff --git a/website/pages/ru/developing/graph-ts/api.mdx b/website/pages/ru/developing/graph-ts/api.mdx
index ae9840e913d9..b5a90b9930fb 100644
--- a/website/pages/ru/developing/graph-ts/api.mdx
+++ b/website/pages/ru/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ title: AssemblyScript API
 
 `apiVersion` в манифесте субграфа указывает версию мэппинга API, которая запускается посредством Graph Node для данного субграфа.
 
-| Версия | Примечания к релизу |
-| :-: | --- |
-| 0.0.9 | Добавлены новые функции хоста [`eth_get_balance`](#balance-of-an-address) и [`hasCode`](#check-if-an-address-a-contract-or-eoa) |
-| 0.0.8 | Добавлена проверка наличия полей в схеме при сохранении объекта. |
-| 0.0.7 | К типам Ethereum добавлены классы `TransactionReceipt` и `Log`<br />К объекту Ethereum Event добавлено поле `receipt` |
-| 0.0.6 | В объект Ethereum Transaction добавлено поле `nonce`<br />В объект Ethereum Block добавлено поле `baseFeePerGas` |
-| 0.0.5 | AssemblyScript обновлен до версии 0.19.10 (включая критические изменения, см. [`Руководство по миграции`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` переименован в `ethereum.transaction.gasLimit` |
-| 0.0.4 | В объект Ethereum SmartContractCall добавлено поле `functionSignature` |
-| 0.0.3 | В объект Ethereum Call добавлено поле `from`<br />`etherem.call.address` переименован в ethereum.call.to\` |
-| 0.0.2 | В объект Ethereum Transaction добавлено поле `input` |
+| Версия | Примечания к релизу                                                                                                                                                                                                                          |
+| :----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9 | Добавлены новые функции хоста [`eth_get_balance`](#balance-of-an-address) и [`hasCode`](#check-if-an-address-a-contract-or-eoa)                                                                                                              |
+|  0.0.8 | Добавлена проверка наличия полей в схеме при сохранении объекта.                                                                                                                                                                             |
+|  0.0.7 | К типам Ethereum добавлены классы `TransactionReceipt` и `Log`<br />К объекту Ethereum Event добавлено поле `receipt`                                                                                                                        |
+|  0.0.6 | В объект Ethereum Transaction добавлено поле `nonce`<br />В объект Ethereum Block добавлено поле `baseFeePerGas`                                                                                                                             |
+|  0.0.5 | AssemblyScript обновлен до версии 0.19.10 (включая критические изменения, см. [`Руководство по миграции`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` переименован в `ethereum.transaction.gasLimit` |
+|  0.0.4 | В объект Ethereum SmartContractCall добавлено поле `functionSignature`                                                                                                                                                                       |
+|  0.0.3 | В объект Ethereum Call добавлено поле `from`<br />`etherem.call.address` переименован в ethereum.call.to\`                                                                                                                                   |
+|  0.0.2 | В объект Ethereum Transaction добавлено поле `input`                                                                                                                                                                                         |
 
 ### Встроенные типы
 
@@ -233,7 +233,7 @@ API `store` позволяет загружать, сохранять и уда
 // Импорт класса событий Transfer, сгенерированного из ERC20 ABI
 import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
 
-// Импорт типа объекта Transfer, сгенерированного из схемы GraphQL
+// Импорт типа объекта Transfer, сгенерированного из схемы GraphQL 
 import { Transfer } from '../generated/schema'
 событие
 // Обработчик события передачи
@@ -269,6 +269,7 @@ if (transfer == null) {
   transfer = new Transfer(id)
 }
 
+
 // Используйте объект Transfer, как и раньше
 ```
 
@@ -292,6 +293,7 @@ if (transfer == null) {
   transfer = new Transfer(id)
 }
 
+
 // Используйте объект Transfer, как и раньше
 ```
 
@@ -695,8 +697,8 @@ let data = ipfs.cat(path)
 import { JSONValue, Value } from '@graphprotocol/graph-ts'
 
 export function processItem(value: JSONValue, userData: Value): void {
-  // Смотрите документацию по JsonValue для получения подробной информации о работе
-  // со значениями JSON
+// Смотрите документацию по JsonValue для получения подробной информации о работе
+// со значениями JSON
   let obj = value.toObject()
   let id = obj.get('id')
   let title = obj.get('title')
@@ -705,7 +707,7 @@ export function processItem(value: JSONValue, userData: Value): void {
     return
   }
 
-  // Обратные вызовы также могут создавать объекты
+// Обратные вызовы также могут создавать объекты
   let newItem = new Item(id)
   newItem.title = title.toString()
   newitem.parent = userData.toString() // Установите для родителя значение "parentId"
@@ -770,44 +772,44 @@ if (value.kind == JSONValueKind.BOOL) {
 
 ### Справка по преобразованию типов
 
-| Источник(и)          | Место назначения     | Функция преобразования        |
-| -------------------- | -------------------- | ----------------------------- |
-| Address              | Bytes                | отсутствует                   |
-| Address              | String               | s.toHexString()               |
-| BigDecimal           | String               | s.toString()                  |
-| BigInt               | BigDecimal           | s.toBigDecimal()              |
-| BigInt               | String (hexadecimal) | s.toHexString() или s.toHex() |
-| BigInt               | String (unicode)     | s.toString()                  |
-| BigInt               | i32                  | s.toI32()                     |
-| Boolean              | Boolean              | отсутствует                   |
-| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)     |
-| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)   |
-| Bytes                | String (hexadecimal) | s.toHexString() или s.toHex() |
-| Bytes                | String (unicode)     | s.toString()                  |
-| Bytes                | String (base58)      | s.toBase58()                  |
-| Bytes                | i32                  | s.toI32()                     |
-| Bytes                | u32                  | s.toU32()                     |
-| Bytes                | JSON                 | json.fromBytes(s)             |
-| int8                 | i32                  | отсутствует                   |
-| int32                | i32                  | отсутствует                   |
-| int32                | BigInt               | BigInt.fromI32(s)             |
-| uint24               | i32                  | отсутствует                   |
-| int64 - int256       | BigInt               | отсутствует                   |
-| uint32 - uint256     | BigInt               | отсутствует                   |
-| JSON                 | boolean              | s.toBool()                    |
-| JSON                 | i64                  | s.toU64()                     |
-| JSON                 | u64                  | s.toU64()                     |
-| JSON                 | f64                  | s.toF64()                     |
-| JSON                 | BigInt               | s.toBigInt()                  |
-| JSON                 | string               | s.toString()                  |
-| JSON                 | Array                | s.toArray()                   |
-| JSON                 | Object               | s.toObject()                  |
-| String               | Address              | Address.fromString(s)         |
-| Bytes                | Address              | Address.fromBytes(s)          |
-| String               | BigInt               | BigInt.fromString(s)          |
-| String               | BigDecimal           | BigDecimal.fromString(s)      |
-| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)    |
-| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)         |
+| Источник(и)            | Место назначения          | Функция преобразования              |
+| ---------------------- | ------------------------- | ----------------------------------- |
+| Address                | Bytes                     | отсутствует                         |
+| Address                | String                    | s.toHexString()                     |
+| BigDecimal             | String                    | s.toString()                        |
+| BigInt                 | BigDecimal                | s.toBigDecimal()                    |
+| BigInt                 | String (hexadecimal)      | s.toHexString() или s.toHex()       |
+| BigInt                 | String (unicode)          | s.toString()                        |
+| BigInt                 | i32                       | s.toI32()                           |
+| Boolean                | Boolean                   | отсутствует                         |
+| Bytes (signed)         | BigInt                    | BigInt.fromSignedBytes(s)           |
+| Bytes (unsigned)       | BigInt                    | BigInt.fromUnsignedBytes(s)         |
+| Bytes                  | String (hexadecimal)      | s.toHexString() или s.toHex()       |
+| Bytes                  | String (unicode)          | s.toString()                        |
+| Bytes                  | String (base58)           | s.toBase58()                        |
+| Bytes                  | i32                       | s.toI32()                           |
+| Bytes                  | u32                       | s.toU32()                           |
+| Bytes                  | JSON                      | json.fromBytes(s)                   |
+| int8                   | i32                       | отсутствует                         |
+| int32                  | i32                       | отсутствует                         |
+| int32                  | BigInt                    | BigInt.fromI32(s)                   |
+| uint24                 | i32                       | отсутствует                         |
+| int64 - int256         | BigInt                    | отсутствует                         |
+| uint32 - uint256       | BigInt                    | отсутствует                         |
+| JSON                   | boolean                   | s.toBool()                          |
+| JSON                   | i64                       | s.toU64()                           |
+| JSON                   | u64                       | s.toU64()                           |
+| JSON                   | f64                       | s.toF64()                           |
+| JSON                   | BigInt                    | s.toBigInt()                        |
+| JSON                   | string                    | s.toString()                        |
+| JSON                   | Array                     | s.toArray()                         |
+| JSON                   | Object                    | s.toObject()                        |
+| String                 | Address                   | Address.fromString(s)               |
+| Bytes                  | Address                   | Address.fromBytes(s)                |
+| String                 | BigInt                    | BigInt.fromString(s)                |
+| String                 | BigDecimal                | BigDecimal.fromString(s)            |
+| String (hexadecimal)   | Bytes                     | ByteArray.fromHexString(s)          |
+| String (UTF-8)         | Bytes                     | ByteArray.fromUTF8(s)               |
 
 ### Метаданные источника данных
 

From 51c89341f4797e387a4bd6d321b2002043d8279c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:40 -0500
Subject: [PATCH 0007/3820] New translations indexing.mdx (Turkish)

---
 website/pages/tr/network/indexing.mdx | 34 +++++++++++++--------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/tr/network/indexing.mdx b/website/pages/tr/network/indexing.mdx
index 27984b79fe2a..a9c25ebeee43 100644
--- a/website/pages/tr/network/indexing.mdx
+++ b/website/pages/tr/network/indexing.mdx
@@ -112,12 +112,12 @@ Indexers may differentiate themselves by applying advanced techniques for making
 - **Orta** - 100 subgraph ve saniyede 200-500 isteği destekleyen Üretim İndeksleyici.
 - **Yüksek** - Şu anda kullanılan tüm subgraphları indekslemek ve ilgili trafik için istekleri sunmak için hazırlanmıştır.
 
-| Kurulum | Postgres<br />(CPU'lar) | Postgres<br />(GB cinsinden bellek) | Postgres<br />(TB cinsinden disk) | VM'ler<br />(CPU'lar) | VM'ler<br />(GB cinsinden bellek) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Düşük | 4 | 8 | 1 | 4 | 16 |
-| Standart | 8 | 30 | 1 | 12 | 48 |
-| Orta | 16 | 64 | 2 | 32 | 64 |
-| Yüksek | 72 | 468 | 3.5 | 48 | 184 |
+| Kurulum  | Postgres<br />(CPU'lar) | Postgres<br />(GB cinsinden bellek) | Postgres<br />(TB cinsinden disk) | VM'ler<br />(CPU'lar) | VM'ler<br />(GB cinsinden bellek) |
+| -------- |:-----------------------------:|:-----------------------------------------:|:---------------------------------------:|:---------------------------:|:---------------------------------------:|
+| Düşük    |               4               |                     8                     |                    1                    |              4              |                   16                    |
+| Standart |               8               |                    30                     |                    1                    |             12              |                   48                    |
+| Orta     |              16               |                    64                     |                    2                    |             32              |                   64                    |
+| Yüksek   |              72               |                    468                    |                   3.5                   |             48              |                   184                   |
 
 ### Bir İndeksleyicinin alması gereken bazı temel güvenlik önlemleri nelerdir?
 
@@ -149,20 +149,20 @@ Not: Çevik ölçeklendirmeyi desteklemek için, sorgulama ve indeksleme endişe
 
 #### Graph Node
 
-| Port | Amaç | Rotalar | CLI Argümanı | Ortam Değişkeni |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP sunucusu<br />( subgraph sorguları için) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />( subgraph abonelikleri için) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(dağıtımları yönetmek için) | / | --admin-port | - |
-| 8030 | Subgraph indeksleme durum API'si | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrikleri | /metrics | --metrics-port | - |
+| Port | Amaç                                                        | Rotalar                                              | CLI Argümanı      | Ortam Değişkeni |
+| ---- | ----------------------------------------------------------- | ---------------------------------------------------- | ----------------- | --------------- |
+| 8000 | GraphQL HTTP sunucusu<br />( subgraph sorguları için) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -               |
+| 8001 | GraphQL WS<br />( subgraph abonelikleri için)         | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -               |
+| 8020 | JSON-RPC<br />(dağıtımları yönetmek için)             | /                                                    | --admin-port      | -               |
+| 8030 | Subgraph indeksleme durum API'si                            | /graphql                                             | --index-node-port | -               |
+| 8040 | Prometheus metrikleri                                       | /metrics                                             | --metrics-port    | -               |
 
 #### İndeksleyici Hizmeti
 
-| Port | Amaç | Rotalar | CLI Argümanı | Ortam Değişkeni |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP sunucusu<br />(ücretli subgraph sorguları için) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrikleri | /metrics | --metrics-port | - |
+| Port | Amaç                                                               | Rotalar                                                                 | CLI Argümanı   | Ortam Değişkeni        |
+| ---- | ------------------------------------------------------------------ | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP sunucusu<br />(ücretli subgraph sorguları için) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrikleri                                              | /metrics                                                                | --metrics-port | -                      |
 
 #### İndeksleyici Aracı
 

From ac7f61db103f51fcc869754cbcb41f635d7a782c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:41 -0500
Subject: [PATCH 0008/3820] New translations unit-testing-framework.mdx
 (Russian)

---
 .../ru/developing/unit-testing-framework.mdx  | 56 +++++++++----------
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/website/pages/ru/developing/unit-testing-framework.mdx b/website/pages/ru/developing/unit-testing-framework.mdx
index e50b9e7f4d2b..698e25117b45 100644
--- a/website/pages/ru/developing/unit-testing-framework.mdx
+++ b/website/pages/ru/developing/unit-testing-framework.mdx
@@ -382,7 +382,7 @@ describe("handleNewGravatars, () => {
 
 ```typescript
 import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
-import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
 
 describe('handleUpdatedGravatars', () => {
   beforeEach(() => {
@@ -1108,29 +1108,29 @@ test('Data source simple mocking example', () => {
 
 ```typescript
 test('ethereum/contract dataSource creation example', () => {
-  // Подтверждаем, что не создано ни одного источника данных из шаблона GraphTokenLockWallet
-  assert.dataSourceCount('GraphTokenLockWallet', 0)
+// Подтверждаем, что не создано ни одного источника данных из шаблона GraphTokenLockWallet
+assert.dataSourceCount('GraphTokenLockWallet', 0)
 
-  // Создаем новый источник данных GraphTokenLockWallet с адресом 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
-  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+// Создаем новый источник данных GraphTokenLockWallet с адресом 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
 
-  // Подтверждаем, что источник данных создан
-  assert.dataSourceCount('GraphTokenLockWallet', 1)
+// Подтверждаем, что источник данных создан
+assert.dataSourceCount('GraphTokenLockWallet', 1)
 
-  // Добавляем второй источник данных с контекстом
-  let context = new DataSourceContext()
-  context.set('contextVal', Value.fromI32(325))
+// Добавляем второй источник данных с контекстом
+let context = new DataSourceContext()
+context.set('contextVal', Value.fromI32(325))
 
-  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
 
-  // Подтверждаем, что теперь есть 2 источника данных
-  assert.dataSourceCount('GraphTokenLockWallet', 2)
+// Подтверждаем, что теперь есть 2 источника данных
+assert.dataSourceCount('GraphTokenLockWallet', 2)
 
-  // Подтверждаем, что был создан источник данных с адресом "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B"
-  // Имейте в виду, что тип `Address` преобразуется в строчные буквы при декодировании, поэтому адрес нужно передавать полностью в нижнем регистре, когда Вы проверяете его наличие.
-  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+// Подтверждаем, что был создан источник данных с адресом "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B"
+// Имейте в виду, что тип `Address` преобразуется в строчные буквы при декодировании, поэтому адрес нужно передавать полностью в нижнем регистре, когда Вы проверяете его наличие.
+assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
 
-  logDataSources('GraphTokenLockWallet')
+logDataSources('GraphTokenLockWallet')
 })
 ```
 
@@ -1218,11 +1218,11 @@ type TokenLockMetadata @entity {
 
 ```typescript
 export function handleMetadata(content: Bytes): void {
-  // dataSource.stringParams() возвращает CID источника данных файла
-  // stringParam() будет имитироваться в тесте обработчика
-  // для получения дополнительной информации https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
-  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
-  const value = json.fromBytes(content).toObject()
+ // dataSource.stringParams() возвращает CID источника данных файла
+// stringParam() будет имитироваться в тесте обработчика
+// для получения дополнительной информации https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+const value = json.fromBytes(content).toObject()
 
   if (value) {
     const startTime = value.get('startTime')
@@ -1267,7 +1267,7 @@ test('file/ipfs dataSource creation example', () => {
   logDataSources('GraphTokenLockMetadata')
 
   // Теперь нам нужно смоделировать метаданные dataSource, в частности,
-  dataSource.stringParam()
+ dataSource.stringParam()
   // dataSource.stringParams на самом деле использует значение dataSource.address(), поэтому мы будем имитировать адрес, используя dataSourceMock из matchstick-as
   // Сначала мы сбросим значения, а затем используем dataSourceMock.setAddress() для установки CID
   dataSourceMock.resetValues()
@@ -1381,15 +1381,15 @@ Global test coverage: 22.2% (2/9 handlers).
 Это означает, что Вы использовали в своем коде `console.log`, который не поддерживается AssemblyScript. Пожалуйста, рассмотрите возможность использования [API логирования](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 Несовпадение в аргументах вызвано несоответствием в `graph-ts` и `matchstick-as`. Лучший способ устранить проблемы, подобные этой, - обновить всё до последней выпущенной версии.

From c582bf1282fc3b78c4b2d5dc82d53b298239961a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:43 -0500
Subject: [PATCH 0009/3820] New translations delegating.mdx (Russian)

---
 website/pages/ru/network/delegating.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ru/network/delegating.mdx b/website/pages/ru/network/delegating.mdx
index 95e737c063a9..423bafc439ab 100644
--- a/website/pages/ru/network/delegating.mdx
+++ b/website/pages/ru/network/delegating.mdx
@@ -49,8 +49,8 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
 If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Обратите внимание на комиссию в размере 0,5% в
-  пользовательском интерфейсе Delegation, а также на 28-дневный срок период разблокировки._
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Обратите внимание на комиссию в размере 0,5% в пользовательском интерфейсе Delegation, а также на 28-дневный срок
+  период разблокировки._
 </div>
 
 ### Выбор надежного Индексатора со справедливым распределением вознаграждений для Делегаторов

From e4ffc4ee07bf9ae16bda0bbf5d01bb6288fcefbc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:45 -0500
Subject: [PATCH 0010/3820] New translations developing.mdx (Hindi)

---
 website/pages/hi/network/developing.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/network/developing.mdx b/website/pages/hi/network/developing.mdx
index 6c027c7e2b1c..edd73ccbe18e 100644
--- a/website/pages/hi/network/developing.mdx
+++ b/website/pages/hi/network/developing.mdx
@@ -15,7 +15,7 @@ The Graph पर, आप:
 
 ### GraphQL क्या है?
 
-- [GraphQL](https://graphql.org/learn/) APIs के लिए एक क्वेरी भाषा और आपके मौजूदा डेटा के साथ उन क्वेरीज़ को पूरा करने के लिए एक रनटाइम। The Graph सबग्राफ को क्वेरी करने के लिए GraphQL का उपयोग करता है।
+- [GraphQL](https://graphql.org/learn/) APIs  के लिए एक क्वेरी भाषा और आपके मौजूदा डेटा के साथ उन क्वेरीज़ को पूरा करने के लिए एक रनटाइम। The Graph सबग्राफ को क्वेरी करने के लिए GraphQL का उपयोग करता है।
 
 ### डेवलपर क्रियाएँ
 

From 1a5723400c63df53773ed4234af81e1e8cebe9b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:46 -0500
Subject: [PATCH 0011/3820] New translations tap.mdx (Hindi)

---
 website/pages/hi/tap.mdx | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/hi/tap.mdx b/website/pages/hi/tap.mdx
index ca4837de335e..85f9f8b123ac 100644
--- a/website/pages/hi/tap.mdx
+++ b/website/pages/hi/tap.mdx
@@ -51,13 +51,13 @@ TAP एक प्रेषक को एक प्राप्तकर्ता
 | AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
 | Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
 
-### गेटवे
+### गेटवे 
 
-| घटक              | Edge and Node Mainnet (Aribtrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
-| ---------------- | --------------------------------------------- | --------------------------------------------- |
-| प्रेषक           | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
-| हस्ताक्षरकर्ता   | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
-| संकेन्द्रीयकर्ता | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+| घटक               | Edge and Node Mainnet (Aribtrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ----------------- | --------------------------------------------- | --------------------------------------------- |
+| प्रेषक            | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| हस्ताक्षरकर्ता    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| संकेन्द्रीयकर्ता  | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
 
 ### Requirements
 
@@ -171,7 +171,7 @@ max_amount_willing_to_lose_grt = 20
 टिप्पणियाँ:
 
 - tap.sender_aggregator_endpoints के लिए मान gateway section (/tap/#gateway). में पाए जा सकते हैं।
-- blockchain.receipts_verifier_address के लिए मानों का उपयोग उचित तरीके से Blockchain addresses section (/tap/#contracts) के अनुसार किया जाना चाहिए, जिसमें उचित चेन आईडी का उपयोग किया गया है।
+- blockchain.receipts_verifier_address के लिए मानों का उपयोग उचित तरीके से Blockchain addresses section (/tap/#contracts)  के अनुसार किया जाना चाहिए, जिसमें उचित चेन आईडी का उपयोग किया गया है।
 
 **लॉग स्तर**
 
@@ -186,7 +186,7 @@ max_amount_willing_to_lose_grt = 20
 
 ### Grafana डैशबोर्ड
 
-आप Grafana Dashboard (https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) डाउनलोड कर सकते हैं और इम्पोर्ट कर सकते हैं।
+आप Grafana Dashboard (https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json)  डाउनलोड कर सकते हैं और इम्पोर्ट कर सकते हैं।
 
 ### लॉन्चपैड
 

From f37d2da3849612a70a90e5e3f38b4a01079d9d32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:50 -0500
Subject: [PATCH 0012/3820] New translations developer-faqs.mdx (Hindi)

---
 website/pages/hi/developing/developer-faqs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/developing/developer-faqs.mdx b/website/pages/hi/developing/developer-faqs.mdx
index b335b8eb8867..ec23a849d8cb 100644
--- a/website/pages/hi/developing/developer-faqs.mdx
+++ b/website/pages/hi/developing/developer-faqs.mdx
@@ -135,7 +135,7 @@ someCollection(first: 1000, skip: <number>) { ... }
 
 ## विविध
 
-### क्या Apollo Federation का उपयोग graph-node के ऊपर किया जा सकता है?
+### क्या Apollo Federation  का उपयोग graph-node के ऊपर किया जा सकता है?
 
 Federation अभी समर्थित नहीं है। फिलहाल, आप schema stitching का उपयोग कर सकते हैं, या तो क्लाइंट पर या एक प्रॉक्सी सेवा के माध्यम से।
 

From d133142c97d80f9933bf32780a13795757ee7819 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:53 -0500
Subject: [PATCH 0013/3820] New translations indexing.mdx (Hindi)

---
 website/pages/hi/network/indexing.mdx | 38 +++++++++++++--------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/website/pages/hi/network/indexing.mdx b/website/pages/hi/network/indexing.mdx
index bae7b6240635..62544f991701 100644
--- a/website/pages/hi/network/indexing.mdx
+++ b/website/pages/hi/network/indexing.mdx
@@ -112,12 +112,12 @@ Once an allocation has been closed the rebates are available to be claimed by th
 - **माध्यम** - प्रोडक्शन इंडेक्सर प्रति सेकंड 100 सबग्राफ और 200-500 अनुरोधों का समर्थन करता है।
 - **बड़ा** - वर्तमान में उपयोग किए जाने वाले सभी सबग्राफ को अनुक्रमित करने और संबंधित ट्रैफ़िक के अनुरोधों को पूरा करने के लिए तैयार है।
 
-| Setup | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Small | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 | 184 |
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- |:--------------------------:|:-----------------------------------:|:---------------------------------:|:---------------------:|:------------------------------:|
+| Small    |             4              |                  8                  |                 1                 |           4           |               16               |
+| Standard |             8              |                 30                  |                 1                 |          12           |               48               |
+| Medium   |             16             |                 64                  |                 2                 |          32           |               64               |
+| Large    |             72             |                 468                 |                3.5                |          48           |              184               |
 
 ### एक इंडेक्सर को कौन सी बुनियादी सुरक्षा सावधानियां बरतनी चाहिए?
 
@@ -149,20 +149,20 @@ Once an allocation has been closed the rebates are available to be claimed by th
 
 #### Graph Node
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(सबग्राफ प्रश्नों के लिए) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(सबग्राफ सब्सक्रिप्शन के लिए) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(तैनाती के प्रबंधन के लिए) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                                  | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | -------------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(सबग्राफ प्रश्नों के लिए) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(सबग्राफ सब्सक्रिप्शन के लिए)      | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(तैनाती के प्रबंधन के लिए)           | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                             | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                       | /metrics                                             | --metrics-port    | -                    |
 
 #### Indexer Service
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server<br />(सबग्राफ प्रश्नों के लिए) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                                  | Routes                                                                  | CLI Argument   | Environment Variable   |
+| ---- | -------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(सबग्राफ प्रश्नों के लिए) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                       | /metrics                                                                | --metrics-port | -                      |
 
 #### Indexer Agent
 
@@ -559,7 +559,7 @@ graph indexer status
 
 - `ग्राफ़ अनुक्रमणिका क्रियाएँ स्वीकृत निष्पादित करती हैं` - कार्यकर्ता को स्वीकृत क्रियाओं को तुरंत निष्पादित करने के लिए बाध्य करें
 
-सभी आदेश जो आउटपुट में नियम प्रदर्शित करते हैं, समर्थित आउटपुट स्वरूपों (`तालिका`, `yaml`, और `json`) के बीच `का उपयोग करके चुन सकते हैं - आउटपुट` तर्क।
+सभी आदेश जो आउटपुट में नियम प्रदर्शित करते हैं, समर्थित आउटपुट स्वरूपों (`तालिका`, `yaml`, और `json`) के बीच ` का उपयोग करके चुन सकते हैं - आउटपुट ` तर्क।
 
 #### Indexing rules
 
@@ -623,7 +623,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 - सभी कतारबद्ध क्रियाओं को देखने के लिए इंडेक्सर `indexer-cli` का उपयोग कर सकता है
 - इंडेक्सर (या अन्य सॉफ़्टवेयर) `इंडेक्सर-क्ली` का उपयोग करके कतार में क्रियाओं को स्वीकृत या रद्द कर सकता है। स्वीकृति और रद्द करने के आदेश इनपुट के रूप में क्रिया आईडी की एक सरणी लेते हैं।
 - निष्पादन कार्यकर्ता नियमित रूप से स्वीकृत कार्यों के लिए कतार का चुनाव करता है। यह कतार से `अनुमोदित` कार्यों को पकड़ लेगा, उन्हें निष्पादित करने का प्रयास करेगा, और निष्पादन की स्थिति के आधार पर डीबी में मूल्यों को `सफलता` या `विफल< पर अपडेट करेगा। /0>.</li>
-  <li>If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in <code>auto` or `oversight` mode.
+<li>If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in <code>auto` or `oversight` mode.
 - अनुक्रमणक क्रिया निष्पादन के इतिहास को देखने के लिए क्रिया कतार की निगरानी कर सकता है और यदि आवश्यक हो तो निष्पादन विफल होने पर क्रिया आइटम को पुन: अनुमोदित और अद्यतन कर सकता है। क्रिया कतार पंक्तिबद्ध और की गई सभी कार्रवाइयों का इतिहास प्रदान करती है।
 
 डेटा मॉडल:

From 92dae59f4ede6892e10725c176b7d3b80b460f98 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:54 -0500
Subject: [PATCH 0014/3820] New translations api.mdx (Hindi)

---
 website/pages/hi/developing/graph-ts/api.mdx | 26 +++++++++-----------
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/website/pages/hi/developing/graph-ts/api.mdx b/website/pages/hi/developing/graph-ts/api.mdx
index 9d914991e327..b43331af7860 100644
--- a/website/pages/hi/developing/graph-ts/api.mdx
+++ b/website/pages/hi/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| संस्करण | रिलीज नोट्स |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| संस्करण | रिलीज नोट्स                                                                                                                                                                                                                                   |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### अंतर्निहित प्रकार
 
@@ -595,11 +595,7 @@ The `log` API includes the following functions:
 The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
 
 ```typescript
-log.info('संदेश प्रदर्शित किया जाना है: {}, {}, {}', [
-  value.toString(),
-  OtherValue.toString(),
-  'पहले से ही एक स्ट्रिंग',
-])
+log.info ('संदेश प्रदर्शित किया जाना है: {}, {}, {}', [value.toString (), OtherValue.toString (), 'पहले से ही एक स्ट्रिंग'])
 ```
 
 #### एक या अधिक मान लॉग करना

From ef96bbd693dbb5e13a4e57b6416b02ea59ff0aae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:56 -0500
Subject: [PATCH 0015/3820] New translations triggers-example.mdx (Hindi)

---
 website/pages/hi/sps/triggers-example.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/sps/triggers-example.mdx b/website/pages/hi/sps/triggers-example.mdx
index ae7347e22d72..2f9eab3900f0 100644
--- a/website/pages/hi/sps/triggers-example.mdx
+++ b/website/pages/hi/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'ट्यूटोरियल: Solana पर एक Substreams-शक्ति वाले Subgraph सेट करें'
+title: "ट्यूटोरियल: Solana पर एक Substreams-शक्ति वाले Subgraph सेट करें"
 ---
 
 ## आवश्यक शर्तें
@@ -49,7 +49,7 @@ params: # Modify the param fields to meet your needs
 
 ## चरण 2: Subgraph Manifest उत्पन्न करें
 
-एक बार जब प्रोजेक्ट इनिशियलाइज़ हो जाए, Dev Container में निम्नलिखित कमांड चलाकर subgraph मैनिफेस्ट जेनरेट करें:
+एक बार जब प्रोजेक्ट इनिशियलाइज़ हो जाए, Dev Container में निम्नलिखित कमांड चलाकर subgraph मैनिफेस्ट जेनरेट करें: 
 
 ```bash
 'सबस्ट्रीम्स कोडजेन' subgraph

From 9e35fb6dcf03ac66543170a42a0110d61267a6c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:57 -0500
Subject: [PATCH 0016/3820] New translations transfer-a-subgraph.mdx (Hindi)

---
 website/pages/hi/managing/transfer-a-subgraph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/managing/transfer-a-subgraph.mdx b/website/pages/hi/managing/transfer-a-subgraph.mdx
index fa8e363f09df..f424782f7940 100644
--- a/website/pages/hi/managing/transfer-a-subgraph.mdx
+++ b/website/pages/hi/managing/transfer-a-subgraph.mdx
@@ -4,7 +4,7 @@ title: सबग्राफ ट्रांसफर करें
 
 विभिन्न नेटवर्क पर प्रकाशित subgraphs के लिए उस पते पर एक NFT जारी किया गया है जिसने subgraph प्रकाशित किया। NFT एक मानक ERC721 पर आधारित है, जो The Graph नेटवर्क पर खातों के बीच स्थानांतरण की सुविधा देता है।
 
-## अनुस्मारक
+## अनुस्मारक 
 
 - जो भी 'NFT' का मालिक है, वह subgraph को नियंत्रित करता है।
 - यदि मालिक 'NFT' को बेचने या स्थानांतरित करने का निर्णय लेता है, तो वे नेटवर्क पर उस subgraph को संपादित या अपडेट नहीं कर पाएंगे।

From c59e43a87f5e8840679e118cdfdbf89b7dba5883 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:54:59 -0500
Subject: [PATCH 0017/3820] New translations benefits.mdx (French)

---
 website/pages/fr/network/benefits.mdx | 73 +++++++++++++--------------
 1 file changed, 36 insertions(+), 37 deletions(-)

diff --git a/website/pages/fr/network/benefits.mdx b/website/pages/fr/network/benefits.mdx
index d290716f01bd..702f6c0a5a86 100644
--- a/website/pages/fr/network/benefits.mdx
+++ b/website/pages/fr/network/benefits.mdx
@@ -27,54 +27,53 @@ Les coûts d'interrogation peuvent varier ; le coût indiqué est la moyenne au
 
 ## Utilisateur à faible volume (moins de 100 000 requêtes par mois)
 
-| Cost Comparison | Auto-hébergé | The Graph Network |
-| :-: | :-: | :-: |
-| Coût mensuel du serveur\* | 350 $ au mois | 0 $ |
-| Frais de requête | + 0 $ | 0$ par mois |
-| Temps d'ingénierie<sup>†</sup> | 400 $ au mois | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
-| Requêtes au mois | Limité aux capacités infra | 100 000 (Plan Gratuit) |
-| Tarif par requête | 0 $ | 0$<sup>‡</sup> |
-| Les infrastructures | Centralisée | Décentralisée |
-| La redondance géographique | 750$+ par nœud complémentaire | Compris |
-| Temps de disponibilité | Variable | + 99.9% |
-| Total des coûts mensuels | <span className="highlight-row" />+ 750 $ | 0 $ |
+|        Cost Comparison         |               Auto-hébergé                |                              The Graph Network                              |
+|:------------------------------:|:-----------------------------------------:|:---------------------------------------------------------------------------:|
+|  Coût mensuel du serveur\*   |               350 $ au mois               |                                     0 $                                     |
+|        Frais de requête        |                   + 0 $                   |                                 0$ par mois                                 |
+| Temps d'ingénierie<sup>†</sup> |               400 $ au mois               | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
+|        Requêtes au mois        |        Limité aux capacités infra         |                           100 000 (Plan Gratuit)                            |
+|       Tarif par requête        |                    0 $                    |                               0$<sup>‡</sup>                                |
+|      Les infrastructures       |                Centralisée                |                                Décentralisée                                |
+|   La redondance géographique   |       750$+ par nœud complémentaire       |                                   Compris                                   |
+|     Temps de disponibilité     |                 Variable                  |                                   + 99.9%                                   |
+|    Total des coûts mensuels    | <span className="highlight-row" />+ 750 $ |                                     0 $                                     |
 
 ## Utilisateur à volume moyen (~3M requêtes par mois)
 
-| Comparaison de coût | Auto-hébergé | The Graph Network |
-| :-: | :-: | :-: |
-| Coût mensuel du serveur\* | 350 $ au mois | 0 $ |
-| Frais de requête | 500 $ au mois | 120$ par mois |
-| Temps d'ingénierie<sup>†</sup> | 800 $ au mois | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
-| Requêtes au mois | Limité aux capacités infra | ~3,000,000 |
-| Tarif par requête | 0 $ | $0.00004 |
-| L'infrastructure | Centralisée | Décentralisée |
-| Frais d'ingénierie | 200 $ au mois | Compris |
-| La redondance géographique | 1 200 $ coût total par nœud supplémentaire | Compris |
-| Temps de disponibilité | Variable | + 99.9% |
-| Total des coûts mensuels | <span className="highlight-row" /> + 1650 $ | 120$ |
+|      Comparaison de coût       |                Auto-hébergé                 |                              The Graph Network                              |
+|:------------------------------:|:-------------------------------------------:|:---------------------------------------------------------------------------:|
+|  Coût mensuel du serveur\*   |                350 $ au mois                |                                     0 $                                     |
+|        Frais de requête        |                500 $ au mois                |                                120$ par mois                                |
+| Temps d'ingénierie<sup>†</sup> |                800 $ au mois                | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
+|        Requêtes au mois        |         Limité aux capacités infra          |                                 ~3,000,000                                  |
+|       Tarif par requête        |                     0 $                     |                                  $0.00004                                   |
+|        L'infrastructure        |                 Centralisée                 |                                Décentralisée                                |
+|       Frais d'ingénierie       |                200 $ au mois                |                                   Compris                                   |
+|   La redondance géographique   | 1 200 $ coût total par nœud supplémentaire  |                                   Compris                                   |
+|     Temps de disponibilité     |                  Variable                   |                                   + 99.9%                                   |
+|    Total des coûts mensuels    | <span className="highlight-row" /> + 1650 $ |                                    120$                                     |
 
 ## Utilisateur à volume élevé (~30M requêtes par mois)
 
-| Comparaison des coûts | Auto-hébergé | The Graph Network |
-| :-: | :-: | :-: |
-| Coût mensuel du serveur\* | 1100 $ au mois, par nœud | 0 $ |
-| Frais de requête | 4000 $ | 1 200 $ par mois |
-| Nombre de nœuds obligatoires | 10 | Sans objet |
-| Temps d'ingénierie<sup>†</sup> | 6000 $ ou plus au mois | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
-| Requêtes au mois | Limité aux capacités infra | ~30,000,000 |
-| Tarif par requête | 0 $ | 0.00004$ |
-| L'infrastructure | Centralisée | Décentralisée |
-| La redondance géographique | 1 200 $ de coûts totaux par nœud supplémentaire | Compris |
-| Temps de disponibilité | Variable | + 99.9% |
-| Total des coûts mensuels | <span className="highlight-row" /> + 11 000 $ | 1,200$ |
+|     Comparaison des coûts      |                  Auto-hébergé                   |                              The Graph Network                              |
+|:------------------------------:|:-----------------------------------------------:|:---------------------------------------------------------------------------:|
+|  Coût mensuel du serveur\*   |            1100 $ au mois, par nœud             |                                     0 $                                     |
+|        Frais de requête        |                     4000 $                      |                              1 200 $ par mois                               |
+|  Nombre de nœuds obligatoires  |                       10                        |                                 Sans objet                                  |
+| Temps d'ingénierie<sup>†</sup> |             6000 $ ou plus au mois              | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
+|        Requêtes au mois        |           Limité aux capacités infra            |                                 ~30,000,000                                 |
+|       Tarif par requête        |                       0 $                       |                                  0.00004$                                   |
+|        L'infrastructure        |                   Centralisée                   |                                Décentralisée                                |
+|   La redondance géographique   | 1 200 $ de coûts totaux par nœud supplémentaire |                                   Compris                                   |
+|     Temps de disponibilité     |                    Variable                     |                                   + 99.9%                                   |
+|    Total des coûts mensuels    |  <span className="highlight-row" /> + 11 000 $  |                                   1,200$                                    |
 
 \*y compris les coûts de sauvegarde : $50-$ à 100 dollars au mois
 
 <sup>†</sup>Temps d'ingénierie basé sur une hypothèse de 200 $ de l'heure
 
-<sup>‡</sup>Reflète le coût pour le consommateur de données. Les frais de requête sont toujours payés aux Indexeurs pour
-les requêtes du Plan Gratuit.
+<sup>‡</sup>Reflète le coût pour le consommateur de données. Les frais de requête sont toujours payés aux Indexeurs pour les requêtes du Plan Gratuit.
 
 Les coûts estimés sont uniquement pour les subgraphs Ethereum Mainnet - les coûts sont encore plus élevés lorsqu'on héberge soi-même un `graph-node` sur d'autres réseaux. Certains utilisateurs peuvent avoir besoin de mettre à jour leur subgraph vers une nouvelle version. En raison des frais de gaz Ethereum, une mise à jour coûte ~50 $ au moment de la rédaction. Notez que les frais de gaz sur [Arbitrum](/arbitrum/arbitrum-faq) sont considérablement plus bas que ceux d'Ethereum mainnet.
 

From 0c095931b426b5c1c5bbbf90d035deab89005abf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:00 -0500
Subject: [PATCH 0018/3820] New translations graphql-api.mdx (French)

---
 website/pages/fr/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/fr/querying/graphql-api.mdx b/website/pages/fr/querying/graphql-api.mdx
index ddc2030bdef5..d6965cc4cc87 100644
--- a/website/pages/fr/querying/graphql-api.mdx
+++ b/website/pages/fr/querying/graphql-api.mdx
@@ -223,7 +223,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Sucre syntaxique :** Vous pouvez simplifier la requête ci-dessus en supprimant l'opérateur `et` en passant une sous-expression séparée par des virgules.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -337,12 +337,12 @@ Les champs de requête de recherche en texte `intégral`, fournissent une Api de
 
 Opérateurs de recherche en texte intégral :
 
-| Symbole | Opérateur | Description |
-| --- | --- | --- |
-| `&` | `And` | Pour combiner plusieurs termes de recherche dans un filtre pour les entités incluant tous les termes fournis |
-| &#x7c; | `Or` | Les requêtes comportant plusieurs termes de recherche séparés par l'opérateur ou renverront toutes les entités correspondant à l'un des termes fournis |
-| `<>` | `Follow by` | Spécifiez la distance entre deux mots. |
-| `:*` | `Prefix` | Utilisez le terme de recherche de préfixe pour trouver les mots dont le préfixe correspond (2 caractères requis.) |
+| Symbole    | Opérateur   | Description                                                                                                                                            |
+| ---------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`    | `And`       | Pour combiner plusieurs termes de recherche dans un filtre pour les entités incluant tous les termes fournis                                           |
+| &#x7c;     | `Or`        | Les requêtes comportant plusieurs termes de recherche séparés par l'opérateur ou renverront toutes les entités correspondant à l'un des termes fournis |
+| `<>` | `Follow by` | Spécifiez la distance entre deux mots.                                                                                                                 |
+| `:*`       | `Prefix`    | Utilisez le terme de recherche de préfixe pour trouver les mots dont le préfixe correspond (2 caractères requis.)                                      |
 
 #### Exemples
 

From 95f3de64c178ce06bc7e22841d83b6ae1cab298d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:23 -0500
Subject: [PATCH 0019/3820] New translations graphql-api.mdx (Russian)

---
 website/pages/ru/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ru/querying/graphql-api.mdx b/website/pages/ru/querying/graphql-api.mdx
index f539ff5637c4..2553a41b50ec 100644
--- a/website/pages/ru/querying/graphql-api.mdx
+++ b/website/pages/ru/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:**. Вы можете упростить приведенный выше запрос, удалив оператор `and`, передав подвыражение, разделенное запятыми.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ The result of such a query will not change over time, i.e., querying at a certai
 
 Полнотекстовые поисковые операторы:
 
-| Символ | Оператор | Описание |
-| --- | --- | --- |
-| `&` | `And` | Для объединения нескольких условий поиска в фильтр для объектов, которые включают все указанные условия |
-| &#x7c; | `Or` | Запросы с несколькими условиями поиска, разделенные оператором or, вернут все объекты, которые соответствуют любому из предоставленных условий |
-| `<->` | `Follow by` | Укажите расстояние между двумя словами. |
-| `:*` | `Prefix` | Используйте поисковый запрос по префиксу, чтобы найти слова с соответствующим префиксом (необходимо 2 символа) |
+| Символ      | Оператор    | Описание                                                                                                                                       |
+| ----------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`     | `And`       | Для объединения нескольких условий поиска в фильтр для объектов, которые включают все указанные условия                                        |
+| &#x7c;      | `Or`        | Запросы с несколькими условиями поиска, разделенные оператором or, вернут все объекты, которые соответствуют любому из предоставленных условий |
+| `<->` | `Follow by` | Укажите расстояние между двумя словами.                                                                                                        |
+| `:*`        | `Prefix`    | Используйте поисковый запрос по префиксу, чтобы найти слова с соответствующим префиксом (необходимо 2 символа)                                 |
 
 #### Примеры
 

From e21da4bab494e3877480d9c01aab1f6be7723af5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:26 -0500
Subject: [PATCH 0020/3820] New translations unit-testing-framework.mdx
 (Turkish)

---
 .../pages/tr/developing/unit-testing-framework.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/tr/developing/unit-testing-framework.mdx b/website/pages/tr/developing/unit-testing-framework.mdx
index 379ab4aaa125..85ebc99baaae 100644
--- a/website/pages/tr/developing/unit-testing-framework.mdx
+++ b/website/pages/tr/developing/unit-testing-framework.mdx
@@ -1114,7 +1114,7 @@ test('ethereum/sözleşme dataSource oluşturma örneği', () => {
   // 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A adresiyle yeni bir GraphTokenLockWallet veri kaynağı oluştur
   GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
 
-  // datSource oluşturulduğunu doğrula
+  // datSource oluşturulduğunu doğrula  
   assert.dataSourceCount('GraphTokenLockWallet', 1)
 
   // İkinci dataSource'u bağlamıyla ekle
@@ -1221,7 +1221,7 @@ export function handleMetadata(content: Bytes): void {
   // dataSource.stringParams() File Veri Kaynağı CID'sini döndürür
   // stringParam() işleyici testinde taklit edilecektir
   // daha fazla bilgi için https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
-  process - files
+process-files
   let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
   const value = json.fromBytes(content).toObject()
 
@@ -1381,15 +1381,15 @@ Tutulan kayıt çıktısı test çalışma süresini içerir. İşte buna bir ö
 Bu hata kodunuzda `console.log` kullandığınız anlamına gelir. Bu komut AssemblyScript tarafından desteklenmez. Lütfen [Logging API](/developing/graph-ts/api/#logging-api)'yi kullanmayı düşünün.
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 Argümanlardaki uyumsuzluk, `graph-ts` ve `matchstick-as` arasındaki uyumsuzluktan kaynaklanır. Bu gibi sorunları düzeltmenin en iyi yolu her şeyi en son yayınlanan sürüme güncellemektir.

From 4104516a6fdc04c52be7ff936b4290c630c718c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:30 -0500
Subject: [PATCH 0021/3820] New translations developer-faqs.mdx (Swedish)

---
 website/pages/sv/developing/developer-faqs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/developing/developer-faqs.mdx b/website/pages/sv/developing/developer-faqs.mdx
index e79a1bf808e1..907509ee9f9d 100644
--- a/website/pages/sv/developing/developer-faqs.mdx
+++ b/website/pages/sv/developing/developer-faqs.mdx
@@ -93,7 +93,7 @@ Du kan hitta listan över de stödda nätverken [här](/developing/supported-net
 Ja, du kan göra detta genom att importera `graph-ts` enligt exemplet nedan:
 
 ```javascript
-import { dataSource } from '@graphprotocol/graph-ts'
+import { dataSource } from "@graphprotocol/graph-ts"
 
 dataSource.network()
 dataSource.address()

From 315cac35af29d1f29030307c1c229314803668c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:34 -0500
Subject: [PATCH 0022/3820] New translations unit-testing-framework.mdx
 (Romanian)

---
 website/pages/ro/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ro/developing/unit-testing-framework.mdx b/website/pages/ro/developing/unit-testing-framework.mdx
index 553eec2157b3..53a5c43dedcf 100644
--- a/website/pages/ro/developing/unit-testing-framework.mdx
+++ b/website/pages/ro/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ The log output includes the test run duration. Here's an example:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.

From 1728bfc32b2e83cde2cb8939fd45b9aab53bcd68 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:35 -0500
Subject: [PATCH 0023/3820] New translations graphql-api.mdx (Romanian)

---
 website/pages/ro/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ro/querying/graphql-api.mdx b/website/pages/ro/querying/graphql-api.mdx
index 3dd70fc7b004..d8671e53a77c 100644
--- a/website/pages/ro/querying/graphql-api.mdx
+++ b/website/pages/ro/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 Fulltext search operators:
 
-| Symbol | Operator | Description |
-| --- | --- | --- |
-| `&` | `And` | For combining multiple search terms into a filter for entities that include all of the provided terms |
-| &#x7c; | `Or` | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
-| `<->` | `Follow by` | Specify the distance between two words. |
-| `:*` | `Prefix` | Use the prefix search term to find words whose prefix match (2 characters required.) |
+| Symbol      | Operator    | Description                                                                                                                          |
+| ----------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| &#x7c;      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->` | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`        | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 
 #### Examples
 

From 4a25bb0b113c4b0654c4362724adb27119528bea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:37 -0500
Subject: [PATCH 0024/3820] New translations api.mdx (Romanian)

---
 website/pages/ro/developing/graph-ts/api.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/ro/developing/graph-ts/api.mdx b/website/pages/ro/developing/graph-ts/api.mdx
index 6a0c4e208b99..8fc1f4b48b61 100644
--- a/website/pages/ro/developing/graph-ts/api.mdx
+++ b/website/pages/ro/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| Version | Release notes |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| Version | Release notes                                                                                                                                                                                                                                 |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### Built-in Types
 

From aceb0813f157d159206fbdf2688064d8f582422d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:40 -0500
Subject: [PATCH 0025/3820] New translations install-the-cli.mdx (Romanian)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/ro/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/ro/developing/creating-a-subgraph/install-the-cli.mdx
index 20748328de9e..7da774ac392c 100644
--- a/website/pages/ro/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/ro/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The ABI file(s) must match your contract(s). There are a few ways to obtain ABI
 
 ## SpecVersion Releases
 
-| Version | Release notes |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From ff27a23a0c2cc3c67d7067c0c246766cef118dc2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:41 -0500
Subject: [PATCH 0026/3820] New translations ql-schema.mdx (Romanian)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/ro/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/ro/developing/creating-a-subgraph/ql-schema.mdx
index 90036d1bfab9..3df39853f82b 100644
--- a/website/pages/ro/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/ro/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Type | Description |
-| --- | --- |
-| `Bytes` | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 

From a502297a92916c1801a8b3fc315b44276b358afd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:44 -0500
Subject: [PATCH 0027/3820] New translations near.mdx (French)

---
 website/pages/fr/cookbook/near.mdx | 50 +++++++++++++++---------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/website/pages/fr/cookbook/near.mdx b/website/pages/fr/cookbook/near.mdx
index cb3ed047e136..e922801be61e 100644
--- a/website/pages/fr/cookbook/near.mdx
+++ b/website/pages/fr/cookbook/near.mdx
@@ -51,23 +51,23 @@ $ graph build # génère le Web Assembly à partir des fichiers AssemblyScript,
 Le manifeste de subgraph (`subgraph.yaml`) identifie les sources de données pour le subgraph, les déclencheurs d'intérêt et les fonctions qui doivent être exécutées en réponse à ces déclencheurs. Voici un exemple de manifeste de subgraph pour un subgraph NEAR:
 
 ```yaml
-specVersion: 0.0.2
-schema:
-  file: ./src/schema.graphql # lien vers le fichier de schéma
-dataSources:
-  - kind: near
-    network: near-mainnet
-    source:
-      account: app.good-morning.near # Cette source de données surveillera ce compte
-      startBlock: 10662188 # Requis pour NEAR
-    mapping:
-      apiVersion: 0.0.5
-      language: wasm/assemblyscript
-      blockHandlers:
-        - handler: handleNewBlock # le nom de la fonction dans le fichier de mapping
-      receiptHandlers:
-        - handler: handleReceipt # le nom de la fonction dans le fichier de mappage
-      file: ./src/mapping.ts # lien vers le fichier contenant les mappings Assemblyscript
+specVersion : 0.0.2
+schema :
+  file : ./src/schema.graphql # lien vers le fichier de schéma
+dataSources :
+  - kind : near
+    network : near-mainnet
+    source :
+      account : app.good-morning.near # Cette source de données surveillera ce compte
+      startBlock : 10662188 # Requis pour NEAR
+    mapping :
+      apiVersion : 0.0.5
+      language : wasm/assemblyscript
+      blockHandlers :
+        - handler : handleNewBlock # le nom de la fonction dans le fichier de mapping
+      receiptHandlers :
+        - handler : handleReceipt # le nom de la fonction dans le fichier de mappage
+      file : ./src/mapping.ts # lien vers le fichier contenant les mappings Assemblyscript
 ```
 
 - Les subgraphs NEAR introduisent un nouveau `type` de source de données (`near`)
@@ -77,12 +77,12 @@ dataSources:
 
 ```yaml
 comptes:
-  préfixes:
-    - application
-    - bien
-  suffixes:
-    - matin.près
-    - matin.testnet
+   préfixes :
+     - application
+     - bien
+   suffixes :
+     - matin.près
+     - matin.testnet
 ```
 
 Les fichiers de données NEAR prennent en charge deux types de gestionnaires :
@@ -258,8 +258,8 @@ Si un `compte` est spécifié, il correspondra uniquement au nom exact du compte
 
 ```yaml
 comptes:
-  suffixes:
-    - mintbase1.near
+   suffixes :
+     - mintbase1.near
 ```
 
 ### Les subgraphs NEAR peuvent-ils faire des appels de view aux comptes NEAR pendant les mappings?

From 4e720ba123e63a7aca8b0530717b41887b3c1c93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:46 -0500
Subject: [PATCH 0028/3820] New translations unit-testing-framework.mdx
 (French)

---
 .../fr/developing/unit-testing-framework.mdx  | 23 +++++++++----------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/website/pages/fr/developing/unit-testing-framework.mdx b/website/pages/fr/developing/unit-testing-framework.mdx
index b3c5e2dde822..90f2adcae121 100644
--- a/website/pages/fr/developing/unit-testing-framework.mdx
+++ b/website/pages/fr/developing/unit-testing-framework.mdx
@@ -950,7 +950,7 @@ Les utilisateurs peuvent également simuler une panne critique, comme ceci :
 
 ```typescript
 test('Tout faire exploser', () => {
-  log.critical('Boom!')
+   log.critical('Boom!')
 })
 ```
 
@@ -1107,7 +1107,7 @@ Depuis la version `0.6.0`, il est possible de tester si une nouvelle source de d
 #### Test des modèles `ethereum/contract`
 
 ```typescript
-test('ethereum/contract dataSource creation example', () => {
+test('ethereum/contract dataSource creation example', () =>  {
   // affirme qu'aucune source de données n'est créée à partir du modèle GraphTokenLockWallet
   assert.dataSourceCount('GraphTokenLockWallet', 0)
   // Crée une nouvelle source de données GraphTokenLockWallet avec l'adresse 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
@@ -1157,8 +1157,7 @@ De même que les sources de données dynamiques de contrat, les utilisateurs peu
 ##### Exemple `subgraph.yaml`
 
 ```yaml
-
----
+...
 templates:
   - kind: file/ipfs
     name: GraphTokenLockMetadata
@@ -1221,7 +1220,7 @@ export function handleMetadata(content: Bytes): void {
     const endTime = value.get('endTime')
     const periods = value.get('periods')
     const releaseStartTime = value.get('releaseStartTime')
-    if (startTime && endTime && periods && releaseStartTime) {
+   if (startTime && endTime && periods && releaseStartTime) {
       tokenMetadata.startTime = startTime.toBigInt()
       tokenMetadata.endTime = endTime.toBigInt()
       tokenMetadata.periods = periods.toBigInt()
@@ -1241,7 +1240,7 @@ import { handleMetadata } from '../../src/token-lock-wallet'
 import { TokenLockMetadata } from '../../generated/schema'
 import { GraphTokenLockMetadata } from '../../generated/templates'
 
-test('exemple de création de source de données file/ipfs', () => {
+test('exemple de création de source de données file/ipfs', () =>  {
   // Générer le CID de la source de données à partir du ipfsHash + chemin du fichier du ipfs
   // Par exemple QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
   const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
@@ -1368,20 +1367,20 @@ La sortie du journal inclut la durée de l’exécution du test. Voici un exempl
 Ceci signifie que vous avez utilisé `console.log` dans votre code, ce qui n'est pas pris en charge par AssemblyScript. Veuillez envisager d'utiliser l'[API de journalisation](/developing/graph-ts/api/#logging-api)
 
 > ERREUR TS2554 : attendu ? arguments, mais j'ai eu ?.
->
+> 
 > renvoyer le nouveau ethereum.Block (defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt) ;
->
+> 
 > dans ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > renvoyer un nouveau ethereum.Transaction (defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt) ;
->
+> 
 > dans ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 L'inadéquation des arguments est causée par une inadéquation entre `graph-ts` et `matchstick-as`. La meilleure façon de résoudre des problèmes comme celui-ci est de tout mettre à jour vers la dernière version publiée.
 
-## Ressources additionnelles
+## Ressources complémentaires
 
 For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
 

From 97ebad7efabe29a992da6c0f82f8f75bc5749512 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:47 -0500
Subject: [PATCH 0029/3820] New translations api.mdx (French)

---
 website/pages/fr/developing/graph-ts/api.mdx | 96 ++++++++++----------
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/website/pages/fr/developing/graph-ts/api.mdx b/website/pages/fr/developing/graph-ts/api.mdx
index 3587758f3f64..1fecf7dd1dd4 100644
--- a/website/pages/fr/developing/graph-ts/api.mdx
+++ b/website/pages/fr/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ La bibliothèque `@graphprotocol/graph-ts` fournit les API suivantes :
 
 La `apiVersion` dans le manifeste du subgraph spécifie la version de l'API de mappage exécutée par Graph Node pour un subgraph donné.
 
-| Version | Notes de version |
-| :-: | --- |
-| 0.0.9 | Ajout de nouvelles fonctions hôtes [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Ajout de la validation pour l'existence des champs dans le schéma lors de l'enregistrement d'une entité. |
-| 0.0.7 | Ajout des classes `TransactionReceipt` et `Log`aux types Ethereum<br />Ajout du champ `receipt` à l'objet Ethereum Event |
-| 0.0.6 | Ajout du champ `nonce` à l'objet Ethereum Transaction<br />Ajout de `baseFeePerGas` à l'objet Ethereum Block |
-| 0.0.5 | AssemblyScript a été mis à niveau vers la version 0.19.10 (ceci inclut des changements importants, veuillez consulter le [`Guide de Migration`](/release-notes/assemblyscript-migration-guide))<br />. `ethereum.transaction.gasUsed` est renommé en `ethereum.transaction.gasLimit` |
-| 0.0.4 | Ajout du champ `functionSignature` à l'objet Ethereum SmartContractCall |
-| 0.0.3 | Ajout du champ `from` à l'objet Ethereum Call<br />`etherem.call.address` est renommé en `ethereum.call.to` |
-| 0.0.2 | Ajout du champ `input` à l'objet Ethereum Transaction |
+| Version | Notes de version                                                                                                                                                                                                                                                                     |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  0.0.9  | Ajout de nouvelles fonctions hôtes [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                                              |
+|  0.0.8  | Ajout de la validation pour l'existence des champs dans le schéma lors de l'enregistrement d'une entité.                                                                                                                                                                             |
+|  0.0.7  | Ajout des classes `TransactionReceipt` et `Log`aux types Ethereum<br />Ajout du champ `receipt` à l'objet Ethereum Event                                                                                                                                                             |
+|  0.0.6  | Ajout du champ `nonce` à l'objet Ethereum Transaction<br />Ajout de `baseFeePerGas` à l'objet Ethereum Block                                                                                                                                                                         |
+|  0.0.5  | AssemblyScript a été mis à niveau vers la version 0.19.10 (ceci inclut des changements importants, veuillez consulter le [`Guide de Migration`](/release-notes/assemblyscript-migration-guide))<br />. `ethereum.transaction.gasUsed` est renommé en `ethereum.transaction.gasLimit` |
+|  0.0.4  | Ajout du champ `functionSignature` à l'objet Ethereum SmartContractCall                                                                                                                                                                                                              |
+|  0.0.3  | Ajout du champ `from` à l'objet Ethereum Call<br />`etherem.call.address` est renommé en `ethereum.call.to`                                                                                                                                                                          |
+|  0.0.2  | Ajout du champ `input` à l'objet Ethereum Transaction                                                                                                                                                                                                                                |
 
 ### Types intégrés
 
@@ -770,44 +770,44 @@ Lorsque le type d'une valeur est certain, il peut être converti en un [type int
 
 ### Référence des conversions de types
 
-| Source(s)            | Destination          | Fonctions de conversion      |
-| -------------------- | -------------------- | ---------------------------- |
-| Address              | Bytes                | aucune                       |
-| Address              | String               | s.toHexString()              |
-| BigDecimal           | String               | s.toString()                 |
-| BigInt               | BigDecimal           | s.toBigDecimal()             |
-| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
-| BigInt               | String (unicode)     | s.toString()                 |
-| BigInt               | i32                  | s.toI32()                    |
-| Boolean              | Boolean              | aucune                       |
-| Bytes (signé)        | BigInt               | BigInt.fromSignedBytes(s)    |
-| Bytes (non signé)    | BigInt               | BigInt.fromUnsignedBytes(s)  |
-| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
-| Bytes                | String (unicode)     | s.toString()                 |
-| Bytes                | String (base58)      | s.toBase58()                 |
-| Bytes                | i32                  | s.toI32()                    |
-| Bytes                | u32                  | s.toU32()                    |
-| Bytes                | JSON                 | json.fromBytes(s)            |
-| int8                 | i32                  | aucune                       |
-| int32                | i32                  | aucune                       |
-| int32                | BigInt               | BigInt.fromI32(s)            |
-| uint24               | i32                  | aucune                       |
-| int64 - int256       | BigInt               | aucune                       |
-| uint32 - uint256     | BigInt               | aucune                       |
-| JSON                 | boolean              | s.toBool()                   |
-| JSON                 | i64                  | s.toI64()                    |
-| JSON                 | u64                  | s.toU64()                    |
-| JSON                 | f64                  | s.toF64()                    |
-| JSON                 | BigInt               | s.toBigInt()                 |
-| JSON                 | string               | s.toString()                 |
-| JSON                 | Array                | s.toArray()                  |
-| JSON                 | Object               | s.toObject()                 |
-| String               | Address              | Address.fromString(s)        |
-| Bytes                | Address              | Address.fromBytes(s)         |
-| String               | BigInt               | BigInt.fromString(s)         |
-| String               | BigDecimal           | BigDecimal.fromString(s)     |
-| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
-| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+| Source(s)             | Destination          | Fonctions de conversion          |
+| --------------------- | -------------------- | -------------------------------- |
+| Address               | Bytes                | aucune                           |
+| Address               | String               | s.toHexString()                  |
+| BigDecimal            | String               | s.toString()                     |
+| BigInt                | BigDecimal           | s.toBigDecimal()                 |
+| BigInt                | String (hexadecimal) | s.toHexString() or s.toHex()     |
+| BigInt                | String (unicode)     | s.toString()                     |
+| BigInt                | i32                  | s.toI32()                        |
+| Boolean               | Boolean              | aucune                           |
+| Bytes (signé)         | BigInt               | BigInt.fromSignedBytes(s)        |
+| Bytes (non signé)     | BigInt               | BigInt.fromUnsignedBytes(s)      |
+| Bytes                 | String (hexadecimal) | s.toHexString() or s.toHex()     |
+| Bytes                 | String (unicode)     | s.toString()                     |
+| Bytes                 | String (base58)      | s.toBase58()                     |
+| Bytes                 | i32                  | s.toI32()                        |
+| Bytes                 | u32                  | s.toU32()                        |
+| Bytes                 | JSON                 | json.fromBytes(s)                |
+| int8                  | i32                  | aucune                           |
+| int32                 | i32                  | aucune                           |
+| int32                 | BigInt               | BigInt.fromI32(s)                |
+| uint24                | i32                  | aucune                           |
+| int64 - int256        | BigInt               | aucune                           |
+| uint32 - uint256      | BigInt               | aucune                           |
+| JSON                  | boolean              | s.toBool()                       |
+| JSON                  | i64                  | s.toI64()                        |
+| JSON                  | u64                  | s.toU64()                        |
+| JSON                  | f64                  | s.toF64()                        |
+| JSON                  | BigInt               | s.toBigInt()                     |
+| JSON                  | string               | s.toString()                     |
+| JSON                  | Array                | s.toArray()                      |
+| JSON                  | Object               | s.toObject()                     |
+| String                | Address              | Address.fromString(s)            |
+| Bytes                 | Address              | Address.fromBytes(s)             |
+| String                | BigInt               | BigInt.fromString(s)             |
+| String                | BigDecimal           | BigDecimal.fromString(s)         |
+| String (hexadecimal)  | Bytes                | ByteArray.fromHexString(s)       |
+| String (UTF-8)        | Bytes                | ByteArray.fromUTF8(s)            |
 
 ### Métadonnées de la source de données
 

From 324290f8c4992abfd7537bd867c676dae42f5dba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:48 -0500
Subject: [PATCH 0030/3820] New translations transfer-to-the-graph.mdx (French)

---
 website/pages/fr/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/cookbook/transfer-to-the-graph.mdx b/website/pages/fr/cookbook/transfer-to-the-graph.mdx
index 3ffe317f8063..7b92f88f7ad3 100644
--- a/website/pages/fr/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/fr/cookbook/transfer-to-the-graph.mdx
@@ -98,7 +98,7 @@ You can create API Keys in Subgraph Studio under the “API Keys” menu at the
 
 Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
 
-### Ressources additionnelles
+### Ressources complémentaires
 
 - To quickly create and publish a new subgraph, check out the [Quick Start](/quick-start/).
 - To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 59ee7ee9cbe5c83de73fa4fb6df6504d54ff27d9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:49 -0500
Subject: [PATCH 0031/3820] New translations advanced.mdx (French)

---
 website/pages/fr/developing/creating-a-subgraph/advanced.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/developing/creating-a-subgraph/advanced.mdx b/website/pages/fr/developing/creating-a-subgraph/advanced.mdx
index 9788771e2158..7416cd495bcf 100644
--- a/website/pages/fr/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/fr/developing/creating-a-subgraph/advanced.mdx
@@ -284,7 +284,7 @@ import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
 const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
 //Cet exemple de code concerne un sous-graphe de Crypto coven. Le hachage ipfs ci-dessus est un répertoire contenant les métadonnées des jetons pour toutes les NFT de l'alliance cryptographique.
 
-export function handleTransfer(event: TransferEvent): void {
+export function handleTransfer(event : TransferEvent) : void {
   let token = Token.load(event.params.tokenId.toString())
   if (!token) {
     token = new Token(event.params.tokenId.toString())

From a3fb6a6006b2e0620a66f36a60507a9aba088425 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:51 -0500
Subject: [PATCH 0032/3820] New translations install-the-cli.mdx (French)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/fr/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/fr/developing/creating-a-subgraph/install-the-cli.mdx
index d5f137f2260f..4d94d22392b3 100644
--- a/website/pages/fr/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/fr/developing/creating-a-subgraph/install-the-cli.mdx
@@ -25,7 +25,7 @@ npm install -g @graphprotocol/graph-cli@latest
 #### Using [yarn](https://yarnpkg.com/)
 
 ```bash
-npm install -g @graphprotocol/graph-cli
+yarn global add @graphprotocol/graph-cli
 ```
 
 The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
@@ -106,14 +106,14 @@ Le(s) fichier(s) ABI doivent correspondre à votre(vos) contrat(s). Il existe pl
 
 ## Versions disponibles de SpecVersion
 
-| Version | Notes de version |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Ajout de la prise en charge des gestionnaires d'événement ayant accès aux reçus de transactions. |
-| 0.0.4 | Ajout de la prise en charge du management des fonctionnalités de subgraph. |
+| Version | Notes de version                                                                                                                                                         |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Ajout de la prise en charge des gestionnaires d'événement ayant accès aux reçus de transactions.                                                                         |
+|  0.0.4  | Ajout de la prise en charge du management des fonctionnalités de subgraph.                                                                                               |

From 30db6114307df1919250f59dc8fb3c5e97888edc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:52 -0500
Subject: [PATCH 0033/3820] New translations ql-schema.mdx (French)

---
 .../creating-a-subgraph/ql-schema.mdx         | 30 +++++++++----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/fr/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/fr/developing/creating-a-subgraph/ql-schema.mdx
index b0c91ff4665f..cbf7c64078a3 100644
--- a/website/pages/fr/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/fr/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 Les scalaires suivants sont supportés dans l'API GraphQL :
 
-| Type | Description |
-| --- | --- |
-| `Bytes` | Tableau d'octets, représenté sous forme de chaîne hexadécimale. Couramment utilisé pour les hachages et adresses Ethereum. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Tableau d'octets, représenté sous forme de chaîne hexadécimale. Couramment utilisé pour les hachages et adresses Ethereum.                                                                                       |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 
@@ -210,7 +210,7 @@ Cette approche nécessite que les requêtes descendent vers un niveau supplémen
 query usersWithOrganizations {
   users {
     organizations {
-      # ceci est une entité UserOrganization
+       # ceci est une entité UserOrganization
       organization {
         name
       }
@@ -306,7 +306,7 @@ Dictionnaires de langues pris en charge :
 
 Algorithmes de classement:
 
-| Algorithm | Description |
-| --- | --- |
-| rank | Utilisez la qualité de correspondance (0-1) de la requête en texte intégral pour trier les résultats. |
-| proximitéRang | Similar to rank but also includes the proximity of the matches. |
+| Algorithm     | Description                                                                                           |
+| ------------- | ----------------------------------------------------------------------------------------------------- |
+| rank          | Utilisez la qualité de correspondance (0-1) de la requête en texte intégral pour trier les résultats. |
+| proximitéRang | Similar to rank but also includes the proximity of the matches.                                       |

From 8cd0b9c39b66c18953999822b4cbb08138921ece Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:55:56 -0500
Subject: [PATCH 0034/3820] New translations unit-testing-framework.mdx
 (Spanish)

---
 website/pages/es/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/es/developing/unit-testing-framework.mdx b/website/pages/es/developing/unit-testing-framework.mdx
index 63f6babad3d9..68c3ff849637 100644
--- a/website/pages/es/developing/unit-testing-framework.mdx
+++ b/website/pages/es/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ La salida del log incluye la duración de la ejecución de la prueba. Aquí hay
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 La falta de coincidencia en los argumentos se debe a la falta de coincidencia en `graph-ts` y `matchstick-as`. La mejor manera de solucionar problemas como este es actualizar todo a la última versión publicada.

From d494c813ea6b9fb9b4dae111af5c570b31360277 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:11 -0500
Subject: [PATCH 0035/3820] New translations graphql-api.mdx (Spanish)

---
 website/pages/es/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/es/querying/graphql-api.mdx b/website/pages/es/querying/graphql-api.mdx
index 0817a89f807e..e0281d0b1bdc 100644
--- a/website/pages/es/querying/graphql-api.mdx
+++ b/website/pages/es/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Azúcar sintáctico**: Puedes simplificar la consulta anterior eliminando el operador `and` pasando una subexpresión separada por comas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Las consultas de búsqueda de texto completo tienen un campo obligatorio, `text`
 
 Operadores de búsqueda de texto completo:
 
-| Símbolo | Operador | Descripción |
-| --- | --- | --- |
-| `&` | `And` | Para combinar varios términos de búsqueda en un filtro para entidades que incluyen todos los términos proporcionados |
-| &#x7c; | `O` | Las consultas con varios términos de búsqueda separados por o el operador devolverá todas las entidades que coincidan con cualquiera de los términos proporcionados |
-| `<->` | `Follow by` | Especifica la distancia entre dos palabras. |
-| `:*` | `Prefijo` | Utilice el término de búsqueda del prefijo para encontrar palabras cuyo prefijo coincida (se requieren 2 caracteres.) |
+| Símbolo     | Operador    | Descripción                                                                                                                                                         |
+| ----------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`     | `And`       | Para combinar varios términos de búsqueda en un filtro para entidades que incluyen todos los términos proporcionados                                                |
+| &#x7c;      | `O`         | Las consultas con varios términos de búsqueda separados por o el operador devolverá todas las entidades que coincidan con cualquiera de los términos proporcionados |
+| `<->` | `Follow by` | Especifica la distancia entre dos palabras.                                                                                                                         |
+| `:*`        | `Prefijo`   | Utilice el término de búsqueda del prefijo para encontrar palabras cuyo prefijo coincida (se requieren 2 caracteres.)                                               |
 
 #### Ejemplos
 

From 52d7c5c7a076fde77814b1c071b338d1efbb1588 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:12 -0500
Subject: [PATCH 0036/3820] New translations api.mdx (Spanish)

---
 website/pages/es/developing/graph-ts/api.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/es/developing/graph-ts/api.mdx b/website/pages/es/developing/graph-ts/api.mdx
index 5399f3838722..6660507ae768 100644
--- a/website/pages/es/developing/graph-ts/api.mdx
+++ b/website/pages/es/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| Version | Notas del lanzamiento |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| Version | Notas del lanzamiento                                                                                                                                                                                                                         |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### Tipos Incorporados
 

From 25bcfcbbf958edf7f17966138ac624f49e898f44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:16 -0500
Subject: [PATCH 0037/3820] New translations install-the-cli.mdx (Spanish)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/es/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/es/developing/creating-a-subgraph/install-the-cli.mdx
index b70948811960..9a754fb67035 100644
--- a/website/pages/es/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/es/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ Los archivos ABI deben coincidir con tu(s) contrato(s). Hay varias formas de obt
 
 ## SpecVersion Releases
 
-| Version | Notas del lanzamiento |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| Version | Notas del lanzamiento                                                                                                                                                    |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 31b4be68c9d6f219ef862069f5a05af71a0b2c93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:17 -0500
Subject: [PATCH 0038/3820] New translations ql-schema.mdx (Spanish)

---
 .../creating-a-subgraph/ql-schema.mdx         | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/es/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/es/developing/creating-a-subgraph/ql-schema.mdx
index 4ecbc03b60a8..168d008294ed 100644
--- a/website/pages/es/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/es/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Tipo | Descripción |
-| --- | --- |
-| `Bytes` | Byte array, representado como un string hexadecimal. Comúnmente utilizado para los hashes y direcciones de Ethereum. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Tipo         | Descripción                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, representado como un string hexadecimal. Comúnmente utilizado para los hashes y direcciones de Ethereum.                                                                                             |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 
@@ -306,7 +306,7 @@ Diccionarios de idiomas admitidos:
 
 Algoritmos admitidos para ordenar los resultados:
 
-| Algorithm | Description |
-| --- | --- |
-| rank | Usa la calidad de coincidencia (0-1) de la consulta de texto completo para ordenar los resultados. |
-| rango de proximidad | Similar to rank but also includes the proximity of the matches. |
+| Algorithm           | Description                                                                                        |
+| ------------------- | -------------------------------------------------------------------------------------------------- |
+| rank                | Usa la calidad de coincidencia (0-1) de la consulta de texto completo para ordenar los resultados. |
+| rango de proximidad | Similar to rank but also includes the proximity of the matches.                                    |

From 16e29708f7a2f48da8531f9723d5761f6a6ae7aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:20 -0500
Subject: [PATCH 0039/3820] New translations near.mdx (Arabic)

---
 website/pages/ar/cookbook/near.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ar/cookbook/near.mdx b/website/pages/ar/cookbook/near.mdx
index b2f9eaf75feb..73428b6f6fd5 100644
--- a/website/pages/ar/cookbook/near.mdx
+++ b/website/pages/ar/cookbook/near.mdx
@@ -27,13 +27,13 @@ title: بناء Subgraphs على NEAR
 
 `graphprotocol/graph-ts@` هي مكتبة لأنواع خاصة بـ subgraph.
 
-تطوير NEAR subgraph يتطلب `graph-cli` بإصدار أعلى من `0.23.0` و `graph-ts` بإصدار أعلى من `0.23.0`.
+تطوير NEAR subgraph يتطلب `graph-cli` بإصدار أعلى من ` 0.23.0 ` و `graph-ts` بإصدار أعلى من ` 0.23.0 `.
 
 > Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
 
 هناك ثلاثة جوانب لتعريف الـ subgraph:
 
-**subgraph.yaml:** الـ subgraph manifest ، وتحديد مصادر البيانات ذات الأهمية ، وكيف يجب أن تتم معالجتها.علما أن NEAR هو `نوع` جديد لمصدر البيانات.
+**subgraph.yaml:** الـ subgraph manifest ، وتحديد مصادر البيانات ذات الأهمية ، وكيف يجب أن تتم معالجتها.علما أن NEAR هو ` نوع ` جديد لمصدر البيانات.
 
 **schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph#the-graphql-schema).
 
@@ -163,7 +163,7 @@ class ReceiptWithOutcome {
 These types are passed to block & receipt handlers:
 
 - معالجات الكتلة ستتلقى`Block`
-- معالجات الاستلام ستتلقى`ReceiptWithOutcome`
+- معالجات الاستلام ستتلقى` ReceiptWithOutcome `
 
 Otherwise, the rest of the [AssemblyScript API](/developing/graph-ts/api) is available to NEAR subgraph developers during mapping execution.
 

From d1625f4e8c55e700f835be7ce3f21c8302ffcaa7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:22 -0500
Subject: [PATCH 0040/3820] New translations unit-testing-framework.mdx
 (Arabic)

---
 website/pages/ar/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ar/developing/unit-testing-framework.mdx b/website/pages/ar/developing/unit-testing-framework.mdx
index d123dc0f994b..67c565e95df8 100644
--- a/website/pages/ar/developing/unit-testing-framework.mdx
+++ b/website/pages/ar/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ The log output includes the test run duration. Here's an example:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.

From 540ec4837da3b3f5b4b5157949ccf16212fc2444 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:23 -0500
Subject: [PATCH 0041/3820] New translations graphql-api.mdx (Arabic)

---
 website/pages/ar/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ar/querying/graphql-api.mdx b/website/pages/ar/querying/graphql-api.mdx
index 9699c231d93b..258471c1d9d4 100644
--- a/website/pages/ar/querying/graphql-api.mdx
+++ b/website/pages/ar/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 Fulltext search operators:
 
-| رمز | عامل التشغيل | الوصف |
-| --- | --- | --- |
-| `&` | `And` | لدمج عبارات بحث متعددة في فلتر للكيانات التي تتضمن جميع العبارات المتوفرة |
-| &#x7c; | `أو` | الاستعلامات التي تحتوي على عبارات بحث متعددة مفصولة بواسطة عامل التشغيل or ستعيد جميع الكيانات المتطابقة من أي عبارة متوفرة |
-| `<->` | `Follow by` | يحدد المسافة بين كلمتين. |
-| `:*` | `Prefix` | يستخدم عبارة البحث prefix للعثور على الكلمات التي تتطابق بادئتها (مطلوب حرفان.) |
+| رمز         | عامل التشغيل | الوصف                                                                                                                       |
+| ----------- | ------------ | --------------------------------------------------------------------------------------------------------------------------- |
+| `&`     | `And`        | لدمج عبارات بحث متعددة في فلتر للكيانات التي تتضمن جميع العبارات المتوفرة                                                   |
+| &#x7c;      | `أو`         | الاستعلامات التي تحتوي على عبارات بحث متعددة مفصولة بواسطة عامل التشغيل or ستعيد جميع الكيانات المتطابقة من أي عبارة متوفرة |
+| `<->` | `Follow by`  | يحدد المسافة بين كلمتين.                                                                                                    |
+| `:*`        | `Prefix`     | يستخدم عبارة البحث prefix للعثور على الكلمات التي تتطابق بادئتها (مطلوب حرفان.)                                             |
 
 #### Examples
 

From 39dbfe7f72fd8a9db5cb355e5a40df5dc178a953 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:24 -0500
Subject: [PATCH 0042/3820] New translations api.mdx (Arabic)

---
 website/pages/ar/developing/graph-ts/api.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/ar/developing/graph-ts/api.mdx b/website/pages/ar/developing/graph-ts/api.mdx
index 2de72189db87..544f2118f489 100644
--- a/website/pages/ar/developing/graph-ts/api.mdx
+++ b/website/pages/ar/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| الاصدار | ملاحظات الإصدار |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| الاصدار | ملاحظات الإصدار                                                                                                                                                                                                                               |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### الأنواع المضمنة (Built-in)
 

From 9df0cf225cf8eb15314556b75d37bf9f15f0f013 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:28 -0500
Subject: [PATCH 0043/3820] New translations install-the-cli.mdx (Arabic)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/ar/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/ar/developing/creating-a-subgraph/install-the-cli.mdx
index b18e9aa8f7fb..4aa9caae2a28 100644
--- a/website/pages/ar/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/ar/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is
 
 ## SpecVersion Releases
 
-| الاصدار | ملاحظات الإصدار |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| الاصدار | ملاحظات الإصدار                                                                                                                                                          |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From ebac047d211f65c7d82b7579e6277df2d0ffb591 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:30 -0500
Subject: [PATCH 0044/3820] New translations ql-schema.mdx (Arabic)

---
 .../creating-a-subgraph/ql-schema.mdx         | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/ar/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/ar/developing/creating-a-subgraph/ql-schema.mdx
index 20b4acef827a..b66db45260f0 100644
--- a/website/pages/ar/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/ar/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| النوع | الوصف |
-| --- | --- |
-| `Bytes` | مصفوفة Byte ، ممثلة كسلسلة سداسية عشرية. يشيع استخدامها في Ethereum hashes وعناوينه. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| النوع        | الوصف                                                                                                                                                                                                            |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | مصفوفة Byte ، ممثلة كسلسلة سداسية عشرية. يشيع استخدامها في Ethereum hashes وعناوينه.                                                                                                                             |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 
@@ -306,7 +306,7 @@ Supported language dictionaries:
 
 Supported algorithms for ordering results:
 
-| Algorithm     | Description                                                     |
-| ------------- | --------------------------------------------------------------- |
-| rank          | استخدم جودة مطابقة استعلام النص-الكامل (0-1) لترتيب النتائج.    |
-| proximityRank | Similar to rank but also includes the proximity of the matches. |
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | استخدم جودة مطابقة استعلام النص-الكامل (0-1) لترتيب النتائج.            |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From 926ec775bf8477230f3e4a29db7052010d38b8b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:34 -0500
Subject: [PATCH 0045/3820] New translations unit-testing-framework.mdx (Czech)

---
 website/pages/cs/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/cs/developing/unit-testing-framework.mdx b/website/pages/cs/developing/unit-testing-framework.mdx
index ef2cdd645f76..066874060887 100644
--- a/website/pages/cs/developing/unit-testing-framework.mdx
+++ b/website/pages/cs/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ Výstup protokolu obsahuje dobu trvání test. Zde je příklad:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 Neshoda v argumentech je způsobena neshodou v `graph-ts` a `matchstick-as`. Nejlepší způsob, jak opravit problémy, jako je tento, je aktualizovat vše na nejnovější vydanou verzi.

From 8aca9fcbae4b51206684d12db773fee38e16e293 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:35 -0500
Subject: [PATCH 0046/3820] New translations graphql-api.mdx (Czech)

---
 website/pages/cs/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/cs/querying/graphql-api.mdx b/website/pages/cs/querying/graphql-api.mdx
index 194d477a23c1..16b65fe32b1e 100644
--- a/website/pages/cs/querying/graphql-api.mdx
+++ b/website/pages/cs/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntaktický cukr:** Výše uvedený dotaz můžete zjednodušit odstraněním operátoru `a` předáním podvýrazu odděleného čárkami.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltextové vyhledávací dotazy mají jedno povinné pole `text` pro zadání
 
 Operátory fulltextového vyhledávání:
 
-| Symbol | Operátor | Popis |
-| --- | --- | --- |
-| `&` | `a` | Pro kombinaci více vyhledávacích výrazů do filtru pro entity, které obsahují všechny zadané výrazy |
-| &#x7c; | `Nebo` | Dotazy s více hledanými výrazy oddělenými operátorem nebo vrátí všechny entity, které odpovídají některému z uvedených výrazů |
-| `<->` | `Follow by` | Zadejte vzdálenost mezi dvěma slovy. |
-| `:*` | `Prefix` | Pomocí předponového výrazu vyhledejte slova, jejichž předpona se shoduje (vyžadovány 2 znaky) |
+| Symbol      | Operátor    | Popis                                                                                                                         |
+| ----------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------- |
+| `&`     | `a`         | Pro kombinaci více vyhledávacích výrazů do filtru pro entity, které obsahují všechny zadané výrazy                            |
+| &#x7c;      | `Nebo`      | Dotazy s více hledanými výrazy oddělenými operátorem nebo vrátí všechny entity, které odpovídají některému z uvedených výrazů |
+| `<->` | `Follow by` | Zadejte vzdálenost mezi dvěma slovy.                                                                                          |
+| `:*`        | `Prefix`    | Pomocí předponového výrazu vyhledejte slova, jejichž předpona se shoduje (vyžadovány 2 znaky)                                 |
 
 #### Příklady
 

From 15df8f0a70abbaa9558cb2ce25cadf7503e7e06b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:36 -0500
Subject: [PATCH 0047/3820] New translations api.mdx (Czech)

---
 website/pages/cs/developing/graph-ts/api.mdx | 234 +++++++++----------
 1 file changed, 117 insertions(+), 117 deletions(-)

diff --git a/website/pages/cs/developing/graph-ts/api.mdx b/website/pages/cs/developing/graph-ts/api.mdx
index d8c0004d37ef..ad84f9f9606d 100644
--- a/website/pages/cs/developing/graph-ts/api.mdx
+++ b/website/pages/cs/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ Knihovna `@graphprotocol/graph-ts` poskytuje následující API:
 
 `apiVersion` v manifestu podgrafu určuje verzi mapovacího API, kterou pro daný podgraf používá uzel Graf.
 
-| Verze | Poznámky vydání |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Přidá ověření existence polí ve schéma při ukládání entity. |
-| 0.0.7 | Přidání tříd `TransactionReceipt` a `Log` do typů Ethereum<br />Přidání pole `receipt` do objektu Ethereum událost |
-| 0.0.6 | Přidáno pole `nonce` do objektu Ethereum Transaction<br />Přidáno `baseFeePerGas` do objektu Ethereum bloku |
+| Verze | Poznámky vydání                                                                                                                                                                                                                  |
+| :---: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                     |
+| 0.0.8 | Přidá ověření existence polí ve schéma při ukládání entity.                                                                                                                                                                      |
+| 0.0.7 | Přidání tříd `TransactionReceipt` a `Log` do typů Ethereum<br />Přidání pole `receipt` do objektu Ethereum událost                                                                                                               |
+| 0.0.6 | Přidáno pole `nonce` do objektu Ethereum Transaction<br />Přidáno `baseFeePerGas` do objektu Ethereum bloku                                                                                                                      |
 | 0.0.5 | AssemblyScript povýšen na verzi 0.19.10 (obsahuje rozbíjející změny, viz [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` přejmenováno na `ethereum.transaction.gasLimit` |
-| 0.0.4 | Přidání pole `functionSignature` do objektu Ethereum SmartContractCall |
-| 0.0.3 | Do objektu Ethereum Call přidáno pole `from`<br />`etherem.call.address` přejmenováno na `ethereum.call.to` |
-| 0.0.2 | Přidání pole `input` do objektu Ethereum Transackce |
+| 0.0.4 | Přidání pole `functionSignature` do objektu Ethereum SmartContractCall                                                                                                                                                           |
+| 0.0.3 | Do objektu Ethereum Call přidáno pole `from`<br />`etherem.call.address` přejmenováno na `ethereum.call.to`                                                                                                                      |
+| 0.0.2 | Přidání pole `input` do objektu Ethereum Transackce                                                                                                                                                                              |
 
 ### Vestavěné typy
 
@@ -147,7 +147,7 @@ _Math_
 - `x.notEqual(y: BigInt): bool` –lze zapsat jako `x != y`.
 - `x.lt(y: BigInt): bool` – lze zapsat jako `x < y`.
 - `x.le(y: BigInt): bool` – lze zapsat jako `x <= y`.
-- `x.gt(y: BigInt): bool` – lze zapsat jako `x > y`.
+- `x.gt(y: BigInt): bool` – lze zapsat jako   `x > y`.
 - `x.ge(y: BigInt): bool` – lze zapsat jako `x >= y`.
 - `x.neg(): BigInt` – lze zapsat jako `-x`.
 - `x.divDecimal(y: BigDecimal): BigDecimal` – dělí desetinným číslem, čímž získá desetinný výsledek.
@@ -202,7 +202,7 @@ _Operators_
 - `b.concat(other: Bytes) : Bytes` - - "Vrátit nový `Bytes` skládající se z `this`, který je přímo následován `other`."
 - `b.concatI32(other: i32) : ByteArray` - vrátí nový `Bytes` složený z `this` přímo následovaný bajtovou reprezentací `other`
 
-#### Adresa
+#### Address
 
 ```typescript
 import { Address } from '@graphprotocol/graph-ts'
@@ -215,7 +215,7 @@ Přidává následující metodu nad API `Bytes`:
 - `Address.fromString(s: string): Address` - vytvoří `Address` z hexadecimálního řetězce
 - `Address.fromBytes(b: Bytes): Adresa` - vytvoří `Adresu` z `b`, která musí být dlouhá přesně 20 bajtů. Předání hodnoty s menším nebo větším počtem bajtů bude mít za následek chybu
 
-### API ukládat
+### Store API
 
 ```typescript
 import { store } from '@graphprotocol/graph-ts'
@@ -225,29 +225,29 @@ API `store` umožňuje načítat, ukládat a odebírat entity z a do úložišt
 
 Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
 
-#### Vytváření entity
+#### Creating entities
 
-Následuje běžný vzor pro vytváření entity z událostí Ethereum.
+The following is a common pattern for creating entities from Ethereum events.
 
 ```typescript
-// Importovat třídu události Transfer vygenerovanou z ERC20 ABI
-import { Transfer as TransferEvent } z '../generated/ERC20/ERC20'
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
 
-// Importovat typ entity Transfer vygenerovaný ze schématu GraphQL
-import { Transfer } z '../generated/schema'
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
 
-// Obsluha události Transfer
+// Transfer event handler
 export function handleTransfer(event: TransferEvent): void {
-  // Vytvoří entitu Transfer s použitím hashe transakce jako ID entity
+  // Create a Transfer entity, using the transaction hash as the entity ID
   let id = event.transaction.hash
   let transfer = new Transfer(id)
 
-  // Nastavte vlastnosti entity pomocí parametrů události
+  // Set properties on the entity, using the event parameters
   transfer.from = event.params.from
   transfer.to = event.params.to
   transfer.amount = event.params.amount
 
-  // Uložení entity do úložiště
+  // Save the entity to the store
   transfer.save()
 }
 ```
@@ -258,25 +258,25 @@ Each entity must have a unique ID to avoid collisions with other entities. It is
 
 > Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
 
-#### Načítání entity z úložiště
+#### Loading entities from the store
 
-Pokud již entita existuje, lze ji z úložiště načíst pomocí následujících příkazů:
+If an entity already exists, it can be loaded from the store with the following:
 
 ```typescript
-let id = event.transaction.hash // nebo jakkoli je ID konstruováno
+let id = event.transaction.hash // or however the ID is constructed
 let transfer = Transfer.load(id)
 if (transfer == null) {
   transfer = new Transfer(id)
 }
 
-// Použijte entitu Transfer jako dříve
+// Use the Transfer entity as before
 ```
 
 As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
 
 > Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
 
-#### Vyhledávání entit vytvořených v rámci bloku
+#### Looking up entities created withing a block
 
 Od verzí `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 a `@graphprotocol/graph-cli` v0.49.0 je metoda `loadInBlock` dostupná pro všechny typy entit.
 
@@ -297,11 +297,11 @@ if (transfer == null) {
 
 > Poznámka: Pokud v daném bloku není vytvořena žádná entita, vrátí `loadInBlock` hodnotu `null`, i když v úložišti existuje entita s daným ID.
 
-#### Vyhledávání odvozených entity
+#### Looking up derived entities
 
 Od verzí `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 a `@graphprotocol/graph-cli` v0.51.0 je k dispozici metoda `loadRelated`.
 
-To umožňuje načítání odvozených polí entityh z obsluhy události. Například při následujícím schématu:
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
 
 ```graphql
 type Token @entity {
@@ -320,18 +320,18 @@ Následující kód načte entitu `Token`, ze které byla odvozena entita `Holde
 
 ```typescript
 let holder = Holder.load('test-id')
-// Načtení entit tokenů přidružených k danému držiteli
+// Load the Token entities associated with a given holder
 let tokens = holder.tokens.load()
 ```
 
-#### Aktualizace stávajících entity
+#### Updating existing entities
 
-Existují dva způsoby, jak aktualizovat existující entity:
+There are two ways to update an existing entity:
 
 1. Načtěte entitu např. pomocí `Transfer.load(id)`, nastavte vlastnosti entity a poté ji `.save()` uložte zpět do úložiště.
 2. Jednoduše vytvořte entitu např. pomocí `new Transfer(id)`, nastavte vlastnosti entity a poté ji `.save()` uložte do úložiště. Pokud entita již existuje, změny se do ní sloučí.
 
-Změna vlastností je ve většině případů jednoduchá díky generovaným nastavovačům vlastností:
+Changing properties is straight forward in most cases, thanks to the generated property setters:
 
 ```typescript
 let transfer = new Transfer(id)
@@ -340,7 +340,7 @@ transfer.to = ...
 transfer.amount = ...
 ```
 
-Vlastnosti lze také zrušit jedním z následujících dvou příkazů:
+It is also possible to unset properties with one of the following two instructions:
 
 ```typescript
 transfer.from.unset()
@@ -352,18 +352,18 @@ To funguje pouze u nepovinných vlastností, tj. vlastností, které jsou v jazy
 Aktualizace vlastností pole je trochu složitější, protože získání pole z entity vytvoří kopii tohoto pole. To znamená, že vlastnosti pole je třeba po změně pole znovu explicitně nastavit. Následující příklad předpokládá, že `entita` má `čísla: [BigInt!]!` pole.
 
 ```typescript
-// Tohle nebude fungovat
+// This won't work
 entity.numbers.push(BigInt.fromI32(1))
 entity.save()
 
-// Toto bude fungovat
+// This will work
 let numbers = entity.numbers
 numbers.push(BigInt.fromI32(1))
 entity.numbers = numbers
 entity.save()
 ```
 
-#### Odstranění entit z úložiště
+#### Removing entities from the store
 
 V současné době není možné odstranit entitu prostřednictvím generovaných typů. Místo toho je pro odstranění entity nutné předat název typu entity a ID entity příkazu `store.remove`:
 
@@ -376,15 +376,15 @@ store.remove('Transfer', id)
 
 ### Ethereum API
 
-Ethereum API poskytuje přístup k inteligentním smlouvám, veřejným stavovým proměnným, funkcím smluv, událostem, transakcím, blokům a kódování/dekódování dat Etherea.
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
 
-#### Podpora typů Ethereum
+#### Support for Ethereum Types
 
 Stejně jako u entit generuje `graph codegen` třídy pro všechny inteligentní smlouvy a události používané v podgrafu. Za tímto účelem musí být ABI kontraktu součástí zdroje dat v manifestu podgrafu. Obvykle jsou soubory ABI uloženy ve složce `abis/`.
 
 Ve vygenerovaných třídách probíhají konverze mezi typy Ethereum [built-in-types](#built-in-types) v pozadí, takže se o ně autoři podgraf nemusí starat.
 
-To ilustruje následující příklad. Je dáno schéma podgrafu, jako je
+The following example illustrates this. Given a subgraph schema like
 
 ```graphql
 type Transfer @entity {
@@ -406,7 +406,7 @@ transfer.amount = event.params.amount
 transfer.save()
 ```
 
-#### Události a bloková/transakční data
+#### Events and Block/Transaction Data
 
 Události Ethereum předávané obsluze událostí, jako je událost `Transfer` v předchozích příkladech, poskytují přístup nejen k parametrům události, ale také k nadřazené transakci a bloku, jehož jsou součástí. Z instancí `event` (tyto třídy jsou součástí modulu `ethereum` v `graph-ts`) lze získat následující údaje:
 
@@ -481,23 +481,23 @@ class Log {
 }
 ```
 
-#### Přístup ke stavu inteligentní smlouvy
+#### Access to Smart Contract State
 
 Kód vygenerovaný nástrojem `graph codegen` obsahuje také třídy pro inteligentní smlouvy používané v podgrafu. Ty lze použít k přístupu k veřejným stavovým proměnným a k volání funkcí kontraktu v aktuálním bloku.
 
-Běžným vzorem je přístup ke smlouvě, ze které událost pochází. Toho lze dosáhnout pomocí následujícího kódu:
+A common pattern is to access the contract from which an event originates. This is achieved with the following code:
 
 ```typescript
-// Import vygenerované třídy smlouvy a vygenerované třídy události Transfer
-import { ERC20Contract, Transfer as TransferEvent } z '../generated/ERC20Contract/ERC20Contract'
-// Importovat vygenerovanou třídu entit
-import { Transfer } z "../generated/schema
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
 
 export function handleTransfer(event: TransferEvent) {
-  // Vázat smlouvu na adresu, která událost vyslala
+  // Bind the contract to the address that emitted the event
   let contract = ERC20Contract.bind(event.address)
 
-  // Přístup ke stavovým proměnným a funkcím jejich voláním
+  // Access state variables and functions by calling them
   let erc20Symbol = contract.symbol()
 }
 ```
@@ -506,9 +506,9 @@ export function handleTransfer(event: TransferEvent) {
 
 Pokud má smlouva `ERC20Contract` na platformě Ethereum veřejnou funkci pouze pro čtení s názvem `symbol`, lze ji volat pomocí `.symbol()`. Pro veřejné stavové proměnné se automaticky vytvoří metoda se stejným názvem.
 
-Jakákoli jiná smlouva, která je součástí podgrafu, může být importována z vygenerovaného kódu a může být svázána s platnou adresou.
+Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address.
 
-#### Zpracování vrácených volání
+#### Handling Reverted Calls
 
 If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
 
@@ -526,7 +526,7 @@ if (callResult.reverted) {
 
 > Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
 
-#### Kódování/dekódování ABI
+#### Encoding/Decoding ABI
 
 Data lze kódovat a dekódovat podle formátu kódování ABI Ethereum pomocí funkcí `encode` a `decode` v modulu `ethereum`.
 
@@ -545,7 +545,7 @@ let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
 let decoded = ethereum.decode('(address,uint256)', encoded)
 ```
 
-Více informací:
+For more information:
 
 - [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
 - Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
@@ -598,9 +598,9 @@ The `log` API allows subgraphs to log information to the Graph Node standard out
 log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
 ```
 
-#### Zaznamenávání jedné nebo více hodnot
+#### Logging one or more values
 
-##### Zaznamenávání jedné hodnoty
+##### Logging a single value
 
 V níže uvedeném příkladu je řetězcová hodnota "A" předána do pole a stane se z ní `['A']`, než je zapsána:
 
@@ -613,9 +613,9 @@ export function handleSomeEvent(event: SomeEvent): void {
 }
 ```
 
-##### Protokolování jedné položky z existujícího pole
+##### Logging a single entry from an existing array
 
-V příkladu níže je zaznamenána pouze první hodnota pole argumentů, přestože pole obsahuje tři hodnoty.
+In the example below, only the first value of the argument array is logged, despite the array containing three values.
 
 ```typescript
 let myArray = ['A', 'B', 'C']
@@ -626,7 +626,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 }
 ```
 
-#### Protokolování více záznamů z existujícího pole
+#### Logging multiple entries from an existing array
 
 Každá položka v poli argumentů vyžaduje vlastní zástupný znak `{}` v řetězci zprávy protokolu. Níže uvedený příklad obsahuje tři zástupné zna. Z tohoto důvodu jsou zaznamenány všechny tři hodnoty v poli `myArray`.
 
@@ -639,9 +639,9 @@ export function handleSomeEvent(event: SomeEvent): void {
 }
 ```
 
-##### Protokolování konkrétní položky z existujícího pole
+##### Logging a specific entry from an existing array
 
-Chcete-li zobrazit konkrétní hodnotu v poli, je třeba zadat indexovanou hodnotu.
+To display a specific value in the array, the indexed value must be provided.
 
 ```typescript
 export function handleSomeEvent(event: SomeEvent): void {
@@ -650,9 +650,9 @@ export function handleSomeEvent(event: SomeEvent): void {
 }
 ```
 
-##### Zaznamenávání informací o událostech
+##### Logging event information
 
-Níže uvedený příklad zaznamenává číslo bloku, hash bloku a hash transakce z události:
+The example below logs the block number, block hash and transaction hash from an event:
 
 ```typescript
 import { log } from '@graphprotocol/graph-ts'
@@ -674,17 +674,17 @@ import { ipfs } from '@graphprotocol/graph-ts'
 
 Chytré smlouvy příležitostně ukotvují soubory IPFS v řetězci. To umožňuje mapování získat hashe IPFS ze smlouvy a načíst odpovídající soubory z IPFS. Data souborů budou vrácena jako `Bajty`, což obvykle vyžaduje další zpracování, např. pomocí API `json` zdokumentovaného později na této stránce.
 
-Při zadání hashe nebo cesty IPFS se čtení souboru ze systému IPFS provádí následujícím způsobem:
+Given an IPFS hash or path, reading a file from IPFS is done as follows:
 
 ```typescript
-// Vložte to do obsluhy události v mapování
+// Put this inside an event handler in the mapping
 let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
 let data = ipfs.cat(hash)
 
-// Cesty jako `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
-// které obsahují soubory v adresářích, jsou také podporovány
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
 let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
-let data = ipfs.cat(cesta)
+let data = ipfs.cat(path)
 ```
 
 **Poznámka:** `ipfs.cat` není v současné době deterministický. Pokud se soubor nepodaří načíst přes síť IPFS před vypršením požadavku, vrátí se `null`. Z tohoto důvodu se vždy vyplatí zkontrolovat výsledek na `null`.
@@ -692,11 +692,11 @@ let data = ipfs.cat(cesta)
 Pomocí nástroje `ipfs.map` je také možné zpracovávat větší soubory proudovým způsobem. Funkce očekává hash nebo cestu k souboru IPFS, název zpětného volání a příznaky pro úpravu chování:
 
 ```typescript
-import { JSONValue, Value } z '@graphprotocol/graph-ts'
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
 
 export function processItem(value: JSONValue, userData: Value): void {
-  // Podrobnosti o zpracování viz dokumentace k JSONValue
-  // s hodnotami JSON
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
   let obj = value.toObject()
   let id = obj.get('id')
   let title = obj.get('title')
@@ -705,17 +705,17 @@ export function processItem(value: JSONValue, userData: Value): void {
     return
   }
 
-  // Callbacky mohou také vytvářet entity
+  // Callbacks can also created entities
   let newItem = new Item(id)
   newItem.title = title.toString()
-  newitem.parent = userData.toString() // Nastavit rodiče na "parentId"
+  newitem.parent = userData.toString() // Set parent to "parentId"
   newitem.save()
 }
 
-// Toto vložte do obsluhy události v mapování
+// Put this inside an event handler in the mapping
 ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
 
-// Případně použijte `ipfs.mapJSON`
+// Alternatively, use `ipfs.mapJSON`
 ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
 ```
 
@@ -768,46 +768,46 @@ Pokud je typ hodnoty jistý, lze ji převést na [vestavěný typ](#built-in-typ
 - `value.toString(): string`
 - `value.toArray(): Array<JSONValue>` - (a poté převést `JSONValue` pomocí jedné z 5 výše uvedených metod)
 
-### Převody typů Reference
-
-| Zdroj(e)                | Destinace               | Funkce převodu               |
-| ----------------------- | ----------------------- | ---------------------------- |
-| Address                 | Bytes                   | none                         |
-| Address                 | String                  | s.toHexString()              |
-| BigDecimal              | String                  | s.toString()                 |
-| BigInt                  | BigDecimal              | s.toBigDecimal()             |
-| BigInt                  | String (hexadecimální)  | s.toHexString() or s.toHex() |
-| BigInt                  | String (unicode)        | s.toString()                 |
-| BigInt                  | i32                     | s.toI32()                    |
-| Boolean                 | Boolean                 | none                         |
-| Bytes (signed)          | BigInt                  | BigInt.fromSignedBytes(s)    |
-| Bytes (unsigned)        | BigInt                  | BigInt.fromUnsignedBytes(s)  |
-| Bytes                   | Řetězec (hexadecimální) | s.toHexString() or s.toHex() |
-| Bytes                   | String (unicode)        | s.toString()                 |
-| Bytes                   | String (base58)         | s.toBase58()                 |
-| Bytes                   | i32                     | s.toI32()                    |
-| Bytes                   | u32                     | s.toU32()                    |
-| Bytes                   | JSON                    | json.fromBytes(s)            |
-| int8                    | i32                     | none                         |
-| int32                   | i32                     | none                         |
-| int32                   | BigInt                  | BigInt.fromI32(s)            |
-| uint24                  | i32                     | none                         |
-| int64 - int256          | BigInt                  | none                         |
-| uint32 - uint256        | BigInt                  | none                         |
-| JSON                    | boolean                 | s.toBool()                   |
-| JSON                    | i64                     | s.toI64()                    |
-| JSON                    | u64                     | s.toU64()                    |
-| JSON                    | f64                     | s.toF64()                    |
-| JSON                    | BigInt                  | s.toBigInt()                 |
-| JSON                    | string                  | s.toString()                 |
-| JSON                    | Array                   | s.toArray()                  |
-| JSON                    | Object                  | s.toObject()                 |
-| String                  | Address                 | Address.fromString(s)        |
-| Bytes                   | Address                 | Address.fromBytes(s)         |
-| String                  | BigInt                  | BigInt.fromString(s)         |
-| String                  | BigDecimal              | BigDecimal.fromString(s)     |
-| Řetězec (hexadecimální) | Bytes                   | ByteArray.fromHexString(s)   |
-| String (UTF-8)          | Bytes                   | ByteArray.fromUTF8(s)        |
+### Type Conversions Reference
+
+| Zdroj(e)               | Destinace              | Funkce převodu               |
+| ---------------------- | ---------------------- | ---------------------------- |
+| Address                | Bytes                  | none                         |
+| Address                | String                 | s.toHexString()              |
+| BigDecimal             | String                 | s.toString()                 |
+| BigInt                 | BigDecimal             | s.toBigDecimal()             |
+| BigInt                 | String (hexadecimální) | s.toHexString() or s.toHex() |
+| BigInt                 | String (unicode)       | s.toString()                 |
+| BigInt                 | i32                    | s.toI32()                    |
+| Boolean                | Boolean                | none                         |
+| Bytes (signed)         | BigInt                 | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)       | BigInt                 | BigInt.fromUnsignedBytes(s)  |
+| Bytes                  | String (hexadecimální) | s.toHexString() or s.toHex() |
+| Bytes                  | String (unicode)       | s.toString()                 |
+| Bytes                  | String (base58)        | s.toBase58()                 |
+| Bytes                  | i32                    | s.toI32()                    |
+| Bytes                  | u32                    | s.toU32()                    |
+| Bytes                  | JSON                   | json.fromBytes(s)            |
+| int8                   | i32                    | none                         |
+| int32                  | i32                    | none                         |
+| int32                  | BigInt                 | BigInt.fromI32(s)            |
+| uint24                 | i32                    | none                         |
+| int64 - int256         | BigInt                 | none                         |
+| uint32 - uint256       | BigInt                 | none                         |
+| JSON                   | boolean                | s.toBool()                   |
+| JSON                   | i64                    | s.toI64()                    |
+| JSON                   | u64                    | s.toU64()                    |
+| JSON                   | f64                    | s.toF64()                    |
+| JSON                   | BigInt                 | s.toBigInt()                 |
+| JSON                   | string                 | s.toString()                 |
+| JSON                   | Array                  | s.toArray()                  |
+| JSON                   | Object                 | s.toObject()                 |
+| String                 | Address                | Address.fromString(s)        |
+| Bytes                  | Address                | Address.fromBytes(s)         |
+| String                 | BigInt                 | BigInt.fromString(s)         |
+| String                 | BigDecimal             | BigDecimal.fromString(s)     |
+| String (hexadecimální) | Bytes                  | ByteArray.fromHexString(s)   |
+| String (UTF-8)         | Bytes                  | ByteArray.fromUTF8(s)        |
 
 ### Metadata zdroje dat
 
@@ -817,7 +817,7 @@ Adresu smlouvy, síť a kontext zdroje dat, který obslužnou rutinu vyvolal, m
 - `dataSource.network(): string`
 - `dataSource.context(): DataSourceContext`
 
-### Entity a DataSourceContext
+### Entity and DataSourceContext
 
 Základní třída `Entity` a podřízená třída `DataSourceContext` mají pomocníky pro dynamické nastavování a získávání polí:
 
@@ -834,7 +834,7 @@ Základní třída `Entity` a podřízená třída `DataSourceContext` mají pom
 - `getBoolean(key: string): boolean`
 - `getBigDecimal(key: string): BigDecimal`
 
-### DataSourceContext v manifestu
+### DataSourceContext in Manifest
 
 Sekce `context` v rámci `dataSources` umožňuje definovat páry klíč-hodnota, které jsou přístupné v rámci mapování podgrafů. Dostupné typy jsou `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List` a `BigInt`.
 
@@ -887,4 +887,4 @@ dataSources:
 - `Seznam`: Určuje seznam položek. U každé položky je třeba zadat její typ a data.
 - `BigInt`: Určuje velkou celočíselnou hodnotu. Kvůli velké velikosti musí být uvedena v uvozovkách.
 
-Tento kontext je pak přístupný v souborech mapování podgrafů, což umožňuje vytvářet dynamičtější a konfigurovatelnější podgrafy.
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From 8a72b73108fea5a0c3f4f85a64bd670e2fc15a16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:39 -0500
Subject: [PATCH 0048/3820] New translations advanced.mdx (Czech)

---
 website/pages/cs/developing/creating-a-subgraph/advanced.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/developing/creating-a-subgraph/advanced.mdx b/website/pages/cs/developing/creating-a-subgraph/advanced.mdx
index 7d62e06bd1cd..fc663d24324b 100644
--- a/website/pages/cs/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/cs/developing/creating-a-subgraph/advanced.mdx
@@ -238,7 +238,7 @@ The CID of the file as a readable string can be accessed via the `dataSource` as
 const cid = dataSource.stringParam()
 ```
 
-Příklad
+Příklad 
 
 ```typescript
 import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'

From c37e2230d3d3b40c378909b6f21c6b821505e8f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:41 -0500
Subject: [PATCH 0049/3820] New translations install-the-cli.mdx (Czech)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/cs/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/cs/developing/creating-a-subgraph/install-the-cli.mdx
index 41abfbdccf16..e03ed92103bf 100644
--- a/website/pages/cs/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/cs/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ Soubor(y) ABI se musí shodovat s vaší smlouvou. Soubory ABI lze získat něko
 
 ## SpecVersion Releases
 
-| Verze | Poznámky vydání |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
+| Verze | Poznámky vydání                                                                                                                                                          |
+| :---: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+| 0.0.9 | Supports `endBlock` feature                                                                                                                                              |
 | 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+| 0.0.5 | Added support for event handlers having access to transaction receipts.                                                                                                  |
+| 0.0.4 | Added support for managing subgraph features.                                                                                                                            |

From 93b2514eede94fce6c49aa2740eb4acbdf5b4e96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:42 -0500
Subject: [PATCH 0050/3820] New translations ql-schema.mdx (Czech)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/cs/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/cs/developing/creating-a-subgraph/ql-schema.mdx
index befce4a22bf8..b284541e1b5e 100644
--- a/website/pages/cs/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/cs/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Typ | Popis |
-| --- | --- |
-| `Bytes` | Pole bajtů reprezentované jako hexadecimální řetězec. Běžně se používá pro hashe a adresy Ethereum. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Typ          | Popis                                                                                                                                                                                                            |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Pole bajtů reprezentované jako hexadecimální řetězec. Běžně se používá pro hashe a adresy Ethereum.                                                                                                              |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 

From 7f38f78e7088646674eaece5bb0e623c356b9f2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:47 -0500
Subject: [PATCH 0051/3820] New translations unit-testing-framework.mdx
 (German)

---
 website/pages/de/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/de/developing/unit-testing-framework.mdx b/website/pages/de/developing/unit-testing-framework.mdx
index 553eec2157b3..53a5c43dedcf 100644
--- a/website/pages/de/developing/unit-testing-framework.mdx
+++ b/website/pages/de/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ The log output includes the test run duration. Here's an example:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.

From 3637305410859343b85fb9e233e2e7c6e85e9b7c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:49 -0500
Subject: [PATCH 0052/3820] New translations graphql-api.mdx (German)

---
 website/pages/de/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/de/querying/graphql-api.mdx b/website/pages/de/querying/graphql-api.mdx
index cd06c27f4d94..abe9db8cc7f4 100644
--- a/website/pages/de/querying/graphql-api.mdx
+++ b/website/pages/de/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 Fulltext search operators:
 
-| Symbol | Operator | Beschreibung |
-| --- | --- | --- |
-| `&` | `And` | For combining multiple search terms into a filter for entities that include all of the provided terms |
-| &#x7c; | `Or` | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
-| `<->` | `Follow by` | Specify the distance between two words. |
-| `:*` | `Prefix` | Use the prefix search term to find words whose prefix match (2 characters required.) |
+| Symbol      | Operator    | Beschreibung                                                                                                                         |
+| ----------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| &#x7c;      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->` | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`        | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 
 #### Beispiele
 

From 3cea0600a6362e71d22ed8cf7ad5bf7bfb4469a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:50 -0500
Subject: [PATCH 0053/3820] New translations api.mdx (German)

---
 website/pages/de/developing/graph-ts/api.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/de/developing/graph-ts/api.mdx b/website/pages/de/developing/graph-ts/api.mdx
index 649dc4d73cd5..020d37ade7f7 100644
--- a/website/pages/de/developing/graph-ts/api.mdx
+++ b/website/pages/de/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| Version | Release notes |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| Version | Release notes                                                                                                                                                                                                                                 |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### Built-in Types
 

From d638422f0cf07f3490d7900cc9e3b1dcd9360772 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:54 -0500
Subject: [PATCH 0054/3820] New translations install-the-cli.mdx (German)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/de/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/de/developing/creating-a-subgraph/install-the-cli.mdx
index 91922e0319e7..6b68f875fdd2 100644
--- a/website/pages/de/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/de/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The ABI file(s) must match your contract(s). There are a few ways to obtain ABI
 
 ## SpecVersion Releases
 
-| Version | Release notes |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 9baa2192e285184e1f6f8c7ca97f6d47c48e711a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:55 -0500
Subject: [PATCH 0055/3820] New translations ql-schema.mdx (German)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/de/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/de/developing/creating-a-subgraph/ql-schema.mdx
index 90036d1bfab9..3df39853f82b 100644
--- a/website/pages/de/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/de/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Type | Description |
-| --- | --- |
-| `Bytes` | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 

From 1a11fb2e4471b4ea9427308274ec888128a9bd32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:56:59 -0500
Subject: [PATCH 0056/3820] New translations unit-testing-framework.mdx
 (Italian)

---
 website/pages/it/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/it/developing/unit-testing-framework.mdx b/website/pages/it/developing/unit-testing-framework.mdx
index 553eec2157b3..53a5c43dedcf 100644
--- a/website/pages/it/developing/unit-testing-framework.mdx
+++ b/website/pages/it/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ The log output includes the test run duration. Here's an example:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.

From db6ade881505ef13234fde34e965235bc6d7884a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:01 -0500
Subject: [PATCH 0057/3820] New translations graphql-api.mdx (Italian)

---
 website/pages/it/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/it/querying/graphql-api.mdx b/website/pages/it/querying/graphql-api.mdx
index 39369363a1d5..4c89c5b31f13 100644
--- a/website/pages/it/querying/graphql-api.mdx
+++ b/website/pages/it/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** Si può semplificare la query precedente eliminando l'operatore `and` passando una sottoespressione separata da virgole.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Le query di ricerca fulltext hanno un campo obbligatorio, `text`, per fornire i
 
 Operatori di ricerca fulltext:
 
-| Simbolo | Operatore | Descrizione |
-| --- | --- | --- |
-| `&` | `And` | Per combinare più termini di ricerca in un filtro per le entità che includono tutti i termini forniti |
-| &#x7c; | `Or` | Le query con più termini di ricerca separati dall'operatore Or restituiranno tutte le entità con una corrispondenza tra i termini forniti |
-| `<->` | `Follow by` | Specifica la distanza tra due parole. |
-| `:*` | `Prefisso` | Utilizzare il termine di ricerca del prefisso per trovare le parole il cui prefisso corrisponde (sono richiesti 2 caratteri.) |
+| Simbolo     | Operatore   | Descrizione                                                                                                                               |
+| ----------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`     | `And`       | Per combinare più termini di ricerca in un filtro per le entità che includono tutti i termini forniti                                     |
+| &#x7c;      | `Or`        | Le query con più termini di ricerca separati dall'operatore Or restituiranno tutte le entità con una corrispondenza tra i termini forniti |
+| `<->` | `Follow by` | Specifica la distanza tra due parole.                                                                                                     |
+| `:*`        | `Prefisso`  | Utilizzare il termine di ricerca del prefisso per trovare le parole il cui prefisso corrisponde (sono richiesti 2 caratteri.)             |
 
 #### Esempi
 

From 3a8d3c75ddb5301184630f9094dca119d5aee416 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:02 -0500
Subject: [PATCH 0058/3820] New translations api.mdx (Italian)

---
 website/pages/it/developing/graph-ts/api.mdx | 96 ++++++++++----------
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/website/pages/it/developing/graph-ts/api.mdx b/website/pages/it/developing/graph-ts/api.mdx
index 502644810be8..4edadedcff5e 100644
--- a/website/pages/it/developing/graph-ts/api.mdx
+++ b/website/pages/it/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ La libreria `@graphprotocol/graph-ts` fornisce le seguenti API:
 
 La `apiVersion` nel manifest del subgraph specifica la versione dell'API di mappatura che viene eseguita da the Graph Node per un dato subgraph.
 
-| Versione | Note di rilascio |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Aggiunte le classi `TransactionReceipt` e `Log` ai tipi di Ethereum<br />Aggiunto il campo `receipt` all'oggetto Ethereum Event |
-| 0.0.6 | Aggiunto il campo `nonce` all'oggetto Ethereum Transaction<br />Aggiunto `baseFeePerGas` all'oggetto Ethereum Block |
-| 0.0.5 | AssemblyScript aggiornato alla versione 0.19.10 (questo include modifiche di rottura, consultare la [`Guida alla migrazione`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` rinominato in `ethereum.transaction.gasLimit` |
-| 0.0.4 | Aggiunto il campo `functionSignature` all'oggetto Ethereum SmartContractCall |
-| 0.0.3 | Aggiunto il campo `from` all'oggetto Ethereum Call<br />`etherem.call.address` rinominato in `ethereum.call.to` |
-| 0.0.2 | Aggiunto il campo `input` all'oggetto Ethereum Transaction |
+| Versione | Note di rilascio                                                                                                                                                                                                                                                |
+| :------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|   0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                                    |
+|   0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                                    |
+|   0.0.7  | Aggiunte le classi `TransactionReceipt` e `Log` ai tipi di Ethereum<br />Aggiunto il campo `receipt` all'oggetto Ethereum Event                                                                                                                                 |
+|   0.0.6  | Aggiunto il campo `nonce` all'oggetto Ethereum Transaction<br />Aggiunto `baseFeePerGas` all'oggetto Ethereum Block                                                                                                                                             |
+|   0.0.5  | AssemblyScript aggiornato alla versione 0.19.10 (questo include modifiche di rottura, consultare la [`Guida alla migrazione`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` rinominato in `ethereum.transaction.gasLimit` |
+|   0.0.4  | Aggiunto il campo `functionSignature` all'oggetto Ethereum SmartContractCall                                                                                                                                                                                    |
+|   0.0.3  | Aggiunto il campo `from` all'oggetto Ethereum Call<br />`etherem.call.address` rinominato in `ethereum.call.to`                                                                                                                                                 |
+|   0.0.2  | Aggiunto il campo `input` all'oggetto Ethereum Transaction                                                                                                                                                                                                      |
 
 ### Tipi integrati
 
@@ -770,44 +770,44 @@ Quando il tipo di un valore è certo, può essere convertito in un [tipo incorpo
 
 ### Riferimento alle conversioni di tipo
 
-| Fonte(i)             | Destinazione         | Funzione di conversione     |
-| -------------------- | -------------------- | --------------------------- |
-| Address              | Bytes                | none                        |
-| Address              | String               | s.toHexString()             |
-| BigDecimal           | String               | s.toString()                |
-| BigInt               | BigDecimal           | s.toBigDecimal()            |
-| BigInt               | String (hexadecimal) | s.toHexString() o s.toHex() |
-| BigInt               | String (unicode)     | s.toString()                |
-| BigInt               | i32                  | s.toI32()                   |
-| Boolean              | Boolean              | none                        |
-| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)   |
-| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s) |
-| Bytes                | String (hexadecimal) | s.toHexString() o s.toHex() |
-| Bytes                | String (unicode)     | s.toString()                |
-| Bytes                | String (base58)      | s.toBase58()                |
-| Bytes                | i32                  | s.toI32()                   |
-| Bytes                | u32                  | s.toU32()                   |
-| Bytes                | JSON                 | json.fromBytes(s)           |
-| int8                 | i32                  | none                        |
-| int32                | i32                  | none                        |
-| int32                | BigInt               | BigInt.fromI32(s)           |
-| uint24               | i32                  | none                        |
-| int64 - int256       | BigInt               | none                        |
-| uint32 - uint256     | BigInt               | none                        |
-| JSON                 | boolean              | s.toBool()                  |
-| JSON                 | i64                  | s.toI64()                   |
-| JSON                 | u64                  | s.toU64()                   |
-| JSON                 | f64                  | s.toF64()                   |
-| JSON                 | BigInt               | s.toBigInt()                |
-| JSON                 | string               | s.toString()                |
-| JSON                 | Array                | s.toArray()                 |
-| JSON                 | Object               | s.toObject()                |
-| String               | Address              | Address.fromString(s)       |
-| Bytes                | Address              | Address.fromBytes(s)        |
-| String               | BigInt               | BigInt.fromString(s)        |
-| String               | BigDecimal           | BigDecimal.fromString(s)    |
-| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)  |
-| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)       |
+| Fonte(i)             | Destinazione          | Funzione di conversione          |
+| -------------------- | --------------------- | -------------------------------- |
+| Address              | Bytes                 | none                             |
+| Address              | String                | s.toHexString()                  |
+| BigDecimal           | String                | s.toString()                     |
+| BigInt               | BigDecimal            | s.toBigDecimal()                 |
+| BigInt               | String (hexadecimal)  | s.toHexString() o s.toHex()      |
+| BigInt               | String (unicode)      | s.toString()                     |
+| BigInt               | i32                   | s.toI32()                        |
+| Boolean              | Boolean               | none                             |
+| Bytes (signed)       | BigInt                | BigInt.fromSignedBytes(s)        |
+| Bytes (unsigned)     | BigInt                | BigInt.fromUnsignedBytes(s)      |
+| Bytes                | String (hexadecimal)  | s.toHexString() o s.toHex()      |
+| Bytes                | String (unicode)      | s.toString()                     |
+| Bytes                | String (base58)       | s.toBase58()                     |
+| Bytes                | i32                   | s.toI32()                        |
+| Bytes                | u32                   | s.toU32()                        |
+| Bytes                | JSON                  | json.fromBytes(s)                |
+| int8                 | i32                   | none                             |
+| int32                | i32                   | none                             |
+| int32                | BigInt                | BigInt.fromI32(s)                |
+| uint24               | i32                   | none                             |
+| int64 - int256       | BigInt                | none                             |
+| uint32 - uint256     | BigInt                | none                             |
+| JSON                 | boolean               | s.toBool()                       |
+| JSON                 | i64                   | s.toI64()                        |
+| JSON                 | u64                   | s.toU64()                        |
+| JSON                 | f64                   | s.toF64()                        |
+| JSON                 | BigInt                | s.toBigInt()                     |
+| JSON                 | string                | s.toString()                     |
+| JSON                 | Array                 | s.toArray()                      |
+| JSON                 | Object                | s.toObject()                     |
+| String               | Address               | Address.fromString(s)            |
+| Bytes                | Address               | Address.fromBytes(s)             |
+| String               | BigInt                | BigInt.fromString(s)             |
+| String               | BigDecimal            | BigDecimal.fromString(s)         |
+| String (hexadecimal) | Bytes                 | ByteArray.fromHexString(s)       |
+| String (UTF-8)       | Bytes                 | ByteArray.fromUTF8(s)            |
 
 ### Metadati della Data Source
 

From 6ed5fe054d2d3cade6a36edda1c929fbf379a698 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:06 -0500
Subject: [PATCH 0059/3820] New translations install-the-cli.mdx (Italian)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/it/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/it/developing/creating-a-subgraph/install-the-cli.mdx
index bc62da7231bc..be04d41a029f 100644
--- a/website/pages/it/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/it/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ I file ABI devono corrispondere al vostro contratto. Esistono diversi modi per o
 
 ## SpecVersion Releases
 
-| Version | Release notes |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| Versione | Note di rilascio                                                                                                                                                         |
+| :------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|   1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|   1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|   1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|   0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|   0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|   0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|   0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|   0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|   0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 303ee3640882a59bbc614c3ca254e2a8f1b81b41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:07 -0500
Subject: [PATCH 0060/3820] New translations ql-schema.mdx (Italian)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/it/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/it/developing/creating-a-subgraph/ql-schema.mdx
index 74c9f4274cf2..3445fc2a0ef9 100644
--- a/website/pages/it/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/it/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Tipo | Descrizione |
-| --- | --- |
-| `Bytes` | Byte array, rappresentato come una stringa esadecimale. Comunemente utilizzato per gli hash e gli indirizzi di Ethereum. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Tipo         | Descrizione                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, rappresentato come una stringa esadecimale. Comunemente utilizzato per gli hash e gli indirizzi di Ethereum.                                                                                         |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enum
 

From 9d2e88eb59b11827f066762c4e4f192f2cd45862 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:11 -0500
Subject: [PATCH 0061/3820] New translations unit-testing-framework.mdx
 (Japanese)

---
 website/pages/ja/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ja/developing/unit-testing-framework.mdx b/website/pages/ja/developing/unit-testing-framework.mdx
index 8e20b4fe8312..89cbd8222458 100644
--- a/website/pages/ja/developing/unit-testing-framework.mdx
+++ b/website/pages/ja/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ Global test coverage: 22.2% (2/9 handlers).
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: 期待された引数は?
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: 期待された引数は?
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 引数の不一致は、`graph-ts`と`matchstick-as`の不一致によって起こります。このような問題を解決する最善の方法は、すべてを最新のリリース版にアップデートすることです。

From 819fba2205614e3b1f8d902532fd24d44c808697 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:12 -0500
Subject: [PATCH 0062/3820] New translations graphql-api.mdx (Japanese)

---
 website/pages/ja/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ja/querying/graphql-api.mdx b/website/pages/ja/querying/graphql-api.mdx
index 2c8ec74321ed..839a9bff35f4 100644
--- a/website/pages/ja/querying/graphql-api.mdx
+++ b/website/pages/ja/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **シンタックス シュガー:** コンマで区切られた部分式を渡すことで `and` 演算子を削除することで、上記のクエリを簡素化できます。
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ The result of such a query will not change over time, i.e., querying at a certai
 
 全文検索演算子:
 
-| シンボル | オペレーター | 説明書き |
-| --- | --- | --- |
-| `&` | `と` | 複数の検索語を組み合わせて、指定したすべての検索語を含むエンティティをフィルタリングします。 |
-| &#x7c; | `Or` | 複数の検索語をオペレーターで区切って検索すると、指定した語のいずれかにマッチするすべてのエンティティが返されます。 |
-| `<->` | `Follow by` | 2 つの単語の間の距離を指定します。 |
-| `:*` | `プレフィックス` | プレフィックス検索語を使って、プレフィックスが一致する単語を検索します（2 文字必要） |
+| シンボル        | オペレーター      | 説明書き                                                      |
+| ----------- | ----------- | --------------------------------------------------------- |
+| `&`     | `と`         | 複数の検索語を組み合わせて、指定したすべての検索語を含むエンティティをフィルタリングします。            |
+| &#x7c;      | `Or`        | 複数の検索語をオペレーターで区切って検索すると、指定した語のいずれかにマッチするすべてのエンティティが返されます。 |
+| `<->` | `Follow by` | 2 つの単語の間の距離を指定します。                                        |
+| `:*`        | `プレフィックス`   | プレフィックス検索語を使って、プレフィックスが一致する単語を検索します（2 文字必要）               |
 
 #### 例
 

From 48ebd4a054da7f781ebeda66f5377ed0f309c74b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:14 -0500
Subject: [PATCH 0063/3820] New translations api.mdx (Japanese)

---
 website/pages/ja/developing/graph-ts/api.mdx | 96 ++++++++++----------
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/website/pages/ja/developing/graph-ts/api.mdx b/website/pages/ja/developing/graph-ts/api.mdx
index e6f0d323fd82..cea9a55eb75c 100644
--- a/website/pages/ja/developing/graph-ts/api.mdx
+++ b/website/pages/ja/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ Since language mappings are written in AssemblyScript, it is useful to review th
 
 サブグラフマニフェストapiVersionは、特定のサブグラフのマッピングAPIバージョンを指定します。このバージョンは、Graph Nodeによって実行されます。
 
-| バージョン | リリースノート |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Ethereum タイプに `TransactionReceipt` と `Log` クラスを追加<br /> Ethereum Event オブジェクトに `receipt` フィールドを追加。 |
-| 0.0.6 | Ethereum Transactionオブジェクトに`nonce`フィールドを追加<br /> Ethereum Blockオブジェクトに`baseFeePerGas`を追加。 |
+| バージョン | リリースノート                                                                                                                                                                                                                                                                 |
+| :---: | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                                            |
+| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                                            |
+| 0.0.7 | Ethereum タイプに `TransactionReceipt` と `Log` クラスを追加<br /> Ethereum Event オブジェクトに `receipt` フィールドを追加。                                                                                                                                                                      |
+| 0.0.6 | Ethereum Transactionオブジェクトに`nonce`フィールドを追加<br /> Ethereum Blockオブジェクトに`baseFeePerGas`を追加。                                                                                                                                                                               |
 | 0.0.5 | AssemblyScriptはバージョン0.19.10にアップグレードされました（このバージョンアップには変更点が含まれていますので <a href="/release-notes/assemblyscript-migration-guide"><code>Migration Guide</code></a>) をご覧ください）。 <br /><code>ethereum.transaction.gasUsed</code>の名前が<code>ethereum.transaction.gasLimit</code>に変更 |
-| 0.0.4 | Ethereum SmartContractCall オブジェクトにfunctionSignatureフィールドを追加 |
-| 0.0.3 | イーサリアムコールオブジェクトに`from`フィールドを追加<br />`etherem.call.address`を`ethereum.call.to`に変更。 |
-| 0.0.2 | Ethereum Transaction オブジェクトに inputフィールドを追加 |
+| 0.0.4 | Ethereum SmartContractCall オブジェクトにfunctionSignatureフィールドを追加                                                                                                                                                                                                             |
+| 0.0.3 | イーサリアムコールオブジェクトに`from`フィールドを追加<br />`etherem.call.address`を`ethereum.call.to`に変更。                                                                                                                                                                                       |
+| 0.0.2 | Ethereum Transaction オブジェクトに inputフィールドを追加                                                                                                                                                                                                                              |
 
 ### 組み込み型
 
@@ -286,7 +286,7 @@ The store API facilitates the retrieval of entities that were created or updated
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
 
 ```typescript
-let id = event.transaction.hash // または ID が構築される方法
+let id =event.transaction.hash // または ID が構築される方法
 let transfer = Transfer.loadInBlock(id)
 if (transfer == null) {
   transfer = 新しい転送(id)
@@ -770,44 +770,44 @@ if (value.kind == JSONValueKind.BOOL) {
 
 ### タイプ 変換参照
 
-| Source(s)            | Destination          | Conversion function          |
-| -------------------- | -------------------- | ---------------------------- |
-| Address              | Bytes                | none                         |
-| Address              | String               | s.toHexString()              |
-| BigDecimal           | String               | s.toString()                 |
-| BigInt               | BigDecimal           | s.toBigDecimal()             |
-| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
-| BigInt               | String (unicode)     | s.toString()                 |
-| BigInt               | i32                  | s.toI32()                    |
-| Boolean              | Boolean              | none                         |
-| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
-| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
-| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
-| Bytes                | String (unicode)     | s.toString()                 |
-| Bytes                | String (base58)      | s.toBase58()                 |
-| Bytes                | i32                  | s.toI32()                    |
-| Bytes                | u32                  | s.toU32()                    |
-| Bytes                | JSON                 | json.fromBytes(s)            |
-| int8                 | i32                  | none                         |
-| int32                | i32                  | none                         |
-| int32                | BigInt               | Bigint.fromI32(s)            |
-| uint24               | i32                  | none                         |
-| int64 - int256       | BigInt               | none                         |
-| uint32 - uint256     | BigInt               | none                         |
-| JSON                 | boolean              | s.toBool()                   |
-| JSON                 | i64                  | s.toI64()                    |
-| JSON                 | u64                  | s.toU64()                    |
-| JSON                 | f64                  | s.toF64()                    |
-| JSON                 | BigInt               | s.toBigInt()                 |
-| JSON                 | string               | s.toString()                 |
-| JSON                 | Array                | s.toArray()                  |
-| JSON                 | Object               | s.toObject()                 |
-| String               | Address              | Address.fromString(s)        |
-| Bytes                | Address              | Address.fromString(s)        |
-| String               | BigInt               | BigDecimal.fromString(s)     |
-| String               | BigDecimal           | BigDecimal.fromString(s)     |
-| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
-| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+| Source(s)            | Destination          | Conversion function              |
+| -------------------- | -------------------- | -------------------------------- |
+| Address              | Bytes                | none                             |
+| Address              | String               | s.toHexString()                  |
+| BigDecimal           | String               | s.toString()                     |
+| BigInt               | BigDecimal           | s.toBigDecimal()                 |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex()     |
+| BigInt               | String (unicode)     | s.toString()                     |
+| BigInt               | i32                  | s.toI32()                        |
+| Boolean              | Boolean              | none                             |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)        |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)      |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex()     |
+| Bytes                | String (unicode)     | s.toString()                     |
+| Bytes                | String (base58)      | s.toBase58()                     |
+| Bytes                | i32                  | s.toI32()                        |
+| Bytes                | u32                  | s.toU32()                        |
+| Bytes                | JSON                 | json.fromBytes(s)                |
+| int8                 | i32                  | none                             |
+| int32                | i32                  | none                             |
+| int32                | BigInt               | Bigint.fromI32(s)                |
+| uint24               | i32                  | none                             |
+| int64 - int256       | BigInt               | none                             |
+| uint32 - uint256     | BigInt               | none                             |
+| JSON                 | boolean              | s.toBool()                       |
+| JSON                 | i64                  | s.toI64()                        |
+| JSON                 | u64                  | s.toU64()                        |
+| JSON                 | f64                  | s.toF64()                        |
+| JSON                 | BigInt               | s.toBigInt()                     |
+| JSON                 | string               | s.toString()                     |
+| JSON                 | Array                | s.toArray()                      |
+| JSON                 | Object               | s.toObject()                     |
+| String               | Address              | Address.fromString(s)            |
+| Bytes                | Address              | Address.fromString(s)            |
+| String               | BigInt               | BigDecimal.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)         |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)       |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)            |
 
 ### データソースのメタデータ
 

From 7f1eae9c5a64d6008475f5d81fdcac4811f174e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:17 -0500
Subject: [PATCH 0064/3820] New translations install-the-cli.mdx (Japanese)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/ja/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/ja/developing/creating-a-subgraph/install-the-cli.mdx
index 80ecfac7d53c..9934e852df3a 100644
--- a/website/pages/ja/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/ja/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ ABI ファイルは、契約内容と一致している必要があります。A
 
 ## SpecVersion Releases
 
-| バージョン | リリースノート |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
+| バージョン | リリースノート                                                                                                                                                                  |
+| :---: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+| 0.0.9 | Supports `endBlock` feature                                                                                                                                              |
 | 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+| 0.0.5 | Added support for event handlers having access to transaction receipts.                                                                                                  |
+| 0.0.4 | Added support for managing subgraph features.                                                                                                                            |

From ce09cf54d6cbe83b43ffaec82aeb1bd48059ea3d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:18 -0500
Subject: [PATCH 0065/3820] New translations ql-schema.mdx (Japanese)

---
 .../creating-a-subgraph/ql-schema.mdx         | 62 +++++++++----------
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/website/pages/ja/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/ja/developing/creating-a-subgraph/ql-schema.mdx
index dca410c2b319..17d9779c58f6 100644
--- a/website/pages/ja/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/ja/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| タイプ | 説明書き |
-| --- | --- |
-| `Bytes` | Byte 配列で、16 進数の文字列で表されます。Ethereum のハッシュやアドレスによく使われます。 |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| タイプ          | 説明書き                                                                                                                                                                                                             |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte 配列で、16 進数の文字列で表されます。Ethereum のハッシュやアドレスによく使われます。                                                                                                                                                            |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 
@@ -284,29 +284,29 @@ query {
 サポートされている言語の辞書:
 
 | Code   | 辞書         |
-| ------ | ------------ |
-| simple | General      |
-| da     | Danish       |
-| nl     | Dutch        |
-| en     | English      |
-| fi     | Finnish      |
-| fr     | French       |
-| de     | German       |
-| hu     | Hungarian    |
-| it     | Italian      |
-| no     | Norwegian    |
-| pt     | ポルトガル語 |
-| ro     | Romanian     |
-| ru     | Russian      |
-| es     | Spanish      |
-| sv     | Swedish      |
-| tr     | Turkish      |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | ポルトガル語     |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
 
 ### ランキングアルゴリズム
 
 サポートされている結果の順序付けのアルゴリズム:
 
-| Algorithm     | Description                                                         |
-| ------------- | ------------------------------------------------------------------- |
-| rank          | フルテキストクエリのマッチ品質 (0-1) を使用して結果を並べ替えます。 |
-| proximityRank | Similar to rank but also includes the proximity of the matches.     |
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | フルテキストクエリのマッチ品質 (0-1) を使用して結果を並べ替えます。                                   |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From 89f84e639377ff8b7f96cc104f4869651d136063 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:22 -0500
Subject: [PATCH 0066/3820] New translations unit-testing-framework.mdx
 (Korean)

---
 website/pages/ko/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ko/developing/unit-testing-framework.mdx b/website/pages/ko/developing/unit-testing-framework.mdx
index 553eec2157b3..53a5c43dedcf 100644
--- a/website/pages/ko/developing/unit-testing-framework.mdx
+++ b/website/pages/ko/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ The log output includes the test run duration. Here's an example:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.

From 38c8d5b48fa15525833ceb08672e5ea313ceb23a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:23 -0500
Subject: [PATCH 0067/3820] New translations graphql-api.mdx (Korean)

---
 website/pages/ko/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ko/querying/graphql-api.mdx b/website/pages/ko/querying/graphql-api.mdx
index 3dd70fc7b004..d8671e53a77c 100644
--- a/website/pages/ko/querying/graphql-api.mdx
+++ b/website/pages/ko/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 Fulltext search operators:
 
-| Symbol | Operator | Description |
-| --- | --- | --- |
-| `&` | `And` | For combining multiple search terms into a filter for entities that include all of the provided terms |
-| &#x7c; | `Or` | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
-| `<->` | `Follow by` | Specify the distance between two words. |
-| `:*` | `Prefix` | Use the prefix search term to find words whose prefix match (2 characters required.) |
+| Symbol      | Operator    | Description                                                                                                                          |
+| ----------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| &#x7c;      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->` | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`        | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 
 #### Examples
 

From 2ff66bd276dd42397b13c2dc046740cda1c8ca74 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:25 -0500
Subject: [PATCH 0068/3820] New translations api.mdx (Korean)

---
 website/pages/ko/developing/graph-ts/api.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/ko/developing/graph-ts/api.mdx b/website/pages/ko/developing/graph-ts/api.mdx
index 6a0c4e208b99..8fc1f4b48b61 100644
--- a/website/pages/ko/developing/graph-ts/api.mdx
+++ b/website/pages/ko/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| Version | Release notes |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| Version | Release notes                                                                                                                                                                                                                                 |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### Built-in Types
 

From bddbeb6e2f27c4864ca2dc869474550b23ada7cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:28 -0500
Subject: [PATCH 0069/3820] New translations install-the-cli.mdx (Korean)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/ko/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/ko/developing/creating-a-subgraph/install-the-cli.mdx
index 282c68973a8a..5897ae02b134 100644
--- a/website/pages/ko/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/ko/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The ABI file(s) must match your contract(s). There are a few ways to obtain ABI
 
 ## SpecVersion Releases
 
-| Version | Release notes |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 75aeb0d23802130f21c9e0c9699267499f10f691 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:29 -0500
Subject: [PATCH 0070/3820] New translations ql-schema.mdx (Korean)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/ko/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/ko/developing/creating-a-subgraph/ql-schema.mdx
index 90036d1bfab9..3df39853f82b 100644
--- a/website/pages/ko/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/ko/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Type | Description |
-| --- | --- |
-| `Bytes` | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 

From 42a05310e55ab0087d6df07ad601f5c4bb7ca739 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:33 -0500
Subject: [PATCH 0071/3820] New translations unit-testing-framework.mdx (Dutch)

---
 website/pages/nl/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/nl/developing/unit-testing-framework.mdx b/website/pages/nl/developing/unit-testing-framework.mdx
index 553eec2157b3..53a5c43dedcf 100644
--- a/website/pages/nl/developing/unit-testing-framework.mdx
+++ b/website/pages/nl/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ The log output includes the test run duration. Here's an example:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.

From 94ec26759c5d18d83ea8b4ce2d1a35fc0402587e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:36 -0500
Subject: [PATCH 0072/3820] New translations graphql-api.mdx (Dutch)

---
 website/pages/nl/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/nl/querying/graphql-api.mdx b/website/pages/nl/querying/graphql-api.mdx
index 3dd70fc7b004..d8671e53a77c 100644
--- a/website/pages/nl/querying/graphql-api.mdx
+++ b/website/pages/nl/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 Fulltext search operators:
 
-| Symbol | Operator | Description |
-| --- | --- | --- |
-| `&` | `And` | For combining multiple search terms into a filter for entities that include all of the provided terms |
-| &#x7c; | `Or` | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
-| `<->` | `Follow by` | Specify the distance between two words. |
-| `:*` | `Prefix` | Use the prefix search term to find words whose prefix match (2 characters required.) |
+| Symbol      | Operator    | Description                                                                                                                          |
+| ----------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| &#x7c;      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->` | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`        | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 
 #### Examples
 

From ba384aec54af81cb0f9fc329b96b5a08fcdd30a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:37 -0500
Subject: [PATCH 0073/3820] New translations api.mdx (Dutch)

---
 website/pages/nl/developing/graph-ts/api.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/nl/developing/graph-ts/api.mdx b/website/pages/nl/developing/graph-ts/api.mdx
index 6a0c4e208b99..8fc1f4b48b61 100644
--- a/website/pages/nl/developing/graph-ts/api.mdx
+++ b/website/pages/nl/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| Version | Release notes |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| Version | Release notes                                                                                                                                                                                                                                 |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### Built-in Types
 

From 7b80cf53ea91c638021e3dfa95f3523460c9b37e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:40 -0500
Subject: [PATCH 0074/3820] New translations install-the-cli.mdx (Dutch)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/nl/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/nl/developing/creating-a-subgraph/install-the-cli.mdx
index a23e14babbb2..92a75ed476d9 100644
--- a/website/pages/nl/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/nl/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The ABI file(s) must match your contract(s). There are a few ways to obtain ABI
 
 ## SpecVersion Releases
 
-| Version | Release notes |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 7278a65c92a45cf737d15382531b08ffe0dc2825 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:41 -0500
Subject: [PATCH 0075/3820] New translations ql-schema.mdx (Dutch)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/nl/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/nl/developing/creating-a-subgraph/ql-schema.mdx
index 90036d1bfab9..3df39853f82b 100644
--- a/website/pages/nl/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/nl/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Type | Description |
-| --- | --- |
-| `Bytes` | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 

From f53df5410c2177cfa9fdbcc609b97a5b7a69add6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:45 -0500
Subject: [PATCH 0076/3820] New translations unit-testing-framework.mdx
 (Polish)

---
 website/pages/pl/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/pl/developing/unit-testing-framework.mdx b/website/pages/pl/developing/unit-testing-framework.mdx
index 553eec2157b3..53a5c43dedcf 100644
--- a/website/pages/pl/developing/unit-testing-framework.mdx
+++ b/website/pages/pl/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ The log output includes the test run duration. Here's an example:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.

From 6af4a32cec733433ba9013781244c674ba982b8f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:47 -0500
Subject: [PATCH 0077/3820] New translations graphql-api.mdx (Polish)

---
 website/pages/pl/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/pl/querying/graphql-api.mdx b/website/pages/pl/querying/graphql-api.mdx
index 3dd70fc7b004..d8671e53a77c 100644
--- a/website/pages/pl/querying/graphql-api.mdx
+++ b/website/pages/pl/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 Fulltext search operators:
 
-| Symbol | Operator | Description |
-| --- | --- | --- |
-| `&` | `And` | For combining multiple search terms into a filter for entities that include all of the provided terms |
-| &#x7c; | `Or` | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
-| `<->` | `Follow by` | Specify the distance between two words. |
-| `:*` | `Prefix` | Use the prefix search term to find words whose prefix match (2 characters required.) |
+| Symbol      | Operator    | Description                                                                                                                          |
+| ----------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| &#x7c;      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->` | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`        | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 
 #### Examples
 

From 8cc6f9e1ee6c900834b605117d4746931a0fcc91 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:48 -0500
Subject: [PATCH 0078/3820] New translations api.mdx (Polish)

---
 website/pages/pl/developing/graph-ts/api.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/pl/developing/graph-ts/api.mdx b/website/pages/pl/developing/graph-ts/api.mdx
index 6a0c4e208b99..8fc1f4b48b61 100644
--- a/website/pages/pl/developing/graph-ts/api.mdx
+++ b/website/pages/pl/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| Version | Release notes |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| Version | Release notes                                                                                                                                                                                                                                 |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### Built-in Types
 

From 2c86926c32282dfe154f5696ea0fc9c653b2ff66 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:52 -0500
Subject: [PATCH 0079/3820] New translations install-the-cli.mdx (Polish)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/pl/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/pl/developing/creating-a-subgraph/install-the-cli.mdx
index 37a742e7c78a..5665b2730198 100644
--- a/website/pages/pl/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/pl/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The ABI file(s) must match your contract(s). There are a few ways to obtain ABI
 
 ## SpecVersion Releases
 
-| Version | Release notes |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 1dc2adb1bfc9e717bba816b091560b130f432bf9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:53 -0500
Subject: [PATCH 0080/3820] New translations ql-schema.mdx (Polish)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/pl/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/pl/developing/creating-a-subgraph/ql-schema.mdx
index 90036d1bfab9..3df39853f82b 100644
--- a/website/pages/pl/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/pl/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Type | Description |
-| --- | --- |
-| `Bytes` | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 

From 64259b94000382e00b0c1d51977f3e7a42943bac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:57 -0500
Subject: [PATCH 0081/3820] New translations unit-testing-framework.mdx
 (Portuguese)

---
 .../pages/pt/developing/unit-testing-framework.mdx   | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/pt/developing/unit-testing-framework.mdx b/website/pages/pt/developing/unit-testing-framework.mdx
index 68acc7e892b9..c2c04c318f4f 100644
--- a/website/pages/pt/developing/unit-testing-framework.mdx
+++ b/website/pages/pt/developing/unit-testing-framework.mdx
@@ -1112,7 +1112,7 @@ test('ethereum/contract dataSource creation example', () => {
   assert.dataSourceCount('GraphTokenLockWallet', 0)
 
   // Crie uma nova fonte de dados GraphTokenLockWallet com o endereço
-  0xa16081f360e3847006db660bae1c6d1b2e17ec2a
+  0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
   GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
 
   // Garanta que a dataSource foi criada
@@ -1381,15 +1381,15 @@ A saída do log inclui a duração do teste. Veja um exemplo:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > `ERROR TS2554: Expected ? arguments, but got ?.`
->
+> 
 > `return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);`
->
+> 
 > `in ~lib/matchstick-as/assembly/defaults.ts(18,12)`
->
+> 
 > `ERROR TS2554: Expected ? arguments, but got ?.`
->
+> 
 > `return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);`
->
+> 
 > `in ~lib/matchstick-as/assembly/defaults.ts(24,12)`
 
 A diferença nos argumentos é causada pela diferença no `graph-ts` e no `matchstick-as`. Problemas como este são melhor resolvidos ao atualizar tudo para a versão mais recente.

From e75a9bc502ae2dab692b66fbe33fcfffff9cf44d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:57:58 -0500
Subject: [PATCH 0082/3820] New translations graphql-api.mdx (Portuguese)

---
 website/pages/pt/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/pt/querying/graphql-api.mdx b/website/pages/pt/querying/graphql-api.mdx
index 1a7a109cdaaf..4f64d26bf2a2 100644
--- a/website/pages/pt/querying/graphql-api.mdx
+++ b/website/pages/pt/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Açúcar sintático**: pode simplificar a consulta acima ao retirar o operador `and`, com o passe de uma subexpressão separada por vírgulas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Buscas fulltext têm um campo obrigatório, `text`, para ofertar termos de busca
 
 Operadores de busca fulltext:
 
-| Símbolo | Operador | Descrição |
-| --- | --- | --- |
-| `&` | `And` | Para combinar múltiplos termos de busca num filtro para entidades que incluem todos os termos fornecidos |
-| &#x7c; | `Or` | Consultas com vários termos de busca separados pelo operador `or` retornarão todas as entidades com uma correspondência de qualquer termo providenciado |
-| `<->` | `Follow by` | Especifica a distância entre duas palavras. |
-| `:*` | `Prefix` | Use o prefixo para encontrar palavras que correspondem a tal prefixo (2 caracteres necessários.) |
+| Símbolo     | Operador    | Descrição                                                                                                                                               |
+| ----------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`     | `And`       | Para combinar múltiplos termos de busca num filtro para entidades que incluem todos os termos fornecidos                                                |
+| &#x7c;      | `Or`        | Consultas com vários termos de busca separados pelo operador `or` retornarão todas as entidades com uma correspondência de qualquer termo providenciado |
+| `<->` | `Follow by` | Especifica a distância entre duas palavras.                                                                                                             |
+| `:*`        | `Prefix`    | Use o prefixo para encontrar palavras que correspondem a tal prefixo (2 caracteres necessários.)                                                        |
 
 #### Exemplos
 

From 13cca378491254163a13073a8b8b960a2b620879 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:00 -0500
Subject: [PATCH 0083/3820] New translations api.mdx (Portuguese)

---
 website/pages/pt/developing/graph-ts/api.mdx | 99 ++++++++++----------
 1 file changed, 50 insertions(+), 49 deletions(-)

diff --git a/website/pages/pt/developing/graph-ts/api.mdx b/website/pages/pt/developing/graph-ts/api.mdx
index 0705480c4f03..acc557d643ab 100644
--- a/website/pages/pt/developing/graph-ts/api.mdx
+++ b/website/pages/pt/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ A biblioteca `@graphprotocol/graph-ts` fornece as seguintes APIs:
 
 No manifest do subgraph, `apiVersion` especifica a versão da API de mapeamento, executada pelo Graph Node para um subgraph.
 
-| Versão | Notas de atualização |
-| :-: | --- |
-| 0.0.9 | Adiciona novas funções de host [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adiciona validação para existência de campos no schema ao salvar uma entidade. |
-| 0.0.7 | Classes `TransactionReceipt` e `Log` adicionadas aos tipos do EthereumCampo <br />Campo `receipt` adicionado ao objeto Ethereum Event |
-| 0.0.6 | Campo `nonce` adicionado ao objeto Ethereum TransactionCampo <br />`baseFeePerGas` adicionado ao objeto Ethereum Block |
-| 0.0.5 | AssemblyScript atualizado à versão 0.19.10 (inclui mudanças recentes, favor ler o [`Guia de Migração`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renomeado para `ethereum.transaction.gasLimit` |
-| 0.0.4 | Campo `functionSignature` adicionado ao objeto Ethereum SmartContractCall |
-| 0.0.3 | Campo `from` adicionado ao objeto Ethereum<br /> `Calletherem.call.address` renomeado para `ethereum.call.to` |
-| 0.0.2 | Campo `input` adicionado ao objeto Ethereum Transaction |
+| Versão | Notas de atualização                                                                                                                                                                                                                      |
+| :----: | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9 | Adiciona novas funções de host [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                       |
+|  0.0.8 | Adiciona validação para existência de campos no schema ao salvar uma entidade.                                                                                                                                                            |
+|  0.0.7 | Classes `TransactionReceipt` e `Log` adicionadas aos tipos do EthereumCampo <br />Campo `receipt` adicionado ao objeto Ethereum Event                                                                                                     |
+|  0.0.6 | Campo `nonce` adicionado ao objeto Ethereum TransactionCampo <br />`baseFeePerGas` adicionado ao objeto Ethereum Block                                                                                                                    |
+|  0.0.5 | AssemblyScript atualizado à versão 0.19.10 (inclui mudanças recentes, favor ler o [`Guia de Migração`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renomeado para `ethereum.transaction.gasLimit` |
+|  0.0.4 | Campo `functionSignature` adicionado ao objeto Ethereum SmartContractCall                                                                                                                                                                 |
+|  0.0.3 | Campo `from` adicionado ao objeto Ethereum<br /> `Calletherem.call.address` renomeado para `ethereum.call.to`                                                                                                                             |
+|  0.0.2 | Campo `input` adicionado ao objeto Ethereum Transaction                                                                                                                                                                                   |
 
 ### Tipos Embutidos
 
@@ -166,7 +166,8 @@ _Matemática_
 import { TypedMap } from '@graphprotocol/graph-ts'
 ```
 
-O `TypedMap` pode servir para armazenar pares de chave e valor (key e value ). Confira [este exemplo](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+O `TypedMap` pode servir para armazenar pares de chave e valor (key e value
+). Confira [este exemplo](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
 
 A classe `TypedMap` tem a seguinte API:
 
@@ -770,44 +771,44 @@ Quando o tipo de um valor é confirmado, ele pode ser convertido num [tipo embut
 
 ### Referência de Conversões de Tipos
 
-| Fonte(s)             | Destino              | Função de conversão          |
-| -------------------- | -------------------- | ---------------------------- |
-| Address              | Bytes                | nenhum                       |
-| Address              | String               | s.toHexString()              |
-| BigDecimal           | String               | s.toString()                 |
-| BigInt               | BigDecimal           | s.toBigDecimal()             |
-| BigInt               | String (hexadecimal) | s.toHexString() ou s.toHex() |
-| BigInt               | String (unicode)     | s.toString()                 |
-| BigInt               | i32                  | s.toI32()                    |
-| Boolean              | Boolean              | nenhum                       |
-| Bytes (assinado)     | BigInt               | BigInt.fromSignedBytes(s)    |
-| Bytes (não assinado) | BigInt               | BigInt.fromUnsignedBytes(s)  |
-| Bytes                | String (hexadecimal) | s.toHexString() ou s.toHex() |
-| Bytes                | String (unicode)     | s.toString()                 |
-| Bytes                | String (base58)      | s.toBase58()                 |
-| Bytes                | i32                  | s.toI32()                    |
-| Bytes                | u32                  | s.toU32()                    |
-| Bytes                | JSON                 | json.fromBytes(s)            |
-| int8                 | i32                  | nenhum                       |
-| int32                | i32                  | nenhum                       |
-| int32                | BigInt               | BigInt.fromI32(s)            |
-| uint24               | i32                  | nenhum                       |
-| int64 - int256       | BigInt               | nenhum                       |
-| uint32 - uint256     | BigInt               | nenhum                       |
-| JSON                 | boolean              | s.toBool()                   |
-| JSON                 | i64                  | s.toI64()                    |
-| JSON                 | u64                  | s.toU64()                    |
-| JSON                 | f64                  | s.toF64()                    |
-| JSON                 | BigInt               | s.toBigInt()                 |
-| JSON                 | string               | s.toString()                 |
-| JSON                 | Array                | s.toArray()                  |
-| JSON                 | Object               | s.toObject()                 |
-| String               | Address              | Address.fromString(s)        |
-| Bytes                | Address              | Address.fromBytes(s)         |
-| String               | BigInt               | BigInt.fromString(s)         |
-| String               | BigDecimal           | BigDecimal.fromString(s)     |
-| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
-| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+| Fonte(s)                 | Destino              | Função de conversão            |
+| ------------------------ | -------------------- | ------------------------------ |
+| Address                  | Bytes                | nenhum                         |
+| Address                  | String               | s.toHexString()                |
+| BigDecimal               | String               | s.toString()                   |
+| BigInt                   | BigDecimal           | s.toBigDecimal()               |
+| BigInt                   | String (hexadecimal) | s.toHexString() ou s.toHex()   |
+| BigInt                   | String (unicode)     | s.toString()                   |
+| BigInt                   | i32                  | s.toI32()                      |
+| Boolean                  | Boolean              | nenhum                         |
+| Bytes (assinado)         | BigInt               | BigInt.fromSignedBytes(s)      |
+| Bytes (não assinado)     | BigInt               | BigInt.fromUnsignedBytes(s)    |
+| Bytes                    | String (hexadecimal) | s.toHexString() ou s.toHex()   |
+| Bytes                    | String (unicode)     | s.toString()                   |
+| Bytes                    | String (base58)      | s.toBase58()                   |
+| Bytes                    | i32                  | s.toI32()                      |
+| Bytes                    | u32                  | s.toU32()                      |
+| Bytes                    | JSON                 | json.fromBytes(s)              |
+| int8                     | i32                  | nenhum                         |
+| int32                    | i32                  | nenhum                         |
+| int32                    | BigInt               | BigInt.fromI32(s)              |
+| uint24                   | i32                  | nenhum                         |
+| int64 - int256           | BigInt               | nenhum                         |
+| uint32 - uint256         | BigInt               | nenhum                         |
+| JSON                     | boolean              | s.toBool()                     |
+| JSON                     | i64                  | s.toI64()                      |
+| JSON                     | u64                  | s.toU64()                      |
+| JSON                     | f64                  | s.toF64()                      |
+| JSON                     | BigInt               | s.toBigInt()                   |
+| JSON                     | string               | s.toString()                   |
+| JSON                     | Array                | s.toArray()                    |
+| JSON                     | Object               | s.toObject()                   |
+| String                   | Address              | Address.fromString(s)          |
+| Bytes                    | Address              | Address.fromBytes(s)           |
+| String                   | BigInt               | BigInt.fromString(s)           |
+| String                   | BigDecimal           | BigDecimal.fromString(s)       |
+| String (hexadecimal)     | Bytes                | ByteArray.fromHexString(s)     |
+| String (UTF-8)           | Bytes                | ByteArray.fromUTF8(s)          |
 
 ### Metadados de Fontes de Dados
 

From d69c7eed1bb1e84dcebb8d709c103b87f81b4ff7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:03 -0500
Subject: [PATCH 0084/3820] New translations advanced.mdx (Portuguese)

---
 website/pages/pt/developing/creating-a-subgraph/advanced.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pt/developing/creating-a-subgraph/advanced.mdx b/website/pages/pt/developing/creating-a-subgraph/advanced.mdx
index a46badf10977..4daa3301d866 100644
--- a/website/pages/pt/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/pt/developing/creating-a-subgraph/advanced.mdx
@@ -545,11 +545,11 @@ Como o enxerto copia em vez de indexar dados base, dirigir o subgraph para o blo
 O subgraph enxertado pode usar um schema GraphQL que não é idêntico ao schema do subgraph base, mas é apenas compatível com ele. Ele deve ser um schema válido no seu próprio mérito, mas pode desviar do schema do subgraph base nas seguintes maneiras:
 
 - Ele adiciona ou remove tipos de entidade
-- Ele retira atributos de tipos de identidade
+- Ele retira atributos de tipos de entidade
 - Ele adiciona atributos anuláveis a tipos de entidade
 - Ele transforma atributos não anuláveis em atributos anuláveis
 - Ele adiciona valores a enums
 - Ele adiciona ou remove interfaces
-- Ele muda para quais tipos de entidades uma interface é implementada
+- Ele muda os tipos de entidades para qual implementar uma interface
 
 > **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From c621f24d4d9c1d67a8b193371d93fff8604bd830 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:05 -0500
Subject: [PATCH 0085/3820] New translations install-the-cli.mdx (Portuguese)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/pt/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/pt/developing/creating-a-subgraph/install-the-cli.mdx
index 5a1bf2c57245..aa88b936bbf8 100644
--- a/website/pages/pt/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/pt/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ Os arquivos da ABI devem combinar com o(s) seu(s) contrato(s). Há algumas manei
 
 ## SpecVersion Releases
 
-| Versão | Notas de atualização |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Adicionado apoio a handlers de eventos com acesso a recibos de transação. |
-| 0.0.4 | Adicionado apoio à gestão de recursos de subgraph. |
+| Versão | Notas de atualização                                                                                                                                                     |
+| :----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9 | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5 | Adicionado apoio a handlers de eventos com acesso a recibos de transação.                                                                                                |
+|  0.0.4 | Adicionado apoio à gestão de recursos de subgraph.                                                                                                                       |

From b81d4193f467ac67cc7ab1528afa3230a5e9fb7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:06 -0500
Subject: [PATCH 0086/3820] New translations ql-schema.mdx (Portuguese)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/pt/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/pt/developing/creating-a-subgraph/ql-schema.mdx
index a1518a96b957..592372b0de60 100644
--- a/website/pages/pt/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/pt/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Tipo | Descrição |
-| --- | --- |
-| `Bytes` | Arranjo de bytes, representado como string hexadecimal. Usado frequentemente por hashes e endereços no Ethereum. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Tipo         | Descrição                                                                                                                                                                                                        |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Arranjo de bytes, representado como string hexadecimal. Usado frequentemente por hashes e endereços no Ethereum.                                                                                                 |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 

From 39874ba5a6619e0ccdf43c22e47449d9a9f7c98e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:10 -0500
Subject: [PATCH 0087/3820] New translations transfer-to-the-graph.mdx
 (Russian)

---
 website/pages/ru/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/cookbook/transfer-to-the-graph.mdx b/website/pages/ru/cookbook/transfer-to-the-graph.mdx
index d44d0e63c45f..4c003ddfd40d 100644
--- a/website/pages/ru/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/ru/cookbook/transfer-to-the-graph.mdx
@@ -98,7 +98,7 @@ You can create API Keys in Subgraph Studio under the “API Keys” menu at the
 
 Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
 
-### Дополнительные источники
+### Дополнительные ресурсы
 
 - To quickly create and publish a new subgraph, check out the [Quick Start](/quick-start/).
 - To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From cb28d5484e5fce685e8dc22bd116b5bbaf2383ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:12 -0500
Subject: [PATCH 0088/3820] New translations advanced.mdx (Russian)

---
 .../ru/developing/creating-a-subgraph/advanced.mdx     | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ru/developing/creating-a-subgraph/advanced.mdx b/website/pages/ru/developing/creating-a-subgraph/advanced.mdx
index 63fdffd404df..63e6cc3abed1 100644
--- a/website/pages/ru/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/ru/developing/creating-a-subgraph/advanced.mdx
@@ -87,7 +87,7 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
-## Неисправимые ошибки
+## Нефатальные ошибки
 
 Ошибки индексирования в уже синхронизированных субграфах по умолчанию приведут к сбою субграфа и прекращению синхронизации. В качестве альтернативы субграфы можно настроить на продолжение синхронизации при наличии ошибок, игнорируя изменения, внесенные обработчиком, который спровоцировал ошибку. Это дает авторам субграфов время на исправление своих субграфов, в то время как запросы к последнему блоку продолжают обрабатываться, хотя результаты могут быть противоречивыми из-за бага, вызвавшего ошибку. Обратите внимание на то, что некоторые ошибки всё равно всегда будут фатальны. Чтобы быть нефатальной, ошибка должна быть детерминированной.
 
@@ -542,14 +542,14 @@ When a subgraph whose manifest contains a `graft` block is deployed, Graph Node
 
 Поскольку графтинг копирует, а не индексирует базовые данные, гораздо быстрее перенести субграф в нужный блок, чем индексировать с нуля, хотя для очень больших субграфов копирование исходных данных может занять несколько часов. Пока графтовый субграф инициализируется, узел The Graph будет регистрировать информацию о типах объектов, которые уже были скопированы.
 
-Графтовый субграф может использовать схему GraphQL, которая не идентична схеме базового субграфа, а просто совместима с ней. Она сама по себе должна быть допустимой схемой субграфа, но может отличаться от схемы базового субграфа следующими способами:
+Перенесённый субграф может использовать схему GraphQL, которая не идентична схеме базового субграфа, а просто совместима с ней. Это должна быть автономно действующая схема субграфа, но она может отличаться от схемы базового субграфа следующим образом:
 
 - Она добавляет или удаляет типы объектов
 - Она удаляет атрибуты из типов объектов
-- Она добавляет в типы объектов атрибуты с возможностью обнуления
-- Она превращает ненулевые атрибуты в нулевые
+- Она добавляет обнуляемые атрибуты к типам объектов
+- Она превращает необнуляемые атрибуты в обнуляемые
 - Она добавляет значения в перечисления
 - Она добавляет или удаляет интерфейсы
-- Она изменяется в зависимости от того, для каких типов объектов реализован тот или иной интерфейс
+- Она изменяется в зависимости от того, под какой тип объектов реализован интерфейс
 
 > **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 988476240cba85415628795177bd24d18a61680f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:13 -0500
Subject: [PATCH 0089/3820] New translations install-the-cli.mdx (Russian)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/ru/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/ru/developing/creating-a-subgraph/install-the-cli.mdx
index 69757f55a845..bb6722d19f5e 100644
--- a/website/pages/ru/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/ru/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is
 
 ## Релизы SpecVersion
 
-| Версия | Примечания к релизу |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Добавлена поддержка обработчиков событий, имеющих доступ к чекам транзакций. |
-| 0.0.4 | Добавлена ​​поддержка управления функциями субграфа. |
+| Версия | Примечания к релизу                                                                                                                                                      |
+| :----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9 | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5 | Добавлена поддержка обработчиков событий, имеющих доступ к чекам транзакций.                                                                                             |
+|  0.0.4 | Добавлена ​​поддержка управления функциями субграфа.                                                                                                                     |

From d599be73620043e8e579eb36e0ee41c95f1269f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:15 -0500
Subject: [PATCH 0090/3820] New translations ql-schema.mdx (Russian)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/ru/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/ru/developing/creating-a-subgraph/ql-schema.mdx
index 687ed4af4826..0fe26c115582 100644
--- a/website/pages/ru/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/ru/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 В API GraphQL поддерживаются следующие скаляры:
 
-| Тип | Описание |
-| --- | --- |
-| `Bytes` | Массив байтов, представленный в виде шестнадцатеричной строки. Обычно используется для хэшей и адресов Ethereum. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Тип          | Описание                                                                                                                                                                                                         |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Массив байтов, представленный в виде шестнадцатеричной строки. Обычно используется для хэшей и адресов Ethereum.                                                                                                 |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Перечисления
 

From 0f5b8ef6fc95d09d86d1cad80380955dbcc7fd49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:19 -0500
Subject: [PATCH 0091/3820] New translations unit-testing-framework.mdx
 (Swedish)

---
 .../pages/sv/developing/unit-testing-framework.mdx   | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/sv/developing/unit-testing-framework.mdx b/website/pages/sv/developing/unit-testing-framework.mdx
index 1835214d90f8..03affcca6484 100644
--- a/website/pages/sv/developing/unit-testing-framework.mdx
+++ b/website/pages/sv/developing/unit-testing-framework.mdx
@@ -61,7 +61,7 @@ eller
 <PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
 ```
 
-Se till att du använder en nyare version av Node.js eftersom graph-cli inte längre stöder **v10.19.0**, och det är fortfarande standardversionen för nya Ubuntu-bilder på WSL. Till exempel är Matchstick bekräftat fungerande på WSL med **v18.1.0**. Du kan byta till den antingen via** nvm ** eller genom att uppdatera din globala Node.js. Glöm inte att ta bort `node_modules` och köra `npm install`igen efter att du har uppdaterat Node.js! Sedan, se till att du har **libpq** installerat, du kan göra det genom att köra
+Se till att du använder en nyare version av Node.js eftersom graph-cli inte längre stöder **v10.19.0**, och det är fortfarande standardversionen för nya Ubuntu-bilder på WSL. Till exempel är Matchstick bekräftat fungerande på WSL med **v18.1.0**. Du kan byta till den antingen via** nvm ** eller genom att uppdatera din globala Node.js. Glöm inte att ta bort `node_modules` och köra ` npm install `igen efter att du har uppdaterat Node.js! Sedan, se till att du har **libpq** installerat, du kan göra det genom att köra
 
 ```
 sudo apt-get install libpq-dev
@@ -1380,15 +1380,15 @@ Loggutmatningen innehåller testkörningens varaktighet. Här är ett exempel:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 Motsägelsen i argumenten beror på en motsägelse i `graph-ts` och `matchstick-as`. Det bästa sättet att åtgärda problem som detta är att uppdatera allt till den senaste utgivna versionen.

From 1ed1c35d64ece9d92da238e5ddc1a36340d8a49d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:20 -0500
Subject: [PATCH 0092/3820] New translations graphql-api.mdx (Swedish)

---
 website/pages/sv/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/sv/querying/graphql-api.mdx b/website/pages/sv/querying/graphql-api.mdx
index 06f0568d0e53..89b541abf5eb 100644
--- a/website/pages/sv/querying/graphql-api.mdx
+++ b/website/pages/sv/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** Du kan förenkla ovanstående fråga genom att ta bort `and`-operatorn och istället skicka ett underuttryck separerat med kommatecken.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltextsökförfrågningar har ett obligatoriskt fält, `text`, för att tillha
 
 Fulltextsökoperatorer:
 
-| Symbol | Operatör | Beskrivning |
-| --- | --- | --- |
-| `&` | `Och` | För att kombinera flera söktermer till ett filter för entiteter som inkluderar alla de angivna termerna |
-| &#x7c; | `Eller` | Förfrågningar med flera söktermer separerade av ellipsen kommer att returnera alla entiteter med en matchning från någon av de angivna termerna |
-| `<->` | `Följs av` | Ange avståndet mellan två ord. |
-| `:*` | `Prefix` | Använd prefixsöktermen för att hitta ord vars prefix matchar (2 tecken krävs.) |
+| Symbol      | Operatör   | Beskrivning                                                                                                                                     |
+| ----------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`     | `Och`      | För att kombinera flera söktermer till ett filter för entiteter som inkluderar alla de angivna termerna                                         |
+| &#x7c;      | `Eller`    | Förfrågningar med flera söktermer separerade av ellipsen kommer att returnera alla entiteter med en matchning från någon av de angivna termerna |
+| `<->` | `Följs av` | Ange avståndet mellan två ord.                                                                                                                  |
+| `:*`        | `Prefix`   | Använd prefixsöktermen för att hitta ord vars prefix matchar (2 tecken krävs.)                                                                  |
 
 #### Exempel
 

From ee03f97edeb31832897ac41c1485e83c56b41960 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:22 -0500
Subject: [PATCH 0093/3820] New translations api.mdx (Swedish)

---
 website/pages/sv/developing/graph-ts/api.mdx | 164 ++++++++++---------
 1 file changed, 87 insertions(+), 77 deletions(-)

diff --git a/website/pages/sv/developing/graph-ts/api.mdx b/website/pages/sv/developing/graph-ts/api.mdx
index 9fb6713242bf..2dbb19d8f5cf 100644
--- a/website/pages/sv/developing/graph-ts/api.mdx
+++ b/website/pages/sv/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| Version | Versionsanteckningar |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| Version | Versionsanteckningar                                                                                                                                                                                                                          |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### Inbyggda typer
 
@@ -163,7 +163,7 @@ _Math_
 #### TypedMap
 
 ```typescript
-import { TypedMap } from '@graphprotocol/graph-ts'
+import { TypedMap } from "@graphprotocol/graph-ts";
 ```
 
 `TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
@@ -179,7 +179,7 @@ The `TypedMap` class has the following API:
 #### Bytes
 
 ```typescript
-import { Bytes } from '@graphprotocol/graph-ts'
+import { Bytes } from "@graphprotocol/graph-ts";
 ```
 
 `Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
@@ -205,7 +205,7 @@ _Operators_
 #### Address
 
 ```typescript
-import { Address } from '@graphprotocol/graph-ts'
+import { Address } from "@graphprotocol/graph-ts";
 ```
 
 `Address` extends `Bytes` to represent Ethereum `address` values.
@@ -218,7 +218,7 @@ It adds the following method on top of the `Bytes` API:
 ### Store API
 
 ```typescript
-import { store } from '@graphprotocol/graph-ts'
+import { store } from "@graphprotocol/graph-ts";
 ```
 
 The `store` API allows to load, save and remove entities from and to the Graph Node store.
@@ -231,24 +231,24 @@ Följande är ett vanligt mönster för att skapa entiteter från Ethereum-händ
 
 ```typescript
 // Importera händelseklassen Transfer som genererats från ERC20 ABI
-import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+import { Transfer as TransferEvent } from "../generated/ERC20/ERC20";
 
 // Importera entitetstypen Transfer som genererats från GraphQL-schemat
-import { Transfer } from '../generated/schema'
+import { Transfer } from "../generated/schema";
 
 // Händelsehanterare för överföring
 export function handleTransfer(event: TransferEvent): void {
   // Skapa en Transfer-entitet, med transaktionshash som enhets-ID
-  let id = event.transaction.hash
-  let transfer = new Transfer(id)
+  let id = event.transaction.hash;
+  let transfer = new Transfer(id);
 
   // Ange egenskaper för entiteten med hjälp av händelseparametrarna
-  transfer.from = event.params.from
-  transfer.to = event.params.to
-  transfer.amount = event.params.amount
+  transfer.from = event.params.from;
+  transfer.to = event.params.to;
+  transfer.amount = event.params.amount;
 
   // Spara entiteten till lagret
-  transfer.save()
+  transfer.save();
 }
 ```
 
@@ -263,10 +263,10 @@ Each entity must have a unique ID to avoid collisions with other entities. It is
 Om en entitet redan finns kan den laddas från lagret med följande:
 
 ```typescript
-let id = event.transaction.hash // eller hur ID konstrueras
-let transfer = Transfer.load(id)
+let id = event.transaction.hash; // eller hur ID konstrueras
+let transfer = Transfer.load(id);
 if (transfer == null) {
-  transfer = new Transfer(id)
+  transfer = new Transfer(id);
 }
 
 // Använd överföringsenheten som tidigare
@@ -286,10 +286,10 @@ The store API facilitates the retrieval of entities that were created or updated
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
 
 ```typescript
-let id = event.transaction.hash // eller hur ID konstrueras
-let transfer = Transfer.loadInBlock(id)
+let id = event.transaction.hash; // eller hur ID konstrueras
+let transfer = Transfer.loadInBlock(id);
 if (transfer == null) {
-  transfer = new Transfer(id)
+  transfer = new Transfer(id);
 }
 
 // Använd överföringsenheten som tidigare
@@ -343,7 +343,7 @@ transfer.amount = ...
 Det är också möjligt att avaktivera egenskaper med en av följande två instruktioner:
 
 ```typescript
-transfer.from.unset()
+transfer.from.unset();
 transfer.from = null
 ```
 
@@ -353,14 +353,14 @@ Updating array properties is a little more involved, as the getting an array fro
 
 ```typescript
 // Detta kommer inte att fungera
-entity.numbers.push(BigInt.fromI32(1))
-entity.save()
+entity.numbers.push(BigInt.fromI32(1));
+entity.save();
 
 // Detta kommer att fungera
-let numbers = entity.numbers
-numbers.push(BigInt.fromI32(1))
-entity.numbers = numbers
-entity.save()
+let numbers = entity.numbers;
+numbers.push(BigInt.fromI32(1));
+entity.numbers = numbers;
+entity.save();
 ```
 
 #### Ta bort entiteter från lagret
@@ -398,12 +398,12 @@ type Transfer @entity {
 and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
 
 ```typescript
-let id = event.transaction.hash
-let transfer = new Transfer(id)
-transfer.from = event.params.from
-transfer.to = event.params.to
-transfer.amount = event.params.amount
-transfer.save()
+let id = event.transaction.hash;
+let transfer = new Transfer(id);
+transfer.from = event.params.from;
+transfer.to = event.params.to;
+transfer.amount = event.params.amount;
+transfer.save();
 ```
 
 #### Händelser och Block/Transaktionsdata
@@ -489,16 +489,19 @@ En vanlig mönster är att komma åt kontraktet från vilket en händelse härst
 
 ```typescript
 // Importera den genererade kontraktsklassen och den genererade klassen för överföringshändelser
-import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+import {
+  ERC20Contract,
+  Transfer as TransferEvent,
+} from "../generated/ERC20Contract/ERC20Contract";
 // Importera den genererade entitetsklassen
-import { Transfer } from '../generated/schema'
+import { Transfer } from "../generated/schema";
 
 export function handleTransfer(event: TransferEvent) {
   // Bind kontraktet till den adress som skickade händelsen
-  let contract = ERC20Contract.bind(event.address)
+  let contract = ERC20Contract.bind(event.address);
 
   // Åtkomst till tillståndsvariabler och funktioner genom att anropa dem
-  let erc20Symbol = contract.symbol()
+  let erc20Symbol = contract.symbol();
 }
 ```
 
@@ -515,12 +518,12 @@ If the read-only methods of your contract may revert, then you should handle tha
 - For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
 
 ```typescript
-let gravitera = gravitera.bind(event.address)
-let callResult = gravitera_gravatarToOwner(gravatar)
+let gravitera = gravitera.bind(event.address);
+let callResult = gravitera_gravatarToOwner(gravatar);
 if (callResult.reverted) {
-  log.info('getGravatar reverted', [])
+  log.info("getGravatar reverted", []);
 } else {
-  let owner = callResult.value
+  let owner = callResult.value;
 }
 ```
 
@@ -579,7 +582,7 @@ let isContract = ethereum.hasCode(eoa).inner // returns false
 ### API för loggning
 
 ```typescript
-import { log } from '@graphprotocol/graph-ts'
+import { log } from "@graphprotocol/graph-ts";
 ```
 
 The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
@@ -595,7 +598,11 @@ The `log` API includes the following functions:
 The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
 
 ```typescript
-log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+log.info("Message to be displayed: {}, {}, {}", [
+  value.toString(),
+  anotherValue.toString(),
+  "already a string",
+]);
 ```
 
 #### Loggning av ett eller flera värden
@@ -618,11 +625,11 @@ export function handleSomeEvent(event: SomeEvent): void {
 I exemplet nedan loggas endast det första värdet i argument arrayen, trots att arrayen innehåller tre värden.
 
 ```typescript
-let myArray = ['A', 'B', 'C']
+let myArray = ["A", "B", "C"];
 
 export function handleSomeEvent(event: SomeEvent): void {
   // Visar : "Mitt värde är: A" (Även om tre värden skickas till `log.info`)
-  log.info('Mitt värde är: {}', myArray)
+  log.info("Mitt värde är: {}", myArray);
 }
 ```
 
@@ -631,11 +638,14 @@ export function handleSomeEvent(event: SomeEvent): void {
 Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
 
 ```typescript
-let myArray = ['A', 'B', 'C']
+let myArray = ["A", "B", "C"];
 
 export function handleSomeEvent(event: SomeEvent): void {
   // Visar: "Mitt första värde är: A, andra värdet är: B, tredje värdet är: C"
-  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+  log.info(
+    "My first value is: {}, second value is: {}, third value is: {}",
+    myArray
+  );
 }
 ```
 
@@ -646,7 +656,7 @@ För att visa ett specifikt värde i arrayen måste det indexeras och tillhandah
 ```typescript
 export function handleSomeEvent(event: SomeEvent): void {
   // Visar : "Mitt tredje värde är C"
-  log.info('My third value is: {}', [myArray[2]])
+  log.info("My third value is: {}", [myArray[2]]);
 }
 ```
 
@@ -655,21 +665,21 @@ export function handleSomeEvent(event: SomeEvent): void {
 I exemplet nedan loggas blocknummer, blockhash och transaktionshash från en händelse:
 
 ```typescript
-import { log } from '@graphprotocol/graph-ts'
+import { log } from "@graphprotocol/graph-ts";
 
 export function handleSomeEvent(event: SomeEvent): void {
-  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+  log.debug("Block number: {}, block hash: {}, transaction hash: {}", [
     event.block.number.toString(), // "47596000"
     event.block.hash.toHexString(), // "0x..."
     event.transaction.hash.toHexString(), // "0x..."
-  ])
+  ]);
 }
 ```
 
 ### IPFS API
 
 ```typescript
-import { ipfs } from '@graphprotocol/graph-ts'
+import { ipfs } from "@graphprotocol/graph-ts"
 ```
 
 Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
@@ -678,13 +688,13 @@ För att läsa en fil från IPFS med en given IPFS-hash eller sökväg görs fö
 
 ```typescript
 // Placera detta i en händelsehanterare i mappningen
-let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
-let data = ipfs.cat(hash)
+let hash = "QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D";
+let data = ipfs.cat(hash);
 
 // Sökvägar som `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
 // som inkluderar filer i kataloger stöds också
-let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
-let data = ipfs.cat(path)
+let path = "QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile";
+let data = ipfs.cat(path);
 ```
 
 **Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
@@ -692,31 +702,31 @@ let data = ipfs.cat(path)
 It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
 
 ```typescript
-import { JSONValue, Value } from '@graphprotocol/graph-ts'
+import { JSONValue, Value } from "@graphprotocol/graph-ts";
 
 export function processItem(value: JSONValue, userData: Value): void {
   // Se JSONValue-dokumentationen för mer information om hur man hanterar
   // med JSON-värden
-  let obj = value.toObject()
-  let id = obj.get('id')
-  let title = obj.get('title')
+  let obj = value.toObject();
+  let id = obj.get("id");
+  let title = obj.get("title");
 
   if (!id || !title) {
-    return
+    return;
   }
 
   // Callbacks kan också skapa enheter
-  let newItem = new Item(id)
-  newItem.title = title.toString()
-  newitem.parent = userData.toString() // Ange parent till "parentId"
-  newitem.save()
+  let newItem = new Item(id);
+  newItem.title = title.toString();
+  newitem.parent = userData.toString(); // Ange parent till "parentId"
+  newitem.save();
 }
 
 // Placera detta i en händelsehanterare i mappningen
-ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+ipfs.map("Qm...", "processItem", Value.fromString("parentId"), ["json"]);
 
 // Alternativt kan du använda `ipfs.mapJSON`.
-ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+ipfs.mapJSON("Qm...", "processItem", Value.fromString("parentId"));
 ```
 
 The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
@@ -726,7 +736,7 @@ On success, `ipfs.map` returns `void`. If any invocation of the callback causes
 ### Crypto API
 
 ```typescript
-import { crypto } from '@graphprotocol/graph-ts'
+import { crypto } from "@graphprotocol/graph-ts";
 ```
 
 The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
@@ -736,7 +746,7 @@ The `crypto` API makes a cryptographic functions available for use in mappings.
 ### JSON API
 
 ```typescript
-import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+import { json, JSONValueKind } from "@graphprotocol/graph-ts"
 ```
 
 JSON data can be parsed using the `json` API:

From ca03948eae81dadbce0b4e8e7d0fac266013c196 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:24 -0500
Subject: [PATCH 0094/3820] New translations advanced.mdx (Swedish)

---
 .../creating-a-subgraph/advanced.mdx          | 36 +++++++++----------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/website/pages/sv/developing/creating-a-subgraph/advanced.mdx b/website/pages/sv/developing/creating-a-subgraph/advanced.mdx
index 46220d0a9a0a..587a97a2c21a 100644
--- a/website/pages/sv/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/sv/developing/creating-a-subgraph/advanced.mdx
@@ -279,29 +279,29 @@ For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave b
 Exempel:
 
 ```typescript
-import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+import { TokenMetadata as TokenMetadataTemplate } from "../generated/templates";
 
-const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+const ipfshash = "QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm";
 //Denna exempelkod är för en undergraf för kryptosamverkan. Ovanstående ipfs-hash är en katalog med tokenmetadata för alla kryptosamverkande NFT:er.
 
 export function handleTransfer(event: TransferEvent): void {
-  let token = Token.load(event.params.tokenId.toString())
+  let token = Token.load(event.params.tokenId.toString());
   if (!token) {
-    token = new Token(event.params.tokenId.toString())
-    token.tokenID = event.params.tokenId
+    token = new Token(event.params.tokenId.toString());
+    token.tokenID = event.params.tokenId;
 
-    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
-    const tokenIpfsHash = ipfshash + token.tokenURI
+    token.tokenURI = "/" + event.params.tokenId.toString() + ".json";
+    const tokenIpfsHash = ipfshash + token.tokenURI;
     //Detta skapar en sökväg till metadata för en enskild Crypto coven NFT. Den konkaterar katalogen med "/" + filnamn + ".json"
 
-    token.ipfsURI = tokenIpfsHash
+    token.ipfsURI = tokenIpfsHash;
 
-    TokenMetadataTemplate.create(tokenIpfsHash)
+    TokenMetadataTemplate.create(tokenIpfsHash);
   }
 
-  token.updatedAtTimestamp = event.block.timestamp
-  token.owner = event.params.to.toHexString()
-  token.save()
+  token.updatedAtTimestamp = event.block.timestamp;
+  token.owner = event.params.to.toHexString();
+  token.save();
 }
 ```
 
@@ -542,14 +542,14 @@ When a subgraph whose manifest contains a `graft` block is deployed, Graph Node
 
 Eftersom ympning kopierar data istället för att indexera basdata går det mycket snabbare att få delgrafen till det önskade blocket än att indexera från början, även om den initiala datorkopieringen fortfarande kan ta flera timmar för mycket stora delgrafer. Medan den ympade delgrafen initialiseras kommer Graph Node att logga information om de entitetstyper som redan har kopierats.
 
-Den ympade delgrafen kan använda ett GraphQL-schema som inte är identiskt med basdelgrafens, men bara kompatibelt med den. Det måste vara ett giltigt delgrafschema i sig själv, men kan avvika från basdelgrafens schema på följande sätt:
+Den ympade subgrafen kan använda ett GraphQL-schema som inte är identiskt med det i bas subgrafen, utan bara är kompatibelt med det. Det måste vara ett giltigt subgraf schema i sig, men kan avvika från bas undergrafens schema på följande sätt:
 
 - Den lägger till eller tar bort entitetstyper
-- Den tar bort attribut från entitetstyper
-- Den lägger till nollställbara attribut till entitetstyper
-- Den gör icke-nollställbara attribut till nollställbara attribut
-- Den lägger till värden till enum
+- Det tar bort attribut från entitetstyper
+- Det tar bort attribut från entitetstyper
+- Det förvandlar icke-nullbara attribut till nullbara attribut
+- Det lägger till värden till enums
 - Den lägger till eller tar bort gränssnitt
-- Den ändrar vilka entitetstyper som ett gränssnitt är implementerat för
+- Det ändrar för vilka entitetstyper ett gränssnitt implementeras
 
 > **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 2e13e261b8ae071366eff72e4dd7ecb1ae535582 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:25 -0500
Subject: [PATCH 0095/3820] New translations assemblyscript-mappings.mdx
 (Swedish)

---
 .../creating-a-subgraph/assemblyscript-mappings.mdx           | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sv/developing/creating-a-subgraph/assemblyscript-mappings.mdx b/website/pages/sv/developing/creating-a-subgraph/assemblyscript-mappings.mdx
index 259ae147af9f..646645e79ccc 100644
--- a/website/pages/sv/developing/creating-a-subgraph/assemblyscript-mappings.mdx
+++ b/website/pages/sv/developing/creating-a-subgraph/assemblyscript-mappings.mdx
@@ -99,13 +99,13 @@ import {
   // The events classes:
   NewGravatar,
   UpdatedGravatar,
-} from '../generated/Gravity/Gravity'
+} from "../generated/Gravity/Gravity";
 ```
 
 In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
 
 ```javascript
-import { Gravatar } from '../generated/schema'
+import { Gravatar } from "../generated/schema"
 ```
 
 > **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.

From 23bc6522da07622ba0c5189b6fd6b4a1e6a47798 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:26 -0500
Subject: [PATCH 0096/3820] New translations install-the-cli.mdx (Swedish)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/sv/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/sv/developing/creating-a-subgraph/install-the-cli.mdx
index 8166fa4088c1..09b66d92660e 100644
--- a/website/pages/sv/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/sv/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ ABI-filerna måste matcha ditt/dina kontrakt. Det finns några olika sätt att f
 
 ## SpecVersion Releases
 
-| Version | Versionsanteckningar |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| Version | Versionsanteckningar                                                                                                                                                     |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 6a13b39db2136e54294e49a02a3d628f65d1902f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:28 -0500
Subject: [PATCH 0097/3820] New translations ql-schema.mdx (Swedish)

---
 .../creating-a-subgraph/ql-schema.mdx         | 63 ++++++++++---------
 1 file changed, 34 insertions(+), 29 deletions(-)

diff --git a/website/pages/sv/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/sv/developing/creating-a-subgraph/ql-schema.mdx
index 5428162b401f..7c769d036458 100644
--- a/website/pages/sv/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/sv/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Typ | Beskrivning |
-| --- | --- |
-| `Bytes` | Bytematris, representerad som en hexadecimal sträng. Vanligt används för Ethereum-hashar och adresser. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Typ          | Beskrivning                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Bytematris, representerad som en hexadecimal sträng. Vanligt används för Ethereum-hashar och adresser.                                                                                                           |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 
@@ -247,7 +247,12 @@ type _Schema_
     name: "bandSearch"
     language: en
     algorithm: rank
-    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+    include: [
+      {
+        entity: "Band"
+        fields: [{ name: "name" }, { name: "description" }, { name: "bio" }]
+      }
+    ]
   )
 
 type Band @entity {
@@ -283,24 +288,24 @@ Att välja ett annat språk kommer att ha en definitiv, om än ibland subtil, ef
 
 Stödda språkordböcker:
 
-| Code  | Ordbok       |
-| ----- | ------------ |
-| enkel | General      |
-| da    | Danish       |
-| nl    | Dutch        |
-| en    | English      |
-| fi    | Finnish      |
-| fr    | French       |
-| de    | German       |
-| hu    | Hungarian    |
-| it    | Italian      |
-| no    | Norwegian    |
-| pt    | Portugisiska |
-| ro    | Romanian     |
-| ru    | Russian      |
-| es    | Spanish      |
-| sv    | Swedish      |
-| tr    | Turkish      |
+| Code   | Ordbok       |
+| ------ | ------------ |
+| enkel  | General      |
+| da     | Danish       |
+| nl     | Dutch        |
+| en     | English      |
+| fi     | Finnish      |
+| fr     | French       |
+| de     | German       |
+| hu     | Hungarian    |
+| it     | Italian      |
+| no     | Norwegian    |
+| pt     | Portugisiska |
+| ro     | Romanian     |
+| ru     | Russian      |
+| es     | Spanish      |
+| sv     | Swedish      |
+| tr     | Turkish      |
 
 ### Rankningsalgoritmer
 

From 00168688ac7ddb6dda40e967811d05eda3808f76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:29 -0500
Subject: [PATCH 0098/3820] New translations subgraph-manifest.mdx (Swedish)

---
 .../creating-a-subgraph/subgraph-manifest.mdx | 54 +++++++++----------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/website/pages/sv/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/sv/developing/creating-a-subgraph/subgraph-manifest.mdx
index fa653c523940..eedbf6b73287 100644
--- a/website/pages/sv/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/sv/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -165,7 +165,7 @@ dataSources:
     name: Gravity
     network: mainnet
     source:
-      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      address: "0x731a10897d267e19b34503ad902d0a29173ba4b1"
       abi: Gravity
     mapping:
       kind: ethereum/events
@@ -189,15 +189,15 @@ The `function` is the normalized function signature to filter calls by. The `han
 Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
 
 ```typescript
-import { CreateGravatarCall } from '../generated/Gravity/Gravity'
-import { Transaction } from '../generated/schema'
+import { CreateGravatarCall } from "../generated/Gravity/Gravity";
+import { Transaction } from "../generated/schema";
 
 export function handleCreateGravatar(call: CreateGravatarCall): void {
-  let id = call.transaction.hash
-  let transaction = new Transaction(id)
-  transaction.displayName = call.inputs._displayName
-  transaction.imageUrl = call.inputs._imageUrl
-  transaction.save()
+  let id = call.transaction.hash;
+  let transaction = new Transaction(id);
+  transaction.displayName = call.inputs._displayName;
+  transaction.imageUrl = call.inputs._imageUrl;
+  transaction.save();
 }
 ```
 
@@ -228,7 +228,7 @@ dataSources:
     name: Gravity
     network: dev
     source:
-      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      address: "0x731a10897d267e19b34503ad902d0a29173ba4b1"
       abi: Gravity
     mapping:
       kind: ethereum/events
@@ -280,9 +280,9 @@ Den definierade hanteraren med filtret once kommer att anropas endast en gång i
 
 ```ts
 export function handleOnce(block: ethereum.Block): void {
-  let data = new InitialData(Bytes.fromUTF8('initial'))
-  data.data = 'Setup data here'
-  data.save()
+  let data = new InitialData(Bytes.fromUTF8("initial"));
+  data.data = "Setup data here";
+  data.save();
 }
 ```
 
@@ -291,12 +291,12 @@ export function handleOnce(block: ethereum.Block): void {
 The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
 
 ```typescript
-import { ethereum } from '@graphprotocol/graph-ts'
+import { ethereum } from "@graphprotocol/graph-ts";
 
 export function handleBlock(block: ethereum.Block): void {
-  let id = block.hash
-  let entity = new Block(id)
-  entity.save()
+  let id = block.hash;
+  let entity = new Block(id);
+  entity.save();
 }
 ```
 
@@ -356,7 +356,7 @@ dataSources:
     name: Factory
     network: mainnet
     source:
-      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      address: "0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95"
       abi: Factory
     mapping:
       kind: ethereum/events
@@ -414,12 +414,12 @@ templates:
 In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
 
 ```typescript
-import { Exchange } from '../generated/templates'
+import { Exchange } from "../generated/templates";
 
 export function handleNewExchange(event: NewExchange): void {
   // Start indexing the exchange; `event.params.exchange` is the
   // address of the new exchange contract
-  Exchange.create(event.params.exchange)
+  Exchange.create(event.params.exchange);
 }
 ```
 
@@ -432,22 +432,22 @@ export function handleNewExchange(event: NewExchange): void {
 Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
 
 ```typescript
-import { Exchange } from '../generated/templates'
+import { Exchange } from "../generated/templates";
 
 export function handleNewExchange(event: NewExchange): void {
-  let context = new DataSourceContext()
-  context.setString('tradingPair', event.params.tradingPair)
-  Exchange.createWithContext(event.params.exchange, context)
+  let context = new DataSourceContext();
+  context.setString("tradingPair", event.params.tradingPair);
+  Exchange.createWithContext(event.params.exchange, context);
 }
 ```
 
 Inside a mapping of the `Exchange` template, the context can then be accessed:
 
 ```typescript
-import { dataSource } from '@graphprotocol/graph-ts'
+import { dataSource } from "@graphprotocol/graph-ts";
 
-let context = dataSource.context()
-let tradingPair = context.getString('tradingPair')
+let context = dataSource.context();
+let tradingPair = context.getString("tradingPair")
 ```
 
 There are setters and getters like `setString` and `getString` for all value types.
@@ -462,7 +462,7 @@ dataSources:
     name: ExampleSource
     network: mainnet
     source:
-      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      address: "0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95"
       abi: ExampleContract
       startBlock: 6627917
     mapping:

From c412147a77819f8d158722e8fecb0e78e94aa691 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:32 -0500
Subject: [PATCH 0099/3820] New translations graphql-api.mdx (Turkish)

---
 website/pages/tr/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/tr/querying/graphql-api.mdx b/website/pages/tr/querying/graphql-api.mdx
index c43734c04dd1..54a450425b25 100644
--- a/website/pages/tr/querying/graphql-api.mdx
+++ b/website/pages/tr/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** Yukarıdaki sorguyu, virgülle ayrılmış bir alt ifade geçirerek, `and` operatörünü kaldırarak basitleştirebilirsiniz.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Tam metin arama sorgularının kullanması gereken bir zorunlu alanı vardır, b
 
 Tam metin arama operatörleri:
 
-| Symbol | Operator | Tanım |
-| --- | --- | --- |
-| `&` | `And` | For combining multiple search terms into a filter for entities that include all of the provided terms |
-| &#x7c; | `Or` | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
-| `<->` | `Follow by` | Specify the distance between two words. |
-| `:*` | `Prefix` | Use the prefix search term to find words whose prefix match (2 characters required.) |
+| Symbol      | Operator    | Tanım                                                                                                                                |
+| ----------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| &#x7c;      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->` | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`        | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 
 #### Örnekler
 

From f5e75442bc503396f5f9168126f98cdb9f5395a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:33 -0500
Subject: [PATCH 0100/3820] New translations api.mdx (Turkish)

---
 website/pages/tr/developing/graph-ts/api.mdx | 100 +++++++++----------
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/website/pages/tr/developing/graph-ts/api.mdx b/website/pages/tr/developing/graph-ts/api.mdx
index 9ea83c6096c9..b8a4af72cc47 100644
--- a/website/pages/tr/developing/graph-ts/api.mdx
+++ b/website/pages/tr/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ Dil eşlemeleri AssemblyScript ile yazıldığından, [AssemblyScript wiki'sinde
 
 Subgraph manifestosundaki `apiVersion`, bir subgraph için Graph Düğümü tarafından çalıştırılan eşleme (mapping) API'sinin sürümünü belirtir.
 
-| Sürüm | Sürüm Notları |
-| :-: | --- |
-| 0.0.9 | Yeni host fonksiyonları ekler: [`eth_get_balance`](#balance-of-an-address) ve [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Bir varlığı kaydederken şemadaki alanların varlığını doğrulama mekanizması ekler. |
-| 0.0.7 | Ethereum türlerine `TransactionReceipt` ve `Log` sınıfları eklendi<br />Ethereum Event nesnesine `receipt` alanı eklendi |
-| 0.0.6 | Ethereum Transaction nesnesine `nonce` alanı eklendi<br />Ethereum Block nesnesine `baseFeePerGas` eklendi |
+| Sürüm | Sürüm Notları                                                                                                                                                                                                                                                                                                |
+| :---: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 0.0.9 | Yeni host fonksiyonları ekler: [`eth_get_balance`](#balance-of-an-address) ve [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                                                                         |
+| 0.0.8 | Bir varlığı kaydederken şemadaki alanların varlığını doğrulama mekanizması ekler.                                                                                                                                                                                                                            |
+| 0.0.7 | Ethereum türlerine `TransactionReceipt` ve `Log` sınıfları eklendi<br />Ethereum Event nesnesine `receipt` alanı eklendi                                                                                                                                                                                     |
+| 0.0.6 | Ethereum Transaction nesnesine `nonce` alanı eklendi<br />Ethereum Block nesnesine `baseFeePerGas` eklendi                                                                                                                                                                                                   |
 | 0.0.5 | AssemblyScript sürümü 0.19.10'a yükseltildi (bu sürümle birlikte uyumluluğu bozabilecek değişiklikler yapılmıştır, lütfen [`Geçiş Kılavuzu`](/release-notes/assemblyscript-migration-guide) bölümüne bakın)<br />`ethereum.transaction.gasUsed`, `ethereum.transaction.gasLimit` olarak yeniden adlandırıldı |
-| 0.0.4 | Ethereum SmartContractCall nesnesine `functionSignature` alanı eklendi |
-| 0.0.3 | Ethereum Call nesnesine `from` alanı eklendi<br />`etherem.call.address`, `ethereum.call.to` olarak yeniden adlandırıldı |
-| 0.0.2 | Ethereum Transaction nesnesine `input` alanı eklendi |
+| 0.0.4 | Ethereum SmartContractCall nesnesine `functionSignature` alanı eklendi                                                                                                                                                                                                                                       |
+| 0.0.3 | Ethereum Call nesnesine `from` alanı eklendi<br />`etherem.call.address`, `ethereum.call.to` olarak yeniden adlandırıldı                                                                                                                                                                                     |
+| 0.0.2 | Ethereum Transaction nesnesine `input` alanı eklendi                                                                                                                                                                                                                                                         |
 
 ### Dahili Türler
 
@@ -241,15 +241,15 @@ export function handleTransfer(event: TransferEvent): void {
   // İşlem hash'ını olay kimliği olarak kullanarak bir Transfer varlığı oluşturun
   let id = event.transaction.hash
   let transfer = new Transfer(id)
-
+  
   // Olay parametrelerini kullanarak varlığın özelliklerini ayarlayın
   transfer.from = event.params.from
   transfer.to = event.params.to
   transfer.amount = event.params.amount
-
+  
   // Varlığı depoya kaydedin
   transfer.save()
-}
+  }
 ```
 
 Zincir işlenirken bir `Transfer` olayıyla karşılaşıldığında, oluşturulan `Transfer` türü (burada varlık türüyle adlandırma çakışmasını önlemek için `TransferEvent` olarak adlandırılmıştır) kullanılarak `handleTransfer` olay işleyicisine aktarılır. Bu tür, olayın ana işlemi ve parametreleri gibi verilere erişim sağlar.
@@ -771,44 +771,44 @@ Bir değerin türü kesin olduğunda, aşağıdaki yöntemlerden biri kullanıla
 
 ### Tip Dönüşümleri Referansı
 
-| Kaynak(lar)       | Hedef             | Dönüşüm fonksiyonu           |
-| ----------------- | ----------------- | ---------------------------- |
-| Address           | Bytes             | yok                          |
-| Address           | String            | s.toHexString()              |
-| BigDecimal        | String            | s.toString()                 |
-| BigInt            | BigDecimal        | s.toBigDecimal()             |
-| BigInt            | Dizgi (onaltılık) | s.toHexString() or s.toHex() |
-| BigInt            | String (unicode)  | s.toString()                 |
-| BigInt            | i32               | s.toI32()                    |
-| Boolean           | Boolean           | yok                          |
-| Bytes (işaretli)  | BigInt            | BigInt.fromSignedBytes(s)    |
-| Bytes (işaretsiz) | BigInt            | BigInt.fromUnsignedBytes(s)  |
-| Bytes             | Dizgi (onaltılık) | s.toHexString() or s.toHex() |
-| Bytes             | String (unicode)  | s.toString()                 |
-| Bytes             | String (base58)   | s.toBase58()                 |
-| Bytes             | i32               | s.toI32()                    |
-| Bytes             | u32               | s.toU32()                    |
-| Bytes             | JSON              | json.fromBytes(s)            |
-| int8              | i32               | yok                          |
-| int32             | i32               | yok                          |
-| int32             | BigInt            | BigInt.fromI32(s)            |
-| uint24            | i32               | yok                          |
-| int64 - int256    | BigInt            | yok                          |
-| uint32 - uint256  | BigInt            | yok                          |
-| JSON              | boolean           | s.toBool()                   |
-| JSON              | i64               | s.toI64()                    |
-| JSON              | u64               | s.toU64()                    |
-| JSON              | f64               | s.toF64()                    |
-| JSON              | BigInt            | s.toBigInt()                 |
-| JSON              | string            | s.toString()                 |
-| JSON              | Array             | s.toArray()                  |
-| JSON              | Object            | s.toObject()                 |
-| String            | Address           | Address.fromString(s)        |
-| Bytes             | Address           | Address.fromBytes(s)         |
-| String            | BigInt            | BigInt.fromString(s)         |
-| String            | BigDecimal        | BigDecimal.fromString(s)     |
-| Dizgi (onaltılık) | Bytes             | ByteArray.fromHexString(s)   |
-| String (UTF-8)    | Bytes             | ByteArray.fromUTF8(s)        |
+| Kaynak(lar)            | Hedef                | Dönüşüm fonksiyonu           |
+| ---------------------- | -------------------- | ---------------------------- |
+| Address                | Bytes                | yok                          |
+| Address                | String               | s.toHexString()              |
+| BigDecimal             | String               | s.toString()                 |
+| BigInt                 | BigDecimal           | s.toBigDecimal()             |
+| BigInt                 | Dizgi (onaltılık)    | s.toHexString() or s.toHex() |
+| BigInt                 | String (unicode)     | s.toString()                 |
+| BigInt                 | i32                  | s.toI32()                    |
+| Boolean                | Boolean              | yok                          |
+| Bytes (işaretli)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (işaretsiz)      | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                  | Dizgi (onaltılık)    | s.toHexString() or s.toHex() |
+| Bytes                  | String (unicode)     | s.toString()                 |
+| Bytes                  | String (base58)      | s.toBase58()                 |
+| Bytes                  | i32                  | s.toI32()                    |
+| Bytes                  | u32                  | s.toU32()                    |
+| Bytes                  | JSON                 | json.fromBytes(s)            |
+| int8                   | i32                  | yok                          |
+| int32                  | i32                  | yok                          |
+| int32                  | BigInt               | BigInt.fromI32(s)            |
+| uint24                 | i32                  | yok                          |
+| int64 - int256         | BigInt               | yok                          |
+| uint32 - uint256       | BigInt               | yok                          |
+| JSON                   | boolean              | s.toBool()                   |
+| JSON                   | i64                  | s.toI64()                    |
+| JSON                   | u64                  | s.toU64()                    |
+| JSON                   | f64                  | s.toF64()                    |
+| JSON                   | BigInt               | s.toBigInt()                 |
+| JSON                   | string               | s.toString()                 |
+| JSON                   | Array                | s.toArray()                  |
+| JSON                   | Object               | s.toObject()                 |
+| String                 | Address              | Address.fromString(s)        |
+| Bytes                  | Address              | Address.fromBytes(s)         |
+| String                 | BigInt               | BigInt.fromString(s)         |
+| String                 | BigDecimal           | BigDecimal.fromString(s)     |
+| Dizgi (onaltılık)      | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)         | Bytes                | ByteArray.fromUTF8(s)        |
 
 ### Veri Kaynağı Meta Verileri
 

From a93e1c37997dfd9312b7a143fc93562a30946bb1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:35 -0500
Subject: [PATCH 0101/3820] New translations advanced.mdx (Turkish)

---
 website/pages/tr/developing/creating-a-subgraph/advanced.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/developing/creating-a-subgraph/advanced.mdx b/website/pages/tr/developing/creating-a-subgraph/advanced.mdx
index f44cb3bcf88d..12cc606f09f0 100644
--- a/website/pages/tr/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/tr/developing/creating-a-subgraph/advanced.mdx
@@ -87,7 +87,7 @@ Zaman Serisi ve Toplulaştırmalar özelliklerini kullanmak için, subgraph’in
 
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
-## Kritik olmayan hatalar
+## Ölümcül Olmayan Hatalar
 
 Halihazırda senkronize edilmiş subgraphlarda indeksleme hataları varsayılan olarak subgraph başarısız olmasına ve senkronizasyonun durmasına neden olur. Hatalara rağmen senkronizasyonun devam etmesi için subgraphlar, hata tetikleyen işleyicinin yapılan değişikliklerini yok sayarak yapılandırılabilir. Bu, subgraph yazarlarının subgraphlarını düzeltmeleri için zaman kazandırırken, sorguların en son blokta sunulmaya devam etmesini sağlar, ancak hata nedeniyle sonuçlar tutarsız olabilir. Bazı hatalar hala her zaman ölümcül olacaktır. Ölümcül olmaması için hatanın belirlenmiş olması gerekmektedir.
 

From d77fb72d9b7d74db7b46f184f1b32c8ee1e60a06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:37 -0500
Subject: [PATCH 0102/3820] New translations install-the-cli.mdx (Turkish)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/tr/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/tr/developing/creating-a-subgraph/install-the-cli.mdx
index 6b0ed88435dc..1fc26595c11d 100644
--- a/website/pages/tr/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/tr/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ ABI dosya(lar)ı sözleşme(ler) inizle uygun olmalıdır. ABI dosyalarını edi
 
 ## SpecVersion Sürümleri
 
-| Sürüm | Sürüm Notları |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
+| Sürüm | Sürüm Notları                                                                                                                                                            |
+| :---: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+| 0.0.9 | Supports `endBlock` feature                                                                                                                                              |
 | 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | İşleyicilerin işlem makbuzlarına erişim desteği eklendi. |
-| 0.0.4 | Subgraph özelliklerini yönetme desteği eklendi. |
+| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+| 0.0.5 | İşleyicilerin işlem makbuzlarına erişim desteği eklendi.                                                                                                                 |
+| 0.0.4 | Subgraph özelliklerini yönetme desteği eklendi.                                                                                                                          |

From 949bf3ce5f1486ecfe8f60ce0f60992c32972288 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:38 -0500
Subject: [PATCH 0103/3820] New translations ql-schema.mdx (Turkish)

---
 .../creating-a-subgraph/ql-schema.mdx         | 56 +++++++++----------
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/website/pages/tr/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/tr/developing/creating-a-subgraph/ql-schema.mdx
index c11d86e38b0e..aa158eda5efa 100644
--- a/website/pages/tr/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/tr/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 GraphQL API'sinde desteklenen skalarlardan bazıları şunlardır:
 
-| Tür | Tanım |
-| --- | --- |
-| `Bytes` | Byte dizisi, onaltılık bir dizgi olarak temsil edilir. Ethereum hash değerleri ve adresleri için yaygın olarak kullanılır. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Tür          | Tanım                                                                                                                                                                                                            |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte dizisi, onaltılık bir dizgi olarak temsil edilir. Ethereum hash değerleri ve adresleri için yaygın olarak kullanılır.                                                                                       |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Numaralandırmalar
 
@@ -283,24 +283,24 @@ Farklı bir dil seçmek, tam metin arama API'sı üzerinde bazen az olsa da kesi
 
 Desteklenen dil sözlükleri:
 
-| Code  | Sözlük     |
-| ----- | ---------- |
-| yalın | General    |
-| da    | Danish     |
-| nl    | Dutch      |
-| en    | English    |
-| fi    | Finnish    |
-| fr    | French     |
-| de    | German     |
-| hu    | Hungarian  |
-| it    | Italian    |
-| no    | Norwegian  |
-| pt    | Portekizce |
-| ro    | Romanian   |
-| ru    | Russian    |
-| es    | Spanish    |
-| sv    | Swedish    |
-| tr    | Turkish    |
+| Code   | Sözlük     |
+| ------ | ---------- |
+| yalın  | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Portekizce |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
 
 ### Algoritmaları Sıralama
 

From c69ea0640c64c3c65f8c87c0d08bdda57027b377 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:42 -0500
Subject: [PATCH 0104/3820] New translations unit-testing-framework.mdx
 (Ukrainian)

---
 .../pages/uk/developing/unit-testing-framework.mdx   | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/uk/developing/unit-testing-framework.mdx b/website/pages/uk/developing/unit-testing-framework.mdx
index 553eec2157b3..e537d89d2eb4 100644
--- a/website/pages/uk/developing/unit-testing-framework.mdx
+++ b/website/pages/uk/developing/unit-testing-framework.mdx
@@ -1380,20 +1380,20 @@ The log output includes the test run duration. Here's an example:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
 
-## Additional Resources
+## Додаткові матеріали
 
 For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
 

From a7624a8dd93d8f70d978c71b36948ac9b5a8f47e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:43 -0500
Subject: [PATCH 0105/3820] New translations graphql-api.mdx (Ukrainian)

---
 website/pages/uk/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/uk/querying/graphql-api.mdx b/website/pages/uk/querying/graphql-api.mdx
index 3dd70fc7b004..d8671e53a77c 100644
--- a/website/pages/uk/querying/graphql-api.mdx
+++ b/website/pages/uk/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 Fulltext search operators:
 
-| Symbol | Operator | Description |
-| --- | --- | --- |
-| `&` | `And` | For combining multiple search terms into a filter for entities that include all of the provided terms |
-| &#x7c; | `Or` | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
-| `<->` | `Follow by` | Specify the distance between two words. |
-| `:*` | `Prefix` | Use the prefix search term to find words whose prefix match (2 characters required.) |
+| Symbol      | Operator    | Description                                                                                                                          |
+| ----------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| &#x7c;      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->` | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`        | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 
 #### Examples
 

From dc23c4b0b59bb4ac2cc96e825323e8451279602c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:44 -0500
Subject: [PATCH 0106/3820] New translations api.mdx (Ukrainian)

---
 website/pages/uk/developing/graph-ts/api.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/uk/developing/graph-ts/api.mdx b/website/pages/uk/developing/graph-ts/api.mdx
index 6a0c4e208b99..8fc1f4b48b61 100644
--- a/website/pages/uk/developing/graph-ts/api.mdx
+++ b/website/pages/uk/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| Version | Release notes |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| Version | Release notes                                                                                                                                                                                                                                 |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### Built-in Types
 

From 8d82a057e23f73af41bebd9451175e153fcf8322 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:46 -0500
Subject: [PATCH 0107/3820] New translations transfer-to-the-graph.mdx
 (Ukrainian)

---
 website/pages/uk/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/cookbook/transfer-to-the-graph.mdx b/website/pages/uk/cookbook/transfer-to-the-graph.mdx
index 6a5d2c2793f3..f4166f2d3fe6 100644
--- a/website/pages/uk/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/uk/cookbook/transfer-to-the-graph.mdx
@@ -98,7 +98,7 @@ You can create API Keys in Subgraph Studio under the “API Keys” menu at the
 
 Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
 
-### Additional Resources
+### Додаткові матеріали
 
 - To quickly create and publish a new subgraph, check out the [Quick Start](/quick-start/).
 - To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From d880f8346e974832cd03d388497b5ca46a5ca5e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:48 -0500
Subject: [PATCH 0108/3820] New translations advanced.mdx (Ukrainian)

---
 .../creating-a-subgraph/advanced.mdx           | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/uk/developing/creating-a-subgraph/advanced.mdx b/website/pages/uk/developing/creating-a-subgraph/advanced.mdx
index 3a08ddab7066..f19b38199ae7 100644
--- a/website/pages/uk/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/uk/developing/creating-a-subgraph/advanced.mdx
@@ -542,14 +542,14 @@ When a subgraph whose manifest contains a `graft` block is deployed, Graph Node
 
 Because grafting copies rather than indexes base data, it is much quicker to get the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied.
 
-The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
-
-- It adds or removes entity types
-- It removes attributes from entity types
-- It adds nullable attributes to entity types
-- It turns non-nullable attributes into nullable attributes
-- It adds values to enums
-- It adds or removes interfaces
-- It changes for which entity types an interface is implemented
+Підграф, утворений в результаті може використовувати схему GraphQL, яка не є ідентичною схемі базового підграфа, а лише сумісною з нею. Вона повинна бути валідною схемою підграфа сама по собі, але може відхилятися від схеми базового підграфа у такому випадку:
+
+- Додає або видаляє типи елементів
+- Видаляє атрибути з типів елементів
+- Додає до типів об'єктів атрибути, які можна скасувати
+- Перетворює атрибути, які не можна скасувати, на атрибути, які можна скасувати
+- Додає значення до переліків
+- Додає або видаляє інтерфейси
+- Визначає, для яких типів елементів реалізовано інтерфейс
 
 > **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From e50c1bc1c15a1b44eff2d4062f148163e6ba138c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:50 -0500
Subject: [PATCH 0109/3820] New translations install-the-cli.mdx (Ukrainian)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/uk/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/uk/developing/creating-a-subgraph/install-the-cli.mdx
index 0100b66c4427..46d489f24d76 100644
--- a/website/pages/uk/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/uk/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The ABI file(s) must match your contract(s). There are a few ways to obtain ABI
 
 ## SpecVersion Releases
 
-| Version | Release notes |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 290fef686767153032e9308267e36c1bd66ea933 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:51 -0500
Subject: [PATCH 0110/3820] New translations ql-schema.mdx (Ukrainian)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/uk/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/uk/developing/creating-a-subgraph/ql-schema.mdx
index 90036d1bfab9..3df39853f82b 100644
--- a/website/pages/uk/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/uk/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Type | Description |
-| --- | --- |
-| `Bytes` | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 

From af48472ce72a9181ad84690e05bbd4a0903cc0f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:55 -0500
Subject: [PATCH 0111/3820] New translations unit-testing-framework.mdx
 (Chinese Simplified)

---
 .../zh/developing/unit-testing-framework.mdx     | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/zh/developing/unit-testing-framework.mdx b/website/pages/zh/developing/unit-testing-framework.mdx
index 6a6c46fd3d9b..f5b3d4e5f28c 100644
--- a/website/pages/zh/developing/unit-testing-framework.mdx
+++ b/website/pages/zh/developing/unit-testing-framework.mdx
@@ -33,7 +33,7 @@ Installation command:
 brew install postgresql
 ```
 
-创建到最新 libpq.5. lib* 的符号链接，可能需要首先创建这个目录*`/usr/local/opt/postgreql/lib/`
+创建到最新 libpq.5. lib_ 的符号链接，可能需要首先创建这个目录_`/usr/local/opt/postgreql/lib/`
 
 ```sh
 ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
@@ -236,7 +236,7 @@ test("handleNewGravatar() should create a new entity", () => {
 
 例子：
 
-`beforeAll`中的代码将在文件中的*all*测试之前执行一次。
+`beforeAll`中的代码将在文件中的_all_测试之前执行一次。
 
 ```typescript
 import { describe, test, beforeAll } from "matchstick-as/assembly/index"
@@ -296,7 +296,7 @@ describe("handleUpdatedGravatar()", () => {
 
 例子:
 
-`afterAll`中的代码将在文件中的*all*测试之后执行一次。
+`afterAll`中的代码将在文件中的_all_测试之后执行一次。
 
 ```typescript
 import { describe, test, afterAll } from "matchstick-as/assembly/index"
@@ -1380,15 +1380,15 @@ Global test coverage: 22.2% (2/9 handlers).
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > 返回ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > 返回新ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 参数不匹配是由`graph-ts` and `matchstick-as`不匹配造成的。解决此类问题的最佳方法是将所有内容更新到最新发布的版本。

From ab22a3219f912bf8bf60592fbf177d96f1a12e96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:56 -0500
Subject: [PATCH 0112/3820] New translations graphql-api.mdx (Chinese
 Simplified)

---
 website/pages/zh/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/zh/querying/graphql-api.mdx b/website/pages/zh/querying/graphql-api.mdx
index 7ba254944ed7..2e4b4a0e6f54 100644
--- a/website/pages/zh/querying/graphql-api.mdx
+++ b/website/pages/zh/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **语法糖：**您可以通过传递一个用逗号分隔的子表达式来删除`and`运算符，从而简化上述查询。
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ The result of such a query will not change over time, i.e., querying at a certai
 
 全文搜索运算符：
 
-| 符号   | 运算符      | 描述                                                                   |
-| ------ | ----------- | ---------------------------------------------------------------------- |
-| `&`    | `And`       | 用于将多个搜索词组合到包含所有提供词条的实体的过滤器中                 |
-| &#x7c; | `Or`        | 由 or 运算符分隔的多个搜索词的查询，将返回与任何提供的词匹配的所有实体 |
-| `<->`  | `Follow by` | 指定两个单词之间的距离。                                               |
-| `:*`   | `Prefix`    | 使用前缀搜索词查找前缀匹配的单词（需要 2 个字符）                      |
+| 符号          | 运算符         | 描述                                    |
+| ----------- | ----------- | ------------------------------------- |
+| `&`     | `And`       | 用于将多个搜索词组合到包含所有提供词条的实体的过滤器中           |
+| &#x7c;      | `Or`        | 由 or 运算符分隔的多个搜索词的查询，将返回与任何提供的词匹配的所有实体 |
+| `<->` | `Follow by` | 指定两个单词之间的距离。                          |
+| `:*`        | `Prefix`    | 使用前缀搜索词查找前缀匹配的单词（需要 2 个字符）            |
 
 #### 例子
 

From 91283492010a819f62c523302294a4957d6b8ba9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:58:59 -0500
Subject: [PATCH 0113/3820] New translations api.mdx (Chinese Simplified)

---
 website/pages/zh/developing/graph-ts/api.mdx | 24 ++++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/zh/developing/graph-ts/api.mdx b/website/pages/zh/developing/graph-ts/api.mdx
index 7a814fcd9a7e..0bb53153fae9 100644
--- a/website/pages/zh/developing/graph-ts/api.mdx
+++ b/website/pages/zh/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ Since language mappings are written in AssemblyScript, it is useful to review th
 
 子图清单中的 `apiVersion` 指定了由 Graph Node 运行的特定子图的映射 API 版本。
 
-| 版本 | Release 说明 |
-| :-: | --- |
+|   版本  | Release 说明                                                                                                                   |
+| :---: | ---------------------------------------------------------------------------------------------------------------------------- |
 | 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | 添加了 `TransactionReceipt` 和 `Log` 类到以太坊类型。<br />已将 `receipt` 字段添加到Ethereum Event对象。 |
-| 0.0.6 | 向Ethereum Transaction对象添加了 nonce 字段 向 Etherum Block对象添加<br /> baseFeePerGas字段 |
-| 0.0.5 | AssemblyScript 升级到版本 0.19.10(这包括重大更改，参阅 <br />迁移指南)ethereum.transaction.gasUsed 重命名为 ethereum.transaction.gasLimit |
-| 0.0.4 | 已向 Ethereum SmartContractCall对象添加了 `functionSignature` 字段。 |
-| 0.0.3 | 已向Ethereum Call 对象添加了 `from` 字段。<br />`etherem.call.address` 被重命名为 `ethereum.call.to`。 |
-| 0.0.2 | 已向Ethereum Transaction对象添加了 `input` 字段。 |
+| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity.                                                 |
+| 0.0.7 | 添加了 `TransactionReceipt` 和 `Log` 类到以太坊类型。<br />已将 `receipt` 字段添加到Ethereum Event对象。                                           |
+| 0.0.6 | 向Ethereum Transaction对象添加了 nonce 字段 向 Etherum Block对象添加<br /> baseFeePerGas字段                                                |
+| 0.0.5 | AssemblyScript 升级到版本 0.19.10(这包括重大更改，参阅 <br />迁移指南)ethereum.transaction.gasUsed 重命名为 ethereum.transaction.gasLimit           |
+| 0.0.4 | 已向 Ethereum SmartContractCall对象添加了 `functionSignature` 字段。                                                                   |
+| 0.0.3 | 已向Ethereum Call 对象添加了 `from` 字段。<br />`etherem.call.address` 被重命名为 `ethereum.call.to`。                                       |
+| 0.0.2 | 已向Ethereum Transaction对象添加了 `input` 字段。                                                                                      |
 
 ### 内置类型
 
@@ -769,19 +769,19 @@ if (value.kind == JSONValueKind.BOOL) {
 
 ### 类型转换参考
 
-| 源类型               | 目标类型             | 转换函数                     |
+| 源类型                  | 目标类型                 | 转换函数                         |
 | -------------------- | -------------------- | ---------------------------- |
 | Address              | Bytes                | none                         |
 | Address              | String               | s.toHexString()              |
 | BigDecimal           | String               | s.toString()                 |
 | BigInt               | BigDecimal           | s.toBigDecimal()             |
-| BigInt               | String (hexadecimal) | s.toHexString() 或 s.toHex() |
+| BigInt               | String (hexadecimal) | s.toHexString() 或 s.toHex()  |
 | BigInt               | String (unicode)     | s.toString()                 |
 | BigInt               | i32                  | s.toI32()                    |
 | Boolean              | Boolean              | none                         |
 | Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
 | Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
-| Bytes                | String (hexadecimal) | s.toHexString() 或 s.toHex() |
+| Bytes                | String (hexadecimal) | s.toHexString() 或 s.toHex()  |
 | Bytes                | String (unicode)     | s.toString()                 |
 | Bytes                | String (base58)      | s.toBase58()                 |
 | Bytes                | i32                  | s.toI32()                    |

From 8a7ee4ebd9d4ea41c4b14e92b14888900ce491e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:02 -0500
Subject: [PATCH 0114/3820] New translations advanced.mdx (Chinese Simplified)

---
 website/pages/zh/developing/creating-a-subgraph/advanced.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/developing/creating-a-subgraph/advanced.mdx b/website/pages/zh/developing/creating-a-subgraph/advanced.mdx
index 7ecc521091c6..80c64ac597eb 100644
--- a/website/pages/zh/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/zh/developing/creating-a-subgraph/advanced.mdx
@@ -281,7 +281,7 @@ For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave b
 ```typescript
 import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
 
-const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+const ipfshash = "QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm"
 //This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
 
 export function handleTransfer(event: TransferEvent): void {
@@ -542,7 +542,7 @@ When a subgraph whose manifest contains a `graft` block is deployed, Graph Node
 
 因为嫁接是拷贝而不是索引基础数据，所以子图同步到所需区块比从头开始索引要快得多，尽管对于非常大的子图，初始数据拷贝仍可能需要几个小时。 在初始化嫁接子图时，Graph 节点将记录有关已复制的实体类型的信息。
 
-嫁接子图可以使用一个GraphQL模式，该模式与某个基本子图不同，但仅与基本子图兼容。它本身必须是一个有效的子图模式，但是可以通过以下方式偏离基本子图的模式：
+嫁接子图可以使用一个 GraphQL 模式 schema，该模式与基子图之一不同，但仅与基子图兼容。它本身必须是一个有效的子图模式，但是可以通过以下方式偏离基子图的模式：
 
 - 它添加或删除实体类型
 - 它从实体类型中删除属性

From 0b79697b181c03f580b1dcc0001b909da88241f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:03 -0500
Subject: [PATCH 0115/3820] New translations install-the-cli.mdx (Chinese
 Simplified)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/zh/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/zh/developing/creating-a-subgraph/install-the-cli.mdx
index 9db4e62530b6..50df657982d7 100644
--- a/website/pages/zh/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/zh/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ ABI 文件必须与您的合约相匹配。 获取 ABI 文件的方法有以下
 
 ## SpecVersion Releases
 
-| 版本 | Release 说明 |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
+|   版本  | Release 说明                                                                                                                                                               |
+| :---: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+| 0.0.9 | Supports `endBlock` feature                                                                                                                                              |
 | 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+| 0.0.5 | Added support for event handlers having access to transaction receipts.                                                                                                  |
+| 0.0.4 | Added support for managing subgraph features.                                                                                                                            |

From 659331bf5221024251e42d0b3e74a16f73ced4e5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:05 -0500
Subject: [PATCH 0116/3820] New translations ql-schema.mdx (Chinese Simplified)

---
 .../creating-a-subgraph/ql-schema.mdx         | 64 +++++++++----------
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/website/pages/zh/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/zh/developing/creating-a-subgraph/ql-schema.mdx
index eb5be4580baf..d9ca63c76b45 100644
--- a/website/pages/zh/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/zh/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| 类型 | 描述 |
-| --- | --- |
-| `Bytes` | 字节数组，表示为十六进制字符串。 通常用于以太坊hash和地址。 |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| 类型           | 描述                                                                                                                                                                                                               |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | 字节数组，表示为十六进制字符串。 通常用于以太坊hash和地址。                                                                                                                                                                                 |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### 枚举类型
 
@@ -283,30 +283,30 @@ query {
 
 支持的语言词典：
 
-| Code   | 词典      |
-| ------ | --------- |
-| simple | General   |
-| da     | Danish    |
-| nl     | Dutch     |
-| en     | English   |
-| fi     | Finnish   |
-| fr     | French    |
-| de     | German    |
-| hu     | Hungarian |
-| it     | Italian   |
-| no     | Norwegian |
-| pt     | 葡萄牙语  |
-| ro     | Romanian  |
-| ru     | Russian   |
-| es     | Spanish   |
-| sv     | Swedish   |
-| tr     | Turkish   |
+| Code   | 词典         |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | 葡萄牙语       |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
 
 ### 排序算法
 
 支持的排序结果算法：
 
-| Algorithm     | Description                                                     |
-| ------------- | --------------------------------------------------------------- |
-| rank          | 使用全文查询的匹配质量 (0-1) 对结果进行排序。                   |
-| proximityRank | Similar to rank but also includes the proximity of the matches. |
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | 使用全文查询的匹配质量 (0-1) 对结果进行排序。                                              |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From a87853e0b76a2c121fc6695ee191479c0821d5ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:08 -0500
Subject: [PATCH 0117/3820] New translations near.mdx (Urdu (Pakistan))

---
 website/pages/ur/cookbook/near.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ur/cookbook/near.mdx b/website/pages/ur/cookbook/near.mdx
index 2ce706542d8c..30855c266732 100644
--- a/website/pages/ur/cookbook/near.mdx
+++ b/website/pages/ur/cookbook/near.mdx
@@ -70,7 +70,7 @@ dataSources:
       file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
 ```
 
-- NEAR سب گراف ڈیٹا ماخذ کا ایک نیا `kind` متعارف کراتے ہیں (`near`)
+- NEAR سب گراف ڈیٹا ماخذ کا ایک نیا ` kind ` متعارف کراتے ہیں (`near`)
 - The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
 - NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
 - NEAR ڈیٹا کے ذرائع ایک متبادل اختیاری `source.accounts` فیلڈ متعارف کراتے ہیں، جس میں اختیاری لاحقے اور سابقے ہوتے ہیں۔ کم از کم سابقہ ​​یا لاحقہ متعین ہونا ضروری ہے، وہ بالترتیب اقدار کی فہرست کے ساتھ شروع یا ختم ہونے والے کسی بھی اکاؤنٹ سے مماثل ہوں گے۔ نیچے دی گئی مثال مماثل ہوگی: `[app|good].*[morning.near|morning.testnet]`۔ اگر صرف سابقوں یا لاحقوں کی فہرست ضروری ہو تو دوسری فیلڈ کو چھوڑا جا سکتا ہے.
@@ -254,7 +254,7 @@ NEAR سپورٹ بیٹا میں ہے، جس کا مطلب ہے کہ API میں 
 
 ### کیا رسید ہینڈلرز اکاؤنٹس اور ان کے سب اکاؤنٹس کو متحرک کریں گے؟
 
-اگر ایک `account` متعین کیا گیا ہے، تو وہ صرف صحیح اکاؤنٹ کے نام سے مماثل ہوگا۔ مثال کے طور پر، اکاؤنٹس اور سب اکاؤنٹس سے ملنے کے لیے مخصوص `prefixes` اور ` suffixes` کے ساتھ، `accounts` فیلڈ کی وضاحت کرکے سب اکاؤنٹس کو ملانا ممکن ہے۔ درج ذیل تمام `mintbase1.near` سب اکاؤنٹس سے مماثل ہوں گے:
+اگر ایک ` account ` متعین کیا گیا ہے، تو وہ صرف صحیح اکاؤنٹ کے نام سے مماثل ہوگا۔ مثال کے طور پر، اکاؤنٹس اور سب اکاؤنٹس سے ملنے کے لیے مخصوص ` prefixes ` اور ` suffixes` کے ساتھ، `accounts` فیلڈ کی وضاحت کرکے سب اکاؤنٹس کو ملانا ممکن ہے۔ درج ذیل تمام `mintbase1.near` سب اکاؤنٹس سے مماثل ہوں گے:
 
 ```yaml
 accounts:

From 7be1d07665284ec0cfc5f5fef07a7217cf5ba85f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:09 -0500
Subject: [PATCH 0118/3820] New translations unit-testing-framework.mdx (Urdu
 (Pakistan))

---
 website/pages/ur/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ur/developing/unit-testing-framework.mdx b/website/pages/ur/developing/unit-testing-framework.mdx
index 76d1bd43664a..23e3d1695189 100644
--- a/website/pages/ur/developing/unit-testing-framework.mdx
+++ b/website/pages/ur/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ Global test coverage: 22.2% (2/9 handlers).
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 دلائل میں عدم مماثلت `graph-ts` اور `matchstick-as` میں عدم مماثلت کی وجہ سے ہوتی ہے۔ اس طرح کے مسائل کو حل کرنے کا بہترین طریقہ یہ ہے کہ ہر چیز کو تازہ ترین جاری کردہ ورژن میں اپ ڈیٹ کیا جائے.

From 5f484b271657bc101bb72550f2d73ba8ad9979ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:10 -0500
Subject: [PATCH 0119/3820] New translations graphql-api.mdx (Urdu (Pakistan))

---
 website/pages/ur/querying/graphql-api.mdx | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/ur/querying/graphql-api.mdx b/website/pages/ur/querying/graphql-api.mdx
index dca35f1f671a..3dfdf8d64d89 100644
--- a/website/pages/ur/querying/graphql-api.mdx
+++ b/website/pages/ur/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic شوگر:** آپ `and` آپریٹر کو ہٹا کر کوما سے الگ کردہ سب اظہار کو پاس کر کے مذکورہ کیوری کو آسان بنا سکتے ہیں.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ The result of such a query will not change over time, i.e., querying at a certai
 
 فل ٹیکسٹ سرچ آپریٹرز:
 
-| علامت | آپریٹر | تفصیل |
-| --- | --- | --- |
-| `&` | `And` | ایک سے زیادہ تلاش کی اصطلاحات کو ایک فلٹر میں یکجا کرنے کے لیے ان ہستیوں کے لیے جس میں فراہم کردہ تمام اصطلاحات شامل ہوں |
-| &#x7c; | `Or` | Or آپریٹر کے ذریعہ الگ کردہ متعدد تلاش کی اصطلاحات کے ساتھ کیوریز فراہم کردہ شرائط میں سے کسی سے بھی مماثلت کے ساتھ تمام ہستیوں کو واپس کریں گے |
-| `<>` | `Follow by` | دو الفاظ کے درمیان فاصلہ بتائیں. |
-| `:*` | `Prefix` | ایسے الفاظ تلاش کرنے کے لیے پریفکس ​​تلاش کی اصطلاح استعمال کریں جن کا سابقہ ​​مماثل ہو (۲ حروف درکار ہیں.) |
+| علامت      | آپریٹر      | تفصیل                                                                                                                                           |
+| ---------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`    | `And`       | ایک سے زیادہ تلاش کی اصطلاحات کو ایک فلٹر میں یکجا کرنے کے لیے ان ہستیوں کے لیے جس میں فراہم کردہ تمام اصطلاحات شامل ہوں                        |
+| &#x7c;     | `Or`        | Or آپریٹر کے ذریعہ الگ کردہ متعدد تلاش کی اصطلاحات کے ساتھ کیوریز فراہم کردہ شرائط میں سے کسی سے بھی مماثلت کے ساتھ تمام ہستیوں کو واپس کریں گے |
+| `<>` | `Follow by` | دو الفاظ کے درمیان فاصلہ بتائیں.                                                                                                                |
+| `:*`       | `Prefix`    | ایسے الفاظ تلاش کرنے کے لیے پریفکس ​​تلاش کی اصطلاح استعمال کریں جن کا سابقہ ​​مماثل ہو (۲ حروف درکار ہیں.)                                     |
 
 #### مثالیں
 
@@ -421,7 +421,7 @@ GraphQL schemas generally define root types for `queries`, `subscriptions` and `
 
 اگر کوئی بلاک فراہم کیا جاتا ہے تو، میٹا ڈیٹا اس بلاک کا ہوتا ہے، اگر تازہ ترین انڈیکسڈ بلاک استعمال نہیں کیا جاتا ہے۔ اگر فراہم کیا گیا ہو، تو بلاک سب گراف کے اسٹارٹ بلاک کے بعد ہونا چاہیے، اور حال ہی میں انڈیکس کیے گئے بلاک سے کم یا اس کے برابر ہونا چاہیے.
 
-`deployment` ایک منفرد ID ہے، جو `subgraph.yaml` فائل کے IPFS CID سے مطابقت رکھتی ہے.
+` deployment ` ایک منفرد ID ہے، جو `subgraph.yaml` فائل کے IPFS CID سے مطابقت رکھتی ہے.
 
 `block` تازہ ترین بلاک کے بارے میں معلومات فراہم کرتا ہے (`_meta` کو بھیجی گئی کسی بھی بلاک کی رکاوٹوں کو مدنظر رکھتے ہوئے):
 

From 8b9848119a8a383d40f90726cfc258f96a5b65b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:12 -0500
Subject: [PATCH 0120/3820] New translations api.mdx (Urdu (Pakistan))

---
 website/pages/ur/developing/graph-ts/api.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/ur/developing/graph-ts/api.mdx b/website/pages/ur/developing/graph-ts/api.mdx
index c96035a03ceb..1a796d4b0b41 100644
--- a/website/pages/ur/developing/graph-ts/api.mdx
+++ b/website/pages/ur/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| ورزن | جاری کردہ نوٹس |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
+|  ورزن | جاری کردہ نوٹس                                                                                                                                                                                                                                |
+| :---: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
 | 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+| 0.0.2 | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### بلٹ ان اقسام
 
@@ -225,7 +225,7 @@ The `store` API allows to load, save and remove entities from and to the Graph N
 
 Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
 
-#### ہستیوں کی تخلیق
+#### Creating entities
 
 ایتھیریم ایونٹس سے ہستیوں کو بنانے کے لیے درج ذیل ایک عام نمونہ ہے.
 

From a6858d4272c7b1919d6997ced8e7e3005a9d3d18 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:14 -0500
Subject: [PATCH 0121/3820] New translations advanced.mdx (Urdu (Pakistan))

---
 .../ur/developing/creating-a-subgraph/advanced.mdx   | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/ur/developing/creating-a-subgraph/advanced.mdx b/website/pages/ur/developing/creating-a-subgraph/advanced.mdx
index f25870d6bdf7..c870a9989885 100644
--- a/website/pages/ur/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/ur/developing/creating-a-subgraph/advanced.mdx
@@ -542,14 +542,14 @@ When a subgraph whose manifest contains a `graft` block is deployed, Graph Node
 
 چونکہ گرافٹنگ بیس ڈیٹا کو انڈیکس کرنے کے بجائے کاپی کرتا ہے، شروع سے انڈیکس کرنے کے مقابلے میں مطلوبہ بلاک میں سب گراف حاصل کرنا بہت تیز ہے، حالانکہ ابتدائی ڈیٹا کاپی بہت بڑے سب گراف کے لیے کئی گھنٹے لگ سکتی ہے۔ جب گرافٹ شدہ سب گراف کو شروع کیا جا رہا ہے، گراف نوڈ ان ہستی کی اقسام کے بارے میں معلومات کو لاگ کرے گا جو پہلے ہی کاپی ہو چکی ہیں.
 
-گرافٹڈ سب گراف ایک GraphQL اسکیما استعمال کرسکتا ہے جو بیس سب گراف میں سے ایک سے مماثل نہیں ہے، لیکن اس کے ساتھ محض مطابقت رکھتا ہے۔ یہ اپنے طور پر ایک درست سب گراف سکیما ہونا ضروری ہے، لیکن مندرجہ ذیل طریقوں سے بنیادی سب گراف کے سکیما سے انحراف کر سکتا ہے:
+گرافٹڈ سب گراف ایک گراف کیو ایل اسکیما استعمال کرسکتا ہے جو بیس سب گراف میں سے ایک سے مماثل نہیں ہے، لیکن اس کے ساتھ محض مطابقت رکھتا ہے۔ اسے اپنے طور پر ایک درست سب گراف سکیما ہونا چاہیے، لیکن درج ذیل طریقوں سے بنیادی سب گراف کے سکیما سے انحراف ہو سکتا ہے:
 
-- یہ ہستی کی اقسام کو ڈالتا یا ہٹاتا ہے
+- یہ ہستی کی اقسام کو جوڑتا یا ہٹاتا ہے
 - یہ ہستی کی اقسام سے صفات کو ہٹاتا ہے
-- یہ ہستی کی اقسام میں nullable صفات کا اضافہ کرتا ہے
-- یہ non-nullable صفات کو nullable صفات میں بدل دیتا ہے
+- یہ ہستی کی قسموں میں کالعدم صفات کو شامل کرتا ہے
+- یہ غیر کالعدم صفات کو کالعدم صفات میں بدل دیتا ہے
 - یہ enums میں اقدار کا اضافہ کرتا ہے
-- یہ انٹرفیس میں اضافہ کرتا یا ہٹاتا ہے
-- یہ ان ہستی کی اقسام کے لیے تبدیل ہوتا ہے جن کے لیے ایک انٹرفیس لاگو کیا جاتا ہے
+- یہ انٹرفیس کو جوڑتا یا ہٹاتا ہے
+- یہ تبدیل ہوتا ہے جس کے لیے ایک انٹرفیس لاگو کیا جاتا ہے
 
 > **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From b112a1f71dee5a51e0aa6e2051c4ceca6730641f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:16 -0500
Subject: [PATCH 0122/3820] New translations install-the-cli.mdx (Urdu
 (Pakistan))

---
 .../creating-a-subgraph/install-the-cli.mdx   | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/ur/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/ur/developing/creating-a-subgraph/install-the-cli.mdx
index 118eeea3c5f3..df53c1b48b6e 100644
--- a/website/pages/ur/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/ur/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ ABI فائل (فائلیں) آپ کے کنٹریکٹ (کنٹریکٹس) سے م
 
 ## SpecVersion Releases
 
-| ورزن | جاری کردہ نوٹس |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
+|  ورزن | جاری کردہ نوٹس                                                                                                                                                           |
+| :---: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+| 0.0.9 | Supports `endBlock` feature                                                                                                                                              |
 | 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+| 0.0.5 | Added support for event handlers having access to transaction receipts.                                                                                                  |
+| 0.0.4 | Added support for managing subgraph features.                                                                                                                            |

From 6a3e76b2b4083b95710e8ba9ad77f097e332f733 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:17 -0500
Subject: [PATCH 0123/3820] New translations ql-schema.mdx (Urdu (Pakistan))

---
 .../creating-a-subgraph/ql-schema.mdx         | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/ur/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/ur/developing/creating-a-subgraph/ql-schema.mdx
index 7b866d878c0b..7838cac596df 100644
--- a/website/pages/ur/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/ur/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| قسم | تفصیل |
-| --- | --- |
-| `Bytes` | Byte array، ایک ہیکساڈیسیمل سٹرنگ کے طور پر پیش کیا جاتا ہے. عام طور پر Ethereum hashes اور ایڈریسیس کے لیے استعمال ہوتا ہے. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| قسم          | تفصیل                                                                                                                                                                                                            |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array، ایک ہیکساڈیسیمل سٹرنگ کے طور پر پیش کیا جاتا ہے. عام طور پر Ethereum hashes اور ایڈریسیس کے لیے استعمال ہوتا ہے.                                                                                     |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 
@@ -306,7 +306,7 @@ query {
 
 نتائج ترتیب دینے کے لیے معاون الگورتھم:
 
-| Algorithm    | Description                                                                 |
-| ------------ | --------------------------------------------------------------------------- |
-| rank         | نتائج ترتیب دینے کے لیے فل ٹیکسٹ کیوری کے میچ کوالٹی (1-0) کا استعمال کریں. |
-| قربت کا درجہ | Similar to rank but also includes the proximity of the matches.             |
+| Algorithm     | Description                                                                 |
+| ------------- | --------------------------------------------------------------------------- |
+| rank          | نتائج ترتیب دینے کے لیے فل ٹیکسٹ کیوری کے میچ کوالٹی (1-0) کا استعمال کریں. |
+| قربت کا درجہ  | Similar to rank but also includes the proximity of the matches.             |

From 0c79054123c87a23e4c2598a88652389ab022225 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:21 -0500
Subject: [PATCH 0124/3820] New translations unit-testing-framework.mdx
 (Vietnamese)

---
 website/pages/vi/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/vi/developing/unit-testing-framework.mdx b/website/pages/vi/developing/unit-testing-framework.mdx
index 63da75a0cc84..7bab8ce8c859 100644
--- a/website/pages/vi/developing/unit-testing-framework.mdx
+++ b/website/pages/vi/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ The log output includes the test run duration. Here's an example:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.

From 6e083c3ea4c458c346e732e52333f91e83964bf4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:22 -0500
Subject: [PATCH 0125/3820] New translations graphql-api.mdx (Vietnamese)

---
 website/pages/vi/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/vi/querying/graphql-api.mdx b/website/pages/vi/querying/graphql-api.mdx
index 8db543089d78..65d0a40a7bd4 100644
--- a/website/pages/vi/querying/graphql-api.mdx
+++ b/website/pages/vi/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 Fulltext search operators:
 
-| Biểu tượng | Toán tử | Miêu tả |
-| --- | --- | --- |
-| `&` | `And` | Để kết hợp nhiều cụm từ tìm kiếm thành một bộ lọc cho các thực thể bao gồm tất cả các cụm từ được cung cấp |
-| &#x7c; | `Or` | Các truy vấn có nhiều cụm từ tìm kiếm được phân tách bằng toán tử hoặc sẽ trả về tất cả các thực thể có kết quả khớp với bất kỳ cụm từ nào được cung cấp |
-| `<->` | `Follow by` | Chỉ định khoảng cách giữa hai từ. |
-| `:*` | `Prefix` | Sử dụng cụm từ tìm kiếm tiền tố để tìm các từ có tiền tố khớp với nhau (yêu cầu 2 ký tự.) |
+| Biểu tượng  | Toán tử     | Miêu tả                                                                                                                                                  |
+| ----------- | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`     | `And`       | Để kết hợp nhiều cụm từ tìm kiếm thành một bộ lọc cho các thực thể bao gồm tất cả các cụm từ được cung cấp                                               |
+| &#x7c;      | `Or`        | Các truy vấn có nhiều cụm từ tìm kiếm được phân tách bằng toán tử hoặc sẽ trả về tất cả các thực thể có kết quả khớp với bất kỳ cụm từ nào được cung cấp |
+| `<->` | `Follow by` | Chỉ định khoảng cách giữa hai từ.                                                                                                                        |
+| `:*`        | `Prefix`    | Sử dụng cụm từ tìm kiếm tiền tố để tìm các từ có tiền tố khớp với nhau (yêu cầu 2 ký tự.)                                                                |
 
 #### Examples
 

From ac2feadcc813d51885f969cdc7a63ef2ba998487 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:23 -0500
Subject: [PATCH 0126/3820] New translations api.mdx (Vietnamese)

---
 website/pages/vi/developing/graph-ts/api.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/vi/developing/graph-ts/api.mdx b/website/pages/vi/developing/graph-ts/api.mdx
index 9595add2bc4c..cff2389b0279 100644
--- a/website/pages/vi/developing/graph-ts/api.mdx
+++ b/website/pages/vi/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| Phiên bản | Ghi chú phát hành |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| Phiên bản | Ghi chú phát hành                                                                                                                                                                                                                             |
+| :-------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|   0.0.9   | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|   0.0.8   | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|   0.0.7   | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|   0.0.6   | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|   0.0.5   | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|   0.0.4   | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|   0.0.3   | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|   0.0.2   | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### Các loại cài sẵn
 

From 42152ebe9cea9a99e61dae30372135ba1492c383 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:26 -0500
Subject: [PATCH 0127/3820] New translations advanced.mdx (Vietnamese)

---
 .../vi/developing/creating-a-subgraph/advanced.mdx   | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/vi/developing/creating-a-subgraph/advanced.mdx b/website/pages/vi/developing/creating-a-subgraph/advanced.mdx
index e929137a7147..fcc1bcd06f73 100644
--- a/website/pages/vi/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/vi/developing/creating-a-subgraph/advanced.mdx
@@ -544,12 +544,12 @@ Because grafting copies rather than indexes base data, it is much quicker to get
 
 The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
 
-- Nó thêm hoặc xóa các loại thực thể
-- Nó loại bỏ các thuộc tính khỏi các loại thực thể
-- Nó thêm các thuộc tính nullable vào các loại thực thể
-- Nó biến các thuộc tính không thể nullable thành các thuộc tính nullable
-- Nó thêm giá trị vào enums
-- Nó thêm hoặc xóa các giao diện
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
 - Nó thay đổi đối với loại thực thể nào mà một giao diện được triển khai
 
 > **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 7040ba687bdca34141dd8047113de52ca118e1e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:28 -0500
Subject: [PATCH 0128/3820] New translations install-the-cli.mdx (Vietnamese)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/vi/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/vi/developing/creating-a-subgraph/install-the-cli.mdx
index ce25fbcafc6d..92e75af5d3ad 100644
--- a/website/pages/vi/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/vi/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is
 
 ## SpecVersion Releases
 
-| Phiên bản | Ghi chú phát hành |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| Phiên bản | Ghi chú phát hành                                                                                                                                                        |
+| :-------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|   1.2.0   | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|   1.1.0   | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|   1.0.0   | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|   0.0.9   | Supports `endBlock` feature                                                                                                                                              |
+|   0.0.8   | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|   0.0.7   | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|   0.0.6   | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|   0.0.5   | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|   0.0.4   | Added support for managing subgraph features.                                                                                                                            |

From 1c65274287dc29abdbf1499d064b9c1d9ea2037a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:29 -0500
Subject: [PATCH 0129/3820] New translations ql-schema.mdx (Vietnamese)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/vi/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/vi/developing/creating-a-subgraph/ql-schema.mdx
index 6f440ca3ca8c..4367bbd4b7f1 100644
--- a/website/pages/vi/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/vi/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Loại | Miêu tả |
-| --- | --- |
-| `Bytes` | Mảng byte, được biểu diễn dưới dạng chuỗi thập lục phân. Thường được sử dụng cho các mã băm và địa chỉ Ethereum. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Loại         | Miêu tả                                                                                                                                                                                                          |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Mảng byte, được biểu diễn dưới dạng chuỗi thập lục phân. Thường được sử dụng cho các mã băm và địa chỉ Ethereum.                                                                                                 |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 

From b4f44e994c83fc5ddad7464317c7012f03d52d0a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:33 -0500
Subject: [PATCH 0130/3820] New translations unit-testing-framework.mdx
 (Marathi)

---
 .../pages/mr/developing/unit-testing-framework.mdx   | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/mr/developing/unit-testing-framework.mdx b/website/pages/mr/developing/unit-testing-framework.mdx
index 86ac5cbcd673..9c56efe911c4 100644
--- a/website/pages/mr/developing/unit-testing-framework.mdx
+++ b/website/pages/mr/developing/unit-testing-framework.mdx
@@ -1380,20 +1380,20 @@ ___ ___ _ _ _ _ _
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > त्रुटी TS2554: अपेक्षित आहे? युक्तिवाद, पण मिळाले?.
->
+> 
 > नवीन ethereum.Transaction परत करा(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 `graph-ts` आणि `matchstick-as` मधील जुळत नसल्यामुळे वितर्कांमधील जुळत नाही. यासारख्या समस्यांचे निराकरण करण्याचा सर्वोत्तम मार्ग म्हणजे नवीनतम रिलीझ केलेल्या आवृत्तीवर सर्वकाही अद्यतनित करणे.
 
-## Additional Resources
+## अतिरिक्त संसाधने
 
 For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
 

From 6a76ac4744823d5572d863e502b30363d274f946 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:34 -0500
Subject: [PATCH 0131/3820] New translations graphql-api.mdx (Marathi)

---
 website/pages/mr/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/mr/querying/graphql-api.mdx b/website/pages/mr/querying/graphql-api.mdx
index ed5f483cfc2a..7fefa001aca4 100644
--- a/website/pages/mr/querying/graphql-api.mdx
+++ b/website/pages/mr/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 Fulltext search operators:
 
-| Symbol | Operator | वर्णन |
-| --- | --- | --- |
-| `&` | `आणि` | For combining multiple search terms into a filter for entities that include all of the provided terms |
-| &#x7c; | `किंवा` | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
-| `<->` | `द्वारे अनुसरण करा` | Specify the distance between two words. |
-| `:*` | `Prefix` | Use the prefix search term to find words whose prefix match (2 characters required.) |
+| Symbol      | Operator            | वर्णन                                                                                                                                |
+| ----------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `आणि`               | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| &#x7c;      | `किंवा`             | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->` | `द्वारे अनुसरण करा` | Specify the distance between two words.                                                                                              |
+| `:*`        | `Prefix`            | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 
 #### Examples
 

From 20372dd039930bd277a408fa0b07badc422edb00 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:36 -0500
Subject: [PATCH 0132/3820] New translations api.mdx (Marathi)

---
 website/pages/mr/developing/graph-ts/api.mdx | 22 ++++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/mr/developing/graph-ts/api.mdx b/website/pages/mr/developing/graph-ts/api.mdx
index 1ab6b8e6fad8..5fd1e1635c4e 100644
--- a/website/pages/mr/developing/graph-ts/api.mdx
+++ b/website/pages/mr/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| आवृत्ती | रिलीझ नोट्स |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| आवृत्ती | रिलीझ नोट्स                                                                                                                                                                                                                                   |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### अंगभूत प्रकार
 
@@ -376,7 +376,7 @@ store.remove('Transfer', id)
 
 ### इथरियम API
 
-Ethereum API स्मार्ट कॉन्ट्रॅक्ट्स, पब्लिक स्टेट व्हेरिएबल्स, कॉन्ट्रॅक्ट फंक्शन्स, इव्हेंट्स, व्यवहार, ब्लॉक्स आणि एन्कोडिंग/डिकोडिंग इथरियम डेटामध्ये प्रवेश प्रदान करते.
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
 
 #### इथरियम प्रकारांसाठी समर्थन
 

From 103779b1efd0caf23dbfa1f3fd93c6711349c7c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:37 -0500
Subject: [PATCH 0133/3820] New translations transfer-to-the-graph.mdx
 (Marathi)

---
 website/pages/mr/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/cookbook/transfer-to-the-graph.mdx b/website/pages/mr/cookbook/transfer-to-the-graph.mdx
index 3ab0ac609022..9398cd9703a2 100644
--- a/website/pages/mr/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/mr/cookbook/transfer-to-the-graph.mdx
@@ -98,7 +98,7 @@ You can create API Keys in Subgraph Studio under the “API Keys” menu at the
 
 Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
 
-### Additional Resources
+### अतिरिक्त संसाधने
 
 - To quickly create and publish a new subgraph, check out the [Quick Start](/quick-start/).
 - To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 333b4861fd9290ffb8eaeb3507d8681667c75568 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:38 -0500
Subject: [PATCH 0134/3820] New translations advanced.mdx (Marathi)

---
 website/pages/mr/developing/creating-a-subgraph/advanced.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/developing/creating-a-subgraph/advanced.mdx b/website/pages/mr/developing/creating-a-subgraph/advanced.mdx
index 0908f93a2214..7f833e7989c8 100644
--- a/website/pages/mr/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/mr/developing/creating-a-subgraph/advanced.mdx
@@ -547,7 +547,7 @@ When a subgraph whose manifest contains a `graft` block is deployed, Graph Node
 - हे घटक प्रकार जोडते किंवा काढून टाकते
 - हे घटक प्रकारातील गुणधर्म काढून टाकते
 - हे अस्तित्व प्रकारांमध्ये रद्द करण्यायोग्य विशेषता जोडते
-- हे नॉन-नलेबल अॅट्रिब्यूट्सना न्युलेबल अॅट्रिब्यूटमध्ये बदलते
+- हे नॉन-नलेबल अॅट्रिब्यूट्सना न्युलेबल अॅट्रिब्यूट्समध्ये बदलते
 - हे enums मध्ये मूल्ये जोडते
 - हे इंटरफेस जोडते किंवा काढून टाकते
 - कोणत्या घटकासाठी इंटरफेस लागू केला जातो ते बदलते

From 4e1356b1c8311218dedc743fb9553675782ae4fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:41 -0500
Subject: [PATCH 0135/3820] New translations install-the-cli.mdx (Marathi)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/mr/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/mr/developing/creating-a-subgraph/install-the-cli.mdx
index 7c50a40e48fd..4489fad1955b 100644
--- a/website/pages/mr/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/mr/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The ABI file(s) must match your contract(s). There are a few ways to obtain ABI
 
 ## SpecVersion Releases
 
-| आवृत्ती | रिलीझ नोट्स |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| आवृत्ती | रिलीझ नोट्स                                                                                                                                                              |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 40864ac0855ef3d400831fd3e377929d13034674 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:42 -0500
Subject: [PATCH 0136/3820] New translations ql-schema.mdx (Marathi)

---
 .../creating-a-subgraph/ql-schema.mdx         | 64 +++++++++----------
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/website/pages/mr/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/mr/developing/creating-a-subgraph/ql-schema.mdx
index 57d5ceb7ecf7..5d567ca32ddc 100644
--- a/website/pages/mr/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/mr/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| प्रकार | वर्णन |
-| --- | --- |
-| `Bytes` | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| प्रकार       | वर्णन                                                                                                                                                                                                            |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### एनम्स
 
@@ -283,30 +283,30 @@ query {
 
 समर्थित भाषा शब्दकोश:
 
-| Code | शब्दकोश   |
-| ---- | --------- |
-| सोपे | General   |
-| da   | Danish    |
-| nl   | Dutch     |
-| en   | English   |
-| fi   | Finnish   |
-| fr   | French    |
-| de   | German    |
-| hu   | Hungarian |
-| it   | Italian   |
-| no   | Norwegian |
-| pt   | पोर्तुगीज |
-| ro   | Romanian  |
-| ru   | Russian   |
-| es   | Spanish   |
-| sv   | Swedish   |
-| tr   | Turkish   |
+| Code   | शब्दकोश    |
+| ------ | ---------- |
+| सोपे   | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | पोर्तुगीज  |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
 
 ### रँकिंग अल्गोरिदम
 
 परिणाम ऑर्डर करण्यासाठी समर्थित अल्गोरिदम:
 
-| Algorithm     | Description                                                            |
-| ------------- | ---------------------------------------------------------------------- |
-| rank          | निकाल ऑर्डर करण्यासाठी फुलटेक्स्ट क्वेरीची जुळणी गुणवत्ता (0-1) वापरा. |
-| proximityRank | Similar to rank but also includes the proximity of the matches.        |
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | निकाल ऑर्डर करण्यासाठी फुलटेक्स्ट क्वेरीची जुळणी गुणवत्ता (0-1) वापरा.  |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From 60b17405d6f17992409a450f45115efd84c689bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:44 -0500
Subject: [PATCH 0137/3820] New translations about.mdx (Hindi)

---
 website/pages/hi/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/about.mdx b/website/pages/hi/about.mdx
index 182d6d6b068e..e2937886768f 100644
--- a/website/pages/hi/about.mdx
+++ b/website/pages/hi/about.mdx
@@ -28,7 +28,7 @@ The Graph एक शक्तिशाली विकेंद्रीकृ
 
 ब्लॉकचेन की विशेषताएँ, जैसे अंतिमता, चेन पुनर्गठन, और अंकल ब्लॉक्स, प्रक्रिया में जटिलता जोड़ती हैं, जिससे ब्लॉकचेन डेटा से सटीक क्वेरी परिणाम प्राप्त करना समय लेने वाला और अवधारणात्मक रूप से चुनौतीपूर्ण हो जाता है।
 
-## The Graph एक समाधान प्रदान करता है
+## The Graph  एक समाधान प्रदान करता है
 
 The Graph इस चुनौती को एक विकेन्द्रीकृत प्रोटोकॉल के माध्यम से हल करता है जो ब्लॉकचेन डेटा को इंडेक्स करता है और उसकी कुशल और उच्च-प्रदर्शन वाली क्वेरी करने की सुविधा प्रदान करता है। ये एपीआई (इंडेक्स किए गए "सबग्राफ") फिर एक मानक GraphQL एपीआई के साथ क्वेरी की जा सकती हैं।
 

From 018919d9b1fd09e9c756790aa67ec6d22c28109f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:46 -0500
Subject: [PATCH 0138/3820] New translations unit-testing-framework.mdx (Hindi)

---
 .../hi/developing/unit-testing-framework.mdx     | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/hi/developing/unit-testing-framework.mdx b/website/pages/hi/developing/unit-testing-framework.mdx
index 30433a184d2b..866dcf0fb01c 100644
--- a/website/pages/hi/developing/unit-testing-framework.mdx
+++ b/website/pages/hi/developing/unit-testing-framework.mdx
@@ -420,7 +420,7 @@ describe('handleUpdatedGravatars', () => {
 
 उदाहरण:
 
-प्रत्येक परीक्षण के बाद `afterEach` के अंदर का कोड निष्पादित होगा।
+प्रत्येक परीक्षण के बाद ` afterEach ` के अंदर का कोड निष्पादित होगा।
 
 ```typescript
 import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
@@ -459,7 +459,7 @@ describe("handleUpdatedGravatar", () => {
 })
 ```
 
-उस वर्णन में प्रत्येक परीक्षण के बाद `afterEach` के अंदर का कोड निष्पादित होगा
+उस वर्णन में प्रत्येक परीक्षण के बाद ` afterEach ` के अंदर का कोड निष्पादित होगा
 
 ```typescript
 import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
@@ -1380,20 +1380,20 @@ Global test coverage: 22.2% (2/9 handlers).
 इसका मतलब है कि आपने अपने कोड में ``console.log`\` का उपयोग किया है, जिसे AssemblyScript द्वारा सपोर्ट नहीं किया जाता है। कृपया [Logging API](/developing/graph-ts/api/#logging-api) का उपयोग करने पर विचार करें।
 
 > त्रुटि TS2554: अपेक्षित? तर्क, लेकिन मिला ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > त्रुटि TS2554: अपेक्षित? तर्क, लेकिन मिला ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 तर्कों में बेमेल `ग्राफ़-टीएस` और `मैचस्टिक-एज़` में बेमेल होने के कारण होता है। इस तरह की समस्याओं को ठीक करने का सबसे अच्छा तरीका है कि सभी चीज़ों को नवीनतम रिलीज़ किए गए संस्करण में अपडेट कर दिया जाए.
 
-## अतिरिक्त संसाधन
+## Additional Resources
 
 For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
 

From d31328c700ea8bbb88e4d7925eab9cfe1a049f13 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:48 -0500
Subject: [PATCH 0139/3820] New translations graphql-api.mdx (Hindi)

---
 website/pages/hi/querying/graphql-api.mdx | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/hi/querying/graphql-api.mdx b/website/pages/hi/querying/graphql-api.mdx
index 999a29b08e1a..8c0678c9608f 100644
--- a/website/pages/hi/querying/graphql-api.mdx
+++ b/website/pages/hi/querying/graphql-api.mdx
@@ -6,7 +6,7 @@ The Graph में उपयोग किए जाने वाले GraphQL
 
 ## GraphQL क्या है?
 
-[GraphQL](https://graphql.org/learn/) APIs के लिए एक क्वेरी भाषा और आपके मौजूदा डेटा के साथ उन क्वेरीज़ को पूरा करने के लिए एक रनटाइम। The Graph सबग्राफ को क्वेरी करने के लिए GraphQL का उपयोग करता है।
+[GraphQL](https://graphql.org/learn/) APIs  के लिए एक क्वेरी भाषा और आपके मौजूदा डेटा के साथ उन क्वेरीज़ को पूरा करने के लिए एक रनटाइम। The Graph सबग्राफ को क्वेरी करने के लिए GraphQL का उपयोग करता है।
 
 GraphQL की बड़ी भूमिका को समझने के लिए, [developing](/network/developing/) और [creating a subgraph](/developing/creating-a-subgraph/) की समीक्षा करें।
 
@@ -105,7 +105,7 @@ GraphQL की बड़ी भूमिका को समझने के ल
 
 #### उदाहरण का उपयोग करना `पहले` और `छोड़ें`
 
-क्वेरी 10 `टोकन` इकाइयां, संग्रह की शुरुआत से 10 स्थानों से ऑफसेट:
+क्वेरी 10 ` टोकन ` इकाइयां, संग्रह की शुरुआत से 10 स्थानों से ऑफसेट:
 
 ```graphql
 {
@@ -221,7 +221,7 @@ This can be useful if you are looking to fetch only entities which have changed,
 ```
 
 > **सिंटैक्टिक शुगर:** आप `और` ऑपरेटर को कॉमा द्वारा अलग किए गए सब-एक्सप्रेशन को पास करके उपरोक्त क्वेरी को सरल बना सकते हैं।
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltext search query fields provide an expressive text search API that can be a
 
 पूर्ण पाठ खोज ऑपरेटर:
 
-| प्रतीक | ऑपरेटर | विवरण |
-| --- | --- | --- |
-| `&` | `And` | सभी प्रदान किए गए शब्दों को शामिल करने वाली संस्थाओं के लिए एक से अधिक खोज शब्दों को फ़िल्टर में संयोजित करने के लिए |
-| &#x7c; | `Or` | या ऑपरेटर द्वारा अलग किए गए एकाधिक खोज शब्दों वाली क्वेरी सभी संस्थाओं को प्रदान की गई शर्तों में से किसी से मेल के साथ वापस कर देगी |
-| `<->` | `Follow by` | दो शब्दों के बीच की दूरी निर्दिष्ट करें। |
-| `:*` | `Prefix` | उन शब्दों को खोजने के लिए उपसर्ग खोज शब्द का उपयोग करें जिनके उपसर्ग मेल खाते हैं (2 वर्ण आवश्यक हैं।) |
+| प्रतीक      | ऑपरेटर      | Description                                                                                                                          |
+| ----------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `And`       | सभी प्रदान किए गए शब्दों को शामिल करने वाली संस्थाओं के लिए एक से अधिक खोज शब्दों को फ़िल्टर में संयोजित करने के लिए                 |
+| &#x7c;      | `Or`        | या ऑपरेटर द्वारा अलग किए गए एकाधिक खोज शब्दों वाली क्वेरी सभी संस्थाओं को प्रदान की गई शर्तों में से किसी से मेल के साथ वापस कर देगी |
+| `<->` | `Follow by` | दो शब्दों के बीच की दूरी निर्दिष्ट करें।                                                                                             |
+| `:*`        | `Prefix`    | उन शब्दों को खोजने के लिए उपसर्ग खोज शब्द का उपयोग करें जिनके उपसर्ग मेल खाते हैं (2 वर्ण आवश्यक हैं।)                               |
 
 #### उदाहरण
 

From d4e0de9130adbd58d855ea81a4f1ff98550ce25a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:49 -0500
Subject: [PATCH 0140/3820] New translations advanced.mdx (Hindi)

---
 .../pages/hi/developing/creating-a-subgraph/advanced.mdx   | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/website/pages/hi/developing/creating-a-subgraph/advanced.mdx b/website/pages/hi/developing/creating-a-subgraph/advanced.mdx
index b92e6528b52f..282e58c4f144 100644
--- a/website/pages/hi/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/hi/developing/creating-a-subgraph/advanced.mdx
@@ -521,6 +521,7 @@ calls:
 ```yaml
 calls:
   - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+
 ```
 
 ### मौजूदा सबग्राफ पर ग्राफ्टिंग
@@ -542,10 +543,10 @@ When a subgraph whose manifest contains a `graft` block is deployed, Graph Node
 
 क्योंकि आधार डेटा को अनुक्रमित करने के बजाय प्रतियों को ग्राफ्ट करना, स्क्रैच से अनुक्रमणित करने की तुलना में सबग्राफ को वांछित ब्लॉक में प्राप्त करना बहुत तेज है, हालांकि बहुत बड़े सबग्राफ के लिए प्रारंभिक डेटा कॉपी में अभी भी कई घंटे लग सकते हैं। जबकि ग्राफ्टेड सबग्राफ को इनिशियलाइज़ किया जा रहा है, ग्राफ़ नोड उन एंटिटी प्रकारों के बारे में जानकारी लॉग करेगा जो पहले ही कॉपी किए जा चुके हैं।
 
-ग्राफ्टेड सबग्राफ एक ग्राफक्यूएल स्कीमा का उपयोग कर सकता है जो बेस सबग्राफ के समान नहीं है, लेकिन इसके साथ केवल संगत है। यह अपने आप में एक मान्य सबग्राफ स्कीमा होना चाहिए, लेकिन निम्नलिखित तरीकों से बेस सबग्राफ के स्कीमा से विचलित हो सकता है:
+ग्राफ्टेड सबग्राफ एक ग्राफक्यूएल स्कीमा का उपयोग कर सकता है जो बेस सबग्राफ के समान नहीं है, लेकिन इसके अनुकूल हो। यह अपने आप में एक मान्य सबग्राफ स्कीमा होना चाहिए, लेकिन निम्नलिखित तरीकों से बेस सबग्राफ के स्कीमा से विचलित हो सकता है:
 
-- यह इकाई प्रकार जोड़ता या हटाता है
-- यह इकाई प्रकारों से विशेषताएँ निकालता है
+- यह इकाई के प्रकारों को जोड़ या हटा सकता है|
+- यह इकाई प्रकारों में से गुणों को हटाता है|
 - यह प्रभावहीन गुणों को इकाई प्रकारों में जोड़ता है|
 - यह प्रभाव वाले गुणों को प्रभावहीन गुणों में बदल देता है|
 - यह इनम्स में महत्व देता है|

From 6a9fb30a4fb9fc44283de3df3c4c8539317fc656 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:51 -0500
Subject: [PATCH 0141/3820] New translations install-the-cli.mdx (Hindi)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/hi/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/hi/developing/creating-a-subgraph/install-the-cli.mdx
index f4ddd954e659..0779e3ce1511 100644
--- a/website/pages/hi/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/hi/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is
 
 ## स्पेकवर्जन रिलीज़
 
-| संस्करण | रिलीज नोट्स |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | घटना हैंडलरों को लेनदेन रसीदों तक पहुंच प्रदान करने के लिए समर्थन जोड़ा गया है। |
-| 0.0.4 | घटना हैंडलरों को लेनदेन रसीदों तक पहुंच प्रदान करने के लिए समर्थन जोड़ा गया है। |
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | घटना हैंडलरों को लेनदेन रसीदों तक पहुंच प्रदान करने के लिए समर्थन जोड़ा गया है।                                                                                          |
+|  0.0.4  | घटना हैंडलरों को लेनदेन रसीदों तक पहुंच प्रदान करने के लिए समर्थन जोड़ा गया है।                                                                                          |

From 6bb3cffbacb046c60560a4db892349c0235436ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:52 -0500
Subject: [PATCH 0142/3820] New translations ql-schema.mdx (Hindi)

---
 .../creating-a-subgraph/ql-schema.mdx         | 56 +++++++++----------
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/website/pages/hi/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/hi/developing/creating-a-subgraph/ql-schema.mdx
index cc56484e1fb3..a5057c9a7a29 100644
--- a/website/pages/hi/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/hi/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 नीचे दिए गए स्केलर्स GraphQL API में समर्थित हैं:
 
-| प्रकार | विवरण |
-| --- | --- |
-| `Bytes` | बाइट सरणी, एक हेक्साडेसिमल स्ट्रिंग के रूप में दर्शाया गया है। आमतौर पर एथेरियम हैश और पतों के लिए उपयोग किया जाता है। |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| प्रकार       | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | बाइट सरणी, एक हेक्साडेसिमल स्ट्रिंग के रूप में दर्शाया गया है। आमतौर पर एथेरियम हैश और पतों के लिए उपयोग किया जाता है।                                                                                           |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 
@@ -283,24 +283,24 @@ query {
 
 समर्थित भाषा शब्दकोश:
 
-| Code   | शब्दकोष   |
-| ------ | --------- |
-| simple | General   |
-| da     | Danish    |
-| nl     | Dutch     |
-| en     | English   |
-| fi     | Finnish   |
-| fr     | French    |
-| de     | German    |
-| hu     | Hungarian |
-| it     | Italian   |
-| no     | Norwegian |
-| pt     | पुर्तगाली |
-| ro     | Romanian  |
-| ru     | Russian   |
-| es     | Spanish   |
-| sv     | Swedish   |
-| tr     | Turkish   |
+| Code   | शब्दकोष    |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | पुर्तगाली  |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
 
 ### रैंकिंग एल्गोरिदम
 

From 42fc5f038deea933c2c65935e039b478fdd8ec7f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:53 -0500
Subject: [PATCH 0143/3820] New translations subgraph-manifest.mdx (Hindi)

---
 .../hi/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/hi/developing/creating-a-subgraph/subgraph-manifest.mdx
index 3afa290667f2..7a554404dd2c 100644
--- a/website/pages/hi/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/hi/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -20,7 +20,7 @@ subgraph मैनिफेस्ट, subgraph.yaml, उन स्मार्
 
 - कई स्मार्ट कॉन्ट्रैक्ट्स से डेटा को इंडेक्स करें (लेकिन कई नेटवर्क नहीं)।
 
-- IPFS फ़ाइलों से डेटा को डेटा स्रोत फ़ाइलें का उपयोग करके अनुक्रमित करें।
+- IPFS फ़ाइलों से डेटा को डेटा स्रोत फ़ाइलें  का उपयोग करके अनुक्रमित करें।
 
 - Add an entry for each contract that requires indexing to the `dataSources` array.
 

From 7f7be63838805d8449ce879b7614bf31cd5d6618 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:57 -0500
Subject: [PATCH 0144/3820] New translations unit-testing-framework.mdx
 (Swahili)

---
 website/pages/sw/developing/unit-testing-framework.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/sw/developing/unit-testing-framework.mdx b/website/pages/sw/developing/unit-testing-framework.mdx
index 553eec2157b3..53a5c43dedcf 100644
--- a/website/pages/sw/developing/unit-testing-framework.mdx
+++ b/website/pages/sw/developing/unit-testing-framework.mdx
@@ -1380,15 +1380,15 @@ The log output includes the test run duration. Here's an example:
 This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/developing/graph-ts/api/#logging-api)
 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(18,12)
->
+> 
 > ERROR TS2554: Expected ? arguments, but got ?.
->
+> 
 > return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
->
+> 
 > in ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.

From c27f3241d22c14ae803463e48db46d3b6c6acdbd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 10:59:58 -0500
Subject: [PATCH 0145/3820] New translations graphql-api.mdx (Swahili)

---
 website/pages/sw/querying/graphql-api.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/sw/querying/graphql-api.mdx b/website/pages/sw/querying/graphql-api.mdx
index 3dd70fc7b004..d8671e53a77c 100644
--- a/website/pages/sw/querying/graphql-api.mdx
+++ b/website/pages/sw/querying/graphql-api.mdx
@@ -221,7 +221,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 ```
 
 > **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
->
+> 
 > ```graphql
 > {
 >   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 Fulltext search operators:
 
-| Symbol | Operator | Description |
-| --- | --- | --- |
-| `&` | `And` | For combining multiple search terms into a filter for entities that include all of the provided terms |
-| &#x7c; | `Or` | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
-| `<->` | `Follow by` | Specify the distance between two words. |
-| `:*` | `Prefix` | Use the prefix search term to find words whose prefix match (2 characters required.) |
+| Symbol      | Operator    | Description                                                                                                                          |
+| ----------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| &#x7c;      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->` | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`        | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 
 #### Examples
 

From efbd37bc3477ad312819f6cb2810164c4d5aba2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:00:00 -0500
Subject: [PATCH 0146/3820] New translations api.mdx (Swahili)

---
 website/pages/sw/developing/graph-ts/api.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/sw/developing/graph-ts/api.mdx b/website/pages/sw/developing/graph-ts/api.mdx
index 6a0c4e208b99..8fc1f4b48b61 100644
--- a/website/pages/sw/developing/graph-ts/api.mdx
+++ b/website/pages/sw/developing/graph-ts/api.mdx
@@ -29,16 +29,16 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| Version | Release notes |
-| :-: | --- |
-| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa) |
-| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity. |
-| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object |
-| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object |
-| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object |
-| 0.0.3 | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to` |
-| 0.0.2 | Added `input` field to the Ethereum Transaction object |
+| Version | Release notes                                                                                                                                                                                                                                 |
+| :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                    |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/release-notes/assemblyscript-migration-guide))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                      |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
 ### Built-in Types
 

From 818b16bbf83f47379d772515fd1f707bfad60d72 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:00:07 -0500
Subject: [PATCH 0147/3820] New translations install-the-cli.mdx (Swahili)

---
 .../creating-a-subgraph/install-the-cli.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/sw/developing/creating-a-subgraph/install-the-cli.mdx b/website/pages/sw/developing/creating-a-subgraph/install-the-cli.mdx
index 282c68973a8a..5897ae02b134 100644
--- a/website/pages/sw/developing/creating-a-subgraph/install-the-cli.mdx
+++ b/website/pages/sw/developing/creating-a-subgraph/install-the-cli.mdx
@@ -106,14 +106,14 @@ The ABI file(s) must match your contract(s). There are a few ways to obtain ABI
 
 ## SpecVersion Releases
 
-| Version | Release notes |
-| :-: | --- |
-| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call` |
-| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`. |
-| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs |
-| 0.0.9 | Supports `endBlock` feature |
-| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources). |
-| 0.0.6 | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant. |
-| 0.0.5 | Added support for event handlers having access to transaction receipts. |
-| 0.0.4 | Added support for managing subgraph features. |
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/network/indexing/#what-is-a-proof-of-indexing-poi) calculation variant.                                                               |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From fa617f4f64970c6bba65666d9ab50da3e9ce9d77 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:00:10 -0500
Subject: [PATCH 0148/3820] New translations ql-schema.mdx (Swahili)

---
 .../creating-a-subgraph/ql-schema.mdx         | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/sw/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/sw/developing/creating-a-subgraph/ql-schema.mdx
index 90036d1bfab9..3df39853f82b 100644
--- a/website/pages/sw/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/sw/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Type | Description |
-| --- | --- |
-| `Bytes` | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses. |
-| `String` | Scalar for `string` values. Null characters are not supported and are automatically removed. |
-| `Boolean` | Scalar for `boolean` values. |
-| `Int` | The GraphQL spec defines `Int` to be a signed 32-bit integer. |
-| `Int8` | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt` | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`. |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits. |
-| `Timestamp` | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations. |
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
 
 ### Enums
 

From 47952b628a68ec3447544f5144e5e61b0704435b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:00:15 -0500
Subject: [PATCH 0149/3820] New translations cosmos.mdx (French)

---
 website/pages/fr/cookbook/cosmos.mdx | 44 ++++++++++++++--------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/website/pages/fr/cookbook/cosmos.mdx b/website/pages/fr/cookbook/cosmos.mdx
index ed318635f292..d21938a729dd 100644
--- a/website/pages/fr/cookbook/cosmos.mdx
+++ b/website/pages/fr/cookbook/cosmos.mdx
@@ -48,30 +48,30 @@ La définition d'un subgraph comporte trois éléments clés :
 Le manifeste du subgraph (`subgraph.yaml`) identifie les sources de données du subgraph, les déclencheurs d'intérêt et les fonctions (`handlers`) qui doivent être exécutées en réponse à ces déclencheurs. Vous trouverez ci-dessous un exemple de manifeste de subgraph pour un subgraph Cosmos :
 
 ```yaml
-version spec: 0.0.5
-description: Exemple de subgraph Cosmos
+version spec : 0.0.5
+description : Exemple de subgraph Cosmos
 schéma:
-  fichier: ./schema.graphql # lien vers le fichier de schéma
+   fichier : ./schema.graphql # lien vers le fichier de schéma
 les sources de données:
-  - genre: cosmos
-    nom: CosmosHub
-    réseau: cosmoshub-4 # Cela changera pour chaque blockchain basée sur le cosmos. Dans ce cas, l’exemple utilise le mainnet Cosmos Hub.
-    source:
-      startBlock: 0 # Requis pour Cosmos, définissez-le sur 0 pour démarrer l'indexation à partir de la genèse de la chaîne
-    cartographie:
-      Version api: 0.0.7
-      langage: wasm/assemblyscript
-      gestionnaires de blocs:
-        - handler: handleNewBlock # le nom de la fonction dans le fichier de mappage
-      Gestionnaires d'événements:
-        - event: récompenses # le type d'événement qui sera géré
-          handler: handleReward # le nom de la fonction dans le fichier de mappage
-      Gestionnaires de transactions:
-        - handler: handleTransaction # le nom de la fonction dans le fichier de mappage
-      Gestionnaires de messages:
-        - message: /cosmos.staking.v1beta1.MsgDelegate # le type d'un message
-          handler: handleMsgDelegate # le nom de la fonction dans le fichier de mappage
-      fichier: ./src/mapping.ts # lien vers le fichier avec les mappages Assemblyscript
+   - genre : cosmos
+     nom : CosmosHub
+     réseau : cosmoshub-4 # Cela changera pour chaque blockchain basée sur le cosmos. Dans ce cas, l’exemple utilise le mainnet Cosmos Hub.
+     source:
+       startBlock : 0 # Requis pour Cosmos, définissez-le sur 0 pour démarrer l'indexation à partir de la genèse de la chaîne
+     cartographie :
+       Version api : 0.0.7
+       langage : wasm/assemblyscript
+       gestionnaires de blocs :
+         - handler: handleNewBlock # le nom de la fonction dans le fichier de mappage
+       Gestionnaires d'événements :
+         - event : récompenses # le type d'événement qui sera géré
+           handler: handleReward # le nom de la fonction dans le fichier de mappage
+       Gestionnaires de transactions :
+         - handler: handleTransaction # le nom de la fonction dans le fichier de mappage
+       Gestionnaires de messages :
+         - message : /cosmos.staking.v1beta1.MsgDelegate # le type d'un message
+           handler : handleMsgDelegate # le nom de la fonction dans le fichier de mappage
+       fichier : ./src/mapping.ts # lien vers le fichier avec les mappages Assemblyscript
 ```
 
 - Les subgraphs cosmos introduisent un nouveau `type` de source de données (`cosmos`).

From 6ba1c1066d20b5d50ee9021225ad6e99abd6384b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:00:56 -0500
Subject: [PATCH 0150/3820] New translations deploy-using-subgraph-studio.mdx
 (Hindi)

---
 website/pages/hi/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/deploying/deploy-using-subgraph-studio.mdx b/website/pages/hi/deploying/deploy-using-subgraph-studio.mdx
index b57efc206319..3f07a9b3b2e4 100644
--- a/website/pages/hi/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/hi/deploying/deploy-using-subgraph-studio.mdx
@@ -17,7 +17,7 @@ In <a href="https://thegraph.com/studio/">Subgraph Studio</a>,आप निम
 - अपना subgraph बनाएं
 - अपने subgraph को The Graph CLI का उपयोग करके डिप्लॉय करें
 - अपने 'subgraph' को 'playground' वातावरण में टेस्ट करें
-- अपने स्टेजिंग में 'subgraph' को विकास क्वेरी URL का उपयोग करके एकीकृत करें
+- अपने स्टेजिंग में 'subgraph' को विकास क्वेरी URL का उपयोग करके एकीकृत करें 
 - अपने subgraph को The Graph Network पर प्रकाशित करें
 - अपने बिलिंग को प्रबंधित करें
 
@@ -25,7 +25,7 @@ In <a href="https://thegraph.com/studio/">Subgraph Studio</a>,आप निम
 
 Deploy करने से पहले, आपको The Graph CLI इंस्टॉल करना होगा।
 
-आपको The Graph CLI का उपयोग करने के लिए Node.js(https://nodejs.org/) और आपकी पसंद का पैकेज मैनेजर (npm, yarn या pnpm) स्थापित होना चाहिए। सबसे हालिया (https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI संस्करण की जांच करें।
+आपको The Graph CLI का उपयोग करने के लिए Node.js(https://nodejs.org/)  और आपकी पसंद का पैकेज मैनेजर (npm, yarn या pnpm) स्थापित होना चाहिए। सबसे हालिया (https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI संस्करण की जांच करें।
 
 ### इंस्टॉल करें 'yarn' के साथ
 

From d19b1bec5a6ecc7f6d48241a04959f4b619d5ef2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:01:11 -0500
Subject: [PATCH 0151/3820] New translations enums.mdx (French)

---
 website/pages/fr/cookbook/enums.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/cookbook/enums.mdx b/website/pages/fr/cookbook/enums.mdx
index ac68bdc05ade..581ebd57e7cd 100644
--- a/website/pages/fr/cookbook/enums.mdx
+++ b/website/pages/fr/cookbook/enums.mdx
@@ -269,6 +269,6 @@ Expected output includes the marketplaces that meet the criteria, each represent
 }
 ```
 
-## Ressources additionnelles
+## Ressources complémentaires
 
 For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 48c4b2d29d6c6f00a580cbcb40bbf7df39798d82 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:01:20 -0500
Subject: [PATCH 0152/3820] New translations grafting-hotfix.mdx (French)

---
 website/pages/fr/cookbook/grafting-hotfix.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/cookbook/grafting-hotfix.mdx b/website/pages/fr/cookbook/grafting-hotfix.mdx
index fd32ece68e7e..db72fd93cdbd 100644
--- a/website/pages/fr/cookbook/grafting-hotfix.mdx
+++ b/website/pages/fr/cookbook/grafting-hotfix.mdx
@@ -164,7 +164,7 @@ Grafting is an effective strategy for deploying hotfixes in subgraph development
 
 However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
 
-## Ressources additionnelles
+## Ressources complémentaires
 
 - **[Grafting Documentation](/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
 - **[Understanding Deployment IDs](/querying/querying-by-subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.

From 2c2571e10c6d55999e662dc372ff6b1a7ee584fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:01:44 -0500
Subject: [PATCH 0153/3820] New translations enums.mdx (Hindi)

---
 website/pages/hi/cookbook/enums.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/cookbook/enums.mdx b/website/pages/hi/cookbook/enums.mdx
index 6ce7f9e84551..c542f7d54f90 100644
--- a/website/pages/hi/cookbook/enums.mdx
+++ b/website/pages/hi/cookbook/enums.mdx
@@ -269,6 +269,6 @@ Expected output includes the marketplaces that meet the criteria, each represent
 }
 ```
 
-## अतिरिक्त संसाधन
+## Additional Resources
 
 For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 71a13e87ed35cc9ffc16515e3bb62229befa927f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:02:13 -0500
Subject: [PATCH 0154/3820] New translations grafting-hotfix.mdx (Russian)

---
 website/pages/ru/cookbook/grafting-hotfix.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/cookbook/grafting-hotfix.mdx b/website/pages/ru/cookbook/grafting-hotfix.mdx
index 5d1b5f30770d..993b28090167 100644
--- a/website/pages/ru/cookbook/grafting-hotfix.mdx
+++ b/website/pages/ru/cookbook/grafting-hotfix.mdx
@@ -164,7 +164,7 @@ Grafting is an effective strategy for deploying hotfixes in subgraph development
 
 However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
 
-## Дополнительные источники
+## Дополнительные ресурсы
 
 - **[Grafting Documentation](/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
 - **[Understanding Deployment IDs](/querying/querying-by-subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.

From c3ef3548e0dc028bd70e0961a556c0f60a97e5c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:02:20 -0500
Subject: [PATCH 0155/3820] New translations triggers-example.mdx (French)

---
 website/pages/fr/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/sps/triggers-example.mdx b/website/pages/fr/sps/triggers-example.mdx
index 92f5cb305599..2b4aaa27a8ca 100644
--- a/website/pages/fr/sps/triggers-example.mdx
+++ b/website/pages/fr/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Conditions préalables

From ba0190fc1b6ef5d518ce64e3387f3167285bfe59 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:02:25 -0500
Subject: [PATCH 0156/3820] New translations grafting-hotfix.mdx (Ukrainian)

---
 website/pages/uk/cookbook/grafting-hotfix.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/cookbook/grafting-hotfix.mdx b/website/pages/uk/cookbook/grafting-hotfix.mdx
index 040e3a8209d5..c11b749ee1b2 100644
--- a/website/pages/uk/cookbook/grafting-hotfix.mdx
+++ b/website/pages/uk/cookbook/grafting-hotfix.mdx
@@ -164,7 +164,7 @@ Grafting is an effective strategy for deploying hotfixes in subgraph development
 
 However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
 
-## Additional Resources
+## Додаткові матеріали
 
 - **[Grafting Documentation](/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
 - **[Understanding Deployment IDs](/querying/querying-by-subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.

From 2f4e110a271f20bb8a185ad2d7386d969cd68f9d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:02:29 -0500
Subject: [PATCH 0157/3820] New translations triggers-example.mdx (Russian)

---
 website/pages/ru/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/sps/triggers-example.mdx b/website/pages/ru/sps/triggers-example.mdx
index 6ade2c0d8816..aa110f80d8f7 100644
--- a/website/pages/ru/sps/triggers-example.mdx
+++ b/website/pages/ru/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Предварительные требования

From 7c62f2d975d3b3b015d45f3dfc52290cc604da98 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:02:44 -0500
Subject: [PATCH 0158/3820] New translations grafting-hotfix.mdx (Marathi)

---
 website/pages/mr/cookbook/grafting-hotfix.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/cookbook/grafting-hotfix.mdx b/website/pages/mr/cookbook/grafting-hotfix.mdx
index 16ee51f808cd..c6bc5e330115 100644
--- a/website/pages/mr/cookbook/grafting-hotfix.mdx
+++ b/website/pages/mr/cookbook/grafting-hotfix.mdx
@@ -164,7 +164,7 @@ Grafting is an effective strategy for deploying hotfixes in subgraph development
 
 However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
 
-## Additional Resources
+## अतिरिक्त संसाधने
 
 - **[Grafting Documentation](/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
 - **[Understanding Deployment IDs](/querying/querying-by-subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.

From 52c7c0df1505f912f278e3f308899effb342909b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:02:48 -0500
Subject: [PATCH 0159/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Hindi)

---
 website/pages/hi/cookbook/immutable-entities-bytes-as-ids.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/hi/cookbook/immutable-entities-bytes-as-ids.mdx
index a58adda01cc3..4875006914e4 100644
--- a/website/pages/hi/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/hi/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -90,7 +90,7 @@ Query:
 }
 ```
 
-प्रश्न प्रतिक्रिया:
+प्रश्न प्रतिक्रिया: 
 
 ```json
 {
@@ -146,7 +146,7 @@ Query
 }
 ```
 
-प्रश्न प्रतिक्रिया:
+प्रश्न प्रतिक्रिया: 
 
 ```json
 {

From 1d4c14086ecdce7884dbeb1d8a24407565842a66 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:02:49 -0500
Subject: [PATCH 0160/3820] New translations grafting-hotfix.mdx (Hindi)

---
 website/pages/hi/cookbook/grafting-hotfix.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/cookbook/grafting-hotfix.mdx b/website/pages/hi/cookbook/grafting-hotfix.mdx
index 1c858096478b..ab7bfe16f9f8 100644
--- a/website/pages/hi/cookbook/grafting-hotfix.mdx
+++ b/website/pages/hi/cookbook/grafting-hotfix.mdx
@@ -164,7 +164,7 @@ Grafting is an effective strategy for deploying hotfixes in subgraph development
 
 However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
 
-## अतिरिक्त संसाधन
+## Additional Resources
 
 - **[Grafting Documentation](/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
 - **[Understanding Deployment IDs](/querying/querying-by-subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.

From bf5e0a558f1c19a35b816b903433afad21f9d457 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:02:56 -0500
Subject: [PATCH 0161/3820] New translations benefits.mdx (Romanian)

---
 website/pages/ro/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/ro/network/benefits.mdx b/website/pages/ro/network/benefits.mdx
index 47216a1b6219..b54165acd51b 100644
--- a/website/pages/ro/network/benefits.mdx
+++ b/website/pages/ro/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Cost Comparison | Self Hosted | Rețeaua The Graph |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $0+ | $0 per month |
-| Engineering time<sup>†</sup> | $400 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | 100,000 (Free Plan) |
-| Cost per query | $0 | $0<sup>‡</sup> |
-| Infrastructure | Centralized | Decentralized |
-| Geographic redundancy | $750+ per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" />$750+ | $0 |
+|       Cost Comparison        |               Self Hosted               |                        Rețeaua The Graph                        |
+|:----------------------------:|:---------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |             $350 per month              |                               $0                                |
+|         Query costs          |                   $0+                   |                          $0 per month                           |
+| Engineering time<sup>†</sup> |             $400 per month              | None, built into the network with globally distributed Indexers |
+|      Queries per month       |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                   $0                    |                         $0<sup>‡</sup>                          |
+|        Infrastructure        |               Centralized               |                          Decentralized                          |
+|    Geographic redundancy     |        $750+ per additional node        |                            Included                             |
+|            Uptime            |                 Varies                  |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" />$750+ |                               $0                                |
 
 ## Medium Volume User (~3M queries per month)
 
-| Cost Comparison | Self Hosted | Rețeaua The Graph |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $500 per month | $120 per month |
-| Engineering time<sup>†</sup> | $800 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~3,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Infrastructure | Centralized | Decentralized |
-| Engineering expense | $200 per hour | Included |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $1,650+ | $120 |
+|       Cost Comparison        |                Self Hosted                 |                        Rețeaua The Graph                        |
+|:----------------------------:|:------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |               $350 per month               |                               $0                                |
+|         Query costs          |               $500 per month               |                         $120 per month                          |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|      Queries per month       |       Limited to infra capabilities        |                           ~3,000,000                            |
+|        Cost per query        |                     $0                     |                            $0.00004                             |
+|        Infrastructure        |                Centralized                 |                          Decentralized                          |
+|     Engineering expense      |               $200 per hour                |                            Included                             |
+|    Geographic redundancy     | $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                   |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $1,650+ |                              $120                               |
 
 ## High Volume User (~30M queries per month)
 
-| Cost Comparison | Self Hosted | Rețeaua The Graph |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $1100 per month, per node | $0 |
-| Query costs | $4000 | $1,200 per month |
-| Number of nodes needed | 10 | Not applicable |
-| Engineering time<sup>†</sup> | $6,000 or more per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~30,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Infrastructure | Centralized | Decentralized |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $11,000+ | $1,200 |
+|       Cost Comparison        |                 Self Hosted                 |                        Rețeaua The Graph                        |
+|:----------------------------:|:-------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |          $1100 per month, per node          |                               $0                                |
+|         Query costs          |                    $4000                    |                        $1,200 per month                         |
+|    Number of nodes needed    |                     10                      |                         Not applicable                          |
+| Engineering time<sup>†</sup> |          $6,000 or more per month           | None, built into the network with globally distributed Indexers |
+|      Queries per month       |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                     $0                      |                            $0.00004                             |
+|        Infrastructure        |                 Centralized                 |                          Decentralized                          |
+|    Geographic redundancy     |  $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                    |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $11,000+ |                             $1,200                              |
 
 \*including costs for backup: $50-$100 per month
 

From 45800cb086c64b18ef8b15750a9ecc86e39336dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:02:58 -0500
Subject: [PATCH 0162/3820] New translations benefits.mdx (Spanish)

---
 website/pages/es/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/es/network/benefits.mdx b/website/pages/es/network/benefits.mdx
index 1b8a5510f076..f1055e96a426 100644
--- a/website/pages/es/network/benefits.mdx
+++ b/website/pages/es/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Comparación de costos | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Costo mensual del servidor\* | $350 por mes | $0 |
-| Costos de consulta | $0+ | $0 per month |
-| Tiempo de ingeniería<sup>†</sup> | $400 por mes | Ninguno, integrado en la red con Indexadores distribuidos globalmente |
-| Consultas por mes | Limitado a capacidades de infraestructura | 100,000 (Free Plan) |
-| Costo por consulta | $0 | $0<sup>‡</sup> |
-| Infraestructura | Centralizado | Descentralizado |
-| Redundancia geográfica | $750+ por nodo adicional | Incluido |
-| Tiempo de actividad | Varía | 99.9%+ |
-| Costos mensuales totales | <span className="highlight-row" />$750+ | $0 |
+|      Comparación de costos       |                Self Hosted                |                           The Graph Network                           |
+|:--------------------------------:|:-----------------------------------------:|:---------------------------------------------------------------------:|
+|  Costo mensual del servidor\*  |               $350 por mes                |                                  $0                                   |
+|        Costos de consulta        |                    $0+                    |                             $0 per month                              |
+| Tiempo de ingeniería<sup>†</sup> |               $400 por mes                | Ninguno, integrado en la red con Indexadores distribuidos globalmente |
+|        Consultas por mes         | Limitado a capacidades de infraestructura |                          100,000 (Free Plan)                          |
+|        Costo por consulta        |                    $0                     |                            $0<sup>‡</sup>                             |
+|         Infraestructura          |               Centralizado                |                            Descentralizado                            |
+|      Redundancia geográfica      |         $750+ por nodo adicional          |                               Incluido                                |
+|       Tiempo de actividad        |                   Varía                   |                                99.9%+                                 |
+|     Costos mensuales totales     |  <span className="highlight-row" />$750+  |                                  $0                                   |
 
 ## Medium Volume User (~3M queries per month)
 
-| Comparación de costos | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Costo mensual del servidor\* | $350 por mes | $0 |
-| Costos de consulta | $500 por mes | $120 per month |
-| Tiempo de ingeniería<sup>†</sup> | $800 por mes | Ninguno, integrado en la red con Indexadores distribuidos globalmente |
-| Consultas por mes | Limitado a capacidades de infraestructura | ~3,000,000 |
-| Costo por consulta | $0 | $0.00004 |
-| Infraestructura | Centralizado | Descentralizado |
-| Gastos de ingeniería | $200 por hora | Incluido |
-| Redundancia geográfica | $1,200 en costos totales por nodo adicional | Incluido |
-| Tiempo de actividad | Varía | 99.9%+ |
-| Costos mensuales totales | <span className="highlight-row" /> $1,650+ | $120 |
+|      Comparación de costos       |                 Self Hosted                 |                           The Graph Network                           |
+|:--------------------------------:|:-------------------------------------------:|:---------------------------------------------------------------------:|
+|  Costo mensual del servidor\*  |                $350 por mes                 |                                  $0                                   |
+|        Costos de consulta        |                $500 por mes                 |                            $120 per month                             |
+| Tiempo de ingeniería<sup>†</sup> |                $800 por mes                 | Ninguno, integrado en la red con Indexadores distribuidos globalmente |
+|        Consultas por mes         |  Limitado a capacidades de infraestructura  |                              ~3,000,000                               |
+|        Costo por consulta        |                     $0                      |                               $0.00004                                |
+|         Infraestructura          |                Centralizado                 |                            Descentralizado                            |
+|       Gastos de ingeniería       |                $200 por hora                |                               Incluido                                |
+|      Redundancia geográfica      | $1,200 en costos totales por nodo adicional |                               Incluido                                |
+|       Tiempo de actividad        |                    Varía                    |                                99.9%+                                 |
+|     Costos mensuales totales     | <span className="highlight-row" /> $1,650+  |                                 $120                                  |
 
 ## High Volume User (~30M queries per month)
 
-| Comparación de costos | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Costo mensual del servidor\* | $1100 por mes, por nodo | $0 |
-| Costos de consulta | $4000 | $1,200 per month |
-| Número de nodos necesarios | 10 | No aplica |
-| Tiempo de ingeniería<sup>†</sup> | $6,000 o más por mes | Ninguno, integrado en la red con Indexadores distribuidos globalmente |
-| Consultas por mes | Limitado a capacidades de infraestructura | ~30,000,000 |
-| Costo por consulta | $0 | $0.00004 |
-| Infraestructura | Centralizado | Descentralizado |
-| Redundancia geográfica | $1,200 en costos totales por nodo adicional | Incluido |
-| Tiempo de actividad | Varía | 99.9%+ |
-| Costos mensuales totales | <span className="highlight-row" /> $11,000+ | $1,200 |
+|      Comparación de costos       |                 Self Hosted                 |                           The Graph Network                           |
+|:--------------------------------:|:-------------------------------------------:|:---------------------------------------------------------------------:|
+|  Costo mensual del servidor\*  |           $1100 por mes, por nodo           |                                  $0                                   |
+|        Costos de consulta        |                    $4000                    |                           $1,200 per month                            |
+|    Número de nodos necesarios    |                     10                      |                               No aplica                               |
+| Tiempo de ingeniería<sup>†</sup> |            $6,000 o más por mes             | Ninguno, integrado en la red con Indexadores distribuidos globalmente |
+|        Consultas por mes         |  Limitado a capacidades de infraestructura  |                              ~30,000,000                              |
+|        Costo por consulta        |                     $0                      |                               $0.00004                                |
+|         Infraestructura          |                Centralizado                 |                            Descentralizado                            |
+|      Redundancia geográfica      | $1,200 en costos totales por nodo adicional |                               Incluido                                |
+|       Tiempo de actividad        |                    Varía                    |                                99.9%+                                 |
+|     Costos mensuales totales     | <span className="highlight-row" /> $11,000+ |                                $1,200                                 |
 
 \*incluidos los costos de copia de seguridad: $50-$100 por mes
 

From 869b9a10ca68e4c62684b12ebb040847b2875709 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:02:59 -0500
Subject: [PATCH 0163/3820] New translations benefits.mdx (Arabic)

---
 website/pages/ar/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/ar/network/benefits.mdx b/website/pages/ar/network/benefits.mdx
index 3bdd3f1e6e25..510e4e20eb78 100644
--- a/website/pages/ar/network/benefits.mdx
+++ b/website/pages/ar/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Cost Comparison | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $0+ | $0 per month |
-| Engineering time<sup>†</sup> | $400 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | 100,000 (Free Plan) |
-| Cost per query | $0 | $0<sup>‡</sup> |
-| البنية الأساسية | Centralized | Decentralized |
-| Geographic redundancy | $750+ per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" />$750+ | $0 |
+|       Cost Comparison        |               Self Hosted               |                        The Graph Network                        |
+|:----------------------------:|:---------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |             $350 per month              |                               $0                                |
+|         Query costs          |                   $0+                   |                          $0 per month                           |
+| Engineering time<sup>†</sup> |             $400 per month              | None, built into the network with globally distributed Indexers |
+|      Queries per month       |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                   $0                    |                         $0<sup>‡</sup>                          |
+|       البنية الأساسية        |               Centralized               |                          Decentralized                          |
+|    Geographic redundancy     |        $750+ per additional node        |                            Included                             |
+|            Uptime            |                 Varies                  |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" />$750+ |                               $0                                |
 
 ## Medium Volume User (~3M queries per month)
 
-| Cost Comparison | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $500 per month | $120 per month |
-| Engineering time<sup>†</sup> | $800 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~3,000,000 |
-| Cost per query | $0 | $0.00004 |
-| البنية الأساسية | Centralized | Decentralized |
-| Engineering expense | $200 per hour | Included |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $1,650+ | $120 |
+|       Cost Comparison        |                Self Hosted                 |                        The Graph Network                        |
+|:----------------------------:|:------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |               $350 per month               |                               $0                                |
+|         Query costs          |               $500 per month               |                         $120 per month                          |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|      Queries per month       |       Limited to infra capabilities        |                           ~3,000,000                            |
+|        Cost per query        |                     $0                     |                            $0.00004                             |
+|       البنية الأساسية        |                Centralized                 |                          Decentralized                          |
+|     Engineering expense      |               $200 per hour                |                            Included                             |
+|    Geographic redundancy     | $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                   |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $1,650+ |                              $120                               |
 
 ## High Volume User (~30M queries per month)
 
-| Cost Comparison | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $1100 per month, per node | $0 |
-| Query costs | $4000 | $1,200 per month |
-| Number of nodes needed | 10 | Not applicable |
-| Engineering time<sup>†</sup> | $6,000 or more per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~30,000,000 |
-| Cost per query | $0 | $0.00004 |
-| البنية الأساسية | Centralized | Decentralized |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $11,000+ | $1,200 |
+|       Cost Comparison        |                 Self Hosted                 |                        The Graph Network                        |
+|:----------------------------:|:-------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |          $1100 per month, per node          |                               $0                                |
+|         Query costs          |                    $4000                    |                        $1,200 per month                         |
+|    Number of nodes needed    |                     10                      |                         Not applicable                          |
+| Engineering time<sup>†</sup> |          $6,000 or more per month           | None, built into the network with globally distributed Indexers |
+|      Queries per month       |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                     $0                      |                            $0.00004                             |
+|       البنية الأساسية        |                 Centralized                 |                          Decentralized                          |
+|    Geographic redundancy     |  $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                    |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $11,000+ |                             $1,200                              |
 
 \*including costs for backup: $50-$100 per month
 

From 1b778323c0305741269219f914af2d9552fe954f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:00 -0500
Subject: [PATCH 0164/3820] New translations benefits.mdx (Czech)

---
 website/pages/cs/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/cs/network/benefits.mdx b/website/pages/cs/network/benefits.mdx
index 98d8bba2cb04..971f4a21f7e8 100644
--- a/website/pages/cs/network/benefits.mdx
+++ b/website/pages/cs/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Srovnání nákladů | Vlastní hostitel | The Graph Network |
-| :-: | :-: | :-: |
-| Měsíční náklady na server\* | $350 měsíčně | $0 |
-| Náklady na dotazování | $0+ | $0 per month |
-| Inženýrský čas<sup>†</sup> | $400 měsíčně | Žádné, zabudované do sítě s globálně distribuovanými indexery |
-| Dotazy za měsíc | Omezeno na infra schopnosti | 100,000 (Free Plan) |
-| Náklady na jeden dotaz | $0 | $0<sup>‡</sup> |
-| Infrastruktura | Centralizovaný | Decentralizované |
-| Geografická redundancy | $750+ Usd za další uzel | Zahrnuto |
-| Provozuschopnost | Různé | 99.9%+ |
-| Celkové měsíční náklady | <span className="highlight-row" />$750+ | $0 |
+|       Srovnání nákladů        |            Vlastní hostitel             |                       The Graph Network                       |
+|:-----------------------------:|:---------------------------------------:|:-------------------------------------------------------------:|
+| Měsíční náklady na server\* |              $350 měsíčně               |                              $0                               |
+|     Náklady na dotazování     |                   $0+                   |                         $0 per month                          |
+|  Inženýrský čas<sup>†</sup>   |              $400 měsíčně               | Žádné, zabudované do sítě s globálně distribuovanými indexery |
+|        Dotazy za měsíc        |       Omezeno na infra schopnosti       |                      100,000 (Free Plan)                      |
+|    Náklady na jeden dotaz     |                   $0                    |                        $0<sup>‡</sup>                         |
+|        Infrastruktura         |             Centralizovaný              |                       Decentralizované                        |
+|    Geografická redundancy     |         $750+ Usd za další uzel         |                           Zahrnuto                            |
+|       Provozuschopnost        |                  Různé                  |                            99.9%+                             |
+|    Celkové měsíční náklady    | <span className="highlight-row" />$750+ |                              $0                               |
 
 ## Medium Volume User (~3M queries per month)
 
-| Srovnání nákladů | Vlastní hostitel | The Graph Network |
-| :-: | :-: | :-: |
-| Měsíční náklady na server\* | $350 měsíčně | $0 |
-| Náklady na dotazování | $500 měsíčně | $120 per month |
-| Inženýrský čas<sup>†</sup> | $800 měsíčně | Žádné, zabudované do sítě s globálně distribuovanými indexery |
-| Dotazy za měsíc | Omezeno na infra schopnosti | ~3,000,000 |
-| Náklady na jeden dotaz | $0 | $0.00004 |
-| Infrastruktura | Centralizovaný | Decentralizované |
-| Výdaje inženýrskou | $200 za hodinu | Zahrnuto |
-| Geografická redundancy | $1,200 celkových nákladů na další uzel | Zahrnuto |
-| Provozuschopnost | Různé | 99.9%+ |
-| Celkové měsíční náklady | <span className="highlight-row" /> $1,650+ | $120 |
+|       Srovnání nákladů        |              Vlastní hostitel              |                       The Graph Network                       |
+|:-----------------------------:|:------------------------------------------:|:-------------------------------------------------------------:|
+| Měsíční náklady na server\* |                $350 měsíčně                |                              $0                               |
+|     Náklady na dotazování     |                $500 měsíčně                |                        $120 per month                         |
+|  Inženýrský čas<sup>†</sup>   |                $800 měsíčně                | Žádné, zabudované do sítě s globálně distribuovanými indexery |
+|        Dotazy za měsíc        |        Omezeno na infra schopnosti         |                          ~3,000,000                           |
+|    Náklady na jeden dotaz     |                     $0                     |                           $0.00004                            |
+|        Infrastruktura         |               Centralizovaný               |                       Decentralizované                        |
+|      Výdaje inženýrskou       |               $200 za hodinu               |                           Zahrnuto                            |
+|    Geografická redundancy     |   $1,200 celkových nákladů na další uzel   |                           Zahrnuto                            |
+|       Provozuschopnost        |                   Různé                    |                            99.9%+                             |
+|    Celkové měsíční náklady    | <span className="highlight-row" /> $1,650+ |                             $120                              |
 
 ## High Volume User (~30M queries per month)
 
-| Srovnání nákladů | Vlastní hostitel | The Graph Network |
-| :-: | :-: | :-: |
-| Měsíční náklady na server\* | $1100 měsíčně za uzel | $0 |
-| Náklady na dotazování | $4000 | $1,200 per month |
-| Počet potřebných uzlů | 10 | Nepoužije se |
-| Inženýrský čas<sup>†</sup> | 6$, 000 nebo více měsíčně | Žádné, zabudované do sítě s globálně distribuovanými indexery |
-| Dotazy za měsíc | Omezeno na infra schopnosti | ~30,000,000 |
-| Náklady na jeden dotaz | $0 | $0.00004 |
-| Infrastruktura | Centralizovaný | Decentralizované |
-| Geografická redundancy | $1,200 celkových nákladů na další uzel | Zahrnuto |
-| Provozuschopnost | Různé | 99.9%+ |
-| Celkové měsíční náklady | <span className="highlight-row" /> $11,000+ | $1,200 |
+|       Srovnání nákladů        |              Vlastní hostitel               |                       The Graph Network                       |
+|:-----------------------------:|:-------------------------------------------:|:-------------------------------------------------------------:|
+| Měsíční náklady na server\* |            $1100 měsíčně za uzel            |                              $0                               |
+|     Náklady na dotazování     |                    $4000                    |                       $1,200 per month                        |
+|     Počet potřebných uzlů     |                     10                      |                         Nepoužije se                          |
+|  Inženýrský čas<sup>†</sup>   |          6$, 000 nebo více měsíčně          | Žádné, zabudované do sítě s globálně distribuovanými indexery |
+|        Dotazy za měsíc        |         Omezeno na infra schopnosti         |                          ~30,000,000                          |
+|    Náklady na jeden dotaz     |                     $0                      |                           $0.00004                            |
+|        Infrastruktura         |               Centralizovaný                |                       Decentralizované                        |
+|    Geografická redundancy     |   $1,200 celkových nákladů na další uzel    |                           Zahrnuto                            |
+|       Provozuschopnost        |                    Různé                    |                            99.9%+                             |
+|    Celkové měsíční náklady    | <span className="highlight-row" /> $11,000+ |                            $1,200                             |
 
 \*včetně nákladů na zálohování: $50-$100 měsíčně
 

From 01394f5aff9c17a69550facf3e24e456f859b9ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:02 -0500
Subject: [PATCH 0165/3820] New translations benefits.mdx (German)

---
 website/pages/de/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/de/network/benefits.mdx b/website/pages/de/network/benefits.mdx
index f9aec6eee091..35f0df7781e1 100644
--- a/website/pages/de/network/benefits.mdx
+++ b/website/pages/de/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Cost Comparison | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $0+ | $0 per month |
-| Engineering time<sup>†</sup> | $400 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | 100,000 (Free Plan) |
-| Cost per query | $0 | $0<sup>‡</sup> |
-| Infrastruktur | Centralized | Decentralized |
-| Geographic redundancy | $750+ per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" />$750+ | $0 |
+|       Cost Comparison        |               Self Hosted               |                        The Graph Network                        |
+|:----------------------------:|:---------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |             $350 per month              |                               $0                                |
+|         Query costs          |                   $0+                   |                          $0 per month                           |
+| Engineering time<sup>†</sup> |             $400 per month              | None, built into the network with globally distributed Indexers |
+|      Queries per month       |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                   $0                    |                         $0<sup>‡</sup>                          |
+|        Infrastruktur         |               Centralized               |                          Decentralized                          |
+|    Geographic redundancy     |        $750+ per additional node        |                            Included                             |
+|            Uptime            |                 Varies                  |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" />$750+ |                               $0                                |
 
 ## Medium Volume User (~3M queries per month)
 
-| Cost Comparison | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $500 per month | $120 per month |
-| Engineering time<sup>†</sup> | $800 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~3,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Infrastruktur | Centralized | Decentralized |
-| Engineering expense | $200 per hour | Included |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $1,650+ | $120 |
+|       Cost Comparison        |                Self Hosted                 |                        The Graph Network                        |
+|:----------------------------:|:------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |               $350 per month               |                               $0                                |
+|         Query costs          |               $500 per month               |                         $120 per month                          |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|      Queries per month       |       Limited to infra capabilities        |                           ~3,000,000                            |
+|        Cost per query        |                     $0                     |                            $0.00004                             |
+|        Infrastruktur         |                Centralized                 |                          Decentralized                          |
+|     Engineering expense      |               $200 per hour                |                            Included                             |
+|    Geographic redundancy     | $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                   |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $1,650+ |                              $120                               |
 
 ## High Volume User (~30M queries per month)
 
-| Cost Comparison | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $1100 per month, per node | $0 |
-| Query costs | $4000 | $1,200 per month |
-| Number of nodes needed | 10 | Not applicable |
-| Engineering time<sup>†</sup> | $6,000 or more per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~30,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Infrastruktur | Centralized | Decentralized |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $11,000+ | $1,200 |
+|       Cost Comparison        |                 Self Hosted                 |                        The Graph Network                        |
+|:----------------------------:|:-------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |          $1100 per month, per node          |                               $0                                |
+|         Query costs          |                    $4000                    |                        $1,200 per month                         |
+|    Number of nodes needed    |                     10                      |                         Not applicable                          |
+| Engineering time<sup>†</sup> |          $6,000 or more per month           | None, built into the network with globally distributed Indexers |
+|      Queries per month       |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                     $0                      |                            $0.00004                             |
+|        Infrastruktur         |                 Centralized                 |                          Decentralized                          |
+|    Geographic redundancy     |  $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                    |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $11,000+ |                             $1,200                              |
 
 \*including costs for backup: $50-$100 per month
 

From a242ca660c4015bcc6e48259580ee16c1111302d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:07 -0500
Subject: [PATCH 0166/3820] New translations benefits.mdx (Italian)

---
 website/pages/it/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/it/network/benefits.mdx b/website/pages/it/network/benefits.mdx
index 19b319509f8a..304e99031863 100644
--- a/website/pages/it/network/benefits.mdx
+++ b/website/pages/it/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Confronto costi | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Costo mensile del server\* | $350 al mese | $0 |
-| Costi di query | $0+ | $0 per month |
-| Tempo di progettazione<sup>†</sup> | $400 al mese | Nessuno, integrato nella rete con indicizzatori distribuiti a livello globale |
-| Query al mese | Limitato alle capacità di infra | 100,000 (Free Plan) |
-| Costo per query | $0 | $0<sup>‡</sup> |
-| Infrastruttura | Centralizzato | Decentralizzato |
-| Ridondanza geografica | $750+ per nodo aggiuntivo | Incluso |
-| Tempo di attività | Variabile | 99.9%+ |
-| Costo totale mensile | <span className="highlight-row" />$750+ | $0 |
+|          Confronto costi           |               Self Hosted               |                               The Graph Network                               |
+|:----------------------------------:|:---------------------------------------:|:-----------------------------------------------------------------------------:|
+|    Costo mensile del server\*    |              $350 al mese               |                                      $0                                       |
+|           Costi di query           |                   $0+                   |                                 $0 per month                                  |
+| Tempo di progettazione<sup>†</sup> |              $400 al mese               | Nessuno, integrato nella rete con indicizzatori distribuiti a livello globale |
+|           Query al mese            |     Limitato alle capacità di infra     |                              100,000 (Free Plan)                              |
+|          Costo per query           |                   $0                    |                                $0<sup>‡</sup>                                 |
+|           Infrastruttura           |              Centralizzato              |                                Decentralizzato                                |
+|       Ridondanza geografica        |        $750+ per nodo aggiuntivo        |                                    Incluso                                    |
+|         Tempo di attività          |                Variabile                |                                    99.9%+                                     |
+|        Costo totale mensile        | <span className="highlight-row" />$750+ |                                      $0                                       |
 
 ## Medium Volume User (~3M queries per month)
 
-| Confronto dei costi | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Costo mensile del server\* | $350 al mese | $0 |
-| Costi di query | $500 al mese | $120 per month |
-| Tempo di progettazione<sup>†</sup> | $800 al mese | Nessuno, integrato nella rete con indicizzatori distribuiti a livello globale |
-| Query al mese | Limitato alle capacità dell'infrastruttura | ~3,000,000 |
-| Costo per query | $0 | $0.00004 |
-| Infrastruttura | Centralizzato | Decentralizzato |
-| Costi di ingegneria | $200 all'ora | Incluso |
-| Ridondanza geografica | $1.200 di costi totali per nodo aggiuntivo | Incluso |
-| Tempo di attività | Variabile | 99.9%+ |
-| Costo totale mensile | <span className="highlight-row" /> $1,650+ | $120 |
+|        Confronto dei costi         |                Self Hosted                 |                               The Graph Network                               |
+|:----------------------------------:|:------------------------------------------:|:-----------------------------------------------------------------------------:|
+|    Costo mensile del server\*    |                $350 al mese                |                                      $0                                       |
+|           Costi di query           |                $500 al mese                |                                $120 per month                                 |
+| Tempo di progettazione<sup>†</sup> |                $800 al mese                | Nessuno, integrato nella rete con indicizzatori distribuiti a livello globale |
+|           Query al mese            | Limitato alle capacità dell'infrastruttura |                                  ~3,000,000                                   |
+|          Costo per query           |                     $0                     |                                   $0.00004                                    |
+|           Infrastruttura           |               Centralizzato                |                                Decentralizzato                                |
+|        Costi di ingegneria         |                $200 all'ora                |                                    Incluso                                    |
+|       Ridondanza geografica        | $1.200 di costi totali per nodo aggiuntivo |                                    Incluso                                    |
+|         Tempo di attività          |                 Variabile                  |                                    99.9%+                                     |
+|        Costo totale mensile        | <span className="highlight-row" /> $1,650+ |                                     $120                                      |
 
 ## High Volume User (~30M queries per month)
 
-| Confronto costi | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Costo mensile del server\* | $1100 al mese, per nodo | $0 |
-| Costi di query | $4000 | $1,200 per month |
-| Numero di nodi necessari | 10 | Non applicabile |
-| Tempo di progettazione<sup>†</sup> | $6.000 o più al mese | Nessuno, integrato nella rete con indicizzatori distribuiti a livello globale |
-| Query al mese | Limitato alle capacità di infra | ~30,000,000 |
-| Costo per query | $0 | $0.00004 |
-| Infrastruttura | Centralizzato | Decentralizzato |
-| Ridondanza geografica | $1.200 di costi totali per nodo aggiuntivo | Incluso |
-| Tempo di attività | Variabile | 99.9%+ |
-| Costo totale mensile | <span className="highlight-row" /> $11,000+ | $1,200 |
+|          Confronto costi           |                 Self Hosted                 |                               The Graph Network                               |
+|:----------------------------------:|:-------------------------------------------:|:-----------------------------------------------------------------------------:|
+|    Costo mensile del server\*    |           $1100 al mese, per nodo           |                                      $0                                       |
+|           Costi di query           |                    $4000                    |                               $1,200 per month                                |
+|      Numero di nodi necessari      |                     10                      |                                Non applicabile                                |
+| Tempo di progettazione<sup>†</sup> |            $6.000 o più al mese             | Nessuno, integrato nella rete con indicizzatori distribuiti a livello globale |
+|           Query al mese            |       Limitato alle capacità di infra       |                                  ~30,000,000                                  |
+|          Costo per query           |                     $0                      |                                   $0.00004                                    |
+|           Infrastruttura           |                Centralizzato                |                                Decentralizzato                                |
+|       Ridondanza geografica        | $1.200 di costi totali per nodo aggiuntivo  |                                    Incluso                                    |
+|         Tempo di attività          |                  Variabile                  |                                    99.9%+                                     |
+|        Costo totale mensile        | <span className="highlight-row" /> $11,000+ |                                    $1,200                                     |
 
 \*inclusi i costi per il backup: $50-$100 al mese
 

From 2a97e6abb1f798eafb0317fa9a7ec0f497f0edd8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:09 -0500
Subject: [PATCH 0167/3820] New translations benefits.mdx (Japanese)

---
 website/pages/ja/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/ja/network/benefits.mdx b/website/pages/ja/network/benefits.mdx
index da4b2d00900b..7869ee86e955 100644
--- a/website/pages/ja/network/benefits.mdx
+++ b/website/pages/ja/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| コスト比較 | セルフホスト | グラフネットワーク |
-| :-: | :-: | :-: |
-| 月額サーバー代 | $350/月 | $0 |
-| クエリコスト | $0+ | $0 per month |
-| エンジニアリングタイム<sup>†</sup> | $400/月 | なし/ グローバルに分散されたインデクサーでネットワークに組み込まれる |
-| 月ごとのクエリ | インフラ機能に限定 | 100,000 (Free Plan) |
-| クエリごとのコスト | $0 | $0<sup>‡</sup> |
-| インフラストラクチャ | 集中管理型 | 分散型 |
-| 地理的な冗長性 | 追加1ノードにつき$750+ | 含まれる |
-| アップタイム | バリエーション | 99.9%+ |
-| 月額費用合計 | <span className="highlight-row" />$750+ | $0 |
+|          コスト比較          |                 セルフホスト                  |              グラフネットワーク              |
+|:-----------------------:|:---------------------------------------:|:-----------------------------------:|
+|         月額サーバー代         |                 $350/月                  |                 $0                  |
+|         クエリコスト          |                   $0+                   |            $0 per month             |
+| エンジニアリングタイム<sup>†</sup> |                 $400/月                  | なし/ グローバルに分散されたインデクサーでネットワークに組み込まれる |
+|         月ごとのクエリ         |                インフラ機能に限定                |         100,000 (Free Plan)         |
+|        クエリごとのコスト        |                   $0                    |           $0<sup>‡</sup>            |
+|       インフラストラクチャ        |                  集中管理型                  |                 分散型                 |
+|         地理的な冗長性         |             追加1ノードにつき$750+              |                含まれる                 |
+|         アップタイム          |                 バリエーション                 |               99.9%+                |
+|         月額費用合計          | <span className="highlight-row" />$750+ |                 $0                  |
 
 ## Medium Volume User (~3M queries per month)
 
-| コスト比較 | セルフホスト | グラフネットワーク |
-| :-: | :-: | :-: |
-| 月額サーバー代 | $350/月 | $0 |
-| クエリコスト | $500/月 | $120 per month |
-| エンジニアリングタイム<sup>†</sup> | $800/月 | なし/ グローバルに分散されたインデクサーでネットワークに組み込まれる |
-| 月ごとのクエリ | インフラ機能に限定 | ~3,000,000 |
-| クエリごとのコスト | $0 | $0.00004 |
-| インフラストラクチャ | 中央管理型 | 分散型 |
-| エンジニアリングコスト | $200/時 | 含まれる |
-| 地理的な冗長性 | ノード追加1台につき合計1,200ドル | 含まれる |
-| アップタイム | 変動 | 99.9%+ |
-| 月額費用合計 | <span className="highlight-row" /> $1,650+ | $120 |
+|          コスト比較          |                   セルフホスト                   |              グラフネットワーク              |
+|:-----------------------:|:------------------------------------------:|:-----------------------------------:|
+|         月額サーバー代         |                   $350/月                   |                 $0                  |
+|         クエリコスト          |                   $500/月                   |           $120 per month            |
+| エンジニアリングタイム<sup>†</sup> |                   $800/月                   | なし/ グローバルに分散されたインデクサーでネットワークに組み込まれる |
+|         月ごとのクエリ         |                 インフラ機能に限定                  |             ~3,000,000              |
+|        クエリごとのコスト        |                     $0                     |              $0.00004               |
+|       インフラストラクチャ        |                   中央管理型                    |                 分散型                 |
+|       エンジニアリングコスト       |                   $200/時                   |                含まれる                 |
+|         地理的な冗長性         |            ノード追加1台につき合計1,200ドル             |                含まれる                 |
+|         アップタイム          |                     変動                     |               99.9%+                |
+|         月額費用合計          | <span className="highlight-row" /> $1,650+ |                $120                 |
 
 ## High Volume User (~30M queries per month)
 
-| コスト比較 | セルフホスト | グラフネットワーク |
-| :-: | :-: | :-: |
-| 月額サーバー代 | $1100/月（ノードごと） | $0 |
-| クエリコスト | $4000 | $1,200 per month |
-| 必要ノード数 | 10 | 該当なし |
-| エンジニアリングタイム<sup>†</sup> | $6,000/月 | なし/ グローバルに分散されたインデクサーでネットワークに組み込まれる |
-| 月ごとのクエリ | インフラ機能に限定 | ~30,000,000 |
-| クエリごとのコスト | $0 | $0.00004 |
-| インフラストラクチャ | 集中管理型 | 分散型 |
-| 地理的な冗長性 | ノード追加1台につき合計1,200ドル | 含まれる |
-| アップタイム | 変動 | 99.9%+ |
-| 月額費用合計 | <span className="highlight-row" /> $11,000+ | $1,200 |
+|          コスト比較          |                   セルフホスト                    |              グラフネットワーク              |
+|:-----------------------:|:-------------------------------------------:|:-----------------------------------:|
+|         月額サーバー代         |               $1100/月（ノードごと）                |                 $0                  |
+|         クエリコスト          |                    $4000                    |          $1,200 per month           |
+|         必要ノード数          |                     10                      |                該当なし                 |
+| エンジニアリングタイム<sup>†</sup> |                  $6,000/月                   | なし/ グローバルに分散されたインデクサーでネットワークに組み込まれる |
+|         月ごとのクエリ         |                  インフラ機能に限定                  |             ~30,000,000             |
+|        クエリごとのコスト        |                     $0                      |              $0.00004               |
+|       インフラストラクチャ        |                    集中管理型                    |                 分散型                 |
+|         地理的な冗長性         |             ノード追加1台につき合計1,200ドル             |                含まれる                 |
+|         アップタイム          |                     変動                      |               99.9%+                |
+|         月額費用合計          | <span className="highlight-row" /> $11,000+ |               $1,200                |
 
 \*バックアップ費用含む：月額$50〜$100
 

From 3f2b87e65283fe86e337219da8c0e372b1be01ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:10 -0500
Subject: [PATCH 0168/3820] New translations benefits.mdx (Korean)

---
 website/pages/ko/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/ko/network/benefits.mdx b/website/pages/ko/network/benefits.mdx
index 80e18ef87c62..4fd17e17727d 100644
--- a/website/pages/ko/network/benefits.mdx
+++ b/website/pages/ko/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Cost Comparison | Self Hosted | The Graph 네트워크 |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $0+ | $0 per month |
-| Engineering time<sup>†</sup> | $400 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | 100,000 (Free Plan) |
-| Cost per query | $0 | $0<sup>‡</sup> |
-| Infrastructure | Centralized | Decentralized |
-| Geographic redundancy | $750+ per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" />$750+ | $0 |
+|       Cost Comparison        |               Self Hosted               |                         The Graph 네트워크                          |
+|:----------------------------:|:---------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |             $350 per month              |                               $0                                |
+|         Query costs          |                   $0+                   |                          $0 per month                           |
+| Engineering time<sup>†</sup> |             $400 per month              | None, built into the network with globally distributed Indexers |
+|      Queries per month       |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                   $0                    |                         $0<sup>‡</sup>                          |
+|        Infrastructure        |               Centralized               |                          Decentralized                          |
+|    Geographic redundancy     |        $750+ per additional node        |                            Included                             |
+|            Uptime            |                 Varies                  |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" />$750+ |                               $0                                |
 
 ## Medium Volume User (~3M queries per month)
 
-| Cost Comparison | Self Hosted | The Graph 네트워크 |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $500 per month | $120 per month |
-| Engineering time<sup>†</sup> | $800 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~3,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Infrastructure | Centralized | Decentralized |
-| Engineering expense | $200 per hour | Included |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $1,650+ | $120 |
+|       Cost Comparison        |                Self Hosted                 |                         The Graph 네트워크                          |
+|:----------------------------:|:------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |               $350 per month               |                               $0                                |
+|         Query costs          |               $500 per month               |                         $120 per month                          |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|      Queries per month       |       Limited to infra capabilities        |                           ~3,000,000                            |
+|        Cost per query        |                     $0                     |                            $0.00004                             |
+|        Infrastructure        |                Centralized                 |                          Decentralized                          |
+|     Engineering expense      |               $200 per hour                |                            Included                             |
+|    Geographic redundancy     | $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                   |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $1,650+ |                              $120                               |
 
 ## High Volume User (~30M queries per month)
 
-| Cost Comparison | Self Hosted | The Graph 네트워크 |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $1100 per month, per node | $0 |
-| Query costs | $4000 | $1,200 per month |
-| Number of nodes needed | 10 | Not applicable |
-| Engineering time<sup>†</sup> | $6,000 or more per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~30,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Infrastructure | Centralized | Decentralized |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $11,000+ | $1,200 |
+|       Cost Comparison        |                 Self Hosted                 |                         The Graph 네트워크                          |
+|:----------------------------:|:-------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |          $1100 per month, per node          |                               $0                                |
+|         Query costs          |                    $4000                    |                        $1,200 per month                         |
+|    Number of nodes needed    |                     10                      |                         Not applicable                          |
+| Engineering time<sup>†</sup> |          $6,000 or more per month           | None, built into the network with globally distributed Indexers |
+|      Queries per month       |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                     $0                      |                            $0.00004                             |
+|        Infrastructure        |                 Centralized                 |                          Decentralized                          |
+|    Geographic redundancy     |  $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                    |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $11,000+ |                             $1,200                              |
 
 \*including costs for backup: $50-$100 per month
 

From 806b55337c73b1848c2e56c932715ebfc7f5a71b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:12 -0500
Subject: [PATCH 0169/3820] New translations benefits.mdx (Dutch)

---
 website/pages/nl/network/benefits.mdx | 72 +++++++++++++--------------
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/website/pages/nl/network/benefits.mdx b/website/pages/nl/network/benefits.mdx
index 3c8d31ec132f..85fb9bde66ce 100644
--- a/website/pages/nl/network/benefits.mdx
+++ b/website/pages/nl/network/benefits.mdx
@@ -5,7 +5,7 @@ socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
 
 Het gedecentraliseerde netwerk van The Graph is ontworpen en verfijnd om een robuuste ervaring te creëren bij het indexeren en opvragen van data. Het netwerk wordt iedere dag sterker door de duizenden bijdragers wereldwijd.
 
-De voordelen van dit gedecentraliseerde protocol is dat het niet gerepliceerd kan worden door een `graph-node` lokaal te laten werken. Het Graph Netwerk is betrouwbaarder, efficiënter en goedkoper.
+De voordelen van dit gedecentraliseerde protocol is dat het niet gerepliceerd kan worden door een  `graph-node` lokaal te laten werken. Het Graph Netwerk is betrouwbaarder, efficiënter en goedkoper.
 
 Hier is een analyse:
 
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Kostenvergelijking | Zelf hosten | De Graph Netwerk |
-| :-: | :-: | :-: |
-| Maandelijkse serverkosten | $350 per maand | $0 |
-| Querykosten | $0+ | $0 per month |
-| Onderhoud tijd<sup>†</sup> | $400 per maand | Geen, deze kosten worden opgevangen door het wereldwijd gedistribueerde netwerk van indexeerders |
-| Aantal queries per maand | Beperkt tot infrastructuurcapaciteiten | 100,000 (Free Plan) |
-| Kosten per query | $0 | $0<sup>‡</sup> |
-| Infrastructuur | Gecentraliseerd | Gedecentraliseerd |
-| Geografische redundantie | $750+ per extra node | Inbegrepen |
-| Uptime | Wisselend | 99,9%+ |
-| Totale maandelijkse kosten | <span className="highlight-row" />$750+ | $0 |
+|     Kostenvergelijking     |               Zelf hosten               |                                         De Graph Netwerk                                         |
+|:--------------------------:|:---------------------------------------:|:------------------------------------------------------------------------------------------------:|
+| Maandelijkse serverkosten  |             $350 per maand              |                                                $0                                                |
+|        Querykosten         |                   $0+                   |                                           $0 per month                                           |
+| Onderhoud tijd<sup>†</sup> |             $400 per maand              | Geen, deze kosten worden opgevangen door het wereldwijd gedistribueerde netwerk van indexeerders |
+|  Aantal queries per maand  | Beperkt tot infrastructuurcapaciteiten  |                                       100,000 (Free Plan)                                        |
+|      Kosten per query      |                   $0                    |                                          $0<sup>‡</sup>                                          |
+|       Infrastructuur       |             Gecentraliseerd             |                                        Gedecentraliseerd                                         |
+|  Geografische redundantie  |          $750+ per extra node           |                                            Inbegrepen                                            |
+|           Uptime           |                Wisselend                |                                              99,9%+                                              |
+| Totale maandelijkse kosten | <span className="highlight-row" />$750+ |                                                $0                                                |
 
 ## Medium Volume User (~3M queries per month)
 
-| Kostenvergelijking | Zelf hosten | De Graph Netwerk |
-| :-: | :-: | :-: |
-| Maandelijkse serverkosten | $350 per maand | $0 |
-| Querykosten | $500 per maand | $120 per month |
-| Onderhoud<sup>†</sup> | $800 per maand | Geen, deze kosten worden opgevangen door het wereldwijd gedistribueerde netwerk van indexeerders |
-| Aantal queries per maand | Beperkt tot infrastructuurcapaciteiten | ~3,000,000 |
-| Kosten per query | $0 | $0.00004 |
-| Infrastructuur | Gecentraliseerd | Gedecentraliseerd |
-| Technische personeelskosten | $200 per uur | Inbegrepen |
-| Geografische redundantie | $1200 totale kosten per extra node | Inbegrepen |
-| Uptime | Wisselend | 99,9%+ |
-| Totale maandelijkse kosten | <span className="highlight-row" /> $1650+ | $120 |
+|     Kostenvergelijking      |                Zelf hosten                |                                         De Graph Netwerk                                         |
+|:---------------------------:|:-----------------------------------------:|:------------------------------------------------------------------------------------------------:|
+|  Maandelijkse serverkosten  |              $350 per maand               |                                                $0                                                |
+|         Querykosten         |              $500 per maand               |                                          $120 per month                                          |
+|    Onderhoud<sup>†</sup>    |              $800 per maand               | Geen, deze kosten worden opgevangen door het wereldwijd gedistribueerde netwerk van indexeerders |
+|  Aantal queries per maand   |  Beperkt tot infrastructuurcapaciteiten   |                                            ~3,000,000                                            |
+|      Kosten per query       |                    $0                     |                                             $0.00004                                             |
+|       Infrastructuur        |              Gecentraliseerd              |                                        Gedecentraliseerd                                         |
+| Technische personeelskosten |               $200 per uur                |                                            Inbegrepen                                            |
+|  Geografische redundantie   |    $1200 totale kosten per extra node     |                                            Inbegrepen                                            |
+|           Uptime            |                 Wisselend                 |                                              99,9%+                                              |
+| Totale maandelijkse kosten  | <span className="highlight-row" /> $1650+ |                                               $120                                               |
 
 ## High Volume User (~30M queries per month)
 
-| Kostenvergelijking | Zelf hosten | De Graph Netwerk |
-| :-: | :-: | :-: |
-| Maandelijkse serverkosten | $1100 per maand, per node | $0 |
-| Querykosten | $4000 | $1,200 per month |
-| Aantal benodigde nodes | 10 | Niet van toepassing |
-| Onderhoud<sup>†</sup> | $6000 of meer per maand | Geen, deze kosten worden opgevangen door het wereldwijd gedistribueerde netwerk van indexeerders |
-| Aantal queries per maand | Beperkt tot infrastructuurcapaciteiten | ~30,000,000 |
-| Kosten per query | $0 | $0.00004 |
-| Infrastructuur | Gecentraliseerd | Gedecentraliseerd |
-| Geografische redundantie | $1200 in totale kosten per extra node | Inbegrepen |
-| Uptime | Wisselend | 99,9%+ |
-| Totale maandelijkse kosten | <span className="highlight-row" /> $11000+ | $1,200 |
+|     Kostenvergelijking     |                Zelf hosten                 |                                         De Graph Netwerk                                         |
+|:--------------------------:|:------------------------------------------:|:------------------------------------------------------------------------------------------------:|
+| Maandelijkse serverkosten  |         $1100 per maand, per node          |                                                $0                                                |
+|        Querykosten         |                   $4000                    |                                         $1,200 per month                                         |
+|   Aantal benodigde nodes   |                     10                     |                                       Niet van toepassing                                        |
+|   Onderhoud<sup>†</sup>    |          $6000 of meer per maand           | Geen, deze kosten worden opgevangen door het wereldwijd gedistribueerde netwerk van indexeerders |
+|  Aantal queries per maand  |   Beperkt tot infrastructuurcapaciteiten   |                                           ~30,000,000                                            |
+|      Kosten per query      |                     $0                     |                                             $0.00004                                             |
+|       Infrastructuur       |              Gecentraliseerd               |                                        Gedecentraliseerd                                         |
+|  Geografische redundantie  |   $1200 in totale kosten per extra node    |                                            Inbegrepen                                            |
+|           Uptime           |                 Wisselend                  |                                              99,9%+                                              |
+| Totale maandelijkse kosten | <span className="highlight-row" /> $11000+ |                                              $1,200                                              |
 
 \*inclusief kosten voor een back-up: $50-$100 per maand
 

From d6c3af8a40a7c77c5f5b9dc49180a95da9a548ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:13 -0500
Subject: [PATCH 0170/3820] New translations benefits.mdx (Polish)

---
 website/pages/pl/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/pl/network/benefits.mdx b/website/pages/pl/network/benefits.mdx
index 7416ff6346fe..2ff74600cf86 100644
--- a/website/pages/pl/network/benefits.mdx
+++ b/website/pages/pl/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Cost Comparison | Self Hosted | Sieć The Graph |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $0+ | $0 per month |
-| Engineering time<sup>†</sup> | $400 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | 100,000 (Free Plan) |
-| Cost per query | $0 | $0<sup>‡</sup> |
-| Infrastructure | Centralized | Decentralized |
-| Geographic redundancy | $750+ per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" />$750+ | $0 |
+|       Cost Comparison        |               Self Hosted               |                         Sieć The Graph                          |
+|:----------------------------:|:---------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |             $350 per month              |                               $0                                |
+|         Query costs          |                   $0+                   |                          $0 per month                           |
+| Engineering time<sup>†</sup> |             $400 per month              | None, built into the network with globally distributed Indexers |
+|      Queries per month       |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                   $0                    |                         $0<sup>‡</sup>                          |
+|        Infrastructure        |               Centralized               |                          Decentralized                          |
+|    Geographic redundancy     |        $750+ per additional node        |                            Included                             |
+|            Uptime            |                 Varies                  |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" />$750+ |                               $0                                |
 
 ## Medium Volume User (~3M queries per month)
 
-| Cost Comparison | Self Hosted | Sieć The Graph |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $500 per month | $120 per month |
-| Engineering time<sup>†</sup> | $800 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~3,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Infrastructure | Centralized | Decentralized |
-| Engineering expense | $200 per hour | Included |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $1,650+ | $120 |
+|       Cost Comparison        |                Self Hosted                 |                         Sieć The Graph                          |
+|:----------------------------:|:------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |               $350 per month               |                               $0                                |
+|         Query costs          |               $500 per month               |                         $120 per month                          |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|      Queries per month       |       Limited to infra capabilities        |                           ~3,000,000                            |
+|        Cost per query        |                     $0                     |                            $0.00004                             |
+|        Infrastructure        |                Centralized                 |                          Decentralized                          |
+|     Engineering expense      |               $200 per hour                |                            Included                             |
+|    Geographic redundancy     | $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                   |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $1,650+ |                              $120                               |
 
 ## High Volume User (~30M queries per month)
 
-| Cost Comparison | Self Hosted | Sieć The Graph |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $1100 per month, per node | $0 |
-| Query costs | $4000 | $1,200 per month |
-| Number of nodes needed | 10 | Not applicable |
-| Engineering time<sup>†</sup> | $6,000 or more per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~30,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Infrastructure | Centralized | Decentralized |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $11,000+ | $1,200 |
+|       Cost Comparison        |                 Self Hosted                 |                         Sieć The Graph                          |
+|:----------------------------:|:-------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |          $1100 per month, per node          |                               $0                                |
+|         Query costs          |                    $4000                    |                        $1,200 per month                         |
+|    Number of nodes needed    |                     10                      |                         Not applicable                          |
+| Engineering time<sup>†</sup> |          $6,000 or more per month           | None, built into the network with globally distributed Indexers |
+|      Queries per month       |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                     $0                      |                            $0.00004                             |
+|        Infrastructure        |                 Centralized                 |                          Decentralized                          |
+|    Geographic redundancy     |  $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                    |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $11,000+ |                             $1,200                              |
 
 \*including costs for backup: $50-$100 per month
 

From f4500517fca4dd780ff4498c8101942c3614c903 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:19 -0500
Subject: [PATCH 0171/3820] New translations enums.mdx (Russian)

---
 website/pages/ru/cookbook/enums.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/cookbook/enums.mdx b/website/pages/ru/cookbook/enums.mdx
index d2e724ae5f8e..bf4f37f4152a 100644
--- a/website/pages/ru/cookbook/enums.mdx
+++ b/website/pages/ru/cookbook/enums.mdx
@@ -269,6 +269,6 @@ Expected output includes the marketplaces that meet the criteria, each represent
 }
 ```
 
-## Дополнительные источники
+## Дополнительные ресурсы
 
 For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 208832c24691676f73d3d6379509b90fd3e0e0bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:20 -0500
Subject: [PATCH 0172/3820] New translations benefits.mdx (Portuguese)

---
 website/pages/pt/network/benefits.mdx | 73 +++++++++++++--------------
 1 file changed, 36 insertions(+), 37 deletions(-)

diff --git a/website/pages/pt/network/benefits.mdx b/website/pages/pt/network/benefits.mdx
index ff04d9e965ce..081aef23ec08 100644
--- a/website/pages/pt/network/benefits.mdx
+++ b/website/pages/pt/network/benefits.mdx
@@ -27,54 +27,53 @@ Os custos de query podem variar; o custo citado é o normal até o fechamento da
 
 ## Utilizador de Baixo Volume (menos de 100 mil queries por mês)
 
-| Comparação de Custos | Auto-hospedagem | The Graph Network |
-| :-: | :-: | :-: |
-| Custo mensal de servidor\* | $350 por mês | $0 |
-| Custos de query | $0+ | $0 por mês |
-| Tempo de engenharia<sup>†</sup> | $400 por mês | Nenhum, embutido na rede com Indexadores distribuídos globalmente |
-| Queries por mês | Limitadas pelas capabilidades da infra | 100 mil (Plano Grátis) |
-| Custo por query | $0 | $0<sup>‡</sup> |
-| Infraestrutura | Centralizada | Descentralizada |
-| Redundância geográfica | $750+ por node adicional | Incluída |
-| Uptime (disponibilidade) | Varia | 99.9%+ |
-| Custos mensais totais | <span className="highlight-row" />$750+ | $0 |
+|      Comparação de Custos       |             Auto-hospedagem             |                         The Graph Network                         |
+|:-------------------------------:|:---------------------------------------:|:-----------------------------------------------------------------:|
+|  Custo mensal de servidor\*   |              $350 por mês               |                                $0                                 |
+|         Custos de query         |                   $0+                   |                            $0 por mês                             |
+| Tempo de engenharia<sup>†</sup> |              $400 por mês               | Nenhum, embutido na rede com Indexadores distribuídos globalmente |
+|         Queries por mês         | Limitadas pelas capabilidades da infra  |                      100 mil (Plano Grátis)                       |
+|         Custo por query         |                   $0                    |                          $0<sup>‡</sup>                           |
+|         Infraestrutura          |              Centralizada               |                          Descentralizada                          |
+|     Redundância geográfica      |        $750+ por node adicional         |                             Incluída                              |
+|    Uptime (disponibilidade)     |                  Varia                  |                              99.9%+                               |
+|      Custos mensais totais      | <span className="highlight-row" />$750+ |                                $0                                 |
 
 ## Utilizador de Volume Médio (cerca de 3 milhões de queries por mês)
 
-| Comparação de Custos | Auto-hospedagem | The Graph Network |
-| :-: | :-: | :-: |
-| Custo mensal de servidor\* | $350 por mês | $0 |
-| Custos de query | $500 por mês | $120 por mês |
-| Tempo de engenharia<sup>†</sup> | $800 por mês | Nenhum, embutido na rede com Indexadores distribuídos globalmente |
-| Queries por mês | Limitadas pelas capabilidades da infra | ~3 milhões |
-| Custo por query | $0 | $0.00004 |
-| Infraestrutura | Centralizada | Descentralizada |
-| Custo de engenharia | $200 por hora | Incluído |
-| Redundância geográfica | $1.200 em custos totais por node adicional | Incluída |
-| Uptime (disponibilidade) | Varia | 99.9%+ |
-| Custos mensais totais | <span className="highlight-row" /> $1.650+ | $120 |
+|      Comparação de Custos       |              Auto-hospedagem               |                         The Graph Network                         |
+|:-------------------------------:|:------------------------------------------:|:-----------------------------------------------------------------:|
+|  Custo mensal de servidor\*   |                $350 por mês                |                                $0                                 |
+|         Custos de query         |                $500 por mês                |                           $120 por mês                            |
+| Tempo de engenharia<sup>†</sup> |                $800 por mês                | Nenhum, embutido na rede com Indexadores distribuídos globalmente |
+|         Queries por mês         |   Limitadas pelas capabilidades da infra   |                            ~3 milhões                             |
+|         Custo por query         |                     $0                     |                             $0.00004                              |
+|         Infraestrutura          |                Centralizada                |                          Descentralizada                          |
+|       Custo de engenharia       |               $200 por hora                |                             Incluído                              |
+|     Redundância geográfica      | $1.200 em custos totais por node adicional |                             Incluída                              |
+|    Uptime (disponibilidade)     |                   Varia                    |                              99.9%+                               |
+|      Custos mensais totais      | <span className="highlight-row" /> $1.650+ |                               $120                                |
 
 ## Utilizador de Volume Alto (cerca de 30 milhões de queries por mês)
 
-| Comparação de Custos | Auto-hospedagem | The Graph Network |
-| :-: | :-: | :-: |
-| Custo mensal de servidor\* | $1.100 por mês, por node | $0 |
-| Custos de query | $4.000 | $1,200 por mês |
-| Número de nodes necessário | 10 | Não se aplica |
-| Tempo de engenharia<sup>†</sup> | $6.000 ou mais por mês | Nenhum, embutido na rede com Indexadores distribuídos globalmente |
-| Queries por mês | Limitadas pelas capabilidades da infra | Cerca de 30 milhões |
-| Custo por query | $0 | $0.00004 |
-| Infraestrutura | Centralizada | Descentralizada |
-| Redundância geográfica | $1.200 em custos totais por node adicional | Incluída |
-| Uptime (disponibilidade) | Varia | 99.9%+ |
-| Custos mensais totais | <span className="highlight-row" /> $11.000+ | $1.200 |
+|      Comparação de Custos       |               Auto-hospedagem               |                         The Graph Network                         |
+|:-------------------------------:|:-------------------------------------------:|:-----------------------------------------------------------------:|
+|  Custo mensal de servidor\*   |          $1.100 por mês, por node           |                                $0                                 |
+|         Custos de query         |                   $4.000                    |                          $1,200 por mês                           |
+|   Número de nodes necessário    |                     10                      |                           Não se aplica                           |
+| Tempo de engenharia<sup>†</sup> |           $6.000 ou mais por mês            | Nenhum, embutido na rede com Indexadores distribuídos globalmente |
+|         Queries por mês         |   Limitadas pelas capabilidades da infra    |                        Cerca de 30 milhões                        |
+|         Custo por query         |                     $0                      |                             $0.00004                              |
+|         Infraestrutura          |                Centralizada                 |                          Descentralizada                          |
+|     Redundância geográfica      | $1.200 em custos totais por node adicional  |                             Incluída                              |
+|    Uptime (disponibilidade)     |                    Varia                    |                              99.9%+                               |
+|      Custos mensais totais      | <span className="highlight-row" /> $11.000+ |                              $1.200                               |
 
 \*com custos de backup incluídos: $50-$100 por mês
 
 <sup>†</sup>Tempo de engenharia baseado numa hipótese de $200 por hora
 
-<sup>‡</sup>Reflete o custo ao consumidor de dados. Taxas de query ainda são pagas a Indexadores por queries do Plano
-Grátis.
+<sup>‡</sup>Reflete o custo ao consumidor de dados. Taxas de query ainda são pagas a Indexadores por queries do Plano Grátis.
 
 Os custos estimados são apenas para subgraphs na Mainnet do Ethereum — os custos são maiores ao auto-hospedar um `graph-node` em outras redes. Alguns utilizadores devem atualizar o seu subgraph a uma versão mais recente. Até o fechamento deste texto, devido às taxas de gas do Ethereum, uma atualização custa cerca de 50 dólares. Note que as taxas de gás no [Arbitrum](/arbitrum/arbitrum-faq) são muito menores que as da mainnet do Ethereum.
 

From 02cee5d7e7bb8666c4322065821b53cc0e6cc0f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:22 -0500
Subject: [PATCH 0173/3820] New translations benefits.mdx (Russian)

---
 website/pages/ru/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/ru/network/benefits.mdx b/website/pages/ru/network/benefits.mdx
index 809d32f249df..a11455ede307 100644
--- a/website/pages/ru/network/benefits.mdx
+++ b/website/pages/ru/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Сравнение затрат | Самостоятельный хостинг | Сеть The Graph |
-| :-: | :-: | :-: |
-| Ежемесячная стоимость сервера\* | $350 в месяц | $0 |
-| Стоимость запроса | $0+ | $0 per month |
-| Время разработки<sup>†</sup> | $400 в месяц | Никто, встроен в сеть с глобально распределенными индексаторами |
-| Запросы в месяц | Ограничен возможностями инфраструктуры | 100,000 (Free Plan) |
-| Стоимость одного запроса | $0 | $0<sup>‡</sup> |
-| Инфраструктура | Централизованная | Децентрализованная |
-| Географическая избыточность | $750+ за каждую дополнительную ноду | Включено |
-| Время безотказной работы | Варьируется | 99.9%+ |
-| Общие ежемесячные расходы | <span className="highlight-row" />$750+ | $0 |
+|         Сравнение затрат          |         Самостоятельный хостинг         |                         Сеть The Graph                          |
+|:---------------------------------:|:---------------------------------------:|:---------------------------------------------------------------:|
+| Ежемесячная стоимость сервера\* |              $350 в месяц               |                               $0                                |
+|         Стоимость запроса         |                   $0+                   |                          $0 per month                           |
+|   Время разработки<sup>†</sup>    |              $400 в месяц               | Никто, встроен в сеть с глобально распределенными индексаторами |
+|          Запросы в месяц          | Ограничен возможностями инфраструктуры  |                       100,000 (Free Plan)                       |
+|     Стоимость одного запроса      |                   $0                    |                         $0<sup>‡</sup>                          |
+|          Инфраструктура           |            Централизованная             |                       Децентрализованная                        |
+|    Географическая избыточность    |   $750+ за каждую дополнительную ноду   |                            Включено                             |
+|     Время безотказной работы      |               Варьируется               |                             99.9%+                              |
+|     Общие ежемесячные расходы     | <span className="highlight-row" />$750+ |                               $0                                |
 
 ## Medium Volume User (~3M queries per month)
 
-| Сравнение затрат | Самостоятельный хостинг | Сеть The Graph |
-| :-: | :-: | :-: |
-| Ежемесячная стоимость сервера\* | $350 в месяц | $0 |
-| Стоимость запроса | $500 в месяц | $120 per month |
-| Время разработки<sup>†</sup> | $800 в месяц | Никто, встроен в сеть с глобально распределенными индексаторами |
-| Запросы в месяц | Ограничен возможностями инфраструктуры | ~3,000,000 |
-| Стоимость одного запроса | $0 | $0.00004 |
-| Инфраструктура | Централизованная | Децентрализованная |
-| Инженерные расходы | $200 в час | Включено |
-| Географическая избыточность | общие затраты на каждую дополнительную ноду составляют $1,200 | Включено |
-| Время безотказной работы | Варьируется | 99.9%+ |
-| Общие ежемесячные расходы | <span className="highlight-row" /> $1,650+ | $120 |
+|         Сравнение затрат          |                    Самостоятельный хостинг                    |                         Сеть The Graph                          |
+|:---------------------------------:|:-------------------------------------------------------------:|:---------------------------------------------------------------:|
+| Ежемесячная стоимость сервера\* |                         $350 в месяц                          |                               $0                                |
+|         Стоимость запроса         |                         $500 в месяц                          |                         $120 per month                          |
+|   Время разработки<sup>†</sup>    |                         $800 в месяц                          | Никто, встроен в сеть с глобально распределенными индексаторами |
+|          Запросы в месяц          |            Ограничен возможностями инфраструктуры             |                           ~3,000,000                            |
+|     Стоимость одного запроса      |                              $0                               |                            $0.00004                             |
+|          Инфраструктура           |                       Централизованная                        |                       Децентрализованная                        |
+|        Инженерные расходы         |                          $200 в час                           |                            Включено                             |
+|    Географическая избыточность    | общие затраты на каждую дополнительную ноду составляют $1,200 |                            Включено                             |
+|     Время безотказной работы      |                          Варьируется                          |                             99.9%+                              |
+|     Общие ежемесячные расходы     |          <span className="highlight-row" /> $1,650+           |                              $120                               |
 
 ## High Volume User (~30M queries per month)
 
-| Сравнение затрат | Самостоятельный хостинг | Сеть The Graph |
-| :-: | :-: | :-: |
-| Ежемесячная стоимость сервера\* | $1100 в месяц за ноду | $0 |
-| Стоимость запроса | $4000 | $1,200 per month |
-| Необходимое количество нод | 10 | Не подходит |
-| Время разработки<sup>†</sup> | $6,000 или больше в месяц | Никто, встроен в сеть с глобально распределенными индексаторами |
-| Запросы в месяц | Ограничен возможностями инфраструктуры | ~30,000,000 |
-| Стоимость одного запроса | $0 | $0.00004 |
-| Инфраструктура | Централизованная | Децентрализованная |
-| Географическая избыточность | общие затраты на каждую дополнительную ноду составляют $1,200 | Включено |
-| Время безотказной работы | Варьируется | 99.9%+ |
-| Общие ежемесячные расходы | <span className="highlight-row" /> $11,000+ | $1,200 |
+|         Сравнение затрат          |                    Самостоятельный хостинг                    |                         Сеть The Graph                          |
+|:---------------------------------:|:-------------------------------------------------------------:|:---------------------------------------------------------------:|
+| Ежемесячная стоимость сервера\* |                     $1100 в месяц за ноду                     |                               $0                                |
+|         Стоимость запроса         |                             $4000                             |                        $1,200 per month                         |
+|    Необходимое количество нод     |                              10                               |                           Не подходит                           |
+|   Время разработки<sup>†</sup>    |                   $6,000 или больше в месяц                   | Никто, встроен в сеть с глобально распределенными индексаторами |
+|          Запросы в месяц          |            Ограничен возможностями инфраструктуры             |                           ~30,000,000                           |
+|     Стоимость одного запроса      |                              $0                               |                            $0.00004                             |
+|          Инфраструктура           |                       Централизованная                        |                       Децентрализованная                        |
+|    Географическая избыточность    | общие затраты на каждую дополнительную ноду составляют $1,200 |                            Включено                             |
+|     Время безотказной работы      |                          Варьируется                          |                             99.9%+                              |
+|     Общие ежемесячные расходы     |          <span className="highlight-row" /> $11,000+          |                             $1,200                              |
 
 \* включая расходы на резервное копирование: $50-$100 в месяц
 

From 3bf292b58f912f82c9a7ddec32e183bbf32583f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:23 -0500
Subject: [PATCH 0174/3820] New translations benefits.mdx (Swedish)

---
 website/pages/sv/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/sv/network/benefits.mdx b/website/pages/sv/network/benefits.mdx
index 2ad0e58e1e1b..3b8ace79fa89 100644
--- a/website/pages/sv/network/benefits.mdx
+++ b/website/pages/sv/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Kostnadsjämförelse | Egen Värd | The Graph Nätverk |
-| :-: | :-: | :-: |
-| Månatlig kostnad för server\* | $350 per månad | $0 |
-| Kostnad för frågor | $0+ | $0 per month |
-| Konstruktionstid<sup>†</sup> | $400 per månad | Ingen, inbyggd i nätverket med globalt distribuerade Indexers |
-| Frågor per månad | Begränsad till infra kapacitet | 100,000 (Free Plan) |
-| Kostnad per fråga | $0 | $0<sup>‡</sup> |
-| Infrastruktur | Centraliserad | Decentraliserad |
-| Geografisk redundans | $750+ per extra nod | Inkluderat |
-| Drifttid | Varierande | 99.9%+ |
-| Total Månadskostnad | <span className="highlight-row" />$750+ | $0 |
+|       Kostnadsjämförelse        |                Egen Värd                |                       The Graph Nätverk                       |
+|:-------------------------------:|:---------------------------------------:|:-------------------------------------------------------------:|
+| Månatlig kostnad för server\* |             $350 per månad              |                              $0                               |
+|       Kostnad för frågor        |                   $0+                   |                         $0 per month                          |
+|  Konstruktionstid<sup>†</sup>   |             $400 per månad              | Ingen, inbyggd i nätverket med globalt distribuerade Indexers |
+|        Frågor per månad         |     Begränsad till infra kapacitet      |                      100,000 (Free Plan)                      |
+|        Kostnad per fråga        |                   $0                    |                        $0<sup>‡</sup>                         |
+|          Infrastruktur          |              Centraliserad              |                        Decentraliserad                        |
+|      Geografisk redundans       |           $750+ per extra nod           |                          Inkluderat                           |
+|            Drifttid             |               Varierande                |                            99.9%+                             |
+|       Total Månadskostnad       | <span className="highlight-row" />$750+ |                              $0                               |
 
 ## Medium Volume User (~3M queries per month)
 
-| Kostnadsjämförelse | Egen Värd | The Graph Nätverk |
-| :-: | :-: | :-: |
-| Månadskostnad för server\* | $350 per månad | $0 |
-| Kostnad för frågor | $500 per månad | $120 per month |
-| Ingenjörstid<sup>†</sup> | $800 per månad | Ingen, inbyggd i nätverket med globalt distribuerade Indexers |
-| Frågor per månad | Begränsad till infra kapacitet | ~3,000,000 |
-| Kostnad per fråga | $0 | $0.00004 |
-| Infrastruktur | Centraliserad | Decentraliserad |
-| Kostnader för ingenjörsarbete | $200 per timme | Inkluderat |
-| Geografisk redundans | $1,200 i totala kostnader per extra nod | Inkluderat |
-| Drifttid | Varierar | 99.9%+ |
-| Total Månadskostnad | <span className="highlight-row" /> $1,650+ | $120 |
+|      Kostnadsjämförelse       |                 Egen Värd                  |                       The Graph Nätverk                       |
+|:-----------------------------:|:------------------------------------------:|:-------------------------------------------------------------:|
+| Månadskostnad för server\*  |               $350 per månad               |                              $0                               |
+|      Kostnad för frågor       |               $500 per månad               |                        $120 per month                         |
+|   Ingenjörstid<sup>†</sup>    |               $800 per månad               | Ingen, inbyggd i nätverket med globalt distribuerade Indexers |
+|       Frågor per månad        |       Begränsad till infra kapacitet       |                          ~3,000,000                           |
+|       Kostnad per fråga       |                     $0                     |                           $0.00004                            |
+|         Infrastruktur         |               Centraliserad                |                        Decentraliserad                        |
+| Kostnader för ingenjörsarbete |               $200 per timme               |                          Inkluderat                           |
+|     Geografisk redundans      |  $1,200 i totala kostnader per extra nod   |                          Inkluderat                           |
+|           Drifttid            |                  Varierar                  |                            99.9%+                             |
+|      Total Månadskostnad      | <span className="highlight-row" /> $1,650+ |                             $120                              |
 
 ## High Volume User (~30M queries per month)
 
-| Kostnadsjämförelse | Egen Värd | The Graph Nätverk |
-| :-: | :-: | :-: |
-| Månadskostnad för server\* | $1100 per månad, per nod | $0 |
-| Kostnad för frågor | $4000 | $1,200 per month |
-| Antal noder som behövs | 10 | Ej tillämpligt |
-| Ingenjörstid<sup>†</sup> | $6,000 eller mer per månad | Ingen, inbyggd i nätverket med globalt distribuerade Indexers |
-| Frågor per månad | Begränsad till infra kapacitet | ~30,000,000 |
-| Kostnad per fråga | $0 | $0.00004 |
-| Infrastruktur | Centraliserad | Decentraliserad |
-| Geografisk redundans | $1,200 i totala kostnader per extra nod | Inkluderat |
-| Drifttid | Varierar | 99.9%+ |
-| Total Månadskostnad | <span className="highlight-row" /> $11,000+ | $1,200 |
+|      Kostnadsjämförelse      |                  Egen Värd                  |                       The Graph Nätverk                       |
+|:----------------------------:|:-------------------------------------------:|:-------------------------------------------------------------:|
+| Månadskostnad för server\* |          $1100 per månad, per nod           |                              $0                               |
+|      Kostnad för frågor      |                    $4000                    |                       $1,200 per month                        |
+|    Antal noder som behövs    |                     10                      |                        Ej tillämpligt                         |
+|   Ingenjörstid<sup>†</sup>   |         $6,000 eller mer per månad          | Ingen, inbyggd i nätverket med globalt distribuerade Indexers |
+|       Frågor per månad       |       Begränsad till infra kapacitet        |                          ~30,000,000                          |
+|      Kostnad per fråga       |                     $0                      |                           $0.00004                            |
+|        Infrastruktur         |                Centraliserad                |                        Decentraliserad                        |
+|     Geografisk redundans     |   $1,200 i totala kostnader per extra nod   |                          Inkluderat                           |
+|           Drifttid           |                  Varierar                   |                            99.9%+                             |
+|     Total Månadskostnad      | <span className="highlight-row" /> $11,000+ |                            $1,200                             |
 
 \*inklusive kostnader för backup: $50-$100 per månad
 

From 53911b333afe8f204ba493445d48b7c6327a1ed1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:24 -0500
Subject: [PATCH 0175/3820] New translations benefits.mdx (Turkish)

---
 website/pages/tr/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/tr/network/benefits.mdx b/website/pages/tr/network/benefits.mdx
index 60bed9f2847a..282c68f00f68 100644
--- a/website/pages/tr/network/benefits.mdx
+++ b/website/pages/tr/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Cost Comparison | Self Hosted | Graph Ağı |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $0+ | $0 per month |
-| Engineering time<sup>†</sup> | $400 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | 100,000 (Free Plan) |
-| Cost per query | $0 | $0<sup>‡</sup> |
-| Altyapı | Centralized | Decentralized |
-| Geographic redundancy | $750+ per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" />$750+ | $0 |
+|       Cost Comparison        |               Self Hosted               |                            Graph Ağı                            |
+|:----------------------------:|:---------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |             $350 per month              |                               $0                                |
+|         Query costs          |                   $0+                   |                          $0 per month                           |
+| Engineering time<sup>†</sup> |             $400 per month              | None, built into the network with globally distributed Indexers |
+|      Queries per month       |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                   $0                    |                         $0<sup>‡</sup>                          |
+|           Altyapı            |               Centralized               |                          Decentralized                          |
+|    Geographic redundancy     |        $750+ per additional node        |                            Included                             |
+|            Uptime            |                 Varies                  |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" />$750+ |                               $0                                |
 
 ## Medium Volume User (~3M queries per month)
 
-| Cost Comparison | Self Hosted | Graph Ağı |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $500 per month | $120 per month |
-| Engineering time<sup>†</sup> | $800 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~3,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Altyapı | Centralized | Decentralized |
-| Engineering expense | $200 per hour | Included |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $1,650+ | $120 |
+|       Cost Comparison        |                Self Hosted                 |                            Graph Ağı                            |
+|:----------------------------:|:------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |               $350 per month               |                               $0                                |
+|         Query costs          |               $500 per month               |                         $120 per month                          |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|      Queries per month       |       Limited to infra capabilities        |                           ~3,000,000                            |
+|        Cost per query        |                     $0                     |                            $0.00004                             |
+|           Altyapı            |                Centralized                 |                          Decentralized                          |
+|     Engineering expense      |               $200 per hour                |                            Included                             |
+|    Geographic redundancy     | $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                   |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $1,650+ |                              $120                               |
 
 ## High Volume User (~30M queries per month)
 
-| Cost Comparison | Self Hosted | Graph Ağı |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $1100 per month, per node | $0 |
-| Query costs | $4000 | $1,200 per month |
-| Number of nodes needed | 10 | Not applicable |
-| Engineering time<sup>†</sup> | $6,000 or more per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~30,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Altyapı | Centralized | Decentralized |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $11,000+ | $1,200 |
+|       Cost Comparison        |                 Self Hosted                 |                            Graph Ağı                            |
+|:----------------------------:|:-------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |          $1100 per month, per node          |                               $0                                |
+|         Query costs          |                    $4000                    |                        $1,200 per month                         |
+|    Number of nodes needed    |                     10                      |                         Not applicable                          |
+| Engineering time<sup>†</sup> |          $6,000 or more per month           | None, built into the network with globally distributed Indexers |
+|      Queries per month       |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                     $0                      |                            $0.00004                             |
+|           Altyapı            |                 Centralized                 |                          Decentralized                          |
+|    Geographic redundancy     |  $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                    |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $11,000+ |                             $1,200                              |
 
 \*including costs for backup: $50-$100 per month
 

From c83e6ec5d97c2ed53b7d48549ee9fc71f1790132 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:25 -0500
Subject: [PATCH 0176/3820] New translations benefits.mdx (Ukrainian)

---
 website/pages/uk/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/uk/network/benefits.mdx b/website/pages/uk/network/benefits.mdx
index 2ab73dd7d7ba..b37047538c52 100644
--- a/website/pages/uk/network/benefits.mdx
+++ b/website/pages/uk/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Порівняння вартості послуг | Самостійний хостинг | Graph мережа |
-| :-: | :-: | :-: |
-| Щомісячна плата за сервер\* | $350 на місяць | $0 |
-| Вартість запитів | $0+ | $0 per month |
-| Час технічного обслуговування<sup>†</sup> | $400 на місяць | Немає, вбудовані в мережу з глобально розподіленими індексаторами |
-| Кількість запитів за місяць | Обмежується інфраструктурними можливостями | 100,000 (Free Plan) |
-| Вартість одного запиту | $0 | $0<sup>‡</sup> |
-| Інфраструктура | Централізована | Децентралізована |
-| Географічне резервування | $750+ за кожну додаткову ноду | Включено |
-| Час безвідмовної роботи | Варіюється | 99.9%+ |
-| Загальна сума щомісячних витрат | <span className="highlight-row" />$750+ | $0 |
+|        Порівняння вартості послуг         |            Самостійний хостинг             |                           Graph мережа                            |
+|:-----------------------------------------:|:------------------------------------------:|:-----------------------------------------------------------------:|
+|       Щомісячна плата за сервер\*       |               $350 на місяць               |                                $0                                 |
+|             Вартість запитів              |                    $0+                     |                           $0 per month                            |
+| Час технічного обслуговування<sup>†</sup> |               $400 на місяць               | Немає, вбудовані в мережу з глобально розподіленими індексаторами |
+|        Кількість запитів за місяць        | Обмежується інфраструктурними можливостями |                        100,000 (Free Plan)                        |
+|          Вартість одного запиту           |                     $0                     |                          $0<sup>‡</sup>                           |
+|              Інфраструктура               |               Централізована               |                         Децентралізована                          |
+|         Географічне резервування          |       $750+ за кожну додаткову ноду        |                             Включено                              |
+|          Час безвідмовної роботи          |                 Варіюється                 |                              99.9%+                               |
+|      Загальна сума щомісячних витрат      |  <span className="highlight-row" />$750+   |                                $0                                 |
 
 ## Medium Volume User (~3M queries per month)
 
-| Порівняння вартості послуг | Самостійний хостинг | Graph мережа |
-| :-: | :-: | :-: |
-| Щомісячна плата за сервер\* | $350 на місяць | $0 |
-| Вартість запитів | $500 на місяць | $120 per month |
-| Час технічного обслуговування<sup>†</sup> | $800 на місяць | Немає, вбудовані в мережу з глобально розподіленими індексаторами |
-| Кількість запитів за місяць | Обмежується інфраструктурними можливостями | ~3,000,000 |
-| Вартість одного запиту | $0 | $0.00004 |
-| Інфраструктура | Централізована | Децентралізована |
-| Інженерно-технічні витрати | $200 на годину | Включено |
-| Географічне резервування | $1,200 загальних витрат на кожну додаткову ноду | Включено |
-| Час безвідмовної роботи | Варіюється | 99.9%+ |
-| Загальна сума щомісячних витрат | <span className="highlight-row" /> $1,650+ | $120 |
+|        Порівняння вартості послуг         |               Самостійний хостинг               |                           Graph мережа                            |
+|:-----------------------------------------:|:-----------------------------------------------:|:-----------------------------------------------------------------:|
+|       Щомісячна плата за сервер\*       |                 $350 на місяць                  |                                $0                                 |
+|             Вартість запитів              |                 $500 на місяць                  |                          $120 per month                           |
+| Час технічного обслуговування<sup>†</sup> |                 $800 на місяць                  | Немає, вбудовані в мережу з глобально розподіленими індексаторами |
+|        Кількість запитів за місяць        |   Обмежується інфраструктурними можливостями    |                            ~3,000,000                             |
+|          Вартість одного запиту           |                       $0                        |                             $0.00004                              |
+|              Інфраструктура               |                 Централізована                  |                         Децентралізована                          |
+|        Інженерно-технічні витрати         |                 $200 на годину                  |                             Включено                              |
+|         Географічне резервування          | $1,200 загальних витрат на кожну додаткову ноду |                             Включено                              |
+|          Час безвідмовної роботи          |                   Варіюється                    |                              99.9%+                               |
+|      Загальна сума щомісячних витрат      |   <span className="highlight-row" /> $1,650+    |                               $120                                |
 
 ## High Volume User (~30M queries per month)
 
-| Порівняння вартості послуг | Самостійний хостинг | Graph мережа |
-| :-: | :-: | :-: |
-| Щомісячна плата за сервер\* | $1100 на місяць, за одну ноду | $0 |
-| Вартість запитів | $4000 | $1,200 per month |
-| Кількість необхідних нод | 10 | Не стосується |
-| Час технічного обслуговування<sup>†</sup> | $6,000 і більше на місяць | Немає, вбудовані в мережу з глобально розподіленими індексаторами |
-| Кількість запитів за місяць | Обмежується інфраструктурними можливостями | ~30,000,000 |
-| Вартість одного запиту | $0 | $0.00004 |
-| Інфраструктура | Централізована | Децентралізована |
-| Географічне резервування | $1,200 загальних витрат на кожну додаткову ноду | Включено |
-| Час безвідмовної роботи | Варіюється | 99.9%+ |
-| Загальна сума щомісячних витрат | <span className="highlight-row" /> $11,000+ | $1,200 |
+|        Порівняння вартості послуг         |               Самостійний хостинг               |                           Graph мережа                            |
+|:-----------------------------------------:|:-----------------------------------------------:|:-----------------------------------------------------------------:|
+|       Щомісячна плата за сервер\*       |          $1100 на місяць, за одну ноду          |                                $0                                 |
+|             Вартість запитів              |                      $4000                      |                         $1,200 per month                          |
+|         Кількість необхідних нод          |                       10                        |                           Не стосується                           |
+| Час технічного обслуговування<sup>†</sup> |            $6,000 і більше на місяць            | Немає, вбудовані в мережу з глобально розподіленими індексаторами |
+|        Кількість запитів за місяць        |   Обмежується інфраструктурними можливостями    |                            ~30,000,000                            |
+|          Вартість одного запиту           |                       $0                        |                             $0.00004                              |
+|              Інфраструктура               |                 Централізована                  |                         Децентралізована                          |
+|         Географічне резервування          | $1,200 загальних витрат на кожну додаткову ноду |                             Включено                              |
+|          Час безвідмовної роботи          |                   Варіюється                    |                              99.9%+                               |
+|      Загальна сума щомісячних витрат      |   <span className="highlight-row" /> $11,000+   |                              $1,200                               |
 
 \*включаючи витрати на резервне копіювання: $50-$100 на місяць
 

From 6394018fce1ce8cd8eb745808ba6959119ab5053 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:30 -0500
Subject: [PATCH 0177/3820] New translations benefits.mdx (Chinese Simplified)

---
 website/pages/zh/network/benefits.mdx | 72 +++++++++++++--------------
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/website/pages/zh/network/benefits.mdx b/website/pages/zh/network/benefits.mdx
index e9170c43c645..56e7fbfdbde5 100644
--- a/website/pages/zh/network/benefits.mdx
+++ b/website/pages/zh/network/benefits.mdx
@@ -27,49 +27,49 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-|       成本比较       |                 自托管                  |                 Graph网络                  |
-| :------------------: | :-------------------------------------: | :----------------------------------------: |
-|  每月服务器费用 \*   |               每月350美元               |                   0美元                    |
-|       查询成本       |                   $0+                   |                $0 per month                |
-| 工程时间<sup>†</sup> |               400美元每月               | 没有，内置在具有全球去中心化索引者的网络中 |
-|       每月查询       |           受限于基础设施能力            |            100,000 (Free Plan)             |
-|    每个查询的成本    |                  0美元                  |               $0<sup>‡</sup>               |
-|       基础设施       |                 中心化                  |                  去中心化                  |
-|       异地备援       |           每个额外节点 $750 +           |                  包括在内                  |
-|     正常工作时间     |                  变量                   |                   99.9%+                   |
-|      每月总成本      | <span className="highlight-row" />$750+ |                   0美元                    |
+|       成本比较       |                   自托管                   |        Graph网络        |
+|:----------------:|:---------------------------------------:|:---------------------:|
+|   每月服务器费用 \*   |                 每月350美元                 |          0美元          |
+|       查询成本       |                   $0+                   |     $0 per month      |
+| 工程时间<sup>†</sup> |                 400美元每月                 | 没有，内置在具有全球去中心化索引者的网络中 |
+|       每月查询       |                受限于基础设施能力                |  100,000 (Free Plan)  |
+|     每个查询的成本      |                   0美元                   |    $0<sup>‡</sup>     |
+|       基础设施       |                   中心化                   |         去中心化          |
+|       异地备援       |              每个额外节点 $750 +              |         包括在内          |
+|      正常工作时间      |                   变量                    |        99.9%+         |
+|      每月总成本       | <span className="highlight-row" />$750+ |          0美元          |
 
 ## Medium Volume User (~3M queries per month)
 
-|       成本比较       |                     自托管                      |                 Graph网络                  |
-| :------------------: | :---------------------------------------------: | :----------------------------------------: |
-|  每月服务器费用 \*   |                   每月350美元                   |                   0美元                    |
-|       查询成本       |                   每月500美元                   |               $120 per month               |
+|       成本比较       |                     自托管                     |        Graph网络        |
+|:----------------:|:-------------------------------------------:|:---------------------:|
+|   每月服务器费用 \*   |                   每月350美元                   |          0美元          |
+|       查询成本       |                   每月500美元                   |    $120 per month     |
 | 工程时间<sup>†</sup> |                   每月800美元                   | 没有，内置在具有全球去中心化索引者的网络中 |
-|       每月查询       |               受限于基础设施能力                |                 ~3,000,000                 |
-|    每个查询的成本    |                      0美元                      |                  $0.00004                  |
-|       基础设施       |                     中心化                      |                  去中心化                  |
-|       工程费用       |                  每小时200美元                  |                  包括在内                  |
-|       异地备援       |         每个额外节点的总成本为1200美元          |                  包括在内                  |
-|     正常工作时间     |                      变量                       |                   99.9%+                   |
-|      每月总成本      | <span className="highlight-row" /> 1650美元以上 |                    $120                    |
+|       每月查询       |                  受限于基础设施能力                  |      ~3,000,000       |
+|     每个查询的成本      |                     0美元                     |       $0.00004        |
+|       基础设施       |                     中心化                     |         去中心化          |
+|       工程费用       |                  每小时200美元                   |         包括在内          |
+|       异地备援       |              每个额外节点的总成本为1200美元              |         包括在内          |
+|      正常工作时间      |                     变量                      |        99.9%+         |
+|      每月总成本       | <span className="highlight-row" /> 1650美元以上 |         $120          |
 
 ## High Volume User (~30M queries per month)
 
-|       成本比较       |                    自托管                     |                 Graph网络                  |
-| :------------------: | :-------------------------------------------: | :----------------------------------------: |
-|  每月服务器费用 \*   |              1100美元每月每节点               |                   0美元                    |
-|       查询成本       |                   4000美元                    |              $1,200 per month              |
-|    需要的节点数量    |                      10                       |                   不适用                   |
-| 工程时间<sup>†</sup> |              每月6000美元或以上               | 没有，内置在具有全球去中心化索引人的网络中 |
-|       每月查询       |              受限于基础设施能力               |                ~30,000,000                 |
-|    每个查询的成本    |                     0美元                     |                  $0.00004                  |
-|       基础设施       |                    中心化                     |                  去中心化                  |
-|       异地备援       |        每个额外节点的总成本为1200美元         |                  包括在内                  |
-|     正常工作时间     |                     变量                      |                   99.9%+                   |
-|      每月总成本      | <span className="highlight-row" /> 11000+美元 |                   $1,200                   |
-
-- 包括后备费用: 每月$50-$100美元
+|       成本比较       |                     自托管                     |        Graph网络        |
+|:----------------:|:-------------------------------------------:|:---------------------:|
+|   每月服务器费用 \*   |                 1100美元每月每节点                 |          0美元          |
+|       查询成本       |                   4000美元                    |   $1,200 per month    |
+|     需要的节点数量      |                     10                      |          不适用          |
+| 工程时间<sup>†</sup> |                 每月6000美元或以上                 | 没有，内置在具有全球去中心化索引人的网络中 |
+|       每月查询       |                  受限于基础设施能力                  |      ~30,000,000      |
+|     每个查询的成本      |                     0美元                     |       $0.00004        |
+|       基础设施       |                     中心化                     |         去中心化          |
+|       异地备援       |              每个额外节点的总成本为1200美元              |         包括在内          |
+|      正常工作时间      |                     变量                      |        99.9%+         |
+|      每月总成本       | <span className="highlight-row" /> 11000+美元 |        $1,200         |
+
+* 包括后备费用: 每月$50-$100美元
 
 <sup>†</sup>按每小时200美元的假设计算的工程时间
 

From c798943e206e00942f6503e829c8b2618598b9cf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:32 -0500
Subject: [PATCH 0178/3820] New translations benefits.mdx (Urdu (Pakistan))

---
 website/pages/ur/network/benefits.mdx | 74 +++++++++++++--------------
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/website/pages/ur/network/benefits.mdx b/website/pages/ur/network/benefits.mdx
index 2597116aef61..21ef629e8418 100644
--- a/website/pages/ur/network/benefits.mdx
+++ b/website/pages/ur/network/benefits.mdx
@@ -27,49 +27,49 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| اخراجات کا موازنہ | خود میزبان | The Graph Network |
-| :-: | :-: | :-: |
-| ماہانہ سرور کی قیمت/\* | $350 فی مہینہ | $0 |
-| استفسار کے اخراجات | $0+ | $0 per month |
-| انجینئرنگ کا وقت<sup>†</sup> | $400 فی مہینہ | کوئی بھی نہیں، عالمی سطح پر تقسیم شدہ انڈیکسرز کے ساتھ نیٹ ورک میں بنایا گیا ہے |
-| فی مہینہ سوالات | بنیادی صلاحیتوں تک محدود | 100,000 (Free Plan) |
-| قیمت فی سوال | $0 | $0<sup>‡</sup> |
-| بنیادی ڈھانچہ | سینٹرلائزڈ | ڈیسینٹرلائزڈ |
-| جغرافیائی فالتو پن | $750+ فی اضافی نوڈ | شامل |
-| اپ ٹائم | اتار چڑھاو | 99.9%+ |
-| کل ماہانہ اخراجات | <span className="highlight-row" />$750+ | $0 |
+|      اخراجات کا موازنہ       |               خود میزبان                |                                The Graph Network                                |
+|:----------------------------:|:---------------------------------------:|:-------------------------------------------------------------------------------:|
+|    ماہانہ سرور کی قیمت/*     |              $350 فی مہینہ              |                                       $0                                        |
+|      استفسار کے اخراجات      |                   $0+                   |                                  $0 per month                                   |
+| انجینئرنگ کا وقت<sup>†</sup> |              $400 فی مہینہ              | کوئی بھی نہیں، عالمی سطح پر تقسیم شدہ انڈیکسرز کے ساتھ نیٹ ورک میں بنایا گیا ہے |
+|       فی مہینہ سوالات        |        بنیادی صلاحیتوں تک محدود         |                               100,000 (Free Plan)                               |
+|         قیمت فی سوال         |                   $0                    |                                 $0<sup>‡</sup>                                  |
+|        بنیادی ڈھانچہ         |               سینٹرلائزڈ                |                                  ڈیسینٹرلائزڈ                                   |
+|      جغرافیائی فالتو پن      |           $750+ فی اضافی نوڈ            |                                      شامل                                       |
+|           اپ ٹائم            |               اتار چڑھاو                |                                     99.9%+                                      |
+|      کل ماہانہ اخراجات       | <span className="highlight-row" />$750+ |                                       $0                                        |
 
 ## Medium Volume User (~3M queries per month)
 
-| اخراجات کا موازنہ | خود میزبان | The Graph Network |
-| :-: | :-: | :-: |
-| ماہانہ سرور کی قیمت/\* | $350 فی مہینہ | $0 |
-| استفسار کے اخراجات | $500 فی مہینہ | $120 per month |
-| انجینئرنگ کا وقت<sup>†</sup> | $800 فی مہینہ | کوئی بھی نہیں، عالمی سطح پر تقسیم شدہ انڈیکسرز کے ساتھ نیٹ ورک میں بنایا گیا ہے |
-| فی مہینہ سوالات | بنیادی صلاحیتوں تک محدود | ~3,000,000 |
-| قیمت فی سوال | $0 | $0.00004 |
-| بنیادی ڈھانچہ | سینٹرلائزڈ | ڈیسینٹرلائزڈ |
-| انجینئرنگ کے اخراجات | $200 فی گھنٹہ | شامل |
-| جغرافیائی فالتو پن | فی اضافی نوڈ کل اخراجات میں $1,200 | شامل |
-| اپ ٹائم | اتار چڑھاو | 99.9%+ |
-| کل ماہانہ اخراجات | <span className="highlight-row" /> $1,650+ | $120 |
+|      اخراجات کا موازنہ       |                 خود میزبان                 |                                The Graph Network                                |
+|:----------------------------:|:------------------------------------------:|:-------------------------------------------------------------------------------:|
+|    ماہانہ سرور کی قیمت/*     |               $350 فی مہینہ                |                                       $0                                        |
+|      استفسار کے اخراجات      |               $500 فی مہینہ                |                                 $120 per month                                  |
+| انجینئرنگ کا وقت<sup>†</sup> |               $800 فی مہینہ                | کوئی بھی نہیں، عالمی سطح پر تقسیم شدہ انڈیکسرز کے ساتھ نیٹ ورک میں بنایا گیا ہے |
+|       فی مہینہ سوالات        |          بنیادی صلاحیتوں تک محدود          |                                   ~3,000,000                                    |
+|         قیمت فی سوال         |                     $0                     |                                    $0.00004                                     |
+|        بنیادی ڈھانچہ         |                 سینٹرلائزڈ                 |                                  ڈیسینٹرلائزڈ                                   |
+|     انجینئرنگ کے اخراجات     |               $200 فی گھنٹہ                |                                      شامل                                       |
+|      جغرافیائی فالتو پن      |     فی اضافی نوڈ کل اخراجات میں $1,200     |                                      شامل                                       |
+|           اپ ٹائم            |                 اتار چڑھاو                 |                                     99.9%+                                      |
+|      کل ماہانہ اخراجات       | <span className="highlight-row" /> $1,650+ |                                      $120                                       |
 
 ## High Volume User (~30M queries per month)
 
-| اخراجات کا موازنہ | سیلف ہوسٹڈ | The Graph Network |
-| :-: | :-: | :-: |
-| ماہانہ سرور کی قیمت/\* | $1100 فی مہینہ، فی نوڈ | $0 |
-| استفسار کے اخراجات | $4000 | $1,200 per month |
-| نوڈس کی تعداد درکار ہے | 10 | قابل اطلاق نہیں |
-| انجینئرنگ کا وقت<sup>†</sup> | $6,000 یا اس سے زیادہ فی مہینہ | کوئی بھی نہیں، عالمی سطح پر تقسیم شدہ انڈیکسرز کے ساتھ نیٹ ورک میں بنایا گیا ہے |
-| فی مہینہ سوالات | بنیادی صلاحیتوں تک محدود | ~30,000,000 |
-| قیمت فی سوال | $0 | $0.00004 |
-| بنیادی ڈھانچہ | سینٹرلائزڈ | ڈیسینٹرلائزڈ |
-| جغرافیائی فالتو پن | فی اضافی نوڈ کل اخراجات میں $1,200 | شامل |
-| اپ ٹائم | اتار چڑھاو | 99.9%+ |
-| کل ماہانہ اخراجات | <span className="highlight-row" /> $11,000+ | $1,200 |
-
-/\*بیک اپ کے اخراجات سمیت: $50-$100 فی مہینہ
+|      اخراجات کا موازنہ       |                 سیلف ہوسٹڈ                  |                                The Graph Network                                |
+|:----------------------------:|:-------------------------------------------:|:-------------------------------------------------------------------------------:|
+|    ماہانہ سرور کی قیمت/*     |           $1100 فی مہینہ، فی نوڈ            |                                       $0                                        |
+|      استفسار کے اخراجات      |                    $4000                    |                                $1,200 per month                                 |
+|    نوڈس کی تعداد درکار ہے    |                     10                      |                                 قابل اطلاق نہیں                                 |
+| انجینئرنگ کا وقت<sup>†</sup> |       $6,000 یا اس سے زیادہ فی مہینہ        | کوئی بھی نہیں، عالمی سطح پر تقسیم شدہ انڈیکسرز کے ساتھ نیٹ ورک میں بنایا گیا ہے |
+|       فی مہینہ سوالات        |          بنیادی صلاحیتوں تک محدود           |                                   ~30,000,000                                   |
+|         قیمت فی سوال         |                     $0                      |                                    $0.00004                                     |
+|        بنیادی ڈھانچہ         |                 سینٹرلائزڈ                  |                                  ڈیسینٹرلائزڈ                                   |
+|      جغرافیائی فالتو پن      |     فی اضافی نوڈ کل اخراجات میں $1,200      |                                      شامل                                       |
+|           اپ ٹائم            |                 اتار چڑھاو                  |                                     99.9%+                                      |
+|      کل ماہانہ اخراجات       | <span className="highlight-row" /> $11,000+ |                                     $1,200                                      |
+
+/*بیک اپ کے اخراجات سمیت: $50-$100 فی مہینہ
 
 <sup>†</sup>$200 فی گھنٹہ کے مفروضے کی بنیاد پر انجینئرنگ کا وقت
 

From 0a8ac05c979d392e2e5dd2449f2d1046a2737a25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:33 -0500
Subject: [PATCH 0179/3820] New translations benefits.mdx (Vietnamese)

---
 website/pages/vi/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/vi/network/benefits.mdx b/website/pages/vi/network/benefits.mdx
index 41f8bc870b9a..a5857ff2ed86 100644
--- a/website/pages/vi/network/benefits.mdx
+++ b/website/pages/vi/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Cost Comparison | Self Hosted | Mạng The Graph |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $0+ | $0 per month |
-| Engineering time<sup>†</sup> | $400 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | 100,000 (Free Plan) |
-| Cost per query | $0 | $0<sup>‡</sup> |
-| Cơ sở hạ tầng | Centralized | Decentralized |
-| Geographic redundancy | $750+ per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" />$750+ | $0 |
+|       Cost Comparison        |               Self Hosted               |                         Mạng The Graph                          |
+|:----------------------------:|:---------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |             $350 per month              |                               $0                                |
+|         Query costs          |                   $0+                   |                          $0 per month                           |
+| Engineering time<sup>†</sup> |             $400 per month              | None, built into the network with globally distributed Indexers |
+|      Queries per month       |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                   $0                    |                         $0<sup>‡</sup>                          |
+|        Cơ sở hạ tầng         |               Centralized               |                          Decentralized                          |
+|    Geographic redundancy     |        $750+ per additional node        |                            Included                             |
+|            Uptime            |                 Varies                  |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" />$750+ |                               $0                                |
 
 ## Medium Volume User (~3M queries per month)
 
-| Cost Comparison | Self Hosted | Mạng The Graph |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $500 per month | $120 per month |
-| Engineering time<sup>†</sup> | $800 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~3,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Cơ sở hạ tầng | Centralized | Decentralized |
-| Engineering expense | $200 per hour | Included |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $1,650+ | $120 |
+|       Cost Comparison        |                Self Hosted                 |                         Mạng The Graph                          |
+|:----------------------------:|:------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |               $350 per month               |                               $0                                |
+|         Query costs          |               $500 per month               |                         $120 per month                          |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|      Queries per month       |       Limited to infra capabilities        |                           ~3,000,000                            |
+|        Cost per query        |                     $0                     |                            $0.00004                             |
+|        Cơ sở hạ tầng         |                Centralized                 |                          Decentralized                          |
+|     Engineering expense      |               $200 per hour                |                            Included                             |
+|    Geographic redundancy     | $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                   |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $1,650+ |                              $120                               |
 
 ## High Volume User (~30M queries per month)
 
-| Cost Comparison | Self Hosted | Mạng The Graph |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $1100 per month, per node | $0 |
-| Query costs | $4000 | $1,200 per month |
-| Number of nodes needed | 10 | Not applicable |
-| Engineering time<sup>†</sup> | $6,000 or more per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~30,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Cơ sở hạ tầng | Centralized | Decentralized |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $11,000+ | $1,200 |
+|       Cost Comparison        |                 Self Hosted                 |                         Mạng The Graph                          |
+|:----------------------------:|:-------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |          $1100 per month, per node          |                               $0                                |
+|         Query costs          |                    $4000                    |                        $1,200 per month                         |
+|    Number of nodes needed    |                     10                      |                         Not applicable                          |
+| Engineering time<sup>†</sup> |          $6,000 or more per month           | None, built into the network with globally distributed Indexers |
+|      Queries per month       |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                     $0                      |                            $0.00004                             |
+|        Cơ sở hạ tầng         |                 Centralized                 |                          Decentralized                          |
+|    Geographic redundancy     |  $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                    |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $11,000+ |                             $1,200                              |
 
 \*including costs for backup: $50-$100 per month
 

From 902873316c38543da8c0773e08ab2a24bd12157e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:34 -0500
Subject: [PATCH 0180/3820] New translations benefits.mdx (Marathi)

---
 website/pages/mr/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/mr/network/benefits.mdx b/website/pages/mr/network/benefits.mdx
index 50102fc70729..95d7187a2039 100644
--- a/website/pages/mr/network/benefits.mdx
+++ b/website/pages/mr/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| खर्चाची तुलना | स्वत: होस्ट केलेले | आलेख नेटवर्क |
-| :-: | :-: | :-: |
-| मासिक सर्व्हर खर्च\* | दरमहा $350 | $0 |
-| क्वेरी खर्च | $0+ | $0 per month |
-| अभियांत्रिकी वेळ<sup>†</sup> | दरमहा $400 | काहीही नाही, जागतिक स्तरावर वितरित इंडेक्सर्ससह नेटवर्कमध्ये तयार केलेले |
-| प्रति महिना प्रश्न | इन्फ्रा क्षमतांपुरती मर्यादित | 100,000 (Free Plan) |
-| प्रति क्वेरी खर्च | $0 | $0<sup>‡</sup> |
-| पायाभूत सुविधा | केंद्रीकृत | विकेंद्रित |
-| भौगोलिक रिडंडंसी | प्रति अतिरिक्त नोड $750+ | समाविष्ट |
-| अपटाइम | बदलते | 99.9%+ |
-| एकूण मासिक खर्च | <span className="highlight-row" />$750+ | $0 |
+|        खर्चाची तुलना         |           स्वत: होस्ट केलेले            |                               आलेख नेटवर्क                               |
+|:----------------------------:|:---------------------------------------:|:------------------------------------------------------------------------:|
+|    मासिक सर्व्हर खर्च\*    |               दरमहा $350                |                                    $0                                    |
+|         क्वेरी खर्च          |                   $0+                   |                               $0 per month                               |
+| अभियांत्रिकी वेळ<sup>†</sup> |               दरमहा $400                | काहीही नाही, जागतिक स्तरावर वितरित इंडेक्सर्ससह नेटवर्कमध्ये तयार केलेले |
+|      प्रति महिना प्रश्न      |      इन्फ्रा क्षमतांपुरती मर्यादित      |                           100,000 (Free Plan)                            |
+|      प्रति क्वेरी खर्च       |                   $0                    |                              $0<sup>‡</sup>                              |
+|        पायाभूत सुविधा        |               केंद्रीकृत                |                                विकेंद्रित                                |
+|       भौगोलिक रिडंडंसी       |        प्रति अतिरिक्त नोड $750+         |                                 समाविष्ट                                 |
+|            अपटाइम            |                  बदलते                  |                                  99.9%+                                  |
+|       एकूण मासिक खर्च        | <span className="highlight-row" />$750+ |                                    $0                                    |
 
 ## Medium Volume User (~3M queries per month)
 
-| खर्चाची तुलना | स्वत: होस्ट केलेले | आलेख नेटवर्क |
-| :-: | :-: | :-: |
-| मासिक सर्व्हर खर्च\* | दरमहा $350 | $0 |
-| क्वेरी खर्च | दरमहा $500 | $120 per month |
-| अभियांत्रिकी वेळ<sup>†</sup> | दरमहा $800 | काहीही नाही, जागतिक स्तरावर वितरित इंडेक्सर्ससह नेटवर्कमध्ये तयार केलेले |
-| प्रति महिना प्रश्न | इन्फ्रा क्षमतांपुरती मर्यादित | ~3,000,000 |
-| प्रति क्वेरी खर्च | $0 | $0.00004 |
-| पायाभूत सुविधा | केंद्रीकृत | विकेंद्रित |
-| अभियांत्रिकी खर्च | $200 प्रति तास | समाविष्ट |
-| भौगोलिक रिडंडंसी | प्रति अतिरिक्त नोड एकूण खर्चात $1,200 | समाविष्ट |
-| अपटाइम | बदलते | 99.9%+ |
-| एकूण मासिक खर्च | <span className="highlight-row" /> $1,650+ | $120 |
+|        खर्चाची तुलना         |             स्वत: होस्ट केलेले             |                               आलेख नेटवर्क                               |
+|:----------------------------:|:------------------------------------------:|:------------------------------------------------------------------------:|
+|    मासिक सर्व्हर खर्च\*    |                 दरमहा $350                 |                                    $0                                    |
+|         क्वेरी खर्च          |                 दरमहा $500                 |                              $120 per month                              |
+| अभियांत्रिकी वेळ<sup>†</sup> |                 दरमहा $800                 | काहीही नाही, जागतिक स्तरावर वितरित इंडेक्सर्ससह नेटवर्कमध्ये तयार केलेले |
+|      प्रति महिना प्रश्न      |       इन्फ्रा क्षमतांपुरती मर्यादित        |                                ~3,000,000                                |
+|      प्रति क्वेरी खर्च       |                     $0                     |                                 $0.00004                                 |
+|        पायाभूत सुविधा        |                 केंद्रीकृत                 |                                विकेंद्रित                                |
+|      अभियांत्रिकी खर्च       |               $200 प्रति तास               |                                 समाविष्ट                                 |
+|       भौगोलिक रिडंडंसी       |   प्रति अतिरिक्त नोड एकूण खर्चात $1,200    |                                 समाविष्ट                                 |
+|            अपटाइम            |                   बदलते                    |                                  99.9%+                                  |
+|       एकूण मासिक खर्च        | <span className="highlight-row" /> $1,650+ |                                   $120                                   |
 
 ## High Volume User (~30M queries per month)
 
-| खर्चाची तुलना | स्वत: होस्ट केलेले | आलेख नेटवर्क |
-| :-: | :-: | :-: |
-| मासिक सर्व्हर खर्च\* | प्रति नोड, प्रति महिना $1100 | $0 |
-| क्वेरी खर्च | $4000 | $1,200 per month |
-| आवश्यक नोड्सची संख्या | 10 | लागू नाही |
-| अभियांत्रिकी वेळ<sup>†</sup> | दरमहा $6,000 किंवा अधिक | काहीही नाही, जागतिक स्तरावर वितरित इंडेक्सर्ससह नेटवर्कमध्ये तयार केलेले |
-| प्रति महिना प्रश्न | इन्फ्रा क्षमतांपुरती मर्यादित | ~30,000,000 |
-| प्रति क्वेरी खर्च | $0 | $0.00004 |
-| पायाभूत सुविधा | केंद्रीकृत | विकेंद्रित |
-| भौगोलिक रिडंडंसी | प्रति अतिरिक्त नोड एकूण खर्चात $1,200 | समाविष्ट |
-| अपटाइम | बदलते | 99.9%+ |
-| एकूण मासिक खर्च | <span className="highlight-row" /> $11,000+ | $1,200 |
+|        खर्चाची तुलना         |             स्वत: होस्ट केलेले              |                               आलेख नेटवर्क                               |
+|:----------------------------:|:-------------------------------------------:|:------------------------------------------------------------------------:|
+|    मासिक सर्व्हर खर्च\*    |        प्रति नोड, प्रति महिना $1100         |                                    $0                                    |
+|         क्वेरी खर्च          |                    $4000                    |                             $1,200 per month                             |
+|    आवश्यक नोड्सची संख्या     |                     10                      |                                लागू नाही                                 |
+| अभियांत्रिकी वेळ<sup>†</sup> |           दरमहा $6,000 किंवा अधिक           | काहीही नाही, जागतिक स्तरावर वितरित इंडेक्सर्ससह नेटवर्कमध्ये तयार केलेले |
+|      प्रति महिना प्रश्न      |        इन्फ्रा क्षमतांपुरती मर्यादित        |                               ~30,000,000                                |
+|      प्रति क्वेरी खर्च       |                     $0                      |                                 $0.00004                                 |
+|        पायाभूत सुविधा        |                 केंद्रीकृत                  |                                विकेंद्रित                                |
+|       भौगोलिक रिडंडंसी       |    प्रति अतिरिक्त नोड एकूण खर्चात $1,200    |                                 समाविष्ट                                 |
+|            अपटाइम            |                    बदलते                    |                                  99.9%+                                  |
+|       एकूण मासिक खर्च        | <span className="highlight-row" /> $11,000+ |                                  $1,200                                  |
 
 \*बॅकअपच्या खर्चासह: $50-$100 प्रति महिना
 

From 11c1a82391d400f2d3e8cd96db654726c5ff161a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:35 -0500
Subject: [PATCH 0181/3820] New translations benefits.mdx (Hindi)

---
 website/pages/hi/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/hi/network/benefits.mdx b/website/pages/hi/network/benefits.mdx
index 72171c86bf9c..fb724441c964 100644
--- a/website/pages/hi/network/benefits.mdx
+++ b/website/pages/hi/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| लागत तुलना | स्वयं होस्ट किया गया | The Graph Network |
-| :-: | :-: | :-: |
-| मासिक सर्वर लागत\* | $350 प्रति माह | $0 |
-| पूछताछ लागत | $0+ | $0 per month |
-| इंजीनियरिंग का समय<sup>†</sup> | $ 400 प्रति माह | कोई नहीं, विश्व स्तर पर वितरित इंडेक्सर्स के साथ नेटवर्क में बनाया गया |
-| प्रति माह प्रश्न | इन्फ्रा क्षमताओं तक सीमित | 100,000 (Free Plan) |
-| लागत प्रति क्वेरी | $0 | $0<sup>‡</sup> |
-| आधारभूत संरचना | केंद्रीकृत | विकेन्द्रीकृत |
-| भौगोलिक अतिरेक | $750+ प्रति अतिरिक्त नोड | शामिल |
-| अपटाइम | भिन्न | 99.9%+ |
-| कुल मासिक लागत | <span className="highlight-row" />$750+ | $0 |
+|           लागत तुलना           |          स्वयं होस्ट किया गया           |                           The Graph Network                            |
+|:------------------------------:|:---------------------------------------:|:----------------------------------------------------------------------:|
+|      मासिक सर्वर लागत\*      |             $350 प्रति माह              |                                   $0                                   |
+|          पूछताछ लागत           |                   $0+                   |                              $0 per month                              |
+| इंजीनियरिंग का समय<sup>†</sup> |             $ 400 प्रति माह             | कोई नहीं, विश्व स्तर पर वितरित इंडेक्सर्स के साथ नेटवर्क में बनाया गया |
+|        प्रति माह प्रश्न        |        इन्फ्रा क्षमताओं तक सीमित        |                          100,000 (Free Plan)                           |
+|       लागत प्रति क्वेरी        |                   $0                    |                             $0<sup>‡</sup>                             |
+|         आधारभूत संरचना         |               केंद्रीकृत                |                             विकेन्द्रीकृत                              |
+|         भौगोलिक अतिरेक         |        $750+ प्रति अतिरिक्त नोड         |                                 शामिल                                  |
+|             अपटाइम             |                  भिन्न                  |                                 99.9%+                                 |
+|         कुल मासिक लागत         | <span className="highlight-row" />$750+ |                                   $0                                   |
 
 ## Medium Volume User (~3M queries per month)
 
-| लागत तुलना | स्वयं होस्ट किया गया | The Graph Network |
-| :-: | :-: | :-: |
-| मासिक सर्वर लागत\* | $350 प्रति माह | $0 |
-| पूछताछ लागत | $ 500 प्रति माह | $120 per month |
-| इंजीनियरिंग का समय<sup>†</sup> | $800 प्रति माह | कोई नहीं, विश्व स्तर पर वितरित इंडेक्सर्स के साथ नेटवर्क में बनाया गया |
-| प्रति माह प्रश्न | इन्फ्रा क्षमताओं तक सीमित | ~3,000,000 |
-| लागत प्रति क्वेरी | $0 | $0.00004 |
-| आधारभूत संरचना | केंद्रीकृत | विकेन्द्रीकृत |
-| इंजीनियरिंग खर्च | $ 200 प्रति घंटा | शामिल |
-| भौगोलिक अतिरेक | प्रति अतिरिक्त नोड कुल लागत में $1,200 | शामिल |
-| अपटाइम | भिन्न | 99.9%+ |
-| कुल मासिक लागत | <span className="highlight-row" /> $1,650+ | $120 |
+|           लागत तुलना           |            स्वयं होस्ट किया गया            |                           The Graph Network                            |
+|:------------------------------:|:------------------------------------------:|:----------------------------------------------------------------------:|
+|      मासिक सर्वर लागत\*      |               $350 प्रति माह               |                                   $0                                   |
+|          पूछताछ लागत           |              $ 500 प्रति माह               |                             $120 per month                             |
+| इंजीनियरिंग का समय<sup>†</sup> |               $800 प्रति माह               | कोई नहीं, विश्व स्तर पर वितरित इंडेक्सर्स के साथ नेटवर्क में बनाया गया |
+|        प्रति माह प्रश्न        |         इन्फ्रा क्षमताओं तक सीमित          |                               ~3,000,000                               |
+|       लागत प्रति क्वेरी        |                     $0                     |                                $0.00004                                |
+|         आधारभूत संरचना         |                 केंद्रीकृत                 |                             विकेन्द्रीकृत                              |
+|        इंजीनियरिंग खर्च        |              $ 200 प्रति घंटा              |                                 शामिल                                  |
+|         भौगोलिक अतिरेक         |   प्रति अतिरिक्त नोड कुल लागत में $1,200   |                                 शामिल                                  |
+|             अपटाइम             |                   भिन्न                    |                                 99.9%+                                 |
+|         कुल मासिक लागत         | <span className="highlight-row" /> $1,650+ |                                  $120                                  |
 
 ## High Volume User (~30M queries per month)
 
-| लागत तुलना | स्वयं होस्ट किया गया | The Graph Network |
-| :-: | :-: | :-: |
-| मासिक सर्वर लागत\* | $1100 प्रति माह, प्रति नोड | $0 |
-| पूछताछ लागत | $4000 | $1,200 per month |
-| आवश्यक नोड्स की संख्या | 10 | Not applicable |
-| इंजीनियरिंग का समय<sup>†</sup> | $6,000 or more per month | कोई नहीं, विश्व स्तर पर वितरित इंडेक्सर्स के साथ नेटवर्क में बनाया गया |
-| प्रति माह प्रश्न | इन्फ्रा क्षमताओं तक सीमित | ~30,000,000 |
-| लागत प्रति क्वेरी | $0 | $0.00004 |
-| आधारभूत संरचना | केंद्रीकृत | विकेन्द्रीकृत |
-| भौगोलिक अतिरेक | प्रति अतिरिक्त नोड कुल लागत में $1,200 | शामिल |
-| अपटाइम | भिन्न | 99.9%+ |
-| कुल मासिक लागत | <span className="highlight-row" /> $11,000+ | $1,200 |
+|           लागत तुलना           |            स्वयं होस्ट किया गया             |                           The Graph Network                            |
+|:------------------------------:|:-------------------------------------------:|:----------------------------------------------------------------------:|
+|      मासिक सर्वर लागत\*      |         $1100 प्रति माह, प्रति नोड          |                                   $0                                   |
+|          पूछताछ लागत           |                    $4000                    |                            $1,200 per month                            |
+|     आवश्यक नोड्स की संख्या     |                     10                      |                             Not applicable                             |
+| इंजीनियरिंग का समय<sup>†</sup> |          $6,000 or more per month           | कोई नहीं, विश्व स्तर पर वितरित इंडेक्सर्स के साथ नेटवर्क में बनाया गया |
+|        प्रति माह प्रश्न        |          इन्फ्रा क्षमताओं तक सीमित          |                              ~30,000,000                               |
+|       लागत प्रति क्वेरी        |                     $0                      |                                $0.00004                                |
+|         आधारभूत संरचना         |                 केंद्रीकृत                  |                             विकेन्द्रीकृत                              |
+|         भौगोलिक अतिरेक         |   प्रति अतिरिक्त नोड कुल लागत में $1,200    |                                 शामिल                                  |
+|             अपटाइम             |                    भिन्न                    |                                 99.9%+                                 |
+|         कुल मासिक लागत         | <span className="highlight-row" /> $11,000+ |                                 $1,200                                 |
 
 \*बैकअप की लागत सहित: $50-$100 प्रति माह
 

From 0b14de3c8c9097a78bae0541139429c889d5f25e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:36 -0500
Subject: [PATCH 0182/3820] New translations benefits.mdx (Swahili)

---
 website/pages/sw/network/benefits.mdx | 70 +++++++++++++--------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/sw/network/benefits.mdx b/website/pages/sw/network/benefits.mdx
index 7b50daa789a4..9000c85bc383 100644
--- a/website/pages/sw/network/benefits.mdx
+++ b/website/pages/sw/network/benefits.mdx
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-| Cost Comparison | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $0+ | $0 per month |
-| Engineering time<sup>†</sup> | $400 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | 100,000 (Free Plan) |
-| Cost per query | $0 | $0<sup>‡</sup> |
-| Infrastructure | Centralized | Decentralized |
-| Geographic redundancy | $750+ per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" />$750+ | $0 |
+|       Cost Comparison        |               Self Hosted               |                        The Graph Network                        |
+|:----------------------------:|:---------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |             $350 per month              |                               $0                                |
+|         Query costs          |                   $0+                   |                          $0 per month                           |
+| Engineering time<sup>†</sup> |             $400 per month              | None, built into the network with globally distributed Indexers |
+|      Queries per month       |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                   $0                    |                         $0<sup>‡</sup>                          |
+|        Infrastructure        |               Centralized               |                          Decentralized                          |
+|    Geographic redundancy     |        $750+ per additional node        |                            Included                             |
+|            Uptime            |                 Varies                  |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" />$750+ |                               $0                                |
 
 ## Medium Volume User (~3M queries per month)
 
-| Cost Comparison | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $350 per month | $0 |
-| Query costs | $500 per month | $120 per month |
-| Engineering time<sup>†</sup> | $800 per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~3,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Infrastructure | Centralized | Decentralized |
-| Engineering expense | $200 per hour | Included |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $1,650+ | $120 |
+|       Cost Comparison        |                Self Hosted                 |                        The Graph Network                        |
+|:----------------------------:|:------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |               $350 per month               |                               $0                                |
+|         Query costs          |               $500 per month               |                         $120 per month                          |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|      Queries per month       |       Limited to infra capabilities        |                           ~3,000,000                            |
+|        Cost per query        |                     $0                     |                            $0.00004                             |
+|        Infrastructure        |                Centralized                 |                          Decentralized                          |
+|     Engineering expense      |               $200 per hour                |                            Included                             |
+|    Geographic redundancy     | $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                   |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $1,650+ |                              $120                               |
 
 ## High Volume User (~30M queries per month)
 
-| Cost Comparison | Self Hosted | The Graph Network |
-| :-: | :-: | :-: |
-| Monthly server cost\* | $1100 per month, per node | $0 |
-| Query costs | $4000 | $1,200 per month |
-| Number of nodes needed | 10 | Not applicable |
-| Engineering time<sup>†</sup> | $6,000 or more per month | None, built into the network with globally distributed Indexers |
-| Queries per month | Limited to infra capabilities | ~30,000,000 |
-| Cost per query | $0 | $0.00004 |
-| Infrastructure | Centralized | Decentralized |
-| Geographic redundancy | $1,200 in total costs per additional node | Included |
-| Uptime | Varies | 99.9%+ |
-| Total Monthly Costs | <span className="highlight-row" /> $11,000+ | $1,200 |
+|       Cost Comparison        |                 Self Hosted                 |                        The Graph Network                        |
+|:----------------------------:|:-------------------------------------------:|:---------------------------------------------------------------:|
+|   Monthly server cost\*    |          $1100 per month, per node          |                               $0                                |
+|         Query costs          |                    $4000                    |                        $1,200 per month                         |
+|    Number of nodes needed    |                     10                      |                         Not applicable                          |
+| Engineering time<sup>†</sup> |          $6,000 or more per month           | None, built into the network with globally distributed Indexers |
+|      Queries per month       |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                     $0                      |                            $0.00004                             |
+|        Infrastructure        |                 Centralized                 |                          Decentralized                          |
+|    Geographic redundancy     |  $1,200 in total costs per additional node  |                            Included                             |
+|            Uptime            |                   Varies                    |                             99.9%+                              |
+|     Total Monthly Costs      | <span className="highlight-row" /> $11,000+ |                             $1,200                              |
 
 \*including costs for backup: $50-$100 per month
 

From d38b31d12bc35c2ee860c88179e14ee068e3cb7f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:03:44 -0500
Subject: [PATCH 0183/3820] New translations cosmos.mdx (Spanish)

---
 website/pages/es/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/cookbook/cosmos.mdx b/website/pages/es/cookbook/cosmos.mdx
index fe36514f6de9..67d7021cf6d0 100644
--- a/website/pages/es/cookbook/cosmos.mdx
+++ b/website/pages/es/cookbook/cosmos.mdx
@@ -170,7 +170,7 @@ Cada tipo de handler viene con su propia estructura de datos que se pasa como ar
 - Los handlers de transacciones reciben el tipo `TransactionData`.
 - Los handlers de mensajes reciben el tipo `MessageData`.
 
-Como parte de `MessageData`, el message handler recibe un contexto de transacción, que contiene la información más importante sobre una transacción que abarca un mensaje. El contexto de transacción también está disponible en el tipo `EventData`, pero solo cuando el evento correspondiente está asociado con una transacción. Además, todos los controladores reciben una referencia a un bloque (`HeaderOnlyBlock`).
+Como parte de `MessageData`, el message handler recibe un contexto de transacción, que contiene la información más importante sobre una transacción que abarca un mensaje. El contexto de transacción también está disponible en el tipo ` EventData `, pero solo cuando el evento correspondiente está asociado con una transacción. Además, todos los controladores reciben una referencia a un bloque (` HeaderOnlyBlock `).
 
 Puedes encontrar una lista completa de los tipos para la integración Cosmos aquí [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
 

From 25bf48d28b87f358c8b8611cc14ca6c33374ce7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:04:11 -0500
Subject: [PATCH 0184/3820] New translations cosmos.mdx (Urdu (Pakistan))

---
 website/pages/ur/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/cookbook/cosmos.mdx b/website/pages/ur/cookbook/cosmos.mdx
index 64a25e1cef88..19ef50e2ca0d 100644
--- a/website/pages/ur/cookbook/cosmos.mdx
+++ b/website/pages/ur/cookbook/cosmos.mdx
@@ -165,7 +165,7 @@ class Any {
 
 ہر ہینڈلر کی قسم اس کے اپنے ڈیٹا ڈھانچے کے ساتھ آتی ہے جو میپنگ فنکشن کی دلیل کے طور پر پاس کی جاتی ہے.
 
-- بلاک ہینڈلرز کو `Block` قسم موصول ہوتی ہے.
+- بلاک ہینڈلرز کو ` Block ` قسم موصول ہوتی ہے.
 - ایونٹ ہینڈلرز کو `EventData` قسم موصول ہوتی ہے.
 - ٹرانزیکشن ہینڈلرز کو `TransactionData` قسم موصول ہوتی ہے.
 - میسج ہینڈلرز کو `MessageData` قسم موصول ہوتی ہے.

From 5a7b652b75e6695b12e0bd164c478183ca23eea0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:04:35 -0500
Subject: [PATCH 0185/3820] New translations arweave.mdx (Portuguese)

---
 website/pages/pt/cookbook/arweave.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/pt/cookbook/arweave.mdx b/website/pages/pt/cookbook/arweave.mdx
index 83781cb0165e..beac71cf7ea5 100644
--- a/website/pages/pt/cookbook/arweave.mdx
+++ b/website/pages/pt/cookbook/arweave.mdx
@@ -86,7 +86,7 @@ dataSources:
 - A rede deve corresponder a uma rede no Graph Node que a hospeda. No Subgraph Studio, a mainnet do Arweave é `arweave-mainnet`
 - Fontes de dados no Arweave introduzem um campo `source.owner` opcional, a chave pública de uma carteira no Arweave
 
-Fontes de dados no Arweave apoiam duas categorias de _handlers_:
+Fontes de dados no Arweave apoiam duas categorias de *handlers*:
 
 - `blockHandlers` - Executar em cada bloco novo no Arweave. Nenhum `source.owner` é exigido.
 - `transactionHandlers` — Executar em todas as transações onde o `source.owner` da fonte de dados é o dono. Atualmente, um dono é exigido para o `transactionHandlers`; caso utilizadores queiram processar todas as transações, eles devem providenciar "" como o `source.owner`
@@ -97,13 +97,13 @@ Fontes de dados no Arweave apoiam duas categorias de _handlers_:
 
 > Nota: Transações no [Irys (antigo Bundlr)](https://bundlr.network/) não são apoiadas presentemente.
 
-## Definição de _Schema_
+## Definição de *Schema*
 
 A definição de Schema descreve a estrutura do banco de dados resultado do subgraph, e os relacionamentos entre entidades. Isto é agnóstico da fonte de dados original. Há mais detalhes na definição de schema de subgraph [aqui](/developing/creating-a-subgraph/#the-graphql-schema).
 
 ## Mapeamentos de AssemblyScript
 
-Os _handlers_ para eventos de processamento são escritos em [AssemblyScript](https://www.assemblyscript.org/).
+Os *handlers* para eventos de processamento são escritos em [AssemblyScript](https://www.assemblyscript.org/).
 
 Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/developing/graph-ts/api/).
 
@@ -146,7 +146,7 @@ class Transaction {
 }
 ```
 
-_Handlers_ de bloco recebem um `Block`, enquanto transações recebem uma `Transaction`.
+*Handlers* de bloco recebem um `Block`, enquanto transações recebem uma `Transaction`.
 
 Escrever os mapeamentos de um Subgraph no Arweave é muito similar à escrita dos mapeamentos de um Subgraph no Ethereum. Para mais informações, clique [aqui](/developing/creating-a-subgraph/#writing-mappings).
 

From e51950c6de1358833c7479855abc8843b9eabe96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:04:50 -0500
Subject: [PATCH 0186/3820] New translations subgraph-debug-forking.mdx
 (Arabic)

---
 website/pages/ar/cookbook/subgraph-debug-forking.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ar/cookbook/subgraph-debug-forking.mdx b/website/pages/ar/cookbook/subgraph-debug-forking.mdx
index 6c87d43045c5..44a8bfa28c2c 100644
--- a/website/pages/ar/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/ar/cookbook/subgraph-debug-forking.mdx
@@ -69,14 +69,14 @@ Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph St
 
 وأنا أجيب:
 
-1. `fork-base` هو عنوان URL "الأساسي" ،فمثلا عند إلحاق _subgraph id_ ، يكون عنوان URL الناتج (`<fork-base>/<subgraph-id>`) هو GraphQL endpoint صالح لمخزن الـ subgraph.
+1. ` fork-base ` هو عنوان URL "الأساسي" ،فمثلا عند إلحاق _subgraph id_ ، يكون عنوان URL الناتج (`<fork-base>/<subgraph-id>`) هو GraphQL endpoint صالح لمخزن الـ subgraph.
 2. الـتفريع سهل ، فلا داعي للقلق:
 
 ```bash
 $ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
 ```
 
-أيضًا ، لا تنس تعيين حقل `dataSources.source.startBlock` في subgraph manifest لرقم الكتلة(block) التي بها المشكلة، حتى تتمكن من تخطي فهرسة الكتل الغير ضرورية والاستفادة من التفريع!
+أيضًا ، لا تنس تعيين حقل ` dataSources.source.startBlock ` في subgraph manifest لرقم الكتلة(block) التي بها المشكلة، حتى تتمكن من تخطي فهرسة الكتل الغير ضرورية والاستفادة من التفريع!
 
 لذلك ، هذا ما أفعله:
 
@@ -90,7 +90,7 @@ $ cargo run -p graph-node --release -- \
     --fork-base https://api.thegraph.com/subgraphs/id/
 ```
 
-2. بعد فحص دقيق ، لاحظت أن هناك عدم تطابق في تمثيلات الـ `id` المستخدمة عند فهرسة `Gravatar` في المعالجين الخاصين بي. بينما `handleNewGravatar` يحول (`event.params.id.toHex()`) إلى سداسي ، `handleUpdatedGravatar` يستخدم int32 (`event.params.id.toI32()`) مما يجعل `handleUpdatedGravatar` قلقا من "Gravatar not found!". أنا أجعلهم كلاهما يحولان `id` إلى سداسي.
+2. بعد فحص دقيق ، لاحظت أن هناك عدم تطابق في تمثيلات الـ ` id ` المستخدمة عند فهرسة ` Gravatar ` في المعالجين الخاصين بي. بينما ` handleNewGravatar ` يحول (`event.params.id.toHex()`) إلى سداسي ، `handleUpdatedGravatar` يستخدم int32 (`event.params.id.toI32()`) مما يجعل ` handleUpdatedGravatar ` قلقا من "Gravatar not found!". أنا أجعلهم كلاهما يحولان ` id ` إلى سداسي.
 3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
 
 ```bash

From ef71f21390c26d9375593947de6d9ed56bd6d29f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:04:51 -0500
Subject: [PATCH 0187/3820] New translations subgraph-debug-forking.mdx (Czech)

---
 website/pages/cs/cookbook/subgraph-debug-forking.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/cookbook/subgraph-debug-forking.mdx b/website/pages/cs/cookbook/subgraph-debug-forking.mdx
index 84df907a9602..522c273a7e36 100644
--- a/website/pages/cs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/cs/cookbook/subgraph-debug-forking.mdx
@@ -14,7 +14,7 @@ V kontextu ladění vám ** vidličkování podgrafů** umožňuje ladit neúsp
 
 Když nasadíte podgraf do vzdáleného uzlu Graf pro indexování a ten selže v bloku _X_, dobrou zprávou je, že uzel Graf bude stále obsluhovat dotazy GraphQL pomocí svého úložiště, které je synchronizováno s blokem _X_. To je skvělé! To znamená, že můžeme využít tohoto "aktuálního" úložiště k opravě chyb vznikajících při indexování bloku _X_.
 
-Stručně řečeno, _rozvětvíme neúspěšný podgraf_ ze vzdáleného uzlu grafu, u kterého je zaručeno, že podgraf bude indexován až do bloku _X_, abychom lokálně nasazenému podgrafu laděnému v bloku _X_ poskytli aktuální pohled na stav indexování.
+Stručně řečeno, _rozvětvíme neúspěšný podgraf_ ze vzdáleného uzlu grafu, u kterého je zaručeno, že podgraf bude indexován až do bloku *X*, abychom lokálně nasazenému podgrafu laděnému v bloku _X_ poskytli aktuální pohled na stav indexování.
 
 ## Ukažte mi prosím nějaký kód!
 

From 82527a408e28028b1d1628d214fd2314001cfb3f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:01 -0500
Subject: [PATCH 0188/3820] New translations subgraph-debug-forking.mdx
 (Japanese)

---
 website/pages/ja/cookbook/subgraph-debug-forking.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ja/cookbook/subgraph-debug-forking.mdx b/website/pages/ja/cookbook/subgraph-debug-forking.mdx
index a18cf73d17b7..6fbb5070e2ec 100644
--- a/website/pages/ja/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/ja/cookbook/subgraph-debug-forking.mdx
@@ -6,9 +6,9 @@ As with many systems processing large amounts of data, The Graph's Indexers (Gra
 
 ## さて、それは何でしょうか？
 
-**サブグラフのフォーク**とは、*他*のサブグラフのストア(通常はリモート) からエンティティをフェッチするプロセスです。
+**サブグラフのフォーク**とは、_他_のサブグラフのストア(通常はリモート) からエンティティをフェッチするプロセスです。
 
-デバッグの文脈では、**サブグラフのフォーク**により、ブロック*X*への同期を待つことなく、ブロック*X*で失敗したサブグラフのデバッグを行うことができます。
+デバッグの文脈では、**サブグラフのフォーク**により、ブロック_X_への同期を待つことなく、ブロック_X_で失敗したサブグラフのデバッグを行うことができます。
 
 ## その方法は？
 
@@ -69,7 +69,7 @@ Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph St
 
 回答：
 
-1. `fork-base`は「ベース」URLで、*subgraph id*が追加されたときのURL (`<fork-base>/<subgraph-id>`) はサブグラフのストアに対する有効な GraphQL endpoint であることを示します。
+1. `fork-base`は「ベース」URLで、_subgraph id_が追加されたときのURL (`<fork-base>/<subgraph-id>`) はサブグラフのストアに対する有効な GraphQL endpoint であることを示します。
 2. フォーキングは簡単であり煩雑な手間はありません
 
 ```bash

From 5ba449ec7a130f2b34bd93f15c63160944b528cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:14 -0500
Subject: [PATCH 0189/3820] New translations subgraph-debug-forking.mdx
 (Chinese Simplified)

---
 website/pages/zh/cookbook/subgraph-debug-forking.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/cookbook/subgraph-debug-forking.mdx b/website/pages/zh/cookbook/subgraph-debug-forking.mdx
index 9407cd0d670a..96fdd046a87f 100644
--- a/website/pages/zh/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/zh/cookbook/subgraph-debug-forking.mdx
@@ -6,7 +6,7 @@ As with many systems processing large amounts of data, The Graph's Indexers (Gra
 
 ## 首先，让我们来看什么是子图分叉
 
-**子图分叉** 是从*另一个* 子图的存储（通常是远程存储）中缓慢获取实体的过程。
+**子图分叉** 是从_另一个_ 子图的存储（通常是远程存储）中缓慢获取实体的过程。
 
 在调试时，**subgraph forking** 允许您在固定的区块 _X_ 中调试失败的子图，而无需等待区块同步 _X_。
 

From 2d71176fdce78edc1e2a24dbec4851c8a5d956fd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:21 -0500
Subject: [PATCH 0190/3820] New translations subgraph-debug-forking.mdx (Hindi)

---
 website/pages/hi/cookbook/subgraph-debug-forking.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/cookbook/subgraph-debug-forking.mdx b/website/pages/hi/cookbook/subgraph-debug-forking.mdx
index da72d452509e..89d0d58605ff 100644
--- a/website/pages/hi/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/hi/cookbook/subgraph-debug-forking.mdx
@@ -8,7 +8,7 @@ As with many systems processing large amounts of data, The Graph's Indexers (Gra
 
 **सबग्राफ फोर्किंग** आलसी ढंग से _दूसरे_ सबग्राफ के स्टोर (आमतौर पर एक परोक्ष सबग्राफ) से इकाइयां को लाने की प्रक्रिया है।
 
-डिबगिंग के संदर्भ में, **सबग्राफ फोर्किंग** आपको ब्लॉक*X* को सिंक-अप करने के लिए बिना प्रतीक्षा किए ब्लॉक _X_ पर अपने विफल सबग्राफ को डीबग करने की अनुमति देता है ।
+डिबगिंग के संदर्भ में, **सबग्राफ फोर्किंग** आपको ब्लॉक_X_ को सिंक-अप करने के लिए बिना प्रतीक्षा किए ब्लॉक _X_ पर अपने विफल सबग्राफ को डीबग करने की अनुमति देता है ।
 
 ## क्या?! कैसे?
 

From ffcbfc26afb30b656c7aa226b7c83a26d2b939f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:28 -0500
Subject: [PATCH 0191/3820] New translations delegating.mdx (Arabic)

---
 website/pages/ar/network/delegating.mdx | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/website/pages/ar/network/delegating.mdx b/website/pages/ar/network/delegating.mdx
index 185dc09a8cac..812f7bd16609 100644
--- a/website/pages/ar/network/delegating.mdx
+++ b/website/pages/ar/network/delegating.mdx
@@ -48,7 +48,9 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
 
 If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
 
-<div sx={{ mx: 'auto', maxWidth: '400px' }}>لاحظ 0.5٪ رسوم التفويض ، بالإضافة إلى فترة 28 يوما لإلغاء التفويض.</div>
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  لاحظ 0.5٪ رسوم التفويض ، بالإضافة إلى فترة 28 يوما لإلغاء التفويض.
+</div>
 
 ### اختيار مفهرس جدير بالثقة مع عائد جيد للمفوضين
 
@@ -121,7 +123,7 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### مثال
+#### Example
 
 Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
 

From 8548d36b4f59a71c5d5ce233cf0b346d1ec8222e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:29 -0500
Subject: [PATCH 0192/3820] New translations delegating.mdx (Czech)

---
 website/pages/cs/network/delegating.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/cs/network/delegating.mdx b/website/pages/cs/network/delegating.mdx
index ef106bad0942..249cd411e45a 100644
--- a/website/pages/cs/network/delegating.mdx
+++ b/website/pages/cs/network/delegating.mdx
@@ -64,8 +64,8 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
   - If it is set to 80%, as a Delegator, you will receive 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *Nejlepší indexátor dává delegátům 90 % odměn. Na prostřední dává
-  delegátům 20 % odměn. Spodní dává delegátům ~83 %.*
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *Nejlepší indexátor dává delegátům 90 % odměn. Na
+  prostřední dává delegátům 20 % odměn. Spodní dává delegátům ~83 %.*
 </div>
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.

From 2019bf855d519cf720e1633c7f0dc95256142382 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:30 -0500
Subject: [PATCH 0193/3820] New translations delegating.mdx (German)

---
 website/pages/de/network/delegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/network/delegating.mdx b/website/pages/de/network/delegating.mdx
index eda60369e00a..5fa99f101641 100644
--- a/website/pages/de/network/delegating.mdx
+++ b/website/pages/de/network/delegating.mdx
@@ -125,7 +125,7 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
+#### Beispiel
 
 Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
 

From af7376ebe2cf7fb97e1bee52683267f2948660f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:36 -0500
Subject: [PATCH 0194/3820] New translations indexing.mdx (Romanian)

---
 website/pages/ro/network/indexing.mdx | 34 +++++++++++++--------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/ro/network/indexing.mdx b/website/pages/ro/network/indexing.mdx
index a6844c2da009..0eb017b5be3f 100644
--- a/website/pages/ro/network/indexing.mdx
+++ b/website/pages/ro/network/indexing.mdx
@@ -112,12 +112,12 @@ Indexers may differentiate themselves by applying advanced techniques for making
 - **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
 - **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
 
-| Setup | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Small | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 | 184 |
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- |:--------------------------:|:-----------------------------------:|:---------------------------------:|:---------------------:|:------------------------------:|
+| Small    |             4              |                  8                  |                 1                 |           4           |               16               |
+| Standard |             8              |                 30                  |                 1                 |          12           |               48               |
+| Medium   |             16             |                 64                  |                 2                 |          32           |               64               |
+| Large    |             72             |                 468                 |                3.5                |          48           |              184               |
 
 ### What are some basic security precautions an Indexer should take?
 
@@ -149,20 +149,20 @@ Note: To support agile scaling, it is recommended that query and indexing concer
 
 #### Graph Node
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(for subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                               | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                          | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                    | /metrics                                             | --metrics-port    | -                    |
 
 #### Indexer Service
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                                    | Routes                                                                  | CLI Argument   | Environment Variable   |
+| ---- | ---------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                         | /metrics                                                                | --metrics-port | -                      |
 
 #### Indexer Agent
 

From 0fd9061a64794ee2882d095bdc1984b08017e619 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:38 -0500
Subject: [PATCH 0195/3820] New translations delegating.mdx (Italian)

---
 website/pages/it/network/delegating.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/it/network/delegating.mdx b/website/pages/it/network/delegating.mdx
index e7d832347433..d5c86e5ecf43 100644
--- a/website/pages/it/network/delegating.mdx
+++ b/website/pages/it/network/delegating.mdx
@@ -49,8 +49,8 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
 If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![Sblocco di Delegator](/img/Delegation-Unbonding.png) _Nota la commissione del 0,5% nel UI della delegazione, così
-  come il periodo di sblocco di 28 giorni. periodo di sblocco._
+  ![Sblocco di Delegator](/img/Delegation-Unbonding.png) _Nota la commissione del 0,5% nel UI della delegazione, così come il periodo di sblocco di 28 giorni.
+  periodo di sblocco._
 </div>
 
 ### Scegliere un Indexer affidabile con una giusta ricompensa per i Delegator
@@ -64,8 +64,8 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
   - If it is set to 80%, as a Delegator, you will receive 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Taglio delle ricompense dell'indicizzazione](/img/Indexing-Reward-Cut.png) *Il top Indexer sta dando ai Delegator il
-  90% delle ricompense. Il centrale dà ai Delegator il 20%. Quello in basso dà ai Delegator ~83%.*
+  ![Taglio delle ricompense dell'indicizzazione](/img/Indexing-Reward-Cut.png) *Il top Indexer sta dando ai Delegator il 90% delle ricompense. Il
+  centrale dà ai Delegator il 20%. Quello in basso dà ai Delegator ~83%.*
 </div>
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.

From b884db79b8743d35504f07fc548099a3896b14fd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:40 -0500
Subject: [PATCH 0196/3820] New translations delegating.mdx (Dutch)

---
 website/pages/nl/network/delegating.mdx | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/website/pages/nl/network/delegating.mdx b/website/pages/nl/network/delegating.mdx
index 84d2c6dd2118..c0a3224f156c 100644
--- a/website/pages/nl/network/delegating.mdx
+++ b/website/pages/nl/network/delegating.mdx
@@ -49,8 +49,7 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
 If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Let op de 0,5% belasting in de Delegatie UI, evenals de
-  28-daagse ontbindingsperiode_
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Let op de 0,5% belasting in de Delegatie UI, evenals de 28-daagse ontbindingsperiode_
 </div>
 
 ### Het kiezen van een betrouwbare Indexeerder met een eerlijke beloningsuitbetaling voor Delegeerders
@@ -64,8 +63,7 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
   - If it is set to 80%, as a Delegator, you will receive 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *De bovenste Indexeerder geeft Delegeerders 90% van de
-  beloningen. De middelste geeft Delegeerders 20%. De onderste geeft Delegeerders ~83%.*
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png)  *De bovenste Indexeerder geeft Delegeerders 90% van de beloningen. De middelste geeft Delegeerders 20%. De onderste geeft Delegeerders ~83%.*
 </div>
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.

From 1077847b1dc7567a33ea5c81a7e87f07cad5b006 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:49 -0500
Subject: [PATCH 0197/3820] New translations delegating.mdx (Portuguese)

---
 website/pages/pt/network/delegating.mdx | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/website/pages/pt/network/delegating.mdx b/website/pages/pt/network/delegating.mdx
index e2880912d7b3..97c25db9c751 100644
--- a/website/pages/pt/network/delegating.mdx
+++ b/website/pages/pt/network/delegating.mdx
@@ -49,8 +49,7 @@ Se um Delegado quiser cancelar a sua delegação, seus tokens estarão sujeitos
 If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Perceba a taxa de 0.5% na interface da Delegação, além do
-  período de separação de 28 dias._
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Perceba a taxa de 0.5% na interface da Delegação, além do período de separação de 28 dias._
 </div>
 
 ### Como escolher um Indexador de confiança, com um pagamento justo para Delegantes
@@ -64,8 +63,7 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
   - If it is set to 80%, as a Delegator, you will receive 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *O Indexador acima está a dar 90% das recompensas aos Delegantes,
-  o do meio dá 20%, e o de baixo dá cerca de 83%.*
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *O Indexador acima está a dar 90% das recompensas aos Delegantes, o do meio dá 20%, e o de baixo dá cerca de 83%.*
 </div>
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.

From 1cec7433fa62f70f2000877916f9416c99f6e706 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:50 -0500
Subject: [PATCH 0198/3820] New translations delegating.mdx (Swedish)

---
 website/pages/sv/network/delegating.mdx | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/website/pages/sv/network/delegating.mdx b/website/pages/sv/network/delegating.mdx
index a342ea0e34eb..42363dfd0958 100644
--- a/website/pages/sv/network/delegating.mdx
+++ b/website/pages/sv/network/delegating.mdx
@@ -49,8 +49,8 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
 If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![Delegation upphävning](/img/Delegation-Unbonding.png) _Observera avgiften på 0,5% i Delegation UI, samt den 28 dagar
-  långa upphävningsperioden._
+  ![Delegation upphävning](/img/Delegation-Unbonding.png) _Observera avgiften
+på 0,5% i Delegation UI, samt den 28 dagar långa   upphävningsperioden._
 </div>
 
 ### Att välja en pålitlig Indexer med en rättvis belöningsutbetalning till Delegater
@@ -64,8 +64,9 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
   - If it is set to 80%, as a Delegator, you will receive 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Edward Cut](/img/Indexing-Reward-Cut.png) *Den översta Indexet ger Delegater 90% av belöningarna. Den
-  mellersta ger Delegater 20%. Den nedersta ger Delegater ~83%.*
+  ![Indexing Edward Cut](/img/Indexing-Reward-Cut.png) *Den översta Indexet ger
+Delegater 90% av belöningarna. Den   mellersta ger Delegater 20%. Den nedersta
+ger Delegater ~83%.*
 </div>
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.

From 82f9e65cdfd431aa61ad098cec2bd41ec7ca99cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:52 -0500
Subject: [PATCH 0199/3820] New translations delegating.mdx (Ukrainian)

---
 website/pages/uk/network/delegating.mdx | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/website/pages/uk/network/delegating.mdx b/website/pages/uk/network/delegating.mdx
index be1802797a9a..8327acb60b7b 100644
--- a/website/pages/uk/network/delegating.mdx
+++ b/website/pages/uk/network/delegating.mdx
@@ -49,8 +49,7 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
 If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Зверніть увагу на комісію в розмірі 0,5% в Інтерфейсі для
-  делегацій, а також на 28-денний період розблокування._
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Зверніть увагу на комісію в розмірі 0,5% в Інтерфейсі для делегацій, а також на 28-денний період розблокування._
 </div>
 
 ### Вибір надійного індексатора зі справедливою винагородою для делегатів
@@ -64,8 +63,7 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
   - If it is set to 80%, as a Delegator, you will receive 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *Найкращий індексатор віддає делегатам 90% від суми винагороди.
-  Середній - 20%. Найменший індексатор дає ~83%. *
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *Найкращий індексатор віддає делегатам 90% від суми винагороди. Середній - 20%. Найменший індексатор дає ~83%. *
 </div>
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.

From 442237ab82ff93a3aa3a3ee9c4c094b7754bb097 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:05:58 -0500
Subject: [PATCH 0200/3820] New translations curating.mdx (Hindi)

---
 website/pages/hi/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/network/curating.mdx b/website/pages/hi/network/curating.mdx
index ed5965d0e5cd..34d446b1314f 100644
--- a/website/pages/hi/network/curating.mdx
+++ b/website/pages/hi/network/curating.mdx
@@ -47,7 +47,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 ## जोखिम
 
 1. क्वेरी बाजार द ग्राफ में स्वाभाविक रूप से युवा है और इसमें जोखिम है कि नवजात बाजार की गतिशीलता के कारण आपका %APY आपकी अपेक्षा से कम हो सकता है।
-2. क्यूरेशन शुल्क - जब कोई क्यूरेटर किसी सबग्राफ़ पर GRT सिग्नल करता है, तो उसे 1% क्यूरेशन टैक्स देना होता है। यह शुल्क जला दिया जाता है।
+2. क्यूरेशन शुल्क  - जब कोई क्यूरेटर किसी सबग्राफ़ पर GRT सिग्नल करता है, तो उसे 1% क्यूरेशन टैक्स देना होता है। यह शुल्क जला दिया जाता है।
 3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/network/delegating).
 4. बग के कारण सबग्राफ विफल हो सकता है। एक विफल सबग्राफ क्वेरी शुल्क अर्जित नहीं करता है। नतीजतन, आपको तब तक इंतजार करना होगा जब तक कि डेवलपर बग को ठीक नहीं करता है और एक नया संस्करण तैनात करता है।
    - यदि आपने सबग्राफ के नवीनतम संस्करण की सदस्यता ली है, तो आपके शेयर उस नए संस्करण में स्वत: माइग्रेट हो जाएंगे। इस पर 0.5% क्यूरेशन टैक्स लगेगा।

From 9e58b6395a58f4940cb201749dfb1ce0e80a035c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:00 -0500
Subject: [PATCH 0201/3820] New translations delegating.mdx (Chinese
 Simplified)

---
 website/pages/zh/network/delegating.mdx | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/website/pages/zh/network/delegating.mdx b/website/pages/zh/network/delegating.mdx
index 7f7954b42fdc..80ca76888364 100644
--- a/website/pages/zh/network/delegating.mdx
+++ b/website/pages/zh/network/delegating.mdx
@@ -48,7 +48,9 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
 
 If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
 
-<div sx={{ mx: 'auto', maxWidth: '400px' }}>请注意委托用户界面中的0.5%费用，以及28天的解约期。</div>
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  请注意委托用户界面中的0.5%费用，以及28天的解约期。
+</div>
 
 ### 选择一个为委托人提供公平的奖励分配的值得信赖的索引人
 
@@ -61,8 +63,7 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
   - If it is set to 80%, as a Delegator, you will receive 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *上 面的索引人分给委托人 90% 的收益。 中间的给委托人 20%。
-  下面的给委托人约 83%。
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *上 面的索引人分给委托人 90% 的收益。 中间的给委托人 20%。 下面的给委托人约 83%。
 </div>
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.

From bba4192ffbf03ada773adce0d559afca7dff36f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:01 -0500
Subject: [PATCH 0202/3820] New translations delegating.mdx (Urdu (Pakistan))

---
 website/pages/ur/network/delegating.mdx | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/website/pages/ur/network/delegating.mdx b/website/pages/ur/network/delegating.mdx
index 062b3c7db382..5bc50cb9ce02 100644
--- a/website/pages/ur/network/delegating.mdx
+++ b/website/pages/ur/network/delegating.mdx
@@ -49,8 +49,8 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
 If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  [ڈیلیگیشن ان بانڈنگ](/img/Delegation-Unbonding.png) _ڈیلیگیشن UI میں 0.5% فیس نوٹ کریں، ساتھ ہی 28 دن غیر بندھن کی
-  مدت۔_
+  [ڈیلیگیشن ان بانڈنگ](/img/Delegation-Unbonding.png) _ڈیلیگیشن UI میں 0.5% فیس نوٹ کریں، ساتھ ہی 28 دن
+  غیر بندھن کی مدت۔_
 </div>
 
 ### ڈیلیگیٹرز کے لیے منصفانہ انعامی ادائیگی کے ساتھ ایک قابل اعتماد انڈیکسر کا انتخاب کرنا
@@ -64,8 +64,7 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
   - If it is set to 80%, as a Delegator, you will receive 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![انڈیکسنگ ریوارڈ کٹ](/img/Indexing-Reward-Cut.png) *سب سے اوپر انڈیکسر ڈیلیگیٹرز کو 90% انعامات دے رہا ہے. درمیان
-  والا ڈیلیگیٹرز کو 20% دے رہا ہے۔ نیچے والا ڈیلیگیٹرز کو ~83% دے رہا ہے۔*
+  ![انڈیکسنگ ریوارڈ کٹ](/img/Indexing-Reward-Cut.png) *سب سے اوپر انڈیکسر ڈیلیگیٹرز کو 90% انعامات دے رہا ہے. درمیان والا ڈیلیگیٹرز کو 20% دے رہا ہے۔ نیچے والا ڈیلیگیٹرز کو ~83% دے رہا ہے۔*
 </div>
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.

From 4139f4810b5d62ea353251e42239f895b20e2064 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:03 -0500
Subject: [PATCH 0203/3820] New translations delegating.mdx (Marathi)

---
 website/pages/mr/network/delegating.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/mr/network/delegating.mdx b/website/pages/mr/network/delegating.mdx
index a3cffb359ffe..8877d25721c4 100644
--- a/website/pages/mr/network/delegating.mdx
+++ b/website/pages/mr/network/delegating.mdx
@@ -50,7 +50,7 @@ If you choose an Indexer that is not trustworthy or not doing a good job, you wi
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![प्रतिनिधी अनबॉन्डिंग](/img/Delegation-Unbonding.png) _डेलिगेशन UI मध्ये 0.5% शुल्क तसेच २८ दिवसांची नोंद घ्या
-  अनबॉन्डिंग कालावधी._
+   अनबॉन्डिंग कालावधी._
 </div>
 
 ### Choosing a trustworthy Indexer with a fair reward payout for Delegators
@@ -64,8 +64,8 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
   - If it is set to 80%, as a Delegator, you will receive 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![इंडेक्सिंग रिवॉर्ड कट](/img/Indexing-Reward-Cut.png) *टॉप इंडेक्सर प्रतिनिधींना 90% बक्षिसे देत आहे. द मधला
-  प्रतिनिधी 20% देत आहे. सर्वात खालचा भाग प्रतिनिधींना ~83% देत आहे.*
+  ![इंडेक्सिंग रिवॉर्ड कट](/img/Indexing-Reward-Cut.png) *टॉप इंडेक्सर प्रतिनिधींना 90% बक्षिसे देत आहे. द
+   मधला प्रतिनिधी 20% देत आहे. सर्वात खालचा भाग प्रतिनिधींना ~83% देत आहे.*
 </div>
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.

From 4000d235b9a1a66115e54668b3fa548f33110e8a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:05 -0500
Subject: [PATCH 0204/3820] New translations delegating.mdx (Hindi)

---
 website/pages/hi/network/delegating.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/hi/network/delegating.mdx b/website/pages/hi/network/delegating.mdx
index 926c4520fc6e..09c0de82002b 100644
--- a/website/pages/hi/network/delegating.mdx
+++ b/website/pages/hi/network/delegating.mdx
@@ -49,8 +49,8 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
 यदि आप किसी ऐसे Indexer का चयन करते हैं जो विश्वसनीय नहीं है या अच्छा काम नहीं कर रहा है, तो आप डेलीगेट को रद्द करना चाहेंगे। इसका मतलब है कि आप पुरस्कार कमाने के कई अवसर खो देंगे, जो GRT को जलाने के समान बुरा हो सकता है। परिणामस्वरूप, यह अनुशंसा की जाती है कि आप एक Indexer का चयन समझदारी से करें।
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![डेलिगेशन अनबॉन्डिंग](/img/Delegation-Unbonding.png) _डेलीगेशन UI में 0.5% शुल्क और साथ ही 28 दिन पर ध्यान दें बंधन
-  अवधि._
+  ![डेलिगेशन अनबॉन्डिंग](/img/Delegation-Unbonding.png) _डेलीगेशन UI में 0.5% शुल्क और साथ ही 28 दिन पर ध्यान दें
+   बंधन अवधि._
 </div>
 
 ### डेलीगेटर्स के लिए उचित इनाम भुगतान के साथ एक भरोसेमंद इंडेक्सर चुनना
@@ -64,8 +64,8 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
   - यदि इसे 80% पर सेट किया गया है, तो एक Delegator के रूप में, आप 20% प्राप्त करेंगे।
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![इंडेक्सिंग रिवॉर्ड कट](/img/Indexing-Reward-Cut.png) *शीर्ष इंडेक्सर डेलीगेटर्स को पुरस्कारों का 90% दे रहा है। बीच
-  वाला प्रतिनिधि को 20% दे रहा है। नीचे वाला डेलिगेटरों को ~83% दे रहा है।*
+  ![इंडेक्सिंग रिवॉर्ड कट](/img/Indexing-Reward-Cut.png) *शीर्ष इंडेक्सर डेलीगेटर्स को पुरस्कारों का 90% दे रहा है। 
+   बीच वाला प्रतिनिधि को 20% दे रहा है। नीचे वाला डेलिगेटरों को ~83% दे रहा है।*
 </div>
 
 - **क्वेरी शुल्क कटौती** - यह बिल्कुल 'Indexing Reward Cut' जैसा है, लेकिन यह उन रिटर्न पर लागू होता है जो 'query fees' से प्राप्त होते हैं जो Indexers एकत्र करते हैं।

From 9225863b29492ce43dcc9909255db4b129d7f75a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:11 -0500
Subject: [PATCH 0205/3820] New translations indexing.mdx (Spanish)

---
 website/pages/es/network/indexing.mdx | 32 +++++++++++++--------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/es/network/indexing.mdx b/website/pages/es/network/indexing.mdx
index e85cc01e0b86..076ee45d9703 100644
--- a/website/pages/es/network/indexing.mdx
+++ b/website/pages/es/network/indexing.mdx
@@ -113,11 +113,11 @@ Los indexadores pueden diferenciarse aplicando técnicas avanzadas para tomar de
 - **Grande**: Preparado para indexar todos los subgrafos utilizados actualmente y atender solicitudes para el tráfico relacionado.
 
 | Configuración | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Pequeño | 4 | 8 | 1 | 4 | 16 |
-| Estándar | 8 | 30 | 1 | 12 | 48 |
-| Medio | 16 | 64 | 2 | 32 | 64 |
-| Grande | 72 | 468 | 3,5 | 48 | 184 |
+| ------------- |:--------------------------:|:-----------------------------------:|:---------------------------------:|:---------------------:|:------------------------------:|
+| Pequeño       |             4              |                  8                  |                 1                 |           4           |               16               |
+| Estándar      |             8              |                 30                  |                 1                 |          12           |               48               |
+| Medio         |             16             |                 64                  |                 2                 |          32           |               64               |
+| Grande        |             72             |                 468                 |                3,5                |          48           |              184               |
 
 ### ¿Qué precauciones básicas de seguridad debe tomar un Indexador?
 
@@ -149,20 +149,20 @@ Nota: Para admitir el escalado ágil, se recomienda que las inquietudes de consu
 
 #### Graph Node
 
-| Puerto | Objeto | Rutas | Argumento CLI | Variable de Entorno |
-| --- | --- | --- | --- | --- |
-| 8000 | Servidor HTTP GraphQL<br />(para consultas de subgrafos) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(para suscripciones a subgrafos) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(para administrar implementaciones) | / | --admin-port | - |
-| 8030 | API de estado de indexación de subgrafos | /graphql | --index-node-port | - |
-| 8040 | Métricas de Prometheus | /metrics | --metrics-port | - |
+| Puerto | Objeto                                                         | Rutas                                                | Argumento CLI     | Variable de Entorno |
+| ------ | -------------------------------------------------------------- | ---------------------------------------------------- | ----------------- | ------------------- |
+| 8000   | Servidor HTTP GraphQL<br />(para consultas de subgrafos) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                   |
+| 8001   | GraphQL WS<br />(para suscripciones a subgrafos)         | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                   |
+| 8020   | JSON-RPC<br />(para administrar implementaciones)        | /                                                    | --admin-port      | -                   |
+| 8030   | API de estado de indexación de subgrafos                       | /graphql                                             | --index-node-port | -                   |
+| 8040   | Métricas de Prometheus                                         | /metrics                                             | --metrics-port    | -                   |
 
 #### Servicio de Indexador
 
-| Puerto | Objeto | Rutas | Argumento CLI | Variable de Entorno |
-| --- | --- | --- | --- | --- |
-| 7600 | Servidor HTTP GraphQL<br />(para consultas de subgrafo pagadas) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Métricas de Prometheus | /metrics | --metrics-port | - |
+| Puerto | Objeto                                                                | Rutas                                                                   | Argumento CLI  | Variable de Entorno    |
+| ------ | --------------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600   | Servidor HTTP GraphQL<br />(para consultas de subgrafo pagadas) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300   | Métricas de Prometheus                                                | /metrics                                                                | --metrics-port | -                      |
 
 #### Agente Indexador
 

From ac01bfbd5f81f73945f3bc316d9146169b1d595e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:13 -0500
Subject: [PATCH 0206/3820] New translations indexing.mdx (Arabic)

---
 website/pages/ar/network/indexing.mdx | 32 +++++++++++++--------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/ar/network/indexing.mdx b/website/pages/ar/network/indexing.mdx
index e5cb4d8ea17d..849d5d13f7b5 100644
--- a/website/pages/ar/network/indexing.mdx
+++ b/website/pages/ar/network/indexing.mdx
@@ -113,11 +113,11 @@ The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that
 - **كبيرة** - مُعدة لفهرسة جميع ال subgraphs المستخدمة حاليا وأيضا لخدمة طلبات حركة مرور البيانات ذات الصلة.
 
 | Setup | Postgres<br /> (CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| صغير | 4 | 8 | 1 | 4 | 16 |
-| قياسي | 8 | 30 | 1 | 12 | 48 |
-| متوسط | 16 | 64 | 2 | 32 | 64 |
-| كبير | 72 | 468 | 3.5 | 48 | 184 |
+| ----- |:---------------------------:|:-----------------------------------:|:---------------------------------:|:---------------------:|:------------------------------:|
+| صغير  |              4              |                  8                  |                 1                 |           4           |               16               |
+| قياسي |              8              |                 30                  |                 1                 |          12           |               48               |
+| متوسط |             16              |                 64                  |                 2                 |          32           |               64               |
+| كبير  |             72              |                 468                 |                3.5                |          48           |              184               |
 
 ### What are some basic security precautions an Indexer should take?
 
@@ -149,20 +149,20 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 #### Graph Node
 
-| المنفذ | الغرض | المسار | CLI Argument | متغيرات البيئة |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | http-port-- | - |
-| 8001 | GraphQL WS <br /> (for subgraph subscriptions) | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | ws-port-- | - |
-| 8020 | JSON-RPC <br /> (for managing deployments) | / | admin-port-- | - |
-| 8030 | Subgraph indexing status API | /graphql | index-node-port-- | - |
-| 8040 | Prometheus metrics | /metrics | metrics-port-- | - |
+| المنفذ | الغرض                                                   | المسار                                                              | CLI Argument      | متغيرات البيئة |
+| ------ | ------------------------------------------------------- | ------------------------------------------------------------------- | ----------------- | -------------- |
+| 8000   | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | http-port--       | -              |
+| 8001   | GraphQL WS <br /> (for subgraph subscriptions)    | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | ws-port--         | -              |
+| 8020   | JSON-RPC <br /> (for managing deployments)        | /                                                                   | admin-port--      | -              |
+| 8030   | Subgraph indexing status API                            | /graphql                                                            | index-node-port-- | -              |
+| 8040   | Prometheus metrics                                      | /metrics                                                            | metrics-port--    | -              |
 
 #### خدمة المفهرس
 
-| المنفذ | الغرض | المسار | CLI Argument | متغيرات البيئة |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server <br /> (for paid subgraph queries) | /subgraphs/id/... <br /> /status <br /> /channel-messages-inbox | port-- | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | metrics-port-- | - |
+| المنفذ | الغرض                                                        | المسار                                                                      | CLI Argument   | متغيرات البيئة         |
+| ------ | ------------------------------------------------------------ | --------------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600   | GraphQL HTTP server <br /> (for paid subgraph queries) | /subgraphs/id/... <br /> /status <br /> /channel-messages-inbox | port--         | `INDEXER_SERVICE_PORT` |
+| 7300   | Prometheus metrics                                           | /metrics                                                                    | metrics-port-- | -                      |
 
 #### وكيل المفهرس(Indexer Agent)
 

From c5af1eba7b218508ab74af3fd568b842543ffc38 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:14 -0500
Subject: [PATCH 0207/3820] New translations indexing.mdx (Czech)

---
 website/pages/cs/network/indexing.mdx | 32 +++++++++++++--------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/cs/network/indexing.mdx b/website/pages/cs/network/indexing.mdx
index a3fb06a96484..fe0a36c340ca 100644
--- a/website/pages/cs/network/indexing.mdx
+++ b/website/pages/cs/network/indexing.mdx
@@ -113,11 +113,11 @@ Indexátory se mohou odlišovat použitím pokročilých technik pro rozhodován
 - **Large** - Připraveno k indexování všech aktuálně nepoužívaných příbuzných podgrafů.
 
 | Nastavení | Postgres<br />(CPUs) | Postgres<br />(paměť v GBs) | Postgres<br />(disk v TBs) | VMs<br />(CPUs) | VMs<br />(paměť v GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Malé | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Střední | 16 | 64 | 2 | 32 | 64 |
-| Velký | 72 | 468 | 3.5 | 48 | 184 |
+| --------- |:--------------------------:|:---------------------------------:|:--------------------------------:|:---------------------:|:----------------------------:|
+| Malé      |             4              |                 8                 |                1                 |           4           |              16              |
+| Standard  |             8              |                30                 |                1                 |          12           |              48              |
+| Střední   |             16             |                64                 |                2                 |          32           |              64              |
+| Velký     |             72             |                468                |               3.5                |          48           |             184              |
 
 ### Jaká jsou základní bezpečnostní opatření, která by měl indexátor přijmout?
 
@@ -149,20 +149,20 @@ Poznámka: Pro podporu agilního škálování se doporučuje oddělit dotazová
 
 #### Uzel Graf
 
-| Port | Účel | Trasy | CLI Argument | Proměnná prostředí |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(pro dotazy podgrafy) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(pro odběry podgrafů) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(pro správu nasazení) | / | --admin-port | - |
-| 8030 | Stav indexování podgrafů API | /graphql | --index-node-port | - |
-| 8040 | Metriky Prometheus | /metrics | --metrics-port | - |
+| Port | Účel                                                 | Trasy                                                | CLI Argument      | Proměnná prostředí |
+| ---- | ---------------------------------------------------- | ---------------------------------------------------- | ----------------- | ------------------ |
+| 8000 | GraphQL HTTP server<br />(pro dotazy podgrafy) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                  |
+| 8001 | GraphQL WS<br />(pro odběry podgrafů)          | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                  |
+| 8020 | JSON-RPC<br />(pro správu nasazení)            | /                                                    | --admin-port      | -                  |
+| 8030 | Stav indexování podgrafů API                         | /graphql                                             | --index-node-port | -                  |
+| 8040 | Metriky Prometheus                                   | /metrics                                             | --metrics-port    | -                  |
 
 #### Služba Indexer
 
-| Port | Účel | Trasy | CLI Argument | Proměnná prostředí |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server<br />(pro placené dotazy na podgrafy) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Metriky Prometheus | /metrics | --metrics-port | - |
+| Port | Účel                                                            | Trasy                                                                   | CLI Argument   | Proměnná prostředí     |
+| ---- | --------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(pro placené dotazy na podgrafy) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Metriky Prometheus                                              | /metrics                                                                | --metrics-port | -                      |
 
 #### Agent indexátoru
 

From 9ff3b730113d2041b3c26f1e9aee8aab70ae1d93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:16 -0500
Subject: [PATCH 0208/3820] New translations indexing.mdx (German)

---
 website/pages/de/network/indexing.mdx | 32 +++++++++++++--------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/de/network/indexing.mdx b/website/pages/de/network/indexing.mdx
index c620276a90e7..3b704381d0f0 100644
--- a/website/pages/de/network/indexing.mdx
+++ b/website/pages/de/network/indexing.mdx
@@ -113,11 +113,11 @@ Indexers may differentiate themselves by applying advanced techniques for making
 - **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
 
 | Konfiguration | Postgres<br />(CPUs) | Postgres<br />(Speicher in GB) | Postgres<br />(Festplatte in TB) | VMs<br />(CPUs) | VMs<br />(Speicher in GB) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Klein | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Mittel | 16 | 64 | 2 | 32 | 64 |
-| Groß | 72 | 468 | 3.5 | 48 | 184 |
+| ------------- |:--------------------------:|:------------------------------------:|:--------------------------------------:|:---------------------:|:-------------------------------:|
+| Klein         |             4              |                  8                   |                   1                    |           4           |               16                |
+| Standard      |             8              |                  30                  |                   1                    |          12           |               48                |
+| Mittel        |             16             |                  64                  |                   2                    |          32           |               64                |
+| Groß          |             72             |                 468                  |                  3.5                   |          48           |               184               |
 
 ### What are some basic security precautions an Indexer should take?
 
@@ -149,20 +149,20 @@ Note: To support agile scaling, it is recommended that query and indexing concer
 
 #### Der Graph-Knoten
 
-| Port | Zweck | Routen | CLI-Argument | Umgebungsvariable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP-Server<br />(für Subgraf-Abfragen) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(für Subgraf-Abonnements) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(zum Verwalten von Deployments) | / | --admin-port | - |
-| 8030 | Subgraf-Indizierungsstatus-API | /graphql | --index-node-port | - |
-| 8040 | Prometheus-Metriken | /metrics | --metrics-port | - |
+| Port | Zweck                                                 | Routen                                               | CLI-Argument      | Umgebungsvariable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | ----------------- |
+| 8000 | GraphQL HTTP-Server<br />(für Subgraf-Abfragen) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                 |
+| 8001 | GraphQL WS<br />(für Subgraf-Abonnements)       | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                 |
+| 8020 | JSON-RPC<br />(zum Verwalten von Deployments)   | /                                                    | --admin-port      | -                 |
+| 8030 | Subgraf-Indizierungsstatus-API                        | /graphql                                             | --index-node-port | -                 |
+| 8040 | Prometheus-Metriken                                   | /metrics                                             | --metrics-port    | -                 |
 
 #### Indexer Service
 
-| Port | Zweck | Routen | CLI-Argument | Umgebungsvariable |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL-HTTP-Server<br />(für kostenpflichtige Subgraf-Abfragen) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus-Metriken | /metrics | --metrics-port | - |
+| Port | Zweck                                                                  | Routen                                                                  | CLI-Argument   | Umgebungsvariable      |
+| ---- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL-HTTP-Server<br />(für kostenpflichtige Subgraf-Abfragen) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus-Metriken                                                    | /metrics                                                                | --metrics-port | -                      |
 
 #### Indexer Agent
 

From 7a7491b30a14034ab75c0d085f890e7b7bd96c8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:24 -0500
Subject: [PATCH 0209/3820] New translations indexing.mdx (Italian)

---
 website/pages/it/network/indexing.mdx | 34 +++++++++++++--------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/it/network/indexing.mdx b/website/pages/it/network/indexing.mdx
index 3b449dc021fa..183041694bb7 100644
--- a/website/pages/it/network/indexing.mdx
+++ b/website/pages/it/network/indexing.mdx
@@ -112,12 +112,12 @@ Gli Indexer possono differenziarsi applicando tecniche avanzate per prendere dec
 - **Medio** - Indexer di produzione che supporta 100 subgraph e 200-500 richieste al secondo.
 - **Grande** - È pronto a indicizzare tutti i subgraph attualmente utilizzati e a servire le richieste per il relativo traffico.
 
-| Setup | Postgres<br />(CPUs) | Postgres<br />(memoria in GBs) | Postgres<br />(disco in TBs) | VMs<br />(CPUs) | VMs<br />(memoria in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Piccolo | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medio | 16 | 64 | 2 | 32 | 64 |
-| Grande | 72 | 468 | 3.5 | 48 | 184 |
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memoria in GBs) | Postgres<br />(disco in TBs) | VMs<br />(CPUs) | VMs<br />(memoria in GBs) |
+| -------- |:--------------------------:|:------------------------------------:|:----------------------------------:|:---------------------:|:-------------------------------:|
+| Piccolo  |             4              |                  8                   |                 1                  |           4           |               16                |
+| Standard |             8              |                  30                  |                 1                  |          12           |               48                |
+| Medio    |             16             |                  64                  |                 2                  |          32           |               64                |
+| Grande   |             72             |                 468                  |                3.5                 |          48           |               184               |
 
 ### Quali sono le precauzioni di base per la sicurezza che un Indexer dovrebbe adottare?
 
@@ -149,20 +149,20 @@ Nota: Per supportare una scalabilità agile, si consiglia di separare le attivit
 
 #### Graph Node
 
-| Porta | Obiettivo | Routes | Argomento CLI | Variabile d'ambiente |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(per le query di subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(per le sottoscrizioni ai subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(per la gestione dei deployment) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Metriche di Prometheus | /metrics | --metrics-port | - |
+| Porta | Obiettivo                                                 | Routes                                               | Argomento CLI     | Variabile d'ambiente |
+| ----- | --------------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000  | GraphQL HTTP server<br />(per le query di subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001  | GraphQL WS<br />(per le sottoscrizioni ai subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020  | JSON-RPC<br />(per la gestione dei deployment)      | /                                                    | --admin-port      | -                    |
+| 8030  | Subgraph indexing status API                              | /graphql                                             | --index-node-port | -                    |
+| 8040  | Metriche di Prometheus                                    | /metrics                                             | --metrics-port    | -                    |
 
 #### Servizio Indexer
 
-| Porta | Obiettivo | Routes | Argomento CLI | Variabile d'ambiente |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server<br />(per le query di subgraph a pagamento) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Metriche di Prometheus | /metrics | --metrics-port | - |
+| Porta | Obiettivo                                                             | Routes                                                                  | Argomento CLI  | Variabile d'ambiente   |
+| ----- | --------------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600  | GraphQL HTTP server<br />(per le query di subgraph a pagamento) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300  | Metriche di Prometheus                                                | /metrics                                                                | --metrics-port | -                      |
 
 #### Indexer Agent
 

From d8f95ad84a26af56f2c209c205925a386109c94d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:26 -0500
Subject: [PATCH 0210/3820] New translations indexing.mdx (Japanese)

---
 website/pages/ja/network/indexing.mdx | 38 +++++++++++++--------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/website/pages/ja/network/indexing.mdx b/website/pages/ja/network/indexing.mdx
index 54d5a7c19f23..a1202e884ecc 100644
--- a/website/pages/ja/network/indexing.mdx
+++ b/website/pages/ja/network/indexing.mdx
@@ -112,12 +112,12 @@ Use Etherscan to call `getRewards()`:
 - **Medium** - 100 個のサブグラフと 1 秒あたり 200 ～ 500 のリクエストをサポートするプロダクションインデクサー
 - **Large** - 現在使用されているすべてのサブグラフのインデックスを作成し、関連するトラフィックのリクエストに対応します
 
-| Setup | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Small | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 | 184 |
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- |:--------------------------:|:-----------------------------------:|:---------------------------------:|:---------------------:|:------------------------------:|
+| Small    |             4              |                  8                  |                 1                 |           4           |               16               |
+| Standard |             8              |                 30                  |                 1                 |          12           |               48               |
+| Medium   |             16             |                 64                  |                 2                 |          32           |               64               |
+| Large    |             72             |                 468                 |                3.5                |          48           |              184               |
 
 ### インデクサーが取るべきセキュリティ対策は？
 
@@ -149,20 +149,20 @@ Use Etherscan to call `getRewards()`:
 
 #### グラフノード
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> /subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS <br /> (for subgraph subscriptions) | /subgraphs/id/... <br /> /subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC <br /> (for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                                 | Routes                                                 | CLI Argument      | Environment Variable |
+| ---- | ------------------------------------------------------- | ------------------------------------------------------ | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> /subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS <br /> (for subgraph subscriptions)    | /subgraphs/id/... <br /> /subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC <br /> (for managing deployments)        | /                                                      | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                            | /graphql                                               | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                      | /metrics                                               | --metrics-port    | -                    |
 
 #### Indexer Service
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server <br /> (for paid subgraph queries) | /subgraphs/id/... <br /> /status <br /> /channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                                      | Routes                                                                      | CLI Argument   | Environment Variable   |
+| ---- | ------------------------------------------------------------ | --------------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP server <br /> (for paid subgraph queries) | /subgraphs/id/... <br /> /status <br /> /channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                           | /metrics                                                                    | --metrics-port | -                      |
 
 #### Indexer Agent
 
@@ -730,10 +730,10 @@ default => 0.1 * $SYSTEM_LOAD;
 
 上記のモデルを使用したクエリのコスト計算の例:
 
-| クエリ                                                                       | 価格    |
+| クエリ                                                                          | 価格      |
 | ---------------------------------------------------------------------------- | ------- |
 | &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
-| &#123; トークン &#123; シンボル &#125; &#125;                                | 0.1 GRT |
+| &#123; トークン &#123; シンボル &#125; &#125;                                        | 0.1 GRT |
 | &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### コストモデルの適用

From 313a9fe02bab876f7d2b1121d3a3bb3ac6bc43a2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:28 -0500
Subject: [PATCH 0211/3820] New translations indexing.mdx (Korean)

---
 website/pages/ko/network/indexing.mdx | 34 +++++++++++++--------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/ko/network/indexing.mdx b/website/pages/ko/network/indexing.mdx
index a6844c2da009..0eb017b5be3f 100644
--- a/website/pages/ko/network/indexing.mdx
+++ b/website/pages/ko/network/indexing.mdx
@@ -112,12 +112,12 @@ Indexers may differentiate themselves by applying advanced techniques for making
 - **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
 - **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
 
-| Setup | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Small | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 | 184 |
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- |:--------------------------:|:-----------------------------------:|:---------------------------------:|:---------------------:|:------------------------------:|
+| Small    |             4              |                  8                  |                 1                 |           4           |               16               |
+| Standard |             8              |                 30                  |                 1                 |          12           |               48               |
+| Medium   |             16             |                 64                  |                 2                 |          32           |               64               |
+| Large    |             72             |                 468                 |                3.5                |          48           |              184               |
 
 ### What are some basic security precautions an Indexer should take?
 
@@ -149,20 +149,20 @@ Note: To support agile scaling, it is recommended that query and indexing concer
 
 #### Graph Node
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(for subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                               | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                          | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                    | /metrics                                             | --metrics-port    | -                    |
 
 #### Indexer Service
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                                    | Routes                                                                  | CLI Argument   | Environment Variable   |
+| ---- | ---------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                         | /metrics                                                                | --metrics-port | -                      |
 
 #### Indexer Agent
 

From e558b030131c2a2cac462c64eee000ca052fd0e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:29 -0500
Subject: [PATCH 0212/3820] New translations indexing.mdx (Dutch)

---
 website/pages/nl/network/indexing.mdx | 34 +++++++++++++--------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/nl/network/indexing.mdx b/website/pages/nl/network/indexing.mdx
index ee65031735f6..40c0fc8f131e 100644
--- a/website/pages/nl/network/indexing.mdx
+++ b/website/pages/nl/network/indexing.mdx
@@ -112,12 +112,12 @@ Indexeerders kunnen zich onderscheiden door geavanceerde technieken toe te passe
 - **Middel** - Indexer die 100 subgraphs ondersteund en 200-500 query's per seconde verwerkt.
 - **Groot** - Voorbereid om alle momenteel gebruikte subgraphs te indexeren en de bijbehorende query's te verwerken.
 
-| Setup | Postgres<br />(CPUs) | Postgres<br />(Geheugen in GBs) | Postgres<br />(schijf in TBs) | VMs<br />(CPUs) | VMs<br />(geheugen in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Klein | 4 | 8 | 1 | 4 | 16 |
-| Standaard | 8 | 30 | 1 | 12 | 48 |
-| Middel | 16 | 64 | 2 | 32 | 64 |
-| Groot | 72 | 468 | 3.5 | 48 | 184 |
+| Setup     | Postgres<br />(CPUs) | Postgres<br />(Geheugen in GBs) | Postgres<br />(schijf in TBs) | VMs<br />(CPUs) | VMs<br />(geheugen in GBs) |
+| --------- |:--------------------------:|:-------------------------------------:|:-----------------------------------:|:---------------------:|:--------------------------------:|
+| Klein     |             4              |                   8                   |                  1                  |           4           |                16                |
+| Standaard |             8              |                  30                   |                  1                  |          12           |                48                |
+| Middel    |             16             |                  64                   |                  2                  |          32           |                64                |
+| Groot     |             72             |                  468                  |                 3.5                 |          48           |               184                |
 
 ### Wat zijn enkele basisveiligheidsmaatregelen die een Indexeerder moet nemen?
 
@@ -149,20 +149,20 @@ Tip: Om wendbare schaalvergroting te ondersteunen, wordt aanbevolen om Query- en
 
 #### Graph Node
 
-| Poort | Doel | Routes | CLI-Argument | Omgevingsvariabele |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(voor subgraph query's) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(voor subgraph abonnementen) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(voor het beheren van implementaties) | / | --admin-port | - |
-| 8030 | Subgraph indexeerstatus API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Poort | Doel                                                      | Routes                                               | CLI-Argument      | Omgevingsvariabele |
+| ----- | --------------------------------------------------------- | ---------------------------------------------------- | ----------------- | ------------------ |
+| 8000  | GraphQL HTTP server<br />(voor subgraph query's)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                  |
+| 8001  | GraphQL WS<br />(voor subgraph abonnementen)        | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                  |
+| 8020  | JSON-RPC<br />(voor het beheren van implementaties) | /                                                    | --admin-port      | -                  |
+| 8030  | Subgraph indexeerstatus API                               | /graphql                                             | --index-node-port | -                  |
+| 8040  | Prometheus metrics                                        | /metrics                                             | --metrics-port    | -                  |
 
 #### Indexer Service
 
-| Poort | Doel | Routes | CLI-Argument | Omgevingsvariabele |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server<br />(voor betaalde subgraph query's) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | --metrics-port | - |
+| Poort | Doel                                                            | Routes                                                                  | CLI-Argument   | Omgevingsvariabele     |
+| ----- | --------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600  | GraphQL HTTP server<br />(voor betaalde subgraph query's) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300  | Prometheus metrics                                              | /metrics                                                                | --metrics-port | -                      |
 
 #### Indexer Agent
 

From 4a97804ab233129929d1853bc0674b959c237ffc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:30 -0500
Subject: [PATCH 0213/3820] New translations indexing.mdx (Polish)

---
 website/pages/pl/network/indexing.mdx | 34 +++++++++++++--------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/pl/network/indexing.mdx b/website/pages/pl/network/indexing.mdx
index a6844c2da009..0eb017b5be3f 100644
--- a/website/pages/pl/network/indexing.mdx
+++ b/website/pages/pl/network/indexing.mdx
@@ -112,12 +112,12 @@ Indexers may differentiate themselves by applying advanced techniques for making
 - **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
 - **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
 
-| Setup | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Small | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 | 184 |
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- |:--------------------------:|:-----------------------------------:|:---------------------------------:|:---------------------:|:------------------------------:|
+| Small    |             4              |                  8                  |                 1                 |           4           |               16               |
+| Standard |             8              |                 30                  |                 1                 |          12           |               48               |
+| Medium   |             16             |                 64                  |                 2                 |          32           |               64               |
+| Large    |             72             |                 468                 |                3.5                |          48           |              184               |
 
 ### What are some basic security precautions an Indexer should take?
 
@@ -149,20 +149,20 @@ Note: To support agile scaling, it is recommended that query and indexing concer
 
 #### Graph Node
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(for subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                               | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                          | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                    | /metrics                                             | --metrics-port    | -                    |
 
 #### Indexer Service
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                                    | Routes                                                                  | CLI Argument   | Environment Variable   |
+| ---- | ---------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                         | /metrics                                                                | --metrics-port | -                      |
 
 #### Indexer Agent
 

From 4a53222f0f3fd15dbcc423e2d67979f844ae6a3a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:37 -0500
Subject: [PATCH 0214/3820] New translations indexing.mdx (Portuguese)

---
 website/pages/pt/network/indexing.mdx | 34 +++++++++++++--------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/pt/network/indexing.mdx b/website/pages/pt/network/indexing.mdx
index 00392d71f392..36e588e4237e 100644
--- a/website/pages/pt/network/indexing.mdx
+++ b/website/pages/pt/network/indexing.mdx
@@ -112,12 +112,12 @@ Os Indexadores podem se diferenciar ao aplicar técnicas avançadas para decidir
 - **Médio** — Indexador de Produção. Apoia 100 subgraphs e 200 – 500 pedidos por segundo.
 - **Grande** — Preparado para indexar todos os subgraphs usados atualmente e servir pedidos para o tráfego relacionado.
 
-| Setup | Postgres<br />(CPUs) | Postgres<br />(memória em GBs) | Postgres<br />(disco em TBs) | VMs<br />(CPUs) | VMs<br />(memória em GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Pequeno | 4 | 8 | 1 | 4 | 16 |
-| Normal | 8 | 30 | 1 | 12 | 48 |
-| Médio | 16 | 64 | 2 | 32 | 64 |
-| Grande | 72 | 468 | 3.5 | 48 | 184 |
+| Setup   | Postgres<br />(CPUs) | Postgres<br />(memória em GBs) | Postgres<br />(disco em TBs) | VMs<br />(CPUs) | VMs<br />(memória em GBs) |
+| ------- |:--------------------------:|:------------------------------------:|:----------------------------------:|:---------------------:|:-------------------------------:|
+| Pequeno |             4              |                  8                   |                 1                  |           4           |               16                |
+| Normal  |             8              |                  30                  |                 1                  |          12           |               48                |
+| Médio   |             16             |                  64                  |                 2                  |          32           |               64                |
+| Grande  |             72             |                 468                  |                3.5                 |          48           |               184               |
 
 ### Há alguma precaução básica de segurança que um Indexador deve tomar?
 
@@ -149,20 +149,20 @@ Nota: Para apoiar o escalamento ágil, recomendamos que assuntos de consulta e i
 
 #### Graph Node
 
-| Porta | Propósito | Rotas | Argumento CLI | Variável de Ambiente |
-| --- | --- | --- | --- | --- |
-| 8000 | Servidor HTTP GraphQL<br />(para consultas de subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | WS GraphQL<br />(para inscrições a subgraphs) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(para gerir lançamentos) | / | --admin-port | - |
-| 8030 | API de status de indexamento do subgraph | /graphql | --index-node-port | - |
-| 8040 | Métricas Prometheus | /metrics | --metrics-port | - |
+| Porta | Propósito                                                     | Rotas                                                | Argumento CLI     | Variável de Ambiente |
+| ----- | ------------------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000  | Servidor HTTP GraphQL<br />(para consultas de subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001  | WS GraphQL<br />(para inscrições a subgraphs)           | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020  | JSON-RPC<br />(para gerir lançamentos)                  | /                                                    | --admin-port      | -                    |
+| 8030  | API de status de indexamento do subgraph                      | /graphql                                             | --index-node-port | -                    |
+| 8040  | Métricas Prometheus                                           | /metrics                                             | --metrics-port    | -                    |
 
 #### Serviço Indexador
 
-| Porta | Propósito | Rotas | Argumento CLI | Variável de Ambiente |
-| --- | --- | --- | --- | --- |
-| 7600 | Servidor HTTP GraphQL<br />(para consultas de subgraph pagas) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | --metrics-port | - |
+| Porta | Propósito                                                           | Rotas                                                                   | Argumento CLI  | Variável de Ambiente   |
+| ----- | ------------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600  | Servidor HTTP GraphQL<br />(para consultas de subgraph pagas) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300  | Prometheus metrics                                                  | /metrics                                                                | --metrics-port | -                      |
 
 #### Agente Indexador
 

From 3df110900458a4f2640ff881bca2bca521cf205c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:39 -0500
Subject: [PATCH 0215/3820] New translations indexing.mdx (Swedish)

---
 website/pages/sv/network/indexing.mdx | 32 +++++++++++++--------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/sv/network/indexing.mdx b/website/pages/sv/network/indexing.mdx
index c1916a3e9a8e..c249ed8f3404 100644
--- a/website/pages/sv/network/indexing.mdx
+++ b/website/pages/sv/network/indexing.mdx
@@ -113,11 +113,11 @@ Indexers kan skilja sig åt genom att tillämpa avancerade tekniker för att fat
 - **Stor** - Förberedd för att indexera alla för närvarande använda subgrafer och att ta emot förfrågningar för relaterad trafik.
 
 | Konfiguration | Postgres<br />(CPU:er) | Postgres<br />(minne i GB) | Postgres<br />(disk i TB) | VM:er<br />(CPU:er) | VM:er<br />(minne i GB) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Liten | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Stor | 72 | 468 | 3,5 | 48 | 184 |
+| ------------- |:----------------------------:|:--------------------------------:|:-------------------------------:|:-------------------------:|:-----------------------------:|
+| Liten         |              4               |                8                 |                1                |             4             |              16               |
+| Standard      |              8               |                30                |                1                |            12             |              48               |
+| Medium        |              16              |                64                |                2                |            32             |              64               |
+| Stor          |              72              |               468                |               3,5               |            48             |              184              |
 
 ### Vilka grundläggande säkerhetsåtgärder bör en Indexer vidta?
 
@@ -149,20 +149,20 @@ Observera: För att stödja smidig skalning rekommenderas det att fråge- och in
 
 #### Graf Node
 
-| Port | Syfte | Vägar | CLI-argument | Miljövariabel |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP-server<br />(för subgraf-förfrågningar) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(för subgraf-prenumerationer) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(för hantering av distributioner) | / | --admin-port | - |
-| 8030 | Subgrafindexeringsstatus-API | /graphql | --index-node-port | - |
-| 8040 | Prometheus-metrar | /metrics | --metrics-port | - |
+| Port | Syfte                                                      | Vägar                                                | CLI-argument      | Miljövariabel |
+| ---- | ---------------------------------------------------------- | ---------------------------------------------------- | ----------------- | ------------- |
+| 8000 | GraphQL HTTP-server<br />(för subgraf-förfrågningar) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -             |
+| 8001 | GraphQL WS<br />(för subgraf-prenumerationer)        | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -             |
+| 8020 | JSON-RPC<br />(för hantering av distributioner)      | /                                                    | --admin-port      | -             |
+| 8030 | Subgrafindexeringsstatus-API                               | /graphql                                             | --index-node-port | -             |
+| 8040 | Prometheus-metrar                                          | /metrics                                             | --metrics-port    | -             |
 
 #### Indexertjänst
 
-| Port | Syfte | Vägar | CLI-argument | Miljövariabel |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP-server<br />(för betalda subgraf-förfrågningar) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus-metrar | /metrics | --metrics-port | - |
+| Port | Syfte                                                              | Vägar                                                                   | CLI-argument   | Miljövariabel          |
+| ---- | ------------------------------------------------------------------ | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP-server<br />(för betalda subgraf-förfrågningar) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus-metrar                                                  | /metrics                                                                | --metrics-port | -                      |
 
 #### Indexeragent
 

From 3427b1de41e4a5bd8c6241224392d1c8699c660d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:41 -0500
Subject: [PATCH 0216/3820] New translations indexing.mdx (Ukrainian)

---
 website/pages/uk/network/indexing.mdx | 38 +++++++++++++--------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/website/pages/uk/network/indexing.mdx b/website/pages/uk/network/indexing.mdx
index d9f39f72fe02..8c30f75568e8 100644
--- a/website/pages/uk/network/indexing.mdx
+++ b/website/pages/uk/network/indexing.mdx
@@ -113,11 +113,11 @@ Query fees are collected by the gateway and distributed to indexers according to
 - **Large** - підготовлений для індексації всіх підграфів, що використовуються наразі, і обслуговування запитів на відповідний трафік.
 
 | Налаштування | Postgres<br />(CPU) | Postgres<br />(пам'ять в GB) | Postgres<br />(диск у ТБ) | VMs<br />(Центральні CPU) | VMs<br />(пам'ять у ГБ) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Small | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 | 184 |
+| ------------ |:-------------------------:|:----------------------------------:|:-------------------------------:|:-------------------------------:|:-----------------------------:|
+| Small        |             4             |                 8                  |                1                |                4                |              16               |
+| Standard     |             8             |                 30                 |                1                |               12                |              48               |
+| Medium       |            16             |                 64                 |                2                |               32                |              64               |
+| Large        |            72             |                468                 |               3.5               |               48                |              184              |
 
 ### Яких основних заходів безпеки повинен дотримуватися індексатор?
 
@@ -149,26 +149,26 @@ Query fees are collected by the gateway and distributed to indexers according to
 
 #### Graph Node
 
-| Порт | Призначення | Розташування | Аргумент CLI | Перемінна оточення |
-| --- | --- | --- | --- | --- |
-| 8000 | HTTP-сервер GraphQL<br />(для запитів до підграфів) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-порт | - |
-| 8001 | GraphQL WS<br />(для підписок на підграфи) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(для керування розгортаннями) | / | --admin-port | - |
-| 8030 | API стану індексації підграфів | /graphql | --index-node-port | - |
-| 8040 | Метрики Prometheus | /metrics | --metrics-port | - |
+| Порт | Призначення                                               | Розташування                                         | Аргумент CLI      | Перемінна оточення |
+| ---- | --------------------------------------------------------- | ---------------------------------------------------- | ----------------- | ------------------ |
+| 8000 | HTTP-сервер GraphQL<br />(для запитів до підграфів) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-порт       | -                  |
+| 8001 | GraphQL WS<br />(для підписок на підграфи)          | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                  |
+| 8020 | JSON-RPC<br />(для керування розгортаннями)         | /                                                    | --admin-port      | -                  |
+| 8030 | API стану індексації підграфів                            | /graphql                                             | --index-node-port | -                  |
+| 8040 | Метрики Prometheus                                        | /metrics                                             | --metrics-port    | -                  |
 
 #### Служба індексації
 
-| Порт | Призначення | Розташування | Аргумент CLI | Перемінна оточення |
-| --- | --- | --- | --- | --- |
-| 7600 | HTTP-сервер GraphQL<br />(для платних запитів до підграфів) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Метрики Prometheus | /metrics | --metrics-port | - |
+| Порт | Призначення                                                       | Розташування                                                            | Аргумент CLI   | Перемінна оточення     |
+| ---- | ----------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | HTTP-сервер GraphQL<br />(для платних запитів до підграфів) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Метрики Prometheus                                                | /metrics                                                                | --metrics-port | -                      |
 
 #### Агент індексації
 
-| Порт | Призначення | Розташування | Аргумент CLI | Перемінна оточення |
-| --- | --- | --- | --- | --- |
-| 8000 | API для керування індексатором | / | --indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+| Порт | Призначення                    | Розташування | Аргумент CLI              | Перемінна оточення                      |
+| ---- | ------------------------------ | ------------ | ------------------------- | --------------------------------------- |
+| 8000 | API для керування індексатором | /            | --indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
 
 ### Налаштування серверної інфраструктури з використанням Terraform на Google Cloud
 

From 72992c86af557e907eba1abdfb43edb2195f0f16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:46 -0500
Subject: [PATCH 0217/3820] New translations indexing.mdx (Chinese Simplified)

---
 website/pages/zh/network/indexing.mdx | 40 +++++++++++++--------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/website/pages/zh/network/indexing.mdx b/website/pages/zh/network/indexing.mdx
index 9daffa4ac7d0..9451572c8438 100644
--- a/website/pages/zh/network/indexing.mdx
+++ b/website/pages/zh/network/indexing.mdx
@@ -113,11 +113,11 @@ Query fees are collected by the gateway and distributed to indexers according to
 - **大型** -准备对当前使用的所有子图进行索引，并为相关流量的请求提供服务。
 
 | 设置 | (CPU 数量) | (内存 GB) | (硬盘 TB) | (CPU 数量) | (内存 GB) |
-| ---- | :--------: | :-------: | :-------: | :--------: | :-------: |
-| 小型 |     4      |     8     |     1     |     4      |    16     |
-| 标准 |     8      |    30     |     1     |     12     |    48     |
-| 中型 |     16     |    64     |     2     |     32     |    64     |
-| 大型 |     72     |    468    |    3.5    |     48     |    184    |
+| -- |:--------:|:-------:|:-------:|:--------:|:-------:|
+| 小型 |    4     |    8    |    1    |    4     |   16    |
+| 标准 |    8     |   30    |    1    |    12    |   48    |
+| 中型 |    16    |   64    |    2    |    32    |   64    |
+| 大型 |    72    |   468   |   3.5   |    48    |   184   |
 
 ### 索引人应该采取哪些基本的安全防范措施？
 
@@ -149,26 +149,26 @@ Query fees are collected by the gateway and distributed to indexers according to
 
 #### Graph 节点
 
-| 端口 | 用途 | 路径 | CLI 参数 | 环境 变量 |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP 服务 <br />（用于子图查询） | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS <br />（用于子图订阅） | /subgraphs/id/... <br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC <br />（用于管理部署） | / | --admin-port | - |
-| 8030 | 子图索引状态 API | /graphql | --index-node-port | - |
-| 8040 | Prometheus 指标 | /metrics | --metrics-port | - |
+| 端口   | 用途                                   | 路径                                                                  | CLI 参数            | 环境 变量 |
+| ---- | ------------------------------------ | ------------------------------------------------------------------- | ----------------- | ----- |
+| 8000 | GraphQL HTTP 服务 <br />（用于子图查询） | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | --http-port       | -     |
+| 8001 | GraphQL WS <br />（用于子图订阅）      | /subgraphs/id/... <br />/subgraphs/name/.../...               | --ws-port         | -     |
+| 8020 | JSON-RPC <br />（用于管理部署）        | /                                                                   | --admin-port      | -     |
+| 8030 | 子图索引状态 API                           | /graphql                                                            | --index-node-port | -     |
+| 8040 | Prometheus 指标                        | /metrics                                                            | --metrics-port    | -     |
 
 #### 索引人服务
 
-| 端口 | 用途 | 路径 | CLI 参数 | 环境 变量 |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP 服务器<br /> （用于付费子图查询） | /subgraphs/id/... <br /> /status <br /> /channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus 指标 | /metrics | --metrics-port | - |
+| 端口   | 用途                                      | 路径                                                                          | CLI 参数         | 环境 变量                  |
+| ---- | --------------------------------------- | --------------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP 服务器<br /> （用于付费子图查询） | /subgraphs/id/... <br /> /status <br /> /channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus 指标                           | /metrics                                                                    | --metrics-port | -                      |
 
 #### 索引人代理
 
-| 端口 | 用途           | 路径 | CLI 参数                  | 环境 变量                               |
-| ---- | -------------- | ---- | ------------------------- | --------------------------------------- |
-| 8000 | 索引人管理 API | /    | --indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+| 端口   | 用途        | 路径 | CLI 参数                    | 环境 变量                                   |
+| ---- | --------- | -- | ------------------------- | --------------------------------------- |
+| 8000 | 索引人管理 API | /  | --indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
 
 ### 在谷歌云上使用 Terraform 建立服务器基础设施
 
@@ -731,7 +731,7 @@ default => 0.1 * $SYSTEM_LOAD;
 
 使用上述模型的查询成本计算示例：
 
-| 询问                                                                         | 价格    |
+| 询问                                                                           | 价格      |
 | ---------------------------------------------------------------------------- | ------- |
 | &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
 | &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |

From 27d0e2cc8ca5f25363e54d88773153e612c3a665 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:48 -0500
Subject: [PATCH 0218/3820] New translations indexing.mdx (Urdu (Pakistan))

---
 website/pages/ur/network/indexing.mdx | 34 +++++++++++++--------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/ur/network/indexing.mdx b/website/pages/ur/network/indexing.mdx
index a115bb4c34a3..59933c810c92 100644
--- a/website/pages/ur/network/indexing.mdx
+++ b/website/pages/ur/network/indexing.mdx
@@ -112,12 +112,12 @@ query indexerAllocations {
 - **درمیانہ** - پروڈکشن انڈیکسر 100 سب گراف اور 200-500 درخواستیں فی سیکنڈ کو اٹھا سکتا ہے.
 - **بڑا** - تمام فی الحال زیر استعمال سب گرافس کو انڈیکس کرنے اور متعلقہ ٹریفک کے لیے درخواستیں پیش کرنے کے لیے تیار ہے.
 
-| سیٹ اپ | Postgres<br />(CPUs) | Postgres<br />(GBs میں میموری) | Postgres<br />(TBs میں ڈسک) | VMs<br />(CPUs) | VMs<br />(GBs میں میموری) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| چھوٹا | 4 | 8 | 1 | 4 | 16 |
-| معیاری | 8 | 30 | 1 | 12 | 48 |
-| درمیانہ | 16 | 64 | 2 | 32 | 64 |
-| بڑا | 72 | 468 | 3.5 | 48 | 184 |
+| سیٹ اپ  | Postgres<br />(CPUs) | Postgres<br />(GBs میں میموری) | Postgres<br />(TBs میں ڈسک) | VMs<br />(CPUs) | VMs<br />(GBs میں میموری) |
+| ------- |:--------------------------:|:------------------------------------:|:---------------------------------:|:---------------------:|:-------------------------------:|
+| چھوٹا   |             4              |                  8                   |                 1                 |           4           |               16                |
+| معیاری  |             8              |                  30                  |                 1                 |          12           |               48                |
+| درمیانہ |             16             |                  64                  |                 2                 |          32           |               64                |
+| بڑا     |             72             |                 468                  |                3.5                |          48           |               184               |
 
 ### وہ کون سی چند بنیادی حفاظتی تدابیر ہیں جو ایک انڈیکسر کو اختیار کرنی چاہیے؟
 
@@ -149,20 +149,20 @@ query indexerAllocations {
 
 #### گراف نوڈ
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(سب گراف کی کیوریز کے لیے) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(سب گراف سبسکرپشنز کے لیے) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(تعیناتیوں کے انتظام کے لیے) | / | --admin-port | - |
-| 8030 | سب گراف انڈیکسنگ اسٹیٹس API | /graphql | --index-node-port | - |
-| 8040 | Prometheus میٹرکس | /metrics | --metrics-port | - |
+| Port | Purpose                                                   | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | --------------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(سب گراف کی کیوریز کے لیے) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(سب گراف سبسکرپشنز کے لیے)          | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(تعیناتیوں کے انتظام کے لیے)          | /                                                    | --admin-port      | -                    |
+| 8030 | سب گراف انڈیکسنگ اسٹیٹس API                               | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus میٹرکس                                         | /metrics                                             | --metrics-port    | -                    |
 
 #### انڈیکسر سروس
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server<br />(ادا شدہ سب گراف کی کیوریز کے لیے) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus میٹرکس | /metrics | --metrics-port | - |
+| Port | Purpose                                                           | Routes                                                                  | CLI Argument   | Environment Variable   |
+| ---- | ----------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(ادا شدہ سب گراف کی کیوریز کے لیے) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus میٹرکس                                                 | /metrics                                                                | --metrics-port | -                      |
 
 #### انڈیکسر ایجنٹ
 

From 853994d1f2a98d37ce7d796f16a8150ce1476ad6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:49 -0500
Subject: [PATCH 0219/3820] New translations indexing.mdx (Vietnamese)

---
 website/pages/vi/network/indexing.mdx | 34 +++++++++++++--------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/vi/network/indexing.mdx b/website/pages/vi/network/indexing.mdx
index 8c5ac85fb98e..b19e9f99a983 100644
--- a/website/pages/vi/network/indexing.mdx
+++ b/website/pages/vi/network/indexing.mdx
@@ -112,12 +112,12 @@ Indexer có thể tự phân biệt bản thân bằng cách áp dụng các k
 - **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
 - **Lớn** - Được chuẩn bị để index tất cả các subgraph hiện đang được sử dụng và phục vụ các yêu cầu cho lưu lượng truy cập liên quan.
 
-| Cài đặt | Postgres<br />(CPUs) | Postgres<br />(bộ nhớ tính bằng GB) | Postgres<br />(đĩa tính bằng TB) | VMs<br />(CPUs) | VMs<br />(bộ nhớ tính bằng GB) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Nhỏ | 4 | 8 | 1 | 4 | 16 |
-| Tiêu chuẩn | 8 | 30 | 1 | 12 | 48 |
-| Trung bình | 16 | 64 | 2 | 32 | 64 |
-| Lớn | 72 | 468 | 3.5 | 48 | 184 |
+| Cài đặt     | Postgres<br />(CPUs) | Postgres<br />(bộ nhớ tính bằng GB) | Postgres<br />(đĩa tính bằng TB) | VMs<br />(CPUs) | VMs<br />(bộ nhớ tính bằng GB) |
+| ----------- |:--------------------------:|:-----------------------------------------:|:--------------------------------------:|:---------------------:|:------------------------------------:|
+| Nhỏ         |             4              |                     8                     |                   1                    |           4           |                  16                  |
+| Tiêu chuẩn  |             8              |                    30                     |                   1                    |          12           |                  48                  |
+| Trung bình |             16             |                    64                     |                   2                    |          32           |                  64                  |
+| Lớn         |             72             |                    468                    |                  3.5                   |          48           |                 184                  |
 
 ### What are some basic security precautions an Indexer should take?
 
@@ -149,20 +149,20 @@ Lưu ý: Để hỗ trợ mở rộng quy mô nhanh, bạn nên tách các mối
 
 #### Graph Node
 
-| Cổng | Mục đích | Tuyến | Đối số CLI | Biến môi trường |
-| --- | --- | --- | --- | --- |
-| 8000 | Máy chủ GraphQL HTTP<br />(cho các truy vấn subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(cho các đăng ký subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(để quản lý triển khai) | / | --admin-port | - |
-| 8030 | API trạng thái lập chỉ mục Subgraph | /graphql | --index-node-port | - |
-| 8040 | Số liệu Prometheus | /metrics | --metrics-port | - |
+| Cổng | Mục đích                                                    | Tuyến                                                | Đối số CLI        | Biến môi trường |
+| ---- | ----------------------------------------------------------- | ---------------------------------------------------- | ----------------- | --------------- |
+| 8000 | Máy chủ GraphQL HTTP<br />(cho các truy vấn subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -               |
+| 8001 | GraphQL WS<br />(cho các đăng ký subgraph)            | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -               |
+| 8020 | JSON-RPC<br />(để quản lý triển khai)                 | /                                                    | --admin-port      | -               |
+| 8030 | API trạng thái lập chỉ mục Subgraph                         | /graphql                                             | --index-node-port | -               |
+| 8040 | Số liệu Prometheus                                          | /metrics                                             | --metrics-port    | -               |
 
 #### Dịch vụ Indexer
 
-| Cổng | Mục đích | Tuyến | Đối số CLI | Biến môi trường |
-| --- | --- | --- | --- | --- |
-| 7600 | Máy chủ GraphQL HTTP<br />(cho các truy vấn subgraph có trả phí) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Số liệu Prometheus | /metrics | --metrics-port | - |
+| Cổng | Mục đích                                                               | Tuyến                                                                   | Đối số CLI     | Biến môi trường        |
+| ---- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | Máy chủ GraphQL HTTP<br />(cho các truy vấn subgraph có trả phí) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Số liệu Prometheus                                                     | /metrics                                                                | --metrics-port | -                      |
 
 #### Đại lý Indexer
 

From 5f6772765695ee83ed9176c510c6b485b0870754 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:51 -0500
Subject: [PATCH 0220/3820] New translations indexing.mdx (Marathi)

---
 website/pages/mr/network/indexing.mdx | 36 +++++++++++++--------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/website/pages/mr/network/indexing.mdx b/website/pages/mr/network/indexing.mdx
index e725d445b914..4f87435bda60 100644
--- a/website/pages/mr/network/indexing.mdx
+++ b/website/pages/mr/network/indexing.mdx
@@ -112,12 +112,12 @@ Once an allocation has been closed the rebates are available to be claimed by th
 - **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
 - **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
 
-| Setup | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Small | 4 | 8 | 1 | 4 | 16 |
-| मानक | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 | 184 |
+| Setup  | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| ------ |:--------------------------:|:-----------------------------------:|:---------------------------------:|:---------------------:|:------------------------------:|
+| Small  |             4              |                  8                  |                 1                 |           4           |               16               |
+| मानक   |             8              |                 30                  |                 1                 |          12           |               48               |
+| Medium |             16             |                 64                  |                 2                 |          32           |               64               |
+| Large  |             72             |                 468                 |                3.5                |          48           |              184               |
 
 ### What are some basic security precautions an Indexer should take?
 
@@ -149,20 +149,20 @@ Once an allocation has been closed the rebates are available to be claimed by th
 
 #### आलेख नोड
 
-| बंदर | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(for subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| बंदर | Purpose                                               | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                          | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                    | /metrics                                             | --metrics-port    | -                    |
 
 #### Indexer Service
 
-| बंदर | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | --metrics-port | - |
+| बंदर | Purpose                                                    | Routes                                                                  | CLI Argument   | Environment Variable   |
+| ---- | ---------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                         | /metrics                                                                | --metrics-port | -                      |
 
 #### Indexer Agent
 
@@ -623,7 +623,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 - Indexer can use the `indexer-cli` to view all queued actions
 - इंडेक्सर (किंवा इतर सॉफ्टवेअर) `indexer-cli` वापरून रांगेतील क्रिया मंजूर किंवा रद्द करू शकतात. मंजूर आणि रद्द आदेश इनपुट म्हणून अॅक्शन आयडीचा अॅरे घेतात.
 - अंमलबजावणी कर्मचारी नियमितपणे मंजूर कृतींसाठी रांगेत मतदान करतात. ते रांगेतील `मंजूर` क्रिया पकडेल, त्या कार्यान्वित करण्याचा प्रयत्न करेल आणि अंमलबजावणीच्या स्थितीनुसार `यशस्वी` किंवा `अयशस्वी< वर db मधील मूल्ये अपडेट करेल. /code>.</li>
-  <li>एखादी कृती यशस्वी झाल्यास कार्यकर्ता खात्री करेल की एक अनुक्रमणिका नियम उपस्थित आहे जो एजंटला वाटप कसे व्यवस्थापित करावे हे सांगते, एजंट <code>ऑटो` किंवा ` मध्ये असताना मॅन्युअल क्रिया करताना उपयुक्त oversight` मोड.
+<li>एखादी कृती यशस्वी झाल्यास कार्यकर्ता खात्री करेल की एक अनुक्रमणिका नियम उपस्थित आहे जो एजंटला वाटप कसे व्यवस्थापित करावे हे सांगते, एजंट <code>ऑटो` किंवा ` मध्ये असताना मॅन्युअल क्रिया करताना उपयुक्त oversight` मोड.
 - इंडेक्सर कारवाईच्या अंमलबजावणीचा इतिहास पाहण्यासाठी कृती रांगेचे निरीक्षण करू शकतो आणि आवश्यक असल्यास क्रिया आयटमची अंमलबजावणी अयशस्वी झाल्यास पुन्हा मंजूर आणि अद्यतनित करू शकतो. कृती रांग रांगेत लावलेल्या आणि केलेल्या सर्व क्रियांचा इतिहास प्रदान करते.
 
 Data model:

From 5915d9b5815988a6687c13be421e0003b33c4222 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:52 -0500
Subject: [PATCH 0221/3820] New translations indexing.mdx (Swahili)

---
 website/pages/sw/network/indexing.mdx | 34 +++++++++++++--------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/sw/network/indexing.mdx b/website/pages/sw/network/indexing.mdx
index a6844c2da009..0eb017b5be3f 100644
--- a/website/pages/sw/network/indexing.mdx
+++ b/website/pages/sw/network/indexing.mdx
@@ -112,12 +112,12 @@ Indexers may differentiate themselves by applying advanced techniques for making
 - **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
 - **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
 
-| Setup | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Small | 4 | 8 | 1 | 4 | 16 |
-| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 | 184 |
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- |:--------------------------:|:-----------------------------------:|:---------------------------------:|:---------------------:|:------------------------------:|
+| Small    |             4              |                  8                  |                 1                 |           4           |               16               |
+| Standard |             8              |                 30                  |                 1                 |          12           |               48               |
+| Medium   |             16             |                 64                  |                 2                 |          32           |               64               |
+| Large    |             72             |                 468                 |                3.5                |          48           |              184               |
 
 ### What are some basic security precautions an Indexer should take?
 
@@ -149,20 +149,20 @@ Note: To support agile scaling, it is recommended that query and indexing concer
 
 #### Graph Node
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(for subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                               | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                          | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                    | /metrics                                             | --metrics-port    | -                    |
 
 #### Indexer Service
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                                    | Routes                                                                  | CLI Argument   | Environment Variable   |
+| ---- | ---------------------------------------------------------- | ----------------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | --port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                         | /metrics                                                                | --metrics-port | -                      |
 
 #### Indexer Agent
 

From 2ff62e4c7bf56fa8987b1b7b6ea9c5899a32f57e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:06:58 -0500
Subject: [PATCH 0222/3820] New translations distributed-systems.mdx (French)

---
 .../pages/fr/querying/distributed-systems.mdx  | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/fr/querying/distributed-systems.mdx b/website/pages/fr/querying/distributed-systems.mdx
index cc52558ba647..270b55bfd86d 100644
--- a/website/pages/fr/querying/distributed-systems.mdx
+++ b/website/pages/fr/querying/distributed-systems.mdx
@@ -34,21 +34,21 @@ Le graph fournit l'API `block : { number_gte: $minBlock }`, qui garantit que la
 Nous pouvons utiliser `number_gte` pour nous assurer que le temps ne recule jamais lorsque nous interrogeons des données dans une boucle. Voici un exemple :
 
 ```javascript
-/// Met à jour la variable protocol.paused avec la dernière valeur
+/// Met à jour la variable protocol.paused avec la dernière valeur 
 /// connue dans une boucle en la récupérant en utilisant The Graph.
 async function updateProtocolPaused() {
   // Il est correct de commencer avec minBlock à 0. La requête sera servie
   // en utilisant le dernier bloc disponible. Définir minBlock à 0 revient
   // à omettre cet argument.
   let minBlock = 0
-
+  
   for (;;) {
-    // Planifie une promesse qui sera prête une fois que le prochain bloc
+    // Planifie une promesse qui sera prête une fois que le prochain bloc 
     // Ethereum sera probablement disponible.
     const nextBlock = new Promise((f) => {
       setTimeout(f, 14000)
     })
-
+ 
     const query = `
         query GetProtocol($minBlock: Int!) {
             protocol(block: { number_gte: $minBlock }  id: "0") {
@@ -60,14 +60,14 @@ async function updateProtocolPaused() {
                 }
             }
         }`
-
+    
     const variables = { minBlock }
     const response = await graphql(query, variables)
     minBlock = response._meta.block.number
-
+    
     // TODO: Faites quelque chose avec les données de réponse ici au lieu de les journaliser.
     console.log(response.protocol.paused)
-
+    
     // Dort pour attendre le prochain bloc
     await nextBlock
   }
@@ -87,9 +87,9 @@ async function getDomainNames() {
   let pages = 5
   const perPage = 1000
 
-  // La première requête obtiendra la première page de résultats et obtiendra également le
+  // La première requête obtiendra la première page de résultats et obtiendra également le 
   // hachage du bloc afin que le reste des requêtes soit cohérent avec la première.
-  const listDomainsQuery = `
+ const listDomainsQuery = `
     query ListDomains($perPage: Int!) {
         domains(first: $perPage) {
             name

From 43254646dc0645252fcd898e4ad8cf27955ce02a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:07:04 -0500
Subject: [PATCH 0223/3820] New translations querying-best-practices.mdx
 (Arabic)

---
 .../pages/ar/querying/querying-best-practices.mdx    | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/ar/querying/querying-best-practices.mdx b/website/pages/ar/querying/querying-best-practices.mdx
index 48e8dec63a28..99d7ed349b04 100644
--- a/website/pages/ar/querying/querying-best-practices.mdx
+++ b/website/pages/ar/querying/querying-best-practices.mdx
@@ -14,7 +14,7 @@ Learn the essential GraphQL language rules and best practices to optimize your s
 
 على عكس REST API ، فإن GraphQL API مبنية على مخطط يحدد الاستعلامات التي يمكن تنفيذها.
 
-على سبيل المثال ، طلب الاستعلام للحصول على توكن باستخدام استعلام `token` سيبدو كما يلي:
+على سبيل المثال ، طلب الاستعلام للحصول على توكن باستخدام استعلام ` token ` سيبدو كما يلي:
 
 ```graphql
 query GetToken($id: ID!) {
@@ -38,7 +38,7 @@ query GetToken($id: ID!) {
 
 تستخدم استعلامات GraphQL لغة GraphQL ، التي تم تحديدها في [المواصفات](https://spec.graphql.org/).
 
-يتكون استعلام `GetToken` أعلاه من أجزاء متعددة للغة (تم استبدالها أدناه بـ placeholders `[...]`):
+يتكون استعلام ` GetToken ` أعلاه من أجزاء متعددة للغة (تم استبدالها أدناه بـ placeholders ` [...] `):
 
 ```graphql
 query [operationName]([variableName]: [variableType]) {
@@ -52,8 +52,8 @@ query [operationName]([variableName]: [variableType]) {
 
 ## Rules for Writing GraphQL Queries
 
-- يجب استخدام كل `queryName` مرة واحدة فقط لكل عملية.
-- يجب استخدام كل `field` مرة واحدة فقط في التحديد (لا يمكننا الاستعلام عن `id` مرتين ضمن `token`)
+- يجب استخدام كل ` queryName ` مرة واحدة فقط لكل عملية.
+- يجب استخدام كل ` field ` مرة واحدة فقط في التحديد (لا يمكننا الاستعلام عن ` id ` مرتين ضمن ` token `)
 - Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/network/explorer).
 - يجب أن يكون أي متغير تم تعيينه لوسيط متطابقًا مع نوعه.
 - في قائمة المتغيرات المعطاة ، يجب أن يكون كل واحد منها فريدًا.
@@ -456,8 +456,8 @@ In order to keep up with the mentioned above best practices and syntactic rules,
 
 [Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
 
-- `@ graphql-eslint / field-on-right-type`: هل يتم استخدام الحقل على النوع المناسب؟
-- `@ graphql-eslint / no-unused variables`: هل يجب أن يبقى المتغير المعطى غير مستخدم؟
+- ` @ graphql-eslint / field-on-right-type `: هل يتم استخدام الحقل على النوع المناسب؟
+- ` @ graphql-eslint / no-unused variables `: هل يجب أن يبقى المتغير المعطى غير مستخدم؟
 - و اكثر!
 
 This will allow you to **catch errors without even testing queries** on the playground or running them in production!

From 3354d77136c319ad0f8dc9e14b62425ad5c30057 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:07:17 -0500
Subject: [PATCH 0224/3820] New translations distributed-systems.mdx (Swedish)

---
 .../pages/sv/querying/distributed-systems.mdx | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/sv/querying/distributed-systems.mdx b/website/pages/sv/querying/distributed-systems.mdx
index 365340f65a1b..3143d4859eb8 100644
--- a/website/pages/sv/querying/distributed-systems.mdx
+++ b/website/pages/sv/querying/distributed-systems.mdx
@@ -84,8 +84,8 @@ Här kommer vi att använda argumentet `block: { hash: $blockHash }` för att bi
 /// Gets a list of domain names from a single block using pagination
 async function getDomainNames() {
   // Set a cap on the maximum number of items to pull.
-  let pages = 5
-  const perPage = 1000
+  let pages = 5;
+  const perPage = 1000;
 
   // The first query will get the first page of results and also get the block
   // hash so that the remainder of the queries are consistent with the first.
@@ -100,34 +100,34 @@ async function getDomainNames() {
                 hash
             }
         }
-    }`
+    }`;
 
-  let data = await graphql(listDomainsQuery, { perPage })
-  let result = data.domains.map((d) => d.name)
-  let blockHash = data._meta.block.hash
+  let data = await graphql(listDomainsQuery, { perPage });
+  let result = data.domains.map((d) => d.name);
+  let blockHash = data._meta.block.hash;
 
-  let query
+  let query;
   // Continue fetching additional pages until either we run into the limit of
   // 5 pages total (specified above) or we know we have reached the last page
   // because the page has fewer entities than a full page.
   while (data.domains.length == perPage && --pages) {
-    let lastID = data.domains[data.domains.length - 1].id
+    let lastID = data.domains[data.domains.length - 1].id;
     query = `
         query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
             domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
                 name
                 id
             }
-        }`
+        }`;
 
-    data = await graphql(query, { perPage, lastID, blockHash })
+    data = await graphql(query, { perPage, lastID, blockHash });
 
     // Accumulate domain names into the result
     for (domain of data.domains) {
-      result.push(domain.name)
+      result.push(domain.name);
     }
   }
-  return result
+  return result;
 }
 ```
 

From 7d5cddad9313e24d07fddc3a0b1c200068562710 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:07:21 -0500
Subject: [PATCH 0225/3820] New translations querying-best-practices.mdx
 (Swedish)

---
 .../sv/querying/querying-best-practices.mdx   | 26 +++++++++----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/website/pages/sv/querying/querying-best-practices.mdx b/website/pages/sv/querying/querying-best-practices.mdx
index 4f836b50ab52..0acb3a3f0351 100644
--- a/website/pages/sv/querying/querying-best-practices.mdx
+++ b/website/pages/sv/querying/querying-best-practices.mdx
@@ -79,7 +79,7 @@ However, as mentioned in ["Querying from an Application"](/querying/querying-fro
 Here's how to query The Graph with `graph-client`:
 
 ```tsx
-import { execute } from '../.graphclient'
+import { execute } from "../.graphclient";
 
 const query = `
 query GetToken($id: ID!) {
@@ -88,13 +88,13 @@ query GetToken($id: ID!) {
     owner
   }
 }
-`
+`;
 const variables = { id: '1' }
 
 async function main() {
-  const result = await execute(query, variables)
+  const result = await execute(query, variables);
   // `result` är fullständigt typad!
-  console.log(result)
+  console.log(result);
 }
 
 main()
@@ -111,15 +111,15 @@ More GraphQL client alternatives are covered in ["Querying from an Application"]
 A common (bad) practice is to dynamically build query strings as follows:
 
 ```tsx
-const id = params.id
-const fields = ['id', 'owner']
+const id = params.id;
+const fields = ["id", "owner"];
 const query = `
 query GetToken {
   token(id: ${id}) {
-    ${fields.join('\n')}
+    ${fields.join("\n")}
   }
 }
-`
+`;
 
 // Execute query...
 ```
@@ -134,9 +134,9 @@ While the above snippet produces a valid GraphQL query, **it has many drawbacks*
 For this reason, it is recommended to always write queries as static strings:
 
 ```tsx
-import { execute } from 'your-favorite-graphql-client'
+import { execute } from "your-favorite-graphql-client";
 
-const id = params.id
+const id = params.id;
 const query = `
 query GetToken($id: ID!) {
   token(id: $id) {
@@ -144,7 +144,7 @@ query GetToken($id: ID!) {
     owner
   }
 }
-`
+`;
 
 const result = await execute(query, {
   variables: {
@@ -167,9 +167,9 @@ You might want to include the `owner` field only on a particular condition.
 For this, you can leverage the `@include(if:...)` directive as follows:
 
 ```tsx
-import { execute } from 'your-favorite-graphql-client'
+import { execute } from "your-favorite-graphql-client";
 
-const id = params.id
+const id = params.id;
 const query = `
 query GetToken($id: ID!, $includeOwner: Boolean) {
   token(id: $id) {

From e8d8c40d369f5828cf10a62ba714d5e915a302bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:07:26 -0500
Subject: [PATCH 0226/3820] New translations publishing-a-subgraph.mdx (Hindi)

---
 website/pages/hi/publishing/publishing-a-subgraph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/publishing/publishing-a-subgraph.mdx b/website/pages/hi/publishing/publishing-a-subgraph.mdx
index dfeec280edfc..d851b7952e7e 100644
--- a/website/pages/hi/publishing/publishing-a-subgraph.mdx
+++ b/website/pages/hi/publishing/publishing-a-subgraph.mdx
@@ -33,7 +33,7 @@ title: विकेंद्रीकृत नेटवर्क के लि
 
 ## Publishing from the CLI
 
-Version 0.73.0 के अनुसार, आप अपने subgraph को[`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli)के साथ भी publish कर सकते हैं।
+Version 0.73.0 के अनुसार, आप अपने subgraph को[` graph-cli `](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli)के साथ भी publish कर सकते हैं।
 
 1. `graph-cli` खोलें।
 2. निम्नलिखित कमांड का उपयोग करें: `graph codegen && graph build` फिर `graph publish`।

From 469a78170e084287bb0c09ba21706ffc167fd2cf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:07:33 -0500
Subject: [PATCH 0227/3820] New translations querying-best-practices.mdx (Urdu
 (Pakistan))

---
 website/pages/ur/querying/querying-best-practices.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/querying/querying-best-practices.mdx b/website/pages/ur/querying/querying-best-practices.mdx
index 47954840b8fe..cd9942f43ea4 100644
--- a/website/pages/ur/querying/querying-best-practices.mdx
+++ b/website/pages/ur/querying/querying-best-practices.mdx
@@ -53,7 +53,7 @@ query [operationName]([variableName]: [variableType]) {
 ## Rules for Writing GraphQL Queries
 
 - ہر ایک `queryName` کو فی آپریشن صرف ایک بار استعمال کیا جانا چاہیے.
-- ہر ایک `field` کو انتخاب میں صرف ایک بار استعمال کیا جانا چاہیے (ہم `token` کے تحت دو بار `id` سے کیوری نہیں کرسکتے ہیں)
+- ہر ایک ` field ` کو انتخاب میں صرف ایک بار استعمال کیا جانا چاہیے (ہم `token` کے تحت دو بار `id` سے کیوری نہیں کرسکتے ہیں)
 - Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/network/explorer).
 - کسی دلیل کو تفویض کردہ کوئی بھی متغیر اس کی قسم سے مماثل ہونا چاہیے.
 - متغیرات کی دی گئی فہرست میں، ان میں سے ہر ایک منفرد ہونا چاہیے.

From a02322033117f14d1ff820925cf124fdd60677fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:07:41 -0500
Subject: [PATCH 0228/3820] New translations assemblyscript-migration-guide.mdx
 (Romanian)

---
 .../ro/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/ro/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ro/release-notes/assemblyscript-migration-guide.mdx
index 85f6903a6c69..17224699570d 100644
--- a/website/pages/ro/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/ro/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 You'll need to rename your duplicate variables if you had variable shadowing.
-
 ### Null Comparisons
-
 By doing the upgrade on your subgraph, sometimes you might get errors like these:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 To solve you can simply change the `if` statement to something like this:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
 
 ```typescript

From 55645db6fecbd938cf59a6c5bdaf0b092318a055 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:07:42 -0500
Subject: [PATCH 0229/3820] New translations assemblyscript-migration-guide.mdx
 (French)

---
 .../assemblyscript-migration-guide.mdx            | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/website/pages/fr/release-notes/assemblyscript-migration-guide.mdx b/website/pages/fr/release-notes/assemblyscript-migration-guide.mdx
index 49e76d908653..619ba98b326a 100644
--- a/website/pages/fr/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/fr/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 Vous devrez renommer vos variables en double si vous conservez une observation de variables.
-
 ### Comparaisons nulles
-
 En effectuant la mise à niveau sur votre subgraph, vous pouvez parfois obtenir des erreurs comme celles-ci :
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 Pour résoudre, vous pouvez simplement remplacer l'instruction `if` par quelque chose comme ceci :
 
 ```typescript
@@ -213,7 +209,7 @@ Dans ces cas-là, vous pouvez utiliser la fonction `changetype<T>` :
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-changetype<Bytes>(uint8Array) // fonctionne :)
+changetype<Bytes>(uint8Array ) // fonctionne :)
 ```
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 Pour résoudre ce problème, vous pouvez créer une variable pour l'accès à cette propriété afin que le compilateur puisse effectuer la vérification magique de la nullité :
 
 ```typescript
@@ -406,7 +401,7 @@ type Total @entity {
 let total = Total.load('latest')
 
 if (total === null) {
-  total = new Total('latest') // initialise déjà les propriétés non-nullables
+    total = new Total('latest') // initialise déjà les propriétés non-nullables
 }
 
 total.amount = total.amount + BigInt.fromI32(1)
@@ -488,12 +483,12 @@ Vous ne pouvez désormais plus définir de champs dans vos types qui sont des li
 
 ```graphql
 type Something @entity {
-  id: Bytes!
+    id: Bytes!
 }
 
 type MyEntity @entity {
-  id: Bytes!
-  invalidField: [Something]! # n'est plus valide
+    id: Bytes!
+    invalidField: [Something]! # n'est plus valide
 }
 ```
 

From 1919a2f7fb859478539a287860f62908f0fc8db6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:07:44 -0500
Subject: [PATCH 0230/3820] New translations assemblyscript-migration-guide.mdx
 (Spanish)

---
 .../es/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/es/release-notes/assemblyscript-migration-guide.mdx b/website/pages/es/release-notes/assemblyscript-migration-guide.mdx
index bfc973f982dd..c3770a5c9ef7 100644
--- a/website/pages/es/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/es/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 Tendrás que cambiar el nombre de las variables duplicadas si tienes una variable shadowing.
-
 ### Comparaciones Nulas
-
 Al hacer la actualización en un subgrafo, a veces pueden aparecer errores como estos:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 Para solucionarlo puedes simplemente cambiar la declaración `if` por algo así:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 Para solucionar este problema, puedes crear una variable para ese acceso a la propiedad de manera que el compilador pueda hacer la magia de la comprobación de nulidad:
 
 ```typescript

From 646e763d6d63dc20a852d0d9889b39409d3f98e5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:07:51 -0500
Subject: [PATCH 0231/3820] New translations querying-from-an-application.mdx
 (Portuguese)

---
 website/pages/pt/querying/querying-from-an-application.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/querying/querying-from-an-application.mdx b/website/pages/pt/querying/querying-from-an-application.mdx
index c073a9d05bde..477899816aab 100644
--- a/website/pages/pt/querying/querying-from-an-application.mdx
+++ b/website/pages/pt/querying/querying-from-an-application.mdx
@@ -114,7 +114,7 @@ Update your `.ts` file to use the generated typed GraphQL documents:
 import React, { useEffect } from 'react'
 // ...
 // nós importamos tipos e documentos em graphql do código gerado
-;`..graphclient/`
+(`..graphclient/`)
 import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
 
 function App() {

From a18c89a5e3f94d572e9264d452504370a1c5b53c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:07:53 -0500
Subject: [PATCH 0232/3820] New translations querying-from-an-application.mdx
 (Swedish)

---
 .../querying/querying-from-an-application.mdx | 30 +++++++++----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/sv/querying/querying-from-an-application.mdx b/website/pages/sv/querying/querying-from-an-application.mdx
index d46eed0ef858..cf26ba6cac68 100644
--- a/website/pages/sv/querying/querying-from-an-application.mdx
+++ b/website/pages/sv/querying/querying-from-an-application.mdx
@@ -177,9 +177,9 @@ npm install @apollo/client graphql
 Query the API with the following code:
 
 ```javascript
-import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+import { ApolloClient, InMemoryCache, gql } from "@apollo/client";
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = "https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/";
 
 const tokensQuery = `
   query {
@@ -190,20 +190,20 @@ const tokensQuery = `
       metadataURI
     }
   }
-`
+`;
 
 const client = new ApolloClient({
   uri: APIURL,
   cache: new InMemoryCache(),
-})
+});
 
 client
   .query({
     query: gql(tokensQuery),
   })
-  .then((data) => console.log('Subgraph data: ', data))
+  .then((data) => console.log("Subgraph data: ", data))
   .catch((err) => {
-    console.log('Error fetching data: ', err)
+    console.log("Error fetching data: ", err);
   })
 ```
 
@@ -223,20 +223,20 @@ const tokensQuery = `
       metadataURI
     }
   }
-`
+`;
 
 client
   .query({
     query: gql(tokensQuery),
     variables: {
       first: 10,
-      orderBy: 'createdAtTimestamp',
-      orderDirection: 'desc',
+      orderBy: "createdAtTimestamp",
+      orderDirection: "desc",
     },
   })
-  .then((data) => console.log('Subgraph data: ', data))
+  .then((data) => console.log("Subgraph data: ", data))
   .catch((err) => {
-    console.log('Error fetching data: ', err)
+    console.log("Error fetching data: ", err);
   })
 ```
 
@@ -266,9 +266,9 @@ npm install urql graphql
 Query the API with the following code:
 
 ```javascript
-import { createClient } from 'urql'
+import { createClient } from "urql";
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = "https://api.thegraph.com/subgraphs/name/username/subgraphname";
 
 const tokensQuery = `
   query {
@@ -279,11 +279,11 @@ const tokensQuery = `
       metadataURI
     }
   }
-`
+`;
 
 const client = createClient({
   url: APIURL,
-})
+});
 
 const data = await client.query(tokensQuery).toPromise()
 ```

From c26b6b444c04fe98392609f6253af23da679696a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:09 -0500
Subject: [PATCH 0233/3820] New translations assemblyscript-migration-guide.mdx
 (Arabic)

---
 .../ar/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/ar/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ar/release-notes/assemblyscript-migration-guide.mdx
index 84e00f13b4e1..9674f1777573 100644
--- a/website/pages/ar/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/ar/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ let a = a + b
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 ستحتاج إلى إعادة تسمية المتغيرات المكررة إذا كان لديك variable shadowing.
-
 ### مقارانات Null
-
 من خلال إجراء الترقية على ال Subgraph الخاص بك ، قد تحصل أحيانًا على أخطاء مثل هذه:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 لحل المشكلة يمكنك ببساطة تغيير عبارة `if` إلى شيء مثل هذا:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 لإصلاح هذه المشكلة ، يمكنك إنشاء متغير للوصول إلى الخاصية حتى يتمكن المترجم من القيام بعملية التحقق من الـ nullability:
 
 ```typescript

From 47e78204be5cb41264d37be7aa9ec432a266712a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:10 -0500
Subject: [PATCH 0234/3820] New translations assemblyscript-migration-guide.mdx
 (Czech)

---
 .../cs/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/cs/release-notes/assemblyscript-migration-guide.mdx b/website/pages/cs/release-notes/assemblyscript-migration-guide.mdx
index d1b9eb00bc04..e59516868de6 100644
--- a/website/pages/cs/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/cs/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 Pokud jste použili stínování proměnných, musíte duplicitní proměnné přejmenovat.
-
 ### Nulová srovnání
-
 Při aktualizaci podgrafu může někdy dojít k těmto chybám:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 Pro vyřešení můžete jednoduše změnit příkaz `if` na něco takového:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 Chcete-li tento problém vyřešit, můžete vytvořit proměnnou pro přístup k této vlastnosti, aby překladač mohl provést kouzlo kontroly nulovatelnosti:
 
 ```typescript

From ba33c0570ae3ed7371d598c8bbe0fa0fc7d509f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:12 -0500
Subject: [PATCH 0235/3820] New translations assemblyscript-migration-guide.mdx
 (German)

---
 .../de/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/de/release-notes/assemblyscript-migration-guide.mdx b/website/pages/de/release-notes/assemblyscript-migration-guide.mdx
index fb1ad8beb382..058c48b32e6f 100644
--- a/website/pages/de/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/de/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 You'll need to rename your duplicate variables if you had variable shadowing.
-
 ### Null Comparisons
-
 By doing the upgrade on your subgraph, sometimes you might get errors like these:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 To solve you can simply change the `if` statement to something like this:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
 
 ```typescript

From 1ce39efd4d9854773bb92d4eecd3bead8926746e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:19 -0500
Subject: [PATCH 0236/3820] New translations grafting.mdx (Arabic)

---
 website/pages/ar/cookbook/grafting.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ar/cookbook/grafting.mdx b/website/pages/ar/cookbook/grafting.mdx
index 08c347c50a63..b02cb89876af 100644
--- a/website/pages/ar/cookbook/grafting.mdx
+++ b/website/pages/ar/cookbook/grafting.mdx
@@ -12,15 +12,15 @@ The grafted subgraph can use a GraphQL schema that is not identical to the one o
 
 - يضيف أو يزيل أنواع الكيانات
 - يزيل الصفات من أنواع الكيانات
-- يضيف صفات nullable لأنواع الكيانات
-- يحول صفات non-nullable إلى صفات nullable
-- يضيف قيما إلى enums
-- يضيف أو يزيل الواجهات
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
 - يغير للكيانات التي يتم تنفيذ الواجهة لها
 
 For more information, you can check:
 
-- [تطعيم(Grafting)](/developing/creating-a-subgraph#grafting-onto-existing-subgraphs)
+- [Grafting](/developing/creating-a-subgraph#grafting-onto-existing-subgraphs)
 
 In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
 

From 8bf101ee40a4c8877a1355b84713aeae4826e3a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:22 -0500
Subject: [PATCH 0237/3820] New translations assemblyscript-migration-guide.mdx
 (Italian)

---
 .../it/release-notes/assemblyscript-migration-guide.mdx    | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/website/pages/it/release-notes/assemblyscript-migration-guide.mdx b/website/pages/it/release-notes/assemblyscript-migration-guide.mdx
index b6bd7ecc38d2..64cbf23decf7 100644
--- a/website/pages/it/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/it/release-notes/assemblyscript-migration-guide.mdx
@@ -59,7 +59,7 @@ dataSources:
 2. Aggiornare il `graph-cli` in uso alla versione `ultima` eseguendo:
 
 ```bash
-# se è installato globalmente
+# se è installato globalmente 
 npm install --global @graphprotocol/graph-cli@latest
 
 # o nel proprio subgraph, se è una dipendenza di dev
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 È necessario rinominare le variabili duplicate se si dispone di un'ombreggiatura delle variabili.
-
 ### Confronti nulli
-
 Eseguendo l'aggiornamento sul subgraph, a volte si possono ottenere errori come questi:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 Per risolvere il problema è sufficiente modificare l'istruzione `if` in qualcosa di simile:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 Per risolvere questo problema, si può creare una variabile per l'accesso alla proprietà, in modo che il compilatore possa fare la magia del controllo di annullabilità:
 
 ```typescript

From 06c07ef4e11b0a702954f03dbe2a5b4cae987515 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:23 -0500
Subject: [PATCH 0238/3820] New translations assemblyscript-migration-guide.mdx
 (Japanese)

---
 .../ja/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/ja/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ja/release-notes/assemblyscript-migration-guide.mdx
index 766fbb6c80a3..82a7d23de3f8 100644
--- a/website/pages/ja/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/ja/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 変数シャドウイングを行っていた場合は、重複する変数の名前を変更する必要があります。
-
 ### Null 比較
-
 サブグラフのアップグレードを行うと、時々以下のようなエラーが発生することがあります。
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 解決するには、 `if` 文を以下のように変更するだけです。
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 この問題を解決するには、そのプロパティアクセスのための変数を作成して、コンパイラが nullability check のマジックを行うようにします。
 
 ```typescript

From a0b139a8e7472a729c2f840e3cc15dc5204b77ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:24 -0500
Subject: [PATCH 0239/3820] New translations assemblyscript-migration-guide.mdx
 (Korean)

---
 .../ko/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/ko/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ko/release-notes/assemblyscript-migration-guide.mdx
index 85f6903a6c69..17224699570d 100644
--- a/website/pages/ko/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/ko/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 You'll need to rename your duplicate variables if you had variable shadowing.
-
 ### Null Comparisons
-
 By doing the upgrade on your subgraph, sometimes you might get errors like these:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 To solve you can simply change the `if` statement to something like this:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
 
 ```typescript

From 9d3e01bbd6879ebe8f9479425e4378148df2d2d9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:26 -0500
Subject: [PATCH 0240/3820] New translations assemblyscript-migration-guide.mdx
 (Dutch)

---
 .../nl/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/nl/release-notes/assemblyscript-migration-guide.mdx b/website/pages/nl/release-notes/assemblyscript-migration-guide.mdx
index 85f6903a6c69..17224699570d 100644
--- a/website/pages/nl/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/nl/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 You'll need to rename your duplicate variables if you had variable shadowing.
-
 ### Null Comparisons
-
 By doing the upgrade on your subgraph, sometimes you might get errors like these:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 To solve you can simply change the `if` statement to something like this:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
 
 ```typescript

From 8d0630c1e5dc4f67ac7cc25662ff1b5350380da8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:27 -0500
Subject: [PATCH 0241/3820] New translations assemblyscript-migration-guide.mdx
 (Polish)

---
 .../pl/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/pl/release-notes/assemblyscript-migration-guide.mdx b/website/pages/pl/release-notes/assemblyscript-migration-guide.mdx
index 85f6903a6c69..17224699570d 100644
--- a/website/pages/pl/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/pl/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 You'll need to rename your duplicate variables if you had variable shadowing.
-
 ### Null Comparisons
-
 By doing the upgrade on your subgraph, sometimes you might get errors like these:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 To solve you can simply change the `if` statement to something like this:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
 
 ```typescript

From 78a89d84b72675adbf64a9932bd7b9c3bdde29ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:32 -0500
Subject: [PATCH 0242/3820] New translations grafting.mdx (Italian)

---
 website/pages/it/cookbook/grafting.mdx | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/it/cookbook/grafting.mdx b/website/pages/it/cookbook/grafting.mdx
index d6c443a46538..6c3b85419af9 100644
--- a/website/pages/it/cookbook/grafting.mdx
+++ b/website/pages/it/cookbook/grafting.mdx
@@ -8,15 +8,15 @@ In this guide, you will learn how to build and deploy new subgraphs by grafting
 
 Grafting reuses the data from an existing subgraph and starts indexing it at a later block. This is useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. Also, it can be used when adding a feature to a subgraph that takes long to index from scratch.
 
-Il grafted subgraph può utilizzare uno schema GraphQL non identico a quello del subgraph di base, ma semplicemente compatibile con esso. Deve essere uno schema di subgraph valido di per sé, ma può discostarsi dallo schema del subgraph di base nei seguenti modi:
-
-- Aggiunge o rimuove i tipi di entità
-- Rimuove gli attributi dai tipi di entità
-- Aggiunge attributi annullabili ai tipi di entità
-- Trasforma gli attributi non nulli in attributi nulli
-- Aggiunge valori agli enum
-- Aggiunge o rimuove le interfacce
-- Cambia per quali tipi di entità viene implementata un'interfaccia
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
 
 For more information, you can check:
 

From 69f1e17333e195949fe4c3c131c46dd7989241dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:35 -0500
Subject: [PATCH 0243/3820] New translations assemblyscript-migration-guide.mdx
 (Portuguese)

---
 .../pt/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/pt/release-notes/assemblyscript-migration-guide.mdx b/website/pages/pt/release-notes/assemblyscript-migration-guide.mdx
index ce410b9ed255..df425838fea1 100644
--- a/website/pages/pt/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/pt/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 Renomeie as suas variáveis duplicadas, se tinha o sombreamento variável.
-
 ### Comparações de Nulos
-
 Ao fazer a atualização no seu subgraph, às vezes aparecem erros como este:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 Para resolver isto, basta mudar a declaração `if` para algo assim:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 Para consertar este problema, vale criar uma variável para aquele acesso à propriedade, para que o compilador faça a magia da checagem de anulabilidade:
 
 ```typescript

From a8227c0be9a12483fb688b063c8448e68581a67f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:36 -0500
Subject: [PATCH 0244/3820] New translations assemblyscript-migration-guide.mdx
 (Russian)

---
 .../ru/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/ru/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ru/release-notes/assemblyscript-migration-guide.mdx
index af444be7a6e3..1047cc70ad5b 100644
--- a/website/pages/ru/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/ru/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 Вам нужно будет переименовать дублированные переменные, если Вы используете затенение переменных.
-
 ### Нулевые сравнения
-
 Выполняя обновление своего субграфа, иногда Вы можете получить такие ошибки:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 Чтобы решить эту проблему, Вы можете просто изменить оператор `if` на что-то вроде этого:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 Чтобы решить эту проблему, Вы можете создать переменную для доступа к этому свойству, чтобы компилятор мог выполнять проверку допустимости значений NULL:
 
 ```typescript

From ac946df7a81a30edabbfe5bd1bab5abd4b237131 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:37 -0500
Subject: [PATCH 0245/3820] New translations assemblyscript-migration-guide.mdx
 (Swedish)

---
 .../assemblyscript-migration-guide.mdx        | 127 +++++++++---------
 1 file changed, 61 insertions(+), 66 deletions(-)

diff --git a/website/pages/sv/release-notes/assemblyscript-migration-guide.mdx b/website/pages/sv/release-notes/assemblyscript-migration-guide.mdx
index 97c6bb95635a..afa4a7df4747 100644
--- a/website/pages/sv/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/sv/release-notes/assemblyscript-migration-guide.mdx
@@ -91,17 +91,17 @@ maybeValue.aMethod();
 Men i den nyare versionen, eftersom värdet är nullable, måste du kontrollera, så här:
 
 ```typescript
-let maybeValue = load()
+let maybeValue = load();
 
 if (maybeValue) {
-  maybeValue.aMethod() // `maybeValue` is not null anymore
+  maybeValue.aMethod(); // `maybeValue` is not null anymore
 }
 ```
 
 Eller gör så här:
 
 ```typescript
-let maybeValue = load()! // bryts i runtime om värdet är null
+let maybeValue = load()!; // bryts i runtime om värdet är null
 
 maybeValue.aMethod()
 ```
@@ -113,8 +113,8 @@ Om du är osäker på vilken du ska välja, rekommenderar vi alltid att använda
 Tidigare kunde du använda [variabelskuggning](https://en.wikipedia.org/wiki/Variable_shadowing) och kod som detta skulle fungera:
 
 ```typescript
-let a = 10
-let b = 20
+let a = 10;
+let b = 20;
 let a = a + b
 ```
 
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 Du måste döpa om dina duplicerade variabler om du hade variabelskuggning.
-
 ### Jämförelser med nollvärden
-
 När du gör uppgraderingen av din subgraf kan du ibland få fel som dessa:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 För att lösa problemet kan du helt enkelt ändra `if`-satsen till något i den här stilen:
 
 ```typescript
@@ -158,8 +154,8 @@ Samma gäller om du använder != istället för ==.
 Det vanliga sättet att göra kasting tidigare var att bara använda nyckelordet `as`, som så här:
 
 ```typescript
-let byteArray = new ByteArray(10)
-let uint8Array = byteArray as Uint8Array // motsvarande: <Uint8Array>byteArray
+let byteArray = new ByteArray(10);
+let uint8Array = byteArray as Uint8Array; // motsvarande: <Uint8Array>byteArray
 ```
 
 Detta fungerar dock endast i två scenarier:
@@ -171,8 +167,8 @@ Exempel:
 
 ```typescript
 // primitive casting
-let a: usize = 10
-let b: isize = 5
+let a: usize = 10;
+let b: isize = 5;
 let c: usize = a + (b as usize)
 ```
 
@@ -180,7 +176,7 @@ let c: usize = a + (b as usize)
 // upcasting on class inheritance
 class Bytes extends Uint8Array {}
 
-let bytes = new Bytes(2)
+let bytes = new Bytes(2);
 // <Uint8Array>bytes // same as: bytes as Uint8Array
 ```
 
@@ -193,7 +189,7 @@ Det finns två scenarier där du kan vilja casta, men att använda `as`/`<T>var`
 // downcasting om klassarv
 class Bytes extends Uint8Array {}
 
-let uint8Array = new Uint8Array(2)
+let uint8Array = new Uint8Array(2);
 // <Bytes>uint8Array // breaks in runtime :(
 ```
 
@@ -202,7 +198,7 @@ let uint8Array = new Uint8Array(2)
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
-let bytes = new Bytes(2)
+let bytes = new Bytes(2);
 // <ByteArray>bytes // breaks in runtime :(
 ```
 
@@ -212,8 +208,8 @@ I dessa fall kan du använda funktionen `changetype<T>`:
 // downcasting om klassarv
 class Bytes extends Uint8Array {}
 
-let uint8Array = new Uint8Array(2)
-changetype<Bytes>(uint8Array) // works :)
+let uint8Array = new Uint8Array(2);
+changetype<Bytes>(uint8Array); // works :)
 ```
 
 ```typescript
@@ -221,18 +217,18 @@ changetype<Bytes>(uint8Array) // works :)
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
-let bytes = new Bytes(2)
-changetype<ByteArray>(bytes) // works :)
+let bytes = new Bytes(2);
+changetype<ByteArray>(bytes); // works :)
 ```
 
 Om du bara vill ta bort nullability kan du fortsätta använda `as`-operatorn (eller `<T>variable`), men se till att du vet att värdet inte kan vara null, annars kommer det att bryta.
 
 ```typescript
 // ta bort ogiltighet
-let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+let previousBalance = AccountBalance.load(balanceId); // AccountBalance | null
 
 if (previousBalance != null) {
-  return previousBalance as AccountBalance // safe remove null
+  return previousBalance as AccountBalance; // safe remove null
 }
 
 let newBalance = new AccountBalance(balanceId)
@@ -252,18 +248,18 @@ Vi har också lagt till några fler statiska metoder i vissa typer för att unde
 För att använda [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) kan du använda antingen `if`-satser eller den ternära operatorn (`?` och `:`) så här:
 
 ```typescript
-let something: string | null = 'data'
+let something: string | null = "data";
 
-let somethingOrElse = something ? something : 'else'
+let somethingOrElse = something ? something : "else";
 
 // or
 
-let somethingOrElse
+let somethingOrElse;
 
 if (something) {
-  somethingOrElse = something
+  somethingOrElse = something;
 } else {
-  somethingOrElse = 'else'
+  somethingOrElse = "else";
 }
 ```
 
@@ -274,10 +270,10 @@ class Container {
   data: string | null
 }
 
-let container = new Container()
-container.data = 'data'
+let container = new Container();
+container.data = "data";
 
-let somethingOrElse: string = container.data ? container.data : 'else' // Kompilerar inte
+let somethingOrElse: string = container.data ? container.data : "else"; // Kompilerar inte
 ```
 
 Vilket ger detta fel:
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 För att åtgärda problemet kan du skapa en variabel för den egenskapen så att kompilatorn kan utföra den magiska nollbarhetskontrollen:
 
 ```typescript
@@ -296,12 +291,12 @@ class Container {
   data: string | null
 }
 
-let container = new Container()
-container.data = 'data'
+let container = new Container();
+container.data = "data";
 
-let data = container.data
+let data = container.data;
 
-let somethingOrElse: string = data ? data : 'else' // kompilerar helt okej :)
+let somethingOrElse: string = data ? data : "else"; // kompilerar helt okej :)
 ```
 
 ### Operatörsöverladdning med egenskapsaccess
@@ -310,7 +305,7 @@ Om du försöker summera (till exempel) en nullable typ (från en property acces
 
 ```typescript
 class BigInt extends Uint8Array {
-  @operator('+')
+  @operator("+")
   plus(other: BigInt): BigInt {
     // ...
   }
@@ -320,26 +315,26 @@ class Wrapper {
   public constructor(public n: BigInt | null) {}
 }
 
-let x = BigInt.fromI32(2)
-let y: BigInt | null = null
+let x = BigInt.fromI32(2);
+let y: BigInt | null = null;
 
-x + y // ge kompileringsfel om ogiltighet
+x + y; // ge kompileringsfel om ogiltighet
 
-let wrapper = new Wrapper(y)
+let wrapper = new Wrapper(y);
 
-wrapper.n = wrapper.n + x // ger inte kompileringsfel som det borde
+wrapper.n = wrapper.n + x; // ger inte kompileringsfel som det borde
 ```
 
 Vi har öppnat en fråga om AssemblyScript-kompilatorn för detta, men om du gör den här typen av operationer i dina subgraf-mappningar bör du ändra dem så att de gör en null-kontroll innan den.
 
 ```typescript
-let wrapper = new Wrapper(y)
+let wrapper = new Wrapper(y);
 
 if (!wrapper.n) {
-  wrapper.n = BigInt.fromI32(0)
+  wrapper.n = BigInt.fromI32(0);
 }
 
-wrapper.n = wrapper.n + x // nu är `n` garanterat ett BigInt
+wrapper.n = wrapper.n + x; // nu är `n` garanterat ett BigInt
 ```
 
 ### Initialisering av värde
@@ -347,17 +342,17 @@ wrapper.n = wrapper.n + x // nu är `n` garanterat ett BigInt
 Om du har någon kod som denna:
 
 ```typescript
-var value: Type // null
-value.x = 10
-value.y = 'content'
+var value: Type; // null
+value.x = 10;
+value.y = "content"
 ```
 
 Det kommer att kompilera men brytas vid körning, det händer eftersom värdet inte har initialiserats, så se till att din subgraf har initialiserat sina värden, så här:
 
 ```typescript
-var value = new Type() // initialized
-value.x = 10
-value.y = 'content'
+var value = new Type(); // initialized
+value.x = 10;
+value.y = "content"
 ```
 
 Även om du har nullable properties i en GraphQL-entitet, som denna:
@@ -372,10 +367,10 @@ type Total @entity {
 Och du har en kod som liknar den här:
 
 ```typescript
-let total = Total.load('latest')
+let total = Total.load("latest");
 
 if (total === null) {
-  total = new Total('latest')
+  total = new Total("latest")
 }
 
 total.amount = total.amount + BigInt.fromI32(1)
@@ -384,11 +379,11 @@ total.amount = total.amount + BigInt.fromI32(1)
 Du måste se till att initialisera värdet `total.amount`, för om du försöker komma åt som i den sista raden för summan, kommer det att krascha. Så antingen initialiserar du det först:
 
 ```typescript
-let total = Total.load('latest')
+let total = Total.load("latest")
 
 if (total === null) {
-  total = new Total('latest')
-  total.amount = BigInt.fromI32(0)
+  total = new Total("latest")
+  total.amount = BigInt.fromI32(0);
 }
 
 total.tokens = total.tokens + BigInt.fromI32(1)
@@ -404,10 +399,10 @@ type Total @entity {
 ```
 
 ```typescript
-let total = Total.load('latest')
+let total = Total.load("latest");
 
 if (total === null) {
-  total = new Total('latest') // initierar redan icke-nullställbara egenskaper
+  total = new Total("latest"); // initierar redan icke-nullställbara egenskaper
 }
 
 total.amount = total.amount + BigInt.fromI32(1)
@@ -435,17 +430,17 @@ export class Something {
 // or
 
 export class Something {
-  value: Thing
+  value: Thing;
 
   constructor(value: Thing) {
-    this.value = value
+    this.value = value;
   }
 }
 
 // or
 
 export class Something {
-  value!: Thing
+  value!: Thing;
 }
 ```
 
@@ -454,9 +449,9 @@ export class Something {
 Klassen `Array` accepterar fortfarande ett tal för att initiera längden på listan, men du bör vara försiktig eftersom operationer som `.push` faktiskt ökar storleken istället för att lägga till i början, till exempel:
 
 ```typescript
-let arr = new Array<string>(5) // ["", "", "", "", ""]
+let arr = new Array<string>(5); // ["", "", "", "", ""]
 
-arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+arr.push("something"); // ["", "", "", "", "", "something"] // size 6 :(
 ```
 
 Beroende på vilka typer du använder, t.ex. nullable-typer, och hur du kommer åt dem, kan du stöta på ett runtime-fel som det här:
@@ -468,17 +463,17 @@ ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/ar
 För att faktiskt trycka i början bör du antingen initiera `Array` med storlek noll, så här:
 
 ```typescript
-let arr = new Array<string>(0) // []
+let arr = new Array<string>(0); // []
 
-arr.push('something') // ["something"]
+arr.push("something"); // ["something"]
 ```
 
 Eller så bör du mutera den via index:
 
 ```typescript
-let arr = new Array<string>(5) // ["", "", "", "", ""]
+let arr = new Array<string>(5); // ["", "", "", "", ""]
 
-arr[0] = 'something' // ["something", "", "", "", ""]
+arr[0] = "something"; // ["something", "", "", "", ""]
 ```
 
 ### GraphQL-schema

From 5633a5ed6b6cbc050348f0acb91b068cc8039cc1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:38 -0500
Subject: [PATCH 0246/3820] New translations assemblyscript-migration-guide.mdx
 (Turkish)

---
 .../tr/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/tr/release-notes/assemblyscript-migration-guide.mdx b/website/pages/tr/release-notes/assemblyscript-migration-guide.mdx
index a8bb2e376807..fd305a2ca624 100644
--- a/website/pages/tr/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/tr/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 You'll need to rename your duplicate variables if you had variable shadowing.
-
 ### Null Comparisons
-
 By doing the upgrade on your subgraph, sometimes you might get errors like these:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 To solve you can simply change the `if` statement to something like this:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
 
 ```typescript

From 85b4b61b151917991541cd5fcaff217c08562ab7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:40 -0500
Subject: [PATCH 0247/3820] New translations assemblyscript-migration-guide.mdx
 (Ukrainian)

---
 .../uk/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/uk/release-notes/assemblyscript-migration-guide.mdx b/website/pages/uk/release-notes/assemblyscript-migration-guide.mdx
index 85f6903a6c69..17224699570d 100644
--- a/website/pages/uk/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/uk/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 You'll need to rename your duplicate variables if you had variable shadowing.
-
 ### Null Comparisons
-
 By doing the upgrade on your subgraph, sometimes you might get errors like these:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 To solve you can simply change the `if` statement to something like this:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
 
 ```typescript

From d650aaeefedf06e188b5273f6a39b7ae9314ce94 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:44 -0500
Subject: [PATCH 0248/3820] New translations assemblyscript-migration-guide.mdx
 (Chinese Simplified)

---
 .../zh/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/zh/release-notes/assemblyscript-migration-guide.mdx b/website/pages/zh/release-notes/assemblyscript-migration-guide.mdx
index 622bdeef307e..3ff2d318c88f 100644
--- a/website/pages/zh/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/zh/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 如果您有变量遮蔽的情况，则需要重命名重名变量。
-
 ### 空值比较
-
 对子图进行升级后，有时您可能会遇到如下错误：
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 要解决此问题，您只需将 `if` 语句更改为如下所示代码：
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 要解决此问题，您可以为该属性访问创建一个变量，以便编译器可以执行可空性检查：
 
 ```typescript

From 2fb453d50e02bcebb55682cb2389bddbbed17f4e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:45 -0500
Subject: [PATCH 0249/3820] New translations assemblyscript-migration-guide.mdx
 (Urdu (Pakistan))

---
 .../ur/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/ur/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ur/release-notes/assemblyscript-migration-guide.mdx
index 31439d43c505..9c8d0512a4eb 100644
--- a/website/pages/ur/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/ur/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 اگر آپ کے پاس متغیر شیڈونگ ہے تو آپ کو اپنے ڈپلیکیٹ متغیرات کا نام تبدیل کرنے کی ضرورت ہوگی.
-
 ### کالعدم موازنہ
-
 اپنے سب گراف پر اپ گریڈ کرنے سے، بعض اوقات آپ کو اس طرح کی غلطیاں مل سکتی ہیں:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 حل کرنے کے لیے آپ صرف `if` اسٹیٹمنٹ کو اس طرح تبدیل کر سکتے ہیں:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 اس مسئلے کو حل کرنے کے لیے، آپ اس پراپرٹی تک رسائی کے لیے ایک متغیر بنا سکتے ہیں تاکہ مرتب کرنے والا منسوخی چیک میجک کر سکے:
 
 ```typescript

From d0b658c12bc52e64c88e0db1893a9a50e21d017e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:47 -0500
Subject: [PATCH 0250/3820] New translations assemblyscript-migration-guide.mdx
 (Vietnamese)

---
 .../vi/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/vi/release-notes/assemblyscript-migration-guide.mdx b/website/pages/vi/release-notes/assemblyscript-migration-guide.mdx
index 69c36218d8af..8536b657e78a 100644
--- a/website/pages/vi/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/vi/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 Bạn sẽ cần đổi tên các biến trùng lặp của mình nếu bạn có che biến.
-
 ### So sánh Null
-
 Bằng cách thực hiện nâng cấp trên subgraph của bạn, đôi khi bạn có thể gặp các lỗi như sau:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 Để giải quyết, bạn có thể chỉ cần thay đổi câu lệnh `if` thành một cái gì đó như sau:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 Để khắc phục sự cố này, bạn có thể tạo một biến cho quyền truy cập thuộc tính đó để trình biên dịch có thể thực hiện phép thuật kiểm tra tính nullability:
 
 ```typescript

From b717dee228c2283690efeca71d3ee9a8f7c72f8a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:48 -0500
Subject: [PATCH 0251/3820] New translations assemblyscript-migration-guide.mdx
 (Marathi)

---
 .../mr/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/mr/release-notes/assemblyscript-migration-guide.mdx b/website/pages/mr/release-notes/assemblyscript-migration-guide.mdx
index a170ebec8cda..2d735415bebb 100644
--- a/website/pages/mr/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/mr/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ However now this isn't possible anymore, and the compiler returns this error:
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 You'll need to rename your duplicate variables if you had variable shadowing.
-
 ### Null Comparisons
-
 By doing the upgrade on your subgraph, sometimes you might get errors like these:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 To solve you can simply change the `if` statement to something like this:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
 
 ```typescript

From 9901874288018dbcdd216c32cc05b99725677d30 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:49 -0500
Subject: [PATCH 0252/3820] New translations assemblyscript-migration-guide.mdx
 (Hindi)

---
 .../hi/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/hi/release-notes/assemblyscript-migration-guide.mdx b/website/pages/hi/release-notes/assemblyscript-migration-guide.mdx
index 6bc091a4083a..031b1d2dd195 100644
--- a/website/pages/hi/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/hi/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 यदि आपके पास वेरिएबल शैडोइंग है, तो आपको अपने डुप्लिकेट वेरिएबल्स का नाम बदलने की आवश्यकता होगी।
-
 ### Null Comparisons
-
 अपने सबग्राफ पर अपग्रेड करने से, कभी-कभी आपको इस तरह की त्रुटियाँ मिल सकती हैं:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 हल करने के लिए आप केवल `if` कथन को कुछ इस तरह से बदल सकते हैं:
 
 ```typescript
@@ -287,7 +283,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
 
    let somethingOrElse: string = container.data ? container.data : "else";
 ```
-
 इस समस्या को ठीक करने के लिए, आप उस प्रॉपर्टी एक्सेस के लिए एक वेरिएबल बना सकते हैं ताकि कंपाइलर अशक्तता जांच जादू कर सके:
 
 ```typescript

From 5a2def966bfa819f76f230320e1b8eedc70c36fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:50 -0500
Subject: [PATCH 0253/3820] New translations assemblyscript-migration-guide.mdx
 (Swahili)

---
 .../sw/release-notes/assemblyscript-migration-guide.mdx      | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/website/pages/sw/release-notes/assemblyscript-migration-guide.mdx b/website/pages/sw/release-notes/assemblyscript-migration-guide.mdx
index 85f6903a6c69..17224699570d 100644
--- a/website/pages/sw/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/sw/release-notes/assemblyscript-migration-guide.mdx
@@ -127,11 +127,8 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
  ~~~~~~~~~~~~~
 in assembly/index.ts(4,3)
 ```
-
 You'll need to rename your duplicate variables if you had variable shadowing.
-
 ### Null Comparisons
-
 By doing the upgrade on your subgraph, sometimes you might get errors like these:
 
 ```typescript
@@ -140,7 +137,6 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
                      ~~~~
  in src/mappings/file.ts(41,21)
 ```
-
 To solve you can simply change the `if` statement to something like this:
 
 ```typescript
@@ -288,7 +284,6 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
    let somethingOrElse: string = container.data ? container.data : "else";
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
-
 To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
 
 ```typescript

From 39be66318a7ec2da2d496d410f7f402431743656 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:08:54 -0500
Subject: [PATCH 0254/3820] New translations billing.mdx (Hindi)

---
 website/pages/hi/billing.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/billing.mdx b/website/pages/hi/billing.mdx
index 1462d5d49ea6..d67ec53497ca 100644
--- a/website/pages/hi/billing.mdx
+++ b/website/pages/hi/billing.mdx
@@ -31,11 +31,11 @@ Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph
 
 ### GRT on Arbitrum or Ethereum
 
-The Graph का बिलिंग सिस्टम Arbitrum पर GRT को स्वीकार करता है, और उपयोगकर्ताओं को गैस के भुगतान के लिए Arbitrum पर ETH की आवश्यकता होगी। जबकि The Graph प्रोटोकॉल Ethereum Mainnet पर शुरू हुआ, सभी गतिविधियाँ, जिसमें बिलिंग कॉन्ट्रैक्ट्स भी शामिल हैं, अब Arbitrum One पर हैं।
+The Graph का बिलिंग सिस्टम Arbitrum पर GRT को स्वीकार करता है, और उपयोगकर्ताओं को गैस के भुगतान के लिए Arbitrum  पर ETH की आवश्यकता होगी। जबकि The Graph प्रोटोकॉल Ethereum Mainnet पर शुरू हुआ, सभी गतिविधियाँ, जिसमें बिलिंग कॉन्ट्रैक्ट्स भी शामिल हैं, अब Arbitrum One पर हैं।
 
 क्वेरियों के लिए भुगतान करने के लिए, आपको Arbitrum पर GRT की आवश्यकता है। इसे प्राप्त करने के लिए कुछ विभिन्न तरीके यहां दिए गए हैं:
 
-- यदि आपके पास पहले से Ethereum पर GRT है, तो आप इसे Arbitrum पर ब्रिज कर सकते हैं। आप यह Subgraph Studio में प्रदान किए गए GRT ब्रिजिंग विकल्प के माध्यम से या निम्नलिखित में से किसी एक ब्रिज का उपयोग करके कर सकते हैं:
+- यदि आपके पास पहले से  Ethereum पर GRT है, तो आप इसे Arbitrum पर ब्रिज कर सकते हैं। आप यह Subgraph Studio में प्रदान किए गए GRT ब्रिजिंग विकल्प के माध्यम से या निम्नलिखित में से किसी एक ब्रिज का उपयोग करके कर सकते हैं:
 
 - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
 - [TransferTo](https://transferto.xyz/swap)

From 0f8c7313b58b37144d34524b080137e69dabc557 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:21 -0500
Subject: [PATCH 0255/3820] New translations grafting.mdx (Vietnamese)

---
 website/pages/vi/cookbook/grafting.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/vi/cookbook/grafting.mdx b/website/pages/vi/cookbook/grafting.mdx
index c37ae95c28e0..88488c27d3a2 100644
--- a/website/pages/vi/cookbook/grafting.mdx
+++ b/website/pages/vi/cookbook/grafting.mdx
@@ -10,12 +10,12 @@ Grafting reuses the data from an existing subgraph and starts indexing it at a l
 
 The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
 
-- Nó thêm hoặc xóa các loại thực thể
-- Nó loại bỏ các thuộc tính khỏi các loại thực thể
-- Nó thêm các thuộc tính nullable vào các loại thực thể
-- Nó biến các thuộc tính không thể nullable thành các thuộc tính nullable
-- Nó thêm giá trị vào enums
-- Nó thêm hoặc xóa các giao diện
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
 - Nó thay đổi đối với loại thực thể nào mà một giao diện được triển khai
 
 For more information, you can check:

From 54cf7878b501dcdb4dc24c0dac5e8af12620fa29 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:23 -0500
Subject: [PATCH 0256/3820] New translations grafting.mdx (Hindi)

---
 website/pages/hi/cookbook/grafting.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/cookbook/grafting.mdx b/website/pages/hi/cookbook/grafting.mdx
index 2225f5cacb01..9505f7e39b5b 100644
--- a/website/pages/hi/cookbook/grafting.mdx
+++ b/website/pages/hi/cookbook/grafting.mdx
@@ -189,7 +189,7 @@ You can see that the `graft-replacement` subgraph is indexing from older `graph-
 
 Congrats! You have successfully grafted a subgraph onto another subgraph.
 
-## अतिरिक्त संसाधन
+## Additional Resources
 
 यदि आप grafting के साथ अधिक अनुभव प्राप्त करना चाहते हैं, तो यहां कुछ लोकप्रिय कॉन्ट्रैक्ट्स के उदाहरण दिए गए हैं:
 

From bf2b107cb208730623b5bf73b6e0a61ec3832743 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:29 -0500
Subject: [PATCH 0257/3820] New translations operating-graph-node.mdx
 (Romanian)

---
 website/pages/ro/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ro/operating-graph-node.mdx b/website/pages/ro/operating-graph-node.mdx
index dbbfcd5fc545..fb3d538f952a 100644
--- a/website/pages/ro/operating-graph-node.mdx
+++ b/website/pages/ro/operating-graph-node.mdx
@@ -77,13 +77,13 @@ A complete Kubernetes example configuration can be found in the [indexer reposit
 
 When it is running Graph Node exposes the following ports:
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(for subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                               | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                          | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                    | /metrics                                             | --metrics-port    | -                    |
 
 > **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
 

From f7fed03bc2c73c41d7a1032f0c6460523c9910ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:30 -0500
Subject: [PATCH 0258/3820] New translations operating-graph-node.mdx (French)

---
 website/pages/fr/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/fr/operating-graph-node.mdx b/website/pages/fr/operating-graph-node.mdx
index 252894e113a0..329f1ac72adf 100644
--- a/website/pages/fr/operating-graph-node.mdx
+++ b/website/pages/fr/operating-graph-node.mdx
@@ -77,13 +77,13 @@ Un exemple complet de configuration de Kubernetes est disponible dans le [dépô
 
 Lorsqu'il est en cours d'exécution, Graph Node expose les ports suivants :
 
-| Port | Objectif | Routes | Argument CLI | Variable d'environnement |
-| --- | --- | --- | --- | --- |
-| 8000 | Serveur HTTP GraphQL<br />(pour les requêtes de subgraphs) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(pour les abonnements aux subgraphs) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(pour gérer les déploiements) | / | --admin-port | - |
-| 8030 | API de statut d'indexation des subgraphs | /graphq | --index-node-port | - |
-| 8040 | Métriques Prometheus | /metrics | --metrics-port | - |
+| Port | Objectif                                                         | Routes                                               | Argument CLI      | Variable d'environnement |
+| ---- | ---------------------------------------------------------------- | ---------------------------------------------------- | ----------------- | ------------------------ |
+| 8000 | Serveur HTTP GraphQL<br />(pour les requêtes de subgraphs) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                        |
+| 8001 | GraphQL WS<br />(pour les abonnements aux subgraphs)       | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                        |
+| 8020 | JSON-RPC<br />(pour gérer les déploiements)                | /                                                    | --admin-port      | -                        |
+| 8030 | API de statut d'indexation des subgraphs                         | /graphq                                              | --index-node-port | -                        |
+| 8040 | Métriques Prometheus                                             | /metrics                                             | --metrics-port    | -                        |
 
 > **Important** : Soyez prudent lorsque vous exposez les ports publiquement : les **ports d'administration** doivent rester verrouillés. Cela inclut le point de terminaison Graph Node JSON-RPC.
 

From 049e98ce812f0f6aae8a9426e653d443ec16a37f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:31 -0500
Subject: [PATCH 0259/3820] New translations operating-graph-node.mdx (Spanish)

---
 website/pages/es/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/es/operating-graph-node.mdx b/website/pages/es/operating-graph-node.mdx
index 2dc80685b400..99e966da590a 100644
--- a/website/pages/es/operating-graph-node.mdx
+++ b/website/pages/es/operating-graph-node.mdx
@@ -77,13 +77,13 @@ Puedes encontrar un ejemplo completo de configuración de Kubernetes en el [Inde
 
 Cuando está funcionando, Graph Node muestra los siguientes puertos:
 
-| Puerto | Objeto | Rutas | Argumento CLI | Variable de Entorno |
-| --- | --- | --- | --- | --- |
-| 8000 | Servidor HTTP GraphQL<br />(para consultas de subgrafos) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(para suscripciones a subgrafos) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(para administrar implementaciones) | / | --admin-port | - |
-| 8030 | API de estado de indexación de subgrafos | /graphql | --index-node-port | - |
-| 8040 | Métricas de Prometheus | /metrics | --metrics-port | - |
+| Puerto | Objeto                                                         | Rutas                                                | Argumento CLI     | Variable de Entorno |
+| ------ | -------------------------------------------------------------- | ---------------------------------------------------- | ----------------- | ------------------- |
+| 8000   | Servidor HTTP GraphQL<br />(para consultas de subgrafos) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                   |
+| 8001   | GraphQL WS<br />(para suscripciones a subgrafos)         | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                   |
+| 8020   | JSON-RPC<br />(para administrar implementaciones)        | /                                                    | --admin-port      | -                   |
+| 8030   | API de estado de indexación de subgrafos                       | /graphql                                             | --index-node-port | -                   |
+| 8040   | Métricas de Prometheus                                         | /metrics                                             | --metrics-port    | -                   |
 
 > **Importante**: Ten cuidado con exponer puertos públicamente - los **puertos de administración** deben mantenerse bloqueados. Esto incluye el punto final JSON-RPC de Graph Node.
 

From 550b0095542dff93329c5d13b7f9863afad5acf3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:33 -0500
Subject: [PATCH 0260/3820] New translations operating-graph-node.mdx (Arabic)

---
 website/pages/ar/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ar/operating-graph-node.mdx b/website/pages/ar/operating-graph-node.mdx
index ec9595ef8404..ac2816215c96 100644
--- a/website/pages/ar/operating-graph-node.mdx
+++ b/website/pages/ar/operating-graph-node.mdx
@@ -77,13 +77,13 @@ A complete Kubernetes example configuration can be found in the [indexer reposit
 
 When it is running Graph Node exposes the following ports:
 
-| المنفذ | الغرض | المسار | CLI Argument | متغيرات البيئة |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | http-port-- | - |
-| 8001 | GraphQL WS <br /> (for subgraph subscriptions) | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | ws-port-- | - |
-| 8020 | JSON-RPC <br /> (for managing deployments) | / | admin-port-- | - |
-| 8030 | Subgraph indexing status API | /graphql | index-node-port-- | - |
-| 8040 | Prometheus metrics | /metrics | metrics-port-- | - |
+| المنفذ | الغرض                                                   | المسار                                                              | CLI Argument      | متغيرات البيئة |
+| ------ | ------------------------------------------------------- | ------------------------------------------------------------------- | ----------------- | -------------- |
+| 8000   | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | http-port--       | -              |
+| 8001   | GraphQL WS <br /> (for subgraph subscriptions)    | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | ws-port--         | -              |
+| 8020   | JSON-RPC <br /> (for managing deployments)        | /                                                                   | admin-port--      | -              |
+| 8030   | Subgraph indexing status API                            | /graphql                                                            | index-node-port-- | -              |
+| 8040   | Prometheus metrics                                      | /metrics                                                            | metrics-port--    | -              |
 
 > **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
 

From 43588f108ce1ec3817b124ff3560e8d220e4193b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:34 -0500
Subject: [PATCH 0261/3820] New translations operating-graph-node.mdx (Czech)

---
 website/pages/cs/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/cs/operating-graph-node.mdx b/website/pages/cs/operating-graph-node.mdx
index b6067883a47a..9a720348c8c5 100644
--- a/website/pages/cs/operating-graph-node.mdx
+++ b/website/pages/cs/operating-graph-node.mdx
@@ -77,13 +77,13 @@ Kompletní příklad konfigurace Kubernetes naleznete v úložišti [indexer](ht
 
 Když je Graf Uzel spuštěn, zpřístupňuje následující ports:
 
-| Port | Účel | Trasy | CLI Argument | Proměnná prostředí |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(pro dotazy podgrafy) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(pro odběry podgrafů) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(pro správu nasazení) | / | --admin-port | - |
-| 8030 | Stav indexování podgrafů API | /graphql | --index-node-port | - |
-| 8040 | Metriky Prometheus | /metrics | --metrics-port | - |
+| Port | Účel                                                 | Trasy                                                | CLI Argument      | Proměnná prostředí |
+| ---- | ---------------------------------------------------- | ---------------------------------------------------- | ----------------- | ------------------ |
+| 8000 | GraphQL HTTP server<br />(pro dotazy podgrafy) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                  |
+| 8001 | GraphQL WS<br />(pro odběry podgrafů)          | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                  |
+| 8020 | JSON-RPC<br />(pro správu nasazení)            | /                                                    | --admin-port      | -                  |
+| 8030 | Stav indexování podgrafů API                         | /graphql                                             | --index-node-port | -                  |
+| 8040 | Metriky Prometheus                                   | /metrics                                             | --metrics-port    | -                  |
 
 > **Důležité**: Dávejte pozor na veřejné vystavování portů - **administrační porty** by měly být uzamčeny. To se týká i koncového bodu JSON-RPC uzlu Graf.
 

From e7d129219e7605370ebcece6f4b572243bccf8a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:39 -0500
Subject: [PATCH 0262/3820] New translations operating-graph-node.mdx (German)

---
 website/pages/de/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/de/operating-graph-node.mdx b/website/pages/de/operating-graph-node.mdx
index 0a2dda70086d..571f332cd774 100644
--- a/website/pages/de/operating-graph-node.mdx
+++ b/website/pages/de/operating-graph-node.mdx
@@ -77,13 +77,13 @@ Eine vollständige Kubernetes-Beispielkonfiguration finden Sie im [Indexer-Repos
 
 Wenn es ausgeführt wird, stellt Graph Node die folgenden Ports zur Verfügung:
 
-| Port | Zweck | Routen | CLI-Argument | Umgebungsvariable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP-Server<br />(für Subgraf-Abfragen) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(für Subgraf-Abonnements) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(zum Verwalten von Deployments) | / | --admin-port | - |
-| 8030 | Subgraf-Indizierungsstatus-API | /graphql | --index-node-port | - |
-| 8040 | Prometheus-Metriken | /metrics | --metrics-port | - |
+| Port | Zweck                                                 | Routen                                               | CLI-Argument      | Umgebungsvariable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | ----------------- |
+| 8000 | GraphQL HTTP-Server<br />(für Subgraf-Abfragen) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                 |
+| 8001 | GraphQL WS<br />(für Subgraf-Abonnements)       | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                 |
+| 8020 | JSON-RPC<br />(zum Verwalten von Deployments)   | /                                                    | --admin-port      | -                 |
+| 8030 | Subgraf-Indizierungsstatus-API                        | /graphql                                             | --index-node-port | -                 |
+| 8040 | Prometheus-Metriken                                   | /metrics                                             | --metrics-port    | -                 |
 
 > **Wichtig**: Seien Sie vorsichtig, wenn Sie Ports öffentlich zugänglich machen - **Administrationsports** sollten gesperrt bleiben. Dies schließt den JSON-RPC-Endpunkt des Graph-Knotens ein.
 

From af566fd3083cb5a595393eaf2bf99f09fd9458ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:40 -0500
Subject: [PATCH 0263/3820] New translations operating-graph-node.mdx (Italian)

---
 website/pages/it/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/it/operating-graph-node.mdx b/website/pages/it/operating-graph-node.mdx
index b3b3ca24e204..276c3022ec6c 100644
--- a/website/pages/it/operating-graph-node.mdx
+++ b/website/pages/it/operating-graph-node.mdx
@@ -77,13 +77,13 @@ Un esempio completo di configurazione Kubernetes si trova nel [repository indexe
 
 Quando è in funzione, Graph Node espone le seguenti porte:
 
-| Porta | Obiettivo | Routes | Argomento CLI | Variabile d'ambiente |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(per le query di subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(per le sottoscrizioni ai subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(per la gestione dei deployment) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Metriche di Prometheus | /metrics | --metrics-port | - |
+| Porta | Obiettivo                                                 | Routes                                               | Argomento CLI     | Variabile d'ambiente |
+| ----- | --------------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000  | GraphQL HTTP server<br />(per le query di subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001  | GraphQL WS<br />(per le sottoscrizioni ai subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020  | JSON-RPC<br />(per la gestione dei deployment)      | /                                                    | --admin-port      | -                    |
+| 8030  | Subgraph indexing status API                              | /graphql                                             | --index-node-port | -                    |
+| 8040  | Metriche di Prometheus                                    | /metrics                                             | --metrics-port    | -                    |
 
 > **Importante**: fare attenzione a esporre le porte pubblicamente - le porte di **amministrazione** devono essere tenute sotto chiave. Questo include l'endpoint JSON-RPC del Graph Node.
 

From aa2c91ac5c08145611f651ab69d2fcc9f31d880c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:41 -0500
Subject: [PATCH 0264/3820] New translations operating-graph-node.mdx
 (Japanese)

---
 website/pages/ja/operating-graph-node.mdx | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/ja/operating-graph-node.mdx b/website/pages/ja/operating-graph-node.mdx
index cb9e4f14e8f3..71da764773e6 100644
--- a/website/pages/ja/operating-graph-node.mdx
+++ b/website/pages/ja/operating-graph-node.mdx
@@ -26,7 +26,7 @@ title: オペレーティンググラフノード
 
 ### IPFSノード
 
-IPFS ノード（バージョン 未満） - サブグラフのデプロイメタデータは IPFS ネットワーク上に保存されます。 グラフノードは、サブグラフのデプロイ時に主に IPFS ノードにアクセスし、サブグラフマニフェストと全てのリンクファイルを取得します。 ネットワーク・インデクサーは独自の IPFS ノードをホストする必要はありません。 ネットワーク用の IPFS ノードは、https://ipfs.network.thegraph.com でホストされています。
+IPFS ノード（バージョン  未満） - サブグラフのデプロイメタデータは IPFS ネットワーク上に保存されます。 グラフノードは、サブグラフのデプロイ時に主に IPFS ノードにアクセスし、サブグラフマニフェストと全てのリンクファイルを取得します。 ネットワーク・インデクサーは独自の IPFS ノードをホストする必要はありません。 ネットワーク用の IPFS ノードは、https://ipfs.network.thegraph.com でホストされています。
 
 ### Prometheus メトリクスサーバー
 
@@ -77,13 +77,13 @@ Kubernetesの完全な設定例は、[indexerリポジトリ](https://github.com
 
 グラフノードは起動時に以下のポートを公開します。
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> /subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS <br /> (for subgraph subscriptions) | /subgraphs/id/... <br /> /subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC <br /> (for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                                 | Routes                                                 | CLI Argument      | Environment Variable |
+| ---- | ------------------------------------------------------- | ------------------------------------------------------ | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> /subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS <br /> (for subgraph subscriptions)    | /subgraphs/id/... <br /> /subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC <br /> (for managing deployments)        | /                                                      | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                            | /graphql                                               | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                      | /metrics                                               | --metrics-port    | -                    |
 
 > **重要**: ポートを公に公開する場合は注意してください。**管理ポート**はロックしておく必要があります。ノードの JSON-RPC エンドポイント
 

From 6434e306fc58c763868ea032ba455d9d74aa145d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:43 -0500
Subject: [PATCH 0265/3820] New translations operating-graph-node.mdx (Korean)

---
 website/pages/ko/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ko/operating-graph-node.mdx b/website/pages/ko/operating-graph-node.mdx
index dbbfcd5fc545..fb3d538f952a 100644
--- a/website/pages/ko/operating-graph-node.mdx
+++ b/website/pages/ko/operating-graph-node.mdx
@@ -77,13 +77,13 @@ A complete Kubernetes example configuration can be found in the [indexer reposit
 
 When it is running Graph Node exposes the following ports:
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(for subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                               | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                          | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                    | /metrics                                             | --metrics-port    | -                    |
 
 > **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
 

From 70d9b4ef15e3bee0861b3738a2b2710c7ae325b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:44 -0500
Subject: [PATCH 0266/3820] New translations operating-graph-node.mdx (Dutch)

---
 website/pages/nl/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/nl/operating-graph-node.mdx b/website/pages/nl/operating-graph-node.mdx
index d2117bcf07d5..7524b17721c9 100644
--- a/website/pages/nl/operating-graph-node.mdx
+++ b/website/pages/nl/operating-graph-node.mdx
@@ -77,13 +77,13 @@ A complete Kubernetes example configuration can be found in the [indexer reposit
 
 When it is running Graph Node exposes the following ports:
 
-| Poort | Doel | Routes | CLI-Argument | Omgevingsvariabele |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(voor subgraph query's) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(voor subgraph abonnementen) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(voor het beheren van implementaties) | / | --admin-port | - |
-| 8030 | Subgraph indexeerstatus API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Poort | Doel                                                      | Routes                                               | CLI-Argument      | Omgevingsvariabele |
+| ----- | --------------------------------------------------------- | ---------------------------------------------------- | ----------------- | ------------------ |
+| 8000  | GraphQL HTTP server<br />(voor subgraph query's)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                  |
+| 8001  | GraphQL WS<br />(voor subgraph abonnementen)        | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                  |
+| 8020  | JSON-RPC<br />(voor het beheren van implementaties) | /                                                    | --admin-port      | -                  |
+| 8030  | Subgraph indexeerstatus API                               | /graphql                                             | --index-node-port | -                  |
+| 8040  | Prometheus metrics                                        | /metrics                                             | --metrics-port    | -                  |
 
 > **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
 

From c9b8773c2d54f4a581865f6069595af7d4497c6c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:45 -0500
Subject: [PATCH 0267/3820] New translations operating-graph-node.mdx (Polish)

---
 website/pages/pl/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/pl/operating-graph-node.mdx b/website/pages/pl/operating-graph-node.mdx
index dbbfcd5fc545..fb3d538f952a 100644
--- a/website/pages/pl/operating-graph-node.mdx
+++ b/website/pages/pl/operating-graph-node.mdx
@@ -77,13 +77,13 @@ A complete Kubernetes example configuration can be found in the [indexer reposit
 
 When it is running Graph Node exposes the following ports:
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(for subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                               | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                          | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                    | /metrics                                             | --metrics-port    | -                    |
 
 > **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
 

From 076e95df03e1ee001b2c159bbc67eef6f3e74cc1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:50 -0500
Subject: [PATCH 0268/3820] New translations operating-graph-node.mdx
 (Portuguese)

---
 website/pages/pt/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/pt/operating-graph-node.mdx b/website/pages/pt/operating-graph-node.mdx
index 38202b73da9c..5eb6c795dcd5 100644
--- a/website/pages/pt/operating-graph-node.mdx
+++ b/website/pages/pt/operating-graph-node.mdx
@@ -77,13 +77,13 @@ Veja uma configuração de exemplo completa do Kubernetes no [repositório de in
 
 Durante a execução, o Graph Node expõe as seguintes portas:
 
-| Porta | Propósito | Rotas | Argumento CLI | Variável de Ambiente |
-| --- | --- | --- | --- | --- |
-| 8000 | Servidor HTTP GraphQL<br />(para queries de subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | WS GraphQL<br />(para inscrições a subgraphs) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(para gerir lançamentos) | / | --admin-port | - |
-| 8030 | API de status de indexamento do subgraph | /graphql | --index-node-port | - |
-| 8040 | Métricas Prometheus | /metrics | --metrics-port | - |
+| Porta | Propósito                                                   | Rotas                                                | Argumento CLI     | Variável de Ambiente |
+| ----- | ----------------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000  | Servidor HTTP GraphQL<br />(para queries de subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001  | WS GraphQL<br />(para inscrições a subgraphs)         | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020  | JSON-RPC<br />(para gerir lançamentos)                | /                                                    | --admin-port      | -                    |
+| 8030  | API de status de indexamento do subgraph                    | /graphql                                             | --index-node-port | -                    |
+| 8040  | Métricas Prometheus                                         | /metrics                                             | --metrics-port    | -                    |
 
 > **Importante:** Cuidado ao expor portas publicamente; as **portas de administração** devem ser trancadas a sete chaves. Isto inclui o endpoint JSON-RPC do Graph Node.
 

From 974e4896b47cf5ff77bede86c66815ee824ab327 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:51 -0500
Subject: [PATCH 0269/3820] New translations operating-graph-node.mdx (Russian)

---
 website/pages/ru/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ru/operating-graph-node.mdx b/website/pages/ru/operating-graph-node.mdx
index dad9f543237a..d4ac6c51a05d 100644
--- a/website/pages/ru/operating-graph-node.mdx
+++ b/website/pages/ru/operating-graph-node.mdx
@@ -77,13 +77,13 @@ cargo run -p graph-node --release -- \
 
 Во время работы Graph Node предоставляет следующие порты:
 
-| Порт | Назначение | Расположение | CLI-аргумент | Переменная среды |
-| --- | --- | --- | --- | --- |
-| 8000 | HTTP-сервер GraphQL<br />(для запросов подграфов) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(для подписок на подграфы) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(для управления процессом развертывания) | / | --admin-port | - |
-| 8030 | API для определения статуса индексирования подграфов | /graphql | --index-node-port | - |
-| 8040 | Показатели Prometheus | /metrics | --metrics-port | - |
+| Порт | Назначение                                                   | Расположение                                         | CLI-аргумент      | Переменная среды |
+| ---- | ------------------------------------------------------------ | ---------------------------------------------------- | ----------------- | ---------------- |
+| 8000 | HTTP-сервер GraphQL<br />(для запросов подграфов)      | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                |
+| 8001 | GraphQL WS<br />(для подписок на подграфы)             | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                |
+| 8020 | JSON-RPC<br />(для управления процессом развертывания) | /                                                    | --admin-port      | -                |
+| 8030 | API для определения статуса индексирования подграфов         | /graphql                                             | --index-node-port | -                |
+| 8040 | Показатели Prometheus                                        | /metrics                                             | --metrics-port    | -                |
 
 > **Важно**. Будьте осторожны, открывая порты для общего доступа — **порты администрирования** должны быть заблокированы. Это касается конечных точек Graph Node JSON-RPC.
 

From 7e352c79a0bd8e979d2e9289f54a60a6443281b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:53 -0500
Subject: [PATCH 0270/3820] New translations operating-graph-node.mdx (Swedish)

---
 website/pages/sv/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/sv/operating-graph-node.mdx b/website/pages/sv/operating-graph-node.mdx
index 65b506e574dd..83c59421c17b 100644
--- a/website/pages/sv/operating-graph-node.mdx
+++ b/website/pages/sv/operating-graph-node.mdx
@@ -77,13 +77,13 @@ En komplett exempelkonfiguration för Kubernetes finns i [indexer repository](ht
 
 När Graph Node är igång exponerar den följande portar:
 
-| Port | Syfte | Rutter | Argument för CLI | Miljö Variabel |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP-server<br />(för frågor om undergrafer) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(för prenumerationer på undergrafer) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(för hantering av distributioner) | / | --admin-port | - |
-| 8030 | Status för indexering av undergrafer API | /graphql | --index-node-port | - |
-| 8040 | Prometheus mätvärden | /metrics | --metrics-port | - |
+| Port | Syfte                                                      | Rutter                                               | Argument för CLI  | Miljö Variabel |
+| ---- | ---------------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------- |
+| 8000 | GraphQL HTTP-server<br />(för frågor om undergrafer) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -              |
+| 8001 | GraphQL WS<br />(för prenumerationer på undergrafer) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -              |
+| 8020 | JSON-RPC<br />(för hantering av distributioner)      | /                                                    | --admin-port      | -              |
+| 8030 | Status för indexering av undergrafer API                   | /graphql                                             | --index-node-port | -              |
+| 8040 | Prometheus mätvärden                                       | /metrics                                             | --metrics-port    | -              |
 
 > **Viktigt**: Var försiktig med att exponera portar offentligt - **administrationsportar** bör hållas säkra. Detta inkluderar JSON-RPC-slutpunkten för Graph Node.
 

From 775b3bfc19df976189beed1af879f72a9612e08a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:54 -0500
Subject: [PATCH 0271/3820] New translations operating-graph-node.mdx (Turkish)

---
 website/pages/tr/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/tr/operating-graph-node.mdx b/website/pages/tr/operating-graph-node.mdx
index 7a9039808b81..7112df5b91c5 100644
--- a/website/pages/tr/operating-graph-node.mdx
+++ b/website/pages/tr/operating-graph-node.mdx
@@ -77,13 +77,13 @@ Tam Kubernetes örnek yapılandırması [indeksleyici Github deposunda](https://
 
 Graph Düğümü çalışırken aşağıdaki portları açar:
 
-| Port | Amaç | Rotalar | CLI Argümanı | Ortam Değişkeni |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP sunucusu<br />( subgraph sorguları için) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />( subgraph abonelikleri için) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(dağıtımları yönetmek için) | / | --admin-port | - |
-| 8030 | Subgraph indeksleme durum API'si | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrikleri | /metrics | --metrics-port | - |
+| Port | Amaç                                                        | Rotalar                                              | CLI Argümanı      | Ortam Değişkeni |
+| ---- | ----------------------------------------------------------- | ---------------------------------------------------- | ----------------- | --------------- |
+| 8000 | GraphQL HTTP sunucusu<br />( subgraph sorguları için) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -               |
+| 8001 | GraphQL WS<br />( subgraph abonelikleri için)         | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -               |
+| 8020 | JSON-RPC<br />(dağıtımları yönetmek için)             | /                                                    | --admin-port      | -               |
+| 8030 | Subgraph indeksleme durum API'si                            | /graphql                                             | --index-node-port | -               |
+| 8040 | Prometheus metrikleri                                       | /metrics                                             | --metrics-port    | -               |
 
 > **Önemli**: Bağlantı noktalarını herkese açık olarak açarken dikkatli olun - **yönetim portları** kilitli tutulmalıdır. Bu, Graph Düğümü JSON-RPC uç noktasını içerir.
 

From 0da9b7b4b6c2c39f9dd3ad1834d8f3319c42a93e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:09:55 -0500
Subject: [PATCH 0272/3820] New translations operating-graph-node.mdx
 (Ukrainian)

---
 website/pages/uk/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/uk/operating-graph-node.mdx b/website/pages/uk/operating-graph-node.mdx
index 30a9ee532653..cd8118b275b7 100644
--- a/website/pages/uk/operating-graph-node.mdx
+++ b/website/pages/uk/operating-graph-node.mdx
@@ -77,13 +77,13 @@ A complete Kubernetes example configuration can be found in the [indexer reposit
 
 When it is running Graph Node exposes the following ports:
 
-| Порт | Призначення | Розташування | Аргумент CLI | Перемінна оточення |
-| --- | --- | --- | --- | --- |
-| 8000 | HTTP-сервер GraphQL<br />(для запитів до підграфів) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-порт | - |
-| 8001 | GraphQL WS<br />(для підписок на підграфи) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(для керування розгортаннями) | / | --admin-port | - |
-| 8030 | API стану індексації підграфів | /graphql | --index-node-port | - |
-| 8040 | Метрики Prometheus | /metrics | --metrics-port | - |
+| Порт | Призначення                                               | Розташування                                         | Аргумент CLI      | Перемінна оточення |
+| ---- | --------------------------------------------------------- | ---------------------------------------------------- | ----------------- | ------------------ |
+| 8000 | HTTP-сервер GraphQL<br />(для запитів до підграфів) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-порт       | -                  |
+| 8001 | GraphQL WS<br />(для підписок на підграфи)          | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                  |
+| 8020 | JSON-RPC<br />(для керування розгортаннями)         | /                                                    | --admin-port      | -                  |
+| 8030 | API стану індексації підграфів                            | /graphql                                             | --index-node-port | -                  |
+| 8040 | Метрики Prometheus                                        | /metrics                                             | --metrics-port    | -                  |
 
 > **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
 

From 70fd9f03a6a6b397eef80b6002217fea20a484f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:03 -0500
Subject: [PATCH 0273/3820] New translations operating-graph-node.mdx (Chinese
 Simplified)

---
 website/pages/zh/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/zh/operating-graph-node.mdx b/website/pages/zh/operating-graph-node.mdx
index 0847fd1c03c6..ecda26fa9061 100644
--- a/website/pages/zh/operating-graph-node.mdx
+++ b/website/pages/zh/operating-graph-node.mdx
@@ -77,13 +77,13 @@ cargo run -p graph-node --release -- \
 
 当运行Graph Node时，会暴露以下端口：
 
-| 端口 | 用途 | 路径 | CLI 参数 | 环境 变量 |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP 服务 <br />（用于子图查询） | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS <br />（用于子图订阅） | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC <br />（用于管理部署） | / | --admin-port | - |
-| 8030 | 子图索引状态 API | /graphql | --index-node-port | - |
-| 8040 | Prometheus 指标 | /metrics | --metrics-port | - |
+| 端口   | 用途                                   | 路径                                                                  | CLI 参数            | 环境 变量 |
+| ---- | ------------------------------------ | ------------------------------------------------------------------- | ----------------- | ----- |
+| 8000 | GraphQL HTTP 服务 <br />（用于子图查询） | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | --http-port       | -     |
+| 8001 | GraphQL WS <br />（用于子图订阅）      | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | --ws-port         | -     |
+| 8020 | JSON-RPC <br />（用于管理部署）        | /                                                                   | --admin-port      | -     |
+| 8030 | 子图索引状态 API                           | /graphql                                                            | --index-node-port | -     |
+| 8040 | Prometheus 指标                        | /metrics                                                            | --metrics-port    | -     |
 
 > **重要**: 公开暴露端口时要小心 - **管理端口** 应保持锁定。 这包括下面详述的 Graph 节点 JSON-RPC 和索引人管理端点。
 

From 46255285c1934a962019bada7eeccb5006755277 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:04 -0500
Subject: [PATCH 0274/3820] New translations operating-graph-node.mdx (Urdu
 (Pakistan))

---
 website/pages/ur/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ur/operating-graph-node.mdx b/website/pages/ur/operating-graph-node.mdx
index 53ed532c07f8..1591a45dd2d0 100644
--- a/website/pages/ur/operating-graph-node.mdx
+++ b/website/pages/ur/operating-graph-node.mdx
@@ -77,13 +77,13 @@ cargo run -p graph-node --release -- \
 
 جب یہ چل رہا ہوتا ہے گراف نوڈ مندرجہ ذیل پورٹس کو بے نقاب کرتا ہے:
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(سب گراف کی کیوریز کے لیے) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(سب گراف سبسکرپشنز کے لیے) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(تعیناتیوں کے انتظام کے لیے) | / | --admin-port | - |
-| 8030 | سب گراف انڈیکسنگ اسٹیٹس API | /graphql | --index-node-port | - |
-| 8040 | Prometheus میٹرکس | /metrics | --metrics-port | - |
+| Port | Purpose                                                   | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | --------------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(سب گراف کی کیوریز کے لیے) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(سب گراف سبسکرپشنز کے لیے)          | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(تعیناتیوں کے انتظام کے لیے)          | /                                                    | --admin-port      | -                    |
+| 8030 | سب گراف انڈیکسنگ اسٹیٹس API                               | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus میٹرکس                                         | /metrics                                             | --metrics-port    | -                    |
 
 > **اہم**: پورٹس کو عوامی طور پر ظاہر کرنے میں محتاط رہیں - **انتظامی پورٹس** کو بند رکھا جانا چاہیے. اس میں گراف نوڈ کا JSON-RPC اینڈ پوائنٹ شامل ہے.
 

From f44bc1ed1b6b7d2bbbd6335d587198498456da2c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:05 -0500
Subject: [PATCH 0275/3820] New translations operating-graph-node.mdx
 (Vietnamese)

---
 website/pages/vi/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/vi/operating-graph-node.mdx b/website/pages/vi/operating-graph-node.mdx
index 82cebd402554..9185043e72a4 100644
--- a/website/pages/vi/operating-graph-node.mdx
+++ b/website/pages/vi/operating-graph-node.mdx
@@ -77,13 +77,13 @@ A complete Kubernetes example configuration can be found in the [indexer reposit
 
 When it is running Graph Node exposes the following ports:
 
-| Cổng | Mục đích | Tuyến | Đối số CLI | Biến môi trường |
-| --- | --- | --- | --- | --- |
-| 8000 | Máy chủ GraphQL HTTP<br />(cho các truy vấn subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(cho các đăng ký subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(để quản lý triển khai) | / | --admin-port | - |
-| 8030 | API trạng thái lập chỉ mục Subgraph | /graphql | --index-node-port | - |
-| 8040 | Số liệu Prometheus | /metrics | --metrics-port | - |
+| Cổng | Mục đích                                                    | Tuyến                                                | Đối số CLI        | Biến môi trường |
+| ---- | ----------------------------------------------------------- | ---------------------------------------------------- | ----------------- | --------------- |
+| 8000 | Máy chủ GraphQL HTTP<br />(cho các truy vấn subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -               |
+| 8001 | GraphQL WS<br />(cho các đăng ký subgraph)            | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -               |
+| 8020 | JSON-RPC<br />(để quản lý triển khai)                 | /                                                    | --admin-port      | -               |
+| 8030 | API trạng thái lập chỉ mục Subgraph                         | /graphql                                             | --index-node-port | -               |
+| 8040 | Số liệu Prometheus                                          | /metrics                                             | --metrics-port    | -               |
 
 > **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
 

From 562c4a4faf94b11890c2737208eb8c71eb760243 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:07 -0500
Subject: [PATCH 0276/3820] New translations operating-graph-node.mdx (Marathi)

---
 website/pages/mr/operating-graph-node.mdx | 118 +++++++++++-----------
 1 file changed, 59 insertions(+), 59 deletions(-)

diff --git a/website/pages/mr/operating-graph-node.mdx b/website/pages/mr/operating-graph-node.mdx
index 907114f75be5..c9a9e5a2afed 100644
--- a/website/pages/mr/operating-graph-node.mdx
+++ b/website/pages/mr/operating-graph-node.mdx
@@ -2,19 +2,19 @@
 title: ऑपरेटिंग ग्राफ नोड
 ---
 
-ग्राफ नोड हा घटक आहे जो सबग्राफ इंडेक्स करतो आणि परिणामी डेटा GraphQL API द्वारे क्वेरीसाठी उपलब्ध करतो. हे इंडेक्सर स्टॅकसाठी मध्यवर्ती आहे आणि यशस्वी इंडेक्सर चालवण्यासाठी ग्राफ नोडचे योग्य ऑपरेशन महत्वाचे आहे.
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
 
-हे ग्राफ नोडचे संदर्भित विहंगावलोकन आणि इंडेक्सर्ससाठी उपलब्ध काही अधिक प्रगत पर्याय प्रदान करते. तपशीलवार दस्तऐवजीकरण आणि सूचना [ग्राफ नोड भांडार](https://github.com/graphprotocol/graph-node) मध्ये आढळू शकतात.
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
 
 ## आलेख नोड
 
-[ग्राफ नोड](https://github.com/graphprotocol/graph-node) हे ग्राफ नेटवर्कवर सबग्राफ अनुक्रमित करण्यासाठी, ब्लॉकचेन क्लायंटशी कनेक्ट करण्यासाठी, सबग्राफ अनुक्रमित करण्यासाठी आणि अनुक्रमित डेटा उपलब्ध करण्यासाठी संदर्भ अंमलबजावणी आहे पृच्छणे.
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
 
-ग्राफ नोड (आणि संपूर्ण इंडेक्सर स्टॅक) बेअर मेटलवर किंवा क्लाउड वातावरणात चालवला जाऊ शकतो. केंद्रीय अनुक्रमणिका घटकाची ही लवचिकता आलेख प्रोटोकॉलच्या मजबुतीसाठी महत्त्वपूर्ण आहे. त्याचप्रमाणे, आलेख नोड [स्रोत पासून तयार](https://github.com/graphprotocol/graph-node) केला जाऊ शकतो किंवा अनुक्रमणिका [डॉकर प्रतिमा प्रदान केल्या](https:// पैकी एक वापरू शकतात hub.docker.com/r/graphprotocol/graph-node).
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
 
 ### PostgreSQL डेटाबेस
 
-ग्राफ नोडसाठी मुख्य स्टोअर, येथे सबग्राफ डेटा संग्रहित केला जातो, तसेच सबग्राफबद्दलचा मेटाडेटा आणि सबग्राफ-अज्ञेयवादी नेटवर्क डेटा जसे की ब्लॉक कॅशे आणि eth_call कॅशे.
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
 
 ### नेटवर्क क्लायंट
 
@@ -26,7 +26,7 @@ While some subgraphs may just require a full node, some may have indexing featur
 
 ### आयपीएफएस नोड्स
 
-सबग्राफ डिप्लॉयमेंट मेटाडेटा आयपीएफएस नेटवर्कवर संग्रहित केला जातो. सबग्राफ मॅनिफेस्ट आणि सर्व लिंक केलेल्या फाइल्स आणण्यासाठी सबग्राफ डिप्लॉयमेंट दरम्यान ग्राफ नोड प्रामुख्याने आयपीएफएस नोडमध्ये प्रवेश करतो. नेटवर्क इंडेक्सर्सना त्यांचे स्वतःचे IPFS नोड होस्ट करण्याची आवश्यकता नाही. नेटवर्कसाठी एक IPFS नोड https://ipfs.network.thegraph.com वर होस्ट केला आहे.
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
 
 ### प्रोमिथियस मेट्रिक्स सर्व्हर
 
@@ -73,29 +73,29 @@ cargo run -p graph-node --release -- \
 
 A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
 
-### बंदरे
+### Ports
 
 When it is running Graph Node exposes the following ports:
 
-| बंदर | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(for subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| बंदर | Purpose                                               | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                          | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                    | /metrics                                             | --metrics-port    | -                    |
 
-> **महत्त्वाचे**: पोर्ट सार्वजनिकपणे उघड करण्याबाबत सावधगिरी बाळगा - **प्रशासन पोर्ट** लॉक डाउन ठेवले पाहिजेत. यामध्ये ग्राफ नोड JSON-RPC एंडपॉइंटचा समावेश आहे.
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
 
 ## प्रगत ग्राफ नोड कॉन्फिगरेशन
 
-सर्वात सोप्या पद्धतीने, ग्राफ नोड, ग्राफ नोड, एकल PostgreSQL डेटाबेस, एक IPFS नोड, आणि सबग्राफ अनुक्रमित करण्यासाठी आवश्यक असलेल्या नेटवर्क क्लायंटच्या एकाच उदाहरणासह ऑपरेट केला जाऊ शकतो.
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
 
-हा सेटअप क्षैतिजरित्या स्केल केला जाऊ शकतो, अनेक ग्राफ नोड्स आणि त्या ग्राफ नोड्सला समर्थन देण्यासाठी एकाधिक डेटाबेस जोडून. प्रगत वापरकर्ते ग्राफ नोडच्या काही क्षैतिज स्केलिंग क्षमतांचा, तसेच काही अधिक प्रगत कॉन्फिगरेशन पर्यायांचा लाभ घेऊ इच्छितात, `config.toml` फाइल आणि ग्राफ नोडच्या पर्यावरणीय चलने.
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
 
 ### `config.toml`
 
-[TOML](https://toml.io/en/) कॉन्फिगरेशन फाईल CLI मध्ये उघड केलेल्या कॉन्फिगरेशनपेक्षा अधिक जटिल कॉन्फिगरेशन सेट करण्यासाठी वापरली जाऊ शकते. फाइलचे स्थान --config कमांड लाइन स्विचसह पास केले जाते.
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
 
 > When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.
 
@@ -120,7 +120,7 @@ Graph Node indexing can scale horizontally, running multiple instances of Graph
 
 #### डिप्लॉयमेंट नियम
 
-एकापेक्षा जास्त आलेख नोड्स दिल्यास, नवीन सबग्राफची तैनाती व्यवस्थापित करणे आवश्यक आहे जेणेकरून समान सबग्राफ दोन भिन्न नोड्सद्वारे अनुक्रमित केला जाणार नाही, ज्यामुळे टक्कर होईल. हे उपयोजन नियम वापरून केले जाऊ शकते, जे डेटाबेस शार्डिंग वापरत असल्यास, सबग्राफचा डेटा कोणत्या `shard` मध्ये संग्रहित केला जावा हे देखील निर्दिष्ट करू शकते. डिप्लॉयमेंट नियम उपग्राफ नाव आणि नेटवर्कवर जुळू शकतात जे निर्णय घेण्यासाठी उपयोजन अनुक्रमित करत आहे.
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
 
 उपयोजन नियम कॉन्फिगरेशनचे उदाहरण:
 
@@ -165,21 +165,21 @@ Any node whose --node-id matches the regular expression will be set up to only r
 
 #### शार्डिंगद्वारे डेटाबेस स्केलिंग
 
-बर्‍याच वापराच्या प्रकरणांसाठी, ग्राफ-नोड उदाहरणास समर्थन देण्यासाठी एकच पोस्टग्रेस डेटाबेस पुरेसा आहे. जेव्हा ग्राफ-नोडचे उदाहरण एका पोस्टग्रेस डेटाबेसला मागे टाकते, तेव्हा ग्राफ-नोडच्या डेटाचे स्टोरेज एकाधिक पोस्टग्रेस डेटाबेसमध्ये विभाजित करणे शक्य आहे. सर्व डेटाबेस एकत्रितपणे आलेख-नोड उदाहरणाचे स्टोअर तयार करतात. प्रत्येक वैयक्तिक डेटाबेसला शार्ड म्हणतात.
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
 
-शार्ड्सचा वापर एकाधिक डेटाबेसमध्ये सबग्राफ डिप्लॉयमेंट्स विभाजित करण्यासाठी केला जाऊ शकतो आणि डेटाबेसमध्ये क्वेरी लोड पसरवण्यासाठी प्रतिकृती वापरण्यासाठी देखील वापरला जाऊ शकतो. यामध्ये प्रत्येक `ग्राफ-नोड` ने प्रत्येक डेटाबेससाठी त्याच्या कनेक्शन पूलमध्ये ठेवल्या पाहिजेत अशा उपलब्ध डेटाबेस कनेक्शनची संख्या कॉन्फिगर करणे समाविष्ट आहे, जे अधिक सबग्राफ अनुक्रमित केले जात असल्याने वाढत्या प्रमाणात महत्त्वाचे होते.
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
 
-जेव्हा तुमचा विद्यमान डेटाबेस ग्राफ नोडवर ठेवत असलेल्या लोडसह ठेवू शकत नाही आणि जेव्हा डेटाबेस आकार वाढवणे शक्य नसेल तेव्हा शार्डिंग उपयुक्त ठरते.
+Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore.
 
-> शार्ड्ससह प्रारंभ करण्यापूर्वी एकच डेटाबेस शक्य तितका मोठा करणे सामान्यतः चांगले आहे. एक अपवाद असा आहे की जिथे क्वेरी ट्रॅफिक सबग्राफ्समध्ये खूप असमानपणे विभाजित केले जाते; उच्च-आवाजातील सबग्राफ एका शार्डमध्ये आणि इतर सर्व गोष्टी दुसर्‍यामध्ये ठेवल्या गेल्यास अशा परिस्थितीत ते नाटकीयरित्या मदत करू शकते कारण त्या सेटअपमुळे उच्च-व्हॉल्यूम सबग्राफचा डेटा db-अंतर्गत कॅशेमध्ये राहण्याची अधिक शक्यता असते. कमी-व्हॉल्यूम सबग्राफमधून आवश्यक नसलेल्या डेटाद्वारे बदला.
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
 
-कनेक्शन कॉन्फिगर करण्याच्या दृष्टीने, postgresql.conf मधील max_connections ने 400 (किंवा कदाचित 200 देखील) सेट करून प्रारंभ करा आणि store_connection_wait_time_ms आणि store_connection_checkout_count Prometheus मेट्रिक्स पहा. लक्षात येण्याजोग्या प्रतीक्षा वेळा (5ms वरील काहीही) हे एक संकेत आहे की तेथे खूप कमी कनेक्शन उपलब्ध आहेत; डेटाबेस खूप व्यस्त असल्यामुळे (जसे की उच्च CPU लोड) जास्त प्रतीक्षा वेळ देखील असेल. तथापि, डेटाबेस अन्यथा स्थिर वाटत असल्यास, उच्च प्रतीक्षा वेळ कनेक्शनची संख्या वाढवण्याची आवश्यकता दर्शवते. कॉन्फिगरेशनमध्ये, प्रत्येक ग्राफ-नोड उदाहरणे किती कनेक्शन वापरू शकतात ही एक वरची मर्यादा आहे आणि ग्राफ नोडला आवश्यक नसल्यास कनेक्शन उघडे ठेवणार नाही.
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
 
 स्टोअर कॉन्फिगरेशनबद्दल [येथे](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases) अधिक वाचा.
 
 #### समर्पित ब्लॉक अंतर्ग्रहण
 
-जर अनेक नोड्स कॉन्फिगर केले असतील तर, नवीन ब्लॉक्सच्या अंतर्ग्रहणासाठी जबाबदार असणारा एक नोड निर्दिष्ट करणे आवश्यक असेल, जेणेकरून सर्व कॉन्फिगर केलेले इंडेक्स नोड्स चेन हेडवर मतदान करत नाहीत. हे `साखळी` नेमस्पेसचा भाग म्हणून केले जाते, ब्लॉक अंतर्ग्रहणासाठी वापरले जाणारे `node_id` निर्दिष्ट करते:
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
 
 ```toml
 [chains]
@@ -188,13 +188,13 @@ ingestor = "block_ingestor_node"
 
 #### एकाधिक नेटवर्क समर्थन
 
-आलेख प्रोटोकॉल इंडेक्सिंग रिवॉर्ड्ससाठी समर्थित नेटवर्क्सची संख्या वाढवत आहे आणि असे अनेक सबग्राफ आहेत जे असमर्थित नेटवर्क अनुक्रमित करतात ज्यावर इंडेक्सर प्रक्रिया करू इच्छितो. `config.toml` फाइल अर्थपूर्ण आणि लवचिक कॉन्फिगरेशनसाठी परवानगी देते:
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
 
 - एकाधिक नेटवर्क
-- प्रति नेटवर्क एकाधिक प्रदाते (हे प्रदात्यांमध्ये लोडचे विभाजन करण्यास अनुमती देऊ शकते आणि पूर्ण नोड्स तसेच संग्रहित नोड्सच्या कॉन्फिगरेशनला देखील अनुमती देऊ शकते, दिलेल्या वर्कलोडला परवानगी दिल्यास ग्राफ नोड स्वस्त प्रदात्यांकडे प्राधान्य देतो).
-- अतिरिक्त प्रदाता तपशील, जसे की वैशिष्ट्ये, प्रमाणीकरण आणि प्रदात्याचा प्रकार (प्रायोगिक फायरहोस समर्थनासाठी)
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
 
-`[chains]` विभाग इथेरियम प्रदाते नियंत्रित करतो ज्यांना ग्राफ-नोड कनेक्ट केले जाते आणि जेथे प्रत्येक साखळीसाठी ब्लॉक आणि इतर मेटाडेटा संग्रहित केला जातो. खालील उदाहरण दोन चेन कॉन्फिगर करते, मेननेट आणि कोव्हन, जिथे मेननेटचे ब्लॉक्स vip शार्डमध्ये साठवले जातात आणि कोवनचे ब्लॉक्स प्राथमिक शार्डमध्ये साठवले जातात. मेननेट चेन दोन भिन्न प्रदाते वापरू शकते, तर कोव्हनमध्ये फक्त एक प्रदाता आहे.
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
 
 ```toml
 [chains]
@@ -210,48 +210,48 @@ shard = "primary"
 provider = [ { label = "kovan", url = "http://..", features = [] } ]
 ```
 
-प्रदाता कॉन्फिगरेशनबद्दल [येथे](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers) अधिक वाचा.
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
 
 ### पर्यावरण परिवर्तने
 
-ग्राफ नोड पर्यावरणीय चलांच्या श्रेणीचे समर्थन करते जे वैशिष्ट्ये सक्षम करू शकतात किंवा ग्राफ नोड वर्तन बदलू शकतात. हे [येथे](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md) दस्तऐवजीकरण केलेले आहेत.
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
 
 ### सतत तैनाती
 
-प्रगत कॉन्फिगरेशनसह स्केल केलेले इंडेक्सिंग सेटअप चालवणारे वापरकर्ते त्यांचे ग्राफ नोड्स Kubernetes सोबत व्यवस्थापित करण्याचा फायदा घेऊ शकतात.
+Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes.
 
 - The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
-- [Launchpad](https://docs.graphops.xyz/launchpad/intro) हे GraphOps द्वारे देखरेख केलेल्या Kubernetes वर ग्राफ प्रोटोकॉल इंडेक्सर चालवण्यासाठी टूलकिट आहे. हे ग्राफ नोड उपयोजन व्यवस्थापित करण्यासाठी हेल्म चार्ट आणि एक CLI प्रदान करते.
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
 
 ### ग्राफ नोडचे व्यवस्थापन
 
-चालू असलेला आलेख नोड (किंवा आलेख नोड्स!) दिल्यास, त्या नोड्सवर उपयोजित सबग्राफ व्यवस्थापित करण्याचे आव्हान आहे. उपग्राफ व्यवस्थापित करण्यात मदत करण्यासाठी ग्राफ नोड अनेक साधनांची श्रेणी तयार करतो.
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
 
 #### लॉगिंग
 
-ग्राफ नोडचे लॉग ग्राफ नोड आणि विशिष्ट सबग्राफच्या डीबगिंग आणि ऑप्टिमायझेशनसाठी उपयुक्त माहिती प्रदान करू शकतात. ग्राफ नोड `GRAPH_LOG` पर्यावरण व्हेरिएबलद्वारे विविध लॉग स्तरांना खालील स्तरांसह समर्थन देतो: त्रुटी, चेतावणी, माहिती, डीबग किंवा ट्रेस.
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
 
-याव्यतिरिक्त `gql` वर `GRAPH_LOG_QUERY_TIMING` सेटिंग केल्याने GraphQL क्वेरी कशा चालत आहेत याबद्दल अधिक तपशील प्रदान करते (जरी हे मोठ्या प्रमाणात लॉग तयार करेल).
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
 
 #### देखरेख & चेतावणी
 
-ग्राफ नोड डिफॉल्टनुसार 8040 पोर्टवर प्रोमिथियस एंडपॉइंटद्वारे मेट्रिक्स प्रदान करतो. या मेट्रिक्सची कल्पना करण्यासाठी ग्राफानाचा वापर केला जाऊ शकतो.
+Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics.
 
 The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
 
 #### ग्राफमन
 
-`ग्राफमन` हे ग्राफ नोडसाठी एक देखभाल साधन आहे, जे वेगवेगळ्या दैनंदिन आणि अपवादात्मक कार्यांचे निदान आणि निराकरण करण्यात मदत करते.
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
 
-ग्राफमन कमांड अधिकृत कंटेनरमध्ये समाविष्ट केली आहे आणि ती चालवण्यासाठी तुम्ही तुमच्या ग्राफ-नोड कंटेनरमध्ये डॉकर एक्झी करू शकता. यासाठी `config.toml` फाइल आवश्यक आहे.
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
 
-`graphman` आदेशांचे संपूर्ण दस्तऐवजीकरण ग्राफ नोड भांडारात उपलब्ध आहे. ग्राफ नोड `/docs` मध्ये \[/docs/graphman.md\] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) पहा
+Full documentation of `graphman` commands is available in the Graph Node repository. See \[/docs/graphman.md\] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
 
 ### सबग्राफसह कार्य करणे
 
 #### अनुक्रमणिका स्थिती API
 
-डीफॉल्टनुसार पोर्ट 8030/graphql वर उपलब्ध, अनुक्रमणिका स्थिती API वेगवेगळ्या सबग्राफसाठी अनुक्रमणिका स्थिती तपासण्यासाठी, अनुक्रमणिकेचे पुरावे तपासण्यासाठी, सबग्राफ वैशिष्ट्यांचे निरीक्षण करण्यासाठी आणि बरेच काही करण्यासाठी पद्धतींची श्रेणी उघड करते.
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
 
 संपूर्ण स्कीमा [येथे](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql) उपलब्ध आहे.
 
@@ -260,14 +260,14 @@ The indexer repository provides an [example Grafana configuration](https://githu
 There are three separate parts of the indexing process:
 
 - प्रदात्याकडून स्वारस्यपूर्ण इव्हेंट आणत आहे
-- योग्य हँडलर्ससह इव्हेंट्सवर प्रक्रिया करणे (यामध्ये राज्यासाठी साखळी कॉल करणे आणि स्टोअरमधून डेटा आणणे समाविष्ट असू शकते)
+- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
 - परिणामी डेटा स्टोअरमध्ये लिहित आहे
 
-हे टप्पे पाइपलाइन केलेले आहेत (म्हणजे ते समांतरपणे कार्यान्वित केले जाऊ शकतात), परंतु ते एकमेकांवर अवलंबून आहेत. जेथे सबग्राफ अनुक्रमणिकेसाठी मंद असतात, तेथे मूळ कारण विशिष्ट सबग्राफवर अवलंबून असेल.
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
 
 अनुक्रमणिका मंद होण्याची सामान्य कारणे:
 
-- साखळीतून संबंधित इव्हेंट शोधण्यासाठी लागणारा वेळ (`trace_filter` वर अवलंबून राहिल्यामुळे कॉल हँडलर धीमे असू शकतात)
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
 - Making large numbers of `eth_calls` as part of handlers
 - A large amount of store interaction during execution
 - A large amount of data to save to the store
@@ -276,35 +276,35 @@ There are three separate parts of the indexing process:
 - प्रदाता स्वतः साखळी डोके मागे घसरण
 - Slowness in fetching new receipts at the chain head from the provider
 
-सबग्राफ इंडेक्सिंग मेट्रिक्स इंडेक्सिंग मंदतेच्या मूळ कारणाचे निदान करण्यात मदत करू शकतात. काही प्रकरणांमध्ये, समस्या उपग्राफमध्येच असते, परंतु इतरांमध्ये, सुधारित नेटवर्क प्रदाते, कमी डेटाबेस विवाद आणि इतर कॉन्फिगरेशन सुधारणा अनुक्रमणिका कार्यप्रदर्शनात लक्षणीय सुधारणा करू शकतात.
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
 
 #### अयशस्वी सबग्राफ
 
-अनुक्रमणिका दरम्यान सबग्राफ अयशस्वी होऊ शकतात, त्यांना अनपेक्षित डेटा आढळल्यास, काही घटक अपेक्षेप्रमाणे कार्य करत नसल्यास किंवा इव्हेंट हँडलर किंवा कॉन्फिगरेशनमध्ये काही बग असल्यास. अपयशाचे दोन सामान्य प्रकार आहेत:
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
 
 - Deterministic failures: these are failures which will not be resolved with retries
-- नॉन-डिटरमिनिस्टिक अपयश: हे प्रदात्याशी संबंधित समस्या किंवा काही अनपेक्षित ग्राफ नोड त्रुटींमुळे असू शकतात. जेव्हा नॉन-डिटरमिनिस्टिक अपयश येते, तेव्हा ग्राफ नोड अयशस्वी हँडलरचा पुन्हा प्रयत्न करेल, कालांतराने बॅक ऑफ होईल.
+- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
 
-काही प्रकरणांमध्ये इंडेक्सरद्वारे बिघाडाचे निराकरण केले जाऊ शकते (उदाहरणार्थ त्रुटी योग्य प्रकारचा प्रदाता नसल्यामुळे, आवश्यक प्रदाता जोडल्याने अनुक्रमणिका सुरू ठेवता येईल). तथापि, इतरांमध्ये, सबग्राफ कोडमध्ये बदल आवश्यक आहे.
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
 
-> निर्धारक अपयशांना "अंतिम" मानले जाते, अयशस्वी ब्लॉकसाठी अनुक्रमणिकेचा पुरावा व्युत्पन्न केला जातो, तर नॉन-डिटरमिनिस्टिक अपयश असे नसतात, कारण सबग्राफ "अनफल" आणि अनुक्रमणिका सुरू ठेवू शकतो. काही प्रकरणांमध्ये, नॉन-डिटरमिनिस्टिक लेबल चुकीचे आहे, आणि सबग्राफ कधीही त्रुटीवर मात करणार नाही; अशा अपयशांचा ग्राफ नोड रेपॉजिटरीवरील समस्या म्हणून अहवाल द्यावा.
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-determinstic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
 
 #### ब्लॉक आणि कॉल कॅशे
 
-प्रदात्याकडून रीफेचिंग जतन करण्यासाठी ग्राफ नोड स्टोअरमधील काही डेटा कॅश करतो. `eth_calls` च्या परिणामांप्रमाणेच ब्लॉक्स कॅशे केले जातात (नंतरचे विशिष्ट ब्लॉक म्हणून कॅश केले जातात). हे कॅशिंग थोड्याशा बदललेल्या सबग्राफच्या "रीसिंकिंग" दरम्यान अनुक्रमणिकेची गती नाटकीयरित्या वाढवू शकते.
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
 
 However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
 
 If a block cache inconsistency is suspected, such as a tx receipt missing event:
 
 1. `graphman chain list` to find the chain name.
-2. `ग्राफमन चेन चेक-ब्लॉक <CHAIN> बाय-नंबर <NUMBER>` कॅशे केलेला ब्लॉक प्रदात्याशी जुळतो की नाही हे तपासेल आणि तसे नसल्यास कॅशेमधून ब्लॉक हटवेल.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
    1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
    2. If the block matches the provider, then the issue can be debugged directly against the provider.
 
 #### समस्या आणि त्रुटींची चौकशी करणे
 
-एकदा सबग्राफ इंडेक्स केला गेला की, इंडेक्सर्स सबग्राफच्या समर्पित क्वेरी एंडपॉइंटद्वारे क्वेरी सर्व्ह करण्याची अपेक्षा करू शकतात. जर इंडेक्सर महत्त्वपूर्ण क्वेरी व्हॉल्यूम प्रदान करण्याची आशा करत असेल तर, समर्पित क्वेरी नोडची शिफारस केली जाते आणि खूप जास्त क्वेरी व्हॉल्यूम असल्यास, इंडेक्सर्स प्रतिकृती शार्ड्स कॉन्फिगर करू शकतात जेणेकरुन क्वेरींचा अनुक्रमणिका प्रक्रियेवर परिणाम होणार नाही.
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
 
 However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
 
@@ -312,21 +312,21 @@ There is not one "silver bullet", but a range of tools for preventing, diagnosin
 
 ##### क्वेरी कॅशिंग
 
-ग्राफ नोड डीफॉल्टनुसार GraphQL क्वेरी कॅश करते, जे डेटाबेस लोड लक्षणीयरीत्या कमी करू शकते. हे पुढे `GRAPH_QUERY_CACHE_BLOCKS` आणि `GRAPH_QUERY_CACHE_MAX_MEM` सेटिंग्जसह कॉन्फिगर केले जाऊ शकते - [येथे](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching) अधिक वाचा.
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
 
 ##### प्रश्नांचे विश्लेषण करत आहे
 
-समस्याप्रधान क्वेरी बहुतेक वेळा दोनपैकी एका मार्गाने समोर येतात. काही प्रकरणांमध्ये, वापरकर्ते स्वतः तक्रार करतात की दिलेली क्वेरी धीमी आहे. अशावेळी मंदपणाच्या कारणाचे निदान करणे हे आव्हान असते - मग ती सामान्य समस्या असो, किंवा त्या सबग्राफ किंवा क्वेरीशी संबंधित असो. आणि मग नक्कीच, शक्य असल्यास, निराकरण करण्यासाठी.
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
 
-इतर प्रकरणांमध्ये, ट्रिगर हा क्वेरी नोडवर उच्च मेमरी वापर असू शकतो, अशा परिस्थितीत समस्या निर्माण करणारी क्वेरी ओळखण्याचे आव्हान प्रथम आहे.
+In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
 
-इंडेक्सर्स ग्राफ नोडच्या क्वेरी लॉगची प्रक्रिया आणि सारांश देण्यासाठी [qlog](https://github.com/graphprotocol/qlog/) वापरू शकतात. `GRAPH_LOG_QUERY_TIMING` मंद क्वेरी ओळखण्यात आणि डीबग करण्यात मदत करण्यासाठी देखील सक्षम केले जाऊ शकते.
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
 
-धीमे क्वेरी दिल्यास, इंडेक्सर्सकडे काही पर्याय आहेत. समस्याप्रधान क्वेरी पाठविण्याच्या खर्चात लक्षणीय वाढ करण्यासाठी अर्थातच ते त्यांच्या किंमतीचे मॉडेल बदलू शकतात. यामुळे त्या क्वेरीची वारंवारता कमी होऊ शकते. तथापि, हे सहसा समस्येचे मूळ कारण सोडवत नाही.
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
 
 ##### खात्यासारखे ऑप्टिमायझेशन
 
-डाटाबेस सारणी जे संस्था संग्रहित करतात ते साधारणपणे दोन प्रकारात येतात: 'व्यवहारासारखे', जेथे संस्था, एकदा तयार केल्या गेल्या, कधीही अद्यतनित केल्या जात नाहीत, म्हणजे, ते आर्थिक व्यवहारांच्या सूचीसारखे काहीतरी संग्रहित करतात आणि 'खाते-सारखे' जेथे संस्था बर्‍याचदा अपडेट केले जातात, म्हणजे, ते आर्थिक खात्यांसारखे काहीतरी संग्रहित करतात जे प्रत्येक वेळी व्यवहार रेकॉर्ड केल्यावर सुधारित केले जातात. खात्यासारख्या सारण्यांचे वैशिष्ट्य असे आहे की त्यामध्ये मोठ्या संख्येने अस्तित्व आवृत्त्या आहेत, परंतु तुलनेने काही वेगळे घटक आहेत. बर्‍याचदा, अशा सारण्यांमध्ये भिन्न घटकांची संख्या एकूण पंक्तींच्या 1% असते (संस्था आवृत्ती)
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
 
 खात्यासारख्या सारण्यांसाठी, `ग्राफ-नोड` क्वेरी व्युत्पन्न करू शकतात जे पोस्टग्रेस एवढ्या उच्च बदलासह डेटा कसा संग्रहित करते याच्या तपशीलाचा फायदा घेतात, म्हणजे अलीकडील ब्लॉक्ससाठी सर्व आवृत्त्या आहेत. अशा सारणीसाठी एकूण स्टोरेजचा एक छोटा उपविभाग.
 
@@ -334,7 +334,7 @@ There is not one "silver bullet", but a range of tools for preventing, diagnosin
 
 सर्वसाधारणपणे, ज्या सारण्यांमध्ये भिन्न घटकांची संख्या एकूण पंक्ती/संस्थेच्या आवृत्त्यांच्या 1% पेक्षा कमी आहे ते खाते-समान ऑप्टिमायझेशनसाठी चांगले उमेदवार आहेत. जेव्हा `ग्राफमन आकडेवारी दर्शविते` चे आउटपुट सूचित करते की टेबलला या ऑप्टिमायझेशनचा फायदा होऊ शकतो, तेव्हा `ग्राफमन आकडेवारी <sgdNNN> <table>` सारणीची संपूर्ण गणना करेल - ते धीमे असू शकते, परंतु एकूण घटक आवृत्त्यांमधील भिन्न घटकांच्या गुणोत्तराचे अचूक माप देते.
 
-एकदा टेबल खात्यासारखे असल्याचे निश्चित केले गेले की, `ग्राफमन स्टॅट्स अकाउंट-समान <sgdNNN>.<table>` चालवल्याने त्या टेबलवरील क्वेरींसाठी खाते-सारखे ऑप्टिमायझेशन चालू होईल. ऑप्टिमायझेशन `graphman stats account-like --clear <sgdNNN>.<table>` सह पुन्हा बंद केले जाऊ शकते हे ऑप्टिमायझेशन चालू केले आहे हे लक्षात येण्यासाठी क्वेरी नोड्ससाठी 5 मिनिटे लागतात किंवा बंद. ऑप्टिमायझेशन चालू केल्यानंतर, बदलामुळे त्या टेबलसाठी प्रश्नांची गती कमी होत नाही हे सत्यापित करणे आवश्यक आहे. तुम्ही पोस्टग्रेसचे निरीक्षण करण्यासाठी Grafana कॉन्फिगर केले असल्यास, स्लो क्वेरी `pg_stat_activity`मध्‍ये मोठ्या संख्येने दिसतील, काही सेकंद घेतील. अशा परिस्थितीत, ऑप्टिमायझेशन पुन्हा बंद करणे आवश्यक आहे.
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
 
 युनिस्‍ॅप सारख्या सबग्राफसाठी, `जोडी` आणि `टोकन` सारण्या या ऑप्टिमायझेशनसाठी प्रमुख उमेदवार आहेत आणि डेटाबेस लोडवर नाटकीय प्रभाव टाकू शकतात.
 

From f5e81dc631a0a1e0450c89b19f254e355d5e4a64 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:08 -0500
Subject: [PATCH 0277/3820] New translations operating-graph-node.mdx (Hindi)

---
 website/pages/hi/operating-graph-node.mdx | 182 +++++++++++-----------
 1 file changed, 91 insertions(+), 91 deletions(-)

diff --git a/website/pages/hi/operating-graph-node.mdx b/website/pages/hi/operating-graph-node.mdx
index d8707dae894c..ac2e211ca271 100644
--- a/website/pages/hi/operating-graph-node.mdx
+++ b/website/pages/hi/operating-graph-node.mdx
@@ -2,19 +2,19 @@
 title: ग्राफ नोड का परिचालन
 ---
 
-ग्राफ़ नोड वह घटक है जो उप-अनुच्छेदों को अनुक्रमित करता है, और परिणामी डेटा को ग्राफ़िकल एपीआई के माध्यम से क्वेरी के लिए उपलब्ध कराता है। इस तरह यह इंडेक्सर स्टैक के लिए केंद्रीय है, और एक सफल इंडेक्सर चलाने के लिए ग्राफ नोड का सही संचालन महत्वपूर्ण है।
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
 
-यह ग्राफ़ नोड का एक प्रासंगिक अवलोकन प्रदान करता है, और इंडेक्सर्स के लिए उपलब्ध कुछ और उन्नत विकल्प प्रदान करता है। विस्तृत दस्तावेज़ और निर्देश [ग्राफ़ नोड रिपॉजिटरी](https://github.com/graphprotocol/graph-node) में देखे जा सकते हैं।
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
 
 ## Graph Node
 
-[ग्राफ़ नोड](https://github.com/graphprotocol/graph-node) ग्राफ़ नेटवर्क पर सबग्राफ़ को इंडेक्स करने, ब्लॉकचेन क्लाइंट से कनेक्ट करने, सबग्राफ़ को इंडेक्स करने और इंडेक्स किए गए डेटा को उपलब्ध कराने के लिए संदर्भ कार्यान्वयन है पूछताछ करने के लिए।
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
 
-ग्राफ़ नोड (और संपूर्ण इंडेक्सर स्टैक) को नंगे धातु, या क्लाउड वातावरण में चलाया जा सकता है। सेंट्रल इंडेक्सिंग कंपोनेंट का यह लचीलापन द ग्राफ प्रोटोकॉल की मजबूती के लिए महत्वपूर्ण है। इसी तरह, ग्राफ़ नोड [स्रोत से निर्मित](https://github.com/graphprotocol/graph-node) हो सकता है, या इंडेक्सर [डॉकर छवियां प्रदान करता है](https:// में से किसी एक का उपयोग कर सकते हैं। hub.docker.com/r/graphprotocol/graph-node)।
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
 
 ### पोस्टग्रेएसक्यूएल डेटाबेस
 
-ग्राफ नोड के लिए मुख्य स्टोर, यह वह जगह है जहां सबग्राफ डेटा संग्रहीत किया जाता है, साथ ही सबग्राफ के बारे में मेटाडेटा, और सबग्राफ-एग्नोस्टिक नेटवर्क डेटा जैसे ब्लॉक कैश, और eth_call कैश।
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
 
 ### नेटवर्क क्लाइंट
 
@@ -26,11 +26,11 @@ title: ग्राफ नोड का परिचालन
 
 ### आईपीएफएस नोड्स
 
-सबग्राफ परिनियोजन मेटाडेटा IPFS नेटवर्क पर संग्रहीत है। सबग्राफ मैनिफ़ेस्ट और सभी लिंक की गई फ़ाइलों को लाने के लिए सबग्राफ़ परिनियोजन के दौरान ग्राफ़ नोड मुख्य रूप से IPFS नोड तक पहुँचता है। नेटवर्क इंडेक्सर्स को अपने स्वयं के IPFS नोड को होस्ट करने की आवश्यकता नहीं है। नेटवर्क के लिए IPFS नोड https://ipfs.network.thegraph.com पर होस्ट किया गया है।
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
 
 ### प्रोमेथियस मेट्रिक्स सर्वर
 
-निगरानी और रिपोर्टिंग को सक्षम करने के लिए, ग्राफ़ नोड वैकल्पिक रूप से मेट्रिक्स को प्रोमेथियस मेट्रिक्स सर्वर पर लॉग कर सकता है।
+To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
 
 ### स्रोत से प्रारंभ करना
 
@@ -69,33 +69,33 @@ cargo run -p graph-node --release -- \
   --ipfs https://ipfs.network.thegraph.com
 ```
 
-### कुबेरनेट्स के साथ शुरुआत करना
+### Getting started with Kubernetes
 
-एक पूर्ण कुबेरनेट्स उदाहरण विन्यास [इंडेक्सर रिपॉजिटरी](https://github.com/graphprotocol/indexer/tree/main/k8s) में पाया जा सकता है।
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
 
 ### Ports
 
-जब यह चल रहा होता है तो ग्राफ़ नोड निम्नलिखित पोर्ट को उजागर करता है:
+When it is running Graph Node exposes the following ports:
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(सबग्राफ प्रश्नों के लिए) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(सबग्राफ सब्सक्रिप्शन के लिए) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(तैनाती के प्रबंधन के लिए) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                                  | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | -------------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(सबग्राफ प्रश्नों के लिए) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(सबग्राफ सब्सक्रिप्शन के लिए)      | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(तैनाती के प्रबंधन के लिए)           | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                             | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                       | /metrics                                             | --metrics-port    | -                    |
 
 > **महत्वपूर्ण**: बंदरगाहों को सार्वजनिक रूप से उजागर करने के बारे में सावधान रहें - **प्रशासन बंदरगाहों** को बंद रखा जाना चाहिए। इसमें ग्राफ़ नोड JSON-RPC समापन बिंदु शामिल है।
 
-## उन्नत ग्राफ़ नोड कॉन्फ़िगरेशन
+## Advanced Graph Node configuration
 
-अपने सरलतम रूप में, ग्राफ़ नोड को ग्राफ़ नोड, एक एकल PostgreSQL डेटाबेस, एक IPFS नोड, और नेटवर्क क्लाइंट के रूप में संचालित किया जा सकता है, जैसा कि उप-अनुच्छेदों द्वारा अनुक्रमित किया जाना आवश्यक है।
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
 
-उन ग्राफ़ नोड्स का समर्थन करने के लिए कई ग्राफ़ नोड्स और कई डेटाबेस जोड़कर इस सेटअप को क्षैतिज रूप से बढ़ाया जा सकता है। उन्नत उपयोगकर्ता `config.toml` फ़ाइल और ग्राफ़ नोड के पर्यावरण चर के माध्यम से ग्राफ़ नोड की कुछ क्षैतिज स्केलिंग क्षमताओं के साथ-साथ कुछ अधिक उन्नत कॉन्फ़िगरेशन विकल्पों का लाभ उठाना चाह सकते हैं।
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
 
 ### `config.toml`
 
-एक [TOML](https://toml.io/en/) कॉन्फ़िगरेशन फ़ाइल का उपयोग CLI में प्रदर्शित कॉन्फ़िगरेशन की तुलना में अधिक जटिल कॉन्फ़िगरेशन सेट करने के लिए किया जा सकता है। फ़ाइल का स्थान --config कमांड लाइन स्विच के साथ दिया जाता है।
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
 
 > कॉन्फ़िगरेशन फ़ाइल का उपयोग करते समय, --postgres-url, --postgres-secondary-hosts, और --postgres-host-weights विकल्पों का उपयोग करना संभव नहीं है।
 
@@ -110,19 +110,19 @@ connection="<.. postgres-url argument ..>"
 indexers = [ "<.. list of all indexing nodes ..>" ]
 ```
 
-`config.toml` का पूरा दस्तावेज़ [ग्राफ़ नोड में पाया जा सकता है डॉक्स](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md)।
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
 
-#### एकाधिक ग्राफ नोड्स
+#### Multiple Graph Nodes
 
 Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
 
 > ध्यान दें कि एक ही डेटाबेस का उपयोग करने के लिए कई ग्राफ़ नोड्स को कॉन्फ़िगर किया जा सकता है, जिसे स्वयं शार्डिंग के माध्यम से क्षैतिज रूप से बढ़ाया जा सकता है।
 
-#### परिनियोजन नियम
+#### Deployment rules
 
-कई ग्राफ़ नोड्स को देखते हुए, नए सबग्राफ की तैनाती का प्रबंधन करना आवश्यक है ताकि एक ही सबग्राफ को दो अलग-अलग नोड्स द्वारा अनुक्रमित नहीं किया जा सके, जिससे टकराव हो। यह परिनियोजन नियमों का उपयोग करके किया जा सकता है, जो यह भी निर्दिष्ट कर सकता है कि यदि डेटाबेस शार्डिंग का उपयोग किया जा रहा है, तो `shard` को सबग्राफ के डेटा में संग्रहीत किया जाना चाहिए। डिप्लॉयमेंट नियम सबग्राफ नाम और उस नेटवर्क से मेल खा सकते हैं जिसे निर्णय लेने के लिए डिप्लॉयमेंट इंडेक्स कर रहा है।
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
 
-उदाहरण परिनियोजन नियम कॉन्फ़िगरेशन:
+Example deployment rule configuration:
 
 ```toml
 [deployment]
@@ -150,51 +150,51 @@ indexers = [
   ]
 ```
 
-परिनियोजन नियमों के बारे में [यहां](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment) अधिक पढ़ें।
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
 
-#### समर्पित क्वेरी नोड्स
+#### Dedicated query nodes
 
-कॉन्फ़िगरेशन फ़ाइल में निम्नलिखित को शामिल करके नोड्स को स्पष्ट रूप से क्वेरी नोड होने के लिए कॉन्फ़िगर किया जा सकता है:
+Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
 
 ```toml
 [general]
 query = "<regular expression>"
 ```
 
-कोई भी नोड जिसका --node-id रेगुलर एक्सप्रेशन से मेल खाता है, केवल प्रश्नों का जवाब देने के लिए सेट किया जाएगा।
+Any node whose --node-id matches the regular expression will be set up to only respond to queries.
 
-#### शार्डिंग के माध्यम से डाटाबेस स्केलिंग
+#### Database scaling via sharding
 
-अधिकांश उपयोग के मामलों के लिए, एक एकल पोस्टग्रेज डेटाबेस ग्राफ-नोड उदाहरण का समर्थन करने के लिए पर्याप्त है। जब एक ग्राफ-नोड उदाहरण एकल पोस्टग्रेज डेटाबेस से आगे निकल जाता है, तो ग्राफ-नोड के डेटा के भंडारण को कई पोस्टग्रेज डेटाबेस में विभाजित करना संभव है। सभी डेटाबेस मिलकर ग्राफ़-नोड इंस्टेंस का स्टोर बनाते हैं। प्रत्येक व्यक्तिगत डेटाबेस को शार्ड कहा जाता है।
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
 
-कई डेटाबेस में सबग्राफ परिनियोजन को विभाजित करने के लिए शार्ड्स का उपयोग किया जा सकता है, और डेटाबेस में क्वेरी लोड को फैलाने के लिए प्रतिकृतियों का उपयोग करने के लिए भी उपयोग किया जा सकता है। इसमें उपलब्ध डेटाबेस कनेक्शनों की संख्या को कॉन्फ़िगर करना शामिल है, प्रत्येक ग्राफ-नोड को प्रत्येक डेटाबेस के लिए अपने कनेक्शन पूल में रखना चाहिए, जो तेजी से महत्वपूर्ण हो जाता है क्योंकि अधिक उप-अनुच्छेदों को अनुक्रमित किया जा रहा है।
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
 
 शेयरिंग तब उपयोगी हो जाती है जब आपका मौजूदा डेटाबेस ग्राफ़ नोड द्वारा डाले गए भार के साथ नहीं रह सकता है, और जब डेटाबेस का आकार बढ़ाना संभव नहीं होता है।
 
-> शार्क से शुरू करने से पहले, आम तौर पर जितना संभव हो उतना बड़ा डेटाबेस बनाना बेहतर होता है। एक अपवाद वह है जहां क्वेरी ट्रैफ़िक सबग्राफ के बीच असमान रूप से विभाजित होता है; उन परिस्थितियों में यह नाटकीय रूप से मदद कर सकता है यदि उच्च मात्रा वाले सबग्राफ को एक शार्ड में रखा जाता है और बाकी सब कुछ दूसरे में रखा जाता है क्योंकि यह सेटअप अधिक संभावना बनाता है कि उच्च मात्रा वाले सबग्राफ के लिए डेटा डीबी-आंतरिक कैश में रहता है और नहीं करता है उन डेटा से प्रतिस्थापित हो जाएं जिनकी कम मात्रा वाले सबग्राफ से उतनी आवश्यकता नहीं है।
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
 
-कनेक्शन कॉन्फ़िगर करने के मामले में, postgresql.conf में max_connections से 400 (या शायद 200) पर सेट करें और store_connection_wait_time_ms और store_connection_checkout_count प्रोमेथियस मेट्रिक्स देखें। ध्यान देने योग्य प्रतीक्षा समय (5ms से ऊपर कुछ भी) एक संकेत है कि बहुत कम कनेक्शन उपलब्ध हैं; उच्च प्रतीक्षा समय डेटाबेस के बहुत व्यस्त होने (जैसे उच्च CPU लोड) के कारण भी होगा। हालाँकि यदि डेटाबेस अन्यथा स्थिर लगता है, तो उच्च प्रतीक्षा समय कनेक्शन की संख्या बढ़ाने की आवश्यकता का संकेत देता है। कॉन्फ़िगरेशन में, प्रत्येक ग्राफ़-नोड उदाहरण कितने कनेक्शन का उपयोग कर सकता है, यह एक ऊपरी सीमा है, और ग्राफ़ नोड कनेक्शन को खुला नहीं रखेगा यदि इसकी आवश्यकता नहीं है।
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
 
-स्टोर कॉन्फ़िगरेशन के बारे में [यहां](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases) अधिक पढ़ें।
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
 
-#### समर्पित ब्लॉक अंतर्ग्रहण
+#### Dedicated block ingestion
 
-यदि कई नोड्स कॉन्फ़िगर किए गए हैं, तो एक नोड को निर्दिष्ट करना आवश्यक होगा जो नए ब्लॉकों के अंतर्ग्रहण के लिए जिम्मेदार है, ताकि सभी कॉन्फ़िगर किए गए इंडेक्स नोड्स चेन हेड को पोल न करें। यह `चेन्स` नामस्थान के हिस्से के रूप में किया जाता है, ब्लॉक अंतर्ग्रहण के लिए उपयोग किए जाने वाले `node_id` को निर्दिष्ट करता है:
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
 
 ```toml
 [chains]
 ingestor = "block_ingestor_node"
 ```
 
-#### कई नेटवर्क का समर्थन करना
+#### Supporting multiple networks
 
-ग्राफ़ प्रोटोकॉल इंडेक्सिंग पुरस्कारों के लिए समर्थित नेटवर्क की संख्या बढ़ा रहा है, और ऐसे कई सबग्राफ मौजूद हैं जो असमर्थित नेटवर्क को इंडेक्स करते हैं जिन्हें एक इंडेक्सर प्रोसेस करना चाहता है। `config.toml` फ़ाइल अभिव्यक्तिपूर्ण और लचीले कॉन्फ़िगरेशन की अनुमति देती है:
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
 
-- एकाधिक नेटवर्क
-- प्रति नेटवर्क एकाधिक प्रदाता (यह प्रदाताओं में लोड को विभाजित करने की अनुमति दे सकता है, और पूर्ण नोड्स के साथ-साथ आर्काइव नोड्स के कॉन्फ़िगरेशन की अनुमति भी दे सकता है, यदि कोई वर्कलोड अनुमति देता है तो ग्राफ नोड सस्ता प्रदाताओं को प्राथमिकता देता है)।
-- अतिरिक्त प्रदाता विवरण, जैसे सुविधाएँ, प्रमाणीकरण और प्रदाता का प्रकार (प्रायोगिक फ़ायरहोज़ समर्थन के लिए)
+- Multiple networks
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
 
-`[chains]` अनुभाग एथेरियम प्रदाताओं को नियंत्रित करता है जो ग्राफ़-नोड से कनेक्ट होते हैं, और जहां प्रत्येक श्रृंखला के लिए ब्लॉक और अन्य मेटाडेटा संग्रहीत होते हैं। निम्न उदाहरण दो श्रृंखलाओं, मेननेट और कोवन को कॉन्फ़िगर करता है, जहां मेननेट के ब्लॉक वीआईपी शार्ड में संग्रहीत होते हैं और कोवन के लिए ब्लॉक प्राथमिक शार्ड में संग्रहीत होते हैं। मेननेट श्रृंखला दो अलग-अलग प्रदाताओं का उपयोग कर सकती है, जबकि कोवन में केवल एक प्रदाता होता है।
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
 
 ```toml
 [chains]
@@ -210,34 +210,34 @@ shard = "primary"
 provider = [ { label = "kovan", url = "http://..", features = [] } ]
 ```
 
-प्रदाता कॉन्फ़िगरेशन के बारे में [यहां](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers) अधिक पढ़ें।
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
 
 ### Environment variables
 
-ग्राफ़ नोड पर्यावरण चर की एक श्रृंखला का समर्थन करता है जो सुविधाओं को सक्षम कर सकता है, या ग्राफ़ नोड व्यवहार को बदल सकता है। ये [यहां](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md) प्रलेखित हैं।
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
 
 ### Continuous deployment
 
 जो उपयोगकर्ता उन्नत कॉन्फ़िगरेशन के साथ एक स्केल्ड इंडेक्सिंग सेटअप का संचालन कर रहे हैं, वे कुबेरनेट्स के साथ अपने ग्राफ़ नोड्स को प्रबंधित करने से लाभान्वित हो सकते हैं।
 
-- इंडेक्सर रिपॉजिटरी में [उदाहरण Kubernetes संदर्भ](https://github.com/graphprotocol/indexer/tree/main/k8s) है
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
 - [लॉन्चपैड](https://docs.graphops.xyz/launchpad/intro) ग्राफऑप्स द्वारा संचालित कुबेरनेट्स पर ग्राफ प्रोटोकॉल इंडेक्सर चलाने के लिए एक टूलकिट है। यह ग्राफ नोड परिनियोजन का प्रबंधन करने के लिए हेल्म चार्ट और सीएलआई का एक सेट प्रदान करता है।
 
-### ग्राफ नोड का प्रबंधन
+### Managing Graph Node
 
-चल रहे ग्राफ़ नोड (या ग्राफ़ नोड्स!) को देखते हुए, चुनौती उन नोड्स में तैनात सबग्राफ को प्रबंधित करने की है। ग्राफ़ नोड उप-अनुच्छेदों को प्रबंधित करने में मदद करने के लिए उपकरणों की एक श्रृंखला पेश करता है।
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
 
 #### लॉगिंग
 
-ग्राफ़ नोड के लॉग ग्राफ़ नोड और विशिष्ट सबग्राफ के डिबगिंग और अनुकूलन के लिए उपयोगी जानकारी प्रदान कर सकते हैं। ग्राफ़ नोड निम्न स्तरों के साथ `GRAPH_LOG` पर्यावरण चर के माध्यम से विभिन्न लॉग स्तरों का समर्थन करता है: त्रुटि, चेतावनी, सूचना, डीबग या ट्रेस।
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
 
 इसके अलावा `GRAPH_LOG_QUERY_TIMING` को `gql` पर सेट करना इस बारे में अधिक विवरण प्रदान करता है कि ग्राफ़क्यूएल क्वेरीज़ कैसे चल रही हैं (हालांकि यह बड़ी मात्रा में लॉग उत्पन्न करेगा)।
 
-#### निगरानी & चेतावनी
+#### Monitoring & alerting
 
 ग्राफ़ नोड डिफ़ॉल्ट रूप से 8040 पोर्ट पर प्रोमेथियस एंडपॉइंट के माध्यम से मेट्रिक्स प्रदान करता है। इन मेट्रिक्स की कल्पना करने के लिए ग्राफाना का उपयोग किया जा सकता है।
 
-इंडेक्सर रिपॉजिटरी [ग्राफाना कॉन्फ़िगरेशन का उदाहरण](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml) प्रदान करता है।
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
 
 #### Graphman
 
@@ -245,66 +245,66 @@ provider = [ { label = "kovan", url = "http://..", features = [] } ]
 
 ग्राफ़मैन कमांड आधिकारिक कंटेनरों में शामिल है, और आप इसे चलाने के लिए अपने ग्राफ़-नोड कंटेनर में docker exec कर सकते हैं। इसके लिए `config.toml` फ़ाइल की आवश्यकता होती है।
 
-`ग्राफ़मैन` कमांड का पूरा दस्तावेज़ ग्राफ़ नोड रिपॉजिटरी में उपलब्ध है। देखें \[/docs/graphman.md\] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) ग्राफ़ नोड `/docs` में
+Full documentation of `graphman` commands is available in the Graph Node repository. See \[/docs/graphman.md\] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
 
 ### सबग्राफ के साथ काम करना
 
 #### अनुक्रमण स्थिति एपीआई
 
-डिफ़ॉल्ट रूप से पोर्ट 8030/ग्राफ़िकल पर उपलब्ध, इंडेक्सिंग स्टेटस एपीआई विभिन्न सबग्राफ के लिए इंडेक्सिंग स्टेटस की जाँच करने, इंडेक्सिंग के प्रूफ़ की जाँच करने, सबग्राफ़ सुविधाओं का निरीक्षण करने आदि के लिए कई तरीकों को उजागर करता है।
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
 
-पूरा स्कीमा [यहां](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql) उपलब्ध है।
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
 
-#### अनुक्रमण प्रदर्शन
+#### Indexing performance
 
-अनुक्रमण प्रक्रिया के तीन अलग-अलग भाग हैं:
+There are three separate parts of the indexing process:
 
-- प्रदाता से रुचि के इवेंट लाए जा रहे हैं
+- Fetching events of interest from the provider
 - उपयुक्त संचालकों के साथ घटनाओं को संसाधित करना (इसमें राज्य के लिए श्रृंखला को कॉल करना और स्टोर से डेटा प्राप्त करना शामिल हो सकता है)
-- परिणामी डेटा को स्टोर पर लिखना
+- Writing the resulting data to the store
 
-इन चरणों को पाइपलाइन किया गया है (अर्थात इन्हें समानांतर में निष्पादित किया जा सकता है), लेकिन वे एक दूसरे पर निर्भर हैं। जहां सबग्राफ इंडेक्स के लिए धीमे होते हैं, अंतर्निहित कारण विशिष्ट सबग्राफ पर निर्भर करेगा।
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
 
-अनुक्रमण धीमा होने के सामान्य कारण:
+Common causes of indexing slowness:
 
-- श्रृंखला से प्रासंगिक घटनाओं को खोजने में लगने वाला समय (विशेष रूप से कॉल हैंडलर धीमा हो सकता है, `trace_filter` पर निर्भरता को देखते हुए)
-- हैंडलर्स के हिस्से के रूप में बड़ी संख्या में `eth_calls` बनाना
-- निष्पादन के दौरान बड़ी मात्रा में स्टोर इंटरैक्शन
-- स्टोर में सहेजने के लिए बड़ी मात्रा में डेटा
-- संसाधित करने के लिए बड़ी संख्या में ईवेंट
-- जलाने के लिए बड़ी संख्या में व्याकुलता
-- प्रदाता स्वयं चेन हेड के पीछे पड़ रहा है
-- प्रदाता से चेन हेड पर नई रसीदें प्राप्त करने में धीमापन
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- A large number of events to process
+- Slow database connection time, for crowded nodes
+- The provider itself falling behind the chain head
+- Slowness in fetching new receipts at the chain head from the provider
 
-सबग्राफ इंडेक्सिंग मेट्रिक्स इंडेक्सिंग धीमेपन के मूल कारण का निदान करने में मदद कर सकते हैं। कुछ मामलों में, समस्या सबग्राफ में ही निहित है, लेकिन अन्य में, बेहतर नेटवर्क प्रदाता, कम डेटाबेस विवाद और अन्य कॉन्फ़िगरेशन सुधार इंडेक्सिंग प्रदर्शन में स्पष्ट रूप से सुधार कर सकते हैं।
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
 
 #### विफल सबग्राफ
 
-इंडेक्सिंग सबग्राफ के दौरान विफल हो सकता है, यदि वे अप्रत्याशित डेटा का सामना करते हैं, कुछ घटक अपेक्षित रूप से काम नहीं कर रहे हैं, या यदि ईवेंट हैंडलर या कॉन्फ़िगरेशन में कुछ बग है। विफलता के दो सामान्य प्रकार हैं:
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
 
-- नियतात्मक विफलताएँ: ये ऐसी विफलताएँ हैं जिन्हें पुनर्प्रयास से हल नहीं किया जा सकता है
+- Deterministic failures: these are failures which will not be resolved with retries
 - गैर-नियतात्मक विफलताएँ: ये प्रदाता के साथ समस्याओं या कुछ अप्रत्याशित ग्राफ़ नोड त्रुटि के कारण हो सकती हैं। जब एक गैर-नियतात्मक विफलता होती है, तो ग्राफ़ नोड समय के साथ पीछे हटते हुए विफल हैंडलर को फिर से प्रयास करेगा।
 
-कुछ मामलों में इंडेक्सर द्वारा विफलता को हल किया जा सकता है (उदाहरण के लिए यदि त्रुटि सही प्रकार का प्रदाता नहीं होने का परिणाम है, तो आवश्यक प्रदाता जोड़ने से अनुक्रमण जारी रहेगा)। हालाँकि अन्य में, सबग्राफ कोड में बदलाव की आवश्यकता होती है।
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
 
-> नियतात्मक विफलताओं को "अंतिम" माना जाता है, असफल ब्लॉक के लिए उत्पन्न अनुक्रमण के प्रमाण के साथ, जबकि गैर-निर्धारक विफलताओं को नहीं माना जाता है, क्योंकि सबग्राफ "असफल" और अनुक्रमण जारी रखने का प्रबंधन कर सकता है। कुछ मामलों में, गैर-नियतात्मक लेबल गलत है, और सबग्राफ कभी भी त्रुटि को दूर नहीं करेगा; ऐसी विफलताओं को ग्राफ़ नोड रिपॉजिटरी पर मुद्दों के रूप में रिपोर्ट किया जाना चाहिए।
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-determinstic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
 
 #### कैश को ब्लॉक और कॉल करें
 
-प्रदाता से रीफ़ेचिंग को बचाने के लिए ग्राफ़ नोड स्टोर में कुछ डेटा को कैश करता है। ब्लॉक को कैश किया जाता है, जैसा कि `eth_calls` के परिणाम होते हैं (बाद वाले को एक विशिष्ट ब्लॉक के रूप में कैश किया जाता है)। यह कैशिंग थोड़े बदले हुए सबग्राफ के "रीसिंकिंग" के दौरान अनुक्रमण गति को नाटकीय रूप से बढ़ा सकती है।
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
 
 हालाँकि, कुछ उदाहरणों में, यदि एथेरियम नोड ने कुछ अवधि के लिए गलत डेटा प्रदान किया है, तो यह कैश में अपना रास्ता बना सकता है, जिससे गलत डेटा या विफल सबग्राफ हो सकते हैं। इस मामले में इंडेक्सर जहरीली कैश को साफ करने के लिए `ग्राफमैन` का उपयोग कर सकते हैं, और फिर प्रभावित सबग्राफ को रिवाइंड कर सकते हैं, जो तब (उम्मीद है) स्वस्थ प्रदाता से ताजा डेटा प्राप्त करेगा।
 
-यदि एक ब्लॉक कैश असंगतता का संदेह है, जैसे कि tx रसीद गुम घटना:
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
 
-1. `ग्राफमैन श्रृंखला सूची` श्रृंखला का नाम खोजने के लिए।
+1. `graphman chain list` to find the chain name.
 2. `ग्राफमैन चेन चेक-ब्लॉक <CHAIN> बाई-नंबर <NUMBER>` यह जांच करेगा कि क्या कैश्ड ब्लॉक प्रदाता से मेल खाता है, और यदि ऐसा नहीं होता है तो ब्लॉक को कैश से हटा देता है।
    1. यदि कोई अंतर है, तो `ग्राफमैन चेन ट्रंकेट <CHAIN>` के साथ पूरे कैश को छोटा करना अधिक सुरक्षित हो सकता है।
    2. यदि ब्लॉक प्रदाता से मेल खाता है, तो समस्या को सीधे प्रदाता के विरुद्ध डिबग किया जा सकता है।
 
-#### समस्याओं और त्रुटियों को क्वेरी करना
+#### Querying issues and errors
 
-एक बार सबग्राफ अनुक्रमित हो जाने के बाद, इंडेक्सर्स सबग्राफ के समर्पित क्वेरी एंडपॉइंट के माध्यम से प्रश्नों की सेवा करने की उम्मीद कर सकते हैं। यदि इंडेक्सर महत्वपूर्ण क्वेरी वॉल्यूम की सेवा करने की उम्मीद कर रहा है, तो एक समर्पित क्वेरी नोड की सिफारिश की जाती है, और बहुत अधिक क्वेरी वॉल्यूम के मामले में, इंडेक्सर्स रेप्लिका शार्ड्स को कॉन्फ़िगर करना चाह सकते हैं ताकि क्वेरी इंडेक्सिंग प्रक्रिया को प्रभावित न करें।
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
 
 हालाँकि, एक समर्पित क्वेरी नोड और प्रतिकृतियों के साथ भी, कुछ प्रश्नों को निष्पादित करने में लंबा समय लग सकता है, और कुछ मामलों में मेमोरी उपयोग में वृद्धि होती है और अन्य उपयोगकर्ताओं के लिए क्वेरी समय को नकारात्मक रूप से प्रभावित करती है।
 
@@ -312,34 +312,34 @@ provider = [ { label = "kovan", url = "http://..", features = [] } ]
 
 ##### क्वेरी कैशिंग
 
-ग्राफ़ नोड डिफ़ॉल्ट रूप से ग्राफ़क्यूएल प्रश्नों को कैश करता है, जो डेटाबेस लोड को काफी कम कर सकता है। इसे `GRAPH_QUERY_CACHE_BLOCKS` और `GRAPH_QUERY_CACHE_MAX_MEM` सेटिंग्स के साथ और अधिक कॉन्फ़िगर किया जा सकता है - अधिक [यहां](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching) पढ़ें।
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
 
-##### प्रश्नों का विश्लेषण
+##### Analysing queries
 
-समस्याग्रस्त प्रश्न अक्सर दो तरीकों में से एक में सामने आते हैं। कुछ मामलों में, उपयोगकर्ता स्वयं रिपोर्ट करते हैं कि दी गई क्वेरी धीमी है। उस स्थिति में धीमी गति के कारण का निदान करना चुनौती है - चाहे वह एक सामान्य समस्या हो, या उस सबग्राफ या क्वेरी के लिए विशिष्ट हो। और यदि संभव हो तो निश्चित रूप से इसे हल करने के लिए।
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
 
 अन्य मामलों में, क्वेरी नोड पर ट्रिगर उच्च मेमोरी उपयोग हो सकता है, इस मामले में सबसे पहले समस्या उत्पन्न करने वाली क्वेरी की पहचान करना चुनौती है।
 
 इंडेक्सर [qlog](https://github.com/graphprotocol/qlog/) का इस्तेमाल ग्राफ़ नोड के क्वेरी लॉग को प्रोसेस करने और सारांशित करने के लिए कर सकते हैं। `GRAPH_LOG_QUERY_TIMING` को धीमी क्वेरी को पहचानने और डीबग करने में सहायता के लिए भी सक्षम किया जा सकता है।
 
-धीमी क्वेरी को देखते हुए, इंडेक्सर्स के पास कुछ विकल्प होते हैं। निस्संदेह वे अपने लागत मॉडल को बदल सकते हैं, समस्याग्रस्त क्वेरी भेजने की लागत में काफी वृद्धि कर सकते हैं। इसके परिणामस्वरूप उस क्वेरी की आवृत्ति में कमी हो सकती है। हालाँकि यह अक्सर समस्या के मूल कारण को हल नहीं करता है।
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
 
-##### खाता जैसा अनुकूलन
+##### Account-like optimisation
 
-डेटाबेस तालिकाएँ जो संस्थाओं को स्टोर करती हैं, आम तौर पर दो किस्मों में आती हैं: 'लेन-देन-जैसी', जहाँ संस्थाएँ, एक बार बनने के बाद, कभी भी अपडेट नहीं होती हैं, यानी, वे वित्तीय लेनदेन की सूची के समान कुछ स्टोर करती हैं, और 'खाता-जैसा' जहाँ संस्थाएँ बहुत बार अपडेट किए जाते हैं, यानी, वे वित्तीय खातों की तरह कुछ स्टोर करते हैं जो हर बार लेनदेन रिकॉर्ड होने पर संशोधित हो जाते हैं। खाता-जैसी तालिकाओं की विशेषता इस तथ्य से होती है कि उनमें बड़ी संख्या में इकाई संस्करण होते हैं, लेकिन अपेक्षाकृत कुछ विशिष्ट इकाइयाँ होती हैं। अक्सर, ऐसी तालिकाओं में अलग-अलग संस्थाओं की संख्या पंक्तियों की कुल संख्या (इकाई संस्करण) का 1% होती है
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
 
-खाता-जैसी तालिकाओं के लिए, `ग्राफ़-नोड` प्रश्नों को उत्पन्न कर सकता है जो इस बात का विवरण देता है कि कैसे पोस्टग्रेज डेटा को इतनी उच्च दर के परिवर्तन के साथ संग्रहीत करता है, अर्थात् हाल के ब्लॉक के सभी संस्करण अंदर हैं ऐसी तालिका के लिए समग्र संग्रहण का एक छोटा उपखंड।
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
 
-आदेश `ग्राफ़मैन आँकड़े <sgdNNNN`> दिखाता है, परिनियोजन में प्रत्येक इकाई प्रकार/तालिका के लिए, कितने अलग निकाय हैं, और प्रत्येक तालिका में कितने इकाई संस्करण हैं। वह डेटा पोस्टग्रेज-आंतरिक अनुमानों पर आधारित है, और इसलिए अनिवार्य रूप से सटीक है, और परिमाण के क्रम से बंद हो सकता है। `-1` `entities` कॉलम में इसका मतलब है कि Postgres का मानना है कि सभी पंक्तियों में एक अलग इकाई होती है।
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
 
-सामान्य तौर पर, तालिकाएँ जहाँ अलग-अलग संस्थाओं की संख्या पंक्तियों / इकाई संस्करणों की कुल संख्या के 1% से कम होती है, वे खाता-जैसे अनुकूलन के लिए अच्छे उम्मीदवार होते हैं। जब `ग्राफ़मैन आँकड़े दिखाते हैं` का आउटपुट इंगित करता है कि एक तालिका इस अनुकूलन से लाभान्वित हो सकती है, चल रहे `ग्राफ़मैन आँकड़े <sgdNNN> <टेबल>` तालिका की पूरी गणना करेगा - जो धीमा हो सकता है, लेकिन अलग-अलग इकाइयों के समग्र इकाई संस्करणों के अनुपात का एक सटीक माप देता है।
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
 
-एक बार तालिका को खाता-समान निर्धारित कर लेने के बाद, `ग्राफ़मैन आँकड़े खाता-जैसा <sgdNNN>.<table>` चलाने से उस तालिका के विरुद्ध प्रश्नों के लिए खाता-जैसा अनुकूलन चालू हो जाएगा। ऑप्टिमाइज़ेशन को फिर से बंद किया जा सकता है `ग्राफ़मैन स्टैटिस्टिक्स अकाउंट-लाइक --clear <sgdNNN>.<table>` क्वेरी नोड्स को यह नोटिस करने में 5 मिनट तक का समय लगता है कि ऑप्टिमाइज़ेशन चालू कर दिया गया है या बंद। अनुकूलन चालू करने के बाद, यह सत्यापित करना आवश्यक है कि परिवर्तन वास्तव में उस तालिका के लिए प्रश्नों को धीमा नहीं करता है। यदि आपने Postgres की निगरानी के लिए Grafana को कॉन्फ़िगर किया है, तो धीमी क्वेरी बड़ी संख्या में `pg_stat_activity`में दिखाई देगी, जिसमें कई सेकंड लगेंगे। उस स्थिति में, अनुकूलन को फिर से बंद करने की आवश्यकता होती है।
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
 
-Uniswap- जैसे सबग्राफ के लिए `pair` और `token` टेबल इस ऑप्टिमाइज़ेशन के लिए प्रमुख उम्मीदवार हैं, और डेटाबेस लोड पर नाटकीय प्रभाव डाल सकते हैं।
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
 
 #### सबग्राफ हटाना
 
-> यह नई कार्यक्षमता है, जो ग्राफ नोड 0.29.x में उपलब्ध होगी
+> This is new functionality, which will be available in Graph Node 0.29.x
 
 किसी बिंदु पर एक अनुक्रमणिका किसी दिए गए सबग्राफ को हटाना चाह सकती है। यह `ग्राफमैन ड्रॉप` के माध्यम से आसानी से किया जा सकता है, जो एक परिनियोजन और उसके सभी अनुक्रमित डेटा को हटा देता है। परिनियोजन को या तो सबग्राफ नाम, IPFS हैश `Qm..`, या डेटाबेस नाम स्थान `sgdNNN` के रूप में निर्दिष्ट किया जा सकता है। आगे के दस्तावेज़ [यहां](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop) उपलब्ध हैं।

From 645d2a7b25278a1490a302265046bafe2c0d4d7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:10 -0500
Subject: [PATCH 0278/3820] New translations operating-graph-node.mdx (Swahili)

---
 website/pages/sw/operating-graph-node.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/sw/operating-graph-node.mdx b/website/pages/sw/operating-graph-node.mdx
index dbbfcd5fc545..fb3d538f952a 100644
--- a/website/pages/sw/operating-graph-node.mdx
+++ b/website/pages/sw/operating-graph-node.mdx
@@ -77,13 +77,13 @@ A complete Kubernetes example configuration can be found in the [indexer reposit
 
 When it is running Graph Node exposes the following ports:
 
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS<br />(for subgraph subscriptions) | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC<br />(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| Port | Purpose                                               | Routes                                               | CLI Argument      | Environment Variable |
+| ---- | ----------------------------------------------------- | ---------------------------------------------------- | ----------------- | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | --http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | --ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                                    | --admin-port      | -                    |
+| 8030 | Subgraph indexing status API                          | /graphql                                             | --index-node-port | -                    |
+| 8040 | Prometheus metrics                                    | /metrics                                             | --metrics-port    | -                    |
 
 > **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
 

From 854eac0f0026836350b2c3272b041bbf51596193 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:20 -0500
Subject: [PATCH 0279/3820] New translations
 graphql-validations-migration-guide.mdx (French)

---
 .../release-notes/graphql-validations-migration-guide.mdx   | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/release-notes/graphql-validations-migration-guide.mdx b/website/pages/fr/release-notes/graphql-validations-migration-guide.mdx
index 62e5435c0fc3..567231e0bedf 100644
--- a/website/pages/fr/release-notes/graphql-validations-migration-guide.mdx
+++ b/website/pages/fr/release-notes/graphql-validations-migration-guide.mdx
@@ -103,7 +103,7 @@ query myData {
 }
 
 query myData2 {
-  # renommer la deuxième requête
+   # renommer la deuxième requête
   name
 }
 ```
@@ -158,7 +158,7 @@ _Solution:_
 
 ```graphql
 query myData($id: String) {
-  # conserver la variable pertinente (ici : `$id: String`)
+   # conserver la variable pertinente (ici : `$id: String`)
   id
   ...MyFields
 }
@@ -259,7 +259,7 @@ query {
 
 ```graphql
 # Différents arguments peuvent conduire à des données différentes,
-# donc nous ne pouvons pas supposer que les champs seront les mêmes.
+# donc nous ne pouvons pas supposer que les champs seront les mêmes. 
 query {
   dogs {
     doesKnowCommand(dogCommand: SIT)

From b40d389c4dc9aa2ca56b42f701158c146043d47f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:22 -0500
Subject: [PATCH 0280/3820] New translations
 graphql-validations-migration-guide.mdx (Spanish)

---
 .../es/release-notes/graphql-validations-migration-guide.mdx     | 1 +
 1 file changed, 1 insertion(+)

diff --git a/website/pages/es/release-notes/graphql-validations-migration-guide.mdx b/website/pages/es/release-notes/graphql-validations-migration-guide.mdx
index 55801738ddca..292c60a70cf9 100644
--- a/website/pages/es/release-notes/graphql-validations-migration-guide.mdx
+++ b/website/pages/es/release-notes/graphql-validations-migration-guide.mdx
@@ -406,6 +406,7 @@ query {
   user {
     id
     image # 'image' requiere un conjunto de selección para subcampos!
+
   }
 }
 ```

From 7ca364810293058c42058112816410484d72aa80 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:33 -0500
Subject: [PATCH 0281/3820] New translations
 graphql-validations-migration-guide.mdx (Japanese)

---
 .../ja/release-notes/graphql-validations-migration-guide.mdx    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/release-notes/graphql-validations-migration-guide.mdx b/website/pages/ja/release-notes/graphql-validations-migration-guide.mdx
index b004e14d9f98..9a8bcf34625f 100644
--- a/website/pages/ja/release-notes/graphql-validations-migration-guide.mdx
+++ b/website/pages/ja/release-notes/graphql-validations-migration-guide.mdx
@@ -521,7 +521,7 @@ query {
 }
 ```
 
-\_注: `@stream`、`@live`、`@defer` はサポートされていません。
+_注: `@stream`、`@live`、`@defer` はサポートされていません。
 
 **ディレクティブは、この場所で 1 回だけ使用できます (#UniqueDirectivesPerLocationRule)**
 

From 5c0f578605e682832b7cb24314669f2141e26c8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:38 -0500
Subject: [PATCH 0282/3820] New translations graphcast.mdx (Russian)

---
 website/pages/ru/graphcast.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/graphcast.mdx b/website/pages/ru/graphcast.mdx
index f3b330f6c374..a49399997208 100644
--- a/website/pages/ru/graphcast.mdx
+++ b/website/pages/ru/graphcast.mdx
@@ -2,7 +2,7 @@
 title: Graphcast
 ---
 
-## Введение
+## Introduction
 
 Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
 

From 0c247d73dd8f4ee5f200ec684771d82374293ce4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:47 -0500
Subject: [PATCH 0283/3820] New translations graphcast.mdx (Hindi)

---
 website/pages/hi/graphcast.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/graphcast.mdx b/website/pages/hi/graphcast.mdx
index a52e116cf941..beec8cbeeb3f 100644
--- a/website/pages/hi/graphcast.mdx
+++ b/website/pages/hi/graphcast.mdx
@@ -2,7 +2,7 @@
 title: ग्राफकास्ट
 ---
 
-## परिचय
+## Introduction
 
 क्या कोई ऐसी चीज है जिसे आप स्वचालित तरीके से अपने साथी इंडेक्सर्स से सीखना या साझा करना चाहते हैं, लेकिन यह बहुत अधिक परेशानी है या बहुत अधिक लागत है?
 

From b900ebd29e391a2894840805db204c0872a242b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:52 -0500
Subject: [PATCH 0284/3820] New translations arbitrum-faq.mdx (Arabic)

---
 website/pages/ar/arbitrum/arbitrum-faq.mdx | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/ar/arbitrum/arbitrum-faq.mdx b/website/pages/ar/arbitrum/arbitrum-faq.mdx
index 2cf8402a7718..cca6d4443119 100644
--- a/website/pages/ar/arbitrum/arbitrum-faq.mdx
+++ b/website/pages/ar/arbitrum/arbitrum-faq.mdx
@@ -1,5 +1,5 @@
 ---
-title: الأسئلة الشائعة حول Arbitrum
+title: Arbitrum FAQ
 ---
 
 Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs.
@@ -18,7 +18,7 @@ Scaling the protocol smart contracts onto L2 allows network participants to inte
 
 The Graph community decided to move forward with Arbitrum last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion.
 
-## ما الذي يجب علي فعله لاستخدام The Graph في L2؟
+## What do I need to do to use The Graph on L2?
 
 The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
 
@@ -35,7 +35,7 @@ Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few diffe
 
 Once you have GRT on Arbitrum, you can add it to your billing balance.
 
-للاستفادة من استخدام The Graph على L2 ، استخدم قائمة المنسدلة للتبديل بين الشبكات.
+To take advantage of using The Graph on L2, use this dropdown switcher to toggle between chains.
 
 ![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
 
@@ -59,21 +59,21 @@ All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/arb
 
 Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational.
 
-## الأسئلة الشائعة حول إعداد الفواتير في Arbitrum
+## Billing on Arbitrum FAQs
 
-## ما الذي علي فعله بشأن ال GRT في حساب الفوترة الخاص بي ؟
+## What do I need to do about the GRT in my billing balance?
 
-لا شئ! لقد تم نقل GRT الخاصة بك بشكل آمن إلى Arbitrum ويتم استخدامها للدفع مقابل الاستعلامات.
+Nothing! Your GRT has been securely migrated to Arbitrum and is being used to pay for queries as you read this.
 
-## كيف أعرف أن أموالي قد انتقلت بشكل آمن إلى Arbitrum؟
+## How do I know my funds have migrated securely to Arbitrum?
 
 All GRT billing balances have already been successfully migrated to Arbitrum. You can view the billing contract on Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
 
-## كيف أعرف أن جسر Arbitrum آمن؟
+## How do I know the Arbitrum bridge is secure?
 
 The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
 
-## ماذا علي أن أفعل إذا قمت بإضافة GRT جديد من محفظة Ethereum mainnet الخاصة بي؟
+## What do I need to do if I'm adding fresh GRT from my Ethereum mainnet wallet?
 
 Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction.
 

From 534e319fe7a21d547f54e491a36245ac78387eee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:10:54 -0500
Subject: [PATCH 0285/3820] New translations l2-transfer-tools-faq.mdx (French)

---
 website/pages/fr/arbitrum/l2-transfer-tools-faq.mdx | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/fr/arbitrum/l2-transfer-tools-faq.mdx
index 45ec79e9d4f9..d43463682da5 100644
--- a/website/pages/fr/arbitrum/l2-transfer-tools-faq.mdx
+++ b/website/pages/fr/arbitrum/l2-transfer-tools-faq.mdx
@@ -336,11 +336,13 @@ Si vous n’avez transféré aucun solde de contrat de vesting à L2 et que votr
 
 ### J’utilise mon contrat de vesting pour investir dans mainnet. Puis-je transférer ma participation à Arbitrum?
 
-Oui, mais si votre contrat est toujours acquis, vous ne pouvez transférer la participation que pour qu’elle soit détenue par votre contrat d’acquisition L2. Vous devez d’abord initialiser ce contrat L2 en transférant un solde de GRT à l’aide de l’outil de transfert de contrat d’acquisition dans Explorer. Si votre contrat est entièrement acquis, vous pouvez transférer votre participation à n’importe quelle adresse en L2, mais vous devez le définir au préalable et déposer des GRT pour l’outil de transfert L2 pour payer le gaz L2.
+Oui, mais si votre contrat est toujours acquis, vous ne pouvez transférer la participation que pour qu’elle soit détenue par votre contrat d’acquisition L2. Vous devez d’abord initialiser ce contrat L2 en transférant un solde de GRT à l’aide de l’outil de transfert de contrat d’acquisition dans Explorer. Si
+votre contrat est entièrement acquis, vous pouvez transférer votre participation à n’importe quelle adresse en L2, mais vous devez le définir au préalable et déposer des GRT pour l’outil de transfert L2 pour payer le gaz L2.
 
 ### J’utilise mon contrat de vesting pour déléguer sur mainnet. Puis-je transférer mes délégations à Arbitrum?
 
-Oui, mais si votre contrat est toujours acquis, vous ne pouvez transférer la participation que pour qu’elle soit détenue par votre contrat de vesting L2. Vous devez d’abord initialiser ce contrat L2 en transférant un solde de GRT à l’aide de l’outil de transfert de contrat de vesting dans Explorer. Si votre contrat est entièrement acquis, vous pouvez transférer votre participation à n’importe quelle adresse en L2, mais vous devez le définir au préalable et déposer des GRT pour l’outil de transfert L2 pour payer le gaz L2.
+Oui, mais si votre contrat est toujours acquis, vous ne pouvez transférer la participation que pour qu’elle soit détenue par votre contrat de vesting L2. Vous devez d’abord initialiser ce contrat L2 en transférant un solde de GRT à l’aide de l’outil de transfert de contrat de vesting dans Explorer. Si
+votre contrat est entièrement acquis, vous pouvez transférer votre participation à n’importe quelle adresse en L2, mais vous devez le définir au préalable et déposer des GRT pour l’outil de transfert L2 pour payer le gaz L2.
 
 ### Puis-je spécifier un bénéficiaire différent pour mon contrat de vesting sur L2?
 

From 3a9374d16645c3ea08dd70e108d6036989242dda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:11:02 -0500
Subject: [PATCH 0286/3820] New translations l2-transfer-tools-faq.mdx (German)

---
 website/pages/de/arbitrum/l2-transfer-tools-faq.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/de/arbitrum/l2-transfer-tools-faq.mdx
index 5ff21e03c171..48944eebbfbb 100644
--- a/website/pages/de/arbitrum/l2-transfer-tools-faq.mdx
+++ b/website/pages/de/arbitrum/l2-transfer-tools-faq.mdx
@@ -64,7 +64,7 @@ Die Übertragungszeit beträgt etwa 20 Minuten. Die Arbitrum-Brücke arbeitet im
 
 ### Wird mein Subgraph noch auffindbar sein, nachdem ich ihn auf L2 übertragen habe?
 
-Ihr Subgraph ist nur in dem Netzwerk auffindbar, in dem er veröffentlicht ist. Wenn Ihr Subgraph zum Beispiel auf Arbitrum One ist, können Sie ihn nur im Explorer auf Arbitrum One finden und nicht auf Ethereum. Bitte vergewissern Sie sich, dass Sie Arbitrum One in der Netzwerkumschaltung oben auf der Seite ausgewählt haben, um sicherzustellen, dass Sie sich im richtigen Netzwerk befinden. Nach der Übertragung wird der L1-Subgraph als veraltet angezeigt.
+Ihr Subgraph ist nur in dem Netzwerk auffindbar, in dem er veröffentlicht ist. Wenn Ihr Subgraph zum Beispiel auf Arbitrum One ist, können Sie ihn nur im Explorer auf Arbitrum One finden und nicht auf Ethereum. Bitte vergewissern Sie sich, dass Sie Arbitrum One in der Netzwerkumschaltung oben auf der Seite ausgewählt haben, um sicherzustellen, dass Sie sich im richtigen Netzwerk befinden.  Nach der Übertragung wird der L1-Subgraph als veraltet angezeigt.
 
 ### Muss mein Subgraph ( Teilgraph ) veröffentlicht werden, um ihn zu übertragen?
 

From 4e1e7a1b174e8d1a99f2de4947c08797019e9307 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:11:04 -0500
Subject: [PATCH 0287/3820] New translations l2-transfer-tools-faq.mdx
 (Italian)

---
 website/pages/it/arbitrum/l2-transfer-tools-faq.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/it/arbitrum/l2-transfer-tools-faq.mdx
index a5252f121a00..147439f09c2c 100644
--- a/website/pages/it/arbitrum/l2-transfer-tools-faq.mdx
+++ b/website/pages/it/arbitrum/l2-transfer-tools-faq.mdx
@@ -2,7 +2,7 @@
 title: L2 Transfer Tools FAQ
 ---
 
-## Generale
+## General
 
 ### Cosa sono gli Strumenti di Trasferimento L2?
 

From b328331fa06fb7dea75ef2916d536ffb94b4b0b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:11:06 -0500
Subject: [PATCH 0288/3820] New translations l2-transfer-tools-faq.mdx (Korean)

---
 website/pages/ko/arbitrum/l2-transfer-tools-faq.mdx | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/website/pages/ko/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/ko/arbitrum/l2-transfer-tools-faq.mdx
index de12152a1f00..602b2a2c3aa2 100644
--- a/website/pages/ko/arbitrum/l2-transfer-tools-faq.mdx
+++ b/website/pages/ko/arbitrum/l2-transfer-tools-faq.mdx
@@ -22,7 +22,8 @@ The exception is with smart contract wallets like multisigs: these are smart con
 
 ### 만약 7일 안에 이체를 완료하지 못하면 어떻게 되나요?
 
-L2 전송 도구는 Arbitrum의 기본 메커니즘을 사용하여 L1에서 L2로 메시지를 보냅니다. 이 메커니즘은 "재시도 가능한 티켓"이라고 하며 Arbitrum GRT 브리지를 포함한 모든 네이티브 토큰 브리지를 사용하여 사용됩니다. 재시도 가능한 티켓에 대해 자세히 읽을 수 있습니다 [Arbitrum 문서] (https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+L2 전송 도구는 Arbitrum의 기본 메커니즘을 사용하여 L1에서 L2로 메시지를 보냅니다. 이 메커니즘은 "재시도 가능한 티켓"이라고 하며 Arbitrum GRT 브리지를 포함한 모든 네이티브 토큰 브리지를 사용하여 사용됩니다. 재시도 가능한 티켓에 대해 자세히 읽을 수 있습니다 [Arbitrum 문서] 
+(https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
 
 자산(하위 그래프, 스테이크, 위임 또는 큐레이션) 을 L2로 이전하면 L2에서 재시도 가능한 티켓을 생성하는 Arbitrum GRT 브리지를 통해 메시지가 전송됩니다. 전송 도구에는 거래에 일부 ETH 값이 포함되어 있으며, 이는 1) 티켓 생성 비용을 지불하고 2) L2에서 티켓을 실행하기 위해 가스 비용을 지불하는 데 사용됩니다. 그러나 티켓이 L2에서 실행될 준비가 될 때까지 가스 가격이 시간에 따라 달라질 수 있으므로 이 자동 실행 시도가 실패할 수 있습니다. 그런 일이 발생하면 Arbitrum 브릿지는 재시도 가능한 티켓을 최대 7일 동안 유지하며 누구나 티켓 "사용"을 재시도할 수 있습니다(Arbitrum에 브릿지된 일부 ETH가 있는 지갑이 필요함).
 
@@ -40,6 +41,8 @@ If you have the L1 transaction hash (which you can find by looking at the recent
 
 <VideoEmbed youtube="R8_vz4lx2Co" />
 
+
+
 1. 이더리움 메인넷에서 전송 시작
 
 2. 확인을 위해 20분 정도 기다리세요

From 7b6fa3a479b880187179899aa6777c8e70aa915a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:11:09 -0500
Subject: [PATCH 0289/3820] New translations
 graphql-validations-migration-guide.mdx (Portuguese)

---
 .../graphql-validations-migration-guide.mdx         | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/website/pages/pt/release-notes/graphql-validations-migration-guide.mdx b/website/pages/pt/release-notes/graphql-validations-migration-guide.mdx
index 7b94db58a11d..75c8799b9286 100644
--- a/website/pages/pt/release-notes/graphql-validations-migration-guide.mdx
+++ b/website/pages/pt/release-notes/graphql-validations-migration-guide.mdx
@@ -256,7 +256,8 @@ query {
 }
 ```
 
-**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)** (Campos em conflito com argumentos)
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+(Campos em conflito com argumentos)
 
 ```graphql
 # Argumentos diferentes podem levar a dados diferentes,
@@ -465,10 +466,10 @@ Estas referências desconhecidas devem ser consertadas:
 - caso contrário, remova
 
 ### Fragment: invalid spread or definition
-
 (Fragment: espalhamento ou definição inválidos)
 
-**Invalid Fragment spread (#PossibleFragmentSpreadsRule)** (Espalhamento de fragment inválido)
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+(Espalhamento de fragment inválido)
 
 Um Fragment não pode ser espalhado em um tipo não aplicável.
 
@@ -508,7 +509,8 @@ fragment inlineFragOnScalar on Dog {
 
 ### Uso de Diretivas
 
-**Directive cannot be used at this location (#KnownDirectivesRule)** (A diretiva não pode ser usada neste local)
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+(A diretiva não pode ser usada neste local)
 
 Apenas diretivas GraphQL (`@...`) apoiadas pela API do The Graph podem ser usadas.
 
@@ -525,7 +527,8 @@ query {
 
 _Nota: `@stream`, `@live`, e `@defer` não têm apoio._
 
-**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)** (A diretiva só pode ser usada neste local uma vez)
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+(A diretiva só pode ser usada neste local uma vez)
 
 As diretivas apoiadas pelo The Graph só podem ser usadas uma vez por local.
 

From 426ae62486315e79af659edafb548a4a0a425b69 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:11:10 -0500
Subject: [PATCH 0290/3820] New translations
 graphql-validations-migration-guide.mdx (Russian)

---
 .../graphql-validations-migration-guide.mdx            | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ru/release-notes/graphql-validations-migration-guide.mdx b/website/pages/ru/release-notes/graphql-validations-migration-guide.mdx
index b7cb792259b3..25238b858a50 100644
--- a/website/pages/ru/release-notes/graphql-validations-migration-guide.mdx
+++ b/website/pages/ru/release-notes/graphql-validations-migration-guide.mdx
@@ -284,8 +284,8 @@ query {
 
 ```graphql
 query {
-  # В конце концов, у нас есть два определения "x", указывающие
-  # на разные поля!
+ # В конце концов, у нас есть два определения "x", указывающие
+ # на разные поля!
   ...A
   ...B
 }
@@ -437,7 +437,7 @@ query {
 ```graphql
 query purposes {
   # Если в схеме "name" определено как "String",
-  # этот запрос не пройдёт валидацию.
+   # этот запрос не пройдёт валидацию.
   purpose(name: 1) {
     id
   }
@@ -447,8 +447,8 @@ query purposes {
 
 query purposes($name: Int!) {
   # Если "name" определено в схеме как `String`,
-  # этот запрос не пройдёт валидацию, потому что
-  # используемая переменная имеет тип `Int`
+   # этот запрос не пройдёт валидацию, потому что
+   # используемая переменная имеет тип `Int`
   purpose(name: $name) {
     id
   }

From 2a505e251aee2bc6e1c432ba609c75cce91b9aef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:11:20 -0500
Subject: [PATCH 0291/3820] New translations
 graphql-validations-migration-guide.mdx (Urdu (Pakistan))

---
 .../ur/release-notes/graphql-validations-migration-guide.mdx   | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/website/pages/ur/release-notes/graphql-validations-migration-guide.mdx b/website/pages/ur/release-notes/graphql-validations-migration-guide.mdx
index fba78a067915..3d1289e29dd2 100644
--- a/website/pages/ur/release-notes/graphql-validations-migration-guide.mdx
+++ b/website/pages/ur/release-notes/graphql-validations-migration-guide.mdx
@@ -4,7 +4,8 @@ title: GraphQL کی توثیق کی منتقلی گائیڈ
 
 جلد ہی `گراف نوڈ` [GraphQL توثیق کی تفصیلات](https://spec.graphql.org/June2018/#sec-Validation) کی 100% کوریج کو سپورٹ کرے گا.
 
-`گراف نوڈ` کے پچھلے ورژن تمام توثیقوں کی حمایت نہیں کرتے تھے اور زیادہ خوبصورت جوابات فراہم کرتے تھے - لہذا، ابہام کی صورت میں، `گراف نوڈ` غلط گراف کیو ایل آپریشن کے اجزاء کو نظر انداز کر رہا تھا.
+`گراف نوڈ` کے پچھلے ورژن تمام توثیقوں کی حمایت نہیں کرتے تھے اور زیادہ خوبصورت جوابات فراہم کرتے تھے - لہذا، ابہام کی صورت میں، `گراف نوڈ` غلط گراف کیو ایل
+ آپریشن کے اجزاء کو نظر انداز کر رہا تھا.
 
 GraphQL ویلیڈیشن سپورٹ آنے والی نئی خصوصیات اور گراف نیٹ ورک کے پیمانے پر کارکردگی کا ایک ستون ہے.
 

From ea2c2da50c79ab6c188c2c80ed3822b51b0f76ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:11:26 -0500
Subject: [PATCH 0292/3820] New translations arbitrum-faq.mdx (Marathi)

---
 website/pages/mr/arbitrum/arbitrum-faq.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/mr/arbitrum/arbitrum-faq.mdx b/website/pages/mr/arbitrum/arbitrum-faq.mdx
index 6a6ac6739ee8..9c12c8816259 100644
--- a/website/pages/mr/arbitrum/arbitrum-faq.mdx
+++ b/website/pages/mr/arbitrum/arbitrum-faq.mdx
@@ -39,7 +39,7 @@ To take advantage of using The Graph on L2, use this dropdown switcher to toggle
 
 ![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
 
-## सबग्राफ डेव्हलपर, डेटा कंझ्युमर, इंडेक्सर, क्युरेटर किंवा डेलिगेटर म्हणून, मला आता काय करावे लागेल?
+## As a subgraph developer, data consumer, Indexer, Curator, or Delegator, what do I need to do now?
 
 Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/arbitrum/l2-transfer-tools-guide/) for additional support.
 
@@ -73,7 +73,7 @@ All GRT billing balances have already been successfully migrated to Arbitrum. Yo
 
 The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
 
-## मी माझ्या इथरियम मेननेट वॉलेटमधून नवीन GRT जोडत असल्यास मला काय करावे लागेल?
+## What do I need to do if I'm adding fresh GRT from my Ethereum mainnet wallet?
 
 Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction.
 

From 9858e032768c866def2c1e8fffda3c0634b3170a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:11:28 -0500
Subject: [PATCH 0293/3820] New translations arbitrum-faq.mdx (Hindi)

---
 website/pages/hi/arbitrum/arbitrum-faq.mdx | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/website/pages/hi/arbitrum/arbitrum-faq.mdx b/website/pages/hi/arbitrum/arbitrum-faq.mdx
index 885ebdc4f88f..3da16e27202d 100644
--- a/website/pages/hi/arbitrum/arbitrum-faq.mdx
+++ b/website/pages/hi/arbitrum/arbitrum-faq.mdx
@@ -6,7 +6,7 @@ Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitru
 
 ## The Graph ने L2 समाधान को लागू करने का कारण क्या था?
 
-L2 पर The Graph को स्केल करके, नेटवर्क के प्रतिभागी अब निम्नलिखित लाभ उठा सकते हैं:
+ L2 पर The Graph को स्केल करके, नेटवर्क के प्रतिभागी अब निम्नलिखित लाभ उठा सकते हैं:
 
 - Upwards of 26x savings on gas fees
 
@@ -18,7 +18,7 @@ L2 पर प्रोटोकॉल स्मार्ट कॉन्ट्
 
 The Graph community decided to move forward with Arbitrum last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion.
 
-## L2 पर ग्राफ़ का उपयोग करने के लिए मुझे क्या करना होगा?
+## What do I need to do to use The Graph on L2?
 
 The Graph का बिलिंग सिस्टम Arbitrum पर GRT स्वीकार करता है, और उपयोगकर्ताओं को गैस के लिए Arbitrum पर ETHकी आवश्यकता होगी। जबकि The Graph प्रोटोकॉल Ethereum Mainnet पर शुरू हुआ था, अब सभी गतिविधियाँ, जिसमें बिलिंग कॉन्ट्रैक्ट्स शामिल हैं, Arbitrum One पर हैं।
 
@@ -35,7 +35,7 @@ The Graph का बिलिंग सिस्टम Arbitrum पर GRT स
 
 एक बार जब आपके पास Arbitrum पर GRT हो, तो आप इसे अपनी बिलिंग बैलेंस में जोड़ सकते हैं।
 
-L2 पर द ग्राफ़ का उपयोग करने का लाभ उठाने के लिए, इस ड्रॉपडाउन स्विचर का उपयोग जंजीरों के बीच टॉगल करने के लिए करें।
+To take advantage of using The Graph on L2, use this dropdown switcher to toggle between chains.
 
 ![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
 
@@ -47,7 +47,8 @@ L2 पर द ग्राफ़ का उपयोग करने का ल
 
 ## क्या नेटवर्क को L2 पर स्केल करने से संबंधित कोई जोखिम थे?
 
-सभी स्मार्ट कॉन्ट्रैक्ट्स का पूरी तरह से परीक्षित किया गया है। (https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+सभी स्मार्ट कॉन्ट्रैक्ट्स का पूरी तरह से परीक्षित किया गया है।
+(https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
 
 हर चीज़ का पूरी तरह से परीक्षण किया गया है, और एक सुरक्षित और निर्बाध संक्रमण सुनिश्चित करने के लिए एक आकस्मिक योजना बनाई गई है। विवरण यहां पाया जा सकता है [here] (https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and- सुरक्षा-विचार-20).
 
@@ -61,19 +62,19 @@ Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/addr
 
 ## Arbitrum पर बिलिंग FAQs
 
-## मुझे अपने बिलिंग बैलेंस में GRT के बारे में क्या करना होगा?
+## What do I need to do about the GRT in my billing balance?
 
-कुछ नहीं! आपके जीआरटी को आर्बिट्रम में सुरक्षित रूप से माइग्रेट कर दिया गया है और जब आप इसे पढ़ रहे हैं तो इसका उपयोग प्रश्नों के भुगतान के लिए किया जा रहा है।
+Nothing! Your GRT has been securely migrated to Arbitrum and is being used to pay for queries as you read this.
 
-## मुझे कैसे पता चलेगा कि मेरे फंड आर्बिट्रम में सुरक्षित रूप से माइग्रेट हो गए हैं?
+## How do I know my funds have migrated securely to Arbitrum?
 
 सभी जीआरटी बिलिंग शेष पहले ही सफलतापूर्वक आर्बिट्रम में स्थानांतरित कर दिए गए हैं। आप आर्बिट्रम पर बिलिंग अनुबंध [यहां] [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a) देख सकते हैं।
 
-## मुझे कैसे पता चलेगा कि आर्बिट्रम ब्रिज सुरक्षित है?
+## How do I know the Arbitrum bridge is secure?
 
 The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
 
-## अगर मैं अपने एथेरियम मेननेट वॉलेट से ताजा जीआरटी जोड़ रहा हूं तो मुझे क्या करना होगा?
+## What do I need to do if I'm adding fresh GRT from my Ethereum mainnet wallet?
 
 आपके आर्बिट्रम बिलिंग बैलेंस में जीआरटी जोड़ना [सबग्राफ स्टूडियो] (https://thegraph.com/studio/) में एक-क्लिक अनुभव के साथ किया जा सकता है। आप आसानी से अपने जीआरटी को आर्बिट्रम से जोड़ सकेंगे और एक लेनदेन में अपनी एपीआई कुंजी भर सकेंगे।
 

From 74d4a7cc6f96153f7526d1d08de728231d519f76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:03 -0500
Subject: [PATCH 0294/3820] New translations new-chain-integration.mdx
 (Romanian)

---
 website/pages/ro/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/new-chain-integration.mdx b/website/pages/ro/new-chain-integration.mdx
index 3bb6c774f961..534d6701efdb 100644
--- a/website/pages/ro/new-chain-integration.mdx
+++ b/website/pages/ro/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 0e20ec313e25b6a159f4f6265cfc792ae4488531 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:04 -0500
Subject: [PATCH 0295/3820] New translations new-chain-integration.mdx (French)

---
 website/pages/fr/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/new-chain-integration.mdx b/website/pages/fr/new-chain-integration.mdx
index 3f0e6d2612d6..398e4770837e 100644
--- a/website/pages/fr/new-chain-integration.mdx
+++ b/website/pages/fr/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 3d5005b9388c3388a457683f7e8a38ff73779673 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:05 -0500
Subject: [PATCH 0296/3820] New translations new-chain-integration.mdx
 (Spanish)

---
 website/pages/es/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/new-chain-integration.mdx b/website/pages/es/new-chain-integration.mdx
index 6e61fadecf0c..ea501d78d47a 100644
--- a/website/pages/es/new-chain-integration.mdx
+++ b/website/pages/es/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, en una solicitud por lotes JSON-RPC
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 3d473cc822eb8dfcd87cfdf63dec9c040d5e6b88 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:06 -0500
Subject: [PATCH 0297/3820] New translations new-chain-integration.mdx (Arabic)

---
 website/pages/ar/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/new-chain-integration.mdx b/website/pages/ar/new-chain-integration.mdx
index 75df818160ce..ec987dfa5b55 100644
--- a/website/pages/ar/new-chain-integration.mdx
+++ b/website/pages/ar/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`، ضمن طلب دفعة استدعاء الإجراء عن بُعد باستخدام تمثيل كائنات جافا سكريبت
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 2b55dac52a59f12a3212201e5adf1d59c0567f9f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:07 -0500
Subject: [PATCH 0298/3820] New translations new-chain-integration.mdx (Czech)

---
 website/pages/cs/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/new-chain-integration.mdx b/website/pages/cs/new-chain-integration.mdx
index e9f52eb42a93..6fd34e39cbac 100644
--- a/website/pages/cs/new-chain-integration.mdx
+++ b/website/pages/cs/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 807a20d49af7823d9346ce6c3bcc0ba9900eefce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:15 -0500
Subject: [PATCH 0299/3820] New translations new-chain-integration.mdx (German)

---
 website/pages/de/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/new-chain-integration.mdx b/website/pages/de/new-chain-integration.mdx
index 3bb6c774f961..534d6701efdb 100644
--- a/website/pages/de/new-chain-integration.mdx
+++ b/website/pages/de/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From e24392650f3e522668b67752f4efad4bd7c3bd12 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:16 -0500
Subject: [PATCH 0300/3820] New translations new-chain-integration.mdx
 (Italian)

---
 website/pages/it/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/new-chain-integration.mdx b/website/pages/it/new-chain-integration.mdx
index 3bb6c774f961..534d6701efdb 100644
--- a/website/pages/it/new-chain-integration.mdx
+++ b/website/pages/it/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 4ed2ca579f35992b58287bb96e1128f6e491e2fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:17 -0500
Subject: [PATCH 0301/3820] New translations new-chain-integration.mdx
 (Japanese)

---
 website/pages/ja/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/new-chain-integration.mdx b/website/pages/ja/new-chain-integration.mdx
index ce4d66cccdc7..76d085dc6ea8 100644
--- a/website/pages/ja/new-chain-integration.mdx
+++ b/website/pages/ja/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 0335333778e01a883c168ae2f9da4a487fb6581a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:18 -0500
Subject: [PATCH 0302/3820] New translations new-chain-integration.mdx (Korean)

---
 website/pages/ko/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/new-chain-integration.mdx b/website/pages/ko/new-chain-integration.mdx
index 3bb6c774f961..534d6701efdb 100644
--- a/website/pages/ko/new-chain-integration.mdx
+++ b/website/pages/ko/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From dae5b4497a92dad9b16d860273db706f75e035c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:20 -0500
Subject: [PATCH 0303/3820] New translations new-chain-integration.mdx (Dutch)

---
 website/pages/nl/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/new-chain-integration.mdx b/website/pages/nl/new-chain-integration.mdx
index 3bb6c774f961..534d6701efdb 100644
--- a/website/pages/nl/new-chain-integration.mdx
+++ b/website/pages/nl/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From bf6ad5ffc74c8cf339af9caf034b22c7d67b5187 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:21 -0500
Subject: [PATCH 0304/3820] New translations new-chain-integration.mdx (Polish)

---
 website/pages/pl/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/new-chain-integration.mdx b/website/pages/pl/new-chain-integration.mdx
index 3bb6c774f961..534d6701efdb 100644
--- a/website/pages/pl/new-chain-integration.mdx
+++ b/website/pages/pl/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From d59279cbc61a8ed529ee36b1970ac843c9a658c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:27 -0500
Subject: [PATCH 0305/3820] New translations new-chain-integration.mdx
 (Russian)

---
 website/pages/ru/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/new-chain-integration.mdx b/website/pages/ru/new-chain-integration.mdx
index 3bb6c774f961..534d6701efdb 100644
--- a/website/pages/ru/new-chain-integration.mdx
+++ b/website/pages/ru/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 20f785eed86a6720551729998adf2a8b3d2ee0f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:28 -0500
Subject: [PATCH 0306/3820] New translations new-chain-integration.mdx
 (Swedish)

---
 website/pages/sv/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/new-chain-integration.mdx b/website/pages/sv/new-chain-integration.mdx
index d3584aea08f5..7902ed6f31b2 100644
--- a/website/pages/sv/new-chain-integration.mdx
+++ b/website/pages/sv/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, i en JSON-RPC batch-begäran
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 83c7695417a9c71beafaba30f8853f3a5e4af094 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:29 -0500
Subject: [PATCH 0307/3820] New translations new-chain-integration.mdx
 (Turkish)

---
 website/pages/tr/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/new-chain-integration.mdx b/website/pages/tr/new-chain-integration.mdx
index f9553b1ba605..9f2bc45f75cd 100644
--- a/website/pages/tr/new-chain-integration.mdx
+++ b/website/pages/tr/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, bir JSON-RPC toplu talebinde
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 55b7b0d74388727ed664b5a23603451611dacb85 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:30 -0500
Subject: [PATCH 0308/3820] New translations new-chain-integration.mdx
 (Ukrainian)

---
 website/pages/uk/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/new-chain-integration.mdx b/website/pages/uk/new-chain-integration.mdx
index 3bb6c774f961..534d6701efdb 100644
--- a/website/pages/uk/new-chain-integration.mdx
+++ b/website/pages/uk/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 72486d2dc9114ee0ff094c36fd5093629877e00a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:32 -0500
Subject: [PATCH 0309/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Urdu (Pakistan))

---
 .../pages/ur/developing/substreams-powered-subgraphs-faq.mdx   | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/website/pages/ur/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/ur/developing/substreams-powered-subgraphs-faq.mdx
index d00028321854..ff87c267315c 100644
--- a/website/pages/ur/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/ur/developing/substreams-powered-subgraphs-faq.mdx
@@ -44,7 +44,8 @@ Substreams-powered subgraphs combine all the benefits of Substreams with the que
 
 [StreamingFast](https://www.streamingfast.io/) کے ذریعے تیار کردہ، Firehose ایک بلاکچین ڈیٹا نکالنے کی پرت ہے جسے شروع سے بلاکچینز کی مکمل تاریخ کو اس رفتار سے پروسیس کرنے کے لیے ڈیزائن کیا گیا ہے جو پہلے نظر نہیں آتی تھیں۔ فائلوں پر مبنی اور سٹریمنگ فرسٹ اپروچ فراہم کرنا، یہ سٹریمنگ فاسٹ کے اوپن سورس ٹیکنالوجیز کے سوٹ کا بنیادی جزو اور سب اسٹریمز کی بنیاد ہے.
 
-Firehose کے بارے میں مزید جاننے کے لیے[documentation] (https://firehose.streamingfast.io/) پر جائیں.
+Firehose کے بارے میں مزید جاننے کے لیے[documentation]
+(https://firehose.streamingfast.io/) پر جائیں.
 
 ## Firehose کے کیا فوائد ہیں؟
 

From f20e699daa538c534b0d8865e2818615cb70af25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:35 -0500
Subject: [PATCH 0310/3820] New translations new-chain-integration.mdx (Chinese
 Simplified)

---
 website/pages/zh/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/new-chain-integration.mdx b/website/pages/zh/new-chain-integration.mdx
index d7a098e18184..a3074f0c8223 100644
--- a/website/pages/zh/new-chain-integration.mdx
+++ b/website/pages/zh/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, 在JSON-RPC批量请求中
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From c5e90186bfa5fd6c329608e34e49426383857991 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:36 -0500
Subject: [PATCH 0311/3820] New translations new-chain-integration.mdx (Urdu
 (Pakistan))

---
 website/pages/ur/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/new-chain-integration.mdx b/website/pages/ur/new-chain-integration.mdx
index 6853e523e756..8a348a4970ea 100644
--- a/website/pages/ur/new-chain-integration.mdx
+++ b/website/pages/ur/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 3c996eafba0ca601ec8fd9fbb758fddb50112dfc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:37 -0500
Subject: [PATCH 0312/3820] New translations new-chain-integration.mdx
 (Vietnamese)

---
 website/pages/vi/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/new-chain-integration.mdx b/website/pages/vi/new-chain-integration.mdx
index 3bb6c774f961..534d6701efdb 100644
--- a/website/pages/vi/new-chain-integration.mdx
+++ b/website/pages/vi/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From 492f4c82d4cd6615e78ce1794f8ea7389e565040 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:38 -0500
Subject: [PATCH 0313/3820] New translations new-chain-integration.mdx
 (Marathi)

---
 website/pages/mr/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/new-chain-integration.mdx b/website/pages/mr/new-chain-integration.mdx
index 3bb6c774f961..534d6701efdb 100644
--- a/website/pages/mr/new-chain-integration.mdx
+++ b/website/pages/mr/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From a6efab064cf056bdbed00a2a72c97c24ba9efe41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:12:40 -0500
Subject: [PATCH 0314/3820] New translations new-chain-integration.mdx
 (Swahili)

---
 website/pages/sw/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/new-chain-integration.mdx b/website/pages/sw/new-chain-integration.mdx
index 3bb6c774f961..534d6701efdb 100644
--- a/website/pages/sw/new-chain-integration.mdx
+++ b/website/pages/sw/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` *(optionally required for Graph Node to support call handlers)*
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
 

From e890e5005ff1e593652f2577ff9d38ecec4800ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:13:02 -0500
Subject: [PATCH 0315/3820] New translations chain-integration-overview.mdx
 (Urdu (Pakistan))

---
 website/pages/ur/chain-integration-overview.mdx | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/website/pages/ur/chain-integration-overview.mdx b/website/pages/ur/chain-integration-overview.mdx
index 6230099cd0f5..43b53094048a 100644
--- a/website/pages/ur/chain-integration-overview.mdx
+++ b/website/pages/ur/chain-integration-overview.mdx
@@ -7,7 +7,8 @@ title: چین انٹیگریشن کے عمل کا جائزہ
 ## مرحلہ 1. تکنیکی انٹیگریشن
 
 - Please visit [New Chain Integration](/new-chain-integration) for information on `graph-node` support for new chains.
-- ٹیمیں فورم تھریڈ بنا کر پروٹوکول انٹیگریشن کا عمل شروع کرتی ہیں [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71)(گورننس اور GIPs کے تحت نئے ڈیٹا ذرائع ذیلی زمرہ) ۔ پہلے سے طے شدہ فورم ٹیمپلیٹ کا استعمال لازمی ہے.
+- ٹیمیں فورم تھریڈ بنا کر پروٹوکول انٹیگریشن کا عمل شروع کرتی ہیں [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71)(گورننس اور GIPs کے تحت نئے ڈیٹا ذرائع ذیلی زمرہ)
+  ۔ پہلے سے طے شدہ فورم ٹیمپلیٹ کا استعمال لازمی ہے.
 
 ## مرحلہ 2۔ انٹیگریشن کی توثیق
 

From 8f548c968ec1b94063f6f01dba2e74b5280e7d2d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:02 -0500
Subject: [PATCH 0316/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Hindi)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/hi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index cce3d8339979..e4f078918c5c 100644
--- a/website/pages/hi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/hi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -24,7 +24,7 @@ title: कैसे सुरक्षित करें API Keys का उप
 
 ### आवश्यक शर्तें
 
-- [Subgraph Studio](https://thegraph.com/studio) से एक API कुंजी
+-  [Subgraph Studio](https://thegraph.com/studio) से एक API कुंजी
 - Next.js और React का बुनियादी ज्ञान
 - एक मौजूदा Next.js प्रोजेक्ट जो App Router (https://nextjs.org/docs/app). का उपयोग करता है।
 

From fda1dcbe67d6122828de83ba29ef601061788559 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:04 -0500
Subject: [PATCH 0317/3820] New translations supported-network-requirements.mdx
 (Romanian)

---
 .../ro/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/ro/supported-network-requirements.mdx b/website/pages/ro/supported-network-requirements.mdx
index df15ef48d762..afbf755c0a5a 100644
--- a/website/pages/ro/supported-network-requirements.mdx
+++ b/website/pages/ro/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Network | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 4c8e179a5b23573e7a5d2d846e5d33ab87c72fdf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:06 -0500
Subject: [PATCH 0318/3820] New translations supported-network-requirements.mdx
 (French)

---
 .../fr/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/fr/supported-network-requirements.mdx b/website/pages/fr/supported-network-requirements.mdx
index 40d53ab2c69b..8df2bb4bc660 100644
--- a/website/pages/fr/supported-network-requirements.mdx
+++ b/website/pages/fr/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Réseau | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Réseau    | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 3c00724288f05658ce2518e962204c182342c639 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:07 -0500
Subject: [PATCH 0319/3820] New translations supported-network-requirements.mdx
 (Spanish)

---
 .../es/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/es/supported-network-requirements.mdx b/website/pages/es/supported-network-requirements.mdx
index dfebec344880..c06461d981d6 100644
--- a/website/pages/es/supported-network-requirements.mdx
+++ b/website/pages/es/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Red | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Red       | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From e9da6faf366f3f0c8cd66603935a46fdbe781c57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:08 -0500
Subject: [PATCH 0320/3820] New translations supported-network-requirements.mdx
 (Arabic)

---
 .../ar/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/ar/supported-network-requirements.mdx b/website/pages/ar/supported-network-requirements.mdx
index 9c820d055399..811fb2a8cec7 100644
--- a/website/pages/ar/supported-network-requirements.mdx
+++ b/website/pages/ar/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Network | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| بوليجون | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| بوليجون   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 10028f7b3eba38fa6b031919b18475057263c12f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:09 -0500
Subject: [PATCH 0321/3820] New translations supported-network-requirements.mdx
 (Czech)

---
 .../cs/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/cs/supported-network-requirements.mdx b/website/pages/cs/supported-network-requirements.mdx
index a81118cec231..efbee1c17750 100644
--- a/website/pages/cs/supported-network-requirements.mdx
+++ b/website/pages/cs/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Síť | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Síť       | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 26bba5648a773a4e920138e616c576e863ebc516 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:13 -0500
Subject: [PATCH 0322/3820] New translations supported-network-requirements.mdx
 (German)

---
 .../de/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/de/supported-network-requirements.mdx b/website/pages/de/supported-network-requirements.mdx
index df15ef48d762..afbf755c0a5a 100644
--- a/website/pages/de/supported-network-requirements.mdx
+++ b/website/pages/de/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Network | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 97bf664f4ffe668448593c9db0debe7390802910 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:15 -0500
Subject: [PATCH 0323/3820] New translations supported-network-requirements.mdx
 (Italian)

---
 .../it/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/it/supported-network-requirements.mdx b/website/pages/it/supported-network-requirements.mdx
index 7eed955d1013..88be77e74cc8 100644
--- a/website/pages/it/supported-network-requirements.mdx
+++ b/website/pages/it/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| La rete | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| La rete   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From d6e78c003b170bfe016d88c8579f61eebce1ff63 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:16 -0500
Subject: [PATCH 0324/3820] New translations supported-network-requirements.mdx
 (Japanese)

---
 .../ja/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/ja/supported-network-requirements.mdx b/website/pages/ja/supported-network-requirements.mdx
index 6aa0c0caa16f..99ceda419e06 100644
--- a/website/pages/ja/supported-network-requirements.mdx
+++ b/website/pages/ja/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| ネットワーク | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| ネットワーク    | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 7b3c8ddf46623cc3543c360e198ef0cac8c966f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:17 -0500
Subject: [PATCH 0325/3820] New translations supported-network-requirements.mdx
 (Korean)

---
 .../ko/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/ko/supported-network-requirements.mdx b/website/pages/ko/supported-network-requirements.mdx
index df15ef48d762..afbf755c0a5a 100644
--- a/website/pages/ko/supported-network-requirements.mdx
+++ b/website/pages/ko/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Network | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From def5d12b7dd07e69c1008157219aed78586a7ed5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:18 -0500
Subject: [PATCH 0326/3820] New translations supported-network-requirements.mdx
 (Dutch)

---
 .../nl/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/nl/supported-network-requirements.mdx b/website/pages/nl/supported-network-requirements.mdx
index 9bfbc8d0fefd..4a5d2fa8f364 100644
--- a/website/pages/nl/supported-network-requirements.mdx
+++ b/website/pages/nl/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Netwerk | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Netwerk   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 5cd0d266c03b5dfa24b6f265b0b2dcba422aa020 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:19 -0500
Subject: [PATCH 0327/3820] New translations supported-network-requirements.mdx
 (Polish)

---
 .../pl/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/pl/supported-network-requirements.mdx b/website/pages/pl/supported-network-requirements.mdx
index df15ef48d762..afbf755c0a5a 100644
--- a/website/pages/pl/supported-network-requirements.mdx
+++ b/website/pages/pl/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Network | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From f85c52bb4aa88bead2b692abcac93467a329aed3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:26 -0500
Subject: [PATCH 0328/3820] New translations supported-network-requirements.mdx
 (Portuguese)

---
 .../pt/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/pt/supported-network-requirements.mdx b/website/pages/pt/supported-network-requirements.mdx
index d678f0534f01..c1bd4433f1d7 100644
--- a/website/pages/pt/supported-network-requirements.mdx
+++ b/website/pages/pt/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Requisitos de Redes Apoiadas
 ---
 
-| Rede | Guias | Requisitos de sistema | Recompensas de Indexação |
-| --- | --- | --- | :-: |
-| Arbitrum | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Guia Docker](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | CPU de 4+ núcleos<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= SSD NVMe com mais de 8 TiB<br /> _última atualização em agosto de 2023_ | ✅ |
-| Avalanche | [Guia Docker](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> SSD NVMe com mais de 5 TiB<br /> _última atualização em agosto de 2023_ | ✅ |
-| Base | [Guia Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [Guia GETH Baremetal](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [Guia GETH Docker](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | CPU de 8+ núcleos<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> mais 4.5TB (NVMe preferido)<br /> _última atualização em 14 de maio de 2024_ | ✅ |
-| Binance | [Guia Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | CPU de 8 núcleos e 16 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> NVMe SSD com mais de 14 TiB<br /> _última atualização em 22 de junho de 2024_ | ✅ |
-| Celo | [Guia Docker](https://docs.infradao.com/archive-nodes-101/celo/docker) | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= SSD NVMe com mais de 2 TiB<br /> _última atualização em agosto de 2023_ | ✅ |
-| Ethereum | [Guia Docker](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Frequência de clock maior que número de núcleos<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> Mais de 3TB (NVMe recomendado)<br /> _última atualização em agosto de 2023_ | ✅ |
-| Fantom | [Guia Docker](https://docs.infradao.com/archive-nodes-101/fantom/docker) | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> SSD NVMe com mais de 13 TiB<br /> _última atualização em agosto de 2023_ | ✅ |
-| Gnosis | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | CPU de 6 núcleos e 12 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> NVMe SSD com mais de 3 TiB<br /> _última atualização em agosto de 2023_ | ✅ |
-| Linea | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | CPU de 4+ núcleos<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= SSD NVMe com mais de 1 TiB<br /> _última atualização em 2 de abril de 2024_ | ✅ |
-| Optimism | [Guia Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [Guia GETH Baremetal](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [Guia GETH Docker](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> SSD NVMe com mais de 8 TiB<br /> _última atualização em agosto de 2023_ | ✅ |
-| Polygon | [Guia Docker](https://docs.infradao.com/archive-nodes-101/polygon/docker) | CPU de 16 núcleos<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= SSD NVMe com mais de 10 TiB<br /> _última atualização em agosto de 2023_ | ✅ |
-| Scroll | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Guia Docker](https://docs.infradao.com/archive-nodes-101/scroll/docker) | CPU de 4 núcleos e 8 threads<br /> Debian 12<br /> 16GB+ RAM<br /> SSD NVMe com mais de 1 TiB<br /> _última atualização em 3 de abril de 2024_ | ✅ |
+| Rede      | Guias                                                                                                                                                                                                                                                                                            | Requisitos de sistema                                                                                                                                                | Recompensas de Indexação |
+| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------: |
+| Arbitrum  | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Guia Docker](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                | CPU de 4+ núcleos<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= SSD NVMe com mais de 8 TiB<br /> _última atualização em agosto de 2023_                                |             ✅            |
+| Avalanche | [Guia Docker](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                      | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> SSD NVMe com mais de 5 TiB<br /> _última atualização em agosto de 2023_                        |             ✅            |
+| Base      | [Guia Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [Guia GETH Baremetal](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [Guia GETH Docker](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | CPU de 8+ núcleos<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> mais 4.5TB (NVMe preferido)<br /> _última atualização em 14 de maio de 2024_                    |             ✅            |
+| Binance   | [Guia Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                    | CPU de 8 núcleos e 16 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> NVMe SSD com mais de 14 TiB<br /> _última atualização em 22 de junho de 2024_                 |             ✅            |
+| Celo      | [Guia Docker](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                           | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= SSD NVMe com mais de 2 TiB<br /> _última atualização em agosto de 2023_                     |             ✅            |
+| Ethereum  | [Guia Docker](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                | Frequência de clock maior que número de núcleos<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> Mais de 3TB (NVMe recomendado)<br /> _última atualização em agosto de 2023_ |             ✅            |
+| Fantom    | [Guia Docker](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                         | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> SSD NVMe com mais de 13 TiB<br /> _última atualização em agosto de 2023_                       |             ✅            |
+| Gnosis    | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                            | CPU de 6 núcleos e 12 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> NVMe SSD com mais de 3 TiB<br /> _última atualização em agosto de 2023_                       |             ✅            |
+| Linea     | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                    | CPU de 4+ núcleos<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= SSD NVMe com mais de 1 TiB<br /> _última atualização em 2 de abril de 2024_                            |             ✅            |
+| Optimism  | [Guia Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [Guia GETH Baremetal](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [Guia GETH Docker](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> SSD NVMe com mais de 8 TiB<br /> _última atualização em agosto de 2023_                        |             ✅            |
+| Polygon   | [Guia Docker](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                        | CPU de 16 núcleos<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= SSD NVMe com mais de 10 TiB<br /> _última atualização em agosto de 2023_                               |             ✅            |
+| Scroll    | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Guia Docker](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                    | CPU de 4 núcleos e 8 threads<br /> Debian 12<br /> 16GB+ RAM<br /> SSD NVMe com mais de 1 TiB<br /> _última atualização em 3 de abril de 2024_                       |             ✅            |

From 4980ae354fbf3f561bf798ffb2f7d246977bd037 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:27 -0500
Subject: [PATCH 0329/3820] New translations supported-network-requirements.mdx
 (Russian)

---
 .../ru/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/ru/supported-network-requirements.mdx b/website/pages/ru/supported-network-requirements.mdx
index abc7b820fde7..21a6f62ebb20 100644
--- a/website/pages/ru/supported-network-requirements.mdx
+++ b/website/pages/ru/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Сеть | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Арбитрум | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Сеть      | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Арбитрум  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 24c51811cb4599000fa349bf3782ff1f9526fc7d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:29 -0500
Subject: [PATCH 0330/3820] New translations supported-network-requirements.mdx
 (Swedish)

---
 .../sv/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/sv/supported-network-requirements.mdx b/website/pages/sv/supported-network-requirements.mdx
index f7a4943afd1b..f6c91108bac9 100644
--- a/website/pages/sv/supported-network-requirements.mdx
+++ b/website/pages/sv/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Nätverk | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Nätverk   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 77af380bb9b352d17ee5bde521ed01e5f8a55255 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:30 -0500
Subject: [PATCH 0331/3820] New translations supported-network-requirements.mdx
 (Turkish)

---
 .../tr/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/tr/supported-network-requirements.mdx b/website/pages/tr/supported-network-requirements.mdx
index 5329c6b9dad2..73adcca0dded 100644
--- a/website/pages/tr/supported-network-requirements.mdx
+++ b/website/pages/tr/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Ağ | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Ağ        | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 03accd42291c831d07a22bc7219d78a35b0cb74e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:31 -0500
Subject: [PATCH 0332/3820] New translations supported-network-requirements.mdx
 (Ukrainian)

---
 .../uk/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/uk/supported-network-requirements.mdx b/website/pages/uk/supported-network-requirements.mdx
index df15ef48d762..afbf755c0a5a 100644
--- a/website/pages/uk/supported-network-requirements.mdx
+++ b/website/pages/uk/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Network | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 69914ad5d7a82ffb4cdec120d1f362c03ae11ff3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:38 -0500
Subject: [PATCH 0333/3820] New translations supported-network-requirements.mdx
 (Chinese Simplified)

---
 .../zh/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/zh/supported-network-requirements.mdx b/website/pages/zh/supported-network-requirements.mdx
index 62bb55c63746..d9e844cbbe43 100644
--- a/website/pages/zh/supported-network-requirements.mdx
+++ b/website/pages/zh/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| 网络 | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| 以太坊 | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| 网络        | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| 以太坊       | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 71cf9954d468817e2a86f3285d2afd1df4bb1928 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:39 -0500
Subject: [PATCH 0334/3820] New translations supported-network-requirements.mdx
 (Urdu (Pakistan))

---
 .../ur/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/ur/supported-network-requirements.mdx b/website/pages/ur/supported-network-requirements.mdx
index f4b5a7768f13..ee345dee7c3f 100644
--- a/website/pages/ur/supported-network-requirements.mdx
+++ b/website/pages/ur/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| نیٹ ورک | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| نیٹ ورک   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 9c45096351e3f27eb0d21bab617eb887c8711740 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:40 -0500
Subject: [PATCH 0335/3820] New translations supported-network-requirements.mdx
 (Vietnamese)

---
 .../vi/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/vi/supported-network-requirements.mdx b/website/pages/vi/supported-network-requirements.mdx
index 50cd5e88b459..a8305e895706 100644
--- a/website/pages/vi/supported-network-requirements.mdx
+++ b/website/pages/vi/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Mạng lưới | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Mạng lưới | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 747f719a27db3dba91440793d4c252a367ec75ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:41 -0500
Subject: [PATCH 0336/3820] New translations supported-network-requirements.mdx
 (Marathi)

---
 .../mr/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/mr/supported-network-requirements.mdx b/website/pages/mr/supported-network-requirements.mdx
index a1a9e0338649..8d20c31f3fc5 100644
--- a/website/pages/mr/supported-network-requirements.mdx
+++ b/website/pages/mr/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Network | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| हिमस्खलन | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| इथरियम | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| फॅन्टम | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| आशावाद | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| बहुभुज | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Network  | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| हिमस्खलन | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base     | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo     | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| इथरियम   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| फॅन्टम   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis   | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| आशावाद   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| बहुभुज   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll   | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 06540dba4aaad70b2a98f9e4615963ead945085c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:42 -0500
Subject: [PATCH 0337/3820] New translations supported-network-requirements.mdx
 (Hindi)

---
 .../hi/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/hi/supported-network-requirements.mdx b/website/pages/hi/supported-network-requirements.mdx
index 647eda3e6651..29673e7529a7 100644
--- a/website/pages/hi/supported-network-requirements.mdx
+++ b/website/pages/hi/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| नेटवर्क | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _अंतिम बार अपडेट किया गया 22 जून 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| नेटवर्क   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _अंतिम बार अपडेट किया गया 22 जून 2024_    |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From f5fcd1cd885135ba7e65cfd3f335ec42ebc861d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:44 -0500
Subject: [PATCH 0338/3820] New translations supported-network-requirements.mdx
 (Swahili)

---
 .../sw/supported-network-requirements.mdx     | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/sw/supported-network-requirements.mdx b/website/pages/sw/supported-network-requirements.mdx
index df15ef48d762..afbf755c0a5a 100644
--- a/website/pages/sw/supported-network-requirements.mdx
+++ b/website/pages/sw/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Supported Network Requirements
 ---
 
-| Network | Guides | System Requirements | Indexing Rewards |
-| --- | --- | --- | :-: |
-| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Base | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker) | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_ | ✅ |
-| Binance | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal) | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_ | ✅ |
-| Celo | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Ethereum | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker) | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ | ✅ |
-| Fantom | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Gnosis | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal) | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Linea | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal) | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_ | ✅ |
-| Optimism | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Polygon | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker) | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_ | ✅ |
-| Scroll | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker) | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_ | ✅ |
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From f063251dab231185d51df88b2bb684da6142979c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:48 -0500
Subject: [PATCH 0339/3820] New translations triggers-example.mdx (Romanian)

---
 website/pages/ro/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/sps/triggers-example.mdx b/website/pages/ro/sps/triggers-example.mdx
index bb278b7f0eee..495298871a22 100644
--- a/website/pages/ro/sps/triggers-example.mdx
+++ b/website/pages/ro/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Prerequisites

From 0819445c3802c571ea844bdf5a1185f72717b077 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:49 -0500
Subject: [PATCH 0340/3820] New translations triggers-example.mdx (Spanish)

---
 website/pages/es/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/sps/triggers-example.mdx b/website/pages/es/sps/triggers-example.mdx
index f5b1d99ba473..b52cd3cf42e3 100644
--- a/website/pages/es/sps/triggers-example.mdx
+++ b/website/pages/es/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Prerrequisitos

From 19b1196784120e87009bbbd2962dbc8cd0a0d658 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:50 -0500
Subject: [PATCH 0341/3820] New translations triggers-example.mdx (Arabic)

---
 website/pages/ar/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/sps/triggers-example.mdx b/website/pages/ar/sps/triggers-example.mdx
index 943e9898ed14..3c1909f87ac8 100644
--- a/website/pages/ar/sps/triggers-example.mdx
+++ b/website/pages/ar/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## المتطلبات الأساسية

From b20381c246ce3998c7d539681e6a1050b62b7d60 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:51 -0500
Subject: [PATCH 0342/3820] New translations triggers-example.mdx (Czech)

---
 website/pages/cs/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/sps/triggers-example.mdx b/website/pages/cs/sps/triggers-example.mdx
index 70dda12c61fd..a25f86fd5aa6 100644
--- a/website/pages/cs/sps/triggers-example.mdx
+++ b/website/pages/cs/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Požadavky

From 257743d6e8877418eb20481d7f773c0f401ef327 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:58 -0500
Subject: [PATCH 0343/3820] New translations triggers-example.mdx (German)

---
 website/pages/de/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/sps/triggers-example.mdx b/website/pages/de/sps/triggers-example.mdx
index bb278b7f0eee..495298871a22 100644
--- a/website/pages/de/sps/triggers-example.mdx
+++ b/website/pages/de/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Prerequisites

From 7db10dc061e1355a27769795d5a9300dc649b99c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:14:59 -0500
Subject: [PATCH 0344/3820] New translations triggers-example.mdx (Italian)

---
 website/pages/it/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/sps/triggers-example.mdx b/website/pages/it/sps/triggers-example.mdx
index bb278b7f0eee..495298871a22 100644
--- a/website/pages/it/sps/triggers-example.mdx
+++ b/website/pages/it/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Prerequisites

From 01c5440a9f8fdc2fb61298d452fc3a132ebfd2e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:00 -0500
Subject: [PATCH 0345/3820] New translations triggers-example.mdx (Japanese)

---
 website/pages/ja/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/sps/triggers-example.mdx b/website/pages/ja/sps/triggers-example.mdx
index b547721bc3c7..7c513edec723 100644
--- a/website/pages/ja/sps/triggers-example.mdx
+++ b/website/pages/ja/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## 前提条件

From de5c0c947cd241d1edc05f84d97df3a39da51399 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:01 -0500
Subject: [PATCH 0346/3820] New translations triggers-example.mdx (Korean)

---
 website/pages/ko/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/sps/triggers-example.mdx b/website/pages/ko/sps/triggers-example.mdx
index bb278b7f0eee..495298871a22 100644
--- a/website/pages/ko/sps/triggers-example.mdx
+++ b/website/pages/ko/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Prerequisites

From ae189f775e2bce6c84a4317bcea78c0907b8efb2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:02 -0500
Subject: [PATCH 0347/3820] New translations triggers-example.mdx (Dutch)

---
 website/pages/nl/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/sps/triggers-example.mdx b/website/pages/nl/sps/triggers-example.mdx
index bb278b7f0eee..495298871a22 100644
--- a/website/pages/nl/sps/triggers-example.mdx
+++ b/website/pages/nl/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Prerequisites

From cd9bb21588bcb27def0541a390498f08188ca2c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:04 -0500
Subject: [PATCH 0348/3820] New translations triggers-example.mdx (Polish)

---
 website/pages/pl/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/sps/triggers-example.mdx b/website/pages/pl/sps/triggers-example.mdx
index bb278b7f0eee..495298871a22 100644
--- a/website/pages/pl/sps/triggers-example.mdx
+++ b/website/pages/pl/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Prerequisites

From 29c2d9193f8ac05ecee4e80c4a5dc28ac6e35a46 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:08 -0500
Subject: [PATCH 0349/3820] New translations triggers-example.mdx (Portuguese)

---
 website/pages/pt/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/sps/triggers-example.mdx b/website/pages/pt/sps/triggers-example.mdx
index 5562eb4ee073..503fcdeab65e 100644
--- a/website/pages/pt/sps/triggers-example.mdx
+++ b/website/pages/pt/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Pré-requisitos

From e4c9c0f2fa9b1bc59ae8f642d4ad119ac82ad9d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:10 -0500
Subject: [PATCH 0350/3820] New translations triggers-example.mdx (Swedish)

---
 website/pages/sv/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/sps/triggers-example.mdx b/website/pages/sv/sps/triggers-example.mdx
index 8140015d7721..f0419707408a 100644
--- a/website/pages/sv/sps/triggers-example.mdx
+++ b/website/pages/sv/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Förutsättningar

From 8f2c9f58b63d8b917d8d937256a4d385aa66c69e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:11 -0500
Subject: [PATCH 0351/3820] New translations triggers-example.mdx (Turkish)

---
 website/pages/tr/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/sps/triggers-example.mdx b/website/pages/tr/sps/triggers-example.mdx
index 219363637aaa..4301c586e460 100644
--- a/website/pages/tr/sps/triggers-example.mdx
+++ b/website/pages/tr/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Ön Koşullar

From 71968377386a2e7f86098e8690b443549d333d63 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:12 -0500
Subject: [PATCH 0352/3820] New translations triggers-example.mdx (Ukrainian)

---
 website/pages/uk/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/sps/triggers-example.mdx b/website/pages/uk/sps/triggers-example.mdx
index bb278b7f0eee..495298871a22 100644
--- a/website/pages/uk/sps/triggers-example.mdx
+++ b/website/pages/uk/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Prerequisites

From 13d094be1ddb8e1135cdfc10fc4cc389ea17d0ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:18 -0500
Subject: [PATCH 0353/3820] New translations triggers-example.mdx (Chinese
 Simplified)

---
 website/pages/zh/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/sps/triggers-example.mdx b/website/pages/zh/sps/triggers-example.mdx
index 9782a9989ba5..657a4d2402e2 100644
--- a/website/pages/zh/sps/triggers-example.mdx
+++ b/website/pages/zh/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## 先决条件

From b95cc3c218e6deb0e7a67bd5309ad9f523276bf0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:19 -0500
Subject: [PATCH 0354/3820] New translations triggers-example.mdx (Urdu
 (Pakistan))

---
 website/pages/ur/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/sps/triggers-example.mdx b/website/pages/ur/sps/triggers-example.mdx
index eb250dc250c5..604c864981b7 100644
--- a/website/pages/ur/sps/triggers-example.mdx
+++ b/website/pages/ur/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## شرطیں

From 52e8a94ca7d267c31097dd1ab599618f8fe261ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:20 -0500
Subject: [PATCH 0355/3820] New translations triggers-example.mdx (Vietnamese)

---
 website/pages/vi/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/sps/triggers-example.mdx b/website/pages/vi/sps/triggers-example.mdx
index 8912961e3be0..3ed429e6133b 100644
--- a/website/pages/vi/sps/triggers-example.mdx
+++ b/website/pages/vi/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Điều kiện tiên quyết

From 06f0c03170029ab66fb2c01e858ee51d979678cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:21 -0500
Subject: [PATCH 0356/3820] New translations triggers-example.mdx (Marathi)

---
 website/pages/mr/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/sps/triggers-example.mdx b/website/pages/mr/sps/triggers-example.mdx
index 5291e4a404b3..7ea6674d7884 100644
--- a/website/pages/mr/sps/triggers-example.mdx
+++ b/website/pages/mr/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## पूर्वतयारी

From 90ba4974f6007ea65c834c2cfb4519c27dd60118 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:23 -0500
Subject: [PATCH 0357/3820] New translations triggers-example.mdx (Swahili)

---
 website/pages/sw/sps/triggers-example.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/sps/triggers-example.mdx b/website/pages/sw/sps/triggers-example.mdx
index bb278b7f0eee..495298871a22 100644
--- a/website/pages/sw/sps/triggers-example.mdx
+++ b/website/pages/sw/sps/triggers-example.mdx
@@ -1,5 +1,5 @@
 ---
-title: 'Tutorial: Set Up a Substreams-Powered Subgraph on Solana'
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
 ## Prerequisites

From 3d043311e2c94b9ac20d6ab4ffefbf66c149948b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:54 -0500
Subject: [PATCH 0358/3820] New translations deploy-using-subgraph-studio.mdx
 (French)

---
 website/pages/fr/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/deploying/deploy-using-subgraph-studio.mdx b/website/pages/fr/deploying/deploy-using-subgraph-studio.mdx
index 3aeb7730bd33..2d1dba965948 100644
--- a/website/pages/fr/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/fr/deploying/deploy-using-subgraph-studio.mdx
@@ -30,7 +30,7 @@ Vous devez avoir [Node.js](https://nodejs.org/) et un gestionnaire de packages d
 ### Installation avec yarn
 
 ```bash
-npm install -g @graphprotocol/graph-cli
+yarn global add @graphprotocol/graph-cli
 ```
 
 ### Installation avec npm
@@ -63,7 +63,7 @@ Pour être pris en charge par les Indexeurs sur The Graph Network, les subgraphs
 - Ne doit utiliser aucune des fonctionnalités suivantes :
   - ipfs.cat & ipfs.map
   - Erreurs non fatales
-  - La greffe
+  - Greffage
 
 ## Initialisez votre Subgraph
 

From a5c08c5c6bbba8618c4a262b70d5728fedbfa310 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:15:56 -0500
Subject: [PATCH 0359/3820] New translations deploy-using-subgraph-studio.mdx
 (Arabic)

---
 website/pages/ar/deploying/deploy-using-subgraph-studio.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/deploying/deploy-using-subgraph-studio.mdx b/website/pages/ar/deploying/deploy-using-subgraph-studio.mdx
index 3e357875b406..f20a1567749c 100644
--- a/website/pages/ar/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/ar/deploying/deploy-using-subgraph-studio.mdx
@@ -63,7 +63,7 @@ In order to be supported by Indexers on The Graph Network, subgraphs must:
 - يجب ألا تستخدم أيًا من الميزات التالية:
   - ipfs.cat & ipfs.map
   - أخطاء غير فادحة
-  - تطعيم(Grafting)
+  - Grafting
 
 ## Initialize Your Subgraph
 

From 7e72c8031ea9771d7fe55fb79a7a2ac6d18e0091 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:16:08 -0500
Subject: [PATCH 0360/3820] New translations deploy-using-subgraph-studio.mdx
 (Russian)

---
 website/pages/ru/deploying/deploy-using-subgraph-studio.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/deploying/deploy-using-subgraph-studio.mdx b/website/pages/ru/deploying/deploy-using-subgraph-studio.mdx
index b8240d68ce51..da4b08f51fa6 100644
--- a/website/pages/ru/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/ru/deploying/deploy-using-subgraph-studio.mdx
@@ -62,7 +62,7 @@ In order to be supported by Indexers on The Graph Network, subgraphs must:
 - Индексировать [поддерживаемую сеть](/developing/supported-networks)
 - Не должны использовать ни одну из следующих функций:
   - ipfs.cat & ipfs.map
-  - Неисправимые ошибки
+  - Нефатальные ошибки
   - Grafting
 
 ## Инициализация Вашего Субграфа

From dc68930fb74f96d4989ed814f6f2c8137380a4ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:16:13 -0500
Subject: [PATCH 0361/3820] New translations enums.mdx (Ukrainian)

---
 website/pages/uk/cookbook/enums.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/cookbook/enums.mdx b/website/pages/uk/cookbook/enums.mdx
index a10970c1539f..4fa07dc05765 100644
--- a/website/pages/uk/cookbook/enums.mdx
+++ b/website/pages/uk/cookbook/enums.mdx
@@ -269,6 +269,6 @@ Expected output includes the marketplaces that meet the criteria, each represent
 }
 ```
 
-## Additional Resources
+## Додаткові матеріали
 
 For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From b607933e4282013a1a53adbaef4ca7657c14faaa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:16:18 -0500
Subject: [PATCH 0362/3820] New translations deploy-using-subgraph-studio.mdx
 (Urdu (Pakistan))

---
 website/pages/ur/deploying/deploy-using-subgraph-studio.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/deploying/deploy-using-subgraph-studio.mdx b/website/pages/ur/deploying/deploy-using-subgraph-studio.mdx
index 7a0e9d8ce26e..ba1b86a17ed7 100644
--- a/website/pages/ur/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/ur/deploying/deploy-using-subgraph-studio.mdx
@@ -63,7 +63,7 @@ In order to be supported by Indexers on The Graph Network, subgraphs must:
 - درج ذیل خصوصیات میں سے کوئی بھی استعمال نہیں کرنا چاہیے:
   - ipfs.cat & ipfs.map
   - Non-fatal errors
-  - Grafting
+  - گرافٹنگ
 
 ## Initialize Your Subgraph
 

From b9b1fd8ca8e662b227b604712e7e15d25d4035bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 11:16:21 -0500
Subject: [PATCH 0363/3820] New translations enums.mdx (Marathi)

---
 website/pages/mr/cookbook/enums.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/cookbook/enums.mdx b/website/pages/mr/cookbook/enums.mdx
index a10970c1539f..081add904f9a 100644
--- a/website/pages/mr/cookbook/enums.mdx
+++ b/website/pages/mr/cookbook/enums.mdx
@@ -269,6 +269,6 @@ Expected output includes the marketplaces that meet the criteria, each represent
 }
 ```
 
-## Additional Resources
+## अतिरिक्त संसाधने
 
 For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 44c316bc4087b74c3c301faabe11734b383815ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:03:04 -0500
Subject: [PATCH 0364/3820] New translations quick-start.mdx (French)

---
 website/pages/fr/quick-start.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/quick-start.mdx b/website/pages/fr/quick-start.mdx
index 5759a2cb0dbb..acb4e3d0ba78 100644
--- a/website/pages/fr/quick-start.mdx
+++ b/website/pages/fr/quick-start.mdx
@@ -34,7 +34,7 @@ npm install -g @graphprotocol/graph-cli@latest
 Using [yarn](https://yarnpkg.com/):
 
 ```sh
-npm install -g @graphprotocol/graph-cli
+yarn global add @graphprotocol/graph-cli
 ```
 
 ### 3. Initialize your subgraph

From 9812958aea4809e32a127c74e0f23d48bebd3376 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:03:24 -0500
Subject: [PATCH 0365/3820] New translations transfer-a-subgraph.mdx (Turkish)

---
 website/pages/tr/managing/transfer-a-subgraph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/managing/transfer-a-subgraph.mdx b/website/pages/tr/managing/transfer-a-subgraph.mdx
index 78f649b0e669..25249a444d83 100644
--- a/website/pages/tr/managing/transfer-a-subgraph.mdx
+++ b/website/pages/tr/managing/transfer-a-subgraph.mdx
@@ -4,7 +4,7 @@ title: Bir Subgraph’i Transfer Etme
 
 Merkeziyetsiz ağda yayımlanan subgraph’ler, NFT olarak oluşturulup subgraph’i yayımlayan adrese gönderilir. Bu NFT, The Graph Ağı’ndaki hesaplar arasında transferi kolaylaştıran standart bir ERC721 sözleşmesini temel alır.
 
-## Hatırlatmalar
+## Reminders
 
 - NFT’ye sahip olan kişi, subgraph’in kontrolünü elinde tutar.
 - NFT’nin sahibi NFT’yi satmaya veya transfer etmeye karar verirse, artık bu subgraph’i ağ üzerinde düzenleyemez veya güncelleyemez.

From 2be5fef16e53f9ec50426e84bdcdf2aeaeaebacc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:03:26 -0500
Subject: [PATCH 0366/3820] New translations deploy-using-subgraph-studio.mdx
 (Turkish)

---
 website/pages/tr/deploying/deploy-using-subgraph-studio.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/deploying/deploy-using-subgraph-studio.mdx b/website/pages/tr/deploying/deploy-using-subgraph-studio.mdx
index eaca0a81f65f..91fb05f09292 100644
--- a/website/pages/tr/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/tr/deploying/deploy-using-subgraph-studio.mdx
@@ -62,7 +62,7 @@ Subgraph'lerin Graph Ağı Endeksleyicileri tarafından desteklenebilmesi için
 - [Desteklenen bir ağı](/developing/supported-networks) endeksliyor olmalı
 - Aşağıdaki özelliklerden hiçbirini kullanmamalı:
   - ipfs.cat & ipfs.map
-  - Kritik olmayan hatalar
+  - Ölümcül Olmayan Hatalar
   - Graftlama
 
 ## Subgraph'inizi İlklendirme

From f477a6a6c458c5e22436ddad01e375ff09848064 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:03:31 -0500
Subject: [PATCH 0367/3820] New translations transfer-to-the-graph.mdx (Hindi)

---
 website/pages/hi/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/cookbook/transfer-to-the-graph.mdx b/website/pages/hi/cookbook/transfer-to-the-graph.mdx
index caa5f49f29fa..eefabc7d2cd1 100644
--- a/website/pages/hi/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/hi/cookbook/transfer-to-the-graph.mdx
@@ -98,7 +98,7 @@ You can create API Keys in Subgraph Studio under the “API Keys” menu at the
 
 Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
 
-### अतिरिक्त संसाधन
+### Additional Resources
 
 - To quickly create and publish a new subgraph, check out the [Quick Start](/quick-start/).
 - To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 7bbcbf9cfb8af4dafeaf23259c71ed68d8e242b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:03:34 -0500
Subject: [PATCH 0368/3820] New translations unit-testing-framework.mdx
 (Russian)

---
 website/pages/ru/developing/unit-testing-framework.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/developing/unit-testing-framework.mdx b/website/pages/ru/developing/unit-testing-framework.mdx
index 698e25117b45..aa807bf64c9c 100644
--- a/website/pages/ru/developing/unit-testing-framework.mdx
+++ b/website/pages/ru/developing/unit-testing-framework.mdx
@@ -1394,7 +1394,7 @@ Global test coverage: 22.2% (2/9 handlers).
 
 Несовпадение в аргументах вызвано несоответствием в `graph-ts` и `matchstick-as`. Лучший способ устранить проблемы, подобные этой, - обновить всё до последней выпущенной версии.
 
-## Дополнительные источники
+## Дополнительные ресурсы
 
 For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
 

From ed549f7ae7f7ceaa28f44e90eca94200f3c9b756 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:03:35 -0500
Subject: [PATCH 0369/3820] New translations api.mdx (Hindi)

---
 website/pages/hi/developing/graph-ts/api.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/hi/developing/graph-ts/api.mdx b/website/pages/hi/developing/graph-ts/api.mdx
index b43331af7860..39bffd6bac80 100644
--- a/website/pages/hi/developing/graph-ts/api.mdx
+++ b/website/pages/hi/developing/graph-ts/api.mdx
@@ -1,5 +1,5 @@
 ---
-title: असेंबलीस्क्रिप्ट एपीआई
+title: AssemblyScript API
 ---
 
 > ध्यान दें: यदि आपने `graph-cli`/`graph-ts` version `0.22.0` से पहले एक subgragh बनाया है, तो आप AssemblyScript के पुराना संस्करण का उपयोग कर रहे हैं, हम अनुशंसा करते हैं कि [`Migration Guide`](/release-notes/assemblyscript-migration-guide).
@@ -13,7 +13,7 @@ title: असेंबलीस्क्रिप्ट एपीआई
 
 चूंकि भाषा मैपिंग्स AssemblyScript में लिखी गई हैं, इसलिए [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki) से भाषा और मानक पुस्तकालय की सुविधाओं की समीक्षा करना उपयोगी है।
 
-## एपीआई संदर्भ
+## API Reference
 
 The `@graphprotocol/graph-ts` library provides the following APIs:
 
@@ -25,11 +25,11 @@ The `@graphprotocol/graph-ts` library provides the following APIs:
 - A `crypto` API to use cryptographic functions.
 - एथेरियम, JSON, ग्राफक्यूएल और असेंबलीस्क्रिप्ट जैसे विभिन्न प्रकार की प्रणालियों के बीच अनुवाद करने के लिए निम्न-स्तरीय आदिम।
 
-### संस्करणों
+### Versions
 
 The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
 
-| संस्करण | रिलीज नोट्स                                                                                                                                                                                                                                   |
+| Version | Release notes                                                                                                                                                                                                                                 |
 | :-----: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 |  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
 |  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                  |
@@ -40,7 +40,7 @@ The `apiVersion` in the subgraph manifest specifies the mapping API version whic
 |  0.0.3  | Added `from` field to the Ethereum Call object<br />`etherem.call.address` renamed to `ethereum.call.to`                                                                                                                                      |
 |  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                        |
 
-### अंतर्निहित प्रकार
+### Built-in Types
 
 Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
 
@@ -809,7 +809,7 @@ When the type of a value is certain, it can be converted to a [built-in type](#b
 | String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
 | String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
 
-### डेटा स्रोत मेटाडेटा
+### Data Source Metadata
 
 You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
 

From ab4e40fb79f3989a37cd0ec9986f9e6fcabf52d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:03:57 -0500
Subject: [PATCH 0370/3820] New translations delete-a-subgraph.mdx (German)

---
 website/pages/de/managing/delete-a-subgraph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/managing/delete-a-subgraph.mdx b/website/pages/de/managing/delete-a-subgraph.mdx
index 1807741026ae..3beb3f15ff8b 100644
--- a/website/pages/de/managing/delete-a-subgraph.mdx
+++ b/website/pages/de/managing/delete-a-subgraph.mdx
@@ -6,7 +6,7 @@ Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
 
 > Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
 
-## Step-by-Step
+## Schritt für Schritt
 
 1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
 

From 8a134914e598b1fb502545c853ca64142aae9ff5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:04:23 -0500
Subject: [PATCH 0371/3820] New translations advanced.mdx (French)

---
 .../fr/developing/creating-a-subgraph/advanced.mdx     | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/fr/developing/creating-a-subgraph/advanced.mdx b/website/pages/fr/developing/creating-a-subgraph/advanced.mdx
index 7416cd495bcf..d555c847481a 100644
--- a/website/pages/fr/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/fr/developing/creating-a-subgraph/advanced.mdx
@@ -542,13 +542,13 @@ When a subgraph whose manifest contains a `graft` block is deployed, Graph Node
 
 Étant donné que le greffage copie plutôt que l'indexation des données de base, il est beaucoup plus rapide d'amener le susgraph dans le bloc souhaité que l'indexation à partir de zéro, bien que la copie initiale des données puisse encore prendre plusieurs heures pour de très gros subgraphs. Pendant l'initialisation du subgraph greffé, le nœud graphique enregistrera des informations sur les types d'entités qui ont déjà été copiés.
 
-Le subgraph greffé peut utiliser un schéma GraphQL qui n'est pas identique à celui du subgraph de base, mais simplement compatible avec celui-ci. Il doit s'agir d'un schéma de subgraph valide à part entière, mais il peut s'écarter du schéma du subgraph de base des manières suivantes :
+Le subgraph greffé peut utiliser un schema GraphQL qui n'est pas identique à celui du subgraph de base, mais simplement compatible avec lui. Il doit s'agir d'un schema de subgraph valide en tant que tel, mais il peut s'écarter du schema du subgraph de base de la manière suivante :
 
-- Il ajoute ou supprime des types d'entités
-- Il supprime les attributs des types d'entités
+- Il ajoute ou supprime des types d'entité
+- Il supprime les attributs des types d'entité
 - Il ajoute des attributs nullables aux types d'entités
-- Il transforme les attributs non nullables en attributs nullables
-- Il ajoute des valeurs aux énumérations
+- Il transforme les attributs non nullables en attributs nuls
+- Cela ajoute des valeurs aux énumérations
 - Il ajoute ou supprime des interfaces
 - Cela change pour quels types d'entités une interface est implémentée
 

From 84850f70d7a14948e6abda0b459c68e7042c688b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:04:30 -0500
Subject: [PATCH 0372/3820] New translations delete-a-subgraph.mdx (Turkish)

---
 website/pages/tr/managing/delete-a-subgraph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/managing/delete-a-subgraph.mdx b/website/pages/tr/managing/delete-a-subgraph.mdx
index 02bef8483798..1e3f81ba0c32 100644
--- a/website/pages/tr/managing/delete-a-subgraph.mdx
+++ b/website/pages/tr/managing/delete-a-subgraph.mdx
@@ -26,6 +26,6 @@ Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
 ### Important Reminders
 
 - Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
-- Küratörler artık subgraph'e sinyal veremeyecek.
+- Curators will not be able to signal on the subgraph anymore.
 - Subgraph'e halihazırda sinyal vermiş küratörler, sinyallerini ortalama hisse fiyatından geri çekebilir.
 - Deleted subgraphs will show an error message.

From 36b519346a74f874138b2c2481bca497ac657737 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:04:51 -0500
Subject: [PATCH 0373/3820] New translations graphql-api.mdx (Arabic)

---
 website/pages/ar/querying/graphql-api.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ar/querying/graphql-api.mdx b/website/pages/ar/querying/graphql-api.mdx
index 258471c1d9d4..2ae31d1fc12a 100644
--- a/website/pages/ar/querying/graphql-api.mdx
+++ b/website/pages/ar/querying/graphql-api.mdx
@@ -49,7 +49,7 @@ When querying a collection, you may:
 - Use the `orderBy` parameter to sort by a specific attribute.
 - Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
 
-#### مثال
+#### Example
 
 ```graphql
 {
@@ -295,7 +295,7 @@ The result of such a query will not change over time, i.e., querying at a certai
 
 > Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
 
-#### مثال
+#### Example
 
 ```graphql
 {
@@ -311,7 +311,7 @@ The result of such a query will not change over time, i.e., querying at a certai
 
 This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
 
-#### مثال
+#### Example
 
 ```graphql
 {

From b6b0f65021a4cd7c23d9d36be4ef9a2fdb5feb80 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:04:53 -0500
Subject: [PATCH 0374/3820] New translations transfer-to-the-graph.mdx (Arabic)

---
 website/pages/ar/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/cookbook/transfer-to-the-graph.mdx b/website/pages/ar/cookbook/transfer-to-the-graph.mdx
index 5c0446fa7fda..cb6a721e416c 100644
--- a/website/pages/ar/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/ar/cookbook/transfer-to-the-graph.mdx
@@ -74,7 +74,7 @@ graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
 
 You can start [querying](/querying/querying-the-graph/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
 
-#### مثال
+#### Example
 
 [CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
 

From ea37bcf9c05b39116ce3e987569ae4af9e74c189 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:04:55 -0500
Subject: [PATCH 0375/3820] New translations advanced.mdx (Arabic)

---
 .../pages/ar/developing/creating-a-subgraph/advanced.mdx  | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/ar/developing/creating-a-subgraph/advanced.mdx b/website/pages/ar/developing/creating-a-subgraph/advanced.mdx
index 04984ebb31a6..253555628061 100644
--- a/website/pages/ar/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/ar/developing/creating-a-subgraph/advanced.mdx
@@ -546,10 +546,10 @@ The grafted subgraph can use a GraphQL schema that is not identical to the one o
 
 - يضيف أو يزيل أنواع الكيانات
 - يزيل الصفات من أنواع الكيانات
-- يضيف صفات nullable لأنواع الكيانات
-- يحول صفات non-nullable إلى صفات nullable
-- يضيف قيما إلى enums
-- يضيف أو يزيل الواجهات
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
 - يغير للكيانات التي يتم تنفيذ الواجهة لها
 
 > **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 42465e3f0dd0bdffb3bc551ba4dc6af50af31ad6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:04:57 -0500
Subject: [PATCH 0376/3820] New translations ql-schema.mdx (Arabic)

---
 website/pages/ar/developing/creating-a-subgraph/ql-schema.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ar/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/ar/developing/creating-a-subgraph/ql-schema.mdx
index b66db45260f0..c34e0d57e597 100644
--- a/website/pages/ar/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/ar/developing/creating-a-subgraph/ql-schema.mdx
@@ -143,7 +143,7 @@ Reverse lookups can be defined on an entity through the `@derivedFrom` field. Th
 
 For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived. Storing the relationship this way, rather than storing an array of entities on the 'many' side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.
 
-#### مثال
+#### Example
 
 We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
 
@@ -164,7 +164,7 @@ type TokenBalance @entity {
 
 For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.
 
-#### مثال
+#### Example
 
 Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
 

From bcde1ae589b8382373515b8151acfca0c167d579 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:05:02 -0500
Subject: [PATCH 0377/3820] New translations api.mdx (Czech)

---
 website/pages/cs/developing/graph-ts/api.mdx | 136 +++++++++----------
 1 file changed, 68 insertions(+), 68 deletions(-)

diff --git a/website/pages/cs/developing/graph-ts/api.mdx b/website/pages/cs/developing/graph-ts/api.mdx
index ad84f9f9606d..799b8a222b5e 100644
--- a/website/pages/cs/developing/graph-ts/api.mdx
+++ b/website/pages/cs/developing/graph-ts/api.mdx
@@ -202,7 +202,7 @@ _Operators_
 - `b.concat(other: Bytes) : Bytes` - - "Vrátit nový `Bytes` skládající se z `this`, který je přímo následován `other`."
 - `b.concatI32(other: i32) : ByteArray` - vrátí nový `Bytes` složený z `this` přímo následovaný bajtovou reprezentací `other`
 
-#### Address
+#### Adresa
 
 ```typescript
 import { Address } from '@graphprotocol/graph-ts'
@@ -215,7 +215,7 @@ Přidává následující metodu nad API `Bytes`:
 - `Address.fromString(s: string): Address` - vytvoří `Address` z hexadecimálního řetězce
 - `Address.fromBytes(b: Bytes): Adresa` - vytvoří `Adresu` z `b`, která musí být dlouhá přesně 20 bajtů. Předání hodnoty s menším nebo větším počtem bajtů bude mít za následek chybu
 
-### Store API
+### API ukládat
 
 ```typescript
 import { store } from '@graphprotocol/graph-ts'
@@ -225,29 +225,29 @@ API `store` umožňuje načítat, ukládat a odebírat entity z a do úložišt
 
 Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
 
-#### Creating entities
+#### Vytváření entity
 
-The following is a common pattern for creating entities from Ethereum events.
+Následuje běžný vzor pro vytváření entity z událostí Ethereum.
 
 ```typescript
-// Import the Transfer event class generated from the ERC20 ABI
-import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+// Importovat třídu události Transfer vygenerovanou z ERC20 ABI
+import { Transfer as TransferEvent } z '../generated/ERC20/ERC20'
 
-// Import the Transfer entity type generated from the GraphQL schema
-import { Transfer } from '../generated/schema'
+// Importovat typ entity Transfer vygenerovaný ze schématu GraphQL
+import { Transfer } z '../generated/schema'
 
-// Transfer event handler
+// Obsluha události Transfer
 export function handleTransfer(event: TransferEvent): void {
-  // Create a Transfer entity, using the transaction hash as the entity ID
+  // Vytvoří entitu Transfer s použitím hashe transakce jako ID entity
   let id = event.transaction.hash
   let transfer = new Transfer(id)
 
-  // Set properties on the entity, using the event parameters
+  // Nastavte vlastnosti entity pomocí parametrů události
   transfer.from = event.params.from
   transfer.to = event.params.to
   transfer.amount = event.params.amount
 
-  // Save the entity to the store
+  // Uložení entity do úložiště
   transfer.save()
 }
 ```
@@ -258,25 +258,25 @@ Each entity must have a unique ID to avoid collisions with other entities. It is
 
 > Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
 
-#### Loading entities from the store
+#### Načítání entity z úložiště
 
-If an entity already exists, it can be loaded from the store with the following:
+Pokud již entita existuje, lze ji z úložiště načíst pomocí následujících příkazů:
 
 ```typescript
-let id = event.transaction.hash // or however the ID is constructed
+let id = event.transaction.hash // nebo jakkoli je ID konstruováno
 let transfer = Transfer.load(id)
 if (transfer == null) {
   transfer = new Transfer(id)
 }
 
-// Use the Transfer entity as before
+// Použijte entitu Transfer jako dříve
 ```
 
 As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
 
 > Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
 
-#### Looking up entities created withing a block
+#### Vyhledávání entit vytvořených v rámci bloku
 
 Od verzí `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 a `@graphprotocol/graph-cli` v0.49.0 je metoda `loadInBlock` dostupná pro všechny typy entit.
 
@@ -297,11 +297,11 @@ if (transfer == null) {
 
 > Poznámka: Pokud v daném bloku není vytvořena žádná entita, vrátí `loadInBlock` hodnotu `null`, i když v úložišti existuje entita s daným ID.
 
-#### Looking up derived entities
+#### Vyhledávání odvozených entity
 
 Od verzí `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 a `@graphprotocol/graph-cli` v0.51.0 je k dispozici metoda `loadRelated`.
 
-This enables loading derived entity fields from within an event handler. For example, given the following schema:
+To umožňuje načítání odvozených polí entityh z obsluhy události. Například při následujícím schématu:
 
 ```graphql
 type Token @entity {
@@ -320,18 +320,18 @@ Následující kód načte entitu `Token`, ze které byla odvozena entita `Holde
 
 ```typescript
 let holder = Holder.load('test-id')
-// Load the Token entities associated with a given holder
+// Načtení entit tokenů přidružených k danému držiteli
 let tokens = holder.tokens.load()
 ```
 
-#### Updating existing entities
+#### Aktualizace stávajících entity
 
-There are two ways to update an existing entity:
+Existují dva způsoby, jak aktualizovat existující entity:
 
 1. Načtěte entitu např. pomocí `Transfer.load(id)`, nastavte vlastnosti entity a poté ji `.save()` uložte zpět do úložiště.
 2. Jednoduše vytvořte entitu např. pomocí `new Transfer(id)`, nastavte vlastnosti entity a poté ji `.save()` uložte do úložiště. Pokud entita již existuje, změny se do ní sloučí.
 
-Changing properties is straight forward in most cases, thanks to the generated property setters:
+Změna vlastností je ve většině případů jednoduchá díky generovaným nastavovačům vlastností:
 
 ```typescript
 let transfer = new Transfer(id)
@@ -340,7 +340,7 @@ transfer.to = ...
 transfer.amount = ...
 ```
 
-It is also possible to unset properties with one of the following two instructions:
+Vlastnosti lze také zrušit jedním z následujících dvou příkazů:
 
 ```typescript
 transfer.from.unset()
@@ -352,18 +352,18 @@ To funguje pouze u nepovinných vlastností, tj. vlastností, které jsou v jazy
 Aktualizace vlastností pole je trochu složitější, protože získání pole z entity vytvoří kopii tohoto pole. To znamená, že vlastnosti pole je třeba po změně pole znovu explicitně nastavit. Následující příklad předpokládá, že `entita` má `čísla: [BigInt!]!` pole.
 
 ```typescript
-// This won't work
+// Tohle nebude fungovat
 entity.numbers.push(BigInt.fromI32(1))
 entity.save()
 
-// This will work
+// Toto bude fungovat
 let numbers = entity.numbers
 numbers.push(BigInt.fromI32(1))
 entity.numbers = numbers
 entity.save()
 ```
 
-#### Removing entities from the store
+#### Odstranění entit z úložiště
 
 V současné době není možné odstranit entitu prostřednictvím generovaných typů. Místo toho je pro odstranění entity nutné předat název typu entity a ID entity příkazu `store.remove`:
 
@@ -376,15 +376,15 @@ store.remove('Transfer', id)
 
 ### Ethereum API
 
-The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
+Ethereum API poskytuje přístup k inteligentním smlouvám, veřejným stavovým proměnným, funkcím smluv, událostem, transakcím, blokům a kódování/dekódování dat Etherea.
 
-#### Support for Ethereum Types
+#### Podpora typů Ethereum
 
 Stejně jako u entit generuje `graph codegen` třídy pro všechny inteligentní smlouvy a události používané v podgrafu. Za tímto účelem musí být ABI kontraktu součástí zdroje dat v manifestu podgrafu. Obvykle jsou soubory ABI uloženy ve složce `abis/`.
 
 Ve vygenerovaných třídách probíhají konverze mezi typy Ethereum [built-in-types](#built-in-types) v pozadí, takže se o ně autoři podgraf nemusí starat.
 
-The following example illustrates this. Given a subgraph schema like
+To ilustruje následující příklad. Je dáno schéma podgrafu, jako je
 
 ```graphql
 type Transfer @entity {
@@ -406,7 +406,7 @@ transfer.amount = event.params.amount
 transfer.save()
 ```
 
-#### Events and Block/Transaction Data
+#### Události a bloková/transakční data
 
 Události Ethereum předávané obsluze událostí, jako je událost `Transfer` v předchozích příkladech, poskytují přístup nejen k parametrům události, ale také k nadřazené transakci a bloku, jehož jsou součástí. Z instancí `event` (tyto třídy jsou součástí modulu `ethereum` v `graph-ts`) lze získat následující údaje:
 
@@ -481,23 +481,23 @@ class Log {
 }
 ```
 
-#### Access to Smart Contract State
+#### Přístup ke stavu inteligentní smlouvy
 
 Kód vygenerovaný nástrojem `graph codegen` obsahuje také třídy pro inteligentní smlouvy používané v podgrafu. Ty lze použít k přístupu k veřejným stavovým proměnným a k volání funkcí kontraktu v aktuálním bloku.
 
-A common pattern is to access the contract from which an event originates. This is achieved with the following code:
+Běžným vzorem je přístup ke smlouvě, ze které událost pochází. Toho lze dosáhnout pomocí následujícího kódu:
 
 ```typescript
-// Import the generated contract class and generated Transfer event class
-import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
-// Import the generated entity class
-import { Transfer } from '../generated/schema'
+// Import vygenerované třídy smlouvy a vygenerované třídy události Transfer
+import { ERC20Contract, Transfer as TransferEvent } z '../generated/ERC20Contract/ERC20Contract'
+// Importovat vygenerovanou třídu entit
+import { Transfer } z "../generated/schema
 
 export function handleTransfer(event: TransferEvent) {
-  // Bind the contract to the address that emitted the event
+  // Vázat smlouvu na adresu, která událost vyslala
   let contract = ERC20Contract.bind(event.address)
 
-  // Access state variables and functions by calling them
+  // Přístup ke stavovým proměnným a funkcím jejich voláním
   let erc20Symbol = contract.symbol()
 }
 ```
@@ -506,9 +506,9 @@ export function handleTransfer(event: TransferEvent) {
 
 Pokud má smlouva `ERC20Contract` na platformě Ethereum veřejnou funkci pouze pro čtení s názvem `symbol`, lze ji volat pomocí `.symbol()`. Pro veřejné stavové proměnné se automaticky vytvoří metoda se stejným názvem.
 
-Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address.
+Jakákoli jiná smlouva, která je součástí podgrafu, může být importována z vygenerovaného kódu a může být svázána s platnou adresou.
 
-#### Handling Reverted Calls
+#### Zpracování vrácených volání
 
 If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
 
@@ -526,7 +526,7 @@ if (callResult.reverted) {
 
 > Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
 
-#### Encoding/Decoding ABI
+#### Kódování/dekódování ABI
 
 Data lze kódovat a dekódovat podle formátu kódování ABI Ethereum pomocí funkcí `encode` a `decode` v modulu `ethereum`.
 
@@ -545,7 +545,7 @@ let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
 let decoded = ethereum.decode('(address,uint256)', encoded)
 ```
 
-For more information:
+Více informací:
 
 - [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
 - Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
@@ -598,9 +598,9 @@ The `log` API allows subgraphs to log information to the Graph Node standard out
 log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
 ```
 
-#### Logging one or more values
+#### Zaznamenávání jedné nebo více hodnot
 
-##### Logging a single value
+##### Zaznamenávání jedné hodnoty
 
 V níže uvedeném příkladu je řetězcová hodnota "A" předána do pole a stane se z ní `['A']`, než je zapsána:
 
@@ -613,9 +613,9 @@ export function handleSomeEvent(event: SomeEvent): void {
 }
 ```
 
-##### Logging a single entry from an existing array
+##### Protokolování jedné položky z existujícího pole
 
-In the example below, only the first value of the argument array is logged, despite the array containing three values.
+V příkladu níže je zaznamenána pouze první hodnota pole argumentů, přestože pole obsahuje tři hodnoty.
 
 ```typescript
 let myArray = ['A', 'B', 'C']
@@ -626,7 +626,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 }
 ```
 
-#### Logging multiple entries from an existing array
+#### Protokolování více záznamů z existujícího pole
 
 Každá položka v poli argumentů vyžaduje vlastní zástupný znak `{}` v řetězci zprávy protokolu. Níže uvedený příklad obsahuje tři zástupné zna. Z tohoto důvodu jsou zaznamenány všechny tři hodnoty v poli `myArray`.
 
@@ -639,9 +639,9 @@ export function handleSomeEvent(event: SomeEvent): void {
 }
 ```
 
-##### Logging a specific entry from an existing array
+##### Protokolování konkrétní položky z existujícího pole
 
-To display a specific value in the array, the indexed value must be provided.
+Chcete-li zobrazit konkrétní hodnotu v poli, je třeba zadat indexovanou hodnotu.
 
 ```typescript
 export function handleSomeEvent(event: SomeEvent): void {
@@ -650,9 +650,9 @@ export function handleSomeEvent(event: SomeEvent): void {
 }
 ```
 
-##### Logging event information
+##### Zaznamenávání informací o událostech
 
-The example below logs the block number, block hash and transaction hash from an event:
+Níže uvedený příklad zaznamenává číslo bloku, hash bloku a hash transakce z události:
 
 ```typescript
 import { log } from '@graphprotocol/graph-ts'
@@ -674,17 +674,17 @@ import { ipfs } from '@graphprotocol/graph-ts'
 
 Chytré smlouvy příležitostně ukotvují soubory IPFS v řetězci. To umožňuje mapování získat hashe IPFS ze smlouvy a načíst odpovídající soubory z IPFS. Data souborů budou vrácena jako `Bajty`, což obvykle vyžaduje další zpracování, např. pomocí API `json` zdokumentovaného později na této stránce.
 
-Given an IPFS hash or path, reading a file from IPFS is done as follows:
+Při zadání hashe nebo cesty IPFS se čtení souboru ze systému IPFS provádí následujícím způsobem:
 
 ```typescript
-// Put this inside an event handler in the mapping
+// Vložte to do obsluhy události v mapování
 let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
 let data = ipfs.cat(hash)
 
-// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
-// that include files in directories are also supported
+// Cesty jako `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// které obsahují soubory v adresářích, jsou také podporovány
 let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
-let data = ipfs.cat(path)
+let data = ipfs.cat(cesta)
 ```
 
 **Poznámka:** `ipfs.cat` není v současné době deterministický. Pokud se soubor nepodaří načíst přes síť IPFS před vypršením požadavku, vrátí se `null`. Z tohoto důvodu se vždy vyplatí zkontrolovat výsledek na `null`.
@@ -692,11 +692,11 @@ let data = ipfs.cat(path)
 Pomocí nástroje `ipfs.map` je také možné zpracovávat větší soubory proudovým způsobem. Funkce očekává hash nebo cestu k souboru IPFS, název zpětného volání a příznaky pro úpravu chování:
 
 ```typescript
-import { JSONValue, Value } from '@graphprotocol/graph-ts'
+import { JSONValue, Value } z '@graphprotocol/graph-ts'
 
 export function processItem(value: JSONValue, userData: Value): void {
-  // See the JSONValue documentation for details on dealing
-  // with JSON values
+  // Podrobnosti o zpracování viz dokumentace k JSONValue
+  // s hodnotami JSON
   let obj = value.toObject()
   let id = obj.get('id')
   let title = obj.get('title')
@@ -705,17 +705,17 @@ export function processItem(value: JSONValue, userData: Value): void {
     return
   }
 
-  // Callbacks can also created entities
+  // Callbacky mohou také vytvářet entity
   let newItem = new Item(id)
   newItem.title = title.toString()
-  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.parent = userData.toString() // Nastavit rodiče na "parentId"
   newitem.save()
 }
 
-// Put this inside an event handler in the mapping
+// Toto vložte do obsluhy události v mapování
 ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
 
-// Alternatively, use `ipfs.mapJSON`
+// Případně použijte `ipfs.mapJSON`
 ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
 ```
 
@@ -768,7 +768,7 @@ Pokud je typ hodnoty jistý, lze ji převést na [vestavěný typ](#built-in-typ
 - `value.toString(): string`
 - `value.toArray(): Array<JSONValue>` - (a poté převést `JSONValue` pomocí jedné z 5 výše uvedených metod)
 
-### Type Conversions Reference
+### Převody typů Reference
 
 | Zdroj(e)               | Destinace              | Funkce převodu               |
 | ---------------------- | ---------------------- | ---------------------------- |
@@ -817,7 +817,7 @@ Adresu smlouvy, síť a kontext zdroje dat, který obslužnou rutinu vyvolal, m
 - `dataSource.network(): string`
 - `dataSource.context(): DataSourceContext`
 
-### Entity and DataSourceContext
+### Entity a DataSourceContext
 
 Základní třída `Entity` a podřízená třída `DataSourceContext` mají pomocníky pro dynamické nastavování a získávání polí:
 
@@ -834,7 +834,7 @@ Základní třída `Entity` a podřízená třída `DataSourceContext` mají pom
 - `getBoolean(key: string): boolean`
 - `getBigDecimal(key: string): BigDecimal`
 
-### DataSourceContext in Manifest
+### DataSourceContext v manifestu
 
 Sekce `context` v rámci `dataSources` umožňuje definovat páry klíč-hodnota, které jsou přístupné v rámci mapování podgrafů. Dostupné typy jsou `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List` a `BigInt`.
 
@@ -887,4 +887,4 @@ dataSources:
 - `Seznam`: Určuje seznam položek. U každé položky je třeba zadat její typ a data.
 - `BigInt`: Určuje velkou celočíselnou hodnotu. Kvůli velké velikosti musí být uvedena v uvozovkách.
 
-This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.
+Tento kontext je pak přístupný v souborech mapování podgrafů, což umožňuje vytvářet dynamičtější a konfigurovatelnější podgrafy.

From 64242e93d7ef5f29f3f0cfaf780e4e4d512414ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:05:05 -0500
Subject: [PATCH 0378/3820] New translations advanced.mdx (Czech)

---
 website/pages/cs/developing/creating-a-subgraph/advanced.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/cs/developing/creating-a-subgraph/advanced.mdx b/website/pages/cs/developing/creating-a-subgraph/advanced.mdx
index fc663d24324b..72853c4c067a 100644
--- a/website/pages/cs/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/cs/developing/creating-a-subgraph/advanced.mdx
@@ -542,13 +542,13 @@ When a subgraph whose manifest contains a `graft` block is deployed, Graph Node
 
 Protože se při roubování základní data spíše kopírují než indexují, je mnohem rychlejší dostat podgraf do požadovaného bloku než při indexování od nuly, i když počáteční kopírování dat může u velmi velkých podgrafů trvat i několik hodin. Během inicializace roubovaného podgrafu bude uzel Graf Uzel zaznamenávat informace o typů entit, které již byly zkopírovány.
 
-Roubované podgraf může používat schéma GraphQL, které není totožné se schématem základního podgrafu, ale je s ním pouze kompatibilní. Musí to být platné schéma podgrafu jako takové, ale může se od schématu základního podgrafu odchýlit následujícími způsoby:
+Štěpovaný podgraf může používat schéma GraphQL, které není totožné se schématem základního podgrafu, ale je s ním pouze kompatibilní. Musí to být platné schéma podgrafu jako takové, ale může se od schématu základního podgrafu odchýlit následujícími způsoby:
 
 - Přidává nebo odebírá typy entit
 - Odstraňuje atributy z typů entit
 - Přidává nulovatelné atributy k typům entit
 - Mění nenulovatelné atributy na nulovatelné atributy
-- Přidává hodnoty de enums
+- Přidává hodnoty do enums
 - Přidává nebo odebírá rozhraní
 - Mění se, pro které typy entit je rozhraní implementováno
 

From e6c11f9f14931bcb0d819ab448ae8e69e0098725 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:05:12 -0500
Subject: [PATCH 0379/3820] New translations graphql-api.mdx (German)

---
 website/pages/de/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/querying/graphql-api.mdx b/website/pages/de/querying/graphql-api.mdx
index abe9db8cc7f4..dddbf69370b1 100644
--- a/website/pages/de/querying/graphql-api.mdx
+++ b/website/pages/de/querying/graphql-api.mdx
@@ -295,7 +295,7 @@ The result of such a query will not change over time, i.e., querying at a certai
 
 > Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
 
-#### Example
+#### Beispiel
 
 ```graphql
 {

From 02ab2def913e5436e8400e79c3926477a4c2d2ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:05:15 -0500
Subject: [PATCH 0380/3820] New translations transfer-to-the-graph.mdx (German)

---
 website/pages/de/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/cookbook/transfer-to-the-graph.mdx b/website/pages/de/cookbook/transfer-to-the-graph.mdx
index 3844b7a94142..c9017d23b88f 100644
--- a/website/pages/de/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/de/cookbook/transfer-to-the-graph.mdx
@@ -74,7 +74,7 @@ graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
 
 You can start [querying](/querying/querying-the-graph/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
 
-#### Example
+#### Beispiel
 
 [CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
 

From e1e2de523f40df1ad4dc3532555bf2743bfe2035 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:05:18 -0500
Subject: [PATCH 0381/3820] New translations ql-schema.mdx (German)

---
 .../pages/de/developing/creating-a-subgraph/ql-schema.mdx   | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/de/developing/creating-a-subgraph/ql-schema.mdx b/website/pages/de/developing/creating-a-subgraph/ql-schema.mdx
index 3df39853f82b..5b226f214d9d 100644
--- a/website/pages/de/developing/creating-a-subgraph/ql-schema.mdx
+++ b/website/pages/de/developing/creating-a-subgraph/ql-schema.mdx
@@ -72,7 +72,7 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 The following scalars are supported in the GraphQL API:
 
-| Type         | Description                                                                                                                                                                                                      |
+| Type         | Beschreibung                                                                                                                                                                                                     |
 | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
 | `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
@@ -143,7 +143,7 @@ Reverse lookups can be defined on an entity through the `@derivedFrom` field. Th
 
 For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived. Storing the relationship this way, rather than storing an array of entities on the 'many' side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.
 
-#### Example
+#### Beispiel
 
 We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
 
@@ -164,7 +164,7 @@ type TokenBalance @entity {
 
 For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.
 
-#### Example
+#### Beispiel
 
 Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
 

From bf151fbe082d7dc4d7214028134d3b239c7c4022 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:05:25 -0500
Subject: [PATCH 0382/3820] New translations advanced.mdx (Italian)

---
 .../creating-a-subgraph/advanced.mdx           | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/it/developing/creating-a-subgraph/advanced.mdx b/website/pages/it/developing/creating-a-subgraph/advanced.mdx
index 2638c71c7190..1fe74a2db24d 100644
--- a/website/pages/it/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/it/developing/creating-a-subgraph/advanced.mdx
@@ -542,14 +542,14 @@ When a subgraph whose manifest contains a `graft` block is deployed, Graph Node
 
 Poiché l'innesto copia piuttosto che indicizzare i dati di base, è molto più veloce portare il subgraph al blocco desiderato rispetto all'indicizzazione da zero, anche se la copia iniziale dei dati può richiedere diverse ore per subgraph molto grandi. Mentre il subgraph innestato viene inizializzato, il Graph Node registra le informazioni sui tipi di entità già copiati.
 
-Il grafted subgraph può utilizzare uno schema GraphQL non identico a quello del subgraph di base, ma semplicemente compatibile con esso. Deve essere uno schema di subgraph valido di per sé, ma può discostarsi dallo schema del subgraph di base nei seguenti modi:
-
-- Aggiunge o rimuove i tipi di entità
-- Rimuove gli attributi dai tipi di entità
-- Aggiunge attributi annullabili ai tipi di entità
-- Trasforma gli attributi non nulli in attributi nulli
-- Aggiunge valori agli enum
-- Aggiunge o rimuove le interfacce
-- Cambia per quali tipi di entità viene implementata un'interfaccia
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
 
 > **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 727459f264a0f25b94735949dba90dea79d42c8b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 13:05:33 -0500
Subject: [PATCH 0383/3820] New translations advanced.mdx (Japanese)

---
 website/pages/ja/developing/creating-a-subgraph/advanced.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/developing/creating-a-subgraph/advanced.mdx b/website/pages/ja/developing/creating-a-subgraph/advanced.mdx
index 6b8fd1fb7db4..da5c5badbaef 100644
--- a/website/pages/ja/developing/creating-a-subgraph/advanced.mdx
+++ b/website/pages/ja/developing/creating-a-subgraph/advanced.mdx
@@ -546,7 +546,7 @@ When a subgraph whose manifest contains a `graft` block is deployed, Graph Node
 
 - エンティティタイプを追加または削除する
 - エンティティタイプから属性を削除する
-- エンティティタイプに nullable 属性を追加する
+- 属性を追エンティティタイプに nullable加する
 - null 化できない属性を null 化できる属性に変更する
 - enums に値を追加する
 - インターフェースの追加または削除

From 21e19e245828da6574d9fcac80141e7866ee742d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:05 -0500
Subject: [PATCH 0384/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (French)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/fr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index df8f8b2b28ea..e93e561e36b4 100644
--- a/website/pages/fr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/fr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 849efb486b5893f2a6deb6e56f1d3629bce9eb0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:06 -0500
Subject: [PATCH 0385/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Russian)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/ru/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index d0e6eca00359..76c09b9f795a 100644
--- a/website/pages/ru/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/ru/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From f22bee7cf61884414c2b1de51f07105bb3a06ebb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:07 -0500
Subject: [PATCH 0386/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Romanian)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/ro/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index e37d83acbe78..5ae8b1b0a8dc 100644
--- a/website/pages/ro/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/ro/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From a9805784c02ccce5cb5a50964f55f48be5727996 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:08 -0500
Subject: [PATCH 0387/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Spanish)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/es/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index 2b5b9632ceb0..45849ac7dc65 100644
--- a/website/pages/es/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/es/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 13abbf0e33446c2d812d0ca1b54f302907068202 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:09 -0500
Subject: [PATCH 0388/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Arabic)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/ar/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index 23845a17520d..ef735cca4897 100644
--- a/website/pages/ar/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/ar/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From d9fd1bf7cef76505fe3e174ed4b2dc827fc769b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:11 -0500
Subject: [PATCH 0389/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Czech)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/cs/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index 12a504471cb7..722fb846bdd9 100644
--- a/website/pages/cs/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/cs/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Spusťte naši aplikaci Next.js pomocí `npm run dev`. Ověřte, že serverová
 
 ### Závěr
 
-Použitím serverových komponent Next.js jsme efektivně skryli klíč API před klientskou stranou, čímž jsme zvýšili bezpečnost naší aplikace. Tato metoda zajišťuje, že citlivé operace jsou zpracovávány na straně serveru, mimo potenciální zranitelnosti na straně klienta. Nakonec nezapomeňte prozkoumat [další opatření pro zabezpečení klíče API](/cookbook/upgrading-a-subgraph/#securing-your-api-key), abyste ještě více zvýšili zabezpečení svého klíče API.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 6f45a23c72f04da0571edeff89d185e2064b61cf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:12 -0500
Subject: [PATCH 0390/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (German)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/de/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index e37d83acbe78..5ae8b1b0a8dc 100644
--- a/website/pages/de/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/de/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 69ad8b3f1f1bc2ee3e6dde6d69f7562da3f12422 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:13 -0500
Subject: [PATCH 0391/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Italian)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/it/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index 5c3778edb064..f1a06150e9c3 100644
--- a/website/pages/it/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/it/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 9031dd7b1374015514af166cc63688f3ccc7059d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:14 -0500
Subject: [PATCH 0392/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Japanese)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/ja/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index ba4a9e799615..fa5923d9ee87 100644
--- a/website/pages/ja/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/ja/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 015fe6aa43660eb36acf87a19d8603ce1e4a6d92 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:15 -0500
Subject: [PATCH 0393/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Korean)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/ko/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index e37d83acbe78..5ae8b1b0a8dc 100644
--- a/website/pages/ko/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/ko/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 52185c6a5b2a46a6c95d6b9a063c0f9494cc7c7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:16 -0500
Subject: [PATCH 0394/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Dutch)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/nl/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index e37d83acbe78..5ae8b1b0a8dc 100644
--- a/website/pages/nl/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/nl/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 8f80fb197f6abab1097877857a0ec48e08805cb4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:17 -0500
Subject: [PATCH 0395/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Polish)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/pl/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index e37d83acbe78..5ae8b1b0a8dc 100644
--- a/website/pages/pl/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/pl/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 383371acab03faa4e0eca4015fdf31266a26a9b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:18 -0500
Subject: [PATCH 0396/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Portuguese)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/pt/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index 5bb8b017c0bc..b1d59d550707 100644
--- a/website/pages/pt/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/pt/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Inicie o nosso aplicativo Next.js com `npm run dev`. Verifique se o componente d
 
 ### Conclusão
 
-Ao utilizar os Componentes de Servidor Next.js, nós praticamente escondemos a chave API do client-side, o que aumenta a segurança do nosso aplicativo. Com este método, operações sensíveis podem ser executadas server-side, longe de vulnerabilidades em potencial no client-side. E finalmente, orientamos que explore [outras medidas de segurança de chave API](/cookbook/upgrading-a-subgraph/#securing-your-api-key) para aumentar ainda mais a sua segurança de chaves API.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From a356f9af8b3f031512015b8c2f618e2a542c7078 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:20 -0500
Subject: [PATCH 0397/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Swedish)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/sv/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index dfc61ce365d0..b0d913ed965f 100644
--- a/website/pages/sv/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/sv/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 28dc6fc96258167d557a25df1adb07f6cb1febc1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:21 -0500
Subject: [PATCH 0398/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Turkish)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/tr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index b3eff9269cea..b394a038b4b0 100644
--- a/website/pages/tr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/tr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 3a3f58f89771422f8d6f020b0abf38c2f3c474ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:22 -0500
Subject: [PATCH 0399/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Ukrainian)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/uk/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index e37d83acbe78..5ae8b1b0a8dc 100644
--- a/website/pages/uk/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/uk/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 09520afb36b29b00eb1241fb002a476899674cdd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:23 -0500
Subject: [PATCH 0400/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Chinese
 Simplified)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/zh/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index 00e49384691c..5690ae462084 100644
--- a/website/pages/zh/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/zh/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 7794d5584c5aba69811967ff317286731c352bcb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:24 -0500
Subject: [PATCH 0401/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Urdu (Pakistan))

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/ur/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index f5735d5627c3..7eeb3fa056fc 100644
--- a/website/pages/ur/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/ur/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 93e477e42692b79e7cb913e137f5c632d84a3866 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:25 -0500
Subject: [PATCH 0402/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Vietnamese)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/vi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index 7c0461051202..6360236cdfa9 100644
--- a/website/pages/vi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/vi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 96c7dd51e711458f01fe032f2c423624dd66b815 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:26 -0500
Subject: [PATCH 0403/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Marathi)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/mr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index d4e672df4fdb..6f351188ae73 100644
--- a/website/pages/mr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/mr/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From dc2c1a578f2bc9f3e18e0f40f50a83e94fe2b12e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:27 -0500
Subject: [PATCH 0404/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Hindi)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/hi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index e4f078918c5c..1e05772231a6 100644
--- a/website/pages/hi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/hi/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ export default function Home() {
 
 ### निष्कर्ष
 
-Next.js Server Components का उपयोग करके, हमने प्रभावी रूप से API कुंजी को क्लाइंट-साइड से छिपा दिया है, जिससे हमारे एप्लिकेशन की सुरक्षा में वृद्धि हुई है। यह विधि सुनिश्चित करती है कि संवेदनशील संचालन सर्वर-साइड पर, संभावित क्लाइंट-साइड कमजोरियों से दूर, संभाले जाते हैं। अंत में, अपने API कुंजी की सुरक्षा बढ़ाने के लिए other API key security measures (/cookbook/upgrading-a-subgraph/#securing-your-api-key) का अन्वेषण करना न भूलें।
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From 6720abb678a046eb030c24d6066691b2c6688211 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 16 Dec 2024 18:27:29 -0500
Subject: [PATCH 0405/3820] New translations
 how-to-secure-api-keys-using-nextjs-server-components.mdx (Swahili)

---
 .../how-to-secure-api-keys-using-nextjs-server-components.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx b/website/pages/sw/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
index e37d83acbe78..5ae8b1b0a8dc 100644
--- a/website/pages/sw/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
+++ b/website/pages/sw/cookbook/how-to-secure-api-keys-using-nextjs-server-components.mdx
@@ -120,4 +120,4 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ### Conclusion
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/cookbook/upgrading-a-subgraph/#securing-your-api-key) to increase your API key security even further.
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/querying/managing-api-keys/) to increase your API key security even further.

From c7f715509235e5160ad27598bab03d7f6a921003 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:01 -0500
Subject: [PATCH 0406/3820] New translations tap.mdx (Hindi)

---
 website/pages/hi/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/tap.mdx b/website/pages/hi/tap.mdx
index 85f9f8b123ac..e646579eb80f 100644
--- a/website/pages/hi/tap.mdx
+++ b/website/pages/hi/tap.mdx
@@ -9,7 +9,7 @@ The Graph के नए भुगतान प्रणाली, Timeline Aggre
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) मौजूदा Scalar भुगतान प्रणाली का एक ड्रॉप-इन प्रतिस्थापन है। यह निम्नलिखित प्रमुख सुविधाएँ प्रदान करता है:
 
 - सूक्ष्म भुगतानों को कुशलता से संभालता है।
-- ऑन-चेन लेनदेन और लागतों में समेकनों की एक परत जोड़ता है।
+- Adds a layer of consolidations to onchain transactions and costs.
 - प्राप्तियों और भुगतान पर Indexers को नियंत्रण की अनुमति देता है, प्रश्नों के लिए भुगतान की गारंटी देता है।
 - यह विकेन्द्रीकृत, विश्वास रहित गेटवे को सक्षम बनाता है और कई भेजने वालों के लिए indexer-service के प्रदर्शन में सुधार करता है।
 

From e6c3e4d73245ca07fdfe31c428bf201d287e942f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:02 -0500
Subject: [PATCH 0407/3820] New translations api.mdx (Russian)

---
 website/pages/ru/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ru/developing/graph-ts/api.mdx b/website/pages/ru/developing/graph-ts/api.mdx
index b5a90b9930fb..075be4e59b21 100644
--- a/website/pages/ru/developing/graph-ts/api.mdx
+++ b/website/pages/ru/developing/graph-ts/api.mdx
@@ -281,7 +281,7 @@ if (transfer == null) {
 
 Начиная с `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 и `@graphprotocol/graph-cli` v0.49.0 метод `loadInBlock` доступен для всех типов объектов.
 
-API хранилища облегчает извлечение объектов, которые были созданы или обновлены в текущем блоке. Типичная ситуация: один обработчик создает транзакцию из какого-то события в он-чейне, а следующий обработчик хочет получить доступ к этой транзакции, если она существует.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - В случае, если транзакция не существует, субграф должен будет обратиться к базе данных просто для того, чтобы узнать, что объект не существует. Если автор субграфа уже знает, что объект должен быть создан в том же блоке, использование `loadInBlock` позволяет избежать этого обращения к базе данных.
 - Для некоторых субграфов эти пропущенные поиски могут существенно увеличить время индексации.
@@ -674,7 +674,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Смарт-контракты иногда привязывают файлы IPFS к чейну. Это позволяет мэппингам получать хэши IPFS из контракта и считывать соответствующие файлы из IPFS. Данные файла будут возвращены в виде `Bytes`, что обычно требует дальнейшей обработки, например, с помощью `json` API, описанного далее на этой странице.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 При наличии хеша или пути IPFS чтение файла из IPFS выполняется следующим образом:
 

From e3103125b4080a4f6a25985cc6260bf0dd277bd9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:04 -0500
Subject: [PATCH 0408/3820] New translations deploy-using-subgraph-studio.mdx
 (Turkish)

---
 website/pages/tr/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/deploying/deploy-using-subgraph-studio.mdx b/website/pages/tr/deploying/deploy-using-subgraph-studio.mdx
index 91fb05f09292..3ccb3e02c262 100644
--- a/website/pages/tr/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/tr/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Subgraph Studio Kullanarak Dağıtma
 
 Subgraph'inizi Subgraph Studio'da dağıtma adımlarını öğrenin.
 
-> Not: Bir subgraph'i yayına aldığınızda, onu Subgraph Studio’ya iletmiş olursunuz ve orada test edebilirsiniz. Dağıtmanın yayımlamakla aynı şey olmadığını hatırlamak önemlidir. Bir subgraph'i yayımladığınızda, onu zincir üzerinde yayımlamış olursunuz.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio'ya Genel Bakış
 
@@ -124,7 +124,7 @@ Subgraph’inizi güncellemek isterseniz, aşağıdaki adımları izleyebilirsin
 - Memnun kaldığınızda, yeni dağıtımınızı [Graph Gezgini](https://thegraph.com/explorer)'nde yayımlayabilirsiniz.
 - Bu işlem, küratörlerin sinyal vermeye başlayabileceği ve Endeksleyicilerin endeksleyebileceği, subgraph'inizin yeni bir sürümünü oluşturur.
 
-Ayrıca, subgraph'inizin meta verilerini yeni bir sürüm yayımlamak zorunda kalmadan güncelleyebilirsiniz. Studio’daki (profil resmi, isim, açıklama gibi) subgraph ayrıntılarını [Graph Gezgini](https://thegraph.com/explorer)'ndeki **Ayrıntıları Güncelle** seçeneğini işaretleyerek güncelleyebilirsiniz. Bu seçenek işaretlendiğinde, yeni bir sürüm yayımlamaya gerek kalmadan, Explorer'da subgraph ayrıntılarını güncelleyen bir blokzincir işlemi oluşturulur.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Bir subgraph’in yeni bir sürümünü ağda yayımlamanın maliyetleri olduğunu unutmayın. İşlem ücretlerine ek olarak, otomatik olarak taşınan sinyalin kürasyon vergisinin bir kısmını da finanse etmeniz gerekmektedir. Küratörler subgraph'inize sinyal vermemişse subgraph'inizin yeni bir sürümünü yayımlayamazsınız. Daha fazla bilgi için [buraya](/network/curating/) göz atın.
 

From dc815ee4f5b3247378ccae497205acbad4d8cb2c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:05 -0500
Subject: [PATCH 0409/3820] New translations transfer-to-the-graph.mdx (Hindi)

---
 website/pages/hi/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/cookbook/transfer-to-the-graph.mdx b/website/pages/hi/cookbook/transfer-to-the-graph.mdx
index eefabc7d2cd1..fb4c001480cb 100644
--- a/website/pages/hi/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/hi/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - [Subgraph Studio](https://thegraph.com/studio/) पर जाएँ और अपने वॉलेट को कनेक्ट करें।
 - "एक सबग्राफ बनाएं" पर क्लिक करें। सबग्राफ का नाम टाइटल केस में रखनाrecommended है: "सबग्राफ नाम चेन नाम"।
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 7ceea6382b3301e2f07c3afc1a90b355c15a85d2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:06 -0500
Subject: [PATCH 0410/3820] New translations indexing.mdx (Hindi)

---
 website/pages/hi/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/hi/network/indexing.mdx b/website/pages/hi/network/indexing.mdx
index 62544f991701..c2c0dc68bac3 100644
--- a/website/pages/hi/network/indexing.mdx
+++ b/website/pages/hi/network/indexing.mdx
@@ -137,7 +137,7 @@ Once an allocation has been closed the rebates are available to be claimed by th
 
 - **इंडेक्सर सेवा** - नेटवर्क के साथ सभी आवश्यक बाहरी संचार को संभालती है। शेयर लागत मॉडल और अनुक्रमण स्थिति, गेटवे से ग्राफ़ नोड पर क्वेरी अनुरोधों को पास करता है, और गेटवे के साथ राज्य चैनलों के माध्यम से क्वेरी भुगतान का प्रबंधन करता है।
 
-- **इंडेक्सर एजेंट** - नेटवर्क पर पंजीकरण, इसके ग्राफ नोड/एस पर सबग्राफ परिनियोजन प्रबंधित करने और आवंटन प्रबंधित करने सहित श्रृंखला पर इंडेक्सर्स इंटरैक्शन की सुविधा प्रदान करता है।
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **प्रोमेथियस मेट्रिक्स सर्वर** - ग्राफ नोड और इंडेक्सर घटक अपने मेट्रिक्स को मेट्रिक्स सर्वर पर लॉग करते हैं।
 
@@ -367,7 +367,7 @@ docker-compose up
 
 नेटवर्क में सफलतापूर्वक भाग लेने के लिए लगभग निरंतर निगरानी और सहभागिता की आवश्यकता होती है, इसलिए हमने इंडेक्सर्स नेटवर्क भागीदारी को सुविधाजनक बनाने के लिए टाइपस्क्रिप्ट एप्लिकेशन का एक सूट बनाया है। तीन इंडेक्सर घटक हैं:
 
-- **इंडेक्सर एजेंट** - एजेंट नेटवर्क और इंडेक्सर के अपने इंफ्रास्ट्रक्चर की निगरानी करता है और प्रबंधित करता है कि कौन से सबग्राफ परिनियोजन अनुक्रमित हैं और चेन पर आवंटित किए गए हैं और प्रत्येक के लिए कितना आवंटित किया गया है।
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **इंडेक्सर सेवा** - एकमात्र घटक जिसे बाहरी रूप से प्रदर्शित करने की आवश्यकता होती है, सेवा ग्राफ नोड को सबग्राफ क्वेरी भेजती है, क्वेरी भुगतान के लिए राज्य चैनल प्रबंधित करती है, महत्वपूर्ण निर्णय लेने की जानकारी साझा करती है गेटवे जैसे ग्राहकों के लिए।
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 इंडेक्सर-क्ली एक्शन क्यू के साथ मैन्युअल रूप से काम करने के लिए `कार्रवाई` मॉड्यूल प्रदान करता है। यह क्रिया क्यू के साथ इंटरैक्ट करने के लिए अनुक्रमणिका प्रबंधन सर्वर द्वारा होस्ट किए गए **Graphql API** का उपयोग करता है।
 
-क्रिया निष्पादन कार्यकर्ता कतार से केवल आइटमों को निष्पादित करने के लिए पकड़ेगा यदि उनके पास `ActionStatus = स्वीकृत` है। अनुशंसित पथ में कार्रवाई कतार में ActionStatus = कतारबद्ध के साथ जोड़ी जाती है, इसलिए उन्हें ऑन-चेन निष्पादित करने के लिए अनुमोदित किया जाना चाहिए। सामान्य प्रवाह इस तरह दिखेगा:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - तृतीय पक्ष ऑप्टिमाइज़र टूल या इंडेक्सर-क्ली उपयोगकर्ता द्वारा कतार में जोड़ी गई कार्रवाई
 - सभी कतारबद्ध क्रियाओं को देखने के लिए इंडेक्सर `indexer-cli` का उपयोग कर सकता है
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-इंडेक्सर्स को ऑन-चेन आवंटन बनाने से पहले चेनहेड में सबग्राफ परिनियोजन को सिंक करने के लिए ऑफ-चेन सिंकिंग कार्यक्षमता का उपयोग करने की सिफारिश की जाती है। यह सुविधा सबग्राफ के लिए विशेष रूप से उपयोगी है जो सिंक करने के लिए 28 से अधिक समय ले सकती है या अनिश्चित रूप से विफल होने की कुछ संभावनाएं हैं।
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From c8c6880c0bd484d947685f58c37aa0ba44425e66 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:07 -0500
Subject: [PATCH 0411/3820] New translations curating.mdx (French)

---
 website/pages/fr/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/network/curating.mdx b/website/pages/fr/network/curating.mdx
index da503e1d6dea..5c2913bf7dd8 100644
--- a/website/pages/fr/network/curating.mdx
+++ b/website/pages/fr/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. Quel est le coût de la mise à jour d'un subgraph ?
 
-La migration de vos parts de curation vers une nouvelle version de subgraph entraîne une taxe de curation de 1%. Les Curateurs peuvent choisir de s'abonner à la version la plus récente d'un subgraph. Lorsque les parts de Curateur sont auto-migrées vers une nouvelle version, les Curateurs paieront également une demi-taxe de curation, soit 0,5%, car la mise à jour des subgraphs est une action on-chain qui coûte des frais de gaz.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. À quelle fréquence puis-je mettre à jour mon subgraph ?
 

From f8641f207e3b01f3e8cb0b4897e929e2f6417095 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:09 -0500
Subject: [PATCH 0412/3820] New translations indexing.mdx (French)

---
 website/pages/fr/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/fr/network/indexing.mdx b/website/pages/fr/network/indexing.mdx
index 55955d4a56b9..bc7f35e6e95d 100644
--- a/website/pages/fr/network/indexing.mdx
+++ b/website/pages/fr/network/indexing.mdx
@@ -137,7 +137,7 @@ Au centre de l'infrastructure d'un indexeur se trouve le nœud Graph qui surveil
 
 - **Service d'indexation** : gère toutes les communications externes requises avec le réseau. Partage les modèles de coûts et les statuts d'indexation, transmet les demandes de requête des passerelles à un nœud graphlm et gère les paiements des requêtes via les canaux d'état avec la passerelle.
 
-- **Agent indexeur** - Facilite les interactions des indexeurs sur la chaîne, y compris l'enregistrement sur le réseau, la gestion des déploiements de subgraphs sur son(ses) nœud(s) graph(s) et la gestion des allocations.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Serveur de métriques Prometheus** : les composants Graph Node et Indexer enregistrent leurs métriques sur le serveur de métriques.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 Pour participer avec succès au réseau, il faut une surveillance et une interaction presque constantes. Nous avons donc créé une suite d'applications Typescript pour faciliter la participation au réseau des indexeurs. Il existe trois composants d'indexeur :
 
-- **Agent indexeur** - L'agent surveille le réseau et la propre infrastructure de l'indexeur et gère les déploiements de subgraphs qui sont indexés et alloués sur la chaîne et la quantité allouée à chacun.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Service d'indexation** : seul composant qui doit être exposé en externe, le service transmet les requêtes de subgraph au nœud de graph, gère les canaux d'état pour les paiements des requêtes, partage des informations importantes pour la prise de décision. aux clients comme les passerelles.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 L'indexer-cli fournit un module `actions` pour travailler manuellement avec le fichier d'attente d'actions. Il utilise l'**API Graphql** hébergée par le serveur de gestion de l'indexeur pour interagir avec le fichier d'attente des actions.
 
-Le travailleur d'exécution d'action ne récupérera les éléments de la file d'attente à exécuter que s'ils ont `ActionStatus = approved`. Dans le chemin recommandé, les actions sont ajoutées à la file d'attente avec ActionStatus = queued, elles doivent donc ensuite être approuvées afin d'être exécutées en chaîne. Le flux général ressemblera à :
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Action ajoutée à la file d'attente par l'outil d'optimisation tiers ou l'utilisateur indexeur-cli
 - L'indexeur peut utiliser `indexer-cli` pour afficher toutes les actions en file d'attente
@@ -813,8 +813,8 @@ Pour définir les paramètres de délégation à l'aide de l'interface Graph Exp
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Une fois qu'une allocation est créée on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) elle est considérée comme **active**. Une partie du staking de l'Indexeur et/ou du staking délégué est allouée à un déploiement de subgraph, ce qui leur permet de réclamer des récompenses d'indexation et de servir des requêtes pour ce déploiement de subgraph. L'agent Indexeur gère la création des allocations en fonction des règles de l'Indexeur.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - Un Indexeur est libre de fermer une allocation une fois qu'une époque est passée ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) ou son agent Indexeur fermera automatiquement l'allocation après le **maxAllocationEpochs** (actuellement 28 jours). Lorsqu'une allocation est fermée avec une preuve d'indexation (POI) valide, leurs récompenses d'indexation sont distribuées à l'Indexeur et à ses Délégateurs ([en savoir plus](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Il est recommandé aux indexeurs d'utiliser la fonctionnalité de synchronisation hors chaîne pour synchroniser les déploiements de subgraphs avec Chainhead avant de créer l'allocation en chaîne. Cette fonctionnalité est particulièrement utile pour les sous-graphes dont la synchronisation peut prendre plus de 28 époques ou qui risquent d'échouer de manière indéterministe.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 8037e5771334e135bd08e3eafc2470834078f024 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:10 -0500
Subject: [PATCH 0413/3820] New translations indexing.mdx (Turkish)

---
 website/pages/tr/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/tr/network/indexing.mdx b/website/pages/tr/network/indexing.mdx
index a9c25ebeee43..d94516d448a3 100644
--- a/website/pages/tr/network/indexing.mdx
+++ b/website/pages/tr/network/indexing.mdx
@@ -137,7 +137,7 @@ Bir İndeksleyicinin altyapısının merkezinde, indekslenen ağları izleyen, b
 
 - **İndeksleyici hizmeti** - Ağ ile gerekli tüm harici iletişimleri gerçekleştirir. Maliyet modellerini ve indeksleme durumlarını paylaşır, ağ geçitlerinden gelen sorgu isteklerini bir Graph Düğümü'ne iletir ve ağ geçidi ile durum kanalları aracılığıyla sorgu ödemelerini yönetir.
 
-- **İndeksleyici aracı** - Ağa kaydolma, Graph Düğümlerine subgraph dağıtımlarını ve tahsisleri yönetme dahil olmak üzere İndeksleyicilerin zincir üzerindeki etkileşimlerini kolaylaştırır.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrik sunucusu** - Graph Düğümü ve İndeksleyici bileşenleri metriklerini metrik sunucusuna kaydeder.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 Ağa başarılı bir şekilde katılmak hemen hemen sürekli izleme ve etkileşim gerektirir, bu nedenle İndeksleyicilerin ağa katılımını kolaylaştırmak için bir dizi Typescript uygulaması oluşturduk. Üç İndeksleyici bileşeni bulunmaktadır:
 
-- **İndeksleyici aracısı** - Aracı, ağı ve İndeksleyicinin kendi altyapısını izler ve hangi subgraph dağıtımlarının indekslendiğini, zincir üzerinde tahsis edildiğini ve her birine ne miktarda tahsis edildiğini yönetir.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **İndeksleyici hizmeti** - Harici olarak gösterilmesi gereken tek bileşen olan hizmet, subgraph sorgularını graph düğümüne iletir, sorgu ödemeleri için durum kanallarını yönetir ve istemcilerle ağ geçitleri gibi önemli karar verme bilgilerini paylaşır.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 Indexer-cli, eylem kuyruğu ile manuel olarak çalışmak için bir `actions` modülü sağlar. Eylem kuyruğu ile etkileşim kurmak için indeksleyici yönetim sunucusu tarafından barındırılan **Graphql API**'sini kullanır.
 
-Eylem yürütme çalışanı, yalnızca `ActionStatus = approved` değerine sahipse yürütmek için kuyruktan öğeleri alır. Önerilen yolda eylemler ActionStatus = queued ile kuyruğa eklenir, bu nedenle zincir üzerinde yürütülmeleri için onaylanmaları gerekir. Genel işleyiş şu şekilde olacaktır:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Kuyruğa üçüncü şahıs optimizasyon aracı veya indexer-cli kullanıcısı tarafından eklenen eylem
 - İndeksleyici, sıraya alınan tüm eylemleri görüntülemek için `indexer-cli`'yi kullanabilir
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-İndeksleyicilerin, zincir üstünde tahsis oluşturmadan önce subgraph dağıtımlarını chainhead ile senkronize etmek için zincir dışı senkronizasyon fonksiyonunu kullanmaları önerilir. Bu özellik bilhassa senkronize edilmesi 28 dönemden daha uzun sürebilecek veya belirsiz bir şekilde başarısız olma ihtimali olan subgraphlar için kullanışlıdır.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From ac1b71f4d40e18f75ceafad77b2705c1b2fa54b5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:11 -0500
Subject: [PATCH 0414/3820] New translations api.mdx (Hindi)

---
 website/pages/hi/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/developing/graph-ts/api.mdx b/website/pages/hi/developing/graph-ts/api.mdx
index 39bffd6bac80..4b341cb7b60b 100644
--- a/website/pages/hi/developing/graph-ts/api.mdx
+++ b/website/pages/hi/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ if (transfer == null) {
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-स्टोर एपीआई वर्तमान ब्लॉक में बनाए गए या अपडेट किए गए Entities को पुनः प्राप्त करने की सुविधा प्रदान करता है। इस स्थिति में एक हैंडलर किसी ऑन-चेन घटना से एक लेन-देन बनाता है, और एक बाद वाला हैंडलर चाहता है कि यदि यह लेन-देन मौजूद है, तो वह इसे एक्सेस कर सके।
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - यदि लेन-देन मौजूद नहीं है, तो subgraph को केवल यह पता लगाने के लिए डेटाबेस में जाना होगा कि Entity मौजूद नहीं है। यदि subgraph लेखक पहले से जानता है कि Entity उसी ब्लॉक में बनाई जानी चाहिए थी, तो `loadInBlock` का उपयोग इस डेटाबेस राउंडट्रिप से बचाता है।
 - कुछ subgraphs के लिए, ये छूटे हुए लुकअप्स indexing समय में महत्वपूर्ण योगदान दे सकते हैं।
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 IPFS हैश या पथ को देखते हुए, IPFS से फ़ाइल पढ़ना निम्नानुसार किया जाता है:
 

From c45821697eddef9f812a79404b20634a04a11928 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:12 -0500
Subject: [PATCH 0415/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Russian)

---
 .../pages/ru/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ru/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/ru/developing/substreams-powered-subgraphs-faq.mdx
index 4d6d97dd686f..f11032755e72 100644
--- a/website/pages/ru/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/ru/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ Go to the [Substreams Documentation](/substreams) to learn more about Substreams
 
 ## Чем субграфы, работающие на основе Субпотоков, отличаются от субграфов?
 
-Субграфы состоят из источников данных, которые определяют события в цепочке и то, как эти события должны быть преобразованы с помощью обработчиков, написанных на Assemblyscript. Эти события обрабатываются последовательно в зависимости от того, в каком порядке события происходят в цепочке.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-Напротив, субграфы, работающие на основе субпотоков, имеют один источник данных, который ссылается на пакет субпотоков, обрабатываемый the Graph Node. Субпотоки имеют доступ к дополнительным детализированным данным в цепочке по сравнению с обычными субграфами, а также могут извлекать выгоду из массового распараллеливания обработки, что может подразумевать гораздо более быстрое время обработки.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## Каковы преимущества использования субграфов, работающих на основе Субпотоков?
 

From 95397cc1d1db8400481d7b5d54e84cb7a3e4ebe2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:14 -0500
Subject: [PATCH 0416/3820] New translations curating.mdx (Turkish)

---
 website/pages/tr/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/network/curating.mdx b/website/pages/tr/network/curating.mdx
index 17c05c0de615..6831282af1e9 100644
--- a/website/pages/tr/network/curating.mdx
+++ b/website/pages/tr/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. Bir subgraph'ı güncellemenin maliyeti nedir?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. Subgraph'ımı ne sıklıkla güncelleyebilirim?
 

From 247007f818c1d5f3288a89e1d66ddbd941d0dad3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:15 -0500
Subject: [PATCH 0417/3820] New translations subgraphs.mdx (French)

---
 website/pages/fr/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs.mdx b/website/pages/fr/subgraphs.mdx
index 2d86a8dea5b8..132d5136f734 100644
--- a/website/pages/fr/subgraphs.mdx
+++ b/website/pages/fr/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 5e204047e586e0a612936a6285ca8e7db5d54e55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:16 -0500
Subject: [PATCH 0418/3820] New translations subgraphs.mdx (Turkish)

---
 website/pages/tr/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs.mdx b/website/pages/tr/subgraphs.mdx
index 4feb5d9d52c3..04b28676bebd 100644
--- a/website/pages/tr/subgraphs.mdx
+++ b/website/pages/tr/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 71e57334f6f334b232ac7f385bf946132dd2f389 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:17 -0500
Subject: [PATCH 0419/3820] New translations subgraphs.mdx (Russian)

---
 website/pages/ru/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs.mdx b/website/pages/ru/subgraphs.mdx
index a53e52db48ec..bbbae84e7ee2 100644
--- a/website/pages/ru/subgraphs.mdx
+++ b/website/pages/ru/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 7e232c89af8695bb214f3c128e79c2fb67984def Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:18 -0500
Subject: [PATCH 0420/3820] New translations near.mdx (Romanian)

---
 website/pages/ro/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/cookbook/near.mdx b/website/pages/ro/cookbook/near.mdx
index f2509e44e84c..d382e179b948 100644
--- a/website/pages/ro/cookbook/near.mdx
+++ b/website/pages/ro/cookbook/near.mdx
@@ -12,7 +12,7 @@ This guide is an introduction to building subgraphs indexing smart contracts on
 
 The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
 
-Subgraphs are event-based, which means that they listen for and then process on-chain events. There are currently two types of handlers supported for NEAR subgraphs:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Block handlers: these are run on every new block
 - Receipt handlers: run every time a message is executed at a specified account

From d36e677c0df081fa85396b61b562984c8c5a53f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:19 -0500
Subject: [PATCH 0421/3820] New translations api.mdx (Romanian)

---
 website/pages/ro/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ro/developing/graph-ts/api.mdx b/website/pages/ro/developing/graph-ts/api.mdx
index 8fc1f4b48b61..34aca9ef10ee 100644
--- a/website/pages/ro/developing/graph-ts/api.mdx
+++ b/website/pages/ro/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Given an IPFS hash or path, reading a file from IPFS is done as follows:
 

From 5e7f500f969bf8f242cfd58ac5b4595681f1fb2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:20 -0500
Subject: [PATCH 0422/3820] New translations subgraphs.mdx (Romanian)

---
 website/pages/ro/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/subgraphs.mdx b/website/pages/ro/subgraphs.mdx
index 42c1e806f822..1fdd0baf80eb 100644
--- a/website/pages/ro/subgraphs.mdx
+++ b/website/pages/ro/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 23afee9f86133a98a67276f47973bd39e9ad693d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:21 -0500
Subject: [PATCH 0423/3820] New translations transfer-to-the-graph.mdx
 (Romanian)

---
 website/pages/ro/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/cookbook/transfer-to-the-graph.mdx b/website/pages/ro/cookbook/transfer-to-the-graph.mdx
index 6a5d2c2793f3..e3acb966c427 100644
--- a/website/pages/ro/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/ro/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 30f07c373ff53c7d7ed94ffcc0519fd320eee61c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:22 -0500
Subject: [PATCH 0424/3820] New translations subgraph-manifest.mdx (Romanian)

---
 .../ro/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/ro/developing/creating-a-subgraph/subgraph-manifest.mdx
index f282f3946e75..4af0a0adbf2d 100644
--- a/website/pages/ro/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/ro/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Data Source for the Main Contract
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 7b1054221d7af6699631316d5edad6af5e1e27ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:23 -0500
Subject: [PATCH 0425/3820] New translations near.mdx (French)

---
 website/pages/fr/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/cookbook/near.mdx b/website/pages/fr/cookbook/near.mdx
index e922801be61e..d301eef88b9a 100644
--- a/website/pages/fr/cookbook/near.mdx
+++ b/website/pages/fr/cookbook/near.mdx
@@ -12,7 +12,7 @@ Ce guide est une introduction à la construction de subgraphs indexant des contr
 
 Le Graph donne aux développeurs des outils pour traiter les événements de la blockchain et rendre les données résultantes facilement disponibles via une API GraphQL, connue individuellement comme un subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) est désormais capable de traiter les événements NEAR, ce qui signifie que les développeurs NEAR peuvent désormais construire des subgraphs pour indexer leurs smart contracts.
 
-Les subgraphs sont basés sur des événements, ce qui signifie qu'ils écoutent et traitent les événements de la chaîne. Il existe actuellement deux types de gestionnaires pour les subgraphs NEAR :
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Gestionnaires de blocs : ceux-ci sont exécutés à chaque nouveau bloc
 - Gestionnaires de reçus : exécutés à chaque fois qu'un message est exécuté sur un compte spécifié

From f3a52a9aa67696036fca9bda50392d6138265e2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:25 -0500
Subject: [PATCH 0426/3820] New translations api.mdx (French)

---
 website/pages/fr/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/developing/graph-ts/api.mdx b/website/pages/fr/developing/graph-ts/api.mdx
index 1fecf7dd1dd4..018691da0d9b 100644
--- a/website/pages/fr/developing/graph-ts/api.mdx
+++ b/website/pages/fr/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ Comme l'entité peut ne pas encore exister dans le magasin, la méthode `load` r
 
 Depuis `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 et `@graphprotocol/graph-cli` v0.49.0 la méthode `loadInBlock` est disponible pour tous les types d'entités.
 
-L'API store facilite la récupération des entités qui ont été créées ou mises à jour dans le bloc actuel. Une situation typique est qu'un gestionnaire crée une transaction à partir d'un événement on-chain, et qu'un gestionnaire ultérieur souhaite accéder à cette transaction si elle existe.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - Dans le cas où la transaction n'existe pas, le subgraph devra interroger la base de données pour découvrir que l'entité n'existe pas. Si l'auteur du subgraph sait déjà que l'entité doit avoir été créée dans le même bloc, utiliser `loadInBlock` évite ce détour par la base de données.
 - Pour certains subgraphs, ces recherches infructueuses peuvent contribuer de manière significative au temps d'indexation.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Les contrats intelligents ancrent occasionnellement des fichiers IPFS sur la blockchain. Cela permet aux mappages d'obtenir les hashs IPFS du contrat et de lire les fichiers correspondants à partir d'IPFS. Les données du fichier seront retournées sous forme de `Bytes`, ce qui nécessite généralement un traitement supplémentaire, par exemple avec l'API `json` documentée plus loin sur cette page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Étant donné un hachage ou un chemin IPFS, la lecture d'un fichier depuis IPFS se fait comme suit :
 

From 5c49df965e9ecb374ea6f5c6bc67fe4db7baf737 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:26 -0500
Subject: [PATCH 0427/3820] New translations transfer-to-the-graph.mdx (French)

---
 website/pages/fr/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/cookbook/transfer-to-the-graph.mdx b/website/pages/fr/cookbook/transfer-to-the-graph.mdx
index 7b92f88f7ad3..858c8e7bd81f 100644
--- a/website/pages/fr/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/fr/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 75ad57b081d64bd9cbf3b24e394477cd55eef729 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:27 -0500
Subject: [PATCH 0428/3820] New translations subgraph-manifest.mdx (French)

---
 .../fr/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/fr/developing/creating-a-subgraph/subgraph-manifest.mdx
index a7c76c52d491..d0594330e1f0 100644
--- a/website/pages/fr/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/fr/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Source de données pour le contrat principal
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 83b2d1873e76bcb8281545fcc2041d9e4dfcf278 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:28 -0500
Subject: [PATCH 0429/3820] New translations near.mdx (Spanish)

---
 website/pages/es/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/cookbook/near.mdx b/website/pages/es/cookbook/near.mdx
index f915ec580057..f77bee50ea2e 100644
--- a/website/pages/es/cookbook/near.mdx
+++ b/website/pages/es/cookbook/near.mdx
@@ -12,7 +12,7 @@ Esta guía es una introducción a la construcción de subgrafos que indexan cont
 
 The Graph brinda a los desarrolladores herramientas para procesar eventos de blockchain y hacer que los datos resultantes estén fácilmente disponibles a través de una API GraphQL, conocido individualmente como subgrafo. [Graph Node](https://github.com/graphprotocol/graph-node) ahora puede procesar eventos NEAR, lo que significa que los desarrolladores de NEAR ahora pueden crear subgrafos para indexar sus contratos inteligentes.
 
-Los subgrafos se basan en eventos, lo que significa que escuchan y procesan los eventos on-chain. Actualmente hay dos tipos de handlers compatibles con los subgrafos NEAR:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Handlers de bloques: se ejecutan en cada nuevo bloque
 - Handlers de recibos: se realizan cada vez que se ejecuta un mensaje en una cuenta específica

From e3e76e6287642f4885feb82dbf919072c1d1c5e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:30 -0500
Subject: [PATCH 0430/3820] New translations api.mdx (Spanish)

---
 website/pages/es/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/es/developing/graph-ts/api.mdx b/website/pages/es/developing/graph-ts/api.mdx
index 6660507ae768..ae97c662e59b 100644
--- a/website/pages/es/developing/graph-ts/api.mdx
+++ b/website/pages/es/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Dado un hash o ruta de IPFS, la lectura de un archivo desde IPFS se realiza de la siguiente manera:
 

From 0b09f25c8d50b1bf07ad80d62e8ad3596da4744f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:31 -0500
Subject: [PATCH 0431/3820] New translations subgraphs.mdx (Spanish)

---
 website/pages/es/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/subgraphs.mdx b/website/pages/es/subgraphs.mdx
index f41177ea6fbf..365ab19aee4d 100644
--- a/website/pages/es/subgraphs.mdx
+++ b/website/pages/es/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 24446d8304e73b83ef0eae8a46939900e72ca9a8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:32 -0500
Subject: [PATCH 0432/3820] New translations transfer-to-the-graph.mdx
 (Spanish)

---
 website/pages/es/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/cookbook/transfer-to-the-graph.mdx b/website/pages/es/cookbook/transfer-to-the-graph.mdx
index d86f6f31fc62..67a9cdd5e90d 100644
--- a/website/pages/es/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/es/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 07d1ece75a7a6d3c06b91ab98380ad2fe6f631e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:33 -0500
Subject: [PATCH 0433/3820] New translations subgraph-manifest.mdx (Spanish)

---
 .../es/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/es/developing/creating-a-subgraph/subgraph-manifest.mdx
index d8d4f07fd43a..5eb00c42f961 100644
--- a/website/pages/es/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/es/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Fuente de Datos para el Contrato Principal
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From af45b360570e5371965affbf4bb6b90c99d50d8d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:34 -0500
Subject: [PATCH 0434/3820] New translations near.mdx (Arabic)

---
 website/pages/ar/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/cookbook/near.mdx b/website/pages/ar/cookbook/near.mdx
index 73428b6f6fd5..8e4e6942264d 100644
--- a/website/pages/ar/cookbook/near.mdx
+++ b/website/pages/ar/cookbook/near.mdx
@@ -12,7 +12,7 @@ title: بناء Subgraphs على NEAR
 
 يوفر The Graph للمطورين أدوات لمعالجة أحداث blockchain وجعل البيانات الناتجة متاحة بسهولة عبر GraphQL API ، والمعروفة باسم subgraph. أصبح [ Graph Node ](https://github.com/graphprotocol/graph-node) الآن قادرًا على معالجة أحداث NEAR ، مما يعني أن مطوري NEAR يمكنهم الآن إنشاء subgraphs لفهرسة عقودهم الذكية (smart contracts).
 
-تعتمد الـ Subgraphs على الأحداث ، مما يعني أنها تستمع إلى أحداث on-chain ثم تعالجها. يوجد حاليًا نوعان من المعالجات المدعومة لـ NEAR subgraphs:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - معالجات الكتل(Block handlers): يتم تشغيلها على كل كتلة جديدة
 - معالجات الاستلام (Receipt handlers): يتم تشغيلها في كل مرة يتم فيها تنفيذ رسالة على حساب محدد

From 2e4b33d721f1a89ca1044ac37630d4b6444ab0c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:35 -0500
Subject: [PATCH 0435/3820] New translations api.mdx (Arabic)

---
 website/pages/ar/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ar/developing/graph-ts/api.mdx b/website/pages/ar/developing/graph-ts/api.mdx
index 544f2118f489..a46cbb30bf3a 100644
--- a/website/pages/ar/developing/graph-ts/api.mdx
+++ b/website/pages/ar/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 'import { ipfs } from '@graphprotocol/graph-ts
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Given an IPFS hash or path, reading a file from IPFS is done as follows:
 

From 381a93e78ae31b7babf2c66579d5594d9f2fd585 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:36 -0500
Subject: [PATCH 0436/3820] New translations subgraphs.mdx (Arabic)

---
 website/pages/ar/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/subgraphs.mdx b/website/pages/ar/subgraphs.mdx
index d770a7cb9c57..e1eabb2cd72e 100644
--- a/website/pages/ar/subgraphs.mdx
+++ b/website/pages/ar/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 828a82013746a284aee027ce786f885bcab265df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:37 -0500
Subject: [PATCH 0437/3820] New translations transfer-to-the-graph.mdx (Arabic)

---
 website/pages/ar/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/cookbook/transfer-to-the-graph.mdx b/website/pages/ar/cookbook/transfer-to-the-graph.mdx
index cb6a721e416c..eff1a743e251 100644
--- a/website/pages/ar/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/ar/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 6d1b324e2389f1ae7e5a8a80d8956b77ddb07612 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:38 -0500
Subject: [PATCH 0438/3820] New translations subgraph-manifest.mdx (Arabic)

---
 .../ar/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/ar/developing/creating-a-subgraph/subgraph-manifest.mdx
index 8c36c56b624a..c81744223b3b 100644
--- a/website/pages/ar/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/ar/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### مصدر البيانات للعقد الرئيسي
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From ad78d091d8e3870717e4a8136e11fdf2fedfffab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:40 -0500
Subject: [PATCH 0439/3820] New translations near.mdx (Czech)

---
 website/pages/cs/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/cookbook/near.mdx b/website/pages/cs/cookbook/near.mdx
index ac95d0149954..1a3b2ed3e4f1 100644
--- a/website/pages/cs/cookbook/near.mdx
+++ b/website/pages/cs/cookbook/near.mdx
@@ -12,7 +12,7 @@ Tato příručka je úvodem do vytváření subgrafů indexujících chytré kon
 
 "The Graph poskytuje vývojářům nástroje pro zpracování událostí na blockchainu a snadný přístup k výsledným datům prostřednictvím GraphQL API, známého individuálně jako podgraf. [Graph Node](https://github.com/graphprotocol/graph-node) je nyní schopen zpracovávat události na síti NEAR, což znamená, že vývojáři na NEAR mohou nyní vytvářet podgrafy pro indexaci svých chytrých kontraktů."
 
-Podgrafy jsou založeny na událostech, což znamená, že naslouchají událostem v řetězci a následně je zpracovávají. V současné době jsou pro podgrafy NEAR podporovány dva typy zpracovatelů:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Obsluhy bloků: jsou spouštěny při každém novém bloku.
 - Obsluhy příjmu: spouštějí se pokaždé, když je zpráva provedena na zadaném účtu.

From 6ec4ccfb3a78fed95c018f822e8b96758298f88b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:41 -0500
Subject: [PATCH 0440/3820] New translations api.mdx (Czech)

---
 website/pages/cs/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/cs/developing/graph-ts/api.mdx b/website/pages/cs/developing/graph-ts/api.mdx
index 799b8a222b5e..f933724d57e6 100644
--- a/website/pages/cs/developing/graph-ts/api.mdx
+++ b/website/pages/cs/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 Od verzí `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 a `@graphprotocol/graph-cli` v0.49.0 je metoda `loadInBlock` dostupná pro všechny typy entit.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Chytré smlouvy příležitostně ukotvují soubory IPFS v řetězci. To umožňuje mapování získat hashe IPFS ze smlouvy a načíst odpovídající soubory z IPFS. Data souborů budou vrácena jako `Bajty`, což obvykle vyžaduje další zpracování, např. pomocí API `json` zdokumentovaného později na této stránce.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Při zadání hashe nebo cesty IPFS se čtení souboru ze systému IPFS provádí následujícím způsobem:
 

From 6d1a20132b698df7d77886d35ec6c176700667c6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:44 -0500
Subject: [PATCH 0441/3820] New translations subgraphs.mdx (Czech)

---
 website/pages/cs/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/subgraphs.mdx b/website/pages/cs/subgraphs.mdx
index 386ea043e174..e6a5724fc868 100644
--- a/website/pages/cs/subgraphs.mdx
+++ b/website/pages/cs/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 1690cba8a6efd37b3ceb1d388d578546fe701e69 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:46 -0500
Subject: [PATCH 0442/3820] New translations transfer-to-the-graph.mdx (Czech)

---
 website/pages/cs/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/cookbook/transfer-to-the-graph.mdx b/website/pages/cs/cookbook/transfer-to-the-graph.mdx
index e0b9a1fbfe53..a451fafc19ba 100644
--- a/website/pages/cs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/cs/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 3cb51d094072f026229ef79294d320e1249be0dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:48 -0500
Subject: [PATCH 0443/3820] New translations subgraph-manifest.mdx (Czech)

---
 .../cs/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/cs/developing/creating-a-subgraph/subgraph-manifest.mdx
index 84ff104974cf..8a2a789623c3 100644
--- a/website/pages/cs/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/cs/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Zdroj dat pro hlavní smlouvu
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From c7d7b783f91e32b7eb157b5a2749e522f9b9556b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:49 -0500
Subject: [PATCH 0444/3820] New translations near.mdx (German)

---
 website/pages/de/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/cookbook/near.mdx b/website/pages/de/cookbook/near.mdx
index 6ab983b22272..893d7579d86b 100644
--- a/website/pages/de/cookbook/near.mdx
+++ b/website/pages/de/cookbook/near.mdx
@@ -12,7 +12,7 @@ This guide is an introduction to building subgraphs indexing smart contracts on
 
 The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
 
-Subgraphs are event-based, which means that they listen for and then process on-chain events. There are currently two types of handlers supported for NEAR subgraphs:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Block handlers: these are run on every new block
 - Receipt handlers: run every time a message is executed at a specified account

From ece4b52d30d5fe0c79cd3eff9b353becc875b2c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:50 -0500
Subject: [PATCH 0445/3820] New translations api.mdx (German)

---
 website/pages/de/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/developing/graph-ts/api.mdx b/website/pages/de/developing/graph-ts/api.mdx
index 020d37ade7f7..da727c3160e6 100644
--- a/website/pages/de/developing/graph-ts/api.mdx
+++ b/website/pages/de/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Given an IPFS hash or path, reading a file from IPFS is done as follows:
 

From 4fba0f175e513829391d0eb504249ff01030cee3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:51 -0500
Subject: [PATCH 0446/3820] New translations subgraphs.mdx (German)

---
 website/pages/de/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs.mdx b/website/pages/de/subgraphs.mdx
index 58cf1e9f6498..91325d31744a 100644
--- a/website/pages/de/subgraphs.mdx
+++ b/website/pages/de/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From dbf8a068a30668b62f279f5138370c86aba6f42b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:52 -0500
Subject: [PATCH 0447/3820] New translations transfer-to-the-graph.mdx (German)

---
 website/pages/de/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/cookbook/transfer-to-the-graph.mdx b/website/pages/de/cookbook/transfer-to-the-graph.mdx
index c9017d23b88f..4470c770e8b5 100644
--- a/website/pages/de/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/de/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Gehen Sie zu [Subgraph Studio] (https://thegraph.com/studio/) und verbinden Sie Ihre Wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 2882925ff0f754b341a2d5d5fe5b0440027ec837 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:53 -0500
Subject: [PATCH 0448/3820] New translations subgraph-manifest.mdx (German)

---
 .../de/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/de/developing/creating-a-subgraph/subgraph-manifest.mdx
index 0adbd44216a0..3075a0d63840 100644
--- a/website/pages/de/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/de/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Data Source for the Main Contract
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From e433411a6d724f36c1c515e4b86d46dbb3a87abc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:54 -0500
Subject: [PATCH 0449/3820] New translations near.mdx (Italian)

---
 website/pages/it/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/cookbook/near.mdx b/website/pages/it/cookbook/near.mdx
index 1d2edfe873eb..6282380266e2 100644
--- a/website/pages/it/cookbook/near.mdx
+++ b/website/pages/it/cookbook/near.mdx
@@ -12,7 +12,7 @@ This guide is an introduction to building subgraphs indexing smart contracts on
 
 The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
 
-Subgraphs are event-based, which means that they listen for and then process on-chain events. There are currently two types of handlers supported for NEAR subgraphs:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Block handlers: these are run on every new block
 - Receipt handlers: run every time a message is executed at a specified account

From a8d7c90315398fbe77576392957cfb60af6d73f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:56 -0500
Subject: [PATCH 0450/3820] New translations api.mdx (Italian)

---
 website/pages/it/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/it/developing/graph-ts/api.mdx b/website/pages/it/developing/graph-ts/api.mdx
index 4edadedcff5e..1a945e0517ce 100644
--- a/website/pages/it/developing/graph-ts/api.mdx
+++ b/website/pages/it/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 A partire da `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 e `@graphprotocol/graph-cli` v0.49.0 il metodo `loadInBlock` è disponibile per tutti i tipi di entità.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Gli smart contract di tanto in tanto ancorano i file IPFS sulla chain. Ciò consente alle mappature di ottenere gli hash IPFS dal contratto e di leggere i file corrispondenti da IPFS. I dati del file saranno restituiti come `Byte`, che di solito richiedono un'ulteriore elaborazione, ad esempio con l'API `json` documentata più avanti in questa pagina.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Dato un hash o un percorso IPFS, la lettura di un file da IPFS avviene come segue:
 

From 48cba79b725ff07020b7e80cc5dacc1b6db941f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:57 -0500
Subject: [PATCH 0451/3820] New translations subgraphs.mdx (Italian)

---
 website/pages/it/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/subgraphs.mdx b/website/pages/it/subgraphs.mdx
index ba810051a7c4..a186c0ebffd2 100644
--- a/website/pages/it/subgraphs.mdx
+++ b/website/pages/it/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 4ef37eb79d25b8d431e1a2781b87bcfefde63486 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:58 -0500
Subject: [PATCH 0452/3820] New translations transfer-to-the-graph.mdx
 (Italian)

---
 website/pages/it/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/cookbook/transfer-to-the-graph.mdx b/website/pages/it/cookbook/transfer-to-the-graph.mdx
index be40d06f45c0..859bd7be8c7e 100644
--- a/website/pages/it/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/it/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From bf584929b47a6c99c1ece060073a2d9713029731 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:21:59 -0500
Subject: [PATCH 0453/3820] New translations subgraph-manifest.mdx (Italian)

---
 .../it/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/it/developing/creating-a-subgraph/subgraph-manifest.mdx
index 43e510cf1a7a..f03d66833dfa 100644
--- a/website/pages/it/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/it/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Data Source per il contratto principale
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From e64b6d68f4927b11b38b64f253bdfe40dfd5b958 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:00 -0500
Subject: [PATCH 0454/3820] New translations near.mdx (Japanese)

---
 website/pages/ja/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/cookbook/near.mdx b/website/pages/ja/cookbook/near.mdx
index 8c5f1625eaeb..014b3b5f1493 100644
--- a/website/pages/ja/cookbook/near.mdx
+++ b/website/pages/ja/cookbook/near.mdx
@@ -12,7 +12,7 @@ title: NEAR でサブグラフを作成する
 
 Graph は、ブロックチェーンのイベントを処理し、その結果得られたデータを GraphQL API を介して簡単に利用できるようにするためのツールを開発者に提供するもので、個別にはサブグラフとして知られています。[Graph Node](https://github.com/graphprotocol/graph-node)が NEAR イベントを処理できるようになったということは、NEAR の開発者がスマートコントラクトの指標となるサブグラフを構築できるようになったということです。
 
-サブグラフはイベントベースなので、チェーン上のイベントをリッスンしてから処理します。現在、NEAR サブグラフでサポートされているハンドラーは 2 種類あります:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - ブロックハンドラ：新しいブロックごとに実行されます
 - レシートハンドラ：指定されたアカウントでメッセージが実行されるたびに実行されます

From e17852c61e909d2c3eab9d092b6c424068f1ab5e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:01 -0500
Subject: [PATCH 0455/3820] New translations api.mdx (Japanese)

---
 website/pages/ja/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ja/developing/graph-ts/api.mdx b/website/pages/ja/developing/graph-ts/api.mdx
index cea9a55eb75c..4a3fc2254031 100644
--- a/website/pages/ja/developing/graph-ts/api.mdx
+++ b/website/pages/ja/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 graph-node v0.31.0、@graphprotocol/graph-ts v0.30.0、および @graphprotocol/graph-cli v0.49.0 以降、 loadInBlock メソッドはすべてのエンティティ タイプで使用できます。
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 '@graphprotocol/graph-ts'から { ipfs } をインポートします。
 ```
 
-スマートコントラクトは時折、チェーン上の IPFS ファイルをアンカリングします。 これにより、マッピングはコントラクトから IPFS ハッシュを取得し、IPFS から対応するファイルを読み取ることができます。 ファイルのデータはBytesとして返されますが、通常は、このページで後述する json API などを使ってさらに処理する必要があります。
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 IPFS のハッシュやパスが与えられた場合、IPFS からのファイルの読み込みは以下のように行われます。
 

From b0f7420a868027778c1c8862909eed33b6771225 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:03 -0500
Subject: [PATCH 0456/3820] New translations subgraphs.mdx (Japanese)

---
 website/pages/ja/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/subgraphs.mdx b/website/pages/ja/subgraphs.mdx
index 4801361f96eb..3180b952c45f 100644
--- a/website/pages/ja/subgraphs.mdx
+++ b/website/pages/ja/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 73fb498458d7cb8ddcdf142a78d73d31761f70c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:04 -0500
Subject: [PATCH 0457/3820] New translations transfer-to-the-graph.mdx
 (Japanese)

---
 website/pages/ja/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/cookbook/transfer-to-the-graph.mdx b/website/pages/ja/cookbook/transfer-to-the-graph.mdx
index 3b064acb6cd5..8477e7ca94e6 100644
--- a/website/pages/ja/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/ja/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 46b0e2395af6452c0d6967cef5bf1f3252f42f93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:06 -0500
Subject: [PATCH 0458/3820] New translations subgraph-manifest.mdx (Japanese)

---
 .../ja/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/ja/developing/creating-a-subgraph/subgraph-manifest.mdx
index 76206b5791cb..c9ea95d0b679 100644
--- a/website/pages/ja/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/ja/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### メインコントラクトのデータソース
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From a19f9f0dfef15378850f746f054163ef48463df4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:07 -0500
Subject: [PATCH 0459/3820] New translations near.mdx (Korean)

---
 website/pages/ko/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/cookbook/near.mdx b/website/pages/ko/cookbook/near.mdx
index f2509e44e84c..d382e179b948 100644
--- a/website/pages/ko/cookbook/near.mdx
+++ b/website/pages/ko/cookbook/near.mdx
@@ -12,7 +12,7 @@ This guide is an introduction to building subgraphs indexing smart contracts on
 
 The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
 
-Subgraphs are event-based, which means that they listen for and then process on-chain events. There are currently two types of handlers supported for NEAR subgraphs:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Block handlers: these are run on every new block
 - Receipt handlers: run every time a message is executed at a specified account

From ff6a7c36146b040a1332b2f0198e2e695ae5c26c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:08 -0500
Subject: [PATCH 0460/3820] New translations api.mdx (Korean)

---
 website/pages/ko/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ko/developing/graph-ts/api.mdx b/website/pages/ko/developing/graph-ts/api.mdx
index 8fc1f4b48b61..34aca9ef10ee 100644
--- a/website/pages/ko/developing/graph-ts/api.mdx
+++ b/website/pages/ko/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Given an IPFS hash or path, reading a file from IPFS is done as follows:
 

From 806ad07f502f3dd4a37b6951269dd2a225864da1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:10 -0500
Subject: [PATCH 0461/3820] New translations subgraphs.mdx (Korean)

---
 website/pages/ko/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/subgraphs.mdx b/website/pages/ko/subgraphs.mdx
index 42c1e806f822..1fdd0baf80eb 100644
--- a/website/pages/ko/subgraphs.mdx
+++ b/website/pages/ko/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From ca6bc157b4c055b7a33f3836bc5459a72307f816 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:11 -0500
Subject: [PATCH 0462/3820] New translations transfer-to-the-graph.mdx (Korean)

---
 website/pages/ko/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/cookbook/transfer-to-the-graph.mdx b/website/pages/ko/cookbook/transfer-to-the-graph.mdx
index 6a5d2c2793f3..e3acb966c427 100644
--- a/website/pages/ko/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/ko/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From bf5ab921374e65a784ca6b5a17e49b45260e12d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:12 -0500
Subject: [PATCH 0463/3820] New translations subgraph-manifest.mdx (Korean)

---
 .../ko/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/ko/developing/creating-a-subgraph/subgraph-manifest.mdx
index f282f3946e75..4af0a0adbf2d 100644
--- a/website/pages/ko/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/ko/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Data Source for the Main Contract
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 77fc7c702f7565cbce870a959b77102c39911fa1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:13 -0500
Subject: [PATCH 0464/3820] New translations near.mdx (Dutch)

---
 website/pages/nl/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/cookbook/near.mdx b/website/pages/nl/cookbook/near.mdx
index 46090338ae0d..4f480a159c91 100644
--- a/website/pages/nl/cookbook/near.mdx
+++ b/website/pages/nl/cookbook/near.mdx
@@ -12,7 +12,7 @@ This guide is an introduction to building subgraphs indexing smart contracts on
 
 The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
 
-Subgraphs are event-based, which means that they listen for and then process on-chain events. There are currently two types of handlers supported for NEAR subgraphs:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Block handlers: these are run on every new block
 - Receipt handlers: run every time a message is executed at a specified account

From d0606fa11aefd1ef6bec9766a743faa9551a2937 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:14 -0500
Subject: [PATCH 0465/3820] New translations api.mdx (Dutch)

---
 website/pages/nl/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/nl/developing/graph-ts/api.mdx b/website/pages/nl/developing/graph-ts/api.mdx
index 8fc1f4b48b61..34aca9ef10ee 100644
--- a/website/pages/nl/developing/graph-ts/api.mdx
+++ b/website/pages/nl/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Given an IPFS hash or path, reading a file from IPFS is done as follows:
 

From 9c07336949757d791a2fb7c75a1fbb55cb2820c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:15 -0500
Subject: [PATCH 0466/3820] New translations subgraphs.mdx (Dutch)

---
 website/pages/nl/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/subgraphs.mdx b/website/pages/nl/subgraphs.mdx
index 42c1e806f822..1fdd0baf80eb 100644
--- a/website/pages/nl/subgraphs.mdx
+++ b/website/pages/nl/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 3cb8091cea43af172918e9e97f8c90c3d4ffd08d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:16 -0500
Subject: [PATCH 0467/3820] New translations transfer-to-the-graph.mdx (Dutch)

---
 website/pages/nl/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/cookbook/transfer-to-the-graph.mdx b/website/pages/nl/cookbook/transfer-to-the-graph.mdx
index 6a5d2c2793f3..e3acb966c427 100644
--- a/website/pages/nl/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/nl/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 4733fe7e83880b05f692519c4cae7caddd5ec532 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:18 -0500
Subject: [PATCH 0468/3820] New translations subgraph-manifest.mdx (Dutch)

---
 .../nl/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/nl/developing/creating-a-subgraph/subgraph-manifest.mdx
index f282f3946e75..4af0a0adbf2d 100644
--- a/website/pages/nl/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/nl/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Data Source for the Main Contract
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From ba1ec11bbf88afdf6fc485d2e069fe8d35c254fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:19 -0500
Subject: [PATCH 0469/3820] New translations near.mdx (Polish)

---
 website/pages/pl/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/cookbook/near.mdx b/website/pages/pl/cookbook/near.mdx
index f2509e44e84c..d382e179b948 100644
--- a/website/pages/pl/cookbook/near.mdx
+++ b/website/pages/pl/cookbook/near.mdx
@@ -12,7 +12,7 @@ This guide is an introduction to building subgraphs indexing smart contracts on
 
 The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
 
-Subgraphs are event-based, which means that they listen for and then process on-chain events. There are currently two types of handlers supported for NEAR subgraphs:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Block handlers: these are run on every new block
 - Receipt handlers: run every time a message is executed at a specified account

From 7d70302b41db7e745c7514d18c4c4e8cf1a97f87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:20 -0500
Subject: [PATCH 0470/3820] New translations api.mdx (Polish)

---
 website/pages/pl/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pl/developing/graph-ts/api.mdx b/website/pages/pl/developing/graph-ts/api.mdx
index 8fc1f4b48b61..34aca9ef10ee 100644
--- a/website/pages/pl/developing/graph-ts/api.mdx
+++ b/website/pages/pl/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Given an IPFS hash or path, reading a file from IPFS is done as follows:
 

From c6d5f0cc2a373e396d3efd5acab1ef64a2be48dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:21 -0500
Subject: [PATCH 0471/3820] New translations subgraphs.mdx (Polish)

---
 website/pages/pl/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/subgraphs.mdx b/website/pages/pl/subgraphs.mdx
index 614577e46fb0..9c36957c51f5 100644
--- a/website/pages/pl/subgraphs.mdx
+++ b/website/pages/pl/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From eb7e8061154334532fda55938a2bf8fba0095ae2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:22 -0500
Subject: [PATCH 0472/3820] New translations transfer-to-the-graph.mdx (Polish)

---
 website/pages/pl/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/cookbook/transfer-to-the-graph.mdx b/website/pages/pl/cookbook/transfer-to-the-graph.mdx
index 6a5d2c2793f3..e3acb966c427 100644
--- a/website/pages/pl/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/pl/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 8cd5d816d08b7053e6789519802922cc9e01f4ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:23 -0500
Subject: [PATCH 0473/3820] New translations subgraph-manifest.mdx (Polish)

---
 .../pl/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/pl/developing/creating-a-subgraph/subgraph-manifest.mdx
index f282f3946e75..4af0a0adbf2d 100644
--- a/website/pages/pl/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/pl/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Data Source for the Main Contract
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From e313b9e0fc274e12d13fab6e5cb64fa13b85d3d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:24 -0500
Subject: [PATCH 0474/3820] New translations near.mdx (Portuguese)

---
 website/pages/pt/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/cookbook/near.mdx b/website/pages/pt/cookbook/near.mdx
index 1b7c1254531f..a90573187f2b 100644
--- a/website/pages/pt/cookbook/near.mdx
+++ b/website/pages/pt/cookbook/near.mdx
@@ -12,7 +12,7 @@ O [NEAR](https://near.org/) é uma plataforma de contratos inteligentes para a c
 
 Os programadores do The Graph recebem ferramentas para processar eventos em blockchain e disponibilizar facilmente os dados resultantes através de uma API GraphQL, conhecida individualmente como um subgraph. O [Graph Node](https://github.com/graphprotocol/graph-node) agora é capaz de processar eventos no NEAR, significando que programadores na NEAR agora podem construir subgraphs para indexar seus contratos inteligentes.
 
-Subgraphs são baseados em eventos; quer dizer, eles esperam e então processam eventos on-chain. Atualmente há dois tipos de handlers que funcionam para subgraphs no NEAR:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Handlers de blocos: executados em todos os blocos novos
 - Handlers de recibos: Executados sempre que uma mensagem é executada numa conta especificada

From 4179062ccf7fbd16b491d017913ca65bea501e94 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:26 -0500
Subject: [PATCH 0475/3820] New translations api.mdx (Portuguese)

---
 website/pages/pt/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pt/developing/graph-ts/api.mdx b/website/pages/pt/developing/graph-ts/api.mdx
index acc557d643ab..4c863ee78024 100644
--- a/website/pages/pt/developing/graph-ts/api.mdx
+++ b/website/pages/pt/developing/graph-ts/api.mdx
@@ -281,7 +281,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 Desde o `graph-node` v0.31.0, o `@graphprotocol/graph-ts` v0.30.0 e o `@graphprotocol/graph-cli v0.49.0`, o método `loadInBlock` está disponível em todos os tipos de entidade.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -673,7 +673,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Contratos inteligentes ocasionalmente ancoram arquivos IPFS on-chain. Assim, os mapeamentos obtém os hashes IPFS do contrato e lêem os arquivos correspondentes do IPFS. Os dados dos arquivos serão retornados como `Bytes`, o que costuma exigir mais processamento; por ex., com a API `json` documentada mais abaixo nesta página.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Considerando um hash ou local IPFS, um arquivo do IPFS é lido da seguinte maneira:
 

From 394056555e16d72639e7468e5ae500333921d091 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:27 -0500
Subject: [PATCH 0476/3820] New translations subgraphs.mdx (Portuguese)

---
 website/pages/pt/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs.mdx b/website/pages/pt/subgraphs.mdx
index 5ca8d4007ec4..3227ac5e1f72 100644
--- a/website/pages/pt/subgraphs.mdx
+++ b/website/pages/pt/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 6063e10cf089403a976510328f0c13a018228e27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:28 -0500
Subject: [PATCH 0477/3820] New translations transfer-to-the-graph.mdx
 (Portuguese)

---
 website/pages/pt/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/cookbook/transfer-to-the-graph.mdx b/website/pages/pt/cookbook/transfer-to-the-graph.mdx
index 7d0d8cda34c4..67209945dd70 100644
--- a/website/pages/pt/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/pt/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 78f145ee7ea7afcfc2929e796d53c12cb06dc07a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:29 -0500
Subject: [PATCH 0478/3820] New translations subgraph-manifest.mdx (Portuguese)

---
 .../pt/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/pt/developing/creating-a-subgraph/subgraph-manifest.mdx
index e56c0a59dba8..555e26b5ae90 100644
--- a/website/pages/pt/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/pt/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Fonte de Dados para o Contrato Principal
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 10d75799bb5e16810208ff52310788907ef7f73b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:30 -0500
Subject: [PATCH 0479/3820] New translations near.mdx (Russian)

---
 website/pages/ru/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/cookbook/near.mdx b/website/pages/ru/cookbook/near.mdx
index f462d71a036a..ccfe9185cffc 100644
--- a/website/pages/ru/cookbook/near.mdx
+++ b/website/pages/ru/cookbook/near.mdx
@@ -12,7 +12,7 @@ title: Создание субграфов на NEAR
 
 The Graph предоставляет разработчикам инструменты для обработки событий блокчейна и делает результирующие данные легко доступными через GraphQL API, известный индивидуально как субграф. [Graph Node](https://github.com/graphprotocol/graph-node) теперь способен обрабатывать события NEAR, что означает, что разработчики NEAR теперь могут создавать субграфы для индексации своих смарт-контрактов.
 
-Субграфы основаны на событиях, что означает, что они отслеживают и затем обрабатывают события в сети. В настоящее время для подграфов NEAR поддерживаются два типа обработчиков:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Обработчики блоков: они запускаются для каждого нового блока
 - Обработчики квитанций: запускаются каждый раз, когда сообщение выполняется в указанной учетной записи

From 07f8b5e5084c94c802427d92093a894278b11dfa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:31 -0500
Subject: [PATCH 0480/3820] New translations transfer-to-the-graph.mdx
 (Russian)

---
 website/pages/ru/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/cookbook/transfer-to-the-graph.mdx b/website/pages/ru/cookbook/transfer-to-the-graph.mdx
index 4c003ddfd40d..a3fc17c877a9 100644
--- a/website/pages/ru/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/ru/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Перейдите в [Subgraph Studio](https://thegraph.com/studio/) и подключите свой кошелек.
 - Нажмите "Создать субграф". Рекомендуется называть субграф с использованием Заглавного регистра: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 8bffbd4c5455c3d68762c5eb06f68e1a90b43b0d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:32 -0500
Subject: [PATCH 0481/3820] New translations subgraph-manifest.mdx (Russian)

---
 .../ru/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/ru/developing/creating-a-subgraph/subgraph-manifest.mdx
index 4a8f9c3a7aac..a44ce035a1a3 100644
--- a/website/pages/ru/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/ru/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Источник данных для основного контракта
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 40abccfdd97921046b7c5bd1d227d34142bc5b51 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:33 -0500
Subject: [PATCH 0482/3820] New translations near.mdx (Swedish)

---
 website/pages/sv/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/cookbook/near.mdx b/website/pages/sv/cookbook/near.mdx
index 78fb45077df5..b627c8d0d671 100644
--- a/website/pages/sv/cookbook/near.mdx
+++ b/website/pages/sv/cookbook/near.mdx
@@ -12,7 +12,7 @@ Den här guiden är en introduktion till att bygga subgrafer som indexerar smart
 
 The Graph ger utvecklare verktyg för att bearbeta blockchain-händelser och göra den resulterande informationen lätt tillgänglig via ett GraphQL API, individuellt känt som en subgraf. [Graph Node](https://github.com/graphprotocol/graph-node) kan nu bearbeta NEAR-händelser, vilket innebär att NEAR-utvecklare nu kan bygga subgrafer för att indexera sina smarta kontrakt.
 
-Subgrafer är händelsebaserade, vilket innebär att de lyssnar efter och sedan bearbetar händelser i kedjan. Det finns för närvarande två typer av hanterare som stöds för NEAR subgrafer:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Blockhanterare: dessa körs på varje nytt block
 - Kvittohanterare: körs varje gång ett meddelande körs på ett angivet konto

From 2c8c3b9733ab2d2bdfaddb80227c9ee85ff311e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:35 -0500
Subject: [PATCH 0483/3820] New translations api.mdx (Swedish)

---
 website/pages/sv/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sv/developing/graph-ts/api.mdx b/website/pages/sv/developing/graph-ts/api.mdx
index 2dbb19d8f5cf..f5fafa3ec973 100644
--- a/website/pages/sv/developing/graph-ts/api.mdx
+++ b/website/pages/sv/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -682,7 +682,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from "@graphprotocol/graph-ts"
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 För att läsa en fil från IPFS med en given IPFS-hash eller sökväg görs följande:
 

From 94f4e2f7a2554c7fdc5444e36d466c0d5aa742a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:36 -0500
Subject: [PATCH 0484/3820] New translations subgraphs.mdx (Swedish)

---
 website/pages/sv/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/subgraphs.mdx b/website/pages/sv/subgraphs.mdx
index ff81ea93c8b9..e30dbda31901 100644
--- a/website/pages/sv/subgraphs.mdx
+++ b/website/pages/sv/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From d25fb7ca638ac8e5a5f22728e3c671ade3b5cd3f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:37 -0500
Subject: [PATCH 0485/3820] New translations transfer-to-the-graph.mdx
 (Swedish)

---
 website/pages/sv/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/cookbook/transfer-to-the-graph.mdx b/website/pages/sv/cookbook/transfer-to-the-graph.mdx
index 34d7ef222024..65209742aaee 100644
--- a/website/pages/sv/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/sv/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From dafcf39bd72e4b8660108bc7a7678902b476bdd9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:38 -0500
Subject: [PATCH 0486/3820] New translations subgraph-manifest.mdx (Swedish)

---
 .../sv/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/sv/developing/creating-a-subgraph/subgraph-manifest.mdx
index eedbf6b73287..984fce79d8bc 100644
--- a/website/pages/sv/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/sv/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Datakälla för huvudkontraktet
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 98e5f71898ef401e7eb8cf1efee4a3febf9ee0ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:39 -0500
Subject: [PATCH 0487/3820] New translations near.mdx (Turkish)

---
 website/pages/tr/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/cookbook/near.mdx b/website/pages/tr/cookbook/near.mdx
index e55819a7d0e7..50aeaa2cc195 100644
--- a/website/pages/tr/cookbook/near.mdx
+++ b/website/pages/tr/cookbook/near.mdx
@@ -12,7 +12,7 @@ Bu rehber, [NEAR blok zincirinde](https://docs.near.org/) akıllı sözleşmeler
 
 Graph, geliştiricilere blok zinciri olaylarını işlemek ve elde edilen verileri tek tek subgraph olarak bilinen bir GraphQL API aracılığıyla kolayca erişilebilir hale getirmek için araçlar sunar. [Graph Düğümü](https://github.com/graphprotocol/graph-node) artık NEAR olaylarını işleyebiliyor, bu da NEAR geliştiricilerinin artık akıllı sözleşmelerini indekslemek için subgraphlar oluşturabilecekleri anlamına geliyor.
 
-Subgraphlar olay tabanlıdır, yani zincir üzerindeki olayların etkinliklerini gözler ve ardından işlerler. Şu anda NEAR subgraphları için desteklenen iki tür işleyici vardır:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Blok işleyicileri: Bunlar her yeni blokta çalışır
 - Makbuz işleyicileri: Belirli bir hesapta her mesaj yürütüldüğünde çalışır

From ffb7576c4c52d4e3f234f6c37eb1243c21b45e4f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:40 -0500
Subject: [PATCH 0488/3820] New translations api.mdx (Turkish)

---
 website/pages/tr/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/developing/graph-ts/api.mdx b/website/pages/tr/developing/graph-ts/api.mdx
index b8a4af72cc47..c20f231f4145 100644
--- a/website/pages/tr/developing/graph-ts/api.mdx
+++ b/website/pages/tr/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ Varlık henüz depoda mevcut olmayabileceğinden, `load` yöntemi `Transfer | nu
 
 `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 ve `@graphprotocol/graph-cli` v0.49.0 itibarıyla `loadInBlock` metodu tüm varlık türlerinde kullanılabilir hale gelmiştir.
 
-Store API'si mevcut blokta oluşturulan veya güncellenen varlıkların alınmasına olanak tanır. Bunun tipik bir örneği, bir işleyicinin zincir-üzeri bir olaydan bir işlem oluşturması ve sonraki bir işleyicinin, bu işlem mevcutsa ona erişmek istemesidir.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - Eğer işlem mevcut değilse subgraph sırf varlığın mevcut olmadığını öğrenmek için veritabanına başvurmak zorunda kalacaktır. Ancak, subgraph yazarı varlığın aynı blokta oluşturulmuş olması gerektiğini zaten biliyorsa, `loadInBlock` kullanmak bu veritabanı sorgusunu ortadan kaldırır.
 - Bazı subgraph'lerde bu başarısız aramalar endeksleme süresine önemli ölçüde etki edebilir.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Akıllı sözleşmeler bazen IPFS dosyalarını zincire sabitler. Bu, eşlemelerin sözleşmeden IPFS hash'lerini almasını ve ilgili dosyaları IPFS'ten okumasını sağlar. Dosya verileri `Bytes` olarak döndürülür ve genellikle daha fazla işleme tabi tutulması gerekir; örneğin, bu sayfada daha sonra belgelenen `json` API'si ile.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 IPFS hash'ı veya yolu verildiğinde, bir dosyayı IPFS'den okuma şu şekilde yapılır:
 

From 6f52636aaf3bcff17a86dafdcbb9f2febe94005a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:42 -0500
Subject: [PATCH 0489/3820] New translations transfer-to-the-graph.mdx
 (Turkish)

---
 website/pages/tr/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/cookbook/transfer-to-the-graph.mdx b/website/pages/tr/cookbook/transfer-to-the-graph.mdx
index 879b63e66039..41bf51eb3add 100644
--- a/website/pages/tr/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/tr/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - [Subgraph Studio](https://thegraph.com/studio/)'ya gidin ve cüzdanınızı bağlayın.
 - "Subgraph Oluştur" düğmesine tıklayın. Subgraph'in adını başlık formunda vermeniz önerilir: "Subgraph Adı Ağ Adı".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From b288921df97c0be90509325927743f3f43e1439e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:43 -0500
Subject: [PATCH 0490/3820] New translations subgraph-manifest.mdx (Turkish)

---
 .../tr/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/tr/developing/creating-a-subgraph/subgraph-manifest.mdx
index 702a2183dc23..96360efadbf3 100644
--- a/website/pages/tr/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/tr/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Ana Sözleşme için Veri Kaynağı
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From deecc6558f81941706a1e8b28f0f425b9f414c6f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:44 -0500
Subject: [PATCH 0491/3820] New translations near.mdx (Ukrainian)

---
 website/pages/uk/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/cookbook/near.mdx b/website/pages/uk/cookbook/near.mdx
index 3d72ba528304..f16952ec4f1d 100644
--- a/website/pages/uk/cookbook/near.mdx
+++ b/website/pages/uk/cookbook/near.mdx
@@ -12,7 +12,7 @@ This guide is an introduction to building subgraphs indexing smart contracts on
 
 The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
 
-Subgraphs are event-based, which means that they listen for and then process on-chain events. There are currently two types of handlers supported for NEAR subgraphs:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Block handlers: these are run on every new block
 - Receipt handlers: run every time a message is executed at a specified account

From 49b40c82ceb0446a47b3f3090d25826b32d805cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:45 -0500
Subject: [PATCH 0492/3820] New translations api.mdx (Ukrainian)

---
 website/pages/uk/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/uk/developing/graph-ts/api.mdx b/website/pages/uk/developing/graph-ts/api.mdx
index 8fc1f4b48b61..34aca9ef10ee 100644
--- a/website/pages/uk/developing/graph-ts/api.mdx
+++ b/website/pages/uk/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Given an IPFS hash or path, reading a file from IPFS is done as follows:
 

From 016a3438cca35537e31ba3dbaead50bc6b559e90 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:46 -0500
Subject: [PATCH 0493/3820] New translations subgraphs.mdx (Ukrainian)

---
 website/pages/uk/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/subgraphs.mdx b/website/pages/uk/subgraphs.mdx
index 1e93ac7c30b8..5bc4e3275b35 100644
--- a/website/pages/uk/subgraphs.mdx
+++ b/website/pages/uk/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 007bdb7015f97fe736bc6b47547e7f22e88282d0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:47 -0500
Subject: [PATCH 0494/3820] New translations transfer-to-the-graph.mdx
 (Ukrainian)

---
 website/pages/uk/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/cookbook/transfer-to-the-graph.mdx b/website/pages/uk/cookbook/transfer-to-the-graph.mdx
index f4166f2d3fe6..164452240cbd 100644
--- a/website/pages/uk/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/uk/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 1c5b6edd575801665f60c3cc3ce79ebf1b5d70ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:49 -0500
Subject: [PATCH 0495/3820] New translations subgraph-manifest.mdx (Ukrainian)

---
 .../uk/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/uk/developing/creating-a-subgraph/subgraph-manifest.mdx
index f282f3946e75..4af0a0adbf2d 100644
--- a/website/pages/uk/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/uk/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Data Source for the Main Contract
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 8db72b04f12165d4ae7ea84b570dcae2b69723c6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:50 -0500
Subject: [PATCH 0496/3820] New translations near.mdx (Chinese Simplified)

---
 website/pages/zh/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/cookbook/near.mdx b/website/pages/zh/cookbook/near.mdx
index 25598b11f46d..8f1fa903538b 100644
--- a/website/pages/zh/cookbook/near.mdx
+++ b/website/pages/zh/cookbook/near.mdx
@@ -12,7 +12,7 @@ title: 在 NEAR 上构建子图
 
 Graph 为开发人员提供了一种被称为子图的工具，利用这个工具，开发人员能够处理区块链事件，并通过 GraphQL API 提供结果数据。 [Graph 节点](https://github.com/graphprotocol/graph-node)现在能够处理 NEAR 事件，这意味着 NEAR 开发人员现在可以构建子图来索引他们的智能合约。
 
-子图是基于事件的，这意味着子图可以侦听并处理链上事件。 NEAR 子图目前支持两种类型的处理程序：
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - 区块处理器: 这些处理程序在每个新区块上运行。
 - 收据处理器: 每次在指定账户上一个消息被执行时运行。

From f50df70df3da65ea67f17bfcdc15a6e13465f078 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:51 -0500
Subject: [PATCH 0497/3820] New translations api.mdx (Chinese Simplified)

---
 website/pages/zh/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/developing/graph-ts/api.mdx b/website/pages/zh/developing/graph-ts/api.mdx
index 0bb53153fae9..90f73e66d436 100644
--- a/website/pages/zh/developing/graph-ts/api.mdx
+++ b/website/pages/zh/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 截至 `graph-node` v0.31.0、`@graphprotocol/graph-ts` v0.30.0 和 `@graphprotocol/graph-cli` v0.49.0，所有实体类型上都提供了 `loadInBlock` 方法。
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -671,7 +671,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 从 '@graphprotocol/graph-ts'导入{ ipfs }
 ```
 
-智能合约偶尔会在链上固定 IPFS 文件。这允许映射从合约获取 IPFS 哈希并从 IPFS 读取相应的文件。文件数据将作为 `Bytes` 返回，通常需要进一步处理，例如使用稍后在本页面中记录的 `json` API。
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 给定一个 IPFS hash或路径，从 IPFS 读取文件的过程如下：
 

From 5b85fa99011cb716865812093322058ca1a1821d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:52 -0500
Subject: [PATCH 0498/3820] New translations subgraphs.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs.mdx b/website/pages/zh/subgraphs.mdx
index bf8d590fe7e9..68f566e43b18 100644
--- a/website/pages/zh/subgraphs.mdx
+++ b/website/pages/zh/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 91fe142478cb2cd3d64ea743bf1b746eae50870c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:53 -0500
Subject: [PATCH 0499/3820] New translations transfer-to-the-graph.mdx (Chinese
 Simplified)

---
 website/pages/zh/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/cookbook/transfer-to-the-graph.mdx b/website/pages/zh/cookbook/transfer-to-the-graph.mdx
index 5186b6088071..0c8abaa68597 100644
--- a/website/pages/zh/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/zh/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 8aff4b53ffd1c780d48615c9a476e1ac282bbe99 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:54 -0500
Subject: [PATCH 0500/3820] New translations subgraph-manifest.mdx (Chinese
 Simplified)

---
 .../zh/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/zh/developing/creating-a-subgraph/subgraph-manifest.mdx
index 58f782bc4bb7..735ec4ebf832 100644
--- a/website/pages/zh/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/zh/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### 主合约的数据源
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 39687a48f4614d313be0d731bb344df5857a637d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:55 -0500
Subject: [PATCH 0501/3820] New translations near.mdx (Urdu (Pakistan))

---
 website/pages/ur/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/cookbook/near.mdx b/website/pages/ur/cookbook/near.mdx
index 30855c266732..e966448fd9ea 100644
--- a/website/pages/ur/cookbook/near.mdx
+++ b/website/pages/ur/cookbook/near.mdx
@@ -12,7 +12,7 @@ title: سب گرافس کو NEAR پر بنانا
 
 گراف ڈویلپرز کو بلاکچین ایونٹس پر کارروائی کرنے کے لیے ٹولز دیتا ہے اور نتیجے میں ڈیٹا کو GraphQL API کے ذریعے آسانی سے دستیاب کرتا ہے، جسے انفرادی طور پر سب گراف کے نام سے جانا جاتا ہے۔ [گراف نوڈ](https://github.com/graphprotocol/graph-node) اب NEAR ایونٹس پر کارروائی کرنے کے قابل ہے، جس کا مطلب ہے کہ NEAR ڈویلپرز اب اپنے سمارٹ کنٹریکٹ کو انڈیکس کرنے کے لیے سب گراف بنا سکتے ہیں.
 
-سب گراف ایونٹس پر مبنی ہیں, جس کا مطلب ہے کہ وہ آن چین ایونٹس کو سنتے ہیں اور پھر اس پر کارروائی کرتے ہیں. NEAR سب گرافس کے لیے فی الحال دو قسم کے ہینڈلرز کی حمایت کی جاتی ہے:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - بلاک ہینڈلرز: یہ ہر نۓ بلاک پر چلتے ہیں
 - ریسیپٹ ہینڈلرز: ہر بار جب کسی مخصوص اکاؤنٹ پر کوئی پیغام عمل میں آۓ تو چلتا ہے

From 9e758f1fb8df8cdba8123640267d5312b74af6f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:57 -0500
Subject: [PATCH 0502/3820] New translations api.mdx (Urdu (Pakistan))

---
 website/pages/ur/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ur/developing/graph-ts/api.mdx b/website/pages/ur/developing/graph-ts/api.mdx
index 1a796d4b0b41..6060393db184 100644
--- a/website/pages/ur/developing/graph-ts/api.mdx
+++ b/website/pages/ur/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 IPFS ہیش یا پاتھ کو دیکھتے ہوئے، IPFS سے فائل کو پڑھنا اس طرح کیا جاتا ہے:
 

From bfcfd04cfb295fb35225fb4b32bc6c0cb45dc5c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:22:58 -0500
Subject: [PATCH 0503/3820] New translations subgraphs.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/subgraphs.mdx b/website/pages/ur/subgraphs.mdx
index 5886281f8274..f142d119bb35 100644
--- a/website/pages/ur/subgraphs.mdx
+++ b/website/pages/ur/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 1bad93b2fa46896ce8e3867a90afe6883ecc5053 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:00 -0500
Subject: [PATCH 0504/3820] New translations transfer-to-the-graph.mdx (Urdu
 (Pakistan))

---
 website/pages/ur/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/cookbook/transfer-to-the-graph.mdx b/website/pages/ur/cookbook/transfer-to-the-graph.mdx
index b5effc7221d4..a81d9964455c 100644
--- a/website/pages/ur/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/ur/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 5c430a14073b52f85c0de14e3cf83b02936114bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:01 -0500
Subject: [PATCH 0505/3820] New translations subgraph-manifest.mdx (Urdu
 (Pakistan))

---
 .../ur/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/ur/developing/creating-a-subgraph/subgraph-manifest.mdx
index d81254c61923..43a1253de7f5 100644
--- a/website/pages/ur/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/ur/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### مرکزی کنٹریکٹ کے لیے ڈیٹا سورس
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 02c49ba100495a6e576eb3f28befa4718e6b48c6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:03 -0500
Subject: [PATCH 0506/3820] New translations near.mdx (Vietnamese)

---
 website/pages/vi/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/cookbook/near.mdx b/website/pages/vi/cookbook/near.mdx
index 9f56cb19e152..7da09218e8fa 100644
--- a/website/pages/vi/cookbook/near.mdx
+++ b/website/pages/vi/cookbook/near.mdx
@@ -12,7 +12,7 @@ This guide is an introduction to building subgraphs indexing smart contracts on
 
 The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
 
-Subgraphs are event-based, which means that they listen for and then process on-chain events. There are currently two types of handlers supported for NEAR subgraphs:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Block handlers: these are run on every new block
 - Receipt handlers: run every time a message is executed at a specified account

From 2bd2a13bad509831b4f9d59af7f2d876b2906355 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:04 -0500
Subject: [PATCH 0507/3820] New translations api.mdx (Vietnamese)

---
 website/pages/vi/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/vi/developing/graph-ts/api.mdx b/website/pages/vi/developing/graph-ts/api.mdx
index cff2389b0279..63c0c61a4c6c 100644
--- a/website/pages/vi/developing/graph-ts/api.mdx
+++ b/website/pages/vi/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Given an IPFS hash or path, reading a file from IPFS is done as follows:
 

From 36d139216099c0678f81cf7a9a830f526e954c1b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:05 -0500
Subject: [PATCH 0508/3820] New translations subgraphs.mdx (Vietnamese)

---
 website/pages/vi/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/subgraphs.mdx b/website/pages/vi/subgraphs.mdx
index 42c1e806f822..1fdd0baf80eb 100644
--- a/website/pages/vi/subgraphs.mdx
+++ b/website/pages/vi/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 4097f9a6a9dda68aa35243657d36dfeeae507ca7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:06 -0500
Subject: [PATCH 0509/3820] New translations transfer-to-the-graph.mdx
 (Vietnamese)

---
 website/pages/vi/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/cookbook/transfer-to-the-graph.mdx b/website/pages/vi/cookbook/transfer-to-the-graph.mdx
index cfd461e80d4d..eeaf1ae279e6 100644
--- a/website/pages/vi/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/vi/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 12bf4a140399a5bb4f9810998882572cdf3d4d9c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:08 -0500
Subject: [PATCH 0510/3820] New translations subgraph-manifest.mdx (Vietnamese)

---
 .../vi/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/vi/developing/creating-a-subgraph/subgraph-manifest.mdx
index 1843837e0506..08d322c4f129 100644
--- a/website/pages/vi/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/vi/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Nguồn Dữ liệu cho Hợp đồng Chính
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 3f0596970c0e1c2b3f3c29635c754be0fd71a77d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:09 -0500
Subject: [PATCH 0511/3820] New translations near.mdx (Marathi)

---
 website/pages/mr/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/cookbook/near.mdx b/website/pages/mr/cookbook/near.mdx
index efd00f148a8f..8a16179f5009 100644
--- a/website/pages/mr/cookbook/near.mdx
+++ b/website/pages/mr/cookbook/near.mdx
@@ -12,7 +12,7 @@ This guide is an introduction to building subgraphs indexing smart contracts on
 
 ग्राफ डेव्हलपरला ब्लॉकचेन इव्हेंट्सवर प्रक्रिया करण्यासाठी आणि परिणामी डेटा ग्राफक्यूएल API द्वारे सहज उपलब्ध करण्यासाठी साधने देतो, जो वैयक्तिकरित्या सबग्राफ म्हणून ओळखला जातो. [ग्राफ नोड](https://github.com/graphprotocol/graph-node) आता जवळच्या इव्हेंटवर प्रक्रिया करण्यास सक्षम आहे, याचा अर्थ असा की NEAR डेव्हलपर आता त्यांचे स्मार्ट करार अनुक्रमित करण्यासाठी सबग्राफ तयार करू शकतात.
 
-सबग्राफ इव्हेंट-आधारित असतात, याचा अर्थ ते ऐकतात आणि नंतर ऑन-चेन इव्हेंटवर प्रक्रिया करतात. सध्या जवळच्या सबग्राफसाठी दोन प्रकारचे हँडलर समर्थित आहेत:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - ब्लॉक हँडलर: हे प्रत्येक नवीन ब्लॉकवर चालवले जातात
 - पावती हँडलर्स: निर्दिष्ट खात्यावर संदेश कार्यान्वित झाल्यावर प्रत्येक वेळी चालवा

From fdc60ce20279f4220203362840faa6f8a5f728cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:10 -0500
Subject: [PATCH 0512/3820] New translations api.mdx (Marathi)

---
 website/pages/mr/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/mr/developing/graph-ts/api.mdx b/website/pages/mr/developing/graph-ts/api.mdx
index 5fd1e1635c4e..a57a678a1242 100644
--- a/website/pages/mr/developing/graph-ts/api.mdx
+++ b/website/pages/mr/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 '@graphprotocol/graph-ts' वरून { ipfs } आयात करा
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 आयपीएफएस हॅश किंवा पथ दिल्यास, आयपीएफएस मधून फाइल वाचणे खालीलप्रमाणे केले जाते:
 

From 0c243883b3039436a86712989a8437fc2342aeb1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:11 -0500
Subject: [PATCH 0513/3820] New translations subgraphs.mdx (Marathi)

---
 website/pages/mr/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/subgraphs.mdx b/website/pages/mr/subgraphs.mdx
index 1738964b82d2..8c3596567c08 100644
--- a/website/pages/mr/subgraphs.mdx
+++ b/website/pages/mr/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From cdc0b6fd06e102c0ed390350d8cdb5b036ee9a97 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:12 -0500
Subject: [PATCH 0514/3820] New translations transfer-to-the-graph.mdx
 (Marathi)

---
 website/pages/mr/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/cookbook/transfer-to-the-graph.mdx b/website/pages/mr/cookbook/transfer-to-the-graph.mdx
index 9398cd9703a2..415127eaf64e 100644
--- a/website/pages/mr/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/mr/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From b20920410fc3cc186d8ee08858bea5ed0842c621 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:13 -0500
Subject: [PATCH 0515/3820] New translations subgraph-manifest.mdx (Marathi)

---
 .../mr/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/mr/developing/creating-a-subgraph/subgraph-manifest.mdx
index fad2db52e58e..88a6d69c0894 100644
--- a/website/pages/mr/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/mr/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### मुख्य करारासाठी डेटा स्रोत
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 7e3179e4d1d103794b84ab4eebaa88263d860a70 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:15 -0500
Subject: [PATCH 0516/3820] New translations near.mdx (Hindi)

---
 website/pages/hi/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/cookbook/near.mdx b/website/pages/hi/cookbook/near.mdx
index 6ffcaca61696..ec16d45c5ccc 100644
--- a/website/pages/hi/cookbook/near.mdx
+++ b/website/pages/hi/cookbook/near.mdx
@@ -12,7 +12,7 @@ title: NEAR पर सबग्राफ बनाना
 
 ग्राफ़ ब्लॉकचैन घटनाओं को प्रोसेस करने के लिए डेवलपर्स टूल देता है और परिणामी डेटा को एक ग्राफक्यूएल एपीआई के माध्यम से आसानी से उपलब्ध कराता है, जिसे व्यक्तिगत रूप से सबग्राफ के रूप में जाना जाता है। [ग्राफ़ नोड](https://github.com/graphprotocol/graph-node) अब NEAR इवेंट को प्रोसेस करने में सक्षम है, जिसका मतलब है कि NEAR डेवलपर अब अपने स्मार्ट कॉन्ट्रैक्ट को इंडेक्स करने के लिए सबग्राफ बना सकते हैं।
 
-सबग्राफ घटना-आधारित होते हैं, जिसका अर्थ है कि वे ऑन-चेन घटनाओं को सुनते हैं और फिर उन्हें प्रोसेस करते हैं। वर्तमान में NEAR सबग्राफ के लिए समर्थित दो प्रकार के हैंडलर हैं:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - ब्लॉक हैंडलर्स: ये हर नए ब्लॉक पर चलते हैं
 - रसीद हैंडलर: किसी निर्दिष्ट खाते पर संदेश निष्पादित होने पर हर बार चलें

From e9e3a7029da62d4f22900a27715a3553c7d152e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:16 -0500
Subject: [PATCH 0517/3820] New translations subgraphs.mdx (Hindi)

---
 website/pages/hi/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs.mdx b/website/pages/hi/subgraphs.mdx
index 4599a8cc79d9..e5037e33f7fe 100644
--- a/website/pages/hi/subgraphs.mdx
+++ b/website/pages/hi/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From ee47104c1e9a85f126d7bd2386ed8d2e083adc6f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:17 -0500
Subject: [PATCH 0518/3820] New translations subgraph-manifest.mdx (Hindi)

---
 .../hi/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/hi/developing/creating-a-subgraph/subgraph-manifest.mdx
index 7a554404dd2c..430236013eaf 100644
--- a/website/pages/hi/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/hi/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### मुख्य अनुबंध के लिए डेटा स्रोत
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From bcc96ab1b8bfe26e4213431369528946ae84a43a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:18 -0500
Subject: [PATCH 0519/3820] New translations near.mdx (Swahili)

---
 website/pages/sw/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/cookbook/near.mdx b/website/pages/sw/cookbook/near.mdx
index f2509e44e84c..d382e179b948 100644
--- a/website/pages/sw/cookbook/near.mdx
+++ b/website/pages/sw/cookbook/near.mdx
@@ -12,7 +12,7 @@ This guide is an introduction to building subgraphs indexing smart contracts on
 
 The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
 
-Subgraphs are event-based, which means that they listen for and then process on-chain events. There are currently two types of handlers supported for NEAR subgraphs:
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
 - Block handlers: these are run on every new block
 - Receipt handlers: run every time a message is executed at a specified account

From e80a1c0457831c7cf742efda3adb50db0c856db4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:19 -0500
Subject: [PATCH 0520/3820] New translations api.mdx (Swahili)

---
 website/pages/sw/developing/graph-ts/api.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sw/developing/graph-ts/api.mdx b/website/pages/sw/developing/graph-ts/api.mdx
index 8fc1f4b48b61..34aca9ef10ee 100644
--- a/website/pages/sw/developing/graph-ts/api.mdx
+++ b/website/pages/sw/developing/graph-ts/api.mdx
@@ -280,7 +280,7 @@ As the entity may not exist in the store yet, the `load` method returns a value
 
 As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some on-chain event, and a later handler wants to access this transaction if it exists.
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
 
 - In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
 - For some subgraphs, these missed lookups can contribute significantly to the indexing time.
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files on chain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
 
 Given an IPFS hash or path, reading a file from IPFS is done as follows:
 

From 58558ad9f106880c86a7fc94afef420c85b4eb2d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:20 -0500
Subject: [PATCH 0521/3820] New translations subgraphs.mdx (Swahili)

---
 website/pages/sw/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/subgraphs.mdx b/website/pages/sw/subgraphs.mdx
index 42c1e806f822..1fdd0baf80eb 100644
--- a/website/pages/sw/subgraphs.mdx
+++ b/website/pages/sw/subgraphs.mdx
@@ -55,7 +55,7 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 
 When you're happy with your subgraph, you can [publish it](/publishing/publishing-a-subgraph/) to The Graph Network.
 
-- This is an on-chain action, which registers the subgraph and makes it discoverable by Indexers.
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
 - Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/managing/transfer-a-subgraph/) by sending the NFT.
 - Published subgraphs have associated metadata, which provides other network participants with useful context and information.
 

From 0efa58dc356dde5afe4e78d77c79775264bfc000 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:22 -0500
Subject: [PATCH 0522/3820] New translations transfer-to-the-graph.mdx
 (Swahili)

---
 website/pages/sw/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/cookbook/transfer-to-the-graph.mdx b/website/pages/sw/cookbook/transfer-to-the-graph.mdx
index 6a5d2c2793f3..e3acb966c427 100644
--- a/website/pages/sw/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/sw/cookbook/transfer-to-the-graph.mdx
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
 - Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires on-chain action each time, so name it properly.
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
 ### Install the Graph CLI⁠
 

From 1e7b4dc7f801e6cd4bfeeeda7e3c76f34c9ce1c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:23 -0500
Subject: [PATCH 0523/3820] New translations subgraph-manifest.mdx (Swahili)

---
 .../sw/developing/creating-a-subgraph/subgraph-manifest.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/developing/creating-a-subgraph/subgraph-manifest.mdx b/website/pages/sw/developing/creating-a-subgraph/subgraph-manifest.mdx
index f282f3946e75..4af0a0adbf2d 100644
--- a/website/pages/sw/developing/creating-a-subgraph/subgraph-manifest.mdx
+++ b/website/pages/sw/developing/creating-a-subgraph/subgraph-manifest.mdx
@@ -348,7 +348,7 @@ The addresses of these sub-contracts may or may not be known upfront and many of
 
 ### Data Source for the Main Contract
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created on-chain by the factory contract.
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
 
 ```yaml
 dataSources:

From 50625898c5ced89835703a818ae048db71c29c7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:24 -0500
Subject: [PATCH 0524/3820] New translations deploy-using-subgraph-studio.mdx
 (Hindi)

---
 website/pages/hi/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/deploying/deploy-using-subgraph-studio.mdx b/website/pages/hi/deploying/deploy-using-subgraph-studio.mdx
index 3f07a9b3b2e4..10e98f4cb338 100644
--- a/website/pages/hi/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/hi/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Subgraph Studio का उपयोग करके डिप्लॉय
 
 अपने subgraph को Subgraph Studio में डिप्लॉय करना सीखें।
 
-> नोट: जब आप एक subgraph को डिप्लॉय करते हैं, तो आप इसे Subgraph Studio पर पुश करते हैं, जहाँ आप इसे टेस्ट कर सकेंगे। यह याद रखना महत्वपूर्ण है कि डिप्लॉय करना प्रकाशित करने के समान नहीं है। जब आप एक subgraph को प्रकाशित करते हैं, तो आप इसे ऑन-चेन प्रकाशित कर रहे हैं।
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio का अवलोकन
 
@@ -124,7 +124,7 @@ Subgraph Studio का उपयोग करके डैशबोर्ड प
 - एक बार जब आप इससे संतुष्ट हो जाएं, तो आप अपने नए डिप्लॉयमेंट को Graph Explorer(https://thegraph.com/explorer). पर प्रकाशित कर सकते हैं।
 - यह क्रिया आपके नए संस्करण का निर्माण करेगी जिसे Curators सिग्नल करना शुरू कर सकते हैं और Indexers अनुक्रमित कर सकते हैं।
 
-आप अपने subgraph के मेटाडेटा को बिना नई संस्करण प्रकाशित किए भी अपडेट कर सकते हैं। आप Studio में अपने subgraph विवरण (प्रोफ़ाइल चित्र, नाम, विवरण, आदि के अंतर्गत) को [Graph Explorer](https://thegraph.com/explorer). में Update Details नामक विकल्प को चेक करके अपडेट कर सकते हैं। यदि यह चेक किया गया है, तो एक ऑन-चेन लेनदेन उत्पन्न होगा जो Explorer में subgraph विवरण को अपडेट करेगा, बिना नई तैनाती के साथ नया संस्करण प्रकाशित किए।
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: नेटवर्क पर नए संस्करण को प्रकाशित करने से संबंधित लागतें हैं। लेनदेन शुल्क के अलावा, आपको ऑटो-माइग्रेटिंग सिग्नल पर क्यूरेशन टैक्स का एक भाग भी फंड करना होगा। यदि क्यूरेटरों ने इस पर सिग्नल नहीं किया है, तो आप अपने सबग्राफ का नया संस्करण प्रकाशित नहीं कर सकते। अधिक जानकारी के लिए, कृपया और पढ़ें यहाँ(/network/curating/).
 

From f17d30d51e5c1d08fe7839c11e1ad7e5c64957b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:25 -0500
Subject: [PATCH 0525/3820] New translations cosmos.mdx (French)

---
 website/pages/fr/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/cookbook/cosmos.mdx b/website/pages/fr/cookbook/cosmos.mdx
index d21938a729dd..afe2a458324a 100644
--- a/website/pages/fr/cookbook/cosmos.mdx
+++ b/website/pages/fr/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## Que sont les subgraphs de Cosmos ?
 
-The Graph permet aux développeurs de traiter les événements de la blockchain et de rendre les données résultantes facilement disponibles via une API GraphQL publique, connue sous le nom de subgraph. Par exemple : [Graph Node](https://github.com/graphprotocol/graph-node) est désormais capable de traiter les événements Cosmos, ce qui signifie que les développeurs peuvent désormais construire des subgraphs pour indexer facilement les événements sur cette chaîne.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 Il existe quatre types de gestionnaires pris en charge dans les subgraphs de Cosmos :
 

From 60758708e654378f654fa2885ef7b7c1ed33adeb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:26 -0500
Subject: [PATCH 0526/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Turkish)

---
 .../pages/tr/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/tr/developing/substreams-powered-subgraphs-faq.mdx
index 008fc7ecef4a..df5b9e36a62c 100644
--- a/website/pages/tr/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/tr/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ Eğer subgraph geliştirme konusun aşina iseniz, aklınızda bulundurun ki, Sub
 
 ## Substreams destekli subgraphlar'ın normal subgraphlar'dan farkı nedir?
 
-Subgraphlar, zincir üstü olayları ve bu olayların nasıl AssemblyScript işleyicileri aracılığıyla dönüştürüleceğini belirleyen veri kaynaklarından oluşur. Bu olaylar, olayların zincir üstünde meydana geldikleri sıraya göre işlenir.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-Buna karşılık, Substreams destekli subgraphlar, Substreams paketini referans alan tek bir veri kaynağına sahiptir ve bu veri kaynağı Graph Düğümü tarafından işlenir. Substreams, geleneksel subgraphlara kıyasla daha detaylı zincir üstü verilere erişebilir ve ayrıca büyük ölçekli paralel işlemden yararlanarak çok daha hızlı işleme süreleri elde edebilir.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## Substreams destekli subgraphlar kullanmanın avantajları nelerdir?
 

From b7a4684dcd1608829bc2480cd172e0731cf20295 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:27 -0500
Subject: [PATCH 0527/3820] New translations cosmos.mdx (Hindi)

---
 website/pages/hi/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/cookbook/cosmos.mdx b/website/pages/hi/cookbook/cosmos.mdx
index b64bc7c1cd7b..cb9090d73f17 100644
--- a/website/pages/hi/cookbook/cosmos.mdx
+++ b/website/pages/hi/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## कॉसमॉस सब-ग्राफ्स क्या होते हैं?
 
-द ग्राफ की मदद से डेवेलपर्स ब्लॉकचेन की गतिविधियों को प्रोसेस कर सकते हैं और उससे आने वाले डाटा को आसानी से GraphQL एपीआई की मदद से उपलब्ध करवा सकते हैं जिन्हे, सब-ग्राफ कहा जाता है| [ग्राफ नोड](https://github.com/graphprotocol/graph-node) अब कॉसमॉस की गतिविधियों को प्रोसेस करने में सक्षम है जिसका मतलब यह है की अब डेवेलपर्स चेन पर होने वाली गतिविधियों पर नज़र रखने के लिए आसानी से सब-ग्राफ्स बना सकते हैं|
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 कॉसमॉस सब-ग्राफ्स में कुल चार प्रकार के हैंडलर्स सहयोगी हैं:
 

From 9d3206bf85426c4d77c400a1e5159b65ea7701e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:28 -0500
Subject: [PATCH 0528/3820] New translations
 immutable-entities-bytes-as-ids.mdx (French)

---
 website/pages/fr/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/fr/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/fr/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/fr/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From 850db0ee7432975dea7bf2c487c083e787a1ea50 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:29 -0500
Subject: [PATCH 0529/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Romanian)

---
 website/pages/ro/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ro/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/ro/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/ro/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From 1a921fe79679ceef7a12d4daf6d69e5028159f3d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:30 -0500
Subject: [PATCH 0530/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Spanish)

---
 website/pages/es/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/es/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/es/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/es/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From 69a45f58306dda8b96659e94f30fe140efbe36ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:31 -0500
Subject: [PATCH 0531/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Arabic)

---
 website/pages/ar/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ar/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/ar/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/ar/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From c840376e9fb27a1be8be71739dbaa87a1c3078a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:32 -0500
Subject: [PATCH 0532/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Czech)

---
 website/pages/cs/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/cs/cookbook/immutable-entities-bytes-as-ids.mdx
index 620906f8cf65..a37fde8f4d54 100644
--- a/website/pages/cs/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/cs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 Tím, že je entita `Transfer` neměnná, je grafový uzel schopen ji zpracovávat efektivněji, což zvyšuje rychlost indexování a odezvu dotazů.
 
-Struktury neměnných entit se v budoucnu nezmění. Ideální entitou, která by se měla stát nezměnitelnou entitou, by byla entita, která přímo zaznamenává data událostí v řetězci, například událost `Převod` by byla zaznamenána jako entita `Převod`.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Pod kapotou
 

From 4f5b8a1148226e213d0038f5ebe321af22e08290 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:33 -0500
Subject: [PATCH 0533/3820] New translations
 immutable-entities-bytes-as-ids.mdx (German)

---
 website/pages/de/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/de/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/de/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/de/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From bead90d5fe33104377c967617053deeff58c382b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:34 -0500
Subject: [PATCH 0534/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Italian)

---
 website/pages/it/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/it/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/it/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/it/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From e657549625110abadb1ab69426055dbf3e1c2fb8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:35 -0500
Subject: [PATCH 0535/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Japanese)

---
 website/pages/ja/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ja/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/ja/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/ja/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From 1ba18ebf41e6a26b7d6a74a19473acf943d6098a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:36 -0500
Subject: [PATCH 0536/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Korean)

---
 website/pages/ko/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ko/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/ko/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/ko/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From 900e0e33944794612672f452c8a06443600c17f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:37 -0500
Subject: [PATCH 0537/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Dutch)

---
 website/pages/nl/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/nl/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/nl/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/nl/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From 6a6976dc2a96af0f0a9241da58fadf02c9bc4c7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:38 -0500
Subject: [PATCH 0538/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Polish)

---
 website/pages/pl/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/pl/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/pl/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/pl/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From 738e405750121c83fc74b43183f2187f49fd956e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:39 -0500
Subject: [PATCH 0539/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Portuguese)

---
 website/pages/pt/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/pt/cookbook/immutable-entities-bytes-as-ids.mdx
index b00bf3708ef3..cdbf1ade9221 100644
--- a/website/pages/pt/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/pt/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 Ao tornar a entidade `Transfer` imutável, o graph-node pode processá-la com mais eficácia, o que melhora as velocidades de indexação e a capacidade de resposta das queries.
 
-Estruturas de Entidades Imutáveis não mudarão no futuro. Uma entidade ideal para se tornar Imutável seria uma que grava diretamente dados de eventos on-chain; por exemplo, um evento `Transfer` gravado como uma entidade `Transfer`.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### De dentro da casca
 

From a36182d234a28f47c52603ac33cf77cc9748e2ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:40 -0500
Subject: [PATCH 0540/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Russian)

---
 website/pages/ru/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ru/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/ru/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/ru/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From bc683234d516a47e7729a3afca508f845e2ba986 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:41 -0500
Subject: [PATCH 0541/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Swedish)

---
 website/pages/sv/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/sv/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/sv/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/sv/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From c6e6262c5fdd095098a89e95bfec06a8a2411256 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:42 -0500
Subject: [PATCH 0542/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Turkish)

---
 website/pages/tr/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/tr/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/tr/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/tr/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From bdae321b618795ef35d7a12e01f78f4ded2c905c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:43 -0500
Subject: [PATCH 0543/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Ukrainian)

---
 website/pages/uk/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/uk/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/uk/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/uk/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From 894ad7380874ae3c3c2a68068e2d4f4c550ead6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:44 -0500
Subject: [PATCH 0544/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Chinese Simplified)

---
 website/pages/zh/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/zh/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/zh/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/zh/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From e4e436e5c00eb324ba87c2de29cc6def48422a07 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:45 -0500
Subject: [PATCH 0545/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Urdu (Pakistan))

---
 website/pages/ur/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ur/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/ur/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/ur/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From 04455bc6b4709d4150cab610484b83a388855f40 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:46 -0500
Subject: [PATCH 0546/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Vietnamese)

---
 website/pages/vi/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/vi/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/vi/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/vi/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From 99ee37e0502bc1ff72519d79ff6a9e5979fc8415 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:47 -0500
Subject: [PATCH 0547/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Marathi)

---
 website/pages/mr/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/mr/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/mr/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/mr/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From feef32dae6aa6a2c014738e0efbe5a8e5cdabeef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:48 -0500
Subject: [PATCH 0548/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Hindi)

---
 website/pages/hi/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/hi/cookbook/immutable-entities-bytes-as-ids.mdx
index 4875006914e4..c27feff7f9fc 100644
--- a/website/pages/hi/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/hi/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 Transfer एंटिटी को अमूर्त बनाने से, graph-node एंटिटी को अधिक कुशलता से संसाधित कर सकता है, जिससे indexing गति और क्वेरी की प्रतिक्रिया में सुधार होता है।
 
-Immutable Entities संरचनाएँ भविष्य में नहीं बदलेंगी। एक आदर्श एंटिटी जो अमूर्त एंटिटी बनेगी, वह एंटिटी होगी जो सीधे ऑन-चेन इवेंट डेटा को लॉग कर रही है, जैसे कि Transfer इवेंट को Transfer एंटिटी के रूप में लॉग किया जाना।
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### हुड के नीचे
 

From 18286cf05ea7cc4273a6eae8c011cb42c14c718b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:49 -0500
Subject: [PATCH 0549/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Swahili)

---
 website/pages/sw/cookbook/immutable-entities-bytes-as-ids.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/sw/cookbook/immutable-entities-bytes-as-ids.mdx
index 541212617f9f..c605e3eeb165 100644
--- a/website/pages/sw/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/sw/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging on-chain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
 ### Under the hood
 

From 675aaa752f12c438f15966df84f05702daed8956 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:50 -0500
Subject: [PATCH 0550/3820] New translations cosmos.mdx (Russian)

---
 website/pages/ru/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/cookbook/cosmos.mdx b/website/pages/ru/cookbook/cosmos.mdx
index f47e04b61d35..744ab9fe07e5 100644
--- a/website/pages/ru/cookbook/cosmos.mdx
+++ b/website/pages/ru/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ title: Создание субграфов на Cosmos
 
 ## Что такое субграфы на Cosmos?
 
-The Graph позволяет разработчикам обрабатывать события блокчейна и делать полученные данные легко доступными через открытый API GraphQL, известный как субграф. [Graph Node](https://github.com/graphprotocol/graph-node) теперь может обрабатывать события Cosmos, а это означает, что разработчики Cosmos теперь могут создавать субграфы для удобного индексирования событий в сети.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 Существует четыре типа обработчиков, поддерживаемых в субграфах Cosmos:
 

From 8589d32f1b37d8f42e1887fcf25b10f0ab64d2e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:51 -0500
Subject: [PATCH 0551/3820] New translations cosmos.mdx (Romanian)

---
 website/pages/ro/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/cookbook/cosmos.mdx b/website/pages/ro/cookbook/cosmos.mdx
index cd23a3742f86..dfdb377688aa 100644
--- a/website/pages/ro/cookbook/cosmos.mdx
+++ b/website/pages/ro/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## What are Cosmos subgraphs?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index on-chain events.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 There are four types of handlers supported in Cosmos subgraphs:
 

From d02c702b45cab8c3dacba9121d991f6f4ab37dfb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:52 -0500
Subject: [PATCH 0552/3820] New translations cosmos.mdx (Spanish)

---
 website/pages/es/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/cookbook/cosmos.mdx b/website/pages/es/cookbook/cosmos.mdx
index 67d7021cf6d0..5de0755de801 100644
--- a/website/pages/es/cookbook/cosmos.mdx
+++ b/website/pages/es/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## ¿Qué son los subgrafos de Cosmos?
 
-The Graph permite a los developers procesar eventos de blockchain y hacer que los datos resultantes estén fácilmente disponibles a través de una API GraphQL abierta, conocida como subgrafo. [Graph Node](https://github.com/graphprotocol/graph-node) ahora puede procesar eventos de Cosmos, lo que significa que los developers de Cosmos ahora pueden crear subgrafos para indexar fácilmente eventos on-chain.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 Hay cuatro tipos de handlers admitidos en los subgrafos de Cosmos:
 

From 5f747a64bf13df0f77f88b61aa298b00aadc86a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:53 -0500
Subject: [PATCH 0553/3820] New translations cosmos.mdx (Arabic)

---
 website/pages/ar/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/cookbook/cosmos.mdx b/website/pages/ar/cookbook/cosmos.mdx
index 15fbf0537bca..e7b7870f7a88 100644
--- a/website/pages/ar/cookbook/cosmos.mdx
+++ b/website/pages/ar/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## What are Cosmos subgraphs?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index on-chain events.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 There are four types of handlers supported in Cosmos subgraphs:
 

From 5163bc837fffa44fa46bb01e6b2f97ee0cc783e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:55 -0500
Subject: [PATCH 0554/3820] New translations cosmos.mdx (Czech)

---
 website/pages/cs/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/cookbook/cosmos.mdx b/website/pages/cs/cookbook/cosmos.mdx
index b604b8dabda0..8a6301cf7963 100644
--- a/website/pages/cs/cookbook/cosmos.mdx
+++ b/website/pages/cs/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ Tato příručka je úvodem k vytváření podgrafů indexujících [Blokové ř
 
 ## Co jsou podgrafy Cosmos?
 
-Graph umožňuje vývojářům zpracovávat blockchainové události a výsledná data snadno zpřístupňovat prostřednictvím otevřeného rozhraní GraphQL API, známého jako podgraf. [Graph Node](https://github.com/graphprotocol/graph-node) je nyní schopen zpracovávat události Cosmos, což znamená, že vývojáři Cosmos nyní mohou vytvářet podgrafy pro snadné indexování událostí v řetězci.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 V podgrafech Cosmos jsou podporovány čtyři typy ovladačů:
 

From 35df2fd1223e8841f81eee595d5fdd8008adcf17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:56 -0500
Subject: [PATCH 0555/3820] New translations cosmos.mdx (German)

---
 website/pages/de/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/cookbook/cosmos.mdx b/website/pages/de/cookbook/cosmos.mdx
index c37bc95e625e..7fcf6f6d68c7 100644
--- a/website/pages/de/cookbook/cosmos.mdx
+++ b/website/pages/de/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## Was sind Cosmos-Subgrafen?
 
-The Graph ermöglicht es Entwicklern, Blockchain-Ereignisse zu verarbeiten und die resultierenden Daten durch eine offene GraphQL-API, die als Subgraf bezeichnet wird, einfach verfügbar zu machen. [Graph Node](https://github.com/graphprotocol/graph-node) ist jetzt in der Lage, Cosmos-Ereignisse zu verarbeiten, was bedeutet, dass Cosmos-Entwickler jetzt Subgrafen erstellen können, um On-Chain-Ereignisse einfach zu indizieren.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 In Cosmos-Subgrafen werden vier Arten von Handlern unterstützt:
 

From e4e99d64030ed56a041a0861921f20f2e274d85a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:57 -0500
Subject: [PATCH 0556/3820] New translations cosmos.mdx (Italian)

---
 website/pages/it/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/cookbook/cosmos.mdx b/website/pages/it/cookbook/cosmos.mdx
index cd23a3742f86..dfdb377688aa 100644
--- a/website/pages/it/cookbook/cosmos.mdx
+++ b/website/pages/it/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## What are Cosmos subgraphs?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index on-chain events.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 There are four types of handlers supported in Cosmos subgraphs:
 

From b03e8ab63bb104c041b206c2f43aa333bc53fe1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:58 -0500
Subject: [PATCH 0557/3820] New translations cosmos.mdx (Japanese)

---
 website/pages/ja/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/cookbook/cosmos.mdx b/website/pages/ja/cookbook/cosmos.mdx
index 4ff9a970011d..f2b39ee11212 100644
--- a/website/pages/ja/cookbook/cosmos.mdx
+++ b/website/pages/ja/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## Cosmosのサブグラフとは何ですか？
 
-Graph は、ブロックチェーンのイベントを処理し、その結果得られたデータを GraphQL API を介して簡単に利用できるようにするためのツールを開発者に提供するもので、個別にはサブグラフとして知られています。[Graph Node](https://github.com/graphprotocol/graph-node)が Cosmosイベントを処理できるようになったということは、Cosmosの開発者がスマートコントラクトの指標となるサブグラフを構築できるようになったということです。
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 Cosmosのサブグラフでサポートされているハンドラーは4種類あります。
 

From 64f22f469421d19fe21020b97bb45325a1cb16b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:23:59 -0500
Subject: [PATCH 0558/3820] New translations cosmos.mdx (Korean)

---
 website/pages/ko/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/cookbook/cosmos.mdx b/website/pages/ko/cookbook/cosmos.mdx
index cd23a3742f86..dfdb377688aa 100644
--- a/website/pages/ko/cookbook/cosmos.mdx
+++ b/website/pages/ko/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## What are Cosmos subgraphs?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index on-chain events.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 There are four types of handlers supported in Cosmos subgraphs:
 

From 5eca8eef1182299ee8ab45e28a95b9c459183c9b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:00 -0500
Subject: [PATCH 0559/3820] New translations cosmos.mdx (Dutch)

---
 website/pages/nl/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/cookbook/cosmos.mdx b/website/pages/nl/cookbook/cosmos.mdx
index cd23a3742f86..dfdb377688aa 100644
--- a/website/pages/nl/cookbook/cosmos.mdx
+++ b/website/pages/nl/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## What are Cosmos subgraphs?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index on-chain events.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 There are four types of handlers supported in Cosmos subgraphs:
 

From f7ca9e1e7c4fe9d22ff6a02724232c262aa70377 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:01 -0500
Subject: [PATCH 0560/3820] New translations cosmos.mdx (Polish)

---
 website/pages/pl/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/cookbook/cosmos.mdx b/website/pages/pl/cookbook/cosmos.mdx
index cd23a3742f86..dfdb377688aa 100644
--- a/website/pages/pl/cookbook/cosmos.mdx
+++ b/website/pages/pl/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## What are Cosmos subgraphs?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index on-chain events.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 There are four types of handlers supported in Cosmos subgraphs:
 

From f752541cc0f9cb11e4bdb4accff89ca4cd7fbc17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:02 -0500
Subject: [PATCH 0561/3820] New translations cosmos.mdx (Portuguese)

---
 website/pages/pt/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/cookbook/cosmos.mdx b/website/pages/pt/cookbook/cosmos.mdx
index d98ffafe1a01..ea5005174e80 100644
--- a/website/pages/pt/cookbook/cosmos.mdx
+++ b/website/pages/pt/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ Este guia é uma introdução à construção de subgraphs através da indexaç
 
 ## O que são subgraphs no Cosmos?
 
-The Graph permite que os programadores processem eventos em blockchain e façam dos dados resultantes facilmente disponíveis através de uma API aberta do GraphQL, conhecida como um subgraph. O [Graph Node](https://github.com/graphprotocol/graph-node) agora pode processar eventos no Cosmos, o que significa que programadores no Cosmos agora podem construir subgraphs para indexar com facilidade eventos on-chain.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 Existem quatro categorias de handlers apoiados em subgraphs no Cosmos:
 

From 58bfe370bef7b02a52f696b061d04b2ab2cfc102 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:03 -0500
Subject: [PATCH 0562/3820] New translations cosmos.mdx (Swedish)

---
 website/pages/sv/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/cookbook/cosmos.mdx b/website/pages/sv/cookbook/cosmos.mdx
index f1ae3d262aa3..d00c700235b3 100644
--- a/website/pages/sv/cookbook/cosmos.mdx
+++ b/website/pages/sv/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## Vad är Cosmos subgrafer?
 
-Graph tillåter utvecklare att bearbeta blockchain-händelser och göra den resulterande informationen lätt tillgänglig via en öppen GraphQL API, känd som en subgraf. [Graph Node](https://github.com/graphprotocol/graph-node) kan nu bearbeta Cosmos-händelser, vilket innebär att Cosmos-utvecklare nu kan bygga subgrafer för att enkelt indexera händelser i kedjan.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 Det finns fyra typer av hanterare som stöds i Cosmos subgrafer:
 

From 1436baadbe45a2d28f736eca2c7a4a1f90e433d2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:04 -0500
Subject: [PATCH 0563/3820] New translations cosmos.mdx (Turkish)

---
 website/pages/tr/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/cookbook/cosmos.mdx b/website/pages/tr/cookbook/cosmos.mdx
index e1064c19faf7..6d3ac47610c6 100644
--- a/website/pages/tr/cookbook/cosmos.mdx
+++ b/website/pages/tr/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## Cosmos subgraph'leri nelerdir?
 
-Graph, geliştiricilerin blockchain etkinliklerini işlemesine ve ortaya çıkan verileri subgraph olarak bilinen açık bir GraphQL API aracılığıyla kolayca kullanılabilir hale getirmesine olanak tanır. [Graph Düğümü](https://github.com/graphprotocol/graph-node) artık Cosmos etkinliklerini işleyebilir, bu da Cosmos geliştiricilerinin artık zincir üstü olayları kolayca dizine eklemek için subgraph'ler oluşturabileceği anlamına gelir.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 Cosmos subgraph'lerinde desteklenen dört tür işleyici vardır:
 

From 474bdec537a2694197fd41c197ed5a71d8a09b94 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:06 -0500
Subject: [PATCH 0564/3820] New translations cosmos.mdx (Ukrainian)

---
 website/pages/uk/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/cookbook/cosmos.mdx b/website/pages/uk/cookbook/cosmos.mdx
index 979de8d0a4cc..524eff5a3a66 100644
--- a/website/pages/uk/cookbook/cosmos.mdx
+++ b/website/pages/uk/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## Що таке Cosmos підграфи?
 
-The Graph дозволяє розробникам проводити обробку подій блокчейну і робити отримані дані легко доступними за допомогою відкритого API GraphQL, відомого як підграф. [Graph Node](https://github.com/graphprotocol/graph-node) тепер може обробляти події на Cosmos, що означає, що розробники Cosmos тепер можуть створювати підграфи для легкого індексування подій у блокчейні.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 У підграфах на Cosmos підтримується чотири типи обробників:
 

From 830c526584e14404fdf208af86f665adb9869972 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:07 -0500
Subject: [PATCH 0565/3820] New translations cosmos.mdx (Chinese Simplified)

---
 website/pages/zh/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/cookbook/cosmos.mdx b/website/pages/zh/cookbook/cosmos.mdx
index c5ea0c2b44e6..2607ef891467 100644
--- a/website/pages/zh/cookbook/cosmos.mdx
+++ b/website/pages/zh/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## Cosmos 子图是什么？
 
-Graph 为开发人员提供了一种被称为子图的工具，利用这个工具，开发人员能够处理区块链事件，并通过 GraphQL API 提供结果数据。 [Graph 节点](https://github.com/graphprotocol/graph-node)现在能够处理 Cosmos 事件，这意味着 Cosmos 开发人员现在可以构建子图来索引链上事件。
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 Cosmos 子图目前支持四种类型的处理程序：
 

From ac9e4284ff8f613039a137bb512127ee25bcf6a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:08 -0500
Subject: [PATCH 0566/3820] New translations cosmos.mdx (Urdu (Pakistan))

---
 website/pages/ur/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/cookbook/cosmos.mdx b/website/pages/ur/cookbook/cosmos.mdx
index 19ef50e2ca0d..9b9e8a7f51a3 100644
--- a/website/pages/ur/cookbook/cosmos.mdx
+++ b/website/pages/ur/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## کوزموس کے سب گراف کیا ہیں ؟
 
-گراف ڈویلپرز کو بلاکچین ایونٹس پر کارروائی کرنے اور نتیجے میں آنے والے ڈیٹا کو ای کھلے GraphQL API کے ذریعے آسانی سے دستیاب کرنے کی اجازت دیتا ہے، جسے سب گراف کہا جاتا ہے۔ [گراف نوڈ](https://github.com/graphprotocol/graph-node) اب کوزموس ایونٹس پر کارروائی کرنے کے قابل ہے، جس کا مطلب ہے کہ کوزموس ڈویلپرز اب آسانی سے آن چین ایونٹس کو انڈیکس کرنے کے لیے سب گراف بنا سکتے ہیں.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 کوزموس سب گراف میں چار قسم کے ہینڈلرز کی حمایت کی جاتی ہے:
 

From dd1e2ddc6ba41289412653b1a63972b86c559ba5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:09 -0500
Subject: [PATCH 0567/3820] New translations cosmos.mdx (Vietnamese)

---
 website/pages/vi/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/cookbook/cosmos.mdx b/website/pages/vi/cookbook/cosmos.mdx
index 38b983935e9a..cea948c1d7a4 100644
--- a/website/pages/vi/cookbook/cosmos.mdx
+++ b/website/pages/vi/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## What are Cosmos subgraphs?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index on-chain events.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 There are four types of handlers supported in Cosmos subgraphs:
 

From 3331f1f8fffe0540dbbd4c799041edcfe5bccfc1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:10 -0500
Subject: [PATCH 0568/3820] New translations cosmos.mdx (Marathi)

---
 website/pages/mr/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/cookbook/cosmos.mdx b/website/pages/mr/cookbook/cosmos.mdx
index 80243dc25ebd..e918d095ab31 100644
--- a/website/pages/mr/cookbook/cosmos.mdx
+++ b/website/pages/mr/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## कॉसमॉस सबग्राफ काय आहेत?
 
-आलेख विकसकांना ब्लॉकचेन इव्हेंट्सवर प्रक्रिया करण्यास आणि परिणामी डेटा ओपन ग्राफक्यूएल API द्वारे सहज उपलब्ध करून देतो, ज्याला सबग्राफ म्हणून ओळखले जाते. [Graph Node](https://github.com/graphprotocol/graph-node) आता Cosmos इव्हेंटवर प्रक्रिया करण्यास सक्षम आहे, याचा अर्थ Cosmos डेव्हलपर आता ऑन-चेन इव्हेंट सहजपणे अनुक्रमित करण्यासाठी सबग्राफ तयार करू शकतात.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 कॉसमॉस सबग्राफमध्ये चार प्रकारचे हँडलर समर्थित आहेत:
 

From b84513c152c5bcf32ae3004d64d2c6940efff649 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:11 -0500
Subject: [PATCH 0569/3820] New translations cosmos.mdx (Swahili)

---
 website/pages/sw/cookbook/cosmos.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/cookbook/cosmos.mdx b/website/pages/sw/cookbook/cosmos.mdx
index cd23a3742f86..dfdb377688aa 100644
--- a/website/pages/sw/cookbook/cosmos.mdx
+++ b/website/pages/sw/cookbook/cosmos.mdx
@@ -6,7 +6,7 @@ This guide is an introduction on building subgraphs indexing [Cosmos](https://co
 
 ## What are Cosmos subgraphs?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index on-chain events.
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
 
 There are four types of handlers supported in Cosmos subgraphs:
 

From 6f2135701b4db0cdfae779154caa5124b44ae855 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:12 -0500
Subject: [PATCH 0570/3820] New translations curating.mdx (Romanian)

---
 website/pages/ro/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/network/curating.mdx b/website/pages/ro/network/curating.mdx
index a5a63f3e2751..f584117580ae 100644
--- a/website/pages/ro/network/curating.mdx
+++ b/website/pages/ro/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

From 6040e28a4de4291777d06d8e8b28503cc8847ed9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:13 -0500
Subject: [PATCH 0571/3820] New translations curating.mdx (Spanish)

---
 website/pages/es/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/network/curating.mdx b/website/pages/es/network/curating.mdx
index a11299ddd57e..f8a742b1ceb0 100644
--- a/website/pages/es/network/curating.mdx
+++ b/website/pages/es/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

From a0527f645c625192a7897a315fed6eb948012d52 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:14 -0500
Subject: [PATCH 0572/3820] New translations curating.mdx (Arabic)

---
 website/pages/ar/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/network/curating.mdx b/website/pages/ar/network/curating.mdx
index 970b6fbbc405..2470757e7f61 100644
--- a/website/pages/ar/network/curating.mdx
+++ b/website/pages/ar/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

From e05a65ddbbd105b0427b07c1888124fde9d87fea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:16 -0500
Subject: [PATCH 0573/3820] New translations curating.mdx (Czech)

---
 website/pages/cs/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/network/curating.mdx b/website/pages/cs/network/curating.mdx
index d0230e080bdf..c495615556f8 100644
--- a/website/pages/cs/network/curating.mdx
+++ b/website/pages/cs/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. Jaké jsou náklady na aktualizaci podgrafu?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. Jak často mohu svůj podgraf aktualizovat?
 

From 46ded0c59be75b7acf2ca0a94cf202a78703bbec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:17 -0500
Subject: [PATCH 0574/3820] New translations curating.mdx (German)

---
 website/pages/de/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/network/curating.mdx b/website/pages/de/network/curating.mdx
index a5a63f3e2751..f584117580ae 100644
--- a/website/pages/de/network/curating.mdx
+++ b/website/pages/de/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

From 6e4b4da064b37e4e5a4ff4279d10e772f7f68117 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:18 -0500
Subject: [PATCH 0575/3820] New translations curating.mdx (Italian)

---
 website/pages/it/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/network/curating.mdx b/website/pages/it/network/curating.mdx
index b7c0039f86b9..f1b41d808ea2 100644
--- a/website/pages/it/network/curating.mdx
+++ b/website/pages/it/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. Qual è il costo dell'aggiornamento di un subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. Con quale frequenza posso aggiornare il mio subgraph?
 

From 646f58ed43263d8a4a16f5f78cabbd4e98601456 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:19 -0500
Subject: [PATCH 0576/3820] New translations curating.mdx (Japanese)

---
 website/pages/ja/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/network/curating.mdx b/website/pages/ja/network/curating.mdx
index 1415887e0b70..daef48d4f790 100644
--- a/website/pages/ja/network/curating.mdx
+++ b/website/pages/ja/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. サブグラフの更新にかかるコストはいくらですか?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. サブグラフはどれくらいの頻度で更新できますか?
 

From 42d6fae67215199c1a2388bf4cd0c57641e41b0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:20 -0500
Subject: [PATCH 0577/3820] New translations curating.mdx (Korean)

---
 website/pages/ko/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/network/curating.mdx b/website/pages/ko/network/curating.mdx
index a5a63f3e2751..f584117580ae 100644
--- a/website/pages/ko/network/curating.mdx
+++ b/website/pages/ko/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

From 81b806c99e7531bcf4accf18228cce22196c8a33 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:21 -0500
Subject: [PATCH 0578/3820] New translations curating.mdx (Dutch)

---
 website/pages/nl/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/network/curating.mdx b/website/pages/nl/network/curating.mdx
index 3e64881ac6eb..a3b876b80717 100644
--- a/website/pages/nl/network/curating.mdx
+++ b/website/pages/nl/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### Wat zijn de kosten voor het updaten van een subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### Hoe vaak kan ik mijn subgraph updaten?
 

From fab4705432cd4ddec368a93e07f79fb1aed0ac03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:22 -0500
Subject: [PATCH 0579/3820] New translations curating.mdx (Polish)

---
 website/pages/pl/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/network/curating.mdx b/website/pages/pl/network/curating.mdx
index a5a63f3e2751..f584117580ae 100644
--- a/website/pages/pl/network/curating.mdx
+++ b/website/pages/pl/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

From b0945227ba6b226031b66064c86f44205c524947 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:24 -0500
Subject: [PATCH 0580/3820] New translations curating.mdx (Portuguese)

---
 website/pages/pt/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/network/curating.mdx b/website/pages/pt/network/curating.mdx
index 89fc295d4c15..6430ea65c82e 100644
--- a/website/pages/pt/network/curating.mdx
+++ b/website/pages/pt/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. Qual o custo de atualizar um subgraph?
 
-Migrar as suas ações de curadoria a uma nova versão de subgraph incorre uma taxa de curadoria de 1%. Os curadores podem escolher se inscrever na versão mais nova de um subgraph. Quando ações de curadores são automigradas a uma nova versão, os Curadores também pagarão metade da taxa de curadoria, por ex., 0.5%, porque a atualização de subgraphs é uma ação on-chain que custa gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. Com que frequência posso atualizar o meu subgraph?
 

From 7d5bcf8c0eedf18cdc043d50b3c6eda3830bf8f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:25 -0500
Subject: [PATCH 0581/3820] New translations curating.mdx (Russian)

---
 website/pages/ru/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/network/curating.mdx b/website/pages/ru/network/curating.mdx
index 1d05b5c92262..6ca88c1949b5 100644
--- a/website/pages/ru/network/curating.mdx
+++ b/website/pages/ru/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. Какова стоимость обновления подграфа?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. Как часто я могу обновлять свой подграф?
 

From 2f5ba2e084593ed366700b85deafb949c43afb96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:26 -0500
Subject: [PATCH 0582/3820] New translations curating.mdx (Swedish)

---
 website/pages/sv/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/network/curating.mdx b/website/pages/sv/network/curating.mdx
index 89b3b4d392f3..d5f29daf54ba 100644
--- a/website/pages/sv/network/curating.mdx
+++ b/website/pages/sv/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. Vad kostar det att uppdatera en subgraf?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. Hur ofta kan jag uppdatera min subgraf?
 

From c625c37a7137e93193061a06d9d7914de013895f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:27 -0500
Subject: [PATCH 0583/3820] New translations curating.mdx (Ukrainian)

---
 website/pages/uk/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/network/curating.mdx b/website/pages/uk/network/curating.mdx
index 513644bac22c..6be219760a3a 100644
--- a/website/pages/uk/network/curating.mdx
+++ b/website/pages/uk/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

From cd520dc88803f3f8fac5a8cb0621370a0de6c944 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:28 -0500
Subject: [PATCH 0584/3820] New translations curating.mdx (Chinese Simplified)

---
 website/pages/zh/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/network/curating.mdx b/website/pages/zh/network/curating.mdx
index 1788ca600226..9feaa3896d66 100644
--- a/website/pages/zh/network/curating.mdx
+++ b/website/pages/zh/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. 升级一个子图的成本是多少？
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. 我可以多频繁的升级子图？
 

From 853b827a59b080f2491c1c633316d9ee6b8bf735 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:29 -0500
Subject: [PATCH 0585/3820] New translations curating.mdx (Urdu (Pakistan))

---
 website/pages/ur/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/network/curating.mdx b/website/pages/ur/network/curating.mdx
index bd7bb8b3f57f..9e3be903c54b 100644
--- a/website/pages/ur/network/curating.mdx
+++ b/website/pages/ur/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. سب گراف کو اپ ڈیٹ کرنے کی کیا قیمت ہے؟
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. میں اپنے سب گراف کو کتنی بار اپ گریڈ کر سکتا ہوں؟
 

From 80b8d64a8c44e62e5ce08869f0ffdfff962ea61d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:30 -0500
Subject: [PATCH 0586/3820] New translations curating.mdx (Vietnamese)

---
 website/pages/vi/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/network/curating.mdx b/website/pages/vi/network/curating.mdx
index b10717935904..ec8afe46b474 100644
--- a/website/pages/vi/network/curating.mdx
+++ b/website/pages/vi/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

From fd6997bc187d4d329bd1f41ca8164413e0de0a7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:32 -0500
Subject: [PATCH 0587/3820] New translations curating.mdx (Marathi)

---
 website/pages/mr/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/network/curating.mdx b/website/pages/mr/network/curating.mdx
index 5e9cadc79a04..b1c7db5e3d77 100644
--- a/website/pages/mr/network/curating.mdx
+++ b/website/pages/mr/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

From b45776b0d35d1866e9ae2ad24a411e0a12c465c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:33 -0500
Subject: [PATCH 0588/3820] New translations curating.mdx (Hindi)

---
 website/pages/hi/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/network/curating.mdx b/website/pages/hi/network/curating.mdx
index 34d446b1314f..3a89e0064f67 100644
--- a/website/pages/hi/network/curating.mdx
+++ b/website/pages/hi/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

From 4fff5d04d0d2d1023638cb40ccd6f6dfc759af03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:34 -0500
Subject: [PATCH 0589/3820] New translations curating.mdx (Swahili)

---
 website/pages/sw/network/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/network/curating.mdx b/website/pages/sw/network/curating.mdx
index a5a63f3e2751..f584117580ae 100644
--- a/website/pages/sw/network/curating.mdx
+++ b/website/pages/sw/network/curating.mdx
@@ -68,7 +68,7 @@ Finding high-quality subgraphs is a complex task, but it can be approached in ma
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an on-chain action that costs gas.
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
 ### 4. How often can I update my subgraph?
 

From 47b66418ec48a02da1a15191b20bb7de37f928a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:35 -0500
Subject: [PATCH 0590/3820] New translations indexing.mdx (Romanian)

---
 website/pages/ro/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ro/network/indexing.mdx b/website/pages/ro/network/indexing.mdx
index 0eb017b5be3f..fc35c4e841b9 100644
--- a/website/pages/ro/network/indexing.mdx
+++ b/website/pages/ro/network/indexing.mdx
@@ -137,7 +137,7 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 - **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
 
-- **Indexer agent** - Facilitates the Indexers interactions on chain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards on chain and how much is allocated towards each.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
 - Indexer can use the `indexer-cli` to view all queued actions
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation on-chain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From b240845a00eafd7381a628aff6cf54299107bd39 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:36 -0500
Subject: [PATCH 0591/3820] New translations indexing.mdx (Spanish)

---
 website/pages/es/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/es/network/indexing.mdx b/website/pages/es/network/indexing.mdx
index 076ee45d9703..f6c5506e8154 100644
--- a/website/pages/es/network/indexing.mdx
+++ b/website/pages/es/network/indexing.mdx
@@ -137,7 +137,7 @@ En el centro de la infraestructura de un Indexador está el Graph Node que monit
 
 - **Servicio de Indexador**: Gestiona todas las comunicaciones externas necesarias con la red. Comparte modelos de costos y estados de indexación, transfiere solicitudes de consulta desde el gateway a Graph Node y administra los pagos de consultas a través de canales de estado con la gateway.
 
-- **Agente Indexador**: Facilita las interacciones de los Indexadores on-chain, incluido el registro en la red, la gestión de deploy de subgrafos en sus Graph Node y la gestión de allocations.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Servidor de métricas de Prometheus** - Los componentes Graph Node y el Indexer registran sus métricas en el servidor de métricas.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 Para participar con éxito en la red se requiere una supervisión e interacción casi constantes, por lo que hemos creado un conjunto de aplicaciones de Typecript para facilitar la participación de una red de Indexadores. Hay tres componentes de Indexador:
 
-- **Agente Indexador** - El agente monitorea la red y la propia infraestructura del Indexador y administra qué deploy de subgrafos se indexan y asignan on-chain y cuánto se asigna a cada uno.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Servicio de Indexador**: El único componente que debe exponerse externamente, el servicio transfiere las consultas de subgrafo al graph node, administra los canales de estado para los pagos de consultas, comparte información importante para la toma de decisiones a clientes como las gateways.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 El Indexador-cli proporciona un módulo de `acciones` para trabajar manualmente con la fila de acciones. Utiliza la **API Graphql** alojada en el servidor de gestión del Indexador para interactuar con la fila de acciones.
 
-El trabajador de ejecución de acciones sólo tomará elementos de la fila para ejecutarlos si tienen `ActionStatus = approved`. En la ruta recomendada, las acciones se añaden a la fila con ActionStatus = queued, por lo que deben ser aprobadas para poder ejecutarse on-chain. El flujo general será el siguiente:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Acción añadida a la fila por la herramienta optimizadora de terceros o el usuario de Indexer-cli
 - El Indexador puede utilizar el `indexer-cli` para ver todas las acciones en fila
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Se recomienda a los Indexadores que utilicen la funcionalidad de sincronización fuera de la cadena para sincronizar el deploy de subgrafos con el cabezal de la cadena antes de crear la allocation on-chain. Esta función es especialmente útil para subgrafos que pueden tardar más de 28 épocas en sincronizarse o que tienen algunas posibilidades de fallar de forma indeterminada.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 8debe99e7e34d56f232a255ea36a865b3f1b8281 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:38 -0500
Subject: [PATCH 0592/3820] New translations indexing.mdx (Arabic)

---
 website/pages/ar/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ar/network/indexing.mdx b/website/pages/ar/network/indexing.mdx
index 849d5d13f7b5..94f34c30faba 100644
--- a/website/pages/ar/network/indexing.mdx
+++ b/website/pages/ar/network/indexing.mdx
@@ -137,7 +137,7 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 - **خدمة المفهرس Indexer service**- يتعامل مع جميع الاتصالات الخارجية المطلوبة مع الشبكة. ويشارك نماذج التكلفة وحالات الفهرسة ، ويمرر طلبات الاستعلام من البوابات gateways إلى Graph Node ، ويدير مدفوعات الاستعلام عبر قنوات الحالة مع البوابة.
 
-- **Indexer agent** - Facilitates the Indexers interactions on chain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrics server** - مكونات The Graph Node والمفهرس يسجلون مقاييسهم على سيرفر المقاييس.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards on chain and how much is allocated towards each.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** - المكون الوحيد الذي يجب الكشف عنه للعامة، حيث تمر الخدمة على استعلامات subgraph إلى graph node ، وتدير قنوات الحالة state channels لمدفوعات الاستعلام ، وتشارك معلومات مهمة بشأن اتخاذ القرار للعملاء مثل البوابات gateways.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
 - Indexer can use the `indexer-cli` to view all queued actions
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation on-chain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 3bd13f5418772ad0f82c1a91c34596625661b96e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:39 -0500
Subject: [PATCH 0593/3820] New translations indexing.mdx (Czech)

---
 website/pages/cs/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/cs/network/indexing.mdx b/website/pages/cs/network/indexing.mdx
index fe0a36c340ca..5eb0540427fa 100644
--- a/website/pages/cs/network/indexing.mdx
+++ b/website/pages/cs/network/indexing.mdx
@@ -137,7 +137,7 @@ Centrem infrastruktury indexeru je uzel Graf, který monitoruje indexované sít
 
 - **Služba indexeru** - Zpracovává veškerou požadovanou externí komunikaci se sítí. Sdílí nákladové modely a stavy indexace, předává požadavky na dotazy z bran na uzel Graga spravuje platby za dotazy prostřednictvím stavových kanálů s branou.
 
-- **Indexer agent** - Usnadňuje interakce indexerů v řetězci, včetně registrace v síti, správy nasazení podgrafů do jejich grafových uzlů a správy alokací.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Server metrik Prometheus** - Komponenty Uzel grafu a Indexer zaznamenávají své metriky na metrický server.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 Úspěšná účast v síti vyžaduje téměř neustálé sledování a interakci, proto jsme vytvořili sadu aplikací Typescript pro usnadnění účasti v síti Indexers. K dispozici jsou tři komponenty Indexer:
 
-- **Agent indexátoru** - Agent monitoruje síť a vlastní infrastrukturu indexátoru a spravuje, která dílčí nasazení jsou indexována a alokována do řetězce a kolik je jim přiděleno.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Služba indexeru** - Jediná komponenta, která musí být vystavena externě, služba předává dotazy na podgraf uzlu grafu, spravuje stavové kanály pro platby dotazů, sdílí důležité rozhodovací informace klientům, jako jsou brány.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 Indexer-cli poskytuje modul `actions` pro ruční práci s frontou akcí. K interakci s frontou akcí používá **Graphql API**, které je hostováno serverem pro správu indexeru.
 
-Pracovník pro provádění akcí převezme položky z fronty k provedení pouze tehdy, pokud mají `ActionStatus = approved`. V doporučené cestě jsou akce přidány do fronty se stavem ActionStatus = queued, takže pak musí být schváleny, aby mohly být provedeny v řetězci. Obecný průběh bude vypadat takto:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Akce přidaná do fronty nástrojem optimalizace třetí strany nebo uživatelem indexer-cli
 - Indexer může pomocí `indexer-cli` zobrazit všechny akce ve frontě
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Aktivní** – Jakmile je alokace vytvořena v řetězci ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/ contract/staking/Staking.sol#L316)) je považován za **aktivní**. Část vlastního a/nebo delegovaného podílu indexeru je přidělena na nasazení podgrafu, což jim umožňuje nárokovat si odměny za indexování a obsluhovat dotazy pro toto nasazení podgrafu. Agent indexeru spravuje vytváření alokací na základě pravidel indexeru.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Indexerům se doporučuje využívat funkce synchronizace mimo řetězec k synchronizaci nasazení subgrafů do hlavy řetězce před vytvořením alokace v řetězci. Tato funkce je užitečná zejména pro subgrafy, jejichž synchronizace může trvat déle než 28 epoch nebo u nichž existuje určitá pravděpodobnost nedeterministického selhání.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From f000b5577a044a1a6df2d761740de6bb2f15b8ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:40 -0500
Subject: [PATCH 0594/3820] New translations indexing.mdx (German)

---
 website/pages/de/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/de/network/indexing.mdx b/website/pages/de/network/indexing.mdx
index 3b704381d0f0..d05a31f56072 100644
--- a/website/pages/de/network/indexing.mdx
+++ b/website/pages/de/network/indexing.mdx
@@ -137,7 +137,7 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 - **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
 
-- **Indexer agent** - Facilitates the Indexers interactions on chain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards on chain and how much is allocated towards each.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
 - Indexer can use the `indexer-cli` to view all queued actions
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation on-chain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From fa689f38922bc9969ed70d4ced31f642cbffbf9c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:42 -0500
Subject: [PATCH 0595/3820] New translations indexing.mdx (Italian)

---
 website/pages/it/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/it/network/indexing.mdx b/website/pages/it/network/indexing.mdx
index 183041694bb7..8a8ec3af61a4 100644
--- a/website/pages/it/network/indexing.mdx
+++ b/website/pages/it/network/indexing.mdx
@@ -137,7 +137,7 @@ Al centro dell'infrastruttura di un Indexer c'è the Graph Node, che monitora le
 
 - **Indexer service** - Gestisce tutte le comunicazioni esterne necessarie con la rete. Condivide i modelli di costo e gli stati di indicizzazione, passa le richieste di query dai gateway a un Graph Node e gestisce i pagamenti delle query tramite canali di stato con il gateway.
 
-- **Indexer agent** - Facilita le interazioni degli Indexer sulla chain, compresa la registrazione sulla rete, la gestione delle distribuzioni di subgraph ai Graph Node e la gestione delle allocazioni.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Server di metriche Prometheus** - I componenti Graph Node e Indexer registrano le loro metriche sul server delle metriche.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 Per partecipare con successo alla rete è necessario un monitoraggio e un'interazione quasi costante, quindi abbiamo costruito una suite di applicazioni Typescript per facilitare la partecipazione alla rete degli Indexer. I componenti di Indexer sono tre:
 
-- **Indexer agent** - L'agente monitora la rete e l'infrastruttura dell'Indexer e gestisce quali distribuzioni di subgraph vengono indicizzate e allocate sulla chain e quanto viene allocato su ciascuna di esse.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** - L'unico componente che deve essere esposto all'esterno, il servizio passa le query del subgraph al The Graph Node, gestisce i canali di stato per i pagamenti delle query, condivide importanti informazioni decisionali ai client come i gateway.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 L'indexer-cli fornisce un modulo di `actions` per lavorare manualmente con la coda di azioni. Utilizza il **Graphql API** ospitato dal server di gestione dell'Indexer per interagire con la coda delle azioni.
 
-L'operaio per l'esecuzione dell'azione prenderà gli elementi dalla coda per eseguirli solo se hanno `ActionStatus = approved`. Nel percorso consigliato le azioni vengono aggiunte alla coda con ActionStatus = queued, quindi devono essere approvate per essere eseguite sulla catena. Il flusso generale sarà simile a:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Azione aggiunta alla coda dallo strumento ottimizzatore di terze parti o dall'utente di indexer-cli
 - L' Indexer può utilizzare l'`indexer-cli` per visualizzare tutte le azioni in coda
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Si raccomanda agli Indexer di utilizzare la funzionalità di sincronizzazione offchain per sincronizzare le distribuzioni dei subgraph con chainhead prima di creare l'allocazione on-chain. Questa funzione è particolarmente utile per i subgraph che possono richiedere più di 28 epoche per la sincronizzazione o che hanno qualche possibilità di fallire in modo indeterminato.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From a9ea105e564c5978c03d991b410d46e6f2ae1098 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:43 -0500
Subject: [PATCH 0596/3820] New translations indexing.mdx (Japanese)

---
 website/pages/ja/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ja/network/indexing.mdx b/website/pages/ja/network/indexing.mdx
index a1202e884ecc..53cd6002d33c 100644
--- a/website/pages/ja/network/indexing.mdx
+++ b/website/pages/ja/network/indexing.mdx
@@ -137,7 +137,7 @@ Use Etherscan to call `getRewards()`:
 
 - **Indexer service** - ネットワークとの必要な外部通信を全て処理します。 コストモデルとインデキシングのステータスを共有し、ゲートウェイからのクエリ要求をグラフノードに渡し、ゲートウェイとのステートチャンネルを介してクエリの支払いを管理します。
 
-- **Indexer agent** - ネットワークへの登録、グラフノードへのサブグラフのデプロイ管理、割り当ての管理など、チェーン上のインデクサーのインタラクションを容易にします。
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrics server** - Graph Node と Indexer コンポーネントは、自分のメトリクスをメトリクス・サーバーにログします。
 
@@ -366,7 +366,7 @@ docker-compose up
 
 ネットワークへの参加を成功させるためには、ほぼ常に監視と対話を行う必要があるため、Indexers のネットワークへの参加を促進するための一連の Typescript アプリケーションを構築しました。 インデクサーには 3 つのコンポーネントがあります:
 
-- **Indexer agent** - ネットワークとインデクサー自身のインフラを監視し、どのサブグラフ・デプロイメントがインデキシングされ、チェーンに割り当てられるか、またそれぞれにどれだけの量が割り当てられるかを管理します。
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** - 外部に公開する必要のある唯一のコンポーネントで、サブグラフのクエリをグラフノードに渡し、クエリの支払いのための状態チャンネルを管理し、重要な意思決定情報をゲートウェイなどのクライアントに共有します。
 
@@ -616,7 +616,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 indexer-cli は、アクションキューを手動で操作するための `actions` モジュールを提供します。これは、アクションキューと対話するために、インデクサ管理サーバによってホストされる **Graphql API** を使用します。
 
-アクション実行ワーカーは、`ActionStatus = approved` である場合にのみ、実行するためにキューからアイテムを取得します。推奨されるパスでは、アクションは ActionStatus = queued でキューに追加されるので、オンチェインで実行するためには承認されなければなりません。一般的なフローは次のようになります。
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - サードパーティのオプティマイザツールやindexer-cliのユーザーによってキューに追加されたアクション
 - インデクサーは `indexer-cli` を使って、キューに入れられたすべてのアクションを見ることができます。
@@ -811,8 +811,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-インデクサーは、チェーン上に配置を作成する前に、チェーンヘッドにサブグラフの配置を同期させるために、オフチェーン同期機能を利用することを推奨します。この機能は、同期に28エポック以上かかる可能性があるサブグラフや、不定期に失敗する可能性があるサブグラフに特に有効です。
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From a1f0707f22a810b6e6792a361c1ec8fe6f3f47fd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:45 -0500
Subject: [PATCH 0597/3820] New translations indexing.mdx (Korean)

---
 website/pages/ko/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ko/network/indexing.mdx b/website/pages/ko/network/indexing.mdx
index 0eb017b5be3f..fc35c4e841b9 100644
--- a/website/pages/ko/network/indexing.mdx
+++ b/website/pages/ko/network/indexing.mdx
@@ -137,7 +137,7 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 - **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
 
-- **Indexer agent** - Facilitates the Indexers interactions on chain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards on chain and how much is allocated towards each.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
 - Indexer can use the `indexer-cli` to view all queued actions
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation on-chain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From e542984bb1932a472148d89c6eb7a43f1adc9808 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:46 -0500
Subject: [PATCH 0598/3820] New translations indexing.mdx (Dutch)

---
 website/pages/nl/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/nl/network/indexing.mdx b/website/pages/nl/network/indexing.mdx
index 40c0fc8f131e..6dc4c3ee19bd 100644
--- a/website/pages/nl/network/indexing.mdx
+++ b/website/pages/nl/network/indexing.mdx
@@ -137,7 +137,7 @@ Het hart van de infrastructuur van een Indexeerder is de Graph Node, die de geï
 
 - **Indexer service** - Beheert alle vereiste externe communicatie met het netwerk. Deelt kostenmodellen en indexeerstatussen, stuurt query's van gateways door naar een Graph Node en beheert de query betalingen via state channels met de gateway.
 
-- **Indexer agent** - Faciliteert de interacties van de Indexeerders op de chain, inclusief registratie op het netwerk, beheer van subgraph implementaties op de Graph Node(s) en beheer van allocaties.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrics-server** - De Graph Node en Indexer-componenten versturen hun metrics naar de metrics-server.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 Om succesvol deel te nemen aan het netwerk is bijna constante monitoring en interactie nodig, dus we hebben een reeks Typescript applicaties ontwikkeld om deelname van Indexeerders aan het netwerk te vergemakkelijken. De indexer heeft drie componenten:
 
-- **Indexer agent** - De agent monitort het netwerk en de Indexers eigen infrastructuur en beheert welke subgraph implementaties worden geïndexeerd en allocaties naar on chain en hoe veel naar elk toegewezen wordt.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** - Het enige component dat extern moet worden blootgesteld. De Indexer service geeft subgraph query's door aan de Graph Node, beheert state channels voor betalingen van query's en deelt belangrijke besluitvormingsinformatie met cliënten zoals de gateways.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
 - Indexer can use the `indexer-cli` to view all queued actions
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation on-chain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 29af58650d2af2738a9d23b7079cfd2e94ac457a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:47 -0500
Subject: [PATCH 0599/3820] New translations indexing.mdx (Polish)

---
 website/pages/pl/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/pl/network/indexing.mdx b/website/pages/pl/network/indexing.mdx
index 0eb017b5be3f..fc35c4e841b9 100644
--- a/website/pages/pl/network/indexing.mdx
+++ b/website/pages/pl/network/indexing.mdx
@@ -137,7 +137,7 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 - **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
 
-- **Indexer agent** - Facilitates the Indexers interactions on chain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards on chain and how much is allocated towards each.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
 - Indexer can use the `indexer-cli` to view all queued actions
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation on-chain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 541fa4bf09d0073f3f38f8a20b2be1913ce4760c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:49 -0500
Subject: [PATCH 0600/3820] New translations indexing.mdx (Portuguese)

---
 website/pages/pt/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/pt/network/indexing.mdx b/website/pages/pt/network/indexing.mdx
index 36e588e4237e..a081ea902fbf 100644
--- a/website/pages/pt/network/indexing.mdx
+++ b/website/pages/pt/network/indexing.mdx
@@ -137,7 +137,7 @@ O núcleo da infraestrutura de um Indexador é o Graph Node, que monitora as red
 
 - **Serviço de Indexador** — Cuida de todas as comunicações externas com a rede requeridas. Divide modelos de custo e estados de indexação, passa pedidos de consulta de gateways para um Graph Node, e monitora os pagamentos de consulta através de canais de estado com o gateway.
 
-- **Agente Indexador** — Facilita as interações de Indexadores on-chain, incluindo cadastros na rede, gestão de lançamentos de Subgraph ao(s) seu(s) Graph Node(s), e gestão de alocações.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Servidor de métricas Prometheus** — O Graph Node e os componentes de Indexador logam suas métricas ao servidor de métricas.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 Para participar com êxito na rede, são necessários monitorados e interações quase constantes, portanto, construímos uma suite de aplicativos Typescript para facilitar a participação de um Indexador na rede. Há três componentes de Indexador:
 
-- **Agente indexador** — O agente monitora a rede e a própria infraestrutura do Indexador, e administra quais lançamentos de subgraph são indexados e alocados on-chain; e a quantia a ser alocada para cada um.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Serviço indexador** — O único componente que deve ser exposto externamente, o serviço passa consultas de subgraph ao graph node, cuida de canais de estado para pagamentos de consulta, e compartilha informações importantes de decisões para clientes, como os gateways.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 O indexer-cli providencia um módulo `actions` para trabalhar manualmente com a fila de ações. Ele interage com a fila de ações através do **API GraphQL** hospedado pelo servidor de gestão de indexador.
 
-O trabalhador de execução de ações só retirará itens da fila para execução se eles tiverem o `ActionStatus = approved`. No caminho recomendado, as ações são adicionadas à fila com `ActionStatus = queued`, para que sejam depois aprovadas para serem executadas on-chain. O fluxo geral parecerá com isto:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Ação adicionada à fila por ferramenta de otimização de terceiros ou utilizador do indexer-cli
 - O Indexador pode usar o `indexer-cli` para visualizar todas as ações enfileiradas
@@ -813,8 +813,8 @@ Para configurar os parâmetros de delegação com a interface do Graph Explorer,
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Ativa** - Quando uma alocação é criada on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)), ela é considerada **ativa**. Uma porção do stake próprio e/ou delegado do Indexador é alocada a um lançamento de subgraph, que lhe permite resgatar recompensas de indexação e servir queries para aquele lançamento de subgraph. O agente indexador cria alocações baseada nas regras do Indexador.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Fechada** - Um Indexador pode fechar uma alocação após a passagem de um epoch ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)), ou o seu agente indexador a fechará automaticamente após o **maxAllocationEpochs** (atualmente, 28 dias). Quando uma alocação é fechada com uma prova de indexação válida (POI), as suas recompensas de indexação são distribuídas ao Indexador e aos seus Delegantes ([aprenda mais](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-É ideal que os Indexadores utilizem a funcionalidade de sincronização off-chain para sincronizar lançamentos de subgraph à chainhead antes de criar a alocação on-chain. Esta ferramenta é mais útil para subgraphs que demorem mais de 28 epochs para sincronizar, ou que têm chances de falhar não-deterministicamente.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From ef40ec4ca8261b430bbc16b99aed9d31ac1fb962 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:50 -0500
Subject: [PATCH 0601/3820] New translations indexing.mdx (Russian)

---
 website/pages/ru/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ru/network/indexing.mdx b/website/pages/ru/network/indexing.mdx
index 978878e51f41..7eb4d8c8ec3e 100644
--- a/website/pages/ru/network/indexing.mdx
+++ b/website/pages/ru/network/indexing.mdx
@@ -137,7 +137,7 @@ Once an allocation has been closed the rebates are available to be claimed by th
 
 - **Indexer service**. Обрабатывает все необходимые внешние подключения к сети. Совместно использует модели затрат и статусы индексации, передает заявки на запросы от шлюзов на Graph Node, и управляет платежами по запросам через каналы состояний с помощью шлюза.
 
-- **Indexer agent**. Облегчает взаимодействие индексаторов в сети, включая регистрацию в сети, управление развертыванием подграфов на его Graph Node/ах и управление аллокациями.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrics server**. Компоненты Graph Node и индексатора регистрируют свои показатели на сервере данных.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 Для успешного участия в сети требуется почти постоянный мониторинг и взаимодействие, поэтому мы создали набор приложений на основе Typescript для облегчения участия индексаторов в сети. Существует три компонента индексатора:
 
-- **Indexer agent**. Агент отслеживает сеть и собственную инфраструктуру индексатора и управляет тем, какие развертывания подграфов индексируются и распределяются по сети, а также сколько выделено для каждого из них.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** — единственный компонент, который должен быть доступен извне. Служба передает запросы подграфа на the graph ноду, управляет каналами состояния для платежей по запросу, делится важной информацией для принятия решений с клиентами, такими как шлюзы.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 indexer-cli предоставляет модуль `actions` для ручного управления очередностью действий. Для взаимодействия с очередностью действий он использует **Graphql API**, размещенный на сервере управления индексатором.
 
-Обработчик выполнения действий будет извлекать элементы из очереди для выполнения только в том случае, если они имеют `ActionStatus = Approved`. В рекомендуемом пути действия добавляются в очередь с ActionStatus = queued, поэтому они должны быть одобрены для выполнения в сети. Общий поток будет выглядеть следующим образом:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Действие, добавленное в очередь сторонним инструментом оптимизатора или пользователем indexer-cli
 - Индексатор может использовать `indexer-cli` для просмотра всех действий, поставленных в очередь
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Индексаторам рекомендуется использовать функцию синхронизации вне сети для синхронизации развертывания подграфов в chainhead перед созданием аллокации в сети. Эта функция особенно полезна для подграфов, синхронизация которых может занять более 28 эпох или имеющих некоторую вероятность неопределенного сбоя.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 7b2bbf229855f5107a7ec81fbb26e4f55d6a4cdb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:51 -0500
Subject: [PATCH 0602/3820] New translations indexing.mdx (Swedish)

---
 website/pages/sv/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/sv/network/indexing.mdx b/website/pages/sv/network/indexing.mdx
index c249ed8f3404..046e157b93e0 100644
--- a/website/pages/sv/network/indexing.mdx
+++ b/website/pages/sv/network/indexing.mdx
@@ -137,7 +137,7 @@ I centrum av en Indexers infrastruktur finns Graph Node, som övervakar de index
 
 - **Indexertjänst** - Hanterar alla nödvändiga externa kommunikationer med nätverket. Delar kostnadsmodeller och indexeringsstatus, skickar frågebegäranden från gateways vidare till en Graph Node och hanterar frågebetalningar via tillståndskanaler med gatewayen.
 
-- **Indexeragent** - Underlättar Indexers interaktioner på kedjan, inklusive registrering i nätverket, hantering av subgrafdistributioner till sina Graph Node/noder och hantering av tilldelningar.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus-metrisk server** - Graph Node och Indexer-komponenter loggar sina metriska data till metrisk servern.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 För att framgångsrikt delta i nätverket krävs nästan konstant övervakning och interaktion, så vi har byggt en uppsättning Typescript-applikationer för att underlätta en Indexers nätverksdeltagande. Det finns tre Indexer-komponenter:
 
-- **Indexeragent** - Agenten övervakar nätverket och Indexerens egen infrastruktur och hanterar vilka subgraph-distributioner som indexeras och tilldelas på kedjan och hur mycket som tilldelas till varje.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexertjänst** - Den enda komponenten som behöver exponeras externt, tjänsten vidarebefordrar subgraph-förfrågningar till grafnoden, hanterar tillståndskanaler för förfrågningsbetalningar, delar viktig beslutsinformation till klienter som gatewayer.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 Indexer-cli tillhandahåller ett `actions`-modul för manuellt arbete med åtgärds kön. Det använder **Graphql API** som hostas av indexeringshanteringsservern för att interagera med åtgärds kön.
 
-Åtgärdsutförande-arbetaren kommer endast att hämta objekt från kön för att utföra om de har `ActionStatus = approved`. På den rekommenderade vägen läggs åtgärder till i kön med ActionStatus = queued, så de måste sedan godkännas för att utföras på kedjan. Den generella flödet kommer att se ut som följer:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Åtgärd läggs till i kön av tredjeparts-optimeringsverktyget eller indexer-cli-användaren
 - Indexer kan använda `indexer-cli` för att visa alla köade åtgärder
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Det rekommenderas att Indexers använder funktionen för offchain-synkronisering för att synkronisera subgraph-deploys till kedjehuvudet innan de skapar allokeringen på kedjan. Den här funktionen är särskilt användbar för subgraphs som kan ta längre tid än 28 epoker att synkronisera eller har vissa chanser att misslyckas obestämt.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 9bdaa914eb2ccea985366d0b42b4c66223ba8434 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:52 -0500
Subject: [PATCH 0603/3820] New translations indexing.mdx (Ukrainian)

---
 website/pages/uk/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/uk/network/indexing.mdx b/website/pages/uk/network/indexing.mdx
index 8c30f75568e8..a7ebfc01808c 100644
--- a/website/pages/uk/network/indexing.mdx
+++ b/website/pages/uk/network/indexing.mdx
@@ -137,7 +137,7 @@ Query fees are collected by the gateway and distributed to indexers according to
 
 - **Indexer service** - виконує всі необхідні зовнішні комунікації з мережею. Обмінюється моделями витрат і статусами індексації, передає запити від шлюзів до Graph Node, а також керує оплатою запитів через відповідні канали зі шлюзом.
 
-- **Indexer agent** - полегшує взаємодію індексаторів в мережі, включаючи реєстрацію у мережі, керування розгортанням підграфів у Graph Node/-ах та керуванням розподілами.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Сервер метрик Prometheus** - Компоненти Graph Node та індексаторів реєструють свої метрики на відповідному на сервері.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 Для успішної участі в мережі потрібен майже постійний моніторинг і взаємодію, тому ми створили набір додатків Typescript для полегшення участі в мережі індексаторів. Існує три компоненти Індексатора:
 
-- **Indexer agent** - Агент відстежує мережу та власну інфраструктуру індексатора і керує розгортаннями підграфів, які індексуються та розподіляються в мережі, а також визначає, скільки ресурсів виділяється для кожного з них.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** - Єдиний компонент, який потрібно виставляти назовні, сервіс передає запити підграфів до graph node, керує каналами стану для оплати запитів, ділиться важливою інформацією для прийняття рішень з клієнтами, такими як шлюзи.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 indexer-cli надає модуль `actions` для ручної роботи з чергою дій. Для взаємодії з чергою дій він використовує **Graphql API**, розміщений на сервері керування індексатором.
 
-Виконавець дії буде брати елементи з черги на виконання, тільки якщо вони мають `ActionStatus = accepted`. У рекомендованому шляху дії додаються до черги зі статусом ActionStatus = queued, тому вони повинні бути схвалені, щоб бути виконаними в мережі. Загальний потік буде виглядати так:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Дія, додана до черги стороннім оптимізатором або користувачем indexer-cli
 - Індексатор може використовувати `indexer-cli` для перегляду всіх дій у черзі
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Індексаторам рекомендується використовувати функцію offchain синхронізації для синхронізації розгортань підграфів з head of chain перед створенням розподілів у мережі. Ця функція особливо корисна для підграфів, синхронізація яких може зайняти понад 28 епох, або для яких існує ймовірність невизначеного збою.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From b0347f05b7ace87cb00533ecdb7730ec53be0ced Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:54 -0500
Subject: [PATCH 0604/3820] New translations indexing.mdx (Chinese Simplified)

---
 website/pages/zh/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/zh/network/indexing.mdx b/website/pages/zh/network/indexing.mdx
index 9451572c8438..04be82599373 100644
--- a/website/pages/zh/network/indexing.mdx
+++ b/website/pages/zh/network/indexing.mdx
@@ -137,7 +137,7 @@ Query fees are collected by the gateway and distributed to indexers according to
 
 - **索引人服务** -处理所有网络必要的外部通信。 共享成本模型和索引状态，将来自网关的查询请求传递给一个Graph节点，并通过状态通道与网关管理查询支付。
 
-- **索引人代理** - 促进索引人在链上的交互，包括在网络上注册，管理子图部署到其Graph节点，以及管理分配。
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus 指标服务器** - Graph节点 和索引人组件将其指标记录到指标服务器。
 
@@ -367,7 +367,7 @@ docker-compose up
 
 要成功地参与网络，需要几乎持续的监控和互动，所以我们建立了一套 Typescript 应用程序，以方便索引人的网络参与。 有三个索引人组件。
 
-- **索引人代理** - 代理监控网络和索引人自身的基础设施，并管理哪些子图部署被索引和分配到链上，以及分配到每个子图的数量。
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **索引人服务** - 唯一需要对外暴露的组件，该服务将子图查询传递给节点，管理查询支付的状态通道，将重要的决策信息分享给网关等客户端。
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 Indexer-cli 提供了一个 `actions` 模块，用于手动处理操作队列。它使用由索引器管理服务器托管的 **Graphql API** 与操作队列进行交互。
 
-如果`ActionStatus=已批准`，则操作执行工作人员将仅从队列中获取要执行的项目。在推荐的路径中，操作被添加到ActionStatus=queued的队列中，因此必须经过批准才能在链上执行。一般流程如下：
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - 第三方优化器工具或indexer-cli用户添加到队列的操作
 - 索引人可以使用`indexer-cli`查看所有排队的操作
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-建议索引人在链上创建分配之前，利用链外同步功能将子图部署同步到链头。对于可能需要超过28个时期才能同步或有一些无法确定失败的机会的子图，此功能特别有用。
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From bccee1b5b833fc2894133cb9c1af56734e26fbec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:55 -0500
Subject: [PATCH 0605/3820] New translations indexing.mdx (Urdu (Pakistan))

---
 website/pages/ur/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ur/network/indexing.mdx b/website/pages/ur/network/indexing.mdx
index 59933c810c92..43e9ae1c8047 100644
--- a/website/pages/ur/network/indexing.mdx
+++ b/website/pages/ur/network/indexing.mdx
@@ -137,7 +137,7 @@ query indexerAllocations {
 
 - **انڈیکسر سروس** - نیٹ ورک کے ساتھ تمام مطلوبہ بیرونی مواصلات کو ہینڈل کرتا ہے۔ لاگت کے ماڈلز اور انڈیکسنگ کے حالات کا اشتراک کرتا ہے، گیٹ ویز سے کیوری کی درخواستوں کو گراف نوڈ پر منتقل کرتا ہے، اور گیٹ وے کے ساتھ سٹیٹ چینلز کے ذریعے کیوری کی ادائیگیوں کا انتظام کرتا ہے.
 
-- **انڈیکسر ایجنٹ** - نیٹ ورک پر رجسٹریشن، اس کے گراف نوڈ/س میں سب گراف کی تعیناتیوں کا انتظام، اور ایلوکیشنز کا نظم کرنے سمیت چین پر انڈیکسرز کے تعاملات کی سہولت فراہم کرتا ہے.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus میٹرکس سرور** - گراف نوڈ اور انڈیکسر کمپونینٹس اپنے میٹرکس کو میٹرکس سرور پر لاگ کرتے ہیں.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 نیٹ ورک میں کامیابی کے ساتھ حصہ لینے کے لیے تقریباً مسلسل نگرانی اور تعامل کی ضرورت ہوتی ہے، اس لیے ہم نے انڈیکسرز نیٹ ورک کی شرکت کی سہولت کے لیے Typescript ایپلی کیشنز کا ایک مجموعہ بنایا ہے. انڈیکسر کے تین کمپونینٹس ہیں:
 
-- **انڈیکسر ایجنٹ** - ایجنٹ نیٹ ورک اور انڈیکسر کے اپنے بنیادی انفراسٹرکچر کی نگرانی کرتا ہے اور اس کا انتظام کرتا ہے کہ کون سے سب گراف کی تعیناتیوں کو انڈیکس کیا جا رہا ہے اور چین کی طرف مختص کیا جاتا ہے اور ہر ایک کے لیے کتنی رقم مختص کی جاتی ہے.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **انڈیکسر سروس** - واحد کمپونینٹ جسے بیرونی طور پر سامنے لانے کی ضرورت ہے، سروس سب گراف کیوریز کو گراف نوڈ تک پہنچاتی ہے، کیوری کی ادائیگی کے لیے سٹیٹ چینلز کا انتظام کرتی ہے، کلائنٹس کو فیصلہ سازی کی اہم معلومات شیئر کرتی ہے جیسا کہ گیٹ ویز.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 Indexer-cli کارروائی کی قطار کے ساتھ دستی طور پر کام کرنے کے لیے ایک `actions` ماڈیول فراہم کرتا ہے. یہ کارروائی کی قطارe کے ساتھ تعامل کرنے کے لیے انڈیکسر مینیجمینٹ سرور کے زیر اہتمام **Graphql API** کا استعمال کرتا ہے.
 
-عمل پر عملدرآمد کرنے والا کارکن صرف اس صورت میں قطار سے آئٹمز کو پکڑے گا جب ان کے پاس `ActionStatus = approved` ہو. تجویز کردہ راستے میں کارروائیوں کو ActionStatus = queued کے ساتھ قطار میں شامل کیا جاتا ہے، لہذا ان کو آن چین پر عمل درآمد کرنے کے لیے منظور ہونا ضروری ہے۔ عام بہاؤ اس طرح نظر آئے گا:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - فریق ثالث کا اصلاح کنندہ ٹول یا indexer-cli صارف کے ذریعے قطار میں ایکشن شامل کیا گیا
 - انڈیکسر تمام queued کارروائیوں کو دیکھنے کے لیے `indexer-cli` استعمال کر سکتا ہے
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-انڈیکسرز کو تجویز کی جاتی ہے کہ وہ offchain مطابقت پذیری کی فعالیت کو استعمال کریں تاکہ on-chain ایلوکیشن سے پہلے سب گراف کی تعیناتیوں کو chainhead سے ہم آہنگ کیا جا سکے. یہ خصوصیت خاص طور پر ان سب گرافوں کے لیے مفید ہے جن کی مطابقت پذیری میں 28 ایپوک سے زیادہ وقت لگ سکتا ہے یا غیر یقینی طور پر ناکام ہونے کے کچھ امکانات ہوتے ہیں.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From fda1011ef72d3446f9d975dfcf1ec5882cd77c4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:57 -0500
Subject: [PATCH 0606/3820] New translations indexing.mdx (Vietnamese)

---
 website/pages/vi/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/vi/network/indexing.mdx b/website/pages/vi/network/indexing.mdx
index b19e9f99a983..118361663a72 100644
--- a/website/pages/vi/network/indexing.mdx
+++ b/website/pages/vi/network/indexing.mdx
@@ -137,7 +137,7 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 - **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
 
-- **Indexer agent** - Facilitates the Indexers interactions on chain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards on chain and how much is allocated towards each.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Dịch vụ Indexer** - Thành phần duy nhất cần được hiển thị bên ngoài, dịch vụ chuyển các truy vấn subgraph đến graph node, quản lý các kênh trạng thái cho các khoản thanh toán truy vấn, chia sẻ thông tin ra quyết định quan trọng cho máy khách như các cổng.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
 - Indexer can use the `indexer-cli` to view all queued actions
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation on-chain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From e25346362416061f5ffb646ec44661c5abcbb1ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:58 -0500
Subject: [PATCH 0607/3820] New translations indexing.mdx (Marathi)

---
 website/pages/mr/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/mr/network/indexing.mdx b/website/pages/mr/network/indexing.mdx
index 4f87435bda60..ad7593a80edb 100644
--- a/website/pages/mr/network/indexing.mdx
+++ b/website/pages/mr/network/indexing.mdx
@@ -137,7 +137,7 @@ Once an allocation has been closed the rebates are available to be claimed by th
 
 - **इंडेक्सर सेवा** - नेटवर्कसह सर्व आवश्यक बाह्य संप्रेषणे हाताळते. किमतीची मॉडेल्स आणि अनुक्रमणिका स्थिती शेअर करते, गेटवेकडून आलेख नोडवर क्वेरी विनंत्या पाठवते आणि गेटवेसह राज्य चॅनेलद्वारे क्वेरी पेमेंट व्यवस्थापित करते.
 
-- **इंडेक्सर एजंट** - नेटवर्कवर नोंदणी करणे, त्याच्या ग्राफ नोड्सवर सबग्राफ उपयोजन व्यवस्थापित करणे आणि वाटप व्यवस्थापित करणे यासह साखळीवरील इंडेक्सर्स परस्परसंवाद सुलभ करते.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **प्रोमेथियस मेट्रिक्स सर्व्हर** - ग्राफ नोड आणि इंडेक्सर घटक त्यांचे मेट्रिक्स मेट्रिक्स सर्व्हरवर लॉग करतात.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 फक्त लिनक्स वापरण्यासाठी - स्क्रिप्ट वापरून `docker-compose. yaml` मध्ये `host. docker. internal` समाविष्ट करा होस्ट आयपी पत्ता वापरा:
 
-- **इंडेक्सर एजंट** - एजंट नेटवर्क आणि इंडेक्सरच्या स्वतःच्या इन्फ्रास्ट्रक्चरचे निरीक्षण करतो आणि कोणते सबग्राफ डिप्लॉयमेंट अनुक्रमित केले जातात आणि साखळीवर वाटप केले जातात आणि प्रत्येकासाठी किती वाटप केले जाते हे व्यवस्थापित करतो.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **इंडेक्सर सेवा** - बाहेरून उघड करणे आवश्यक असलेला एकमेव घटक, सेवा ग्राफ नोडवर सबग्राफ क्वेरी पास करते, क्वेरी पेमेंटसाठी राज्य चॅनेल व्यवस्थापित करते, महत्त्वपूर्ण निर्णय घेण्याची माहिती सामायिक करते गेटवे सारख्या ग्राहकांना.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 इंडेक्सर-cli कृती रांगेसह मॅन्युअली कार्य करण्यासाठी `कृती` मॉड्यूल प्रदान करते. ते क्रिया रांगेशी संवाद साधण्यासाठी इंडेक्सर व्यवस्थापन सर्व्हरद्वारे होस्ट केलेले **Graphql API** वापरते.
 
-क्रिया अंमलबजावणी कार्यकर्ता रांगेतील आयटम फक्त अंमलात आणण्यासाठी पकडेल जर त्यांच्याकडे `ActionStatus = मंजूर` असेल. शिफारस केलेल्या पथात क्रिया ActionStatus = रांगेत रांगेत जोडल्या जातात, त्यामुळे ऑन-चेन अंमलात आणण्यासाठी त्या नंतर मंजूर केल्या पाहिजेत. सामान्य प्रवाह असे दिसेल:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
 - Indexer can use the `indexer-cli` to view all queued actions
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-ऑन-चेन वाटप तयार करण्यापूर्वी चेनहेडमध्ये सबग्राफ उपयोजन समक्रमित करण्यासाठी ऑफचेन सिंकिंग कार्यक्षमता वापरण्याची शिफारस इंडेक्सर्सना केली जाते. हे वैशिष्ट्य विशेषतः उपग्राफसाठी उपयुक्त आहे ज्यांना समक्रमित करण्यासाठी 28 पेक्षा जास्त काळ लागू शकतो किंवा अनिश्चितपणे अयशस्वी होण्याची काही शक्यता असते.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 533a701102e204b3e3bc40367ffdc3f590868d35 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:24:59 -0500
Subject: [PATCH 0608/3820] New translations indexing.mdx (Swahili)

---
 website/pages/sw/network/indexing.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/sw/network/indexing.mdx b/website/pages/sw/network/indexing.mdx
index 0eb017b5be3f..fc35c4e841b9 100644
--- a/website/pages/sw/network/indexing.mdx
+++ b/website/pages/sw/network/indexing.mdx
@@ -137,7 +137,7 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 - **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
 
-- **Indexer agent** - Facilitates the Indexers interactions on chain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
 - **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
 
@@ -367,7 +367,7 @@ docker-compose up
 
 To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards on chain and how much is allocated towards each.
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
 
 - **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
 
@@ -617,7 +617,7 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like:
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
 - Indexer can use the `indexer-cli` to view all queued actions
@@ -812,8 +812,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 After being created by an Indexer a healthy allocation goes through two states.
 
-- **Active** - Once an allocation is created on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 
 - **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/network/indexing/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation on-chain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From c19d976e248211c91f93a8dfa63ec38ccd0287cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:00 -0500
Subject: [PATCH 0609/3820] New translations glossary.mdx (Romanian)

---
 website/pages/ro/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ro/glossary.mdx b/website/pages/ro/glossary.mdx
index bdeff7281023..fa813b659730 100644
--- a/website/pages/ro/glossary.mdx
+++ b/website/pages/ro/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 

From edc831a91593264cde857e4f731b03ee803e512b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:02 -0500
Subject: [PATCH 0610/3820] New translations glossary.mdx (French)

---
 website/pages/fr/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/glossary.mdx b/website/pages/fr/glossary.mdx
index ebe5e6e88668..9e97b6f22479 100644
--- a/website/pages/fr/glossary.mdx
+++ b/website/pages/fr/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossaire
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Actif** : Une allocation est considérée comme active lorsqu'elle est créée sur la chaîne. Cela s'appelle ouvrir une allocation, et indique au réseau que l'indexeur indexe et sert activement les requêtes pour un subgraph particulier. Les allocations actives accumulent des récompenses d'indexation proportionnelles au signal sur le subgraph et à la quantité de GRT allouée.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossaire
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client** : une bibliothèque pour créer des dapps basées sur GraphQL de manière décentralisée.
 

From 26a17a4136bcb8e4dc4ec6532a4a665f96ebfdf7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:03 -0500
Subject: [PATCH 0611/3820] New translations glossary.mdx (Spanish)

---
 website/pages/es/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/es/glossary.mdx b/website/pages/es/glossary.mdx
index b2b41524b887..0075b9ffcdb5 100644
--- a/website/pages/es/glossary.mdx
+++ b/website/pages/es/glossary.mdx
@@ -42,7 +42,7 @@ title: Glosario
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Activa (Active)**: Una allocation se considera activa cuando se crea on-chain. Esto se llama abrir una allocation, e indica a la red que el Indexador está indexando activamente y sirviendo consultas para un subgrafo en particular. Las allocations activas acumulan recompensas de indexación proporcionales a la señal del subgrafo y a la cantidad de GRT asignada.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glosario
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **Cliente The Graph (The Graph Client)**: Una biblioteca para construir dapps basadas en GraphQL de forma descentralizada.
 

From 4f53fb8fc32ca1ded9107deb12a208d960ee0d3d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:04 -0500
Subject: [PATCH 0612/3820] New translations glossary.mdx (Arabic)

---
 website/pages/ar/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ar/glossary.mdx b/website/pages/ar/glossary.mdx
index 6e4fbeab2e85..d0c38a3eebe5 100644
--- a/website/pages/ar/glossary.mdx
+++ b/website/pages/ar/glossary.mdx
@@ -42,7 +42,7 @@ title: قائمة المصطلحات
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: قائمة المصطلحات
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 

From c5dcd6457e2fc2fcd735145e5e02c23945d01546 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:05 -0500
Subject: [PATCH 0613/3820] New translations glossary.mdx (Czech)

---
 website/pages/cs/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/cs/glossary.mdx b/website/pages/cs/glossary.mdx
index 5e3859945744..989593321b53 100644
--- a/website/pages/cs/glossary.mdx
+++ b/website/pages/cs/glossary.mdx
@@ -42,7 +42,7 @@ title: Glosář
 
 - **Alokace**: Indexátor může přidělit svůj celkový podíl GRT (včetně podílu delegátů) na podgrafy, které byly zveřejněny v decentralizované síti Graf. Alokace mohou mít různé stavy:
 
-  1. **Aktivní**: Alokace je považována za aktivní, když je vytvořena v řetězci. Tomu se říká otevření alokace a signalizuje síti, že indexátor aktivně indexuje a obsluhuje dotazy pro daný podgraf. Aktivní alokace získávají odměny za indexování úměrné signálu na podgrafu a množství alokovaného GRT.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glosář
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **Klient grafu**: Knihovna pro decentralizované vytváření dapps na bázi GraphQL.
 

From 01a3770b7248cf60fd84651ae29ec0d0d583ee4d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:06 -0500
Subject: [PATCH 0614/3820] New translations glossary.mdx (German)

---
 website/pages/de/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/glossary.mdx b/website/pages/de/glossary.mdx
index bdeff7281023..fa813b659730 100644
--- a/website/pages/de/glossary.mdx
+++ b/website/pages/de/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 

From 6b97f891999046bb4e94f92db20403644e9caaec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:08 -0500
Subject: [PATCH 0615/3820] New translations glossary.mdx (Italian)

---
 website/pages/it/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/it/glossary.mdx b/website/pages/it/glossary.mdx
index bdeff7281023..fa813b659730 100644
--- a/website/pages/it/glossary.mdx
+++ b/website/pages/it/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 

From 46ede5c437d594112d0a90e304c71027e0f5876e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:09 -0500
Subject: [PATCH 0616/3820] New translations glossary.mdx (Japanese)

---
 website/pages/ja/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ja/glossary.mdx b/website/pages/ja/glossary.mdx
index ced046d1391e..7cd92418675d 100644
--- a/website/pages/ja/glossary.mdx
+++ b/website/pages/ja/glossary.mdx
@@ -42,7 +42,7 @@ title: 用語集
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **アクティブ**：アロケーションは、オンチェーンで作成されたときにアクティブとみなされます。これはアロケーションを開くと呼ばれ、インデクサーが特定のサブグラフのために積極的にインデックスを作成し、クエリを提供していることをネットワークに示しています。アクティブなアロケーションは、サブグラフ上のシグナルと割り当てられたGRTの量に比例してインデックス作成報酬を発生させます。
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: 用語集
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **グラフクライアント**：GraphQLベースのDappsを分散的に構築するためのライブラリです。
 

From 2e58947740310a1d214a08585d8d0bd3fa8ad2a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:10 -0500
Subject: [PATCH 0617/3820] New translations glossary.mdx (Korean)

---
 website/pages/ko/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ko/glossary.mdx b/website/pages/ko/glossary.mdx
index bdeff7281023..fa813b659730 100644
--- a/website/pages/ko/glossary.mdx
+++ b/website/pages/ko/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 

From 7ce267b9c62c2469a843d3a25a8d29c0869ede03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:11 -0500
Subject: [PATCH 0618/3820] New translations glossary.mdx (Dutch)

---
 website/pages/nl/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/nl/glossary.mdx b/website/pages/nl/glossary.mdx
index bdeff7281023..fa813b659730 100644
--- a/website/pages/nl/glossary.mdx
+++ b/website/pages/nl/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 

From a919596d95627c32ea6492f58df92990ec012006 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:12 -0500
Subject: [PATCH 0619/3820] New translations glossary.mdx (Polish)

---
 website/pages/pl/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pl/glossary.mdx b/website/pages/pl/glossary.mdx
index bdeff7281023..fa813b659730 100644
--- a/website/pages/pl/glossary.mdx
+++ b/website/pages/pl/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 

From 056d0ab8f6ea20477f9de8c276a5b8072cb8399e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:13 -0500
Subject: [PATCH 0620/3820] New translations glossary.mdx (Portuguese)

---
 website/pages/pt/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pt/glossary.mdx b/website/pages/pt/glossary.mdx
index e7442f46ccba..e7849c50836b 100644
--- a/website/pages/pt/glossary.mdx
+++ b/website/pages/pt/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossário
 
 - **Alocação**: Um indexador pode alocar o seu stake total em GRT (incluindo o stake dos Delegantes) em subgraphs editados na rede descentralizada do The Graph. As alocações podem ter estados diferentes:
 
-  1. **Ativa**: Uma alocação é considerada ativa quando é criada on-chain. Isto se chama abrir de uma alocação, e indica à rede que o Indexador está a indexar e servir consultas ativamente para um subgraph particular. Alocações ativas acumulam recompensas de indexação proporcionais ao sinal no subgraph, e à quantidade de GRT alocada.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossário
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: Uma biblioteca para construir dApps baseados em GraphQL de maneira descentralizada.
 

From 49fd0b5b162113907a473b70bac76509670c38dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:14 -0500
Subject: [PATCH 0621/3820] New translations glossary.mdx (Russian)

---
 website/pages/ru/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ru/glossary.mdx b/website/pages/ru/glossary.mdx
index bdeff7281023..fa813b659730 100644
--- a/website/pages/ru/glossary.mdx
+++ b/website/pages/ru/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 

From 185cd3ffac1d8ded711fb9a7c41020bd539745b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:15 -0500
Subject: [PATCH 0622/3820] New translations glossary.mdx (Swedish)

---
 website/pages/sv/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sv/glossary.mdx b/website/pages/sv/glossary.mdx
index fffe4b8e1ef7..822091ade7a1 100644
--- a/website/pages/sv/glossary.mdx
+++ b/website/pages/sv/glossary.mdx
@@ -42,7 +42,7 @@ title: Ordlista
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Aktiv**: En allokering anses vara aktiv när den skapas på kedjan. Detta kallas att öppna en allokering och indikerar för nätverket att Indexer aktivt indexerar och betjänar frågor för en särskild subgraf. Aktiva allokeringar ackumulerar indexbelöningar proportionellt mot signalen på subgrafen och mängden GRT som allokerats.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Ordlista
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Klient**: Ett bibliotek för att bygga decentraliserade dappar baserade på GraphQL.
 

From c7bad2b3f64547af756d00582b9cc4b423aad542 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:16 -0500
Subject: [PATCH 0623/3820] New translations glossary.mdx (Turkish)

---
 website/pages/tr/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/glossary.mdx b/website/pages/tr/glossary.mdx
index 9c7b1781c257..b7b62807139b 100644
--- a/website/pages/tr/glossary.mdx
+++ b/website/pages/tr/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Aktif**: Bir tahsis, zincir üzerinde oluşturulduğunda aktif kabul edilir. Buna tahsis açma denir ve ağa, indeksleyicinin belirli bir subgraph için sorguları aktif olarak indekslediğini ve sunduğunu gösterir. Aktif tahsisler, subgraph'teki sinyal ve tahsis edilen GRT miktarı ile orantılı olarak indeksleme ödülleri tahakkuk ettirir.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **Graph Tüketicileri**: Merkeziyetsiz bir şekilde GraphQL tabanlı merkeziyetsiz uygulamalar inşa etmeye yönelik bir kitaplık.
 

From e6a9a05fd7007966fb3b1313188ef0ae53d4d240 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:18 -0500
Subject: [PATCH 0624/3820] New translations glossary.mdx (Ukrainian)

---
 website/pages/uk/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/uk/glossary.mdx b/website/pages/uk/glossary.mdx
index 162a88d424e0..c9d8466bb06a 100644
--- a/website/pages/uk/glossary.mdx
+++ b/website/pages/uk/glossary.mdx
@@ -42,7 +42,7 @@ title: Глосарій
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Активний**: Розподіл вважається активним, коли він створюється всередині мережі. Це називається відкриттям розподілу і вказує мережі на те, що індексатор активно індексує та обслуговує запити для конкретного підграфа. При активному розподілі нараховується винагорода за індексацію пропорційно до кількості сигналів на підграфі та суми розподілених GRT токенів.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Глосарій
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **Клієнт The Graph**: Бібліотека для децентралізованого створення додатків на основі GraphQL.
 

From a2c80e969bccdb62a2d299314b0181b723559110 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:19 -0500
Subject: [PATCH 0625/3820] New translations glossary.mdx (Chinese Simplified)

---
 website/pages/zh/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/glossary.mdx b/website/pages/zh/glossary.mdx
index 99305cea1b15..c46748d7f745 100644
--- a/website/pages/zh/glossary.mdx
+++ b/website/pages/zh/glossary.mdx
@@ -42,7 +42,7 @@ title: 术语汇编
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: 分配在链上创建时被认为是活动的。这称为打开一个分配，并向网络表明索引人正在为特定子图建立索引并提供查询服务。主动分配的增值索引奖励与子图上的信号以及分配的 GRT 的数量成比例。
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: 术语汇编
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: 用于以去中心化方式构建基于 GraphQL 的 dapps 的库。
 

From 10c6d58a9f6d544ff6cf137a0866b700918b5182 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:20 -0500
Subject: [PATCH 0626/3820] New translations glossary.mdx (Urdu (Pakistan))

---
 website/pages/ur/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ur/glossary.mdx b/website/pages/ur/glossary.mdx
index 1b58dd720662..c5ab3b4ee98f 100644
--- a/website/pages/ur/glossary.mdx
+++ b/website/pages/ur/glossary.mdx
@@ -42,7 +42,7 @@ title: لغت
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **فعال**: ایک مختص کو فعال سمجھا جاتا ہے جب اسے آن چین بنایا جاتا ہے۔ اسے ایلوکیشن کھولنا کہا جاتا ہے، اور یہ نیٹ ورک کی طرف اشارہ کرتا ہے کہ انڈیکسر کسی خاص سب گراف کے لیے فعال طور پر انڈیکس کر رہا ہے اور کیوریز پیش کر رہا ہے۔ فعال مختصات سب گراف پر سگنل کے متناسب انڈیکسنگ انعامات اور مختص کردہ GRT کی رقم جمع کرتی ہیں.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: لغت
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **گراف کلائنٹ**: ڈیسینٹرالائزڈ طریقے سے GraphQL پر مبنی ڈیپ بنانے کے لیے ایک لائبریری.
 

From 6385edfb402a89a0a4c65df24d777dc60491032f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:21 -0500
Subject: [PATCH 0627/3820] New translations glossary.mdx (Vietnamese)

---
 website/pages/vi/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/vi/glossary.mdx b/website/pages/vi/glossary.mdx
index bdeff7281023..fa813b659730 100644
--- a/website/pages/vi/glossary.mdx
+++ b/website/pages/vi/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 

From 6cc6b3a978cf3e7515e5e2437074f6e81dd8b771 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:22 -0500
Subject: [PATCH 0628/3820] New translations glossary.mdx (Marathi)

---
 website/pages/mr/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/mr/glossary.mdx b/website/pages/mr/glossary.mdx
index 71fd8619af45..7a9ea31043a0 100644
--- a/website/pages/mr/glossary.mdx
+++ b/website/pages/mr/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **सक्रिय**: ऑन-चेन तयार केल्यावर वाटप सक्रिय मानले जाते. याला वाटप उघडणे म्हणतात, आणि नेटवर्कला सूचित करते की इंडेक्सर सक्रियपणे अनुक्रमित करत आहे आणि विशिष्ट सबग्राफसाठी क्वेरी सर्व्ह करत आहे. सक्रिय वाटप सबग्राफवरील सिग्नल आणि वाटप केलेल्या GRT रकमेच्या प्रमाणात अनुक्रमणिका बक्षिसे जमा करतात.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **द ग्राफ क्लायंट**: GraphQL-आधारित dapps विकेंद्रित पद्धतीने तयार करण्यासाठी लायब्ररी.
 

From d79e5f6e276ff70255d0d7090706af82b2c4619b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:23 -0500
Subject: [PATCH 0629/3820] New translations glossary.mdx (Hindi)

---
 website/pages/hi/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/glossary.mdx b/website/pages/hi/glossary.mdx
index 244ef6f95cdd..e1c4a99f0d1b 100644
--- a/website/pages/hi/glossary.mdx
+++ b/website/pages/hi/glossary.mdx
@@ -42,7 +42,7 @@ title: शब्दकोष
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **सक्रिय**: एक आवंटन को तब सक्रिय माना जाता है जब इसे ऑन-चेन बनाया जाता है। इसे ओपनिंग आबंटन कहा जाता है, और यह नेटवर्क को इंगित करता है कि इंडेक्सर सक्रिय रूप से अनुक्रमण कर रहा है और किसी विशेष सबग्राफ के लिए प्रश्नों की सेवा कर रहा है। सक्रिय आबंटन उप-अनुच्छेद पर संकेत के अनुपात में अनुक्रमित पुरस्कार अर्जित करते हैं, और आवंटित जीआरटी की राशि।
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **बंद**: एक Indexer एक दिए गए Subgraph पर अर्जित indexing पुरस्कारों का दावा कर सकता है, जब वह हाल का और वैध **Proof of Indexing (POI)** प्रस्तुत करता है। इसे आवंटन बंद करना कहा जाता है। एक आवंटन को बंद करने से पहले न्यूनतम एक युग के लिए खुला होना चाहिए। अधिकतम आवंटन अवधि 28 युग होती है। यदि एक Indexer 28 युगों के बाद भी आवंटन को खुला रखता है, तो इसे बासी आवंटन कहा जाता है। जब एक आवंटन **बंद** स्थिति में होता है, तो एक फिशरमैन अभी भी Indexer को झूठे डेटा की सेवा करने के लिए चुनौती देने के लिए एक विवाद खोल सकता है।
 
@@ -64,7 +64,7 @@ title: शब्दकोष
 
 - **ग्राफ़ नोड**: ग्राफ़ नोड वह घटक है जो सबग्राफ़ को इंडेक्स करता है और परिणामस्वरूप डेटा को GraphQL APIके माध्यम से क्वेरी के लिए उपलब्ध कराता है। इसलिए, यह Indexer स्टैक का केंद्रीय हिस्सा है, और ग्राफ़ नोड का सही संचालन एक सफल इंडेक्सर चलाने के लिए महत्वपूर्ण है।
 
-- **Indexer एजेंट**: इंडेक्सर एजेंट इंडेक्सर स्टैक का हिस्सा है। यह नेटवर्क पर इंडेक्सर की इंटरैक्शन को सुगम बनाता है, जिसमें नेटवर्क पर पंजीकरण, अपने Graph Node(s) पर सबग्राफ़ तैनातियों का प्रबंधन, और आवंटनों का प्रबंधन शामिल है।
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **द ग्राफ़ क्लाइंट**: विकेंद्रीकृत तरीके से ग्राफ़कॉल-आधारित डैप बनाने के लिए एक लाइब्रेरी।
 

From f4ace25690d7c65f861970706f001cd21438745d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:24 -0500
Subject: [PATCH 0630/3820] New translations glossary.mdx (Swahili)

---
 website/pages/sw/glossary.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sw/glossary.mdx b/website/pages/sw/glossary.mdx
index bdeff7281023..fa813b659730 100644
--- a/website/pages/sw/glossary.mdx
+++ b/website/pages/sw/glossary.mdx
@@ -42,7 +42,7 @@ title: Glossary
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
@@ -64,7 +64,7 @@ title: Glossary
 
 - **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
 - **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 

From f76e2bb033ccb196012914d66255ea74c7fded56 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:25 -0500
Subject: [PATCH 0631/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Romanian)

---
 .../pages/ro/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ro/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/ro/developing/substreams-powered-subgraphs-faq.mdx
index 92c6a8313a5f..052d7b093749 100644
--- a/website/pages/ro/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/ro/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From 7fe9a85042f5f67fbb9ecdf5b4b44d3a90ec634f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:27 -0500
Subject: [PATCH 0632/3820] New translations
 substreams-powered-subgraphs-faq.mdx (French)

---
 .../pages/fr/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/fr/developing/substreams-powered-subgraphs-faq.mdx
index b5510cf7441c..209b63e763f4 100644
--- a/website/pages/fr/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/fr/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ Si vous êtes déjà familiarisé avec le développement de subgraphs, notez que
 
 ## En quoi les subgraphs alimentés par les courants secondaires sont-ils différents des subgraphs ?
 
-Les subgraphs sont constitués de sources de données qui spécifient les événements de la chaîne et la manière dont ces événements doivent être traités par des gestionnaires écrits en Assemblyscript. Ces événements sont traités de manière séquentielle, en fonction de l'ordre dans lequel ils se produisent dans la chaîne.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-En revanche, les subgraphs alimentés par des flux secondaires disposent d'une source de données unique référençant un paquet de flux secondaires, qui est traité par le nœud de graphe. Les subgraphs ont accès à des données granulaires supplémentaires sur la chaîne par rapport aux subgraphs conventionnels et peuvent également bénéficier d'un traitement massivement parallélisé, ce qui peut se traduire par des temps de traitement beaucoup plus rapides.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## Quels sont les avantages de l'utilisation de subgraphs alimentés par des courants descendants ?
 

From 91a7dfc61549bef54a908202d2e243a876ef11fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:28 -0500
Subject: [PATCH 0633/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Spanish)

---
 .../pages/es/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/es/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/es/developing/substreams-powered-subgraphs-faq.mdx
index 92c6a8313a5f..052d7b093749 100644
--- a/website/pages/es/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/es/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From 9e31397ab4b01adaaa7ef4117bbfe4abac17ac3f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:29 -0500
Subject: [PATCH 0634/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Arabic)

---
 .../pages/ar/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ar/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/ar/developing/substreams-powered-subgraphs-faq.mdx
index d46783a1f7e3..3d24021d2c86 100644
--- a/website/pages/ar/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/ar/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an ex
 
 ## كيف تختلف الغرافات الفرعية التي تعمل بسبستريمز عن الغرافات الفرعية؟
 
-الغرافات الفرعية تتكون من مصادر البيانات التي تحدد الأحداث على السلسلة وكيف ينبغي تحويل تلك الأحداث من خلال معالجات مكتوبة بـلغة أسمبلي اسكريبت. يتم معالجة هذه الأحداث بتسلسل، استناداً إلى ترتيب حدوث الأحداث على السلسلة.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-على نقيض ذلك، تحتوي الغرافات الفرعية المدعومة بسبستريمز على مصدر بيانات واحد يشير إلى حزمة سبستريمز، والتي يتم معالجتها بواسطة نقطة الغراف. تتيح سبستريمز الوصول إلى بيانات إضافية على السلسلة مقارنةً بالغرافات الفرعية التقليدية، ويمكن أيضاً للعمليات الموازية الضخمة أن توفر أوقات معالجة أسرع بكثير.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## ما هي فوائد استخدام الغرافات الفرعية المدعومة بسبستريمز؟
 

From 596183dc1dba4648eaaa01303f1503de80f2d78d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:30 -0500
Subject: [PATCH 0635/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Czech)

---
 .../pages/cs/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/cs/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/cs/developing/substreams-powered-subgraphs-faq.mdx
index 330cafa3d2d5..8d318d2f9ae0 100644
--- a/website/pages/cs/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/cs/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ Pokud jste již obeznámeni s vývojem podgrafů, pak vězte, že na podgrafy vy
 
 ## Jak se liší substream, které jsou napájeny podgrafy, od podgrafů?
 
-Podgrafy jsou tvořeny datovými zdroji, které určují události v řetězci a způsob, jakým mají být tyto události transformovány prostřednictvím obslužných programů napsaných v jazyce Assemblyscript. Tyto události jsou zpracovávány postupně podle pořadí, v jakém k nim v řetězci dochází.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-Naproti tomu podgrafy napájené substreamy mají jediný zdroj dat, který odkazuje na balíček substreamů, který zpracovává uzel Graf. Substreamy mají ve srovnání s běžnými podgrafy přístup k dalším granulárním datům v řetězci a mohou také využívat výhod masivně paralelizovaného zpracování, což může znamenat mnohem rychlejší časy zpracování.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## Jaké jsou výhody používání substreamu, které jsou založeny na podgraf?
 

From b91f418cec6027ad3299932bc4a4257be8d13676 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:31 -0500
Subject: [PATCH 0636/3820] New translations
 substreams-powered-subgraphs-faq.mdx (German)

---
 .../pages/de/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/de/developing/substreams-powered-subgraphs-faq.mdx
index 92c6a8313a5f..052d7b093749 100644
--- a/website/pages/de/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/de/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From cd3da440f75415e2b51f205f4a05b299da3544f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:32 -0500
Subject: [PATCH 0637/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Italian)

---
 .../pages/it/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/it/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/it/developing/substreams-powered-subgraphs-faq.mdx
index 92c6a8313a5f..052d7b093749 100644
--- a/website/pages/it/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/it/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From 0ddc5572907ab8cdf7b8f865216c932108bae23a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:33 -0500
Subject: [PATCH 0638/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Japanese)

---
 .../pages/ja/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ja/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/ja/developing/substreams-powered-subgraphs-faq.mdx
index b1f97753e12f..09e639d8677e 100644
--- a/website/pages/ja/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/ja/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an ex
 
 ## サブストリームを利用したサブグラフはサブグラフとどう違うのでしょうか?
 
-サブグラフは、オンチェーン イベントと、それらのイベントが Assemblyscript で記述されたハンドラーを介して変換される方法を指定するデータソースで構成されます。これらのイベントは、チェーン上でイベントが発生する順序に基づいて、順番に処理されます。
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-一方、Substreamsで動作するサブグラフは、Substreamsパッケージを参照する単一のデータソースを持ち、これはGraph Nodeによって処理されます。従来のサブグラフと比較して、Substreamsはより細かい粒度のオンチェーンデータにアクセスでき、また、大規模な並列処理の恩恵も受けることができます。これにより、処理時間が大幅に短縮される可能性があります。
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## サブストリームを利用したサブグラフを使用する利点は何ですか?
 

From 348969d1a90b4745c02f198efaa2dcd62d793d48 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:35 -0500
Subject: [PATCH 0639/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Korean)

---
 .../pages/ko/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ko/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/ko/developing/substreams-powered-subgraphs-faq.mdx
index 92c6a8313a5f..052d7b093749 100644
--- a/website/pages/ko/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/ko/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From e5e475c96bc3e83f721cdc05b5bf2527d2e0616e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:36 -0500
Subject: [PATCH 0640/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Dutch)

---
 .../pages/nl/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/nl/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/nl/developing/substreams-powered-subgraphs-faq.mdx
index 92c6a8313a5f..052d7b093749 100644
--- a/website/pages/nl/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/nl/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From 57fedc9ccedcd1b9b844c1ad85f5c42e9c1080c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:37 -0500
Subject: [PATCH 0641/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Polish)

---
 .../pages/pl/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pl/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/pl/developing/substreams-powered-subgraphs-faq.mdx
index 92c6a8313a5f..052d7b093749 100644
--- a/website/pages/pl/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/pl/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From f3a7d786e97d7b31c1df9b69266810f9b946b446 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:38 -0500
Subject: [PATCH 0642/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Portuguese)

---
 .../pages/pt/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pt/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/pt/developing/substreams-powered-subgraphs-faq.mdx
index 5fc4b8f0c2f6..53cfc42c03b7 100644
--- a/website/pages/pt/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/pt/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ Se você já for familiar com a programação de subgraphs, então note que subg
 
 ## Como subgraphs movidos a Substreams são diferentes de subgraphs?
 
-Subgraphs são compostos de fontes de dados que especificam eventos on-chain, e como estes eventos devem ser transformados através de handlers escritos em AssemblyScript. Estes eventos são processados em sequência, com base na ordem na qual eventos acontecem na chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-Ao contrário, subgraphs movidos a substreams têm uma única fonte de dados que referencia um pacote de substreams, processado pelo Graph Node. Substreams têm acesso a mais dados granulares on-chain em comparação a subgraphs convencionais, e também podem se beneficiar de um processamento paralelizado em massa, o que pode resultar em tempos de processamento muito mais rápidos.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## Quais os benefícios do uso de subgraphs movidos a Substreams?
 

From f9b5aa2cab25c3cd861151c7a481c7bc29bc92ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:39 -0500
Subject: [PATCH 0643/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Swedish)

---
 .../pages/sv/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sv/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/sv/developing/substreams-powered-subgraphs-faq.mdx
index 4bca0c8caada..b729492bcbf3 100644
--- a/website/pages/sv/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/sv/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ Om du redan är bekant med utveckling av subgrafer kan du notera att Substreams-
 
 ## Hur skiljer sig Substreams-drivna subgrafer från subgrafer?
 
-Subgrafer består av datakällor som specificerar händelser på blockkedjan och hur dessa händelser ska omvandlas via hanterare skrivna i AssemblyScript. Dessa händelser bearbetas sekventiellt, baserat på ordningen som händelserna inträffar på blockkedjan.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-Å andra sidan har Substreams-drivna subgrafer en enda datakälla som refererar till ett Substreams-paket, vilket bearbetas av Graph Node. Substreams har tillgång till ytterligare detaljerade on-chain data jämfört med konventionella subgrafer och kan även dra nytta av massivt parallell bearbetning, vilket kan leda till betydligt snabbare bearbetningstider.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## Vilka fördelar har användning av Substreams-drivna subgrafer?
 

From 6b05f5d135c458aa842abd4dc4e08f9cf86c51ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:39 -0500
Subject: [PATCH 0644/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Ukrainian)

---
 .../pages/uk/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/uk/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/uk/developing/substreams-powered-subgraphs-faq.mdx
index 92c6a8313a5f..052d7b093749 100644
--- a/website/pages/uk/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/uk/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From 51ec55d34c146b7ff9aee0e4952ef1e943ec017f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:41 -0500
Subject: [PATCH 0645/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Chinese Simplified)

---
 .../pages/zh/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/zh/developing/substreams-powered-subgraphs-faq.mdx
index 3a9a4b0fe654..9ac98651b7a1 100644
--- a/website/pages/zh/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/zh/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ Go to the [Substreams Documentation](/substreams) to learn more about Substreams
 
 ## 基于Substreams的子图和普通子图有什么区别？
 
-子图由数据源组成，这些数据源指定了在链上发生的事件以及通过用Assemblyscript编写的处理程序应如何转换这些事件。这些事件按照链上发生事件的顺序依次进行处理。
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-相比之下，由Substreams支持的子图具有单一数据源，该数据源引用一个Substreams包，由图节点进行处理。与传统的子图相比，Substreams可以访问更多精细的链上数据，并且还可以从大规模并行处理中获益，这可能意味着处理时间更快。
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## 使用基于Substeams的子图的优势是什么？
 

From aed9740bf203339a3d9a3031399745019c231018 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:42 -0500
Subject: [PATCH 0646/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Urdu (Pakistan))

---
 .../pages/ur/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ur/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/ur/developing/substreams-powered-subgraphs-faq.mdx
index ff87c267315c..66939013c46e 100644
--- a/website/pages/ur/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/ur/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an ex
 
 ## سب سٹریمز سے چلنے والے سب گرافس سب گراف سے کیسے مختلف ہیں؟
 
-سب گرافس ڈیٹا سورسز پر مشتمل ہوتے ہیں جو آن چین ایونٹس کی وضاحت کرتے ہیں، اور ان واقعات کو اسمبلی اسکرپٹ میں لکھے گئے ہینڈلرز کے ذریعے کیسے تبدیل کیا جانا چاہیے۔ ان واقعات پر ترتیب وار کارروائی کی جاتی ہے، اس ترتیب کی بنیاد پر جس میں ایونٹس آن چین ہوتے ہیں.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-اس کے برعکس، سب سٹریمز سے چلنے والے سب گرافس میں ایک واحد ڈیٹا سورس ہوتا ہے جو سب سٹریم پیکیج کا حوالہ دیتا ہے، جس پر گراف نوڈ کے ذریعے کارروائی کی جاتی ہے۔ روایتی سب گرافس کے مقابلے سب سٹریمز کو اضافی دانے دار آن چین ڈیٹا تک رسائی حاصل ہے، اور یہ بڑے پیمانے پر متوازی پروسیسنگ سے بھی فائدہ اٹھا سکتے ہیں، جس کا مطلب بہت تیز پروسیسنگ کے اوقات ہو سکتا ہے.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## سب سٹریمز سے چلنے والے سب گرافس استعمال کرنے کے کیا فوائد ہیں؟
 

From 06d9046d376fdc4bc74d7d73b54846e92a3ba175 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:43 -0500
Subject: [PATCH 0647/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Vietnamese)

---
 .../pages/vi/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/vi/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/vi/developing/substreams-powered-subgraphs-faq.mdx
index 92c6a8313a5f..052d7b093749 100644
--- a/website/pages/vi/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/vi/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From 7038b029de3115d332452cbe1c1381bb5d6da001 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:44 -0500
Subject: [PATCH 0648/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Marathi)

---
 .../pages/mr/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/mr/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/mr/developing/substreams-powered-subgraphs-faq.mdx
index 92c6a8313a5f..052d7b093749 100644
--- a/website/pages/mr/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/mr/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From d2b2b2e415fd30649e40794dc38d71a00976e46b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:45 -0500
Subject: [PATCH 0649/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Hindi)

---
 .../pages/hi/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/hi/developing/substreams-powered-subgraphs-faq.mdx
index 4ac776772148..219235cf766d 100644
--- a/website/pages/hi/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/hi/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From 3f8a755969d8c9ea77ebc107af640d3d2b2864b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:46 -0500
Subject: [PATCH 0650/3820] New translations
 substreams-powered-subgraphs-faq.mdx (Swahili)

---
 .../pages/sw/developing/substreams-powered-subgraphs-faq.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sw/developing/substreams-powered-subgraphs-faq.mdx b/website/pages/sw/developing/substreams-powered-subgraphs-faq.mdx
index 92c6a8313a5f..052d7b093749 100644
--- a/website/pages/sw/developing/substreams-powered-subgraphs-faq.mdx
+++ b/website/pages/sw/developing/substreams-powered-subgraphs-faq.mdx
@@ -16,9 +16,9 @@ If you are already familiar with subgraph development, then note that Substreams
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify on-chain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen on-chain.
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular on-chain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 
 ## What are the benefits of using Substreams-powered subgraphs?
 

From edb6926610b41300becd42f1290575ed591e16fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:47 -0500
Subject: [PATCH 0651/3820] New translations tap.mdx (Romanian)

---
 website/pages/ro/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/tap.mdx b/website/pages/ro/tap.mdx
index 3e8185186982..3d6bbed374a9 100644
--- a/website/pages/ro/tap.mdx
+++ b/website/pages/ro/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From 9c08905557eb61909bad27109523822f52a87beb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:48 -0500
Subject: [PATCH 0652/3820] New translations tap.mdx (French)

---
 website/pages/fr/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/tap.mdx b/website/pages/fr/tap.mdx
index 3430199911ab..f761ecde9c9c 100644
--- a/website/pages/fr/tap.mdx
+++ b/website/pages/fr/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From d96a1a790131f7f40de60990b4040c4b3852236c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:49 -0500
Subject: [PATCH 0653/3820] New translations tap.mdx (Spanish)

---
 website/pages/es/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/tap.mdx b/website/pages/es/tap.mdx
index 2f0b75160fa9..7e0fd50843c6 100644
--- a/website/pages/es/tap.mdx
+++ b/website/pages/es/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From 47dd0b731f93276fb8a0e40e28dcd33739fea678 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:50 -0500
Subject: [PATCH 0654/3820] New translations tap.mdx (Arabic)

---
 website/pages/ar/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/tap.mdx b/website/pages/ar/tap.mdx
index 0cef5f4209fa..e5d5a7539362 100644
--- a/website/pages/ar/tap.mdx
+++ b/website/pages/ar/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From e4624e5b6bec5174dab51904a3d0a6ca97b73436 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:52 -0500
Subject: [PATCH 0655/3820] New translations tap.mdx (Czech)

---
 website/pages/cs/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/tap.mdx b/website/pages/cs/tap.mdx
index 6594ce05e1f5..a33187536c3f 100644
--- a/website/pages/cs/tap.mdx
+++ b/website/pages/cs/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From 3732dacbb788ac1dd9b5639960847a25ce8f3e9b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:53 -0500
Subject: [PATCH 0656/3820] New translations tap.mdx (German)

---
 website/pages/de/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/tap.mdx b/website/pages/de/tap.mdx
index c259f0dbbf32..5adfff3c1ad6 100644
--- a/website/pages/de/tap.mdx
+++ b/website/pages/de/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From 87a2cbd0f0ba2778e2de3099dfd13bd3867f7de4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:54 -0500
Subject: [PATCH 0657/3820] New translations tap.mdx (Italian)

---
 website/pages/it/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/tap.mdx b/website/pages/it/tap.mdx
index ed40e829a2cb..4123949414ee 100644
--- a/website/pages/it/tap.mdx
+++ b/website/pages/it/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From d5370a97a33e761516ea48a960fe73eeb0c3e241 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:55 -0500
Subject: [PATCH 0658/3820] New translations tap.mdx (Japanese)

---
 website/pages/ja/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/tap.mdx b/website/pages/ja/tap.mdx
index ab14dd962926..75f8c505baeb 100644
--- a/website/pages/ja/tap.mdx
+++ b/website/pages/ja/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From c67c0d37ed0a379700d43af06322ffb77893bc95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:56 -0500
Subject: [PATCH 0659/3820] New translations tap.mdx (Korean)

---
 website/pages/ko/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/tap.mdx b/website/pages/ko/tap.mdx
index 3e8185186982..3d6bbed374a9 100644
--- a/website/pages/ko/tap.mdx
+++ b/website/pages/ko/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From 31017195e2c0886b5069bbc576c8f3b002ea1d3e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:57 -0500
Subject: [PATCH 0660/3820] New translations tap.mdx (Dutch)

---
 website/pages/nl/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/tap.mdx b/website/pages/nl/tap.mdx
index 3e8185186982..3d6bbed374a9 100644
--- a/website/pages/nl/tap.mdx
+++ b/website/pages/nl/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From d6931900f734482ad07c7a2da592aa3f11a9c975 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:58 -0500
Subject: [PATCH 0661/3820] New translations tap.mdx (Polish)

---
 website/pages/pl/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/tap.mdx b/website/pages/pl/tap.mdx
index 3e8185186982..3d6bbed374a9 100644
--- a/website/pages/pl/tap.mdx
+++ b/website/pages/pl/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From 126f66e1727afc84861a1c31831b90638e26e0d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:25:59 -0500
Subject: [PATCH 0662/3820] New translations tap.mdx (Portuguese)

---
 website/pages/pt/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/tap.mdx b/website/pages/pt/tap.mdx
index c2fefbdd9694..edf2cc893395 100644
--- a/website/pages/pt/tap.mdx
+++ b/website/pages/pt/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From 8e06f5d4b7bda2df60b10d7c0a824328a98dada4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:00 -0500
Subject: [PATCH 0663/3820] New translations tap.mdx (Russian)

---
 website/pages/ru/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/tap.mdx b/website/pages/ru/tap.mdx
index 699d25f0f1b5..6396d1f342b8 100644
--- a/website/pages/ru/tap.mdx
+++ b/website/pages/ru/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From 30348df2c6e46b034a4eff1a14bbf49cc618ecfa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:01 -0500
Subject: [PATCH 0664/3820] New translations tap.mdx (Swedish)

---
 website/pages/sv/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/tap.mdx b/website/pages/sv/tap.mdx
index d55093c0862e..e7fbfe81ee15 100644
--- a/website/pages/sv/tap.mdx
+++ b/website/pages/sv/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From 28815bff281cab6b84a93dfc22a0d6d6ed6d699a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:02 -0500
Subject: [PATCH 0665/3820] New translations tap.mdx (Turkish)

---
 website/pages/tr/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/tap.mdx b/website/pages/tr/tap.mdx
index cdee8f3f9111..68583902ea01 100644
--- a/website/pages/tr/tap.mdx
+++ b/website/pages/tr/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From cc066572720f5edf72b19433c34c946a33df83c6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:03 -0500
Subject: [PATCH 0666/3820] New translations tap.mdx (Ukrainian)

---
 website/pages/uk/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/tap.mdx b/website/pages/uk/tap.mdx
index 3e8185186982..3d6bbed374a9 100644
--- a/website/pages/uk/tap.mdx
+++ b/website/pages/uk/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From 8dbe04cb3ad4f0bc1bb2e8c3da2e8829e95591d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:04 -0500
Subject: [PATCH 0667/3820] New translations tap.mdx (Chinese Simplified)

---
 website/pages/zh/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/tap.mdx b/website/pages/zh/tap.mdx
index a91191795f03..59cd6091b56c 100644
--- a/website/pages/zh/tap.mdx
+++ b/website/pages/zh/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From cdb3bbeedf9e596b79fd7865379569792ae5c5d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:05 -0500
Subject: [PATCH 0668/3820] New translations tap.mdx (Urdu (Pakistan))

---
 website/pages/ur/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/tap.mdx b/website/pages/ur/tap.mdx
index 44b46f2e5fc7..f1ceea57be32 100644
--- a/website/pages/ur/tap.mdx
+++ b/website/pages/ur/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From c24d89545781adeffec5a5584b7b658f89aeef7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:07 -0500
Subject: [PATCH 0669/3820] New translations tap.mdx (Vietnamese)

---
 website/pages/vi/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/tap.mdx b/website/pages/vi/tap.mdx
index 63b32fa831f6..0e7f958d5bf9 100644
--- a/website/pages/vi/tap.mdx
+++ b/website/pages/vi/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From c160617e39a131bf42eedd50b643ee698d1873b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:08 -0500
Subject: [PATCH 0670/3820] New translations tap.mdx (Marathi)

---
 website/pages/mr/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/tap.mdx b/website/pages/mr/tap.mdx
index 47cb3cbcee00..b35022d34447 100644
--- a/website/pages/mr/tap.mdx
+++ b/website/pages/mr/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From 9c42e87561f1abdafa2a4ed7d0386103522e3063 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:09 -0500
Subject: [PATCH 0671/3820] New translations tap.mdx (Swahili)

---
 website/pages/sw/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/tap.mdx b/website/pages/sw/tap.mdx
index 3e8185186982..3d6bbed374a9 100644
--- a/website/pages/sw/tap.mdx
+++ b/website/pages/sw/tap.mdx
@@ -9,7 +9,7 @@ Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, T
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 
 - Efficiently handles micropayments.
-- Adds a layer of consolidations to on-chain transactions and costs.
+- Adds a layer of consolidations to onchain transactions and costs.
 - Allows Indexers control of receipts and payments, guaranteeing payment for queries.
 - It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
 

From e4ac48a8b0254e798e395fa21fbc76976190ab77 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:10 -0500
Subject: [PATCH 0672/3820] New translations deploy-using-subgraph-studio.mdx
 (Romanian)

---
 website/pages/ro/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ro/deploying/deploy-using-subgraph-studio.mdx b/website/pages/ro/deploying/deploy-using-subgraph-studio.mdx
index d8bb14e9f3c1..1c8e177ef6c5 100644
--- a/website/pages/ro/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/ro/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 7c93675cfa090d19a2a57b1dc29c462b4eb1fa03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:11 -0500
Subject: [PATCH 0673/3820] New translations deploy-using-subgraph-studio.mdx
 (French)

---
 website/pages/fr/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/deploying/deploy-using-subgraph-studio.mdx b/website/pages/fr/deploying/deploy-using-subgraph-studio.mdx
index 2d1dba965948..779b461469be 100644
--- a/website/pages/fr/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/fr/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Déploiement en utilisant Subgraph Studio
 
 Apprenez à déployer votre subgraph sur Subgraph Studio.
 
-> Note : Lorsque vous déployez un subgraph, vous le poussez vers Subgraph Studio, où vous pourrez le tester. Il est important de se rappeler que déployer n'est pas la même chose que publier. Lorsque vous publiez un subgraph, vous le publiez sur la blockchain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Présentation de Subgraph Studio
 
@@ -124,7 +124,7 @@ Si vous souhaitez mettre à jour votre subgraph, vous pouvez faire ce qui suit :
 - Une fois que vous en êtes satisfait, vous pouvez publier votre nouveau déploiement sur [Graph Explorer](https://thegraph.com/explorer).
 - Cette action créera une nouvelle version de votre subgraph sur laquelle les Curateurs pourront commencer à signaler et que les Indexeurs pourront indexer.
 
-Vous pouvez également mettre à jour les métadonnées de votre subgraph sans publier une nouvelle version. Vous pouvez mettre à jour les détails de votre subgraph dans Studio (sous la photo de profil, le nom, la description, etc.) en cochant une option appelée **Update Details** dans [Graph Explorer](https://thegraph.com/explorer). Si cette option est cochée, une transaction sera générée sur la blockchain (on-chain) pour mettre à jour les détails du subgraph dans Explorer sans avoir à publier une nouvelle version avec un nouveau déploiement.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Remarque : Il y a des coûts associés à la publication d'une nouvelle version d'un subgraph sur le réseau. En plus des frais de transaction, vous devez également financer une partie de la taxe de curation sur le signal d'auto-migration . Vous ne pouvez pas publier une nouvelle version de votre subgraph si les Curateurs n'ont pas signalé dessus. Pour plus d'informations, veuillez lire plus [ici](/network/curating/).
 

From f31492c004539815e4ba98f3df8e37de29e81e4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:12 -0500
Subject: [PATCH 0674/3820] New translations deploy-using-subgraph-studio.mdx
 (Spanish)

---
 website/pages/es/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/es/deploying/deploy-using-subgraph-studio.mdx b/website/pages/es/deploying/deploy-using-subgraph-studio.mdx
index 1ea90990a2d9..920714a60353 100644
--- a/website/pages/es/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/es/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 1c1e159921a86a3dffa584dbbb10fdb88947a110 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:13 -0500
Subject: [PATCH 0675/3820] New translations deploy-using-subgraph-studio.mdx
 (Arabic)

---
 website/pages/ar/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ar/deploying/deploy-using-subgraph-studio.mdx b/website/pages/ar/deploying/deploy-using-subgraph-studio.mdx
index f20a1567749c..884dd06879ff 100644
--- a/website/pages/ar/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/ar/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 980d83ae1d14caeddbc396597311be067d4b171d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:14 -0500
Subject: [PATCH 0676/3820] New translations deploy-using-subgraph-studio.mdx
 (Czech)

---
 website/pages/cs/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/cs/deploying/deploy-using-subgraph-studio.mdx b/website/pages/cs/deploying/deploy-using-subgraph-studio.mdx
index 160322951c6f..88dd05772565 100644
--- a/website/pages/cs/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/cs/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From ea061b99019251bfdf7a8282b26affc0fc8c90ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:15 -0500
Subject: [PATCH 0677/3820] New translations deploy-using-subgraph-studio.mdx
 (German)

---
 website/pages/de/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/deploying/deploy-using-subgraph-studio.mdx b/website/pages/de/deploying/deploy-using-subgraph-studio.mdx
index 6b2f6a058019..d96a22a116c7 100644
--- a/website/pages/de/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/de/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Bereitstellung mit Subgraph Studio
 
 Erfahren Sie, wie Sie Ihren Subgraph in Subgraph Studio bereitstellen können.
 
-> Hinweis: Wenn Sie einen Subgraph bereitstellen, schieben Sie ihn zu Subgraph Studio, wo Sie ihn testen können. Es ist wichtig zu wissen, dass Bereitstellen nicht dasselbe ist wie Veröffentlichen. Wenn Sie einen Subgraph veröffentlichen, dann veröffentlichen Sie ihn in der Kette.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Überblick
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 0e0e5f748647dac568f08c73631de5eeb5c969fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:16 -0500
Subject: [PATCH 0678/3820] New translations deploy-using-subgraph-studio.mdx
 (Italian)

---
 website/pages/it/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/it/deploying/deploy-using-subgraph-studio.mdx b/website/pages/it/deploying/deploy-using-subgraph-studio.mdx
index 5d36bc2e669a..f76118a199dd 100644
--- a/website/pages/it/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/it/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From bf49a4ff409e5f805c4d836f74d0ba28b8215594 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:17 -0500
Subject: [PATCH 0679/3820] New translations deploy-using-subgraph-studio.mdx
 (Japanese)

---
 website/pages/ja/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ja/deploying/deploy-using-subgraph-studio.mdx b/website/pages/ja/deploying/deploy-using-subgraph-studio.mdx
index 0a867171a0c3..6e90844458e2 100644
--- a/website/pages/ja/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/ja/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From c14ecfdc0c621bfba425618abb97be8e59ca4bef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:18 -0500
Subject: [PATCH 0680/3820] New translations deploy-using-subgraph-studio.mdx
 (Korean)

---
 website/pages/ko/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ko/deploying/deploy-using-subgraph-studio.mdx b/website/pages/ko/deploying/deploy-using-subgraph-studio.mdx
index a3b2f150a79c..cb3badff5d1b 100644
--- a/website/pages/ko/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/ko/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 517a7b93d80a63bdaaf9804019d7123d5a29cff8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:19 -0500
Subject: [PATCH 0681/3820] New translations deploy-using-subgraph-studio.mdx
 (Dutch)

---
 website/pages/nl/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/nl/deploying/deploy-using-subgraph-studio.mdx b/website/pages/nl/deploying/deploy-using-subgraph-studio.mdx
index 1918c4b13f00..7d04f9cc227b 100644
--- a/website/pages/nl/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/nl/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 54b1614493deeb664059ddbd1c7258a59063dfea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:21 -0500
Subject: [PATCH 0682/3820] New translations deploy-using-subgraph-studio.mdx
 (Polish)

---
 website/pages/pl/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pl/deploying/deploy-using-subgraph-studio.mdx b/website/pages/pl/deploying/deploy-using-subgraph-studio.mdx
index 2eb14f2ab083..454503e6d8b6 100644
--- a/website/pages/pl/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/pl/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 3e2384da145e32047ba93ea209664486bbb2c80a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:22 -0500
Subject: [PATCH 0683/3820] New translations deploy-using-subgraph-studio.mdx
 (Portuguese)

---
 website/pages/pt/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pt/deploying/deploy-using-subgraph-studio.mdx b/website/pages/pt/deploying/deploy-using-subgraph-studio.mdx
index f54b8f30084a..2ce095bf2678 100644
--- a/website/pages/pt/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/pt/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 661fffcfc827ed152dcd6c9b57c7f2e5d1a3b37d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:23 -0500
Subject: [PATCH 0684/3820] New translations deploy-using-subgraph-studio.mdx
 (Russian)

---
 website/pages/ru/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ru/deploying/deploy-using-subgraph-studio.mdx b/website/pages/ru/deploying/deploy-using-subgraph-studio.mdx
index da4b08f51fa6..cf97014e72d8 100644
--- a/website/pages/ru/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/ru/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Развертывание с использованием Subgraph Studi
 
 Узнайте, как развернуть свой субграф в Subgraph Studio.
 
-> Примечание: При развертывании субграфа Вы отправляете его в Subgraph Studio, где сможете его протестировать. Важно помнить, что развертывание — это не то же самое, что публикация. При публикации субграфа Вы размещаете его на чейне.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Обзор Subgraph Studio
 
@@ -124,7 +124,7 @@ graph deploy <SUBGRAPH_SLUG>
 - Если результат Вас устроит, Вы можете опубликовать новое развертывание в [Graph Explorer](https://thegraph.com/explorer).
 - Это действие создаст новую версию вашего субграфа, о которой Кураторы смогут начать сигнализировать, а Индексаторы — индексировать.
 
-Вы также можете обновить метаданные субграфа без публикации новой версии. В Studio можно обновить данные субграфа (аватар, название, описание и т.д.), выбрав опцию **Обновить данные** в [Graph Explorer](https://thegraph.com/explorer). Если эта опция выбрана, будет сгенерирована транзакция в сети, которая обновит информацию о субграфе в Explorer без необходимости публиковать новую версию с новым развертыванием.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Примечание: Публикация новой версии субграфа в сети требует определенных затрат. Помимо комиссий за транзакцию, Вам нужно также оплатить часть кураторского сбора за авто-миграционный сигнал. Вы не сможете опубликовать новую версию субграфа, если на нее не был подан сигнал от Кураторов. Дополнительную информацию можно прочитать [здесь](/network/curating/).
 

From 5407e67d20b2aba75f9d78f6904249b2d8e148f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:24 -0500
Subject: [PATCH 0685/3820] New translations deploy-using-subgraph-studio.mdx
 (Swedish)

---
 website/pages/sv/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sv/deploying/deploy-using-subgraph-studio.mdx b/website/pages/sv/deploying/deploy-using-subgraph-studio.mdx
index fefe0f330649..a8343706b3ef 100644
--- a/website/pages/sv/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/sv/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 94acc66c5ae48d5309cdbc5333543b08ab95e2e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:25 -0500
Subject: [PATCH 0686/3820] New translations deploy-using-subgraph-studio.mdx
 (Ukrainian)

---
 website/pages/uk/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/uk/deploying/deploy-using-subgraph-studio.mdx b/website/pages/uk/deploying/deploy-using-subgraph-studio.mdx
index 8e97e86976fd..3a45c69a805a 100644
--- a/website/pages/uk/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/uk/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From aafe0ce429581c82f83abfaf240e05800c5d4f3a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:26 -0500
Subject: [PATCH 0687/3820] New translations deploy-using-subgraph-studio.mdx
 (Chinese Simplified)

---
 website/pages/zh/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/deploying/deploy-using-subgraph-studio.mdx b/website/pages/zh/deploying/deploy-using-subgraph-studio.mdx
index d3ee2203f7d3..e3c514ebdf77 100644
--- a/website/pages/zh/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/zh/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 07b7831d6b21525b657d5f95c50c44fb305cb273 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:27 -0500
Subject: [PATCH 0688/3820] New translations deploy-using-subgraph-studio.mdx
 (Urdu (Pakistan))

---
 website/pages/ur/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ur/deploying/deploy-using-subgraph-studio.mdx b/website/pages/ur/deploying/deploy-using-subgraph-studio.mdx
index ba1b86a17ed7..6e9cde585b6c 100644
--- a/website/pages/ur/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/ur/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 2ad0b8a072fa9033aee4aa018ee716c789e6f586 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:28 -0500
Subject: [PATCH 0689/3820] New translations deploy-using-subgraph-studio.mdx
 (Vietnamese)

---
 website/pages/vi/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/vi/deploying/deploy-using-subgraph-studio.mdx b/website/pages/vi/deploying/deploy-using-subgraph-studio.mdx
index 8e4333eec207..ebbbedb9727e 100644
--- a/website/pages/vi/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/vi/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 277e34b507e4acedb22ed8a4f80407abd9149069 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:29 -0500
Subject: [PATCH 0690/3820] New translations deploy-using-subgraph-studio.mdx
 (Marathi)

---
 website/pages/mr/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/mr/deploying/deploy-using-subgraph-studio.mdx b/website/pages/mr/deploying/deploy-using-subgraph-studio.mdx
index 72a5eca3d903..454ae9e97f0a 100644
--- a/website/pages/mr/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/mr/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From 089d3aaa1a55afc48150636b202a42997b0f6c62 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 18 Dec 2024 17:26:30 -0500
Subject: [PATCH 0691/3820] New translations deploy-using-subgraph-studio.mdx
 (Swahili)

---
 website/pages/sw/deploying/deploy-using-subgraph-studio.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sw/deploying/deploy-using-subgraph-studio.mdx b/website/pages/sw/deploying/deploy-using-subgraph-studio.mdx
index a3b2f150a79c..cb3badff5d1b 100644
--- a/website/pages/sw/deploying/deploy-using-subgraph-studio.mdx
+++ b/website/pages/sw/deploying/deploy-using-subgraph-studio.mdx
@@ -4,7 +4,7 @@ title: Deploy Using Subgraph Studio
 
 Learn how to deploy your subgraph to Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it on-chain.
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
 ## Subgraph Studio Overview
 
@@ -124,7 +124,7 @@ If you want to update your subgraph, you can do the following:
 - Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
 - This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an on-chain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
 
 > Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/network/curating/).
 

From b96efc72a9e5d2d184982e8460630d8b92d1cd0f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:33 -0500
Subject: [PATCH 0692/3820] New translations starting-your-subgraph.mdx
 (Romanian)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/ro/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/ro/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..4823231d9a40
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Overview
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 3c17e02c12dce089e3aa26c991c17bbcbdd94060 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:34 -0500
Subject: [PATCH 0693/3820] New translations starting-your-subgraph.mdx
 (French)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..bd3e033c26d6
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Aperçu
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 606b6dd28bb999c1dd5cc44a0a62c5ec398e18f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:35 -0500
Subject: [PATCH 0694/3820] New translations starting-your-subgraph.mdx
 (Spanish)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/es/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/es/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..76ff7db16bba
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Descripción
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 8cc4948813a7d8b07b9d3210b55e217a454ce307 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:37 -0500
Subject: [PATCH 0695/3820] New translations starting-your-subgraph.mdx
 (Arabic)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/ar/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/ar/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..8f2e787688c2
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## نظره عامة
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 0b3de2d65887b18dfe3a257032c8efb979743fab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:38 -0500
Subject: [PATCH 0696/3820] New translations starting-your-subgraph.mdx (Czech)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/cs/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/cs/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..436b407a19ba
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Přehled
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 301f9e91ac4abc8d3bb6d227a14bcea89656b50d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:39 -0500
Subject: [PATCH 0697/3820] New translations starting-your-subgraph.mdx
 (German)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..4823231d9a40
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Overview
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From ad619c4ce34125e1ca85cb5c5f1ffbca06159cb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:40 -0500
Subject: [PATCH 0698/3820] New translations starting-your-subgraph.mdx
 (Italian)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/it/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/it/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..6b6247b0ce50
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Panoramica
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 30d4955bb1813ee6c01f4c841df218514718ac17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:41 -0500
Subject: [PATCH 0699/3820] New translations starting-your-subgraph.mdx
 (Japanese)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/ja/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/ja/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..c2dcb7ad1d68
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## 概要
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 925b599c414774d6885e99cff6b324d26d81c4d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:43 -0500
Subject: [PATCH 0700/3820] New translations starting-your-subgraph.mdx
 (Korean)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/ko/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/ko/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..4823231d9a40
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Overview
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 8e02b7ce3446f8c5f049a88efba6da4804c7de42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:44 -0500
Subject: [PATCH 0701/3820] New translations starting-your-subgraph.mdx (Dutch)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/nl/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/nl/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..4823231d9a40
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Overview
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From e12b47260cae0c96fa128c43a8557d75124b4eb5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:45 -0500
Subject: [PATCH 0702/3820] New translations starting-your-subgraph.mdx
 (Polish)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/pl/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/pl/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..4823231d9a40
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Overview
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 8dfa899e7f1520d5902bf89c95cec67ec89a6d7d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:47 -0500
Subject: [PATCH 0703/3820] New translations starting-your-subgraph.mdx
 (Portuguese)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/pt/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/pt/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..1b70a2ec98ad
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Visão geral
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 6b090b6848f071dba8af51fd0e2a5ac63bd50fbc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:48 -0500
Subject: [PATCH 0704/3820] New translations starting-your-subgraph.mdx
 (Russian)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/ru/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/ru/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..8136fb559cff
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Обзор
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From f6909ecd5a07882e51505bbadcaccbfcb57c0fd1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:49 -0500
Subject: [PATCH 0705/3820] New translations starting-your-subgraph.mdx
 (Swedish)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/sv/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/sv/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..9f06ce8fcd1d
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Översikt
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 96cabadbd4cad001634dc81056e003ad3833cd60 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:50 -0500
Subject: [PATCH 0706/3820] New translations starting-your-subgraph.mdx
 (Turkish)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/tr/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/tr/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..c10f6facbb0d
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Genel Bakış
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From db49174582384662d13541d3c91bbca42946aeae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:52 -0500
Subject: [PATCH 0707/3820] New translations starting-your-subgraph.mdx
 (Ukrainian)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/uk/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/uk/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..4823231d9a40
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Overview
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 21d741d4b106fe299c8837bcca611c83a27833f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:53 -0500
Subject: [PATCH 0708/3820] New translations starting-your-subgraph.mdx
 (Chinese Simplified)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/zh/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/zh/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..d00c872abc59
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## 概述
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From b23bf6d51332f1118158c4dee2dd2f9527008312 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:55 -0500
Subject: [PATCH 0709/3820] New translations starting-your-subgraph.mdx (Urdu
 (Pakistan))

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/ur/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/ur/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..3f0d9b8cde40
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## جائزہ
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From bc2973a28664464779fc92af65d7ae038137e844 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:56 -0500
Subject: [PATCH 0710/3820] New translations starting-your-subgraph.mdx
 (Vietnamese)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/vi/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/vi/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..f7427e79c81a
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Tổng quan
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 60af5ea2cf9d3c3cbfff6fbc03b6bcbd5015e394 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:57 -0500
Subject: [PATCH 0711/3820] New translations starting-your-subgraph.mdx
 (Marathi)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/mr/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/mr/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..946093ef308b
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## सविश्लेषण
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 38af5a9bac67613e19d8f2835f8e08d11f69e8fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:58 -0500
Subject: [PATCH 0712/3820] New translations starting-your-subgraph.mdx (Hindi)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/hi/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/hi/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..8770e21dd651
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## अवलोकन
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From b35a10dd15df8a7d64ee06dc9268af13e6f37e25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 20 Dec 2024 18:20:59 -0500
Subject: [PATCH 0713/3820] New translations starting-your-subgraph.mdx
 (Swahili)

---
 .../creating/starting-your-subgraph.mdx       | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/creating/starting-your-subgraph.mdx

diff --git a/website/pages/sw/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/sw/subgraphs/developing/creating/starting-your-subgraph.mdx
new file mode 100644
index 000000000000..4823231d9a40
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -0,0 +1,23 @@
+---
+title: Starting Your Subgraph
+---
+
+## Overview
+
+The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+
+When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+
+Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+
+### Start Building
+
+Start the process and build a subgraph that matches your needs:
+
+1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
+3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
+4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
+5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+
+Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 08d4455b089721c259b17171a7b3877b4a9fc16f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:07 -0500
Subject: [PATCH 0714/3820] New translations overview.mdx (Romanian)

---
 website/pages/ro/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/ro/indexing/overview.mdx

diff --git a/website/pages/ro/indexing/overview.mdx b/website/pages/ro/indexing/overview.mdx
new file mode 100644
index 000000000000..ced5ed20026b
--- /dev/null
+++ b/website/pages/ro/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+
+GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.
+
+Indexers select subgraphs to index based on the subgraph’s curation signal, where Curators stake GRT in order to indicate which subgraphs are high-quality and should be prioritized. Consumers (eg. applications) can also set parameters for which Indexers process queries for their subgraphs and set preferences for query fee pricing.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### What is the minimum stake required to be an Indexer on the network?
+
+The minimum stake for an Indexer is currently set to 100K GRT.
+
+### What are the revenue streams for an Indexer?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### How are indexing rewards distributed?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### What is a proof of indexing (POI)?
+
+POIs are used in the network to verify that an Indexer is indexing the subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific subgraph deployment up to and including that block.
+
+### When are indexing rewards distributed?
+
+Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).
+
+### Can pending indexing rewards be monitored?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Many of the community-made dashboards include pending rewards values and they can be easily checked manually by following these steps:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### What are disputes and where can I view them?
+
+Indexer's queries and allocations can both be disputed on The Graph during the dispute period. The dispute period varies, depending on the type of dispute. Queries/attestations have 7 epochs dispute window, whereas allocations have 56 epochs. After these periods pass, disputes cannot be opened against either of allocations or queries. When a dispute is opened, a deposit of a minimum of 10,000 GRT is required by the Fishermen, which will be locked until the dispute is finalized and a resolution has been given. Fisherman are any network participants that open disputes.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- If the dispute is rejected, the GRT deposited by the Fishermen will be burned, and the disputed Indexer will not be slashed.
+- If the dispute is settled as a draw, the Fishermen's deposit will be returned, and the disputed Indexer will not be slashed.
+- If the dispute is accepted, the GRT deposited by the Fishermen will be returned, the disputed Indexer will be slashed and the Fishermen will earn 50% of the slashed GRT.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### What are query fee rebates and when are they distributed?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+
+### What is query fee cut and indexing reward cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### How do Indexers know which subgraphs to index?
+
+Indexers may differentiate themselves by applying advanced techniques for making subgraph indexing decisions but to give a general idea we'll discuss several key metrics used to evaluate subgraphs in the network:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### What are the hardware requirements?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- | :------------------: | :---------------------------: | :-------------------------: | :-------------: | :----------------------: |
+| Small    |           4          |               8               |              1              |        4        |            16            |
+| Standard |           8          |               30              |              1              |        12       |            48            |
+| Medium   |          16          |               64              |              2              |        32       |            64            |
+| Large    |          72          |              468              |             3.5             |        48       |            184           |
+
+### What are some basic security precautions an Indexer should take?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastructure
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Note: To support agile scaling, it is recommended that query and indexing concerns are separated between different sets of nodes: query nodes and index nodes.
+
+### Ports overview
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Port | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
+
+#### Indexer Service
+
+| Port | Purpose                                              | Routes                                                      | CLI Argument    | Environment Variable   |
+| ---- | ---------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                   | /metrics                                                    | \--metrics-port | -                      |
+
+#### Indexer Agent
+
+| Port | Purpose                | Routes | CLI Argument               | Environment Variable                    |
+| ---- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | Indexer management API | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Setup server infrastructure using Terraform on Google Cloud
+
+> Note: Indexers can alternatively use AWS, Microsoft Azure, or Alibaba.
+
+#### Install prerequisites
+
+- Google Cloud SDK
+- Kubectl command line tool
+- Terraform
+
+#### Create a Google Cloud Project
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Authenticate with Google Cloud and create a new project.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Use the Google Cloud Console's billing page to enable billing for the new project.
+
+- Create a Google Cloud configuration.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Enable required Google Cloud APIs.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Create a service account.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Enable peering between database and Kubernetes cluster that will be created in the next step.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Create minimal terraform configuration file (update as needed).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Use Terraform to create infrastructure
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Run the following commands to create the infrastructure.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Creating the Kubernetes components for the Indexer
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Getting started from source
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start a PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Now that all the dependencies are setup, start the Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Getting started using Docker
+
+#### Prerequisites
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Setup
+
+1. Clone Graph Node and navigate to the Docker directory:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Start a local Graph Node that will connect to your Ethereum endpoint:
+
+```sh
+docker-compose up
+```
+
+### Indexer components
+
+To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Getting started
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### From NPM packages
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### From source
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Using docker
+
+- Pull images from the registry
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Or build images locally from source
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Run the components
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Using K8s and Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Usage
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexer agent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Indexer management using Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Usage
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Indexing rules
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Data model:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Example usage of indexing rule:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Action added to the queue by the 3rd party optimizer tool or indexer-cli user
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken.
+
+Data model:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Example usage from source:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Note that supported action types for allocation management have different input requirements:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - required action params:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - required action params:
+    - allocationID
+    - deploymentID
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - required action params:
+    - allocationID
+    - deploymentID
+    - amount
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+#### Cost models
+
+Cost models provide dynamic pricing for queries based on market and query attributes. The Indexer Service shares a cost model with the gateways for each subgraph for which they intend to respond to queries. The gateways, in turn, use the cost model to make Indexer selection decisions per query and to negotiate payment with chosen Indexers.
+
+#### Agora
+
+The Agora language provides a flexible format for declaring cost models for queries. An Agora price model is a sequence of statements that execute in order for each top-level query in a GraphQL query. For each top-level query, the first statement which matches it determines the price for that query.
+
+A statement is comprised of a predicate, which is used for matching GraphQL queries, and a cost expression which when evaluated outputs a cost in decimal GRT. Values in the named argument position of a query may be captured in the predicate and used in the expression. Globals may also be set and substituted in for placeholders in an expression.
+
+Example cost model:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Example query costing using the above model:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Applying the cost model
+
+Cost models are applied via the Indexer CLI, which passes them to the Indexer Management API of the Indexer agent for storing in the database. The Indexer Service will then pick them up and serve the cost models to gateways whenever they ask for them.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interacting with the network
+
+### Stake in the protocol
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Approve tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Stake tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### The life of an allocation
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 607ee162637971fa0a8bb56e6a55c40cd4175a8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:08 -0500
Subject: [PATCH 0715/3820] New translations tap.mdx (Romanian)

---
 website/pages/ro/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/ro/indexing/tap.mdx

diff --git a/website/pages/ro/indexing/tap.mdx b/website/pages/ro/indexing/tap.mdx
new file mode 100644
index 000000000000..3bab672ab211
--- /dev/null
+++ b/website/pages/ro/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Overview
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notes:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From 0d38fc3633bdf6a403b33e98890e3bd7379aaea0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:09 -0500
Subject: [PATCH 0716/3820] New translations graph-node.mdx (Romanian)

---
 .../pages/ro/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/ro/indexing/tooling/graph-node.mdx

diff --git a/website/pages/ro/indexing/tooling/graph-node.mdx b/website/pages/ro/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..6a27301b680b
--- /dev/null
+++ b/website/pages/ro/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL database
+
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
+
+### Network clients
+
+In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS Nodes
+
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+### Prometheus metrics server
+
+To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
+
+### Getting started from source
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start a PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Now that all the dependencies are setup, start the Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Getting started with Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+When it is running Graph Node exposes the following ports:
+
+| Port | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Advanced Graph Node configuration
+
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Multiple Graph Nodes
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding.
+
+#### Deployment rules
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Example deployment rule configuration:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Dedicated query nodes
+
+Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Any node whose --node-id matches the regular expression will be set up to only respond to queries.
+
+#### Database scaling via sharding
+
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore.
+
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Dedicated block ingestion
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Supporting multiple networks
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Multiple networks
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Environment variables
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Continuous deployment
+
+Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Managing Graph Node
+
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Working with subgraphs
+
+#### Indexing status API
+
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Indexing performance
+
+There are three separate parts of the indexing process:
+
+- Fetching events of interest from the provider
+- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
+- Writing the resulting data to the store
+
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+
+Common causes of indexing slowness:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- A large number of events to process
+- Slow database connection time, for crowded nodes
+- The provider itself falling behind the chain head
+- Slowness in fetching new receipts at the chain head from the provider
+
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+
+#### Failed subgraphs
+
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+
+- Deterministic failures: these are failures which will not be resolved with retries
+- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
+
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Block and call cache
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. If the block matches the provider, then the issue can be debugged directly against the provider.
+
+#### Querying issues and errors
+
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+
+However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+
+There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.
+
+##### Query caching
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analysing queries
+
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
+
+In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
+
+##### Account-like optimisation
+
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Removing subgraphs
+
+> This is new functionality, which will be available in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 94301fd13d08255ec60b71c81282040cf0e0b0bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:11 -0500
Subject: [PATCH 0717/3820] New translations advanced.mdx (Romanian)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/ro/subgraphs/developing/creating/advanced.mdx b/website/pages/ro/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..a6a4b224bc3e
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Overview
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Non-fatal errors
+
+Indexing errors on already synced subgraphs will, by default, cause the subgraph to fail and stop syncing. Subgraphs can alternatively be configured to continue syncing in the presence of errors, by ignoring the changes made by the handler which provoked the error. This gives subgraph authors time to correct their subgraphs while queries continue to be served against the latest block, though the results might be inconsistent due to the bug that caused the error. Note that some errors are still always fatal. To be non-fatal, the error must be known to be deterministic.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Enabling non-fatal errors requires setting the following feature flag on the subgraph manifest:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way. File data sources support fetching files from IPFS and from Arweave.
+
+> This also lays the groundwork for deterministic indexing of off-chain data, as well as the potential introduction of arbitrary HTTP-sourced data.
+
+### Overview
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Upgrade guide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Add a new entity type which will be updated when files are found
+
+File data sources cannot access or update chain-based entities, but must update file specific entities.
+
+This may mean splitting out fields from existing entities into separate entities, linked together.
+
+Original combined entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+New, split entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+If the relationship is 1:1 between the parent entity and the resulting file data source entity, the simplest pattern is to link the parent entity to a resulting file entity by using the IPFS CID as the lookup. Get in touch on Discord if you are having difficulty modelling your new file-based entities!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+This is the data source which will be spawned when a file of interest is identified.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Create a new handler to process files
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Example handler:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Spawn file data sources when required
+
+You can now create file data sources during execution of chain-based handlers:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Example:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+This will create a new file data source, which will poll Graph Node's configured IPFS or Arweave endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Congratulations, you are using file data sources!
+
+#### Deploying your subgraphs
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitations
+
+File data source handlers and entities are isolated from other subgraph entities, ensuring that they are deterministic when executed, and ensuring no contamination of chain-based data sources. To be specific:
+
+- Entities created by File Data Sources are immutable, and cannot be updated
+- File Data Source handlers cannot access entities from other file data sources
+- Entities associated with File Data Sources cannot be accessed by chain-based handlers
+
+> While this constraint should not be problematic for most use-cases, it may introduce complexity for some. Please get in touch via Discord if you are having issues modelling your file-based data in a subgraph!
+
+Additionally, it is not possible to create data sources from a file data source, be it an onchain data source or another file data source. This restriction may be lifted in the future.
+
+#### Best practices
+
+If you are linking NFT metadata to corresponding tokens, use the metadata's IPFS hash to reference a Metadata entity from the Token entity. Save the Metadata entity using the IPFS hash as an ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> We are working to improve the above recommendation, so queries only return the "most recent" version
+
+#### Known issues
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Examples
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### References
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Grafting onto Existing Subgraphs
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Because grafting copies rather than indexes base data, it is much quicker to get the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From c5df754bf75b7f5188f76c58994ab5a0bf51ff9f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:12 -0500
Subject: [PATCH 0718/3820] New translations api.mdx (Romanian)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/ro/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/ro/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..5cd8ab120b25
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API Reference
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- Low-level primitives to translate between different type systems such as Ethereum, JSON, GraphQL and AssemblyScript.
+
+### Versions
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| Version | Release notes                                                                                                                                                                                                                                            |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### Built-in Types
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Creating entities
+
+The following is a common pattern for creating entities from Ethereum events.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Loading entities from the store
+
+If an entity already exists, it can be loaded from the store with the following:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Looking up entities created withing a block
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### Updating existing entities
+
+There are two ways to update an existing entity:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+Changing properties is straight forward in most cases, thanks to the generated property setters:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+It is also possible to unset properties with one of the following two instructions:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Removing entities from the store
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
+
+#### Support for Ethereum Types
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+The following example illustrates this. Given a subgraph schema like
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Events and Block/Transaction Data
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Access to Smart Contract State
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+A common pattern is to access the contract from which an event originates. This is achieved with the following code:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address.
+
+#### Handling Reverted Calls
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Encoding/Decoding ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+For more information:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Logging one or more values
+
+##### Logging a single value
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Logging a single entry from an existing array
+
+In the example below, only the first value of the argument array is logged, despite the array containing three values.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Logging multiple entries from an existing array
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Logging a specific entry from an existing array
+
+To display a specific value in the array, the indexed value must be provided.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Logging event information
+
+The example below logs the block number, block hash and transaction hash from an event:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Given an IPFS hash or path, reading a file from IPFS is done as follows:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### Type Conversions Reference
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### Data Source Metadata
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entity and DataSourceContext
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From 8acc9d75eb53819bd5576ac68bfa28798c330cd6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:14 -0500
Subject: [PATCH 0719/3820] New translations common-issues.mdx (Romanian)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/ro/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/ro/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..f8d0c9c004c2
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Common AssemblyScript Issues
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From de534fb57c2e980cdc01976d6342f91124ecc1ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:15 -0500
Subject: [PATCH 0720/3820] New translations unit-testing-framework.mdx
 (Romanian)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/ro/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/ro/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..2133c1d4b5c9
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Unit Testing Framework
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Getting Started
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+or
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+This will run all tests in the test folder:
+
+```sh
+graph test
+```
+
+This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
+
+```sh
+graph test gravity
+```
+
+This will run only that specific test file:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo subgraph
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Video tutorials
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+or
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Examples:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Example:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Examples:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Write a Unit Test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Assuming we have the following handler function (along with two helper functions to make our life easier):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+We first have to create a test file in our project. This is an example of how that might look like:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- We're setting up our initial state and adding one custom Gravatar entity;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- We assert the state of the store. How does that work? - We're passing a unique combination of Entity type and id. Then we check a specific field on that Entity and assert that it has the value we expect it to have. We're doing this both for the initial Gravatar Entity we added to the store, as well as the two Gravatar entities that gets added when the handler function is called;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+There we go - we've created our first test! 👏
+
+Now in order to run our tests you simply need to run the following in your subgraph root folder:
+
+`graph test Gravity`
+
+And if all goes well you should be greeted with the following:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Common test scenarios
+
+### Hydrating the store with a certain state
+
+Users are able to hydrate the store with a known set of entities. Here's an example to initialise the store with a Gravatar entity:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Calling a mapping function with an event
+
+A user can create a custom event and pass it to a mapping function that is bound to the store:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Calling all of the mappings with event fixtures
+
+Users can call the mappings with test fixtures.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocking contract calls
+
+Users can mock contract calls:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+As demonstrated, in order to mock a contract call and hardcore a return value, the user must provide a contract address, function name, function signature, an array of arguments, and of course - the return value.
+
+Users can also mock function reverts:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking IPFS files (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Asserting the state of the store
+
+Users are able to assert the final (or midway) state of the store through asserting entities. In order to do this, the user has to supply an Entity type, the specific ID of an Entity, a name of a field on that Entity, and the expected value of the field. Here's a quick example:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interacting with Event metadata
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Asserting variable equality
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Users can assert that an entity does not exist in the store. The function takes an entity type and an id. If the entity is in fact in the store, the test will fail with a relevant error message. Here's a quick example of how to use this functionality:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+You can print the whole store to the console using this helper function:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Expected failure
+
+Users can have expected test failures, using the shouldFail flag on the test() functions:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+If the test is marked with shouldFail = true but DOES NOT fail, that will show up as an error in the logs and the test block will fail. Also, if it's marked with shouldFail = false (the default state), the test executor will crash.
+
+### Logging
+
+Having custom logs in the unit tests is exactly the same as logging in the mappings. The difference is that the log object needs to be imported from matchstick-as rather than graph-ts. Here's a simple example with all non-critical log types:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Users can also simulate a critical failure, like so:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Logging critical errors will stop the execution of the tests and blow everything up. After all - we want to make sure you're code doesn't have critical logs in deployment, and you should notice right away if that were to happen.
+
+### Testing derived fields
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testing dynamic data sources
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Example below:
+
+First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+And then we have the test using one of the methods in the dataSourceMock namespace to set a new return value for all of the dataSource functions:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Notice that dataSourceMock.resetValues() is called at the end. That's because the values are remembered when they are changed and need to be reset if you want to go back to the default values.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Test Coverage
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Prerequisites
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Export your handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Usage
+
+Once that's all set up, to run the test coverage tool, simply run:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Test run time duration in the log output
+
+The log output includes the test run duration. Here's an example:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Common compiler errors
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Additional Resources
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Feedback
+
+If you have any questions, feedback, feature requests or just want to reach out, the best place would be The Graph Discord where we have a dedicated channel for Matchstick, called 🔥| unit-testing.

From 4e2edf7fccf6264a6253253ec6ae4a14b5201acc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:17 -0500
Subject: [PATCH 0721/3820] New translations transferring-a-subgraph.mdx
 (Romanian)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/ro/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/ro/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 83cce108e51cba8f8f594411b3850e3daae850af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:18 -0500
Subject: [PATCH 0722/3820] New translations graphql-api.mdx (Romanian)

---
 .../ro/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/ro/subgraphs/querying/graphql-api.mdx b/website/pages/ro/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..2ffcb85e4019
--- /dev/null
+++ b/website/pages/ro/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Examples
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sorting
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Example
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Example for nested entity sorting
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Pagination
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Query the first 10 tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtering
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Example for range filtering
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for block filtering
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for nested entity filtering
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+This can be useful if you are looking to fetch only entities whose child-level entities meet the provided conditions.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logical operators
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### All Filters
+
+Full list of parameter suffixes:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Time-travel queries
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltext Search Queries
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Fulltext search operators:
+
+| Symbol | Operator    | Description                                                                                                                          |
+| ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
+
+#### Examples
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validation
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Subgraph Metadata
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: the hash of the block
+- number: the block number
+- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 7cf08de485e89163f23749de3f4022fbeaabf7fd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:19 -0500
Subject: [PATCH 0723/3820] New translations python.mdx (Romanian)

---
 .../pages/ro/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/querying/python.mdx

diff --git a/website/pages/ro/subgraphs/querying/python.mdx b/website/pages/ro/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..c10d7a0e57ab
--- /dev/null
+++ b/website/pages/ro/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Getting Started
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From cf959bb546d16d886dc67e2ce9e3c37d970bffdf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:20 -0500
Subject: [PATCH 0724/3820] New translations triggers.mdx (Romanian)

---
 website/pages/ro/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/ro/substreams/sps/triggers.mdx

diff --git a/website/pages/ro/substreams/sps/triggers.mdx b/website/pages/ro/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/ro/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From d26cea72fa39047a74d6dd5d6f029d4332ac6657 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:21 -0500
Subject: [PATCH 0725/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/fr/indexing/overview.mdx

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
new file mode 100644
index 000000000000..e3c31e6563ee
--- /dev/null
+++ b/website/pages/fr/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Les indexeurs sont des opérateurs de nœuds dans The Graph Network qui mettent en jeu des jetons Graph (GRT) afin de fournir des services d'indexation et de traitement de requêtes. Les indexeurs perçoivent des frais de requête et des récompenses d'indexation pour leurs services. Ils perçoivent également des frais de requête qui sont réduits selon une fonction de remise exponentielle.
+
+Le GRT intégré au protocole est soumis à une période de décongélation et peut être réduit si les indexeurs sont malveillants et fournissent des données incorrectes aux applications ou s'ils indexent de manière incorrecte. Les indexeurs gagnent également des récompenses pour la participation déléguée des délégués, afin de contribuer au réseau.
+
+Les indexeurs sélectionnent les subgraphs à indexer en fonction du signal de curation du subgraph, où les curateurs misent du GRT afin d'indiquer quels subgraphs sont de haute qualité et doivent être priorisés. Les consommateurs (par exemple les applications) peuvent également définir les paramètres pour lesquels les indexeurs traitent les requêtes pour leurs subgraphs et définir les préférences pour la tarification des frais de requête.
+
+<Difficulty level="ADVANCED" />
+
+## Questions fréquemment posées
+
+### Quelle est la mise minimale requise pour être indexeur sur le réseau ?
+
+La mise minimale pour un indexeur est actuellement fixée à 100 000 GRT.
+
+### Quelles sont les sources de revenus pour un indexeur ?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### Comment sont distribuées les récompenses d’indexation ?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### Qu'est-ce qu'une preuve d'indexation (POI) ?
+
+Les POI sont utilisés dans le réseau pour vérifier qu'un indexeur indexe les subgraphs sur lesquels ils ont été alloués. Un POI pour le premier bloc de l'époque actuelle doit être soumis lors de la clôture d'une allocation pour que cette allocation soit éligible aux récompenses d'indexation. Un POI pour un bloc est un résumé de toutes les transactions du magasin d'entités pour un déploiement de subgraph spécifique jusqu'à ce bloc inclus.
+
+### Quand les récompenses d’indexation sont-elles distribuées ?
+
+Les allocations accumulent continuellement des récompenses pendant qu'elles sont actives et allouées dans un délai de 28 époques. Les récompenses sont collectées par les indexeurs et distribuées chaque fois que leurs allocations sont clôturées. Cela se produit soit manuellement, chaque fois que l'indexeur souhaite forcer leur fermeture, soit après 28 époques, un délégant peut fermer l'allocation pour l'indexeur, mais cela n'entraîne aucune récompense. 28 époques est la durée de vie maximale de l'allocation (à l'heure actuelle, une époque dure environ 24 heures).
+
+### Les récompenses d’indexation en attente peuvent-elles être surveillées ?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+De nombreux tableaux de bord créés par la communauté incluent des valeurs de récompenses en attente et ils peuvent être facilement vérifiés manuellement en suivant ces étapes :
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### Que sont les litiges et où puis-je les consulter ?
+
+Les requêtes et les allocations de l'indexeur peuvent toutes deux être contestées sur The Graph pendant la période de contestation. Le délai de contestation varie selon le type de litige. Les requêtes/attestations ont une fenêtre de contestation de 7 époques, tandis que les allocations ont 56 époques. Passé ces délais, aucun litige ne peut être ouvert ni contre les attributions ni contre les requêtes. Lorsqu'un litige est ouvert, une caution d'un minimum de 10 000 GRT est exigée par les pêcheurs, qui sera verrouillée jusqu'à ce que le litige soit finalisé et qu'une résolution soit trouvée. Les pêcheurs sont tous les participants au réseau qui ouvrent des différends.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- Si la contestation est rejetée, le GRT déposé par les Pêcheurs sera brûlé, et l'Indexeur contesté ne sera pas sabré.
+- Si le différend est réglé par un match nul, la caution du pêcheur sera restituée et l'indexeur contesté ne sera pas réduit.
+- Si la contestation est acceptée, le GRT déposé par les Pêcheurs sera restitué, l'Indexeur contesté sera réduit et les Pêcheurs gagneront 50% du GRT réduit.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### Que sont les remises sur les frais de requête et quand sont-elles distribuées ?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Une fois qu'une allocation a été clôturée, les remises peuvent être réclamées par l'indexeur. Lors de la réclamation, les remises sur les frais de requête sont distribuées à l'indexeur et à leurs délégués en fonction de la réduction des frais de requête et de la fonction de remise exponentielle.
+
+### Qu'est-ce que la réduction des frais de requête et la réduction des récompenses d'indexation ?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### Comment les indexeurs savent-ils quels subgraphs indexer ?
+
+Les indexeurs peuvent se différencier en appliquant des techniques avancées pour prendre des décisions d'indexation de subgraphs, mais pour donner une idée générale, nous discuterons de plusieurs mesures clés utilisées pour évaluer les subgraphs du réseau :
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### Quelle est la configuration matérielle requise ?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Installation | Postgres<br />(CPUs) | Postgres<br />(mémoire en Gbs) | Postgres<br />(disque en TB) | VMs<br />(CPUs) | VMs<br />(mémoire en Gbs) |
+| ------------ | :------------------: | :----------------------------: | :--------------------------: | :-------------: | :-----------------------: |
+| Petit        |           4          |                8               |               1              |        4        |             16            |
+| Standard     |           8          |               30               |               1              |        12       |             48            |
+| Moyen        |          16          |               64               |               2              |        32       |             64            |
+| Large        |          72          |               468              |              3.5             |        48       |                           |
+
+### Quelles sont les précautions de sécurité de base qu’un indexeur doit prendre ?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastructure
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Remarque : Pour prendre en charge la mise à l'échelle agile, il est recommandé de séparer les problèmes de requête et d'indexation entre différents ensembles de nœuds : nœuds de requête et nœuds d'index.
+
+### Aperçu des ports
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Nœud de The Graph
+
+| Port | Objectif                                                   | Routes                                         | Argument CLI       | Variable d'environnement |
+| ---- | ---------------------------------------------------------- | ---------------------------------------------- | ------------------ | ------------------------ |
+| 8000 | Serveur HTTP GraphQL<br />(pour les requêtes de subgraphs) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                        |
+| 8001 | GraphQL WS<br />(pour les abonnements aux subgraphs)       | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                        |
+| 8020 | JSON-RPC<br />(pour gérer les déploiements)                | /                                              | \--admin-port      | -                        |
+| 8030 | API de statut d'indexation des subgraphs                   | /graphq                                        | \--index-node-port | -                        |
+| 8040 | Métriques Prometheus                                       | /metrics                                       | \--metrics-port    | -                        |
+
+#### Service d'indexation
+
+| Port | Objectif                                                            | Routes                                                      | Argument CLI    | Variable d'environnement |
+| ---- | ------------------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ------------------------ |
+| 7600 | Serveur HTTP GraphQL<br />(pour les requêtes payantes de subgraphs) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT`   |
+| 7300 | Métriques Prometheus                                                | /metrics                                                    | \--metrics-port | -                        |
+
+#### Agent indexeur
+
+| Port | Purpose                      | Routes | CLI Argument               | Environment Variable                    |
+| ---- | ---------------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | API de gestion des indexeurs | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Configurer l'infrastructure du serveur à l'aide de Terraform sur Google Cloud
+
+> Note : Les indexeurs peuvent alternativement utiliser AWS, Microsoft Azure ou Alibaba.
+
+#### Conditions préalables à l'installation
+
+- Google Cloud SDK
+- Outil de ligne de commande kubectl
+- Terraform
+
+#### Créer un projet Google Cloud
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Authentifiez-vous auprès de Google Cloud et créez un nouveau projet.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Utilisez la page de facturation de Google Cloud Console pour activer la facturation du nouveau projet.
+
+- Créez une configuration Google Cloud.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Activez les API Google Cloud requises.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Créez un compte de service.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Activez le peering entre la base de données et le cluster Kubernetes qui sera créé à l'étape suivante.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Créez un fichier de configuration Terraform minimal (mettez à jour si nécessaire).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Utiliser Terraform pour créer une infrastructure
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Exécutez les commandes suivantes pour créer l'infrastructure.
+
+```sh
+# Installer les Plugins Requis
+terraform init
+
+# Afficher le plan des ressources à créer
+terraform plan
+
+# Créez les ressources (attendez-vous à ce que cela prenne jusqu'à 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Création des composants Kubernetes pour l'indexeur
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Nœud de The Graph
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Commencer à partir des sources
+
+#### Conditions préalables à l'installation
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Installation
+
+1. Démarrer un serveur de base de données PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Maintenant que toutes les dépendances sont configurées, démarrez le Graph Node :
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Démarrer avec Docker
+
+#### Conditions préalables
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Installation
+
+1. Clonez Graph Node et accédez au répertoire Docker :
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Démarrez un nœud graph local qui se connectera à votre point de terminaison Ethereum :
+
+```sh
+docker-compose up
+```
+
+### Composants de l'indexeur
+
+Pour participer avec succès au réseau, il faut une surveillance et une interaction presque constantes. Nous avons donc créé une suite d'applications Typescript pour faciliter la participation au réseau des indexeurs. Il existe trois composants d'indexeur :
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Commencer
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### À partir des packages NPM
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### De la source
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Utiliser docker
+
+- Extraire les images du registre
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Ou créez des images localement à partir de la source
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Exécutez les composants
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Utilisation de K8s et Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Usage
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexer agent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Gestion de l'indexeur à l'aide de l'indexeur CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Usage
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Règles d'indexation
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Modèle de données:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Exemple d'utilisation de la règle d'indexation :
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### CLI de la file des actions
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Action ajoutée à la file d'attente par l'outil d'optimisation tiers ou l'utilisateur indexeur-cli
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- L'indexeur peut surveiller la file d'attente des actions pour consulter un historique de l'exécution des actions et, si nécessaire, réapprouver et mettre à jour les éléments d'action en cas d'échec de leur exécution. La file d'attente des actions fournit un historique de toutes les actions mises en file d'attente et entreprises.
+
+Modèle de données:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Exemple d'utilisation à partir de la source :
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Notez que les types d'actions pris en charge pour la gestion des allocations ont des exigences d'entrée différentes :
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - paramètres d'action requis :
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - paramètres d'action requis :
+    - ID d'allocation
+    - deploymentID
+  - paramètres d'action facultatifs :
+    - poi
+    - force (force l'utilisation du POI fourni même s'il ne correspond pas à ce que fournit le nœud graph)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - paramètres d'action requis :
+    - ID d'allocation
+    - deploymentID
+    - amount
+  - paramètres d'action facultatifs :
+    - poi
+    - force (force l'utilisation du POI fourni même s'il ne correspond pas à ce que fournit le nœud graph)
+
+#### Modèles de coûts
+
+Les modèles de coûts fournissent une tarification dynamique pour les requêtes en fonction des attributs du marché et des requêtes. Le service Indexeur partage un modèle de coût avec les passerelles pour chaque subgraph pour lequel elles ont l'intention de répondre aux requêtes. Les passerelles, à leur tour, utilisent le modèle de coût pour prendre des décisions de sélection des indexeurs par requête et pour négocier le paiement avec les indexeurs choisis.
+
+#### Agora
+
+Le langage Agora fournit un format flexible pour déclarer des modèles de coûts pour les requêtes. Un modèle de prix Agora est une séquence d'instructions qui s'exécutent dans l'ordre pour chaque requête de niveau supérieur dans une requête GraphQL. Pour chaque requête de niveau supérieur, la première instruction qui y correspond détermine le prix de cette requête.
+
+Une instruction est composée d'un prédicat, qui est utilisé pour faire correspondre les requêtes GraphQL, et d'une expression de coût qui, une fois évaluée, génère un coût en GRT décimal. Les valeurs dans la position d'argument nommé d'une requête peuvent être capturées dans le prédicat et utilisées dans l'expression. Des éléments globaux peuvent également être définis et remplacés par des espaces réservés dans une expression.
+
+Exemple de modèle de coût :
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Exemple de calcul des coûts de requête utilisant le modèle ci-dessus :
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Application du modèle de coût
+
+Les modèles de coûts sont appliqués via la CLI Indexer, qui les transmet à l'API de gestion de l'indexeur de l'agent Indexer pour les stocker dans la base de données. Le service d'indexation les récupérera ensuite et fournira les modèles de coûts aux passerelles chaque fois qu'elles les demanderont.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interagir avec le réseau
+
+### Enjeu dans le protocole
+
+Les premières étapes pour participer au réseau en tant qu'Indexeur sont d'approuver le protocole, de staker des fonds et (facultativement) de configurer une adresse opérateur pour les interactions quotidiennes avec le protocole.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Approuver les jetons
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Jetons de mise
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Définition des paramètres de délégation
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### Comment définir les paramètres de délégation
+
+Pour définir les paramètres de délégation à l'aide de l'interface Graph Explorer, suivez ces étapes :
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connectez votre portefeuille. Choisissez multisig (comme Gnosis Safe) puis sélectionnez mainnet. Note : Vous devrez répéter ce processus pour Arbitrum One.
+3. Connectez le portefeuille que vous avez en tant que signataire.
+4. Accédez à la section "Settings" puis sélectionnez "Delegation Parameters". Ces paramètres doivent être configurés afin d’obtenir un taux effectif dans la fourchette souhaitée. Une fois les valeurs saisies dans les champs prévus, l’interface calcule automatiquement ce taux effectif. Ajustez les valeurs selon vos besoins pour atteindre le pourcentage effectif désiré.
+5. Soumettez la transaction au réseau.
+
+> Note : Cette transaction devra être confirmée par les signataires du portefeuille multisig.
+
+### La durée de vie d'une allocation
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From b2ead9f35908fbfcfabdec0b2266872e8abc0490 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:23 -0500
Subject: [PATCH 0726/3820] New translations tap.mdx (French)

---
 website/pages/fr/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/fr/indexing/tap.mdx

diff --git a/website/pages/fr/indexing/tap.mdx b/website/pages/fr/indexing/tap.mdx
new file mode 100644
index 000000000000..773ddf96163a
--- /dev/null
+++ b/website/pages/fr/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Aperçu
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Spécificités⁠
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Exigences
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notez :
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From f222235a46839c9d9cb4db7dbb9cb43a895643e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:24 -0500
Subject: [PATCH 0727/3820] New translations graph-node.mdx (French)

---
 .../pages/fr/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/fr/indexing/tooling/graph-node.mdx

diff --git a/website/pages/fr/indexing/tooling/graph-node.mdx b/website/pages/fr/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..ed5733e07d22
--- /dev/null
+++ b/website/pages/fr/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Nœud de The Graph
+---
+
+Graph Node est le composant qui indexe les subgraphs et rend les données résultantes disponibles pour interrogation via une API GraphQL. En tant que tel, il est au cœur de la pile de l’indexeur, et le bon fonctionnement de Graph Node est crucial pour exécuter un indexeur réussi.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Nœud de The Graph
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL database
+
+Le magasin principal du nœud de graph, c'est là que les données des sous-graphes sont stockées, ainsi que les métadonnées sur les subgraphs et les données réseau indépendantes des subgraphs telles que le cache de blocs et le cache eth_call.
+
+### Clients réseau
+
+Pour indexer un réseau, Graph Node doit avoir accès à un client réseau via une API JSON-RPC compatible avec EVM. Cette RPC peut se connecter à un seul client ou à une configuration plus complexe qui équilibre la charge entre plusieurs clients.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### Nœuds IPFS
+
+Les métadonnées de déploiement de subgraphs sont stockées sur le réseau IPFS. The Graph Node accède principalement au noed IPFS pendant le déploiement du subgraph pour récupérer le manifeste du subgraph et tous les fichiers liés. Les indexeurs de réseau n'ont pas besoin d'héberger leur propre noed IPFS. Un noed IPFS pour le réseau est hébergé sur https://ipfs.network.thegraph.com.
+
+### Serveur de métriques Prometheus
+
+Pour activer la surveillance et la création de rapports, Graph Node peut éventuellement enregistrer les métriques sur un serveur de métriques Prometheus.
+
+### Commencer à partir des sources
+
+#### Conditions préalables à l'installation
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Installation
+
+1. Démarrer un serveur de base de données PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Maintenant que toutes les dépendances sont configurées, démarrez le Graph Node :
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Bien démarrer avec Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+Lorsqu'il est en cours d'exécution, Graph Node expose les ports suivants :
+
+| Port | Objectif                                                   | Routes                                         | Argument CLI       | Variable d'environnement |
+| ---- | ---------------------------------------------------------- | ---------------------------------------------- | ------------------ | ------------------------ |
+| 8000 | Serveur HTTP GraphQL<br />(pour les requêtes de subgraphs) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                        |
+| 8001 | GraphQL WS<br />(pour les abonnements aux subgraphs)       | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                        |
+| 8020 | JSON-RPC<br />(pour gérer les déploiements)                | /                                              | \--admin-port      | -                        |
+| 8030 | API de statut d'indexation des subgraphs                   | /graphq                                        | \--index-node-port | -                        |
+| 8040 | Métriques Prometheus                                       | /metrics                                       | \--metrics-port    | -                        |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Configuration avancée du nœud graph
+
+Dans sa forme la plus simple, Graph Node peut être utilisé avec une seule instance de Graph Node, une seule base de données PostgreSQL, un nœud IPFS et les clients réseau selon les besoins des subgraphs à indexer.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> Lors de l'utilisation d'un fichier de configuration, il n'est pas possible d'utiliser les options --postgres-url, --postgres-secondary-hosts et --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Multiple Graph Nodes
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Notez que plusieurs nœuds de graph peuvent tous être configurés pour utiliser la même base de données, qui elle-même peut être mise à l'échelle horizontalement via le partitionnement.
+
+#### Règles de déploiement
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Exemple de configuration de règle de déploiement :
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Nœuds de requête dédiés
+
+Les nœuds peuvent être configurés pour être explicitement des nœuds de requête en incluant les éléments suivants dans le fichier de configuration :
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Tout nœud dont --node-id correspond à l'expression régulière sera configuré pour répondre uniquement aux requêtes.
+
+#### Mise à l'échelle de la base de données via le partitionnement
+
+Pour la plupart des cas d'utilisation, une seule base de données Postgres suffit pour prendre en charge une instance de nœud graph. Lorsqu'une instance de nœud graph dépasse une seule base de données Postgres, il est possible de diviser le stockage des données de nœud graph sur plusieurs bases de données Postgres. Toutes les bases de données forment ensemble le magasin de l’instance de nœud graph. Chaque base de données individuelle est appelée une partition.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Le partage devient utile lorsque votre base de données existante ne peut pas suivre la charge que Graph Node lui impose et lorsqu'il n'est plus possible d'augmenter la taille de la base de données.
+
+> Il est généralement préférable de créer une base de données unique aussi grande que possible avant de commencer avec des fragments. Une exception est lorsque le trafic des requêtes est réparti de manière très inégale entre les subgraphs ; dans ces situations, cela peut être considérablement utile si les subgraphs à volume élevé sont conservés dans une partition et tout le reste dans une autre, car cette configuration rend plus probable que les données des subgraphs à volume élevé restent dans le cache interne de la base de données et ne le font pas. sont remplacés par des données qui ne sont pas autant nécessaires à partir de subgraphs à faible volume.
+
+En termes de configuration des connexions, commencez par max_connections dans postgresql.conf défini sur 400 (ou peut-être même 200) et regardez les métriques store_connection_wait_time_ms et store_connection_checkout_count Prometheus. Des temps d'attente notables (tout ce qui dépasse 5 ms) indiquent qu'il y a trop peu de connexions disponibles ; des temps d'attente élevés seront également dus au fait que la base de données est très occupée (comme une charge CPU élevée). Cependant, si la base de données semble par ailleurs stable, des temps d'attente élevés indiquent la nécessité d'augmenter le nombre de connexions. Dans la configuration, le nombre de connexions que chaque instance de nœud graph peut utiliser constitue une limite supérieure, et Graph Node ne maintiendra pas les connexions ouvertes s'il n'en a pas besoin.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Ingestion de blocs dédiés
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Prise en charge de plusieurs réseaux
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Plusieurs réseaux
+- Plusieurs fournisseurs par réseau (cela peut permettre de répartir la charge entre les fournisseurs, et peut également permettre la configuration de nœuds complets ainsi que de nœuds d'archives, Graph Node préférant les fournisseurs moins chers si une charge de travail donnée le permet).
+- Détails supplémentaires sur le fournisseur, tels que les fonctionnalités, l'authentification et le type de fournisseur (pour la prise en charge expérimentale de Firehose)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Variables d'environnement
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Déploiement continu
+
+Les utilisateurs qui utilisent une configuration d'indexation à grande échelle avec une configuration avancée peuvent bénéficier de la gestion de leurs nœuds graph avec Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Gestion du nœud de graph
+
+Étant donné un nœud de graph en cours d'exécution (ou des nœuds de graph !), le défi consiste alors à gérer les subgraphs déployés sur ces nœuds. Graph Node propose une gamme d'outils pour vous aider à gérer les subgraphs.
+
+#### Journal de bord
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node fournit les métriques via le point de terminaison Prometheus sur le port 8040 par défaut. Grafana peut ensuite être utilisé pour visualiser ces métriques.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Travailler avec des subgraphs
+
+#### API d'état d'indexation
+
+Disponible sur le port 8030/graphql par défaut, l'API d'état d'indexation expose une gamme de méthodes pour vérifier l'état d'indexation de différents subgraphs, vérifier les preuves d'indexation, inspecter les fonctionnalités des subgraphs et bien plus encore.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Performances d'indexation
+
+Le processus d'indexation comporte trois parties distinctes :
+
+- Récupération des événements d'intérêt auprès du fournisseur
+- Traiter les événements dans l'ordre avec les gestionnaires appropriés (cela peut impliquer d'appeler la chaîne pour connaître l'état et de récupérer les données du magasin)
+- Écriture des données résultantes dans le magasin
+
+Ces étapes sont pipeline (c’est-à-dire qu’elles peuvent être exécutées en parallèle), mais elles dépendent les unes des autres. Lorsque les subgraphs sont lents à indexer, la cause sous-jacente dépendra du subgraph spécifique.
+
+Causes courantes de lenteur d’indexation :
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- Une grande quantité d'interactions avec le magasin pendant l'exécution
+- Une grande quantité de données à sauvegarder dans le magasin
+- Un grand nombre d'événements à traiter
+- Temps de connexion à la base de données lent, pour les nœuds encombrés
+- Le prestataire lui-même prend du retard sur la tête de la chaîne
+- Lenteur dans la récupération des nouvelles recettes en tête de chaîne auprès du prestataire
+
+Les métriques d’indexation de subgraphs peuvent aider à diagnostiquer la cause première de la lenteur de l’indexation. Dans certains cas, le problème réside dans le subgraph lui-même, mais dans d'autres, des fournisseurs de réseau améliorés, une réduction des conflits de base de données et d'autres améliorations de configuration peuvent améliorer considérablement les performances d'indexation.
+
+#### Subgraphs ayant échoué
+
+Lors de l'indexation, les subgraphs peuvent échouer s'ils rencontrent des données inattendues, si certains composants ne fonctionnent pas comme prévu ou s'il y a un bogue dans les gestionnaires d'événements ou la configuration. Il existe deux types généraux de pannes :
+
+- Échecs déterministes : ce sont des échecs qui ne seront pas résolus par de nouvelles tentatives
+- Échecs non déterministes : ils peuvent être dus à des problèmes avec le fournisseur ou à une erreur inattendue de Graph Node. Lorsqu'un échec non déterministe se produit, Graph Node réessaiera les gestionnaires défaillants, en reculant au fil du temps.
+
+Dans certains cas, un échec peut être résolu par l'indexeur (par exemple, si l'erreur est due au fait de ne pas disposer du bon type de fournisseur, l'ajout du fournisseur requis permettra de poursuivre l'indexation). Cependant, dans d'autres cas, une modification du code du subgraph est requise.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Bloquer et appeler le cache
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+Si une incohérence du cache de blocs est suspectée, telle qu'un événement de réception de transmission manquant :
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. Si le bloc correspond au fournisseur, le problème peut être débogué directement auprès du fournisseur.
+
+#### Interroger les problèmes et les erreurs
+
+Une fois qu'un subgraph a été indexé, les indexeurs peuvent s'attendre à traiter les requêtes via le point de terminaison de requête dédié du subgraph. Si l'indexeur espère traiter un volume de requêtes important, un nœud de requête dédié est recommandé, et en cas de volumes de requêtes très élevés, les indexeurs peuvent souhaiter configurer des fragments de réplique afin que les requêtes n'aient pas d'impact sur le processus d'indexation.
+
+However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+
+Il n'existe pas de solution miracle, mais une gamme d'outils permettant de prévenir, de diagnostiquer et de traiter les requêtes lentes.
+
+##### Mise en cache des requêtes
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analyser les requêtes
+
+Les requêtes problématiques apparaissent le plus souvent de deux manières. Dans certains cas, les utilisateurs eux-mêmes signalent qu'une requête donnée est lente. Dans ce cas, le défi consiste à diagnostiquer la raison de la lenteur, qu'il s'agisse d'un problème général ou spécifique à ce subgraph ou à cette requête. Et puis bien sûr de le résoudre, si possible.
+
+Dans d'autres cas, le déclencheur peut être une utilisation élevée de la mémoire sur un nœud de requête, auquel cas le défi consiste d'abord à identifier la requête à l'origine du problème.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Étant donné une requête lente, les indexeurs disposent de quelques options. Bien entendu, ils peuvent modifier leur modèle de coûts pour augmenter considérablement le coût d’envoi de la requête problématique. Cela peut entraîner une réduction de la fréquence de cette requête. Cependant, cela ne résout souvent pas la cause première du problème.
+
+##### Optimisation de type compte
+
+Les tables de base de données qui stockent les entités semblent généralement se décliner en deux variétés : les tables de type « transaction », où les entités, une fois créées, ne sont jamais mises à jour, c'est-à-dire qu'elles stockent quelque chose qui s'apparente à une liste de transactions financières, et les « de type compte », où les entités sont mis à jour très souvent, c'est-à-dire qu'ils stockent quelque chose comme des comptes financiers qui sont modifiés à chaque fois qu'une transaction est enregistrée. Les tables de type compte se caractérisent par le fait qu'elles contiennent un grand nombre de versions d'entités, mais relativement peu d'entités distinctes. Souvent, dans de tels tableaux, le nombre d'entités distinctes représente 1 % du nombre total de lignes (versions d'entités)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Supprimer des subgraphs
+
+> Il s'agit d'une nouvelle fonctionnalité qui sera disponible dans Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 4ab2549ada222ad6bf0acf470eee5addf7693db5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:25 -0500
Subject: [PATCH 0728/3820] New translations advanced.mdx (French)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/fr/subgraphs/developing/creating/advanced.mdx b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..04392cf899e6
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Aperçu
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Séries chronologiques et agrégations
+
+Les séries chronologiques et les agrégations permettent à votre subgraph de suivre des statistiques telles que le prix moyen journalier, le total des transferts par heure, etc.
+
+Cette fonctionnalité introduit deux nouveaux types d'entités de subgraph. Les entités de séries chronologiques enregistrent des points de données avec des horodatages. Les entités d'agrégation effectuent des calculs pré-déclarés sur les points de données des séries chronologiques sur une base horaire ou quotidienne, puis stockent les résultats pour un accès facile via GraphQL.
+
+### Exemple de schéma
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Définition des Séries Chronologiques et des Agrégations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Intervalles d'Agrégation disponibles
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Fonctions d'Agrégation disponibles
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Exemple de requête d'Agrégations
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Remarque:
+
+Pour utiliser les Séries Chronologiques et les Agrégations, un subgraph doit avoir une spec Version ≥1.1.0. Notez que cette fonctionnalité pourrait subir des changements significatifs affectant la compatibilité rétroactive.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Erreurs non fatales
+
+Les erreurs d'indexation sur les subgraphs déjà synchronisés entraîneront, par défaut, l'échec du subgraph et l'arrêt de la synchronisation. Les subgraphs peuvent également être configurés pour continuer la synchronisation en présence d'erreurs, en ignorant les modifications apportées par le gestionnaire qui a provoqué l'erreur. Cela donne aux auteurs de subgraphs le temps de corriger leurs subgraphs pendant que les requêtes continuent d'être traitées sur le dernier bloc, bien que les résultats puissent être incohérents en raison du bogue à l'origine de l'erreur. Notez que certaines erreurs sont toujours fatales. Pour être non fatale, l'erreur doit être connue pour être déterministe.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+L'activation des erreurs non fatales nécessite la définition de l'indicateur de fonctionnalité suivant sur le manifeste du subgraph :
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## File Data Sources de fichiers IPFS/Arweave
+
+Les sources de données de fichiers sont une nouvelle fonctionnalité de subgraph permettant d'accéder aux données hors chaîne pendant l'indexation de manière robuste et extensible. Les sources de données de fichiers prennent en charge la récupération de fichiers depuis IPFS et Arweave.
+
+> Cela jette également les bases d’une indexation déterministe des données hors chaîne, ainsi que de l’introduction potentielle de données arbitraires provenant de HTTP.
+
+### Aperçu
+
+Plutôt que de récupérer les fichiers "ligne par ligne" pendant l'exécution du gestionnaire, ceci introduit des modèles qui peuvent être générés comme nouvelles sources de données pour un identifiant de fichier donné. Ces nouvelles sources de données récupèrent les fichiers, réessayant en cas d'échec, et exécutant un gestionnaire dédié lorsque le fichier est trouvé.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Guide de mise à niveau
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Ajouter un nouveau type d'entité qui sera mis à jour lorsque des fichiers seront trouvés
+
+Les sources de données de fichier ne peuvent pas accéder ni mettre à jour les entités basées sur une chaîne, mais doivent mettre à jour les entités spécifiques au fichier.
+
+Cela peut impliquer de diviser les champs des entités existantes en entités distinctes, liées entre elles.
+
+Entité combinée d'origine :
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+Nouvelle entité scindée :
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+Si la relation est 1:1 entre l'entité parent et l'entité de source de données de fichier résultante, le modèle le plus simple consiste à lier l'entité parent à une entité de fichier résultante en utilisant le CID IPFS comme recherche. Contactez Discord si vous rencontrez des difficultés pour modéliser vos nouvelles entités basées sur des fichiers !
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+Il s'agit de la source de données qui sera générée lorsqu'un fichier d'intérêt est identifié.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Créer un nouveau gestionnaire pour traiter les fichiers
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Exemple de gestionnaire :
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Générer des sources de données de fichiers si nécessaire
+
+Vous pouvez désormais créer des sources de données de fichiers lors de l'exécution de gestionnaires basés sur une chaîne :
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+L'exemple:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//Cet exemple de code concerne un sous-graphe de Crypto coven. Le hachage ipfs ci-dessus est un répertoire contenant les métadonnées des jetons pour toutes les NFT de l'alliance cryptographique.
+
+export function handleTransfer(event : TransferEvent) : void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //Ceci crée un chemin vers les métadonnées pour un seul Crypto coven NFT. Il concatène le répertoire avec "/" + nom de fichier + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+Cela créera une nouvelle source de données de fichier, qui interrogera le point d'extrémité IPFS ou Arweave configuré du nœud de graphique, en réessayant si elle n'est pas trouvée. Lorsque le fichier est trouvé, le gestionnaire de la source de données de fichier est exécuté.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Félicitations, vous utilisez des sources de données de fichiers !
+
+#### Déployer vos subgraphs
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitations
+
+Les entités et les gestionnaires de sources de données de fichiers sont isolés des autres entités du subgraph, ce qui garantit que leur exécution est déterministe et qu'il n'y a pas de contamination des sources de données basées sur des chaînes. Pour être plus précis :
+
+- Les entités créées par les sources de données de fichiers sont immuables et ne peuvent pas être mises à jour
+- Les gestionnaires de sources de données de fichiers ne peuvent pas accéder à des entités provenant d'autres sources de données de fichiers
+- Les entités associées aux sources de données de fichiers ne sont pas accessibles aux gestionnaires basés sur des chaînes
+
+> Cette contrainte ne devrait pas poser de problème pour la plupart des cas d'utilisation, mais elle peut en compliquer certains. N'hésitez pas à nous contacter via Discord si vous rencontrez des problèmes pour modéliser vos données basées sur des fichiers dans un subgraph !
+
+En outre, il n'est pas possible de créer des sources de données à partir d'une source de données de fichier, qu'il s'agisse d'une source de données onchain ou d'une autre source de données de fichier. Cette restriction pourrait être levée à l'avenir.
+
+#### Meilleures pratiques
+
+Si vous liez des métadonnées NFT aux jetons correspondants, utilisez le hachage IPFS des métadonnées pour référencer une entité Metadata à partir de l'entité Token. Enregistrez l'entité Metadata en utilisant le hachage IPFS comme identifiant.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> Nous travaillons à l'amélioration de la recommandation ci-dessus, afin que les requêtes ne renvoient que la version "la plus récente"
+
+#### Problèmes connus
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Exemples
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### Les Références
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Filtres d'Arguments indexés / Filtres de Topics
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Les filtres de topics, également connus sous le nom de filtres d'arguments indexés, sont une fonctionnalité puissante dans les subgraphs qui permettent aux utilisateurs de filtrer précisément les événements de la blockchain en fonction des valeurs de leurs arguments indexés.
+
+- Ces filtres aident à isoler des événements spécifiques intéressants parmi le vaste flux d'événements sur la blockchain, permettant aux subgraphs de fonctionner plus efficacement en se concentrant uniquement sur les données pertinentes.
+
+- Ceci est utile pour créer des subgraphs personnels qui suivent des adresses spécifiques et leurs interactions avec divers contrats intelligents sur la blockchain.
+
+### Comment fonctionnent les filtres de Topics
+
+Lorsqu'un contrat intelligent émet un événement, tous les arguments marqués comme indexés peuvent être utilisés comme filtres dans le manifeste d'un subgraph. Ceci permet au subgraph d'écouter de façon sélective les événements qui correspondent à ces arguments indexés.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Déclaration de l'événement avec des paramètres indexés pour les adresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Fonction pour simuler le transfert de tokens
+    function transfer(address to, uint256 value) public {
+        // Emission de l'événement Transfer avec from, to, et value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+Dans cet exemple:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration dans les subgraphs
+
+Les filtres de topics sont définis directement dans la configuration du gestionnaire d'évènement situé dans le manifeste du subgraph. Voici comment ils sont configurés :
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+Dans cette configuration :
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Chaque topic peut avoir une ou plusieurs valeurs, et un événement n'est traité que s'il correspond à l'une des valeurs de chaque rubrique spécifiée.
+
+#### Logique des Filtres
+
+- Au sein d'une même Topic: La logique fonctionne comme une condition OR. L'événement sera traité s'il correspond à l'une des valeurs listées dans une rubrique donnée.
+- Entre différents Topics: La logique fonctionne comme une condition AND. Un événement doit satisfaire toutes les conditions spécifiées à travers les différents topics pour déclencher le gestionnaire associé.
+
+#### Exemple 1 : Suivi des transferts directs de l'adresse A à l'adresse B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+Dans cette configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Exemple 2 : Suivi des transactions dans les deux sens entre deux ou plusieurs adresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+Dans cette configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- Le subgraph indexera les transactions qui se produisent dans les deux sens entre plusieurs adresses, permettant une surveillance complète des interactions impliquant toutes les adresses.
+
+## Déclaration eth_call
+
+> Remarque : Il s'agit d'une fonctionnalité expérimentale qui n'est pas encore disponible dans une version stable de Graph Node. Vous ne pouvez l'utiliser que dans Subgraph Studio ou sur votre nœud auto-hébergé.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+Cette fonctionnalité permet de :
+
+- Améliorer de manière significative les performances de la récupération des données de la blockchain Ethereum en réduisant le temps total pour plusieurs appels et en optimisant l'efficacité globale du subgraph.
+- Permet une récupération plus rapide des données, entraînant des réponses de requête plus rapides et une meilleure expérience utilisateur.
+- Réduire les temps d'attente pour les applications qui doivent réunir des données de plusieurs appels Ethereum, rendant le processus de récupération des données plus efficace.
+
+### Concepts clés
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Exécution en parallèle : Au lieu d'attendre la fin d'un appel avant de commencer le suivant, plusieurs appels peuvent être initiés simultanément.
+- Efficacité temporelle : Le temps total nécessaire pour tous les appels passe de la somme des temps d'appel individuels (séquentiels) au temps pris par l'appel le plus long (parallèle).
+
+#### Scenario without Declarative `eth_calls`
+
+Imaginez que vous ayez un subgraph qui doit effectuer trois appels Ethereum pour récupérer des données sur les transactions, le solde et les avoirs en jetons d'un utilisateur.
+
+Traditionnellement, ces appels pourraient être effectués de manière séquentielle :
+
+1. Appel 1 (Transactions) : Prend 3 secondes
+2. Appel 2 (Solde) : Prend 2 secondes
+3. Appel 3 (Avoirs en jetons) : Prend 4 secondes
+
+Temps total pris = 3 + 2 + 4 = 9 secondes
+
+#### Scenario with Declarative `eth_calls`
+
+Avec cette fonctionnalité, vous pouvez déclarer que ces appels soient exécutés en parallèle :
+
+1. Appel 1 (Transactions) : Prend 3 secondes
+2. Appel 2 (Solde) : Prend 2 secondes
+3. Appel 3 (Avoirs en jetons) : Prend 4 secondes
+
+Puisque ces appels sont exécutés en parallèle, le temps total pris est égal au temps pris par l'appel le plus long.
+
+Temps total pris = max (3, 2, 4) = 4 secondes
+
+#### Comment ça marche
+
+1. Définition déclarative : Dans le manifeste du subgraph, vous déclarez les appels Ethereum d'une manière indiquant qu'ils peuvent être exécutés en parallèle.
+2. Moteur d'exécution parallèle : Le moteur d'exécution de Graph Node reconnaît ces déclarations et exécute les appels simultanément.
+3. Agrégation des résultats : Une fois que tous les appels sont terminés, les résultats sont réunis et utilisés par le subgraph pour un traitement ultérieur.
+
+#### Exemple de configuration dans le manifeste du subgraph
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Détails pour l'exemple ci-dessus :
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Greffe sur des subgraphs existants
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Étant donné que le greffage copie plutôt que l'indexation des données de base, il est beaucoup plus rapide d'amener le susgraph dans le bloc souhaité que l'indexation à partir de zéro, bien que la copie initiale des données puisse encore prendre plusieurs heures pour de très gros subgraphs. Pendant l'initialisation du subgraph greffé, le nœud graphique enregistrera des informations sur les types d'entités qui ont déjà été copiés.
+
+Le subgraph greffé peut utiliser un schema GraphQL qui n'est pas identique à celui du subgraph de base, mais simplement compatible avec lui. Il doit s'agir d'un schema de subgraph valide en tant que tel, mais il peut s'écarter du schema du subgraph de base de la manière suivante :
+
+- Il ajoute ou supprime des types d'entité
+- Il supprime les attributs des types d'entité
+- Il ajoute des attributs nullables aux types d'entités
+- Il transforme les attributs non nullables en attributs nuls
+- Cela ajoute des valeurs aux énumérations
+- Il ajoute ou supprime des interfaces
+- Cela change pour quels types d'entités une interface est implémentée
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 0ccbda8861592d1626c310fc762d11bdafea7b8a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:26 -0500
Subject: [PATCH 0729/3820] New translations api.mdx (French)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..125a4eb976b2
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: API AssemblyScript
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Découvrez quelles APIs intégrées peuvent être utilisées lors de l'écriture des mappages de subgraph. Il existe deux types d'APIs disponibles par défaut :
+
+- La [Bibliothèque TypeScript de The Graph](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code généré à partir des fichiers du subgraph par `graph codegen`
+
+Vous pouvez également ajouter d'autres bibliothèques comme dépendances, à condition qu'elles soient compatibles avec [AssemblyScript] (https://github.com/AssemblyScript/assemblyscript).
+
+Étant donné que les mappages de langage sont écrits en AssemblyScript, il est utile de consulter les fonctionnalités de langage et de bibliothèque standard dans le du [wiki AssemblyScript] (https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## Référence API
+
+La bibliothèque `@graphprotocol/graph-ts` fournit les API suivantes :
+
+- Une API `ethereum` pour travailler avec les contrats intelligents Ethereum, les événements, les blocs, les transactions et les valeurs Ethereum.
+- Une API `store` pour charger et enregistrer des entités depuis et vers le magasin Graph Node.
+- Une API `log` pour enregistrer des messages dans la sortie Graph Node et Graph Explorer.
+- Une API `ipfs` pour charger des fichiers depuis IPFS.
+- Une API `json` pour analyser les données JSON.
+- Une API `crypto` pour utiliser des fonctions cryptographiques.
+- Primitives de bas niveau pour traduire entre différents systèmes de types tels que Ethereum, JSON, GraphQL et AssemblyScript.
+
+### Versions
+
+La `apiVersion` dans le manifeste du subgraph spécifie la version de l'API de mappage exécutée par Graph Node pour un subgraph donné.
+
+| Version | Notes de version                                                                                                                                                                                                                                         |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Ajout de nouvelles fonctions hôtes [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
+|  0.0.8  | Ajout de la validation pour l'existence des champs dans le schéma lors de l'enregistrement d'une entité.                                                                                                                                                 |
+|  0.0.7  | Ajout des classes `TransactionReceipt` et `Log`aux types Ethereum<br />Ajout du champ `receipt` à l'objet Ethereum Event                                                                                                                                 |
+|  0.0.6  | Ajout du champ `nonce` à l'objet Ethereum Transaction<br />Ajout de `baseFeePerGas` à l'objet Ethereum Block                                                                                                                                             |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Ajout du champ `functionSignature` à l'objet Ethereum SmartContractCall                                                                                                                                                                                  |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Ajout du champ `input` à l'objet Ethereum Transaction                                                                                                                                                                                                    |
+
+### Types intégrés
+
+La documentation sur les types de base intégrés dans AssemblyScript se trouve dans le [wiki AssemblyScript](https://www.assemblyscript.org/types.html).
+
+Les types additionnels suivants sont fournis par `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` représente un tableau de `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Décompose `x` en octets.
+- `fromHexString(hex: string): ByteArray` - La longueur de la saisie doit être paire. Le préfixe `0x` est optionnel.
+
+_Conversions de type_
+
+- `toHexString(): string` - Convertit en une chaîne de caractères hexadécimale ayant comme préfixe `0x`.
+- `toString(): string` - Interprète les octets comme une chaîne UTF-8.
+- toBase58(): string\` - Encode les octets en une chaîne de caractères de type base58.
+- `toU32(): u32` - Interprète les octets comme un `u32` en little-endian. Envoie une exception en cas de dépassement.
+- `toI32(): i32` - Interprète le tableau d'octets comme un `i32` en little-endian. Envoie une exception en cas de dépassement.
+
+_Operateurs_
+
+- `equals(y: ByteArray): bool` – peut être écrit comme `x == y`.
+- `concat(other: ByteArray) : ByteArray` - renvoie un nouveau `ByteArray` constitué de `this` directement suivi par `other`
+- `concatI32(other: i32) : ByteArray` - retourne un nouveau `ByteArray` constitué de `this` directement suivi par la représentation en octets de `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` est utilisé pour représenter des décimales à précision arbitraire.
+
+> Remarque: [En interne](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` est stocké au format [IEEE-754 décimal128 à virgule flottante](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), qui supporte 34 chiffres significatifs. Cela rend `BigDecimal` inapproprié pour représenter des types à virgule fixe pouvant dépasser 34 chiffres, comme un Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) ou équivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – crée un `BigDecimal` à partir d'un `BigInt`.
+- `static fromString(s: string): BigDecimal` – analyse à partir d'une chaîne de caractères décimaux.
+
+_Conversions de type_
+
+- `toString(): string` – affiche en une chaîne de caractères décimaux.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – peut être écrit comme `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – peut être écrit comme `x - y`.
+- `times(y: BigDecimal): BigDecimal` – peut être écrit comme `x * y`.
+- `div(y: BigDecimal): BigDecimal` – peut être écrit comme `x / y`.
+- `equals(y: BigDecimal): bool` – peut être écrit comme `x == y`.
+- `notEqual(y: BigDecimal): bool` – peut être écrit comme `x != y`.
+- `lt(y: BigDecimal): bool` – peut être écrit comme `x < y`.
+- `le(y: BigDecimal): bool` – peut être écrit comme `x <= y`.
+- `gt(y: BigDecimal): bool` – peut être écrit comme `x > y`.
+- `ge(y: BigDecimal): bool` – peut être écrit comme `x >= y`.
+- `neg(): BigDecimal` - peut être écrit comme `-x`.
+
+#### BigInt
+
+```typescript
+importer { BigInt } depuis '@graphprotocol/graph-ts'
+```
+
+`BigInt` est utilisé pour représenter de grands entiers. Cela inclut les valeurs Ethereum de type `uint32` à `uint256` et `int64` à`int256`. Tout ce qui est en dessous de `uint32`, tel que `int32`, `uint24` ou `int8` est représenté sous forme de `i32`.
+
+La classe `BigInt` possède l'API suivante :
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – crée un `BigInt` à partir d'un `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Analyse un `BigInt` à partir d'une chaîne de caractères.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprète `bytes` comme un entier non signé en little-endian. Si votre saisie est en big-endian, appelez d'abord `.reverse()`.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprète `bytes` comme un entier signé en little-endian. Si votre saisie est en big-endian, appelez d'abord `.reverse()`.
+
+  _Conversions de type_
+
+- `x.toHex(): string` – transforme `BigInt` en une chaîne de caractères hexadécimaux.
+
+- `x.toString(): string` – transforme`BigInt` en une chaîne de caractères de nombres décimaux.
+
+- `x.toI32(): i32` – renvoie le `BigInt` comme un `i32`; échoue si la valeur ne rentre pas dans un `i32`. Il est conseillé de vérifier d'abord `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - convertit en un nombre décimal sans virgule.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – peut être écrit comme `x + y`.
+- `x.minus(y: BigInt): BigInt` – peut être écrit comme `x - y`.
+- `x.times(y: BigInt): BigInt` – peut être écrit comme `x * y`.
+- `x.div(y: BigInt): BigInt` – peut être écrit comme `x / y`.
+- `x.mod(y: BigInt): BigInt` – peut être écrit comme `x % y`.
+- `x.equals(y: BigInt): bool` – peut être écrit comme `x == y`.
+- `x.notEqual(y: BigInt): bool` – peut être écrit comme `x != y`.
+- `x.lt(y: BigInt): bool` – peut être écrit comme `x < y`.
+- `x.le(y: BigInt): bool` – peut être écrit comme `x <= y`.
+- `x.gt(y: BigInt): bool` – peut être écrit comme `x > y`.
+- `x.ge(y: BigInt): bool` – peut être écrit comme `x >= y`.
+- `x.neg(): BigInt` – peut être écrit comme `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divise par un nombre décimal, donnant un résultat décimal.
+- `x.isZero(): bool` – Est pratique pour vérifier si le nombre est zéro.
+- `x.isI32(): bool` – Vérifie si le nombre rentre dans un `i32`.
+- `x.abs(): BigInt` – Valeur absolue.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – peut être écrit comme `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – peut être écrit comme `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – peut être écrit comme `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – peut être écrit comme `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` peut être utilisé pour stocker des paires clé-valeur. Consultez [cet exemple](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+La classe `TypedMap` possède l'API suivante :
+
+- `new TypedMap<K, V>()` – crée une carte vide avec des clés de type `K` et des valeurs de type `V`
+- `map.set(key: K, value: V): void` – définit la valeur de `key` à `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – renvoie la paire clé-valeur pour une `key` ou `null` si la `key` n'existe pas dans la carte
+- `map.get(key: K): V | null` – renvoie la valeur pour une `key` ou `null` si la `key` n'existe pas dans la carte
+- `map.isSet(key: K): bool` – renvoie `true` si la `key` existe dans la carte et `false` si ce n'est pas le cas
+
+#### Octets
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` est utilisé pour représenter des tableaux d'octets de longueur arbitraire. Ceci inclut les valeurs Ethereum de type `bytes`, `bytes32`, etc.
+
+La classe `Bytes` hérite de [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) d'AssemblyScript et prend en charge toutes les fonctionnalités de `Uint8Array` ainsi que les nouvelles méthodes suivantes :
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convertit la chaîne de caractères `hex` qui doit comporter un nombre pair de chiffres hexadécimaux en un `ByteArray`. La chaîne de caractères `hex` peut de façon optionnelle commencer par `0x`
+- `fromI32(i: i32) : Bytes` - Convertit `i` en un tableau de d'octets
+
+_Conversions de type_
+
+- `b.toHex()` – renvoie une chaîne de caractères hexadécimale représentant les octets dans le tableau
+- `b.toString()` – convertit les octets dans le tableau en une chaîne de caractères unicode
+- `b.toBase58()` – convertit une valeur Ethereum Bytes en codage de type base58 (utilisé pour les hachages IPFS)
+
+_Operateurs_
+
+- `b.concat(other: Bytes) : Bytes` - - renvoie un nouveau `Bytes` constitué de `this` suivi directement de `other`
+- `b.concatI32(other: i32) : ByteArray` - renvoie un nouveau `Bytes` constitué de `this` suivi directement de la représentation en octets de `other`
+
+#### Addresse
+
+```typescript
+import { Address } du '@graphprotocol/graph-ts'
+```
+
+`Address` hérite de `Bytes` pour représenter les valeurs `address` d'Ethereum.
+
+Cela ajoute la méthode suivante en plus de l'API `Bytes` :
+
+- `Address.fromString(s: string): Address` – crée une `Address` à partir d'une chaîne de caractères hexadécimale
+- `Address.fromBytes(b: Bytes): Address` – crée une `Address` à partir de `b` qui doit avoir exactement 20 octets de long. Passer une valeur avec moins ou plus d'octets entraînera une erreur
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+L'API `store` permet de charger, sauvegarder et supprimer des entités dans et depuis le magasin Graph Node.
+
+Les entités écrites dans le magasin correspondent directement aux types `@entity` définis dans le schéma GraphQL du subgraph. Pour faciliter le travail avec ces entités, la commande `graph codegen` fournie par [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) génère des classes d'entités, qui sont des sous-classes du type `Entity` intégré, avec des accesseurs et des mutateurs pour les champs du schéma ainsi que des méthodes pour charger et sauvegarder ces entités.
+
+#### Création d'entités
+
+Ce qui suit est un modèle courant pour créer des entités à partir d’événements Ethereum.
+
+```typescript
+// Importer la classe Transfer générée à partir de l'ABI ERC20
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Importer le type d'entité Transfer généré à partir du schéma GraphQL
+import { Transfer } from '../generated/schema'
+
+// Gestionnaire d'événement Transfer
+export function handleTransfer(event: TransferEvent): void {
+  // Créer une entité Transfer, en utilisant le hash de la transaction comme ID de l'entité
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Définir les propriétés sur l'entité, en utilisant les paramètres de l'événement
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Sauvegarder l'entité dans le stockage
+  transfer.save()
+}
+```
+
+Lorsqu'un événement `Transfer` est rencontré lors du traitement de la blockchain, il est transmis au gestionnaire d'événements `handleTransfer` en utilisant le type `Transfer` généré (ayant pour pseudonyme `TransferEvent` ici pour éviter un conflit de nom avec le type d'entité). Ce type permet d'accéder à des données telles que la transaction parente de l'événement et ses paramètres.
+
+Chaque entité doit avoir un ID unique pour éviter les collisions avec d'autres entités. Il est assez courant que les paramètres des événements incluent un identifiant unique pouvant être utilisé.
+
+> Remarque : utiliser le hash de la transaction comme ID suppose qu'aucun autre événement dans la même transaction ne crée d'entités avec ce hash comme ID.
+
+#### Chargement d'entités depuis le magasin
+
+Si une entité existe déjà, elle peut être chargée depuis le magasin avec les éléments suivants :
+
+```typescript
+let id = event.transaction.hash // ou selon la manière dont l'ID est construit
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Utiliser l'entité Transfer comme précédemment
+```
+
+Comme l'entité peut ne pas encore exister dans le magasin, la méthode `load` renvoie une valeur de type `Transfer | null`. Il peut être nécessaire de vérifier le cas `null` avant d'utiliser la valeur.
+
+> Remarque : Le chargement des entités n'est nécessaire que si les modifications apportées dans le mappage dépendent des données précédentes d'une entité. Consultez la section suivante pour savoir les deux façons de mettre à jour les entités existantes.
+
+#### Recherche d'entités créées dans un bloc
+
+Depuis `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 et `@graphprotocol/graph-cli` v0.49.0 la méthode `loadInBlock` est disponible pour tous les types d'entités.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- Dans le cas où la transaction n'existe pas, le subgraph devra interroger la base de données pour découvrir que l'entité n'existe pas. Si l'auteur du subgraph sait déjà que l'entité doit avoir été créée dans le même bloc, utiliser `loadInBlock` évite ce détour par la base de données.
+- Pour certains subgraphs, ces recherches infructueuses peuvent contribuer de manière significative au temps d'indexation.
+
+```typescript
+let id = event.transaction.hash // ou de toute autre manière dont l'ID est construit
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Utiliser l'entité Transfer comme auparavant
+```
+
+> Remarque : S'il n'y a pas d'entité créée dans le bloc donné, `loadInBlock` renverra `null` même s'il y a une entité avec l'ID donné dans le magasin.
+
+#### Recherche d'entités dérivées
+
+Depuis `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 et`@graphprotocol/graph-cli` v0.51.0 la méthode `loadRelated` est disponible.
+
+Cela permet de charger des champs d'entités dérivés à partir d'un gestionnaire d'événements. Par exemple, étant donné le schéma suivant :
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+Le code suivant chargera l'entité `Token` dont l'entité `Holder`est dérivée :
+
+```typescript
+let holder = Holder.load('test-id')
+// Charger les entités Token associées à un détenteur donné
+let tokens = holder.tokens.load()
+```
+
+#### Mise à jour des entités existantes
+
+Il existe deux manières de mettre à jour une entité existante :
+
+1. Chargez l'entité avec, par exemple, `Transfer.load(id)`, définissez des propriétés sur l'entité, puis `.save()` pour la sauvegarder dans le magasin.
+2. Créez simplement l'entité avec, par exemple, `new Transfer(id)`, séfinissez des propriétés sur l'entité, puis `.save()` pour la sauvegarder dans le magasin. Si l'entité existe déjà, les modifications y sont fusionnées.
+
+La modification des propriétés est simple dans la plupart des cas, grâce aux paramètres de propriétés générés :
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+Il est également possible de supprimer des propriétés avec l'une des deux instructions suivantes :
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+Ceci ne fonctionne qu'avec des propriétés optionnelles, c'est-à-dire des propriétés déclarées sans `!` dans GraphQL. Deux exemples seraient `owner: Bytes` ou `amount: BigInt`.
+
+La mise à jour des propriétés de tableau est un peu plus complexe, car obtenir un tableau à partir d'une entité crée une copie de ce tableau. Cela signifie que les propriétés de tableau doivent être définies à nouveau explicitement après la modification du tableau. Ce qui suit suppose que `entity` a un champ `numbers: [BigInt!]!` .
+
+```typescript
+// Cela ne fonctionnera pas
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// Cela fonctionnera
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Supprimer des entités du magasin
+
+Il n'y a actuellement aucun moyen de supprimer une entité via les types générés. Au lieu de cela, la suppression d'une entité nécessite de passer le nom du type d'entité et l'ID de l'entité à `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+L'API Ethereum donne accès aux contrats intelligents, aux variables d'état public, aux fonctions de contrat, aux événements, aux transactions, aux blocs et aux données d'encodage/décodage Ethereum.
+
+#### Prise en charge des types Ethereum
+
+Comme pour les entités, `graph codegen` génère des classes pour tous les contrats intelligents et événements utilisés dans un subgraph. Pour cela, les ABIs des contrats doivent faire partie de la source de données dans le manifeste du subgraph. En général, les fichiers ABI sont stockés dans un dossier `abis/` .
+
+Avec les classes générées, les conversions entre les types Ethereum et [les types intégrés](#built-in-types) se font en arrière-plan afin que les auteurs de subgraph n'aient pas à s'en soucier.
+
+L’exemple suivant illustre cela. Étant donné un schéma de subgraph comme
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+et une signature d'événement `Transfer(address,address,uint256)` sur Ethereum, les valeurs `from`, `to` et`amount` de type `address`, `address` et `uint256` sont enverties en `Address` et `BigInt`, leur permettant d'être passées aux propriétés `Bytes!` et `BigInt!` de l'entité `Transfer` :
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Événements et données de bloc/transaction
+
+Les événements Ethereum passés aux gestionnaires d'événements, comme l'événement `Transfer` dans les exemples précédents, fournissent non seulement l'accès aux paramètres de l'événement, mais également à leur transaction parente et au bloc auquel ils appartiennent. Les données suivantes peuvent être obtenues à partir des instances d' `event` (ces classes font partie du module `ethereum` dans `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Accès à l'état du contrat intelligent
+
+Le code généré par `graph codegen` inclut également des classes pour les contrats intelligents utilisés dans le subgraph. Celles-ci peuvent être utilisées pour accéder aux variables d'état publiques et appeler des fonctions du contrat au bloc actuel.
+
+Un modèle courant consiste à accéder au contrat dont provient un événement. Ceci est réalisé avec le code suivant :
+
+```typescript
+// Importer la classe de contrat générée et la classe d'événement Transfer générée
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Importer la classe d'entité générée
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Lier le contrat à l'adresse qui a émis l'événement
+  let contract = ERC20Contract.bind(event.address)
+
+  // Accéder aux variables d'état et aux fonctions en les appelant
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` est remplacé par `TransferEvent` ici pour éviter un conflit de nommage avec le type d'entité
+
+Tant que le `ERC20Contract` sur Ethereum a une fonction publique en lecture seule appelée `symbol`, elle peut être appelée avec `.symbol()`. Pour les variables d'état publiques, une méthode du même nom est créée automatiquement.
+
+Tout autre contrat faisant partie du subgraph peut être importé à partir du code généré et peut être lié à une adresse valide.
+
+#### Gestion des appels retournés
+
+Si les méthodes en lecture seule de votre contrat peuvent échouer, vous devez gérer cela en appelant la méthode de contrat générée préfixée par `try_`.
+
+- Par exemple, le contrat Gravity expose la méthode `gravatarToOwner` . Ce code serait capable de gérer une erreur dans cette méthode :
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar a été annulé', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Remarque : Un Graph Node connecté à un client Geth ou Infura peut ne pas détecter toutes les réversions (reverts). Si vous en dépendez, nous recommandons d'utiliser un Graph Node connecté à un client Parity.
+
+#### Encodage/décodage ABI
+
+Les données peuvent être encodées et décodées selon le format de codage ABI d'Ethereum en utilisant les fonctions `encode` et `decode` du module `ethereum`.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+Pour plus d'informations:
+
+- [Spécifications ABI](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encodage/décodage [bibliothèque Rust/CLI] (https://github.com/rust-ethereum/ethabi)
+- Exemple [plus complexe](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Solde d'une adresse
+
+Le solde de jetons natifs d'une adresse peut être récupéré en utilisant le module `ethereum`. Cette fonctionnalité est disponible à partir de `apiVersion: 0.0.9` définie dans `subgraph.yaml`. La fonction `getBalance()` récupère le solde de l'adresse spécifiée à la fin du bloc où l'événement est déclenché.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // renvoie le solde en BigInt
+```
+
+#### Vérifier si une adresse est une adresse de contrat intelligent ou une adresse détenue par des personnes (EOA)
+
+Pour vérifier si une adresse est une adresse de contrat intelligent ou une adresse détenue extérieurement (EOA), utilisez la fonction `hasCode()` du module `ethereum` qui retournera un `boolean`. Cette fonctionnalité est disponible à partir de `apiVersion: 0.0.9` qui est définie dans `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // renvoie true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // renvoie false
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+L'API `log` permet aux subgraphs d'enregistrer des informations sur la sortie standard de Graph Node ainsi que sur Graph Explorer. Les messages peuvent être enregistrés en utilisant différents niveaux de journalisation. Une syntaxe de chaîne de caractère de format de base est fournie pour composer des messages de journal à partir de l'argument.
+
+L'API `log` inclut les fonctions suivantes :
+
+- `log.debug(fmt: string, args: Array<string>): void` - enregistre un message de débogage.
+- `log.info(fmt: string, args: Array<string>): void` - enregistre un message d'information.
+- `log.warning(fmt: string, args: Array<string>): void` - enregistre un avertissement.
+- `log.error(fmt: string, args: Array<string>): void` - enregistre un message d'erreur.
+- `log.critical(fmt: string, args: Array<string>): void` – enregistre un message critique _et_ met fin au subgraph.
+
+L'API `log` prend une chaîne de caractères de format et un tableau de valeurs de chaîne de caractères. Elle remplace ensuite les espaces réservés par les valeurs de chaîne de caractères du tableau. Le premier espace réservé `{}` est remplacé par la première valeur du tableau, le second `{}` est remplacé par la deuxième valeur, et ainsi de suite.
+
+```typescript
+log.info('Message à afficher : {}, {}, {}', [value.toString(), anotherValue.toString(), 'déjà une chaîne'])
+```
+
+#### Enregistrer une ou plusieurs valeurs
+
+##### Enregistrer une seule valeur
+
+Dans l'exemple ci-dessous, la valeur de chaîne de caractères "A" est passée dans un tableau pour devenir `['A']` avant d'être enregistrée:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Affiche : "Ma valeur est : A"
+  log.info('Ma valeur est : {}', [myValue])
+}
+```
+
+##### Journalisation d'une seule entrée à partir d'un tableau existant
+
+Dans l'exemple ci-dessous, seule la première valeur du tableau d'arguments est journalisée, bien que le tableau contienne trois valeurs.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Affiche : "Ma valeur est : A"  (Même si trois valeurs sont passées à `log.info`)
+  log.info('Ma valeur est : {}', myArray)
+}
+```
+
+#### Journalisation de plusieurs entrées d'un tableau existant
+
+Chaque entrée dans le tableau des arguments nécessite son propre espace réservé `{}` dans la chaîne de caractères du message de log. L'exemple ci-dessous contient trois espaces réservés `{}` dans le message de log. À cause de cela, toutes les trois valeurs dans `myArray` sont enregistrées.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Affiche : "Ma première valeur est : A, la deuxième valeur est : B, la troisième valeur est : C"
+  log.info('Ma première valeur est : {}, la deuxième valeur est : {}, la troisième valeur est : {}', myArray)
+}
+```
+
+##### Enregistrer une entrée spécifique à partir d'un tableau existant
+
+Pour afficher une valeur spécifique dans le tableau, la valeur indexée doit être fournie.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Affiche : "Ma troisième valeur est C"
+  log.info('Ma troisième valeur est : {}', [myArray[2]])
+}
+```
+
+##### Journalisation des informations sur les événements
+
+L'exemple ci-dessous enregistre le numéro de bloc, le hachage de bloc et le hachage de transaction d'un événement :
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Numéro de bloc : {}, hachage de bloc : {}, hachage de transaction : {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Étant donné un hachage ou un chemin IPFS, la lecture d'un fichier depuis IPFS se fait comme suit :
+
+```typescript
+// Mettez ceci à l'intérieur d'un gestionnaire d'événements dans le mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Les chemins comme `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// qui incluent des fichiers dans des répertoires sont également pris en charge
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Remarque:** `ipfs.cat` n'est pas déterministe pour le moment. Si le fichier ne peut pas être récupéré sur le réseau IPFS avant l'expiration de la demande, il retournera `null`. Pour cette raison, il est toujours utile de vérifier le résultat pour `null`.
+
+Il est également possible de traiter des fichiers plus volumineux en streaming avec `ipfs.map`. La fonction s'attend à recevoir un hash ou à un chemin pour un fichier IPFS, le nom d'un callback, et des indicateurs pour modifier son comportement :
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // Voir la documentation JSONValue pour les détails sur le traitement
+  // des valeurs JSON
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Les callbacks peuvent également créer des entités
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newItem.parent = userData.toString() // Définit le parent à "parentId"
+  newItem.save()
+}
+
+// Mettez ceci à l'intérieur d'un gestionnaire d'événements dans le mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternativement, utilisez `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+Le seul indicateur actuellement pris en charge est `json`, qui doit être passé à `ipfs.map`. Avec l'indicateur `json` , le fichier IPFS doit consister en une série de valeurs JSON, une valeur par ligne. L'appel à `ipfs.map` lira chaque ligne du fichier, la désérialisera en un `JSONValue` et appellera le callback pour chacune d'entre elles. Le callback peut alors utiliser des opérations des entités pour stocker des données à partir du `JSONValue`. Les modifications d'entité ne sont enregistrées que lorsque le gestionnaire qui a appelé `ipfs.map` se termine avec succès ; en attendant, elles sont conservées en mémoire, et la taille du fichier que `ipfs.map` peut traiter est donc limitée.
+
+En cas de succès, `ipfs.map` renvoie `void`. Si une invocation du callback provoque une erreur, le gestionnaire qui a invoqué `ipfs.map` est interrompu et le subgraph marqué comme échoué.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+L'API `crypto` rend des fonctions cryptographiques disponibles pour une utilisation dans les mappages. Actuellement, il n'y en a qu'une seule :
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+Les données JSON peuvent être analysées en utilisant l'API `json`:
+
+- `json.fromBytes(data: Bytes): JSONValue` – analyse les données JSON à partir d'un tableau `Bytes` interprété comme une séquence UTF-8 valide
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – version sécurisée de `json.fromBytes`, elle renvoie une variante d'erreur si l'analyse échoue
+- `json.fromString(data: string): JSONValue` – analyse les données JSON à partir d'une `String` UTF-8 valide
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – version sécurisée de `json.fromString`, elle renvoie une variante d'erreur si l'analyse échoue
+
+La classe `JSONValue` fournit un moyen d'extraire des valeurs d'un document JSON arbitraire. Étant donné que les valeurs JSON peuvent être des booléens, des nombres, des tableaux et plus encore, `JSONValue` est accompagné d'une propriété `kind` pour vérifier le type d'une valeur :
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+De plus, il existe une méthode pour vérifier si la valeur est `null`:
+
+- `value.isNull(): boolean`
+
+Lorsque le type d'une valeur est certain, il peut être converti en un [type intégré](#built-in-types) n utilisant l'une des méthodes suivantes :
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (et ensuite convertir `JSONValue` avec l'une des 5 méthodes ci-dessus)
+
+### Référence des conversions de types
+
+| Source(s)             | Destination          | Fonctions de conversion          |
+| --------------------- | -------------------- | -------------------------------- |
+| Address               | Bytes                | aucune                           |
+| Address               | String               | s.toHexString()                  |
+| BigDecimal            | String               | s.toString()                     |
+| BigInt                | BigDecimal           | s.toBigDecimal()                 |
+| BigInt                | String (hexadecimal) | s.toHexString() or s.toHex()     |
+| BigInt                | String (unicode)     | s.toString()                     |
+| BigInt                | i32                  | s.toI32()                        |
+| Boolean               | Boolean              | aucune                           |
+| Bytes (signé)         | BigInt               | BigInt.fromSignedBytes(s)        |
+| Bytes (non signé)     | BigInt               | BigInt.fromUnsignedBytes(s)      |
+| Bytes                 | String (hexadecimal) | s.toHexString() or s.toHex()     |
+| Bytes                 | String (unicode)     | s.toString()                     |
+| Bytes                 | String (base58)      | s.toBase58()                     |
+| Bytes                 | i32                  | s.toI32()                        |
+| Bytes                 | u32                  | s.toU32()                        |
+| Bytes                 | JSON                 | json.fromBytes(s)                |
+| int8                  | i32                  | aucune                           |
+| int32                 | i32                  | aucune                           |
+| int32                 | BigInt               | BigInt.fromI32(s)                |
+| uint24                | i32                  | aucune                           |
+| int64 - int256        | BigInt               | aucune                           |
+| uint32 - uint256      | BigInt               | aucune                           |
+| JSON                  | boolean              | s.toBool()                       |
+| JSON                  | i64                  | s.toI64()                        |
+| JSON                  | u64                  | s.toU64()                        |
+| JSON                  | f64                  | s.toF64()                        |
+| JSON                  | BigInt               | s.toBigInt()                     |
+| JSON                  | string               | s.toString()                     |
+| JSON                  | Array                | s.toArray()                      |
+| JSON                  | Object               | s.toObject()                     |
+| String                | Address              | Address.fromString(s)            |
+| Bytes                 | Address              | Address.fromBytes(s)             |
+| String                | BigInt               | BigInt.fromString(s)             |
+| String                | BigDecimal           | BigDecimal.fromString(s)         |
+| String (hexadecimal)  | Bytes                | ByteArray.fromHexString(s)       |
+| String (UTF-8)        | Bytes                | ByteArray.fromUTF8(s)            |
+
+### Métadonnées de la source de données
+
+Vous pouvez inspecter l'adresse du contrat, le réseau et le contexte de la source de données qui a invoqué le gestionnaire grâce un namespace `dataSource` :
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entité et DataSourceContext
+
+La classe de base `Entity` et la classe enfant `DataSourceContext` disposent d'assistants pour définir et récupérer dynamiquement des champs :
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+La section `context` de `dataSources` vous permet de définir des paires clé-valeur qui sont accessibles dans vos mappages de subgraphs. Les types disponibles sont `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, et `BigInt`.
+
+Voici un exemple YAML illustrant l'utilisation de différents types dans la section `context` :
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool` : Spécifie une valeur booléenne (`true` ou `false`).
+- `String` : Spécifie une valeur de type chaîne de caractères.
+- `Int` : Spécifie un nombre entier de 32 bits.
+- `Int8` : Spécifie un entier de 8 bits.
+- `BigDecimal` : Spécifie un nombre décimal. Doit être entre mis guillemets.
+- `Bytes` : Spécifie une chaîne de caractères hexadécimale.
+- `List` : Spécifie une liste d'éléments. Chaque élément doit spécifier son type et ses données.
+- `BigInt` : Spécifie une grande valeur entière. Elle doit être mise entre guillemets en raison de sa grande taille.
+
+Ce contexte est ensuite accessible dans vos fichiers de mappage de subgraphs, permettant des subgraphs plus dynamiques et configurables.

From 7015533e69691a59194f05d297b33920bd1266eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:28 -0500
Subject: [PATCH 0730/3820] New translations common-issues.mdx (French)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/fr/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/fr/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..37d2e382794e
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Common AssemblyScript Issues
+---
+
+Il existe certains problèmes courants avec [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) lors du développement de subgraph. Ces problèmes varient en termes de difficulté de débogage, mais les connaître peut être utile. Voici une liste non exhaustive de ces problèmes :
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- La portée n'est pas héritée dans les [fonctions de fermeture] (https://www.assemblyscript.org/status.html#on-closures), c'est-à-dire que les variables déclarées en dehors des fonctions de fermeture ne peuvent pas être utilisées. Explication dans les [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 81de996f67296a6ab4dfa42617547b9b3c84a4ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:29 -0500
Subject: [PATCH 0731/3820] New translations unit-testing-framework.mdx
 (French)

---
 .../creating/unit-testing-framework.mdx       | 1401 +++++++++++++++++
 1 file changed, 1401 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..5528316d8f9f
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1401 @@
+---
+title: Cadre pour les tests unitaires
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Démarrage
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt installer postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+Vous pouvez utiliser Matchstick sur WSL en utilisant à la fois l'approche Docker et l'approche binaire. Comme WSL peut être un peu délicat, voici quelques conseils au cas où vous rencontreriez des problèmes tels que
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+ou bien
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+Cette opération permet d'exécuter tous les tests contenus dans le dossier test :
+
+```sh
+graph test
+```
+
+Ceci lancera un test nommé gravity.test.ts et/ou tous les tests à l'intérieur d'un dossier nommé gravity :
+
+```sh
+gravity graph test
+```
+
+Ce fichier de test sera le seul à être exécuté :
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### La Configuration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Subgraph démonstration
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Tutoriels vidéos
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Structure des tests
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### décrivez()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+L'exemple:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### tester ()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+L'exemple:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+ou bien
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### avantTout()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Les Exemples:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+L'exemple:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Les Exemples:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Assertions
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+À partir de la version 0.6.0, les assertions supportent également les messages d'erreur personnalisés
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Écrire un test unitaire
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+En supposant que nous disposions de la fonction de traitement suivante (ainsi que de deux fonctions d'aide pour nous faciliter la vie) :
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+Nous devons tout d'abord créer un fichier de test dans notre projet. Voici un exemple de ce à quoi cela pourrait ressembler :
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- Mettons en place notre état initial et ajoutons une entité Gravatar personnalisée ;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- Affirmons l'état du magasin. Comment cela fonctionne-t-il ? - Nous passons une combinaison unique de type d'entité et d'identifiant. Ensuite, nous vérifions un champ spécifique de cette entité et affirmons qu'il a la valeur que nous attendons. Nous faisons cela à la fois pour l'entité Gravatar initiale que nous avons ajoutée au magasin, ainsi que pour les deux entités Gravatar qui sont ajoutées lorsque la fonction de gestion est appelée ;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+Et voilà, nous avons formulé notre premier test ! 👏
+
+Maintenant, afin d'exécuter nos tests, il suffit d'exécuter ce qui suit dans le dossier racine de votre subgraph :
+
+`graph test Gravity`
+
+Et si tout se passe bien, vous devriez être accueilli par ce qui suit :
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Scénarios de tests actuels
+
+### L'Hydratation du magasin avec un certain état
+
+Les utilisateurs peuvent hydrater le magasin avec un ensemble connu d'entités. Voici un exemple pour initialiser la boutique avec une entité Gravatar :
+
+```typescript
+laissez gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Appel d'une fonction de cartographie avec un événement
+
+Un utilisateur peut créer un événement personnalisé et le transmettre à une fonction de cartographie liée au magasin :
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Appel de tous les mappages avec des projecteurs d'événements
+
+Les utilisateurs peuvent appeler les mappages avec des dispositifs de test.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Appels de contrat moqueurs
+
+Les utilisateurs peuvent simuler des appels de contrat :
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+Comme démontré, afin de se moquer d'un appel de contrat et d'obtenir une valeur de retour, l'utilisateur doit fournir une adresse de contrat, un nom de fonction, une signature de fonction, un tableau d'arguments et bien sûr – la valeur de retour.
+
+Utilisateurs peuvent également simuler des annulations de fonctions :
+
+```typescript
+laissez contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+   .withArgs([ethereum.Value.fromAddress(contractAddress)])
+   .reverts()
+```
+
+### Se moquer des fichiers IPFS (à partir de Matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// rappel ipfs.map
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // Consultez la documentation de JSONValue pour plus de détails sur la façon de traiter les données.
+  // avec JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Des entités de rappel peuvent également être créées
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// fonction qui appelle ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Affirmation de l'état du magasin
+
+Les utilisateurs sont en mesure d'affirmer l'état final (ou intermédiaire) du magasin via des entités d'affirmation. Pour ce faire, l'utilisateur doit fournir un type d'entité, l'ID spécifique d'une entité, le nom d'un champ sur cette entité et la valeur attendue du champ. Voici un exemple rapide:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interagir avec les métadonnées d'événement
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Lisez
+let logType = newGravatarEvent.logType
+
+// Écrivez
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Affirmation de l'égalité des variables
+
+```typescript
+assert.equals(ethereum.Value.fromString("bonjour"); ethereum.Value.fromString("bonjour"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Les utilisateurs peuvent affirmer qu'une entité n'existe pas dans le magasin. La fonction prend un type d'entité et un identifiant. Si l'entité se trouve effectivement dans le magasin, le test échouera avec un message d'erreur pertinent. Voici un exemple rapide de la façon d'utiliser cette fonctionnalité :
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Affichage de tout le magasin ou d'entités individuelles (à des fins de débogage)
+
+Vous pouvez imprimer l'intégralité du magasin sur la console à l'aide de cette fonction d'assistance:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Échec prévu
+
+Les utilisateurs peuvent s'attendre à des échecs de test, en utilisant l'indicateur ShouldFail sur les fonctions test() :
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+Si le test est marqué avec ShouldFail = true mais n'échoue PAS, cela apparaîtra comme une erreur dans les journaux et le bloc de test échouera. De plus, s'il est marqué avec ShouldFail = false (l'état par défaut), l'exécuteur de test plantera.
+
+### Journal de bord
+
+Avoir des journaux personnalisés dans les tests unitaires équivaut exactement à la journalisation des mappages. La différence est que l'objet journal doit être importé depuis matchstick-as plutôt que graph-ts. Voici un exemple simple avec tous les types de journaux non critiques :
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Les utilisateurs peuvent également simuler une panne critique, comme ceci :
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+La journalisation des erreurs critiques arrêtera l’exécution des tests et fera tout exploser. Après tout, nous voulons nous assurer que votre code ne contient pas de journaux critiques lors du déploiement, et vous devriez le remarquer immédiatement si cela devait se produire.
+
+### Tests dérivés
+
+Tester les champs dérivés est une fonctionnalité qui permet aux utilisateurs de définir un champ sur une certaine entité et de faire en sorte qu'une autre entité soit automatiquement mise à jour si elle dérive l'un de ses champs de la première entité.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Tester les sources de données dynamiques
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+L'exemple ci-dessous :
+
+Nous avons d’abord le gestionnaire d’événements suivant (qui a été intentionnellement réutilisé pour présenter la moquerie de la source de données) :
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+Et puis nous avons le test utilisant l'une des méthodes de l'espace de noms dataSourceMock pour définir une nouvelle valeur de retour pour toutes les fonctions dataSource :
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Notez que dataSourceMock.resetValues() est appelé à la fin. C'est parce que les valeurs sont mémorisées lorsqu'elles sont modifiées et doivent être réinitialisées si vous voulez revenir aux valeurs par défaut.
+
+### Test de la création dynamique de sources de données
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+  - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Portefeuilles de verrouillage de jetons qui contiennent des GRT verrouillés
+"""
+type TokenLockMetadata @entity {
+  "L'adresse du portefeuille de blocage des jetons"
+  id: ID!
+  "Heure de début du calendrier de sortie"
+  startTime: BigInt!
+  "Heure de fin du calendrier de sortie""
+  endTime: BigInt!
+  "Nombre de périodes entre l'heure de début et l'heure de fin"
+  periods: BigInt!
+  "Heure à laquelle commence la sortie"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Exemple de gestionnaire
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Exemple de test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Couverture de test
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Conditions préalables
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Exportez vos gestionnaires
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+importez { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+exportez { handleNewGravatar }
+```
+
+### Usage
+
+Une fois tout configuré, pour exécuter l'outil de couverture de test, exécutez simplement :
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+Cela exécutera l'outil de couverture et vous devriez voir quelque chose comme ceci dans le terminal :
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Durée d'exécution du test dans la sortie du journal
+
+La sortie du journal inclut la durée de l’exécution du test. Voici un exemple :
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Erreurs de compilation courantes
+
+> Critique : impossible de créer WasmInstance à partir d'un module valide avec un contexte : importation inconnue : wasi_snapshot_preview1::fd_write n'a pas été défini
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERREUR TS2554 : attendu ? arguments, mais j'ai eu ?.
+>
+> renvoyer le nouveau ethereum.Block (defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt) ;
+>
+> dans ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERREUR TS2554 : attendu ? arguments, mais j'ai eu ?.
+>
+> renvoyer un nouveau ethereum.Transaction (defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt) ;
+>
+> dans ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Ressources complémentaires
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Réaction
+
+Si vous avez des questions, des commentaires, des demandes de fonctionnalités ou si vous souhaitez simplement nous contacter, le meilleur endroit serait The Graph Discord où nous avons une chaîne dédiée à Matchstick, appelée 🔥| tests unitaires.

From 1a297f690453fe92165d95e09f9aff5c98ae80f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:30 -0500
Subject: [PATCH 0732/3820] New translations transferring-a-subgraph.mdx
 (French)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/fr/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/fr/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0dcb040eb00d
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Les subgraphs publiés sur le réseau décentralisé possèdent un NFT minté à l'adresse qui a publié le subgraph. Le NFT est basé sur la norme ERC721, ce qui facilite les transferts entre comptes sur The Graph Network.
+
+## Rappels
+
+- Quiconque possède le NFT contrôle le subgraph.
+- Si le propriétaire décide de vendre ou de transférer le NFT, il ne pourra plus éditer ou mettre à jour ce subgraph sur le réseau.
+- Vous pouvez facilement déplacer le contrôle d'un subgraph vers un multi-sig.
+- Un membre de la communauté peut créer un subgraph au nom d'une DAO.
+
+## Voir votre Subgraph en tant que NFT
+
+Pour voir votre subgraph en tant que NFT, vous pouvez visiter une marketplace NFT telle que **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Ou un explorateur de portefeuille comme **Rainbow.me**:
+
+```
+https://rainbow.me/adresse-de-votre-portefeuille
+```
+
+## Étape par Étape
+
+Pour transférer la propriété d'un subgraph, procédez comme suit :
+
+1. Utilisez l'interface utilisateur intégrée dans Subgraph Studio :
+
+   ![Transfert de propriété de subgraph](/img/subgraph-ownership-transfer-1.png)
+
+2. Choisissez l'adresse vers laquelle vous souhaitez transférer le subgraph :
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionnellement, vous pouvez également utiliser l'interface utilisateur intégrée dans les marketplaces NFT comme OpenSea :
+
+![Transfert de propriété de subgraph depuis la marketplace NFT](/img/subgraph-ownership-transfer-nft-marketplace.png)

From a728cdbabc05daa9198962312444655d7f5b30c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:31 -0500
Subject: [PATCH 0733/3820] New translations graphql-api.mdx (French)

---
 .../fr/subgraphs/querying/graphql-api.mdx     | 434 ++++++++++++++++++
 1 file changed, 434 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/fr/subgraphs/querying/graphql-api.mdx b/website/pages/fr/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..40f107eface9
--- /dev/null
+++ b/website/pages/fr/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,434 @@
+---
+title: API GraphQL
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## Qu'est-ce que GraphQL ?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Exemples
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Tri
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Exemple
+
+```graphql
+{
+  tokens(orderBy : price, orderDirection : asc) {
+    id
+    propriétaire
+  }
+}
+```
+
+#### Exemple de tri d'entités imbriquées
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+   jetons (orderBy : propriétaire__nom, orderDirection : asc) {
+     identifiant
+     propriétaire {
+       {
+      name
+    }
+     }
+   }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Pagination
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Interroger les 10 premiers tokens :
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtration
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Exemple de filtrage de plage
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Exemple de filtrage par bloc
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+Cela peut être utile si vous cherchez à récupérer uniquement les entités qui ont changé, par exemple depuis la dernière fois que vous avez interrogé. Ou bien, il peut être utile d'étudier ou de déboguer la façon dont les entités changent dans votre subgraph (si combiné avec un filtre de bloc, vous pouvez isoler uniquement les entités qui ont changé dans un bloc spécifique).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Exemple de filtrage d'entités imbriquées
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+Cela peut être utile si vous souhaitez récupérer uniquement les entités dont les entités au niveau enfant remplissent les conditions fournies.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Opérateurs logiques
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### Tous les filtres
+
+Liste complète des suffixes de paramètres :
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(numéro_gte : Int)
+```
+
+### Interrogation des états précédents
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Exemple
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Exemple
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Requêtes de recherche en texte intégral
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Opérateurs de recherche en texte intégral :
+
+| Symbole | Opérateur   | Description                                                                                                                                            |
+| ------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `And`       | Pour combiner plusieurs termes de recherche dans un filtre pour les entités incluant tous les termes fournis                                           |
+| |       | `Or`        | Les requêtes comportant plusieurs termes de recherche séparés par l'opérateur ou renverront toutes les entités correspondant à l'un des termes fournis |
+| `<->`   | `Follow by` | Spécifiez la distance entre deux mots.                                                                                                                 |
+| `:*`    | `Prefix`    | Utilisez le terme de recherche de préfixe pour trouver les mots dont le préfixe correspond (2 caractères requis.)                                      |
+
+#### Exemples
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combinez des opérateurs de texte intégral pour créer des filtres plus complexes. Avec un opérateur de recherche de prétexte combiné à un suivi de cet exemple, la requête fera correspondre toutes les entités de blog avec des mots commençant par « lou » suivi de « musique ».
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validation
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Métadonnées du Subgraph
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+Si un bloc est fourni, les métadonnées sont celles de ce bloc, sinon le dernier bloc indexé est utilisé. S'il est fourni, le bloc doit être postérieur au bloc de départ du subgraph et inférieur ou égal au bloc indexé le plus récent.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash : le hash du bloc
+- number: the block number
+- timestamp : l'horodatage du bloc, si disponible (ceci n'est actuellement disponible que pour les subgraphs indexant les réseaux EVM)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 1f5269418825b4c78a2384f0a4008ab7e91148b5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:32 -0500
Subject: [PATCH 0734/3820] New translations python.mdx (French)

---
 .../pages/fr/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/querying/python.mdx

diff --git a/website/pages/fr/subgraphs/querying/python.mdx b/website/pages/fr/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..56ad17c8a8be
--- /dev/null
+++ b/website/pages/fr/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Interroger The Graph avec Python et Subgrounds
+---
+
+Subgrounds est une librairie Python utilisée pour les requêtes Subgraph. Cette librairie a été conçue par [Playgrounds](https://playgrounds.network/). Subgrounds permet de connecter directement les données d'un Subgraph à un environnement de données Python, permettant l'utilisation de librairies comme [pandas](https://pandas.pydata.org/) afin de faire de l'analyse de données!
+
+Subgrounds propose une API Python simplifiée afin de construire des requêtes GraphQL. Subgrounds automatise les workflows fastidieux comme la pagination, et donne aux utilisateurs avancés plus de pouvoir grâce à des transformations de schéma contrôlées.
+
+## Démarrage
+
+Subgrounds nécessite Python 3.10 ou une version ultérieure. Subgrounds est disponible depuis [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Une fois installé, vous pouvez tester Subgrounds avec la requête suivante. La requête ci-dessous récupère un Subgraph pour le protocole Aave v2 et interroge les 5 principaux marchés par TVL (Total Value Locked - Valeur Totale Verouillée), sélectionne leur nom et leur TVL (en USD) et renvoie les données sous forme de DataFrame Panda [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds est développé et maintenu par l'équipe de [Playgrounds](https://playgrounds.network/) et est accessible depuis la [documentation de Playgrounds](https://docs.playgrounds.network/subgrounds).
+
+Étant donné que Subgrounds propose un large éventail de fonctionnalités, voici quelques points de départ utiles :
+
+- [Commencer avec Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - Une première étape excellente pour apprendre à construire des requêtes avec Subgrounds.
+- [Champs synthétiques](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - Une brève introduction aux champs synthétiques qui transforment vos données à partir du schema.
+- [Requêtes concurrentes](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Améliorez vos requêtes en les parallélisant.
+- [Export de données en CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From b298fe3cad2a873436054cd5e27eff3e8611dbf0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:34 -0500
Subject: [PATCH 0735/3820] New translations triggers.mdx (French)

---
 website/pages/fr/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/fr/substreams/sps/triggers.mdx

diff --git a/website/pages/fr/substreams/sps/triggers.mdx b/website/pages/fr/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/fr/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From c2950a0b2d62a7a1a3bf719c752b9243cb94937f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:35 -0500
Subject: [PATCH 0736/3820] New translations overview.mdx (Spanish)

---
 website/pages/es/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/es/indexing/overview.mdx

diff --git a/website/pages/es/indexing/overview.mdx b/website/pages/es/indexing/overview.mdx
new file mode 100644
index 000000000000..0c27c37d6d31
--- /dev/null
+++ b/website/pages/es/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+
+Los GRT que se depositan en stake en el protocolo está sujeto a un periodo de desbloqueo y puede incurrir en slashing (ser reducidos) si los Indexadores son maliciosos y sirven datos incorrectos a las aplicaciones o si indexan incorrectamente. Los Indexadores también obtienen recompensas por stake delegados de los Delegadores, para contribuir a la red.
+
+Los Indexadores seleccionan subgrafos para indexar basados en la señal de curación del subgrafo, donde los Curadores realizan stake de sus GRT para indicar qué subgrafos son de mejor calidad y deben tener prioridad para ser indexados. Los consumidores (por ejemplo, aplicaciones, clientes) también pueden establecer parámetros para los cuales los Indexadores procesan consultas para sus subgrafos y establecen preferencias para el precio asignado a cada consulta.
+
+<Difficulty level="ADVANCED" />
+
+## Preguntas frecuentes
+
+### ¿Cuál es el stake mínimo necesario para ser Indexador en la red?
+
+El stake mínimo para un Indexador es actualmente de 100.000 GRT.
+
+### ¿Cuáles son las fuentes de ingresos de un Indexador?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### ¿Cómo se distribuyen las recompensas de indexación?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### ¿Qué es una prueba de indexación (POI)?
+
+Las POIs se utilizan en la red para verificar que un Indexador está indexando los subgrafos en los que tiene allocation. Se debe enviar un POI para el primer bloque de la época actual al cerrar una allocation para que dicha allocation pueda optar a las recompensas de indexación. Un POI para un bloque es un resumen de todas las transacciones de las entidades involucradaas en el deployment de un subgrafo específico hasta ese bloque inclusive.
+
+### ¿Cuándo se distribuyen las recompensas de indexación?
+
+Las allocations acumulan recompensas continuamente mientras están activas y asignadas dentro de 28 épocas. Los Indexadores recogen las recompensas y las distribuyen cuando se cierran sus allocations. Esto ocurre manualmente, siempre que el Indexador quiera forzar el cierre, o después de 28 épocas un Delegador puede cerrar la allocation para el Indexador, pero esto da como resultado que no se generen recompensas. 28 épocas es la duración máxima de la allocation (ahora mismo, una época dura unas 24 horas).
+
+### ¿Se pueden monitorear las recompensas de indexación pendientes?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Muchos de los paneles creados por la comunidad incluyen valores de recompensas pendientes y se pueden verificar fácilmente de forma manual siguiendo estos pasos:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### ¿Qué son las disputas y dónde puedo verlas?
+
+Las consultas y allocation del Indexador se pueden disputar en The Graph durante el período de disputa. El período de disputa varía según el tipo de disputa. Las consultas tienen una ventana de disputa de 7 épocas, mientras que las allocation tienen 56 épocas. Una vez transcurridos estos períodos, no se pueden abrir disputas contra allocation o consultas. Cuando se abre una disputa, los Fishermen requieren un depósito mínimo de 10,000 GRT, que permanecerá bloqueado hasta que finalice la disputa y se haya dado una resolución. Los Fishermen (o pescadores) son todos los participantes de la red que abren disputas.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- Si se rechaza la disputa, los GRT depositados por los Fishermen se quemarán y el Indexador en disputa no incurrirá en slashing.
+- Si la disputa se resuelve como empate, se devolverá el depósito de los Fishermen y no se realizará slashing al Indexador en disputa.
+- Si la disputa es aceptada, los GRT depositados por los Fishermen serán devueltos, el Indexador en disputa recibirá slashing y los Fishermen ganarán el 50% de los GRT en slashing.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### ¿Qué son los reembolsos de tarifas de consulta y cuándo se distribuyen?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+
+### ¿Qué es el recorte de la tarifa de consulta y el recorte de la recompensa de indexación?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### ¿Cómo saben los Indexadores qué subgrafos indexar?
+
+Los indexadores pueden diferenciarse aplicando técnicas avanzadas para tomar decisiones de indexación de subgrafos, pero para dar una idea general, discutiremos varias métricas clave que se utilizan para evaluar subgrafos en la red:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### ¿Cuáles son los requisitos de hardware?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Configuración | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| ------------- | :------------------: | :---------------------------: | :-------------------------: | :-------------: | :----------------------: |
+| Pequeño       |           4          |               8               |              1              |        4        |            16            |
+| Estándar      |           8          |               30              |              1              |        12       |            48            |
+| Medio         |          16          |               64              |              2              |        32       |            64            |
+| Grande        |          72          |              468              |             3,5             |        48       |            184           |
+
+### ¿Qué precauciones básicas de seguridad debe tomar un Indexador?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infraestructura
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Nota: Para admitir el escalado ágil, se recomienda que las inquietudes de consulta e indexación se separen entre diferentes conjuntos de nodos: nodos de consulta y nodos de índice.
+
+### Vista general de puertos
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Puerto | Objeto                                                   | Rutas                                          | Argumento CLI      | Variable de Entorno |
+| ------ | -------------------------------------------------------- | ---------------------------------------------- | ------------------ | ------------------- |
+| 8000   | Servidor HTTP GraphQL<br />(para consultas de subgrafos) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                   |
+| 8001   | GraphQL WS<br />(para suscripciones a subgrafos)         | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                   |
+| 8020   | JSON-RPC<br />(para administrar implementaciones)        | /                                              | \--admin-port      | -                   |
+| 8030   | API de estado de indexación de subgrafos                 | /graphql                                       | \--index-node-port | -                   |
+| 8040   | Métricas de Prometheus                                   | /metrics                                       | \--metrics-port    | -                   |
+
+#### Servicio de Indexador
+
+| Puerto | Objeto                                                          | Rutas                                                       | Argumento CLI   | Variable de Entorno    |
+| ------ | --------------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600   | Servidor HTTP GraphQL<br />(para consultas de subgrafo pagadas) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300   | Métricas de Prometheus                                          | /metrics                                                    | \--metrics-port | -                      |
+
+#### Agente Indexador
+
+| Puerto | Purpose                       | Rutas  | CLI Argument               | Environment Variable                    |
+| ------ | ----------------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000   | API de gestión de indexadores | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Configurar la infraestructura del servidor con Terraform en Google Cloud
+
+> Nota: Los Indexadores pueden utilizar alternativamente AWS, Microsoft Azure o Alibaba.
+
+#### Instalar requisitos previos
+
+- SDK de Google Cloud
+- Herramienta de línea de comandos de Kubectl
+- Terraform
+
+#### Crear un proyecto de Google Cloud
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Autentícate con Google Cloud y crea un nuevo proyecto.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Usa la página de facturación de Google Cloud Console para habilitar la facturación del nuevo proyecto.
+
+- Crea una configuración de Google Cloud.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Habilita las API requeridas de Google Cloud.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Crea una cuenta de servicio.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Habilita el emparejamiento entre la base de datos y el cluster de Kubernetes que se creará en el siguiente paso.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Crea un archivo de configuración mínimo de terraform (actualiza según sea necesario).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Usa Terraform para crear infraestructura
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Ejecuta los siguientes comandos para crear la infraestructura.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Crea los componentes de Kubernetes para el Indexador
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Empezar desde el origen
+
+#### Instalar requisitos previos
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Configuración
+
+1. Inicia un servidor de base de datos PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Ahora que todas las dependencias están configuradas, inicia el nodo Graph:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Empezar usando Docker
+
+#### Prerrequisitos
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Configuración
+
+1. Clona Graph Node y navega hasta el directorio de Docker:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Inicia un Graph Node local que se conectará a tu endpoint de Ethereum:
+
+```sh
+docker-compose up
+```
+
+### Componentes de Indexador
+
+Para participar con éxito en la red se requiere una supervisión e interacción casi constantes, por lo que hemos creado un conjunto de aplicaciones de Typecript para facilitar la participación de una red de Indexadores. Hay tres componentes de Indexador:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Comenzar
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### Paquetes de NPM
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### De la fuente
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Uso de Docker
+
+- Extrae imágenes del registro
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+O crea imágenes localmente desde la fuente
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Ejecuta los componentes
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Uso de K8s y Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Uso
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Agente Indexador
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Servicio de Indexador
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### CLI del Indexador
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Gestión del Indexador mediante Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Uso
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Reglas de Indexación
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Modelo de Datos:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Ejemplo de uso de la regla de indexación:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### CLI de la fila de acciones
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Acción añadida a la fila por la herramienta optimizadora de terceros o el usuario de Indexer-cli
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- El Indexador puede supervisar la fila de acciones para ver un historial de la ejecución de las acciones y, si es necesario, volver a aprobar y actualizar los elementos de acción si fallan en su ejecución. La fila de acciones proporciona un historial de todas las acciones en fila y ejecutadas.
+
+Modelo de Datos:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Ejemplo de uso de la fuente:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Ten en cuenta que los tipos de acción admitidos para la gestión de la allocation tienen diferentes requisitos de entrada:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - parámetros de acción requeridos:
+    - deploymentID
+    - cantidad
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - parámetros de acción requeridos:
+    - allocationID
+    - deploymentID
+  - parámetros de acción opcionales:
+    - poi
+    - force (obliga a utilizar el POI proporcionado aunque no coincida con lo que proporciona el graph-node)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - parámetros de acción requeridos:
+    - allocationID
+    - deploymentID
+    - cantidad
+  - parámetros de acción opcionales:
+    - poi
+    - force (obliga a utilizar el POI proporcionado aunque no coincida con lo que proporciona el graph-node)
+
+#### Modelos de Costos
+
+Los modelos de costes proporcionan precios dinámicos para las consultas basados en el mercado y los atributos de la consulta. El Servicio de Indexadores comparte un modelo de costes con las gateway para cada subgrafo para el que pretenden responder a las consultas. Las gateway, a su vez, utilizan el modelo de costes para tomar decisiones de selección de Indexadores por consulta y para negociar el pago con los Indexadores elegidos.
+
+#### Agora
+
+El lenguaje Agora proporciona un formato flexible para declarar modelos de costos para consultas. Un modelo de precios de Agora es una secuencia de declaraciones que se ejecutan en orden para cada consulta de nivel superior en una consulta GraphQL. Para cada consulta de nivel superior, la primera declaración que coincide con ella determina el precio de esa consulta.
+
+Una declaración se compone de un predicado, que se utiliza para hacer coincidir consultas GraphQL, y una expresión de costo que, cuando se evalúa, genera un costo en GRT decimal. Los valores en la posición del argumento nombrado de una consulta pueden capturarse en el predicado y usarse en la expresión. Los globales también se pueden establecer y sustituir por marcadores de posición en una expresión.
+
+Ejemplo de modelo de costos:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Ejemplo de modelo de costo usando el modelo anterior:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0,5 GRT |
+| { tokens { symbol } }                                                        | 0,1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0,6 GRT |
+
+#### Aplicación del modelo de costos
+
+Los modelos de costos se aplican a través de la CLI del Indexador, que los pasa a la API de Administración de Indexador del agente Indexador para almacenarlos en la base de datos. Luego, el Servicio del Indexador los recogerá y entregará los modelos de costos a las gateway siempre que los soliciten.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interactuar con la red
+
+### Stake en el protocolo
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Aprobar tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Staking de tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### La vida de una allocation
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 6743a43c16390a58d7779237042cb119e584ba05 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:36 -0500
Subject: [PATCH 0737/3820] New translations tap.mdx (Spanish)

---
 website/pages/es/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/es/indexing/tap.mdx

diff --git a/website/pages/es/indexing/tap.mdx b/website/pages/es/indexing/tap.mdx
new file mode 100644
index 000000000000..50cb4c91638a
--- /dev/null
+++ b/website/pages/es/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Descripción
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notas:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From 0349731b51a0dcac270d8793397dc603d256c015 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:37 -0500
Subject: [PATCH 0738/3820] New translations graph-node.mdx (Spanish)

---
 .../pages/es/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/es/indexing/tooling/graph-node.mdx

diff --git a/website/pages/es/indexing/tooling/graph-node.mdx b/website/pages/es/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..b15fc35c907d
--- /dev/null
+++ b/website/pages/es/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node es el componente que indexa los subgrafos, y hace que los datos resultantes estén disponibles para su consulta a través de una API GraphQL. Como tal, es fundamental para el stack del Indexador, y el correcto funcionamiento de Graph Node es crucial para ejecutar un Indexador con éxito.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### Base de datos PostgreSQL
+
+El almacén principal para Graph Node, aquí es donde se almacenan los datos de los subgrafos, así como los metadatos de los subgrafos, y los datos de una red subgrafo-agnóstica como el caché de bloques, y el caché eth_call.
+
+### Clientes de red
+
+Para indexar una red, Graph Node necesita acceso a un cliente de red a través de una API JSON-RPC compatible con EVM. Esta RPC puede conectarse a un solo cliente o puede ser una configuración más compleja que equilibre la carga entre varios clientes.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### Nodos IPFS
+
+Los metadatos de deploy del subgrafo se almacenan en la red IPFS. El Graph Node accede principalmente al nodo IPFS durante el deploy del subgrafo para obtener el manifiesto del subgrafo y todos los archivos vinculados. Los Indexadores de red no necesitan alojar su propio nodo IPFS. En https://ipfs.network.thegraph.com se aloja un nodo IPFS para la red.
+
+### Servidor de métricas Prometheus
+
+Para permitir la supervisión y la generación de informes, Graph Node puede registrar métricas opcionalmente en un servidor de métricas Prometheus.
+
+### Empezar desde el origen
+
+#### Instalar requisitos previos
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Configuración
+
+1. Inicia un servidor de base de datos PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Ahora que todas las dependencias están configuradas, inicia el nodo Graph:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Introducción a Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Puertos
+
+Cuando está funcionando, Graph Node muestra los siguientes puertos:
+
+| Puerto | Objeto                                                   | Rutas                                          | Argumento CLI      | Variable de Entorno |
+| ------ | -------------------------------------------------------- | ---------------------------------------------- | ------------------ | ------------------- |
+| 8000   | Servidor HTTP GraphQL<br />(para consultas de subgrafos) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                   |
+| 8001   | GraphQL WS<br />(para suscripciones a subgrafos)         | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                   |
+| 8020   | JSON-RPC<br />(para administrar implementaciones)        | /                                              | \--admin-port      | -                   |
+| 8030   | API de estado de indexación de subgrafos                 | /graphql                                       | \--index-node-port | -                   |
+| 8040   | Métricas de Prometheus                                   | /metrics                                       | \--metrics-port    | -                   |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Configuración avanzada de Graph Node
+
+En su forma más simple, Graph Node puede funcionar con una única instancia de Graph Node, una única base de datos PostgreSQL, un nodo IPFS y los clientes de red que requieran los subgrafos a indexar.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> Cuando se utiliza un archivo de configuración, no es posible utilizar las opciones --postgres-url, --postgres-secondary-hosts y --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Graph Nodes múltiples
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Ten en cuenta que varios Graph Nodes pueden configurarse para utilizar la misma base de datos, que a su vez puede escalarse horizontalmente mediante sharding.
+
+#### Reglas de deploy
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Ejemplo de configuración de reglas de deploy:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Nodos de consulta dedicados
+
+Los nodos pueden configurarse para ser explícitamente nodos de consulta incluyendo lo siguiente en el archivo de configuración:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Cualquier nodo cuyo --node-id coincida con la expresión regular se configurará para que solo responda a consultas.
+
+#### Escalado de bases de datos mediante sharding
+
+Para la mayoría de los casos de uso, una única base de datos Postgres es suficiente para soportar una instancia de graph-node. Cuando una instancia de graph-node supera una única base de datos Postgres, es posible dividir el almacenamiento de los datos de graph-node en varias bases de datos Postgres. Todas las bases de datos juntas forman el almacén de la instancia graph-node. Cada base de datos individual se denomina shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+El Sharding resulta útil cuando la base de datos existente no puede soportar la carga que le impone Graph Node y cuando ya no es posible aumentar el tamaño de la base de datos.
+
+> En general, es mejor hacer una única base de datos lo más grande posible, antes de empezar con los shards. Una excepción es cuando el tráfico de consultas se divide de forma muy desigual entre los subgrafos; en esas situaciones puede ayudar dramáticamente si los subgrafos de alto volumen se mantienen en un shard y todo lo demás en otro, porque esa configuración hace que sea más probable que los datos de los subgrafos de alto volumen permanezcan en la caché interna de la base de datos y no sean reemplazados por datos que no se necesitan tanto de los subgrafos de bajo volumen.
+
+En términos de configuración de las conexiones, comienza con max_connections en postgresql.conf establecido en 400 (o tal vez incluso 200) y mira las métricas de Prometheus store_connection_wait_time_ms y store_connection_checkout_count. Tiempos de espera notables (cualquier cosa por encima de 5ms) es una indicación de que hay muy pocas conexiones disponibles; altos tiempos de espera allí también serán causados por la base de datos que está muy ocupada (como alta carga de CPU). Sin embargo, si la base de datos parece estable, los tiempos de espera elevados indican la necesidad de aumentar el número de conexiones. En la configuración, el número de conexiones que puede utilizar cada instancia de Graph Node es un límite superior, y Graph Node no mantendrá conexiones abiertas si no las necesita.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Bloques de procesamiento dedicado
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Soporte de múltiples redes
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Redes múltiples
+- Múltiples proveedores por red (esto puede permitir dividir la carga entre los proveedores, y también puede permitir la configuración de nodos completos, así como nodos de archivo, con Graph Node prefiriendo proveedores más baratos si una carga de trabajo dada lo permite).
+- Detalles adicionales del proveedor, como features, autenticación y tipo de proveedor (para soporte experimental de Firehose)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Variables del entorno
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Deploy continuo
+
+Los usuarios que están operando una configuración de indexación escalada con configuración avanzada pueden beneficiarse de la gestión de sus Graph Nodes con Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Operar Graph Node
+
+Dado un Graph Node en funcionamiento (¡o Graph Nodes!), el reto consiste en gestionar los subgrafos deployados en esos nodos. Graph Node ofrece una serie de herramientas para ayudar a gestionar los subgrafos.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node proporciona las métricas a través del endpoint Prometheus en el puerto 8040 por defecto. Grafana se puede utilizar para visualizar estas métricas.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Trabajar con subgrafos
+
+#### API de estado de indexación
+
+Disponible por defecto en el puerto 8030/graphql, la API de estado de indexación expone una serie de métodos para comprobar el estado de indexación de diferentes subgrafos, comprobar pruebas de indexación, inspeccionar características de subgrafos y mucho más.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Rendimiento de indexación
+
+El proceso de indexación consta de tres partes diferenciadas:
+
+- Obtener eventos de interés del proveedor
+- Procesar los eventos en orden con los handlers apropiados (esto puede implicar llamar a la cadena para obtener el estado y obtener datos del store)
+- Escribir los datos resultantes en el store
+
+"Estas etapas están en serie (es decir, se pueden ejecutar en paralelo), pero dependen una de la otra. Cuando los subgrafos son lentos en indexarse, la causa subyacente dependerá del subgrafo específico.
+
+Causas habituales de la lentitud de indexación:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- Gran cantidad de interacción con el depósito durante la ejecución
+- Una gran cantidad de datos para guardar en el depósito
+- Un gran número de eventos que procesar
+- Tiempo de conexión a la base de datos lento, para nodos abarrotados
+- El proveedor en sí mismo se está quedando rezagado con respecto a la cabeza de la cadena
+- Lentitud en la obtención de nuevos recibos en la cabeza de la cadena desde el proveedor
+
+Las métricas de indexación de subgrafos pueden ayudar a diagnosticar la causa raíz de la lentitud de la indexación. En algunos casos, el problema reside en el propio subgrafo, pero en otros, la mejora de los proveedores de red, la reducción de la contención de la base de datos y otras mejoras de configuración pueden mejorar notablemente el rendimiento de la indexación.
+
+#### Subgrafos fallidos
+
+Durante la indexación, los subgrafos pueden fallar si encuentran datos inesperados, si algún componente no funciona como se esperaba o si hay algún error en los event handlers o en la configuración. Hay dos tipos generales de fallo:
+
+- Fallos deterministas: son fallos que no se resolverán con reintentos
+- Fallos no deterministas: pueden deberse a problemas con el proveedor o a algún error inesperado de Graph Node. Cuando se produce un fallo no determinista, Graph Node reintentará los handlers que han fallado, retrocediendo en el tiempo.
+
+En algunos casos, un fallo puede ser resuelto por el Indexador (por ejemplo, si el error es resultado de no tener el tipo correcto de proveedor, añadir el proveedor necesario permitirá continuar con la indexación). Sin embargo, en otros, se requiere un cambio en el código del subgrafo.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Caché de bloques y llamadas
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+Si se sospecha de una inconsistencia en el caché de bloques, como un evento de falta de recepción tx:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. Si el bloque coincide con el proveedor, el problema puede depurarse directamente contra el proveedor.
+
+#### Consulta de problemas y errores
+
+Una vez que un subgrafo ha sido indexado, los Indexadores pueden esperar servir consultas a través del endpoint de consulta dedicado del subgrafo. Si el Indexador espera servir un volumen de consultas significativo, se recomienda un nodo de consulta dedicado, y en caso de volúmenes de consulta muy altos, los Indexadores pueden querer configurar shards de réplica para que las consultas no impacten en el proceso de indexación.
+
+Sin embargo, incluso con un nodo de consulta dedicado y réplicas, ciertas consultas pueden llevar mucho tiempo para ejecutarse y, en algunos casos, aumentar el uso de memoria y afectar negativamente el tiempo de consulta de otros usuarios.
+
+No existe una "bala de plata", sino toda una serie de herramientas para prevenir, diagnosticar y tratar las consultas lentas.
+
+##### Caché de consultas
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Análisis de consultas
+
+Las consultas problemáticas suelen surgir de dos maneras. En algunos casos, los propios usuarios informan de que una consulta determinada es lenta. En ese caso, el reto consiste en diagnosticar el motivo de la lentitud, ya sea un problema general o específico de ese subgrafo o consulta. Y, por supuesto, resolverlo, si es posible.
+
+En otros casos, el desencadenante puede ser un uso elevado de memoria en un nodo de consulta, en cuyo caso el reto consiste primero en identificar la consulta causante del problema.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Ante una consulta lenta, los Indexadores tienen algunas opciones. Por supuesto, pueden alterar su modelo de costes, para aumentar significativamente el coste de envío de la consulta problemática. Esto puede dar lugar a una reducción de la frecuencia de esa consulta. Sin embargo, a menudo esto no resuelve la raíz del problema.
+
+##### Optimización a nivel de cuenta
+
+Las tablas de bases de datos que almacenan entidades suelen ser de dos tipos: Las de tipo "transacción", en las que las entidades, una vez creadas, no se actualizan nunca, es decir, almacenan algo parecido a una lista de transacciones financieras, y las de tipo "cuenta", en las que las entidades se actualizan muy a menudo, es decir, almacenan algo parecido a cuentas financieras que se modifican cada vez que se registra una transacción. Las tablas tipo cuenta se caracterizan por contener un gran número de versiones de entidades, pero relativamente pocas entidades distintas. A menudo, en este tipo de tablas, el número de entidades distintas es del 1% del número total de filas (versiones de entidades)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Eliminar subgrafos
+
+> Se trata de una nueva funcionalidad, que estará disponible en Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From c1662ae3caf586dfd56a21629613761fc7b75aeb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:38 -0500
Subject: [PATCH 0739/3820] New translations advanced.mdx (Spanish)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/es/subgraphs/developing/creating/advanced.mdx b/website/pages/es/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..93a6a6241618
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Descripción
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Errores no fatales
+
+Los errores de indexación en subgrafos ya sincronizados provocarán, por defecto, que el subgrafo falle y deje de sincronizarse. Los subgrafos pueden ser configurados de manera alternativa para continuar la sincronización en presencia de errores, ignorando los cambios realizados por el handler que provocó el error. Esto da a los autores de los subgrafos tiempo para corregir sus subgrafos mientras las consultas continúan siendo servidas contra el último bloque, aunque los resultados serán posiblemente inconsistentes debido al bug que provocó el error. Nótese que algunos errores siguen siendo siempre fatales, para que el error no sea fatal debe saberse que es deterministico.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Para activar los errores no fatales es necesario establecer el siguiente indicador en el manifiesto del subgrafo:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way. File data sources support fetching files from IPFS and from Arweave.
+
+> Esto también establece las bases para la indexación determinista de datos off-chain, así como la posible introducción de datos arbitrarios procedentes de HTTP.
+
+### Descripción
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Upgrade guide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Añadir un nuevo tipo de entidad que se actualizará cuando se encuentren archivos
+
+Las fuentes de datos de archivos no pueden acceder a entidades basadas en cadenas ni actualizarlas, pero deben actualizar entidades específicas de archivos.
+
+Esto puede significar dividir campos de entidades existentes en entidades separadas, vinculadas entre sí.
+
+Entidad combinada original:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+Nueva, entidad dividida:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+Si la relación es 1:1 entre la entidad padre y la entidad fuente de datos de archivo resultante, el patrón más sencillo es vincular la entidad padre a una entidad de archivo resultante utilizando el CID IPFS como búsqueda. Pónte en contacto con nosotros en Discord si tienes dificultades para modelar tus nuevas entidades basadas en archivos!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+Esta es la fuente de datos que se generará cuando se identifique un archivo de interés.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Crear un nuevo handler para procesar archivos
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Ejemplo de handler:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Generar fuentes de datos de archivos cuando sea necesario
+
+Ahora puedes crear fuentes de datos de archivos durante la ejecución de handlers basados en cadenas:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Ejemplo:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+This will create a new file data source, which will poll Graph Node's configured IPFS or Arweave endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+¡Felicitaciones, estás utilizando fuentes de datos de archivos!
+
+#### Deploy de tus subgrafos
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitaciones
+
+Los handlers y entidades de fuentes de datos de archivos están aislados de otras entidades del subgrafo, asegurando que son deterministas cuando se ejecutan, y asegurando que no se contaminan las fuentes de datos basadas en cadenas. En concreto:
+
+- Las entidades creadas por File Data Sources son inmutables y no pueden actualizarse
+- Los handlers de File Data Source no pueden acceder a entidades de otras fuentes de datos de archivos
+- Los handlers basados en cadenas no pueden acceder a las entidades asociadas a File Data Sources
+
+> Aunque esta restricción no debería ser problemática para la mayoría de los casos de uso, puede introducir complejidad para algunos. Si tienes problemas para modelar tus datos basados en archivos en un subgrafo, ponte en contacto con nosotros a través de Discord!
+
+Además, no es posible crear fuentes de datos a partir de una File Data Source, ya sea una fuente de datos on-chain u otra File Data Source. Es posible que esta restricción se elimine en el futuro.
+
+#### Mejores Prácticas
+
+Si estás vinculando metadatos NFT a los tokens correspondientes, utiliza el hash IPFS de los metadatos para hacer referencia a una entidad Metadata desde la entidad Token. Guarda la entidad de metadatos utilizando el hash IPFS como ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> Estamos trabajando para mejorar la recomendación anterior, de modo que las consultas sólo devuelvan la versión "más reciente"
+
+#### Problemas conocidos
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Ejemplos
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### Referencias
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Grafting sobre subgrafos existentes
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Debido a que el grafting copia en lugar de indexar los datos base, es mucho más rápido llevar el subgrafo al bloque deseado que indexar desde cero, aunque la copia inicial de los datos aún puede llevar varias horas para subgrafos muy grandes. Mientras se inicializa el subgrafo grafted, Graph Node registrará información sobre los tipos de entidad que ya han sido copiados.
+
+El subgrafo grafteado puede utilizar un esquema GraphQL que no es idéntico al del subgrafo base, sino simplemente compatible con él. Tiene que ser un esquema de subgrafo válido por sí mismo, pero puede diferir del esquema del subgrafo base de las siguientes maneras:
+
+- Agrega o elimina tipos de entidades
+- Elimina los atributos de los tipos de entidad
+- Agrega atributos anulables a los tipos de entidad
+- Convierte los atributos no anulables en atributos anulables
+- Añade valores a los enums
+- Agrega o elimina interfaces
+- Cambia para qué tipos de entidades se implementa una interfaz
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 55a5c4a9822dbb025dc6a4ef869bffa0709fefac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:40 -0500
Subject: [PATCH 0740/3820] New translations api.mdx (Spanish)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/es/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/es/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..c8d2985155e0
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## Referencias de API
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- Primitivas de bajo nivel para traducir entre los distintos tipos de sistemas, tales como, Ethereum, JSON, GraphQL y AssemblyScript.
+
+### Versiones
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| Version | Notas del lanzamiento                                                                                                                                                                                                                                    |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### Tipos Incorporados
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Dirección
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### Almacén de API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Creacion de entidades
+
+El siguiente es un patrón común para crear entidades a partir de eventos de Ethereum.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Carga de entidades desde el store
+
+Si una entidad ya existe, se puede cargar desde el store con lo siguiente:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Buscando entidades creadas dentro de un bloque
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Usa la identidad de transferencia como se indica arriba
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Buscando entidades derivadas
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### Actualización de las entidades existentes
+
+Hay dos maneras de actualizar una entidad existente:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+Cambiar las propiedades es sencillo en la mayoría de los casos, gracias a los definidores de propiedades generados:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+También es posible desajustar las propiedades con una de las dos instrucciones siguientes:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Eliminar entidades del store
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### API de Ethereum
+
+La API de Ethereum proporciona acceso a los contratos inteligentes, a las variables de estado públicas, a las funciones de los contratos, a los eventos, a las transacciones, a los bloques y a la codificación/decodificación de los datos de Ethereum.
+
+#### Compatibilidad con los tipos de Ethereum
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+El siguiente ejemplo lo ilustra. Dado un esquema de subgrafos como
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Eventos y datos de bloques/transacciones
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Acceso al Estado del Contrato Inteligente
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+Un patrón común es acceder al contrato desde el que se origina un evento. Esto se consigue con el siguiente código:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+Cualquier otro contrato que forme parte del subgrafo puede ser importado desde el código generado y puede ser vinculado a una dirección válida.
+
+#### Tratamiento de las Llamadas Revertidas
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Codificación/Descodificación ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+Para mas informacion:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### API de Registro
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Registro de uno o varios valores
+
+##### Registro de un solo valor
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Registro de una sola entrada de una matriz existente
+
+En el ejemplo siguiente, sólo se registra el primer valor de la matriz de argumentos, a pesar de que la matriz contiene tres valores.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Registro de múltiples entradas de una matriz existente
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Registro de una entrada específica de una matriz existente
+
+Para mostrar un valor específico en el array, se debe proporcionar el valor indexado.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Registro de información de eventos
+
+El ejemplo siguiente registra el número de bloque, el hash del bloque y el hash de la transacción de un evento:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### API IPFS
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Dado un hash o ruta de IPFS, la lectura de un archivo desde IPFS se realiza de la siguiente manera:
+
+```typescript
+// Colocar esto dentro del gestor de eventos del mapeo
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Rutas como `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// que incluye documentos en directorios que son soportados
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### API Cripto
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### API JSON
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### Referencias de Tipo de Conversiones
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### Metadatos de la Fuente de Datos
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entity y DataSourceContext
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From e42aef258c3ff31122b3a659cca282a6ca614796 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:41 -0500
Subject: [PATCH 0741/3820] New translations common-issues.mdx (Spanish)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/es/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/es/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..9b540b6d07d4
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Problemas comunes de AssemblyScript
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 203766b820b1af58f30a1c69ccd994dc6486ae57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:42 -0500
Subject: [PATCH 0742/3820] New translations unit-testing-framework.mdx
 (Spanish)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/es/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/es/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..d90abc888b78
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Marco de Unit Testing
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Empezando
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+Puedes usar Matchstick en WSL tanto con el enfoque de Docker como con el enfoque binario. Ya que WSL puede ser un poco complicado, aquí hay algunos consejos en caso de que encuentres problemas como
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+o
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### Opciones CLI
+
+Esto ejecutará todas las pruebas en la carpeta de prueba:
+
+```sh
+graph test
+```
+
+Esto ejecutará una prueba llamada gravity.test.ts y/o todas las pruebas dentro de una carpeta llamada gravity:
+
+```sh
+graph test gravity
+```
+
+Esto ejecutará solo ese archivo de prueba específico:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuración
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Subgrafo de demostración
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Tutoriales en vídeo
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Ejemplo:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Ejemplo:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+o
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Ejemplos:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Ejemplo:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Ejemplos:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Escribir un Unit Test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Suponiendo que tenemos la siguiente función handler (junto con dos funciones auxiliares para hacernos la vida más fácil):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+Primero tenemos que crear un archivo de prueba en nuestro proyecto. Este es un ejemplo de cómo podría verse:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- Estamos configurando nuestro estado inicial y agregando una entidad Gravatar personalizada;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- Hacemos valer el estado del almacén. ¿Cómo funciona eso? - Pasamos una combinación única de tipo de Entidad e id. A continuación, comprobamos un campo específico de esa Entidad y afirmamos que tiene el valor que esperamos que tenga. Hacemos esto tanto para la Entidad Gravatar inicial que añadimos al almacén, como para las dos entidades Gravatar que se añaden cuando se llama a la función del handler;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+Ahí vamos: ¡hemos creado nuestra primera prueba! 👏
+
+Ahora, para ejecutar nuestras pruebas, simplemente necesitas ejecutar lo siguiente en la carpeta raíz de tu subgrafo:
+
+`graph test Gravity`
+
+Y si todo va bien, deberías ser recibido con lo siguiente:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Escenarios de prueba comunes
+
+### Abastecer la tienda con un cierto estado
+
+Los usuarios pueden abastecer la tienda con un conjunto conocido de entidades. Aquí hay un ejemplo para inicializar la tienda con una entidad Gravatar:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Llamar a una función de mapeo con un evento
+
+Un usuario puede crear un evento personalizado y pasarlo a una función de mapeo que está vinculada al store:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Llamar a todos los mapeos con fixtures de eventos
+
+Los usuarios pueden llamar a los mapeos con fixtures de prueba.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocking de llamadas de contrato
+
+Los usuarios pueden mock llamadas de contrato:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+Como se demostró, para hacer mock de una llamada de contrato y obtener un valor de retorno, el usuario debe proporcionar una dirección de contrato, un nombre de función, una firma de función, una serie de argumentos y, por supuesto, el valor de retorno.
+
+Las usuarios también pueden hacer mock de reversiones de funciones:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking de archivos IPFS (desde matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Afirmando el estado del almacenamiento
+
+Los usuarios pueden afirmar el estado final (o intermedio) del almacenamiento mediante la afirmación de entidades. Para hacerlo, el usuario debe proporcionar un tipo de entidad, el ID específico de una entidad, un nombre de campo en esa entidad y el valor esperado del campo. Aquí hay un ejemplo rápido:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interactuar con metadatos de eventos
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Afirmar la igualdad de variables
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Los usuarios pueden afirmar que una entidad no existe en el almacenamiento. La función toma un tipo de entidad y una identificación. Si la entidad está de hecho en el almacenamiento, la prueba fallará con un mensaje de error relevante. Aquí hay un ejemplo rápido de cómo usar esta funcionalidad:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+Puede imprimir todo el almacenamiento a la consola usando esta función de ayuda:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Fallo esperado
+
+Los usuarios pueden tener fallas de prueba esperadas, usando el indicador shouldFail en las funciones test():
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+Si la prueba está marcada con shouldFail = true pero NO falla, aparecerá como un error en los registros y el bloque de prueba fallará. Además, si está marcado con shouldFail = false (el estado predeterminado), el ejecutor de prueba fallará.
+
+### Logging
+
+Tener logs personalizados en los unit tests es exactamente lo mismo que hacer logging en los mapeos. La diferencia es que el objeto de registro debe importarse desde matchstick-as en lugar de graph-ts. Aquí hay un ejemplo simple con todos los tipos de log no críticos:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Los usuarios también pueden simular una falla crítica, así:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+El logging de errores críticos detendrá la ejecución de las pruebas y explotará todo. Después de todo, queremos asegurarnos de que tu código no tenga logs críticos en el deployment, y deberías darte cuenta de inmediato si eso sucediera.
+
+### Testing de campos derivados
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Probar fuentes de datos dinámicas
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Ejemplo a continuación:
+
+Primero, tenemos el siguiente handler de eventos (que se ha reutilizado intencionalmente para mostrar el mocking de datasource):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+Y luego tenemos la prueba usando uno de los métodos en el namespace dataSourceMock para establecer un nuevo valor de retorno para todas las funciones de dataSource:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Tenga en cuenta que dataSourceMock.resetValues() se llama al final. Esto se debe a que los valores se recuerdan cuando se modifican y deben restablecerse si desea volver a los valores predeterminados.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Cobertura de prueba
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Prerrequisitos
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Exporta tus handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Uso
+
+Una vez que esté todo configurado, para ejecutar la herramienta de cobertura de prueba, simplemente ejecuta:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+Eso ejecutará la herramienta de cobertura y deberías ver algo como esto en la terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Duración del tiempo de ejecución de la prueba en la salida del log
+
+La salida del log incluye la duración de la ejecución de la prueba. Aquí hay un ejemplo:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Errores comunes del compilador
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Recursos Adicionales
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Comentario
+
+Si tiene preguntas, comentarios, solicitudes de funciones o simplemente deseas comunicarte, el mejor lugar sería The Graph Discord, donde tenemos un canal dedicado para Matchstick, llamado 🔥| unit-testing.

From 9b784e9959d489c422deb4bf528fd99168f35ec5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:43 -0500
Subject: [PATCH 0743/3820] New translations transferring-a-subgraph.mdx
 (Spanish)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/es/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/es/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 6786650b290fe8c138c7621be1ba0f92c30e6ee6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:44 -0500
Subject: [PATCH 0744/3820] New translations graphql-api.mdx (Spanish)

---
 .../es/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/es/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/es/subgraphs/querying/graphql-api.mdx b/website/pages/es/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..cb3df62fee73
--- /dev/null
+++ b/website/pages/es/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: API GraphQL
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Ejemplos
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Clasificación
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Ejemplo
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Ejemplo de filtrado de entidades anidadas
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Paginación
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Consulta los primeros 10 tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtrado
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Ejemplo de filtrado de rango
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Ejemplo de filtrado de bloques
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+Esto puede ser útil si buscas obtener solo las entidades que han cambiado, por ejemplo, desde la última vez que realizaste una encuesta. O, alternativamente, puede ser útil para investigar o depurar cómo cambian las entidades en tu subgrafo (si se combina con un filtro de bloque, puedes aislar solo las entidades que cambiaron en un bloque específico).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Ejemplo de filtrado de entidades anidadas
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+Esto puede ser útil si estás buscando obtener solo entidades cuyas entidades de nivel inicial cumplan con las condiciones proporcionadas.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Operadores lógicos
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### Todos los filtros
+
+Lista completa de sufijos de parámetros:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Consultas sobre Time-travel
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Ejemplo
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Ejemplo
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Consultas de Búsqueda de Texto Completo
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Operadores de búsqueda de texto completo:
+
+| Símbolo | Operador    | Descripción                                                                                                                                                         |
+| ------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`     | `And`       | Para combinar varios términos de búsqueda en un filtro para entidades que incluyen todos los términos proporcionados                                                |
+| |       | `Or`        | Las consultas con varios términos de búsqueda separados por o el operador devolverá todas las entidades que coincidan con cualquiera de los términos proporcionados |
+| `<->`   | `Follow by` | Especifica la distancia entre dos palabras.                                                                                                                         |
+| `:*`    | `Prefix`    | Utilice el término de búsqueda del prefijo para encontrar palabras cuyo prefijo coincida (se requieren 2 caracteres.)                                               |
+
+#### Ejemplos
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combina operadores de texto completo para crear filtros más complejos. Con un operador de búsqueda de pretexto combinado con una consulta de seguimiento de este ejemplo, se buscarán coincidencias con todas las entidades del blog con palabras que comiencen con "lou" seguido de "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validación
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Esquema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entidades
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Metadatos del subgrafo
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+Si se proporciona un bloque, los metadatos corresponden a ese bloque; de lo contrario, se utiliza el bloque indexado más reciente. Si es proporcionado, el bloque debe ser posterior al bloque de inicio del subgrafo y menor o igual que el bloque indexado más reciente.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: el hash del bloque
+- número: el número de bloque
+- timestamp: la marca de tiempo del bloque, en caso de estar disponible (actualmente solo está disponible para subgrafos que indexan redes EVM)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 5ce18cde54fbbeaddcd5b013559b8c4e2846240c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:45 -0500
Subject: [PATCH 0745/3820] New translations python.mdx (Spanish)

---
 .../pages/es/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/es/subgraphs/querying/python.mdx

diff --git a/website/pages/es/subgraphs/querying/python.mdx b/website/pages/es/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..0d0eda090fe8
--- /dev/null
+++ b/website/pages/es/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Empezando
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 04eabf35028dcfb747976d7214ee3c77ab193354 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:46 -0500
Subject: [PATCH 0746/3820] New translations triggers.mdx (Spanish)

---
 website/pages/es/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/es/substreams/sps/triggers.mdx

diff --git a/website/pages/es/substreams/sps/triggers.mdx b/website/pages/es/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/es/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 580bf4137d9eaf631b797cbebcfcc6439c7dfca6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:47 -0500
Subject: [PATCH 0747/3820] New translations overview.mdx (Arabic)

---
 website/pages/ar/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/ar/indexing/overview.mdx

diff --git a/website/pages/ar/indexing/overview.mdx b/website/pages/ar/indexing/overview.mdx
new file mode 100644
index 000000000000..b896de2f4d64
--- /dev/null
+++ b/website/pages/ar/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+
+GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.
+
+يختار المفهرسون subgraphs للقيام بالفهرسة بناء على إشارة تنسيق subgraphs ، حيث أن المنسقون يقومون ب staking ل GRT وذلك للإشارة ل Subgraphs عالية الجودة. يمكن أيضا للعملاء (مثل التطبيقات) تعيين بارامترات حيث يقوم المفهرسون بمعالجة الاستعلامات ل Subgraphs وتسعير رسوم الاستعلام.
+
+<Difficulty level="ADVANCED" />
+
+## الأسئلة الشائعة
+
+### What is the minimum stake required to be an Indexer on the network?
+
+The minimum stake for an Indexer is currently set to 100K GRT.
+
+### What are the revenue streams for an Indexer?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### How are indexing rewards distributed?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### ما هو إثبات الفهرسة (POI)؟
+
+POIs are used in the network to verify that an Indexer is indexing the subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific subgraph deployment up to and including that block.
+
+### متى يتم توزيع مكافآت الفهرسة؟
+
+Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).
+
+### Can pending indexing rewards be monitored?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+تشتمل العديد من لوحات المعلومات التي أنشأها المجتمع على قيم المكافآت المعلقة ويمكن التحقق منها بسهولة يدويًا باتباع الخطوات التالية:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### ما هي الاعتراضات disputes وأين يمكنني عرضها؟
+
+يمكن الاعتراض على استعلامات المفهرس وتخصيصاته على The Graph أثناء فترة الاعتراض dispute. تختلف فترة الاعتراض حسب نوع الاعتراض. تحتوي الاستعلامات / الشهادات Queries/attestations على نافذة اعتراض لـ 7 فترات ، في حين أن المخصصات لها 56 فترة. بعد مرور هذه الفترات ، لا يمكن فتح اعتراضات ضد أي من المخصصات أو الاستعلامات. عند فتح الاعتراض ، يجب على الصيادين Fishermen إيداع على الأقل 10000 GRT ، والتي سيتم حجزها حتى يتم الانتهاء من الاعتراض وتقديم حل. الصيادون Fisherman هم المشاركون في الشبكة الذين يفتحون الاعتراضات.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- إذا تم رفض الاعتراض، فسيتم حرق GRT المودعة من قبل ال Fishermen ، ولن يتم شطب المفهرس المعترض عليه.
+- إذا تمت تسوية الاعتراض بالتعادل، فسيتم إرجاع وديعة ال Fishermen ، ولن يتم شطب المفهرس المعترض عليه.
+- إذا تم قبول الاعتراض، فسيتم إرجاع GRT التي أودعها الFishermen ، وسيتم شطب المفهرس المعترض عليه وسيكسب Fishermen ال 50٪ من GRT المشطوبة.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### ما هي خصومات رسوم الاستعلام ومتى يتم توزيعها؟
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+
+### What is query fee cut and indexing reward cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### How do Indexers know which subgraphs to index?
+
+من خلال تطبيق تقنيات متقدمة لاتخاذ قرارات فهرسة ال subgraph ، وسنناقش العديد من المقاييس الرئيسية المستخدمة لتقييم ال subgraphs في الشبكة:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### ما هي المتطلبات للهاردوير؟
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Setup | Postgres<br /> (CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| ----- | :-------------------: | :---------------------------: | :-------------------------: | :-------------: | :----------------------: |
+| صغير  |           4           |               8               |              1              |        4        |            16            |
+| قياسي |           8           |               30              |              1              |        12       |            48            |
+| متوسط |           16          |               64              |              2              |        32       |            64            |
+| كبير  |           72          |              468              |             3.5             |        48       |            184           |
+
+### What are some basic security precautions an Indexer should take?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## البنية الأساسية
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+ملاحظة: لدعم القياس السريع ، يستحسن فصل الاستعلام والفهرسة بين مجموعات مختلفة من العقد Nodes: عقد الاستعلام وعقد الفهرس.
+
+### نظرة عامة على المنافذ Ports
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| المنفذ | الغرض                                             | المسار                                                  | CLI Argument      | متغيرات البيئة |
+| ------ | ------------------------------------------------- | ------------------------------------------------------- | ----------------- | -------------- |
+| 8000   | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | http-port--       | -              |
+| 8001   | GraphQL WS <br /> (for subgraph subscriptions)    | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | ws-port--         | -              |
+| 8020   | JSON-RPC <br /> (for managing deployments)        | /                                                       | admin-port--      | -              |
+| 8030   | Subgraph indexing status API                      | /graphql                                                | index-node-port-- | -              |
+| 8040   | Prometheus metrics                                | /metrics                                                | metrics-port--    | -              |
+
+#### خدمة المفهرس
+
+| المنفذ | الغرض                                                  | المسار                                                          | CLI Argument   | متغيرات البيئة         |
+| ------ | ------------------------------------------------------ | --------------------------------------------------------------- | -------------- | ---------------------- |
+| 7600   | GraphQL HTTP server <br /> (for paid subgraph queries) | /subgraphs/id/... <br /> /status <br /> /channel-messages-inbox | port--         | `INDEXER_SERVICE_PORT` |
+| 7300   | Prometheus metrics                                     | /metrics                                                        | metrics-port-- | -                      |
+
+#### وكيل المفهرس(Indexer Agent)
+
+| المنفذ | Purpose                | المسار | CLI Argument               | Environment Variable                    |
+| ------ | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000   | API إدارة المفهرس      | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### قم بإعداد البنية الأساسية للسيرفر باستخدام Terraform على جوجل كلاود
+
+> ملاحظة: يمكن للمفهرسين كبديل استخدام خدمات أمازون ويب، أو مايكروسوفت أزور، أو علي بابا.
+
+#### متطلبات التثبيت
+
+- Google Cloud SDK
+- أداة سطر أوامر Kubectl
+- Terraform
+
+#### أنشئ مشروع Google Cloud
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- قم بالتوثيق بواسطة Google Cloud وأنشئ مشروع جديد.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- استخدم [صفحة الفوترة] في Google Cloud Console لتمكين الفوترة للمشروع الجديد.
+
+- قم بإنشاء Google Cloud configuration.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- قم بتفعيل Google Cloud APIs المطلوبة.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- قم بإنشاء حساب الخدمة حساب الخدمة.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- قم بتفعيل ال peering بين قاعدة البيانات ومجموعة Kubernetes التي سيتم إنشاؤها في الخطوة التالية.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- قم بإنشاء الحد الأدنى من ملف التهيئة ل terraform (التحديث حسب الحاجة).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### استخدم Terraform لإنشاء البنية الأساسية
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- قم بتشغيل الأوامر التالية لإنشاء البنية الأساسية.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Creating the Kubernetes components for the Indexer
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### ابدأ من المصدر
+
+#### متطلبات التثبيت
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. شغل سيرفر قاعدة بيانات PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. ابدأ Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### الشروع في استخدام Docker
+
+#### المتطلبات الأساسية
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Setup
+
+1. انسخ Graph Node وانتقل إلى دليل Docker:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. ابدأ Graph Node محلية والتي ستتصل ب Ethereum endpoint الخاصة بك:
+
+```sh
+docker-compose up
+```
+
+### مكونات المفهرس Indexer components
+
+To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### ابدأ
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### من حزم NPM
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### من المصدر
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### استخدام docker
+
+- اسحب الصور من السجل
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+<strong x-id="1">ملاحظة</strong>: بعد بدء ال containers ، يجب أن تكون خدمة المفهرس متاحة على <a href="http://localhost:7600">http://localhost:7600</a> ويجب على وكيل المفهرس عرض API إدارة المفهرس على <a href="http://localhost:18000/">http://localhost:18000/</a>.
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- قم بتشغيل المكونات
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### استخدام K8s و Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### الاستخدام
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### وكيل المفهرس(Indexer Agent)
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### خدمة المفهرس Indexer service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### CLI المفهرس
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Indexer management using Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### الاستخدام
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### قواعد الفهرسة
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+نموذج البيانات Data model:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Example usage of indexing rule:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Action added to the queue by the 3rd party optimizer tool or indexer-cli user
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken.
+
+نموذج البيانات Data model:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Example usage from source:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Note that supported action types for allocation management have different input requirements:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - required action params:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - required action params:
+    - allocationID
+    - deploymentID
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - required action params:
+    - allocationID
+    - deploymentID
+    - amount
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+#### نماذج التكلفة Cost models
+
+Cost models provide dynamic pricing for queries based on market and query attributes. The Indexer Service shares a cost model with the gateways for each subgraph for which they intend to respond to queries. The gateways, in turn, use the cost model to make Indexer selection decisions per query and to negotiate payment with chosen Indexers.
+
+#### Agora
+
+توفر لغة Agora تنسيقا مرنا للإعلان عن نماذج التكلفة للاستعلامات. نموذج سعر Agora هو سلسلة من العبارات التي يتم تنفيذها بالترتيب لكل استعلام عالي المستوى في GraphQL. بالنسبة إلى كل استعلام عالي المستوى top-level ، فإن العبارة الأولى التي تتطابق معه تحدد سعر هذا الاستعلام.
+
+تتكون العبارة من المسند predicate ، والذي يستخدم لمطابقة استعلامات GraphQL وتعبير التكلفة والتي عند تقييم النواتج تكون التكلفة ب GRT عشري. قيم الاستعلام الموجودة في ال argument ،قد يتم تسجيلها في المسند predicate واستخدامها في التعبير expression. يمكن أيضًا تعيين Globals وتعويضه في التعبير expression.
+
+مثال لتكلفة الاستعلام باستخدام النموذج أعلاه:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+مثال على نموذج التكلفة:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### تطبيق نموذج التكلفة
+
+Cost models are applied via the Indexer CLI, which passes them to the Indexer Management API of the Indexer agent for storing in the database. The Indexer Service will then pick them up and serve the cost models to gateways whenever they ask for them.
+
+```sh
+'indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }
+indexer cost set model my_model.agora
+```
+
+## التفاعل مع الشبكة
+
+### Stake in the protocol
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### اعتماد التوكن tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Stake tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### عمر التخصيص allocation
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 245ec3322bb667c8c928fc01479f4d499876e560 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:49 -0500
Subject: [PATCH 0748/3820] New translations tap.mdx (Arabic)

---
 website/pages/ar/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/ar/indexing/tap.mdx

diff --git a/website/pages/ar/indexing/tap.mdx b/website/pages/ar/indexing/tap.mdx
new file mode 100644
index 000000000000..ee96a02cd5b8
--- /dev/null
+++ b/website/pages/ar/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## نظره عامة
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notes:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From ea4d1b26c75223447d47046af69ef79cad793cd2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:50 -0500
Subject: [PATCH 0749/3820] New translations graph-node.mdx (Arabic)

---
 .../pages/ar/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/ar/indexing/tooling/graph-node.mdx

diff --git a/website/pages/ar/indexing/tooling/graph-node.mdx b/website/pages/ar/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..24653047ebc4
--- /dev/null
+++ b/website/pages/ar/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL database
+
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
+
+### Network clients
+
+In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS Nodes
+
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+### Prometheus metrics server
+
+To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
+
+### ابدأ من المصدر
+
+#### متطلبات التثبيت
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. شغل سيرفر قاعدة بيانات PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. ابدأ Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Getting started with Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+When it is running Graph Node exposes the following ports:
+
+| المنفذ | الغرض                                             | المسار                                                  | CLI Argument      | متغيرات البيئة |
+| ------ | ------------------------------------------------- | ------------------------------------------------------- | ----------------- | -------------- |
+| 8000   | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | http-port--       | -              |
+| 8001   | GraphQL WS <br /> (for subgraph subscriptions)    | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | ws-port--         | -              |
+| 8020   | JSON-RPC <br /> (for managing deployments)        | /                                                       | admin-port--      | -              |
+| 8030   | Subgraph indexing status API                      | /graphql                                                | index-node-port-- | -              |
+| 8040   | Prometheus metrics                                | /metrics                                                | metrics-port--    | -              |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Advanced Graph Node configuration
+
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Multiple Graph Nodes
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding.
+
+#### Deployment rules
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Example deployment rule configuration:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Dedicated query nodes
+
+Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Any node whose --node-id matches the regular expression will be set up to only respond to queries.
+
+#### Database scaling via sharding
+
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore.
+
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Dedicated block ingestion
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Supporting multiple networks
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Multiple networks
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Environment variables
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Continuous deployment
+
+Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Managing Graph Node
+
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Working with subgraphs
+
+#### Indexing status API
+
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Indexing performance
+
+There are three separate parts of the indexing process:
+
+- Fetching events of interest from the provider
+- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
+- Writing the resulting data to the store
+
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+
+Common causes of indexing slowness:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- A large number of events to process
+- Slow database connection time, for crowded nodes
+- The provider itself falling behind the chain head
+- Slowness in fetching new receipts at the chain head from the provider
+
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+
+#### Failed subgraphs
+
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+
+- Deterministic failures: these are failures which will not be resolved with retries
+- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
+
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Block and call cache
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. If the block matches the provider, then the issue can be debugged directly against the provider.
+
+#### Querying issues and errors
+
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+
+However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+
+There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.
+
+##### Query caching
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analysing queries
+
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
+
+In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
+
+##### Account-like optimisation
+
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Removing subgraphs
+
+> This is new functionality, which will be available in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 921b8dd0f4d9a885189562b86bd2c7da6f5568ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:51 -0500
Subject: [PATCH 0750/3820] New translations advanced.mdx (Arabic)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/ar/subgraphs/developing/creating/advanced.mdx b/website/pages/ar/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..8c097d25ff62
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## نظره عامة
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## أخطاء غير فادحة
+
+Indexing errors on already synced subgraphs will, by default, cause the subgraph to fail and stop syncing. Subgraphs can alternatively be configured to continue syncing in the presence of errors, by ignoring the changes made by the handler which provoked the error. This gives subgraph authors time to correct their subgraphs while queries continue to be served against the latest block, though the results might be inconsistent due to the bug that caused the error. Note that some errors are still always fatal. To be non-fatal, the error must be known to be deterministic.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Enabling non-fatal errors requires setting the following feature flag on the subgraph manifest:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way. File data sources support fetching files from IPFS and from Arweave.
+
+> This also lays the groundwork for deterministic indexing of off-chain data, as well as the potential introduction of arbitrary HTTP-sourced data.
+
+### نظره عامة
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Upgrade guide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Add a new entity type which will be updated when files are found
+
+File data sources cannot access or update chain-based entities, but must update file specific entities.
+
+This may mean splitting out fields from existing entities into separate entities, linked together.
+
+Original combined entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+New, split entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+If the relationship is 1:1 between the parent entity and the resulting file data source entity, the simplest pattern is to link the parent entity to a resulting file entity by using the IPFS CID as the lookup. Get in touch on Discord if you are having difficulty modelling your new file-based entities!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+This is the data source which will be spawned when a file of interest is identified.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Create a new handler to process files
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Example handler:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Spawn file data sources when required
+
+You can now create file data sources during execution of chain-based handlers:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Example:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+This will create a new file data source, which will poll Graph Node's configured IPFS or Arweave endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Congratulations, you are using file data sources!
+
+#### Deploying your subgraphs
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitations
+
+File data source handlers and entities are isolated from other subgraph entities, ensuring that they are deterministic when executed, and ensuring no contamination of chain-based data sources. To be specific:
+
+- Entities created by File Data Sources are immutable, and cannot be updated
+- File Data Source handlers cannot access entities from other file data sources
+- Entities associated with File Data Sources cannot be accessed by chain-based handlers
+
+> While this constraint should not be problematic for most use-cases, it may introduce complexity for some. Please get in touch via Discord if you are having issues modelling your file-based data in a subgraph!
+
+Additionally, it is not possible to create data sources from a file data source, be it an onchain data source or another file data source. This restriction may be lifted in the future.
+
+#### Best practices
+
+If you are linking NFT metadata to corresponding tokens, use the metadata's IPFS hash to reference a Metadata entity from the Token entity. Save the Metadata entity using the IPFS hash as an ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> We are working to improve the above recommendation, so queries only return the "most recent" version
+
+#### Known issues
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Examples
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### المراجع
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Grafting على Subgraphs موجودة
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Because grafting copies rather than indexes base data, it is much quicker to get the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- يضيف أو يزيل أنواع الكيانات
+- يزيل الصفات من أنواع الكيانات
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- يغير للكيانات التي يتم تنفيذ الواجهة لها
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From dec2b2fc816bd903228c401189c04fed119c01d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:52 -0500
Subject: [PATCH 0751/3820] New translations api.mdx (Arabic)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/ar/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/ar/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..00a7c89a1454
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## مرجع API
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- الأوامر الأساسية منخفضة المستوى للترجمة بين أنظمة الأنواع المختلفة مثل Ethereum و JSON و GraphQL و AssemblyScript.
+
+### إصدارات
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| الاصدار | ملاحظات الإصدار                                                                                                                                                                                                                                          |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### الأنواع المضمنة (Built-in)
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+'import { ByteArray } from '@graphprotocol/graph-ts
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+'import { BigDecimal } from '@graphprotocol/graph-ts
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+'import { BigInt } from '@graphprotocol/graph-ts
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+'import { TypedMap } from '@graphprotocol/graph-ts
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+'import { Bytes } from '@graphprotocol/graph-ts
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### العنوان
+
+```typescript
+'import { Address } from '@graphprotocol/graph-ts
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### مخزن API
+
+```typescript
+'import { store } from '@graphprotocol/graph-ts
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### إنشاء الكيانات
+
+The following is a common pattern for creating entities from Ethereum events.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### تحميل الكيانات من المخزن
+
+If an entity already exists, it can be loaded from the store with the following:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Looking up entities created withing a block
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### تحديث الكيانات الموجودة
+
+There are two ways to update an existing entity:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+Changing properties is straight forward in most cases, thanks to the generated property setters:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+It is also possible to unset properties with one of the following two instructions:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### إزالة الكيانات من المخزن
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### API إيثيريوم
+
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
+
+#### دعم أنواع الإيثيريوم
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+The following example illustrates this. Given a subgraph schema like
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### الأحداث وبيانات الكتلة/ الإجراء
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### الوصول إلى حالة العقد الذكي Smart Contract
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+A common pattern is to access the contract from which an event originates. This is achieved with the following code:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address.
+
+#### معالجة الاستدعاءات المعادة
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### تشفير/فك تشفير ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+For more information:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### تسجيل قيمة واحدة أو أكثر
+
+##### تسجيل قيمة واحدة
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### تسجيل إدخال واحد من مصفوفة موجودة
+
+In the example below, only the first value of the argument array is logged, despite the array containing three values.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### تسجيل إدخالات متعددة من مصفوفة موجودة
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### تسجيل إدخال محدد من مصفوفة موجودة
+
+To display a specific value in the array, the indexed value must be provided.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### تسجيل معلومات الحدث
+
+The example below logs the block number, block hash and transaction hash from an event:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+'import { ipfs } from '@graphprotocol/graph-ts
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Given an IPFS hash or path, reading a file from IPFS is done as follows:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### Crypto API
+
+```typescript
+'import { crypto } from '@graphprotocol/graph-ts
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+'import { json, JSONValueKind } from '@graphprotocol/graph-ts
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### مرجع تحويلات الأنواع
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### البيانات الوصفية لمصدر البيانات
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### الكيان و DataSourceContext
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From f391838af8972c6a693c38d62453bf954dcf7fa5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:53 -0500
Subject: [PATCH 0752/3820] New translations common-issues.mdx (Arabic)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/ar/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/ar/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..6c50af984ad0
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: مشاكل شائعة في أسمبلي سكريبت (AssemblyScript)
+---
+
+هناك بعض مشاكل [أسمبلي سكريبت](https://github.com/AssemblyScript/assemblyscript) المحددة، التي من الشائع الوقوع فيها أثتاء تطوير غرافٍ فرعي. وهي تتراوح في صعوبة تصحيح الأخطاء، ومع ذلك، فإنّ إدراكها قد يساعد. وفيما يلي قائمة غير شاملة لهذه المشاكل:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- لا يتم توريث النطاق في [دوال الإغلاق](https://www.assemblyscript.org/status.html#on-closures)، أي لا يمكن استخدام المتغيرات المعلنة خارج دوال الإغلاق. الشرح في [ النقاط الهامة للمطورين #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 1002f8c4d7bf1def6212f7a31b05b82fdecf25d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:55 -0500
Subject: [PATCH 0753/3820] New translations unit-testing-framework.mdx
 (Arabic)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/ar/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/ar/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..1c8706be8edf
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: اختبار وحدة Framework
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Getting Started
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+or
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+This will run all tests in the test folder:
+
+```sh
+graph test
+```
+
+This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
+
+```sh
+graph test gravity
+```
+
+This will run only that specific test file:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo subgraph
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Video tutorials
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+or
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+أمثلة:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Example:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+أمثلة:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Write a Unit Test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Assuming we have the following handler function (along with two helper functions to make our life easier):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+We first have to create a test file in our project. This is an example of how that might look like:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- We're setting up our initial state and adding one custom Gravatar entity;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- We assert the state of the store. How does that work? - We're passing a unique combination of Entity type and id. Then we check a specific field on that Entity and assert that it has the value we expect it to have. We're doing this both for the initial Gravatar Entity we added to the store, as well as the two Gravatar entities that gets added when the handler function is called;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+There we go - we've created our first test! 👏
+
+Now in order to run our tests you simply need to run the following in your subgraph root folder:
+
+`graph test Gravity`
+
+And if all goes well you should be greeted with the following:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Common test scenarios
+
+### Hydrating the store with a certain state
+
+Users are able to hydrate the store with a known set of entities. Here's an example to initialise the store with a Gravatar entity:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Calling a mapping function with an event
+
+A user can create a custom event and pass it to a mapping function that is bound to the store:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Calling all of the mappings with event fixtures
+
+Users can call the mappings with test fixtures.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocking contract calls
+
+Users can mock contract calls:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+As demonstrated, in order to mock a contract call and hardcore a return value, the user must provide a contract address, function name, function signature, an array of arguments, and of course - the return value.
+
+Users can also mock function reverts:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking IPFS files (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Asserting the state of the store
+
+Users are able to assert the final (or midway) state of the store through asserting entities. In order to do this, the user has to supply an Entity type, the specific ID of an Entity, a name of a field on that Entity, and the expected value of the field. Here's a quick example:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interacting with Event metadata
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Asserting variable equality
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Users can assert that an entity does not exist in the store. The function takes an entity type and an id. If the entity is in fact in the store, the test will fail with a relevant error message. Here's a quick example of how to use this functionality:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+You can print the whole store to the console using this helper function:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Expected failure
+
+Users can have expected test failures, using the shouldFail flag on the test() functions:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+If the test is marked with shouldFail = true but DOES NOT fail, that will show up as an error in the logs and the test block will fail. Also, if it's marked with shouldFail = false (the default state), the test executor will crash.
+
+### Logging
+
+Having custom logs in the unit tests is exactly the same as logging in the mappings. The difference is that the log object needs to be imported from matchstick-as rather than graph-ts. Here's a simple example with all non-critical log types:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Users can also simulate a critical failure, like so:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Logging critical errors will stop the execution of the tests and blow everything up. After all - we want to make sure you're code doesn't have critical logs in deployment, and you should notice right away if that were to happen.
+
+### Testing derived fields
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testing dynamic data sources
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Example below:
+
+First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+And then we have the test using one of the methods in the dataSourceMock namespace to set a new return value for all of the dataSource functions:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Notice that dataSourceMock.resetValues() is called at the end. That's because the values are remembered when they are changed and need to be reset if you want to go back to the default values.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Test Coverage
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### المتطلبات الأساسية
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Export your handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### الاستخدام
+
+Once that's all set up, to run the test coverage tool, simply run:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Test run time duration in the log output
+
+The log output includes the test run duration. Here's an example:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Common compiler errors
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## مصادر إضافية
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Feedback
+
+If you have any questions, feedback, feature requests or just want to reach out, the best place would be The Graph Discord where we have a dedicated channel for Matchstick, called 🔥| unit-testing.

From 10e784ec38189953bb04004f930f5d6c1620623b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:56 -0500
Subject: [PATCH 0754/3820] New translations transferring-a-subgraph.mdx
 (Arabic)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/ar/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/ar/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 4a48fecd4370def960ad3ee52a91ec327ed14ef9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:57 -0500
Subject: [PATCH 0755/3820] New translations graphql-api.mdx (Arabic)

---
 .../ar/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/ar/subgraphs/querying/graphql-api.mdx b/website/pages/ar/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..b93b5b717f96
--- /dev/null
+++ b/website/pages/ar/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Examples
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sorting
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Example
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Example for nested entity sorting
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Pagination
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Query the first 10 tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtering
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Example for range filtering
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for block filtering
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for nested entity filtering
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+This can be useful if you are looking to fetch only entities whose child-level entities meet the provided conditions.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logical operators
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### All Filters
+
+Full list of parameter suffixes:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Time-travel queries
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltext Search Queries
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Fulltext search operators:
+
+| رمز   | عامل التشغيل | الوصف                                                                                                                       |
+| ----- | ------------ | --------------------------------------------------------------------------------------------------------------------------- |
+| `&`   | `And`        | لدمج عبارات بحث متعددة في فلتر للكيانات التي تتضمن جميع العبارات المتوفرة                                                   |
+| |     | `Or`         | الاستعلامات التي تحتوي على عبارات بحث متعددة مفصولة بواسطة عامل التشغيل or ستعيد جميع الكيانات المتطابقة من أي عبارة متوفرة |
+| `<->` | `Follow by`  | يحدد المسافة بين كلمتين.                                                                                                    |
+| `:*`  | `Prefix`     | يستخدم عبارة البحث prefix للعثور على الكلمات التي تتطابق بادئتها (مطلوب حرفان.)                                             |
+
+#### Examples
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validation
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## المخطط
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Subgraph Metadata
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: the hash of the block
+- number: the block number
+- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From e2debf19d01d576f2fcbd72b5843521f704e4bf9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:58 -0500
Subject: [PATCH 0756/3820] New translations python.mdx (Arabic)

---
 .../pages/ar/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/querying/python.mdx

diff --git a/website/pages/ar/subgraphs/querying/python.mdx b/website/pages/ar/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..c10d7a0e57ab
--- /dev/null
+++ b/website/pages/ar/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Getting Started
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From fb79cd37a4aeeb5685945df3f8a37bfb3bc1e3f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:12:59 -0500
Subject: [PATCH 0757/3820] New translations triggers.mdx (Arabic)

---
 website/pages/ar/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/ar/substreams/sps/triggers.mdx

diff --git a/website/pages/ar/substreams/sps/triggers.mdx b/website/pages/ar/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/ar/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From ea4b002236204b525e22e3d7d5d2a8392f42f6c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:00 -0500
Subject: [PATCH 0758/3820] New translations overview.mdx (Czech)

---
 website/pages/cs/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/cs/indexing/overview.mdx

diff --git a/website/pages/cs/indexing/overview.mdx b/website/pages/cs/indexing/overview.mdx
new file mode 100644
index 000000000000..0a053109d883
--- /dev/null
+++ b/website/pages/cs/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexery jsou operátoři uzlů v síti Graf, kteří sázejí graf tokeny (GRT), aby mohli poskytovat služby indexování a zpracování dotazů. Indexátoři za své služby získávají poplatky za dotazy a odměny za indexování. Získávají také poplatky za dotazy, které jsou vráceny podle exponenciální funkce vrácení.
+
+GRT, který je v protokolu založen, podléhá období rozmrazování a může být zkrácen, pokud jsou indexátory škodlivé a poskytují aplikacím nesprávná data nebo pokud indexují nesprávně. Indexátoři také získávají odměny za delegované sázky od delegátů, aby přispěli do sítě.
+
+Indexátory vybírají podgrafy k indexování na základě signálu kurátorů podgrafů, přičemž kurátoři sázejí na GRT, aby určili, které podgrafy jsou vysoce kvalitní a měly by být upřednostněny. Spotřebitelé (např. aplikace) mohou také nastavit parametry, podle kterých indexátoři zpracovávají dotazy pro jejich podgrafy, a nastavit preference pro stanovení ceny poplatků za dotazy.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### Jaký je minimální podíl potřebný k tomu, abyste se mohli stát indexátorem v síti?
+
+Minimální vklad pro indexátora je v současné době nastaven na 100k GRT.
+
+### Jaké jsou toky příjmů pro indexátora?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### Jak se rozdělují odměny za indexaci?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### Co je Důkaz indexování (POI)?
+
+V síti se používají Proofy indexování (POI) k ověření, zda indexátor skutečně indexuje podgrafy, na které má alokovanou kapacitu. Pro uzavření alokace a možnost získat odměny za indexování je nutné při uzavírání alokace předložit POI pro první blok aktuální epochy. POI pro daný blok je souhrn všech transakcí v úložišti entit pro konkrétní nasazení podgrafu, a to až do tohoto bloku včetně.
+
+### Kdy se rozdělují odměny za indexaci?
+
+Za přidělení se průběžně připisují odměny, dokud jsou aktivní a přidělené během 28 epoch. Odměny jsou shromažďovány indexátory a rozdělovány vždy, když jsou jejich alokace uzavřeny. To se děje buď ručně, kdykoli je chce indexátor násilně uzavřít, nebo po 28 epochách může alokaci za indexátora uzavřít delegát, což však nevede k žádným odměnám. 28 epoch je maximální doba životnosti alokace (právě teď trvá jedna epocha ~24 hodin).
+
+### Lze sledovat čekající odměny za indexaci?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Mnoho informačních panelů vytvořených komunitou obsahuje hodnoty čekajících odměn a lze je snadno zkontrolovat ručně podle následujících kroků:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### Co jsou to spory a kde si je mohu prohlédnout?
+
+Dotazy indexátoru i alokace lze v grafu zpochybnit během sporného období. Období sporu se liší v závislosti na typu sporu. Dotazy/atesty mají 7 epochové sporné okno, zatímco alokace mají 56 epoch. Po uplynutí těchto období nelze zahájit spor ani proti alokacím, ani proti dotazům. Při zahájení sporu musí rybáři složit zálohu v minimální výši 10,000 GRT, která bude zablokována až do ukončení sporu a vydání rozhodnutí. Rybáři jsou všichni účastníci sítě, kteří otevírají spory.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- Pokud bude spor zamítnut, GRT složené rybáři budou spáleny a sporný indexátor nebude krácen.
+- Pokud je spor vyřešen nerozhodně, bude Fishermen's vklad vrácen a sporný indexátor nebude penalizován snížením stake.
+- Pokud je spor uznán, bude Fishermen's vklad vrácen, sporný indexátor bude penalizován snížením stake a Fishermen obdrží 50 % sníženého stake.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### Co jsou to slevy z poplatků za dotaz a kdy se rozdělují?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Po uzavření přídělu může indexátor požádat o slevy. Po uplatnění nároku jsou slevy z poplatku za dotaz rozděleny mezi indexátora a jeho delegáty na základě snížení poplatku za dotaz a exponenciální funkce slevy.
+
+### Co je to snížení poplatku za dotaz a snížení odměny za indexaci?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### Jak indexátory poznají, které podgrafy mají indexovat?
+
+Indexátory se mohou odlišovat použitím pokročilých technik pro rozhodování o indexaci podgrafů, ale pro obecnou představu probereme několik klíčových metrik používaných k hodnocení podgrafů v síti:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### Jaké jsou požadavky na hardware?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Nastavení | Postgres<br />(CPUs) | Postgres<br />(paměť v GBs) | Postgres<br />(disk v TBs) | VMs<br />(CPUs) | VMs<br />(paměť v GBs) |
+| --------- | :------------------: | :-------------------------: | :------------------------: | :-------------: | :--------------------: |
+| Malé      |           4          |              8              |              1             |        4        |           16           |
+| Standard  |           8          |              30             |              1             |        12       |           48           |
+| Střední   |          16          |              64             |              2             |        32       |           64           |
+| Velký     |          72          |             468             |             3.5            |        48       |           184          |
+
+### Jaká jsou základní bezpečnostní opatření, která by měl indexátor přijmout?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastruktura
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Poznámka: Pro podporu agilního škálování se doporučuje oddělit dotazování a indexování mezi různé sady uzlů: dotazovací uzly a indexovací uzly.
+
+### Přehled portů
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Uzel Graf
+
+| Port | Účel                                           | Trasy                                          | CLI Argument       | Proměnná prostředí |
+| ---- | ---------------------------------------------- | ---------------------------------------------- | ------------------ | ------------------ |
+| 8000 | GraphQL HTTP server<br />(pro dotazy podgrafy) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                  |
+| 8001 | GraphQL WS<br />(pro odběry podgrafů)          | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                  |
+| 8020 | JSON-RPC<br />(pro správu nasazení)            | /                                              | \--admin-port      | -                  |
+| 8030 | Stav indexování podgrafů API                   | /graphql                                       | \--index-node-port | -                  |
+| 8040 | Metriky Prometheus                             | /metrics                                       | \--metrics-port    | -                  |
+
+#### Služba Indexer
+
+| Port | Účel                                                      | Trasy                                                       | CLI Argument    | Proměnná prostředí     |
+| ---- | --------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(pro placené dotazy na podgrafy) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Metriky Prometheus                                        | /metrics                                                    | \--metrics-port | -                      |
+
+#### Agent indexátoru
+
+| Port | Purpose                   | Trasy  | CLI Argument               | Environment Variable                    |
+| ---- | ------------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | API pro správu indexátoru | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Nastavení serverové infrastruktury pomocí Terraformu ve Google Cloud
+
+> Poznámka: Indexéry mohou alternativně používat AWS, Microsoft Azure nebo Alibaba.
+
+#### Instalace předpokladů
+
+- Google Cloud SDK
+- Nástroj příkazového řádku Kubectl
+- Terraform
+
+#### Vytvoření projektu Google Cloud
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Ověřte se pomocí služby Google Cloud a vytvořte nový projekt.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Pomocí fakturační stránky konzoly Google Cloud Console povolte fakturaci pro nový projekt.
+
+- Vytvořte konfiguraci služby Google Cloud.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Povolte požadované Google Cloud API.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Vytvoření účtu služby.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Povolte peering mezi databází a clusterem Kubernetes, který bude vytvořen v dalším kroku.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Vytvořte minimální konfigurační soubor terraformu (aktualizujte jej podle potřeby).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Použití nástroje Terraform k vytvoření infrastruktury
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Pro vytvoření infrastruktury spusťte následující příkazy.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Vytvoření komponent Kubernetes pro Indexer
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Uzel Graf
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Začínáme od zdroje
+
+#### Instalace předpokladů
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Nastavení
+
+1. Spuštění databázového serveru PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Nyní, když jsou všechny závislosti nastaveny, spusťte uzel Graf:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Začínáme používat Docker
+
+#### Požadavky
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Nastavení
+
+1. Klonujte graf uzel a najděte cestu do adresáře Docker:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Spusťte místní uzel Graf, který se připojí ke koncovému bodu Ethereum:
+
+```sh
+docker-compose up
+```
+
+### Součásti indexeru
+
+Úspěšná účast v síti vyžaduje téměř neustálé sledování a interakci, proto jsme vytvořili sadu aplikací Typescript pro usnadnění účasti v síti Indexers. K dispozici jsou tři komponenty Indexer:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Začínáme
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### Z balíčků NPM
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### Ze zdroje
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Použití docker
+
+- Stažení obrázků z registru
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Nebo sestavte obrazy lokálně ze zdrojových kódů
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Spustit komponenty
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Použití K8s a Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Použití
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Agent indexátoru
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Služba Indexer
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Správa indexeru pomocí Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Použití
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Pravidla indexování
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Datový model:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Příklad použití indexovacího pravidla:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Fronta akcí CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Akce přidaná do fronty nástrojem optimalizace třetí strany nebo uživatelem indexer-cli
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- Indexer může sledovat frontu akcí a zobrazit historii jejich provádění a v případě potřeby znovu schválit a aktualizovat položky akcí, pokud se nepodařilo je provést. Fronta akcí poskytuje historii všech akcí zařazených do fronty a provedených.
+
+Datový model:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Příklad použití ze zdroje:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Všimněte si, že podporované typy akcí pro správu přidělování mají různé vstupní požadavky:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - požadované parametry akce:
+    - deploymentID
+    - částka
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - požadované parametry akce:
+    - allocationID
+    - deploymentID
+  - volitelné parametry akce:
+    - poi
+    - síla (vynutí pomocí poskytnutého POI, i když neodpovídá tomu, co poskytuje uzel graf)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - požadované parametry akce:
+    - allocationID
+    - deploymentID
+    - částka
+  - volitelné parametry akce:
+    - poi
+    - síla (vynutí pomocí poskytnutého POI, i když neodpovídá tomu, co poskytuje uzel graf)
+
+#### Nákladové modely
+
+Modely nákladů poskytují dynamické ceny pro dotazy na základě atributů trhu a dotazu. Služba Indexer sdílí s gateway model nákladů pro každý pods podgraf, na jehož dotazy chtějí odpovídat. Gatewaye pak na základě modelu nákladů rozhodují o výběru indexátoru pro každý dotaz a vyjednávají platby s vybranými indexátory.
+
+#### Agora
+
+Jazyk Agora poskytuje flexibilní formát pro deklarování nákladových modelů pro dotazy. Cenový model Agora je posloupnost příkazů, které se provádějí v pořadí pro každý dotaz nejvyšší úrovně v dotazu GraphQL. Pro každý dotaz nejvyšší úrovně určuje cenu tohoto dotazu první příkaz, který mu odpovídá.
+
+Příkaz se skládá z predikátu, který se používá pro porovnávání dotazů GraphQL, a nákladového výrazu, který po vyhodnocení vypisuje náklady v desetinném GRT. Hodnoty na pozici pojmenovaného argumentu dotazu mohou být zachyceny v predikátu a použity ve výrazu. Globály lze také nastavit a nahradit jimi zástupné znaky ve výrazu.
+
+Příklad nákladového modelu:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Příklad výpočtu nákladů na dotaz pomocí výše uvedeného modelu:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Použití nákladového modelu
+
+Nákladové modely se používají prostřednictvím Indexer CLI, které je předává API pro správu indexátoru agenta Indexer k uložení do databáze. Služba Indexer je pak vyzvedne a nákladové modely doručí branám, kdykoli o ně požádají.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interakce se sítí
+
+### Podíl na protokolu
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Schválení žetonů
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Vkladové žetony
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### Životnost přídělu
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 8ccce9c4e1792841dac5cd15896cf8f58b394184 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:01 -0500
Subject: [PATCH 0759/3820] New translations tap.mdx (Czech)

---
 website/pages/cs/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/cs/indexing/tap.mdx

diff --git a/website/pages/cs/indexing/tap.mdx b/website/pages/cs/indexing/tap.mdx
new file mode 100644
index 000000000000..f8d028634016
--- /dev/null
+++ b/website/pages/cs/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Přehled
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Požadavky
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Poznámky:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From e0a79f77f15c952263da476809ce91691213c592 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:02 -0500
Subject: [PATCH 0760/3820] New translations graph-node.mdx (Czech)

---
 .../pages/cs/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/cs/indexing/tooling/graph-node.mdx

diff --git a/website/pages/cs/indexing/tooling/graph-node.mdx b/website/pages/cs/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..1bac977b6aee
--- /dev/null
+++ b/website/pages/cs/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Uzel Graf
+---
+
+Graf Uzel je komponenta, která indexuje podgrafy a zpřístupňuje výsledná data k dotazování prostřednictvím rozhraní GraphQL API. Jako taková je ústředním prvkem zásobníku indexeru a její správná činnost je pro úspěšný provoz indexeru klíčová.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Uzel Graf
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### Databáze PostgreSQL
+
+Hlavní úložiště pro uzel Graf Uzel, kde jsou uložena data podgrafů, metadata o podgraf a síťová data týkající se podgrafů, jako je bloková cache a cache eth_call.
+
+### Síťoví klienti
+
+Aby mohl uzel Graph Node indexovat síť, potřebuje přístup k síťovému klientovi prostřednictvím rozhraní API JSON-RPC kompatibilního s EVM. Toto RPC se může připojit k jedinému klientovi nebo může jít o složitější nastavení, které vyrovnává zátěž mezi více klienty.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS uzly
+
+Metadata nasazení podgrafů jsou uložena v síti IPFS. Uzel Graf přistupuje během nasazení podgrafu především k uzlu IPFS, aby načetl manifest podgrafu a všechny propojené soubory. Síťové indexery nemusí hostit vlastní uzel IPFS. Uzel IPFS pro síť je hostován na adrese https://ipfs.network.thegraph.com.
+
+### Metrický server Prometheus
+
+Aby bylo možné monitorovat a podávat zprávy, může uzel Graf volitelně zaznamenávat metriky na metrický server Prometheus.
+
+### Začínáme od zdroje
+
+#### Instalace předpokladů
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Nastavení
+
+1. Spuštění databázového serveru PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Nyní, když jsou všechny závislosti nastaveny, spusťte uzel Graf:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Začínáme s Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+Když je Graf Uzel spuštěn, zpřístupňuje následující ports:
+
+| Port | Účel                                           | Trasy                                          | CLI Argument       | Proměnná prostředí |
+| ---- | ---------------------------------------------- | ---------------------------------------------- | ------------------ | ------------------ |
+| 8000 | GraphQL HTTP server<br />(pro dotazy podgrafy) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                  |
+| 8001 | GraphQL WS<br />(pro odběry podgrafů)          | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                  |
+| 8020 | JSON-RPC<br />(pro správu nasazení)            | /                                              | \--admin-port      | -                  |
+| 8030 | Stav indexování podgrafů API                   | /graphql                                       | \--index-node-port | -                  |
+| 8040 | Metriky Prometheus                             | /metrics                                       | \--metrics-port    | -                  |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Pokročilá konfigurace uzlu Graf
+
+V nejjednodušším případě lze Graf Uzel provozovat s jednou instancí Graf Uzel, jednou databází PostgreSQL, uzlem IPFS a síťovými klienty podle potřeby indexovaných podgrafů.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> Při použití konfiguračního souboru není možné použít volby --postgres-url, --postgres-secondary-hosts a --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Více uzlů graf
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Všimněte si, že více graf uzlů lze nakonfigurovat tak, aby používaly stejnou databázi, kterou lze horizontálně škálovat pomocí sharding.
+
+#### Pravidla nasazení
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Příklad konfigurace pravidla nasazení:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Vyhrazené dotazovací uzly
+
+Uzly lze nakonfigurovat tak, aby byly explicitně dotazovacími uzly, a to tak, že do konfiguračního souboru vložíte následující údaje:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Každý uzel, jehož --node-id odpovídá regulárnímu výrazu, bude nastaven tak, aby odpovídal pouze na dotazy.
+
+#### Škálování databáze pomocí sharding
+
+Pro většinu případů použití postačuje k podpoře instance graf uzlu jedna databáze Postgres. Pokud instance graf uzlu přeroste rámec jedné databáze Postgres, je možné rozdělit ukládání dat grafového uzlu do více databází Postgres. Všechny databáze dohromady tvoří úložiště instance graf uzlu. Každá jednotlivá databáze se nazývá shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding se stává užitečným, když vaše stávající databáze nedokáže udržet krok se zátěží, kterou na ni Graf Uzel vyvíjí, a když už není možné zvětšit velikost databáze.
+
+> Obecně je lepší vytvořit jednu co největší databázi, než začít s oddíly. Jednou z výjimek jsou případy, kdy je provoz dotazů rozdělen velmi nerovnoměrně mezi dílčí podgrafy; v těchto situacích může výrazně pomoci, pokud jsou dílčí podgrafy s velkým objemem uchovávány v jednom shardu a vše ostatní v jiném, protože toto nastavení zvyšuje pravděpodobnost, že data pro dílčí podgrafu s velkým objemem zůstanou v interní cache db a nebudou nahrazena daty, která nejsou tolik potřebná z dílčích podgrafů s malým objemem.
+
+Pokud jde o konfiguraci připojení, začněte s max_connections v souboru postgresql.conf nastaveným na 400 (nebo možná dokonce 200) a podívejte se na metriky store_connection_wait_time_ms a store_connection_checkout_count Prometheus. Výrazné čekací doby (cokoli nad 5 ms) jsou známkou toho, že je k dispozici příliš málo připojení; vysoké čekací doby tam budou také způsobeny tím, že databáze je velmi vytížená (například vysoké zatížení procesoru). Pokud se však databáze jinak jeví jako stabilní, vysoké čekací doby naznačují potřebu zvýšit počet připojení. V konfiguraci je horní hranicí, kolik připojení může každá instance graf uzlu používat, a graf uzel nebude udržovat otevřená připojení, pokud je nepotřebuje.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Vyhrazené zpracování bloků
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Podpora více sítí
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Více sítí
+- Více poskytovatelů na síť (to může umožnit rozdělení zátěže mezi poskytovatele a také konfiguraci plných uzlů i archivních uzlů, přičemž Graph Node může preferovat levnější poskytovatele, pokud to daná pracovní zátěž umožňuje).
+- Další údaje o poskytovateli, jako jsou funkce, ověřování a typ poskytovatele (pro experimentální podporu Firehose)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Proměnná prostředí
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Průběžné nasazování
+
+Uživatelé, kteří provozují škálované nastavení indexování s pokročilou konfigurací, mohou využít správu svých graf uzlů pomocí Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Správa uzlu graf
+
+Vzhledem k běžícímu uzlu Graf (nebo uzlům Graf Uzel!) je pak úkolem spravovat rozmístěné podgrafy v těchto uzlech. Graf Uzel nabízí řadu nástrojů, které pomáhají se správou podgrafů.
+
+#### Protokolování
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graf Uzel poskytuje metriky prostřednictvím koncového bodu Prometheus na portu 8040 ve výchozím nastavení. K vizualizaci těchto metrik lze pak použít nástroj Grafana.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Práce s podgrafy
+
+#### Stav indexování API
+
+API pro stav indexování, které je ve výchozím nastavení dostupné na portu 8030/graphql, nabízí řadu metod pro kontrolu stavu indexování pro různé podgrafy, kontrolu důkazů indexování, kontrolu vlastností podgrafů a další.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Výkonnost indexování
+
+Proces indexování má tři samostatné části:
+
+- Získávání zajímavých událostí od zprostředkovatele
+- Zpracování událostí v pořadí pomocí příslušných obslužných (to může zahrnovat volání řetězce pro zjištění stavu a načtení dat z úložiště)
+- Zápis výsledných dat do úložiště
+
+Tyto fáze jsou spojeny do potrubí (tj. mohou být prováděny paralelně), ale jsou na sobě závislé. Pokud se podgrafy indexují pomalu, bude příčina záviset na konkrétním podgrafu.
+
+Běžné příčiny pomalého indexování:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- Velké množství interakcí s úložištěm během provádění
+- Velké množství dat k uložení do úložiště
+- Velký počet událostí ke zpracování
+- Pomalá doba připojení k databázi u přeplněných uzlů
+- Samotný poskytovatel se dostává za hlavu řetězu
+- Pomalé načítání nových účtenek od poskytovatele v hlavě řetězce
+
+Metriky indexování podgrafů mohou pomoci diagnostikovat hlavní příčinu pomalého indexování. V některých případech spočívá problém v samotném podgrafu, ale v jiných případech mohou zlepšení síťových poskytovatelů, snížení konfliktů v databázi a další zlepšení konfigurace výrazně zlepšit výkon indexování.
+
+#### Neúspěšné podgrafy
+
+Během indexování mohou dílčí graf selhat, pokud narazí na neočekávaná data, pokud některá komponenta nefunguje podle očekávání nebo pokud je chyba ve zpracovatelích událostí nebo v konfiguraci. Existují dva obecné typy selhání:
+
+- Deterministická selhání: jedná se o selhání, která nebudou vyřešena opakovanými pokusy
+- Nedeterministická selhání: mohou být způsobena problémy se zprostředkovatelem nebo neočekávanou chybou grafického uzlu. Pokud dojde k nedeterministickému selhání, uzel Graf zopakuje selhání obsluhy a postupně se vrátí zpět.
+
+V některých případech může být chyba řešitelná indexátorem (například pokud je chyba důsledkem toho, že není k dispozici správný typ zprostředkovatele, přidání požadovaného zprostředkovatele umožní pokračovat v indexování). V jiných případech je však nutná změna v kódu podgrafu.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Bloková a volací mezipaměť
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+Pokud existuje podezření na nekonzistenci blokové mezipaměti, například chybějící událost tx receipt:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. Pokud se blok shoduje s poskytovatelem, lze problém ladit přímo proti poskytovateli.
+
+#### Problémy a chyby při dotazování
+
+Jakmile je podgraf indexován, lze očekávat, že indexery budou obsluhovat dotazy prostřednictvím koncového bodu vyhrazeného pro dotazy podgrafu. Pokud indexátor doufá, že bude obsluhovat značný objem dotazů, doporučuje se použít vyhrazený uzel pro dotazy a v případě velmi vysokého objemu dotazů mohou indexátory chtít nakonfigurovat oddíly replik tak, aby dotazy neovlivňovaly proces indexování.
+
+I s vyhrazeným dotazovacím uzlem a replikami však může provádění některých dotazů trvat dlouho a v některých případech může zvýšit využití paměti a negativně ovlivnit dobu dotazování ostatních uživatelů.
+
+Neexistuje jedna "stříbrná kulka", ale celá řada nástrojů pro prevenci, diagnostiku a řešení pomalých dotazů.
+
+##### Ukládání dotazů do mezipaměti
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analýza dotazů
+
+Problematické dotazy se nejčastěji objevují jedním ze dvou způsobů. V některých případech uživatelé sami hlásí, že daný dotaz je pomalý. V takovém případě je úkolem diagnostikovat příčinu pomalosti - zda se jedná o obecný problém, nebo o specifický problém daného podgrafu či dotazu. A pak ho samozřejmě vyřešit, pokud je to možné.
+
+V jiných případech může být spouštěcím faktorem vysoké využití paměti v uzlu dotazu a v takovém případě je třeba nejprve identifikovat dotaz, který problém způsobuje.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Při pomalém dotazu mají indexátory několik možností. Samozřejmě mohou změnit svůj nákladový model a výrazně zvýšit náklady na odeslání problematického dotazu. To může vést ke snížení četnosti tohoto dotazu. To však často neřeší hlavní příčinu problému.
+
+##### Optimalizace podobná účtu
+
+Zdá se, že databázové tabulky, které uchovávají entity, se obecně vyskytují ve dvou variantách: Jsou to tabulky "transakční", kde entity, jakmile jsou jednou vytvořeny, nejsou nikdy aktualizovány, tj. ukládají něco podobného seznamu finančních transakcí, a "účetní", kde jsou entity aktualizovány velmi často, tj. ukládají něco podobného finančním účtům, které se mění při každé zaznamenané transakci. Tabulky podobné účtům se vyznačují tím, že obsahují velké množství verzí entit, ale relativně málo odlišných entit. Často je v takových tabulkách počet odlišných entit 1 % z celkového počtu řádků (verzí entit)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Odstranění podgrafů
+
+> Jedná se o novou funkci, která bude k dispozici v uzlu Graf 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From bce993075583be63fad24c77a8f223781a092973 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:03 -0500
Subject: [PATCH 0761/3820] New translations advanced.mdx (Czech)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/cs/subgraphs/developing/creating/advanced.mdx b/website/pages/cs/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..aea6ad357dd8
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Přehled
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Nefatální
+
+Chyby indexování v již synchronizovaných podgrafech ve výchozím nastavení způsobí selhání podgrafy a zastavení synchronizace. Podgrafy lze alternativně nakonfigurovat tak, aby pokračovaly v synchronizaci i při přítomnosti chyb, a to ignorováním změn provedených obslužnou rutinou, která chybu vyvolala. To dává autorům podgrafů čas na opravu jejich podgrafů, zatímco dotazy jsou nadále obsluhovány proti poslednímu bloku, ačkoli výsledky mohou být nekonzistentní kvůli chybě, která chybu způsobila. Všimněte si, že některé chyby jsou stále fatální. Aby chyba nebyla fatální, musí být známo, že je deterministická.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Povolení nefatálních chyb vyžaduje nastavení následujícího příznaku funkce v manifestu podgraf:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+Zdroje dat souborů jsou novou funkcí podgrafu pro přístup k datům mimo řetězec během indexování robustním a rozšiřitelným způsobem. Zdroje souborových dat podporují načítání souborů ze systému IPFS a z Arweave.
+
+> To také vytváří základ pro deterministické indexování dat mimo řetězec a potenciální zavedení libovolných dat ze zdrojů HTTP.
+
+### Přehled
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Průvodce upgradem
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Přidání nového typu entity, který bude aktualizován při nalezení souborů
+
+Zdroje dat souborů nemohou přistupovat k entitám založeným na řetězci ani je aktualizovat, ale musí aktualizovat entity specifické pro soubor.
+
+To může znamenat rozdělení polí ze stávajících entit do samostatných entit, které budou vzájemně propojeny.
+
+Původní kombinovaný entita:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+Nové, rozdělená entit:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+Pokud je vztah mezi nadřazenou entitou a entitou výsledného zdroje dat souboru 1:1, je nejjednodušším vzorem propojení nadřazené entity s entitou výsledného souboru pomocí CID IPFS jako vyhledávacího prvku. Pokud máte potíže s modelováním nových entit založených na souborech, ozvěte se na Discord!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+Jedná se o zdroj dat, který bude vytvořen při identifikaci souboru zájmu.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Vytvoření nové obslužné pro zpracování souborů
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Příklad 
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Spawn zdrojů dat souborů v případě potřeby
+
+Nyní můžete vytvářet zdroje dat souborů během provádění obslužných založených na řetězci:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Příklad:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+Tím se vytvoří nový zdroj dat souborů, který bude dotazovat nakonfigurovaný koncový bod IPFS nebo Arweave grafického uzlu a v případě nenalezení se pokusí o opakování. Když je soubor nalezen, spustí se obslužná zdroje dat souboru.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Gratulujeme, používáte souborové zdroje dat!
+
+#### Nasazení podgrafů
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Omezení
+
+Zpracovatelé a entity zdrojů dat souborů jsou izolovány od ostatních entit podgrafů, což zajišťuje, že jsou při provádění deterministické a nedochází ke kontaminaci zdrojů dat založených na řetězci. Přesněji řečeno:
+
+- Entity vytvořené souborovými zdroji dat jsou neměnné a nelze je aktualizovat
+- Obsluhy zdrojů dat souborů nemohou přistupovat k entita z jiných zdrojů dat souborů
+- K entita přidruženým k datovým zdrojům souborů nelze přistupovat pomocí zpracovatelů založených na řetězci
+
+> Ačkoli by toto omezení nemělo být pro většinu případů použití problematické, pro některé může představovat složitost. Pokud máte problémy s modelováním dat založených na souborech v podgrafu, kontaktujte nás prosím prostřednictvím služby Discord!
+
+Kromě toho není možné vytvářet zdroje dat ze zdroje dat souborů, ať už se jedná o zdroj dat v řetězci nebo jiný zdroj dat souborů. Toto omezení může být v budoucnu zrušeno.
+
+#### Osvědčené postupy
+
+Pokud propojovat metadata NFT s odpovídajícími tokeny, použijte hash IPFS metadat k odkazu na entita Metadata z entity Token. Uložte entitu Metadata s použitím hashe IPFS jako ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> Pracujeme na zlepšení výše uvedeného doporučení, aby dotazy vracely pouze "nejnovější" verzi
+
+#### Známé problémy
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Příklady
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### Odkazy:
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Roubování na existující podgrafy
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Protože se při roubování základní data spíše kopírují než indexují, je mnohem rychlejší dostat podgraf do požadovaného bloku než při indexování od nuly, i když počáteční kopírování dat může u velmi velkých podgrafů trvat i několik hodin. Během inicializace roubovaného podgrafu bude uzel Graf Uzel zaznamenávat informace o typů entit, které již byly zkopírovány.
+
+Štěpovaný podgraf může používat schéma GraphQL, které není totožné se schématem základního podgrafu, ale je s ním pouze kompatibilní. Musí to být platné schéma podgrafu jako takové, ale může se od schématu základního podgrafu odchýlit následujícími způsoby:
+
+- Přidává nebo odebírá typy entit
+- Odstraňuje atributy z typů entit
+- Přidává nulovatelné atributy k typům entit
+- Mění nenulovatelné atributy na nulovatelné atributy
+- Přidává hodnoty do enums
+- Přidává nebo odebírá rozhraní
+- Mění se, pro které typy entit je rozhraní implementováno
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 79dfd4d0fc0ff63b609e19b57312aba27729ad87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:05 -0500
Subject: [PATCH 0762/3820] New translations api.mdx (Czech)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/cs/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/cs/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..4bd1104996f9
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## Reference API
+
+Knihovna `@graphprotocol/graph-ts` poskytuje následující API:
+
+- API `ethereum` pro práci s inteligentními kontrakty Ethereum, událostmi, bloky, transakcemi a hodnotami Ethereum.
+- API `store` pro načítání a ukládání entit z a do úložiště Graf uzel.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- API `ipfs` pro načítání souborů ze IPFS.
+- API `json` pro rozbor dat JSON.
+- API `crypto` pro použití kryptografických funkcí.
+- Nízkoúrovňové primitivy pro překlad mezi různými typovými systémy, jako je Ethereum, JSON, GraphQL a AssemblyScript.
+
+### Verze
+
+`apiVersion` v manifestu podgrafu určuje verzi mapovacího API, kterou pro daný podgraf používá uzel Graf.
+
+| Verze | Poznámky vydání                                                                                                                                                                                                                                          |
+| :---: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+| 0.0.8 | Přidá ověření existence polí ve schéma při ukládání entity.                                                                                                                                                                                              |
+| 0.0.7 | Přidání tříd `TransactionReceipt` a `Log` do typů Ethereum<br />Přidání pole `receipt` do objektu Ethereum událost                                                                                                                                       |
+| 0.0.6 | Přidáno pole `nonce` do objektu Ethereum Transaction<br />Přidáno `baseFeePerGas` do objektu Ethereum bloku                                                                                                                                              |
+| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+| 0.0.4 | Přidání pole `functionSignature` do objektu Ethereum SmartContractCall                                                                                                                                                                                   |
+| 0.0.3 | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+| 0.0.2 | Přidání pole `input` do objektu Ethereum Transackce                                                                                                                                                                                                      |
+
+### Vestavěné typy
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+Následující doplňkové typy poskytuje `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` představuje pole `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Rozebrat `x` na bajty.
+- `fromHexString(hex: string): - Vstupní délka musí být sudá. Předpona `0x\` je nepovinná.
+
+_Type conversions_
+
+- `toHexString(): string` - Převede na hexadecimální řetězec s předponou `0x`.
+- `toString(): string` - čte bajty jako řetězec UTF-8.
+- `toBase58(): string` - Zakóduje bajty do řetězce base58.
+- `toU32(): u32` - Interpretuje bajty jako little-endian `u32`. Hodí v případě přetečení.
+- `toI32(): i32` - Interpretuje pole bajtů jako little-endian `i32`. V případě přetečení hází.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – lze zapsat jako`x == y`.
+- `concat(other: ByteArray) : ByteArray` - vrátí nové `ByteArray` složené z `this` přímo následované `other`
+- `concatI32(other: i32) : ByteArray` - vrátí nové `ByteArray` složené z `this` přímo následované bytovou reprezentací `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+\`BigDecimal se používá k reprezentaci libovolně přesných desetinných míst.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` - vytvoří `BigDecimal` z `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` - vypisuje do desetinného řetězce.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – lze zapsat jako `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – lze zapsat jako `x - y`.
+- `times(y: BigDecimal): BigDecimal` – lze zapsat jako `x * y`.
+- `div(y: BigDecimal): BigDecimal` – lze zapsat jako`x / y`.
+- `equals(y: BigDecimal): bool` – lze zapsat jako`x == y`.
+- `notEqual(y: BigDecimal): bool` – lze zapsat jako\`x !=.
+- `lt(y: BigDecimal): bool` – lze zapsat jako`x < y`.
+- `le(y: BigDecimal): bool` – lze zapsat jako `x <= y`.
+- `gt(y: BigDecimal): bool` – lze zapsat jako `x > y`.
+- `ge(y: BigDecimal): bool` – lze zapsat jako `x >= y`.
+- `neg(): BigDecimal - lze zapsat jako -x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` se používá k reprezentaci velkých celých čísel. Patří sem hodnoty Etherea typu `uint32` až `uint256` a `int64` až `int256`. Vše pod `uint32`, jako například `uint32`, `uint24` nebo `uint8`, je reprezentováno jako `i32`.
+
+Třída `BigInt` má následující API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` - vytvoří `BigInt` z `i32`.
+
+- `BigInt.fromString(s: string): BigInt`- Zpracuje `BigInt` z řetězce.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): - Interpretuje `bytes`jako celé číslo bez znaménka, little-endian. Pokud je váš vstup big-endian, zavolejte nejprve`.reverse()\`.
+
+- `BigInt.fromSignedBytes(x: Bytes): - Interpretuje `bytes`jako celé číslo se znaménkem, little-endian. Pokud je váš vstup big-endian, zavolejte nejprve`.reverse()\`.
+
+  _Type conversions_
+
+- `x.toHex(): string` - změní `BigInt` na řetězec hexadecimálních znaků.
+
+- `x.toString(): string` - změní `BigInt` na řetězec desetinných čísel.
+
+- `x.toI32(): i32` - vrátí `BigInt` jako `i32`; selže, pokud se hodnota nevejde do `i32`. Je dobré nejprve zkontrolovat `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - převede na desetinné číslo bez zlomkové části.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – lze zapsat jako `x + y`.
+- `x.minus(y: BigInt): BigInt` – lze zapsat jako `x - y`.
+- `x.times(y: BigInt): BigInt` – lze zapsat jako `x * y`.
+- `x.div(y: BigInt): BigInt` – lze zapsat jako `x / y`.
+- `x.mod(y: BigInt): BigInt` – lze zapsat jako `x % y`.
+- `x.equals(y: BigInt): bool` – lze zapsat jako `x == y`.
+- `x.notEqual(y: BigInt): bool` –lze zapsat jako `x != y`.
+- `x.lt(y: BigInt): bool` – lze zapsat jako `x < y`.
+- `x.le(y: BigInt): bool` – lze zapsat jako `x <= y`.
+- `x.gt(y: BigInt): bool` – lze zapsat jako   `x > y`.
+- `x.ge(y: BigInt): bool` – lze zapsat jako `x >= y`.
+- `x.neg(): BigInt` – lze zapsat jako `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – dělí desetinným číslem, čímž získá desetinný výsledek.
+- `x.isZero(): bool` – Slouží ke kontrole, zda je číslo rovno nule.
+- `x.isI32(): bool` – Zjistí, zda se číslo vejde do `i32`.
+- `x.abs(): BigInt` – absolutní hodnota.
+- `x.pow(exp: u8): BigInt` – umocňování.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – lze zapsat jako `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – lze zapsat jako `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – lze zapsat jako `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – lze zapsat jako `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` lze použít k ukládání dvojic klíč-hodnota. Viz [tento příklad](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+Třída `TypedMap` má následující API:
+
+- `new TypedMap<K, V>()` – vytvoří prázdnou mapu s klíči typu `K` a hodnotami typu`V`
+- `map.set(key: K, value: V): void` – nastaví hodnotu `key` na `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – vrátí dvojici klíč-hodnota pro `key` nebo `null`, pokud `key` v mapě neexistuje
+- `map.get(key: K): V | null` – vrací hodnotu pro `key` nebo `null`, pokud `key` v mapě neexistuje
+- `map.isSet(key: K): bool` – vrací `true`, pokud `klíč` v mapě existuje, a `false`, pokud ne
+
+#### Bajtů
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` se používá k reprezentaci libovolně dlouhých polí bajtů. Patří sem hodnoty Ethereum typu `bytes`, `bytes32` atd.
+
+Třída `Bytes` rozšiřuje třídu AssemblyScript [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) a podporuje všechny funkce třídy `Uint8Array` a navíc následující nové metody:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Převede řetězec `hex`, který se musí skládat ze sudého počtu hexadecimálních číslic, na `ByteArray`. Řetězec `hex` může volitelně začínat znakem `0x`
+- `fromI32(i: i32) : Bytes` - Převod `i` na pole bajtů
+
+_Type conversions_
+
+- `b.toHex()` – vrací hexadecimální řetězec reprezentující bajty v poli
+- `b.toString()` – převede bajty v poli na řetězec unicode znaků
+- `b.toBase58()` –změní hodnotu Ethereum Bytes na kódování base58 (používá se pro IPFS hashe)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - "Vrátit nový `Bytes` skládající se z `this`, který je přímo následován `other`."
+- `b.concatI32(other: i32) : ByteArray` - vrátí nový `Bytes` složený z `this` přímo následovaný bajtovou reprezentací `other`
+
+#### Adresa
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` rozšiřuje `Bytes` pro reprezentaci hodnot `adresa` Ethereum.
+
+Přidává následující metodu nad API `Bytes`:
+
+- `Address.fromString(s: string): Address` - vytvoří `Address` z hexadecimálního řetězce
+- `Address.fromBytes(b: Bytes): Adresa` - vytvoří `Adresu` z `b`, která musí být dlouhá přesně 20 bajtů. Předání hodnoty s menším nebo větším počtem bajtů bude mít za následek chybu
+
+### API ukládat
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+API `store` umožňuje načítat, ukládat a odebírat entity z a do úložiště Graf uzel.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Vytváření entity
+
+Následuje běžný vzor pro vytváření entity z událostí Ethereum.
+
+```typescript
+// Importovat třídu události Transfer vygenerovanou z ERC20 ABI
+import { Transfer as TransferEvent } z '../generated/ERC20/ERC20'
+
+// Importovat typ entity Transfer vygenerovaný ze schématu GraphQL
+import { Transfer } z '../generated/schema'
+
+// Obsluha události Transfer
+export function handleTransfer(event: TransferEvent): void {
+  // Vytvoří entitu Transfer s použitím hashe transakce jako ID entity
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Nastavte vlastnosti entity pomocí parametrů události
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Uložení entity do úložiště
+  transfer.save()
+}
+```
+
+Pokud se při zpracování řetězce vyskytne událost `Transfer`, je předána obsluze události `handleTransfer` pomocí vygenerovaného typu `Transfer` (zde alias `TransferEvent`, aby nedošlo ke konfliktu názvů s typem entity). Tento typ umožňuje přístup k datům, jako je nadřazená transakce události a její parametr.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Načítání entity z úložiště
+
+Pokud již entita existuje, lze ji z úložiště načíst pomocí následujících příkazů:
+
+```typescript
+let id = event.transaction.hash // nebo jakkoli je ID konstruováno
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Použijte entitu Transfer jako dříve
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Vyhledávání entit vytvořených v rámci bloku
+
+Od verzí `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 a `@graphprotocol/graph-cli` v0.49.0 je metoda `loadInBlock` dostupná pro všechny typy entit.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Poznámka: Pokud v daném bloku není vytvořena žádná entita, vrátí `loadInBlock` hodnotu `null`, i když v úložišti existuje entita s daným ID.
+
+#### Vyhledávání odvozených entity
+
+Od verzí `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 a `@graphprotocol/graph-cli` v0.51.0 je k dispozici metoda `loadRelated`.
+
+To umožňuje načítání odvozených polí entityh z obsluhy události. Například při následujícím schématu:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+Následující kód načte entitu `Token`, ze které byla odvozena entita `Holder`:
+
+```typescript
+let holder = Holder.load('test-id')
+// Načtení entit tokenů přidružených k danému držiteli
+let tokens = holder.tokens.load()
+```
+
+#### Aktualizace stávajících entity
+
+Existují dva způsoby, jak aktualizovat existující entity:
+
+1. Načtěte entitu např. pomocí `Transfer.load(id)`, nastavte vlastnosti entity a poté ji `.save()` uložte zpět do úložiště.
+2. Jednoduše vytvořte entitu např. pomocí `new Transfer(id)`, nastavte vlastnosti entity a poté ji `.save()` uložte do úložiště. Pokud entita již existuje, změny se do ní sloučí.
+
+Změna vlastností je ve většině případů jednoduchá díky generovaným nastavovačům vlastností:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+Vlastnosti lze také zrušit jedním z následujících dvou příkazů:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+To funguje pouze u nepovinných vlastností, tj. vlastností, které jsou v jazyce GraphQL deklarovány bez znaku `!`. Dva příklady: `owner: Bytes` nebo `amount: BigInt`.
+
+Aktualizace vlastností pole je trochu složitější, protože získání pole z entity vytvoří kopii tohoto pole. To znamená, že vlastnosti pole je třeba po změně pole znovu explicitně nastavit. Následující příklad předpokládá, že `entita` má `čísla: [BigInt!]!` pole.
+
+```typescript
+// Tohle nebude fungovat
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// Toto bude fungovat
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Odstranění entit z úložiště
+
+V současné době není možné odstranit entitu prostřednictvím generovaných typů. Místo toho je pro odstranění entity nutné předat název typu entity a ID entity příkazu `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+Ethereum API poskytuje přístup k inteligentním smlouvám, veřejným stavovým proměnným, funkcím smluv, událostem, transakcím, blokům a kódování/dekódování dat Etherea.
+
+#### Podpora typů Ethereum
+
+Stejně jako u entit generuje `graph codegen` třídy pro všechny inteligentní smlouvy a události používané v podgrafu. Za tímto účelem musí být ABI kontraktu součástí zdroje dat v manifestu podgrafu. Obvykle jsou soubory ABI uloženy ve složce `abis/`.
+
+Ve vygenerovaných třídách probíhají konverze mezi typy Ethereum [built-in-types](#built-in-types) v pozadí, takže se o ně autoři podgraf nemusí starat.
+
+To ilustruje následující příklad. Je dáno schéma podgrafu, jako je
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+a podpis události `Transfer(address,address,uint256)` na platformě Ethereum jsou hodnoty `from`, `to` a `amount` typu `adresa`, `adresa` a `uint256` převedeny na `Address` a `BigInt`, což umožňuje jejich předání do vlastností `Bytes!` a `BigInt!` entity `Transfer`:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Události a bloková/transakční data
+
+Události Ethereum předávané obsluze událostí, jako je událost `Transfer` v předchozích příkladech, poskytují přístup nejen k parametrům události, ale také k nadřazené transakci a bloku, jehož jsou součástí. Z instancí `event` (tyto třídy jsou součástí modulu `ethereum` v `graph-ts`) lze získat následující údaje:
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Přístup ke stavu inteligentní smlouvy
+
+Kód vygenerovaný nástrojem `graph codegen` obsahuje také třídy pro inteligentní smlouvy používané v podgrafu. Ty lze použít k přístupu k veřejným stavovým proměnným a k volání funkcí kontraktu v aktuálním bloku.
+
+Běžným vzorem je přístup ke smlouvě, ze které událost pochází. Toho lze dosáhnout pomocí následujícího kódu:
+
+```typescript
+// Import vygenerované třídy smlouvy a vygenerované třídy události Transfer
+import { ERC20Contract, Transfer as TransferEvent } z '../generated/ERC20Contract/ERC20Contract'
+// Importovat vygenerovanou třídu entit
+import { Transfer } z "../generated/schema
+
+export function handleTransfer(event: TransferEvent) {
+  // Vázat smlouvu na adresu, která událost vyslala
+  let contract = ERC20Contract.bind(event.address)
+
+  // Přístup ke stavovým proměnným a funkcím jejich voláním
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` je zde aliasován na `TransferEvent`, aby nedošlo ke konfliktu názvů s typ entity
+
+Pokud má smlouva `ERC20Contract` na platformě Ethereum veřejnou funkci pouze pro čtení s názvem `symbol`, lze ji volat pomocí `.symbol()`. Pro veřejné stavové proměnné se automaticky vytvoří metoda se stejným názvem.
+
+Jakákoli jiná smlouva, která je součástí podgrafu, může být importována z vygenerovaného kódu a může být svázána s platnou adresou.
+
+#### Zpracování vrácených volání
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Kódování/dekódování ABI
+
+Data lze kódovat a dekódovat podle formátu kódování ABI Ethereum pomocí funkcí `encode` a `decode` v modulu `ethereum`.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+Více informací:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+`log` API obsahuje následující funkce:
+
+- `log.debug(fmt: string, args: Array<string>): void` - zaznamená ladicí zprávu.
+- `log.info(fmt: string, args: Array<string>): void` - zaznamená informační zprávu.
+- `log.warning(fmt: string, args: Array<string>): void` - zaznamená varování.
+- `log.error(fmt: string, args: Array<string>): void` - zaznamená chybovou zprávu.
+- `log.critical(fmt: string, args: Array<string>): void` - zaznamená kritickou zprávu _a_ ukončí podgraf.
+
+`log` API přebírá formátovací řetězec a pole řetězcových hodnot. Poté nahradí zástupné symboly řetězcovými hodnotami z pole. První zástupný symbol „{}“ bude nahrazen první hodnotou v poli, druhý zástupný symbol „{}“ bude nahrazen druhou hodnotou a tak dále.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Zaznamenávání jedné nebo více hodnot
+
+##### Zaznamenávání jedné hodnoty
+
+V níže uvedeném příkladu je řetězcová hodnota "A" předána do pole a stane se z ní `['A']`, než je zapsána:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Protokolování jedné položky z existujícího pole
+
+V příkladu níže je zaznamenána pouze první hodnota pole argumentů, přestože pole obsahuje tři hodnoty.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Protokolování více záznamů z existujícího pole
+
+Každá položka v poli argumentů vyžaduje vlastní zástupný znak `{}` v řetězci zprávy protokolu. Níže uvedený příklad obsahuje tři zástupné zna. Z tohoto důvodu jsou zaznamenány všechny tři hodnoty v poli `myArray`.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Protokolování konkrétní položky z existujícího pole
+
+Chcete-li zobrazit konkrétní hodnotu v poli, je třeba zadat indexovanou hodnotu.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Zaznamenávání informací o událostech
+
+Níže uvedený příklad zaznamenává číslo bloku, hash bloku a hash transakce z události:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Při zadání hashe nebo cesty IPFS se čtení souboru ze systému IPFS provádí následujícím způsobem:
+
+```typescript
+// Vložte to do obsluhy události v mapování
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Cesty jako `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// které obsahují soubory v adresářích, jsou také podporovány
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(cesta)
+```
+
+**Poznámka:** `ipfs.cat` není v současné době deterministický. Pokud se soubor nepodaří načíst přes síť IPFS před vypršením požadavku, vrátí se `null`. Z tohoto důvodu se vždy vyplatí zkontrolovat výsledek na `null`.
+
+Pomocí nástroje `ipfs.map` je také možné zpracovávat větší soubory proudovým způsobem. Funkce očekává hash nebo cestu k souboru IPFS, název zpětného volání a příznaky pro úpravu chování:
+
+```typescript
+import { JSONValue, Value } z '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // Podrobnosti o zpracování viz dokumentace k JSONValue
+  // s hodnotami JSON
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacky mohou také vytvářet entity
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Nastavit rodiče na "parentId"
+  newitem.save()
+}
+
+// Toto vložte do obsluhy události v mapování
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Případně použijte `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+V současné době je podporován pouze příznak `json`, který musí být předán souboru `ipfs.map`. S příznakem `json` se soubor IPFS musí skládat z řady hodnot JSON, jedna hodnota na řádek. Volání příkazu `ipfs.map` přečte každý řádek souboru, deserializuje jej do hodnoty `JSONValue` a pro každou z nich zavolá zpětné volání. Zpětné volání pak může použít operace entit k uložení dat z `JSONValue`. Změny entit se uloží až po úspěšném ukončení obsluhy, která volala `ipfs.map`; do té doby se uchovávají v paměti, a velikost souboru, který může `ipfs.map` zpracovat, je proto omezená.
+
+Při úspěchu vrátí `ipfs.map` hodnotu `void`. Pokud vyvolání zpětného volání způsobí chybu, obslužná rutina, která vyvolala `ipfs.map`, se přeruší a podgraf se označí jako neúspěšný.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+API `crypto` zpřístupňuje kryptografické funkce pro použití v mapování. Nyní je k dispozici pouze jedna:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+Data JSON lze analyzovat pomocí API `json`:
+
+- `json.fromBytes(data: Bytes): JSONValue` - analyzuje data JSON z pole `Bytes` interpretovaného jako platná posloupnost UTF-8
+- `json.try_fromBytes(data: Bytes): Výsledek<JSONValue, boolean>` - bezpečná verze `json.fromBytes`, vrací chybovou variantu, pokud se parsování nezdařilo
+- `json.fromString(data: string): JSONValue` - analyzuje data JSON z platného UTF-8 `Řetězce`
+- `json.try_fromString(data: string): Výsledek<JSONValue, boolean>` - bezpečná verze `json.fromString`, vrací chybovou variantu, pokud se parsování nezdařilo
+
+Třída `JSONValue` poskytuje způsob, jak vytáhnout hodnoty z libovolného dokumentu JSON. Protože hodnoty JSON mohou být logické, číselné, pole a další, je `JSONValue` vybavena vlastností `kind` pro kontrolu typu hodnoty:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+Kromě toho existuje metoda pro kontrolu, zda je hodnota `null`:
+
+- `value.isNull(): boolean`
+
+Pokud je typ hodnoty jistý, lze ji převést na [vestavěný typ](#built-in-types) pomocí jedné z následujících metod:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (a poté převést `JSONValue` pomocí jedné z 5 výše uvedených metod)
+
+### Převody typů Reference
+
+| Zdroj(e)               | Destinace              | Funkce převodu               |
+| ---------------------- | ---------------------- | ---------------------------- |
+| Address                | Bytes                  | none                         |
+| Address                | String                 | s.toHexString()              |
+| BigDecimal             | String                 | s.toString()                 |
+| BigInt                 | BigDecimal             | s.toBigDecimal()             |
+| BigInt                 | String (hexadecimální) | s.toHexString() or s.toHex() |
+| BigInt                 | String (unicode)       | s.toString()                 |
+| BigInt                 | i32                    | s.toI32()                    |
+| Boolean                | Boolean                | none                         |
+| Bytes (signed)         | BigInt                 | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)       | BigInt                 | BigInt.fromUnsignedBytes(s)  |
+| Bytes                  | String (hexadecimální) | s.toHexString() or s.toHex() |
+| Bytes                  | String (unicode)       | s.toString()                 |
+| Bytes                  | String (base58)        | s.toBase58()                 |
+| Bytes                  | i32                    | s.toI32()                    |
+| Bytes                  | u32                    | s.toU32()                    |
+| Bytes                  | JSON                   | json.fromBytes(s)            |
+| int8                   | i32                    | none                         |
+| int32                  | i32                    | none                         |
+| int32                  | BigInt                 | BigInt.fromI32(s)            |
+| uint24                 | i32                    | none                         |
+| int64 - int256         | BigInt                 | none                         |
+| uint32 - uint256       | BigInt                 | none                         |
+| JSON                   | boolean                | s.toBool()                   |
+| JSON                   | i64                    | s.toI64()                    |
+| JSON                   | u64                    | s.toU64()                    |
+| JSON                   | f64                    | s.toF64()                    |
+| JSON                   | BigInt                 | s.toBigInt()                 |
+| JSON                   | string                 | s.toString()                 |
+| JSON                   | Array                  | s.toArray()                  |
+| JSON                   | Object                 | s.toObject()                 |
+| String                 | Address                | Address.fromString(s)        |
+| Bytes                  | Address                | Address.fromBytes(s)         |
+| String                 | BigInt                 | BigInt.fromString(s)         |
+| String                 | BigDecimal             | BigDecimal.fromString(s)     |
+| String (hexadecimální) | Bytes                  | ByteArray.fromHexString(s)   |
+| String (UTF-8)         | Bytes                  | ByteArray.fromUTF8(s)        |
+
+### Metadata zdroje dat
+
+Adresu smlouvy, síť a kontext zdroje dat, který obslužnou rutinu vyvolal, můžete zkontrolovat prostřednictvím jmenného prostoru `dataSource`:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entity a DataSourceContext
+
+Základní třída `Entity` a podřízená třída `DataSourceContext` mají pomocníky pro dynamické nastavování a získávání polí:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext v manifestu
+
+Sekce `context` v rámci `dataSources` umožňuje definovat páry klíč-hodnota, které jsou přístupné v rámci mapování podgrafů. Dostupné typy jsou `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List` a `BigInt`.
+
+Zde je příklad YAML ilustrující použití různých typů v sekci `context`:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Určuje Boolean hodnotu (`true` nebo `false`).
+- `String`: Určuje hodnotu řetězce.
+- `Int`: Určuje 32bitové celé číslo.
+- `Int8`: Určuje 8bitové celé číslo.
+- `BigDecimal`: Určuje desetinné číslo. Musí být uvedeno v uvozovkách.
+- `Bytes`: Určuje hexadecimální řetězec.
+- `Seznam`: Určuje seznam položek. U každé položky je třeba zadat její typ a data.
+- `BigInt`: Určuje velkou celočíselnou hodnotu. Kvůli velké velikosti musí být uvedena v uvozovkách.
+
+Tento kontext je pak přístupný v souborech mapování podgrafů, což umožňuje vytvářet dynamičtější a konfigurovatelnější podgrafy.

From c4f93c7ad15df52d9543ef21e59781d842a01259 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:06 -0500
Subject: [PATCH 0763/3820] New translations common-issues.mdx (Czech)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/cs/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/cs/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..79ec3df1a827
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Běžné problémy se AssemblyScript
+---
+
+Při vývoji podgrafů se často vyskytují určité problémy [AssemblyScript](https://github.com/AssemblyScript/assemblyscript). Jejich obtížnost při ladění je různá, nicméně jejich znalost může pomoci. Následuje neúplný seznam těchto problémů:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Rozsah se nedědí do [uzavíracích funkcí](https://www.assemblyscript.org/status.html#on-closures), tj. proměnné deklarované mimo uzavírací funkce nelze použít. Vysvětlení v [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 62d570d0cb35aa643114f03a0a3043692289d628 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:07 -0500
Subject: [PATCH 0764/3820] New translations unit-testing-framework.mdx (Czech)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/cs/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/cs/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..546f81543147
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Rámec pro testování jednotek
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Začínáme
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew instalovat postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+Matchstick můžete na WSL používat jak pomocí přístupu Docker, tak pomocí binárního přístupu. Protože WSL může být trochu složitější, přinášíme několik tipů pro případ, že narazíte na problémy, jako např
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+nebo
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### Možnosti CLI
+
+Tím se spustí všechny testy ve složce testů:
+
+```sh
+test graf
+```
+
+Spustí se test s názvem gravity.test.ts a/nebo všechny testy uvnitř složky s názvem gravity:
+
+```sh
+testovací gravitace graf
+```
+
+Spustí se pouze tento konkrétní testovací soubor:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Konfigurace
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Ukázkový podgraf
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Videonávody
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Příklad:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Příklad:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+nebo
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Příklady:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Příklad:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Příklady:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Tvrdí
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Napsat jednotkový test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Předpokládejme, že máme následující obslužnou funkci (spolu se dvěma pomocnými funkcemi, které nám usnadní život):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+Nejprve musíme v projektu vytvořit testovací soubor. Toto je příklad, jak by to mohlo vypadat:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- Nastavujeme počáteční stav a přidáváme jednu vlastní entita Gravatar;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- Ujišťujeme se o stavu obchodu. Jak to funguje? - Předáváme jedinečnou kombinaci typu Entity a id. Pak zkontrolujeme konkrétní pole této entity a potvrdíme, že má hodnotu, kterou očekáváme. Toto provádíme jak pro počáteční Entitu Gravatar, kterou jsme přidali do úložiště, tak pro dvě entity Gravatar, které se přidají při volání funkce obsluhy;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+A je to tady - vytvořili jsme první test! 👏
+
+Pro spuštění našich testů nyní stačí v kořenové složce podgrafu spustit následující příkaz:
+
+`graph test Gravity`
+
+A pokud vše proběhne v pořádku, měli byste se setkat s následujícím:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Běžné testovací scénáře
+
+### Hydratace obchodu s určitým stavem
+
+Uživatelé mohou hydratovat sklad známou sadou entit. Zde je příklad inicializace úložiště pomocí entity Gravatar:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Volání funkce mapování pomocí události
+
+Uživatel může vytvořit vlastní událost a předat ji funkci mapování, která je svázána s úložištěm:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Volání všech mapování pomocí příslušenství událostí
+
+Uživatelé mohou mapování vyvolat pomocí testovacích přípravků.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Zesměšňování smluvních volání
+
+Uživatelé mohou zesměšňovat smluvní hovory:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+Jak bylo ukázáno, aby bylo možné zesměšnit volání smlouvy a hardcore návratovou hodnotu, musí uživatel zadat adresu smlouvy, název funkce, signaturu funkce, pole argumentů a samozřejmě návratovou hodnotu.
+
+Uživatelé mohou také zesměšňovat vracení funkcí:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Zesměšňování souborů IPFS (od matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Zjištění stavu skladu
+
+Uživatelé mohou potvrdit konečný (nebo střední) stav úložiště prostřednictvím potvrzujících entit. K tomu musí uživatel zadat typ entity, konkrétní ID entity, název pole této entity a očekávanou hodnotu pole. Zde je rychlý příklad:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interakce s metadaty událostí
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Potvrzení rovnosti proměnných
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Uživatelé mohou tvrdit, že entita v úložišti neexistuje. Funkce přebírá typ entity a id. Pokud se entita v úložišti skutečně nachází, test selže s příslušným chybovým hlášením. Zde je rychlý příklad použití této funkce:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+Pomocí této pomocné funkce můžete vypsat celý obchod na konzolu:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Očekávané selhání
+
+Uživatelé mohou očekávat selhání test pomocí příznaku shouldFail ve funkcích test():
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+Pokud je test označen hodnotou shouldFail = true, ale NESPADNE, zobrazí se to v protokolech jako chyba a blok test selže. Pokud je také označen shouldFail = false (výchozí stav), dojde k pádu spouštěče test.
+
+### Protokolování
+
+Vlastní protokoly v jednotkových test jsou úplně stejné jako protokoly v mapování. Rozdíl je v tom, že objekt logu je třeba importovat z matchstick-as, nikoli z graph-ts. Zde je jednoduchý příklad se všemi nekritickými typy log:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Uživatelé mohou také simulovat kritickou poruchu, například takto:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Zaznamenáním kritických chyb se provádění testů zastaví a vše se pokazí. Koneckonců - chceme mít jistotu, že váš kód nemá při nasazení kritické log, a pokud by se tak stalo, měli byste si toho okamžitě všimnout.
+
+### Testování odvozených polí
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testování dynamických zdrojů dat
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Příklad níže:
+
+Nejprve máme následující obsluhu události (která byla záměrně přepracována za účelem předvedení posměchu datovému zdroji):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+A pak máme test, který používá jednu z metod v oboru názvů dataSourceMock k nastavení nové návratové hodnoty pro všechny funkce dataSource:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Všimněte si, že na konci je volána funkce dataSourceMock.resetValues(). To proto, že hodnoty se při změně pamatují a je třeba je resetovat, pokud se chcete vrátit k výchozím hodnotám.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Pokrytí test
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Požadavky
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Exportování zpracovatelů
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Použití
+
+Jakmile je vše nastaveno, spusťte nástroj pro pokrytí test:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+Tím se spustí nástroj pro pokrytí a v terminálu by se mělo zobrazit něco takového:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Doba trvání test ve výstupu protokolu
+
+Výstup protokolu obsahuje dobu trvání test. Zde je příklad:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Běžné chyby překladače
+
+> Kritické: Nelze vytvořit WasmInstance z platného modulu s kontextem: neznámý import: wasi_snapshot_preview1::fd_write nebyl definován
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Další zdroje
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Zpětná vazba
+
+Pokud máte nějaké dotazy, zpětnou vazbu, požadavky na funkce nebo se jen chcete ozvat, nejlépe na Graf Discord, kde máme pro Matchstick vyhrazený kanál s názvem 🔥| unit-testing.

From 863d1be037885fb962724616fba9aa8d0250c34a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:08 -0500
Subject: [PATCH 0765/3820] New translations transferring-a-subgraph.mdx
 (Czech)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/cs/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/cs/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 9255f62c5b0f08b53bc5d0c8bdc038557f3195d2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:09 -0500
Subject: [PATCH 0766/3820] New translations graphql-api.mdx (Czech)

---
 .../cs/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/cs/subgraphs/querying/graphql-api.mdx b/website/pages/cs/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..a02cf74a0854
--- /dev/null
+++ b/website/pages/cs/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Příklady
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Třídění
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Příklad
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Příklad vnořeného třídění entit
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Stránkování
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Dotaz na prvních 10 tokenů:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtrování
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Příklad filtrování rozsahu
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Příklad pro filtrování bloků
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+To může být užitečné, pokud chcete načíst pouze entity, které se změnily například od posledního dotazování. Nebo může být užitečná pro zkoumání nebo ladění změn entit v podgrafu (v kombinaci s blokovým filtrem můžete izolovat pouze entity, které se změnily v určitém bloku).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Příklad vnořeného filtrování entit
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+To může být užitečné, pokud chcete načíst pouze entity, jejichž entity podřízené úrovně splňují zadané podmínky.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logické operátory
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### Všechny filtry
+
+Úplný seznam přípon parametrů:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Dotazy na cestování čase
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Příklad
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Příklad
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltextové Vyhledávání dotazy
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Operátory fulltextového vyhledávání:
+
+| Symbol | Operátor    | Popis                                                                                                                         |
+| ------ | ----------- | ----------------------------------------------------------------------------------------------------------------------------- |
+| `&`    | `And`       | Pro kombinaci více vyhledávacích výrazů do filtru pro entity, které obsahují všechny zadané výrazy                            |
+| |      | `Or`        | Dotazy s více hledanými výrazy oddělenými operátorem nebo vrátí všechny entity, které odpovídají některému z uvedených výrazů |
+| `<->`  | `Follow by` | Zadejte vzdálenost mezi dvěma slovy.                                                                                          |
+| `:*`   | `Prefix`    | Pomocí předponového výrazu vyhledejte slova, jejichž předpona se shoduje (vyžadovány 2 znaky)                                 |
+
+#### Příklady
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Kombinací fulltextových operátorů můžete vytvářet složitější filtry. S operátorem pretextového vyhledávání v kombinaci s operátorem follow by bude tento příklad dotazu odpovídat všem entitá blog se slovy začínajícími na "lou" a následovanými slovem "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validace
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Metadata podgrafů
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+Pokud je uveden blok, metadata se vztahují k tomuto bloku, pokud ne, použije se poslední indexovaný blok. Pokud je blok uveden, musí se nacházet za počátečním blokem podgrafu a musí být menší nebo roven poslednímu Indevovaný bloku.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: hash bloku
+- číslo: číslo bloku
+- timestamp: časové razítko bloku, pokud je k dispozici (v současné době je k dispozici pouze pro podgrafy indexující sítě EVM)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 25c76ee0fa32b1457d13795c0688e2147f246169 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:10 -0500
Subject: [PATCH 0767/3820] New translations python.mdx (Czech)

---
 .../pages/cs/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/querying/python.mdx

diff --git a/website/pages/cs/subgraphs/querying/python.mdx b/website/pages/cs/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..a08bc09c97c3
--- /dev/null
+++ b/website/pages/cs/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds je intuitivní knihovna Pythonu pro dotazování na podgrafy, vytvořená [Playgrounds](https://playgrounds.network/). Umožňuje přímo připojit data subgrafů k datovému prostředí Pythonu, což vám umožní používat knihovny jako [pandas](https://pandas.pydata.org/) k provádění analýzy dat!
+
+Subgrounds nabízí jednoduché Pythonic API pro vytváření dotazů GraphQL, automatizuje zdlouhavé pracovní postupy, jako je stránkování, a umožňuje pokročilým uživatelům řízené transformace schémat.
+
+## Začínáme
+
+Subgrounds vyžaduje Python 3.10 nebo vyšší a je k dispozici na [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Po instalaci můžete vyzkoušet podklady pomocí následujícího dotazu. Následující příklad uchopí podgraf pro protokol Aave v2 a dotazuje se na 5 největších trhů seřazených podle TVL (Total Value Locked), vybere jejich název a jejich TVL (v USD) a vrátí data jako pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Načtení podgrafu
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Sestavte dotaz
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection="desc",
+    first=5,
+)
+# Vrátit dotaz do datového rámce
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Dokumentace
+
+Subgrounds je vytvořen a spravován týmem [Playgrounds](https://playgrounds.network/) a je k dispozici na stránce [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Vzhledem k tomu, že subgrounds má rozsáhlou sadu funkcí, které je třeba prozkoumat, uvádíme několik užitečných výchozích bodů:
+
+- [Začínáme s dotazováním](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - Dobrý první krok k tomu, jak vytvářet dotazy s subgrounds.
+- [Budování syntetických polí](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - Jemný úvod do definování syntetických polí, která transformují data definovaná ze schématu.
+- [Souběžné dotazy](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Zjistěte, jak zvýšit úroveň dotazů jejich paralelizací.
+- [Export dat do CSV](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 565bbe03f16e2dc419c44287880082bf644f03b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:11 -0500
Subject: [PATCH 0768/3820] New translations triggers.mdx (Czech)

---
 website/pages/cs/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/cs/substreams/sps/triggers.mdx

diff --git a/website/pages/cs/substreams/sps/triggers.mdx b/website/pages/cs/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/cs/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 10575e37e64b5ebc86d5e52fedfae2a4ac2d4d41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:13 -0500
Subject: [PATCH 0769/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/de/indexing/overview.mdx

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
new file mode 100644
index 000000000000..5898077a6936
--- /dev/null
+++ b/website/pages/de/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+
+GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.
+
+Indexers select subgraphs to index based on the subgraph’s curation signal, where Curators stake GRT in order to indicate which subgraphs are high-quality and should be prioritized. Consumers (eg. applications) can also set parameters for which Indexers process queries for their subgraphs and set preferences for query fee pricing.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### What is the minimum stake required to be an Indexer on the network?
+
+The minimum stake for an Indexer is currently set to 100K GRT.
+
+### What are the revenue streams for an Indexer?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### How are indexing rewards distributed?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### What is a proof of indexing (POI)?
+
+POIs are used in the network to verify that an Indexer is indexing the subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific subgraph deployment up to and including that block.
+
+### When are indexing rewards distributed?
+
+Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).
+
+### Can pending indexing rewards be monitored?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Many of the community-made dashboards include pending rewards values and they can be easily checked manually by following these steps:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### What are disputes and where can I view them?
+
+Indexer's queries and allocations can both be disputed on The Graph during the dispute period. The dispute period varies, depending on the type of dispute. Queries/attestations have 7 epochs dispute window, whereas allocations have 56 epochs. After these periods pass, disputes cannot be opened against either of allocations or queries. When a dispute is opened, a deposit of a minimum of 10,000 GRT is required by the Fishermen, which will be locked until the dispute is finalized and a resolution has been given. Fisherman are any network participants that open disputes.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- If the dispute is rejected, the GRT deposited by the Fishermen will be burned, and the disputed Indexer will not be slashed.
+- If the dispute is settled as a draw, the Fishermen's deposit will be returned, and the disputed Indexer will not be slashed.
+- If the dispute is accepted, the GRT deposited by the Fishermen will be returned, the disputed Indexer will be slashed and the Fishermen will earn 50% of the slashed GRT.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### What are query fee rebates and when are they distributed?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+
+### What is query fee cut and indexing reward cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### How do Indexers know which subgraphs to index?
+
+Indexers may differentiate themselves by applying advanced techniques for making subgraph indexing decisions but to give a general idea we'll discuss several key metrics used to evaluate subgraphs in the network:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### What are the hardware requirements?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Konfiguration | Postgres<br />(CPUs) | Postgres<br />(Speicher in GB) | Postgres<br />(Festplatte in TB) | VMs<br />(CPUs) | VMs<br />(Speicher in GB) |
+| ------------- | :------------------: | :----------------------------: | :------------------------------: | :-------------: | :-----------------------: |
+| Klein         |           4          |                8               |                 1                |        4        |             16            |
+| Standard      |           8          |               30               |                 1                |        12       |             48            |
+| Mittel        |          16          |               64               |                 2                |        32       |             64            |
+| Groß          |          72          |               468              |                3.5               |        48       |            184            |
+
+### What are some basic security precautions an Indexer should take?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastruktur
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Note: To support agile scaling, it is recommended that query and indexing concerns are separated between different sets of nodes: query nodes and index nodes.
+
+### Ports overview
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Der Graph-Knoten
+
+| Port | Zweck                                           | Routen                                         | CLI-Argument       | Umgebungsvariable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | ----------------- |
+| 8000 | GraphQL HTTP-Server<br />(für Subgraf-Abfragen) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                 |
+| 8001 | GraphQL WS<br />(für Subgraf-Abonnements)       | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                 |
+| 8020 | JSON-RPC<br />(zum Verwalten von Deployments)   | /                                              | \--admin-port      | -                 |
+| 8030 | Subgraf-Indizierungsstatus-API                  | /graphql                                       | \--index-node-port | -                 |
+| 8040 | Prometheus-Metriken                             | /metrics                                       | \--metrics-port    | -                 |
+
+#### Indexer Service
+
+| Port | Zweck                                                            | Routen                                                      | CLI-Argument    | Umgebungsvariable      |
+| ---- | ---------------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL-HTTP-Server<br />(für kostenpflichtige Subgraf-Abfragen) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus-Metriken                                              | /metrics                                                    | \--metrics-port | -                      |
+
+#### Indexer Agent
+
+| Port | Purpose                 | Routen | CLI Argument               | Environment Variable                    |
+| ---- | ----------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | Indexer-Verwaltungs-API | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Setup server infrastructure using Terraform on Google Cloud
+
+> Note: Indexers can alternatively use AWS, Microsoft Azure, or Alibaba.
+
+#### Installieren Sie die Voraussetzungen
+
+- Google Cloud-SDK
+- Kubectl-Befehlszeilentool
+- Terraform
+
+#### Create a Google Cloud Project
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Authentifizieren Sie sich bei Google Cloud und erstellen Sie ein neues Projekt.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Aktivieren Sie die Abrechnung für das neue Projekt auf der Abrechnungsseite der Google Cloud Console.
+
+- Erstellen Sie eine Google Cloud-Konfiguration.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Aktivieren Sie die erforderlichen Google Cloud-APIs.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Create a service account.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Enable peering between database and Kubernetes cluster that will be created in the next step.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer Networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Create minimal terraform configuration file (update as needed).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Verwenden Sie Terraform zum Erstellen einer Infrastruktur
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Run the following commands to create the infrastructure.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Creating the Kubernetes components for the Indexer
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Der Graph-Knoten
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Einstieg in den Sourcecode
+
+#### Installieren Sie die Voraussetzungen
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Konfiguration
+
+1. Starten Sie einen PostgreSQL-Datenbankserver
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Nachdem alle Abhängigkeiten eingerichtet sind, starten Sie den Graph-Knoten:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Erste Schritte mit Docker
+
+#### Prerequisites
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Konfiguration
+
+1. Klonen Sie den Graph-Knoten und navigieren Sie zum Docker-Verzeichnis:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Starten Sie einen lokalen Graph-Knoten, der sich mit Ihrem Ethereum-Endpunkt verbindet:
+
+```sh
+docker-compose up
+```
+
+### Indexer-Komponenten
+
+To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Getting started
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### From NPM packages
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### From source
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Using docker
+
+- Pull images from the registry
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Or build images locally from source
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Run the components
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Using K8s and Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Usage
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexer-Agent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer-Service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer-CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Indexer management using Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Usage
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Indexing rules
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Data model:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Example usage of indexing rule:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Action added to the queue by the 3rd party optimizer tool or indexer-cli user
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken.
+
+Data model:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Example usage from source:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Note that supported action types for allocation management have different input requirements:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - required action params:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - required action params:
+    - allocationID
+    - deploymentID
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - required action params:
+    - allocationID
+    - deploymentID
+    - amount
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+#### Kostenmodelle
+
+Cost models provide dynamic pricing for queries based on market and query attributes. The Indexer Service shares a cost model with the gateways for each subgraph for which they intend to respond to queries. The gateways, in turn, use the cost model to make Indexer selection decisions per query and to negotiate payment with chosen Indexers.
+
+#### Agora
+
+The Agora language provides a flexible format for declaring cost models for queries. An Agora price model is a sequence of statements that execute in order for each top-level query in a GraphQL query. For each top-level query, the first statement which matches it determines the price for that query.
+
+A statement is comprised of a predicate, which is used for matching GraphQL queries, and a cost expression which when evaluated outputs a cost in decimal GRT. Values in the named argument position of a query may be captured in the predicate and used in the expression. Globals may also be set and substituted in for placeholders in an expression.
+
+Example cost model:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Example query costing using the above model:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Anwendung des Kostenmodells
+
+Cost models are applied via the Indexer CLI, which passes them to the Indexer Management API of the Indexer agent for storing in the database. The Indexer Service will then pick them up and serve the cost models to gateways whenever they ask for them.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interaktion mit dem Netzwerk
+
+### Stake in the protocol
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Approve tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Stake tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### The life of an allocation
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From fccca9458c6677ddfa36b6f30552e3d1955401d2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:14 -0500
Subject: [PATCH 0770/3820] New translations tap.mdx (German)

---
 website/pages/de/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/de/indexing/tap.mdx

diff --git a/website/pages/de/indexing/tap.mdx b/website/pages/de/indexing/tap.mdx
new file mode 100644
index 000000000000..d2d87874bdbf
--- /dev/null
+++ b/website/pages/de/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Overview
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Besonderheiten
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notes:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From e56d7f59f24f4bbbd522b1fbed6716b402fb8ed4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:15 -0500
Subject: [PATCH 0771/3820] New translations graph-node.mdx (German)

---
 .../pages/de/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/de/indexing/tooling/graph-node.mdx

diff --git a/website/pages/de/indexing/tooling/graph-node.mdx b/website/pages/de/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..9dedce36b46f
--- /dev/null
+++ b/website/pages/de/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Der Graph-Knoten
+---
+
+Graph Node ist die Komponente, die Subgrafen indiziert und die resultierenden Daten zur Abfrage über eine GraphQL-API verfügbar macht. Als solches ist es für den Indexer-Stack von zentraler Bedeutung, und der korrekte Betrieb des Graph-Knotens ist entscheidend für den Betrieb eines erfolgreichen Indexers.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Der Graph-Knoten
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL-Datenbank
+
+Der Hauptspeicher für den Graph-Knoten, hier werden Subgraf-Daten sowie Metadaten zu Subgrafen und Subgraf-unabhängige Netzwerkdaten wie Block-Cache und eth_call-Cache gespeichert.
+
+### Netzwerk-Clients
+
+In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS-Knoten
+
+Subgraf-Bereitstellungsmetadaten werden im IPFS-Netzwerk gespeichert. Der Graph-Knoten greift hauptsächlich während der Subgraf-Bereitstellung auf den IPFS-Knoten zu, um das Subgraf-Manifest und alle verknüpften Dateien abzurufen. Netzwerk-Indexierer müssen keinen eigenen IPFS-Knoten hosten, ein IPFS-Knoten für das Netzwerk wird unter https://ipfs.network.thegraph.com gehostet.
+
+### Prometheus-Metrikserver
+
+Um Überwachung und Berichterstellung zu ermöglichen, kann Graph Node optional Metriken auf einem Prometheus-Metrikserver protokollieren.
+
+### Einstieg in den Sourcecode
+
+#### Installieren Sie die Voraussetzungen
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Konfiguration
+
+1. Starten Sie einen PostgreSQL-Datenbankserver
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Nachdem alle Abhängigkeiten eingerichtet sind, starten Sie den Graph-Knoten:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Erste Schritte mit Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+Wenn es ausgeführt wird, stellt Graph Node die folgenden Ports zur Verfügung:
+
+| Port | Zweck                                           | Routen                                         | CLI-Argument       | Umgebungsvariable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | ----------------- |
+| 8000 | GraphQL HTTP-Server<br />(für Subgraf-Abfragen) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                 |
+| 8001 | GraphQL WS<br />(für Subgraf-Abonnements)       | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                 |
+| 8020 | JSON-RPC<br />(zum Verwalten von Deployments)   | /                                              | \--admin-port      | -                 |
+| 8030 | Subgraf-Indizierungsstatus-API                  | /graphql                                       | \--index-node-port | -                 |
+| 8040 | Prometheus-Metriken                             | /metrics                                       | \--metrics-port    | -                 |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Erweiterte Graph-Knoten-Konfiguration
+
+In seiner einfachsten Form kann Graph Node mit einer einzelnen Instanz von Graph Node, einer einzelnen PostgreSQL-Datenbank, einem IPFS-Knoten und den Netzwerk-Clients betrieben werden, die von den zu indizierenden Subgrafen benötigt werden.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> Bei Verwendung einer Konfigurationsdatei ist es nicht möglich, die Optionen --postgres-url, --postgres-secondary-hosts und --postgres-host-weights zu verwenden.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Mehrere Graph-Knoten
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Beachten Sie darauf, dass mehrere Graph-Knoten so konfiguriert werden können, dass sie dieselbe Datenbank verwenden, die ihrerseits durch Sharding horizontal skaliert werden kann.
+
+#### Bereitstellungsregeln
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Beispielkonfiguration für Bereitstellungsregeln:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Dedizierte Abfrageknoten
+
+Knoten können explizit als Abfrageknoten konfiguriert werden, indem Sie Folgendes in die Konfigurationsdatei aufnehmen:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Jeder Knoten, dessen --node-id mit dem regulären Ausdruck übereinstimmt, wird so eingerichtet, dass er nur auf Abfragen antwortet.
+
+#### Datenbankskalierung durch Sharding
+
+Für die meisten Anwendungsfälle reicht eine einzelne Postgres-Datenbank aus, um eine Graph-Node-Instanz zu unterstützen. Wenn eine Graph-Node-Instanz aus einer einzelnen Postgres-Datenbank herauswächst, ist es möglich, die Speicherung der Daten des Graph-Nodes auf mehrere Postgres-Datenbanken aufzuteilen. Alle Datenbanken zusammen bilden den Speicher der Graph-Node-Instanz. Jede einzelne Datenbank wird als Shard bezeichnet.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding wird nützlich, wenn Ihre vorhandene Datenbank nicht mit der Last Schritt halten kann, die Graph Node ihr auferlegt, und wenn es nicht mehr möglich ist, die Datenbankgröße zu erhöhen.
+
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+
+Was das Konfigurieren von Verbindungen betrifft, beginnen Sie mit max_connections in postgresql.conf, das auf 400 (oder vielleicht sogar 200) eingestellt ist, und sehen Sie sich die Prometheus-Metriken store_connection_wait_time_ms und store_connection_checkout_count an. Spürbare Wartezeiten (alles über 5 ms) sind ein Hinweis darauf, dass zu wenige Verbindungen verfügbar sind; hohe Wartezeiten werden auch dadurch verursacht, dass die Datenbank sehr ausgelastet ist (z. B. hohe CPU-Last). Wenn die Datenbank jedoch ansonsten stabil erscheint, weisen hohe Wartezeiten darauf hin, dass die Anzahl der Verbindungen erhöht werden muss. In der Konfiguration ist die Anzahl der Verbindungen, die jede Graph-Knoten-Instanz verwenden kann, eine Obergrenze, und der Graph-Knoten hält Verbindungen nicht offen, wenn er sie nicht benötigt.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Dedizierte Blockaufnahme
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Unterstützung mehrerer Netzwerke
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Mehrere Netzwerke
+- Mehrere Anbieter pro Netzwerk (dies kann eine Aufteilung der Last auf Anbieter ermöglichen und kann auch die Konfiguration von vollständigen Knoten sowie Archivknoten ermöglichen, wobei Graph Node günstigere Anbieter bevorzugt, wenn eine bestimmte Arbeitslast dies zulässt).
+- Zusätzliche Anbieterdetails, wie Funktionen, Authentifizierung und Anbietertyp (für experimentelle Firehose-Unterstützung)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Umgebungsvariablen
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Kontinuierlicher Einsatz
+
+Benutzer, die ein skaliertes Indizierungs-Setup mit erweiterter Konfiguration betreiben, können von der Verwaltung ihrer Graph-Knoten mit Kubernetes profitieren.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Managing Graph Node
+
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node stellt die Metriken standardmäßig durch den Prometheus-Endpunkt am Port 8040 bereit. Grafana kann dann zur Visualisierung dieser Metriken verwendet werden.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Working with subgraphs
+
+#### Indizierungsstatus-API
+
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Indexing performance
+
+There are three separate parts of the indexing process:
+
+- Fetching events of interest from the provider
+- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
+- Writing the resulting data to the store
+
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+
+Common causes of indexing slowness:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- A large number of events to process
+- Slow database connection time, for crowded nodes
+- The provider itself falling behind the chain head
+- Slowness in fetching new receipts at the chain head from the provider
+
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+
+#### Failed subgraphs
+
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+
+- Deterministic failures: these are failures which will not be resolved with retries
+- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
+
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Block and call cache
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. If the block matches the provider, then the issue can be debugged directly against the provider.
+
+#### Querying issues and errors
+
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+
+However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+
+There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.
+
+##### Query caching
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analysing queries
+
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
+
+In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
+
+##### Account-like optimisation
+
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Removing subgraphs
+
+> This is new functionality, which will be available in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 4469f303d6e8f84e11dba51f833e1deee05a6365 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:16 -0500
Subject: [PATCH 0772/3820] New translations advanced.mdx (German)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/de/subgraphs/developing/creating/advanced.mdx b/website/pages/de/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..aa21fd14c492
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Overview
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Non-fatal errors
+
+Indexing errors on already synced subgraphs will, by default, cause the subgraph to fail and stop syncing. Subgraphs can alternatively be configured to continue syncing in the presence of errors, by ignoring the changes made by the handler which provoked the error. This gives subgraph authors time to correct their subgraphs while queries continue to be served against the latest block, though the results might be inconsistent due to the bug that caused the error. Note that some errors are still always fatal. To be non-fatal, the error must be known to be deterministic.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Enabling non-fatal errors requires setting the following feature flag on the subgraph manifest:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way. File data sources support fetching files from IPFS and from Arweave.
+
+> This also lays the groundwork for deterministic indexing of off-chain data, as well as the potential introduction of arbitrary HTTP-sourced data.
+
+### Overview
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Upgrade guide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Add a new entity type which will be updated when files are found
+
+File data sources cannot access or update chain-based entities, but must update file specific entities.
+
+This may mean splitting out fields from existing entities into separate entities, linked together.
+
+Original combined entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+New, split entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+If the relationship is 1:1 between the parent entity and the resulting file data source entity, the simplest pattern is to link the parent entity to a resulting file entity by using the IPFS CID as the lookup. Get in touch on Discord if you are having difficulty modelling your new file-based entities!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+This is the data source which will be spawned when a file of interest is identified.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Create a new handler to process files
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Example handler:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Spawn file data sources when required
+
+You can now create file data sources during execution of chain-based handlers:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Example:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+This will create a new file data source, which will poll Graph Node's configured IPFS or Arweave endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Congratulations, you are using file data sources!
+
+#### Deploying your subgraphs
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitations
+
+File data source handlers and entities are isolated from other subgraph entities, ensuring that they are deterministic when executed, and ensuring no contamination of chain-based data sources. To be specific:
+
+- Entities created by File Data Sources are immutable, and cannot be updated
+- File Data Source handlers cannot access entities from other file data sources
+- Entities associated with File Data Sources cannot be accessed by chain-based handlers
+
+> While this constraint should not be problematic for most use-cases, it may introduce complexity for some. Please get in touch via Discord if you are having issues modelling your file-based data in a subgraph!
+
+Additionally, it is not possible to create data sources from a file data source, be it an onchain data source or another file data source. This restriction may be lifted in the future.
+
+#### Best practices
+
+If you are linking NFT metadata to corresponding tokens, use the metadata's IPFS hash to reference a Metadata entity from the Token entity. Save the Metadata entity using the IPFS hash as an ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> We are working to improve the above recommendation, so queries only return the "most recent" version
+
+#### Known issues
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Beispiele
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### References
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Grafting onto Existing Subgraphs
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Because grafting copies rather than indexes base data, it is much quicker to get the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From f24c4851ab91350a5ecc8566f0ef18963dfa355d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:18 -0500
Subject: [PATCH 0773/3820] New translations api.mdx (German)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/de/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/de/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..d3118e43e306
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API Reference
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- Low-level primitives to translate between different type systems such as Ethereum, JSON, GraphQL and AssemblyScript.
+
+### Versionen
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| Version | Release notes                                                                                                                                                                                                                                            |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### Built-in Types
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Adress
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Creating entities
+
+The following is a common pattern for creating entities from Ethereum events.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Loading entities from the store
+
+If an entity already exists, it can be loaded from the store with the following:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Looking up entities created withing a block
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### Updating existing entities
+
+There are two ways to update an existing entity:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+Changing properties is straight forward in most cases, thanks to the generated property setters:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+It is also possible to unset properties with one of the following two instructions:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// Das wird nicht funktionieren
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// Das wird funktionieren
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Removing entities from the store
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
+
+#### Support for Ethereum Types
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+The following example illustrates this. Given a subgraph schema like
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Events and Block/Transaction Data
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Access to Smart Contract State
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+A common pattern is to access the contract from which an event originates. This is achieved with the following code:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address.
+
+#### Handling Reverted Calls
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Encoding/Decoding ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+For more information:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Logging one or more values
+
+##### Logging a single value
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Logging a single entry from an existing array
+
+In the example below, only the first value of the argument array is logged, despite the array containing three values.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Logging multiple entries from an existing array
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Logging a specific entry from an existing array
+
+To display a specific value in the array, the indexed value must be provided.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Logging event information
+
+The example below logs the block number, block hash and transaction hash from an event:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Given an IPFS hash or path, reading a file from IPFS is done as follows:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### Type Conversions Reference
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### Data Source Metadata
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entity and DataSourceContext
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From 7fe391ebff318ba6d57a4195a61913c1d9618ecd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:19 -0500
Subject: [PATCH 0774/3820] New translations common-issues.mdx (German)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/de/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/de/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..f8d0c9c004c2
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Common AssemblyScript Issues
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 14406422cc1fc985544b2d591b857dac4f150ac8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:20 -0500
Subject: [PATCH 0775/3820] New translations unit-testing-framework.mdx
 (German)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..2133c1d4b5c9
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Unit Testing Framework
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Getting Started
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+or
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+This will run all tests in the test folder:
+
+```sh
+graph test
+```
+
+This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
+
+```sh
+graph test gravity
+```
+
+This will run only that specific test file:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo subgraph
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Video tutorials
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+or
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Examples:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Example:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Examples:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Write a Unit Test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Assuming we have the following handler function (along with two helper functions to make our life easier):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+We first have to create a test file in our project. This is an example of how that might look like:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- We're setting up our initial state and adding one custom Gravatar entity;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- We assert the state of the store. How does that work? - We're passing a unique combination of Entity type and id. Then we check a specific field on that Entity and assert that it has the value we expect it to have. We're doing this both for the initial Gravatar Entity we added to the store, as well as the two Gravatar entities that gets added when the handler function is called;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+There we go - we've created our first test! 👏
+
+Now in order to run our tests you simply need to run the following in your subgraph root folder:
+
+`graph test Gravity`
+
+And if all goes well you should be greeted with the following:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Common test scenarios
+
+### Hydrating the store with a certain state
+
+Users are able to hydrate the store with a known set of entities. Here's an example to initialise the store with a Gravatar entity:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Calling a mapping function with an event
+
+A user can create a custom event and pass it to a mapping function that is bound to the store:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Calling all of the mappings with event fixtures
+
+Users can call the mappings with test fixtures.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocking contract calls
+
+Users can mock contract calls:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+As demonstrated, in order to mock a contract call and hardcore a return value, the user must provide a contract address, function name, function signature, an array of arguments, and of course - the return value.
+
+Users can also mock function reverts:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking IPFS files (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Asserting the state of the store
+
+Users are able to assert the final (or midway) state of the store through asserting entities. In order to do this, the user has to supply an Entity type, the specific ID of an Entity, a name of a field on that Entity, and the expected value of the field. Here's a quick example:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interacting with Event metadata
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Asserting variable equality
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Users can assert that an entity does not exist in the store. The function takes an entity type and an id. If the entity is in fact in the store, the test will fail with a relevant error message. Here's a quick example of how to use this functionality:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+You can print the whole store to the console using this helper function:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Expected failure
+
+Users can have expected test failures, using the shouldFail flag on the test() functions:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+If the test is marked with shouldFail = true but DOES NOT fail, that will show up as an error in the logs and the test block will fail. Also, if it's marked with shouldFail = false (the default state), the test executor will crash.
+
+### Logging
+
+Having custom logs in the unit tests is exactly the same as logging in the mappings. The difference is that the log object needs to be imported from matchstick-as rather than graph-ts. Here's a simple example with all non-critical log types:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Users can also simulate a critical failure, like so:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Logging critical errors will stop the execution of the tests and blow everything up. After all - we want to make sure you're code doesn't have critical logs in deployment, and you should notice right away if that were to happen.
+
+### Testing derived fields
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testing dynamic data sources
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Example below:
+
+First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+And then we have the test using one of the methods in the dataSourceMock namespace to set a new return value for all of the dataSource functions:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Notice that dataSourceMock.resetValues() is called at the end. That's because the values are remembered when they are changed and need to be reset if you want to go back to the default values.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Test Coverage
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Prerequisites
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Export your handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Usage
+
+Once that's all set up, to run the test coverage tool, simply run:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Test run time duration in the log output
+
+The log output includes the test run duration. Here's an example:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Common compiler errors
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Additional Resources
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Feedback
+
+If you have any questions, feedback, feature requests or just want to reach out, the best place would be The Graph Discord where we have a dedicated channel for Matchstick, called 🔥| unit-testing.

From 2c018adc2bfe6bb69b3db49a2054ffa602a61972 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:21 -0500
Subject: [PATCH 0776/3820] New translations transferring-a-subgraph.mdx
 (German)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/de/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/de/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..d6837fbade98
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs, die im dezentralen Netzwerk veröffentlicht werden, haben eine NFT, die auf die Adresse geprägt wird, die den Subgraph veröffentlicht hat. Die NFT basiert auf dem Standard ERC721, der Überweisungen zwischen Konten im The Graph Network erleichtert.
+
+## Erinnerungshilfen
+
+- Wer im Besitz der NFT ist, kontrolliert den Subgraph.
+- Wenn der Eigentümer beschließt, das NFT zu verkaufen oder zu übertragen, kann er diesen Subgraph im Netz nicht mehr bearbeiten oder aktualisieren.
+- Sie können die Kontrolle über einen Subgraph leicht an eine Multisig übertragen.
+- Ein Community-Mitglied kann einen Subgraph im Namen einer DAO erstellen.
+
+## Betrachten Sie Ihren Subgraph als NFT
+
+Um Ihren Subgraph als NFT zu betrachten, können Sie einen NFT-Marktplatz wie **OpenSea** besuchen:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Oder ein Wallet-Explorer wie **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Schritt für Schritt
+
+Um das Eigentum an einem Subgraph zu übertragen, gehen Sie wie folgt vor:
+
+1. Verwenden Sie die in Subgraph Studio integrierte Benutzeroberfläche:
+
+   ![Subgraph-Besitzübertragung](/img/subgraph-ownership-transfer-1.png)
+
+2. Wählen Sie die Adresse, an die Sie den Subgraph übertragen möchten:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optional können Sie auch die integrierte Benutzeroberfläche von NFT-Marktplätzen wie OpenSea verwenden:
+
+![Subgraph-Eigentumsübertragung vom NFT-Marktplatz](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 8a0c35a7c80c62d948740dad1e0069e5cecc1e31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:22 -0500
Subject: [PATCH 0777/3820] New translations graphql-api.mdx (German)

---
 .../de/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/de/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/de/subgraphs/querying/graphql-api.mdx b/website/pages/de/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..cef9143e85af
--- /dev/null
+++ b/website/pages/de/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL-API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Beispiele
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sortierung
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Beispiel
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Beispiel für die Sortierung verschachtelter Entitäten
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Pagination
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Die Abfrage für die ersten 10 Token:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtering
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Example for range filtering
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for block filtering
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for nested entity filtering
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+This can be useful if you are looking to fetch only entities whose child-level entities meet the provided conditions.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logical operators
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### All Filters
+
+Full list of parameter suffixes:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Time-travel queries
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Beispiel
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Beispiel
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltext Search Queries
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Fulltext search operators:
+
+| Symbol | Operator    | Beschreibung                                                                                                                         |
+| ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
+
+#### Beispiele
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validierung
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Subgraph Metadata
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: the hash of the block
+- number: the block number
+- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 56800160923be4c96faff559ceef5895c2698b04 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:23 -0500
Subject: [PATCH 0778/3820] New translations python.mdx (German)

---
 .../pages/de/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/de/subgraphs/querying/python.mdx

diff --git a/website/pages/de/subgraphs/querying/python.mdx b/website/pages/de/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..c10d7a0e57ab
--- /dev/null
+++ b/website/pages/de/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Getting Started
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From b474247f5d821502a08bfbec9ea0f9e224cb52ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:24 -0500
Subject: [PATCH 0779/3820] New translations triggers.mdx (German)

---
 website/pages/de/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/de/substreams/sps/triggers.mdx

diff --git a/website/pages/de/substreams/sps/triggers.mdx b/website/pages/de/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/de/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 7ad9f9d61cda5f4653d17cb81fc4f6d73982c285 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:27 -0500
Subject: [PATCH 0780/3820] New translations overview.mdx (Italian)

---
 website/pages/it/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/it/indexing/overview.mdx

diff --git a/website/pages/it/indexing/overview.mdx b/website/pages/it/indexing/overview.mdx
new file mode 100644
index 000000000000..fcd01714bbb8
--- /dev/null
+++ b/website/pages/it/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Gli Indexer sono operatori di nodi di The Graph Network che fanno staking di Graph Token (GRT) per fornire servizi di indicizzazione e di elaborazione delle query. Gli Indexer guadagnano tariffe di query e ricompense di indicizzazione per i loro servizi. Guadagnano anche tariffe di query che vengono rimborsate in base a una funzione di rimborso esponenziale.
+
+Il GRT che viene fatto staking nel protocollo è soggetto a un periodo di scongelamento e può essere ridotto se gli Indexer sono malintenzionati e servono dati errati alle applicazioni o se indicizzano in modo errato. Gli Indexer guadagnano anche ricompense per le stake delegate dai Delegator, per contribuire alla rete.
+
+Gli Indexer selezionano i subgraph da indicizzare in base al segnale di curation del subgraph, dove i Curator fanno staking di GRT per indicare quali subgraph sono di alta qualità e dovrebbero essere prioritari. I consumatori (ad esempio, le applicazioni) possono anche impostare i parametri per cui gli Indexer elaborano le query per i loro subgraph e stabilire le preferenze per le tariffe di query.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### Qual è lo stake minimo richiesto per essere un Indexer sulla rete?
+
+Lo stake minimo per un Indexer è attualmente fissato a 100K GRT.
+
+### Quali sono le fonti di guadagno di un Indexer?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### Come vengono distribuite le ricompense di indicizzazione?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### Che cos'è una prova di indicizzazione (POI)?
+
+I POI sono utilizzati nella rete per verificare che un Indexer stia indicizzando i subgraph su cui ha effettuato l'allocazione. Un POI per il primo blocco dell'epoca corrente deve essere presentato alla chiusura di un'allocazione affinché questa possa beneficiare delle ricompense di indicizzazione. Un POI per un blocco è un insieme di tutte le transazioni dell'entity store per una specifica distribuzione di subgraph fino a quel blocco incluso.
+
+### Quando vengono distribuite le ricompense di indicizzazione?
+
+Le allocazioni accumulano continuamente ricompense mentre sono attive e vengono allocate entro 28 epoche. Le ricompense vengono raccolte dagli Indexer e distribuite quando le loro allocazioni vengono chiuse. Ciò avviene manualmente, ogni volta che l'Indexer vuole chiuderle forzatamente, oppure dopo 28 epoche un Delegator può chiudere l'allocazione per l'Indexer, ma questo non comporta ricompense. 28 epoche è la durata massima dell'allocazione (al momento, un'epoca dura circa 24 ore).
+
+### È possibile monitorare le ricompense di indicizzazione in sospeso?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Molte delle dashboard create dalla comunità includono i valori delle ricompense in sospeso, che possono essere facilmente controllate manualmente seguendo questi passaggi:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### Cosa sono le controversie e dove posso vederle?
+
+Le query e le allocazioni dell'Indexer possono essere contestate su The Graph durante il periodo di contestazione. Il periodo di contestazione varia a seconda del tipo di contestazione. Le query/attestazioni hanno una finestra di contestazione di 7 epoche, mentre le allocazioni 56 epoche. Una volta trascorsi questi periodi, non è più possibile aprire controversie né contro le allocation né contro le query. Quando viene aperta una controversia, i Fisherman devono versare un deposito minimo di 10.000 GRT, che rimarrà bloccato fino a quando la controversia non sarà conclusa e sarà stata data una risoluzione. I Fisherman sono tutti i partecipanti alla rete che aprono controversie.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- Se la controversia viene respinta, il GRT depositato dai Fishermen verrà bruciato e l'Indexer contestato non verrà tagliato.
+- Se la controversia viene risolta con un pareggio, il deposito dei Fishermen verrà restituito e l'Indexer contestato non verrà tagliato.
+- Se la controversia viene accettata, il GRT depositato dai Fishermen verrà restituito, l'Indexer contestato verrà tagliato e i Fishermen guadagneranno il 50% dei GRT tagliati.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### Cosa sono gli sconti sulle tariffe di query e quando vengono distribuiti?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Una volta chiusa un'allocation, gli sconti possono essere richiesti dall'Indexer. Al momento della richiesta, gli sconti sulle tariffe di query vengono distribuiti all'Indexer e ai suoi Delegator in base alla riduzione delle tariffe di query e alla funzione di sconto esponenziale.
+
+### Che cos'è la query fee cut e la indexing reward cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### Come fanno gli Indexer a sapere quali subgraph indicizzare?
+
+Gli Indexer possono differenziarsi applicando tecniche avanzate per prendere decisioni sull'indicizzazione dei subgraph, ma per dare un'idea generale discuteremo diverse metriche chiave utilizzate per valutare i subgraph nella rete:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### Quali sono i requisiti hardware?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memoria in GBs) | Postgres<br />(disco in TBs) | VMs<br />(CPUs) | VMs<br />(memoria in GBs) |
+| -------- | :------------------: | :----------------------------: | :--------------------------: | :-------------: | :-----------------------: |
+| Piccolo  |           4          |                8               |               1              |        4        |             16            |
+| Standard |           8          |               30               |               1              |        12       |             48            |
+| Medio    |          16          |               64               |               2              |        32       |             64            |
+| Grande   |          72          |               468              |              3.5             |        48       |            184            |
+
+### Quali sono le precauzioni di base per la sicurezza che un Indexer dovrebbe adottare?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastruttura
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Nota: Per supportare una scalabilità agile, si consiglia di separare le attività di query e indicizzazione tra diversi gruppi di nodi: nodi di query e nodi di indicizzazione.
+
+### Panoramica delle porte
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Porta | Obiettivo                                           | Routes                                         | Argomento CLI      | Variabile d'ambiente |
+| ----- | --------------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000  | GraphQL HTTP server<br />(per le query di subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001  | GraphQL WS<br />(per le sottoscrizioni ai subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020  | JSON-RPC<br />(per la gestione dei deployment)      | /                                              | \--admin-port      | -                    |
+| 8030  | Subgraph indexing status API                        | /graphql                                       | \--index-node-port | -                    |
+| 8040  | Metriche di Prometheus                              | /metrics                                       | \--metrics-port    | -                    |
+
+#### Servizio Indexer
+
+| Porta | Obiettivo                                                       | Routes                                                      | Argomento CLI   | Variabile d'ambiente   |
+| ----- | --------------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600  | GraphQL HTTP server<br />(per le query di subgraph a pagamento) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300  | Metriche di Prometheus                                          | /metrics                                                    | \--metrics-port | -                      |
+
+#### Indexer Agent
+
+| Porta | Purpose                       | Routes | CLI Argument               | Environment Variable                    |
+| ----- | ----------------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000  | API di gestione degli Indexer | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Configurare l'infrastruttura server utilizzando Terraform su Google Cloud
+
+> Nota: gli Indexer possono utilizzare in alternativa AWS, Microsoft Azure o Alibaba.
+
+#### Installare i prerequisiti
+
+- Google Cloud SDK
+- Kubectl command line tool
+- Terraform
+
+#### Creare un progetto Google Cloud
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Autenticare con Google Cloud e creare un nuovo progetto.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Utilizzare la pagina di fatturazione di Google Cloud Console per abilitare la fatturazione del nuovo progetto.
+
+- Creare una configurazione di Google Cloud.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Abilitare le API di Google Cloud necessarie.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Creare un account di servizio.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Abilitare il peering tra il database e il cluster Kubernetes che verrà creato nella fase successiva.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Creare un file di configurazione minima di terraform (aggiornare secondo necessità).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Utilizzare Terraform per creare l'infrastruttura
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Eseguire i seguenti comandi per creare l'infrastruttura.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Creazione dei componenti Kubernetes per l'Indexer
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Iniziare dalla sorgente
+
+#### Installare i prerequisiti
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Avviare un server di database PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Ora che tutte le dipendenze sono state configurate, avviare il Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Come iniziare a usare Docker
+
+#### Prerequisites
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Setup
+
+1. Clonare il Graph Node e navigare nella directory Docker:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Avviare un Graph Node locale che si connetta all'endpoint di Ethereum:
+
+```sh
+docker-compose up
+```
+
+### Componenti dell'Indexer
+
+Per partecipare con successo alla rete è necessario un monitoraggio e un'interazione quasi costante, quindi abbiamo costruito una suite di applicazioni Typescript per facilitare la partecipazione alla rete degli Indexer. I componenti di Indexer sono tre:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Per cominciare
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### Dai pacchetti NPM
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### Dalla fonte
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Utilizzo di docker
+
+- Estrarre le immagini dal registro
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Oppure costruire le immagini localmente dal sorgente
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Eseguire i componenti
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Utilizzo di K8s e Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Usage
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexer agent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Gestione dell'Indexer tramite Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Usage
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Regole di indicizzazione
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Modello di dati:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Esempio di utilizzo della regola di indicizzazione:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### CLI della coda di azioni
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Azione aggiunta alla coda dallo strumento ottimizzatore di terze parti o dall'utente di indexer-cli
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- L'Indexer può monitorare la coda delle azioni per vedere la cronologia dell'esecuzione delle azioni e, se necessario, riapprovare e aggiornare le voci di azione se non sono state eseguite. La coda di azioni fornisce una cronologia di tutte le azioni accodate ed eseguite.
+
+Modello di dati:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Esempio di utilizzo dalla sorgente:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Si noti che i tipi di azione supportati per la gestione dell'allocazione hanno requisiti di input diversi:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - parametri d'azione richiesti:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - parametri d'azione richiesti:
+    - allocationID
+    - deploymentID
+  - parametri dell'azione facoltativi:
+    - poi
+    - force (forza l'uso del POI fornito anche se non corrisponde a quello fornito dal the graph-node)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - parametri d'azione richiesti:
+    - allocationID
+    - deploymentID
+    - amount
+  - parametri dell'azione facoltativi:
+    - poi
+    - force (forza l'uso del POI fornito anche se non corrisponde a quello fornito dal the graph-node)
+
+#### Modelli di costo
+
+I modelli di costo forniscono prezzi dinamici per le query in base al mercato e agli attributi della query. L'Indexer service condivide con i gateway un modello di costo per ogni subgraph per il quale intende rispondere alle query. I gateway, a loro volta, utilizzano il modello di costo per prendere decisioni sulla selezione degli Indexer per ogni query e per negoziare il pagamento con gli Indexer scelti.
+
+#### Agora
+
+Il linguaggio Agora fornisce un formato flessibile per dichiarare i modelli di costo delle query. Un modello di prezzo Agora è una sequenza di istruzioni che vengono eseguite in ordine per ogni query di primo livello in una query GraphQL. Per ogni query di primo livello, la prima istruzione che vi corrisponde determina il prezzo per quella query.
+
+Una dichiarazione è composta da un predicato, che viene usato per abbinare le query GraphQL, e da un'espressione di costo che, una volta valutata, produce un costo in GRT decimali. I valori nella posizione dell'argomento nominato di una query possono essere catturati nel predicato e usati nell'espressione. Si possono anche impostare dei globali e sostituirli ai segnaposto in un'espressione.
+
+Esempio di modello di costo:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Esempio di query di costo utilizzando il modello di cui sopra:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Applicazione del modello di costo
+
+I modelli di costo vengono applicati tramite l'Indexer CLI, che li passa all'Indexer Management API dell' Indexer agent per la memorizzazione nel database. L'Indexer Service li preleva e serve i modelli di costo ai gateway ogni volta che li richiedono.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interazione con la rete
+
+### Staking al protocollo
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Approvare i token
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Fare staking dei token
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### La vita di un'allocazione
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From d976176e66ec55f9acd7b1c307f6488ae75d19ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:28 -0500
Subject: [PATCH 0781/3820] New translations tap.mdx (Italian)

---
 website/pages/it/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/it/indexing/tap.mdx

diff --git a/website/pages/it/indexing/tap.mdx b/website/pages/it/indexing/tap.mdx
new file mode 100644
index 000000000000..8604a92b41e7
--- /dev/null
+++ b/website/pages/it/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Panoramica
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notes:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From 37c9d8aa40b9ab5dcb4176cb850b48fc7ec30136 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:29 -0500
Subject: [PATCH 0782/3820] New translations graph-node.mdx (Italian)

---
 .../pages/it/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/it/indexing/tooling/graph-node.mdx

diff --git a/website/pages/it/indexing/tooling/graph-node.mdx b/website/pages/it/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..336052cca506
--- /dev/null
+++ b/website/pages/it/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node è il componente che indica i subgraph e rende i dati risultanti disponibili per l'interrogazione tramite API GraphQL. È quindi centrale per lo stack degli indexer, ed inoltre il corretto funzionamento di Graph Node è cruciale per il buon funzionamento di un indexer di successo.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### Database PostgreSQL
+
+È l'archivio principale del Graph Node, in cui vengono memorizzati i dati dei subgraph, i metadati sui subgraph e i dati di rete che non dipendono dal subgraph, come la cache dei blocchi e la cache eth_call.
+
+### Clienti della rete
+
+Per indicizzare una rete, Graph Node deve accedere a un cliente di rete tramite un'API JSON-RPC compatibile con EVM. Questo RPC può connettersi a un singolo cliente o può essere una configurazione più complessa che bilancia il carico su più clienti.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### Nodi IPFS
+
+I metadati di distribuzione del subgraph sono memorizzati sulla rete IPFS. The Graph Node accede principalmente al nodo IPFS durante la distribuzione del subgraph per recuperare il manifest del subgraph e tutti i file collegati. Gli indexer di rete non devono ospitare un proprio nodo IPFS. Un nodo IPFS per la rete è ospitato su https://ipfs.network.thegraph.com.
+
+### Server di metriche Prometheus
+
+Per consentire il monitoraggio e la creazione di report, Graph Node può opzionalmente registrare le metriche su un server di metriche Prometheus.
+
+### Iniziare dalla sorgente
+
+#### Installare i prerequisiti
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Avviare un server di database PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Ora che tutte le dipendenze sono state configurate, avviare il Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Come iniziare con Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Porti
+
+Quando è in funzione, Graph Node espone le seguenti porte:
+
+| Porta | Obiettivo                                           | Routes                                         | Argomento CLI      | Variabile d'ambiente |
+| ----- | --------------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000  | GraphQL HTTP server<br />(per le query di subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001  | GraphQL WS<br />(per le sottoscrizioni ai subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020  | JSON-RPC<br />(per la gestione dei deployment)      | /                                              | \--admin-port      | -                    |
+| 8030  | Subgraph indexing status API                        | /graphql                                       | \--index-node-port | -                    |
+| 8040  | Metriche di Prometheus                              | /metrics                                       | \--metrics-port    | -                    |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Configurazione avanzata del Graph Node
+
+Nella sua forma più semplice, Graph Node può essere utilizzato con una singola istanza di Graph Node, un singolo database PostgreSQL, un nodo IPFS e i client di rete richiesti dai subgraph da indicizzare.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> Quando si usa un file di configurazione, non è possibile usare le opzioni --postgres-url, --postgres-secondary-hosts e --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Graph Node multipli
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Si noti che più Graph Node possono essere configurati per utilizzare lo stesso database, che può essere scalato orizzontalmente tramite sharding.
+
+#### Regole di distribuzione
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Esempio di configurazione della regola di distribuzione:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|importante)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# Nessun shard, quindi usiamo lo shard predefinito chiamato "primario".
+indicizzatori = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# Non c'è nessun "match", quindi qualsiasi sottografo corrisponde
+shard = [ "sharda", "shardb" ]
+indicizzatori = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "indice_nodo_comunità_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Nodi di query dedicati
+
+I nodi possono essere configurati per essere esplicitamente nodi di query includendo quanto segue nel file di configurazione:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Ogni nodo il cui --node-id corrisponde all'espressione regolare sarà impostato per rispondere solo alle query.
+
+#### Scalabilità del database tramite sharding
+
+Per la maggior parte dei casi d'uso, un singolo database Postgres è sufficiente per supportare un'istanza del graph-node. Quando un'istanza del graph-node supera un singolo database Postgres, è possibile suddividere l'archiviazione dei dati del graph-node su più database Postgres. Tutti i database insieme formano lo store dell'istanza del graph-node. Ogni singolo database è chiamato shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Lo sharding diventa utile quando il database esistente non riesce a reggere il carico che Graph Node gli impone e quando non è più possibile aumentare le dimensioni del database.
+
+> In genere è meglio creare un singolo database il più grande possibile, prima di iniziare con gli shard. Un'eccezione è rappresentata dai casi in cui il traffico di query è suddiviso in modo molto disomogeneo tra i subgraph; in queste situazioni può essere di grande aiuto tenere i subgraph ad alto volume in uno shard e tutto il resto in un altro, perché questa configurazione rende più probabile che i dati per i subgraph ad alto volume rimangano nella cache interna del database e non vengano sostituiti da dati non necessari per i subgraph a basso volume.
+
+Per quanto riguarda la configurazione delle connessioni, iniziare con max_connections in postgresql.conf impostato a 400 (o forse anche a 200) e osservare le metriche di Prometheus store_connection_wait_time_ms e store_connection_checkout_count. Tempi di attesa notevoli (qualsiasi cosa superiore a 5 ms) indicano che le connessioni disponibili sono troppo poche; tempi di attesa elevati possono anche essere causati da un database molto occupato (come un elevato carico della CPU). Tuttavia, se il database sembra altrimenti stabile, tempi di attesa elevati indicano la necessità di aumentare il numero di connessioni. Nella configurazione, il numero di connessioni che ogni istanza del graph-node può utilizzare è un limite massimo e Graph Node non manterrà aperte le connessioni se non ne ha bisogno.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Ingestione di blocchi dedicati
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Supporto di più reti
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Reti multiple
+- Fornitori multipli per rete (questo può consentire di suddividere il carico tra i fornitori e di configurare nodi completi e nodi di archivio, con Graph Node che preferisce i fornitori più economici se un determinato carico di lavoro lo consente).
+- Ulteriori dettagli sul provider, come le caratteristiche, l'autenticazione e il tipo di provider (per il supporto sperimentale di Firehose)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[catene]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archivio", "tracce" ] } }
+]
+[catene.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Variabili d'ambiente
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Distribuzione continua
+
+Gli utenti che gestiscono una configurazione di indicizzazione scalare con una configurazione avanzata possono trarre vantaggio dalla gestione dei Graph Node con Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Gestione del Graph Node
+
+Dato un Graph Node (o più Graph Nodes!) in funzione, la sfida consiste nel gestire i subgraph distribuiti tra i nodi. Graph Node offre una serie di strumenti che aiutano a gestire i subgraph.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node fornisce le metriche tramite l'endpoint Prometheus sulla porta 8040. È possibile utilizzare Grafana per visualizzare queste metriche.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Lavorare con i subgraph
+
+#### Stato dell'indicizzazione API
+
+Disponibile sulla porta 8030/graphql per impostazione predefinita, l'API dello stato di indicizzazione espone una serie di metodi per verificare lo stato di indicizzazione di diversi subgraph, controllare le prove di indicizzazione, ispezionare le caratteristiche dei subgraph e altro ancora.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Prestazioni di indicizzazione
+
+Il processo di indicizzazione si articola in tre parti distinte:
+
+- Recuperare gli eventi di interesse dal provider
+- Elaborare gli eventi in ordine con i gestori appropriati (questo può comportare la chiamata alla chain per lo stato e il recupero dei dati dall'archivio)
+- Scrivere i dati risultanti nell'archivio
+
+Questi stadi sono collegati tra loro (cioè possono essere eseguiti in parallelo), ma dipendono l'uno dall'altro. Se i subgraph sono lenti da indicizzare, la causa dipende dal subgraph specifico.
+
+Cause comuni di lentezza dell'indicizzazione:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- Una grande quantità di interazioni con l'archivio durante l'esecuzione
+- Una grande quantità di dati da salvare nell'archivio
+- Un numero elevato di eventi da elaborare
+- Tempo di connessione al database lento, per i nodi affollati
+- Il fornitore stesso è in ritardo rispetto alla testa della chain
+- Lentezza nell'acquisizione di nuove ricevute dal fornitore alla testa della chain
+
+Le metriche di indicizzazione dei subgraph possono aiutare a diagnosticare la causa principale della lentezza dell'indicizzazione. In alcuni casi, il problema risiede nel subgraph stesso, ma in altri, il miglioramento dei provider di rete, la riduzione della contesa del database e altri miglioramenti della configurazione possono migliorare notevolmente le prestazioni dell'indicizzazione.
+
+#### I subgraph falliti
+
+Durante l'indicizzazione, i subgraph possono fallire se incontrano dati inaspettati, se qualche componente non funziona come previsto o se c'è un bug nei gestori di eventi o nella configurazione. Esistono due tipi generali di errore:
+
+- Guasti deterministici: si tratta di guasti che non possono essere risolti con tentativi di risposta
+- Fallimenti non deterministici: potrebbero essere dovuti a problemi con il provider o a qualche errore imprevisto di Graph Node. Quando si verifica un errore non deterministico, Graph Node riprova i gestori che non hanno funzionato, riducendo il tempo a disposizione.
+
+In alcuni casi, un errore può essere risolto dall'indexer (ad esempio, se l'errore è dovuto alla mancanza del tipo di provider giusto, l'aggiunta del provider richiesto consentirà di continuare l'indicizzazione). In altri casi, invece, è necessario modificare il codice del subgraph.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Cache dei blocchi e delle chiamate
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+Se si sospetta un'incongruenza nella cache a blocchi, come ad esempio un evento di ricezione tx mancante:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. Se il blocco corrisponde al provider, è possibile eseguire il debug del problema direttamente sul provider.
+
+#### Problemi ed errori di query
+
+Una volta che un subgraph è stato indicizzato, gli indexer possono aspettarsi di servire le query attraverso l'endpoint di query dedicato al subgraph. Se l'indexer spera di servire un volume significativo di query, è consigliabile un nodo di query dedicato; in caso di volumi di query molto elevati, gli indexer potrebbero voler configurare shard di replica in modo che le query non abbiano un impatto sul processo di indicizzazione.
+
+Tuttavia, anche con un nodo di query dedicato e le repliche, alcune query possono richiedere molto tempo per essere eseguite e, in alcuni casi, aumentare l'utilizzo della memoria e avere un impatto negativo sul tempo di query per gli altri utenti.
+
+Non esiste una "pallottola d'argento", ma una serie di strumenti per prevenire, diagnosticare e gestire le query lente.
+
+##### Caching delle query
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analisi delle query
+
+Le query problematiche emergono spesso in due modi. In alcuni casi, sono gli stessi utenti a segnalare la lentezza di una determinata query. In questo caso, la sfida consiste nel diagnosticare la ragione della lentezza, sia che si tratti di un problema generale, sia che si tratti di un problema specifico di quel subgraph o di quella query. E poi, naturalmente, risolverlo, se possibile.
+
+In altri casi, il fattore scatenante potrebbe essere l'elevato utilizzo della memoria su un nodo di query, nel qual caso la sfida consiste nell'identificare la query che causa il problema.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Con una query lenta, gli indexer hanno alcune opzioni. Naturalmente possono modificare il loro modello di costo, aumentando in modo significativo il costo di invio della query problematica. Questo può portare a una riduzione della frequenza della query. Tuttavia, questo spesso non risolve la causa principale del problema.
+
+##### Ottimizzazione di tipo account
+
+Le tabelle di database che memorizzano le entità sembrano essere generalmente di due tipi: "tipo transazioni", in cui le entità, una volta create, non vengono mai aggiornate, cioè memorizzano qualcosa di simile a un elenco di transazioni finanziarie, e "tipo account", in cui le entità vengono aggiornate molto spesso, cioè memorizzano qualcosa di simile a conti finanziari che vengono modificati ogni volta che viene registrata una transazione. Le tabelle di tipo account sono caratterizzate dal fatto di contenere un gran numero di versioni di entità, ma relativamente poche entità distinte. Spesso, in queste tabelle il numero di entità distinte è pari all'1% del numero totale di righe (versioni di entità)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Rimozione dei subgraph
+
+> Si tratta di una nuova funzionalità, che sarà disponibile in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From fd347ff08cf3ad9034ae34dcc9654660da590744 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:31 -0500
Subject: [PATCH 0783/3820] New translations advanced.mdx (Italian)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/it/subgraphs/developing/creating/advanced.mdx b/website/pages/it/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..3e7a7f2f6c4f
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Panoramica
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Errori non fatali
+
+Gli errori di indicizzazione su subgraph già sincronizzati causano, per impostazione predefinita, il fallimento del subgraph e l'interruzione della sincronizzazione. In alternativa, i subgraph possono essere configurati per continuare la sincronizzazione in presenza di errori, ignorando le modifiche apportate dal gestore che ha provocato l'errore. In questo modo gli autori dei subgraph hanno il tempo di correggere i loro subgraph mentre le query continuano a essere servite rispetto al blocco più recente, anche se i risultati potrebbero essere incoerenti a causa del bug che ha causato l'errore. Si noti che alcuni errori sono sempre fatali. Per essere non fatale, l'errore deve essere noto come deterministico.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Per abilitare gli errori non fatali è necessario impostare il seguente flag di caratteristica nel manifesto del subgraph:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+I data source file sono una nuova funzionalità del subgraph per accedere ai dati fuori chain durante l'indicizzazione in modo robusto ed estendibile. I data source file supportano il recupero di file da IPFS e da Arweave.
+
+> Questo pone anche le basi per l'indicizzazione deterministica dei dati fuori chain e per la potenziale introduzione di dati arbitrari provenienti da HTTP.
+
+### Panoramica
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Guida all'aggiornamento
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Aggiungere un nuovo tipo di entità che verrà aggiornato quando verranno trovati dei file
+
+I data sources file non possono accedere o aggiornare le entità basate sulla chain, ma devono aggiornare le entità specifiche del file.
+
+Ciò può significare dividere i campi delle entità esistenti in entità separate, collegate tra loro.
+
+Entità combinata originale:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+Entità nuova, divisa:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+Se la relazione è 1:1 tra l'entità genitore e l'entità data source file risultante, il modello più semplice è quello di collegare l'entità genitore a un'entità file risultante utilizzando il CID IPFS come lookup. Contattateci su Discord se avete difficoltà a modellare le vostre nuove entità basate su file!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+È l'origine dati che verrà generata quando viene identificato un file di interesse.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Creare un nuovo gestore per elaborare i file
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Esempio di gestore:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Creare i data source file quando necessario
+
+È ora possibile creare i data sources file durante l'esecuzione di gestori a chain:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Example:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+Questo creerà una nuova data source file, che interrogherà l'endpoint IPFS o Arweave configurato del Graph Node, ritentando se non viene trovato. Quando il file viene trovato, viene eseguito il gestore del data source file.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Congratulazioni, state usando i data source file!
+
+#### Distribuire i subgraph
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitazioni
+
+I gestori e le entità di data source file sono isolati dalle altre entità del subgraph, assicurando che siano deterministici quando vengono eseguiti e garantendo che non ci sia contaminazione di data source basate sulla chain. Per essere precisi:
+
+- Le entità create di Data Source file sono immutabili e non possono essere aggiornate
+- I gestori di Data Source file non possono accedere alle entità di altre data source file
+- Le entità associate al Data Source file non sono accessibili ai gestori alla chain
+
+> Sebbene questo vincolo non dovrebbe essere problematico per la maggior parte dei casi d'uso, potrebbe introdurre complessità per alcuni. Contattate via Discord se avete problemi a modellare i vostri dati basati su file in un subgraph!
+
+Inoltre, non è possibile creare data source da una data source file, sia essa una data source onchain o un'altra data source file. Questa restrizione potrebbe essere eliminata in futuro.
+
+#### Migliori pratiche
+
+Se si collegano i metadati NFT ai token corrispondenti, utilizzare l'hash IPFS dei metadati per fare riferimento a un'entità Metadata dall'entità Token. Salvare l'entità Metadata usando l'hash IPFS come ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> Stiamo lavorando per migliorare la raccomandazione di cui sopra, in modo che le query restituiscano solo la versione "più recente"
+
+#### Problemi conosciuti
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Esempi
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### Riferimenti
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Grafting su subgraph esistenti
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Poiché l'innesto copia piuttosto che indicizzare i dati di base, è molto più veloce portare il subgraph al blocco desiderato rispetto all'indicizzazione da zero, anche se la copia iniziale dei dati può richiedere diverse ore per subgraph molto grandi. Mentre il subgraph innestato viene inizializzato, il Graph Node registra le informazioni sui tipi di entità già copiati.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From fa92cfcae6512249ae466dc6e19654aec5b3648f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:32 -0500
Subject: [PATCH 0784/3820] New translations api.mdx (Italian)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/it/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/it/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..0cb5bcc1519c
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: API AssemblyScript
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## Riferimento API
+
+La libreria `@graphprotocol/graph-ts` fornisce le seguenti API:
+
+- Un'API `ethereum` per lavorare con gli smart contract di Ethereum, gli eventi, i blocchi, le transazioni e i valori di Ethereum.
+- Un'API `store` per caricare e salvare entità da e verso il Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- Un'API `ipfs` per caricare i file da IPFS.
+- Un'API `json` per analizzare i dati JSON.
+- Un'API `crypto` per utilizzare le funzioni crittografiche.
+- Primitive di basso livello per tradurre tra diversi sistemi di tipi come Ethereum, JSON, GraphQL e AssemblyScript.
+
+### Versioni
+
+La `apiVersion` nel manifest del subgraph specifica la versione dell'API di mappatura che viene eseguita da the Graph Node per un dato subgraph.
+
+| Versione | Note di rilascio                                                                                                                                                                                                                                         |
+| :------: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|   0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|   0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|   0.0.7  | Aggiunte le classi `TransactionReceipt` e `Log` ai tipi di Ethereum<br />Aggiunto il campo `receipt` all'oggetto Ethereum Event                                                                                                                          |
+|   0.0.6  | Aggiunto il campo `nonce` all'oggetto Ethereum Transaction<br />Aggiunto `baseFeePerGas` all'oggetto Ethereum Block                                                                                                                                      |
+|   0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|   0.0.4  | Aggiunto il campo `functionSignature` all'oggetto Ethereum SmartContractCall                                                                                                                                                                             |
+|   0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|   0.0.2  | Aggiunto il campo `input` all'oggetto Ethereum Transaction                                                                                                                                                                                               |
+
+### Tipi integrati
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+I seguenti tipi aggiuntivi sono forniti da `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+importare { ByteArray } da '@graphprotocol/graph-ts'
+```
+
+`ByteArray` rappresenta un array di `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decompone `x` in byte.
+- `fromHexString(hex: string): ByteArray` - La lunghezza dell'input deve essere pari. Il prefisso `0x` è facoltativo.
+
+_Type conversions_
+
+- `toHexString(): string` - Converte in una stringa esadecimale con prefisso `0x`.
+- `toString(): string` - Interpreta i byte come una string UTF-8.
+- `toBase58(): string` - Codifica i byte in una stringa base58.
+- `toU32(): u32` - Interpreta i byte come un `u32` little-endian. Viene lanciata in caso di overflow.
+- `toI32(): i32` - Interpreta l'array di byte come un `i32` little-endian. Viene lanciata in caso di overflow.
+
+_Operators_
+
+- equals(y: ByteArray): bool`- può essere scritto come`x == y\`.
+- `concat(other: ByteArray) : ByteArray` - restituisce un nuovo `ByteArray` costituito da `this` direttamente seguito da `other`
+- `concatI32(other: i32) : ByteArray` - restituisce un nuovo `ByteArray` costituito da `this` direttamente seguito dalla rappresentazione in byte di `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` è usato per rappresentare decimali di precisione arbitraria.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` - crea un `BigDecimal` da un `BigInt`.
+- `static fromString(s: string): BigDecimal` - analizza una stringa decimale.
+
+_Type conversions_
+
+- `toString(): string` - stampa una stringa decimale.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` - può essere scritto come `x + y`.
+- `minus(y: BigDecimal): BigDecimal` - può essere scritto come `x - y`.
+- `times(y: BigDecimal): BigDecimal` - può essere scritto come `x * y`.
+- `div(y: BigDecimal): BigDecimal` - può essere scritto come `x / y`.
+- `equals(y: BigDecimal): bool` - può essere scritto come `x == y`.
+- `notEqual(y: BigDecimal): bool` - può essere scritto come `x != y`.
+- `lt(y: BigDecimal): bool` – può essere scritto come `x < y`.
+- `le(y: BigDecimal): bool` – può essere scritto come `x <= y`.
+- `gt(y: BigDecimal): bool` – può essere scritto come `x > y`.
+- `ge(y: BigDecimal): bool` – può essere scritto come `x >= y`.
+- `neg(): BigDecimal` - può essere scritto come `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` è usato per rappresentare i grandi numeri interi. Questo include i valori Ethereum di tipo da `uint32` a `uint256` e da `int64` a `int256`. Tutto ciò che è inferiore a `uint32`, come `int32`, `uint24` o `int8` è rappresentato come `i32`.
+
+La classe `BigInt` ha la seguente API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` - crea un `BigInt` da un `i32`.
+
+- `BigInt.fromString(s: string): BigInt`- Analizza un `BigInt` da una stringa.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` - Interpreta `bytes` come un intero senza segno, little-endian. Se l'input è big-endian, chiamare prima `.reverse()`.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` - Interpreta `bytes` come un intero firmato, little-endian. Se l'input è big-endian, chiamare prima `.reverse()`.
+
+  _Type conversions_
+
+- `x.toHex(): string` - trasforma `BigInt` in una stringa di caratteri esadecimali.
+
+- `x.toString(): string` - trasforma `BigInt` in una stringa di numeri decimali.
+
+- `x.toI32(): i32` - restituisce il `BigInt` come `i32`; fallisce se il valore non entra in `i32`. È una buona idea controllare prima `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converte in un decimale senza parti frazionarie.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` - può essere scritto come `x + y`.
+- `x.minus(y: BigInt): BigInt` - può essere scritto come `x - y`.
+- `x.times(y: BigInt): BigInt` - può essere scritto come `x * y`.
+- `x.div(y: BigInt): BigInt` - può essere scritto come `x / y`.
+- `x.mod(y: BigInt): BigInt` - può essere scritto come `x % y`.
+- `x.equals(y: BigInt): bool` - può essere scritto come `x == y`.
+- `x.notEqual(y: BigInt): bool` - può essere scritto come `x != y`.
+- `x.lt(y: BigInt): bool` - può essere scritto come `x < y`.
+- `x.le(y: BigInt): bool` - può essere scritto come `x <= y`.
+- `x.gt(y: BigInt): bool` - può essere scritto come `x > y`.
+- `x.ge(y: BigInt): bool` - può essere scritto come `x >= y`.
+- `x.neg(): BigInt` - può essere scritto come `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` - divide per un decimale, dando un risultato decimale.
+- `x.isZero(): bool` - Conviene prima verificare se il numero è zero.
+- `x.isI32(): bool` - Controlla se il numero è compreso in un `i32`.
+- `x.abs(): BigInt` - Valore assoluto.
+- `x.pow(exp: u8): BigInt` - Esponenziale.
+- `bitOr(x: BigInt, y: BigInt): BigInt` - può essere scritto come `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` - può essere scritto come `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` - può essere scritto come `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` - può essere scritto come `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` può essere usato per memorizzare coppie key-value. Vedere [questo esempio] (https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+La classe `TypedMap` ha la seguente API:
+
+- `new TypedMap<K, V>()` - crea una mappa vuota con chiavi di tipo `K` e valori di tipo `V`
+- `map.set(chiave: K, valore: V): void` - imposta il valore di `chiave` su `valore`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` - restituisce la coppia key-value per una `key` o `null` se la `key` non esiste nella mappa
+- `map.get(chiave: K): V | null` - restituisce il valore di una `chiave` o `null` se la `chiave` non esiste nella mappa
+- `map.isSet(key: K): bool` - restituisce `true` se la `key` esiste nella mappa e `false` se non esiste
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` è usato per rappresentare array di byte di lunghezza arbitraria. Questo include i valori Ethereum di tipo `bytes`, `bytes32`, ecc.
+
+La classe `Bytes` estende [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) di AssemblyScript e supporta tutte le funzionalità di `Uint8Array`, oltre ai seguenti nuovi metodi:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Converte la stringa `hex`, che deve essere composta da un numero pari di cifre esadecimali, in un `ByteArray`. La stringa `hex` può facoltativamente iniziare con `0x`
+- `fromI32(i: i32) : Bytes` - Converte `i` in un array di byte
+
+_Type conversions_
+
+- `b.toHex()` - restituisce una stringa esadecimale che rappresenta i byte nell'array
+- `b.toString()` - converte i byte dell'array in una stringa di caratteri unicode
+- `b.toBase58()` - trasforma un valore Ethereum Bytes in una codifica base58 (usata per gli hash IPFS)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - restituisce nuovi `Bytes` costituiti da `this` direttamente seguito da `other`
+- `b.concatI32(other: i32) : ByteArray` - restituisce nuovi `Byte` costituiti da `this` direttamente seguito dalla rappresentazione in byte di `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` estende `Bytes` per rappresentare i valori di `address` di Ethereum.
+
+Aggiunge il seguente metodo all'API `Bytes`:
+
+- `Address.fromString(s: string): Address` - crea un `Address` a partire da una stringa esadecimale
+- `Address.fromBytes(b: Bytes): Address` - crea un `Address` da `b` che deve essere lungo esattamente 20 byte. Se si passa un valore con un numero di byte inferiore o superiore, risulterà in un errore
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+L'API `store` consente di caricare, salvare e rimuovere entità da e verso il Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Creazione di entità
+
+Quello che segue è un modello comune per la creazione di entità a partire da eventi Ethereum.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+Quando un evento `Transfer` viene incontrato durante l'elaborazione della chain, viene passato al gestore dell'evento `handleTransfer` usando il tipo `Transfer` generato (qui alias `TransferEvent` per evitare un conflitto di nomi con il tipo di entità). Questo tipo consente di accedere a dati quali la transazione genitore dell'evento e i suoi parametri.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Caricare le entità dallo store
+
+Se un'entità esiste già, può essere caricata dall'archivio con la seguente procedura:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Ricerca delle entità create all'interno di un blocco
+
+A partire da `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 e `@graphprotocol/graph-cli` v0.49.0 il metodo `loadInBlock` è disponibile per tutti i tipi di entità.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Nota: Se non esiste un'entità creata nel blocco dato, `loadInBlock` restituirà `null` anche se esiste un'entità con l'ID dato nel negozio.
+
+#### Ricerca di entità derivate
+
+A partire da `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 e `@graphprotocol/graph-cli` v0.51.0 è disponibile il metodo `loadRelated`.
+
+Ciò consente di caricare i campi entità derivati da un gestore di eventi. Per esempio, dato il seguente schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+Il codice seguente carica l'entità `Token` da cui è derivata l'entità `Holder`:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### Aggiornamento di entità esistenti
+
+Esistono due modi per aggiornare un'entità esistente:
+
+1. Caricare l'entità con, ad esempio, `Transfer.load(id)`, impostare le proprietà sull'entità, quindi `.save()` riportarla in archivio.
+2. È sufficiente creare l'entità con, ad esempio, `new Transfer(id)`, impostare le proprietà sull'entità e quindi `.save()` nel negozio. Se l'entità esiste già, le modifiche vengono unite ad essa.
+
+La modifica delle proprietà è semplice nella maggior parte dei casi, grazie ai setter di proprietà generati:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+È anche possibile disattivare le proprietà con una delle due istruzioni seguenti:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+Questo funziona solo con le proprietà opzionali, cioè quelle dichiarate senza un `!` in GraphQL. Due esempi potrebbero essere `owner: Bytes` o `amount: BigInt`.
+
+L'aggiornamento delle proprietà degli array è un po' più complicato, poiché l'ottenimento di un array da un'entità crea una copia di tale array. Ciò significa che le proprietà dell'array devono essere impostate di nuovo in modo esplicito dopo aver modificato l'array. Quanto segue presuppone che l'entità abbia un campo `numbers: [BigInt!]!`.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Rimozione di entità dal negozio
+
+Attualmente non c'è modo di rimuovere un'entità tramite i tipi generati. Per rimuovere un'entità è necessario passare il nome del tipo di entità e l'ID dell'entità a `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### API Ethereum
+
+L'API di Ethereum fornisce l'accesso agli smart contract, alle variabili di stato pubbliche, alle funzioni dei contratti, agli eventi, alle transazioni, ai blocchi e alla codifica/decodifica dei dati di Ethereum.
+
+#### Supporto per i tipi di Ethereum
+
+Come per le entità, `graph codegen` genera classi per tutti gli smart contract e gli eventi utilizzati in un subgraph. Per questo, gli ABI dei contratti devono far parte dell'origine dati nel manifest del subgraph. In genere, i file ABI sono memorizzati in una cartella `abis/`.
+
+Con le classi generate, le conversioni tra i tipi di Ethereum e i [tipi incorporati](#built-in-types) avvengono dietro le quinte, in modo che gli autori dei subgraph non debbano preoccuparsene.
+
+L'esempio seguente lo illustra. Dato uno schema di subgraph come
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+e una firma di evento `Transfer(address,address,uint256)` su Ethereum, i valori `from`, `to` e `amount` di tipo `address`, `address` e `uint256` sono convertiti in `Address` e `BigInt`, consentendo di passarli alle proprietà `Bytes!` e `BigInt!` dell'entità `Transfer`:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Eventi e dati di blocco/transazione
+
+Gli eventi di Ethereum passati ai gestori di eventi, come l'evento `Transfer` negli esempi precedenti, non solo forniscono accesso ai parametri dell'evento, ma anche alla transazione genitore e al blocco di cui fanno parte. I seguenti dati possono essere ottenuti dalle istanze di `event` (queste classi fanno parte del modulo `ethereum` di `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Accesso allo stato dello smart contract
+
+Il codice generato da `graph codegen` include anche classi per gli smart contract utilizzati nel subgraph. Queste possono essere utilizzate per accedere alle variabili di stato pubbliche e per chiamare le funzioni del contratto nel blocco corrente.
+
+Un modello comune è quello di accedere al contratto da cui proviene un evento. Questo si ottiene con il seguente codice:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` è alias di `TransferEvent` qui per evitare un conflitto di nomi con il tipo di entità
+
+Finché il `ERC20Contract` su Ethereum ha una funzione pubblica di sola lettura chiamata `symbol`, questa può essere chiamata con `.symbol()`. Per le variabili di stato pubbliche viene creato automaticamente un metodo con lo stesso nome.
+
+Qualsiasi altro contratto che faccia parte del subgraph può essere importato dal codice generato e può essere legato a un indirizzo valido.
+
+#### Gestione delle chiamate annullate
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Codifica/decodifica ABI
+
+I dati possono essere codificati e decodificati secondo il formato di codifica ABI di Ethereum utilizzando le funzioni `encode` e `decode` del modulo `ethereum`.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+Per maggiori informazioni:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Codifica/decodifica [libreria Rust/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### API di registrazione
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+L'API `log` include le seguenti funzioni:
+
+- `log.debug(fmt: string, args: Array<string>): void` - registra un messaggio di debug.
+- `log.info(fmt: string, args: Array<string>): void` - registra un messaggio informativo.
+- `log.warning(fmt: string, args: Array<string>): void` - registra un avviso.
+- `log.error(fmt: string, args: Array<string>): void` - registra un messaggio di errore.
+- `log.critical(fmt: string, args: Array<string>): void` - registra un messaggio critico _and_ termina il subgraph.
+
+L'API `log` accetta una stringa di formato e un array di valori stringa. Quindi sostituisce i segnaposto con i valori stringa dell'array. Il primo segnaposto `{}` viene sostituito dal primo valore dell'array, il secondo segnaposto `{}` viene sostituito dal secondo valore e così via.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Registrazione di uno o più valori
+
+##### Registrazione di un singolo valore
+
+Nell'esempio seguente, il valore stringa "A" viene passato in un array per diventare `['A']` prima di essere registrato:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Registrazione di una singola voce da un array esistente
+
+Nell'esempio seguente, viene registrato solo il primo valore dell'array di argomenti, nonostante l'array contenga tre valori.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Registrazione di più voci da una matrice esistente
+
+Ogni voce dell'array di argomenti richiede il proprio segnaposto `{}` nella stringa del messaggio di log. L'esempio seguente contiene tre segnaposto `{}` nel messaggio di log. Per questo motivo, tutti e tre i valori di `myArray` vengono registrati.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Registrazione di una voce specifica da un array esistente
+
+Per visualizzare un valore specifico della matrice, è necessario fornire il valore indicizzato.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Registrazione delle informazioni sugli eventi
+
+L'esempio seguente registra il numero di blocco, l'hash del blocco e l'hash della transazione di un evento:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Dato un hash o un percorso IPFS, la lettura di un file da IPFS avviene come segue:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Nota:** `ipfs.cat` non è deterministico al momento. Se il file non può essere recuperato attraverso la rete IPFS prima che la richiesta si esaurisca, restituirà `null`. Per questo motivo, vale sempre la pena di controllare che il risultato non sia `null`.
+
+È anche possibile elaborare file di dimensioni maggiori in modo streaming con `ipfs.map`. La funzione si aspetta l'hash o il percorso di un file IPFS, il nome di un callback e i flag per modificare il suo comportamento:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+L'unico flag attualmente supportato è `json`, che deve essere passato a `ipfs.map`. Con il flag `json`, il file IPFS deve essere costituito da una serie di valori JSON, un valore per riga. La chiamata a `ipfs.map` leggerà ogni riga del file, la deserializzerà in un `JSONValue` e chiamerà il callback per ognuno di essi. Il callback può quindi utilizzare le operazioni sulle entità per memorizzare i dati dal `JSONValue`. Le modifiche alle entità vengono memorizzate solo quando il gestore che ha chiamato `ipfs.map` termina con successo; nel frattempo, vengono mantenute in memoria e la dimensione del file che `ipfs.map` può elaborare è quindi limitata.
+
+In caso di successo, `ipfs.map` restituisce `void`. Se una qualsiasi invocazione del callback causa un errore, il gestore che ha invocato `ipfs.map` viene interrotto e il subgraph viene contrassegnato come fallito.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+L'API `crypto` rende disponibili funzioni crittografiche da usare nelle mappature. Al momento, ce n'è solo una:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+I dati JSON possono essere analizzati utilizzando l'API `json`:
+
+- `json.fromBytes(data: Bytes): JSONValue` - analizza i dati JSON da un array di `Bytes` interpretati come una sequenza UTF-8 valida
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` - versione sicura di `json.fromBytes`, restituisce una variante di errore se il parsing è fallito
+- `json.fromString(data: string): JSONValue` - analizza i dati JSON da una `string` UTF-8 valida
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` - versione sicura di `json.fromString`, restituisce una variante di errore se il parsing è fallito
+
+La classe `JSONValue` fornisce un modo per estrarre valori da un documento JSON arbitrario. Poiché i valori JSON possono essere booleani, numeri, array e altro, `JSONValue` è dotato di una proprietà `kind` per verificare il tipo di valore:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+Inoltre, esiste un metodo per verificare se il valore è `null`:
+
+- `value.isNull(): boolean`
+
+Quando il tipo di un valore è certo, può essere convertito in un [tipo incorporato](#built-in-types) usando uno dei seguenti metodi:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (e poi convertire `JSONValue` con uno dei 5 metodi precedenti)
+
+### Riferimento alle conversioni di tipo
+
+| Fonte(i)             | Destinazione          | Funzione di conversione          |
+| -------------------- | --------------------- | -------------------------------- |
+| Address              | Bytes                 | none                             |
+| Address              | String                | s.toHexString()                  |
+| BigDecimal           | String                | s.toString()                     |
+| BigInt               | BigDecimal            | s.toBigDecimal()                 |
+| BigInt               | String (hexadecimal)  | s.toHexString() o s.toHex()      |
+| BigInt               | String (unicode)      | s.toString()                     |
+| BigInt               | i32                   | s.toI32()                        |
+| Boolean              | Boolean               | none                             |
+| Bytes (signed)       | BigInt                | BigInt.fromSignedBytes(s)        |
+| Bytes (unsigned)     | BigInt                | BigInt.fromUnsignedBytes(s)      |
+| Bytes                | String (hexadecimal)  | s.toHexString() o s.toHex()      |
+| Bytes                | String (unicode)      | s.toString()                     |
+| Bytes                | String (base58)       | s.toBase58()                     |
+| Bytes                | i32                   | s.toI32()                        |
+| Bytes                | u32                   | s.toU32()                        |
+| Bytes                | JSON                  | json.fromBytes(s)                |
+| int8                 | i32                   | none                             |
+| int32                | i32                   | none                             |
+| int32                | BigInt                | BigInt.fromI32(s)                |
+| uint24               | i32                   | none                             |
+| int64 - int256       | BigInt                | none                             |
+| uint32 - uint256     | BigInt                | none                             |
+| JSON                 | boolean               | s.toBool()                       |
+| JSON                 | i64                   | s.toI64()                        |
+| JSON                 | u64                   | s.toU64()                        |
+| JSON                 | f64                   | s.toF64()                        |
+| JSON                 | BigInt                | s.toBigInt()                     |
+| JSON                 | string                | s.toString()                     |
+| JSON                 | Array                 | s.toArray()                      |
+| JSON                 | Object                | s.toObject()                     |
+| String               | Address               | Address.fromString(s)            |
+| Bytes                | Address               | Address.fromBytes(s)             |
+| String               | BigInt                | BigInt.fromString(s)             |
+| String               | BigDecimal            | BigDecimal.fromString(s)         |
+| String (hexadecimal) | Bytes                 | ByteArray.fromHexString(s)       |
+| String (UTF-8)       | Bytes                 | ByteArray.fromUTF8(s)            |
+
+### Metadati della Data Source
+
+È possibile ispezionare l'indirizzo del contratto, la rete e il contesto dell'origine dati che ha invocato il gestore attraverso lo spazio dei nomi `dataSource`:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entità e DataSourceContext
+
+La classe base `Entity` e la classe figlia `DataSourceContext` hanno degli helper per impostare e ottenere dinamicamente i campi:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext nel manifesto
+
+La sezione `contesto` all'interno di `dataSources` consente di definire coppie chiave-valore accessibili nelle mappature dei subgraph. I tipi disponibili sono `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List` e `BigInt`.
+
+Ecco un esempio YAML che illustra l'uso di vari tipi nella sezione `context`:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifica un valore booleano (`true` o `false`).
+- `String`: Specifica un valore string.
+- `Int`: Specifica un numero intero a 32 bit.
+- `Int8`: Specifica un numero intero a 8 bit.
+- `BigDecimal`: Specifica un numero decimale. Deve essere quotato.
+- `Bytes`: Specifica una string esadecimale.
+- `List`: Specifica un elenco di elementi. Ogni elemento deve specificare il suo tipo e i suoi dati.
+- `BigInt`: Specifica un valore intero di grandi dimensioni. Deve essere quotato a causa delle sue grandi dimensioni.
+
+Questo contesto è quindi accessibile nei file di mappatura dei subgraph, consentendo di ottenere subgraph più dinamici e configurabili.

From 3c2678a3441dd8000b9c029aa6fdb53c80bdde84 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:33 -0500
Subject: [PATCH 0785/3820] New translations common-issues.mdx (Italian)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/it/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/it/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..8d714dad8499
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Problemi comuni di AssemblyScript
+---
+
+Ci sono alcuni problemi [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) in cui è comune imbattersi durante lo sviluppo di subgraph. La loro difficoltà di debug è variabile, ma conoscerli può essere d'aiuto. Quello che segue è un elenco non esaustivo di questi problemi:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- L'ambito non è ereditato nelle [closure functions](https://www.assemblyscript.org/status.html#on-closures), cioè le variabili dichiarate al di fuori delle closure functions non possono essere utilizzate. Spiegazione in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 66443f51652d37af67beb1459bc73019e9afe9da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:34 -0500
Subject: [PATCH 0786/3820] New translations unit-testing-framework.mdx
 (Italian)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/it/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/it/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..2133c1d4b5c9
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Unit Testing Framework
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Getting Started
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+or
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+This will run all tests in the test folder:
+
+```sh
+graph test
+```
+
+This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
+
+```sh
+graph test gravity
+```
+
+This will run only that specific test file:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo subgraph
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Video tutorials
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+or
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Examples:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Example:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Examples:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Write a Unit Test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Assuming we have the following handler function (along with two helper functions to make our life easier):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+We first have to create a test file in our project. This is an example of how that might look like:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- We're setting up our initial state and adding one custom Gravatar entity;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- We assert the state of the store. How does that work? - We're passing a unique combination of Entity type and id. Then we check a specific field on that Entity and assert that it has the value we expect it to have. We're doing this both for the initial Gravatar Entity we added to the store, as well as the two Gravatar entities that gets added when the handler function is called;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+There we go - we've created our first test! 👏
+
+Now in order to run our tests you simply need to run the following in your subgraph root folder:
+
+`graph test Gravity`
+
+And if all goes well you should be greeted with the following:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Common test scenarios
+
+### Hydrating the store with a certain state
+
+Users are able to hydrate the store with a known set of entities. Here's an example to initialise the store with a Gravatar entity:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Calling a mapping function with an event
+
+A user can create a custom event and pass it to a mapping function that is bound to the store:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Calling all of the mappings with event fixtures
+
+Users can call the mappings with test fixtures.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocking contract calls
+
+Users can mock contract calls:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+As demonstrated, in order to mock a contract call and hardcore a return value, the user must provide a contract address, function name, function signature, an array of arguments, and of course - the return value.
+
+Users can also mock function reverts:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking IPFS files (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Asserting the state of the store
+
+Users are able to assert the final (or midway) state of the store through asserting entities. In order to do this, the user has to supply an Entity type, the specific ID of an Entity, a name of a field on that Entity, and the expected value of the field. Here's a quick example:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interacting with Event metadata
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Asserting variable equality
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Users can assert that an entity does not exist in the store. The function takes an entity type and an id. If the entity is in fact in the store, the test will fail with a relevant error message. Here's a quick example of how to use this functionality:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+You can print the whole store to the console using this helper function:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Expected failure
+
+Users can have expected test failures, using the shouldFail flag on the test() functions:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+If the test is marked with shouldFail = true but DOES NOT fail, that will show up as an error in the logs and the test block will fail. Also, if it's marked with shouldFail = false (the default state), the test executor will crash.
+
+### Logging
+
+Having custom logs in the unit tests is exactly the same as logging in the mappings. The difference is that the log object needs to be imported from matchstick-as rather than graph-ts. Here's a simple example with all non-critical log types:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Users can also simulate a critical failure, like so:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Logging critical errors will stop the execution of the tests and blow everything up. After all - we want to make sure you're code doesn't have critical logs in deployment, and you should notice right away if that were to happen.
+
+### Testing derived fields
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testing dynamic data sources
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Example below:
+
+First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+And then we have the test using one of the methods in the dataSourceMock namespace to set a new return value for all of the dataSource functions:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Notice that dataSourceMock.resetValues() is called at the end. That's because the values are remembered when they are changed and need to be reset if you want to go back to the default values.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Test Coverage
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Prerequisites
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Export your handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Usage
+
+Once that's all set up, to run the test coverage tool, simply run:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Test run time duration in the log output
+
+The log output includes the test run duration. Here's an example:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Common compiler errors
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Additional Resources
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Feedback
+
+If you have any questions, feedback, feature requests or just want to reach out, the best place would be The Graph Discord where we have a dedicated channel for Matchstick, called 🔥| unit-testing.

From bf28dc60a57508d134b37e3b9d11f156339263d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:35 -0500
Subject: [PATCH 0787/3820] New translations transferring-a-subgraph.mdx
 (Italian)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/it/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/it/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From d3073e33ab08cdb51338d088a6707a2a65919c67 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:36 -0500
Subject: [PATCH 0788/3820] New translations graphql-api.mdx (Italian)

---
 .../it/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/it/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/it/subgraphs/querying/graphql-api.mdx b/website/pages/it/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..52fbb7200072
--- /dev/null
+++ b/website/pages/it/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: API GraphQL
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Esempi
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Ordinamento
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Esempio
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Esempio di ordinamento di entità annidate
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Impaginazione
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Eseguire query di primi 10 token:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtraggio
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Esempio di filtraggio dell'intervallo
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Esempio di filtraggio dei blocchi
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+Questo può essere utile se si vuole recuperare solo le entità che sono cambiate, ad esempio dall'ultima volta che è stato effettuato il polling. In alternativa, può essere utile per indagare o fare il debug di come le entità stanno cambiando nel subgraph (se combinato con un filtro di blocco, è possibile isolare solo le entità che sono cambiate in un blocco specifico).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Esempio di filtraggio di entità annidate
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+Questo può essere utile se si vuole recuperare solo le entità il cui livello di figlio soddisfa le condizioni fornite.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Operatori logici
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### Tutti i filtri
+
+Elenco completo dei suffissi dei parametri:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Query Time-travel
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Esempio
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Esempio
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Query di ricerca fulltext
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Operatori di ricerca fulltext:
+
+| Simbolo | Operatore   | Descrizione                                                                                                                               |
+| ------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`     | `And`       | Per combinare più termini di ricerca in un filtro per le entità che includono tutti i termini forniti                                     |
+| |       | `Or`        | Le query con più termini di ricerca separati dall'operatore Or restituiranno tutte le entità con una corrispondenza tra i termini forniti |
+| `<->`   | `Follow by` | Specifica la distanza tra due parole.                                                                                                     |
+| `:*`    | `Prefix`    | Utilizzare il termine di ricerca del prefisso per trovare le parole il cui prefisso corrisponde (sono richiesti 2 caratteri.)             |
+
+#### Esempi
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combinare gli operatori fulltext per creare filtri più complessi. Con un operatore di ricerca pretext combinato con un follow by questa query di esempio corrisponderà a tutte le entità del blog con parole che iniziano con "lou" seguite da "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validazione
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entità
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Metadati del Subgraph
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+Se viene fornito un blocco, i metadati si riferiscono a quel blocco, altrimenti viene utilizzato il blocco indicizzato più recente. Se fornito, il blocco deve essere successivo al blocco iniziale del subgraph e inferiore o uguale al blocco indicizzato più recente.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: l'hash del blocco
+- numero: il numero del blocco
+- timestamp: il timestamp del blocco, se disponibile (attualmente è disponibile solo per i subgraph che indicizzano le reti EVM)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 079b61805e9e392eeced26d786210d339ad80988 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:37 -0500
Subject: [PATCH 0789/3820] New translations python.mdx (Italian)

---
 .../pages/it/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/it/subgraphs/querying/python.mdx

diff --git a/website/pages/it/subgraphs/querying/python.mdx b/website/pages/it/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..6468c62fc487
--- /dev/null
+++ b/website/pages/it/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds è una libreria Python intuitiva per query dei subgraph, realizzata da [Playgrounds](https://playgrounds.network/). Permette di collegare direttamente i dati dei subgraph a un ambiente dati Python, consentendo di utilizzare librerie come [pandas](https://pandas.pydata.org/) per eseguire analisi dei dati!
+
+Subgrounds offre una semplice API Pythonic per la creazione di query GraphQL, automatizza i flussi di lavoro più noiosi come la paginazione, e dà agli utenti avanzati la possibilità di effettuare trasformazioni controllate dello schema.
+
+## Getting Started
+
+Subgrounds richiede Python 3.10 o superiore ed è disponibile su [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Una volta installato, è possibile testare subgrounds con la seguente query. L'esempio seguente prende un subgraph per il protocollo Aave v2 e effettua query dei primi 5 mercati ordinati per TVL (Total Value Locked), seleziona il loro nome e il loro TVL (in USD) e restituisce i dati come pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+da subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Caricare il subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Costruire la query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Restituire la query a un dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentazione
+
+Subgrounds è costruito e mantenuto dal team di [Playgrounds](https://playgrounds.network/) e si può accedere su [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Poiché le funzionalità di subgrounds sono numerose e tutte da esplorare, ecco alcuni punti di partenza utili:
+
+- [Introduzione alle query](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - Un buon primo passo per costruire le query con subgrounds.
+- [Costruire campi sintetici](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - Una leggera introduzione alla definizione di campi sintetici che trasformano i dati definiti dallo schema.
+- [Query concorrenti](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Imparate a migliorare le vostre query parallelizzandole.
+- [Esportazione di dati in CSV](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From a949b50cbd7843a8516314c7e2e6a26ea5092423 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:38 -0500
Subject: [PATCH 0790/3820] New translations triggers.mdx (Italian)

---
 website/pages/it/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/it/substreams/sps/triggers.mdx

diff --git a/website/pages/it/substreams/sps/triggers.mdx b/website/pages/it/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/it/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From f37a8fd516a1e83f84d005ecaa89e9edd080fc5b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:39 -0500
Subject: [PATCH 0791/3820] New translations overview.mdx (Japanese)

---
 website/pages/ja/indexing/overview.mdx | 820 +++++++++++++++++++++++++
 1 file changed, 820 insertions(+)
 create mode 100644 website/pages/ja/indexing/overview.mdx

diff --git a/website/pages/ja/indexing/overview.mdx b/website/pages/ja/indexing/overview.mdx
new file mode 100644
index 000000000000..aed98f39d428
--- /dev/null
+++ b/website/pages/ja/indexing/overview.mdx
@@ -0,0 +1,820 @@
+---
+title: Indexing Overview
+---
+
+インデクサーは、The Graph Network内のノードオペレーターであり、インデックス化とクエリ処理のサービスを提供するためにGraph Token（GRT）をステークします。インデクサーは、そのサービスに対するクエリ料金とインデックスリワードを獲得します。また、指数的なリベート関数に従ってリベートされるクエリ料金も獲得します。
+
+プロトコルにステークされた GRT は解凍期間が設けられており、インデクサーが悪意を持ってアプリケーションに不正なデータを提供したり、不正なインデックスを作成した場合には、スラッシュされる可能性があります。 また、インデクサーはデリゲーターからステークによる委任を受けて、ネットワークに貢献することができます。
+
+インデクサ − は、サブグラフのキュレーション・シグナルに基づいてインデックスを作成するサブグラフを選択し、キュレーターは、どのサブグラフが高品質で優先されるべきかを示すために GRT をステークします。 消費者（アプリケーションなど）は、インデクサーが自分のサブグラフに対するクエリを処理するパラメータを設定したり、クエリフィーの設定を行うこともできます。
+
+<Difficulty level="ADVANCED" />
+
+## よくある質問
+
+### ネットワーク上のインデクサーになるために必要な最低ステーク量はいくらですか？
+
+インデクサーの最低ステーク量は、現在 100K GRT に設定されています。
+
+### インデクサーの収入源は何ですか？
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### インデキシングリワードはどのように配布されますか？
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### POI（proof of indexing）とは何ですか？
+
+POI は、インデクサーが割り当てられたサブグラフにインデックスを作成していることを確認するためにネットワークで使用されます。 現在のエポックの最初のブロックに対する POI は、割り当てを終了する際に提出しなければ、その割り当てはインデックス報酬の対象となりません。 あるブロックの POI は、そのブロックまでの特定のサブグラフのデプロイに対するすべてのエンティティストアのトランザクションのダイジェストです。
+
+### インデキシングリワードはいつ配布されますか？
+
+割り当ては、それがアクティブである間、継続的に報酬を発生させます。 報酬はインデクサによって集められ、割り当てが終了するたびに分配されます。 これは、インデクサーが強制的に閉じようとしたときに手動で行うか、28 エポックの後にデリゲーターがインデクサーのために割り当てを終了することができますが、この場合は報酬がミントされません。 28 エポックは最大の割り当て期間です（現在、1 エポックは約 24 時間です）
+
+### 保留中のインデクサーの報酬は監視できますか？
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+コミュニティが作成したダッシュボードの多くには保留中の報酬値が含まれており、次の手順に従って手動で簡単に確認できます。
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### 争議（disputes）とは何で、どこで見ることができますか？
+
+インデクサークエリとアロケーションは、期間中に The Graph 上で争議することができます。 争議期間は、争議の種類によって異なります。 クエリ/裁定には 7 エポックスの紛争窓口があり、割り当てには 56 エポックスがあります。 これらの期間が経過した後は、割り当てやクエリのいずれに対しても紛争を起こすことはできません。 紛争が開始されると、Fishermen は最低 10,000GRT のデポジットを要求され、このデポジットは紛争が最終的に解決されるまでロックされます。 フィッシャーマンとは、紛争を開始するネットワーク参加者のことです。
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- 争議が却下された場合、フィッシャーマンが預かった GRT はバーンされ、争議中のインデクサーはスラッシュされません。
+- 争議が引き分けた場合、フィッシャーマンのデポジットは返還され、争議中のインデクサーはスラッシュされることはありません。
+- 争議が受け入れられた場合、フィッシャーマンがデポジットした GRT は返却され、争議中のインデクサーはスラッシュされ、フィッシャーマンはスラッシュされた GRT の 50%を獲得します。
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### クエリフィーリベートとは何ですか、またいつ配布されますか？
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+割り当てが閉じられると、リベートはインデクサーによって請求されることができるようになります。請求されると、クエリ料金のリベートは、クエリ料金のカットと指数的なリベート関数に基づいて、インデクサーとその委任者に分配されます。
+
+### クエリフィーカットとインデキシングリワードカットとは？
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### インデクサーはどのサブグラフにインデックスを付けるかをどう見分けるのですか？
+
+インデクサーは、サブグラフのインデキシングの決定に高度な技術を適用することで差別化を図ることができますが、一般的な考え方として、ネットワーク内のサブグラフを評価するために使用されるいくつかの主要な指標について説明します。
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### 必要なハードウェアは何ですか？
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- | :------------------: | :---------------------------: | :-------------------------: | :-------------: | :----------------------: |
+| Small    |           4          |               8               |              1              |        4        |            16            |
+| Standard |           8          |               30              |              1              |        12       |            48            |
+| Medium   |          16          |               64              |              2              |        32       |            64            |
+| Large    |          72          |              468              |             3.5             |        48       |            184           |
+
+### インデクサーが取るべきセキュリティ対策は？
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## インフラストラクチャ
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+注: アジャイルなスケーリングをサポートするには、クエリとインデックス作成の懸念事項を異なるノード セット (クエリ ノードとインデックス ノード) に分けることをお勧めします。
+
+### ポートの概要
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### グラフノード
+
+| Port | Purpose                                           | Routes                                           | CLI Argument       | Environment Variable |
+| ---- | ------------------------------------------------- | ------------------------------------------------ | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> /subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS <br /> (for subgraph subscriptions)    | /subgraphs/id/... <br /> /subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC <br /> (for managing deployments)        | /                                                | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                      | /graphql                                         | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                                | /metrics                                         | \--metrics-port    | -                    |
+
+#### Indexer Service
+
+| Port | Purpose                                                | Routes                                                          | CLI Argument    | Environment Variable   |
+| ---- | ------------------------------------------------------ | --------------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP server <br /> (for paid subgraph queries) | /subgraphs/id/... <br /> /status <br /> /channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                     | /metrics                                                        | \--metrics-port | -                      |
+
+#### Indexer Agent
+
+| Port | Purpose                | Routes | CLI Argument               | Environment Variable                    |
+| ---- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | Indexer management API | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Google Cloud で Terraform を使ってサーバーインフラを構築
+
+> 注：インデクサーは、AWS、Microsoft Azure、Alibabaを代替的に使用することができます。
+
+#### インストールの前提条件
+
+- Google Cloud SDK
+- Kubectl コマンドラインツール
+- Terraform
+
+#### Google Cloud プロジェクトの作成
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Google Cloud で認証し、新しいプロジェクトを作成
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Google Cloud Console の\[billing page\](課金ページ) を使用して、新しいプロジェクトの課金を有効にします。
+
+- Google Cloud の設定を作成します。
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Google Cloud API の設定
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- サービスアカウントを作成
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- データベースと次のステップで作成する Kubernetes クラスター間のピアリングを有効化
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.' gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Terraform 設定ファイルを作成（必要に応じて更新してください）
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Terraform を使ってインフラを構築
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- 以下のコマンドを実行して、インフラを作成します。
+
+```sh
+# 必要なプラグインのインストール
+terraform init
+
+# 作成されるリソースのプランを見る
+terraform plan
+
+# リソースの作成（最大で30分程度かかる見込みです）
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### インデクサー用の Kubernetes コンポーネントの作成
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### グラフノード
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### ソースからのスタート
+
+#### インストールの前提条件
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. PostgreSQL データベースサーバを起動します。
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. 全ての依存関係の設定が完了したら、グラフノードを起動します:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Docker の使用
+
+#### 前提条件
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Setup
+
+1. Graph Node をクローンし、Docker ディレクトリに移動します。
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Ethereum のエンドポイントに接続し、ローカルの Graph Node を起動します:
+
+```sh
+docker-compose up
+```
+
+### インデクサーコンポーネント
+
+ネットワークへの参加を成功させるためには、ほぼ常に監視と対話を行う必要があるため、Indexers のネットワークへの参加を促進するための一連の Typescript アプリケーションを構築しました。 インデクサーには 3 つのコンポーネントがあります:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### はじめに
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### NPM パッケージから
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### ソースから
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Docker の使用
+
+- レジストリからイメージを引き出す
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+または、ソースからローカルにイメージをビルドします
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- コンポーネントの実行
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### K8s と Terraform の使用
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### 使い方
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### インデクサーエージェント
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### インデクサーサービス
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### インデクサー CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Indexer CLI によるインデクサー管理
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### 使い方
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### インデキシングルール
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+データモデル
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+インデックスルールの使用例：
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### アクションキュー CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- サードパーティのオプティマイザツールやindexer-cliのユーザーによってキューに追加されたアクション
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- インデクサーはアクションキューを監視してアクションの実行履歴を確認し、必要であれば、実行に失敗したアクションアイテムを再承認して更新することができます。アクションキューは、キューに入れられ、実行されたすべてのアクションの履歴を提供します。
+
+データモデル
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+ソースからの使用例：
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+割り当て管理でサポートされるアクションタイプは、入力要件が異なることに注意してください。
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - 必要なアクションパラメータを指定します:
+    - デプロイメントID
+    - 量
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - 必要なアクションパラメータを指定します:
+    - アロケーションID
+    - デプロイメントID
+  - 任意のアクションパラメータ：
+    - poi
+    - force (グラフノードが提供するものと一致しなくても、提供されたPOIを使用することを強制する)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - 必要なアクションパラメータを指定します:
+    - アロケーションID
+    - デプロイメントID
+    - 量
+  - 任意のアクションパラメータ：
+    - poi
+    - force (グラフノードが提供するものと一致しなくても、提供されたPOIを使用することを強制する)
+
+#### コストモデル
+
+コストモデルは、マーケットやクエリ属性に基づいて、クエリの動的な価格設定を行います。 インデクサーサービスは、クエリに応答する予定の各サブグラフのコストモデルをゲートウェイと共有します。 一方、ゲートウェイはコストモデルを使用して、クエリごとにインデクサーの選択を決定し、選択されたインデクサーと支払いの交渉を行います。
+
+#### Agora
+
+Agora 言語は、クエリのコストモデルを宣言するための柔軟なフォーマットを提供します。 Agora のコストモデルは、GraphQL クエリのトップレベルのクエリごとに順番に実行される一連のステートメントです。 各トップレベルのクエリに対して、それにマッチする最初のステートメントがそのクエリの価格を決定します。
+
+ステートメントは、GraphQL クエリのマッチングに使用される述語と、評価されると decimal GRT でコストを出力するコスト式で構成されます。 クエリの名前付き引数の位置にある値は、述語の中に取り込まれ、式の中で使用されます。 また、グローバルを設定し、式のプレースホルダーとして代用することもできます。
+
+コストモデルの例:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+上記のモデルを使用したクエリのコスト計算の例:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### コストモデルの適用
+
+コストモデルは Indexer CLI を通じて適用され、それをインデクサー・エージェントの Indexer Management API に渡してデータベースに格納します。 その後、インデクサーサービスがこれを受け取り、ゲートウェイから要求があるたびにコスト・モデルを提供します。
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## ネットワークとのインタラクション
+
+### プロトコルへのステーク
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### トークンの承認
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### トークンをステークする
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### アロケーションの寿命
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 7333190be440e51338f9d60cd42c841972d3a41c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:40 -0500
Subject: [PATCH 0792/3820] New translations tap.mdx (Japanese)

---
 website/pages/ja/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/ja/indexing/tap.mdx

diff --git a/website/pages/ja/indexing/tap.mdx b/website/pages/ja/indexing/tap.mdx
new file mode 100644
index 000000000000..b1d43a4e628c
--- /dev/null
+++ b/website/pages/ja/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## 概要
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### 要件
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+注：
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From 9ae490584d7ede28c08c84c02c9ea0ff9006c17a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:41 -0500
Subject: [PATCH 0793/3820] New translations graph-node.mdx (Japanese)

---
 .../pages/ja/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/ja/indexing/tooling/graph-node.mdx

diff --git a/website/pages/ja/indexing/tooling/graph-node.mdx b/website/pages/ja/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..bd3c64e30901
--- /dev/null
+++ b/website/pages/ja/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: グラフノード
+---
+
+グラフノードはサブグラフのインデックスを作成し、得られたデータをGraphQL API経由でクエリできるようにするコンポーネントです。そのため、インデクサースタックの中心的存在であり、グラフノードの正しい動作はインデクサーを成功させるために非常に重要です。
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## グラフノード
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQLデータベース
+
+グラフノードのメインストアで、サブグラフデータ、サブグラフに関するメタデータ、ブロックキャッシュやeth_callキャッシュなどのサブグラフに依存しないネットワークデータが格納されます。
+
+### ネットワーククライアント
+
+ネットワークにインデックスを付けるために、グラフ ノードは EVM 互換の JSON-RPC API を介してネットワーク クライアントにアクセスする必要があります。この RPC は単一のクライアントに接続する場合もあれば、複数のクライアントに負荷を分散するより複雑なセットアップになる場合もあります。
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFSノード
+
+IPFS ノード（バージョン  未満） - サブグラフのデプロイメタデータは IPFS ネットワーク上に保存されます。 グラフノードは、サブグラフのデプロイ時に主に IPFS ノードにアクセスし、サブグラフマニフェストと全てのリンクファイルを取得します。 ネットワーク・インデクサーは独自の IPFS ノードをホストする必要はありません。 ネットワーク用の IPFS ノードは、https://ipfs.network.thegraph.com でホストされています。
+
+### Prometheus メトリクスサーバー
+
+監視とレポート作成を可能にするため、Graph NodeはオプションでPrometheusのメトリクスサーバーにメトリクスを記録することができます。
+
+### ソースからのスタート
+
+#### インストールの前提条件
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. PostgreSQL データベースサーバを起動します。
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. 全ての依存関係の設定が完了したら、グラフノードを起動します:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Kubernetesを始めるにあたって
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Port
+
+グラフノードは起動時に以下のポートを公開します。
+
+| Port | Purpose                                           | Routes                                           | CLI Argument       | Environment Variable |
+| ---- | ------------------------------------------------- | ------------------------------------------------ | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server <br /> (for subgraph queries) | /subgraphs/id/... <br /> /subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS <br /> (for subgraph subscriptions)    | /subgraphs/id/... <br /> /subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC <br /> (for managing deployments)        | /                                                | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                      | /graphql                                         | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                                | /metrics                                         | \--metrics-port    | -                    |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## グラフノードの高度な設定
+
+最も単純な場合、Graph Node は、Graph Node の単一のインスタンス、単一の PostgreSQL データベース、IPFS ノード、およびサブグラフのインデックス作成に必要なネットワーク クライアントで操作できます。
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> 設定ファイルを使用する場合、-postgres-url、-postgres-secondary-hosts、および --postgres-host-weights オプションを使用することはできません。
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### 複数のグラフノード
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> なお、複数のGraph Nodeはすべて同じデータベースを使用するように設定することができ、Shardingによって水平方向に拡張することができます。
+
+#### デプロイメントルール
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+デプロイメントルールの設定例：
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### 専用クエリノード
+
+設定ファイルに以下を記述することで、ノードを明示的にクエリノードに設定することができます。
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+正規表現に --node-id がマッチするノードは、クエリーにのみ応答するように設定されます。
+
+#### シャーディングによるデータベースのスケーリング
+
+ほとんどの場合、1つのPostgresデータベースでグラフノードインスタンスをサポートするのに十分です。グラフノードインスタンスが1つのPostgresデータベースを使い切った場合、グラフノードデータを複数のPostgresデータベースに分割して保存することが可能です。全てのデータベースが一緒になってグラフノードインスタンスのストアを形成します。個々のデータベースはシャード（shard）と呼ばれます。
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+グラフノードの負荷に既存のデータベースが追いつかず、これ以上データベースサイズを大きくすることができない場合に、シャーディングが有効になります。
+
+> 一般的には、シャードを作成する前に、単一のデータベースを可能な限り大きくすることをお勧めします。例外は、クエリのトラフィックがサブグラフ間で非常に不均一に分割される場合です。このような状況では、ボリュームの大きいサブグラフを1つのシャードに、それ以外を別のシャードに保存すると劇的に効果があります。この設定により、ボリュームの大きいサブグラフのデータがdb内部キャッシュに残り、ボリュームの小さいサブグラフからそれほど必要とされていないデータに置き換えられる可能性が少なくなるためです。
+
+接続の設定に関しては、まずpostgresql.confのmax_connectionsを400（あるいは200）に設定し、store_connection_wait_time_msとstore_connection_checkout_count Prometheusメトリクスを見てみてください。顕著な待ち時間(5ms以上)は、利用可能な接続が少なすぎることを示しています。高い待ち時間は、データベースが非常に忙しいこと(CPU負荷が高いなど)によっても引き起こされます。しかし、データベースが安定しているようであれば、待ち時間が長いのは接続数を増やす必要があることを示しています。設定上、各グラフノードインスタンスが使用できるコネクション数は上限であり、グラフノードは必要ないコネクションはオープンにしておきません。
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### 専用ブロックインジェスト
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### 複数のネットワークに対応
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- 複数のネットワーク
+- ネットワークごとに複数のプロバイダ（プロバイダ間で負荷を分割することができ、また、フルノードとアーカイブノードを構成することができ、作業負荷が許す限り、Graph Nodeはより安価なプロバイダを優先することができます）。
+- 機能、認証、プロバイダの種類など、プロバイダの詳細（実験的なFirehoseのサポートのため）
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### 環境変数について
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### 継続的なデプロイ
+
+高度な構成でスケーリングされたインデックス作成セットアップを運用しているユーザーは、Kubernetes を使用してグラフ ノードを管理することでメリットが得られる場合があります。
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### グラフノードの管理
+
+グラフノードが動作している場合、それらのノードに展開されたサブグラフを管理することが課題となります。グラフノードは、サブグラフを管理するための様々なツールを提供します。
+
+#### ロギング
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+グラフノードは、デフォルトで8040ポートのPrometheusエンドポイント経由でメトリクスを提供します。そして、Grafanaを使用してこれらのメトリクスを可視化することができます。
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### サブグラフの操作
+
+#### インデックスステータスAPI
+
+デフォルトではポート8030/graphqlで利用可能なindexing status APIは、異なるサブグラフのindexing statusのチェック、indexing proofのチェック、サブグラフの特徴の検査など、様々なメソッドを公開しています。
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### インデックスのパフォーマンス
+
+インデックス作成は、3つのパートに分かれています：
+
+- プロバイダから興味のあるイベントを取得
+- 適切なハンドラで順番にイベントを処理する（これには、状態のためにチェーンを呼び出したり、ストアからデータを取得したりすることが含まれます）。
+- 出来上がったデータをストアに書き込む
+
+これらのステージはパイプライン化されていますが（つまり、並列に実行することができます）、互いに依存し合っています。サブグラフのインデックス作成に時間がかかる場合、その根本的な原因は、特定のサブグラフに依存します。
+
+インデックス作成が遅くなる一般的な原因：
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- 実行中に大量のストアインタラクションが発生
+- ストアに保存するデータ量が多い場合
+- 処理するイベントの数が多い場合
+- データベースへの接続時間が遅い（混雑したノード）
+- プロバイダー自体がチェーンヘッドに遅れる場合
+- チェーンヘッドでプロバイダーから新しいレシートを取得する際の遅延
+
+サブグラフのインデックス作成指標は、インデックス作成の遅さの根本的な原因を診断するのに役立ちます。あるケースでは、問題はサブグラフ自体にありますが、他のケースでは、ネットワークプロバイダーの改善、データベースの競合の減少、その他の構成の改善により、インデックス作成性能を著しく向上させることができます。
+
+#### 失敗したサブグラフ
+
+インデックス作成中、サブグラフは予期しないデータに遭遇したり、あるコンポーネントが期待通りに動作しなかったり、イベントハンドラや設定に何らかのバグがあったりすると、失敗することがあります。失敗には一般に2つのタイプがあります。
+
+- 決定論的失敗：再試行では解決できない失敗
+- 非決定論的失敗：プロバイダの問題や、予期しないグラフノードのエラーに起因する可能性があります。非決定論的失敗が発生すると、グラフノードは失敗したハンドラを再試行し、時間をかけて後退させます。
+
+いくつかのケースでは、失敗はインデクサーによって解決できるかもしれません（例えば、エラーが正しい種類のプロバイダを持っていない結果である場合、必要なプロバイダを追加することでインデックス作成を継続することが可能になります）。しかし、サブグラフのコードを変更する必要がある場合もあります。
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### ブロックキャッシュとコールキャッシュ
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+TX受信欠落イベントなど、ブロックキャッシュの不整合が疑われる場合。
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. ブロックがプロバイダに一致する場合、問題はプロバイダに対して直接デバッグすることができます。
+
+#### 問題やエラーのクエリ
+
+サブグラフがインデックス化されると、インデクサはサブグラフの専用クエリエントポイントを介してクエリを提供することが期待できます。もしインデクサがかなりの量のクエリを提供することを望むなら、専用のクエリノードを推奨します。また、クエリ量が非常に多い場合、インデクサーはレプリカシャードを構成して、クエリがインデックス作成プロセスに影響を与えないようにしたいと思うかもしれません。
+
+ただし、専用のクエリ ノードとレプリカを使用しても、特定のクエリの実行に時間がかかる場合があり、場合によってはメモリ使用量が増加し、他のユーザーのクエリ時間に悪影響を及ぼします。
+
+「銀の弾丸」は一つではなく、遅いクエリを防止、診断、対処するための様々なツールがあります。
+
+##### クエリキャッシング
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### クエリの分析
+
+問題のあるクエリが表面化するのは、ほとんどの場合、次の2つの方法のどちらかです。あるケースでは、ユーザー自身があるクエリが遅いと報告します。この場合、一般的な問題なのか、そのサブグラフやクエリに固有の問題なのか、遅さの理由を診断することが課題となります。そしてもちろん、可能であればそれを解決することです。
+
+また、クエリノードでメモリ使用量が多いことが引き金になる場合もあり、その場合は、まず問題の原因となっているクエリを特定することが課題となります。
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+クエリが遅い場合、インデクサーにはいくつかのオプションがあります。もちろん、コスト モデルを変更して、問題のあるクエリを送信するコストを大幅に増やすことができます。これにより、そのクエリの頻度が減少する可能性があります。ただし、これでは問題の根本原因が解決しないことがよくあります。
+
+##### アカウントライクな最適化
+
+エンティティを格納するデータベーステーブルには、一般に2つの種類があるようです。エンティティは一度作成されると更新されない「トランザクションライク」なもの、 つまり金融取引のリストのようなものを格納するものと、エンティティが頻繁に更新される「アカウント ライク」なもの、つまり取引が記録されるたびに変更される金融口座のようなものを格納するものである。口座のようなテーブルの特徴は、多くのバージョンの実体を含むが、異なる実体は 比較的少ないということである。このようなテーブルでは、別個のエンティティの数は行（エンティティバージョン）の総数の1%であることがよくある。
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### サブグラフの削除
+
+> これは新しい機能で、Graph Node 0.29.xで利用可能になる予定です。
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From eccccf203d54035742231095491fab43080fb8cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:43 -0500
Subject: [PATCH 0794/3820] New translations advanced.mdx (Japanese)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/ja/subgraphs/developing/creating/advanced.mdx b/website/pages/ja/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..a53e473f71ba
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## 概要
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## 致命的でないエラー
+
+すでに同期しているサブグラフのインデックスエラーは、デフォルトではサブグラフを失敗させ、同期を停止させます。サブグラフは、エラーが発生したハンドラーによる変更を無視することで、エラーが発生しても同期を継続するように設定することができます。これにより、サブグラフの作成者はサブグラフを修正する時間を得ることができ、一方でクエリは最新のブロックに対して提供され続けますが、エラーの原因となったバグのために結果が一貫していない可能性があります。なお、エラーの中には常に致命的なものもあり、致命的でないものにするためには、そのエラーが決定論的であることがわかっていなければなりません。
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+非致命的エラーを有効にするには、サブグラフのマニフェストに以下の機能フラグを設定する必要があります:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - fullTextSearch
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+ファイルデータソースは、堅牢で拡張可能な方法でインデックス作成中にオフチェーンデータにアクセスするための新しいサブグラフ機能です。ファイルデータソースは、IPFS および Arweave からのファイルのフェッチをサポートしています。
+
+> また、オフチェーンデータの決定論的なインデックス作成、および任意のHTTPソースデータの導入の可能性についても基礎ができました。
+
+### 概要
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### アップグレードガイド
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### ファイルが見つかったときに更新される新しいエンティティタイプを追加します。
+
+ファファイルが見つかったときに更新される新しいエンティティタイプを追加します。イルデータソースは、チェーンベースのエンティティにアクセスしたり更新することはできませんが、ファイル固有のエンティティを更新する必要があります。
+
+これは、既存のエンティティからフィールドを分離し、別のエンティティにリンクさせることを意味します。
+
+Original combined entity：
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+New, split entity：
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+親エンティティと結果のファイルデータソースエンティティの間の関係が1：1である場合、最も単純なパターンは、IPFS CIDをルックアップとして使用して、親エンティティを結果のファイルエンティティにリンクすることです。新しいファイルベースのエンティティのモデリングに問題がある場合は、Discordに連絡してください。
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+目的のファイルが特定されたときに生成されるデータソースです。
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### ファイルを処理するハンドラーを新規に作成
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+ハンドラーの例：
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### 必要なときにファイルデータソースを起動する
+
+チェーンベースハンドラーの実行中に、ファイルデータソースを作成できるようになりました：
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+例：
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+これにより、新しいファイル データ ソースが作成され、グラフ ノードの構成済み IPFS または Arweave エンドポイントがポーリングされ、見つからない場合は再試行されます。ファイルが見つかると、ファイルデータソースハンドラが実行されます。
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+おめでとうございます！ファイルデータソースが使用できます。
+
+#### サブグラフのデプロイ
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### 制限事項
+
+ファイルデータソースハンドラおよびエンティティは、他のサブグラフエンティティから分離され、実行時に決定論的であることを保証し、チェーンベースのデータソースを汚染しないことを保証します。具体的には、以下の通りです。
+
+- ファイルデータソースで作成されたエンティティは不変であり、更新することはできません。
+- ファイルデータソースハンドラは、他のファイルデータソースのエンティティにアクセスすることはできません。
+- ファイルデータソースに関連するエンティティは、チェーンベースハンドラーからアクセスできません。
+
+> この制約は、ほとんどのユースケースで問題になることはありませんが、一部のユースケースでは複雑さをもたらすかもしれません。ファイルベースのデータをサブグラフでモデル化する際に問題がある場合は、Discordを通じてご連絡ください。
+
+また、オンチェーンデータソースや他のファイルデータソースからデータソースを作成することはできません。この制限は、将来的に解除される可能性があります。
+
+#### ベストプラクティス
+
+NFT メタデータを対応するトークンにリンクする場合、メタデータの IPFS ハッシュを使用して、トークン エンティティから Metadata エンティティを参照します。IPFSハッシュをIDとして使用してMetadataエンティティを保存します。
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> クエリが「最新版」のみを返すように、上記の推奨事項を改善するよう取り組んでいます。
+
+#### 既知の問題点
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### 例
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### 参考文献
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### 既存のサブグラフへのグラフト
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+グラフトはベースデータのインデックスではなくコピーを行うため、スクラッチからインデックスを作成するよりもサブグラフを目的のブロックに早く到達させることができますが、非常に大きなサブグラフの場合は最初のデータコピーに数時間かかることもあります。グラフトされたサブグラフが初期化されている間、グラフノードは既にコピーされたエンティティタイプに関する情報を記録します。
+
+グラフト化されたサブグラフは、ベースとなるサブグラフのスキーマと同一ではなく、単に互換性のある GraphQL スキーマを使用することができます。また、それ自体は有効なサブグラフのスキーマでなければなりませんが、以下の方法でベースサブグラフのスキーマから逸脱することができます。
+
+- エンティティタイプを追加または削除する
+- エンティティタイプから属性を削除する
+- 属性を追エンティティタイプに nullable加する
+- null 化できない属性を null 化できる属性に変更する
+- enums に値を追加する
+- インターフェースの追加または削除
+- インターフェースがどのエンティティタイプに実装されるかを変更する
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 8d9934ee469901817d1afceca65a6fdaf1c65836 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:44 -0500
Subject: [PATCH 0795/3820] New translations api.mdx (Japanese)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/ja/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/ja/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..9fdb7beadc1e
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API リファレンス
+
+@graphprotocol/graph-tsライブラリは、以下の API を提供しています:
+
+- Ethereum スマートコントラクト、イベント、ブロック、トランザクション、Ethereum の値を扱うためのethereumAPI
+- エンティティをグラフノードのストアからロードしたり、ストアに保存したりするstoreAPI
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- IPFS からファイルをロードするipfsAPI
+- JSON データを解析するためのjsonAPI
+- 暗号機能を使用するためのcryptoAPI
+- Ethereum、JSON、GraphQL、AssemblyScript など、異なるタイプのシステム間で変換するための低レベルプリミティブ
+
+### バージョン
+
+サブグラフマニフェストapiVersionは、特定のサブグラフのマッピングAPIバージョンを指定します。このバージョンは、Graph Nodeによって実行されます。
+
+| バージョン | リリースノート                                                                                                                                                                                                                                                  |
+| :---: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+| 0.0.7 | Ethereum タイプに `TransactionReceipt` と `Log` クラスを追加<br /> Ethereum Event オブジェクトに `receipt` フィールドを追加。                                                                                                                                                       |
+| 0.0.6 | Ethereum Transactionオブジェクトに`nonce`フィールドを追加<br /> Ethereum Blockオブジェクトに`baseFeePerGas`を追加。                                                                                                                                                                |
+| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+| 0.0.4 | Ethereum SmartContractCall オブジェクトにfunctionSignatureフィールドを追加                                                                                                                                                                                              |
+| 0.0.3 | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+| 0.0.2 | Ethereum Transaction オブジェクトに inputフィールドを追加                                                                                                                                                                                                               |
+
+### 組み込み型
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+以下の追加型は@graphprotocol/graph-tsで提供されています。
+
+#### バイト配列
+
+```typescript
+'@graphprotocol/graph-ts'から{ ByteArray } をインポートします。
+```
+
+ByteArrayは、u8の配列を表します。
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- fromHexString(hex:: 文字列)： ByteArray` - 入力長は偶数でなければなりません。0x`のプレフィックスはオプションとなります。
+
+_Type conversions_
+
+- `toHexString(): string` - `0x` を先頭に持つ 16 進文字列に変換します。
+- `toString(): string` - バイトを UTF-8 文字列として解釈します。
+- `toBase58(): string` - バイトをbase58の文字列にエンコードします。
+- `toU32(): u32` - バイトをリトルエンディアンの `u32` として解釈し、オーバーフローした場合にスローします。
+- `toI32(): i32` - バイト配列をリトルエンディアンの `i32` として解釈し、オーバーフローした場合にスローします。
+
+_Operators_
+
+- equals(y: ByteArray): bool`-`x == y\` と書くことができます。
+- `concat(other: ByteArray) ： ByteArray` - `this` に `other` を直接続けた `ByteArray` を返します。
+- `concatI32(other: i32) : ByteArray` - `this` に `other` のバイト表現を直接続けた `ByteArray` を返します。
+
+#### BigDecimal
+
+```typescript
+'@graphprotocol/graph-ts'から { BigDecimal } をインポートします。
+```
+
+BigDecimalは、任意の精度の小数を表現するために使用されます。
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` - `BigInt` から `BigDecimal` を生成します。
+- `static fromString(s: string)： BigDecimal` - 10進数の文字列をパースします。
+
+_Type conversions_
+
+- toString(): string\` - 10進数の文字列を表示します。
+
+_Math_
+
+- `plus(y: BigDecimal)： BigDecimal` - `x + y` と書くことができます。
+- `minus(y: BigDecimal)： BigDecimal` - `x + y` と書くことができます。
+- `times(y: BigDecimal)： BigDecimal` - `x + y` と書くことができます。
+- div(y: BigDecimal)： BigDecimal`-`x / y\` と書くことができます。
+- equals(y: BigDecimal): bool`-`x == y\` と書くことができます。
+- notEqual(y: BigDecimal): bool`-`x != y\` と書くことができます。
+- lt(y: BigDecimal): bool`-`x < y\` と書くことができます。
+- `le(y: BigDecimal): bool` - `x <= y` と書くことができます。
+- `gt(y: BigDecimal): bool` と書くことができます。
+- `ge(y: BigDecimal): bool`と書くことができます。
+- `neg()： BigDecimal` - `-x` と書くことができます。
+
+#### BigInt
+
+```typescript
+'@graphprotocol/graph-ts'から { BigInt } をインポートします。
+```
+
+`BigInt` は大きな整数を表現するために使用されます。これには `uint32` から `uint256` と `int64` から `int256` 型のイーサリアムの値が含まれます。uint32`以下の値、例えば`int32`、`uint24`、`int8`は全て`i32\` として表現されます。
+
+BigIntクラスの API は以下の通りです。
+
+_Construction_
+
+- `BigInt.fromI32(x: i32)： BigInt` - `i32` から `BigInt` を作成すします。
+
+- `BigInt.fromString(s: string)： BigInt`- 文字列から `BigInt` をパースします。
+
+- `BigInt.fromUnsignedBytes(x: Bytes)： BigInt` - `bytes` を符号なし、リトルエンディアンの整数として解釈します。入力がビッグエンディアンの場合は、最初に `.reverse()` を呼び出します。
+
+- `BigInt.fromSignedBytes(x: Bytes)： BigInt` - `bytes` を符号付きのリトルエンディアン整数として解釈します。入力がビッグエンディアンの場合は、最初に `.reverse()` を呼び出します。
+
+  _Type conversions_
+
+- `x.toHex(): string` - `BigInt` を16進数の文字列に変換します。
+
+- `x.toString(): string` - `BigInt` を10進数の文字列に変換します。
+
+- `x.toI32(): i32` - `BigInt` を `i32` として返す。値が `i32` に収まらない場合は失敗します。まず `x.isI32()` をチェックするのが良いでしょう。
+
+- `x.toBigDecimal()： BigDecimal` - 小数部のない10進数に変換します。
+
+_Math_
+
+- `x.plus(y: BigInt)： BigInt` - `x + y` と書くことができます。
+- `x.minus(y: BigInt)： BigInt` - `x - y` と書くことができます。
+- `x.times(y: BigInt)： BigInt` - `x * y` と書くことができます。
+- `x.div(y: BigInt)： BigInt` - `x / y` と書くことができます。
+- `x.mod(y: BigInt)： BigInt` - `x % y` と書くことができます。
+- `x.equals(y: BigInt): bool - x == y` と書くことができます。
+- `x.notEqual(y: BigInt): bool - x = y` と書くことができます。
+- `x.lt(y: BigInt): bool - x < y` と書くことができます。
+- `x.le(y: BigInt): bool - x <= y` と書くことができます。
+- `x.gt(y: BigInt): bool - x > y` と書くことができます。
+- `x.ge(y: BigInt): bool - x >= y` と書くことができます。
+- `x.neg()： BigInt - -x` と書くことができます。
+- `x.divDecimal(y: BigDecimal)： BigDecimal` - 小数点で割り、10進数の結果を返します。
+- `x.isZero(): bool` - 数がゼロかどうかをチェックするための便利な関数です。
+- `x.isI32(): bool` - 数が `i32` に収まるかどうかを調べます。
+- x.abs(): BigInt\` - 絶対値。
+- `x.pow(exp: u8): BigInt` - 指数。
+- `bitOr(x: BigInt, y: BigInt)： BigInt` - `x | y` と書くことができます。
+- `bitAnd(x: BigInt, y: BigInt): BigInt` - `x & y` と書くことができます。
+- `leftShift(x: BigInt, bits: u8): BigInt` - `x << y` と書くことができます。
+- `rightShift(x: BigInt, bits: u8): BigInt` - `x >> y` と書くことができます。
+
+#### TypedMap
+
+```typescript
+'@graphprotocol/graph-ts'から { TypedMap } をインポートします。
+```
+
+`TypedMap`はキーと値のペアを格納するために使用することができます。この例](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51)を参照してください。
+
+`TypedMap`クラスは以下のAPIを持っています：
+
+- `new TypedMap<K, V>()` - `K` 型のキーと `V` 型の値を持つ空のマップを作成します。
+- `map.set(key: K, value: V): void` - `key` の値を `value` に設定します。
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` - `key` のキーと値のペアを返します。
+- `map.get(key: K): V | null` - `key` の値を返して、`key` がマップに存在しない場合は `null` を返します。
+- `map.isSet(key: K): bool` - `key` がマップに存在すれば `true` を返し、存在しなければ `false` を返します。
+
+#### Bytes
+
+```typescript
+'@graphprotocol/graph-ts'から { Bytes } をインポートします。
+```
+
+`Bytes`は任意の長さのバイト配列を表現するために使用されます。これには `bytes`、`bytes32` 型などのイーサリアム値が含まれます。
+
+`Bytes`クラスはAssemblyScriptの[Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64)を拡張したもので、`Uint8Array`のすべての機能に加え、以下の新しいメソッドをサポートしています：
+
+_Construction_
+
+- `fromHexString(hex: string) ： Bytes` - 偶数桁の16進数からなる文字列 `hex` を `ByteArray` に変換します。文字列 `hex` はオプションで `0x` から始めることができます。
+- `fromI32(i: i32): Bytes` - `i` をバイト配列に変換します。
+
+_Type conversions_
+
+- `b.toHex()` - 配列のバイト数を16進数で表した文字列を返します。
+- `b.toString()` - 配列のバイト列をユニコード文字列に変換します。
+- `b.toBase58()` - イーサリアムバイトの値を base58 エンコーディングに変換します (IPFS ハッシュに使用)
+
+_Operators_
+
+- `b.concat(other: Bytes): Bytes` - - `this` に `other` を直接連結した `Bytes` を返します。
+- `b.concatI32(other: i32) : ByteArray` - `this` に `other` のバイト表現を直接続けた `Bytes` を返します。
+
+#### 住所
+
+```typescript
+'@graphprotocol/graph-ts'から { Address } をインポートします。
+```
+
+アドレス `Address` はイーサリアムのアドレス `address` 値を表現するために `Bytes` を継承しています。
+
+Bytesの API の上に以下のメソッドを追加しています。
+
+- `Address.fromString(s: string)： Address` - 16進数文字列から `Address` を作成します。
+- `Address.fromBytes(b: Bytes)： Address` - `b` から `Address` を生成します。これは正確に20バイト長でなければなりません。それ以下のバイト数の値を渡すとエラーになります。
+
+### ストア API
+
+```typescript
+'@graphprotocol/graph-ts'から { store } をインポートします。
+```
+
+Store API は、グラフノードのストアにエンティティを読み込んだり、保存したり、削除したりすることができます。
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### エンティティの作成
+
+Ethereum のイベントからエンティティを作成する際の一般的なパターンを以下に示します。
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+チェーンの処理中に `Transfer` イベントが発生すると、生成された `Transfer` 型（エンティティ型との名前の衝突を避けるために、ここでは `TransferEvent` のエイリアス）を使用して `handleTransfer` イベントハンドラに渡されます。この型はイベントの親トランザクションやそのパラメータなどのデータにアクセスすることを可能にします。
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### ストアからのエンティティの読み込み
+
+エンティティがすでに存在する場合、以下の方法でストアからロードすることができます。
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### ブロック内で作成されたエンティティの検索
+
+graph-node v0.31.0、@graphprotocol/graph-ts v0.30.0、および @graphprotocol/graph-cli v0.49.0 以降、 loadInBlock メソッドはすべてのエンティティ タイプで使用できます。
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id =event.transaction.hash // または ID が構築される方法
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = 新しい転送(id)
+}
+
+// 以前と同様に Transfer エンティティを使用します
+```
+
+> 注: 指定されたブロックにエンティティが作成されていない場合、ストア内に指定された ID を持つエンティティが存在する場合でも、loadInBlock は null を返します。
+
+#### 派生エンティティの検索
+
+graph-node v0.31.0、@graphprotocol/graph-ts v0.31.0、および @graphprotocol/graph-cli v0.51.0 以降、loadMany メソッドが利用可能です。
+
+これにより、イベント ハンドラー内から派生エンティティ フィールドをロードできるようになります。たとえば、次のスキーマがあるとします。
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+次のコードは、Holder エンティティの派生元である Token エンティティを読み込みます。
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### 既存のエンティティの更新
+
+既存のエンティティを更新するには 2 つの方法があります。
+
+1. Transfer.load(id)などでエンティティをロードし、エンティティにプロパティを設定した後、.save()でストアに戻す。
+2. 単純にnew Transfer(id)でエンティティを作成し、エンティティにプロパティを設定し、ストアに .save()します。 エンティティがすでに存在する場合は、変更内容がマージされます。
+
+プロパティの変更は、生成されたプロパティセッターのおかげで、ほとんどの場合、簡単です。
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+また、次の 2 つの命令のいずれかで、プロパティの設定を解除することも可能です。
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+これは、オプションのプロパティ、つまり GraphQL で!を付けずに宣言されているプロパティでのみ機能します。 例としては、owner: Bytesやamount: BigIntです。
+
+エンティティから配列を取得すると、その配列のコピーが作成されるため、配列のプロパティの更新には少し手間がかかります。 つまり、配列を変更した後は、明示的に配列のプロパティを設定し直す必要があります。 次の例では、entity が numbers: [BigInt!]! を持っていると仮定します。
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### ストアからのエンティティの削除
+
+現在、生成された型を使ってエンティティを削除する方法はありません。 代わりに、エンティティを削除するには、エンティティタイプの名前とエンティティ ID をstore.removeに渡す必要があります。
+
+```typescript
+mport { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+Ethereum API は、スマートコントラクト、パブリックステート変数、コントラクト関数、イベント、トランザクション、ブロック、および Ethereum データのエンコード/デコードへのアクセスを提供します。
+
+#### Ethereum タイプのサポート
+
+エンティティと同様に、graph codegenは、サブグラフで使用されるすべてのスマートコントラクトとイベントのためのクラスを生成します。 このためには、コントラクト ABI がサブグラフマニフェストのデータソースの一部である必要があります。 通常、ABI ファイルはabis/フォルダに格納されています。
+
+生成されたクラスでは、Ethereum Typeと[built-in types](#built-in-types)間の変換が舞台裏で行われるため、サブグラフ作成者はそれらを気にする必要がありません。
+
+以下の例で説明します。 以下のようなサブグラフのスキーマが与えられます。
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+イーサリアムの `Transfer(address,address,uint256)` イベントシグネチャを使用すると、`from`, `to`, `uint256` 型の値は `Address` と `BigInt` に変換され、`Transfer` エンティティの `Bytes!` プロパティと `BigInt!` プロパティに渡すことができます：
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### イベントとブロック/トランザクションデータ
+
+前述の例のTransferイベントのように、イベントハンドラに渡された Ethereum イベントは、イベントパラメータへのアクセスだけでなく、その親となるトランザクションや、それらが属するブロックへのアクセスも提供します。 event インスタンスからは、以下のデータを取得することができます（これらのクラスは、 graph-tsのethereumモジュールの一部です）。
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### スマートコントラクトの状態へのアクセス
+
+graph codegenが生成するコードには、サブグラフで使用されるスマートコントラクトのクラスも含まれています。 これらを使って、パブリックな状態変数にアクセスしたり、現在のブロックにあるコントラクトの関数を呼び出したりすることができます。
+
+よくあるパターンは、イベントが発生したコントラクトにアクセスすることです。 これは以下のコードで実現できます。
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+Transferは、エンティティタイプとの名前の衝突を避けるために、ここではTransferEventにエイリアスされています。
+
+Ethereum の ERC20Contractにsymbolというパブリックな読み取り専用の関数があれば、.symbol()で呼び出すことができます。 パブリックな状態変数については、同じ名前のメソッドが自動的に作成されます。
+
+サブグラフの一部である他のコントラクトは、生成されたコードからインポートすることができ、有効なアドレスにバインドすることができます。
+
+#### リバートされた呼び出しの処理
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### 符号化/復号化 ABI
+
+ethereumモジュールのencode/ decode関数を使用して、Ethereum の ABI エンコーディングフォーマットに従ってデータをエンコード/デコードすることができます。
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+その他の情報:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### Logging API
+
+```typescript
+'@graphprotocol/graph-ts'から{ log } をインポートします。
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+log API には以下の機能があります:
+
+- `log.debug(fmt: string, args: Array<string>): void` - デバッグメッセージを記録します。
+- `log.info(fmt: string, args: Array<string>): void` - インフォメーションメッセージを記録します。
+- `log.warning(fmt: string, args: Array<string>): void` - 警告メッセージを記録します。
+- `log.error(fmt: string, args: Array<string>): void` - エラーメッセージを記録します。
+- `log.critical(fmt: string, args: Array<string>): void` - クリティカル・メッセージを記録して、サブグラフを終了します。
+
+log API は、フォーマット文字列と文字列値の配列を受け取ります。 そして、プレースホルダーを配列の文字列値で置き換えます。 最初の{}プレースホルダーは配列の最初の値に置き換えられ、2 番目の{}プレースホルダーは 2 番目の値に置き換えられ、以下のようになります。
+
+```typescript
+log.info('表示されるメッセージ。{}, {}, {}', [value.toString(), anotherValue.toString(), 'すでに文字列'])
+```
+
+#### 1 つまたは複数の値を記録する
+
+##### 1 つの値を記録する
+
+以下の例では、文字列値 "A" を配列に渡して['A'] にしてからログに記録しています。
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### 既存の配列から 1 つのエントリをロギングする
+
+以下の例では、配列に 3 つの値が含まれているにもかかわらず、引数の配列の最初の値だけがログに記録されます。
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### 既存の配列から複数のエントリを記録する
+
+引数配列の各エントリは、ログメッセージ文字列に独自のプレースホルダー{}を必要とします。 以下の例では、ログメッセージに 3 つのプレースホルダー{}が含まれています。 このため、myArrayの 3 つの値すべてがログに記録されます。
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### 既存の配列から特定のエントリをロギングする
+
+配列内の特定の値を表示するには、インデックス化された値を指定する必要があります。
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### イベント情報の記録
+
+以下の例では、イベントからブロック番号、ブロックハッシュ、トランザクションハッシュをログに記録しています。
+
+```typescript
+'@graphprotocol/graph-ts'から { log } をインポートします。
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+'@graphprotocol/graph-ts'から { ipfs } をインポートします。
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+IPFS のハッシュやパスが与えられた場合、IPFS からのファイルの読み込みは以下のように行われます。
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+注: ipfs.cat は今のところ決定論的なものではありません。もし要求がタイムアウトする前にIPFSネットワーク上でファイルを取得できなければ、 nullを返します。このため、常に null の結果をチェックする価値があります。
+
+また、ipfs.map.を使って、大きなファイルをストリーミングで処理することも可能です。 この関数は、IPFS ファイルのハッシュまたはパス、コールバックの名前、そして動作を変更するためのフラグを受け取ります。
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+現在サポートされているフラグは `json` だけで、これは `ipfs.map` に渡さなければなりません。json` フラグを指定すると、IPFS ファイルは一連の JSON 値で構成されます。ipfs.map` を呼び出すと、ファイルの各行を読み込んで `JSONValue` にデシリアライズし、それぞれのコールバックを呼び出します。コールバックは `JSONValue` からデータを格納するためにエンティティ操作を使用することができます。エンティティの変更は、`ipfs.map` を呼び出したハンドラが正常に終了したときのみ保存されます。その間はメモリ上に保持されるので、`ipfs.map` が処理できるファイルのサイズは制限されます。
+
+成功すると，ipfs.mapは voidを返します。 コールバックの呼び出しでエラーが発生した場合、ipfs.mapを呼び出したハンドラは中止され、サブグラフは失敗とマークされます。
+
+### Crypto API
+
+```typescript
+'@graphprotocol/graph-ts'から { crypto } をインポートします。
+```
+
+crypto API は、マッピングで使用できる暗号化関数を提供します。 今のところ、1 つしかありません。
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+'@graphprotocol/graph-ts'から{ json, JSONValueKind } をインポートします。
+```
+
+JSON データは、json API を使って解析することができます。
+
+- `json.fromBytes(data: Bytes)： JSONValue` - 有効な UTF-8 シーケンスとして解釈され、 `Bytes` 配列から JSON データをパースします。
+- `json.try_fromBytes(data: Bytes)： Result<JSONValue, boolean>` - `json.fromBytes` の安全バージョンで、パースに失敗した場合はエラーバリアントを返します。
+- `json.fromString(data: string)： JSONValue` - 有効な UTF-8 `String` から JSON データをパースします。
+- `json.try_fromString(data: string)： Result<JSONValue, boolean>` - `json.fromString` の安全バージョンで、パースに失敗した場合はエラーバリアントを返します。
+
+JSONValue クラスは、任意の JSON ドキュメントから値を引き出す方法を提供します。 JSON の値には、ブーリアン、数値、配列などがあるため、JSONValueには、値の種類をチェックするためのkindプロパティが付属しています。
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+さらに、値がnullかどうかをチェックするメソッドもあります\`:
+
+- `value.isNull(): boolean`
+
+値の型が確実な場合は、以下のいずれかの方法で[組み込み型](#built-in-types)に変換することができます：
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (その後、上記の 5 つのメソッドのいずれかを使用して `JSONValue` を変換します)
+
+### タイプ 変換参照
+
+| Source(s)            | Destination          | Conversion function              |
+| -------------------- | -------------------- | -------------------------------- |
+| Address              | Bytes                | none                             |
+| Address              | String               | s.toHexString()                  |
+| BigDecimal           | String               | s.toString()                     |
+| BigInt               | BigDecimal           | s.toBigDecimal()                 |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex()     |
+| BigInt               | String (unicode)     | s.toString()                     |
+| BigInt               | i32                  | s.toI32()                        |
+| Boolean              | Boolean              | none                             |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)        |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)      |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex()     |
+| Bytes                | String (unicode)     | s.toString()                     |
+| Bytes                | String (base58)      | s.toBase58()                     |
+| Bytes                | i32                  | s.toI32()                        |
+| Bytes                | u32                  | s.toU32()                        |
+| Bytes                | JSON                 | json.fromBytes(s)                |
+| int8                 | i32                  | none                             |
+| int32                | i32                  | none                             |
+| int32                | BigInt               | Bigint.fromI32(s)                |
+| uint24               | i32                  | none                             |
+| int64 - int256       | BigInt               | none                             |
+| uint32 - uint256     | BigInt               | none                             |
+| JSON                 | boolean              | s.toBool()                       |
+| JSON                 | i64                  | s.toI64()                        |
+| JSON                 | u64                  | s.toU64()                        |
+| JSON                 | f64                  | s.toF64()                        |
+| JSON                 | BigInt               | s.toBigInt()                     |
+| JSON                 | string               | s.toString()                     |
+| JSON                 | Array                | s.toArray()                      |
+| JSON                 | Object               | s.toObject()                     |
+| String               | Address              | Address.fromString(s)            |
+| Bytes                | Address              | Address.fromString(s)            |
+| String               | BigInt               | BigDecimal.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)         |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)       |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)            |
+
+### データソースのメタデータ
+
+ハンドラを起動したデータソースのコントラクトアドレス、ネットワーク、コンテキストは、以下のようにして調べることができます。
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### エンティティと DataSourceContext
+
+ベースとなるエンティティクラスと子クラスのDataSourceContextクラスには、フィールドを動的に設定・取得するためのヘルパーが用意されています。
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### マニフェスト内のDataSourceContext
+
+DataSources`の`context`セクションでは、サブグラフマッピング内でアクセス可能なキーと値のペアを定義することができます。使用可能な型は`Bool`、`String`、`Int`、`Int8`、`BigDecimal`、`Bytes`、`List`、`BigInt\` です。
+
+以下は `context` セクションのさまざまな型の使い方を示す YAML の例です：
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+このコンテキストは、サブグラフのマッピング・ファイルからアクセスでき、よりダイナミックで設定可能なサブグラフを実現します。

From 069d0ac906d9b8286a12bbb71f14b62da1260435 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:45 -0500
Subject: [PATCH 0796/3820] New translations common-issues.mdx (Japanese)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/ja/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/ja/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..9bb0634b57b3
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: AssemblyScriptのよくある問題
+---
+
+AssemblyScript](https://github.com/AssemblyScript/assemblyscript)には、サブグラフの開発中によく遭遇する問題があります。これらの問題は、デバッグの難易度に幅がありますが、認識しておくと役に立つかもしれません。以下は、これらの問題の非網羅的なリストです：
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- スコープは[クロージャー関数](https://www.assemblyscript.org/status.html#on-closures)には継承されません。つまり、クロージャー関数の外で宣言された変数は使用できません。Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s)に説明があります。

From c46321fab304844e3d33c0572a9c6b9c2584add2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:46 -0500
Subject: [PATCH 0797/3820] New translations unit-testing-framework.mdx
 (Japanese)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/ja/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/ja/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..e6b547aed8be
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: ユニットテストフレームワーク
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## はじめに
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+postgresql をインストールします。
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt postgresql をインストール
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+WSLでは、Dockerアプローチとバイナリアプローチの両方でMatchstickを使用することができます。WSLは少しトリッキーなので、以下のような問題に遭遇した場合のヒントを紹介します。
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+または
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev （インストール）
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+これにより、test フォルダ内のすべてのテストが実行されます。
+
+```sh
+グラフテスト
+```
+
+これは、gravity.test.tsという名前のテストと、gravityというフォルダの中にあるすべてのテストを実行します：
+
+```sh
+gravityのテスト
+```
+
+これは、その特定のテストファイルのみを実行します：
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### コンフィギュレーション
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### デモ・サブグラフ
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### ビデオチュートリアル
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+例：
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+例：
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+または
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+例
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+例：
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+例
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## アサート
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## 単体テストを書く
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+次のようなハンドラ関数があるとします（さらに、生活を便利にするための2つのヘルパー関数もあります）。
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+まず、プロジェクト内にテストファイルを作成する必要があります。これは、そのような例です：
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- 初期状態を設定し、カスタムGravatarエンティティを1つ追加しています；
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- storeの状態をアサートする場合、これはどのように行われるのでしょうか。- Entityの種類とidの一意の組み合わせを渡します。そして、そのEntityの特定のフィールドをチェックし、期待通りの値を持っていることを表明します。これはstoreに追加した最初の Gravatar Entity と、ハンドラ関数が呼び出されたときに追加される 2 つの Gravatar Entity の両方に対して行っているのです。
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+これで最初のテストが完成しました! 👏
+
+テストを実行するには、サブグラフのルートフォルダで以下を実行する必要があります：
+
+`graph test Gravity`
+
+すべてがうまくいくと、以下のメッセージが表示されます：
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## 一般的なテストシナリオ
+
+### 特定の状態で店舗を潤す
+
+ユーザーは、既知のエンティティのセットでストアをハイドレートすることができます。ここでは、Gravatarのエンティティでストアを初期化する例を示します：
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### イベントを使ったマッピング関数の呼び出し
+
+ユーザーはカスタムイベントを作成し、それをストアにバインドされたマッピング関数に渡すことができます：
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### イベントフィクスチャですべてのマッピングを呼び出す
+
+ユーザーはテストフィクスチャでマッピングを呼び出すことができます。
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### コントラクトコールのモック
+
+ユーザーはコントラクトコールをモックすることができます：
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+このように、コントラクトの呼び出しと戻り値をハードコア化するために、ユーザーはコントラクトのアドレス、関数名、関数シグネチャ、引数の配列、そしてもちろん戻り値を提供する必要があります。
+
+また、関数の戻り値をモックすることもできます：
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking IPFS files (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### ストアの状態をアサートする
+
+ユーザーは、エンティティをアサートすることで、ストアの最終的な状態（または途中の状態）をアサートすることができます。これを実行するためには、ユーザーはエンティティタイプ、エンティティの特定の ID、フィールド名、フィールドの期待値を指定する必要があります。以下に例を示します：
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### イベントメタデータとのやりとり
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### 変数の等値性の主張
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+ユーザーは、あるエンティティがストアに存在しないことをアサートできます。この関数は、エンティティタイプと id を受け取ります。エンティティが実際にストア内にある場合、テストは関連するエラーメッセージを表示して失敗します。この機能を使った簡単な例をご紹介します：
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+このヘルパー関数を使って、ストア全体をコンソールに出力することができます：
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### 予想される不具合
+
+Test() 関数のshouldFailフラグを使用して、ユーザーがテストの失敗を予想することができます：
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+ShouldFail = true とマークされているにもかかわらずテストが失敗した場合は、ログにエラーとして表示され、テストブロックは失敗します。また、shouldFail = false (デフォルトの状態) と設定されている場合は、テスト実行者がクラッシュします。
+
+### ロギング
+
+ユニットテストにカスタムログを持たせることは、マッピングにログを持たせることと全く同じです。違いは、ログオブジェクトをgraph-tsではなくmatchstick-asからインポートする必要があることです。以下は、すべての非重要なログタイプを使った簡単な例です：
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+ユーザーは、このように致命的な失敗をシミュレートすることもできます：
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+クリティカルエラーのログを取るとテストの実行が止まり、すべてが飛んでしまいます。コードに重要なログがデプロイされていないことを確認し、もし発生した場合にはすぐに気付く必要があります。
+
+### 派生フィールドのテスト
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### 動的データソースのテスト
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+以下はその例です：
+
+まず、次のようなイベントハンドラを用意します (これはデータソースのモッキングを紹介するために意図的に再利用されています)：
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+そして、dataSourceMock namespaceのメソッドの1つを使用して、すべてのdataSource関数に新しい戻り値を設定するテストがあります：
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+最後にdataSourceMock.resetValues()が呼び出されていることに注目してください。これは、値が変更されると記憶されるため、デフォルトの値に戻したい場合はリセットする必要があるからです。
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## テストカバレッジ
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### 前提条件
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### ハンドラのエクスポート
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### 使い方
+
+設定が完了したら、テストカバレッジツールを実行するために実行します：
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+これによりカバレッジ ツールが実行され、ターミナルに次のような内容が表示されるはずです。
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### ログ出力でのテスト実行時間の表示
+
+ログ出力にテスト実行時間が含まれるようになりました。以下はその例です：
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## 一般的なコンパイラーエラー
+
+> Critical: 有効なモジュールから WasmInstance を作成できない。コンテキストが不明 インポート: wasi_snapshot_preview1::fd_write が定義されていない
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: 期待された引数は?
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: 期待された引数は?
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## その他のリソース
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## フィードバック
+
+質問、フィードバックなどがありましたら、The Graph DiscordにMatchstick専用のチャンネル🔥| unit-testing がありますので、そちらにお問い合わせください。

From 9be71fbbfac2ec6d66537458d441cb648d5c5972 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:47 -0500
Subject: [PATCH 0798/3820] New translations transferring-a-subgraph.mdx
 (Japanese)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/ja/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/ja/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 5129a2c2ac57e3e0c4963cc27eba21b3c4bf3690 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:48 -0500
Subject: [PATCH 0799/3820] New translations graphql-api.mdx (Japanese)

---
 .../ja/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/ja/subgraphs/querying/graphql-api.mdx b/website/pages/ja/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..b0708c414106
--- /dev/null
+++ b/website/pages/ja/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### 例
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### 並べ替え
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### 例
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### ネストされたエンティティの並べ替えの例
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### ページネーション
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+最初の 10 個のトークンを照会します。
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### フィルタリング
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### 範囲フィルタリングの例
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### ブロックフィルタリングの例
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+これは、前回のポーリング以降など、変更されたエンティティのみをフェッチする場合に役立ちます。または、サブグラフでエンティティがどのように変化しているかを調査またはデバッグするのに役立ちます (ブロック フィルターと組み合わせると、特定のブロックで変更されたエンティティのみを分離できます)。
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### ネストされたエンティティ フィルタリングの例
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+これは、子レベルのエンティティが指定された条件を満たすエンティティのみをフェッチする場合に役立ちます。
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### 論理演算子
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### すべてのフィルター
+
+パラメータのサフィックスの全リスト:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### タイムトラベル クエリ
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### 例
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### 例
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### 全文検索クエリ
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+全文検索演算子:
+
+| シンボル  | オペレーター      | 説明書き                                                      |
+| ----- | ----------- | --------------------------------------------------------- |
+| `&`   | `And`       | 複数の検索語を組み合わせて、指定したすべての検索語を含むエンティティをフィルタリングします。            |
+| |     | `Or`        | 複数の検索語をオペレーターで区切って検索すると、指定した語のいずれかにマッチするすべてのエンティティが返されます。 |
+| `<->` | `Follow by` | 2 つの単語の間の距離を指定します。                                        |
+| `:*`  | `Prefix`    | プレフィックス検索語を使って、プレフィックスが一致する単語を検索します（2 文字必要）               |
+
+#### 例
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+全文演算子を組み合わせて、より複雑なフィルターを作成します。口実検索演算子を follow by このサンプル クエリと組み合わせて使用​​すると、"lou" で始まり、その後に "music" が続く単語を持つすべてのブログ エンティティが一致します。
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### 認証
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## スキーマ
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### エンティティ
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### サブグラフ メタデータ
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+ブロックが提供されている場合、メタデータはそのブロックのものであり、そうでない場合は、最新のインデックス付きブロックが使用されます。提供される場合、ブロックはサブグラフの開始ブロックの後にあり、最後にインデックス付けされたブロック以下でなければなりません。
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: ブロックのハッシュ
+- number: ブロック番号
+- timestamp: 可能であれば、ブロックのタイムスタンプ (これは現在、EVMネットワークのインデックスを作成するサブグラフでのみ利用可能)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 751ea3a8247c31e91deac3f3ba28acf620eb50aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:49 -0500
Subject: [PATCH 0800/3820] New translations python.mdx (Japanese)

---
 .../pages/ja/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/querying/python.mdx

diff --git a/website/pages/ja/subgraphs/querying/python.mdx b/website/pages/ja/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..8e32f12b9599
--- /dev/null
+++ b/website/pages/ja/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgroundsは、[Playgrounds](https://playgrounds.network/)によって構築された、サブグラフをクエリするための直感的なPythonライブラリです。サブグラフデータを直接Pythonデータ環境に接続し、[pandas](https://pandas.pydata.org/)のようなライブラリを使用してデータ分析を行うことができます！
+
+Subgroundsは、GraphQLクエリを構築するためのシンプルなPythonic APIを提供し、ページ分割のような面倒なワークフローを自動化し、制御されたスキーマ変換によって高度なユーザーを支援します。
+
+## はじめに
+
+SubgroundsはPython 3.10以降を必要とし、[pypi](https://pypi.org/project/subgrounds/)で利用可能です。
+
+```bash
+pip install --upgrade subgrounds
+# または
+python -m pip install --upgrade subgrounds
+```
+
+インストールしたら、以下のクエリでsubgroundsを試すことができる。以下の例では、Aave v2 プロトコルのサブグラフを取得し、TVL (Total Value Locked) 順に並べられた上位 5 つの市場をクエリし、その名前と TVL (USD) を選択し、pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame) としてデータを返します。
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# サブグラフを読み込む
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# クエリの構築
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD、
+    orderDirection='desc'、
+    first=5、
+)
+# クエリをデータフレームに戻す
+sg.query_df([
+    latest_markets.name、
+    latest_markets.totalValueLockedUSD、
+])
+```
+
+## ドキュメンテーション
+
+Subgroundsは[Playgrounds](https://playgrounds.network/)チームによってビルド、メンテナンスされており、[Playgrounds docs](https://docs.playgrounds.network/subgrounds)からアクセスすることができます。
+
+Subgroundsには多くの機能があるので、まずはここから始めましょう：
+
+- - クエリ入門](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - - subgroundsでクエリを構築するための最初のステップです。
+- ｛合成フィールドの構築](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - - スキーマから定義されたデータを変換する合成フィールドの定義をやさしく紹介します。
+- [並行クエリ](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - クエリを並列化することで、クエリをレベルアップする方法を紹介します。
+- [データをCSVにエクスポートする](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 04e8c52ed9d1202f494f986af20882d7a1d6e4bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:50 -0500
Subject: [PATCH 0801/3820] New translations triggers.mdx (Japanese)

---
 website/pages/ja/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/ja/substreams/sps/triggers.mdx

diff --git a/website/pages/ja/substreams/sps/triggers.mdx b/website/pages/ja/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/ja/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 85a1bca533942e3de5e69e71b9cbb4019044befc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:52 -0500
Subject: [PATCH 0802/3820] New translations overview.mdx (Korean)

---
 website/pages/ko/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/ko/indexing/overview.mdx

diff --git a/website/pages/ko/indexing/overview.mdx b/website/pages/ko/indexing/overview.mdx
new file mode 100644
index 000000000000..ced5ed20026b
--- /dev/null
+++ b/website/pages/ko/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+
+GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.
+
+Indexers select subgraphs to index based on the subgraph’s curation signal, where Curators stake GRT in order to indicate which subgraphs are high-quality and should be prioritized. Consumers (eg. applications) can also set parameters for which Indexers process queries for their subgraphs and set preferences for query fee pricing.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### What is the minimum stake required to be an Indexer on the network?
+
+The minimum stake for an Indexer is currently set to 100K GRT.
+
+### What are the revenue streams for an Indexer?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### How are indexing rewards distributed?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### What is a proof of indexing (POI)?
+
+POIs are used in the network to verify that an Indexer is indexing the subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific subgraph deployment up to and including that block.
+
+### When are indexing rewards distributed?
+
+Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).
+
+### Can pending indexing rewards be monitored?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Many of the community-made dashboards include pending rewards values and they can be easily checked manually by following these steps:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### What are disputes and where can I view them?
+
+Indexer's queries and allocations can both be disputed on The Graph during the dispute period. The dispute period varies, depending on the type of dispute. Queries/attestations have 7 epochs dispute window, whereas allocations have 56 epochs. After these periods pass, disputes cannot be opened against either of allocations or queries. When a dispute is opened, a deposit of a minimum of 10,000 GRT is required by the Fishermen, which will be locked until the dispute is finalized and a resolution has been given. Fisherman are any network participants that open disputes.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- If the dispute is rejected, the GRT deposited by the Fishermen will be burned, and the disputed Indexer will not be slashed.
+- If the dispute is settled as a draw, the Fishermen's deposit will be returned, and the disputed Indexer will not be slashed.
+- If the dispute is accepted, the GRT deposited by the Fishermen will be returned, the disputed Indexer will be slashed and the Fishermen will earn 50% of the slashed GRT.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### What are query fee rebates and when are they distributed?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+
+### What is query fee cut and indexing reward cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### How do Indexers know which subgraphs to index?
+
+Indexers may differentiate themselves by applying advanced techniques for making subgraph indexing decisions but to give a general idea we'll discuss several key metrics used to evaluate subgraphs in the network:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### What are the hardware requirements?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- | :------------------: | :---------------------------: | :-------------------------: | :-------------: | :----------------------: |
+| Small    |           4          |               8               |              1              |        4        |            16            |
+| Standard |           8          |               30              |              1              |        12       |            48            |
+| Medium   |          16          |               64              |              2              |        32       |            64            |
+| Large    |          72          |              468              |             3.5             |        48       |            184           |
+
+### What are some basic security precautions an Indexer should take?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastructure
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Note: To support agile scaling, it is recommended that query and indexing concerns are separated between different sets of nodes: query nodes and index nodes.
+
+### Ports overview
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Port | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
+
+#### Indexer Service
+
+| Port | Purpose                                              | Routes                                                      | CLI Argument    | Environment Variable   |
+| ---- | ---------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                   | /metrics                                                    | \--metrics-port | -                      |
+
+#### Indexer Agent
+
+| Port | Purpose                | Routes | CLI Argument               | Environment Variable                    |
+| ---- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | Indexer management API | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Setup server infrastructure using Terraform on Google Cloud
+
+> Note: Indexers can alternatively use AWS, Microsoft Azure, or Alibaba.
+
+#### Install prerequisites
+
+- Google Cloud SDK
+- Kubectl command line tool
+- Terraform
+
+#### Create a Google Cloud Project
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Authenticate with Google Cloud and create a new project.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Use the Google Cloud Console's billing page to enable billing for the new project.
+
+- Create a Google Cloud configuration.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Enable required Google Cloud APIs.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Create a service account.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Enable peering between database and Kubernetes cluster that will be created in the next step.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Create minimal terraform configuration file (update as needed).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Use Terraform to create infrastructure
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Run the following commands to create the infrastructure.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Creating the Kubernetes components for the Indexer
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Getting started from source
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start a PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Now that all the dependencies are setup, start the Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Getting started using Docker
+
+#### Prerequisites
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Setup
+
+1. Clone Graph Node and navigate to the Docker directory:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Start a local Graph Node that will connect to your Ethereum endpoint:
+
+```sh
+docker-compose up
+```
+
+### Indexer components
+
+To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Getting started
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### From NPM packages
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### From source
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Using docker
+
+- Pull images from the registry
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Or build images locally from source
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Run the components
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Using K8s and Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Usage
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexer agent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Indexer management using Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Usage
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Indexing rules
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Data model:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Example usage of indexing rule:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Action added to the queue by the 3rd party optimizer tool or indexer-cli user
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken.
+
+Data model:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Example usage from source:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Note that supported action types for allocation management have different input requirements:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - required action params:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - required action params:
+    - allocationID
+    - deploymentID
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - required action params:
+    - allocationID
+    - deploymentID
+    - amount
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+#### Cost models
+
+Cost models provide dynamic pricing for queries based on market and query attributes. The Indexer Service shares a cost model with the gateways for each subgraph for which they intend to respond to queries. The gateways, in turn, use the cost model to make Indexer selection decisions per query and to negotiate payment with chosen Indexers.
+
+#### Agora
+
+The Agora language provides a flexible format for declaring cost models for queries. An Agora price model is a sequence of statements that execute in order for each top-level query in a GraphQL query. For each top-level query, the first statement which matches it determines the price for that query.
+
+A statement is comprised of a predicate, which is used for matching GraphQL queries, and a cost expression which when evaluated outputs a cost in decimal GRT. Values in the named argument position of a query may be captured in the predicate and used in the expression. Globals may also be set and substituted in for placeholders in an expression.
+
+Example cost model:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Example query costing using the above model:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Applying the cost model
+
+Cost models are applied via the Indexer CLI, which passes them to the Indexer Management API of the Indexer agent for storing in the database. The Indexer Service will then pick them up and serve the cost models to gateways whenever they ask for them.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interacting with the network
+
+### Stake in the protocol
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Approve tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Stake tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### The life of an allocation
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 2a171cd1e8012fa989e00b210b2a798933eed7c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:53 -0500
Subject: [PATCH 0803/3820] New translations tap.mdx (Korean)

---
 website/pages/ko/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/ko/indexing/tap.mdx

diff --git a/website/pages/ko/indexing/tap.mdx b/website/pages/ko/indexing/tap.mdx
new file mode 100644
index 000000000000..3bab672ab211
--- /dev/null
+++ b/website/pages/ko/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Overview
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notes:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From 6cd126114932e505fb37d9417b584d623a926c89 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:54 -0500
Subject: [PATCH 0804/3820] New translations graph-node.mdx (Korean)

---
 .../pages/ko/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/ko/indexing/tooling/graph-node.mdx

diff --git a/website/pages/ko/indexing/tooling/graph-node.mdx b/website/pages/ko/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..6a27301b680b
--- /dev/null
+++ b/website/pages/ko/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL database
+
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
+
+### Network clients
+
+In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS Nodes
+
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+### Prometheus metrics server
+
+To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
+
+### Getting started from source
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start a PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Now that all the dependencies are setup, start the Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Getting started with Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+When it is running Graph Node exposes the following ports:
+
+| Port | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Advanced Graph Node configuration
+
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Multiple Graph Nodes
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding.
+
+#### Deployment rules
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Example deployment rule configuration:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Dedicated query nodes
+
+Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Any node whose --node-id matches the regular expression will be set up to only respond to queries.
+
+#### Database scaling via sharding
+
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore.
+
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Dedicated block ingestion
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Supporting multiple networks
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Multiple networks
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Environment variables
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Continuous deployment
+
+Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Managing Graph Node
+
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Working with subgraphs
+
+#### Indexing status API
+
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Indexing performance
+
+There are three separate parts of the indexing process:
+
+- Fetching events of interest from the provider
+- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
+- Writing the resulting data to the store
+
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+
+Common causes of indexing slowness:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- A large number of events to process
+- Slow database connection time, for crowded nodes
+- The provider itself falling behind the chain head
+- Slowness in fetching new receipts at the chain head from the provider
+
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+
+#### Failed subgraphs
+
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+
+- Deterministic failures: these are failures which will not be resolved with retries
+- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
+
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Block and call cache
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. If the block matches the provider, then the issue can be debugged directly against the provider.
+
+#### Querying issues and errors
+
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+
+However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+
+There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.
+
+##### Query caching
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analysing queries
+
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
+
+In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
+
+##### Account-like optimisation
+
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Removing subgraphs
+
+> This is new functionality, which will be available in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 3acc1c5b2930450b13529e472d66af446bffb96c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:55 -0500
Subject: [PATCH 0805/3820] New translations advanced.mdx (Korean)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/ko/subgraphs/developing/creating/advanced.mdx b/website/pages/ko/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..a6a4b224bc3e
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Overview
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Non-fatal errors
+
+Indexing errors on already synced subgraphs will, by default, cause the subgraph to fail and stop syncing. Subgraphs can alternatively be configured to continue syncing in the presence of errors, by ignoring the changes made by the handler which provoked the error. This gives subgraph authors time to correct their subgraphs while queries continue to be served against the latest block, though the results might be inconsistent due to the bug that caused the error. Note that some errors are still always fatal. To be non-fatal, the error must be known to be deterministic.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Enabling non-fatal errors requires setting the following feature flag on the subgraph manifest:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way. File data sources support fetching files from IPFS and from Arweave.
+
+> This also lays the groundwork for deterministic indexing of off-chain data, as well as the potential introduction of arbitrary HTTP-sourced data.
+
+### Overview
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Upgrade guide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Add a new entity type which will be updated when files are found
+
+File data sources cannot access or update chain-based entities, but must update file specific entities.
+
+This may mean splitting out fields from existing entities into separate entities, linked together.
+
+Original combined entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+New, split entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+If the relationship is 1:1 between the parent entity and the resulting file data source entity, the simplest pattern is to link the parent entity to a resulting file entity by using the IPFS CID as the lookup. Get in touch on Discord if you are having difficulty modelling your new file-based entities!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+This is the data source which will be spawned when a file of interest is identified.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Create a new handler to process files
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Example handler:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Spawn file data sources when required
+
+You can now create file data sources during execution of chain-based handlers:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Example:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+This will create a new file data source, which will poll Graph Node's configured IPFS or Arweave endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Congratulations, you are using file data sources!
+
+#### Deploying your subgraphs
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitations
+
+File data source handlers and entities are isolated from other subgraph entities, ensuring that they are deterministic when executed, and ensuring no contamination of chain-based data sources. To be specific:
+
+- Entities created by File Data Sources are immutable, and cannot be updated
+- File Data Source handlers cannot access entities from other file data sources
+- Entities associated with File Data Sources cannot be accessed by chain-based handlers
+
+> While this constraint should not be problematic for most use-cases, it may introduce complexity for some. Please get in touch via Discord if you are having issues modelling your file-based data in a subgraph!
+
+Additionally, it is not possible to create data sources from a file data source, be it an onchain data source or another file data source. This restriction may be lifted in the future.
+
+#### Best practices
+
+If you are linking NFT metadata to corresponding tokens, use the metadata's IPFS hash to reference a Metadata entity from the Token entity. Save the Metadata entity using the IPFS hash as an ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> We are working to improve the above recommendation, so queries only return the "most recent" version
+
+#### Known issues
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Examples
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### References
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Grafting onto Existing Subgraphs
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Because grafting copies rather than indexes base data, it is much quicker to get the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 0728472df44212b4f622302f3b14680c4111e7c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:56 -0500
Subject: [PATCH 0806/3820] New translations api.mdx (Korean)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/ko/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/ko/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..5cd8ab120b25
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API Reference
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- Low-level primitives to translate between different type systems such as Ethereum, JSON, GraphQL and AssemblyScript.
+
+### Versions
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| Version | Release notes                                                                                                                                                                                                                                            |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### Built-in Types
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Creating entities
+
+The following is a common pattern for creating entities from Ethereum events.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Loading entities from the store
+
+If an entity already exists, it can be loaded from the store with the following:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Looking up entities created withing a block
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### Updating existing entities
+
+There are two ways to update an existing entity:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+Changing properties is straight forward in most cases, thanks to the generated property setters:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+It is also possible to unset properties with one of the following two instructions:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Removing entities from the store
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
+
+#### Support for Ethereum Types
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+The following example illustrates this. Given a subgraph schema like
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Events and Block/Transaction Data
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Access to Smart Contract State
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+A common pattern is to access the contract from which an event originates. This is achieved with the following code:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address.
+
+#### Handling Reverted Calls
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Encoding/Decoding ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+For more information:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Logging one or more values
+
+##### Logging a single value
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Logging a single entry from an existing array
+
+In the example below, only the first value of the argument array is logged, despite the array containing three values.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Logging multiple entries from an existing array
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Logging a specific entry from an existing array
+
+To display a specific value in the array, the indexed value must be provided.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Logging event information
+
+The example below logs the block number, block hash and transaction hash from an event:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Given an IPFS hash or path, reading a file from IPFS is done as follows:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### Type Conversions Reference
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### Data Source Metadata
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entity and DataSourceContext
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From 874d78528cc5cfd693dad541dc2a1eac61424bdd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:57 -0500
Subject: [PATCH 0807/3820] New translations common-issues.mdx (Korean)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/ko/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/ko/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..f8d0c9c004c2
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Common AssemblyScript Issues
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 45657f5928151ad8144597fa7b4fea76c315fab8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:13:59 -0500
Subject: [PATCH 0808/3820] New translations unit-testing-framework.mdx
 (Korean)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/ko/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/ko/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..2133c1d4b5c9
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Unit Testing Framework
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Getting Started
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+or
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+This will run all tests in the test folder:
+
+```sh
+graph test
+```
+
+This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
+
+```sh
+graph test gravity
+```
+
+This will run only that specific test file:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo subgraph
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Video tutorials
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+or
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Examples:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Example:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Examples:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Write a Unit Test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Assuming we have the following handler function (along with two helper functions to make our life easier):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+We first have to create a test file in our project. This is an example of how that might look like:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- We're setting up our initial state and adding one custom Gravatar entity;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- We assert the state of the store. How does that work? - We're passing a unique combination of Entity type and id. Then we check a specific field on that Entity and assert that it has the value we expect it to have. We're doing this both for the initial Gravatar Entity we added to the store, as well as the two Gravatar entities that gets added when the handler function is called;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+There we go - we've created our first test! 👏
+
+Now in order to run our tests you simply need to run the following in your subgraph root folder:
+
+`graph test Gravity`
+
+And if all goes well you should be greeted with the following:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Common test scenarios
+
+### Hydrating the store with a certain state
+
+Users are able to hydrate the store with a known set of entities. Here's an example to initialise the store with a Gravatar entity:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Calling a mapping function with an event
+
+A user can create a custom event and pass it to a mapping function that is bound to the store:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Calling all of the mappings with event fixtures
+
+Users can call the mappings with test fixtures.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocking contract calls
+
+Users can mock contract calls:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+As demonstrated, in order to mock a contract call and hardcore a return value, the user must provide a contract address, function name, function signature, an array of arguments, and of course - the return value.
+
+Users can also mock function reverts:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking IPFS files (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Asserting the state of the store
+
+Users are able to assert the final (or midway) state of the store through asserting entities. In order to do this, the user has to supply an Entity type, the specific ID of an Entity, a name of a field on that Entity, and the expected value of the field. Here's a quick example:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interacting with Event metadata
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Asserting variable equality
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Users can assert that an entity does not exist in the store. The function takes an entity type and an id. If the entity is in fact in the store, the test will fail with a relevant error message. Here's a quick example of how to use this functionality:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+You can print the whole store to the console using this helper function:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Expected failure
+
+Users can have expected test failures, using the shouldFail flag on the test() functions:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+If the test is marked with shouldFail = true but DOES NOT fail, that will show up as an error in the logs and the test block will fail. Also, if it's marked with shouldFail = false (the default state), the test executor will crash.
+
+### Logging
+
+Having custom logs in the unit tests is exactly the same as logging in the mappings. The difference is that the log object needs to be imported from matchstick-as rather than graph-ts. Here's a simple example with all non-critical log types:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Users can also simulate a critical failure, like so:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Logging critical errors will stop the execution of the tests and blow everything up. After all - we want to make sure you're code doesn't have critical logs in deployment, and you should notice right away if that were to happen.
+
+### Testing derived fields
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testing dynamic data sources
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Example below:
+
+First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+And then we have the test using one of the methods in the dataSourceMock namespace to set a new return value for all of the dataSource functions:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Notice that dataSourceMock.resetValues() is called at the end. That's because the values are remembered when they are changed and need to be reset if you want to go back to the default values.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Test Coverage
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Prerequisites
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Export your handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Usage
+
+Once that's all set up, to run the test coverage tool, simply run:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Test run time duration in the log output
+
+The log output includes the test run duration. Here's an example:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Common compiler errors
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Additional Resources
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Feedback
+
+If you have any questions, feedback, feature requests or just want to reach out, the best place would be The Graph Discord where we have a dedicated channel for Matchstick, called 🔥| unit-testing.

From d96efec7d89159c5a96e40c9dbb27e7acf14a3a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:00 -0500
Subject: [PATCH 0809/3820] New translations transferring-a-subgraph.mdx
 (Korean)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/ko/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/ko/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 771e2949ccf1be21cfa7bd5b58b904911fe80a4f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:01 -0500
Subject: [PATCH 0810/3820] New translations graphql-api.mdx (Korean)

---
 .../ko/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/ko/subgraphs/querying/graphql-api.mdx b/website/pages/ko/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..2ffcb85e4019
--- /dev/null
+++ b/website/pages/ko/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Examples
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sorting
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Example
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Example for nested entity sorting
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Pagination
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Query the first 10 tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtering
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Example for range filtering
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for block filtering
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for nested entity filtering
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+This can be useful if you are looking to fetch only entities whose child-level entities meet the provided conditions.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logical operators
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### All Filters
+
+Full list of parameter suffixes:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Time-travel queries
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltext Search Queries
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Fulltext search operators:
+
+| Symbol | Operator    | Description                                                                                                                          |
+| ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
+
+#### Examples
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validation
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Subgraph Metadata
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: the hash of the block
+- number: the block number
+- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 7cf3665d5a245063305c48831646f383104742eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:02 -0500
Subject: [PATCH 0811/3820] New translations python.mdx (Korean)

---
 .../pages/ko/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/querying/python.mdx

diff --git a/website/pages/ko/subgraphs/querying/python.mdx b/website/pages/ko/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..c10d7a0e57ab
--- /dev/null
+++ b/website/pages/ko/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Getting Started
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 59407f340a02d1e38a4dfa98c1f2c69dec039f44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:03 -0500
Subject: [PATCH 0812/3820] New translations triggers.mdx (Korean)

---
 website/pages/ko/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/ko/substreams/sps/triggers.mdx

diff --git a/website/pages/ko/substreams/sps/triggers.mdx b/website/pages/ko/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/ko/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 6994938c1edda7ade3d5687ff4f2e6ca0f157cf3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:05 -0500
Subject: [PATCH 0813/3820] New translations overview.mdx (Dutch)

---
 website/pages/nl/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/nl/indexing/overview.mdx

diff --git a/website/pages/nl/indexing/overview.mdx b/website/pages/nl/indexing/overview.mdx
new file mode 100644
index 000000000000..7a90a3200a65
--- /dev/null
+++ b/website/pages/nl/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexeers zijn node-operators in The Graph Netwerk die Graph Tokens (GRT) inzetten om indexing- en queryverwerkingsdiensten te leveren. Indexeerders verdienen querykosten en indexingsbeloningen voor hun diensten. Ze verdienen ook querykosten die worden terugbetaald volgens een exponentiële functie.
+
+GRT dat in het protocol wordt ingezet, is onderheven aan een ontdooiperiode en kan worden geslashed als Indexers schadelijke acties ondernemen, onjuiste data aan applicaties leveren of als ze onjuist indexeren. Indexers verdienen ook beloningen voor gedelegeerde inzet van Delegators om te contributeren aan het netwerk.
+
+Indexeerders selecteren subgraphs om te indexeren op basis van het curatiesignaal van de subgraph, waar Curatoren GRT inzetten om aan te geven welke subgraphs van hoge kwaliteit zijn en prioriteit moeten krijgen. Consumenten (bijv. applicaties) kunnen ook parameters instellen voor welke Indexeerders queries voor hun subgraphs verwerken en voorkeuren instellen voor de prijs van querykosten.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### Wat is de minimale inzet vereist om een Indexeerder op het netwerk te zijn?
+
+De minimale inzet voor een Indexeerder is momenteel vastgesteld op 100K GRT.
+
+### Wat zijn de inkomstenstromen voor een Indexeerder?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### Hoe worden indexeringsbeloningen verdeeld?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### Wat is een bewijs van indexering (Proof of Indexing)?
+
+POI's worden in het netwerk gebruikt om te verifiëren dat een indexer aan het indexeren is op de subgraph waaraan zij zijn toegewezen. Een POI voor het eerste blok van de huidige epoch moet opgegeven worden tijdens het sluiten van een allocatie, zodat die allocatie in aanmerking komt voor indexeringsbeloningen. Een POI voor een blok is een verwerking van alle entiteitwinkeltransacties voor een specifieke subgraph-implementatie tot aan en inclusief dat blok.
+
+### Wanneer worden indexeringsbeloningen verdeeld?
+
+Allocaties verzamelen voortdurend beloningen terwijl ze actief zijn tot een maximum duur van 28 epochs. Beloningen worden verzameld door de Indexers en verdeeld wanneer ze hun allocaties sluiten. Dat gebeurt handmatig wanneer de Indexeerder ze wil sluiten of, na 28 epochs kan een Delagator de allocatie voor de Indexeerder sluiten, maar dit resulteerd in geen beloningen. 28 epochs is de maximale duur van een allocatie (momenteel duurt één epoch ongeveer 24 uur).
+
+### Kunnen ongerealiseerde indexeringsbeloningen worden bekeken?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Veel van de door de community gemaakte dashboards bevatten waarden van ongerealiseerde beloningen en ze kunnen gemakkelijk handmatig worden gecontroleerd door deze stappen te volgen:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### Wat zijn geschillen en waar kan ik ze bekijken?
+
+Een indexers query's en allocaties kunnen beide betwist worden op The Graph tijdens de dispuutperiode. De dispuutperiode varieert afhankelijk van het type dispuut. Query's/attestaties hebben een 7 epochs dispuutperiode waarbij allocaties 56 epochs hebben. Nadat deze periodes aflopen kunnen disputen niet meer geopnd worde thegen allocaties of query's. Wanneer een dispuut geopend is, is een storting van minimaal 10,000 GRT vereist door de Fisherman, welke vergrendeld zal worden to het dipuut gefinalizeerd is en een resolutie gegeven is. Fisherman zijn alle netwerkdeelnemers die disputen openen.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- Als het dispuut wordt verworpen, wordt de door de Fishermen gestorte GRT verbrand, en de betwiste Indexeerder zal niet worden geslashed.
+- Als het dispuut wordt beoordeeld als een gelijkspel, wordt de storting van de Fishermen teruggestort, en de betwiste Indexeerder zal niet worden geslashed.
+- Als het dispuut wordt geaccepteerd, wordt de door de Fishermen gestorte GRT teruggestort, de betwiste Indexeerder zal worden geslashed. De Fishermen ontvangen 50% van de GRT die geslashed is.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### Wat zijn query kosten rebates en wanneer worden ze uitgedeeld?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Zodra een allocatie is gesloten, zijn de rebates beschikbaar om door de Indexeerder te worden geclaimd. Bij het claimen worden de query rebates verdeeld aan de Indexeerder en hun Delegators op basis van de query fee cut en de exponentiële rebate-functie.
+
+### Wat is de Query Fee Cut en de Indexing Reward Cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### Hoe weten Indexeerders welke subgraphs te indexeren?
+
+Indexeerders kunnen zich onderscheiden door geavanceerde technieken toe te passen bij het maken van beslissingen over subgraph indexering maar om een algemeen idee te geven, bespreken we enkele belangrijke meetpunten die worden gebruikt om subgraphs te evalueren in het netwerk:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### Wat zijn de hardware vereisten?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Setup     | Postgres<br />(CPUs) | Postgres<br />(Geheugen in GBs) | Postgres<br />(schijf in TBs) | VMs<br />(CPUs) | VMs<br />(geheugen in GBs) |
+| --------- | :------------------: | :-----------------------------: | :---------------------------: | :-------------: | :------------------------: |
+| Klein     |           4          |                8                |               1               |        4        |             16             |
+| Standaard |           8          |                30               |               1               |        12       |             48             |
+| Middel    |          16          |                64               |               2               |        32       |             64             |
+| Groot     |          72          |               468               |              3.5              |        48       |             184            |
+
+### Wat zijn enkele basisveiligheidsmaatregelen die een Indexeerder moet nemen?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastructuur
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Tip: Om wendbare schaalvergroting te ondersteunen, wordt aanbevolen om Query- en Indexeringszaken te scheiden tussen verschillende sets nodes: Query Nodes en Index Nodes.
+
+### Poorten overzicht
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Poort | Doel                                                | Routes                                         | CLI-Argument       | Omgevingsvariabele |
+| ----- | --------------------------------------------------- | ---------------------------------------------- | ------------------ | ------------------ |
+| 8000  | GraphQL HTTP server<br />(voor subgraph query's)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                  |
+| 8001  | GraphQL WS<br />(voor subgraph abonnementen)        | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                  |
+| 8020  | JSON-RPC<br />(voor het beheren van implementaties) | /                                              | \--admin-port      | -                  |
+| 8030  | Subgraph indexeerstatus API                         | /graphql                                       | \--index-node-port | -                  |
+| 8040  | Prometheus metrics                                  | /metrics                                       | \--metrics-port    | -                  |
+
+#### Indexer Service
+
+| Poort | Doel                                                      | Routes                                                      | CLI-Argument    | Omgevingsvariabele     |
+| ----- | --------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600  | GraphQL HTTP server<br />(voor betaalde subgraph query's) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300  | Prometheus metrics                                        | /metrics                                                    | \--metrics-port | -                      |
+
+#### Indexer Agent
+
+| Poort | Purpose                | Routes | CLI Argument               | Environment Variable                    |
+| ----- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000  | Indexer management API | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Het opzetten van server infrastructuur met Terraform op Google Cloud
+
+> Let op: Indexeerders kunnen als alternatief AWS, Microsoft Azure or Alibaba gebruiken.
+
+#### Installeer vereisten
+
+- Google Cloud SDK
+- Kubectl command line tool
+- Terraform
+
+#### Maak een Google Cloud project aan
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Authenticeer met Google Cloud en maak een nieuw project.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Gebruik de factureringspagina van Google Cloud Console om facturering voor het nieuwe project in te schakelen.
+
+- Maak een Google Cloud configuratie.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Schakel de vereiste Google Cloud API's in.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Maak een serviceaccount.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Schakel peering in tussen de database en de Kubernetes cluster die in de volgende stap wordt gemaakt.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Maak het minimaal terraform-configuratiebestand (update indien nodig).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Gebruik Terraform om infrastructuur te creëren
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Voer de volgende commandos in om de infrastructuur te creëren.
+
+```sh
+# Installeer vereiste plug-ins
+terraform init
+
+# Bekijk het plan voor bronnen die gecreëerd worden
+terraform plan
+
+# Creëer de bronnen (verwacht dat het tot 30 minuten duurt)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Creëer de Kubernetes-componenten voor de Indexer
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Starten vanuit source
+
+#### Installeer vereisten
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start een PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Nu alle afhankelijkheden zijn ingesteld, start de Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Starten met Docker
+
+#### Prerequisites
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Setup
+
+1. Kloon Graph Node en navigeer naar de Docker map:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Start een lokale Graph Node die verbeiding maakt met uw Ethereum endpoint:
+
+```sh
+docker-compose up
+```
+
+### De componenten van de Indexer
+
+Om succesvol deel te nemen aan het netwerk is bijna constante monitoring en interactie nodig, dus we hebben een reeks Typescript applicaties ontwikkeld om deelname van Indexeerders aan het netwerk te vergemakkelijken. De indexer heeft drie componenten:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Aan de slag
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### Met NPM-pakketten
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is een plug-in voor Graph CLI, dus beide moeten worden geïnstalleerd:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+# Stuur de poort van uw agent pod door als u Kubernetes gebruikt
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### Met source-code
+
+```sh
+# Vanuit de hoofdmap van de repository
+yarn
+
+# Indexer service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Met Docker
+
+- Haal de images uit het register
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Of bouw imagines lokaal vanuit source
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Zet de componenten aan
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Met K8s en Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Usage
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexer Agent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer Service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Indexer management using Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Usage
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Indexing rules
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Data model:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Example usage of indexing rule:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Action added to the queue by the 3rd party optimizer tool or indexer-cli user
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken.
+
+Data model:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Example usage from source:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Note that supported action types for allocation management have different input requirements:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - required action params:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - required action params:
+    - allocationID
+    - deploymentID
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - required action params:
+    - allocationID
+    - deploymentID
+    - amount
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+#### Cost models
+
+Cost models provide dynamic pricing for queries based on market and query attributes. The Indexer Service shares a cost model with the gateways for each subgraph for which they intend to respond to queries. The gateways, in turn, use the cost model to make Indexer selection decisions per query and to negotiate payment with chosen Indexers.
+
+#### Agora
+
+The Agora language provides a flexible format for declaring cost models for queries. An Agora price model is a sequence of statements that execute in order for each top-level query in a GraphQL query. For each top-level query, the first statement which matches it determines the price for that query.
+
+A statement is comprised of a predicate, which is used for matching GraphQL queries, and a cost expression which when evaluated outputs a cost in decimal GRT. Values in the named argument position of a query may be captured in the predicate and used in the expression. Globals may also be set and substituted in for placeholders in an expression.
+
+Example cost model:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Example query costing using the above model:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Applying the cost model
+
+Cost models are applied via the Indexer CLI, which passes them to the Indexer Management API of the Indexer agent for storing in the database. The Indexer Service will then pick them up and serve the cost models to gateways whenever they ask for them.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interacting with the network
+
+### Stake in the protocol
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Approve tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Stake tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### The life of an allocation
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From d31382011562cefd4694bc1c70ddf91f9b67a167 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:06 -0500
Subject: [PATCH 0814/3820] New translations tap.mdx (Dutch)

---
 website/pages/nl/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/nl/indexing/tap.mdx

diff --git a/website/pages/nl/indexing/tap.mdx b/website/pages/nl/indexing/tap.mdx
new file mode 100644
index 000000000000..3bab672ab211
--- /dev/null
+++ b/website/pages/nl/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Overview
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notes:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From f9785f5558b6dbe5fcb9bbd27c934e77a12c5d55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:07 -0500
Subject: [PATCH 0815/3820] New translations graph-node.mdx (Dutch)

---
 .../pages/nl/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/nl/indexing/tooling/graph-node.mdx

diff --git a/website/pages/nl/indexing/tooling/graph-node.mdx b/website/pages/nl/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..e8df054acf64
--- /dev/null
+++ b/website/pages/nl/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL database
+
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
+
+### Network clients
+
+In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS Nodes
+
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+### Prometheus metrics server
+
+To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
+
+### Starten vanuit source
+
+#### Installeer vereisten
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start een PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Nu alle afhankelijkheden zijn ingesteld, start de Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Getting started with Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+When it is running Graph Node exposes the following ports:
+
+| Poort | Doel                                                | Routes                                         | CLI-Argument       | Omgevingsvariabele |
+| ----- | --------------------------------------------------- | ---------------------------------------------- | ------------------ | ------------------ |
+| 8000  | GraphQL HTTP server<br />(voor subgraph query's)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                  |
+| 8001  | GraphQL WS<br />(voor subgraph abonnementen)        | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                  |
+| 8020  | JSON-RPC<br />(voor het beheren van implementaties) | /                                              | \--admin-port      | -                  |
+| 8030  | Subgraph indexeerstatus API                         | /graphql                                       | \--index-node-port | -                  |
+| 8040  | Prometheus metrics                                  | /metrics                                       | \--metrics-port    | -                  |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Advanced Graph Node configuration
+
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Multiple Graph Nodes
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding.
+
+#### Deployment rules
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Example deployment rule configuration:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Dedicated query nodes
+
+Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Any node whose --node-id matches the regular expression will be set up to only respond to queries.
+
+#### Database scaling via sharding
+
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore.
+
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Dedicated block ingestion
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Supporting multiple networks
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Multiple networks
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Environment variables
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Continuous deployment
+
+Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Managing Graph Node
+
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Working with subgraphs
+
+#### Indexing status API
+
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Indexing performance
+
+There are three separate parts of the indexing process:
+
+- Fetching events of interest from the provider
+- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
+- Writing the resulting data to the store
+
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+
+Common causes of indexing slowness:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- A large number of events to process
+- Slow database connection time, for crowded nodes
+- The provider itself falling behind the chain head
+- Slowness in fetching new receipts at the chain head from the provider
+
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+
+#### Failed subgraphs
+
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+
+- Deterministic failures: these are failures which will not be resolved with retries
+- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
+
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Block and call cache
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. If the block matches the provider, then the issue can be debugged directly against the provider.
+
+#### Querying issues and errors
+
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+
+However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+
+There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.
+
+##### Query caching
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analysing queries
+
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
+
+In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
+
+##### Account-like optimisation
+
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Removing subgraphs
+
+> This is new functionality, which will be available in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 01a082f46c4181f47f6f4463ed2bb38e9fca1ffe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:08 -0500
Subject: [PATCH 0816/3820] New translations advanced.mdx (Dutch)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/nl/subgraphs/developing/creating/advanced.mdx b/website/pages/nl/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..a6a4b224bc3e
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Overview
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Non-fatal errors
+
+Indexing errors on already synced subgraphs will, by default, cause the subgraph to fail and stop syncing. Subgraphs can alternatively be configured to continue syncing in the presence of errors, by ignoring the changes made by the handler which provoked the error. This gives subgraph authors time to correct their subgraphs while queries continue to be served against the latest block, though the results might be inconsistent due to the bug that caused the error. Note that some errors are still always fatal. To be non-fatal, the error must be known to be deterministic.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Enabling non-fatal errors requires setting the following feature flag on the subgraph manifest:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way. File data sources support fetching files from IPFS and from Arweave.
+
+> This also lays the groundwork for deterministic indexing of off-chain data, as well as the potential introduction of arbitrary HTTP-sourced data.
+
+### Overview
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Upgrade guide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Add a new entity type which will be updated when files are found
+
+File data sources cannot access or update chain-based entities, but must update file specific entities.
+
+This may mean splitting out fields from existing entities into separate entities, linked together.
+
+Original combined entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+New, split entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+If the relationship is 1:1 between the parent entity and the resulting file data source entity, the simplest pattern is to link the parent entity to a resulting file entity by using the IPFS CID as the lookup. Get in touch on Discord if you are having difficulty modelling your new file-based entities!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+This is the data source which will be spawned when a file of interest is identified.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Create a new handler to process files
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Example handler:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Spawn file data sources when required
+
+You can now create file data sources during execution of chain-based handlers:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Example:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+This will create a new file data source, which will poll Graph Node's configured IPFS or Arweave endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Congratulations, you are using file data sources!
+
+#### Deploying your subgraphs
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitations
+
+File data source handlers and entities are isolated from other subgraph entities, ensuring that they are deterministic when executed, and ensuring no contamination of chain-based data sources. To be specific:
+
+- Entities created by File Data Sources are immutable, and cannot be updated
+- File Data Source handlers cannot access entities from other file data sources
+- Entities associated with File Data Sources cannot be accessed by chain-based handlers
+
+> While this constraint should not be problematic for most use-cases, it may introduce complexity for some. Please get in touch via Discord if you are having issues modelling your file-based data in a subgraph!
+
+Additionally, it is not possible to create data sources from a file data source, be it an onchain data source or another file data source. This restriction may be lifted in the future.
+
+#### Best practices
+
+If you are linking NFT metadata to corresponding tokens, use the metadata's IPFS hash to reference a Metadata entity from the Token entity. Save the Metadata entity using the IPFS hash as an ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> We are working to improve the above recommendation, so queries only return the "most recent" version
+
+#### Known issues
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Examples
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### References
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Grafting onto Existing Subgraphs
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Because grafting copies rather than indexes base data, it is much quicker to get the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From b68154b84daeb390f69b70e582bdd425de99b877 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:10 -0500
Subject: [PATCH 0817/3820] New translations api.mdx (Dutch)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/nl/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/nl/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..5cd8ab120b25
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API Reference
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- Low-level primitives to translate between different type systems such as Ethereum, JSON, GraphQL and AssemblyScript.
+
+### Versions
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| Version | Release notes                                                                                                                                                                                                                                            |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### Built-in Types
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Creating entities
+
+The following is a common pattern for creating entities from Ethereum events.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Loading entities from the store
+
+If an entity already exists, it can be loaded from the store with the following:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Looking up entities created withing a block
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### Updating existing entities
+
+There are two ways to update an existing entity:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+Changing properties is straight forward in most cases, thanks to the generated property setters:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+It is also possible to unset properties with one of the following two instructions:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Removing entities from the store
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
+
+#### Support for Ethereum Types
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+The following example illustrates this. Given a subgraph schema like
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Events and Block/Transaction Data
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Access to Smart Contract State
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+A common pattern is to access the contract from which an event originates. This is achieved with the following code:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address.
+
+#### Handling Reverted Calls
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Encoding/Decoding ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+For more information:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Logging one or more values
+
+##### Logging a single value
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Logging a single entry from an existing array
+
+In the example below, only the first value of the argument array is logged, despite the array containing three values.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Logging multiple entries from an existing array
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Logging a specific entry from an existing array
+
+To display a specific value in the array, the indexed value must be provided.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Logging event information
+
+The example below logs the block number, block hash and transaction hash from an event:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Given an IPFS hash or path, reading a file from IPFS is done as follows:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### Type Conversions Reference
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### Data Source Metadata
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entity and DataSourceContext
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From a58a22fb3b98f0be1554cde902f4e1db17269d5c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:11 -0500
Subject: [PATCH 0818/3820] New translations common-issues.mdx (Dutch)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/nl/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/nl/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..f8d0c9c004c2
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Common AssemblyScript Issues
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 7c7c2ef51b52d2c72df24f38b22fd2a547a829f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:12 -0500
Subject: [PATCH 0819/3820] New translations unit-testing-framework.mdx (Dutch)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/nl/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/nl/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..2133c1d4b5c9
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Unit Testing Framework
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Getting Started
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+or
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+This will run all tests in the test folder:
+
+```sh
+graph test
+```
+
+This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
+
+```sh
+graph test gravity
+```
+
+This will run only that specific test file:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo subgraph
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Video tutorials
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+or
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Examples:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Example:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Examples:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Write a Unit Test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Assuming we have the following handler function (along with two helper functions to make our life easier):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+We first have to create a test file in our project. This is an example of how that might look like:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- We're setting up our initial state and adding one custom Gravatar entity;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- We assert the state of the store. How does that work? - We're passing a unique combination of Entity type and id. Then we check a specific field on that Entity and assert that it has the value we expect it to have. We're doing this both for the initial Gravatar Entity we added to the store, as well as the two Gravatar entities that gets added when the handler function is called;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+There we go - we've created our first test! 👏
+
+Now in order to run our tests you simply need to run the following in your subgraph root folder:
+
+`graph test Gravity`
+
+And if all goes well you should be greeted with the following:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Common test scenarios
+
+### Hydrating the store with a certain state
+
+Users are able to hydrate the store with a known set of entities. Here's an example to initialise the store with a Gravatar entity:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Calling a mapping function with an event
+
+A user can create a custom event and pass it to a mapping function that is bound to the store:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Calling all of the mappings with event fixtures
+
+Users can call the mappings with test fixtures.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocking contract calls
+
+Users can mock contract calls:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+As demonstrated, in order to mock a contract call and hardcore a return value, the user must provide a contract address, function name, function signature, an array of arguments, and of course - the return value.
+
+Users can also mock function reverts:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking IPFS files (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Asserting the state of the store
+
+Users are able to assert the final (or midway) state of the store through asserting entities. In order to do this, the user has to supply an Entity type, the specific ID of an Entity, a name of a field on that Entity, and the expected value of the field. Here's a quick example:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interacting with Event metadata
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Asserting variable equality
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Users can assert that an entity does not exist in the store. The function takes an entity type and an id. If the entity is in fact in the store, the test will fail with a relevant error message. Here's a quick example of how to use this functionality:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+You can print the whole store to the console using this helper function:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Expected failure
+
+Users can have expected test failures, using the shouldFail flag on the test() functions:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+If the test is marked with shouldFail = true but DOES NOT fail, that will show up as an error in the logs and the test block will fail. Also, if it's marked with shouldFail = false (the default state), the test executor will crash.
+
+### Logging
+
+Having custom logs in the unit tests is exactly the same as logging in the mappings. The difference is that the log object needs to be imported from matchstick-as rather than graph-ts. Here's a simple example with all non-critical log types:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Users can also simulate a critical failure, like so:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Logging critical errors will stop the execution of the tests and blow everything up. After all - we want to make sure you're code doesn't have critical logs in deployment, and you should notice right away if that were to happen.
+
+### Testing derived fields
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testing dynamic data sources
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Example below:
+
+First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+And then we have the test using one of the methods in the dataSourceMock namespace to set a new return value for all of the dataSource functions:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Notice that dataSourceMock.resetValues() is called at the end. That's because the values are remembered when they are changed and need to be reset if you want to go back to the default values.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Test Coverage
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Prerequisites
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Export your handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Usage
+
+Once that's all set up, to run the test coverage tool, simply run:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Test run time duration in the log output
+
+The log output includes the test run duration. Here's an example:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Common compiler errors
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Additional Resources
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Feedback
+
+If you have any questions, feedback, feature requests or just want to reach out, the best place would be The Graph Discord where we have a dedicated channel for Matchstick, called 🔥| unit-testing.

From a94b167ed9733308b60526331d31cd4d9152ac2c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:13 -0500
Subject: [PATCH 0820/3820] New translations transferring-a-subgraph.mdx
 (Dutch)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/nl/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/nl/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From e5e525850f24b780ceaf7f0bbe2a2fa1a3b54704 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:14 -0500
Subject: [PATCH 0821/3820] New translations graphql-api.mdx (Dutch)

---
 .../nl/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/nl/subgraphs/querying/graphql-api.mdx b/website/pages/nl/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..2ffcb85e4019
--- /dev/null
+++ b/website/pages/nl/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Examples
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sorting
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Example
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Example for nested entity sorting
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Pagination
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Query the first 10 tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtering
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Example for range filtering
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for block filtering
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for nested entity filtering
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+This can be useful if you are looking to fetch only entities whose child-level entities meet the provided conditions.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logical operators
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### All Filters
+
+Full list of parameter suffixes:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Time-travel queries
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltext Search Queries
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Fulltext search operators:
+
+| Symbol | Operator    | Description                                                                                                                          |
+| ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
+
+#### Examples
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validation
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Subgraph Metadata
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: the hash of the block
+- number: the block number
+- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 908cb67589c7ba5234673645e71af4af5a36b216 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:15 -0500
Subject: [PATCH 0822/3820] New translations python.mdx (Dutch)

---
 .../pages/nl/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/querying/python.mdx

diff --git a/website/pages/nl/subgraphs/querying/python.mdx b/website/pages/nl/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..c10d7a0e57ab
--- /dev/null
+++ b/website/pages/nl/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Getting Started
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 1bedefc9f98856266c0852520e20c95072f47449 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:16 -0500
Subject: [PATCH 0823/3820] New translations triggers.mdx (Dutch)

---
 website/pages/nl/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/nl/substreams/sps/triggers.mdx

diff --git a/website/pages/nl/substreams/sps/triggers.mdx b/website/pages/nl/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/nl/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 370e2842109d0187bdcd9de3c98aebe11a58d639 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:17 -0500
Subject: [PATCH 0824/3820] New translations overview.mdx (Polish)

---
 website/pages/pl/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/pl/indexing/overview.mdx

diff --git a/website/pages/pl/indexing/overview.mdx b/website/pages/pl/indexing/overview.mdx
new file mode 100644
index 000000000000..ced5ed20026b
--- /dev/null
+++ b/website/pages/pl/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+
+GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.
+
+Indexers select subgraphs to index based on the subgraph’s curation signal, where Curators stake GRT in order to indicate which subgraphs are high-quality and should be prioritized. Consumers (eg. applications) can also set parameters for which Indexers process queries for their subgraphs and set preferences for query fee pricing.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### What is the minimum stake required to be an Indexer on the network?
+
+The minimum stake for an Indexer is currently set to 100K GRT.
+
+### What are the revenue streams for an Indexer?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### How are indexing rewards distributed?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### What is a proof of indexing (POI)?
+
+POIs are used in the network to verify that an Indexer is indexing the subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific subgraph deployment up to and including that block.
+
+### When are indexing rewards distributed?
+
+Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).
+
+### Can pending indexing rewards be monitored?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Many of the community-made dashboards include pending rewards values and they can be easily checked manually by following these steps:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### What are disputes and where can I view them?
+
+Indexer's queries and allocations can both be disputed on The Graph during the dispute period. The dispute period varies, depending on the type of dispute. Queries/attestations have 7 epochs dispute window, whereas allocations have 56 epochs. After these periods pass, disputes cannot be opened against either of allocations or queries. When a dispute is opened, a deposit of a minimum of 10,000 GRT is required by the Fishermen, which will be locked until the dispute is finalized and a resolution has been given. Fisherman are any network participants that open disputes.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- If the dispute is rejected, the GRT deposited by the Fishermen will be burned, and the disputed Indexer will not be slashed.
+- If the dispute is settled as a draw, the Fishermen's deposit will be returned, and the disputed Indexer will not be slashed.
+- If the dispute is accepted, the GRT deposited by the Fishermen will be returned, the disputed Indexer will be slashed and the Fishermen will earn 50% of the slashed GRT.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### What are query fee rebates and when are they distributed?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+
+### What is query fee cut and indexing reward cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### How do Indexers know which subgraphs to index?
+
+Indexers may differentiate themselves by applying advanced techniques for making subgraph indexing decisions but to give a general idea we'll discuss several key metrics used to evaluate subgraphs in the network:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### What are the hardware requirements?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- | :------------------: | :---------------------------: | :-------------------------: | :-------------: | :----------------------: |
+| Small    |           4          |               8               |              1              |        4        |            16            |
+| Standard |           8          |               30              |              1              |        12       |            48            |
+| Medium   |          16          |               64              |              2              |        32       |            64            |
+| Large    |          72          |              468              |             3.5             |        48       |            184           |
+
+### What are some basic security precautions an Indexer should take?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastructure
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Note: To support agile scaling, it is recommended that query and indexing concerns are separated between different sets of nodes: query nodes and index nodes.
+
+### Ports overview
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Port | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
+
+#### Indexer Service
+
+| Port | Purpose                                              | Routes                                                      | CLI Argument    | Environment Variable   |
+| ---- | ---------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                   | /metrics                                                    | \--metrics-port | -                      |
+
+#### Indexer Agent
+
+| Port | Purpose                | Routes | CLI Argument               | Environment Variable                    |
+| ---- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | Indexer management API | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Setup server infrastructure using Terraform on Google Cloud
+
+> Note: Indexers can alternatively use AWS, Microsoft Azure, or Alibaba.
+
+#### Install prerequisites
+
+- Google Cloud SDK
+- Kubectl command line tool
+- Terraform
+
+#### Create a Google Cloud Project
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Authenticate with Google Cloud and create a new project.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Use the Google Cloud Console's billing page to enable billing for the new project.
+
+- Create a Google Cloud configuration.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Enable required Google Cloud APIs.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Create a service account.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Enable peering between database and Kubernetes cluster that will be created in the next step.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Create minimal terraform configuration file (update as needed).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Use Terraform to create infrastructure
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Run the following commands to create the infrastructure.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Creating the Kubernetes components for the Indexer
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Getting started from source
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start a PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Now that all the dependencies are setup, start the Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Getting started using Docker
+
+#### Prerequisites
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Setup
+
+1. Clone Graph Node and navigate to the Docker directory:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Start a local Graph Node that will connect to your Ethereum endpoint:
+
+```sh
+docker-compose up
+```
+
+### Indexer components
+
+To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Getting started
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### From NPM packages
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### From source
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Using docker
+
+- Pull images from the registry
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Or build images locally from source
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Run the components
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Using K8s and Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Usage
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexer agent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Indexer management using Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Usage
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Indexing rules
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Data model:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Example usage of indexing rule:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Action added to the queue by the 3rd party optimizer tool or indexer-cli user
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken.
+
+Data model:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Example usage from source:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Note that supported action types for allocation management have different input requirements:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - required action params:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - required action params:
+    - allocationID
+    - deploymentID
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - required action params:
+    - allocationID
+    - deploymentID
+    - amount
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+#### Cost models
+
+Cost models provide dynamic pricing for queries based on market and query attributes. The Indexer Service shares a cost model with the gateways for each subgraph for which they intend to respond to queries. The gateways, in turn, use the cost model to make Indexer selection decisions per query and to negotiate payment with chosen Indexers.
+
+#### Agora
+
+The Agora language provides a flexible format for declaring cost models for queries. An Agora price model is a sequence of statements that execute in order for each top-level query in a GraphQL query. For each top-level query, the first statement which matches it determines the price for that query.
+
+A statement is comprised of a predicate, which is used for matching GraphQL queries, and a cost expression which when evaluated outputs a cost in decimal GRT. Values in the named argument position of a query may be captured in the predicate and used in the expression. Globals may also be set and substituted in for placeholders in an expression.
+
+Example cost model:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Example query costing using the above model:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Applying the cost model
+
+Cost models are applied via the Indexer CLI, which passes them to the Indexer Management API of the Indexer agent for storing in the database. The Indexer Service will then pick them up and serve the cost models to gateways whenever they ask for them.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interacting with the network
+
+### Stake in the protocol
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Approve tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Stake tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### The life of an allocation
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 8f62ac1650d58b71edd3e5919fa56e85842eebcc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:19 -0500
Subject: [PATCH 0825/3820] New translations tap.mdx (Polish)

---
 website/pages/pl/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/pl/indexing/tap.mdx

diff --git a/website/pages/pl/indexing/tap.mdx b/website/pages/pl/indexing/tap.mdx
new file mode 100644
index 000000000000..3bab672ab211
--- /dev/null
+++ b/website/pages/pl/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Overview
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notes:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From ffe62b603b2377ab8f9b80736abef36139dbd583 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:20 -0500
Subject: [PATCH 0826/3820] New translations graph-node.mdx (Polish)

---
 .../pages/pl/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/pl/indexing/tooling/graph-node.mdx

diff --git a/website/pages/pl/indexing/tooling/graph-node.mdx b/website/pages/pl/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..6a27301b680b
--- /dev/null
+++ b/website/pages/pl/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL database
+
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
+
+### Network clients
+
+In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS Nodes
+
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+### Prometheus metrics server
+
+To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
+
+### Getting started from source
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start a PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Now that all the dependencies are setup, start the Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Getting started with Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+When it is running Graph Node exposes the following ports:
+
+| Port | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Advanced Graph Node configuration
+
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Multiple Graph Nodes
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding.
+
+#### Deployment rules
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Example deployment rule configuration:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Dedicated query nodes
+
+Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Any node whose --node-id matches the regular expression will be set up to only respond to queries.
+
+#### Database scaling via sharding
+
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore.
+
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Dedicated block ingestion
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Supporting multiple networks
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Multiple networks
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Environment variables
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Continuous deployment
+
+Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Managing Graph Node
+
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Working with subgraphs
+
+#### Indexing status API
+
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Indexing performance
+
+There are three separate parts of the indexing process:
+
+- Fetching events of interest from the provider
+- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
+- Writing the resulting data to the store
+
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+
+Common causes of indexing slowness:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- A large number of events to process
+- Slow database connection time, for crowded nodes
+- The provider itself falling behind the chain head
+- Slowness in fetching new receipts at the chain head from the provider
+
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+
+#### Failed subgraphs
+
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+
+- Deterministic failures: these are failures which will not be resolved with retries
+- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
+
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Block and call cache
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. If the block matches the provider, then the issue can be debugged directly against the provider.
+
+#### Querying issues and errors
+
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+
+However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+
+There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.
+
+##### Query caching
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analysing queries
+
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
+
+In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
+
+##### Account-like optimisation
+
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Removing subgraphs
+
+> This is new functionality, which will be available in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 789218b28df20147f9ae6f6cc83dc9fd7ce30373 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:21 -0500
Subject: [PATCH 0827/3820] New translations advanced.mdx (Polish)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/pl/subgraphs/developing/creating/advanced.mdx b/website/pages/pl/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..a6a4b224bc3e
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Overview
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Non-fatal errors
+
+Indexing errors on already synced subgraphs will, by default, cause the subgraph to fail and stop syncing. Subgraphs can alternatively be configured to continue syncing in the presence of errors, by ignoring the changes made by the handler which provoked the error. This gives subgraph authors time to correct their subgraphs while queries continue to be served against the latest block, though the results might be inconsistent due to the bug that caused the error. Note that some errors are still always fatal. To be non-fatal, the error must be known to be deterministic.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Enabling non-fatal errors requires setting the following feature flag on the subgraph manifest:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way. File data sources support fetching files from IPFS and from Arweave.
+
+> This also lays the groundwork for deterministic indexing of off-chain data, as well as the potential introduction of arbitrary HTTP-sourced data.
+
+### Overview
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Upgrade guide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Add a new entity type which will be updated when files are found
+
+File data sources cannot access or update chain-based entities, but must update file specific entities.
+
+This may mean splitting out fields from existing entities into separate entities, linked together.
+
+Original combined entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+New, split entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+If the relationship is 1:1 between the parent entity and the resulting file data source entity, the simplest pattern is to link the parent entity to a resulting file entity by using the IPFS CID as the lookup. Get in touch on Discord if you are having difficulty modelling your new file-based entities!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+This is the data source which will be spawned when a file of interest is identified.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Create a new handler to process files
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Example handler:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Spawn file data sources when required
+
+You can now create file data sources during execution of chain-based handlers:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Example:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+This will create a new file data source, which will poll Graph Node's configured IPFS or Arweave endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Congratulations, you are using file data sources!
+
+#### Deploying your subgraphs
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitations
+
+File data source handlers and entities are isolated from other subgraph entities, ensuring that they are deterministic when executed, and ensuring no contamination of chain-based data sources. To be specific:
+
+- Entities created by File Data Sources are immutable, and cannot be updated
+- File Data Source handlers cannot access entities from other file data sources
+- Entities associated with File Data Sources cannot be accessed by chain-based handlers
+
+> While this constraint should not be problematic for most use-cases, it may introduce complexity for some. Please get in touch via Discord if you are having issues modelling your file-based data in a subgraph!
+
+Additionally, it is not possible to create data sources from a file data source, be it an onchain data source or another file data source. This restriction may be lifted in the future.
+
+#### Best practices
+
+If you are linking NFT metadata to corresponding tokens, use the metadata's IPFS hash to reference a Metadata entity from the Token entity. Save the Metadata entity using the IPFS hash as an ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> We are working to improve the above recommendation, so queries only return the "most recent" version
+
+#### Known issues
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Examples
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### References
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Grafting onto Existing Subgraphs
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Because grafting copies rather than indexes base data, it is much quicker to get the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From e0645f347ab82fca9f458b1beb86eaa79a55b131 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:22 -0500
Subject: [PATCH 0828/3820] New translations api.mdx (Polish)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/pl/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/pl/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..5cd8ab120b25
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API Reference
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- Low-level primitives to translate between different type systems such as Ethereum, JSON, GraphQL and AssemblyScript.
+
+### Versions
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| Version | Release notes                                                                                                                                                                                                                                            |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### Built-in Types
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Creating entities
+
+The following is a common pattern for creating entities from Ethereum events.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Loading entities from the store
+
+If an entity already exists, it can be loaded from the store with the following:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Looking up entities created withing a block
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### Updating existing entities
+
+There are two ways to update an existing entity:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+Changing properties is straight forward in most cases, thanks to the generated property setters:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+It is also possible to unset properties with one of the following two instructions:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Removing entities from the store
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
+
+#### Support for Ethereum Types
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+The following example illustrates this. Given a subgraph schema like
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Events and Block/Transaction Data
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Access to Smart Contract State
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+A common pattern is to access the contract from which an event originates. This is achieved with the following code:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address.
+
+#### Handling Reverted Calls
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Encoding/Decoding ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+For more information:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Logging one or more values
+
+##### Logging a single value
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Logging a single entry from an existing array
+
+In the example below, only the first value of the argument array is logged, despite the array containing three values.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Logging multiple entries from an existing array
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Logging a specific entry from an existing array
+
+To display a specific value in the array, the indexed value must be provided.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Logging event information
+
+The example below logs the block number, block hash and transaction hash from an event:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Given an IPFS hash or path, reading a file from IPFS is done as follows:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### Type Conversions Reference
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### Data Source Metadata
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entity and DataSourceContext
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From ddbe694d183d3272a42f175e4e9b77a6e0635213 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:23 -0500
Subject: [PATCH 0829/3820] New translations common-issues.mdx (Polish)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/pl/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/pl/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..f8d0c9c004c2
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Common AssemblyScript Issues
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 3067c8311b86c4a4798b41ad4a13347f3b0292c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:24 -0500
Subject: [PATCH 0830/3820] New translations unit-testing-framework.mdx
 (Polish)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/pl/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/pl/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..2133c1d4b5c9
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Unit Testing Framework
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Getting Started
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+or
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+This will run all tests in the test folder:
+
+```sh
+graph test
+```
+
+This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
+
+```sh
+graph test gravity
+```
+
+This will run only that specific test file:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo subgraph
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Video tutorials
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+or
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Examples:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Example:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Examples:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Write a Unit Test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Assuming we have the following handler function (along with two helper functions to make our life easier):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+We first have to create a test file in our project. This is an example of how that might look like:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- We're setting up our initial state and adding one custom Gravatar entity;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- We assert the state of the store. How does that work? - We're passing a unique combination of Entity type and id. Then we check a specific field on that Entity and assert that it has the value we expect it to have. We're doing this both for the initial Gravatar Entity we added to the store, as well as the two Gravatar entities that gets added when the handler function is called;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+There we go - we've created our first test! 👏
+
+Now in order to run our tests you simply need to run the following in your subgraph root folder:
+
+`graph test Gravity`
+
+And if all goes well you should be greeted with the following:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Common test scenarios
+
+### Hydrating the store with a certain state
+
+Users are able to hydrate the store with a known set of entities. Here's an example to initialise the store with a Gravatar entity:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Calling a mapping function with an event
+
+A user can create a custom event and pass it to a mapping function that is bound to the store:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Calling all of the mappings with event fixtures
+
+Users can call the mappings with test fixtures.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocking contract calls
+
+Users can mock contract calls:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+As demonstrated, in order to mock a contract call and hardcore a return value, the user must provide a contract address, function name, function signature, an array of arguments, and of course - the return value.
+
+Users can also mock function reverts:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking IPFS files (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Asserting the state of the store
+
+Users are able to assert the final (or midway) state of the store through asserting entities. In order to do this, the user has to supply an Entity type, the specific ID of an Entity, a name of a field on that Entity, and the expected value of the field. Here's a quick example:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interacting with Event metadata
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Asserting variable equality
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Users can assert that an entity does not exist in the store. The function takes an entity type and an id. If the entity is in fact in the store, the test will fail with a relevant error message. Here's a quick example of how to use this functionality:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+You can print the whole store to the console using this helper function:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Expected failure
+
+Users can have expected test failures, using the shouldFail flag on the test() functions:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+If the test is marked with shouldFail = true but DOES NOT fail, that will show up as an error in the logs and the test block will fail. Also, if it's marked with shouldFail = false (the default state), the test executor will crash.
+
+### Logging
+
+Having custom logs in the unit tests is exactly the same as logging in the mappings. The difference is that the log object needs to be imported from matchstick-as rather than graph-ts. Here's a simple example with all non-critical log types:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Users can also simulate a critical failure, like so:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Logging critical errors will stop the execution of the tests and blow everything up. After all - we want to make sure you're code doesn't have critical logs in deployment, and you should notice right away if that were to happen.
+
+### Testing derived fields
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testing dynamic data sources
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Example below:
+
+First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+And then we have the test using one of the methods in the dataSourceMock namespace to set a new return value for all of the dataSource functions:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Notice that dataSourceMock.resetValues() is called at the end. That's because the values are remembered when they are changed and need to be reset if you want to go back to the default values.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Test Coverage
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Prerequisites
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Export your handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Usage
+
+Once that's all set up, to run the test coverage tool, simply run:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Test run time duration in the log output
+
+The log output includes the test run duration. Here's an example:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Common compiler errors
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Additional Resources
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Feedback
+
+If you have any questions, feedback, feature requests or just want to reach out, the best place would be The Graph Discord where we have a dedicated channel for Matchstick, called 🔥| unit-testing.

From 5c8440afaf9386b49d94f746d51f5c6a34394ff3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:26 -0500
Subject: [PATCH 0831/3820] New translations transferring-a-subgraph.mdx
 (Polish)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/pl/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/pl/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 4edfeb5db9ed7bdb701a751aec41672cbe30857c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:27 -0500
Subject: [PATCH 0832/3820] New translations graphql-api.mdx (Polish)

---
 .../pl/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/pl/subgraphs/querying/graphql-api.mdx b/website/pages/pl/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..2ffcb85e4019
--- /dev/null
+++ b/website/pages/pl/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Examples
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sorting
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Example
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Example for nested entity sorting
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Pagination
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Query the first 10 tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtering
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Example for range filtering
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for block filtering
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for nested entity filtering
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+This can be useful if you are looking to fetch only entities whose child-level entities meet the provided conditions.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logical operators
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### All Filters
+
+Full list of parameter suffixes:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Time-travel queries
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltext Search Queries
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Fulltext search operators:
+
+| Symbol | Operator    | Description                                                                                                                          |
+| ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
+
+#### Examples
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validation
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Subgraph Metadata
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: the hash of the block
+- number: the block number
+- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From c29b91d971acc4cd32b87498dc5bdee84af62db0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:28 -0500
Subject: [PATCH 0833/3820] New translations python.mdx (Polish)

---
 .../pages/pl/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/querying/python.mdx

diff --git a/website/pages/pl/subgraphs/querying/python.mdx b/website/pages/pl/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..c10d7a0e57ab
--- /dev/null
+++ b/website/pages/pl/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Getting Started
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 9c23b701f1d05abb23967a5bb20a9baf22a3f80e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:29 -0500
Subject: [PATCH 0834/3820] New translations triggers.mdx (Polish)

---
 website/pages/pl/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/pl/substreams/sps/triggers.mdx

diff --git a/website/pages/pl/substreams/sps/triggers.mdx b/website/pages/pl/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/pl/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From e3b85ab78202cf85cb829defaff538d361b7a6f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:30 -0500
Subject: [PATCH 0835/3820] New translations overview.mdx (Portuguese)

---
 website/pages/pt/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/pt/indexing/overview.mdx

diff --git a/website/pages/pt/indexing/overview.mdx b/website/pages/pt/indexing/overview.mdx
new file mode 100644
index 000000000000..a9b2bc304e84
--- /dev/null
+++ b/website/pages/pt/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexadores são operadores de nodes na Graph Network que fazem staking em Graph Tokens (GRT) para prover serviços de indexação e processamento de consultas em query (queries). Os indexadores ganham taxas de consulta e recompensas de indexação pelos seus serviços. Eles também ganham taxas de query que são rebatadas de acordo com uma função de rebate exponencial.
+
+O GRT em staking no protocolo é sujeito a um período de degelo, e pode passar por slashing (recolhimento de fundos) se algum Indexador maliciosamente servir dados incorretos para aplicativos ou indexar incorretamente. Os Indexadores também recebem recompensas dos Delegantes por stake delegado, para contribuir à rede.
+
+Indexadores selecionam subgraphs para indexar com base no sinal de curadoria do subgraph, onde Curadores depositam GRT em staking para indicar quais subgraphs são de qualidade alta e devem ser priorizados. Consumidores (por ex., aplicativos) também podem configurar parâmetros para os quais Indexadores processam queries para seus subgraphs, além de configurar preferências para o preço das taxas de query.
+
+<Difficulty level="ADVANCED" />
+
+## Perguntas Frequentes
+
+### Qual o stake mínimo exigido para ser um Indexador na rede?
+
+O stake mínimo atual para um Indexador é de 100 mil GRT.
+
+### Quais são as fontes de renda para um Indexador?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### Como são distribuídas as recompensas de indexação?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### O que é uma prova de indexação (POI)?
+
+POIs são usadas na rede, para verificar que um Indexador está indexando os subgraphs nos quais eles alocaram. Uma POI para o primeiro bloco da epoch atual deve ser enviada ao fechar uma alocação, para que aquela alocação seja elegível a recompensas de indexação. Uma POI para um bloco serve como resumo para todas as transações de armazenamento de entidade para um lançamento específico de subgraph, até, e incluindo, aquele bloco.
+
+### Quando são distribuídas as recompensas de indexação?
+
+As alocações continuamente acumulam recompensas enquanto permanecerem ativas e alocadas dentro de 28 epochs. As recompensas são coletadas pelos Indexadores, e distribuídas sempre que suas alocações são fechadas. Isto acontece ou manualmente, quando o Indexer quer fechá-las à força; ou após 28 epochs, quando um Delegante pode fechar a alocação para o Indexador, mas isto não rende recompensas. A vida máxima de uma alocação é de 28 epochs (no momento, um epoch dura cerca de 24 horas).
+
+### É possível monitorar recompensas de indexação pendentes?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Muitos dos painéis feitos pela comunidade incluem valores pendentes de recompensas, que podem facilmente ser conferidos de forma manual ao seguir os seguintes passos:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### O que são disputas e onde posso vê-las?
+
+As consultas em query e alocações de Indexadores podem ser disputadas no The Graph durante o período de disputa. O período de disputa varia dependendo do tipo de disputa. Consultas/atestações têm uma janela de disputa de 7 epochs, enquanto alocações duram até 56 epochs. Após o vencimento destes períodos, não se pode abrir disputas contra alocações ou consultas. Quando uma disputa é aberta, um depósito mínimo de 10.000 GRT é exigido pelos Pescadores, que será trancado até ser finalizada a disputa e servida uma resolução. Pescadores são quaisquer participantes de rede que abrem disputas.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- Se a disputa for rejeitada, o GRT depositado pelo Pescador será queimado, e o Indexador disputado não será penalizado.
+- Se a disputa terminar em empate, o depósito do Pescador será retornado, e o Indexador disputado não será penalizado.
+- Caso aceita a disputa, o GRT depositado pelo Pescador será retornado, o Indexador disputado será penalizado, e o(s) Pescador(es) ganhará(ão) 50% do GRT cortado.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### O que são rebates de taxas de consulta e quando eles são distribuídos?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Quando uma alocação é fechada, os rebates podem ser reivindicados pelo Indexador. Ao reivindicar, os rebates de taxa de consulta são distribuídos ao Indexador e os seus Delegantes com base na porção de taxas de consulta e na função de rebate exponencial.
+
+### O que são porção de taxa de consulta e porção de recompensa de indexação?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### Como os Indexadores podem saber quais subgraphs indexar?
+
+Os Indexadores podem se diferenciar ao aplicar técnicas avançadas para decidir indexações de subgraph, mas para dar uma ideia geral, vamos discutir várias métricas importantes usadas para avaliar subgraphs na rede:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### Quais são os requisitos de hardware?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Setup   | Postgres<br />(CPUs) | Postgres<br />(memória em GBs) | Postgres<br />(disco em TBs) | VMs<br />(CPUs) | VMs<br />(memória em GBs) |
+| ------- | :------------------: | :----------------------------: | :--------------------------: | :-------------: | :-----------------------: |
+| Pequeno |           4          |                8               |               1              |        4        |             16            |
+| Normal  |           8          |               30               |               1              |        12       |             48            |
+| Médio   |          16          |               64               |               2              |        32       |             64            |
+| Grande  |          72          |               468              |              3.5             |        48       |            184            |
+
+### Há alguma precaução básica de segurança que um Indexador deve tomar?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infraestutura
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Nota: Para apoiar o escalamento ágil, recomendamos que assuntos de consulta e indexação sejam separados entre conjuntos diferentes de nodes: nodes de consulta e nodes de indexação.
+
+### Resumo das portas
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Porta | Propósito                                               | Rotas                                          | Argumento CLI      | Variável de Ambiente |
+| ----- | ------------------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000  | Servidor HTTP GraphQL<br />(para consultas de subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001  | WS GraphQL<br />(para inscrições a subgraphs)           | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020  | JSON-RPC<br />(para gerir lançamentos)                  | /                                              | \--admin-port      | -                    |
+| 8030  | API de status de indexamento do subgraph                | /graphql                                       | \--index-node-port | -                    |
+| 8040  | Métricas Prometheus                                     | /metrics                                       | \--metrics-port    | -                    |
+
+#### Serviço Indexador
+
+| Porta | Propósito                                                     | Rotas                                                       | Argumento CLI   | Variável de Ambiente   |
+| ----- | ------------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600  | Servidor HTTP GraphQL<br />(para consultas de subgraph pagas) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300  | Métricas Prometheus                                           | /metrics                                                    | \--metrics-port | -                      |
+
+#### Agente Indexador
+
+| Porta | Purpose                    | Rotas  | CLI Argument               | Environment Variable                    |
+| ----- | -------------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000  | API de gestão de Indexador | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Preparando uma infraestrutura de servidor usando o Terraform no Google Cloud
+
+> Nota: Como alternativa, os Indexadores podem usar o AWS, Microsoft Azure, ou Alibaba.
+
+#### Pré-requisitos para a instalação
+
+- Google Cloud SDK
+- Ferramenta de linha de comando Kubectl
+- Terraform
+
+#### Como criar um projeto no Google Cloud
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Autentique como Google Cloud e crie um novo projeto.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Use a página de cobrança do Google Cloud Console para configurar a cobrança para o novo projeto.
+
+- Crie uma configuração no Google Cloud.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Ligue as APIs requeridas do Google Cloud.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Crie uma conta de serviço.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Ligue o peering entre o banco de dados e o cluster Kubernetes, que será criado no próximo passo.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Crie o arquivo de configuração mínimo no terraform (atualize quando necessário).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Usando o Terraform para criar infraestrutura
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Execute os seguintes comandos para criar a infraestrutura.
+
+```sh
+# Instalar os plugins requeridos
+terraform init
+
+# Ver o plano para recursos a ser criados
+terraform plan
+
+# Criar os recursos (isto deve levar até 30 minutos)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Criando os componentes do Kubernetes para o Indexador
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Começando da fonte
+
+#### Pré-requisitos para a instalação
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Comece um servidor de banco de dados PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Agora que todas as dependências estão prontas, inicie o Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Como começar com o Docker
+
+#### Pré-requisitos
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Setup
+
+1. Clone o Graph Node e navegue ao diretório do Docker:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Inicie um Graph Node local que conectará ao seu endpoint no Ethereum:
+
+```sh
+docker-compose up
+```
+
+### Componentes de Indexador
+
+Para participar com êxito na rede, são necessários monitorados e interações quase constantes, portanto, construímos uma suite de aplicativos Typescript para facilitar a participação de um Indexador na rede. Há três componentes de Indexador:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Começando
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### De pacotes NPM
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# O Indexer CLI é um plugin para o Graph CLI, então ambos devem ser instalados:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Serviço Indexador
+graph-indexer-service start ...
+
+# Agente Indexador
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Redirecione a porta do seu agent pod se estiver usando o Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### Da fonte
+
+```sh
+# Do diretório raiz do Repo
+yarn
+
+# Serviço Indexador
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Agente Indexador
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Usando o docker
+
+- Puxe as imagens do registo
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Ou construa imagens localmente da fonte
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Execute os componentes
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Usando K8s e Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Uso
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Agente Indexador
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Serviço Indexador
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Gestão de Indexador usando o Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Uso
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Regras de indexação
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Modelo de dados:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Exemplos de uso de regra de indexação:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### CLI de fila de ações
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Ação adicionada à fila por ferramenta de otimização de terceiros ou utilizador do indexer-cli
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- O indexador pode monitorizar a fila de ações para ver um histórico de execuções de ação, e se necessário, aprovar novamente e atualizar itens de ação caso a sua execução falhe. A fila de ações provém um histórico de todas as ações agendadas e tomadas.
+
+Modelo de dados:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Exemplo de uso da fonte:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Note que os tipos apoiados de ações para gestão de alocação têm requisitos diferentes de entrada:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - parâmetros de ação exigidos:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - parâmetros de ação exigidos:
+    - allocationID
+    - deploymentID
+  - parâmetros de ação opcionais:
+    - poi
+    - force (força o uso do POI providenciado, mesmo se ele não corresponder ao providenciado pelo graph-node)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - parâmetros de ação exigidos:
+    - allocationID
+    - deploymentID
+    - amount
+  - parâmetros de ação opcionais:
+    - poi
+    - force (força o uso do POI providenciado, mesmo se ele não corresponder ao providenciado pelo graph-node)
+
+#### Modelos de custo
+
+Modelos de custo servem preços dinâmicos para queries, com base em atributos de mercado e query. O Serviço de Indexador compartilha um modelo de custo com os gateways para cada subgraph, aos quais ele pretende responder a consultas. Os gateways, por sua vez, usam o modelo de custo para decidir seleções de Indexador por query e para negociar pagamentos com Indexadores escolhidos.
+
+#### Agora
+
+A linguagem Agora providencia um formato flexível para a declaração de modelos de custo para queries. Um modelo de preço do Agora é uma sequência de declarações, executadas em ordem, para cada query de alto-nível em um query no GraphQL. Para cada query de nível máximo, a primeira declaração correspondente determina o preço para o tal query.
+
+Uma declaração consiste de um predicado, que é usado para corresponder a buscas GraphQL; e uma expressão de custo que, quando avaliada, mostra um custo em GRT decimal. Valores na posição de argumento nomeada em um query podem ser capturados no predicado e usados na expressão. Globais também podem ser configurados e substituídos por valores temporários em uma expressão.
+
+Exemplo de modelo de custo:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Exemplo de custo de query usando o modelo acima:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Aplicação do modelo de custo
+
+Os modelos de custo são aplicados através do Indexer CLI, que os repassa à API de Gestão do agente de Indexador para armazenamento no banco de dados. O Serviço de Indexador depois irá localizar e servir os modelos de custo para gateways, sempre que eles forem requisitados.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interações com a rede
+
+### Stake no protocolo
+
+Os primeiros passos para participar como Indexador consistem em aprovar o protocolo, fazer staking de fundos, e (opcionalmente) preparar um endereço de operador para interações ordinárias do protocolo.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Aprovação de tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Staking de tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Configuração de parâmetros de delegação
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### Como configurar parâmetros de delegação
+
+Para configurar os parâmetros de delegação com a interface do Graph Explorer, siga os seguintes passos:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Conecte a sua carteira. Escolha a multisig (por ex., Gnosis Safe) e depois selecione a mainnet. Nota: Será necessário repetir este processo para o Arbitrum One.
+3. Conecte a sua carteira como signatário.
+4. Navegue até a seção 'Settings' (Configurações) e selecione 'Delegation Parameters' (Parâmetros de Delegação). Estes parâmetros devem ser configurados para alcançar uma parte efetiva dentro do alcance desejado. Após preencher os campos com valores, a interface calculará automaticamente a parte efetiva. Ajuste estes valores como necessário para obter a percentagem de parte efetiva desejada.
+5. Envie a transação à rede.
+
+> Nota: Esta transação deverá ser confirmada pelos signatários da carteira multisig.
+
+### A vida de uma alocação
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 6e7ac7789b2fe035abac0c37543d2759c6307264 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:31 -0500
Subject: [PATCH 0836/3820] New translations tap.mdx (Portuguese)

---
 website/pages/pt/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/pt/indexing/tap.mdx

diff --git a/website/pages/pt/indexing/tap.mdx b/website/pages/pt/indexing/tap.mdx
new file mode 100644
index 000000000000..9296595074d3
--- /dev/null
+++ b/website/pages/pt/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Visão geral
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Especificações
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requisitos
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notas:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From 65bf9165b2e4028cdfa15f06d7425fb9efa61dd4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:32 -0500
Subject: [PATCH 0837/3820] New translations graph-node.mdx (Portuguese)

---
 .../pages/pt/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/pt/indexing/tooling/graph-node.mdx

diff --git a/website/pages/pt/indexing/tooling/graph-node.mdx b/website/pages/pt/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..bac51d4c0ac8
--- /dev/null
+++ b/website/pages/pt/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+O Node do The Graph (Graph Node) é o componente que indexa subgraphs e disponibiliza os dados resultantes a queries (consultas de dados) através de uma API GraphQL. Assim, ele é central ao stack dos indexers, e é crucial fazer operações corretas com um node Graph para executar um indexer com êxito.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### Banco de dados PostgreSQL
+
+O armazenamento principal para o Graph Node. É aqui que são guardados dados de subgraph, assim como metadados sobre subgraphs e dados de rede agnósticos a subgraphs, como o cache de blocos e o cache eth_call.
+
+### Clientes de rede
+
+Para indexar uma rede, o Graph Node precisa de acesso a um cliente de rede através de uma API JSON-RPC compatível com EVM. Esta RPC (chamada de processamento remoto) pode se conectar a um único cliente de Ethereum; ou o setup pode ser mais complexo, de modo a carregar saldos em múltiplos clientes.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### Nodes IPFS
+
+Os metadados de lançamento de subgraph são armazenados na rede IPFS. O Graph Node acessa primariamente o node IPFS durante o lançamento do subgraph, para retirar o manifest e todos os arquivos ligados. Os indexadores de rede não precisam hospedar seu próprio node IPFS. Um node IPFS para a rede é hospedado em https://ipfs.network.thegraph.com.
+
+### Servidor de métricas Prometheus
+
+O Graph Node pode, opcionalmente, logar métricas a um servidor de métricas Prometheus para permitir funções de relatórios e monitorado.
+
+### Começando da fonte
+
+#### Pré-requisitos para a instalação
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Comece um servidor de banco de dados PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Agora que todas as dependências estão prontas, inicie o Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Como começar com Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Os básicos do Kubernetes
+
+Durante a execução, o Graph Node expõe as seguintes portas:
+
+| Porta | Propósito                                               | Rotas                                          | Argumento CLI      | Variável de Ambiente |
+| ----- | ------------------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000  | Servidor HTTP GraphQL<br />(para consultas de subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001  | WS GraphQL<br />(para inscrições a subgraphs)           | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020  | JSON-RPC<br />(para gerir lançamentos)                  | /                                              | \--admin-port      | -                    |
+| 8030  | API de status de indexamento do subgraph                | /graphql                                       | \--index-node-port | -                    |
+| 8040  | Métricas Prometheus                                     | /metrics                                       | \--metrics-port    | -                    |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Configurações avançadas do Graph Node
+
+Basicamente, o Graph Node pode ser operado com uma única instância de Graph Node, um único banco de dados PostgreSQP, e os clientes de rede como exigidos pelos subgraphs a serem indexados.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> Ao usar um arquivo de configuração, não é possível usar as opções --postgres-url, --postgres-secondary-hosts, e --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Múltiplos Graph Nodes
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Note que vários Graph Nodes podem ser configurados para usar o mesmo banco de dados — que, por conta própria, pode ser escalado horizontalmente através do sharding.
+
+#### Regras de lançamento
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Exemplo de configuração de regra de lançamento:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Nodes dedicados de query
+
+Os nodes podem ser configurados explicitamente para fins de query ao incluir o seguinte no arquivo de configuração:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Qualquer node cujo --node-id combina com a expressão regular será programado para responder apenas a queries.
+
+#### Escalamento de bancos de dados via sharding
+
+Para a maioria dos casos de uso, um único banco de dados Postgres é suficiente para apoiar uma instância de graph-node. Quando uma instância de graph-node cresce mais que um único banco Postgres, é possível dividir o armazenamento dos dados do graph-node entre múltiplos bancos Postgres. Todos os bancos de dados, juntos, formam o armazenamento da instância do graph-node. Cada banco de dados individual é chamado de shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+O sharding torna-se útil quando o seu banco de dados existente não aguenta o peso do Graph Node, e quando não é mais possível aumentar o tamanho do banco.
+
+> Geralmente, antes de começar com shards, é melhor maximizar o tamanho de um único banco de dados. Uma exceção é onde o tráfego de queries é dividido de maneira muito desigual entre subgraphs; nestes casos, pode ser de bom valor que os subgraphs de alto volume sejam mantidos em um shard e todo o resto em outro, porque aquele setup aumenta muito a chance dos dados para os subgraphs de alto volume permanecerem no cache db-internal e não serem substituídos por dados de menor prioridade nos subgraphs de baixo volume.
+
+Em termos de configuração de conexões, comece com o max_connections no postgresql.conf configurado em 400 (ou talvez até 200) e preste atenção nas métricas do Prometheus store_connection_wait_time_ms e store_connection_checkout_count. Tempos de espera óbvios (acima de 5ms) indicam que há poucas conexões disponíveis; também podem ser causados por atividade excessiva no banco de dados (como uso alto de CPU). Mas caso o banco de dados pareça estável fora isto, os tempos de espera longos indicam uma necessidade de aumento no número de conexões. Na configuração, há um limite máximo de conexões que cada instância graph-node pode usar, e o Graph Node não manterá conexões abertas caso não sejam necessárias.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Ingestão dedicada de blocos
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Apoio a múltiplas redes
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Múltiplas redes
+- Múltiplos provedores por rede (isto pode permitir a separação de peso entre eles, e pode permitir a configuração de nodes completos além de nodes de arquivo; o Graph Node prefere provedores mais baratos, caso permita uma carga de trabalho).
+- Detalhes adicionais de provedor, como recursos, autenticação e tipo (para apoio experimental ao Firehose)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Variáveis de ambiente
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Lançamento contínuo
+
+Os utilizadores a operar um setup de indexing escalado, com configurações avançadas, podem ganhar mais ao gerir os seus Graph Nodes com o Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Como gerir o Graph Node
+
+Dado um Graph Node (ou Nodes!) em execução, o desafio torna-se gerir subgraphs lançados entre estes nodes. O Graph Node tem uma gama de ferramentas para ajudar a direção de subgraphs.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Naturalmente, o Graph Node fornece as métricas através do endpoint Prometheus na porta 8040. Estas métricas podem ser visualizadas no Grafana.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Como trabalhar com subgraphs
+
+#### API de estado de indexação
+
+Inicialmente disponível na porta 8030/graphql, a API de estado de indexação expõe uma gama de métodos para conferir o estado da indexação para subgraphs diferentes, conferir provas de indexação, inspecionar características de subgraphs, e mais.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Desempenho da indexação
+
+Há três partes separadas no processo de indexação:
+
+- Retirar eventos de interesse do provedor
+- Processar eventos conforme os handlers apropriados (isto pode envolver chamar a chain para o estado, e retirar dados do armazenamento)
+- Escrever os dados resultantes ao armazenamento
+
+Estes estágios são segmentados (por ex., podem ser executados em paralelo), mas são dependentes um no outro. Quando há demora em indexar, a causa depende do subgraph específico.
+
+Causas comuns de lentidão na indexação:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- Excesso de interações no armazenamento durante a execução
+- Muitos dados para guardar no armazenamento
+- Muitos eventos a serem processados
+- Conexão lenta ao banco de dados, para nodes lotados
+- Atraso do próprio provedor em relação ao topo da chain
+- Atraso em retirar novos recibos do topo da chain do provedor
+
+As métricas de indexação de subgraph podem ajudar a diagnosticar a causa raiz do atraso na indexação. Em alguns casos, o problema está no próprio subgraph, mas em outros, melhorar provedores de rede, reduzir a contenção no banco de dados, e outras melhorias na configuração podem aprimorar muito o desempenho da indexação.
+
+#### Subgraphs falhos
+
+É possível que subgraphs falhem durante a indexação, caso encontrem dados inesperados; algum componente não funcione como o esperado; ou se houver algum bug nos handlers de eventos ou na configuração. Geralmente, há dois tipos de falha:
+
+- Falhas determinísticas: Falhas que não podem ser resolvidas com outras tentativas
+- Falhas não determinísticas: podem ser resumidas em problemas com o provedor ou algum erro inesperado no Graph Node. Quando ocorrer uma falha não determinística, o Graph Node reiniciará os handlers falhos e recuará gradualmente.
+
+Em alguns casos, uma falha pode ser resolvida pelo indexador (por ex. a indexação falhou por ter o tipo errado de provedor, e necessita do correto para continuar). Porém, em outros, é necessária uma alteração no código do subgraph.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Cache de blocos e chamadas
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+Caso haja uma suspeita de inconsistência no cache de blocos, como a falta de um evento <code>tx receipt missing</code>:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. Caso o bloco corresponda ao provedor, então o problema pode ser debugado em frente ao provedor.
+
+#### Erros e problemas de query
+
+Quando um subgraph for indexado, os indexadores podem esperar servir consultas através do endpoint dedicado de consultas do subgraph. Se o indexador espera servir volumes significantes de consultas, é recomendado um node dedicado a queries; e para volumes muito altos, podem querer configurar réplicas de shard para que os queries não impactem o processo de indexação.
+
+Porém, mesmo com um node dedicado a consultas e réplicas deste, certos queries podem demorar muito para executar; em alguns casos, aumentam o uso da memória e pioram o tempo de query para outros utilizadores.
+
+Não há uma "bala de prata", mas sim uma gama de ferramentas para prevenir, diagnosticar e lidar com queries lentos.
+
+##### Caching de query
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Análise de queries
+
+Queries problemáticos tendem a surgir em uma de duas maneiras. Em alguns casos, os próprios utilizadores relatam que um certo query está lento; neste caso, o desafio é diagnosticar a razão para a lentidão, seja um problema geral ou específico àquele subgraph ou query. E depois, claro, resolvê-lo se possível.
+
+Em outros casos, o gatilho pode ser o excesso de uso de memória em um node de query; no caso, o primeiro desafio é identificar a consulta que causou este problema.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Considerando um query lento, os indexadores têm algumas opções. Claro que podem alterar o seu modelo de custo, para aumentar o custo de enviar o query problemático. A frequência dessa query pode diminuir, mas isto não costuma resolver a raiz do problema.
+
+##### Otimização tipo-conta
+
+Tábuas de base de dados que armazenam entidades geralmente vêm em duas variedades: 'tipo-transação', em que as entidades nunca são atualizadas depois da criação (por ex., armazenam algo como uma lista de transações financeiras); e 'tipo-conta', em que as entidades atualizam com frequência (ex.: armazenam algo como contas financeiras, que são modificadas sempre que uma transação é gravada). Tábuas tipo-contas são caracterizadas por ter muitas versões de entidade, mas poucas entidades distintas. O número de entidades distintas nessas tábuas costuma ser 1% do total de linhas (versões de entidade)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Como remover subgraphs
+
+> Esta é uma funcionalidade nova, que estará disponível no Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From abf022d1273c4800bbf669cd71c10ce0e3586606 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:33 -0500
Subject: [PATCH 0838/3820] New translations advanced.mdx (Portuguese)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/pt/subgraphs/developing/creating/advanced.mdx b/website/pages/pt/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..6355d3026aee
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Visão geral
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Séries de Tempo e Agregações
+
+Séries de tempo e agregações permitem que o seu subgraph registre estatísticas como médias diárias de preço, total de transferências por hora, etc.
+
+Este recurso introduz dois novos tipos de entidade de subgraph. Entidades de série de tempo registram pontos de dados com marcações de tempo. Entidades de agregação realizam cálculos pré-declarados nos pontos de dados de Séries de Tempo numa base por hora ou diária, e depois armazenam os resultados para acesso fácil via GraphQL.
+
+### Exemplo de Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Definição de Série de Tempo e Agregações
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Intervalos de Agregação Disponíveis
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Funções de Agregação Disponíveis
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Exemplo de Query de Agregações
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Nota:
+
+Para utilizar Séries de Tempo e Agregações, um subgraph deve ter uma versão de especificação maior que 1.1.0. Note que este recurso pode passar por mudanças significativas que podem afetar a retrocompatibilidade.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Erros não-fatais
+
+Erros de indexação em subgraphs já sincronizados, por si próprios, farão que o subgraph falhe e pare de sincronizar. Os subgraphs podem, de outra forma, ser configurados a continuar a sincronizar na presença de erros, ao ignorar as mudanças feitas pelo handler que provocaram o erro. Isto dá tempo aos autores de subgraphs para corrigir seus subgraphs enquanto queries continuam a ser servidos perante o bloco mais recente, porém os resultados podem ser inconsistentes devido ao bug que causou o erro. Note que alguns erros ainda são sempre fatais. Para ser não-fatais, os erros devem ser confirmados como determinísticos.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Permitir erros não fatais exige a configuração da seguinte feature flag no manifest do subgraph:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## Fontes de Dados de Arquivos em IPFS/Arweave
+
+Fontes de dados de arquivos são uma nova funcionalidade de subgraph para acessar dados off-chain de forma robusta e extensível. As fontes de dados de arquivos apoiam o retiro de arquivos do IPFS e do Arweave.
+
+> Isto também abre as portas para indexar dados off-chain de forma determinística, além de potencialmente introduzir dados arbitrários com fonte em HTTP.
+
+### Visão geral
+
+Em vez de buscar arquivos "em fila" durante a execução do handler, isto introduz modelos que podem ser colocados como novas fontes de dados para um identificador de arquivos. Estas novas fontes de dados pegam os arquivos e tentam novamente caso não obtenham êxito; quando o arquivo é encontrado, executam um handler dedicado.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Guia de atualização
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Adicionar um novo tipo de entidade que será atualizado quando os arquivos forem encontrados
+
+Fontes de dados de arquivos não podem acessar ou atualizar entidades baseadas em chain, mas devem atualizar entidades específicas a arquivos.
+
+Isto pode implicar separar campos de entidades existentes em entidades separadas, ligadas juntas.
+
+Entidade combinada original:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+Entidade nova, separada:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+Se o relacionamento for perfeitamente proporcional entre a entidade parente e a entidade de fontes de dados de arquivos resultante, é mais simples ligar a entidade parente a uma entidade de arquivos resultante, com a CID IPFS como o assunto de busca. Se tiver dificuldades em modelar suas novas entidades baseadas em arquivos, pergunte no Discord!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+Esta é a fonte de dados que será gerada quando um arquivo de interesse for identificado.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Criar um novo handler para processar arquivos
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Exemplo de handler:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Gerar fontes de dados de arquivos quando for obrigatório
+
+Agora pode criar fontes de dados de arquivos durante a execução de handlers baseados em chain:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Exemplo:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//Este exemplo de código é para um subgraph do Crypto Coven. O hash ipfs acima é um diretório com metadados de tokens para todos os NFTs do Crypto Coven.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //Isto cria um caminho aos metadados para um único NFT do Crypto Coven. Ele concatena o diretório com "/" + nome do arquivo + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+Isto criará uma fonte de dados de arquivos, que avaliará o endpoint de IPFS ou Arweave configurado do Graph Node, e tentará novamente caso não achá-lo. Com o arquivo localizado, o handler da fonte de dados de arquivos será executado.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Parabéns, você está a usar fontes de dados de arquivos!
+
+#### Como lançar os seus Subgraphs
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitações
+
+Handlers e entidades de fontes de dados de arquivos são isolados de outras entidades de subgraph, o que garante que sejam determinísticos quando executados e que não haja contaminação de fontes de dados baseadas em chain. Especificamente:
+
+- Entidades criadas por Fontes de Dados de Arquivos são imutáveis, e não podem ser atualizadas
+- Handlers de Fontes de Dados de Arquivos não podem acessar entidades de outras fontes de dados de arquivos
+- Entidades associadas com Fontes de Dados de Arquivos não podem ser acessadas por handlers baseados em chain
+
+> Enquanto esta limitação pode não ser problemática para a maioria dos casos de uso, ela pode deixar alguns mais complexos. Se houver qualquer problema neste processo, por favor dê um alô via Discord!
+
+Além disto, não é possível criar fontes de dados de uma fonte de dado de arquivos, seja uma on-chain ou outra fonte de dados de arquivos. Esta restrição poderá ser retirada no futuro.
+
+#### Boas práticas
+
+Caso ligue metadados de NFTs a tokens correspondentes, use o hash IPFS destes para referenciar uma entidade de Metadados da entidade do Token. Salve a entidade de Metadados a usar o hash IPFS como ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> Estamos a melhorar a recomendação acima, para que os queries retornem apenas a versão "mais recente"
+
+#### Problemas conhecidos
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Exemplos
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### Referências
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Filtros de Argumentos Indexados / Filtros de Tópicos
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Filtros de tópico, também conhecidos como filtros de argumentos indexados, permitem que os utilizadores filtrem eventos de blockchain com alta precisão, em base nos valores dos seus argumentos indexados.
+
+- Estes filtros ajudam a isolar eventos específicos de interesse do fluxo vasto de eventos na blockchain, o que permite que subgraphs operem com mais eficácia ao focarem apenas em dados relevantes.
+
+- Isto serve para criar subgraphs pessoais que rastreiam endereços específicos e as suas interações com vários contratos inteligentes na blockchain.
+
+### Como Filtros de Tópicos Funcionam
+
+Quando um contrato inteligente emite um evento, quaisquer argumentos que forem marcados como indexados podem ser usados como filtros no manifest de um subgraph. Isto permite que o subgraph preste atenção seletiva para eventos que correspondam a estes argumentos indexados.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Declaração de evento com parâmetros indexados para endereços
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Função para simular a transferência de tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+Neste exemplo:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuração em Subgraphs
+
+Filtros de tópicos são definidos diretamente na configuração de handlers de eventos no manifest do subgraph. Veja como eles são configurados:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+Neste cenário:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Cada tópico pode ter um ou mais valores, e um evento só é processado se corresponder a um dos valores em cada tópico especificado.
+
+#### Lógica de Filtro
+
+- Dentro de um Tópico Único: A lógica funciona como uma condição OR. O evento será processado se corresponder a qualquer dos valores listados num tópico.
+- Entre Tópicos Diferentes: A lógica funciona como uma condição AND. Um evento deve atender a todas as condições especificadas em vários tópicos para acionar o handler associado.
+
+#### Exemplo 1: Como Rastrear Transferências Diretas do Endereço A ao Endereço B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+Nesta configuração:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Exemplo 2: Como Rastrear Transações em Qualquer Direção Entre Dois ou Mais Endereços
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Endereço do Remetente
+    topic2: ['0xAddressB', '0xAddressC'] # Endereço do Destinatário
+```
+
+Nesta configuração:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- O subgraph indexará transações que ocorrerem em qualquer direção entre vários endereços, o que permite a monitoria compreensiva de interações que envolverem todos os endereços.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+Esta ferramenta faz o seguinte:
+
+- Aumenta muito o desempenho do retiro de dados da blockchain Ethereum ao reduzir o tempo total para múltiplas chamadas e otimizar a eficácia geral do subgraph.
+- Permite retiros de dados mais rápidos, o que resulta em respostas de query aceleradas e uma experiência de utilizador melhorada.
+- Reduz tempos de espera para aplicativos que precisam agregar dados de várias chamadas no Ethereum, o que aumenta a eficácia do processo de retiro de dados.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Execução Paralela: Ao invés de esperar o término de uma chamada para começar a próxima, várias chamadas podem ser iniciadas simultaneamente.
+- Eficácia de Tempo: O total de tempo levado para todas as chamadas muda da soma dos tempos de chamadas individuais (sequencial) para o tempo levado para a chamada mais longa (paralelo).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagina que tens um subgraph que precisa fazer três chamadas no Ethereum para retirar dados sobre as transações, o saldo e as posses de token de um utilizador.
+
+Tradicionalmente, estas chamadas podem ser realizadas em sequência:
+
+1. Chamada 1 (Transações): Leva 3 segundos
+2. Chamada 2 (Saldo): Leva 2 segundos
+3. Chamada 3 (Posses de Token): Leva 4 segundos
+
+Total de tempo: 3 + 2 + 4 = 9 segundos
+
+#### Scenario with Declarative `eth_calls`
+
+Com esta ferramenta, é possível declarar que estas chamadas sejam executadas em paralelo:
+
+1. Chamada 1 (Transações): Leva 3 segundos
+2. Chamada 2 (Saldo): Leva 2 segundos
+3. Chamada 3 (Posses de Token): Leva 4 segundos
+
+Como estas chamadas são executadas em paralelo, o total de tempo é igual ao tempo gasto pela chamada mais longa.
+
+Total de tempo = max (3, 2, 4) = 4 segundos
+
+#### How it Works
+
+1. Definição Declarativa: No manifest do subgraph, as chamadas no Ethereum são declaradas de maneira que indique que elas possam ser executadas em paralelo.
+2. Motor de Execução Paralela: O motor de execução do Graph Node reconhece estas declarações e executa as chamadas simultaneamente.
+3. Agregação de Resultado: Quando todas as chamadas forem completadas, os resultados são agregados e usados pelo subgraph para mais processos.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Detalhes para o exemplo acima:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Como Enxertar em Subgraphs Existentes
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # ID do subgraph base
+  block: 7345624 # Número do bloco
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Como o enxerto copia em vez de indexar dados base, dirigir o subgraph para o bloco desejado desta maneira é mais rápido que indexar do começo, mesmo que a cópia inicial dos dados ainda possa levar várias horas para subgraphs muito grandes. Enquanto o subgraph enxertado é inicializado, o Graph Node gravará informações sobre os tipos de entidade que já foram copiados.
+
+O subgraph enxertado pode usar um schema GraphQL que não é idêntico ao schema do subgraph base, mas é apenas compatível com ele. Ele deve ser um schema válido no seu próprio mérito, mas pode desviar do schema do subgraph base nas seguintes maneiras:
+
+- Ele adiciona ou remove tipos de entidade
+- Ele retira atributos de tipos de entidade
+- Ele adiciona atributos anuláveis a tipos de entidade
+- Ele transforma atributos não anuláveis em atributos anuláveis
+- Ele adiciona valores a enums
+- Ele adiciona ou remove interfaces
+- Ele muda os tipos de entidades para qual implementar uma interface
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 3880670a60ccef4434ab2c2f94fb92ad9c1e8fb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:35 -0500
Subject: [PATCH 0839/3820] New translations api.mdx (Portuguese)

---
 .../developing/creating/graph-ts/api.mdx      | 891 ++++++++++++++++++
 1 file changed, 891 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/pt/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/pt/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..ba49a090be91
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,891 @@
+---
+title: API AssemblyScript
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## Referência da API
+
+A biblioteca `@graphprotocol/graph-ts` fornece as seguintes APIs:
+
+- Uma API `ethereum` para trabalhar com contratos inteligentes, eventos, blocos, transações, e valores no Ethereum.
+- Uma API `store` para carregar e guardar entidades dentro e fora do armazenamento do Graph Node.
+- Uma API `log` para gravar mensagens ao resultado do Graph Node e ao Graph Explorer.
+- Uma API `ipfs` para carregar arquivos do IPFS.
+- Uma API `json` para analisar dados em JSON.
+- Uma API `crypto` para usar funções criptográficas.
+- Primitivos de baixo nível para traduzir entre sistemas de tipos diferentes, como Ethereum, JSON, GraphQL e AssemblyScript.
+
+### Versões
+
+No manifest do subgraph, `apiVersion` especifica a versão da API de mapeamento, executada pelo Graph Node para um subgraph.
+
+| Versão | Notas de atualização                                                                                                                                                                                                                                     |
+| :----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9 | Adiciona novas funções de host [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                      |
+|  0.0.8 | Adiciona validação para existência de campos no schema ao salvar uma entidade.                                                                                                                                                                           |
+|  0.0.7 | Classes `TransactionReceipt` e `Log` adicionadas aos tipos do EthereumCampo <br />Campo `receipt` adicionado ao objeto Ethereum Event                                                                                                                    |
+|  0.0.6 | Campo `nonce` adicionado ao objeto Ethereum TransactionCampo <br />`baseFeePerGas` adicionado ao objeto Ethereum Block                                                                                                                                   |
+|  0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4 | Campo `functionSignature` adicionado ao objeto Ethereum SmartContractCall                                                                                                                                                                                |
+|  0.0.3 | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2 | Campo `input` adicionado ao objeto Ethereum Transaction                                                                                                                                                                                                  |
+
+### Tipos Embutidos
+
+A documentação sobre os tipos de base embutidos no AssemblyScript está na [wiki do AssemblyScript](https://www.assemblyscript.org/types.html).
+
+Os seguintes tipos adicionais são fornecidos pelo `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` representa um arranjo de `u8`.
+
+_Construção_
+
+- `fromI32(x: i32): ByteArray` - Decompõe x em bytes.
+- `fromHexString(hex: string): ByteArray` — O comprimento da entrada deve ser par. É facultativo prefixar com 0x.
+
+_Conversões de tipo_
+
+- `toHexString(): string` — Converte numa cadeia de caracteres hex prefixada com 0x\`.
+- `toString(): string` — Interpreta os bytes como uma cadeia de caracteres UTF-8.
+- `toBase58(): string` — Codifica os bytes como uma cadeia base58.
+- `toU32(): u32` — Interpreta os bytes como um `u32` little-endian. Não funciona em caso de overflow.
+- `toI32(): i32` - Interpreta o arranjo de byte como um `i32` little-endian. Não funciona em caso de overflow.
+
+_Operadores_
+
+- `equals(y: ByteArray): bool` — pode ser escrito como x == y\`.
+- `concat(other: ByteArray) : ByteArray` — retorna um novo `ByteArray` que consiste de `this` diretamente seguido de `other`
+- `concatI32(other: i32) : ByteArray` — retorna um novo `ByteArray` que consiste de `this` diretamente seguido pela representação em byte de `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+O `BigDecimal` é usado para representar decimais de precisão arbitrária.
+
+> Nota: [Internalmente](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/bigdecimal.rs), o `BigDecimal` é armazenado no [formato de ponto flutuante IEEE-754 decimal128](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), que apoia 34 dígitos decimais de significando. Portanto, o `BigDecimal` não serve para representar tipos de ponto fixo que possam exceder 34 dígitos, como um (ufixed256x18)[https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers] em Solidity ou equivalente.
+
+_Construção_
+
+- `constructor(bigInt: BigInt)` – cria um `BigDecimal` a partir de um `BigInt`.
+- `static fromString(s: string): BigDecimal` — faz uma análise sintática a partir de uma cadeia decimal.
+
+_Conversões de tipo_
+
+- `toString(): string` — imprime para uma cadeia decimal.
+
+_Matemática_
+
+- `plus(y: BigDecimal): BigDecimal` — pode ser escrito como `x + y`.
+- `minus(y: BigDecimal): BigDecimal` — pode ser escrito como `x - y`.
+- `times(y: BigDecimal): BigDecimal` — pode ser `x * y`.
+- `div(y: BigDecimal): BigDecimal` — pode ser escrito como `x / y`.
+- `equals(y: BigDecimal): bool` — pode ser `x == y`.
+- `notEqual(y: BigDecimal): bool` — pode ser `x != y`.
+- `lt(y: BigDecimal): bool` — pode ser `x < y`.
+- `le(y: BigDecimal): bool` – pode ser `x <= y`.
+- `gt(y: BigDecimal): bool` – pode ser `x > y`.
+- `ge(y: BigDecimal): bool` – pode ser `x >= y`.
+- `neg(): BigDecimal` - pode ser `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+O `BigInt` é usado para representar números inteiros grandes, inclusive valores em Ethereum de `uint32` até `uint256`, e `int64` até `int256`. Tudo abaixo de `uint32`, como o `int32`, `uint24` ou `int8` é representado como `i32`.
+
+A classe `BigInt` tem a seguinte API:
+
+_Construção_
+
+- `BigInt.fromI32(x: i32): BigInt` – cria um `BigInt` de um `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Analisa um `BigInt` de uma cadeia.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` — Interpreta `bytes` como um inteiro little-endian, não assinado. Se a sua entrada for big-endian, chame pelo `.reverse()` primeiro.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` — Interpreta `bytes` como um inteiro little-endian, assinado. Se a sua entrada for big-endian, chame pelo `.reverse()` primeiro.
+
+  _Conversões de tipo_
+
+- `x.toHex(): string` — transforma o `BigInt` numa cadeia de caracteres hexadecimais.
+
+- `x.toString(): string` — transforma o `BigInt` numa cadeia de números decimais.
+
+- `x.toI32(): i32` — retorna o `BigInt` como um `i32`; falha se o valor não couber no `i32`. É bom verificar o `x.isI32()` primeiro.
+
+- `x.toBigDecimal(): BigDecimal` — converte num decimal sem fracionário.
+
+_Matemática_
+
+- `x.plus(y: BigInt): BigInt` – pode ser escrito como `x + y`.
+- `x.minus(y: BigInt): BigInt` – pode ser escrito como `x - y`.
+- `x.times(y: BigInt): BigInt` – pode ser escrito como `x * y`.
+- `x.div(y: BigInt): BigInt` – pode ser escrito como `x / y`.
+- `x.mod(y: BigInt): BigInt` – pode ser escrito como `x % y`.
+- `x.equals(y: BigInt): bool` – pode ser escrito como `x == y`.
+- `x.notEqual(y: BigInt): bool` – pode ser escrito como `x != y`.
+- `x.lt(y: BigInt): bool` – pode ser escrito como `x < y`.
+- `x.le(y: BigInt): bool` – pode ser escrito como `x <= y`.
+- `x.gt(y: BigInt): bool` – pode ser escrito como `x > y`.
+- `x.ge(y: BigInt): bool` – pode ser escrito como `x >= y`.
+- `x.neg(): BigInt` – pode ser escrito como `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divide por um decimal e dá um resultado decimal.
+- `x.isZero(): bool` — Conveniência para conferir se o número é zero.
+- `x.isl32(): bool` — Confere se o número cabe em um `i32`.
+- `x.abs(): BigInt` — Valor absoluto.
+- `x.pow(exp: u8): BigInt` — Exponenciação.
+- `bitOr(x: BigInt, y: BigInt): BigInt` — pode ser escrito como `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` — pode ser escrito como `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – pode ser escrito como `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – pode ser escrito como `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+O `TypedMap` pode servir para armazenar pares de chave e valor (key e value
+). Confira [este exemplo](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+A classe `TypedMap` tem a seguinte API:
+
+- `new TypedMap<K, V>()` — cria um mapa vazio com chaves do tipo `K` e valores do tipo `V`
+- `map.set(key: K, value: V): void` — coloca o valor do `key` como `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` — retorna o par de valor-chave para um `key` ou `null` se o `key` não existir no mapa
+- `map.get(key: K): V | null` — retorna o valor para um `key` ou `null` se o `key` não existir no mapa
+- `map.isSet(key: K): bool` — retorna `true` se o `key` existir no mapa e `false` se não existir
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+O `Bytes` serve para representar arranjos de comprimento arbitrário de bytes. Isto inclui valores do Ethereum do tipo `bytes`, `bytes32`, etc.
+
+A classe `Bytes` estende o [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) do AssemblyScript. Isto apoia toda a funcionalidade `Uint8Array`, além dos novos métodos a seguir:
+
+_Construção_
+
+- `fromHexString(hex: string) : Bytes` — Converte a cadeia `hex`, que deve consistir de um número par de dígitos hexadecimais para um `ByteArray`. Opcionalmente, a cadeia `hex` pode começar com `0x`
+- `fromI32(i: i32) : Bytes` - Converte o `i` em um arranjo de bytes
+
+_Conversões de tipo_
+
+- `b.toHex()` — retorna uma cadeia hexadecimal que representa os bytes no arranjo
+- `b.toString()` — converte os bytes no arranjo para uma cadeia de caracteres em unicode
+- `b.toBase58()` — transforma um valor de Ethereum Bytes numa codificação base58 (usado para hashes IPFS)
+
+_Operadores_
+
+- `b.concat(other: Bytes) : Bytes` - - retorna um novo `Bytes` que consiste de `this` diretamente seguido por `other`
+- `b.concatI32(other: i32) : ByteArray` — retorna um novo `Bytes` que consiste de `this` diretamente seguido pela representação em byte de `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` estende o `Bytes` para representar valores de `address` do Ethereum.
+
+Ele adiciona o seguinte método em cima da API `Bytes`:
+
+- `Address.fromString(s: string): Address` — cria um `Address` a partir de uma cadeia hexadecimal
+- `Address.fromBytes(b: Bytes): Address` — cria um `Address` a partir do `b`, que deve ter o comprimento exato de 20 bytes. Preencher um valor com menos ou mais bytes causará um erro
+
+### Armazenamento da API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+A API `store` permite carregar, salvar e remover entidades do/para o armazenamento do Graph Node.
+
+As entidades escritas no armazenamento mapeam um-por-um com os tipos de `@entity` definidos no schema GraphQL do subgraph. Para trabalhar com estas entidades de forma conveniente, o comando `graph codegen` fornecido pelo [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) gera classes de entidades, que são subclasses do tipo embutido `Entity`, com getters e setters de propriedade para os campos no schema e métodos para carregar e salvar estas entidades.
+
+#### Como criar entidades
+
+Este é um padrão comum para a criação de entidades de eventos do Ethereum.
+
+```typescript
+// Importar a classe de evento de transferência gerada da ABI ERC20
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Importar o tipo de entidade de transferência gerado do schema do GraphQL
+import { Transfer } from '../generated/schema'
+
+// Handler de evento de transferência
+export function handleTransfer(event: TransferEvent): void {
+  // Criar uma entidade de Transferência, usando o hash da transação como a ID da entidade
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Determinar propriedades na entidade, usando os parâmetros do evento
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Salvar a entidade no armazenamento
+  transfer.save()
+}
+```
+
+Quando um evento `Transfer` é encontrado durante o processamento da chain, ele é passado para o handler de evento `handleTransfer` com o tipo `Transfer` gerado (apelidado de `TransferEvent` aqui, para evitar confusões com o tipo de entidade). Este tipo permite o acesso a dados como a transação parente do evento e seus parâmetros.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Como carregar entidades a partir do armazenamento
+
+Se uma entidade já existe, ela pode ser carregada do armazenamento com os seguintes comandos:
+
+```typescript
+let id = event.transaction.hash // ou como a ID for construída
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use a entidade Transfer como antes
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Como consultar entidades criadas dentro de um bloco
+
+Desde o `graph-node` v0.31.0, o `@graphprotocol/graph-ts` v0.30.0 e o `@graphprotocol/graph-cli v0.49.0`, o método `loadInBlock` está disponível em todos os tipos de entidade.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // ou como a ID for construída
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use a entidade Transfer como antes
+```
+
+> Nota: se não houver nenhuma entidade criada no bloco dado, o `loadInBlock` retornará um `null` mesmo se houver uma entidade com o ID dado no armazenamento.
+
+#### Como buscar entidades derivadas
+
+A partir da versão 0.31.0 do `graph-node`, `@graphprotocol/graph-ts` v0.31.0 e a versão 0.51.0 do `@graphprotocol/graph-cli`, está disponível o método `loadRelated`.
+
+Isto permite o carregamento de campos de entidade derivada a partir de um event handler. Por exemplo, considerando o schema a seguir:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+O código a seguir carregará a entidade `Token` de que foi derivada a entidade `Holder`:
+
+```typescript
+let holder = Holder.load('test-id')
+// Carrega as entidades de Token associadas com um titular dado
+let tokens = holder.tokens.load()
+```
+
+#### Como atualizar entidades existentes
+
+Há duas maneiras de atualizar uma entidade existente:
+
+1. Carregar a entidade com, por ex., `Transfer.load(id)`, determinar as propriedades da entidade, e então usar o `.save()` para colocá-la no armazenamento.
+2. Simplesmente criar a entidade com, por ex., `new Transfer(id)`, determinar as propriedades da entidade, e depois colocá-la no armazenamento com `.save()`. Se a entidade já existir, as mudanças serão integradas a ela.
+
+Geralmente é simples mudar propriedades, graças aos setters de propriedade gerados:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+Também é possível cancelar propriedades com uma das seguintes instruções:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+Isto só funciona com propriedades opcionais; por ex., propriedades declaradas sem um `!` no GraphQL. Dois exemplos seriam `owner: Bytes` ou `amount: BigInt`.
+
+Atualizar propriedades de arranjos é um processo um pouco mais envolvido, pois pegar um arranjo de uma entidade cria uma cópia deste mesmo arranjo. Isto significa que as propriedades de arranjos devem ser impostas explicitamente após mudar um arranjo. O seguinte assume que o `entity` tem um campo `numbers: [BigInt!]!`.
+
+```typescript
+// Isto não funcionará
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// Isto funcionará
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Como remover entidades do armazenamento
+
+Atualmente, não há como remover uma entidade através dos tipos gerados. Em vez disto, o processo requer a passagem do ID da entidade e do nome do tipo da mesma ao `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### API do Ethereum
+
+A API do Ethereum fornece acesso a contratos inteligentes, variáveis de estado público, funções de contrato, eventos, transações, blocos e a codificação/decodificação de dados no Ethereum.
+
+#### Apoio para Tipos no Ethereum
+
+Assim como em entidades, o `graph codegen` gera classes para todos os contratos inteligentes e eventos usados em um subgraph. Para isto, as ABIs dos contratos devem ser parte da fonte de dados no manifest do subgraph. Tipicamente, os arquivos da ABI são armazenados em uma pasta `abis/`.
+
+Com as classes geradas, conversões entre tipos no Ethereum e os [tipos embutidos](#built-in-types) acontecem em segundo plano para que os autores de subgraphs não precisem se preocupar com elas.
+
+Veja um exemplo a seguir. Considerando um schema de subgraph como
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+e uma assinatura de evento `Transfer(address,address,uint256)` na Ethereum, os valores `from`, `to` e `amount` do tipo `address`, `address` and `uint256` são convertidos para `Address` and `BigInt`, o que permite que sejam passados para as propriedades `Bytes!` and `BigInt!` da entidade `Transfer`:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Eventos e Dados de Blocos/Transações
+
+Eventos de Ethereum passados para handlers de eventos, como o evento `Transfer` nos exemplos anteriores, não só permitem acessar os parâmetros de evento, mas também sua transação parente e o bloco de qual fazem parte. Os seguintes dados podem ser obtidos de instâncias `event` (estas classes são parte do módulo `ethereum` no `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Acesso ao Estado do Contrato Inteligente
+
+O código gerado pelo `graph codegen` também inclui classes para os contratos inteligentes usados no subgraph. Estes servem para acessar variáveis de estado público e funções de chamada do contrato no bloco atual.
+
+É comum acessar o contrato de qual origina um evento. Isto é feito com o seguinte código:
+
+```typescript
+// Importar a classe do contrato gerado e a classe do evento de transferência gerado
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Ligar o contrato ao endereço que emitiu o evento
+  let contract = ERC20Contract.bind(event.address)
+
+  // Acessar variáveis e funções de estado fazendo chamadas
+  let erc20Symbol = contract.symbol()
+}
+```
+
+O `Transfer` é apelidado de `TransferEvent` aqui para evitar confusões de nomenclatura com o tipo da entidade
+
+Enquanto o `ERC20Contract` no Ethereum tiver uma função pública de apenas-leitura chamada `symbol`, ele pode ser chamado com o `.symbol()`. Para variáveis de estado público, um método com o mesmo nome é criado automaticamente.
+
+Qualquer outro contrato que seja parte do subgraph pode ser importado do código gerado e ligado a um endereço válido.
+
+#### Como Lidar com Chamadas Revertidas
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### ABI de Codificação/Decodificação
+
+Dados podem ser codificados e decodificados conforme o formato de codificação da ABI do Ethereum, através das funções `encode` e `decode` no módulo `ethereum`.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+Para mais informações:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Codificação e decodificação da [biblioteca/CLI do Rust](https://github.com/rust-ethereum/ethabi)
+- Um [exemplo mais complexo](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Saldo de um Endereço
+
+O saldo de token nativo de um endereço pode ser resgatado com o módulo `ethereum`. Este recurso está disponível a partir do `apiVersion: 0.0.9`, definido no `subgraph.yaml`. O `getBalance()` resgata o saldo do endereço especificado como o do fim do bloco em que o evento é adicionado.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // retorna o saldo em BigInt
+```
+
+#### Como Conferir Se Um Endereço é Um Contrato Ou Um EOA
+
+Para conferir se um endereço é um de contrato inteligente ou um endereço titulado externamente (sigla em português para EOA), use a função `hasCode()` do módulo `ethereum` que retornará `boolean`. Este recurso está disponível a partir do `apiVersion: 0.0.9`, definido no `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // retorna false
+```
+
+### API de Logging
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+A API `log` permite que os subgraphs gravem informações à saída padrão do Graph Node, assim como ao Graph Explorer. Mensagens podem ser gravadas com níveis diferentes de log. É fornecida uma sintaxe básica de formatação de strings para compor mensagens de log do argumento.
+
+A API `log` inclui as seguintes funções:
+
+- `log.debug(fmt: string, args: Array<string>): void` — loga uma mensagem de debug.
+- `log.info(fmt: string, args: Array<string>): void` - loga uma mensagem de debug.
+- `log.warning(fmt: string, args: Array<string>): void` - loga um aviso.
+- `log.error(fmt: string, args: Array<string>): void` - loga uma mensagem de erro.
+- `log.critical(fmt: string, args: Array<string>): void` – loga uma mensagem crítica _e_ encerra o subgraph.
+
+A API `log` toma um string de formato e um arranjo de valores de string. Ele então substitui os temporários com os valores de strings do arranjo. O primeiro `{}` temporário é substituído pelo primeiro valor no arranjo, o segundo `{}` temporário é substituído pelo segundo valor, e assim por diante.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Como logar um ou mais valores
+
+##### Como logar um único valor
+
+No exemplo abaixo, o valor de string "A" é passado a um arranjo para tornar-se `['A']` antes de ser registado no log:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Mostra : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Como logar uma única entrada de um arranjo existente
+
+No exemplo abaixo, só é logado o primeiro valor do arranjo do argumento, apesar de haver três valores no arranjo.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Apesar de três valores serem passados ao `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Como logar várias entradas de um arranjo existente
+
+Cada entrada no arranjo dos argumentos exige o seu próprio `{}` no string de mensagens de log. O exemplo abaixo contém três `{}` temporários na mensagem de log. Por causa disto, são registados todos os três valores no `myArray`.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Mostra : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Como logar uma entrada específica de um arranjo existente
+
+Para mostrar um valor específico no arranjo, forneça o valor indexado.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Mostra : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Como logar informações de eventos
+
+O exemplo abaixo loga o número do bloco, hash do bloco e o hash da transação de um evento:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### API do IPFS
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Considerando um hash ou local IPFS, um arquivo do IPFS é lido da seguinte maneira:
+
+```typescript
+// Coloque isto dentro de um handler de evento no mapeamento
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Locais como `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// que incluem arquivos em diretorias também são apoiados
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Nota**: O `ipfs.cat` não é determinístico no momento. Se o arquivo não puder ser retirado sobre a rede IPFS antes do tempo do pedido acabar, ele retornará um `null`. Com isto, sempre vale a pena procurar o `null` no resultado.
+
+Também é possível processar arquivos maiores em streaming com o `ipfs.map`. A função espera o hash ou local de um arquivo IPFS, o nome de um callback, e flags para modificar o seu comportamento:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // Ver a documentação do JSONValue para detalhes sobre
+  // como lidar com valores JSON
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks também podem criar entidades
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Coloque isto dentro de um handler de evento no mapeamento
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Como alternativa, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+O único flag atualmente apoiado é o `json`, que deve ser passado ao `ipfs.map`. Com o flag `json`, o arquivo IPFS deve consistir de uma série de valores JSON, com um valor por linha. Chamar `ipfs.map`, irá ler cada linha no arquivo, desserializá-lo em um `JSONValue`, e chamar o callback para cada linha. O callback pode então armazenar dados do `JSONValue` com operações de entidade. As mudanças na entidade só serão armazenadas quando o handler que chamou o `ipfs.map` concluir com sucesso; enquanto isso, elas ficam na memória, e o tamanho do arquivo que o `ipfs.map` pode processar é então limitado.
+
+Em caso de sucesso, o `ipfs.map` retorna `void`. Se qualquer invocação do callback causar um erro, o handler que invocou o `ipfs.map` é abortado, e o subgraph é marcado como falho.
+
+### API de Criptografia
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+A API `crypto` disponibiliza funções criptográficas para uso em mapeamentos. No momento, apenas um está disponível:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### API JSON
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+Dados em JSON podem ser analisados com a API `json`:
+
+- `json.fromBytes(data: Bytes): JSONValue` — analisa dados JSON de um arranjo `Bytes` interpretado como uma sequência válida de UTF-8
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>`— versão segura do `json.fromBytes`, retorna um erro se houver falha no parsing
+- `json.fromString(data: string): JSONValue` — faz parsing de dados JSON de um String em UTF-8 válido\`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – versão segura do `json.fromString`, retorna um erro se houver falha no parsing
+
+A classe `JSONValue` fornece uma maneira de retirar valores de um documento JSON arbitrário. Como valores JSON podem ser booleans, números, arranjos e mais, o `JSONValue` vem com uma propriedade `kind` para conferir o tipo de um valor:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+Além disso, há um método para conferir se o valor é `null`:
+
+- `value.isNull(): boolean`
+
+Quando o tipo de um valor é confirmado, ele pode ser convertido num [tipo embutido](#built-in-types) usando um dos seguintes métodos:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (e depois converter o `JSONValue` com um dos 5 métodos acima)
+
+### Referência de Conversões de Tipos
+
+| Fonte(s)                 | Destino              | Função de conversão            |
+| ------------------------ | -------------------- | ------------------------------ |
+| Address                  | Bytes                | nenhum                         |
+| Address                  | String               | s.toHexString()                |
+| BigDecimal               | String               | s.toString()                   |
+| BigInt                   | BigDecimal           | s.toBigDecimal()               |
+| BigInt                   | String (hexadecimal) | s.toHexString() ou s.toHex()   |
+| BigInt                   | String (unicode)     | s.toString()                   |
+| BigInt                   | i32                  | s.toI32()                      |
+| Boolean                  | Boolean              | nenhum                         |
+| Bytes (assinado)         | BigInt               | BigInt.fromSignedBytes(s)      |
+| Bytes (não assinado)     | BigInt               | BigInt.fromUnsignedBytes(s)    |
+| Bytes                    | String (hexadecimal) | s.toHexString() ou s.toHex()   |
+| Bytes                    | String (unicode)     | s.toString()                   |
+| Bytes                    | String (base58)      | s.toBase58()                   |
+| Bytes                    | i32                  | s.toI32()                      |
+| Bytes                    | u32                  | s.toU32()                      |
+| Bytes                    | JSON                 | json.fromBytes(s)              |
+| int8                     | i32                  | nenhum                         |
+| int32                    | i32                  | nenhum                         |
+| int32                    | BigInt               | BigInt.fromI32(s)              |
+| uint24                   | i32                  | nenhum                         |
+| int64 - int256           | BigInt               | nenhum                         |
+| uint32 - uint256         | BigInt               | nenhum                         |
+| JSON                     | boolean              | s.toBool()                     |
+| JSON                     | i64                  | s.toI64()                      |
+| JSON                     | u64                  | s.toU64()                      |
+| JSON                     | f64                  | s.toF64()                      |
+| JSON                     | BigInt               | s.toBigInt()                   |
+| JSON                     | string               | s.toString()                   |
+| JSON                     | Array                | s.toArray()                    |
+| JSON                     | Object               | s.toObject()                   |
+| String                   | Address              | Address.fromString(s)          |
+| Bytes                    | Address              | Address.fromBytes(s)           |
+| String                   | BigInt               | BigInt.fromString(s)           |
+| String                   | BigDecimal           | BigDecimal.fromString(s)       |
+| String (hexadecimal)     | Bytes                | ByteArray.fromHexString(s)     |
+| String (UTF-8)           | Bytes                | ByteArray.fromUTF8(s)          |
+
+### Metadados de Fontes de Dados
+
+É possível inspecionar o endereço do contrato, a rede, e o contexto das fontes de dados que invocaram o handler através do namespace `dataSource`:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entidade e DataSourceContext
+
+A classe base `Entity` e a subclasse `DataSourceContext` têm helpers para determinar e retornar campos de forma dinâmica:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext no Manifest
+
+A seção `context` dentro do `dataSources` lhe permite definir pares key-value acessíveis dentro dos seus mapeamentos de subgraph. Os tipos disponíveis são `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, e `BigInt`.
+
+Aqui está um exemplo de YAML que ilustra o uso de vários tipos na seção `context`:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Especifica um valor Boolean (`true` ou `false`).
+- `String`: Especifica um valor String.
+- `Int`: Especifica um integral de 32 bits.
+- `Int8`: Especifica um integral de 8 bits.
+- `BigDecimal`: Especifica um número decimal. Deve ser citado.
+- `Bytes`: Especifica um string hexadecimal.
+- `List`: Especifica uma lista de itens. Cada item deve especificar o seu tipo e dados.
+- `BigInt`: Especifica um valor integral largo. É necessário citar este devido ao seu grande tamanho.
+
+Este contexto, então, pode ser acessado nos seus arquivos de mapeamento de subgraph, o que resulta em subgraphs mais dinâmicos e configuráveis.

From 762b9f5f12589320008f59c170421247aea525c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:36 -0500
Subject: [PATCH 0840/3820] New translations common-issues.mdx (Portuguese)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/pt/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/pt/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..2f5f5b63c40a
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Problemas Comuns no AssemblyScript
+---
+
+É comum encontrar certos problemas no [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) durante o desenvolvimento do subgraph. Eles variam em dificuldade de debug, mas vale ter consciência deles. A seguir, uma lista não exaustiva destes problemas:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- O escopo não é herdado em [funções de closure](https://www.assemblyscript.org/status.html#on-closures), por ex., não é possível usar variáveis declaradas fora de funções de closure. Há uma explicação [neste vídeo](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From b0d920c0e5274541c50c1085f570abc8ea73073c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:37 -0500
Subject: [PATCH 0841/3820] New translations unit-testing-framework.mdx
 (Portuguese)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/pt/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/pt/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..d73ee0ee95cb
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Estrutura de Testes de Unidades
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Como Começar
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+Pode usar o Matchstick no WSL tanto com a abordagem do Docker quanto com a abordagem binária. Como o WSL pode ser um pouco complicado, aqui estão algumas dicas caso encontre problemas
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+ou
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### Opções de CLI
+
+Isto executará todos os testes na pasta-teste:
+
+```sh
+graph test
+```
+
+Isto executará um teste chamado gravity.test.ts e/ou todos os testes dentro de uma pasta chamada gravity:
+
+```sh
+graph test gravity
+```
+
+Isto só executará esse arquivo de teste específico:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuração
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Subgraph de demonstração
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Tutoriais de vídeo
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Estrutura de testes
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Exemplo:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Exemplo:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+ou
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Exemplos:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Exemplo:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Exemplos:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+A partir da versão 0.6.0, asserts também apoiam mensagens de erro personalizadas
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Como Escrever um Teste de Unidade
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Suponhamos que temos a seguinte função de handler (com duas funções de helper para facilitar):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+Primeiro, devemos criar um arquivo de teste no nosso projeto. Este é um exemplo de como ele pode ficar:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- Configuramos nosso estado inicial e adicionamos uma entidade de Gravatar personalizada;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- Garantimos o estado da loja. Como isto funciona? — Passamos uma combinação do tipo e da id da Entidade. Depois conferimos um campo específico naquela Entidade e garantimos que ela tem o valor que esperamos que tenha. Estamos a fazer isto tanto para a Entidade Gravatar inicial adicionada ao armazenamento, quanto para as duas entidades Gravatar adicionadas ao chamar a função de handler;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+Prontinho — criamos o nosso primeiro teste! 👏
+
+Para executar os nossos testes, basta apenas executar o seguinte na pasta raiz do seu subgraph:
+
+`graph test Gravity`
+
+E se tudo der certo, deve receber a seguinte resposta:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Cenários de teste comuns
+
+### Como hidratar o armazenamento com um certo estado
+
+Os utilizadores podem hidratar o armazenamento com um conjunto conhecido de entidades. Aqui está um exemplo para inicializar o armazenamento com uma entidade Gravatar:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Como chamar uma função de mapeamento com um evento
+
+Um utilizador pode criar um evento personalizado e passá-lo a uma função de mapeamento ligada ao armazenamento:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Como chamar todos os mapeamentos com fixações de eventos
+
+Os utilizadores podem chamar os mapeamentos com fixações de teste.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Como simular chamadas de contratos
+
+Os utilizadores podem simular chamadas de contratos:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+Como demonstrado, para simular uma chamada de contrato e conseguir um valor de retorno de linha-dura, o utilizador deve fornecer um endereço de contrato, nome de função, assinatura de função, arranjo de argumentos — e claro, o valor de retorno.
+
+Os utilizadores também podem simular regressos de funções:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Como simular arquivos IPFS (do matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// callback do ipfs.map
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks também podem criar entidades
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// função que chama o ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Como afirmar o estado do armazenamento
+
+Os utilizadores podem afirmar o estado final (ou parcial) do armazenamento através de entidades de afirmação. Para isto, o utilizador precisa fornecer um tipo de Entidade, a ID específica de uma Entidade, o nome de um campo naquela Entidade, e o valor esperado do campo. Aqui vai um exemplo rápido:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Como interagir com metadados de Eventos
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Leitura
+let logType = newGravatarEvent.logType
+
+// Escrita
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Como afirmar a igualdade das variáveis
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Os utilizadores podem afirmar que uma entidade não existe no armazenamento. A função toma um tipo e uma id de entidade. Caso a entidade esteja, de facto, na loja, o teste acabará em erro, com uma mensagem de erro relevante. Veja um exemplo rápido de como usar esta funcionalidade:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Impressão do armazenamento completo, ou de entidades individuais dele (para debugging)
+
+Pode imprimir o armazenamento inteiro na consola com esta função de helper:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Falhas esperadas
+
+Os utilizadores podem encontrar falhas esperadas, com o flag shouldFail nas funções <code>test()</code>:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+Caso o teste seja marcado com <code>shouldFail = true</code> mas NÃO falhe, isto será mostrado como um erro nos logs e o bloco de teste não terá êxito. E se for marcado com <code>shouldFail = false</code> (o estado normal), o executor de teste travará.
+
+### Logging
+
+Ter logs personalizados nos testes de unidade é a mesma coisa que logar nos mapeamentos. A diferença é que o objeto do log deve ser importado do matchstick-as, em vez do graph-ts. Aqui vai um exemplo simples com todos os tipos de log não-críticos:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Os utilizadores também podem simular uma falha crítica, como no seguinte:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Logar erros críticos interromperá a execução dos testes e causará um desastre. Afinal, queremos ter certeza que o seu código não tenha logs críticos no lançamento; perceberia imediatamente se isto acontecer.
+
+### Como testar campos derivados
+
+Testar campos derivados permite aos utilizadores configurar um campo numa entidade e atualizar outra automaticamente, caso ela derive um dos seus campos da primeira entidade.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Como testar fontes de dados dinâmicas
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Exemplo abaixo:
+
+Primeiro temos o seguinte handler de eventos (que foi apropriado intencionalmente para demonstrar a falsificação de fontes de dados):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+E então, temos o teste que usa um dos métodos do namespace dataSourceMock para determinar um novo valor de retorno para todas as funções do dataSource:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Note que o <code>dataSourceMock.resetValues()</code> é chamado no final. Isto é porque os valores são lembrados quando mudados, e devem ser reconfigurados caso queira voltar aos valores padrão.
+
+### Teste de criação de fontes de dados dinâmicas
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets que têm GRT trancado
+"""
+type TokenLockMetadata @entity {
+  "Endereço da token lock wallet"
+  id: ID!
+  "Começo da agenda de lançamento"
+  startTime: BigInt!
+  "Final da agenda de lançamento"
+  endTime: BigInt!
+  "Número de períodos entre o início e o fim"
+  periods: BigInt!
+  "Hora quando os lançamentos começam"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Exemplo de handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Exxemplo de teste
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Cobertura de Testes
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Pré-requisitos
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Exportar seus handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Uso
+
+Assim que tudo estiver pronto, para executar a ferramenta de cobertura de testes, basta:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+Isto executará a ferramenta de cobertura. Verás algo parecido com isto no terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Duração do teste na saída do log
+
+A saída do log inclui a duração do teste. Veja um exemplo:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Erros comuns do compilador
+
+> <code>Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined</code>
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> <code>ERROR TS2554: Expected ? arguments, but got ?.</code>
+>
+> <code>return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);</code>
+>
+> <code>in ~lib/matchstick-as/assembly/defaults.ts(18,12)</code>
+>
+> <code>ERROR TS2554: Expected ? arguments, but got ?.</code>
+>
+> <code>return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);</code>
+>
+> <code>in ~lib/matchstick-as/assembly/defaults.ts(24,12)</code>
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Outros Recursos
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Feedback
+
+Caso tenha qualquer pergunta, opinião, pedidos de recursos, ou só quer entrar em contacto, venha para o Discord do The Graph — lá, temos um canal dedicado ao Matchstick, chamado 🔥| unit-testing.

From 10a257646a09ae71bc48a9aac14b4996672fa7dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:38 -0500
Subject: [PATCH 0842/3820] New translations transferring-a-subgraph.mdx
 (Portuguese)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/pt/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/pt/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..1931370a6df7
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs publicados na rede descentralizada terão um NFT mintado no endereço que publicou o subgraph. O NFT é baseado no padrão ERC-721, que facilita transferências entre contas na Graph Network.
+
+## Reminders
+
+- O dono do NFT controla o subgraph.
+- Se o dono atual decidir vender ou transferir o NFT, ele não poderá mais editar ou atualizar aquele subgraph na rede.
+- É possível transferir o controle de um subgraph para uma multisig.
+- Um membro da comunidade pode criar um subgraph no nome de uma DAO.
+
+## View Your Subgraph as an NFT
+
+Para visualizar o seu subgraph como um NFT, visite um mercado de NFTs como o **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Ou um explorador de carteiras, como o **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Passo a Passo
+
+Para transferir a titularidade de um subgraph, faça o seguinte:
+
+1. Use a interface embutida no Subgraph Studio:
+
+   ![Transferência de Titularidade de Subgraph](/img/subgraph-ownership-transfer-1.png)
+
+2. Escolha o endereço para o qual gostaria de transferir o subgraph:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Também é possível usar a interface embutida de mercados de NFT, como o OpenSea:
+
+![Transferência de Titularidade de Subgraph de um mercado de NFT](/img/subgraph-ownership-transfer-nft-marketplace.png)

From bbdc97feb2d76aa8bab87527aee20f1948b823dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:39 -0500
Subject: [PATCH 0843/3820] New translations graphql-api.mdx (Portuguese)

---
 .../pt/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/pt/subgraphs/querying/graphql-api.mdx b/website/pages/pt/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..58f928ebbaed
--- /dev/null
+++ b/website/pages/pt/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: API GraphQL
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Exemplos
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Organização
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Exemplo
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Exemplo para organização de entidade aninhada
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Paginação
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Consulte os 10 primeiros tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtragem
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Exemplo para filtragem de alcance
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Exemplo para filtragem de blocos
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+Isto pode servir caso mire retirar apenas entidades que mudaram, por exemplo, desde a última vez que você pesquisou. Também pode ser bom investigar ou debugar como as entidades mudam no seu subgraph (se combinado com um filtro de blocos, pode isolar apenas entidades que mudaram em um bloco específico).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Exemplo para filtragem de entidade ninhada
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+Isto é bom caso mire retirar apenas entidades cujas entidades de nível-filho correspondem às condições requeridas.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Operadores lógicos
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### Todos os Filtros
+
+Lista completa de sufixos de parâmetro:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Consultas de viagem no tempo
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Exemplo
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Exemplo
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Consultas de Busca Fulltext
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Operadores de busca fulltext:
+
+| Símbolo | Operador    | Descrição                                                                                                                                                          |
+| ------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`     | `And`       | Para combinar múltiplos termos de busca num filtro para entidades que incluem todos os termos fornecidos                                                           |
+| |       | `Or`        | Consultas com vários termos de busca separados pelo operador <code>or</code> retornarão todas as entidades com uma correspondência de qualquer termo providenciado |
+| `<->`   | `Follow by` | Especifica a distância entre duas palavras.                                                                                                                        |
+| `:*`    | `Prefix`    | Use o prefixo para encontrar palavras que correspondem a tal prefixo (2 caracteres necessários.)                                                                   |
+
+#### Exemplos
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine operadores de fulltext para fazer filtros mais complexos. Com um operador de busca pretext combinado com um 'follow by', este exemplo de consulta corresponderá todas as entidades de blog com palavras que começam com "lou" seguido de "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validação
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entidades
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Metadados de Subgraph
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+Se um bloco for fornecido, os metadados são desde aquele bloco; e se não, é usado o último indexado. Se providenciado, o bloco deve ser após o inicial do subgraph, e menor ou igual ao bloco indexado mais recentemente.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: o hash do bloco
+- number: o número do bloco
+- timestamp: a hora do bloco, se disponível (disponível atualmente apenas para subgraphs que indexam redes EVM)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 2e071812016875156f01f88dcf617b4888663a79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:40 -0500
Subject: [PATCH 0844/3820] New translations python.mdx (Portuguese)

---
 .../pages/pt/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/querying/python.mdx

diff --git a/website/pages/pt/subgraphs/querying/python.mdx b/website/pages/pt/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..9b789b77fb29
--- /dev/null
+++ b/website/pages/pt/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Queries no The Graph com Python e Subgrounds
+---
+
+Subgrounds é uma biblioteca intuitiva em Python para a construção de subgraphs, construída pela [Playgrounds](https://playgrounds.network/). Ela permite-lhe conectar diretamente dados de subgraph a um ambiente de dados em Python e usar bibliotecas como [pandas](https://pandas.pydata.org/) para realizar análises de dados!
+
+O Subgrounds oferece uma API simples para a construção de queries em GraphQL, automatiza fluxos de trabalho entediantes, como a paginação, e empodera utilizadores avançados via transformações controladas de schema.
+
+## Como Começar
+
+O Subgrounds requer Python 3.10 ou maior, e está disponível no [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# ou
+python -m pip install --upgrade subgrounds
+```
+
+Quando instalado, você pode testar o subgrounds com o seguinte query. O exemplo a seguir coleta um subgraph do protocolo Aave v2 e realiza queries para os 5 maiores mercados ordenados por valor total bloqueado, seleciona os seus nomes e o seu VTB (em USD) e retorna os dados como um [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame) em pandas.
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Carrega o subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Constrói o query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Retorna o query a um quadro de dados
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentação
+
+O Subgrounds é construído e mantido pela [Playgrounds](https://playgrounds.network/) e pode ser acessado na [documentação do Playgrounds](https://docs.playgrounds.network/subgrounds).
+
+Como o subgrounds tem um grande conjunto de recursos para explorar, aqui estão alguns pontos úteis de início:
+
+- [Começando com Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - Um bom primeiro passo para construir queries com subgrounds.
+- [Construção de Campos Sintéticos](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - Uma introdução suave para a definição de campos sintéticos que transformam dados definidos do schema.
+- [Queries Concorrentes](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Aprenda como subir o nível das suas queries ao paralelizá-las.
+- [Exportação de Dados em CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 46a1b0b22b60f78f5db3ed873c25ff4c5b19b5cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:41 -0500
Subject: [PATCH 0845/3820] New translations triggers.mdx (Portuguese)

---
 website/pages/pt/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/pt/substreams/sps/triggers.mdx

diff --git a/website/pages/pt/substreams/sps/triggers.mdx b/website/pages/pt/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/pt/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From a5efb3bc472dea1fb19a80dd258df8a7d831ca2d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:42 -0500
Subject: [PATCH 0846/3820] New translations overview.mdx (Russian)

---
 website/pages/ru/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/ru/indexing/overview.mdx

diff --git a/website/pages/ru/indexing/overview.mdx b/website/pages/ru/indexing/overview.mdx
new file mode 100644
index 000000000000..c6255dfc3d1c
--- /dev/null
+++ b/website/pages/ru/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+
+Токены GRT, которые застейканы в протоколе, подлежат периоду "оттаивания" и могут быть срезаны, если индексаторы являются вредоносными и передают неверные данные приложениям или если они некорректно осуществляют индексирование. Индексаторы также получают вознаграждение за делегированный стейк от делегаторов, внося свой вклад в работу сети.
+
+Индексаторы выбирают подграфы для индексирования на основе сигналов от кураторов, в которых кураторы стейкают токены GRT, чтобы обозначить, какие подграфы являются высококачественными и заслуживают приоритетного внимания. Потребители (к примеру, приложения) также могут задавать параметры, по которым индексаторы обрабатывают запросы к их подграфам, и устанавливать предпочтения по цене за запрос.
+
+<Difficulty level="ADVANCED" />
+
+## Часто задаваемые вопросы
+
+### Какова минимальная величина стейка, требуемая для того, чтобы быть индексатором в сети?
+
+Минимальная величина стейка для индексатора в настоящее время установлена ​​на уровне 100 000 GRT.
+
+### Каковы источники доходов индексатора?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### Как распределяются вознаграждения за индексацию?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### Что такое подтверждение индексации (proof of indexing - POI)?
+
+POI (подтверждение индексации) используются в сети для проверки того, индексирует ли индексатор назначенные им подграфы. При закрытии распределения необходимо предоставить POI для первого блока текущей эпохи, чтобы это распределение имело право на индексацию наград. POI для блока — это дайджест для всех транзакций хранилища объектов для данного развертывания подграфа до этого блока включительно.
+
+### Когда распределяются вознаграждения за индексацию?
+
+Награды за распределения постоянно накапливаются, пока они активны и распределяются в течение 28 эпох. Награды собираются и распределяются индексаторами после того, как их распределение закрыто. Это делается либо вручную, если индексатор выбирает принудительное закрытие, либо через 28 эпох делегатор может закрыть выделение для индексатора, но это не приводит к вознаграждению. 28 эпох — это максимальное время жизни распределения (сейчас одна эпоха длится ~ 24 часа).
+
+### Каким образом можно отслеживать ожидаемые вознаграждения за индексацию?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Многие панели мониторинга, созданные сообществом, содержат ожидающие значения вознаграждений, и их можно легко проверить вручную, выполнив следующие действия:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### Что такое споры и где их можно просмотреть?
+
+Запросы и распределения индексатора могут быть оспорены на The Graph в течение периода спора. Срок спора варьируется в зависимости от типа спора. Запросы/аттестации имеют 7 эпох спорного окна, тогда как распределения имеют 56 эпох. По истечении этих периодов споры не могут быть открыты ни в отношении выделений, ни в отношении запросов. При открытии спора от Рыбаков требуется депозит в размере не менее 10 000 GRT, который будет заблокирован до завершения спора и принятия решения. Рыбаки — это любые участники сети, которые открывают споры.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- Если спор отклонен, то GRT, внесенные рыбаками, будут сожжены, а оспариваемый индексатор не будет урезан.
+- Если спор будет решен в виде ничьей, депозит рыбака будет возвращен, а спорный индексатор не будет урезан.
+- Если спор будет принят, GRT, внесенные рыбаками, будут возвращены, спорный индексатор будет урезан, а рыбаки получат 50% от урезанных GRT.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### Что такое query fee rebates и когда они распределяются?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+
+### Что такое query fee cut и indexing reward cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### Как индексаторы узнают, какие подграфы индексировать?
+
+Индексаторы могут отличаться друг от друга, применяя передовые методы принятия решений об индексации подграфов, но чтобы дать общее представление, мы обсудим несколько ключевых показателей, используемых для оценки подграфов в сети:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### Каковы требования к аппаратному обеспечению?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Настройка | Postgres<br />(ЦП) | Postgres<br />(память в ГБ) | Postgres<br />(диск в ТБ) | VMs<br />(ЦП) | VMs<br />(память в ГБ) |
+| --------- | :----------------: | :-------------------------: | :-----------------------: | :-----------: | :--------------------: |
+| Small     |          4         |              8              |             1             |       4       |           16           |
+| Standard  |          8         |              30             |             1             |       12      |           48           |
+| Medium    |         16         |              64             |             2             |       32      |           64           |
+| Large     |         72         |             468             |            3.5            |       48      |           184          |
+
+### Какие основные меры безопасности следует предпринять индексатору?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastructure
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Примечание: Для поддержки динамичного масштабирования рекомендуется разделить задачи запросов и индексирования между разными наборами нод: нодами запросов и нодами индексирования.
+
+### Обзор портов
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Порт | Назначение                                             | Расположение                                   | CLI-аргумент       | Переменная среды |
+| ---- | ------------------------------------------------------ | ---------------------------------------------- | ------------------ | ---------------- |
+| 8000 | HTTP-сервер GraphQL<br />(для запросов подграфов)      | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                |
+| 8001 | GraphQL WS<br />(для подписок на подграфы)             | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                |
+| 8020 | JSON-RPC<br />(для управления процессом развертывания) | /                                              | \--admin-port      | -                |
+| 8030 | API для определения статуса индексирования подграфов   | /graphql                                       | \--index-node-port | -                |
+| 8040 | Показатели Prometheus                                  | /metrics                                       | \--metrics-port    | -                |
+
+#### Indexer Service
+
+| Порт | Назначение                                                  | Расположение                                                | CLI-аргумент    | Переменная среды       |
+| ---- | ----------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | HTTP-сервер GraphQL<br />(для платных запросов к подграфам) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Показатели Prometheus                                       | /metrics                                                    | \--metrics-port | -                      |
+
+#### Indexer Agent
+
+| Порт | Purpose                         | Расположение | CLI Argument               | Environment Variable                    |
+| ---- | ------------------------------- | ------------ | -------------------------- | --------------------------------------- |
+| 8000 | API для управления индексатором | /            | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Настройка серверной инфраструктуры с помощью Terraform в Google Cloud
+
+> Примечание: Индексаторы могут в качестве альтернативы использовать AWS, Microsoft Azure или Alibaba.
+
+#### Установка предварительного обеспечения
+
+- Google Cloud SDK
+- Инструмент командной строки Kubectl
+- Terraform
+
+#### Создайте проект Google Cloud
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Авторизуйтесь в Google Cloud и создайте новый проект.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Используйте страницу биллинга в Google Cloud Console, чтобы включить эту функцию для нового проекта.
+
+- Создайте конфигурацию Google Cloud.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Включите необходимые API-интерфейсы Google Cloud.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Создайте сервисный аккаунт.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Активируйте peering между базой данных и кластером Kubernetes, который будет создан на следующем шаге.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Создайте минимальный файл конфигурации terraform (обновляйте его по мере необходимости).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Используйте Terraform для создания инфраструктуры
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Запустите следующие команды для создания инфраструктуры.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Создание Kubernetes компонентов для индексатора
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Начало работы с исходным кодом
+
+#### Установка предварительного обеспечения
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Настройка
+
+1. Запустите сервер базы данных PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Теперь, когда все зависимости настроены, запустите Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Начало работы с Docker
+
+#### Предварительные требования
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Настройка
+
+1. Клонируйте Graph Node и перейдите в директорию Docker:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Запустите локальную Graph Node, которая будет подключаться к вашему Ethereum эндпоинту:
+
+```sh
+docker-compose up
+```
+
+### Компоненты индексатора
+
+Для успешного участия в сети требуется почти постоянный мониторинг и взаимодействие, поэтому мы создали набор приложений на основе Typescript для облегчения участия индексаторов в сети. Существует три компонента индексатора:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Начало работы
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### Из пакетов NPM
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### Из исходного кода
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### С помощью docker
+
+- Извлеките образы из реестра
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Или создайте образы локально из исходного кода
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Запустите компоненты
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Использование K8s и Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Применение
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexer agent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Управление индексатором с помощью интерфейса командной строки индексатора
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Применение
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Indexing rules
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Модель данных:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Пример применения правила индексации:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Очередь действий в CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Действие, добавленное в очередь сторонним инструментом оптимизатора или пользователем indexer-cli
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- Индексатор может отслеживать очередность действий, просматривая историю выполнения действий и, при необходимости, повторно утвердить и обновить элементы действий, если они не выполнились. Очередность действий содержит историю всех действий, поставленных в очередь и выполненных.
+
+Модель данных:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Пример использования из исходного кода:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Обратите внимание, что поддерживаемые типы действий для управления распределением имеют разные входные требования:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - Требуемые параметры действия:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - Требуемые параметры действия:
+    - allocationID
+    - deploymentID
+  - Опциональные параметры действия:
+    - poi
+    - force (принудительно использует предоставленный POI, даже если он не соответствует тому, что предоставляет graph-node)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - Требуемые параметры действия:
+    - allocationID
+    - deploymentID
+    - amount
+  - Опциональные параметры действия:
+    - poi
+    - force (принудительно использует предоставленный POI, даже если он не соответствует тому, что предоставляет graph-node)
+
+#### Модели затрат
+
+Модели затрат обеспечивают динамическое ценообразование для запросов на основе рынка и атрибутов запроса. Служба индексатора делится со шлюзом моделью стоимости для каждого подграфа, для которого они намереваются отвечать на запросы. Шлюзы, в свою очередь, используют модель затрат для принятия решений о выборе индексатора для каждого запроса и согласования оплаты с выбранными индексаторами.
+
+#### Agora
+
+Язык Agora предоставляет гибкий формат для объявления моделей затрат на запросы. Ценовая модель Agora — это последовательность операторов, которые выполняются по порядку для каждого запроса верхнего уровня в запросе GraphQL. Для каждого запроса верхнего уровня цена за этот запрос определяется первым соответствующим ему оператором.
+
+Оператор состоит из predicate, который используется для сопоставления запросов GraphQL, и выражения стоимости, которое при оценке выводит стоимость в десятичном формате GRT. Значения в позиции именованного аргумента запроса могут быть захвачены в predicate и использованы в expression. Глобальные переменные также могут быть установлены и заменены на placeholders в expression.
+
+Пример модели затрат:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Пример расчета стоимости запроса с использованием приведенной выше модели:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Применение модели затрат
+
+Модели затрат применяются через интерфейс командной строки (CLI) индексатора, который передает их в API управления индексатором агента индексатора для сохранения в базе данных. Затем Indexer Service отбирает их и предоставляет модели затрат шлюзам каждый раз, когда они запрашивают их.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Взаимодействие с сетью
+
+### Стейкинг в протоколе
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Подтверждение токенов
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Стейкинг токенов
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### Срок существования аллокации
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 80f0546e2923656de669a56e22af9e9c054086a2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:43 -0500
Subject: [PATCH 0847/3820] New translations tap.mdx (Russian)

---
 website/pages/ru/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/ru/indexing/tap.mdx

diff --git a/website/pages/ru/indexing/tap.mdx b/website/pages/ru/indexing/tap.mdx
new file mode 100644
index 000000000000..62ca0e8c561c
--- /dev/null
+++ b/website/pages/ru/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Обзор
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Специфические особенности
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Требования
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Примечания:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From da1810d44cbcbea73341573d00da10a140c51e95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:44 -0500
Subject: [PATCH 0848/3820] New translations graph-node.mdx (Russian)

---
 .../pages/ru/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/ru/indexing/tooling/graph-node.mdx

diff --git a/website/pages/ru/indexing/tooling/graph-node.mdx b/website/pages/ru/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..d5ca3261edc7
--- /dev/null
+++ b/website/pages/ru/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node — это компонент, который индексирует подграфы и делает полученные данные доступными для запроса через GraphQL API. Таким образом, он занимает центральное место в стеке индексатора, а правильная работа Graph Node имеет решающее значение для успешного запуска индексатора.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### База данных PostgreSQL
+
+Основное хранилище для Graph Node, это место, где хранятся данные подграфа, а также метаданные о подграфах и сетевые данные, не зависящие от подграфа, такие как кэш блоков и кэш eth_call.
+
+### Клиенты сети
+
+Для индексации сети Graph Node требуется доступ к сетевому клиенту через EVM-совместимый JSON-RPC API. Этот RPC может подключаться к одному клиенту или может представлять собой более сложную настройку, которая распределяет нагрузку между несколькими.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### Ноды IPFS
+
+Метаданные о развертывании подграфа хранятся в сети IPFS. The Graph Node в первую очередь обращается к ноде IPFS во время развертывания подграфа, чтобы получить манифест подграфа и все связанные файлы. Сетевым индексаторам не требуется запускать собственную ноду IPFS. Нода IPFS для сети находиться по адресу https://ipfs.network.thegraph.com.
+
+### Сервер метрик Prometheus
+
+Чтобы включить мониторинг и отчетность, Graph Node может дополнительно регистрировать метрики на сервере метрик Prometheus.
+
+### Начало работы с исходным кодом
+
+#### Установка предварительного обеспечения
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Настройка
+
+1. Запустите сервер базы данных PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Теперь, когда все зависимости настроены, запустите Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Начало работы с Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Порты
+
+Во время работы Graph Node предоставляет следующие порты:
+
+| Порт | Назначение                                             | Расположение                                   | CLI-аргумент       | Переменная среды |
+| ---- | ------------------------------------------------------ | ---------------------------------------------- | ------------------ | ---------------- |
+| 8000 | HTTP-сервер GraphQL<br />(для запросов подграфов)      | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                |
+| 8001 | GraphQL WS<br />(для подписок на подграфы)             | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                |
+| 8020 | JSON-RPC<br />(для управления процессом развертывания) | /                                              | \--admin-port      | -                |
+| 8030 | API для определения статуса индексирования подграфов   | /graphql                                       | \--index-node-port | -                |
+| 8040 | Показатели Prometheus                                  | /metrics                                       | \--metrics-port    | -                |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Расширенная настройка Graph Node
+
+На простейшем уровне Graph Node может работать с одним экземпляром Graph Node, одной базой данных PostgreSQL, нодой IPFS и сетевыми клиентами в соответствии с требованиями субграфов, подлежащих индексированию.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> При использовании файла конфигурации невозможно использовать параметры --postgres-url, --postgres-secondary-hosts и --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Множественные Graph Node
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Обратите внимание, что несколько Graph Nodes могут быть настроены для использования одной и той же базы данных, которая сама по себе может масштабироваться по горизонтали с помощью сегментирования.
+
+#### Правила развертывания
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Пример настройки правил развертывания:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Выделенные ноды запросов
+
+Ноды можно настроить так, чтобы они были нодами запросов, включив в файл конфигурации следующее:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Любая нода, чей --node-id соответствует регулярному выражению, будет настроена так, чтобы отвечать только на запросы.
+
+#### Масштабирование базы данных с помощью шардинга (сегментирования)
+
+В большинстве случаев одной базы данных Postgres достаточно для поддержки отдельной Graph Node. Когда отдельная Graph Node перерастает одну базу данных Postgres, можно разделить хранилище данных Graph Node между несколькими базами данных Postgres. Все базы данных вместе образуют хранилище отдельной Graph Node. Каждая отдельная база данных называется шардом (сегментом).
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Сегментирование становится полезным, когда Ваша существующая база данных не может справиться с нагрузкой, которую на нее возлагает Graph Node, и когда больше невозможно увеличить размер базы данных.
+
+> Обычно лучше сделать одну базу данных максимально большой, прежде чем начинать с шардов (сегментов). Единственным исключением является случай, когда трафик запросов распределяется между подграфами очень неравномерно; в таких ситуациях может существенно помочь, если подграфы большого объема хранятся в одном сегменте, а все остальное — в другом, потому что такая настройка повышает вероятность того, что данные для подграфов большого объема останутся во внутреннем кеше базы данных и не будут заменяться данными, которые не очень нужны, из подграфов с небольшим объемом.
+
+Что касается настройки соединений, начните с max_connections в postgresql.conf, установленного на 400 (или, может быть, даже на 200), и посмотрите на метрики store_connection_wait_time_ms и store_connection_checkout_count Prometheus. Длительное время ожидания (все, что превышает 5 мс) является признаком того, что доступных соединений слишком мало; большое время ожидания также будет вызвано тем, что база данных очень загружена (например, высокая загрузка ЦП). Однако, если в остальном база данных кажется стабильной, большое время ожидания указывает на необходимость увеличения количества подключений. В конфигурации количество подключений, которое может использовать каждая отдельная Graph Node, является верхним пределом, и Graph Node не будет держать соединения открытыми, если они ей не нужны.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Прием выделенного блока
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Поддержка нескольких сетей
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Несколько сетей
+- Несколько провайдеров на сеть (это может позволить разделить нагрузку между провайдерами, а также может позволить настроить полные ноды, а также архивные ноды, при этом Graph Node предпочитает более дешевых поставщиков, если позволяет данная рабочая нагрузка).
+- Дополнительные сведения о провайдере, такие как функции, аутентификация и тип провайдера (для экспериментальной поддержки Firehose)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Переменные среды
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Непрерывное развертывание
+
+Пользователи, использующие масштабируемую настройку индексирования с расширенной конфигурацией, могут получить преимущество от управления своими узлами Graph с помощью Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Управление Graph Node
+
+При наличии работающей Graph Node (или Graph Nodes!), задача состоит в том, чтобы управлять развернутыми подграфами на этих нодах. Graph Node предлагает ряд инструментов для управления подграфами.
+
+#### Логирование (ведение журналов)
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node предоставляет метрики через конечную точку Prometheus на порту 8040 по умолчанию. Затем можно использовать Grafana для визуализации этих метрик.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Работа с подграфами
+
+#### API статуса индексирования
+
+Доступный по умолчанию на порту 8030/graphql, API статуса индексирования предоставляет ряд методов для проверки статуса индексирования для различных подграфов, проверки доказательств индексирования, проверки функций подграфов и многого другого.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Производительность индексирования
+
+Процесс индексирования состоит из трех отдельных частей:
+
+- Получение интересующих событий от провайдера
+- Обработка событий по порядку с помощью соответствующих обработчиков (это может включать вызов чейна для состояния и выборку данных из хранилища)
+- Запись полученных данных в хранилище
+
+Эти этапы конвейерные (т.е. могут выполняться параллельно), но они зависят друг от друга. Там, где подграфы индексируются медленно, основная причина будет зависеть от конкретного подграфа.
+
+Распространенные причины низкой скорости индексации:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- Большое количество операций с хранилищем во время выполнения
+- Большой объем данных для сохранения в хранилище
+- Большое количество событий для обработки
+- Медленное время подключения к базе данных для переполненных нод
+- Сам провайдер отстает от головного чейна
+- Задержка получения новых поступлений от провайдера в головном чейне
+
+Метрики индексации подграфов могут помочь диагностировать основную причину замедления индексации. В некоторых случаях проблема связана с самим подграфом, но в других случаях усовершенствованные сетевые провайдеры, снижение конкуренции за базу данных и другие улучшения конфигурации могут заметно повысить производительность индексирования.
+
+#### Повреждённые подграфы
+
+Во время индексации подграфов может произойти сбой, если они столкнутся с неожиданными данными, какой-то компонент не будет работать должным образом или если в обработчиках событий или конфигурации появится ошибка. Есть два основных типа отказа:
+
+- Детерминированные сбои: это сбои, которые не будут устранены при повторных попытках
+- Недетерминированные сбои: они могут быть связаны с проблемами с провайдером или какой-либо неожиданной ошибкой Graph Node. Когда происходит недетерминированный сбой, Graph Node повторяет попытки обработчиков сбоя, со временем отказываясь от них.
+
+В некоторых случаях сбой может быть устранен индексатором (например, если ошибка вызвана отсутствием нужного поставщика, добавление необходимого поставщика позволит продолжить индексирование). Однако в других случаях требуется изменить код подграфа.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Кэш блокировки и вызова
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+Если есть подозрение на несогласованность кэша блоков, например, событие отсутствия квитанции tx:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. Если блок соответствует провайдеру, то проблема может быть отлажена непосредственно провайдером.
+
+#### Запрос проблем и ошибок
+
+После индексации подграфа индексаторы могут рассчитывать на обслуживание запросов через выделенную конечную точку запроса подграфа. Если индексатор планирует обслуживать значительный объем запросов, рекомендуется выделенная нода запросов, а в случае очень больших объемов запросов индексаторы могут настроить сегменты копий так, чтобы запросы не влияли на процесс индексирования.
+
+Однако, даже с выделенной нодой запросов и копиями выполнение некоторых запросов может занять много времени, а в некоторых случаях увеличить использование памяти и негативно повлиять на время выполнения запросов другими пользователями.
+
+Существует не одна «серебряная пуля» (панацея), а целый ряд инструментов для предотвращения, диагностики и обработки медленных запросов.
+
+##### Кэширование запросов
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Анализ запросов
+
+Проблемные запросы чаще всего выявляются одним из двух способов. В некоторых случаях пользователи сами сообщают, что данный запрос выполняется медленно. В этом случае задача состоит в том, чтобы диагностировать причину замедленности — является ли это общей проблемой или специфичной для этого подграфа или запроса. А затем, конечно же, решить ее, если это возможно.
+
+В других случаях триггером может быть высокий уровень использования памяти на ноде запроса, и в этом случае сначала нужно определить запрос, вызвавший проблему.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+При медленном запросе у индексаторов есть несколько вариантов. Разумеется, они могут изменить свою модель затрат, чтобы значительно увеличить стоимость отправки проблемного запроса. Это может привести к снижению частоты этого запроса. Однако это часто не устраняет основной причины проблемы.
+
+##### Аккаунт-подобная оптимизация
+
+Таблицы базы данных, в которых хранятся объекты, как правило, бывают двух видов: «подобные транзакциям», когда объекты, однажды созданные, никогда не обновляются, т. е. они хранят что-то вроде списка финансовых транзакций и «подобные учетной записи», где объекты обновляются очень часто, т. е. они хранят что-то вроде финансовых счетов, которые изменяются каждый раз при записи транзакции. Таблицы, подобные учетным записям, характеризуются тем, что они содержат большое количество версий объектов, но относительно мало отдельных объектов. Часто в таких таблицах количество отдельных объектов составляет 1% от общего количества строк (версий объектов)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Удаление подграфов
+
+> Это новый функционал, который будет доступен в Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 9b5f4f44369291d1c357afb63e667e61548e07d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:45 -0500
Subject: [PATCH 0849/3820] New translations advanced.mdx (Russian)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/ru/subgraphs/developing/creating/advanced.mdx b/website/pages/ru/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..edf4e8358bd9
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Обзор
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Тайм-серии и агрегации
+
+Тайм-серии и агрегации позволяют Вашему субграфу отслеживать такие статистические данные, как средняя цена за день, общий объем переводов за час и т. д.
+
+Эта функция представляет два новых типа объектов субграфов. Объекты тайм-серий записывают точки данных с временными метками. Объекты агрегирования выполняют заранее объявленные вычисления над точками данных тайм-серий ежечасно или ежедневно, а затем сохраняют результаты для быстрого доступа через GraphQL.
+
+### Пример схемы
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Определение тайм-серий и агрегаций
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Доступные интервалы агрегации
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Доступные функции агрегации
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Пример запроса агрегации
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Примечание:
+
+Чтобы использовать тайм-серии и агрегации, субграф должен иметь версию спецификации ≥1.1.0. Обратите внимание, что эта функция может претерпеть значительные изменения, которые могут повлиять на обратную совместимость.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Нефатальные ошибки
+
+Ошибки индексирования в уже синхронизированных субграфах по умолчанию приведут к сбою субграфа и прекращению синхронизации. В качестве альтернативы субграфы можно настроить на продолжение синхронизации при наличии ошибок, игнорируя изменения, внесенные обработчиком, который спровоцировал ошибку. Это дает авторам субграфов время на исправление своих субграфов, в то время как запросы к последнему блоку продолжают обрабатываться, хотя результаты могут быть противоречивыми из-за бага, вызвавшего ошибку. Обратите внимание на то, что некоторые ошибки всё равно всегда будут фатальны. Чтобы быть нефатальной, ошибка должна быть детерминированной.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Для включения нефатальных ошибок необходимо установить в манифесте субграфа следующий флаг функции:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## Источники файловых данных IPFS/Arweave
+
+Источники файловых данных — это новая функциональность субграфа для надежного и расширенного доступа к данным вне чейна во время индексации. Источники данных файлов поддерживают получение файлов из IPFS и Arweave.
+
+> Это также закладывает основу для детерминированного индексирования данных вне сети, а также потенциального введения произвольных данных из HTTP-источников.
+
+### Обзор
+
+Вместо "встроенного" получения файлов во время выполнения обработчика, это решение вводит шаблоны, которые могут создаваться в качестве новых источников данных для заданного идентификатора файла. Эти новые источники данных загружают файлы, повторяя попытки в случае неудачи, и запускают специальный обработчик при нахождении файла.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Руководство по обновлению
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Добавьте новый тип объекта, который будет обновляться при обнаружении файлов
+
+Источники файловых данных не могут получать доступ к объектам на чейн-основе или обновлять их, но должны обновлять объекты, специфичные для файлов.
+
+Это может означать разделение полей существующих объектов на отдельные объекты, связанные между собой.
+
+Исходный объединенный объект:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+Новый разделенный объект:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+Если между родительским объектом и результирующим объектом-источником данных существует связь1:1, то наиболее простым вариантом будет связать родительский объект с результирующим файловым объектом, используя в качестве поиска IPFS CID. Свяжитесь с нами в Discord, если у Вас возникли трудности с моделированием новых объектов на основе файлов!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+Это источник данных, который будет создан при обнаружении интересующего файла.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Создание нового обработчика для обработки файлов
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Пример обработчика:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Создание файловых источников данных при необходимости
+
+Теперь вы можете создавать файловые источники данных во время выполнения обработчиков на чейн-основе:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Пример:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//Этот пример кода предназначен для сборщика субграфа Crypto. Приведенный выше хеш ipfs представляет собой каталог с метаданными токена для всех NFT криптоковена.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //Это создает путь к метаданным для одного сборщика NFT Crypto. Он объединяет каталог с "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+Это создаст новый источник данных файла, который будет опрашивать настроенную конечную точку IPFS или Arweave Graph Node, повторяя попытку, если она не найдена. Когда файл будет найден, будет выполнен обработчик источника данных файла.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Поздравляем, Вы используете файловые источники данных!
+
+#### Развертывание субграфов
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Ограничения
+
+Обработчики и объекты файловых источников данных изолированы от других объектов субграфа, что гарантирует их детерминированность при выполнении и исключает загрязнение источников данных на чейн-основе. В частности:
+
+- Объекты, созданные с помощью файловых источников данных, неизменяемы и не могут быть обновлены
+- Обработчики файловых источников данных не могут получить доступ к объектам из других файловых источников данных
+- Объекты, связанные с источниками данных файлов, не могут быть доступны обработчикам на чейн-основе
+
+> Хотя это ограничение не должно вызывать проблем в большинстве случаев, для некоторых оно может вызвать сложности. Если у Вас возникли проблемы с моделированием Ваших файловых данных в субграфе, свяжитесь с нами через Discord!
+
+Кроме того, невозможно создать источники данных из файлового источника данных, будь то источник данных onchain или другой файловый источник данных. Это ограничение может быть снято в будущем.
+
+#### Лучшие практики
+
+Если Вы связываете метаданные NFT с соответствующими токенами, используйте хэш IPFS метаданных для ссылки на объект Metadata из объекта Token. Сохраните объект Metadata, используя хэш IPFS в качестве идентификатора.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> Мы работаем над улучшением приведенной выше рекомендации, поэтому запросы возвращают только "самую последнюю" версию
+
+#### Известные проблемы
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Примеры
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### Ссылки
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Фильтры индексированных аргументов/фильтры тем
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Фильтры по темам, также известные как фильтры по индексированным аргументам, — это мощная функция в субграфах, которая позволяет пользователям точно фильтровать события блокчейна на основе значений их индексированных аргументов.
+
+- Эти фильтры помогают изолировать конкретные интересующие события из огромного потока событий в блокчейне, позволяя субграфам работать более эффективно, сосредотачиваясь только на релевантных данных.
+
+- Это полезно для создания персональных субграфов, отслеживающих конкретные адреса и их взаимодействие с различными смарт-контрактами в блокчейне.
+
+### Как работают фильтры тем
+
+Когда смарт-контракт генерирует событие, любые аргументы, помеченные как индексированные, могут использоваться в манифесте субграфа в качестве фильтров. Это позволяет субграфу выборочно прослушивать события, соответствующие этим индексированным аргументам.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// Идентификатор лицензии SPDX: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Объявление события с индексируемыми параметрами для адресов
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Функция для имитации передачи токенов
+    function transfer(address to, uint256 value) public {
+        // Генерация события Transfer с указанием from, to и value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+В этом примере:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Конфигурация в субграфах
+
+Фильтры тем определяются непосредственно в конфигурации обработчика событий в манифесте субграфа. Вот как они настроены:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+В этой настройке:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Каждая тема может иметь одно или несколько значений, и событие обрабатывается только в том случае, если оно соответствует одному из значений в каждой указанной теме.
+
+#### Логика фильтра
+
+- В рамках одной темы: логика действует как условие OR. Событие будет обработано, если оно соответствует любому из перечисленных значений в данной теме.
+- Между разными темами: логика функционирует как условие AND. Событие должно удовлетворять всем указанным условиям в разных темах, чтобы вызвать соответствующий обработчик.
+
+#### Пример 1. Отслеживание прямых переводов с адреса A на адрес B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+В данной конфигурации:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Пример 2. Отслеживание транзакций в любом направлении между двумя и более адресами
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Адрес отправителя
+    topic2: ['0xAddressB', '0xAddressC'] # Адрес получателя
+```
+
+В данной конфигурации:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- Субграф будет индексировать транзакции, происходящие в любом направлении между несколькими адресами, что позволит осуществлять комплексный мониторинг взаимодействий с участием всех адресов.
+
+## Декларированный eth_call
+
+> Примечание: Это экспериментальная функция, которая пока недоступна в стабильной версии Graph Node. Вы можете использовать её только в Subgraph Studio или на своей локальной ноде.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+Эта функция выполняет следующие действия:
+
+- Значительно повышает производительность получения данных из блокчейна Ethereum за счет сокращения общего времени выполнения нескольких вызовов и оптимизации общей эффективности субграфа.
+- Обеспечивает ускоренное получение данных, что приводит к более быстрому реагированию на запросы и улучшению пользовательского опыта.
+- Сокращает время ожидания для приложений, которым необходимо агрегировать данные из нескольких вызовов Ethereum, что делает процесс получения данных более эффективным.
+
+### Ключевые понятия
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Параллельное выполнение: Вместо того, чтобы ждать завершения одного вызова перед началом следующего, можно инициировать несколько вызовов одновременно.
+- Эффективность использования времени: Общее время, затраченное на все вызовы, изменяется от суммы времени отдельных вызовов (последовательные) до времени, затраченного на самый продолжительный вызов (параллельные).
+
+#### Scenario without Declarative `eth_calls`
+
+Представьте, что у вас есть субграф, которому необходимо выполнить три вызова в Ethereum, чтобы получить данные о транзакциях пользователя, балансе и владении токенами.
+
+Традиционно эти вызовы могут выполняться последовательно:
+
+1. Вызов 1 (Транзакции): Занимает 3 секунды
+2. Вызов 2 (Баланс): Занимает 2 секунды
+3. Вызов 3 (Холдинг токенов): Занимает 4 секунды
+
+Общее затраченное время = 3 + 2 + 4 = 9 секунд
+
+#### Scenario with Declarative `eth_calls`
+
+С помощью этой функции Вы можете объявить, что эти вызовы будут выполняться параллельно:
+
+1. Вызов 1 (Транзакции): Занимает 3 секунды
+2. Вызов 2 (Баланс): Занимает 2 секунды
+3. Вызов 3 (Холдинг токенов): Занимает 4 секунды
+
+Поскольку эти вызовы выполняются параллельно, общее затраченное время равно времени, затраченному на самый длительный вызов.
+
+Общее затраченное время = макс. (3, 2, 4) = 4 секунды
+
+#### Как это работает
+
+1. Декларативное определение: В манифесте субграфа Вы декларируете вызовы Ethereum таким образом, чтобы указать, что они могут выполняться параллельно.
+2. Механизм параллельного выполнения: Механизм выполнения The Graph Node распознает эти объявления и выполняет вызовы одновременно.
+3. Агрегация результатов: После завершения всех вызовов результаты агрегируются и используются субграфом для дальнейшей обработки.
+
+#### Пример конфигурации в манифесте субграфа
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Подробности для приведенного выше примера:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Графтинг (перенос) на существующие субграфы
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Поскольку графтинг копирует, а не индексирует базовые данные, гораздо быстрее перенести субграф в нужный блок, чем индексировать с нуля, хотя для очень больших субграфов копирование исходных данных может занять несколько часов. Пока графтовый субграф инициализируется, узел The Graph будет регистрировать информацию о типах объектов, которые уже были скопированы.
+
+Перенесённый субграф может использовать схему GraphQL, которая не идентична схеме базового субграфа, а просто совместима с ней. Это должна быть автономно действующая схема субграфа, но она может отличаться от схемы базового субграфа следующим образом:
+
+- Она добавляет или удаляет типы объектов
+- Она удаляет атрибуты из типов объектов
+- Она добавляет обнуляемые атрибуты к типам объектов
+- Она превращает необнуляемые атрибуты в обнуляемые
+- Она добавляет значения в перечисления
+- Она добавляет или удаляет интерфейсы
+- Она изменяется в зависимости от того, под какой тип объектов реализован интерфейс
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 18f0020848b6948368fbb3e8d7a62e3963308260 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:46 -0500
Subject: [PATCH 0850/3820] New translations api.mdx (Russian)

---
 .../developing/creating/graph-ts/api.mdx      | 892 ++++++++++++++++++
 1 file changed, 892 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/ru/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/ru/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..727f252a9650
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,892 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Узнайте, какие встроенные API можно использовать при написании мэппингов субграфов. По умолчанию доступны два типа API:
+
+- [Библиотека The Graph TypeScript](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Код, сгенерированный из файлов субграфов с помощью `graph codegen`
+
+Вы также можете добавлять другие библиотеки в качестве зависимостей, если они совместимы с [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Поскольку мэппинги языков написаны на AssemblyScript, полезно ознакомиться с функциями языка и стандартной библиотеки на [вики-странице AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## Референс API
+
+Библиотека `@graphprotocol/graph-ts` предоставляет следующие API:
+
+- API `ethereum` для работы со смарт-контактами Ethereum, событиями, блоками, транзакциями и значениями Ethereum.
+- API `store` для загрузки и сохранения объектов из хранилища the Graph Node и в него.
+- API `log` для регистрации сообщений в выходных данных the Graph Node и Graph Explorer.
+- API `ipfs` для загрузки файлов из IPFS.
+- API `json` для выполнения разбора данных в формате JSON.
+- API `crypto` для использования криптографических функций.
+- Низкоуровневые примитивы для перевода между системами различных типов, таких как Ethereum, JSON, GraphQL и AssemblyScript.
+
+### Версии
+
+`apiVersion` в манифесте субграфа указывает версию мэппинга API, которая запускается посредством Graph Node для данного субграфа.
+
+| Версия | Примечания к релизу                                                                                                                                                                                                                                      |
+| :----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9 | Добавлены новые функции хоста [`eth_get_balance`](#balance-of-an-address) и [`hasCode`](#check-if-an-address-a-contract-or-eoa)                                                                                                                          |
+|  0.0.8 | Добавлена проверка наличия полей в схеме при сохранении объекта.                                                                                                                                                                                         |
+|  0.0.7 | К типам Ethereum добавлены классы `TransactionReceipt` и `Log`<br />К объекту Ethereum Event добавлено поле `receipt`                                                                                                                                    |
+|  0.0.6 | В объект Ethereum Transaction добавлено поле `nonce`<br />В объект Ethereum Block добавлено поле `baseFeePerGas`                                                                                                                                         |
+|  0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4 | В объект Ethereum SmartContractCall добавлено поле `functionSignature`                                                                                                                                                                                   |
+|  0.0.3 | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2 | В объект Ethereum Transaction добавлено поле `input`                                                                                                                                                                                                     |
+
+### Встроенные типы
+
+Документацию по базовым типам, встроенным в AssemblyScript, можно найти в [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+Дополнительные типы, предоставляемые `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` представляет собой массив `u8`.
+
+_Конструкция_
+
+- `fromI32(x: i32): ByteArray` — Разбивает `x` на байты.
+- `fromHexString(hex: string): ByteArray` - Длина ввода должна быть четной. Префикс `0x` необязателен.
+
+_Преобразования типов_
+
+- `toHexString(): string` - Преобразуется в шестнадцатеричную строку с префиксом `0x`.
+- `toString(): string` - Интерпретирует байты как строку UTF-8.
+- `to Base 58(): string` - Кодирует байты в строку base58.
+- `to U32(): u32` - Интерпретирует байты как little-endian `u32`. Выбрасывает в случае переполнения.
+- `to I32(): i32` - Интерпретирует массив байтов как little-endian `i32`. Выбрасывает в случае переполнения.
+
+_Операторы_
+
+- `equals(y: ByteArray): bool` – может быть записано как `x == y`.
+- `concat(other: ByteArray) : ByteArray` - возвращает новый `ByteArray`, состоящий из `this`, за которым непосредственно следует `other`
+- `concatI32(other: i32) : ByteArray` - возвращает новый `ByteArray`, состоящий из `this`, за которым непосредственно следует байтовое представление `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` используется для представления десятичных знаков произвольной точности.
+
+> Примечание: [Внутренне](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` хранится в [формате с плавающей точкой IEEE-754 decimal128](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), который поддерживает 34 десятичных знака после запятой. Это делает `BigDecimal` непригодным для представления типов с фиксированной точкой, которые могут охватывать более 34 знаков, таких как Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) или его эквивалентов.
+
+_Конструкция_
+
+- `constructor(bigInt: BigInt)` — создает `BigDecimal` из `BigInt`.
+- `static fromString(s: string): BigDecimal` – выполняет синтаксический разбор из десятичной строки.
+
+_Преобразования типов_
+
+- `toString(): string` – выводит в виде десятичной строки.
+
+_Математика_
+
+- `plus(y: BigDecimal): BigDecimal` – может быть записано как `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – может быть записано как `x - y`.
+- `times(y: BigDecimal): BigDecimal` – может быть записано как `x * y`.
+- `div(y: BigDecimal): BigDecimal` – может быть записано как `x / y`.
+- `equals(y: BigDecimal): bool` – может быть записано как `x == y`.
+- `notEqual(y: BigDecimal): bool` – может быть записано как `x != y`.
+- `lt(y: BigDecimal): bool` – может быть записано как `x < y`.
+- `le(y: BigDecimal): bool` – может быть записано как `x <= y`.
+- `gt(y: BigDecimal): bool` – может быть записано как `x > y`.
+- `ge(y: BigDecimal): bool` – может быть записано как `x >= y`.
+- `neg(): BigDecimal` - может быть записано как `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` используется для представления больших целых чисел. Сюда входят значения Ethereum типа от `uint32` до `uint256` и от `int64` до `int256`. Все, что находится ниже `uint32`, например `int32`, `uint24` или `int8`, представлено как `i32`.
+
+Класс `BigInt` имеет следующий API:
+
+_Конструкция_
+
+- `BigInt.fromI32(x: i32): BigInt` – создает `BigInt` из `i32`.
+
+- `BigInt.fromString(s:string): BigInt`– Выполняет разбор `BigInt` из строки.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` — Интерпретирует `bytes` беззнаковое целое число в формате little-endian (младшие байты идут первыми). Если Ваши входные данные в формате big-endian (старшие байты идут первыми), сначала вызовите `.reverse()`.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` — Интерпретирует `bytes` как знаковое целое число в формате little-endian (младшие байты идут первыми). Если Ваши входные данные в формате big-endian (старшие байты идут первыми), сначала вызовите `.reverse()`.
+
+  _Преобразования типов_
+
+- `x.toHex(): string` – преобразует `BigInt` в строку шестнадцатеричных символов.
+
+- `x.toString(): string` – преобразует `BigInt` в строку десятичных чисел.
+
+- `x.toI32(): i32` – возвращает `BigInt` в виде `i32`; завершается с ошибкой, если значение не соответствует `i32`. Рекомендуется сначала проверить `x.is I32()`.
+
+- `x.to BigDecimal(): BigDecimal` - преобразует в десятичное число без дробной части.
+
+_Математика_
+
+- `x.plus(y: BigInt): BigInt` – может быть записано как `x + y`.
+- `x.minus(y: BigInt): BigInt` – может быть записано как `x - y`.
+- `x.times(y: BigInt): BigInt` – может быть записано как `x * y`.
+- `x.div(y: BigInt): BigInt` – может быть записано как `x / y`.
+- `x.mod(y: BigInt): BigInt` – может быть записано как `x % y`.
+- `x.equals(y: BigInt): bool` – может быть записано как `x == y`.
+- `x.notEqual(y: BigInt): bool` – может быть записано как `x != y`.
+- `x.lt(y: BigInt): bool` – может быть записано как `x < y`.
+- `x.le(y: BigInt): bool` – может быть записано как `x <= y`.
+- `x.gt(y: BigInt): bool` – может быть записано как `x > y`.
+- `x.ge(y: BigInt): bool` – может быть записано как `x >= y`.
+- `x.neg(): BigInt` – может быть записано как `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – делит на десятичное число, что дает десятичный результат.
+- `x.isZero(): bool` – Удобство для проверки, равно ли число нулю.
+- `x.isI32(): bool` – Проверяет, соответствует ли число `i32`.
+- `x.abs(): BigInt` – Абсолютное значение.
+- `x.pow(exp: u8): BigInt` – Возведение в степень.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – может быть записан как `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – может быть записан как `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – может быть записан как `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – может быть записан как `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` можно использовать для хранения пар ключ-значение. Смотрите [этот пример](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+Класс `TypedMap` имеет следующий API:
+
+- `new TypedMap<K, V>()` создает пустую карту с ключами типа `K` и значениями типа `V`
+- `map.set(key: K, value: V): void` – устанавливает значение `key` в `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – возвращает пару ключ-значение для `key` или `null`, если `key` не существует на карте
+- `map.get(key: K): V | null` – возвращает значение для `key` или `null`, если `key` не существует на карте
+- `map.isSet(key: K): bool` – возвращает `true`, если `key` существует на карте, и `false`, если его нет
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` используется для представления массивов байтов произвольной длины. Сюда входят значения Ethereum типа `bytes`, `bytes32` и т. д.
+
+Класс `Bytes` расширяет [Uint8Array] из AssemblyScript (https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) и поддерживает все функциональные возможности `Uint8Array`, а также следующие новые методы:
+
+_Конструкция_
+
+- `fromHexString(hex: string) : Bytes` - Преобразует строку `hex`, которая должна состоять из четного числа шестнадцатеричных цифр, в `ByteArray`. Строка `hex` может опционально начинаться с `0x`
+- `fromI32(i: i32) : Bytes` - Преобразовывает `i` в массив байтов
+
+_Преобразования типов_
+
+- `b.toHex()` – возвращает шестнадцатеричную строку, представляющую байты в массиве
+- `b.toString()` – преобразует байты в массиве в строку символов Unicode
+- `b.toBase58()` – преобразует значение Ethereum `Bytes` в кодировку `base58` (используется для хэшей IPFS)
+
+_Операторы_
+
+- `b.concat(other: Bytes) : Bytes` - - возвращает новые `Bytes`, состоящие из `this`, за которым непосредственно следует `other`
+- `b.concatI32(other: i32) : ByteArray` - возвращает новые `Bytes`, состоящие из `this`, за которым непосредственно следует байтовое представление `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` расширяет `Bytes` для представления значений Ethereum `address`.
+
+Поверх `Bytes` API добавляется следующий метод:
+
+- `Address.fromString(s: string): Address` – создает `Address` из шестнадцатеричной строки
+- `Address.fromBytes(b: Bytes): Address` — создайте `Address` из `b` длиной ровно 20 байт. Передача значения с меньшим или большим количеством байт приведет к ошибке
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+API `store` позволяет загружать, сохранять и удалять объекты из хранилища the Graph Node и в него.
+
+Объекты, записанные в хранилище карты, сопоставляются один к одному с типами `@entity`, определенными в схеме субграфов GraphQL. Чтобы сделать работу с этими объектами удобной, команда `graph codegen`, предоставляемая [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) генерирует классы объектов, которые являются подклассами встроенного типа `Entity`, с геттерами и сеттерами свойств для полей в схеме, а также методами загрузки и сохранения этих объектов.
+
+#### Создание объектов
+
+Ниже приведен общий шаблон для создания объектов из событий Ethereum.
+
+```typescript
+// Импорт класса событий Transfer, сгенерированного из ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Импорт типа объекта Transfer, сгенерированного из схемы GraphQL 
+import { Transfer } from '../generated/schema'
+событие
+// Обработчик события передачи
+экспортирует функцию handleTransfer(event: TransferEvent): void {
+  // Создание объекта Transfer, с использованием хеша транзакции в качестве идентификатора объекта
+let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Установка свойства объекта, с использованием параметров события
+transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Сохранение объекта в хранилище
+transfer.save()
+}
+```
+
+Когда при обработке чейна возникает событие `Transfer`, оно передается обработчику события `handleTransfer`, используя сгенерированный тип `Transfer` (здесь используется псевдоним `TransferEvent`, чтобы избежать конфликта наименования с типом объекта). Этот тип позволяет получить доступ к таким данным, как материнская транзакция события и ее параметры.
+
+Каждый объект должен иметь уникальный идентификатор, чтобы избежать конфликтов с другими объектами. Параметры событий довольно часто включают уникальный идентификатор, который можно использовать.
+
+> Примечание: Использование хэша транзакции в качестве идентификатора предполагает, что никакие другие события в той же транзакции не создают объекты с этим хэшем в качестве идентификатора.
+
+#### Загрузка объектов из хранилища
+
+Если объект уже существует, его можно загрузить из хранилища следующим образом:
+
+```typescript
+let id = event.transaction.hash // или некоторым образом создается идентификатор
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+
+// Используйте объект Transfer, как и раньше
+```
+
+Поскольку объект может еще не существовать в хранилище, метод `load` возвращает значение типа `Transfer | null`. Таким образом, перед использованием значения может потребоваться проверка на наличие `null`.
+
+> Примечание: Загрузка объектов необходима только в том случае, если изменения, внесенные в мэппинг, зависят от предыдущих данных объекта. В следующем разделе описаны два способа обновления существующих объектов.
+
+#### Поиск объектов, созданных внутри блока
+
+Начиная с `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 и `@graphprotocol/graph-cli` v0.49.0 метод `loadInBlock` доступен для всех типов объектов.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- В случае, если транзакция не существует, субграф должен будет обратиться к базе данных просто для того, чтобы узнать, что объект не существует. Если автор субграфа уже знает, что объект должен быть создан в том же блоке, использование `loadInBlock` позволяет избежать этого обращения к базе данных.
+- Для некоторых субграфов эти пропущенные поиски могут существенно увеличить время индексации.
+
+```typescript
+let id = event.transaction.hash // или некоторым образом создается идентификатор
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+
+// Используйте объект Transfer, как и раньше
+```
+
+> Примечание: Если в данном блоке не создан объект, `loadInBlock` вернет `null`, даже если в хранилище есть объект с данным идентификатором.
+
+#### Поиск производных объектов
+
+Начиная с `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 и `@graphprotocol/graph-cli` v0.51.0 метод `loadRelated` доступен.
+
+Это позволяет загружать поля производных объектов из обработчика событий. Например, учитывая следующую схему:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+Следующий код загрузит объект `Token`, из которого был получен объект `Holder`:
+
+```typescript
+let holder = Holder.load('test-id')
+// Загрузите объекты токена, связанные с данным держателем
+let tokens = holder.tokens.load()
+```
+
+#### Обновление существующих объектов
+
+Существует два способа обновить существующий объект:
+
+1. Загрузите объект, например, с помощью `Transfer.load(id)`, установите свойства объекта, затем с помощью `.save()` верните его обратно в хранилище.
+2. Просто создайте объект, например, с помощью `new Transfer(id)`, установите свойства объекта, затем с помощью `.save()` сохраните его в хранилище. Если объект уже существует, изменения будут объединены с ним.
+
+Изменение свойств в большинстве случаев не вызывает затруднений благодаря сгенерированным установщикам свойств:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+Также можно сбросить свойства с помощью одной из следующих двух инструкций:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+Это работает только с необязательными свойствами, то есть свойствами, объявленными без `!` в GraphQL. Два примера: `owner: Bytes` или `amount: BigInt`.
+
+Обновление свойств массива немного сложнее, поскольку получение массива из объекта создает копию этого массива. Это означает, что после изменения массива необходимо снова точно задать его свойства. В следующем примере предполагается, что `entity` имеет поле `numbers: [BigInt!]!`.
+
+```typescript
+// Это не сработает
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// Это сработает
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Удаление объектов из хранилища
+
+В настоящее время нет способа удалить объект с помощью сгенерированных типов. Вместо этого для удаления объекта требуется передать имя типа объекта и идентификатор объекта в `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+Ethereum API предоставляет доступ к смарт-контрактам, общедоступным переменным состояния, функциям контрактов, событиям, транзакциям, блокам и кодированию/декодированию данных Ethereum.
+
+#### Поддержка типов Ethereum
+
+Как и в случае с объектами, `graph codegen` генерирует классы для всех смарт-контрактов и событий, используемых в субграфе. Для этого ABI контракта должны быть частью источника данных в манифесте субграфа. Как правило, файлы ABI хранятся в папке `abis/`.
+
+С помощью сгенерированных классов преобразования между типами Ethereum и [встроенными типами] (#built-in-types) происходят за кулисами, так что авторам субграфов не нужно беспокоиться о них.
+
+Следующий пример иллюстрирует это. С учётом схемы субграфа, такой как
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+и сигнатура события `Transfer(address,address,uint256)` на Ethereum, значения `from`, `to` и `amount` типа `address`, `address` и `uint256` преобразуются в `Address` и `BigInt`, что позволяет передавать их в свойства `Bytes!` и `BigInt!` объекта `Transfer`:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### События и данные о блоках/транзакциях
+
+События Ethereum, передаваемые обработчикам событий, такие как событие `Transfer` в предыдущих примерах, предоставляют доступ не только к параметрам события, но и к их материнской транзакции и блоку, частью которого они являются. Следующие данные могут быть получены из экземпляров `event` (эти классы являются частью модуля `ethereum` в `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Доступ к состоянию смарт-контракта
+
+Код, сгенерированный с помощью `graph codegen`, также включает классы для смарт-контрактов, используемых в субграфе. Они могут быть использованы для доступа к общедоступным переменным состояния и вызова функций контракта в текущем блоке.
+
+Распространенным шаблоном является доступ к контракту, из которого исходит событие. Это достигается с помощью следующего кода:
+
+```typescript
+// Импорт сгенерированного класса контракта и сгенерированного класса события Transfer
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Импорт созданного класса объекта
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Привязка контракта к адресу, сгенерировавшему событие
+  let contract = ERC20Contract.bind(event.address)
+
+   // Доступ к переменным состояния и функциям путем их вызова
+   пусть erc20Symbol = контракт.символ()
+}
+```
+
+`Transfer` связывается с `TransferEvent`, чтобы избежать конфликта наименований с типом объекта
+
+Пока `ERC20Contract` в Ethereum имеет общедоступную функцию только для чтения, называемую `symbol`, ее можно вызвать с помощью `.symbol()`. Для общедоступных переменных состояния автоматически создается метод с таким же именем.
+
+Любой другой контракт, который является частью субграфа, может быть импортирован из сгенерированного кода и привязан к действительному адресу.
+
+#### Обработка возвращенных вызовов
+
+Если методы Вашего контракта, доступные только для чтения, могут вернуться к предыдущему состоянию, то Вам следует решить эту проблему, вызвав сгенерированный метод контракта с префиксом `try_`.
+
+- Например, контракт Gravity предоставляет метод `gravatarToOwner`. Этот код сможет выполнить возврат в этом методе:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Примечание: Graph Node, подключенный к клиенту Geth или Infura, может обнаружить не все откаты. Если Вы полагаетесь на это, мы рекомендуем использовать Graph Node, подключенный к клиенту Parity.
+
+#### Кодирование/декодирование ABI
+
+Данные могут быть закодированы и декодированы в соответствии с форматом кодирования ABI Ethereum с использованием функций `encode` и `decode` в модуле `ethereum`.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+Для получения дополнительной информации:
+
+- [Спецификация ABI](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Кодирование/декодирование [библиотека Rust/CLI](https://github.com/rust-ethereum/ethabi)
+- Более [сложный пример] (https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Баланс адреса
+
+Баланс нативного токена адреса можно получить с помощью модуля `ethereum`. Эта функция доступна начиная с `apiVersion: 0.0.9`, которая определена `subgraph.yaml`. `getBalance()` извлекает баланс указанного адреса на конец блока, в котором инициировано событие.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // возвращает баланс в BigInt
+```
+
+#### Проверьте, является ли адрес контрактом или EOA
+
+Чтобы проверить, является ли адрес адресом смарт-контракта или внешним адресом (EOA), используйте функцию `hasCode()` из модуля `ethereum`, которая вернет `boolean`. Эта функция доступна начиная с `apiVersion: 0.0.9`, которая определена `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // возвращает ложное значение
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // возвращает ложное значение
+```
+
+### Регистрация API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+API `log` позволяет субграфам записывать информацию в стандартный вывод Graph Node, а также в Graph Explorer. Сообщения могут быть зарегистрированы с использованием различных уровней ведения лога. Для составления сообщений лога из аргумента предусмотрен синтаксис строки базового формата.
+
+API `log` включает в себя следующие функции:
+
+- `log.debug(fmt: string, args: Array<string>): void` - регистрирует сообщение об отладке.
+- `log.info (fmt: string, args: Array<string>): void` - регистрирует информационное сообщение.
+- `log.warning(fmt: string, args: Array<string>): void` - регистрирует предупреждение.
+- `log.error(fmt: string, args: Array<string>): void` - регистрирует сообщение об ошибке.
+- `log.critical(fmt: string, args: Array<string>): void` – регистрирует критическое сообщение и завершает работу субграфа.
+
+API `log` принимает строку формата и массив строковых значений. Затем он заменяет заполнители строковыми значениями из массива. Первый `{}` заполнитель заменяется первым значением в массиве, второй `{}` заполнитель заменяется вторым значением и так далее.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Регистрация одного или нескольких значений
+
+##### Регистрация одного значения
+
+В приведенном ниже примере строковое значение "A" передается в массив, чтобы стать `['A']` перед тем как будет записано в лог:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Отображает: "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Регистрация одной записи из существующего массива
+
+В приведенном ниже примере регистрируется только первое значение массива аргументов, несмотря на то, что массив содержит три значения.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Отображает : "My value is: A" (Несмотря на то, что в `log.info` передаются три значения)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Регистрация нескольких записей из существующего массива
+
+Для каждой записи в массиве arguments требуется свой собственный заполнитель `{}` в строке сообщения лога. В приведенном ниже примере в сообщении лога содержатся три заполнителя `{}`. По этой причине в `myArray` регистрируются все три значения.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Отображает : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Регистрация конкретной записи из существующего массива
+
+Чтобы отобразить определенное значение в массиве, необходимо указать индексированное значение.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Отображает : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Регистрация информации о событии
+
+В приведенном ниже примере регистрируется номер блока, хэш блока и хэш транзакции из события:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+При наличии хеша или пути IPFS чтение файла из IPFS выполняется следующим образом:
+
+```typescript
+// Поместите это в обработчик события в мэппинге
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Пути, подобные `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`,
+// которые включают файлы в директориях, также поддерживаются
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Примечание:** `pfs.cat` на данный момент не является детерминированным. Если файл не может быть получен по сети IPFS до истечения времени ожидания запроса, он вернет `null`. В связи с этим всегда стоит проверять результат на наличие `null`.
+
+С помощью `ipfs.map` можно также обрабатывать файлы большего размера в потоковом режиме. Функция ожидает, что хэш или путь к файлу IPFS, имя обратного вызова и флаги изменят его поведение:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+// Смотрите документацию по JsonValue для получения подробной информации о работе
+// со значениями JSON
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+// Обратные вызовы также могут создавать объекты
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Установите для родителя значение "parentId"
+  newitem.save()
+}
+
+// Поместите это внутри обработчика событий в мэппинге
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// В качестве альтернативы, используйте `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+Единственным поддерживаемым в настоящее время флагом является `json`, который должен быть передан в `ipfs.map`. С флагом `json` файл IPFS должен состоять из серии значений JSON, по одному значению в строке. Вызов `ipfs.map` прочитает каждую строку в файле, десериализует ее в `JSONValue` и совершит обратный вызов для каждой из них. Затем обратный вызов может использовать операции с объектами для хранения данных из `JSONValue`. Изменения объекта сохраняются только после успешного завершения обработчика, вызвавшего `ipfs.map`; в то же время они хранятся в памяти, и поэтому размер файла, который может обработать `ipfs.map`, ограничен.
+
+При успешном завершении `ipfs.map` возвращает `void`. Если какое-либо совершение обратного вызова приводит к ошибке, обработчик, вызвавший `ipfs.map`, прерывается, а субграф помечается как давший сбой.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+API `crypto` делает криптографические функции доступными для использования в мэппингах. На данный момент есть только один:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+Данные JSON могут быть разобраны с помощью `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – выполняет разбор данных JSON из массива `Bytes`, интерпретируемого как допустимая последовательность UTF-8
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – безопасная версия `json.fromBytes`, возвращает вариант ошибки, если выполнение разбора не удалось
+- `json.fromString(data: string): JSONValue` – выполняет разбор данных JSON из допустимой UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – безопасная версия `json.fromString`, возвращает вариант ошибки, если выполнение разбора не удалось
+
+Класс `JSONValue` предоставляет способ извлечения значений из произвольного документа JSON. Поскольку значениями JSON могут быть логические значения, числа, массивы и многое другое, `JSONValue` поставляется со свойством `kind` для проверки типа значения:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+Кроме того, существует способ проверить, является ли значение `null`:
+
+- `value.isNull(): boolean`
+
+Когда тип значения определен, его можно преобразовать во [встроенный тип](#built-in-types), используя один из следующих методов:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (а затем преобразовать `JSONValue` одним из 5 методов, описанных выше)
+
+### Справка по преобразованию типов
+
+| Источник(и)            | Место назначения          | Функция преобразования              |
+| ---------------------- | ------------------------- | ----------------------------------- |
+| Address                | Bytes                     | отсутствует                         |
+| Address                | String                    | s.toHexString()                     |
+| BigDecimal             | String                    | s.toString()                        |
+| BigInt                 | BigDecimal                | s.toBigDecimal()                    |
+| BigInt                 | String (hexadecimal)      | s.toHexString() или s.toHex()       |
+| BigInt                 | String (unicode)          | s.toString()                        |
+| BigInt                 | i32                       | s.toI32()                           |
+| Boolean                | Boolean                   | отсутствует                         |
+| Bytes (signed)         | BigInt                    | BigInt.fromSignedBytes(s)           |
+| Bytes (unsigned)       | BigInt                    | BigInt.fromUnsignedBytes(s)         |
+| Bytes                  | String (hexadecimal)      | s.toHexString() или s.toHex()       |
+| Bytes                  | String (unicode)          | s.toString()                        |
+| Bytes                  | String (base58)           | s.toBase58()                        |
+| Bytes                  | i32                       | s.toI32()                           |
+| Bytes                  | u32                       | s.toU32()                           |
+| Bytes                  | JSON                      | json.fromBytes(s)                   |
+| int8                   | i32                       | отсутствует                         |
+| int32                  | i32                       | отсутствует                         |
+| int32                  | BigInt                    | BigInt.fromI32(s)                   |
+| uint24                 | i32                       | отсутствует                         |
+| int64 - int256         | BigInt                    | отсутствует                         |
+| uint32 - uint256       | BigInt                    | отсутствует                         |
+| JSON                   | boolean                   | s.toBool()                          |
+| JSON                   | i64                       | s.toU64()                           |
+| JSON                   | u64                       | s.toU64()                           |
+| JSON                   | f64                       | s.toF64()                           |
+| JSON                   | BigInt                    | s.toBigInt()                        |
+| JSON                   | string                    | s.toString()                        |
+| JSON                   | Array                     | s.toArray()                         |
+| JSON                   | Object                    | s.toObject()                        |
+| String                 | Address                   | Address.fromString(s)               |
+| Bytes                  | Address                   | Address.fromBytes(s)                |
+| String                 | BigInt                    | BigInt.fromString(s)                |
+| String                 | BigDecimal                | BigDecimal.fromString(s)            |
+| String (hexadecimal)   | Bytes                     | ByteArray.fromHexString(s)          |
+| String (UTF-8)         | Bytes                     | ByteArray.fromUTF8(s)               |
+
+### Метаданные источника данных
+
+Вы можете проверить адрес контракта, сеть и контекст источника данных, который вызвал обработчик, через пространство имен `DataSource`:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Объект и DataSourceContext
+
+Базовый класс `Entity` и дочерний класс `DataSourceContext` имеют помощников для динамической установки и получения полей:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext в манифесте
+
+Раздел `context` в `dataSources` позволяет Вам определять пары ключ-значение, которые доступны в Ваших мэппингах субграфа. Доступные типы: `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List` и `BigInt`.
+
+Ниже приведен пример YAML, иллюстрирующий использование различных типов в разделе `context`:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Определяет логическое значение (`true` или `false`).
+- `String`: Определяет строковое значение.
+- `Int`: Определяет 32-разрядное целое число.
+- `Int8`: Определяет 8-разрядное целое число.
+- `BigDecimal`: Определяет десятичное число. Необходимо заключить в кавычки.
+- `Bytes`: Определяет шестнадцатеричную строку.
+- `List`: Определяет список элементов. Для каждого элемента необходимо указать его тип и данные.
+- `BigInt`: Определяет большое целочисленное значение. Необходимо заключить в кавычки из-за большого размера.
+
+Затем этот контекст становится доступным в Ваших мэппинговых файлах субграфов, что позволяет сделать субграфы более динамичными и настраиваемыми.

From 6eb263fc18f26f26377e4f2c2db7fea0c1f91963 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:47 -0500
Subject: [PATCH 0851/3820] New translations common-issues.mdx (Russian)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/ru/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/ru/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..74f717af91a4
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Распространенные проблемы с AssemblyScript
+---
+
+Существуют определенные проблемы c [AssemblyScript] (https://github.com/AssemblyScript/assemblyscript), с которыми часто приходится сталкиваться при разработке субграфа. Они различаются по сложности отладки, однако знание о них может помочь. Ниже приведен неполный перечень этих проблем:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Область видимости не наследуется [функциями замыкания](https://www.assemblyscript.org/status.html#on-closures), т.е. переменные, объявленные вне функций замыкания, не могут быть использованы. Пояснения см. в [Рекомендациях для разработчиков #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From a96cc5c2df7fb366351f29df38c41ab99206b1e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:48 -0500
Subject: [PATCH 0852/3820] New translations unit-testing-framework.mdx
 (Russian)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/ru/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/ru/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..831a626be059
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Фреймворк модульного тестирования
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Начало работы
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+Вы можете использовать Matchstick в WSL как с помощью подхода Docker, так и с помощью бинарного подхода. Поскольку WSL может быть немного сложной задачей, вот несколько советов на случай, если Вы столкнетесь с такими проблемами, как
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+или
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### Параметры CLI
+
+Это запустит все тесты в тестовой папке:
+
+```sh
+graph test
+```
+
+Это запустит тест с именем gravity.test.ts и/или все тесты внутри папки с именем gravity:
+
+```sh
+graph test gravity
+```
+
+Это запустит только конкретный тестовый файл:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Конфигурация
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Демонстрационный субграф
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Видеоуроки
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Структура тестов
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Пример:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Пример:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+или
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Примеры:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Пример:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Примеры:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Утверждения
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+Начиная с версии 0.6.0, утверждения также поддерживают настраиваемые сообщения об ошибках
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Напишите юнит-тест
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Предположим, у нас есть следующая функция-обработчик (наряду с двумя вспомогательными функциями, облегчающими нашу жизнь):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+Сначала мы должны создать тестовый файл в нашем проекте. Вот пример того, как это могло бы выглядеть:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- Мы настраиваем наше исходное состояние и добавляем один пользовательский объект Gravatar;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- Мы утверждаем состояние хранилища. Как это происходит? - Мы передаем уникальную комбинацию типа объекта и идентификатора. Затем мы проверяем конкретное поле в этом объекте и утверждаем, что оно имеет то значение, которое мы ожидаем от него получить. Мы делаем это как для исходного объекта Gravatar, который мы добавили в хранилище, так и для двух объектов Gravatar, которые добавляются при вызове функции-обработчика;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+Вот и все - мы создали наш первый тест! 👏
+
+Теперь, чтобы запустить наши тесты, Вам просто нужно запустить в корневой папке своего субграфа следующее:
+
+`graph test Gravity`
+
+И если все пойдет хорошо, Вы увидите следующее приветствие:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Распространенные сценарии тестирования
+
+### Наполнение хранилища до определенного состояния
+
+Пользователи могут наполнять хранилище известным набором объектов. Вот пример инициализации хранилища с помощью объекта Gravatar:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Вызов функции мэппинга с помощью события
+
+Пользователь может создать пользовательское событие и передать его функции мэппинга, привязанной к хранилищу:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Вызов всех мэппингов с фиксированными событиями
+
+Пользователи могут вызывать мэппинги с помощью тестовых наборов данных.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Имитация вызовов контракта
+
+Пользователи могут имитировать вызовы контракта:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+Как было продемонстрировано, для того, чтобы имитировать вызов контракта и хардкор возвращаемого значения, пользователь должен предоставить адрес контракта, имя функции, сигнатуру функции, массив аргументов и, конечно же, возвращаемое значение.
+
+Пользователи также могут имитировать возврат функций:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Имитация файлов IPFS (из matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// обратный вызов ipfs.map
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // Смотрите документацию по JsonValue для получения подробной информации о работе
+  // со значениями JSON
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Обратные вызовы также могут создавать объекты
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// функция, которая вызывает ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Подтверждение состояния хранилища
+
+Пользователи могут утверждать конечное (или промежуточное) состояние хранилища с помощью утверждающих объектов. Для этого пользователь должен указать тип объекта, конкретный идентификатор объекта, имя поля этого объекта и ожидаемое значение поля. Вот небольшой пример:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Взаимодействие с метаданными событий
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Чтение
+let logType = newGravatarEvent.logType
+
+// Запись
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Утверждение равенства переменных
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Пользователи могут утверждать, что объект отсутствует в хранилище. Функция принимает тип объекта и идентификатор. Если объект действительно находится в хранилище, тест завершится неудачей с соответствующим сообщением об ошибке. Вот краткий пример использования этой функции:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Вывод всего хранилища или отдельных его объектов (в целях отладки)
+
+С помощью этой вспомогательной функции можно вывести всё хранилище на консоль:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Ожидаемый сбой
+
+Пользователи могут ожидать сбоев тестирования, используя флаг shouldFail в функциях test():
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+Если тест помечен как shouldFail = true, но НЕ завершается неудачей, это отобразится как ошибка в логах, и тестовый блок завершится неудачей. Также, если он помечен как shouldFail = false (состояние по умолчанию), произойдет сбой тестового исполнителя.
+
+### Логирование (ведение журналов)
+
+Наличие пользовательских логов в модульных тестах - это точно то же самое, что логирование в мэппингах. Разница заключается в том, что объект лога необходимо импортировать из matchstick-as, а не из graph-ts. Вот простой пример со всеми некритическими типами логов:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Пользователи также могут имитировать критический сбой, например, так:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Логирование критических ошибок остановит выполнение тестов и все испортит. В конце концов, мы хотим быть уверены, что Ваш код не содержит критических логов при развертывании, и Вы сразу заметите, если это произойдет.
+
+### Тестирование производных полей
+
+Тестирование производных полей — это функция, которая позволяет пользователям устанавливать поле для определенного объекта и автоматически обновлять другой объект, если он извлекает одно из своих полей из первого объекта.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Тестирование динамических источников данных
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Пример ниже:
+
+Во-первых, у нас есть следующий обработчик событий (который был намеренно перепрофилирован для демонстрации искусственного искажения источника данных):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+Во-вторых, у нас есть тест, использующий один из методов в пространстве имён dataSourceMock для установки нового возвращаемого значения для всех функций dataSource:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Обратите внимание, что функция DataSource Mock.resetValues() вызывается в конце. Это происходит потому, что значения запоминаются при их изменении, и их необходимо сбросить, если Вы хотите вернуться к значениям по умолчанию.
+
+### Тестирование создания источника динамических данных
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Пример обработчика
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Пример теста
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Тестовое покрытие
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Предварительные требования
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Экспортируйте свои обработчики
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Применение
+
+После того как всё это будет настроено, чтобы запустить инструмент тестового покрытия, просто запустите:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+При этом запустится инструмент покрытия, и в терминале Вы должны увидеть что-то вроде этого:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Продолжительность выполнения теста в выходных данных лога
+
+Выходные данные лога включают в себя продолжительность тестового запуска. Вот пример:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Типичные ошибки компилятора
+
+> Критично: Не удалось создать WasmInstance из допустимого модуля с контекстом: неизвестный импорт: wasi_snapshot_preview1::fd_write не определен
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Дополнительные ресурсы
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Обратная связь
+
+Если у Вас есть какие-либо вопросы, отзывы, пожелания по функциям или Вы просто хотите связаться с нами, лучшим местом будет Graph Discord, где у нас есть выделенный канал для Matchstick под названием 🔥| unit-testing.

From 12768bf9ea50c7d8c3f359530e94517bf75d78f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:49 -0500
Subject: [PATCH 0853/3820] New translations transferring-a-subgraph.mdx
 (Russian)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/ru/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/ru/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..c57a0263068e
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Субграфы, опубликованные в децентрализованной сети, имеют NFT, сминченный по адресу, опубликовавшему субграф. NFT основан на стандарте ERC721, который облегчает переводы между аккаунтами в The Graph Network.
+
+## Напоминания
+
+- Тот, кто владеет NFT, управляет субграфом.
+- Если владелец решит продать или передать NFT, он больше не сможет редактировать или обновлять этот субграф в сети.
+- Вы можете легко перенести управление субграфом на мультиподпись.
+- Участник сообщества может создать субграф от имени DAO.
+
+## Просмотр Вашего субграфа как NFT
+
+Чтобы просмотреть свой субграф как NFT, Вы можете посетить маркетплейс NFT, например, **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Или воспользоваться программой для поиска кошелька, например, **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Пошаговое руководство
+
+Чтобы передать право собственности на субграф, выполните следующие действия:
+
+1. Используйте встроенный в Subgraph Studio пользовательский интерфейс:
+
+   ![Передача права собственности на субграф](/image/subgraph-ownership-transfer-1.png)
+
+2. Выберите адрес, на который хотели бы передать субграф:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+При желании Вы также можете использовать встроенный пользовательский интерфейс таких маркетплейсов NFT, как OpenSea:
+
+![Передача права собственности на субграф с маркетплейса NFT](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 0c576934c49390cf7873eac6d2329835b608909e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:51 -0500
Subject: [PATCH 0854/3820] New translations graphql-api.mdx (Russian)

---
 .../ru/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/ru/subgraphs/querying/graphql-api.mdx b/website/pages/ru/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..a47052ee06bb
--- /dev/null
+++ b/website/pages/ru/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: API GraphQL
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Примеры
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Сортировка
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Пример
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Пример сортировки вложенных объектов
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Пагинация
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Запрос первых 10 токенов:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Фильтрация
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Пример фильтрации диапазона
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Пример фильтрации блока
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+Это может быть полезно, если Вы хотите получить только объекты, которые изменились, например, с момента последнего опроса. Или, в качестве альтернативы, может быть полезно исследовать или отладить изменнения объектов в Вашем субграфе (в сочетании с фильтрацией блоков Вы можете изолировать только объекты, которые изменились в определенном блоке).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Пример фильтрации вложенных объектов
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+Это может быть полезно, если Вы хотите получать только объекты, у которых объекты дочернего уровня удовлетворяют заданным условиям.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Логические операторы
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### Все фильтры
+
+Полный список суффиксов параметров:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Запросы на Time-travel
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Пример
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Пример
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Полнотекстовые поисковые запросы
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Полнотекстовые поисковые операторы:
+
+| Символ | Оператор    | Описание                                                                                                                                       |
+| ------ | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`    | `And`       | Для объединения нескольких условий поиска в фильтр для объектов, которые включают все указанные условия                                        |
+| |      | `Or`        | Запросы с несколькими условиями поиска, разделенные оператором or, вернут все объекты, которые соответствуют любому из предоставленных условий |
+| `<->`  | `Follow by` | Укажите расстояние между двумя словами.                                                                                                        |
+| `:*`   | `Prefix`    | Используйте поисковый запрос по префиксу, чтобы найти слова с соответствующим префиксом (необходимо 2 символа)                                 |
+
+#### Примеры
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Комбинируйте полнотекстовые операторы, чтобы создавать более сложные фильтры. С оператором поиска по префиксу в сочетании с запросом «follow by» будут найдены все объекты блога со словами, начинающимися с «lou», за которыми следует «music».
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Валидация
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Схема
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Объекты
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Метаданные субграфа
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+Если предоставлен блок, метаданные относятся к этому блоку, в противном случае используется последний проиндексированный блок. Если предоставляется блок, он должен быть после начального блока субграфа и меньше или равен последнему проиндексированному блоку.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: хэш блока
+- number: номер блока
+- timestamp: временная метка блока, если она доступна (в настоящее время доступна только для субграфов, индексирующих сети EVM)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 2508adc66b95a797deb763095d6908cadb262f8a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:52 -0500
Subject: [PATCH 0855/3820] New translations python.mdx (Russian)

---
 .../pages/ru/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/querying/python.mdx

diff --git a/website/pages/ru/subgraphs/querying/python.mdx b/website/pages/ru/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..fba75504ef62
--- /dev/null
+++ b/website/pages/ru/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Начало работы
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From d23755164d9b79ed048f7df73bf452090fd41bf2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:53 -0500
Subject: [PATCH 0856/3820] New translations triggers.mdx (Russian)

---
 website/pages/ru/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/ru/substreams/sps/triggers.mdx

diff --git a/website/pages/ru/substreams/sps/triggers.mdx b/website/pages/ru/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/ru/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 5f7e22fbf1631a9d45ed1fb09d76f422ef2dc97c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:54 -0500
Subject: [PATCH 0857/3820] New translations overview.mdx (Swedish)

---
 website/pages/sv/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/sv/indexing/overview.mdx

diff --git a/website/pages/sv/indexing/overview.mdx b/website/pages/sv/indexing/overview.mdx
new file mode 100644
index 000000000000..909be6a56069
--- /dev/null
+++ b/website/pages/sv/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexerare är nodoperatörer i The Graph Network som satsar Graph Tokens (GRT) för att tillhandahålla indexering och frågebehandlingstjänster. Indexerare tjänar avgifter för frågor och indexering samt får frågebetalningar som återbetalas enligt en exponentiell återbetalningsfunktion.
+
+GRT som satsas i protokollet är föremål för en tiningperiod och kan drabbas av strykning om indexerare är skadliga och tillhandahåller felaktiga data till applikationer eller om de indexerar felaktigt. Indexerare tjänar också belöningar för delegerat satsning från Delegater, för att bidra till nätverket.
+
+Indexerare väljer subgrafer att indexera baserat på subgrafens kuratersignal, där Curators satsar GRT för att ange vilka subgrafer som är av hög kvalitet och bör prioriteras. Konsumenter (t.ex. applikationer) kan också ställa in parametrar för vilka indexerare som behandlar frågor för deras subgrafer och ange preferenser för pris på frågebetalning.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### Vad är det minsta satsade belopp som krävs för att vara en indexerare i nätverket?
+
+Det minsta beloppet för en indexerare är för närvarande inställt på 100 000 GRT.
+
+### Vad är intäktskällorna för en indexerare?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### Hur fördelas indexeringsbelöningar?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### Vad är ett bevis på indexering (POI)?
+
+POI:er används i nätverket för att verifiera att en indexerare indexerar de subgrafer de har tilldelat sig. Ett POI för det första blocket i den nuvarande epoken måste lämnas in när en tilldelning stängs för att vara berättigad till indexeringsbelöningar. Ett POI för ett block är en digest för alla entity store-transaktioner för en specifik subgrafdepå fram till och med det blocket.
+
+### När fördelas indexeringsbelöningar?
+
+Tilldelningar ackumulerar kontinuerligt belöningar medan de är aktiva och tilldelade inom 28 epoker. Belöningarna samlas in av indexerarna och distribueras när deras tilldelningar stängs. Det sker antingen manuellt, när indexeraren vill tvinga dem att stängas, eller efter 28 epoker kan en Delegat stänga tilldelningen för indexeraren, men detta resulterar inte i några belöningar. 28 epoker är den maximala tilldelningens livslängd (för närvarande varar en epok i cirka ~24h).
+
+### Kan väntande indexeringsbelöningar övervakas?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Många av gemenskapens egentillverkade instrument inkluderar värden för väntande belöningar och de kan enkelt kontrolleras manuellt genom att följa dessa steg:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### Vad är tvister och var kan jag se dem?
+
+Indexerares frågor och tilldelningar kan båda bli föremål för tvister på The Graph under tvisteperioden. Tvisteperioden varierar beroende på typen av tvist. Frågor/erkännanden har en tvistefönster på 7 epocher, medan tilldelningar har 56 epocher. Efter att dessa perioder har passerat kan inga tvister öppnas mot vare sig tilldelningar eller frågor. När en tvist öppnas krävs en insättning av minst 10 000 GRT av Fishermen, som kommer att vara låsta tills tvisten är avslutad och en resolution har lämnats. Fishermen är nätverksdeltagare som öppnar tvister.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- Om tvisten avvisas kommer den GRT som satts in av Fishermen att brännas, och den ifrågasatta Indexern kommer inte att bli straffad.
+- Om tvisten avgörs som oavgjord kommer Fishermens insättning att återbetalas, och den ifrågasatta Indexern kommer inte att bli straffad.
+- Om tvisten godkänns kommer den GRT som satts in av Fishermen att återbetalas, den ifrågasatta Indexern kommer att bli straffad, och Fishermen kommer att tjäna 50% av den straffade GRT.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### Vad är återbetalningar av frågeavgifter och när distribueras de?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+När en tilldelning har avslutats är återbetalningarna tillgängliga för Indexern att hämta. Vid hämtning distribueras frågeavgiftsåterbetalningarna till Indexern och deras Delegatorer baserat på frågeavgiftsminskningen och den exponentiella rabattfunktionen.
+
+### Vad är frågeavgiftsminskning och minskning av indexeringsbelöning?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### Hur vet Indexers vilka subgrafer de ska indexera?
+
+Indexers kan skilja sig åt genom att tillämpa avancerade tekniker för att fatta beslut om indexering av subgrafer, men för att ge en allmän idé kommer vi att diskutera flera viktiga metoder som används för att utvärdera subgrafer i nätverket:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### Vilka är de tekniska kraven?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Konfiguration | Postgres<br />(CPU:er) | Postgres<br />(minne i GB) | Postgres<br />(disk i TB) | VM:er<br />(CPU:er) | VM:er<br />(minne i GB) |
+| ------------- | :--------------------: | :------------------------: | :-----------------------: | :-----------------: | :---------------------: |
+| Liten         |            4           |              8             |             1             |          4          |            16           |
+| Standard      |            8           |             30             |             1             |          12         |            48           |
+| Medium        |           16           |             64             |             2             |          32         |            64           |
+| Stor          |           72           |             468            |            3,5            |          48         |           184           |
+
+### Vilka grundläggande säkerhetsåtgärder bör en Indexer vidta?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastruktur
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Observera: För att stödja smidig skalning rekommenderas det att fråge- och indexeringsbekymmer separeras mellan olika uppsättningar noder: frågenoder och indexnoder.
+
+### Översikt över portar
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graf Node
+
+| Port | Syfte                                                | Vägar                                          | CLI-argument       | Miljövariabel |
+| ---- | ---------------------------------------------------- | ---------------------------------------------- | ------------------ | ------------- |
+| 8000 | GraphQL HTTP-server<br />(för subgraf-förfrågningar) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -             |
+| 8001 | GraphQL WS<br />(för subgraf-prenumerationer)        | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -             |
+| 8020 | JSON-RPC<br />(för hantering av distributioner)      | /                                              | \--admin-port      | -             |
+| 8030 | Subgrafindexeringsstatus-API                         | /graphql                                       | \--index-node-port | -             |
+| 8040 | Prometheus-metrar                                    | /metrics                                       | \--metrics-port    | -             |
+
+#### Indexertjänst
+
+| Port | Syfte                                                        | Vägar                                                       | CLI-argument    | Miljövariabel          |
+| ---- | ------------------------------------------------------------ | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP-server<br />(för betalda subgraf-förfrågningar) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus-metrar                                            | /metrics                                                    | \--metrics-port | -                      |
+
+#### Indexeragent
+
+| Port | Purpose                | Vägar  | CLI Argument               | Environment Variable                    |
+| ---- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | Indexerhanterings-API  | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Konfigurera serverinfrastruktur med Terraform på Google Cloud
+
+> Obs: Indexers kan alternativt använda AWS, Microsoft Azure eller Alibaba.
+
+#### Installera förutsättningar
+
+- SDK för Google Cloud
+- Kubectl kommandoradsverktyg
+- Terraform
+
+#### Skapa ett Google Cloud-projekt
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Autentisera dig med Google Cloud och skapa ett nytt projekt.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Använd faktureringssidan i Google Cloud Console för att aktivera fakturering för det nya projektet.
+
+- Skapa en Google Cloud-konfiguration.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Aktivera nödvändiga API:er för Google Cloud.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Skapa ett servicekonto.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Aktivera peering mellan databasen och Kubernetes-klustret som kommer att skapas i nästa steg.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Skapa en minimal konfigurationsfil för terraformen (uppdatera vid behov).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Använd Terraform för att skapa infrastruktur
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Kör följande kommandon för att skapa infrastrukturen.
+
+```sh
+# Installera nödvändiga plugins
+terraform init
+
+# Se plan för resurser som ska skapas
+terraform plan
+
+# Skapa resurserna (räkna med att det tar upp till 30 minuter)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Skapa Kubernetes-komponenter för indexeraren
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graf Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Komma igång från källkoden
+
+#### Installera förutsättningar
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Konfiguration
+
+1. Starta en PostgreSQL-databasserver
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Nu när alla beroenden är konfigurerade startar du Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Komma igång med Docker
+
+#### Förutsättningar
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Konfiguration
+
+1. Klona Graph Node och navigera till Docker-katalogen:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Starta en lokal Graph Node som kommer att ansluta till din Ethereum-ändpunkt:
+
+```sh
+docker-compose up
+```
+
+### Indexerkomponenter
+
+För att framgångsrikt delta i nätverket krävs nästan konstant övervakning och interaktion, så vi har byggt en uppsättning Typescript-applikationer för att underlätta en Indexers nätverksdeltagande. Det finns tre Indexer-komponenter:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Komma igång
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### Från NPM-paket
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI är ett plugin för Graph CLI, så båda måste installeras:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexeringstjänst
+graph-indexer-service start ...
+
+# Indexerare agent
+graph-indexer-agent start ...
+
+# CLI för indexerare
+#Vidarebefordra porten till din agent-pod om du använder Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### Från källa
+
+```sh
+# Från Repos rotkatalog
+yarn
+
+# Indexeringstjänst
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexerare agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Använda docker
+
+- Hämta bilder från registret
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Eller skapa bilder lokalt från källkod
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Kör komponenterna
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Användning av K8s och Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Användning
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexeragent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexeringstjänst
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Indexerhantering med Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Användning
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Indexeringsregler
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Datamodell:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Exempel på användning av indexeringsregel:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### CLI tail-åtgärder
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Åtgärd läggs till i kön av tredjeparts-optimeringsverktyget eller indexer-cli-användaren
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- Indexer kan övervaka åtgärds kön för att se en historia över åtgärdsutförande och om det behövs godkänna om och uppdatera åtgärdsobjekt om de misslyckades med utförande. Åtgärds kön ger en historia över alla köade och tagna åtgärder.
+
+Datamodell:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Exempel på användning från källa:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Observera att åtgärdstyper som stöds för allokeringshantering har olika krav på indata:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - obligatoriska åtgärdsparametrar:
+    - deploymentID
+    - belopp
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - obligatoriska åtgärdsparametrar:
+    - allocationID
+    - deploymentID
+  - valfria åtgärdsparametrar:
+    - poi
+    - force (tvingar användning av den angivna POI även om den inte matchar det som grafnoden tillhandahåller)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - obligatoriska åtgärdsparametrar:
+    - allocationID
+    - deploymentID
+    - belopp
+  - valfria åtgärdsparametrar:
+    - poi
+    - force (tvingar användning av den angivna POI även om den inte matchar det som grafnoden tillhandahåller)
+
+#### Kostnadsmodeller
+
+Kostnadsmodeller tillhandahåller dynamisk prissättning för frågor baserat på marknaden och frågans egenskaper. Indexer Service delar en kostnadsmodell med gatewayerna för varje subgraph för vilka de avser att svara på frågor. Gatewayerna använder i sin tur kostnadsmodellen för att fatta beslut om indexeringsval per fråga och för att förhandla om betalning med valda indexers.
+
+#### Agora
+
+Agora-språket ger ett flexibelt format för deklaration av kostnadsmodeller för frågor. En Agora-prismodell är en sekvens av uttalanden som utförs i ordning för varje toppnivåfråga i en GraphQL-fråga. För varje toppnivåfråga avgör det första uttalandet som matchar den priset för den frågan.
+
+Ett uttalande består av en predikat, som används för att matcha GraphQL-frågor, och ett kostnadsuttryck som när det utvärderas ger en kostnad i decimal GRT. Värden i den namngivna argumentpositionen i en fråga kan fångas i predikatet och användas i uttrycket. Globala variabler kan också sättas och ersättas för platshållare i ett uttryck.
+
+Exempel kostnadsmodell:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Exempel på kostnadskalkyl enligt ovanstående modell:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Tillämpning av kostnadsmodellen
+
+Kostnadsmodeller tillämpas via Indexer CLI, som skickar dem till Indexer Management API för Indexer agent för lagring i databasen. Indexer Service kommer sedan att hämta dem och servera kostnadsmodellerna till gatewayerna när de begär dem.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interagera med nätverket
+
+### Satsa i protokollet
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Godkänn tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Satsa tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### En allokations livscykel
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From bd37ffc4303dbeb72ca67c61c6e4cded5bd5b516 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:55 -0500
Subject: [PATCH 0858/3820] New translations tap.mdx (Swedish)

---
 website/pages/sv/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/sv/indexing/tap.mdx

diff --git a/website/pages/sv/indexing/tap.mdx b/website/pages/sv/indexing/tap.mdx
new file mode 100644
index 000000000000..d69cb7b5bc91
--- /dev/null
+++ b/website/pages/sv/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Översikt
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Krav
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Noteringar:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From 9fd8ff11f89794ba3ab65d1b96587dee177b2e7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:56 -0500
Subject: [PATCH 0859/3820] New translations graph-node.mdx (Swedish)

---
 .../pages/sv/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/sv/indexing/tooling/graph-node.mdx

diff --git a/website/pages/sv/indexing/tooling/graph-node.mdx b/website/pages/sv/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..fa2cb452bed9
--- /dev/null
+++ b/website/pages/sv/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graf Node
+---
+
+Graf Node är komponenten som indexerar subgraffar och gör den resulterande datan tillgänglig för förfrågan via en GraphQL API. Som sådan är den central för indexeringsstacken, och korrekt drift av Graph Node är avgörande för att driva en framgångsrik indexerare.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graf Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL-databas
+
+Huvudlagret för Graph Node, här lagras subgrafdata, liksom metadata om subgraffar och nätverksdata som är oberoende av subgraffar, som blockcache och eth_call-cache.
+
+### Nätverkskunder
+
+För att indexera ett nätverk behöver Graf Node åtkomst till en nätverksklient via ett EVM-kompatibelt JSON-RPC API. Denna RPC kan ansluta till en enda klient eller så kan det vara en mer komplex konfiguration som lastbalanserar över flera.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS-noder
+
+Metadata för distribution av subgraffar lagras på IPFS-nätverket. Graf Node har främst åtkomst till IPFS-noden under distributionen av subgraffar för att hämta subgrafens manifest och alla länkade filer. Nätverksindexerare behöver inte värd sin egen IPFS-nod. En IPFS-nod för nätverket är värd på https://ipfs.network.thegraph.com.
+
+### Prometheus server för mätvärden
+
+För att möjliggöra övervakning och rapportering kan Graf Node valfritt logga metrik till en Prometheus-metrisk server.
+
+### Komma igång från källkoden
+
+#### Installera förutsättningar
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Konfiguration
+
+1. Starta en PostgreSQL-databasserver
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Nu när alla beroenden är konfigurerade startar du Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Komma igång med Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Portar
+
+När Graph Node är igång exponerar den följande portar:
+
+| Port | Syfte                                                | Vägar                                          | CLI-argument       | Miljövariabel |
+| ---- | ---------------------------------------------------- | ---------------------------------------------- | ------------------ | ------------- |
+| 8000 | GraphQL HTTP-server<br />(för subgraf-förfrågningar) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -             |
+| 8001 | GraphQL WS<br />(för subgraf-prenumerationer)        | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -             |
+| 8020 | JSON-RPC<br />(för hantering av distributioner)      | /                                              | \--admin-port      | -             |
+| 8030 | Subgrafindexeringsstatus-API                         | /graphql                                       | \--index-node-port | -             |
+| 8040 | Prometheus-metrar                                    | /metrics                                       | \--metrics-port    | -             |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Avancerad konfiguration av Graf Node
+
+På sitt enklaste sätt kan Graph Node användas med en enda instans av Graph Node, en enda PostgreSQL-databas, en IPFS-nod och nätverksklienter som krävs av de subgrafer som ska indexeras.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> När du använder en konfigurationsfil är det inte möjligt att använda alternativen --postgres-url, --postgres-secondary-hosts och --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Flera Grafnoder
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Observera att flera Graph Nodes alla kan konfigureras att använda samma databas, som i sig kan skalas horisontellt via sharding.
+
+#### Regler för utplacering
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Exempel på konfiguration av deployeringsregler:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Dedikerade frågenoder
+
+Noder kan konfigureras för att uttryckligen vara frågenoder genom att inkludera följande i konfigurationsfilen:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Alla noder vars --node-id matchar reguljärt uttryck kommer att konfigureras för att endast svara på förfrågningar.
+
+#### Skalning av databas via sharding
+
+För de flesta användningsfall är en enda Postgres-databas tillräcklig för att stödja en graph-node-instans. När en graph-node-instans växer utöver en enda Postgres-databas är det möjligt att dela upp lagringen av graph-node-data över flera Postgres-databaser. Alla databaser tillsammans bildar lagringsutrymmet för graph-node-instansen. Varje individuell databas kallas en shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding blir användbart när din befintliga databas inte kan hålla jämna steg med belastningen som Graph Node sätter på den och när det inte längre är möjligt att öka databasens storlek.
+
+> Det är generellt sett bättre att göra en enda databas så stor som möjligt innan man börjar med shards. Ett undantag är när frågetrafiken är mycket ojämnt fördelad mellan subgrafer; i dessa situationer kan det hjälpa dramatiskt om högvolymsubgraferna hålls i en shard och allt annat i en annan, eftersom den konfigurationen gör det mer troligt att data för högvolymsubgraferna stannar i databasens interna cache och inte ersätts av data som inte behövs lika mycket från lågvolymsubgrafer.
+
+När det gäller att konfigurera anslutningar, börja med max_connections i postgresql.conf som är inställt på 400 (eller kanske till och med 200) och titta på Prometheus-metrarna store_connection_wait_time_ms och store_connection_checkout_count. Märkbara väntetider (något över 5 ms) är en indikation på att det finns för få anslutningar tillgängliga; höga väntetider beror också på att databasen är mycket upptagen (som hög CPU-belastning). Om databasen verkar annars stabil, indikerar höga väntetider att antalet anslutningar behöver ökas. I konfigurationen är det en övre gräns för hur många anslutningar varje graph-node-instans kan använda, och Graph Node kommer inte att hålla anslutningar öppna om det inte behöver dem.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Intag av dedikerade block
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Stöd för flera nätverk
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Flera nätverk
+- Flera leverantörer per nätverk (detta kan göra det möjligt att dela upp belastningen mellan leverantörer, och kan också möjliggöra konfiguration av fullständiga noder samt arkivnoder, där Graph Node föredrar billigare leverantörer om en viss arbetsbelastning tillåter det).
+- Ytterligare information om leverantören, t. ex. funktioner, autentisering och typ av leverantör (för stöd för experimentell Firehose)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Miljö variabler
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Kontinuerlig driftsättning
+
+Användare som driver en skalad indexering med avancerad konfiguration kan dra nytta av att hantera sina Graph Nodes med Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Hantera Graf Noder
+
+Med en körande Graph Node (eller Graph Nodes!) är utmaningen sedan att hantera distribuerade subgrafer över dessa noder. Graph Node erbjuder en rad verktyg för att hjälpa till med hanteringen av subgrafer.
+
+#### Loggning
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node tillhandahåller metrikerna via Prometheus-endpunkt på port 8040 som standard. Grafana kan sedan användas för att visualisera dessa metriker.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Arbeta med undergrafer
+
+#### Indexerings status API
+
+Tillgänglig som standard på port 8030/graphql, exponerar indexeringstatus-API: en en rad metoder för att kontrollera indexeringstatus för olika subgrafer, kontrollera bevis för indexering, inspektera subgrafegenskaper och mer.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Prestanda för indexering
+
+Det finns tre separata delar av indexeringsprocessen:
+
+- Hämta intressanta händelser från leverantören
+- Bearbeta händelser i rätt ordning med lämpliga hanterare (detta kan innebära att kedjan anropas för status och att data hämtas från lagret)
+- Skriva de resulterande data till butiken
+
+Dessa stadier är pipelinerade (det vill säga de kan utföras parallellt), men de är beroende av varandra. När subgrafer är långsamma att indexera beror orsaken på den specifika subgrafgen.
+
+Vanliga orsaker till indexeringslångsamhet:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- En stor mängd butiksinteraktion under exekvering
+- En stor mängd data att spara i butiken
+- Ett stort antal evenemang att bearbeta
+- Långsam databasanslutningstid, för överbelastade noder
+- Leverantören själv faller bakom kedjehuvudet
+- Långsamhet vid hämtning av nya kvitton från leverantören vid kedjehuvudet
+
+Subgrafindexeringsmetriker kan hjälpa till att diagnostisera grunden till indexeringens långsamhet. I vissa fall ligger problemet med subgrafgenen själv, men i andra fall kan förbättrade nätverksleverantörer, minskad databaskonflikt och andra konfigurationsförbättringar markant förbättra indexeringens prestanda.
+
+#### Undergrafer som misslyckats
+
+Under indexering kan subgrafer misslyckas om de stöter på data som är oväntad, om någon komponent inte fungerar som förväntat eller om det finns något fel i händelsehanterare eller konfiguration. Det finns två allmänna typer av misslyckande:
+
+- Deterministiska fel: detta är fel som inte kommer att lösas med retries
+- Icke-deterministiska fel: dessa kan bero på problem med leverantören eller något oväntat Graph Node-fel. När ett icke-deterministiskt fel inträffar kommer Graph Node att försöka igen med de felande hanterarna och backa över tid.
+
+I vissa fall kan ett misslyckande vara lösbart av indexören (till exempel om felet beror på att det inte finns rätt typ av leverantör, kommer att tillåta indexering att fortsätta om den nödvändiga leverantören läggs till). Men i andra fall krävs en ändring i subgrafkoden.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Blockera och anropa cache
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+Om en blockcache-inkonsekvens misstänks, som att en tx-kvitto saknar händelse:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. Om blocket matchar leverantören kan problemet felsökas direkt mot leverantören.
+
+#### Fråga frågor och fel
+
+När en subgraf har indexeras kan indexörer förvänta sig att servera frågor via subgrafens dedikerade frågendpunkt. Om indexören hoppas på att betjäna en betydande mängd frågor rekommenderas en dedikerad frågenod, och vid mycket höga frågevolymer kan indexörer vilja konfigurera replikskivor så att frågor inte påverkar indexeringsprocessen.
+
+Men även med en dedikerad frågenod och repliker kan vissa frågor ta lång tid att utföra, och i vissa fall öka minnesanvändningen och negativt påverka frågetiden för andra användare.
+
+Det finns inte en "silverkula", men en rad verktyg för att förebygga, diagnostisera och hantera långsamma frågor.
+
+##### Fråge cachning
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analyserar frågor
+
+Problematiska frågor dyker oftast upp på ett av två sätt. I vissa fall rapporterar användare själva att en viss fråga är långsam. I det fallet är utmaningen att diagnostisera orsaken till långsamheten - om det är ett generellt problem eller specifikt för den subgraf eller fråga. Och naturligtvis att lösa det om det är möjligt.
+
+I andra fall kan utlösaren vara hög minnesanvändning på en frågenod, i vilket fall utmaningen först är att identifiera frågan som orsakar problemet.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Med en långsam fråga har indexörer några alternativ. Självklart kan de ändra sin kostnadsmodell för att kraftigt öka kostnaden för att skicka den problematiska frågan. Detta kan resultera i att frekvensen av den frågan minskar. Men det löser ofta inte grunden till problemet.
+
+##### Kontoliknande optimering
+
+Databastabeller som lagrar enheter verkar generellt komma i två varianter: 'transaktionsliknande', där enheter, när de väl är skapade, aldrig uppdateras, dvs. de lagrar något liknande en lista över finansiella transaktioner, och 'konto-liknande', där enheter uppdateras mycket ofta, dvs. de lagrar något som finansiella konton som ändras varje gång en transaktion registreras. Tabeller med konto-liknande tabeller karakteriseras av att de innehåller ett stort antal enhetsversioner, men relativt få distinkta enheter. Ofta är antalet distinkta enheter i sådana tabeller 1% av det totala antalet rader (enhetsversioner)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Ta bort undergrafer
+
+> Detta är ny funktionalitet, som kommer att vara tillgänglig i Graf Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 4a7fd0d33dbdce760619727c56d17cfb4bbabe65 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:57 -0500
Subject: [PATCH 0860/3820] New translations advanced.mdx (Swedish)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/sv/subgraphs/developing/creating/advanced.mdx b/website/pages/sv/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..b23b5a9bb7a6
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Översikt
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Icke dödliga fel
+
+Indexeringsfel på redan synkroniserade delgrafer kommer, som standard, att få delgrafen att misslyckas och sluta synkronisera. Delgrafer kan istället konfigureras för att fortsätta synkroniseringen i närvaro av fel, genom att ignorera ändringarna som orsakades av hanteraren som provocerade felet. Det ger delgrafsförfattare tid att korrigera sina delgrafer medan förfrågningar fortsätter att behandlas mot det senaste blocket, även om resultaten kan vara inkonsekventa på grund av felet som orsakade felet. Observera att vissa fel alltid är dödliga. För att vara icke-dödliga måste felet vara känt för att vara deterministiskt.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Aktivering av icke-dödliga fel kräver att följande funktionsflagga sätts i delgrafens manifest:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+Filbaserade datakällor är en ny delgrafsfunktion för att få tillgång till data utanför kedjan under indexering på ett robust, utökat sätt. Filbaserade datakällor stödjer hämtning av filer från IPFS och från Arweave.
+
+> Detta lägger också grunden för deterministisk indexering av data utanför kedjan, samt möjligheten att introducera godtycklig data som hämtas via HTTP.
+
+### Översikt
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Uppgraderingsguide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Lägg till en ny entitetstyp som kommer att uppdateras när filer hittas
+
+Filbaserade datakällor kan inte komma åt eller uppdatera kedjebaserade entiteter, utan måste uppdatera filspecifika entiteter.
+
+Detta kan innebära att fält från befintliga entiteter separeras i separata entiteter som är kopplade ihop.
+
+Ursprunglig kombinerad entitet:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+Ny, delad enhet:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+Om relationen är 1:1 mellan föräldraentiteten och den resulterande filbaserade datakälla entiteten är det enklaste mönstret att länka föräldraentiteten till en resulterande filbaserad entitet genom att använda IPFS CID som söknyckel. Kontakta oss på Discord om du har svårt att modellera dina nya filbaserade entiteter!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+Detta är datakällan som skapas när en intressant fil identifieras.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Skapa en ny hanterare för att bearbeta filer
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Exempel på hanterare:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Skapa filbaserade datakällor vid behov
+
+Nu kan du skapa filbaserade datakällor under utförandet av kedjebaserade hanterare:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Exempel:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from "../generated/templates";
+
+const ipfshash = "QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm";
+//Denna exempelkod är för en undergraf för kryptosamverkan. Ovanstående ipfs-hash är en katalog med tokenmetadata för alla kryptosamverkande NFT:er.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString());
+  if (!token) {
+    token = new Token(event.params.tokenId.toString());
+    token.tokenID = event.params.tokenId;
+
+    token.tokenURI = "/" + event.params.tokenId.toString() + ".json";
+    const tokenIpfsHash = ipfshash + token.tokenURI;
+    //Detta skapar en sökväg till metadata för en enskild Crypto coven NFT. Den konkaterar katalogen med "/" + filnamn + ".json"
+
+    token.ipfsURI = tokenIpfsHash;
+
+    TokenMetadataTemplate.create(tokenIpfsHash);
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp;
+  token.owner = event.params.to.toHexString();
+  token.save();
+}
+```
+
+Detta kommer att skapa en ny filbaserad datakälla som kommer att övervaka Graph Nodes konfigurerade IPFS- eller Arweave-slutpunkt och försöka igen om den inte hittas. När filen hittas kommer filbaserad datakälla hanteraren att köras.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Grattis, du använder filbaserade datakällor!
+
+#### Distribuera dina delgrafer
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Begränsningar
+
+Filbaserade datakällahanterare och entiteter är isolerade från andra delgrafentiteter, vilket säkerställer att de är deterministiska när de körs och att ingen förorening av kedjebaserade datakällor sker. För att vara specifik:
+
+- Entiteter skapade av Filbaserade datakällor är oföränderliga och kan inte uppdateras
+- Filbaserade datakällahanterare kan inte komma åt entiteter från andra filbaserade datakällor
+- Entiteter associerade med filbaserade datakällor kan inte nås av kedjebaserade hanterare
+
+> Även om denna begränsning inte bör vara problematisk för de flesta användningsfall kan den införa komplexitet för vissa. Var god kontakta oss via Discord om du har problem med att modellera din data baserad på fil i en delgraf!
+
+Dessutom är det inte möjligt att skapa datakällor från en filbaserad datakälla, vare sig det är en datakälla på kedjan eller en annan filbaserad datakälla. Denna begränsning kan komma att hävas i framtiden.
+
+#### Bästa praxis
+
+Om du länkar NFT-metadata till motsvarande token, använd metadata IPFS-hash för att referera till en Metadata-entitet från Token-entiteten. Spara Metadata-entiteten med IPFS-hash som ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> Vi arbetar med att förbättra rekommendationen ovan så att förfrågningar endast returnerar den "senaste" versionen
+
+#### Kända problem
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Exempel
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### Referenser
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Ympning på befintliga delgrafer
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Eftersom ympning kopierar data istället för att indexera basdata går det mycket snabbare att få delgrafen till det önskade blocket än att indexera från början, även om den initiala datorkopieringen fortfarande kan ta flera timmar för mycket stora delgrafer. Medan den ympade delgrafen initialiseras kommer Graph Node att logga information om de entitetstyper som redan har kopierats.
+
+Den ympade subgrafen kan använda ett GraphQL-schema som inte är identiskt med det i bas subgrafen, utan bara är kompatibelt med det. Det måste vara ett giltigt subgraf schema i sig, men kan avvika från bas undergrafens schema på följande sätt:
+
+- Den lägger till eller tar bort entitetstyper
+- Det tar bort attribut från entitetstyper
+- Det tar bort attribut från entitetstyper
+- Det förvandlar icke-nullbara attribut till nullbara attribut
+- Det lägger till värden till enums
+- Den lägger till eller tar bort gränssnitt
+- Det ändrar för vilka entitetstyper ett gränssnitt implementeras
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From a9c25aa739c12d6b471e18ace832c8b3883ca29a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:58 -0500
Subject: [PATCH 0861/3820] New translations api.mdx (Swedish)

---
 .../developing/creating/graph-ts/api.mdx      | 900 ++++++++++++++++++
 1 file changed, 900 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/sv/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/sv/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..b2431a839946
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,900 @@
+---
+title: API för AssemblyScript
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API-referens
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- Primitiver på låg nivå för att översätta mellan olika typsystem som Ethereum, JSON, GraphQL och AssemblyScript.
+
+### Versioner
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| Version | Versionsanteckningar                                                                                                                                                                                                                                     |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### Inbyggda typer
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from "@graphprotocol/graph-ts";
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from "@graphprotocol/graph-ts";
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Address
+
+```typescript
+import { Address } from "@graphprotocol/graph-ts";
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### Store API
+
+```typescript
+import { store } from "@graphprotocol/graph-ts";
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Skapa entiteter
+
+Följande är ett vanligt mönster för att skapa entiteter från Ethereum-händelser.
+
+```typescript
+// Importera händelseklassen Transfer som genererats från ERC20 ABI
+import { Transfer as TransferEvent } from "../generated/ERC20/ERC20";
+
+// Importera entitetstypen Transfer som genererats från GraphQL-schemat
+import { Transfer } from "../generated/schema";
+
+// Händelsehanterare för överföring
+export function handleTransfer(event: TransferEvent): void {
+  // Skapa en Transfer-entitet, med transaktionshash som enhets-ID
+  let id = event.transaction.hash;
+  let transfer = new Transfer(id);
+
+  // Ange egenskaper för entiteten med hjälp av händelseparametrarna
+  transfer.from = event.params.from;
+  transfer.to = event.params.to;
+  transfer.amount = event.params.amount;
+
+  // Spara entiteten till lagret
+  transfer.save();
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Ladda entiteter från lagret
+
+Om en entitet redan finns kan den laddas från lagret med följande:
+
+```typescript
+let id = event.transaction.hash; // eller hur ID konstrueras
+let transfer = Transfer.load(id);
+if (transfer == null) {
+  transfer = new Transfer(id);
+}
+
+// Använd överföringsenheten som tidigare
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Sökning av entiteter skapade inom ett block
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash; // eller hur ID konstrueras
+let transfer = Transfer.loadInBlock(id);
+if (transfer == null) {
+  transfer = new Transfer(id);
+}
+
+// Använd överföringsenheten som tidigare
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Sökning av härledda entiteter
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+Detta möjliggör laddning av härledda entitetsfält från inom en händelsehanterare. Till exempel, med följande schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Ladda de Token-enheter som är associerade med en given innehavare
+let tokens = holder.tokens.load()
+```
+
+#### Uppdatering av befintliga entiteter
+
+Det finns två sätt att uppdatera en befintlig entitet:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+Att ändra egenskaper är rakt fram i de flesta fall, tack vare de genererade egenskapsinställarna:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+Det är också möjligt att avaktivera egenskaper med en av följande två instruktioner:
+
+```typescript
+transfer.from.unset();
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// Detta kommer inte att fungera
+entity.numbers.push(BigInt.fromI32(1));
+entity.save();
+
+// Detta kommer att fungera
+let numbers = entity.numbers;
+numbers.push(BigInt.fromI32(1));
+entity.numbers = numbers;
+entity.save();
+```
+
+#### Ta bort entiteter från lagret
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+Ethereum API ger tillgång till smarta kontrakt, offentliga tillståndsvariabler, kontrakt funktioner, händelser, transaktioner, block och kodning/avkodning av Ethereum data.
+
+#### Stöd för Ethereum-typer
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+Följande exempel illustrerar detta. Med en subgraph-schema som
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash;
+let transfer = new Transfer(id);
+transfer.from = event.params.from;
+transfer.to = event.params.to;
+transfer.amount = event.params.amount;
+transfer.save();
+```
+
+#### Händelser och Block/Transaktionsdata
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Åtkomst till Smart Contract-tillstånd
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+En vanlig mönster är att komma åt kontraktet från vilket en händelse härstammar. Detta uppnås med följande kod:
+
+```typescript
+// Importera den genererade kontraktsklassen och den genererade klassen för överföringshändelser
+import {
+  ERC20Contract,
+  Transfer as TransferEvent,
+} from "../generated/ERC20Contract/ERC20Contract";
+// Importera den genererade entitetsklassen
+import { Transfer } from "../generated/schema";
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind kontraktet till den adress som skickade händelsen
+  let contract = ERC20Contract.bind(event.address);
+
+  // Åtkomst till tillståndsvariabler och funktioner genom att anropa dem
+  let erc20Symbol = contract.symbol();
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+Andra kontrakt som är en del av subgraphen kan importeras från den genererade koden och bindas till en giltig adress.
+
+#### Hantering av återkallade anrop
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravitera = gravitera.bind(event.address);
+let callResult = gravitera_gravatarToOwner(gravatar);
+if (callResult.reverted) {
+  log.info("getGravatar reverted", []);
+} else {
+  let owner = callResult.value;
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Kodning/Dekodning av ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+För ytterligare information:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### API för loggning
+
+```typescript
+import { log } from "@graphprotocol/graph-ts";
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info("Message to be displayed: {}, {}, {}", [
+  value.toString(),
+  anotherValue.toString(),
+  "already a string",
+]);
+```
+
+#### Loggning av ett eller flera värden
+
+##### Logga ett enskilt värde
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Logga en enskild post från en befintlig array
+
+I exemplet nedan loggas endast det första värdet i argument arrayen, trots att arrayen innehåller tre värden.
+
+```typescript
+let myArray = ["A", "B", "C"];
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Visar : "Mitt värde är: A" (Även om tre värden skickas till `log.info`)
+  log.info("Mitt värde är: {}", myArray);
+}
+```
+
+#### Logga flera poster från en befintlig array
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ["A", "B", "C"];
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Visar: "Mitt första värde är: A, andra värdet är: B, tredje värdet är: C"
+  log.info(
+    "My first value is: {}, second value is: {}, third value is: {}",
+    myArray
+  );
+}
+```
+
+##### Logga en specifik post från en befintlig array
+
+För att visa ett specifikt värde i arrayen måste det indexeras och tillhandahållas.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Visar : "Mitt tredje värde är C"
+  log.info("My third value is: {}", [myArray[2]]);
+}
+```
+
+##### Loggning av händelseinformation
+
+I exemplet nedan loggas blocknummer, blockhash och transaktionshash från en händelse:
+
+```typescript
+import { log } from "@graphprotocol/graph-ts";
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug("Block number: {}, block hash: {}, transaction hash: {}", [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ]);
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from "@graphprotocol/graph-ts"
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+För att läsa en fil från IPFS med en given IPFS-hash eller sökväg görs följande:
+
+```typescript
+// Placera detta i en händelsehanterare i mappningen
+let hash = "QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D";
+let data = ipfs.cat(hash);
+
+// Sökvägar som `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// som inkluderar filer i kataloger stöds också
+let path = "QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile";
+let data = ipfs.cat(path);
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from "@graphprotocol/graph-ts";
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // Se JSONValue-dokumentationen för mer information om hur man hanterar
+  // med JSON-värden
+  let obj = value.toObject();
+  let id = obj.get("id");
+  let title = obj.get("title");
+
+  if (!id || !title) {
+    return;
+  }
+
+  // Callbacks kan också skapa enheter
+  let newItem = new Item(id);
+  newItem.title = title.toString();
+  newitem.parent = userData.toString(); // Ange parent till "parentId"
+  newitem.save();
+}
+
+// Placera detta i en händelsehanterare i mappningen
+ipfs.map("Qm...", "processItem", Value.fromString("parentId"), ["json"]);
+
+// Alternativt kan du använda `ipfs.mapJSON`.
+ipfs.mapJSON("Qm...", "processItem", Value.fromString("parentId"));
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### Crypto API
+
+```typescript
+import { crypto } from "@graphprotocol/graph-ts";
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from "@graphprotocol/graph-ts"
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### Typkonverteringsreferens
+
+| Source(s)            | Destination          | Conversion function             |
+| -------------------- | -------------------- | ------------------------------- |
+| Address              | Bytes                | none                            |
+| Address              | String               | s.toHexString()                 |
+| BigDecimal           | String               | s.toString()                    |
+| BigInt               | BigDecimal           | s.toBigDecimal()                |
+| BigInt               | Sträng (hexadecimal) | s.toHexString() eller s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                    |
+| BigInt               | i32                  | s.toI32()                       |
+| Boolean              | Boolean              | none                            |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)       |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)     |
+| Bytes                | Sträng (hexadecimal) | s.toHexString() eller s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                    |
+| Bytes                | String (base58)      | s.toBase58()                    |
+| Bytes                | i32                  | s.toI32()                       |
+| Bytes                | u32                  | s.toU32()                       |
+| Bytes                | JSON                 | json.fromBytes(s)               |
+| int8                 | i32                  | none                            |
+| int32                | i32                  | none                            |
+| int32                | BigInt               | BigInt.fromI32(s)               |
+| uint24               | i32                  | none                            |
+| int64 - int256       | BigInt               | none                            |
+| uint32 - uint256     | BigInt               | none                            |
+| JSON                 | boolean              | s.toBool()                      |
+| JSON                 | i64                  | s.toI64()                       |
+| JSON                 | u64                  | s.toU64()                       |
+| JSON                 | f64                  | s.toF64()                       |
+| JSON                 | BigInt               | s.toBigInt()                    |
+| JSON                 | string               | s.toString()                    |
+| JSON                 | Array                | s.toArray()                     |
+| JSON                 | Object               | s.toObject()                    |
+| String               | Address              | Address.fromString(s)           |
+| Bytes                | Address              | Address.fromBytes(s)            |
+| String               | BigInt               | BigInt.fromString(s)            |
+| String               | BigDecimal           | BigDecimal.fromString(s)        |
+| Sträng (hexadecimal) | Bytes                | ByteArray.fromHexString(s)      |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)           |
+
+### Metadata för datakälla
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entitet och DataSourceContext
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From 907405ea7cd9eb596df26b285a42914eeb523d55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:14:59 -0500
Subject: [PATCH 0862/3820] New translations common-issues.mdx (Swedish)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/sv/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/sv/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..b1f7b27f220a
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Vanliga problem med AssemblyScript
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 49d7b31324d8c4b23b09bb438c22ac1ed89c1a3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:01 -0500
Subject: [PATCH 0863/3820] New translations unit-testing-framework.mdx
 (Swedish)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/sv/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/sv/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..f901af278bb1
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Enhetsprovningsramverk
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Komma igång
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+Du kan använda Matchstick i WSL både med Docker-metoden och binärmetoden. Eftersom WSL kan vara lite knepigt, här är några tips om du stöter på problem som
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+eller
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI alternativ
+
+Detta kommer att köra alla tester i testmappen:
+
+```sh
+graph test
+```
+
+Detta kommer att köra en test med namnet gravity.test.ts och/eller alla tester inuti en mapp med namnet gravity:
+
+```sh
+graph test gravity
+```
+
+Då körs endast den specifika testfilen:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Konfiguration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo undergraf
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Handledning för video
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Exempel:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Exempel:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+eller
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Exempel:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Exempel:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Exempel:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Skriv en enhetstest
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Antag att vi har följande hanteringsfunktion (tillsammans med två hjälpfunktioner för att göra vårt liv enklare):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+Vi måste först skapa en testfil i vårt projekt. Det här är ett exempel på hur det kan se ut:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- Vi ställer in vår inledande status och lägger till en anpassad Gravatar-entitet;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- Vi försäkrar oss om statusen för lagringen. Hur fungerar det? - Vi skickar en unik kombination av entitetstyp och id. Sedan kontrollerar vi ett specifikt fält på den entiteten och försäkrar oss om att det har det värde vi förväntar oss. Vi gör detta både för den ursprungliga Gravatar-entiteten vi lade till i lagringen och de två Gravatar-entiteterna som läggs till när hanteringsfunktionen anropas;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+Så där har vi skapat vårt första test! 👏
+
+För att köra våra tester behöver du helt enkelt köra följande i din subgrafs rotmapp:
+
+`graph test Gravity`
+
+Och om allt går bra bör du hälsas av följande:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Vanliga testscenarier
+
+### Fylla på lagringen med en viss status
+
+Användare kan fylla på lagringen med en känd uppsättning entiteter. Här är ett exempel på att initialisera lagringen med en Gravatar-entitet:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Anropa en mappnings funktion med en händelse
+
+En användare kan skapa en anpassad händelse och skicka den till en mappningsfunktion som är bunden till butiken:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Anropar alla mappningar med händelsefixturer
+
+Användare kan kalla mappningarna med testfixturer.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocka kontraktsanrop
+
+Användare kan simulera kontraktssamtal:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+För att kunna simulera ett kontraktsanrop och ett hardcore returvärde måste användaren tillhandahålla en kontraktsadress, funktionsnamn, funktionssignatur, en uppsättning argument och naturligtvis - returvärdet.
+
+Användare kan också simulera funktionsåtergångar:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Simulering av IPFS-filer (från matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // Se JSONValue-dokumentationen för mer information om hur man hanterar
+  // med JSON-värden
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks kan också skapa enheter
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// funktion som anropar ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Kontrollera tillståndet för lagret
+
+Användare kan kontrollera det slutgiltiga (eller delvisa) tillståndet för lagret genom att verifiera enheter. För att göra detta måste användaren ange en enhetstyp, den specifika ID: n för en enhet, namnet på ett fält på den enheten och det förväntade värdet på fältet. Här är ett snabbt exempel:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interagera med händelsemetadata
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Läs
+let logType = newGravatarEvent.logType
+
+// Skriv
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Påstående om variabelns likhet
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Användare kan hävda att en entitet inte finns i butiken. Funktionen tar en entitetstyp och ett id. Om entiteten faktiskt finns i butiken kommer testet att misslyckas med ett relevant felmeddelande. Här är ett snabbt exempel på hur du använder den här funktionen:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+Du kan skriva ut hela lagret till konsolen med hjälp av denna hjälpfunktion:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Förväntat misslyckande
+
+Användare kan ha förväntade testfel genom att använda flaggan shouldFail på test()-funktionerna:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+Om testet är markerat med shouldFail = true men INTE misslyckas, kommer det att visas som ett fel i loggarna och testblocket kommer att misslyckas. Om testet är markerat med shouldFail = false (standardtillståndet) kommer testköraren dessutom att krascha.
+
+### Loggning
+
+Att ha anpassade loggar i enhetstesterna är exakt samma sak som att logga i mappningarna. Skillnaden är att loggobjektet måste importeras från matchstick-as snarare än graph-ts. Här är ett enkelt exempel med alla icke-kritiska loggtyper:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Användare kan också simulera ett kritiskt fel, t.ex:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Loggning av kritiska fel kommer att stoppa utförandet av testerna och orsaka total krasch. Trots allt vill vi säkerställa att din kod inte har kritiska loggar i produktion, och du bör märka det omedelbart om det skulle inträffa.
+
+### Testning av härledda fält
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testning av dynamiska datakällor
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Exempel nedan:
+
+Först har vi följande händelsehanterare (som medvetet har ändrats för att visa datasourcemockning):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+Och sedan har vi testet som använder en av metoderna i namespace dataSourceMock för att ställa in ett nytt returvärde för alla dataSource-funktioner:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Observera att dataSourceMock.resetValues() anropas i slutet. Det beror på att värdena kom ihåg när de ändrades och behöver återställas om du vill återgå till standardvärdena.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Testtäckning
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Förutsättningar
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Exportera dina hanterare
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Användning
+
+När allt är klart kör du bara testtäckningsverktyget:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+Det kommer att köra täckningsverktyget och du bör se något liknande i terminalen:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Testkörningens varaktighet i loggutmatningen
+
+Loggutmatningen innehåller testkörningens varaktighet. Här är ett exempel:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Vanliga kompilatorfel
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Ytterligare resurser
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Respons
+
+Om du har några frågor, feedback, funktionsförfrågningar eller bara vill nå ut, är det bästa stället The Graph Discord där vi har en dedikerad kanal för Matchstick, kallad 🔥| unit-testing.

From 61c57cfe395e66c5c87346c4bba70ef168590599 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:02 -0500
Subject: [PATCH 0864/3820] New translations transferring-a-subgraph.mdx
 (Swedish)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/sv/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/sv/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From e4f0fcc96f9c1eb1c42e73c795e01e2601746acb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:03 -0500
Subject: [PATCH 0865/3820] New translations graphql-api.mdx (Swedish)

---
 .../sv/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/sv/subgraphs/querying/graphql-api.mdx b/website/pages/sv/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..0a5704e2eecf
--- /dev/null
+++ b/website/pages/sv/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Exempel
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sortering
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Exempel
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Exempel på sortering av nästlade entiteter
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Paginering
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Fråga efter de första 10 tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtrering
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Exempel på filtrering av intervall
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Exempel på blockfiltrering
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+Detta kan vara användbart om du bara vill hämta enheter som har ändrats, till exempel sedan den senaste gången du pollade. Eller alternativt kan det vara användbart för att undersöka eller felsöka hur enheter förändras i din undergraf (om det kombineras med ett blockfilter kan du isolera endast enheter som ändrades i ett visst block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Exempel på filtrering av inbäddade entiteter
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+Detta kan vara användbart om du vill hämta endast entiteter vars entiteter på barnnivå uppfyller de angivna villkoren.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logiska operatorer
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### Alla filter
+
+Fullständig lista över parametersuffix:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Tidsreseförfrågningar
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Exempel
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Exempel
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltextsökförfrågningar
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Fulltextsökoperatorer:
+
+| Symbol | Operatör    | Beskrivning                                                                                                                                     |
+| ------ | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`    | `And`       | För att kombinera flera söktermer till ett filter för entiteter som inkluderar alla de angivna termerna                                         |
+| |      | `Or`        | Förfrågningar med flera söktermer separerade av ellipsen kommer att returnera alla entiteter med en matchning från någon av de angivna termerna |
+| `<->`  | `Follow by` | Ange avståndet mellan två ord.                                                                                                                  |
+| `:*`   | `Prefix`    | Använd prefixsöktermen för att hitta ord vars prefix matchar (2 tecken krävs.)                                                                  |
+
+#### Exempel
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Kombinera fulltextoperatorer för att skapa mer komplexa filter. Med en pretext-sökoperatör kombinerad med en follow by kommer detta exempel att matcha alla bloggenheter med ord som börjar med "lou" följt av "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validering
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entiteter
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Metadata för undergrafer
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+Om ett block anges är metadata från det blocket, om inte används det senast indexerade blocket. Om det anges måste blocket vara efter undergrafens startblock och mindre än eller lika med det senast indexerade blocket.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: blockets hash
+- nummer: blockets nummer
+- timestamp: blockets timestamp, om tillgänglig (detta är för närvarande endast tillgängligt för undergrafer som indexerar EVM-nätverk)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 661bab7037475e1e62d0a35c24d9c4a5f67231a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:04 -0500
Subject: [PATCH 0866/3820] New translations python.mdx (Swedish)

---
 .../pages/sv/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/querying/python.mdx

diff --git a/website/pages/sv/subgraphs/querying/python.mdx b/website/pages/sv/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..a5bfbae7a459
--- /dev/null
+++ b/website/pages/sv/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Komma igång
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 806bc3c98b4d9b6ab51d99630c1b857602a680b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:06 -0500
Subject: [PATCH 0867/3820] New translations triggers.mdx (Swedish)

---
 website/pages/sv/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/sv/substreams/sps/triggers.mdx

diff --git a/website/pages/sv/substreams/sps/triggers.mdx b/website/pages/sv/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/sv/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 2f2d24463645605ff8bcb557bc74edaeb5c353c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:07 -0500
Subject: [PATCH 0868/3820] New translations overview.mdx (Turkish)

---
 website/pages/tr/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/tr/indexing/overview.mdx

diff --git a/website/pages/tr/indexing/overview.mdx b/website/pages/tr/indexing/overview.mdx
new file mode 100644
index 000000000000..9eaa60e5ac98
--- /dev/null
+++ b/website/pages/tr/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+İndeksleyiciler, indeksleme ve sorgu işleme hizmetleri sağlamak için Graph Token'leri (GRT) stake eden Graph Ağındaki düğüm operatörleridir. İndeksleyiciler, hizmetleri karşılığında sorgu ücretleri ve indeksleme ödülleri kazanırlar. Ayrıca üstel bir indirim fonksiyonuna göre geri ödenen sorgu ücretleri de kazanırlar.
+
+GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.
+
+Indexers select subgraphs to index based on the subgraph’s curation signal, where Curators stake GRT in order to indicate which subgraphs are high-quality and should be prioritized. Consumers (eg. applications) can also set parameters for which Indexers process queries for their subgraphs and set preferences for query fee pricing.
+
+<Difficulty level="ADVANCED" />
+
+## SSS
+
+### What is the minimum stake required to be an Indexer on the network?
+
+The minimum stake for an Indexer is currently set to 100K GRT.
+
+### What are the revenue streams for an Indexer?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### How are indexing rewards distributed?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### What is a proof of indexing (POI)?
+
+POIs are used in the network to verify that an Indexer is indexing the subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific subgraph deployment up to and including that block.
+
+### When are indexing rewards distributed?
+
+Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).
+
+### Can pending indexing rewards be monitored?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Many of the community-made dashboards include pending rewards values and they can be easily checked manually by following these steps:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### What are disputes and where can I view them?
+
+Indexer's queries and allocations can both be disputed on The Graph during the dispute period. The dispute period varies, depending on the type of dispute. Queries/attestations have 7 epochs dispute window, whereas allocations have 56 epochs. After these periods pass, disputes cannot be opened against either of allocations or queries. When a dispute is opened, a deposit of a minimum of 10,000 GRT is required by the Fishermen, which will be locked until the dispute is finalized and a resolution has been given. Fisherman are any network participants that open disputes.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- If the dispute is rejected, the GRT deposited by the Fishermen will be burned, and the disputed Indexer will not be slashed.
+- If the dispute is settled as a draw, the Fishermen's deposit will be returned, and the disputed Indexer will not be slashed.
+- If the dispute is accepted, the GRT deposited by the Fishermen will be returned, the disputed Indexer will be slashed and the Fishermen will earn 50% of the slashed GRT.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### What are query fee rebates and when are they distributed?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Bir tahsisat kapatıldıktan sonra iadeler İndeksleyici tarafından talep edilebilir. Talep edildikten sonra, sorgu ücreti iadeleri, sorgu ücreti kesintisi ve üstel indirim fonksiyonuna göre İndeksleyiciye ve Delegatörlerine dağıtılır.
+
+### What is query fee cut and indexing reward cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### How do Indexers know which subgraphs to index?
+
+Indexers may differentiate themselves by applying advanced techniques for making subgraph indexing decisions but to give a general idea we'll discuss several key metrics used to evaluate subgraphs in the network:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### Donanım gereksinimleri nelerdir?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Kurulum  | Postgres<br />(CPU'lar) | Postgres<br />(GB cinsinden bellek) | Postgres<br />(TB cinsinden disk) | VM'ler<br />(CPU'lar) | VM'ler<br />(GB cinsinden bellek) |
+| -------- | :---------------------: | :---------------------------------: | :-------------------------------: | :-------------------: | :-------------------------------: |
+| Düşük    |            4            |                  8                  |                 1                 |           4           |                 16                |
+| Standart |            8            |                  30                 |                 1                 |           12          |                 48                |
+| Orta     |            16           |                  64                 |                 2                 |           32          |                 64                |
+| Yüksek   |            72           |                 468                 |                3.5                |           48          |                184                |
+
+### Bir İndeksleyicinin alması gereken bazı temel güvenlik önlemleri nelerdir?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Altyapı
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Not: Çevik ölçeklendirmeyi desteklemek için, sorgulama ve indeksleme endişelerinin sorgu düğümleri ve indeks düğümleri olarak farklı düğüm kümeleri arasında ayrılması önerilir.
+
+### Portlara genel bakış
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Port | Amaç                                                  | Rotalar                                        | CLI Argümanı       | Ortam Değişkeni |
+| ---- | ----------------------------------------------------- | ---------------------------------------------- | ------------------ | --------------- |
+| 8000 | GraphQL HTTP sunucusu<br />( subgraph sorguları için) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -               |
+| 8001 | GraphQL WS<br />( subgraph abonelikleri için)         | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -               |
+| 8020 | JSON-RPC<br />(dağıtımları yönetmek için)             | /                                              | \--admin-port      | -               |
+| 8030 | Subgraph indeksleme durum API'si                      | /graphql                                       | \--index-node-port | -               |
+| 8040 | Prometheus metrikleri                                 | /metrics                                       | \--metrics-port    | -               |
+
+#### İndeksleyici Hizmeti
+
+| Port | Amaç                                                         | Rotalar                                                     | CLI Argümanı    | Ortam Değişkeni        |
+| ---- | ------------------------------------------------------------ | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP sunucusu<br />(ücretli subgraph sorguları için) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrikleri                                        | /metrics                                                    | \--metrics-port | -                      |
+
+#### İndeksleyici Aracı
+
+| Port | Purpose                     | Rotalar | CLI Argument               | Environment Variable                    |
+| ---- | --------------------------- | ------- | -------------------------- | --------------------------------------- |
+| 8000 | İndeksleyici yönetim API'si | /       | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Google Cloud'da Terraform kullanarak sunucu altyapısını kurun
+
+> Not: İndeksleyiciler alternatif olarak AWS, Microsoft Azure veya Alibaba kullanabilir.
+
+#### Önkoşulları yükleme
+
+- Google Cloud SDK
+- Kubectl komut satırı aracı
+- Terraform
+
+#### Bir Google Cloud Projesi Oluşturun
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Google Cloud ile kimlik doğrulaması yapın ve yeni bir proje oluşturun.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Yeni projenin faturalandırılmasını etkinleştirmek için Google Cloud Console'un faturalandırma sayfasını kullanın.
+
+- Bir Google Cloud yapılandırması oluşturun.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Gerekli Google Cloud API'lerini etkinleştirin.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Bir hizmet hesabı oluşturun.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Bir sonraki adımda oluşturulacak veritabanı ve Kubernetes kümesi arasında eşlemeyi etkinleştirin.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Create minimal terraform configuration file (update as needed).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Use Terraform to create infrastructure
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Altyapıyı oluşturmak için aşağıdaki komutları çalıştırın.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### İndeksleyici için Kubernetes komponentlerini oluşturma
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Kaynaktan başlama
+
+#### Önkoşulları yükleme
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Kurulum
+
+1. Bir PostgreSQL veritabanı sunucusu başlatma
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Artık tüm bağımlılıklar ayarlandığına göre Graph Düğümü'nü başlatın:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Docker kullanmaya başlama
+
+#### Ön Koşullar
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Kurulum
+
+1. Graph Düğümü'nü klonlayın ve Docker dizinine gidin:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Ethereum uç noktanıza bağlanacak yerel bir Graph Düğümü başlatın:
+
+```sh
+docker-compose up
+```
+
+### İndeksleyici komponentleri
+
+Ağa başarılı bir şekilde katılmak hemen hemen sürekli izleme ve etkileşim gerektirir, bu nedenle İndeksleyicilerin ağa katılımını kolaylaştırmak için bir dizi Typescript uygulaması oluşturduk. Üç İndeksleyici bileşeni bulunmaktadır:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Buradan başlayın
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### NPM paketlerinden
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### Kaynaktan
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Docker kullanma
+
+- Kayıt defterinden görüntüleri çekin
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Veya görüntüleri yerel olarak kaynaktan oluşturun
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Komponentleri çalıştırın
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### K8s ve Terraform kullanma
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Kullanış
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### İndeksleyici Aracı
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### İndeksleyici hizmeti
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### İndeksleyici CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### İndeksleyici CLI kullanarak indeksleyici yönetimi
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Kullanış
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### İndeksleme kuralları
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Veri modeli:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+İndeksleme kuralı örnek kullanımı:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Eylemler kuyruğu CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Kuyruğa üçüncü şahıs optimizasyon aracı veya indexer-cli kullanıcısı tarafından eklenen eylem
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- İndeksleyici, eylem yürütme geçmişini görmek için eylem kuyruğunu izleyebilir ve gerekirse yürütmede başarısız olan eylem öğelerini yeniden onaylayabilir ve güncelleyebilir. Eylem kuyruğu, kuyruğa alınan ve gerçekleştirilen tüm eylemlerin bir geçmiş kaydını sağlar.
+
+Veri modeli:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Kaynaktan kullanım örneği:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Tahsis yönetimi için desteklenen eylem türlerinin farklı girdi gereksinimleri olduğunu unutmayın:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - gerekli eylem parametreleri:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - gerekli eylem parametreleri:
+    - allocationID
+    - deploymentID
+  - opsiyonel eylem parametreleri:
+    - poi
+    - force (graph-node'un sağladığıyla uyuşmasa bile sağlanan POI'yi kullanmaya zorlar)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - gerekli eylem parametreleri:
+    - allocationID
+    - deploymentID
+    - amount
+  - opsiyonel eylem parametreleri:
+    - poi
+    - force (graph-node'un sağladığıyla uyuşmasa bile sağlanan POI'yi kullanmaya zorlar)
+
+#### Maliyet modelleri
+
+Maliyet modelleri, pazar ve sorgu niteliklerine dayalı olarak sorgular için dinamik fiyatlandırma sağlar. İndeksleyici Hizmeti, sorgulara yanıt vermeyi amaçladıkları her bir subgraph için ağ geçitleriyle bir maliyet modeli paylaşır. Ağ geçitleri de sorgu başına İndeksleyici seçim kararları vermek ve seçilen İndeksleyicilerle ödeme pazarlığı yapmak için maliyet modelini kullanır.
+
+#### Agora
+
+Agora dili, sorgular için maliyet modellerini bildirmek için esnek bir format sağlar. Agora fiyat modeli, bir GraphQL sorgusundaki her üst düzey sorgu için sırayla çalışan bir deyimler serisidir. Her üst düzey sorgu için, onunla eşleşen ilk ifade o sorgunun fiyatını belirler.
+
+Bir ifade, GraphQL sorgularını eşleştirmek için kullanılan bir evet-hayır sorusundan ve değerlendirildiğinde GRT cinsinden ondalık maliyet çıktısı veren bir maliyet ifadesinden oluşur. Bir sorgunun adlandırılmış argüman konumundaki değerleri evet-hayır sorusunda yakalanabilir ve ifadede kullanılabilir. Ayrıca, genel değerler de ayarlanabilir ve bir ifadedeki yer tutucuların yerine kullanılabilir.
+
+Örnek maliyet modeli:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Yukarıdaki modeli kullanarak örnek sorgu maliyetlendirmesi:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Maliyet modelinin uygulanması
+
+Maliyet modelleri, onları veritabanında saklanmak üzere İndeksleyici aracısının İndeksleyici Yönetim API'sine aktaran İndeksleyici CLI aracılığıyla uygulanır. İndeksleyici Hizmeti daha sonra bunları alır ve maliyet modellerini istedikleri zaman ağ geçitlerine sunar.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Ağ ile etkileşim kurma
+
+### Protokolde stake
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Tokenleri onaylama
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Tokenleri stake et
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### Bir tahsisin ömrü
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From fc5cd568a9987a1e29f4c079cbbecc3455966d06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:09 -0500
Subject: [PATCH 0869/3820] New translations tap.mdx (Turkish)

---
 website/pages/tr/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/tr/indexing/tap.mdx

diff --git a/website/pages/tr/indexing/tap.mdx b/website/pages/tr/indexing/tap.mdx
new file mode 100644
index 000000000000..5ad4f2dc020e
--- /dev/null
+++ b/website/pages/tr/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Genel Bakış
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Ayrıntılar
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Gereksinimler
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notlar:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From f934ef78d0d15bf6c3ab36796c66553d84da3443 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:10 -0500
Subject: [PATCH 0870/3820] New translations graph-node.mdx (Turkish)

---
 .../pages/tr/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/tr/indexing/tooling/graph-node.mdx

diff --git a/website/pages/tr/indexing/tooling/graph-node.mdx b/website/pages/tr/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..b9a840ecce56
--- /dev/null
+++ b/website/pages/tr/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Düğümü, subgraphları indeksleyen ve sonuçta oluşan verileri GraphQL API aracılığıyla sorgulanabilir hale getiren bileşendir. Bu nedenle indeksleyici yığınının merkezi bir parçasıdır ve başarılı bir indeksleyici çalıştırmak için Graph Düğümü'nün doğru şekilde çalışması çok önemlidir.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL veritabanı
+
+Graph Düğümü'nün ana deposu, burada subgraph verileri yanı sıra subgraphlarla ilgili üst veriler ve blok önbelleği ve eth_call önbelleği gibi subgraphtan bağımsız ağ verileri saklanır.
+
+### Ağ istemcileri
+
+In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS Düğümleri
+
+Subgraph dağıtım üst verilerini IPFS ağında depolanır. Graph düğümü, subgraph manifestini ve tüm bağlantılı dosyaları almak için subgraph dağıtımı sırasında öncelikle IPFS düğümüne erişir. Ağ indeksleyicilerinin kendi IPFS düğümlerini barındırmaları gerekmez. Ağ için bir IPFS düğümü https://ipfs.network.thegraph.com adresinde barındırılmaktadır.
+
+### Prometheus metrik sunucusu
+
+İzleme ve raporlama etkinleştirmek için Graph Düğümü, metrikleri bir Prometheus metrik sunucusuna opsiyonel olarak kaydedebilir.
+
+### Kaynaktan başlama
+
+#### Önkoşulları yükleme
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Kurulum
+
+1. Bir PostgreSQL veritabanı sunucusu başlatma
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Artık tüm bağımlılıklar ayarlandığına göre Graph Düğümü'nü başlatın:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Kubernetes'i kullanmaya başlarken
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Portlar
+
+Graph Düğümü çalışırken aşağıdaki portları açar:
+
+| Port | Amaç                                                  | Rotalar                                        | CLI Argümanı       | Ortam Değişkeni |
+| ---- | ----------------------------------------------------- | ---------------------------------------------- | ------------------ | --------------- |
+| 8000 | GraphQL HTTP sunucusu<br />( subgraph sorguları için) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -               |
+| 8001 | GraphQL WS<br />( subgraph abonelikleri için)         | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -               |
+| 8020 | JSON-RPC<br />(dağıtımları yönetmek için)             | /                                              | \--admin-port      | -               |
+| 8030 | Subgraph indeksleme durum API'si                      | /graphql                                       | \--index-node-port | -               |
+| 8040 | Prometheus metrikleri                                 | /metrics                                       | \--metrics-port    | -               |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Gelişmiş Graph Düğüm yapılandırması
+
+En basit haliyle, Graph Düğümü tek bir Graph Düğüm örneği, bir PostgreSQL veritabanı, bir IPFS düğümü ve indekslenecek subgraphlar tarafından gerektirilen ağ istemcileri ile çalıştırılabilir.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> Yapılandırma dosyası kullanırken --postgres-url, --postgres-secondary-hosts ve --postgres-host-weights seçeneklerinin kullanılması mümkün değildir.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Birden Fazla Graph Düğümü
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Birden fazla Graph Düğümü, aynı veritabanını kullanacak şekilde yapılandırılabilir ve veritabanı sharding kullanılarak yatay olarak ölçeklenebilir.
+
+#### Dağıtım kuralları
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Örnek dağıtım kuralı yapılandırması:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Özelleştirilmiş sorgu düğümleri
+
+Düğümler, yapılandırma dosyasına aşağıdakini dahil ederek açıkça sorgu düğümleri olarak yapılandırılabilir:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+\--node-id'si düzenli ifade ile eşleşen herhangi bir düğüm, sadece sorgulara yanıt vermek üzere ayarlanacaktır.
+
+#### Sharding ile veritabanı ölçeklendirme
+
+Çoğu kullanım durumu için, tek bir Postgres veritabanı bir graph-düğümü örneğini desteklemek için yeterlidir. Bir graph-düğümü örneği tek bir Postgres veritabanından daha büyük hale geldiğinde, bu graph düğümü verilerinin depolanmasını birden fazla Postgres veritabanına yaymak mümkündür. Tüm veritabanları birlikte, graph-düğümü örneğinin deposunu oluşturur. Her tekil veritabanına bir shard denir.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding, Graph Düğümü'nün üzerine koyduğu yükü mevcut veritabanınıza koyamadığınızda ve veritabanı boyutunu artıramayacağınızda faydalı hale gelir.
+
+> Genellikle, shard'larla başlamadan önce tek bir veritabanını mümkün olduğunca büyük hale getirmek daha mantıklıdır. Tek bir istisna, sorgu trafiği subgraphlar arasında çokta eşit olmayan bir şekilde bölünmesidir. Bu durumda, yüksek-hacimli subgraphlar'ın bir shard'da tutulması ve geriye kalan her şeyin diğer bir shard'da tutulması, yüksek hacimli subgraphlar için verinin veritabanı dahili önbellekte kalması ve düşük hacimli subgraphlar'daki daha az ihtiyaç duyulan veriler tarafından değiştirilmemesi daha olası olduğu için çok yardımcı olabilir.
+
+Bağlantı yapılandırması açısından postgresql.conf'da max_connections değerinin 400 (veya belki de 200) olarak ayarlanması ve store_connection_wait_time_ms ve store_connection_checkout_count Prometheus metriklerine bakılması önerilir. Belirgin bekleme süreleri (5 milisaniye'nin üzerinde herhangi bir değer) yetersiz bağlantıların mevcut olduğunun bir işaretidir; yüksek bekleme süreleri veritabanının çok yoğun olması gibi sebeplerden de kaynaklanabilir. Ancak, veritabanı genel olarak stabil görünüyorsa, yüksek bekleme süreleri bağlantı sayısını arttırma ihtiyacını belirtir. Yapılandırmada her graph-düğümü örneğinin ne kadar bağlantı kullanabileceği bir üst sınırdır ve Graph Düğümü bunları gereksiz bulmadığı sürece açık tutmaz.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Özelleştirilmiş blok alınması
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Birden fazla ağın desteklenmesi
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Birden fazla ağ
+- Ağ başına birden fazla sağlayıcı (bu, yükü sağlayıcılar arasında bölme ve bir Graph Düğümü'nün deneyimsel Firehose desteği gibi daha ucuz sağlayıcıları tercih etmesi ile tam düğümlerin yanı sıra arşiv düğümlerinin yapılandırılmasına da izin verebilir).
+- Özellikler, kimlik doğrulama ve sağlayıcı türü gibi ek sağlayıcı detayları (deneysel Firehose desteği için)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Ortam değişkenleri
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Sürekli dağıtım
+
+Gelişmiş yapılandırmaya sahip ölçeklendirilmiş bir dizinleme kurulumu işleten kullanıcılar, Graph Düğümler'ini Kubernetes ile yönetmekten faydalanabilirler.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Graph Düğümü Yönetimi
+
+Çalışan bir Graph Düğümüne (veya Graph Düğümlerine) sahip olunduktan sonra, dağıtılan subgraplar'ın bu düğümler üzerinde yönetilmesi zorluğu ortaya çıkar. Subgraphlar'ı yönetmeye yardımcı olmak için Graph Düğümü, bir dizi araç sunar.
+
+#### Kayıt tutma
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Düğümü, varsayılan olarak 8040 port'undaki Prometheus uç noktası aracılığıyla metrikleri sağlar. Ardından Grafana, bu metrikleri görselleştirmek için kullanılabilir.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Subgraphlarla çalışma
+
+#### İndeksleme durum API'si
+
+Varsayılan olarak 8030/graphql port'unda mevcut olan indeksleme durumu API'si, farklı subgraphlar için indeksleme durumunu ve ispatlarını kontrol etmek, subgraph özelliklerini incelemek ve daha fazlasını yapmak için çeşitli yöntemler sunar.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Endeksleme performansı
+
+İndeksleme sürecinin üç ayrı parçası bulunmaktadır:
+
+- Sağlayıcıdan ilgili olayları getirme
+- Uygun işleyicilerle sırayla olayları işleme (bu, durumu sormak için zincire çağrı yapmayı ve depodan veri getirmeyi içerebilir)
+- Elde edilen verileri depoya yazma
+
+Bu aşamalar boru hattında (yani eşzamanlı olarak yürütülebilir), ancak birbirlerine bağımlıdırlar. Subgraphlar'ın indekslenmesi yavaş olduğunda, bunun altındaki neden spesifik subgraphlar'a bağlı olacaktır.
+
+İndeksleme yavaşlığının yaygın nedenleri:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- Yürütme sırasında büyük miktarda depolama etkileşimi
+- Depoya kaydedilecek büyük miktarda veri
+- İşlenecek büyük miktarda olay
+- Kalabalık düğümler için yavaş veritabanı bağlantı süresi
+- Sağlayıcının zincir başından geriye düşmesi
+- Sağlayıcıdan zincir başındaki yeni makbuzların alınmasındaki yavaşlık
+
+Subgraph indeksleme metrikleri, indeksleme yavaşlığının temel nedenini teşhis etmede yardımcı olabilir. Bazı durumlarda, sorun subgraph'ın kendisiyle ilgilidir, ancak diğer durumlarda, geliştirilmiş ağ sağlayıcıları, azaltılmış veritabanı çekişmesi ve diğer yapılandırma iyileştirmeleri indeksleme performansını belirgin şekilde artırabilir.
+
+#### Başarısıız subgraphlar
+
+İndekslemesi sırasında subgraphlar beklenmedik veri, beklendiği gibi çalışmayan bir bileşen veya olay işleyicilerinde veya yapılandırmada bir hata olması durumunda başarısız olabilir. İki genel başarısızlık türü mevcuttur:
+
+- Deterministik başarısızlıklar: Bu, yeniden denemelerle çözülmeyecek hatalardır
+- Deterministik olmayan başarısızlıklar: Bunlar, sağlayıcının sorunları veya beklenmedik bir Graph Düğüm hatası gibi nedenlere bağlı olabilir. Deterministik olmayan bir başarısızlık meydana geldiğinde Graph Düğümü, başarısız olan işleyicileri yeniden deneyecek ve zamanla geri çekilecektir.
+
+Bazı durumlarda, başarısızlık indeksleyici tarafından çözülebilir (örneğin, hatanın doğru türde sağlayıcıya sahip olmamasından kaynaklanması durumunda, gerekli sağlayıcı eklenirse indeksleme devam ettirilebilir). Ancak diğer durumlarda, subgraph kodunda bir değişiklik gereklidir.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Blok ve çağrı önbelleği
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+Örneğin tx makbuzu etkinlik eksikliği gibi bir blok önbellek tutarsızlığı şüphesi varsa:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. Blok sağlayıcıyla eşleşirse, sorun doğrudan sağlayıcıya karşı hata ayıklanabilir.
+
+#### Sorgulama sorunları ve hataları
+
+Bir subgraph indekslendikten sonra, indeksleyiciler subgraph'ın ayrılmış sorgu son noktası aracılığıyla sorguları sunmayı bekleyebilirler. İndeksleyiciler önemli sorgu hacmi sunmayı umuyorlarsa, bunun için ayrılmış bir sorgu düğümü önerilir ve çok yüksek sorgu hacimleri durumunda indeksleyiciler sorguların indeksleme sürecini etkilememesi için replika shardlar yapılandırmak isteyebilirler.
+
+Bununla birlikte, özel bir sorgu düğümü ve replikalarda bile, belirli sorguların yürütülmesi uzun zaman alabilir, bazı durumlarda bellek kullanımını artırabilir ve diğer kullanıcılar için sorgu süresini olumsuz etkileyebilir.
+
+Tek bir "sihirli çözüm" yoktur, ancak yavaş sorguların önlenmesi, teşhisi ve işlenmesi için bir dizi araç bulunmaktadır.
+
+##### Sorgu önbellekleme
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Sorguların analizi
+
+Sorunlu sorgular genellikle iki şekilde ortaya çıkar. Bazı durumlarda, kullanıcılar kendileri belirli bir sorgunun yavaş olduğunu bildirirler. Bu durumda zorluk, yavaşlığın nedenini teşhis etmektir - genel bir sorun mu, yoksa subgraph'a veya sorguya özgü mü olduğunu belirlemek ve tabii ki mümkünse sonra çözmek olacaktır.
+
+Diğer durumlarda, tetikleyici sorgu düğümündee yüksek bellek kullanımı olabilir, bu durumda zorluk ilk olarak soruna neden olan sorguyu belirlemektir.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Yavaş bir sorgu verildiğinde, indeksleyicilerin birkaç seçeneği vardır. Tabii ki, sorunlu sorgunun gönderilme maliyetini önemli ölçüde artırmak için maliyet modelini değiştirebilirler. Bu, o sorgunun sıklığında azalmaya neden olabilir. Ancak, genellikle sorunun temek nedenini çözmez.
+
+##### Hesabımsı optimizasyon
+
+Varlıkları depolayan veritabanı tablolarının genellikle iki çeşit olduğu görünmektedir: oluşturulduktan sonra hiçbir zaman güncellenmeyen mesela finansal işlemler listesine benzer şeyler saklayan olan 'işlemimsi' ve varlıkların çok sık güncellendiği, mesela her işlem kaydedildiğinde değiştirilen finansal hesaplar gibi şeyler saklayan 'hesabımsı'. Hesabımsı tablolar, birçok varlık sürümünü içermelerine rağmen, nispeten az sayıda farklı varlığa sahip olmasıyla bilinir. Çoğu durumda, böyle bir tabloda farklı varlık sayısı, toplam satır (varlık sürümleri) sayısının %1'ine eşittir
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Subgraphları kaldırma
+
+> Bu, Graph Node 0.29.x sürümünde kullanılabilir olan yeni bir fonksiyonelliktir
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 11617474054ddaf8cd24943f79ce57eec6695a84 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:11 -0500
Subject: [PATCH 0871/3820] New translations advanced.mdx (Turkish)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/tr/subgraphs/developing/creating/advanced.mdx b/website/pages/tr/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..cb3b29560228
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Genel Bakış
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Zaman Serileri ve Toplulaştırmalar
+
+Zaman serileri ve toplulaştırmalar, subgraph'inizin günlük ortalama fiyat, saatlik toplam transferler gibi istatistikleri takip etmesini sağlar.
+
+Bu özellik, iki yeni subgraph varlık türünü tanıtır. Zaman Serisi varlıkları, zaman damgaları ile veri noktalarını kaydeder. Toplulaştırma varlıkları ise saatlik veya günlük bazda Zaman Serisi veri noktaları üzerinde önceden belirlenmiş hesaplamalar yapar ve sonuçları GraphQL üzerinden kolay erişim için saklar.
+
+### Örnek Şema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Zaman Serileri ve Toplulaştırmaları Tanımlama
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Mevcut Toplulaştırma Aralıkları
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Mevcut Toplulaştırma Fonksiyonları
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Örnek Toplulaştırmalar Sorgusu
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Not:
+
+Zaman Serisi ve Toplulaştırmalar özelliklerini kullanmak için, subgraph’inizin spec sürümü ≥1.1.0 olmalıdır. Bu özelliğin, geriye dönük uyumluluğu etkileyebilecek önemli değişikliklerden geçebileceğini unutmayın.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Ölümcül Olmayan Hatalar
+
+Halihazırda senkronize edilmiş subgraphlarda indeksleme hataları varsayılan olarak subgraph başarısız olmasına ve senkronizasyonun durmasına neden olur. Hatalara rağmen senkronizasyonun devam etmesi için subgraphlar, hata tetikleyen işleyicinin yapılan değişikliklerini yok sayarak yapılandırılabilir. Bu, subgraph yazarlarının subgraphlarını düzeltmeleri için zaman kazandırırken, sorguların en son blokta sunulmaya devam etmesini sağlar, ancak hata nedeniyle sonuçlar tutarsız olabilir. Bazı hatalar hala her zaman ölümcül olacaktır. Ölümcül olmaması için hatanın belirlenmiş olması gerekmektedir.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Ölümcül olmayan hataların etkinleştirilmesi, subgraph manifestinde aşağıdaki özellik bayrağının ayarlanmasını gerektirir:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave Dosya Veri Kaynakları
+
+Dosya veri kaynakları, indeksleme sırasında zincir dışı verilere sağlam ve genişletilebilir bir şekilde erişmek için yeni bir subgraph fonksiyonudur. Dosya veri kaynakları IPFS'den ve Arweave'den dosya getirmeyi desteklemektedir.
+
+> Bu aynı zamanda zincir dışı verilerinin belirlenebilir indekslenmesi için zemin hazırlar ve keyfi HTTP kaynaklı verilerin tanıtılma potansiyelini de beraberinde getirir.
+
+### Genel Bakış
+
+İşleyici yürütülürken dosyaları “sıra sıra” almak yerine, Dosya Veri Kaynakları, belirli bir dosya kimliği için yeni veri kaynakları olarak kullanılabilecek şablonlar sunar. Bu yeni veri kaynakları dosyaları getirir. Başarısız olurlarsa yeniden denerler ve dosya bulunduğunda bu işe mahsus bir işleyici çalıştırırlar.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Yükseltme rehberi
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Dosyalar bulunduğunda güncellenecek yeni bir varlık türü ekleyin
+
+Dosya veri kaynakları zincir tabanlı varlıklara erişemez veya bunları güncelleyemez, ancak dosya belirli varlıkları güncellemelidir.
+
+Bu, mevcut varlıklardaki alanları ayrı varlıklara bölmeyi gerektirebilir ve bunlar birbirine bağlanabilir.
+
+Özgün birleştirilmiş varlık:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+Yeni, ayrılmış varlık:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+Ana varlık ve sonuç dosya veri kaynak varlığı arasındaki ilişki bire bir ise, en basit kalıp, IPFS CID'yi arama anahtarı olarak kullanarak ana varlığını sonuç dosya varlığına bağlamaktır. Yeni dosya tabanlı varlıklarınızın modellemesiyle ilgili sorun yaşarsanız Discord üzerinden iletişime geçin!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+Bu, ilgi alanı dosyası tespit edildiğinde oluşturulacak veri kaynağıdır.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Dosyaları işlemek için yeni bir işleyici oluşturun
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Örnek işleyici:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Gerektiğinde dosya veri kaynakları oluşturun
+
+Artık zincir tabanlı işleyicilerin yürütülmesi sırasında dosya veri kaynakları oluşturabilirsiniz:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Örnek:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//Bu örnek kod, bir Crypto coven subgraph'ı içindir. Yukarıdaki ipfs hash'ı, tüm kripto NFT'leri için token üst verilerine sahip bir dizindir.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //Bu, tek bir Crypto coven NFT için üst verilere giden bir yol oluşturur. Dizini "/" + dosya adı + ".json" ile birleştirir.
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+Bu, Graph Düğümü'nün yapılandırılmış IPFS veya Arweave uç noktasını sorgulayacak yeni bir veri kaynağı dosyası oluşturacak ve bulunamazsa yeniden deneyecek. Dosya bulunduğunda, dosya veri kaynağı işleyicisi çalıştırılacaktır.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Tebrikler, dosya veri kaynaklarını kullanıyorsunuz!
+
+#### Subgraph'ınızı dağıtma
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Sınırlamalar
+
+Dosya veri kaynağı işleyicileri ve varlıkları yürütüldüklerinde belirleyici olmaları ve zincir tabanlı veri kaynaklarının bozulmasını önlemeleri için, diğer subgraph varlıklarından izole edilir,. Açıkça şunlardır:
+
+- Dosya Veri Kaynakları tarafından oluşturulan varlıklar değiştirilemez ve güncellenemez
+- Dosya Veri Kaynağı işleyicileri, diğer dosya veri kaynaklarından varlıklara erişemez
+- Dosya Veri Kaynaklarıyla ilişkili varlıklara zincir tabanlı işleyicilerden erişilemez
+
+> Bu kısıtlama çoğu kullanım durumu için sorun oluşturmamalıdır, ancak bazı durumlarda karmaşıklıklığa sebep olabilir. Dosya tabanlı verilerinizi bir subgraph'ta modellemekte zorluk yaşarsanız, lütfen Discord üzerinden bizimle iletişime geçin!
+
+Ek olarak, zincir üstü bir veri kaynağı veya başka bir dosya veri kaynağı olsun, bir dosya veri kaynağından veri kaynakları oluşturmak mümkün değildir. Bu kısıtlama gelecekte kaldırılabilir.
+
+#### En iyi uygulamalar
+
+NFT meta verilerini ilgili tokenleri bağlarken, Üst veri varlığına Token varlığından başvurmak için üst verinin IPFS hash değerini kullanın. Üst veri varlığını IPFS hash değerini bir kimlik olarak kullanarak kaydedin.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> Yukarıdaki öneriyi geliştirmeye çalışıyoruz, bu nedenle sorgular yalnızca "en son" sürümü döndürür
+
+#### Bilinen Sorunlar
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Örnekler
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### Referanslar
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Endekslenmiş Argüman Filtreleri / Konu Filtreleri
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Konu filtreleri veya endekslenmiş argüman filtreleri olarak da bilinen bu özellik, subgraph'lerin endekslenmiş argümanlarının değerlerine göre blok zinciri olaylarını hassas bir şekilde filtrelemesine olanak tanır.
+
+- Bu filtreler, blokzincirindeki büyük olay akışından ilgilenilen belirli olayları izole etmeye yardımcı olarak, subgraph'lerin yalnızca alakalı verilere odaklanmasını ve böylece daha verimli çalışmasını sağlar.
+
+- Bu özellik, belirli adresleri ve bunların blokzincirindeki çeşitli akıllı sözleşmelerle olan etkileşimlerini izleyen kişisel subgraph'ler oluşturmak için faydalıdır.
+
+### Konu Filtreleri Nasıl Çalışır
+
+Bir akıllı sözleşme olay yaydığında, endekslenmiş olarak işaretlenen tüm argümanlar bir subgraph'in manifestosunda filtre olarak kullanılabilir. Bu durum, subgraph'in yalnızca ilgili endekslenmiş argümanlara uyan olayları dinleyip diğerlerini görmezden gelmesini sağlar.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Adresler için endekslenmiş parametreleriyle birlikte olay bildirimi
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Token transferini simüle eden fonksiyon
+    function transfer(address to, uint256 value) public {
+        // Transfer olayını from, to ve value ile yayma
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+Bu örnekte:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Subgraph'lerde Yapılandırma
+
+Konu filtreleri, subgraph manifestosunda doğrudan olay işleyici yapılandırması içinde tanımlanır. Yapılandırma örneği:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+Bu bağlamda:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Her konu (topic) bir veya daha fazla değere sahip olabilir ve bir olay yalnızca karşılık geldiği konudaki değerlerden biriyle eşleşiyorsa işlenir.
+
+#### Filtre Mantığı
+
+- Tek Bir Konu İçinde: VEYA koşulu olarak çalışır. Olay, verilen konunun listesindeki herhangi bir değerle eşleşirse işlenecektir.
+- Farklı Konular Arasında: VE koşulu olarak çalışır. Bir olayın ilgili işleyiciyi tetiklemesi için farklı konular arasındaki belirlenmiş tüm koşulları karşılaması gerekir.
+
+#### Örnek 1: Adres A'dan Adres B'ye Doğrudan Transferleri Takip Etme
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+Bu konfigürasyonda:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Örnek 2: İki veya Daha Fazla Adres Arasında Her İki Yönde Gerçekleşen İşlemleri Takip Etme
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+Bu konfigürasyonda:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- Subgraph, birden fazla adres arasında her iki yönde gerçekleşen işlemleri endeksleyerek tüm adresleri içeren etkileşimlerin kapsamlı bir şekilde izlenmesini sağlar.
+
+## Deklare edilmiş eth_call
+
+> Not: Bu, henüz stabil bir Graph Düğümü sürümünde mevcut olmayan deneysel bir özelliktir. Yalnızca Subgraph Studio'da veya sağlayıcılığını kendiniz yaptığınız düğümünüzde kullanabilirsiniz.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+Bu özellik:
+
+- Ethereum blokzincirinden veri getirme performansını önemli ölçüde artırır. Bunu birden fazla çağrı için toplam süreyi azaltarak ve subgraph'in genel verimliliğini optimize ederek yapar.
+- Daha hızlı veri çekmeye olanak tanıyarak, daha hızlı sorgu yanıtları alınmasını ve daha iyi bir kullanıcı deneyimi sağlar.
+- Birden fazla Ethereum çağrısından veri toplaması gereken uygulamalar için bekleme sürelerini azaltarak veri çekme sürecini daha verimli hale getirir.
+
+### Ana Kavramlar
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Paralel Yürütme: Bir çağrıyı başlatmak için diğerinin bitmesini beklemek yerine, birden fazla çağrı aynı anda başlatılabilir.
+- Zaman Verimliliği: Tüm çağrılar için geçen toplam süre, bireysel çağrı sürelerinin toplamından (işlemler ardışık yapıldığında), en uzun çağrının süresine dönüşür (işlemler paralel yapıldığında).
+
+#### Scenario without Declarative `eth_calls`
+
+Bir kullanıcının işlemleri, bakiyesi ve token varlıkları hakkında veri almak için üç Ethereum çağrısı yapması gereken bir subgraph'iniz olduğunu düşünün.
+
+Geleneksel olarak, bu çağrılar ardışık olarak yapılabilir:
+
+1. Çağrı 1 (İşlem geçmişi): 3 saniye sürer
+2. Çağrı 2 (Bakiye): 2 saniye sürer
+3. Çağrı 3 (Token varlıkları): 4 saniye sürer
+
+Toplam geçen süre = 3 + 2 + 4 = 9 saniye
+
+#### Scenario with Declarative `eth_calls`
+
+Bu özellik sayesinde bu çağrıların paralel olarak gerçekleştirileceğini belirtebilirsiniz:
+
+1. Çağrı 1 (İşlem geçmişi): 3 saniye sürer
+2. Çağrı 2 (Bakiye): 2 saniye sürer
+3. Çağrı 3 (Token varlıkları): 4 saniye sürer
+
+Bu çağrılar paralel olarak yürütüldüğünden, toplam süre en uzun süren çağrının süresine eşittir.
+
+Toplam süre = max (3, 2, 4) = 4 saniye
+
+#### Nasıl Çalışır
+
+1. Bildirimsel Tanım: Subgraph manifestosunda, Ethereum çağrılarını paralel olarak çalıştırılabilecek şekilde tanımlarsınız.
+2. Paralel Çalıştırma Motoru: Graph Düğümü'nün yürütme motoru bu bildirimleri tanır ve çağrıları aynı anda çalıştırır.
+3. Sonuçların Birleştirilmesi: Tüm çağrılar tamamlandığında, sonuçlar birleştirilir ve sonraki işlemler için subgraph tarafından kullanılır.
+
+#### Subgraph Manifestosunda Örnek Yapılandırma
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Yukarıdaki örnek için detaylar:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Mevcut Subgraph'ta Graftlama
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Graftlama, temel verileri indekslemek yerine kopyaladığından, subgraph'ı istenen bloğa getirmek sıfırdan indekslemeye nazaran çok daha hızlıdır, ancak ilk veri kopyası çok büyük subgraphlar için yine birkaç saat sürebilir. Graftlanmış subgraph başlatılırken, Graph Düğümü halihazırda kopyalanmış olan varlık türleri hakkında bilgileri kaydedecektir.
+
+Graftlanan subgraph, temel subgraphla tamamen aynı olmayan, ancak onunla uyumlu olan bir GraphQL şeması kullanabilir. Kendi başına geçerli bir subgraph şeması olmalıdır, ancak şu şekillerde temel subgraph şemasından sapabilir:
+
+- Varlık türlerini ekler veya kaldırır
+- Varlık türlerinden öznitelikleri kaldırır
+- Varlık türlerine null yapılabilir öznitelikler ekler
+- Null yapılamayan öznitelikleri null yapılabilir özniteliklere dönüştürür
+- Numaralandırmalara değerler ekler
+- Arayüzleri ekler veya kaldırır
+- Arayüzün hangi varlık türleri için uygulandığını değiştirir
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 5019006edd3652b6f73dbd8bc7bcebd798a7d273 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:13 -0500
Subject: [PATCH 0872/3820] New translations api.mdx (Turkish)

---
 .../developing/creating/graph-ts/api.mdx      | 891 ++++++++++++++++++
 1 file changed, 891 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/tr/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/tr/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..bda6a0f67c61
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,891 @@
+---
+title: AssemblyScript API'si
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Subgraph eşlemeleri yazarken kullanılabilecek yerleşik API'leri öğrenin. Hazır olarak sunulan iki tür API mevcuttur:
+
+- [Graph TypeScript kütüphanesi](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Subgraph dosyalarından `graph codegen` tarafından üretilen kod
+
+[AssemblyScript](https://github.com/AssemblyScript/assemblyscript) ile uyumlu olduğu sürece diğer kütüphaneleri de bağımlılık olarak ekleyebilirsiniz.
+
+Dil eşlemeleri AssemblyScript ile yazıldığından, [AssemblyScript wiki'sindeki](https://github.com/AssemblyScript/assemblyscript/wiki) dil ve standart kütüphane özelliklerini gözden geçirmek faydalı olacaktır.
+
+## API Referansı
+
+`@graphprotocol/graph-ts` kütüphanesi aşağıdaki API'leri sağlar:
+
+- Ethereum akıllı sözleşmeleri, olaylar, bloklar, işlemler ve Ethereum değerleriyle çalışmak için bir `ethereum` API'si.
+- Varlıkları Graph Düğümü deposundan yüklemek ve depoya kaydetmek için bir `store` API'si.
+- Graph Düğümü çıktısına ve Graph Gezgini'ne mesaj kaydetmek için bir `log` API'si.
+- IPFS'ten dosyaları yüklemek için bir `ipfs` API'si.
+- JSON verilerini ayrıştırmak için bir `json` API'si.
+- Kriptografik fonksiyonları kullanmak için bir `crypto` API'si.
+- Ethereum, JSON, GraphQL ve AssemblyScript gibi farklı tip sistemler arası çeviri yapmak için düşük seviyeli yazılımlar.
+
+### Sürümler
+
+Subgraph manifestosundaki `apiVersion`, bir subgraph için Graph Düğümü tarafından çalıştırılan eşleme (mapping) API'sinin sürümünü belirtir.
+
+| Sürüm | Sürüm Notları                                                                                                                                                                                                                                            |
+| :---: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0.0.9 | Yeni host fonksiyonları ekler: [`eth_get_balance`](#balance-of-an-address) ve [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                     |
+| 0.0.8 | Bir varlığı kaydederken şemadaki alanların varlığını doğrulama mekanizması ekler.                                                                                                                                                                        |
+| 0.0.7 | Ethereum türlerine `TransactionReceipt` ve `Log` sınıfları eklendi<br />Ethereum Event nesnesine `receipt` alanı eklendi                                                                                                                                 |
+| 0.0.6 | Ethereum Transaction nesnesine `nonce` alanı eklendi<br />Ethereum Block nesnesine `baseFeePerGas` eklendi                                                                                                                                               |
+| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+| 0.0.4 | Ethereum SmartContractCall nesnesine `functionSignature` alanı eklendi                                                                                                                                                                                   |
+| 0.0.3 | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+| 0.0.2 | Ethereum Transaction nesnesine `input` alanı eklendi                                                                                                                                                                                                     |
+
+### Dahili Türler
+
+AssemblyScript'e yerleşik olan temel türler hakkında dökümantasyona [AssemblyScript wiki'sinden](https://www.assemblyscript.org/types.html) ulaşabilirsiniz.
+
+Aşağıdaki ek türler `@graphprotocol/graph-ts` tarafından sağlanmaktadır.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray`, bir `u8` dizisini temsil eder.
+
+_Oluşturma_
+
+- `fromI32(x: i32): ByteArray` - `x` değerini baytlara ayrıştırır.
+- `fromHexString(hex: string): ByteArray` - Girdi uzunluğu çift sayı olmalıdır. `0x` ile başlatmak isteğe bağlıdır.
+
+_Tür Dönüşümleri_
+
+- `toHexString(): string` - On altılık tabanda bir dizeye (hex string) dönüştürür ve `0x` öneki ekler.
+- `toString(): string` - Baytları UTF-8 dizesi olarak yorumlar.
+- `toBase58(): string` - Baytları base58 dizesine kodlar.
+- `toU32(): u32` - Baytları little-endian bir `u32` olarak yorumlar. Aşım durumunda hata verir.
+- `toI32(): i32` - Bayt dizisini little-endian bir `i32` olarak yorumlar. Aşım durumunda hata verir.
+
+_Operatörler_
+
+- `equals(y: ByteArray): bool` – `x == y` olarak yazılabilir.
+- `concat(other: ByteArray): ByteArray` - `this` dizisinin sonuna `other` dizisini ekleyerek yeni bir `ByteArray` döner.
+- `concatI32(other: i32): ByteArray` - `this` dizisinin sonuna `other`'ın bayt temsili ekleyerek yeni bir `ByteArray` döner.
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal`, ondalık sayıları istenildiği kadar doğrulukta temsil etmek için kullanılır.
+
+> Not: [Dahili olarak](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal`, [IEEE-754 decimal128 floating-point formatında](https://en.wikipedia.org/wiki/Decimal128_floating-point_format) saklanır ve bu format 34 ondalık basamağa kadar destek sunar. Bu durum, `BigDecimal`'i, 34 basamağı aşabilen sabit noktalı türleri temsil etmek için (örneğin Solidity'deki [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) gibi) uygun olmaktan çıkarır.
+
+_Oluşturma_
+
+- `constructor(bigInt: BigInt)` – Bir `BigInt`'ten bir `BigDecimal` oluşturur.
+- `static fromString(s: string): BigDecimal` – Ondalık bir dizeyi ayrıştırır.
+
+_Tür Dönüşümleri_
+
+- `toString(): string` – Ondalık bir dize olarak yazdırır.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – `x + y` şeklinde yazılabilir.
+- `minus(y: BigDecimal): BigDecimal` – `x - y` şeklinde yazılabilir.
+- `times(y: BigDecimal): BigDecimal` – `x * y` şeklinde yazılabilir.
+- `div(y: BigDecimal): BigDecimal` – `x / y` şeklinde yazılabilir.
+- `equals(y: BigDecimal): bool` – `x == y` şeklinde yazılabilir.
+- `notEqual(y: BigDecimal): bool` – `x != y` şeklinde yazılabilir.
+- `lt(y: BigDecimal): bool` – `x < y` şeklinde yazılabilir.
+- `le(y: BigDecimal): bool` – `x <= y` şeklinde yazılabilir.
+- `gt(y: BigDecimal): bool` – `x > y` şeklinde yazılabilir.
+- `ge(y: BigDecimal): bool` – `x >= y` şeklinde yazılabilir.
+- `neg(): BigDecimal` - `-x` şeklinde yazılabilir.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt`, büyük tam sayıları temsil etmek için kullanılır. Buna, Ethereum'daki `uint32` ile `uint256` ve `int64` ile `int256` türlerindeki değerler dahildir. `uint32`'nin altındaki her şey, örneğin `int32`, `uint24` veya `int8`, `i32` olarak temsil edilir.
+
+`BigInt` sınıfı aşağıdaki API'ye sahiptir:
+
+_Oluşturma_
+
+- `BigInt.fromI32(x: i32): BigInt` – Bir `i32`'den bir `BigInt` oluşturur.
+
+- `BigInt.fromString(s: string): BigInt` – Bir dizeden bir `BigInt` oluşturur.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – `bytes`'i işaretsiz, little-endian bir tamsayı olarak yorumlar. Girdiniz big-endian ise önce `.reverse()` metodunu kullanın.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – `bytes`'i işaretli, little-endian bir tamsayı olarak yorumlar. Girdiniz big-endian ise önce `.reverse()` metodunu kullanın.
+
+  _Tür Dönüşümleri_
+
+- `x.toHex(): dize` – `BigInt`'i on altılık tabanda bir karakter dizesine dönüştürür.
+
+- `x.toString(): dize` – `BigInt`'i ondalık tabanda bir dizeye dönüştürür.
+
+- `x.toI32(): i32` – `BigInt`'i bir `i32` olarak döndürür, değer `i32`'ye sığmazsa hata verir. İlk olarak `x.isI32()` kontrolünü yapmanız önerilir.
+
+- `x.toBigDecimal(): BigDecimal` – Kesirli kısmı olmayan bir ondalık sayıya dönüştürür.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – `x + y` şeklinde yazılabilir.
+- `x.minus(y: BigInt): BigInt` – `x - y` şeklinde yazılabilir.
+- `x.times(y: BigInt): BigInt` – `x * y` şeklinde yazılabilir.
+- `x.div(y: BigInt): BigInt` – `x / y` şeklinde yazılabilir.
+- `x.mod(y: BigInt): BigInt` – `x % y` şeklinde yazılabilir.
+- `x.equals(y: BigInt): bool` – `x == y` şeklinde yazılabilir.
+- `x.notEqual(y: BigInt): bool` – `x != y` şeklinde yazılabilir.
+- `x.lt(y: BigInt): bool` – `x < y` şeklinde yazılabilir.
+- `x.le(y: BigInt): bool` – `x <= y` şeklinde yazılabilir.
+- `x.gt(y: BigInt): bool` – `x > y` şeklinde yazılabilir.
+- `x.ge(y: BigInt): bool` – `x >= y` şeklinde yazılabilir.
+- `x.neg(): BigInt` – `-x` şeklinde yazılabilir.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – Ondalık bir sayı ile böler ve ondalık bir sonuç döndürür.
+- `x.isZero(): bool` – Sayının sıfır olup olmadığını kontrol etmek için kullanışlı bir metot.
+- `x.isI32(): bool` – Sayının bir `i32`'ye sığıp sığmadığını kontrol eder.
+- `x.abs(): BigInt` – Mutlak değer.
+- `x.pow(exp: u8): BigInt` – Üs alma işlemi.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – `x | y` olarak yazılabilir.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – `x & y` şeklinde yazılabilir.
+- `leftShift(x: BigInt, bits: u8): BigInt` – `x << y` şeklinde yazılabilir.
+- `rightShift(x: BigInt, bits: u8): BigInt` – `x >> y` şeklinde yazılabilir.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap`, anahtar-değer çiftlerini saklamak için kullanılabilir. [Bu örneği](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51) inceleyebilirsiniz.
+
+`TypedMap` sınıfının API'si aşağıdaki gibidir:
+
+- `new TypedMap<K, V>()` – `K` türünde anahtarlar ve `V` türünde değerler içeren boş bir eşlem oluşturur
+- `map.set(key: K, value: V): void` – `key` anahtarının değerini `value` olarak ayarlar
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – `key` için anahtar-değer çiftini döndürür, eğer `key` eşlemde mevcut değilse `null` döner
+- `map.get(key: K): V | null` – `key` için değeri döndürür, eğer `key` eşlemde mevcut değilse `null` döner
+- `map.isSet(key: K): bool` – Eğer `key` eşlemde mevcutsa `true`, değilse `false` döner
+
+#### Baytlar
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes`, keyfi uzunluktaki bayt dizilerini temsil etmek için kullanılır. Buna Ethereum'daki `bytes`, `bytes32` gibi türler dahildir.
+
+`Bytes` sınıfı, AssemblyScript'in [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) sınıfını genişletir ve `Uint8Array`'in tüm işlevselliğini destekler. Buna ek olarak, aşağıdaki yeni metotlara sahiptir:
+
+_Oluşturma_
+
+- `fromHexString(hex: string): Bytes` – `hex` dizesini, on altı tabanında çift sayıda basamaktan oluşması koşuluyla bir `ByteArray`'e dönüştürür. `hex` dizesi isteğe bağlı olarak `0x` ile başlayabilir
+- `fromI32(i: i32): Bytes` – `i` değerini bir bayt dizisine dönüştürür
+
+_Tür Dönüşümleri_
+
+- `b.toHex()` – dizideki baytları temsil eden on altı tabanında bir dize döndürür
+- `b.toString()` – dizideki baytları Unicode karakterlerinden oluşan bir dizeye dönüştürür
+- `b.toBase58()` – bir Ethereum Bytes değerini base58 kodlamasına (IPFS hash'leri için kullanılır) dönüştürür
+
+_Operatörler_
+
+- `b.concat(other: Bytes): Bytes` – `this` dizisinin sonuna `other` dizisini ekleyerek yeni bir `Bytes` döndürür
+- `b.concatI32(other: i32): ByteArray` – `this` dizisinin sonrasına `other`'ın bayt temsilini eklenerek yeni bir `Bytes` döndürür
+
+#### Adres(Address)
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address`, Ethereum `address` değerlerini temsil etmek için `Bytes` sınıfını genişletir.
+
+`Bytes` API'sine ek olarak aşağıdaki metotları sağlar:
+
+- `Address.fromString(s: dize): Address` – On altılık tabanda bir dizeden bir `Address` oluşturur
+- `Address.fromBytes(b: Bytes): Address` – Tam olarak 20 bayt uzunluğunda olması gereken `b` dizisinden bir `Address` oluşturur. Daha az veya daha fazla bayt içeren bir değer geçildiğinde hata verir
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+`store` API'si, varlıkları Graph Düğümü deposundan yüklemeye, depoya kaydetmeye ve depodan kaldırmaya olanak tanır.
+
+Depoya yazılan varlıklar, subgraph'in GraphQL şemasında tanımlanan `@entity` türleriyle bire bir eşleşir. Bu varlıklarla çalışmayı kolaylaştırmak için [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) tarafından sağlanan `graph codegen` komutu varlık sınıfları oluşturur. Varlık sınıfları, şemadaki alanlar için özellik alıcıları ve ayarlayıcılarının yanı sıra bu varlıkları yüklemek ve kaydetmek için metotlar içeren, yerleşik `Entity` türünün alt sınıflarıdır.
+
+#### Unsurların Oluşturulması
+
+Aşağıdaki, Ethereum olaylarından varlıklar oluşturmak için yaygın bir modeldir.
+
+```typescript
+// ERC20 ABI'dan oluşturulan Transfer olay sınıfını içe aktarın
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// GraphQL şemasından oluşturulan Transfer varlık türünü içe aktarın
+import { Transfer } from '../generated/schema'
+
+// Transfer olayı işleyicisi
+export function handleTransfer(event: TransferEvent): void {
+  // İşlem hash'ını olay kimliği olarak kullanarak bir Transfer varlığı oluşturun
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+  
+  // Olay parametrelerini kullanarak varlığın özelliklerini ayarlayın
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+  
+  // Varlığı depoya kaydedin
+  transfer.save()
+  }
+```
+
+Zincir işlenirken bir `Transfer` olayıyla karşılaşıldığında, oluşturulan `Transfer` türü (burada varlık türüyle adlandırma çakışmasını önlemek için `TransferEvent` olarak adlandırılmıştır) kullanılarak `handleTransfer` olay işleyicisine aktarılır. Bu tür, olayın ana işlemi ve parametreleri gibi verilere erişim sağlar.
+
+Her varlık, diğer varlıklarla çakışmayı önlemek için benzersiz bir ID'ye sahip olmalıdır. Genellikle olay parametrelerinin içinde bu iş için kullanılabilecek benzersiz bir tanımlayıcı bulunur.
+
+> Not: ID olarak işlem hash'ini kullanmak, aynı işlemdeki diğer olayların bu hash'i ID olarak kullanarak varlık oluşturmadığını varsayar.
+
+#### Depodan varlık yükleme
+
+Bir varlık mevcutsa aiağıdaki kod kullanılarak depodan yüklenebilir:
+
+```typescript
+let id = event.transaction.hash // veya kimlik(ID) nasıl oluşturulmuşsa
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Transfer varlığı önceki gibi kullanılır
+```
+
+Varlık henüz depoda mevcut olmayabileceğinden, `load` yöntemi `Transfer | null` türünde bir değer döndürür. Değeri kullanmadan önce `null` olup olmadığını kontrol etmek gerekebilir.
+
+> Not: Varlıkları yüklemek, yalnızca, eşlemede yapılan değişikliklerin bir varlığın önceki verilerine bağlı olması durumunda gereklidir. Mevcut varlıkları güncellemenin iki yolunu görmek için bir sonraki bölüme bakın.
+
+#### Bir blok içinde oluşturulan varlıkları arama
+
+`graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 ve `@graphprotocol/graph-cli` v0.49.0 itibarıyla `loadInBlock` metodu tüm varlık türlerinde kullanılabilir hale gelmiştir.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- Eğer işlem mevcut değilse subgraph sırf varlığın mevcut olmadığını öğrenmek için veritabanına başvurmak zorunda kalacaktır. Ancak, subgraph yazarı varlığın aynı blokta oluşturulmuş olması gerektiğini zaten biliyorsa, `loadInBlock` kullanmak bu veritabanı sorgusunu ortadan kaldırır.
+- Bazı subgraph'lerde bu başarısız aramalar endeksleme süresine önemli ölçüde etki edebilir.
+
+```typescript
+let id = event.transaction.hash // veya ID nasıl oluşturulurmuşsa
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Transfer varlığını daha önce olduğu gibi kullanın
+```
+
+> Not: Belirtilen blokta bir varlık oluşturulmadıysa, depoda verilen ID'ye sahip bir varlık olsa bile `loadInBlock` yöntemi `null` döndürecektir.
+
+#### Türetilmiş varlıkları arama
+
+`graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 ve `@graphprotocol/graph-cli` v0.51.0 itibarıyla, `loadRelated` metodu kullanılabilir hale gelmiştir.
+
+Bu, türetilmiş varlık alanlarının bir olay işleyicisi içinden yüklenmesini sağlar. Örneğin, aşağıdaki şema göz önüne alındığında:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+Aşağıdaki kod, `Holder` varlığının türetildiği `Token` varlığını yükleyecektir:
+
+```typescript
+let holder = Holder.load('test-id')
+// Belirli bir sahiple ilişkili Token unsurlarını yükleyin
+let tokens = holder.tokens.load()
+```
+
+#### Mevcut varlıkları güncelleme
+
+Mevcut bir varlığı güncellemenin iki yolu vardır:
+
+1. `Transfer.load(id)` ya da benzeri bir metotla varlığı yükleyin, varlık üzerindeki özellikleri ayarlayın ve ardından `.save()` ile tekrar depoya kaydedin.
+2. `new Transfer(id)` ya da benzeri bir metotla varlığı oluşturun, varlık üzerindeki özellikleri ayarlayın ve ardından `.save()` ile depoya kaydedin. Eğer varlık zaten mevcutsa, yapılan değişiklikler mevcut varlıkla birleştirilir.
+
+Oluşturulan özellik ayarlayıcılar sayesinde çoğu durumda özellikerin değiştirilmesi kolaydır:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+Ayrıca aşağıdaki iki talimattan biriyle özellikleri kaldırmakta mümkündür:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+Bu yalnızca isteğe bağlı özelliklerle çalışır, yani GraphQL'de `!` olmadan tanımlanan özelliklerle. Örnek olarak, `owner: Bytes` veya `amount: BigInt` verilebilir.
+
+Dizi özelliklerini güncellemek biraz daha karmaşıktır, çünkü bir varlıktan bir dizi almak, o dizinin bir kopyasını oluşturur. Bu sebeple diziyi değiştirdikten sonra dizi özelliklerinin tekrar doğrudan ayarlanması gerekmektedir. Aşağıdaki örnek, `entity`nin bir `numbers: [BigInt!]!` alanına sahip olduğunu varsayar.
+
+```typescript
+// Bu işe yaramaz
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// Bu çalışır
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Depodan varlık kaldırma
+
+Şu andabir varlığı oluşturulan türler aracılığıyla kaldırmanın bir yolu yoktur. Bunun yerine, bir varlığı kaldırmak için varlık türünün adını ve varlık ID'sini `store.remove` yöntemine iletmek gerekir:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+Ethereum API'si, akıllı sözleşmelere, genel durum değişkenlerine, sözleşme fonksiyonlarına, olaylara, işlemlere, bloklara ve Ethereum verilerinin kodlama/çözme işlemlerine erişim sağlar.
+
+#### Ethereum Türleri İçin Destek
+
+Varlıklarda olduğu gibi `graph codegen`, bir subgraph'te kullanılan tüm akıllı sözleşmeler ve olaylar için sınıflar oluşturur. Bunun için, sözleşme ABI'lerinin subgraph manifestosundaki veri kaynağının bir parçası olması gerekir. ABI dosyaları genelde `abis/` klasöründe saklanır.
+
+Oluşturulan sınıflarla sayesinde Ethereum türleri ile [yerleşik türler](#built-in-types) arasındaki dönüşümler arka planda gerçekleşir, böylece subgraph yazarlarının bu dönüşümlerle ilgilenmesine gerek kalmaz.
+
+Aşağıdaki örnek bunu açıklar. Aşağıdaki gibi bir subgraph şeması verildiğinde
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+ve Ethereum üzerindeki `Transfer(address,address,uint256)` olay imzası için, sırasıyla `address`, `address` ve `uint256` türlerine sahip`from`, `to` ve `amount` değerleri, `Address` ve `BigInt` türlerine dönüştürülür. Bu sayede, bu değerler `Transfer` varlığındaki `Bytes!` ve `BigInt!` özelliklerine aktarılabilir:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Olaylar ve Blok/İşlem Verileri
+
+Önceki örneklerdeki `Transfer` olayı gibi olay işleyicilere iletilen Ethereum olayları, sadece olay parametrelerine değil, aynı zamanda bu olayların ait olduğu işlem ve blok bilgilerine de erişim sağlar. `event` örneklerinden aşağıdaki veriler elde edilebilir (bu sınıflar `graph-ts` içindeki `ethereum` modülünün bir parçasıdır):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Akıllı Sözleşme Durumuna Erişim
+
+`graph codegen` tarafından oluşturulan kod, subgraph'te kullanılan akıllı sözleşmeler için sınıflar da içerir. Bu sınıflar, mevcut blokta sözleşmenin genel durum değişkenlerine erişmek ve sözleşme fonksiyonlarını çağırmak için kullanılabilir.
+
+Yaygın bir model, bir olayın kaynaklandığı sözleşmeye erişmektir. Bu, aşağıdaki kodla elde edilir:
+
+```typescript
+// Oluşturulan sözleşme sınıfı ve Transfer olayı sınıfını içe aktarın
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Oluşturulan varlık sınıfını içe aktarın
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Sözleşmeyi olayı yayınlayan adresle bağlayın
+  let contract = ERC20Contract.bind(event.address)
+
+  //  Durum değişkenlerine ve işlevlere erişmek için çağrı yapın
+  let erc20Symbol = contract.symbol()
+}
+```
+
+Burada `Transfer`, varlık türüyle adlandırma çakışmasını önlemek için `TransferEvent` olarak yeniden adlandırılmıştır
+
+Ethereum üzerindeki `ERC20Contract` sözleşmesi `symbol` adında herkese açık ve salt okunur bir fonksiyona sahip olduğu sürece, `.symbol()` ile çağrılabilir. Genel durum değişkenleri için otomatik olarak aynı ada sahip bir metot oluşturulur.
+
+Subgraph parçası olan diğer tüm sözleşmelerde oluşturulan koddan içe aktarılabilir ve geçerli bir adrese bağlanabilir.
+
+#### Geri Dönen Çağrıları Yönetme
+
+Eğer sözleşmenizin salt okunur metotlarıının başarısız olması (revert) mümkünse, kodunuzu `try_` öneki ile oluşturulmuş sözleşme metodunu çağırarak çözümleyebilirsiniz (handle).
+
+- Örneğin, Gravity sözleşmesi `gravatarToOwner` metodunu dışa açar. Bu kod, metodun başarısızlıkla sonuçlanmasını (revert) çözümleyebilir:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Not: Geth veya Infura istemcisine bağlı bir Graph Düğümü tüm başarısızlıkları (revert) algılamayabilir. Buna bel bağlıyorsanız Parity istemcisine bağlı bir Graph Düğümü kullanmanızı öneririz.
+
+#### ABI Kodlama/Çözme
+
+Veriler, `ethereum` modülündeki `encode` ve `decode` fonksiyonları kullanılarak Ethereum'un ABI kodlama formatına göre kodlanabilir ve kodu çözülebilir.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+Daha fazla bilgi için:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Kodlama/kod çözme [Rust kütüphanesi/CLI](https://github.com/rust-ethereum/ethabi)
+- Daha [karmaşık bir örnek](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Bir Adresin Bakiyesi
+
+Bir adresin yerel token bakiyesi `ethereum` modülü kullanılarak elde edilebilir. Bu özellik, `subgraph.yaml` dosyasında tanımlanan `apiVersion: 0.0.9` itibarıyla kullanılabilir. `getBalance()` fonksiyonu, belirtilen adresin olayın tetiklendiği blok sonundaki bakiyesini alır.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // bakiyeyi BigInt olarak döndürür
+```
+
+#### Bir Adresin Akıllı Sözleşme veya EOA (Harici Sahipli Hesap) Olup Olmadığını Kontrol Etme
+
+Bir adresin akıllı sözleşme adresi mi yoksa harici sahipli bir adres (EOA) mi olduğunu kontrol etmek için, `ethereum` modülündeki `hasCode()` fonksiyonu kullanılabilir. Bu fonksiyon `boolean` döner. Bu özellik `subgraph.yaml` dosyasında tanımlanan `apiVersion: 0.0.9` itibarıyla kullanılabilir.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // true döndürür
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // false döndürür
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+`log` API'si, subgraph'lerin bilgileri Graph Düğümü standart çıktısına ve Graph Gezgini'ne kaydetmesine olanak tanır. Mesajlar farklı günlük seviyeleri kullanılarak kaydedilebilir. Verilen argümanlardan günlük mesajlarını oluşturmak için temel bir biçimlendirme dizesi sentaksı sunulmaktadır.
+
+`log` API'si aşağıdaki fonksiyonları içerir:
+
+- `log.debug(fmt: string, args: Array<string>): void` – bir hata ayıklama mesajı kaydeder.
+- `log.info(fmt: string, args: Array<string>): void` – bir bilgilendirme mesajı kaydeder.
+- `log.warning(fmt: string, args: Array<string>): void` – bir uyarı mesajı kaydeder.
+- `log.error(fmt: string, args: Array<string>): void` – bir hata mesajı kaydeder.
+- `log.critical(fmt: string, args: Array<string>): void` – kritik bir mesaj kaydeder **ve** subgraph'i sonlandırır.
+
+`log` API'si bir format dizesi ve bir dize değerleri dizisini alır. Daha sonra, dizideki dize değerlerini format dizesindeki yer tutucuların yerine koyar. İlk `{}` yer tutucusu dizideki ilk değerle, ikinci `{}` yer tutucusu ikinci değerle ve bu şekilde devam ederek değiştirilir.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Bir veya daha fazla değerin loglanması
+
+##### Tek bir değerin loglanması
+
+Aşağıdaki örnekte, "A" dize değeri, kaydedilmeden önce bir diziye dönüştürülerek `['A']` haline getirilir:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Görüntüler : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Mevcut bir diziden tek bir girişi loglama
+
+Aşağıdaki örnekte, bağımsız değişken dizisi üç değer içermesine rağmen dizinin yalnızca ilk değeri loglanır.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Görüntüler: "My value is: A"  ('log.info'ya üç değer iletilmiş olsa da)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Mevcut bir diziden birden çok girişi kaydetme
+
+Argüman dizisindeki her girişin günlük mesajındaki bir yer tutucu `{}` ile eşleşmesi gerekir. Aşağıdaki örnek, günlük mesajında üç yer tutucu `{}` içerir. Bu nedenle, `myArray`'deki üç değerin üçü de loglanır.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Görüntüler: "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Mevcut bir diziden belirli bir girişi loglama
+
+Dizide belirli bir değeri görüntülemek için dizinlenmiş değer bulunmalıdır.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Görüntüler : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Olay bilgilerinin loglanması
+
+Aşağıdaki örnek, bir olaydan blok numarasını, blok hash'ını ve işlem hash'ını loglar:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+IPFS hash'ı veya yolu verildiğinde, bir dosyayı IPFS'den okuma şu şekilde yapılır:
+
+```typescript
+// Bunu eşleştirmedeki bir olay işleyicinin içine koyun
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+gibi yollar
+// bu dizinlerdeki dosyaları içerenler de desteklenir
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Not:** Şu anda `ipfs.cat` deterministik değildir. Eğer dosya, IPFS ağı üzerinden, talebin zaman aşımından önce getirilemezse, fonksiyon `null` döndürür. Bu nedenle, sonucun`null` olup olmadığını kontrol etmek her zaman önemlidir.
+
+Ayrıca, daha büyük dosyaları akış halinde işlemek için `ipfs.map` kullanmak da mümkündür. Bu fonksiyon, bir IPFS dosyasının hash'ini veya yolunu, bir geri çağırma işlevinin adını ve davranışını değiştirmek için bayraklar alır:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // İşlem yapmayla ilgili ayrıntılar için JSONValue belgelerine bakın
+  // JSON değerleri ile
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Geri çağırmalar da varlık oluşturabilir
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Bunu eşleştirmedeki bir olay işleyicisinin içine koyun
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatif olarak `ipfs.mapJSON` kullanın
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+Şu anda desteklenen tek bayrak `ipfs.map`'e iletilmesi gereken `json` bayrağıdır. `json` bayrağı ile IPFS dosyası, her satırda bir JSON değeri olacak şekilde bir dizi JSON değerinden oluşmalıdır. `ipfs.map` çağrısı, dosyadaki her satırı okur, bir `JSONValue` olarak ayrıştırır (deserialize eder) ve her biri için geri çağırma (callback) fonksiyonunu çağırır. Geri çağırma fonksiyonu daha sonra `JSONValue`dan gelen verileri depolamak için varlık operasyonlarını kullanabilir. Varlık değişiklikleri yalnızca `ipfs.map`'i çağıran işleyici başarıyla tamamlandığında depolanır; bu sırada değişiklikler bellekte tutulur ve bu nedenle `ipfs.map`'in işleyebileceği dosya boyutu sınırlıdır.
+
+Başarılı olduğunda `ipfs.map`, `void` döndürür. Geri çağırma fonksiyonunun herhangi bir çağrısı bir hataya neden olursa, `ipfs.map`'i çağıran işleyici durdurulur ve subgraph başarısız olarak işaretlenir.
+
+### Kripto(Crypto) API'si
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+`crypto` API'si, eşlemelerde kullanılan kriptografik fonksiyonları sağlar. Şu anda yalnızca bir fonksiyon mevcuttur:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON verileri, `json` API'si kullanılarak ayrıştırılabilir:
+
+- `json.fromBytes(data: Bytes): JSONValue` – Geçerli bir UTF-8 sekansı olarak yorumlanan bir `Bytes` dizisinden JSON verisini ayrıştırır
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – `json.fromBytes`'in güvenli versiyonu. Ayrıştırma başarısız olursa bir hata döndürür
+- `json.fromString(data: string): JSONValue` – Geçerli bir UTF-8 `String`den JSON verilerini ayrıştırır
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – `json.fromString`'in güvenli versiyonu. Ayrıştırma başarısız olursa bir hata döndürür
+
+`JSONValue` sınıfı, rastgele bir JSON belgesinden değerleri çekmek için bir yol sağlar. JSON değerleri boolean, sayı, dizi gibi türlerde olabileceği için, `JSONValue` sınıfı bir değerin türünü kontrol etmek için `kind` özelliği ile birlikte gelir:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+Ayrıca, değerin `null` olup olmadığını kontrol etmek için bir metot da vardır:
+
+- `value.isNull(): boolean`
+
+Bir değerin türü kesin olduğunda, aşağıdaki yöntemlerden biri kullanılarak [yerleşik türlerden](#built-in-types) birine dönüştürülebilir:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` – (ve ardından `JSONValue` değerini yukarıdaki 5 metottan biriyle dönüştürün)
+
+### Tip Dönüşümleri Referansı
+
+| Kaynak(lar)            | Hedef                | Dönüşüm fonksiyonu           |
+| ---------------------- | -------------------- | ---------------------------- |
+| Address                | Bytes                | yok                          |
+| Address                | String               | s.toHexString()              |
+| BigDecimal             | String               | s.toString()                 |
+| BigInt                 | BigDecimal           | s.toBigDecimal()             |
+| BigInt                 | Dizgi (onaltılık)    | s.toHexString() or s.toHex() |
+| BigInt                 | String (unicode)     | s.toString()                 |
+| BigInt                 | i32                  | s.toI32()                    |
+| Boolean                | Boolean              | yok                          |
+| Bytes (işaretli)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (işaretsiz)      | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                  | Dizgi (onaltılık)    | s.toHexString() or s.toHex() |
+| Bytes                  | String (unicode)     | s.toString()                 |
+| Bytes                  | String (base58)      | s.toBase58()                 |
+| Bytes                  | i32                  | s.toI32()                    |
+| Bytes                  | u32                  | s.toU32()                    |
+| Bytes                  | JSON                 | json.fromBytes(s)            |
+| int8                   | i32                  | yok                          |
+| int32                  | i32                  | yok                          |
+| int32                  | BigInt               | BigInt.fromI32(s)            |
+| uint24                 | i32                  | yok                          |
+| int64 - int256         | BigInt               | yok                          |
+| uint32 - uint256       | BigInt               | yok                          |
+| JSON                   | boolean              | s.toBool()                   |
+| JSON                   | i64                  | s.toI64()                    |
+| JSON                   | u64                  | s.toU64()                    |
+| JSON                   | f64                  | s.toF64()                    |
+| JSON                   | BigInt               | s.toBigInt()                 |
+| JSON                   | string               | s.toString()                 |
+| JSON                   | Array                | s.toArray()                  |
+| JSON                   | Object               | s.toObject()                 |
+| String                 | Address              | Address.fromString(s)        |
+| Bytes                  | Address              | Address.fromBytes(s)         |
+| String                 | BigInt               | BigInt.fromString(s)         |
+| String                 | BigDecimal           | BigDecimal.fromString(s)     |
+| Dizgi (onaltılık)      | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)         | Bytes                | ByteArray.fromUTF8(s)        |
+
+### Veri Kaynağı Meta Verileri
+
+`dataSource` ad alanı üzerinden işleyiciyi çağıran veri kaynağının sözleşme adresini, ağını ve bağlamını inceleyebilirsiniz:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Varlık ve VeriKaynağıBağlamı
+
+Temel `Entity` sınıfı ve alt sınıf olan `DataSourceContext` sınıfı, alanları dinamik olarak ayarlamak ve almak için yardımcı programlara sahiptir:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### Manifest'teki DataSourceContext
+
+`dataSources` içindeki `context` bölümü, subgraph eşlemeleriniz içinde erişilebilen anahtar-değer çiftlerini tanımlamanıza olanak tanır. Kullanılabilir türler şunlardır: `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List` ve `BigInt`.
+
+İşte `context` bölümünde çeşitli türlerin kullanımını gösteren bir YAML örneği:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Boolean bir değer (`true` veya `false`) belirtir.
+- `String`: Bir String (dize) değeri belirtir.
+- `Int`: 32-bit bir tamsayı belirtir.
+- `Int8`: 8-bit bir tamsayı belirtir.
+- `BigDecimal`: Ondalık bir sayı belirtir. Tırnak içinde yazılması gerekir.
+- `Bytes`: On altılık tabanda (hexadecimal) bir dizeyi belirtir.
+- `List`: Elemanlardan oluşan bir liste belirtir. Her elemanın türü ve verisi belirtilmelidir.
+- `BigInt`: Büyük bir tamsayı değeri belirtir. Büyük boyutu nedeniyle tırnak içinde yazılması gerekir.
+
+Bu bağlama daha sonra subgraph eşleştirme dosyalarınızdan erişilebilir ve böylece daha dinamik ve yapılandırılabilir subgraphlar elde edebilirsiniz.

From 57768d6afc237e0ac8d4d1d597de0322ed37cfc3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:14 -0500
Subject: [PATCH 0873/3820] New translations common-issues.mdx (Turkish)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/tr/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/tr/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..681a0a3c6b31
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Genel AssemblyScript Sorunları
+---
+
+Subgraph geliştirme sırasında karşılaşılması muhtemel bazı [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) sorunları bulunmaktadır. Bu sorunlar, hata ayıklama zorluğuna göre değişiklik gösterse de bunların farkında olmak faydalı olabilir. Aşağıda, bu sorunların kapsamlı olmayan bir listesi verilmiştir:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Kapsam [Closure fonksiyonlarına] aktarılmaz (https://www.assemblyscript.org/status.html#on-closures) kalıtılmaz, yani closure fonksiyonlarının dışında tanımlanan değişkenler bu fonksiyonlar içinde kullanılamaz. Daha fazla açıklama için [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s) videosuna bakabilirsiniz.

From f3a378aca629207cf6bfec60bc1d8c5a08482131 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:15 -0500
Subject: [PATCH 0874/3820] New translations unit-testing-framework.mdx
 (Turkish)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/tr/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/tr/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..6968cbcc5e22
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Birim Testi Framework'ü
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Buradan Başlayın
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+Matchstick'i WSL'de Docker yaklaşımı ve ikili yaklaşımı kullanarak kullanabilirsiniz. WSL biraz alengirli olabileceğinden, aşağıdaki gibi sorunlarla karşılaşırsanız birkaç ipucu verelim
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+yada
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI seçenekleri
+
+Bu, test klasöründeki tüm testleri çalıştıracaktır:
+
+```sh
+graph test
+```
+
+Bu, gravity.test.ts adında bir testi ve/veya gravity adında bir klasördeki tüm testleri çalıştıracaktır:
+
+```sh
+graph test gravity
+```
+
+Bu sadece belirtilen test dosyasını çalıştıracaktır:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Yapılandırma
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo subgraph
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Öğretici videolar
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Test yapısı
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Örnek:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Örnek:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+yada
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Örnekler:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Örnek:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Örnekler:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Açıklamalar
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+Sürüm 0.6.0 itibariyle, assert fonksiyonları özel hata mesajlarını da desteklemektedir
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Bir Birim Testi Yazın
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Aşağıdaki işleyici fonksiyonuna sahip olduğumuzu varsayarsak (iki yardımcı işlevle birlikte):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+Önce projemizde bir test dosyası oluşturmamız gerekiyor. Bunun nasıl görünebileceğine dair bir örnek:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- İlk durumumuzu ayarlıyor ve bir özel Gravatar varlığı ekliyoruz;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- Depo durumunu doğruluyoruz. Bu nasıl çalışır? - Bir varlık türü ve kimliğinin benzersiz bir kombinasyonunu geçiriyoruz. Ardından, bu varlıkta belirli bir alanı kontrol ediyoruz ve beklediğimiz değeri almasını sağlıyoruz. Hem depoya eklediğimiz ilk Gravatar Varlığı için hem de işleyici işlevi çağrıldığında eklenen iki Gravatar varlığı için bunu yapıyoruz;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+İşte başardın - ilk testimizi oluşturduk! 👏
+
+Şimdi testlerimizi çalıştırmak için subgraph kök klasörünüzde şunu çalıştırmanız yeterlidir:
+
+`graph test Gravity`
+
+Ve her şey yolunda giderse aşağıdakiyle karşılaşacaksınız:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Çok rastlanan test senaryoları
+
+### Belirli bir durumla depoyu doldurma
+
+Kullanıcılar bilinen bir varlık kümesiyle depoyu doldurabilirler. Aşağıdaki örnek depoyu Gravatar varlığıyla başlatmak için kullanılabilir:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Olayla bir eşleştirme fonksiyonu çağırmak
+
+Kullanıcı, depoya bağlı bir eşleştirme fonksiyonuna özel bir olay oluşturabilir ve onu iletebilir:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Tüm eşitlemeleri olay fikstürleriyle çağırmak
+
+Kullanıcılar test fikstürleriyle eşleştirmeleri çağırabilirler.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Kontrat çağrılarını mocklama
+
+Kullanıcılar sözleşme çağrılarını mocklayabilir:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+Gösterildiği gibi, bir sözleşme çağrısını mocklamak ve bir dönüş değeri sabitlemek için kullanıcı, bir sözleşme adresi, işlev adı, işlev imzası, bir argüman dizisi ve elbette dönüş değerini sağlamalıdır.
+
+Kullanıcılar ayrıca fonksiyon geri çevirilerinide mocklayabilirler:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### IPFS dosyalarını mocklama (Matchstick 0.4.1'den)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map geri çağrısı
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // İşlem yapmayla ilgili ayrıntılar için JSONValue belgelerine bakın
+  // JSON değerleri ile
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Geri çağrılar ayrıca varlıklar oluşturabilir
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// ipfs.cat'i çağıran fonksiyon
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Depo durumunu doğrulama
+
+Kullanıcılar, varlıkları doğrulayarak deponun nihai (veya orta) durumunu doğrulayabilirler. Bunun için, kullanıcı bir Varlık türü, bir Varlığın belirli bir kimliği, o Varlıktaki bir alanın adı ve alanın beklenen değerini sağlamalıdır. Hızlıca bir örneğe bakalım:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Olay üst verileriyle etkileşim
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Okuma
+let logType = newGravatarEvent.logType
+
+// Yazma
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Değişken eşitliğini doğrulama
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Kullanıcılar, bir varlığın depoda olmadığını doğrulayabilirler. Bu fonksiyon, bir varlık türü ve bir kimlik alır. Eğer varlık gerçekten depoda ise, test ilgili bir hata mesajı vererej başarısız olacaktır. Fonksiyonun nasıl kullanılacağına dair hızlıca bir örneğe bakalım:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Tüm mağazayı veya tüm mağazadan tek varlıkları yazdırma (hata ayıklama amaçlı)
+
+Bu yardımcı fonksiyon kullanılarak deponun tamamı konsola yazdırılabilir:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Beklenen başarısızlık
+
+Kullanıcılar, shouldFail bayrağını test() fonksiyonlarında kullanarak beklenen test başarısızlıklarına sahip olabilirler:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+Test, shouldFail = true olarak işaretlenirse ama BAŞARISIZ olmazsa, bu kayıtlarda bir hata olarak görünecek ve test bloğu başarısız olacaktır. Ayrıca, with shouldFail = false (the default state) olarak işaretlenirse, test yürütücüsü çökecektir.
+
+### Kayıt tutma
+
+Birim testlerinde özel kayıt tutmanın eşitlemelerdeki kayıt tutmaktan tamamen aynıdır. Fark, günlük nesnesinin graph-ts yerine matchstick-as'dan içe aktarılması gerektmesidir. İşte tüm kritik olmayan kayıt türleriyle ilgili basit bir örnek:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Kullanıcılar ayrıca şu şekilde kritik bir hatayı simüle edebilirler:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Kritik hataları kayıt altına almak, testlerin yürütülmesini durduracak ve her şeyi mahvedecektir. Sonuçta, kodunuzun dağıtımda kritik kayıtları içermediğinden emin olmak istiyoruz ve bunun olması durumunda hemen fark etmeniz gerekiyor.
+
+### Türetilmiş alanların test edilmesi
+
+Türetilmiş alanları test etme özelliği, belirli bir varlıkta bir alan belirleyip, bu varlıktan türetilmiş bir alan içeriyoren başka bir varlığın otomatik olarak güncellenmesini sağlayan bir özelliktir.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Dinamik Veri Kaynaklarının Test Edilmesi
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Aşağıdaki örnekte:
+
+Öncelikle aşağıdaki olay işleyicisine sahibiz (veri kaynağı mocklamasını göstermek için kasıtlı olarak amaç değişikliği):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+Ardından, dataSourceMock ad alanındaki yöntemlerden birini kullanarak tüm veri kaynağı fonksiyonları için yeni bir geri dönüş değeri ayarlayan testi görüyoruz:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+dataSourceMock.resetValues()'in en sonda çağrıldığına dikkat edin. Bunun nedeni değerler değiştirildiğinde hatırlanır ve varsayılan değerlere geri dönmek istiyorsanız sıfırlanmaları gerekir.
+
+### Dinamik veri kaynağı oluşturulmasının test edilmesi
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Kilitli GRT tutan Token Kilit Cüzdanları
+"""
+type TokenLockMetadata @entity {
+  "Token kilit cüzdanının adresi"
+  id: ID!
+  "Serbest bırakma programının başlangıç zamanı"
+  startTime: BigInt!
+  "Serbest bırakma programının bitiş zamanı"
+  endTime: BigInt!
+  "Başlangıç zamanı ile bitiş zamanı arasındaki periyot sayısı"
+  periods: BigInt!
+  "Serbest bırakmaların başladığı zaman"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### İşleyici örneği
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Test örneği
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Test Kapsamı
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Ön Koşullar
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### İşleyicilerinizi dışa aktarın
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Kullanış
+
+Her şey hazır olduğunda, test kapsama aracını çalıştırmak için basitçe şunu çalıştırın:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+Bu, kapsama aracını çalıştıracak ve terminalde buna benzer bir şey göreceksiniz:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Tutulan kayıt çıktısında test çalışma süresi
+
+Tutulan kayıt çıktısı test çalışma süresini içerir. İşte buna bir örnek:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Çok rastlanan derleyici hataları
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Ek Kaynaklar
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Geribildirim
+
+Soru, geri bildirim, özellik istekleri veya sadece iletişim kurmak istiyorsanız en iyi yer Matchstick için ayrılmış bir kanal olan 🔥| unit-testing kanalına sahip olduğumuz The Graph Discord'udur.

From 0796ff3d711d0df56a283e2e4e085b581a7e210c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:16 -0500
Subject: [PATCH 0875/3820] New translations transferring-a-subgraph.mdx
 (Turkish)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/tr/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/tr/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..3631cc8a2973
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Merkeziyetsiz ağda yayımlanan subgraph’ler, NFT olarak oluşturulup subgraph’i yayımlayan adrese gönderilir. Bu NFT, The Graph Ağı’ndaki hesaplar arasında transferi kolaylaştıran standart bir ERC721 sözleşmesini temel alır.
+
+## Reminders
+
+- NFT’ye sahip olan kişi, subgraph’in kontrolünü elinde tutar.
+- NFT’nin sahibi NFT’yi satmaya veya transfer etmeye karar verirse, artık bu subgraph’i ağ üzerinde düzenleyemez veya güncelleyemez.
+- Subgraph kontrolünü kolayca bir multi-sig cüzdana taşıyabilirsiniz.
+- Bir topluluk üyesi, bir DAO adına subgraph oluşturabilir.
+
+## Subgraph’inizi NFT Olarak Görüntüleyin
+
+Subgraph’inizi bir NFT olarak görüntülemek için, **OpenSea** gibi bir NFT pazar yerini ziyaret edebilirsiniz:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Ya da **Rainbow.me** gibi bir cüzdan gezgini kullanabilirsiniz:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Adım Adım
+
+Bir subgraph’in sahipliğini transfer etmek için şu adımları izleyin:
+
+1. Subgraph Studio’ya entegre edilmiş kullanıcı arayüzünü kullanın:
+
+   ![Subgraph Sahipliği Transferi](/img/subgraph-ownership-transfer-1.png)
+
+2. Subgraph’i transfer etmek istediğiniz adresi seçin:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Alternatif olarak, OpenSea gibi NFT pazar yerlerinin entegre kullanıcı arayüzünü de kullanabilirsiniz:
+
+![NFT Pazar Yerinden Subgraph Sahipliği Transferi](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 669fb463e911a2df00dd066813ce766e51588384 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:17 -0500
Subject: [PATCH 0876/3820] New translations graphql-api.mdx (Turkish)

---
 .../tr/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/tr/subgraphs/querying/graphql-api.mdx b/website/pages/tr/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..95fb439ed2c3
--- /dev/null
+++ b/website/pages/tr/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Örnekler
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sıralama
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Örnek
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### İç içe varlık sıralaması için örnek
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Sayfalandırma
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+İlk 10 tokeni sorgulayın:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtreleme
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Aralık filtreleme için örnek
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Blok filtreleme için örnek
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+Örneğin bu, son yoklamanızdan bu yana yalnızca değişen varlıkları almak istiyorsanız yararlı olabilir. Ya da alternatif olarak, subgraph'ınızda varlıkların nasıl değiştiğini araştırmak veya hata ayıklamak için yararlı olabilir (bir blok filtresiyle birleştirilirse, yalnızca belirli bir blokta değişen varlıkları izole edebilirsiniz).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### İç içe varlık filtreleme örneği
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+Bu, yalnızca alt düzey varlıkları sağlanan koşulları karşılayan varlıkları getirmek istiyorsanız yararlı olabilir.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Mantıksal operatörler
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### Tüm Filtreler
+
+Parametre eklerinin tam listesi:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Zaman yolculuğu sorguları
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Örnek
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Örnek
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Tam Metin Arama Sorguları
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Tam metin arama operatörleri:
+
+| Symbol | Operator    | Tanım                                                                                                                                |
+| ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
+
+#### Örnekler
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Daha karmaşık filtreler oluşturmak için tam metin operatörlerini birleştirin. Bu örnek sorgu, bir pretext arama işleci ile bir follow by işlecini birleştirerek "lou" ile başlayan ve ardından "music" ile devam eden sözcükleri içeren tüm blog varlıklarıyla eşleşecektir.
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validasyon
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Varlıklar
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Subgraph Üst Verisi
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+Eğer bir blok belirtilirse, üst veri o blokla ilgilidir; belirtilmezse en son dizinlenen blok dikkate alınır. Eğer belirtilirse, blok subgraph başlangıç bloğundan sonra olmalıdır ve en son indekslenen bloğa eşit veya daha küçük olmalıdır.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: the hash of the block
+- number: the block number
+- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 62876398147942f24d0ef14c927aacc3efa607ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:18 -0500
Subject: [PATCH 0877/3820] New translations python.mdx (Turkish)

---
 .../pages/tr/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/querying/python.mdx

diff --git a/website/pages/tr/subgraphs/querying/python.mdx b/website/pages/tr/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..ab45b88184a2
--- /dev/null
+++ b/website/pages/tr/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds, [Playgrounds](https://playgrounds.network/) tarafından oluşturulmuş, subgraph sorgulamak için kullanılan sezgisel bir Python kütüphanesidir. Bu kütüphane, subgraph verilerini doğrudan bir Python veri ortamına bağlamanıza olanak tanır ve [pandas](https://pandas.pydata.org/) gibi kütüphaneleri kullanarak veri analizi yapmanıza imkan sağlar!
+
+Subgrounds, GraphQL sorguları oluşturmak için sayfalandırma gibi sıkıcı iş akışlarını otomatikleştiren ve kontrollü şema dönüşümleri aracılığıyla ileri düzey kullanıcıları güçlendiren basit bir Pythonic API sunar.
+
+## Buradan Başlayın
+
+Subgrounds, Python 3.10 veya daha yüksek bir sürümünü gerektirir ve [pypi](https://pypi.org/project/subgrounds/) üzerinden erişilebilir.
+
+```bash
+pip install --upgrade subgrounds
+# yada
+python -m pip install --upgrade subgrounds
+```
+
+Kurulum tamamlandıktan sonra, aşağıdaki sorgu ile subgrounds'ı test edebilirsiniz. Aşağıdaki örnek, Aave v2 protokolü için bir subgraph çeker ve TVL'ye (Toplam Kilitli Varlık) göre sıralanan en üst 5 pazarı sorgular, adlarını ve TVL'lerini (USD cinsinden) seçer ve verileri bir pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame) olarak döndürür.
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Subgraph'ı yükleme
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Sorguyu oluşturma
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Sorguyu bir veri çerçevesine döndürme
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Dökümantasyon
+
+Subgrounds, [Playgrounds](https://playgrounds.network/) ekibi tarafından oluşturulmuş ve sürdürülmektedir ve [Playgrounds dokümantasyonu](https://docs.playgrounds.network/subgrounds) üzerinden erişilebilir.
+
+Subgrounds'un keşfedilecek geniş bir özellik seti bulunduğundan, işe bazı yararlı başlangıç noktaları:
+
+- [Sorgulamaya Başlarken](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - Subgrounds ile sorguların nasıl oluşturulacağına dair iyi bir başlangıç.
+- [Sentetik Alanlar Oluşturma](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - Veri şemasından tanımlanan verileri dönüştüren sentetik alanları tanımlamaya yönelik yumuşak bir giriş.
+- [Eşzamanlı Sorgular](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Sorgularınızı paralelleştirerek nasıl geliştireceğinizi öğrenin.
+- [Veriyi CSV dosyalarına aktarma](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From abd5c4a1ac5a93b05cc510488536cc5f4328512b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:19 -0500
Subject: [PATCH 0878/3820] New translations triggers.mdx (Turkish)

---
 website/pages/tr/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/tr/substreams/sps/triggers.mdx

diff --git a/website/pages/tr/substreams/sps/triggers.mdx b/website/pages/tr/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/tr/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From a7c78485bad4777c0b138de1f929af0852bcfc0f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:21 -0500
Subject: [PATCH 0879/3820] New translations overview.mdx (Ukrainian)

---
 website/pages/uk/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/uk/indexing/overview.mdx

diff --git a/website/pages/uk/indexing/overview.mdx b/website/pages/uk/indexing/overview.mdx
new file mode 100644
index 000000000000..f296f9b15e07
--- /dev/null
+++ b/website/pages/uk/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Індексатори - це оператори нод у The Graph Network, які стейкають токени Graph (GRT), щоб надавати послуги з індексування та обробки запитів. За свої послуги індексатори отримують плату за запити та винагороду за індексацію. Вони також заробляють комісію за запити, яка повертається відповідно до експоненціальної функції компенсації.
+
+GRT, які застейкані в протоколі, підлягають періоду "розблокування" і можуть бути порізані (slashing), якщо індексатори є шкідливими та надають некоректні дані додаткам або якщо вони неправильно індексують. Індексатори також отримують винагороду за стейк, який вони отримують від делегатів, щоб зробити свій внесок у розвиток мережі.
+
+Індексатори вибирають підграфи для індексування на основі сигналу від кураторів, де куратори стейкають GRT, щоб вказати, які підграфи є якісними та мають бути пріоритетними. Споживачі (наприклад, додатки) також можуть задавати параметри, за якими індексатори обробляють запити до їхніх підграфів, і встановлювати налаштування щодо оплати за запити.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### Яка мінімальна кількість GRT необхідна для того, щоб стати індексатором в мережі?
+
+Мінімальна кількість для індексатора наразі встановлена на рівні 100 тис. GRT.
+
+### Які джерела доходу для індексатора?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### Як розподіляються винагороди за індексацію?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### Що за доказ індексації (POI)?
+
+POI використовуються в мережі для перевірки того, що Індексатор індексує підграфи, на які вони були розподілені. POI для першого блоку поточної епохи має бути надісланий при закритті розподілу, щоб цей розподіл мав право на винагороду за індексацію. POI для блоку - це дайджест усіх транзакцій сховища об'єктів для певного розгортання підграфів до цього блоку включно.
+
+### Коли розподіляються винагороди за індексацію?
+
+Винагороди безперервно накопичуються, поки алокації активні та розподілені протягом 28 періодів. Винагороди збираються Індексаторами та розподіляються щоразу, коли їхні розподіли закриваються. Це відбувається або вручну, коли Індексатор хоче примусово закрити їх, або після 28 епох, делегат може закрити розподіл для Індексатора, але це не призводить до отримання винагороди. 28 епох - це максимальний час роботи розподілів (зараз одна епоха триває ~24 години).
+
+### Чи можна відстежувати винагороди за індексацію, що очікують на розгляд?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Багато інформаційних панелей, створених спільнотою, містять очікувані значення винагород, і їх можна легко перевірити вручну, виконавши ці кроки:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### Що таке спори (disputes) та де я можу їх переглянути?
+
+Запити індексатора та розподіли можуть бути оскаржені на Graph протягом відповідного періоду оскарження. Цей період варіюється в залежності від типу спору. Для запитів/атестацій вікно спору триває 7 епох, тоді як для розподілів - 56. Після закінчення цих періодів спори не можуть бути відкриті ні проти розподілів, ні проти запитів. При відкритті спору учасник повинен внести депозит у розмірі не менше 10 000 GRT, який буде заблокований до завершення спору і винесення рішення по ній. Fisherman (рибалка) - це будь-який учасник мережі, який відкриває спори.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- Якщо спір буде відхилено, GRT, внесений в якості депозиту, буде спалено, а Індексатор не буде порізаний.
+- Якщо суперечка буде вирішена внічию, депозит користувача буде повернуто, а індексатора не буде порізано.
+- Якщо спір буде задоволено, GRT, внесений учасником, буде повернуто, Індексатора буде порізано, а рибалка отримає 50% від GRT, які були порізані.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### Що за комісії за опрацювання запитів і коли вони розподіляються?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Після закриття розподілу виплати можуть бути отримані індексатором. Після клейму, комісії за запити розподіляються між індексатором та його делегатами на основі зниження цін за запити та експоненціальної функції повернень.
+
+### Що таке query fee cut і indexing reward cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### Як індексатори знають, які підграфи індексувати?
+
+Індексатори можуть відрізнятися один від одного, застосовуючи передові методи для прийняття рішень щодо індексування підграфів, але для того, щоб дати загальне уявлення, ми обговоримо кілька ключових метрик, які використовуються для оцінки підграфів у мережі:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### Які вимоги до апаратного обладнання?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Налаштування | Postgres<br />(CPU) | Postgres<br />(пам'ять в GB) | Postgres<br />(диск у ТБ) | VMs<br />(Центральні CPU) | VMs<br />(пам'ять у ГБ) |
+| ------------ | :-----------------: | :--------------------------: | :-----------------------: | :-----------------------: | :---------------------: |
+| Small        |          4          |               8              |             1             |             4             |            16           |
+| Standard     |          8          |              30              |             1             |             12            |            48           |
+| Medium       |          16         |              64              |             2             |             32            |            64           |
+| Large        |          72         |              468             |            3.5            |             48            |           184           |
+
+### Яких основних заходів безпеки повинен дотримуватися індексатор?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Інфраструктура
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Примітка: Для підтримки гнучкого масштабування рекомендується розділити завдання запитів та індексації між різними наборами нод: нодами запитів та нодами індексації.
+
+### Огляд портів
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Порт | Призначення                                         | Розташування                                   | Аргумент CLI       | Перемінна оточення |
+| ---- | --------------------------------------------------- | ---------------------------------------------- | ------------------ | ------------------ |
+| 8000 | HTTP-сервер GraphQL<br />(для запитів до підграфів) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-порт       | -                  |
+| 8001 | GraphQL WS<br />(для підписок на підграфи)          | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                  |
+| 8020 | JSON-RPC<br />(для керування розгортаннями)         | /                                              | \--admin-port      | -                  |
+| 8030 | API стану індексації підграфів                      | /graphql                                       | \--index-node-port | -                  |
+| 8040 | Метрики Prometheus                                  | /metrics                                       | \--metrics-port    | -                  |
+
+#### Служба індексації
+
+| Порт | Призначення                                                 | Розташування                                                | Аргумент CLI    | Перемінна оточення     |
+| ---- | ----------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | HTTP-сервер GraphQL<br />(для платних запитів до підграфів) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Метрики Prometheus                                          | /metrics                                                    | \--metrics-port | -                      |
+
+#### Агент індексації
+
+| Порт | Purpose                        | Розташування | CLI Argument               | Environment Variable                    |
+| ---- | ------------------------------ | ------------ | -------------------------- | --------------------------------------- |
+| 8000 | API для керування індексатором | /            | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Налаштування серверної інфраструктури з використанням Terraform на Google Cloud
+
+> Примітка: Індексатори можуть альтернативно використовувати AWS, Microsoft Azure або Alibaba.
+
+#### Встановіть необхідні умови
+
+- Google Cloud SDK
+- Kubectl - інструмент командного рядка
+- Terraform
+
+#### Створіть проєкт на Google Cloud
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Авторизуйтесь у Google Cloud і створіть новий проєкт.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Використовуйте сторінку виставлення рахунків у Google Cloud Console, щоб увімкнути виставлення рахунків для нового проєкту.
+
+- Створіть конфігурацію Google Cloud.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Увімкніть необхідні Google Cloud API.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Створіть обліковий запис сервісу.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Увімкніть взаємодію між базою даних і кластером Kubernetes, який буде створено на наступному кроці.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Створіть мінімальний конфігураційний файл terraform (оновлюйте за потреби).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Використовуйте Terraform для створення інфраструктури
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Запустіть наступні команди, щоб створити інфраструктуру.
+
+```sh
+# Встановіть необхідні плагіни
+terraform init
+
+# Переглянути план для ресурсів, які будуть створені
+terraform plan
+
+# Створіть ресурси (очікується, що це займе до 30 хвилин)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Створення компонентів Kubernetes для індексатора
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Початок роботи з базового коду
+
+#### Встановіть необхідні умови
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Налаштування
+
+1. Запуск сервера бази даних PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Тепер, коли всі необхідні складові налаштовано, запустіть Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Початок роботи з Docker
+
+#### Prerequisites
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Налаштування
+
+1. Клонуйте Graph Node і перейдіть до каталогу Docker:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Запустіть локальну Graph Node, яка буде підключена до вашої кінцевої точки Ethereum:
+
+```sh
+docker-compose up
+```
+
+### Компоненти індексатора
+
+Для успішної участі в мережі потрібен майже постійний моніторинг і взаємодію, тому ми створили набір додатків Typescript для полегшення участі в мережі індексаторів. Існує три компоненти Індексатора:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Початок роботи
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### З NPM-пакетів
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### З базового коду
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Використання docker
+
+- Витягнути images з реєстру
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Або створіть images локально з базового коду
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Запустіть компоненти
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Використання K8 та Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Usage
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexer agent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Керування індексатором за допомогою Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Usage
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Правила індексації
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Модель даних:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Приклад використання правила індексації:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Дія, додана до черги стороннім оптимізатором або користувачем indexer-cli
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- Індексатор може стежити за чергою дій, щоб бачити історію виконання дій і при необхідності повторно затверджувати та оновлювати елементи дій, якщо вони не були виконані. У черзі дій відображається історія всіх дій, поставлених у чергу і виконаних.
+
+Модель даних:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Приклад використання:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Зверніть увагу, що підтримувані типи дій для управління розподілами мають різні вимоги до вхідних даних:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - необхідні параметри:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - необхідні параметри:
+    - allocationID
+    - deploymentID
+  - необов'язкові параметри:
+    - poi
+    - force (змушує використовувати наданий POI, навіть якщо він не збігається з тим, що надає graph-node)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - необхідні параметри:
+    - allocationID
+    - deploymentID
+    - amount
+  - необов'язкові параметри:
+    - poi
+    - force (змушує використовувати наданий POI, навіть якщо він не збігається з тим, що надає graph-node)
+
+#### Моделі витрат
+
+Моделі витрат забезпечують динамічне ціноутворення для запитів на основі атрибутів ринку і запиту. Сервіс-індексатора ділиться моделлю вартості зі шлюзами для кожного підграфа, для якого вони мають намір відповідати на запити. Шлюзи, і собі, використовують модель вартості для прийняття рішень про вибір індексатора для кожного запиту і для обговорень про оплату з обраними індексаторами.
+
+#### Agora
+
+Мова Agora надає гнучкий формат для оголошення цінових моделей для запитів. Цінова модель Agora - це послідовність операторів, які виконуються по черзі для кожного запиту верхнього рівня в запиті GraphQL. Для кожного запиту верхнього рівня перший оператор, який йому відповідає, визначає ціну для цього запиту.
+
+Оператор складається з параметра, який використовується для зіставлення запитів GraphQL, і виразу вартості, який при обчисленні виводить вартість у десяткових GRT. Значення в позиції іменованого аргументу запиту можуть бути перехоплені в пропозицію і використані у виразі. Globals також можна встановлювати та підставляти замість символів-замінників у виразі.
+
+Приклад моделі витрат:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Приклад розрахунку вартості запиту за наведеною вище моделлю:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Застосування вартісної моделі
+
+Моделі витрат застосовуються за допомогою Indexer CLI, яка передає їх до Indexer Management API агента індексатора для зберігання в базі даних. Потім сервіс-індексатора забирає їх і надає моделі витрат шлюзам, коли вони їх запитують.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Взаємодія з мережею
+
+### Стейкінг в протоколі
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Approve токенів
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Стейкінг токенів
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### Термін розподілу
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 74e05243bfe2809e39f4c4ee3a1de51455ab3934 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:22 -0500
Subject: [PATCH 0880/3820] New translations tap.mdx (Ukrainian)

---
 website/pages/uk/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/uk/indexing/tap.mdx

diff --git a/website/pages/uk/indexing/tap.mdx b/website/pages/uk/indexing/tap.mdx
new file mode 100644
index 000000000000..3bab672ab211
--- /dev/null
+++ b/website/pages/uk/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Overview
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notes:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From f61d118fb9a22795d1241d915cecae66330ae9d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:23 -0500
Subject: [PATCH 0881/3820] New translations graph-node.mdx (Ukrainian)

---
 .../pages/uk/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/uk/indexing/tooling/graph-node.mdx

diff --git a/website/pages/uk/indexing/tooling/graph-node.mdx b/website/pages/uk/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..207fe8923eeb
--- /dev/null
+++ b/website/pages/uk/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL database
+
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
+
+### Network clients
+
+In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS Nodes
+
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+### Prometheus metrics server
+
+To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
+
+### Початок роботи з базового коду
+
+#### Встановіть необхідні умови
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Налаштування
+
+1. Запуск сервера бази даних PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Тепер, коли всі необхідні складові налаштовано, запустіть Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Getting started with Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+When it is running Graph Node exposes the following ports:
+
+| Порт | Призначення                                         | Розташування                                   | Аргумент CLI       | Перемінна оточення |
+| ---- | --------------------------------------------------- | ---------------------------------------------- | ------------------ | ------------------ |
+| 8000 | HTTP-сервер GraphQL<br />(для запитів до підграфів) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-порт       | -                  |
+| 8001 | GraphQL WS<br />(для підписок на підграфи)          | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                  |
+| 8020 | JSON-RPC<br />(для керування розгортаннями)         | /                                              | \--admin-port      | -                  |
+| 8030 | API стану індексації підграфів                      | /graphql                                       | \--index-node-port | -                  |
+| 8040 | Метрики Prometheus                                  | /metrics                                       | \--metrics-port    | -                  |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Advanced Graph Node configuration
+
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Multiple Graph Nodes
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding.
+
+#### Deployment rules
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Example deployment rule configuration:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Dedicated query nodes
+
+Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Any node whose --node-id matches the regular expression will be set up to only respond to queries.
+
+#### Database scaling via sharding
+
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore.
+
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Dedicated block ingestion
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Supporting multiple networks
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Multiple networks
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Environment variables
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Continuous deployment
+
+Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Managing Graph Node
+
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Working with subgraphs
+
+#### Indexing status API
+
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Indexing performance
+
+There are three separate parts of the indexing process:
+
+- Fetching events of interest from the provider
+- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
+- Writing the resulting data to the store
+
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+
+Common causes of indexing slowness:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- A large number of events to process
+- Slow database connection time, for crowded nodes
+- The provider itself falling behind the chain head
+- Slowness in fetching new receipts at the chain head from the provider
+
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+
+#### Failed subgraphs
+
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+
+- Deterministic failures: these are failures which will not be resolved with retries
+- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
+
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Block and call cache
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. If the block matches the provider, then the issue can be debugged directly against the provider.
+
+#### Querying issues and errors
+
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+
+However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+
+There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.
+
+##### Query caching
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analysing queries
+
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
+
+In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
+
+##### Account-like optimisation
+
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Removing subgraphs
+
+> This is new functionality, which will be available in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 79cabbd0aacf5c8d0ee0a5a97a56f91c96df876c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:24 -0500
Subject: [PATCH 0882/3820] New translations advanced.mdx (Ukrainian)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/uk/subgraphs/developing/creating/advanced.mdx b/website/pages/uk/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..c35f84285c78
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Overview
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Non-fatal errors
+
+Indexing errors on already synced subgraphs will, by default, cause the subgraph to fail and stop syncing. Subgraphs can alternatively be configured to continue syncing in the presence of errors, by ignoring the changes made by the handler which provoked the error. This gives subgraph authors time to correct their subgraphs while queries continue to be served against the latest block, though the results might be inconsistent due to the bug that caused the error. Note that some errors are still always fatal. To be non-fatal, the error must be known to be deterministic.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Enabling non-fatal errors requires setting the following feature flag on the subgraph manifest:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way. File data sources support fetching files from IPFS and from Arweave.
+
+> This also lays the groundwork for deterministic indexing of off-chain data, as well as the potential introduction of arbitrary HTTP-sourced data.
+
+### Overview
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Upgrade guide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Add a new entity type which will be updated when files are found
+
+File data sources cannot access or update chain-based entities, but must update file specific entities.
+
+This may mean splitting out fields from existing entities into separate entities, linked together.
+
+Original combined entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+New, split entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+If the relationship is 1:1 between the parent entity and the resulting file data source entity, the simplest pattern is to link the parent entity to a resulting file entity by using the IPFS CID as the lookup. Get in touch on Discord if you are having difficulty modelling your new file-based entities!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+This is the data source which will be spawned when a file of interest is identified.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Create a new handler to process files
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Example handler:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Spawn file data sources when required
+
+You can now create file data sources during execution of chain-based handlers:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Example:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+This will create a new file data source, which will poll Graph Node's configured IPFS or Arweave endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Congratulations, you are using file data sources!
+
+#### Deploying your subgraphs
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitations
+
+File data source handlers and entities are isolated from other subgraph entities, ensuring that they are deterministic when executed, and ensuring no contamination of chain-based data sources. To be specific:
+
+- Entities created by File Data Sources are immutable, and cannot be updated
+- File Data Source handlers cannot access entities from other file data sources
+- Entities associated with File Data Sources cannot be accessed by chain-based handlers
+
+> While this constraint should not be problematic for most use-cases, it may introduce complexity for some. Please get in touch via Discord if you are having issues modelling your file-based data in a subgraph!
+
+Additionally, it is not possible to create data sources from a file data source, be it an onchain data source or another file data source. This restriction may be lifted in the future.
+
+#### Best practices
+
+If you are linking NFT metadata to corresponding tokens, use the metadata's IPFS hash to reference a Metadata entity from the Token entity. Save the Metadata entity using the IPFS hash as an ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> We are working to improve the above recommendation, so queries only return the "most recent" version
+
+#### Known issues
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Examples
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### References
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Grafting onto Existing Subgraphs
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Because grafting copies rather than indexes base data, it is much quicker to get the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied.
+
+Підграф, утворений в результаті може використовувати схему GraphQL, яка не є ідентичною схемі базового підграфа, а лише сумісною з нею. Вона повинна бути валідною схемою підграфа сама по собі, але може відхилятися від схеми базового підграфа у такому випадку:
+
+- Додає або видаляє типи елементів
+- Видаляє атрибути з типів елементів
+- Додає до типів об'єктів атрибути, які можна скасувати
+- Перетворює атрибути, які не можна скасувати, на атрибути, які можна скасувати
+- Додає значення до переліків
+- Додає або видаляє інтерфейси
+- Визначає, для яких типів елементів реалізовано інтерфейс
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 509b3b19cf92f575d5836d8d44dee509aab0b92d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:25 -0500
Subject: [PATCH 0883/3820] New translations api.mdx (Ukrainian)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/uk/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/uk/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..5cd8ab120b25
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API Reference
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- Low-level primitives to translate between different type systems such as Ethereum, JSON, GraphQL and AssemblyScript.
+
+### Versions
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| Version | Release notes                                                                                                                                                                                                                                            |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### Built-in Types
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Creating entities
+
+The following is a common pattern for creating entities from Ethereum events.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Loading entities from the store
+
+If an entity already exists, it can be loaded from the store with the following:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Looking up entities created withing a block
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### Updating existing entities
+
+There are two ways to update an existing entity:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+Changing properties is straight forward in most cases, thanks to the generated property setters:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+It is also possible to unset properties with one of the following two instructions:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Removing entities from the store
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
+
+#### Support for Ethereum Types
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+The following example illustrates this. Given a subgraph schema like
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Events and Block/Transaction Data
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Access to Smart Contract State
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+A common pattern is to access the contract from which an event originates. This is achieved with the following code:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address.
+
+#### Handling Reverted Calls
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Encoding/Decoding ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+For more information:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Logging one or more values
+
+##### Logging a single value
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Logging a single entry from an existing array
+
+In the example below, only the first value of the argument array is logged, despite the array containing three values.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Logging multiple entries from an existing array
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Logging a specific entry from an existing array
+
+To display a specific value in the array, the indexed value must be provided.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Logging event information
+
+The example below logs the block number, block hash and transaction hash from an event:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Given an IPFS hash or path, reading a file from IPFS is done as follows:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### Type Conversions Reference
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### Data Source Metadata
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entity and DataSourceContext
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From 0955dbbfc9558e24d70b1fbcb2848a0a0f15c97f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:26 -0500
Subject: [PATCH 0884/3820] New translations common-issues.mdx (Ukrainian)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/uk/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/uk/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..f8d0c9c004c2
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Common AssemblyScript Issues
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From e87b0d63849d26bc6c4a28b9233f9be71cb75281 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:27 -0500
Subject: [PATCH 0885/3820] New translations unit-testing-framework.mdx
 (Ukrainian)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/uk/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/uk/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..78df2c601459
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Unit Testing Framework
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Getting Started
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+or
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+This will run all tests in the test folder:
+
+```sh
+graph test
+```
+
+This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
+
+```sh
+graph test gravity
+```
+
+This will run only that specific test file:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo subgraph
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Video tutorials
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+or
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Examples:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Example:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Examples:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Write a Unit Test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Assuming we have the following handler function (along with two helper functions to make our life easier):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+We first have to create a test file in our project. This is an example of how that might look like:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- We're setting up our initial state and adding one custom Gravatar entity;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- We assert the state of the store. How does that work? - We're passing a unique combination of Entity type and id. Then we check a specific field on that Entity and assert that it has the value we expect it to have. We're doing this both for the initial Gravatar Entity we added to the store, as well as the two Gravatar entities that gets added when the handler function is called;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+There we go - we've created our first test! 👏
+
+Now in order to run our tests you simply need to run the following in your subgraph root folder:
+
+`graph test Gravity`
+
+And if all goes well you should be greeted with the following:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Common test scenarios
+
+### Hydrating the store with a certain state
+
+Users are able to hydrate the store with a known set of entities. Here's an example to initialise the store with a Gravatar entity:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Calling a mapping function with an event
+
+A user can create a custom event and pass it to a mapping function that is bound to the store:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Calling all of the mappings with event fixtures
+
+Users can call the mappings with test fixtures.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocking contract calls
+
+Users can mock contract calls:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+As demonstrated, in order to mock a contract call and hardcore a return value, the user must provide a contract address, function name, function signature, an array of arguments, and of course - the return value.
+
+Users can also mock function reverts:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking IPFS files (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Asserting the state of the store
+
+Users are able to assert the final (or midway) state of the store through asserting entities. In order to do this, the user has to supply an Entity type, the specific ID of an Entity, a name of a field on that Entity, and the expected value of the field. Here's a quick example:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interacting with Event metadata
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Asserting variable equality
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Users can assert that an entity does not exist in the store. The function takes an entity type and an id. If the entity is in fact in the store, the test will fail with a relevant error message. Here's a quick example of how to use this functionality:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+You can print the whole store to the console using this helper function:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Expected failure
+
+Users can have expected test failures, using the shouldFail flag on the test() functions:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+If the test is marked with shouldFail = true but DOES NOT fail, that will show up as an error in the logs and the test block will fail. Also, if it's marked with shouldFail = false (the default state), the test executor will crash.
+
+### Logging
+
+Having custom logs in the unit tests is exactly the same as logging in the mappings. The difference is that the log object needs to be imported from matchstick-as rather than graph-ts. Here's a simple example with all non-critical log types:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Users can also simulate a critical failure, like so:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Logging critical errors will stop the execution of the tests and blow everything up. After all - we want to make sure you're code doesn't have critical logs in deployment, and you should notice right away if that were to happen.
+
+### Testing derived fields
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testing dynamic data sources
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Example below:
+
+First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+And then we have the test using one of the methods in the dataSourceMock namespace to set a new return value for all of the dataSource functions:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Notice that dataSourceMock.resetValues() is called at the end. That's because the values are remembered when they are changed and need to be reset if you want to go back to the default values.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Test Coverage
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Prerequisites
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Export your handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Usage
+
+Once that's all set up, to run the test coverage tool, simply run:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Test run time duration in the log output
+
+The log output includes the test run duration. Here's an example:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Common compiler errors
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Додаткові матеріали
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Feedback
+
+If you have any questions, feedback, feature requests or just want to reach out, the best place would be The Graph Discord where we have a dedicated channel for Matchstick, called 🔥| unit-testing.

From a1974ad631ff82e34d39f19a6d82fde8ced50de3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:29 -0500
Subject: [PATCH 0886/3820] New translations transferring-a-subgraph.mdx
 (Ukrainian)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/uk/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/uk/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 614b12992d4e27351b7d4a8c1f48140ef8d570a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:30 -0500
Subject: [PATCH 0887/3820] New translations graphql-api.mdx (Ukrainian)

---
 .../uk/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/uk/subgraphs/querying/graphql-api.mdx b/website/pages/uk/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..2ffcb85e4019
--- /dev/null
+++ b/website/pages/uk/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Examples
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sorting
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Example
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Example for nested entity sorting
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Pagination
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Query the first 10 tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtering
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Example for range filtering
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for block filtering
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for nested entity filtering
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+This can be useful if you are looking to fetch only entities whose child-level entities meet the provided conditions.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logical operators
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### All Filters
+
+Full list of parameter suffixes:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Time-travel queries
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltext Search Queries
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Fulltext search operators:
+
+| Symbol | Operator    | Description                                                                                                                          |
+| ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
+
+#### Examples
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validation
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Subgraph Metadata
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: the hash of the block
+- number: the block number
+- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 5d830017593ff417235b78b7fc05963d45bf90ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:31 -0500
Subject: [PATCH 0888/3820] New translations python.mdx (Ukrainian)

---
 .../pages/uk/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/querying/python.mdx

diff --git a/website/pages/uk/subgraphs/querying/python.mdx b/website/pages/uk/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..c10d7a0e57ab
--- /dev/null
+++ b/website/pages/uk/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Getting Started
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 1f6dd057cf787c6639c9d7b8828211a5a7c2e4c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:32 -0500
Subject: [PATCH 0889/3820] New translations triggers.mdx (Ukrainian)

---
 website/pages/uk/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/uk/substreams/sps/triggers.mdx

diff --git a/website/pages/uk/substreams/sps/triggers.mdx b/website/pages/uk/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/uk/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From a1dade52142c696634cd2b0aff7c6e7464e73701 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:33 -0500
Subject: [PATCH 0890/3820] New translations overview.mdx (Chinese Simplified)

---
 website/pages/zh/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/zh/indexing/overview.mdx

diff --git a/website/pages/zh/indexing/overview.mdx b/website/pages/zh/indexing/overview.mdx
new file mode 100644
index 000000000000..fe2db7b5ddd2
--- /dev/null
+++ b/website/pages/zh/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+索引人是Graph 网络中的节点运营商，他们质押 Graph 通证 (GRT) 以提供索引和查询处理服务。 索引人通过他们的服务赚取查询费和索引奖励。 他们还根据 Cobbs-Douglas 回扣函数从回扣池中赚取收益，该回扣池与所有网络贡献者按他们的工作成比例共享。
+
+抵押在协议中的 GRT 会受到解冻期的影响，如果索引人是恶意的并向应用程序提供不正确的数据或索引不正确，则可能会被削减。 索引人也可以从委托人那里获得委托，为网络做出贡献。
+
+索引人根据子图的策展信号选择要索引的子图，其中策展人质押 GRT 以指示哪些子图是高质量的并应优先考虑。 消费者（例如应用程序）还可以设置索引人处理其子图查询的参数，并设置查询费用定价的偏好。
+
+<Difficulty level="ADVANCED" />
+
+## 常见问题
+
+### 成为网络索引人所需的最低份额是多少？
+
+索引人的最低抵押数量目前设置为 10万个 GRT。
+
+### 索引人的收入来源是什么？
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### 索引奖励如何分配？
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### 什么是索引证明 (POI)？
+
+网络中使用 POI 来验证索引人是否正在索引它们分配的子图。 在关闭该分配的分配时，必须提交当前时期第一个区块的 POI，才有资格获得索引奖励。 区块的 POI 是特定子图部署的所有实体存储交易的摘要，直到并包括该块。
+
+### 索引奖励什么时候分配？
+
+当分配活动在28个时期内分配时，分配会不断累积奖励。奖励由索引人收集，并在分配结束时分发。 这可以手动发生，每当索引人想要强制关闭它们时，或者在 28 个时期后，委托人可以关闭索引人的分配，但这会导致没有奖励。28 个时期是最大分配生命周期（现在，一个 时期持续约 24 小时）。
+
+### 可以监控待处理的索引人奖励吗？
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+许多社区制作的仪表板包含悬而未决的奖励值，通过以下步骤可以很容易地手动检查这些值:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### 争议是什么？ 在哪里可以查看？
+
+在争议期间，索引人的查询和分配都可以在Graph上进行争论。 争议期限因争议类型而异。 查询/证明有 7 个时期的争议窗口，而分配有 56 个时期。 在这些期限过后，不能对分配或查询提出争议。 当争议开始时，Fishermen需要至少 10000 GRT 的押金，押金将被锁定，直到争议结束并给出解决方案。 Fishermen是任何引发争议的网络参与者。
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- 如果争议被驳回，Fishermen存入的 GRT 将被消耗，争议的索引人将不会被削减。
+- 如果以平局方式解决争议，Fishermen的押金将被退还，并且争议的索引人不会被削减。
+- 如果争议被接受，Fishermen存入的 GRT 将被退回，有争议的索引人将被削减，Fishermen将获得被削减的 GRT的50%。
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### 什么是查询费返利？ 何时分配？
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+一旦分配已结束且争议期已过，索引人就可以要求回扣。 查询费用回扣根据查询费用减免和委托池比例分配给索引人及其委托人。
+
+### 什么是查询费减免和索引奖励减免？
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### 索引人如何知道要索引哪些子图？
+
+索引人可以通过应用高级技术来进行子图索引决策，从而使自己与众不同，但为了给出一个大致的概念，我们将讨论几个用于评估网络中子图的关键指标:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### 对硬件有什么要求？
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| 设置 | (CPU 数量) | (内存 GB) | (硬盘 TB) | (CPU 数量) | (内存 GB) |
+| -- | :------: | :-----: | :-----: | :------: | :-----: |
+| 小型 |     4    |    8    |    1    |     4    |    16   |
+| 标准 |     8    |    30   |    1    |    12    |    48   |
+| 中型 |    16    |    64   |    2    |    32    |    64   |
+| 大型 |    72    |   468   |   3.5   |    48    |   184   |
+
+### 索引人应该采取哪些基本的安全防范措施？
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## 基础设施
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+注意：为了支持敏捷扩展，建议在不同的节点集之间分开查询和索引问题：查询节点和索引节点。
+
+### 端口概述
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph 节点
+
+| 端口   | 用途                             | 路径                                                      | CLI 参数             | 环境 变量 |
+| ---- | ------------------------------ | ------------------------------------------------------- | ------------------ | ----- |
+| 8000 | GraphQL HTTP 服务 <br />（用于子图查询） | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | \--http-port       | -     |
+| 8001 | GraphQL WS <br />（用于子图订阅）      | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | \--ws-port         | -     |
+| 8020 | JSON-RPC <br />（用于管理部署）        | /                                                       | \--admin-port      | -     |
+| 8030 | 子图索引状态 API                     | /graphql                                                | \--index-node-port | -     |
+| 8040 | Prometheus 指标                  | /metrics                                                | \--metrics-port    | -     |
+
+#### 索引人服务
+
+| 端口   | 用途                                | 路径                                                              | CLI 参数          | 环境 变量                  |
+| ---- | --------------------------------- | --------------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP 服务器<br /> （用于付费子图查询） | /subgraphs/id/... <br /> /status <br /> /channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus 指标                     | /metrics                                                        | \--metrics-port | -                      |
+
+#### 索引人代理
+
+| 端口   | Purpose                | 路径     | CLI Argument               | Environment Variable                    |
+| ---- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | 索引人管理 API              | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### 在谷歌云上使用 Terraform 建立服务器基础设施
+
+> 注意：索引人可以选择使用AWS，Microsoft Azure, or Alibaba。
+
+#### 安装先决条件
+
+- 谷歌云 SDK
+- Kubectl 命令行工具
+- Terraform
+
+#### 创建一个谷歌云项目
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- 通过谷歌云认证并创建一个新项目。
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- 使用 Google Cloud Console 的计费页面为新项目启用计费。
+
+- 创建谷歌云配置。
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- 启用所需的 Google Cloud API。
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- 创建一个服务账户。
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- 启用将在下一步中创建的数据库和 Kubernetes 集群之间的对等连接。
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- 创建最小的 terraform 配置文件（根据需要更新）。
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### 使用 Terraform 创建基础设施
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- 运行以下命令来创建基础设施。
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### 为索引人创建 Kubernetes 组件
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph 节点
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### 从来源开始
+
+#### 安装先决条件
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### 设置
+
+1. 启动 PostgreSQL 数据库服务器
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. 现在，所有的依赖关系都已设置完毕，启动 Graph节点。
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### 使用 Docker
+
+#### 先决条件
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### 设置
+
+1. 克隆Graph节点并导航到Docker目录。
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. 启动一个本地Graph节点，它将连接到你的以太坊端点。
+
+```sh
+docker-compose up
+```
+
+### 索引人组件
+
+要成功地参与网络，需要几乎持续的监控和互动，所以我们建立了一套 Typescript 应用程序，以方便索引人的网络参与。 有三个索引人组件。
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### 开始
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### 来自 NPM 包
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### 来自数据源
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### 使用 docker
+
+- 从注册表中提取图像
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+或从数据源本地生成图像
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- 运行组件
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### 使用 K8s 和 Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### 使用方法
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### 索引代理
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### 索引人服务
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### 索引人 CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### 使用Indexer CLI 管理索引人
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### 使用方法
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### 索引规则
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+数据模型：
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+索引规则用法示例:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### 操作队列CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- 第三方优化器工具或indexer-cli用户添加到队列的操作
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- 索引人可以监视操作队列以查看操作执行的历史记录，如果需要，可以在操作项执行失败时重新批准和更新操作项。操作队列提供排队和执行的所有操作的历史记录。
+
+数据模型：
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+数据源用法示例
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+请注意，分配管理支持的操作类型有不同的输入要求：
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - 所需的操作参数：
+    - 部署ID
+    - 数量
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - 所需的操作参数：
+    - 分配ID
+    - 部署ID
+  - 可选操作参数：
+    - poi
+    - force（使用提供的POI的力量，即使它与图形节点提供的不匹配)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - 所需的操作参数：
+    - 分配ID
+    - 部署ID
+    - 数量
+  - 可选操作参数：
+    - poi
+    - force（使用提供的POI的力量，即使它与图形节点提供的不匹配)
+
+#### 成本模式
+
+成本模型根据市场和查询属性为查询提供动态定价。索引人服务与网关共享一个成本模型，用于它们打算响应查询的每个子图。反过来，网关使用成本模型对每个查询进行索引人选择决策，并与选定的索引人协商付款。
+
+#### Agora
+
+Agora 语言提供了一种灵活的格式来声明查询的成本模型。 Agora 价格模型是一系列的语句，它们按照 GraphQL 查询中每个顶层查询的顺序执行。 对于每个顶层查询，第一个与其匹配的语句决定了该查询的价格。
+
+语句由一个用于匹配 GraphQL 查询的谓词和一个成本表达式组成，该表达式在评估时输出一个以十进制 GRT 表示的成本。 查询的命名参数位置中的值可以在谓词中捕获并在表达式中使用。 也可以在表达式中设置全局，并代替占位符。
+
+成本模型示例：
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+使用上述模型的查询成本计算示例：
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### 应用成本模式
+
+成本模型是通过索引人 CLI 应用的，CLI 将它们传递给索引人代理的索引人管理 API，以便存储在数据库中。 然后，索引人服务将接收这些模型，并在网关要求时将成本模型提供给它们。
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## 与网络的交互
+
+### 在协议中进行质押
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### 批准代币
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### 质押代币
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### 分配的生命周期
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 6954d680188fdb3ff2f383fcacdca151db5065b5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:34 -0500
Subject: [PATCH 0891/3820] New translations tap.mdx (Chinese Simplified)

---
 website/pages/zh/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/zh/indexing/tap.mdx

diff --git a/website/pages/zh/indexing/tap.mdx b/website/pages/zh/indexing/tap.mdx
new file mode 100644
index 000000000000..de09d72fa74a
--- /dev/null
+++ b/website/pages/zh/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## 概述
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### 要求
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+注意：
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From 865c32b6044b522026fb84e73fd8858d541a3532 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:35 -0500
Subject: [PATCH 0892/3820] New translations graph-node.mdx (Chinese
 Simplified)

---
 .../pages/zh/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/zh/indexing/tooling/graph-node.mdx

diff --git a/website/pages/zh/indexing/tooling/graph-node.mdx b/website/pages/zh/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..353ada8687dd
--- /dev/null
+++ b/website/pages/zh/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph 节点
+---
+
+Graph节点是索引子图的组件，并使生成的数据可通过GraphQL API进行查询。因此，它是索引人堆栈的中心，Graph节点的正确运作对于运行成功的索引人至关重要。
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph 节点
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL 数据库
+
+Graph节点的主存储区，这是存储子图数据、子图元数据以及子图不可知的网络数据（如区块缓存和eth_call缓存）的地方。
+
+### 网络客户端
+
+为了索引网络，Graph节点需要通过以太坊兼容的JSON-RPC访问网络客户端。此RPC可能连接到单个以太坊客户端，也可能是跨多个客户端进行负载平衡的更复杂的设置。
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS节点
+
+子图部署元数据存储在IPFS网络上。Graph节点主要在子图部署期间访问IPFS节点，以获取子图清单和所有链接文件。网络索引人不需要托管自己的IPFS节点。网络的IPFS节点托管于https://ipfs.network.thegraph.com。
+
+### Prometheus指标服务器
+
+为了实现监控和报告，Graph节点可以选择将指标记录到Prometheus指标服务器。
+
+### 从来源开始
+
+#### 安装先决条件
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### 设置
+
+1. 启动 PostgreSQL 数据库服务器
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. 现在，所有的依赖关系都已设置完毕，启动 Graph节点。
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Kubernetes入门
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### 端口
+
+当运行Graph Node时，会暴露以下端口：
+
+| 端口   | 用途                             | 路径                                                      | CLI 参数             | 环境 变量 |
+| ---- | ------------------------------ | ------------------------------------------------------- | ------------------ | ----- |
+| 8000 | GraphQL HTTP 服务 <br />（用于子图查询） | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | \--http-port       | -     |
+| 8001 | GraphQL WS <br />（用于子图订阅）      | /subgraphs/id/... <br /> <br /> /subgraphs/name/.../... | \--ws-port         | -     |
+| 8020 | JSON-RPC <br />（用于管理部署）        | /                                                       | \--admin-port      | -     |
+| 8030 | 子图索引状态 API                     | /graphql                                                | \--index-node-port | -     |
+| 8040 | Prometheus 指标                  | /metrics                                                | \--metrics-port    | -     |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## 高级 Graph 节点配置
+
+最简单的是，Graph节点可以使用Graph节点的单个实例、单个PostgreSQL数据库、IPFS节点和要索引的子图所需的网络客户端来操作。
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> 使用配置文件时，不能使用选项--postgres-url、--postgres-secondary-hosts和--postgres-host-weights。
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### 多个 Graph 节点
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> 请注意，可以将多个Graph节点配置为使用同一个数据库，该数据库本身可以通过分片进行水平扩展。
+
+#### 部署规则
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+部署规则配置示例：
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### 专用查询节点
+
+通过在配置文件中包含以下内容，可以将节点配置为显式查询节点：
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+任何--node-id与正则表达式匹配的节点都将被设置为只响应查询。
+
+#### 通过分片扩展数据库
+
+对于大多数用例，单个Postgres数据库足以支持graph节点实例。当一个graph节点实例超过一个Postgres数据库时，可以将graph节点的数据存储拆分到多个Postgres数据库中。所有数据库一起构成graph节点实例的存储。每个单独的数据库都称为分片。
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+当您的现有数据库无法跟上Graph节点给它带来的负载时，以及当无法再增加数据库大小时，分片变得非常有用。
+
+> 在开始使用分片之前，通常最好使单个数据库尽可能大。一个例外是查询流量在子图之间分配非常不均匀；在这些情况下，如果将高容量子图保存在一个分片中，而将其他所有内容都保存在另一个分片上，这会有很大的帮助，因为这种设置使高容量子图的数据更有可能保留在数据库内部缓存中，而不会被低容量子图中不需要的数据所取代。
+
+在配置连接方面，首先将 postgresql.conf 中的 max_connections 设置为400（或甚至200），然后查看 store_connection_wait_time_ms 和 store_connecion_checkout_count Prometheus 度量。明显的等待时间（任何超过5ms的时间）表明可用连接太少；高等待时间也将由数据库非常繁忙（如高CPU负载）引起。然而，如果数据库在其他方面看起来很稳定，那么高等待时间表明需要增加连接数量。在配置中，每个graph节点实例可以使用的连接数是一个上限，如果不需要，Graph节点将不会保持连接打开。
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### 专用区块摄取
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### 支持多个网络
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- 多个网络。
+- 每个网络有多个提供程序（这可以允许跨提供程序分配负载，也可以允许配置完整节点和归档节点，如果给定的工作负载允许，Graph Node更喜欢便宜些的提供程序）。
+- 其他提供商详细信息，如特征、身份验证和提供程序类型（用于实验性Firehose支持）。
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### 环境变量
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### 持续部署
+
+使用高级配置操作缩放索引设置的用户可以从使用Kubernetes管理Graph节点中受益。
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### 管理Graph节点
+
+给定一个正在运行的 Graph 节点（或多個 Graph 节点！），接下来的挑战是如何跨这些节点管理部署的子图。Graph 节点覆盖了一系列工具，以帮助管理子图。
+
+#### 日志
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+默认情况下，Graph Node通过8040端口上的Prometheus端点提供指标。然后可以使用Grafana来可视化这些指标。
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### 使用子图
+
+#### 索引状态API
+
+默认情况下，在端口8030/graphql上可用，索引状态API公开了一系列方法，用于检查不同子图的索引状态、检查索引证明、检查子图特征等。
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### 索引性能
+
+索引过程有三个独立的部分：
+
+- 正在从提供程序获取感兴趣的事件
+- 使用适当的处理程序按顺序处理事件（这可能涉及调用状态链，并从存储中获取数据）
+- 将生成的数据写入存储
+
+这些阶段是流水线的（即可以并行执行），但它们彼此依赖。如果子图索引速度慢，则根本原因将取决于特定的子图。
+
+索引速度慢的常见原因：
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- 执行期间大量的存储交互
+- 要保存到存储的大量数据
+- 要处理的大量事件
+- 拥挤节点的数据库连接时间慢
+- 提供商本身落后于链头
+- 在链头从提供商获取新收据的速度较慢
+
+子图索引度量可以帮助诊断索引速度慢的根本原因。在某些情况下，问题在于子图本身，但在其他情况下，改进的网络提供商、减少的数据库冲突和其他配置改进可以显著提高索引性能。
+
+#### 失败的子图
+
+在为子图编制索引期间，如果遇到意外数据、某些组件未按预期工作，或者事件处理程序或配置中存在错误，则子图可能会失败。有两种常见的故障类型：
+
+- 确定性故障：这些故障不会通过重试解决
+- 非确定性故障：这些故障可能是由于提供程序的问题，或者是一些意外的Graph节点错误。当发生非确定性故障时，Graph节点将重试失败的处理程序，并随着时间的推移而后退。
+
+在某些情况下，索引人可能会解决故障（例如，如果错误是由于没有正确类型的提供程序导致的，则添加所需的提供程序将允许继续索引）。然而，在其他情况下，需要更改子图代码。
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### 区块和调用缓存
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+如果怀疑区块缓存不一致，例如tx收据丢失事件：
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. 如果区块与提供程序匹配，则可以直接针对提供程序调试问题。
+
+#### 查询问题和错误
+
+一旦子图被索引，索引人就可以期望通过子图的专用查询端点来服务查询。如果索引人希望为大量查询量提供服务，建议使用专用查询节点，如果查询量非常大，索引人可能需要配置副本分片，以便查询不会影响索引过程。
+
+然而，即使使用专用的查询节点和副本，某些查询也可能需要很长时间才能执行，在某些情况下还会增加内存使用量，并对其他用户的查询时间产生负面影响。
+
+没有一个"万灵丹"，而是一系列用于预防、诊断和处理慢速查询的工具。
+
+##### 查询缓存
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### 分析查询
+
+有问题的查询通常以两种方式之一出现。在某些情况下，用户自己报告给定的查询很慢。在这种情况下，挑战是诊断缓慢的原因——无论是一般问题，还是特定于子图或查询。如果可能的话，当然要解决它。
+
+在其他情况下，触发因素可能是查询节点上的高内存使用率，在这种情况下，首要挑战是要确定导致问题的查询。
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+针对慢查询，索引器有几个选项。当然，他们可以改变成本模型，显著增加发送有问题查询的成本。这可能导致该查询的频率降低。然而，这通常并不能解决问题的根本原因。
+
+##### 账户式优化
+
+存储实体的数据库表通常有两种类型：“类交易”，即实体一旦创建，就永远不会更新，即存储类似于金融交易列表的内容；“类账户”，即经常更新实体，即存储每次记录交易时都会修改的类似金融账户的内容。类账户表的特点是，它们包含大量实体版本，但不同的实体相对较少。通常，在这种表中，不同实体的数量是行总数的1%（实体版本）。
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### 删除子图
+
+> 这是一项新功能，将在Graph Node 0.29.x中提供。
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From dc9a94e63203b1dfe0c14f093aac61aa95b34aca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:36 -0500
Subject: [PATCH 0893/3820] New translations advanced.mdx (Chinese Simplified)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/zh/subgraphs/developing/creating/advanced.mdx b/website/pages/zh/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..c45246f33212
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## 概述
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## 非致命错误
+
+在默认情况下，已同步子图上的索引错误会导致子图失败并停止同步。 子图也可以配置为忽略引发错误的处理程序所做的更改, 在出现错误时继续同步。 这使子图作者有时间更正他们的子图，同时继续针对最新区块提供查询，尽管由于导致错误的代码问题，结果可能会不一致。 请注意，某些错误仍然总是致命的，要成为非致命错误，首先需要确定相应的错误是确定性的错误。
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+启用非致命错误需要在子图清单上设置以下功能标志：
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+文件数据源是一种新的子图功能，用于以稳健、可扩展的方式在索引期间访问链下数据。文件数据源支持从IPFS和Arweave获取文件。
+
+> 这也为链外数据的确定性索引以及引入任意HTTP源数据奠定了基础。
+
+### 概述
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### 升级指南
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### 添加新的实体类型，当找到文件时将更新该类型
+
+文件数据源不能访问或更新基于链的实体，但必须更新特定于文件的实体。
+
+这可能意味着将现有实体中的字段拆分为单独的实体，并链接在一起。
+
+原始合并实体：
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+新拆分实体：
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+如果母实体与生成的文件数据源实体之间的关系为1:1，则最简单的模式是通过使用IPFS CID作为查找将母实体链接到生成的文件实体。如果您在建模新的基于文件的实体时遇到困难，请联系Discord！
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+这是在识别出感兴趣的文件时生成的数据源。
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### 创建新处理程序以处理文件
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+示例处理程序：
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### 需要时生成文件数据源
+
+现在，您可以在执行基于链的处理程序期间创建文件数据源：
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+例子:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = "QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm"
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+这将创建一个新的文件数据源，该数据源将轮询Graph Node配置的IPFS或Arweave端点，如果未找到文件，则进行重试。当找到文件时，文件数据源处理程序将被执行。
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+祝贺您，您正在使用文件数据源！
+
+#### 将你的子图部署
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### 限制
+
+文件数据源处理程序和实体与其他子图实体隔离，确保它们在执行时是确定的，并确保基于链的数据源不受污染。具体来说:
+
+- 文件数据源创建的实体是不可变的，不能更新
+- 文件数据源处理程序无法访问其他文件数据源中的实体
+- 基于链的处理程序无法访问与文件数据源关联的实体
+
+> 虽然这个约束对于大多数用例不应该是有问题的，但是对于某些用例，它可能会引入复杂性。如果您在子图中基于文件数据建模时遇到问题，请通过 Discord 与我们联系！
+
+此外，不可能从文件数据源创建数据源，无论是线上数据源还是其他文件数据源。这项限制将来可能会取消。
+
+#### 最佳实践
+
+如果要将 NFT 元数据链接到相应的代币，请使用元数据的 IPFS hash从代币实体引用元数据实体。使用 IPFS hash作为 ID 保存元数据实体。
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> 我们正在努力改进上述建议，因此查询只返回“最新”版本。
+
+#### 已知问题
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### 例子
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### 参考
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### 嫁接到现有子图
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+因为嫁接是拷贝而不是索引基础数据，所以子图同步到所需区块比从头开始索引要快得多，尽管对于非常大的子图，初始数据拷贝仍可能需要几个小时。 在初始化嫁接子图时，Graph 节点将记录有关已复制的实体类型的信息。
+
+嫁接子图可以使用一个 GraphQL 模式 schema，该模式与基子图之一不同，但仅与基子图兼容。它本身必须是一个有效的子图模式，但是可以通过以下方式偏离基子图的模式：
+
+- 它添加或删除实体类型
+- 它从实体类型中删除属性
+- 它将可为空的属性添加到实体类型
+- 它将不可为空的属性转换为可空的属性
+- 它将值添加到枚举类型中
+- 它添加或删除接口
+- 它改变了实现接口的实体类型
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From e1c4ab2a069f1127c22768872dc550a3db546cef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:38 -0500
Subject: [PATCH 0894/3820] New translations api.mdx (Chinese Simplified)

---
 .../developing/creating/graph-ts/api.mdx      | 889 ++++++++++++++++++
 1 file changed, 889 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/zh/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/zh/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..3f5accd21882
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,889 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API 参考
+
+@graphprotocol/graph-ts 库提供以下 API：
+
+- 用于处理以太坊智能合约、事件、区块、交易和以太坊价值的以太坊 API。
+- 用于与图形节点交互，存储和加载实体的 存储 API。
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- 用于从 IPFS 加载文件的ipfs API。
+- 用于解析 JSON 数据的json API。
+- 使用加密功能的crypto API。
+- 用于在不同类型系统（例如 Ethereum、JSON、GraphQL 和 AssemblyScript）之间进行转换的低级原语。
+
+### 版本
+
+子图清单中的 `apiVersion` 指定了由 Graph Node 运行的特定子图的映射 API 版本。
+
+|   版本  | Release 说明                                                                                                                                                                                                                                               |
+| :---: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+| 0.0.7 | 添加了 `TransactionReceipt` 和 `Log` 类到以太坊类型。<br />已将 `receipt` 字段添加到Ethereum Event对象。                                                                                                                                                                       |
+| 0.0.6 | 向Ethereum Transaction对象添加了 nonce 字段 向 Etherum Block对象添加<br /> baseFeePerGas字段                                                                                                                                                                            |
+| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+| 0.0.4 | 已向 Ethereum SmartContractCall对象添加了 `functionSignature` 字段。                                                                                                                                                                                               |
+| 0.0.3 | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+| 0.0.2 | 已向Ethereum Transaction对象添加了 `input` 字段。                                                                                                                                                                                                                  |
+
+### 内置类型
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+以下额外的类型由 `@graphprotocol/graph-ts` 提供。
+
+#### 字节数组
+
+```typescript
+从'@graphprotocol/graph-ts'导入{ ByteArray }
+```
+
+`ByteArray` 表示一个 `u8` 类型的数组。
+
+结构
+
+- `fromI32(x: i32): ByteArray` - 将 `x` 分解为字节。
+- `fromHexString(hex: string): ByteArray` - 输入长度必须是偶数。在十六进制字符串中添加 `0x` 前缀是可选的。
+
+类型转换
+
+- `toHexString(): string` - 转换为以 `0x` 前缀的十六进制字符串。
+- `toString(): string` - 将字节解释为 UTF-8 字符串。
+- `toBase58(): string` - 将字节编码为 base58 字符串。
+- `toU32(): u32` - 将字节解释为小端 `u32`。在溢出的情况下会抛出异常。
+- `toI32(): i32` - 将字节数组解释为小端 `i32`。在溢出的情况下会抛出异常。
+
+操作符
+
+- `equals(y: ByteArray): bool` – 可以写成 `x == y`。
+- `concat(other: ByteArray) : ByteArray` - 返回一个新的 `ByteArray`，由 `this` 直接跟随 `other` 构成。
+- `concatI32(other: i32) : ByteArray` - 返回一个新的 `ByteArray`，由 `this` 直接跟随 `other` 的字节表示构成。
+
+#### BigDecimal
+
+```typescript
+从“@Graphprotocol/graph-ts”导入{ BigDecimal }
+```
+
+BigDecimal 用于表示任意精度的小数。
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+结构
+
+- `constructor(bigInt: BigInt)` – 从一个 `BigInt` 创建一个 `BigDecimal`。
+- `static fromString(s: string): BigDecimal` – 从一个十进制字符串解析。
+
+类型转换
+
+- toString (): string - 打印为十进制字符串。
+
+数学方法
+
+- `plus(y: BigDecimal): BigDecimal` – 可以写成 `x + y`。
+- `minus(y: BigDecimal): BigDecimal` – 可以写成 `x - y`。
+- `times(y: BigDecimal): BigDecimal` – 可以写成 `x * y`。
+- `div(y: BigDecimal): BigDecimal` – 可以写成 `x / y`。
+- `equals(y: BigDecimal): bool` – 可以写成 `x == y`。
+- `notEqual(y: BigDecimal): bool` – 可以写成 `x != y`。
+- `lt(y: BigDecimal): bool` – 可以写成 `x < y`。
+- `le(y: BigDecimal): bool` – 可以写成 `x <= y`。
+- `gt(y: BigDecimal): bool` – 可以写成 `x > y`。
+- `ge(y: BigDecimal): bool` – 可以写成 `x >= y`。
+- `neg(): BigDecimal` - 可以写成 `-x`。
+
+#### BigInt
+
+```typescript
+从'@graphprotocol/graph-ts'导入{ BigInt }
+```
+
+`BigInt` 用于表示大整数。这包括以太坊中的类型 `uint32` 到 `uint256` 和 `int64` 到 `int256` 的数值。所有小于 `uint32` 的数值，比如 `int32`、`uint24` 或 `int8` 都被表示为 `i32`。
+
+BigInt 类具有以下 API：
+
+结构
+
+- `BigInt.fromI32(x: i32): BigInt` – 从 i32 创建一个 BigInt。
+
+- `BigInt.fromString(s: string): BigInt` – 从字符串解析一个 BigInt。
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – 将 bytes 解释为无符号的小端整数。如果你的输入是大端的，请先调用.reverse()。
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – 将 bytes 解释为有符号的小端整数。如果你的输入是大端的，请先调用.reverse()。
+
+  类型转换
+
+- `x.toHex(): string` – 将 BigInt 转换为十六进制字符的字符串。
+
+- `x.toString(): string` – 将 BigInt 转换为十进制数字字符串。
+
+- `x.toI32(): i32` – 将 BigInt 作为 i32 返回；如果值不适合 i32，则失败。最好先检查 x.isI32()。
+
+- `x.toBigDecimal(): BigDecimal` - 转换为没有小数部分的十进制数。
+
+数学方法
+
+- `x.plus(y: BigInt): BigInt` – 可以写成 `x + y`.
+- `x.minus(y: BigInt): BigInt` – 可以写成`x - y`.
+- `x.times(y: BigInt): BigInt` – 可以写成 `x * y`.
+- `x.div(y: BigInt): BigInt` – 可以写成 `x / y`.
+- `x.mod(y: BigInt): BigInt` – 可以写成 `x % y`.
+- `x.equals(y: BigInt): bool` – 可以写成 `x == y`.
+- `x.notEqual(y: BigInt): bool` – 可以写成 `x != y`.
+- `x.lt(y: BigInt): bool` – 可以写成 `x < y`.
+- `x.le(y: BigInt): bool` – 可以写成 `x <= y`.
+- `x.gt(y: BigInt): bool` – 可以写成 `x > y`.
+- `x.ge(y: BigInt): bool` – 可以写成 `x >= y`.
+- `x.neg(): BigInt` – 可以写成 `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – 除以一个十进制数，得到十进制数格式的结果。
+- `x.isZero(): bool` – 方便检查数字是否为零。
+- `x.isI32(): bool` – 检查数字是否适合i32类型。
+- `x.abs(): BigInt` – 绝对值。
+- `x.pow(exp: u8): BigInt` – 指数。
+- `bitOr(x: BigInt, y: BigInt): BigInt` – 可以写成 `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – 可以写成 `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – 可以写成 `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – 可以写成 `x >> y`.
+
+#### 类型化映射
+
+```typescript
+从'@graphprotocol/graph-ts'导入{ TypedMap }
+```
+
+`TypedMap` 可用于存储键值对。请参阅[此示例](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51)。
+
+TypedMap 类具有以下 API：
+
+- `new TypedMap<K, V>()` - 创建一个键类型为 `K`，值类型为 `V` 的空映射。
+- `map.set(key: K, value: V): void` – 将 `key` 的值设置为 `value`。
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – 返回键为 `key` 的键值对，如果映射中不存在该键，则返回 `null`。
+- `map.get(key: K): V | null` – 返回键为 `key` 的值，如果映射中不存在该键，则返回 `null`。
+- `map.isSet(key: K): bool` – 如果映射中存在 `key` 则返回 `true`，否则返回 `false`。
+
+#### 字节
+
+```typescript
+从 '@graphprotocol/graph-ts'导入{ Bytes }
+```
+
+字节用于表示任意长度的字节数组，包括字节类型的以太坊值、 bytes32等。
+
+`Bytes` 类扩展了 AssemblyScript 的 [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64)，支持所有 `Uint8Array` 的功能，以及以下新方法：
+
+结构
+
+- `fromHexString(hex: string): Bytes` - 将字符串 `hex` 转换为一个 `ByteArray`。字符串 `hex` 必须由偶数个十六进制数字组成，并且可选地以 `0x` 开头。
+- `fromI32(i: i32): Bytes` - 将 `i` 转换为一个字节数组。
+
+类型转换
+
+- `b.toHex()` – 返回表示数组中字节的十六进制字符串。
+- `b.toString()` – 将数组中的字节转换为 Unicode 字符串。
+- `b.toBase58()` – 将以太坊的字节数值转换为 base58 编码（用于 IPFS 哈希）。
+
+操作符
+
+- `b.concat(other: Bytes): Bytes` - 返回一个新的 `Bytes`，由 `this` 直接跟随 `other` 组成。
+- `b.concatI32(other: i32): ByteArray` - 返回一个新的 `Bytes`，由 `this` 直接跟随 `other` 的字节表示组成。
+
+#### 地址
+
+```typescript
+从 '@graphprotocol/graph-ts'导入{ Address }
+```
+
+`Address` 扩展了 `Bytes`，用于表示以太坊的 `address` 值。
+
+除了 `Bytes` API 之外，它还添加了以下方法：
+
+- `Address.fromString(s: string): Address` – 从十六进制字符串创建一个 `Address`。
+- `Address.fromBytes(b: Bytes): Address` – 从 `b` 创建一个 `Address`，`b` 必须恰好为 20 个字节长。传入长度不足或超过 20 字节的值将导致错误。
+
+### 商店API
+
+```typescript
+从 '@graphprotocol/graph-ts'导入 { store }
+```
+
+`store` API 允许从和到 Graph Node 存储加载、保存和删除实体。
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### 创建实体
+
+以下是从以太坊事件创建实体的常见模式。
+
+```typescript
+/ Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+如果在处理链时遇到 Transfer 事件，它会使用生成的 Transfer 类型(别名为 TransferEvent 以避免与实体类型的命名冲突) 传递给 handleTransfer 事件处理器。 此类型允许访问事件的母交易及其参数等数据。
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### 从存储中加载实体
+
+如果实体已经存在，则可以使用以下内容从存储中加载它：
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### 查找在区块中创建的实体
+
+截至 `graph-node` v0.31.0、`@graphprotocol/graph-ts` v0.30.0 和 `@graphprotocol/graph-cli` v0.49.0，所有实体类型上都提供了 `loadInBlock` 方法。
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> 注意: 如果在给定的区块中没有创建实体，则 `loadInBlock` 将返回 `null`，即使存储中存在具有给定 ID 的实体也是如此。
+
+#### 查找派生实体
+
+在 `graph-node` v0.31.0、`@graphprotocol/graph-ts` v0.31.0 和 `@graphprotocol/graph-cli` v0.51.0 中引入了 `loadRelated` 方法。
+
+这允许从事件处理程序中加载派生实体字段。例如，给定以下模式：
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+以下代码将加载Holder实体来源的Token实体：
+
+```typescript
+let holder = Holder.load('test-id')
+// 加载与给定持有人相关联的 Token 实体。
+let tokens = holder.tokens.load()
+```
+
+#### 更新现有实体
+
+有两种方法可以更新现有实体：
+
+1. 利用 Transfer.load(id)加载实体，在实体上设置属性，然后调用.save() 将其返回到存储。
+2. 使用 new Transfer(id)创建实体，在实体上设置属性，然后调用.save()将其保存到存储。 如果实体已经存在，则将更改合并到其中。
+
+由于生成的属性设置器，在大多数情况下更改属性是直截了当的：
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+也可以使用以下两条指令之一取消设置属性：
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+这只适用于可选属性，即在 GraphQL 中声明时没有使用 `!` 的属性。两个例子是 `owner: Bytes` 或 `amount: BigInt`。
+
+更新数组属性稍微复杂一些，因为从实体获取数组会创建该数组的副本。这意味着在更改数组后，必须显式地重新设置数组属性。以下假设 `entity` 有一个 `numbers: [BigInt!]!` 字段。
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### 从存储中删除实体
+
+目前无法通过生成的类型来删除实体。相反，要删除实体，需要将实体类型的名称和实体ID传递给 `store.remove` 方法：
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### 以太坊 API
+
+以太坊 API 提供对智能合约、公共状态变量、合约函数、事件、交易、区块和编码/解码以太坊数据的访问。
+
+#### 对以太坊类型的支持
+
+与实体一样，`graph codegen` 为子图中使用的所有智能合约和事件生成类。为此，合约 ABI 需要作为子图清单中数据源的一部分。通常，ABI 文件存储在一个名为 `abis/` 的文件夹中。
+
+通过生成的类，以太坊类型和内置类型之间的转换在幕后进行，这样子图作者就不必担心它们。
+
+以下示例说明了这一点。 给定一个子图模式，如
+
+```graphql
+type Transfer @entity {
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+对于以太坊上的 `Transfer(address,address,uint256)` 事件签名，类型为 `address`、`address` 和 `uint256` 的 `from`、`to` 和 `amount` 值被转换为 `Address` 和 `BigInt`，从而允许它们传递给 `Transfer` 实体的 `Bytes!` 和 `BigInt!` 属性：
+
+```typescript
+let id = event.transaction.hash.toHex()
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### 事件和区块/交易数据
+
+传递给事件处理程序的以太坊事件（例如前面示例中的 `Transfer` 事件）不仅提供对事件参数的访问，还提供对其父事务和它们所在的区块的访问。以下数据可以从 `event` 实例中获取（这些类是 `graph-ts` 中的 `ethereum` 模块的一部分）：
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### 访问智能合约状态
+
+由 `graph codegen` 生成的代码还包括用于子图中使用的智能合约的类。这些类可以用于访问智能合约在当前区块上的公共状态变量和调用函数。
+
+一种常见的模式是访问事件起源的合约。 这是通过以下代码实现的：
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+这里将 `Transfer` 别名为 `TransferEvent`，以避免与实体类型产生命名冲突。
+
+只要以太坊上的 `ERC20Contract` 有一个名为 `symbol` 的公共只读函数，就可以使用 `.symbol()` 来调用它。对于公共状态变量，将自动生成一个同名的方法。
+
+作为子图一部分的任何其他合约都可以从生成的代码中导入，并且可以绑定到一个有效地址。
+
+#### 处理重复调用
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### 编码/解码 ABI
+
+数据可以按照以太坊的 ABI 编码格式使用 `ethereum` 模块中的 `encode` 和 `decode` 函数进行编码和解码。
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+查询更多的信息：
+
+- [ABI 规范](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- 您可以使用[Rust Ethereum ABI 库/CLI](https://github.com/rust-ethereum/ethabi)来进行编码和解码。
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### 日志记录 API
+
+```typescript
+从 '@graphprotocol/graph-ts'导入 { log }
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+`log` API 包括以下函数：
+
+- `log.debug(fmt: string, args: Array<string>): void` - 记录调试消息。
+- `log.info(fmt: string, args: Array<string>): void` - 记录信息消息。
+- `log.warning(fmt: string, args: Array<string>): void` - 记录警告消息。
+- `log.error(fmt: string, args: Array<string>): void` - 记录错误消息。
+- `log.critical(fmt: string, args: Array<string>): void` – 记录关键消息并终止子图。
+
+`log` API 接受一个格式字符串和一个字符串值数组。然后，它用数组中的字符串值替换占位符。第一个 `{}` 占位符会被数组中的第一个值替换，第二个 `{}` 占位符会被第二个值替换，依此类推。
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### 记录一个或多个值
+
+##### 记录单个值
+
+在下面的示例中，字符串值 "A" 被传入一个数组中成为 `['A']`，然后被记录：
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### 从现有数组记录单个条目
+
+在下面的示例中，尽管参数数组包含三个值，只有该数组的第一个值被记录了。
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### 从现有数组记录多个条目
+
+在日志消息字符串中，参数数组中的每个条目都需要自己的占位符 {}。下面的示例包含了日志消息中的三个占位符 {}。因此，myArray 中的所有三个值都被记录。
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### 从现有数组记录特定条目
+
+要在数组中显示特定值，必须提供它的索引值。
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### 记录事件信息
+
+下面的例子记录了一个事件的区块号、区块hash和交易hash：
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+从 '@graphprotocol/graph-ts'导入{ ipfs }
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+给定一个 IPFS hash或路径，从 IPFS 读取文件的过程如下：
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**注意:** 目前 `ipfs.cat` 不是确定性的。如果在请求超时之前无法从 IPFS 网络检索到文件，则会返回 `null`。因此，始终值得检查结果是否为 `null`。
+
+还可以使用 ipfs.map 以流式处理的方式处理较大的文件。该函数需要 IPFS 文件的哈希或路径、回调函数的名称以及修改其行为的标志：
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+当前仅支持的标志是 `json`，必须传递给 `ipfs.map`。使用 `json` 标志时，IPFS 文件必须由一系列 JSON 值组成，每行一个值。`ipfs.map` 的调用将读取文件中的每一行，将其反序列化为 `JSONValue` 并为每个值调用回调函数。然后，回调函数可以使用实体操作将数据存储到 `JSONValue` 中。仅当调用 `ipfs.map` 的处理程序成功完成时，才会存储实体更改；在此期间，它们将保留在内存中，因此 `ipfs.map` 可以处理的文件大小受到限制。
+
+成功时，`ipfs.map` 返回 `void`。如果回调的任何调用导致错误，则调用 `ipfs.map` 的处理程序将被中止，并且子图被标记为失败。
+
+### Crypto API
+
+```typescript
+从'@graphprotocol/graph-ts'导入{ crypto }
+```
+
+`crypto` API 为映射中的使用提供了加密函数。目前，只有一个函数可用：
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+从'@graphprotocol/graph-ts'导入{ json, JSONValueKind }
+```
+
+JSON 数据可以使用 json API 进行解析：
+
+- `json.fromBytes(data: Bytes): JSONValue` – 从有效的 UTF-8 序列的 `Bytes` 数组中解析 JSON 数据
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – `json.fromBytes` 的安全版本，如果解析失败，则返回错误变体
+- `json.fromString(data: string): JSONValue` – 从有效的 UTF-8 `String` 解析 JSON 数据
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – `json.fromString` 的安全版本，如果解析失败，则返回错误变体
+
+`JSONValue` 类提供了一种从任意 JSON 文档中提取值的方法。由于 JSON 值可以是布尔值、数字、数组等，因此 `JSONValue` 带有一个 `kind` 属性用于检查值的类型：
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+此外，还有一个方法用于检查值是否为 `null`：
+
+- `value.isNull(): boolean`
+
+当值的类型确定时，可以使用以下方法之一将其转换为[内置类型](#built-in-types)：
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - （然后使用上述 5 种方法之一将 `JSONValue` 转换）
+
+### 类型转换参考
+
+| 源类型                  | 目标类型                 | 转换函数                         |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() 或 s.toHex()  |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() 或 s.toHex()  |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toU64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### 数据源元数据
+
+您可以通过 `dataSource` 命名空间检查调用处理程序的数据源的合约地址、网络和上下文：
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entity 和 DataSourceContext
+
+基础的 `Entity` 类和子类 `DataSourceContext` 类都有助于动态设置和获取字段的帮助函数：
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setI32(key: string, value: i32): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### 清单文件中的 DataSourceContext
+
+`dataSources` 内的 `context` 部分允许您定义在子图映射中可访问的键值对。可用的类型包括 `Bool`、`String`、`Int`、`Int8`、`BigDecimal`、`Bytes`、`List` 和 `BigInt`。
+
+以下是一个 YAML 示例，说明了在 context 部分使用各种类型的情况：
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`：指定一个布尔值（`true` 或 `false`）。
+- `String`：指定一个字符串值。
+- `Int`：指定一个32位整数。
+- `Int8`：指定一个8位整数。
+- `BigDecimal`：指定一个十进制数。必须用引号括起来。
+- `Bytes`：指定一个十六进制字符串。
+- `List`：指定一个项目列表。每个项目都需要指定其类型和数据。
+- `BigInt`：指定一个大整数值。由于其较大，必须用引号括起来。
+
+该上下文可以在您的子图映射文件中访问，从而实现更加动态和可配置的子图。

From 82c5a935573b05bf8ad7f14b95114858aa4c581e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:39 -0500
Subject: [PATCH 0895/3820] New translations common-issues.mdx (Chinese
 Simplified)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/zh/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/zh/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..d8625f05baea
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: AssemblyScript的常见问题
+---
+
+在子图开发过程中，常常会遇到某些 <a href="https://github.com/AssemblyScript/assemblyscript">AssemblyScript</a> 问题。它们在调试难度范围内，但是，意识到它们可能会有所帮助。以下是这些问题的非详尽清单:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From d7eb1ef18178943ec911d8f5c1a51849e0a1e741 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:40 -0500
Subject: [PATCH 0896/3820] New translations unit-testing-framework.mdx
 (Chinese Simplified)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/zh/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/zh/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..1f4f9c098742
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: 单元测试框架
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## 开始
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+可以使用 Docker 方法和二进制方法在 WSL 上使用 Matchstick。由于 WSL 可能有点复杂，所以这里有一些提示，以防您遇到诸如
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+或者
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI 选项
+
+这将运行测试文件夹中的所有测试：
+
+```sh
+graph test
+```
+
+这将运行名为gravity.test.ts的测试和/或名为gravity的文件夹中的所有测试：
+
+```sh
+graph test Gravity
+```
+
+这将仅运行特定的测试文件：
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### 配置
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### 演示子图
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### 视频教程
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### 描述（）
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+例子:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### 测试（）
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+例子:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+或者
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+例子：
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+例子:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+例子：
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## 断言
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## 编写一个单元测试
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+假设我们有以下处理程序函数（以及两个帮助函数，以使我们的生活更轻松）：
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+我们首先必须在项目中创建一个测试文件。这是一个示例，说明它可能是什么样子的：
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- 我们正在设置我们的初始状态并添加一个自定义的 Gravatar 实体。
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- 我们断定存储的状态。那是怎么实现的呢？- 我们传递一个实体类型和 id 的唯一组合。然后我们检查该实体的一个特定字段，并断定它具有我们期望的值。我们为我们添加到存储的初始 Gravatar 实体，以及当处理函数被调用时被添加的两个 Gravatar 实体都做这个。
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+好了，我们创建了第一个测试！👏
+
+现在，为了运行我们的测试，您只需在子图根文件夹中运行以下命令：
+
+`graph test Gravity`
+
+如果一切顺利，您应该会收到以下信息：
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## 常见测试场景
+
+### 使用特定状态来填充存储
+
+用户能够用一组已知的实体来补充存储。下面是一个用Gravatar实体初始化存储的例子。
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### 用一个事件调用一个映射函数
+
+用户可以创建自定义事件并将其传递给绑定到存储的映射函数：
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### 用事件夹具调用所有的映射关系
+
+用户可以用测试夹具调用所有的映射关系。
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### 模拟合约调用
+
+用户可以模拟合约调用：
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+如图所示，为了模拟合约调用并实现返回值，用户必须提供合约地址、函数名、函数签名、参数数组，当然还有返回值。
+
+用户还可以模拟函数还原：
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### 模拟IPFS文件(from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### 断定存储的状态
+
+用户能够通过断定实体断定存储的最终（或中途）状态。为此，用户必须提供实体类型、实体的特定ID、该实体上的字段名称以及字段的预期值。下面是一个快速示例：
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### 与事件元数据交互
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### 断定变量相等
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+用户可以断定实体在存储中不存在。该函数接受实体类型和id。如果实体实际上在存储中，测试将失败，并显示相关错误消息。以下是如何使用此功能的快速示例：
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+您可以使用此助手功能将整个存储登载到控制台：
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### 预期故障
+
+使用test（）函数上的shouldFail标志，用户可能会出现预期的测试失败：
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+如果测试标记为should fail=true但不失败，则将在日志中显示为错误，测试区块将失败。此外，如果标记为shouldFail=false（默认状态），测试执行器将崩溃。
+
+### 日志
+
+在单元测试中记录自定义日志与在映射中记录完全相同。不同之处在于，日志对象需要从matchstick-as 而不是graph-ts导入。下面是一个所有非关键日志类型的简单示例：
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+用户还可以模拟严重故障，如下所示：
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+记录关键错误将停止测试的执行，并使一切崩溃。毕竟，我们希望确保您的代码在部署中没有关键日志，如果发生这种情况，您应该立即注意。
+
+### 测试派生字段
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### 测试动态数据源
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+示例如下：
+
+首先，我们有以下事件处理程序（它被有意地重新用于展示模拟数据源）：
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+然后，我们使用dataSourceMock命名空间中的一个方法进行测试，为所有dataSource函数设置一个新返回值：
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+注意，dataSourceMock.resetValues（）在末尾被调用。这是因为值在更改时会被记住，如果要返回到默认值，则需要重新设置。
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## 测试覆盖率
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### 先决条件
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### 导出处理程序
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### 使用方法
+
+设置好后，要运行测试覆盖工具，只需运行：
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+希望这可以毫无问题地执行覆盖工具。您应该在终端中看到类似的内容：
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### 日志输出中的测试运行持续时间
+
+日志输出包括测试运行持续时间。下面是一个示例：
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## 常见编译器错误
+
+> 关键：无法从具有背景的有效模块创建WasmInstance：未知导入：wasi_snapshot_preview1:：尚未定义fd_write
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> 返回ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> 返回新ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## 其他资源
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## 反馈
+
+如果您有任何问题、反馈、特征请求或只是想与我们联系，最好的地方是 Graph Discord，我们有一个专门的 Matchstick 频道，名为 🔥| 单元测试。

From d28369b6fd86e029ee4469b6a57c362d8343cdbe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:41 -0500
Subject: [PATCH 0897/3820] New translations transferring-a-subgraph.mdx
 (Chinese Simplified)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/zh/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/zh/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 8deab1b88dab428eef27c2179404c7fe3fd4b775 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:42 -0500
Subject: [PATCH 0898/3820] New translations graphql-api.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/zh/subgraphs/querying/graphql-api.mdx b/website/pages/zh/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..dfea78d5e6ef
--- /dev/null
+++ b/website/pages/zh/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### 例子
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### 排序
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### 示例
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### 嵌套实体筛选示例
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### 分页
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+查询前10 个代币：
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {    tokens(first: 1000, where: { id_gt: $lastID }) {
+      id
+      owner
+    }
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### 过滤
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### 范围过滤示例
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### 区块过滤示例
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+如果您只想获取已经更改的实体，例如自上次轮询以来改变的实体，那么这将非常有用。或者也可以调查或调试子图中实体的变化情况(如果与区块过滤器结合使用，则只能隔离在特定区块中发生变化的实体)。
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### 嵌套实体筛选示例
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+如果您希望只获取其子级实体满足条件的实体，那么这可能很有用。
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### 逻辑运算符
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### 所有过滤器
+
+参数后缀的完整列表:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### 跨时间查询
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### 示例
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### 示例
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### 全文搜索查询
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+全文搜索运算符：
+
+| 符号    | 运算符         | 描述                                    |
+| ----- | ----------- | ------------------------------------- |
+| `&`   | `And`       | 用于将多个搜索词组合到包含所有提供词条的实体的过滤器中           |
+| |     | `Or`        | 由 or 运算符分隔的多个搜索词的查询，将返回与任何提供的词匹配的所有实体 |
+| `<->` | `Follow by` | 指定两个单词之间的距离。                          |
+| `:*`  | `Prefix`    | 使用前缀搜索词查找前缀匹配的单词（需要 2 个字符）            |
+
+#### 例子
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+可以将全文运算符进行组合来制作更复杂的过滤器。 在下面的查询示例中，使用前缀搜索运算符与其他运算符的结合，可以实现匹配所有以“lou”开头后，跟着“music”单词的日志实体。
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### 验证
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## 模式
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### 实体
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### 子图元数据
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+如果提供了区块，则元数据为该区块的元数据，如果未使用最新的索引区块。如果提供，则区块必须在子图的起始区块之后，并且小于或等于最近索引的区块。
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash：区块的哈希
+- number：区块编号
+- timestamp：区块的时间戳（如果可用）（当前仅适用于索引EVM网络的子图）
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 9d8573fa1a8ae8aff19c90a2be37540615232ef7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:43 -0500
Subject: [PATCH 0899/3820] New translations python.mdx (Chinese Simplified)

---
 .../pages/zh/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/querying/python.mdx

diff --git a/website/pages/zh/subgraphs/querying/python.mdx b/website/pages/zh/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..dcc3a34023e9
--- /dev/null
+++ b/website/pages/zh/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## 开始
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 86b31c06a2a4a557c53d216eaacf9cf73c7309cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:44 -0500
Subject: [PATCH 0900/3820] New translations triggers.mdx (Chinese Simplified)

---
 website/pages/zh/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/zh/substreams/sps/triggers.mdx

diff --git a/website/pages/zh/substreams/sps/triggers.mdx b/website/pages/zh/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/zh/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From f4e1ee82955fa897c0bd1b4ca7858175d2080d63 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:45 -0500
Subject: [PATCH 0901/3820] New translations overview.mdx (Urdu (Pakistan))

---
 website/pages/ur/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/ur/indexing/overview.mdx

diff --git a/website/pages/ur/indexing/overview.mdx b/website/pages/ur/indexing/overview.mdx
new file mode 100644
index 000000000000..dba342e3bf8a
--- /dev/null
+++ b/website/pages/ur/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+انڈیکسرز گراف نیٹ ورک میں نوڈ آپریٹرز ہیں جو انڈیکسنگ اور کیوری پراسیسنگ کی خدمات فراہم کرنے کے لیے گراف ٹوکنز (GRT) کو داؤ پر لگاتے ہیں۔ انڈیکسرز اپنی خدمات کے لیے کیوری فیس اور انڈیکسنگ کے انعامات حاصل کرتے ہیں۔ وہ کیوری فیس بھی کماتے ہیں جو ایک کفایتی چھوٹ کی تقریب کے مطابق چھوٹ دی جاتی ہیں.
+
+پروٹوکول میں داؤ پر لگائی گئی GRT پگھلنے کی مدت سے مشروط ہے اور اگر انڈیکسرز بدنیتی پر مبنی ہوں اور ایپلیکیشنز کو غلط ڈیٹا پیش کرتے ہیں یا اگر وہ غلط طریقے سے انڈیکس کرتے ہیں تو اسے کم کیا جا سکتا ہے. انڈیکسرز نیٹ ورک میں حصہ ڈالنے کے لیے ڈیلیگیٹرز کی جانب سے دیے گئے سٹیک کے لیے بھی انعامات حاصل کرتے ہیں.
+
+انڈیکسرز سب گراف کے کیوریشن سگنل کی بنیاد پر انڈیکس کرنے کے لیے سب گرافس کا انتخاب کرتے ہیں, جہاں کیوریٹرز GRT کو سٹیک کرتے ہیں تاکہ یہ ظاہر کیا جا سکے کہ کون سے سب گرافس اعلیٰ معیار کے ہیں اور انہیں ترجیح دی جانی چاہیے. صارفین (مثلاً ایپلی کیشنز) ایسے عوامل کا تعین کر سکتے ہیں جن کے لیے انڈیکسرز اپنے سب گرافس کے لیے کیوریز پر کارروائی کرتے ہیں اور کیوری کی فیس کی قیمتوں کے لیے ترجیحات طے کرتے ہیں.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### نیٹ ورک پر انڈیکسر بننے کے لیے کم از کم کتنا سٹیک درکار ہے?
+
+انڈیکسر کے لیے کم از کم سٹیک فی الحال 100 ہزار GRT پر سیٹ ہے.
+
+### انڈیکسر کے لیے آمدنی کے سلسلے کیا ہیں؟
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### انڈیکسنگ کے انعامات کیسے تقسیم کیے جاتے ہیں?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### انڈئکسنگ کا ثبوت (POI) کیا ہے؟
+
+POIs کو نیٹ ورک میں اس بات کی تصدیق کرنے کے لیے استعمال کیا جاتا ہے کہ ایک انڈیکسر ان سب گرافس کو انڈیکس کر رہا ہے جو انہوں نے مختص کیے ہیں. موجودہ ایپوک کے پہلے بلاک کے لیے ایک POI جمع کرانا ضروری ہے جب اس ایلوکیشن کے لیے ایلوکیشن کو بند کرتے ہوئے تاکہ انڈیکسنگ کے انعامات کے لیے اہل ہو سکے. ایک بلاک کے لیے POI تمام ہستیاں سٹور کی ٹرانزیکشنز کے لیے ایک ڈائجسٹ ہوتا ہے جس میں اس بلاک تک اور اس سمیت کسی مخصوص سب گراف کی تعیناتی ہوتی ہے.
+
+### انڈیکسنگ کے انعامات کب تقسیم کیے جاتے ہیں؟
+
+ایلوکیشنز مسلسل انعامات حاصل کر رہی ہوتی ہیں جب کہ وہ فعال ہیں اور 28 ایپوکس میں مختص کر دی جاتی ہیں. انعامات اینڈیکسرز کے ذریعے جمع کیے جاتے ہیں، اور ایلوکیشن کے بند ہوتے ہی تقسیم کر دیے جاتے ہیں. یہ یا تو دستی طور پر ہوتا ہے، جب بھی انڈیکسر انہیں زبردستی بند کرنا چاہتا ہے، یا 28 ایپوکس کے بعد ایک ڈیلیگیٹر انڈیکسر کے لیے ایلوکیشن کو بند کر سکتا ہے، لیکن اس کے نتیجے میں کوئی انعام نہیں ہوتا. 28 ایپوکس زیادہ سے زیادہ ایلوکیشن کا دورانیہ ہے (ابھی، ایک ایپوک تقریبا ~ 24 گھنٹے تک رہتا ہے).
+
+### کیا زیر غور انڈیکسنگ کے انعامات کی نگرانی کی جا سکتی ہے؟
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+کمیونٹی کے بنائے ہوئے بہت سے ڈیش بورڈز میں زیر التواء انعامات کی قدریں شامل ہیں اور ان اقدامات پر عمل کر کے انہیں آسانی سے دستی طور پر چیک کیا جا سکتا ہے:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### تنازعات کیا ہیں اور میں انہیں کہاں دیکھ سکتا ہوں?
+
+انڈیکسر کی کیوریز اور ایکوکیشنز دونوں تنازعات کی مدت کے دوران گراف پر متنازعہ ہوسکتے ہیں. تنازعہ کی نوعیت کے لحاظ سے تنازعہ کی مدت مختلف ہوتی ہے. کیوریز/attestations میں تنازعات کے 7 epochs ہوتے ہیں، جبکہ ایلوکیشنز میں 56 epochs ہوتے ہیں. یہ مدت گزر جانے کے بعد، ایلوکیشنز یا کیوریز میں سے کسی کے خلاف تنازعات نہیں کھولے جا سکتے. جب کوئی تنازعہ کھولا جاتا ہے تو، Fishermen کو کم از کم 10,000 GRT جمع کرنا ضروری ہے، جو تنازعہ کے حتمی ہونے اور حل ہونے تک locked رہیں گے. Fishermen کسی بھی نیٹ ورک کے شرکاء ہیں جو تنازعات کو کھولتے ہیں.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- اگر تنازعہ مسترد کر دیا جاتا ہے, تو Fishermen کی طرف سے جمع کردہ GRT کو جلا دیا جائے گا، اور متنازعہ انڈیکسر کی کٹوتی نہیں کی جائے گی.
+- اگر تنازعہ قرعہ اندازی کے طور پر طے پا جاتا ہے، تو Fishermen کی جمع رقم واپس کر دی جائے گی، اور متنازعہ انڈیکسر کی کٹوتی نہیں کی جائے گی.
+- اگر تنازعہ قبول کر لیا جاتا ہے، تو Fishermen کی طرف سے جمع کرائی گئی GRT واپس کر دی جائے گی، متنازعہ انڈیکسر کی کٹوتی کر لی جائے گی اور Fishermen کٹوتی کے GRT کا 50% کمائیں گے.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### کیوری فیس ری بیٹس کیا ہیں اور وہ کب تقسیم کی جاتی ہیں?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+ایک بار مختص کرنے کے بعد ریبیٹ انڈیکسر کے ذریعہ دعوی کرنے کے لئے دستیاب ہے۔ دعویٰ کرنے پر،کیوری فیس کی چھوٹ انڈیکسر اور ان کے ڈیلیگیٹرز کو کیوری فیس میں کٹوتی اور ایکسپونینشل ریبیٹ فنکشن کی بنیاد پر تقسیم کی جاتی ہے.
+
+### کیوری فی کٹ اور انڈیکسنگ ریوارڈ کٹ کیا ہے؟
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### انڈیکسر کیسے جانتے ہیں کہ کون سے سب گرافس کو انڈیکس کرنا ہے؟
+
+انڈیکسرز سب گراف انڈیکسنگ کے فیصلے کرنے کے لیے جدید تکنیکوں کو استعمال کر کے خود کو نمایاں کر سکتے ہیں لیکن ایک عمومی خیال دینے کے لیے ہم نیٹ ورک میں سب گراف کی جانچ کے لیے استعمال ہونے والی کئی کلیدی میٹرکس پر بات کریں گے:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### ہارڈ ویئر کی ضروریات کیا ہیں؟
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| سیٹ اپ  | Postgres<br />(CPUs) | Postgres<br />(GBs میں میموری) | Postgres<br />(TBs میں ڈسک) | VMs<br />(CPUs) | VMs<br />(GBs میں میموری) |
+| ------- | :------------------: | :----------------------------: | :-------------------------: | :-------------: | :-----------------------: |
+| چھوٹا   |           4          |                8               |              1              |        4        |             16            |
+| معیاری  |           8          |               30               |              1              |        12       |             48            |
+| درمیانہ |          16          |               64               |              2              |        32       |             64            |
+| بڑا     |          72          |               468              |             3.5             |        48       |            184            |
+
+### وہ کون سی چند بنیادی حفاظتی تدابیر ہیں جو ایک انڈیکسر کو اختیار کرنی چاہیے؟
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## انفراسٹرکچر
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+نوٹ: فرتیلی پیمائی کو سپورٹ کرنے کے لیے، یہ تجویز کیا جاتا ہے کہ کیوری اور انڈیکسنگ کے معاملات کو نوڈس کے مختلف سیٹس کے درمیان الگ کیا جائے: کیوری نوڈس اور انڈیکس نوڈس.
+
+### پورٹس کا جائزہ
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### گراف نوڈ
+
+| Port | Purpose                                             | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | --------------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(سب گراف کی کیوریز کے لیے) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(سب گراف سبسکرپشنز کے لیے)          | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(تعیناتیوں کے انتظام کے لیے)          | /                                              | \--admin-port      | -                    |
+| 8030 | سب گراف انڈیکسنگ اسٹیٹس API                         | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus میٹرکس                                   | /metrics                                       | \--metrics-port    | -                    |
+
+#### انڈیکسر سروس
+
+| Port | Purpose                                                     | Routes                                                      | CLI Argument    | Environment Variable   |
+| ---- | ----------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(ادا شدہ سب گراف کی کیوریز کے لیے) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus میٹرکس                                           | /metrics                                                    | \--metrics-port | -                      |
+
+#### انڈیکسر ایجنٹ
+
+| Port | Purpose                | Routes | CLI Argument               | Environment Variable                    |
+| ---- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | انڈیکسر مینجمنٹ API    | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### گوگل کلاؤڈ پر ٹیرا فورم کا استعمال کرتے ہوئے سرور کا بنیادی ڈھانچہ ترتیب دیں
+
+> نوٹ: انڈیکسرز متبادل طور پر AWS، Microsoft Azure، یا Alibaba استعمال کر سکتے ہیں.
+
+#### اولین ضروریات کو انسٹال کریں
+
+- Google Cloud SDK
+- Kubectl command line tool
+- Terraform
+
+#### گوگل کلاؤڈ پروجیکٹ بنائیں
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- گوگل کلاؤڈ کے ساتھ تصدیق کریں اور ایک نیا پروجیکٹ بنائیں.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- نئے پروجیکٹ کے لیے بلنگ کو فعال کرنے کے لیے گوگل کلاؤڈ کنسول کا بلنگ والا صفحہ استعمال کریں.
+
+- گوگل کلاؤڈ کنفگریشن بنائیں.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- مطلوبہ گوگل کلاؤڈ APIs کو فعال کریں.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- ایک سروس اکاؤنٹ بنائیں.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- ڈیٹا بیس اور Kubernetes کلسٹر کے درمیان پیئرنگ کو فعال کریں جو اگلے مرحلے میں بنائے جائیں گے.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- کم سے کم terraform کنفیگریشن فائل بنائیں (ضرورت کے مطابق اپ ڈیٹ کریں).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### انفراسٹرکچر بنانے کے لیے Terraform کا استعمال کریں
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- انفراسٹرکچر بنانے کے لیے درج ذیل کمانڈز چلائیں.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### انڈیکسر کے لیے Kubernetes اجزاء کی تخلیق
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### گراف نوڈ
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### سورس سے شروع کرنا
+
+#### اولین ضروریات کو انسٹال کریں
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### سیٹ اپ
+
+1. PostgreSQL ڈیٹا بیس سرور چالو کریں
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. اب جب کہ تمام انحصار سیٹ اپ ہو چکے ہیں، گراف نوڈ شروع کریں:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Docker کے ساتھ استعمال شروع کرنا
+
+#### شرطیں
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### سیٹ اپ
+
+1. گراف نوڈ کو کلون کریں اور Docker ڈائرکٹری پر جائیں:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. ایک مقامی گراف نوڈ شروع کریں جو آپ کے ایتھریم اینڈ پوائنٹ سے جڑے گا:
+
+```sh
+docker-compose up
+```
+
+### انڈیکسر کے اجزاء
+
+نیٹ ورک میں کامیابی کے ساتھ حصہ لینے کے لیے تقریباً مسلسل نگرانی اور تعامل کی ضرورت ہوتی ہے، اس لیے ہم نے انڈیکسرز نیٹ ورک کی شرکت کی سہولت کے لیے Typescript ایپلی کیشنز کا ایک مجموعہ بنایا ہے. انڈیکسر کے تین کمپونینٹس ہیں:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### شروع کرتے ہوئے
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### NPM پیکیجیز سے
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### سورس سے
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### docker استعمال کرتے ہوئے
+
+- ریجیسٹری سے تصاویر کو پل کریں
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+یا سورس سے مقامی طور پر تصاویر کو بلڈ کریں
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- اجزاء کو چلائیں
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### K8s اور Terraform کو استعمال کرتے ہوئے
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### استعمال
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### انڈیکسر ایجنٹ
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### انڈیکسر سروس
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### انڈیکسر CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### انڈیکسر CLI کا استعمال کرتے ہوئے انڈیکسر کا انتظام
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### استعمال
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### انڈیکسنگ کے قواعد
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+ڈیٹا ماڈل:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+انڈیکسنگ کے اصول کے استعمال کی مثال:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- فریق ثالث کا اصلاح کنندہ ٹول یا indexer-cli صارف کے ذریعے قطار میں ایکشن شامل کیا گیا
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- انڈیکسر ایکشن کے عمل کی تاریخ دیکھنے کے لیے action queue کی نگرانی کر سکتا ہے اور اگر ضرورت ہو تو ایکشن کے اجزاء کو دوبارہ منظور اور اپ ڈیٹ کر سکتا ہے اگر وہ عمل درآمد میں ناکام رہے. action queue تمام queued اور taken اعمال کی تاریخ فراہم کرتی ہے.
+
+ڈیٹا ماڈل:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+سورس سے استعمال کی مثال:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+نوٹ کریں کہ ایلوکیشن کے انتظام کے لیے معاون کارروائی کی اقسام میں مختلف ان پٹ تقاضے ہوتے ہیں:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - مطلوبہ ایکشن params:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - مطلوبہ ایکشن params:
+    - allocationID
+    - deploymentID
+  - اختیاری ایکشن params:
+    - poi
+    - فورس (فراہم کردہ POI استعمال کرنے والی فورس یہاں تک کہ اگر یہ گراف نوڈ کے فراہم کردہ سے مماثل نہیں ہے)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - مطلوبہ ایکشن params:
+    - allocationID
+    - deploymentID
+    - amount
+  - اختیاری ایکشن params:
+    - poi
+    - فورس (فراہم کردہ POI استعمال کرنے والی فورس یہاں تک کہ اگر یہ گراف نوڈ کے فراہم کردہ سے مماثل نہیں ہے)
+
+#### لاگت کے ماڈل
+
+لاگت کے ماڈل مارکیٹ اور کیوری کی خصوصیات پر مبنی کیوریز کے لیے متحرک قیمت فراہم کرتے ہیں. انڈیکسر سروس ہر سب گراف کے گیٹ ویز کے ساتھ لاگت ماڈل شیئر کرتی ہے جس کے لیے وہ کیوریز کا جواب دینا چاہتے ہیں. گیٹ وے، بدلے میں، فی کیوری انڈیکسر کے انتخاب کے فیصلے کرنے اور منتخب کردہ انڈیکسرز کے ساتھ ادائیگی پر بات چیت کرنے کے لیے لاگت ماڈلز کا استعمال کرتے ہیں.
+
+#### Agora
+
+Agora زبان کیوریز کے لیے لاگت ماڈل بنانے کے لیے ایک لچکدار فارمیٹ فراہم کرتی ہے. Agora لاگت کے ماڈل سٹیٹمنٹس کا ایک سلسلہ ہے جو GraphQL کیوری میں ہر اعلیٰ درجے کی کیوری کے لیے ترتیب دیتا ہے. ہر top-level کیوری کے لیے، پہلا بیان جو اس سے ملتا ہے اس کیوری کی قیمت کا تعین کرتا ہے.
+
+ایک بیان ایک پیشن گوئی پر مشتمل ہوتی ہے، جو GraphQL کی کیوریز کے ملاپ کے لیے استعمال ہوتی ہے، اور ایک cost expression جس کا جب اندازہ کیا جاتا ہے تو اعشاریہ GRT میں لاگت نکلتی ہے. کیوری کی نامزد argument پوزیشن میں اقدار کو پیش گوئی میں پکڑا جاسکتا ہے اور expression میں استعمال کیا جاسکتا ہے. Globals کو ایک expression میں placeholders کے لیے بھی سیٹ اور متبادل کیا جا سکتا ہے.
+
+مثال کا cost model:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+مندرجہ بالا ماڈل کا استعمال کرتے ہوئے کیوری کی قیمت کی مثال:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Cost ماڈل لاگو کرنا
+
+لاگت کے ماڈلز کا اطلاق انڈیکسر CLI کے ذریعے کیا جاتا ہے، جو ڈیٹا بیس میں ذخیرہ کرنے کے لیے انڈیکسر ایجنٹ کے انڈیکسر مینجمنٹ API کو بھیجتا ہے. اس کے بعد انڈیکسر سروس انہیں اٹھائے گی اور لاگت کے ماڈلز کو گیٹ ویز پر پیش کرے گی جب بھی وہ ان سے پوچھیں گے.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## نیٹ ورک کے ساتھ تعامل
+
+### پروٹوکول میں حصہ ڈالنا
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### ٹوکنز منظور کریں
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### سٹیک ٹوکنز
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### ایک ایلوکیشن کا دورانیہ
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 63034ac423f7fd69e62e61cec94f6654b95c2e97 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:46 -0500
Subject: [PATCH 0902/3820] New translations tap.mdx (Urdu (Pakistan))

---
 website/pages/ur/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/ur/indexing/tap.mdx

diff --git a/website/pages/ur/indexing/tap.mdx b/website/pages/ur/indexing/tap.mdx
new file mode 100644
index 000000000000..227fbfc0593f
--- /dev/null
+++ b/website/pages/ur/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## جائزہ
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### تقاضے
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+نوٹس:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From e60d28cac62fca6b79d36fd208e7d024d26c9cf6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:47 -0500
Subject: [PATCH 0903/3820] New translations graph-node.mdx (Urdu (Pakistan))

---
 .../pages/ur/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/ur/indexing/tooling/graph-node.mdx

diff --git a/website/pages/ur/indexing/tooling/graph-node.mdx b/website/pages/ur/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..0b6838fbf58e
--- /dev/null
+++ b/website/pages/ur/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: گراف نوڈ
+---
+
+گراف نوڈ وہ جزو ہے جو سب گراف کو انڈیکس کرتا ہے، اور نتیجے میں ڈیٹا کو GraphQL API کے ذریعے کیوری کے لیے دستیاب کرتا ہے. اس طرح یہ انڈیکسر اسٹیک میں مرکزی حیثیت رکھتا ہے، اور ایک کامیاب انڈیکسر چلانے کے لیے گراف نوڈ کا درست آپریشن بہت ضروری ہے.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## گراف نوڈ
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL ڈیٹا بیس
+
+گراف نوڈ کا مرکزی اسٹور، یہ وہ جگہ ہے جہاں سب گراف کا ڈیٹا ذخیرہ کیا جاتا ہے، ساتھ ہی سب گراف کے بارے میں میٹا ڈیٹا، اور سب گراف-اگنوسٹک نیٹ ورک ڈیٹا جیسے کہ بلاک کیشے، اور ایتھ_کال کیشے.
+
+### نیٹ ورک کلائنٹس
+
+کسی نیٹ ورک کو انڈیکس کرنے کے لیے، گراف نوڈ کو EVM سے مطابقت رکھنے والے JSON-RPC API کے ذریعے نیٹ ورک کلائنٹ تک رسائی کی ضرورت ہے۔ یہ RPC کسی ایک کلائنٹ سے منسلک ہو سکتا ہے یا یہ زیادہ پیچیدہ سیٹ اپ ہو سکتا ہے جو متعدد پر بیلنس لوڈ کرتا ہے.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS نوڈس
+
+سب گراف تعیناتی کا میٹا ڈیٹا IPFS نیٹ ورک پر محفوظ کیا جاتا ہے. گراف نوڈ بنیادی طور پر سب گراف کی تعیناتی کے دوران IPFS نوڈ تک رسائی حاصل کرتا ہے تاکہ سب گراف مینی فیسٹ اور تمام منسلک فائلوں کو حاصل کیا جا سکے. نیٹ ورک انڈیکسرز کو اپنے IPFص نوڈ کو ہوسٹ کرنے کی ضرورت نہیں ہے. نیٹ ورک کے لیے ایک IPFS نوڈ https://ipfs.network.thegraph.com پر ہوسٹ کیا گیا ہے.
+
+### Prometheus میٹرکس سرور
+
+نگرانی اور رپورٹنگ کو فعال کرنے کے لیے، گراف نوڈ اختیاری طور پر میٹرکس کو prometheus میٹرکس سرور پر لاگ کر سکتا ہے.
+
+### سورس سے شروع کرنا
+
+#### اولین ضروریات کو انسٹال کریں
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### سیٹ اپ
+
+1. PostgreSQL ڈیٹا بیس سرور چالو کریں
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. اب جب کہ تمام انحصار سیٹ اپ ہو چکے ہیں، گراف نوڈ شروع کریں:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Kubernetes کے ساتھ شروع کریں
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### پورٹس
+
+جب یہ چل رہا ہوتا ہے گراف نوڈ مندرجہ ذیل پورٹس کو بے نقاب کرتا ہے:
+
+| Port | Purpose                                             | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | --------------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(سب گراف کی کیوریز کے لیے) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(سب گراف سبسکرپشنز کے لیے)          | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(تعیناتیوں کے انتظام کے لیے)          | /                                              | \--admin-port      | -                    |
+| 8030 | سب گراف انڈیکسنگ اسٹیٹس API                         | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus میٹرکس                                   | /metrics                                       | \--metrics-port    | -                    |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## اعلی درجے کی گراف نوڈ کنفیگریشن
+
+اس کے آسان ترین طور پر، گراف نوڈ کو گراف نوڈ کے ایک انسٹینس, واحد PostgreSQL ڈیٹا بیس، ایک IPFS نوڈ، اور نیٹ ورک کلائنٹس کے ساتھ آپریٹ کیا جا سکتا ہے جیسا کہ سب گراف کو انڈیکس کرنے کے لیے ضرورت ہوتی ہے.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> کنفیگریشن فائل استعمال کرتے وقت، --postgres-url، --postgres-secondary-hosts اور --postgres-host-weights کے آپشنز استعمال کرنا ممکن نہیں ہے.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### متعدد گراف نوڈس
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> نوٹ کریں کہ ایک سے زیادہ گراف نوڈس کو ایک ہی ڈیٹا بیس کو استعمال کرنے کے لیے کنفیگر کیا جا سکتا ہے، جسے خود کو شارڈنگ کے ذریعے افقی طور پر سکیل کیا جا سکتا ہے.
+
+#### تعیناتی کے قواعد
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+مثال کی تعیناتی کے اصول کی کنفگریشن:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### وقف شدہ کیوری نوڈس
+
+نوڈس کو کنفیگریشن فائل میں درج ذیل کو شامل کرکے واضح طور پر کیوری نوڈس کے لیے کنفیگر کیا جاسکتا ہے:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+کوئی بھی نوڈ جس کا node-id-- ریگولر ایکسپریشن سے میل کھاتا ہے صرف کیوریز کا جواب دینے کے لیے ترتیب دیا جائے گا.
+
+#### شارڈنگ کے ذریعے ڈیٹا بیس کو بڑھانا
+
+زیادہ تر استعمال کے معاملات میں، ایک واحد Postgres ڈیٹا بیس گراف نوڈ کی انسٹینس کو سپورٹ کرنے کے لیے کافی ہے. جب ایک گراف نوڈ کی انسٹینس ایک واحد postgres ڈیٹا بیس سے بڑھ جاتی ہے، تو یہ ممکن ہے کہ گراف نوڈ کے ڈیٹا کے ذخیرہ کو متعدد پوسٹگریس ڈیٹا بیس میں تقسیم کیا جا سکے. تمام ڈیٹا بیس مل کر گراف نوڈ انسٹینس کا اسٹور بناتے ہیں. ہر انفرادی ڈیٹا بیس کو شارڈ کہا جاتا ہے.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+شارڈنگ مفید ہو جاتا ہے جب آپ کا موجودہ ڈیٹا بیس اس بوجھ کو برقرار نہیں رکھ سکتا جو گراف نوڈ اس پر ڈالتا ہے، اور جب ڈیٹا بیس کے سائز کو مزید بڑھانا ممکن نہ ہو.
+
+> عام طور پر یہ بہتر ہے کہ شارڈز کے ساتھ شروع کرنے سے پہلے، ایک ہی ڈیٹا بیس کو جتنا ہو سکے بڑا بنائیں. ایک استثناء وہ ہے جہاں کیوری ٹریفک کو سب گرافس کے درمیان بہت غیر مساوی طور پر تقسیم کیا جاتا ہے; ان حالات میں یہ بھاری طور پر مدد کر سکتا ہے اگر اعلی حجم کے سب گراف کو ایک شارڈ میں اور باقی سب کچھ دوسرے میں رکھا جائے کیونکہ اس سیٹ اپ سے یہ زیادہ امکان ہوتا ہے کہ زیادہ حجم والے سب گرافس کا ڈیٹا db-internal کیشے میں رہتا ہے اور ایسا نہیں ہوتا ہے کہ وہ کم حجم والے سب گرافس سے ڈیٹا کی جگہ لے لیں جس کی ضرورت نہیں ہے.
+
+کنکشن کنفیگر کرنے کے معاملے میں، postgresql.conf میں max_connections کے ساتھ شروع کریں 400 سیٹ کریں(یا شاید 200 بھی) اور store_connection_wait_time_ms اور store_connection_checkout_count Prometheus میٹرکس دیکھیں. قابل توجہ انتظار کے اوقات (5ms سے اوپر کی کوئی بھی چیز) اس بات کا اشارہ ہے کہ بہت کم کنکشن دستیاب ہیں; زیادہ انتظار کا وقت بھی ڈیٹا بیس کے بہت مصروف ہونے کی وجہ سے ہوگا (جیسے زیادہ CPU لوڈ). تاہم اگر ڈیٹا بیس بصورت دیگر مستحکم معلوم ہوتا ہے تو، زیادہ انتظار کے اوقات کنکشن کی تعداد بڑھانے کی ضرورت کی نشاندہی کرتے ہیں. کنفیگریشن میں، ہر گراف نوڈ انسٹینس کتنے کنکشن استعمال کر سکتا ہے ایک بالائی حد ہے، اور اگر گراف نوڈ کو ان کی ضرورت نہ ہو تو کنکشن کو کھلا نہیں رکھے گا.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### وقف شدہ بلاک انجیش
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### متعدد نیٹ ورکس کو سپورٹ کرنا
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- متعدد نیٹ ورکس
+- ایک سے زیادہ فراہم کنندگان فی نیٹ ورک (یہ فراہم کنندگان میں بوجھ کو تقسیم کرنے کی اجازت دے سکتا ہے، اور مکمل نوڈس کے ساتھ ساتھ آرکائیو نوڈس کی ترتیب کی بھی اجازت دے سکتا ہے، گراف نوڈ سستے فراہم کنندگان کو ترجیح دیتا ہے اگر کام کا بوجھ اجازت دیتا ہے).
+- فراہم کنندہ کی اضافی تفصیلات، جیسے خصوصیات، تصدیق اور فراہم کنندہ کی قسم (تجرباتی firehose سپورٹ کے لیے)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### ماحولیاتی تغیرات
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### مسلسل تعیناتی
+
+وہ صارفین جو اعلی درجے کی ترتیب کے ساتھ سکیلڈ انڈیکسنگ سیٹ اپ چلا رہے ہیں وہ اپنے گراف نوڈس کو Kubernetes کے ساتھ منظم کرنے سے فائدہ اٹھا سکتے ہیں.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### گراف نوڈ کا انتظام
+
+چلتے ہوئے گراف نوڈ (یا گراف نوڈس!) کو دیکھتے ہوئے، پھر چیلنج یہ ہے کہ ان نوڈس میں تعینات سب گراف کا انتظام کرنا. گراف نوڈ سب گرافس کو منظم کرنے میں مدد کے لیے ٹولز کی ایک رینج پیش کرتا ہے.
+
+#### لاگنگ
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+گراف نوڈ بطور ڈیفالٹ 8040 port پر prometheus endpoint کے ذریعے میٹرکس فراہم کرتا ہے. Grafana کو پھر ان metrics کو دیکھنے کے لیے استعمال کیا جا سکتا ہے.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### سب گرافس کے ساتھ کام کرنا
+
+#### انڈیکسنگ اسٹیٹس API
+
+پورٹ 8030/graphql پر بطور ڈیفالٹ دستیاب ہے، انڈیکسنگ اسٹیٹس API مختلف سب گرافس کے لیے انڈیکسنگ کی حیثیت کو جانچنے، انڈیکسنگ کے ثبوتوں کی جانچ، سب گراف کی خصوصیات کا معائنہ کرنے اور مزید بہت سے طریقوں کو ظاہر کرتا ہے.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### انڈیکسنگ کی کارکردگی
+
+انڈیکسنگ کے عمل کے تین الگ الگ حصے ہیں:
+
+- فراہم کنندہ سے دلچسپی کے ایوینٹس لانا
+- مناسب ہینڈلرز کے ساتھ ایوینٹس پر کارروائی کرنا (اس میں سٹیٹ کے لیے چین کو کال کرنا، اور اسٹور سے ڈیٹا حاصل کرنا شامل ہو سکتا ہے)
+- نتیجے کے ڈیٹا کو اسٹور پر لکھنا
+
+یہ مراحل پائپ لائنڈ ہیں (یعنی انہیں متوازی طور پر انجام دیا جا سکتا ہے)، لیکن وہ ایک دوسرے پر منحصر ہیں. جہاں سب گراف انڈیکس میں سست ہیں، بنیادی وجہ مخصوص سب گراف پر منحصر ہوگی.
+
+انڈیکسنگ میں سستی کی عام وجوہات:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- عمل درآمد کے دوران سٹور کے تعامل کی ایک بڑی مقدار
+- اسٹور میں محفوظ کرنے کے لیے ڈیٹا کی ایک بڑی مقدار
+- کارروائی کرنے کے لیے ایوینٹس کی ایک بڑی تعداد
+- ہجوم نوڈس کے لیے سست ڈیٹا بیس کنکشن کا وقت
+- فراہم کنندہ خود چین ہیڈ کے پیچھے پڑا ہے
+- فراہم کنندہ سے چین ہیڈ پر نئی رسیدیں لانے میں سست روی
+
+سب گراف انڈیکسنگ میٹرکس انڈیکسنگ کی سستی کی بنیادی وجہ کی تشخیص میں مدد کر سکتی ہے. کچھ معاملات میں، مسئلہ خود سب گراف کے ساتھ ہوتا ہے، لیکن دوسروں میں، بہتر نیٹ ورک فراہم کرنے والے، ڈیٹا بیس کے تنازعہ میں کمی اور دیگر ترتیب میں بہتری انڈیکسنگ کی کارکردگی کو نمایاں طور پر بہتر بنا سکتی ہے.
+
+#### ناکام سب گراف
+
+انڈیکسنگ کے دوران سب گرافس ناکام ہو سکتے ہیں، اگر وہ غیر متوقع ڈیٹا کا سامنا کرتے ہیں، کچھ جزو توقع کے مطابق کام نہیں کر رہا ہے، یا اگر ایونٹ ہینڈلرز یا کنفیگریشن میں کچھ بگ ہے۔ ناکامی کی دو عمومی قسمیں ہیں:
+
+- تعییناتی ناکامیاں: یہ وہ ناکامیاں ہیں جو دوبارہ کوششوں سے حل نہیں ہوں گی
+- غیر مقررہ ناکامیاں: یہ فراہم کنندہ کے ساتھ مسائل، یا کچھ غیر متوقع گراف نوڈ کی خرابی کی وجہ سے ہوسکتی ہیں. جب ایک غیر مقررہ ناکامی واقع ہوتی ہے تو، گراف نوڈ ناکام ہونے والے ہینڈلرز کو دوبارہ کوشش کرے گا، وقت کے ساتھ پیچھے ہٹتا ہے.
+
+بعض صورتوں میں ایک ناکامی کو انڈیکسر کے ذریعے حل کیا جا سکتا ہے (مثال کے طور پر اگر غلطی صحیح قسم کا فراہم کنندہ نہ ہونے کا نتیجہ ہے، مطلوبہ فراہم کنندہ کو شامل کرنے سے انڈیکسنگ جاری رہے گی). تاہم دوسری صورتوں میں، سب گراف کوڈ میں تبدیلی کی ضرورت ہے.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### کیشے
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+اگر کسی بلاک کیشے کی عدم مطابقت کا شبہ ہے، جیسے کہ tx رسید غائب ہونے کا ایوینٹ:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. اگر بلاک فراہم کنندہ سے میل کھاتا ہے، تو مسئلہ کو براہ راست فراہم کنندہ کے خلاف ڈیبگ کیا جا سکتا ہے.
+
+#### مسائل اور غلطیوں کو کیوری کرنا
+
+ایک بار ایک سب گراف کو انڈیکس کرنے کے بعد، انڈیکسرز سب گراف کے وقف کردہ کیوری کے اختتامی نقطہ کے ذریعے کیوریز پیش کرنے کی توقع کر سکتے ہیں. اگر انڈیکسر کافی تعداد میں کیوریز کے حجم کو پیش کرنے کی امید کر رہا ہے تو، ایک وقف شدہ کیوری نوڈ کی تجویز کی جاتی ہے، اور بہت زیادہ کیوریز کی تعداد کی صورت میں، انڈیکسر نقل شارڈز کو ترتیب دینا چاہیں گے تاکہ کیوریز انڈیکسنگ کے عمل کو متاثر نہ کریں.
+
+تاہم، ایک وقف شدہ کیوری نوڈ اور نقل کے ساتھ بھی، بعض کیوریز کو عمل میں لانے میں کافی وقت لگ سکتا ہے، اور بعض صورتوں میں میموری کے استعمال میں اضافہ ہوتا ہے اور دوسرے صارفین کے لیے کیوری کے وقت پر منفی اثر پڑتا ہے.
+
+یہاں ایک "سلور بلیٹ" نہیں ہے، لیکن آہستہ چلنے والی کیوریز کو روکنے، تشخیص کرنے اور ان سے نمٹنے کے لیے ٹولز کی ایک رینج ہے.
+
+##### کیوری کی کیشنگ
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### کیوریز کا تجزیہ کرنا
+
+مشکل کیوریز اکثر دو طریقوں میں سے ایک میں سامنے آتی ہیں. کچھ معاملات میں، صارفین خود رپورٹ کرتے ہیں کہ دی گئی کیوری آہستہ ہے. اس صورت میں چیلنج آہستگی کی وجہ کی تشخیص کرنا ہے ء چاہے یہ عام مسئلہ ہو، یا اس سب گراف یا کیوری کے لیے مخصوص ہو. اور پھر اگر ممکن ہو تو یقیناً اسے حل کرنا.
+
+دوسری صورتوں میں، مسئلہ ایک کیوری نوڈ پر زیادہ میموری کا استعمال ہو سکتا ہے، ایسی صورت میں چیلنج سب سے پہلے اس کیوری کی نشاندہی کرنا ہے جس کی وجہ سے مسئلہ ہے.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+سست کیوریز کو دیکھتے ہوئے، انڈیکسرز کے پاس کچھ آپشنز ہوتے ہیں. بلاشبہ وہ اپنے لاگت ماڈل کو تبدیل کر سکتے ہیں، تاکہ مسئلہ کرنے والی کیوری کو بھیجنے کی لاگت میں نمایاں اضافہ ہو سکے. اس کے نتیجے میں اس کیوری کی تعدد میں کمی واقع ہوسکتی ہے. تاہم یہ اکثر مسئلے کی بنیادی وجہ کو حل نہیں کرتا ہے.
+
+##### Account-like optimisation
+
+ڈیٹا بیس ٹیبلز جو اینٹیٹیز کو ذخیرہ کرتے ہیں عام طور پر دو قسموں میں آتے ہیں: 'transaction-like'، جہاں اینٹیٹیز کو، ایک بار بنائے جانے کے بعد، کبھی اپ ڈیٹ نہیں کیا جاتا، یعنی، وہ مالیاتی ٹرانزیکشن کی فہرست کے مشابہ کچھ ذخیرہ کرتے ہیں، اور 'account-like' جہاں اینٹیٹیز کو اکثر اپ ڈیٹ کیا جاتا ہے، یعنی، وہ مالیاتی اکاؤنٹس کی طرح کچھ ذخیرہ کرتے ہیں جو ہر بار جب کوئی ٹرانزیکشن ریکارڈ ہوتا ہے تو ان میں ترمیم کی جاتی ہے. اکاؤنٹ جیسی ٹیبلز اس حقیقت کی خصوصیت رکھتی ہیں کہ ان میں بڑی تعداد میں اینٹیٹی کے ورژنز ہوتے ہیں، لیکن نسبتاً کم الگ الگ اینٹیٹیز ہیں. اکثر، ایسے ٹیبلز میں الگ الگ اینٹیٹیز کی تعداد قطاروں کی کل تعداد کا 1% ہوتی ہے (اینٹیٹی کے ورژنز)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### سب گراف کو ختم کرنا
+
+> یہ نئی فعالیت ہے، جو گراف نوڈ 0.29.x میں دستیاب ہوگی
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 63884c46cf5ba949cf0c693d1b47f0d687f18da8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:49 -0500
Subject: [PATCH 0904/3820] New translations advanced.mdx (Urdu (Pakistan))

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/ur/subgraphs/developing/creating/advanced.mdx b/website/pages/ur/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..3d47fb8364cd
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## جائزہ
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Non-fatal errors
+
+پہلے سے مطابقت پذیر سب گرافس پر انڈیکسنگ کی غلطیاں، بذریعہ ڈیفالٹ، سب گراف کے ناکام ہونے اور مطابقت پذیری کو روکنے کا سبب بنیں گی. سب گراف کو متبادل طور پر غلطیوں کی موجودگی میں مطابقت پذیری جاری رکھنے کے لیے ترتیب دیا جا سکتا ہے، ہینڈلر کی طرف سے کی گئی تبدیلیوں کو نظر انداز کر کے جس سے خرابی پیدا ہوئی. اس سے سب گراف مصنفین کو اپنے سب گراف کو درست کرنے کا وقت ملتا ہے جب کہ تازہ ترین بلاک کے خلاف کیوریز پیش کی جاتی رہتی ہیں، حالانکہ اس خرابی کی وجہ سے نتائج متضاد ہو سکتے ہیں. نوٹ کریں کہ کچھ غلطیاں اب بھی ہمیشہ مہلک ہوتی ہیں. غیر مہلک ہونے کے لیے، خرابی کو تعییناتی معلوم ہونا چاہیے.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+غیر مہلک غلطیوں کو فعال کرنے کے لیے سب گراف مینی فیسٹ پر درج ذیل خصوصیت کا فلیگ ترتیب دینے کی ضرورت ہے:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+فائل ڈیٹا کے ذرائع ایک مضبوط، قابل توسیع طریقے سے انڈیکسنگ کے دوران آف چین ڈیٹا تک رسائی کے لیے ایک نئی سب گراف کی فعالیت ہے۔ فائل ڈیٹا کے ذرائع IPFS اور Arweave سے فائلیں لانے میں معاونت کرتے ہیں.
+
+> یہ آف چین ڈیٹا کی تعییناتی انڈیکسنگ کے ساتھ ساتھ صوابدیدی HTTP سے حاصل کردہ ڈیٹا کے ممکنہ تعارف کی بنیاد بھی رکھتا ہے.
+
+### جائزہ
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### اپ گریڈ گائیڈ
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### ایک نئے ادارے کی قسم شامل کریں جو فائلیں ملنے پر اپ ڈیٹ ہو جائے گی
+
+فائل ڈیٹا سورسز چین پر مبنی اداروں تک رسائی یا اپ ڈیٹ نہیں کر سکتے ہیں، لیکن فائل کے مخصوص اداروں کو اپ ڈیٹ کرنا ضروری ہے.
+
+اس کا مطلب یہ ہوسکتا ہے کہ موجودہ اداروں سے فیلڈز کو الگ الگ اداروں میں تقسیم کیا جائے، جو آپس میں جڑے ہوئے ہوں.
+
+اصل مشترکہ ادارہ:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+نیا، تقسیم شدہ ادارہ:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+اگر رشتہ پیرنٹ ادارے اور نتیجے میں آنے والی فائل ڈیٹا سورس ہستی کے درمیان 1:1 ہے، تو سادہ ترین نمونہ IPFS CID کو بطور لوک اپ استعمال کر کے پیرنٹ کی ہستی کو نتیجے میں آنے والی فائل ہستی سے جوڑنا ہے۔ اگر آپ کو اپنی نئی فائل پر مبنی ہستیوں کو ماڈل بنانے میں دشواری ہو رہی ہے تو ڈسکورڈ پر رابطہ کریں!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+یہ ڈیٹا سورس ہے جو دلچسپی کی فائل کی شناخت ہونے پر پیدا کیا جائے گا.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### فائلوں پر کارروائی کرنے کے لیے ایک نیا ہینڈلر بنائیں
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+مثالی ہینڈلر:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### ضرورت پڑنے پر فائل ڈیٹا سورسز کو دریافت کریں
+
+اب آپ چین پر مبنی ہینڈلرز کے عمل کے دوران فائل ڈیٹا کے ذرائع بنا سکتے ہیں:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+مثال:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+یہ ایک نیا فائل ڈیٹا سورس بنائے گا، جو گراف نوڈ کے کنفیگر کردہ آئی پی ایف ایس یا Arweave اینڈ پوائنٹ کو پول کرے گا، اگر یہ نہ ملا تو دوبارہ کوشش کریں۔ جب فائل مل جائے گی، فائل ڈیٹا سورس ہینڈلر کو عمل میں لایا جائے گا.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+مبارک ہو، آپ فائل ڈیٹا سورسز استعمال کر رہے ہیں!
+
+#### آپ کے سب گراف کو تعینات کرنا
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### حدود
+
+فائل ڈیٹا سورس کے ہینڈلرز اور ہستیوں کو دیگر سب گراف ہستیوں سے الگ تھلگ کر دیا جاتا ہے، اس بات کو یقینی بناتے ہوئے کہ عمل درآمد کے وقت وہ تعیین پسند ہیں، اور اس بات کو یقینی بناتے ہیں کہ چین پر مبنی ڈیٹا سورسز کی کوئی آلودگی نہ ہو۔ مخصوص ہونا:
+
+- فائل ڈیٹا سورسز کے ذریعے تخلیق کردہ ادارے ناقابل تغیر ہیں، اور انہیں اپ ڈیٹ نہیں کیا جا سکتا
+- فائل ڈیٹا کے ذرائع ہینڈلرز دوسرے فائل ڈیٹا سورسز سے اداروں تک رسائی حاصل نہیں کرسکتے ہیں
+- فائل ڈیٹا کے ذرائع سے وابستہ ہستیوں تک چین پر مبنی ہینڈلرز تک رسائی حاصل نہیں کی جا سکتی ہے
+
+> اگرچہ یہ رکاوٹ زیادہ تر استعمال کے معاملات کے لیے مشکل نہیں ہونی چاہیے، لیکن یہ کچھ لوگوں کے لیے پیچیدگی پیدا کر سکتی ہے۔ براہ کرم ڈسکورڈ کے ذریعے رابطہ کریں اگر آپ کو اپنے فائل پر مبنی ڈیٹا کو سب گراف میں ماڈل کرنے میں مسئلہ درپیش ہے!
+
+مزید برآں، فائل ڈیٹا سورس سے ڈیٹا سورسز بنانا ممکن نہیں ہے، چاہے وہ آن چین ڈیٹا سورس ہو یا کوئی اور فائل ڈیٹا سورس۔ مستقبل میں یہ پابندی ختم ہو سکتی ہے.
+
+#### بہترین طریقے
+
+اگر آپ NFT میٹا ڈیٹا کو متعلقہ ٹوکنز سے جوڑ رہے ہیں، تو ٹوکن ہستی سے میٹا ڈیٹا ہستی کا حوالہ دینے کے لیے میٹا ڈیٹا کے IPFS ہیش کا استعمال کریں۔ آئی پی ایف ایس ہیش کو بطور ID استعمال کرتے ہوئے میٹا ڈیٹا ہستی کو محفوظ کریں.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> ہم مندرجہ بالا سفارش کو بہتر بنانے کے لیے کام کر رہے ہیں، لہذا کیوریز صرف "حالیہ ترین" ورژن واپس کرتے ہیں
+
+#### معلوم مسائل
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### مثالیں
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### حوالہ جات
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### موجودہ سب گرافس پر گرافٹنگ
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+چونکہ گرافٹنگ بیس ڈیٹا کو انڈیکس کرنے کے بجائے کاپی کرتا ہے، شروع سے انڈیکس کرنے کے مقابلے میں مطلوبہ بلاک میں سب گراف حاصل کرنا بہت تیز ہے، حالانکہ ابتدائی ڈیٹا کاپی بہت بڑے سب گراف کے لیے کئی گھنٹے لگ سکتی ہے۔ جب گرافٹ شدہ سب گراف کو شروع کیا جا رہا ہے، گراف نوڈ ان ہستی کی اقسام کے بارے میں معلومات کو لاگ کرے گا جو پہلے ہی کاپی ہو چکی ہیں.
+
+گرافٹڈ سب گراف ایک گراف کیو ایل اسکیما استعمال کرسکتا ہے جو بیس سب گراف میں سے ایک سے مماثل نہیں ہے، لیکن اس کے ساتھ محض مطابقت رکھتا ہے۔ اسے اپنے طور پر ایک درست سب گراف سکیما ہونا چاہیے، لیکن درج ذیل طریقوں سے بنیادی سب گراف کے سکیما سے انحراف ہو سکتا ہے:
+
+- یہ ہستی کی اقسام کو جوڑتا یا ہٹاتا ہے
+- یہ ہستی کی اقسام سے صفات کو ہٹاتا ہے
+- یہ ہستی کی قسموں میں کالعدم صفات کو شامل کرتا ہے
+- یہ غیر کالعدم صفات کو کالعدم صفات میں بدل دیتا ہے
+- یہ enums میں اقدار کا اضافہ کرتا ہے
+- یہ انٹرفیس کو جوڑتا یا ہٹاتا ہے
+- یہ تبدیل ہوتا ہے جس کے لیے ایک انٹرفیس لاگو کیا جاتا ہے
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 52318632067cd8736b4253a5819acae3143f4441 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:50 -0500
Subject: [PATCH 0905/3820] New translations api.mdx (Urdu (Pakistan))

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/ur/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/ur/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..f4e52ec28767
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: اسمبلی اسکرپٹ API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API حوالہ
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- مختلف قسم کے سسٹمز جیسے کہ ایتھیریم، JSON، GraphQL اور اسمبلی اسکرپٹ کے درمیان ترجمہ کرنے کے لیے نچلی سطح کے قدیم.
+
+### ورژنز
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+|  ورزن | جاری کردہ نوٹس                                                                                                                                                                                                                                           |
+| :---: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0.0.9 | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+| 0.0.8 | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+| 0.0.7 | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+| 0.0.6 | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+| 0.0.5 | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+| 0.0.4 | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+| 0.0.3 | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+| 0.0.2 | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### بلٹ ان اقسام
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### سٹور API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Creating entities
+
+ایتھیریم ایونٹس سے ہستیوں کو بنانے کے لیے درج ذیل ایک عام نمونہ ہے.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### اسٹور سے ہستیوں کو لوڈ کرنا
+
+اگر کوئی ہستی پہلے سے موجود ہے تو اسے اسٹور سے درج ذیل کے ساتھ لوڈ کیا جا سکتا ہے:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### بلاک کے ساتھ تخلیق کردہ ہستیوں کو تلاش کرنا
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### موجودہ ہستیوں کو اپ ڈیٹ کرنا
+
+موجودہ ہستی کو اپ ڈیٹ کرنے کے دو طریقے ہیں:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+پراپرٹیز کو تبدیل کرنا زیادہ تر معاملات میں سیدھا آگے ہے، جنریٹڈ پراپرٹی سیٹرز کی بدولت:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+درج ذیل دو ہدایات میں سے کسی ایک کے ساتھ پراپرٹیز کو غیر سیٹ کرنا بھی ممکن ہے:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### اسٹور سے ہستیوں کو ہٹانا
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### ایتھیریم API
+
+ایتھیریم API سمارٹ کنٹریکٹس، پبلک سٹیٹ ویری ایبلز، کنٹریکٹ فنکشنز، ایونٹس، ٹرانزیکشنز، بلاکس اور انکوڈنگ/ڈی کوڈنگ ایتھیریم ڈیٹا تک رسائی فراہم کرتا ہے.
+
+#### ایتھیریم کی اقسام کے لیے سپورٹ
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+مندرجہ ذیل مثال اس کی وضاحت کرتی ہے۔ جیسا کہ سب گراف اسکیما دیا گیا
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### ایونٹس اور بلاک/ٹرانزیکشن ڈیٹا
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### سمارٹ کنٹریکٹ اسٹیٹ تک رسائی
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+ایک عام نمونہ اس کنٹریکٹ تک رسائی حاصل کرنا ہے جہاں سے کوئی واقعہ شروع ہوتا ہے۔ یہ مندرجہ ذیل کوڈ کے ساتھ حاصل کیا جاتا ہے:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+کوئی بھی دوسرا کنٹریکٹ جو سب گراف کا حصہ ہے، تیار کردہ کوڈ سے درآمد کیا جا سکتا ہے اور اسے ایک درست ایڈریس کا پابند کیا جا سکتا ہے.
+
+#### واپس آنے والی کالوں کو ہینڈل کرنا
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### انکوڈنگ/ڈی کوڈنگ ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+مزید معلومات کے لیے:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### لاگنگ API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### ایک یا زیادہ اقدار کو لاگ کرنا
+
+##### ایک سنگل ویلیو لاگ کرنا
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### موجودہ صف سے ایک ہی اندراج کو لاگ کرنا
+
+نیچے دی گئی مثال میں، تین ویلیوس پر مشتمل ایرے کے باوجود، آرگیومینٹ ایرے کی صرف پہلی ویلیو لاگ ان ہوتی ہے.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### موجودہ ایرے سے متعدد اندراجات کو لاگ کرنا
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### موجودہ صف سے مخصوص اندراج کو لاگ کرنا
+
+صف میں ایک مخصوص قدر ظاہر کرنے کے لیے، انڈیکس قدر فراہم کی جانی چاہیے.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### لاگنگ ایونٹ کی معلومات
+
+ذیل کی مثال کسی ایونٹ سے بلاک نمبر، بلاک ہیش اور ٹرانزیکشن ہیش کو لاگ کرتی ہے:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+IPFS ہیش یا پاتھ کو دیکھتے ہوئے، IPFS سے فائل کو پڑھنا اس طرح کیا جاتا ہے:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### کرپٹو API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### تبادلوں کا حوالہ ٹائپ کریں
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### ڈیٹا ماخذ میٹا ڈیٹا
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### ہستی اور ڈیٹا سورس سیاق و سباق
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From 52e8537fab48e842a2ae09f8000d19ecd71c9501 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:51 -0500
Subject: [PATCH 0906/3820] New translations common-issues.mdx (Urdu
 (Pakistan))

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/ur/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/ur/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..4b7eaae1c362
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: مشترکہ اسمبلی اسکرپٹ کے مسائل
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 1a1f2a43f245ab51c6b911d1b2fb5ffc824d933e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:52 -0500
Subject: [PATCH 0907/3820] New translations unit-testing-framework.mdx (Urdu
 (Pakistan))

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/ur/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/ur/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..0effe170f354
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: یونٹ ٹیسٹنگ فریم ورک
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## شروع ہوا چاہتا ہے
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+آپ ڈوکر اپروچ اور بائنری اپروچ دونوں کا استعمال کرتے ہوئے WSL پر Matchstick استعمال کر سکتے ہیں۔ جیسا کہ WSL تھوڑا مشکل ہوسکتا ہے، اگر آپ کو اس طرح کے مسائل کا سامنا کرنا پڑتا ہے تو یہاں کچھ تجاویز ہیں
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+یا
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI کے اختیارات
+
+یہ تمام ٹیسٹس کو ٹیسٹ فولڈر میں چلاۓ گا:
+
+```sh
+graph test
+```
+
+یہ gravity.test.ts نامی ٹیسٹ اور/یا کشش ثقل نامی فولڈر کے اندر تمام ٹیسٹ چلائے گا:
+
+```sh
+graph test gravity
+```
+
+یہ صرف مخصوص ٹیسٹ فائل کو چلاۓ گا:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### ڈوکر
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### کنفیگریشن
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### ڈیمو سب گراف
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### ویڈیو ٹیوٹوریلز
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+مثال:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+مثال:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+یا
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+مثالیں:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+مثال:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+مثالیں:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## یونٹ ٹیسٹ لکھیں
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+یہ فرض کرتے ہوئے کہ ہمارے پاس مندرجہ ذیل ہینڈلر فنکشن ہے (ہماری زندگی کو آسان بنانے کے لیے دو مددگار افعال کے ساتھ):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+ہمیں پہلے اپنے پروجیکٹ میں ایک ٹیسٹ فائل بنانا ہوگی۔ یہ اس کی ایک مثال ہے کہ یہ کس طرح نظر آسکتا ہے:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- ہم اپنی ابتدائی حالت قائم کر رہے ہیں اور ایک حسب ضرورت Gravatar ہستی شامل کر رہے ہیں;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- ہم اسٹور کی حالت پر زور دیتے ہیں۔ یہ کیسے کام کرتا ہے؟ - ہم ہستی کی قسم اور آئی ڈی کا ایک انوکھا امتزاج پاس کر رہے ہیں۔ پھر ہم اس ہستی پر ایک مخصوص فیلڈ کو چیک کرتے ہیں اور اس بات پر زور دیتے ہیں کہ اس کی وہ قدر ہے جس کی ہم اس سے توقع رکھتے ہیں۔ ہم یہ دونوں ابتدائی Gravatar ہستی کے لیے کر رہے ہیں جسے ہم نے سٹور میں شامل کیا ہے، اور ساتھ ہی وہ دو Gravatar اداروں کے لیے جو ہینڈلر فنکشن کو کال کرنے پر شامل ہو جاتی ہیں;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+ہم وہاں جاتے ہیں - ہم نے اپنا پہلا ٹیسٹ بنایا ہے! 👏
+
+اب ہمارے ٹیسٹ چلانے کے لیے آپ کو اپنے سب گراف روٹ فولڈر میں درج ذیل کو چلانے کی ضرورت ہے:
+
+`graph test Gravity`
+
+اور اگر سب کچھ ٹھیک رہا تو آپ کو درج ذیل کے ساتھ خوش آمدید کہا جانا چاہئے:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## عام ٹیسٹ کے منظرنامے
+
+### ایک مخصوص حالت کے ساتھ اسٹور کو ہائیڈریٹ کرنا
+
+صارفین معلوم ہستیوں کے ایک سیٹ کے ساتھ اسٹور کو ہائیڈریٹ کرنے کے قابل ہیں۔ Gravatar ہستی کے ساتھ اسٹور کو شروع کرنے کی ایک مثال یہ ہے:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### میپنگ فنکشن کو ایونٹ سے کال کرنا
+
+صارف ایک حسب ضرورت ایونٹ بنا سکتا ہے اور اسے ایک میپنگ فنکشن میں منتقل کر سکتا ہے جو اسٹور سے منسلک ہے:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### ایونٹ کے فکسچر کے ساتھ تمام نقشوں کو کال کرنا
+
+صارف میپنگ کو ٹیسٹ فکسچر کے ساتھ کال کر سکتے ہیں.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### کنٹریکٹ کالز کو موک کرنا
+
+صارفین کنٹریکٹ کالس کو موک کر سکتے ہیں:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+جیسا کہ دکھایا گیا ہے، کنٹریکٹ کال کو موک کرنے کے لۓ اور واپسی کی ویلیو کو سخت کرنے کے لیے، صارف کو کنٹریکٹ ایڈریس، فنکشن کا نام، فنکشن کے دستخط، دلائل کی ایک صف، اور یقیناً - واپسی کی قیمت فراہم کرنی چاہیے.
+
+صارفین فنکشن ریورٹس کو بھی موک کر سکتے ہیں:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### IPFS files کو موک کرنا (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### اسٹور کی حالت کا دعویٰ
+
+صارفین دعویٰ کرنے والے اداروں کے ذریعے اسٹور کی حتمی (یا وسط میں) حالت کا دعویٰ کر سکتے ہیں۔ ایسا کرنے کے لیے، صارف کو ایک ہستی کی قسم، کسی ہستی کی مخصوص ID، اس ہستی پر موجود کسی فیلڈ کا نام، اور فیلڈ کی متوقع قیمت فراہم کرنی ہوگی۔ یہاں ایک فوری مثال ہے:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### ایونٹ میٹا ڈیٹا کے ساتھ تعامل کرنا
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### متغیر مساوات پر زور دینا
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+صارفین اس بات پر زور دے سکتے ہیں کہ اسٹور میں کوئی ہستی موجود نہیں ہے۔ فنکشن ایک ہستی کی قسم اور ایک شناخت لیتا ہے۔ اگر ہستی حقیقت میں اسٹور میں ہے تو، متعلقہ خرابی کے پیغام کے ساتھ ٹیسٹ ناکام ہو جائے گا۔ اس فعالیت کو استعمال کرنے کے طریقے کی ایک فوری مثال یہ ہے:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+آپ اس مددگار فنکشن کا استعمال کرکے پورے اسٹور کو کنسول پر پرنٹ کرسکتے ہیں:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### متوقع ناکامی
+
+Test() فنکشنز پر shouldFail پرچم کا استعمال کرتے ہوئے، صارفین کو ٹیسٹ میں ناکامی کی توقع ہو سکتی ہے:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+اگر ٹیسٹ کو shouldFail = true کے ساتھ نشان زد کیا گیا ہے لیکن ناکام نہیں ہوتا ہے، تو یہ لاگز میں ایک غلطی کے طور پر ظاہر ہوگا اور ٹیسٹ بلاک ناکام ہو جائے گا۔ اس کے علاوہ، اگر اسے shouldFail = false (پہلے سے طے شدہ حالت) سے نشان زد کیا گیا ہے، تو ٹیسٹ ایگزیکیوٹر کریش ہو جائے گا.
+
+### لاگنگ
+
+یونٹ ٹیسٹ میں حسب ضرورت لاگز کا ہونا بالکل ویسا ہی ہے جیسا کہ میپنگ میں لاگ ان کرنا ہے۔ فرق یہ ہے کہ لاگ آبجیکٹ کو graph-ts کی بجائے matchstick-as سے درآمد کرنے کی ضرورت ہے۔ یہاں تمام غیر اہم لاگ اقسام کے ساتھ ایک سادہ مثال ہے:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+صارف ایک اہم ناکامی کی نقل بھی کر سکتے ہیں، جیسے:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+اہم غلطیوں کو لاگ کرنا ٹیسٹوں پر عمل درآمد روک دے گا اور سب کچھ اڑا دے گا۔ آخر کار - ہم یہ یقینی بنانا چاہتے ہیں کہ آپ کے کوڈ میں تعیناتی میں اہم لاگز نہیں ہیں، اور اگر ایسا ہونا تھا تو آپ کو فوراً نوٹس لینا چاہیے.
+
+### ماخوذ فیلڈز کی جانچ کرنا
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### متحرک ڈیٹا کے ذرائع کی جانچ کرنا
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+ذیل کی مثال:
+
+سب سے پہلے ہمارے پاس مندرجہ ذیل ایونٹ ہینڈلر ہے (جو جان بوجھ کر ڈیٹا سورس کو موک کرنے کے لیۓ دوبارہ تیار کیا گیا ہے):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+اور پھر ہمارے پاس ڈیٹا سورس موک نام کی جگہ کے طریقوں میں سے ایک کا استعمال کرتے ہوئے ڈیٹا سورس کے تمام افعال کے لیے ایک نئی واپسی کی قیمت مقرر کرنے کے لیے ٹیسٹ ہے:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+نوٹ کریں کہ dataSourceMock.resetValues() کو آخر میں بلایا گیا ہے۔ اس کی وجہ یہ ہے کہ جب اقدار کو تبدیل کیا جاتا ہے تو انہیں یاد رکھا جاتا ہے اور اگر آپ پہلے سے طے شدہ اقدار پر واپس جانا چاہتے ہیں تو انہیں دوبارہ ترتیب دینے کی ضرورت ہے.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## ٹیسٹ کوریج
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### شرطیں
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### اپنے ہینڈلرز کو ایکسپورٹ کریں
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### استعمال
+
+ایک بار جب یہ سب سیٹ ہو جائے تو، ٹیسٹ کوریج ٹول کو چلانے کے لیے، بس چلائیں:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### لاگ آؤٹ پٹ میں ٹیسٹ رن ٹائم دورانیہ
+
+لاگ آؤٹ پٹ میں ٹیسٹ رن کا دورانیہ شامل ہوتا ہے۔ یہاں ایک مثال ہے:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## کمپائلر کی عام غلطیاں
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## اضافی وسائل
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## تاثرات
+
+اگر آپ کے پاس کوئی سوال، تاثرات، فیچر کی درخواستیں ہیں یا آپ صرف رابطہ کرنا چاہتے ہیں، تو بہترین جگہ گراف ڈسکورڈ ہوگی جہاں ہمارے پاس Matchstick کے لیے ایک سرشار چینل ہے، جسے 🔥| یونٹ ٹیسٹنگ بلایا جاتا ہے.

From 5ab4df4d02ebb879883e731bcb91a5d0f1fe2b57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:53 -0500
Subject: [PATCH 0908/3820] New translations transferring-a-subgraph.mdx (Urdu
 (Pakistan))

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/ur/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/ur/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 7e9db03a75152c4ebb18781c85b131f36531ac34 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:54 -0500
Subject: [PATCH 0909/3820] New translations graphql-api.mdx (Urdu (Pakistan))

---
 .../ur/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/ur/subgraphs/querying/graphql-api.mdx b/website/pages/ur/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..de7aa00b9d61
--- /dev/null
+++ b/website/pages/ur/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### مثالیں
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### سورٹنگ
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### مثال
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### نیسٹڈ ہستی کی چھانٹی کی مثال
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### صفحہ بندی
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+پہلے 10 ٹوکنز سے کیوری کریں:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### فلٹرنگ
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### رینج فلٹرنگ کی مثال
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### بلاک فلٹرنگ کی مثال
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+یہ کارآمد ہو سکتا ہے اگر آپ صرف ان ہستیوں کو لانے کے خواہاں ہیں جو تبدیل ہو چکی ہیں، مثال کے طور پر آخری بار جب آپ نے پول کیا تھا۔ یا متبادل طور پر یہ تحقیق کرنا یا ڈیبگ کرنا مفید ہو سکتا ہے کہ آپ کے سب گراف میں ہستی کیسے تبدیل ہو رہی ہیں (اگر بلاک فلٹر کے ساتھ ملایا جائے تو، آپ صرف ان ہستیوں کو الگ تھلگ کر سکتے ہیں جو ایک مخصوص بلاک میں تبدیل ہوئی ہیں).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### نیسٹڈ ہستی فلٹرنگ کی مثال
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+یہ مفید ہو سکتا ہے اگر آپ صرف ان ہستیوں کو لانے کے خواہاں ہیں جن کی چائلڈ لیول کے ہستی فراہم کردہ شرائط کو پورا کرتے ہیں.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### منطقی آپریٹرز
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### تمام فلٹرز
+
+پیرامیٹر لاحقوں کی مکمل فہرست:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### ٹائم ٹریول کے کیوریز
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### مثال
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### مثال
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### فل ٹیکسٹ تلاش کے کیوریز
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+فل ٹیکسٹ سرچ آپریٹرز:
+
+| علامت | آپریٹر      | تفصیل                                                                                                                                           |
+| ----- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`   | `And`       | ایک سے زیادہ تلاش کی اصطلاحات کو ایک فلٹر میں یکجا کرنے کے لیے ان ہستیوں کے لیے جس میں فراہم کردہ تمام اصطلاحات شامل ہوں                        |
+| |     | `Or`        | Or آپریٹر کے ذریعہ الگ کردہ متعدد تلاش کی اصطلاحات کے ساتھ کیوریز فراہم کردہ شرائط میں سے کسی سے بھی مماثلت کے ساتھ تمام ہستیوں کو واپس کریں گے |
+| `<->` | `Follow by` | دو الفاظ کے درمیان فاصلہ بتائیں.                                                                                                                |
+| `:*`  | `Prefix`    | ایسے الفاظ تلاش کرنے کے لیے پریفکس ​​تلاش کی اصطلاح استعمال کریں جن کا سابقہ ​​مماثل ہو (۲ حروف درکار ہیں.)                                     |
+
+#### مثالیں
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+مزید پیچیدہ فلٹرز بنانے کے لیے فل ٹیکسٹ آپریٹرز کو یکجا کریں۔ ایک بہانہ سرچ آپریٹر کے ساتھ اس مثال کے کیوری کی پیروی کے ساتھ مل کر بلاگ کے تمام ہستیوں کو ایسے الفاظ سے مماثل کرے گا جو "lou" کے بعد "موسیقی" سے شروع ہوتے ہیں.
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### توثیق
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## سکیما
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### ہستیوں
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### سب گراف میٹا ڈیٹا
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+اگر کوئی بلاک فراہم کیا جاتا ہے تو، میٹا ڈیٹا اس بلاک کا ہوتا ہے، اگر تازہ ترین انڈیکسڈ بلاک استعمال نہیں کیا جاتا ہے۔ اگر فراہم کیا گیا ہو، تو بلاک سب گراف کے اسٹارٹ بلاک کے بعد ہونا چاہیے، اور حال ہی میں انڈیکس کیے گئے بلاک سے کم یا اس کے برابر ہونا چاہیے.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- ہیش: بلاک کی ہیش
+- نمبر: بلاک نمبر
+- ٹائم اسٹیمپ: بلاک کا ٹائم اسٹیمپ، اگر دستیاب ہو (یہ فی الحال صرف ای وی ایم نیٹ ورکس کو انڈیکس کرنے والے سب گرافس کے لیے دستیاب ہے)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 20641e11a9b0558a845bbdff7a44f27e8d6f7cb9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:56 -0500
Subject: [PATCH 0910/3820] New translations python.mdx (Urdu (Pakistan))

---
 .../pages/ur/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/querying/python.mdx

diff --git a/website/pages/ur/subgraphs/querying/python.mdx b/website/pages/ur/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..4c8b2e1f247a
--- /dev/null
+++ b/website/pages/ur/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## شروع ہوا چاہتا ہے
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 531a0a14b02d7dfdfc66e15e30111960ab7a19fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:57 -0500
Subject: [PATCH 0911/3820] New translations triggers.mdx (Urdu (Pakistan))

---
 website/pages/ur/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/ur/substreams/sps/triggers.mdx

diff --git a/website/pages/ur/substreams/sps/triggers.mdx b/website/pages/ur/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/ur/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 1707da4e004efd35152a7baec6f1ea99763da15f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:58 -0500
Subject: [PATCH 0912/3820] New translations overview.mdx (Vietnamese)

---
 website/pages/vi/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/vi/indexing/overview.mdx

diff --git a/website/pages/vi/indexing/overview.mdx b/website/pages/vi/indexing/overview.mdx
new file mode 100644
index 000000000000..91584928878f
--- /dev/null
+++ b/website/pages/vi/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+
+GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.
+
+Indexer chọn các subgraph để index dựa trên tín hiệu curation của subgraph, trong đó Curator stake GRT để chỉ ra subgraph nào có chất lượng cao và cần được ưu tiên. Bên tiêu dùng (ví dụ: ứng dụng) cũng có thể đặt các tham số (parameter) mà Indexer xử lý các truy vấn cho các subgraph của họ và đặt các tùy chọn cho việc định giá phí truy vấn.
+
+<Difficulty level="ADVANCED" />
+
+## CÂU HỎI THƯỜNG GẶP
+
+### What is the minimum stake required to be an Indexer on the network?
+
+The minimum stake for an Indexer is currently set to 100K GRT.
+
+### What are the revenue streams for an Indexer?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### How are indexing rewards distributed?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### Bằng chứng lập chỉ mục (proof of indexing - POI) là gì?
+
+POIs are used in the network to verify that an Indexer is indexing the subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific subgraph deployment up to and including that block.
+
+### Khi nào Phần thưởng indexing được phân phối?
+
+Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).
+
+### Can pending indexing rewards be monitored?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Nhiều trang tổng quan (dashboard) do cộng đồng tạo bao gồm các giá trị phần thưởng đang chờ xử lý và bạn có thể dễ dàng kiểm tra chúng theo cách thủ công bằng cách làm theo các bước sau:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### Tranh chấp là gì và tôi có thể xem chúng ở đâu?
+
+Các truy vấn và phần phân bổ của Indexer đều có thể bị tranh chấp trên The Graph trong thời gian tranh chấp. Thời hạn tranh chấp khác nhau, tùy thuộc vào loại tranh chấp. Truy vấn / chứng thực có cửa sổ tranh chấp 7 epoch (kỷ nguyên), trong khi phần phân bổ có 56 epoch. Sau khi các giai đoạn này trôi qua, không thể mở các tranh chấp đối với phần phân bổ hoặc truy vấn. Khi một tranh chấp được mở ra, các Fisherman yêu cầu một khoản stake tối thiểu là 10.000 GRT, sẽ bị khóa cho đến khi tranh chấp được hoàn tất và giải pháp đã được đưa ra. Fisherman là bất kỳ người tham gia mạng nào mà đã mở ra tranh chấp.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- Nếu tranh chấp bị từ chối, GRT do Fisherman gửi sẽ bị đốt, và Indexer tranh chấp sẽ không bị phạt cắt giảm (slashed).
+- Nếu tranh chấp được giải quyết dưới dạng hòa, tiền gửi của Fisherman sẽ được trả lại, và Indexer bị tranh chấp sẽ không bị phạt cắt giảm (slashed).
+- Nếu tranh chấp được chấp nhận, lượng GRT do Fisherman đã gửi sẽ được trả lại, Indexer bị tranh chấp sẽ bị cắt và Fisherman sẽ kiếm được 50% GRT đã bị phạt cắt giảm (slashed).
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### Các khoản hoàn phí truy vấn là gì và chúng được phân phối khi nào?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+
+### Cắt giảm phí truy vấn và cắt giảm phần thưởng indexing là gì?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### How do Indexers know which subgraphs to index?
+
+Indexer có thể tự phân biệt bản thân bằng cách áp dụng các kỹ thuật nâng cao để đưa ra quyết định index subgraph nhưng để đưa ra ý tưởng chung, chúng ta sẽ thảo luận một số số liệu chính được sử dụng để đánh giá các subgraph trong mạng:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### Có các yêu cầu gì về phần cứng (hardware)?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Cài đặt     | Postgres<br />(CPUs) | Postgres<br />(bộ nhớ tính bằng GB) | Postgres<br />(đĩa tính bằng TB) | VMs<br />(CPUs) | VMs<br />(bộ nhớ tính bằng GB) |
+| ----------- | :------------------: | :---------------------------------: | :------------------------------: | :-------------: | :----------------------------: |
+| Nhỏ         |           4          |                  8                  |                 1                |        4        |               16               |
+| Tiêu chuẩn  |           8          |                  30                 |                 1                |        12       |               48               |
+| Trung bình |          16          |                  64                 |                 2                |        32       |               64               |
+| Lớn         |          72          |                 468                 |                3.5               |        48       |               184              |
+
+### What are some basic security precautions an Indexer should take?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Cơ sở hạ tầng
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Lưu ý: Để hỗ trợ mở rộng quy mô nhanh, bạn nên tách các mối quan tâm về truy vấn và indexing giữa các nhóm node khác nhau: node truy vấn và node index.
+
+### Tổng quan về các cổng
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Cổng | Mục đích                                              | Tuyến                                          | Đối số CLI         | Biến môi trường |
+| ---- | ----------------------------------------------------- | ---------------------------------------------- | ------------------ | --------------- |
+| 8000 | Máy chủ GraphQL HTTP<br />(cho các truy vấn subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -               |
+| 8001 | GraphQL WS<br />(cho các đăng ký subgraph)            | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -               |
+| 8020 | JSON-RPC<br />(để quản lý triển khai)                 | /                                              | \--admin-port      | -               |
+| 8030 | API trạng thái lập chỉ mục Subgraph                   | /graphql                                       | \--index-node-port | -               |
+| 8040 | Số liệu Prometheus                                    | /metrics                                       | \--metrics-port    | -               |
+
+#### Dịch vụ Indexer
+
+| Cổng | Mục đích                                                         | Tuyến                                                       | Đối số CLI      | Biến môi trường        |
+| ---- | ---------------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | Máy chủ GraphQL HTTP<br />(cho các truy vấn subgraph có trả phí) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Số liệu Prometheus                                               | /metrics                                                    | \--metrics-port | -                      |
+
+#### Đại lý Indexer
+
+| Cổng | Purpose                | Tuyến  | CLI Argument               | Environment Variable                    |
+| ---- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | API quản lý Indexer    | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Thiết lập cơ sở hạ tầng máy chủ bằng Terraform trên Google Cloud
+
+> Note: Indexers can alternatively use AWS, Microsoft Azure, or Alibaba.
+
+#### Cài đặt điều kiện tiên quyết
+
+- Google Cloud SDK
+- Công cụ dòng lệnh Kubectl
+- Terraform
+
+#### Tạo một dự án Google Cloud
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Xác thực với Google Cloud và tạo một dự án mới.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Sử dụng \[billing page\](billing page) của Google Cloud Consolde để cho phép thanh toán cho dự án mới.
+
+- Tạo một cấu hình Google Cloud.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Bật các API Google Cloud được yêu cầu.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Tạo một tài khoản dịch vụ.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Bật tính năng ngang hàng (peering) giữa cơ sở dữ liệu và cụm Kubernetes sẽ được tạo trong bước tiếp theo.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Tạo tệp cấu hình terraform tối thiểu (cập nhật nếu cần).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Sử dụng Terraform để tạo cơ sở hạ tầng
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Chạy các lệnh sau để tạo cơ sở hạ tầng.
+
+```sh
+# Cài đặt các Plugins được yêu cầu
+terraform init
+
+# Xem kế hoạch cho các tài nguyên sẽ được tạo
+terraform plan
+
+# Tạo tài nguyên (dự kiến mất đến 30 phút)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Creating the Kubernetes components for the Indexer
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Bắt đầu từ nguồn
+
+#### Cài đặt điều kiện tiên quyết
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Cài đặt
+
+1. Khởi động máy chủ cơ sở dữ liệu PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Bây giờ tất cả các phụ thuộc đã được thiết lập, hãy khởi động Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Bắt đầu sử dụng Docker
+
+#### Điều kiện tiên quyết
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Cài đặt
+
+1. Nhân bản Graph Node và điều hướng đến thư mục Docker:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Bắt đầu một Graph Node cục bộ sẽ kết nối với điểm cuối Ethereum của bạn:
+
+```sh
+docker-compose up
+```
+
+### Các thành phần của Indexer
+
+To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Bắt đầu
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### Từ các gói NPM
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### Từ nguồn
+
+```sh
+# Từ Repo root directory
+yarn
+
+# Dịch vụ Indexer
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Đại lý Indexer
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Sử dụng docker
+
+- Kéo hình ảnh từ sổ đăng ký
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Hoặc xây dựng hình ảnh cục bộ từ nguồn
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Chạy các thành phần
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Sử dụng K8s and Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Sử dụng
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Đại lý Indexer
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Dịch vụ Indexer
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Indexer management using Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Sử dụng
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Các quy tắc indexing
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Mô hình dữ liệu:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Example usage of indexing rule:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Action added to the queue by the 3rd party optimizer tool or indexer-cli user
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken.
+
+Mô hình dữ liệu:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Example usage from source:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Note that supported action types for allocation management have different input requirements:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - required action params:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - required action params:
+    - allocationID
+    - deploymentID
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - required action params:
+    - allocationID
+    - deploymentID
+    - amount
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+#### Các mô hình chi phí
+
+Cost models provide dynamic pricing for queries based on market and query attributes. The Indexer Service shares a cost model with the gateways for each subgraph for which they intend to respond to queries. The gateways, in turn, use the cost model to make Indexer selection decisions per query and to negotiate payment with chosen Indexers.
+
+#### Agora
+
+Ngôn ngữ Agora cung cấp một định dạng linh hoạt để khai báo các mô hình chi phí cho các truy vấn. Mô hình giá Agora là một chuỗi các câu lệnh thực thi theo thứ tự cho mỗi truy vấn cấp cao nhất trong một truy vấn GraphQL. Đối với mỗi truy vấn cấp cao nhất, câu lệnh đầu tiên phù hợp với nó xác định giá cho truy vấn đó.
+
+Một câu lệnh bao gồm một vị từ (predicate), được sử dụng để đối sánh các truy vấn GraphQL và một biểu thức chi phí mà khi được đánh giá sẽ xuất ra chi phí ở dạng GRT thập phân. Các giá trị ở vị trí đối số được đặt tên của một truy vấn có thể được ghi lại trong vị từ và được sử dụng trong biểu thức. Các Globals có thể được đặt và thay thế cho các phần giữ chỗ trong một biểu thức.
+
+Mô hình chi phí mẫu:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Example query costing using the above model:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Áp dụng mô hình chi phí
+
+Cost models are applied via the Indexer CLI, which passes them to the Indexer Management API of the Indexer agent for storing in the database. The Indexer Service will then pick them up and serve the cost models to gateways whenever they ask for them.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Tương tác với mạng
+
+### Stake trong giao thức
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Phê duyệt các token
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Stake các token
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### Tuổi thọ của một phân bổ
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From c390fb20e2c6c06ff7bdc12cff547c114de6cdd6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:15:59 -0500
Subject: [PATCH 0913/3820] New translations tap.mdx (Vietnamese)

---
 website/pages/vi/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/vi/indexing/tap.mdx

diff --git a/website/pages/vi/indexing/tap.mdx b/website/pages/vi/indexing/tap.mdx
new file mode 100644
index 000000000000..eccf6efc1d41
--- /dev/null
+++ b/website/pages/vi/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Tổng quan
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notes:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From 852b537ec8ffc784a4f9c692f9ed4d895f9889ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:00 -0500
Subject: [PATCH 0914/3820] New translations graph-node.mdx (Vietnamese)

---
 .../pages/vi/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/vi/indexing/tooling/graph-node.mdx

diff --git a/website/pages/vi/indexing/tooling/graph-node.mdx b/website/pages/vi/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..2bb9cff76bc6
--- /dev/null
+++ b/website/pages/vi/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL database
+
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
+
+### Network clients
+
+In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS Nodes
+
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+### Prometheus metrics server
+
+To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
+
+### Bắt đầu từ nguồn
+
+#### Cài đặt điều kiện tiên quyết
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Cài đặt
+
+1. Khởi động máy chủ cơ sở dữ liệu PostgreSQL
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Bây giờ tất cả các phụ thuộc đã được thiết lập, hãy khởi động Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Getting started with Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+When it is running Graph Node exposes the following ports:
+
+| Cổng | Mục đích                                              | Tuyến                                          | Đối số CLI         | Biến môi trường |
+| ---- | ----------------------------------------------------- | ---------------------------------------------- | ------------------ | --------------- |
+| 8000 | Máy chủ GraphQL HTTP<br />(cho các truy vấn subgraph) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -               |
+| 8001 | GraphQL WS<br />(cho các đăng ký subgraph)            | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -               |
+| 8020 | JSON-RPC<br />(để quản lý triển khai)                 | /                                              | \--admin-port      | -               |
+| 8030 | API trạng thái lập chỉ mục Subgraph                   | /graphql                                       | \--index-node-port | -               |
+| 8040 | Số liệu Prometheus                                    | /metrics                                       | \--metrics-port    | -               |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Advanced Graph Node configuration
+
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Multiple Graph Nodes
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding.
+
+#### Deployment rules
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Example deployment rule configuration:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Dedicated query nodes
+
+Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Any node whose --node-id matches the regular expression will be set up to only respond to queries.
+
+#### Database scaling via sharding
+
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore.
+
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Dedicated block ingestion
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Supporting multiple networks
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Multiple networks
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Environment variables
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Continuous deployment
+
+Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Managing Graph Node
+
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Working with subgraphs
+
+#### Indexing status API
+
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Indexing performance
+
+There are three separate parts of the indexing process:
+
+- Fetching events of interest from the provider
+- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
+- Writing the resulting data to the store
+
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+
+Common causes of indexing slowness:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- A large number of events to process
+- Slow database connection time, for crowded nodes
+- The provider itself falling behind the chain head
+- Slowness in fetching new receipts at the chain head from the provider
+
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+
+#### Failed subgraphs
+
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+
+- Deterministic failures: these are failures which will not be resolved with retries
+- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
+
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Block and call cache
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. If the block matches the provider, then the issue can be debugged directly against the provider.
+
+#### Querying issues and errors
+
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+
+However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+
+There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.
+
+##### Query caching
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analysing queries
+
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
+
+In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
+
+##### Account-like optimisation
+
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Removing subgraphs
+
+> This is new functionality, which will be available in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 1d978573e38b3009706af200801adb39564eeef5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:01 -0500
Subject: [PATCH 0915/3820] New translations advanced.mdx (Vietnamese)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/vi/subgraphs/developing/creating/advanced.mdx b/website/pages/vi/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..757cec73a8fa
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Tổng quan
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Lỗi không nghiêm trọng
+
+Indexing errors on already synced subgraphs will, by default, cause the subgraph to fail and stop syncing. Subgraphs can alternatively be configured to continue syncing in the presence of errors, by ignoring the changes made by the handler which provoked the error. This gives subgraph authors time to correct their subgraphs while queries continue to be served against the latest block, though the results might be inconsistent due to the bug that caused the error. Note that some errors are still always fatal. To be non-fatal, the error must be known to be deterministic.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Enabling non-fatal errors requires setting the following feature flag on the subgraph manifest:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way. File data sources support fetching files from IPFS and from Arweave.
+
+> This also lays the groundwork for deterministic indexing of off-chain data, as well as the potential introduction of arbitrary HTTP-sourced data.
+
+### Tổng quan
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Upgrade guide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Add a new entity type which will be updated when files are found
+
+File data sources cannot access or update chain-based entities, but must update file specific entities.
+
+This may mean splitting out fields from existing entities into separate entities, linked together.
+
+Original combined entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+New, split entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+If the relationship is 1:1 between the parent entity and the resulting file data source entity, the simplest pattern is to link the parent entity to a resulting file entity by using the IPFS CID as the lookup. Get in touch on Discord if you are having difficulty modelling your new file-based entities!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+This is the data source which will be spawned when a file of interest is identified.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Create a new handler to process files
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Example handler:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Spawn file data sources when required
+
+You can now create file data sources during execution of chain-based handlers:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Example:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+This will create a new file data source, which will poll Graph Node's configured IPFS or Arweave endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Congratulations, you are using file data sources!
+
+#### Deploying your subgraphs
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitations
+
+File data source handlers and entities are isolated from other subgraph entities, ensuring that they are deterministic when executed, and ensuring no contamination of chain-based data sources. To be specific:
+
+- Entities created by File Data Sources are immutable, and cannot be updated
+- File Data Source handlers cannot access entities from other file data sources
+- Entities associated with File Data Sources cannot be accessed by chain-based handlers
+
+> While this constraint should not be problematic for most use-cases, it may introduce complexity for some. Please get in touch via Discord if you are having issues modelling your file-based data in a subgraph!
+
+Additionally, it is not possible to create data sources from a file data source, be it an onchain data source or another file data source. This restriction may be lifted in the future.
+
+#### Best practices
+
+If you are linking NFT metadata to corresponding tokens, use the metadata's IPFS hash to reference a Metadata entity from the Token entity. Save the Metadata entity using the IPFS hash as an ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> We are working to improve the above recommendation, so queries only return the "most recent" version
+
+#### Known issues
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Examples
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### References
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Ghép vào các Subgraph Hiện có
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Because grafting copies rather than indexes base data, it is much quicker to get the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- Nó thay đổi đối với loại thực thể nào mà một giao diện được triển khai
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 0af6009ee0b211a4131bedbf3da8d5b0331b3c4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:03 -0500
Subject: [PATCH 0916/3820] New translations api.mdx (Vietnamese)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/vi/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/vi/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..731770a79c96
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## Tham chiếu API
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- Các primitives cấp thấp để dịch giữa các hệ thống kiểu khác nhau như Ethereum, JSON, GraphQL và AssemblyScript.
+
+### Các phiên bản
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| Phiên bản | Ghi chú phát hành                                                                                                                                                                                                                                        |
+| :-------: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|   0.0.9   | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|   0.0.8   | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|   0.0.7   | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|   0.0.6   | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|   0.0.5   | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|   0.0.4   | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|   0.0.3   | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|   0.0.2   | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### Các loại cài sẵn
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Tạo các thực thể
+
+The following is a common pattern for creating entities from Ethereum events.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Loading entities from the store
+
+If an entity already exists, it can be loaded from the store with the following:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Looking up entities created withing a block
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### Cập nhật các thực thể hiện có
+
+There are two ways to update an existing entity:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+Changing properties is straight forward in most cases, thanks to the generated property setters:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+It is also possible to unset properties with one of the following two instructions:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Removing entities from the store
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
+
+#### Hỗ trợ các loại Ethereum
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+The following example illustrates this. Given a subgraph schema like
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Sự kiện và dữ liệu Khối/Giao dịch
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Quyền truy cập vào Trạng thái Hợp đồng Thông minh
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+A common pattern is to access the contract from which an event originates. This is achieved with the following code:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address.
+
+#### Xử lý các lệnh gọi được hoàn nguyên
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Mã hóa / Giải mã ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+For more information:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Logging một hoặc nhiều giá trị
+
+##### Logging một giá trị duy nhất
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Logging một mục nhập từ một mảng hiện có
+
+In the example below, only the first value of the argument array is logged, despite the array containing three values.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Logging nhiều mục nhập từ một mảng hiện có
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Logging một mục cụ thể từ một mảng hiện có
+
+To display a specific value in the array, the indexed value must be provided.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Logging thông tin sự kiện
+
+The example below logs the block number, block hash and transaction hash from an event:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Given an IPFS hash or path, reading a file from IPFS is done as follows:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### Tham chiếu Chuyển đổi Loại
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### Siêu Dữ liệu Nguồn Dữ liệu
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entity và DataSourceContext
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From d3713982f9cf85e6ea42957436ba220ea08a104a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:04 -0500
Subject: [PATCH 0917/3820] New translations common-issues.mdx (Vietnamese)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/vi/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/vi/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..f8d0c9c004c2
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Common AssemblyScript Issues
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 9c6d9d20fa9d9b3a5b2e83069e69ef1e7c1f56b5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:05 -0500
Subject: [PATCH 0918/3820] New translations unit-testing-framework.mdx
 (Vietnamese)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/vi/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/vi/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..f47680902afb
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Unit Testing Framework
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Getting Started
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+or
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+This will run all tests in the test folder:
+
+```sh
+graph test
+```
+
+This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
+
+```sh
+graph test gravity
+```
+
+This will run only that specific test file:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo subgraph
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Video tutorials
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+or
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Các ví dụ:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Example:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Các ví dụ:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Write a Unit Test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Assuming we have the following handler function (along with two helper functions to make our life easier):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+We first have to create a test file in our project. This is an example of how that might look like:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- We're setting up our initial state and adding one custom Gravatar entity;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- We assert the state of the store. How does that work? - We're passing a unique combination of Entity type and id. Then we check a specific field on that Entity and assert that it has the value we expect it to have. We're doing this both for the initial Gravatar Entity we added to the store, as well as the two Gravatar entities that gets added when the handler function is called;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+There we go - we've created our first test! 👏
+
+Now in order to run our tests you simply need to run the following in your subgraph root folder:
+
+`graph test Gravity`
+
+And if all goes well you should be greeted with the following:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Common test scenarios
+
+### Hydrating the store with a certain state
+
+Users are able to hydrate the store with a known set of entities. Here's an example to initialise the store with a Gravatar entity:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Calling a mapping function with an event
+
+A user can create a custom event and pass it to a mapping function that is bound to the store:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Calling all of the mappings with event fixtures
+
+Users can call the mappings with test fixtures.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocking contract calls
+
+Users can mock contract calls:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+As demonstrated, in order to mock a contract call and hardcore a return value, the user must provide a contract address, function name, function signature, an array of arguments, and of course - the return value.
+
+Users can also mock function reverts:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking IPFS files (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Asserting the state of the store
+
+Users are able to assert the final (or midway) state of the store through asserting entities. In order to do this, the user has to supply an Entity type, the specific ID of an Entity, a name of a field on that Entity, and the expected value of the field. Here's a quick example:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interacting with Event metadata
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Asserting variable equality
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Users can assert that an entity does not exist in the store. The function takes an entity type and an id. If the entity is in fact in the store, the test will fail with a relevant error message. Here's a quick example of how to use this functionality:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+You can print the whole store to the console using this helper function:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Expected failure
+
+Users can have expected test failures, using the shouldFail flag on the test() functions:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+If the test is marked with shouldFail = true but DOES NOT fail, that will show up as an error in the logs and the test block will fail. Also, if it's marked with shouldFail = false (the default state), the test executor will crash.
+
+### Logging
+
+Having custom logs in the unit tests is exactly the same as logging in the mappings. The difference is that the log object needs to be imported from matchstick-as rather than graph-ts. Here's a simple example with all non-critical log types:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Users can also simulate a critical failure, like so:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Logging critical errors will stop the execution of the tests and blow everything up. After all - we want to make sure you're code doesn't have critical logs in deployment, and you should notice right away if that were to happen.
+
+### Testing derived fields
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testing dynamic data sources
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Example below:
+
+First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+And then we have the test using one of the methods in the dataSourceMock namespace to set a new return value for all of the dataSource functions:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Notice that dataSourceMock.resetValues() is called at the end. That's because the values are remembered when they are changed and need to be reset if you want to go back to the default values.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Test Coverage
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Điều kiện tiên quyết
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Export your handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Sử dụng
+
+Once that's all set up, to run the test coverage tool, simply run:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Test run time duration in the log output
+
+The log output includes the test run duration. Here's an example:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Common compiler errors
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Additional Resources
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Feedback
+
+If you have any questions, feedback, feature requests or just want to reach out, the best place would be The Graph Discord where we have a dedicated channel for Matchstick, called 🔥| unit-testing.

From 1c36d6b0bb8a310d4cdd0b418657d0632ee5536b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:06 -0500
Subject: [PATCH 0919/3820] New translations transferring-a-subgraph.mdx
 (Vietnamese)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/vi/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/vi/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From f4a39abf14a4025b089ba2d8fa719f5c07c8a03e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:07 -0500
Subject: [PATCH 0920/3820] New translations graphql-api.mdx (Vietnamese)

---
 .../vi/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/vi/subgraphs/querying/graphql-api.mdx b/website/pages/vi/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..380c4abb48be
--- /dev/null
+++ b/website/pages/vi/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Examples
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sorting
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Ví dụ
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Example for nested entity sorting
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Pagination
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Query the first 10 tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtering
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Example for range filtering
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for block filtering
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for nested entity filtering
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+This can be useful if you are looking to fetch only entities whose child-level entities meet the provided conditions.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logical operators
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### All Filters
+
+Full list of parameter suffixes:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Time-travel queries
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Ví dụ
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Ví dụ
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltext Search Queries
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Fulltext search operators:
+
+| Biểu tượng | Toán tử     | Miêu tả                                                                                                                                                  |
+| ---------- | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`        | `And`       | Để kết hợp nhiều cụm từ tìm kiếm thành một bộ lọc cho các thực thể bao gồm tất cả các cụm từ được cung cấp                                               |
+| |          | `Or`        | Các truy vấn có nhiều cụm từ tìm kiếm được phân tách bằng toán tử hoặc sẽ trả về tất cả các thực thể có kết quả khớp với bất kỳ cụm từ nào được cung cấp |
+| `<->`      | `Follow by` | Chỉ định khoảng cách giữa hai từ.                                                                                                                        |
+| `:*`       | `Prefix`    | Sử dụng cụm từ tìm kiếm tiền tố để tìm các từ có tiền tố khớp với nhau (yêu cầu 2 ký tự.)                                                                |
+
+#### Examples
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validation
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Lược đồ
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Subgraph Metadata
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: the hash of the block
+- number: the block number
+- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From f09c7431f02182e8ff2d13532af8467dcc6a0a2c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:08 -0500
Subject: [PATCH 0921/3820] New translations python.mdx (Vietnamese)

---
 .../pages/vi/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/querying/python.mdx

diff --git a/website/pages/vi/subgraphs/querying/python.mdx b/website/pages/vi/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..c10d7a0e57ab
--- /dev/null
+++ b/website/pages/vi/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Getting Started
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 098fd29ac73ca52e1a99c649d7074b43404e31ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:09 -0500
Subject: [PATCH 0922/3820] New translations triggers.mdx (Vietnamese)

---
 website/pages/vi/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/vi/substreams/sps/triggers.mdx

diff --git a/website/pages/vi/substreams/sps/triggers.mdx b/website/pages/vi/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/vi/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 6d77cbb40106ecab01fb8f6a5820759731ec5652 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:10 -0500
Subject: [PATCH 0923/3820] New translations overview.mdx (Marathi)

---
 website/pages/mr/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/mr/indexing/overview.mdx

diff --git a/website/pages/mr/indexing/overview.mdx b/website/pages/mr/indexing/overview.mdx
new file mode 100644
index 000000000000..929bdf624e9d
--- /dev/null
+++ b/website/pages/mr/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+
+प्रोटोकॉलमध्ये स्टॅक केलेले GRT वितळण्याच्या कालावधीच्या अधीन आहे आणि जर इंडेक्सर्स दुर्भावनापूर्ण असतील आणि ऍप्लिकेशन्सना चुकीचा डेटा देत असतील किंवा ते चुकीच्या पद्धतीने इंडेक्स करत असतील तर ते कमी केले जाऊ शकतात. इंडेक्सर्स नेटवर्कमध्ये योगदान देण्यासाठी डेलिगेटर्सकडून डेलिगेटेड स्टेकसाठी बक्षिसे देखील मिळवतात.
+
+इंडेक्सर्स सबग्राफच्या क्युरेशन सिग्नलच्या आधारे इंडेक्समध्ये सबग्राफ निवडतात, जिथे क्यूरेटर्स जीआरटी घेतात जेणेकरून कोणते सबग्राफ उच्च-गुणवत्तेचे आहेत आणि त्यांना प्राधान्य दिले पाहिजे. ग्राहक (उदा. ऍप्लिकेशन्स) मापदंड देखील सेट करू शकतात ज्यासाठी इंडेक्सर्स त्यांच्या सबग्राफसाठी क्वेरी प्रक्रिया करतात आणि क्वेरी शुल्क किंमतीसाठी प्राधान्ये सेट करतात.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### What is the minimum stake required to be an Indexer on the network?
+
+The minimum stake for an Indexer is currently set to 100K GRT.
+
+### What are the revenue streams for an Indexer?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### How are indexing rewards distributed?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### What is a proof of indexing (POI)?
+
+इंडेक्सर त्यांनी वाटप केलेले सबग्राफ अनुक्रमित करत आहे हे सत्यापित करण्यासाठी नेटवर्कमध्ये POIs वापरले जातात. इंडेक्सिंग रिवॉर्ड्ससाठी पात्र होण्यासाठी त्या वाटपाचे वाटप बंद करताना वर्तमान युगाच्या पहिल्या ब्लॉकसाठी POI सबमिट करणे आवश्यक आहे. ब्लॉकसाठी POI हे सर्व एंटिटी स्टोअर व्यवहारांसाठी एक डायजेस्ट आहे जे विशिष्ट सबग्राफ तैनातीसाठी आणि त्या ब्लॉकपर्यंत समाविष्ट आहे.
+
+### When are indexing rewards distributed?
+
+वाटप सक्रिय असताना आणि 28 युगांमध्ये वाटप करत असताना ते सतत बक्षिसे मिळवत असतात. इंडेक्सर्सद्वारे बक्षिसे गोळा केली जातात आणि जेव्हाही त्यांचे वाटप बंद होते तेव्हा ते वितरित केले जातात. हे एकतर मॅन्युअली घडते, जेव्हा जेव्हा इंडेक्सर त्यांना सक्तीने बंद करू इच्छितो, किंवा 28 युगांनंतर एक प्रतिनिधी इंडेक्सरसाठी वाटप बंद करू शकतो, परंतु यामुळे कोणतेही पुरस्कार मिळत नाहीत. 28 युग हे जास्तीत जास्त वाटप आजीवन आहे (सध्या, एक युग ~24 तास चालतो).
+
+### Can pending indexing rewards be monitored?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+समुदायाने बनवलेल्या अनेक डॅशबोर्डमध्ये प्रलंबित पुरस्कार मूल्यांचा समावेश आहे आणि ते या चरणांचे अनुसरण करून सहजपणे व्यक्तिचलितपणे तपासले जाऊ शकतात:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### विवाद काय आहेत आणि मी ते कोठे पाहू शकतो?
+
+इंडेक्सरच्या क्वेरी आणि वाटप या दोन्ही विवाद कालावधी दरम्यान ग्राफवर विवादित केले जाऊ शकतात. विवादाच्या प्रकारानुसार विवाद कालावधी बदलतो. क्वेरी/प्रमाणपत्रांमध्ये 7 युग विवाद विंडो आहे, तर वाटपांमध्ये 56 युगे आहेत. हा कालावधी संपल्यानंतर, वाटप किंवा क्वेरी यापैकी कोणतेही विवाद उघडले जाऊ शकत नाहीत. जेव्हा विवाद उघडला जातो, तेव्हा मच्छिमारांना किमान 10,000 GRT जमा करणे आवश्यक असते, जे विवाद अंतिम होईपर्यंत आणि ठराव दिले जाईपर्यंत लॉक केले जाईल. मच्छीमार हे कोणतेही नेटवर्क सहभागी आहेत जे विवाद उघडतात.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- विवाद नाकारल्यास, मच्छिमारांनी जमा केलेला GRT जाळून टाकला जाईल आणि विवादित इंडेक्सर कमी केला जाणार नाही.
+- विवाद सोडतीप्रमाणे निकाली काढल्यास, मच्छिमारांची ठेव परत केली जाईल आणि विवादित इंडेक्सर कमी केला जाणार नाही.
+- विवाद स्वीकारल्यास, मच्छिमारांनी जमा केलेला GRT परत केला जाईल, विवादित इंडेक्सर कमी केला जाईल आणि मच्छिमारांना कमी केलेल्या GRT च्या 50% मिळतील.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### What are query fee rebates and when are they distributed?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+
+### What is query fee cut and indexing reward cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### How do Indexers know which subgraphs to index?
+
+सबग्राफ इंडेक्सिंग निर्णय घेण्यासाठी प्रगत तंत्रे लागू करून इंडेक्सर्स स्वतःला वेगळे करू शकतात परंतु सामान्य कल्पना देण्यासाठी आम्ही नेटवर्कमधील सबग्राफचे मूल्यांकन करण्यासाठी वापरल्या जाणार्‍या अनेक मुख्य मेट्रिक्सवर चर्चा करू:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### What are the hardware requirements?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Setup  | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| ------ | :------------------: | :---------------------------: | :-------------------------: | :-------------: | :----------------------: |
+| Small  |           4          |               8               |              1              |        4        |            16            |
+| मानक   |           8          |               30              |              1              |        12       |            48            |
+| Medium |          16          |               64              |              2              |        32       |            64            |
+| Large  |          72          |              468              |             3.5             |        48       |            184           |
+
+### What are some basic security precautions an Indexer should take?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastructure
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+टीप: चपळ स्केलिंगला समर्थन देण्यासाठी, नोड्सच्या वेगवेगळ्या सेटमध्ये क्वेरी आणि इंडेक्सिंग चिंता विभक्त करण्याची शिफारस केली जाते: क्वेरी नोड्स आणि इंडेक्स नोड्स.
+
+### Ports overview
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### आलेख नोड
+
+| बंदर | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
+
+#### Indexer Service
+
+| बंदर | Purpose                                              | Routes                                                      | CLI Argument    | Environment Variable   |
+| ---- | ---------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                   | /metrics                                                    | \--metrics-port | -                      |
+
+#### Indexer Agent
+
+| बंदर | Purpose                 | Routes | CLI Argument               | Environment Variable                    |
+| ---- | ----------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | इंडेक्सर व्यवस्थापन API | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Setup server infrastructure using Terraform on Google Cloud
+
+> Note: Indexers can alternatively use AWS, Microsoft Azure, or Alibaba.
+
+#### Install prerequisites
+
+- Google Cloud SDK
+- Kubectl command line tool
+- Terraform
+
+#### Create a Google Cloud Project
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Authenticate with Google Cloud and create a new project.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Use the Google Cloud Console's billing page to enable billing for the new project.
+
+- Create a Google Cloud configuration.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Enable required Google Cloud APIs.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Create a service account.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Enable peering between database and Kubernetes cluster that will be created in the next step.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Create minimal terraform configuration file (update as needed).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Use Terraform to create infrastructure
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Run the following commands to create the infrastructure.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Creating the Kubernetes components for the Indexer
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### आलेख नोड
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Getting started from source
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start a PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Now that all the dependencies are setup, start the Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Getting started using Docker
+
+#### पूर्वतयारी
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Setup
+
+1. Clone Graph Node and navigate to the Docker directory:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Start a local Graph Node that will connect to your Ethereum endpoint:
+
+```sh
+docker-compose up
+```
+
+### Indexer components
+
+फक्त लिनक्स वापरण्यासाठी - स्क्रिप्ट वापरून <code>docker-compose. yaml</code> मध्ये <code>host. docker. internal</code> समाविष्ट करा होस्ट आयपी पत्ता वापरा:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Getting started
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### From NPM packages
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### From source
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Using docker
+
+- Pull images from the registry
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Or build images locally from source
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Run the components
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Using K8s and Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### वापर
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexer agent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Indexer management using Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### वापर
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Indexing rules
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Data model:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Example usage of indexing rule:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Action added to the queue by the 3rd party optimizer tool or indexer-cli user
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- इंडेक्सर कारवाईच्या अंमलबजावणीचा इतिहास पाहण्यासाठी कृती रांगेचे निरीक्षण करू शकतो आणि आवश्यक असल्यास क्रिया आयटमची अंमलबजावणी अयशस्वी झाल्यास पुन्हा मंजूर आणि अद्यतनित करू शकतो. कृती रांग रांगेत लावलेल्या आणि केलेल्या सर्व क्रियांचा इतिहास प्रदान करते.
+
+Data model:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Example usage from source:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Note that supported action types for allocation management have different input requirements:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - required action params:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - required action params:
+    - allocationID
+    - deploymentID
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - required action params:
+    - allocationID
+    - deploymentID
+    - amount
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+#### Cost models
+
+किंमत मॉडेल बाजार आणि क्वेरी गुणधर्मांवर आधारित क्वेरीसाठी डायनॅमिक किंमत प्रदान करतात. इंडेक्सर सेवा प्रत्येक सबग्राफसाठी गेटवेसह किंमत मॉडेल सामायिक करते ज्यासाठी ते प्रश्नांना उत्तर देऊ इच्छितात. गेटवे, या बदल्यात, प्रति क्वेरी इंडेक्सर निवड निर्णय घेण्यासाठी आणि निवडलेल्या इंडेक्सर्ससह पेमेंटची वाटाघाटी करण्यासाठी किंमत मॉडेलचा वापर करतात.
+
+#### Agora
+
+अगोरा भाषा प्रश्नांसाठी किंमत मॉडेल घोषित करण्यासाठी एक लवचिक स्वरूप प्रदान करते. Agora किंमत मॉडेल हे विधानांचा एक क्रम आहे जो GraphQL क्वेरीमधील प्रत्येक उच्च-स्तरीय क्वेरीसाठी क्रमाने कार्यान्वित करतो. प्रत्येक उच्च-स्तरीय क्वेरीसाठी, त्याच्याशी जुळणारे पहिले विधान त्या क्वेरीसाठी किंमत निर्धारित करते.
+
+स्टेटमेंटमध्ये प्रेडिकेटचा समावेश असतो, जो ग्राफक्यूएल क्वेरीशी जुळण्यासाठी वापरला जातो आणि किंमत एक्स्प्रेशन ज्याचे मूल्यमापन केल्यावर दशांश GRT मध्ये खर्च येतो. क्वेरीच्या नामित युक्तिवाद स्थितीतील मूल्ये प्रेडिकेटमध्ये कॅप्चर केली जाऊ शकतात आणि अभिव्यक्तीमध्ये वापरली जाऊ शकतात. अभिव्यक्तीमध्ये प्लेसहोल्डर्ससाठी ग्लोबल देखील सेट आणि बदलले जाऊ शकतात.
+
+Example cost model:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Example query costing using the above model:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Applying the cost model
+
+किमतीचे मॉडेल इंडेक्सर CLI द्वारे लागू केले जातात, जे त्यांना डेटाबेसमध्ये साठवण्यासाठी इंडेक्सर एजंटच्या इंडेक्सर मॅनेजमेंट API कडे पाठवतात. इंडेक्सर सेवा नंतर त्यांना उचलेल आणि गेटवेला जेव्हा ते मागतील तेव्हा किंमत मॉडेल सर्व्ह करेल.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interacting with the network
+
+### Stake in the protocol
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Approve tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Stake tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### The life of an allocation
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From de9b2dc751a1ae714d465b79b4f27fa140ab7d19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:12 -0500
Subject: [PATCH 0924/3820] New translations tap.mdx (Marathi)

---
 website/pages/mr/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/mr/indexing/tap.mdx

diff --git a/website/pages/mr/indexing/tap.mdx b/website/pages/mr/indexing/tap.mdx
new file mode 100644
index 000000000000..f6248123d886
--- /dev/null
+++ b/website/pages/mr/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## सविश्लेषण
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+नोट्स:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From 99450f9c425c47f0e435e881cb605d8eecad4cf2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:13 -0500
Subject: [PATCH 0925/3820] New translations graph-node.mdx (Marathi)

---
 .../pages/mr/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/mr/indexing/tooling/graph-node.mdx

diff --git a/website/pages/mr/indexing/tooling/graph-node.mdx b/website/pages/mr/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..d00410536cac
--- /dev/null
+++ b/website/pages/mr/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: आलेख नोड
+---
+
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## आलेख नोड
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL डेटाबेस
+
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
+
+### नेटवर्क क्लायंट
+
+In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### आयपीएफएस नोड्स
+
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+### प्रोमिथियस मेट्रिक्स सर्व्हर
+
+To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
+
+### Getting started from source
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start a PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Now that all the dependencies are setup, start the Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Kubernetes सह प्रारंभ करणे
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+When it is running Graph Node exposes the following ports:
+
+| बंदर | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## प्रगत ग्राफ नोड कॉन्फिगरेशन
+
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### एकाधिक ग्राफ नोड्स
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding.
+
+#### डिप्लॉयमेंट नियम
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+उपयोजन नियम कॉन्फिगरेशनचे उदाहरण:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### समर्पित क्वेरी नोड्स
+
+Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Any node whose --node-id matches the regular expression will be set up to only respond to queries.
+
+#### शार्डिंगद्वारे डेटाबेस स्केलिंग
+
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore.
+
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### समर्पित ब्लॉक अंतर्ग्रहण
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### एकाधिक नेटवर्क समर्थन
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- एकाधिक नेटवर्क
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### पर्यावरण परिवर्तने
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### सतत तैनाती
+
+Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### ग्राफ नोडचे व्यवस्थापन
+
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+
+#### लॉगिंग
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### ग्राफमन
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### सबग्राफसह कार्य करणे
+
+#### अनुक्रमणिका स्थिती API
+
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### अनुक्रमणिका कार्यप्रदर्शन
+
+There are three separate parts of the indexing process:
+
+- प्रदात्याकडून स्वारस्यपूर्ण इव्हेंट आणत आहे
+- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
+- परिणामी डेटा स्टोअरमध्ये लिहित आहे
+
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+
+अनुक्रमणिका मंद होण्याची सामान्य कारणे:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- प्रक्रिया करण्यासाठी मोठ्या संख्येने इव्हेंट
+- गर्दीच्या नोड्ससाठी स्लो डेटाबेस कनेक्शन वेळ
+- प्रदाता स्वतः साखळी डोके मागे घसरण
+- Slowness in fetching new receipts at the chain head from the provider
+
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+
+#### अयशस्वी सबग्राफ
+
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+
+- Deterministic failures: these are failures which will not be resolved with retries
+- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
+
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### ब्लॉक आणि कॉल कॅशे
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. If the block matches the provider, then the issue can be debugged directly against the provider.
+
+#### समस्या आणि त्रुटींची चौकशी करणे
+
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+
+However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+
+There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.
+
+##### क्वेरी कॅशिंग
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### प्रश्नांचे विश्लेषण करत आहे
+
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
+
+In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
+
+##### खात्यासारखे ऑप्टिमायझेशन
+
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### सबग्राफ काढून टाकत आहे
+
+> This is new functionality, which will be available in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From fc4f267ee17ae323d12afb7180537faca19736a8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:14 -0500
Subject: [PATCH 0926/3820] New translations advanced.mdx (Marathi)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/mr/subgraphs/developing/creating/advanced.mdx b/website/pages/mr/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..5dc2a473ef77
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## सविश्लेषण
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## गैर-घातक त्रुटी
+
+आधीच समक्रमित केलेल्या सबग्राफ्सवर अनुक्रमणिका त्रुटी, डीफॉल्टनुसार, सबग्राफ अयशस्वी होण्यास आणि समक्रमण थांबवण्यास कारणीभूत ठरतील. सबग्राफ वैकल्पिकरित्या त्रुटींच्या उपस्थितीत समक्रमण सुरू ठेवण्यासाठी कॉन्फिगर केले जाऊ शकतात, हँडलरने केलेल्या बदलांकडे दुर्लक्ष करून, ज्यामुळे त्रुटी उद्भवली. हे सबग्राफ लेखकांना त्यांचे सबग्राफ दुरुस्त करण्यासाठी वेळ देते जेव्हा की नवीनतम ब्लॉकच्या विरूद्ध क्वेरी चालू ठेवल्या जातात, जरी त्रुटीमुळे परिणाम विसंगत असू शकतात. लक्षात घ्या की काही त्रुटी अजूनही नेहमीच घातक असतात. गैर-घातक होण्यासाठी, त्रुटी निश्चितपणे ज्ञात असणे आवश्यक आहे.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Enabling non-fatal errors requires setting the following feature flag on the subgraph manifest:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way. File data sources support fetching files from IPFS and from Arweave.
+
+> हे ऑफ-चेन डेटाच्या निर्धारवादी अनुक्रमणिकेसाठी तसेच अनियंत्रित HTTP-स्रोत डेटाच्या संभाव्य परिचयासाठी देखील पाया घालते.
+
+### सविश्लेषण
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Upgrade guide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Add a new entity type which will be updated when files are found
+
+File data sources cannot access or update chain-based entities, but must update file specific entities.
+
+This may mean splitting out fields from existing entities into separate entities, linked together.
+
+मूळ एकत्रित अस्तित्व:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+नवीन, विभाजित अस्तित्व:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+जर मूळ घटक आणि परिणामी फाइल डेटा स्रोत घटक यांच्यातील संबंध 1:1 असेल तर, आयपीएफएस सीआयडी लुकअप म्हणून वापरून मूळ घटकाला परिणामी फाइल घटकाशी जोडणे हा सर्वात सोपा नमुना आहे. तुम्हाला तुमच्या नवीन फाइल-आधारित घटकांचे मॉडेलिंग करण्यात अडचण येत असल्यास Discord वर संपर्क साधा!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+This is the data source which will be spawned when a file of interest is identified.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### फाइल्सवर प्रक्रिया करण्यासाठी नवीन हँडलर तयार करा
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+उदाहरण हँडलर:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### आवश्यकतेनुसार फाईल डेटा स्रोत तयार करा
+
+You can now create file data sources during execution of chain-based handlers:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+उदाहरण:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+This will create a new file data source, which will poll Graph Node's configured IPFS or Arweave endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Congratulations, you are using file data sources!
+
+#### तुमचे सबग्राफ उपयोजित करत आहे
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitations
+
+फाइल डेटा स्रोत हँडलर आणि संस्था इतर सबग्राफ संस्थांपासून वेगळ्या केल्या जातात, ते कार्यान्वित केल्यावर ते निर्धारवादी आहेत याची खात्री करून आणि साखळी-आधारित डेटा स्रोतांचे दूषित होणार नाही याची खात्री करतात. विशिष्ट असणे:
+
+- Entities created by File Data Sources are immutable, and cannot be updated
+- File Data Source handlers cannot access entities from other file data sources
+- Entities associated with File Data Sources cannot be accessed by chain-based handlers
+
+> बहुतेक वापर-प्रकरणांसाठी ही मर्यादा समस्याप्रधान नसावी, परंतु काहींसाठी ते जटिलता आणू शकते. सबग्राफमध्‍ये तुमच्‍या फाईल-आधारित डेटाचे मॉडेल बनवण्‍यात तुम्‍हाला समस्या येत असल्‍यास कृपया डिस्‍कॉर्ड द्वारे संपर्क साधा!
+
+याव्यतिरिक्त, फाइल डेटा स्रोतावरून डेटा स्रोत तयार करणे शक्य नाही, मग ते ऑनचेन डेटा स्रोत असो किंवा अन्य फाइल डेटा स्रोत. भविष्यात हे निर्बंध उठवले जाऊ शकतात.
+
+#### चांगला सराव
+
+तुम्ही एनएफटी मेटाडेटाला संबंधित टोकनशी लिंक करत असल्यास, टोकन एंटिटीमधील मेटाडेटा घटकाचा संदर्भ देण्यासाठी मेटाडेटाचा IPFS हॅश वापरा. आयडी म्हणून IPFS हॅश वापरून मेटाडेटा घटक जतन करा.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> We are working to improve the above recommendation, so queries only return the "most recent" version
+
+#### ओळखलेले समस्या
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Examples
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### संदर्भ
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### विद्यमान सबग्राफवर कलम करणे
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+बेस डेटा इंडेक्स करण्याऐवजी कॉपीचे ग्राफ्टिंग केल्यामुळे, सुरवातीपासून इंडेक्स करण्यापेक्षा इच्छित ब्लॉकमध्ये सबग्राफ मिळवणे खूप जलद आहे, जरी सुरुवातीच्या डेटा कॉपीला खूप मोठ्या सबग्राफसाठी बरेच तास लागू शकतात. ग्रॅफ्टेड सबग्राफ सुरू होत असताना, ग्राफ नोड आधीपासून कॉपी केलेल्या घटक प्रकारांबद्दल माहिती लॉग करेल.
+
+ग्राफ्टेड सबग्राफ GraphQL स्कीमा वापरू शकतो जो बेस सबग्राफपैकी एकाशी एकसारखा नसतो, परंतु त्याच्याशी फक्त सुसंगत असतो. ती स्वतःच्या अधिकारात वैध सबग्राफ स्कीमा असणे आवश्यक आहे, परंतु खालील प्रकारे बेस सबग्राफच्या स्कीमापासून विचलित होऊ शकते:
+
+- हे घटक प्रकार जोडते किंवा काढून टाकते
+- हे घटक प्रकारातील गुणधर्म काढून टाकते
+- हे अस्तित्व प्रकारांमध्ये रद्द करण्यायोग्य विशेषता जोडते
+- हे नॉन-नलेबल अॅट्रिब्यूट्सना न्युलेबल अॅट्रिब्यूट्समध्ये बदलते
+- हे enums मध्ये मूल्ये जोडते
+- हे इंटरफेस जोडते किंवा काढून टाकते
+- कोणत्या घटकासाठी इंटरफेस लागू केला जातो ते बदलते
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 7305b35db38ab49306f1be3011b441d772764199 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:15 -0500
Subject: [PATCH 0927/3820] New translations api.mdx (Marathi)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/mr/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/mr/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..97cca409a0eb
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: असेंबलीस्क्रिप्ट API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API संदर्भ
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- Ethereum, JSON, GraphQL आणि असेंबलीस्क्रिप्ट सारख्या विविध प्रकारच्या सिस्टीममध्ये भाषांतर करण्यासाठी निम्न-स्तरीय आदिम.
+
+### आवृत्त्या
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| आवृत्ती | रिलीझ नोट्स                                                                                                                                                                                                                                              |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### अंगभूत प्रकार
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+'@graphprotocol/graph-ts' वरून { ByteArray } आयात करा
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### बिग डेसिमल
+
+```typescript
+'@graphprotocol/graph-ts' वरून { BigDecimal } आयात करा
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+'@graphprotocol/graph-ts' वरून { BigInt } आयात करा
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+'@graphprotocol/graph-ts' वरून { TypedMap } आयात करा
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### बाइट्स
+
+```typescript
+'@graphprotocol/graph-ts' वरून { Bytes } आयात करा
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### पत्ता
+
+```typescript
+'@graphprotocol/graph-ts' वरून { Address } आयात करा
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### स्टोअर API
+
+```typescript
+'@graphprotocol/graph-ts' वरून { store } आयात करा
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### अंदाज निर्मिती करणे
+
+इथरियम इव्हेंटमधून संस्था तयार करण्यासाठी खालील एक सामान्य नमुना आहे.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### स्टोअरमधून घटक लोड करत आहे
+
+एखादी संस्था आधीपासून अस्तित्वात असल्यास, ती खालील गोष्टींसह स्टोअरमधून लोड केली जाऊ शकते:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### ब्लॉकसह तयार केलेल्या संस्था शोधत आहे
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### विद्यमान घटक अद्यतनित करत आहे
+
+विद्यमान घटक अद्यतनित करण्याचे दोन मार्ग आहेत:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+व्युत्पन्न केलेल्या प्रॉपर्टी सेटरला धन्यवाद, बहुतेक प्रकरणांमध्ये गुणधर्म बदलणे सरळ पुढे आहे:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+खालील दोन सूचनांपैकी एकासह गुणधर्म अनसेट करणे देखील शक्य आहे:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### स्टोअरमधून एंटिटीस काढून टाकणे
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### इथरियम API
+
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
+
+#### इथरियम प्रकारांसाठी समर्थन
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+पुढील उदाहरण हे स्पष्ट करते. सारखी सबग्राफ स्कीमा दिली
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### इव्हेंट आणि ब्लॉक/व्यवहार डेटा
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### स्मार्ट कॉन्ट्रॅक्ट स्टेटमध्ये प्रवेश
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+कॉन्ट्रॅक्टमध्ये प्रवेश करणे हा एक सामान्य पॅटर्न आहे ज्यातून इव्हेंटची उत्पत्ती होते. हे खालील कोडसह साध्य केले आहे:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+सबग्राफचा भाग असलेला इतर कोणताही करार व्युत्पन्न केलेल्या कोडमधून आयात केला जाऊ शकतो आणि वैध पत्त्यावर बांधला जाऊ शकतो.
+
+#### रिव्हर्ट केलेले कॉल हाताळणे
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### एन्कोडिंग/डिकोडिंग ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+अधिक माहितीसाठी:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### लॉगिंग API
+
+```typescript
+'@graphprotocol/graph-ts' वरून { log } आयात करा
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('प्रदर्शनासाठी संदेश: {}, {}, {}', [value.toString(), anotherValue.toString(), 'आधीपासूनच एक स्ट्रिंग'])
+```
+
+#### एक किंवा अधिक मूल्ये लॉग करणे
+
+##### एकल मूल्य लॉग करत आहे
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### विद्यमान अॅरेमधून एकल एंट्री लॉग करत आहे
+
+खालील उदाहरणामध्ये, तीन मूल्यांचा समावेश असूनही, केवळ वितर्क अॅरेचे पहिले मूल्य लॉग केले आहे.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### विद्यमान अॅरेमधून एकाधिक नोंदी लॉग करणे
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### विद्यमान अॅरेमधून विशिष्ट एंट्री लॉग करणे
+
+अॅरेमध्ये विशिष्ट मूल्य प्रदर्शित करण्यासाठी, अनुक्रमित मूल्य प्रदान करणे आवश्यक आहे.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### कार्यक्रम माहिती लॉगिंग
+
+खालील उदाहरण इव्हेंटमधील ब्लॉक नंबर, ब्लॉक हॅश आणि ट्रान्झॅक्शन हॅश लॉग करते:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+'@graphprotocol/graph-ts' वरून { ipfs } आयात करा
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+आयपीएफएस हॅश किंवा पथ दिल्यास, आयपीएफएस मधून फाइल वाचणे खालीलप्रमाणे केले जाते:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+'@graphprotocol/graph-ts' वरून { JSONValue, Value } आयात करा
+
+निर्यात कार्य प्रक्रिया आयटम(मूल्य: JSONValue, userData: मूल्य): void {
+  // व्यवहाराच्या तपशीलांसाठी JSONValue दस्तऐवजीकरण पहा
+  // JSON मूल्यांसह
+  द्या obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  जर (!id || !title) {
+    परत
+  }
+
+  // कॉलबॅक देखील संस्था तयार करू शकतात
+  let newItem = newItem(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // पालकांना "parentId" वर सेट करा
+  newitem.save()
+}
+
+// हे मॅपिंगमध्ये इव्हेंट हँडलरमध्ये ठेवा
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// वैकल्पिकरित्या, `ipfs.mapJSON` वापरा
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### क्रिप्टो API
+
+```typescript
+'@graphprotocol/graph-ts' वरून { crypto } आयात करा
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+'@graphprotocol/graph-ts' वरून { json, JSONValueKind } आयात करा
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### प्रकार रूपांतरण संदर्भ
+
+| Source(s)               | Destination             | Conversion function          |
+| ----------------------- | ----------------------- | ---------------------------- |
+| Address                 | Bytes                   | none                         |
+| Address                 | String                  | s.toHexString()              |
+| BigDecimal              | String                  | s.toString()                 |
+| BigInt                  | BigDecimal              | s.toBigDecimal()             |
+| BigInt                  | स्ट्रिंग (हेक्साडेसिमल) | s.toHexString() or s.toHex() |
+| BigInt                  | String (unicode)        | s.toString()                 |
+| BigInt                  | i32                     | s.toI32()                    |
+| Boolean                 | Boolean                 | none                         |
+| Bytes (signed)          | BigInt                  | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)        | BigInt                  | BigInt.fromUnsignedBytes(s)  |
+| Bytes                   | स्ट्रिंग (हेक्साडेसिमल) | s.toHexString() or s.toHex() |
+| Bytes                   | String (unicode)        | s.toString()                 |
+| Bytes                   | String (base58)         | s.toBase58()                 |
+| Bytes                   | i32                     | s.toI32()                    |
+| Bytes                   | u32                     | s.toU32()                    |
+| Bytes                   | JSON                    | json.fromBytes(s)            |
+| int8                    | i32                     | none                         |
+| int32                   | i32                     | none                         |
+| int32                   | BigInt                  | BigInt.fromI32(s)            |
+| uint24                  | i32                     | none                         |
+| int64 - int256          | BigInt                  | none                         |
+| uint32 - uint256        | BigInt                  | none                         |
+| JSON                    | boolean                 | s.toBool()                   |
+| JSON                    | i64                     | s.toI64()                    |
+| JSON                    | u64                     | s.toU64()                    |
+| JSON                    | f64                     | s.toF64()                    |
+| JSON                    | BigInt                  | s.toBigInt()                 |
+| JSON                    | string                  | s.toString()                 |
+| JSON                    | Array                   | s.toArray()                  |
+| JSON                    | Object                  | s.toObject()                 |
+| String                  | Address                 | Address.fromString(s)        |
+| Bytes                   | Address                 | Address.fromBytes(s)         |
+| String                  | BigInt                  | BigInt.fromString(s)         |
+| String                  | BigDecimal              | BigDecimal.fromString(s)     |
+| स्ट्रिंग (हेक्साडेसिमल) | Bytes                   | ByteArray.fromHexString(s)   |
+| String (UTF-8)          | Bytes                   | ByteArray.fromUTF8(s)        |
+
+### डेटा स्रोत मेटाडेटा
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### संस्था आणि डेटास्रोत संदर्भ
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From 127e6e1cd35f59d485185acce9274568113600ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:17 -0500
Subject: [PATCH 0928/3820] New translations common-issues.mdx (Marathi)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/mr/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/mr/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..d291033f3ff0
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: सामान्य असेंब्लीस्क्रिप्ट समस्या
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From e0bfbdb37bf06ccc0a2556b63aa35b4af52d6ee5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:18 -0500
Subject: [PATCH 0929/3820] New translations unit-testing-framework.mdx
 (Marathi)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/mr/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/mr/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..ffe35026063d
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: युनिट चाचणी फ्रेमवर्क
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## प्रारंभ करणे
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+डॉकर दृष्टिकोन आणि बायनरी दृष्टिकोन वापरून तुम्ही WSL वर मॅचस्टिक वापरू शकता. डब्ल्यूएसएल थोडे अवघड असू शकते, यासारख्या समस्या आल्यास येथे काही टिपा आहेत
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+किंवा
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI पर्याय
+
+हे चाचणी फोल्डरमधील सर्व चाचण्या चालवेल:
+
+```sh
+आलेख चाचणी
+```
+
+हे gravity.test.ts नावाची चाचणी आणि/किंवा गुरुत्वाकर्षण नावाच्या फोल्डरच्या आत सर्व चाचणी चालवेल:
+
+```sh
+graph test gravity
+```
+
+हे फक्त विशिष्ट चाचणी फाइल चालवेल:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### डॉकर
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### कॉन्फिगरेशन
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### डेमो सबग्राफ
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### व्हिडिओ ट्यूटोरियल
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### वर्णन करणे()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+उदाहरण:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### चाचणी()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+उदाहरण:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+किंवा
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### आधी सर्व()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+उदाहरणे:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### शेवटी()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+उदाहरण:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### प्रत्येकाच्या आधी()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### प्रत्येक नंतर()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+उदाहरणे:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## ठामपणे सांगतात
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## एक युनिट चाचणी लिहा
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+असे गृहीत धरून की आमच्याकडे खालील हँडलर फंक्शन आहे (आपले जीवन सोपे करण्यासाठी दोन मदतनीस कार्यांसह):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+आम्हाला आमच्या प्रोजेक्टमध्ये प्रथम चाचणी फाइल तयार करावी लागेल. ते कसे दिसू शकते याचे हे उदाहरण आहे:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- आम्ही आमची प्रारंभिक स्थिती सेट करत आहोत आणि एक कस्टम Gravatar अस्तित्व जोडत आहोत;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- आम्ही स्टोअरच्या स्थितीवर ठाम आहोत. ते कसे कार्य करते? - आम्ही अस्तित्व प्रकार आणि आयडीचे एक अद्वितीय संयोजन पास करत आहोत. मग आम्ही त्या घटकावरील विशिष्ट फील्ड तपासतो आणि असे प्रतिपादन करतो की तिच्याकडे अपेक्षित मूल्य आहे. आम्ही स्टोअरमध्ये जोडलेल्या सुरुवातीच्या Gravatar एंटिटीसाठी तसेच हँडलर फंक्शन कॉल केल्यावर जोडल्या जाणार्‍या दोन Gravatar घटकांसाठी आम्ही हे करत आहोत;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+आम्ही तिथे जातो - आम्ही आमची पहिली चाचणी तयार केली आहे! 👏
+
+आता आमच्या चाचण्या चालवण्यासाठी तुम्हाला तुमच्या सबग्राफ रूट फोल्डरमध्ये खालील गोष्टी चालवाव्या लागतील:
+
+`graph test Gravity`
+
+आणि जर सर्व काही ठीक झाले तर तुम्हाला पुढील गोष्टींसह स्वागत केले पाहिजे:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## सामान्य चाचणी परिस्थिती
+
+### एका विशिष्ट स्थितीसह स्टोअर हायड्रेटिंग
+
+वापरकर्ते ज्ञात घटकांच्या संचासह स्टोअर हायड्रेट करण्यास सक्षम आहेत. Gravatar घटकासह स्टोअर सुरू करण्यासाठी येथे एक उदाहरण आहे:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### इव्हेंटसह मॅपिंग फंक्शन कॉल करणे
+
+वापरकर्ता सानुकूल इव्हेंट तयार करू शकतो आणि स्टोअरला बांधील असलेल्या मॅपिंग फंक्शनमध्ये पास करू शकतो:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### इव्हेंट फिक्स्चरसह सर्व मॅपिंग कॉल करणे
+
+वापरकर्ते चाचणी फिक्स्चरसह मॅपिंग कॉल करू शकतात.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### मस्करी कॉन्ट्रॅक्ट कॉल
+
+वापरकर्ते कॉन्ट्रॅक्ट कॉलची थट्टा करू शकतात:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+दाखवल्याप्रमाणे, कॉन्ट्रॅक्ट कॉलची थट्टा करण्यासाठी आणि रिटर्न व्हॅल्यू हार्डकोर करण्यासाठी, वापरकर्त्याने कॉन्ट्रॅक्ट अॅड्रेस, फंक्शनचे नाव, फंक्शन सिग्नेचर, वितर्कांची अॅरे आणि अर्थातच - रिटर्न व्हॅल्यू प्रदान करणे आवश्यक आहे.
+
+वापरकर्ते फंक्शन रिव्हर्ट्सची थट्टा देखील करू शकतात:
+
+```typescript
+द्या कॉन्ट्रॅक्ट अॅड्रेस = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+   .withArgs([ethereum.Value.fromAddress(contractAddress)])
+   .परत करते()
+```
+
+### IPFS फाइल्सची थट्टा उडवणारी (माचस्टिक ०. ४. १ वरून)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### स्टोअरची स्थिती सांगून
+
+वापरकर्ते दावा करणार्‍या संस्थांद्वारे स्टोअरची अंतिम (किंवा मिडवे) स्थिती सांगू शकतात. हे करण्यासाठी, वापरकर्त्याला एंटिटी प्रकार, एंटिटीचा विशिष्ट आयडी, त्या घटकावरील फील्डचे नाव आणि फील्डचे अपेक्षित मूल्य पुरवावे लागेल. येथे एक द्रुत उदाहरण आहे:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### इव्हेंट मेटाडेटासह संवाद साधत आहे
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### व्हेरिएबल समानतेचे प्रतिपादन
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+वापरकर्ते असे ठामपणे सांगू शकतात की स्टोअरमध्ये अस्तित्व नाही. फंक्शन एक अस्तित्व प्रकार आणि आयडी घेते. वस्तुस्थिती स्टोअरमध्ये असल्यास, चाचणी संबंधित त्रुटी संदेशासह अयशस्वी होईल. ही कार्यक्षमता कशी वापरायची याचे एक द्रुत उदाहरण येथे आहे:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+हे हेल्पर फंक्शन वापरून तुम्ही संपूर्ण स्टोअर कन्सोलवर मुद्रित करू शकता:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### अपेक्षित अपयश
+
+चाचणी() फंक्शन्सवर shouldFail ध्वज वापरून वापरकर्त्यांना अपेक्षित चाचणी अपयश येऊ शकते:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+जर चाचणी shouldFail = true सह चिन्हांकित केली असेल परंतु अयशस्वी होत नसेल, तर ती लॉगमध्ये त्रुटी म्हणून दिसून येईल आणि चाचणी ब्लॉक अयशस्वी होईल. तसेच, जर हे shouldFail = false (डिफॉल्ट स्थिती) ने चिन्हांकित केले असेल, तर चाचणी निष्पादक क्रॅश होईल.
+
+### लॉगिंग
+
+युनिट चाचण्यांमध्ये सानुकूल लॉग असणे हे मॅपिंगमध्ये लॉग इन करण्यासारखेच आहे. फरक असा आहे की लॉग ऑब्जेक्ट ग्राफ-टीएस ऐवजी मॅचस्टिक-एज वरून आयात करणे आवश्यक आहे. सर्व गैर-गंभीर लॉग प्रकारांसह येथे एक साधे उदाहरण आहे:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+वापरकर्ते गंभीर अपयशाचे अनुकरण देखील करू शकतात, जसे की:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+गंभीर त्रुटी लॉग केल्याने चाचण्यांची अंमलबजावणी थांबेल आणि सर्वकाही उडून जाईल. शेवटी - आम्ही हे सुनिश्चित करू इच्छितो की तुमच्या कोडमध्ये डिप्लॉयमेंटमध्ये गंभीर नोंदी नाहीत, आणि तसे झाल्यास तुम्हाला लगेच लक्षात येईल.
+
+### व्युत्पन्न फील्ड चाचणी
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### डायनॅमिक डेटा स्रोतांची चाचणी
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+खालील उदाहरण:
+
+प्रथम आमच्याकडे खालील इव्हेंट हँडलर आहे (जे जाणूनबुजून डेटासोर्स मस्करी दाखवण्यासाठी पुन्हा केले गेले आहे):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+आणि मग डेटासोर्सच्या सर्व फंक्शन्ससाठी नवीन रिटर्न व्हॅल्यू सेट करण्यासाठी dataSourceMock नेमस्पेसमधील पद्धतींपैकी एक वापरून आमच्याकडे चाचणी आहे:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+लक्षात घ्या की शेवटी dataSourceMock.resetValues() कॉल केला आहे. याचे कारण असे की जेव्हा मूल्ये बदलली जातात तेव्हा ती लक्षात ठेवली जातात आणि जर तुम्हाला डीफॉल्ट मूल्यांवर परत जायचे असेल तर ते रीसेट करणे आवश्यक आहे.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## चाचणी कव्हरेज
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### पूर्वतयारी
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### तुमचे हँडलर निर्यात करा
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+'../../src/gravity' वरून { handleNewGravatar } आयात करा
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+निर्यात { handleNewGravatar }
+```
+
+### वापर
+
+एकदा ते सर्व सेट झाल्यानंतर, चाचणी कव्हरेज साधन चालविण्यासाठी, फक्त चालवा:
+
+```sh
+आलेख चाचणी-- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### लॉग आउटपुटमध्ये चाचणी रन टाइम कालावधी
+
+लॉग आउटपुटमध्ये चाचणी रन कालावधी समाविष्ट आहे. येथे एक उदाहरण आहे:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## सामान्य कंपाइलर त्रुटी
+
+> गंभीर: संदर्भासह वैध मॉड्यूलमधून WasmInstance तयार करू शकलो नाही: अज्ञात आयात: wasi_snapshot_preview1::fd_write परिभाषित केले गेले नाही
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> नवीन ethereum.Transaction परत करा(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## अतिरिक्त संसाधने
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## अभिप्राय
+
+तुमच्याकडे काही प्रश्न, अभिप्राय, वैशिष्ट्य विनंत्या असल्यास किंवा फक्त संपर्क साधायचा असल्यास, सर्वोत्तम ठिकाण म्हणजे The Graph Discord जेथे आमच्याकडे Matchstick साठी एक समर्पित चॅनेल आहे, ज्याला 🔥| युनिट-चाचणी.

From ddc58abf25bb54948f029cbd6351232b6013f9f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:19 -0500
Subject: [PATCH 0930/3820] New translations transferring-a-subgraph.mdx
 (Marathi)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/mr/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/mr/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From bb45ca6a14765be2806e4a99b71ecf7ac813da72 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:20 -0500
Subject: [PATCH 0931/3820] New translations graphql-api.mdx (Marathi)

---
 .../mr/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/mr/subgraphs/querying/graphql-api.mdx b/website/pages/mr/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..e78c16e9f438
--- /dev/null
+++ b/website/pages/mr/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Examples
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sorting
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### उदाहरण
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Example for nested entity sorting
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Pagination
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Query the first 10 tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtering
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Example for range filtering
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for block filtering
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for nested entity filtering
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+This can be useful if you are looking to fetch only entities whose child-level entities meet the provided conditions.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logical operators
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### All Filters
+
+Full list of parameter suffixes:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Time-travel queries
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### उदाहरण
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### उदाहरण
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltext Search Queries
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Fulltext search operators:
+
+| Symbol | Operator    | वर्णन                                                                                                                                |
+| ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
+
+#### Examples
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validation
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Subgraph Metadata
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: the hash of the block
+- number: the block number
+- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 0d8e00d6430bc8152e526d6865af58f3756113f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:21 -0500
Subject: [PATCH 0932/3820] New translations python.mdx (Marathi)

---
 .../pages/mr/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/querying/python.mdx

diff --git a/website/pages/mr/subgraphs/querying/python.mdx b/website/pages/mr/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..ed355941c0ca
--- /dev/null
+++ b/website/pages/mr/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## प्रारंभ करणे
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From a5ab9c39bc32e486d4f86efdab4651dc0ac53f98 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:22 -0500
Subject: [PATCH 0933/3820] New translations triggers.mdx (Marathi)

---
 website/pages/mr/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/mr/substreams/sps/triggers.mdx

diff --git a/website/pages/mr/substreams/sps/triggers.mdx b/website/pages/mr/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/mr/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 23e9273e9c9c0c82643466ec9fa6d9e49d451cd6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:24 -0500
Subject: [PATCH 0934/3820] New translations overview.mdx (Hindi)

---
 website/pages/hi/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/hi/indexing/overview.mdx

diff --git a/website/pages/hi/indexing/overview.mdx b/website/pages/hi/indexing/overview.mdx
new file mode 100644
index 000000000000..e157e17b9427
--- /dev/null
+++ b/website/pages/hi/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+
+जीआरटी जो प्रोटोकॉल में दांव पर लगा है, विगलन अवधि के अधीन है और यदि अनुक्रमणिका दुर्भावनापूर्ण हैं और अनुप्रयोगों को गलत डेटा प्रदान करते हैं या यदि वे गलत तरीके से अनुक्रमणित करते हैं तो इसे घटाया जा सकता है। इंडेक्सर्स नेटवर्क में योगदान करने के लिए डेलीगेटर्स से प्रत्यायोजित हिस्सेदारी के लिए पुरस्कार भी अर्जित करते हैं।
+
+इंडेक्सर्स सबग्राफ के क्यूरेशन सिग्नल के आधार पर इंडेक्स के लिए सबग्राफ का चयन करते हैं, जहां क्यूरेटर GRT को यह इंगित करने के लिए दांव पर लगाते हैं कि कौन से सबग्राफ उच्च-गुणवत्ता वाले हैं और उन्हें प्राथमिकता दी जानी चाहिए। उपभोक्ता (उदाहरण के लिए अनुप्रयोग) पैरामीटर भी सेट कर सकते हैं जिसके लिए इंडेक्सर्स अपने सबग्राफ के लिए प्रश्नों को प्रोसेस करते हैं और क्वेरी शुल्क मूल्य निर्धारण के लिए वरीयताएँ निर्धारित करते हैं।
+
+<Difficulty level="ADVANCED" />
+
+## सामान्य प्रश्न
+
+### नेटवर्क पर इंडेक्सर बनने के लिए आवश्यक न्यूनतम हिस्सेदारी क्या है?
+
+इंडेक्सर के लिए न्यूनतम हिस्सेदारी वर्तमान में 100K GRT पर सेट है।
+
+### एक इंडेक्सर के लिए राजस्व धाराएं क्या हैं?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### इंडेक्सिंग पुरस्कार कैसे वितरित किए जाते हैं?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### इंडेक्सिंग (पीओआई) का सबूत क्या है?
+
+पीओआई का उपयोग नेटवर्क में यह सत्यापित करने के लिए किया जाता है कि एक इंडेक्सर उनके द्वारा आवंटित उपग्राफों को अनुक्रमित कर रहा है। इंडेक्सिंग पुरस्कारों के लिए पात्र होने के लिए उस आवंटन के आवंटन को बंद करते समय वर्तमान युग के पहले ब्लॉक के लिए एक पीओआई जमा किया जाना चाहिए। एक ब्लॉक के लिए एक पीओआई उस ब्लॉक तक और उस सहित एक विशिष्ट सबग्राफ परिनियोजन के लिए सभी एंटिटी स्टोर लेनदेन के लिए डाइजेस्ट है।
+
+### अनुक्रमण पुरस्कार कब वितरित किए जाते हैं?
+
+आवंटन लगातार पुरस्कार अर्जित कर रहे हैं जबकि वे सक्रिय हैं और 28 युगों के भीतर आवंटित किए गए हैं। इंडेक्सर्स द्वारा पुरस्कार एकत्र किए जाते हैं, और जब भी उनका आवंटन बंद हो जाता है, वितरित किया जाता है। यह या तो मैन्युअल रूप से होता है, जब भी इंडेक्सर उन्हें बंद करना चाहता है, या 28 युगों के बाद एक प्रतिनिधि इंडेक्सर के आवंटन को बंद कर सकता है, लेकिन इसका परिणाम कोई पुरस्कार नहीं होता है। 28 युग अधिकतम आवंटन जीवनकाल है (अभी, एक युग ~ 24h तक रहता है)।
+
+### क्या लंबित अनुक्रमण पुरस्कारों की निगरानी की जा सकती है?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+कई समुदाय-निर्मित डैशबोर्ड में लंबित पुरस्कार मान शामिल हैं और इन चरणों का पालन करके उन्हें आसानी से मैन्युअल रूप से चेक किया जा सकता है:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### विवाद क्या हैं और मैं उन्हें कहां देख सकता हूं?
+
+विवाद की अवधि के दौरान इंडेक्सर की पूछताछ और आवंटन दोनों को ग्राफ़ पर विवादित किया जा सकता है। विवाद के प्रकार के आधार पर विवाद की अवधि अलग-अलग होती है। प्रश्न/सत्यापन में 7 युग विवाद विंडो हैं, जबकि आवंटन में 56 युग हैं। इन अवधियों के बीत जाने के बाद, आवंटन या प्रश्नों में से किसी के विरुद्ध विवाद नहीं खोला जा सकता है। जब कोई विवाद खोला जाता है, तो मछुआरों द्वारा न्यूनतम 10,000 जीआरटी की जमा राशि की आवश्यकता होती है, जो विवाद को अंतिम रूप देने और समाधान दिए जाने तक बंद रहेगा। मछुआरे कोई भी नेटवर्क प्रतिभागी हैं जो विवाद खोलते हैं।
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- यदि विवाद को खारिज कर दिया जाता है, तो मछुआरों द्वारा जमा किए गए जीआरटी को जला दिया जाएगा और विवादित इंडेक्सर को नहीं काटा जाएगा।
+- यदि विवाद ड्रा के रूप में सुलझाया जाता है, तो मछुआरों की जमा राशि वापस कर दी जाएगी, और विवादित इंडेक्सर को नहीं काटा जाएगा।
+- यदि विवाद स्वीकार किया जाता है, तो मछुआरों द्वारा जमा किया गया जीआरटी वापस कर दिया जाएगा, विवादित इंडेक्सर को घटा दिया जाएगा और मछुआरे घटे हुए जीआरटी का 50% अर्जित करेंगे।
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### प्रश्न शुल्क छूट क्या हैं और वे कब वितरित की जाती हैं?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+
+### क्वेरी फी कट और इंडेक्सिंग रिवॉर्ड कट क्या है?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### इंडेक्सर्स कैसे जानते हैं कि इंडेक्स करने के लिए कौन से सबग्राफ हैं?
+
+इंडेक्सर्स सबग्राफ इंडेक्सिंग निर्णय लेने के लिए उन्नत तकनीकों को लागू करके खुद को अलग कर सकते हैं लेकिन एक सामान्य विचार देने के लिए हम नेटवर्क में सबग्राफ का मूल्यांकन करने के लिए उपयोग की जाने वाली कई प्रमुख मीट्रिक पर चर्चा करेंगे:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### हार्डवेयर आवश्यकताएँ क्या हैं?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- | :------------------: | :---------------------------: | :-------------------------: | :-------------: | :----------------------: |
+| Small    |           4          |               8               |              1              |        4        |            16            |
+| Standard |           8          |               30              |              1              |        12       |            48            |
+| Medium   |          16          |               64              |              2              |        32       |            64            |
+| Large    |          72          |              468              |             3.5             |        48       |            184           |
+
+### एक इंडेक्सर को कौन सी बुनियादी सुरक्षा सावधानियां बरतनी चाहिए?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## आधारभूत संरचना
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+नोट: फुर्तीली स्केलिंग का समर्थन करने के लिए, यह अनुशंसा की जाती है कि क्वेरी और इंडेक्सिंग चिंताओं को नोड्स के विभिन्न सेटों के बीच अलग किया जाए: क्वेरी नोड्स और इंडेक्स नोड्स।
+
+### Ports overview
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Port | Purpose                                            | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | -------------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(सबग्राफ प्रश्नों के लिए) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(सबग्राफ सब्सक्रिप्शन के लिए)      | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(तैनाती के प्रबंधन के लिए)           | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                       | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                                 | /metrics                                       | \--metrics-port    | -                    |
+
+#### Indexer Service
+
+| Port | Purpose                                            | Routes                                                      | CLI Argument    | Environment Variable   |
+| ---- | -------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(सबग्राफ प्रश्नों के लिए) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                 | /metrics                                                    | \--metrics-port | -                      |
+
+#### Indexer Agent
+
+| Port | Purpose                | Routes | CLI Argument               | Environment Variable                    |
+| ---- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | Indexer management API | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Google क्लाउड पर टेराफॉर्म का उपयोग करके सर्वर इंफ्रास्ट्रक्चर सेटअप करें
+
+> नोट: इंडेक्सर वैकल्पिक रूप से AWS, Microsoft Azure, या अलीबाबा का उपयोग कर सकते हैं।
+
+#### Install prerequisites
+
+- Google Cloud SDK
+- Kubectl command line tool
+- Terraform
+
+#### एक Google क्लाउड प्रोजेक्ट बनाएं
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Google क्लाउड से प्रमाणित करें और एक नया प्रोजेक्ट बनाएं।
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- नए प्रोजेक्ट के लिए बिलिंग सक्षम करने के लिए Google क्लाउड कंसोल के बिलिंग पृष्ठ का उपयोग करें।
+
+- Create a Google Cloud configuration.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- आवश्यक Google क्लाउड एपीआई सक्षम करें।
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- एक सेवा खाता बनाएँ।
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- डेटाबेस और Kubernetes क्लस्टर के बीच पियरिंग सक्षम करें जो अगले चरण में बनाया जाएगा।
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- न्यूनतम टेराफ़ॉर्म कॉन्फ़िगरेशन फ़ाइल बनाएँ (आवश्यकतानुसार अद्यतन करें)।
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### इंफ्रास्ट्रक्चर बनाने के लिए टेराफॉर्म का इस्तेमाल करें
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- इन्फ्रास्ट्रक्चर बनाने के लिए निम्नलिखित कमांड चलाएँ।
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### इंडेक्सर के लिए कुबेरनेट्स घटक बनाना
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### स्रोत से प्रारंभ करना
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. एक PostgreSQL डेटाबेस सर्वर प्रारंभ करें
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. अब जब सभी निर्भरताएँ स्थापित हो गई हैं, तो ग्राफ़ नोड प्रारंभ करें:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### डॉकर का उपयोग शुरू करना
+
+#### आवश्यक शर्तें
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Setup
+
+1. क्लोन ग्राफ़ नोड और डॉकर निर्देशिका पर नेविगेट करें:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. एक स्थानीय ग्राफ़ नोड प्रारंभ करें जो आपके एथेरियम समापन बिंदु से जुड़ जाएगा:
+
+```sh
+docker-compose up
+```
+
+### Indexer components
+
+नेटवर्क में सफलतापूर्वक भाग लेने के लिए लगभग निरंतर निगरानी और सहभागिता की आवश्यकता होती है, इसलिए हमने इंडेक्सर्स नेटवर्क भागीदारी को सुविधाजनक बनाने के लिए टाइपस्क्रिप्ट एप्लिकेशन का एक सूट बनाया है। तीन इंडेक्सर घटक हैं:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### शुरू करना
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### From NPM packages
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### From source
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Using docker
+
+- रजिस्ट्री से चित्र खींचे
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+या स्रोत से स्थानीय रूप से छवियां बनाएं
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- घटकों को चलाएँ
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### K8s और टेराफॉर्म का उपयोग करना
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### प्रयोग
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### इंडेक्सर एजेंट
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer Service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### इंडेक्सर सीएलआई का उपयोग कर इंडेक्सर प्रबंधन
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### प्रयोग
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Indexing rules
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+डेटा मॉडल:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+अनुक्रमण नियम का उदाहरण उपयोग:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- तृतीय पक्ष ऑप्टिमाइज़र टूल या इंडेक्सर-क्ली उपयोगकर्ता द्वारा कतार में जोड़ी गई कार्रवाई
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- अनुक्रमणक क्रिया निष्पादन के इतिहास को देखने के लिए क्रिया कतार की निगरानी कर सकता है और यदि आवश्यक हो तो निष्पादन विफल होने पर क्रिया आइटम को पुन: अनुमोदित और अद्यतन कर सकता है। क्रिया कतार पंक्तिबद्ध और की गई सभी कार्रवाइयों का इतिहास प्रदान करती है।
+
+डेटा मॉडल:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+स्रोत से उदाहरण उपयोग:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+ध्यान दें कि आवंटन प्रबंधन के लिए समर्थित क्रिया प्रकारों की अलग-अलग इनपुट आवश्यकताएं होती हैं:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - आवश्यक क्रिया पैरामीटर:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - आवश्यक क्रिया पैरामीटर:
+    - allocationID
+    - deploymentID
+  - वैकल्पिक क्रिया पैरामीटर:
+    - poi
+    - बल (प्रदान किए गए POI का उपयोग करने पर बल देता है, भले ही वह ग्राफ़-नोड द्वारा प्रदान किए गए मेल से मेल न खाता हो)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - आवश्यक क्रिया पैरामीटर:
+    - allocationID
+    - deploymentID
+    - amount
+  - वैकल्पिक क्रिया पैरामीटर:
+    - poi
+    - बल (प्रदान किए गए POI का उपयोग करने पर बल देता है, भले ही वह ग्राफ़-नोड द्वारा प्रदान किए गए मेल से मेल न खाता हो)
+
+#### Cost models
+
+लागत मॉडल बाजार और क्वेरी विशेषताओं के आधार पर प्रश्नों के लिए गतिशील मूल्य निर्धारण प्रदान करते हैं। अनुक्रमणिका सेवा प्रत्येक सबग्राफ के लिए गेटवे के साथ एक लागत मॉडल साझा करती है जिसके लिए वे प्रश्नों का उत्तर देना चाहते हैं। गेटवे, बदले में, प्रति प्रश्न अनुक्रमणिका चयन निर्णय लेने और चुने गए अनुक्रमणकों के साथ भुगतान पर बातचीत करने के लिए लागत मॉडल का उपयोग करते हैं।
+
+#### Agora
+
+अगोरा भाषा प्रश्नों के लिए लागत मॉडल घोषित करने के लिए एक लचीला प्रारूप प्रदान करती है। एक एगोरा मूल्य मॉडल बयानों का एक क्रम है जो एक ग्राफक्यूएल क्वेरी में प्रत्येक शीर्ष-स्तरीय क्वेरी के क्रम में निष्पादित होता है। प्रत्येक शीर्ष-स्तरीय क्वेरी के लिए, पहला कथन जो उससे मेल खाता है, उस क्वेरी के लिए मूल्य निर्धारित करता है।
+
+एक कथन में एक विधेय शामिल होता है, जिसका उपयोग ग्राफक्यूएल प्रश्नों के मिलान के लिए किया जाता है, और एक लागत अभिव्यक्ति होती है, जिसका मूल्यांकन दशमलव GRT में लागत को आउटपुट करता है। क्वेरी के नामित तर्क स्थिति में मान विधेय में कैप्चर किए जा सकते हैं और अभिव्यक्ति में उपयोग किए जा सकते हैं। एक अभिव्यक्ति में प्लेसहोल्डर्स के लिए ग्लोबल्स भी सेट और प्रतिस्थापित किए जा सकते हैं।
+
+उदाहरण लागत मॉडल:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+उपरोक्त मॉडल का उपयोग करके उदाहरण क्वेरी लागत:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### लागत मॉडल लागू करना
+
+लागत मॉडल इंडेक्सर सीएलआई के माध्यम से लागू किए जाते हैं, जो उन्हें डेटाबेस में स्टोर करने के लिए इंडेक्सर एजेंट के इंडेक्सर मैनेजमेंट एपीआई को भेजता है। इंडेक्सर सर्विस तब उन्हें उठाएगी और जब भी वे उनके लिए मांगेंगे, गेटवे को लागत मॉडल की सेवा देगी।
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## नेटवर्क के साथ बातचीत करना
+
+### प्रोटोकॉल में हिस्सेदारी
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### टोकन स्वीकृत करें
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### स्टेक टोकन
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### आवंटन का जीवन
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 0ba72b8fd9a7138b62d8130fa6db5e0b8bbc29dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:25 -0500
Subject: [PATCH 0935/3820] New translations tap.mdx (Hindi)

---
 website/pages/hi/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/hi/indexing/tap.mdx

diff --git a/website/pages/hi/indexing/tap.mdx b/website/pages/hi/indexing/tap.mdx
new file mode 100644
index 000000000000..cf7aa1d24159
--- /dev/null
+++ b/website/pages/hi/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP माइग्रेशन गाइड
+---
+
+The Graph के नए भुगतान प्रणाली, Timeline Aggregation Protocol, TAP के बारे में जानें। यह प्रणाली तेज, कुशल माइक्रोट्रांजेक्शन प्रदान करती है जिसमें विश्वास को न्यूनतम किया गया है।
+
+## अवलोकन
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) मौजूदा Scalar भुगतान प्रणाली का एक ड्रॉप-इन प्रतिस्थापन है। यह निम्नलिखित प्रमुख सुविधाएँ प्रदान करता है:
+
+- सूक्ष्म भुगतानों को कुशलता से संभालता है।
+- Adds a layer of consolidations to onchain transactions and costs.
+- प्राप्तियों और भुगतान पर Indexers को नियंत्रण की अनुमति देता है, प्रश्नों के लिए भुगतान की गारंटी देता है।
+- यह विकेन्द्रीकृत, विश्वास रहित गेटवे को सक्षम बनाता है और कई भेजने वालों के लिए indexer-service के प्रदर्शन में सुधार करता है।
+
+## विशिष्टताएँ
+
+TAP एक प्रेषक को एक प्राप्तकर्ता को कई भुगतान करने की अनुमति देता है, TAP Receipts, जो इन भुगतानों को एकल भुगतान में एकत्र करता है, जिसे Receipt Aggregate Voucher भी कहा जाता है, जिसे RAV के नाम से भी जाना जाता है। यह एकत्रित भुगतान फिर ब्लॉकचेन पर सत्यापित किया जा सकता है, लेनदेन की संख्या को कम करता है और भुगतान प्रक्रिया को सरल बनाता है।
+
+प्रत्येक क्वेरी के लिए, गेटवे आपको एक साइन किए गए रिसिप्ट भेजेगा जिसे आपके डेटाबेस में संग्रहीत किया जाएगा। फिर, इन क्वेरियों को एक अनुरोध के माध्यम से एक टेप-एजेंट द्वारा समेकित किया जाएगा। इसके बाद, आपको एक RAV प्राप्त होगा। आप नए रिसिप्ट्स के साथ इसे भेजकर RAV को अपडेट कर सकते हैं और इससे एक नया RAV उत्पन्न होगा जिसमें बढ़ी हुई राशि होगी।
+
+### RAV विवरण
+
+- यह वह पैसा है जो ब्लॉकचेन पर भेजे जाने का इंतजार कर रहा है।
+
+- यह जारी रखेगा अनुरोध भेजना ताकि यह सुनिश्चित किया जा सके कि गैर-एकत्रित रसीदों का कुल मूल्य 'amount willing to lose' से अधिक न हो।
+
+- प्रत्येक RAV को अनुबंधों में एक बार भुनाया जा सकता है, यही कारण है कि इन्हें आवंटन बंद होने के बाद भेजा जाता है।
+
+### RAV का उपयोग करना
+
+जब तक आप tap-agent और indexer-agent को चलाते हैं, सब कुछ स्वचालित रूप से निष्पादित होगा। निम्नलिखित प्रक्रिया का विस्तृत विवरण प्रदान करता है:
+
+1. एक Indexer आवंटन बंद करता है।
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` सभी लंबित प्राप्तियों को उस विशेष आवंटन के लिए लेता है और एक RAV में समेकन के लिए अनुरोध करता है, इसे 'last' के रूप में चिह्नित करता है।
+
+3. indexer-agent सभी पिछले RAVS लेता है और ब्लॉकचेन को रिडीम अनुरोध भेजता है, जो redeem_at के मान को अपडेट करेगा।
+
+4. `<finality-time>` अवधि के दौरान, `indexer-agent` यह देखता है कि क्या ब्लॉकचेन में कोई पुनर्गठन है जो लेनदेन को पूर्ववत करता है।
+
+   - यदि इसे रिवर्ट किया गया, तो RAV को फिर से ब्लॉकचेन पर भेजा जाता है। यदि इसे रिवर्ट नहीं किया गया, तो इसे final के रूप में चिह्नित किया जाता है।
+
+## ब्लॉकचेन पते(Addresses)
+
+### contract
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### गेटवे 
+
+| घटक               | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ----------------- | --------------------------------------------- | --------------------------------------------- |
+| प्रेषक            | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| हस्ताक्षरकर्ता    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| संकेन्द्रीयकर्ता  | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+एक Indexer चलाने की सामान्य आवश्यकताओं के अलावा, आपको TAP अपडेट को क्वेरी करने के लिए एक tap-escrow-subgraph एंडपॉइंट की आवश्यकता होगी। आप TAP को क्वेरी करने के लिए The Graph Network का उपयोग कर सकते हैं या अपने graph-node पर स्वयं होस्ट कर सकते हैं।
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## माइग्रेशन गाइड
+
+### सॉफ़्टवेयर संस्करण
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### कदम
+
+1. **Indexer एजेंट**
+
+   - उसी प्रक्रिया का पालन करें'(https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - नया तर्क --tap-subgraph-endpoint दें ताकि नए TAP कोडपाथ्स को सक्रिय किया जा सके और TAP RAVs को रिडीम करने की अनुमति मिल सके।
+
+2. **Indexer सेवा**
+
+   - अपने वर्तमान कॉन्फ़िगरेशन को पूरी तरह से new Indexer Service rs (https://github.com/graphprotocol/indexer-rs). से बदलें। यह सुझाव दिया गया है कि आप container image (https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs). का उपयोग करें।
+   - पुरानी संस्करण की तरह, आप Indexer Service को आसानी से क्षैतिज रूप से स्केल कर सकते हैं। यह अभी भी stateless है।
+
+3. **TAP एजेंट**
+
+   - हमेशा एक ही उदाहरण चलाएँ TAP Agent (https://github.com/graphprotocol/indexer-rs)। यह सिफारिश की जाती है कि आप container image (https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs). का उपयोग करें।
+
+4. इंडेक्सर सेवा और TAP एजेंट कॉन्फ़िगर करें
+
+   कॉन्फ़िगरेशन एक TOML फ़ाइल है जो indexer-service और tap-agent के बीच साझा की जाती है, जो --config /path/to/config.toml तर्क के साथ प्रदान की जाती है।
+
+   पूरा configuration (https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml)और default values (https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml) देखें।
+
+"कम से कम कॉन्फ़िगरेशन के लिए, निम्नलिखित टेम्पलेट का उपयोग करें:"
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+टिप्पणियाँ:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**लॉग स्तर**
+
+- आप लॉग स्तर को RUST_LOG एनवायरनमेंट वेरिएबल का उपयोग करके सेट कर सकते हैं।
+- यह अनुशंसा की जाती है कि आप इसे RUST_LOG=indexer_tap_agent=debug,info पर सेट करें।
+
+## निगरानी
+
+### मेट्रिक्स
+
+सभी घटक पोर्ट 7300 को प्रदर्शित करते हैं जिसे prometheus द्वारा क्वेरी किया जा सकता है।
+
+### Grafana डैशबोर्ड
+
+आप Grafana Dashboard (https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json)  डाउनलोड कर सकते हैं और इम्पोर्ट कर सकते हैं।
+
+### लॉन्चपैड
+
+वर्तमान में, indexer-rs और tap-agent का एक WIP संस्करण है जो यहाँ पाया जा सकता है यहां (https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From 3548691bd1e46083a364694dfaa5e861cc91acf1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:26 -0500
Subject: [PATCH 0936/3820] New translations graph-node.mdx (Hindi)

---
 .../pages/hi/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/hi/indexing/tooling/graph-node.mdx

diff --git a/website/pages/hi/indexing/tooling/graph-node.mdx b/website/pages/hi/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..6a95fb4ce462
--- /dev/null
+++ b/website/pages/hi/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### पोस्टग्रेएसक्यूएल डेटाबेस
+
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
+
+### नेटवर्क क्लाइंट
+
+किसी नेटवर्क को इंडेक्स करने के लिए, ग्राफ़ नोड को एथेरियम-संगत JSON-RPC के माध्यम से नेटवर्क क्लाइंट तक पहुंच की आवश्यकता होती है। यह आरपीसी एक एथेरियम क्लाइंट से जुड़ सकता है या यह एक अधिक जटिल सेटअप हो सकता है जो कई में संतुलन लोड करता है।
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### आईपीएफएस नोड्स
+
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+### प्रोमेथियस मेट्रिक्स सर्वर
+
+To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
+
+### स्रोत से प्रारंभ करना
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. एक PostgreSQL डेटाबेस सर्वर प्रारंभ करें
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. अब जब सभी निर्भरताएँ स्थापित हो गई हैं, तो ग्राफ़ नोड प्रारंभ करें:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Getting started with Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+When it is running Graph Node exposes the following ports:
+
+| Port | Purpose                                            | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | -------------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(सबग्राफ प्रश्नों के लिए) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(सबग्राफ सब्सक्रिप्शन के लिए)      | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(तैनाती के प्रबंधन के लिए)           | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                       | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                                 | /metrics                                       | \--metrics-port    | -                    |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Advanced Graph Node configuration
+
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> कॉन्फ़िगरेशन फ़ाइल का उपयोग करते समय, --postgres-url, --postgres-secondary-hosts, और --postgres-host-weights विकल्पों का उपयोग करना संभव नहीं है।
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Multiple Graph Nodes
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> ध्यान दें कि एक ही डेटाबेस का उपयोग करने के लिए कई ग्राफ़ नोड्स को कॉन्फ़िगर किया जा सकता है, जिसे स्वयं शार्डिंग के माध्यम से क्षैतिज रूप से बढ़ाया जा सकता है।
+
+#### Deployment rules
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Example deployment rule configuration:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Dedicated query nodes
+
+Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Any node whose --node-id matches the regular expression will be set up to only respond to queries.
+
+#### Database scaling via sharding
+
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+शेयरिंग तब उपयोगी हो जाती है जब आपका मौजूदा डेटाबेस ग्राफ़ नोड द्वारा डाले गए भार के साथ नहीं रह सकता है, और जब डेटाबेस का आकार बढ़ाना संभव नहीं होता है।
+
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Dedicated block ingestion
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Supporting multiple networks
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Multiple networks
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Environment variables
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Continuous deployment
+
+जो उपयोगकर्ता उन्नत कॉन्फ़िगरेशन के साथ एक स्केल्ड इंडेक्सिंग सेटअप का संचालन कर रहे हैं, वे कुबेरनेट्स के साथ अपने ग्राफ़ नोड्स को प्रबंधित करने से लाभान्वित हो सकते हैं।
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Managing Graph Node
+
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+
+#### लॉगिंग
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+ग्राफ़ नोड डिफ़ॉल्ट रूप से 8040 पोर्ट पर प्रोमेथियस एंडपॉइंट के माध्यम से मेट्रिक्स प्रदान करता है। इन मेट्रिक्स की कल्पना करने के लिए ग्राफाना का उपयोग किया जा सकता है।
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### सबग्राफ के साथ काम करना
+
+#### अनुक्रमण स्थिति एपीआई
+
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Indexing performance
+
+There are three separate parts of the indexing process:
+
+- Fetching events of interest from the provider
+- उपयुक्त संचालकों के साथ घटनाओं को संसाधित करना (इसमें राज्य के लिए श्रृंखला को कॉल करना और स्टोर से डेटा प्राप्त करना शामिल हो सकता है)
+- Writing the resulting data to the store
+
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+
+Common causes of indexing slowness:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- A large number of events to process
+- Slow database connection time, for crowded nodes
+- The provider itself falling behind the chain head
+- Slowness in fetching new receipts at the chain head from the provider
+
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+
+#### विफल सबग्राफ
+
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+
+- Deterministic failures: these are failures which will not be resolved with retries
+- गैर-नियतात्मक विफलताएँ: ये प्रदाता के साथ समस्याओं या कुछ अप्रत्याशित ग्राफ़ नोड त्रुटि के कारण हो सकती हैं। जब एक गैर-नियतात्मक विफलता होती है, तो ग्राफ़ नोड समय के साथ पीछे हटते हुए विफल हैंडलर को फिर से प्रयास करेगा।
+
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### कैश को ब्लॉक और कॉल करें
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. यदि ब्लॉक प्रदाता से मेल खाता है, तो समस्या को सीधे प्रदाता के विरुद्ध डिबग किया जा सकता है।
+
+#### Querying issues and errors
+
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+
+हालाँकि, एक समर्पित क्वेरी नोड और प्रतिकृतियों के साथ भी, कुछ प्रश्नों को निष्पादित करने में लंबा समय लग सकता है, और कुछ मामलों में मेमोरी उपयोग में वृद्धि होती है और अन्य उपयोगकर्ताओं के लिए क्वेरी समय को नकारात्मक रूप से प्रभावित करती है।
+
+एक "सिल्वर बुलेट" नहीं है, लेकिन धीमे प्रश्नों को रोकने, निदान करने और निपटने के लिए उपकरणों की एक श्रृंखला है।
+
+##### क्वेरी कैशिंग
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analysing queries
+
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
+
+अन्य मामलों में, क्वेरी नोड पर ट्रिगर उच्च मेमोरी उपयोग हो सकता है, इस मामले में सबसे पहले समस्या उत्पन्न करने वाली क्वेरी की पहचान करना चुनौती है।
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
+
+##### Account-like optimisation
+
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### सबग्राफ हटाना
+
+> This is new functionality, which will be available in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 7f95de8ea0e73c44f4287d9c4436c832d3ef03b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:27 -0500
Subject: [PATCH 0937/3820] New translations advanced.mdx (Hindi)

---
 .../developing/creating/advanced.mdx          | 556 ++++++++++++++++++
 1 file changed, 556 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/hi/subgraphs/developing/creating/advanced.mdx b/website/pages/hi/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..f6e33f4d3b44
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,556 @@
+---
+title: Advanced Subgraph Features
+---
+
+## अवलोकन
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries और Aggregations
+
+Timeseries और aggregations आपके subgraph को दैनिक औसत मूल्य, घंटेवारी कुल स्थानांतरण आदि जैसे आंकड़े ट्रैक करने में सक्षम बनाते हैं।
+
+यह विशेषता दो नए प्रकार की 'subgraph' इकाई पेश करती है। 'Timeseries' इकाइयाँ डेटा बिंदुओं को समय की छाप के साथ रिकॉर्ड करती हैं। 'Aggregation' इकाइयाँ 'Timeseries' डेटा बिंदुओं पर पूर्व-घोषित गणनाएँ करती हैं, जो प्रति घंटे या प्रति दिन होती हैं, फिर परिणामों को GraphQL के माध्यम से आसान पहुँच के लिए संग्रहीत करती हैं।
+
+### उदाहरण स्कीमा
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### टाइमसीरीज और एग्रीगेशन्स को परिभाषित करना
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### उपलब्ध Aggregation अंतराल
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### उपलब्ध Aggregation फ़ंक्शन
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### उदाहरण Aggregations queries
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+नोट:
+
+Timeseries और Aggregations का उपयोग करने के लिए, एक subgraph का spec version ≥1.1.0 होना चाहिए। ध्यान दें कि यह सुविधा महत्वपूर्ण परिवर्तनों का सामना कर सकती है जो पीछे की संगतता को प्रभावित कर सकती है।
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## गैर-घातक त्रुटियाँ
+
+पहले से सिंक किए गए सबग्राफ पर इंडेक्सिंग त्रुटियां, डिफ़ॉल्ट रूप से, सबग्राफ को विफल कर देंगी और सिंक करना बंद कर देंगी। सबग्राफ को वैकल्पिक रूप से त्रुटियों की उपस्थिति में समन्वयन जारी रखने के लिए कॉन्फ़िगर किया जा सकता है, हैंडलर द्वारा किए गए परिवर्तनों को अनदेखा करके त्रुटि उत्पन्न हुई। यह सबग्राफ लेखकों को अपने सबग्राफ को ठीक करने का समय देता है, जबकि नवीनतम ब्लॉक के विरुद्ध प्रश्नों को जारी रखा जाता है, हालांकि त्रुटि के कारण बग के कारण परिणाम असंगत हो सकते हैं। ध्यान दें कि कुछ त्रुटियाँ अभी भी हमेशा घातक होती हैं। गैर-घातक होने के लिए, त्रुटि नियतात्मक होने के लिए जानी जानी चाहिए।
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+गैर-घातक त्रुटियों को सक्षम करने के लिए सबग्राफ मेनिफ़ेस्ट पर निम्न फ़ीचर फ़्लैग सेट करने की आवश्यकता होती है:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave फ़ाइल डेटा स्रोत
+
+फाइल डेटा स्रोत एक नई subgraph कार्यक्षमता है जो indexing के दौरान ऑफ-चेन डेटा तक एक मजबूत, विस्तारित तरीके से पहुँच प्रदान करती है। फाइल डेटा स्रोत IPFS और Arweave से फ़ाइलें फ़ेच करने का समर्थन करते हैं।
+
+> यह ऑफ-चेन डेटा के नियतात्मक अनुक्रमण के साथ-साथ स्वैच्छिक HTTP-स्रोत डेटा के संभावित परिचय के लिए आधार भी देता है।
+
+### अवलोकन
+
+"लाइन" में हैंडलर कार्यान्वयन के दौरान फ़ाइलों को लाने के बजाय, यह टेम्पलेट्स को पेश करता है जिन्हें एक दिए गए फ़ाइल पहचानकर्ता के लिए नए डेटा स्रोतों के रूप में उत्पन्न किया जा सकता है। ये नए डेटा स्रोत फ़ाइलों को लाते हैं, यदि वे असफल होते हैं तो पुनः प्रयास करते हैं, और जब फ़ाइल मिलती है तो एक समर्पित हैंडलर चलाते हैं।
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### अपग्रेड गाइड
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### एक नया इकाई प्रकार जोड़ें जो फ़ाइलें मिलने पर अपडेट किया जाएगा
+
+फ़ाइल डेटा स्रोत श्रृंखला-आधारित संस्थाओं तक पहुँच या अद्यतन नहीं कर सकते हैं, लेकिन फ़ाइल विशिष्ट संस्थाओं को अद्यतन करना चाहिए।
+
+इसका मतलब हो सकता है कि फ़ील्ड को मौजूदा इकाइयों से अलग-अलग इकाइयों में विभाजित करना, एक साथ जुड़े हुए।
+
+मूल संयुक्त इकाई:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+नई, विभाजित इकाई:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+यदि पैरेंट इकाई और परिणामी फ़ाइल डेटा स्रोत इकाई के बीच संबंध 1:1 है, तो सबसे सरल पैटर्न मूल इकाई को लुकअप के रूप में IPFS CID का उपयोग करके परिणामी फ़ाइल इकाई से लिंक करना है। यदि आपको अपनी नई फ़ाइल-आधारित संस्थाओं को मॉडलिंग करने में कठिनाई हो रही है, तो डिस्कॉर्ड पर संपर्क करें!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+यह वह डेटा स्रोत है जो ब्याज की फ़ाइल की पहचान होने पर उत्पन्न होगा।
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### फ़ाइलों को संसाधित करने के लिए एक नया हैंडलर बनाएँ
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+उदाहरण हैंडलर:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### आवश्यक होने पर फ़ाइल डेटा स्रोत स्पॉन करें
+
+अब आप चेन-आधारित हैंडलर के निष्पादन के दौरान फ़ाइल डेटा स्रोत बना सकते हैं:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+उदाहरण:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+यह एक नया file data source बनाएगा, जो Graph Node के configured किए गए IPFS या Arweave endpoint का सर्वेक्षण करेगा, यदि यह नहीं मिलता है तो पुनः प्रयास करेगा। जब file मिल जाती है, तो file data source handler execute किया जाएगा।
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+बधाई हो, आप फ़ाइल डेटा स्रोतों का उपयोग कर रहे हैं!
+
+#### अपने उप-अनुच्छेदों को तैनात करना
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### परिसीमन
+
+फ़ाइल डेटा स्रोत हैंडलर और संस्थाएँ अन्य सबग्राफ संस्थाओं से अलग हैं, यह सुनिश्चित करते हुए कि वे निष्पादित होने पर नियतात्मक हैं, और श्रृंखला-आधारित डेटा स्रोतों का कोई संदूषण सुनिश्चित नहीं करते हैं। विस्तार से:
+
+- फ़ाइल डेटा स्रोतों द्वारा बनाई गई इकाइयाँ अपरिवर्तनीय हैं, और इन्हें अद्यतन नहीं किया जा सकता है
+- फ़ाइल डेटा स्रोत हैंडलर अन्य फ़ाइल डेटा स्रोतों से संस्थाओं तक नहीं पहुँच सकते
+- फ़ाइल डेटा स्रोतों से जुड़ी संस्थाओं को चेन-आधारित हैंडलर द्वारा एक्सेस नहीं किया जा सकता है
+
+> हालांकि यह बाधा अधिकांश उपयोग-मामलों के लिए समस्याग्रस्त नहीं होनी चाहिए, यह कुछ के लिए जटिलता का परिचय दे सकती है। यदि आपको अपने फ़ाइल-आधारित डेटा को सबग्राफ में मॉडलिंग करने में समस्या आ रही है, तो कृपया डिस्कॉर्ड के माध्यम से संपर्क करें!
+
+इसके अतिरिक्त, फ़ाइल डेटा स्रोत से डेटा स्रोत बनाना संभव नहीं है, चाहे वह ऑनचेन डेटा स्रोत हो या अन्य फ़ाइल डेटा स्रोत। भविष्य में यह प्रतिबंध हटाया जा सकता है।
+
+#### सर्वोत्तम प्रथाएं
+
+यदि आप NFT मेटाडेटा को संबंधित टोकन से लिंक कर रहे हैं, तो टोकन इकाई से मेटाडेटा इकाई को संदर्भित करने के लिए मेटाडेटा के IPFS हैश का उपयोग करें। एक आईडी के रूप में IPFS हैश का उपयोग करके मेटाडेटा इकाई को सहेजें।
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> हम ऊपर दिए गए सुझाव को बेहतर बनाने के लिए काम कर रहे हैं, इसलिए क्वेरी केवल "नवीनतम" संस्करण लौटाती हैं
+
+#### ज्ञात समस्याएँ
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### उदाहरण
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### संदर्भ
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## सूचीकृत तर्क फ़िल्टर / विषय फ़िल्टर
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+विषय फ़िल्टर, जिन्हें इंडेक्स किए गए तर्क फ़िल्टर भी कहा जाता है, एक शक्तिशाली विशेषता है जो उपयोगकर्ताओं को उनके इंडेक्स किए गए तर्कों के मानों के आधार पर ब्लॉकचेन घटनाओं को सटीक रूप से फ़िल्टर करने की अनुमति देती है।
+
+- ये फ़िल्टर ब्लॉकचेन पर घटनाओं की विशाल धारा से रुचि की विशिष्ट घटनाओं को अलग करने में मदद करते हैं, जिससे सबग्राफ़ केवल प्रासंगिक डेटा पर ध्यान केंद्रित करके अधिक कुशलता से कार्य कर सके।
+
+- यह व्यक्तिगत subgraphs बनाने के लिए उपयोगी है जो विशेष पते और विभिन्न स्मार्ट कॉन्ट्रैक्ट्स के साथ उनके इंटरैक्शन को ट्रैक करते हैं ब्लॉकचेन पर।
+
+### शीर्षक फ़िल्टर कैसे काम करते हैं
+
+जब एक स्मार्ट कॉन्ट्रैक्ट एक इवेंट को उत्पन्न करता है, तो कोई भी तर्क जो 'indexed' के रूप में चिह्नित किया गया है, एक 'subgraph' की मैनिफेस्ट में फ़िल्टर के रूप में उपयोग किया जा सकता है। यह 'subgraph' को इन 'indexed' तर्कों से मेल खाने वाले इवेंट्स के लिए चयनात्मक रूप से सुनने की अनुमति देता है।
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // ईवेंट की घोषणा जिसमें पते के लिए इंडेक्स्ड पैरामीटर हैं
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // टोकन ट्रांसफर करने की क्रिया को सिमुलेट करने के लिए फ़ंक्शन
+    function transfer(address to, uint256 value) public {
+        // from, to, और value के साथ Transfer ईवेंट को उत्सर्जित करना
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+इस उदाहरण में:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### सबस्पष्ट में कॉन्फ़िगरेशन
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+इस सेटअप में:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- प्रत्येक विषय में एक या अधिक मान हो सकते हैं, और एक घटना केवल तभी प्रोसेस की जाती है जब वह प्रत्येक निर्दिष्ट विषय में से किसी एक मान से मेल खाती है।
+
+#### फ़िल्टर लॉजिक
+
+- एकल विषय के भीतर: लॉजिक एक OR स्थिति के रूप में कार्य करता है। यदि यह किसी दिए गए विषय में सूचीबद्ध मूल्यों में से किसी एक के साथ मेल खाता है, तो इवेंट को प्रोसेस किया जाएगा।
+- विभिन्न विषयों के बीच: लॉजिक एक AND स्थिति के रूप में कार्य करता है। एक घटना को संबंधित हैंडलर को ट्रिगर करने के लिए विभिन्न विषयों में सभी निर्दिष्ट शर्तों को संतोषजनक रूप से पूरा करना चाहिए।
+
+#### उदाहरण 1: 'पता A' से 'पता B' के लिए प्रत्यक्ष स्थानांतरण का ट्रैकिंग
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+इस कॉन्फ़िगरेशन में:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### उदाहरण 2: दो या अधिक 'पते' के बीच किसी भी दिशा में लेन-देन को ट्रैक करना
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # प्रेषक पता
+    topic2: ['0xAddressB', '0xAddressC'] # प्राप्तकर्ता पता
+```
+
+इस कॉन्फ़िगरेशन में:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- Subgraph उन कई पतों के बीच होने वाले लेनदेन को दोनों दिशाओं में सूचीबद्ध करेगा, जिससे सभी पतों के बीच इंटरैक्शन की व्यापक निगरानी संभव हो सकेगी।
+
+## घोषित eth_call
+
+> नोट: यह एक प्रयोगात्मक फीचर है जो अभी तक स्थिर Graph Node रिलीज़ में उपलब्ध नहीं है। आप इसे केवल Subgraph Studio या अपने स्वयं-होस्टेड नोड में ही उपयोग कर सकते हैं।
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+यह फ़ीचर निम्नलिखित कार्य करता है:
+
+- इथेरियम ब्लॉकचेन से डेटा प्राप्त करने के प्रदर्शन में महत्वपूर्ण सुधार करता है, जिससे कई कॉल के लिए कुल समय कम होता है और सबग्राफ की समग्र दक्षता का अनुकूलन होता है।
+- यह तेजी से डेटा फ़ेचिंग की अनुमति देता है, जिससे तेजी से क्वेरी प्रतिक्रियाएँ और बेहतर उपयोगकर्ता अनुभव मिलता है।
+- कई Ethereum कॉल्स से डेटा को एकत्रित करने की आवश्यकता वाली अनुप्रयोगों के लिए प्रतीक्षा समय को कम करता है, जिससे डेटा पुनर्प्राप्ति प्रक्रिया अधिक प्रभावी हो जाती है।
+
+### मुख्य अवधारणाएँ
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- समानांतर निष्पादन: एक कॉल समाप्त होने की प्रतीक्षा करने के बजाय, कई कॉल एक साथ आरंभ किए जा सकते हैं।
+- समय दक्षता: सभी कॉल के लिए कुल समय व्यक्तिगत कॉल के समय के योग (अनुक्रमिक) से बदलकर सबसे लंबे कॉल के द्वारा लिए गए समय (समानांतर) में बदल जाता है।
+
+#### Scenario without Declarative `eth_calls`
+
+आपके पास एक subgraph है जिसे एक उपयोगकर्ता के लेनदेन, बैलेंस और टोकन होल्डिंग्स के बारे में डेटा प्राप्त करने के लिए तीन Ethereum कॉल करने की आवश्यकता है।
+
+परंपरागत रूप से, ये कॉल क्रमिक रूप से की जा सकती हैं:
+
+1. कॉल 1 (लेनदेन): 3 सेकंड लेता है
+2. कॉल 2 (शेष): 2 सेकंड लेता है
+3. कॉल 3 (टोकन होल्डिंग्स): लेता है 4 सेकंड
+
+कुल समय लिया गया = 3 + 2 + 4 = 9 सेकंड
+
+#### Scenario with Declarative `eth_calls`
+
+इस फीचर के साथ, आप इन कॉल्स को समानांतर में निष्पादित करने के लिए घोषित कर सकते हैं:
+
+1. कॉल 1 (लेनदेन): 3 सेकंड लेता है
+2. कॉल 2 (शेष): 2 सेकंड लेता है
+3. कॉल 3 (टोकन होल्डिंग्स): लेता है 4 सेकंड
+
+चूंकि ये कॉल समानांतर में निष्पादित होते हैं, कुल समय लिया गया सबसे लंबे कॉल के समय के बराबर होता है।
+
+कुल समय = max (3, 2, 4) = 4 सेकंड
+
+#### कैसे कार्य करता है
+
+1. In the subgraph manifest, आप Ethereum कॉल्स को इस तरह घोषित करते हैं कि ये समानांतर में निष्पादित किए जा सकें।
+2. पैरलेल निष्पादन इंजन: The Graph Node का निष्पादन इंजन इन घोषणाओं को पहचानता है और कॉल को समानांतर में चलाता है।
+3. परिणाम संग्रहण: जब सभी कॉल समाप्त हो जाते हैं, तो परिणामों को एकत्रित किया जाता है और आगे की प्रक्रिया के लिए उपयोग किया जाता है।
+
+#### उदाहरण कॉन्फ़िगरेशन Subgraph मैनिफेस्ट में
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+उदाहरण उपरोक्त के लिए विवरण:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+
+```
+
+### मौजूदा सबग्राफ पर ग्राफ्टिंग
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+क्योंकि आधार डेटा को अनुक्रमित करने के बजाय प्रतियों को ग्राफ्ट करना, स्क्रैच से अनुक्रमणित करने की तुलना में सबग्राफ को वांछित ब्लॉक में प्राप्त करना बहुत तेज है, हालांकि बहुत बड़े सबग्राफ के लिए प्रारंभिक डेटा कॉपी में अभी भी कई घंटे लग सकते हैं। जबकि ग्राफ्टेड सबग्राफ को इनिशियलाइज़ किया जा रहा है, ग्राफ़ नोड उन एंटिटी प्रकारों के बारे में जानकारी लॉग करेगा जो पहले ही कॉपी किए जा चुके हैं।
+
+ग्राफ्टेड सबग्राफ एक ग्राफक्यूएल स्कीमा का उपयोग कर सकता है जो बेस सबग्राफ के समान नहीं है, लेकिन इसके अनुकूल हो। यह अपने आप में एक मान्य सबग्राफ स्कीमा होना चाहिए, लेकिन निम्नलिखित तरीकों से बेस सबग्राफ के स्कीमा से विचलित हो सकता है:
+
+- यह इकाई के प्रकारों को जोड़ या हटा सकता है|
+- यह इकाई प्रकारों में से गुणों को हटाता है|
+- यह प्रभावहीन गुणों को इकाई प्रकारों में जोड़ता है|
+- यह प्रभाव वाले गुणों को प्रभावहीन गुणों में बदल देता है|
+- यह इनम्स में महत्व देता है|
+- यह इंटरफेस जोड़ता या हटाता है|
+- यह कि, किन इकाई प्रकारों के लिए इंटरफ़ेस लागू होगा, इसे बदल देता है|
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From db19b992afb04fa2347aae5b35a453c5c73cf627 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:28 -0500
Subject: [PATCH 0938/3820] New translations api.mdx (Hindi)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/hi/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/hi/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..3c388a628d5b
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+यह पृष्ठ दस्तावेज करता है कि Subgraph मैपिंग लिखते समय किन अंतर्निहित एपीआई का उपयोग किया जा सकता है। बॉक्स से बाहर दो प्रकार के एपीआई उपलब्ध हैं:
+
+- The Graph TypeScript लाइब्रेरी (https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (graph-ts)
+- `graph codegen` द्वारा subgraph files से उत्पन्न code
+
+आप अन्य पुस्तकालयों को भी निर्भरताओं के रूप में जोड़ सकते हैं, बशर्ते कि वे [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) के साथ संगत हों।
+
+चूंकि भाषा मैपिंग्स AssemblyScript में लिखी गई हैं, इसलिए [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki) से भाषा और मानक पुस्तकालय की सुविधाओं की समीक्षा करना उपयोगी है।
+
+## API Reference
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- एथेरियम, JSON, ग्राफक्यूएल और असेंबलीस्क्रिप्ट जैसे विभिन्न प्रकार की प्रणालियों के बीच अनुवाद करने के लिए निम्न-स्तरीय आदिम।
+
+### Versions
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| Version | Release notes                                                                                                                                                                                                                                            |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### Built-in Types
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### स्टोर एपीआई
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### संस्थाओं का निर्माण
+
+एथेरियम घटनाओं से संस्थाओं को बनाने के लिए निम्नलिखित एक सामान्य पैटर्न है।
+
+```typescript
+/ Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+प्रत्येक इकाई के पास एक अद्वितीय ID होनी चाहिए ताकि अन्य इकाइयों के साथ टकराव से बचा जा सके। यह काफी सामान्य है कि इवेंट पैरामीटर में एक अद्वितीय पहचानकर्ता शामिल होता है जिसका उपयोग किया जा सकता है।
+
+> नोट: लेन-देन हैश को आईडी के रूप में उपयोग करने का मतलब यह है कि उसी लेन-देन में कोई अन्य घटनाएँ इस हैश को आईडी के रूप में Entities नहीं बनाती हैं।
+
+#### Loading entities from the store
+
+यदि कोई इकाई पहले से मौजूद है, तो इसे स्टोर से निम्न के साथ लोड किया जा सकता है:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+चूंकि एंटिटी स्टोर में अभी मौजूद नहीं हो सकती है, इसलिए `load` विधि `Transfer | null` प्रकार का मान लौटाती है। मान का उपयोग करने से पहले `null` मामले की जांच करना आवश्यक हो सकता है।
+
+> ध्यान दें: एंटिटी लोड करना तभी आवश्यक है जब मैपिंग में किए गए परिवर्तन किसी एंटिटी के पिछले डेटा पर निर्भर हों। मौजूदा एंटिटी को अपडेट करने के दो तरीकों के लिए अगला सेक्शन देखें।
+
+#### एक ब्लॉक के साथ बनाई गई संस्थाओं को देखना
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- यदि लेन-देन मौजूद नहीं है, तो subgraph को केवल यह पता लगाने के लिए डेटाबेस में जाना होगा कि Entity मौजूद नहीं है। यदि subgraph लेखक पहले से जानता है कि Entity उसी ब्लॉक में बनाई जानी चाहिए थी, तो `loadInBlock` का उपयोग इस डेटाबेस राउंडट्रिप से बचाता है।
+- कुछ subgraphs के लिए, ये छूटे हुए लुकअप्स indexing समय में महत्वपूर्ण योगदान दे सकते हैं।
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### Updating existing entities
+
+किसी मौजूदा निकाय को अद्यतन करने के दो तरीके हैं:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+ज्यादातर मामलों में गुण बदलना सीधे आगे है, उत्पन्न संपत्ति सेटर्स के लिए धन्यवाद:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+It is also possible to unset properties with one of the following two instructions:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### स्टोर से संस्थाओं को हटाना
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### एथेरियम एपीआई
+
+एथेरियम एपीआई स्मार्ट कॉन्ट्रैक्ट्स, पब्लिक स्टेट वेरिएबल्स, कॉन्ट्रैक्ट फ़ंक्शंस, इवेंट्स, ट्रांजेक्शन, ब्लॉक्स और एन्कोडिंग / डिकोडिंग एथेरियम डेटा तक पहुंच प्रदान करता है।
+
+#### एथेरियम प्रकार के लिए समर्थन
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+The following example illustrates this. Given a subgraph schema like
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### घटनाक्रम और ब्लॉक/लेनदेन डेटा
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Access to Smart Contract State
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+एक सामान्य पैटर्न उस अनुबंध का उपयोग करना है जिससे कोई घटना उत्पन्न होती है। यह निम्नलिखित कोड के साथ हासिल किया गया है:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+कोई अन्य अनुबंध जो सबग्राफ का हिस्सा है, उत्पन्न कोड से आयात किया जा सकता है और एक वैध पते के लिए बाध्य किया जा सकता है।
+
+#### रिवर्टेड कॉल्स को हैंडल करना
+
+यदि आपके अनुबंध के केवल-पढ़ने वाले तरीके वापस हो सकते हैं, तो आपको इसे `try_` से पूर्व निर्धारित अनुबंध विधि को कॉल करके संभालना चाहिए।
+
+- उदाहरण के लिए, Gravity कॉन्ट्रैक्ट `gravatarToOwner` मेथड को उजागर करता है। यह कोड उस मेथड में एक रिवर्ट को संभालने में सक्षम होगा:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> नोट: एक Graph नोड जो Geth या Infura क्लाइंट से जुड़ा है, सभी रिवर्ट का पता नहीं लगा सकता है। यदि आप इस पर निर्भर करते हैं, तो हम Parity क्लाइंट से जुड़े Graph नोड का उपयोग करने की सिफारिश करते हैं।
+
+#### एन्कोडिंग/डिकोडिंग एबीआई
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+अधिक जानकारी के लिए:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- ज्यादा जटिल उदाहरण (https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### लॉगिंग एपीआई
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info ('संदेश प्रदर्शित किया जाना है: {}, {}, {}', [value.toString (), OtherValue.toString (), 'पहले से ही एक स्ट्रिंग'])
+```
+
+#### एक या अधिक मान लॉग करना
+
+##### एकल मान लॉग करना
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### किसी मौजूदा सरणी से एकल प्रविष्टि लॉग करना
+
+नीचे दिए गए उदाहरण में, तीन मानों वाले सरणी के बावजूद, तर्क सरणी का केवल पहला मान लॉग किया गया है।
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### मौजूदा सरणी से एकाधिक प्रविष्टियां लॉग करना
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### मौजूदा सरणी से एक विशिष्ट प्रविष्टि लॉग करना
+
+सरणी में एक विशिष्ट मान प्रदर्शित करने के लिए, अनुक्रमित मान प्रदान किया जाना चाहिए।
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### लॉगिंग घटना की जानकारी
+
+नीचे दिया गया उदाहरण एक घटना से ब्लॉक संख्या, ब्लॉक हैश और लेनदेन हैश को लॉग करता है:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### आईपीएफएस एपीआई
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+IPFS हैश या पथ को देखते हुए, IPFS से फ़ाइल पढ़ना निम्नानुसार किया जाता है:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### क्रिप्टो एपीआई
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### प्रकार रूपांतरण संदर्भ
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() या s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() या s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### Data Source Metadata
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### इकाई और डेटासोर्स कॉन्टेक्स्ट
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From 4251d0e29f3d1f74d100658c6a50c50bd72f60a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:29 -0500
Subject: [PATCH 0939/3820] New translations common-issues.mdx (Hindi)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/hi/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/hi/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..155469a5960b
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: आम AssemblyScript मुद्दे
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 6189f72af8935ca6207842caa4e91705955add67 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:31 -0500
Subject: [PATCH 0940/3820] New translations unit-testing-framework.mdx (Hindi)

---
 .../creating/unit-testing-framework.mdx       | 1404 +++++++++++++++++
 1 file changed, 1404 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..843caff9680f
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1404 @@
+---
+title: |-
+  Unit परीक्षण फ्रेमवर्क प्राप्त करना
+  कला
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## शुरू करना
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+कृपया ध्यान दें, आर्बिट्रम माइग्रेशन पूरा होने पर इसमें सुधार होगा, जिससे नेटवर्क पर भाग लेने के लिए गैस की लागत काफी कम हो जाएगी।...
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+या
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### सीएलआई विकल्प
+
+यह परीक्षण फ़ोल्डर में सभी परीक्षण चलाएगा:
+
+```sh
+graph test
+```
+
+यह gravity.test.ts नाम का एक परीक्षण चलाएगा और/या गुरुत्वाकर्षण नामक फ़ोल्डर के अंदर सभी परीक्षण चलाएगा:
+
+```sh
+graph test gravity
+```
+
+This will run only that specific test file:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### विन्यास
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### डेमो सबग्राफ
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### वीडियो शिक्षण
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+उदाहरण:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+उदाहरण:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+या
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+उदाहरण:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+उदाहरण:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+उदाहरण:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## इस बात पर ज़ोर
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## यूनिट टेस्ट लिखें
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+मान लें कि हमारे पास निम्नलिखित हैंडलर फ़ंक्शन हैं (हमारे जीवन को आसान बनाने के लिए दो सहायक कार्यों के साथ):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+हमें पहले अपने प्रोजेक्ट में एक टेस्ट फाइल बनानी होगी। यह कैसा दिख सकता है इसका एक उदाहरण है:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- हम अपनी प्रारंभिक स्थिति सेट कर रहे हैं और एक कस्टम Gravatar इकाई जोड़ रहे हैं;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- हम स्टोर की स्थिति पर जोर देते हैं। वह कैसे काम करता है? - हम इकाई प्रकार और आईडी का एक अनूठा संयोजन पारित कर रहे हैं। फिर हम उस इकाई पर एक विशिष्ट क्षेत्र की जाँच करते हैं और दावा करते हैं कि इसका वह मूल्य है जिसकी हम अपेक्षा करते हैं। हम यह दोनों प्रारंभिक Gravatar एंटिटी के लिए कर रहे हैं जिसे हमने स्टोर में जोड़ा है, साथ ही दो Gravatar एंटिटी जो हैंडलर फ़ंक्शन को कॉल करने पर जुड़ जाती हैं;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+ये रहा - हमने अपना पहला परीक्षण बना लिया है! 👏
+
+अब हमारे परीक्षण चलाने के लिए आपको बस अपने सबग्राफ रूट फ़ोल्डर में निम्नलिखित को चलाने की आवश्यकता है:
+
+`graph test Gravity`
+
+और अगर सब ठीक हो जाता है तो आपको निम्नलिखित के साथ बधाई दी जानी चाहिए:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## सामान्य परीक्षण परिदृश्य
+
+### एक निश्चित अवस्था के साथ स्टोर को हाइड्रेट करना
+
+उपयोगकर्ता संस्थाओं के ज्ञात सेट के साथ स्टोर को हाइड्रेट करने में सक्षम हैं। यहाँ एक Gravatar इकाई के साथ स्टोर को इनिशियलाइज़ करने का एक उदाहरण दिया गया है:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### किसी ईवेंट के साथ मैपिंग फ़ंक्शन को कॉल करना
+
+एक उपयोगकर्ता एक कस्टम ईवेंट बना सकता है और इसे मैपिंग फ़ंक्शन में पास कर सकता है जो स्टोर से जुड़ा हुआ है:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### इवेंट फिक्स्चर के साथ सभी मैपिंग को कॉल करना
+
+उपयोगकर्ता मैपिंग को टेस्ट फिक्स्चर के साथ कॉल कर सकते हैं।
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### नकली अनुबंध कॉल
+
+उपयोगकर्ता अनुबंध कॉल का नक़ल सकते हैं:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+जैसा कि प्रदर्शित किया गया है, एक अनुबंध कॉल और कट्टर वापसी मूल्य का मजाक उड़ाने के लिए, उपयोगकर्ता को एक अनुबंध का पता, फ़ंक्शन का नाम, फ़ंक्शन हस्ताक्षर, तर्कों की एक सरणी और निश्चित रूप से - वापसी मूल्य प्रदान करना होगा।
+
+उपयोगकर्ता फ़ंक्शन रिवर्ट्स का नक़ल सकते हैं:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### आईपीएफएस फाइलों का मज़ाक उड़ाना (मैचस्टिक 0.4.1 से)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Asserting the state of the store
+
+उपयोगकर्ता संस्थाओं पर जोर देकर स्टोर की अंतिम (या मिडवे) स्थिति का दावा करने में सक्षम हैं। ऐसा करने के लिए, उपयोगकर्ता को एक इकाई प्रकार, एक इकाई की विशिष्ट आईडी, उस इकाई पर एक फ़ील्ड का नाम और फ़ील्ड के अपेक्षित मूल्य की आपूर्ति करनी होगी। यहाँ एक त्वरित उदाहरण है:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### इवेंट मेटाडेटा के साथ इंटरैक्ट करना
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### चर समानता पर जोर देना
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+उपयोगकर्ता यह दावा कर सकते हैं कि स्टोर में कोई इकाई मौजूद नहीं है। फ़ंक्शन एक इकाई प्रकार और एक आईडी लेता है। यदि इकाई वास्तव में स्टोर में है, तो प्रासंगिक त्रुटि संदेश के साथ परीक्षण विफल हो जाएगा। इस कार्यक्षमता का उपयोग कैसे करें इसका एक त्वरित उदाहरण यहां दिया गया है:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+आप इस सहायक फ़ंक्शन का उपयोग करके पूरे स्टोर को कंसोल पर प्रिंट कर सकते हैं:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### अपेक्षित असफलता
+
+परीक्षण () फ़ंक्शंस पर shouldFail फ़्लैग का उपयोग करके, उपयोगकर्ताओं की अपेक्षित परीक्षण विफलताएँ हो सकती हैं:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+यदि परीक्षण shouldFail = true के साथ चिह्नित किया गया है, लेकिन विफल नहीं होता है, तो यह लॉग में एक त्रुटि के रूप में दिखाई देगा और परीक्षण ब्लॉक विफल हो जाएगा। साथ ही, यदि इसे shouldFail = false (डिफ़ॉल्ट स्थिति) के साथ चिह्नित किया गया है, तो परीक्षण निष्पादक क्रैश हो जाएगा।
+
+### लॉगिंग
+
+यूनिट परीक्षणों में कस्टम लॉग रखना मैपिंग में लॉगिंग के समान ही है। अंतर यह है कि लॉग ऑब्जेक्ट को ग्राफ़-टीएस के बजाय माचिस की तीली से आयात करने की आवश्यकता होती है। यहाँ सभी गैर-महत्वपूर्ण लॉग प्रकारों के साथ एक सरल उदाहरण दिया गया है:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+उपयोगकर्ता एक गंभीर विफलता का अनुकरण भी कर सकते हैं, जैसे:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+महत्वपूर्ण त्रुटियों को लॉग करने से परीक्षणों का निष्पादन बंद हो जाएगा और सब कुछ उड़ जाएगा। आखिरकार - हम यह सुनिश्चित करना चाहते हैं कि आपके कोड में परिनियोजन में महत्वपूर्ण लॉग नहीं हैं, और यदि ऐसा होता है तो आपको तुरंत ध्यान देना चाहिए।
+
+### व्युत्पन्न क्षेत्रों का परीक्षण
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### गतिशील डेटा स्रोतों का परीक्षण
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+उदाहरण नीचे:
+
+सबसे पहले हमारे पास निम्नलिखित ईवेंट हैंडलर है (जिसे जानबूझकर डेटासोर्स मॉकिंग दिखाने के लिए पुनर्निर्मित किया गया है):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+और फिर हमारे पास सभी डेटा स्रोत कार्यों के लिए एक नया रिटर्न वैल्यू सेट करने के लिए डेटासोर्समॉक नेमस्पेस में विधियों में से एक का उपयोग करके परीक्षण है:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+ध्यान दें कि dataSourceMock.resetValues() को अंत में कॉल किया जाता है। ऐसा इसलिए है क्योंकि मूल्यों को याद किया जाता है जब वे बदले जाते हैं और यदि आप डिफ़ॉल्ट मानों पर वापस जाना चाहते हैं तो उन्हें रीसेट करने की आवश्यकता होती है।
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## टेस्ट कवरेज
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### आवश्यक शर्तें
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### अपने हैंडलर निर्यात करें
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### प्रयोग
+
+एक बार यह सब सेट हो जाने के बाद, परीक्षण कवरेज टूल चलाने के लिए, बस चलाएँ:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### लॉग आउटपुट में टेस्ट रन टाइम अवधि
+
+लॉग आउटपुट में टेस्ट रन अवधि शामिल है। यहाँ एक उदाहरण है:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## सामान्य संकलक त्रुटियाँ
+
+> गंभीर: संदर्भ के साथ मान्य मॉड्यूल से WasmInstance नहीं बना सका: अज्ञात आयात: wasi_snapshot_preview1::fd_write परिभाषित नहीं किया गया है
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> त्रुटि TS2554: अपेक्षित? तर्क, लेकिन मिला ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> त्रुटि TS2554: अपेक्षित? तर्क, लेकिन मिला ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Additional Resources
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## प्रतिक्रिया
+
+यदि आपके पास कोई प्रश्न, प्रतिक्रिया, फीचर अनुरोध है या आप बस पहुंचना चाहते हैं, तो सबसे अच्छी जगह द ग्राफ डिस्कॉर्ड होगी जहां हमारे पास मैचस्टिक के लिए एक समर्पित चैनल है, जिसे 🔥 कहा जाता है| इकाई का परीक्षण।

From 2f3c08dd32612226923e22cb2d3b30cf9daad5ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:32 -0500
Subject: [PATCH 0941/3820] New translations transferring-a-subgraph.mdx
 (Hindi)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/hi/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/hi/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..3720eff056a0
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+विभिन्न नेटवर्क पर प्रकाशित subgraphs के लिए उस पते पर एक NFT जारी किया गया है जिसने subgraph प्रकाशित किया। NFT एक मानक ERC721 पर आधारित है, जो The Graph नेटवर्क पर खातों के बीच स्थानांतरण की सुविधा देता है।
+
+## अनुस्मारक 
+
+- जो भी 'NFT' का मालिक है, वह subgraph को नियंत्रित करता है।
+- यदि मालिक 'NFT' को बेचने या स्थानांतरित करने का निर्णय लेता है, तो वे नेटवर्क पर उस subgraph को संपादित या अपडेट नहीं कर पाएंगे।
+- आप आसानी से एक subgraph का नियंत्रण एक multi-sig में स्थानांतरित कर सकते हैं।
+- एक समुदाय का सदस्य DAO की ओर से एक subgraph बना सकता है।
+
+## अपने 'subgraph' को एक NFT के रूप में देखें
+
+अपने 'subgraph' को एक NFT के रूप में देखने के लिए, आप एक NFT मार्केटप्लेस जैसे OpenSea पर जा सकते हैं:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+या एक वॉलेट एक्सप्लोरर जैसे **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## चरण-दर-चरण
+
+एक Subgraph का स्वामित्व स्थानांतरित करने के लिए, निम्नलिखित करें:
+
+1. 'Subgraph Studio' में निर्मित UI का उपयोग करें:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. उस पते का चयन करें जिसे आप 'subgraph' को स्थानांतरित करना चाहेंगे:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+आप वैकल्पिक रूप से NFT बाजारों जैसे OpenSea के अंतर्निहित UI का भी उपयोग कर सकते हैं:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 69aac03a65053a268f6bf2871197180cb91e6c36 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:33 -0500
Subject: [PATCH 0942/3820] New translations graphql-api.mdx (Hindi)

---
 .../hi/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/hi/subgraphs/querying/graphql-api.mdx b/website/pages/hi/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..f1d417589f6b
--- /dev/null
+++ b/website/pages/hi/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: ग्राफक्यूएल एपीआई
+---
+
+The Graph में उपयोग किए जाने वाले GraphQL Query API के बारे में जानें।
+
+## GraphQL क्या है?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## GraphQL के साथ क्वेरीज़
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### उदाहरण
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sorting
+
+जब आप एक संग्रह के लिए क्वेरी कर रहे हों, तो आप:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### उदाहरण
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### नेस्टेड इकाई छँटाई के लिए उदाहरण
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+निम्नलिखित उदाहरण में टोकन उनके मालिक के नाम के अनुसार क्रमबद्ध किए गए हैं:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### पृष्ठ पर अंक लगाना
+
+जब एक संग्रह के लिए क्वेरी की जाती है, तो यह सबसे अच्छा होता है:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+पहले 10 टोकन पूछें:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+यदि एक क्लाइंट को बड़ी संख्या में एंटिटीज़ पुनर्प्राप्त करने की आवश्यकता है, तो एट्रिब्यूट पर आधारित क्वेरी बनाना और उस एट्रिब्यूट द्वारा फ़िल्टर करना अधिक प्रभावशाली है। उदाहरण के लिए, एक क्लाइंट इस क्वेरी का उपयोग करके बड़ी संख्या में टोकन पुनर्प्राप्त कर सकता है:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### छनन
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### श्रेणी फ़िल्टरिंग के लिए उदाहरण
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### ब्लॉक फ़िल्टरिंग के लिए उदाहरण
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### नेस्टेड इकाई फ़िल्टरिंग के लिए उदाहरण
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+यह उपयोगी हो सकता है यदि आप केवल उन संस्थाओं को लाना चाहते हैं जिनके चाइल्ड-स्तरीय निकाय प्रदान की गई शर्तों को पूरा करते हैं।
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### लॉजिकल ऑपरेटर्स
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### सभी फ़िल्टर
+
+पैरामीटर प्रत्यय की पूरी सूची:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Time-travel queries
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### उदाहरण
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### उदाहरण
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### पूर्ण पाठ खोज प्रश्न
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+पूर्ण पाठ खोज ऑपरेटर:
+
+| प्रतीक | ऑपरेटर      | Description                                                                                                                          |
+| ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`    | `And`       | सभी प्रदान किए गए शब्दों को शामिल करने वाली संस्थाओं के लिए एक से अधिक खोज शब्दों को फ़िल्टर में संयोजित करने के लिए                 |
+| |      | `Or`        | या ऑपरेटर द्वारा अलग किए गए एकाधिक खोज शब्दों वाली क्वेरी सभी संस्थाओं को प्रदान की गई शर्तों में से किसी से मेल के साथ वापस कर देगी |
+| `<->`  | `Follow by` | दो शब्दों के बीच की दूरी निर्दिष्ट करें।                                                                                             |
+| `:*`   | `Prefix`    | उन शब्दों को खोजने के लिए उपसर्ग खोज शब्द का उपयोग करें जिनके उपसर्ग मेल खाते हैं (2 वर्ण आवश्यक हैं।)                               |
+
+#### उदाहरण
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### मान्यकरण
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## योजना
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> ध्यान दें: हमारा एपीआई म्यूटेशन को उजागर नहीं करता है क्योंकि डेवलपर्स से उम्मीद की जाती है कि वे अपने एप्लिकेशन से अंतर्निहित ब्लॉकचेन के खिलाफ सीधे लेन-देन(transaction) जारी करेंगे।
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### सबग्राफ मेटाडेटा
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- हैश: ब्लॉक का हैश
+- नंबर: ब्लॉक नंबर
+- टाइमस्टैम्प: ब्लॉक का टाइमस्टैम्प, यदि उपलब्ध हो (यह वर्तमान में केवल ईवीएम नेटवर्क को इंडेक्स करने वाले सबग्राफ के लिए उपलब्ध है)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From b350470119bb910935c6cc5d732931a0a1a45f40 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:34 -0500
Subject: [PATCH 0943/3820] New translations python.mdx (Hindi)

---
 .../pages/hi/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/querying/python.mdx

diff --git a/website/pages/hi/subgraphs/querying/python.mdx b/website/pages/hi/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..4d1bbb06dde9
--- /dev/null
+++ b/website/pages/hi/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## शुरू करना
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From 8d1fd222eff8ddaa736f265c33a3ee34f68108fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:35 -0500
Subject: [PATCH 0944/3820] New translations triggers.mdx (Hindi)

---
 website/pages/hi/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/hi/substreams/sps/triggers.mdx

diff --git a/website/pages/hi/substreams/sps/triggers.mdx b/website/pages/hi/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a5d1d32e1b95
--- /dev/null
+++ b/website/pages/hi/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: सबस्ट्रीम्स ट्रिगर्स
+---
+
+कस्टम ट्रिगर्स आपको अपने subgraph मैपिंग फ़ाइल और इकाइयों (टेबल और फ़ील्ड के समान) में डेटा सीधे भेजने की अनुमति देते हैं, जो GraphQL परत का पूरा उपयोग करने में सक्षम बनाते हैं। अपने Substreams मॉड्यूल द्वारा उत्पन्न Protobuf परिभाषाओं को आयात करके, आप अपने subgraph के हैंडलर के भीतर इस डेटा को प्राप्त और प्रोसेस कर सकते हैं, जो subgraph ढांचे के भीतर कुशल और सुव्यवस्थित डेटा प्रबंधन सुनिश्चित करता है।
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+निम्नलिखित कोड यह दर्शाता है कि कैसे एक handleTransactions फ़ंक्शन को एक subgraph हैंडलर में परिभाषित किया जा सकता है। यह फ़ंक्शन कच्चे Substreams बाइट्स को एक पैरामीटर के रूप में प्राप्त करता है और उन्हें एक Transactions ऑब्जेक्ट में डिकोड करता है। प्रत्येक लेनदेन के लिए, एक नई subgraph एंटिटी बनाई जाती है।
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+यहां वह है जो आप mappings.ts फ़ाइल में देख रहे हैं:
+
+1. Substreams डेटा को जनरेट किए गए Transactions ऑब्जेक्ट में डिकोड किया जाता है, यह ऑब्जेक्ट किसी अन्य AssemblyScript ऑब्जेक्ट की तरह उपयोग किया जाता है।
+2. लेनदेन पर लूप करना
+3. प्रत्येक लेनदेन के लिए एक नया subgraph entity बनाएं
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From ca3b9e1a118275faaa553c505f155e2cdfcb3407 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:36 -0500
Subject: [PATCH 0945/3820] New translations overview.mdx (Swahili)

---
 website/pages/sw/indexing/overview.mdx | 821 +++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 website/pages/sw/indexing/overview.mdx

diff --git a/website/pages/sw/indexing/overview.mdx b/website/pages/sw/indexing/overview.mdx
new file mode 100644
index 000000000000..ced5ed20026b
--- /dev/null
+++ b/website/pages/sw/indexing/overview.mdx
@@ -0,0 +1,821 @@
+---
+title: Indexing Overview
+---
+
+Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+
+GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.
+
+Indexers select subgraphs to index based on the subgraph’s curation signal, where Curators stake GRT in order to indicate which subgraphs are high-quality and should be prioritized. Consumers (eg. applications) can also set parameters for which Indexers process queries for their subgraphs and set preferences for query fee pricing.
+
+<Difficulty level="ADVANCED" />
+
+## FAQ
+
+### What is the minimum stake required to be an Indexer on the network?
+
+The minimum stake for an Indexer is currently set to 100K GRT.
+
+### What are the revenue streams for an Indexer?
+
+**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+
+**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+
+### How are indexing rewards distributed?
+
+Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+
+Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+
+### What is a proof of indexing (POI)?
+
+POIs are used in the network to verify that an Indexer is indexing the subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific subgraph deployment up to and including that block.
+
+### When are indexing rewards distributed?
+
+Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).
+
+### Can pending indexing rewards be monitored?
+
+The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+
+Many of the community-made dashboards include pending rewards values and they can be easily checked manually by following these steps:
+
+1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+
+```graphql
+query indexerAllocations {
+  indexer(id: "<INDEXER_ADDRESS>") {
+    allocations {
+      activeForIndexer {
+        allocations {
+          id
+        }
+      }
+    }
+  }
+}
+```
+
+Use Etherscan to call `getRewards()`:
+
+- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+
+<!---->
+
+- To call `getRewards()`:
+  - Expand the **9. getRewards** dropdown.
+  - Enter the **allocationID** in the input.
+  - Click the **Query** button.
+
+### What are disputes and where can I view them?
+
+Indexer's queries and allocations can both be disputed on The Graph during the dispute period. The dispute period varies, depending on the type of dispute. Queries/attestations have 7 epochs dispute window, whereas allocations have 56 epochs. After these periods pass, disputes cannot be opened against either of allocations or queries. When a dispute is opened, a deposit of a minimum of 10,000 GRT is required by the Fishermen, which will be locked until the dispute is finalized and a resolution has been given. Fisherman are any network participants that open disputes.
+
+Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+
+- If the dispute is rejected, the GRT deposited by the Fishermen will be burned, and the disputed Indexer will not be slashed.
+- If the dispute is settled as a draw, the Fishermen's deposit will be returned, and the disputed Indexer will not be slashed.
+- If the dispute is accepted, the GRT deposited by the Fishermen will be returned, the disputed Indexer will be slashed and the Fishermen will earn 50% of the slashed GRT.
+
+Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+
+### What are query fee rebates and when are they distributed?
+
+Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+
+Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+
+### What is query fee cut and indexing reward cut?
+
+The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+
+- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+
+- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+
+### How do Indexers know which subgraphs to index?
+
+Indexers may differentiate themselves by applying advanced techniques for making subgraph indexing decisions but to give a general idea we'll discuss several key metrics used to evaluate subgraphs in the network:
+
+- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+
+- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+
+- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+
+- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+
+### What are the hardware requirements?
+
+- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
+- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+
+| Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
+| -------- | :------------------: | :---------------------------: | :-------------------------: | :-------------: | :----------------------: |
+| Small    |           4          |               8               |              1              |        4        |            16            |
+| Standard |           8          |               30              |              1              |        12       |            48            |
+| Medium   |          16          |               64              |              2              |        32       |            64            |
+| Large    |          72          |              468              |             3.5             |        48       |            184           |
+
+### What are some basic security precautions an Indexer should take?
+
+- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+
+- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+
+## Infrastructure
+
+At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+
+- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+
+- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+
+- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+
+- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+
+- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+
+Note: To support agile scaling, it is recommended that query and indexing concerns are separated between different sets of nodes: query nodes and index nodes.
+
+### Ports overview
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+
+#### Graph Node
+
+| Port | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
+
+#### Indexer Service
+
+| Port | Purpose                                              | Routes                                                      | CLI Argument    | Environment Variable   |
+| ---- | ---------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
+| 7600 | GraphQL HTTP server<br />(for paid subgraph queries) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
+| 7300 | Prometheus metrics                                   | /metrics                                                    | \--metrics-port | -                      |
+
+#### Indexer Agent
+
+| Port | Purpose                | Routes | CLI Argument               | Environment Variable                    |
+| ---- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | Indexer management API | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+
+### Setup server infrastructure using Terraform on Google Cloud
+
+> Note: Indexers can alternatively use AWS, Microsoft Azure, or Alibaba.
+
+#### Install prerequisites
+
+- Google Cloud SDK
+- Kubectl command line tool
+- Terraform
+
+#### Create a Google Cloud Project
+
+- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+
+- Navigate to the `./terraform` directory, this is where all commands should be executed.
+
+```sh
+cd terraform
+```
+
+- Authenticate with Google Cloud and create a new project.
+
+```sh
+gcloud auth login
+project=<PROJECT_NAME>
+gcloud projects create --enable-cloud-apis $project
+```
+
+- Use the Google Cloud Console's billing page to enable billing for the new project.
+
+- Create a Google Cloud configuration.
+
+```sh
+proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
+gcloud config configurations create $project
+gcloud config set project "$proj_id"
+gcloud config set compute/region us-central1
+gcloud config set compute/zone us-central1-a
+```
+
+- Enable required Google Cloud APIs.
+
+```sh
+gcloud services enable compute.googleapis.com
+gcloud services enable container.googleapis.com
+gcloud services enable servicenetworking.googleapis.com
+gcloud services enable sqladmin.googleapis.com
+```
+
+- Create a service account.
+
+```sh
+svc_name=<SERVICE_ACCOUNT_NAME>
+gcloud iam service-accounts create $svc_name \
+  --description="Service account for Terraform" \
+  --display-name="$svc_name"
+gcloud iam service-accounts list
+# Get the email of the service account from the list
+svc=$(gcloud iam service-accounts list --format='get(email)'
+--filter="displayName=$svc_name")
+gcloud iam service-accounts keys create .gcloud-credentials.json \
+  --iam-account="$svc"
+gcloud projects add-iam-policy-binding $proj_id \
+  --member serviceAccount:$svc \
+  --role roles/editor
+```
+
+- Enable peering between database and Kubernetes cluster that will be created in the next step.
+
+```sh
+gcloud compute addresses create google-managed-services-default \
+  --prefix-length=20 \
+  --purpose=VPC_PEERING \
+  --network default \
+  --global \
+  --description 'IP Range for peer networks.'
+gcloud services vpc-peerings connect \
+  --network=default \
+  --ranges=google-managed-services-default
+```
+
+- Create minimal terraform configuration file (update as needed).
+
+```sh
+indexer=<INDEXER_NAME>
+cat > terraform.tfvars <<EOF
+project = "$proj_id"
+indexer = "$indexer"
+database_password = "<database password>"
+EOF
+```
+
+#### Use Terraform to create infrastructure
+
+Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+
+- Run the following commands to create the infrastructure.
+
+```sh
+# Install required plugins
+terraform init
+
+# View plan for resources to be created
+terraform plan
+
+# Create the resources (expect it to take up to 30 minutes)
+terraform apply
+```
+
+Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+
+```sh
+gcloud container clusters get-credentials $indexer
+kubectl config use-context $(kubectl config get-contexts --output='name'
+| grep $indexer)
+```
+
+#### Creating the Kubernetes components for the Indexer
+
+- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+
+- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+
+Deploy all resources with `kubectl apply -k $dir`.
+
+### Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+
+#### Getting started from source
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start a PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Now that all the dependencies are setup, start the Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+#### Getting started using Docker
+
+#### Prerequisites
+
+- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+
+#### Setup
+
+1. Clone Graph Node and navigate to the Docker directory:
+
+```sh
+git clone https://github.com/graphprotocol/graph-node
+cd graph-node/docker
+```
+
+2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+
+```sh
+./setup.sh
+```
+
+3. Start a local Graph Node that will connect to your Ethereum endpoint:
+
+```sh
+docker-compose up
+```
+
+### Indexer components
+
+To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
+
+- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+
+- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+
+- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+
+#### Getting started
+
+The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+
+#### From NPM packages
+
+```sh
+npm install -g @graphprotocol/indexer-service
+npm install -g @graphprotocol/indexer-agent
+
+# Indexer CLI is a plugin for Graph CLI, so both need to be installed:
+npm install -g @graphprotocol/graph-cli
+npm install -g @graphprotocol/indexer-cli
+
+# Indexer service
+graph-indexer-service start ...
+
+# Indexer agent
+graph-indexer-agent start ...
+
+# Indexer CLI
+#Forward the port of your agent pod if using Kubernetes
+kubectl port-forward pod/POD_ID 18000:8000
+graph indexer connect http://localhost:18000/
+graph indexer ...
+```
+
+#### From source
+
+```sh
+# From Repo root directory
+yarn
+
+# Indexer Service
+cd packages/indexer-service
+./bin/graph-indexer-service start ...
+
+# Indexer agent
+cd packages/indexer-agent
+./bin/graph-indexer-service start ...
+
+# Indexer CLI
+cd packages/indexer-cli
+./bin/graph-indexer-cli indexer connect http://localhost:18000/
+./bin/graph-indexer-cli indexer ...
+```
+
+#### Using docker
+
+- Pull images from the registry
+
+```sh
+docker pull ghcr.io/graphprotocol/indexer-service:latest
+docker pull ghcr.io/graphprotocol/indexer-agent:latest
+```
+
+Or build images locally from source
+
+```sh
+# Indexer service
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-service \
+  -t indexer-service:latest \
+# Indexer agent
+docker build \
+  --build-arg NPM_TOKEN=<npm-token> \
+  -f Dockerfile.indexer-agent \
+  -t indexer-agent:latest \
+```
+
+- Run the components
+
+```sh
+docker run -p 7600:7600 -it indexer-service:latest ...
+docker run -p 18000:8000 -it indexer-agent:latest ...
+```
+
+**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+
+#### Using K8s and Terraform
+
+See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+
+#### Usage
+
+> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+
+#### Indexer agent
+
+```sh
+graph-indexer-agent start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --graph-node-admin-endpoint http://localhost:8020/ \
+  --public-indexer-url http://localhost:7600/ \
+  --indexer-geo-coordinates <YOUR_COORDINATES> \
+  --index-node-ids default \
+  --indexer-management-port 18000 \
+  --metrics-port 7040 \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  --default-allocation-amount 100 \
+  --register true \
+  --inject-dai true \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database indexer \
+  --allocation-management auto \
+  | pino-pretty
+```
+
+#### Indexer service
+
+```sh
+SERVER_HOST=localhost \
+SERVER_PORT=5432 \
+SERVER_DB_NAME=is_staging \
+SERVER_DB_USER=<DB_USERNAME> \
+SERVER_DB_PASSWORD=<DB_PASSWORD> \
+graph-indexer-service start \
+  --ethereum <MAINNET_ETH_ENDPOINT> \
+  --ethereum-network mainnet \
+  --mnemonic <MNEMONIC> \
+  --indexer-address <INDEXER_ADDRESS> \
+  --port 7600 \
+  --metrics-port 7300 \
+  --graph-node-query-endpoint http://localhost:8000/ \
+  --graph-node-status-endpoint http://localhost:8030/graphql \
+  --postgres-host localhost \
+  --postgres-port 5432 \
+  --postgres-username <DB_USERNAME> \
+  --postgres-password <DB_PASSWORD> \
+  --postgres-database is_staging \
+  --network-subgraph-endpoint http://query-node-0:8000/subgraphs/id/QmUzRg2HHMpbgf6Q4VHKNDbtBEJnyp5JWCh2gUX9AV6jXv \
+  | pino-pretty
+```
+
+#### Indexer CLI
+
+The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+
+```sh
+graph indexer connect http://localhost:18000
+graph indexer status
+```
+
+#### Indexer management using Indexer CLI
+
+The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+
+#### Usage
+
+The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+
+- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+
+- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+
+- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+
+- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+
+- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+
+- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+
+- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+
+- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+
+All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+
+#### Indexing rules
+
+Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+
+For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+
+Data model:
+
+```graphql
+type IndexingRule {
+    identifier: string
+    identifierType: IdentifierType
+    decisionBasis: IndexingDecisionBasis!
+    allocationAmount: number | null
+    allocationLifetime: number | null
+    autoRenewal: boolean
+    parallelAllocations: number | null
+    maxAllocationPercentage: number | null
+    minSignal: string | null
+    maxSignal: string | null
+    minStake: string | null
+    minAverageQueryFees: string | null
+    custom: string | null
+    requireSupported: boolean | null
+  }
+
+IdentifierType {
+  deployment
+  subgraph
+  group
+}
+
+IndexingDecisionBasis {
+  rules
+  never
+  always
+  offchain
+}
+```
+
+Example usage of indexing rule:
+
+```
+graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules set QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK decisionBasis always allocationAmount 123321 allocationLifetime 14 autoRenewal false requireSupported false
+
+graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+
+graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
+```
+
+#### Actions queue CLI
+
+The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+
+The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+
+- Action added to the queue by the 3rd party optimizer tool or indexer-cli user
+- Indexer can use the `indexer-cli` to view all queued actions
+- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
+- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
+- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken.
+
+Data model:
+
+```graphql
+Type ActionInput {
+    status: ActionStatus
+    type: ActionType
+    deploymentID: string | null
+    allocationID: string | null
+    amount: string | null
+    poi: string | null
+    force: boolean | null
+    source: string
+    reason: string | null
+    priority: number | null
+}
+
+ActionStatus {
+  queued
+  approved
+  pending
+  success
+  failed
+  canceled
+}
+
+ActionType {
+  allocate
+  unallocate
+  reallocate
+  collect
+}
+```
+
+Example usage from source:
+
+```bash
+graph indexer actions get all
+
+graph indexer actions get --status queued
+
+graph indexer actions queue allocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 5000
+
+graph indexer actions queue reallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae5 55000
+
+graph indexer actions queue unallocate QmeqJ6hsdyk9dVbo1tvRgAxWrVS3rkERiEMsxzPShKLco6 0x4a58d33e27d3acbaecc92c15101fbc82f47c2ae
+
+graph indexer actions cancel
+
+graph indexer actions approve 1 3 5
+
+graph indexer actions execute approve
+```
+
+Note that supported action types for allocation management have different input requirements:
+
+- `Allocate` - allocate stake to a specific subgraph deployment
+
+  - required action params:
+    - deploymentID
+    - amount
+
+- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+
+  - required action params:
+    - allocationID
+    - deploymentID
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+
+  - required action params:
+    - allocationID
+    - deploymentID
+    - amount
+  - optional action params:
+    - poi
+    - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+
+#### Cost models
+
+Cost models provide dynamic pricing for queries based on market and query attributes. The Indexer Service shares a cost model with the gateways for each subgraph for which they intend to respond to queries. The gateways, in turn, use the cost model to make Indexer selection decisions per query and to negotiate payment with chosen Indexers.
+
+#### Agora
+
+The Agora language provides a flexible format for declaring cost models for queries. An Agora price model is a sequence of statements that execute in order for each top-level query in a GraphQL query. For each top-level query, the first statement which matches it determines the price for that query.
+
+A statement is comprised of a predicate, which is used for matching GraphQL queries, and a cost expression which when evaluated outputs a cost in decimal GRT. Values in the named argument position of a query may be captured in the predicate and used in the expression. Globals may also be set and substituted in for placeholders in an expression.
+
+Example cost model:
+
+```
+# This statement captures the skip value,
+# uses a boolean expression in the predicate to match specific queries that use `skip`
+# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+
+# This default will match any GraphQL expression.
+# It uses a Global substituted into the expression to calculate cost
+default => 0.1 * $SYSTEM_LOAD;
+```
+
+Example query costing using the above model:
+
+| Query                                                                        | Price   |
+| ---------------------------------------------------------------------------- | ------- |
+| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
+| { tokens { symbol } }                                                        | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+
+#### Applying the cost model
+
+Cost models are applied via the Indexer CLI, which passes them to the Indexer Management API of the Indexer agent for storing in the database. The Indexer Service will then pick them up and serve the cost models to gateways whenever they ask for them.
+
+```sh
+indexer cost set variables '{ "SYSTEM_LOAD": 1.4 }'
+indexer cost set model my_model.agora
+```
+
+## Interacting with the network
+
+### Stake in the protocol
+
+The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+
+> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+
+Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+
+#### Approve tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+
+3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+
+6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+
+#### Stake tokens
+
+1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+
+2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+
+3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+
+4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+
+5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+
+6. Call `stake()` to stake GRT in the protocol.
+
+7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+
+8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+
+```
+setDelegationParameters(950000, 600000, 500)
+```
+
+### Setting delegation parameters
+
+The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+
+### How to set delegation parameters
+
+To set the delegation parameters using Graph Explorer interface, follow these steps:
+
+1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
+3. Connect the wallet you have as a signer.
+4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
+5. Submit the transaction to the network.
+
+> Note: This transaction will need to be confirmed by the multisig wallet signers.
+
+### The life of an allocation
+
+After being created by an Indexer a healthy allocation goes through two states.
+
+- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+
+- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+
+Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.

From 7efb48ada52e24985836780046fdb65d8aaf9539 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:38 -0500
Subject: [PATCH 0946/3820] New translations tap.mdx (Swahili)

---
 website/pages/sw/indexing/tap.mdx | 193 ++++++++++++++++++++++++++++++
 1 file changed, 193 insertions(+)
 create mode 100644 website/pages/sw/indexing/tap.mdx

diff --git a/website/pages/sw/indexing/tap.mdx b/website/pages/sw/indexing/tap.mdx
new file mode 100644
index 000000000000..3bab672ab211
--- /dev/null
+++ b/website/pages/sw/indexing/tap.mdx
@@ -0,0 +1,193 @@
+---
+title: TAP Migration Guide
+---
+
+Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+
+## Overview
+
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+
+- Efficiently handles micropayments.
+- Adds a layer of consolidations to onchain transactions and costs.
+- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
+- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+
+## Specifics
+
+TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+
+For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+
+### RAV Details
+
+- It’s money that is waiting to be sent to the blockchain.
+
+- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+
+- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+
+### Redeeming RAV
+
+As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+
+1. An Indexer closes allocation.
+
+2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+
+3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+
+4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+
+   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+
+## Blockchain Addresses
+
+### Contracts
+
+| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+
+### Gateway
+
+| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------- | --------------------------------------------- | --------------------------------------------- |
+| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+
+### Requirements
+
+In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+
+- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+
+> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+
+## Migration Guide
+
+### Software versions
+
+The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+
+### Steps
+
+1. **Indexer Agent**
+
+   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+
+2. **Indexer Service**
+
+   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+
+3. **TAP Agent**
+
+   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+
+4. **Configure Indexer Service and TAP Agent**
+
+   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+
+   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+
+For minimal configuration, use the following template:
+
+```bash
+# You will have to change *all* the values below to match your setup.
+#
+# Some of the config below are global graph network values, which you can find here:
+# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+#
+# Pro tip: if you need to load some values from the environment into this config, you
+# can overwrite with environment variables. For example, the following can be replaced
+# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+#
+# [database]
+# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+
+[indexer]
+indexer_address = "0x1111111111111111111111111111111111111111"
+operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+[database]
+# The URL of the Postgres database used for the indexer components. The same database
+# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
+# the necessary tables.
+postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+[graph_node]
+# URL to your graph-node's query endpoint
+query_url = "<http://graph-node:8000>"
+# URL to your graph-node's status endpoint
+status_url = "<http://graph-node:8000/graphql>"
+
+[subgraphs.network]
+# Query URL for the Graph Network subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[subgraphs.escrow]
+# Query URL for the Escrow subgraph.
+query_url = "<http://example.com/network-subgraph>"
+# Optional, deployment to look for in the local `graph-node`, if locally indexed.
+# Locally indexing the subgraph is recommended.
+# NOTE: Use `query_url` or `deployment_id` only
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+[blockchain]
+# The chain ID of the network that the graph network is running on
+chain_id = 1337
+# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+########################################
+# Specific configurations to tap-agent #
+########################################
+[tap]
+# This is the amount of fees you are willing to risk at any given time. For ex.
+# if the sender stops supplying RAVs for long enough and the fees exceed this
+# amount, the indexer-service will stop accepting queries from the sender
+# until the fees are aggregated.
+# NOTE: Use strings for decimal values to prevent rounding errors
+# e.g:
+# max_amount_willing_to_lose_grt = "0.1"
+max_amount_willing_to_lose_grt = 20
+
+[tap.sender_aggregator_endpoints]
+# Key-Value of all senders and their aggregator endpoints
+# This one below is for the E&N testnet gateway for example.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+```
+
+Notes:
+
+- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+
+**Log Level**
+
+- You can set the log level by using the `RUST_LOG` environment variable.
+- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+
+## Monitoring
+
+### Metrics
+
+All components expose the port 7300 to be queried by prometheus.
+
+### Grafana Dashboard
+
+You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+
+### Launchpad
+
+Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From f8732b82ec98aacf8b38c10180c5155a5924a9ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:41 -0500
Subject: [PATCH 0947/3820] New translations graph-node.mdx (Swahili)

---
 .../pages/sw/indexing/tooling/graph-node.mdx  | 345 ++++++++++++++++++
 1 file changed, 345 insertions(+)
 create mode 100644 website/pages/sw/indexing/tooling/graph-node.mdx

diff --git a/website/pages/sw/indexing/tooling/graph-node.mdx b/website/pages/sw/indexing/tooling/graph-node.mdx
new file mode 100644
index 000000000000..6a27301b680b
--- /dev/null
+++ b/website/pages/sw/indexing/tooling/graph-node.mdx
@@ -0,0 +1,345 @@
+---
+title: Graph Node
+---
+
+Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+
+This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+
+## Graph Node
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+
+Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+
+### PostgreSQL database
+
+The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
+
+### Network clients
+
+In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+
+While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+
+**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+
+### IPFS Nodes
+
+Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+
+### Prometheus metrics server
+
+To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
+
+### Getting started from source
+
+#### Install prerequisites
+
+- **Rust**
+
+- **PostgreSQL**
+
+- **IPFS**
+
+- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+
+```sh
+sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
+```
+
+#### Setup
+
+1. Start a PostgreSQL database server
+
+```sh
+initdb -D .postgres
+pg_ctl -D .postgres -l logfile start
+createdb graph-node
+```
+
+2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+
+3. Now that all the dependencies are setup, start the Graph Node:
+
+```sh
+cargo run -p graph-node --release -- \
+  --postgres-url postgresql://[USERNAME]:[PASSWORD]@localhost:5432/graph-node \
+  --ethereum-rpc [NETWORK_NAME]:[URL] \
+  --ipfs https://ipfs.network.thegraph.com
+```
+
+### Getting started with Kubernetes
+
+A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+
+### Ports
+
+When it is running Graph Node exposes the following ports:
+
+| Port | Purpose                                         | Routes                                         | CLI Argument       | Environment Variable |
+| ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
+| 8000 | GraphQL HTTP server<br />(for subgraph queries) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                    |
+| 8001 | GraphQL WS<br />(for subgraph subscriptions)    | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                    |
+| 8020 | JSON-RPC<br />(for managing deployments)        | /                                              | \--admin-port      | -                    |
+| 8030 | Subgraph indexing status API                    | /graphql                                       | \--index-node-port | -                    |
+| 8040 | Prometheus metrics                              | /metrics                                       | \--metrics-port    | -                    |
+
+> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+
+## Advanced Graph Node configuration
+
+At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
+
+This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+
+### `config.toml`
+
+A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+
+> When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.
+
+A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+
+```toml
+[store]
+[store.primary]
+connection="<.. postgres-url argument ..>"
+[deployment]
+[[deployment.rule]]
+indexers = [ "<.. list of all indexing nodes ..>" ]
+```
+
+Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+
+#### Multiple Graph Nodes
+
+Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+
+> Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding.
+
+#### Deployment rules
+
+Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+
+Example deployment rule configuration:
+
+```toml
+[deployment]
+[[deployment.rule]]
+match = { name = "(vip|important)/.*" }
+shard = "vip"
+indexers = [ "index_node_vip_0", "index_node_vip_1" ]
+[[deployment.rule]]
+match = { network = "kovan" }
+# No shard, so we use the default shard called 'primary'
+indexers = [ "index_node_kovan_0" ]
+[[deployment.rule]]
+match = { network = [ "xdai", "poa-core" ] }
+indexers = [ "index_node_other_0" ]
+[[deployment.rule]]
+# There's no 'match', so any subgraph matches
+shards = [ "sharda", "shardb" ]
+indexers = [
+    "index_node_community_0",
+    "index_node_community_1",
+    "index_node_community_2",
+    "index_node_community_3",
+    "index_node_community_4",
+    "index_node_community_5"
+  ]
+```
+
+Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+
+#### Dedicated query nodes
+
+Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
+
+```toml
+[general]
+query = "<regular expression>"
+```
+
+Any node whose --node-id matches the regular expression will be set up to only respond to queries.
+
+#### Database scaling via sharding
+
+For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
+
+Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+
+Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore.
+
+> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+
+In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
+
+Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+
+#### Dedicated block ingestion
+
+If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+```
+
+#### Supporting multiple networks
+
+The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+
+- Multiple networks
+- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
+- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
+
+The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+
+```toml
+[chains]
+ingestor = "block_ingestor_node"
+[chains.mainnet]
+shard = "vip"
+provider = [
+  { label = "mainnet1", url = "http://..", features = [], headers = { Authorization = "Bearer foo" } },
+  { label = "mainnet2", url = "http://..", features = [ "archive", "traces" ] }
+]
+[chains.kovan]
+shard = "primary"
+provider = [ { label = "kovan", url = "http://..", features = [] } ]
+```
+
+Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+
+### Environment variables
+
+Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+
+### Continuous deployment
+
+Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes.
+
+- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+
+### Managing Graph Node
+
+Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+
+#### Logging
+
+Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+
+In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+
+#### Monitoring & alerting
+
+Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics.
+
+The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+
+#### Graphman
+
+`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+
+The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+
+Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+
+### Working with subgraphs
+
+#### Indexing status API
+
+Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+
+The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+
+#### Indexing performance
+
+There are three separate parts of the indexing process:
+
+- Fetching events of interest from the provider
+- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
+- Writing the resulting data to the store
+
+These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+
+Common causes of indexing slowness:
+
+- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
+- Making large numbers of `eth_calls` as part of handlers
+- A large amount of store interaction during execution
+- A large amount of data to save to the store
+- A large number of events to process
+- Slow database connection time, for crowded nodes
+- The provider itself falling behind the chain head
+- Slowness in fetching new receipts at the chain head from the provider
+
+Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+
+#### Failed subgraphs
+
+During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+
+- Deterministic failures: these are failures which will not be resolved with retries
+- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
+
+In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+
+> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+
+#### Block and call cache
+
+Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+
+However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+
+If a block cache inconsistency is suspected, such as a tx receipt missing event:
+
+1. `graphman chain list` to find the chain name.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
+   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+   2. If the block matches the provider, then the issue can be debugged directly against the provider.
+
+#### Querying issues and errors
+
+Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+
+However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+
+There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.
+
+##### Query caching
+
+Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+
+##### Analysing queries
+
+Problematic queries most often surface in one of two ways. In some cases, users themselves report that a given query is slow. In that case the challenge is to diagnose the reason for the slowness - whether it is a general issue, or specific to that subgraph or query. And then of course to resolve it, if possible.
+
+In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
+
+Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+
+Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
+
+##### Account-like optimisation
+
+Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
+
+For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+
+The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+
+In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+
+Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+
+For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+
+#### Removing subgraphs
+
+> This is new functionality, which will be available in Graph Node 0.29.x
+
+At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 2a914a10dd39566625f2632d73d4629396e78120 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:44 -0500
Subject: [PATCH 0948/3820] New translations advanced.mdx (Swahili)

---
 .../developing/creating/advanced.mdx          | 555 ++++++++++++++++++
 1 file changed, 555 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/creating/advanced.mdx

diff --git a/website/pages/sw/subgraphs/developing/creating/advanced.mdx b/website/pages/sw/subgraphs/developing/creating/advanced.mdx
new file mode 100644
index 000000000000..a6a4b224bc3e
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/creating/advanced.mdx
@@ -0,0 +1,555 @@
+---
+title: Advanced Subgraph Features
+---
+
+## Overview
+
+Add and implement advanced subgraph features to enhanced your subgraph's built.
+
+Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+
+| Feature                                              | Name             |
+| ---------------------------------------------------- | ---------------- |
+| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
+| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
+| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+
+For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+  - fullTextSearch
+  - nonFatalErrors
+dataSources: ...
+```
+
+> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+
+## Timeseries and Aggregations
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+
+### Example Schema
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+### Defining Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+
+Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+
+#### Available Aggregation Intervals
+
+- `hour`: sets the timeseries period every hour, on the hour.
+- `day`: sets the timeseries period every day, starting and ending at 00:00.
+
+#### Available Aggregation Functions
+
+- `sum`: Total of all values.
+- `count`: Number of values.
+- `min`: Minimum value.
+- `max`: Maximum value.
+- `first`: First value in the period.
+- `last`: Last value in the period.
+
+#### Example Aggregations Query
+
+```graphql
+{
+  stats(interval: "hour", where: { timestamp_gt: 1704085200 }) {
+    id
+    timestamp
+    sum
+  }
+}
+```
+
+Note:
+
+To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
+
+[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+
+## Non-fatal errors
+
+Indexing errors on already synced subgraphs will, by default, cause the subgraph to fail and stop syncing. Subgraphs can alternatively be configured to continue syncing in the presence of errors, by ignoring the changes made by the handler which provoked the error. This gives subgraph authors time to correct their subgraphs while queries continue to be served against the latest block, though the results might be inconsistent due to the bug that caused the error. Note that some errors are still always fatal. To be non-fatal, the error must be known to be deterministic.
+
+> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+
+Enabling non-fatal errors requires setting the following feature flag on the subgraph manifest:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+features:
+    - nonFatalErrors
+    ...
+```
+
+The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+
+```graphql
+foos(first: 100, subgraphError: allow) {
+  id
+}
+
+_meta {
+  hasIndexingErrors
+}
+```
+
+If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+
+```graphql
+"data": {
+    "foos": [
+        {
+          "id": "0xdead"
+        }
+    ],
+    "_meta": {
+        "hasIndexingErrors": true
+    }
+},
+"errors": [
+    {
+        "message": "indexing_error"
+    }
+]
+```
+
+## IPFS/Arweave File Data Sources
+
+File data sources are a new subgraph functionality for accessing off-chain data during indexing in a robust, extendable way. File data sources support fetching files from IPFS and from Arweave.
+
+> This also lays the groundwork for deterministic indexing of off-chain data, as well as the potential introduction of arbitrary HTTP-sourced data.
+
+### Overview
+
+Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
+
+This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+
+> This replaces the existing `ipfs.cat` API
+
+### Upgrade guide
+
+#### Update `graph-ts` and `graph-cli`
+
+File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+
+#### Add a new entity type which will be updated when files are found
+
+File data sources cannot access or update chain-based entities, but must update file specific entities.
+
+This may mean splitting out fields from existing entities into separate entities, linked together.
+
+Original combined entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  externalURL: String!
+  ipfsURI: String!
+  image: String!
+  name: String!
+  description: String!
+  type: String!
+  updatedAtTimestamp: BigInt
+  owner: User!
+}
+```
+
+New, split entity:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenID: BigInt!
+  tokenURI: String!
+  ipfsURI: TokenMetadata
+  updatedAtTimestamp: BigInt
+  owner: String!
+}
+
+type TokenMetadata @entity {
+  id: ID!
+  image: String!
+  externalURL: String!
+  name: String!
+  description: String!
+}
+```
+
+If the relationship is 1:1 between the parent entity and the resulting file data source entity, the simplest pattern is to link the parent entity to a resulting file entity by using the IPFS CID as the lookup. Get in touch on Discord if you are having difficulty modelling your new file-based entities!
+
+> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+
+#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+
+This is the data source which will be spawned when a file of interest is identified.
+
+```yaml
+templates:
+  - name: TokenMetadata
+    kind: file/ipfs
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      file: ./src/mapping.ts
+      handler: handleMetadata
+      entities:
+        - TokenMetadata
+      abis:
+        - name: Token
+          file: ./abis/Token.json
+```
+
+> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+
+The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+
+#### Create a new handler to process files
+
+This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+
+The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+
+```typescript
+const cid = dataSource.stringParam()
+```
+
+Example handler:
+
+```typescript
+import { json, Bytes, dataSource } from '@graphprotocol/graph-ts'
+import { TokenMetadata } from '../generated/schema'
+
+export function handleMetadata(content: Bytes): void {
+  let tokenMetadata = new TokenMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+  if (value) {
+    const image = value.get('image')
+    const name = value.get('name')
+    const description = value.get('description')
+    const externalURL = value.get('external_url')
+
+    if (name && image && description && externalURL) {
+      tokenMetadata.name = name.toString()
+      tokenMetadata.image = image.toString()
+      tokenMetadata.externalURL = externalURL.toString()
+      tokenMetadata.description = description.toString()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+#### Spawn file data sources when required
+
+You can now create file data sources during execution of chain-based handlers:
+
+- Import the template from the auto-generated `templates`
+- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+
+For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+
+For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+
+Example:
+
+```typescript
+import { TokenMetadata as TokenMetadataTemplate } from '../generated/templates'
+
+const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+//This example code is for a Crypto coven subgraph. The above ipfs hash is a directory with token metadata for all crypto coven NFTs.
+
+export function handleTransfer(event: TransferEvent): void {
+  let token = Token.load(event.params.tokenId.toString())
+  if (!token) {
+    token = new Token(event.params.tokenId.toString())
+    token.tokenID = event.params.tokenId
+
+    token.tokenURI = '/' + event.params.tokenId.toString() + '.json'
+    const tokenIpfsHash = ipfshash + token.tokenURI
+    //This creates a path to the metadata for a single Crypto coven NFT. It concats the directory with "/" + filename + ".json"
+
+    token.ipfsURI = tokenIpfsHash
+
+    TokenMetadataTemplate.create(tokenIpfsHash)
+  }
+
+  token.updatedAtTimestamp = event.block.timestamp
+  token.owner = event.params.to.toHexString()
+  token.save()
+}
+```
+
+This will create a new file data source, which will poll Graph Node's configured IPFS or Arweave endpoint, retrying if it is not found. When the file is found, the file data source handler will be executed.
+
+This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+
+> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+
+Congratulations, you are using file data sources!
+
+#### Deploying your subgraphs
+
+You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+
+#### Limitations
+
+File data source handlers and entities are isolated from other subgraph entities, ensuring that they are deterministic when executed, and ensuring no contamination of chain-based data sources. To be specific:
+
+- Entities created by File Data Sources are immutable, and cannot be updated
+- File Data Source handlers cannot access entities from other file data sources
+- Entities associated with File Data Sources cannot be accessed by chain-based handlers
+
+> While this constraint should not be problematic for most use-cases, it may introduce complexity for some. Please get in touch via Discord if you are having issues modelling your file-based data in a subgraph!
+
+Additionally, it is not possible to create data sources from a file data source, be it an onchain data source or another file data source. This restriction may be lifted in the future.
+
+#### Best practices
+
+If you are linking NFT metadata to corresponding tokens, use the metadata's IPFS hash to reference a Metadata entity from the Token entity. Save the Metadata entity using the IPFS hash as an ID.
+
+You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+
+If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+
+> We are working to improve the above recommendation, so queries only return the "most recent" version
+
+#### Known issues
+
+File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+
+Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+
+#### Examples
+
+[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+
+#### References
+
+[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+
+## Indexed Argument Filters / Topic Filters
+
+> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+
+Topic filters, also known as indexed argument filters, are a powerful feature in subgraphs that allow users to precisely filter blockchain events based on the values of their indexed arguments.
+
+- These filters help isolate specific events of interest from the vast stream of events on the blockchain, allowing subgraphs to operate more efficiently by focusing only on relevant data.
+
+- This is useful for creating personal subgraphs that track specific addresses and their interactions with various smart contracts on the blockchain.
+
+### How Topic Filters Work
+
+When a smart contract emits an event, any arguments that are marked as indexed can be used as filters in a subgraph's manifest. This allows the subgraph to listen selectively for events that match these indexed arguments.
+
+- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract Token {
+    // Event declaration with indexed parameters for addresses
+    event Transfer(address indexed from, address indexed to, uint256 value);
+
+    // Function to simulate transferring tokens
+    function transfer(address to, uint256 value) public {
+        // Emitting the Transfer event with from, to, and value
+        emit Transfer(msg.sender, to, value);
+    }
+}
+```
+
+In this example:
+
+- The `Transfer` event is used to log transactions of tokens between addresses.
+- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
+- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+
+#### Configuration in Subgraphs
+
+Topic filters are defined directly within the event handler configuration in the subgraph manifest. Here is how they are configured:
+
+```yaml
+eventHandlers:
+  - event: SomeEvent(indexed uint256, indexed address, indexed uint256)
+    handler: handleSomeEvent
+    topic1: ['0xValue1', '0xValue2']
+    topic2: ['0xAddress1', '0xAddress2']
+    topic3: ['0xValue3']
+```
+
+In this setup:
+
+- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- Each topic can have one or more values, and an event is only processed if it matches one of the values in each specified topic.
+
+#### Filter Logic
+
+- Within a Single Topic: The logic functions as an OR condition. The event will be processed if it matches any one of the listed values in a given topic.
+- Between Different Topics: The logic functions as an AND condition. An event must satisfy all specified conditions across different topics to trigger the associated handler.
+
+#### Example 1: Tracking Direct Transfers from Address A to Address B
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleDirectedTransfer
+    topic1: ['0xAddressA'] # Sender Address
+    topic2: ['0xAddressB'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
+- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+
+#### Example 2: Tracking Transactions in Either Direction Between Two or More Addresses
+
+```yaml
+eventHandlers:
+  - event: Transfer(indexed address,indexed address,uint256)
+    handler: handleTransferToOrFrom
+    topic1: ['0xAddressA', '0xAddressB', '0xAddressC'] # Sender Address
+    topic2: ['0xAddressB', '0xAddressC'] # Receiver Address
+```
+
+In this configuration:
+
+- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
+- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- The subgraph will index transactions that occur in either direction between multiple addresses allowing for comprehensive monitoring of interactions involving all addresses.
+
+## Declared eth_call
+
+> Note: This is an experimental feature that is not currently available in a stable Graph Node release yet. You can only use it in Subgraph Studio or your self-hosted node.
+
+Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+
+This feature does the following:
+
+- Significantly improves the performance of fetching data from the Ethereum blockchain by reducing the total time for multiple calls and optimizing the subgraph's overall efficiency.
+- Allows faster data fetching, resulting in quicker query responses and a better user experience.
+- Reduces wait times for applications that need to aggregate data from multiple Ethereum calls, making the data retrieval process more efficient.
+
+### Key Concepts
+
+- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Parallel Execution: Instead of waiting for one call to finish before starting the next, multiple calls can be initiated simultaneously.
+- Time Efficiency: The total time taken for all the calls changes from the sum of the individual call times (sequential) to the time taken by the longest call (parallel).
+
+#### Scenario without Declarative `eth_calls`
+
+Imagine you have a subgraph that needs to make three Ethereum calls to fetch data about a user's transactions, balance, and token holdings.
+
+Traditionally, these calls might be made sequentially:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Total time taken = 3 + 2 + 4 = 9 seconds
+
+#### Scenario with Declarative `eth_calls`
+
+With this feature, you can declare these calls to be executed in parallel:
+
+1. Call 1 (Transactions): Takes 3 seconds
+2. Call 2 (Balance): Takes 2 seconds
+3. Call 3 (Token Holdings): Takes 4 seconds
+
+Since these calls are executed in parallel, the total time taken is equal to the time taken by the longest call.
+
+Total time taken = max (3, 2, 4) = 4 seconds
+
+#### How it Works
+
+1. Declarative Definition: In the subgraph manifest, you declare the Ethereum calls in a way that indicates they can be executed in parallel.
+2. Parallel Execution Engine: The Graph Node's execution engine recognizes these declarations and runs the calls simultaneously.
+3. Result Aggregation: Once all calls are complete, the results are aggregated and used by the subgraph for further processing.
+
+#### Example Configuration in Subgraph Manifest
+
+Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+
+`Subgraph.yaml` using `event.address`:
+
+```yaml
+eventHandlers:
+event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
+handler: handleSwap
+calls:
+  global0X128: Pool[event.address].feeGrowthGlobal0X128()
+  global1X128: Pool[event.address].feeGrowthGlobal1X128()
+```
+
+Details for the example above:
+
+- `global0X128` is the declared `eth_call`.
+- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
+- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
+- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+
+`Subgraph.yaml` using `event.params`
+
+```yaml
+calls:
+  - ERC20DecimalsToken0: ERC20[event.params.token0].decimals()
+```
+
+### Grafting onto Existing Subgraphs
+
+> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+
+When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+
+A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+
+```yaml
+description: ...
+graft:
+  base: Qm... # Subgraph ID of base subgraph
+  block: 7345624 # Block number
+```
+
+When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+
+Because grafting copies rather than indexes base data, it is much quicker to get the subgraph to the desired block than indexing from scratch, though the initial data copy can still take several hours for very large subgraphs. While the grafted subgraph is being initialized, the Graph Node will log information about the entity types that have already been copied.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.

From 71f763529d3e978dcb7c35ed25262f0ecb264bdc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:45 -0500
Subject: [PATCH 0949/3820] New translations api.mdx (Swahili)

---
 .../developing/creating/graph-ts/api.mdx      | 890 ++++++++++++++++++
 1 file changed, 890 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/creating/graph-ts/api.mdx

diff --git a/website/pages/sw/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/sw/subgraphs/developing/creating/graph-ts/api.mdx
new file mode 100644
index 000000000000..5cd8ab120b25
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/creating/graph-ts/api.mdx
@@ -0,0 +1,890 @@
+---
+title: AssemblyScript API
+---
+
+> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+
+Learn what built-in APIs can be used when writing subgraph mappings. There are two kinds of APIs available out of the box:
+
+- The [Graph TypeScript library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) (`graph-ts`)
+- Code generated from subgraph files by `graph codegen`
+
+You can also add other libraries as dependencies, as long as they are compatible with [AssemblyScript](https://github.com/AssemblyScript/assemblyscript).
+
+Since language mappings are written in AssemblyScript, it is useful to review the language and standard library features from the [AssemblyScript wiki](https://github.com/AssemblyScript/assemblyscript/wiki).
+
+## API Reference
+
+The `@graphprotocol/graph-ts` library provides the following APIs:
+
+- An `ethereum` API for working with Ethereum smart contracts, events, blocks, transactions, and Ethereum values.
+- A `store` API to load and save entities from and to the Graph Node store.
+- A `log` API to log messages to the Graph Node output and Graph Explorer.
+- An `ipfs` API to load files from IPFS.
+- A `json` API to parse JSON data.
+- A `crypto` API to use cryptographic functions.
+- Low-level primitives to translate between different type systems such as Ethereum, JSON, GraphQL and AssemblyScript.
+
+### Versions
+
+The `apiVersion` in the subgraph manifest specifies the mapping API version which is run by Graph Node for a given subgraph.
+
+| Version | Release notes                                                                                                                                                                                                                                            |
+| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  0.0.9  | Adds new host functions [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                             |
+|  0.0.8  | Adds validation for existence of fields in the schema when saving an entity.                                                                                                                                                                             |
+|  0.0.7  | Added `TransactionReceipt` and `Log` classes to the Ethereum types<br />Added `receipt` field to the Ethereum Event object                                                                                                                               |
+|  0.0.6  | Added `nonce` field to the Ethereum Transaction object<br />Added `baseFeePerGas` to the Ethereum Block object                                                                                                                                           |
+|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
+|  0.0.4  | Added `functionSignature` field to the Ethereum SmartContractCall object                                                                                                                                                                                 |
+|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
+|  0.0.2  | Added `input` field to the Ethereum Transaction object                                                                                                                                                                                                   |
+
+### Built-in Types
+
+Documentation on the base types built into AssemblyScript can be found in the [AssemblyScript wiki](https://www.assemblyscript.org/types.html).
+
+The following additional types are provided by `@graphprotocol/graph-ts`.
+
+#### ByteArray
+
+```typescript
+import { ByteArray } from '@graphprotocol/graph-ts'
+```
+
+`ByteArray` represents an array of `u8`.
+
+_Construction_
+
+- `fromI32(x: i32): ByteArray` - Decomposes `x` into bytes.
+- `fromHexString(hex: string): ByteArray` - Input length must be even. Prefixing with `0x` is optional.
+
+_Type conversions_
+
+- `toHexString(): string` - Converts to a hex string prefixed with `0x`.
+- `toString(): string` - Interprets the bytes as a UTF-8 string.
+- `toBase58(): string` - Encodes the bytes into a base58 string.
+- `toU32(): u32` - Interprets the bytes as a little-endian `u32`. Throws in case of overflow.
+- `toI32(): i32` - Interprets the byte array as a little-endian `i32`. Throws in case of overflow.
+
+_Operators_
+
+- `equals(y: ByteArray): bool` – can be written as `x == y`.
+- `concat(other: ByteArray) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by `other`
+- `concatI32(other: i32) : ByteArray` - return a new `ByteArray` consisting of `this` directly followed by the byte representation of `other`
+
+#### BigDecimal
+
+```typescript
+import { BigDecimal } from '@graphprotocol/graph-ts'
+```
+
+`BigDecimal` is used to represent arbitrary precision decimals.
+
+> Note: [Internally](https://github.com/graphprotocol/graph-node/blob/master/graph/src/data/store/scalar/bigdecimal.rs) `BigDecimal` is stored in [IEEE-754 decimal128 floating-point format](https://en.wikipedia.org/wiki/Decimal128_floating-point_format), which supports 34 decimal digits of significand. This makes `BigDecimal` unsuitable for representing fixed-point types that can span wider than 34 digits, such as a Solidity [`ufixed256x18`](https://docs.soliditylang.org/en/latest/types.html#fixed-point-numbers) or equivalent.
+
+_Construction_
+
+- `constructor(bigInt: BigInt)` – creates a `BigDecimal` from an `BigInt`.
+- `static fromString(s: string): BigDecimal` – parses from a decimal string.
+
+_Type conversions_
+
+- `toString(): string` – prints to a decimal string.
+
+_Math_
+
+- `plus(y: BigDecimal): BigDecimal` – can be written as `x + y`.
+- `minus(y: BigDecimal): BigDecimal` – can be written as `x - y`.
+- `times(y: BigDecimal): BigDecimal` – can be written as `x * y`.
+- `div(y: BigDecimal): BigDecimal` – can be written as `x / y`.
+- `equals(y: BigDecimal): bool` – can be written as `x == y`.
+- `notEqual(y: BigDecimal): bool` – can be written as `x != y`.
+- `lt(y: BigDecimal): bool` – can be written as `x < y`.
+- `le(y: BigDecimal): bool` – can be written as `x <= y`.
+- `gt(y: BigDecimal): bool` – can be written as `x > y`.
+- `ge(y: BigDecimal): bool` – can be written as `x >= y`.
+- `neg(): BigDecimal` - can be written as `-x`.
+
+#### BigInt
+
+```typescript
+import { BigInt } from '@graphprotocol/graph-ts'
+```
+
+`BigInt` is used to represent big integers. This includes Ethereum values of type `uint32` to `uint256` and `int64` to `int256`. Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.
+
+The `BigInt` class has the following API:
+
+_Construction_
+
+- `BigInt.fromI32(x: i32): BigInt` – creates a `BigInt` from an `i32`.
+
+- `BigInt.fromString(s: string): BigInt`– Parses a `BigInt` from a string.
+
+- `BigInt.fromUnsignedBytes(x: Bytes): BigInt` – Interprets `bytes` as an unsigned, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+- `BigInt.fromSignedBytes(x: Bytes): BigInt` – Interprets `bytes` as a signed, little-endian integer. If your input is big-endian, call `.reverse()` first.
+
+  _Type conversions_
+
+- `x.toHex(): string` – turns `BigInt` into a string of hexadecimal characters.
+
+- `x.toString(): string` – turns `BigInt` into a decimal number string.
+
+- `x.toI32(): i32` – returns the `BigInt` as an `i32`; fails if the value does not fit into `i32`. It's a good idea to first check `x.isI32()`.
+
+- `x.toBigDecimal(): BigDecimal` - converts into a decimal with no fractional part.
+
+_Math_
+
+- `x.plus(y: BigInt): BigInt` – can be written as `x + y`.
+- `x.minus(y: BigInt): BigInt` – can be written as `x - y`.
+- `x.times(y: BigInt): BigInt` – can be written as `x * y`.
+- `x.div(y: BigInt): BigInt` – can be written as `x / y`.
+- `x.mod(y: BigInt): BigInt` – can be written as `x % y`.
+- `x.equals(y: BigInt): bool` – can be written as `x == y`.
+- `x.notEqual(y: BigInt): bool` – can be written as `x != y`.
+- `x.lt(y: BigInt): bool` – can be written as `x < y`.
+- `x.le(y: BigInt): bool` – can be written as `x <= y`.
+- `x.gt(y: BigInt): bool` – can be written as `x > y`.
+- `x.ge(y: BigInt): bool` – can be written as `x >= y`.
+- `x.neg(): BigInt` – can be written as `-x`.
+- `x.divDecimal(y: BigDecimal): BigDecimal` – divides by a decimal, giving a decimal result.
+- `x.isZero(): bool` – Convenience for checking if the number is zero.
+- `x.isI32(): bool` – Check if the number fits in an `i32`.
+- `x.abs(): BigInt` – Absolute value.
+- `x.pow(exp: u8): BigInt` – Exponentiation.
+- `bitOr(x: BigInt, y: BigInt): BigInt` – can be written as `x | y`.
+- `bitAnd(x: BigInt, y: BigInt): BigInt` – can be written as `x & y`.
+- `leftShift(x: BigInt, bits: u8): BigInt` – can be written as `x << y`.
+- `rightShift(x: BigInt, bits: u8): BigInt` – can be written as `x >> y`.
+
+#### TypedMap
+
+```typescript
+import { TypedMap } from '@graphprotocol/graph-ts'
+```
+
+`TypedMap` can be used to store key-value pairs. See [this example](https://github.com/graphprotocol/aragon-subgraph/blob/29dd38680c5e5104d9fdc2f90e740298c67e4a31/individual-dao-subgraph/mappings/constants.ts#L51).
+
+The `TypedMap` class has the following API:
+
+- `new TypedMap<K, V>()` – creates an empty map with keys of type `K` and values of type `V`
+- `map.set(key: K, value: V): void` – sets the value of `key` to `value`
+- `map.getEntry(key: K): TypedMapEntry<K, V> | null` – returns the key-value pair for a `key` or `null` if the `key` does not exist in the map
+- `map.get(key: K): V | null` – returns the value for a `key` or `null` if the `key` does not exist in the map
+- `map.isSet(key: K): bool` – returns `true` if the `key` exists in the map and `false` if it does not
+
+#### Bytes
+
+```typescript
+import { Bytes } from '@graphprotocol/graph-ts'
+```
+
+`Bytes` is used to represent arbitrary-length arrays of bytes. This includes Ethereum values of type `bytes`, `bytes32`, etc.
+
+The `Bytes` class extends AssemblyScript's [Uint8Array](https://github.com/AssemblyScript/assemblyscript/blob/3b1852bc376ae799d9ebca888e6413afac7b572f/std/assembly/typedarray.ts#L64) and this supports all the `Uint8Array` functionality, plus the following new methods:
+
+_Construction_
+
+- `fromHexString(hex: string) : Bytes` - Convert the string `hex` which must consist of an even number of hexadecimal digits to a `ByteArray`. The string `hex` can optionally start with `0x`
+- `fromI32(i: i32) : Bytes` - Convert `i` to an array of bytes
+
+_Type conversions_
+
+- `b.toHex()` – returns a hexadecimal string representing the bytes in the array
+- `b.toString()` – converts the bytes in the array to a string of unicode characters
+- `b.toBase58()` – turns an Ethereum Bytes value to base58 encoding (used for IPFS hashes)
+
+_Operators_
+
+- `b.concat(other: Bytes) : Bytes` - - return new `Bytes` consisting of `this` directly followed by `other`
+- `b.concatI32(other: i32) : ByteArray` - return new `Bytes` consisting of `this` directly follow by the byte representation of `other`
+
+#### Address
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+```
+
+`Address` extends `Bytes` to represent Ethereum `address` values.
+
+It adds the following method on top of the `Bytes` API:
+
+- `Address.fromString(s: string): Address` – creates an `Address` from a hexadecimal string
+- `Address.fromBytes(b: Bytes): Address` – create an `Address` from `b` which must be exactly 20 bytes long. Passing in a value with fewer or more bytes will result in an error
+
+### Store API
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+```
+
+The `store` API allows to load, save and remove entities from and to the Graph Node store.
+
+Entities written to the store map one-to-one to the `@entity` types defined in the subgraph's GraphQL schema. To make working with these entities convenient, the `graph codegen` command provided by the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) generates entity classes, which are subclasses of the built-in `Entity` type, with property getters and setters for the fields in the schema as well as methods to load and save these entities.
+
+#### Creating entities
+
+The following is a common pattern for creating entities from Ethereum events.
+
+```typescript
+// Import the Transfer event class generated from the ERC20 ABI
+import { Transfer as TransferEvent } from '../generated/ERC20/ERC20'
+
+// Import the Transfer entity type generated from the GraphQL schema
+import { Transfer } from '../generated/schema'
+
+// Transfer event handler
+export function handleTransfer(event: TransferEvent): void {
+  // Create a Transfer entity, using the transaction hash as the entity ID
+  let id = event.transaction.hash
+  let transfer = new Transfer(id)
+
+  // Set properties on the entity, using the event parameters
+  transfer.from = event.params.from
+  transfer.to = event.params.to
+  transfer.amount = event.params.amount
+
+  // Save the entity to the store
+  transfer.save()
+}
+```
+
+When a `Transfer` event is encountered while processing the chain, it is passed to the `handleTransfer` event handler using the generated `Transfer` type (aliased to `TransferEvent` here to avoid a naming conflict with the entity type). This type allows accessing data such as the event's parent transaction and its parameters.
+
+Each entity must have a unique ID to avoid collisions with other entities. It is fairly common for event parameters to include a unique identifier that can be used.
+
+> Note: Using the transaction hash as the ID assumes that no other events in the same transaction create entities with this hash as the ID.
+
+#### Loading entities from the store
+
+If an entity already exists, it can be loaded from the store with the following:
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.load(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+As the entity may not exist in the store yet, the `load` method returns a value of type `Transfer | null`. It may be necessary to check for the `null` case before using the value.
+
+> Note: Loading entities is only necessary if the changes made in the mapping depend on the previous data of an entity. See the next section for the two ways of updating existing entities.
+
+#### Looking up entities created withing a block
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 and `@graphprotocol/graph-cli` v0.49.0 the `loadInBlock` method is available on all entity types.
+
+The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+
+- In the case where the transaction does not exist, the subgraph will have to go to the database simply to find out that the entity does not exist. If the subgraph author already knows that the entity must have been created in the same block, using `loadInBlock` avoids this database roundtrip.
+- For some subgraphs, these missed lookups can contribute significantly to the indexing time.
+
+```typescript
+let id = event.transaction.hash // or however the ID is constructed
+let transfer = Transfer.loadInBlock(id)
+if (transfer == null) {
+  transfer = new Transfer(id)
+}
+
+// Use the Transfer entity as before
+```
+
+> Note: If there is no entity created in the given block, `loadInBlock` will return `null` even if there is an entity with the given ID in the store.
+
+#### Looking up derived entities
+
+As of `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.31.0 and `@graphprotocol/graph-cli` v0.51.0 the `loadRelated` method is available.
+
+This enables loading derived entity fields from within an event handler. For example, given the following schema:
+
+```graphql
+type Token @entity {
+  id: ID!
+  holder: Holder!
+  color: String
+}
+
+type Holder @entity {
+  id: ID!
+  tokens: [Token!]! @derivedFrom(field: "holder")
+}
+```
+
+The following code will load the `Token` entity that the `Holder` entity was derived from:
+
+```typescript
+let holder = Holder.load('test-id')
+// Load the Token entities associated with a given holder
+let tokens = holder.tokens.load()
+```
+
+#### Updating existing entities
+
+There are two ways to update an existing entity:
+
+1. Load the entity with e.g. `Transfer.load(id)`, set properties on the entity, then `.save()` it back to the store.
+2. Simply create the entity with e.g. `new Transfer(id)`, set properties on the entity, then `.save()` it to the store. If the entity already exists, the changes are merged into it.
+
+Changing properties is straight forward in most cases, thanks to the generated property setters:
+
+```typescript
+let transfer = new Transfer(id)
+transfer.from = ...
+transfer.to = ...
+transfer.amount = ...
+```
+
+It is also possible to unset properties with one of the following two instructions:
+
+```typescript
+transfer.from.unset()
+transfer.from = null
+```
+
+This only works with optional properties, i.e. properties that are declared without a `!` in GraphQL. Two examples would be `owner: Bytes` or `amount: BigInt`.
+
+Updating array properties is a little more involved, as the getting an array from an entity creates a copy of that array. This means array properties have to be set again explicitly after changing the array. The following assumes `entity` has a `numbers: [BigInt!]!` field.
+
+```typescript
+// This won't work
+entity.numbers.push(BigInt.fromI32(1))
+entity.save()
+
+// This will work
+let numbers = entity.numbers
+numbers.push(BigInt.fromI32(1))
+entity.numbers = numbers
+entity.save()
+```
+
+#### Removing entities from the store
+
+There is currently no way to remove an entity via the generated types. Instead, removing an entity requires passing the name of the entity type and the entity ID to `store.remove`:
+
+```typescript
+import { store } from '@graphprotocol/graph-ts'
+...
+let id = event.transaction.hash
+store.remove('Transfer', id)
+```
+
+### Ethereum API
+
+The Ethereum API provides access to smart contracts, public state variables, contract functions, events, transactions, blocks and the encoding/decoding Ethereum data.
+
+#### Support for Ethereum Types
+
+As with entities, `graph codegen` generates classes for all smart contracts and events used in a subgraph. For this, the contract ABIs need to be part of the data source in the subgraph manifest. Typically, the ABI files are stored in an `abis/` folder.
+
+With the generated classes, conversions between Ethereum types and the [built-in types](#built-in-types) take place behind the scenes so that subgraph authors do not have to worry about them.
+
+The following example illustrates this. Given a subgraph schema like
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  amount: BigInt!
+}
+```
+
+and a `Transfer(address,address,uint256)` event signature on Ethereum, the `from`, `to` and `amount` values of type `address`, `address` and `uint256` are converted to `Address` and `BigInt`, allowing them to be passed on to the `Bytes!` and `BigInt!` properties of the `Transfer` entity:
+
+```typescript
+let id = event.transaction.hash
+let transfer = new Transfer(id)
+transfer.from = event.params.from
+transfer.to = event.params.to
+transfer.amount = event.params.amount
+transfer.save()
+```
+
+#### Events and Block/Transaction Data
+
+Ethereum events passed to event handlers, such as the `Transfer` event in the previous examples, not only provide access to the event parameters but also to their parent transaction and the block they are part of. The following data can be obtained from `event` instances (these classes are a part of the `ethereum` module in `graph-ts`):
+
+```typescript
+class Event {
+  address: Address
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string | null
+  block: Block
+  transaction: Transaction
+  parameters: Array<EventParam>
+  receipt: TransactionReceipt | null
+}
+
+class Block {
+  hash: Bytes
+  parentHash: Bytes
+  unclesHash: Bytes
+  author: Address
+  stateRoot: Bytes
+  transactionsRoot: Bytes
+  receiptsRoot: Bytes
+  number: BigInt
+  gasUsed: BigInt
+  gasLimit: BigInt
+  timestamp: BigInt
+  difficulty: BigInt
+  totalDifficulty: BigInt
+  size: BigInt | null
+  baseFeePerGas: BigInt | null
+}
+
+class Transaction {
+  hash: Bytes
+  index: BigInt
+  from: Address
+  to: Address | null
+  value: BigInt
+  gasLimit: BigInt
+  gasPrice: BigInt
+  input: Bytes
+  nonce: BigInt
+}
+
+class TransactionReceipt {
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  blockHash: Bytes
+  blockNumber: BigInt
+  cumulativeGasUsed: BigInt
+  gasUsed: BigInt
+  contractAddress: Address
+  logs: Array<Log>
+  status: BigInt
+  root: Bytes
+  logsBloom: Bytes
+}
+
+class Log {
+  address: Address
+  topics: Array<Bytes>
+  data: Bytes
+  blockHash: Bytes
+  blockNumber: Bytes
+  transactionHash: Bytes
+  transactionIndex: BigInt
+  logIndex: BigInt
+  transactionLogIndex: BigInt
+  logType: string
+  removed: bool | null
+}
+```
+
+#### Access to Smart Contract State
+
+The code generated by `graph codegen` also includes classes for the smart contracts used in the subgraph. These can be used to access public state variables and call functions of the contract at the current block.
+
+A common pattern is to access the contract from which an event originates. This is achieved with the following code:
+
+```typescript
+// Import the generated contract class and generated Transfer event class
+import { ERC20Contract, Transfer as TransferEvent } from '../generated/ERC20Contract/ERC20Contract'
+// Import the generated entity class
+import { Transfer } from '../generated/schema'
+
+export function handleTransfer(event: TransferEvent) {
+  // Bind the contract to the address that emitted the event
+  let contract = ERC20Contract.bind(event.address)
+
+  // Access state variables and functions by calling them
+  let erc20Symbol = contract.symbol()
+}
+```
+
+`Transfer` is aliased to `TransferEvent` here to avoid a naming conflict with the entity type
+
+As long as the `ERC20Contract` on Ethereum has a public read-only function called `symbol`, it can be called with `.symbol()`. For public state variables a method with the same name is created automatically.
+
+Any other contract that is part of the subgraph can be imported from the generated code and can be bound to a valid address.
+
+#### Handling Reverted Calls
+
+If the read-only methods of your contract may revert, then you should handle that by calling the generated contract method prefixed with `try_`.
+
+- For example, the Gravity contract exposes the `gravatarToOwner` method. This code would be able to handle a revert in that method:
+
+```typescript
+let gravity = Gravity.bind(event.address)
+let callResult = gravity.try_gravatarToOwner(gravatar)
+if (callResult.reverted) {
+  log.info('getGravatar reverted', [])
+} else {
+  let owner = callResult.value
+}
+```
+
+> Note: A Graph node connected to a Geth or Infura client may not detect all reverts. If you rely on this, we recommend using a Graph Node connected to a Parity client.
+
+#### Encoding/Decoding ABI
+
+Data can be encoded and decoded according to Ethereum's ABI encoding format using the `encode` and `decode` functions in the `ethereum` module.
+
+```typescript
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let tupleArray: Array<ethereum.Value> = [
+  ethereum.Value.fromAddress(Address.fromString('0x0000000000000000000000000000000000000420')),
+  ethereum.Value.fromUnsignedBigInt(BigInt.fromI32(62)),
+]
+
+let tuple = tupleArray as ethereum.Tuple
+
+let encoded = ethereum.encode(ethereum.Value.fromTuple(tuple))!
+
+let decoded = ethereum.decode('(address,uint256)', encoded)
+```
+
+For more information:
+
+- [ABI Spec](https://docs.soliditylang.org/en/v0.7.4/abi-spec.html#types)
+- Encoding/decoding [Rust library/CLI](https://github.com/rust-ethereum/ethabi)
+- More [complex example](https://github.com/graphprotocol/graph-node/blob/08da7cb46ddc8c09f448c5ea4b210c9021ea05ad/tests/integration-tests/host-exports/src/mapping.ts#L86).
+
+#### Balance of an Address
+
+The native token balance of an address can be retrieved using the `ethereum` module. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`. The `getBalance()` retrieves the balance of the specified address as of the end of the block in which the event is triggered.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let address = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let balance = ethereum.getBalance(address) // returns balance in BigInt
+```
+
+#### Check if an Address is a Contract or EOA
+
+To check whether an address is a smart contract address or an externally owned address (EOA), use the `hasCode()` function from the `ethereum` module which will return `boolean`. This feature is available from `apiVersion: 0.0.9` which is defined `subgraph.yaml`.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddr = Address.fromString('0x2E645469f354BB4F5c8a05B3b30A929361cf77eC')
+let isContract = ethereum.hasCode(contractAddr).inner // returns true
+
+let eoa = Address.fromString('0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045')
+let isContract = ethereum.hasCode(eoa).inner // returns false
+```
+
+### Logging API
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+```
+
+The `log` API allows subgraphs to log information to the Graph Node standard output as well as Graph Explorer. Messages can be logged using different log levels. A basic format string syntax is provided to compose log messages from argument.
+
+The `log` API includes the following functions:
+
+- `log.debug(fmt: string, args: Array<string>): void` - logs a debug message.
+- `log.info(fmt: string, args: Array<string>): void` - logs an informational message.
+- `log.warning(fmt: string, args: Array<string>): void` - logs a warning.
+- `log.error(fmt: string, args: Array<string>): void` - logs an error message.
+- `log.critical(fmt: string, args: Array<string>): void` – logs a critical message _and_ terminates the subgraph.
+
+The `log` API takes a format string and an array of string values. It then replaces placeholders with the string values from the array. The first `{}` placeholder gets replaced by the first value in the array, the second `{}` placeholder gets replaced by the second value and so on.
+
+```typescript
+log.info('Message to be displayed: {}, {}, {}', [value.toString(), anotherValue.toString(), 'already a string'])
+```
+
+#### Logging one or more values
+
+##### Logging a single value
+
+In the example below, the string value "A" is passed into an array to become`['A']` before being logged:
+
+```typescript
+let myValue = 'A'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"
+  log.info('My value is: {}', [myValue])
+}
+```
+
+##### Logging a single entry from an existing array
+
+In the example below, only the first value of the argument array is logged, despite the array containing three values.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My value is: A"  (Even though three values are passed to `log.info`)
+  log.info('My value is: {}', myArray)
+}
+```
+
+#### Logging multiple entries from an existing array
+
+Each entry in the arguments array requires its own placeholder `{}` in the log message string. The below example contains three placeholders `{}` in the log message. Because of this, all three values in `myArray` are logged.
+
+```typescript
+let myArray = ['A', 'B', 'C']
+
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My first value is: A, second value is: B, third value is: C"
+  log.info('My first value is: {}, second value is: {}, third value is: {}', myArray)
+}
+```
+
+##### Logging a specific entry from an existing array
+
+To display a specific value in the array, the indexed value must be provided.
+
+```typescript
+export function handleSomeEvent(event: SomeEvent): void {
+  // Displays : "My third value is C"
+  log.info('My third value is: {}', [myArray[2]])
+}
+```
+
+##### Logging event information
+
+The example below logs the block number, block hash and transaction hash from an event:
+
+```typescript
+import { log } from '@graphprotocol/graph-ts'
+
+export function handleSomeEvent(event: SomeEvent): void {
+  log.debug('Block number: {}, block hash: {}, transaction hash: {}', [
+    event.block.number.toString(), // "47596000"
+    event.block.hash.toHexString(), // "0x..."
+    event.transaction.hash.toHexString(), // "0x..."
+  ])
+}
+```
+
+### IPFS API
+
+```typescript
+import { ipfs } from '@graphprotocol/graph-ts'
+```
+
+Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+
+Given an IPFS hash or path, reading a file from IPFS is done as follows:
+
+```typescript
+// Put this inside an event handler in the mapping
+let hash = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D'
+let data = ipfs.cat(hash)
+
+// Paths like `QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile`
+// that include files in directories are also supported
+let path = 'QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/Makefile'
+let data = ipfs.cat(path)
+```
+
+**Note:** `ipfs.cat` is not deterministic at the moment. If the file cannot be retrieved over the IPFS network before the request times out, it will return `null`. Due to this, it's always worth checking the result for `null`.
+
+It is also possible to process larger files in a streaming fashion with `ipfs.map`. The function expects the hash or path for an IPFS file, the name of a callback, and flags to modify its behavior:
+
+```typescript
+import { JSONValue, Value } from '@graphprotocol/graph-ts'
+
+export function processItem(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+  let title = obj.get('title')
+
+  if (!id || !title) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let newItem = new Item(id)
+  newItem.title = title.toString()
+  newitem.parent = userData.toString() // Set parent to "parentId"
+  newitem.save()
+}
+
+// Put this inside an event handler in the mapping
+ipfs.map('Qm...', 'processItem', Value.fromString('parentId'), ['json'])
+
+// Alternatively, use `ipfs.mapJSON`
+ipfs.mapJSON('Qm...', 'processItem', Value.fromString('parentId'))
+```
+
+The only flag currently supported is `json`, which must be passed to `ipfs.map`. With the `json` flag, the IPFS file must consist of a series of JSON values, one value per line. The call to `ipfs.map` will read each line in the file, deserialize it into a `JSONValue` and call the callback for each of them. The callback can then use entity operations to store data from the `JSONValue`. Entity changes are stored only when the handler that called `ipfs.map` finishes successfully; in the meantime, they are kept in memory, and the size of the file that `ipfs.map` can process is therefore limited.
+
+On success, `ipfs.map` returns `void`. If any invocation of the callback causes an error, the handler that invoked `ipfs.map` is aborted, and the subgraph is marked as failed.
+
+### Crypto API
+
+```typescript
+import { crypto } from '@graphprotocol/graph-ts'
+```
+
+The `crypto` API makes a cryptographic functions available for use in mappings. Right now, there is only one:
+
+- `crypto.keccak256(input: ByteArray): ByteArray`
+
+### JSON API
+
+```typescript
+import { json, JSONValueKind } from '@graphprotocol/graph-ts'
+```
+
+JSON data can be parsed using the `json` API:
+
+- `json.fromBytes(data: Bytes): JSONValue` – parses JSON data from a `Bytes` array interpreted as a valid UTF-8 sequence
+- `json.try_fromBytes(data: Bytes): Result<JSONValue, boolean>` – safe version of `json.fromBytes`, it returns an error variant if the parsing failed
+- `json.fromString(data: string): JSONValue` – parses JSON data from a valid UTF-8 `String`
+- `json.try_fromString(data: string): Result<JSONValue, boolean>` – safe version of `json.fromString`, it returns an error variant if the parsing failed
+
+The `JSONValue` class provides a way to pull values out of an arbitrary JSON document. Since JSON values can be booleans, numbers, arrays and more, `JSONValue` comes with a `kind` property to check the type of a value:
+
+```typescript
+let value = json.fromBytes(...)
+if (value.kind == JSONValueKind.BOOL) {
+  ...
+}
+```
+
+In addition, there is a method to check if the value is `null`:
+
+- `value.isNull(): boolean`
+
+When the type of a value is certain, it can be converted to a [built-in type](#built-in-types) using one of the following methods:
+
+- `value.toBool(): boolean`
+- `value.toI64(): i64`
+- `value.toF64(): f64`
+- `value.toBigInt(): BigInt`
+- `value.toString(): string`
+- `value.toArray(): Array<JSONValue>` - (and then convert `JSONValue` with one of the 5 methods above)
+
+### Type Conversions Reference
+
+| Source(s)            | Destination          | Conversion function          |
+| -------------------- | -------------------- | ---------------------------- |
+| Address              | Bytes                | none                         |
+| Address              | String               | s.toHexString()              |
+| BigDecimal           | String               | s.toString()                 |
+| BigInt               | BigDecimal           | s.toBigDecimal()             |
+| BigInt               | String (hexadecimal) | s.toHexString() or s.toHex() |
+| BigInt               | String (unicode)     | s.toString()                 |
+| BigInt               | i32                  | s.toI32()                    |
+| Boolean              | Boolean              | none                         |
+| Bytes (signed)       | BigInt               | BigInt.fromSignedBytes(s)    |
+| Bytes (unsigned)     | BigInt               | BigInt.fromUnsignedBytes(s)  |
+| Bytes                | String (hexadecimal) | s.toHexString() or s.toHex() |
+| Bytes                | String (unicode)     | s.toString()                 |
+| Bytes                | String (base58)      | s.toBase58()                 |
+| Bytes                | i32                  | s.toI32()                    |
+| Bytes                | u32                  | s.toU32()                    |
+| Bytes                | JSON                 | json.fromBytes(s)            |
+| int8                 | i32                  | none                         |
+| int32                | i32                  | none                         |
+| int32                | BigInt               | BigInt.fromI32(s)            |
+| uint24               | i32                  | none                         |
+| int64 - int256       | BigInt               | none                         |
+| uint32 - uint256     | BigInt               | none                         |
+| JSON                 | boolean              | s.toBool()                   |
+| JSON                 | i64                  | s.toI64()                    |
+| JSON                 | u64                  | s.toU64()                    |
+| JSON                 | f64                  | s.toF64()                    |
+| JSON                 | BigInt               | s.toBigInt()                 |
+| JSON                 | string               | s.toString()                 |
+| JSON                 | Array                | s.toArray()                  |
+| JSON                 | Object               | s.toObject()                 |
+| String               | Address              | Address.fromString(s)        |
+| Bytes                | Address              | Address.fromBytes(s)         |
+| String               | BigInt               | BigInt.fromString(s)         |
+| String               | BigDecimal           | BigDecimal.fromString(s)     |
+| String (hexadecimal) | Bytes                | ByteArray.fromHexString(s)   |
+| String (UTF-8)       | Bytes                | ByteArray.fromUTF8(s)        |
+
+### Data Source Metadata
+
+You can inspect the contract address, network and context of the data source that invoked the handler through the `dataSource` namespace:
+
+- `dataSource.address(): Address`
+- `dataSource.network(): string`
+- `dataSource.context(): DataSourceContext`
+
+### Entity and DataSourceContext
+
+The base `Entity` class and the child `DataSourceContext` class have helpers to dynamically set and get fields:
+
+- `setString(key: string, value: string): void`
+- `setI32(key: string, value: i32): void`
+- `setBigInt(key: string, value: BigInt): void`
+- `setBytes(key: string, value: Bytes): void`
+- `setBoolean(key: string, value: bool): void`
+- `setBigDecimal(key, value: BigDecimal): void`
+- `getString(key: string): string`
+- `getI32(key: string): i32`
+- `getBigInt(key: string): BigInt`
+- `getBytes(key: string): Bytes`
+- `getBoolean(key: string): boolean`
+- `getBigDecimal(key: string): BigDecimal`
+
+### DataSourceContext in Manifest
+
+The `context` section within `dataSources` allows you to define key-value pairs that are accessible within your subgraph mappings. The available types are `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`.
+
+Here is a YAML example illustrating the usage of various types in the `context` section:
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ContractName
+    network: mainnet
+    context:
+      bool_example:
+        type: Bool
+        data: true
+      string_example:
+        type: String
+        data: 'hello'
+      int_example:
+        type: Int
+        data: 42
+      int8_example:
+        type: Int8
+        data: 127
+      big_decimal_example:
+        type: BigDecimal
+        data: '10.99'
+      bytes_example:
+        type: Bytes
+        data: '0x68656c6c6f'
+      list_example:
+        type: List
+        data:
+          - type: Int
+            data: 1
+          - type: Int
+            data: 2
+          - type: Int
+            data: 3
+      big_int_example:
+        type: BigInt
+        data: '1000000000000000000000000'
+```
+
+- `Bool`: Specifies a Boolean value (`true` or `false`).
+- `String`: Specifies a String value.
+- `Int`: Specifies a 32-bit integer.
+- `Int8`: Specifies an 8-bit integer.
+- `BigDecimal`: Specifies a decimal number. Must be quoted.
+- `Bytes`: Specifies a hexadecimal string.
+- `List`: Specifies a list of items. Each item needs to specify its type and data.
+- `BigInt`: Specifies a large integer value. Must be quoted due to its large size.
+
+This context is then accessible in your subgraph mapping files, enabling more dynamic and configurable subgraphs.

From 6ca97ef0469e4950f79b4ad791f8d28574dbb217 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:46 -0500
Subject: [PATCH 0950/3820] New translations common-issues.mdx (Swahili)

---
 .../developing/creating/graph-ts/common-issues.mdx        | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/creating/graph-ts/common-issues.mdx

diff --git a/website/pages/sw/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/sw/subgraphs/developing/creating/graph-ts/common-issues.mdx
new file mode 100644
index 000000000000..f8d0c9c004c2
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -0,0 +1,8 @@
+---
+title: Common AssemblyScript Issues
+---
+
+There are certain [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) issues that are common to run into during subgraph development. They range in debug difficulty, however, being aware of them may help. The following is a non-exhaustive list of these issues:
+
+- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Scope is not inherited into [closure functions](https://www.assemblyscript.org/status.html#on-closures), i.e. variables declared outside of closure functions cannot be used. Explanation in [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 38356fff194b6744fa9eb0041eb7121d3885a509 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:48 -0500
Subject: [PATCH 0951/3820] New translations unit-testing-framework.mdx
 (Swahili)

---
 .../creating/unit-testing-framework.mdx       | 1402 +++++++++++++++++
 1 file changed, 1402 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/creating/unit-testing-framework.mdx

diff --git a/website/pages/sw/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/sw/subgraphs/developing/creating/unit-testing-framework.mdx
new file mode 100644
index 000000000000..2133c1d4b5c9
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -0,0 +1,1402 @@
+---
+title: Unit Testing Framework
+---
+
+Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+
+## Benefits of Using Matchstick
+
+- It's written in Rust and optimized for high performance.
+- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+
+## Getting Started
+
+### Install Dependencies
+
+In order to use the test helper methods and run tests, you need to install the following dependencies:
+
+```sh
+yarn add --dev matchstick-as
+```
+
+### Install PostgreSQL
+
+`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+
+> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+
+#### Using MacOS
+
+Installation command:
+
+```sh
+brew install postgresql
+```
+
+Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+
+```sh
+ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
+```
+
+#### Using Linux
+
+Installation command (depends on your distro):
+
+```sh
+sudo apt install postgresql
+```
+
+### Using WSL (Windows Subsystem for Linux)
+
+You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
+
+```
+static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+```
+
+or
+
+```
+<PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
+```
+
+Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+
+```
+sudo apt-get install libpq-dev
+```
+
+And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+
+```json
+{
+  "name": "demo-subgraph",
+  "version": "0.1.0",
+  "scripts": {
+    "test": "graph test",
+    ...
+  },
+  "dependencies": {
+    "@graphprotocol/graph-cli": "^0.56.0",
+    "@graphprotocol/graph-ts": "^0.31.0",
+    "matchstick-as": "^0.6.0"
+  }
+}
+```
+
+### Using Matchstick
+
+To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+
+### CLI options
+
+This will run all tests in the test folder:
+
+```sh
+graph test
+```
+
+This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
+
+```sh
+graph test gravity
+```
+
+This will run only that specific test file:
+
+```sh
+graph test path/to/file.test.ts
+```
+
+**Options:**
+
+```sh
+-c, --coverage                Run the tests in coverage mode
+-d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
+-f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
+-h, --help                    Show usage information
+-l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
+-r, --recompile               Forces tests to be recompiled
+-v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+```
+
+### Docker
+
+From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+
+❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+
+❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+
+```sh
+  error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
+```
+
+In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+
+### Configuration
+
+Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+
+```yaml
+testsFolder: path/to/tests
+libsFolder: path/to/libs
+manifestPath: path/to/subgraph.yaml
+```
+
+### Demo subgraph
+
+You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+
+### Video tutorials
+
+Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+
+## Tests structure
+
+_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+
+### describe()
+
+`describe(name: String , () => {})` - Defines a test group.
+
+**_Notes:_**
+
+- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Gravatar entity", () => {
+    ...
+  })
+})
+```
+
+Nested `describe()` example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar } from "../../src/gravity"
+
+describe("handleUpdatedGravatar()", () => {
+  describe("When entity exists", () => {
+    test("updates the entity", () => {
+      ...
+    })
+  })
+
+  describe("When entity does not exists", () => {
+    test("it creates a new entity", () => {
+      ...
+    })
+  })
+})
+```
+
+---
+
+### test()
+
+`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+
+Example:
+
+```typescript
+import { describe, test } from "matchstick-as/assembly/index"
+import { handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar()", () => {
+  test("Should create a new Entity", () => {
+    ...
+  })
+})
+```
+
+or
+
+```typescript
+test("handleNewGravatar() should create a new entity", () => {
+  ...
+})
+
+
+```
+
+---
+
+### beforeAll()
+
+Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+
+Examples:
+
+Code inside `beforeAll` will execute once before _all_ tests in the file.
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+beforeAll(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+  ...
+})
+
+describe("When the entity does not exist", () => {
+  test("it should create a new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+
+describe("When entity already exists", () => {
+  test("it should update the Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `beforeAll` will execute once before all tests in the first describe block
+
+```typescript
+import { describe, test, beforeAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { Gravatar } from "../../generated/schema"
+
+describe("handleUpdatedGravatar()", () => {
+  beforeAll(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = “First Gravatar”
+    gravatar.save()
+    ...
+  })
+
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+
+  test("creates new Gravatar with id 0x1", () => {
+    ...
+  })
+})
+```
+
+---
+
+### afterAll()
+
+Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+
+Example:
+
+Code inside `afterAll` will execute once after _all_ tests in the file.
+
+```typescript
+import { describe, test, afterAll } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+import { store } from "@graphprotocol/graph-ts"
+
+afterAll(() => {
+  store.remove("Gravatar", "0x0")
+  ...
+})
+
+describe("handleNewGravatar, () => {
+  test("creates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+Code inside `afterAll` will execute once after all tests in the first describe block
+
+```typescript
+import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+	afterAll(() => {
+    store.remove("Gravatar", "0x1")
+    ...
+	})
+
+  test("It creates a new entity with Id 0x0", () => {
+    ...
+  })
+
+  test("It creates a new entity with Id 0x1", () => {
+    ...
+  })
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("updates Gravatar with id 0x0", () => {
+    ...
+  })
+})
+```
+
+---
+
+### beforeEach()
+
+Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+
+Examples: Code inside `beforeEach` will execute before each tests.
+
+```typescript
+import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
+import { handleNewGravatars } from "./utils"
+
+beforeEach(() => {
+  clearStore() // <-- clear the store before each test in the file
+})
+
+describe("handleNewGravatars, () => {
+  test("A test that requires a clean store", () => {
+    ...
+  })
+
+  test("Second that requires a clean store", () => {
+    ...
+  })
+})
+
+ ...
+```
+
+Code inside `beforeEach` will execute only before each test in the that describe
+
+```typescript
+import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
+import { handleUpdatedGravatar, handleNewGravatar } from '../../src/gravity'
+
+describe('handleUpdatedGravatars', () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar('0x0')
+    gravatar.displayName = 'First Gravatar'
+    gravatar.imageUrl = ''
+    gravatar.save()
+  })
+
+  test('Updates the displayName', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
+    store.remove('Gravatar', '0x0')
+  })
+
+  test('Updates the imageUrl', () => {
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
+    store.remove('Gravatar', '0x0')
+  })
+})
+```
+
+---
+
+### afterEach()
+
+Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+
+Examples:
+
+Code inside `afterEach` will execute after every test.
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+beforeEach(() => {
+  let gravatar = new Gravatar("0x0")
+  gravatar.displayName = “First Gravatar”
+  gravatar.save()
+})
+
+afterEach(() => {
+  store.remove("Gravatar", "0x0")
+})
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+Code inside `afterEach` will execute after each test in that describe
+
+```typescript
+import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
+import { handleUpdatedGravatar, handleNewGravatar } from "../../src/gravity"
+
+describe("handleNewGravatar", () => {
+  ...
+})
+
+describe("handleUpdatedGravatar", () => {
+  beforeEach(() => {
+    let gravatar = new Gravatar("0x0")
+    gravatar.displayName = "First Gravatar"
+    gravatar.imageUrl = ""
+    gravatar.save()
+  })
+
+  afterEach(() => {
+    store.remove("Gravatar", "0x0")
+  })
+
+  test("Updates the displayName", () => {
+     assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
+
+    // code that should update the displayName to 1st Gravatar
+
+    assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
+  })
+
+  test("Updates the imageUrl", () => {
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
+
+    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+
+    assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
+  })
+})
+```
+
+## Asserts
+
+```typescript
+fieldEquals(entityType: string, id: string, fieldName: string, expectedVal: string)
+
+equals(expected: ethereum.Value, actual: ethereum.Value)
+
+notInStore(entityType: string, id: string)
+
+addressEquals(address1: Address, address2: Address)
+
+bytesEquals(bytes1: Bytes, bytes2: Bytes)
+
+i32Equals(number1: i32, number2: i32)
+
+bigIntEquals(bigInt1: BigInt, bigInt2: BigInt)
+
+booleanEquals(bool1: boolean, bool2: boolean)
+
+stringEquals(string1: string, string2: string)
+
+arrayEquals(array1: Array<ethereum.Value>, array2: Array<ethereum.Value>)
+
+tupleEquals(tuple1: ethereum.Tuple, tuple2: ethereum.Tuple)
+
+assertTrue(value: boolean)
+
+assertNull<T>(value: T)
+
+assertNotNull<T>(value: T)
+
+entityCount(entityType: string, expectedCount: i32)
+```
+
+As of version 0.6.0, asserts support custom error messages as well
+
+```typescript
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
+assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
+assert.i32Equals(2, 2, 'I32 should equal 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
+assert.booleanEquals(true, true, 'Boolean should be true')
+assert.stringEquals('1', '1', 'String should equal 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.tupleEquals(
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
+  'Tuples should be equal',
+)
+assert.assertTrue(true, 'Should be true')
+assert.assertNull(null, 'Should be null')
+assert.assertNotNull('not null', 'Should be not null')
+assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.dataSourceExists(
+  'GraphTokenLockWallet',
+  Address.zero().toHexString(),
+  'GraphTokenLockWallet should have a data source for zero address',
+)
+```
+
+## Write a Unit Test
+
+Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+
+Assuming we have the following handler function (along with two helper functions to make our life easier):
+
+```typescript
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleNewGravatars(events: NewGravatar[]): void {
+  events.forEach((event) => {
+    handleNewGravatar(event)
+  })
+}
+
+export function createNewGravatarEvent(
+  id: i32,
+  ownerAddress: string,
+  displayName: string,
+  imageUrl: string,
+): NewGravatar {
+  let mockEvent = newMockEvent()
+  let newGravatarEvent = new NewGravatar(
+    mockEvent.address,
+    mockEvent.logIndex,
+    mockEvent.transactionLogIndex,
+    mockEvent.logType,
+    mockEvent.block,
+    mockEvent.transaction,
+    mockEvent.parameters,
+  )
+  newGravatarEvent.parameters = new Array()
+  let idParam = new ethereum.EventParam('id', ethereum.Value.fromI32(id))
+  let addressParam = new ethereum.EventParam(
+    'ownerAddress',
+    ethereum.Value.fromAddress(Address.fromString(ownerAddress)),
+  )
+  let displayNameParam = new ethereum.EventParam('displayName', ethereum.Value.fromString(displayName))
+  let imageUrlParam = new ethereum.EventParam('imageUrl', ethereum.Value.fromString(imageUrl))
+
+  newGravatarEvent.parameters.push(idParam)
+  newGravatarEvent.parameters.push(addressParam)
+  newGravatarEvent.parameters.push(displayNameParam)
+  newGravatarEvent.parameters.push(imageUrlParam)
+
+  return newGravatarEvent
+}
+```
+
+We first have to create a test file in our project. This is an example of how that might look like:
+
+```typescript
+import { clearStore, test, assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../../generated/schema'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
+
+test('Can call mappings with custom events', () => {
+  // Create a test entity and save it in the store as initial state (optional)
+  let gravatar = new Gravatar('gravatarId0')
+  gravatar.save()
+
+  // Create mock events
+  let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+  let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+  // Call mapping functions passing the events we just created
+  handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+
+  // Assert the state of the store
+  assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+  assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+  assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
+
+  // Clear the store in order to start the next test off on a clean slate
+  clearStore()
+})
+
+test('Next test', () => {
+  //...
+})
+```
+
+That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+
+- We're setting up our initial state and adding one custom Gravatar entity;
+- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
+- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- We assert the state of the store. How does that work? - We're passing a unique combination of Entity type and id. Then we check a specific field on that Entity and assert that it has the value we expect it to have. We're doing this both for the initial Gravatar Entity we added to the store, as well as the two Gravatar entities that gets added when the handler function is called;
+- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+
+There we go - we've created our first test! 👏
+
+Now in order to run our tests you simply need to run the following in your subgraph root folder:
+
+`graph test Gravity`
+
+And if all goes well you should be greeted with the following:
+
+![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+
+## Common test scenarios
+
+### Hydrating the store with a certain state
+
+Users are able to hydrate the store with a known set of entities. Here's an example to initialise the store with a Gravatar entity:
+
+```typescript
+let gravatar = new Gravatar('entryId')
+gravatar.save()
+```
+
+### Calling a mapping function with an event
+
+A user can create a custom event and pass it to a mapping function that is bound to the store:
+
+```typescript
+import { store } from 'matchstick-as/assembly/store'
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatar(newGravatarEvent)
+```
+
+### Calling all of the mappings with event fixtures
+
+Users can call the mappings with test fixtures.
+
+```typescript
+import { NewGravatar } from '../../generated/Gravity/Gravity'
+import { store } from 'matchstick-as/assembly/store'
+import { handleNewGravatars, createNewGravatarEvent } from './mapping'
+
+let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
+
+handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
+```
+
+```
+export function handleNewGravatars(events: NewGravatar[]): void {
+    events.forEach(event => {
+        handleNewGravatar(event);
+    });
+}
+```
+
+### Mocking contract calls
+
+Users can mock contract calls:
+
+```typescript
+import { addMetadata, assert, createMockedFunction, clearStore, test } from 'matchstick-as/assembly/index'
+import { Gravity } from '../../generated/Gravity/Gravity'
+import { Address, BigInt, ethereum } from '@graphprotocol/graph-ts'
+
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+let expectedResult = Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947')
+let bigIntParam = BigInt.fromString('1234')
+createMockedFunction(contractAddress, 'gravatarToOwner', 'gravatarToOwner(uint256):(address)')
+  .withArgs([ethereum.Value.fromSignedBigInt(bigIntParam)])
+  .returns([ethereum.Value.fromAddress(Address.fromString('0x90cBa2Bbb19ecc291A12066Fd8329D65FA1f1947'))])
+
+let gravity = Gravity.bind(contractAddress)
+let result = gravity.gravatarToOwner(bigIntParam)
+
+assert.equals(ethereum.Value.fromAddress(expectedResult), ethereum.Value.fromAddress(result))
+```
+
+As demonstrated, in order to mock a contract call and hardcore a return value, the user must provide a contract address, function name, function signature, an array of arguments, and of course - the return value.
+
+Users can also mock function reverts:
+
+```typescript
+let contractAddress = Address.fromString('0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
+createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(string,string)')
+  .withArgs([ethereum.Value.fromAddress(contractAddress)])
+  .reverts()
+```
+
+### Mocking IPFS files (from matchstick 0.4.1)
+
+Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+
+NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+
+`.test.ts` file:
+
+```typescript
+import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
+import { ipfs } from '@graphprotocol/graph-ts'
+import { gravatarFromIpfs } from './utils'
+
+// Export ipfs.map() callback in order for matchstck to detect it
+export { processGravatar } from './utils'
+
+test('ipfs.cat', () => {
+  mockIpfsFile('ipfsCatfileHash', 'tests/ipfs/cat.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  gravatarFromIpfs()
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 1)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'imageUrl', 'https://i.ytimg.com/vi/MELP46s8Cic/maxresdefault.jpg')
+
+  clearStore()
+})
+
+test('ipfs.map', () => {
+  mockIpfsFile('ipfsMapfileHash', 'tests/ipfs/map.json')
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 0)
+
+  ipfs.map('ipfsMapfileHash', 'processGravatar', Value.fromString('Gravatar'), ['json'])
+
+  assert.entityCount(GRAVATAR_ENTITY_TYPE, 3)
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '1', 'displayName', 'Gravatar1')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '2', 'displayName', 'Gravatar2')
+  assert.fieldEquals(GRAVATAR_ENTITY_TYPE, '3', 'displayName', 'Gravatar3')
+})
+```
+
+`utils.ts` file:
+
+```typescript
+import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
+import { Gravatar } from "../../generated/schema"
+
+...
+
+// ipfs.map callback
+export function processGravatar(value: JSONValue, userData: Value): void {
+  // See the JSONValue documentation for details on dealing
+  // with JSON values
+  let obj = value.toObject()
+  let id = obj.get('id')
+
+  if (!id) {
+    return
+  }
+
+  // Callbacks can also created entities
+  let gravatar = new Gravatar(id.toString())
+  gravatar.displayName = userData.toString() + id.toString()
+  gravatar.save()
+}
+
+// function that calls ipfs.cat
+export function gravatarFromIpfs(): void {
+  let rawData = ipfs.cat("ipfsCatfileHash")
+
+  if (!rawData) {
+    return
+  }
+
+  let jsonData = json.fromBytes(rawData as Bytes).toObject()
+
+  let id = jsonData.get('id')
+  let url = jsonData.get("imageUrl")
+
+  if (!id || !url) {
+    return
+  }
+
+  let gravatar = new Gravatar(id.toString())
+  gravatar.imageUrl = url.toString()
+  gravatar.save()
+}
+```
+
+### Asserting the state of the store
+
+Users are able to assert the final (or midway) state of the store through asserting entities. In order to do this, the user has to supply an Entity type, the specific ID of an Entity, a name of a field on that Entity, and the expected value of the field. Here's a quick example:
+
+```typescript
+import { assert } from 'matchstick-as/assembly/index'
+import { Gravatar } from '../generated/schema'
+
+let gravatar = new Gravatar('gravatarId0')
+gravatar.save()
+
+assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
+```
+
+Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+
+### Interacting with Event metadata
+
+Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+
+```typescript
+// Read
+let logType = newGravatarEvent.logType
+
+// Write
+let UPDATED_ADDRESS = '0xB16081F360e3847006dB660bae1c6d1b2e17eC2A'
+newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
+```
+
+### Asserting variable equality
+
+```typescript
+assert.equals(ethereum.Value.fromString("hello"); ethereum.Value.fromString("hello"));
+```
+
+### Asserting that an Entity is **not** in the store
+
+Users can assert that an entity does not exist in the store. The function takes an entity type and an id. If the entity is in fact in the store, the test will fail with a relevant error message. Here's a quick example of how to use this functionality:
+
+```typescript
+assert.notInStore('Gravatar', '23')
+```
+
+### Printing the whole store, or single entities from it (for debug purposes)
+
+You can print the whole store to the console using this helper function:
+
+```typescript
+import { logStore } from 'matchstick-as/assembly/store'
+
+logStore()
+```
+
+As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+
+```
+import { logEntity } from 'matchstick-as/assembly/store'
+
+
+logEntity("Gravatar", 23, true)
+```
+
+### Expected failure
+
+Users can have expected test failures, using the shouldFail flag on the test() functions:
+
+```typescript
+test(
+  'Should throw an error',
+  () => {
+    throw new Error()
+  },
+  true,
+)
+```
+
+If the test is marked with shouldFail = true but DOES NOT fail, that will show up as an error in the logs and the test block will fail. Also, if it's marked with shouldFail = false (the default state), the test executor will crash.
+
+### Logging
+
+Having custom logs in the unit tests is exactly the same as logging in the mappings. The difference is that the log object needs to be imported from matchstick-as rather than graph-ts. Here's a simple example with all non-critical log types:
+
+```typescript
+import { test } from "matchstick-as/assembly/index";
+import { log } from "matchstick-as/assembly/log";
+
+test("Success", () => {
+    log.success("Success!". []);
+});
+test("Error", () => {
+    log.error("Error :( ", []);
+});
+test("Debug", () => {
+    log.debug("Debugging...", []);
+});
+test("Info", () => {
+    log.info("Info!", []);
+});
+test("Warning", () => {
+    log.warning("Warning!", []);
+});
+```
+
+Users can also simulate a critical failure, like so:
+
+```typescript
+test('Blow everything up', () => {
+  log.critical('Boom!')
+})
+```
+
+Logging critical errors will stop the execution of the tests and blow everything up. After all - we want to make sure you're code doesn't have critical logs in deployment, and you should notice right away if that were to happen.
+
+### Testing derived fields
+
+Testing derived fields is a feature which allows users to set a field on a certain entity and have another entity be updated automatically if it derives one of its fields from the first entity.
+
+Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+
+```typescript
+let entity = ExampleEntity.load('id')
+let derivedEntity = entity.derived_entity
+```
+
+As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+
+```typescript
+test('Derived fields example test', () => {
+  let mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  let operatedAccount = GraphAccount.load('1')!
+  operatedAccount.operators = [mainAccount.id]
+  operatedAccount.save()
+
+  mockNameSignalTransaction('1234', mainAccount.id)
+  mockNameSignalTransaction('2', mainAccount.id)
+
+  mainAccount = GraphAccount.load('12')!
+
+  assert.assertNull(mainAccount.get('nameSignalTransactions'))
+  assert.assertNull(mainAccount.get('operatorOf'))
+
+  const nameSignalTransactions = mainAccount.nameSignalTransactions.load()
+  const operatorsOfMainAccount = mainAccount.operatorOf.load()
+
+  assert.i32Equals(2, nameSignalTransactions.length)
+  assert.i32Equals(1, operatorsOfMainAccount.length)
+
+  assert.stringEquals('1', operatorsOfMainAccount[0].id)
+
+  mockNameSignalTransaction('2345', mainAccount.id)
+
+  let nst = NameSignalTransaction.load('1234')!
+  nst.signer = '11'
+  nst.save()
+
+  store.remove('NameSignalTransaction', '2')
+
+  mainAccount = GraphAccount.load('12')!
+  assert.i32Equals(1, mainAccount.nameSignalTransactions.load().length)
+})
+```
+
+### Testing `loadInBlock`
+
+As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+
+```typescript
+import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
+import { Gravatar } from '../../generated/schema'
+
+describe('loadInBlock', () => {
+  beforeAll(() => {
+    mockInBlockStore('Gravatar', 'gravatarId0', gravatar)
+  })
+
+  afterAll(() => {
+    clearInBlockStore()
+  })
+
+  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+    let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
+    assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
+  })
+
+  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+    let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
+    assert.assertNull(retrievedGravatar)
+  })
+})
+```
+
+### Testing dynamic data sources
+
+Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+
+Example below:
+
+First we have the following event handler (which has been intentionally repurposed to showcase datasource mocking):
+
+```typescript
+export function handleApproveTokenDestinations(event: ApproveTokenDestinations): void {
+  let tokenLockWallet = TokenLockWallet.load(dataSource.address().toHexString())!
+  if (dataSource.network() == 'rinkeby') {
+    tokenLockWallet.tokenDestinationsApproved = true
+  }
+  let context = dataSource.context()
+  if (context.get('contextVal')!.toI32() > 0) {
+    tokenLockWallet.setBigInt('tokensReleased', BigInt.fromI32(context.get('contextVal')!.toI32()))
+  }
+  tokenLockWallet.save()
+}
+```
+
+And then we have the test using one of the methods in the dataSourceMock namespace to set a new return value for all of the dataSource functions:
+
+```typescript
+import { assert, test, newMockEvent, dataSourceMock } from 'matchstick-as/assembly/index'
+import { BigInt, DataSourceContext, Value } from '@graphprotocol/graph-ts'
+
+import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
+import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
+import { TokenLockWallet } from '../../generated/schema'
+
+test('Data source simple mocking example', () => {
+  let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
+  let address = Address.fromString(addressString)
+
+  let wallet = new TokenLockWallet(address.toHexString())
+  wallet.save()
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+  dataSourceMock.setReturnValues(addressString, 'rinkeby', context)
+  let event = changetype<ApproveTokenDestinations>(newMockEvent())
+
+  assert.assertTrue(!wallet.tokenDestinationsApproved)
+
+  handleApproveTokenDestinations(event)
+
+  wallet = TokenLockWallet.load(address.toHexString())!
+  assert.assertTrue(wallet.tokenDestinationsApproved)
+  assert.bigIntEquals(wallet.tokensReleased, BigInt.fromI32(325))
+
+  dataSourceMock.resetValues()
+})
+```
+
+Notice that dataSourceMock.resetValues() is called at the end. That's because the values are remembered when they are changed and need to be reset if you want to go back to the default values.
+
+### Testing dynamic data source creation
+
+As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+
+- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
+- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
+- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
+- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+
+#### Testing `ethereum/contract` templates
+
+```typescript
+test('ethereum/contract dataSource creation example', () => {
+  // Assert there are no dataSources created from GraphTokenLockWallet template
+  assert.dataSourceCount('GraphTokenLockWallet', 0)
+
+  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockWallet', 1)
+
+  // Add a second dataSource with context
+  let context = new DataSourceContext()
+  context.set('contextVal', Value.fromI32(325))
+
+  GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
+
+  // Assert there are now 2 dataSources
+  assert.dataSourceCount('GraphTokenLockWallet', 2)
+
+  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
+  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
+
+  logDataSources('GraphTokenLockWallet')
+})
+```
+
+##### Example `logDataSource` output
+
+```bash
+🛠  {
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2a": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2a",
+    "context": null
+  },
+  "0xa16081f360e3847006db660bae1c6d1b2e17ec2b": {
+    "kind": "ethereum/contract",
+    "name": "GraphTokenLockWallet",
+    "address": "0xa16081f360e3847006db660bae1c6d1b2e17ec2b",
+    "context": {
+      "contextVal": {
+        "type": "Int",
+        "data": 325
+      }
+    }
+  }
+}
+```
+
+#### Testing `file/ipfs` templates
+
+Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+
+##### Example `subgraph.yaml`
+
+```yaml
+...
+templates:
+ - kind: file/ipfs
+    name: GraphTokenLockMetadata
+    network: mainnet
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/token-lock-wallet.ts
+      handler: handleMetadata
+      entities:
+        - TokenLockMetadata
+      abis:
+        - name: GraphTokenLockWallet
+          file: ./abis/GraphTokenLockWallet.json
+```
+
+##### Example `schema.graphql`
+
+```graphql
+"""
+Token Lock Wallets which hold locked GRT
+"""
+type TokenLockMetadata @entity {
+  "The address of the token lock wallet"
+  id: ID!
+  "Start time of the release schedule"
+  startTime: BigInt!
+  "End time of the release schedule"
+  endTime: BigInt!
+  "Number of periods between start time and end time"
+  periods: BigInt!
+  "Time when the releases start"
+  releaseStartTime: BigInt!
+}
+```
+
+##### Example `metadata.json`
+
+```json
+{
+  "startTime": 1,
+  "endTime": 1,
+  "periods": 1,
+  "releaseStartTime": 1
+}
+```
+
+##### Example handler
+
+```typescript
+export function handleMetadata(content: Bytes): void {
+  // dataSource.stringParams() returns the File DataSource CID
+  // stringParam() will be mocked in the handler test
+  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+  let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
+  const value = json.fromBytes(content).toObject()
+
+  if (value) {
+    const startTime = value.get('startTime')
+    const endTime = value.get('endTime')
+    const periods = value.get('periods')
+    const releaseStartTime = value.get('releaseStartTime')
+
+    if (startTime && endTime && periods && releaseStartTime) {
+      tokenMetadata.startTime = startTime.toBigInt()
+      tokenMetadata.endTime = endTime.toBigInt()
+      tokenMetadata.periods = periods.toBigInt()
+      tokenMetadata.releaseStartTime = releaseStartTime.toBigInt()
+    }
+
+    tokenMetadata.save()
+  }
+}
+```
+
+##### Example test
+
+```typescript
+import { assert, test, dataSourceMock, readFile } from 'matchstick-as'
+import { Address, BigInt, Bytes, DataSourceContext, ipfs, json, store, Value } from '@graphprotocol/graph-ts'
+
+import { handleMetadata } from '../../src/token-lock-wallet'
+import { TokenLockMetadata } from '../../generated/schema'
+import { GraphTokenLockMetadata } from '../../generated/templates'
+
+test('file/ipfs dataSource creation example', () => {
+  // Generate the dataSource CID from the ipfsHash + ipfs path file
+  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+  const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
+  const CID = `${ipfshash}/example.json`
+
+  // Create a new dataSource using the generated CID
+  GraphTokenLockMetadata.create(CID)
+
+  // Assert the dataSource has been created
+  assert.dataSourceCount('GraphTokenLockMetadata', 1)
+  assert.dataSourceExists('GraphTokenLockMetadata', CID)
+  logDataSources('GraphTokenLockMetadata')
+
+  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
+  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
+  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  dataSourceMock.resetValues()
+  dataSourceMock.setAddress(CID)
+
+  // Now we need to generate the Bytes to pass to the dataSource handler
+  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+  const content = readFile(`path/to/metadata.json`)
+  handleMetadata(content)
+
+  // Now we will test if a TokenLockMetadata was created
+  const metadata = TokenLockMetadata.load(CID)
+
+  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+})
+```
+
+## Test Coverage
+
+Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+
+The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+
+### Prerequisites
+
+To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+
+#### Export your handlers
+
+In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+
+```typescript
+import { handleNewGravatar } from '../../src/gravity'
+```
+
+In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+
+```typescript
+export { handleNewGravatar }
+```
+
+### Usage
+
+Once that's all set up, to run the test coverage tool, simply run:
+
+```sh
+graph test -- -c
+```
+
+You could also add a custom `coverage` command to your `package.json` file, like so:
+
+```typescript
+ "scripts": {
+    /.../
+    "coverage": "graph test -- -c"
+  },
+```
+
+That will execute the coverage tool and you should see something like this in the terminal:
+
+```sh
+$ graph test -c
+Skipping download/install step because binary already exists at /Users/petko/work/demo-subgraph/node_modules/binary-install-raw/bin/0.4.0
+
+___  ___      _       _         _   _      _
+|  \/  |     | |     | |       | | (_)    | |
+| .  . | __ _| |_ ___| |__  ___| |_ _  ___| | __
+| |\/| |/ _` | __/ __| '_ \/ __| __| |/ __| |/ /
+| |  | | (_| | || (__| | | \__ \ |_| | (__|   <
+\_|  |_/\__,_|\__\___|_| |_|___/\__|_|\___|_|\_\
+
+Compiling...
+
+Running in coverage report mode.
+ ️
+Reading generated test modules... 🔎️
+
+Generating coverage report 📝
+
+Handlers for source 'Gravity':
+Handler 'handleNewGravatar' is tested.
+Handler 'handleUpdatedGravatar' is not tested.
+Handler 'handleCreateGravatar' is tested.
+Test coverage: 66.7% (2/3 handlers).
+
+Handlers for source 'GraphTokenLockWallet':
+Handler 'handleTokensReleased' is not tested.
+Handler 'handleTokensWithdrawn' is not tested.
+Handler 'handleTokensRevoked' is not tested.
+Handler 'handleManagerUpdated' is not tested.
+Handler 'handleApproveTokenDestinations' is not tested.
+Handler 'handleRevokeTokenDestinations' is not tested.
+Test coverage: 0.0% (0/6 handlers).
+
+Global test coverage: 22.2% (2/9 handlers).
+```
+
+### Test run time duration in the log output
+
+The log output includes the test run duration. Here's an example:
+
+`[Thu, 31 Mar 2022 13:54:54 +0300] Program executed in: 42.270ms.`
+
+## Common compiler errors
+
+> Critical: Could not create WasmInstance from valid module with context: unknown import: wasi_snapshot_preview1::fd_write has not been defined
+
+This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Block(defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultAddress, defaultAddressBytes, defaultAddressBytes, defaultAddressBytes, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(18,12)
+>
+> ERROR TS2554: Expected ? arguments, but got ?.
+>
+> return new ethereum.Transaction(defaultAddressBytes, defaultBigInt, defaultAddress, defaultAddress, defaultBigInt, defaultBigInt, defaultBigInt, defaultAddressBytes, defaultBigInt);
+>
+> in ~lib/matchstick-as/assembly/defaults.ts(24,12)
+
+The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+
+## Additional Resources
+
+For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+
+## Feedback
+
+If you have any questions, feedback, feature requests or just want to reach out, the best place would be The Graph Discord where we have a dedicated channel for Matchstick, called 🔥| unit-testing.

From 6f56f92e03c0c0bfa21a2d510c289cb482104c43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:49 -0500
Subject: [PATCH 0952/3820] New translations transferring-a-subgraph.mdx
 (Swahili)

---
 .../managing/transferring-a-subgraph.mdx      | 42 +++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/managing/transferring-a-subgraph.mdx

diff --git a/website/pages/sw/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/sw/subgraphs/developing/managing/transferring-a-subgraph.mdx
new file mode 100644
index 000000000000..0fc6632cbc40
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -0,0 +1,42 @@
+---
+title: Transferring a Subgraph
+---
+
+Subgraphs published to the decentralized network have an NFT minted to the address that published the subgraph. The NFT is based on a standard ERC721, which facilitates transfers between accounts on The Graph Network.
+
+## Reminders
+
+- Whoever owns the NFT controls the subgraph.
+- If the owner decides to sell or transfer the NFT, they will no longer be able to edit or update that subgraph on the network.
+- You can easily move control of a subgraph to a multi-sig.
+- A community member can create a subgraph on behalf of a DAO.
+
+## View Your Subgraph as an NFT
+
+To view your subgraph as an NFT, you can visit an NFT marketplace like **OpenSea**:
+
+```
+https://opensea.io/your-wallet-address
+```
+
+Or a wallet explorer like **Rainbow.me**:
+
+```
+https://rainbow.me/your-wallet-addres
+```
+
+## Step-by-Step
+
+To transfer ownership of a subgraph, do the following:
+
+1. Use the UI built into Subgraph Studio:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-1.png)
+
+2. Choose the address that you would like to transfer the subgraph to:
+
+   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+
+Optionally, you can also use the built-in UI of NFT marketplaces like OpenSea:
+
+![Subgraph Ownership Transfer from NFT marketplace](/img/subgraph-ownership-transfer-nft-marketplace.png)

From 09d7445d4f01ae928d754c46bfa19fb1b7847f0e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:50 -0500
Subject: [PATCH 0953/3820] New translations graphql-api.mdx (Swahili)

---
 .../sw/subgraphs/querying/graphql-api.mdx     | 432 ++++++++++++++++++
 1 file changed, 432 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/querying/graphql-api.mdx

diff --git a/website/pages/sw/subgraphs/querying/graphql-api.mdx b/website/pages/sw/subgraphs/querying/graphql-api.mdx
new file mode 100644
index 000000000000..2ffcb85e4019
--- /dev/null
+++ b/website/pages/sw/subgraphs/querying/graphql-api.mdx
@@ -0,0 +1,432 @@
+---
+title: GraphQL API
+---
+
+Learn about the GraphQL Query API used in The Graph.
+
+## What is GraphQL?
+
+[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Queries with GraphQL
+
+In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+
+> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+
+### Examples
+
+Query for a single `Token` entity defined in your schema:
+
+```graphql
+{
+  token(id: "1") {
+    id
+    owner
+  }
+}
+```
+
+> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+
+Query all `Token` entities:
+
+```graphql
+{
+  tokens {
+    id
+    owner
+  }
+}
+```
+
+### Sorting
+
+When querying a collection, you may:
+
+- Use the `orderBy` parameter to sort by a specific attribute.
+- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+
+#### Example
+
+```graphql
+{
+  tokens(orderBy: price, orderDirection: asc) {
+    id
+    owner
+  }
+}
+```
+
+#### Example for nested entity sorting
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+
+The following example shows tokens sorted by the name of their owner:
+
+```graphql
+{
+  tokens(orderBy: owner__name, orderDirection: asc) {
+    id
+    owner {
+      name
+    }
+  }
+}
+```
+
+> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+
+### Pagination
+
+When querying a collection, it's best to:
+
+- Use the `first` parameter to paginate from the beginning of the collection.
+  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
+- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
+- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+
+#### Example using `first`
+
+Query the first 10 tokens:
+
+```graphql
+{
+  tokens(first: 10) {
+    id
+    owner
+  }
+}
+```
+
+To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+
+#### Example using `first` and `skip`
+
+Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+
+```graphql
+{
+  tokens(first: 10, skip: 10) {
+    id
+    owner
+  }
+}
+```
+
+#### Example using `first` and `id_ge`
+
+If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+
+```graphql
+query manyTokens($lastID: String) {
+  tokens(first: 1000, where: { id_gt: $lastID }) {
+    id
+    owner
+  }
+}
+```
+
+The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+
+### Filtering
+
+- You can use the `where` parameter in your queries to filter for different properties.
+- You can filter on multiple values within the `where` parameter.
+
+#### Example using `where`
+
+Query challenges with `failed` outcome:
+
+```graphql
+{
+  challenges(where: { outcome: "failed" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+You can use suffixes like `_gt`, `_lte` for value comparison:
+
+#### Example for range filtering
+
+```graphql
+{
+  applications(where: { deposit_gt: "10000000000" }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for block filtering
+
+You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+
+This can be useful if you are looking to fetch only entities which have changed, for example since the last time you polled. Or alternatively it can be useful to investigate or debug how entities are changing in your subgraph (if combined with a block filter, you can isolate only entities that changed in a specific block).
+
+```graphql
+{
+  applications(where: { _change_block: { number_gte: 100 } }) {
+    id
+    whitelisted
+    deposit
+  }
+}
+```
+
+#### Example for nested entity filtering
+
+Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+
+This can be useful if you are looking to fetch only entities whose child-level entities meet the provided conditions.
+
+```graphql
+{
+  challenges(where: { application_: { id: 1 } }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+#### Logical operators
+
+As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+
+##### `AND` Operator
+
+The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { and: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+>
+> ```graphql
+> {
+>   challenges(where: { number_gte: 100, outcome: "succeeded" }) {
+>     challenger
+>     outcome
+>     application {
+>       id
+>     }
+>   }
+> }
+> ```
+
+##### `OR` Operator
+
+The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+
+```graphql
+{
+  challenges(where: { or: [{ number_gte: 100 }, { outcome: "succeeded" }] }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+
+#### All Filters
+
+Full list of parameter suffixes:
+
+```
+_
+_not
+_gt
+_lt
+_gte
+_lte
+_in
+_not_in
+_contains
+_contains_nocase
+_not_contains
+_not_contains_nocase
+_starts_with
+_starts_with_nocase
+_ends_with
+_ends_with_nocase
+_not_starts_with
+_not_starts_with_nocase
+_not_ends_with
+_not_ends_with_nocase
+```
+
+> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+
+In addition, the following global filters are available as part of `where` argument:
+
+```gr
+_change_block(number_gte: Int)
+```
+
+### Time-travel queries
+
+You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+
+The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+
+> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { number: 8000000 }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+
+#### Example
+
+```graphql
+{
+  challenges(block: { hash: "0x5a0b54d5dc17e0aadc383d2db43b0a0d3e029c4c" }) {
+    challenger
+    outcome
+    application {
+      id
+    }
+  }
+}
+```
+
+This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+
+### Fulltext Search Queries
+
+Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+
+Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+
+Fulltext search operators:
+
+| Symbol | Operator    | Description                                                                                                                          |
+| ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
+| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
+| `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
+
+#### Examples
+
+Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+
+```graphql
+{
+  blogSearch(text: "anarchism | crumpets") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+
+```graphql
+{
+  blogSearch(text: "decentralized <-> philosophy") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+Combine fulltext operators to make more complex filters. With a pretext search operator combined with a follow by this example query will match all blog entities with words that start with "lou" followed by "music".
+
+```graphql
+{
+  blogSearch(text: "lou:* <-> music") {
+    id
+    title
+    body
+    author
+  }
+}
+```
+
+### Validation
+
+Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+
+## Schema
+
+The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+
+GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+
+> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+
+### Entities
+
+All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+
+> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+
+### Subgraph Metadata
+
+All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+
+```graphQL
+{
+  _meta(block: { number: 123987 }) {
+    block {
+      number
+      hash
+      timestamp
+    }
+    deployment
+    hasIndexingErrors
+  }
+}
+```
+
+If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
+
+`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+
+`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+
+- hash: the hash of the block
+- number: the block number
+- timestamp: the timestamp of the block, if available (this is currently only available for subgraphs indexing EVM networks)
+
+`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block

From 1a0e9eba171ad465afe725052e2a2f6344292de0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:51 -0500
Subject: [PATCH 0954/3820] New translations python.mdx (Swahili)

---
 .../pages/sw/subgraphs/querying/python.mdx    | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/querying/python.mdx

diff --git a/website/pages/sw/subgraphs/querying/python.mdx b/website/pages/sw/subgraphs/querying/python.mdx
new file mode 100644
index 000000000000..c10d7a0e57ab
--- /dev/null
+++ b/website/pages/sw/subgraphs/querying/python.mdx
@@ -0,0 +1,56 @@
+---
+title: Query The Graph with Python and Subgrounds
+---
+
+Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+
+Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+
+## Getting Started
+
+Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+
+```bash
+pip install --upgrade subgrounds
+# or
+python -m pip install --upgrade subgrounds
+```
+
+Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+
+```python
+from subgrounds import Subgrounds
+
+sg = Subgrounds()
+
+# Load the subgraph
+aave_v2 = sg.load_subgraph(
+    "https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
+
+# Construct the query
+latest_markets = aave_v2.Query.markets(
+    orderBy=aave_v2.Market.totalValueLockedUSD,
+    orderDirection='desc',
+    first=5,
+)
+# Return query to a dataframe
+sg.query_df([
+    latest_markets.name,
+    latest_markets.totalValueLockedUSD,
+])
+```
+
+## Documentation
+
+Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+
+Since subgrounds has a large feature set to explore, here are some helpful starting places:
+
+- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+  - A good first step for how to build queries with subgrounds.
+- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+  - A gentle introduction to defining synthetic fields that transform data defined from the schema.
+- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+  - Learn how to level up your queries by parallelizing them.
+- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+  - A quick article on how to seamlessly save your data as CSVs for further analysis.

From d7a7f03282428a99852a072d92aa0a86737ebaf4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:16:52 -0500
Subject: [PATCH 0955/3820] New translations triggers.mdx (Swahili)

---
 website/pages/sw/substreams/sps/triggers.mdx | 37 ++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 website/pages/sw/substreams/sps/triggers.mdx

diff --git a/website/pages/sw/substreams/sps/triggers.mdx b/website/pages/sw/substreams/sps/triggers.mdx
new file mode 100644
index 000000000000..a923fe40ec78
--- /dev/null
+++ b/website/pages/sw/substreams/sps/triggers.mdx
@@ -0,0 +1,37 @@
+---
+title: Substreams Triggers
+---
+
+Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+
+> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+
+The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+
+```tsx
+export function handleTransactions(bytes: Uint8Array): void {
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
+  if (transactions.length == 0) {
+    log.info('No transactions found', [])
+    return
+  }
+
+  for (let i = 0; i < transactions.length; i++) {
+    // 2.
+    let transaction = transactions[i]
+
+    let entity = new Transaction(transaction.hash) // 3.
+    entity.from = transaction.from
+    entity.to = transaction.to
+    entity.save()
+  }
+}
+```
+
+Here's what you’re seeing in the `mappings.ts` file:
+
+1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
+2. Looping over the transactions
+3. Create a new subgraph entity for every transaction
+
+To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From c46584cb66c9f9880cdfdab20cfbc09ee56c0c2e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:16 -0500
Subject: [PATCH 0956/3820] New translations index.json (Romanian)

---
 website/pages/ro/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/index.json b/website/pages/ro/index.json
index 63c3c940c6fb..fc992f488ac4 100644
--- a/website/pages/ro/index.json
+++ b/website/pages/ro/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Începe",
+  "title": "Home",
   "intro": "Află mai multe despre The Graph, un protocol descentralizat pentru indexarea și interogarea datelor din blockchains.",
   "shortcuts": {
     "aboutTheGraph": {

From 1e4205272a62ab0e6504343f8d9ff773e46f33e5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:17 -0500
Subject: [PATCH 0957/3820] New translations index.json (French)

---
 website/pages/fr/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/index.json b/website/pages/fr/index.json
index dd7f5b249c72..09cee1e3aaa4 100644
--- a/website/pages/fr/index.json
+++ b/website/pages/fr/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Commencer",
+  "title": "Accueil",
   "intro": "Découvrez The Graph, un protocole décentralisé d'indexation et d'interrogation des données provenant des blockchains.",
   "shortcuts": {
     "aboutTheGraph": {

From 8805e5ee943eb3c33181ee8f4df86f6e095eae2e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:18 -0500
Subject: [PATCH 0958/3820] New translations index.json (Spanish)

---
 website/pages/es/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/index.json b/website/pages/es/index.json
index 0fd4bc82e691..b1b02555a927 100644
--- a/website/pages/es/index.json
+++ b/website/pages/es/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Comenzar",
+  "title": "Home",
   "intro": "Aprende más sobre The Graph, un protocolo descentralizado para indexar y consultar datos de las blockchains.",
   "shortcuts": {
     "aboutTheGraph": {

From 7d69ad5612d479fbf4b42220ad33c9e6d75a23a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:19 -0500
Subject: [PATCH 0959/3820] New translations index.json (Arabic)

---
 website/pages/ar/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/index.json b/website/pages/ar/index.json
index ef9526840c44..1847a8c18331 100644
--- a/website/pages/ar/index.json
+++ b/website/pages/ar/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "البدء",
+  "title": "Home",
   "intro": "تعرف على The Graph ، وهو بروتوكول لامركزي لفهرسة البيانات والاستعلام عنها من ال Blockchains.",
   "shortcuts": {
     "aboutTheGraph": {

From 970a190008af6d407d01ee6994733c344b39bfab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:20 -0500
Subject: [PATCH 0960/3820] New translations index.json (Czech)

---
 website/pages/cs/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/index.json b/website/pages/cs/index.json
index 4dd97a91d425..00fc53aaa9ac 100644
--- a/website/pages/cs/index.json
+++ b/website/pages/cs/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Začněte",
+  "title": "Domov",
   "intro": "Seznamte se s Grafu, decentralizovaným protokolem pro indexování a dotazování dat z blockchainů.",
   "shortcuts": {
     "aboutTheGraph": {

From 0d67682ad1bf5a2308c305932bda7db98c6f9e26 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:22 -0500
Subject: [PATCH 0961/3820] New translations index.json (German)

---
 website/pages/de/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/index.json b/website/pages/de/index.json
index a3d38b854804..7ccccdb30a4f 100644
--- a/website/pages/de/index.json
+++ b/website/pages/de/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Los geht’s",
+  "title": "Home",
   "intro": "Learn about The Graph, a decentralized protocol for indexing and querying data from blockchains.",
   "shortcuts": {
     "aboutTheGraph": {

From 4381f6bbdfd900dd98bbe9ccd55fc9ccdc583a02 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:23 -0500
Subject: [PATCH 0962/3820] New translations index.json (Italian)

---
 website/pages/it/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/index.json b/website/pages/it/index.json
index 10b8c6a7f7c2..d4e8a9d3684e 100644
--- a/website/pages/it/index.json
+++ b/website/pages/it/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Iniziare",
+  "title": "Home",
   "intro": "Learn about The Graph, a decentralized protocol for indexing and querying data from blockchains.",
   "shortcuts": {
     "aboutTheGraph": {

From 34f94b532afcdb1b1261fd2ff0206ec1f2b758fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:24 -0500
Subject: [PATCH 0963/3820] New translations index.json (Japanese)

---
 website/pages/ja/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/index.json b/website/pages/ja/index.json
index 7e8c957541eb..400e87ce65b8 100644
--- a/website/pages/ja/index.json
+++ b/website/pages/ja/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "始めましょう",
+  "title": "Home",
   "intro": "ブロックチェーンのデータにインデックスを付けたり、クエリを実行するための分散型プロトコル「The Graph」についてご紹介します。",
   "shortcuts": {
     "aboutTheGraph": {

From b8f55caa6d57391e72f3e37c697b51d2d30f1a0b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:25 -0500
Subject: [PATCH 0964/3820] New translations index.json (Korean)

---
 website/pages/ko/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/index.json b/website/pages/ko/index.json
index 7b5de0b796fd..b622b0198a5b 100644
--- a/website/pages/ko/index.json
+++ b/website/pages/ko/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Get Started",
+  "title": "Home",
   "intro": "Learn about The Graph, a decentralized protocol for indexing and querying data from blockchains.",
   "shortcuts": {
     "aboutTheGraph": {

From 767640baf141b1b0428f4f7dec92df7826e7760d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:26 -0500
Subject: [PATCH 0965/3820] New translations index.json (Dutch)

---
 website/pages/nl/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/index.json b/website/pages/nl/index.json
index 357c0bbf8d61..15beb05d6888 100644
--- a/website/pages/nl/index.json
+++ b/website/pages/nl/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Begin",
+  "title": "Start",
   "intro": "Leer over The Graph, een gedecentraliseerd protocol voor het indexen en opvragen van data op blockchains.",
   "shortcuts": {
     "aboutTheGraph": {

From 3a1cb3441329c7473ea27f071e5504d32d0cedf8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:27 -0500
Subject: [PATCH 0966/3820] New translations index.json (Polish)

---
 website/pages/pl/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/index.json b/website/pages/pl/index.json
index da068b79078f..4ce485567e17 100644
--- a/website/pages/pl/index.json
+++ b/website/pages/pl/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Jak zacząć?",
+  "title": "Home",
   "intro": "Dowiedz się więcej o The Graph - zdecentralizowanym protokole indeksującym dane sieci blockchain i umożliwiającym tworzenie zapytań.",
   "shortcuts": {
     "aboutTheGraph": {

From 225f9239c78757bc599960e6254526fffc101cfb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:28 -0500
Subject: [PATCH 0967/3820] New translations index.json (Portuguese)

---
 website/pages/pt/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/index.json b/website/pages/pt/index.json
index 9d8d3f9a08d4..30de91bbfd91 100644
--- a/website/pages/pt/index.json
+++ b/website/pages/pt/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Como Começar",
+  "title": "Início",
   "intro": "Aprenda sobre o The Graph, um protocolo descentralizado para a indexação e consulta de dados de blockchains.",
   "shortcuts": {
     "aboutTheGraph": {

From 424d73d07f3e31a250ed750e46151c0fd0aaedac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:29 -0500
Subject: [PATCH 0968/3820] New translations index.json (Russian)

---
 website/pages/ru/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/index.json b/website/pages/ru/index.json
index 6f0d6145cb32..96204ab2f890 100644
--- a/website/pages/ru/index.json
+++ b/website/pages/ru/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Начнем",
+  "title": "Главная страница",
   "intro": "Начни изучение протокола The Graph как распределенного протокола для индексации и обслуживания запросов данных из блокчейнов.",
   "shortcuts": {
     "aboutTheGraph": {

From 4240357b5891098cff2fc342bf01450e726a5fb7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:30 -0500
Subject: [PATCH 0969/3820] New translations index.json (Swedish)

---
 website/pages/sv/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/index.json b/website/pages/sv/index.json
index 9b056e8960c2..b01a6779cc0f 100644
--- a/website/pages/sv/index.json
+++ b/website/pages/sv/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Komma igång",
+  "title": "Home",
   "intro": "Lär dig om The Graph, ett decentraliserat protokoll för indexering och sökning av data från blockkedjor.",
   "shortcuts": {
     "aboutTheGraph": {

From 32cf4ee979c7e3ba37d74a77b629bd6817539c09 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:31 -0500
Subject: [PATCH 0970/3820] New translations index.json (Turkish)

---
 website/pages/tr/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/index.json b/website/pages/tr/index.json
index ef3649332398..fe87377eb4bd 100644
--- a/website/pages/tr/index.json
+++ b/website/pages/tr/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Başlayalım",
+  "title": "Ana sayfa",
   "intro": "Blok zincirlerinden verileri indekslemek ve sorgulamak için merkeziyetsiz bir protokol olan Graph Protokol hakkında bilgi edinin.",
   "shortcuts": {
     "aboutTheGraph": {

From 3c9e86fa83e4fea62f94b02aa3264b858c5534ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:32 -0500
Subject: [PATCH 0971/3820] New translations index.json (Ukrainian)

---
 website/pages/uk/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/index.json b/website/pages/uk/index.json
index 8ecfe9f81e56..4fc2b1a2e2f3 100644
--- a/website/pages/uk/index.json
+++ b/website/pages/uk/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Розпочати роботу",
+  "title": "Home",
   "intro": "Дізнайтеся про Graph - децентралізований протокол для індексації та запитів даних з блокчейнів.",
   "shortcuts": {
     "aboutTheGraph": {

From 6e22f71f586989923349a41bc7bb0d67a08dd145 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:33 -0500
Subject: [PATCH 0972/3820] New translations index.json (Chinese Simplified)

---
 website/pages/zh/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/index.json b/website/pages/zh/index.json
index 7be9a7ca1935..b3c96de26337 100644
--- a/website/pages/zh/index.json
+++ b/website/pages/zh/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "开始",
+  "title": "Home",
   "intro": "了解Graph，一个用于索引和查询区块链数据的去中心化的协议。",
   "shortcuts": {
     "aboutTheGraph": {

From d40e11713f81610dc6fed3477b546dc23d2cb496 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:34 -0500
Subject: [PATCH 0973/3820] New translations index.json (Urdu (Pakistan))

---
 website/pages/ur/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/index.json b/website/pages/ur/index.json
index 9065fe445b9a..61a6b34f23e2 100644
--- a/website/pages/ur/index.json
+++ b/website/pages/ur/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "شروع کریں",
+  "title": "Home",
   "intro": "گراف کے بارے میں جانیں، ایک ڈیسینٹرلائز پروٹوکول جو بلاک چینز سے ڈیٹا کو انڈیکس کرنے اور کیوری کرتا ہے.",
   "shortcuts": {
     "aboutTheGraph": {

From c4fb9f6517dc288395d9a17962b9d903a24f3265 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:35 -0500
Subject: [PATCH 0974/3820] New translations index.json (Vietnamese)

---
 website/pages/vi/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/index.json b/website/pages/vi/index.json
index 8d84655f79d8..5042349d170b 100644
--- a/website/pages/vi/index.json
+++ b/website/pages/vi/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Bắt đầu",
+  "title": "Home",
   "intro": "Tìm hiểu về The Graph một giao thức phi tập trung để lập chỉ mục và truy vấn dữ liệu từ các blockchain.",
   "shortcuts": {
     "aboutTheGraph": {

From fc0bb695d600459efa0825ad28ebb07dc853116b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:36 -0500
Subject: [PATCH 0975/3820] New translations index.json (Marathi)

---
 website/pages/mr/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/index.json b/website/pages/mr/index.json
index 5d50b71571c4..905d2da397f1 100644
--- a/website/pages/mr/index.json
+++ b/website/pages/mr/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "सुरु करूया",
+  "title": "Home",
   "intro": "द ग्राफ बद्दल जाणून घ्या, ब्लॉकचेन वरून डेटा अनुक्रमित करण्यासाठी आणि क्वेरी करण्यासाठी विकेंद्रित प्रोटोकॉल.",
   "shortcuts": {
     "aboutTheGraph": {

From a1bc21ecdcb32ad1ff15b16b8f56699083bbe79d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:37 -0500
Subject: [PATCH 0976/3820] New translations index.json (Hindi)

---
 website/pages/hi/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/index.json b/website/pages/hi/index.json
index 8b2ce2fa9a68..92b143b8bdf6 100644
--- a/website/pages/hi/index.json
+++ b/website/pages/hi/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "शुरू हो जाओ",
+  "title": "Home",
   "intro": "द ग्राफ के बारे में जानें, ब्लॉकचेन से डेटा को अनुक्रमित करने और क्वेरी करने के लिए एक विकेन्द्रीकृत प्रोटोकॉल।",
   "shortcuts": {
     "aboutTheGraph": {

From 23cf2fe27bae6f82cad62b3d45a71e8579646163 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:38 -0500
Subject: [PATCH 0977/3820] New translations index.json (Swahili)

---
 website/pages/sw/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/index.json b/website/pages/sw/index.json
index 7b5de0b796fd..b622b0198a5b 100644
--- a/website/pages/sw/index.json
+++ b/website/pages/sw/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Get Started",
+  "title": "Home",
   "intro": "Learn about The Graph, a decentralized protocol for indexing and querying data from blockchains.",
   "shortcuts": {
     "aboutTheGraph": {

From 8d69815ffaf638d6730e75002b55d0f1a3014b55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:51 -0500
Subject: [PATCH 0978/3820] New translations about.mdx (Romanian)

---
 website/pages/ro/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/about.mdx b/website/pages/ro/about.mdx
index ad19563a31d2..25c810045af0 100644
--- a/website/pages/ro/about.mdx
+++ b/website/pages/ro/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From ede6b0a3be7e5eba0b6d9f68df6ed117b0c5e128 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:52 -0500
Subject: [PATCH 0979/3820] New translations about.mdx (French)

---
 website/pages/fr/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/about.mdx b/website/pages/fr/about.mdx
index 36904a652bd4..0740a57e71c5 100644
--- a/website/pages/fr/about.mdx
+++ b/website/pages/fr/about.mdx
@@ -24,7 +24,7 @@ Dans le cas de l'exemple mentionné ci-dessus, Bored Ape Yacht Club, vous pouvez
 
 Il faudrait des **heures, voire des jours,** pour qu'une application décentralisée (dapp) fonctionnant dans un navigateur obtienne une réponse à ces questions simples.
 
-Une alternative serait de configurer votre propre serveur, de traiter les transactions, de les stocker dans une base de données et de créer une API pour interroger les données. Cependant, cette solution est [coûteuse en ressources](/network/benefits/), nécessite une maintenance constante, présente un point de défaillance unique et compromet d'importantes propriétés de securité essentiels à la décentralisation.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Les spécificités de la blockchain, comme la finalité des transactions, les réorganisations de chaîne et les blocs oncles (blocs rejetés lorsque deux blocs sont créés simultanément, ce qui entraîne l'omission d'un bloc de la blockchain.), ajoutent de la complexité au processus, rendant longue et conceptuellement difficile la récupération de résultats précis à partir des données de la blockchain.
 

From 8dcd5afdeb487b9216c67511ebcadfe1b5289987 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:53 -0500
Subject: [PATCH 0980/3820] New translations about.mdx (Spanish)

---
 website/pages/es/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/about.mdx b/website/pages/es/about.mdx
index 8b1a092a77b5..22dafa9785ad 100644
--- a/website/pages/es/about.mdx
+++ b/website/pages/es/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From c00899be109ba7ad0601204422440fa300426a13 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:54 -0500
Subject: [PATCH 0981/3820] New translations about.mdx (Arabic)

---
 website/pages/ar/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/about.mdx b/website/pages/ar/about.mdx
index 7660b0dfd54b..8005f34aef5f 100644
--- a/website/pages/ar/about.mdx
+++ b/website/pages/ar/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From fa9b15c218d53fe8df817eb36d3bb85177f7312b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:55 -0500
Subject: [PATCH 0982/3820] New translations about.mdx (Czech)

---
 website/pages/cs/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/about.mdx b/website/pages/cs/about.mdx
index e29bcf5fe650..256519660a73 100644
--- a/website/pages/cs/about.mdx
+++ b/website/pages/cs/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From d63d3f56ce5b560487c7339320be2cc2005779bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:56 -0500
Subject: [PATCH 0983/3820] New translations about.mdx (German)

---
 website/pages/de/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/about.mdx b/website/pages/de/about.mdx
index 8c088d6a53d1..1104aba75925 100644
--- a/website/pages/de/about.mdx
+++ b/website/pages/de/about.mdx
@@ -24,7 +24,7 @@ Im Fall des oben aufgeführten konkreten Beispiels, Bored Ape Yacht Club, könne
 
 Es würde **Stunden oder sogar Tage** dauern, bis eine dezentrale Anwendung (dapp), die in einem Browser läuft, eine Antwort auf diese einfachen Fragen erhält.
 
-Alternativ können Sie einen eigenen Server einrichten, die Transaktionen verarbeiten, sie in einer Datenbank speichern und einen API-Endpunkt zur Abfrage der Daten erstellen. Diese Option ist jedoch [Ressourcen-intensiv](/network/benefits/), muss gewartet werden, stellt einen Single Point of Failure dar und bricht wichtige Sicherheitseigenschaften, die für die Dezentralisierung erforderlich sind.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain-Eigenschaften wie Endgültigkeit, Umstrukturierung der Kette und nicht gesperrte Blöcke erhöhen die Komplexität des Prozesses und machen es zeitaufwändig und konzeptionell schwierig, genaue Abfrageergebnisse aus Blockchain-Daten zu erhalten.
 

From 79215c2a71d5259783375b5b75bacf551763cfbb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:57 -0500
Subject: [PATCH 0984/3820] New translations about.mdx (Italian)

---
 website/pages/it/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/about.mdx b/website/pages/it/about.mdx
index d1cfbfad3b82..3060784eac83 100644
--- a/website/pages/it/about.mdx
+++ b/website/pages/it/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From b0de3893f4d5d4af294d6e0b07e037a41104b726 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 13:59:59 -0500
Subject: [PATCH 0985/3820] New translations about.mdx (Japanese)

---
 website/pages/ja/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/about.mdx b/website/pages/ja/about.mdx
index db8864a69b0f..c867800369a3 100644
--- a/website/pages/ja/about.mdx
+++ b/website/pages/ja/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From 82ff6efa38b4a7f27f77ed143370570fac230b6a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:00 -0500
Subject: [PATCH 0986/3820] New translations about.mdx (Korean)

---
 website/pages/ko/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/about.mdx b/website/pages/ko/about.mdx
index 9c21bf00d08f..02b29895881f 100644
--- a/website/pages/ko/about.mdx
+++ b/website/pages/ko/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From 25656bf0419391d89eb919dcb426b9b3af0684b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:01 -0500
Subject: [PATCH 0987/3820] New translations about.mdx (Dutch)

---
 website/pages/nl/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/about.mdx b/website/pages/nl/about.mdx
index 641ff09b8d15..ab5a9033cdac 100644
--- a/website/pages/nl/about.mdx
+++ b/website/pages/nl/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From 837f040a9affc3579c0ebd3ec07f7327d57c56d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:02 -0500
Subject: [PATCH 0988/3820] New translations about.mdx (Polish)

---
 website/pages/pl/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/about.mdx b/website/pages/pl/about.mdx
index f669bb650fd6..199bc6a77400 100644
--- a/website/pages/pl/about.mdx
+++ b/website/pages/pl/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From 0c6226f9667e48147f1dc7e3d2f54e7edc40ade6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:04 -0500
Subject: [PATCH 0989/3820] New translations about.mdx (Portuguese)

---
 website/pages/pt/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/about.mdx b/website/pages/pt/about.mdx
index f244df9f2b9d..6603713efd91 100644
--- a/website/pages/pt/about.mdx
+++ b/website/pages/pt/about.mdx
@@ -24,7 +24,7 @@ No caso do exemplo listado acima, o Bored Ape Yacht Club, é possível realizar
 
 Levariam **horas, ou até mesmo dias**, para que um aplicativo descentralizado (dApp) executado em um navegador conseguisse uma resposta a estas questões simples.
 
-Como alternativa, haveria a opção de construir o seu próprio servidor, processar as transações, salvá-las num banco de dados, e construir um endpoint de API sobre tudo isso tudo para poder fazer o query dos dados. Porém, esta opção [consome muitos recursos](/network/benefits/), precisa de manutenção, apresenta um único ponto de falha, e quebra propriedades de segurança importantes obrigatórias para a descentralização.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Propriedades de blockchain, como finalidade, reorganizações de chain, ou blocos uncle, complicam ainda mais este processo, e não apenas o tornam longo e cansativo, mas dificultam conceitualmente a retirada de resultados precisos de queries dos dados da blockchain.
 

From cb7b7efc9c3a71769c73b163125086086030a4f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:05 -0500
Subject: [PATCH 0990/3820] New translations about.mdx (Russian)

---
 website/pages/ru/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/about.mdx b/website/pages/ru/about.mdx
index ed071feb2124..35f9c6efd933 100644
--- a/website/pages/ru/about.mdx
+++ b/website/pages/ru/about.mdx
@@ -24,7 +24,7 @@ The Graph — это мощный децентрализованный прот
 
 Децентрализованному приложению (dapp), запущенному в браузере, потребуются **часы или даже дни**, чтобы получить ответ на эти простые вопросы.
 
-В качестве альтернативы у Вас есть возможность настроить собственный сервер, обрабатывать транзакции, хранить их в базе данных и создать конечную точку API для запроса данных. Однако этот вариант [ресурсоемок](/network/benefits/), требует обслуживания, представляет собой единственную возможную причину сбоя и нарушает важные свойства безопасности, необходимые для децентрализации.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Такие свойства блокчейна, как окончательность, реорганизация чейна и необработанные блоки, усложняют процесс, делая получение точных результатов запроса из данных блокчейна трудоемким и концептуально сложным.
 

From c693280ad31691c66709517435e7568caff4cb61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:06 -0500
Subject: [PATCH 0991/3820] New translations about.mdx (Swedish)

---
 website/pages/sv/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/about.mdx b/website/pages/sv/about.mdx
index a819e0212c3b..90c63c0f036d 100644
--- a/website/pages/sv/about.mdx
+++ b/website/pages/sv/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From 8e28be1939aad4e8dd7df646b585f527fc748e2c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:08 -0500
Subject: [PATCH 0992/3820] New translations about.mdx (Turkish)

---
 website/pages/tr/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/about.mdx b/website/pages/tr/about.mdx
index eba9046c6f35..775696c41265 100644
--- a/website/pages/tr/about.mdx
+++ b/website/pages/tr/about.mdx
@@ -24,7 +24,7 @@ Yukarıda bahsedilen Bored Ape Yacht Club örneğinde, [sözleşmenin](https://e
 
 Bu basit sorulara yanıt almak, tarayıcıda çalışan bir merkeziyetsiz uygulama (dapp) için **saatler, hatta günler ** sürebilir.
 
-Alternatif olarak, kendi sunucunuzu kurup işlemleri işleyebilir, bunları bir veri tabanında depolayabilir ve veriyi sorgulamak için bir API uç noktası oluşturabilirsiniz. Ancak, bu seçenek [kaynak açısından maliyetli](/network/benefits/) olup sürekli bakım gerektirir, tek bir arıza noktası oluşturur ve merkeziyetsizliğin gerektirdiği önemli güvenlik özelliklerini ortadan kaldırır.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Finalite, zincir yeniden organizasyonu ve "uncle" bloklar gibi blokzinciri özellikleri, sürece karmaşıklık katar ve doğru sorgu sonuçlarını blokzinciri verilerinden elde etmeyi zaman alıcı hale getirip kavramsal olarak zorlaştırır.
 

From ba202ba539dc3d1b0d4ff42951e95d05e8056278 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:09 -0500
Subject: [PATCH 0993/3820] New translations about.mdx (Ukrainian)

---
 website/pages/uk/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/about.mdx b/website/pages/uk/about.mdx
index ebc3f6d6f360..7d346fa59854 100644
--- a/website/pages/uk/about.mdx
+++ b/website/pages/uk/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From 4e451b2365d8a66a2e9514d14de4b88404d8869a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:10 -0500
Subject: [PATCH 0994/3820] New translations about.mdx (Chinese Simplified)

---
 website/pages/zh/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/about.mdx b/website/pages/zh/about.mdx
index d057befe67cf..81c40b3d9f61 100644
--- a/website/pages/zh/about.mdx
+++ b/website/pages/zh/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From 834a8743bb072af0fe821c0e0cb2d8e74cf9e414 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:11 -0500
Subject: [PATCH 0995/3820] New translations about.mdx (Urdu (Pakistan))

---
 website/pages/ur/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/about.mdx b/website/pages/ur/about.mdx
index 9d53ba42d773..75dd5e34c6e0 100644
--- a/website/pages/ur/about.mdx
+++ b/website/pages/ur/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From 8efd4e105ccad06ba7467de23db819b9b1f7ed54 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:13 -0500
Subject: [PATCH 0996/3820] New translations about.mdx (Vietnamese)

---
 website/pages/vi/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/about.mdx b/website/pages/vi/about.mdx
index b45ddbbc5c39..917e7817b3a7 100644
--- a/website/pages/vi/about.mdx
+++ b/website/pages/vi/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From 8c1a69246556c14c13e1c5335fa5e20333adc0ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:14 -0500
Subject: [PATCH 0997/3820] New translations about.mdx (Marathi)

---
 website/pages/mr/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/about.mdx b/website/pages/mr/about.mdx
index d560ebcd179d..6ec630cd8e4e 100644
--- a/website/pages/mr/about.mdx
+++ b/website/pages/mr/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From 9d74ad61c5fdc943fe57dcdceea2794616ea1848 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:15 -0500
Subject: [PATCH 0998/3820] New translations about.mdx (Hindi)

---
 website/pages/hi/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/about.mdx b/website/pages/hi/about.mdx
index e2937886768f..1e99e4584845 100644
--- a/website/pages/hi/about.mdx
+++ b/website/pages/hi/about.mdx
@@ -24,7 +24,7 @@ The Graph एक शक्तिशाली विकेंद्रीकृ
 
 यह सरल सवालों का जवाब पाने में एक ब्राउज़र में चल रही एक विकेन्द्रीकृत एप्लिकेशन (dapp) को **घंटे या यहाँ तक कि दिन** लग सकते हैं।
 
-वैकल्पिक रूप से, आपके पास अपना स्वयं का सर्वर सेट अप करने, लेनदेन को प्रोसेस करने, उन्हें एक डेटाबेस में स्टोर करने, और डेटा को क्वेरी करने के लिए एक API एन्डपॉइंट बनाने का विकल्प है। हालांकि, यह विकल्प [संसाधन-संवेदनशील](/network/benefits/) है, रखरखाव की आवश्यकता होती है, एकल विफलता बिंदु प्रस्तुत करता है, और विकेंद्रीकरण के लिए आवश्यक महत्वपूर्ण सुरक्षा गुणों को तोड़ता है।
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 ब्लॉकचेन की विशेषताएँ, जैसे अंतिमता, चेन पुनर्गठन, और अंकल ब्लॉक्स, प्रक्रिया में जटिलता जोड़ती हैं, जिससे ब्लॉकचेन डेटा से सटीक क्वेरी परिणाम प्राप्त करना समय लेने वाला और अवधारणात्मक रूप से चुनौतीपूर्ण हो जाता है।
 

From bc855863243d25db8b473235f3cd151ef89cdec8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:00:16 -0500
Subject: [PATCH 0999/3820] New translations about.mdx (Swahili)

---
 website/pages/sw/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/about.mdx b/website/pages/sw/about.mdx
index 9c21bf00d08f..02b29895881f 100644
--- a/website/pages/sw/about.mdx
+++ b/website/pages/sw/about.mdx
@@ -24,7 +24,7 @@ In the case of the example listed above, Bored Ape Yacht Club, you can perform b
 
 It would take **hours or even days** for a decentralized application (dapp) running in a browser to get an answer to these simple questions.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/network/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
 
 Blockchain properties, such as finality, chain reorganizations, and uncled blocks, add complexity to the process, making it time-consuming and conceptually challenging to retrieve accurate query results from blockchain data.
 

From 465f83478c2a889643fc56d9f6cdbdca19cec404 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:13 -0500
Subject: [PATCH 1000/3820] New translations arbitrum-faq.mdx (Romanian)

---
 .../ro/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ro/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/ro/archived/arbitrum/arbitrum-faq.mdx b/website/pages/ro/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..562824e64e95
--- /dev/null
+++ b/website/pages/ro/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum FAQ
+---
+
+Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Upwards of 26x savings on gas fees
+
+- Faster transaction speed
+
+- Security inherited from Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+The Graph community decided to move forward with Arbitrum last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion.
+
+## What do I need to do to use The Graph on L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+To take advantage of using The Graph on L2, use this dropdown switcher to toggle between chains.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## As a subgraph developer, data consumer, Indexer, Curator, or Delegator, what do I need to do now?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Everything has been tested thoroughly, and a contingency plan is in place to ensure a safe and seamless transition. Details can be found [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational.
+
+## Billing on Arbitrum FAQs
+
+## What do I need to do about the GRT in my billing balance?
+
+Nothing! Your GRT has been securely migrated to Arbitrum and is being used to pay for queries as you read this.
+
+## How do I know my funds have migrated securely to Arbitrum?
+
+All GRT billing balances have already been successfully migrated to Arbitrum. You can view the billing contract on Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## How do I know the Arbitrum bridge is secure?
+
+The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
+
+## What do I need to do if I'm adding fresh GRT from my Ethereum mainnet wallet?
+
+Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 740d934aeae28b7c12e6c9e60b6660cc384597f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:15 -0500
Subject: [PATCH 1001/3820] New translations arbitrum-faq.mdx (French)

---
 .../fr/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/fr/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/fr/archived/arbitrum/arbitrum-faq.mdx b/website/pages/fr/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..6e037eab2211
--- /dev/null
+++ b/website/pages/fr/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: FAQ d'Arbitrum
+---
+
+Cliquez [ici] (#billing-on-arbitrum-faqs) si vous souhaitez passer à la FAQ sur la facturation Arbitrum.
+
+## Pourquoi The Graph a-t-il mis en place une solution L2 ?
+
+Grâce à la mise à l'échelle de The Graph sur la L2, les participants du réseau peuvent désormais bénéficier de ce qui suit :
+
+- Jusqu'à 26 fois plus d'économies sur les frais de gaz
+
+- Vitesse de transaction plus élevée
+
+- La sécurité héritée d'Ethereum
+
+La mise à l'échelle des contrats intelligents du protocole sur la L2 permet aux participants du réseau d'interagir plus fréquemment pour un coût réduit en termes de frais de gaz. Par exemple, les Indexeurs peuvent ouvrir et fermer des allocations plus fréquemment pour indexer un plus grand nombre de subgraphs. Les développeurs peuvent déployer et mettre à jour des subgraphs plus facilement, et les Déléguateurs peuvent déléguer des GRT plus fréquemment. Les Curateurs peuvent ajouter ou supprimer des signaux dans un plus grand nombre de subgraphs - des actions auparavant considérées comme trop coûteuses pour être effectuées fréquemment en raison des frais de gaz.
+
+La communauté Graph a décidé d'avancer avec Arbitrum l'année dernière après le résultat de la discussion [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305).
+
+## Que dois-je faire pour utiliser The Graph en L2 ?
+
+Le système de facturation de The Graph accepte le GRT sur Arbitrum, et les utilisateurs auront besoin d'ETH sur Arbitrum pour payer leurs frais de gaz. Bien que le protocole The Graph ait commencé sur Ethereum Mainnet, toute l'activité, y compris les contrats de facturation, est maintenant sur Arbitrum One.
+
+Par conséquent, pour payer les requêtes, vous avez besoin de GRT sur Arbitrum. Voici quelques façons d'y parvenir :
+
+- Si vous avez déjà des GRT sur Ethereum, vous pouvez les bridge vers Arbitrum. Vous pouvez le faire via l'option de bridge de GRT fournie dans Subgraph Studio ou en utilisant l'un des bridges suivants :
+
+  - [Le Bridge Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- Si vous avez d'autres actifs sur Arbitrum, vous pouvez les échanger contre du GRT via un protocole de swap comme Uniswap.
+
+- Alternativement, vous pouvez obtenir des GRT directement sur Arbitrum via un échangeur décentralisé.
+
+Une fois que vous avez des GRT sur Arbitrum, vous pouvez l'ajouter à votre solde de facturation.
+
+Pour tirer parti de l'utilisation de The Graph sur L2, utilisez ce sélecteur déroulant pour passer d'une chaîne à l'autre.
+
+[Sélecteur déroulant pour activer Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## En tant que développeur de subgraphs, consommateur de données, indexeur, curateur ou délégateur, que dois-je faire maintenant ?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+Toutes les récompenses d'indexation sont désormais entièrement sur Arbitrum.
+
+## Y avait-il des risques associés à la mise à l'échelle du réseau vers la L2 ?
+
+Tous les contrats intelligents ont été soigneusement [vérifiés](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-aud.pdf).
+
+Tout a été testé minutieusement et un plan d’urgence est en place pour assurer une transition sûre et fluide. Les détails peuvent être trouvés [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and- considérations de sécurité-20).
+
+## Les subgraphs existants sur Ethereum fonctionnent  t-ils?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## GRT a-t-il un nouveau contrat intelligent déployé sur Arbitrum ?
+
+Oui, GRT dispose d'un [contrat intelligent sur Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7) supplémentaire. Cependant, le réseau principal Ethereum [contrat GRT](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) restera opérationnel.
+
+## FAQ sur la facturation sur Arbitrum
+
+## Que dois-je faire à propos du GRT dans mon solde de facturation ?
+
+Rien! Votre GRT a été migré de manière sécurisée vers Arbitrum et est utilisé pour payer les requêtes au moment où vous lisez ceci.
+
+## Comment savoir si mes fonds ont migré en toute sécurité vers Arbitrum ?
+
+Tous les soldes de facturation GRT ont déjà été migrés avec succès vers Arbitrum. Vous pouvez afficher le contrat de facturation sur Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## Comment savoir si le pont Arbitrum est sécurisé ?
+
+Le pont a été [fortement audité](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) pour garantir la sécurité de tous les utilisateurs.
+
+## Que dois-je faire si j'ajoute du nouveau GRT depuis mon portefeuille du mainnet Ethereum ?
+
+L'ajout de GRT à votre solde de facturation Arbitrum peut être effectué en un seul clic dans [Subgraph Studio](https://thegraph.com/studio/). Vous pourrez facilement relier votre GRT à Arbitrum et remplir vos clés API en une seule transaction.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From d8f23f33c5d8d2f082a0efcb4dd6a7676d9a2fe8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:16 -0500
Subject: [PATCH 1002/3820] New translations arbitrum-faq.mdx (Spanish)

---
 .../es/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/es/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/es/archived/arbitrum/arbitrum-faq.mdx b/website/pages/es/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..85ad70c11ca2
--- /dev/null
+++ b/website/pages/es/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Preguntas frecuentes sobre Arbitrum
+---
+
+Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Upwards of 26x savings on gas fees
+
+- Mayor velocidad de transacción
+
+- Security inherited from Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+The Graph community decided to move forward with Arbitrum last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion.
+
+## ¿Qué debo hacer para usar The Graph en L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+Para aprovechar el uso de The Graph en L2, usa este conmutador desplegable para alternar entre cadenas.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## Como developer de subgrafos, consumidor de datos, Indexador, Curador o Delegador, ¿qué debo hacer ahora?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Everything has been tested thoroughly, and a contingency plan is in place to ensure a safe and seamless transition. Details can be found [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational.
+
+## Preguntas frecuentes sobre facturación en Arbitrum
+
+## ¿Qué debo hacer con el GRT en mi saldo de facturación?
+
+¡Nada! Tu GRT se ha migrado de forma segura a Arbitrum y se está utilizando para pagar consultas mientras lees esto.
+
+## ¿Cómo sé que mis fondos han migrado de forma segura a Arbitrum?
+
+All GRT billing balances have already been successfully migrated to Arbitrum. You can view the billing contract on Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## ¿Cómo sé que el bridge Arbitrum es seguro?
+
+The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
+
+## ¿Qué debo hacer si agrego GRT fresco de mi billetera mainnet de Ethereum?
+
+Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 94b565585d2572e9ebd34bb19adc64f2b67223b5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:17 -0500
Subject: [PATCH 1003/3820] New translations arbitrum-faq.mdx (Arabic)

---
 .../ar/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ar/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/ar/archived/arbitrum/arbitrum-faq.mdx b/website/pages/ar/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..898175b05cad
--- /dev/null
+++ b/website/pages/ar/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum FAQ
+---
+
+Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Upwards of 26x savings on gas fees
+
+- سرعة أكبر في المعاملات
+
+- Security inherited from Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+The Graph community decided to move forward with Arbitrum last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion.
+
+## What do I need to do to use The Graph on L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+To take advantage of using The Graph on L2, use this dropdown switcher to toggle between chains.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## As a subgraph developer, data consumer, Indexer, Curator, or Delegator, what do I need to do now?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Everything has been tested thoroughly, and a contingency plan is in place to ensure a safe and seamless transition. Details can be found [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational.
+
+## Billing on Arbitrum FAQs
+
+## What do I need to do about the GRT in my billing balance?
+
+Nothing! Your GRT has been securely migrated to Arbitrum and is being used to pay for queries as you read this.
+
+## How do I know my funds have migrated securely to Arbitrum?
+
+All GRT billing balances have already been successfully migrated to Arbitrum. You can view the billing contract on Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## How do I know the Arbitrum bridge is secure?
+
+The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
+
+## What do I need to do if I'm adding fresh GRT from my Ethereum mainnet wallet?
+
+Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 395c1d70b2e57ccc6ea9be93dfd14abbf18c5868 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:18 -0500
Subject: [PATCH 1004/3820] New translations arbitrum-faq.mdx (Czech)

---
 .../cs/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/cs/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/cs/archived/arbitrum/arbitrum-faq.mdx b/website/pages/cs/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..050d1a0641aa
--- /dev/null
+++ b/website/pages/cs/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum FAQ
+---
+
+Pokud chcete přejít na často ptal dotazy k účtování Arbitrum, klikněte na [here](#billing-on-arbitrum-faqs).
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Až 26x úspora na poplatcích za plyn
+
+- Rychlejší transakce
+
+- Zabezpečení zděděné po Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+Komunita Graf se v loňském roce rozhodla pokračovat v Arbitrum po výsledku diskuze [GIP-0031] (https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305).
+
+## Co musím udělat, abych mohl používat The Graph na serveru L2?
+
+Fakturační systém Graf přijímá GRT na Arbitrum a uživatelé budou potřebovat ETH na Arbitrum, aby mohli zaplatit za plyn. Zatímco protokol Graf začínal na Ethereum Mainnet, veškerá činnost, včetně smluv o vyúčtování, je nyní na Arbitrum One.
+
+Abyste mohli platit za dotazy, potřebujete GRT na Arbitrum. Zde je několik různých způsobů, jak toho dosáhnout:
+
+- Pokud již máte GRT na platformě Ethereum, můžete ji přemostit na Arbitrum. Můžete tak učinit pomocí možnosti přemostění GRT, která je k dispozici v podgraf Studio, nebo pomocí jednoho z následujících přemostění:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- Pokud máte na Arbitrum jiná aktiva, můžete je vyměnit za GRT prostřednictvím výměnného protokolu, jako je Uniswap.
+
+- Alternativně můžete GRT získat přímo na burze Arbitrum prostřednictvím decentralizované výměny.
+
+Jakmile máte GRT v Arbitrum, můžete jej přidat do svého fakturačního zůstatku.
+
+Pro využití výhod používání a Graf na L2 použijte rozevírací přepínač k přepínání mezi řetězci.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## Jako vývojář podgrafů, Spotřebitel dat, indexer, kurátor, nebo delegátor, co mám nyní udělat?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+Všechny chytré smlouvy byly důkladně [auditovány](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Vše bylo důkladně otestováno, a je připraven pohotovostní plán, který zajistí bezpečný a bezproblémový přechod. Podrobnosti naleznete [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Ano, GRT má další [smart contract na Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). Mainnetový [kontrakt GRT](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) na Ethereum však zůstane v provozu.
+
+## Billing on Arbitrum FAQs
+
+## Co je třeba udělat s GRT ve vyúčtování zůstatku?
+
+Nic! Váš GRT byl bezpečně převeden do společnosti Arbitrum a v době, kdy čtete tyto řádky, je používán k platit dotazů.
+
+## Jak poznám, že mé prostředky byly bezpečně převedeny do společnosti Arbitrum?
+
+Všechny zůstatky GRT byly úspěšně převedeny na Arbitrum. Zobrazit fakturační smlouvu na Arbitrum [here] (https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## Jak poznám, že je most Arbitrum bezpečný?
+
+Most byl [podroben důkladnému auditu](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest), aby byla zajištěna bezpečnost pro všechny uživatele.
+
+## Co musím udělat, když přidávám čerstvé GRT ze své peněženky v mainnetu Ethereum?
+
+Přidání GRT do vašeho zúčtovacího zůstatku Arbitrum lze provést jedním kliknutím v aplikaci [Subgraph Studio](https://thegraph.com/studio/). Budete moci snadno propojit své GRT s Arbitrum a vyplnit své klíče API v rámci jedné transakce.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 22ae9d4b430c27d851fe3262fa06293561e6d7f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:19 -0500
Subject: [PATCH 1005/3820] New translations arbitrum-faq.mdx (German)

---
 .../de/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/de/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/de/archived/arbitrum/arbitrum-faq.mdx b/website/pages/de/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..9ed1396ab31a
--- /dev/null
+++ b/website/pages/de/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum-FAQ
+---
+
+Klicken Sie [hier](#billing-on-arbitrum-faqs), wenn Sie zu den Arbitrum Billing FAQs springen möchten.
+
+## Warum hat The Graph eine L2-Lösung eingeführt?
+
+Durch die Skalierung von The Graph auf L2 können die Netzwerkteilnehmer nun von folgenden Vorteilen profitieren:
+
+- Bis zu 26-fache Einsparungen bei den Gebühren für Gas
+
+- Schnellere Transaktionsgeschwindigkeit
+
+- Von Ethereum übernommene Sicherheit
+
+Die Skalierung der Smart Contracts des Protokolls auf L2 ermöglicht den Netzwerkteilnehmern eine häufigere Interaktion zu geringeren Kosten in Form von Gasgebühren. So können Indexer beispielsweise häufiger Zuweisungen öffnen und schließen, um eine größere Anzahl von Subgraphen zu indexieren. Entwickler können Subgraphen leichter bereitstellen und aktualisieren, und Delegatoren können GRT häufiger delegieren. Kuratoren können einer größeren Anzahl von Subgraphen Signale hinzufügen oder entfernen - Aktionen, die bisher aufgrund der Kosten zu kostspielig waren, um sie häufig durchzuführen.
+
+Die The Graph-Community beschloss letztes Jahr nach dem Ergebnis der [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305)-Diskussion, mit Arbitrum weiterzumachen.
+
+## Was muss ich tun, um The Graph auf L2 zu nutzen?
+
+Das Abrechnungssystem von The Graph akzeptiert GRT auf Arbitrum, und die Nutzer benötigen ETH auf Arbitrum, um ihr Gas zu bezahlen. Während das The Graph-Protokoll auf dem Ethereum Mainnet begann, finden alle Aktivitäten, einschließlich der Abrechnungsverträge, nun auf Arbitrum One statt.
+
+Um Abfragen zu bezahlen brauchen Sie also GRT auf Arbitrum. Hier sind ein paar Möglichkeiten, dies zu erreichen:
+
+- Wenn Sie bereits GRT auf Ethereum haben, können Sie es zu Arbitrum überbrücken. Sie können dieses über GRT-Bridging-Option in Subgraph Studio tun oder eine der folgenden Bridges verwenden:
+
+  - [Die Arbitrum-Brücke] (https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- Wenn du andere Vermögenswerte auf Arbitrum hast, kannst du sie über ein Swapping-Protokoll wie Uniswap in GRT tauschen.
+
+- Alternativ können Sie GRT auch direkt auf Arbitrum über einen dezentralen Handelsplatz erwerben.
+
+Sobald Sie GRT auf Arbitrum haben, können Sie es zu Ihrem Guthaben hinzufügen.
+
+Um die Vorteile von The Graph auf L2 zu nutzen, verwenden Sie diesen Dropdown-Schalter, um zwischen den Ketten umzuschalten.
+
+![Dropdown-Schalter zum Aktivieren von Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## Was muss ich als Entwickler von Subgraphen, Datenkonsument, Indexer, Kurator oder Delegator jetzt tun?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+Alle Indexierungsprämien sind jetzt vollständig auf Arbitrum.
+
+## Sind mit der Skalierung des Netzes auf L2 irgendwelche Risiken verbunden?
+
+Alle Smart Contracts wurden gründlich [audited] (https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Alles wurde gründlich getestet, und es gibt einen Notfallplan, um einen sicheren und nahtlosen Übergang zu gewährleisten. Einzelheiten finden Sie [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Funktionieren die vorhandenen Subgraphen auf Ethereum?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Verfügt GRT über einen neuen Smart Contract, der auf Arbitrum eingesetzt wird?
+
+Ja, GRT hat einen zusätzlichen [Smart Contract auf Arbitrum] (https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). Der Ethereum-Hauptnetz-[GRT-Vertrag](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) wird jedoch weiterhin funktionieren.
+
+## Abrechnung auf Arbitrum FAQs
+
+## Was muss ich mit den GRT in meinem Rechnungssaldo tun?
+
+Nichts! Ihr GRT wurde sicher zu Arbitrum migriert und wird, während Sie dies lesen, zur Bezahlung von Abfragen verwendet.
+
+## Woher weiß ich, dass meine Guthaben sicher zu Arbitrum migriert sind?
+
+Alle GRT-Abrechnungssalden wurden bereits erfolgreich auf Arbitrum migriert. Sie können den Abrechnungsvertrag auf Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a) einsehen.
+
+## Woher weiß ich, dass die Arbitrum-Brücke sicher ist?
+
+Die Brücke wurde [umfangreich geprüft] (https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest), um die Sicherheit für alle Nutzer zu gewährleisten.
+
+## Was muss ich tun, wenn ich neue GRT von meiner Ethereum Mainnet Wallet hinzufüge?
+
+Das Hinzufügen von GRT zu Ihrem Arbitrum-Abrechnungssaldo kann mit nur einem Klick in [Subgraph Studio] (https://thegraph.com/studio/) erfolgen. Sie können Ihr GRT ganz einfach mit Arbitrum verbinden und Ihre API-Schlüssel in einer einzigen Transaktion füllen.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From ebc2a14f8ab14cf7bfbec8c2f82eae29ecffd098 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:20 -0500
Subject: [PATCH 1006/3820] New translations arbitrum-faq.mdx (Italian)

---
 .../it/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/it/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/it/archived/arbitrum/arbitrum-faq.mdx b/website/pages/it/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..4b6ef7df03fc
--- /dev/null
+++ b/website/pages/it/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum FAQ
+---
+
+Clicca [qui](#billing-on-arbitrum-faqs) se desideri saltare alle domande frequenti sulla fatturazione su Arbitrum.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Risparmi fino a 26 volte sulle commissioni di gas
+
+- Velocità di transazione più veloce
+
+- Sicurezza ereditata da Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+La comunità di The Graph ha deciso di procedere con Arbitrum l'anno scorso dopo l'esito della discussione [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305).
+
+## Cosa devo fare per utilizzare The Graph su L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+Per sfruttare l'utilizzo di The Graph su L2, utilizza il selettore a discesa per passare tra le chain.
+
+![Selettore a discesa per cambiare a Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## In quanto sviluppatore di subgraph, consumatore di dati, Indexer, Curator o Delegator, cosa devo fare ora?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Tutto è stato testato accuratamente e un piano di contingenza è in atto per garantire una transizione sicura e senza intoppi. I dettagli possono essere trovati [qui](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Sì, GRT avrà un nuovo [smart contract su Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). Tuttavia, il contratto principale [GRT](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) su Ethereum continuerà a essere operativo.
+
+## FAQ sulla fatturazione su Arbitrum
+
+## Cosa devo fare riguardo ai miei GRT nel mio saldo di fatturazione?
+
+Nulla! I tuoi GRT sono stati migrati in modo sicuro su Arbitrum e vengono utilizzati per pagare le query in questo istante.
+
+## Come posso essere certo che i miei fondi siano stati migrati in modo sicuro su Arbitrum?
+
+Tutti i saldi di fatturazione GRT sono stati già migrati con successo su Arbitrum. Puoi visualizzare il contratto di fatturazione su Arbitrum [qui](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## Come posso essere sicuro che il bridge di Arbitrum sia sicuro?
+
+Il bridge è stato rigorosamente sottoposto ad [audit](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) per garantire la sicurezza per tutti gli utenti.
+
+## Cosa devo fare se sto aggiungendo nuovi GRT dal mio wallet di Ethereum mainnet?
+
+Aggiungere GRT al tuo saldo di pagamento su Arbitrum può essere fatto con un solo click in [Subgraph Studio](https://thegraph.com/studio/). Sarai in grado di trasferire facilmente i tuoi GRT su Arbitrum e compilare le tue chiavi API in una sola transazione.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From f8102c259572da37d03b664c39601cde03ccb49f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:21 -0500
Subject: [PATCH 1007/3820] New translations arbitrum-faq.mdx (Japanese)

---
 .../ja/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ja/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/ja/archived/arbitrum/arbitrum-faq.mdx b/website/pages/ja/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..3ab2bdbbf83b
--- /dev/null
+++ b/website/pages/ja/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum FAQ
+---
+
+Arbitrum Billing FAQ にスキップしたい場合は[here](#billing-on-arbitrum-faqs) をクリックしてください。
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- ガス料金を 26 倍以上節約
+
+- 取引スピードの高速化
+
+- イーサリアムから継承したセキュリティ
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+Graph コミュニティは、[GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) の議論の結果を受けて、昨年 Arbitrum を進めることを決定しました。
+
+## The Graph on L2を利用するために必要なことは何ですか？
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+L2でのThe Graphの活用には、このドロップダウンスイッチャーを使用して、チェーンを切り替えてください。
+
+![Arbitrum を切り替えるドロップダウン スイッチャー](/img/arbitrum-screenshot-toggle.png)
+
+## サブグラフ開発者、データ消費者、インデクサー、キュレーター、デリゲーターは何をする必要がありますか？
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+すべてが徹底的にテストされており、安全かつシームレスな移行を保証するための緊急時対応計画が整備されています。詳細は[here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20)をご覧ください。
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+はい、GRT には追加の [Arbitrum 上のスマート コントラクト](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7) があります。ただし、イーサリアムのメインネット [GRT 契約](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) は引き続き運用されます。
+
+## Arbitrumでの課金に関するFAQ
+
+## 課金バランスのGRTについてはどうすればいいのでしょうか？
+
+何もない！？あなたのGRTはArbitrumに安全に移行され、あなたがこれを読んでいる間、クエリの支払いに使われているのです。
+
+## 自分の資金がArbitrumに安全に移行されたことを確認するにはどうすればよいですか？
+
+すべての GRT 請求残高はすでに Arbitrum に正常に移行されています。請求契約は Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a) でご覧いただけます。
+
+## Arbitrumブリッジの安全性を確認するにはどうすればよいですか？
+
+すべてのユーザーの安全とセキュリティを確保するために、ブリッジは [厳重な監査](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) を受けています。
+
+## イーサリアムメインネットのウォレットからGRTを追加する場合、何をする必要があるのでしょうか？
+
+Arbitrum 請求残高への GRT の追加は、[Subgraph Studio](https://thegraph.com/studio/) でワンクリックで行うことができます。 GRT を Arbitrum に簡単にブリッジし、1 回のトランザクションで API キーを入力できるようになります。
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 8520927c6b4f19706bdba302c5a25fa6bf9ee413 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:23 -0500
Subject: [PATCH 1008/3820] New translations arbitrum-faq.mdx (Korean)

---
 .../ko/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ko/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/ko/archived/arbitrum/arbitrum-faq.mdx b/website/pages/ko/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..562824e64e95
--- /dev/null
+++ b/website/pages/ko/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum FAQ
+---
+
+Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Upwards of 26x savings on gas fees
+
+- Faster transaction speed
+
+- Security inherited from Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+The Graph community decided to move forward with Arbitrum last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion.
+
+## What do I need to do to use The Graph on L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+To take advantage of using The Graph on L2, use this dropdown switcher to toggle between chains.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## As a subgraph developer, data consumer, Indexer, Curator, or Delegator, what do I need to do now?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Everything has been tested thoroughly, and a contingency plan is in place to ensure a safe and seamless transition. Details can be found [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational.
+
+## Billing on Arbitrum FAQs
+
+## What do I need to do about the GRT in my billing balance?
+
+Nothing! Your GRT has been securely migrated to Arbitrum and is being used to pay for queries as you read this.
+
+## How do I know my funds have migrated securely to Arbitrum?
+
+All GRT billing balances have already been successfully migrated to Arbitrum. You can view the billing contract on Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## How do I know the Arbitrum bridge is secure?
+
+The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
+
+## What do I need to do if I'm adding fresh GRT from my Ethereum mainnet wallet?
+
+Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 2d41ebc3d4e953c7eee9a73b8ac26c758be3dbeb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:24 -0500
Subject: [PATCH 1009/3820] New translations arbitrum-faq.mdx (Dutch)

---
 .../nl/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/nl/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/nl/archived/arbitrum/arbitrum-faq.mdx b/website/pages/nl/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..ee8b300ccb87
--- /dev/null
+++ b/website/pages/nl/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum FAQ
+---
+
+Klik [hier] (#billing-on-arbitrum-faqs) als je de Arbitrum facturering FAQ wilt overslaan.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Meer dan 26x besparen op gas fees
+
+- Snellere transactie snelheden
+
+- Veiligheid overgenomen van Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+The Graph gemeenschap heeft vorig jaar besloten om door te gaan met Arbitrum na de uitkomst van [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussie.
+
+## Wat moet ik doen om The Graph te gebruiken op L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+Om gebruik te maken van The Graph op L2, gebruik deze keuzeschakelaar om te wisselen tussen chains.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## Als een subgraph ontwikkelaar, data consument, Indexer, Curator, of Delegator, wat moet ik nu doen?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Alles is grondig getest, en een eventualiteiten plan is gemaakt en klaargezet voor een veilige en naadloze transitie. Details kunnen [hier](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20) gevonden worden.
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Ja, GRT heeft een extra [smart contract op Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). Echter, het Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) zal operationeel blijven.
+
+## Facturering op Arbitrum FAQs
+
+## Wat moet ik doen met de GRT in mijn facturerings balans?
+
+Niks! Jouw GRT is veilig naar Arbirtum gemigreerd en wordt gebruikt om voor queries te betalen terwijl jij dit aan het lezen bent.
+
+## Hoe weet ik dat mijn fondsen veilig zijn gemigreerd naar Arbitrum?
+
+Alle GRT-balansen zijn al veilig gemigreerd naar Arbitrum. Je kan de de facturering contracten [hier](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a) inzien.
+
+## Hoe weet ik dat de Arbitrum brug veilig is?
+
+De brug is [grondig ge-audit](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) om veiligheid en zekerheid voor alle gebruikers te garanderen.
+
+## Wat moet ik doen als ik verse GRT van mijn Ethereum mainnet wallet toevoeg?
+
+Het toevoegen van GRT aan je Arbitrum factuurbalans kan worden gedaan met een èèn klik ervaring in [Subgraph Studio](https://thegraph.com/studio/). Je kunt eenvoudig je GRT naar Arbitrum overzetten en je API-sleutels vullen in één transactie.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From d51c63b5a5c69ef1f74db554e3f410053df9a355 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:25 -0500
Subject: [PATCH 1010/3820] New translations arbitrum-faq.mdx (Polish)

---
 .../pl/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/pl/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/pl/archived/arbitrum/arbitrum-faq.mdx b/website/pages/pl/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..8e3f51fe99c9
--- /dev/null
+++ b/website/pages/pl/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum - najczęściej zadawane pytania
+---
+
+Kliknij [tutaj](#billing-on-Arbitrum-faqs), jeśli chcesz przejść do najczęściej zadawanych pytań dotyczących rozliczeń w sieci Arbitrum.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Ponad 26-krotną oszczędność na opłatach za gaz
+
+- Szybszą prędkość transakcji
+
+- Bezpieczeństwo jako spuścizna sieci Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+W zeszłym roku społeczność The Graph postanowiła pójść o krok do przodu z Arbitrum po wynikach dyskusji [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305).
+
+## Co należy zrobić by móc używać protokołu The Graph w L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [Przeniesienie do](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+By w pełni wykorzystać wszystkie zalety używania protokołu The Graph na L2 warto używać rozwijanej listy aby przełączać się między łańcuchami.
+
+![Przejście do listy zawierającej Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## Co powinien wiedzieć na ten temat subgraf developer, konsument danych, indekser, kurator lub delegator?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Wszystko zostało dokładnie przetestowane i przygotowano plan awaryjny, aby zapewnić bezpieczne i płynne przeniesienie. Szczegóły można znaleźć [tutaj](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Tak, GRT ma dodatkowy [smart kontrakt na Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). Jednak główna sieć Ethereum [kontrakt GRT](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) będzie nadal funkcjonować.
+
+## Najczęstsze pytania o: płatności w sieci Arbitrum
+
+## Co powinienem zrobić ze swoim saldem GRT w aktualnym rozliczeniu?
+
+Nie jest wymagana żadna akcja. Tokeny GRT zostały bezpiecznie zmigrowane do sieci Arbitrum i są używane do płatności za zapytania już teraz.
+
+## Skąd mam wiedzieć, czy moje środki zostały bezpiecznie zmigrowane do sieci Arbitrum?
+
+Wszystkie salda rozliczeniowe GRT zostały już pomyślnie przeniesione do Arbitrum. Możesz zobaczyć kontrakt rozliczeniowy na Arbitrum [tutaj] (https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## Skąd mam wiedzieć że używanie "Arbitrum bridge" jest bezpieczne?
+
+Most został poddany [szczegółowemu audytowi](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) w celu zapewnienia bezpieczeństwa wszystkim użytkownikom.
+
+## O czym muszę pamiętać dodając nowe tokeny GRT z mojego portfela Ethereum?
+
+Dodanie GRT do salda rozliczeniowego Arbitrum można wykonać jednym kliknięciem w [Subgraph Studio](https://thegraph.com/studio/). To właśnie tam można łatwo przenieść swoje GRT do Arbitrum i uzupełnić klucze API w jednej transakcji.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From ba33c0a127b90abb34103d519c73f216969ab059 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:26 -0500
Subject: [PATCH 1011/3820] New translations arbitrum-faq.mdx (Portuguese)

---
 .../pt/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/pt/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/pt/archived/arbitrum/arbitrum-faq.mdx b/website/pages/pt/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..9698a750905d
--- /dev/null
+++ b/website/pages/pt/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Perguntas Frequentes do Arbitrum
+---
+
+Clique [aqui](#billing-on-arbitrum-faqs) para pular até as Perguntas Frequentes de Cobranças no Arbitrum.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Poupar até 26x em taxas de gas
+
+- Fazer transações mais rápidas
+
+- Herdar segurança do Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+A comunidade do The Graph prosseguiu com o Arbitrum no ano passado, após o resultado da discussão [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305).
+
+## O que preciso fazer para usar o The Graph na L2?
+
+O sistema de cobranças do The Graph aceita GRT no Arbitrum, e utilizadores precisarão de ETH no Arbitrum para pagar pelo seu gas. O protocolo do The Graph começou na Mainnet do Ethereum, mas todas as atividades, que incluem os contratos de cobranças, agora se encontram no Arbitrum One.
+
+Portanto, para pagar por queries, é necessário GRT no Arbitrum. Aqui estão algumas maneiras diferentes de consegui-lo:
+
+- Caso já tenha GRT no Ethereum, é possível enviá-lo ao Arbitrum via bridge. Isto pode ser feito via a opção de bridging de GRT providenciada no Subgraph Studio ou uma das seguintes bridges:
+
+  - [Bridge no Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- Caso tenha outros ativos no Arbitrum, é possível trocá-los por GRT através de um protocolo de troca como o Uniswap.
+
+- Como alternativa, é possível adquirir GRT diretamente no Arbitrum via uma exchange descentralizada.
+
+Quando tiveres GRT no Arbitrum, será possível depositar o token no seu saldo de cobranças.
+
+Para aproveitar o The Graph na L2, use este switcher de dropdown para alternar entre chains.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## Como um programador, consumidor de dados, Indexador, Curador ou Delegante, o que devo fazer agora?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+Todos os contratos inteligentes já foram devidamente [auditados](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Tudo foi testado exaustivamente, e já está pronto um plano de contingência para garantir uma transição segura e suave. Mais detalhes [aqui](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Sim, o GRT tem um [contrato inteligente adicional no Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). Porém, o [contrato do GRT](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) na mainnet do Ethereum continuará em operação.
+
+## Perguntas Frequentes sobre Cobranças no Arbitrum
+
+## O que devo fazer sobre o GRT no meu saldo de cobrança?
+
+Nada! O seu GRT foi migrado ao Arbitrum com segurança e está em uso para pagar por queries enquanto lê isto.
+
+## Como sei que os meus fundos foram migrados ao Arbitrum com segurança?
+
+Todos os saldos de cobrança de GRT já foram migrados com êxito ao Arbitrum. Veja o contrato de cobrança no Arbitrum [aqui](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## Como sei que a bridge do Arbitrum é segura?
+
+O bridge foi [auditado rigorosamente](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) para garantir segurança para todos os utilizadores.
+
+## O que devo fazer se depositar GRT novo a partir da minha carteira da mainnet Ethereum?
+
+A adição de GRT ao seu saldo de cobrança no Arbitrum pode ser feito em apenas um clique no [Subgraph Studio](https://thegraph.com/studio/). Você poderá fazer o bridge do seu GRT ao Arbitrum com facilidade, e preencher as suas chaves de API em uma única transação.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 9825c95abfb9a45f9b78c8f5cd6c6a442b38ec79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:27 -0500
Subject: [PATCH 1012/3820] New translations arbitrum-faq.mdx (Russian)

---
 .../ru/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ru/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/ru/archived/arbitrum/arbitrum-faq.mdx b/website/pages/ru/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..0375e85a7135
--- /dev/null
+++ b/website/pages/ru/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Часто задаваемые вопросы об Arbitrum
+---
+
+Нажмите [here](#billing-on-arbitrum-faqs), если хотите перейти к часто задаваемым вопросам о выставлении счетов Arbitrum.
+
+## Почему The Graph внедрил решение L2?
+
+Масштабируя The Graph на L2, участники сети теперь могут получить следующие преимущества:
+
+- Экономию более чем в 26 раз на оплате газа
+
+- Более высокую скорость транзакций
+
+- Безопасность, унаследованную от Ethereum
+
+Масштабирование смарт-контрактов протокола на L2 позволяет участникам сети взаимодействовать чаще и с меньшими затратами на комиссии за газ. Например, Индексаторы могут чаще открывать и закрывать аллокации, чтобы индексировать большее количество субграфов. Разработчики могут с большей легкостью разворачивать и обновлять субграфы, а Делегаторы — чаще делегировать GRT. Кураторы могут добавлять или удалять сигнал для большего количества субграфов — действия, которые ранее считались слишком затратными для частого выполнения из-за стоимости газа.
+
+Решение о продолжении сотрудничества с Arbitrum было принято в прошлом году по итогам обсуждения сообществом The Graph [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305).
+
+## Что мне нужно сделать, чтобы использовать The Graph на L2?
+
+Платежная система The Graph принимает GRT на Arbitrum, и пользователям потребуется ETH на Arbitrum для оплаты газа. Хотя протокол The Graph изначально был запущен на основной сети Ethereum, вся активность, включая платежные контракты, теперь проходит на Arbitrum One.
+
+Поэтому для оплаты запросов Вам потребуется GRT на Arbitrum. Вот несколько способов, как это можно сделать:
+
+- Если у Вас уже есть GRT на Ethereum, Вы можете перенести его на Arbitrum. Вы можете сделать это через опцию переноса GRT, доступную в Subgraph Studio, или с помощью одного из следующих мостов:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- Если у Вас есть другие активы на Arbitrum, Вы можете обменять их на GRT с помощью протокола обмена, такого как Uniswap.
+
+- В качестве альтернативы, Вы можете приобрести GRT напрямую на Arbitrum через децентрализованную биржу.
+
+Как только у Вас появится GRT на Arbitrum, Вы сможете добавить его к своему платежному балансу.
+
+Чтобы воспользоваться преимуществами использования The Graph на L2, используйте этот выпадающий список для переключения между сетями.
+
+![Выпадающий список для переключения на Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## Что мне нужно делать сейчас как разработчику субграфа, потребителю данных, индексатору, куратору или делегатору?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+Все вознаграждения за индексацию теперь полностью находятся на Arbitrum.
+
+## Существуют ли какие-либо риски, связанные с масштабированием сети до L2?
+
+Все смарт-контракты прошли тщательный [аудит](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-cultural-bridge-audit.pdf).
+
+Все было тщательно протестировано, и разработан план действий на случай непредвиденных обстоятельств, чтобы обеспечить безопасный и непрерывный переход. Подробности можно найти [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Работают ли существующие субграфы на Ethereum?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Есть ли у GRT новый смарт-контракт, развернутый на Arbitrum?
+
+Да, у GRT есть дополнительный смарт-контракт [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). Тем не менее, [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) в основной сети Ethereum останется в рабочем состоянии.
+
+## Часто задаваемые вопросы о выставлении счетов на Arbitrum
+
+## Что мне нужно сделать с GRT на моем платежном балансе?
+
+Ничего! Ваш GRT был безопасно перенесен на Arbitrum и используется для оплаты запросов, пока Вы это читаете.
+
+## Как я узнаю, что мои средства безопасно перенесены на Arbitrum?
+
+Все балансы GRT для оплаты были успешно перенесены на Arbitrum. Вы можете просмотреть контракт об оплате на Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## Как я узнаю, что мост Arbitrum безопасен?
+
+Мост был тщательно проверен [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) для обеспечения безопасности всех пользователей.
+
+## Что мне нужно сделать, если я добавляю новый GRT из своего кошелька в основной сети Ethereum?
+
+Добавление GRT к Вашему балансу для оплаты на Arbitrum можно выполнить в один клик в [Subgraph Studio](https://thegraph.com/studio/). Вы сможете легко перенести свои GRT на Arbitrum и ввести свои API-ключи в одной транзакции.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 6bd3c171348de541a1328a55ff0173017566b1ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:28 -0500
Subject: [PATCH 1013/3820] New translations arbitrum-faq.mdx (Swedish)

---
 .../sv/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/sv/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/sv/archived/arbitrum/arbitrum-faq.mdx b/website/pages/sv/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..a3162cf19888
--- /dev/null
+++ b/website/pages/sv/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum Vanliga frågor
+---
+
+Klicka [here](#billing-on-arbitrum-faqs) om du vill hoppa till Arbitrum Billing Vanliga frågor.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Uppemot 26x besparingar på gasavgifter
+
+- Snabbare transaktionshastighet
+
+- Säkerhet ärvt från Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+Graph gemenskapen beslutade att gå vidare med Arbitrum förra året efter resultatet av diskussionen [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305).
+
+## Vad behöver jag göra för att använda The Graph på L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+För att dra fördel av att använda The Graph på L2, använd den här rullgardinsmenyn för att växla mellan kedjor.
+
+![Dropdown-väljare för att växla Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## Som subgrafutvecklare, datakonsument, indexerare, curator eller delegator, vad behöver jag göra nu?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Allt har testats noggrant och en beredskapsplan finns på plats för att säkerställa en säker och sömlös övergång. Detaljer finns [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Ja, GRT har ytterligare ett [smart kontrakt på Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). Ethereums huvudnät [GRT-kontrakt](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) kommer dock att fortsätta att fungera.
+
+## Fakturering på Arbitrum Vanliga frågor
+
+## Vad behöver jag göra med GRT i mitt faktureringssaldo?
+
+Ingenting! Din GRT har migrerats på ett säkert sätt till Arbitrum och används för att betala för frågor när du läser detta.
+
+## Hur vet jag att mina pengar har migrerats säkert till Arbitrum?
+
+Alla GRT faktureringssaldon har redan migrerats till Arbitrum. Du kan se faktureringsavtalet på Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## Hur vet jag att Arbitrum bron är säker?
+
+Bron har blivit [hårt granskad](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) för att garantera säkerhet och säkerhet för alla användare.
+
+## Vad behöver jag göra om jag lägger till färsk GRT från min Ethereum mainnet plånbok?
+
+Att lägga till GRT till ditt Arbitrum faktureringssaldo kan göras med ett klick i [Subgraf Studio](https://thegraph.com/studio/). Du kommer enkelt att kunna koppla din GRT till Arbitrum och fylla dina API nycklar i en transaktion.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 569c709b13b6efa8b634d688bc3f2ed5696a60b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:29 -0500
Subject: [PATCH 1014/3820] New translations arbitrum-faq.mdx (Turkish)

---
 .../tr/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/tr/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/tr/archived/arbitrum/arbitrum-faq.mdx b/website/pages/tr/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..63db1affd745
--- /dev/null
+++ b/website/pages/tr/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum Hakkında SSS
+---
+
+Arbitrum Faturalama SSS bölümüne geçmek istiyorsanız [buraya](#billing-on-arbitrum-faqs) tıklayın.
+
+## The Graph neden Katman 2 (L2) çözümü kullanıyor?
+
+Ağ katılımcıları, The Graph'i L2 üzerinde ölçeklendirerek şunlardan faydalanabilir:
+
+- Gas ücretlerinde 26 kata kadar tasarruf
+
+- Daha hızlı işlemler
+
+- Ethereum'dan aktarılmış güvenlik
+
+Protokol akıllı sözleşmelerini L2’ye ölçeklendirmek, ağ katılımcılarının daha düşük gas ücretleriyle daha sık etkileşimde bulunmasına olanak tanır. Örneğin, Endeksleyiciler daha fazla subgraph endekslemek için tahsisleri daha sık açıp kapatabilir. Geliştiriciler, subgraph’leri daha kolay bir şekilde dağıtabilir ve güncelleyebilir. Delegatörler, GRT’yi daha sık bir şekilde delege edebilir. Küratörler, daha fazla sayıda subgraph’e sinyal ekleyebilir veya kaldırabilir. Böylece önceden gas maliyetleri nedeniyle sık yapılması ekonomik olmayan işlemler artık mümkün hale gelir.
+
+Graph topluluğu, geçen yıl [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) tartışmasının sonucuna göre Arbitrum ile çalışmaya karar verdi.
+
+## Graph'ı Katman2'de kullanmak için ne yapmam gerekiyor?
+
+The Graph'in faturalandırma sistemi, Arbitrum ağı üzerinde GRT ile ödeme alır. Kullanıcıların gaz ücretlerini ödemek için Arbitrum üzerinde ETH'ye ihtiyaçları olacaktır. The Graph protokolü, başlangıçta Ethereum Mainnet üzerinde başlatılmış olsa da, faturalandırma sözleşmeleri de dahil olmak üzere tüm faaliyetler artık Arbitrum One üzerinde gerçekleştirilmektedir.
+
+Dolayısıyla, sorgu ödemelerini yapmak için Arbitrum üzerinde GRT'ye ihtiyacınız var. İşte GRT elde etmenin birkaç farklı yolu:
+
+- Ethereum üzerinde halihazırda GRT'leriniz varsa, bunları Arbitrum'a köprüleyebilirsiniz. Bu işlemi Subgraph Studio'da sunulan GRT köprüleme seçeneği aracılığıyla veya aşağıdaki köprülerden birini kullanarak yapabilirsiniz:
+
+  - [Arbitrum Köprüsü](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- Arbitrum üzerinde başka varlıklarınız varsa, Uniswap gibi bir takas protokolü aracılığıyla varlıklarınızı GRT ile takas edebilirsiniz.
+
+- Alternatif olarak, GRT'yi doğrudan Arbitrum üzerinde merkeziyetsiz bir borsa aracılığıyla edinebilirsiniz.
+
+GRT tutarınız Arbitrum'a ulaşınca faturalandırma bakiyenize ekleyebilirsiniz.
+
+Graph'ı Katman2'de kullanmanın avantajlarından yararlanmak için, zincirler arasında geçiş yapma noktasında bu açılır anahtarı kullanın.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## Bir subgraph geliştirici, veri tüketicisi, Endeksleyici, Küratör veya Delegatör olarak şimdi ne yapmalıyım?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+Tüm endeksleme ödülleri artık tamamen Arbitrum üzerindedir.
+
+## Ağı Katman 2'ye ölçeklendirmekle ilgili herhangi bir risk var mı?
+
+Tüm akıllı sözleşmeler kapsamlı bir şekilde [denetlenmiştir](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Güvenli ve sorunsuz bir geçiş sağlamak için her şey kapsamlı bir şekilde test edilmiş ve bir acil durum planı hazırlanmıştır. Ayrıntıları [burada](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20) bulabilirsiniz.
+
+## Ethereum üzerindeki mevcut subgraph'ler çalışıyor mu?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## GRT'nin Arbitrum'da yeni bir akıllı sözleşmesi mi var?
+
+Evet, GRT'nin Arbitrum üzerinde ek bir [akıllı sözleşmesi](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7) bulunmaktadır. Ancak, Ethereum ana ağında bulunan [GRT sözleşmesi](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) çalışmaya devam edecektir.
+
+## Arbitrum'da Faturalandırma SSS'leri
+
+## Faturalandırma bakiyemdeki GRT için ne yapmam gerekiyor?
+
+Hiçbir şey! GRT'niz güvenli bir şekilde Arbitrum'a taşındı ve bu satırları okuduğunuz sırada sorgular için kullanılmaktadır.
+
+## Fonlarımın güvenli bir şekilde Arbitrum'a taşındığını nasıl anlarım?
+
+Tüm GRT faturalandırma bakiyeleri Arbitrum'a başarıyla taşınmıştır. Arbitrum'daki faturalandırma sözleşmesini [buradan](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a) görüntüleyebilirsiniz.
+
+## Arbitrum köprüsünün güvenli olduğunu nasıl anlarım?
+
+Köprü, tüm kullanıcılar için emniyet ve güvenliği sağlamak amacıyla [kapsamlı bir şekilde denetlenmiştir](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest).
+
+## Ethereum ana ağ cüzdanımdan yeni GRT ekliyorsam ne yapmam gerekiyor?
+
+GRT'yi Arbitrum faturalandırma bakiyenize eklemek [Subgraph Stüdyo'da](https://thegraph.com/studio/) tek bir tık ile yapılabilir. GRT'nizi Arbitrum'a kolayca köprüleyebilecek ve API anahtarlarınızı tek bir işlemle doldurabileceksiniz.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From f9b3af6d7a444fea7f890ab035006a614296ec7c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:30 -0500
Subject: [PATCH 1015/3820] New translations arbitrum-faq.mdx (Ukrainian)

---
 .../uk/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/uk/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/uk/archived/arbitrum/arbitrum-faq.mdx b/website/pages/uk/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..28f6a3faeee6
--- /dev/null
+++ b/website/pages/uk/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Найбільш поширені запитання по Arbitrum
+---
+
+Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Upwards of 26x savings on gas fees
+
+- Набагато швидші транзакції
+
+- Security inherited from Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+The Graph community decided to move forward with Arbitrum last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion.
+
+## Що мені потрібно зробити, щоб використовувати The Graph на L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+Щоб скористатися перевагами The Graph на L2, використовуйте перемикач, який допомагає перемкнутись між різними мережами, ви бачите його на зображенні.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## Якщо я розробник підграфів, споживач даних, Індексатор, Куратор або Делегат, що мені потрібно робити зараз?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Everything has been tested thoroughly, and a contingency plan is in place to ensure a safe and seamless transition. Details can be found [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational.
+
+## Найбільш поширені запитання про білінг на Arbitrum
+
+## Що мені потрібно зробити з тими токенами GRT, які залишились на моєму платіжному балансі?
+
+Нічого! Ваш GRT був безпечно перенесений на Arbitrum і використовується для оплати запитів, в той час, коли ви читаєте цю статтю.
+
+## Як я можу переконатися, що мої кошти були надійно переведені на Arbitrum?
+
+All GRT billing balances have already been successfully migrated to Arbitrum. You can view the billing contract on Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## Звідки мені знати, чи міст Arbitrum є безпечним?
+
+The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
+
+## Що мені потрібно зробити, якщо я додаю нові токени GRT з мого криптогаманця в основній мережі Ethereum?
+
+Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 9d6d95b03e250f9e48b652190ef9b40c13d9b0fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:31 -0500
Subject: [PATCH 1016/3820] New translations arbitrum-faq.mdx (Chinese
 Simplified)

---
 .../zh/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/zh/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/zh/archived/arbitrum/arbitrum-faq.mdx b/website/pages/zh/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..1696ca24d7fe
--- /dev/null
+++ b/website/pages/zh/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum网络常见问题解答
+---
+
+如果您想跳到Arbitrum计费常见问题解答，请单击[here](#billing-on-arbitrum-faqs)。
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- 燃气费节省26倍以上
+
+- 更快的交易处理速度
+
+- 从以太坊继承的安全性
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+去年，The Graph社区在[GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) 讨论的结果之后，决定推进Arbitrum。
+
+## 我需要做什么才能在L2上使用Graph？
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+要使用L2上的Graph，请使用此下拉开关在链之间切换。
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## 作为子图开发人员、数据消费者、索引人、策展人或授权者，我现在需要做什么？
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+所有事项已经经过了彻底测试，并制定了应急计划，以确保安全和无缝过渡。详细信息可以在这里 [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20)找到。
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+是的，GRT在Arbitrum上有一个额外的智能合约[smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)。然而，以太坊主网上的GRT合约 [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)将继续保持运营。
+
+## Arbitrum账单常见问题解答
+
+## 我需要如何处理账单余额中的GRT？
+
+什么都不用做！您的GRT已安全迁移到Arbitrum，并用于支付您阅读本文时的查询费用。
+
+## 如何知道我的资金已安全转移到Arbitrum？
+
+所有GRT的计费余额已成功迁移到Arbitrum。您可以在Arbitrum上查看计费合约 [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a)。
+
+## 怎么知道Arbitrum 跨链桥是安全的？
+
+为确保所有用户的安全性和安全性，该跨链桥经过了严格的审计[heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest)。
+
+## 如果从以太坊主网钱包添加新的GRT，需要做什么？
+
+您可以通过在[Subgraph Studio](https://thegraph.com/studio/)中进行一键体验，将GRT添加到您的Arbitrum计费余额中。您将能够通过一笔交易轻松将您的GRT桥接到Arbitrum并填写您的API密钥。
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From f1e0735b97be1b66556768b5711cb32797f13b76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:32 -0500
Subject: [PATCH 1017/3820] New translations arbitrum-faq.mdx (Urdu (Pakistan))

---
 .../ur/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ur/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/ur/archived/arbitrum/arbitrum-faq.mdx b/website/pages/ur/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..c51d33e4e16c
--- /dev/null
+++ b/website/pages/ur/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: آربٹرم اکثر پوچھے گئے سوالات
+---
+
+[یہاں](#billing-on-arbitrum-faqs) کلک کریں اگر آپ Arbitrum بلنگ FAQs پر جانا چاہتے ہیں۔
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- گیس فیس پر 26 گنا زیادہ کی بچت
+
+- تیز تر ٹرانزیکشن کی رفتار
+
+- سیکیورٹی ایتھیریم سے وراثت میں ملی
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+گراف کمیونٹی نے [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) بحث کے نتائج کے بعد گزشتہ سال Arbitrum کے ساتھ آگے بڑھنے کا فیصلہ کیا۔
+
+## گراف کو L2 پر استعمال کرنے کے لیے مجھے کیا کرنے کی ضرورت ہے؟
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+L2 پر گراف استعمال کرنے کا فائدہ اٹھانے کے لیے، چینز کے درمیان ٹوگل کرنے کے لیے اس ڈراپ ڈاؤن سوئچر کا استعمال کریں.
+
+![Arbitrum کو ٹوگل کرنے کے لیے ڈراپ ڈاؤن سویچر](/img/arbitrum-screenshot-toggle.png)
+
+## بطور سب گراف ڈویلپر، ڈیٹا کنزیومر، انڈیکسر، کیوریٹر، یا ڈیلیگیٹر، مجھے اب کیا کرنے کی ضرورت ہے؟
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+ہر چیز کی اچھی طرح جانچ کی گئی ہے، اور ایک محفوظ اور ہموار منتقلی کو یقینی بنانے کے لیے ایک ہنگامی منصوبہ تیار کیا گیا ہے۔ تفصیلات دیکھی جا سکتی ہیں [یہاں](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+ہاں، GRT کے پاس ایک اضافی [Arbitrum پر سمارٹ کنٹریکٹ] (https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)۔ تاہم، ایتھیریم مین نیٹ [GRT کنٹریکٹ] (https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) کا کام جاری رہے گا۔
+
+## آربٹرم اکثر پوچھے گئے سوالات پر بلنگ
+
+## مجھے اپنے بلنگ بیلنس میں GRT کے بارے میں کیا کرنے کی ضرورت ہے?
+
+کچھ نہیں! آپ کے GRT کو محفوظ طریقے سے آربٹرم میں منتقل کر دیا گیا ہے اور اسے پڑھتے ہی کیوریز کی ادائیگی کے لیے استعمال کیا جا رہا ہے.
+
+## میں کیسے جان سکتا ہوں کہ میرے فنڈز محفوظ طریقے سے آربٹرم میں منتقل ہو گئے ہیں؟
+
+تمام GRT بلنگ بیلنس پہلے ہی کامیابی کے ساتھ Arbitrum میں منتقل ہو چکے ہیں۔ آپ Arbitrum پر بلنگ کنٹریکٹ دیکھ سکتے ہیں [یہاں](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## میں کیسے جان سکتا ہوں کہ آربٹرم بریج محفوظ ہے؟
+
+تمام صارفین کے لیے حفاظت اور تحفظ کو یقینی بنانے کے لیے اس بریج کو [بھاری طرح سے آڈٹ] (https://code4rena.com/contest/2022-10-the-graph-l2-bridge-contest) کیا گیا ہے۔
+
+## اگر میں اپنے ایتھیریم مینیٹ والیٹ سے تازہ GRT شامل کر رہا ہوں تو مجھے کیا کرنے کی ضرورت ہے؟
+
+اپنے Arbitrum بلنگ بیلنس میں GRT شامل کرنا [سب گراف سٹوڈیو](https://thegraph.com/studio/) میں ایک کلک کے تجربے کے ساتھ کیا جا سکتا ہے۔ آپ آسانی سے اپنے GRT کو Arbitrum سے بریج کر سکیں گے اور ایک ٹرانزیکشن میں اپنی API کیز کو بھر سکیں گے۔
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 2c7125f38cad598dcdf7d67adb0f861c1e4bbb49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:34 -0500
Subject: [PATCH 1018/3820] New translations arbitrum-faq.mdx (Vietnamese)

---
 .../vi/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/vi/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/vi/archived/arbitrum/arbitrum-faq.mdx b/website/pages/vi/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..562824e64e95
--- /dev/null
+++ b/website/pages/vi/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum FAQ
+---
+
+Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Upwards of 26x savings on gas fees
+
+- Faster transaction speed
+
+- Security inherited from Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+The Graph community decided to move forward with Arbitrum last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion.
+
+## What do I need to do to use The Graph on L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+To take advantage of using The Graph on L2, use this dropdown switcher to toggle between chains.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## As a subgraph developer, data consumer, Indexer, Curator, or Delegator, what do I need to do now?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Everything has been tested thoroughly, and a contingency plan is in place to ensure a safe and seamless transition. Details can be found [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational.
+
+## Billing on Arbitrum FAQs
+
+## What do I need to do about the GRT in my billing balance?
+
+Nothing! Your GRT has been securely migrated to Arbitrum and is being used to pay for queries as you read this.
+
+## How do I know my funds have migrated securely to Arbitrum?
+
+All GRT billing balances have already been successfully migrated to Arbitrum. You can view the billing contract on Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## How do I know the Arbitrum bridge is secure?
+
+The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
+
+## What do I need to do if I'm adding fresh GRT from my Ethereum mainnet wallet?
+
+Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 7f8ab2a451e83a1b6ca157b07f59c3c2185f8aec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:35 -0500
Subject: [PATCH 1019/3820] New translations arbitrum-faq.mdx (Marathi)

---
 .../mr/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/mr/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/mr/archived/arbitrum/arbitrum-faq.mdx b/website/pages/mr/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..562824e64e95
--- /dev/null
+++ b/website/pages/mr/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum FAQ
+---
+
+Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Upwards of 26x savings on gas fees
+
+- Faster transaction speed
+
+- Security inherited from Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+The Graph community decided to move forward with Arbitrum last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion.
+
+## What do I need to do to use The Graph on L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+To take advantage of using The Graph on L2, use this dropdown switcher to toggle between chains.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## As a subgraph developer, data consumer, Indexer, Curator, or Delegator, what do I need to do now?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Everything has been tested thoroughly, and a contingency plan is in place to ensure a safe and seamless transition. Details can be found [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational.
+
+## Billing on Arbitrum FAQs
+
+## What do I need to do about the GRT in my billing balance?
+
+Nothing! Your GRT has been securely migrated to Arbitrum and is being used to pay for queries as you read this.
+
+## How do I know my funds have migrated securely to Arbitrum?
+
+All GRT billing balances have already been successfully migrated to Arbitrum. You can view the billing contract on Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## How do I know the Arbitrum bridge is secure?
+
+The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
+
+## What do I need to do if I'm adding fresh GRT from my Ethereum mainnet wallet?
+
+Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 2c8596f9acf1ca273eb595e4207953552e35002e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:36 -0500
Subject: [PATCH 1020/3820] New translations arbitrum-faq.mdx (Hindi)

---
 .../hi/archived/arbitrum/arbitrum-faq.mdx     | 81 +++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/hi/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/hi/archived/arbitrum/arbitrum-faq.mdx b/website/pages/hi/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..3c96c3cd78e2
--- /dev/null
+++ b/website/pages/hi/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,81 @@
+---
+title: Arbitrum FAQ
+---
+
+Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs.
+
+## The Graph ने L2 समाधान को लागू करने का कारण क्या था?
+
+ L2 पर The Graph को स्केल करके, नेटवर्क के प्रतिभागी अब निम्नलिखित लाभ उठा सकते हैं:
+
+- Upwards of 26x savings on gas fees
+
+- Faster transaction speed
+
+- Security inherited from Ethereum
+
+L2 पर प्रोटोकॉल स्मार्ट कॉन्ट्रैक्ट्स को स्केल करने से नेटवर्क के प्रतिभागियों को गैस शुल्क में कमी के साथ अधिक बार इंटरैक्ट करने की अनुमति मिलती है। उदाहरण के लिए, Indexer अधिक बार आवंटन खोल और बंद कर सकते हैं ताकि अधिक सबग्राफ़ को इंडेक्स किया जा सके। डेवलपर्स सबग्राफ़ को अधिक आसानी से तैनात और अपडेट कर सकते हैं, और डेलीगेटर्स अधिक बार GRT को डेलीगेट कर सकते हैं। क्यूरेटर अधिक सबग्राफ़ में सिग्नल जोड़ या हटा सकते हैं—ऐसे कार्य जो पहले गैस की उच्च लागत के कारण अक्सर करना बहुत महंगा माना जाता था।
+
+The Graph community decided to move forward with Arbitrum last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion.
+
+## What do I need to do to use The Graph on L2?
+
+The Graph का बिलिंग सिस्टम Arbitrum पर GRT स्वीकार करता है, और उपयोगकर्ताओं को गैस के लिए Arbitrum पर ETHकी आवश्यकता होगी। जबकि The Graph प्रोटोकॉल Ethereum Mainnet पर शुरू हुआ था, अब सभी गतिविधियाँ, जिसमें बिलिंग कॉन्ट्रैक्ट्स शामिल हैं, Arbitrum One पर हैं।
+
+अत: क्वेरीज़ के लिए भुगतान करने के लिए, आपको Arbitrum पर GRT की आवश्यकता है। इसे प्राप्त करने के कुछ विभिन्न तरीके यहाँ दिए गए हैं:
+
+- यदि आपके पास पहले से Ethereum पर GRT है, तो आप इसे Arbitrum पर ब्रिज कर सकते हैं। आप इसे Subgraph Studio में उपलब्ध GRT ब्रिजिंग विकल्प के माध्यम से या निम्नलिखित में से किसी एक ब्रिज का उपयोग करके कर सकते हैं:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- यदि आपके पास Arbitrum पर अन्य संपत्तियाँ हैं, तो आप उन्हें Uniswap जैसे स्वैपिंग प्रोटोकॉल के माध्यम से GRT में स्वैप कर सकते हैं।
+
+- वैकल्पिक रूप से, आप Arbitrum पर सीधे एक विकेन्द्रीकृत एक्सचेंज के माध्यम से GRT प्राप्त कर सकते हैं।
+
+एक बार जब आपके पास Arbitrum पर GRT हो, तो आप इसे अपनी बिलिंग बैलेंस में जोड़ सकते हैं।
+
+To take advantage of using The Graph on L2, use this dropdown switcher to toggle between chains.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## Subgraph developer, data consumer, Indexer, Curator, or Delegator, के रूप में, मुझे अब क्या करने की आवश्यकता है?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+अब सभी इंडेक्सिंग पुरस्कार पूरी तरह से Arbitrum पर हैं।
+
+## क्या नेटवर्क को L2 पर स्केल करने से संबंधित कोई जोखिम थे?
+
+सभी स्मार्ट कॉन्ट्रैक्ट्स का पूरी तरह से परीक्षित किया गया है।
+(https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+हर चीज़ का पूरी तरह से परीक्षण किया गया है, और एक सुरक्षित और निर्बाध संक्रमण सुनिश्चित करने के लिए एक आकस्मिक योजना बनाई गई है। विवरण यहां पाया जा सकता है [here] (https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and- सुरक्षा-विचार-20).
+
+## क्या Ethereum पर मौजूद सबग्राफ़ काम कर रहे हैं?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## क्या GRT का एक नया स्मार्ट कॉन्ट्रैक्ट Arbitrum पर तैनात किया गया है?
+
+Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational.
+
+## Arbitrum पर बिलिंग FAQs
+
+## What do I need to do about the GRT in my billing balance?
+
+Nothing! Your GRT has been securely migrated to Arbitrum and is being used to pay for queries as you read this.
+
+## How do I know my funds have migrated securely to Arbitrum?
+
+सभी जीआरटी बिलिंग शेष पहले ही सफलतापूर्वक आर्बिट्रम में स्थानांतरित कर दिए गए हैं। आप आर्बिट्रम पर बिलिंग अनुबंध [यहां] [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a) देख सकते हैं।
+
+## How do I know the Arbitrum bridge is secure?
+
+The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
+
+## What do I need to do if I'm adding fresh GRT from my Ethereum mainnet wallet?
+
+आपके आर्बिट्रम बिलिंग बैलेंस में जीआरटी जोड़ना [सबग्राफ स्टूडियो] (https://thegraph.com/studio/) में एक-क्लिक अनुभव के साथ किया जा सकता है। आप आसानी से अपने जीआरटी को आर्बिट्रम से जोड़ सकेंगे और एक लेनदेन में अपनी एपीआई कुंजी भर सकेंगे।
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From 5e7e2e0d823c87e1a1076880ff94ad43c1666570 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:37 -0500
Subject: [PATCH 1021/3820] New translations arbitrum-faq.mdx (Swahili)

---
 .../sw/archived/arbitrum/arbitrum-faq.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/sw/archived/arbitrum/arbitrum-faq.mdx

diff --git a/website/pages/sw/archived/arbitrum/arbitrum-faq.mdx b/website/pages/sw/archived/arbitrum/arbitrum-faq.mdx
new file mode 100644
index 000000000000..562824e64e95
--- /dev/null
+++ b/website/pages/sw/archived/arbitrum/arbitrum-faq.mdx
@@ -0,0 +1,80 @@
+---
+title: Arbitrum FAQ
+---
+
+Click [here](#billing-on-arbitrum-faqs) if you would like to skip to the Arbitrum Billing FAQs.
+
+## Why did The Graph implement an L2 Solution?
+
+By scaling The Graph on L2, network participants can now benefit from:
+
+- Upwards of 26x savings on gas fees
+
+- Faster transaction speed
+
+- Security inherited from Ethereum
+
+Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
+
+The Graph community decided to move forward with Arbitrum last year after the outcome of the [GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) discussion.
+
+## What do I need to do to use The Graph on L2?
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+  - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+  - [TransferTo](https://transferto.xyz/swap)
+
+- If you have other assets on Arbitrum, you can swap them for GRT through a swapping protocol like Uniswap.
+
+- Alternatively, you can acquire GRT directly on Arbitrum through a decentralized exchange.
+
+Once you have GRT on Arbitrum, you can add it to your billing balance.
+
+To take advantage of using The Graph on L2, use this dropdown switcher to toggle between chains.
+
+![Dropdown switcher to toggle Arbitrum](/img/arbitrum-screenshot-toggle.png)
+
+## As a subgraph developer, data consumer, Indexer, Curator, or Delegator, what do I need to do now?
+
+Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+
+All indexing rewards are now entirely on Arbitrum.
+
+## Were there any risks associated with scaling the network to L2?
+
+All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
+
+Everything has been tested thoroughly, and a contingency plan is in place to ensure a safe and seamless transition. Details can be found [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20).
+
+## Are existing subgraphs on Ethereum working?
+
+All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+
+## Does GRT have a new smart contract deployed on Arbitrum?
+
+Yes, GRT has an additional [smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7). However, the Ethereum mainnet [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7) will remain operational.
+
+## Billing on Arbitrum FAQs
+
+## What do I need to do about the GRT in my billing balance?
+
+Nothing! Your GRT has been securely migrated to Arbitrum and is being used to pay for queries as you read this.
+
+## How do I know my funds have migrated securely to Arbitrum?
+
+All GRT billing balances have already been successfully migrated to Arbitrum. You can view the billing contract on Arbitrum [here](https://arbiscan.io/address/0x1B07D3344188908Fb6DEcEac381f3eE63C48477a).
+
+## How do I know the Arbitrum bridge is secure?
+
+The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest) to ensure safety and security for all users.
+
+## What do I need to do if I'm adding fresh GRT from my Ethereum mainnet wallet?
+
+Adding GRT to your Arbitrum billing balance can be done with a one-click experience in [Subgraph Studio](https://thegraph.com/studio/). You'll be able to easily bridge your GRT to Arbitrum and fill your API keys in one transaction.
+
+Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.

From f248721a5b5481f1f7c8e1cc5d119d94a683476a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:38 -0500
Subject: [PATCH 1022/3820] New translations l2-transfer-tools-faq.mdx
 (Romanian)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/ro/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/ro/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/ro/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..8e6da852a01c
--- /dev/null
+++ b/website/pages/ro/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2 Transfer Tools FAQ
+---
+
+## General
+
+### What are L2 Transfer Tools?
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### Can I use the same wallet I use on Ethereum mainnet?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### What happens if I don’t finish my transfer in 7 days?
+
+The L2 Transfer Tools use Arbitrum’s native mechanism to send messages from L1 to L2. This mechanism is called a “retryable ticket” and is used by all native token bridges, including the Arbitrum GRT bridge. You can read more about retryable tickets in the [Arbitrum docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+When you transfer your assets (subgraph, stake, delegation or curation) to L2, a message is sent through the Arbitrum GRT bridge which creates a retryable ticket in L2. The transfer tool includes some ETH value in the transaction, that is used to 1) pay to create the ticket and 2) pay for the gas to execute the ticket in L2. However, because gas prices might vary in the time until the ticket is ready to execute in L2, it is possible that this auto-execution attempt fails. When that happens, the Arbitrum bridge will keep the retryable ticket alive for up to 7 days, and anyone can retry “redeeming” the ticket (which requires a wallet with some ETH bridged to Arbitrum).
+
+This is what we call the “Confirm” step in all the transfer tools - it will run automatically in most cases, as the auto-execution is most often successful, but it is important that you check back to make sure it went through. If it doesn’t succeed and there are no successful retries in 7 days, the Arbitrum bridge will discard the ticket, and your assets (subgraph, stake, delegation or curation) will be lost and can’t be recovered. The Graph core devs have a monitoring system in place to detect these situations and try to redeem the tickets before it’s too late, but it is ultimately your responsibility to ensure your transfer is completed in time. If you’re having trouble confirming your transaction, please reach out using [this form](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) and core devs will be there help you.
+
+### I started my delegation/stake/curation transfer and I'm not sure if it made it through to L2, how can I confirm that it was transferred correctly?
+
+If you don't see a banner on your profile asking you to finish the transfer, then it's likely the transaction made it safely to L2 and no more action is needed. If in doubt, you can check if Explorer shows your delegation, stake or curation on Arbitrum One.
+
+If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire.
+
+## Subgraph Transfer
+
+### How do I transfer my subgraph?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+To transfer your subgraph, you will need to complete the following steps:
+
+1. Initiate the transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm subgraph transfer on Arbitrum\*
+
+4. Finish publishing subgraph on Arbitrum
+
+5. Update Query URL (recommended)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Where should I initiate my transfer from?
+
+You can initiate your transfer from the [Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) or any subgraph details page. Click the "Transfer Subgraph" button in the subgraph details page to start the transfer.
+
+### How long do I need to wait until my subgraph is transferred
+
+The transfer time takes approximately 20 minutes. The Arbitrum bridge is working in the background to complete the bridge transfer automatically. In some cases, gas costs may spike and you will need to confirm the transaction again.
+
+### Will my subgraph still be discoverable after I transfer it to L2?
+
+Your subgraph will only be discoverable on the network it is published to. For example, if your subgraph is on Arbitrum One, then you can only find it in Explorer on Arbitrum One and will not be able to find it on Ethereum. Please ensure that you have Arbitrum One selected in the network switcher at the top of the page to ensure you are on the correct network.  After the transfer, the L1 subgraph will appear as deprecated.
+
+### Does my subgraph need to be published to transfer it?
+
+To take advantage of the subgraph transfer tool, your subgraph must be already published to Ethereum mainnet and must have some curation signal owned by the wallet that owns the subgraph. If your subgraph is not published, it is recommended you simply publish directly on Arbitrum One - the associated gas fees will be considerably lower. If you want to transfer a published subgraph but the owner account hasn't curated any signal on it, you can signal a small amount (e.g. 1 GRT) from that account; make sure to choose "auto-migrating" signal.
+
+### What happens to the Ethereum mainnet version of my subgraph after I transfer to Arbitrum?
+
+After transferring your subgraph to Arbitrum, the Ethereum mainnet version will be deprecated. We recommend you update your query URL within 48 hours. However, there is a grace period in place that keeps your mainnet URL functioning so that any third-party dapp support can be updated.
+
+### After I transfer, do I also need to re-publish on Arbitrum?
+
+After the 20 minute transfer window, you will need to confirm the transfer with a transaction in the UI to finish the transfer, but the transfer tool will guide you through this. Your L1 endpoint will continue to be supported during the transfer window and a grace period after. It is encouraged that you update your endpoint when convenient for you.
+
+### Will my endpoint experience downtime while re-publishing?
+
+It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the subgraph on L1 and whether they keep indexing it until the subgraph is fully supported on L2.
+
+### Is publishing and versioning the same on L2 as Ethereum Ethereum mainnet?
+
+Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the subgraph.
+
+### Will my subgraph's curation move with my subgraph?
+
+If you've chosen auto-migrating signal, 100% of your own curation will move with your subgraph to Arbitrum One. All of the subgraph's curation signal will be converted to GRT at the time of the transfer, and the GRT corresponding to your curation signal will be used to mint signal on the L2 subgraph.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph.
+
+### Can I move my subgraph back to Ethereum mainnet after I transfer?
+
+Once transferred, your Ethereum mainnet version of this subgraph will be deprecated. If you would like to move back to mainnet, you will need to redeploy and publish back to mainnet. However, transferring back to Ethereum mainnet is strongly discouraged as indexing rewards will eventually be distributed entirely on Arbitrum One.
+
+### Why do I need bridged ETH to complete my transfer?
+
+Gas fees on Arbitrum One are paid using bridged ETH (i.e. ETH that has been bridged to Arbitrum One). However, the gas fees are significantly lower when compared to Ethereum mainnet.
+
+## Delegation
+
+### How do I transfer my delegation?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+To transfer your delegation, you will need to complete the following steps:
+
+1. Initiate delegation transfer on Ethereum mainnet
+2. Wait 20 minutes for confirmation
+3. Confirm delegation transfer on Arbitrum
+
+\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### What happens to my rewards if I initiate a transfer with an open allocation on Ethereum mainnet?
+
+If the Indexer to whom you're delegating is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer.
+
+### What happens if the Indexer I currently delegate to isn't on Arbitrum One?
+
+The L2 transfer tool will only be enabled if the Indexer you have delegated to has transferred their own stake to Arbitrum.
+
+### Do Delegators have the option to delegate to another Indexer?
+
+If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to.
+
+### What if I can't find the Indexer I'm delegating to on L2?
+
+The L2 transfer tool will automatically detect the Indexer you previously delegated to.
+
+### Will I be able to mix and match or 'spread' my delegation across new or several Indexers instead of the prior Indexer?
+
+The L2 transfer tool will always move your delegation to the same Indexer you delegated to previously. Once you have moved to L2, you can undelegate, wait for the thawing period, and decide if you'd like to split up your delegation.
+
+### Am I subject to the cooldown period or can I withdraw immediately after using the L2 delegation transfer tool?
+
+The transfer tool allows you to immediately move to L2. If you would like to undelegate you will have to wait for the thawing period. However, if an Indexer has transferred all of their stake to L2, you can withdraw on Ethereum mainnet immediately.
+
+### Can my rewards be negatively impacted if I do not transfer my delegation?
+
+It is anticipated that all network participation will move to Arbitrum One in the future.
+
+### How long does it take to complete the transfer of my delegation to L2?
+
+A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Can I transfer my delegation if I'm using a GRT vesting contract/token lock wallet?
+
+Yes! The process is a bit different because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the delegation to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### Is there any delegation tax?
+
+No. Received tokens on L2 are delegated to the specified Indexer on behalf of the specified Delegator without charging a delegation tax.
+
+### Will my unrealized rewards be transferred when I transfer my delegation?
+
+​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards.
+
+At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​
+
+### Is moving delegations to L2 mandatory? Is there a deadline?
+
+​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1?
+
+​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## Curation Signal
+
+### How do I transfer my curation?
+
+To transfer your curation, you will need to complete the following steps:
+
+1. Initiate signal transfer on Ethereum mainnet
+
+2. Specify an L2 Curator address\*
+
+3. Wait 20 minutes for confirmation
+
+\*If necessary - i.e. you are using a contract address.
+
+### How will I know if the subgraph I curated has moved to L2?
+
+When viewing the subgraph details page, a banner will notify you that this subgraph has been transferred. You can follow the prompt to transfer your curation. You can also find this information on the subgraph details page of any subgraph that has moved.
+
+### What if I do not wish to move my curation to L2?
+
+When a subgraph is deprecated you have the option to withdraw your signal. Similarly, if a subgraph has moved to L2, you can choose to withdraw your signal in Ethereum mainnet or send the signal to L2.
+
+### How do I know my curation successfully transferred?
+
+Signal details will be accessible via Explorer approximately 20 minutes after the L2 transfer tool is initiated.
+
+### Can I transfer my curation on more than one subgraph at a time?
+
+There is no bulk transfer option at this time.
+
+## Indexer Stake
+
+### How do I transfer my stake to Arbitrum?
+
+> Disclaimer: If you are currently unstaking any portion of your GRT on your Indexer, you will not be able to use L2 Transfer Tools.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+To transfer your stake, you will need to complete the following steps:
+
+1. Initiate stake transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm stake transfer on Arbitrum
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Will all of my stake transfer?
+
+You can choose how much of your stake to transfer. If you choose to transfer all of your stake at once, you will need to close any open allocations first.
+
+If you plan on transferring parts of your stake over multiple transactions, you must always specify the same beneficiary address.
+
+Note: You must meet the minimum stake requirements on L2 the first time you use the transfer tool. Indexers must send the minimum 100k GRT (when calling this function the first time). If leaving a portion of stake on L1, it must also be over the 100k GRT minimum and be sufficient (together with your delegations) to cover your open allocations.
+
+### How much time do I have to confirm my stake transfer to Arbitrum?
+
+\*\*\* You must confirm your transaction to complete the stake transfer on Arbitrum. This step must be completed within 7 days or stake could be lost.
+
+### What if I have open allocations?
+
+If you are not sending all of your stake, the L2 transfer tool will validate that at least the minimum 100k GRT remains in Ethereum mainnet and your remaining stake and delegation is enough to cover any open allocations. You may need to close open allocations if your GRT balance does not cover the minimums + open allocations.
+
+### Using the transfer tools, is it necessary to wait 28 days to unstake on Ethereum mainnet before transferring?
+
+No, you can transfer your stake to L2 immediately, there's no need to unstake and wait before using the transfer tool. The 28-day wait only applies if you'd like to withdraw the stake back to your wallet, on Ethereum mainnet or L2.
+
+### How long will it take to transfer my stake?
+
+It will take approximately 20 minutes for the L2 transfer tool to complete transferring your stake.
+
+### Do I have to index on Arbitrum before I transfer my stake?
+
+You can effectively transfer your stake first before setting up indexing, but you will not be able to claim any rewards on L2 until you allocate to subgraphs on L2, index them, and present POIs.
+
+### Can Delegators move their delegation before I move my indexing stake?
+
+No, in order for Delegators to transfer their delegated GRT to Arbitrum, the Indexer they are delegating to must be active on L2.
+
+### Can I transfer my stake if I'm using a GRT vesting contract / token lock wallet?
+
+Yes! The process is a bit different, because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the stake to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## Vesting Contract Transfer
+
+### How do I transfer my vesting contract?
+
+To transfer your vesting, you will need to complete the following steps:
+
+1. Initiate the vesting transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm vesting transfer on Arbitrum
+
+### How do I transfer my vesting contract if I am only partially vested?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount)
+
+2. Send some locked GRT through the transfer tool contract, to L2 to initialize the L2 vesting lock. This will also set their L2 beneficiary address.
+
+3. Send their stake/delegation to L2 through the "locked" transfer tool functions in the L1Staking contract.
+
+4. Withdraw any remaining ETH from the transfer tool contract
+
+### How do I transfer my vesting contract if I am fully vested?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+For those that are fully vested, the process is similar:
+
+1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount)
+
+2. Set your L2 address with a call to the transfer tool contract
+
+3. Send your stake/delegation to L2 through the "locked" transfer tool functions in the L1 Staking contract.
+
+4. Withdraw any remaining ETH from the transfer tool contract
+
+### Can I transfer my vesting contract to Arbitrum?
+
+You can transfer your vesting contract's GRT balance to a vesting contract in L2. This is a prerequisite for transferring stake or delegation from your vesting contract to L2. The vesting contract must hold a nonzero amount of GRT (you can transfer a small amount like 1 GRT to it if needed).
+
+When you transfer GRT from your L1 vesting contract to L2, you can choose the amount to send and you can do this as many times as you like. The L2 vesting contract will be initialized the first time you transfer GRT.
+
+The transfers are done using a Transfer Tool that will be visible on your Explorer profile when you connect with the vesting contract account.
+
+Please note that you will not be able to release/withdraw GRT from the L2 vesting contract until the end of your vesting timeline when your contract is fully vested. If you need to release GRT before then, you can transfer the GRT back to the L1 vesting contract using another transfer tool that is available for that purpose.
+
+If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2.
+
+### I'm using my vesting contract to stake on mainnet. Can I transfer my stake to Arbitrum?
+
+Yes, but if your contract is still vesting, you can only transfer the stake so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your stake to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas.
+
+### I'm using my vesting contract to delegate on mainnet. Can I transfer my delegations to Arbitrum?
+
+Yes, but if your contract is still vesting, you can only transfer the delegation so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your delegation to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas.
+
+### Can I specify a different beneficiary for my vesting contract on L2?
+
+Yes, the first time you transfer a balance and set up your L2 vesting contract, you can specify an L2 beneficiary. Make sure this beneficiary is a wallet that can perform transactions on Arbitrum One, i.e. it must be an EOA or a multisig deployed to Arbitrum One.
+
+If your contract is fully vested, you will not set up a vesting contract on L2; instead, you will set an L2 wallet address and this will be the receiving wallet for your stake or delegation on Arbitrum.
+
+### My contract is fully vested. Can I transfer my stake or delegation to another address that is not an L2 vesting contract?
+
+Yes. If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2.
+
+This allows you to transfer your stake or delegation to any L2 address.
+
+### My vesting contract is still vesting. How do I transfer my vesting contract balance to L2?
+
+These steps only apply if your contract is still vesting, or if you've used this process before when your contract was still vesting.
+
+To transfer your vesting contract to L2, you will send any GRT balance to L2 using the transfer tools, which will initialize your L2 vesting contract:
+
+1. Deposit some ETH into the transfer tool contract (this will be used to pay for L2 gas)
+
+2. Revoke protocol access to the vesting contract (needed for the next step)
+
+3. Give protocol access to the vesting contract (will allow your contract to interact with the transfer tool)
+
+4. Specify an L2 beneficiary address\* and initiate the balance transfer on Ethereum mainnet
+
+5. Wait 20 minutes for confirmation
+
+6. Confirm the balance transfer on L2
+
+\*If necessary - i.e. you are using a contract address.
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### Can I move my vesting contract back to L1?
+
+There is no need to do so because your vesting contract is still in L1. When you use the transfer tools, you just create a new contract in L2 that is connected with your L1 vesting contract, and you can send GRT back and forth between the two.
+
+### Why do I need to move my vesting contract to begin with?
+
+You need to set up an L2 vesting contract so that this account can own your stake or delegation on L2. Otherwise, there'd be no way for you to transfer the stake/delegation to L2 without "escaping" the vesting contract.
+
+### What happens if I try to cash out my contract when it is only partially vested? Is this possible?
+
+This is not a possibility. You can move funds back to L1 and withdraw them there.
+
+### What if I don't want to move my vesting contract to L2?
+
+You can keep staking/delegating on L1. Over time, you may want to consider moving to L2 to enable rewards there as the protocol scales on Arbitrum. Note that these transfer tools are for vesting contracts that are allowed to stake and delegate in the protocol. If your contract does not allow staking or delegating, or is revocable, then there is no transfer tool available. You will still be able to withdraw your GRT from L1 when available.

From 17df5c8b044b20ce0a9c6bc9705db103ae7b3423 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:39 -0500
Subject: [PATCH 1023/3820] New translations l2-transfer-tools-faq.mdx (French)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 413 ++++++++++++++++++
 1 file changed, 413 insertions(+)
 create mode 100644 website/pages/fr/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/fr/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/fr/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..893bfcaf2b89
--- /dev/null
+++ b/website/pages/fr/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,413 @@
+---
+title: FAQ sur les outils de transfert L2
+---
+
+## Général
+
+### Que sont les outils de transfert L2 ?
+
+The Graph a rendu la participation au réseau 26 fois moins chère pour les contributeurs en déployant le protocole sur Arbitrum One. Les outils de transfert L2 ont été créés par les développeurs du noyau pour faciliter le passage à L2.
+
+Pour chaque participant au réseau, un ensemble d'outils de transfert L2 est disponible pour rendre l'expérience transparente lors du passage à L2, en évitant les périodes de dégel ou d'avoir à retirer manuellement et à ponter les TRG.
+
+Ces outils vous obligeront à suivre un ensemble d'étapes spécifiques en fonction de votre rôle au sein de The Graph et de ce que vous transférez vers L2.
+
+### Puis-je utiliser le même portefeuille que celui que j'utilise sur le réseau principal Ethereum ?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Les portefeuilles sur les blockchains EVM comme Ethereum et Arbitrum sont une paire de clés (publiques et privées) que vous créez sans avoir besoin d'interagir avec la blockchain. Ainsi, tout portefeuille créé pour Ethereum fonctionnera également sur Arbitrum sans action supplémentaire.
+
+Une exception concerne les portefeuilles de smart contracts comme les multisigs : ces smart contrats sont déployés séparément sur chaque chaîne, et obtiennent leur adresse une fois déployés. Si un multisig a été déployé sur Ethereum, il n'existera pas avec la même adresse sur Arbitrum. Un nouveau multisig doit d'abord être créé sur Arbitrum, et aura une adresse différente.
+
+### Que se passe-t-il si je ne termine pas mon transfert dans les 7 jours?
+
+Les outils de transfert L2 utilisent le mécanisme natif d’Arbitrum pour envoyer des messages de L1 à L2. Ce mécanisme s’appelle un « billet modifiable » et est utilisé par tous les ponts de jetons natifs, y compris le pont GRT Arbitrum. Vous pouvez en savoir plus sur les billets retryables dans le [Arbitrum docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+Lorsque vous transférez vos actifs (subgraph, enjeu, délégation ou curation) vers L2, un message est envoyé par le pont GRT Arbitrum qui crée un ticket modifiable en L2. L’outil de transfert inclut une certaine valeur ETH dans la transaction, qui est utilisée pour 1) payer la création du ticket et 2) payer pour le gaz utile à l'exécution du ticket en L2. Cependant, comme le prix du gaz peut varier durant le temps nécessaire à l'exécution du ticket en L2, il est possible que cette tentative d’exécution automatique échoue. Lorsque cela se produit, le pont Arbitrum maintient le billet remboursable en vie pendant 7 jours, et tout le monde peut réessayer de « racheter » le billet (ce qui nécessite un portefeuille avec des ETH liés à Arbitrum).
+
+C'est ce que nous appelons l'étape « Confirmer » dans tous les outils de transfert : elle s'exécute automatiquement dans la plupart des cas et l'exécution automatique réussit le plus souvent. Il est tout de même important de vérifier que le transfert se soit bien déroulé. Si cela échoue et qu'aucune autre tentative n'est confirmé dans les 7 jours, le pont Arbitrum rejettera le ticket et vos actifs (subgraph, participation, délégation ou curation) ne pourront pas être récupérés. Les développeurs principaux de Graph ont mis en place un système de surveillance pour détecter ces situations et essayer d'échanger les billets avant qu'il ne soit trop tard, mais il en reste de votre responsabilité de vous assurer que votre transfert est terminé à temps. Si vous rencontrez des difficultés pour confirmer votre transaction, veuillez nous contacter en utilisant [ce formulaire](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) et les développeurs seront là pour vous aider.
+
+### J'ai commencé le transfert de ma délégation/enjeu/curation et je ne suis pas sûr qu'il soit parvenu jusqu'à L2, comment puis-je confirmer qu'il a été transféré correctement ?
+
+Si vous ne voyez pas de bannière sur votre profil vous demandant de terminer le transfert, il est probable que la transaction soit arrivée en toute sécurité en L2 et qu'aucune autre action ne soit nécessaire. En cas de doute, vous pouvez vérifier si Explorer affiche votre délégation, votre participation ou votre curation sur Arbitrum One.
+
+Si vous disposez du hachage de transaction L1 (que vous pouvez trouver en consultant les transactions récentes dans votre portefeuille), vous pouvez également confirmer si le « ticket réessayable » qui a transporté le message vers L2 a été utilisé ici : https://retryable-dashboard.arbitrum.io/ - si l'échange automatique échoue, vous pouvez également y connecter votre portefeuille et l'échanger. Soyez assuré que les développeurs principaux surveillent également les messages bloqués et tenteront de les récupérer avant leur expiration.
+
+## Subgraph transfert
+
+### Comment transférer mon subgraph ?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+Pour transférer votre subgraph, suivez les étapes qui suivent :
+
+1. Initier le transfert sur le mainnet Ethereum
+
+2. Attendre 20 minutes pour une confirmation
+
+3. Vérifier le transfert de subgraph sur Arbitrum\*
+
+4. Terminer la publication du sous-graphe sur Arbitrum
+
+5. Mettre à jour l’URL de requête (recommandé)
+
+\*Notez que vous devez confirmer le transfert dans un délai de 7 jours, faute de quoi votre subgraph pourrait être perdu. Dans la plupart des cas, cette étape s'exécutera automatiquement, mais une confirmation manuelle peut être nécessaire en cas de hausse du prix du gaz sur Arbitrum. En cas de problème au cours de ce processus, des ressources seront disponibles pour vous aider : contactez le service d'assistance à l'adresse support@thegraph.com ou sur [Discord](https://discord.gg/graphprotocol).
+
+### D’où dois-je initier mon transfert ?
+
+Vous pouvez effectuer votre transfert à partir de la [Subgraph Studio] (https://thegraph.com/studio/), [Explorer,] (https://thegraph.com/explorer) ou de n’importe quelle page de détails de subgraph. Cliquez sur le bouton "Transférer le subgraph" dans la page de détails du subgraph pour démarrer le transfert.
+
+### Combien de temps dois-je attendre avant que mon subgraph soit transféré ?
+
+Le temps de transfert prend environ 20 minutes. Le pont Arbitrum fonctionne en arrière-plan pour terminer automatiquement le transfert du pont. Dans certains cas, les coûts du gaz peuvent augmenter et vous devrez confirmer à nouveau la transaction.
+
+### Mon subgraph sera-t-il toujours repérable après le transfert à L2?
+
+Votre subgraph ne sera détectable que sur le réseau sur lequel il est publié. Par exemple, si votre subgraph est sur Arbitrum One, vous ne pouvez le trouver que dans Explorer sur Arbitrum One et vous ne pourrez pas le trouver sur Ethereum. Assurez-vous que vous avez Arbitrum One sélectionné dans le commutateur de réseau en haut de la page pour vous assurer que vous êtes sur le bon réseau.  Après le transfert, le subgraph L1 apparaîtra comme obsolète.
+
+### Mon subgraph doit-il être publié afin d'être transférer ?
+
+Pour profiter de l’outil de transfert de subgraph, votre subgraph doit déjà être publié sur Ethereum mainnet et doit avoir un signal de curation appartenant au portefeuille qui possède le subgraph. Si votre subgraph n’est pas publié, il est recommandé de publier simplement directement sur Arbitrum One - les frais de gaz associés seront considérablement moins élevés. Si vous souhaitez transférer un subgraph publié mais que le compte propriétaire n’a pas sélectionné de signal, vous pouvez signaler un petit montant (par ex. 1 GRT) à partir de ce compte; assurez-vous de choisir le signal de “migration automatique”.
+
+### Que se passe-t-il pour la version Ethereum mainnet de mon subgraph après que j'ai transféré sur Arbitrum ?
+
+Après avoir transféré votre subgraph vers Arbitrum, la version du réseau principal Ethereum deviendra obsolète. Nous vous recommandons de mettre à jour votre URL de requête dans les 48 heures. Cependant, il existe une période de grâce qui maintient le fonctionnement de votre URL mainnet afin que tout support dapp tiers puisse être mis à jour.
+
+### Après le transfert, dois-je également republier sur Arbitrum ?
+
+Après la fenêtre de transfert de 20 minutes, vous devrez confirmer le transfert avec une transaction dans l'interface utilisateur pour terminer le transfert, mais l'outil de transfert vous guidera tout au long de cette étape. Votre point de terminaison L1 continuera à être pris en charge pendant la fenêtre de transfert et pendant une période de grâce après. Il est encouragé que vous mettiez à jour votre point de terminaison lorsque cela vous convient.
+
+### Mon point de terminaison subira-t-il un temps d'arrêt lors de la republication ?
+
+Il est peu probable, mais possible, de subir un bref temps d'arrêt selon les indexeurs qui prennent en charge le subgraph sur L1 et s'ils continuent à l'indexer jusqu'à ce que le subgraph soit entièrement pris en charge sur L2.
+
+### La publication et la gestion des versions sont-elles les mêmes sur L2 que sur le mainnet Ethereum Ethereum ?
+
+Oui. Sélectionnez Arbitrum One comme réseau publié lors de la publication dans le Subgraph Studio. Dans le Studio, le dernier point de terminaison sera disponible et vous dirigera vers la dernière version mise à jour du subgraph.
+
+### La curation de mon subgraph sera-t-elle déplacée avec mon subgraph?
+
+Si vous avez choisi le signal de migration automatique, 100% de votre propre curation se déplacera avec votre subgraph vers Arbitrum One. Tout le signal de curation du subgraph sera converti en GTR au moment du transfert, et le GRT correspondant à votre signal de curation sera utilisé pour frapper le signal sur le subgraph L2.
+
+D’autres conservateurs peuvent choisir de retirer leur fraction de GRT ou de la transférer à L2 pour créer un signal neuf sur le même subgraph.
+
+### Puis-je déplacer mon subgraph vers le mainnet Ethereum après le transfert?
+
+Une fois transféré, votre version mainnet Ethereum de ce subgraph deviendra obsolète. Si vous souhaitez revenir au mainnet, vous devrez redéployer et publier à nouveau sur le mainnet. Cependant, le transfert vers le mainnet Ethereumt est fortement déconseillé car les récompenses d’indexation seront distribuées entièrement sur Arbitrum One.
+
+### Pourquoi ai-je besoin d’un pont ETH pour finaliser mon transfert ?
+
+Les frais de gaz sur Arbitrum One sont payés en utilisant l'ETH bridgé (c'est-à-dire l'ETH qui a été bridgé sur Arbitrum One). Cependant, les frais de gaz sont nettement inférieurs à ceux de mainnet Ethereum.
+
+## Délégation
+
+### Comment puis-je transférer ma délégation?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+Pour transférer votre délégation, complétez les étapes suivantes :
+
+1. Lancer un transfert de délégation sur le mainnet Ethereum
+2. Attendre 20 minutes pour une confirmation
+3. Confirmer le transfert de délégation sur Arbitrum
+
+\*\*\*\*Vous devez confirmer la transaction pour compléter le transfert de la délégation sur Arbitrum. Cette étape doit être réalisée dans les 7 jours, sinon la délégation pourrait être perdue. Dans la plupart des cas, cette étape se déroule automatiquement, mais une confirmation manuelle peut être nécessaire en cas de hausse du prix du gaz sur Arbitrum. Si vous rencontrez des problèmes au cours de ce processus, il y aura des ressources pour vous aider : contactez le support à support@thegraph.com ou sur [Discord](https://discord.gg/graphprotocol).
+
+### Qu'arrive-t-il à mes récompenses si j'initie un transfert avec une allocation ouverte sur le mainnet Ethereum ?
+
+Si l'indexeur auquel vous déléguez est encore en activité sur L1, lorsque vous transférez sur Arbitrum, vous perdrez toutes les récompenses de délégation provenant d'allocations ouvertes sur le réseau principal Ethereum. Cela signifie que vous perdrez les récompenses de la dernière période de 28 jours au maximum. Si vous effectuez le transfert juste après que l'indexeur ait fermé les allocations, vous pouvez vous assurer que ce montant est le plus bas possible. Si vous disposez d'un canal de communication avec votre (vos) indexeur(s), envisagez de discuter avec lui (eux) pour trouver le meilleur moment pour effectuer votre transfert.
+
+### Que se passe-t-il si l’indexeur auquel je délègue actuellement mes pouvoirs n’est pas sur Arbitrum One ?
+
+L'outil de transfert L2 ne sera activé que si l'indexeur à qui vous avez délégué a transféré sa propre participation à Arbitrum.
+
+### Les délégués ont-ils la possibilité de déléguer à un autre indexeur ?
+
+Si vous souhaitez déléguer à un autre indexeur, vous pouvez transférer vers le même indexeur sur Arbitrum, puis annuler la délégation et attendre la période de décongélation. Après cela, vous pouvez sélectionner un autre indexeur actif auquel déléguer.
+
+### Que faire si je ne trouve pas l'indexeur auquel je délègue sur L2 ?
+
+L'outil de transfert L2 détectera automatiquement l'indexeur auquel vous avez précédemment délégué.
+
+### Pourrai-je mélanger et trier ou "répartir" ma délégation sur un ou plusieurs indexeurs au lieu de l'indexeur précédent ?
+
+L'outil de transfert L2 déplacera toujours votre délégation vers le même indexeur que celui auquel vous l'avez déléguée précédemment. Une fois que vous avez transféré vers L2, vous pouvez annuler la délégation, attendre la période de dégel et décider si vous souhaitez diviser votre délégation.
+
+### Suis-je soumis à la période de suspension ou puis-je effectuer un retrait immédiatement après avoir utilisé l'outil de transfert de délégation L2 ?
+
+L’outil de transfert permet de passer immédiatement en L2. Si vous souhaitez annuler la délégation, vous devrez attendre la période de décongélation. Cependant, si un indexeur a transféré la totalité de sa participation vers L2, vous pouvez immédiatement retirer sur le réseau principal Ethereum.
+
+### Mes récompenses peuvent-elles être affectées négativement si je ne transfère pas ma délégation ?
+
+Il est prévu que toutes les participations au réseau soient transférées vers Arbitrum One à l'avenir.
+
+### Combien de temps faut-il pour effectuer le transfert de ma délégation au L2?
+
+Une confirmation de 20 minutes est requise pour le transfert de la délégation. Veuillez noter qu'après la période de 20 minutes, vous devez revenir et terminer l'étape 3 du processus de transfert dans les 7 jours. Si vous ne le faites pas, votre délégation risque d'être perdue. Notez que dans la plupart des cas, l'outil de transfert effectuera cette étape automatiquement pour vous. En cas d'échec d'une tentative automatique, vous devrez la compléter manuellement. Si des problèmes surviennent au cours de ce processus, ne vous inquiétez pas, nous serons là pour vous aider : contactez-nous à support@thegraph.com ou sur [Discord](https://discord.gg/graphprotocol).
+
+### Puis-je transférer ma délégation si j'utilise un contrat d'acquisition GRT/un portefeuille token lock ?
+
+Oui! Le processus est un peu différent car les contrats d'acquisition ne peuvent pas transmettre l'ETH nécessaire au paiement du gaz L2, vous devez donc le déposer au préalable. Si votre contrat d'acquisition n'est pas totalement acquis, vous devrez également initialiser au préalable un contrat d'acquisition contrepartie sur L2 et ne pourrez transférer la délégation que sur ce contrat d'acquisition L2. L'interface utilisateur d'Explorer peut vous guider tout au long de ce processus lorsque vous êtes connecté à Explorer à l'aide du portefeuille de verrouillage d'acquisition.
+
+### Mon contrat d'acquisition Arbitrum permet-il de libérer du GRT comme sur le réseau principal ?
+
+Non, le contrat d'acquisition créé sur Arbitrum ne permettra pas de libérer de GRT avant la fin du délai d'acquisition, c'est-à-dire jusqu'à ce que votre contrat soit entièrement acquis. L’objectif est d’éviter une double dépense, sinon il serait possible de débloquer les mêmes montants sur les deux niveaux.
+
+Si vous souhaitez libérer les GRT du contrat d'acquisition, vous pouvez les retransférer vers le contrat d'acquisition L1 à l'aide d'Explorer : dans votre profil Arbitrum One, vous verrez une bannière indiquant que vous pouvez retransférer les GRT vers le contrat de vesting du mainnet. Cela nécessite une transaction sur Arbitrum One, en attente de 7 jours, et une transaction finale sur le mainnet, car elle utilise le même mécanisme de pontage natif que celui du pont GRT.
+
+### Y a-t-il une taxe de délégation ?
+
+Non. Les jetons reçus sur L2 sont délégués à l'indexeur spécifié au nom du délégateur spécifié sans facturer de taxe de délégation.
+
+### Mes récompenses non réalisées seront-elles transférées lorsque je transférerai ma délégation ?
+
+Oui! Les seules récompenses qui ne peuvent pas être transférées sont celles des allocations ouvertes, car elles n'existeront pas tant que l'indexeur n'aura pas clôturé les allocations (généralement tous les 28 jours). Si vous déléguez depuis un certain temps, cela ne représente probablement qu'une petite fraction des récompenses.
+
+Au niveau du smart contract, les récompenses non réalisées font déjà partie de votre solde de délégation, elles seront donc transférées lorsque vous transférerez votre délégation en L2. ​
+
+### Le déplacement des délégations en L2 est-il obligatoire ? Y a-t-il un délai ?
+
+Le déplacement de la délégation vers L2 n'est pas obligatoire, mais les récompenses d'indexation augmentent en L2 selon le calendrier décrit dans [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to- augmentation-récompenses-en-l2/4193). À terme, si le Conseil continue d'approuver les augmentations, toutes les récompenses seront distribuées en L2 et il n'y aura aucune récompense d'indexation pour les indexeurs et les délégués en L1. ​
+
+### Si je délègue à un indexeur qui a déjà transféré sa participation en L2, est-ce que je cesse de recevoir des récompenses sur L1 ?
+
+De nombreux indexeurs transfèrent progressivement leur participation, de sorte que les indexeurs sur L1 continueront de gagner des récompenses et des frais sur L1, qui seront ensuite partagés avec les délégués. Une fois qu'un indexeur a transféré la totalité de sa participation, il cessera de fonctionner sur L1, de sorte que les délégués ne recevront plus de récompenses à moins qu'ils ne soient transférés vers L2.
+
+Finalement, si le Conseil continue d'approuver les augmentations des récompenses d'indexation en L2, toutes les récompenses seront distribuées sur L2 et il n'y aura aucune récompense d'indexation pour les indexeurs et les délégués en L1. ​
+
+### Je ne vois pas de bouton pour transférer ma délégation. Pourquoi donc?
+
+Votre indexeur n'a probablement pas encore activé les outils de transfert L2 pour transférer les participations.
+
+Si vous pouvez contacter l'indexeur, vous pouvez l'encourager à utiliser les outils de transfert L2 afin que les délégués puissent transférer des délégations vers leur adresse d'indexeur L2. ​
+
+### Mon Indexeur est également sur Arbitrum, mais je ne vois pas de bouton pour transférer la délégation dans mon profil. Pourquoi donc?
+
+Il est possible que l'indexeur ait mis en place des opérations sur L2, mais qu'il n'ait pas activé les outils de transfert L2 pour transférer des participations. Les smart contracts L1 ne connaîtront donc pas l'adresse L2 de l'indexeur. Si vous pouvez contacter l'indexeur, vous pouvez l'encourager à activer l'outil de transfert afin que les délégués puissent transférer des délégations à l'adresse de l'indexeur L2
+
+### Puis-je transférer ma délégation à L2 si j'ai entamé la procédure de dé-délégation et que je ne l'ai pas encore retirée ?
+
+Non. Si votre délégation dégèle, vous devez attendre 28 jours et la retirer.
+
+Les jetons en cours de dé-délégation sont « verrouillés » et ne peuvent donc pas être transférés vers L2.
+
+## Signal de curation
+
+### Comment puis-je transférer ma curation ?
+
+Pour transférer votre curation, vous devrez compléter les étapes suivantes :
+
+1. Initier le transfert de signal sur le mainnet Ethereum
+
+2. Spécifiez une adresse de curateur L2\*
+
+3. Attendre 20 minutes pour une confirmation
+
+\*Si nécessaire, c'est-à-dire que vous utilisez une adresse contractuelle.
+
+### Comment saurai-je si le subgraph que j'ai organisé a été déplacé vers L2 ?
+
+Lors de la visualisation de la page de détails du subgraph, une bannière vous informera que ce subgraph a été transféré. Vous pouvez suivre l'invite pour transférer votre curation. Vous pouvez également trouver ces informations sur la page de détails du subgraph de tout subgraph déplacé.
+
+### Que se passe-t-il si je ne souhaite pas déplacer ma curation en L2 ?
+
+Lorsqu’un subgraph est déprécié, vous avez la possibilité de retirer votre signal. De même, si un subgraph est passé à L2, vous pouvez choisir de retirer votre signal dans Ethereum mainnet ou d’envoyer le signal à L2.
+
+### Comment puis-je savoir si ma curation a été transférée avec succès?
+
+Les détails du signal seront accessibles via Explorer environ 20 minutes après le lancement de l'outil de transfert L2.
+
+### Puis-je transférer ma curation sur plus d’un subgraph à la fois?
+
+Il n’existe actuellement aucune option de transfert groupé.
+
+## Enjeu de l'indexeur
+
+### Comment transférer ma participation vers Arbitrum ?
+
+> Avis de non-responsabilité : si vous supprimez actuellement une partie de votre GRT sur votre indexeur, vous ne pourrez pas utiliser les outils de transfert L2.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+Pour transférer votre participation, vous devrez suivre les étapes suivantes :
+
+1. Initier un transfert de participation sur Ethereum mainnet
+
+2. Attendre 20 minutes pour une confirmation
+
+3. Confirmer le transfert de participation sur Arbitrum
+
+\*Notez que vous devez confirmer le transfert dans les 7 jours, sinon votre mise pourrait être perdue. Dans la plupart des cas, cette étape s'exécutera automatiquement, mais une confirmation manuelle peut être nécessaire en cas de hausse du prix du gaz sur Arbitrum. Si vous rencontrez des problèmes au cours de ce processus, des ressources seront disponibles pour vous aider : contactez l'assistance à support@thegraph.com ou sur [Discord](https://discord.gg/graphprotocol).
+
+### Est-ce que tous mes enjeux seront transférés?
+
+Vous pouvez choisir la part de votre mise à transférer. Si vous choisissez de transférer la totalité de votre participation en une seule fois, vous devrez d'abord clôturer toutes les allocations ouvertes.
+
+Si vous prévoyez de transférer une partie de votre participation sur plusieurs transactions, vous devez toujours indiquer la même adresse de bénéficiaire.
+
+Notez : Vous devez répondre aux exigences minimales de mise sur L2 la première fois que vous utilisez l’outil de transfert. Les indexeurs doivent envoyer le minimum de cent mille GRT (lors de l’appel de cette fonction la première fois). Si vous laissez une partie de la mise sur L1, elle doit également être supérieure à cent mille GRT minimum et être suffisante (avec vos délégations) pour couvrir vos allocations ouvertes.
+
+### De combien de temps ai-je pour confirmer le transfert de ma participation à Arbitrum ?
+
+\*\*\* Vous devez confirmer votre transaction pour finaliser le transfert de participation sur Arbitrum. Cette étape doit être complétée dans les 7 jours sinon la mise pourrait être perdue.
+
+### Que se passe-t-il si j'ai des allocations ouvertes ?
+
+Si vous n’envoyez pas la totalité de votre mise, l’outil de transfert L2 validera qu’au moins cent mille GRT restent dans le mainnet Ethereum et que votre participation et votre délégation restantes sont suffisantes pour couvrir toute allocation ouverte. Vous devrez peut-être fermer les allocations ouvertes si votre solde de GRT ne couvre pas les allocations minimales + ouvertes.
+
+### À l’aide des outils de transfert, faut-il attendre 28 jours pour se détacher du mainnet Ethereum avant de transférer?
+
+Non, vous pouvez transférer votre mise vers L2 immédiatement, vous n'avez pas besoin de vous désengager et d'attendre avant d'utiliser l'outil de transfert. L'attente de 28 jours ne s'applique que si vous souhaitez retirer la mise sur votre portefeuille, sur le réseau principal Ethereum ou L2.
+
+### Combien de temps faudra-t-il pour transférer ma participation ?
+
+Il faudra environ 20 minutes à l'outil de transfert L2 pour achever le transfert de votre participation.
+
+### Dois-je indexer sur Arbitrum avant de transférer ma mise ?
+
+Vous pouvez effectivement transférer votre mise d’abord avant de mettre en place l’indexation, mais vous ne serez pas en mesure de réclamer des récompenses sur L2 jusqu’à ce que vous allouez à des sous-graphes sur L2, les indexer, et présenter des points d’intérêt.
+
+### Les délégués peuvent-ils déplacer leur délégation avant que je ne déplace ma participation à l'indexation ?
+
+Non, pour que les délégataires puissent transférer leur GRT délégué à Arbitrum, l'indexeur auquel ils délèguent doit être actif sur L2.
+
+### Puis-je transférer ma participation si j'utilise un contrat de vesting GRT / un token lock wallet ?
+
+Oui! Le processus est un peu différent, car les contrats d'acquisition ne peuvent pas transmettre l'ETH nécessaire pour payer le gaz L2, vous devez donc le déposer au préalable. Si votre contrat d'acquisition n'est pas entièrement acquis, vous devrez également initialiser au préalable un contrat d'acquisition contrepartie sur L2 et ne pourrez transférer la participation que sur ce contrat d'acquisition L2. L'interface utilisateur d'Explorer peut vous guider tout au long de ce processus lorsque vous êtes connecté à Explorer à l'aide du portefeuille de verrouillage d'acquisition.
+
+### J'ai déjà des participations en L2. Dois-je toujours envoyer 100 000 GRT lorsque j'utilise les outils de transfert pour la première fois ?
+
+Oui. Les smart contracts L1 ne connaissent pas vos participations en L2, ils vous exigeront donc de transférer au moins 100 000 GRT lors de votre premier transfert. ​
+
+### Puis-je transférer ma participation vers L2 si je suis en train de retirer du GRT ?
+
+Non. Si une fraction de votre mise est en train de dégeler, vous devez attendre les 28 jours et la retirer avant de pouvoir transférer votre mise. Les jetons mis en jeu sont "verrouillés" et empêchent tout transfert ou mise vers L2.
+
+## Transfert de contrat de vesting
+
+### Comment transférer mon contrat de vesting ?
+
+Pour transférer votre vesting, vous devez suivre les étapes suivantes :
+
+1. Initier le transfert de vesting sur Ethereum mainnet
+
+2. Attendre 20 minutes pour une confirmation
+
+3. Confirmer le transfert de vesting dans Arbitrum
+
+### Comment puis-je transférer mon contrat de vesting si je ne suis que partiellement investi?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Déposez quelques ETH dans le contrat de l'outil de transfert (l'interface utilisateur peut vous aider à estimer un montant raisonnable)
+
+2. Envoyez une partie de la GRT verrouillée au moyen du contrat de l’outil de transfert au L2 pour initialiser le verrou d’acquisition L2, ce qui établira également l’adresse du bénéficiaire L2.
+
+3. Envoyer leur enjeu/délégation à L2 via les fonctions de l’outil de transfert "verrouillé" du contrat L1Staking.
+
+4. Retirer tout ETH restant du contrat d’outil de transfert
+
+### Comment puis-je transférer mon contrat d’acquisition si je suis entièrement investi?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+Pour ceux qui ont acquis la totalité de leurs droits, le processus est similaire :
+
+1. Déposez quelques ETH dans le contrat de l'outil de transfert (l'interface utilisateur peut vous aider à estimer un montant raisonnable)
+
+2. Paramétrez votre adresse L2 en appelant le contrat outil de transfert
+
+3. Envoyez votre participation/délégation à L2 via les fonctions de l'outil de transfert « verrouillées » dans le contrat de Staking L1.
+
+4. Retirer tout ETH restant du contrat d’outil de transfert
+
+### Puis-je transférer mon contrat de vesting à Arbitrum ?
+
+Vous pouvez transférer le solde GRT de votre contrat de vesting vers un contrat de vesting en L2. C’est une condition préalable au transfert de participation ou de délégation de votre contrat de vesting vers L2. Le contrat de vesting doit contenir un montant non nul de GRT (vous pouvez y transférer un petit montant comme 1 GRT si nécessaire).
+
+Lorsque vous transférez des TRG de votre contrat de vesting L1 vers L2, vous pouvez choisir le montant à envoyer et vous pouvez le faire autant de fois que vous le souhaitez. Le contrat de vesting L2 sera initialisé la première fois que vous transférez des TRG.
+
+Les transferts s'effectuent à l'aide d'un outil de transfert qui sera visible sur votre profil Explorer lorsque vous vous connecterez au compte du contrat de vesting.
+
+Veuillez noter que vous ne pourrez pas libérer/retirer la GRT du contrat de vesting de L2 avant la fin de votre délai de vesting lorsque votre contrat sera entièrement acquis. Si vous devez libérer la GRT avant cette date, vous pouvez la transférer au contrat de vesting de L1 à l’aide d’un autre outil de transfert disponible à cette fin.
+
+Si vous n’avez transféré aucun solde de contrat de vesting à L2 et que votre contrat de vesting est entièrement dévolu, vous ne devez pas transférer votre contrat de vesting à L2. Au lieu de cela, vous pouvez utiliser les outils de transfert pour définir une adresse de portefeuille L2 et transférer directement votre participation ou délégation à ce portefeuille régulier sur L2.
+
+### J’utilise mon contrat de vesting pour investir dans mainnet. Puis-je transférer ma participation à Arbitrum?
+
+Oui, mais si votre contrat est toujours acquis, vous ne pouvez transférer la participation que pour qu’elle soit détenue par votre contrat d’acquisition L2. Vous devez d’abord initialiser ce contrat L2 en transférant un solde de GRT à l’aide de l’outil de transfert de contrat d’acquisition dans Explorer. Si
+votre contrat est entièrement acquis, vous pouvez transférer votre participation à n’importe quelle adresse en L2, mais vous devez le définir au préalable et déposer des GRT pour l’outil de transfert L2 pour payer le gaz L2.
+
+### J’utilise mon contrat de vesting pour déléguer sur mainnet. Puis-je transférer mes délégations à Arbitrum?
+
+Oui, mais si votre contrat est toujours acquis, vous ne pouvez transférer la participation que pour qu’elle soit détenue par votre contrat de vesting L2. Vous devez d’abord initialiser ce contrat L2 en transférant un solde de GRT à l’aide de l’outil de transfert de contrat de vesting dans Explorer. Si
+votre contrat est entièrement acquis, vous pouvez transférer votre participation à n’importe quelle adresse en L2, mais vous devez le définir au préalable et déposer des GRT pour l’outil de transfert L2 pour payer le gaz L2.
+
+### Puis-je spécifier un bénéficiaire différent pour mon contrat de vesting sur L2?
+
+Oui, la première fois que vous transférez un solde et mettez en place votre contrat de vesting L2, vous pouvez désigner un bénéficiaire L2. Assurez-vous que ce bénéficiaire est un portefeuille capable d'effectuer des transactions sur Arbitrum One, c'est-à-dire qu'il doit s'agir d'un EOA ou d'un multisig déployé sur Arbitrum One.
+
+Si votre contrat est entièrement dévolu, vous n’établirez pas de contrat de vesting sur L2 ; au lieu de cela, vous établirez une adresse de portefeuille L2 et ce sera le portefeuille destinataire de votre mise ou délégation sur Arbitrum.
+
+### Mon contrat est entièrement dévolu. Puis-je transférer ma participation ou ma délégation à une autre adresse qui n’est pas un contrat de vesting L2?
+
+Oui. Si vous n’avez transféré aucun solde de contrat de vesting à L2 et que votre contrat de vesting est entièrement dévolu, vous ne devez pas transférer votre contrat de vesting à L2. Au lieu de cela, vous pouvez utiliser les outils de transfert pour définir une adresse de portefeuille L2 et transférer directement votre participation ou délégation à ce portefeuille régulier sur L2.
+
+Ceci vous permet de transférer votre participation ou délégation à n’importe quelle adresse L2.
+
+### Mon contrat de vesting est toujours acquis. Comment puis-je transférer le solde de mon contrat de vesting à L2 ?
+
+Ces étapes ne s'appliquent que si votre contrat est encore en cours de vesting ou si vous avez déjà utilisé cette procédure lorsque votre contrat était encore en cours de vesting.
+
+Pour transférer votre contrat de vesting à L2, vous enverrez tout solde de TRB à L2 à l’aide des outils de transfert, ce qui initialisera votre contrat de vesting à L2 :
+
+1. Déposez de l'ETH dans le contrat de l'outil de transfert (cela sera utilisé pour payer le gaz L2)
+
+2. Révoquer l'accès au protocole au contrat de vesting (nécessaire pour l'étape suivante)
+
+3. Donner au protocole l'accès au contrat de vesting (pour permettre à votre contrat d'interagir avec l'outil de transfert)
+
+4. Spécifiez une adresse de bénéficiaire L2\* et lancez le transfert de solde sur le mainnet Ethereum
+
+5. Attendre 20 minutes pour une confirmation
+
+6. Confirmation du transfert de solde à L2
+
+\*Si nécessaire, c'est-à-dire que vous utilisez une adresse contractuelle.
+
+\*\*\*\*Vous devez confirmer votre transaction pour terminer le transfert de solde sur Arbitrum. Cette étape doit être complétée dans un délai de 7 jours sinon le solde pourrait être perdu. Dans la plupart des cas, cette étape s'exécutera automatiquement, mais une confirmation manuelle peut être nécessaire en cas de hausse du prix du gaz sur Arbitrum. Si vous rencontrez des problèmes au cours de ce processus, des ressources seront disponibles pour vous aider : contactez l'assistance à support@thegraph.com ou sur [Discord](https://discord.gg/graphprotocol).
+
+### Mon contrat de vesting indique 0 GRT donc je ne peux pas le transférer - pourquoi et comment régler ça ?
+
+Pour initialiser votre contrat de vesting en L2, vous devez transférer un montant non nul de GRT en L2. Cette opération est requise par le pont Arbitrum GRT utilisé par les outils de transfert L2. Les GRT doivent provenir du solde du contrat de vesting, n'incluant donc pas les GRT stackés ou délégués.
+
+Si vous avez stacké ou délégué tous vos GRT à partir du contrat de vesting, vous pouvez envoyer manuellement un petit montant (1 GRT) à l'adresse du contrat de vesting à partir de n'importe quel autre endroit (exemple : à partir d'un autre portefeuille ou d'un échange)
+
+### J'utilise un contrat de vesting pour mettre en jeu ou déléguer, mais je ne vois pas de bouton pour transférer ma mise en jeu ou ma délégation à L2, que dois-je faire ?
+
+Si votre contrat de vesting n'a pas fini d'être acquis, vous devez d'abord créer un contrat de vesting L2 qui recevra votre mise ou votre délégation sur L2. Ce contrat de vesting ne permettra pas de libérer des jetons en L2 avant la fin de la période de vesting, mais il vous permettra de transférer des GRT vers le contrat de vesting en L1 pour les y libérer.
+
+Lorsque vous êtes connecté au contrat de vesting sur Explorer, vous devriez voir un bouton pour initialiser votre contrat de vesting L2. Suivez d'abord cette procédure et vous verrez ensuite les boutons pour transférer votre participation ou votre délégation dans votre profil
+
+### Si j’initialise mon contrat de vesting L2, est-ce que cela transférera également automatiquement ma délégation en L2 ?
+
+Non, l'initialisation de votre contrat de vesting L2 est une condition préalable au transfert de la participation ou de la délégation du contrat de vesting, mais vous devez toujours les transférer séparément.
+
+Vous verrez apparaître sur votre profil une bannière vous invitant à transférer votre participation ou votre délégation après avoir initialisé votre contrat de vesting L2.
+
+### Puis-je ramener mon contrat de vestng au L1?
+
+Il n’est pas nécessaire de le faire car votre contrat de vesting est toujours en L1. Lorsque vous utilisez les outils de transfert, vous créez simplement un nouveau contrat en L2 qui est lié à votre contrat de vesting L1, et vous pouvez envoyer GRT aller-retour entre les deux.
+
+### Pourquoi dois-je commencer par déplacer mon contrat de vesting ?
+
+Vous devez mettre en place un contrat de vesting L2 afin que ce compte puisse être propriétaire de votre mise ou délégation sur L2. Sinon, il n’y aurait aucun moyen pour vous de transférer la participation / délégation à L2 sans "échapper" au contrat de vesting.
+
+### Que se passe-t-il si j'essaie d'encaisser mon contrat alors qu'il n'est que partiellement acquis ? Est-ce possible ?
+
+Ce n'est pas possible. Vous pouvez transférer des fonds vers L1 et les y retirer.
+
+### Que se passe-t-il si je ne souhaite pas transférer mon contrat de vesting vers L2 ?
+
+Vous pouvez continuer à jalonner/déléguer sur L1. Au fil du temps, vous souhaiterez peut-être envisager de passer à L2 pour y activer les récompenses à mesure que le protocole évolue sur Arbitrum. Notez que ces outils de transfert sont destinés à l'acquisition de contrats qui sont autorisés à participer et à déléguer dans le protocole. Si votre contrat ne permet pas de jalonner ou de déléguer, ou est révocable, aucun outil de transfert n'est disponible. Vous pourrez toujours retirer votre GRT de L1 lorsqu'il sera disponible.

From 6b5366ff3626515447e9dba5880e1c0e3f4aea50 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:40 -0500
Subject: [PATCH 1024/3820] New translations l2-transfer-tools-faq.mdx
 (Spanish)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/es/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/es/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/es/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..8c4f263f418b
--- /dev/null
+++ b/website/pages/es/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2 Transfer Tools FAQ
+---
+
+## General
+
+### What are L2 Transfer Tools?
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### Can I use the same wallet I use on Ethereum mainnet?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### ¿Qué sucede si no completo mi transferencia en 7 días?
+
+Las Herramientas de Transferencia a L2 utilizan el mecanismo nativo de Arbitrum para enviar mensajes de L1 a L2. Este mecanismo se llama "ticket reintentable" y es utilizado por todos los puentes de tokens nativos, incluido el puente GRT de Arbitrum. Puedes obtener más información sobre los tickets reintentables en la [Documentación de Arbitrum](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+Cuando transfieres tus activos (subgrafo, stake, delegación o curación) a L2, se envía un mensaje a través del puente Arbitrum GRT que crea un ticket reintentable en L2. La herramienta de transferencia incluye un valor ETH en la transacción, que se utiliza para: 1) pagar la creación del ticket y 2) pagar por el gas para ejecutar el ticket en L2. Sin embargo, debido a que los precios del gas pueden variar durante el tiempo hasta que el ticket esté listo para ejecutarse en L2, es posible que este intento de autoejecución falle. Cuando eso sucede, el puente de Arbitrum mantendrá el ticket reintentable activo durante un máximo de 7 días, y cualquier persona puede intentar nuevamente "canjear" el ticket (lo que requiere una wallet con algo de ETH transferido a Arbitrum).
+
+Esto es lo que llamamos el paso de "Confirmar" en todas las herramientas de transferencia. En la mayoría de los casos, se ejecutará automáticamente, ya que la autoejecución suele ser exitosa, pero es importante que vuelvas a verificar para asegurarte de que se haya completado. Si no tiene éxito y no hay reintentos exitosos en 7 días, el puente de Arbitrum descartará el ticket, y tus activos (subgrafo, stake, delegación o curación) se perderán y no podrán recuperarse. Los core devs de The Graph tienen un sistema de monitoreo para detectar estas situaciones e intentar canjear los tickets antes de que sea demasiado tarde, pero en última instancia, es tu responsabilidad asegurarte de que tu transferencia se complete a tiempo. Si tienes problemas para confirmar tu transacción, por favor comunícate a través de [este formulario](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) y los core devs estarán allí para ayudarte.
+
+### Comencé la transferencia de mi delegación/stake/curación y no estoy seguro de si se completó en L2, ¿cómo puedo confirmar que se transfirió correctamente?
+
+Si no ves un banner en tu perfil que te pida completar la transferencia, es probable que la transacción haya llegado de manera segura a L2 y no sea necesario realizar ninguna otra acción. Si tienes dudas, puedes verificar si el Explorer muestra tu delegación, stake o curación en Arbitrum One.
+
+Si tienes el hash de la transacción en L1 (que puedes encontrar revisando las transacciones recientes en tu wallet), también puedes confirmar si el "ticket reintentable" que transportó el mensaje a L2 fue redimido aquí: https://retryable-dashboard.arbitrum.io/ - si la redención automática falló, también puedes conectar tu wallet allí y redimirlo. Puedes estar seguro de que los core devs también están monitoreando los mensajes que quedan atascados y tratarán de redimirlos antes de que expiren.
+
+## Transferencia de Subgrafo
+
+### ¿Cómo transfiero mi subgrafo?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+Para transferir tu subgrafo, tendrás que completar los siguientes pasos:
+
+1. Inicia la transferencia en Ethereum mainnet
+
+2. Espera 20 minutos para la confirmación
+
+3. Confirma la transferencia del subgrafo en Arbitrum
+
+4. Termina de publicar el subgrafo en Arbitrum
+
+5. Actualiza la URL de consulta (recomendado)
+
+\*Ten en cuenta que debes confirmar la transferencia dentro de los 7 días, de lo contrario, es posible que se pierda tu subgrafo. En la mayoría de los casos, este paso se ejecutará automáticamente, pero puede ser necesaria una confirmación manual si hay un aumento en el precio del gas en Arbitrum. Si surgen problemas durante este proceso, habrá recursos disponibles para ayudarte: ponte en contacto con el soporte en support@thegraph.com o en [Discord](https://discord.gg/graphprotocol).
+
+### ¿Desde dónde debo iniciar mi transferencia?
+
+Puedes iniciar la transferencia desde el [Subgraph Studio](https://thegraph.com/studio/), [Explorer](https://thegraph.com/explorer) o desde cualquier página de detalles del subgrafo. Haz clic en el botón "Transferir Subgrafo" en la página de detalles del subgrafo para iniciar la transferencia.
+
+### ¿Cuánto tiempo tengo que esperar hasta que se transfiera mi subgrafo?
+
+El tiempo de transferencia demora aproximadamente 20 minutos. El puente de Arbitrum está trabajando en segundo plano para completar la transferencia automáticamente. En algunos casos, los costos de gas pueden aumentar y necesitarás confirmar la transacción nuevamente.
+
+### ¿Mi subgrafo seguirá siendo accesible después de transferirlo a L2?
+
+Tu subgrafo solo será accesible en la red donde esté publicado. Por ejemplo, si tu subgrafo está en Arbitrum One, solo podrás encontrarlo en el explorador de Arbitrum One y no podrás encontrarlo en Ethereum. Asegúrate de tener seleccionado Arbitrum One en el selector de redes en la parte superior de la página para asegurarte de estar en la red correcta. Después de la transferencia, el subgrafo en L1 aparecerá como obsoleto.
+
+### ¿Es necesario publicar mi subgrafo para transferirlo?
+
+Para aprovechar la herramienta de transferencia de subgrafos, tu subgrafo debe estar ya publicado en la red principal de Ethereum y debe tener alguna señal de curación propiedad de la wallet que posee el subgrafo. Si tu subgrafo no está publicado, se recomienda que lo publiques directamente en Arbitrum One, ya que las tarifas de gas asociadas serán considerablemente más bajas. Si deseas transferir un subgrafo ya publicado pero la cuenta del propietario no ha curado ninguna señal en él, puedes señalizar una pequeña cantidad (por ejemplo, 1 GRT) desde esa cuenta; asegúrate de elegir la opción de señal "auto-migración".
+
+### ¿Qué ocurre con la versión de Ethereum mainnet de mi subgrafo después de transferirlo a Arbitrum?
+
+Tras transferir tu subgrafo a Arbitrum, la versión de Ethereum mainnet quedará obsoleta. Te recomendamos que actualices tu URL de consulta en un plazo de 48 horas. Sin embargo, existe un periodo de gracia que mantiene tu URL de mainnet en funcionamiento para que se pueda actualizar cualquier soporte de dapp de terceros.
+
+### Después de la transferencia, ¿también tengo que volver a publicar en Arbitrum?
+
+Una vez transcurridos los 20 minutos de la ventana de transferencia, tendrás que confirmar la transferencia con una transacción en la interfaz de usuario para finalizar la transferencia, pero la herramienta de transferencia te guiará en este proceso. Tu endpoint L1 seguirá siendo compatible durante la ventana de transferencia y un período de gracia después. Te recomendamos que actualices tu endpoint cuando te resulte conveniente.
+
+### ¿Experimentará mi endpoint una interrupción durante la republicación?
+
+Es poco probable, pero es posible experimentar una breve interrupción dependiendo de qué Indexadores estén respaldando el subgrafo en L1 y si continúan indexándolo hasta que el subgrafo esté completamente respaldado en L2.
+
+### ¿Es lo mismo publicar y versionar en L2 que en Ethereum mainnet?
+
+Sí. Asegúrate de seleccionar Arbitrum One como tu red para publicar cuando publiques en Subgraph Studio. En el Studio, estará disponible el último endpoint que apunta a la última versión actualizada del subgrafo.
+
+### ¿Se moverá la curación de mi subgrafo junto con mi subgrafo?
+
+Si has elegido auto-migrar la señal, el 100% de tu curación propia se moverá con tu subgrafo a Arbitrum One. Toda la señal de curación del subgrafo se convertirá a GRT en el momento de la transferencia, y el GRT correspondiente a tu señal de curación se utilizará para mintear señal en el subgrafo L2.
+
+Otros Curadores pueden elegir si retiran su fracción de GRT, o también la transfieren a L2 para mintear señal en el mismo subgrafo.
+
+### ¿Puedo mover mi subgrafo de nuevo a Ethereum mainnet después de la transferencia?
+
+Una vez transferida, la versión en Ethereum mainnet de este subgrafo quedará obsoleta. Si deseas regresar a mainnet, deberás volver a deployar y publicar en mainnet. Sin embargo, se desaconseja firmemente volver a transferir a Ethereum mainnet, ya que las recompensas por indexación se distribuirán eventualmente por completo en Arbitrum One.
+
+### ¿Por qué necesito ETH bridgeado para completar mi transferencia?
+
+Las tarifas de gas en Arbitrum One se pagan utilizando ETH bridgeado (es decir, ETH que ha sido transferido a Arbitrum One). Sin embargo, las tarifas de gas son significativamente más bajas en comparación con Ethereum mainnet.
+
+## Delegación
+
+### ¿Cómo transfiero mi delegación?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+Para transferir tu delegación, deberás seguir los siguientes pasos:
+
+1. Inicia la transferencia de delegación en Ethereum mainnet
+2. Espera 20 minutos para la confirmación
+3. Confirma la transferencia de delegación en Arbitrum
+
+\*\*\*\*Debes confirmar la transacción para completar la transferencia de la delegación en Arbitrum. Este paso debe completarse dentro de los 7 días o la delegación podría perderse. En la mayoría de los casos, este paso se ejecutará automáticamente, pero puede ser necesaria una confirmación manual si hay un aumento en el precio del gas en Arbitrum. Si surgen problemas durante este proceso, habrá recursos disponibles para ayudarte: contacta con el soporte en support@thegraph.com o en [Discord](https://discord.gg/graphprotocol).
+
+### ¿Qué sucede con mis recompensas si inicio una transferencia con una allocation abierta en Ethereum mainnet?
+
+Si el Indexador al que estás delegando aún está operando en L1, cuando transfieras a Arbitrum perderás cualquier recompensa de delegación de allocations abiertas en Ethereum mainnet. Esto significa que perderás las recompensas de, como máximo, el último período de 28 días. Si sincronizas la transferencia justo después de que el Indexador haya cerrado las allocations, puedes asegurarte de que sea la menor cantidad posible. Si tienes un canal de comunicación con tu(s) Indexador(es), considera discutir con ellos para encontrar el mejor momento para hacer la transferencia.
+
+### ¿Qué sucede si el Indexador al que actualmente delego no está en Arbitrum One?
+
+La herramienta de transferencia a L2 solo estará habilitada si el Indexador al que has delegado ha transferido su stake propio a Arbitrum.
+
+### ¿Los Delegadores tienen la opción de delegar a otro Indexador?
+
+Si deseas delegar a otro Indexador, puedes transferir a ese mismo Indexador en Arbitrum, luego anular la delegación y esperar el período de desbloqueo. Después de esto, puedes seleccionar otro Indexador activo al que delegar.
+
+### ¿Qué sucede si no puedo encontrar al Indexador al que estoy delegando en L2?
+
+La herramienta de transferencia a L2 detectará automáticamente al Indexador al que previamente has delegado.
+
+### ¿Podré mezclar o distribuir mi delegación entre nuevos Indexadores o varios Indexadores en lugar del Indexador anterior?
+
+La herramienta de transferencia a L2 siempre trasladará tu delegación al mismo Indexador al que delegaste anteriormente. Una vez que te hayas trasladado a L2, puedes anular la delegación, esperar el período de desbloqueo y decidir si deseas dividir tu delegación.
+
+### ¿Estoy sujeto al período de espera o puedo retirarme inmediatamente después de usar la herramienta de transferencia de delegación a L2?
+
+La herramienta de transferencia te permite moverte de inmediato a L2. Si deseas anular la delegación, tendrás que esperar el período de desbloqueo. Sin embargo, si un Indexador ha transferido todo su stake a L2, podrás retirarla inmediatamente en Ethereum mainnet.
+
+### ¿Mis recompensas pueden verse afectadas negativamente si no transfiero mi delegación?
+
+Se espera que toda la participación en la red se traslade a Arbitrum One en el futuro.
+
+### ¿Cuánto tiempo se tarda en completar la transferencia de mi delegación a L2?
+
+Se requiere una confirmación de 20 minutos para la transferencia de la delegación. Después del período de 20 minutos, debes regresar y completar el paso 3 del proceso de transferencia dentro de los 7 días. Si no lo haces, es posible que pierdas tu delegación. Ten en cuenta que en la mayoría de los casos, la herramienta de transferencia completará automáticamente este paso por ti. En caso de que ocurra un intento automático fallido, deberás completarlo manualmente. Si surgen problemas durante este proceso, no te preocupes, estaremos aquí para ayudarte: contáctanos en support@thegraph.com o en [Discord](https://discord.gg/vtvv7FP).
+
+### ¿Puedo transferir mi delegación si estoy usando un contrato de vesting o una wallet de bloqueo de tokens?
+
+¡Sí! El proceso es un poco diferente porque los contratos de vesting no pueden enviar el ETH necesario para pagar las tarifas de gas en L2, por lo que debes depositarlo con antelación. Si tu contrato de vesting aún no está completamente adquirido, también deberás inicializar un contrato de vesting equivalente en L2 y solo podrás transferir la delegación a este contrato de vesting en L2. La interfaz de usuario en Explorer te guiará a través de este proceso cuando te hayas conectado a Explorer usando la wallet con bloqueo por vesting.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### ¿Existe algún impuesto a la delegación?
+
+No, no se cobra ningún impuesto de delegación. Los tokens recibidos en L2 se delegan al Indexador especificado en nombre del Delegador especificado sin cobrar ningún impuesto de delegación.
+
+### ¿Se transferirán mis recompensas no realizadas cuando transfiera mi delegación?
+
+¡Sí! Las únicas recompensas que no se pueden transferir son las correspondientes a allocations abiertas, ya que estas no existirán hasta que el Indexador cierre las allocations (generalmente cada 28 días). Si has estado delegando durante un tiempo, es probable que estas sean solo una pequeña fracción de las recompensas.
+
+A nivel de contrato inteligente, las recompensas no realizadas ya forman parte de tu saldo de delegación, por lo que se transferirán cuando transfieras tu delegación a L2.
+
+### ¿Es obligatorio trasladar las delegaciones a L2? ¿Hay algún plazo límite?
+
+Trasladar la delegación a L2 no es obligatorio, pero las recompensas de indexación están aumentando en L2 siguiendo el calendario descrito en [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventualmente, si el Council sigue aprobando los aumentos, todas las recompensas se distribuirán en L2 y no habrá recompensas de indexación para Indexadores y Delegadores en L1.
+
+### Si estoy delegando a un Indexador que ya ha transferido su stake a L2, ¿dejo de recibir recompensas en L1?
+
+Muchos Indexadores están transfiriendo su stake gradualmente, por lo que los Indexadores en L1 seguirán ganando recompensas y tarifas en L1, las cuales luego se comparten con los Delegadores. Una vez que un Indexador haya transferido todo su stake, dejarán de operar en L1, por lo que los Delegadores no recibirán más recompensas a menos que transfieran a L2.
+
+Eventualmente, si el Consejo continúa aprobando aumentos en las recompensas de indexación en L2, todas las recompensas se distribuirán en L2 y no habrá recompensas de indexación para Indexers y Delegators en L1
+
+### No veo un botón para transferir mi delegación. ¿Por qué sucede eso?
+
+Tu Indexer probablemente aún no ha utilizado las herramientas de transferencia de L2 para transferir la participación.
+
+Si puedes contactar al Indexador, puedes animarlos a utilizar las Herramientas de Transferencia de L2 para que los Delegators puedan transferir sus delegaciones a la dirección de L2 del Indexer
+
+### Mi Indexador también está en Arbitrum, pero no veo un botón para transferir la delegación en mi perfil. ¿Por qué sucede eso?
+
+Es posible que el Indexador haya configurado operaciones en L2, pero no haya utilizado las herramientas de transferencia de L2 para transferir la participación. Por lo tanto, los contratos inteligentes de L1 no tendrán información sobre la dirección de L2 del Indexador. Si puedes ponerte en contacto con el Indexador, puedes animarlos a utilizar la herramienta de transferencia para que los Delegadores puedan transferir sus delegaciones a la dirección de L2 del Indexador
+
+### ¿Puedo transferir mi delegación a L2 si he iniciado el proceso de cancelación de la delegación y aún no lo he retirado?
+
+No. Si tu delegación está desbloqueandose, debes esperar los 28 días y retirarla.
+
+Los tokens que se están desdelegando están "bloqueados" y, por lo tanto, no se pueden transferir a L2.
+
+## Señal de Curación
+
+### ¿Cómo transfiero mi curaduría?
+
+Para transferir tu curación, deberás completar los siguientes pasos:
+
+1. Iniciar la transferencia de señal en Ethereum mainnet
+
+2. Especifica una dirección L2 de Curador
+
+3. Espera 20 minutos para la confirmación
+
+\*Si es necesario - i.e. si estás utilizando una dirección de contrato.
+
+### ¿Cómo sabré si el subgrafo que he curado ha pasado a L2?
+
+Al ver la página de detalles del subgrafo, un banner te notificará que este subgrafo ha sido transferido. Puedes seguir la indicación para transferir tu curación. También puedes encontrar esta información en la página de detalles del subgrafo de cualquier subgrafo que se haya trasladado.
+
+### ¿Qué ocurre si no deseo trasladar mi curación a L2?
+
+Cuando un subgrafo queda obsoleto, tienes la opción de retirar tu señal. De manera similar, si un subgrafo se ha trasladado a L2, puedes elegir retirar tu señal en Ethereum mainnet o enviar la señal a L2.
+
+### ¿Cómo sé si mi curación se ha transferido correctamente?
+
+Los detalles de la señal serán accesibles a través del Explorer aproximadamente 20 minutos después de iniciar la herramienta de transferencia a L2.
+
+### ¿Puedo transferir mi curación en más de un subgrafo a la vez?
+
+En este momento no existe la opción de transferencia masiva.
+
+## Stake del Indexador
+
+### ¿Cómo transfiero mi stake a Arbitrum?
+
+> Aviso: Si en este momento estás retirando alguna porción de tus GRT de tu Indexador, no podrás utilizar las Herramientas de Transferencia de L2.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+Para transferir tu stake, deberás seguir los siguientes pasos:
+
+1. Inicia la transferencia de stake en Ethereum mainnet
+
+2. Espera 20 minutos para la confirmación
+
+3. Confirma la transferencia de stake en Arbitrum
+
+\*Ten en cuenta que debes confirmar la transferencia dentro de los 7 días; de lo contrario, tu participación podría perderse. En la mayoría de los casos, este paso se ejecutará automáticamente, pero puede ser necesaria una confirmación manual si hay un aumento en el precio del gas en Arbitrum. Si surgen problemas durante este proceso, habrá recursos disponibles para ayudarte: ponte en contacto con el soporte en support@thegraph.com o en [Discord](https://discord.gg/graphprotocol).
+
+### ¿Se transferirá todo mi stake?
+
+Puedes elegir qué parte de tu stake deseas transferir. Si decides transferir todo tu stake de una vez, deberás cerrar primero las allocations abiertas.
+
+Si planeas transferir partes de tu stake en múltiples transacciones, siempre debes especificar la misma dirección de beneficiario.
+
+Nota: Debes cumplir con los requisitos mínimos de participación en L2 la primera vez que utilices la herramienta de transferencia. Los Indexadores deben enviar un mínimo de 100,000 GRT (cuando llaman a esta función por primera vez). Si dejas una parte de la participación en L1, también debe superar el mínimo de 100,000 GRT y ser suficiente (junto con tus delegaciones) para cubrir tus asignaciones abiertas.
+
+### ¿Cuánto tiempo tengo para confirmar la transferencia de mi stake a Arbitrum?
+
+\*\*\* Debes confirmar tu transacción para completar la transferencia del stake en Arbitrum. Este paso debe completarse dentro de los 7 días, de lo contrario, el stake podría perderse.
+
+### ¿Qué sucede si tengo allocations abiertas?
+
+Si no estás enviando la totalidad de tu stake, la herramienta de transferencia a L2 validará que al menos el mínimo de 100.000 GRT permanezca en Ethereum mainnet y que tu stake y delegación restantes sean suficientes para cubrir cualquier allocation abierta. Es posible que debas cerrar allocations abiertas si tu saldo de GRT no cubre los mínimos + allocations abiertas.
+
+### ¿Es necesario esperar 28 días para retirar el stake en Ethereum mainnet antes de realizar la transferencia utilizando las herramientas de transferencia?
+
+No, puedes transferir tu stake a L2 de inmediato, no es necesario retirarlo y esperar antes de utilizar la herramienta de transferencia. La espera de 28 días solo aplica si deseas retirar el stake de regreso a tu wallet, ya sea en Ethereum mainnet o en L2.
+
+### ¿Cuánto tardaré en transferir mi stake?
+
+La herramienta de transferencia L2 tardará aproximadamente 20 minutos en completar la transferencia de tu stake.
+
+### ¿Tengo que indexar en Arbitrum antes de transferir mi stake?
+
+En efecto, puedes transferir tu stake primero antes de configurar la indexación de manera efectiva, pero no podrás reclamar ninguna recompensa en L2 hasta que asignes a subgrafos en L2, los indexes y presentes POIs.
+
+### ¿Pueden los Delegadores trasladar su delegación antes de que yo traslade mi stake de Indexador?
+
+No, para que los Delegadores puedan transferir su GRT delegado a Arbitrum, el Indexador en el que delegan debe estar activo en L2.
+
+### ¿Puedo transferir mi stake si estoy utilizando un contrato de liberación gradual de GRT (GRT vesting contract) o una wallet de bloqueo de tokens?
+
+¡Sí! El proceso es un poco diferente porque los contratos de vesting no pueden transferir el ETH necesario para pagar el gas en L2, por lo que debes depositarlo de antemano. Si tu contrato de vesting aún no ha sido completamente adquirido, también deberás inicializar un contrato de vesting equivalente en L2 y solo podrás transferir el stake a este contrato de vesting en L2. La interfaz de usuario en Explorer puede guiarte a través de este proceso cuando te hayas conectado a Explorer utilizando la wallet de bloqueo de vesting.
+
+### Ya tengo participación en L2. ¿Todavía necesito enviar 100,000 GRT cuando use las herramientas de transferencia por primera vez?
+
+Sí. Los contratos inteligentes de L1 no tendrán conocimiento de tu participación en L2, por lo que requerirán que transfieras al menos 100,000 GRT cuando realices la transferencia por primera vez
+
+### ¿Puedo transferir mi participación a L2 si estoy en proceso de retirar GRT?
+
+No. Si alguna fracción de tu participación se encuentra desbloqueandose, debes esperar los 28 días y retirarla antes de poder transferir la participación. Los tokens que se están apostando están "bloqueados" y evitarán cualquier transferencia o participación en L2.
+
+## Transferencia de Contrato de Vesting
+
+### ¿Cómo transfiero mi contrato de vesting?
+
+Para transferir tu contrato de vesting, deberás completar los siguientes pasos:
+
+1. Inicia la transferencia del vesting en Ethereum mainnet
+
+2. Espera 20 minutos para la confirmación
+
+3. Confirma la transferencia del contrato de vesting en Arbitrum
+
+### ¿Cómo transfiero mi contrato de vesting si solo está parcialmente adquirido?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Deposita una cantidad de ETH en el contrato de la herramienta de transferencia (la interfaz de usuario puede ayudar a estimar una cantidad razonable)
+
+2. Envía un poco de GRT bloqueado a través del contrato de la herramienta de transferencia, a L2 para inicializar el bloqueo de vesting en L2. Esto también establecerá su dirección de beneficiario en L2.
+
+3. Envía tu stake/delegación a L2 a través de las funciones de transferencia "bloqueada" en el contrato L1Staking.
+
+4. Retira cualquier ETH restante del contrato de la herramienta de transferencia
+
+### ¿Cómo transfiero mi contrato de vesting si está completamente adquirido?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+Para aquellos que están completamente adquiridos, el proceso es similar:
+
+1. Deposita una cantidad de ETH en el contrato de la herramienta de transferencia (la interfaz de usuario puede ayudar a estimar una cantidad razonable)
+
+2. Establece tu dirección de L2 con una llamada al contrato de la herramienta de transferencia
+
+3. Envía tu stake/delegación a L2 a través de las funciones de transferencia "bloqueada" en el contrato de Staking de L1.
+
+4. Retira cualquier ETH restante del contrato de la herramienta de transferencia
+
+### ¿Puedo transferir mi contrato de vesting a Arbitrum?
+
+Puedes transferir el saldo de GRT de tu contrato de vesting a un contrato de vesting en L2. Esto es un requisito previo para transferir el stake o la delegación de tu contrato de vesting a L2. El contrato de vesting debe contener una cantidad distinta de cero de GRT (puedes transferir una pequeña cantidad, como 1 GRT, si es necesario).
+
+Cuando transfieres GRT desde tu contrato de vesting en L1 a L2, puedes elegir la cantidad que deseas enviar y puedes hacerlo tantas veces como desees. El contrato en L2 se inicializará la primera vez que transfieras GRT.
+
+Las transferencias se realizan utilizando una herramienta de transferencia que estará visible en tu perfil de Explorer cuando te conectes con la cuenta del contrato de vesting.
+
+Ten en cuenta que no podrás liberar/retirar GRT del contrato de vesting en L2 hasta el final de tu período de vesting, cuando tu contrato esté completamente adquirido. Si necesitas liberar GRT antes de ese momento, puedes transferir el GRT de regreso al contrato de vesting en L1 utilizando otra herramienta de transferencia disponible para ese propósito.
+
+Si no has transferido ningún saldo del contrato de vesting a L2 y tu contrato de vesting está completamente adquirido, no debes transferir tu contrato de vesting a L2. En su lugar, puedes usar las herramientas de transferencia para establecer una dirección de wallet en L2 y transferir directamente tu stake o delegación a esta wallet regular en L2.
+
+### Si estoy utilizando mi contrato de vesting para realizar stake en la red principal, ¿puedo transferir mi stake a Arbitrum?
+
+Sí, pero si tu contrato aún tiene vesting, solo puedes transferir el stake para que sea propiedad de tu contrato de vesting en L2. Debes inicializar primero este contrato en L2 transfiriendo un saldo de GRT usando la herramienta de transferencia de contrato de vesting en Explorer. Si tu contrato está completamente adquirido, puedes transferir tu stake a cualquier dirección en L2, pero debes configurarla con antelación y depositar algo de ETH para que la herramienta de transferencia en L2 pague por las tarifas de gas en L2.
+
+### Si estoy utilizando mi contrato de vesting para delegar en mainnet, ¿puedo transferir mis delegaciones a Arbitrum?
+
+Sí, pero si tu contrato aún tiene vesting, solo puedes transferir la delegación para que sea propiedad de tu contrato de vesting en L2. Debes inicializar primero este contrato en L2 transfiriendo un saldo de GRT usando la herramienta de transferencia de contrato de vesting en Explorer. Si tu contrato está completamente adquirido, puedes transferir tu delegación a cualquier dirección en L2, pero debes configurarla con antelación y depositar algo de ETH para que la herramienta de transferencia en L2 pague por las tarifas de gas en L2.
+
+### ¿Puedo especificar un beneficiario diferente para mi contrato de vesting en L2?
+
+Sí, la primera vez que transfieras un saldo y configures tu contrato de vesting en L2, puedes especificar un beneficiario en L2. Asegúrate de que este beneficiario sea una wallet que pueda realizar transacciones en Arbitrum One, es decir, debe ser una cuenta de propietario externa (EOA) o un contrato de firma múltiple implementado en Arbitrum One.
+
+Si tu contrato está completamente adquirido, no configurarás un contrato de vesting en L2; en su lugar, establecerás una dirección de wallet en L2 y esta será la wallet receptora para tu stake o delegación en Arbitrum.
+
+### Mi contrato está completamente adquirido. ¿Puedo transferir mi stake o delegación a otra dirección que no es un contrato de vesting en L2?
+
+Si. Si no has transferido ningún saldo de contrato de vesting a L2 y tu contrato de vesting está completamente adquirido, no debes transferir tu contrato de vesting a L2. En su lugar, puedes utilizar las herramientas de transferencia para establecer una dirección de wallet en L2 y transferir directamente tu stake o delegación a esta wallet regular en L2.
+
+Esto te permite transferir tu stake o delegación a cualquier dirección en L2.
+
+### Mi contrato de vesting todavía está en proceso de vesting, ¿cómo transfiero el saldo de mi contrato de vesting a L2?
+
+Estos pasos solo se aplican si tu contrato todavía tiene vesting o si has utilizado este proceso antes cuando tu contrato todavía tenía vesting.
+
+Para transferir tu contrato de vesting a L2, enviarás cualquier saldo de GRT a L2 utilizando las herramientas de transferencia, lo que inicializará tu contrato de vesting en L2:
+
+1. Deposita algo de ETH en el contrato de la herramienta de transferencia (esto se usará para pagar el gas de L2)
+
+2. Revoca el acceso del protocolo al contrato de vesting (necesario para el siguiente paso)
+
+3. Otorga acceso del protocolo al contrato de vesting (permitirá que tu contrato interactúe con la herramienta de transferencia)
+
+4. Especifica una dirección de beneficiario en L2\* e inicia la transferencia de saldo en Ethereum mainnet
+
+5. Espera 20 minutos para la confirmación
+
+6. Confirma la transferencia de saldo en L2
+
+\*Si es necesario - i.e. si estás utilizando una dirección de contrato.
+
+\*\*\*\*Debes confirmar tu transacción para completar la transferencia de saldo en Arbitrum. Este paso debe completarse en un plazo de 7 días, o el saldo podría perderse. En la mayoría de los casos, este paso se ejecutará automáticamente, pero puede ser necesaria una confirmación manual si hay un aumento en el precio del gas en Arbitrum. Si surgen problemas durante este proceso, habrá recursos disponibles para ayudarte: ponte en contacto con el soporte en support@thegraph.com o en [Discord](https://discord.gg/graphprotocol).
+
+### Mi contrato de bloqueo de participación muestra 0 GRT, por lo que no puedo transferirlo. ¿Por qué sucede esto y cómo puedo solucionarlo?
+
+Para inicializar tu contrato de bloqueo en L2, debes transferir una cantidad no nula de GRT a L2. Esto es requerido por el puente de GRT de Arbitrum que es utilizado por las Herramientas de Transferencia en L2. Los GRT deben provenir del saldo del contrato de bloqueo, por lo que no incluye GRT apostados o delegados.
+
+Si has apostado o delegado todo tu GRT del contrato de bloqueo, puedes enviar manualmente una pequeña cantidad, como 1 GRT, a la dirección del contrato de bloqueo desde cualquier otro lugar (por ejemplo, desde otra billetera o desde una plataforma de intercambio)
+
+### Estoy utilizando un contrato de bloqueo para apostar o delegar, pero no veo un botón para transferir mi participación o delegación a L2, ¿qué debo hacer?
+
+Si tu contrato de bloqueo aún no ha terminado de bloquear, primero debes crear un contrato de bloqueo en L2 que recibirá tu participación o delegación en L2. Este contrato de bloqueo no permitirá liberar tokens en L2 hasta el final del período de bloqueo, pero te permitirá transferir GRT de vuelta al contrato de bloqueo en L1 para que sean liberados allí.
+
+Cuando estés conectado al contrato de bloqueo en el Explorador, deberías ver un botón para inicializar tu contrato de bloqueo en L2. Sigue ese proceso primero y luego verás los botones para transferir tu participación o delegación en tu perfil
+
+### Si inicializo mi contrato de bloqueo en L2, ¿esto transferirá automáticamente mi delegación a L2?
+
+No, inicializar tu contrato de bloqueo en L2 es un requisito previo para transferir la participación o delegación desde el contrato de bloqueo, pero aún así necesitas hacer estas transferencias por separado.
+
+Verás un banner en tu perfil que te indicará que transfieras tu participación o delegación después de haber inicializado tu contrato de bloqueo en L2.
+
+### ¿Puedo trasladar mi contrato de bloqueo de nuevo a L1?
+
+No es necesario hacerlo porque tu contrato de vesting todavía está en L1. Cuando utilizas las herramientas de transferencia, simplemente creas un nuevo contrato en L2 que está conectado con tu contrato de vesting en L1, y puedes enviar GRT de un lado a otro entre los dos.
+
+### ¿Por qué necesito mover mi contrato de vesting para empezar?
+
+Necesitas configurar un contrato de vesting en L2 para que esta cuenta pueda ser propietaria de tu stake o delegación en L2. De lo contrario, no habría forma de transferir el stake/delegación a L2 sin "escapar" del contrato de vesting.
+
+### ¿Qué sucede si intento cobrar mi contrato cuando solo está parcialmente adquirido? ¿Es posible hacerlo?
+
+Esto no es posible. Puedes mover los fondos de regreso a L1 y retirarlos desde allí.
+
+### ¿Qué sucede si no quiero trasladar mi contrato de vesting a L2?
+
+Puedes seguir realizando stake/delegando en L1. Con el tiempo, es posible que desees considerar el traslado a L2 para habilitar las recompensas allí a medida que el protocolo se escala en Arbitrum. Ten en cuenta que estas herramientas de transferencia son para contratos de vesting que están permitidos para staking y delegación en el protocolo. Si tu contrato no permite staking o delegación, o es revocable, entonces no hay disponible ninguna herramienta de transferencia. Aún podrás retirar tu GRT de L1 cuando esté disponible.

From 56a31427a5eadb8250e32bca28ceb647654d7243 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:42 -0500
Subject: [PATCH 1025/3820] New translations l2-transfer-tools-faq.mdx (Arabic)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/ar/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/ar/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/ar/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..e746544bbc66
--- /dev/null
+++ b/website/pages/ar/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: الأسئلة الشائعة حول أدوات النقل L2
+---
+
+## عام
+
+### ما هي أدوات النقل L2؟
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### هل يمكنني استخدام نفس المحفظة التي استخدمها في Ethereum mainnet؟
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### What happens if I don’t finish my transfer in 7 days?
+
+The L2 Transfer Tools use Arbitrum’s native mechanism to send messages from L1 to L2. This mechanism is called a “retryable ticket” and is used by all native token bridges, including the Arbitrum GRT bridge. You can read more about retryable tickets in the [Arbitrum docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+When you transfer your assets (subgraph, stake, delegation or curation) to L2, a message is sent through the Arbitrum GRT bridge which creates a retryable ticket in L2. The transfer tool includes some ETH value in the transaction, that is used to 1) pay to create the ticket and 2) pay for the gas to execute the ticket in L2. However, because gas prices might vary in the time until the ticket is ready to execute in L2, it is possible that this auto-execution attempt fails. When that happens, the Arbitrum bridge will keep the retryable ticket alive for up to 7 days, and anyone can retry “redeeming” the ticket (which requires a wallet with some ETH bridged to Arbitrum).
+
+This is what we call the “Confirm” step in all the transfer tools - it will run automatically in most cases, as the auto-execution is most often successful, but it is important that you check back to make sure it went through. If it doesn’t succeed and there are no successful retries in 7 days, the Arbitrum bridge will discard the ticket, and your assets (subgraph, stake, delegation or curation) will be lost and can’t be recovered. The Graph core devs have a monitoring system in place to detect these situations and try to redeem the tickets before it’s too late, but it is ultimately your responsibility to ensure your transfer is completed in time. If you’re having trouble confirming your transaction, please reach out using [this form](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) and core devs will be there help you.
+
+### I started my delegation/stake/curation transfer and I'm not sure if it made it through to L2, how can I confirm that it was transferred correctly?
+
+If you don't see a banner on your profile asking you to finish the transfer, then it's likely the transaction made it safely to L2 and no more action is needed. If in doubt, you can check if Explorer shows your delegation, stake or curation on Arbitrum One.
+
+If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire.
+
+## نقل الـ Subgraph (الرسم البياني الفرعي)
+
+### كيفكيف أقوم بتحويل الـ subgraph الخاص بي؟
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+لنقل الـ subgraph الخاص بك ، ستحتاج إلى إكمال الخطوات التالية:
+
+1. ابدأ التحويل على شبكة Ethereum mainnet
+
+2. انتظر 20 دقيقة للتأكيد
+
+3. قم بتأكيد نقل الـ subgraph على Arbitrum \ \*
+
+4. قم بإنهاء نشر الـ subgraph على Arbitrum
+
+5. جدث عنوان URL للاستعلام (مستحسن)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### من أين يجب أن أبدأ التحويل ؟
+
+يمكنك بدء عملية النقل من [Subgraph Studio] (https://thegraph.com/studio/) ، [Explorer ،] (https://thegraph.com/explorer) أو من أي صفحة تفاصيل subgraph. انقر فوق الزر "Transfer Subgraph" في صفحة تفاصيل الرسم الـ subgraph لبدء النقل.
+
+### كم من الوقت سأنتظر حتى يتم نقل الـ subgraph الخاص بي
+
+يستغرق وقت النقل حوالي 20 دقيقة. يعمل جسر Arbitrum في الخلفية لإكمال نقل الجسر تلقائيًا. في بعض الحالات ، قد ترتفع تكاليف الغاز وستحتاج إلى تأكيد المعاملة مرة أخرى.
+
+### هل سيظل الـ subgraph قابلاً للاكتشاف بعد أن أنقله إلى L2؟
+
+سيكون الـ subgraph الخاص بك قابلاً للاكتشاف على الشبكة التي تم نشرها عليها فقط. على سبيل المثال ، إذا كان الـ subgraph الخاص بك موجودًا على Arbitrum One ، فيمكنك العثور عليه فقط في Explorer على Arbitrum One ولن تتمكن من العثور عليه على Ethereum. يرجى التأكد من تحديد Arbitrum One في مبدل الشبكة في أعلى الصفحة للتأكد من أنك على الشبكة الصحيحة. بعد النقل ، سيظهر الـ L1 subgraph على أنه مهمل.
+
+### هل يلزم نشر الـ subgraph الخاص بي لنقله؟
+
+للاستفادة من أداة نقل الـ subgraph ، يجب أن يكون الرسم البياني الفرعي الخاص بك قد تم نشره بالفعل على شبكة Ethereum الرئيسية ويجب أن يكون لديه إشارة تنسيق مملوكة للمحفظة التي تمتلك الرسم البياني الفرعي. إذا لم يتم نشر الرسم البياني الفرعي الخاص بك ، فمن المستحسن أن تقوم ببساطة بالنشر مباشرة على Arbitrum One - ستكون رسوم الغاز أقل بكثير. إذا كنت تريد نقل رسم بياني فرعي منشور ولكن حساب المالك لا يملك إشارة تنسيق عليه ، فيمكنك الإشارة بمبلغ صغير (على سبيل المثال 1 GRT) من ذلك الحساب ؛ تأكد من اختيار إشارة "auto-migrating".
+
+### ماذا يحدث لإصدار Ethereum mainnet للرسم البياني الفرعي الخاص بي بعد أن النقل إلى Arbitrum؟
+
+بعد نقل الرسم البياني الفرعي الخاص بك إلى Arbitrum ، سيتم إهمال إصدار Ethereum mainnet. نوصي بتحديث عنوان URL للاستعلام في غضون 48 ساعة. ومع ذلك ، هناك فترة سماح تحافظ على عمل عنوان URL للشبكة الرئيسية الخاصة بك بحيث يمكن تحديث أي دعم dapp لجهة خارجية.
+
+### بعد النقل ، هل أحتاج أيضًا إلى إعادة النشر على Arbitrum؟
+
+بعد فترة النقل البالغة 20 دقيقة ، ستحتاج إلى تأكيد النقل لإكمال النقل ، أداة النقل ستوجهك للقيام بذلك. سيستمر دعم L1 endpoint الخاص بك خلال فترة النقل وفترة السماح. من المستحسن أن تقوم بتحديثه عندما يكون ذلك مناسبًا لك.
+
+### Will my endpoint experience downtime while re-publishing?
+
+It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the subgraph on L1 and whether they keep indexing it until the subgraph is fully supported on L2.
+
+### هل يتم نشر وتخطيط الإصدار بنفس الطريقة في الـ L2 كما هو الحال في شبكة Ethereum Ethereum mainnet؟
+
+Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the subgraph.
+
+### هل سينتقل تنسيق الـ subgraph مع الـ subgraph ؟
+
+إذا اخترت إشارة الترحيل التلقائي auto-migrating ، فسيتم نقل 100٪ من التنسيق مع الرسم البياني الفرعي الخاص بك إلى Arbitrum One. سيتم تحويل كل إشارة التنسيق الخاصة بالرسم الفرعي إلى GRT في وقت النقل ، وسيتم استخدام GRT المقابل لإشارة التنسيق الخاصة بك لصك الإشارة على L2 subgraph.
+
+يمكن للمنسقين الآخرين اختيار ما إذا كانوا سيسحبون أجزاء من GRT ، أو ينقلونه أيضًا إلى L2 لإنتاج إشارة على نفس الرسم البياني الفرعي.
+
+### هل يمكنني إعادة الرسم البياني الفرعي الخاص بي إلى Ethereum mainnet بعد أن أقوم بالنقل؟
+
+بمجرد النقل ، سيتم إهمال إصدار شبكة Ethereum mainnet للرسم البياني الفرعي الخاص بك. إذا كنت ترغب في العودة إلى mainnet ، فستحتاج إلى إعادة النشر (redeploy) والنشر مرة أخرى على mainnet. ومع ذلك ، لا يُنصح بشدة بالتحويل مرة أخرى إلى شبكة Ethereum mainnet حيث سيتم في النهاية توزيع مكافآت الفهرسة بالكامل على Arbitrum One.
+
+### لماذا أحتاج إلى Bridged ETH لإكمال النقل؟
+
+يتم دفع رسوم الغاز في Arbitrum One باستخدام ETHbridged ETH (ETH الذي تم ربطه بـ Arbitrum One). ومع ذلك ، فإن رسوم الغاز أقل بكثير عند مقارنتها بشبكة Ethereum mainnet.
+
+## Delegation(التفويض)
+
+### كيف أنقل تفويضي؟
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+لنقل تفويضك ، ستحتاج إلى إكمال الخطوات التالية:
+
+1. ابدأ نقل التفويض على شبكة Ethereum mainnet
+2. انتظر 20 دقيقة للتأكيد
+3. قم بتأكيد نقل التفويض على Arbitrum
+
+\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### ماذا يحدث لمكافآتي إذا بدأت عملية تحويل وكان لا يزال التخصيص مفتوحا على Ethereum mainnet؟
+
+If the Indexer to whom you're delegating is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer.
+
+### ماذا يحدث إذا كان المفهرس الذي أفوضه حاليًا غير موجود في Arbitrum One؟
+
+لن يتم تمكين أداة النقل L2 إلا إذا قام المفهرس الذي فوضته بتحويل حصته إلى Arbitrum.
+
+### هل يملك المفوضين خيارا للتفويض إلى مفهرس آخر؟
+
+If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to.
+
+### ماذا لو لم أتمكن من العثور على المفهرس الذي قمت بالتوفيض إليه في L2؟
+
+ستكتشف أداة النقل L2 المفهرس الذي قمت بالتفويض إليه مسبقًا تلقائيًا.
+
+### هل سأكون قادرًا على المزج والمطابقة أو "نشر" تفويضي عبر مفهرس جديد أو مفهرسين جدد بدلاً من المفهرس السابق؟
+
+ستعمل أداة نقل L2 دائمًا على نقل التفويض إلى نفس المفهرس الذي فوضته سابقًا. وبمجرد الانتقال إلى L2 ، يمكنك إلغاء التفويض وانتظار فترة الذوبان ، وتحديد ما إذا كنت ترغب في تقسيم التفويض الخاص بك.
+
+### هل أنا خاضع لفترة الانتظار أم يمكنني السحب فورًا بعد استخدام أداة نقل التفويض L2؟
+
+تتيح لك أداة النقل الانتقال على الفور إلى L2. إذا كنت ترغب في إلغاء التفويض ، فسيتعين عليك انتظار فترة الذوبان. ومع ذلك ، إذا قام المفهرس بتحويل جميع حصته إلى L2 ، فيمكنك السحب على شبكة Ethereum mainnet فورا.
+
+### هل يمكن أن تتأثر مكافآتي سلبًا إذا لم أحول تفويضي؟
+
+من المتوقع أن تنتقل جميع مشاركات الشبكة إلى Arbitrum One في المستقبل.
+
+### كم من الوقت يستغرق استكمال نقل تفويضي إلى L2؟
+
+A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Can I transfer my delegation if I'm using a GRT vesting contract/token lock wallet?
+
+Yes! The process is a bit different because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the delegation to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### هل هناك ضريبة على التفويض؟
+
+لا ، يتم تفويض التوكن المستلمة على L2 إلى المفهرس المحدد نيابة عن المفوض المحدد دون فرض ضريبة التفويض.
+
+### Will my unrealized rewards be transferred when I transfer my delegation?
+
+​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards.
+
+At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​
+
+### Is moving delegations to L2 mandatory? Is there a deadline?
+
+​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1?
+
+​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## Curation Signal(إشارة التنسيق)
+
+### كيف أنقل إشارة التنسيق الخاص بي؟
+
+لنقل التنسيق الخاص بك ، ستحتاج إلى إكمال الخطوات التالية:
+
+1. ابدأ نقل الإشارة على شبكة Ethereum mainnet
+
+2. حدد عنوان L2 للمنسق \ \*
+
+3. انتظر 20 دقيقة للتأكيد
+
+\ \* إذا لزم الأمر -أنت تستخدم عنوان عقد.
+
+### كيف سأعرف ما إذا كان الرسم البياني الفرعي الذي قمت بعمل إشارة تنسيق عليه قد انتقل إلى L2؟
+
+عند عرض صفحة تفاصيل الرسم البياني الفرعي ، ستعلمك لافتة بأنه تم نقل هذا الرسم البياني الفرعي. يمكنك اتباع التعليمات لنقل إشارة التنسيق الخاص بك. يمكنك أيضًا العثور على هذه المعلومات في صفحة تفاصيل الرسم البياني الفرعي لأي رسم بياني فرعي تم نقله.
+
+### ماذا لو كنت لا أرغب في نقل إشارة التنسيق الخاص بي إلى L2؟
+
+عندما يتم إهمال الرسم البياني الفرعي ، يكون لديك خيار سحب الإشارة. وبالمثل ، إذا انتقل الرسم البياني الفرعي إلى L2 ، فيمكنك اختيار سحب الإشارة في شبكة Ethereum الرئيسية أو إرسال الإشارة إلى L2.
+
+### كيف أعرف أنه تم نقل إشارة التنسيق بنجاح؟
+
+يمكن الوصول إلى تفاصيل الإشارة عبر Explorer بعد حوالي 20 دقيقة من بدء أداة النقل للـ L2.
+
+### هل يمكنني نقل إشاة التنسيق الخاص بي على أكثر من رسم بياني فرعي في وقت واحد؟
+
+لا يوجد خيار كهذا حالياً.
+
+## Indexer Stake(حصة المفهرس)
+
+### كيف يمكنني تحويل حصتي إلى Arbitrum؟
+
+> Disclaimer: If you are currently unstaking any portion of your GRT on your Indexer, you will not be able to use L2 Transfer Tools.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+لتحويل حصتك ، ستحتاج إلى إكمال الخطوات التالية:
+
+1. ابدأ تحويل الحصص على شبكة Ethereum mainnet
+
+2. انتظر 20 دقيقة للتأكيد
+
+3. Confirm stake transfer on Arbitrum
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### هل سيتم تحويل حصتي بالكامل؟
+
+يمكنك اختيار مقدار حصتك المراد تحويلها. إذا اخترت تحويل حصتك بالكامل مرة واحدة ، فستحتاج إلى إغلاق أي تخصيصات مفتوحة أولاً.
+
+إذا كنت تخطط لنقل أجزاء من حصتك في معاملات متعددة ، فيجب عليك دائمًا تحديد نفس عنوان المستفيد.
+
+ملاحظة: يجب أن تفي بالحد الأدنى من متطلبات الحصة على L2 في المرة الأولى التي تستخدم فيها أداة التحويل. يجب أن يرسل المفهرسون 100 ألف GRT كحد أدنى (عند استدعاء هذه الوظيفة في المرة الأولى). في حالة ترك جزء من الحصة على L1 ، يجب أن يكون أيضًا أكثر من 100 ألف GRT كحد أدنى وأن يكون كافيًا (جنبًا إلى جنب مع التفويضات) لتغطية مخصصاتك المفتوحة.
+
+### كم من الوقت لدي لتأكيد تحويل حصتي إلى Arbitrum؟
+
+\ _ \ _ \ \* يجب تأكيد معاملتك لإتمام تحويل الحصة على Arbitrum. يجب إكمال هذه الخطوة في غضون 7 أيام وإلا فقد يتم فقدان الحصة.
+
+### ماذا لو كان لدي تخصيصات مفتوحة؟
+
+إذا كنت لا ترسل كل حصصك، فإن أداة نقل L2 ستتحقق من أن الحد الأدنى 100 ألف GRT لا يزال في شبكة Ethereum mainnet وأن حصتك المتبقية وتفويضك كافيان لتغطية أي تخصيصات مفتوحة. قد تحتاج إلى إغلاق التخصيصات المفتوحة إذا كان رصيد GRT الخاص بك لا يغطي الحد الأدنى + المخصصات المفتوحة.
+
+### باستخدام أدوات النقل ، هل من الضروري الانتظار 28 يومًا لإلغاء الحصة في Ethereum mainnet قبل التحويل؟
+
+لا ، يمكنك تحويل حصتك إلى L2 على الفور ، ولا داعي لإلغاء حصتك والانتظار قبل استخدام أداة التحويل. لا يسري الانتظار لمدة 28 يومًا إلا إذا كنت ترغب في سحب الحصة إلى محفظتك ، على شبكة Ethereum mainnet أو L2.
+
+### كم من الوقت سيستغرق تحويل حصتي؟
+
+ستستغرق أداة النقل L2 حوالي 20 دقيقة لإكمال تحويل حصتك.
+
+### هل يجب أن أقوم بالفهرسة على Arbitrum قبل أن أنقل حصتي؟
+
+يمكنك تحويل حصتك بشكل فعال أولاً قبل إعداد الفهرسة ، ولكن لن تتمكن من المطالبة بأي مكافآت على L2 حتى تقوم بتخصيصها لـ subgraphs على L2 وفهرستها وعرض POIs.
+
+### هل يستطيع المفوضون نقل تفويضهم قبل نقل indexing stake الخاص بي؟
+
+لا ، لكي يقوم المفوضون بنقل GRT المفوضة إلى Arbitrum ، يجب أن يكون المفهرس الذي يتم التفويض إليه نشطًا في L2.
+
+### Can I transfer my stake if I'm using a GRT vesting contract / token lock wallet?
+
+Yes! The process is a bit different, because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the stake to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## نقل Vesting Contract(عقد الاستحقاق)
+
+### كيف أنقل عقد الاستحقاق الخاص بي؟
+
+لتحويل استحقاقك ، ستحتاج إلى إكمال الخطوات التالية:
+
+1. ابدأ تحويل الاستحقاق على شبكة Ethereum mainnet
+
+2. انتظر 20 دقيقة للتأكيد
+
+3. قم بالتأكيد على نقل الاستحقاق على Arbitrum
+
+### كيف يمكنني تحويل عقد الاستحقاق الخاص بي إذا كنت مخولًا جزئيًا فقط؟
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. قم بإيداع بعض ETH في عقد أداة النقل (يمكن أن تساعد واجهة المستخدم في تقدير مبلغ معقول)
+
+2. Send some locked GRT through the transfer tool contract, to L2 to initialize the L2 vesting lock. This will also set their L2 beneficiary address.
+
+3. Send their stake/delegation to L2 through the "locked" transfer tool functions in the L1Staking contract.
+
+4. سحب أي ETH متبقي من عقد أداة النقل(transfer tool contract)
+
+### كيف يمكنني تحويل عقد الاستحقاق الخاص بي إذا كنت مخولًا بالكامل؟
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+بالنسبة لمن يتمتعون بكامل الصلاحيات ، فإن العملية مماثلة:
+
+1. قم بإيداع بعض ETH في عقد أداة النقل (يمكن أن تساعد واجهة المستخدم في تقدير مبلغ معقول)
+
+2. قم بتعيين عنوان L2 الخاص بك من خلال استدعاء عقد أداة النقل
+
+3. أرسل حصتك / تفويضك إلى L2 من خلال وظائف أداة التحويل "locked" في L1 Staking contract.
+
+4. سحب أي ETH متبقي من عقد أداة النقل(transfer tool contract)
+
+### هل يمكنني نقل عقد الاستحقاق الخاص بي إلى Arbitrum؟
+
+يمكنك تحويل رصيد GRT الخاص بعقد الاستحقاق الخاص بك إلى عقد استحقاق آخر على L2. هذا شرط أساسي لنقل الحصة أو التفويض من عقد الاستحقاق الخاص بك إلى L2. يجب أن يحتوي عقد الاستحقاق على مبلغ غير صفري من GRT (يمكنك تحويل مبلغ صغير إليه مثل 1 GRT إذا لزم الأمر).
+
+عندما تقوم بتحويل GRT من عقد الاستحقاق L1 الخاص بك إلى L2 ، يمكنك اختيار المبلغ الذي تريد إرساله ويمكنك القيام بذلك عدة مرات. سيتم بدء عقد الاستحقاق على L2 في المرة الأولى التي تقوم فيها بتحويل GRT.
+
+تتم عمليات النقل باستخدام أداة النقل(Transfer Tool) التي ستكون مرئية في ملف تعريف Explorer الخاص بك عند الاتصال بحساب عقد الاستحقاق.
+
+يرجى ملاحظة أنك لن تكون قادرًا على استخلاص/ سحب GRT من عقد الاستحقاق على L2 حتى نهاية الجدول الزمني للاستحقاق عندما يتم تخويل عقدك بالكامل. إذا كنت بحاجة لتحرير GRT قبل ذلك الحين ، فيمكنك إعادة نقل GRT إلى عقد الاستحقاق على L1 باستخدام أداة تحويل أخرى متاحة لهذا الغرض.
+
+إذا لم تقم بتحويل أي رصيد من عقود الاستحقاق إلى L2 ، وكان عقد الاستحقاق الخاص بك مخولًا بالكامل ، فلا يجب عليك تحويل عقد الاستحقاق الخاص بك إلى L2. بدلاً من ذلك ، يمكنك استخدام أدوات التحويل لتعيين عنوان محفظة L2 ، وتحويل حصتك أو تفويضك مباشرةً إلى هذه المحفظة العادية على L2.
+
+### أنا أستخدم عقد الاستحقاق الخاص بي للقيام بالتخزين (staking) في mainnet. هل يمكنني تحويل حصتي إلى Arbitrum؟
+
+نعم ، ولكن إذا كان عقدك لا يزال مستحقًا ، فيمكنك فقط نقل الحصة بحيث تكون مملوكة لعقد الاستحقاق L2 الخاص بك. يجب أولاً تهيئة عقد L2 هذا عن طريق تحويل بعض رصيد GRT باستخدام أداة تحويل عقد الاستحقاق في Explorer. إذا كان عقدك مخولًا بالكامل ، فيمكنك تحويل حصتك إلى أي عنوان على L2 ، ولكن يجب عليك تعيينها مسبقًا وإيداع بعض ETH لأداة التحويل L2 لدفع ثمن غاز L2.
+
+### أنا أستخدم عقد الاستحقاق الخاص بي للتفويض على mainnet. هل يمكنني نقل تفويضاتي إلى Arbitrum؟
+
+نعم ، ولكن إذا كان عقدك لا يزال مستحقًا ، فيمكنك فقط نقل التفويض بحيث يكون مملوكًا لعقد الاستحقاق L2 الخاص بك. يجب أولاً تهيئة عقد L2 هذا عن طريق تحويل بعضا من رصيد GRT باستخدام أداة تحويل عقد الاستحقاق في Explorer. إذا كان عقدك مخولًا بالكامل ، فيمكنك نقل تفويضك إلى أي عنوان في L2 ، ولكن يجب عليك تعيينه مسبقًا وإيداع بعض ETH لأداة التحويل L2 لدفع ثمن غاز L2.
+
+### هل يمكنني تحديد مستفيد مختلف لعقد الاستحقاق الخاص بي على L2؟
+
+نعم ، في المرة الأولى التي تقوم فيها بتحويل رصيد وإعداد عقد استحقاق L2 ، يمكنك تحديد مستفيد من L2. تأكد من أن هذا المستفيد عبارة عن محفظة يمكنها إجراء المعاملات على Arbitrum One ، يجب أن تكون EOA أو multisig تم نشرها على Arbitrum One.
+
+إذا كان عقدك مخولًا بالكامل ، فلن تقوم بإعداد عقد استحقاق على L2 ؛ بدلاً من ذلك ، ستقوم بتعيين عنوان محفظة L2 وستكون هذه هي المحفظة المستلمة لحصتك أو تفويضك في Arbitrum.
+
+### عقدي مخول بالكامل. هل يمكنني نقل حصتي أو تفويضي إلى عنوان آخر ليس عقداً استحقاقيا على L2؟
+
+نعم. إذا لم تقم بتحويل أي رصيد من عقود الاستحقاق إلى L2 ، وكان عقد الاستحقاق الخاص بك مخولًا بالكامل ، فلا يجب عليك تحويل عقد الاستحقاق الخاص بك إلى L2. بدلاً من ذلك ، يمكنك استخدام أدوات التحويل لتعيين عنوان محفظة L2 ، وتحويل حصتك أو تفويضك مباشرةً إلى هذه المحفظة العادية على L2.
+
+هذا يسمح لك بتحويل حصتك أو تفويضك إلى أي عنوان L2.
+
+### عقد الاستحقاق الخاص بي لا يزال مستحقًا. كيف أقوم بتحويل رصيد عقد الاستحقاق الخاص بي إلى L2؟
+
+تنطبق هذه الخطوات فقط إذا كان عقدك لا يزال مستحقًا ، أو إذا كنت قد استخدمت هذه العملية من قبل عندما كان عقدك لا يزال مستحقًا.
+
+لتحويل عقد الاستحقاق الخاص بك إلى L2 ، سوف ترسل أي رصيد GRT إلى L2 باستخدام أدوات التحويل ، والتي ستعمل على تهيئة عقد استحقاق L2 الخاص بك:
+
+1. قم بإيداع بعض ETH في عقد أداة النقل (سيتم استخدام هذا لدفع ثمن غاز L2)
+
+2. إبطال وصول البروتوكول إلى عقد الاستحقاق (مطلوب للخطوة التالية)
+
+3. امنح البروتوكول حق الوصول إلى عقد الاستحقاق (سيسمح لعقدك بالتفاعل مع أداة التحويل)
+
+4. حدد عنوان المستفيد على L2 \ \* وابدأ في تحويل الرصيد على Ethereum mainnet
+
+5. انتظر 20 دقيقة للتأكيد
+
+6. قم بتأكيد تحويل الرصيد على L2
+
+\ \* إذا لزم الأمر -أنت تستخدم عنوان عقد.
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### هل يمكنني إرجاع عقد الاستحقاق إلى L1؟
+
+ليست هناك حاجة للقيام بذلك لأن عقد الاستحقاق الخاص بك لا يزال في L1. عندما تستخدم أدوات التحويل ، فأنت تقوم فقط بإنشاء عقد جديد في L2 مرتبط بعقد الاستحقاق L1 الخاص بك ، ويمكنك إرسال GRT ذهابًا وإيابًا بينهما.
+
+### لماذا أحتاج إلى تغيير عقد الاستحقاق الخاص بي من البداية؟
+
+يجب عليك إعداد عقد استحقاق L2 حتى يتمكن هذا الحساب من امتلاك حصتك أو تفويضك في L2. وإلا ، لن يكون هناك وسيلة لك لنقل الحصة / التفويض إلى L2 دون "الهروب" من عقد الاستحقاق.
+
+### ماذا يحدث إذا حاولت سحب عقدي عندما لم يتم تنفيذه بالكامل؟هل هذا ممكن؟
+
+هذا ليس احتمال. يمكنك إعادة الأموال إلى L1 وسحبها هناك.
+
+### ماذا لو لم أرغب في نقل عقد الاستحقاق الخاص بي إلى L2؟
+
+يمكنك الاستمرار في التخزين / التفويض على L1. بمرور الوقت ، قد ترغب في التفكير في الانتقال إلى L2 لتمكين المكافآت هناك حيث يتوسع البروتوكول في Arbitrum. لاحظ أن أدوات التحويل هذه مخصصة لمنح العقود المسموح لها بالمشاركة والتفويض في البروتوكول. إذا كان عقدك لا يسمح بالتخزين أو التفويض ، أو كان قابلاً للإلغاء ، فلا توجد أداة نقل متاحة. ستظل قادرًا على سحب GRT من L1 عندما يكون ذلك متاحًا.

From 2504f094a11cc41b58021ef1b4a7a10fc947bac2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:43 -0500
Subject: [PATCH 1026/3820] New translations l2-transfer-tools-faq.mdx (Czech)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/cs/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/cs/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/cs/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..d90fe0f20118
--- /dev/null
+++ b/website/pages/cs/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2 Transfer Tools FAQ
+---
+
+## Obecný
+
+### Co jsou nástroje pro přenos L2?
+
+Graph zlevnila náklady na účast přispěvatelů v síti 26krát tím, že nasadila protokol Arbitrum One. Nástroje pro přechod na L2 byly vytvořeny hlavními vývojáři, aby usnadnily a zjednodušily přechod na L2.
+
+Každý účastník sítě má k dispozici sadu nástrojů pro přenos L2, což umožňuje bezproblémový přechod na L2, Vyhněte se období rozmrazování nebo potřeby ručně odebrat a přemosťovat GRT.
+
+Tyto nástroje vyžadují, abyste provedli určitý soubor kroků v závislosti na tom, jaká je vaše role v systému The Graph a co přenášíte do L2.
+
+### Mohu používat stejnou peněženku, kterou používám na mainnet Ethereum?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Peněženky na blockchainech EVM, jako jsou Ethereum a Arbitrum, představují dvojici klíčů (veřejný a soukromý), které vytvoříte bez nutnosti interakce s blockchainem. Takže jakákoli peněženka vytvořená pro Ethereum bude fungovat i pro Arbitrum, aniž byste museli dělat cokoli jiného.
+
+Výjimkou jsou peněženky s chytrými smlouvami, jako je multisigs: jedná se o chytré smlouvy, které jsou nasazeny v každém řetězci zvlášť a při nasazení získávají svou adresu. Pokud byl multisig nasazen na Ethereum, nebude existovat se stejnou adresou na Arbitrum. Nový multisig musí být nejprve vytvořen v Arbitrum a může dostat jinou adresu.
+
+### Co se stane, když převod nedokončím do 7 dnů?
+
+Nástroje pro přenos L2 používají k odesílání zpráv z L1 do L2 nativní mechanismus Arbitrum. Tento mechanismus se nazývá 'retryable ticket,' a všechny nativní tokenové můstky, včetně můstku Arbitrum GRT, ho používají. Další informace o opakovatelných ticketch naleznete v části [Arbitrum docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+Při přenosu aktiv (podgraf, podíl, delegace nebo kurátorství) do L2 se odešle zpráva přes můstek Arbitrum GRT, která vytvoří opakovatelný tiket v L2. Nástroj pro převod zahrnuje v transakci určitou hodnotu ETH, která se použije na 1) zaplacení vytvoření tiketu a 2) zaplacení plynu pro provedení tiketu v L2. Se však ceny plynu mohou v době, než je ticket připraven k provedení v režimu L2, měnit. Je možné, že se tento pokus o automatické provedení nezdaří. Když se tak stane, most Arbitrum udrží opakovatelný tiket naživu až 7 dní a kdokoli se může pokusit o jeho "vykoupení" (což vyžaduje peněženku s určitým množstvím ETH propojenou s mostem Arbitrum).
+
+Tomuto kroku říkáme 'Potvrzení' ve všech nástrojích pro přenos - ve většině případů se spustí automaticky, protože automatické provedení je většinou úspěšné, ale je důležité, abyste se ujistili, že proběhlo. Pokud se to nepodaří a během 7 dnů nedojde k žádnému úspěšnému opakování, můstek Arbitrum tiket zahodí a vaše aktiva (podgraf, podíl, delegace nebo kurátorství) budou ztracena a nebude možné je obnovit. Vývojáři The Graph jádra mají k dispozici monitorovací systém, který tyto situace odhaluje a snaží se lístky uplatnit dříve, než bude pozdě, ale v konečném důsledku je vaší odpovědností zajistit, aby byl váš přenos dokončen včas. Pokud máte potíže s potvrzením transakce, obraťte se na nás pomocí [tohoto formuláře](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) a hlavní vývojáři vám pomohou.
+
+### Zahájil jsem přenos delegace/podílů/kurátorství a nejsem si jistý, zda se to dostalo do L2. Jak mohu potvrdit, že to bylo přeneseno správně?
+
+Pokud se na vašem profilu nezobrazí banner s výzvou k dokončení převodu, je pravděpodobné, že transakce proběhla bezpečně na server L2 a není třeba provádět další kroky. Pokud máte pochybnosti, můžete zkontrolovat, zda Průzkumník zobrazuje vaši delegaci, podíl nebo kurátorství na Arbitrum One.
+
+Pokud máte k dispozici hash transakce L1 (který zjistíte, když se podíváte na poslední transakce ve své peněžence), můžete si také ověřit, zda byl "retryable ticket", který přenesl zprávu na L2, vykoupen zde: https://retryable-dashboard.arbitrum.io/ - pokud automatické vykoupení selhalo, můžete svou peněženku připojit i tam a vykoupit ji. Můžete si být jisti, že vývojáři jádra také sledují zprávy, které se zaseknou, a pokusí se je vyplatit před vypršením jejich platnosti.
+
+## Podgraf přenos
+
+### Jak mohu přenést svůj podgraf?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+Chcete-li přenést svůj podgraf, musíte provést následující kroky:
+
+1. Zahájení převodu v mainnet Ethereum
+
+2. Počkejte 20 minut na potvrzení
+
+3. Potvrzení přenosu podgrafů na Arbitrum\*
+
+4. Úplné zveřejnění podgrafu na arbitrum
+
+5. Aktualizovat adresu URL dotazu (doporučeno)
+
+\*Upozorňujeme, že převod musíte potvrdit do 7 dnů, jinak může dojít ke ztrátě vašeho podgrafu. Ve většině případů se tento krok provede automaticky, ale v případě prudkého nárůstu cen plynu na Arbitru může být nutné ruční potvrzení. Pokud se během tohoto procesu vyskytnou nějaké problémy, budou k dispozici zdroje, které vám pomohou: kontaktujte podporu na adrese support@thegraph.com nebo na [Discord](https://discord.gg/graphprotocol).
+
+### Odkud mám iniciovat převod?
+
+Přenos můžete zahájit v [Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) nebo na libovolné stránce s detaily subgrafu. "Kliknutím na tlačítko 'Transfer Subgraph' na stránce s podrobnostmi o podgrafu zahájíte přenos.
+
+### Jak dlouho musím čekat, než bude můj podgraf přenesen
+
+Přenos trvá přibližně 20 minut. Most Arbitrum pracuje na pozadí a automaticky dokončí přenos mostu. V některých případech může dojít ke zvýšení nákladů na plyn a transakci bude nutné potvrdit znovu.
+
+### Bude můj podgraf zjistitelný i poté, co jej přenesu do L2?
+
+Váš podgraf bude zjistitelný pouze v síti, ve které je publikován. Pokud se například váš subgraf nachází na Arbitrum One, pak jej najdete pouze v Průzkumníku na Arbitrum One a na Ethereum jej nenajdete. Ujistěte se, že máte v přepínači sítí v horní části stránky vybranou možnost Arbitrum One, abyste se ujistili, že jste ve správné síti. Po přenosu se podgraf L1 zobrazí jako zastaralý.
+
+### Musí být můj podgraf zveřejněn, abych ho mohl přenést?
+
+Abyste mohli využít nástroj pro přenos subgrafů, musí být váš subgraf již zveřejněn v mainnet Ethereum a musí mít nějaký kurátorský signál vlastněný peněženkou, která subgraf vlastní. Pokud váš subgraf není zveřejněn, doporučujeme vám jednoduše publikovat přímo na Arbitrum One - související poplatky za plyn budou podstatně nižší. Pokud chcete přenést publikovaný podgraf, ale účet vlastníka na něm nemá kurátorský signál, můžete z tohoto účtu signalizovat malou částku (např. 1 GRT); nezapomeňte zvolit "auto-migrating" signál.
+
+### Co se stane s verzí mého subgrafu na ethereum mainnet po převodu na Arbitrum?
+
+Po převedení vašeho subgrafu na Arbitrum bude verze mainnet Ethereum zastaralá. Doporučujeme vám aktualizovat adresu URL dotazu do 48 hodin. Je však zavedena ochranná lhůta, která udržuje adresu URL mainnet funkční, aby bylo možné aktualizovat podporu dapp třetích stran.
+
+### Musím po převodu také znovu publikovat na Arbitrum?
+
+Po uplynutí 20minutového okna pro převod budete muset převod potvrdit transakcí v UI, abyste převod dokončili, ale nástroj pro převod vás tímto úkonem provede. Koncový bod L1 bude i nadále podporován během okna pro převody a po něm po dobu odkladu. doporučujeme, abyste svůj koncový bod aktualizovali, jakmile se vám to bude hodit.
+
+### Dojde při opětovném publikování k výpadku mého koncového bodu?
+
+Je nepravděpodobné, ale je možné, že dojde ke krátkému výpadku v závislosti na tom, které indexátory podporují podgraf na L1 a zda jej indexují, dokud není podgraf plně podporován na L2.
+
+### Je publikování a verzování na L2 stejné jako na mainnet Ethereum Ethereum?
+
+Ano. Při publikování v aplikaci Subgraph Studio vyberte jako publikovanou síť Arbitrum One. Ve Studiu bude k dispozici nejnovější koncový bod, který odkazuje na nejnovější aktualizovanou verzi podgrafu.
+
+### Bude se kurátorství mého podgrafu pohybovat spolu s mým podgrafem?
+
+Pokud jste zvolili automatickou migraci signálu, 100 % vaší vlastní kurátorství se přesune spolu s vaším subgrafem do Arbitrum One. Veškerý signál kurátorství podgrafu bude v okamžiku převodu převeden na GRT a GRT odpovídající vašemu signálu kurátorství bude použit k ražbě signálu na podgrafu L2.
+
+Ostatní kurátoři se mohou rozhodnout, zda stáhnou svou část GRT, nebo ji také převedou na L2, aby vyrazili signál na stejném podgraf.
+
+### Mohu svůj subgraf po převodu přesunout zpět do mainnet Ethereum?
+
+Po přenosu bude vaše verze tohoto podgrafu v síti Ethereum mainnet zneplatněna. Pokud se chcete přesunout zpět do mainnetu, musíte provést nové nasazení a publikovat zpět do mainnet. Převod zpět do mainnetu Etherea se však důrazně nedoporučuje, protože odměny za indexování budou nakonec distribuovány výhradně na Arbitrum One.
+
+### Proč potřebuji k dokončení převodu překlenovací ETH?
+
+Poplatky za plyn na Arbitrum One se platí pomocí přemostěného ETH (tj. ETH, který byl přemostěn na Arbitrum One). Poplatky za plyn jsou však ve srovnání s mainnet Ethereum výrazně nižší.
+
+## Delegace
+
+### Jak mohu přenést svou delegaci?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+Chcete-li přenést své delegování, musíte provést následující kroky:
+
+1. Zahájení přenosu delegace v mainnet Ethereum
+2. Počkejte 20 minut na potvrzení
+3. Potvrzení přenosu delegace na Arbitrum
+
+\*\*\*\*\*Pro dokončení převodu delegování na Arbitrum musíte transakci potvrdit. Tento krok musí být dokončen do 7 dnů, jinak by mohlo dojít ke ztrátě delegace. Ve většině případů se tento krok provede automaticky, ale v případě prudkého nárůstu cen plynu na platformě Arbitrum může být nutné provést ruční potvrzení. Pokud se během tohoto procesu vyskytnou nějaké problémy, budou k dispozici zdroje, které vám pomohou: kontaktujte podporu na support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Co se stane s mými odměnami, pokud iniciuji převod s otevřenou alokací v mainnet Ethereum?
+
+Pokud Indexer, na kterého delegujete, stále funguje na L1, při přechodu na Arbitrum ztratíte veškeré odměny za delegování z otevřených alokací v mainnet Ethereum. To znamená, že přijdete o odměny maximálně za posledních 28 dní. Pokud převod načasujete ihned po uzavření alokací indexeru, můžete zajistit, aby to bylo co nejméně. Pokud se svým indexátorem (indexátory) komunikujete, zvažte, zda s ním (nimi) neprojednáte nejvhodnější dobu pro převod.
+
+### Co se stane, když indexátor, na kterého právě deleguju, není v Arbitrum One?
+
+Nástroj pro převod L2 se aktivuje pouze v případě, že indexátor, kterého jste delegovali, převedl svůj vlastní podíl na Arbitrum.
+
+### Mají delegáti možnost delegovat na jiného indexátora?
+
+Pokud chcete delegovat na jiného indexátora, můžete převést na stejného indexátora na Arbitrum, poté odeberte a počkejte na dobu odmrazování. Poté můžete vybrat jiného aktivního indexátora, na kterého můžete delegovat.
+
+### Co když nemohu na L2 najít indexátora, kterého deleguji?
+
+Nástroj pro přenos L2 automaticky zjistí indexátor, který jste předtím delegovali.
+
+### Budu moci své delegace kombinovat nebo "rozložit" mezi nové nebo více indexátorů namísto předchozího indexátoru?
+
+Nástroj pro přenos L2 vždy přesune vaše delegování do stejného indexátora, do kterého jste delegovali dříve. Po přesunu na L2 můžete delegaci zrušit, počkat na dobu rozmrazení a rozhodnout se, zda chcete delegaci rozdělit.
+
+### Vztahuje se na mě období chladnutí, nebo mohu vyjmout ihned po použití nástroje pro přenos delegací L2?
+
+Nástroj pro přenos umožňuje okamžitý přesun na úroveň L2. Pokud chcete přenesení zrušit, musíte počkat na dobu rozmrazení. Pokud však indexer převedl celý svůj podíl na L2, můžete okamžitě vybírat v mainnet Ethereum.
+
+### Mohou být mé odměny negativně ovlivněny, pokud nepřevedu svou delegaci?
+
+Předpokládá se, že veškerá účast v síti se v budoucnu přesune do Arbitrum One.
+
+### Jak dlouho trvá dokončení převodu mé delegace do L2?
+
+Pro delegování je nutné 20minutové potvrzení. Upozorňujeme, že po uplynutí 20minutové lhůty se musíte vrátit a do 7 dnů dokončit 3. krok procesu převodu. Pokud tak neučiníte, může být vaše delegace ztracena. Všimněte si, že ve většině případů nástroj pro přenos provede tento krok automaticky za vás.V případě neúspěšného automatického pokusu je třeba jej dokončit ručně. Pokud se během tohoto procesu vyskytnou nějaké problémy, nemějte obavy, budeme vám k dispozici: support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Mohu přenést svou delegaci, pokud používám peněženku se smlouvou o převodu práv/zámkem na tokeny GRT?
+
+Ano! Proces je trochu odlišný, protože vestingové smlouvy nemohou přeposílat ETH potřebné k zaplacení plynu L2, takže je třeba je uložit předem. Pokud vaše vestingová smlouva není plně vestingová, budete muset také nejprve inicializovat protějškovou vestingovou smlouvu na L2 a delegaci budete moci převést pouze na tuto vestingovou smlouvu na L2. Uživatelské rozhraní Průzkumníka vás tímto procesem provede, pokud jste se k Průzkumníkovi připojili pomocí peněženky s vestingovým zámkem.
+
+### Umožňuje moje smlouva o převodu práv na Arbitrum uvolnění GRT stejně jako na mainnet?
+
+Ne, vestingová smlouva vytvořená na platformě Arbitrum neumožňuje uvolnění GRT až do konce časové osy vestingu, tj. dokud není vaše smlouva plně vestingová. Je to proto, aby se zabránilo dvojímu utrácení, protože jinak by bylo možné uvolnit stejné částky na obou vrstvách.
+
+Pokud chcete GRT z vestingové smlouvy uvolnit, můžete je pomocí Průzkumníka převést zpět do vestingové smlouvy L1: ve svém profilu Arbitrum One uvidíte banner s informací, že můžete GRT převést zpět do vestingové smlouvy mainnetu. To vyžaduje transakci na Arbitrum One, čekání 7 dní a konečnou transakci na mainnetu, protože se používá stejný nativní mechanismus přemostění z můstku GRT.
+
+### Existuje nějaká delegační daň?
+
+Ne. Přijaté tokeny na L2 jsou delegovány zadanému indexátorovi jménem zadaného delegáta bez účtování daně z delegování.
+
+### Budou mé nerealizované odměny převedeny při převodu delegace?
+
+Ano! Jediné odměny, které nelze převést, jsou odměny za otevřené alokace, protože ty nebudou existovat, dokud indexátor alokace neuzavře (obvykle každých 28 dní). Pokud delegujete již delší dobu, jedná se pravděpodobně jen o malý zlomek odměn.
+
+Na úrovni chytrého kontraktu jsou nerealizované odměny již součástí vašeho zůstatku delegace, takže budou převedeny při převodu delegace na L2,
+
+### Je přesun delegací na úroveň L2 povinný? Existuje nějaká lhůta?
+
+Přesun delegování na L2 není povinný, ale odměny za indexování se na L2 zvyšují podle časového plánu popsaného v [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Pokud bude Rada zvyšování odměn i nadále schvalovat, budou nakonec všechny odměny rozdělovány v L2 a indexátoři a delegáti nebudou mít na L1 žádné odměny za indexování
+
+### Pokud deleguji na indexátora, který již převedl podíl na L2, přestanu dostávat odměny na L1?
+
+Mnoho indexátorů převádí podíly postupně, takže indexátoři na L1 budou stále získávat odměny a poplatky na L1, které jsou pak sdíleny s delegáty. Jakmile indexátor převede celý svůj podíl, přestane působit na L1, takže delegáti již nedostanou žádnou odměnu, pokud nepřevedou na L2.
+
+Pokud Rada bude i nadále schvalovat zvyšování odměn za indexaci na L2, budou nakonec všechny odměny rozděleny na L2 a na L1 nebudou žádné odměny za indexaci pro indexátory a delegáty.
+
+### Nevidím tlačítko pro přenos delegace. Proč tomu tak je?
+
+Váš indexovač pravděpodobně ještě nepoužil nástroje pro přenos L2 k přenosu kůl.
+
+Pokud se vám podaří kontaktovat indexátora, můžete ho vyzvat, aby použil nástroje pro přenos L2, aby delegáti mohli přenášet delegace na adresu indexátora L2.
+
+### Můj Indexer je také na Arbitrum, ale v profilu nevidím tlačítko pro přenos delegování. Proč tomu tak je?
+
+Je možné, že indexátor nastavil operace na L2, ale nepoužil nástroje pro přenos L2 k přenosu sázek. Chytré kontrakty L1 proto nebudou znát adresu L2 indexátoru. Pokud se vám podaří Indexera kontaktovat, můžete ho vyzvat, aby použil nástroj pro přenos, aby mohli Delegáti přenést delegace na adresu Indexera L2.
+
+### Mohu své pověření převést na L2, pokud jsem zahájil proces odebrání pověření a ještě jsem ho neodebral?
+
+Ne. Pokud vaše delegace rozmrazuje, musíte počkat 28 dní a stáhnout ji.
+
+Tokeny, které nejsou delegovány, jsou "uzamčeny", a proto je nelze přenést na L2.
+
+## Kurátorský signál
+
+### Jak mohu přenést své kurátorství?
+
+Chcete-li přenést své kurátorství, musíte provést následující kroky:
+
+1. Zahájení přenosu signálu v mainnet Ethereum
+
+2. Zadejte adresu kurátora L2\*
+
+3. Počkejte 20 minut na potvrzení
+
+\*Pokud je to nutné - tj. používáte smluvní adresu.
+
+### Jak se dozvím, že se mnou kurátorovaný podgraf přesunul do L2?
+
+Při zobrazení stránky s podrobnostmi podgrafu se zobrazí banner s upozorněním, že tento podgraf byl přenesen. Můžete následovat výzvu k přenosu kurátorství. Tyto informace najdete také na stránce s podrobnostmi o podgrafu, který se přesunul.
+
+### Co když si nepřeji přesunout své kurátorství do L2?
+
+Pokud je podgraf vyřazen, máte možnost stáhnout svůj signál. Stejně tak pokud se podgraf přesunul do L2, můžete si vybrat, zda chcete stáhnout svůj signál v mainnet Ethereum, nebo signál poslat do L2.
+
+### Jak poznám, že se moje kurátorství úspěšně přeneslo?
+
+Podrobnosti o signálu budou k dispozici prostřednictvím Průzkumníka přibližně 20 minut po spuštění nástroje pro přenos L2.
+
+### Mohu přenést své kurátorství na více než jeden podgraf najednou?
+
+V současné době není k dispozici možnost hromadného přenosu.
+
+## Podíl indexátoru
+
+### Jak mohu převést svůj podíl do společnosti Arbitrum?
+
+> Odmítnutí odpovědnosti: Pokud v současné době na svém indexovači rozkládáte jakoukoli část GRT, nebudete moci používat nástroje pro přenos L2.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+Chcete-li svůj podíl převést, musíte provést následující kroky:
+
+1. Zahájení převodu podílu v mainnet Ethereum
+
+2. Počkejte 20 minut na potvrzení
+
+3. Potvrzení převodu podílu na Arbitrum
+
+\*Upozorňujeme, že převod musíte potvrdit do 7 dnů, jinak může váš vklad propadnout. Ve většině případů tento krok proběhne automaticky, ale v případě prudkého nárůstu ceny plynu na Arbitrum může být nutné ruční potvrzení. Pokud se během tohoto procesu vyskytnou nějaké problémy, budou k dispozici zdroje, které vám pomohou: kontaktujte podporu na adrese support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Bude převeden celý můj podíl?
+
+Můžete si vybrat, jakou část svého vkladu chcete převést. Pokud se rozhodnete převést celý svůj podíl najednou, musíte nejprve uzavřít všechny otevřené alokace.
+
+Pokud plánujete převést část svého podílu ve více transakcích, musíte vždy zadat stejnou adresu příjemce.
+
+Poznámka: Při prvním použití nástroje pro převod musíte splnit požadavky na minimální vklad na serveru L2. Indexátoři musí odeslat minimálně 100 tisíc GRT (při prvním volání této funkce). Pokud ponecháváte část podílu na L1, musí být také vyšší než minimální hodnota 100 000 GRT a musí být dostatečná (spolu s vašimi delegacemi) k pokrytí vašich otevřených přídělů.
+
+### Kolik času mám na potvrzení převodu podílu na společnost Arbitrum?
+
+\*\*\* Pro dokončení převodu sázek na Arbitrum musíte transakci potvrdit. Tento krok musí být dokončen do 7 dnů, jinak může dojít ke ztrátě podílu.
+
+### Co když mám otevřené příděly?
+
+Pokud neposíláte celý svůj podíl, nástroj pro převod L2 ověří, že v mainnet Ethereum zůstává alespoň minimální 100k GRT a že váš zbývající podíl a delegace stačí na pokrytí všech otevřených alokací. Pokud váš zůstatek GRT nepokrývá minima + otevřené alokace, může být nutné otevřené alokace uzavřít.
+
+### Je nutné při použití nástrojů pro převod čekat 28 dní na unstake v mainnet Ethereum před převodem?
+
+Ne, svůj vklad můžete na L2 převést ihned, není třeba ho vybírat a čekat, než použijete nástroj pro převod. 28denní čekací lhůta platí pouze v případě, že chcete vybrat vklad zpět do své peněženky v mainnet Ethereum nebo L2.
+
+### Jak dlouho bude trvat převod mého podílu?
+
+Nástroj pro převod L2 dokončí převod vašeho podílu přibližně za 20 minut.
+
+### Musím před převodem svého podílu indexovat na Arbitrum?
+
+Před nastavením indexování můžete nejprve efektivně převést svůj podíl, ale nebudete si moci nárokovat žádné odměny na L2, dokud nepřidělíte podgrafy na L2, neindexujete je a nepředložíte POIs.
+
+### Mohou delegáti přesunout svou delegaci dříve, než přesunu svůj indexovací podíl?
+
+Ne, aby mohli delegáti přenést své delegované GRT do společnosti Arbitrum, musí být indexátor, na kterého delegují, aktivní na L2.
+
+### Mohu převést svůj podíl, pokud používám smlouvu o převodu GRT / peněženku se zámkem token?
+
+Ano! Proces je trochu jiný, protože vestingové smlouvy nemohou přeposílat ETH potřebné k zaplacení plynu L2, takže je třeba je vložit předem. Pokud vaše smlouva o převodu podílu není plně vestovaná, budete muset také nejprve inicializovat protějšek smlouvy o převodu podílu na L2 a podíl budete moci převést pouze na tuto smlouvu o převodu podílu na L2. Uživatelské rozhraní Průzkumníka vás tímto procesem provede, pokud jste se k Průzkumníkovi připojili pomocí peněženky s vestingovým zámkem.
+
+### Na L2 už mám podíl. Musím ještě poslat 100k GRT, když poprvé použiji převodní nástroje?
+
+Ano, chytré kontrakty L1 nebudou znát váš podíl L2, takže budou vyžadovat, abyste při prvním převodu převedli alespoň 100 tisíc GRT.
+
+### Mohu poslat svůj podíl do L2, pokud jsem v procesu odebírání podílu GRT?
+
+Ne Pokud dojde k rozmrazení jakékoli části vaší sázky, musíte počkat 28 dní a vybrat ji, než budete moci sázku převést. Tokeny, které jsou vsazeny, jsou „uzamčeny“ a zabrání jakémukoli převodu nebo vkladu do L2.
+
+## Přenos vestovací smlouvy
+
+### Jak mohu převést svou smlouvu o vestování?
+
+Chcete-li převést své nároky, musíte provést následující kroky:
+
+1. Zahájení vesting v mainnet Ethereum
+
+2. Počkejte 20 minut na potvrzení
+
+3. Potvrzení vesting na Arbitrum
+
+### Ak mohu převést svou smlouvu o vesting, pokud mám pouze částečná práva?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Vložte nějaký ETH do smlouvy o převodním nástroji (uživatelské rozhraní může pomoci odhadnout rozumnou částku)
+
+2. Odeslání některých uzamčených GRT prostřednictvím smlouvy nástroje pro přenos do L2, aby se inicializoval zámek vestingu L2. Tím se také nastaví jejich adresa příjemce L2.
+
+3. Odeslat svůj podíl/delegaci na L2 prostřednictvím funkce "uzamčeného" převodního nástroje ve smlouvě L1Staking.
+
+4. Vybrat zbývající ETH ze smlouvy o převodním nástroji
+
+### Jak mohu převést svou smlouvu o vesting práv, pokud jsem získal/a plná práva?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+U těch, kteří jsou plně vested, je postup podobný:
+
+1. Vložte nějaký ETH do smlouvy o převodním nástroji (uživatelské rozhraní může pomoci odhadnout rozumnou částku)
+
+2. Nastavení adresy L2 pomocí volání smlouvy o přenosovém nástroji
+
+3. Svůj vklad/delegaci odešlete na L2 pomocí funkce "uzamčeného" převodního nástroje ve smlouvě o sázkách L1.
+
+4. Vybrat zbývající ETH ze smlouvy o převodním nástroji
+
+### Mohu svou smlouvu o převodu vesting převést na společnost Arbitrum?
+
+Je možné převést zůstatek GRT ze smlouvy o vesting na smlouvu o vesting v L2. Toto je předpokladem pro převod sázky nebo delegace ze smlouvy o vesting do L2. Smlouva o převodu musí obsahovat nenulové množství GRT (v případě potřeby do ní můžete převést malé množství, například 1 GRT).
+
+Při převodu GRT ze smlouvy L1 do L2 si můžete zvolit částku, kterou chcete poslat, a můžete to udělat tolikrát, kolikrát chcete. Při prvním převodu GRT bude inicializována vesting smlouva L2.
+
+Převody se provádějí pomocí nástroje pro převody, který se zobrazí ve vašem profilu Průzkumníka po připojení k účtu se smlouvou o vestingu.
+
+Mějte na paměti, že nebudete moci uvolnit/vyjmout GRT z vesting smlouvy L2 až do konce vaší vesting časové osy, kdy bude vaše smlouva plně vested. Pokud potřebujete uvolnit GRT před tímto termínem, můžete převést GRT zpět do L1 vesting smlouvy pomocí jiného převodního nástroje, který je k dispozici pro tento účel.
+
+Pokud jste nepřevedli žádný zůstatek z vesting smlouvy do L2 a vaše vesting smlouva je plně vested, neměli byste převádět vaši vesting smlouvu do L2. Místo toho můžete použít nástroje pro převod k nastavení L2 adresy peněženky a přímo převést svůj vklad nebo delegaci na tuto běžnou peněženku na L2.
+
+### Používám svou vestingovou smlouvu ke sázení v mainnet. Mohu převést svůj podíl na Arbitrum?
+
+Ano, ale pokud je vaše smlouva stále ve fázi vesting, můžete převést pouze podíl tak, aby byl vlastněn vaší vesting smlouvou L2. Musíte nejprve inicializovat tuto smlouvu L2 převodem nějakého zůstatku GRT pomocí nástroje pro převod vestingové smlouvy v Průzkumníku. Pokud je vaše smlouva plně vesting, můžete převést svůj podíl na libovolnou adresu v L2, ale musíte ji nastavit předem a vložit nějaký ETH pro nástroj převodu na L2, aby mohl platit za L2 plyn.
+
+### K delegování na mainnet používám smlouvu o vesting. Mohu své delegace přenést na Arbitrum?
+
+Ano, ale pokud je vaše smlouva stále ve fázi delegace, mohli jste převést pouze podíl tak, aby byl vlastněn vaší delegační smlouvou L2. Museli jste nejprve inicializovat tuto smlouvu L2 převodem nějakého zůstatku GRT pomocí nástroje pro převod delegační smlouvy v Průzkumníku. Pokud je vaše smlouva plně delegovalo, mohli jste převést svůj podíl na libovolnou adresu v L2, ale museli jste ji nastavit předem a vložit nějaký ETH pro nástroj převodu na L2, aby mohl platit za L2 plyn.
+
+### Mohu na L2 zadat jiného příjemce pro smlouvu o převodu vesting?
+
+Ano, poprvé, když převedete zůstatek a nastavíte svou smlouvu o vesting na L2, můžete specifikovat L2 příjemce. Ujistěte se, že tento příjemce je peněženka, která může provádět transakce na Arbitrum One, tj. musí to být EOA nebo multisig nasazený na Arbitrum One.
+
+Pokud je vaše smlouva plně vested, nebudete nastavovat vesting smlouvu na L2; místo toho nastavíte adresu peněženky na L2 a tato adresa bude příjmovou peněženkou pro váš podíl nebo delegaci na Arbitrum.
+
+### Moje smlouva je plně vested. Mohu převést svůj podíl nebo delegaci na jinou adresu, která není vesting smlouvou na L2?
+
+Ano. Pokud jste do L2 nepřevedli žádný zůstatek na smlouvě s nárokem na vesting a vaše smlouva s nárokem na vesting je plně vested, neměli byste smlouvu s nárokem na vesting převádět do L2. Místo toho můžete pomocí nástrojů pro převod nastavit adresu peněženky L2 a přímo převést svůj podíl nebo delegaci do této běžné peněženky na L2.
+
+Díky tomu můžete svůj podíl nebo delegaci převést na libovolnou adresu L2.
+
+### Moje vesting smlouva stále vestuje. Jak převedu zůstatek mé vesting smlouvy na L2?
+
+Tyto kroky platí pouze v případě, že je vaše smlouva stále vesting, nebo pokud jste tento postup použili již dříve, když byla vaše smlouva stále vesting.
+
+Chcete-li převést svou vesting smlouvu na L2, odešlete veškerý zůstatek GRT na L2 pomocí nástrojů pro převod, čímž se inicializuje vaše vesting smlouva na L2:
+
+1. Vložte nějaký ETH do smlouvy o převodním nástroji (bude použit na zaplacení plynu L2)
+
+2. Zrušení přístupu protokolu k vestingové smlouvě (nutné pro další krok)
+
+3. Poskytněte protokol přístup ke smlouvě o vesting (umožní vaší smlouvě komunikovat s nástrojem pro převod)
+
+4. Zadejte adresu příjemce L2\* a iniciujte převod zůstatku v mainnet Ethereum
+
+5. Počkejte 20 minut na potvrzení
+
+6. Potvrzení převodu zůstatku na L2
+
+\*Pokud je to nutné - tj. používáte smluvní adresu.
+
+\*\*\*\*\*Pro dokončení převodu zůstatku na Arbitrum musíte transakci potvrdit. Tento krok musí být dokončen do 7 dnů, jinak může dojít ke ztrátě zůstatku. Ve většině případů se tento krok provede automaticky, ale pokud dojde ke skokovému nárůstu cen plynu na Arbitrum, může být nutné provést ruční potvrzení. Pokud se během tohoto procesu vyskytnou nějaké problémy, budou k dispozici zdroje, které vám pomohou: kontaktujte podporu na adrese support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Moje smlouva o vesting ukazuje 0 GRT, takže ji nemohu převést. Proč tomu tak je a jak to mohu napravit?
+
+Abyste mohli inicializovat smlouvu o převodu vesting L2, musíte do L2 převést nenulovou částku GRT. To vyžaduje můstek Arbitrum GRT, který používají nástroje pro převod L2. GRT musí pocházet ze zůstatku smlouvy o vesting převodu práv, takže nezahrnuje vsazené nebo delegované GRT.
+
+Pokud jste vsadili nebo delegovali všechny GRT z vesting kontraktu, můžete na adresu vesting kontraktu ručně poslat malou částku, například 1 GRT, odkudkoli jinde (např. z jiné peněženky nebo burzy).
+
+### Používám smlouvu s vesting právy k podílu nebo delegování, ale nemohu nalézt tlačítko pro převod podílu nebo delegování na L2. Jak mám postupovat?
+
+Pokud vaše smlouva o vesting převodu práv ještě nedokončila převod práv, musíte nejprve vytvořit smlouvu o vesting převodu práv na L2, která obdrží váš podíl nebo delegaci na L2. Tato vesting smlouva neumožní uvolnění tokenů na L2 až do konce časové osy vesting, ale umožní vám převést GRT zpět na vesting smlouvu L1, abyste je mohli uvolnit tam.
+
+Po připojení k vesting smlouvě v Průzkumníku by se mělo zobrazit tlačítko pro inicializaci vesting smlouvy L2. Nejprve proveďte tento proces a poté se ve vašem profilu zobrazí tlačítka pro převod podílu nebo delegování
+
+### Pokud inicializuji smlouvu o převodu vesting práv L2, přenesou se tím automaticky i mé delegace do L2?
+
+Ne, inicializace vesting smlouvy L2 je předpokladem pro převod podílu nebo delegování z vestingové smlouvy, ale i tak je třeba je převést samostatně.
+
+Po inicializaci smlouvy o vesting na L2 uvidíte na svém profilu banner s výzvou k převodu svého podílu nebo delegace.
+
+### Mohu přesunout svou vesting smlouvu zpět na L1?
+
+Není to nutné, protože vaše vesting smlouva stále zůstává v L1. Při používání nástrojů pro převod vytvoříte pouze novou smlouvu v L2, která je propojená s vaší vesting smlouvou v L1, a můžete posílat GRT tam a zpět mezi oběma.
+
+### Proč vůbec potřebuji přesunout vesting smlouvu?
+
+Je třeba nastavit vesting smlouvu na L2, aby tento účet mohl vlastnit váš podíl nebo delegaci na L2. Jinak byste neměli možnost převést podíl/delegaci na L2, aniž byste 'unikli' vesting smlouvě.
+
+### Co se stane, když se pokusím vyplatit svoji vesting smlouvu, když je pouze částečně vested? Je to možné?
+
+To není možné. Prostředky můžete přesunout zpět na účet L1 a vybrat je tam.
+
+### Co když nechci přesunout svoji vesting smlouvu do L2?
+
+Na L1 můžete pokračovat ve sázkách/delegaci. Časem možná budete chtít zvážit přesun na L2, abyste tam umožnili odměny, protože protokol se na Arbitru škáluje. Všimněte si, že tyto přenosové nástroje jsou určeny pro smlouvy s právy, které mají v protokolu povoleno sázet a delegovat. Pokud vaše smlouva neumožňuje sázení nebo delegování nebo je odvolatelná, pak není k dispozici žádný nástroj pro přenos. I tak budete moci vybrat svůj GRT z L1, jakmile bude k dispozici.

From d1f5bbd123dff299b558663c70195cd1dba53cce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:44 -0500
Subject: [PATCH 1027/3820] New translations l2-transfer-tools-faq.mdx (German)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/de/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/de/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/de/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..d5b536456532
--- /dev/null
+++ b/website/pages/de/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2-Übertragungs-Tools FAQ
+---
+
+## Allgemein
+
+### Was sind L2-Transfer-Tools?
+
+The Graph hat die Teilnahme am Netzwerk für Mitwirkende um das 26-fache kostengünstiger gemacht, indem das Protokoll auf Arbitrum One bereitgestellt wurde. Die L2-Transfer-Tools wurden von den Kernentwicklern entwickelt, um den Wechsel zu L2 zu erleichtern.
+
+Für jeden Netzwerkteilnehmer stehen eine Reihe von L2-Transfer-Tools zur Verfügung, die einen nahtlosen Übergang zu L2 ermöglichen, ohne dass Auftauzeiten entstehen oder GRT manuell entnommen und überbrückt werden müssen.
+
+Für diese Tools müssen Sie eine Reihe von Schritten befolgen, je nachdem, welche Rolle Sie bei The Graph spielen und was Sie auf L2 übertragen.
+
+### Kann ich dieselbe Wallet verwenden, die ich im Ethereum Mainnet benutze?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets auf EVM-Blockchains wie Ethereum und Arbitrum bestehen aus einem Paar von Schlüsseln (öffentlich und privat), die Sie erstellen, ohne mit der Blockchain interagieren zu müssen. Jede Wallet, die für Ethereum erstellt wurde, funktioniert also auch auf Arbitrum, ohne dass Sie etwas anderes tun müssen.
+
+Die Ausnahme sind Smart-Contract-Wallets wie Multisigs: Das sind Smart Contracts, die auf jeder Kette separat eingesetzt werden und ihre Adresse erhalten, wenn sie eingesetzt werden. Wenn ein Multisig auf Ethereum bereitgestellt wurde, wird er nicht mit der gleichen Adresse auf Arbitrum existieren. Ein neuer Multisig muss zuerst auf Arbitrum erstellt werden und kann eine andere Adresse erhalten.
+
+### Was passiert, wenn ich meinen Transfer nicht innerhalb von 7 Tagen abschließe?
+
+Die L2-Transfer-Tools verwenden den nativen Mechanismus von Arbitrum, um Nachrichten von L1 nach L2 zu senden. Dieser Mechanismus wird "retryable ticket" genannt und wird von allen nativen Token-Bridges verwendet, einschließlich der Arbitrum GRT-Bridge. Sie können mehr über wiederholbare Tickets in den [Arbitrum docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging) lesen.
+
+Wenn Sie Ihre Vermögenswerte (Subgraph, Anteil, Delegation oder Kuration) an L2 übertragen, wird eine Nachricht über die Arbitrum GRT-Brücke gesendet, die ein wiederholbares Ticket in L2 erstellt. Das Transfer-Tool beinhaltet einen gewissen ETH-Wert in der Transaktion, der verwendet wird, um 1) die Erstellung des Tickets und 2) das Gas für die Ausführung des Tickets in L2 zu bezahlen. Da jedoch die Gaspreise in der Zeit, bis das Zertifikat zur Ausführung in L2 bereit ist, schwanken können, ist es möglich, dass dieser automatische Ausführungsversuch fehlschlägt. Wenn das passiert, hält die Arbitrum-Brücke das wiederholbare Zertifikat für bis zu 7 Tage am Leben, und jeder kann versuchen, das Ticket erneut "einzulösen" (was eine Geldbörse mit etwas ETH erfordert, die mit Arbitrum verbunden ist).
+
+Dies ist der so genannte "Bestätigungsschritt" in allen Übertragungswerkzeugen - er wird in den meisten Fällen automatisch ausgeführt, da die automatische Ausführung meist erfolgreich ist, aber es ist wichtig, dass Sie sich vergewissern, dass die Übertragung erfolgreich war. Wenn dies nicht gelingt und es innerhalb von 7 Tagen keine erfolgreichen Wiederholungsversuche gibt, verwirft die Arbitrum-Brücke das Ticket, und Ihre Assets (Subgraph, Pfahl, Delegation oder Kuration) gehen verloren und können nicht wiederhergestellt werden. Die Entwickler des Graph-Kerns haben ein Überwachungssystem eingerichtet, um diese Situationen zu erkennen und zu versuchen, die Tickets einzulösen, bevor es zu spät ist, aber es liegt letztendlich in Ihrer Verantwortung, sicherzustellen, dass Ihr Transfer rechtzeitig abgeschlossen wird. Wenn Sie Probleme mit der Bestätigung Ihrer Transaktion haben, wenden Sie sich bitte an [dieses Formular] (https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) und die Entwickler des Kerns werden Ihnen helfen.
+
+### Ich habe mit der Übertragung meiner Delegation/des Einsatzes/der Kuration begonnen und bin mir nicht sicher, ob sie an L2 weitergeleitet wurde. Wie kann ich bestätigen, dass sie korrekt übertragen wurde?
+
+If you don't see a banner on your profile asking you to finish the transfer, then it's likely the transaction made it safely to L2 and no more action is needed. If in doubt, you can check if Explorer shows your delegation, stake or curation on Arbitrum One.
+
+If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire.
+
+## Subgraph-Transfer
+
+### Wie übertrage ich meinen Subgraphen
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+Um Ihren Subgraphen zu übertragen, müssen Sie die folgenden Schritte ausführen:
+
+1. Starten Sie den Transfer im Ethereum-Mainnet
+
+2. 20 Minuten auf Bestätigung warten
+
+3. Bestätigung der Übertragung von Subgraphen auf Arbitrum\*
+
+4. Veröffentlichung des Subgraphen auf Arbitrum beenden
+
+5. Abfrage-URL aktualisieren (empfohlen)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Von wo aus soll ich meine Übertragung veranlassen?
+
+Sie können die Übertragung vom [Subgraph Studio] (https://thegraph.com/studio/), vom [Explorer] (https://thegraph.com/explorer) oder von einer beliebigen Subgraph-Detailseite aus starten. Klicken Sie auf die Schaltfläche "Subgraph übertragen" auf der Detailseite des Subgraphen, um die Übertragung zu starten.
+
+### Wie lange muss ich warten, bis mein Subgraph übertragen wird?
+
+Die Übertragungszeit beträgt etwa 20 Minuten. Die Arbitrum-Brücke arbeitet im Hintergrund, um den Übergang automatisch abzuschließen. In einigen Fällen können die Gaskosten in die Höhe schnellen und Sie müssen die Transaktion erneut bestätigen.
+
+### Wird mein Subgraph noch auffindbar sein, nachdem ich ihn auf L2 übertragen habe?
+
+Ihr Subgraph ist nur in dem Netzwerk auffindbar, in dem er veröffentlicht ist. Wenn Ihr Subgraph zum Beispiel auf Arbitrum One ist, können Sie ihn nur im Explorer auf Arbitrum One finden und nicht auf Ethereum. Bitte vergewissern Sie sich, dass Sie Arbitrum One in der Netzwerkumschaltung oben auf der Seite ausgewählt haben, um sicherzustellen, dass Sie sich im richtigen Netzwerk befinden.  Nach der Übertragung wird der L1-Subgraph als veraltet angezeigt.
+
+### Muss mein Subgraph ( Teilgraph ) veröffentlicht werden, um ihn zu übertragen?
+
+Um das Subgraph-Transfer-Tool nutzen zu können, muss Ihr Subgraph bereits im Ethereum-Mainnet veröffentlicht sein und über ein Kurationssignal verfügen, das der Wallet gehört, die den Subgraph besitzt. Wenn Ihr Subgraph nicht veröffentlicht ist, empfehlen wir Ihnen, ihn einfach direkt auf Arbitrum One zu veröffentlichen - die damit verbundenen Gasgebühren sind erheblich niedriger. Wenn Sie einen veröffentlichten Subgraphen übertragen wollen, aber das Konto des Eigentümers kein Signal darauf kuratiert hat, können Sie einen kleinen Betrag (z.B. 1 GRT) von diesem Konto signalisieren; stellen Sie sicher, dass Sie ein "auto-migrating" Signal wählen.
+
+### Was passiert mit der Ethereum-Mainnet-Version meines Subgraphen, nachdem ich zu Arbitrum übergehe?
+
+Nach der Übertragung Ihres Subgraphen auf Arbitrum wird die Ethereum-Hauptnetzversion veraltet sein. Wir empfehlen Ihnen, Ihre Abfrage-URL innerhalb von 48 Stunden zu aktualisieren. Es gibt jedoch eine Schonfrist, die Ihre Mainnet-URL funktionsfähig hält, so dass jede Drittanbieter-Dapp-Unterstützung aktualisiert werden kann.
+
+### Muss ich nach der Übertragung auch auf Arbitrum neu veröffentlichen?
+
+Nach Ablauf des 20-minütigen Übertragungsfensters müssen Sie die Übertragung mit einer Transaktion in der Benutzeroberfläche bestätigen, um die Übertragung abzuschließen. Ihr L1-Endpunkt wird während des Übertragungsfensters und einer Schonfrist danach weiterhin unterstützt. Es wird empfohlen, dass Sie Ihren Endpunkt aktualisieren, wenn es Ihnen passt.
+
+### Will my endpoint experience downtime while re-publishing?
+
+It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the subgraph on L1 and whether they keep indexing it until the subgraph is fully supported on L2.
+
+### Ist die Veröffentlichung und Versionierung auf L2 die gleiche wie im Ethereum-Mainnet?
+
+Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the subgraph.
+
+### Bewegt sich die Kuration meines Untergraphen ( Subgraphen ) mit meinem Untergraphen?
+
+Wenn Sie die automatische Signalmigration gewählt haben, werden 100 % Ihrer eigenen Kuration mit Ihrem Subgraphen zu Arbitrum One übertragen. Alle Kurationssignale des Subgraphen werden zum Zeitpunkt des Transfers in GRT umgewandelt, und die GRT, die Ihrem Kurationssignal entsprechen, werden zum Prägen von Signalen auf dem L2-Subgraphen verwendet.
+
+Andere Kuratoren können wählen, ob sie ihren Anteil an GRT zurückziehen oder ihn ebenfalls auf L2 übertragen, um das Signal auf demselben Untergraphen zu prägen.
+
+### Kann ich meinen Subgraph nach dem Transfer zurück ins Ethereum Mainnet verschieben?
+
+Nach der Übertragung wird Ihre Ethereum-Mainnet-Version dieses Untergraphen veraltet sein. Wenn Sie zum Mainnet zurückkehren möchten, müssen Sie Ihre Version neu bereitstellen und zurück zum Mainnet veröffentlichen. Es wird jedoch dringend davon abgeraten, zurück ins Ethereum Mainnet zu wechseln, da die Indexierungsbelohnungen schließlich vollständig auf Arbitrum One verteilt werden.
+
+### Warum brauche ich überbrückte ETH, um meine Überweisung abzuschließen?
+
+Gasgebühren auf Arbitrum One werden mit überbrückter ETH bezahlt (d.h. ETH, die zu Arbitrum One überbrückt wurde). Allerdings sind die Gasgebühren im Vergleich zum Ethereum Mainnet deutlich niedriger.
+
+## Delegation
+
+### Wie übertrage ich meine Delegation?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+Um Ihre Delegation zu übertragen, müssen Sie die folgenden Schritte ausführen:
+
+1. Initiieren einer Delegationsübertragung im Ethereum-Mainnet
+2. 20 Minuten auf Bestätigung warten
+3. Bestätigung der Delegationsübertragung auf Arbitrum
+
+\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Was passiert mit meinen Rewards, wenn ich einen Transfer mit einer offenen Zuteilung im Ethereum Mainnet initiiere?
+
+If the Indexer to whom you're delegating is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer.
+
+### Was passiert, wenn der Indexer, an den ich derzeit delegiere, nicht auf Arbitrum One ist?
+
+Das L2-Transfer-Tool wird nur aktiviert, wenn der Indexer, den Sie delegiert haben, seinen eigenen Anteil an Arbitrum übertragen hat.
+
+### Haben Delegatoren die Möglichkeit, an einen anderen Indexierer zu delegieren?
+
+If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to.
+
+### Was ist, wenn ich den Indexer, an den ich delegiere, auf L2 nicht finden kann?
+
+Das L2-Übertragungstool erkennt automatisch den Indexer, an den Sie zuvor delegiert haben.
+
+### Kann ich meine Delegationen auf neue oder mehrere Indexer statt auf den vorherigen Indexer verteilen?
+
+Mit dem L2-Transfertool wird Ihre Delegation immer an denselben Indexer übertragen, an den Sie zuvor delegiert haben. Sobald Sie zu L2 umgezogen sind, können Sie die Delegation aufheben, die Auftauzeit abwarten und entscheiden, ob Sie Ihre Delegation aufteilen möchten.
+
+### Unterliege ich der Wartezeit oder kann ich sofort abheben, nachdem ich das L2 Delegationstool benutzt habe?
+
+Mit dem Transfer-Tool können Sie sofort zu L2 wechseln. Wenn Sie den Transfer wieder rückgängig machen möchten, müssen Sie die Sperrfrist abwarten. Wenn ein Indexer jedoch seinen gesamten Einsatz auf L2 übertragen hat, können Sie sofort auf dem Ethereum-Mainnet abheben.
+
+### Kann es sich negativ auf meine Prämien auswirken, wenn ich meine Delegation nicht übertrage?
+
+Es wird davon ausgegangen, dass die gesamte Netzbeteiligung in Zukunft zu Arbitrum One wechseln wird.
+
+### Wie lange dauert es, bis die Übertragung meiner Delegation auf L2 abgeschlossen ist?
+
+A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Kann ich meine Delegation übertragen, wenn ich eine GRT Vesting Contract/Token Lock Wallet verwende?
+
+Ja! Der Prozess ist ein wenig anders, weil Vesting-Verträge die ETH, die für die Bezahlung des L2-Gases benötigt werden, nicht weiterleiten können, also müssen Sie sie vorher einzahlen. Wenn Ihr Berechtigungsvertrag nicht vollständig freigeschaltet ist, müssen Sie außerdem zuerst einen Gegenkontrakt auf L2 initialisieren und können die Delegation dann nur auf diesen L2-Berechtigungsvertrag übertragen. Die Benutzeroberfläche des Explorers kann Sie durch diesen Prozess leiten, wenn Sie sich über die Vesting Lock Wallet mit dem Explorer verbunden haben.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### Fällt eine Delegationssteuer an?
+
+Nein. Auf L2 erhaltene Token werden im Namen des angegebenen Delegators an den angegebenen Indexierer delegiert, ohne dass eine Delegationssteuer erhoben wird.
+
+### Will my unrealized rewards be transferred when I transfer my delegation?
+
+​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards.
+
+At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​
+
+### Is moving delegations to L2 mandatory? Is there a deadline?
+
+​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1?
+
+​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## Kurationssignal
+
+### Wie übertrage ich meine Kuration?
+
+Um Ihre Kuration zu übertragen, müssen Sie die folgenden Schritte ausführen:
+
+1. Signalübertragung im Ethereum-Mainnet einleiten
+
+2. Spezifizieren Sie eine L2-Kurator-Adresse\*
+
+3. 20 Minuten auf Bestätigung warten
+
+\* Falls erforderlich - d.h. wenn Sie eine Vertragsadresse verwenden.
+
+### Wie erfahre ich, ob der von mir kuratierte Subgraph nach L2 umgezogen ist?
+
+Auf der Seite mit den Details der Subgraphen werden Sie durch ein Banner darauf hingewiesen, dass dieser Subgraph übertragen wurde. Sie können der Aufforderung folgen, um Ihre Kuration zu übertragen. Diese Information finden Sie auch auf der Seite mit den Details zu jedem verschobenen Subgraphen.
+
+### Was ist, wenn ich meine Kuration nicht auf L2 verschieben möchte?
+
+Wenn ein Subgraph veraltet ist, haben Sie die Möglichkeit, Ihr Signal zurückzuziehen. Wenn ein Subgraph nach L2 verschoben wurde, können Sie wählen, ob Sie Ihr Signal im Ethereum-Mainnet zurückziehen oder das Signal an L2 senden.
+
+### Woran erkenne ich, dass meine Kuration erfolgreich übertragen wurde?
+
+Die Signaldetails werden etwa 20 Minuten nach dem Start des L2-Transfertools über den Explorer zugänglich sein.
+
+### Kann ich meine Kuration auf mehr als einen Subgraphen zur gleichen Zeit übertragen?
+
+Zurzeit gibt es keine Option für Massenübertragungen.
+
+## Indexer-Einsatz
+
+### Wie übertrage ich meine Anteile auf Arbitrum?
+
+> Disclaimer: If you are currently unstaking any portion of your GRT on your Indexer, you will not be able to use L2 Transfer Tools.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+Um Ihren Einsatz zu übertragen, müssen Sie die folgenden Schritte ausführen:
+
+1. Initiieren Sie den Stake-Transfer im Ethereum-Mainnet
+
+2. 20 Minuten auf Bestätigung warten
+
+3. Bestätigen Sie die Übertragung von Anteilen auf Arbitrum
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Wird mein gesamter Einsatz übertragen?
+
+Sie können wählen, wie viel von Ihrem Einsatz Sie übertragen möchten. Wenn Sie Ihren gesamten Einsatz auf einmal übertragen möchten, müssen Sie zunächst alle offenen Zuteilungen schließen.
+
+Wenn Sie vorhaben, Teile Ihres Anteils über mehrere Transaktionen zu übertragen, müssen Sie immer dieselbe Adresse des Begünstigten angeben.
+
+Hinweis: Sie müssen die Mindestanforderungen für den Einsatz auf L2 erfüllen, wenn Sie das Übertragungswerkzeug zum ersten Mal verwenden. Indexierer müssen (beim ersten Aufruf dieser Funktion) den Mindestbetrag von 100k GRT übermitteln. Wenn Sie einen Teil des Einsatzes auf L1 belassen, muss dieser ebenfalls über dem Minimum von 100k GRT liegen und (zusammen mit Ihren Delegationen) ausreichen, um Ihre offenen Zuteilungen zu decken.
+
+### Wie viel Zeit habe ich, um die Übertragung meiner Anteile auf Arbitrum zu bestätigen?
+
+\*\*\* Sie müssen Ihre Transaktion bestätigen, um die Übertragung des Einsatzes auf Arbitrum abzuschließen. Dieser Schritt muss innerhalb von 7 Tagen abgeschlossen werden, sonst kann der Einsatz verloren gehen.
+
+### Was ist, wenn ich offene Zuteilungen habe?
+
+Wenn Sie nicht Ihren gesamten Einsatz senden, prüft das L2-Transfer-Tool, ob mindestens 100k GRT im Ethereum-Mainnet verbleiben und Ihr verbleibender Einsatz und Ihre Delegation ausreichen, um alle offenen Zuteilungen zu decken. Möglicherweise müssen Sie offene Zuteilungen schließen, wenn Ihr GRT-Guthaben die Mindestbeträge + offene Zuteilungen nicht abdeckt.
+
+### Muss man bei der Verwendung der Transfer-Tools 28 Tage warten, bis man im Ethereum-Mainnet unstake ist, bevor man transferieren kann?
+
+Nein, Sie können Ihren Einsatz sofort auf L2 übertragen. Sie müssen den Einsatz nicht aufheben und warten, bevor Sie das Transfer-Tool verwenden. Die 28-tägige Wartezeit gilt nur, wenn Sie den Einsatz wieder auf Ihre Wallet, das Ethereum-Mainnet oder L2 auszahlen möchten.
+
+### Wie lange dauert es, bis mein Anteil übertragen wird?
+
+Es dauert etwa 20 Minuten, bis das L2-Transfertool die Übertragung Ihres Einsatzes abgeschlossen hat.
+
+### Muss ich auf Arbitrum indexieren, bevor ich meinen Einsatz übertrage?
+
+Sie können Ihren Einsatz zuerst überweisen, bevor Sie die Indizierung einrichten, aber Sie können keine Belohnungen auf L2 beanspruchen, bevor Sie Subgraphen auf L2 zuweisen, sie indizieren und POIs präsentieren.
+
+### Können Delegatoren ihre Delegation verschieben, bevor ich meine Indizierungsbeteiligung verschiebe?
+
+Nein, damit Delegatoren ihre delegierten GRT an Arbitrum übertragen können, muss der Indexer, an den sie delegieren, auf L2 aktiv sein.
+
+### Kann ich meinen Einsatz übertragen, wenn ich einen GRT Sperrvertrag / ein Token Lock Wallet verwende?
+
+Ja! Der Prozess ist ein wenig anders, weil Vesting-Verträge die ETH, die für die Bezahlung des L2-Gases benötigt werden, nicht weiterleiten können, so dass Sie sie vorher einzahlen müssen. Wenn Ihr Freizügigkeitsvertrag nicht vollständig freigeschaltet ist, müssen Sie außerdem zuerst einen Gegenkontrakt auf L2 initialisieren und können den Anteil nur auf diesen L2-Freizügigkeitsvertrag übertragen. Die Benutzeroberfläche des Explorers kann Sie durch diesen Prozess führen, wenn Sie sich mit dem Explorer über die Vesting Lock Wallet verbunden haben.
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## Unverfallbare Vertragsübertragung
+
+### Wie übertrage ich meinen Vesting-Vertrag?
+
+Um Ihren Einsatz zu übertragen, müssen Sie die folgenden Schritte ausführen:
+
+1. Initiieren Sie die Vesting-Übertragung im Ethereum-Mainnet
+
+2. 20 Minuten auf Bestätigung warten
+
+3. Bestätigen Sie die Übertragung von Anteilen auf Arbitrum
+
+### Wie übertrage ich meinen unverfallbaren Vertrag, wenn ich nur teilweise unverfallbar bin?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Zahlen Sie etwas ETH in den Transfer-Tool-Vertrag ein (UI kann helfen, einen angemessenen Betrag zu schätzen)
+
+2. Senden Sie einige gesperrte GRT über den Transfer-Tool-Vertrag an L2, um die L2-Freizügigkeitssperre zu initialisieren. Dadurch wird auch die Adresse des L2-Begünstigten festgelegt.
+
+3. Senden Sie Ihren Einsatz bzw. Ihre Delegation über die "gesperrten" Transfer-Tool-Funktionen im L1-Einsatzvertrag an L2.
+
+4. Restliche ETH aus dem Transfer-Tool-Vertrag abziehen
+
+### Wie übertrage ich meinen Freizügigkeitsvertrag, wenn ich eine vollständige Freizügigkeit erlangt habe?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+Für diejenigen, die voll berechtigt sind, ist das Verfahren ähnlich:
+
+1. Zahlen Sie etwas ETH in den Transfer-Tool-Vertrag ein (UI kann helfen, einen angemessenen Betrag zu schätzen)
+
+2. Stellen Sie Ihre L2-Adresse mit einem Aufruf des Transfer-Tool-Vertrags ein
+
+3. Senden Sie Ihren Einsatz bzw. Ihre Delegation über die "gesperrten" Transfer-Tool-Funktionen im L1-Einsatzvertrag an L2.
+
+4. Restliche ETH aus dem Transfer-Tool-Vertrag abziehen
+
+### Kann ich meinen Vesting-Vertrag auf Arbitrum übertragen?
+
+Sie können den GRT-Saldo Ihres Vesting-Vertrags auf einen Vesting-Vertrag in L2 übertragen. Dies ist eine Voraussetzung für die Übertragung von Anteilen oder Delegationen von Ihrem Freizügigkeitsvertrag auf L2. Der Vesting-Vertrag muss einen GRT-Betrag haben, der nicht Null ist (Sie können bei Bedarf einen kleinen Betrag wie 1 GRT auf ihn übertragen).
+
+Wenn Sie GRT von Ihrem L1-Vesting-Vertrag auf L2 übertragen, können Sie den Betrag wählen, den Sie senden möchten, und Sie können dies so oft tun, wie Sie möchten. Der Vesting-Vertrag L2 wird initialisiert, wenn Sie das erste Mal GRT übertragen.
+
+Die Übertragungen erfolgen über ein Übertragungstool, das in Ihrem Explorer-Profil angezeigt wird, wenn Sie sich mit dem Vesting-Vertragskonto verbinden.
+
+Bitte beachten Sie, dass Sie GRT aus dem Vesting-Vertrag L2 erst am Ende Ihres Vesting-Zeitraums freigeben/abziehen können, wenn Ihr Vertrag vollständig unverfallbar ist. Wenn Sie vor diesem Zeitpunkt GRT freigeben müssen, können Sie die GRT mit einem anderen, für diesen Zweck verfügbaren Transfertool zurück auf den L1-Freizügigkeitsvertrag übertragen.
+
+Wenn Sie noch kein Guthaben auf L2 übertragen haben und Ihr Vesting-Vertrag vollständig ausübbar ist, sollten Sie Ihren Vesting-Vertrag nicht auf L2 übertragen. Stattdessen können Sie die Transfer-Tools verwenden, um eine L2-Wallet-Adresse festzulegen und Ihren Einsatz oder Ihre Delegation direkt auf diese reguläre Wallet auf L2 zu übertragen.
+
+### Ich verwende meinen Vesting-Vertrag für Einsätze im Mainnet. Kann ich meinen Einsatz auf Arbitrum übertragen?
+
+Ja, aber wenn Ihr Vertrag noch ausläuft, können Sie den Einsatz nur so übertragen, dass er zu Ihrem auslaufenden L2-Vertrag gehört. Sie müssen diesen L2-Vertrag zunächst initialisieren, indem Sie ein gewisses GRT-Guthaben mit dem Freizügigkeitsvertrags-Transfertool im Explorer übertragen. Wenn Ihr Vertrag vollständig unverfallbar ist, können Sie Ihren Einsatz auf eine beliebige Adresse in L2 übertragen, aber Sie müssen ihn vorher festlegen und einige ETH für das L2-Transfer-Tool hinterlegen, um das L2-Gas zu bezahlen.
+
+### Ich verwende meinen Freizügigkeitsvertrag, um im Mainnet zu delegieren. Kann ich meine Delegationen auf Arbitrum übertragen?
+
+Ja, aber wenn Ihr Vertrag noch unverfallbar ist, können Sie die Delegation nur so übertragen, dass sie im Besitz Ihres L2-Vesting-Vertrags ist. Sie müssen diesen L2-Vertrag zunächst initialisieren, indem Sie ein gewisses GRT-Guthaben mit dem Freizügigkeitsvertrags-Transfertool im Explorer übertragen. Wenn Ihr Vertrag vollständig unverfallbar ist, können Sie Ihre Delegation an eine beliebige Adresse in L2 übertragen, aber Sie müssen sie vorher festlegen und einige ETH für das L2-Transfer-Tool hinterlegen, um für L2-Gas zu bezahlen.
+
+### Kann ich einen anderen Empfänger für meinen Freizügigkeitsvertrag auf L2 angeben?
+
+Ja, wenn Sie zum ersten Mal ein Guthaben übertragen und Ihren L2-Freizügigkeitsvertrag einrichten, können Sie einen L2-Begünstigten angeben. Stellen Sie sicher, dass dieser Begünstigte eine Wallet ist, die Transaktionen auf Arbitrum One durchführen kann, d.h. es muss eine EOA oder eine Multisig sein, die auf Arbitrum One eingesetzt wird.
+
+Wenn Ihr Kontrakt vollständig ausübbar ist, werden Sie keinen ausübbaren Kontrakt auf L2 einrichten; stattdessen werden Sie eine L2-Wallet-Adresse festlegen, die die empfangende Wallet für Ihren Einsatz oder Ihre Delegation auf Arbitrum sein wird.
+
+### Mein Vertrag ist vollständig unverfallbar. Kann ich meinen Anteil oder meine Delegation auf eine andere Adresse übertragen, bei der es sich nicht um einen Vertrag mit Unverfallbarkeit L2 handelt?
+
+Ja. Wenn Sie noch kein Guthaben auf L2 übertragen haben und Ihr Vesting-Vertrag vollständig ausübbar ist, sollten Sie Ihren Vesting-Vertrag nicht auf L2 übertragen. Stattdessen können Sie die Transfer-Tools verwenden, um eine L2-Wallet-Adresse festzulegen und Ihren Einsatz oder Ihre Delegation direkt auf diese reguläre Wallet auf L2 zu übertragen.
+
+So können Sie Ihren Einsatz oder Ihre Delegation an eine beliebige L2-Adresse übertragen.
+
+### Mein Vesting-Vertrag ist noch unverfallbar. Wie übertrage ich mein Freizügigkeitsguthaben auf L2?
+
+Diese Schritte gelten nur, wenn Ihr Vertrag noch unverfallbar ist, oder wenn Sie dieses Verfahren schon einmal angewendet haben, als Ihr Vertrag noch unverfallbar war.
+
+Um Ihren Vesting-Vertrag auf L2 zu übertragen, senden Sie ein eventuelles GRT-Guthaben mit Hilfe der Transfer-Tools an L2, wodurch Ihr L2-Vesting-Vertrag initialisiert wird:
+
+1. Zahlen Sie einige ETH in den Transfer-Tool-Vertrag ein (diese werden zur Bezahlung von L2-Gas verwendet)
+
+2. Widerruf des Protokollzugriffs auf den Vesting-Vertrag (erforderlich für den nächsten Schritt)
+
+3. Geben Sie dem Protokoll Zugriff auf den Vesting-Vertrag (damit Ihr Vertrag mit dem Übertragungstool interagieren kann)
+
+4. Geben Sie eine Empfängeradresse L2\* an und initiieren Sie den Guthaben-Transfer im Ethereum-Mainnet
+
+5. 20 Minuten auf Bestätigung warten
+
+6. Bestätigen Sie die Übertragung des Saldos auf L2
+
+\* Falls erforderlich - d.h. wenn Sie eine Vertragsadresse verwenden.
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### Kann ich meinen Vertrag mit unverfallbarer Anwartschaft zurück nach L1 verschieben?
+
+Das ist nicht nötig, da sich Ihr Vesting-Vertrag noch in L1 befindet. Wenn Sie die Übertragungstools verwenden, erstellen Sie einfach einen neuen Vertrag in L2, der mit Ihrem Vesting-Vertrag in L1 verbunden ist, und Sie können GRT zwischen den beiden Verträgen hin- und herschicken.
+
+### Warum muss ich meinen Vesting-Vertrag zunächst einmal verschieben?
+
+Sie müssen einen Unverfallbarkeitsvertrag für L2 einrichten, damit dieses Konto Eigentümer Ihres Einsatzes oder Ihrer Delegation auf L2 werden kann. Andernfalls gibt es für Sie keine Möglichkeit, den Einsatz/die Delegation auf L2 zu übertragen, ohne den Vesting-Vertrag zu "umgehen".
+
+### Was passiert, wenn ich versuche, meinen Vertrag auszuzahlen, obwohl er nur teilweise unverfallbar ist? Ist das möglich?
+
+Dies ist nicht möglich. Sie können Gelder zurück nach L1 verschieben und sie dort abheben.
+
+### Was ist, wenn ich meinen Vertrag mit Unverfallbarkeit nicht auf L2 übertragen möchte?
+
+Sie können weiterhin auf L1 staken/delegieren. Im Laufe der Zeit können Sie in Erwägung ziehen, auf L2 zu wechseln, um dort Belohnungen zu ermöglichen, wenn das Protokoll auf Arbitrum skaliert. Beachten Sie, dass diese Transfer-Tools nur für Verträge gelten, die das Abstecken und Delegieren im Protokoll erlauben. Wenn Ihr Vertrag kein Staking oder Delegieren erlaubt oder widerrufbar ist, dann gibt es kein Transfer-Tool. Sie können Ihr GRT trotzdem von L1 abheben, wenn es verfügbar ist.

From e02166131156101dc8e54a5f7fb98ad1d3b2ff2c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:45 -0500
Subject: [PATCH 1028/3820] New translations l2-transfer-tools-faq.mdx
 (Italian)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/it/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/it/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/it/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..3f438490c010
--- /dev/null
+++ b/website/pages/it/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2 Transfer Tools FAQ
+---
+
+## General
+
+### Cosa sono gli Strumenti di Trasferimento L2?
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### Posso usare lo stesso wallet utilizzato su Ethereum mainnet?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### Cosa succede se non completo il trasferimento in 7 giorni?
+
+Gli Strumenti di Trasferimento L2 utilizzano il meccanismo nativo di Arbitrum per inviare messaggi da L1 a L2. Questo meccanismo è chiamato "retryable ticket" e viene utilizzato da tutti i bridge di token nativi, incluso il bridge GRT di Arbitrum. Puoi leggere ulteriori dettagli sui retryable tickets nella [documentazione di Arbitrum](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+Quando trasferisci i tuoi asset (subgraph, stake, delegation o curation) su L2, un messaggio viene inviato tramite il bridge GRT di Arbitrum, che crea un "retryable ticket" su L2. Lo strumento di trasferimento include un valore in ETH nella transazione, che viene utilizzato per 1) pagare la creazione del ticket e 2) coprire il costo del gas per eseguire il ticket su L2. Tuttavia, poiché i prezzi del gas potrebbero variare nel tempo fino a quando il ticket non è pronto per l'esecuzione su L2, è possibile che questo tentativo di auto-esecuzione fallisca. Quando ciò accade, il bridge Arbitrum manterrà il "retryable ticket" attivo per un massimo di 7 giorni, e chiunque può riprovare a "riscattare" il ticket (il che richiede un wallet con un po' di ETH trasferiti su Arbitrum).
+
+Questo è ciò che chiamiamo il passaggio "Conferma" in tutti gli strumenti di trasferimento: in molti casi verrà eseguito automaticamente, poiché l'auto-esecuzione ha spesso successo, ma è importante che tu verifichi che sia andato a buon fine. Se non è andato a buon fine e nessuna riprova ha successo entro 7 giorni, il bridge Arbitrum scarterà il "retryable ticket" e i tuoi asset (subgraph, stake, delegation o curation) andranno persi e non potranno essere recuperati. I core devs di The Graph hanno un sistema di monitoraggio per rilevare queste situazioni e cercare di riscattare i ticket prima che sia troppo tardi, ma alla fine è tua responsabilità assicurarti che il trasferimento venga completato in tempo. Se hai difficoltà a confermare la tua transazione, ti preghiamo di contattarci utilizzando [questo modulo](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) e i core devs saranno pronti ad aiutarti.
+
+### I started my delegation/stake/curation transfer and I'm not sure if it made it through to L2, how can I confirm that it was transferred correctly?
+
+If you don't see a banner on your profile asking you to finish the transfer, then it's likely the transaction made it safely to L2 and no more action is needed. If in doubt, you can check if Explorer shows your delegation, stake or curation on Arbitrum One.
+
+If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire.
+
+## Traserimento del Subgraph
+
+### Come faccio a trasferire un mio subgraph?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+Per fare un trasferimento del tuo subgraph, dovrai completare i seguenti passaggi:
+
+1. Inizializza il trasferimento su Ethereum mainnet
+
+2. Aspetta 20 minuti per la conferma
+
+3. Conferma il trasferimento del subgraph su Arbitrum\*
+
+4. Termina la pubblicazione del subgraph su Arbitrum
+
+5. Aggiorna l'URL della Query (raccomandato)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Da dove devo inizializzare il mio trasferimento?
+
+Puoi inizializzare il tuo trasferimento da [Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) o dalla pagina di dettaglio di qualsiasi subgraph. Clicca sul bottone "Trasferisci Subgraph" sulla pagina di dettaglio del subgraph e inizia il trasferimento.
+
+### Quanto devo aspettare per il completamento del trasferimento del mio subgraph
+
+Il tempo di trasferimento richiede circa 20 minuti. Il bridge Arbitrum sta lavorando in background per completare automaticamente il trasferimento. In alcuni casi, i costi del gas potrebbero aumentare e dovrai confermare nuovamente la transazione.
+
+### I miei subgraph saranno ancora rintracciabili dopo averli trasferiti su L2?
+
+Il tuo subgraph sarà rintracciabile solo sulla rete su cui è stata pubblicata. Ad esempio, se il tuo subgraph è su Arbitrum One, potrai trovarlo solo su Explorer su Arbitrum One e non sarai in grado di trovarlo su Ethereum. Assicurati di avere selezionato Arbitrum One nel tasto in alto nella pagina per essere sicuro di essere sulla rete corretta. Dopo il transfer, il subgraph su L1 apparirà come deprecato.
+
+### Il mio subgraph deve essere pubblicato per poterlo trasferire?
+
+Per usufruire dello strumento di trasferimento del subgraph, il tuo subgraph deve già essere pubblicato sulla mainnet di Ethereum e deve possedere alcuni segnali di curation di proprietà del wallet che possiede il subgraph. Se il tuo subgraph non è stato pubblicato, è consigliabile pubblicarlo direttamente su Arbitrum One: le commissioni di gas associate saranno considerevolmente più basse. Se desideri trasferire un subgraph pubblicato ma l'account proprietario non inserito nessun segnale di curation su di esso, puoi segnalare una piccola quantità (ad esempio 1 GRT) da quell'account; assicurati di selezionare il segnale "auto-migrante".
+
+### Cosa succede alla versione del mio subgraph sulla mainnet di Ethereum dopo il trasferimento su Arbitrum?
+
+Dopo aver trasferito il tuo subgraph su Arbitrum, la versione sulla mainnet di Ethereum sarà deprecata. Ti consigliamo di aggiornare l'URL della query entro 48 ore. Tuttavia, è previsto un periodo di tolleranza che mantiene funzionante l'URL sulla mainnet in modo che il supporto per eventuali dApp di terze parti possa essere aggiornato.
+
+### Dopo il trasferimento, devo anche pubblicare di nuovo su Arbitrum?
+
+Dopo la finestra di trasferimento di 20 minuti, dovrai confermare il trasferimento con una transazione nell'interfaccia utente per completare il trasferimento, ma lo strumento di trasferimento ti guiderà attraverso questo processo. Il tuo endpoint L1 continuerà a essere supportato durante la finestra di trasferimento e un periodo di grazia successivo. Ti incoraggiamo ad aggiornare il tuo endpoint quando ti risulti più comodo.
+
+### Will my endpoint experience downtime while re-publishing?
+
+It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the subgraph on L1 and whether they keep indexing it until the subgraph is fully supported on L2.
+
+### Is publishing and versioning the same on L2 as Ethereum Ethereum mainnet?
+
+Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the subgraph.
+
+### Will my subgraph's curation move with my subgraph?
+
+If you've chosen auto-migrating signal, 100% of your own curation will move with your subgraph to Arbitrum One. All of the subgraph's curation signal will be converted to GRT at the time of the transfer, and the GRT corresponding to your curation signal will be used to mint signal on the L2 subgraph.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph.
+
+### Can I move my subgraph back to Ethereum mainnet after I transfer?
+
+Once transferred, your Ethereum mainnet version of this subgraph will be deprecated. If you would like to move back to mainnet, you will need to redeploy and publish back to mainnet. However, transferring back to Ethereum mainnet is strongly discouraged as indexing rewards will eventually be distributed entirely on Arbitrum One.
+
+### Why do I need bridged ETH to complete my transfer?
+
+Gas fees on Arbitrum One are paid using bridged ETH (i.e. ETH that has been bridged to Arbitrum One). However, the gas fees are significantly lower when compared to Ethereum mainnet.
+
+## Delegation
+
+### How do I transfer my delegation?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+To transfer your delegation, you will need to complete the following steps:
+
+1. Initiate delegation transfer on Ethereum mainnet
+2. Aspetta 20 minuti per la conferma
+3. Confirm delegation transfer on Arbitrum
+
+\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### What happens to my rewards if I initiate a transfer with an open allocation on Ethereum mainnet?
+
+If the Indexer to whom you're delegating is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer.
+
+### What happens if the Indexer I currently delegate to isn't on Arbitrum One?
+
+The L2 transfer tool will only be enabled if the Indexer you have delegated to has transferred their own stake to Arbitrum.
+
+### Do Delegators have the option to delegate to another Indexer?
+
+If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to.
+
+### What if I can't find the Indexer I'm delegating to on L2?
+
+The L2 transfer tool will automatically detect the Indexer you previously delegated to.
+
+### Will I be able to mix and match or 'spread' my delegation across new or several Indexers instead of the prior Indexer?
+
+The L2 transfer tool will always move your delegation to the same Indexer you delegated to previously. Once you have moved to L2, you can undelegate, wait for the thawing period, and decide if you'd like to split up your delegation.
+
+### Am I subject to the cooldown period or can I withdraw immediately after using the L2 delegation transfer tool?
+
+The transfer tool allows you to immediately move to L2. If you would like to undelegate you will have to wait for the thawing period. However, if an Indexer has transferred all of their stake to L2, you can withdraw on Ethereum mainnet immediately.
+
+### Can my rewards be negatively impacted if I do not transfer my delegation?
+
+It is anticipated that all network participation will move to Arbitrum One in the future.
+
+### How long does it take to complete the transfer of my delegation to L2?
+
+A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Can I transfer my delegation if I'm using a GRT vesting contract/token lock wallet?
+
+Yes! The process is a bit different because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the delegation to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### Is there any delegation tax?
+
+No. Received tokens on L2 are delegated to the specified Indexer on behalf of the specified Delegator without charging a delegation tax.
+
+### Will my unrealized rewards be transferred when I transfer my delegation?
+
+​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards.
+
+At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​
+
+### Is moving delegations to L2 mandatory? Is there a deadline?
+
+​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1?
+
+​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## Curation Signal
+
+### How do I transfer my curation?
+
+To transfer your curation, you will need to complete the following steps:
+
+1. Initiate signal transfer on Ethereum mainnet
+
+2. Specify an L2 Curator address\*
+
+3. Aspetta 20 minuti per la conferma
+
+\*If necessary - i.e. you are using a contract address.
+
+### How will I know if the subgraph I curated has moved to L2?
+
+When viewing the subgraph details page, a banner will notify you that this subgraph has been transferred. You can follow the prompt to transfer your curation. You can also find this information on the subgraph details page of any subgraph that has moved.
+
+### What if I do not wish to move my curation to L2?
+
+When a subgraph is deprecated you have the option to withdraw your signal. Similarly, if a subgraph has moved to L2, you can choose to withdraw your signal in Ethereum mainnet or send the signal to L2.
+
+### How do I know my curation successfully transferred?
+
+Signal details will be accessible via Explorer approximately 20 minutes after the L2 transfer tool is initiated.
+
+### Can I transfer my curation on more than one subgraph at a time?
+
+There is no bulk transfer option at this time.
+
+## Indexer Stake
+
+### How do I transfer my stake to Arbitrum?
+
+> Disclaimer: If you are currently unstaking any portion of your GRT on your Indexer, you will not be able to use L2 Transfer Tools.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+To transfer your stake, you will need to complete the following steps:
+
+1. Initiate stake transfer on Ethereum mainnet
+
+2. Aspetta 20 minuti per la conferma
+
+3. Confirm stake transfer on Arbitrum
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Will all of my stake transfer?
+
+You can choose how much of your stake to transfer. If you choose to transfer all of your stake at once, you will need to close any open allocations first.
+
+If you plan on transferring parts of your stake over multiple transactions, you must always specify the same beneficiary address.
+
+Note: You must meet the minimum stake requirements on L2 the first time you use the transfer tool. Indexers must send the minimum 100k GRT (when calling this function the first time). If leaving a portion of stake on L1, it must also be over the 100k GRT minimum and be sufficient (together with your delegations) to cover your open allocations.
+
+### How much time do I have to confirm my stake transfer to Arbitrum?
+
+\*\*\* You must confirm your transaction to complete the stake transfer on Arbitrum. This step must be completed within 7 days or stake could be lost.
+
+### What if I have open allocations?
+
+If you are not sending all of your stake, the L2 transfer tool will validate that at least the minimum 100k GRT remains in Ethereum mainnet and your remaining stake and delegation is enough to cover any open allocations. You may need to close open allocations if your GRT balance does not cover the minimums + open allocations.
+
+### Using the transfer tools, is it necessary to wait 28 days to unstake on Ethereum mainnet before transferring?
+
+No, you can transfer your stake to L2 immediately, there's no need to unstake and wait before using the transfer tool. The 28-day wait only applies if you'd like to withdraw the stake back to your wallet, on Ethereum mainnet or L2.
+
+### How long will it take to transfer my stake?
+
+It will take approximately 20 minutes for the L2 transfer tool to complete transferring your stake.
+
+### Do I have to index on Arbitrum before I transfer my stake?
+
+You can effectively transfer your stake first before setting up indexing, but you will not be able to claim any rewards on L2 until you allocate to subgraphs on L2, index them, and present POIs.
+
+### Can Delegators move their delegation before I move my indexing stake?
+
+No, in order for Delegators to transfer their delegated GRT to Arbitrum, the Indexer they are delegating to must be active on L2.
+
+### Can I transfer my stake if I'm using a GRT vesting contract / token lock wallet?
+
+Yes! The process is a bit different, because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the stake to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## Vesting Contract Transfer
+
+### How do I transfer my vesting contract?
+
+To transfer your vesting, you will need to complete the following steps:
+
+1. Initiate the vesting transfer on Ethereum mainnet
+
+2. Aspetta 20 minuti per la conferma
+
+3. Confirm vesting transfer on Arbitrum
+
+### How do I transfer my vesting contract if I am only partially vested?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount)
+
+2. Send some locked GRT through the transfer tool contract, to L2 to initialize the L2 vesting lock. This will also set their L2 beneficiary address.
+
+3. Send their stake/delegation to L2 through the "locked" transfer tool functions in the L1Staking contract.
+
+4. Withdraw any remaining ETH from the transfer tool contract
+
+### How do I transfer my vesting contract if I am fully vested?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+For those that are fully vested, the process is similar:
+
+1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount)
+
+2. Set your L2 address with a call to the transfer tool contract
+
+3. Send your stake/delegation to L2 through the "locked" transfer tool functions in the L1 Staking contract.
+
+4. Withdraw any remaining ETH from the transfer tool contract
+
+### Can I transfer my vesting contract to Arbitrum?
+
+You can transfer your vesting contract's GRT balance to a vesting contract in L2. This is a prerequisite for transferring stake or delegation from your vesting contract to L2. The vesting contract must hold a nonzero amount of GRT (you can transfer a small amount like 1 GRT to it if needed).
+
+When you transfer GRT from your L1 vesting contract to L2, you can choose the amount to send and you can do this as many times as you like. The L2 vesting contract will be initialized the first time you transfer GRT.
+
+The transfers are done using a Transfer Tool that will be visible on your Explorer profile when you connect with the vesting contract account.
+
+Please note that you will not be able to release/withdraw GRT from the L2 vesting contract until the end of your vesting timeline when your contract is fully vested. If you need to release GRT before then, you can transfer the GRT back to the L1 vesting contract using another transfer tool that is available for that purpose.
+
+If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2.
+
+### I'm using my vesting contract to stake on mainnet. Can I transfer my stake to Arbitrum?
+
+Yes, but if your contract is still vesting, you can only transfer the stake so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your stake to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas.
+
+### I'm using my vesting contract to delegate on mainnet. Can I transfer my delegations to Arbitrum?
+
+Yes, but if your contract is still vesting, you can only transfer the delegation so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your delegation to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas.
+
+### Can I specify a different beneficiary for my vesting contract on L2?
+
+Yes, the first time you transfer a balance and set up your L2 vesting contract, you can specify an L2 beneficiary. Make sure this beneficiary is a wallet that can perform transactions on Arbitrum One, i.e. it must be an EOA or a multisig deployed to Arbitrum One.
+
+If your contract is fully vested, you will not set up a vesting contract on L2; instead, you will set an L2 wallet address and this will be the receiving wallet for your stake or delegation on Arbitrum.
+
+### My contract is fully vested. Can I transfer my stake or delegation to another address that is not an L2 vesting contract?
+
+Yes. If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2.
+
+This allows you to transfer your stake or delegation to any L2 address.
+
+### My vesting contract is still vesting. How do I transfer my vesting contract balance to L2?
+
+These steps only apply if your contract is still vesting, or if you've used this process before when your contract was still vesting.
+
+To transfer your vesting contract to L2, you will send any GRT balance to L2 using the transfer tools, which will initialize your L2 vesting contract:
+
+1. Deposit some ETH into the transfer tool contract (this will be used to pay for L2 gas)
+
+2. Revoke protocol access to the vesting contract (needed for the next step)
+
+3. Give protocol access to the vesting contract (will allow your contract to interact with the transfer tool)
+
+4. Specify an L2 beneficiary address\* and initiate the balance transfer on Ethereum mainnet
+
+5. Aspetta 20 minuti per la conferma
+
+6. Confirm the balance transfer on L2
+
+\*If necessary - i.e. you are using a contract address.
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### Can I move my vesting contract back to L1?
+
+There is no need to do so because your vesting contract is still in L1. When you use the transfer tools, you just create a new contract in L2 that is connected with your L1 vesting contract, and you can send GRT back and forth between the two.
+
+### Why do I need to move my vesting contract to begin with?
+
+You need to set up an L2 vesting contract so that this account can own your stake or delegation on L2. Otherwise, there'd be no way for you to transfer the stake/delegation to L2 without "escaping" the vesting contract.
+
+### What happens if I try to cash out my contract when it is only partially vested? Is this possible?
+
+This is not a possibility. You can move funds back to L1 and withdraw them there.
+
+### What if I don't want to move my vesting contract to L2?
+
+You can keep staking/delegating on L1. Over time, you may want to consider moving to L2 to enable rewards there as the protocol scales on Arbitrum. Note that these transfer tools are for vesting contracts that are allowed to stake and delegate in the protocol. If your contract does not allow staking or delegating, or is revocable, then there is no transfer tool available. You will still be able to withdraw your GRT from L1 when available.

From cdaf05d1655012fd42460b632e22d553317cda57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:46 -0500
Subject: [PATCH 1029/3820] New translations l2-transfer-tools-faq.mdx
 (Japanese)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/ja/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/ja/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/ja/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..6a17a2e8dfdc
--- /dev/null
+++ b/website/pages/ja/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2 転送ツールに関するよくある質問
+---
+
+## General
+
+### L2転送ツールとは何ですか?
+
+The Graphは、プロトコルをArbitrum Oneに展開することで、コントリビューターがネットワークに参加するのが26倍安くなりました。L2 Transfer Toolsはコア開発者によって作成され、L2への移行を簡単にするためのツールです。
+
+各ネットワーク参加者には、L2へ移行する際にシームレスな体験を提供するための一連のL2トランスファーツールが利用可能です。これにより、解凍期間を回避したり、GRTを手動で引き出したりブリッジを構築する手間が省けます。
+
+これらのツールを使用するには、The Graph内でのあなたの役割とL2への転送内容に応じて特定のステップに従う必要があります。
+
+### イーサリアムメインネットで使用しているのと同じウォレットを使用できますか?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+EthereumやArbitrumのようなEVMブロックチェーン上のウォレットは、ブロックチェーンとやり取りすることなく作成できる一対の鍵（公開鍵と秘密鍵）です。そのため、イーサリアム用に作成されたウォレットは、Arbitrum上でも何もすることなく動作します。
+
+マルチシグのようなスマートコントラクトのウォレットは例外です。これらのスマートコントラクトは各チェーンに別々にデプロイされ、デプロイ時にアドレスを取得します。マルチシグがイーサリアムにデプロイされた場合、Arbitrum上に同じアドレスで存在することはありません。新しいマルチシグはまずArbitrum上で作成する必要があり、異なるアドレスを取得する可能性があります。
+
+### 7日以内に転送を完了しないとどうなりますか?
+
+L2転送ツールは、アービトラムのネイティブメカニズムを使用してL1からL2にメッセージを送信します。このメカニズムは「再試行可能チケット」と呼ばれ、Arbitrum GRTブリッジを含むすべてのネイティブトークンブリッジで使用されます。再試行可能なチケットの詳細については、[アービトラムドキュメント](https://docs.arbitrum.io/arbos/l1 からl2へのメッセージング)を参照してください。
+
+資産（サブグラフ、ステーク、委任、またはキュレーション）をL2に転送する際、Arbitrum GRTブリッジを介してメッセージが送信され、L2でretryable ticketが作成されます。転送ツールにはトランザクションに一部のETHが含まれており、これは1）チケットの作成に支払われ、2）L2でのチケットの実行に必要なガスに使用されます。ただし、チケットがL2で実行可能になるまでの時間でガス料金が変動する可能性があるため、この自動実行試行が失敗することがあります。その場合、Arbitrumブリッジはretryable ticketを最大7日間保持し、誰でもそのチケットを「償還」しようと再試行できます（これにはArbitrumにブリッジされた一部のETHを持つウォレットが必要です）。
+
+これは、すべての転送ツールで「確認」ステップと呼んでいるものです。ほとんどの場合、自動実行は成功するため、自動的に実行されますが、確認が完了したことを確認するために戻ってチェックすることが重要です。成功せず、7日間で成功した再試行がない場合、Arbitrumブリッジはそのチケットを破棄し、あなたの資産（サブグラフ、ステーク、委任、またはキュレーション）は失われ、回復できません。The Graphのコア開発者は、これらの状況を検出し、遅すぎる前にチケットを償還しようとする監視システムを設置していますが、最終的には転送が時間内に完了することを確認する責任があなたにあります。トランザクションの確認に問題がある場合は、[this form](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) を使用して連絡し、コア開発者が助けてくれるでしょう。
+
+### 委任/ステーク/キュレーション転送を開始しましたが、L2 まで転送されたかどうかわかりません。正しく転送されたことを確認するにはどうすればよいですか?
+
+プロフィールに転送を完了するように求めるバナーが表示されない場合、おそらくトランザクションは安全にL2に到達し、それ以上の操作は必要ありません。疑念がある場合、ExplorerがArbitrum Oneでのあなたの委任、ステーク、またはキュレーションを表示しているかどうかを確認できます。
+
+L1トランザクションのハッシュを持っている場合（これはウォレット内の最近のトランザクションを見ることで見つけることができます）、メッセージをL2に運ぶ「retryable ticket」が償還されたかどうかをこちらで確認できます：https://retryable-dashboard.arbitrum.io/ - 自動償還が失敗した場合、そこでウォレットを接続して償還することもできます。コア開発者もメッセージが詰まった場合を監視し、期限切れになる前にそれらを償還しようと試みますので、安心してください。
+
+## 部分グラフの転送
+
+### サブグラフを転送するにはどうすればよいですか?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+サブグラフを転送するには、次の手順を完了する必要があります。
+
+1. イーサリアムメインネットで転送を開始する
+
+2. 確認を待つために20分お待ちください。
+
+3. Arbitrum でサブグラフ転送を確認します\*
+
+4. Arbitrum でサブグラフの公開を完了する
+
+5. クエリ URL を更新 (推奨)
+
+\*注意：7日以内に転送を確認する必要があります。それ以外の場合、サブグラフが失われる可能性があります。ほとんどの場合、このステップは自動的に実行されますが、Arbitrumでガス価格が急上昇した場合には手動で確認する必要があるかもしれません。このプロセス中に問題が発生した場合、サポートを受けるためのリソースが用意されています：support@thegraph.com に連絡するか、[Discord](https://discord.gg/graphprotocol)でお問い合わせください\。
+
+### どこから転送を開始すればよいですか?
+
+トランスファーを開始するには、[Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer)またはサブグラフの詳細ページからトランスファーを開始できます。サブグラフの詳細ページで「サブグラフを転送」ボタンをクリックしてトランスファーを開始してください。
+
+### サブグラフが転送されるまでどれくらい待つ必要がありますか
+
+トランスファーには約20分かかります。Arbitrumブリッジはバックグラウンドでブリッジトランスファーを自動的に完了します。一部の場合、ガス料金が急上昇する可能性があり、トランザクションを再度確認する必要があるかもしれません。
+
+### 私のサブグラフは L2 に転送した後も検出可能ですか?
+
+あなたのサブグラフは、それが公開されたネットワーク上でのみ発見できます。たとえば、あなたのサブグラフがArbitrum Oneにある場合、それはArbitrum OneのExplorerでのみ見つけることができ、Ethereum上では見つけることはできません。正しいネットワークにいることを確認するために、ページの上部にあるネットワーク切り替えツールでArbitrum Oneを選択していることを確認してください。トランスファー後、L1サブグラフは非推奨として表示されます。
+
+### 私のサブグラフを転送するには公開する必要がありますか?
+
+サブグラフ転送ツールを活用するには、サブグラフがすでにEthereumメインネットに公開され、そのサブグラフを所有するウォレットが所有するキュレーション信号を持っている必要があります。サブグラフが公開されていない場合、Arbitrum Oneに直接公開することをお勧めします。関連するガス料金はかなり低くなります。公開されたサブグラフを転送したいが、所有者のアカウントがそれに対してキュレーション信号を出していない場合、そのアカウントから少額（たとえば1 GRT）の信号を送ることができます。必ず「auto-migrating（自動移行）」信号を選択してください。
+
+### Arbitrumへの転送後、Ethereumメインネットバージョンの私のサブグラフはどうなりますか？
+
+サブグラフをArbitrumに転送した後、Ethereumメインネットワークのバージョンは非推奨とされます。おすすめでは、48時間以内にクエリURLを更新することをお勧めしています。ただし、サードパーティのDAppサポートが更新されるために、メインネットワークのURLが機能し続ける猶予期間も設けられています。
+
+### 転送後、Arbitrum上で再公開する必要がありますか？
+
+20分のトランスファーウィンドウの後、トランスファーを完了するためにUI内でトランザクションを確認する必要がありますが、トランスファーツールがこれをガイドします。トランスファーウィンドウおよびその後の猶予期間中、L1エンドポイントはサポートされ続けます。都合が良いときにエンドポイントを更新することが奨励されています。
+
+### 再公開中にエンドポイントでダウンタイムが発生しますか?
+
+短期間のダウンタイムを経験する可能性は低いですが、L1でサブグラフをサポートしているインデクサーと、サブグラフが完全にL2でサポートされるまでインデクシングを続けるかどうかに依存することがあります。
+
+### L2上での公開とバージョニングは、Ethereumメインネットと同じですか？
+
+はい、Subgraph Studioで公開する際には、公開ネットワークとしてArbitrum Oneを選択してください。Studioでは、最新のエンドポイントが利用可能で、最新の更新されたサブグラフバージョンを指します。
+
+### 私のサブグラフのキュレーションは、サブグラフと一緒に移動しますか？
+
+自動移行信号を選択した場合、あなたのキュレーションの100％はサブグラフと一緒にArbitrum Oneに移行します。サブグラフのすべてのキュレーション信号は、転送時にGRTに変換され、あなたのキュレーション信号に対応するGRTがL2サブグラフ上で信号を発行するために使用されます。
+
+他のキュレーターは、自分の一部のGRTを引き出すか、それをL2に転送して同じサブグラフで信号を発行するかを選択できます。
+
+### 転送後にサブグラフをEthereumメインネットに戻すことはできますか？
+
+一度転送されると、Ethereumメインネットワークのサブグラフバージョンは非推奨とされます。メインネットワークに戻りたい場合、再デプロイしてメインネットワークに再度公開する必要があります。ただし、Ethereumメインネットワークに戻すことは強く勧められていません。なぜなら、将来的にはインデクシングリワードが完全にArbitrum Oneで分配されるためです。
+
+### なぜ転送を完了するためにブリッジされたETHが必要なのですか？
+
+Arbitrum One上のガス料金は、ブリッジを介してArbitrum OneにブリッジされたETHを使用して支払われます。ただし、Ethereumメインネットワークと比較して、ガス料金はかなり低いです。
+
+## Delegation
+
+### 委任を転送するにはどうすればよいですか?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+委任を転送するには、次の手順を完了する必要があります。
+
+1. イーサリアムメインネットで委任転送を開始する
+2. 確認を待つために20分お待ちください。
+3. アービトラムでの委任転送の確認
+
+\*\*\*\*Arbitrum上での委任トランスファーを完了するには、トランザクションを確認する必要があります。このステップは7日以内に完了する必要があり、それ以外の場合、委任が失われる可能性があります。ほとんどの場合、このステップは自動的に実行されますが、Arbitrumでガス価格が急上昇した場合、手動の確認が必要になることがあります。このプロセス中に問題が発生した場合、サポートを受けるためのリソースが用意されています：support@thegraph.com または[Discord](https://discord.gg/graphprotocol)でサポートに連絡してください。
+
+### イーサリアムメインネットでオープンアロケーションで送金を開始した場合、報酬はどうなりますか?
+
+もし委任先のインデクサーがまだL1上で運営されている場合、Arbitrumに移行するとEthereumメインネットワークのオープンアロケーションからの委任報酬が失われます。つまり、最大で過去28日間の報酬が失われる可能性があります。報酬の損失を最小限に抑えるために、インデクサーがアロケーションを終了した直後にトランスファーをタイミングすることができます。インデクサーとコミュニケーションチャネルがある場合、彼らと相談してトランスファーの最適なタイミングを見つけることを検討してください。
+
+### 現在委任しているインデクサーがアービトラム One にない場合はどうなりますか?
+
+L2トランスファーツールは、あなたが委任したインデクサーが自分のステークをArbitrumに転送した場合にのみ有効になります。
+
+### デリゲーターは、別のインデクサーに委任する選択肢がありますか？
+
+別のインデクサーに委任したい場合、まずArbitrum上で同じインデクサーにトランスファーし、その後委任を解除して解凍期間を待ちます。その後、別のアクティブなインデクサーを選択して委任できます。
+
+### L2 で委任先のインデクサーが見つからない場合はどうすればよいですか?
+
+L2 転送ツールは、以前に委任したインデクサーを自動的に検出します。
+
+### 以前のインデクサーではなく、新しいインデクサーまたは複数のインデクサーに委任を組み合わせて一致させたり、"分散" したりできますか?
+
+L2トランスファーツールは常に、以前に委任した同じインデクサーにあなたの委任を移動させます。L2に移動した後、委任を解除し、解凍期間を待ってから、委任を分割するかどうかを決定できます。
+
+### クールダウン期間の対象になりますか、それともL2委任転送ツールを使用した直後に撤退できますか?
+
+トランスファーツールを使用すると、即座にL2に移動できます。委任を解除したい場合は、解凍期間を待たなければなりません。ただし、インデクサーがステークをすべてL2に移動させた場合、Ethereumメインネットワークで即座に引き出すことができます。
+
+### 委任を譲渡しない場合、報酬に悪影響が及ぶ可能性がありますか?
+
+将来的には、すべてのネットワーク参加者がArbitrum Oneに移行すると予想されています。
+
+### L2への委任の転送が完了するまでどのくらいかかりますか?
+
+委任転送には 20 分間の確認が必要です。20 分後、7 日以内に転送プロセスのステップ 3 を戻って完了する必要があります。これを怠ると、委任が失われる可能性があります。ほとんどの場合、転送ツールはこのステップを自動的に完了することに注意してください。自動試行が失敗した場合は、手動で完了する必要があります。このプロセス中に問題が発生した場合は、心配しないでください。サポートのためにここにいます。support@thegraph.com または[Discord](https://discord.gg/graphprotocol).
+
+### GRT権利確定契約/トークンロックウォレットを使用している場合、委任を譲渡できますか?
+
+はい！プロセスは少し異なります。ベスティングコントラクトはL2ガスの支払いに必要なETHを転送できないため、事前にそれを預ける必要があります。ベスティングコントラクトが完全にベスティングされていない場合、まずL2上でカウンターパートのベスティングコントラクトを初期化する必要があり、委任をこのL2ベスティングコントラクトにのみ転送できます。Explorerを使用してベスティングロックウォレットに接続した場合、UIがこのプロセスを案内することができます。
+
+### Arbitrumの権利確定契約では、メインネットと同じようにGRTをリリースできますか？
+
+いいえ、Arbitrumで作成された権利確定契約では、権利確定タイムラインが終了するまで、つまりコントラクトが完全に権利確定されるまで、GRTを放出することはできません。これは、二重消費を防ぐためです。そうしないと、両方のレイヤーで同じ金額を放出することが可能になってしまうからです。
+
+Arbitrum Oneのプロファイルに、GRTをメインネットの権利確定契約に戻すことができるというバナーが表示されます。この場合、GRTブリッジと同じネイティブブリッジメカニズムを使用するため、Arbitrum One上でトランザクションを行い、7日間待ち、メインネット上で最終トランザクションを行う必要があります。
+
+### 委任税はありますか?
+
+いいえ、L2で受け取ったトークンは、指定された委任者の代わりに指定されたインデクサーに委任され、委任税は課金されません。
+
+### 委任を譲渡すると、未実現の報酬も譲渡されますか?
+
+はい！転送できない報酬は、アロケーションがクローズされるまで存在しないため、オープンアロケーションの報酬だけです（通常、28日ごとにクローズされます）。長い間委任している場合、これはおそらく報酬のほんの一部です。
+
+スマート コントラクト レベルでは、未実現報酬はすでに委任残高の一部となっているため、委任を L2 に転送するときに転送されます。
+
+### 委任を L2 に移動することは必須ですか? 期限はありますか?
+
+L2への委任移行は強制ではありませんが、[GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193) で説明されているタイムラインに従ってL2でのインデクシング報酬が増加しています。最終的には、評議会が増加を承認し続ける限り、すべての報酬がL2で分配され、L1のインデクサーや委任者にはインデクシング報酬がなくなる可能性があります。
+
+### すでにステークを L2 に移管しているインデクサーに委任している場合、L1 での報酬の受け取りは停止されますか?
+
+多くのインデクサーは段階的にステークを移行しており、したがってL1でのインデクサーは引き続きL1で報酬と手数料を稼ぎ、それらはその後委任者と共有されます。インデクサーがステークをすべて移行した場合、それからはL1での運用を停止し、委任者はL2に移行しない限り追加の報酬を受け取らなくなります。
+
+最終的に、評議会がL2でのインデクシング報酬の増加を承認し続ける場合、すべての報酬はL2で分配され、L1のインデクサーや委任者にはインデクシング報酬が存在しなくなるでしょう。
+
+### 委任を転送するボタンが表示されません。 何故ですか？
+
+あなたのインデクサーは、ステークを転送するために L2 転送ツールをまだ使用していない可能性があります。
+
+Indexerに連絡できる場合、彼らにL2トランスファーツールを使用するように奨励し、委任者が委任を彼らのL2インデクサーアドレスに転送できるようにすることができます。
+
+### 私のインデクサーも Arbitrum 上にありますが、プロファイルに委任を転送するボタンが表示されません。 何故ですか？
+
+インデクサーがL2での運用を設定しているが、ステークを転送するためにL2トランスファーツールを使用していない可能性があります。したがって、L1のスマートコントラクトはインデクサーのL2アドレスについては知らないかもしれません。インデクサーに連絡できる場合、彼らに転送ツールを使用するよう奨励し、委任者が委任を彼らのL2インデクサーアドレスに転送できるようにすることができます。
+
+### 委任解除プロセスを開始していてまだ撤回していない場合、委任を L2 に転送できますか?
+
+いいえ。 代表団が解凍されつつある場合は、28 日間待って代表団を撤回する必要があります。
+
+委任が解除されているトークンは「ロック」されているため、L2 に転送できません。
+
+## キュレーションシグナル
+
+### キュレーションを転送するにはどうすればよいですか?
+
+キュレーションを転送するには、次の手順を完了する必要があります。
+
+1. イーサリアムメインネットでシグナル転送を開始する
+
+2. イーサリアムメインネットでシグナル転送を開始する
+
+3. 確認を待つために20分お待ちください。
+
+\*必要な場合 - つまり、契約アドレスを使用している場合。
+
+### 私がキュレーションしたサブグラフが L2 に移動したかどうかはどうすればわかりますか?
+
+サブグラフの詳細ページを表示すると、このサブグラフが転送されたことを通知するバナーが表示されます。バナーに従ってキュレーションを転送できます。また、移動したサブグラフの詳細ページでもこの情報を見つけることができます。
+
+### 自分のキュレーションを L2 に移動したくない場合はどうすればよいですか?
+
+サブグラフが非推奨になった場合、信号を引き出すオプションがあります。同様に、サブグラフがL2に移動した場合、Ethereumメインネットワークで信号を引き出すか、L2に送信することを選択できます。
+
+### 私のキュレーションが正常に転送されたことを確認するにはどうすればよいですか?
+
+L2トランスファーツールを開始してから約20分後、Explorerを介して信号の詳細にアクセスできるようになります。
+
+### 一度に複数のサブグラフへキュレーションを転送することはできますか？
+
+現時点では一括転送オプションは提供されていません。
+
+## Indexer Stake
+
+### 自分の株式をArbitrumに移管するにはどうすればよいですか?
+
+> 免責事項: インデクサーからGRTの一部を現在アンステークしている場合、L2トランスファーツールを使用することはできません。
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+ステークを譲渡するには、次の手順を完了する必要があります。
+
+1. イーサリアムメインネットでのステーク転送を開始してください。
+
+2. 確認を待つために20分お待ちください。
+
+3. Arbitrumでのステーク転送を確認してください。
+
+\*注意：7日以内に転送を確認する必要があります。それ以外の場合、あなたのステークが失われる可能性があります。ほとんどの場合、このステップは自動的に実行されますが、Arbitrumでガス価格が急上昇した場合には手動で確認が必要な場合があります。このプロセス中に問題が発生した場合、サポートを受けるためのリソースが用意されています：support@thegraph.com に連絡するか、[Discord](https://discord.gg/graphprotocol)でお問い合わせください。
+
+### 私のすべてのステークは譲渡されますか?
+
+どれだけのステークを転送するかを選択できます。すべてのステークを一度に転送する場合、まずオープンなアロケーションを閉じる必要があります。
+
+ステークの一部を複数のトランザクションで転送する予定の場合、常に同じ受益者アドレスを指定する必要があります。
+
+注意: トランスファーツールを初めて使用する際には、L2での最小ステーク要件を満たす必要があります。インデクサーは、最初にこの関数を呼び出す際に最小100k GRTを送信する必要があります。L1にステークの一部を残す場合、それも100k GRT以上でなければならず、オープンなアロケーションをカバーするのに十分である必要があります（委任と合わせて）。
+
+### アービトラムへのステーク譲渡の確認にはどのくらいの時間が必要ですか?
+
+\*\*\* Arbitrum上でのステーク転送を完了するには、トランザクションを確認する必要があります。このステップは7日以内に完了する必要があり、それ以外の場合、ステークが失われる可能性があります。
+
+### 未処理の配賦がある場合はどうなりますか?
+
+すべてのステークを送信しない場合、L2トランスファーツールはEthereumメインネットで最低でも100k GRTが残っており、残りのステークと委任がオープンなアロケーションをカバーするのに十分であることを検証します。GRTの残高が最小要件とオープンなアロケーションをカバーしない場合、オープンなアロケーションを閉じる必要があるかもしれません。
+
+### 転送ツールを使用して、転送する前にイーサリアムメインネットのステーキングを解除するために28日間待つ必要がありますか?
+
+いいえ、L2にステークをすぐに転送できます。トランスファーツールを使用する前にアンステークして待つ必要はありません。28日の待機期間は、ステークをEthereumメインネットまたはL2のウォレットに戻す場合にのみ適用されます。
+
+### 賭け金の譲渡にはどのくらい時間がかかりますか?
+
+L2トランスファーツールがステークの転送を完了するのに約20分かかります。
+
+### 株式を譲渡する前に、Arbitrum でインデックスを作成する必要がありますか?
+
+インデクシングのセットアップよりも先にステークを効果的に転送できますが、L2でのサブグラフへの割り当て、それらのサブグラフのインデクシング、およびPOIの提出を行うまで、L2での報酬を請求することはできません。
+
+### 委任者は、インデックス作成の賭け金を移動する前に委任を移動できますか?
+
+いいえ、委任者が委任されたGRTをArbitrumに転送するためには、委任しているインデクサーがL2でアクティブである必要があります。
+
+### GRT権利確定契約/トークンロックウォレットを使用している場合、株式を譲渡できますか?
+
+はい！プロセスは少し異なります。ベスティングコントラクトはL2ガスの支払いに必要なETHを転送できないため、事前にそれを預ける必要があります。ベスティングコントラクトが完全にベスティングされていない場合、まずL2上でカウンターパートのベスティングコントラクトを初期化する必要があり、ステークはこのL2ベスティングコントラクトにのみ転送できます。Explorerを使用してベスティングロックウォレットを介してExplorerに接続した場合、UIがこのプロセスを案内することができます。
+
+### 私はすでにL2の権益を持っています。 初めて転送ツールを使用するときも 100k GRT を送信する必要がありますか?
+
+はい。L1のスマートコントラクトはあなたのL2のステークを認識しないため、最初に転送する際に少なくとも100k GRTを転送する必要があります。
+
+### GRT のステーキングを解除している最中に、ステークを L2 に移すことはできますか?
+
+いいえ。ステークの一部が解凍中の場合、ステークを転送する前に28日間待つ必要があり、解凍中のトークンは「ロックされ」、転送やL2へのステークはできません。
+
+## 権利確定契約の譲渡
+
+### 権利確定契約を譲渡するにはどうすればよいですか?
+
+権利確定を譲渡するには、次の手順を完了する必要があります:
+
+1. イーサリアムメインネットで権利確定転送を開始する
+
+2. 確認を待つために20分お待ちください。
+
+3. アービトラムでの権利確定転送の確認
+
+### 部分的にしか権利が与えられていない場合、権利確定契約を譲渡するにはどうすればよいですか?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. 転送ツール契約にETHを入金します(UIは妥当な金額を見積もるのに役立ちます)
+
+2. ロックされたGRTを転送ツールコントラクトを介してL2に送信して、L2ベスティングロックを初期化します。これにより、L2の受益者アドレスも設定されます。
+
+3. ステーク/委任をL2に送信するには、L1Staking契約内の「ロックされた」トランスファーツール機能を使用します。
+
+4. 転送ツール契約から残りの ETH を引き出します
+
+### 完全に権利が確定している場合、権利確定契約を譲渡するにはどうすればよいですか?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+完全に権利が与えられているものの場合、プロセスは似ています:
+
+1. 転送ツール契約にETHを入金します(UIは妥当な金額を見積もるのに役立ちます)
+
+2. 転送ツール契約への呼び出しでL2アドレスを設定する
+
+3. あなたのステーク/委任をL2に送信するには、L1ステーキング契約内の「ロック」されたトランスファーツール機能を使用してください。
+
+4. 転送ツール契約から残りの ETH を引き出します
+
+### 私のベスティング契約をアービトラムに転送できますか？
+
+あなたはベスティングコントラクトのGRT残高をL2のベスティングコントラクトに転送できます。これは、ベスティングコントラクトからステークまたは委任をL2に転送するための前提条件です。ベスティングコントラクトはGRTのゼロでない残高を保持している必要があります（必要に応じて1 GRTのような少額を転送できます）。
+
+L1のベスティングコントラクトからL2にGRTを転送する際、送信する金額を選択でき、何度でもこれを行うことができます。L2のベスティングコントラクトは、最初にGRTを転送する際に初期化されます。
+
+これらの転送は、ベスティングコントラクトアカウントでExplorerプロフィールに接続した際に表示されるTransfer Toolを使用して行われます。
+
+L2のベスティングコントラクトからGRTを解放または引き出すことは、契約が完全にベスティングされる契約終了時までできません。それ以前にGRTを解放する必要がある場合、その目的で使用できる別のトランスファーツールを使用してGRTをL1のベスティングコントラクトに戻すことができます。
+
+もしベスティングコントラクトの残高をL2に転送していない場合、かつベスティングコントラクトが完全にベスティングされている場合、ベスティングコントラクトをL2に転送しないでください。代わりに、トランスファーツールを使用してL2ウォレットアドレスを設定し、ステークまたは委任をこの通常のL2ウォレットに直接転送できます。
+
+### 私は権利確定契約を利用してメインネットに賭けています。 自分の株式をArbitrumに譲渡できますか?
+
+はい、ただし、契約がまだベスティング中の場合、ステークをL2ベスティングコントラクトが所有するように転送できます。まず、Explorerのベスティングコントラクトの転送ツールを使用して、このL2コントラクトを初期化する必要があります。契約が完全にベスティングされている場合、ステークをL2内の任意のアドレスに転送できますが、事前に設定し、L2ガスの支払いに必要な一部のETHをデポジットする必要があります。
+
+### 私は権利確定契約を使用してメインネットを委任しています。 私の代表団をArbitrumに移管できますか?
+
+はい、ただし、契約がまだベスティング中の場合、委任をL2ベスティングコントラクトが所有するように転送できます。まず、Explorerのベスティングコントラクトの転送ツールを使用して、このL2コントラクトを初期化する必要があります。契約が完全にベスティングされている場合、委任をL2内の任意のアドレスに転送できますが、事前に設定し、L2ガスの支払いに必要な一部のETHをデポジットする必要があります。
+
+### L2の権利確定契約に別の受益者を指定することはできますか?
+
+はい、最初に残高を転送し、L2ベスティングコントラクトを設定する際、L2の受益者を指定できます。この受益者は、Arbitrum Oneでトランザクションを実行できるウォレットである必要があります。つまり、EOAまたはArbitrum Oneに展開されたマルチシグである必要があります。
+
+契約が完全にベスティングされている場合、L2でのベスティングコントラクトを設定しません。代わりに、L2ウォレットアドレスを設定し、これがArbitrum上でのステークまたは委任の受信ウォレットとなります。
+
+### 私の契約は完全に権利確定しています。 自分のステークまたは委任を、L2 権利確定契約ではない別のアドレスに移すことはできますか?
+
+はい。もしベスティング契約の残高をL2に転送していない場合、かつベスティング契約が完全にベスティングされている場合、ベスティング契約をL2に転送すべきではありません。代わりに、トランスファーツールを使用してL2ウォレットアドレスを設定し、ステークまたは委任をこの通常のL2ウォレットに直接転送できます。
+
+これにより, ステークまたは委任を任意のL2アドレスに移すことができます。
+
+### 私の権利確定契約はまだ権利確定中です。 権利確定契約残高を L2 に転送するにはどうすればよいですか?
+
+これらのステップは、契約がまだベスティング中の場合、または契約がまだベスティング中であったときにこのプロセスを使用した場合にのみ適用されます。
+
+権利確定契約をL2に転送するには、L2権利確定契約を初期化する転送ツールを使用してGRT残高をL2に送信します。
+
+1. 転送ツール契約にETHを入金します(これはL2ガスの支払いに使用されます)
+
+2. 権利確定契約へのプロトコルアクセスを取り消す(次のステップで必要)
+
+3. 権利確定契約へのプロトコルアクセスを許可します(契約が転送ツールと対話できるようにします)
+
+4. L2受取人アドレス\*を指定し、イーサリアムメインネットで残高転送を開始します
+
+5. 確認を待つために20分お待ちください。
+
+6. L2での残高転送の確認
+
+\*必要な場合 - つまり、契約アドレスを使用している場合。
+
+\*\*\*\*Arbitrum での残高振替を完了するには、取引を確認する必要があります。このステップは 7 日以内に完了する必要があります。そうしないと、残高が失われる可能性があります。ほとんどの場合、このステップは自動的に実行されますが、Arbitrum にガス価格の急上昇がある場合は手動確認が必要になる場合があります。このプロセス中に問題がある場合は、サポートするためのリソースがあります: support@thegraph.com または [Discord](https://discord.gg/graphprotocol).
+
+### 私の権利確定契約には 0 GRT と表示されているため、転送できません。これはなぜですか? どうすれば修正できますか?
+
+L2ベスティングコントラクトを初期化するためには、L2にゼロでない額のGRTを転送する必要があります。これは、L2トランスファーツールで使用されるArbitrum GRTブリッジによって必要とされます。GRTはベスティングコントラクトの残高から提供される必要があり、ステークまたは委任されたGRTは含まれません。
+
+もしベスティング契約からステークまたは委任されたGRTをすべて行ってしまった場合、他のどこかから（別のウォレットや取引所からなど）ベスティング契約アドレスに1 GRTのような少額を手動で送信できます。
+
+### 権利確定契約を使用してステークまたは委任を行っていますが、ステークまたは委任を L2 に転送するボタンが表示されません。どうすればよいですか?
+
+ベスティング契約のベスティングが完了していない場合、まずL2ベスティング契約を作成する必要があります。このL2ベスティング契約は、ベスティングタイムラインの終了までL2でトークンの解放を許可しませんが、L1ベスティング契約にトークンを転送してそちらで解放することができます。
+
+Explorerでベスティング契約に接続した場合、L2ベスティング契約を初期化するボタンが表示されるはずです。まず、このプロセスに従って初期化を行い、その後、プロファイルでステークまたは委任を転送するためのボタンが表示されるはずです。
+
+### L2 権利確定契約を初期化すると、委任も自動的に L2 に転送されますか?
+
+いいえ、L2 権利確定契約の初期化は、権利確定契約からステークまたは委任を移管するための前提条件ですが、これらを個別に移管する必要があります。
+
+L2 権利確定契約を初期化した後、プロフィールにステークまたは委任の譲渡を促すバナーが表示されます。
+
+### 権利確定契約をL1に戻すことはできますか?
+
+その必要はありません。なぜなら、あなたのベスティング契約はまだL1にあるからです。トランスファーツールを使用すると、単にL1ベスティング契約に接続された新しいL2契約を作成し、その間でGRTを送受信できるようになります。
+
+### そもそもなぜ権利確定契約を移動する必要があるのですか?
+
+L2ベスティング契約を設定する必要があります。これにより、このアカウントがL2上のステークまたは委任を所有できるようになります。それ以外の場合、ベスティング契約を"脱出"せずにステーク/委任をL2に転送する方法がありません。
+
+### 部分的にしか権利が確定していないのに契約を現金化しようとするとどうなりますか? これは可能ですか?
+
+これは可能ではありません。資金をL1に戻し、そこで引き出すことはできます。
+
+### 権利確定契約をL2に移行したくない場合はどうすればよいですか?
+
+L1でのステーキング/委任を継続することができます。将来的に、プロトコルがArbitrumでスケーリングするにつれて、L2で報酬を有効にすることを検討するかもしれません。ただし、これらのトランスファーツールは、プロトコルでステーキングや委任が許可されているベスティング契約向けのものです。契約がステーキングや委任を許可していないか、取り消し可能な場合、トランスファーツールは利用できません。利用可能な場合、まだL1からGRTを引き出すことができます。

From 6315ee2d33a5f880eaa76e46c331156ecaef0f77 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:48 -0500
Subject: [PATCH 1030/3820] New translations l2-transfer-tools-faq.mdx (Korean)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 412 ++++++++++++++++++
 1 file changed, 412 insertions(+)
 create mode 100644 website/pages/ko/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/ko/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/ko/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..4aff46059308
--- /dev/null
+++ b/website/pages/ko/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,412 @@
+---
+title: L2 Transfer Tools FAQ
+---
+
+## General
+
+### L2 전송 도구란 무엇입니까?
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### 이더리움 메인넷에서 사용하는 지갑을 그대로 사용할 수 있나요?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### 만약 7일 안에 이체를 완료하지 못하면 어떻게 되나요?
+
+L2 전송 도구는 Arbitrum의 기본 메커니즘을 사용하여 L1에서 L2로 메시지를 보냅니다. 이 메커니즘은 "재시도 가능한 티켓"이라고 하며 Arbitrum GRT 브리지를 포함한 모든 네이티브 토큰 브리지를 사용하여 사용됩니다. 재시도 가능한 티켓에 대해 자세히 읽을 수 있습니다 [Arbitrum 문서] 
+(https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+자산(하위 그래프, 스테이크, 위임 또는 큐레이션) 을 L2로 이전하면 L2에서 재시도 가능한 티켓을 생성하는 Arbitrum GRT 브리지를 통해 메시지가 전송됩니다. 전송 도구에는 거래에 일부 ETH 값이 포함되어 있으며, 이는 1) 티켓 생성 비용을 지불하고 2) L2에서 티켓을 실행하기 위해 가스 비용을 지불하는 데 사용됩니다. 그러나 티켓이 L2에서 실행될 준비가 될 때까지 가스 가격이 시간에 따라 달라질 수 있으므로 이 자동 실행 시도가 실패할 수 있습니다. 그런 일이 발생하면 Arbitrum 브릿지는 재시도 가능한 티켓을 최대 7일 동안 유지하며 누구나 티켓 "사용"을 재시도할 수 있습니다(Arbitrum에 브릿지된 일부 ETH가 있는 지갑이 필요함).
+
+이것이 모든 전송 도구에서 '확인' 단계라고 부르는 것입니다. 자동 실행이 성공하는 경우가 가장 많기 때문에 대부분의 경우 자동으로 실행되지만 제대로 진행되었는지 다시 확인하는 것이 중요합니다. 성공하지 못하고 7일 이내에 성공적인 재시도가 없으면 Arbitrum 브릿지는 티켓을 폐기하며 귀하의 자산(하위 그래프, 지분, 위임 또는 큐레이션)은 손실되어 복구할 수 없습니다. Graph 코어 개발자는 이러한 상황을 감지하고 너무 늦기 전에 티켓을 교환하기 위해 모니터링 시스템을 갖추고 있지만 전송이 제 시간에 완료되도록 하는 것은 궁극적으로 귀하의 책임입니다. 거래를 확인하는 데 문제가 있는 경우 [이 양식]을 사용하여 문의하세요 (https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) 핵심 개발자들이 도와드릴 것입니다.
+
+### I started my delegation/stake/curation transfer and I'm not sure if it made it through to L2, how can I confirm that it was transferred correctly?
+
+If you don't see a banner on your profile asking you to finish the transfer, then it's likely the transaction made it safely to L2 and no more action is needed. If in doubt, you can check if Explorer shows your delegation, stake or curation on Arbitrum One.
+
+If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire.
+
+## 하위 그래프 전송
+
+### 내 서브그래프를 어떻게 이전하나요?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+
+
+1. 이더리움 메인넷에서 전송 시작
+
+2. 확인을 위해 20분 정도 기다리세요
+
+3. Arbitrum에서 하위 그래프 전송 확인\*
+
+4. Arbitrum에 하위 그래프 게시 완료
+
+5. 쿼리 URL 업데이트(권장)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### 어디에서 이전을 시작해야 합니까?
+
+[Subgraph Studio](https://thegraph.com/studio/), [Explorer](https://thegraph.com/explorer) 또는 하위 그래프 세부정보 페이지에서 전송을 시작할 수 있습니다. 하위 그래프 세부 정보 페이지에서 "하위 그래프 전송" 버튼을 클릭하여 전송을 시작하세요.
+
+### 내 하위 그래프가 전송될 때까지 얼마나 기다려야 합니까?
+
+환승 시간은 약 20분 정도 소요됩니다. Arbitrum 브리지는 브리지 전송을 자동으로 완료하기 위해 백그라운드에서 작동하고 있습니다. 경우에 따라 가스 비용이 급증할 수 있으며 거래를 다시 확인해야 합니다.
+
+### 내 하위 그래프를 L2로 전송한 후에도 계속 검색할 수 있나요?
+
+귀하의 하위 그래프는 해당 하위 그래프가 게시된 네트워크에서만 검색 가능합니다. 예를 들어, 귀하의 하위 그래프가 Arbitrum One에 있는 경우 Arbitrum One의 Explorer에서만 찾을 수 있으며 Ethereum에서는 찾을 수 없습니다. 올바른 네트워크에 있는지 확인하려면 페이지 상단의 네트워크 전환기에서 Arbitrum One을 선택했는지 확인하세요. 이전 후 L1 하위 그래프는 더 이상 사용되지 않는 것으로 표시됩니다.
+
+### 내 하위 그래프를 전송하려면 게시해야 합니까?
+
+하위 그래프 전송 도구를 활용하려면 하위 그래프가 이미 이더리움 메인넷에 게시되어 있어야 하며 하위 그래프를 소유한 지갑이 소유한 일부 큐레이션 신호가 있어야 합니다. 하위 그래프가 게시되지 않은 경우 Arbitrum One에 직접 게시하는 것이 좋습니다. 관련 가스 요금은 상당히 낮아집니다. 게시된 하위 그래프를 전송하고 싶지만 소유자 계정이 이에 대한 신호를 큐레이팅하지 않은 경우 해당 계정에서 소액(예: 1 GRT)을 신호로 보낼 수 있습니다. "자동 마이그레이션" 신호를 선택했는지 확인하세요.
+
+### Arbitrum으로 이전한 후 내 서브그래프의 이더리움 메인넷 버전은 어떻게 되나요?
+
+귀하의 하위 그래프를 Arbitrum으로 이전한 후에는 Ethereum 메인넷 버전이 더 이상 사용되지 않습니다. 48시간 이내에 쿼리 URL을 업데이트하는 것이 좋습니다. 그러나 타사 dapp 지원이 업데이트될 수 있도록 메인넷 URL이 작동하도록 유지하는 유예 기간이 있습니다.
+
+### 양도한 후에 Arbitrum에 다시 게시해야 합니까?
+
+20분의 이체 기간이 지나면 이체를 완료하려면 UI에서 거래를 통해 이체를 확인해야 하지만 이체 도구가 이를 안내합니다. L1 엔드포인트는 전송 기간과 그 이후의 유예 기간 동안 계속 지원됩니다. 편리할 때 엔드포인트를 업데이트하는 것이 좋습니다.
+
+### Will my endpoint experience downtime while re-publishing?
+
+It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the subgraph on L1 and whether they keep indexing it until the subgraph is fully supported on L2.
+
+### L2에서 Ethereum Ethereum 메인넷과 게시 및 버전 관리가 동일합니까?
+
+Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the subgraph.
+
+### 내 하위 그래프의 큐레이션이 내 하위 그래프와 함께 이동하나요?
+
+자동 마이그레이션 신호를 선택한 경우 자체 큐레이션의 100%가 하위 그래프와 함께 Arbitrum One으로 이동됩니다. 하위 그래프의 모든 큐레이션 신호는 전송 시 GRT로 변환되며, 큐레이션 신호에 해당하는 GRT는 L2 하위 그래프의 신호 생성에 사용됩니다.
+
+다른 큐레이터는 GRT 일부를 인출할지, 아니면 L2로 전송하여 동일한 하위 그래프의 신호를 생성할지 선택할 수 있습니다.
+
+### 이전 후 구독을 이더리움 메인넷으로 다시 이동할 수 있나요?
+
+이전되면 이 하위 그래프의 Ethereum 메인넷 버전은 더 이상 사용되지 않습니다. 메인넷으로 다시 이동하려면 다시 메인넷에 재배포하고 게시해야 합니다. 그러나 인덱싱 보상은 결국 Arbitrum One에 전적으로 배포되므로 이더리움 메인넷으로 다시 이전하는 것은 권장되지 않습니다.
+
+### 전송을 완료하려면 브리지된 ETH가 필요한 이유는 무엇입니까?
+
+Arbitrum One의 가스 요금은 브리지된 ETH(즉, Arbitrum One에 브리지된 ETH)를 사용하여 지불됩니다. 그러나 이더리움 메인넷에 비해 가스 비용은 상당히 낮습니다.
+
+## 대표단
+
+### 위임을 어떻게 이전하나요?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+위임을 이전하려면 다음 단계를 완료해야 합니다.
+
+1. 이더리움 메인넷에서 위임 이전 시작
+2. 확인을 위해 20분 정도 기다리세요
+3. Arbitrum에서 위임 이전 확인
+
+\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### 이더리움 메인넷에서 공개 할당으로 전송을 시작하면 보상은 어떻게 되나요?
+
+If the Indexer to whom you're delegating is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer.
+
+### 현재 위임한 인덱서가 Arbitrum One에 없으면 어떻게 됩니까?
+
+L2 전송 도구는 귀하가 위임한 인덱서가 자신의 지분을 Arbitrum으로 전송한 경우에만 활성화됩니다.
+
+### 위임자는 다른 인덱서에게 위임할 수 있나요?
+
+If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to.
+
+### L2에서 위임할 인덱서를 찾을 수 없으면 어떻게 되나요?
+
+L2 전송 도구는 이전에 위임한 인덱서를 자동으로 감지합니다.
+
+### 이전 인덱서 대신 새 인덱서나 여러 인덱서에 내 위임을 혼합하고 일치시키거나 '확산'할 수 있나요?
+
+L2 전송 도구는 항상 이전에 위임한 동일한 인덱서로 위임을 이동합니다. L2로 이동한 후에는 위임을 취소하고 해동 기간을 기다린 후 위임을 분할할지 결정할 수 있습니다.
+
+### 휴지 기간이 적용되나요, 아니면 L2 위임 전송 도구를 사용한 후 즉시 철회할 수 있나요?
+
+Transfer Tool을 사용하면 즉시 L2로 이동할 수 있습니다. 위임을 취소하려면 해동 기간을 기다려야 합니다. 그러나 인덱서가 모든 지분을 L2로 이전한 경우 이더리움 메인넷에서 즉시 출금할 수 있습니다.
+
+### 위임을 양도하지 않으면 보상에 부정적인 영향을 미칠 수 있나요?
+
+향후 모든 네트워크 참여는 Arbitrum One으로 이동할 것으로 예상됩니다.
+
+### 내 위임을 L2로 이전하는 데 시간이 얼마나 걸리나요?
+
+A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Can I transfer my delegation if I'm using a GRT vesting contract/token lock wallet?
+
+예! 베스팅 컨트랙트는 L2 가스 지불에 필요한 ETH를 전달할 수 없기 때문에 프로세스가 조금 다르므로 미리 입금해야 합니다. 귀하의 베스팅 계약이 완전히 베스팅되지 않은 경우 먼저 L2에서 상대방 베스팅 계약을 초기화해야 하며 위임을 이 L2 베스팅 계약으로만 전송할 수 있습니다. Explorer의 UI는 베스팅 잠금 지갑을 사용하여 Explorer에 연결한 경우 이 프로세스를 안내할 수 있습니다.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### 위임세가 있나요?
+
+아니요. L2에서 받은 토큰은 위임세를 부과하지 않고 지정된 위임자를 대신하여 지정된 인덱서에 위임됩니다.
+
+### Will my unrealized rewards be transferred when I transfer my delegation?
+
+​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards.
+
+At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​
+
+### Is moving delegations to L2 mandatory? Is there a deadline?
+
+​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1?
+
+​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## 큐레이션 신호
+
+### 내 큐레이션을 어떻게 이전하나요?
+
+큐레이션을 전송하려면 다음 단계를 완료해야 합니다.
+
+1. 이더리움 메인넷에서 신호 전송 시작
+
+2. L2 큐레이터 주소 지정\*
+
+3. 확인을 위해 20분 정도 기다리세요
+
+\*필요한 경우 - 즉, 계약 주소를 사용하고 있습니다.
+
+### 내가 큐레이트한 하위 그래프가 L2로 이동했는지 어떻게 알 수 있나요?
+
+하위 세부정보 페이지를 보면 해당 하위 하위가 이전되었음을 알리는 배너가 표시됩니다. 메시지에 따라 큐레이션을 전송할 수 있습니다. 이동한 하위 그래프의 하위 그래프 세부정보 페이지에서도 이 정보를 찾을 수 있습니다.
+
+### 큐레이션을 L2로 옮기고 싶지 않으면 어떻게 되나요?
+
+하위 그래프가 더 이상 사용되지 않으면 신호를 철회할 수 있는 옵션이 있습니다. 마찬가지로 하위 그래프가 L2로 이동한 경우 이더리움 메인넷에서 신호를 철회하거나 L2로 신호를 보낼 수 있습니다.
+
+### 내 큐레이션이 성공적으로 전송되었는지 어떻게 알 수 있나요?
+
+L2 전송 도구가 시작된 후 약 20분 후에 Explorer를 통해 신호 세부 정보에 액세스할 수 있습니다.
+
+### 한 번에 두 개 이상의 하위 그래프에 대한 내 큐레이션을 전송할 수 있나요?
+
+현재는 대량 전송 옵션이 없습니다.
+
+## 인덱서 스테이크
+
+### 내 지분을 Arbitrum으로 어떻게 이전하나요?
+
+> 고지 사항: 현재 인덱서에서 GRT의 일부를 언스테이킹 중인 경우 L2 전송 도구를 사용할 수 없습니다.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+지분을 양도하려면 다음 단계를 완료해야 합니다.
+
+1. 이더리움 메인넷에서 지분 이전 시작
+
+2. 확인을 위해 20분 정도 기다리세요
+
+3. Arbitrum에서 지분 이전 확인
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### 내 지분이 모두 이전되나요?
+
+양도할 지분의 양을 선택할 수 있습니다. 모든 지분을 한 번에 이전하기로 선택한 경우 먼저 열려 있는 할당을 모두 종료해야 합니다.
+
+여러 거래를 통해 지분의 일부를 양도할 계획이라면 항상 동일한 수취인 주소를 지정해야 합니다.
+
+참고: 이체 도구를 처음 사용할 때 L2의 최소 지분 요구 사항을 충족해야 합니다. 인덱서는 최소 100,000 GRT를 보내야 합니다(이 함수를 처음 호출할 때). L1에 지분 일부를 남겨 두는 경우 최소 100,000 GRT를 초과해야 하며 (대표단과 함께) 공개 할당량을 감당하기에 충분해야 합니다.
+
+### Arbitrum으로의 지분 이전을 확인하는 데 얼마나 시간이 걸리나요?
+
+\*\*\* Arbitrum에서 지분 이전을 완료하려면 거래를 확인해야 합니다. 이 단계는 7일 이내에 완료되어야 합니다. 그렇지 않으면 지분이 손실될 수 있습니다.
+
+### 공개 할당이 있으면 어떻게 되나요?
+
+지분을 전부 보내지 않는 경우, L2 전송 도구는 최소 100,000 GRT가 이더리움 메인넷에 남아 있고 남은 지분과 위임이 열려 있는 할당량을 감당하기에 충분한지 확인합니다. GRT 잔액이 최소 금액 + 공개 할당을 충족하지 못하는 경우 공개 할당을 종료해야 할 수도 있습니다.
+
+### 전송 도구를 사용하면 전송하기 전에 이더리움 메인넷에서 언스테이크를 해제하는 데 28일을 기다려야 합니까?
+
+아니요, 스테이크를 L2로 즉시 전송할 수 있습니다. 전송 도구를 사용하기 전에 스테이크를 해제하고 기다릴 필요가 없습니다. 28일 대기 기간은 이더리움 메인넷 또는 L2에서 스테이크를 지갑으로 다시 인출하려는 경우에만 적용됩니다.
+
+### 지분을 이전하는 데 얼마나 걸리나요?
+
+L2 전송 도구가 지분 전송을 완료하는 데 약 20분이 소요됩니다.
+
+### 지분을 양도하기 전에 Arbitrum에서 색인을 생성해야 합니까?
+
+인덱싱을 설정하기 전에 먼저 지분을 효과적으로 이전할 수 있지만, L2의 하위 그래프에 할당하고 이를 인덱싱하고 POI를 제시할 때까지는 L2에서 어떤 보상도 청구할 수 없습니다.
+
+### 내가 인덱싱 지분을 이동하기 전에 위임자가 자신의 위임을 이동할 수 있나요?
+
+아니요, 위임자가 위임된 GRT를 Arbitrum으로 전송하려면 위임하는 인덱서가 L2에서 활성화되어 있어야 합니다.
+
+### GRT 베스팅 계약/토큰 잠금 지갑을 사용하는 경우 지분을 양도할 수 있나요?
+
+예! 베스팅 컨트랙트는 L2 가스 비용을 지불하는 데 필요한 ETH를 전달할 수 없기 때문에 프로세스가 조금 다릅니다. 따라서 미리 입금해야 합니다. 귀하의 베스팅 계약이 완전히 베스팅되지 않은 경우 먼저 L2에서 상대방 베스팅 계약을 초기화해야 하며 지분을 이 L2 베스팅 계약으로만 이전할 수 있습니다. Explorer의 UI는 베스팅 잠금 지갑을 사용하여 Explorer에 연결한 경우 이 프로세스를 안내할 수 있습니다.
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## 베스팅 계약 양도
+
+### 베스팅 계약을 어떻게 이전하나요?
+
+베스팅을 이전하려면 다음 단계를 완료해야 합니다.
+
+1. 이더리움 메인넷에서 베스팅 전송을 시작합니다.
+
+2. 확인을 위해 20분 정도 기다리세요
+
+3. Arbitrum에서 베스팅 양도 확인
+
+### 부분적으로만 베스팅된 경우 베스팅 계약을 어떻게 이전합니까?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. 이체 도구 계약에 일부 ETH를 입금하십시오. (UI는 합리적인 금액을 추정하는 데 도움이 될 수 있습니다.)
+
+2. L2 베스팅 잠금을 초기화하기 위해 전송 도구 계약을 통해 일부 잠긴 GRT를 L2로 보냅니다. 그러면 L2 수취인 주소도 설정됩니다.
+
+3. L1Stake 계약의 "잠긴" 전송 도구 기능을 통해 스테이크/위임권을 L2로 보냅니다.
+
+4. 전송 도구 계약에서 남은 ETH를 인출하세요.
+
+### 완전히 베스팅된 경우 베스팅 계약을 어떻게 이전합니까?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+완전히 베스팅된 경우 프로세스는 유사합니다.
+
+1. 이체 도구 계약에 일부 ETH를 입금하십시오. (UI는 합리적인 금액을 추정하는 데 도움이 될 수 있습니다.)
+
+2. 전송 도구 계약을 호출하여 L2 주소를 설정하세요.
+
+3. L1 스테이킹 계약의 "잠긴" 전송 도구 기능을 통해 스테이크/위임금을 L2로 보냅니다.
+
+4. 전송 도구 계약에서 남은 ETH를 인출하세요.
+
+### 베스팅 계약을 Arbitrum으로 이전할 수 있나요?
+
+베스팅 계약의 GRT 잔액을 L2의 베스팅 계약으로 이전할 수 있습니다. 이는 베스팅 계약에서 L2로 지분이나 위임을 이전하기 위한 전제 조건입니다. 베스팅 계약은 0이 아닌 금액의 GRT를 보유해야 합니다(필요한 경우 1 GRT와 같은 소액을 전송할 수 있음).
+
+L1 베스팅 계약에서 L2로 GRT를 전송할 때 보낼 금액을 선택할 수 있으며 원하는 만큼 이 작업을 수행할 수 있습니다. L2 베스팅 계약은 GRT를 처음 전송할 때 초기화됩니다.
+
+이체는 베스팅 계약 계정에 연결할 때 Explorer 프로필에 표시되는 이체 도구를 사용하여 수행됩니다.
+
+계약이 완전히 확정된 베스팅 일정이 끝날 때까지 L2 베스팅 계약에서 GRT를 해제/철회할 수 없다는 점에 유의하세요. 그 전에 GRT를 해제해야 하는 경우 해당 목적에 사용할 수 있는 다른 전송 도구를 사용하여 GRT를 L1 베스팅 계약으로 다시 전송할 수 있습니다.
+
+베스팅 계약 잔액을 L2로 이전하지 않았고 베스팅 계약이 완전히 베스팅된 경우, 베스팅 계약을 L2로 이전해서는 안 됩니다. 대신 전송 도구를 사용하여 L2 지갑 주소를 설정하고 L2의 일반 지갑으로 지분이나 위임을 직접 전송할 수 있습니다.
+
+### 나는 베스팅 계약을 사용해 메인넷에 스테이킹하고 있습니다. 내 지분을 Arbitrum으로 이전할 수 있나요?
+
+예, 하지만 계약이 아직 베스팅 중인 경우 L2 베스팅 계약이 소유하도록 지분을 양도할 수 있습니다. 먼저 Explorer의 베스팅 계약 이전 도구를 사용하여 일부 GRT 잔액을 이전하여 이 L2 계약을 초기화해야 합니다. 계약이 완전히 확정된 경우 지분을 L2의 어떤 주소로든 전송할 수 있지만 L2 가스 비용을 지불하려면 L2 전송 도구에 대해 미리 설정하고 일부 ETH를 입금해야 합니다.
+
+### 나는 메인넷에 위임하기 위해 베스팅 계약을 사용하고 있습니다. 내 위임을 Arbitrum으로 이전할 수 있나요?
+
+예. 하지만 계약이 아직 베스팅 중인 경우 L2 베스팅 계약이 소유하도록 위임을 양도할 수 있습니다. 먼저 Explorer의 베스팅 계약 이전 도구를 사용하여 일부 GRT 잔액을 이전하여 이 L2 계약을 초기화해야 합니다. 계약이 완전히 확정된 경우 L2의 어떤 주소로든 위임을 전송할 수 있지만, L2 가스 비용을 지불하려면 L2 전송 도구에 대한 일부 ETH를 미리 설정하고 예치해야 합니다.
+
+### L2 베스팅 계약에 대해 다른 수혜자를 지정할 수 있나요?
+
+예. 처음 잔액을 이체하고 L2 베스팅 계약을 설정할 때 L2 수혜자를 지정할 수 있습니다. 이 수혜자가 Arbitrum One에서 거래를 수행할 수 있는 지갑인지 확인하세요. 즉, Arbitrum One에 배포된 EOA 또는 다중 서명이어야 합니다.
+
+귀하의 계약이 완전히 확정된 경우 L2에 가득 계약을 설정하지 않습니다. 대신 L2 지갑 주소를 설정하게 되며 이는 Arbitrum의 스테이크 또는 위임을 위한 수신 지갑이 됩니다.
+
+### 내 계약은 완전히 귀속되었습니다. 내 지분이나 위임을 L2 베스팅 계약이 아닌 다른 주소로 이전할 수 있나요?
+
+예. 베스팅 계약 잔액을 L2로 이전하지 않았고 베스팅 계약이 완전히 베스팅된 경우, 베스팅 계약을 L2로 이전해서는 안 됩니다. 대신 전송 도구를 사용하여 L2 지갑 주소를 설정하고 L2의 일반 지갑으로 지분이나 위임을 직접 전송할 수 있습니다.
+
+이를 통해 스테이크나 위임을 어떤 L2 주소로든 전송할 수 있습니다.
+
+### 내 베스팅 계약은 아직 베스팅 중입니다. 베스팅 계약 잔액을 L2로 어떻게 이전합니까?
+
+이 단계는 귀하의 계약이 아직 베스팅 중이거나 계약이 아직 베스팅 중일 때 이전에 이 프로세스를 사용한 경우에만 적용됩니다.
+
+베스팅 계약을 L2로 이전하려면 L2 베스팅 계약을 초기화하는 이전 도구를 사용하여 GRT 잔액을 L2로 보내십시오.
+
+1. 일부 ETH를 전송 도구 계약에 입금하십시오. (이는 L2 가스 비용을 지불하는 데 사용됩니다.)
+
+2. 베스팅 계약에 대한 프로토콜 액세스 취소(다음 단계에 필요)
+
+3. 베스팅 계약에 프로토콜 액세스 권한을 부여합니다(귀하의 계약이 전송 도구와 상호 작용할 수 있도록 허용합니다).
+
+4. L2 수취인 주소\*를 지정하고 이더리움 메인넷에서 잔액 이체를 시작하세요.
+
+5. 확인을 위해 20분 정도 기다리세요
+
+6. L2 잔액 이체 확인
+
+\*필요한 경우 - 즉, 계약 주소를 사용하고 있습니다.
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### 베스팅 계약을 다시 L1으로 이동할 수 있나요?
+
+귀하의 베스팅 계약은 아직 L1에 있으므로 그렇게 할 필요가 없습니다. 전송 도구를 사용하면 L1 베스팅 계약과 연결된 L2에서 새 계약을 생성하고 두 계약 간에 GRT를 주고받을 수 있습니다.
+
+### 우선 베스팅 계약을 이동해야 하는 이유는 무엇입니까?
+
+이 계정이 L2에 대한 지분이나 위임을 소유할 수 있도록 L2 베스팅 계약을 설정해야 합니다. 그렇지 않으면 베스팅 계약을 "탈출"하지 않고 지분/위임권을 L2로 이전할 수 있는 방법이 없습니다.
+
+### 부분적으로만 확정된 계약을 현금화하려고 하면 어떻게 됩니까? 이것이 가능한가?
+
+이것은 가능성이 없습니다. 자금을 다시 L1으로 옮기고 그곳에서 인출할 수 있습니다.
+
+### 베스팅 계약을 L2로 옮기고 싶지 않으면 어떻게 하나요?
+
+L1에서는 계속 스테이킹/위임할 수 있습니다. 시간이 지남에 따라 Arbitrum에서 프로토콜이 확장됨에 따라 L2로 이동하여 보상을 활성화하는 것을 고려할 수 있습니다. 이러한 전송 도구는 프로토콜에서 지분을 보유하고 위임할 수 있는 계약을 베스팅하기 위한 것입니다. 계약이 스테이킹이나 위임을 허용하지 않거나 취소 가능한 경우에는 사용 가능한 전송 도구가 없습니다. 가능한 경우 L1에서 GRT를 인출할 수 있습니다.

From 515c9db51505d66b0ac17570126849f2e8d57004 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:49 -0500
Subject: [PATCH 1031/3820] New translations l2-transfer-tools-faq.mdx (Dutch)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/nl/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/nl/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/nl/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..45e6b2ec3dc2
--- /dev/null
+++ b/website/pages/nl/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2 Transfer Tools FAQ
+---
+
+## General
+
+### What are L2 Transfer Tools?
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### Can I use the same wallet I use on Ethereum mainnet?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### Wat gebeurt er als ik mijn overdracht niet binnen 7 dagen afrond?
+
+De L2 Transfer Tools gebruiken Arbitrum's eigen mechanismen op berichten te sturen van L1 naar L2. Dit mechanisme heet een "retryable ticket" en is gebruikt door alle eigen token bruggen, inclusief de Arbitrum GRT brug. Je kunt meer lezen over retryable tickets in de [Arbiturm docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+Wanneer je jouw activa (subgraph, inzet, delegatie of curatie) overdraagt naar L2, wordt er een bericht via de Arbitrum GRT-brug gestuurd dat een herhaalbaar ticket in L2 aanmaakt. De overdrachtstool bevat een bepaalde hoeveelheid ETH in de transactie, die gebruikt wordt om 1) te betalen voor de creatie van de ticket en 2) te betalen voor de gas voor de uitvoer van de ticket in L2. Omdat de gasprijzen kunnen variëren in de tijd tot het ticket gereed is om in L2 uit te voeren, is het mogelijk dat deze automatische uitvoerpoging mislukt. Als dat gebeurt, zal de Arbitrum-brug het herhaalbare ticket tot 7 dagen lang actief houden, en iedereen kan proberen het ticket te "inlossen" (wat een portemonnee met wat ETH dat naar Arbitrum is overgebracht, vereist).
+
+Dit is wat we de "Bevestigen"-stap noemen in alle overdrachtstools - deze zal in de meeste gevallen automatisch worden uitgevoerd, omdat de automatische uitvoering meestal succesvol is, maar het is belangrijk dat je terugkeert om te controleren of het is gelukt. Als het niet lukt en er zijn geen succesvolle herhaalpogingen in 7 dagen, zal de Arbitrum-brug het ticket verwerpen, en je activa (subgraph, inzet, delegatie of curatie) zullen verloren gaan en kunnen niet worden hersteld. De kernontwikkelaars van The Graph hebben een bewakingssysteem om deze situaties te detecteren en proberen de tickets in te lossen voordat het te laat is, maar uiteindelijk ben jij verantwoordelijk om ervoor te zorgen dat je overdracht op tijd is voltooid. Als je problemen hebt met het bevestigen van je transactie, neem dan contact op via [dit formulier](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) en de kernontwikkelaars zullen er zijn om je te helpen.
+
+### Ik ben mijn delegatie/inzet/curatie overdracht begonnen en ik ben niet zeker of deze door is gekomen naar L2, hoe kan ik bevestigen dat deze correct is overgedragen?
+
+Als je geen banner op je profiel ziet die vraagt om de overdracht af te ronden, dan is het waarschijnlijk dat de transactie het veilig heft gehaald naar L2 en geen acties meer vereist zijn. Als je twijfelt, kan je checken of Explorer jouw delegatie, inzet of curatie toont op Arbitrum One.
+
+Als je de L1 transactie-hash hebt (die je kunt vinden door naar de recente transacties in je portemonnee te kijken), kun je ook bevestigen of het "herhaalbare ticket" dat de boodschap naar L2 heeft gedragen hier is ingewisseld: https://retryable-dashboard.arbitrum.io/ - als de automatische inwisseling is mislukt, kun je ook daar je portemonnee verbinden en het inwisselen. Wees gerust dat de kernontwikkelaars ook berichten monitoren die vastlopen en zullen proberen ze in te wisselen voordat ze verlopen.
+
+## Subgraph Overdracht
+
+### Hoe verplaats ik mijn subgraphs?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+Om je subgraph te verplaatsen, moet je de volgende stappen volgen:
+
+1. Start de overdracht op het Ethereum mainnet
+
+2. Wacht 20 minuten op bevestiging
+
+3. Bevestig subgraph overdracht op Arbitrum\*
+
+4. Maak het publiceren van subrgaph op Arbitrum af
+
+5. Update Query URL (aanbevolen)
+
+\*Let op dat je de overdracht binnen 7 dagen moet bevestigen, anders kan je subgraph verloren gaan. In de meeste gevallen zal deze stap automatisch verlopen, maar een handmatige bevestiging kan nodig zijn als er een gasprijsstijging is op Arbitrum. Als er tijdens dit proces problemen zijn, zijn er bronnen beschikbaar om te helpen: neem contact op met de ondersteuning via support@thegraph.com of op [Discord](https://discord.gg/graphprotocol).
+
+### Waarvandaan moet ik mijn overdracht vanaf starten?
+
+Je kan je overdracht starten vanaf de [Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) of elke subgraph details pagina. Klik de "Transfer Subgraph" knop in de subgraph details pagina om de overdracht te starten.
+
+### Hoe lang moet ik wachten to mijn subrgaph overgedragen is
+
+De overdracht duurt ongeveer 20 minuten. De Arbitrum brug werkt momenteel op de achtergrond om de brug overdracht automatisch te laten voltooien. In sommige gevallen kunnen gaskosten pieken en zul je de overdracht opnieuw moeten bevestigen.
+
+### Is mijn subgraph nog te ontdekken nadat ik het naar L2 overgedragen heb?
+
+Jouw subgraph zal alleen te ontdekken zijn op het netwerk waarnaar deze gepubliceerd is. Bijvoorbeeld, als jouw subgraph gepubliceerd is op Arbitrum One, dan kan je deze alleen vinden via de Explorer op Arbitrum One en zul je deze niet kunnen vinden op Ethereum. Zorg ervoor dat je Arbitrum One hebt geselecteerd in de netwerkschakelaar bovenaan de pagina om er zeker van te zijn dat je op het juiste netwerk bent.  Na de overdracht zal de L1 subgraph als verouderd worden weergegeven.
+
+### Moet mijn subgraph gepubliceerd zijn om deze te kunnen overdragen?
+
+Om gebruik te maken van de subgraph transfer tool, moet jouw subgraph al gepubliceerd zijn op het Ethereum mainnet en moet het enige curatie-signalen hebben die eigendom zijn van de wallet die de subgraph bezit. Als jouw subgraph nog niet is gepubliceerd, wordt het aanbevolen om het direct op Arbitrum One te publiceren - de bijbehorende gas fees zullen aanzienlijk lager zijn. Als je een gepubliceerde subgraph wilt overdragen maar het eigenaarsaccount heeft nog geen enkel curatie-signalen, kun je een klein bedrag signaleren (bv.: 1 GRT) vanaf dat account; zorg ervoor dat je "auto-migrating" signalen kiest.
+
+### Wat gebeurt er met de Ethereum mainnet versie van mijn subgraph nadat ik overdraag naar Arbitrum?
+
+Nadat je je subgraph naar Arbitrum hebt overgezet, zal de versie op het Ethereum mainnet als verouderd worden beschouwd. We raden aan om je query URL binnen 48 uur bij te werken. Er is echter een overgangsperiode waardoor je mainnet URL nog steeds werkt, zodat ondersteuning voor externe dapps kan worden bijgewerkt.
+
+### Nadat ik overgedragen heb, moet ik opnieuw publiceren op Arbitrum?
+
+Na de overdracht periode van 20 minuten, zul je de overdracht moeten bevestigen met transactie in de UI om de overdracht af te ronden, maar de transfer tool zal je hierdoor begeleiden. Jouw L1 endpoint zal worden ondersteund tijdens de overdracht periode en transitie periode hierna. Het wordt aangeraden om jouw endpoint bij te werken wanneer dit jou uitkomt.
+
+### Zal mijn eindpunt downtime ervaren tijdens het opnieuw publiceren?
+
+Het is onwaarschijnlijk, maar mogelijk om een korte downtime te ervaren afhankelijk van welke Indexers de subgraph op L1 ondersteunen en of zij blijven indexen totdat de subgraph volledig ondersteund wordt op L2.
+
+### Is het publiceren en versiebeheer hetzelfde op L2 als Ethereum mainnet?
+
+Ja. Selecteer Arbiturm One als jou gepubliceerde netwerk tijdens het publiceren in Subrgaph Studio. In de studio, de laatste endpoint die beschikbaar is zal wijzen naar de meest recentelijk bijgewerkte versie van de subgraph.
+
+### Zal mijn subgraphs curatie mee verplaatsen met mijn subgraph?
+
+Als je gekozen hebt voor auto-migrating signal, dan zal 100% van je eigen curatie mee verplaatsen met jouw subgraph naar Arbitrum One. Alle curatie signalen van de subgraph zullen worden omgezet naar GRT tijdens de overdracht en alle GRT die corresponderen met jouw curatie signaal zullen worden gebruikt om signalen te minten op de L2 subgraph.
+
+Andere curators kunnen kiezen of ze hun deel van GRT kunnen opnemen, of overdragen naar L2 om signalen te minten op dezelfde subgraph.
+
+### Kan ik nadat ik mijn subgraph overgedragen heb deze weer terug overdragen naar Ethereum mainnet?
+
+Wanneer overgedragen, zal jouw Ethereum mainnet versie van deze subgraph als verouderd worden beschouwd. Als je terug wilt gaan naar het mainnet, zul je deze opnieuw moeten implementeren en publiceren op het mainnet. Echter, het wordt sterk afgeraden om terug naar het Ethereum mainnet over te dragen gezien index beloningen uiteindelijk op Arbitrum One zullen worden verdeeld.
+
+### Waarom heb ik gebrugd ETH nodig om mijn transactie te voltooien?
+
+Gas fees op Arbitrum One zijn betaald door middel van gebrugd ETH (bv. ETH dat naar Arbitrum One gebrugd is). Echter, gas fees zijn aanzienlijk lager vergeleken met Ethereum mainnet.
+
+## Delegatie
+
+### Hoe draag ik mijn delegatie over?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+Om je delegatie over te dragen moet je de volgende stappen volgen:
+
+1. Start delegatie overdracht op Ethereum mainnet
+2. Wacht 20 minuten op bevestiging
+3. Bevestig delegatie overdracht op Arbitrum
+
+\*\*\*\*Je moet de transactie bevestigen om de delegatie overdracht te voltooien op Arbitrum. Deze stap moet binnen 7 dagen voltooid worden of de delegatie kan verloren gaan. In de meeste gevallen, zal deze stap automatisch verlopen, maar een handmatige bevestiging kan nodig zijn als er een gasprijsstijging is op Arbitrum. Als er problemen zijn tijdens dit process, zijn er hier hulpmiddelen: neem contact op met support via support@thegraph.com op op [Discord](https://discord.gg/graphprotocol).
+
+### Wat gebeurt er met mijn beloningen als ik een overdracht start met een open allocatie op Ethereum mainnet?
+
+Als de Indexer waaraan je gedelegeerd hebt nog steeds actief is op L1, zul je bij de overdracht naar Arbitrum eventuele delegatiebeloningen van openstaande allocaties op het Ethereum-mainnet verliezen. Dit betekent dat je de beloningen van hoogstens de laatste 28-daagse periode zult verliezen. Als je de overdracht precies plant na het sluiten van de allocaties door de Indexer, kun je ervoor zorgen dat dit het minimale bedrag is. Als je een communicatiekanaal hebt met je Indexer(s), overweeg dan om met hen te bespreken wanneer het beste moment is om de overdracht uit te voeren.
+
+### Wat gebeurt er als de Indexer waaraan ik gedelegeerd heb niet actief is op Arbitrum One?
+
+De L2 transfer tool zal alleen worden ingeschakeld als de Indexer waaraan je hebt gedelegeerd hun eigen inzet heeft overgedragen naar Arbitrum.
+
+### Hebben Delegatoren de optie om een andere Indexer te delegeren?
+
+Als je wilt delegeren naar een andere Indexer, kun je overdragen naar dezelfde Indexer op Arbitrum, daarna delegeren ongedaan maken en wachten op de dooiperiode. Hierna, kun je een andere actieve delegator kiezen om naar te delegeren.
+
+### Wat als ik de Indexer niet kan vinden waarnaar ik delegeer op L2?
+
+De L2 transfer tool zal automatisch de Indexer detecteren naar wie je eerder gedelegeerd hebt.
+
+### Zal ik mijn delegatie kunnen verdelen of 'spreiden' over nieuw of meerdere Indexers in plaats van de voorgaande Indexer?
+
+De L2 transfer tool zal altijd jouw delegatie verplaatsen naar dezelfde Indexer aan wie jij eerder gedelegeerd hebt. Zodra je bent verplaatst naar L2 kan ja, onderdelegeren, wachten op de dooi-periode, en beslissen of jij je delegering wilt splitsen.
+
+### Ben ik gebonden aan de dooi-periode of kan ik direct opnemen na het gebruiken van de L2 transfer tool?
+
+De transfer tool staat jou toe direct naar te verplaatsen naar L2. Als je wilt onderdelegeren zul je moeten wachten op de dooi-periode. Alhoewel, als een Indexer al hun inzet heeft overgedragen naar L2 zul je direct kunnen opnemen op het Ethereum Mainnet.
+
+### Kunnen mijn beloningen negatief beïnvloedt worden als ik mijn delegering overdraag?
+
+Het is verwacht dat alle netwerk deelname zal verplaatsen naar Arbitrum One in de toekomst.
+
+### Hoe lang duurt het voordat de overdracht van mijn delegering naar L2 voldaan is?
+
+Een 20-minuten bevestiging is nodig voor een delegerings-overdracht. Houd er rekening dat na de periode van 20 minuten, je stap 3 van het overdracht proces moet voltooien binnen 7 dagen. Als je dit niet doet, zou je delegering verloren gegaan kunnen. Houd ook rekening met dat de tool, in de meeste gevallen, deze stap automatisch zal voltooien. In het geval van een gefaalde auto-attempt, zul je dit handmatig moeten voltooien. Mochten er problemen omhoog komen tijdens dit proces, geen zorgen, wij zijn hier om te helpen: bereik ons via support@thegraph.com of op [Discord](https://discord.gg/graphprotocol).
+
+### Kan ik mijn delegering overdragen als ik gebruik maak van een GRT toekenningscontract/token lock wallet?
+
+Ja! Het proces is een beetje anders omdat toekenningscontract de benodigde ETH voor de L2-gas niet kunnen doorsturen, dus je moet het van tevoren storten. Als je toekenningscontract nog niet volledig is gevestigd, moet je ook eerst een tegenhanger van het toekenningscontract op L2 initialiseren en kun je alleen de delegering overzetten naar dit L2-toekenningscontract. De UI op Explorer kan je door dit proces leiden wanneer je bent verbonden met Explorer met behulp van de vesting lock-wallet.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### Is er een delegering belasting?
+
+Nee. Ontvangen tokens op L2 zijn gedelegeerd aan de specifieke Indexer namens de gespecificeerde Delegator zonder een delegering belasting.
+
+### Zullen mijn ongerealiseerde beloningen overgedragen worden als ik mijn delegering overdraag?
+
+Ja! De enige beloningen die niet overgedragen kunnen worden zijn degene voor open allocaties, omdat deze niet zullen bestaan totdat de Indexer de allocaties sluit (doorgaans elke 28 dagen). Als je voor een tijd al aan het delegeren bent geweest zal dit enkel een fractie van de beloningen zijn.
+
+Op het smart contract niveau, ongerealiseerde beloningen zijn al deel van je delegering balans, dus worden deze overgedragen wanneer je jouw delegering overdraagt naar L2.
+
+### Is verplaatsen van delegeringen naar L2 verplicht? Is er een deadline?
+
+Verplaatsen van delegeringen naar L2 is niet verplicht, maar index beloningen groeien op L2 volgend de tijdlijn omschreven in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Uiteindelijk, als de raad de toenames blijft goedkeuren, zullen alle beloningen in L2 worden verdeeld en zullen er geen index beloningen zijn voor Indexers en Delegators op L1.
+
+### Als ik aan het delegeren ben aan een Indexer die al zijn inzet overgedragen heeft naar L2, ontvang ik dan geen beloningen meer op L1?
+
+Vele Indexers zijn geleidelijk inzet aan het overdragen zodat Indexers op L1 nog steeds beloningen en vergoedingen ontvangen op L1, die vervolgens gedeeld worden met Delegators. Zodra een Indexer al zijn inzet overgedragen heeft, houden zij op met opereren op L1, dus Delegators zullen geen beloningen meer ontvangen tenzij ze overdragen naar L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## Curatie Signaal
+
+### Hoe draag ik mijn curatie over?
+
+Om je curatie over te dragen, moet je de volgende stappen volgen:
+
+1. Start de signaal overdracht op het Ethereum mainnet
+
+2. Specifieer een L2 Curator address\*
+
+3. Wacht 20 minuten op bevestiging
+
+\*indien nodig - bv. als je een contract adres gebruikt hebt.
+
+### Hoe weet ik of de subgraph die ik cureer verplaatst is naar L2?
+
+Bij het bekijken van de details pagina van de subgraph zal er een banner verschijnen om je te laten weten dat deze subgraph is overgedragen. Je kunt de instructies volgen om je curatie over te zetten. Deze informatie is ook te vinden op de detailspagina van elke subgraph die is overgezet.
+
+### Wat als ik niet mijn curatie wil overdragen naar L2?
+
+Wanneer een subgraph is verouderd, heb je de optie om je signaal terug te trekken. Op dezelfde manier, als een subgraph naar L2 is verhuisd, kun je ervoor kiezen om je signaal op het Ethereum-mainnet terug te trekken of het signaal naar L2 te sturen.
+
+### Hoe weet ik of mijn curatie succesvol is overgedragen?
+
+Signaal details zullen toegankelijk zijn via Explorer ongeveer 20 minuten nadat de L2 transfer tool is gestart.
+
+### Kan ik mijn curatie overdragen op meer dan een subgraph per keer?
+
+Op dit moment is er geen bulk overdracht optie.
+
+## Indexer Inzet
+
+### Hoe draag ik mijn inzet over naar Arbitrum?
+
+> Disclaimer: If you are currently unstaking any portion of your GRT on your Indexer, you will not be able to use L2 Transfer Tools.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+Om je inzet over te dragen, moet je de volgende stappen volgen:
+
+1. Start de inzet overdracht op Ethereum mainnet
+
+2. Wacht 20 minuten op bevestiging
+
+3. Bevestig inzet overdracht op Arbitrum
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Zal al mijn inzet overgedragen worden?
+
+Je kan kiezen hoeveel van inzet je wilt overdragen. Als je ervoor kiest om al je inzet in een keer over te dragen, zul je eerst openstaande allocaties moeten sluiten.
+
+Als je van plan bent on je inzet over te dragen in meerdere transacties, moet je altijd hetzelfde begunstigde adres opgeven.
+
+Let op: De eerste keer dat je de overdracht tool gebruikt, moet je voldoen aan de minimale inzet vereisten op L2. Indexers moeten ten minste 100.000 GRT verzenden (bij het uitvoeren van deze functie voor de eerste keer). Als je een deel van je inzet op L1 achterlaat, moet dit ook boven het minimum van 100.000 GRT zijn en voldoende zijn (samen met je delegaties) om je openstaande allocaties te dekken.
+
+### Hoe lang heb ik om mijn inzet overdracht te bevestigen naar Arbitrum?
+
+\*\*\* Je moet jouw transactie bevestigen om je inzet overdracht te voltooien op Arbitrum. Deze stap moet voltooid worden binnen 7 dagen of je inzet kan verloren gaan.
+
+### Wat als ik allocaties open heb staan?
+
+Als je niet al je inzet verstuurt, zal de L2-overdrachtstool valideren dat er ten minste het minimum van 100k GRT achterblijft op het Ethereum mainnet en dat je resterende inzet en delegaties voldoende zijn om eventuele openstaande allocaties te dekken. Mogelijk moet je openstaande allocaties sluiten als je GRT-saldo de minimumvereisten + openstaande allocaties niet dekt.
+
+### Gebruik makend van de transfer tools, is het noodzakelijk om 28 dagen te wachten om je inzet op heffen op Ethereum mainnet voor het overdragen?
+
+Nee, je kan je inzet direct naar L2 overdragen, het is niet nodig om je inzet op te heffen en wachten voordat je gebruik maakt van de transfer tool. De 28 dagen wachttijd is alleen van toepassing als je de inzet wilt opnemen naar je wallet, op Ethereum mainnet of L2.
+
+### Hoe lang zal het duren om mijn inzet over te dragen?
+
+Het duurt ongeveer 20 minuten voordat de L2-overdrachtstool je inzet heeft overgezet.
+
+### Moet ik indexeren op Arbitrum voordat ik mijn inzet overdraag?
+
+Je kunt je inzet effectief overdragen voordat je indexing opzet, maar je zult geen beloningen kunnen claimen op L2 totdat je toewijst aan subgraphs op L2, ze indexeert en POI's presenteert.
+
+### Kunnen Delegators hun delegatie overdragen voordat ik mijn index inzet overdraag?
+
+Nee, om Delegators in staat te stellen hun gedelegeerde GRT naar Arbitrum over te zetten, moet de Indexer waaraan ze delegeren actief zijn op L2.
+
+### Kan ik mijn inzet overdragen als ik een GRT toekenningscontract / token lock-wallet gebruik?
+
+Ja! Het proces is een beetje anders, omdat toekenningscontract de benodigde ETH voor de L2-gas niet kunnen doorsturen, dus je moet het van tevoren storten. Als je toekenningscontract nog niet volledig is toegekend, moet je ook eerst een tegenhanger van het toekenningscontract op L2 initialiseren en kun je alleen de inzet overzetten naar dit L2-toekenningscontract. De UI op Explorer kan je door dit proces leiden wanneer je bent verbonden met Explorer met behulp van de toekenning lock-wallet.
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## Toekenningscontract Overdracht
+
+### Hoe draag ik mijn toekenningscontract over?
+
+Om je toekenning over te dragen, moet je de volgende stappen volgen:
+
+1. Start de toekennings transfer op Ethereum mainnet
+
+2. Wacht 20 minuten op bevestiging
+
+3. Bevestig toekenning transfer op Arbitrum
+
+### Hoe draag ik mijn toekenningscontract over als ik alleen deels toegekend ben?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Stort wat ETH in de transfer tool contract (UI kan helpen met het schatten van een redelijke hoeveelheid)
+
+2. Stuur wat gesloten GRT via de transfer tool contract naar L3 om de L2 vesting lock te starten. Deze zal ook de begunstigde adres instellen.
+
+3. Stuur de inzet/delegering naar L2 door de "gesloten" transfer tool functies in de L1Staking contract.
+
+4. Neem overgebleven ETH op van de transfer tool contract
+
+### Hoe draag ik mijn vesting contract over als ik volledig gevest ben?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+Voor die volledig toegekend zijn is het proces vergelijkbaar:
+
+1. Stort wat ETH in de transfer tool contract (UI kan helpen met het schatten van een redelijke hoeveelheid)
+
+2. Stel jouw L2 adres in met een vraag aan de transfer tool contract
+
+3. Stuur jouw inzet/delegering naar L2 door de "gesloten" transfer tool functies in de L1 Staking contract.
+
+4. Neem overgebleven ETH op van de transfer tool contract
+
+### Kan ik mijn toekenningscontract overdragen naar Arbitrum?
+
+Je kan je toekenninscontract's GRT-balans overdragen aan een toekenningscontract in L2. Dit is een vereiste voor inzet overdracht of delegering van jouw toekenningscontract naar L2. De toekennignscontract met een niet nul hoeveelheid aan GRT bevatten (je kunt kleine hoeveelheden zoals 1 GRT overdragen indien nodig).
+
+Wanneer jij GRT overdraagt van jouw L1 toekenningscontract naar L2, kan je de hoeveelheid om te sturen kiezen en dit doen zo vaak je wilt. De L2 toekenningscontract zal gestart worden de eerste keer dat je GRT overdraagt.
+
+De overdrachten worden gedaan door middel van de Transfer Tool die zichtbaar zullen zijn op jouw Explorer profiel zodra je verbindt met de toekenninsgcontract account.
+
+Houd rekening dat je niet GRT kunt opnemen/vrijlaten van de L2 toekenningscontract to het einde van je toekenningstijdlijn wanneer je contract volledig is toegekend. Als jij je GRT moet vrijlaten voor dat moment, kan jij je GRT weer terug overdragen naar de L1 toekenningscontract door middel van een andere tool die beschikbaar is voor deze toepassing.
+
+Als je nog niet toekenningscontract balans overgedragen hebt naar L2, en je contract is volledig toegekend, moet je niet je toekenningscontract overdragen naar L2. In plaats daarvan kan je de transfer tool gebruiken om een L2 wallet adres in te stellen, en direct je inzet of delegering over te dragen naar deze reguliere wallet op L2.
+
+### Ik gebruik mijn toekenningscontract om in te zetten op mainnet. Kan ik mijn inzet overdragen naar Arbitrum?
+
+Ja, maar als je contract nog aan het toekennen is, kan je alleen de inzet overdragen die van jouw toekenningscontract is. Je moet eerst deze L2 contract starten door GRT balans over te dragen door gebruik te maken van de toekenningscontract overdracht tool op Explorer. Als jouw contract volledig overgedragen is, kun je jouw inzeten overdragen naar elk adres in L2, maar je moet deze op voorhand instellen en ETH storten om de L2 tool te laten betalen voor L2 gas.
+
+### Ik gebruik mijn toekenningscontract om te delegeren op mainnet. Kan ik mijn delegeringen overdragen naar Arbitrum?
+
+Ja, maar als je contract nog aan het toekennen is, kan je alleen de delegering overdragen die van jouw toekenningscontract is. Je moet eerst deze L2 contract starten door GRT balans over te dragen door gebruik te maken van de toekenningscontract overdracht tool op Explorer. Als jouw contract volledig overgedragen is, kun je jouw delegering overdragen naar elk adres in L2, maar je moet deze op voorhand instellen en ETH storten om de L2 tool te laten betalen voor L2 gas.
+
+### Kan ik een andere begunstigde specificeren voor mijn toekenninscontract op L2?
+
+Ja, de eerste keer dat je balans overdraagt en je L2 toekennings contract opzet moet je een L2 begunstigde opgeven. Zorg dat de begunstigde een wallet is waarmee je transacties op Arbitrum One kunt uitvoeren, bijv. het moet een EOA of een multisig zijn ingezet op Arbitrum One.
+
+Als je contract volledig toegekend is, zul je niet een toekenningscontract opzetten op L2; in plaats daarvan, zul je een L2 wallet adres instellen en zal deze de ontvangende wallet zijn voor jouw inzet of delegering op Arbitrum.
+
+### Mijn contract is volledig toegekend. Kan ik mijn inzet of delegering overdragen naar een ander adres dat niet een L2 toekenning contract is?
+
+Ja. Als je nog niet toekenningscontract balans overgedragen hebt naar L2, en je contract is volledig toegekend, moet je niet je toekenningscontract overdragen naar L2. In plaats daarvan kan je de transfer tool gebruiken om een L2 wallet adres in te stellen, en direct je inzet of delegering over te dragen naar deze reguliere wallet op L2.
+
+Dit staat je toe om je inzet of delegering over te dragen naar elk L2 adres.
+
+### Mij toekenning contract is nog steeds toe aan het kennen. Hoe draag ik mijn toekenning balans over naar L2?
+
+Deze stappen zijn alleen van toepassing als je contract nog steeds toe aan het kennen is, of als je dit proces gebruikt hebt toen je contract nog toe aan het kennen was.
+
+Om je toekenning contract over te dragen naar L2, zul je elke GRT-balans naar L2 sturen door middel van de transfer tools die je L2 toekenning contract zullen starten:
+
+1. Stort wat ETH in de transfer tool contract (deze zal gebruikt worden om je L2 gas te financieren)
+
+2. Hef protocol toegang naar de toekenning contract op (benodigd voor de volgende stap)
+
+3. Geef protocol toegang aan het toekenningscontract (laat jouw contract interactie te hebben met de overdracht tool)
+
+4. Specifieer een L2 begunstigde adres\* en start de balans overdracht op Ethereum mainnet
+
+5. Wacht 20 minuten op bevestiging
+
+6. Bevestig de balans overdracht op L2
+
+\*indien nodig - bv. als je een contract adres gebruikt hebt.
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### Kan ik mijn toekenning contract terug verplaatsen naar L1?
+
+Er is geen nood om dit te doen omdat je toekenning contract nog steeds in L1 is. Als jee gebruik maakt van de transfer tools dan creëer je een nieuw contract in L2 dat verbonden is met je L1 toekenning contract, en je kan GRT tussen deze twee sturen.
+
+### Waarom moet ik überhaupt mijn toekenning contract verplaatsen om mee te beginnen?
+
+Je moet een L2 toekenning contract opzetten zodat deze account bezit kan nemen van jouw inzet of delegering op L2. Anders is er geen mogelijkheid voor jou om inzet/delegering over te dragen naar L2 zonder te "ontsnappen" van de toekenning contract.
+
+### Wat gebeurt er als ik mijn contract uit probeer te betalen als deze gedeeltelijk toegekend is? Is dit mogelijk?
+
+Dit is geen mogelijkheid. Je kan fondsen terug naar L1 overdragen en van daar opnemen.
+
+### Wat als ik niet mijn toekenning contract wil verplaatsen naar L2?
+
+Je kan blijven inzetten/delegeren op L1. Naar mate de tijd vordert zou je kunnen overwegen om over te dragen naar L2 om daar beloningen in te schakelen naarmate het protocol opschaalt op Arbitrum. Houd er rekening mee dat deze tools voor toekenning contracten zijn die in mogen zetten en delegeren in het protocol. Als jouw contract inzetten of delegeren niet toelaat, of herroproepbaar is, dan zijn er geen transfer tools beschikbaar. Je kan nog steeds GRT opnemen van L1 indien beschikbaar.

From 5cb3e794220b98b911a7c4c3beb9e1cb82c9f46c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:50 -0500
Subject: [PATCH 1032/3820] New translations l2-transfer-tools-faq.mdx (Polish)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/pl/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/pl/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/pl/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..5c517c3f2887
--- /dev/null
+++ b/website/pages/pl/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: Narzędzia przesyłania L2 - najczęściej zadawane pytania
+---
+
+## General
+
+### Czym są narzędzia przesyłania L2?
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### Czy mogę używać tego samego portfela, którego używam w mainnecie Ethereum?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### Co się stanie, jeśli nie zrealizuję przesyłania w ciągu 7 dni?
+
+Narzędzia przesyłania L2 używają natywnego mechanizmu Arbitrum do wysyłania wiadomości z L1 do L2. Mechanizm ten nazywany jest "ponowny bilet" i jest używany przez wszystkie natywne mosty tokenowe, w tym most Arbitrum GRT. Więcej informacji na temat "ponownych biletów" można znaleźć w [dokumentacji Arbitrum](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+Kiedy przenosisz swoje aktywa (subgraph, stake, delegowanie lub kuratorstwo) do L2, wiadomość jest wysyłana przez most Arbitrum GRT, który tworzy bilet z możliwością ponownej próby w L2. Narzędzie transferu zawiera pewną wartość ETH w transakcji, która jest wykorzystywana do 1) zapłaty za utworzenie biletu i 2) zapłaty za gaz do wykonania biletu w L2. Ponieważ jednak ceny gazu mogą się różnić w czasie do momentu, gdy bilet będzie gotowy do zrealizowania w L2, możliwe jest, że ta próba automatycznego wykonania zakończy się niepowodzeniem. Gdy tak się stanie, most Arbitrum utrzyma ten bilet aktywnym przez maksymalnie 7 dni, i każdy może ponowić próbę "zrealizowania" biletu (co wymaga portfela z pewną ilością ETH pzesłanego do Arbitrum).
+
+Nazywamy to etapem "Potwierdzenia" we wszystkich narzędziach do przesyłania - w większości przypadków będzie on wykonywany automatycznie, ponieważ najczęściej kończy się sukcesem, ale ważne jest, aby sprawdzić i upewnić się, że się powiódł. Jeśli się nie powiedzie i w ciągu 7 dni nie będzie skutecznych ponownych prób, most Arbitrum odrzuci bilet, a twoje zasoby ( subgraf, stake, delegowanie lub kuratorstwo) zostaną utracone i nie będzie można ich odzyskać. Główni programiści Graph mają system monitorowania, który wykrywa takie sytuacje i próbuje zrealizować bilety, zanim będzie za późno, ale ostatecznie to ty jesteś odpowiedzialny za zapewnienie, że przesyłanie zostanie zakończone na czas. Jeśli masz problemy z potwierdzeniem transakcji, skontaktuj się z nami za pomocą [tego formularza] (https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms), a nasi deweloperzy udzielą Ci pomocy.
+
+### I started my delegation/stake/curation transfer and I'm not sure if it made it through to L2, how can I confirm that it was transferred correctly?
+
+If you don't see a banner on your profile asking you to finish the transfer, then it's likely the transaction made it safely to L2 and no more action is needed. If in doubt, you can check if Explorer shows your delegation, stake or curation on Arbitrum One.
+
+If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire.
+
+## Subgraph Transfer
+
+### Jak mogę przenieść swój subgraph?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+Aby przesłać swój subgraf, należy wykonać następujące kroki:
+
+1. Zainicjuj przesyłanie w sieci głównej Ethereum
+
+2. Poczekaj 20 minut na potwierdzenie
+
+3. Potwierdź przesyłanie subgrafu na Arbitrum\*
+
+4. Zakończ publikowanie subgrafu na Arbitrum
+
+5. Zaktualizuj adres URL zapytania (zalecane)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Skąd powinienem zainicjować przesyłanie?
+
+Przesyłanie można zainicjować ze strony [Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) lub dowolnej strony zawierającej szczegóły subgrafu. Kliknij przycisk "Prześlij subgraf " na tej stronie, aby zainicjować proces przesyłania.
+
+### Jak długo muszę czekać, aż mój subgraf zostanie przesłany
+
+Przesyłanie trwa około 20 minut. Most Arbitrum działa w tle, automatycznie kończąc przesyłanie danych. W niektórych przypadkach koszty gazu mogą wzrosnąć i konieczne będzie ponowne potwierdzenie transakcji.
+
+### Czy mój subgraf będzie nadal wykrywalny po przesłaniu go do L2?
+
+Twój subgraf będzie można znaleźć tylko w sieci, w której został opublikowany. Na przykład, jeśli subgraf znajduje się w Arbitrum One, można go znaleźć tylko w Eksploratorze w Arbitrum One i nie będzie można go znaleźć w Ethereum. Upewnij się, że wybrałeś Arbitrum One w przełączniku sieci u góry strony i że jesteś we właściwej sieci. Po przesłaniu subgraf L1 będzie oznaczony jako nieaktualny.
+
+### Czy mój subgraf musi zostać opublikowany, aby móc go przesłać?
+
+Aby skorzystać z narzędzia do przesyłania subgrafów, musi on być już opublikowany w sieci głównej Ethereum i musi mieć jakiś sygnał kuratorski należący do portfela, który jest właścicielem subgrafu. Jeśli subgraf nie został opublikowany, zaleca się po prostu opublikowanie go bezpośrednio na Arbitrum One - związane z tym opłaty za gaz będą znacznie niższe. Jeśli chcesz przesłać opublikowany subgraf, ale konto właściciela nie ma na nim żadnego sygnału, możesz zasygnalizować niewielką kwotę (np. 1 GRT) z tego konta; upewnij się, że wybrałeś sygnał "automatycznej migracji".
+
+### Co stanie się z wersją mojego subgrafu w sieci głównej Ethereum po przesłaniu go do Arbitrum?
+
+Po przesłaniu subgrafu do Arbitrum, wersja głównej sieci Ethereum zostanie wycofana. Zalecamy zaktualizowanie adresu URL zapytania w ciągu 48 godzin. Istnieje jednak okres prolongaty, dzięki któremu adres URL sieci głównej będzie dalej funkcjonował, tak aby można było zaktualizować obsługę innych aplikacji.
+
+### Czy po przesłaniu muszę również ponownie opublikować na Arbitrum?
+
+Po upływie 20-minutowego okna przesyłania konieczne będzie jego potwierdzenie za pomocą transakcji w interfejsie użytkownika, aby zakończyć przesyłanie, przy czym narzędzie do przesyłania poprowadzi Cię przez ten proces. Twój endpoint L1 będzie nadal obsługiwany podczas okna przesyłania i okresu prolongaty po jego zakończeniu. Zachęcamy do aktualizacji swojego endpointa w dogodnym dla siebie momencie.
+
+### Will my endpoint experience downtime while re-publishing?
+
+It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the subgraph on L1 and whether they keep indexing it until the subgraph is fully supported on L2.
+
+### Czy publikowanie i wersjonowanie jest takie samo w L2 jak w sieci głównej Ethereum?
+
+Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the subgraph.
+
+### Czy kurator mojego subgrafu będzie się przemieszczał wraz z moim subgrafem?
+
+Jeśli wybrałeś automatyczną migrację sygnału, 100% twojego własnego kuratorstwa zostanie przeniesione wraz z subgrafem do Arbitrum One. Cały sygnał kuratorski subgrafu zostanie przekonwertowany na GRT w momencie transferu, a GRT odpowiadający sygnałowi kuratorskiemu zostanie użyty do zmintowania sygnału na subgrafie L2.
+
+Inni kuratorzy mogą zdecydować, czy wycofać swoją część GRT, czy też przesłać ją do L2 w celu zmintowania sygnału na tym samym subgrafie.
+
+### Czy mogę przenieść swój subgraf z powrotem do głównej sieci Ethereum po jego przesłaniu?
+
+Po przesłaniu, wersja tego subgrafu w sieci głównej Ethereum zostanie wycofana. Jeśli chcesz ją przywrócić do sieci głównej, musisz ją ponownie wdrożyć i opublikować. Jednak przeniesienie z powrotem do sieci głównej Ethereum nie jest zalecane, ponieważ nagrody za indeksowanie zostaną całkowicie rozdzielone na Arbitrum One.
+
+### Dlaczego potrzebuję bridgowanego ETH do przesłania?
+
+Opłaty za gaz w Arbitrum One są uiszczane za pomocą bridgowanego ETH (tj. ETH, które zostało przeniesione do Arbitrum One). Opłaty za gaz są jednak znacznie niższe w porównaniu do głównej sieci Ethereum.
+
+## Delegowanie
+
+### Jak mogę przesłać swoją delegację?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+Aby przesłać delegację, należy wykonać następujące kroki:
+
+1. Zainicjuj przesyłanie delegacji w sieci głównej Ethereum
+2. Poczekaj 20 minut na potwierdzenie
+3. Potwierdź przesyłanie delegacji na Arbitrum
+
+\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Co stanie się z moimi nagrodami, jeśli zainicjuję przesył z otwartą alokacją w sieci głównej Ethereum?
+
+If the Indexer to whom you're delegating is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer.
+
+### What happens if the Indexer I currently delegate to isn't on Arbitrum One?
+
+The L2 transfer tool will only be enabled if the Indexer you have delegated to has transferred their own stake to Arbitrum.
+
+### Czy Delegaci mają możliwość delegowania do innego Indeksera?
+
+If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to.
+
+### Co jeśli nie mogę znaleźć Indeksera, do którego deleguję w L2?
+
+Narzędzie przesyłania L2 automatycznie wykryje indexera, do którego wcześniej delegowałeś.
+
+### Czy będę mógł łączyć i modyfikować lub "rozkładać" moje delegacje pomiędzy jednym nowym lub kilkoma Indekserami zamiast dotychczasowego?
+
+Narzędzie przesyłania L2 zawsze przenosi delegację do tego samego Indeksera, do którego delegowano wcześniej. Po przeniesieniu do L2 możesz cofnąć delegację, poczekać do momentu rozmrożenia i zdecydować, czy chcesz rozdzielić delegację.
+
+### Czy podlegam okresowi zawieszenia, czy też mogę wypłacić środki natychmiast po skorzystaniu z narzędzia przesyłania delegacji L2?
+
+Narzędzie przesyłania umożliwia natychmiastowe przeniesienie do L2. Jeśli chcesz cofnąć delegację, będziesz musiał poczekać na okres rozmrażania. Jeśli jednak Indekser przesłał cały swój stake do L2, możesz natychmiast wypłacić środki w sieci głównej Ethereum.
+
+### Czy może to mieć negatywny wpływ na moje nagrody, jeśli nie przekażę delegacji?
+
+Przewiduje się, że w przyszłości cały udział w sieci zostanie przeniesiony do Arbitrum One.
+
+### Jak długo trwa przesyłanie delegacji do L2?
+
+A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Czy mogę przesłać swoją delegację, jeśli korzystam z kontraktu GRT/portfela z zablokowanymi tokenami?
+
+Tak! Proces jest nieco inny, ponieważ kontrakty vestingowe nie mogą przekazywać ETH niezbędnych do opłacenia gazu L2, więc musisz je wcześniej wpłacić. Jeśli twój kontrakt vestingowy nie jest w pełni vestowany, najpierw będziesz musiał zainicjować odpowiednik kontraktu vestingowego na L2 i dopiero wtedy będziesz mógł przenieść delegację do tego właśnie kontraktu. Interfejs użytkownika w Eksploratorze poprowadzi Cię przez ten proces, gdy połączysz się z Eksploratorem za pomocą portfela z blokadą vestingu.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### Czy istnieje podatek od delegacji?
+
+Nie. Otrzymane tokeny na L2 są delegowane do określonego Indeksera w imieniu określonego Delegatora bez naliczania podatku od delegacji.
+
+### Will my unrealized rewards be transferred when I transfer my delegation?
+
+​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards.
+
+At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​
+
+### Is moving delegations to L2 mandatory? Is there a deadline?
+
+​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1?
+
+​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## Sygnał kuratorski
+
+### Jak mogę przesłać swoje kuratorstwo?
+
+Aby przesłać swoje kuratorstwo, należy wykonać następujące kroki:
+
+1. Zainicjuj przesyłanie sygnału w sieci głównej Ethereum
+
+2. Podaj adres kuratora L2\*
+
+3. Poczekaj 20 minut na potwierdzenie
+
+\*Jeżeli będzie wymagane - np. w przypadku korzystania z adresu kontraktu.
+
+### Skąd będę wiedzieć, czy subgraf, którego jestem kuratorem, został przeniesiony do L2?
+
+Podczas przeglądania strony ze szczegółami subgrafu pojawi się baner informujący, że subgraf został przeniesiony. Możesz postępować zgodnie z wyświetlanymi instrukcjami, aby przesłać swoje kuratorstwo. Informacje te można również znaleźć na stronie ze szczegółami subgrafu każdego z tych, które zostały przeniesione.
+
+### Co jeśli nie chcę przenosić swojego kuratorstwa do L2?
+
+Gdy subgraf jest nieaktualny, masz możliwość wycofania swojego sygnału. Podobnie, jeśli subgraf został przeniesiony do L2, możesz wycofać swój sygnał w sieci głównej Ethereum lub wysłać sygnał do L2.
+
+### Skąd mam wiedzieć, że moje kuratorstwo zostało pomyślnie przesłane?
+
+Szczegóły sygnału będą dostępne za pośrednictwem Eksploratora po upływie ok. 20 minut od uruchomienia narzędzia do przesyłania L2.
+
+### Czy mogę przesłać swoje kuratorstwo do więcej niż jednego subgrafu na raz?
+
+Obecnie nie ma opcji zbiorczego przesyłania.
+
+## Stake Indeksera
+
+### Jak mogę przesłać swój stake do Arbitrum?
+
+> Zastrzeżenie: Jeśli obecnie dokonujesz unstakingu jakiejkolwiek części GRT w swoim Indekserze, nie będziesz mógł korzystać z Narzędzi Przesyłania L2.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+Aby przesłać swój stake, należy wykonać następujące kroki:
+
+1. Zainicjuj przesłanie stake'u w sieci głównej Ethereum
+
+2. Poczekaj 20 minut na potwierdzenie
+
+3. Potwierdź przesyłanie stake'u na Arbitrum
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Czy wszystkie moje stake'i zostaną przesłane?
+
+Możesz wybrać, jaką część stake'u chcesz przesłać. Jeśli zdecydujesz się przenieść cały swój stake za jednym razem, będziesz musiał najpierw zamknąć wszystkie otwarte alokacje.
+
+Jeśli planujesz przesłać część swojego stake'u w kilku transakcjach, musisz zawsze podawać ten sam adres beneficjenta.
+
+Ważne: Przy pierwszym użyciu narzędzia do przesyłania musisz spełnić minimalne wymagania dotyczące stake'u na L2. Indeksatorzy muszą wysłać minimum 100 tys. GRT (przy pierwszym wywołaniu tej funkcji). W przypadku pozostawienia części stake'u na L1, musi ona również przekraczać minimum 100 tys. GRT i być wystarczająca (wraz z delegacjami) do pokrycia otwartych alokacji.
+
+### Ile mam czasu na potwierdzenie przesłania stake'u do Arbitrum?
+
+\*\*\* Aby zakończyć przesyłanie stake'u na Arbitrum, należy potwierdzić transakcję. Ten krok należy wykonać w ciągu 7 dni, w przeciwnym razie stake może zostać utracony.
+
+### Co jeśli mam otwarte alokacje?
+
+Jeśli nie wysyłasz całego swojego stake'a, narzędzie do przesyłania L2 zweryfikuje, czy w sieci głównej Ethereum pozostało co najmniej 100 tys. GRT, a pozostała część stake'a i delegacji jest wystarczająca do pokrycia wszelkich otwartych alokacji. Może być konieczne zamknięcie otwartych alokacji, jeśli saldo GRT nie pokrywa minimum + otwartych alokacji.
+
+### Korzystając z narzędzi do przesyłania, czy konieczne jest czekanie 28 dni na odblokowanie w sieci głównej Ethereum przed dokonaniem przesłania?
+
+Nie, możesz przesłać swój stake do L2 natychmiast, nie ma potrzeby unstake'owania i czekania przed użyciem narzędzia do przesyłania. 28-dniowy okres oczekiwania ma miejsce tylko wtedy, gdy chcesz wypłacić stake z powrotem do swojego portfela, w sieci głównej Ethereum lub L2.
+
+### Jak długo potrwa przesłanie mojego stake'u?
+
+Przesyłanie stake'a przez narzędzie do przesyłania L2 zajmie około 20 minut.
+
+### Czy muszę indeksować na Arbitrum, zanim przekażę swój stake?
+
+Możesz skutecznie przesłać swój stake przed skonfigurowaniem indeksowania, lecz nie będziesz w stanie odebrać żadnych nagród na L2, dopóki nie alokujesz do subgrafów na L2, nie zindeksujesz ich i nie podasz POI.
+
+### Czy delegaci mogą przenieść swoje delegacje, zanim ja przeniosę swój indeksujący stake?
+
+No, in order for Delegators to transfer their delegated GRT to Arbitrum, the Indexer they are delegating to must be active on L2.
+
+### Czy mogę przesłać swój stake, jeśli korzystam z kontraktu GRT / portfela z blokadą tokena?
+
+Tak! Proces jest nieco inny, ponieważ kontrakty vestingowe nie mogą przesyłać ETH potrzebnych do opłacenia gazu L2, więc musisz je wcześniej wpłacić. Jeśli Twój kontrakt vestingowy nie jest w pełni vestowany, będziesz musiał również najpierw zainicjować odpowiednik kontraktu vestingowego na L2 i będziesz mógł przesłać stake tylko do tego kontraktu vestingowego L2. Interfejs użytkownika w Eksploratorze poprowadzi Cię przez ten proces, gdy połączysz się z Eksploratorem za pomocą portfela vesting lock.
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## Przesłanie Kontraktu Vestingowego
+
+### Jak mogę przesłać kontrakt vestingowy?
+
+Aby przesłać vesting, należy wykonać następujące kroki:
+
+1. Zainicjuj przesyłanie vestingu w sieci głównej Ethereum
+
+2. Poczekaj 20 minut na potwierdzenie
+
+3. Potwierdź przesłanie vestingu na Arbitrum
+
+### W jaki sposób mogę przesłać swój kontrakt vestingowy, jeśli mam tylko część vestingu?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Wpłać trochę ETH do kontraktu narzędzia przesyłania (UI pomoże oszacować odpowiednią kwotę)
+
+2. Wyślij zablokowane GRT za pośrednictwem kontraktu narzędzia przesyłania do L2, aby zainicjować blokadę vestingu L2. Ustawi to również adres beneficjenta L2.
+
+3. Wyślij swój stake/delegację do L2 poprzez "zablokowane" funkcje narzędzia przesyłania w kontrakcie stakingu L1.
+
+4. Wycofaj pozostałe ETH z kontraktu narzędzia przesyłania
+
+### W jaki sposób mogę przesłać kontrakt vestingowy, jeśli mam pełny vesting?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+Dla tych, którzy mają pełny vesting, proces wygląda podobnie:
+
+1. Wpłać trochę ETH do kontraktu narzędzia przesyłania (UI pomoże oszacować odpowiednią kwotę)
+
+2. Ustaw adres L2 za pomocą wywołania kontraktu narzędzia przesyłania
+
+3. Wyślij swój stake/delegację do L2 poprzez "zablokowane" funkcje narzędzia przesyłania w kontrakcie stakingu L1.
+
+4. Wycofaj pozostałe ETH z kontraktu narzędzia przesyłania
+
+### Czy mogę przesłać swój kontrakt vestingowy do Arbitrum?
+
+Możesz przesłać saldo GRT kontraktu vestingowego do kontraktu vestingowego w L2. Jest to warunek wstępny do przesłania stake'u lub delegacji z kontraktu vestingowego do L2. Kontrakt vestingowy musi posiadać jakąś ilość GRT (w razie potrzeby możesz przesłać do niego niewielką ilość, np. 1 GRT).
+
+Przesyłając GRT z kontraktu vestingowego L1 do L2, możesz wybrać wysokość kwoty do wysłania i zrobić to tyle razy, ile chcesz. Kontrakt vestingowy L2 zostanie zainicjowany przy pierwszym przesłaniu GRT.
+
+Przesyłanie odbywa się za pomocą narzędzia do przesyłania, które będzie widoczne na profilu Eksploratora po połączeniu się z kontem kontraktu vestingowego.
+
+Należy pamiętać, że nie będzie można odblokować/wycofać GRT z kontraktu vestingowego L2 do końca okresu vestingu, gdy kontrakt zostanie w pełni vestingowany. Jeśli musisz odblokować GRT przed tym terminem, możesz przesłać GRT z powrotem do kontraktu vestingowego L1 za pomocą innego narzędzia przesyłania, które jest przeznaczone właśnie dla tego celu.
+
+Jeśli nie przesłałeś żadnego salda kontraktu vestingowego do L2, a Twój kontrakt vestingowy jest w pełni opłacony, nie powinieneś przenosić swojego kontraktu vestingowego do L2. Zamiast tego możesz użyć narzędzi do przesyłania, aby ustawić adres portfela L2 i bezpośrednio przenieść swój stake lub delegację do tego zwykłego portfela na L2.
+
+### Używam kontraktu vestingowego do stakingu w mainnecie. Czy mogę przenieść swój stake do Arbitrum?
+
+Tak, lecz jeżeli Twój kontrakt nadal się vestinguje, możesz przesłać stake tylko w taki sposób, aby był on własnością Twojego kontraktu vestingowego L2. Musisz najpierw zainicjować ten kontrakt L2, przesyłając saldo GRT za pomocą narzędzia do przesyłania kontraktów vestingowych w Eksploratorze. Jeśli Twój kontrakt jest w pełni vestowany, możesz przesłać swój stake na dowolny adres w L2, ale musisz go wcześniej ustawić i wpłacić trochę ETH, aby narzędzie do przesyłania L2 zapłaciło za gaz w L2.
+
+### Używam swojego kontraktu vestingowego do delegowania w mainnecie. Czy mogę przesłać swoje delegacje do Arbitrum?
+
+Tak, ale jeśli Twój kontrakt nadal się vestinguje, możesz przesłać delegację tylko w taki sposób, aby była własnością Twojego kontraktu vestingowego L2. Musisz najpierw zainicjować ten kontrakt L2, przesyłając saldo GRT za pomocą narzędzia do przesyłania kontraktów vestingowych w Eksploratorze. Jeśli twój kontrakt jest w pełni vestowany, możesz przesłać swoją delegację na dowolny adres w L2, ale musisz go wcześniej ustawić i wpłacić trochę ETH do narzędzia do przesyłania L2, aby zapłacić za gaz w L2.
+
+### Czy mogę wybrać innego beneficjenta dla kontraktu vestingowego na L2?
+
+Tak, przy pierwszym przesłaniu salda i ustawieniu kontraktu vestingowego L2 można określić beneficjenta L2. Upewnij się, że ten beneficjent jest portfelem, który może wykonywać transakcje na Arbitrum One, tj. musi to być EOA lub multisig wdrożony w Arbitrum One.
+
+Jeśli Twój kontrakt jest w pełni vestowany, nie będziesz musiał ustawiać kontraktu vestingowego na L2; zamiast tego ustawisz adres portfela L2 i będzie to portfel odbiorczy dla Twojego stake'a lub delegacji na Arbitrum.
+
+### Mój kontrakt jest w pełni vestowany. Czy mogę przesłać swój stake lub delegację na inny adres, który nie jest kontraktem vestingowym L2?
+
+Tak. Jeśli nie przesłałeś żadnego salda kontraktu vestingowego do L2, a Twój kontrakt vestingowy jest w pełni vestowany, nie powinieneś przesyłać swojego kontraktu vestingowego do L2. Zamiast tego możesz użyć narzędzi do przesyłania, aby ustawić adres portfela L2 i bezpośrednio przesłać swój stake lub delegację do tego zwykłego portfela na L2.
+
+Pozwala to na przesłanie stake'a lub delegacji na dowolny adres L2.
+
+### Mój kontrakt vestingowy jest nadal vestowany. Jak mogę przesłać saldo kontraktu vestingowego do L2?
+
+Kroki te mają zastosowanie tylko wtedy, gdy Twój kontrakt jest nadal vestowany lub jeśli wykonałeś te kroki, gdy Twój kontrakt był jeszcze vestowany.
+
+Aby przesłać kontrakt vestingowy do L2, należy przesłać saldo GRT do L2 za pomocą narzędzi przesyłania, co spowoduje zainicjowanie kontraktu vestingowego L2:
+
+1. Wpłać trochę ETH do kontraktu narzędzia przesyłania (zostanie to wykorzystane do zapłaty za gaz L2)
+
+2. Anuluj dostęp protokołu do kontraktu vestingowego (potrzebne do następnego kroku)
+
+3. Udziel protokołowi dostępu do kontraktu vestingowego (pozwoli to na interakcję kontraktu z narzędziem przesyłania)
+
+4. Określ adres beneficjenta L2\* i zainicjuj przesyłanie salda w sieci głównej Ethereum
+
+5. Poczekaj 20 minut na potwierdzenie
+
+6. Potwierdź przesłanie salda na L2
+
+\*Jeżeli będzie wymagane - np. w przypadku korzystania z adresu kontraktu.
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### Czy mogę przesłać swój kontrakt vestingowy z powrotem do L1?
+
+Nie ma takiej potrzeby, ponieważ Twój kontrakt vestingowy nadal znajduje się w L1. Kiedy korzystasz z narzędzi przesyłania, po prostu tworzysz nowy kontrakt w L2, który jest połączony z kontraktem vestingowym w L1 i możesz wysyłać GRT pomiędzy nimi.
+
+### Dlaczego muszę przenosić kontrakt vestingowy?
+
+Musisz ustawić kontrakt vestingowy L2, aby to konto mogło mieć Twój stake lub delegację na L2. W przeciwnym razie nie będzie możliwości przesłania stake'u/delegacji do L2 bez "uniknięcia" kontraktu vestingowego.
+
+### Co się stanie, jeśli spróbuję wypłacić środki z mojego kontraktu, gdy są one tylko częściowo vestowane? Czy jest to możliwe?
+
+Nie ma takiej możliwości. Możesz przenieść środki z powrotem do L1 i stamtąd je wypłacić.
+
+### Co zrobić, jeśli nie chcę przenosić mojego kontraktu vestingowego do L2?
+
+Możesz nadal stake'ować/delegować na L1. Z czasem możesz rozważyć przeniesienie się do L2, aby umożliwić otrzymywanie nagród w miarę skalowania protokołu na Arbitrum. Należy pamiętać, że te narzędzia przesyłania są przeznaczone dla kontraktów vestingowych, które mogą stake'ować i delegować w protokole. Jeśli twój kontrakt nie pozwala na stake'owanie lub delegowanie, lub podlega unieważnieniu, wówczas nie ma dostępnego narzędzia do przesyłania. Nadal będziesz mógł wypłacić swój GRT z L1, gdy będzie dostępny.

From 2c7805c2e4555ae6286af6402900d9aae26fb127 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:51 -0500
Subject: [PATCH 1033/3820] New translations l2-transfer-tools-faq.mdx
 (Portuguese)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/pt/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/pt/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/pt/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..2e16beb4b0c9
--- /dev/null
+++ b/website/pages/pt/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: Perguntas Frequentes sobre Ferramentas de Transferência para L2
+---
+
+## Geral
+
+### O que são Ferramentas de Transferência para L2?
+
+O The Graph diminuiu em 26x o custo para contribuintes participarem na rede através do lançamento do protocolo ao Arbitrum One. As Ferramentas de Transferência para L2 foram criadas por programadores centrais para facilitar a mudança à L2.
+
+Para cada participante na rede, um conjunto de Ferramentas de Transferência para L2 é disponibilizado para suavizar a experiência, de modo a evitar períodos de degelo ou ter que sacar GRT e colocá-lo em bridge manualmente.
+
+Estas ferramentas exigem aderência a um conjunto específico de passos a depender do seu papel dentro do The Graph e o que será transferido para a L2.
+
+### Posso usar a mesma carteira que uso na mainnet do Ethereum?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Carteiras em blockchains EVM como Ethereum e Arbitrum são um par de chaves (pública e privada), que você cria sem precisar interagir com a blockchain. Qualquer carteira criada para o Ethereum também funcionará no Arbitrum sem ter que fazer qualquer outra coisa.
+
+A exceção é com carteiras de contrato inteligente como multisigs: estas são contratos inteligentes publicados separadamente em cada chain, que buscam os endereços necessários quando lançados. Se uma multisig foi publicada no Ethereum, ela não existirá com o mesmo endereço no Arbitrum. Uma nova multisig deve ser criada primeiro no Arbitrum; esta tem chances de receber um endereço diferente.
+
+### O que acontece se a minha transferência não for finalizada em 7 dias?
+
+As Ferramentas de Transferência para L2 usam o mecanismo nativo do Arbitrum para enviar mensagens da L1 à L2. Este mecanismo é chamado de "retryable ticket" (bilhete retentável) e é usado por todos os bridges de tokens nativos, incluindo o bridge de GRT do Arbitrum. Leia mais na [documentação do Arbitrum](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+Ao transferir os seus ativos (subgraph, stake, delegação ou curadoria) à L2, é enviada uma mensagem através do bridge de GRT do Arbitrum, que cria um retryable ticket na L2. A ferramenta de transferência inclui um valor de ETH na transação, que é usado para pagar 1) pela criação do ticket e 2) pelo gas da execução do ticket na L2. Porém, devido à possível variação dos preços de gas no tempo até a execução do ticket na L2, esta tentativa de execução automática pode falhar. Se isto acontecer, o bridge do Arbitrum tentará manter o retryable ticket ativo por até 7 dias; assim, qualquer pessoa pode tentar novamente o "resgate" do ticket (que requer uma carteira com algum ETH em bridge ao Arbitrum).
+
+Este é o passo de "Confirmação" em todas as ferramentas de transferência. Ele será executado automaticamente e com êxito na maioria dos casos, mas é importante verificar que ele foi executado. Se não tiver êxito na primeira execução e nem em quaisquer das novas tentativas dentro de 7 dias, o bridge do Arbitrum descartará o ticket, e os seus ativos (subgraph, stake, delegação ou curadoria) serão perdidos sem volta. Os programadores-núcleo do The Graph têm um sistema de monitoria para detectar estas situações e tentar resgatar os tickets antes que seja tarde, mas no final, a responsabilidade é sua de que a sua transferência complete a tempo. Caso haja problemas ao confirmar a sua transação, contacte-nos com [este formulário](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) e o núcleo tentará lhe ajudar.
+
+### Eu comecei a transferir a minha delegação/meu stake/minha curadoria e não tenho certeza se ela chegou à L2, como posso ter certeza de que a mesma foi transferida corretamente?
+
+Caso não veja um banner no seu perfil pedindo que termine a transferência, a transação pode ter chegado com segurança na L2 e você não precisa fazer mais nada. Caso haja dúvidas, é possível conferir se o Explorer mostra a sua delegação, seu stake ou a sua curadoria no Arbitrum One.
+
+Se tiver o hash de transação da L1 (confira as transações recentes na sua carteira), podes também confirmar se o "bilhete retentável" que entregou a mensagem à L2 foi resgatado aqui: https://retryable-dashboard.arbitrum.io/ - se o resgate automático falhar, podes também conectar a sua carteira lá e resgatá-lo. Os programadores-núcleo também procuram mensagens que se perdem no caminho, e tentarão resgatar os bilhetes antes que vençam.
+
+## Transferência de Subgraph
+
+### Como transfiro o meu subgraph?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+Para transferir o seu subgraph, complete os seguintes passos:
+
+1. Inicie a transferência na mainnet Ethereum
+
+2. Espere 20 minutos pela confirmação
+
+3. Confirme a transferência do subgraph no Arbitrum\*
+
+4. Termine de editar o subgraph no Arbitrum
+
+5. Atualize o URL de Query (recomendado)
+
+\*Você deve confirmar a transferência dentro de 7 dias, ou o seu subgraph poderá ser perdido. Na maioria dos casos, este passo será executado automaticamente, mas pode ser necessário confirmar manualmente caso haja um surto no preço de gas no Arbitrum. Caso haja quaisquer dificuldades neste processo, contacte o suporte em support@thegraph.com ou no [Discord](https://discord.gg/graphprotocol).
+
+### De onde devo iniciar a minha transferência?
+
+Do [Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) ou de qualquer página de detalhes de subgraph. Clique no botão "Transfer Subgraph" (Transferir Subgraph) na página de detalhes de subgraph para começar a transferência.
+
+### Quanto tempo devo esperar até que o meu subgraph seja transferido
+
+A transferência leva cerca de 20 minutos. O bridge do Arbitrum trabalha em segundo plano para completar a transferência automaticamente. Às vezes, os custos de gas podem subir demais e a transação deverá ser confirmada novamente.
+
+### O meu subgraph ainda poderá ser descoberto após ser transferido para a L2?
+
+O seu subgraph só será descobrível na rede em qual foi editado. Por exemplo, se o seu subgraph estiver no Arbitrum One, então só poderá encontrá-lo no Explorer do Arbitrum One e não no Ethereum. Garanta que o Arbitrum One está selecionado no seletor de rede no topo da página para garantir que está na rede correta.  Após a transferência, o subgraph na L1 aparecerá como depreciado.
+
+### O meu subgraph precisa ser editado para poder ser transferido?
+
+Para aproveitar a ferramenta de transferência de subgraph, o seu subgraph já deve estar editado na mainnet Ethereum e deve ter algum sinal de curadoria em posse da carteira titular do subgraph. Se o seu subgraph não estiver editado, edite-o diretamente no Arbitrum One - as taxas de gas associadas serão bem menores. Se quiser transferir um subgraph editado, mas a conta titular não curou qualquer sinal nele, você pode sinalizar uma quantidade pequena (por ex. 1 GRT) daquela conta; escolha o sinal "migração automática".
+
+### O que acontece com a versão da mainnet Ethereum do meu subgraph após eu transferi-lo ao Arbitrum?
+
+Após transferir o seu subgraph ao Arbitrum, a versão na mainnet Ethereum será depreciada. Recomendamos que atualize o seu URL de query em dentro de 28 horas. Porém, há um período que mantém o seu URL na mainnet em funcionamento, para que qualquer apoio de dapp de terceiros seja atualizado.
+
+### Após a transferência, preciso reeditar no Arbitrum?
+
+Após a janela de transferência de 20 minutos, confirme a transferência com uma transação na interface para finalizá-la; a ferramenta de transferência te guiará no processo. O seu endpoint na L1 continuará a ser apoiado durante a janela e por um período de graça após isto. Vale atualizar o seu endpoint quando lhe for conveniente.
+
+### O meu endpoint estará fora do ar durante a reedição?
+
+É improvável, mas é possível passar por um breve desligamento a depender de quais Indexadores apoiam o subgraph na L1, e de se eles continuarão a indexá-lo até o subgraph ter apoio total na L2.
+
+### Editar e versionar na L2 funcionam da mesma forma que na mainnet Ethereum?
+
+Sim. Selcione o Arbitrum One como a sua rede editada ao editar no Subgraph Studio. No Studio, o último endpoint disponível apontará à versão atualizada mais recente do subgraph.
+
+### A curadoria do meu subgraph se mudará com o meu subgraph?
+
+Caso tenha escolhido o sinal automigratório, 100% da sua própria curadoria se mudará ao Arbitrum One junto com o seu subgraph. Todo o sinal de curadoria do subgraph será convertido em GRT na hora da transferência, e o GRT correspondente ao seu sinal de curadoria será usado para mintar sinais no subgraph na L2.
+
+Outros Curadores podem escolher se querem sacar a sua fração de GRT, ou também transferi-la à L2 para mintar sinais no mesmo subgraph.
+
+### Posso devolver o meu subgraph à mainnet Ethereum após a transferência?
+
+Após a transferência, a versão da mainnet Ethereum deste subgraph será depreciada. Se quiser devolvê-lo à mainnet, será necessário relançá-lo e editá-lo de volta à mainnet. Porém, transferir de volta à mainnet do Ethereum é muito arriscado, já que as recompensas de indexação logo serão distribuidas apenas no Arbitrum One.
+
+### Por que preciso de ETH em bridge para completar a minha transferência?
+
+As taxas de gás no Arbitrum One são pagas com ETH em bridge (por ex. ETH que foi conectado ao Arbitrum One). Porém, as taxassão muito menores comparadas à mainnet Ethereum.
+
+## Delegação
+
+### Como transfiro a minha delegação?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+Para transferir a sua delegação, complete os seguintes passos:
+
+1. Inicie a transferência de delegação na mainnet Ethereum
+2. Espere 20 minutos pela confirmação
+3. Confirme a transferência da delegação no Arbitrum
+
+\*\*\*\*Confirme a transferência dentro de 7 dias, ou o seu subgraph poderá ser perdido. Na maioria dos casos, este passo será executado automaticamente, mas pode ser necessário confirmar manualmente caso haja um surto no preço de gas no Arbitrum. Caso haja quaisquer dificuldades neste processo, contacte o suporte em support@thegraph.com ou no [Discord](https://discord.gg/graphprotocol).
+
+### O que acontece com as minhas recompensas se eu iniciar uma transferência com uma alocação aberta na mainnet Ethereum?
+
+Se o Indexador a qual você delega ainda está a operar no L1, ao transferir ao Arbitrum, você perderá quaisquer recompensas de delegação oriundas de alocações abertas na mainnet do Ethereum. Isto significa que perderá as recompensas do último período de 28 dias, no máximo. Se executar a transferência logo após o Indexador fechar as suas alocações, verifique se esta é a menor quantia possível. Se houver um canal de comunicação com o(s) seu(s) Indexador(es), considere discutir com eles o melhor tempo para executar a sua transferência.
+
+### O que acontece se o Indexador ao qual eu atualmente delego não estiver no Arbitrum One?
+
+A ferramenta de transferência a L2 só será ativada se o Indexador ao qual delegaste transferiu o stake dele ao Arbitrum.
+
+### Os Delegadores têm a opção de delegar a outro Indexador?
+
+Se desejar delegar a outro Indexador, dá para transferir ao mesmo Indexador no Arbitrum, para depois retirar a delegação e esperar o período de degelo. Após isto, pode selecionar outro Indexador ativo para quem delegar.
+
+### E se eu não conseguir achar o Indexador ao qual delego na L2?
+
+A ferramenta de transferência à L2 detectará automaticamente o Indexador ao qual delegou anteriormente.
+
+### Eu posso misturar ou 'dividir' a minha delegação entre novos (ou vários) Indexadores em vez do Indexador anterior?
+
+A ferramenta de transferência à L2 sempre mudará a sua delegação ao mesmo Indexador ao qual delegaste anteriormente. Após você se mudar para a L2, pode retirar a delegação, esperar o período de degelo, e decidir se quer separar a sua delegação.
+
+### Estou sujeito ao período de recarga ou posso retirar-me imediatamente após usar a ferramenta de transferência de delegação na L2?
+
+A ferramenta de transferência permite-lhe uma mudança imediata à L2. Se quiser desdelegar, espere pelo período de degelo. Porém, se um Indexador transferir todo o stake dele à L2, dá para fazer saque na mainnet Ethereum imediatamente.
+
+### As minhas recompensas podem ser prejudicadas se eu não transferir a minha delegação?
+
+Espera-se que toda a participação na rede seja transferida ao Arbitrum One no futuro.
+
+### Quanto tempo leva para completar a transferência da minha delegação à L2?
+
+Após este período, complete o terceiro passo do processo de transferência dentro de 7 dias, ou a sua delegação poderá ser perdida. Na maioria dos casos, este passo será executado automaticamente, mas pode ser necessário confirmar manualmente caso este falhe. Caso haja quaisquer dificuldades neste processo, contacte o suporte em support@thegraph.com ou no [Discord](https://discord.gg/graphprotocol).
+
+### Posso transferir a minha delegação se eu usar um contrato de vesting / carteira de bloqueio de token de GRT?
+
+Sim! O processo é um pouco diferente, já que contratos de vesting não podem repassar o ETH necessário para pagar o gas da L2, então é necessário depositá-lo primeiro. Se o seu contrato de vesting não for totalmente vestido, inicie também um contrato de vesting na L2 — assim, a delegação só poderá ser transferida a este contrato na L2. A interface no Explorer pode te guiar através deste processo após conectar ao Explorer com a carteira de bloqueio de vesting.
+
+### O meu contrato de vesting no Arbitrum permite liberar GRT da mesma forma que na mainnet?
+
+Não, o contrato de vesting criado no Arbitrum não permitirá liberar qualquer GRT até o fim da agenda de vesting, por ex., até o seu contrato for totalmente vestido. Isto serve para impedir gastos duplos, pois caso contrário, seria possível liberar as mesmas quantidades em ambas as camadas.
+
+Se quiser liberar GRT do contrato de vesting, é possível transferi-lo de volta ao contrato de vesting na L1 com o Explorer: no seu perfil no Arbitrum One, há um banner que diz que você pode transferir GRT de volta ao contrato de vesting na mainnet. Isto exige uma transação no Arbitrum One, uma espera de 7 dias, e uma transação final na mainnet, já que isto usa o mesmo mecanismo nativo de bridging da bridge de GRT.
+
+### Há alguma taxa de delegação?
+
+Não. Os tokens recebidos na L2 são delegados ao Indexador especificado, em nome do Delegador especificado, sem cobrar taxas pela delegação.
+
+### As minhas recompensas não realizadas serão transferidas quando eu transferir a minha delegação?
+
+Sim! As únicas recompensas que não podem ser transferidas são por alocações abertas, já que essas não existirão até o Indexador fechar as alocações (normalmente a cada 28 dias). Se já delega há um bom tempo, isto deve compor apenas uma pequena fração de recompensas.
+
+No nível do contrato inteligente, as recompensas não realizadas já fazem parte do seu saldo de delegação, então elas serão transferidas quando a sua delegação for transferida à L2.
+
+### É obrigatório mudar delegações para a L2? Há uma data limite?
+
+Não é obrigatório transferir delegações para a L2 — mas lá, as recompensas de indexação aumentam com base na linha do tempo descrita no [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventualmente, se o Conselho continuar a aprovar os aumentos, todas as recompensas serão distribuídas na L2 e não haverão mais recompensas de indexação para Indexadores e Delegantes na L1
+
+### Se eu delegar a um Indexador que já transferiu stake à L2, eu paro de receber recompensas na L1?
+
+Muitos Indexadores transferem stakes gradualmente para que Indexadores na L1 continuem a ganhar recompensas e taxas na L1, que então, são compartilhadas com Delegantes. Quando um Indexador tiver transferido todo o seu stake, ele parará de operar na L1, então os Delegantes não receberão mais recompensas até se transferirem à L2.
+
+Eventualmente, caso o Conselho continue a aprovar os aumentos de recompensas de indexação na L2, todas serão distribuídas na L2 e não haverão mais recompensas para Indexadores e Delegantes na L1. ​
+
+### Não vejo um botão para transferir a minha delegação. O que houve?
+
+O seu Indexador provavelmente ainda não transferiu stakes com as ferramentas de transferência para L2.
+
+Se puder contactar o Indexador, tente convencê-lo a usar as Ferramentas de Transferência para L2 para que os Delegantes possam transferir delegações ao próprio endereço de Indexador na L2
+
+### O meu Indexador também está no Arbitrum, mas eu não vejo nenhum botão para transferir a delegação no meu perfil. Porquê?
+
+O Indexador pode ter preparado operações na L2 sem ter transferido stake com as ferramentas de transferência à L2. Assim, os contratos inteligentes na L1 não saberão o endereço do Indexador na L2. Caso seja possível contatar o Indexador, convença-o a usar a ferramenta de transferência para que Delegantes possam transferir delegações ao seu endereço de Indexador na L2
+
+### Posso transferir a minha delegação à L2 caso eu tenha começado o processo de cancelamento da delegação sem tê-la sacado?
+
+Não. Se a sua delegação estiver em degelo, espere os 28 dias para sacá-la.
+
+Os tokens a serem desdelegados estão "trancados", e assim, não podem ser transferidos à L2.
+
+## Sinal de Curadoria
+
+### Como transfiro a minha curadoria?
+
+Para transferir a sua curadoria, complete os seguintes passos:
+
+1. Inicie a transferência de sinal na mainnet Ethereum
+
+2. Especifique um endereço de Curador na L2\*
+
+3. Espere 20 minutos pela confirmação
+
+\*Se necessário - por ex. se você usar um endereço de contrato.
+
+### Como saberei se o subgraph que eu curei foi transferido para a L2?
+
+Ao visualizar a página de detalhes do subgraph, um banner notificará-lhe que este subgraph foi transferido. Siga o prompt para transferir a sua curadoria. Esta informação também aparece na página de detalhes de qualquer subgraph transferido.
+
+### E se eu não quiser mudar a minha curadoria para a L2?
+
+Quando um subgraph é depreciado, há a opção de retirar o seu sinal. Desta forma, se um subgraph for movido à L2, dá para escolher retirar o seu sinal na mainnet Ethereum ou enviar o sinal à L2.
+
+### Como sei se a minha curadoria foi transferida com êxito?
+
+Os detalhes do sinal serão acessíveis através do Explorer cerca de 20 minutos após a ativação da ferramenta de transferência à L2.
+
+### Posso transferir a minha curadoria em vários subgraphs de uma vez?
+
+Não há opção de transferências em conjunto no momento.
+
+## Stake de Indexador
+
+### Como transfiro o meu stake ao Arbitrum?
+
+> Aviso: Caso esteja atualmente a desfazer o stake em qualquer porção do seu GRT no seu Indexador, não haverá como usar as Ferramentas de Transferência à L2.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+Para transferir o seu stake, complete os seguintes passos:
+
+1. Inicie a transferência de stake na mainnet Ethereum
+
+2. Espere 20 minutos pela confirmação
+
+3. Confirme a transferência do stake no Arbitrum
+
+\*Confirme a transferência dentro de 7 dias, ou o seu stake poderá ser perdido. Na maioria dos casos, este passo será executado automaticamente, mas pode ser necessário confirmar manualmente se houver um aumento repentino no preço de gas no Arbitrum. Caso haja quaisquer dificuldades neste processo, contacte o suporte em support@thegraph.com ou no [Discord](https://discord.gg/graphprotocol).
+
+### Todo o meu stake será transferido?
+
+Você pode escolher quanto quer transferir do seu stake. Se escolher transferir todo o seu stake de uma vez, feche quaisquer alocações abertas primeiro.
+
+Se deseja transferir partes do seu stake através de múltiplas transações, sempre especifique o mesmo endereço beneficiário.
+
+Nota: Você deve atender aos requerimentos mínimos de stake na L2 ao usar a ferramenta de transferência pela primeira vez. Os Indexadores devem enviar o mínimo de 100.000 GRT (ao chamar esta função pela primeira vez.). Se uma porção do stake for deixada na L1, ela deve ser maior que o mínimo de 100 mil e ser suficiente (junto com as suas delegações) para cobrir as suas alocações abertas.
+
+### Quanto tempo eu tenho para confirmar a minha transferência de stake ao Arbitrum?
+
+\*\*\* A sua transação deve ser confirmada para completar a transferência de stake no Arbitrum. Confirme a transferência dentro de 7 dias, ou o seu stake poderá ser perdido.
+
+### E se eu tiver alocações abertas?
+
+Caso não envie todo o seu stake, a ferramenta de transferência para L2 validará que o mínimo de 100 mil GRT permaneça na mainnet do Ethereum, e que o seu stake e delegação restantes sejam o suficiente para cobrir quaisquer alocações abertas. Você pode precisar fechar alocações abertas se o seu saldo de GRT não cobrir os mínimos + alocações abertas.
+
+### Com as ferramentas de transferência, devo esperar 28 dias para retirar um stake na mainnet Ethereum antes da transferência?
+
+Não. Dá para transferir o seu stake à L2 imediatamente. Não há necessidade de retirar um stake e esperar antes de usar a ferramenta de transferência. A espera de 28 dias só vale se quiser sacar o stake de volta à sua carteira, na mainnet Ethereum ou na L2.
+
+### Quanto tempo demora para trandferir o meu stake?
+
+A ferramenta de transferência à L2 finalizará a transferência do seu stake em aproximadamente 20 minutos.
+
+### Devo indexar no Arbitrum antes de transferir o meu stake?
+
+Você pode transferir o seu stake antes de preparar a indexação, mas não terá como resgatar recompensas na L2 até alocar para subgraphs na L2, indexá-los, e apresentar POIs.
+
+### Os Delegadores podem mudar a sua delegação antes que eu mude o meu stake de indexação?
+
+Não. Para que os Delegadores transfiram os GRT que delegaram ao Arbitrum, o Indexador a quem eles delegam devem estar ativos na L2.
+
+### Posso transferir o meu stake se eu usar um contrato de vesting / carteira de bloqueio de token de GRT?
+
+Sim! O processo é um pouco diferente, já que contratos de vesting não podem repassar o ETH necessário para pagar o gas da L2, então ele deve ser depositado primeiro. Se o seu contrato de vesting não for totalmente vestido, inicie também um contrato de vesting na L2; o stake só poderá ser transferido a este mesmo contrato. A interface no Explorer pode te guiar através deste processo quando estiver conectado ao Explorer com a carteira de bloqueio de vesting.
+
+### Já tenho stake na L2. Ainda devo enviar 100 mil GRT no primeiro uso das ferramentas de transferência?
+
+Sim. Os contratos inteligentes na L1 não terão conhecimento do seu stake na L2, então será necessário transferir no mínimo 100.000 GRT na sua primeira transferência
+
+### Posso transferir o meu stake à L2 enquanto retirar o stake do meu GRT?
+
+Não. Se qualquer fração do seu stake estiver em degelo, espere os 28 dias e a saque antes de poder transferir o seu stake. Os tokens a serem postos em stake são "trancados" e impedirão quaisquer transferências ou stake na L2.
+
+## Transferência de Contrato de Vesting
+
+### Como transfiro o meu contrato de vesting?
+
+Para transferir o seu vesting, complete os seguintes passos:
+
+1. Inicie a transferência de vesting na mainnet Ethereum
+
+2. Espere 20 minutos pela confirmação
+
+3. Confirme a transferência do vesting no Arbitrum
+
+### Como transfiro o meu contrato de vesting se estiver vestido apenas parcialmente?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Deposite ETH no contrato da ferramenta de transferência (a interface pode ajudar a estimar uma quantia razoável)
+
+2. Envie um pouco de GRT através do contrato da ferramenta de transferência, para que a L2 inicialize o contrato de vesting na L2. Isto também configurará o endereço beneficiário na L2.
+
+3. Envie o seu stake/a sua delegação à L2 através das funções "bloqueadas" da ferramenta de transferência no contrato de staking na L1.
+
+4. Saque qualquer quantia restante de ETH do contrato da ferramenta de transferência
+
+### Como transfiro o meu contrato de vesting, se eu estiver totalmente vestido?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+Para quem estiver totalmente vestido, o processo não é muito diferente:
+
+1. Deposite ETH no contrato da ferramenta de transferência (a interface pode ajudar a estimar uma quantia razoável)
+
+2. Determine o seu endereço na L2 com uma chamada ao contrato da ferramenta de transferência
+
+3. Envie o seu stake/a sua delegação à L2 através das funções "bloqueadas" da ferramenta de transferência no contrato de staking na L1.
+
+4. Saque qualquer quantia restante de ETH do contrato da ferramenta de transferência
+
+### Posso transferir o meu contrato de vesting ao Arbitrum?
+
+Você pode transferir o saldo de GRT do seu contrato de vesting a um contrato na L2. Isto é necessário para transferir stake ou delegações do seu contrato de vesting à L2. O contrato deve ter um saldo de GRT acima de zero (é possível transferir uma quantia pequena, como 1 GRT, se precisar).
+
+Ao transferir GRT do seu contrato de vesting na L1 à L2, dá para escolher a quantia a ser enviada e repetir quantas vezes quiser. O contrato de vesting na L2 será inicializado na sua primeira transferência de GRT.
+
+As transferências são feitas com uma Ferramenta de Transferência, que aparecerá no seu perfil do Explorer ao conectar com a conta do contrato de vesting.
+
+Por favor, lembre que você não poderá liberar ou sacar GRT do contrato de vesting na L2 até o fim da sua agenda de vesting, quando o seu contrato estiver totalmente vestido. Se precisar liberar GRT até então, dá para devolver o GRT ao contrato de vesting na L1, com outra ferramenta de transferência especializada.
+
+Se não tiver transferido qualquer saldo de contrato de vesting à L2, e o seu contrato de vesting estiver totalmente vestido, não transfira o seu contrato de vesting à L2. Em vez disto, use as ferramentas de transferência para firmar um endereço de carteira na L2, e transfira diretamente o seu stake/delegação a esta carteira regular na L2.
+
+### Estou a usar o meu contrato de vesting para fazer stake na mainnet. Posso transferir o meu stake ao Arbitrum?
+
+Sim, mas se o seu contrato ainda estiver vestindo, você só pode transferir o stake para que ele esteja em posse do seu contrato de vesting na L2. Primeiro, inicie este contrato na L2 com a transferência de um saldo de GRT, com uma ferramenta de transferência de contrato de vesting no Explorer. Se o seu contrato estiver totalmente vestido, transfira o seu stake a qualquer endereço na L2 após configurá-lo previamente e deposite ETH para que a ferramenta de transferência pague o gás na L2.
+
+### Estou a usar o meu contrato de vesting para delegar na mainnet. Posso transferir as minhas delegações ao Arbitrum?
+
+Sim, mas se o seu contrato ainda estiver no processo de vesting, você só pode transferir a delegação para que ela fique em posse do seu contrato de vesting na L2. Você deve primeiro inicializar este contrato na L2 com a transferência de um saldo de GRT com o uso de uma ferramenta especializada no Explorer. Se o seu contrato estiver totalmente vestido, você pode transferir a sua delegação a qualquer endereço na L2, mas deve configurá-lo previamente e depositar ETH para que a ferramenta pague o gás na L2.
+
+### Posso especificar um beneficiário diferente para o meu contrato de vesting na L2?
+
+Sim. Na primeira vez que transferir um saldo e preparar o seu contrato de vesting na L2, dá para especificar um beneficiário na L2. Veja se este beneficiário tem uma carteira que possa realizar transações no Arbitrum One, por ex. uma EOA ou uma multisig lançada ao Arbitrum One.
+
+Se o seu contrato estiver totalmente vestido, não será preparado um contrato de vesting na L2; em vez disto, será configurado um endereço de carteira na L2. Esta será a carteira destinatária para o seu stake ou a sua delegação no Arbitrum.
+
+### O meu contrato está totalmente vestido. Posso transferir o meu stake ou a minha delegação para outro endereço que não seja um contrato de vesting na L2?
+
+Sim. Se não tiver transferido qualquer saldo de contrato de vesting à L2, e o seu contrato estiver totalmente vestido, não transfira o seu contrato à L2. Em vez disto, use as ferramentas de transferência para determinar um endereço de carteira na L2 e transfira diretamente o seu stake/delegação a esta carteira regular na L2.
+
+Isto permite-lhe transferir o seu stake ou a sua delegação para qualquer endereço na L2.
+
+### O meu contrato de vesting ainda está no processo de vesting. Como transfiro o saldo do meu contrato à L2?
+
+Estes passos só se aplicam se o seu contrato ainda estiver em processo de vesting, ou se já usou este processo quando seu contrato ainda estava com vesting em andamento.
+
+Para transferir o seu contrato de vesting à L2, envie qualquer saldo de GRT à L2 com as ferramentas de transferência. Isto iniciará o seu contrato de vesting na L2:
+
+1. Deposite ETH no contrato da ferramenta de transferência (isto será usado para pagar gás na L2)
+
+2. Revogue o acesso protocolar ao contrato de vesting (necessário para o próximo passo)
+
+3. Conceda acesso protocolar ao contrato de vesting (isto permitirá que o seu contrato interaja com a ferramenta de transferência)
+
+4. Especifique um endereço beneficiário na L2\* e inicie a transferência do saldo na mainnet Ethereum
+
+5. Espere 20 minutos pela confirmação
+
+6. Confirme a transferência do saldo na L2
+
+\*Se necessário - por ex. se você usar um endereço de contrato.
+
+\*\*\*\*Confirme a sua transação para finalizar a transferência do saldo no Arbitrum. Este passo deve ser completado dentro de 7 dias, ou o saldo será perdido. Na maioria dos casos, este passo será executado automaticamente, mas pode ser necessário confirmar manualmente se houver um aumento repentino no preço de gas no Arbitrum. Caso haja quaisquer dificuldades neste processo, contacte o suporte em support@thegraph.com ou no [Discord](https://discord.gg/graphprotocol).
+
+### O meu contrato de vesting mostra 0 GRT, assim, não posso transferi-lo. Porquê? O que fazer?
+
+Para inicializar o seu contrato de vesting na L2, transfira uma quantia de GRT maior que zero à L2. Isto é exigido pelo bridge de GRT no Arbitrum em uso pelas Ferramentas de Transferência na L2. O GRT deve originar do saldo do contrato, e não deve incluir GRT delegado ou em stake.
+
+Se tiver delegado ou posto em stake todo o seu GRT do contrato de vesting, é possível enviar manualmente uma pequena quantia, como 1 GRT, ao endereço do contrato de vesting a partir de qualquer outro lugar (por ex., de outra carteira, ou de uma corretora)
+
+### Estou a usar um contrato de vesting para fazer stake ou delegar, mas não vejo um botão para transferir o meu stake ou a minha delegação à L2. O que fazer?
+
+Caso o seu contrato de vesting não esteja concluído, crie logo um contrato de vesting na L2 que receba o seu stake ou a sua delegação na L2. Este contrato não permitirá o lançamento de tokens na L2 até o fim da agenda de vesting, mas lhe permitirá transferir GRT de volta ao contrato na L2 para lá ser lançado.
+
+Ao se conectar com o contrato de vesting no Explorer, procure um botão para inicializar o seu contrato de vesting na L2. Siga esse processo primeiro, e então verás os botões para transferir o seu stake ou a sua delegação no seu perfil
+
+### Caso eu inicialize o meu contrato de vesting na L2, isto também transferirá a minha delegação à L2 automaticamente?
+
+Não. Inicializar o seu contrato de vesting na L2 é necessário para a transferência de stakes ou delegações do contrato, mas estes ainda devem ser transferidos separadamente.
+
+Surgirá um banner no seu perfil que lhe pedirá para transferir o seu stake ou a sua delegação após ter inicializado o seu contrato de vesting na L2.
+
+### Posso devolver o meu contrato de vesting à L1?
+
+Não há necessidade, pois o seu contrato de vesting ainda está na L1. Ao usar as ferramentas de transferência, basta criar um contrato na L2 conectado com o seu contrato na L1; assim, poderá enviar GRT entre os dois.
+
+### Por que tenho que mudar o local do meu contrato de vesting?
+
+É necessário configurar um contrato de vesting na L2 para que esta conta tenha o seu stake ou delegação na L2. Senão, não haveria como transferir o seu stake/delegação à L2 sem "escapar" do contrato de vesting.
+
+### O que acontece se eu tentar sacar o meu contrato quando estiver parcialmente vestido? Isto é possível?
+
+Isto não é possível. Você pode devolver fundos para a L1 e sacá-los de lá.
+
+### E se eu não quiser mudar o meu contrato de vesting para a L2?
+
+Você pode continuar a fazer stake/delegar na L1. Pouco a pouco, considere mudar-se à L2 para ativar recompensas lá, sendo que o protocolo escala no Arbitrum. Perceba que estas ferramentas de transferência são para contratos de vesting que podem fazer stake e delegar no protocolo. Se o seu contrato não permite staking ou delegação, ou é revogável, então não haverá ferramentas de transferência disponíveis. Você ainda poderá sacar o seu GRT da L1 quando disponível.

From 73ca66c8ac6c0a67a9768c63f549b28fff4d1455 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:53 -0500
Subject: [PATCH 1034/3820] New translations l2-transfer-tools-faq.mdx
 (Russian)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/ru/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/ru/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/ru/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..892a7c3e8253
--- /dev/null
+++ b/website/pages/ru/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: FAQ по инструментам переноса L2
+---
+
+## Общая информация
+
+### Что такое инструменты переноса L2?
+
+The Graph удешевил участие контрибьюторов в сети в 26 раз, развернув протокол в Arbitrum One. Инструменты переноса L2 были созданы разработчиками ядра, чтобы упростить переход на L2.
+
+Для каждого участника сети доступен набор инструментов L2 Transfer Tools, позволяющих сделать переход на L2 беспрепятственным, избежать периодов оттаивания или необходимости вручную выводить и переносить GRT.
+
+Эти инструменты потребуют от Вас выполнения определенного набора шагов в зависимости от Вашей роли в The Graph и того, что Вы переносите на L2.
+
+### Могу ли я использовать тот же кошелек, что и в основной сети Ethereum?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Кошельки на блокчейнах EVM, таких как Ethereum и Arbitrum, представляют собой пару ключей (публичный и приватный), которые Вы создаете без необходимости взаимодействия с блокчейном. Таким образом, любой кошелек, созданный для Ethereum, также будет работать на Arbitrum без необходимости выполнения дополнительных действий.
+
+Исключение касается умных контрактных кошельков, таких как мультисигнатурные: это умные контракты, которые развертываются отдельно на каждом блокчейне и получают свой адрес при развертывании. Если мультисигнатурный кошелек был развернут на Ethereum, то он не будет существовать с тем же адресом на Arbitrum. Новый мультисигнатурный кошелек должен быть создан сначала на Arbitrum, и его адрес может быть другим.
+
+### Что произойдет, если я не завершу перенос в течение 7 дней?
+
+Инструменты переноса L2 используют встроенный механизм Arbitrum для передачи сообщений с L1 на L2. Этот механизм называется "retryable ticket", или "повторный тикет", и используется всеми собственными токен-мостами, включая мост Arbitrum GRT. Подробнее о повторном тикете можно прочитать в [Arbitrum docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+Когда Вы переносите свои активы (субграф, стейк, делегирование или курирование) на L2, через мост Arbitrum GRT отправляется сообщение, которое создает повторный тикет на L2. Инструмент переноса включает в транзакцию некоторую стоимость ETH, которая используется для 1) оплаты создания тикета и 2) оплаты стоимости газа для выполнения тикета на L2. Однако, поскольку стоимость газа может измениться за время, пока тикет будет готов к исполнению на L2, возможна ситуация, когда попытка автоматического исполнения не удастся. В этом случае мост Arbitrum сохранит повторный тикет в течение 7 дней, и любой желающий может повторить попытку "погасить" тикет (для этого необходимо иметь кошелек с некоторым количеством ETH, подключенный к мосту Arbitrum).
+
+Это так называемый шаг "Подтверждение" во всех инструментах переноса - в большинстве случаев он выполняется автоматически, поскольку автоисполнение чаще всего бывает успешным, но важно, чтобы Вы проверили, прошел ли он. Если он не исполнился и в течение 7 дней не будет повторных успешных попыток, мост Arbitrum отменит тикет, и Ваши активы (субграф, стейк, делегирование или курирование) будут потеряны и не смогут быть восстановлены. У разработчиков ядра The Graph есть система мониторинга, позволяющая выявлять такие ситуации и пытаться погасить тикеты, пока не стало слишком поздно, но в конечном итоге ответственность за своевременное завершение переноса лежит на Вас. Если у Вас возникли проблемы с подтверждением переноса, пожалуйста, свяжитесь с нами через [эту форму] (https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms), и разработчики ядра помогут Вам.
+
+### Я начал передачу делегирования/стейка/курирования и не уверен, что она дошла до уровня L2. Как я могу убедиться, что она была передана правильно?
+
+Если Вы не видите в своем профиле баннер с просьбой завершить передачу, то, скорее всего, транзакция благополучно достигла уровня L2 и никаких дополнительных действий не требуется. Если у Вас есть сомнения, Вы можете проверить, показывает ли Explorer Ваше делегирование, ставку или курирование на Arbitrum One.
+
+Если у Вас есть хеш транзакции L1 (который Вы можете найти, просмотрев недавние транзакции в своем кошельке), Вы также можете подтвердить, был ли погашен «повторный тикет», который перенес сообщение на L2, здесь: https://retryable-dashboard.arbitum.io/ — если автопогашение не удалось, Вы также можете подключить туда свой кошелек и погасить его. Будьте уверены, что разработчики ядра также отслеживают застрявшие сообщения и попытаются активировать их до истечения срока их действия.
+
+## Перенос субграфа
+
+### Как мне перенести свой субграф?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+Чтобы перенести Ваш субграф, необходимо выполнить следующие действия:
+
+1. Инициировать перенос в основной сети Ethereum
+
+2. Подождать 20 минут для получения подтверждения
+
+3. Подтвердить перенос субграфа в Arbitrum\*
+
+4. Завершить публикацию субграфа в Arbitrum
+
+5. Обновить URL-адрес запроса (рекомендуется)
+
+\* Обратите внимание, что Вы должны подтвердить перенос в течение 7 дней, иначе Ваш субграф может быть потерян. В большинстве случаев этот шаг выполнится автоматически, но в случае скачка стоимости комиссии сети в Arbitrum может потребоваться ручное подтверждение. Если в ходе этого процесса возникнут какие-либо проблемы, Вам помогут: обратитесь в службу поддержки по адресу support@thegraph.com или в [Discord](https://discord.gg/graphprotocol).
+
+### С чего необходимо начать перенос?
+
+Вы можете начать перенос со страницы [Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) или любой другой страницы с информацией о субграфе. Для начала переноса нажмите кнопку "Перенести субграф" на странице сведений о субграфе.
+
+### Как долго мне необходимо ждать, пока мой субграф будет перенесен
+
+Время переноса занимает около 20 минут. Мост Arbitrum работает в фоновом режиме, чтобы автоматически завершить перенос через мост. В некоторых случаях стоимость комиссии сети может повыситься, и Вам потребуется повторно подтвердить транзакцию.
+
+### Будет ли мой субграф по-прежнему доступен для поиска после того, как я перенесу его на L2?
+
+Ваш субграф можно будет найти только в той сети, в которой он опубликован. Например, если Ваш субграф находится в сети Arbitrum One, то Вы сможете найти его в Explorer только в сети Arbitrum One, и не сможете найти в сети Ethereum. Обратите внимание, что в переключателе сетей в верхней части страницы выбран Arbitrum One, чтобы убедиться, что Вы находитесь в правильной сети. После переноса субграф L1 будет отображаться как устаревший.
+
+### Должен ли мой субграф быть опубликован, чтобы его можно было перенести?
+
+Чтобы воспользоваться инструментом переноса субграфа, Ваш субграф должен быть уже опубликован в основной сети Ethereum и иметь какой-либо сигнал курирования, принадлежащий кошельку, которому принадлежит субграф. Если Ваш субграф не опубликован, рекомендуется просто опубликовать его непосредственно на Arbitrum One - связанная с этим стоимость комиссии сети будет значительно ниже. Если Вы хотите перенести опубликованный субграф, но на счете владельца нет сигнала курирования, Вы можете подать сигнал на небольшую сумму (например, 1 GRT) с этого счета; при этом обязательно выберите сигнал "автомиграция".
+
+### Что произойдет с версией моего субграфа в основной сети Ethereum после его переноса на Arbitrum?
+
+После переноса Вашего субграфа на Arbitrum версия, находящаяся на основной сети Ethereum станет устаревшей. Мы рекомендуем Вам обновить URL-адрес запроса в течение 48 часов. Однако существует отсрочка, в течение которой Ваш URL-адрес на основной сети будет функционировать, чтобы можно было обновить стороннюю поддержку децентрализованных приложений.
+
+### Нужно ли мне после переноса повторно опубликовываться на Arbitrum?
+
+По истечении 20-минутного окна переноса необходимо подтвердить перенос транзакцией в пользовательском интерфейсе, чтобы завершить перенос, а инструмент переноса подскажет Вам, как это сделать. Ваша конечная точка L1 будет продолжать поддерживаться во время окна переноса и в течение периода отсрочки после него. Рекомендуется обновить свою конечную точку в удобное для Вас время.
+
+### Будет ли моя конечная точка простаивать при повторной публикации?
+
+Это маловероятно, но возможно возникновение кратковременного простоя в зависимости от того, какие индексаторы поддерживают субграф на уровне L1 и продолжают ли они индексировать его до тех пор, пока субграф не будет полностью поддерживаться на уровне L2.
+
+### Публикация и версионность на L2 такие же, как и в основной сети Ethereum?
+
+Да. При публикации в Subgraph Studio выберите Arbitrum One в качестве публикуемой сети. В Studio будет доступна последняя конечная точка, которая указывает на последнюю обновленную версию субграфа.
+
+### Будет ли курирование моего субграфа перемещено вместе с моим субграфом?
+
+Если Вы выбрали автомиграцию сигнала, то 100% Вашего собственного кураторства переместится вместе с Вашим субграфом на Arbitrum One. Весь сигнал курирования субграфа будет преобразован в GRT в момент переноса, а GRT, соответствующий Вашему сигналу курирования, будет использован для обработки сигнала на субграфе L2.
+
+Другие кураторы могут выбрать, снять ли им свою долю GRT, или также перевести ее в L2 для обработки сигнала на том же субграфе.
+
+### Могу ли я переместить свой субграф обратно в основную сеть Ethereum после переноса?
+
+После переноса Ваша версия данного субграфа в основной сети Ethereum станет устаревшей. Если Вы захотите вернуться в основную сеть, Вам нужно будет переразвернуть и снова опубликовать субграф в основной сети. Однако перенос обратно в основную сеть Ethereum настоятельно не рекомендуется, так как вознаграждения за индексирование в конечном итоге будут полностью распределяться на Arbitrum One.
+
+### Зачем мне необходимо использовать мост ETH для завершения переноса?
+
+Стоимость комиссии сети в Arbitrum One осуществляется при использовании моста для ETH (т.е. ETH, который был перемещен через мост в Arbitrum One). Однако по сравнению с основной сетью Ethereum стоимость комиссии сети Arbitrum One значительно ниже.
+
+## Делегирование
+
+### Как перенести мое делегирование?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+Для переноса делегирования необходимо выполнить следующие действия:
+
+1. Инициировать перенос делегирования в основной сети Ethereum
+2. Подождать 20 минут для получения подтверждения
+3. Подтвердить перенос делегирования на Arbitrum
+
+\*\*\*\*Для завершения передачи делегирования на Arbitrum необходимо подтвердить транзакцию. Этот шаг должен быть выполнен в течение 7 дней, иначе делегирование может быть потеряно. В большинстве случаев этот этап выполняется автоматически, однако в случае скачка цен на комиссию сети в Arbitrum может потребоваться ручное подтверждение. Если в ходе этого процесса возникнут какие-либо проблемы, Вам будет оказана помощь: обращайтесь в службу поддержки по адресу support@thegraph.com или в [Discord](https://discord.gg/graphprotocol).
+
+### Что произойдет с моими вознаграждениями, если я инициирую перенос с открытым распределением в основной сети Ethereum?
+
+Если индексатор, которому Вы делегируете полномочия, все еще работает на L1, то при переносе на Arbitrum Вы потеряете все вознаграждения за делегирование от открытых распределений в основной сети Ethereum. Это означает, что Вы потеряете вознаграждение максимум за последний 28-дневный период. Если Вы планируете осуществить перенос сразу после того, как индексатор закроет распределение, Вы можете быть уверены, что это произойдет с минимальными затратами. Если у Вас есть канал связи с индексатором (индексаторами), обсудите с ними оптимальное время для переноса.
+
+### Что произойдет, если индексатора, которому я в данный момент делегирую, нет на Arbitrum One?
+
+Инструмент переноса L2 будет запущен только в том случае, если индексатор, которому Вы делегируете, перенёс свой стейк на Arbitrum.
+
+### Есть ли у делегаторов возможность делегировать другому индексатору?
+
+Если Вы хотите делегировать другому индексатору, Вы можете перевестись к тому же индексатору на Arbitrum, затем отменить делегирование, и дождаться разблокировки. После этого можно выбрать другого активного индексатора для делегирования.
+
+### Что делать, если я не могу найти индексатора, которому я делегирую, на L2?
+
+Инструмент переноса L2 автоматически обнаружит индексатора, которому Вы ранее делегировали.
+
+### Смогу ли я смешивать или "распределять" свое делегирование новому или нескольким индексаторам вместо предыдущего индексатора?
+
+Инструмент переноса L2 всегда будет перемещать делегацию на тот же индексатор, на который она была делегирована ранее. После перемещения на L2 можно отменить делегирование, дождаться разблокировки и принять решение о разделении своей делегации.
+
+### Попадаю ли я в период ограничения или могу сразу же вывести средства после использования инструмента передачи делегирования L2?
+
+Инструмент переноса позволяет немедленно перейти на L2. Если Вы хотите отменить перенос, Вам придется дождаться периода разблокировки. Однако если индексатор перевел весь свой стейк на L2, то можно сразу же вывести средства на основную сеть Ethereum.
+
+### Могут ли мои вознаграждения пострадать, если я не перенесу свою делегацию?
+
+Предполагается, что в будущем все сетевые участники перейдут в Arbitrum One.
+
+### Сколько времени требуется для завершения переноса моей делегации на L2?
+
+Для переноса делегации требуется 20-минутное подтверждение. Обратите внимание, что по истечении 20-минутного периода Вы должны вернуться и завершить 3-й шаг процесса передачи в течение 7 дней. Если этого не сделать, то делегация может быть потеряна. Обратите внимание, что в большинстве случаев инструмент передачи выполнит этот шаг автоматически. В случае неудачной автопопытки Вам придется выполнить его вручную. Если в ходе этого процесса возникнут какие-либо проблемы, не волнуйтесь, мы всегда готовы помочь: обращайтесь к нам по адресу support@thegraph.com или в [Discord](https://discord.gg/graphprotocol).
+
+### Могу ли я перевести свою делегацию, если я использую вестинговый контракт GRT / кошелек с блокировкой токенов?
+
+Да! Процесс немного отличается, поскольку вестинговые контракты не могут пересылать ETH, необходимые для оплаты стоимости комиссии сети на L2, поэтому их необходимо пополнить заранее. Если Ваш вестинговый контракт не полностью вестирован, Вам также придется сначала инициализировать аналогичный вестинговый контракт на L2, и Вы сможете перевести стейк только на этот вестинговый контракт на L2. Пользовательский интерфейс Explorer может подсказать Вам этот процесс, если Вы подключились к Explorer с помощью вестингового закрытого кошелька.
+
+### Позволяет ли мой договор о передаче прав Arbitrum выпускать GRT так же, как в основной сети?
+
+Нет, контракт ограничения выпуска токенов, который создается на Arbitrum, не позволит освободить какие-либо GRT до завершения срока ограничения выпуска, то есть до полного завершения ограничения выпуска Вашего контракта. Это сделано для предотвращения двойных трат, так как в противном случае было бы возможно освободить те же самые суммы на обеих сетях.
+
+Если Вы хотите освободить GRT из контракта ограничения выпуска, Вы можете перевести их обратно в контракт ограничения выпуска L1, используя Explorer: в своем профиле Arbitrum One Вы увидите баннер, сообщающий, что Вы можете перевести GRT обратно в основной контракт ограничения выпуска. Для этого требуется транзакция на Arbitrum One, ожидание 7 дней и завершающая транзакция на основной сети, так как он использует тот же самый механизм моста GRT.
+
+### Существует ли комиссия за делегацию?
+
+Нет. Полученные токены на L2 делегируются указанному индексатору от имени указанного делегатора без взимания пошлины за делегирование.
+
+### Будут ли перенесены мои нереализованные реварды при передаче моей делегации?
+
+Да! Единственные вознаграждения (реварды), которые нельзя передать, — это те, которые предназначены для открытых аллокаций, поскольку они не существуют до тех пор, пока индексатор не закроет аллокации (обычно каждые 28 дней). Если Вы делегировали свои средства на протяжении некоторого времени, это, скорее всего, лишь небольшая часть вознаграждений.
+
+На уровне смарт-контракта нереализованные вознаграждения уже являются частью баланса Вашего делегирования, поэтому они будут перенесены, когда Вы перенесете делегирование на уровень L2.
+
+### Обязателен ли перенос делегирования на уровень L2? Есть ли крайний срок?
+
+Перенос делегирования на уровень L2 не является обязательным, но вознаграждение за индексирование увеличивается на уровне L2 в соответствии с графиком, описанным в [GIP-0052] (https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). В конечном итоге, если Совет продолжит одобрять увеличение, все вознаграждения будут распределены на уровне L2, и индексаторы и делегаторы не будут получать вознаграждения за индексацию на уровне L1.
+
+### Если я передам полномочия индексатору, который уже перевел ставку на уровень L2, перестану ли я получать вознаграждения на уровне L1?
+
+Многие индексаторы переносят ставки постепенно, поэтому индексаторы на уровне L1 по-прежнему будут получать вознаграждения и комиссии на уровне L1, которые затем распределяются между делегаторами. Как только индексатор перенесет всю свою ставку, он прекратит работу на уровне L1, а делегаторы больше не будут получать вознаграждения, если не перейдут на уровень L2.
+
+В конечном итоге, если Совет продолжит утверждать увеличение вознаграждений за индексацию на уровне L2, все вознаграждения будут распределяться на уровне L2, а индексаторы и делегаторы на уровне L1 перестанут получать вознаграждения за индексацию.
+
+### Я не вижу кнопки для передачи моей делегации. Почему?
+
+Вероятно, Ваш индексатор еще не использовал инструменты передачи ставки на уровень L2.
+
+Если Вы можете связаться с индексатором, Вы можете предложить ему использовать Transfer Tools для L2, чтобы делегаторы могли передавать делегирования на адрес своего индексатора на уровне L2.
+
+### Мой индексатор есть на Arbitrum, но я не вижу в своем профиле кнопки передачи делегирования. Почему?
+
+​Возможно, индексатор настроил операции на уровне L2, но не использовал инструменты передачи L2 для передачи ставки. Следовательно, смарт-контракты уровня L1 не будут знать об адресе индексатора на уровне L2. Если Вы можете связаться с индексатором, Вы можете предложить ему использовать инструмент передачи, чтобы делегаторы могли передавать делегирование на адрес своего индексатора на уровне L2.
+
+### Могу ли я передать свое делегирование на уровень L2, если я начал процесс отмены делегирования и еще не отозвал его?
+
+Нет. Если Ваше делегирование находится в стадии разморозки, Вам придется подождать 28 дней и затем отозвать его.
+
+Токены, которые не делегируются, «заблокированы» и, следовательно, не могут быть переданы на уровень L2.
+
+## Сигнал курирования
+
+### Как мне перенести свое курирование?
+
+Для переноса своего курирования необходимо выполнить следующие действия:
+
+1. Инициировать перенос сигнала в основной сети Ethereum
+
+2. Указать L2 адрес куратора\*
+
+3. Подождать 20 минут для получения подтверждения
+
+\*При необходимости - т.е. если Вы используете контрактный адрес.
+
+### Как я узнаю, что курируемый мною субграф перешел в L2?
+
+При просмотре страницы сведений о субграфе появится баннер, уведомляющий о том, что данный субграф был перенесен. Вы можете следовать подсказке, чтобы перенести свое курирование. Эту информацию можно также найти на странице сведений о субграфе любого перемещенного субграфа.
+
+### Что делать, если я не хочу переносить свое курирование в L2?
+
+Когда субграф устаревает, у Вас есть возможность отозвать свой сигнал. Аналогично, если субграф переместился в L2, Вы можете выбрать, отозвать свой сигнал из основной сети Ethereum или отправить его в L2.
+
+### Как я узнаю, что мое курирование успешно перенесено?
+
+Информация о сигнале будет доступна через Explorer примерно через 20 минут после запуска инструмента переноса L2.
+
+### Можно ли перенести курирование на несколько субграфов одновременно?
+
+В настоящее время опция массового переноса отсутствует.
+
+## Стейк индексатора
+
+### Как мне перенести свой стейк в Arbitrum?
+
+> Отказ от ответственности: если Вы в настоящее время выводите из стейкинга какую-либо часть своего GRT на своем индексаторе, Вы не сможете использовать инструменты передачи L2.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+Чтобы передать свою ставку, Вам необходимо выполнить следующие шаги:
+
+1. Инициировать передачу ставок в сети Ethereum
+
+2. Подождать 20 минут для получения подтверждения
+
+3. Подтвердить передачу ставки на Arbitrum
+
+\*Обратите внимание, что Вы должны подтвердить перевод в течение 7 дней, в противном случае Ваша ставка может быть потеряна. В большинстве случаев этот шаг выполняется автоматически, но может потребоваться подтверждение вручную, если на Arbitrum произойдет скачок цен стоимости комиссии сети. Если во время этого процесса возникнут какие-либо проблемы, Вам помогут ресурсы: обратитесь в службу поддержки по адресу support@thegraph.com или в [Discord](https://discord.gg/graphprotocol).
+
+### Вся ли моя ставка будет отправлена?
+
+Вы можете выбрать, какую часть своей ставки перевести. Если Вы решите перевести всю свою ставку сразу, вам необходимо сначала закрыть все открытые распределения.
+
+Если Вы планируете передавать части своей доли в рамках нескольких транзакций, вы всегда должны указывать один и тот же адрес бенефициара.
+
+Примечание. При первом использовании инструмента перевода Вы должны соответствовать требованиям к минимальной ставке на L2. Индексаторы должны отправить минимум 100 000 GRT (при первом вызове этой функции). Если вы оставляете часть ставки на L1, она также должна превышать минимум 100 000 GRT и быть достаточной (вместе с вашими делегированиями) для покрытия Ваших открытых распределений.
+
+### Сколько времени мне нужно, чтобы подтвердить перевод своей ставки в Arbitrum?
+
+\*\*\* Вам необходимо подтвердить транзакцию, чтобы завершить перевод ставки на Arbitrum. Этот шаг необходимо выполнить в течение 7 дней, иначе ставка может быть потеряна.
+
+### Что делать, если у меня есть открытые распределения?
+
+Если Вы не отправляете всю свою ставку, инструмент передачи L2 проверит, что в основной сети Ethereum остается как минимум 100 000 GRT, а вашей оставшейся ставки и делегирования достаточно для покрытия любых открытых распределений. Возможно, Вам придется закрыть открытые распределения, если ваш баланс GRT не покрывает минимальные суммы + открытые распределения.
+
+### При использовании инструментов переноса нужно ли ждать 28 дней для разблокировки в основной сети Ethereum перед переносом?
+
+Нет, Вы можете перевести свой стейк на L2 сразу же, нет необходимости снимать стейк и ждать, прежде чем использовать инструмент переноса. 28-дневное ожидание действует только в том случае, если Вы хотите вывести средства обратно на свой кошелек, в основной сети Ethereum или на L2.
+
+### Сколько времени займет перевод моего стейка?
+
+Инструмент переноса L2 займет около 20 минут для завершения переноса Вашего стейка.
+
+### Должен ли я индексироваться на Arbitrum перед тем, как перенести стейк?
+
+Вы можете эффективно перенести свой стейк до начала настройки индексации, но Вы не сможете претендовать на вознаграждение на L2 до тех пор, пока не распределите субграфы на L2, не проиндексируете их, а также пока не представите POI.
+
+### Могут ли делегаторы перемещать свои делегации до того, как я перемещу свой индексируемый стейк?
+
+Нет, для того чтобы делегаторы могли перенести делегированные ими GRT в Arbitrum, индексатор, которому они делегируют, должен быть активен в L2.
+
+### Могу ли я перенести свой стейк, если я использую вестинговый договор GRT / кошелек с блокировкой токенов?
+
+Да! Процесс немного отличается, поскольку вестинговые контракты не могут пересылать ETH, необходимые для оплаты стоимости комиссии сети на L2, поэтому их необходимо пополнить заранее. Если Ваш вестинговый контракт не полностью вестирован, Вам также придется сначала инициализировать аналогичный вестинговый контракт на L2, и Вы сможете перевести стейк только на этот вестинговый контракт на L2. Пользовательский интерфейс Explorer может подсказать Вам этот процесс, если Вы подключились к Explorer с помощью вестингового закрытого кошелька.
+
+### У меня уже есть ставка на L2. Должен ли я всё же отправлять 100 000 GRT, когда впервые использую инструменты перевода?
+
+Да. Смарт-контракты уровня L1 не будут знать о Вашей ставке на уровне L2, поэтому они потребуют от Вас перевода не менее 100 000 GRT при первом переводе.
+
+### Могу ли я перевести свою ставку на L2, если нахожусь в процессе анстейкинга GRT?
+
+Нет. Если какая-то часть Вашей ставки находится в стадии разморозки, Вам придется подождать 28 дней и вывести ее, прежде чем Вы сможете перевести ставку. Токены, которые отправляются в стейкинг, «заблокированы» и предотвращают любые переводы или стейкинг в L2.
+
+## Перенос вестингового контракта
+
+### Как я могу перенести свой вестинговый контракт?
+
+Для переноса Вашего вестинга необходимо выполнить следующие действия:
+
+1. Инициировать перенос вестинга в основной сети Ethereum
+
+2. Подождать 20 минут для получения подтверждения
+
+3. Подтвердить перенос вестинга на Arbitrum
+
+### Как перенести вестинговый контракт, если я только частично вестирован?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Внесите некоторое количество ETH в контракт инструмента переноса (UI может помочь оценить разумную сумму)
+
+2. Отправьте часть заблокированных GRT через контракт инструмента переноса на L2, чтобы инициализировать блокировку вестинга L2. При этом также будет установлен адрес бенефициара L2.
+
+3. Отправьте свой стейк/делегацию в L2 через "заблокированные" функции инструмента переноса в стейкинговом контракте L1.
+
+4. Выведите оставшиеся ETH из контракта инструмента переноса
+
+### Как перенести вестинговый контракт, если я полностью вестирован?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+Для тех, кто полностью вестирован, процесс аналогичен:
+
+1. Внесите некоторое количество ETH в контракт инструмента переноса (UI может помочь оценить разумную сумму)
+
+2. Установите адрес L2, вызвав контракт инструмента переноса данных
+
+3. Отправьте свои ставку/делегацию в L2 через "заблокированные" функции инструмента переноса в стейкинговом контракте L1.
+
+4. Выведите оставшиеся ETH из контракта инструмента переноса
+
+### Могу ли я перенести свой вестинговый контракт на Arbitrum?
+
+Вы можете перенести баланс GRT своего вестингового контракта на вестинговый контракт в L2. Это является необходимым условием для переноса стейка или делегации с вестингового контракта на L2. Вестинговый контракт должен иметь ненулевую сумму GRT (при необходимости можно перевести на него небольшую сумму, например 1 GRT).
+
+При переносе GRT с вестингового контракта L1 на L2 Вы можете выбрать сумму перевода и делать это столько раз, сколько пожелаете. Вестинговый контракт L2 будет инициализирован при первом переводе GRT.
+
+Переносы осуществляются с помощью инструмента переноса Transfer Tool, который будет виден в профиле Explorer при подключении к счету вестингового контракта.
+
+Обратите внимание, что Вы не сможете высвободить/изъять GRT из вестингового контракта L2 до окончания срока вестинга, когда Ваш контракт будет полностью вестирован. Если Вам необходимо вывести GRT до этого момента, Вы можете перевести их обратно на вестинговый контракт L1, используя другой инструмент переноса, доступный для этой цели.
+
+Если Вы не перенесли на L2 баланс вестингового контракта, а Ваш вестинговый контракт полностью вестирован, то Вам не следует переводить свой вестинговый контракт на L2. Вместо этого Вы можете воспользоваться инструментами переноса, чтобы установить адрес кошелька L2 и напрямую перенести свой стейк или делегацию на этот обычный кошелек на L2.
+
+### Я использую свой вестинговый контракт для размещения стейка в основной сети. Могу ли я перенести свой стейк в Arbitrum?
+
+Да, но если Ваш контракт все еще вестинговый, Вы можете перевести стейк только таким образом, чтобы он принадлежал Вашему вестинговому контракту L2. Сначала необходимо инициализировать этот контракт L2, переведя часть баланса GRT с помощью инструмента переноса вестингового контракта в Explorer. Если Ваш контракт полностью вестирован, Вы можете перевести свой стейк на любой адрес в L2, но для этого необходимо предварительно установить его и внести некоторое количество ETH для инструмента переноса L2, чтобы оплатить комиссию сети в L2.
+
+### Я использую свой вестинговый контракт для делегирования в основной сети. Могу ли я перенести свои делегации в Arbitrum?
+
+Да, но если Ваш контракт все еще вестинговый, Вы можете перевести делегацию только таким образом, чтобы она принадлежала Вашему вестинговому контракту L2. Сначала необходимо инициализировать этот контракт в L2, переведя часть баланса GRT с помощью инструмента переноса вестингового контракта в Explorer. Если Ваш контракт полностью вестирован, Вы можете перевести свою делегацию на любой адрес в L2, но для этого необходимо предварительно установить его и внести некоторое количество ETH для инструмента переноса L2, чтобы оплатить стоимость газа в L2.
+
+### Могу ли я указать другого бенефициара в моем вестинговом контракте на L2?
+
+Да, при первом переводе баланса и настройке вестингового контракта L2 Вы можете указать бенефициара L2. Убедитесь, что этот бенефициар является кошельком, который может совершать операции на Arbitrum One, т.е. это должен быть EOA или кошелёк с мультиподписью, развернутый на Arbitrum One.
+
+Если Ваш контракт полностью вестирован, то Вам не нужно устанавливать вестинговый контракт на L2; вместо этого Вы установите адрес кошелька L2, который будет являться кошельком, принимающим Ваш стейк или делегацию в Arbitrum.
+
+### Мой контракт полностью вестирован. Могу ли я перевести свой стейк или делегацию на другой адрес, который не является вестинговым контрактом L2?
+
+Да. Если Вы не перевели на L2 баланс вестингового контракта, и Ваш вестинговый контракт полностью вестирован, то Вам не следует переводить свой вестинговый контракт на L2. Вместо этого Вы можете воспользоваться инструментами переноса, чтобы установить адрес кошелька L2 и напрямую перевести свой стейк или делегацию на этот обычный кошелек на L2.
+
+Это позволяет переносить свой стейк или делегацию на любой адрес L2.
+
+### Мой вестинговый контракт все еще находится в состоянии вестинга. Как мне перенести остаток по вестинговому контракту на L2?
+
+Эти шаги применимы только в том случае, если Ваш контракт все еще находится в состоянии вестинга, или если Вы уже использовали этот процесс, когда Ваш контракт находился в состоянии вестинга.
+
+Чтобы перенести свой вестинговый контракт в L2, необходимо отправить весь баланс GRT на L2 с помощью инструментов переноса, что приведет к инициализации вестингового контракта в L2:
+
+1. Внести некоторое количество ETH на контракт инструмента переноса (они будут использованы для оплаты комиссии сети L2)
+
+2. Отозвать доступ протокола к вестинговому контракту (необходимо для следующего шага)
+
+3. Предоставить протоколу доступ к вестинговому контракту (позволит Вашему контракту взаимодействовать с инструментом переноса)
+
+4. Указать адрес бенефициара L2\* и инициировать перенос баланса в основной сети Ethereum
+
+5. Подождать 20 минут для получения подтверждения
+
+6. Подтвердите перенос баланса на L2
+
+\*При необходимости - т.е. если Вы используете контрактный адрес.
+
+\*\*\*\*Для завершения передачи баланса на Arbitrum необходимо подтвердить транзакцию. Этот шаг должен быть выполнен в течение 7 дней, иначе баланс может быть потерян. В большинстве случаев этот этап выполняется автоматически, однако в случае скачка цен стоимости комиссии сети в Arbitrum может потребоваться ручное подтверждение. Если в ходе этого процесса возникнут какие-либо проблемы, Вам будет оказана помощь: обращайтесь в службу поддержки по адресу support@thegraph.com или в [Discord](https://discord.gg/graphprotocol).
+
+### В моем договоре о передаче прав указано 0 GRT, поэтому я не могу его передать. Почему это происходит и как это исправить?
+
+​Чтобы инициализировать Ваш контракт на передачу прав L2, Вам необходимо перевести ненулевую сумму GRT в L2. Это требуется для моста Arbitrum GRT, который используется инструментами передачи L2. GRT должен поступать из баланса контракта о передаче прав, поэтому он не включает в себя находящиеся в стейкинге или делегированные GRT.
+
+Если Вы отправили в стейкинг или делегировали все свои GRT из контракта на передачу прав, Вы можете вручную отправить небольшую сумму, например 1 GRT, на адрес контракта на передачу прав из любого другого места (например, из другого кошелька или биржи).
+
+### Я использую договор о передаче прав на ставку или делегирование, но не вижу кнопки для передачи своей ставки или делегирования на уровень L2. Что мне делать?
+
+Если Ваш договор о передаче прав еще не завершен, Вам необходимо сначала создать договор о передаче прав L2, который получит Вашу ставку или делегирование на L2. Этот контракт о передаче прав не позволит передавать токены в L2 до конца графика перехода, но позволит Вам перевести GRT обратно в контракт о передаче прав L1 для передачи там.
+
+При подключении к контракту о передаче прав в Explorer Вы увидите кнопку для инициализации Вашего контракта о передаче прав L2. Сначала выполните этот процесс, и затем в своем профиле Вы увидите кнопки для передачи вашей ставки или делегирования.
+
+### Если я инициализирую свой контракт о передаче прав уровня L2, переведёт ли это также автоматически моё делегирование на уровень L2?
+
+Нет, инициализация Вашего контракта о передаче прав L2 является обязательным условием для передачи ставки или делегирования из контракта о передаче прав, но Вам все равно придется передавать их отдельно.
+
+После инициализации контракта о передаче прав L2 в своем профиле Вы увидите баннер с предложением передать свою долю или делегирование.
+
+### Могу ли я перевести свой вестинговый контракт обратно в L1?
+
+Этого делать не нужно, поскольку Ваш вестинговый контракт по-прежнему находится в L1. Когда Вы используете инструменты переноса, Вы просто создаете новый контракт в L2, связанный с Вашим вестинговым контрактом в L1, и можете отправлять GRT туда и обратно между ними.
+
+### Почему в принципе необходимо переносить вестинговый контракт?
+
+Вам необходимо установить вестинговый контракт в L2, чтобы этот счет мог владеть Вашим стейком или делегированием на L2. В противном случае у Вас не будет возможности перевести стейк/делегирование на L2, не "выходя" из вестингового контракта.
+
+### Что произойдет, если я попытаюсь обналичить деньги по своему контракту, который только частично вестирован? Возможно ли это?
+
+Такой возможности нет. Вы можете перевести средства обратно на L1 и вывести их оттуда.
+
+### Что делать, если я не хочу переносить свой вестинговый контракт в L2?
+
+Вы можете продолжать стейкать/делегировать в L1. Со временем Вы можете рассмотреть возможность перехода на L2, чтобы получать там вознаграждения по мере масштабирования протокола на Arbitrum. Обратите внимание, что эти инструменты переноса предназначены для вестинговых контрактов, которые разрешают стейкать и делегировать в протоколе. Если Ваш контракт не позволяет стейкать или делегировать, или является отзывным, то инструмент переноса недоступен. Вы по-прежнему сможете вывести свои GRT из L1, когда они будут доступны.

From fd322787eb4f87c193cb477ac785b08e8850df37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:54 -0500
Subject: [PATCH 1035/3820] New translations l2-transfer-tools-faq.mdx
 (Swedish)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/sv/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/sv/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/sv/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..57633a393b03
--- /dev/null
+++ b/website/pages/sv/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: Vanliga frågor om L2 Överföringsverktyg
+---
+
+## Allmän
+
+### Vad är L2 Överföringsverktyg?
+
+The Graph har gjort det 26 gånger billigare för bidragsgivare att delta i nätverket genom att implementera protokollet på Arbitrum One. L2 Överföringsverktygen skapades av kärnutvecklarna för att göra det enkelt att flytta till L2.
+
+För varje nätverksdeltagare finns en uppsättning L2 Överföringsverktyg tillgängliga för att göra upplevelsen smidig när du flyttar till L2, vilket undviker upptiningsperioder eller att manuellt ta ut och broa GRT.
+
+Dessa verktyg kommer att kräva att du följer en specifik uppsättning steg beroende på vilken roll du har inom The Graph och vad du överför till L2.
+
+### Kan jag använda samma plånbok som jag använder på Ethereum huvudnätet?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### Vad händer om jag inte avslutar min överföring på 7 dagar?
+
+L2 Överföringsverktygen använder Arbitrums nativa mekanism för att skicka meddelanden från L1 till L2. Denna mekanism kallas en "retryable ticket" och används av alla nativa token-broar, inklusive Arbitrum GRT-broen. Du kan läsa mer om retryable tickets i [Arbitrums dokumentation](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+När du överför dina tillgångar (subgraf, insats, delegation eller kurering) till L2 skickas ett meddelande genom Arbitrum GRT-broen, vilket skapar en retryable ticket i L2. Överföringsverktyget inkluderar ett visst ETH-värde i transaktionen, som används för att 1) betala för att skapa biljetten och 2) betala för gasen för att utföra biljetten i L2. Men eftersom gaspriserna kan variera fram till att biljetten är redo att utföras i L2 kan det hända att detta automatiska utförsel försöket misslyckas. När det händer kommer Arbitrum-broen att behålla retryable ticket i livet i upp till 7 dagar, och vem som helst kan försöka "inlösa" biljetten (vilket kräver en plånbok med en viss mängd ETH broad till Arbitrum).
+
+Detta är vad vi kallar "Bekräfta"-steget i alla överföringsverktygen - det kommer att köras automatiskt i de flesta fall, eftersom den automatiska utförandet oftast är framgångsrikt, men det är viktigt att du kontrollerar att det gick igenom. Om det inte lyckas och det inte finns några framgångsrika försök på 7 dagar kommer Arbitrum-broen att kasta biljetten, och dina tillgångar (subgraf, insats, delegation eller kurering) kommer att gå förlorade och kan inte återvinnas. The Graphs kärnutvecklare har ett övervakningssystem på plats för att upptäcka dessa situationer och försöka lösa biljetterna innan det är för sent, men det är i slutändan ditt ansvar att se till att din överföring är klar i tid. Om du har svårt att bekräfta din transaktion, kontakta oss via [detta formulär](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms), och kärnutvecklarna kommer att vara där för att hjälpa dig.
+
+### Jag startade min överföring av delegation/insats/kurering, och jag är osäker på om den lyckades komma till L2, hur kan jag bekräfta att den överfördes korrekt?
+
+Om du inte ser en banner på din profil som ber dig att slutföra överföringen är det troligt att transaktionen säkert nådde L2, och ingen ytterligare åtgärd behövs. Om du är osäker kan du kontrollera om Utforskaren visar din delegation, insats eller kurering på Arbitrum One.
+
+Om du har L1-transaktionshashen (som du kan hitta genom att titta på de senaste transaktionerna i din plånbok) kan du också bekräfta om "retryable ticket" som bar meddelandet till L2 blev inlöst här: https://retryable-dashboard.arbitrum.io/ - om det automatiska inlösandet misslyckades kan du också ansluta din plånbok där och lösa in det. Var säker på att kärnutvecklarna också övervakar meddelanden som fastnar och kommer att försöka lösa dem innan de går ut.
+
+## Subgraf Överföring
+
+### Hur överför jag min subgraf?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+För att överföra din subgraf måste du slutföra följande steg:
+
+1. Initiera överföringen på Ethereum huvudnätet
+
+2. Vänta 20 minuter på bekräftelse
+
+3. Bekräfta subgraföverföringen på Arbitrum\*
+
+4. Slutför publiceringen av subgraf på Arbitrum
+
+5. Uppdatera fråge-URL (rekommenderas)
+
+\*Observera att du måste bekräfta överföringen inom 7 dagar, annars kan din subgraf gå förlorad. I de flesta fall kommer detta steg att köras automatiskt, men en manuell bekräftelse kan behövas om det finns en gasprisspike på Arbitrum. Om det uppstår några problem under denna process finns det resurser för att hjälpa: kontakta support på support@thegraph.com eller på [Discord](https://discord.gg/graphprotocol).
+
+### Var ska jag initiera min överföring från?
+
+Du kan initiera din överföring från [Subgraph Studio](https://thegraph.com/studio/), [Utforskaren,](https://thegraph.com/explorer) eller från vilken som helst subgrafsdetaljsida. Klicka på knappen "Överför subgraf" på subgrafsdetaljsidan för att starta överföringen.
+
+### Hur länge måste jag vänta tills min subgraf överförs?
+
+Överföringstiden tar ungefär 20 minuter. Arbitrum-broen arbetar i bakgrunden för att slutföra broöverföringen automatiskt. I vissa fall kan gasavgifterna öka, och du måste bekräfta transaktionen igen.
+
+### Kommer min subgraf fortfarande vara sökbar efter att jag har överfört den till L2?
+
+Din subgraf kommer endast vara sökbar på det nätverk där den är publicerad. Till exempel, om din subgraf är på Arbitrum One, kan du endast hitta den i Utforskaren på Arbitrum One och kommer inte att kunna hitta den på Ethereum. Se till att du har valt Arbitrum One i nätverksväxlaren högst upp på sidan för att säkerställa att du är på rätt nätverk.  Efter överföringen kommer L1-subgrafen att visas som föråldrad.
+
+### Måste min subgraf vara publicerad för att kunna överföra den?
+
+För att dra nytta av subgraföverföringsverktyget måste din subgraf redan vara publicerad på Ethereum huvudnät och måste ha något kureringssignal ägt av plånboken som äger subgrafen. Om din subgraf inte är publicerad rekommenderas det att du helt enkelt publicerar direkt på Arbitrum One - de associerade gasavgifterna kommer att vara betydligt lägre. Om du vill överföra en publicerad subgraf men ägarplånboken inte har kuraterat något signal på den kan du signalera en liten mängd (t.ex. 1 GRT) från den plånboken; se till att välja "automigrering" signal.
+
+### Vad händer med Ethereum huvudnätversionen av min subgraf efter att jag har överfört till Arbitrum?
+
+Efter att ha överfört din subgraf till Arbitrum kommer Ethereum huvudnätversionen att föråldras. Vi rekommenderar att du uppdaterar din fråge-URL inom 48 timmar. Det finns dock en nådperiod som gör att din huvudnät-URL fungerar så att stöd från tredjeparts-dappar kan uppdateras.
+
+### Behöver jag också publicera om på Arbitrum efter överföringen?
+
+Efter de 20 minuters överföringsfönstret måste du bekräfta överföringen med en transaktion i användargränssnittet för att slutföra överföringen, men överföringsverktyget kommer att guida dig genom detta. Din L1-endpunkt kommer att fortsätta att stödjas under överföringsfönstret och en nådperiod efter. Det rekommenderas att du uppdaterar din endpunkt när det passar dig.
+
+### Kommer min endpunkt att ha nertid under ompubliceringen?
+
+Det är osannolikt, men det är möjligt att uppleva en kort nertid beroende på vilka indexeringar som stöder subgrafen på L1 och om de fortsätter att indexera den tills subgrafen är fullt stödd på L2.
+
+### Är publicering och versionering densamma på L2 som på Ethereum huvudnätet?
+
+Ja. Välj Arbitrum One som ditt publicerade nätverk när du publicerar i Subgraph Studio. I studion kommer den senaste ändpunkt att vara tillgänglig, som pekar till den senaste uppdaterade versionen av subgrafen.
+
+### Kommer min subgrafs kurering att flyttas med min subgraf?
+
+Om du har valt automatisk migreringssignal kommer 100% av din egen kurering att flyttas med din subgraf till Arbitrum One. All subgrafens kureringssignal kommer att konverteras till GRT vid överföringstillfället, och GRT som motsvarar din kureringssignal kommer att användas för att prägla signal på L2-subgrafen.
+
+Andra kuratorer kan välja att ta tillbaka sin del av GRT eller också överföra den till L2 för att prägla signal på samma subgraf.
+
+### Kan jag flytta min subgraf tillbaka till Ethereum huvudnätet efter överföringen?
+
+När den är överförd kommer din Ethereum huvudnätversion av denna subgraf att vara föråldrad. Om du vill flytta tillbaka till huvudnätet måste du omimplementera och publicera på huvudnätet igen. Dock avråds starkt från att flytta tillbaka till Ethereum huvudnätet eftersom indexbelöningar till sist kommer att fördelas helt på Arbitrum One.
+
+### Varför behöver jag bridged ETH för att slutföra min överföring?
+
+Gasavgifter på Arbitrum One betalas med bridged ETH (dvs. ETH som har broats till Arbitrum One). Gasavgifterna är dock betydligt lägre jämfört med Ethereum huvudnätet.
+
+## Delegering
+
+### Hur överför jag min delegation?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+För att överföra din delegation måste du följa följande steg:
+
+1. Initiera överföring av delegationen på Ethereum huvudnät
+2. Vänta 20 minuter på bekräftelse
+3. Bekräfta överföring av delegationen på Arbitrum
+
+\*\*\*\*Du måste bekräfta transaktionen för att slutföra överföringen av delegationen på Arbitrum. Detta steg måste slutföras inom 7 dagar, annars kan delegationen gå förlorad. I de flesta fall kommer detta steg att köras automatiskt, men manuell bekräftelse kan behövas om det uppstår en gasprisökning på Arbitrum. Om det uppstår problem under denna process finns det resurser för att hjälpa: kontakta support på support@thegraph.com eller på [Discord](https://discord.gg/graphprotocol).
+
+### Vad händer med mina belöningar om jag inleder en överföring med en öppen tilldelning på Ethereum huvudnät?
+
+Om Indexern som du delegerar till fortfarande är aktiv på L1, kommer du att förlora eventuella delegationsbelöningar från öppna tilldelningar på Ethereum huvudnät när du överför till Arbitrum. Det innebär att du kommer att förlora belöningar från högst den senaste 28-dagarsperioden. Om du tajmar överföringen precis efter att Indexern har stängt tilldelningarna kan du se till att detta är den minsta möjliga mängd. Om du har en kommunikationskanal med dina Indexer(s), överväg att diskutera med dem för att hitta den bästa tiden att göra din överföring.
+
+### Vad händer om Indexern som jag för närvarande delegerar till inte finns på Arbitrum One?
+
+Överföringsverktyget för L2 kommer endast att aktiveras om Indexern som du har delegerat till har överfört sin egen insats till Arbitrum.
+
+### Har delegatörer möjlighet att delegera till en annan Indexer?
+
+Om du vill delegera till en annan Indexerare kan du överföra till samma Indexerare på Arbitrum, sedan sluta delegera och vänta på upptiningstiden. Efter detta kan du välja en annan aktiv Indexerare att delegera till.
+
+### Vad gör jag om jag inte kan hitta Indexern som jag delegerar till på L2?
+
+Överföringsverktyget för L2 kommer automatiskt att upptäcka Indexern som du tidigare har delegerat till.
+
+### Kan jag blanda min delegation över flera nya Indexers istället för den tidigare Indexern?
+
+Överföringsverktyget för L2 kommer alltid att flytta din delegation till samma Indexer som du tidigare delegerat till. När du har flyttat till L2 kan du sluta delegera, vänta på upptiningstiden och bestämma om du vill dela upp din delegation.
+
+### Omfattas jag av en återhämtningsperiod eller kan jag ta ut direkt efter att ha använt överföringsverktyget för L2-delegering?
+
+Överföringsverktyget låter dig omedelbart flytta till L2. Om du vill sluta delegera måste du vänta på upptiningstiden. Om en Indexer har överfört all sin insats till L2 kan du dock ta ut på Ethereum huvudnätet direkt.
+
+### Kan mina belöningar påverkas negativt om jag inte överför min delegation?
+
+Det förväntas att all nätverksdeltagande kommer att flyttas till Arbitrum One i framtiden.
+
+### Hur lång tid tar det att slutföra överföringen av min delegering till L2?
+
+En 20-minuters bekräftelse krävs för delegationens överföring. Observera att efter de 20 minuterna måste du komma tillbaka och slutföra steg 3 i överföringsprocessen inom 7 dagar. Om du inte gör det kan din delegation gå förlorad. Notera att i de flesta fall kommer överföringsverktyget att slutföra detta steg åt dig automatiskt. Om det uppstår en misslyckad automatisk försök måste du slutföra det manuellt. Om några problem uppstår under denna process, oroa dig inte, vi kommer att vara här för att hjälpa: kontakta oss på support@thegraph.com eller på [Discord](https://discord.gg/graphprotocol).
+
+### Kan jag överföra min delegation om jag använder en GRT vestingkontrakt/token lock wallet?
+
+Ja! Processen är något annorlunda eftersom vestingkontrakt inte kan vidarebefordra ETH som behövs för att betala för L2-gasen, så du måste sätta in det i förväg. Om ditt vestingkontrakt inte är helt mogen måste du också först initialisera ett motsvarande vestingkontrakt på L2 och kommer endast att kunna överföra delegationen till detta L2-vestingkontrakt. Användargränssnittet på Utforskaren kan vägleda dig genom denna process när du har anslutit till Utforskaren med hjälp av vestinglåsningsplånboken.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### Finns det någon delegatsskatt?
+
+Nej. Mottagna tokens på L2 delegeras till den angivna indexeraren på uppdrag av den angivna delegeraren utan att ta ut en delegeringsskatt.
+
+### Kommer mina orealiserade belöningar att överföras när jag överför min delegation?
+
+Ja! De enda belöningarna som inte kan överföras är de som är för öppna tilldelningar, eftersom de inte kommer att finnas förrän Indexern stänger tilldelningarna (vanligtvis var 28:e dag). Om du har delegerat under en tid är detta troligen bara en liten del av belöningarna.
+
+På smart kontraktsnivå är orealiserade belöningar redan en del av din delegationsbalans, så de kommer att överföras när du överför din delegation till L2.​
+
+### Är det obligatoriskt att flytta delegationer till L2? Finns det en deadline?
+
+Det är inte obligatoriskt att flytta delegationen till L2, men indexbelöningarna ökar på L2 enligt tidslinjen som beskrivs i [GIP-0052](https://forum.thegraph.com/t/gip-0052-tidslinje-och-krav-för-att-öka-belöningarna-på-l2/4193). Till slut, om rådet fortsätter att godkänna ökningarna, kommer alla belöningar att distribueras på L2 och det kommer inte att finnas några indexbelöningar för Indexers och Delegators på L1.​
+
+### Om jag delegerar till en Indexer som redan har överfört insats till L2, slutar jag att få belöningar på L1?
+
+Många Indexers överför insatsen successivt, så Indexers på L1 kommer fortfarande att tjäna belöningar och avgifter på L1, som sedan delas med Delegators. När en Indexer har överfört all sin insats kommer de att sluta agera på L1, så Delegators kommer inte längre att få några belöningar om de inte överför till L2.
+
+Till slut, om rådet fortsätter att godkänna ökningarna av indexbelöningar på L2, kommer alla belöningar att distribueras på L2 och det kommer inte att finnas några indexbelöningar för Indexers och Delegators på L1.​
+
+### Jag ser ingen knapp för att överföra min delegation. Varför är det så?
+
+Din Indexer har förmodligen inte använt L2-överföringsverktygen för att överföra insatsen ännu.
+
+Om du kan kontakta Indexern kan du uppmana dem att använda L2-överföringsverktygen så att Delegators kan överföra delegationer till deras L2-Indexer-adress.​
+
+### Min Indexer finns också på Arbitrum, men jag ser ingen knapp för att överföra delegationen i mitt profil. Varför är det så?
+
+Det är möjligt att Indexern har etablerat verksamhet på L2, men ännu inte har använt L2-överföringsverktygen för att överföra insatsen. L1-smartkontrakten kommer därför inte att känna till Indexerns L2-adress. Om du kan kontakta Indexern kan du uppmana dem att använda överföringsverktyget så att Delegators kan överföra delegationer till deras L2-Indexer-adress.​
+
+### Kan jag överföra min delegation till L2 om jag har påbörjat avdelegeringsprocessen och ännu inte har tagit ut den?
+
+Nej. Om din delegation tinar måste du vänta 28 dagar och ta ut den.
+
+De tokens som avdelegeras är "låsta" och kan därför inte överföras till L2.
+
+## Kureringssignal
+
+### Hur överför jag min kurering?
+
+För att överföra din kurering måste du följa följande steg:
+
+1. Initiera signalöverföring på Ethereum huvudnät
+
+2. Ange en L2-kuratorsadress\*
+
+3. Vänta 20 minuter på bekräftelse
+
+\*Om det behövs - dvs. du använder en kontraktadress.
+
+### Hur vet jag om den subgraph jag har kuraterat har flyttats till L2?
+
+När du tittar på sidan med detaljer om subgraphen kommer en banner att meddela dig att denna subgraph har flyttats. Du kan följa uppmaningen för att överföra din kurering. Du kan också hitta denna information på sidan med detaljer om subgraphen som har flyttat.
+
+### Vad händer om jag inte vill flytta min kurering till L2?
+
+När en subgraph avvecklas har du möjlighet att ta tillbaka din signal. På samma sätt, om en subgraph har flyttats till L2, kan du välja att ta tillbaka din signal på Ethereum huvudnät eller skicka signalen till L2.
+
+### Hur vet jag att min kurering har överförts framgångsrikt?
+
+Signaldetaljer kommer att vara tillgängliga via Explorer ungefär 20 minuter efter att L2-överföringsverktyget har initierats.
+
+### Kan jag överföra min kurering på fler än en subgraph samtidigt?
+
+Det finns för närvarande ingen möjlighet till bulköverföring.
+
+## Indexer-insats
+
+### Hur överför jag min insats till Arbitrum?
+
+> Ansvarsfriskrivning: Om du för närvarande avstår från någon del av ditt GRT hos din Indexer kommer du inte att kunna använda L2 överföringsverktyg.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+För att överföra din insats måste du följa dessa steg:
+
+1. Initiera insatsöverföring på Ethereum huvudnät
+
+2. Vänta 20 minuter på bekräftelse
+
+3. Bekräfta insatsöverföring på Arbitrum.
+
+\*Observera att du måste bekräfta överföringen inom 7 dagar annars kan din insats gå förlorad. I de flesta fall kommer detta steg att köras automatiskt, men en manuell bekräftelse kan behövas om det är en gasprisspik på Arbitrum. Om det uppstår problem under processen finns det resurser för att hjälpa: kontakta support på support@thegraph.com eller på [Discord](https://discord.gg/graphprotocol).
+
+### Kommer hela min insats att överföras?
+
+Du kan välja hur mycket av din insats du vill överföra. Om du väljer att överföra hela din insats på en gång måste du stänga alla öppna tilldelningar först.
+
+Om du planerar att överföra delar av din insats över flera transaktioner måste du alltid ange samma förmånstagaradress.
+
+Observera: Du måste uppfylla minimikraven för insats på L2 första gången du använder överföringsverktyget. Indexers måste skicka minst 100 000 GRT (när de kallar på denna funktion första gången). Om du lämnar en del av insatsen på L1 måste den också överstiga det minimibelopp på 100 000 GRT och vara tillräcklig (tillsammans med dina delegationer) för att täcka dina öppna tilldelningar.
+
+### Hur lång tid har jag att bekräfta min insatsöverföring till Arbitrum?
+
+\*\*\* Du måste bekräfta din transaktion för att slutföra insatsöverföringen på Arbitrum. Detta steg måste slutföras inom 7 dagar, annars kan insatsen gå förlorad.
+
+### Vad händer om jag har öppna tilldelningar?
+
+Om du inte skickar hela din insats kommer L2-överföringsverktyget att validera att minst 100 000 GRT finns kvar på Ethereum huvudnät och att din återstående insats och delegation är tillräcklig för att täcka öppna tilldelningar. Du kan behöva stänga öppna tilldelningar om din GRT-balans inte täcker minimierna + öppna tilldelningar.
+
+### Måste jag vänta 28 dagar innan jag kan avsluta min insats på Ethereum huvudnät innan jag överför?
+
+Nej, du kan överföra din insats till L2 omedelbart, det är ingen nödvändighet att avsluta och vänta innan du använder överföringsverktyget. Väntetiden på 28 dagar gäller endast om du vill ta tillbaka insatsen till din plånbok, på Ethereum huvudnät eller L2.
+
+### Hur lång tid tar det att överföra min insats?
+
+Det tar ungefär 20 minuter för L2-överföringsverktyget att slutföra överföringen av din insats.
+
+### Måste jag indexer på Arbitrum innan jag överför min insats?
+
+Du kan effektivt överföra din insats först innan du sätter upp indexering, men du kommer inte att kunna hämta några belöningar på L2 förrän du allokerar till subgrapher på L2, indexerar dem och presenterar POI.
+
+### Kan Delegators flytta sin delegation innan jag flyttar min indexinsats?
+
+Nej, för att Delegators ska kunna överföra sina delegerade GRT till Arbitrum måste Indexern de delegerar till vara aktiv på L2.
+
+### Kan jag överföra min insats om jag använder en GRT-vestingkontrakt / tokenspärrplånbok?
+
+Ja! Processen är något annorlunda, eftersom vestingkontrakt inte kan vidarebefordra ETH som behövs för att betala för L2-gasen, så du måste sätta in det i förväg. Om ditt vestingkontrakt inte är fullt utdelat måste du också först initialisera ett motsvarande vestingkontrakt på L2 och kommer endast att kunna överföra insatsen till detta L2-vestingkontrakt. UI på Explorer kan vägleda dig genom denna process när du har anslutit till Explorer med hjälp av vestingplånboken.
+
+### Jag har redan en insats på L2. Måste jag fortfarande skicka 100k GRT när jag använder överföringsverktygen första gången?
+
+​Ja. L1-smartkontrakten kommer inte att vara medvetna om din L2-insats, så de kommer att kräva att du överför minst 100k GRT när du överför första gången. ​
+
+### Kan jag överföra min insats till L2 om jag är mitt i processen att avsätta GRT?
+
+​Nej. Om någon del av din insats är på väg att tina måste du vänta 28 dagar och ta tillbaka den innan du kan överföra insatsen. De tokens som är insatta är "låsta" och kommer att förhindra alla överföringar eller insatser till L2.
+
+## Överföring av vestingkontrakt
+
+### Hur överför jag mitt vestingkontrakt?
+
+För att överföra ditt vestingkontrakt måste du följa dessa steg:
+
+1. Initiera överföringen av vesting på Ethereum huvudnät
+
+2. Vänta 20 minuter på bekräftelse
+
+3. Bekräfta överföringen av vesting på Arbitrum
+
+### Hur överför jag mitt vestingkontrakt om jag bara är delvis utdelad?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Sätt in lite ETH i överföringsverktygskontraktet (UI kan hjälpa till att uppskatta en rimlig summa)
+
+2. Skicka lite låst GRT genom överföringsverktygskontraktet till L2 för att initialisera låsningsmekanismen för L2. Detta kommer också att ange deras L2-förmånstagareadress.
+
+3. Skicka deras insats/delegering till L2 genom "låsta" överföringsverktygsfunktioner i L1Staking-kontraktet.
+
+4. Ta ut eventuell kvarvarande ETH från överföringsverktygskontraktet
+
+### Hur överför jag mitt vestingkontrakt om jag är fullständigt utdelad?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+För de som är fullständigt utdelade är processen liknande:
+
+1. Sätt in lite ETH i överföringsverktygskontraktet (UI kan hjälpa till att uppskatta en rimlig summa)
+
+2. Ange din L2-adress med ett anrop till överföringsverktygskontraktet
+
+3. Skicka din insats/delegering till L2 genom "låsta" överföringsverktygsfunktioner i L1-stake-kontraktet.
+
+4. Ta ut eventuell kvarvarande ETH från överföringsverktygskontraktet
+
+### Kan jag överföra mitt vestingkontrakt till Arbitrum?
+
+Du kan överföra ditt vestingkontrakt GRT-saldo till ett vestingkontrakt i L2. Detta är en förutsättning för att överföra insats eller delegering från ditt vestingkontrakt till L2. Vestingkontraktet måste innehålla en icke-noll mängd GRT (du kan överföra en liten mängd som 1 GRT om det behövs).
+
+När du överför GRT från ditt L1-vestingkontrakt till L2 kan du välja beloppet att skicka och du kan göra detta så många gånger du vill. L2-vestingkontraktet initialiseras första gången du överför GRT.
+
+Överföringarna utförs med hjälp av ett överföringsverktyg som kommer att vara synligt på din Explorer-profil när du ansluter med vestingkontraktkontot.
+
+Observera att du inte kommer att kunna släppa/tillbakadra GRT från L2-vestingkontraktet förrän vid slutet av din utdelningstid när ditt kontrakt är fullständigt utdelat. Om du behöver släppa GRT före det kan du överföra GRT tillbaka till L1-vestingkontraktet med ett annat överföringsverktyg som är tillgängligt för detta ändamål.
+
+Om du inte har överfört något vestingkontraktsaldo till L2 och ditt vestingkontrakt är fullständigt utdelat bör du inte överföra ditt vestingkontrakt till L2. Istället kan du använda överföringsverktygen för att ange en L2-plånboksadress och direkt överföra din insats eller delegering till denna vanliga plånbok på L2.
+
+### Jag använder mitt vestingkontrakt för att satsa på huvudnätet. Kan jag överföra min insats till Arbitrum?
+
+Ja, men om ditt kontrakt fortfarande är utdelat kan du bara överföra insatsen så att den ägs av ditt L2-vestingkontrakt. Du måste först initialisera detta L2-kontrakt genom att överföra en viss GRT-saldo med hjälp av vestingkontraktoverföringsverktyget på Explorer. Om ditt kontrakt är fullständigt utdelat kan du överföra din insats till valfri adress i L2, men du måste ställa in den i förväg och sätta in lite ETH för överföringsverktyget på L2 för att betala för L2-gasen.
+
+### Jag använder mitt vestingkontrakt för att delegera på huvudnätet. Kan jag överföra mina delegationer till Arbitrum?
+
+Ja, men om ditt kontrakt fortfarande är utdelat kan du bara överföra delegationen så att den ägs av ditt L2-vestingkontrakt. Du måste först initialisera detta L2-kontrakt genom att överföra en viss GRT-saldo med hjälp av vestingkontraktoverföringsverktyget på Explorer. Om ditt kontrakt är fullständigt utdelat kan du överföra din delegation till valfri adress i L2, men du måste ställa in den i förväg och sätta in lite ETH för överföringsverktyget på L2 för att betala för L2-gasen.
+
+### Kan jag ange en annan förmånstagare för mitt vestingkontrakt på L2?
+
+Ja, första gången du överför ett saldo och konfigurerar ditt L2-vestingkontrakt kan du ange en L2-förmånstagare. Se till att denna förmånstagare är en plånbok som kan utföra transaktioner på Arbitrum One, dvs. den måste vara en EOA eller en multisig som är distribuerad till Arbitrum One.
+
+Om ditt kontrakt är fullständigt utdelat kommer du inte att konfigurera ett vestingkontrakt på L2; istället kommer du att ställa in en L2-plånboksadress och detta kommer att vara den mottagande plånboken för din insats eller delegering på Arbitrum.
+
+### Mitt kontrakt är fullständigt utdelat. Kan jag överföra min insats eller delegering till en annan adress som inte är ett L2-vestingkontrakt?
+
+Ja. Om du inte har överfört något saldo från vestingkontraktet till L2 och ditt vestingkontrakt är fullständigt utdelat bör du inte överföra ditt vestingkontrakt till L2. Istället kan du använda överföringsverktygen för att ange en L2-plånboksadress och direkt överföra din insats eller delegering till denna vanliga plånbok på L2.
+
+Detta gör att du kan överföra din insats eller delegering till valfri L2-adress.
+
+### Mitt vestingkontrakt är fortfarande utdelat. Hur överför jag mitt vestingkontrakts saldo till L2?
+
+Dessa steg gäller endast om ditt kontrakt fortfarande är utdelat eller om du har använt denna process tidigare när ditt kontrakt fortfarande var utdelat.
+
+För att överföra ditt vestingkontrakt till L2 kommer du att skicka en viss GRT-saldo till L2 med hjälp av överföringsverktygen, vilket kommer att initialisera ditt L2-vestingkontrakt:
+
+1. Sätt in lite ETH i överföringsverktygskontraktet (detta kommer att användas för att betala för L2-gas)
+
+2. Återkalla protokollåtkomst till vestingkontraktet (nödvändigt för nästa steg)
+
+3. Ge protokollåtkomst till vestingkontraktet (möjliggör för ditt kontrakt att interagera med överföringsverktyget)
+
+4. Ange en L2-förmånstagareadress\* och initiera saldöverföringen på Ethereum huvudnät
+
+5. Vänta 20 minuter på bekräftelse
+
+6. Bekräfta saldöverföringen på L2
+
+\*Om det behövs - dvs. du använder en kontraktadress.
+
+\*\*\*\* Du måste bekräfta din transaktion för att slutföra saldöverföringen på Arbitrum. Detta steg måste slutföras inom 7 dagar eller saldot kan gå förlorat. I de flesta fall kommer detta steg att köras automatiskt, men manuell bekräftelse kan behövas om det finns en gasprisökning på Arbitrum. Om det uppstår några problem under denna process kommer det att finnas resurser att hjälpa till: kontakta supporten på support@thegraph.com eller på [Discord](https://discord.gg/graphprotocol).
+
+### Mitt vestingkontrakt visar 0 GRT så jag kan inte överföra det, varför är det här och hur fixar jag det?
+
+För att initialisera ditt L2-vestingkontrakt måste du överföra en icke-noll mängd GRT till L2. Detta krävs av Arbitrum GRT-broen som används av L2 Transfer Tools. GRT måste komma från vestingkontraktets saldo, så det inkluderar inte stakade eller delegerade GRT.
+
+Om du har stakat eller delegerat all din GRT från vestingkontraktet kan du manuellt skicka en liten mängd som 1 GRT till vestingkontraktadressen från någon annanstans (t.ex. från en annan plånbok eller en börs).
+
+### Jag använder ett vestingkontrakt för att satsa eller delegera, men jag ser inte någon knapp för att överföra min insats eller delegering till L2, vad gör jag?
+
+Om ditt vestingkontrakt inte har avslutat utdelningen måste du först skapa ett L2-vestingkontrakt som kommer att ta emot din insats eller delegering på L2. Detta vestingkontrakt tillåter inte utgivning av token på L2 förrän i slutet av utdelningstiden, men kommer att tillåta dig att överföra GRT tillbaka till L1-vestingkontraktet för att släppas där.
+
+När du är ansluten till vestingkontraktet på Explorer bör du se en knapp för att initialisera ditt L2-vestingkontrakt. Följ den processen först, och du kommer sedan att se knapparna för att överföra din insats eller delegering i din profil.
+
+### Om jag initierar mitt L2-vestingkontrakt, kommer detta också att överföra min delegering till L2 automatiskt?
+
+Nej, att initiera ditt L2-vestingkontrakt är en förutsättning för att överföra insats eller delegering från vestingkontraktet, men du måste fortfarande överföra dessa separat.
+
+Du kommer att se en banner på din profil som uppmanar dig att överföra din insats eller delegering efter att du har initierat ditt L2-vestingkontrakt.
+
+### Kan jag flytta mitt vestingkontrakt tillbaka till L1?
+
+Det finns ingen anledning att göra det eftersom ditt vestingkontrakt fortfarande finns i L1. När du använder överföringsverktygen skapar du bara ett nytt kontrakt i L2 som är anslutet till ditt L1-vestingkontrakt, och du kan skicka GRT fram och tillbaka mellan de två.
+
+### Varför måste jag flytta mitt vestingkontrakt överhuvudtaget?
+
+Du måste konfigurera ett L2-vestingkontrakt så att detta konto kan äga din insats eller delegering på L2. Annars skulle det inte finnas något sätt för dig att överföra insatsen/delegeringen till L2 utan att "fly" vestingkontraktet.
+
+### Vad händer om jag försöker ta ut mitt kontrakt när det bara är delvis utdelat? Är det möjligt?
+
+Detta är inte möjligt. Du kan flytta pengar tillbaka till L1 och ta ut dem där.
+
+### Vad händer om jag inte vill flytta mitt vestingkontrakt till L2?
+
+Du kan fortsätta satsa/delegera på L1. Över tid kan du överväga att flytta till L2 för att möjliggöra belöningar där när protokollet skalar på Arbitrum. Observera att dessa överföringsverktyg är för vestingkontrakt som får satsa och delegera i protokollet. Om ditt kontrakt inte tillåter satsning eller delegering eller om det är återkallbart finns det inget överföringsverktyg tillgängligt. Du kommer fortfarande att kunna ta ut din GRT från L1 när det är tillgängligt.

From 38230bf0958c701c8384566f8fb32e493610ebe6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:55 -0500
Subject: [PATCH 1036/3820] New translations l2-transfer-tools-faq.mdx
 (Turkish)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/tr/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/tr/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/tr/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..74c52880bc9a
--- /dev/null
+++ b/website/pages/tr/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: Katman2 Transfer Araçları SSS
+---
+
+## Genel
+
+### Katman2 Transfer Araçları Nedir?
+
+Graph, protokolü Arbitrum One'a dağıtarak katkıda bulunanların ağa katılımını 26 kat daha ucuz hale getirdi. Katman2 Transfer Araçları, çekirdek geliştiriciler tarafından Katman2'ye geçişi kolaylaştırmak için oluşturuldu.
+
+Her ağ katılımcısı için, Katman2'ye geçişteki deneyimi sorunsuz hale getirmek, serbest kalma sürelerinden kaçınmak veya GRT'yi manuel olarak geri çekmek ve köprülemek zorunda kalmamak için bir dizi Katman2 Transfer Aracı mevcuttur.
+
+Bu araçlar, Graph içindeki rolünüzün ne olduğuna ve Katman2'ye ne transfer ettiğinize bağlı olarak belirli bir dizi adımı izlemenizi gerektirecektir.
+
+### Ethereum ana ağında kullandığım aynı cüzdanı kullanabilir miyim?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Ethereum ve Arbitrum gibi EVM blok zincirlerindeki cüzdanlar, blok zinciri ile etkileşime girmenize gerek kalmadan oluşturduğunuz bir çift anahtardır (genel ve özel). Dolayısıyla, Ethereum için oluşturulan herhangi bir cüzdan, başka bir işlem yapmanıza gerek kalmadan Arbitrum üzerinde de çalışacaktır.
+
+Bunun istisnası çoklu imza gibi akıllı sözleşme cüzdanlarıdır. Bunlar her bir zincire ayrı ayrı dağıtılan ve dağıtıldıklarında adreslerini alan akıllı sözleşmelerdir. Bir çoklu imza Ethereum'a dağıtılmışsa, Arbitrum'da aynı adresle var olmayacaktır. Yeni bir çoklu imza ilk olarak Arbitrum'da oluşturulmalıdır ve farklı bir adres alabilir.
+
+### Transferimi 7 gün içinde tamamlayamazsam ne olur?
+
+L2 Transfer Araçları, Katman1'den Katman2'ye mesaj göndermek için Arbitrum'un yerel mekanizmasını kullanır. Bu mekanizma "yeniden denenebilir bilet" olarak adlandırılır ve Arbitrum GRT köprüsü de dahil olmak üzere tüm yerel token köprüleri tarafından kullanılır. Tekrar denenebilir biletler hakkında daha fazla bilgiyi [Arbitrum dökümantasyonunda] (https://docs.arbitrum.io/arbos/l1-to-l2-messaging) okuyabilirsiniz.
+
+Varlıklarınızı (subgraph, stake, delegasyon veya kürasyon) Katman2'ye aktardığınızda, Katman2'de yeniden denenebilir bir bilet oluşturan Arbitrum GRT köprüsü aracılığıyla bir mesaj gönderilir. Transfer aracı, işlemde 1) bileti oluşturmak için ödeme yapmak ve 2) bileti Katman2'de yürütmek üzere gas için ödeme yapmak amacıyla kullanılan bir miktar ETH içerir. Ancak, bilet Katman2'de yürütülmeye hazır olana kadar geçen sürede gas fiyatları değişebileceğinden ötürü, bu otomatik yürütme girişiminin başarısız olma ihtimali vardır. Bu durumda, Arbitrum köprüsü yeniden denenebilir bileti 7 güne kadar kullanılabilir tutacaktır ve herkes bileti "kullanmayı" yeniden deneyebilir (bunun için Arbitrum'a köprülenmiş bir miktar ETH'ye sahip bir cüzdan gereklidir).
+
+Bu, tüm transfer araçlarında "Onayla" adımı olarak adlandırdığımız adımdır - otomatik yürütme çoğu zaman başarılı olduğu için çoğu durumda otomatik olarak çalışacaktır, ancak başarılı bir şekilde gerçekleştiğinden emin olmak için tekrar kontrol etmeniz önemlidir. Başarılı olmazsa ve 7 gün içinde başarılı bir yeniden deneme gerçekleşmezse, Arbitrum köprüsü bileti iptal edecek ve varlıklarınız (subgraph, stake, delegasyon veya kürasyon) kaybolacak ve kurtarılamayacaktır. Graph çekirdek geliştiricileri bu durumları tespit etmek ve çok geç olmadan biletleri kurtarmaya çalışmak için bir izleme sistemine sahiptir, ancak transferinizin zamanında tamamlanmasını sağlamak nihayetinde sizin sorumluluğunuzdadır. İşleminizi onaylamakta sorun yaşıyorsanız, lütfen [bu formu](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) kullanarak bize ulaşın; çekirdek geliştiriciler size yardımcı olacaktır.
+
+### Delegasyon/stake/kürasyon transferimi başlattım ve Katman2'ye ulaşıp ulaşmadığından emin değilim, doğru şekilde transfer edilip edilmediğini nasıl teyit edebilirim?
+
+Profilinizde transferi tamamlamanızı isteyen bir banner görmüyorsanız, muhtemelen işlem güvenli bir şekilde Katman2'ye ulaşmıştır ve başka bir işlem yapmanız gerekmiyordur. Herhangi bir şüpheniz varsa, Gezgin'in Arbitrum One'da delegasyonunuzu, stake'inizi veya kürasyonunuzu gösterip göstermediğini kontrol edebilirsiniz.
+
+Katman1 işlem hash'ına sahipseniz (cüzdanınızdaki son işlemlere bakarak bulabilirsiniz), mesajı Katman2'ye taşıyan "yeniden denenebilir biletin" burada kullanılıp kullanılmadığını da doğrulayabilirsiniz: https://retryable-dashboard.arbitrum.io/.Otomatik kurtarma başarısız olduysa, cüzdanınızı oraya bağlayabilir ve kullanabilirsiniz. Çekirdek geliştiricilerin de takılan mesajları izlediğinden ve süresi dolmadan önce bunları kurtarmaya çalışacağından emin olabilirsiniz.
+
+## Subgraph Transferi
+
+### Subgraph'ımı nasıl transfer edebilirim?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+Subgraph'ınızı transfer etmek için aşağıdaki adımları tamamlamanız gerekecektir:
+
+1. Ethereum ana ağında transferi başlatın
+
+2. Onaylanması için 20 dakika bekleyin
+
+3. Arbitrum\* üzerinde subgraph transferini onaylayın
+
+4. Arbitrum üzerinde subgraph'ı yayınlamayı bitirin
+
+5. Sorgu URL'sini Güncelle (önerilir)
+
+\*Transferi 7 gün içinde onaylamanız gerektiğini unutmayın, aksi takdirde subgraph'ınız kaybolabilir. Çoğunlukla, bu adım otomatik olarak çalışacaktır, ancak Arbitrum'da gas fiyatlarında bir artış varsa manuel bir onay gerekebilir. Bu süreç sırasında herhangi bir sorun yaşanırsa, yardımcı olacak kaynaklar olacaktır: support@thegraph.com veya [Discord](https://discord.gg/graphprotocol) üzerinden destek ile iletişime geçin.
+
+### Transferimi nereden başlatmalıyım?
+
+Transferinizi [Subgraph Stüdyo](https://thegraph.com/studio/), [Gezgin](https://thegraph.com/explorer) veya herhangi bir subgraph ayrıntıları sayfasından başlatabilirsiniz. Transferi başlatmak için subgraph ayrıntıları sayfasındaki "Subgraph Transfer" butonuna tıklayın.
+
+### Subgraph'ım transfer edilene kadar ne kadar beklemem gerekir?
+
+Transfer süresi yaklaşık 20 dakika alır. Arbitrum köprüsü, köprü transferini otomatik olarak tamamlamak için arka planda çalışmaktadır. Bazı durumlarda gaz maliyetleri artabilir ve işlemi tekrar onaylamanız gerekebilir.
+
+### Katman2'ye transfer ettikten sonra subgraph'ım hala keşfedilebilir olacak mı?
+
+Subgraph'ınız yalnızca yayınlandığı ağda keşfedilebilir olacaktır. Örneğin, subgraph'ınız Arbitrum One üzerindeyse, onu yalnızca Arbitrum One üzerindeki Gezgin'de bulabilirsiniz, Ethereum'da aradığınızda bulamazsınız. Doğru ağda olduğunuzdan emin olmak için lütfen sayfanın üst kısmındaki ağ değiştiricisinde Arbitrum One'ın seçili olduğundan emin olun. Transferden sonra, Katman1 subgraph'ı kullanımdan kaldırılmış olarak görünecektir.
+
+### Transfer etmek için subgraph'ımın yayınlanmış olması gerekiyor mu?
+
+Subgraph transfer aracından yararlanmak için, subgraph'ınızın Ethereum ana ağı'nda yayınlanmış olması ve subgraph'ın sahibi olan cüzdanın, belirli miktarda kürasyon sinyaline sahip olması gerekmektedir. Eğer subgraph'ınız yayınlanmamışsa, doğrudan Arbitrum One'da yayınlamanız önerilir böylece ilgili gas ücretleri önemli ölçüde daha düşük olacaktır. Yayınlanmış bir subgraph'ı transfer etmek istiyorsanız, ancak sahip hesap üzerinde herhangi bir sinyal kürasyonu yapılmamışsa, bu hesaptan küçük bir miktar (örneğin 1 GRT) sinyal verebilirsiniz; "otomatik geçiş" sinyalini seçtiğinizden emin olun.
+
+### Arbitrum'a transfer olduktan sonra subgraph'ımın Ethereum ana ağ versiyonuna ne olur?
+
+Subgraph'ınızı Arbitrum'a transfer ettikten sonra, Ethereum ana ağ versiyonu kullanımdan kaldırılacaktır. Sorgu URL'nizi 48 saat içinde güncellemenizi öneririz. Bununla birlikte, herhangi bir üçüncü taraf merkeziyetsiz uygulama desteğinin güncellenebilmesi için ana ağ URL'nizin çalışmasını sağlayan bir ödemesiz dönem vardır.
+
+### Transferi tamamladıktan sonra Arbitrum'da da yeniden yayınlamam gerekiyor mu?
+
+20 dakikalık transfer aralığından sonra, transferi tamamlamak için kullanıcı arayüzünde bir işlemle transferi onaylamanız gerekecektir ve transfer aracı size bu konuda rehberlik edecektir. Katman1 uç noktanız transfer aralığı ve sonrasındaki ödemesiz dönem boyunca desteklenmeye devam edecektir. Uç noktanızı sizin için uygun olduğunda güncellemeniz önerilir.
+
+### Yeniden yayınlama sırasında uç noktam kesinti yaşar mı?
+
+Olası değildir, fakat Katman1'de hangi İndeksleyicilerin subgraph'ı desteklediğine ve subgraph Katman2'de tam olarak desteklenene kadar indekslemeye devam edip etmediklerine bağlı olarak kısa bir kesinti yaşanması mümkündür.
+
+### Yayınlama ve sürüm oluşturma Katman2'de Ethereum ana ağı ile aynı mı?
+
+Evet. Subgraph Stüdyo'da yayınlarken, yayınlanan ağınız olarak Arbitrum One'ı seçin. Stüdyo'da, subgprah'ın en son güncellenmiş sürümüne yönlendiren en son uç nokta mevcut olacaktır.
+
+### Subgraph'ımın kürasyonu subgraph'ımla birlikte hareket edecek mi?
+
+Otomatik geçiş sinyalini seçtiyseniz, kendi kürasyonunuzun %100'ü subgraph'ınızla birlikte Arbitrum One'a taşınacaktır. Subgraph'ın tüm kürasyon sinyali, aktarım sırasında GRT'ye dönüştürülecek ve kürasyon sinyalinize karşılık gelen GRT, Katman2 subgraph'ında sinyal basmak için kullanılacaktır.
+
+Diğer Küratörler kendilerne ait GRT miktarını geri çekmeyi ya da aynı subgraph üzerinde sinyal basmak için Katman2'ye transfer etmeyi seçebilirler.
+
+### Transferden sonra subgraph'ımı Ethereum ana ağı'na geri taşıyabilir miyim?
+
+Transfer edildikten sonra, bu subgraph'ınızın Ethereum ana ağı sürümü kullanımdan kaldırılacaktır. Ana ağa geri dönmek isterseniz, ana ağa yeniden dağıtmanız ve geri yayınlamanız gerekecektir. Öte yandan, indeksleme ödülleri eninde sonunda tamamen Arbitrum One üzerinde dağıtılacağından, Ethereum ana ağına geri transfer kesinlikle önerilmez.
+
+### Transferimi tamamlamak için neden köprülenmiş ETH'ye ihtiyacım var?
+
+Arbitrum One'daki gas ücretleri köprülenmiş ETH (yani Arbitrum One'a köprülenmiş ETH) kullanılarak ödenir. Bununla birlikte, gas ücretleri Ethereum ana ağına kıyasla önemli ölçüde daha düşüktür.
+
+## Delegasyon
+
+### Delegasyonumu nasıl transfer edebilirim?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+Delegasyonunuzu transfer etmek için aşağıdaki adımları tamamlamanız gerekecektir:
+
+1. Ethereum ana ağında delegasyon transferi başlatın
+2. Onaylanması için 20 dakika bekleyin
+3. Arbitrum\* üzerinde delegasyon transferini onaylayın
+
+\*\*\*\*Arbitrum üzerinde delegasyon transferini tamamlamak için işlemi onaylamanız gerekir. Bu adım 7 gün içinde tamamlanmalıdır, aksi takdirde delegasyon kaybolabilir. Çoğunlukla, bu adım otomatik olarak çalışacaktır, ancak Arbitrum'da gas fiyatlarında bir artış varsa manuel bir onay gerekebilir. Bu süreç sırasında herhangi bir sorun yaşanırsa, yardımcı olacak kaynaklar olacaktır: support@thegraph.com veya [Discord](https://discord.gg/graphprotocol) üzerinden destek ile iletişime geçin.
+
+### Ethereum ana ağında açık bir tahsis mevcutken transfer başlatırsam ödüllerime ne olur?
+
+Delege ettiğiniz İndeksleyici hala Katman1'de çalışıyorsa, Arbitrum'a transfer ettiğinizde Ethereum ana ağındaki açık tahsislerden elde ettiğiniz tüm delegasyon ödüllerini kaybedersiniz. Bu, maksimum son 28 günlük döneme ait ödülleri kaybedeceğiniz anlamına gelir. Transferi, İndeksleyici tahsisleri kapattıktan hemen sonra yaparsanız, bunun mümkün olan en düşük miktar olduğundan emin olabilirsiniz. İndeksleyici(ler)inizle bir iletişim kanalınız varsa, transferinizi yapmak için en iyi zamanı bulmak için onlarla görüşmeyi düşünün.
+
+### Halihazırda delege ettiğim İndeksleyici Arbitrum One'da değilse ne olur?
+
+Katman2 transfer aracı yalnızca yetki verdiğiniz İndeksleyici kendi stake'ini Arbitrum'a transfer etmişse etkinleştirilecektir.
+
+### Delegatörlerin başka bir İndeksleyiciye delege etme seçeneği var mı?
+
+Başka bir İndeksleyiciye delege etmek isterseniz, Arbitrum'da aynı İndeksleyiciye aktarabilir, ardından delege işlemini geri alabilir ve serbest kalma süresini bekleyebilirsiniz. Bundan sonra, delege etmek için başka bir aktif İndeksleyici seçebilirsiniz.
+
+### Delege ettiğim İndeksleyiciyi Katman2'de bulamazsam ne olur?
+
+Katman2 transfer aracı, daha önce delege ettiğiniz İndeksleyiciyi otomatik olarak tespit edecektir.
+
+### Delegasyonumu önceki İndeksleyici yerine yeni veya birkaç İndeksleyici arasında karıştırabilecek, eşleştirebilecek veya 'yayabilecek' miyim?
+
+Katman2 transfer aracı, delegasyonunuzu her zaman daha önce delege ettiğiniz İndeksleyici'ye taşıyacaktır. Katman2'ye taşındıktan sonra, delegasyonu geri alabilir, serbest kalma süresini bekleyebilir ve delegasyonunuzu bölmek isteyip istemediğinize karar verebilirsiniz.
+
+### Bekleme süresine tabi miyim yoksa Katman2 delegasyon transfer aracını kullandıktan hemen sonra geri çekebilir miyim?
+
+Transfer aracı Katman2'ye hemen geçmenizi sağlar. Eğer delegasyonunuzu bozmak isterseniz, serbest kalma süresini beklemeniz gerekecektir. Ancak, bir İndeksleyici tüm stake'ini Katman2'ye transfer ettiyse, Ethereum ana ağında hemen geri çekebilirsiniz.
+
+### Delegasyonumu transfer etmezsem ödüllerim olumsuz etkilenebilir mi?
+
+Gelecekte tüm ağ katılımının Arbitrum One'a taşınması beklenmektedir.
+
+### Delegasyonumun Katman2'ye transferinin tamamlanması ne kadar sürer?
+
+Delegasyon transferi için 20 dakikalık bir onay gereklidir. Lütfen 20 dakikalık sürenin ardından 7 gün içinde geri gelip transfer sürecinin 3. adımını tamamlamanız gerektiğini unutmayın. Bunu yapmazsanız, delegasyonunuz kaybolabilir. Çoğu durumda transfer aracının bu adımı sizin için otomatik olarak tamamlayacağını unutmayın. Otomatik denemenin başarısız olması durumunda, bunu manuel olarak tamamlamanız gerekecektir. Bu işlem sırasında herhangi bir sorun ortaya çıkarsa endişelenmeyin, size yardımcı olmak için burada olacağız: support@thegraph.com veya [Discord](https://discord.gg/graphprotocol) üzerinden bizimle iletişime geçin.
+
+### GRT hak ediş sözleşmesi / token kilit cüzdanı kullanıyorsam delegasyonumu transfer edebilir miyim?
+
+Evet! Süreç biraz farklıdır çünkü hak ediş sözleşmeleri Katman2 gas'ı için ödeme yapmak adına gereken ETH'yi iletemez, bu nedenle önceden yatırmanız gerekir. Hak ediş sözleşmeniz tam olarak hak edilmemişse, önce Katman2'de bir muadil hak ediş sözleşmesi başlatmanız gerekecek ve delegasyonu yalnızca bu Katman2 hak ediş sözleşmesine aktarabileceksiniz. Gezgin'deki kullanıcı arayüzü, hak ediş kilidi cüzdanını kullanarak Gezgin'a bağlandığınızda bu işlem boyunca size rehberlik edebilir.
+
+### Arbitrum hak ediş sözleşmem ana ağdaki gibi GRT'nin serbest bırakılmasına izin verir mi?
+
+Hayır, Arbitrum'da oluşturulan hak ediş sözleşmesi, hak ediş zaman çizelgesinin sonuna kadar, yani sözleşmeniz tamamen hak edilene kadar herhangi bir GRT'nin serbest bırakılmasına izin vermeyecektir. Bu, aksi takdirde her iki katmanda da aynı miktarları serbest bırakmayı mümkün hale getireceğinden ötürü çifte harcamayı önlemek içindir.
+
+GRT'yi hak ediş sözleşmesinden çıkarmak isterseniz, Gezgin'i kullanarak bunları Katman1 hak ediş sözleşmesine geri transfer edebilirsiniz: Arbitrum One profilinizde, GRT'yi ana ağ hak ediş sözleşmesine geri transfer edebileceğinizi söyleyen bir başlık göreceksiniz. Bu, GRT köprüsündeki aynı yerel köprüleme mekanizmasını kullandığından ötürü, Arbitrum One'da bir işlem, 7 gün bekleme ve ana ağda son bir işlem gerektirir.
+
+### Herhangi bir delegasyon vergisi var mı?
+
+Hayır. Katman2'de alınan tokenler, belirtilen Delegatör adına belirtilen İndeksleyiciye bir delegasyon vergisi alınmadan delege edilir.
+
+### Delegasyonumu transfer ettiğimde henüz gerçekleşmemiş ödüllerim de transfer edilecek mi?
+
+Evet! Transfer edilemeyen tek ödül açık tahsisler için olanlardır, çünkü bunlar İndeksleyici tahsisleri kapatana kadar (genellikle her 28 günde bir) var olmayacaktır. Bir süredir delege ediyorsanız, bu muhtemelen ödüllerin yalnızca küçük bir kısmına denk gelmektedir.
+
+Akıllı sözleşme düzeyinde, gerçekleşmemiş ödüller zaten delegasyon bakiyenizin bir parçasıdır, bu nedenle delegasyonunuzu Katman2'ye transfer ettiğinizde bunlar da transfer edilecektir.
+
+### Delegasyonların Katman2'ye taşınması zorunlu mu? Bunun için bir son tarih var mı?
+
+Delegasyonun Katman2'ye taşınması zorunlu değildir, ancak indeksleme ödülleri [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193)'de açıklanan zaman çizelgesini izleyerek Katman2'de artmaktadır. Nihayetinde, Konsey artışları onaylamaya devam ederse, tüm ödüller Katman2'de dağıtılacak ve Katman1'de İndeksleyiciler ve Delegatörler için indeksleme ödülü kalmayacaktır.
+
+### Stake'ini halihazırda Katman2'ye transfer etmiş olan bir İndeksleyiciye delege ediyorsam, Katman1'de ödül almayı bırakacak mıyım?
+
+Birçok İndeksleyici stake'lerini kademeli olarak transfer etmektedir, bu nedenle Katman1'deki İndeksleyiciler Katman1'de ödüller ve ücretler kazanmaya devam edecek ve bunlar daha sonra Delegatörlerle paylaşılacaktır. Bir İndeksleyici tüm stake'lerini transfer ettiğinde, Katman1'de faaliyet göstermeyi bırakacak, böylece Delegatörler Katman2'ye transfer etmedikleri sürece hiçbir ödül alamayacaklar.
+
+Nihayetinde, Konsey artışları onaylamaya devam ederse, tüm ödüller Katman2'de dağıtılacak ve Katman1'de İndeksleyiciler ve Delegatörler için indeksleme ödülü kalmayacaktır.
+
+### Delegasyonumu transfer etmek için bir düğme göremiyorum. Niçin böyle?
+
+Muhtemelen İndeksleyiciniz henüz stake'lerini transfer etmek için Katman2 transfer araçlarını kullanmamıştır.
+
+İndeksleyici ile iletişime geçebilir ve onları Katman2 Transfer Araçlarını kullanmaya teşvik edebilirsiniz. böylece Delegatörler delegasyonları Katman2 İndeksleyici adreslerine transfer edebilirler.
+
+### İndeksleyicim de Arbitrum'da, ancak profilimde delegasyonu transfer etmek için bir düğme göremiyorum. Niçin böyle?
+
+İndeksleyicinin Katman2 üzerinde işlemler başlatmış olması ancak stake transferi için Katman2 transfer araçlarını kullanmamış olması olası bir durumdur. Bu nedenle Katman1 akıllı sözleşmeleri İndeksleyicinin Katman2 adresi hakkında bilgi sahibi olmayacaktır. İndeksleyici ile iletişime geçebilir ve onları Katman2 Transfer Araçlarını kullanmaya teşvik edebilirsiniz. Böylece Delegatörler delegasyonları Katman2 İndeksleyici adreslerine transfer edebilirler.
+
+### Delegasyonumu geri alma sürecini başlattıysam ve henüz geri çekmediysem delegasyonumu Katman2'ye transfer edebilir miyim?
+
+Hayır. Delegasyonunuz serbest kalma sürecindeyse, 28 gün beklemeniz ve sonra geri çekmeniz gerekir.
+
+Delegeden çıkarılmış statüsünde olan tokenler "kilitli" durumdadır ve bu nedenle Katman2'ye transfer edilemezler.
+
+## Kürasyon Sinyali
+
+### Kürasyonumu nasıl transfer edebilirim?
+
+Kürasyonunuzu transfer etmek için aşağıdaki adımları tamamlamanız gerekecektir:
+
+1. Ethereum ana ağında sinyal transferini başlatın
+
+2. Bir Katman2 Kürasyon adresi belirleyin\*
+
+3. Onaylanması için 20 dakika bekleyin
+
+\*Gerekliyse - yani bir sözleşme adresi kullanıyorsanız.
+
+### Küratörlüğünü yaptığım subgraph'ın Katman2'ye taşınıp taşınmadığını nasıl bileceğim?
+
+Subgraph ayrıntıları sayfasını görüntülerken, bir afiş size bu subgraph'ın transfer edildiğini bildirecektir. Kürasyonunuzu transfer etmek için komut istemini takip edebilirsiniz. Bu bilgiyi taşınan herhangi bir subgraph'ın subgraph ayrıntıları sayfasında da bulabilirsiniz.
+
+### Kürasyonumu Katman2'ye taşımak istemezsem ne olur?
+
+Bir subgraph kullanımdan kaldırıldığında sinyalinizi geri çekme opsiyonu bulunmaktadır. Benzer şekilde, bir subgraph Katman2'ye taşındıysa, sinyalinizi Ethereum ana ağı'nda geri çekmeyi veya sinyali Katman2'ye göndermeyi seçebilirsiniz.
+
+### Kürasyonumun başarıyla transfer edildiğini nasıl bilebilirim?
+
+Sinyal ayrıntıları, Katman2 transfer aracı başlatıldıktan yaklaşık 20 dakika sonra Gezgin üzerinden erişilebilir olacaktır.
+
+### Kürasyonumu aynı anda birden fazla subgraph'a transfer edebilir miyim?
+
+Şu anda toplu transfer seçeneği bulunmamaktadır.
+
+## İndeksleyici Stake'i
+
+### Payımı Arbitrum'a nasıl transfer edebilirim?
+
+> Uyarı: Stake ettiğiniz GRT'nizin herhangi bir bölümünü İndeksleyicinizden kaldırıyorsanız Katman2 Transfer Araçlarını kullanamazsınız.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+Stake'inizi transfer etmek için aşağıdaki adımları tamamlamanız gerekecektir:
+
+1. Ethereum ana ağında stake transferi başlatın
+
+2. Onaylanması için 20 dakika bekleyin
+
+3. Arbitrum\* üzerinde stake transferini onaylayın
+
+\*Transferi 7 gün içinde onaylamanız gerektiğini unutmayın, aksi takdirde stake'iniz kaybolabilir. Çoğunlukla, bu adım otomatik olarak çalışacaktır, ancak Arbitrum'da gas fiyatlarında bir artış varsa manuel bir onay gerekebilir. Bu süreç sırasında herhangi bir sorun yaşanırsa, yardımcı olacak kaynaklar olacaktır: support@thegraph.com veya [Discord](https://discord.gg/graphprotocol) üzerinden destek ile iletişime geçin.
+
+### Stake'imin tamamı transfer edilecek mi?
+
+Stake'inizin ne kadarını transfer edeceğinizi seçebilirsiniz. Tamamını tek seferde transfer etmeyi seçerseniz, önce açık tahsisleri kapatmanız gerekecektir.
+
+Stake'inizin bir kısmını birden fazla işlem üzerinden transfer etmeyi planlıyorsanız, her zaman aynı faydalanıcı adresi belirtmelisiniz.
+
+Not: Transfer aracını ilk kez kullandığınızda Katman2'deki minimum stake gereksinimlerini karşılamanız gerekir. İndeksleyiciler minimum 100 bin GRT göndermelidir (bu fonksiyonu ilk kez çağırırken). Katman1'de stake'in bir kısmını bırakıyorsanız, bu miktarda minimum 100 bin GRT'nin üzerinde olmalı ve açık tahsislerinizi karşılamak için (delegasyonlarınızla birlikte) yeterli olmalıdır.
+
+### Arbitrum'a gerçekleştirdiğim stake transferimi onaylamak için ne kadar zamanım var?
+
+\*\*\* Arbitrum'da stake transferini tamamlamak için işleminizi onaylamanız gerekir. Bu adım 7 gün içinde tamamlanmalıdır, aksi takdirde stake kaybolabilir.
+
+### Açık tahsisatlarım varsa ne olur?
+
+Stake'inizin tamamını göndermiyorsanız, Katman2 transfer aracı Ethereum ana ağında en az 100 bin GRT kaldığını ve kalan stake ve delegasyonunuzun açık tahsisleri karşılamak için yeterli olduğunu doğrulayacaktır. GRT bakiyeniz minimumları + açık tahsisleri karşılamıyorsa açık tahsisleri kapatmanız gerekebilir.
+
+### Transfer araçlarını kullanarak, transfer etmeden önce Ethereum ana ağındaki stake'imin kaldırılması için 28 gün beklemek gerekli mi?
+
+Hayır, stake'inizi hemen Katman2'ye transfer edebilirsiniz, transfer aracını kullanmadan önce stake'i kaldırmanıza ve beklemenize gerek yoktur. 28 günlük bekleme süresi yalnızca stake'i Ethereum ana ağındaki veya Katman2'deki cüzdanınıza geri çekmek istediğinizde geçerlidir.
+
+### Stake'imi transfer etmek ne kadar sürer?
+
+Katman2 transfer aracının stake'inizi transfer etmeyi tamamlaması yaklaşık 20 dakika sürecektir.
+
+### Stake'imi transfer etmeden önce Arbitrum'da indekslemem gerekiyor mu?
+
+İndekslemeyi oluşturmadan önce hissenizi etkin bir şekilde aktarabilirsiniz, ancak Katman2'deki subgraph'lara tahsis edene, bunları indeksleyene ve POI'leri sunana kadar Katman2'de herhangi bir ödül talep edemezsiniz.
+
+### Ben indeksleme stake'imi taşımadan önce Delegatörler delegasyonlarını taşıyabilir mi?
+
+Hayır, Delegatörlerin delege ettikleri GRT'yi Arbitrum'a transfer edebilmeleri için delege ettikleri İndeksleyicinin Katman2'de aktif olması gerekir.
+
+### GRT hak ediş sözleşmesi / token kilit cüzdanı kullanıyorsam stake'imi transfer edebilir miyim?
+
+Evet! Süreç biraz farklıdır, çünkü hak ediş sözleşmeleri Katman2 gas'ı için ödeme yapmak adına gereken ETH'yi iletemez, bu nedenle önceden yatırmanız gerekir. Hak ediş sözleşmeniz tam olarak hak edilmemişse, önce Katman2'de bir muadil hak ediş sözleşmesi başlatmanız gerekecek ve stake'i yalnızca bu Katman2 hak ediş sözleşmesine aktarabileceksiniz. Gezgin'deki kullanıcı arayüzü, hak ediş kilidi cüzdanını kullanarak Gezgin'a bağlandığınızda bu işlem boyunca size rehberlik edebilir.
+
+### Halihazırda Katman2'de stake'im var. Transfer araçlarını ilk kez kullanıyorsam, yine de 100 bin GRT göndermem gerekiyor mu?
+
+Evet. Katman1 akıllı sözleşmeleri Katman2 stake'lerinizden bihaber olacaktır, bu nedenle ilk kez transfer yaptığınızda bu en az 100 bin GRT transfer etmenizi gerektirecektir.
+
+### Stake ettiğim GRT'yi kaldırma sürecindeysem, stake'imi Katman2'ye transfer edebilir miyim?
+
+Hayır. Stake'inizin herhangi bir kısmı serbest kalma sürecindeyse, 28 gün beklemeniz ve stake'inizi transfer etmeden önce çekmeniz gerekir. Stake edilen tokenler "kilitlenmiş" durumdadır ve bu Katman2'ye herhangi bir transfer veya stake yapılmasını engeller.
+
+## Hak ediş Sözleşmesi Transferi
+
+### Hak ediş sözleşmemi nasıl transfer edebilirim?
+
+Hak edişinizi transfer etmek için aşağıdaki adımları tamamlamanız gerekecektir:
+
+1. Ethereum ana ağında hak ediş transferi başlatın
+
+2. Onaylanması için 20 dakika bekleyin
+
+3. Arbitrum\* üzerinde hak ediş transferini onaylayın
+
+### Sadece kısmen hak kazanmışsam hak ediş sözleşmemi nasıl transfer edebilirim?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Transfer aracı sözleşmesine bir miktar ETH yatırın (kullanıcı arayüzü makul bir miktar tahmin etmenize yardımcı olabilir)
+
+2. Katman2 hak ediş kilidini başlatmak için transfer aracı sözleşmesi aracılığıyla bir miktar kilitli GRT'yi Katman2'ye gönderin. Bu aynı zamanda Katman2 faydalanıcı adresini de belirleyecektir.
+
+3. Katman1 Stake etme sözleşmesindeki "kilitli" transfer aracı fonksiyonları aracılığıyla onların stake/delegasyonlarını Katman2'ye gönderin.
+
+4. Transfer aracı sözleşmesinde kalan ETH'yi geri çekin
+
+### Tamamen hak kazanmışsam hak ediş sözleşmemi nasıl transfer edebilirim?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+Tamamen hak sahibi olanlar için süreç benzerdir:
+
+1. Transfer aracı sözleşmesine bir miktar ETH yatırın (kullanıcı arayüzü makul bir miktar tahmin etmenize yardımcı olabilir)
+
+2. Transfer aracı sözleşmesine bir çağrı yaparak Katman2 adresinizi ayarlayın
+
+3. Katman1 Stake etme sözleşmesindeki "kilitli" transfer aracı fonksiyonları aracılığıyla stake/delegasyonlarınızı Katman2'ye gönderin.
+
+4. Transfer aracı sözleşmesinde kalan ETH'yi geri çekin
+
+### Hak ediş sözleşmemi Arbitrum'a transfer edebilir miyim?
+
+Hak ediş sözleşmenizin GRT bakiyesini Katman2'deki bir hak ediş sözleşmesine aktarabilirsiniz. Bu, hak ediş sözleşmenizden Katman2'ye stake veya delegasyon aktarmak için bir ön koşuldur. Hak ediş sözleşmesi GRT miktarınız sıfırdan farklı olmalıdır (gerekirse 1 GRT gibi küçük bir miktarı aktarabilirsiniz).
+
+GRT'yi Katman1 hak ediş sözleşmenizden Katman2'ye transfer ettiğinizde, gönderilecek miktarı seçebilir ve bunu istediğiniz kadar yapabilirsiniz. Katman2 hak ediş sözleşmesi, GRT'yi ilk kez transfer ettiğinizde başlatılacaktır.
+
+Transferler, hak ediş sözleşmesi hesabına bağlandığınızda Gezgin profilinizde görülebilecek bir Transfer Aracı kullanılarak yapılır.
+
+Sözleşmeniz tamamen hak edildiğinde hak ediş zaman çizelgenizin sonuna kadar Katman2 hak ediş sözleşmesinden GRT'yi serbest bırakamayacağınızı/çekemeyeceğinizi lütfen unutmayın. GRT'yi bundan önce serbest bırakmanız gerekiyorsa, bu amaçla kullanılabilen başka bir transfer aracını kullanarak GRT'yi Katman1 hak ediş sözleşmesine geri transfer edebilirsiniz.
+
+Katman2'ye herhangi bir hakediş sözleşmesi bakiyesi transfer etmediyseniz ve hakediş sözleşmeniz tamamen hakedilmişse, hakediş sözleşmenizi Katman2'ye transfer etmemelisiniz. Bunun yerine, bir Katman2 cüzdan adresi belirlemek için transfer araçlarını kullanabilir ve stake'inizi veya delegasyonunuzu doğrudan Katman2'deki bu normal cüzdana transfer edebilirsiniz.
+
+### Ana ağda stake etmek için hak ediş sözleşmemi kullanıyorum. Stake'imi Arbitrum'a transfer edebilir miyim?
+
+Evet, ancak sözleşmeniz hala hak ediş sürecindeyse, stake'i yalnızca Katman2 hak ediş sözleşmenize ait olacak şekilde transfer edebilirsiniz. Öncelikle Gezgin'deki hak ediş sözleşmesi transfer aracını kullanarak bir miktar GRT bakiyesi transfer ederek bu Katman2 sözleşmesini başlatmalısınız. Sözleşmeniz tamamen hak edilmişse, stake'inizi Katman2'deki herhangi bir adrese transfer edebilirsiniz, ancak bunu önceden ayarlamanız ve Katman2 transfer aracının Katman2 gas'ına ödeme yapılması için bir miktar ETH yatırmanız gerekir.
+
+### Ana ağda delege etmek için hak ediş sözleşmemi kullanıyorum. Delegasyonumu Arbitrum'a transfer edebilir miyim?
+
+Evet, ancak sözleşmeniz hala hak ediş sürecindeyse, delegasyonu yalnızca Katman2 hak ediş sözleşmenize ait olacak şekilde transfer edebilirsiniz. Öncelikle Gezgin'deki hak ediş sözleşmesi transfer aracını kullanarak bir miktar GRT bakiyesi transfer ederek bu Katman2 sözleşmesini başlatmalısınız. Sözleşmeniz tamamen hak edilmişse, delegasyonunuzu Katman2'deki herhangi bir adrese transfer edebilirsiniz, ancak bunu önceden ayarlamanız ve Katman2 transfer aracının Katman2 gas'ına ödeme yapılması için bir miktar ETH yatırmanız gerekir.
+
+### Katman2'deki hak ediş sözleşmem için farklı bir faydalanıcı belirleyebilir miyim?
+
+Evet, bir bakiyeyi ilk kez transfer ettiğinizde ve Katman2 hak ediş sözleşmenizi kurduğunuzda, bir Katman2 faydalanıcısı belirleyebilirsiniz. Bu faydalanıcının Arbitrum One'da işlem yapabilen bir cüzdan olduğundan emin olun, yani bir Harici Olarak Sahip Olunan Hesap(EOA) veya Arbitrum One'a dağıtılmış bir çoklu imza cüzdanı olmalıdır.
+
+Sözleşmeniz tamamen hak edilmişse, Katman2 üzerinde bir hak ediş sözleşmesi oluşturmayacaksınız; bunun yerine, bir Katman2 cüzdan adresi belirleyeceksiniz ve bu, Arbitrum'daki stake'iniz veya delegasyonunuz için alıcı cüzdan olacak.
+
+### Sözleşmem tamamen hak edilmiş durumda. Stake'imi veya delegasyonumu Katman2 hak ediş sözleşmesi olmayan başka bir adrese transfer edebilir miyim?
+
+Evet. Katman2'ye herhangi bir hak ediş sözleşmesi bakiyesi transfer etmediyseniz ve hak ediş sözleşmeniz tamamen hak edilmişse, hak ediş sözleşmenizi Katman2'ye transfer etmemelisiniz. Bunun yerine, bir Katman2 cüzdan adresi belirlemek için transfer araçlarını kullanabilir ve stake'inizi veya delegasyonunuzu doğrudan Katman2'deki bu normal cüzdana transfer edebilirsiniz.
+
+Bu, stake'inizi veya delegasyonunuzu herhangi bir Katman2 adresine transfer etmenize olanak tanır.
+
+### Hak ediş sözleşmem hala devam ediyor. Hak ediş sözleşmesi bakiyemi Katman2'ye nasıl transfer edebilirim?
+
+Bu adımlar yalnızca sözleşmeniz hala devam ediyorsa veya bu süreci daha önce sözleşmeniz hala devam ederken kullandıysanız geçerlidir.
+
+Hak ediş sözleşmenizi Katman2'ye transfer etmek için, Katman2 hak ediş sözleşmenizi başlatacak olan transfer araçlarını kullanarak herhangi bir GRT bakiyesini Katman2'ye göndereceksiniz:
+
+1. Transfer aracı sözleşmesine bir miktar ETH yatırın (bu Katman2 gas'ını ödemek için kullanılacaktır)
+
+2. Hak ediş sözleşmesine protokol erişimini kaldırın (bir sonraki adım için gereklidir)
+
+3. Hak ediş sözleşmesine protokol erişimi verin (sözleşmenizin transfer aracıyla etkileşime girmesini sağlayacaktır)
+
+4. Bir Katman2 faydalanıcı adresi\* belirleyin ve Ethereum ana ağında bakiye transferini başlatın
+
+5. Onaylanması için 20 dakika bekleyin
+
+6. Katman2'de bakiye transferini onaylayın
+
+\*Gerekliyse - yani bir sözleşme adresi kullanıyorsanız.
+
+\*\*\*\*Arbitrum üzerinde bakiye transferinizi tamamlamak için işlemi onaylamanız gerekir. Bu adım 7 gün içinde tamamlanmalıdır, aksi takdirde bakiyeniz kaybolabilir.Çoğunlukla, bu adım otomatik olarak çalışacaktır, ancak Arbitrum'da gas fiyatlarında bir artış varsa manuel bir onay gerekebilir. Bu süreç sırasında herhangi bir sorun yaşanırsa, yardımcı olacak kaynaklar olacaktır: support@thegraph.com veya [Discord](https://discord.gg/graphprotocol) üzerinden destek ile iletişime geçin.
+
+### Hak ediş sözleşmem 0 GRT gösteriyor, bu yüzden transfer edemiyorum, bunun nedeni nedir ve nasıl düzeltebilirim?
+
+Katman2 hak ediş sözleşmenizi başlatmak için sıfırdan farklı bir GRT miktarını Katman2'ye transfer etmeniz gerekir. Bu, Katman2 Transfer Araçları tarafından kullanılan Arbitrum GRT köprüsü nedeniyle gereklidir. GRT, hak ediş sözleşmesinin bakiyesinden gelmelidir, bu nedenle stake edilmiş veya delege edilmiş GRT'yi kapsamaz.
+
+Hak ediş sözleşmesinden tüm GRT'nizi stake veya delege ettiyseniz, başka bir yerden (örneğin başka bir cüzdandan veya borsadan) hak ediş sözleşmesi adresine manuel olarak 1 GRT gibi cüzi bir miktar gönderebilirsiniz.
+
+### Stake veya delegasyon için bir hak ediş sözleşmesi kullanıyorum, ancak stake'imi veya delegasyonumu Katman2'ye transfer etmek için bir düğme göremiyorum, ne yapmalıyım?
+
+Eğer hak ediş sözleşmenizin vade süresi dolmadıysa, öncelikle Katman2 stake veya delegasyonunuzu alacak olan bir hak ediş sözleşmesi oluşturmanız gerekecek. Bu hak ediş sözleşmesi, vade süresinin sonuna kadar Katman2'de tokenlerin serbest bırakılmasına izin vermeyecektir, ancak GRT'yi Katman1 hak ediş sözleşmesine geri transfer etmenize izin verecektir ve bu sayede tokenleriniz orada serbest bırakılabilir.
+
+Gezgin üzerindeki hak ediş sözleşmesine bağlandığınızda, Katman2 hak ediş sözleşmenizi başlatmak için bir düğme görmelisiniz. İlk olarak bu süreci takip edin, ardından profilinizde stake veye delegasyonunuzu transfer etmeye yarayan düğmeleri göreceksiniz.
+
+### Katman2 hak ediş sözleşmemi başlatırsam, bu aynı zamanda delegasyonumu otomatik olarak katman2'ye transfer edecek mi?
+
+Hayır, hak ediş sözleşmesinden stake veya delegasyon transfer etmek için Katman2 hak ediş sözleşmenizi başlatmak bir ön koşuldur, ancak yine de bunları ayrı olarak transfer etmeniz gerekmektedir.
+
+Katman2 hak ediş sözleşmenizi başlattıktan sonra profilinizde stake'nizi veya delegasyonunuzu transfer etmenizi isteyen bir banner göreceksiniz.
+
+### Hak ediş sözleşmemi Katman1'e geri taşıyabilir miyim?
+
+Hak ediş sözleşmeniz hala Katman1'de olduğu için bunu yapmanıza gerek yoktur. Transfer araçlarını kullandığınızda, Katman2'de Katman1 hak ediş sözleşmenize bağlı yeni bir sözleşme oluşturursunuz ve ikisi arasında GRT gönderip alabilirsiniz.
+
+### Neden başlangıçta hak ediş sözleşmemi taşımam gerekiyor?
+
+Bu hesabın Katman2'deki stake veya delegasyonunuza sahip olabilmesi için bir Katman2 hak ediş sözleşmesi oluşturmanız gerekir. Aksi takdirde, hak ediş sözleşmesinden " kurtulmadan " stake'i / delegasyonu Katman2'ye transfer etmenizin bir yolu olmaz.
+
+### Sözleşmem sadece kısmen hak edilmişken nakde çevirmeye çalışırsam ne olur? Bu mümkün müdür?
+
+Bu mümkün değildir. Fonları Katman1'e geri taşıyabilir ve oradan çekebilirsiniz.
+
+### Hak ediş sözleşmemi Katman2'ye taşımak istemezsem ne olur?
+
+Katman1'de stake etme/delegasyon yapmaya devam edebilirsiniz. Zamanla, protokol Arbitrum'da ölçeklendikçe ödülleri orada etkinleştirmek için Katman2'ye geçmeyi düşünebilirsiniz. Bu transfer araçlarının protokolde stake etme ve delege etmeye izin verilen hakediş sözleşmeleri için olduğunu unutmayın. Sözleşmeniz stake etmeye veya delege etmeye izin vermiyorsa yada iptal edilebilirse, transfer aracı kullanılamaz. Kullanılabilir olduğunda GRT'nizi Katman1'den çekmeye devam edebileceksiniz.

From 14f8c7c04c09275393c6061b6fd15c9a7d9b59b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:56 -0500
Subject: [PATCH 1037/3820] New translations l2-transfer-tools-faq.mdx
 (Ukrainian)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/uk/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/uk/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/uk/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..8e6da852a01c
--- /dev/null
+++ b/website/pages/uk/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2 Transfer Tools FAQ
+---
+
+## General
+
+### What are L2 Transfer Tools?
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### Can I use the same wallet I use on Ethereum mainnet?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### What happens if I don’t finish my transfer in 7 days?
+
+The L2 Transfer Tools use Arbitrum’s native mechanism to send messages from L1 to L2. This mechanism is called a “retryable ticket” and is used by all native token bridges, including the Arbitrum GRT bridge. You can read more about retryable tickets in the [Arbitrum docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+When you transfer your assets (subgraph, stake, delegation or curation) to L2, a message is sent through the Arbitrum GRT bridge which creates a retryable ticket in L2. The transfer tool includes some ETH value in the transaction, that is used to 1) pay to create the ticket and 2) pay for the gas to execute the ticket in L2. However, because gas prices might vary in the time until the ticket is ready to execute in L2, it is possible that this auto-execution attempt fails. When that happens, the Arbitrum bridge will keep the retryable ticket alive for up to 7 days, and anyone can retry “redeeming” the ticket (which requires a wallet with some ETH bridged to Arbitrum).
+
+This is what we call the “Confirm” step in all the transfer tools - it will run automatically in most cases, as the auto-execution is most often successful, but it is important that you check back to make sure it went through. If it doesn’t succeed and there are no successful retries in 7 days, the Arbitrum bridge will discard the ticket, and your assets (subgraph, stake, delegation or curation) will be lost and can’t be recovered. The Graph core devs have a monitoring system in place to detect these situations and try to redeem the tickets before it’s too late, but it is ultimately your responsibility to ensure your transfer is completed in time. If you’re having trouble confirming your transaction, please reach out using [this form](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) and core devs will be there help you.
+
+### I started my delegation/stake/curation transfer and I'm not sure if it made it through to L2, how can I confirm that it was transferred correctly?
+
+If you don't see a banner on your profile asking you to finish the transfer, then it's likely the transaction made it safely to L2 and no more action is needed. If in doubt, you can check if Explorer shows your delegation, stake or curation on Arbitrum One.
+
+If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire.
+
+## Subgraph Transfer
+
+### How do I transfer my subgraph?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+To transfer your subgraph, you will need to complete the following steps:
+
+1. Initiate the transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm subgraph transfer on Arbitrum\*
+
+4. Finish publishing subgraph on Arbitrum
+
+5. Update Query URL (recommended)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Where should I initiate my transfer from?
+
+You can initiate your transfer from the [Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) or any subgraph details page. Click the "Transfer Subgraph" button in the subgraph details page to start the transfer.
+
+### How long do I need to wait until my subgraph is transferred
+
+The transfer time takes approximately 20 minutes. The Arbitrum bridge is working in the background to complete the bridge transfer automatically. In some cases, gas costs may spike and you will need to confirm the transaction again.
+
+### Will my subgraph still be discoverable after I transfer it to L2?
+
+Your subgraph will only be discoverable on the network it is published to. For example, if your subgraph is on Arbitrum One, then you can only find it in Explorer on Arbitrum One and will not be able to find it on Ethereum. Please ensure that you have Arbitrum One selected in the network switcher at the top of the page to ensure you are on the correct network.  After the transfer, the L1 subgraph will appear as deprecated.
+
+### Does my subgraph need to be published to transfer it?
+
+To take advantage of the subgraph transfer tool, your subgraph must be already published to Ethereum mainnet and must have some curation signal owned by the wallet that owns the subgraph. If your subgraph is not published, it is recommended you simply publish directly on Arbitrum One - the associated gas fees will be considerably lower. If you want to transfer a published subgraph but the owner account hasn't curated any signal on it, you can signal a small amount (e.g. 1 GRT) from that account; make sure to choose "auto-migrating" signal.
+
+### What happens to the Ethereum mainnet version of my subgraph after I transfer to Arbitrum?
+
+After transferring your subgraph to Arbitrum, the Ethereum mainnet version will be deprecated. We recommend you update your query URL within 48 hours. However, there is a grace period in place that keeps your mainnet URL functioning so that any third-party dapp support can be updated.
+
+### After I transfer, do I also need to re-publish on Arbitrum?
+
+After the 20 minute transfer window, you will need to confirm the transfer with a transaction in the UI to finish the transfer, but the transfer tool will guide you through this. Your L1 endpoint will continue to be supported during the transfer window and a grace period after. It is encouraged that you update your endpoint when convenient for you.
+
+### Will my endpoint experience downtime while re-publishing?
+
+It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the subgraph on L1 and whether they keep indexing it until the subgraph is fully supported on L2.
+
+### Is publishing and versioning the same on L2 as Ethereum Ethereum mainnet?
+
+Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the subgraph.
+
+### Will my subgraph's curation move with my subgraph?
+
+If you've chosen auto-migrating signal, 100% of your own curation will move with your subgraph to Arbitrum One. All of the subgraph's curation signal will be converted to GRT at the time of the transfer, and the GRT corresponding to your curation signal will be used to mint signal on the L2 subgraph.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph.
+
+### Can I move my subgraph back to Ethereum mainnet after I transfer?
+
+Once transferred, your Ethereum mainnet version of this subgraph will be deprecated. If you would like to move back to mainnet, you will need to redeploy and publish back to mainnet. However, transferring back to Ethereum mainnet is strongly discouraged as indexing rewards will eventually be distributed entirely on Arbitrum One.
+
+### Why do I need bridged ETH to complete my transfer?
+
+Gas fees on Arbitrum One are paid using bridged ETH (i.e. ETH that has been bridged to Arbitrum One). However, the gas fees are significantly lower when compared to Ethereum mainnet.
+
+## Delegation
+
+### How do I transfer my delegation?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+To transfer your delegation, you will need to complete the following steps:
+
+1. Initiate delegation transfer on Ethereum mainnet
+2. Wait 20 minutes for confirmation
+3. Confirm delegation transfer on Arbitrum
+
+\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### What happens to my rewards if I initiate a transfer with an open allocation on Ethereum mainnet?
+
+If the Indexer to whom you're delegating is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer.
+
+### What happens if the Indexer I currently delegate to isn't on Arbitrum One?
+
+The L2 transfer tool will only be enabled if the Indexer you have delegated to has transferred their own stake to Arbitrum.
+
+### Do Delegators have the option to delegate to another Indexer?
+
+If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to.
+
+### What if I can't find the Indexer I'm delegating to on L2?
+
+The L2 transfer tool will automatically detect the Indexer you previously delegated to.
+
+### Will I be able to mix and match or 'spread' my delegation across new or several Indexers instead of the prior Indexer?
+
+The L2 transfer tool will always move your delegation to the same Indexer you delegated to previously. Once you have moved to L2, you can undelegate, wait for the thawing period, and decide if you'd like to split up your delegation.
+
+### Am I subject to the cooldown period or can I withdraw immediately after using the L2 delegation transfer tool?
+
+The transfer tool allows you to immediately move to L2. If you would like to undelegate you will have to wait for the thawing period. However, if an Indexer has transferred all of their stake to L2, you can withdraw on Ethereum mainnet immediately.
+
+### Can my rewards be negatively impacted if I do not transfer my delegation?
+
+It is anticipated that all network participation will move to Arbitrum One in the future.
+
+### How long does it take to complete the transfer of my delegation to L2?
+
+A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Can I transfer my delegation if I'm using a GRT vesting contract/token lock wallet?
+
+Yes! The process is a bit different because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the delegation to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### Is there any delegation tax?
+
+No. Received tokens on L2 are delegated to the specified Indexer on behalf of the specified Delegator without charging a delegation tax.
+
+### Will my unrealized rewards be transferred when I transfer my delegation?
+
+​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards.
+
+At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​
+
+### Is moving delegations to L2 mandatory? Is there a deadline?
+
+​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1?
+
+​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## Curation Signal
+
+### How do I transfer my curation?
+
+To transfer your curation, you will need to complete the following steps:
+
+1. Initiate signal transfer on Ethereum mainnet
+
+2. Specify an L2 Curator address\*
+
+3. Wait 20 minutes for confirmation
+
+\*If necessary - i.e. you are using a contract address.
+
+### How will I know if the subgraph I curated has moved to L2?
+
+When viewing the subgraph details page, a banner will notify you that this subgraph has been transferred. You can follow the prompt to transfer your curation. You can also find this information on the subgraph details page of any subgraph that has moved.
+
+### What if I do not wish to move my curation to L2?
+
+When a subgraph is deprecated you have the option to withdraw your signal. Similarly, if a subgraph has moved to L2, you can choose to withdraw your signal in Ethereum mainnet or send the signal to L2.
+
+### How do I know my curation successfully transferred?
+
+Signal details will be accessible via Explorer approximately 20 minutes after the L2 transfer tool is initiated.
+
+### Can I transfer my curation on more than one subgraph at a time?
+
+There is no bulk transfer option at this time.
+
+## Indexer Stake
+
+### How do I transfer my stake to Arbitrum?
+
+> Disclaimer: If you are currently unstaking any portion of your GRT on your Indexer, you will not be able to use L2 Transfer Tools.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+To transfer your stake, you will need to complete the following steps:
+
+1. Initiate stake transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm stake transfer on Arbitrum
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Will all of my stake transfer?
+
+You can choose how much of your stake to transfer. If you choose to transfer all of your stake at once, you will need to close any open allocations first.
+
+If you plan on transferring parts of your stake over multiple transactions, you must always specify the same beneficiary address.
+
+Note: You must meet the minimum stake requirements on L2 the first time you use the transfer tool. Indexers must send the minimum 100k GRT (when calling this function the first time). If leaving a portion of stake on L1, it must also be over the 100k GRT minimum and be sufficient (together with your delegations) to cover your open allocations.
+
+### How much time do I have to confirm my stake transfer to Arbitrum?
+
+\*\*\* You must confirm your transaction to complete the stake transfer on Arbitrum. This step must be completed within 7 days or stake could be lost.
+
+### What if I have open allocations?
+
+If you are not sending all of your stake, the L2 transfer tool will validate that at least the minimum 100k GRT remains in Ethereum mainnet and your remaining stake and delegation is enough to cover any open allocations. You may need to close open allocations if your GRT balance does not cover the minimums + open allocations.
+
+### Using the transfer tools, is it necessary to wait 28 days to unstake on Ethereum mainnet before transferring?
+
+No, you can transfer your stake to L2 immediately, there's no need to unstake and wait before using the transfer tool. The 28-day wait only applies if you'd like to withdraw the stake back to your wallet, on Ethereum mainnet or L2.
+
+### How long will it take to transfer my stake?
+
+It will take approximately 20 minutes for the L2 transfer tool to complete transferring your stake.
+
+### Do I have to index on Arbitrum before I transfer my stake?
+
+You can effectively transfer your stake first before setting up indexing, but you will not be able to claim any rewards on L2 until you allocate to subgraphs on L2, index them, and present POIs.
+
+### Can Delegators move their delegation before I move my indexing stake?
+
+No, in order for Delegators to transfer their delegated GRT to Arbitrum, the Indexer they are delegating to must be active on L2.
+
+### Can I transfer my stake if I'm using a GRT vesting contract / token lock wallet?
+
+Yes! The process is a bit different, because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the stake to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## Vesting Contract Transfer
+
+### How do I transfer my vesting contract?
+
+To transfer your vesting, you will need to complete the following steps:
+
+1. Initiate the vesting transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm vesting transfer on Arbitrum
+
+### How do I transfer my vesting contract if I am only partially vested?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount)
+
+2. Send some locked GRT through the transfer tool contract, to L2 to initialize the L2 vesting lock. This will also set their L2 beneficiary address.
+
+3. Send their stake/delegation to L2 through the "locked" transfer tool functions in the L1Staking contract.
+
+4. Withdraw any remaining ETH from the transfer tool contract
+
+### How do I transfer my vesting contract if I am fully vested?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+For those that are fully vested, the process is similar:
+
+1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount)
+
+2. Set your L2 address with a call to the transfer tool contract
+
+3. Send your stake/delegation to L2 through the "locked" transfer tool functions in the L1 Staking contract.
+
+4. Withdraw any remaining ETH from the transfer tool contract
+
+### Can I transfer my vesting contract to Arbitrum?
+
+You can transfer your vesting contract's GRT balance to a vesting contract in L2. This is a prerequisite for transferring stake or delegation from your vesting contract to L2. The vesting contract must hold a nonzero amount of GRT (you can transfer a small amount like 1 GRT to it if needed).
+
+When you transfer GRT from your L1 vesting contract to L2, you can choose the amount to send and you can do this as many times as you like. The L2 vesting contract will be initialized the first time you transfer GRT.
+
+The transfers are done using a Transfer Tool that will be visible on your Explorer profile when you connect with the vesting contract account.
+
+Please note that you will not be able to release/withdraw GRT from the L2 vesting contract until the end of your vesting timeline when your contract is fully vested. If you need to release GRT before then, you can transfer the GRT back to the L1 vesting contract using another transfer tool that is available for that purpose.
+
+If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2.
+
+### I'm using my vesting contract to stake on mainnet. Can I transfer my stake to Arbitrum?
+
+Yes, but if your contract is still vesting, you can only transfer the stake so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your stake to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas.
+
+### I'm using my vesting contract to delegate on mainnet. Can I transfer my delegations to Arbitrum?
+
+Yes, but if your contract is still vesting, you can only transfer the delegation so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your delegation to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas.
+
+### Can I specify a different beneficiary for my vesting contract on L2?
+
+Yes, the first time you transfer a balance and set up your L2 vesting contract, you can specify an L2 beneficiary. Make sure this beneficiary is a wallet that can perform transactions on Arbitrum One, i.e. it must be an EOA or a multisig deployed to Arbitrum One.
+
+If your contract is fully vested, you will not set up a vesting contract on L2; instead, you will set an L2 wallet address and this will be the receiving wallet for your stake or delegation on Arbitrum.
+
+### My contract is fully vested. Can I transfer my stake or delegation to another address that is not an L2 vesting contract?
+
+Yes. If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2.
+
+This allows you to transfer your stake or delegation to any L2 address.
+
+### My vesting contract is still vesting. How do I transfer my vesting contract balance to L2?
+
+These steps only apply if your contract is still vesting, or if you've used this process before when your contract was still vesting.
+
+To transfer your vesting contract to L2, you will send any GRT balance to L2 using the transfer tools, which will initialize your L2 vesting contract:
+
+1. Deposit some ETH into the transfer tool contract (this will be used to pay for L2 gas)
+
+2. Revoke protocol access to the vesting contract (needed for the next step)
+
+3. Give protocol access to the vesting contract (will allow your contract to interact with the transfer tool)
+
+4. Specify an L2 beneficiary address\* and initiate the balance transfer on Ethereum mainnet
+
+5. Wait 20 minutes for confirmation
+
+6. Confirm the balance transfer on L2
+
+\*If necessary - i.e. you are using a contract address.
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### Can I move my vesting contract back to L1?
+
+There is no need to do so because your vesting contract is still in L1. When you use the transfer tools, you just create a new contract in L2 that is connected with your L1 vesting contract, and you can send GRT back and forth between the two.
+
+### Why do I need to move my vesting contract to begin with?
+
+You need to set up an L2 vesting contract so that this account can own your stake or delegation on L2. Otherwise, there'd be no way for you to transfer the stake/delegation to L2 without "escaping" the vesting contract.
+
+### What happens if I try to cash out my contract when it is only partially vested? Is this possible?
+
+This is not a possibility. You can move funds back to L1 and withdraw them there.
+
+### What if I don't want to move my vesting contract to L2?
+
+You can keep staking/delegating on L1. Over time, you may want to consider moving to L2 to enable rewards there as the protocol scales on Arbitrum. Note that these transfer tools are for vesting contracts that are allowed to stake and delegate in the protocol. If your contract does not allow staking or delegating, or is revocable, then there is no transfer tool available. You will still be able to withdraw your GRT from L1 when available.

From 974735892a14334dfbfad3cd5a66c7f6bfc2dbf2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:57 -0500
Subject: [PATCH 1038/3820] New translations l2-transfer-tools-faq.mdx (Chinese
 Simplified)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/zh/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/zh/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/zh/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..2d97f1524380
--- /dev/null
+++ b/website/pages/zh/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2转移工具常见问题解答
+---
+
+## 通用
+
+### 什么是L2转移工具？
+
+The Graph 在将协议部署到 Arbitrum One 后，使参与者参与网络的成本降低了 26 倍。L2 转账工具是核心开发人员创建的，旨在简化转移到 Layer 2（二层网络）的过程。
+
+对于每个网络参与者，都提供了一套L2转账工具，以实现无缝的L2转移体验，避免解冻期或手动提取和桥接GRT代币。
+
+这些工具将要求您根据您在 The Graph 中的角色以及您要转移到 Layer 2 的内容，遵循一套特定的步骤。
+
+### 我可以在以太坊主网上使用相同的钱包吗？
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+在像以太坊和 Arbitrum 这样的 EVM 区块链上，钱包是一对密钥（公钥和私钥），您可以在不需要与区块链进行任何交互的情况下创建。因此，任何在以太坊上创建的钱包也将在 Arbitrum 上运作，而无需采取其他任何行动。
+
+唯一的例外是智能合约钱包，比如多重签名钱包：这些是分别在每条链上部署的智能合约，并在部署时获得它们的地址。如果一个多重签名钱包部署在以太坊上，在 Arbitrum 上不会以相同的地址存在。首先必须在 Arbitrum 上创建一个新的多重签名钱包，而且可能会获得一个不同的地址。
+
+### 如果我没有在 7 天内完成转账，会发生什么情况？
+
+L2 传输工具使用 Arbitrum 的原生机制将信息从 L1 发送至 L2。这种机制被称为 "retryable ticket，所有本地令牌网桥都使用这种机制，包括Arbitrum GRT网桥。您可以在[Arbitrum文档](https://docs.arbitrum.io/arbos/l1-to-l2-messaging)中阅读更多关于retryable ticket的信息。
+
+当您将您的资产（子图、股权、委托）转移到 L2 时，会通过 Arbitrum GRT 桥接器发送一条信息，该桥接器会在 L2 中创建一个可retryable ticket。转移工具在交易中包含一些 ETH ，用于：1）支付创建票据的费用；2）支付在 L2 中执行票据的气体费用。但是，在票据准备好在 L2 中执行之前，gas价格可能会发生变化，因此自动执行尝试可能会失败。当这种情况发生时，Arbitrum 桥接器会将retryable ticket保留最多 7 天，任何人都可以重试 "赎回 "票据（这需要一个与 Arbitrum 桥接了一些 ETH 的钱包）。
+
+这就是我们在所有传输工具中所说的 "确认 "步骤--在大多数情况下，它会自动运行，因为自动执行通常都会成功，但重要的是，您要回过头来检查，以确保它成功了。如果没有成功，并且在 7 天内没有成功的重试，Arbitrum 桥接器将丢弃该票据，您的资产（子图、股权、委托或管理）将丢失且无法恢复。The Graph核心开发人员有一个监控系统来检测这些情况，并尝试在为时已晚之前赎回门票，但确保您的转让及时完成最终还是您的责任。如果您在确认交易时遇到困难，请使用[此表单](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms)联系我们，核心开发人员将为您提供帮助。
+
+### 我开始了我的委托/质押/策展转移，但不确定是否成功转移到了 Layer 2（L2），我如何确认转移是否正确进行了？
+
+如果您在个人资料中没有看到要求完成转移的横幅，那么很可能交易已经安全地转移到了 Layer 2（L2），无需采取更多操作。如果仍有疑问，您可以检查资源浏览器（Explorer），查看您在 Arbitrum One 上的委托、质押或筛选情况。
+
+如果您有 L1 交易哈希（您可以在钱包的最近交易记录中找到），您也可以确认“可重试票据”是否已在此处兑现传递到 L2 的信息：https://retryable-dashboard.arbitrum.io/ - 如果自动兑现失败，您也可以在那里连接您的钱包并兑现它。请放心，核心开发人员也在监控因某些原因被卡住的信息，并会在其到期前尝试兑现它们。
+
+## 子图转移
+
+### 如何转移我的子图？
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+要转移您的子图，您需要完成以下步骤：
+
+1. 在以太坊主网上启动转移过程
+
+2. 等待20分钟进行确认
+
+3. 在Arbitrum上确认子图转移\*
+
+4. 在Arbitrum上完成子图发布
+
+5. 更新查询URL（推荐）
+
+\*请注意，您必须在7天内确认转移，否则您的子图可能会丢失。在大多数情况下，此步骤将自动运行，但如果Arbitrum的燃气价格飙升，则可能需要手动确认。如果在此过程中遇到任何问题，我们将提供帮助：请通过support@thegraph.com或[Discord](https://discord.gg/graphprotocol)与我们联系。
+
+### 我应该从哪里发起转移？
+
+您可以从[Subgraph Studio](https://thegraph.com/studio/), [Explorer](https://thegraph.com/explorer) 或任何子图详细信息页面发起转移。在子图详细信息页面中，点击“Transfer Subgraph”按钮开始转移。
+
+### 我需要等多久才能完成子图转移？
+
+转移时间大约需要20分钟。Arbitrum跨链桥在后台工作，自动完成桥接转移。在某些情况下，燃气费用可能会上涨，您需要再次确认交易。
+
+### 在我将子图转移到L2之后，它还能被发现吗？
+
+您的子图只能在其发布所在的网络上被发现。例如，如果您的子图在Arbitrum One上，那么您只能在Arbitrum One的Explorer中找到它，而无法在以太坊上找到它。请确保您已在页面顶部的网络切换器中选择了Arbitrum One，以确保您位于正确的网络上。转移后，L1子图将显示为已弃用。
+
+### 我的子图是否需要发布才能转移？
+
+要使用子图转移工具，您的子图必须已经发布到以太坊主网上，并且拥有子图的钱包必须拥有一定的策划信号。如果您的子图尚未发布，建议您直接在Arbitrum One上进行发布-相关的燃气费用将大大降低。如果您想转移已发布的子图，但拥有该子图的所有者账户尚未对其进行任何策划信号的策展，您可以从该账户中发送一小笔金额（例如1 GRT）进行信号，确保选择“自动迁移”信号。
+
+### 我将我的子图转移到Arbitrum后，以太坊主网版本的子图会发生什么？
+
+将子图转移到Arbitrum后，以太坊主网版本的子图将被弃用。我们建议您在48小时内更新查询URL。但是，我们已经设置了一个宽限期使您的主网URL继续可用，以便更新任何第三方dapp的支持。
+
+### 转移后，我还需要在Arbitrum上重新发布吗？
+
+在20分钟的转移窗口之后，您需要通过UI中的交易确认来完成转移，但转移工具将指导您完成此过程。在转移窗口和宽限期期间，您的L1端点将继续受到支持。鼓励您在方便的时候更新您的端点。
+
+### 重新发布期间，您的端点会经历停机时间吗？
+
+这是不太可能的，但取决于在 L1 上支持子图的索引人以及他们是否一直进行索引直到子图在 L2 上完全受支持，可能会经历短暂的停机时间。
+
+### L2上的发布和版本控制与以太坊主网上相同吗？
+
+是的。请确保在Subgraph Studio中选择Arbitrum One作为您的发布网络。在Studio中，将提供最新的端点，指向子图的最新更新版本。
+
+### 我的子图的策展是否会随着子图一起转移？
+
+如果您选择了自动迁移信号，您自己的全部策展将与子图一起转移到Arbitrum One。在转移时，所有子图的策展信号将转换为GRT，并且与您的策展信号相对应的GRT将用于在L2子图上生成信号。
+
+其他策展人可以选择是否撤回他们的一部分GRT，或者将其转移到L2上，在同一子图上生成信号。
+
+### 在将子图转移到Arbitrum后，我能否将其转回以太坊主网？
+
+一旦转移，您的以太坊主网版本的子图将被弃用。如果您想转回主网，您需要重新部署并发布到主网。然而，强烈不建议再次转移到以太坊主网，因为索引奖励最终将完全在Arbitrum One上分发。
+
+### 为什么在完成转移时需要桥接ETH？
+
+在Arbitrum One上支付的燃气费用使用桥接ETH（即已桥跨链到Arbitrum One的ETH）支付。但是，与以太坊主网相比，燃气费用要低得多。
+
+## 委托
+
+### 如何转移我的委托？
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+要转移你的委托，你需要完成以下步骤：
+
+1. 在以太坊主网上启动委托转移
+2. 等待20分钟进行确认
+3. 在Arbitrum上确认委托转移
+
+\*\*\*\*请注意，您必须在7天内确认转移，否则您的子图可能会丢失。在大多数情况下，此步骤将自动运行，但如果Arbitrum的燃气价格飙升，则可能需要手动确认。如果在此过程中遇到任何问题，我们将提供帮助：请通过support@thegraph.com或[Discord](https://discord.gg/graphprotocol)与我们联系。
+
+### 如果我在以太坊主网上有未完成的分配，我的奖励会怎样？
+
+如果你将委托转移到 Arbitrum 时，你将放弃来自以太坊主网上的未完成分配的委托奖励。这意味着你将失去最多最近28天的奖励。如果你在索引人关闭分配后的合适时间转移，你可以确保损失的奖励最少。如果你与你的索引人保持沟通，可以考虑与他们讨论以找到最佳转移时间。
+
+### 如果我当前委托的索引人不在 Arbitrum One 上怎么办？
+
+只有你委托的索引人将自己的质押转移到 Arbitrum 后，L2 转移工具才会启用。
+
+### 委托人是否可以选择委托给其他索引人？
+
+如果您希望将委派权转移给另一个索引人，您可以将其转移到 Arbitrum 上的同一索引人，然后取消委派并等待解冻期。在此之后，您可以选择另一个活跃的索引人进行委派。
+
+### 如果我在 L2 上找不到要委派的索引人怎么办？
+
+L2 转移工具将自动检测您先前委派的索引人。
+
+### 我是否可以将委派分散在新的或多个索引人上，而不是之前的索引人？
+
+L2 转移工具将始终将您的委托转移到您先前委托的同一索引人。一旦您转移到 L2，您可以取消委托，等待解冻期，并决定是否要分散您的委托。
+
+### 在使用 L2 委托转移工具后，我是否需要等待冷却期才能提款，还是可以立即提款？
+
+转移工具允许您立即转移到 L2。如果您想取消委托，您将需要等待解冻期。但是，如果一个指标者已经将他们的全部股份转移到 L2 上，您可以立即在以太坊主网上提款。
+
+### 如果我不转移委托是否会对我的奖励产生负面影响？
+
+预计所有网络参与者将来都会转移到 Arbitrum One。
+
+### 完成委托转移到 L2 需要多长时间？
+
+委托转移需要 20 分钟的确认时间。请注意，在 20 分钟的时间结束后，您必须返回并在 7 天内完成转移过程的第三步。如果未能这样做，您的委托可能会丢失。大多数情况下，转移工具将自动完成此步骤。如果自动尝试失败，您将需要手动完成。如果在此过程中遇到任何问题，不要担心，我们会在这里提供帮助：通过电子邮件 (support email address) 或 [Discord](https://discord.gg/vtvv7FP)上的 (channel) 渠道与我们联系。
+
+### 如果我使用的是 GRT 质押合约/代币锁定钱包，我可以转移委托吗？
+
+可以！由于解锁合约（vesting contracts）无法转发用于支付 L2 交易费用的 ETH，所以流程略有不同，你需要事先存入所需的 ETH。如果你的解锁合约尚未完全解锁，你还需要在 L2 上先初始化一个对应的解锁合约，并且只能将质押转移到此 L2 解锁合约。Explorer 上的用户界面可以指导你在使用解锁钱包（vesting lock wallet）连接到 Explorer 时完成这个过程。
+
+### 您的 Arbitrum 解锁合约是否允许像在主网上一样释放 GRT 呢？
+
+不，Arbitrum 上创建的解锁合约不会允许释放任何 GRT，直到到达解锁时间轴的结束，也就是直到您的合约完全解锁。这是为了防止双重支出，否则同样的金额可以在两个层级上释放。
+
+如果您想要从解锁合约中释放 GRT，您可以使用资源管理器将其转移回 L1 的解锁合约：在您的 Arbitrum One 个人资料中，您会看到一个横幅，指示您可以将 GRT 转移回主网的解锁合约。这需要在 Arbitrum One 上进行一笔交易，等待 7 天，并在主网上进行最终交易，因为它使用了来自 GRT 跨链桥的相同本地桥接机制。
+
+### 是否需要支付任何委托税？
+
+不需要。在 L2 上收到的代币将以指定的委托人名义委托给指定的索引人，而无需收取委托税。
+
+### 当我转移我的委托时，我的未实现奖励会被一起转移吗？
+
+是的！唯一无法转移的奖励是针对未结束的分配的奖励，因为这些奖励直到索引人关闭分配（通常每 28 天一次）后才会存在。如果您已经进行了一段时间的委托，这可能只是奖励的一小部分。
+
+在智能合约层面，未实现的奖励已经计入了您的委托余额，因此当您将委托转移到 L2 时，这些奖励将会一并转移。
+
+### 将委托转移到 L2 是否是强制性的？有截止日期吗？
+
+将委托转移到 L2 并非强制性的，但根据 [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193)，L2 上的索引奖励会逐步增加。最终，如果委员会继续批准这些增加，所有奖励将在 L2 上分发，而在 L1 上将不再有索引奖励供索引人和委托人获取。
+
+### 如果我正在委托给已经将质押转移到 L2 的索引人，那么我是否在 L1 上停止接收奖励？
+
+许多索引人正在逐步转移质押，因此在 L1 上的索引人仍将在 L1 上赚取奖励和费用，然后与委托人分享。一旦索引人全部转移了他们的质押，那么他们将停止在 L1 上运行，因此委托人将不再收到任何奖励，除非他们转移到 L2。
+
+最终，如果委员会继续批准在 L2 上增加索引奖励，所有奖励将在 L2 上分发，而在 L1 上将不再有索引人和委托人的索引奖励。
+
+### 我看不到转移我的委托的按钮。为什么会这样？
+
+很可能是您的索引人尚未使用 L2 转移工具来转移质押。
+
+如果您可以联系索引人，可以鼓励他们使用 L2 转移工具，以便委托人可以将委托转移到他们在 L2 上的索引人地址。
+
+### 我的索引人也在Arbitrum上，但我在个人资料中没有看到转移委托的按钮。为什么会这样呢？
+
+可能是索引人在二层网络（L2）设置了操作，但尚未使用L2转账工具来转移质押。因此，一层网络（L1）的智能合约将不知晓索引人的L2地址。如果您可以联系到索引人，可以鼓励他们使用转账工具，以便委托人能够将委托转移到他们的L2索引人地址。
+
+### 如果我已经开始取消委托流程但尚未撤回委托，我能将我的委托转移到二层吗？
+
+不可以。如果您的委托正在解冻，您必须等待 28 天并撤回委托。
+
+正在取消委托的代币是“锁定”的，因此无法转移到二层。
+
+## 策展信号
+
+### 如何转移我的策展信号？
+
+要转移您的策展信号，您需要完成以下步骤：
+
+1. 在以太坊主网上启动信号转移
+
+2. 指定L2策展者地址\*
+
+3. 等待20分钟进行确认
+
+\*如果需要-即您正在使用合约地址。
+
+### 我如何知道我策展的子图已经转移到L2？
+
+在查看子图详细信息页面时，将显示一个横幅，通知您该子图已转移。您可以按照提示进行策展转移。您还可以在已转移的任何子图的子图详细信息页面上找到此信息。
+
+### 如果我不希望将我的策展转移到L2怎么办？
+
+当子图被弃用时，您可以选择撤回您的信号。同样，如果子图转移到L2，您可以选择在以太坊主网上撤回信号，或将信号发送到L2。
+
+### 如何知道我的策展是否成功转移？
+
+信号详细信息将在大约20分钟后通过Exploer可访问。
+
+### 我可以一次在多个子图上转移我的策展吗？
+
+目前没有批量转移选项。
+
+## 索引人质押
+
+### 如何将我的质押转移到Arbitrum？
+
+> 免责声明：如果您目前正在取消索引人上的任何 GRT 部分，则无法使用 L2 转移工具。
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+要转移您的质押，您需要完成以下步骤：
+
+1. 在以太坊主网上启动转移过程
+
+2. 等待20分钟进行确认
+
+3. 在Arbitrum上确认质押转移
+
+\*请注意，您必须在7天内确认转移，否则您的子图可能会丢失。在大多数情况下，此步骤将自动运行，但如果Arbitrum的燃气价格飙升，则可能需要手动确认。如果在此过程中遇到任何问题，我们将提供帮助：请通过support@thegraph.com或[Discord](https://discord.gg/graphprotocol)与我们联系。
+
+### 我所有的质押都会转移吗
+
+您可以选择转移多少质押。如果您选择一次性转移所有质押，您必须先关闭任何未完成的分配。
+
+如果您计划在多个交易中转移部分质押，您必须始终指定相同的受益人地址。
+
+注意：首次使用转移工具时，您必须满足L2的最低质押要求。索引器在首次调用此函数时必须发送最低的100,000个GRT（当调用此函数时）。如果将部分质押留在L1上，它也必须超过100,000个GRT的最低要求，并足以（与您的委托一起）覆盖您的未完成分配。
+
+### 确认质押转移至Arbitrum的时间限制是多久？
+
+\*\*\*您必须确认交易以完成Arbitrum上的质押转移。此步骤必须在7天内完成，否则可能会丢失质押。
+
+### 如果我有未完成的分配会怎么样？
+
+如果您不发送全部质押，L2转移工具将验证以太坊主网上至少保留了最低的100,000个GRT，并且您的剩余质押和委托足以覆盖任何未完成的分配。如果您的GRT余额不足以支付最低要求+未完成的分配，您可能需要关闭未完成的分配。
+
+### 使用转移工具，在以太坊主网上进行转移之前，是否需要等待28天解除质押？
+
+不需要，在使用转移工具之前，你可以立即将你的质押转移到 L2（即 Arbitrum），无需解除质押并等待。28天的等待期仅适用于如果你想要将质押提取回你的钱包，无论是在以太坊主网还是 L2 上。
+
+### 转移质押需要多长时间？
+
+转移质押的过程大约需要20分钟，L2 转移工具将完成质押的转移。
+
+### 在转移质押之前，我是否需要在 Arbitrum 上进行索引（indexing）？
+
+你可以在转移质押之前先有效地进行转移，但在你在 L2 上分配和索引子图之前，你将无法领取 L2 上的任何奖励。要在 L2 上领取奖励，你需要在 L2 上分配子图、对其进行索引并提供 POI。
+
+### 在我转移索引质押之前，委托人是否可以转移他们的委托？
+
+否，为了使委托人能够将他们的委托 GRT 转移到 Arbitrum，他们委托的索引人必须在 L2 上活动。
+
+### 如果我使用 GRT 解锁合约（GRT vesting contract）/令牌锁定钱包，我可以转移质押吗？
+
+可以！由于解锁合约（vesting contracts）无法转发用于支付 L2 交易费用的 ETH，所以流程略有不同，你需要事先存入所需的 ETH。如果你的解锁合约尚未完全解锁，你还需要在 L2 上先初始化一个对应的解锁合约，并且只能将质押转移到此 L2 解锁合约。Explorer 上的用户界面可以指导你在使用解锁钱包（vesting lock wallet）连接到 Explorer 时完成这个过程。
+
+### 我已经在L2有质押。当我第一次使用转移工具时，是否仍需要发送 100,000 GRT？
+
+是的。L1的智能合约不会知晓你在L2的质押，因此当你第一次转移时，它们会要求你至少转移 100,000 GRT。
+
+### 如果我正在取消质押 GRT，是否可以同时将我的质押转移到L2？
+
+不行。如果您的任何一部分质押正在解冻，您必须等待 28 天并在转移质押之前将其撤回。正在质押的代币是“锁定”的，会阻止任何转移或质押到L2。
+
+## 解锁合约转移
+
+### 如何转移我的解锁合约？
+
+要转移您的解锁合约，您需要完成以下步骤：
+
+1. 在以太坊主网上发起解锁合约转移
+
+2. 等待20分钟进行确认
+
+3. 在 Arbitrum 上确认解锁合约转移
+
+### 如果我只有部分解锁完成，如何转移我的解锁合约？
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. 向转移工具合约存入一些以太币（用户界面可以帮助估算合理的金额）
+
+2. 通过转移工具合约将一些被锁定的 GRT 发送到 L2，以初始化 L2 解锁合约。这也将设置它们的 L2 受益人地址。
+
+3. 通过 L1Staking 合约中的“locked”转移工具函数将质押/委托转移到 L2。
+
+4. 从转移工具合约中提取剩余的以太币
+
+### 如果我的份额已经全部解锁，如何转移我的解锁合约？
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+对于已完全完成解锁的用户，流程类似：
+
+1. 向转移工具合约存入一些以太币（用户界面可以帮助估算合理的金额）
+
+2. 通过调用转移工具合约设置您的 L2 地址
+
+3. 通过 L1Staking 合约中的“locked”转移工具函数将质押/委托转移到 L2。
+
+4. 从转移工具合约中提取剩余的以太币
+
+### 我可以将我的解锁合约转移到 Arbitrum 吗？
+
+您可以将解锁合约的 GRT 余额转移到 L2 上的解锁合约。这是将您的解锁合约的质押或委托转移到 L2 的先决条件。解锁合约必须持有非零数量的 GRT（如果需要，您可以向其转移少量的 GRT，如 1 GRT）。
+
+当您将 GRT 从 L1 解锁合约转移到 L2 时，您可以选择要发送的数量，并且可以多次进行此操作。首次转移 GRT 时，L2 解锁合约将初始化。
+
+这些转移操作使用转移工具完成，当您使用质押锁定账户连接到 Explorer 时，转移工具将在您的 Explorer 个人资料上可见。
+
+请注意，您将无法在 L2 解锁合约结束您的质押时间线之前提取/撤回 GRT。如果您在此之前需要释放 GRT，您可以使用另一个专门用于此目的的转移工具将 GRT 转回 L1 解锁合约。
+
+如果您尚未将任何解锁合约余额转移到 L2 上，并且您的解锁合约已完全完成，您不应将解锁合约转移到 L2。相反，您可以使用转移工具设置一个 L2 钱包地址，并直接将您的质押或委托转移到 L2 上的常规钱包。
+
+### 我正在使用解锁合约在主网上质押。我可以将我的质押转移到 Arbitrum 吗？
+
+是的，但如果您的合约仍在解锁中，您只能将质押转移到由您的 L2 解锁合约拥有的地址。您必须先通过 Explorer 上的解锁合约转移工具将一些 GRT 余额转移到 L2 来初始化此 L2 合约。如果您的合约已完全解锁，您可以将质押转移到 L2 中的任何地址，但您必须事先设置好，并存入一些 ETH 以支付 L2 转移工具的 L2 gas 费用。
+
+### 我在使用解锁合约在主网上委托。我可以将我的委托转移到 Arbitrum 吗？
+
+是的，但如果您的合约仍在解锁中，您只能将委托转移到由您的 L2 解锁合约拥有的地址。您必须先通过 Explorer 上的解锁合约转移工具将一些 GRT 余额转移到 L2 来初始化此 L2 合约。如果您的合约已完全解锁，您可以将委托转移到 L2 中的任何地址，但您必须事先设置好，并存入一些 ETH 以支付 L2 转移工具的 L2 gas 费用
+
+### 我可以为我的解锁合约在 L2 上指定不同的受益人吗？
+
+是的，在首次转移余额并设置您的 L2 解锁合约时，您可以指定一个 L2 受益人。请确保该受益人是一个可以在 Arbitrum One 上执行交易的钱包，即它必须是一个 EOA（外部所有者账户）或一个在 Arbitrum One 上部署的多签钱包。
+
+如果您的合约已完全解锁，您将不会在 L2 上设置解锁合约；相反，您将设置一个 L2 钱包地址，该地址将接收您在 Arbitrum 上的质押或委托。
+
+### 我的合约已完全解锁。我可以将我的质押或委托转移到非 L2 解锁合约的其他地址吗？
+
+是的。如果您尚未将任何解锁合约余额转移到 L2 上，并且您的解锁合约已完全解锁，您不应将解锁合约转移到 L2。相反，您可以使用转移工具设置一个 L2 钱包地址，并直接将您的质押或委托转移到 L2 上的常规钱包。
+
+这样可以使您将质押或委托转移到 L2 上的任何地址。
+
+### 我的解锁合约仍在解锁中。如何将解锁合约余额转移到 L2？
+
+以下步骤仅适用于您的合约仍在解锁中的情况，或者在您的合约仍在解锁中时使用此过程。
+
+要将解锁合约转移到 L2，您将使用转移工具将任何 GRT 余额发送到 L2，该工具将初始化您的 L2 解锁合约：
+
+1. 向转移工具合约存入一些以太币（用于支付 L2 gas）
+
+2. 撤销对解锁合约的协议访问权限（需要进行下一步）
+
+3. 授予解锁合约协议访问权限（将允许您的合约与转移工具进行交互）
+
+4. 指定 L2 受益人地址\*，并在以太坊主网上发起余额转移
+
+5. 等待20分钟进行确认
+
+6. 在 L2 上确认余额转移
+
+\*如果需要-即您正在使用合约地址。
+
+\*\*\*\*请注意，您必须在7天内确认转移，否则您的子图可能会丢失。在大多数情况下，此步骤将自动运行，但如果Arbitrum的燃气价格飙升，则可能需要手动确认。如果在此过程中遇到任何问题，我们将提供帮助：请通过support@thegraph.com或[Discord](https://discord.gg/graphprotocol)与我们联系。
+
+### 我的解锁合约显示为 0 GRT，因此无法进行转移，请问是什么原因，以及如何解决？
+
+为了初始化您的 L2 解锁合约，您需要将非零数量的 GRT 转移到 L2。这是由 L2 转移工具使用的 Arbitrum GRT 桥所要求的。GRT 必须来自解锁合约的余额，因此不包括质押或委托的 GRT。
+
+如果您已经从解锁合约中质押或委托了所有的 GRT，您可以手动从其他地方（例如另一个钱包或交易所）向解锁合约地址发送小额资金，比如 1 GRT。
+
+### 我正在使用解锁合约进行质押或委托，但我没有看到将我的质押或委托转移到L2的按钮，我该怎么办？
+
+如果您的解锁合约尚未完成解锁，您需要首先创建一个 L2 解锁合约，用于在二层接收您的质押或委托。该解锁合约在二层不允许在解锁时间段结束之前释放代币，但允许您将 GRT 转移回 L1 解锁合约以在那里释放。
+
+当在资源管理平台（Explorer）中连接到解锁合约时，您应该会看到初始化您的 L2 解锁合约的按钮。首先按照该流程操作，然后您就能在个人资料中看到转移您的质押或委托的按钮。
+
+### 初始化我的 L2 解锁合约会自动将我的委托转移到 L2 吗？
+
+不，初始化您的 L2 解锁合约是从解锁合约转移质押或委托的先决条件，但您仍需要分别进行这些转移。
+
+在您初始化了 L2 解锁合约后，您会在个人资料上看到一个提示横幅，指示您转移您的质押或委托。
+
+### 我可以将我的解锁合约转移到 L1 吗？
+
+没有必要这样做，因为您的解锁合约仍在 L1 上。当您使用转移工具时，您只是在 L2 上创建一个与您的 L1 解锁合约连接的新合约，您可以在两者之间自由发送 GRT。
+
+### 为什么我需要转移我的解锁合约？
+
+您需要设置一个 L2 解锁合约，以便该账户可以在 L2 上拥有您的质押或委托。否则，您将无法在不“逃离”解锁合约的情况下将质押/委托转移到 L2。
+
+### 如果我尝试在解锁未完全完成时兑现我的合约会发生什么？这可能吗？
+
+这是不可能的。您可以将资金转回 L1 并在那里提取。
+
+### 如果我不想将我的解锁合约转移到 L2 怎么办？
+
+您可以继续在 L1 上进行质押/委托。随着协议在 Arbitrum 上的扩展和时间的推移，您可能希望考虑转移到 L2 以启用那里的奖励。请注意，这些转移工具适用于允许在协议中进行质押或委托的解锁合约。如果您的合约不允许质押或委托，或者可以撤销，则没有可用的转移工具。您仍然可以在可用时从 L1 提取 GRT。

From fdbc24867aab746979e8de330daebbb93350ba79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:02:59 -0500
Subject: [PATCH 1039/3820] New translations l2-transfer-tools-faq.mdx (Urdu
 (Pakistan))

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 412 ++++++++++++++++++
 1 file changed, 412 insertions(+)
 create mode 100644 website/pages/ur/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/ur/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/ur/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..174e645fb2d0
--- /dev/null
+++ b/website/pages/ur/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,412 @@
+---
+title: |
+  L2 ٹرانسفر ٹولز اکثر پوچھے گئے سوالات
+---
+
+## General
+
+### L2 ٹرانسفر ٹولز کیا ہیں؟
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### کیا میں وہی والیٹ استعمال کر سکتا ہوں جو میں ایتھیریم مین نیٹ پر استعمال کرتا ہوں؟
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### اگر میں 7 دن میں اپنی منتقلی مکمل نہیں کر پاتا تو کیا ہو گا؟
+
+L2 ٹرانسفر ٹول L1 کو پیغامات بھیجنے کے لیے Arbitrum کا مقامی طریقہ استعمال کرتے ہیں۔ اس طریقہ کار کو "ریٹری ایبل ٹکٹ" کہا جاتا ہے اور اس کا استعمال تمام مقامی ٹوکن برجز بشمول Arbitrum GRT بریج کے ذریعے کیا جاتا ہے۔ آپ دوبارہ قابل کوشش ٹکٹوں کے بارے میں مزید پڑھ سکتے ہیں [Arbitrum دستاویزات](https://docs.arbitrum.io/arbos/l1-to-l2-messaging) میں۔
+
+جب آپ اپنے اثاثے (سب گراف، سٹیک، ڈیلیگیشن یا کیوریشن) L2 پر منتقل کرتے ہیں، تو Arbitrum GRT بریج کے ذریعے ایک پیغام بھیجا جاتا ہے جو L2 میں دوبارہ ریٹری ایبل ٹکٹ بناتا ہے۔ ٹرانسفر ٹول میں ٹرانزیکشن میں کچھ ایتھیریم ویلیو شامل ہوتی ہے، جس کا استعمال 1) ٹکٹ بنانے کے لیے ادائیگی اور 2) L2 میں ٹکٹ کو انجام دینے کے لیے گیس کی ادائیگی کے لیے کیا جاتا ہے۔ تاہم، چونکہ L2 میں ٹکٹ کے مکمل ہونے کے لیے تیار ہونے تک گیس کی قیمتیں مختلف ہو سکتی ہیں، اس لیے یہ ممکن ہے کہ خودکار طریقے سے عمل درآمد کی یہ کوشش ناکام ہو جائے۔ جب ایسا ہوتا ہے، تو Arbitrum بریج دوبارہ کوشش کے قابل ٹکٹ کو 7 دنوں تک زندہ رکھے گا، اور کوئی بھی ٹکٹ کو "چھڑانے" کی دوبارہ کوشش کر سکتا ہے (جس کے لیے Arbitrum کے لیے کچھ ایتھیریم والے والیٹ کی ضرورت ہوتی ہے)۔
+
+اسے ہم منتقلی کے تمام ٹولز میں "تصدیق" مرحلہ کہتے ہیں - یہ زیادہ تر معاملات میں خود بخود چلے گا، کیونکہ خود کار طریقے سے عمل اکثر کامیاب ہوتا ہے، لیکن یہ ضروری ہے کہ آپ اس بات کو یقینی بنانے کے لیے دوبارہ چیک کریں۔ اگر یہ کامیاب نہیں ہوتا ہے اور 7 دنوں میں کوئی کامیاب کوشش نہیں ہوتی ہے، تو Arbitrum بریج ٹکٹ کو رد کر دے گا، اور آپ کے اثاثے (سب گراف، سٹیک، ڈیلیگیشن یا کیوریشن) ضائع ہو جائیں گے اور بازیافت نہیں ہو سکیں گے۔ گراف کور ڈویلپرز کے پاس ان حالات کا پتہ لگانے کے لیے ایک نگرانی کا نظام موجود ہے اور بہت دیر ہونے سے پہلے ٹکٹوں کو چھڑانے کی کوشش کریں، لیکن یہ یقینی بنانا آپ کی ذمہ داری ہے کہ آپ کی منتقلی بروقت مکمل ہو جائے۔ اگر آپ کو اپنے ٹرانزیکشن کی تصدیق کرنے میں دشواری ہو رہی ہے، تو براہ کرم [اس فارم](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) اور کور ڈویلپرز کا استعمال کرتے ہوئے رابطہ کریں۔ وہاں آپ کی مدد ہو گی.
+
+### میں نے اپنا ڈیلیگیشن/سٹیک/کیوریشن کی منتقلی شروع کی ہے اور مجھے یقین نہیں ہے کہ آیا یہ L2 تک پہنچا ہے، میں کیسے تصدیق کر سکتا ہوں کہ اسے صحیح طریقے سے منتقل کیا گیا تھا؟
+
+اگر آپ کو اپنے پروفائل پر کوئی بینر نظر نہیں آتا ہے جس میں آپ سے منتقلی مکمل کرنے کے لیے کہا گیا ہو، تو امکان ہے کہ ٹرانزیکشن نے اسے محفوظ طریقے سے L2 تک پہنچا دیا ہے اور مزید کارروائی کی ضرورت نہیں ہے۔ اگر شک ہو تو، آپ چیک کر سکتے ہیں کہ آیا ایکسپلورر آپ کی ڈیلیگیشن، سٹیک یا کیوریشن Arbitrum One پر دکھاتا ہے۔
+
+اگر آپ کے پاس L1 ٹرانزیکشن ہیش ہے (جسے آپ اپنے والیٹ میں حالیہ ٹرانزیکشن کو دیکھ کر تلاش کر سکتے ہیں)، تو آپ اس بات کی بھی تصدیق کر سکتے ہیں کہ آیا L2 پر پیغام پہنچانے والے "دوبارہ کوشش کے قابل ٹکٹ" کو یہاں سے چھڑا لیا گیا تھا: https://retryable-dashboard .arbitrum.io/ - اگر خودکار نکالنا ناکام ہو جاتا ہے، تو آپ اپنے والیٹا کو وہاں بھی کنیکٹ کر کے اسے نکال سکتے ہیں۔ یقین رکھیں کہ بنیادی ڈویلپرز ان پیغامات کی بھی نگرانی کر رہے ہیں جو پھنس گئے ہیں، اور ان کی میعاد ختم ہونے سے پہلے انہیں نکالنے کی کوشش کریں گے۔
+
+## سب گراف منتقلی
+
+### میں اپنا سب گراف کیسے منتقل کروں؟
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+اپنے سب گراف کو منتقل کرنے کے لیے، آپ کو درج ذیل مراحل کو مکمل کرنے کی ضرورت ہو گی:
+
+1. ایتھیریم مین نیٹ پر منتقلی شروع کریں
+
+2. تصدیق کے لیے 20 منٹ انتظار کریں
+
+3. Arbitrum پر سب گراف منتقلی کی تصدیق کریں\*
+
+4. Arbitrum پر سب گراف کی اشاعت مکمل کریں
+
+5. کیوری لنک اپ ڈیٹ کریں (تجویز کردہ)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### مجھے اپنی منتقلی کہاں سے شروع کرنی چاہیے؟
+
+آپ اپنی منتقلی کو [سب گراف سٹوڈیو](https://thegraph.com/studio/)، [ایکسپلورر](https://thegraph.com/explorer) یا کسی بھی سب گراف کی تفصیلات کے پیج سے شروع کر سکتے ہیں۔ منتقلی شروع کرنے کے لیے سب گراف کی تفصیلات کے پیج میں "سب گراف منتقل کریں" بٹن کلک کریں۔
+
+### میرا سب گراف منتقل ہونے تک مجھے کتنا انتظار کرنا پڑے گا
+
+منتقلی کا وقت تقریباً 20 منٹ لگتا ہے۔ Arbitrum بریج کی منتقلی کو خود بخود مکمل کرنے کے لیے پس منظر میں کام کر رہا ہے۔ کچھ معاملات میں، گیس کی قیمتیں بڑھ سکتی ہیں اور آپ کو دوبارہ ٹرانزیکشن کی تصدیق کرنی ہوگی.
+
+### کیا میرا سب گراف L2 میں منتقل کرنے کے بعد بھی قابل دریافت ہو گا؟
+
+آپ کا سب گراف صرف اس نیٹ ورک پر قابل دریافت ہوگا جس پر اسے شائع کیا گیا ہے۔ مثال کے طور پر، اگر آپ کا سب گراف Arbitrum One پر ہے، تو آپ اسے صرف Arbitrum One پر ایکسپلورر میں تلاش کر سکتے ہیں اور اسے ایتھیریم پر تلاش نہیں کر پائیں گے۔ براہ کرم یقینی بنائیں کہ آپ نے نیٹ ورک سوئچر میں پیج کے اوپری حصے میں Arbitrum One کا انتخاب کیا ہے تاکہ یہ یقینی بنایا جا سکے کہ آپ درست نیٹ ورک پر ہیں۔ منتقلی کے بعد، L1 سب گراف فرسودہ کے طور پر ظاہر ہوگا.
+
+### کیا میرے سب گراف کو منتقل کرنے کے لیے اسے شائع کرنے کی ضرورت ہے؟
+
+سب گراف ٹرانسفر ٹول سے فائدہ اٹھانے کے لیے، آپ کا سب گراف پہلے سے ہی ایتھیریم مین نیٹ پر شائع ہونا چاہیے اور اس میں کچھ کیوریشن سگنل ہونا چاہیے جو والیٹ کی ملکیت ہے جو سب گراف کا مالک ہے۔ اگر آپ کا سب گراف شائع نہیں ہوا ہے، تو یہ تجویز کیا جاتا ہے کہ آپ براہ راست Arbitrum One پر شائع کریں - متعلقہ گیس کی فیسیں کافی کم ہوں گی۔ اگر آپ شائع شدہ سب گراف کو منتقل کرنا چاہتے ہیں لیکن مالک کے اکاؤنٹ نے اس پر کوئی سگنل کیوریٹ نہیں کیا ہے، تو آپ اس اکاؤنٹ سے ایک چھوٹی رقم (جیسے 1 GRT) کا اشارہ دے سکتے ہیں۔ یقینی بنائیں کہ "خودکار منتقلی" سگنل کا انتخاب کریں.
+
+### میرے سب گراف کے ایتھیریم مین نیٹ ورزن کا کیا ہوتا ہے جب میں Arbitrum میں منتقل ہو جاتا ہوں؟
+
+آپ کے سب گراف کو Arbitrum میں منتقل کرنے کے بعد، ایتھیریم مین نیٹ ورزن فرسودہ ہو جائے گا۔ ہمارا مشورہ ہے کہ آپ 48 گھنٹوں کے اندر اپنے کیوری کے لنک کو اپ ڈیٹ کریں۔ تاہم، ایک رعایتی مدت موجود ہے جو آپ کے مین نیٹ لنک کو کام میں لاتی رہتی ہے تاکہ کسی بھی فریق ثالث ڈیپ سپورٹ کو اپ ڈیٹ کیا جا سکے۔
+
+### میری منتقلی کے بعد، کیا مجھے بھی Arbitrum پر دوبارہ شائع کرنے کی ضرورت ہے؟
+
+20 منٹ کی ٹرانسفر ونڈو کے بعد، آپ کو ٹرانسفر کو ختم کرنے کے لیے UI میں ٹرانزیکشن کے ساتھ ٹرانسفر کی تصدیق کرنی ہوگی، لیکن ٹرانسفر ٹول اس میں آپ کی رہنمائی کرے گا۔ آپ کا L1 اینڈ پوائنٹ ٹرانسفر ونڈو اور اس کے بعد ایک رعایتی مدت کے دوران تعاون کرتا رہے گا۔ یہ حوصلہ افزائی کی جاتی ہے کہ جب آپ کے لیے آسان ہو تو آپ اپنا اینڈ پوائنٹ اپ ڈیٹ کریں.
+
+### کیا دوبارہ شائع کرنے کے دوران میرا اینڈ پوائنٹ ڈاؤن ٹائم کا تجربہ کرے گا؟
+
+اس بات کا امکان نہیں ہے، لیکن اس بات پر منحصر ہے کہ انڈیکسرز L1 پر سب گراف کو سپورٹ کر رہے ہیں اور کیا وہ اس کو انڈیکس کرتے رہیں گے جب تک کہ L2 پر سب گراف مکمل طور پر سپورٹ نہ ہو جائے، مختصر وقت کا تجربہ کرنا ممکن ہے۔
+
+### کیا L2 پر اشاعت اور ورزن ایتھیریم مین نیٹ کی طرح ہے؟
+
+جی ہاں. سب گراف سٹوڈیو میں شائع کرتے وقت اپنے شائع شدہ نیٹ ورک کے طور پر Arbitrum One کو منتخب کریں۔ سٹوڈیو میں، تازہ ترین اختتامی نقطہ دستیاب ہوگا جو سب گراف کے تازہ ترین اپ ڈیٹ شدہ ورژن کی طرف اشارہ کرتا ہے۔
+
+### کیا میرے سب گراف کا کیوریشن میرے سب گراف کے ساتھ منتقل ہو جائے گا؟
+
+اگر آپ نے خودکار منتقلی کے سگنل کا انتخاب کیا ہے، تو آپ کی اپنی کیوریشن کا 100% حصہ آپ کے سب گراف کے ساتھ Arbitrum One میں منتقل ہو جائے گا۔ منتقلی کے وقت سب گراف کے تمام کیوریشن سگنل کو GRT میں تبدیل کر دیا جائے گا، اور آپ کے کیوریشن سگنل کے مطابق GRT L2 سب گراف پر سگنل منٹ کے لیے استعمال کیا جائے گا.
+
+دوسرے کیوریٹرز یہ انتخاب کر سکتے ہیں کہ آیا GRT کا اپنا حصہ واپس لینا ہے، یا اسی سب گراف پر اسے L2 پر منٹ سگنل پر منتقل کرنا ہے۔
+
+### کیا میں منتقلی کے بعد اپنے سب گراف کو واپس ایتھیریم مین نیٹ پر منتقل کر سکتا ہوں؟
+
+ایک بار منتقل ہونے کے بعد، اس سب گراف کا آپ کا ایتھیریم مین نیٹ ورزن فرسودہ ہو جائے گا۔ اگر آپ مین نیٹ پر واپس جانا چاہتے ہیں، تو آپ کو مین نیٹ پر دوبارہ تعینات اور شائع کرنے کی ضرورت ہوگی۔ تاہم، ایتھیریم مین نیٹ پر واپس منتقلی کی سختی سے حوصلہ شکنی کی جاتی ہے کیونکہ انڈیکسنگ انعامات بالآخر Arbitrum One پر مکمل طور پر تقسیم کیے جائیں گے.
+
+### مجھے اپنی منتقلی مکمل کرنے کے لیے پریجڈ ایتھیریم کی ضرورت کیوں ہے؟
+
+Arbitrum One پر گیس فیس بریجڈ ایتھیریم (یعنی ایتھیریم جسے Arbitrum One پر بریج کیا گیا ہے) کا استعمال کرتے ہوئے ادا کیا جاتا ہے۔ تاہم، ایتھیریم مین نیٹ کے مقابلے میں گیس فیس نمایاں طور پر کم ہے۔
+
+## ڈیلیگیشن
+
+### میں اپنی ڈیلیگیشن کیسے منتقل کر سکتا ہوں؟
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+اپنی ڈیلیگیشن منتقل کرنے کے لیے، آپ کو درج ذیل مراحل کو مکمل کرنے کی ضرورت ہو گی:
+
+1. ایتھیریم مین نیٹ پر ڈیلیگیشن کی منتقلی شروع کریں
+2. تصدیق کے لیے 20 منٹ انتظار کریں
+3. Arbitrum پر ڈیلیگیشن کی منتقلی کی تصدیق کریں
+
+\*\*\*\* Arbitrum پر ڈیلیگیشن کی منتقلی کو مکمل کرنے کے لیے آپ کو ٹرانزیکشن کی تصدیق کرنی ہوگی۔ یہ مرحلہ 7 دنوں کے اندر مکمل ہونا چاہیے ورنہ ڈیلیگیشن ضائع ہو سکتا ہے۔ زیادہ تر معاملات میں، یہ مرحلہ خود بخود چلے گا، لیکن اگر Arbitrum پر گیس کی قیمت میں اضافہ ہوتا ہے تو دستی تصدیق کی ضرورت ہو سکتی ہے۔ اگر اس عمل کے دوران کوئی مسئلہ درپیش ہے، تو مدد کے لیے وسائل موجود ہوں گے: support@thegraph.com پر یا [ڈسکورڈ](https://discord.gg/graphprotocol) پر سپورٹ سے رابطہ کریں۔.
+
+### اگر میں ایتھیریم مین نیٹ پر کھلی مختص کے ساتھ منتقلی شروع کرتا ہوں تو میرے انعامات کا کیا ہوگا؟
+
+اگر انڈیکسر جس کو آپ ڈیلیگیٹ کر رہے ہیں وہ اب بھی L1 پر کام کر رہا ہے، جب آپ Arbitrum میں منتقل کرتے ہیں تو آپ ایتھیریم مین نیٹ پر کھلی مختص سے کسی بھی ڈیلیگیشن کے انعامات کو ضائع کر دیں گے۔ اس کا مطلب ہے کہ آپ زیادہ سے زیادہ، آخری 28 دن کی مدت کے انعامات سے محروم ہو جائیں گے۔ اگر آپ انڈیکسر کے مختص بند ہونے کے فوراً بعد منتقلی کا وقت دیتے ہیں تو آپ یقینی بنا سکتے ہیں کہ یہ کم سے کم رقم ہے۔ اگر آپ کا اپنے انڈیکسرز کے ساتھ ایک مواصلاتی چینل ہے، تو اپنی منتقلی کے لیے بہترین وقت تلاش کرنے کے لیے ان کے ساتھ بات چیت کرنے پر غور کریں۔.
+
+### اگر میں فی الحال جس انڈیکسر کو ڈیلیگیٹ کرتا ہوں وہ Arbitrum One پر نہیں ہے تو کیا ہو گا؟
+
+L2 ٹرانسفر ٹول صرف اس صورت میں فعال کیا جائے گا جب انڈیکسر جس کو آپ نے ڈیلیگیٹ کیا ہے اس نے اپنا سٹیک Arbitrum کو منتقل کر دیا ہے۔
+
+### کیا ڈیلیگیٹرز کے پاس کسی دوسرے انڈیکسر کو ڈیلیگیٹ کرنے کا اختیار ہے؟
+
+اگر آپ کسی دوسرے انڈیکسر کو ڈیلیگیٹ کرنا چاہتے ہیں، تو آپ Arbitrum پر اسی انڈیکسر کو منتقل کر سکتے ہیں، پھر ان ڈیلیگیٹ کریں اور ختم ہونے کی مدت کا انتظار کریں۔ اس کے بعد، آپ ڈیلیگیٹ کرنے کے لیے ایک اور فعال انڈیکسر منتخب کر سکتے ہیں۔
+
+### کیا ہوگا اگر مجھے L2 پر انڈیکسر نہیں مل رہا جسے میں ڈیلیگیٹ کر رہا ہوں؟
+
+L2 ٹرانسفر ٹول خود بخود اس انڈیکسر کا ایڈریس لگائے گا جسے آپ نے پہلے ڈیلیگیٹ کیا تھا.
+
+### کیا میں اپنے ڈیلیگیشن کو پہلے کے انڈیکسر کی بجائے نئے یا متعدد انڈیکسرز میں مکس اور میچ یا 'پھیلانے' کے قابل ہو جاؤں گا؟
+
+L2 ٹرانسفر ٹول ہمیشہ آپ کے ڈیلیگیشن کو اسی انڈیکسر کی طرف لے جائے گا جسے آپ نے پہلے ڈیلیگیٹ کر دیا تھا۔ ایک بار جب آپ L2 میں منتقل ہو جائیں تو، آپ ان ڈیلیگیٹ کر سکتے ہیں، ختم ہونے کی مدت کا انتظار کر سکتے ہیں، اور فیصلہ کر سکتے ہیں کہ آیا آپ اپنے ڈیلیگیشن کو الگ کرنا چاہتے ہیں.
+
+### کیا میں کول ڈاؤن پیریڈ سے مشروط ہوں یا L2 ڈیلیگیشن ٹرانسفر ٹول استعمال کرنے کے فوراً بعد واپس لے سکتا ہوں؟
+
+ٹرانسفر ٹول آپ کو فوری طور پر L2 پر جانے کی اجازت دیتا ہے۔ اگر آپ ان ڈیلیگیٹ کرنا چاہتے ہیں تو آپ کو ختم ہونے کی مدت کا انتظار کرنا پڑے گا۔ تاہم، اگر کسی انڈیکسر نے اپنے تمام سٹیک L2 کو منتقل کر دیے ہیں، تو آپ ایتھیریم مین نیٹ پر فوری طور پر واپس لے سکتے ہیں.
+
+### اگر میں اپنے ڈیلیگیشن کو منتقل نہیں کرتا ہوں تو کیا میرے انعامات پر منفی اثر پڑ سکتا ہے؟
+
+یہ متوقع ہے کہ تمام نیٹ ورک کی شرکت مستقبل میں Arbitrum One میں منتقل ہو جائے گی.
+
+### میرے ڈیلیگیشن کی L2 میں منتقلی کو مکمل کرنے میں کتنا وقت لگتا ہے؟
+
+ڈیلیگیشن کی منتقلی کے لیے 20 منٹ کی تصدیق درکار ہے۔ براہ کرم نوٹ کریں کہ 20 منٹ کی مدت کے بعد، آپ کو واپس آنا چاہیے اور 7 دنوں کے اندر منتقلی کے عمل کا مرحلہ 3 مکمل کرنا چاہیے۔ اگر آپ ایسا کرنے میں ناکام رہے تو آپ کا ڈیلیگیشن ضائع ہو سکتا ہے۔ نوٹ کریں کہ زیادہ تر معاملات میں ٹرانسفر ٹول آپ کے لیے یہ مرحلہ خود بخود مکمل کر دے گا۔ ناکام خودکار کوشش کی صورت میں، آپ کو اسے دستی طور پر مکمل کرنا ہوگا۔ اگر اس عمل کے دوران کوئی مسئلہ پیدا ہوتا ہے، تو پریشان نہ ہوں، ہم مدد کے لیے حاضر ہوں گے: ہم سے support@thegraph.com پر یا [ڈسکورڈ](https://discord.gg/graphprotocol) پر رابطہ کریں۔.
+
+### کیا میں اپنی ڈیلیگیشن کو منتقل کر سکتا ہوں اگر میں GRT ویسٹنگ کنٹریکٹ/ٹوکن لاک والیٹ استعمال کر رہا ہوں؟
+
+جی ہاں! یہ عمل تھوڑا مختلف ہے کیونکہ ویسٹنگ کنٹریکٹ L2 گیس کی ادائیگی کے لیے درکار ایتھیریم کو آگے نہیں بھیج سکتے، اس لیے آپ کو اسے پہلے سے جمع کروانا ہوگا۔ اگر آپ کا ویسٹنگ کنٹریکٹ مکمل طور پر محفوظ نہیں ہے، تو آپ کو پہلے L2 پر ایک ہم منصب ویسٹنگ کنٹریکٹ کو بھی شروع کرنا ہوگا اور صرف اس L2 ویسٹنگ کنٹریکٹ میں ڈیلیگیشن کو منتقل کر سکیں گے۔ جب آپ ویسٹنگ لاک والیٹ کا استعمال کرتے ہوئے ایکسپلورر سے منسلک ہوتے ہیں تو ایکسپلورر پر UI اس عمل میں آپ کی رہنمائی کر سکتا ہے.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### کیا کوئی ڈیلیگیشن ٹیکس ہے؟
+
+نہیں۔ L2 پر موصول ہونے والے ٹوکن مخصوص ڈیلیگیٹر کی جانب سے ڈیلیگیشن ٹیکس وصول کیے بغیر مخصوص انڈیکسر کو سونپے جاتے ہیں۔
+
+### جب میں اپنے ڈیلیگیشن کو منتقل کروں گا تو کیا میرے غیر حقیقی انعامات کو منتقل کیا جائے گا؟
+
+ہاں! صرف وہ انعامات جو منتقل نہیں کیے جاسکتے ہیں وہ کھلے مختص کے ہیں، کیونکہ وہ اس وقت تک موجود نہیں ہوں گے جب تک کہ انڈیکسر مختص کو بند نہیں کرتا (عام طور پر ہر 28 دن بعد)۔ اگر آپ تھوڑی دیر کے لیے تفویض کر رہے ہیں، تو یہ ممکنہ طور پر انعامات کا ایک چھوٹا سا حصہ ہے۔
+
+سمارٹ کنٹریکٹ کی سطح پر، غیر حقیقی انعامات پہلے سے ہی آپ کے ڈیلیگیشن کے بیلنس کا حصہ ہیں، لہذا جب آپ اپنے ڈیلیگیشن کو L2 میں منتقل کریں گے تو انہیں منتقل کر دیا جائے گا۔
+
+### کیا ڈیلیگیشنز کو L2 میں منتقل کرنا لازمی ہے؟ کیا کوئی ڈیڈ لائن ہے؟
+
+ڈیلیگیشن کو L2 میں منتقل کرنا لازمی نہیں ہے، لیکن [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193) میں بیان کردہ ٹائم لائن کے بعد L2 پر انڈیکسنگ انعامات بڑھ رہے ہیں۔۔ آخرکار، اگر کونسل اضافے کو منظور کرتی رہتی ہے، تو تمام انعامات L2 میں تقسیم کیے جائیں گے اور L1 پر انڈیکس کرنے والوں اور ڈیلیگیٹرز کے لیے کوئی انڈیکسنگ انعامات نہیں ہوں گے۔
+
+### اگر میں کسی ایسے انڈیکسر کو ڈیلیگیٹ کر رہا ہوں جس نے پہلے ہی سٹیک L2 کو منتقل کر دیا ہے، تو کیا میں L1 پر انعامات حاصل کرنا بند کر دوں؟
+
+بہت سے انڈیکسرز دھیرے دھیرے سٹیک کی منتقلی کر رہے ہیں لہذا L1 پر انڈیکسرز اب بھی L1 پر انعامات اور فیسیں حاصل کر رہے ہوں گے، جو پھر ڈیلیگیٹرز کے ساتھ شیئر کیے جاتے ہیں۔ ایک بار جب ایک انڈیکسر اپنے تمام سٹیک کو منتقل کر دیتا ہے، تو وہ L1 پر کام کرنا بند کر دے گا، اس لیے ڈیلیگیٹرز کو مزید انعامات نہیں ملیں گے جب تک کہ وہ L2 کو منتقل نہ کر دیں۔
+
+بالآخر، اگر کونسل L2 میں انڈیکسنگ کے انعامات میں اضافے کی منظوری دیتی رہتی ہے، تو تمام انعامات L2 پر تقسیم کیے جائیں گے اور L1 پر انڈیکسرز اور ڈیلیگیٹرز کے لیے کوئی انڈیکسنگ کے انعامات نہیں ہوں گے۔
+
+### مجھے اپنے ڈیلیگیشن کو منتقل کرنے کا بٹن نظر نہیں آرہا ہے۔ ایسا کیوں ہے؟
+
+آپ کے انڈیکسر نے شاید ابھی تک سٹیک کی منتقلی کے لیے L2 ٹرانسفر ٹولز کا استعمال نہیں کیا ہے۔
+
+اگر آپ انڈیکسر سے رابطہ کر سکتے ہیں، تو آپ انہیں L2 ٹرانسفر ٹولز استعمال کرنے کی ترغیب دے سکتے ہیں تاکہ ڈیلیگیٹرز ڈیلیگیشنز کو اپنے L2 انڈیکسر ایڈریس پر منتقل کر سکیں۔
+
+### میرا انڈیکسر Arbitrum پر ہے، لیکن مجھے اپنی پروفائل میں ڈیلیگیشن منتقل کرنے کا بٹن نہیں نظر آ رہا۔ ایسا کیوں ہے؟
+
+یہ ممکن ہے کہ انڈیکسر نے L2 پر آپریشنز مرتب کیے ہوں، لیکن اس نے سٹیک کی منتقلی کے لیے L2 ٹرانسفر ٹولز کا استعمال نہیں کیا ہے۔ لہذا L1 سمارٹ کنٹریکٹس انڈیکسر کے L2 ایڈریس کے بارے میں نہیں جانتے ہوں گے۔ اگر آپ انڈیکسر سے رابطہ کر سکتے ہیں، تو آپ انہیں ٹرانسفر ٹول استعمال کرنے کی ترغیب دے سکتے ہیں تاکہ ڈیلیگیٹرز ڈیلیگیشنز کو اپنے L2 انڈیکسر ایڈریس پر منتقل کر سکیں۔
+
+### کیا میں اپنے ڈیلیگیشنز کو L2 میں منتقل کر سکتا ہوں اگر میں نے غیر ڈیلیگیشنز کا عمل شروع کر دیا ہے اور ابھی تک اسے واپس نہیں لیا ہے؟
+
+نہیں۔ اگر آپ کی ڈیلیگیشن ختم ہو رہی ہے، آپ کو 28 دنوں تک انتظار کرنا ہو گا اور پھر اسے نکالیں۔
+
+جن ٹوکنز کو غیر ڈیلیگیٹ کیا جا رہا ہے وہ "لاک" ہیں اور اس لیے L2 میں منتقل نہیں کیے جا سکتے۔
+
+## کیوریشن سگنل
+
+### میں اپنی کیوریشن کیسے منتقل کروں؟
+
+اپنی کیوریشن منتقل کرنے کے لیے، آپ کو درج ذیل مراحل کو مکمل کرنے کی ضرورت ہو گی:
+
+1. ایتھیریم مین نیٹ پر سگنل کی منتقلی شروع کریں
+
+2. L2 کیوریٹر ایڈریس کی وضاحت کریں\*
+
+3. تصدیق کے لیے 20 منٹ انتظار کریں
+
+\*اگر ضروری ہو تو - یعنی آپ کنٹریکٹ ایڈریس استعمال کر رہے ہیں.
+
+### مجھے کیسے پتہ چلے گا کہ میں نے جو سب گراف تیار کیا ہے وہ L2 میں چلا گیا ہے؟
+
+سب گراف کی تفصیلات کا پیج دیکھتے وقت، ایک بینر آپ کو مطلع کرے گا کہ اس سب گراف کو منتقل کر دیا گیا ہے۔ آپ اپنے کیوریشن کو منتقل کرنے کے لیے پرامپٹ پر عمل کر سکتے ہیں۔ آپ یہ معلومات کسی بھی سب گراف کے سب گراف کی تفصیلات کے پیج پر بھی حاصل کر سکتے ہیں جو منتقل ہوا ہے۔
+
+### اگر میں اپنے کیوریشن کو L2 میں منتقل نہیں کرنا چاہتا تو کیا ہو گا؟
+
+جب سب گراف فرسودہ ہو جاتا ہے تو آپ کے پاس اپنا سگنل واپس لینے کا اختیار ہوتا ہے۔ اسی طرح، اگر کوئی سب گراف L2 میں منتقل ہو گیا ہے، تو آپ ایتھیریم مین نیٹ میں اپنے سگنل کو واپس لینے یا L2 کو سگنل بھیجنے کا انتخاب کر سکتے ہیں.
+
+### میں کیسے جان سکتا ہوں کہ میری کیوریشن کامیابی سے منتقل ہو گئی ہے؟
+
+L2 ٹرانسفر ٹول شروع ہونے کے تقریباً 20 منٹ بعد سگنل کی تفصیلات ایکسپلورر کے ذریعے قابل رسائی ہوں گی.
+
+### کیا میں ایک وقت میں ایک سے زیادہ سب گراف پر اپنی کیوریشن منتقل کر سکتا ہوں؟
+
+اس وقت بلک ٹرانسفر کا کوئی آپشن نہیں ہے.
+
+## انڈیکسر سٹیک
+
+### میں اپنا سٹیک Arbitrum پر کیسے منتقل کروں؟
+
+> اعلان دستبرداری: اگر آپ فی الحال اپنے انڈیکسر پر اپنے GRT کے کسی بھی سٹیک کو ہٹا رہے ہیں، تو آپ L2 ٹرانسفر ٹولز استعمال نہیں کر سکیں گے۔
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+اپنا سٹیک منتقل کرنے کے لیے، آپ کو درج ذیل مراحل کو مکمل کرنے کی ضرورت ہو گی:
+
+1. ایتھیریم مین نیٹ پر سٹیک کی منتقلی شروع کریں
+
+2. تصدیق کے لیے 20 منٹ انتظار کریں
+
+3. Arbitrum پر سٹیک کی منتقلی کی تصدیق کریں
+
+\*نوٹ کریں کہ آپ کو 7 دنوں کے اندر منتقلی کی تصدیق کرنی چاہیے ورنہ آپ کا سٹیک ضائع ہو سکتا ہے۔ زیادہ تر معاملات میں، یہ مرحلہ خود بخود چلے گا، لیکن اگر Arbitrum پر گیس کی قیمت میں اضافہ ہوتا ہے تو دستی تصدیق کی ضرورت ہو سکتی ہے۔ اگر اس عمل کے دوران کوئی مسئلہ درپیش ہے، تو مدد کے لیے وسائل موجود ہوں گے: support@thegraph.com پر یا [ڈسکورڈ](https://discord.gg/graphprotocol) پر سپورٹ سے رابطہ کریں۔
+
+### کیا میرا تمام سٹیک منتقل ہو جائے گا؟
+
+آپ یہ منتخب کر سکتے ہیں کہ آپ کا کتنا سٹیک منتقل کرنا ہے۔ اگر آپ اپنے تمام سٹیک کو ایک ساتھ منتقل کرنے کا انتخاب کرتے ہیں، تو آپ کو پہلے کسی بھی کھلے سٹیک کو بند کرنے کی ضرورت پڑے گی۔
+
+اگر آپ متعدد ٹرانزیکشن پر اپنے سٹیک کے حصوں کو منتقل کرنے کا ارادہ رکھتے ہیں، تو آپ کو ہمیشہ ایک ہی بینیفیشری کا ایڈریس بتانا ہوگا.
+
+نوٹ: جب آپ پہلی بار ٹرانسفر ٹول استعمال کرتے ہیں تو آپ کو L2 پر کم سے کم سٹیک کی ضروریات کو پورا کرنا ہوگا۔ انڈیکسرز کو کم سے کم 100 ہزار GRT بھیجنا چاہیے (جب اس فنکشن کو پہلی بار کال کریں)۔ اگر L1 پر حصص کا کچھ حصہ چھوڑتے ہیں، تو یہ 100 ہزار GRT کم سے کم سے زیادہ ہونا چاہیے اور آپ کی کھلی تقسیم کو پورا کرنے کے لیے کافی (آپ کے ڈیلیگیشنز کے ساتھ) ہونا چاہیے.
+
+### مجھے اپنے سٹیک کو Arbitrum میں منتقلی کی تصدیق کرنے کے لیے کتنا وقت درکار ہے؟
+
+\*\*\* Arbitrum پر سٹیک کی منتقلی کو مکمل کرنے کے لیے آپ کو اپنے ٹرانزیکشن کی تصدیق کرنی ہوگی۔ یہ مرحلہ 7 دنوں کے اندر مکمل ہونا چاہیے ورنہ سٹیک کھو سکتا ہے.
+
+### اگر میرے پاس کھلی مختص ہے تو کیا ہوگا؟
+
+اگر آپ اپنے تمام سٹیک نہیں بھیج رہے ہیں تو، L2 ٹرانسفر ٹول اس بات کی توثیق کرے گا کہ کم سے کم 100 ہزار GRT ایتھیریم مین نیٹ میں باقی ہیں اور آپ کا باقی سٹیک اور ڈیلیگیشن کسی بھی کھلے مختص کو پورا کرنے کے لیے کافی ہے۔ اگر آپ کا GRT بیلنس کم سے کم + کھلی مختصات کا احاطہ نہیں کرتا ہے تو آپ کو کھلی مختص بند کرنے کی ضرورت پڑسکتی ہے.
+
+### ٹرانسفر ٹولز کا استعمال کرتے ہوئے، کیا منتقل کرنے سے پہلے ایتھیریم مین نیٹ کو ہٹانے کے لیے 28 دن انتظار کرنا ضروری ہے؟
+
+نہیں، آپ L2 پر اپنا سٹیک فوری منتقل کر سکتے ہیں، ٹرانسفر ٹول کو استعمال کرنے سے پہلے اسے واپس لینے اور انتظار کرنے کی ضرورت نہیں ہے۔ 28 دن کا انتظار صرف اس صورت میں لاگو ہوتا ہے جب آپ ایتھیریم مین نیٹ یا L2 پر اپنے والیٹ میں سٹیک واپس لینا چاہتے ہیں۔
+
+### میرا سٹیک منتقل ہونے میں کتنا وقت لگے گا؟
+
+L2 ٹرانسفر ٹول کو آپ کے سٹیک کی منتقلی مکمل کرنے میں تقریبآٓ 20 منٹ لگیں گے۔
+
+### کیا مجھے اپنا سٹیک منتقل کرنے سے پہلے Arbitrum پر انڈیکس کرنا ہو گا؟
+
+آپ انڈیکسنگ کو ترتیب دینے سے پہلے مؤثر طریقے سے اپنا سٹیک منتقل کر سکتے ہیں، لیکن آپ L2 پر کسی بھی انعام کا دعویٰ نہیں کر سکیں گے جب تک کہ آپ L2 پر سب گرافس کے لیے مختص نہیں کر دیتے، ان کو انڈیکس نہیں کرتے اور POIs پیش نہیں کرتے.
+
+### کیا ڈیلیگیٹرز اپنے ڈیلیگیشن کو منتقل کر سکتے ہیں اس سے پہلے کہ میں اپنے انڈیکسنگ کا سٹیک منتقل کروں؟
+
+نہیں، ڈیلیگیٹرز کے لیے اپنے ڈیلیگیٹڈ GRT کو Arbitrum میں منتقل کرنے کے لیے، انڈیکسر جس کو وہ ڈیلیگیٹ کر رہے ہیں L2 پر فعال ہونا چاہیے۔
+
+### اگر میں GRT ویسٹنگ کنٹریکٹ / ٹوکن لاک والیٹ استعمال کر رہا ہوں تو کیا میں اپنا سٹیک منتقل کر سکتا ہوں؟
+
+جی ہاں! یہ عمل قدرے مختلف ہے، کیونکہ ویسٹنگ کنٹریکٹ L2 گیس کی ادائیگی کے لیے درکار ایتھیریم کو آگے نہیں بھیج سکتے، اس لیے آپ کو اسے پہلے سے جمع کروانے کی ضرورت ہے۔ اگر آپ کا ویسٹنگ کنٹریکٹ مکمل طور پر نہیں ہے، تو آپ کو پہلے L2 پر ایک ہم منصب ویسٹنگ کنٹریکٹ بھی شروع کرنا ہو گا اور آپ صرف اس L2 ویسٹنگ کنٹریکٹ میں سٹیک کو منتقل کر سکیں گے۔ جب آپ ویسٹنگ لاک والیٹ کا استعمال کرتے ہوئے ایکسپلورر سے منسلک ہوتے ہیں تو ایکسپلورر پر UI اس عمل میں آپ کی رہنمائی کر سکتا ہے.
+
+### میرے پاس پہلے سے ہی L2 پر سٹیک ہے۔ جب میں پہلی بار ٹرانسفر ٹولز استعمال کرتا ہوں تو کیا مجھے اب بھی 100 ہزار GRT بھیجنے کی ضرورت ہے؟
+
+ہاں۔ L1 سمارٹ کنٹریکٹس آپ کے L2 سٹیک سے واقف نہیں ہوں گے، لہذا جب آپ پہلی بار منتقل کریں گے تو وہ آپ سے کم از کم 100 ہزار GRT منتقل کرنے کا تقاضا کریں گے۔
+
+### کیا میں اپنے سٹیک کو L2 میں منتقل کر سکتا ہوں اگر میں GRT کو ہٹانے کے عمل میں ہوں؟
+
+نہیں اگر آپ کے سٹیک کا کوئی حصہ ختم ہو رہا ہے، تو آپ کو 28 دن انتظار کرنا ہوگا اور اس سے پہلے کہ آپ سٹیک کی منتقلی کر سکیں اسے واپس لے لیں۔ جو ٹوکن داغے جا رہے ہیں وہ "لاک" ہیں اور L2 میں کسی بھی قسم کی منتقلی یا سٹیک کو روکیں گے۔
+
+## ویسٹنگ کنٹریکٹ منتقلی
+
+### میں اپنا ویسٹنگ کنٹریکٹ کیسے منتقل کروں؟
+
+اپنی ویسٹنگ منتقل کرنے کے لیے، آپ کو درج ذیل مراحل کو مکمل کرنے کی ضرورت ہو گی:
+
+1. ایتھیریم مین نیٹ پر ویسٹنگ کی منتقلی شروع کریں
+
+2. تصدیق کے لیے 20 منٹ انتظار کریں
+
+3. Arbitrum پر ویسٹنگ منتقلی کی تصدیق کرنا
+
+### اگر میں صرف جزوی طور پر ویسٹڈ ہوں تو میں اپنا ویسٹنگ کا کنٹریکٹ کیسے منتقل کروں؟
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. ٹرانسفر ٹول کے کنٹریکٹ میں کچھ ایتھیریم جمع کریں (UI مناسب رقم کا تخمینہ لگانے میں مدد کر سکتا ہے)
+
+2. L2 ویسٹنگ لاک کو شروع کرنے کے لیے کچھ لاک شدہ GRT ٹرانسفر ٹول کنٹریکٹ کے ذریعے L2 کو بھیجیں۔ یہ ان کا L2 بینیفیشری کا ایڈریس بھی ترتیب دے گا.
+
+3. L1 سٹیکنگ کنٹریکٹ میں "لاک" ٹرانسفر ٹول فنکشنز کے ذریعے اپنا سٹیک/ڈیلیگیشن L2 کو بھیجیں.
+
+4. ٹرانسفر ٹول کنٹریکٹ سے کوئی بھی بچا ہوا ایتھیریم نکال لیں
+
+### میں اپنا ویسٹنگ کنٹریکٹ کیسے منتقل کروں اگر میں مکمل طور پر ویسٹڈ ہوں؟
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+ان لوگوں کے لیے جو مکمل ویسٹڈ ہیں، یہ عمل ایک جیسا ہے:
+
+1. ٹرانسفر ٹول کے کنٹریکٹ میں کچھ ایتھیریم جمع کریں (UI مناسب رقم کا تخمینہ لگانے میں مدد کر سکتا ہے)
+
+2. ٹرانسفر ٹول کنٹریکٹ پر کال کے ساتھ اپنا L2 ایڈریس سیٹ کریں
+
+3. L1 سٹیکنگ کنٹریکٹ میں "لاکڈ" ٹرانسفر ٹول فنکشنز کے ذریعے اپنا سٹیک/ڈیلیگیشن L2 کو بھیجیں.
+
+4. ٹرانسفر ٹول کنٹریکٹ سے کوئی بھی بچا ہوا ایتھیریم نکال لیں
+
+### کیا میں اپنا ویسٹنگ کنٹریکٹ Arbitrum پر منتقل کر سکتا ہوں؟
+
+آپ اپنے ویسٹنگ کنٹریکٹ کے GRT بیلنس کو L2 میں ویسٹنگ کنٹریکٹ میں منتقل کر سکتے ہیں۔ سٹیک یا ڈیلیگیشن کو آپ کے ویسٹنگ کنٹریکٹ سے L2 میں منتقل کرنے کے لیے یہ ایک شرط ہے۔ ویسٹنگ کنٹریکٹ میں GRT کی غیر صفر رقم ہونی چاہیے (ضرورت پڑنے پر آپ اس میں 1 GRT جیسی چھوٹی رقم منتقل کر سکتے ہیں).
+
+جب آپ GRT کو اپنے L1 ویسٹنگ کنٹریکٹ سے L2 میں منتقل کرتے ہیں، تو آپ بھیجنے کے لیے رقم کا انتخاب کر سکتے ہیں اور آپ اسے جتنی بار چاہیں کر سکتے ہیں۔ جب آپ پہلی بار GRT منتقل کریں گے تو L2 ویسٹنگ کا کنٹریکٹ شروع کیا جائے گا۔
+
+منتقلی ایک ٹرانسفر ٹول کا استعمال کرتے ہوئے کی جاتی ہے جو آپ کے ایکسپلورر پروفائل پر نظر آئے گا جب آپ ویسٹنگ کنٹریکٹ اکاؤنٹ سے منسلک ہوں گے.
+
+براہ کرم نوٹ کریں کہ جب آپ کا کنٹریکٹ مکمل طور پر محفوظ ہو جائے گا تو آپ اپنی ویسٹنگ ٹائم لائن کے اختتام تک L2 ویسٹنگ کنٹریکٹ سے GRT کو جاری/واپس نہیں لے سکیں گے۔ اگر آپ کو اس سے پہلے GRT جاری کرنے کی ضرورت ہے، تو آپ اس مقصد کے لیے دستیاب دوسرے ٹرانسفر ٹول کا استعمال کرتے ہوئے GRT کو L1 ویسٹنگ کنٹریکٹ میں واپس منتقل کر سکتے ہیں.
+
+اگر آپ نے کوئی ویسٹنگ کنٹریکٹ بیلنس L2 میں منتقل نہیں کیا ہے، اور آپ کا ویسٹنگ کنٹریکٹ مکمل طور پر محفوظ ہے، تو آپ کو اپنا ویسٹنگ کنٹریکٹ L2 میں منتقل نہیں کرنا چاہیے۔ اس کے بجائے، آپ L2 والیٹ کا ایڈریس سیٹ کرنے کے لیے ٹرانسفر ٹولز کا استعمال کر سکتے ہیں، اور براہ راست اپنا حصہ یا ڈیلیگیشن L2 پر اس باقاعدہ والیٹ میں منتقل کر سکتے ہیں.
+
+### مین نیٹ پر سٹیک پر لگانے کے لیے میں اپنا ویسٹنگ کنٹریکٹ استعمال کر رہا ہوں۔ کیا میں اپنا سٹیک Arbitrum کو منتقل کر سکتا ہوں؟
+
+ہاں، لیکن اگر آپ کا کنٹریکٹ اب بھی ویسٹنگ ہے، تو آپ سٹیک کو صرف اس لیے منتقل کر سکتے ہیں کہ یہ آپ کے L2 ویسٹنگ کنٹریکٹ کی ملکیت ہو۔ آپ کو پہلے ایکسپلورر پر ویسٹنگ کنٹریکٹ ٹرانسفر ٹول کا استعمال کرتے ہوئے کچھ GRT بیلنس منتقل کرکے اس L2 کنٹریکٹ کو شروع کرنا ہوگا۔ اگر آپ کا کنٹریکٹ مکمل طور پر محفوظ ہے، تو آپ اپنا سٹیک L2 میں کسی بھی ایڈریس پر منتقل کر سکتے ہیں، لیکن آپ کو اسے پہلے سے طے کرنا ہوگا اور L2 گیس کی ادائیگی کے لیے L2 ٹرانسفر ٹول کے لیے کچھ ایتھیریم جمع کرانا ہوگا.
+
+### مین نیٹ پر ڈیلیگیٹ کرنے کے لیے میں اپنا ویسٹنگ کنٹریکٹ استعمال کر رہا ہوں۔ کیا میں اپنے ڈیلیگیشن کو Arbitrum میں منتقل کر سکتا ہوں؟
+
+ہاں، لیکن اگر آپ کا کنٹریکٹ اب بھی ویسٹنگ ہے، تو آپ ڈیلیگیشن کو صرف اس لیے منتقل کر سکتے ہیں تاکہ یہ آپ کے L2 ویسٹنگ کنٹریکٹ کی ملکیت ہو۔ آپ کو پہلے ایکسپلورر پر ویسٹنگ کنٹریکٹ ٹرانسفر ٹول کا استعمال کرتے ہوئے کچھ GRT بیلنس منتقل کرکے اس L2 کنٹریکٹس کو شروع کرنا ہوگا۔ اگر آپ کا کنٹریکٹ مکمل طور پر محفوظ ہے، تو آپ اپنے ڈیلیگیشن کو L2 میں کسی بھی ایڈریس پر منتقل کر سکتے ہیں، لیکن آپ کو اسے پہلے سے طے کرنا چاہیے اور L2 گیس کی ادائیگی کے لیے L2 ٹرانسفر ٹول کے لیے کچھ ایتھیریم جمع کرانا چاہیے.
+
+### کیا میں L2 پر اپنے ویسٹنگ کنٹریکٹ کے لیے ایک مختلف بینیفیشری کو چن سکتا ہوں؟
+
+ہاں، پہلی بار جب آپ بیلنس ٹرانسفر کرتے ہیں اور اپنا L2 ویسٹنگ کنٹریکٹ سیٹ کرتے ہیں، تو آپ ایک L2 بینیفیشری کو چن سکتے ہیں۔ یقینی بنائیں کہ یہ بینیفیشری ایک والیٹ ہے جو Arbitrum One پر ٹرانزیکشن کر سکتا ہے، یعنی یہ EOA یا Arbitrum One میں تعینات ملٹی سگ ہونا چاہیے.
+
+اگر آپ کا کنٹریکٹ مکمل طور پر محفوظ ہے، تو آپ L2 پر ویسٹنگ کنٹریکٹ قائم نہیں کریں گے؛ اس کے بجائے، آپ ایک L2 والیٹ ایڈریس سیٹ کریں گے اور یہ Arbitrum پر آپ کے سٹیک یا ڈیلیگیشن کے لیے وصول کرنے والا والیٹ ہوگا.
+
+### میرا کنٹریکٹ مکمل طور پر محفوظ ہے۔ کیا میں اپنے سٹیک یا ڈیلیگیشن کو کسی دوسرے ایڈریس پر منتقل کر سکتا ہوں جو L2 ویسٹنگ کنٹریکٹ نہیں ہے؟
+
+جی ہاں. اگر آپ نے کوئی ویسٹنگ کنٹریکٹ بیلنس L2 میں منتقل نہیں کیا ہے، اور آپ کا ویسٹنگ کنٹریکٹ مکمل طور پر محفوظ ہے، تو آپ کو اپنا ویسٹنگ کنٹریکٹ L2 میں منتقل نہیں کرنا چاہیے۔ اس کے بجائے، آپ L2 والیٹ کا ایڈریس سیٹ کرنے کے لیے ٹرانسفر ٹولز کا استعمال کر سکتے ہیں، اور براہ راست اپنا سٹیک یا ڈیلیگیشن L2 پر اس باقاعدہ والیٹ میں منتقل کر سکتے ہیں.
+
+یہ آپ کو اپنے سٹیک یا ڈیلیگیشن کو کسی بھی L2 ایڈریس پر منتقل کرنے کی اجازت دیتا ہے.
+
+### میرا ویسٹنگ کنٹریکٹ اب بھی ویسٹنگ کر رہا ہے۔ میں اپنے ویسٹنگ کنٹریکٹ بیلنس کو L2 میں کیسے منتقل کروں؟
+
+یہ اقدامات صرف اس صورت میں لاگو ہوتے ہیں جب آپ کا کنٹریکٹ اب بھی ویسٹنگ کر رہا ہے، یا اگر آپ نے اس عمل کو اس سے پہلے استعمال کیا ہے جب آپ کا کنٹریکٹ ابھی بھی ویسٹنگ کر رہا تھا.
+
+اپنے ویسٹنگ کا کنٹریکٹ L2 میں منتقل کرنے کے لیے، آپ ٹرانسفر ٹولز کا استعمال کرتے ہوئے کوئی بھی GRT بیلنس L2 کو بھیجیں گے، جو آپ کے L2 ویسٹنگ کنٹریکٹ کو شروع کرے گا:
+
+1. ٹرانسفر ٹول کنٹریکٹ میں کچھ ایتھیریم جمع کریں (یہ L2 گیس کی ادائیگی کے لیے استعمال کیا جائے گا)
+
+2. ویسٹنگ کنٹریکٹ تک پروٹوکول کی رسائی منسوخ کریں (اگلے مرحلے کے لیے درکار)
+
+3. ویسٹنگ کنٹریکٹ تک پروٹوکول تک رسائی دیں (آپ کے کنٹریکٹ کو ٹرانسفر ٹول کے ساتھ تعامل کرنے کی اجازت دے گا)
+
+4. ایک L2 بینیفیشری کا ایڈریس بتائیں\* اور ایتھیریم مین نیٹ پر بیلنس کی منتقلی شروع کریں
+
+5. تصدیق کے لیے 20 منٹ انتظار کریں
+
+6. L2 پر بیلنس کی منتقلی کی تصدیق کریں
+
+\*اگر ضروری ہو تو - یعنی آپ کنٹریکٹ ایڈریس استعمال کر رہے ہیں.
+
+\*\*\*\* Arbitrum پر بیلنس کی منتقلی کو مکمل کرنے کے لیے آپ کو اپنے ٹرانزیکشن کی تصدیق کرنی ہوگی۔ یہ مرحلہ 7 دنوں کے اندر مکمل ہونا چاہیے ورنہ بیلنس ضائع ہو سکتا ہے۔ زیادہ تر معاملات میں، یہ مرحلہ خود بخود چلے گا، لیکن اگر Arbitrum پر گیس کی قیمت میں اضافہ ہوتا ہے تو دستی تصدیق کی ضرورت ہو سکتی ہے۔ اگر اس عمل کے دوران کوئی مسئلہ درپیش ہے، تو مدد کے لیے وسائل موجود ہوں گے: support@thegraph.com پر یا [ڈسکورڈ](https://discord.gg/graphprotocol) پر سپورٹ سے رابطہ کریں۔
+
+### میرا ویسٹنگ کنٹریکٹ 0 GRT دکھاتا ہے لہذا میں اسے منتقل نہیں کر سکتا، یہ کیوں ہے اور میں اسے کیسے ٹھیک کروں؟
+
+اپنے L2 ویسٹنگ کنٹریکٹ کو شروع کرنے کے لیے، آپ کو GRT کی غیر صفر رقم L2 میں منتقل کرنے کی ضرورت ہے۔ یہ Arbitrum GRT بریج کے ذریعہ درکار ہے جو L2 ٹرانسفر ٹولز کے ذریعہ استعمال ہوتا ہے۔ GRT لازمی طور پر ویسٹنگ کنٹریکٹ کے بیلنس سے آنا چاہیے، اس لیے اس میں اسٹیک یا ڈیلیگیٹڈ GRT شامل نہیں ہے۔
+
+اگر آپ نے ویسٹنگ کنٹریکٹ سے اپنے تمام GRT کو سٹیک پر لگا دیا ہے یا ڈیلیگیٹ کیا ہے، تو آپ دستی طور پر 1 GRT جیسی چھوٹی رقم کسی اور جگہ سے ویسٹنگ کنٹریکٹ ایڈریس پر بھیج سکتے ہیں (مثلاً کسی اور والیٹ، یا ایکسچینج سے)۔
+
+### میں سٹیک یا ڈیلیگیٹ کرنے کے لیے ایک ویسٹنگ کنٹریکٹ استعمال کر رہا ہوں، لیکن مجھے اپنے سٹیک یا ڈیلیگیشن کو L2 میں منتقل کرنے کے لیے کوئی بٹن نظر نہیں آ رہا، میں کیا کروں؟
+
+اگر آپ کے ویسٹنگ کنٹریکٹ نے ویسٹنگ مکمل نہیں کی ہے، تو آپ کو پہلے ایک L2 ویسٹنگ کنٹریکٹ بنانا ہوگا جو L2 پر آپ کا سٹیک یا ڈیلیگیشن وصول کرے گا۔ ویسٹنگ کا یہ معاہدہ ویسٹنگ ٹائم لائن کے اختتام تک L2 میں ٹوکن جاری کرنے کی اجازت نہیں دے گا، لیکن آپ کو وہاں جاری ہونے والے L1 ویسٹنگ کنٹریکٹ میں GRT کو واپس منتقل کرنے کی اجازت دے گا۔
+
+ایکسپلورر پر ویسٹنگ کنٹریکٹ کے ساتھ منسلک ہونے پر، آپ کو اپنے L2 ویسٹنگ کنٹریکٹ کو شروع کرنے کے لیے ایک بٹن دیکھنا چاہیے۔ پہلے اس عمل کی پیروی کریں، اور پھر آپ کو اپنے پروفائل میں اپنا سٹیک یا ڈیلیگیشن منتقل کرنے کے بٹن نظر آئیں گے۔
+
+### اگر میں اپنے L2 ویسٹنگ کنٹریکٹ کو شروع کرتا ہوں، تو کیا یہ میرے ڈیلیگیشن کو خود بخود L2 میں منتقل کر دے گا؟
+
+نہیں، آپ کے L2 ویسٹنگ کنٹریکٹ کو شروع کرنا ویسٹنگ کنٹریکٹ سے سٹیک یا ڈیلیگیشن کو منتقل کرنے کے لیے ایک شرط ہے، لیکن پھر بھی آپ کو ان کو الگ سے منتقل کرنے کی ضرورت ہے۔
+
+آپ کو اپنے پروفائل پر ایک بینر نظر آئے گا جو آپ کو اپنے سٹیک یا ڈیلیگیشن کو منتقل کرنے کا اشارہ کرے گا جب آپ نے اپنا L2 ویسٹنگ کنٹریکٹ شروع کر دیا ہے۔
+
+### کیا میں اپنے ویسٹنگ کا کنٹریکٹ واپس L1 میں منتقل کر سکتا ہوں؟
+
+ایسا کرنے کی ضرورت نہیں ہے کیونکہ آپ کا ویسٹنگ کا کنٹریکٹ ابھی بھی L1 میں ہے۔ جب آپ ٹرانسفر ٹولز استعمال کرتے ہیں، تو آپ صرف L2 میں ایک نیا کنٹریکٹ بناتے ہیں جو آپ کے L1 ویسٹنگ کنٹریکٹ سے منسلک ہوتا ہے، اور آپ دونوں کے درمیان GRT کو آگے پیچھے بھیج سکتے ہیں.
+
+### شروع کرنے کے لیے مجھے اپنے ویسٹنگ کنٹریکٹ منتقل کرنے کی ضرورت کیوں ہے؟
+
+آپ کو ایک L2 ویسٹنگ کنٹریکٹ قائم کرنے کی ضرورت ہے تاکہ یہ اکاؤنٹ L2 پر آپ کے سٹیک یا ڈیلیگیشن کا مالک بن سکے۔ بصورت دیگر، آپ کے پاس ویسٹنگ کنٹریکٹ سے "فرار" ہوئے بغیر سٹیک/ڈیلیگیشن کو L2 میں منتقل کرنے کا کوئی طریقہ نہیں ہوگا.
+
+### کیا ہوتا ہے اگر میں اپنے کنٹریکٹ کو کیش آؤٹ کرنے کی کوشش کرتا ہوں جب یہ صرف جزوی طور پر ہوتا ہے؟ کیا یہ ممکن ہے؟
+
+یہ کوئی امکان نہیں ہے۔ آپ فنڈز واپس L1 میں منتقل کر سکتے ہیں اور انہیں وہاں سے نکال سکتے ہیں.
+
+### اگر میں اپنے ویسٹنگ کا کنٹریکٹ L2 میں منتقل نہیں کرنا چاہتا تو کیا ہوگا؟
+
+آپ L1 پر سٹیک/ڈیلیگیٹنگ جاری رکھ سکتے ہیں۔ وقت گزرنے کے ساتھ، آپ Arbitrum پر پروٹوکول کے پیمانے کے طور پر وہاں انعامات کو فعال کرنے کے لیے L2 پر جانے پر غور کر سکتے ہیں۔ نوٹ کریں کہ ٹرانسفر ٹولز ان ویسٹنگ کنٹریکٹس کے لیے ہیں جنہیں پروٹوکول میں سٹیک کرنے اور ان کو ڈیلیگیٹ کرنے کی اجازت ہے۔ اگر آپ کا کنٹریکٹ سٹیکنگ یا ڈیلیگیٹنگ کی اجازت نہیں دیتا، یا منسوخی کے قابل ہے، تو پھر کوئی ٹرانسفر ٹول دستیاب نہیں ہے۔ دستیاب ہونے پر بھی آپ L1 سے اپنا GRT واپس لے سکیں گے.

From fd3d50dff9932f7aad06b50a379be5525cdfd142 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:00 -0500
Subject: [PATCH 1040/3820] New translations l2-transfer-tools-faq.mdx
 (Vietnamese)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/vi/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/vi/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/vi/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..ebb2229301d3
--- /dev/null
+++ b/website/pages/vi/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2 Transfer Tools FAQ
+---
+
+## Khái quát
+
+### What are L2 Transfer Tools?
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### Can I use the same wallet I use on Ethereum mainnet?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### What happens if I don’t finish my transfer in 7 days?
+
+The L2 Transfer Tools use Arbitrum’s native mechanism to send messages from L1 to L2. This mechanism is called a “retryable ticket” and is used by all native token bridges, including the Arbitrum GRT bridge. You can read more about retryable tickets in the [Arbitrum docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+When you transfer your assets (subgraph, stake, delegation or curation) to L2, a message is sent through the Arbitrum GRT bridge which creates a retryable ticket in L2. The transfer tool includes some ETH value in the transaction, that is used to 1) pay to create the ticket and 2) pay for the gas to execute the ticket in L2. However, because gas prices might vary in the time until the ticket is ready to execute in L2, it is possible that this auto-execution attempt fails. When that happens, the Arbitrum bridge will keep the retryable ticket alive for up to 7 days, and anyone can retry “redeeming” the ticket (which requires a wallet with some ETH bridged to Arbitrum).
+
+This is what we call the “Confirm” step in all the transfer tools - it will run automatically in most cases, as the auto-execution is most often successful, but it is important that you check back to make sure it went through. If it doesn’t succeed and there are no successful retries in 7 days, the Arbitrum bridge will discard the ticket, and your assets (subgraph, stake, delegation or curation) will be lost and can’t be recovered. The Graph core devs have a monitoring system in place to detect these situations and try to redeem the tickets before it’s too late, but it is ultimately your responsibility to ensure your transfer is completed in time. If you’re having trouble confirming your transaction, please reach out using [this form](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) and core devs will be there help you.
+
+### I started my delegation/stake/curation transfer and I'm not sure if it made it through to L2, how can I confirm that it was transferred correctly?
+
+If you don't see a banner on your profile asking you to finish the transfer, then it's likely the transaction made it safely to L2 and no more action is needed. If in doubt, you can check if Explorer shows your delegation, stake or curation on Arbitrum One.
+
+If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire.
+
+## Subgraph Transfer
+
+### How do I transfer my subgraph?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+To transfer your subgraph, you will need to complete the following steps:
+
+1. Initiate the transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm subgraph transfer on Arbitrum\*
+
+4. Finish publishing subgraph on Arbitrum
+
+5. Update Query URL (recommended)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Where should I initiate my transfer from?
+
+You can initiate your transfer from the [Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) or any subgraph details page. Click the "Transfer Subgraph" button in the subgraph details page to start the transfer.
+
+### How long do I need to wait until my subgraph is transferred
+
+The transfer time takes approximately 20 minutes. The Arbitrum bridge is working in the background to complete the bridge transfer automatically. In some cases, gas costs may spike and you will need to confirm the transaction again.
+
+### Will my subgraph still be discoverable after I transfer it to L2?
+
+Your subgraph will only be discoverable on the network it is published to. For example, if your subgraph is on Arbitrum One, then you can only find it in Explorer on Arbitrum One and will not be able to find it on Ethereum. Please ensure that you have Arbitrum One selected in the network switcher at the top of the page to ensure you are on the correct network.  After the transfer, the L1 subgraph will appear as deprecated.
+
+### Does my subgraph need to be published to transfer it?
+
+To take advantage of the subgraph transfer tool, your subgraph must be already published to Ethereum mainnet and must have some curation signal owned by the wallet that owns the subgraph. If your subgraph is not published, it is recommended you simply publish directly on Arbitrum One - the associated gas fees will be considerably lower. If you want to transfer a published subgraph but the owner account hasn't curated any signal on it, you can signal a small amount (e.g. 1 GRT) from that account; make sure to choose "auto-migrating" signal.
+
+### What happens to the Ethereum mainnet version of my subgraph after I transfer to Arbitrum?
+
+After transferring your subgraph to Arbitrum, the Ethereum mainnet version will be deprecated. We recommend you update your query URL within 48 hours. However, there is a grace period in place that keeps your mainnet URL functioning so that any third-party dapp support can be updated.
+
+### After I transfer, do I also need to re-publish on Arbitrum?
+
+After the 20 minute transfer window, you will need to confirm the transfer with a transaction in the UI to finish the transfer, but the transfer tool will guide you through this. Your L1 endpoint will continue to be supported during the transfer window and a grace period after. It is encouraged that you update your endpoint when convenient for you.
+
+### Will my endpoint experience downtime while re-publishing?
+
+It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the subgraph on L1 and whether they keep indexing it until the subgraph is fully supported on L2.
+
+### Is publishing and versioning the same on L2 as Ethereum Ethereum mainnet?
+
+Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the subgraph.
+
+### Will my subgraph's curation move with my subgraph?
+
+If you've chosen auto-migrating signal, 100% of your own curation will move with your subgraph to Arbitrum One. All of the subgraph's curation signal will be converted to GRT at the time of the transfer, and the GRT corresponding to your curation signal will be used to mint signal on the L2 subgraph.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph.
+
+### Can I move my subgraph back to Ethereum mainnet after I transfer?
+
+Once transferred, your Ethereum mainnet version of this subgraph will be deprecated. If you would like to move back to mainnet, you will need to redeploy and publish back to mainnet. However, transferring back to Ethereum mainnet is strongly discouraged as indexing rewards will eventually be distributed entirely on Arbitrum One.
+
+### Why do I need bridged ETH to complete my transfer?
+
+Gas fees on Arbitrum One are paid using bridged ETH (i.e. ETH that has been bridged to Arbitrum One). However, the gas fees are significantly lower when compared to Ethereum mainnet.
+
+## Delegation
+
+### How do I transfer my delegation?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+To transfer your delegation, you will need to complete the following steps:
+
+1. Initiate delegation transfer on Ethereum mainnet
+2. Wait 20 minutes for confirmation
+3. Confirm delegation transfer on Arbitrum
+
+\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### What happens to my rewards if I initiate a transfer with an open allocation on Ethereum mainnet?
+
+If the Indexer to whom you're delegating is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer.
+
+### What happens if the Indexer I currently delegate to isn't on Arbitrum One?
+
+The L2 transfer tool will only be enabled if the Indexer you have delegated to has transferred their own stake to Arbitrum.
+
+### Do Delegators have the option to delegate to another Indexer?
+
+If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to.
+
+### What if I can't find the Indexer I'm delegating to on L2?
+
+The L2 transfer tool will automatically detect the Indexer you previously delegated to.
+
+### Will I be able to mix and match or 'spread' my delegation across new or several Indexers instead of the prior Indexer?
+
+The L2 transfer tool will always move your delegation to the same Indexer you delegated to previously. Once you have moved to L2, you can undelegate, wait for the thawing period, and decide if you'd like to split up your delegation.
+
+### Am I subject to the cooldown period or can I withdraw immediately after using the L2 delegation transfer tool?
+
+The transfer tool allows you to immediately move to L2. If you would like to undelegate you will have to wait for the thawing period. However, if an Indexer has transferred all of their stake to L2, you can withdraw on Ethereum mainnet immediately.
+
+### Can my rewards be negatively impacted if I do not transfer my delegation?
+
+It is anticipated that all network participation will move to Arbitrum One in the future.
+
+### How long does it take to complete the transfer of my delegation to L2?
+
+A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Can I transfer my delegation if I'm using a GRT vesting contract/token lock wallet?
+
+Yes! The process is a bit different because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the delegation to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### Is there any delegation tax?
+
+No. Received tokens on L2 are delegated to the specified Indexer on behalf of the specified Delegator without charging a delegation tax.
+
+### Will my unrealized rewards be transferred when I transfer my delegation?
+
+​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards.
+
+At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​
+
+### Is moving delegations to L2 mandatory? Is there a deadline?
+
+​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1?
+
+​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## Curation Signal
+
+### How do I transfer my curation?
+
+To transfer your curation, you will need to complete the following steps:
+
+1. Initiate signal transfer on Ethereum mainnet
+
+2. Specify an L2 Curator address\*
+
+3. Wait 20 minutes for confirmation
+
+\*If necessary - i.e. you are using a contract address.
+
+### How will I know if the subgraph I curated has moved to L2?
+
+When viewing the subgraph details page, a banner will notify you that this subgraph has been transferred. You can follow the prompt to transfer your curation. You can also find this information on the subgraph details page of any subgraph that has moved.
+
+### What if I do not wish to move my curation to L2?
+
+When a subgraph is deprecated you have the option to withdraw your signal. Similarly, if a subgraph has moved to L2, you can choose to withdraw your signal in Ethereum mainnet or send the signal to L2.
+
+### How do I know my curation successfully transferred?
+
+Signal details will be accessible via Explorer approximately 20 minutes after the L2 transfer tool is initiated.
+
+### Can I transfer my curation on more than one subgraph at a time?
+
+There is no bulk transfer option at this time.
+
+## Indexer Stake
+
+### How do I transfer my stake to Arbitrum?
+
+> Disclaimer: If you are currently unstaking any portion of your GRT on your Indexer, you will not be able to use L2 Transfer Tools.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+To transfer your stake, you will need to complete the following steps:
+
+1. Initiate stake transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm stake transfer on Arbitrum
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Will all of my stake transfer?
+
+You can choose how much of your stake to transfer. If you choose to transfer all of your stake at once, you will need to close any open allocations first.
+
+If you plan on transferring parts of your stake over multiple transactions, you must always specify the same beneficiary address.
+
+Note: You must meet the minimum stake requirements on L2 the first time you use the transfer tool. Indexers must send the minimum 100k GRT (when calling this function the first time). If leaving a portion of stake on L1, it must also be over the 100k GRT minimum and be sufficient (together with your delegations) to cover your open allocations.
+
+### How much time do I have to confirm my stake transfer to Arbitrum?
+
+\*\*\* You must confirm your transaction to complete the stake transfer on Arbitrum. This step must be completed within 7 days or stake could be lost.
+
+### What if I have open allocations?
+
+If you are not sending all of your stake, the L2 transfer tool will validate that at least the minimum 100k GRT remains in Ethereum mainnet and your remaining stake and delegation is enough to cover any open allocations. You may need to close open allocations if your GRT balance does not cover the minimums + open allocations.
+
+### Using the transfer tools, is it necessary to wait 28 days to unstake on Ethereum mainnet before transferring?
+
+No, you can transfer your stake to L2 immediately, there's no need to unstake and wait before using the transfer tool. The 28-day wait only applies if you'd like to withdraw the stake back to your wallet, on Ethereum mainnet or L2.
+
+### How long will it take to transfer my stake?
+
+It will take approximately 20 minutes for the L2 transfer tool to complete transferring your stake.
+
+### Do I have to index on Arbitrum before I transfer my stake?
+
+You can effectively transfer your stake first before setting up indexing, but you will not be able to claim any rewards on L2 until you allocate to subgraphs on L2, index them, and present POIs.
+
+### Can Delegators move their delegation before I move my indexing stake?
+
+No, in order for Delegators to transfer their delegated GRT to Arbitrum, the Indexer they are delegating to must be active on L2.
+
+### Can I transfer my stake if I'm using a GRT vesting contract / token lock wallet?
+
+Yes! The process is a bit different, because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the stake to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## Vesting Contract Transfer
+
+### How do I transfer my vesting contract?
+
+To transfer your vesting, you will need to complete the following steps:
+
+1. Initiate the vesting transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm vesting transfer on Arbitrum
+
+### How do I transfer my vesting contract if I am only partially vested?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount)
+
+2. Send some locked GRT through the transfer tool contract, to L2 to initialize the L2 vesting lock. This will also set their L2 beneficiary address.
+
+3. Send their stake/delegation to L2 through the "locked" transfer tool functions in the L1Staking contract.
+
+4. Withdraw any remaining ETH from the transfer tool contract
+
+### How do I transfer my vesting contract if I am fully vested?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+For those that are fully vested, the process is similar:
+
+1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount)
+
+2. Set your L2 address with a call to the transfer tool contract
+
+3. Send your stake/delegation to L2 through the "locked" transfer tool functions in the L1 Staking contract.
+
+4. Withdraw any remaining ETH from the transfer tool contract
+
+### Can I transfer my vesting contract to Arbitrum?
+
+You can transfer your vesting contract's GRT balance to a vesting contract in L2. This is a prerequisite for transferring stake or delegation from your vesting contract to L2. The vesting contract must hold a nonzero amount of GRT (you can transfer a small amount like 1 GRT to it if needed).
+
+When you transfer GRT from your L1 vesting contract to L2, you can choose the amount to send and you can do this as many times as you like. The L2 vesting contract will be initialized the first time you transfer GRT.
+
+The transfers are done using a Transfer Tool that will be visible on your Explorer profile when you connect with the vesting contract account.
+
+Please note that you will not be able to release/withdraw GRT from the L2 vesting contract until the end of your vesting timeline when your contract is fully vested. If you need to release GRT before then, you can transfer the GRT back to the L1 vesting contract using another transfer tool that is available for that purpose.
+
+If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2.
+
+### I'm using my vesting contract to stake on mainnet. Can I transfer my stake to Arbitrum?
+
+Yes, but if your contract is still vesting, you can only transfer the stake so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your stake to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas.
+
+### I'm using my vesting contract to delegate on mainnet. Can I transfer my delegations to Arbitrum?
+
+Yes, but if your contract is still vesting, you can only transfer the delegation so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your delegation to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas.
+
+### Can I specify a different beneficiary for my vesting contract on L2?
+
+Yes, the first time you transfer a balance and set up your L2 vesting contract, you can specify an L2 beneficiary. Make sure this beneficiary is a wallet that can perform transactions on Arbitrum One, i.e. it must be an EOA or a multisig deployed to Arbitrum One.
+
+If your contract is fully vested, you will not set up a vesting contract on L2; instead, you will set an L2 wallet address and this will be the receiving wallet for your stake or delegation on Arbitrum.
+
+### My contract is fully vested. Can I transfer my stake or delegation to another address that is not an L2 vesting contract?
+
+Yes. If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2.
+
+This allows you to transfer your stake or delegation to any L2 address.
+
+### My vesting contract is still vesting. How do I transfer my vesting contract balance to L2?
+
+These steps only apply if your contract is still vesting, or if you've used this process before when your contract was still vesting.
+
+To transfer your vesting contract to L2, you will send any GRT balance to L2 using the transfer tools, which will initialize your L2 vesting contract:
+
+1. Deposit some ETH into the transfer tool contract (this will be used to pay for L2 gas)
+
+2. Revoke protocol access to the vesting contract (needed for the next step)
+
+3. Give protocol access to the vesting contract (will allow your contract to interact with the transfer tool)
+
+4. Specify an L2 beneficiary address\* and initiate the balance transfer on Ethereum mainnet
+
+5. Wait 20 minutes for confirmation
+
+6. Confirm the balance transfer on L2
+
+\*If necessary - i.e. you are using a contract address.
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### Can I move my vesting contract back to L1?
+
+There is no need to do so because your vesting contract is still in L1. When you use the transfer tools, you just create a new contract in L2 that is connected with your L1 vesting contract, and you can send GRT back and forth between the two.
+
+### Why do I need to move my vesting contract to begin with?
+
+You need to set up an L2 vesting contract so that this account can own your stake or delegation on L2. Otherwise, there'd be no way for you to transfer the stake/delegation to L2 without "escaping" the vesting contract.
+
+### What happens if I try to cash out my contract when it is only partially vested? Is this possible?
+
+This is not a possibility. You can move funds back to L1 and withdraw them there.
+
+### What if I don't want to move my vesting contract to L2?
+
+You can keep staking/delegating on L1. Over time, you may want to consider moving to L2 to enable rewards there as the protocol scales on Arbitrum. Note that these transfer tools are for vesting contracts that are allowed to stake and delegate in the protocol. If your contract does not allow staking or delegating, or is revocable, then there is no transfer tool available. You will still be able to withdraw your GRT from L1 when available.

From 378a4402994722e7afb70565bd4f0467ec32db33 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:02 -0500
Subject: [PATCH 1041/3820] New translations l2-transfer-tools-faq.mdx
 (Marathi)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/mr/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/mr/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/mr/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..e2a1a4fe92a2
--- /dev/null
+++ b/website/pages/mr/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2 Transfer Tools FAQ
+---
+
+## सामान्य
+
+### L2 हस्तांतरण साधने काय आहेत?
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### मी इथरियम मेननेटवर वापरतो तेच वॉलेट मी वापरू शकतो का?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### मी 7 दिवसात माझे हस्तांतरण पूर्ण केले नाही तर काय होईल?
+
+L2 ट्रांस्फर टूल्स आपल्याला L1 वरून L2ला संदेश पाठविण्याच्या अर्बिट्रमच्या स्वभाविक विधानाचा वापर करतात. हा विधान "पुनः प्रयासयोग्य पर्याय" म्हणून ओळखला जातो आणि हा सर्व स्थानिक टोकन ब्रिजेस, अर्बिट्रम GRT ब्रिज यासह सहाय्यक आहे. आपण पुनः प्रयासयोग्य पर्यायांबद्दल अधिक माहिती [Arbitrum docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging) वाचू शकता.
+
+आपल्याला आपल्या संपत्तींच्या (सबग्राफ, स्टेक, प्रतिनिधित्व किंवा पुरवणी) L2ला स्थानांतरित केल्यास, एक संदेश अर्बिट्रम GRT ब्रिजमध्ये पाठविला जातो ज्याने L2वर पुनः प्रयासयोग्य पर्याय तयार करतो. स्थानांतरण उपकरणात्रूटील वैल्यूत्या किंवा संचलनसाठी काही ईटीएच वॅल्यू आहे, ज्यामुळे 1) पर्याय तयार करण्यासाठी पैसे देणे आणि 2) L2मध्ये पर्याय संचालित करण्यासाठी गॅस देणे ह्याचा वापर केला जातो. परंतु, पर्याय संचालनाच्या काळात गॅसची किंमते वेळेत बदलू शकतात, ज्यामुळे ही स्वयंप्रयत्न किंवा संचालन प्रयत्न अपयशी होऊ शकतात. जेव्हा ती प्रक्रिया अपयशी होते, तेव्हा अर्बिट्रम ब्रिज किंवा 7 दिवसापर्यंत पुन्हा प्रयत्न करण्याची क्षमता आहे, आणि कोणत्याही व्यक्ती त्या "पुनर्मिलन" पर्यायाचा प्रयत्न करू शकतो (त्यासाठी अर्बिट्रमवर काही ईटीएच स्थानांतरित केलेले असणे आवश्यक आहे).
+
+ही आपल्याला सगळ्या स्थानांतरण उपकरणांमध्ये "पुष्टीकरण" चरण म्हणून ओळखता - आपल्याला अधिकांशपेक्षा अधिक आपल्याला स्वयंप्रयत्न सध्याच्या वेळेत स्वयंप्रयत्न सध्याच्या वेळेत स्वतः संचालित होईल, परंतु आपल्याला येते कि ते दिले आहे ह्याची तपासणी करणे महत्वपूर्ण आहे. आपल्याला किंवा 7 दिवसात कोणत्याही सफल पुनर्मिलनाचे प्रयत्न केले त्यामुळे प्रयत्नशील नसत्या आणि त्या 7 दिवसांत कोणताही प्रयत्न नसत्याने, अर्बिट्रम ब्रिजने पुनर्मिलन पर्यायाचा त्याग केला आहे, आणि आपली संपत्ती (सबग्राफ, स्टेक, प्रतिनिधित्व किंवा पुरवणी) वेळेत विचली जाईल आणि पुनर्प्राप्त केली जाऊ शकणार नाही. ग्राफचे मुख्य डेव्हलपर्सन्सने या परिस्थितियांच्या जाणीवपणे प्राणीसमूह ठरविले आहे आणि त्याच्या अगोदर पुनर्मिलन केले जाईल, परंतु याच्यातून, आपल्याला आपल्या स्थानांतरणाची पूर्ण करण्याची जबाबदारी आहे. आपल्याला आपल्या व्यवहाराची पुष्टी करण्यात किंवा संचालनाची समस्या आहे का, कृपया [this form](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) वापरून संपूर्ण डेव्हलपर्सन्सची मदत करण्याची क्षमता आहे.
+
+### I started my delegation/stake/curation transfer and I'm not sure if it made it through to L2, how can I confirm that it was transferred correctly?
+
+If you don't see a banner on your profile asking you to finish the transfer, then it's likely the transaction made it safely to L2 and no more action is needed. If in doubt, you can check if Explorer shows your delegation, stake or curation on Arbitrum One.
+
+If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire.
+
+## सबग्राफ हस्तांतरण
+
+### मी माझा सबग्राफ कसा हस्तांतरित करू?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+तुमचा सबग्राफ हस्तांतरित करण्यासाठी, तुम्हाला खालील चरण पूर्ण करावे लागतील:
+
+1. Ethereum mainnet वर हस्तांतरण सुरू करा
+
+2. पुष्टीकरणासाठी 20 मिनिटे प्रतीक्षा करा
+
+3. आर्बिट्रमवर सबग्राफ हस्तांतरणाची पुष्टी करा\*
+
+4. आर्बिट्रम वर सबग्राफ प्रकाशित करणे समाप्त करा
+
+5. क्वेरी URL अपडेट करा (शिफारस केलेले)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### मी माझे हस्तांतरण कोठून सुरू करावे?
+
+आपल्याला स्थानांतरण सुरू करण्याची क्षमता आहे Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) किंवा कोणत्याही सबग्राफ तपशील पृष्ठापासून सुरू करू शकता. सबग्राफ तपशील पृष्ठावर "सबग्राफ स्थानांतरित करा" बटणवर क्लिक करा आणि स्थानांतरण सुरू करा.
+
+### माझा सबग्राफ हस्तांतरित होईपर्यंत मला किती वेळ प्रतीक्षा करावी लागेल
+
+स्थानांतरणासाठी किंमतीतून प्रायः 20 मिनिटे लागतात. आर्बिट्रम ब्रिज आपल्याला स्वत: स्थानांतरण स्वयंप्रयत्नातून पूर्ण करण्यासाठी पारंपारिकपणे काम करत आहे. कितीतरी प्रकारांत स्थानांतरण केल्यास, गॅस किंमती वाढू शकतात आणि आपल्याला परिपुष्टीकरण पुन्हा करण्याची आवश्यकता लागू शकते.
+
+### मी L2 मध्ये हस्तांतरित केल्यानंतर माझा सबग्राफ अजूनही शोधण्यायोग्य असेल का?
+
+आपला सबग्राफ केवळ त्या नेटवर्कवर शोधन्यायला येतो, ज्यावर तो प्रकाशित केला जातो. उदाहरणार्थ, आपला सबग्राफ आर्बिट्रम वनवर आहे तर आपल्याला तो केवळ आर्बिट्रम वनवरच्या एक्सप्लोररमध्ये शोधू शकता आणि आपल्याला इथे एथेरियमवर शोधायला सक्षम नसेल. कृपया पृष्ठाच्या वरील नेटवर्क स्विचरमध्ये आर्बिट्रम वन निवडल्याची आपल्याला कसे सुनिश्चित करण्याची आवश्यकता आहे. स्थानांतरणानंतर, L1 सबग्राफ विकलप म्हणून दिसणारा.
+
+### माझा सबग्राफ हस्तांतरित करण्यासाठी प्रकाशित करणे आवश्यक आहे का?
+
+सबग्राफ स्थानांतरण उपकरणाचा लाभ घेण्यासाठी, आपल्याला आपल्या सबग्राफला आधीच प्रकाशित केलेला पाहिजे आणि त्याच्या सबग्राफच्या मालक वॉलेटमध्ये काही परिपुष्टी संकेत असणे आवश्यक आहे. आपला सबग्राफ प्रकाशित नसल्यास, आपल्याला साधारणपणे आर्बिट्रम वनवर सीधे प्रकाशित करण्यात योग्य आहे - संबंधित गॅस फीस खूपच किमान असतील. आपल्याला प्रकाशित सबग्राफ स्थानांतरित करू इच्छित असल्यास, परंतु मालक खाते त्यावर कोणतीही प्रतिसाद संकेत दिली नाही, तर आपण त्या खाते पासून थोडीसी परिपुष्टी (उदा. 1 GRT) संकेतिक करू शकता; कृपया "स्वत: स्थानांतरित होणारी" संकेत निवडायला नक्की करा.
+
+### माझ्या सबग्राफच्या इथेरियम मुख्य नेटवर्कचा संस्करण हस्तांतरित करताना Arbitrum वर काय होतं?
+
+आर्बिट्रमकडे आपल्या सबग्राफ स्थानांतरित करण्यानंतर, एथेरियम मुख्यनेट आवृत्ती विकलप म्हणून दिली जाईल. आपल्याला आपल्या क्वेरी URL वरील बदल करण्याची सल्ला आहे की त्याच्या 48 तासांत दिला जाईल. हेरंब विलंबप्रदान केलेले आहे ज्यामुळे आपली मुख्यनेट URL सक्रिय ठेवली जाईल आणि कोणत्याही तृतीय पक्षाच्या dapp समर्थनाच्या आधी अद्यतनित केल्या जाऊ शकतात.
+
+### मी हस्तांतरित केल्यानंतर, मला आर्बिट्रमवर पुन्हा प्रकाशित करण्याची देखील आवश्यकता आहे का?
+
+२० मिनिटांच्या स्थानांतरण कालाच्या नंतर, आपल्याला स्थानांतरण पूर्ण करण्यासाठी UIमध्ये एक संचित्र व्यवहाराच्या माध्यमातून पुनः पुष्टीकरण करण्याची आवश्यकता आहे, परंतु स्थानांतरण उपकरण तुम्हाला ह्याच्या माध्यमातून प्रेषित केल्यास, ते तुम्हाला मार्गदर्शन करेल. आपल्या L1 एंडपॉइंटने स्थानांतरण कालाच्या नंतर आणि एक क्षणानंतर समर्थित राहणारे आहे. तुम्हाला आपल्याला सुविधानुसार एंडपॉइंटच्या अद्यतनित करण्याची प्रोत्साहने आहे.
+
+### Will my endpoint experience downtime while re-publishing?
+
+It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the subgraph on L1 and whether they keep indexing it until the subgraph is fully supported on L2.
+
+### एल2 व Ethereum मुख्य नेटवर्कवर प्रकाशन आणि संस्करणदेखील सारखं आहे का?
+
+Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the subgraph.
+
+### पुन्हा प्रकाशित करताना माझ्या एंडपॉईंटला डाउन-टाइम असेल का?
+
+आपण "स्वत: स्थानांतरित होणारी" संकेत निवडल्यास, आपल्या आपल्या स्वत: स्थानांतरित करणार्या सबग्राफसह 100% आपल्या पुरवणीने निवडलेल्या स्थानांतरण होईल. सबग्राफच्या सर्व स्थानांतरण संकेताच्या स्थानांतरणाच्या क्षणी जीआरटीत रूपांतरित केली जाईल, आणि आपल्या पुरवणीसंकेताशी संबंधित जीआरटी आपल्याला L2 सबग्राफवर संकेत वितरित करण्यासाठी वापरली जाईल.
+
+इतर क्युरेटर्सनी त्याच्या भागाची GRT वापरून घेण्याची किंवा त्याच्या सबग्राफवर सिग्नल मिंट करण्यासाठी त्याची GRT L2वर हस्तांतरित करण्याची परवानगी आहे.
+
+### तुम्ही आपले सबग्राफ L2 वर हस्तांतरित केल्यानंतर पुन्हा Ethereum मुख्य नेटवर्कवर परत करू शकता का?
+
+स्थानांतरित केल्यानंतर, आपल्या आर्बिट्रम वनवरच्या सबग्राफची एथेरियम मुख्यनेट आवृत्ती विकलप म्हणून दिली जाईल. आपल्याला मुख्यनेटवर परत जाण्याची इच्छा आहे किंवा, आपल्याला मुख्यनेटवर परत जाण्याची इच्छा आहे तर आपल्याला पुन्हा डिप्लॉय आणि प्रकाशित करण्याची आवश्यकता आहे. परंतु आर्बिट्रम वनवर परत गेल्याच्या बदलाच्या दिल्लाला मुख्यनेटवरील सूचना पूर्णपणे त्यात दिलेली आहे.
+
+### माझे हस्तांतरण पूर्ण करण्यासाठी मला ब्रिज्ड ETH का आवश्यक आहे?
+
+आर्बिट्रम वनवरील गॅस फीस आर्बिट्रम वनवर स्थानांतरित केलेल्या इथरियम (अर्थात Arbitrum One वर स्थानांतरित केलेल्या) ईटीएचवारे चुकतात. परंतु ते गॅस फीस अत्यंत खूप किमान आहेत त्यासाठी ज्यातरी ईथरियम मुख्यनेटवरच्या गॅस फीसेसारखे आहे.
+
+## प्रतिनिधी
+
+### मी माझे प्रतिनिधी मंडळ कसे हस्तांतरित करू?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+तुमच्या प्रतिनियुक्तीची हस्तांतरण करण्यासाठी, तुम्हाला खालील प्रक्रिया पूर्ण करण्याची आवश्यकता आहे:
+
+1. Ethereum mainnet वर शिष्टमंडळ हस्तांतरण सुरू करा
+2. पुष्टीकरणासाठी 20 मिनिटे प्रतीक्षा करा
+3. आर्बिट्रमवर प्रतिनिधी मंडळाच्या हस्तांतरणाची पुष्टी करा
+
+\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### मी इथरियम मेननेटवर खुल्या वाटपासह हस्तांतरण सुरू केल्यास माझ्या पुरस्कारांचे काय होईल?
+
+If the Indexer to whom you're delegating is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer.
+
+### मी सध्या ज्या इंडेक्सरला नियुक्त करतो तो आर्बिट्रम वन वर नसल्यास काय होईल?
+
+L2 स्थानांतरण साध्य असेल तेव्हा जर तुम्ही प्रतिनियुक्त केलेल्या इंडेक्सरने स्वतःच्या स्टेकला Arbitrum वर स्थानांतरित केलेल्या आहे, तर आपल्याला L2 स्थानांतरण साध्य होईल.
+
+### क्या स्थानिक लेखकों को अन्य इंडेक्सर को प्रतिष्ठित करने का विकल्प है?
+
+If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to.
+
+### जर मी L2 वर माझ्याला प्रतिष्ठित करणारे इंडेक्सर शोधू शकत नसल्यास काय होईल?
+
+L2 हस्तांतरण साधन स्वतःच्या तंतून आपण आधीपासून विनिमय केलेल्या विनिमयकर्त्याला स्वत: प्रमाणे ओळखतो.
+
+### तुम्ही नवीन किंवा विविध अनुक्रमणिकांकडून आपल्याच्या प्रतिनियुक्तीला मिश्रित व किंवा 'पसरवा' द्यायला सक्षम असाल का, किंवा आपल्याच्या अगोदरच्या अनुक्रमणिकाकडून?
+
+L2 स्थानांतरण उपकरण आपल्या देगा लगेच किंवा तुम्ही आत्ताच दिलेल्या इंडेक्सरला हे स्वत: स्थानांतरित करेल. एकदा आपल्याला L2 वर स्थानांतरित केलं आहे, तुम्ही देगा किंवा पुनर्मित्रीकरण करून, थॉइंग कालाची प्रतीक्षा करून, आणि तुम्हाला आपल्या देगा विभागण्याचा निर्णय घेण्याची संधी आहे.
+
+### मी कूलडाउन कालावधीच्या अधीन आहे किंवा मी L2 प्रतिनिधी हस्तांतरण साधन वापरल्यानंतर लगेच पैसे काढू शकतो?
+
+स्थानांतरण साध्य करणारे टूल आपल्याला तुरंत L2 वर स्थानांतरित करण्याची परवाह देतो. जर आपल्याला पुन्हा प्रतिनियुक्ती करण्याची इच्छा असली तर आपल्याला थॉइंग पेरिअडसाठी प्रतीक्षा करावी लागते. परंतु, जर कोणत्याही इंडेक्सरने आपल्या सर्व स्टेकला L2 वर स्थानांतरित केलं आहे, तर आपल्याला Ethereum मुख्य नेटवरील तुरंत विथ्ड्रॉ करण्याची संधी आहे.
+
+### मी माझ्या प्रतिनिधींचे हस्तांतरण न केल्यास माझ्या पुरस्कारांवर नकारात्मक परिणाम होऊ शकतो का?
+
+आपल्याला वाटले आहे की भविष्यात सर्व नेटवर्क सहभाग आर्बिट्रम वनमध्ये होईल.
+
+### माझ्या प्रतिनियुक्तीची L2ला हस्तांतरिती किती वेळ लागतो?
+
+A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### जर आपल्याला GRT वेस्टिंग कॉन्ट्रॅक्ट/टोकन लॉक वॉलेटचा वापर आहे, तर आपल्याला प्रतिनियुक्ती हस्तांतरित करण्याची क्षमता आहे का?
+
+होय! प्रक्रिया काही वेगवेगळी आहे कारण वेस्टिंग कॉन्ट्रॅक्ट्स L2 गॅससाठी आवश्यक असलेले ETH फॉरवर्ड करू शकत नाहीत, म्हणजे आपल्याला त्यापूर्वीक ठेवावं आवश्यक आहे. जर आपल्या वेस्टिंग कॉन्ट्रॅक्ट पूर्णपणे वेस्टेड नसलेला आहे, तर आपल्याला पहिल्यांदाच L2 वरील वेस्टिंग कॉन्ट्रॅक्टवर एक सहकार्यक वेस्टिंग कॉन्ट्रॅक्ट सुरू करण्याची आवश्यकता आहे आणि तुम्ही फक्त हे ल2 वेस्टिंग कॉन्ट्रॅक्टला प्रतिनियुक्ती स्थानांतरित करण्याच्या सर्वोत्तम वेळी होईल. वेस्टिंग लॉक वॉलेट वापरून Explorer ला कनेक्ट केल्यास, Explorer वरील UI तुमच्याला हे प्रक्रियेत मार्गदर्शन करू शकतो.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### काही डेलिगेशन कर आहे का?
+
+नाही. L2 वर प्राप्त झालेले टोकन्स निर्दिष्ट डेलिगेटरच्या नावे घेतल्याने निर्दिष्ट इंडेक्सरवर डेलिगेट केले जातात आणि कोणत्याही डेलिगेशन करारक वर्गासाठी कर केले जात नाही.
+
+### Will my unrealized rewards be transferred when I transfer my delegation?
+
+​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards.
+
+At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​
+
+### Is moving delegations to L2 mandatory? Is there a deadline?
+
+​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1?
+
+​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## क्युरेशन सिग्नल
+
+### मी माझे क्युरेशन कसे हस्तांतरित करू?
+
+तुमच्या कुरेशनची हस्तांतरण करण्यासाठी, तुम्हाला खालील प्रक्रिया पूर्ण करण्याची आवश्यकता आहे:
+
+1. इथरियम मेननेटवर सिग्नल ट्रान्सफर सुरू करा
+
+2. L2 क्युरेटर पत्ता निर्दिष्ट करा\*
+
+3. पुष्टीकरणासाठी 20 मिनिटे प्रतीक्षा करा
+
+\*आवश्यक असल्यास - उदा. तुम्ही एक कॉन्ट्रॅक्ट पत्ता वापरत आहात.
+
+### मी क्युरेट केलेला सबग्राफ L2 वर गेला असल्यास मला कसे कळेल?
+
+सबग्राफ तपशील पृष्ठाची पाहणी केल्यास, एक बॅनर आपल्याला सूचित करेल की हा सबग्राफ स्थानांतरित केलेला आहे. आपल्याला सुचवल्यास, आपल्या पुरवणीचे स्थानांतरण करण्यासाठी प्रॉम्प्ट अनुसरण करू शकता. आपल्याला ह्या माहितीला सापडण्याची किंवा स्थानांतरित केलेल्या कोणत्याही सबग्राफच्या तपशील पृष्ठावर मिळवू शकता.
+
+### मी माझे क्युरेशन L2 वर हलवू इच्छित नसल्यास काय करावे?
+
+कोणत्याही सबग्राफला प्राकृतिक रितीने प्रतिसादित केल्यानंतर, आपल्याला आपल्या सिग्नलला वापरून घेण्याची पर्वाह आहे. तसेच, आपल्याला जर सबग्राफ L2 वर हस्तांतरित केलेला असेल तर, आपल्याला आपल्या सिग्नलला ईथेरियम मेननेटवरून वापरून घेण्याची किंवा L2 वर सिग्नल पाठवण्याची पर्वाह आहे.
+
+### माझे क्युरेशन यशस्वीरित्या हस्तांतरित झाले हे मला कसे कळेल?
+
+L2 हस्तांतरण साधन सुरू केल्यानंतर, संकेत तपशील २० मिनिटांनंतर Explorer मध्ये पहिल्या दिशेने प्रवेशक्षम होईल.
+
+### किंवा तुम्ही एकापेक्षा अधिक सबग्राफवर एकावेळी आपल्या कुरेशनची हस्तांतरण करू शकता का?
+
+यावेळी मोठ्या प्रमाणात हस्तांतरण पर्याय नाही.
+
+## इंडेक्सर स्टेक
+
+### मी माझे स्टेक आर्बिट्रमला कसे हस्तांतरित करू?
+
+> अस्वीकरण: तुम्ही सध्या तुमच्या इंडेक्सरवर तुमच्या GRT चा कोणताही भाग अनस्टॅक करत असल्यास, तुम्ही L2 ट्रान्सफर टूल्स वापरू शकणार नाही.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+तुमचा हिस्सा हस्तांतरित करण्यासाठी, तुम्हाला खालील चरण पूर्ण करावे लागतील:
+
+1. इथरियम मेननेटवर स्टेक ट्रान्सफर सुरू करा
+
+2. पुष्टीकरणासाठी 20 मिनिटे प्रतीक्षा करा
+
+3. आर्बिट्रमवर स्टेक ट्रान्सफरची पुष्टी करा
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### सर्व माझ्या स्टेकची हस्तांतरण होईल का?
+
+आपल्याला आपल्या स्टेकच्या किती ट्रान्सफर करायचं तुमच्या स्वतःच्या निर्णयाक्रमाने घेतला जाऊ शकतो. जर आपण आपला संपूर्ण स्टेक एकदम ट्रान्सफर करण्याचा निर्णय घेतला तर, तुम्हाला सर्व उघड्या आवंटनसह पहिल्यांदा बंद करावा लागेल.
+
+जर आपली विचारायला आहे की आपला स्टेक विभागांत काढण्याच्या किंवा मल्टिपल व्यवहारांत काढण्याच्या योजना आहे, तरीही आपल्याला नेहमीच समान लाभार्थ्य पत्ता स्पष्टपणे सूचित करायचं आवश्यक आहे.
+
+सूचना: आपल्याला पहिल्यांदा ट्रान्सफर टूल वापरण्याच्या वेळी L2 वरील किमान स्टेक आवश्यकता आहे. इंडेक्सर्सने (ही क्रिया पहिल्यांदा केल्याने) किमान 100 हजार GRT पाठवावं लागेल. L1 वर किंवा त्यातला किमान 100 हजार GRT आणि आपल्या सुनिवादांसह आपल्या उघड्या आवंटनांची कवर करणारी सापडणारी पर्याप्त स्टेक असावी.
+
+### आर्बिट्रममध्ये माझे स्टेक हस्तांतरण निश्चित करण्यासाठी मला किती वेळ लागेल?
+
+\*\*\* आपल्याला आपल्या स्टेकची हस्तांतरण पूर्ण करण्यासाठी आपल्या व्यवहाराची पुष्टी करण्याची आवश्यकता आहे, ही पाने 7 दिवसांमध्ये पूर्ण केली पाहिजे किंवा स्टेक हरून जाऊ शकतो.
+
+### माझ्याकडे खुले वाटप असल्यास काय?
+
+जर आपला स्टेक सर्व काढणार नसल्यास, L2 ट्रान्सफर टूल तपासणार आहे की किमान 100 हजार GRT ईथेरियम मेननेटवर अद्याप आहे आणि आपला शिल्लक स्टेक आणि सुनिवाद आपल्या उघड्या आवंटनांची कवर करणारी पर्याप्त आहे किंवा नाही, त्यातल्या न्यायमूलक आवंटने बंद करण्याची आवश्यकता आहे जर आपले GRT शिल्लक किमती + उघड्या आवंटनांची कवर करत नसल्यास.
+
+### ट्रांसफर टूल्सचा वापर करताना, हस्तांतरण करण्यापूर्वी 28 दिवसांच्या काळापासून इथेरियम मुख्य नेटवर्कवरून अनस्टेक करणे आवश्यक आहे का?
+
+नाही, आपल्याला आपल्या स्थानांतरणासाठी स्थानांतरण उपकरणाचा वापर करण्यापूर्वी स्थानांतरित करण्याची आवश्यकता नाही. 28 दिवसांच्या प्रतिमानात, आपल्याला आपल्य्या वॉलेटवर स्थानांतरित करण्याच्या आवश्यकता आहे, ईथेरियम मुख्यनेट किंवा L2 वर.
+
+### स्टेक हस्तांतरणासाठी किती वेळ लागेल?
+
+L2 स्थानांतरण उपकरणाने आपल्याच्या स्थानांतरणाच्या प्रक्रियेच्या पूर्णत्वाकरीता आणखी आधीपासून २० मिनिटे लागणार आहेत.
+
+### माझ्या शेअर्स हस्तांतरित करण्यापूर्वी मला Arbitrum वर सूचीबद्ध करण्याची आवश्यकता आहे का?
+
+आपल्याला स्वारूपण ठरविण्यापूर्वीच आपले स्टेक प्रभावीपणे स्थानांतरित करू शकता, परंतु L2 वर कोणत्या उत्पादनाची मागणी करण्याची अनुमती नसेल तोंद, ते लागू करण्यास आपल्याला L2 वरील सबग्राफ्सला आवंटन देण्याची, त्यांची सूचीबद्धीकरण करण्याची आणि POIs प्रस्तुत करण्याची आवश्यकता आहे, ते तुम्ही L2 वर कोणत्याही प्रामोड पावण्याच्या पर्यायी नसेल.
+
+### मी माझा इंडेक्सिंग स्टेक हलवण्यापूर्वी प्रतिनिधी त्यांचे प्रतिनिधी हलवू शकतात का?
+
+नाही, सुचवलेल्या Delegators ला आपल्या हस्तांतरित GRT ला Arbitrum वर त्यांच्या ध्येयकांना सहमती आहे, त्यासाठी त्यांच्याकडून L2 वर सक्रिय असणार्या अनुक्रमणिकेला आवश्यक आहे.
+
+### मी GRT वेस्टिंग कॉन्ट्रॅक्ट/टोकन लॉक वॉलेट वापरत असल्यास मी माझा स्टेक ट्रान्सफर करू शकतो का?
+
+होय! प्रक्रिया काही वेगवेगळी आहे, कारण वेस्टिंग कॉन्ट्रॅक्ट्स L2 गॅससाठी आवश्यक असलेले ETH प्रायोगिक नही जाऊ शकतात, म्हणजे आपल्याला त्यापूर्वीक ठेवावं आवश्यक आहे. आपल्या वेस्टिंग कॉन्ट्रॅक्ट आपल्याला पूर्णत: वेस्टेड नसल्यास, आपल्याला पहिल्यांदाच L2 वरील वेस्टिंग कॉन्ट्रॅक्टवर आपल्या वेस्टिंग कॉन्ट्रॅक्टला ट्रांसफर करण्याची आवश्यकता आहे आणि तुम्हाला हे L2 वेस्टिंग कॉन्ट्रॅक्ट सुरू करण्याची आवश्यकता आहे. Explorer वरील UI तुमच्याला हे प्रक्रियेत नेत्रुत्व करण्याच्या प्रक्रियेत मार्गदर्शन करू शकतो, जेथे आपल्याला वेस्टिंग लॉक वॉलेट वापरून Explorer ला कनेक्ट केल्यास.
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## वेस्टिंग कॉन्ट्रॅक्ट ट्रान्सफर
+
+### मी माझा वेस्टिंग करार कसा हस्तांतरित करू?
+
+तुमच्या वेस्टिंगची हस्तांतरण करण्यासाठी, तुम्हाला खालील प्रक्रिया पूर्ण करण्याची आवश्यकता आहे:
+
+1. ईथेरियम मेननेटवर वेस्टिंग हस्तांतरण सुरू करा
+
+2. पुष्टीकरणासाठी 20 मिनिटे प्रतीक्षा करा
+
+3. आर्बिट्रमवर वेस्टिंग ट्रांस्फरची पुष्टी करा
+
+### मी केवळ अंशतः निहित असल्यास माझा वेस्टिंग करार कसा हस्तांतरित करू?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. हस्तांतरण साधन संविदाच्या एकांत्रीत थेट ETH जमा करा (UI एक उचित मात्रा आकलन करण्यात मदत करू शकते)
+
+2. लॉक्ड GRT किंवा बंद झालेल्या GRTला स्थानांतरण उपकरण कॉन्ट्रॅक्टद्वारे L2ला पाठवा, ल2ला स्थानांतरित करण्यासाठी. ही प्रक्रिया त्यांना त्याच्या L2 वेस्टिंग लॉक ची सुरुवात करण्याचीची पर्याय देतेल. हे त्याच्या L2 लाभार्थ्याच्या पत्त्यासहही सेट करेल.
+
+3. त्यांनी आपल्या स्थानिकीकरण/अधिग्रहाची धार लॉक केल्याशिवाय, "लॉक्ड" हस्तांतरण साधने L1Staking कर्मचेरीतील कार्य करून L2ला पाठवा.
+
+4. कोणत्याही शिल्लक ETH बाकी आहे त्याच्या ट्रांस्फर टूल कॉन्ट्रॅक्टमधून विचला
+
+### मी पूर्ण निहित असल्यास माझा वेस्टिंग करार कसा हस्तांतरित करू?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+पूर्णपणे निहित असलेल्यांसाठी, प्रक्रिया समान आहे:
+
+1. हस्तांतरण साधन संविदाच्या एकांत्रीत थेट ETH जमा करा (UI एक उचित मात्रा आकलन करण्यात मदत करू शकते)
+
+2. तुमचा L2 पत्ता ट्रांस्फर टूल कॉन्ट्रॅक्टला कॉल करून सेट करा
+
+3. आपली शेअर/प्रतिनियुक्ती "लॉक" केलेल्या हस्तांतरण साधन फंक्शन्सद्वारे L1 Staking संविदातील L2 वर पाठवा.
+
+4. कोणत्याही शिल्लक ETH बाकी आहे त्याच्या ट्रांस्फर टूल कॉन्ट्रॅक्टमधून विचला
+
+### मी माझा वेस्टिंग कॉन्ट्रॅक्ट आर्बिट्रमकडे हस्तांतरित करू शकतो का?
+
+तुम्ही आपल्या वेस्टिंग कॉन्ट्रॅक्टच्या GRT शिल्लकाची L2 वरील एक वेस्टिंग कॉन्ट्रॅक्टला स्थानांतरित करू शकता. हे आपल्याला आपल्या वेस्टिंग कॉन्ट्रॅक्टकिंवा L2 वरील आपल्या स्थानांतरण किंवा प्रतिनियुक्तीसाठी अपायरीक्षक आहे. वेस्टिंग कॉन्ट्रॅक्टला एक अवैध GRT अकाउंट ठेवणे आवश्यक आहे (जर आवश्यक असल्यास, तुम्ही त्याच्याकडून 1 GRT असे एक सारखे किंवा त्याच्यापुढे स्थानांतरित करू शकता).
+
+तुम्ही आपल्या L1 वेस्टिंग कॉन्ट्रॅक्टमधून L2 ला GRT स्थानांतरित करता, तुम्ही पाठविण्याच्या रक्कम निवडू शकता आणि तुम्हाला तुमच्याकडून जेव्हा आवश्यक असेल त्या अनेकदमी वेळा हे करू शकता. L2 वेस्टिंग कॉन्ट्रॅक्ट पहिल्यांदाच आपल्याला GRT स्थानांतरित करताना प्रारंभ केला जाईल.
+
+हे स्थानांतरण वेस्टिंग कॉन्ट्रॅक्ट खात्याच्या संपर्क केल्याने दिलेल्या ट्रॅन्स्फर टूलच्या माध्यमाने केले जातात. जेव्हा आपल्याला वेस्टिंग कॉन्ट्रॅक्ट खात्याच्या संपर्काने कनेक्ट करता, तेव्हा आपल्या एक्सप्लोरर प्रोफाइलवर दिलेल्या ट्रॅन्स्फर टूलचा दृश्य होईल.
+
+कृपया लक्षात घ्या कि आपल्याला आपल्य्या वेस्टिंग वेळापत्रिकेच्या शेवटी त्याच्या वेस्टेड असल्यावर तुम्ही L2 वेस्टिंग कॉन्ट्रॅक्टमधून GRT मोजण्याची किंवा विथ्ड्रॉ करण्याची क्षमता नसेल. जर आपल्याला त्यापूर्वी ग्रीटी छोडण्याची आवश्यकता असली तर आपण त्या उद्देशाने उपलब्ध आहे त्यासाठी इतर एक ट्रॅन्स्फर टूलचा वापर करू शकता, ज्याचा त्याच्यासाठी उपलब्ध आहे.
+
+जर आपल्याला वेस्टिंग कॉन्ट्रॅक्टच्या शिल्लकाची L2 वर कोणतीही अकाउंट स्थानांतरित केली नाही आणि आपला वेस्टिंग कॉन्ट्रॅक्ट पूर्णपणे वेस्टेड आहे, तर आपल्याला आपल्या वेस्टिंग कॉन्ट्रॅक्टला L2 वर स्थानांतरित करू नये. परंतु, तुम्ही आपल्याला L2 वरील एक सामान्य वॉलेटवर प्रतिनियुक्ती किंवा स्थानांतरण स्थापित करण्यासाठी ट्रॅन्सफर टूल्स वापरू शकता, आणि या साधारण वॉलेटवर तुमची स्थानांतरण किंवा प्रतिनियुक्ती सीधे L2 वर स्थानांतरित करू शकता.
+
+### मी मेननेटवर स्टेक करण्यासाठी माझा वेस्टिंग कॉन्ट्रॅक्ट वापरत आहे. मी माझा हिस्सा आर्बिट्रमकडे हस्तांतरित करू शकतो का?
+
+होय, परंतु जर आपल्या कॉन्ट्रॅक्टला अद्याप वेस्टिंग आहे, तर आपण केवळ त्याच्याकडून स्थानांतरण करू शकता, ज्याची स्वामित्व आपल्या L2 वेस्टिंग कॉन्ट्रॅक्टच्या आहे. तुम्हाला सध्याच्या प्रक्रियेकरीता हे L2 कॉन्ट्रॅक्ट आपल्याला Explorer वरील वेस्टिंग कॉन्ट्रॅक्ट ट्रांसफर टूलच्या मदतीने केले पाहिजे. जर आपल्या कॉन्ट्रॅक्टला पूर्णपणे वेस्टेड आहे, तर तुम्ही तुमच्या L2 वरील किंवा किमान ETH ला L2 गॅससाठी भरून त्याच्यापुढे स्थापित करावं आवश्यक आहे आणि आपल्याला त्याच्याकडून स्थानांतरित करायला आवश्यक आहे.
+
+### मी मेननेटवर प्रतिनिधी करण्यासाठी माझा वेस्टिंग कॉन्ट्रॅक्ट वापरत आहे. मी माझे प्रतिनिधी मंडळ आर्बिट्रमकडे हस्तांतरित करू शकतो का?
+
+होय, परंतु जर आपल्याच्या कॉन्ट्रॅक्टला अद्याप वेस्टिंग आहे, तर आपण केवळ त्याच्याकडून प्रतिनियुक्ती स्थानांतरित करू शकता, ज्याची स्वामित्व आपल्या L2 वेस्टिंग कॉन्ट्रॅक्टच्या आहे. तुम्हाला सध्याच्या प्रक्रियेकरीता हे L2 कॉन्ट्रॅक्ट आपल्याला Explorer वरील वेस्टिंग कॉन्ट्रॅक्ट ट्रांसफर टूलच्या मदतीने केले पाहिजे. जर आपल्या कॉन्ट्रॅक्टला पूर्णपणे वेस्टेड आहे, तर तुम्ही तुमच्या L2 वरील किंवा किमान ETH ला L2 गॅससाठी भरून त्याच्यापुढे स्थापित करावं आवश्यक आहे आणि आपल्याला त्याच्याकडून स्थानांतरित करायला आवश्यक आहे.
+
+### L2 वर माझ्या वेस्टिंग करारासाठी मी वेगळा लाभार्थी निर्दिष्ट करू शकतो का?
+
+होय, पहिल्यांदाच आपल्याच्या शिल्लकाच्या स्थानांतरित करण्याच्या वेळी आपल्याला आपल्या L2 वेस्टिंग कॉन्ट्रॅक्टमध्ये बॅनेफिशरचा स्पष्ट उल्लेख करू शकता. कृपया खाते निर्वाचित केला पाहिजे आणि खाता Arbitrum One वर व्यवहार करू शकतो, अर्थात ते एक EOA किंवा Arbitrum One वर डिप्लॉय केलेल्या मल्टीसिगच्या एक महत्त्वाच्या काम करू शकतो.
+
+जर आपल्या कॉन्ट्रॅक्टला पूर्णपणे वेस्टेड आहे, तर आपल्याला L2 वर वेस्टिंग कॉन्ट्रॅक्ट स्थापित करायला हवाच नाही; त्यामुळे, आपल्याला एल 2 वॉलेट पत्ता सेट करायला हवा आणि त्याचं अर्बिट्रमवर आपल्या स्टेक किंवा प्रतिनियुक्तीसाठी प्राप्त केलेल्या वॉलेट होईल.
+
+### माझा करार पूर्णपणे निहित आहे. मी माझा स्टेक किंवा डेलिगेशन L2 वेस्टिंग कॉन्ट्रॅक्ट नसलेल्या दुसर्‍या पत्त्यावर हस्तांतरित करू शकतो का?
+
+होय. जर आपल्याला कोणतेही वेस्टिंग कॉन्ट्रॅक्ट शिल्लक L2 वर स्थानांतरित केलेले नाहीत आणि आपल्याचा वेस्टिंग कॉन्ट्रॅक्ट पूर्णपणे वेस्टेड आहे, तर आपल्याला आपल्या वेस्टिंग कॉन्ट्रॅक्टच्या L2 वर स्थानांतरित करू नये. परंतु, तुम्ही त्यापूर्वी L2 वरील एक साधारण वॉलेट पत्ता सेट करण्याच्या ट्रॅन्सफर टूल्स वापरून स्थानांतरण करू शकता, आणि या साधारण वॉलेटवर तुमची स्थानांतरण किंवा प्रतिनियुक्ती सीधे L2 वर स्थानांतरित करू शकता.
+
+हे आपल्याला आपल्या स्टेक किंवा डिलिगेशनला कोणत्याही L2 पत्त्यावर हस्तांतरित करण्याची परवानगी देते.
+
+### माझ्या वेस्टिंग करारपत्राची किंमत अद्याप वेस्टिंग होत आहे. माझ्या वेस्टिंग करारपत्राची शिल्लक शिल्लक कसे L2 वर हस्तांतरित करू शकतो?
+
+या क्रियांचे अर्ज केवळ तेव्हा लागू होतात जेव्हा आपला करार अजिबात दिलेला आहे, किंवा जेव्हा आपल्याला आपल्या कराराची वेस्टिंग सुरू आहे तेव्हा पुन्हा या प्रक्रियेचा वापर केला आहे.
+
+तुमच्या वेस्टिंग करारपत्राचा L2 वर हस्तांतर करण्यासाठी, तुम्ही हस्तांतरण साधने वापरून लोटसपूर्ण L2 वर GRT शिल्लक हस्तांतरित करणार, ज्यामुळे तुमचा L2 वेस्टिंग करारपत्र प्रारंभ होईल:
+
+1. हस्तांतरण साधनात ETH किंमती जमा करा (ह्यामुळे L2 गॅससाठी पैसे देण्यात येईल)
+
+2. प्रोटोकॉलला वेस्टिंग करारक्षमतेसाठी प्रवेश सुरक्षित करा (पुढील पायर्या साठी आवश्यक)
+
+3. करारपत्राच्या प्रोटोकॉलला प्रवेश परवानगी द्या (ह्यामुळे आपल्या करारपत्राने हस्तांतरण साधने संवाद साधू शकतील)
+
+4. L2 लाभार्थ्याचा पत्ता सूचीत करा\* आणि इथे Ethereum मुख्यनेटवर शिल्लक हस्तांतरण प्रारंभ करा
+
+5. पुष्टीकरणासाठी 20 मिनिटे प्रतीक्षा करा
+
+6. L2 वर शिल्लक हस्तांतरणाची पुष्टी करा
+
+\*आवश्यक असल्यास - उदा. तुम्ही एक कॉन्ट्रॅक्ट पत्ता वापरत आहात.
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### मी माझा वेस्टिंग कॉन्ट्रॅक्ट परत L1 वर हलवू शकतो का?
+
+तुम्हाला तो करावयाचं आवश्यक नाही कारण आपला वेस्टिंग कॉन्ट्रॅक्ट अद्याप L1 वर आहे. जेव्हा आपण ट्रॅन्सफर टूल्स वापरता, तेव्हा आपल्याला फक्त आपल्या L1 वेस्टिंग कॉन्ट्रॅक्टसह संबंधित असलेल्या L2 ला एक नवीन कॉन्ट्रॅक्ट तयार करावा लागतो, आणि तुम्ही त्याच्याकडून GRT दोन्हेकऱ्यांच्या वर्गाच्या किंवा लक्षात घेण्याच्या किंवा त्याच्यामध्ये पाठवू शकता.
+
+### प्रारंभ करण्याच्या संदर्भात माझ्या वेस्टिंग करारक्षमतेची हातभार का आवश्यक आहे?
+
+तुम्हाला त्याच्याकडून स्थानांतरित करायला, आपल्याला तुमचा L2 वेस्टिंग कॉन्ट्रॅक्ट स्थापित करायला हवं आणि या खात्याच्या माध्यमाने आपल्याला L2 वर आपली स्थानांतरण किंवा प्रतिनियुक्ती असण्याची किंमत वाढवू लागेल. अन्यथा, तुमच्या वेस्टिंग कॉन्ट्रॅक्टला "अच्छादित" करण्याचा कोणताही मार्ग नसेल.
+
+### पूर्णपणे वेस्टेड नसलेल्या काराराची आपल्याला पुरस्कृत केल्यास ती काय होईल? कोणत्या प्रकारे काढू शकता?
+
+हे संभाव्य नाही. तुम्ही धन वापस L1वर पाठवू शकता आणि त्यावर ते काढू शकता.
+
+### मला माझा वेस्टिंग कॉन्ट्रॅक्ट L2 वर हलवायचा नसेल तर?
+
+तुम्ही L1 वर स्टेकिंग/डेलीगेटिंग केल्यामुळे ठेवू शकता. वेळेच्या वेळी, तुम्ही अर्बिट्रमवर प्रोटोकॉलला मोजण्यासाठी L2 ला स्थानांतरित करण्याची लक्षात घेऊ शकता, कारण प्रोटोकॉल अर्बिट्रमवर स्थानिक आसापास वाढत आहे. नक्की करा की या स्थानांतरण टूल्स वेस्टिंग कॉन्ट्रॅक्टसाठी आहेत ज्यामध्ये प्रोटोकॉलमध्ये स्टेकिंग किंवा डेलीगेटिंग करण्याची परवानगी आहे. जर आपल्या कॉन्ट्रॅक्टला स्टेकिंग किंवा डेलीगेटिंग करण्याची किंमत नसली तर न येथे नक्की ट्रांसफर टूल उपलब्ध आहे. तुम्हाला आपल्या लाभल्यास तुम्ही L1 वरून तुमच्या GRT अचलीस करू शकता.

From 91759397053c521a60e1651b93a2f5c8844e8da0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:03 -0500
Subject: [PATCH 1042/3820] New translations l2-transfer-tools-faq.mdx (Hindi)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/hi/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/hi/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/hi/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..8a09613e27f6
--- /dev/null
+++ b/website/pages/hi/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2 Transfer Tools FAQ
+---
+
+## आम
+
+### What are L2 Transfer Tools?
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### Can I use the same wallet I use on Ethereum mainnet?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### यदि मैं अपना स्थानांतरण 7 दिनों में पूरा नहीं कर पाता तो क्या होगा?
+
+L2 ट्रांसफर टूल L1 से L2 तक संदेश भेजने के लिए आर्बिट्रम के मूल तंत्र का उपयोग करते हैं। इस तंत्र को "पुनर्प्रयास योग्य टिकट" कहा जाता है और इसका उपयोग आर्बिट्रम जीआरटी ब्रिज सहित सभी देशी टोकन ब्रिजों द्वारा किया जाता है। आप पुनः प्रयास योग्य टिकटों के बारे में अधिक जानकारी [आर्बिट्रम डॉक्स](https://docs.arbitrum.io/arbos/l1-to-l2-messageing) में पढ़ सकते हैं।
+
+जब आप अपनी संपत्ति (सबग्राफ, हिस्सेदारी, प्रतिनिधिमंडल या क्यूरेशन) को एल2 में स्थानांतरित करते हैं, तो आर्बिट्रम जीआरटी ब्रिज के माध्यम से एक संदेश भेजा जाता है जो एल2 में एक पुनः प्रयास योग्य टिकट बनाता है। ट्रांसफ़र टूल में लेन-देन में कुछ ETH मान शामिल होते हैं, जिनका उपयोग 1) टिकट बनाने के लिए भुगतान करने और 2) L2 में टिकट निष्पादित करने के लिए गैस का भुगतान करने के लिए किया जाता है। हालाँकि, क्योंकि गैस की कीमतें L2 में निष्पादित होने के लिए टिकट तैयार होने तक के समय में भिन्न हो सकती हैं, यह संभव है कि यह ऑटो-निष्पादन प्रयास विफल हो जाए। जब ऐसा होता है, तो आर्बिट्रम ब्रिज पुनः प्रयास योग्य टिकट को 7 दिनों तक जीवित रखेगा, और कोई भी टिकट को "रिडीम" करने का पुनः प्रयास कर सकता है (जिसके लिए आर्बिट्रम में ब्रिज किए गए कुछ ईटीएच के साथ वॉलेट की आवश्यकता होती है)।
+
+इसे हम सभी स्थानांतरण टूल में "पुष्टि करें" चरण कहते हैं - यह ज्यादातर मामलों में स्वचालित रूप से चलेगा, क्योंकि ऑटो-निष्पादन अक्सर सफल होता है, लेकिन यह महत्वपूर्ण है कि आप यह सुनिश्चित करने के लिए वापस जांचें कि यह पूरा हो गया है। यदि यह सफल नहीं होता है और 7 दिनों में कोई सफल पुनर्प्रयास नहीं होता है, तो आर्बिट्रम ब्रिज टिकट को खारिज कर देगा, और आपकी संपत्ति (सबग्राफ, हिस्सेदारी, प्रतिनिधिमंडल या क्यूरेशन) खो जाएगी और पुनर्प्राप्त नहीं की जा सकेगी। ग्राफ़ कोर डेवलपर्स के पास इन स्थितियों का पता लगाने और बहुत देर होने से पहले टिकटों को भुनाने की कोशिश करने के लिए एक निगरानी प्रणाली है, लेकिन यह सुनिश्चित करना अंततः आपकी ज़िम्मेदारी है कि आपका स्थानांतरण समय पर पूरा हो जाए। यदि आपको अपने लेनदेन की पुष्टि करने में परेशानी हो रही है, तो कृपया [इस फॉर्म](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) और कोर डेव का उपयोग करके संपर्क करें आपकी मदद के लिए वहाँ मौजूद रहूँगा.
+
+### मैंने अपना डेलिगेशन/स्टेक/क्यूरेशन ट्रांसफर शुरू कर दिया है और मुझे यकीन नहीं है कि यह एल2 तक पहुंच गया है या नहीं, मैं कैसे पुष्टि कर सकता हूं कि इसे सही तरीके से ट्रांसफर किया गया था?
+
+यदि आपको अपनी प्रोफ़ाइल पर स्थानांतरण पूरा करने के लिए कहने वाला कोई बैनर नहीं दिखता है, तो संभव है कि लेन-देन सुरक्षित रूप से L2 पर पहुंच गया है और किसी और कार्रवाई की आवश्यकता नहीं है। यदि संदेह है, तो आप जांच सकते हैं कि एक्सप्लोरर आर्बिट्रम वन पर आपका प्रतिनिधिमंडल, हिस्सेदारी या क्यूरेशन दिखाता है या नहीं।
+
+If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire.
+
+## सबग्राफ स्थानांतरण
+
+### मैं अपना सबग्राफ कैसे स्थानांतरित करूं?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+अपने सबग्राफ को स्थानांतरित करने के लिए, आपको निम्नलिखित चरणों को पूरा करने होंगे:
+
+1. Ethereum mainnet वर हस्तांतरण सुरू करा
+
+2. पुष्टि के लिए 20 मिनट का इंतजार करें:
+
+3. आर्बिट्रमवर सबग्राफ हस्तांतरणाची पुष्टी करा\*
+
+4. आर्बिट्रम पर सबग्राफ का प्रकाशन समाप्त करें
+
+5. क्वेरी यूआरएल अपडेट करें (अनुशंसित)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### मुझे अपना स्थानांतरण कहाँ से आरंभ करना चाहिए?
+
+आप[Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) या किसी भी Subgraph विवरण पृष्ठ से अपने transfer को प्रारंभ कर सकते हैं। Subgraph विवरण पृष्ठ में "Transfer " button पर click करके transfer आरंभ करें।
+
+### मेरा सबग्राफ़ स्थानांतरित होने तक मुझे कितने समय तक प्रतीक्षा करनी होगी?
+
+अंतरण करने में लगभग 20 मिनट का समय लगता है। Arbitrum bridge स्वचालित रूप से bridge अंतरण पूरा करने के लिए पृष्ठभूमि में काम कर रहा है। कुछ मामलों में, गैस लागत में spike हो सकती है और आपको transaction की पुष्टि फिर से करनी होगी।
+
+### क्या मेरा सबग्राफ L2 में स्थानांतरित करने के बाद भी खोजा जा सकेगा?
+
+आपका सबग्राफ केवल उस नेटवर्क पर खोजने योग्य होगा जिस पर यह प्रकाशित किया गया है। उदाहरण स्वरूप, यदि आपका सबग्राफ आर्बिट्रम वन पर है, तो आपकेंद्रीय तंत्र पर केवल आर्बिट्रम वन के खोजक में ही ढूंढा जा सकता है और आप इथेरियम पर इसे नहीं खोज पाएंगे। कृपया सुनिश्चित करें कि आपने पृष्ठ के शीर्ष में नेटवर्क स्विचर में आर्बिट्रम वन को चुना है ताकि आप सही नेटवर्क पर हों। अंतरण के बाद, L1 सबग्राफ को पुराना किया गया माना जाएगा।
+
+### क्या मेरे सबग्राफ को स्थानांतरित करने के लिए इसे प्रकाशित किया जाना आवश्यक है?
+
+सबग्राफ अंतरण उपकरण का लाभ उठाने के लिए, आपके सबग्राफ को पहले ही ईथेरियम मेननेट पर प्रकाशित किया जाना चाहिए और सबग्राफ के मालिक wallet द्वारा स्वामित्व signal subgraph का कुछ होना चाहिए। यदि आपका subgraph प्रकाशित नहीं है, तो सिफ़ारिश की जाती है कि आप सीधे Arbitrum One पर प्रकाशित करें - जुड़े गए gas fees काफी कम होंगे। यदि आप किसी प्रकाशित subgraph को अंतरण करना चाहते हैं लेकिन owner account ने उस पर कोई signal curate नहीं किया है, तो आप उस account से थोड़ी सी राशि (जैसे 1 GRT) के signal कर सकते हैं; सुनिश्चित करें कि आपने "auto-migrating" signal को चुना है।
+
+### मी आर्बिट्रममध्ये हस्तांतरित केल्यानंतर माझ्या सबग्राफच्या इथरियम मेननेट आवृत्तीचे काय होते?
+
+अपने सबग्राफ को आर्बिट्रम पर अंतरण करने के बाद, ईथेरियम मेननेट संस्करण को पुराना किया जाएगा। हम आपको 48 घंटों के भीतर अपनी क्वेरी URL को अद्यतन करने की सिफारिश करते हैं। हालांकि, एक ग्रेस पीरियड लागू होता है जिसके तहत आपकी मुख्यनेट URL को कार्यरत रखा जाता है ताकि किसी तिसरी पक्ष डैप समर्थन को अपडेट किया जा सके।
+
+### स्थानांतरण करने के बाद, क्या मुझे आर्बिट्रम पर पुनः प्रकाशन की आवश्यकता होती है?
+
+20 मिनट के अंतराल के बाद, आपको अंतरण को पूरा करने के लिए UI में एक लेन-देन की पुष्टि करनी होगी, लेकिन अंतरण उपकरण आपको इसके माध्यम से मार्गदर्शन करेगा। आपकी L1 इंड पॉइंट ट्रांसफर विंडो के दौरान और एक ग्रेस पीरियड के बाद भी समर्थित रहेगा। आपको यह सुझाव दिया जाता है कि आप अपनी इंड पॉइंट को अपनी सुविधा के अनुसार अपडेट करें।
+
+### Will my endpoint experience downtime while re-publishing?
+
+It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the subgraph on L1 and whether they keep indexing it until the subgraph is fully supported on L2.
+
+### क्या L2 पर प्रकाशन और संस्करणीकरण Ethereum मेननेट के समान होते हैं?
+
+Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the subgraph.
+
+### क्या मेरे subgraph की curation उसके साथ चलेगी जब मैंsubgraph को स्थानांतरित करूँगा?
+
+यदि आपने " auto-migrating" signal का चयन किया है, तो आपके खुद के curation का 100% आपकेsubgraph के साथ Arbitrum One पर जाएगा। subgraph के सभी curation signalको अंतरण के समय GRT में परिवर्तित किया जाएगा, और आपके curation signal के समर्थन में उत्पन्न होने वाले GRT का उपयोग L2 subgraph पर signal mint करने के लिए किया जाएगा।
+
+अन्य क्यूरेटर यह चुन सकते हैं कि जीआरटी का अपना अंश वापस लेना है या नहीं, या इसे उसी सबग्राफ पर मिंट सिग्नल के लिए एल2 में स्थानांतरित करना है या नहीं।
+
+### क्या मैं स्थानांतरण के बाद अपने सबग्राफ को एथेरियम मेननेट पर वापस ले जा सकता हूं?
+
+एक बार अंतरित होने के बाद, आपके ईथेरियम मेननेट संस्करण को पुराना मान दिया जाएगा। अगर आप मुख्यनेट पर वापस जाना चाहते हैं, तो आपको पुनः डिप्लॉय और प्रकाशित करने की आवश्यकता होगी। हालांकि, वापस ईथेरियम मेननेट पर लौटने को मजबूरी से अनुशंसित किया जाता है क्योंकि सूचीकरण रिवॉर्ड आखिरकार पूरी तरह से आर्बिट्रम वन पर ही वितरित किए जाएंगे।
+
+### मेरे स्थानांतरण को पूरा करने के लिए मुझे ब्रिज़्ड ईथ की आवश्यकता क्यों है?
+
+आर्बिट्रम वन पर गैस शुल्क ब्रिज्ड ईथरियम (यानी ईथरियम जो आर्बिट्रम वन के लिए ब्रिज किया गया है) का उपयोग करके दिए जाते हैं। हालांकि, ईथेरियम मेननेट की तुलना में गैस शुल्क बहुत कम होते हैं।
+
+## प्रतिनिधि
+
+### मैं अपना प्रतिनिधिमंडल कैसे स्थानांतरित करूं?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+अपनी समर्पण को स्थानांतरित करने के लिए, आपको निम्नलिखित चरणों को पूरा करने की आवश्यकता होगी:
+
+1. ईथेरियम मेननेट पर समर्पण स्थानांतरण प्रारंभ करें:
+2. पुष्टि के लिए 20 मिनट का इंतजार करें:
+3. आर्बिट्रम पर समर्पण स्थानांतरण की पुष्टि करें:
+
+\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### अगर मैं ईथेरियम मेननेट पर खुली आवंटन के साथ स्थानांतरण प्रारंभ करता हूँ, तो मेरे पुरस्कारों के साथ क्या होता है?
+
+If the Indexer to whom you're delegating is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer.
+
+### यदि मैं जिस इंडेक्सर को वर्तमान में सौंप रहा हूं वह आर्बिट्रम वन पर नहीं है तो क्या होगा?
+
+L2 हस्तांतरण उपकरण को केवल तब सक्षम किया जाएगा अगर वह इंडेक्सर जिसे आपने डेलीगेट किया है, अपना स्टेक Arbitrum पर हस्तांतरित कर चुका है।
+
+### क्या सहायक व्यक्तियों को किसी अन्य इंडेक्सर को सहायकता देने का विकल्प होता है?
+
+If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to.
+
+### यदि मुझे L2 पर वह इंडेक्सर नहीं मिल रहा है जिसे मैं सौंप रहा हूँ तो क्या होगा?
+
+L2 हस्तांतरण उपकरण स्वचालित रूप से डिटेक्ट करेगा कि आप पहले किस इंडेक्सर को डेलीगेट कर चुके हैं।
+
+### क्या मैं नए या कई इंडेक्सरों के बीच अपनी सौंपन को मिला कर देने की क्षमता रखूंगा, या पहले इंडेक्सर के बजाय।
+
+L2 हस्तांतरण उपकरण हमेशा आपकी डेलीगेशन को उसी इंडेक्सर के पास हस्तांतरित करेगा, जिसे आपने पहले से डेलीगेट किया था। जब आप L2 पर हस्तांतरित हो जाते हैं, तो आप अनडेलीगेट कर सकते हैं, थॉविंग पीरियड का इंतजार कर सकते हैं, और फिर तय कर सकते हैं कि क्या आप अपनी डेलीगेशन को विभाजित करना चाहते हैं।
+
+### क्या मैं कूलडाउन अवधि के अधीन हूं या क्या मैं L2 डेलिगेशन ट्रांसफर टूल का उपयोग करने के तुरंत बाद वापस ले सकता हूं?
+
+ट्रांसफर टूल आपको तुरंत L2 पर हस्तांतरित होने की अनुमति देता है। यदि आप अनडेलीगेट करना चाहते हैं, तो आपको थॉविंग पीरियड का इंतजार करना होगा। हालांकि, अगर किसी इंडेक्सर ने अपने सभी स्टेक को L2 पर हस्तांतरित कर दिया है, तो आप इसे Ethereum मुख्यनेट पर तुरंत निकाल सकते हैं।
+
+### यदि मैं अपने प्रतिनिधित्व को ट्रांसफर नहीं करता हूँ, क्या मेरे प्रतिष्ठान पर नकारात्मक प्रभाव पड़ सकता है?
+
+आंतिकाल में यह आनुमानित है कि सभी नेटवर्क प्रतिभागन आर्बिट्रम वन पर स्थानांतरित होगा।
+
+### मेरे प्रतिनिधित्व को L2 में ट्रांसफर करने का पूरा काम कितने समय तक लगता है?
+
+A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### क्या मैं अपनी सौंपन को स्थानांतरित कर सकता हूँ अगर मैं एक जीआरटी वेस्टिंग अनुबंध/टोकन लॉक वॉलेट का उपयोग कर रहा हूँ?
+
+हाँ! प्रक्रिया थोड़ी अलग है क्योंकि वेस्टिंग कॉन्ट्रैक्ट्स आवश्यक L2 गैस के लिए आवश्यक ETH को फॉरवर्ड नहीं कर सकते, इसलिए आपको पहले ही इसे जमा करना होगा। यदि आपका वेस्टिंग कॉन्ट्रैक्ट पूरी तरह से वेस्ट नहीं होता है, तो आपको पहले L2 पर एक समकक्ष वेस्टिंग कॉन्ट्रैक्ट को प्रारंभ करना होगा और आप केवल इस L2 वेस्टिंग कॉन्ट्रैक्ट पर डेलीगेशन को हस्तांतरित कर सकेंगे। जब आप वेस्टिंग लॉक वॉलेट का उपयोग करके एक्सप्लोरर से जुड़ते हैं, तो यह प्रक्रिया आपको एक्सप्लोरर पर कनेक्ट करने के लिए गाइड कर सकती है।
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### क्या कोई प्रतिनिधिमंडल कर है?
+
+नहीं, L2 पर प्राप्त टोकनों को निर्दिष्ट इंडेक्सर की ओर से निर्दिष्ट डेलीगेटर के प्रतिनिधि रूप में डेलीगेट किया जाता है और डेलीगेशन टैक्स का कोई भुगतान नहीं होता है।
+
+### Will my unrealized rewards be transferred when I transfer my delegation?
+
+​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards.
+
+At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​
+
+### Is moving delegations to L2 mandatory? Is there a deadline?
+
+​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1?
+
+​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## क्यूरेशन सिग्नल
+
+### मैं अपना क्यूरेशन कैसे स्थानांतरित करूं?
+
+तुमचे क्युरेशन हस्तांतरित करण्यासाठी, तुम्हाला खालील चरण पूर्ण करावे लागतील:
+
+1. एथेरियम मेननेट पर सिग्नल ट्रांसफर शुरू करें
+
+2. L2 क्यूरेटर पता निर्दिष्ट करें\*
+
+3. पुष्टि के लिए 20 मिनट का इंतजार करें:
+
+\*यदि आवश्यक हो - अर्थात्, आप एक कॉन्ट्रैक्ट पते का उपयोग कर रहे हैं |
+
+### मी क्युरेट केलेला सबग्राफ L2 वर गेला असल्यास मला कसे कळेल?
+
+सबग्राफ विवरण पृष्ठ को देखते समय, एक बैनर आपको सूचित करेगा कि यह सबग्राफ अंतरण किया गया है। आप प्रोंप्ट का पालन करके अपने क्यूरेशन को अंतरण कर सकते हैं। आप इस जानकारी को भी उन सभी सबग्राफों के विवरण पृष्ठ पर पा सकते हैं जिन्होंने अंतरण किया है।
+
+### अगर मैं अपनी संरचना को L2 में स्थानांतरित करना नहीं चाहता हूँ तो क्या होगा?
+
+जब एक सबग्राफ पुराना होता है, तो आपके पास सिग्नल वापस लेने का विकल्प होता है। उसी तरह, अगर कोई सबग्राफ L2 पर चल रहा है, तो आपको चुनने का विकल्प होता है कि क्या आप ईथेरियम मेननेट से सिग्नल वापस लेना चाहेंगे या सिग्नल को L2 पर भेजें।
+
+### माझे क्युरेशन यशस्वीरित्या हस्तांतरित झाले हे मला कसे कळेल?
+
+एल2 स्थानांतरण उपकरण को प्रारंभ करने के बाद, सिग्नल विवरण एक्सप्लोरर के माध्यम से लगभग 20 मिनट के बाद उपलब्ध होंगे।
+
+### क्या मैं एक समय पर एक से अधिक सबग्राफ पर अपनी संरचना को स्थानांतरित कर सकता हूँ?
+
+वर्तमान में कोई थोक स्थानांतरण विकल्प उपलब्ध नहीं है।
+
+## इंडेक्सर हिस्सेदारी
+
+### मैं अपनी स्थानांतरण को कैसे आर्बिट्रम में स्थानांतरित कर सकता हूँ?
+
+> अस्वीकरण: यदि आप अपने इंडेक्सर पर ग्राफ टोकन का कोई हिस्सा अनस्थित कर रहे हैं, तो आप L2 ट्रांसफर टूल का उपयोग नहीं कर सकेंगे।
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+अपने स्टेक को स्थानांतरित करने के लिए, आपको निम्नलिखित चरणों को पूरा करने होंगे:
+
+1. ईथेरियम मेननेट पर स्थानांतरण प्रारंभ करें:
+
+2. पुष्टि के लिए 20 मिनट का इंतजार करें:
+
+3. आर्बिट्रम पर स्थानांतरण की पुष्टि करें:
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### क्या मेरा सम्पूर्ण स्थानांतरण हो जाएगा?
+
+आप यह चुन सकते हैं कि आपके स्टेक का कितना हिस्सा हस्तांतरित करना चाहते हैं। अगर आप एक साथ अपने पूरे स्टेक को हस्तांतरित करने का चयन करते हैं, तो आपको पहले किसी भी खुली आवंटन को बंद करने की आवश्यकता होगी।
+
+अगर आप अपने स्टेक के भिन्न भिन्न हिस्सों को कई लेन-देनों के माध्यम से हस्तांतरित करने की योजना बना रहे हैं, तो आपको हमेशा एक ही प्राप्ति कर्ता पता निर्दिष्ट करना आवश्यक होगा।
+
+\*ध्यान दें: आपको पहली बार ट्रांसफर टूल का उपयोग करते समय L2 पर न्यूनतम स्टेक आवश्यकताओं को पूरा करना होगा। इंडेक्सर्स को न्यूनतम 100k GRT भेजना होगा (जब वे पहली बार इस संचालन को बुलाते हैं)। यदि L1 पर स्टेक का कुछ हिस्सा छोड़ रहे हैं, तो यह भी 100k GRT की न्यूनतम आवश्यकता को पूरा करना चाहिए और आपके खुले आवंटनों को कवर करने के लिए पर्याप्त होना चाहिए (आपके डेलीगेशन के साथ मिलकर)।
+
+### आर्बिट्रममध्ये माझे स्टेक हस्तांतरण निश्चित करण्यासाठी मला किती वेळ लागेल?
+
+\*\*\* आपको आर्बिट्रम पर स्थानांतरण पूरा करने के लिए अपने लेन-देन की पुष्टि करनी होगी। यह कदम 7 दिन के भीतर पूरा किया जाना चाहिए, अन्यथा स्थान खो सकता है।
+
+### अगर मेरे पास खुली आवंटनें हैं तो क्या होगा?
+
+अगर आप अपना पूरा स्टेक नहीं भेज रहे हैं, तो L2 ट्रांसफर टूल यह सत्यापित करेगा कि Ethereum मुख्यनेट में कम से कम 100k GRT बचे रहें और आपके बचे हुए स्टेक और डेलीगेशन खुले आवंटनों को कवर करने के लिए पर्याप्त हैं। अगर आपका GRT शेष राशि न्यूनतम + खुले आवंटनों को कवर नहीं करता है, तो आपको खुले आवंटनों को बंद करने की आवश्यकता हो सकती है।
+
+### हस्तांतरण साधने वापरून, हस्तांतरण करण्यापूर्वी Ethereum mainnet वर अनस्टेक करण्यासाठी 28 दिवस प्रतीक्षा करणे आवश्यक आहे का?
+
+नहीं, आप अपने स्टेक को तुरंत L2 पर हस्तांतरित कर सकते हैं, ट्रांसफर टूल का उपयोग करने से पहले अनस्थित करने और प्रतीक्षा करने की कोई आवश्यकता नहीं है। 28-दिन की प्रतीक्षा केवल तब लागू होती है अगर आप अपने स्टेक को वापस अपने वॉलेट पर, Ethereum मुख्यनेट या L2 पर वापस लेना चाहते हैं।
+
+### स्थान को स्थानांतरित करने में कितना समय लगेगा?
+
+L2 ट्रान्स्फर टूलला तुमचा स्टेक हस्तांतरित करणे पूर्ण होण्यासाठी अंदाजे 20 मिनिटे लागतील.
+
+### मी माझा हिस्सा हस्तांतरित करण्यापूर्वी मला आर्बिट्रमवर इंडेक्स करावे लागेल का?
+
+आप पहले ही अपने स्टेक को प्रभावी रूप से हस्तांतरित कर सकते हैं, लेकिन आप L2 पर किसी भी पुरस्कार का दावा नहीं कर पाएंगे जब तक आप L2 पर सबग्राफ्स को आवंटित नहीं करते हैं, उन्हें इंडेक्स करते हैं, और पॉइंट ऑफ इंटरेस्ट (POI) प्रस्तुत नहीं करते।
+
+### मी माझा इंडेक्सिंग स्टेक हलवण्यापूर्वी प्रतिनिधी त्यांचे प्रतिनिधी हलवू शकतात का?
+
+नहीं, डेलीगेटर्स को अपने डेलीगेटेड GRT को Arbitrum पर हस्तांतरित करने के लिए, उनके डेलीगेट कर रहे इंडेक्सर को L2 पर सक्रिय होना चाहिए।
+
+### मी GRT वेस्टिंग कॉन्ट्रॅक्ट/टोकन लॉक वॉलेट वापरत असल्यास मी माझा स्टेक ट्रान्सफर करू शकतो का?
+
+हाँ! प्रक्रिया कुछ अलग है, क्योंकि वेस्टिंग कॉन्ट्रैक्ट्स L2 गैस के लिए आवश्यक ETH को फॉरवर्ड नहीं कर सकते, इसलिए आपको पहले ही इसे जमा करना होगा। यदि आपका वेस्टिंग कॉन्ट्रैक्ट पूरी तरह से वेस्ट नहीं होता है, तो आपको पहले L2 पर एक समकक्ष वेस्टिंग कॉन्ट्रैक्ट को प्रारंभ करना होगा और आपको केवल इस L2 वेस्टिंग कॉन्ट्रैक्ट पर स्टेक को हस्तांतरित करने की अनुमति होगी। जब आप वेस्टिंग लॉक वॉलेट का उपयोग करके एक्सप्लोरर से जुड़ते हैं, तो यह प्रक्रिया आपको एक्सप्लोरर पर कनेक्ट करने के लिए गाइड कर सकती है।
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## निहित अनुबंध स्थानांतरण
+
+### मैं अपना वेस्टिंग अनुबंध कैसे ट्रांसफर करूं?
+
+अपने वेस्टिंग को ट्रांसफर करने के लिए, आपको निम्नलिखित चरणों को पूरा करने की आवश्यकता होगी:
+
+1. ईथिरियम मेननेट पर वेस्टिंग ट्रांसफर प्रारंभ करें।
+
+2. पुष्टि के लिए 20 मिनट का इंतजार करें:
+
+3. आर्बिट्रम पर वेस्टिंग ट्रांसफर की पुष्टि करें।
+
+### यदि मैं केवल आंशिक रूप से निहित हूं तो मैं अपना निहित अनुबंध कैसे स्थानांतरित करूं?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. स्थानांतरण उपकरण अनुबंध में कुछ ईटीएच जमा करें (यूआई उचित राशि का अनुमान लगाने में मदद कर सकता है)
+
+2. L2 वेस्टिंग लॉक को आरंभ करने के लिए ट्रांसफर टूल अनुबंध के माध्यम से कुछ लॉक किए गए GRT को L2 पर भेजें। इससे उनका L2 लाभार्थी पता भी सेट हो जाएगा।
+
+3. "लॉक्ड" स्थानांतरण उपकरण कार्यों के माध्यम से उनका स्टेक/सहायकता एल2 में "L1Staking" अनुबंध के माध्यम से भेजें।
+
+4. ट्रांसफर उपकरण अनुबंध से शेषित ETH को निकालें।
+
+### यदि मैं पूरी तरह से निहित हूं तो मैं अपने निहित अनुबंध को कैसे स्थानांतरित करूं?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+जो लोग पूरी तरह से निहित हैं, उनके लिए प्रक्रिया समान है:
+
+1. स्थानांतरण उपकरण अनुबंध में कुछ ईटीएच जमा करें (यूआई उचित राशि का अनुमान लगाने में मदद कर सकता है)
+
+2. ट्रांसफर उपकरण अनुबंध को कॉल करके अपना L2 पता सेट करें।
+
+3. आपके स्टेक/डिलीगेशन को "लॉक्ड" ट्रांसफर टूल के फ़ंक्शन के माध्यम से एल1 स्टेकिंग अनुबंध में एल2 में भेज दें।
+
+4. ट्रांसफर उपकरण अनुबंध से शेषित ETH को निकालें।
+
+### क्या मैं अपने निहित अनुबंध को आर्बिट्रम में स्थानांतरित कर सकता हूँ?
+
+आप अपने वेस्टिंग कॉन्ट्रैक्ट के GRT शेष राशि को L2 में एक वेस्टिंग कॉन्ट्रैक्ट में हस्तांतरित कर सकते हैं। यह आपके वेस्टिंग कॉन्ट्रैक्ट से L2 पर स्टेक या डेलीगेशन को हस्तांतरित करने के लिए एक पूर्विशेष आवश्यकता है। वेस्टिंग कॉन्ट्रैक्ट को एक गैरशून्य राशि GRT को धारण करना चाहिए (यदि आवश्यक हो तो आप उसमें 1 GRT जैसी छोटी राशि को हस्तांतरित कर सकते हैं)।
+
+जब आप अपने L1 वेस्टिंग कॉन्ट्रैक्ट से GRT को L2 में हस्तांतरित करते हैं, तो आप भेजने के लिए राशि का चयन कर सकते हैं और आप इसे जितनी बार चाहें कर सकते हैं। L2 वेस्टिंग कॉन्ट्रैक्ट को पहली बार जब आप GRT को हस्तांतरित करते हैं, तो इसे आरंभ किया जाएगा |
+
+स्थानांतरण एक ट्रांसफर टूल का उपयोग करके किया जाता है जो आपके एक्सप्लोरर प्रोफ़ाइल पर तब दिखाई देगा जब आप वेस्टिंग अनुबंध खाते से जुड़ेंगे।
+
+कृपया ध्यान दें कि आप अपने L2 वेस्टिंग कॉन्ट्रैक्ट से GRT को जब तक आपका कॉन्ट्रैक्ट पूरी तरह से वेस्ट नहीं होता है, तब तक रिलीज/विद्रोहित करने/निकालने के लिए नहीं कर सकेंगे। यदि आपको इससे पहले GRT को रिलीज करने की आवश्यकता है, तो आप उसके लिए उपलब्ध एक अन्य ट्रांसफर टूल का उपयोग करके GRT को L1 वेस्टिंग कॉन्ट्रैक्ट में वापस हस्तांतरित कर सकते हैं।
+
+अगर आपने किसी भी वेस्टिंग कॉन्ट्रैक्ट शेष राशि को L2 में हस्तांतरित नहीं किया है, और आपका वेस्टिंग कॉन्ट्रैक्ट पूरी तरह से वेस्ट हो गया है, तो आपको अपने वेस्टिंग कॉन्ट्रैक्ट को L2 में हस्तांतरित नहीं करना चाहिए। इसके बजाय, आप ट्रांसफर टूल का उपयोग करके एक L2 वॉलेट पता सेट करने और इस सामान्य वॉलेट पर L2 पर स्टेक या डेलीगेशन को सीधे हस्तांतरित कर सकते हैं।
+
+### मैं मेननेट पर हिस्सेदारी के लिए अपने निहित अनुबंध का उपयोग कर रहा हूं। क्या मैं अपनी हिस्सेदारी आर्बिट्रम में स्थानांतरित कर सकता हूँ |
+
+हां, लेकिन यदि आपका कॉन्ट्रैक्ट अब भी वेस्टिंग कर रहा है, तो आप केवल उस स्टेक को हस्तांतरित कर सकते हैं ताकि यह आपके L2 वेस्टिंग कॉन्ट्रैक्ट के स्वामित्व में हो। आपको सबसे पहले इस L2 कॉन्ट्रैक्ट को इनिशियलाइज़ करना होगा, एक्सप्लोरर पर वेस्टिंग कॉन्ट्रैक्ट ट्रांसफर टूल का उपयोग करके कुछ GRT बैलेंस को हस्तांतरित करके। यदि आपका कॉन्ट्रैक्ट पूरी तरह से वेस्टेड है, तो आप अपने स्टेक को L2 में किसी भी पते पर हस्तांतरित कर सकते हैं, लेकिन आपको पहले से सेट करना होगा और L2 गैस के लिए कुछ ETH जमा करना होगा ताकि L2 ट्रांसफर टूल इसे भुगतान कर सके।
+
+### मैं अपने वेस्टिंग अनुबंध का उपयोग मुख्य नेट पर प्रतिनियुक्ति के लिए कर रहा हूँ। क्या मैं अपनी प्रतिनियुक्तियों को आर्बिट्रम पर स्थानांतरित कर सकता हूँ?
+
+हाँ, लेकिन यदि आपका कॉन्ट्रैक्ट अब भी वेस्टिंग कर रहा है, तो आप केवल डेलीगेशन को हस्तांतरित कर सकते हैं ताकि यह आपके L2 वेस्टिंग कॉन्ट्रैक्ट के स्वामित्व में हो। आपको सबसे पहले इस L2 कॉन्ट्रैक्ट को इनिशियलाइज़ करना होगा, एक्सप्लोरर पर वेस्टिंग कॉन्ट्रैक्ट ट्रांसफर टूल का उपयोग करके कुछ GRT बैलेंस को हस्तांतरित करके। अगर आपका कॉन्ट्रैक्ट पूरी तरह से वेस्ट हो गया है, तो आप अपनी डेलीगेशन को L2 में किसी भी पते पर हस्तांतरित कर सकते हैं, लेकिन आपको पहले से सेट करना होगा और L2 गैस के लिए कुछ ETH जमा करना होगा ताकि L2 ट्रांसफर टूल इसे भुगतान कर सके।
+
+### क्या मैं L2 पर अपने निहित अनुबंध के लिए एक अलग लाभार्थी निर्दिष्ट कर सकता हूँ?
+
+हाँ, पहली बार जब आप बैलेंस को हस्तांतरित करते हैं और अपना L2 वेस्टिंग कॉन्ट्रैक्ट सेट करते हैं, तो आप एक L2 लाभार्थी को निर्दिष्ट कर सकते हैं। सुनिश्चित करें कि इस लाभार्थी का एक वॉलेट है जो Arbitrum One पर लेनदेन कर सकता है, अर्थात् यह EOA या Arbitrum One पर डिप्लॉय किया गया मल्टिसिग होना चाहिए।
+
+अगर आपका कॉन्ट्रैक्ट पूरी तरह से वेस्ट हो गया है, तो आप L2 पर वेस्टिंग कॉन्ट्रैक्ट सेट नहीं करेंगे; इसके बजाय, आप एक L2 वॉलेट पता सेट करेंगे और यह आपके स्टेक या डेलीगेशन के लिए Arbitrum पर विद्वेषण करने वाले वॉलेट का भुगतान करने वाला होगा।
+
+### मेरा अनुबंध पूरी तरह से निहित है. क्या मैं अपनी हिस्सेदारी या प्रतिनिधिमंडल को किसी अन्य पते पर स्थानांतरित कर सकता हूं जो L2 निहित अनुबंध नहीं है?
+
+हाँ। अगर आपने L2 में कोई वेस्टिंग कॉन्ट्रैक्ट शेष राशि हस्तांतरित नहीं की है और आपका वेस्टिंग कॉन्ट्रैक्ट पूरी तरह से वेस्ट हो गया है, तो आपको अपने वेस्टिंग कॉन्ट्रैक्ट को L2 में हस्तांतरित नहीं करना चाहिए। इसके बजाय, आप ट्रांसफर टूल्स का उपयोग करके एक L2 वॉलेट पता सेट करने के लिए और स्टेक या डेलीगेशन को इस सामान्य वॉलेट पर सीधे L2 पर हस्तांतरित कर सकते हैं।
+
+यह आपको अपनी हिस्सेदारी या प्रतिनिधिमंडल को किसी भी L2 पते पर स्थानांतरित करने की अनुमति देता है।
+
+### मेरा वेस्टिंग कॉन्ट्रैक्ट अभी भी प्रतिनियुक्ति के अधीन है। मैं अपने वेस्टिंग कॉन्ट्रैक्ट शेष को L2 में कैसे स्थानांतरित करूँ?
+
+ये कदम केवल तब लागू होते हैं अगर आपका कॉन्ट्रैक्ट अब भी वेस्टिंग कर रहा है, या यदि आपने अपने कॉन्ट्रैक्ट का उपयोग किया है जब आपका कॉन्ट्रैक्ट अब भी वेस्टिंग कर रहा था।
+
+अपने वेस्टिंग कॉन्ट्रैक्ट को L2 में हस्तांतरित करने के लिए, आप ट्रांसफर टूल्स का उपयोग करके L2 में किसी भी GRT बैलेंस को हस्तांतरित करेंगे, जिससे आपका L2 वेस्टिंग कॉन्ट्रैक्ट आरंभ होगा:
+
+1. कृपया स्थानांतरण उपकरण अनुबंध में कुछ ईथर जमा करें (यह एल2 गैस के लिए भुगतान करने के लिए उपयोग किया जाएगा)।
+
+2. निहित अनुबंध तक प्रोटोकॉल पहुंच रद्द करें (अगले चरण के लिए आवश्यक)
+
+3. वेस्टिंग अनुबंध को प्रोटोकॉल एक्सेस दें (यह आपके अनुबंध को स्थानांतरण उपकरण के साथ इंटरैक्ट करने की अनुमति देगा)।
+
+4. एक एल2 लाभार्थी पता निर्दिष्ट करें\* और इथेरियम मेननेट पर शेष राशि का ट्रांसफर प्रारंभ करें।
+
+5. पुष्टि के लिए 20 मिनट का इंतजार करें:
+
+6. L2 पर बैलेंस ट्रांसफर की पुष्टि करें
+
+\*यदि आवश्यक हो - अर्थात्, आप एक कॉन्ट्रैक्ट पते का उपयोग कर रहे हैं |
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### क्या मैं अपने निहित अनुबंध को वापस L1 पर ले जा सकता हूँ?
+
+ऐसा करने की कोई आवश्यकता नहीं है क्योंकि आपका वेस्टिंग कॉन्ट्रैक्ट अब भी L1 में है। जब आप ट्रांसफर टूल्स का उपयोग करते हैं, तो आप सिर्फ एक नया कॉन्ट्रैक्ट L2 में बनाते हैं जो आपके L1 वेस्टिंग कॉन्ट्रैक्ट से जुड़ा होता है, और आप उन दोनों के बीच GRT को आगे-पीछे भेज सकते हैं।
+
+### पहले से मेरे वेस्टिंग कॉन्ट्रैक्ट को क्यों स्थानांतरित करने की आवश्यकता है?
+
+आपको एक L2 वेस्टिंग कॉन्ट्रैक्ट सेट करने की आवश्यकता है ताकि इस खाता को L2 पर आपके स्टेक या डेलीगेशन का स्वामित्व हो सके। अन्यथा, आपके पास वेस्टिंग कॉन्ट्रैक्ट को "बाहर निकलने" के बिना स्टेक/डेलीगेशन को L2 पर हस्तांतरित करने का कोई तरीका नहीं होगा।
+
+### अगर मैं कोशिश करता हूँ कि जब मेरा अनुबंध केवल आंशिक रूप से प्रतिनियुक्त है, तो क्या होता है? क्या यह संभव है?
+
+यह एक संभावना नहीं है। आप फंड्स को L1 में वापस स्थानांतरित कर सकते हैं और वहां से उन्हें निकाल सकते हैं।
+
+### अगर मुझे अपने वेस्टिंग कॉन्ट्रैक्ट को L2 में स्थानांतरित नहीं करना है तो क्या होगा?
+
+आप L1 पर स्टेकिंग/डिलीगेशन करते रह सकते हैं। समय के साथ, प्रोटोकॉल Arbitrum पर स्केल करने के साथ-साथ आपको L2 पर रिवॉर्ड्स सक्षम करने के लिए वहां माइग्रेट करने का विचार करना चाहिए। यह ध्यान दें कि ये हस्तांतरण उपकरण उन वेस्टिंग कॉन्ट्रैक्ट्स के लिए हैं जिन्हें प्रोटोकॉल में स्टेकिंग और डिलीगेशन की अनुमति है। यदि आपका कॉन्ट्रैक्ट स्टेकिंग या डिलीगेशन की अनुमति नहीं देता है, या वापस लिया जा सकता है, तो उपकरण उपलब्ध नहीं होगा। आपको फिर भी जब भी उपलब्ध हो, अपने GRT को L1 से निकाल सकेंगे।

From b9498d1e0a87fdd2f70d2af7858110dae355a9c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:04 -0500
Subject: [PATCH 1043/3820] New translations l2-transfer-tools-faq.mdx
 (Swahili)

---
 .../arbitrum/l2-transfer-tools-faq.mdx        | 411 ++++++++++++++++++
 1 file changed, 411 insertions(+)
 create mode 100644 website/pages/sw/archived/arbitrum/l2-transfer-tools-faq.mdx

diff --git a/website/pages/sw/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/sw/archived/arbitrum/l2-transfer-tools-faq.mdx
new file mode 100644
index 000000000000..8e6da852a01c
--- /dev/null
+++ b/website/pages/sw/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -0,0 +1,411 @@
+---
+title: L2 Transfer Tools FAQ
+---
+
+## General
+
+### What are L2 Transfer Tools?
+
+The Graph has made it 26x cheaper for contributors to participate in the network by deploying the protocol to Arbitrum One. The L2 Transfer Tools were created by core devs to make it easy to move to L2.
+
+For each network participant, a set of L2 Transfer Tools are available to make the experience seamless when moving to L2, avoiding thawing periods or having to manually withdraw and bridge GRT.
+
+These tools will require you to follow a specific set of steps depending on what your role is within The Graph and what you are transferring to L2.
+
+### Can I use the same wallet I use on Ethereum mainnet?
+
+If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+
+Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
+
+The exception is with smart contract wallets like multisigs: these are smart contracts that are deployed separately on each chain, and get their address when they are deployed. If a multisig was deployed to Ethereum, it won't exist with the same address on Arbitrum. A new multisig must be created first on Arbitrum, and may get a different address.
+
+### What happens if I don’t finish my transfer in 7 days?
+
+The L2 Transfer Tools use Arbitrum’s native mechanism to send messages from L1 to L2. This mechanism is called a “retryable ticket” and is used by all native token bridges, including the Arbitrum GRT bridge. You can read more about retryable tickets in the [Arbitrum docs](https://docs.arbitrum.io/arbos/l1-to-l2-messaging).
+
+When you transfer your assets (subgraph, stake, delegation or curation) to L2, a message is sent through the Arbitrum GRT bridge which creates a retryable ticket in L2. The transfer tool includes some ETH value in the transaction, that is used to 1) pay to create the ticket and 2) pay for the gas to execute the ticket in L2. However, because gas prices might vary in the time until the ticket is ready to execute in L2, it is possible that this auto-execution attempt fails. When that happens, the Arbitrum bridge will keep the retryable ticket alive for up to 7 days, and anyone can retry “redeeming” the ticket (which requires a wallet with some ETH bridged to Arbitrum).
+
+This is what we call the “Confirm” step in all the transfer tools - it will run automatically in most cases, as the auto-execution is most often successful, but it is important that you check back to make sure it went through. If it doesn’t succeed and there are no successful retries in 7 days, the Arbitrum bridge will discard the ticket, and your assets (subgraph, stake, delegation or curation) will be lost and can’t be recovered. The Graph core devs have a monitoring system in place to detect these situations and try to redeem the tickets before it’s too late, but it is ultimately your responsibility to ensure your transfer is completed in time. If you’re having trouble confirming your transaction, please reach out using [this form](https://noteforms.com/forms/notionform-l2-transfer-tooling-issues-0ogqfu?notionforms=1&utm_source=notionforms) and core devs will be there help you.
+
+### I started my delegation/stake/curation transfer and I'm not sure if it made it through to L2, how can I confirm that it was transferred correctly?
+
+If you don't see a banner on your profile asking you to finish the transfer, then it's likely the transaction made it safely to L2 and no more action is needed. If in doubt, you can check if Explorer shows your delegation, stake or curation on Arbitrum One.
+
+If you have the L1 transaction hash (which you can find by looking at the recent transactions in your wallet), you can also confirm if the "retryable ticket" that carried the message to L2 was redeemed here: https://retryable-dashboard.arbitrum.io/ - if the auto-redeem failed, you can also connect your wallet there and redeem it. Rest assured that core devs are also monitoring for messages that get stuck, and will attempt to redeem them before they expire.
+
+## Subgraph Transfer
+
+### How do I transfer my subgraph?
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+To transfer your subgraph, you will need to complete the following steps:
+
+1. Initiate the transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm subgraph transfer on Arbitrum\*
+
+4. Finish publishing subgraph on Arbitrum
+
+5. Update Query URL (recommended)
+
+\*Note that you must confirm the transfer within 7 days otherwise your subgraph may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Where should I initiate my transfer from?
+
+You can initiate your transfer from the [Subgraph Studio](https://thegraph.com/studio/), [Explorer,](https://thegraph.com/explorer) or any subgraph details page. Click the "Transfer Subgraph" button in the subgraph details page to start the transfer.
+
+### How long do I need to wait until my subgraph is transferred
+
+The transfer time takes approximately 20 minutes. The Arbitrum bridge is working in the background to complete the bridge transfer automatically. In some cases, gas costs may spike and you will need to confirm the transaction again.
+
+### Will my subgraph still be discoverable after I transfer it to L2?
+
+Your subgraph will only be discoverable on the network it is published to. For example, if your subgraph is on Arbitrum One, then you can only find it in Explorer on Arbitrum One and will not be able to find it on Ethereum. Please ensure that you have Arbitrum One selected in the network switcher at the top of the page to ensure you are on the correct network.  After the transfer, the L1 subgraph will appear as deprecated.
+
+### Does my subgraph need to be published to transfer it?
+
+To take advantage of the subgraph transfer tool, your subgraph must be already published to Ethereum mainnet and must have some curation signal owned by the wallet that owns the subgraph. If your subgraph is not published, it is recommended you simply publish directly on Arbitrum One - the associated gas fees will be considerably lower. If you want to transfer a published subgraph but the owner account hasn't curated any signal on it, you can signal a small amount (e.g. 1 GRT) from that account; make sure to choose "auto-migrating" signal.
+
+### What happens to the Ethereum mainnet version of my subgraph after I transfer to Arbitrum?
+
+After transferring your subgraph to Arbitrum, the Ethereum mainnet version will be deprecated. We recommend you update your query URL within 48 hours. However, there is a grace period in place that keeps your mainnet URL functioning so that any third-party dapp support can be updated.
+
+### After I transfer, do I also need to re-publish on Arbitrum?
+
+After the 20 minute transfer window, you will need to confirm the transfer with a transaction in the UI to finish the transfer, but the transfer tool will guide you through this. Your L1 endpoint will continue to be supported during the transfer window and a grace period after. It is encouraged that you update your endpoint when convenient for you.
+
+### Will my endpoint experience downtime while re-publishing?
+
+It is unlikely, but possible to experience a brief downtime depending on which Indexers are supporting the subgraph on L1 and whether they keep indexing it until the subgraph is fully supported on L2.
+
+### Is publishing and versioning the same on L2 as Ethereum Ethereum mainnet?
+
+Yes. Select Arbitrum One as your published network when publishing in Subgraph Studio. In the Studio, the latest endpoint will be available which points to the latest updated version of the subgraph.
+
+### Will my subgraph's curation move with my subgraph?
+
+If you've chosen auto-migrating signal, 100% of your own curation will move with your subgraph to Arbitrum One. All of the subgraph's curation signal will be converted to GRT at the time of the transfer, and the GRT corresponding to your curation signal will be used to mint signal on the L2 subgraph.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph.
+
+### Can I move my subgraph back to Ethereum mainnet after I transfer?
+
+Once transferred, your Ethereum mainnet version of this subgraph will be deprecated. If you would like to move back to mainnet, you will need to redeploy and publish back to mainnet. However, transferring back to Ethereum mainnet is strongly discouraged as indexing rewards will eventually be distributed entirely on Arbitrum One.
+
+### Why do I need bridged ETH to complete my transfer?
+
+Gas fees on Arbitrum One are paid using bridged ETH (i.e. ETH that has been bridged to Arbitrum One). However, the gas fees are significantly lower when compared to Ethereum mainnet.
+
+## Delegation
+
+### How do I transfer my delegation?
+
+<VideoEmbed youtube="CAAQCKw5eV4" />
+
+To transfer your delegation, you will need to complete the following steps:
+
+1. Initiate delegation transfer on Ethereum mainnet
+2. Wait 20 minutes for confirmation
+3. Confirm delegation transfer on Arbitrum
+
+\*\*\*\*You must confirm the transaction to complete the delegation transfer on Arbitrum. This step must be completed within 7 days or the delegation could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### What happens to my rewards if I initiate a transfer with an open allocation on Ethereum mainnet?
+
+If the Indexer to whom you're delegating is still operating on L1, when you transfer to Arbitrum you will forfeit any delegation rewards from open allocations on Ethereum mainnet. This means that you will lose the rewards from, at most, the last 28-day period. If you time the transfer right after the Indexer has closed allocations you can make sure this is the least amount possible. If you have a communication channel with your Indexer(s), consider discussing with them to find the best time to do your transfer.
+
+### What happens if the Indexer I currently delegate to isn't on Arbitrum One?
+
+The L2 transfer tool will only be enabled if the Indexer you have delegated to has transferred their own stake to Arbitrum.
+
+### Do Delegators have the option to delegate to another Indexer?
+
+If you wish to delegate to another Indexer, you can transfer to the same Indexer on Arbitrum, then undelegate and wait for the thawing period. After this, you can select another active Indexer to delegate to.
+
+### What if I can't find the Indexer I'm delegating to on L2?
+
+The L2 transfer tool will automatically detect the Indexer you previously delegated to.
+
+### Will I be able to mix and match or 'spread' my delegation across new or several Indexers instead of the prior Indexer?
+
+The L2 transfer tool will always move your delegation to the same Indexer you delegated to previously. Once you have moved to L2, you can undelegate, wait for the thawing period, and decide if you'd like to split up your delegation.
+
+### Am I subject to the cooldown period or can I withdraw immediately after using the L2 delegation transfer tool?
+
+The transfer tool allows you to immediately move to L2. If you would like to undelegate you will have to wait for the thawing period. However, if an Indexer has transferred all of their stake to L2, you can withdraw on Ethereum mainnet immediately.
+
+### Can my rewards be negatively impacted if I do not transfer my delegation?
+
+It is anticipated that all network participation will move to Arbitrum One in the future.
+
+### How long does it take to complete the transfer of my delegation to L2?
+
+A 20-minute confirmation is required for delegation transfer. Please note that after the 20-minute period, you must come back and complete step 3 of the transfer process within 7 days. If you fail to do this, then your delegation may be lost. Note that in most cases the transfer tool will complete this step for you automatically. In case of a failed auto-attempt, you will need to complete it manually. If any issues arise during this process, don't worry, we'll be here to help: contact us at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Can I transfer my delegation if I'm using a GRT vesting contract/token lock wallet?
+
+Yes! The process is a bit different because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the delegation to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### Does my Arbitrum vesting contract allow releasing GRT just like on mainnet?
+
+No, the vesting contract that is created on Arbitrum will not allow releasing any GRT until the end of the vesting timeline, i.e. until your contract is fully vested. This is to prevent double spending, as otherwise it would be possible to release the same amounts on both layers.
+
+If you'd like to release GRT from the vesting contract, you can transfer them back to the L1 vesting contract using Explorer: in your Arbitrum One profile, you will see a banner saying you can transfer GRT back to the mainnet vesting contract. This requires a transaction on Arbitrum One, waiting 7 days, and a final transaction on mainnet, as it uses the same native bridging mechanism from the GRT bridge.
+
+### Is there any delegation tax?
+
+No. Received tokens on L2 are delegated to the specified Indexer on behalf of the specified Delegator without charging a delegation tax.
+
+### Will my unrealized rewards be transferred when I transfer my delegation?
+
+​Yes! The only rewards that can't be transferred are the ones for open allocations, as those won't exist until the Indexer closes the allocations (usually every 28 days). If you've been delegating for a while, this is likely only a small fraction of rewards.
+
+At the smart contract level, unrealized rewards are already part of your delegation balance, so they will be transferred when you transfer your delegation to L2. ​
+
+### Is moving delegations to L2 mandatory? Is there a deadline?
+
+​Moving delegation to L2 is not mandatory, but indexing rewards are increasing on L2 following the timeline described in [GIP-0052](https://forum.thegraph.com/t/gip-0052-timeline-and-requirements-to-increase-rewards-in-l2/4193). Eventually, if the Council keeps approving the increases, all rewards will be distributed in L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### If I am delegating to an Indexer that has already transferred stake to L2, do I stop receiving rewards on L1?
+
+​Many Indexers are transferring stake gradually so Indexers on L1 will still be earning rewards and fees on L1, which are then shared with Delegators. Once an Indexer has transferred all of their stake, then they will stop operating on L1, so Delegators will not receive any more rewards unless they transfer to L2.
+
+Eventually, if the Council keeps approving the indexing rewards increases in L2, all rewards will be distributed on L2 and there will be no indexing rewards for Indexers and Delegators on L1. ​
+
+### I don't see a button to transfer my delegation. Why is that?
+
+​Your Indexer has probably not used the L2 transfer tools to transfer stake yet.
+
+If you can contact the Indexer, you can encourage them to use the L2 Transfer Tools so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### My Indexer is also on Arbitrum, but I don't see a button to transfer the delegation in my profile. Why is that?
+
+​It is possible that the Indexer has set up operations on L2, but hasn't used the L2 transfer tools to transfer stake. The L1 smart contracts will therefore not know about the Indexer's L2 address. If you can contact the Indexer, you can encourage them to use the transfer tool so that Delegators can transfer delegations to their L2 Indexer address. ​
+
+### Can I transfer my delegation to L2 if I have started the undelegating process and haven't withdrawn it yet?
+
+​No. If your delegation is thawing, you have to wait the 28 days and withdraw it.
+
+The tokens that are being undelegated are "locked" and therefore cannot be transferred to L2.
+
+## Curation Signal
+
+### How do I transfer my curation?
+
+To transfer your curation, you will need to complete the following steps:
+
+1. Initiate signal transfer on Ethereum mainnet
+
+2. Specify an L2 Curator address\*
+
+3. Wait 20 minutes for confirmation
+
+\*If necessary - i.e. you are using a contract address.
+
+### How will I know if the subgraph I curated has moved to L2?
+
+When viewing the subgraph details page, a banner will notify you that this subgraph has been transferred. You can follow the prompt to transfer your curation. You can also find this information on the subgraph details page of any subgraph that has moved.
+
+### What if I do not wish to move my curation to L2?
+
+When a subgraph is deprecated you have the option to withdraw your signal. Similarly, if a subgraph has moved to L2, you can choose to withdraw your signal in Ethereum mainnet or send the signal to L2.
+
+### How do I know my curation successfully transferred?
+
+Signal details will be accessible via Explorer approximately 20 minutes after the L2 transfer tool is initiated.
+
+### Can I transfer my curation on more than one subgraph at a time?
+
+There is no bulk transfer option at this time.
+
+## Indexer Stake
+
+### How do I transfer my stake to Arbitrum?
+
+> Disclaimer: If you are currently unstaking any portion of your GRT on your Indexer, you will not be able to use L2 Transfer Tools.
+
+<VideoEmbed youtube="5lTq_V4YbWc" />
+
+To transfer your stake, you will need to complete the following steps:
+
+1. Initiate stake transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm stake transfer on Arbitrum
+
+\*Note that you must confirm the transfer within 7 days otherwise your stake may be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### Will all of my stake transfer?
+
+You can choose how much of your stake to transfer. If you choose to transfer all of your stake at once, you will need to close any open allocations first.
+
+If you plan on transferring parts of your stake over multiple transactions, you must always specify the same beneficiary address.
+
+Note: You must meet the minimum stake requirements on L2 the first time you use the transfer tool. Indexers must send the minimum 100k GRT (when calling this function the first time). If leaving a portion of stake on L1, it must also be over the 100k GRT minimum and be sufficient (together with your delegations) to cover your open allocations.
+
+### How much time do I have to confirm my stake transfer to Arbitrum?
+
+\*\*\* You must confirm your transaction to complete the stake transfer on Arbitrum. This step must be completed within 7 days or stake could be lost.
+
+### What if I have open allocations?
+
+If you are not sending all of your stake, the L2 transfer tool will validate that at least the minimum 100k GRT remains in Ethereum mainnet and your remaining stake and delegation is enough to cover any open allocations. You may need to close open allocations if your GRT balance does not cover the minimums + open allocations.
+
+### Using the transfer tools, is it necessary to wait 28 days to unstake on Ethereum mainnet before transferring?
+
+No, you can transfer your stake to L2 immediately, there's no need to unstake and wait before using the transfer tool. The 28-day wait only applies if you'd like to withdraw the stake back to your wallet, on Ethereum mainnet or L2.
+
+### How long will it take to transfer my stake?
+
+It will take approximately 20 minutes for the L2 transfer tool to complete transferring your stake.
+
+### Do I have to index on Arbitrum before I transfer my stake?
+
+You can effectively transfer your stake first before setting up indexing, but you will not be able to claim any rewards on L2 until you allocate to subgraphs on L2, index them, and present POIs.
+
+### Can Delegators move their delegation before I move my indexing stake?
+
+No, in order for Delegators to transfer their delegated GRT to Arbitrum, the Indexer they are delegating to must be active on L2.
+
+### Can I transfer my stake if I'm using a GRT vesting contract / token lock wallet?
+
+Yes! The process is a bit different, because vesting contracts can't forward the ETH needed to pay for the L2 gas, so you need to deposit it beforehand. If your vesting contract is not fully vested, you will also have to first initialize a counterpart vesting contract on L2 and will only be able to transfer the stake to this L2 vesting contract. The UI on Explorer can guide you through this process when you've connected to Explorer using the vesting lock wallet.
+
+### I already have stake on L2. Do I still need to send 100k GRT when I use the transfer tools the first time?
+
+​Yes. The L1 smart contracts will not be aware of your L2 stake, so they will require you to transfer at least 100k GRT when you transfer for the first time. ​
+
+### Can I transfer my stake to L2 if I am in the process of unstaking GRT?
+
+​No. If any fraction of your stake is thawing, you have to wait the 28 days and withdraw it before you can transfer stake. The tokens that are being staked are "locked" and will prevent any transfers or stake to L2.
+
+## Vesting Contract Transfer
+
+### How do I transfer my vesting contract?
+
+To transfer your vesting, you will need to complete the following steps:
+
+1. Initiate the vesting transfer on Ethereum mainnet
+
+2. Wait 20 minutes for confirmation
+
+3. Confirm vesting transfer on Arbitrum
+
+### How do I transfer my vesting contract if I am only partially vested?
+
+<VideoEmbed youtube="URPOb2c6o2Y" />
+
+1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount)
+
+2. Send some locked GRT through the transfer tool contract, to L2 to initialize the L2 vesting lock. This will also set their L2 beneficiary address.
+
+3. Send their stake/delegation to L2 through the "locked" transfer tool functions in the L1Staking contract.
+
+4. Withdraw any remaining ETH from the transfer tool contract
+
+### How do I transfer my vesting contract if I am fully vested?
+
+<VideoEmbed youtube="DuZNYPNe1S0" />
+
+For those that are fully vested, the process is similar:
+
+1. Deposit some ETH into the transfer tool contract (UI can help estimate a reasonable amount)
+
+2. Set your L2 address with a call to the transfer tool contract
+
+3. Send your stake/delegation to L2 through the "locked" transfer tool functions in the L1 Staking contract.
+
+4. Withdraw any remaining ETH from the transfer tool contract
+
+### Can I transfer my vesting contract to Arbitrum?
+
+You can transfer your vesting contract's GRT balance to a vesting contract in L2. This is a prerequisite for transferring stake or delegation from your vesting contract to L2. The vesting contract must hold a nonzero amount of GRT (you can transfer a small amount like 1 GRT to it if needed).
+
+When you transfer GRT from your L1 vesting contract to L2, you can choose the amount to send and you can do this as many times as you like. The L2 vesting contract will be initialized the first time you transfer GRT.
+
+The transfers are done using a Transfer Tool that will be visible on your Explorer profile when you connect with the vesting contract account.
+
+Please note that you will not be able to release/withdraw GRT from the L2 vesting contract until the end of your vesting timeline when your contract is fully vested. If you need to release GRT before then, you can transfer the GRT back to the L1 vesting contract using another transfer tool that is available for that purpose.
+
+If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2.
+
+### I'm using my vesting contract to stake on mainnet. Can I transfer my stake to Arbitrum?
+
+Yes, but if your contract is still vesting, you can only transfer the stake so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your stake to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas.
+
+### I'm using my vesting contract to delegate on mainnet. Can I transfer my delegations to Arbitrum?
+
+Yes, but if your contract is still vesting, you can only transfer the delegation so that it is owned by your L2 vesting contract. You must first initialize this L2 contract by transferring some GRT balance using the vesting contract transfer tool on Explorer. If your contract is fully vested, you can transfer your delegation to any address in L2, but you must set it beforehand and deposit some ETH for the L2 transfer tool to pay for L2 gas.
+
+### Can I specify a different beneficiary for my vesting contract on L2?
+
+Yes, the first time you transfer a balance and set up your L2 vesting contract, you can specify an L2 beneficiary. Make sure this beneficiary is a wallet that can perform transactions on Arbitrum One, i.e. it must be an EOA or a multisig deployed to Arbitrum One.
+
+If your contract is fully vested, you will not set up a vesting contract on L2; instead, you will set an L2 wallet address and this will be the receiving wallet for your stake or delegation on Arbitrum.
+
+### My contract is fully vested. Can I transfer my stake or delegation to another address that is not an L2 vesting contract?
+
+Yes. If you haven't transferred any vesting contract balance to L2, and your vesting contract is fully vested, you should not transfer your vesting contract to L2. Instead, you can use the transfer tools to set an L2 wallet address, and directly transfer your stake or delegation to this regular wallet on L2.
+
+This allows you to transfer your stake or delegation to any L2 address.
+
+### My vesting contract is still vesting. How do I transfer my vesting contract balance to L2?
+
+These steps only apply if your contract is still vesting, or if you've used this process before when your contract was still vesting.
+
+To transfer your vesting contract to L2, you will send any GRT balance to L2 using the transfer tools, which will initialize your L2 vesting contract:
+
+1. Deposit some ETH into the transfer tool contract (this will be used to pay for L2 gas)
+
+2. Revoke protocol access to the vesting contract (needed for the next step)
+
+3. Give protocol access to the vesting contract (will allow your contract to interact with the transfer tool)
+
+4. Specify an L2 beneficiary address\* and initiate the balance transfer on Ethereum mainnet
+
+5. Wait 20 minutes for confirmation
+
+6. Confirm the balance transfer on L2
+
+\*If necessary - i.e. you are using a contract address.
+
+\*\*\*\*You must confirm your transaction to complete the balance transfer on Arbitrum. This step must be completed within 7 days or the balance could be lost. In most cases, this step will run automatically, but a manual confirmation may be needed if there is a gas price spike on Arbitrum. If there are any issues during this process, there will be resources to help: contact support at support@thegraph.com or on [Discord](https://discord.gg/graphprotocol).
+
+### My vesting contract shows 0 GRT so I cannot transfer it, why is this and how do I fix it?
+
+​To initialize your L2 vesting contract, you need to transfer a nonzero amount of GRT to L2. This is required by the Arbitrum GRT bridge that is used by the L2 Transfer Tools. The GRT must come from the vesting contract's balance, so it does not include staked or delegated GRT.
+
+If you've staked or delegated all your GRT from the vesting contract, you can manually send a small amount like 1 GRT to the vesting contract address from anywhere else (e.g. from another wallet, or an exchange). ​
+
+### I am using a vesting contract to stake or delegate, but I don't see a button to transfer my stake or delegation to L2, what do I do?
+
+​If your vesting contract hasn't finished vesting, you need to first create an L2 vesting contract that will receive your stake or delegation on L2. This vesting contract will not allow releasing tokens in L2 until the end of the vesting timeline, but will allow you to transfer GRT back to the L1 vesting contract to be released there.
+
+When connected with the vesting contract on Explorer, you should see a button to initialize your L2 vesting contract. Follow that process first, and you will then see the buttons to transfer your stake or delegation in your profile. ​
+
+### If I initialize my L2 vesting contract, will this also transfer my delegation to L2 automatically?
+
+​No, initializing your L2 vesting contract is a prerequisite for transferring stake or delegation from the vesting contract, but you still need to transfer these separately.
+
+You will see a banner on your profile prompting you to transfer your stake or delegation after you have initialized your L2 vesting contract.
+
+### Can I move my vesting contract back to L1?
+
+There is no need to do so because your vesting contract is still in L1. When you use the transfer tools, you just create a new contract in L2 that is connected with your L1 vesting contract, and you can send GRT back and forth between the two.
+
+### Why do I need to move my vesting contract to begin with?
+
+You need to set up an L2 vesting contract so that this account can own your stake or delegation on L2. Otherwise, there'd be no way for you to transfer the stake/delegation to L2 without "escaping" the vesting contract.
+
+### What happens if I try to cash out my contract when it is only partially vested? Is this possible?
+
+This is not a possibility. You can move funds back to L1 and withdraw them there.
+
+### What if I don't want to move my vesting contract to L2?
+
+You can keep staking/delegating on L1. Over time, you may want to consider moving to L2 to enable rewards there as the protocol scales on Arbitrum. Note that these transfer tools are for vesting contracts that are allowed to stake and delegate in the protocol. If your contract does not allow staking or delegating, or is revocable, then there is no transfer tool available. You will still be able to withdraw your GRT from L1 when available.

From ed3df1fc719b5c483a0769ca0f89e2a2aa686332 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:05 -0500
Subject: [PATCH 1044/3820] New translations l2-transfer-tools-guide.mdx
 (Romanian)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/ro/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/ro/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/ro/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..485f34a70c97
--- /dev/null
+++ b/website/pages/ro/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 Transfer Tools Guide
+---
+
+The Graph has made it easy to move to L2 on Arbitrum One. For each protocol participant, there are a set of L2 Transfer Tools to make transferring to L2 seamless for all network participants. These tools will require you to follow a specific set of steps depending on what you are transferring.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## How to transfer your subgraph to Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Benefits of transferring your subgraphs
+
+The Graph's community and core devs have [been preparing](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) to move to Arbitrum over the past year. Arbitrum, a layer 2 or "L2" blockchain, inherits the security from Ethereum but provides drastically lower gas fees.
+
+When you publish or upgrade your subgraph to The Graph Network, you're interacting with smart contracts on the protocol and this requires paying for gas using ETH. By moving your subgraphs to Arbitrum, any future updates to your subgraph will require much lower gas fees. The lower fees, and the fact that curation bonding curves on L2 are flat, also make it easier for other Curators to curate on your subgraph, increasing the rewards for Indexers on your subgraph. This lower-cost environment also makes it cheaper for Indexers to index and serve your subgraph. Indexing rewards will be increasing on Arbitrum and decreasing on Ethereum mainnet over the coming months, so more and more Indexers will be transferring their stake and setting up their operations on L2.
+
+## Understanding what happens with signal, your L1 subgraph and query URLs
+
+Transferring a subgraph to Arbitrum uses the Arbitrum GRT bridge, which in turn uses the native Arbitrum bridge, to send the subgraph to L2. The "transfer" will deprecate the subgraph on mainnet and send the information to re-create the subgraph on L2 using the bridge. It will also include the subgraph owner's signaled GRT, which must be more than zero for the bridge to accept the transfer.
+
+When you choose to transfer the subgraph, this will convert all of the subgraph's curation signal to GRT. This is equivalent to "deprecating" the subgraph on mainnet. The GRT corresponding to your curation will be sent to L2 together with the subgraph, where they will be used to mint signal on your behalf.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph. If a subgraph owner does not transfer their subgraph to L2 and manually deprecates it via a contract call, then Curators will be notified and will be able to withdraw their curation.
+
+As soon as the subgraph is transferred, since all curation is converted to GRT, Indexers will no longer receive rewards for indexing the subgraph. However, there will be Indexers that will 1) keep serving transferred subgraphs for 24 hours, and 2) immediately start indexing the subgraph on L2. Since these Indexers already have the subgraph indexed, there should be no need to wait for the subgraph to sync, and it will be possible to query the L2 subgraph almost immediately.
+
+Queries to the L2 subgraph will need to be done to a different URL (on `arbitrum-gateway.thegraph.com`), but the L1 URL will continue working for at least 48 hours. After that, the L1 gateway will forward queries to the L2 gateway (for some time), but this will add latency so it is recommended to switch all your queries to the new URL as soon as possible.
+
+## Choosing your L2 wallet
+
+When you published your subgraph on mainnet, you used a connected wallet to create the subgraph, and this wallet owns the NFT that represents this subgraph and allows you to publish updates.
+
+When transferring the subgraph to Arbitrum, you can choose a different wallet that will own this subgraph NFT on L2.
+
+If you're using a "regular" wallet like MetaMask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same owner address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 owner of your subgraph.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum. Otherwise, the subgraph will be lost and cannot be recovered.**
+
+## Preparing for the transfer: bridging some ETH
+
+Transferring the subgraph involves sending a transaction through the bridge, and then executing another transaction on Arbitrum. The first transaction uses ETH on mainnet, and includes some ETH to pay for gas when the message is received on L2. However, if this gas is insufficient, you will have to retry the transaction and pay for the gas directly on L2 (this is "Step 3: Confirming the transfer" below). This step **must be executed within 7 days of starting the transfer**. Moreover, the second transaction ("Step 4: Finishing the transfer on L2") will be done directly on Arbitrum. For these reasons, you will need some ETH on an Arbitrum wallet. If you're using a multisig or smart contract account, the ETH will need to be in the regular (EOA) wallet that you are using to execute the transactions, not on the multisig wallet itself.
+
+You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Since gas fees on Arbitrum are lower, you should only need a small amount. It is recommended that you start at a low threshold (0.e.g. 01 ETH) for your transaction to be approved.
+
+## Finding the subgraph Transfer Tool
+
+You can find the L2 Transfer Tool when you're looking at your subgraph's page on Subgraph Studio:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+It is also available on Explorer if you're connected with the wallet that owns a subgraph and on that subgraph's page on Explorer:
+
+![Transferring to L2](/img/transferToL2.png)
+
+Clicking on the Transfer to L2 button will open the transfer tool where you can start the transfer process.
+
+## Step 1: Starting the transfer
+
+Before starting the transfer, you must decide which address will own the subgraph on L2 (see "Choosing your L2 wallet" above), and it is strongly recommend having some ETH for gas already bridged on Arbitrum (see "Preparing for the transfer: bridging some ETH" above).
+
+Also please note transferring the subgraph requires having a nonzero amount of signal on the subgraph with the same account that owns the subgraph; if you haven't signaled on the subgraph you will have to add a bit of curation (adding a small amount like 1 GRT would suffice).
+
+After opening the Transfer Tool, you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Subgraph will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer and deprecate your L1 subgraph (see "Understanding what happens with signal, your L1 subgraph and query URLs" above for more details on what goes on behind the scenes).
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or the subgraph and your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retry-able tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Step 2: Waiting for the subgraph to get to L2
+
+After you start the transfer, the message that sends your L1 subgraph to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## Step 3: Confirming the transfer
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the subgraph on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your subgraph to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## Step 4: Finishing the transfer on L2
+
+At this point, your subgraph and GRT have been received on Arbitrum, but the subgraph is not published yet. You will need to connect using the L2 wallet that you chose as the receiving wallet, switch your wallet network to Arbitrum, and click "Publish Subgraph."
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+This will publish the subgraph so that Indexers that are operating on Arbitrum can start serving it. It will also mint curation signal using the GRT that were transferred from L1.
+
+## Step 5: Updating the query URL
+
+Your subgraph has been successfully transferred to Arbitrum! To query the subgraph, the new URL will be :
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Note that the subgraph ID on Arbitrum will be a different than the one you had on mainnet, but you can always find it on Explorer or Studio. As mentioned above (see "Understanding what happens with signal, your L1 subgraph and query URLs") the old L1 URL will be supported for a short while, but you should switch your queries to the new address as soon as the subgraph has been synced on L2.
+
+## How to transfer your curation to Arbitrum (L2)
+
+## Understanding what happens to curation on subgraph transfers to L2
+
+When the owner of a subgraph transfers a subgraph to Arbitrum, all of the subgraph's signal is converted to GRT at the same time. This applies to "auto-migrated" signal, i.e. signal that is not specific to a subgraph version or deployment but that follows the latest version of a subgraph.
+
+This conversion from signal to GRT is the same as what would happen if the subgraph owner deprecated the subgraph in L1. When the subgraph is deprecated or transferred, all curation signal is "burned" simultaneously (using the curation bonding curve) and the resulting GRT is held by the GNS smart contract (that is the contract that handles subgraph upgrades and auto-migrated signal). Each Curator on that subgraph therefore has a claim to that GRT proportional to the amount of shares they had for the subgraph.
+
+A fraction of these GRT corresponding to the subgraph owner is sent to L2 together with the subgraph.
+
+At this point, the curated GRT will not accrue any more query fees, so Curators can choose to withdraw their GRT or transfer it to the same subgraph on L2, where it can be used to mint new curation signal. There is no rush to do this as the GRT can be help indefinitely and everybody gets an amount proportional to their shares, irrespective of when they do it.
+
+## Choosing your L2 wallet
+
+If you decide to transfer your curated GRT to L2, you can choose a different wallet that will own the curation signal on L2.
+
+If you're using a "regular" wallet like Metamask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same Curator address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 receiving wallet address.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum, as otherwise the curation will be lost and cannot be recovered.**
+
+## Sending curation to L2: Step 1
+
+Before starting the transfer, you must decide which address will own the curation on L2 (see "Choosing your L2 wallet" above), and it is recommended having some ETH for gas already bridged on Arbitrum in case you need to retry the execution of the message on L2. You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - since gas fees on Arbitrum are so low, you should only need a small amount, e.g. 0.01 ETH will probably be more than enough.
+
+If a subgraph that you curate to has been transferred to L2, you will see a message on Explorer telling you that you're curating to a transferred subgraph.
+
+When looking at the subgraph page, you can choose to withdraw or transfer the curation. Clicking on "Transfer Signal to Arbitrum" will open the transfer tool.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+After opening the Transfer Tool, you may be prompted to add some ETH to your wallet if you don't have any. Then you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Signal will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer.
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retryable tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+## Sending curation to L2: step 2
+
+Starting the transfer:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+After you start the transfer, the message that sends your L1 curation to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Sending curation to L2: step 3
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the curation on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your curation to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Withdrawing your curation on L1
+
+If you prefer not to send your GRT to L2, or you'd rather bridge the GRT manually, you can withdraw your curated GRT on L1. On the banner on the subgraph page, choose "Withdraw Signal" and confirm the transaction; the GRT will be sent to your Curator address.

From 59e14b170a3036baafe6d40b4d86d6ced27886ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:06 -0500
Subject: [PATCH 1045/3820] New translations l2-transfer-tools-guide.mdx
 (French)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/fr/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/fr/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/fr/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..2600c26e53a4
--- /dev/null
+++ b/website/pages/fr/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: Guide des outils de transfert L2
+---
+
+The Graph a facilité le passage à L2 sur Arbitrum One. Pour chaque participant au protocole, il existe un ensemble d'outils de transfert L2 permettant de rendre le transfert vers L2 transparent pour tous les participants du réseau. Ces outils vous obligeront à suivre un ensemble d’étapes spécifiques en fonction de ce que vous transférez.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## Comment transférer votre subgraph vers Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Avantages du transfert de vos subgraphs
+
+La communauté et les développeurs du Graph se sont préparés (https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) à passer à Arbitrum au cours de l'année écoulée. Arbitrum, une blockchain de couche 2 ou "L2", hérite de la sécurité d'Ethereum mais offre des frais de gaz considérablement réduits.
+
+Lorsque vous publiez ou mettez à niveau votre subgraph sur The Graph Network, vous interagissez avec des contrats intelligents sur le protocole, ce qui nécessite de payer le gaz avec ETH. En déplaçant vos subgraphs vers Arbitrum, toute mise à jour future de votre subgraph nécessitera des frais de gaz bien inférieurs. Les frais inférieurs et le fait que les courbes de liaison de curation sur L2 soient plates facilitent également la curation pour les autres conservateurs sur votre subgraph, augmentant ainsi les récompenses des indexeurs sur votre subgraph. Cet environnement moins coûteux rend également moins cher pour les indexeurs l'indexation et la diffusion de votre subgraph. Les récompenses d'indexation augmenteront sur Arbitrum et diminueront sur le réseau principal Ethereum au cours des prochains mois, de sorte que de plus en plus d'indexeurs transféreront leur participation et établiront leurs opérations sur L2.
+
+## Comprendre ce qui se passe avec le signal, votre subgraph L1 et les URL de requête
+
+Le transfert d'un subgraph vers Arbitrum utilise le pont GRT sur Arbitrum, qui à son tour utilise le pont natif d'Arbitrum, pour envoyer le subgraph vers L2. Le 'transfert' va déprécier le subgraph sur le mainnet et envoyer les informations pour recréer le subgraph sur L2 en utilisant le pont. Il inclura également les GRT signalés par le propriétaire du subgraph, qui doivent être supérieurs à zéro pour que le pont accepte le transfert.
+
+Lorsque vous choisissez de transférer le subgraph, cela convertira tous les signaux de curation du subgraph en GRT. Cela équivaut à "déprécier" le subgraph sur le mainnet. Les GRT correspondant à votre curation seront envoyés à L2 avec le subgraph, où ils seront utilisés pour monnayer des signaux en votre nom.
+
+Les autres curateurs peuvent choisir de retirer leur fraction de GRT ou de la transférer également à L2 pour le signal de monnayage sur le même subgraph. Si un propriétaire de subgraph ne transfère pas son subgraph à L2 et le déprécie manuellement via un appel de contrat, les curateurs en seront informés et pourront retirer leur curation.
+
+Dès que le subgraph est transféré, puisque toute la curation est convertie en GRT, les indexeurs ne recevront plus de récompenses pour l'indexation du subgraph. Cependant, certains indexeurs 1) continueront à servir les subgraphs transférés pendant 24 heures et 2) commenceront immédiatement à indexer le subgraph sur L2. Comme ces indexeurs ont déjà indexé le subgraph, il ne devrait pas être nécessaire d'attendre la synchronisation du subgraph, et il sera possible d'interroger le subgraph L2 presque immédiatement.
+
+Les requêtes vers le subgraph L2 devront être effectuées vers une URL différente (sur `arbitrum-gateway.thegraph.com`), mais l'URL L1 continuera à fonctionner pendant au moins 48 heures. Après cela, la passerelle L1 transmettra les requêtes à la passerelle L2 (pendant un certain temps), mais cela augmentera la latence. Il est donc recommandé de basculer toutes vos requêtes vers la nouvelle URL dès que possible.
+
+## Choisir son portefeuille L2
+
+Lorsque vous avez publié votre subgraph sur le mainnet, vous avez utilisé un portefeuille connecté pour créer le subgraph, et ce portefeuille possède le NFT qui représente ce subgraph et vous permet de publier des mises à jour.
+
+Lors du transfert du subgraph vers Arbitrum, vous pouvez choisir un autre portefeuille qui possédera ce subgraph NFT sur L2.
+
+Si vous utilisez un portefeuille "normal" comme MetaMask (un Externally Owned Account ou EOA, c'est-à-dire un portefeuille qui n'est pas un smart contract), cette étape est facultative et il est recommandé de conserver la même adresse de propriétaire que dans L1.portefeuille.
+
+Si vous utilisez un portefeuille de smart contrat, comme un multisig (par exemple un Safe), alors choisir une adresse de portefeuille L2 différente est obligatoire, car il est très probable que ce compte n'existe que sur le mainnet et vous ne pourrez pas faire de transactions sur Arbitrum en utilisant ce portefeuille. Si vous souhaitez continuer à utiliser un portefeuille de contrat intelligent ou un multisig, créez un nouveau portefeuille sur Arbitrum et utilisez son adresse comme propriétaire L2 de votre subgraph.
+
+**Il est très important d'utiliser une adresse de portefeuille que vous contrôlez, et qui peut effectuer des transactions sur Arbitrum. Dans le cas contraire, le subgraph sera perdu et ne pourra pas être récupéré**
+
+## Préparer le transfert : faire le pont avec quelques EPF
+
+Le transfert du subgraph implique l'envoi d'une transaction à travers le pont, puis l'exécution d'une autre transaction sur Arbitrum. La première transaction utilise de l'ETH sur le mainnet, et inclut de l'ETH pour payer le gaz lorsque le message est reçu sur L2. Cependant, si ce gaz est insuffisant, vous devrez réessayer la transaction et payer le gaz directement sur L2 (c'est "l'étape 3 : Confirmer le transfert" ci-dessous). Cette étape **doit être exécutée dans les 7 jours suivant le début du transfert**. De plus, la deuxième transaction ("Etape 4 : Terminer le transfert sur L2") se fera directement sur Arbitrum. Pour ces raisons, vous aurez besoin de quelques ETH sur un portefeuille Arbitrum. Si vous utilisez un compte multisig ou smart contract, l'ETH devra être dans le portefeuille régulier (EOA) que vous utilisez pour exécuter les transactions, et non sur le portefeuille multisig lui-même.
+
+Vous pouvez acheter de l'ETH sur certains échanges et le retirer directement sur Arbitrum, ou vous pouvez utiliser le pont Arbitrum pour envoyer de l'ETH d'un portefeuille du mainnet vers L2 : [bridge.arbitrum.io](http://bridge.arbitrum.io). Étant donné que les frais de gaz sur Arbitrum sont moins élevés, vous ne devriez avoir besoin que d'une petite quantité. Il est recommandé de commencer par un seuil bas (0,par exemple 01 ETH) pour que votre transaction soit approuvée.
+
+## Trouver l'outil de transfert de subgraph
+
+Vous pouvez trouver l'outil de transfert L2 lorsque vous consultez la page de votre subgraph dans le Subgraph Studio :
+
+![outil de transfert](/img/L2-transfer-tool1.png)
+
+Elle est également disponible sur Explorer si vous êtes connecté au portefeuille qui possède un subgraph et sur la page de ce subgraph sur Explorer :
+
+![Transfert vers L2](/img/transferToL2.png)
+
+En cliquant sur le bouton Transférer vers L2, vous ouvrirez l'outil de transfert qui vous permettra de lancer la procédure de transfert.
+
+## Étape 1 : Démarrer le transfert
+
+Avant de commencer le transfert, vous devez décider quelle adresse sera propriétaire du subgraph sur L2 (voir "Choisir votre portefeuille L2" ci-dessus), et il est fortement recommandé d'avoir quelques ETH pour le gaz déjà bridgé sur Arbitrum (voir "Préparer le transfert : brider quelques ETH" ci-dessus).
+
+Veuillez également noter que le transfert du subgraph nécessite d'avoir un montant de signal non nul sur le subgraph avec le même compte qui possède le subgraph ; si vous n'avez pas signalé sur le subgraph, vous devrez ajouter un peu de curation (ajouter un petit montant comme 1 GRT suffirait).
+
+Après avoir ouvert l'outil de transfert, vous pourrez saisir l'adresse du portefeuille L2 dans le champ "Adresse du portefeuille destinataire" - **assurez-vous que vous avez saisi la bonne adresse ici**. En cliquant sur Transférer le subgraph, vous serez invité à exécuter la transaction sur votre portefeuille (notez qu'une certaine valeur ETH est incluse pour payer le gaz L2) ; cela lancera le transfert et dépréciera votre subgraph L1 (voir "Comprendre ce qui se passe avec le signal, votre subgraph L1 et les URL de requête" ci-dessus pour plus de détails sur ce qui se passe en coulisses).
+
+Si vous exécutez cette étape, **assurez-vous de continuer jusqu'à terminer l'étape 3 en moins de 7 jours, sinon le subgraph et votre signal GRT seront perdus.** Cela est dû au fonctionnement de la messagerie L1-L2 sur Arbitrum : les messages qui sont envoyés via le pont sont des « tickets réessayables » qui doivent être exécutés dans les 7 jours, et l'exécution initiale peut nécessiter une nouvelle tentative s'il y a des pics dans le prix du gaz sur Arbitrum.
+
+![Démarrer le transfert vers la L2](/img/startTransferL2.png)
+
+## Étape 2 : Attendre que le subgraphe atteigne L2
+
+Après avoir lancé le transfert, le message qui envoie votre subgraph de L1 à L2 doit se propager à travers le pont Arbitrum. Cela prend environ 20 minutes (le pont attend que le bloc du réseau principal contenant la transaction soit "sûr" face aux potentielles réorganisations de la chaîne).
+
+Une fois ce temps d'attente terminé, le réseau Arbitrum tentera d'exécuter automatiquement le transfert sur les contrats L2.
+
+![Écran d'attente](/img/screenshotOfWaitScreenL2.png)
+
+## Étape 3 : Confirmer le transfert
+
+Dans la plupart des cas, cette étape s'exécutera automatiquement car le gaz L2 inclus dans l'étape 1 devrait être suffisant pour exécuter la transaction qui reçoit le subgraph sur les contrats Arbitrum. Cependant, dans certains cas, il est possible qu'une hausse soudaine des prix du gaz sur Arbitrum entraîne l'échec de cette exécution automatique. Dans ce cas, le "ticket" qui envoie votre subgraphe vers L2 sera en attente et nécessitera une nouvelle tentative dans les 7 jours.
+
+Si c'est le cas, vous devrez vous connecter en utilisant un portefeuille L2 qui contient de l'ETH sur Arbitrum, changer le réseau de votre portefeuille vers Arbitrum, et cliquer sur "Confirmer le transfert" pour retenter la transaction.
+
+[Confirmer le transfert vers L2](/img/confirmTransferToL2.png)
+
+## Étape 4 : Terminer le transfert sur L2
+
+À ce stade, votre subgraph et vos GRT ont été reçus sur Arbitrum, mais le subgraph n'est pas encore publié. Vous devrez vous connecter à l'aide du portefeuille L2 que vous avez choisi comme portefeuille de réception, basculer votre réseau de portefeuille sur Arbitrum et cliquer sur « Publier le subgraph.»
+
+![Publier le subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Attendez que le subgraph soit publié](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+Cela permettra de publier le subgraph afin que les indexeurs opérant sur Arbitrum puissent commencer à le servir. Il va également modifier le signal de curation en utilisant les GRT qui ont été transférés de L1.
+
+## Étape 5 : Mise à jour de l'URL de la requête
+
+Votre subgraph a été transféré avec succès vers Arbitrum ! Pour interroger le subgraph, la nouvelle URL sera :
+
+https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]\`
+
+Notez que l'ID du subgraph sur Arbitrum sera différent de celui que vous aviez sur le mainnet, mais vous pouvez toujours le trouver sur Explorer ou Studio. Comme mentionné ci-dessus (voir "Comprendre ce qui se passe avec le signal, votre subgraph L1 et les URL de requête"), l'ancienne URL L1 sera prise en charge pendant une courte période, mais vous devez basculer vos requêtes vers la nouvelle adresse dès que le subgraph aura été synchronisé. sur L2.
+
+## Comment transférer votre curation vers Arbitrum (L2)
+
+## Comprendre ce qui arrive à la curation lors des transferts de subgraphs vers L2
+
+Lorsque le propriétaire d'un subgraph transfère un subgraph vers Arbitrum, tout le signal du subgraph est converti en GRT en même temps. Cela s'applique au signal "auto-migré", c'est-à-dire au signal qui n'est pas spécifique à une version de subgraph ou à un déploiement, mais qui suit la dernière version d'un subgraph.
+
+Cette conversion du signal en GRT est identique à ce qui se produirait si le propriétaire du subgraph dépréciait le subgraph en L1. Lorsque le subgraph est déprécié ou transféré, tout le signal de curation est "brûlé" simultanément (en utilisant la courbe de liaison de curation) et le GRT résultant est détenu par le contrat intelligent GNS (c'est-à-dire le contrat qui gère les mises à niveau des subgraphs et le signal auto-migré). Chaque Curateur de ce subgraph a donc droit à ce GRT de manière proportionnelle à la quantité de parts qu'il détenait pour le subgraph.
+
+Une fraction de ces GRT correspondant au propriétaire du subgraph est envoyée à L2 avec le subgraph.
+
+À ce stade, le GRT organisé n'accumulera plus de frais de requête, les conservateurs peuvent donc choisir de retirer leur GRT ou de le transférer vers le même subgraph sur L2, où il pourra être utilisé pour créer un nouveau signal de curation. Il n'y a pas d'urgence à le faire car le GRT peut être utile indéfiniment et chacun reçoit un montant proportionnel à ses actions, quel que soit le moment où il le fait.
+
+## Choisir son portefeuille L2
+
+Si vous décidez de transférer votre GRT organisé vers L2, vous pouvez choisir un autre portefeuille qui détiendra le signal de curation sur L2.
+
+Si vous utilisez un portefeuille « normal » comme Metamask (un compte externe ou EOA, c'est-à-dire un portefeuille qui n'est pas un contrat intelligent), alors ceci est facultatif et il est recommandé de conserver la même adresse de conservateur qu'en L1.
+
+Si vous utilisez un portefeuille de contrat intelligent, comme un multisig (par exemple un coffre-fort), alors choisir une autre adresse de portefeuille L2 est obligatoire, car il est fort probable que ce compte n'existe que sur le mainnet et que vous ne pourrez pas effectuer de transactions. sur Arbitrum en utilisant ce portefeuille. Si vous souhaitez continuer à utiliser un portefeuille de contrat intelligent ou multisig, créez un nouveau portefeuille sur Arbitrum et utilisez son adresse comme adresse du portefeuille de réception L2.
+
+**Il est très important d'utiliser une adresse de portefeuille que vous contrôlez et qui peut effectuer des transactions sur Arbitrum, sinon la curation sera perdue et ne pourra pas être récupérée.**
+
+## Envoi de la curation à L2 : Étape 1
+
+Avant de commencer le transfert, vous devez décider quelle adresse détiendra la curation sur L2 (voir "Choisir votre portefeuille L2" ci-dessus), et il est recommandé d'avoir des ETH pour le gaz déjà pontés sur Arbitrum au cas où vous auriez besoin de réessayer l'exécution du message sur L2. Vous pouvez acheter de l'ETH sur certaines bourses et le retirer directement sur Arbitrum, ou vous pouvez utiliser le pont Arbitrum pour envoyer de l'ETH depuis un portefeuille du mainnet vers L2 : [bridge.arbitrum.io](http://bridge.arbitrum.io) - étant donné que les frais de gaz sur Arbitrum sont si bas, vous ne devriez avoir besoin que d'un petit montant, par ex. 0,01 ETH sera probablement plus que suffisant.
+
+Si un subgraph que vous organisez a été transféré vers L2, vous verrez un message sur l'Explorateur vous indiquant que vous organisez un subgraph transféré.
+
+En consultant la page du subgraph, vous pouvez choisir de retirer ou de transférer la curation. En cliquant sur "Transférer le signal vers Arbitrum", vous ouvrirez l'outil de transfert.
+
+Signal de transfert](/img/transferSignalL2TransferTools.png)
+
+Après avoir ouvert l'outil de transfert, vous serez peut-être invité à ajouter de l'ETH à votre portefeuille si vous n'en avez pas. Vous pourrez ensuite saisir l'adresse du portefeuille L2 dans le champ "Adresse du portefeuille de réception" - **assurez-vous d'avoir saisi la bonne adresse ici**. En cliquant sur Transfer Signal, vous serez invité à exécuter la transaction sur votre portefeuille (notez qu'une certaine valeur ETH est incluse pour payer le gaz L2) ; cela lancera le transfert.
+
+Si vous exécutez cette étape, **assurez-vous de procéder jusqu'à la complétion de l'étape 3 en moins de 7 jours, sinon vos GRT signalés seront perdus.** Cela est dû à la façon dont la messagerie L1-L2 fonctionne sur Arbitrum : les messages qui sont envoyés à travers le pont sont des "tickets à retenter" qui doivent être exécutés dans les 7 jours, et l'exécution initiale peut nécessiter une nouvelle tentative s'il y a des pics dans le prix du gaz sur Arbitrum.
+
+## Envoi de la curation vers L2 : étape 2
+
+Démarrage du transfert :
+
+![Envoyer un signal à L2](/img/sendingCurationToL2Step2First.png)
+
+Une fois que vous avez commencé le transfert, le message qui envoie votre curation L1 à L2 doit se propager à travers le pont Arbitrum. Cela prend environ 20 minutes (le pont attend que le bloc du mainnet contenant la transaction soit "à l'abri" d'une éventuelle réorganisation de la chaîne).
+
+Une fois ce temps d'attente terminé, le réseau Arbitrum tentera d'exécuter automatiquement le transfert sur les contrats L2.
+
+![Envoi du signal de curation à L2](/img/sendingCurationToL2Step2Second.png)
+
+## Envoi de la curation vers L2 : étape 3
+
+Dans la plupart des cas, cette étape s'exécutera automatiquement car le gaz L2 inclus dans l'étape 1 devrait être suffisant pour exécuter la transaction qui reçoit la curation sur les contrats Arbitrum. Dans certains cas, cependant, il est possible qu'une flambée des prix du gaz sur Arbitrum fasse échouer cette exécution automatique. Dans ce cas, le « ticket » qui envoie votre curation vers L2 sera en attente et nécessitera une nouvelle tentative sous 7 jours.
+
+Si c'est le cas, vous devrez vous connecter en utilisant un portefeuille L2 qui contient de l'ETH sur Arbitrum, changer le réseau de votre portefeuille vers Arbitrum, et cliquer sur "Confirmer le transfert" pour retenter la transaction.
+
+![Envoyer un signal à L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Retrait de la curation sur L1
+
+Si vous préférez ne pas envoyer votre GRT vers L2, ou si vous préférez combler le GRT manuellement, vous pouvez retirer votre GRT organisé sur L1. Sur la bannière de la page du subgraph, choisissez « Retirer le signal » et confirmez la transaction ; le GRT sera envoyé à votre adresse de conservateur.

From ca4659202deb5e73df62a1d62193fd867d9fce43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:07 -0500
Subject: [PATCH 1046/3820] New translations l2-transfer-tools-guide.mdx
 (Spanish)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/es/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/es/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/es/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..2158a5f33db3
--- /dev/null
+++ b/website/pages/es/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: Guía de las Herramientas de Transferencia a L2
+---
+
+The Graph ha facilitado la migración a L2 en Arbitrum One. Para cada participante del protocolo, existen un conjunto de herramientas de transferencia a L2 para que la migración sea fluida para todos los participantes de la red. Estas herramientas requerirán que sigas un conjunto específico de pasos dependiendo de lo que estés transfiriendo.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## Cómo transferir tu subgrafo a Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Beneficios de transferir tus subgrafos
+
+La comunidad de The Graph y los core devs se han [estado preparando] (https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) para migrar a Arbitrum durante el último año. Arbitrum, una blockchain de capa 2 o "L2", hereda la seguridad de Ethereum pero ofrece tarifas de gas considerablemente más bajas.
+
+Cuando publicas o actualizas tus subgrafos en The Graph Network, estás interactuando con contratos inteligentes en el protocolo, lo cual requiere pagar por gas utilizando ETH. Al mover tus subgrafos a Arbitrum, cualquier actualización futura de tu subgrafo requerirá tarifas de gas mucho más bajas. Las tarifas más bajas, y el hecho de que las bonding curves de curación en L2 son planas, también facilitan que otros Curadores realicen curación en tu subgrafo, aumentando las recompensas para los Indexadores en tu subgrafo. Este contexto con tarifas más económicas también hace que sea más barato para los Indexadores indexar y servir tu subgrafo. Las recompensas por indexación aumentarán en Arbitrum y disminuirán en Ethereum mainnet en los próximos meses, por lo que cada vez más Indexadores transferirán su stake y establecerán sus operaciones en L2.
+
+## Comprensión de lo que sucede con la señal, tu subgrafo de L1 y las URL de consulta
+
+Transferir un subgrafo a Arbitrum utiliza el puente de GRT de Arbitrum, que a su vez utiliza el puente nativo de Arbitrum para enviar el subgrafo a L2. La "transferencia" deprecará el subgrafo en mainnet y enviará la información para recrear el subgrafo en L2 utilizando el puente. También incluirá el GRT señalizado del propietario del subgrafo, el cual debe ser mayor que cero para que el puente acepte la transferencia.
+
+Cuando eliges transferir el subgrafo, esto convertirá toda la señal de curación del subgrafo a GRT. Esto equivale a "deprecar" el subgrafo en mainnet. El GRT correspondiente a tu curación se enviará a L2 junto con el subgrafo, donde se utilizarán para emitir señal en tu nombre.
+
+Otros Curadores pueden elegir si retirar su fracción de GRT o también transferirlo a L2 para emitir señal en el mismo subgrafo. Si un propietario de subgrafo no transfiere su subgrafo a L2 y lo depreca manualmente a través de una llamada de contrato, entonces los Curadores serán notificados y podrán retirar su curación.
+
+Tan pronto como se transfiera el subgrafo, dado que toda la curación se convierte en GRT, los Indexadores ya no recibirán recompensas por indexar el subgrafo. Sin embargo, habrá Indexadores que 1) continuarán sirviendo los subgrafos transferidos durante 24 horas y 2) comenzarán inmediatamente a indexar el subgrafo en L2. Dado que estos Indexadores ya tienen el subgrafo indexado, no será necesario esperar a que se sincronice el subgrafo y será posible realizar consultas al subgrafo en L2 casi de inmediato.
+
+Las consultas al subgrafo en L2 deberán realizarse a una URL diferente (en `arbitrum-gateway.thegraph.com`), pero la URL de L1 seguirá funcionando durante al menos 48 horas. Después de eso, la gateway de L1 redirigirá las consultas a la gateway de L2 (durante algún tiempo), pero esto agregará latencia, por lo que se recomienda cambiar todas las consultas a la nueva URL lo antes posible.
+
+## Elección de tu wallet en L2
+
+Cuando publicaste tu subgrafo en mainnet, utilizaste una wallet conectada para crear el subgrafo, y esta wallet es la propietaria del NFT que representa este subgrafo y te permite publicar actualizaciones.
+
+Al transferir el subgrafo a Arbitrum, puedes elegir una wallet diferente que será la propietaria del NFT de este subgrafo en L2.
+
+Si estás utilizando una wallet "convencional" como MetaMask (una Cuenta de Propiedad Externa o EOA, es decir, una wallet que no es un contrato inteligente), esto es opcional y se recomienda para mantener la misma dirección del propietario que en L1.
+
+Si estás utilizando una wallet de tipo smart contract, como una multisig (por ejemplo, una Safe), entonces elegir una dirección de wallet L2 diferente es obligatorio, ya que es muy probable que esta cuenta solo exista en mainnet y no podrás realizar transacciones en Arbitrum utilizando esta wallet. Si deseas seguir utilizando una wallet de tipo smart contract o multisig, crea una nueva wallet en Arbitrum y utiliza su dirección como propietario L2 de tu subgrafo.
+
+**Es muy importante utilizar una dirección de wallet que controles y que pueda realizar transacciones en Arbitrum. De lo contrario, el subgrafo se perderá y no podrá ser recuperado.**
+
+## Preparándose para la transferencia: bridgeando algo de ETH
+
+Transferir el subgrafo implica enviar una transacción a través del puente y luego ejecutar otra transacción en Arbitrum. La primera transacción utiliza ETH en la red principal e incluye cierta cantidad de ETH para pagar el gas cuando se recibe el mensaje en L2. Sin embargo, si este gas es insuficiente, deberás volver a intentar la transacción y pagar el gas directamente en L2 (esto es "Paso 3: Confirmando la transferencia" que se describe a continuación). Este paso **debe ejecutarse dentro de los 7 días desde el inicio de la transferencia**. Además, la segunda transacción ("Paso 4: Finalizando la transferencia en L2") se realizará directamente en Arbitrum. Por estas razones, necesitarás tener algo de ETH en una billetera de Arbitrum. Si estás utilizando una cuenta de firma múltiple o un contrato inteligente, el ETH debe estar en la billetera regular (EOA) que estás utilizando para ejecutar las transacciones, no en la billetera de firma múltiple en sí misma.
+
+Puedes comprar ETH en algunos exchanges y retirarlo directamente a Arbitrum, o puedes utilizar el puente de Arbitrum para enviar ETH desde una billetera en la red principal a L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Dado que las tarifas de gas en Arbitrum son más bajas, solo necesitarás una pequeña cantidad. Se recomienda que comiences con un umbral bajo (por ejemplo, 0.01 ETH) para que tu transacción sea aprobada.
+
+## Encontrando la herramienta de transferencia del subgrafo
+
+Puedes encontrar la herramienta de transferencia a L2 cuando estás viendo la página de tu subgrafo en Subgraph Studio:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+También está disponible en Explorer si estás conectado con la wallet que es propietaria de un subgrafo y en la página de ese subgrafo en Explorer:
+
+![Transferring to L2](/img/transferToL2.png)
+
+Al hacer clic en el botón "Transferir a L2" se abrirá la herramienta de transferencia donde puedes iniciar el proceso de transferencia.
+
+## Paso 1: Iniciar la transferencia
+
+Antes de iniciar la transferencia, debes decidir qué dirección será la propietaria del subgrafo en L2 (ver "Elección de tu wallet en L2" anteriormente), y se recomienda encarecidamente tener ETH para gas ya transferido a Arbitrum (ver "Preparando para la transferencia: transferir ETH" anteriormente).
+
+También ten en cuenta que la transferencia del subgrafo requiere tener una cantidad distinta de cero de señal en el subgrafo con la misma cuenta que es propietaria del subgrafo; si no has emitido señal en el subgrafo, deberás agregar un poco de curación (añadir una pequeña cantidad como 1 GRT sería suficiente).
+
+Después de abrir la herramienta de transferencia, podrás ingresar la dirección de la wallet L2 en el campo "Dirección de la wallet receptora" - asegúrate de ingresar la dirección correcta aquí. Al hacer clic en "Transferir Subgrafo", se te pedirá que ejecutes la transacción en tu wallet (ten en cuenta que se incluye un valor de ETH para pagar el gas de L2); esto iniciará la transferencia y deprecará tu subgrafo de L1 (consulta "Comprensión de lo que sucede con la señal, tu subgrafo de L1 y las URL de consulta" anteriormente para obtener más detalles sobre lo que ocurre detrás de escena).
+
+Si ejecutas este paso, **asegúrate de completar el paso 3 en menos de 7 días, o el subgrafo y tu GRT de señal se perderán**. Esto se debe a cómo funciona la mensajería de L1 a L2 en Arbitrum: los mensajes que se envían a través del puente son "tickets reintentables" que deben ejecutarse dentro de los 7 días, y la ejecución inicial puede requerir un reintento si hay picos en el precio del gas en Arbitrum.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Paso 2: Esperarando a que el subgrafo llegue a L2
+
+Después de iniciar la transferencia, el mensaje que envía tu subgrafo de L1 a L2 debe propagarse a través del puente de Arbitrum. Esto tarda aproximadamente 20 minutos (el puente espera a que el bloque de mainnet que contiene la transacción sea "seguro" para evitar posibles reorganizaciones de la cadena).
+
+Una vez que finalice este tiempo de espera, Arbitrum intentará ejecutar automáticamente la transferencia en los contratos de L2.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## Paso 3: Confirmando la transferencia
+
+En la mayoría de los casos, este paso se ejecutará automáticamente, ya que el gas de L2 incluido en el paso 1 debería ser suficiente para ejecutar la transacción que recibe el subgrafo en los contratos de Arbitrum. Sin embargo, en algunos casos, es posible que un aumento en el precio del gas en Arbitrum cause que esta autoejecución falle. En este caso, el "ticket" que envía tu subgrafo a L2 quedará pendiente y requerirá un reintento dentro de los 7 días.
+
+Si este es el caso, deberás conectarte utilizando una wallet de L2 que tenga algo de ETH en Arbitrum, cambiar la red de tu wallet a Arbitrum y hacer clic en "Confirmar Transferencia" para volver a intentar la transacción.
+
+![Confirmar la transferencia a L2](/img/confirmTransferToL2.png)
+
+## Paso 4: Finalizando la transferencia en L2
+
+En este punto, tu subgrafo y GRT se han recibido en Arbitrum, pero el subgrafo aún no se ha publicado. Deberás conectarte utilizando la wallet de L2 que elegiste como la wallet receptora, cambiar la red de tu wallet a Arbitrum y hacer clic en "Publicar Subgrafo".
+
+![Publicar el subgrafo](/img/publishSubgraphL2TransferTools.png)
+
+![Espera a que el subgrafo este publicado](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+Esto publicará el subgrafo para que los Indexadores que estén operando en Arbitrum puedan comenzar a servirlo. También se emitirá señal de curación utilizando los GRT que se transfirieron desde L1.
+
+## Paso 5: Actualizando la URL de consulta
+
+¡Tu subgrafo se ha transferido correctamente a Arbitrum! Para realizar consultas al subgrafo, la nueva URL será:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Ten en cuenta que el ID del subgrafo en Arbitrum será diferente al que tenías en mainnet, pero siempre podrás encontrarlo en Explorer o Studio. Como se mencionó anteriormente (ver "Comprensión de lo que sucede con la señal, tu subgrafo de L1 y las URL de consulta"), la antigua URL de L1 será compatible durante un corto período de tiempo, pero debes cambiar tus consultas a la nueva dirección tan pronto como el subgrafo se haya sincronizado en L2.
+
+## Cómo transferir tu curación a Arbitrum (L2)
+
+## Comprensión de lo que sucede con la curación al transferir subgrafos a L2
+
+Cuando el propietario de un subgrafo transfiere un subgrafo a Arbitrum, toda la señal del subgrafo se convierte en GRT al mismo tiempo. Esto se aplica a la señal "migrada automáticamente", es decir, la señal que no está vinculada a una versión o deploy específico del subgrafo, sino que sigue la última versión del subgrafo.
+
+Esta conversión de señal a GRT es similar a lo que sucedería si el propietario del subgrafo deprecara el subgrafo en L1. Cuando el subgrafo se depreca o se transfiere, toda la señal de curación se "quema" simultáneamente (utilizando la bonding curve de curación) y el GRT resultante se mantiene en el contrato inteligente de GNS (que es el contrato que maneja las actualizaciones de subgrafos y la señal auto-migrada). Cada Curador en ese subgrafo, por lo tanto, tiene un reclamo sobre ese GRT proporcional a la cantidad de participaciones que tenían para el subgrafo.
+
+Una fracción de estos GRT correspondientes al propietario del subgrafo se envía a L2 junto con el subgrafo.
+
+En este punto, el GRT curado ya no acumulará más tarifas de consulta, por lo que los Curadores pueden optar por retirar su GRT o transferirlo al mismo subgrafo en L2, donde se puede utilizar para generar nueva señal de curación. No hay prisa para hacerlo, ya que el GRT se puede mantener indefinidamente y todos reciben una cantidad proporcional a sus participaciones, independientemente de cuándo lo hagan.
+
+## Elección de tu wallet en L2
+
+Si decides transferir tu GRT curado a L2, puedes elegir una wallet diferente que será propietaria de la señal de curación en L2.
+
+Si estás utilizando una wallet "regular" como Metamask (una cuenta de propietario externa o EOA, es decir, una wallet que no es un contrato inteligente), entonces esto es opcional y se recomienda mantener la misma dirección de Curador que en L1.
+
+Si estás utilizando una billetera de contrato inteligente, como una multisig (por ejemplo, Safe), entonces elegir una dirección de wallet diferente en L2 es obligatorio, ya que es muy probable que esta cuenta solo exista en mainnet y no puedas realizar transacciones en Arbitrum utilizando esta wallet. Si deseas seguir utilizando una wallet de contrato inteligente o una multisig, crea una nueva wallet en Arbitrum y utiliza su dirección como la dirección de wallet receptora en L2.
+
+**Es muy importante utilizar una dirección de wallet que controles y que pueda realizar transacciones en Arbitrum, ya que de lo contrario la curación se perderá y no podrá recuperarse.**
+
+## Enviando curacion para L2: Paso 1
+
+Antes de comenzar la transferencia, debes decidir qué dirección será la propietaria de la curación en L2 (ver "Elegir tu wallet en L2" arriba), y se recomienda tener algo de ETH para el gas ya bridgeado en Arbitrum en caso de que necesites volver a intentar la ejecución del mensaje en L2. Puedes comprar ETH en algunos exchanges y retirarlo directamente a Arbitrum, o puedes utilizar el puente de Arbitrum para enviar ETH desde una wallet en la red principal a L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - dado que las tarifas de gas en Arbitrum son muy bajas, es probable que solo necesites una pequeña cantidad, por ejemplo, 0.01 ETH será más que suficiente.
+
+Si un subgrafo al que has curado ha sido transferido a L2, verás un mensaje en Explorer que te indicará que estás curando hacia un subgrafo transferido.
+
+Cuando estás en la página del subgrafo, puedes elegir retirar o transferir la curación. Al hacer clic en "Transferir Señal a Arbitrum" se abrirá la herramienta de transferencia.
+
+![Transferir señal](/img/transferSignalL2TransferTools.png)
+
+Después de abrir la Herramienta de Transferencia, es posible que se te solicite agregar algo de ETH a tu wallet si no tienes. Luego podrás ingresar la dirección de la wallet en L2 en el campo "Dirección de la wallet receptora" - **asegúrate de ingresar la dirección correcta aquí**. Al hacer clic en "Transferir Señal" se te pedirá que ejecutes la transacción en tu wallet (nota que se incluye un valor de ETH para pagar el gas de L2); esto iniciará la transferencia.
+
+Si ejecutas este paso, **asegúrate de proceder y completar el paso 3 en menos de 7 días, o tu GRT de señal se perderá**. Esto se debe a cómo funciona la mensajería entre L1 y L2 en Arbitrum: los mensajes que se envían a través del puente son "tickets reintentables" que deben ejecutarse dentro de los 7 días, y la ejecución inicial podría necesitar un reintento si hay aumentos en el precio del gas en Arbitrum.
+
+## Enviando la curación a L2: paso 2
+
+Empezando la transferencia:
+
+![Enviando la curación a L2](/img/sendingCurationToL2Step2First.png)
+
+Después de iniciar la transferencia, el mensaje que envía tu curación de L1 a L2 debe propagarse a través del puente de Arbitrum. Esto toma aproximadamente 20 minutos (el puente espera a que el bloque de mainnet que contiene la transacción sea "seguro" y esté protegido de posibles reorganizaciones de la cadena).
+
+Una vez que finalice este tiempo de espera, Arbitrum intentará ejecutar automáticamente la transferencia en los contratos de L2.
+
+![Enviando la señal de curacion a L2](/img/sendingCurationToL2Step2Second.png)
+
+## Enviando curacion a L2: Paso 3
+
+En la mayoría de los casos, este paso se ejecutará automáticamente, ya que el gas de L2 incluido en el paso 1 debería ser suficiente para ejecutar la transacción que recibe la curación en los contratos de Arbitrum. Sin embargo, en algunos casos, es posible que un aumento repentino en los precios del gas en Arbitrum cause que esta ejecución automática falle. En este caso, el "ticket" que envía tu curación a L2 quedará pendiente y requerirá un reintento dentro de los 7 días.
+
+Si este es el caso, deberás conectarte utilizando una wallet de L2 que tenga algo de ETH en Arbitrum, cambiar la red de tu wallet a Arbitrum y hacer clic en "Confirmar Transferencia" para volver a intentar la transacción.
+
+![Enviar señal a L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Retirando tu curacion en L1
+
+Si prefieres no enviar tu GRT a L2, o prefieres bridgear GRT de forma manual, puedes retirar tu GRT curado en L1. En el banner en la página del subgrafo, elige "Retirar Señal" y confirma la transacción; el GRT se enviará a tu dirección de Curador.

From 878c009b7fdf5d2841c17f41655aa57c8fd5fd05 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:08 -0500
Subject: [PATCH 1047/3820] New translations l2-transfer-tools-guide.mdx
 (Arabic)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/ar/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/ar/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/ar/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..d6dc25e0d5e9
--- /dev/null
+++ b/website/pages/ar/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 Transfer Tools Guide
+---
+
+يسهل الغراف الانتقال إلى الطبقة الثانبة على أربترم. لكل مشارك في البروتوكول ، توجد مجموعة من أدوات نقل الطبقة الثانبة لجعل النقل إليها سلسًا لجميع المشاركين في الشبكة. ستطلب منك هذه الأدوات اتباع مجموعة محددة من الخطوات بناءً على ما تقوم بنقله.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## كيف تنقل الغراف الفرعي الخاص بك إلى شبكة آربترم (الطبقة الثانية)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## فوائد نقل الغراف الفرعي الخاصة بك
+
+مجتمع الغراف والمطورون الأساسيون كانوا [يستعدون] (https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) للإنتقال إلى آربترم على مدى العام الماضي. وتعتبر آربترم سلسلة كتل من الطبقة الثانية أو "L2"، حيث ترث الأمان من سلسلة الإيثيريوم ولكنها توفر رسوم غازٍ أقل بشكلٍ كبير.
+
+عندما تقوم بنشر أو ترقية الغرافات الفرعية الخاصة بك إلى شبكة الغراف، فأنت تتفاعل مع عقودٍ ذكيةٍ في البروتوكول وهذا يتطلب دفع رسوم الغاز باستخدام عملة الايثيريوم. من خلال نقل غرافاتك الفرعية إلى آربترم، فإن أي ترقيات مستقبلية لغرافك الفرعي ستتطلب رسوم غازٍ أقل بكثير. الرسوم الأقل، وكذلك حقيقة أن منحنيات الترابط التنسيقي على الطبقة الثانية مستقيمة، تجعل من الأسهل على المنسِّقين الآخرين تنسيق غرافك الفرعي، ممّا يزيد من مكافآت المفهرِسين على غرافك الفرعي. هذه البيئة ذات التكلفة-الأقل كذلك تجعل من الأرخص على المفهرسين أن يقوموا بفهرسة وخدمة غرافك الفرعي. سوف تزداد مكافآت الفهرسة على آربترم وتتناقص على شبكة إيثيريوم الرئيسية على مدى الأشهر المقبلة، لذلك سيقوم المزيد والمزيد من المُفَهرِسين بنقل ودائعهم المربوطة وتثبيت عملياتهم على الطبقة الثانية.
+
+## فهم ما يحدث مع الإشارة وغرافك الفرعي على الطبقة الأولى وعناوين مواقع الإستعلام
+
+عند نقل سبجراف إلى Arbitrum، يتم استخدام جسر Arbitrum GRT، الذي بدوره يستخدم جسر Arbitrum الأصلي، لإرسال السبجراف إلى L2. سيؤدي عملية "النقل" إلى إهمال السبجراف على شبكة الإيثيريوم الرئيسية وإرسال المعلومات لإعادة إنشاء السبجراف على L2 باستخدام الجسر. ستتضمن أيضًا رصيد GRT المرهون المرتبط بمالك السبجراف، والذي يجب أن يكون أكبر من الصفر حتى يقبل الجسر النقل.
+
+عندما تختار نقل الرسم البياني الفرعي ، سيؤدي ذلك إلى تحويل جميع إشارات التنسيق الخاصة بالرسم الفرعي إلى GRT. هذا يعادل "إهمال" الرسم البياني الفرعي على الشبكة الرئيسية. سيتم إرسال GRT المستخدمة لعملية التنسيق الخاصة بك إلى L2 جمباً إلى جمب مع الرسم البياني الفرعي ، حيث سيتم استخدامها لإنتاج الإشارة نيابة عنك.
+
+يمكن للمنسقين الآخرين اختيار ما إذا كانوا سيسحبون جزء من GRT الخاص بهم ، أو نقله أيضًا إلى L2 لصك إشارة على نفس الرسم البياني الفرعي. إذا لم يقم مالك الرسم البياني الفرعي بنقل الرسم البياني الفرعي الخاص به إلى L2 وقام بإيقافه يدويًا عبر استدعاء العقد ، فسيتم إخطار المنسقين وسيتمكنون من سحب تنسيقهم.
+
+بمجرد نقل الرسم البياني الفرعي ، لن يتلقى المفهرسون بعد الآن مكافآت لفهرسة الرسم البياني الفرعي، نظرًا لأنه يتم تحويل كل التنسيق لـ GRT. ومع ذلك ، سيكون هناك مفهرسون 1) سيستمرون في خدمة الرسوم البيانية الفرعية المنقولة لمدة 24 ساعة ، و 2) سيبدأون فورًا في فهرسة الرسم البياني الفرعي على L2. ونظرًا لأن هؤلاء المفهرسون لديهم بالفعل رسم بياني فرعي مفهرس ، فلا داعي لانتظار مزامنة الرسم البياني الفرعي ، وسيكون من الممكن الاستعلام عن الرسم البياني الفرعي على L2 مباشرة تقريبًا.
+
+يجب إجراء الاستعلامات على الرسم البياني الفرعي في L2 على عنوان URL مختلف (على \`` Arbitrum-gateway.thegraph.com`) ، لكن عنوان URL L1 سيستمر في العمل لمدة 48 ساعة على الأقل. بعد ذلك ، ستقوم بوابة L1 بإعادة توجيه الاستعلامات إلى بوابة L2 (لبعض الوقت) ، ولكن هذا سيضيف زمن تأخير لذلك يوصى تغيير جميع استعلاماتك إلى عنوان URL الجديد في أقرب وقت ممكن.
+
+## اختيار محفظة L2 الخاصة بك
+
+عندما قمت بنشر subgraph الخاص بك على الشبكة الرئيسية ، فقد استخدمت محفظة متصلة لإنشاء subgraph ، وتمتلك هذه المحفظة NFT الذي يمثل هذا subgraph ويسمح لك بنشر التحديثات.
+
+عند نقل الرسم البياني الفرعي إلى Arbitrum ، يمكنك اختيار محفظة مختلفة والتي ستمتلك هذا الـ subgraph NFT على L2.
+
+إذا كنت تستخدم محفظة "عادية" مثل MetaMask (حساب مملوك خارجيًا EOA ، محفظة ليست بعقد ذكي) ، فهذا اختياري ويوصى بالاحتفاظ بعنوان المالك نفسه كما في L1.
+
+إذا كنت تستخدم محفظة بعقد ذكي ، مثل multisig (على سبيل المثال Safe) ، فإن اختيار عنوان مختلف لمحفظة L2 أمر إلزامي ، حيث من المرجح أن هذا الحساب موجود فقط على mainnet ولن تكون قادرًا على إجراء المعاملات على Arbitrum باستخدام هذه المحفظة. إذا كنت ترغب في الاستمرار في استخدام محفظة عقد ذكية أو multisig ، فقم بإنشاء محفظة جديدة على Arbitrum واستخدم عنوانها كمالك للرسم البياني الفرعي الخاص بك على L2.
+
+** من المهم جدًا استخدام عنوان محفظة تتحكم فيه ، ويمكنه إجراء معاملات على Arbitrum. وإلا فسيتم فقد الرسم البياني الفرعي ولا يمكن استعادته. **
+
+## التحضير لعملية النقل: إنشاء جسر لـبعض ETH
+
+يتضمن نقل الغراف الفرعي إرسال معاملة عبر الجسر ، ثم تنفيذ معاملة أخرى على شبكة أربترم. تستخدم المعاملة الأولى الإيثيريوم على الشبكة الرئيسية ، وتتضمن بعضًا من إيثيريوم لدفع ثمن الغاز عند استلام الرسالة على الطبقة الثانية. ومع ذلك ، إذا كان هذا الغاز غير كافٍ ، فسيتعين عليك إعادة إجراء المعاملة ودفع ثمن الغاز مباشرةً على الطبقة الثانية (هذه هي "الخطوة 3: تأكيد التحويل" أدناه). يجب تنفيذ هذه الخطوة ** في غضون 7 أيام من بدء التحويل **. علاوة على ذلك ، سيتم إجراء المعاملة الثانية مباشرة على شبكة أربترم ("الخطوة 4: إنهاء التحويل على الطبقة الثانية"). لهذه الأسباب ، ستحتاج بعضًا من إيثيريوم في محفظة أربترم. إذا كنت تستخدم متعدد التواقيع أو عقداً ذكياً ، فيجب أن يكون هناك بعضًا من إيثيريوم في المحفظة العادية (حساب مملوك خارجيا) التي تستخدمها لتنفيذ المعاملات ، وليس على محفظة متعددة التواقيع.
+
+يمكنك شراء إيثيريوم من بعض المنصات وسحبها مباشرة إلى أربترم، أو يمكنك استخدام جسر أربترم لإرسال إيثيريوم من محفظة الشبكة الرئيسيةإلى الطبقة الثانية: [bridge.arbitrum.io] (http://bridge.arbitrum.io). نظرًا لأن رسوم الغاز على أربترم أقل ، فستحتاج فقط إلى مبلغ صغير. من المستحسن أن تبدأ بمبلغ منخفض (0 على سبيل المثال ، 01 ETH) للموافقة على معاملتك.
+
+## العثور على أداة نقل الغراف الفرعي
+
+يمكنك العثور على أداة نقل L2 في صفحة الرسم البياني الفرعي الخاص بك على Subgraph Studio:
+
+![أداة النقل](/img/L2-transfer-tool1.png)
+
+إذا كنت متصلاً بالمحفظة التي تمتلك الغراف الفرعي، فيمكنك الوصول إليها عبر المستكشف، وذلك عن طريق الانتقال إلى صفحة الغراف الفرعي على المستكشف:
+
+![Transferring to L2](/img/transferToL2.png)
+
+سيؤدي النقر فوق زر النقل إلى الطبقة الثانية إلى فتح أداة النقل حيث يمكنك بدء عملية النقل.
+
+## الخطوة 1: بدء عملية النقل
+
+قبل بدء عملية النقل، يجب أن تقرر أي عنوان سيكون مالكًا للغراف الفرعي على الطبقة الثانية (انظر "اختيار محفظة الطبقة الثانية" أعلاه)، ويُوصَى بشدة بأن يكون لديك بعضًا من الإيثيريوم لرسوم الغاز على أربترم. يمكنك الاطلاع على (التحضير لعملية النقل: تحويل بعضًا من إيثيريوم عبر الجسر." أعلاه).
+
+يرجى أيضًا ملاحظة أن نقل الرسم البياني الفرعي يتطلب وجود كمية غير صفرية من إشارة التنسيق عليه بنفس الحساب الذي يمتلك الرسم البياني الفرعي ؛ إذا لم تكن قد أشرت إلى الرسم البياني الفرعي ، فسيتعين عليك إضافة القليل من إشارة التنسيق (يكفي إضافة مبلغ صغير مثل 1 GRT).
+
+بعد فتح أداة النقل، ستتمكن من إدخال عنوان المحفظة في الطبقة الثانية في حقل "عنوان محفظة الاستلام". تأكد من إدخال العنوان الصحيح هنا. بعد ذلك، انقر على "نقل الغراف الفرعي"، وسيتم طلب تنفيذ العملية في محفظتك. (يُرجى ملاحظة أنه يتم تضمين بعضًا من الإثيريوم لدفع رسوم الغاز في الطبقة الثانية). بعد تنفيذ العملية، سيتم بدء عملية النقل وإهمال الغراف الفرعي في الطبقة الأولى. (يمكنك الاطلاع على "فهم ما يحدث مع الإشارة والغراف الفرعي في الطبقة الأولى وعناوين الاستعلام" أعلاه لمزيد من التفاصيل حول ما يحدث خلف الكواليس).
+
+إذا قمت بتنفيذ هذه الخطوة، \*\*يجب عليك التأكد من أنك ستستكمل الخطوة 3 في غضون 7 أيام، وإلا فإنك ستفقد الغراف الفرعي والإشارة GRT الخاصة بك. يرجع ذلك إلى آلية التواصل بين الطبقة الأولى والطبقة الثانية في أربترم: الرسائل التي ترسل عبر الجسر هي "تذاكر قابلة لإعادة المحاولة" يجب تنفيذها في غضون 7 أيام، وقد يتطلب التنفيذ الأولي إعادة المحاولة إذا كان هناك زيادة في سعر الغاز على أربترم.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## الخطوة 2: الانتظار حتى يتم نقل الغراف الفرعي إلى الطبقة الثانية
+
+بعد بدء عملية النقل، يتعين على الرسالة التي ترسل الـ subgraph من L1 إلى L2 أن يتم نشرها عبر جسر Arbitrum. يستغرق ذلك حوالي 20 دقيقة (ينتظر الجسر لكتلة الشبكة الرئيسية التي تحتوي على المعاملة حتى يتأكد أنها "آمنة" من إمكانية إعادة ترتيب السلسلة).
+
+بمجرد انتهاء وقت الانتظار ، ستحاول Arbitrum تنفيذ النقل تلقائيًا على عقود L2.
+
+![شاشة انتظار](/img/screenshotOfWaitScreenL2.png)
+
+## الخطوة الثالثة: تأكيد التحويل
+
+في معظم الحالات ، سيتم تنفيذ هذه الخطوة تلقائيًا لأن غاز الطبقة الثانية المضمن في الخطوة 1 يجب أن يكون كافيًا لتنفيذ المعاملة التي تتلقى الغراف الفرعي في عقود أربترم. ومع ذلك ، في بعض الحالات ، من الممكن أن يؤدي ارتفاع أسعار الغاز على أربترم إلى فشل هذا التنفيذ التلقائي. وفي هذه الحالة ، ستكون "التذكرة" التي ترسل غرافك الفرعي إلى الطبقة الثانية معلقة وتتطلب إعادة المحاولة في غضون 7 أيام.
+
+في هذا الحالة ، فستحتاج إلى الاتصال باستخدام محفظة الطبقة الثانية والتي تحتوي بعضاً من إيثيريوم على أربترم، قم بتغيير شبكة محفظتك إلى أربترم، والنقر فوق "تأكيد النقل" لإعادة محاولة المعاملة.
+
+![تأكيد النقل إلى الطبقة الثانية](/img/confirmTransferToL2.png)
+
+## الخطوة 4: إنهاء عملية النقل على L2
+
+في هذه المرحلة، تم استلام الغراف الفرعي والـ GRT الخاص بك على أربترم، ولكن الغراف الفرعي لم يتم نشره بعد. ستحتاج إلى الربط باستخدام محفظة الطبقة الثانية التي اخترتها كمحفظة استلام، وتغيير شبكة محفظتك إلى أربترم، ثم النقر على "نشر الغراف الفرعي"
+
+![نشر الغراف الفرعي](/img/publishSubgraphL2TransferTools.png)
+
+![انتظر حتى يتم نشر الغراف الفرعي](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+سيؤدي هذا إلى نشر الغراف الفرعي حتى يتمكن المفهرسون الذين يعملون في أربترم بالبدء في تقديم الخدمة. كما أنه سيعمل أيضًا على إصدار إشارة التنسيق باستخدام GRT التي تم نقلها من الطبقة الأولى.
+
+## Step 5: Updating the query URL
+
+تم نقل غرافك الفرعي بنجاح إلى أربترم! للاستعلام عن الغراف الفرعي ، سيكون عنوان URL الجديد هو:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+لاحظ أن ID الغراف الفرعي على أربترم سيكون مختلفًا عن الذي لديك في الشبكة الرئيسية، ولكن يمكنك العثور عليه في المستكشف أو استوديو. كما هو مذكور أعلاه (راجع "فهم ما يحدث للإشارة والغراف الفرعي في الطبقة الأولى وعناوين الاستعلام") سيتم دعم عنوان URL الطبقة الأولى القديم لفترة قصيرة ، ولكن يجب عليك تبديل استعلاماتك إلى العنوان الجديد بمجرد مزامنة الغراف الفرعي على الطبقة الثانية.
+
+## كيفية نقل التنسيق الخاص بك إلى أربترم (الطبقة الثانية)
+
+## Understanding what happens to curation on subgraph transfers to L2
+
+When the owner of a subgraph transfers a subgraph to Arbitrum, all of the subgraph's signal is converted to GRT at the same time. This applies to "auto-migrated" signal, i.e. signal that is not specific to a subgraph version or deployment but that follows the latest version of a subgraph.
+
+This conversion from signal to GRT is the same as what would happen if the subgraph owner deprecated the subgraph in L1. When the subgraph is deprecated or transferred, all curation signal is "burned" simultaneously (using the curation bonding curve) and the resulting GRT is held by the GNS smart contract (that is the contract that handles subgraph upgrades and auto-migrated signal). Each Curator on that subgraph therefore has a claim to that GRT proportional to the amount of shares they had for the subgraph.
+
+A fraction of these GRT corresponding to the subgraph owner is sent to L2 together with the subgraph.
+
+At this point, the curated GRT will not accrue any more query fees, so Curators can choose to withdraw their GRT or transfer it to the same subgraph on L2, where it can be used to mint new curation signal. There is no rush to do this as the GRT can be help indefinitely and everybody gets an amount proportional to their shares, irrespective of when they do it.
+
+## اختيار محفظة L2 الخاصة بك
+
+If you decide to transfer your curated GRT to L2, you can choose a different wallet that will own the curation signal on L2.
+
+If you're using a "regular" wallet like Metamask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same Curator address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 receiving wallet address.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum, as otherwise the curation will be lost and cannot be recovered.**
+
+## Sending curation to L2: Step 1
+
+Before starting the transfer, you must decide which address will own the curation on L2 (see "Choosing your L2 wallet" above), and it is recommended having some ETH for gas already bridged on Arbitrum in case you need to retry the execution of the message on L2. You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - since gas fees on Arbitrum are so low, you should only need a small amount, e.g. 0.01 ETH will probably be more than enough.
+
+If a subgraph that you curate to has been transferred to L2, you will see a message on Explorer telling you that you're curating to a transferred subgraph.
+
+When looking at the subgraph page, you can choose to withdraw or transfer the curation. Clicking on "Transfer Signal to Arbitrum" will open the transfer tool.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+After opening the Transfer Tool, you may be prompted to add some ETH to your wallet if you don't have any. Then you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Signal will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer.
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retryable tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+## Sending curation to L2: step 2
+
+Starting the transfer:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+After you start the transfer, the message that sends your L1 curation to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+بمجرد انتهاء وقت الانتظار ، ستحاول Arbitrum تنفيذ النقل تلقائيًا على عقود L2.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Sending curation to L2: step 3
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the curation on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your curation to L2 will be pending and require a retry within 7 days.
+
+في هذا الحالة ، فستحتاج إلى الاتصال باستخدام محفظة الطبقة الثانية والتي تحتوي بعضاً من إيثيريوم على أربترم، قم بتغيير شبكة محفظتك إلى أربترم، والنقر فوق "تأكيد النقل" لإعادة محاولة المعاملة.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Withdrawing your curation on L1
+
+If you prefer not to send your GRT to L2, or you'd rather bridge the GRT manually, you can withdraw your curated GRT on L1. On the banner on the subgraph page, choose "Withdraw Signal" and confirm the transaction; the GRT will be sent to your Curator address.

From 346d7b46dc0dd538c8a3e458d6432c0ca70eb8f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:10 -0500
Subject: [PATCH 1048/3820] New translations l2-transfer-tools-guide.mdx
 (Czech)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/cs/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/cs/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/cs/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..4b3c747dc08e
--- /dev/null
+++ b/website/pages/cs/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: Průvodce nástroji pro přenos L2
+---
+
+Graph usnadnil přechod na úroveň L2 v Arbitrum One. Pro každého účastníka protokolu je k dispozici sada nástrojů pro přechod na L2, které umožňují bezproblémový přechod na L2 pro všechny účastníky sítě. Tyto nástroje vyžadují provedení určitého souboru kroků v závislosti na tom, co přenášíte.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## Jak přenést podgraf do Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Výhody přenosu podgrafů
+
+Komunita a hlavní vývojáři Graphu se v uplynulém roce [připravovali](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) na přechod na Arbitrum. Arbitrum, blockchain druhé vrstvy neboli "L2", zdědil bezpečnost po Ethereum, ale poskytuje výrazně nižší poplatky za plyn.
+
+Když publikujete nebo aktualizujete svůj subgraf v síti The Graph Network, komunikujete s chytrými smlouvami na protokolu, což vyžaduje platbu za plyn pomocí ETH. Přesunutím subgrafů do Arbitrum budou veškeré budoucí aktualizace subgrafů vyžadovat mnohem nižší poplatky za plyn. Nižší poplatky a skutečnost, že křivky vazby kurátorů na L2 jsou ploché, také usnadňují ostatním kurátorům kurátorství na vašem podgrafu, což zvyšuje odměny pro indexátory na vašem podgrafu. Toto prostředí s nižšími náklady také zlevňuje indexování a obsluhu subgrafu pro indexátory. Odměny za indexování se budou v následujících měsících na Arbitrum zvyšovat a na mainnetu Ethereum snižovat, takže stále více indexerů bude převádět své podíly a zakládat své operace na L2.
+
+## Porozumění tomu, co se děje se signálem, podgrafem L1 a adresami URL dotazů
+
+Při přenosu podgrafu do Arbitrum se používá můstek Arbitrum GRT, který zase používá nativní můstek Arbitrum k odeslání podgrafu do L2. Při "přenosu" se subgraf v mainnetu znehodnotí a odešlou se informace pro opětovné vytvoření subgrafu v L2 pomocí mostu. Zahrnuje také GRT vlastníka podgrafu, který již byl signalizován a který musí být větší než nula, aby most převod přijal.
+
+Pokud zvolíte převod podgrafu, převede se veškerý signál kurátoru podgrafu na GRT. To je ekvivalentní "znehodnocení" podgrafu v síti mainnet. GRT odpovídající vašemu kurátorství budou spolu s podgrafem odeslány na L2, kde budou vaším jménem použity k ražbě signálu.
+
+Ostatní kurátoři se mohou rozhodnout, zda si stáhnou svůj podíl GRT, nebo jej také převedou na L2, aby na stejném podgrafu vyrazili signál. Pokud vlastník podgrafu nepřevede svůj podgraf na L2 a ručně jej znehodnotí prostřednictvím volání smlouvy, pak budou Kurátoři upozorněni a budou moci stáhnout svou kurátorskou funkci.
+
+Jakmile je podgraf převeden, protože veškerá kurátorská činnost je převedena na GRT, indexátoři již nebudou dostávat odměny za indexování podgrafu. Budou však existovat indexátory, které 1) budou obsluhovat převedené podgrafy po dobu 24 hodin a 2) okamžitě začnou indexovat podgraf na L2. Protože tyto Indexery již mají podgraf zaindexovaný, nemělo by být nutné čekat na synchronizaci podgrafu a bude možné se na podgraf na L2 dotazovat téměř okamžitě.
+
+Dotazy do podgrafu L2 bude nutné zadávat na jinou adresu URL (na `arbitrum-gateway.thegraph.com`), ale adresa URL L1 bude fungovat nejméně 48 hodin. Poté bude brána L1 přeposílat dotazy na bránu L2 (po určitou dobu), což však zvýší latenci, takže se doporučuje co nejdříve přepnout všechny dotazy na novou adresu URL.
+
+## Výběr peněženky L2
+
+Když jste publikovali svůj podgraf na hlavní síti (mainnet), použili jste připojenou peněženku, která vlastní NFT reprezentující tento podgraf a umožňuje vám publikovat aktualizace.
+
+Při přenosu podgrafu do Arbitrum si můžete vybrat jinou peněženku, která bude vlastnit tento podgraf NFT na L2.
+
+Pokud používáte "obyčejnou" peněženku, jako je MetaMask (externě vlastněný účet nebo EOA, tj. peněženka, která není chytrým kontraktem), pak je to volitelné a doporučuje se zachovat stejnou adresu vlastníka jako v L1.
+
+Pokud používáte peněženku s chytrým kontraktem, jako je multisig (např. Trezor), pak je nutné zvolit jinou adresu peněženky L2, protože je pravděpodobné, že tento účet existuje pouze v mainnetu a nebudete moci provádět transakce na Arbitrum pomocí této peněženky. Pokud chcete i nadále používat peněženku s chytrým kontraktem nebo multisig, vytvořte si na Arbitrum novou peněženku a její adresu použijte jako vlastníka L2 svého subgrafu.
+
+**Je velmi důležité používat adresu peněženky, kterou máte pod kontrolou a která může provádět transakce na Arbitrum. V opačném případě bude podgraf ztracen a nebude možné jej obnovit.**
+
+## Příprava na převod: přemostění některých ETH
+
+Přenos podgrafu zahrnuje odeslání transakce přes můstek a následné provedení další transakce na Arbitrum. První transakce využívá ETH na mainnetu a obsahuje nějaké ETH na zaplacení plynu, když je zpráva přijata na L2. Pokud však tento plyn nestačí, je třeba transakci zopakovat a zaplatit za plyn přímo na L2 (to je 'Krok 3: Potvrzení převodu' níže). Tento krok musí být proveden do 7 dnů od zahájení převodu\*\*. Druhá transakce ('Krok 4: Dokončení převodu na L2') bude navíc provedena přímo na Arbitrum. Z těchto důvodů budete potřebovat nějaké ETH na peněžence Arbitrum. Pokud používáte multisig nebo smart contract účet, ETH bude muset být v běžné peněžence (EOA), kterou používáte k provádění transakcí, nikoli na samotné multisig peněžence.
+
+ETH si můžete koupit na některých burzách a vybrat přímo na Arbitrum, nebo můžete použít most Arbitrum a poslat ETH z peněženky mainnetu na L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Vzhledem k tomu, že poplatky za plyn na Arbitrum jsou nižší, mělo by vám stačit jen malé množství. Doporučujeme začít na nízkém prahu (např. 0.01 ETH), aby byla vaše transakce schválena.
+
+## Hledání nástroje pro přenos podgrafu
+
+Nástroj pro přenos L2 najdete při prohlížení stránky svého podgrafu v aplikaci Subgraph Studio:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+Je k dispozici také v Průzkumníku, pokud jste připojeni k peněžence, která vlastní podgraf, a na stránce tohoto podgrafu v Průzkumníku:
+
+![Transferring to L2](/img/transferToL2.png)
+
+Kliknutím na tlačítko Přenést na L2 otevřete nástroj pro přenos, kde můžete zahájit proces přenosu.
+
+## Krok 1: Zahájení přenosu
+
+Před zahájením převodu se musíte rozhodnout, která adresa bude vlastnit podgraf na L2 (viz výše "Výběr peněženky L2"), a důrazně doporučujeme mít na Arbitrum již přemostěné ETH pro plyn (viz výše "Příprava na převod: přemostění některých ETH").
+
+Vezměte prosím na vědomí, že přenos podgrafu vyžaduje nenulové množství signálu na podgrafu se stejným účtem, který vlastní podgraf; pokud jste na podgrafu nesignalizovali, budete muset přidat trochu kurátorství (stačí přidat malé množství, například 1 GRT).
+
+Po otevření nástroje Transfer Tool budete moci do pole "Receiving wallet address" zadat adresu peněženky L2 - **ujistěte se, že jste zadali správnou adresu**. Kliknutím na Transfer Subgraph budete vyzváni k provedení transakce na vaší peněžence (všimněte si, že je zahrnuta určitá hodnota ETH, abyste zaplatili za plyn L2); tím se zahájí přenos a znehodnotí váš subgraf L1 (více podrobností o tom, co se děje v zákulisí, najdete výše v části "Porozumění tomu, co se děje se signálem, vaším subgrafem L1 a URL dotazů").
+
+Pokud tento krok provedete, ujistěte se, že jste pokračovali až do dokončení kroku 3 za méně než 7 dní, jinak se podgraf a váš signál GRT ztratí. To je způsobeno tím, jak funguje zasílání zpráv L1-L2 na Arbitrum: zprávy, které jsou zasílány přes most, jsou "Opakovatelný tiket", které musí být provedeny do 7 dní, a počáteční provedení může vyžadovat opakování, pokud dojde ke skokům v ceně plynu na Arbitrum.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Krok 2: Čekání, až se podgraf dostane do L2
+
+Po zahájení přenosu se musí zpráva, která odesílá podgraf L1 do L2, šířit přes můstek Arbitrum. To trvá přibližně 20 minut (můstek čeká, až bude blok mainnetu obsahující transakci "bezpečný" před případnými reorgy řetězce).
+
+Po uplynutí této čekací doby se Arbitrum pokusí o automatické provedení přenosu na základě smluv L2.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## Krok 3: Potvrzení převodu
+
+Ve většině případů se tento krok provede automaticky, protože plyn L2 obsažený v kroku 1 by měl stačit k provedení transakce, která přijímá podgraf na smlouvách Arbitrum. V některých případech je však možné, že prudký nárůst cen plynu na Arbitrum způsobí selhání tohoto automatického provedení. V takovém případě bude "ticket", který odešle subgraf na L2, čekat na vyřízení a bude vyžadovat opakování pokusu do 7 dnů.
+
+V takovém případě se musíte připojit pomocí peněženky L2, která má nějaké ETH na Arbitrum, přepnout síť peněženky na Arbitrum a kliknutím na "Confirm Transfer" zopakovat transakci.
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## Krok 4: Dokončení přenosu na L2
+
+V tuto chvíli byly váš podgraf a GRT přijaty na Arbitrum, ale podgraf ještě není zveřejněn. Budete se muset připojit pomocí peněženky L2, kterou jste si vybrali jako přijímající peněženku, přepnout síť peněženky na Arbitrum a kliknout na "Publikovat subgraf"
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+Tím se podgraf zveřejní, aby jej mohly začít obsluhovat indexery pracující na Arbitrum. Rovněž bude zminován kurátorský signál pomocí GRT, které byly přeneseny z L1.
+
+## Krok 5: Aktualizace URL dotazu
+
+Váš podgraf byl úspěšně přenesen do Arbitrum! Chcete-li se na podgraf zeptat, nová URL bude:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Všimněte si, že ID podgrafu v Arbitrum bude jiné než to, které jste měli v mainnetu, ale vždy ho můžete najít v Průzkumníku nebo Studiu. Jak je uvedeno výše (viz "Pochopení toho, co se děje se signálem, vaším subgrafem L1 a URL dotazů"), stará URL adresa L1 bude po krátkou dobu podporována, ale jakmile bude subgraf synchronizován na L2, měli byste své dotazy přepnout na novou adresu.
+
+## Jak přenést kurátorství do služby Arbitrum (L2)
+
+## Porozumění tomu, co se děje s kurátorstvím při přenosu podgrafů do L2
+
+Když vlastník podgrafu převede podgraf do Arbitrum, je veškerý signál podgrafu současně převeden na GRT. To se týká "automaticky migrovaného" signálu, tj. signálu, který není specifický pro verzi podgrafu nebo nasazení, ale který následuje nejnovější verzi podgrafu.
+
+Tento převod ze signálu na GRT je stejný, jako kdyby vlastník podgrafu zrušil podgraf v L1. Při depreciaci nebo převodu subgrafu se současně "spálí" veškerý kurátorský signál (pomocí kurátorské vazební křivky) a výsledný GRT je držen inteligentním kontraktem GNS (tedy kontraktem, který se stará o upgrade subgrafu a automatickou migraci signálu). Každý kurátor na tomto subgrafu má tedy nárok na tento GRT úměrný množství podílů, které měl na subgrafu.
+
+Část těchto GRT odpovídající vlastníkovi podgrafu je odeslána do L2 spolu s podgrafem.
+
+V tomto okamžiku se za kurátorský GRT již nebudou účtovat žádné poplatky za dotazování, takže kurátoři se mohou rozhodnout, zda svůj GRT stáhnou, nebo jej přenesou do stejného podgrafu na L2, kde může být použit k ražbě nového kurátorského signálu. S tímto úkonem není třeba spěchat, protože GRT lze pomáhat donekonečna a každý dostane částku úměrnou svému podílu bez ohledu na to, kdy tak učiní.
+
+## Výběr peněženky L2
+
+Pokud se rozhodnete převést své kurátorované GRT na L2, můžete si vybrat jinou peněženku, která bude vlastnit kurátorský signál na L2.
+
+Pokud používáte "obyčejnou" peněženku, jako je Metamask (externě vlastněný účet nebo EOA, tj. peněženka, která není chytrým kontraktem), pak je to volitelné a doporučuje se zachovat stejnou adresu kurátora jako v L1.
+
+Pokud používáte peněženku s chytrým kontraktem, jako je multisig (např. Trezor), pak je nutné zvolit jinou adresu peněženky L2, protože je pravděpodobné, že tento účet existuje pouze v mainnetu a nebudete moci provádět transakce na Arbitrum pomocí této peněženky. Pokud chcete i nadále používat peněženku s inteligentním kontraktem nebo multisig, vytvořte si na Arbitrum novou peněženku a její adresu použijte jako adresu přijímací peněženky L2.
+
+**Je velmi důležité používat adresu peněženky, kterou máte pod kontrolou a která může provádět transakce na Arbitrum, protože jinak bude kurátorství ztraceno a nebude možné jej obnovit.**
+
+## Odeslání kurátorství do L2: Krok 1
+
+Před zahájením převodu se musíte rozhodnout, která adresa bude vlastnit kurátorství na L2 (viz výše "Výběr peněženky L2"), a doporučujeme mít nějaké ETH pro plyn již přemostěné na Arbitrum pro případ, že byste potřebovali zopakovat provedení zprávy na L2. ETH můžete nakoupit na některých burzách a vybrat si ho přímo na Arbitrum, nebo můžete použít Arbitrum bridge pro odeslání ETH z peněženky mainnetu na L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - protože poplatky za plyn na Arbitrum jsou tak nízké, mělo by vám stačit jen malé množství, např. 0,01 ETH bude pravděpodobně více než dostačující.
+
+Pokud byl podgraf, do kterého kurátor provádí kurátorství, převeden do L2, zobrazí se v Průzkumníku zpráva, že kurátorství provádíte do převedeného podgrafu.
+
+Při pohledu na stránku podgrafu můžete zvolit stažení nebo přenos kurátorství. Kliknutím na "Přenést signál do Arbitrum" otevřete nástroj pro přenos.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+Po otevření nástroje Transfer Tool můžete být vyzváni k přidání ETH do peněženky, pokud žádné nemáte. Poté budete moci zadat adresu peněženky L2 do pole "Receiving wallet address" - **ujistěte se, že jste zde zadali správnou adresu**. Kliknutím na tlačítko Transfer Signal (Přenést signál) budete vyzváni k provedení transakce na vaší peněžence (všimněte si, že je zahrnuta určitá hodnota ETH pro zaplacení plynu L2); tím bude zahájen převod.
+
+Pokud tento krok provedete, **ujistěte se, že jste pokračovali až do dokončení kroku 3 za méně než 7 dní, jinak bude váš signál GRT ztracen.** To je způsobeno tím, jak funguje zasílání zpráv L1-L2 na Arbitrum: zprávy, které jsou zasílány přes most, jsou "opakovatelné tikety", které musí být provedeny do 7 dní, a počáteční provedení může vyžadovat opakování, pokud dojde ke skokům v ceně plynu na Arbitrum.
+
+## Odeslání kurátorství do L2: krok 2
+
+Zahájení přenosu:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+Po spuštění přenosu se musí zpráva, která odešle vaše kurátorství L1 do L2, šířit přes můstek Arbitrum. To trvá přibližně 20 minut (můstek čeká, až bude blok mainnetu obsahující transakci "bezpečný" před případnými reorgy řetězce).
+
+Po uplynutí této čekací doby se Arbitrum pokusí o automatické provedení přenosu na základě smluv L2.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Odeslání kurátorství do L2: krok 3
+
+Ve většině případů se tento krok provede automaticky, protože plyn L2 obsažený v kroku 1 by měl stačit k provedení transakce, která obdrží kurátorství na smlouvách Arbitrum. V některých případech je však možné, že prudký nárůst cen plynu na Arbitrum způsobí selhání tohoto automatického provedení. V takovém případě bude "ticket", který odešle vaši kurátorskou transakci na L2, čekat na vyřízení a bude vyžadovat opakování pokusu do 7 dnů.
+
+V takovém případě se musíte připojit pomocí peněženky L2, která má nějaké ETH na Arbitrum, přepnout síť peněženky na Arbitrum a kliknutím na "Confirm Transfer" zopakovat transakci.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Odstranění vašeho kurátorství na L1
+
+Pokud nechcete posílat GRT na L2 nebo byste raději překlenuli GRT ručně, můžete si na L1 stáhnout svůj kurátorovaný GRT. Na banneru na stránce podgrafu zvolte "Withdraw Signal" a potvrďte transakci; GRT bude odeslán na vaši adresu kurátora.

From 242b2a17d67ea4bdca4f9323869441144ed83cc8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:11 -0500
Subject: [PATCH 1049/3820] New translations l2-transfer-tools-guide.mdx
 (German)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/de/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/de/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/de/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..9df828a8b1fa
--- /dev/null
+++ b/website/pages/de/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 Transfer Tools Guide
+---
+
+The Graph hat den Wechsel zu L2 auf Arbitrum One leicht gemacht. Für jeden Protokollteilnehmer gibt es eine Reihe von L2-Transfer-Tools, um den Transfer zu L2 für alle Netzwerkteilnehmer nahtlos zu gestalten. Je nachdem, was Sie übertragen möchten, müssen Sie eine bestimmte Anzahl von Schritten befolgen.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## So übertragen Sie Ihren Untergraphen auf Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Vorteile der Übertragung Ihrer Untergraphen
+
+The Graph's Community und die Kernentwickler haben im letzten Jahr den Wechsel zu Arbitrum [vorbereitet] (https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305). Arbitrum, eine Layer-2- oder "L2"-Blockchain, erbt die Sicherheit von Ethereum, bietet aber drastisch niedrigere Gasgebühren.
+
+Wenn Sie Ihren Subgraphen auf The Graph Network veröffentlichen oder aktualisieren, interagieren Sie mit intelligenten Verträgen auf dem Protokoll, und dies erfordert die Bezahlung von Gas mit ETH. Indem Sie Ihre Subgraphen zu Arbitrum verschieben, werden alle zukünftigen Aktualisierungen Ihres Subgraphen viel niedrigere Gasgebühren erfordern. Die niedrigeren Gebühren und die Tatsache, dass die Kurationsbindungskurven auf L2 flach sind, machen es auch für andere Kuratoren einfacher, auf Ihrem Subgraphen zu kuratieren, was die Belohnungen für Indexer auf Ihrem Subgraphen erhöht. Diese kostengünstigere Umgebung macht es auch für Indexer preiswerter, Ihren Subgraphen zu indizieren und zu bedienen. Die Belohnungen für die Indexierung werden in den kommenden Monaten auf Arbitrum steigen und auf dem Ethereum-Mainnet sinken, so dass immer mehr Indexer ihren Einsatz transferieren und ihre Operationen auf L2 einrichten werden.
+
+## Verstehen, was mit dem Signal, Ihrem L1-Subgraphen und den Abfrage-URLs geschieht
+
+Die Übertragung eines Subgraphen nach Arbitrum verwendet die Arbitrum GRT-Brücke, die wiederum die native Arbitrum-Brücke verwendet, um den Subgraphen nach L2 zu senden. Der "Transfer" löscht den Subgraphen im Mainnet und sendet die Informationen, um den Subgraphen auf L2 mit Hilfe der Brücke neu zu erstellen. Sie enthält auch die vom Eigentümer des Subgraphen signalisierte GRT, die größer als Null sein muss, damit die Brücke die Übertragung akzeptiert.
+
+Wenn Sie sich für die Übertragung des Untergraphen entscheiden, wird das gesamte Kurationssignal des Untergraphen in GRT umgewandelt. Dies ist gleichbedeutend mit dem "Verwerfen" des Subgraphen im Mainnet. Die GRT, die Ihrer Kuration entsprechen, werden zusammen mit dem Subgraphen an L2 gesendet, wo sie für die Prägung von Signalen in Ihrem Namen verwendet werden.
+
+Andere Kuratoren können wählen, ob sie ihren Anteil an GRT zurückziehen oder ihn ebenfalls an L2 übertragen, um das Signal auf demselben Untergraphen zu prägen. Wenn ein Subgraph-Eigentümer seinen Subgraph nicht an L2 überträgt und ihn manuell über einen Vertragsaufruf abmeldet, werden die Kuratoren benachrichtigt und können ihre Kuration zurückziehen.
+
+Sobald der Subgraph übertragen wurde, erhalten die Indexer keine Belohnungen mehr für die Indizierung des Subgraphen, da die gesamte Kuration in GRT umgewandelt wird. Es wird jedoch Indexer geben, die 1) übertragene Untergraphen für 24 Stunden weiter bedienen und 2) sofort mit der Indizierung des Untergraphen auf L2 beginnen. Da diese Indexer den Untergraphen bereits indiziert haben, sollte es nicht nötig sein, auf die Synchronisierung des Untergraphen zu warten, und es wird möglich sein, den L2-Untergraphen fast sofort abzufragen.
+
+Anfragen an den L2-Subgraphen müssen an eine andere URL gerichtet werden (an `arbitrum-gateway.thegraph.com`), aber die L1-URL wird noch mindestens 48 Stunden lang funktionieren. Danach wird das L1-Gateway (für eine gewisse Zeit) Anfragen an das L2-Gateway weiterleiten, was jedoch zu zusätzlichen Latenzzeiten führt. Es wird daher empfohlen, alle Anfragen so bald wie möglich auf die neue URL umzustellen.
+
+## Ein Teil dieser GRT, der dem Inhaber des Untergraphen entspricht, wird zusammen mit dem Untergraphen an L2 gesendet.
+
+Als Sie Ihren Subgraphen im Mainnet veröffentlicht haben, haben Sie eine angeschlossene Wallet benutzt, um den Subgraphen zu erstellen, und diese Wallet besitzt die NFT, die diesen Subgraphen repräsentiert und Ihnen erlaubt, Updates zu veröffentlichen.
+
+Wenn man den Subgraphen zu Arbitrum überträgt, kann man eine andere Wallet wählen, die diesen Subgraphen NFT auf L2 besitzen wird.
+
+Wenn Sie eine "normale" Wallet wie MetaMask verwenden (ein Externally Owned Account oder EOA, d.h. eine Wallet, die kein Smart Contract ist), dann ist dies optional und es wird empfohlen, die gleiche Eigentümeradresse wie in L1 beizubehalten.
+
+Wenn Sie eine Smart-Contract-Wallet, wie z.B. eine Multisig (z.B. Safe), verwenden, dann ist die Wahl einer anderen L2-Wallet-Adresse zwingend erforderlich, da es sehr wahrscheinlich ist, dass dieses Konto nur im Mainnet existiert und Sie mit dieser Wallet keine Transaktionen auf Arbitrum durchführen können. Wenn Sie weiterhin eine Smart Contract Wallet oder Multisig verwenden möchten, erstellen Sie eine neue Wallet auf Arbitrum und verwenden Sie deren Adresse als L2-Besitzer Ihres Subgraphen.
+
+**Es ist sehr wichtig, eine Wallet-Adresse zu verwenden, die Sie kontrollieren und die Transaktionen auf Arbitrum durchführen kann. Andernfalls geht der Subgraph verloren und kann nicht wiederhergestellt werden.**
+
+## Vorbereitung der Übertragung: Überbrückung einiger ETH
+
+Die Übertragung des Subgraphen beinhaltet das Senden einer Transaktion über die Brücke und das Ausführen einer weiteren Transaktion auf Arbitrum. Die erste Transaktion verwendet ETH im Mainnet und enthält einige ETH, um das Gas zu bezahlen, wenn die Nachricht auf L2 empfangen wird. Wenn dieses Gas jedoch nicht ausreicht, müssen Sie die Transaktion wiederholen und das Gas direkt auf L2 bezahlen (dies ist "Schritt 3: Bestätigen des Transfers" unten). Dieser Schritt **muss innerhalb von 7 Tagen nach Beginn der Überweisung** ausgeführt werden. Außerdem wird die zweite Transaktion ("Schritt 4: Beenden der Übertragung auf L2") direkt auf Arbitrum durchgeführt. Aus diesen Gründen benötigen Sie etwas ETH auf einer Arbitrum-Wallet. Wenn Sie ein Multisig- oder Smart-Contract-Konto verwenden, muss sich die ETH in der regulären (EOA-) Wallet befinden, die Sie zum Ausführen der Transaktionen verwenden, nicht in der Multisig-Wallet selbst.
+
+Sie können ETH auf einigen Börsen kaufen und direkt auf Arbitrum abheben, oder Sie können die Arbitrum-Brücke verwenden, um ETH von einer Mainnet-Wallet zu L2 zu senden: [bridge.arbitrum.io](http://bridge.arbitrum.io). Da die Gasgebühren auf Arbitrum niedriger sind, sollten Sie nur eine kleine Menge benötigen. Es wird empfohlen, mit einem niedrigen Schwellenwert (z.B. 0,01 ETH) zu beginnen, damit Ihre Transaktion genehmigt wird.
+
+## Suche nach dem Untergraphen Transfer Tool
+
+Sie finden das L2 Transfer Tool, wenn Sie die Seite Ihres Subgraphen in Subgraph Studio ansehen:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+Sie ist auch im Explorer verfügbar, wenn Sie mit der Wallet verbunden sind, die einen Untergraphen besitzt, und auf der Seite dieses Untergraphen im Explorer:
+
+![Transferring to L2](/img/transferToL2.png)
+
+Wenn Sie auf die Schaltfläche auf L2 übertragen klicken, wird das Übertragungstool geöffnet, mit dem Sie den Übertragungsvorgang starten können.
+
+## Schritt 1: Starten der Übertragung
+
+Bevor Sie mit dem Transfer beginnen, müssen Sie entscheiden, welche Adresse den Subgraphen auf L2 besitzen wird (siehe "Wählen Sie Ihre L2-Wallet" oben), und es wird dringend empfohlen, einige ETH für Gas bereits auf Arbitrum zu überbrücken (siehe "Vorbereitung des Transfers: Überbrücken einiger ETH" oben).
+
+Bitte beachten Sie auch, dass die Übertragung des Untergraphen ein Signal ungleich Null auf dem Untergraphen mit demselben Konto erfordert, das den Untergraphen besitzt; wenn Sie kein Signal auf dem Untergraphen haben, müssen Sie ein wenig Kuration hinzufügen (das Hinzufügen eines kleinen Betrags wie 1 GRT würde ausreichen).
+
+Nachdem Sie das Transfer-Tool geöffnet haben, können Sie die L2-Wallet-Adresse in das Feld "Empfänger-Wallet-Adresse" eingeben - **vergewissern Sie sich, dass Sie hier die richtige Adresse eingegeben haben**. Wenn Sie auf "Transfer Subgraph" klicken, werden Sie aufgefordert, die Transaktion auf Ihrer Wallet auszuführen (beachten Sie, dass ein gewisser ETH-Wert enthalten ist, um das L2-Gas zu bezahlen); dadurch wird der Transfer eingeleitet und Ihr L1-Subgraph außer Kraft gesetzt (siehe "Verstehen, was mit Signal, Ihrem L1-Subgraph und Abfrage-URLs passiert" weiter oben für weitere Details darüber, was hinter den Kulissen passiert).
+
+Wenn Sie diesen Schritt ausführen, **vergewissern Sie sich, dass Sie bis zum Abschluss von Schritt 3 in weniger als 7 Tagen fortfahren, sonst gehen der Subgraph und Ihr Signal GRT verloren.** Dies liegt daran, wie L1-L2-Nachrichten auf Arbitrum funktionieren: Nachrichten, die über die Brücke gesendet werden, sind "wiederholbare Tickets", die innerhalb von 7 Tagen ausgeführt werden müssen, und die erste Ausführung muss möglicherweise wiederholt werden, wenn es Spitzen im Gaspreis auf Arbitrum gibt.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Schritt 2: Warten, bis der Untergraph L2 erreicht hat
+
+Nachdem Sie die Übertragung gestartet haben, muss die Nachricht, die Ihren L1-Subgraphen an L2 sendet, die Arbitrum-Brücke durchlaufen. Dies dauert etwa 20 Minuten (die Brücke wartet darauf, dass der Mainnet-Block, der die Transaktion enthält, vor potenziellen Reorgs der Kette "sicher" ist).
+
+Sobald diese Wartezeit abgelaufen ist, versucht Arbitrum, die Übertragung auf den L2-Verträgen automatisch auszuführen.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## Schritt 3: Bestätigung der Übertragung
+
+In den meisten Fällen wird dieser Schritt automatisch ausgeführt, da das in Schritt 1 enthaltene L2-Gas ausreichen sollte, um die Transaktion auszuführen, die den Untergraphen auf den Arbitrum-Verträgen erhält. In einigen Fällen ist es jedoch möglich, dass ein Anstieg der Gaspreise auf Arbitrum dazu führt, dass diese automatische Ausführung fehlschlägt. In diesem Fall wird das "Ticket", das Ihren Subgraphen an L2 sendet, ausstehend sein und einen erneuten Versuch innerhalb von 7 Tagen erfordern.
+
+Wenn dies der Fall ist, müssen Sie sich mit einer L2-Wallet verbinden, die etwas ETH auf Arbitrum hat, Ihr Wallet-Netzwerk auf Arbitrum umstellen und auf "Confirm Transfer" klicken, um die Transaktion zu wiederholen.
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## Schritt 4: Abschluss der Übertragung auf L2
+
+Zu diesem Zeitpunkt wurden Ihr Subgraph und GRT auf Arbitrum empfangen, aber der Subgraph ist noch nicht veröffentlicht. Sie müssen sich mit der L2-Wallet verbinden, die Sie als empfangende Wallet gewählt haben, Ihr Wallet-Netzwerk auf Arbitrum umstellen und auf "Subgraph" veröffentlichen klicken.
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+Dadurch wird der Untergraph veröffentlicht, so dass Indexer, die auf Arbitrum arbeiten, damit beginnen können, ihn zu bedienen. Es wird auch ein Kurationssignal unter Verwendung der GRT, die von L1 übertragen wurden, eingeleitet.
+
+## Schritt 5: Aktualisierung der Abfrage-URL
+
+Ihr Subgraph wurde erfolgreich zu Arbitrum übertragen! Um den Subgraphen abzufragen, wird die neue URL lauten:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Beachten Sie, dass die ID des Subgraphen auf Arbitrum eine andere sein wird als die, die Sie im Mainnet hatten, aber Sie können sie immer im Explorer oder Studio finden. Wie oben erwähnt (siehe "Verstehen, was mit Signal, Ihrem L1-Subgraphen und Abfrage-URLs passiert"), wird die alte L1-URL noch eine kurze Zeit lang unterstützt, aber Sie sollten Ihre Abfragen auf die neue Adresse umstellen, sobald der Subgraph auf L2 synchronisiert worden ist.
+
+## Wie Sie Ihre Kuration auf Arbitrum übertragen (L2)
+
+## Verstehen, was mit der Kuration bei der Übertragung von Untergraphen auf L2 geschieht
+
+Wenn der Eigentümer eines Untergraphen einen Untergraphen an Arbitrum überträgt, werden alle Signale des Untergraphen gleichzeitig in GRT konvertiert. Dies gilt für "automatisch migrierte" Signale, d.h. Signale, die nicht spezifisch für eine Subgraphenversion oder einen Einsatz sind, sondern der neuesten Version eines Subgraphen folgen.
+
+Diese Umwandlung von Signal in GRT entspricht dem, was passieren würde, wenn der Eigentümer des Subgraphen den Subgraphen in L1 verwerfen würde. Wenn der Subgraph veraltet oder übertragen wird, werden alle Kurationssignale gleichzeitig "verbrannt" (unter Verwendung der Kurationsbindungskurve) und das resultierende GRT wird vom GNS-Smart-Contract gehalten (das ist der Vertrag, der Subgraph-Upgrades und automatisch migrierte Signale handhabt). Jeder Kurator auf diesem Subgraphen hat daher einen Anspruch auf dieses GRT proportional zu der Menge an Anteilen, die er für den Subgraphen hatte.
+
+Ein Teil dieser GRT, der dem Eigentümer des Untergraphen entspricht, wird zusammen mit dem Untergraphen an L2 gesendet.
+
+Ein Teil dieser GRT, der dem Eigentümer des Untergraphen entspricht, wird zusammen mit dem Untergraphen an L2 gesendet.
+
+## Ein Teil dieser GRT, der dem Inhaber des Untergraphen entspricht, wird zusammen mit dem Untergraphen an L2 gesendet.
+
+Ein Teil dieser GRT, der dem Eigentümer des Untergraphen entspricht, wird zusammen mit dem Untergraphen an L2 gesendet.
+
+If you're using a "regular" wallet like Metamask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same Curator address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 receiving wallet address.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum, as otherwise the curation will be lost and cannot be recovered.**
+
+## Sending curation to L2: Step 1
+
+Before starting the transfer, you must decide which address will own the curation on L2 (see "Choosing your L2 wallet" above), and it is recommended having some ETH for gas already bridged on Arbitrum in case you need to retry the execution of the message on L2. You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - since gas fees on Arbitrum are so low, you should only need a small amount, e.g. 0.01 ETH will probably be more than enough.
+
+If a subgraph that you curate to has been transferred to L2, you will see a message on Explorer telling you that you're curating to a transferred subgraph.
+
+When looking at the subgraph page, you can choose to withdraw or transfer the curation. Clicking on "Transfer Signal to Arbitrum" will open the transfer tool.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+After opening the Transfer Tool, you may be prompted to add some ETH to your wallet if you don't have any. Then you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Signal will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer.
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retryable tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+## Sending curation to L2: step 2
+
+Starting the transfer:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+After you start the transfer, the message that sends your L1 curation to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Sobald diese Wartezeit abgelaufen ist, versucht Arbitrum, die Übertragung auf den L2-Verträgen automatisch auszuführen.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Sending curation to L2: step 3
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the curation on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your curation to L2 will be pending and require a retry within 7 days.
+
+Wenn dies der Fall ist, müssen Sie sich mit einer L2-Wallet verbinden, die etwas ETH auf Arbitrum hat, Ihr Wallet-Netzwerk auf Arbitrum umstellen und auf "Confirm Transfer" klicken, um die Transaktion zu wiederholen.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Withdrawing your curation on L1
+
+If you prefer not to send your GRT to L2, or you'd rather bridge the GRT manually, you can withdraw your curated GRT on L1. On the banner on the subgraph page, choose "Withdraw Signal" and confirm the transaction; the GRT will be sent to your Curator address.

From fc1648a4d6ea7a453d1cba97c49c94b9a42090ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:12 -0500
Subject: [PATCH 1050/3820] New translations l2-transfer-tools-guide.mdx
 (Italian)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/it/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/it/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/it/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..485f34a70c97
--- /dev/null
+++ b/website/pages/it/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 Transfer Tools Guide
+---
+
+The Graph has made it easy to move to L2 on Arbitrum One. For each protocol participant, there are a set of L2 Transfer Tools to make transferring to L2 seamless for all network participants. These tools will require you to follow a specific set of steps depending on what you are transferring.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## How to transfer your subgraph to Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Benefits of transferring your subgraphs
+
+The Graph's community and core devs have [been preparing](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) to move to Arbitrum over the past year. Arbitrum, a layer 2 or "L2" blockchain, inherits the security from Ethereum but provides drastically lower gas fees.
+
+When you publish or upgrade your subgraph to The Graph Network, you're interacting with smart contracts on the protocol and this requires paying for gas using ETH. By moving your subgraphs to Arbitrum, any future updates to your subgraph will require much lower gas fees. The lower fees, and the fact that curation bonding curves on L2 are flat, also make it easier for other Curators to curate on your subgraph, increasing the rewards for Indexers on your subgraph. This lower-cost environment also makes it cheaper for Indexers to index and serve your subgraph. Indexing rewards will be increasing on Arbitrum and decreasing on Ethereum mainnet over the coming months, so more and more Indexers will be transferring their stake and setting up their operations on L2.
+
+## Understanding what happens with signal, your L1 subgraph and query URLs
+
+Transferring a subgraph to Arbitrum uses the Arbitrum GRT bridge, which in turn uses the native Arbitrum bridge, to send the subgraph to L2. The "transfer" will deprecate the subgraph on mainnet and send the information to re-create the subgraph on L2 using the bridge. It will also include the subgraph owner's signaled GRT, which must be more than zero for the bridge to accept the transfer.
+
+When you choose to transfer the subgraph, this will convert all of the subgraph's curation signal to GRT. This is equivalent to "deprecating" the subgraph on mainnet. The GRT corresponding to your curation will be sent to L2 together with the subgraph, where they will be used to mint signal on your behalf.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph. If a subgraph owner does not transfer their subgraph to L2 and manually deprecates it via a contract call, then Curators will be notified and will be able to withdraw their curation.
+
+As soon as the subgraph is transferred, since all curation is converted to GRT, Indexers will no longer receive rewards for indexing the subgraph. However, there will be Indexers that will 1) keep serving transferred subgraphs for 24 hours, and 2) immediately start indexing the subgraph on L2. Since these Indexers already have the subgraph indexed, there should be no need to wait for the subgraph to sync, and it will be possible to query the L2 subgraph almost immediately.
+
+Queries to the L2 subgraph will need to be done to a different URL (on `arbitrum-gateway.thegraph.com`), but the L1 URL will continue working for at least 48 hours. After that, the L1 gateway will forward queries to the L2 gateway (for some time), but this will add latency so it is recommended to switch all your queries to the new URL as soon as possible.
+
+## Choosing your L2 wallet
+
+When you published your subgraph on mainnet, you used a connected wallet to create the subgraph, and this wallet owns the NFT that represents this subgraph and allows you to publish updates.
+
+When transferring the subgraph to Arbitrum, you can choose a different wallet that will own this subgraph NFT on L2.
+
+If you're using a "regular" wallet like MetaMask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same owner address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 owner of your subgraph.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum. Otherwise, the subgraph will be lost and cannot be recovered.**
+
+## Preparing for the transfer: bridging some ETH
+
+Transferring the subgraph involves sending a transaction through the bridge, and then executing another transaction on Arbitrum. The first transaction uses ETH on mainnet, and includes some ETH to pay for gas when the message is received on L2. However, if this gas is insufficient, you will have to retry the transaction and pay for the gas directly on L2 (this is "Step 3: Confirming the transfer" below). This step **must be executed within 7 days of starting the transfer**. Moreover, the second transaction ("Step 4: Finishing the transfer on L2") will be done directly on Arbitrum. For these reasons, you will need some ETH on an Arbitrum wallet. If you're using a multisig or smart contract account, the ETH will need to be in the regular (EOA) wallet that you are using to execute the transactions, not on the multisig wallet itself.
+
+You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Since gas fees on Arbitrum are lower, you should only need a small amount. It is recommended that you start at a low threshold (0.e.g. 01 ETH) for your transaction to be approved.
+
+## Finding the subgraph Transfer Tool
+
+You can find the L2 Transfer Tool when you're looking at your subgraph's page on Subgraph Studio:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+It is also available on Explorer if you're connected with the wallet that owns a subgraph and on that subgraph's page on Explorer:
+
+![Transferring to L2](/img/transferToL2.png)
+
+Clicking on the Transfer to L2 button will open the transfer tool where you can start the transfer process.
+
+## Step 1: Starting the transfer
+
+Before starting the transfer, you must decide which address will own the subgraph on L2 (see "Choosing your L2 wallet" above), and it is strongly recommend having some ETH for gas already bridged on Arbitrum (see "Preparing for the transfer: bridging some ETH" above).
+
+Also please note transferring the subgraph requires having a nonzero amount of signal on the subgraph with the same account that owns the subgraph; if you haven't signaled on the subgraph you will have to add a bit of curation (adding a small amount like 1 GRT would suffice).
+
+After opening the Transfer Tool, you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Subgraph will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer and deprecate your L1 subgraph (see "Understanding what happens with signal, your L1 subgraph and query URLs" above for more details on what goes on behind the scenes).
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or the subgraph and your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retry-able tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Step 2: Waiting for the subgraph to get to L2
+
+After you start the transfer, the message that sends your L1 subgraph to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## Step 3: Confirming the transfer
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the subgraph on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your subgraph to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## Step 4: Finishing the transfer on L2
+
+At this point, your subgraph and GRT have been received on Arbitrum, but the subgraph is not published yet. You will need to connect using the L2 wallet that you chose as the receiving wallet, switch your wallet network to Arbitrum, and click "Publish Subgraph."
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+This will publish the subgraph so that Indexers that are operating on Arbitrum can start serving it. It will also mint curation signal using the GRT that were transferred from L1.
+
+## Step 5: Updating the query URL
+
+Your subgraph has been successfully transferred to Arbitrum! To query the subgraph, the new URL will be :
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Note that the subgraph ID on Arbitrum will be a different than the one you had on mainnet, but you can always find it on Explorer or Studio. As mentioned above (see "Understanding what happens with signal, your L1 subgraph and query URLs") the old L1 URL will be supported for a short while, but you should switch your queries to the new address as soon as the subgraph has been synced on L2.
+
+## How to transfer your curation to Arbitrum (L2)
+
+## Understanding what happens to curation on subgraph transfers to L2
+
+When the owner of a subgraph transfers a subgraph to Arbitrum, all of the subgraph's signal is converted to GRT at the same time. This applies to "auto-migrated" signal, i.e. signal that is not specific to a subgraph version or deployment but that follows the latest version of a subgraph.
+
+This conversion from signal to GRT is the same as what would happen if the subgraph owner deprecated the subgraph in L1. When the subgraph is deprecated or transferred, all curation signal is "burned" simultaneously (using the curation bonding curve) and the resulting GRT is held by the GNS smart contract (that is the contract that handles subgraph upgrades and auto-migrated signal). Each Curator on that subgraph therefore has a claim to that GRT proportional to the amount of shares they had for the subgraph.
+
+A fraction of these GRT corresponding to the subgraph owner is sent to L2 together with the subgraph.
+
+At this point, the curated GRT will not accrue any more query fees, so Curators can choose to withdraw their GRT or transfer it to the same subgraph on L2, where it can be used to mint new curation signal. There is no rush to do this as the GRT can be help indefinitely and everybody gets an amount proportional to their shares, irrespective of when they do it.
+
+## Choosing your L2 wallet
+
+If you decide to transfer your curated GRT to L2, you can choose a different wallet that will own the curation signal on L2.
+
+If you're using a "regular" wallet like Metamask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same Curator address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 receiving wallet address.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum, as otherwise the curation will be lost and cannot be recovered.**
+
+## Sending curation to L2: Step 1
+
+Before starting the transfer, you must decide which address will own the curation on L2 (see "Choosing your L2 wallet" above), and it is recommended having some ETH for gas already bridged on Arbitrum in case you need to retry the execution of the message on L2. You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - since gas fees on Arbitrum are so low, you should only need a small amount, e.g. 0.01 ETH will probably be more than enough.
+
+If a subgraph that you curate to has been transferred to L2, you will see a message on Explorer telling you that you're curating to a transferred subgraph.
+
+When looking at the subgraph page, you can choose to withdraw or transfer the curation. Clicking on "Transfer Signal to Arbitrum" will open the transfer tool.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+After opening the Transfer Tool, you may be prompted to add some ETH to your wallet if you don't have any. Then you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Signal will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer.
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retryable tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+## Sending curation to L2: step 2
+
+Starting the transfer:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+After you start the transfer, the message that sends your L1 curation to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Sending curation to L2: step 3
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the curation on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your curation to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Withdrawing your curation on L1
+
+If you prefer not to send your GRT to L2, or you'd rather bridge the GRT manually, you can withdraw your curated GRT on L1. On the banner on the subgraph page, choose "Withdraw Signal" and confirm the transaction; the GRT will be sent to your Curator address.

From 7c15f845539acffda39f158fcb786ef7a23b85a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:13 -0500
Subject: [PATCH 1051/3820] New translations l2-transfer-tools-guide.mdx
 (Japanese)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/ja/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/ja/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/ja/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..ac4c0bc9fb0d
--- /dev/null
+++ b/website/pages/ja/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 転送ツールガイド
+---
+
+グラフにより、アービトラムワンのL2に簡単に移動できるようになりました。プロトコル参加者ごとに、すべてのネットワーク参加者が L2 への転送をシームレスに行うための L2 転送ツールのセットがあります。これらのツールでは、転送する内容に応じて、特定の一連の手順に従う必要があります。
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## サブグラフをアービトラムに転送する方法 (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## サブグラフを転送する利点
+
+グラフのコミュニティとコア開発者は、過去1年間、Arbitrumに移行する準備をしてきました(https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305)。レイヤー2または「L2」ブロックチェーンであるアービトラムは、イーサリアムからセキュリティを継承しますが、ガス料金を大幅に削減します。
+
+サブグラフをThe Graph Networkに公開またはアップグレードする際には、プロトコル上のスマートコントラクトとやり取りするため、ETHを使用してガスを支払う必要があります。サブグラフをArbitrumに移動することで、将来のサブグラフのアップデートにかかるガス料金が大幅に削減されます。低い手数料と、L2のキュレーションボンディングカーブがフラットであるという点も、他のキュレーターがあなたのサブグラフをキュレーションしやすくし、サブグラフのインデクサーへの報酬を増加させます。この低コストな環境は、インデクサーがサブグラフをインデックス化して提供するコストも削減します。アービトラム上のインデックス報酬は今後数か月間で増加し、Ethereumメインネット上では減少する予定です。そのため、ますます多くのインデクサーがステークを転送し、L2での運用を設定していくことになるでしょう。
+
+## シグナル、L1サブグラフ、クエリURLで何が起こるかを理解する
+
+サブグラフをアービトラムに転送するには、アービトラムGRTブリッジが使用され、アービトラムGRTブリッジはネイティブアービトラムブリッジを使用してサブグラフをL2に送信します。「転送」はメインネット上のサブグラフを非推奨にし、ブリッジを使用してL2上のサブグラフを再作成するための情報を送信します。また、サブグラフ所有者のシグナル GRT も含まれ、ブリッジが転送を受け入れるには 0 より大きくなければなりません。
+
+サブグラフの転送を選択すると、サブグラフのすべてのキュレーション信号がGRTに変換されます。これは、メインネットのサブグラフを「非推奨」にすることと同じです。キュレーションに対応するGRTはサブグラフとともにL2に送信され、そこであなたに代わってシグナルを作成するために使用されます。
+
+他のキュレーターは、GRTの分数を引き出すか、同じサブグラフでシグナルをミントするためにL2に転送するかを選択できます。サブグラフの所有者がサブグラフをL2に転送せず、コントラクトコールを介して手動で非推奨にした場合、キュレーターに通知され、キュレーションを取り消すことができます。
+
+サブグラフが転送されるとすぐに、すべてのキュレーションがGRTに変換されるため、インデクサーはサブグラフのインデックス作成に対する報酬を受け取らなくなります。ただし、1) 転送されたサブグラフを24時間提供し続け、2) L2でサブグラフのインデックス作成をすぐに開始するインデクサーがあります。これらのインデクサーには既にサブグラフのインデックスが作成されているため、サブグラフが同期するのを待つ必要はなく、ほぼ即座にL2サブグラフを照会できます。
+
+L2 サブグラフへのクエリは別の URL (「arbitrum-gateway.thegraph.com」) に対して実行する必要がありますが、L1 URL は少なくとも 48 時間は機能し続けます。その後、L1ゲートウェイはクエリをL2ゲートウェイに転送しますが(しばらくの間)、これにより遅延が増えるため、できるだけ早くすべてのクエリを新しいURLに切り替えることをお勧めします。
+
+## L2ウォレットの選択
+
+メインネットでサブグラフを公開したときに、接続されたウォレットを使用してサブグラフを作成し、このウォレットはこのサブグラフを表すNFTを所有し、更新を公開できます。
+
+サブグラフをアービトラムに転送する場合、L2でこのサブグラフNFTを所有する別のウォレットを選択できます。
+
+MetaMaskのような "通常の" ウォレット(外部所有アカウントまたはEOA、つまりスマートコントラクトではないウォレット)を使用している場合、これはオプションであり、L1と同じ所有者アドレスを保持することをお勧めします。
+
+マルチシグ(Safeなど)などのスマートコントラクトウォレットを使用している場合、このアカウントはメインネットにのみ存在し、このウォレットを使用してアービトラムで取引を行うことができない可能性が高いため、別のL2ウォレットアドレスを選択する必要があります。スマートコントラクトウォレットまたはマルチシグを使い続けたい場合は、Arbitrumで新しいウォレットを作成し、そのアドレスをサブグラフのL2所有者として使用します。
+
+\*\*あなたが管理し、アービトラムで取引を行うことができるウォレットアドレスを使用することは非常に重要です。そうしないと、サブグラフが失われ、復元できません。
+
+## 転送の準備: 一部のETHのブリッジング
+
+サブグラフを転送するには、ブリッジを介してトランザクションを送信し、その後アービトラム上で別のトランザクションを実行する必要があります。最初のトランザクションでは、メインネット上のETHを使用し、L2でメッセージが受信される際にガスを支払うためにいくらかのETHが含まれています。ただし、このガスが不足している場合、トランザクションを再試行し、L2で直接ガスを支払う必要があります（これが下記の「ステップ3：転送の確認」です）。このステップは、転送を開始してから7日以内に実行する必要があります。さらに、2つ目のトランザクション（「ステップ4：L2での転送の完了」）は、直接アービトラム上で行われます。これらの理由から、アービトラムウォレットに一定のETHが必要です。マルチシグまたはスマートコントラクトアカウントを使用している場合、ETHはトランザクションを実行するために使用している通常の個人のウォレット（EOAウォレット）にある必要があり、マルチシグウォレットそのものにはないことに注意してください
+
+一部の取引所でETHを購入してアービトラムに直接引き出すか、アービトラムブリッジを使用してメインネットウォレットからL2にETHを送信することができます:[bridge.arbitrum.io](http://bridge.arbitrum.io)。アービトラムのガス料金は安いので、必要なのは少量だけです。トランザクションが承認されるには、低いしきい値(0.01 ETHなど)から始めることをお勧めします。
+
+## サブグラフ転送ツールの検索
+
+L2転送ツールは、サブグラフスタジオでサブグラフのページを見ているときに見つけることができます。
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+サブグラフを所有するウォレットに接続している場合は、エクスプローラーとエクスプローラーのそのサブグラフのページでも入手できます。
+
+![Transferring to L2](/img/transferToL2.png)
+
+[L2に転送] ボタンをクリックすると、転送ツールが開き、転送プロセスを開始できます。
+
+## ステップ1: 転送を開始する
+
+転送を開始する前に、どのアドレスがL2のサブグラフを所有するかを決定する必要があり(上記の「L2ウォレットの選択」を参照)、ガス用のETHをアービトラムにすでにブリッジすることを強くお勧めします(上記の「転送の準備: ETHのブリッジング」を参照)。
+
+また、サブグラフを転送するには、サブグラフを所有するのと同じアカウントを持つサブグラフにゼロ以外の量のシグナルが必要であることに注意してください。サブグラフでシグナルを出していない場合は、少しキュレーションを追加する必要があります(1 GRTのような少量を追加するだけで十分です)。
+
+「Transfer Tool」を開いた後、L2ウォレットアドレスを「受信ウォレットアドレス」フィールドに入力できるようになります。ここで正しいアドレスを入力していることを確認してください。「Transfer Subgraph」をクリックすると、ウォレット上でトランザクションを実行するよう求められます（注意：L2ガスの支払いに十分なETHの価値が含まれています）。これにより、トランスファーが開始され、L1サブグラフが廃止されます（詳細については、「背後で何が起こるか：シグナル、L1サブグラフ、およびクエリURLの理解」を参照してください）。
+
+このステップを実行する場合は、\*\*7日以内にステップ3を完了するまで続行してください。そうしないと、サブグラフとシグナルGRTが失われます。 これは、L1-L2メッセージングがアービトラムでどのように機能するかによるものです: ブリッジを介して送信されるメッセージは、7日以内に実行する必要がある「再試行可能なチケット」であり、アービトラムのガス価格に急上昇がある場合は、最初の実行で再試行が必要になる場合があります。
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## ステップ2: サブグラフがL2に到達するのを待つ
+
+転送を開始した後、L1サブグラフをL2に送信するメッセージは、アービトラムブリッジを介して伝播する必要があります。これには約20分かかります(ブリッジは、トランザクションを含むメインネットブロックが潜在的なチェーン再編成から「安全」になるまで待機します)。
+
+この待機時間が終了すると、アービトラムはL2契約の転送の自動実行を試みます。
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## ステップ3: 転送の確認
+
+ほとんどの場合、ステップ1に含まれるL2ガスは、アービトラム契約のサブグラフを受け取るトランザクションを実行するのに十分であるため、このステップは自動実行されます。ただし、場合によっては、アービトラムのガス価格の急騰により、この自動実行が失敗する可能性があります。この場合、サブグラフをL2に送信する「チケット」は保留中であり、7日以内に再試行する必要があります。
+
+この場合、アービトラムにETHがあるL2ウォレットを使用して接続し、ウォレットネットワークをアービトラムに切り替え、[転送の確認] をクリックしてトランザクションを再試行する必要があります。
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## ステップ4: L2での転送の完了
+
+この時点で、サブグラフとGRTはアービトラムで受信されましたが、サブグラフはまだ公開されていません。受信ウォレットとして選択したL2ウォレットを使用して接続し、ウォレットネットワークをArbitrumに切り替えて、[サブグラフの公開] をクリックする必要があります。
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+これにより、アービトラムで動作しているインデクサーがサブグラフの提供を開始できるように、サブグラフが公開されます。また、L1から転送されたGRTを使用してキュレーションシグナルをミントします。
+
+## ステップ 5: クエリ URL の更新
+
+サブグラフがアービトラムに正常に転送されました! サブグラフを照会するには、新しい URL は次のようになります:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+アービトラム上のサブグラフIDは、メインネット上でのものとは異なることに注意してください。ただし、エクスプローラやスタジオ上で常にそのIDを見つけることができます（詳細は「シグナル、L1サブグラフ、およびクエリURLの動作理解」を参照）。前述のように、古いL1 URLはしばらくの間サポートされますが、サブグラフがL2上で同期されたらすぐに新しいアドレスにクエリを切り替える必要があります。
+
+## キュレーションをアービトラム(L2) に転送する方法
+
+## L2へのサブグラフ転送のキュレーションに何が起こるかを理解する
+
+サブグラフの所有者がサブグラフをアービトラムに転送すると、サブグラフのすべての信号が同時にGRTに変換されます。これは、「自動移行」シグナル、つまりサブグラフのバージョンまたはデプロイに固有ではないが、サブグラフの最新バージョンに従うシグナルに適用されます。
+
+このシグナルからGRTへの変換は、サブグラフのオーナーがL1でサブグラフを非推奨にした場合と同じです。サブグラフが非推奨化または移管されると、すべてのキュレーションシグナルは同時に（キュレーションボンディングカーブを使用して）「燃やされ」、その結果得られるGRTはGNSスマートコントラクトに保持されます（これはサブグラフのアップグレードと自動移行されるシグナルを処理するコントラクトです）。そのため、そのサブグラフの各キュレーターは、所持していたシェアの量に比例したGRTの請求権を持っています。
+
+サブグラフの所有者に対応するこれらの GRT の一部は、サブグラフとともに L2 に送信されます。
+
+この時点では、キュレートされたGRTはこれ以上のクエリ手数料を蓄積しません。したがって、キュレーターは自分のGRTを引き出すか、それをL2上の同じサブグラフに移動して新しいキュレーションシグナルを作成するために使用することができます。いつ行うかに関わらず、GRTは無期限に保持でき、すべての人が自分のシェアに比例した額を受け取ることができるため、急ぐ必要はありません。
+
+## L2ウォレットの選択
+
+キュレーションされたGRTをL2に転送する場合は、L2のキュレーションシグナルを所有する別のウォレットを選択できます。
+
+もしMetamaskのような「通常の」ウォレット（Externally Owned AccountまたはEOA、つまりスマートコントラクトではないウォレット）を使用している場合、これはオプションです。そして、L1と同じキュレーターアドレスを保持することが推奨されます。
+
+スマートコントラクトウォレット（例：マルチシグ、Safeなど）を使用している場合、異なるL2ウォレットアドレスを選択することは必須です。おそらくこのアカウントはメインネット上のみ存在しており、このウォレットを使用してArbitrumでトランザクションを行うことはできません。スマートコントラクトウォレットやマルチシグを引き続き使用したい場合は、Arbitrum上で新しいウォレットを作成し、そのアドレスをL2受信ウォレットアドレスとして使用してください。
+
+**重要なのは、あなたがコントロールし、Arbitrum上でトランザクションを行えるウォレットアドレスを使用することです。そうしないとキュレーションが失われ、回復することはできません。**
+
+## キュレーションを L2 に送信する: ステップ 1
+
+転送を開始する前に、L2上でキュレーションを所有するアドレスを決定する必要があります（上記の「L2ウォレットの選択」を参照）。また、L2でメッセージの実行を再試行する必要がある場合に備えて、ガスのためにすでにArbitrumにブリッジされたいくらかのETHを持つことをお勧めします。ETHをいくつかの取引所で購入し、それを直接Arbitrumに引き出すことができます。または、Arbitrumブリッジを使用して、メインネットのウォレットからL2にETHを送信することもできます： [bridge.arbitrum.io](http://bridge.arbitrum.io)。Arbitrumのガス料金が非常に低いため、0.01 ETHなどの少額で十分です。
+
+もしキュレーションしているサブグラフがL2に移行された場合、エクスプローラ上でそのサブグラフが移行されたことを示すメッセージが表示されます。
+
+サブグラフのページを表示する際に、キュレーションを引き出すか、移行するかを選択できます。"Transfer Signal to Arbitrum" をクリックすると、移行ツールが開きます。
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+移行ツールを開いた後、ウォレットにETHがない場合はETHを追加するよう促されることがあります。その後、L2ウォレットアドレスを「受信ウォレットアドレス」フィールドに入力できます。ここに正しいアドレスを入力していることを確認してください。"Transfer Signal" をクリックすると、ウォレット上でトランザクションを実行するよう求められます（L2ガスの支払いに一定のETH価値が含まれています）。これにより、移行が開始されます。
+
+このステップを実行する場合、**ステップ3を7日以内に完了するように注意してください。7日を過ぎると、シグナルGRTは失われる可能性があります。** これは、ArbitrumのL1-L2メッセージングの仕組みに起因しています。ブリッジを介して送信されるメッセージは「再試行可能なチケット」であり、7日以内に実行される必要があり、初回の実行がArbitrumのガス価格の急上昇により再試行が必要な場合もあります。
+
+## キュレーションを L2 に送信する: ステップ 2
+
+転送を開始します:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+移行を開始すると、L1キュレーションをL2に送信するメッセージがArbitrumブリッジを介して伝播する必要があります。これには約20分かかります（ブリッジは、トランザクションを含むメインネットのブロックが潜在的なチェーンの再編から「安全」であるのを待ちます）。
+
+この待機時間が終了すると、アービトラムはL2契約の転送の自動実行を試みます。
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## キュレーションを L2 に送信する: ステップ 3
+
+ほとんどの場合、ステップ1に含まれるL2ガスは、アービトラム契約でキュレーションを受け取るトランザクションを実行するのに十分であるため、このステップは自動実行されます。ただし、場合によっては、アービトラムのガス価格の急騰により、この自動実行が失敗する可能性があります。この場合、キュレーションをL2に送信する「チケット」は保留中であり、7日以内に再試行する必要があります。
+
+この場合、アービトラムにETHがあるL2ウォレットを使用して接続し、ウォレットネットワークをアービトラムに切り替え、[転送の確認] をクリックしてトランザクションを再試行する必要があります。
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## L1 でキュレーションを取り消す
+
+GRT を L2 に送信したくない場合、または GRT を手動でブリッジしたい場合は、L1 でキュレーションされた GRT を取り消すことができます。サブグラフページのバナーで、「シグナルの引き出し」を選択し、トランザクションを確認します。GRTはあなたのキュレーターアドレスに送信されます。

From cccb6c242a7fad10754f3556fb03d778ac302707 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:14 -0500
Subject: [PATCH 1052/3820] New translations l2-transfer-tools-guide.mdx
 (Korean)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/ko/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/ko/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/ko/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..485f34a70c97
--- /dev/null
+++ b/website/pages/ko/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 Transfer Tools Guide
+---
+
+The Graph has made it easy to move to L2 on Arbitrum One. For each protocol participant, there are a set of L2 Transfer Tools to make transferring to L2 seamless for all network participants. These tools will require you to follow a specific set of steps depending on what you are transferring.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## How to transfer your subgraph to Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Benefits of transferring your subgraphs
+
+The Graph's community and core devs have [been preparing](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) to move to Arbitrum over the past year. Arbitrum, a layer 2 or "L2" blockchain, inherits the security from Ethereum but provides drastically lower gas fees.
+
+When you publish or upgrade your subgraph to The Graph Network, you're interacting with smart contracts on the protocol and this requires paying for gas using ETH. By moving your subgraphs to Arbitrum, any future updates to your subgraph will require much lower gas fees. The lower fees, and the fact that curation bonding curves on L2 are flat, also make it easier for other Curators to curate on your subgraph, increasing the rewards for Indexers on your subgraph. This lower-cost environment also makes it cheaper for Indexers to index and serve your subgraph. Indexing rewards will be increasing on Arbitrum and decreasing on Ethereum mainnet over the coming months, so more and more Indexers will be transferring their stake and setting up their operations on L2.
+
+## Understanding what happens with signal, your L1 subgraph and query URLs
+
+Transferring a subgraph to Arbitrum uses the Arbitrum GRT bridge, which in turn uses the native Arbitrum bridge, to send the subgraph to L2. The "transfer" will deprecate the subgraph on mainnet and send the information to re-create the subgraph on L2 using the bridge. It will also include the subgraph owner's signaled GRT, which must be more than zero for the bridge to accept the transfer.
+
+When you choose to transfer the subgraph, this will convert all of the subgraph's curation signal to GRT. This is equivalent to "deprecating" the subgraph on mainnet. The GRT corresponding to your curation will be sent to L2 together with the subgraph, where they will be used to mint signal on your behalf.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph. If a subgraph owner does not transfer their subgraph to L2 and manually deprecates it via a contract call, then Curators will be notified and will be able to withdraw their curation.
+
+As soon as the subgraph is transferred, since all curation is converted to GRT, Indexers will no longer receive rewards for indexing the subgraph. However, there will be Indexers that will 1) keep serving transferred subgraphs for 24 hours, and 2) immediately start indexing the subgraph on L2. Since these Indexers already have the subgraph indexed, there should be no need to wait for the subgraph to sync, and it will be possible to query the L2 subgraph almost immediately.
+
+Queries to the L2 subgraph will need to be done to a different URL (on `arbitrum-gateway.thegraph.com`), but the L1 URL will continue working for at least 48 hours. After that, the L1 gateway will forward queries to the L2 gateway (for some time), but this will add latency so it is recommended to switch all your queries to the new URL as soon as possible.
+
+## Choosing your L2 wallet
+
+When you published your subgraph on mainnet, you used a connected wallet to create the subgraph, and this wallet owns the NFT that represents this subgraph and allows you to publish updates.
+
+When transferring the subgraph to Arbitrum, you can choose a different wallet that will own this subgraph NFT on L2.
+
+If you're using a "regular" wallet like MetaMask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same owner address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 owner of your subgraph.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum. Otherwise, the subgraph will be lost and cannot be recovered.**
+
+## Preparing for the transfer: bridging some ETH
+
+Transferring the subgraph involves sending a transaction through the bridge, and then executing another transaction on Arbitrum. The first transaction uses ETH on mainnet, and includes some ETH to pay for gas when the message is received on L2. However, if this gas is insufficient, you will have to retry the transaction and pay for the gas directly on L2 (this is "Step 3: Confirming the transfer" below). This step **must be executed within 7 days of starting the transfer**. Moreover, the second transaction ("Step 4: Finishing the transfer on L2") will be done directly on Arbitrum. For these reasons, you will need some ETH on an Arbitrum wallet. If you're using a multisig or smart contract account, the ETH will need to be in the regular (EOA) wallet that you are using to execute the transactions, not on the multisig wallet itself.
+
+You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Since gas fees on Arbitrum are lower, you should only need a small amount. It is recommended that you start at a low threshold (0.e.g. 01 ETH) for your transaction to be approved.
+
+## Finding the subgraph Transfer Tool
+
+You can find the L2 Transfer Tool when you're looking at your subgraph's page on Subgraph Studio:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+It is also available on Explorer if you're connected with the wallet that owns a subgraph and on that subgraph's page on Explorer:
+
+![Transferring to L2](/img/transferToL2.png)
+
+Clicking on the Transfer to L2 button will open the transfer tool where you can start the transfer process.
+
+## Step 1: Starting the transfer
+
+Before starting the transfer, you must decide which address will own the subgraph on L2 (see "Choosing your L2 wallet" above), and it is strongly recommend having some ETH for gas already bridged on Arbitrum (see "Preparing for the transfer: bridging some ETH" above).
+
+Also please note transferring the subgraph requires having a nonzero amount of signal on the subgraph with the same account that owns the subgraph; if you haven't signaled on the subgraph you will have to add a bit of curation (adding a small amount like 1 GRT would suffice).
+
+After opening the Transfer Tool, you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Subgraph will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer and deprecate your L1 subgraph (see "Understanding what happens with signal, your L1 subgraph and query URLs" above for more details on what goes on behind the scenes).
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or the subgraph and your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retry-able tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Step 2: Waiting for the subgraph to get to L2
+
+After you start the transfer, the message that sends your L1 subgraph to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## Step 3: Confirming the transfer
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the subgraph on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your subgraph to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## Step 4: Finishing the transfer on L2
+
+At this point, your subgraph and GRT have been received on Arbitrum, but the subgraph is not published yet. You will need to connect using the L2 wallet that you chose as the receiving wallet, switch your wallet network to Arbitrum, and click "Publish Subgraph."
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+This will publish the subgraph so that Indexers that are operating on Arbitrum can start serving it. It will also mint curation signal using the GRT that were transferred from L1.
+
+## Step 5: Updating the query URL
+
+Your subgraph has been successfully transferred to Arbitrum! To query the subgraph, the new URL will be :
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Note that the subgraph ID on Arbitrum will be a different than the one you had on mainnet, but you can always find it on Explorer or Studio. As mentioned above (see "Understanding what happens with signal, your L1 subgraph and query URLs") the old L1 URL will be supported for a short while, but you should switch your queries to the new address as soon as the subgraph has been synced on L2.
+
+## How to transfer your curation to Arbitrum (L2)
+
+## Understanding what happens to curation on subgraph transfers to L2
+
+When the owner of a subgraph transfers a subgraph to Arbitrum, all of the subgraph's signal is converted to GRT at the same time. This applies to "auto-migrated" signal, i.e. signal that is not specific to a subgraph version or deployment but that follows the latest version of a subgraph.
+
+This conversion from signal to GRT is the same as what would happen if the subgraph owner deprecated the subgraph in L1. When the subgraph is deprecated or transferred, all curation signal is "burned" simultaneously (using the curation bonding curve) and the resulting GRT is held by the GNS smart contract (that is the contract that handles subgraph upgrades and auto-migrated signal). Each Curator on that subgraph therefore has a claim to that GRT proportional to the amount of shares they had for the subgraph.
+
+A fraction of these GRT corresponding to the subgraph owner is sent to L2 together with the subgraph.
+
+At this point, the curated GRT will not accrue any more query fees, so Curators can choose to withdraw their GRT or transfer it to the same subgraph on L2, where it can be used to mint new curation signal. There is no rush to do this as the GRT can be help indefinitely and everybody gets an amount proportional to their shares, irrespective of when they do it.
+
+## Choosing your L2 wallet
+
+If you decide to transfer your curated GRT to L2, you can choose a different wallet that will own the curation signal on L2.
+
+If you're using a "regular" wallet like Metamask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same Curator address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 receiving wallet address.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum, as otherwise the curation will be lost and cannot be recovered.**
+
+## Sending curation to L2: Step 1
+
+Before starting the transfer, you must decide which address will own the curation on L2 (see "Choosing your L2 wallet" above), and it is recommended having some ETH for gas already bridged on Arbitrum in case you need to retry the execution of the message on L2. You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - since gas fees on Arbitrum are so low, you should only need a small amount, e.g. 0.01 ETH will probably be more than enough.
+
+If a subgraph that you curate to has been transferred to L2, you will see a message on Explorer telling you that you're curating to a transferred subgraph.
+
+When looking at the subgraph page, you can choose to withdraw or transfer the curation. Clicking on "Transfer Signal to Arbitrum" will open the transfer tool.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+After opening the Transfer Tool, you may be prompted to add some ETH to your wallet if you don't have any. Then you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Signal will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer.
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retryable tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+## Sending curation to L2: step 2
+
+Starting the transfer:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+After you start the transfer, the message that sends your L1 curation to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Sending curation to L2: step 3
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the curation on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your curation to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Withdrawing your curation on L1
+
+If you prefer not to send your GRT to L2, or you'd rather bridge the GRT manually, you can withdraw your curated GRT on L1. On the banner on the subgraph page, choose "Withdraw Signal" and confirm the transaction; the GRT will be sent to your Curator address.

From f8bccba949cd6a2f28954bdebbf1ed7fb5dd16f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:15 -0500
Subject: [PATCH 1053/3820] New translations l2-transfer-tools-guide.mdx
 (Dutch)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/nl/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/nl/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/nl/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..ff8308766556
--- /dev/null
+++ b/website/pages/nl/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: Gids voor L2 Transfer Tools
+---
+
+The Graph heeft het eenvoudig gemaakt om naar L2 op Arbitrum One over te stappen. Voor elke deelnemer aan het protocol is er een set L2 Transfer Tools ontwikkeld om het overzetten van GRT naar L2 makkelijk te maken voor alle netwerkdeelnemers. Deze tools vereisen dat u een specifieke reeks stappen volgt, afhankelijk van wat u overdraagt.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## Hoe zet je je subgraph over naar Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Voordelen van het overzetten van uw subgraphs
+
+De community en ontwikkelaars van The Graph hebben [zich voorbereid](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) op de transitie naar Arbitrum gedurende het afgelopen jaar. Arbitrum, een layer 2 of "L2" blockchain, erft de beveiliging van Ethereum maar biedt aanzienlijk lagere gas fees.
+
+Wanneer je je subgraph publiceert of bijwerkt naar the Graph Network, interacteer je met smart contracts op het protocol en dit vereist het betalen van gas met ETH. Door je subgraphs naar Arbitrum te verplaatsen, zullen eventuele toekomstige updates aan de subgraph veel lagere gas fees vereisen. De lagere kosten, en het feit dat de curatie bonding curves op L2 vlak zijn, maken het ook makkelijker voor andere curatoren om te cureren op uw subgraph, waardoor de beloningen voor indexeerders op uw subgraph toenemen. Deze omgeving met lagere kosten maakt het ook goedkoper voor indexeerders om de subgraph te indexeren en query's te beantwoorden. Indexeringsbeloningen zullen op Arbitrum toenemen en op Ethereum mainnet afnemen in de komden maanden, dus meer en meer indexeerders zullen hun GRT overzetten en hun operaties op L2 opzetten.
+
+## Begrijpen wat er gebeurt met signalen, de L1 subgraph en query URL's
+
+Het overzetten van een subgraph naar Arbitrum gebruikt de Arbitrum GRT brug, die op zijn beurt de natuurlijke Arbitrum brug gebruikt, om de subgraph naar L2 te sturen. De "transfer" zal de subgraph op mainnet verwijderen en de informatie versturen om de subgraph op L2 opnieuw te creëren met de bridge. Het zal ook de gesignaleerde GRT van de eigenaar van de subgraph bevatten, wat meer dan nul moet zijn voor de brug om de overdracht te accepteren.
+
+Wanneer je kiest om de subgraph over te dragen, zal dit alle curatie van de subgraph omzetten in GRT. Dit staat gelijk aan het "degraderen" van de subgraph op mainnet. De GRT die overeenkomt met je curatie zal samen met de subgraph naar L2 worden gestuurd, waar ze zullen worden gebruikt om signaal namens u te munten.
+
+Andere curatoren kunnen kiezen of ze hun fractie van GRT willen opnemen, of het ook naar L2 willen overzetten om signaal op dezelfde subgraph te munten. Als een eigenaar van een subgraph hun subgraph niet naar L2 overzet en handmatig verwijderd via een contract call, dan zullen curatoren worden genotificeerd en zullen ze in staat zijn om hun curatie op te nemen.
+
+Zodra de subgraph is overgedragen, aangezien alle curatie is omgezet in GRT, zullen indexeerders geen beloningen meer ontvangen voor het indexeren van de subgraph. Er zullen echter indexeerders zijn die 1) overgedragen subgraphs 24 uur blijven ondersteunen, en 2) onmiddelijk beginnen met het indexeren van de subgraph op L2. Aangezien deze indexeerders de subgraph al hebben geïndexeerd, zou er geen noodzaak moeten zijn om te wachten tot de subgraph is gesynchroniseerd, en het zal mogelijk zijn om de L2 subgraph bijna onmiddelijk te queryen.
+
+Query's naar de L2 subgraph moeten worden gedaan naar een andere URL (op `arbitrum-gateway.thegraph.com`), maar het L1 URL zal minimaal 48 uur blijven werken. Daarna zal de L1 gateway query's doorsturen naar de L2 gateway (voor enige tijd), maar dit zal latentie toevoegen dus het wordt aanbevolen om al uw query's zo snel mogelijk naar de nieuwe URL over te schakelen.
+
+## Jouw L2 wallet kiezen
+
+Wanneer je je subgraph op mainnet publiceerde, gebruikte je een verbonden wallet om de subgraph te creëren, en deze wallet bezit de NFT die deze subgraph vertegenwoordigt en dit zorgt er voor dat je updates kunt publiceren.
+
+Bij het overzetten van de subgraph naar Arbitrum, kunt u een andere wallet kiezen die deze subgraph NFT op L2 zal bezitten.
+
+Als je een "reguliere" wallet gebruikt zoals MetaMask (een Externally Owned Account of EOA, d.w.z. een wallet die geen smart contract is), dan is dit optioneel en wordt het aanbevolen om dezelfde wallet te gebruiken als in L1.
+
+Als je een smart contract wallet gebruikt, zoals een multisig (bijv. een Safe) dan is het kiezen van een ander L2 wallet adres verplicht, aangezien het waarschijnlijk is dat de multisig alleen op mainnet bestaat en je geen transacties op Arbitrum kunt maken met deze wallet. Als je een smart contract wallet of multisig wilt blijven gebruiken, maak dan een nieuwe wallet aan op Arbitrum en gebruik het adres ervan als de L2 eigenaar van jouw subgraph.
+
+**Het is erg belangrijk om een wallet adres te gebruiken dat u controleert, en dat transacties op Arbitrum kan maken. Anders zal de subgraph verloren gaan en kan niet worden hersteld.**
+
+## Voorbereiden op de overdracht: ETH verplaatsen van L1 naar L2
+
+Het overzetten van de subgraph houdt in dat je een transactie verstuurt via de brug, en vervolgens een andere transactie uitvoert op Arbitrum. De eerste transactie gebruikt ETH op mainnet, en bevat wat ETH om te betalen voor gas wanneer het op L2 wordt ontvangen. Echter, als dit onvoldoende is, zul je de transactie opnieuw moeten proberen en betalen voor het gas direct op L2 (dit is "Stap 3: De overdracht bevestigen" hieronder). Deze stap **moet worden uitgevoerd binnen 7 dagen na het starten van de overdracht**. Bovendien, de tweede transactie ("Stap 4: De overdracht op L2 afronden") zal direct op Arbitrum worden gedaan. Om deze redenen, zul je wat ETH nodig hebben op een Arbitrum wallet. Als je een multisig of smart contract wallet gebruikt, zal de ETH in de reguliere (EOA) wallet moeten zijn die je gebruikt om de transacties uit te voeren, niet op de multisig wallet zelf.
+
+Je kunt ETH kopen op sommige exchanges en direct naar Arbitrum opnemen, of je kunt de Arbitrum bridge gebruiken om ETH van een mainnet wallet naar L2 te sturen: [bridge.arbitrum.io](http://bridge.arbitrum.io). Aangezien de gasprijzen op Arbitrum lager zijn, zou u slechts een kleine hoeveelheid nodig moeten hebben. Het wordt aanbevolen om te beginnen met een lage drempel (e.g. 0.1 ETH) voor uw transactie om te worden goedgekeurd.
+
+## Het vinden van de Transfer Tool voor subgraphs
+
+Je kunt de L2 Transfer Tool vinden als je naar de pagina van je subgraph kijkt in de Subgraph Studio:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+Het is ook beschikbaar in de Explorer als je verbonden bent met de wallet die een subgraph bezit en op de pagina van die subgraph in de Explorer kijkt:
+
+![Transferring to L2](/img/transferToL2.png)
+
+Door op de knop 'Transfer to L2' te klikken, wordt de Transfer Tool geopend waar je het transfer proces mee kunt starten.
+
+## Stap 1: Het transfer proces starten
+
+Voordat je met het transfer proces begint, moet je beslissen welk adres de subgraph op L2 zal bezitten (zie "Je L2 portemonnee kiezen" hierboven), en het wordt sterk aanbevolen om al wat ETH voor gas op Arbitrum te hebben (zie "Voorbereiden op de overdracht: ETH verplaatsen van L1 naar L2" hierboven).
+
+Let ook op dat het overzetten van de subgraph vereist dat je een hoeveelheid signaal groter dan nul op de subgraph hebt met dezelfde account die de subgraph bezit; als je nog geen signaal op de subgraph hebt, moet je een klein beetje curatie toevoegen (een kleine hoeveelheid zoals 1 GRT zou voldoende zijn).
+
+Na het openen van de Transfer Tool, kun je het adres van de L2 wallet invoeren in het veld "Receiving wallet address" - **zorg ervoor dat je het juiste adres hier invoert**. Door op 'Transfer Subgraph' te klikken, wordt je gevraagd de transactie op je wallet uit te voeren (let op dat er wel wat ETH in je wallet zit om te betalen voor L2 gas); dit zal de transfer initiëren en je L1 subgraph verwijderen (zie "Begrijpen wat er gebeurt met signalen, de L1 subgraph en query URL's" hierboven voor meer details over wat er achter de schermen gebeurt).
+
+Als je deze stap uitvoert, **zorg ervoor dat je doorgaat tot het voltooien van stap 3 in minder dan 7 dagen, of de subgraph en je signaal GRT zullen verloren gaan.** Dit komt door hoe L1-L2 berichtgeving werkt op Arbitrum: berichten die via de bridge worden verzonden, zijn "retry-able tickets" die binnen 7 dagen uitgevoerd moeten worden, en de initiële uitvoering zou een nieuwe poging nodig kunnen hebben als er pieken zijn in de prijs voor gas op Arbitrum.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Stap 2: Wachten tot de transfer van de subgraph naar L2 voltooid is
+
+Nadat je de transfer gestart bent, moet het bericht dat je L1-subgraph naar L2 stuurt, via de Arbitrum brug worden doorgestuurd. Dit duurt ongeveer 20 minuten (de brug wacht tot het mainnet block dat de transactie bevat "veilig" is van potentiële chain reorganisaties).
+
+Zodra deze wachttijd voorbij is, zal Arbitrum proberen de transfer automatisch uit te voeren op de L2 contracten.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## Stap 3: De transfer bevestigen
+
+In de meeste gevallen zal deze stap automatisch worden uitgevoerd aangezien de L2 gas kosten die bij stap 1 zijn inbegrepen, voldoende zouden moeten zijn om de transactie die de subgraph op de Arbitrum contracten ontvangt, uit te voeren. In sommige gevallen kan het echter zo zijn dat een piek in de gasprijzen op Arbitrum ervoor zorgt dat deze automatische uitvoering mislukt. In dat geval zal het "ticket" dat je subgraph naar L2 stuurt, in behandeling blijven en is nodig het binnen 7 dagen nogmaals te proberen.
+
+Als dit het geval is, moet je verbinding maken met een L2 wallet die wat ETH op Arbitrum heeft, je walletnetwerk naar Arbitrum overschakelen en op "Bevestig Transfer" klikken op de transactie opnieuw te proberen.
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## Stap 4: De transfer op L2 afronden
+
+Na de vorige stappen zijn je subgraph en GRT ontvangen op Arbitrum, maar de subgraph is nog niet gepubliceerd. Je moet verbinding maken met de L2 wallet die je hebt gekozen als ontvangende wallet, je walletnetwerk naar Arbitrum overschakelen en op "Publiceer Subgraph" klikken
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+Dit zal de subgraph publiceren zodat Indexeerders die op Arbitrum actief zijn, deze kunnen indexeren. Het zal ook curatie signaal munten met de GRT die van L1 zijn overgedragen.
+
+## Stap 5: De query-URL bijwerken
+
+Je subgraph is succesvol overgedragen naar Arbitrum! Om query's naar de subgraph te sturen, kun je deze nieuwe URL gebruiken:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Let op dat de subgraph ID op Arbitum anders zal zijn dan degene die je op mainnet had, maar je kunt deze altijd vinden op de Explorer of in de Studio. Zoals hierboven vermeld (zie "Begrijpen wat er gebeurt met signalen, de L1 subgraph en query URL's") zal de oude L1-URL nog een korte tijd worden ondersteund, maar je zou zo snel mogelijk al je query's naar het nieuwe adres moeten overschakelen zodra de subgraph op L2 is gesynchroniseerd.
+
+## Hoe je je curatie signaal naar Arbitrum (L2) overzet
+
+## Begrijpen wat er gebeurt met curatie bij subgraph transfers naar L2
+
+Wanneer de eigenaar van een subgraph een subgraph naar Arbitrum verplaatst, wordt al het signaal van de subgraph tegelijkertijd omgezet in GRT. Dit is van toepassing op "automatisch gemigreerd" signaal, dus signaal dat niet specifiek is voor een subgraph versie, maar automatisch op de nieuwste versie van de subgraph signaleerd.
+
+De conversie van signaal naar GRT is hetzelfde als wat zou gebeuren als de eigenaar van de subgraph de subgraph van L1 zou verwijderen. Wanneer de subgraph wordt verwijderd of verplaatst wordt naar L2, wordt al het curatie signaal tegelijkertijd "verbrand" (met behulp van de curation bonding curve) en wordt de GRT vastgehouden door het GNS smart contract (dat is het contract dat subgraph upgrades en automatisch gemigreerd signaal afhandeld). Elke Curator op die subgraph heeft daarom recht op die GRT naar rato van het aantal aandelen dat ze voor de subgraph hadden.
+
+Een deel van de GRT, dat behoort tot de eigenaar van de subgraph, wordt samen met de subgraph naar L2 gestuurd.
+
+Op dit punt zal de gesignaleerde GRT niet langer query kosten verzamelen, dus curatoren kunnen kiezen om hun GRT op te nemen of het naar dezelfde subgraph op L2 over te dragen, waar het gebruikt kan worden om nieuw curatie signaal te creëren. Er is geen haast bij, aangezien de GRT voor onbepaalde tijd kan worden bewaard en iedereen krijgt een hoeveelheid naar rato van hun aandelen, ongeacht wanneer ze het doen.
+
+## Jouw L2 wallet kiezen
+
+Als je besluit je gecureerde GRT naar L2 over te dragen, kun je een andere wallet kiezen die het curatie signaal op L2 zal bezitten.
+
+Als je een "reguliere" wallet gebruikt zoals MetaMask (een Externally Owned Account of EOA, d.w.z. een wallet die geen smart contract is), dan is dit optioneel en wordt het aanbevolen om dezelfde wallet te gebruiken als in L1.
+
+Als je een smart contract wallet gebruikt, zoals een multisig (bijv. een Safe) dan is het kiezen van een ander L2 wallet adres verplicht, aangezien het waarschijnlijk is dat de multisig alleen op mainnet bestaat en je geen transacties op Arbitrum kunt maken met deze wallet. Als je een smart contract wallet of multisig wilt blijven gebruiken, maak dan een nieuwe wallet aan op Arbitrum en gebruik het adres ervan als het L2 ontvangstadres voor curatie.
+
+**Het is erg belangrijk om een wallet adres te gebruiken dat u beheert en dat transacties op Arbitrum kan uitvoeren, anders zal de curatie verloren gaan en kan niet worden hersteld.**
+
+## Je curatie naar L2 verzenden: Stap 1
+
+Voordat je de transfer start, moet je beslissen welk wallet adres de curatie op L2 zal bezitting (zie "De L2 wallet kiezen" hierboven) en wordt het aanbevolen om al wat ETH voor gas op Arbitrum te hebben voor het geval je de uitvoering van het bericht op L2 opnieuw moet uitvoeren. Je kunt ETH kopen op sommige beurzen en deze rechstreeks naar je Arbitrum wallet sturen, of je kunt de Arbitrum bridge gebruiken om ETH van een mainnet wallet naar L2 te sturen: [bridge.arbitrum.io](http://bridge.arbitrum.io) - aangezien de gasprijzen op Arbitrum zo laag zijn, heb je waarschijnlijk maar een kleine hoeveelheid nodig, 0.01 ETH is waarschijnlijk meer dan genoeg.
+
+Als een subgraph waar je curatie signaal op hebt naar L2 is verstuurd, zie je een bericht op de Explorer die je verteld dat je curatie hebt op een subgraph die een transfer heeft gemaakt naar L2.
+
+Wanneer je naar de subgraph pagina kijkt, kun je ervoor kiezen om de curatie op te nemen of over te dragen naar L2. Door op "Transfer Signal to Arbitrum" te klikken, worden de Transfer Tools geopend.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+Na het openen van de Transfer Tool, kun je worden gevraagd om wat ETH aan je wallet toe te voegen als je dat nog niet hebt. Vervolgens kun je het L2 wallet adres invoeren in het veld "Receiving wallet address" - **zorg ervoor dat je het juiste adres hier invoert.** Door op Transfer Signal te klikken, word je gevraagd de transactie op je wallet uit te voeren (let op, sommige ETH is inbegrepen om voor L2 gas te betalen); dit zal de transfer starten.
+
+Als je deze stap uitvoert, **zorg ervoor dat je doorgaat tot het voltooien van stap 3 in minder dan 7 dagen, of je signaal GRT zullen verloren gaan.** Dit komt door hoe L1-L2 berichtgeving werkt op Arbitrum: berichten die via de brug worden verzonen, zijn "retry-able tickets" die binnen 7 dagen uitgevoerd moeten worden, en de initiële uitvoering zou een nieuwe poging nodig kunnen hebben als er pieken zijn in de prijs voor gas op Arbitrum.
+
+## Jouw curatie naar L2 verzenden: Stap 2
+
+De transfer starten:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+Nadat je de transfer gestart bent, moet het bericht dat je L1-curatie naar L2 stuurt, via de Arbitrum brug worden doorgestuurd. Dit duurt ongeveer 20 minuten (de brug wacht tot het mainnet block dat de transactie bevat "veilig" is van potentiële chain reorganisaties).
+
+Zodra deze wachttijd voorbij is, zal Arbitrum proberen de transfer automatisch uit te voeren op de L2 contracten.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Je curatie naar L2 verzenden: Stap 3
+
+In de meeste gevallen zal deze stap automatisch worden uitgevoerd aangezien de L2 gas kosten die bij stap 1 zijn inbegrepen, voldoende zouden moeten zijn om de transactie die de curatie op de Arbitrum contracten ontvangt, uit te voeren. In sommige gevallen kan het echter zo zijn dat een piek in de gasprijzen op Arbitrum ervoor zorgt dat deze automatische uitvoering mislukt. In dat geval zal het "ticket" dat je curatie naar L2 stuurt, in behandeling blijven en is nodig het binnen 7 dagen nogmaals te proberen.
+
+Als dit het geval is, moet je verbinding maken met een L2 wallet die wat ETH op Arbitrum heeft, je walletnetwerk naar Arbitrum overschakelen en op "Bevestig Transfer" klikken op de transactie opnieuw te proberen.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Jouw curatie opnemen op L1
+
+Als je je GRT liever niet naar L2 stuurt, of als je de GRT handmatig over de brug wilt sturen, kunt je je gecureerde GRT op L1 opnemen. Kies op de banner op de subgraph pagina "Withdraw Signal" en bevestig de transactie; de GRT wordt naar uw Curator adres gestuurd.

From a284e1d859e58ce0afe208e9cdab14fb4e56d758 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:17 -0500
Subject: [PATCH 1054/3820] New translations l2-transfer-tools-guide.mdx
 (Polish)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/pl/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/pl/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/pl/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..e34be5cd3931
--- /dev/null
+++ b/website/pages/pl/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: Przewodnik po narzędziach przesyłania L2
+---
+
+Graph ułatwił przeniesienie danych do L2 na Arbitrum One. Dla każdego uczestnika protokołu dostępny jest zestaw narzędzi do przesyłania na L2, dzięki którym przeniesienie do L2 jest bezproblemowe dla wszystkich uczestników sieci. Narzędzia te wymagają wykonania określonego zestawu kroków w zależności od przenoszonych danych.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## Jak przenieść swój subgraph do Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Benefits of transferring your subgraphs
+
+Społeczność i deweloperzy Graph [przygotowywali się](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) do przejścia na Arbitrum w ciągu ostatniego roku. Arbitrum, blockchain warstwy 2 lub "L2", dziedziczy bezpieczeństwo po Ethereum, ale zapewnia znacznie niższe opłaty za gaz.
+
+When you publish or upgrade your subgraph to The Graph Network, you're interacting with smart contracts on the protocol and this requires paying for gas using ETH. By moving your subgraphs to Arbitrum, any future updates to your subgraph will require much lower gas fees. The lower fees, and the fact that curation bonding curves on L2 are flat, also make it easier for other Curators to curate on your subgraph, increasing the rewards for Indexers on your subgraph. This lower-cost environment also makes it cheaper for Indexers to index and serve your subgraph. Indexing rewards will be increasing on Arbitrum and decreasing on Ethereum mainnet over the coming months, so more and more Indexers will be transferring their stake and setting up their operations on L2.
+
+## Understanding what happens with signal, your L1 subgraph and query URLs
+
+Transferring a subgraph to Arbitrum uses the Arbitrum GRT bridge, which in turn uses the native Arbitrum bridge, to send the subgraph to L2. The "transfer" will deprecate the subgraph on mainnet and send the information to re-create the subgraph on L2 using the bridge. It will also include the subgraph owner's signaled GRT, which must be more than zero for the bridge to accept the transfer.
+
+When you choose to transfer the subgraph, this will convert all of the subgraph's curation signal to GRT. This is equivalent to "deprecating" the subgraph on mainnet. The GRT corresponding to your curation will be sent to L2 together with the subgraph, where they will be used to mint signal on your behalf.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph. If a subgraph owner does not transfer their subgraph to L2 and manually deprecates it via a contract call, then Curators will be notified and will be able to withdraw their curation.
+
+As soon as the subgraph is transferred, since all curation is converted to GRT, Indexers will no longer receive rewards for indexing the subgraph. However, there will be Indexers that will 1) keep serving transferred subgraphs for 24 hours, and 2) immediately start indexing the subgraph on L2. Since these Indexers already have the subgraph indexed, there should be no need to wait for the subgraph to sync, and it will be possible to query the L2 subgraph almost immediately.
+
+Queries to the L2 subgraph will need to be done to a different URL (on `arbitrum-gateway.thegraph.com`), but the L1 URL will continue working for at least 48 hours. After that, the L1 gateway will forward queries to the L2 gateway (for some time), but this will add latency so it is recommended to switch all your queries to the new URL as soon as possible.
+
+## Choosing your L2 wallet
+
+When you published your subgraph on mainnet, you used a connected wallet to create the subgraph, and this wallet owns the NFT that represents this subgraph and allows you to publish updates.
+
+When transferring the subgraph to Arbitrum, you can choose a different wallet that will own this subgraph NFT on L2.
+
+If you're using a "regular" wallet like MetaMask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same owner address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 owner of your subgraph.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum. Otherwise, the subgraph will be lost and cannot be recovered.**
+
+## Preparing for the transfer: bridging some ETH
+
+Transferring the subgraph involves sending a transaction through the bridge, and then executing another transaction on Arbitrum. The first transaction uses ETH on mainnet, and includes some ETH to pay for gas when the message is received on L2. However, if this gas is insufficient, you will have to retry the transaction and pay for the gas directly on L2 (this is "Step 3: Confirming the transfer" below). This step **must be executed within 7 days of starting the transfer**. Moreover, the second transaction ("Step 4: Finishing the transfer on L2") will be done directly on Arbitrum. For these reasons, you will need some ETH on an Arbitrum wallet. If you're using a multisig or smart contract account, the ETH will need to be in the regular (EOA) wallet that you are using to execute the transactions, not on the multisig wallet itself.
+
+You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Since gas fees on Arbitrum are lower, you should only need a small amount. It is recommended that you start at a low threshold (0.e.g. 01 ETH) for your transaction to be approved.
+
+## Finding the subgraph Transfer Tool
+
+You can find the L2 Transfer Tool when you're looking at your subgraph's page on Subgraph Studio:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+It is also available on Explorer if you're connected with the wallet that owns a subgraph and on that subgraph's page on Explorer:
+
+![Transferring to L2](/img/transferToL2.png)
+
+Clicking on the Transfer to L2 button will open the transfer tool where you can start the transfer process.
+
+## Step 1: Starting the transfer
+
+Before starting the transfer, you must decide which address will own the subgraph on L2 (see "Choosing your L2 wallet" above), and it is strongly recommend having some ETH for gas already bridged on Arbitrum (see "Preparing for the transfer: bridging some ETH" above).
+
+Also please note transferring the subgraph requires having a nonzero amount of signal on the subgraph with the same account that owns the subgraph; if you haven't signaled on the subgraph you will have to add a bit of curation (adding a small amount like 1 GRT would suffice).
+
+After opening the Transfer Tool, you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Subgraph will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer and deprecate your L1 subgraph (see "Understanding what happens with signal, your L1 subgraph and query URLs" above for more details on what goes on behind the scenes).
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or the subgraph and your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retry-able tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Step 2: Waiting for the subgraph to get to L2
+
+After you start the transfer, the message that sends your L1 subgraph to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## Step 3: Confirming the transfer
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the subgraph on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your subgraph to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## Step 4: Finishing the transfer on L2
+
+At this point, your subgraph and GRT have been received on Arbitrum, but the subgraph is not published yet. You will need to connect using the L2 wallet that you chose as the receiving wallet, switch your wallet network to Arbitrum, and click "Publish Subgraph."
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+This will publish the subgraph so that Indexers that are operating on Arbitrum can start serving it. It will also mint curation signal using the GRT that were transferred from L1.
+
+## Step 5: Updating the query URL
+
+Your subgraph has been successfully transferred to Arbitrum! To query the subgraph, the new URL will be :
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Note that the subgraph ID on Arbitrum will be a different than the one you had on mainnet, but you can always find it on Explorer or Studio. As mentioned above (see "Understanding what happens with signal, your L1 subgraph and query URLs") the old L1 URL will be supported for a short while, but you should switch your queries to the new address as soon as the subgraph has been synced on L2.
+
+## How to transfer your curation to Arbitrum (L2)
+
+## Understanding what happens to curation on subgraph transfers to L2
+
+When the owner of a subgraph transfers a subgraph to Arbitrum, all of the subgraph's signal is converted to GRT at the same time. This applies to "auto-migrated" signal, i.e. signal that is not specific to a subgraph version or deployment but that follows the latest version of a subgraph.
+
+This conversion from signal to GRT is the same as what would happen if the subgraph owner deprecated the subgraph in L1. When the subgraph is deprecated or transferred, all curation signal is "burned" simultaneously (using the curation bonding curve) and the resulting GRT is held by the GNS smart contract (that is the contract that handles subgraph upgrades and auto-migrated signal). Each Curator on that subgraph therefore has a claim to that GRT proportional to the amount of shares they had for the subgraph.
+
+A fraction of these GRT corresponding to the subgraph owner is sent to L2 together with the subgraph.
+
+At this point, the curated GRT will not accrue any more query fees, so Curators can choose to withdraw their GRT or transfer it to the same subgraph on L2, where it can be used to mint new curation signal. There is no rush to do this as the GRT can be help indefinitely and everybody gets an amount proportional to their shares, irrespective of when they do it.
+
+## Choosing your L2 wallet
+
+If you decide to transfer your curated GRT to L2, you can choose a different wallet that will own the curation signal on L2.
+
+If you're using a "regular" wallet like Metamask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same Curator address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 receiving wallet address.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum, as otherwise the curation will be lost and cannot be recovered.**
+
+## Sending curation to L2: Step 1
+
+Before starting the transfer, you must decide which address will own the curation on L2 (see "Choosing your L2 wallet" above), and it is recommended having some ETH for gas already bridged on Arbitrum in case you need to retry the execution of the message on L2. You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - since gas fees on Arbitrum are so low, you should only need a small amount, e.g. 0.01 ETH will probably be more than enough.
+
+If a subgraph that you curate to has been transferred to L2, you will see a message on Explorer telling you that you're curating to a transferred subgraph.
+
+When looking at the subgraph page, you can choose to withdraw or transfer the curation. Clicking on "Transfer Signal to Arbitrum" will open the transfer tool.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+After opening the Transfer Tool, you may be prompted to add some ETH to your wallet if you don't have any. Then you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Signal will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer.
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retryable tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+## Sending curation to L2: step 2
+
+Starting the transfer:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+After you start the transfer, the message that sends your L1 curation to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Sending curation to L2: step 3
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the curation on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your curation to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Withdrawing your curation on L1
+
+If you prefer not to send your GRT to L2, or you'd rather bridge the GRT manually, you can withdraw your curated GRT on L1. On the banner on the subgraph page, choose "Withdraw Signal" and confirm the transaction; the GRT will be sent to your Curator address.

From b4884dd3fc7f9dabe04b34f2a4590215d68e4fe9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:18 -0500
Subject: [PATCH 1055/3820] New translations l2-transfer-tools-guide.mdx
 (Portuguese)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/pt/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/pt/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/pt/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..a6f2bd42c1a5
--- /dev/null
+++ b/website/pages/pt/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: Guia das Ferramentas de Transferência para L2
+---
+
+O The Graph facilitou muito o processo de se mudar para a L2 no Arbitrum One. Para cada participante no protocolo, há um conjunto de Ferramentas de Transferência para L2 que suavizam o processo para todos os participantes na rede. Estas ferramentas exigem que você siga um conjunto específico de passos, dependente no que você transferir.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## Como transferir o seu subgraph ao Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Benefícios de transferir os seus subgraphs
+
+A comunidade e os programadores centrais do The Graph andaram [preparando](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) as suas mudanças ao Arbitrum ao longo do último ano. O Arbitrum, uma blockchain layer 2, ou "L2", herda a segurança do Ethereum, mas providencia taxas de gas muito menores.
+
+Ao publicar ou atualizar o seu subgraph na Graph Network, você interaje com contratos inteligentes no protocolo, e isto exige o pagamento de gas usando ETH. Ao mover os seus subgraphs ao Arbitrum, quaisquer atualizações futuras ao seu subgraph exigirão taxas de gas muito menores. As taxas menores, e o fato de que bonding curves de curadoria na L2 são planas, também facilitarão a curadoria no seu subgraph para outros Curadores, a fim de aumentar as recompensas para Indexadores no seu subgraph. Este ambiente de custo reduzido também barateia a indexação e o serviço de Indexadores no seu subgraph. As recompensas de indexação também aumentarão no Arbitrum e decairão na mainnet do Ethereum nos próximos meses, então mais e mais Indexadores transferirão o seu stake e preparando as suas operações na L2.
+
+## Como entender o que acontece com o sinal, o seu subgraph na L1 e URLs de query
+
+Transferir um subgraph ao Arbitrum usa a bridge de GRT do Arbitrum, que por sua vez usa a bridge nativa do Arbitrum, para enviar o subgraph à L2. A "transferência" depreciará o subgraph na mainnet e enviará a informação para recriar o subgraph na L2 com o uso da bridge. Ele também incluirá o GRT sinalizado do dono do subgraph, que deve ser maior que zero para que a bridge aceite a transferência.
+
+Ao escolher transferir o subgraph, isto converterá todo o sinal de curadoria do subgraph em GRT. Isto é equivalente à "depreciação" do subgraph na mainnet. O GRT correspondente à sua curadoria será enviado à L2 junto com o subgraph, onde ele será usado para mintar sinais em seu nome.
+
+Outros Curadores podem escolher retirar a sua fração de GRT, ou também transferi-la à L2 para mintar sinais no mesmo subgraph. Se um dono de subgraph não transferir o seu subgraph à L2 e depreciá-lo manualmente através de uma chamada de contrato, os Curadores serão notificados, e poderão retirar a sua curadoria.
+
+Assim que o subgraph for transferido, como toda curadoria é convertida em GRT, Indexadores não receberão mais recompensas por indexar o subgraph. Porém, haverão Indexadores que 1) continuarão a servir subgraphs transferidos por 24 horas, e 2) começarão imediatamente a indexar o subgraph na L2. Como estes Indexadores já têm o subgraph indexado, não deve haver necessidade de esperar que o subgraph se sincronize, e será possível consultar o subgraph na L2 quase que imediatamente.
+
+Queries no subgraph na L2 deverão ser feitas para uma URL diferente (or 'arbitrum-gateway.thegraph'), mas a URL na L1 continuará a trabalhar por no mínimo 48 horas. Após isto, o gateway na L1 encaminhará queries ao gateway na L2 (por um certo tempo), mas isto adicionará latência, então é recomendado trocar todas as suas queries para a nova URL o mais rápido possível.
+
+## Como escolher a sua carteira na L2
+
+Ao publicar o seu subgraph na mainnet, você usou uma carteira conectada para criar o subgraph, e esta carteira é dona do NFT que representa este subgraph e lhe permite publicar atualizações.
+
+Ao transferir o subgraph ao Arbitrum, você pode escolher uma carteira diferente que será dona deste NFT de subgraph na L2.
+
+Se você usar uma carteira "regular" como o MetaMask (uma Conta de Titularidade Externa, ou EOA, por ex. uma carteira que não é um contrato inteligente), então isto é opcional, e é recomendado manter o mesmo endereço titular que o da L1.
+
+Se você usar uma carteira de contrato inteligente, como uma multisig (por ex. uma Safe), então escolher um endereço de carteira diferente na L2 é obrigatório, pois as chances são altas desta conta só existir na mainnet, e você não poderá fazer transações no Arbitrum enquanto usar esta carteira. Se quiser continuar a usar uma carteira de contrato inteligente ou multisig, crie uma nova carteira no Arbitrum e use o seu endereço lá como o dono do seu subgraph na L2.
+
+**É muito importante usar um endereço de carteira que você controle, e possa fazer transações no Arbitrum. Caso contrário, o subgraph será perdido e não poderá ser recuperado.**
+
+## Preparações para a transferência: bridging de ETH
+
+Transferir o subgraph envolve o envio de uma transação através da bridge, e depois, a execução de outra transação no Arbitrum. A primeira transação usa ETH na mainnet, e inclui um pouco de ETH para pagar por gas quando a mensagem for recebida na L2. Porém, se este gas for insuficiente, você deverá tentar executar a transação novamente e pagar o gas diretamente na L2 (este é o terceiro passo: "Confirmação da transação" abaixo). Este passo **deve ser executado até 7 dias depois do início da transação**. Além disto, a segunda transação ("4º passo: Finalização da transferência na L2") será feita diretamente no Arbitrum. Por estas razões, você precisará de um pouco de ETH em uma carteira Arbitrum. Se usar uma multisig ou uma conta de contrato inteligente, o ETH deverá estar na carteira regular (EOA) que você usar para executar as transações, e não na própria carteira multisig.
+
+Você pode comprar ETH em algumas exchanges e retirá-la diretamente no Arbitrum, ou você pode usar a bridge do Arbitrum para enviar ETH de uma carteira na mainnet para a L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Como as taxas de gas no Arbitrum são menores, você só deve precisar de uma quantidade pequena. É recomendado começar em um limite baixo (por ex. 0.01 ETH) para que a sua transação seja aprovada.
+
+## Como encontrar a Ferramenta de Transferência de Subgraphs
+
+A Ferramenta de Transferência para L2 pode ser encontrada ao olhar a página do seu subgraph no Subgraph Studio:
+
+![ferramenta de transferência](/img/L2-transfer-tool1.png)
+
+Ela também está disponível no Explorer se você se conectar com a carteira dona de um subgraph, e na página daquele subgraph no Explorer:
+
+![Transferência para L2](/img/transferToL2.png)
+
+Clicar no botão Transfer to L2 (Transferir para L2) abrirá a ferramenta de transferências, onde você poderá começar o processo.
+
+## 1º Passo: Como começar a transferência
+
+Antes de começar a transferência, decida qual endereço será dono do subgraph na L2 (ver "Como escolher a sua carteira na L2" acima), e é altamente recomendado ter um pouco de ETH para o gas já em bridge no Arbitrum (ver "Preparações para a transferência: bridging de ETH" acima).
+
+Note também que transferir o subgraph exige ter uma quantidade de sinal no subgraph maior que zero, com a mesma conta dona do subgraph; se você não tiver sinalizado no subgraph, você deverá adicionar um pouco de curadoria (uma adição pequena, como 1 GRT, seria o suficiente).
+
+Após abrir a Ferramenta de Transferências, você poderá colocar o endereço da carteira na L2 no campo "Receiving wallet address" (endereço da carteira destinatária) - **certifique-se que inseriu o endereço correto**. Clicar em Transfer Subgraph (transferir subgraph) resultará em um pedido para executar a transação na sua carteira (note que um valor em ETH é incluído para pagar pelo gas na L2); isto iniciará a transferência e depreciará o seu subgraph na L1 (veja "Como entender o que acontece com o sinal, o seu subgraph na L1 e URLs de query" acima para mais detalhes sobre o que acontece nos bastidores).
+
+Ao executar este passo, **garanta que executará o 3º passo em menos de 7 dias, ou o subgraph e o seu GRT de sinalização serão perdidos.** Isto se deve à maneira de como as mensagens L1-L2 funcionam no Arbitrum: mensagens enviadas através da bridge são "bilhetes de tentativas extras" que devem ser executadas dentro de 7 dias, e a execução inicial pode exigir outra tentativa se houver um surto no preço de gas no Arbitrum.
+
+![Comece a transferência à L2](/img/startTransferL2.png)
+
+## 2º Passo: A espera do caminho do subgraph até a L2
+
+Após iniciar a transferência, a mensagem que envia o seu subgraph da L1 para a L2 deve propagar pela bridge do Arbitrum. Isto leva cerca de 20 minutos (a bridge espera que o bloco da mainnet que contém a transação esteja "seguro" de reorganizações potenciais da chain).
+
+Quando esta espera acabar, o Arbitrum tentará executar a transferência automaticamente nos contratos na L2.
+
+![Tela de espera](/img/screenshotOfWaitScreenL2.png)
+
+## 3º Passo: Como confirmar a transferência
+
+Geralmente, este passo será executado automaticamente, já que o gas na L2 incluído no primeiro passo deverá ser suficiente para executar a transação que recebe o subgraph nos contratos do Arbitrum. Porém, em alguns casos, é possível que um surto nos preços de gas do Arbitrum faça com que esta execução automática falhe. Neste caso, o "bilhete" que envia o seu subgraph à L2 estará pendente e exigirá outra tentativa dentro de 7 dias.
+
+Se este for o caso, você deverá se conectar com uma carteira L2 que tenha um pouco de ETH no Arbitrum, trocar a rede da sua carteira para Arbitrum, e clicar em "Confirmar Transferência" para tentar a transação novamente.
+
+![Confirme a transferência à L2](/img/confirmTransferToL2.png)
+
+## 4º Passo: A finalização da transferência à L2
+
+Até aqui, o seu subgraph e GRT já foram recebidos no Arbitrum, mas o subgraph ainda não foi publicado. Você deverá se conectar com a carteira L2 que escolheu como a carteira destinatária, trocar a rede da carteira para Arbitrum, e clicar em "Publish Subgraph" (Publicar Subgraph).
+
+![Publicação do subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Espera para a publicação do subgraph](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+Isto publicará o subgraph de forma que Indexadores operantes no Arbitrum comecem a servi-lo. Ele também mintará sinais de curadoria com o GRT que foi transferido da L1.
+
+## 5º passo: Atualização da URL de query
+
+Parabéns, o seu subgraph foi transferido ao Arbitrum com êxito! Para consultar o subgraph, a nova URL será:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Note que a ID do subgraph no Arbitrum será diferente daquela que você tinha na mainnet, mas você pode sempre encontrá-la no Explorer ou no Studio. Como mencionado acima (ver "Como entender o que acontece com o sinal, o seu subgraph na L1 e URLs de query"), a URL antiga na L1 será apoiada por um período curto, mas você deve trocar as suas queries para o novo endereço assim que o subgraph for sincronizado na L2.
+
+## Como transferir a sua curadoria ao Arbitrum (L2)
+
+## Como entender o que acontece com a curadoria ao transferir um subgraph à L2
+
+Quando o dono de um subgraph transfere um subgraph ao Arbitrum, todo o sinal do subgraph é convertido em GRT ao mesmo tempo. Isto se aplica a sinais "migrados automaticamente", por ex. sinais que não forem específicos a uma versão de um subgraph ou publicação, mas que segue a versão mais recente de um subgraph.
+
+Esta conversão do sinal ao GRT é a mesma que aconteceria se o dono de um subgraph depreciasse o subgraph na L1. Quando o subgraph é depreciado ou transferido, todo o sinal de curadoria é "queimado" em simultâneo (com o uso da bonding curve de curadoria) e o GRT resultante fica em posse do contrato inteligente GNS (sendo o contrato que cuida de atualizações de subgraph e sinais migrados automaticamente). Cada Curador naquele subgraph então tem um direito àquele GRT, proporcional à quantidade de ações que tinham no subgraph.
+
+Uma fração deste GRT correspondente ao dono do subgraph é enviado à L2 junto com o subgraph.
+
+Neste ponto, o GRT curado não acumulará mais taxas de query, então Curadores podem escolher sacar o seu GRT ou transferi-lo ao mesmo subgraph na L2, onde ele pode ser usado para mintar novos sinais de curadoria. Não há pressa para fazer isto, já que o GRT pode ser possuído por tempo indeterminado, e todos conseguem uma quantidade proporcional às suas ações, irrespectivo de quando a fizerem.
+
+## Como escolher a sua carteira na L2
+
+Caso você decida transferir o seu GRT curado à L2, você pode escolher uma carteira diferente que será titular do sinal de curadoria na L2.
+
+Se você usar uma carteira "regular" como o MetaMask (uma Conta de Titularidade Externa, ou EOA, por ex. uma carteira que não é um contrato inteligente), então isto é opcional, e é recomendado manter o mesmo endereço de curadoria que o da L1.
+
+Se você usar uma carteira de contrato inteligente, como uma multisig (por ex. uma Safe), então escolher um endereço de carteira diferente na L2 é obrigatório, pois as chances são altas desta conta só existir na mainnet, e você não poderá fazer transações no Arbitrum enquanto usar esta carteira. Se quiser continuar a usar uma carteira de contrato inteligente ou multisig, crie uma nova carteira no Arbitrum e use o seu endereço lá como o endereço destinatário na L2.
+
+**É muito importante usar um endereço de carteira que você controle, e possa fazer transações no Arbitrum. Caso contrário, a curadoria será perdida e não poderá ser recuperada.**
+
+## 1º Passo: Como enviar curadoria à L2
+
+Antes de iniciar a transferência, você deve decidir qual endereço será titular da curadoria na L2 (ver "Como escolher a sua carteira na L2" acima), e é recomendado ter um pouco de ETH para o gas já em bridge no Arbitrum, caso seja necessário tentar a execução da mensagem na L2 novamente. Você pode comprar ETH em algumas exchanges e retirá-lo diretamente no Arbitrum, ou você pode usar a bridge do Arbitrum para enviar ETH de uma carteira na mainnet à L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - como as taxas de gas no Arbitrum são menores, você só deve precisar de uma quantidade pequena; por ex. 0.01 ETH deve ser mais que o suficiente.
+
+Se um subgraph para o qual você cura já foi transferido para a L2, você verá uma mensagem no Explorer lhe dizendo que você curará para um subgraph transferido.
+
+Ao olhar a página do subgraph, você pode escolher retirar ou transferir a curadoria. Clicar em "Transfer Signal to Arbitrum" (transferir sinal ao Arbitrum) abrirá a ferramenta de transferência.
+
+![Transferir sinall](/img/transferSignalL2TransferTools.png)
+
+Após abrir a Ferramenta de Transferências, você pode receber um pedido para colocar ETH na sua carteira se não tiver nenhum. Depois, você poderá colocar o endereço da carteira na L2 no campo "Receiving wallet address" (endereço da carteira destinatária) - **certifique-se que inseriu o endereço correto**. Clicar em Transfer Signal (transferir sinal) resultará em um pedido para executar a transação na sua carteira (note que um valor em ETH é incluído para pagar pelo gas na L2); isto iniciará a transferência.
+
+Ao executar este passo, **garanta que executará o 3º passo em menos de 7 dias, ou o seu GRT de sinalização será perdido.** Isto se deve à maneira de como as mensagens L1-L2 funcionam no Arbitrum: mensagens enviadas através da bridge são "bilhetes de tentativas extras" que devem ser executadas dentro de 7 dias, e a execução inicial pode exigir outra tentativa se houver um surto no preço de gas no Arbitrum.
+
+## 2º Passo: Como enviar curadoria à L2
+
+Como começar a transferência:
+
+![Envio de sinal à L2](/img/sendingCurationToL2Step2First.png)
+
+Após iniciar a transferência, a mensagem que envia a sua curadoria da L1 para a L2 deve propagar pela bridge do Arbitrum. Isto leva cerca de 20 minutos (a bridge espera que o bloco da mainnet que contém a transação esteja "seguro" de reorganizações potenciais da chain).
+
+Quando esta espera acabar, o Arbitrum tentará executar a transferência automaticamente nos contratos na L2.
+
+![Envio de sinal de curadoria à L2](/img/sendingCurationToL2Step2Second.png)
+
+## 3º Passo: Como enviar curadoria à L2
+
+Geralmente, este passo será executado automaticamente, já que o gas na L2 incluído no primeiro passo deverá ser suficiente para executar a transação que recebe a curadoria nos contratos do Arbitrum. Porém, em alguns casos, é possível que um surto nos preços de gas do Arbitrum faça com que esta execução automática falhe. Neste caso, o "bilhete" que envia a sua curadoria à L2 estará pendente e exigirá outra tentativa dentro de 7 dias.
+
+Se este for o caso, você deverá se conectar com uma carteira L2 que tenha um pouco de ETH no Arbitrum, trocar a rede da sua carteira para Arbitrum, e clicar em "Confirmar Transferência" para tentar a transação novamente.
+
+![Envio de sinal à L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Como retirar a sua curadoria na L1
+
+Se preferir não enviar o seu GRT à L2, ou preferir fazer um bridge do GRT de forma manual, você pode retirar o seu GRT curado na L1. No banner da página do subgraph, escolha "Withdraw Signal" (Retirar Sinal) e confirme a transação; o GRT será enviado ao seu endereço de Curador.

From 898b75f452ba81c1285cfa13fcdadacbf1117d77 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:19 -0500
Subject: [PATCH 1056/3820] New translations l2-transfer-tools-guide.mdx
 (Russian)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/ru/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/ru/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/ru/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..a1e368df07a3
--- /dev/null
+++ b/website/pages/ru/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: Руководство по инструментам переноса L2
+---
+
+The Graph упростил переход на L2 в Arbitrum One. Для каждого участника протокола существует набор инструментов переноса L2, чтобы сделать переход на L2 бесшовным для всех участников сети. Эти инструменты потребуют от Вас выполнения определенного набора шагов в зависимости от того, что Вы передаете.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## Как перенести свой субграф в Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Преимущества переноса Ваших субграфов
+
+Сообщество и разработчики ядра The Graph [готовились](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) к переходу на Arbitrum в течение прошлого года. Arbitrum, блокчейн уровня 2 или «L2», наследует безопасность от Ethereum, но обеспечивает значительно более низкую комиссию сети.
+
+Когда Вы публикуете или обновляете свой субграф до The Graph Network, Вы взаимодействуете со смарт-контрактами по протоколу, и для этого требуется проплачивать комиссию сети с помощью ETH. После перемещения Ваших субграфов в Arbitrum, любые будущие обновления Вашего субграфа потребуют гораздо более низких сборов за комиссию сети. Более низкие сборы и тот факт, что кривые связи курирования на L2 ровные, также облегчают другим кураторам курирование Вашего субграфа, увеличивая вознаграждение для индексаторов в Вашем субграфе. Эта менее затратная среда также упрощает индексацию и обслуживание Вашего субграфа. В ближайшие месяцы вознаграждения за индексацию в Arbitrum будут увеличиваться, а в основной сети Ethereum уменьшаться, поэтому все больше и больше индексаторов будут переводить свои стейки и настраивать операции на L2.
+
+## Понимание того, что происходит с сигналом, Вашим субграфом L1 и URL-адресами запроса
+
+Для передачи субграфа в Arbitrum используется мост Arbitrum GRT, который, в свою очередь, использует собственный мост Arbitrum для отправки субграфа на L2. «Перенос» отменяет поддержку субграфа в основной сети и отправляет информацию для повторного создания субграфа на L2 с использованием моста. Он также будет включать сигнал GRT владельца субграфа, который должен быть больше нуля, чтобы мост смог принять передачу.
+
+Когда Вы решите передать субграф, весь сигнал курирования подграфа будет преобразован в GRT. Это эквивалентно «прекращению поддержки» субграфа в основной сети. GRT, соответствующие Вашему кураторству, будут отправлен на L2 вместе с субграфом, где они будут использоваться для производства сигнала от Вашего имени.
+
+Другие Кураторы могут выбрать, вывести ли свою долю GRT или также перевести ее в L2 для производства сигнала на том же субграфе. Если владелец субграфа не перенесет свой субграф в L2 и вручную аннулирует его с помощью вызова контракта, то Кураторы будут уведомлены и смогут отозвать свое курирование.
+
+Индексаторы больше не будут получать вознаграждение за индексирование субграфа, как только субграф будет перенесён, так как всё курирование конвертируется в GRT. Однако будут индексаторы, которые 1) продолжат обслуживать переданные субграфы в течение 24 часов и 2) немедленно начнут индексировать субграф на L2. Поскольку эти индексаторы уже проиндексировали субграф, не нужно будет ждать синхронизации субграфа, и можно будет запросить субграф L2 практически сразу.
+
+Запросы к субграфу L2 необходимо будет выполнять по другому URL-адресу (на `arbitrum-gateway.thegraph.com`), но URL-адрес L1 будет продолжать работать в течение как минимум 48 часов. После этого шлюз L1 будет перенаправлять запросы на шлюз L2 (на некоторое время), но это увеличит задержку, поэтому рекомендуется как можно скорее переключить все Ваши запросы на новый URL-адрес.
+
+## Выбор Вашего кошелька L2
+
+Когда Вы опубликовали свой субграф в основной сети, Вы использовали подключенный кошелек для его создания, и этот кошелек обладает NFT, который представляет этот субграф и позволяет Вам публиковать обновления.
+
+При переносе субграфа в Arbitrum Вы можете выбрать другой кошелек, которому будет принадлежать этот NFT субграфа на L2.
+
+Если Вы используете «обычный» кошелек, такой как MetaMask (Externally Owned Account или EOA, то есть кошелек, который не является смарт-контрактом), тогда это необязательно, и рекомендуется сохранить тот же адрес владельца, что и в L1.
+
+Если Вы используете смарт-контрактный кошелек, такой как кошелёк с мультиподписью (например, Safe), то выбор другого адреса кошелька L2 является обязательным, так как, скорее всего, эта учетная запись существует только в основной сети, и Вы не сможете совершать транзакции в сети Arbitrum с помощью этого кошелька. Если Вы хотите продолжать использовать кошелек смарт-контрактов или мультиподпись, создайте новый кошелек на Arbitrum и используйте его адрес в качестве владельца L2 Вашего субграфа.
+
+**Очень важно использовать адрес кошелька, которым Вы управляете и с которого можно совершать транзакции в Arbitrum. В противном случае субграф будет потерян и его невозможно будет восстановить.**
+
+## Подготовка к переносу: использование моста с некоторым количеством ETH
+
+Передача субграфа включает в себя отправку транзакции через мост, а затем выполнение другой транзакции в Arbitrum. Первая транзакция использует ETH в основной сети и включает некоторое количество ETH для оплаты комиссии сети при получении сообщения на уровне L2. Однако, если этого количества будет недостаточно, Вам придется повторить транзакцию и оплатить комиссию сети непосредственно на L2 (это «Шаг 3: Подтверждение перевода» ниже). Этот шаг **должен быть выполнен в течение 7 дней после начала переноса**. Более того, вторая транзакция («Шаг 4: Завершение перевода на L2») будет выполнена непосредственно на Arbitrum. В связи с этим Вам понадобится некоторое количество ETH на кошельке Arbitrum. Если Вы используете учетную запись с мультиподписью или смарт-контрактом, ETH должен находиться в обычном (EOA) кошельке, который Вы используете для выполнения транзакций, а не в самом кошельке с мультиподписью.
+
+Вы можете приобрести ETH на некоторых биржах и вывести его напрямую на Arbitrum, или Вы можете использовать мост Arbitrum для отправки ETH из кошелька основной сети на L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Поскольку плата за комиссию сети в Arbitrum ниже, Вам понадобится лишь небольшая сумма. Рекомендуется начинать с низкого порога (например, 0,01 ETH), чтобы Ваша транзакция была одобрена.
+
+## Поиск инструмента переноса субграфа
+
+Вы можете найти инструмент переноса L2, когда просматриваете страницу своего субграфа в Subgraph Studio:
+
+![инструмент переноса](/img/L2-transfer-tool1.png)
+
+Он также доступен в Explorer, если Вы подключены к кошельку, которому принадлежит субграф, и на странице этого субграфа в Explorer:
+
+![Перенос на L2](/img/transferToL2.png)
+
+При нажатии на кнопку «Перенести на L2» откроется инструмент переноса, в котором Вы сможете начать этот процесс.
+
+## Шаг 1: Запуск перевода
+
+Прежде чем начать перенос, Вы должны решить, какому адресу будет принадлежать субграф на L2 (см. «Выбор кошелька L2» выше), также настоятельно рекомендуется иметь некоторое количество ETH для оплаты комиссии сети за соединение мостом с Arbitrum (см. «Подготовка к переносу: использование моста с некоторым количеством ETH" выше).
+
+Также обратите внимание, что для передачи субграфа требуется наличие ненулевого количества сигнала в субграфе с той же учетной записью, которая владеет субграфом; если Вы не просигнализировали на субграфе, Вам придется добавить немного монет для курирования (достаточно добавить небольшую сумму, например 1 GRT).
+
+После открытия инструмента переноса Вы сможете ввести адрес кошелька L2 в поле «Адрес получающего кошелька» — **убедитесь, что Вы ввели здесь правильный адрес**. После нажатия на «Перевод субграфа», Вам будет предложено выполнить транзакцию в Вашем кошельке (обратите внимание, что некоторое количество ETH включено для оплаты газа L2); это инициирует передачу и отменит Ваш субграф на L1 (см. «Понимание того, что происходит с сигналом, Вашим субграфом L1 и URL-адресами запроса» выше для получения более подробной информации о том, что происходит за кулисами).
+
+Если Вы выполните этот шаг, ** убедитесь в том, что Вы завершили шаг 3 менее чем за 7 дней, иначе субграф и Ваш сигнал GRT будут утеряны.** Это связано с тем, как в Arbitrum работает обмен сообщениями L1-L2: сообщения, которые отправляются через мост, представляют собой «билеты с возможностью повторной попытки», которые должны быть выполнены в течение 7 дней, и для первоначального исполнения может потребоваться повторная попытка, если в Arbitrum будут скачки цен комиссии сети.
+
+![Запустите перенос на L2](/img/startTransferL2.png)
+
+## Шаг 2: Ожидание перехода субграфа в L2
+
+После того, как Вы начнете передачу, сообщение, которое отправляет Ваш субграф с L1 в L2, должно пройти через мост Arbitrum. Это занимает примерно 20 минут (мост ожидает, пока блок основной сети, содержащий транзакцию, будет «защищен» от потенциальных реорганизаций чейна).
+
+По истечении этого времени ожидания Arbitrum попытается автоматически выполнить перевод по контрактам L2.
+
+![Экран ожидания](/img/screenshotOfWaitScreenL2.png)
+
+## Шаг 3: Подтверждение переноса
+
+В большинстве случаев этот шаг будет выполняться автоматически, поскольку комиссии сети L2, включенной в шаг 1, должно быть достаточно для выполнения транзакции, которая получает субграф в контрактах Arbitrum. Однако в некоторых случаях возможно, что скачок цен комиссии сети на Arbitrum приведёт к сбою этого автоматического выполнения. В этом случае «тикет», который отправляет ваш субграф на L2, будет находиться в ожидании и потребует повторной попытки в течение 7 дней.
+
+В этом случае Вам нужно будет подключиться с помощью кошелька L2, в котором есть некоторое количество ETH в сети Arbitrum, переключить сеть Вашего кошелька на Arbitrum и нажать «Подтвердить перевод», чтобы повторить транзакцию.
+
+![Подтвердите перенос на L2](/img/confirmTransferToL2.png)
+
+## Шаг 4: Завершение переноса в L2
+
+На данный момент Ваш субграф и GRT получены в Arbitrum, но субграф еще не опубликован. Вам нужно будет подключиться с помощью кошелька L2, который Вы выбрали в качестве принимающего кошелька, переключить сеть Вашего кошелька на Arbitrum и нажать «Опубликовать субграф».
+
+![Опубликуйте субграф](/img/publishSubgraphL2TransferTools.png)
+
+![Дождитесь публикации субграфа](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+Субграф будет опубликован, и индексаторы, работающие на Arbitrum, смогут начать его обслуживание. Он также будет создавать сигнал курирования, используя GRT, переданные из L1.
+
+## Шаг 5. Обновление URL-адреса запроса
+
+Ваш субграф успешно перенесен в Arbitrum! Для запроса субграфа новый URL будет следующим:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Обратите внимание, что идентификатор субграфа в Arbitrum будет отличаться от того, который был у Вас в основной сети, но Вы всегда можете найти его в Explorer или Studio. Как упоминалось выше (см. «Понимание того, что происходит с сигналом, Вашим субграфом L1 и URL-адресами запроса»), старый URL-адрес L1 будет поддерживаться в течение некоторого времени, но Вы должны переключить свои запросы на новый адрес, как только субграф будет синхронизирован в L2.
+
+## Как перенести свой субграф в Arbitrum (L2)
+
+## Понимание того, что происходит с курированием передачи субграфов на L2
+
+Когда владелец субграфа передает субграф в Arbitrum, весь сигнал субграфа одновременно конвертируется в GRT. Это же относится и к "автоматически мигрировавшему" сигналу, т.е. сигналу, который не относится к конкретной версии или развертыванию субграфа, но который следует за последней версией субграфа.
+
+Это преобразование сигнала в GRT аналогично тому, что произошло бы, если бы владелец субграфа объявил его устаревшим на L1. Когда субграф устаревает или переносится, в то же время «сжигается» весь сигнал курирования (с использованием кривой связывания курирования), а полученный GRT сохраняется в смарт-контракте GNS (то есть контракте, который обрабатывает обновления субграфа и сигнал автоматической миграции). Таким образом, каждый куратор этого субграфа имеет право на GRT, пропорционально количеству акций, которыми он владел в этом субграфе.
+
+Часть этих GRT, принадлежащая владельцу субграфа, отправляется на L2 вместе с субграфом.
+
+На этом этапе курируемый GRT больше не будет начислять комиссии за запросы, поэтому кураторы могут выбрать: вывести свой GRT или перевести его на тот же субграф на L2, где его можно использовать для создания нового сигнала курирования. Спешить с этим не стоит, так как GRT может храниться неограниченное время, и каждый получит сумму пропорционально своим долям, независимо от того, когда это будет сделано.
+
+## Выбор Вашего кошелька L2
+
+Если Вы решите перевести курируемый GRT на L2, Вы можете выбрать другой кошелек, который будет владеть сигналом курирования на L2.
+
+Если Вы используете «обычный» кошелек, такой как Metamask (Externally Owned Account или EOA, то есть кошелек, который не является смарт-контрактом), тогда это необязательно, и рекомендуется сохранить тот же адрес куратора, что и в L1.
+
+Если Вы используете смарт-контрактный кошелек, такой как кошелёк с мультиподписью (например, Safe), то выбор другого адреса кошелька L2 является обязательным, так как, скорее всего, эта учетная запись существует только в основной сети, и Вы не сможете совершать транзакции в сети Arbitrum с помощью этого кошелька. Если Вы хотите продолжать использовать кошелек смарт-контрактов или мультиподпись, создайте новый кошелек на Arbitrum и используйте его адрес в качестве адреса кошелька-получателя на L2.
+
+**Очень важно использовать адрес кошелька, которым Вы управляете и с которого можно совершать транзакции в Arbitrum, в противном случае курирование будет потеряно и его невозможно будет восстановить.**
+
+## Отправка курирования на L2: шаг 1
+
+Прежде чем начать перенос, Вы должны решить, какой адрес будет владеть курированием на L2 (см. "Выбор кошелька L2" выше), также рекомендуется уже иметь на Arbitrum некоторое количество ETH для газа на случай, если Вам потребуется повторно выполнить отправку сообщения на L2. Вы можете купить ETH на любых биржах и вывести его напрямую на Arbitrum, или использовать мост Arbitrum для отправки ETH из кошелька основной сети на L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) — поскольку комиссии за газ на Arbitrum очень низкие, Вам понадобится небольшая сумма, например, 0.01 ETH, этого, вероятно, будет более чем достаточно.
+
+Если субграф, который Вы курируете, был перенесен на L2, Вы увидите сообщение в Explorer о том, что Вы курируете перенесённый субграф.
+
+При просмотре страницы субграфа Вы можете выбрать вывод или перенос курирования. Нажатие на кнопку "Перенести сигнал в Arbitrum", откроет инструмент переноса.
+
+![Перенос сигнала](/img/transferSignalL2TransferTools.png)
+
+После открытия инструмента переноса Вам может быть предложено добавить немного ETH в Ваш кошелек, если у Вас его нет. Затем Вы сможете ввести адрес кошелька L2 в поле "Адрес кошелька получения" - **убедитесь, что ввели здесь правильный адрес.** При нажатии на Сигнал перевода Вам будет предложено выполнить транзакцию в Вашем кошельке (обратите внимание, что для оплаты газа L2 включена некоторая сумма ETH); это инициирует процесс переноса.
+
+Если Вы выполните этот шаг, ** убедитесь в том, что Вы завершили шаг 3 менее чем за 7 дней, иначе Ваш сигнал GRT будет утерян.** Это связано с тем, как в Arbitrum работает обмен сообщениями L1-L2: сообщения, отправленные через мост, представляют собой «билеты с возможностью повторной попытки», которые должны быть выполнены в течение 7 дней, и для первоначального исполнения может потребоваться повторная попытка, если в Arbitrum будут скачки цен комиссии сети.
+
+## Отправка курирования на L2: шаг 2
+
+Запуск переноса:
+
+![Отправить сигнал на L2](/img/sendingCurationToL2Step2First.png)
+
+После того, как Вы начнете перенос, сообщение, которое отправляет Ваше курирование с L1 в L2, должно пройти через мост Arbitrum. Это занимает примерно 20 минут (мост ожидает, пока блок основной сети, содержащий транзакцию, будет «защищен» от потенциальных реорганизаций чейна).
+
+По истечении этого времени ожидания Arbitrum попытается автоматически выполнить перевод по контрактам L2.
+
+![Отправка сигнала курирования на L2](/img/sendingCurationToL2Step2Second.png)
+
+## Отправка курирования на L2: шаг 3
+
+В большинстве случаев этот шаг выполняется автоматически, поскольку газа L2, включенного в шаг 1, должно быть достаточно для выполнения транзакции, которая получает курирование в контрактах Arbitrum. Однако в некоторых случаях возможно, что скачок цен на газ на Arbitrum приведет к сбою автоматического выполнения. В этом случае «тикет», который отправляет Ваше курирование на L2, будет находиться в состоянии ожидания и потребует повторной попытки в течение 7 дней.
+
+В этом случае Вам нужно будет подключиться с помощью кошелька L2, в котором есть некоторое количество ETH в сети Arbitrum, переключить сеть Вашего кошелька на Arbitrum и нажать «Подтвердить перевод», чтобы повторить транзакцию.
+
+![Отправить сигнал на L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Снятие Вашего курирования на L1
+
+Если Вы предпочитаете не отправлять свой GRT на L2 или хотите передать GRT вручную, Вы можете вывести свой курируемый GRT на L1. На баннере на странице субграфа выберите "Вывести сигнал" и подтвердите транзакцию; GRT будет отправлен на Ваш адрес Куратора.

From 120f365eb1a3311536262c5eac3ffeebee6a5aa0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:20 -0500
Subject: [PATCH 1057/3820] New translations l2-transfer-tools-guide.mdx
 (Swedish)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/sv/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/sv/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/sv/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..947ffae9fd95
--- /dev/null
+++ b/website/pages/sv/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 Guide för överföringsverktyg
+---
+
+The Graph har gjort det enkelt att flytta till L2 på Arbitrum One. För varje protokolldeltagare finns det en uppsättning L2 överföringsverktyg som gör överföringen till L2 sömlös för alla nätverksdeltagare. Dessa verktyg kräver att du följer en specifik uppsättning steg beroende på vad du överför.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## Så här överför du din subgraf till Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Fördelar med att överföra dina subgrafer
+
+The Graphs community och kärnutvecklare har [förberett sig](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) för att flytta till Arbitrum under det senaste året. Arbitrum, en blockkedja av lager 2 eller "L2", ärver säkerheten från Ethereum men ger drastiskt lägre gasavgifter.
+
+När du publicerar eller uppgraderar din subgraf till The Graph Network, interagerar du med smarta kontrakt på protokollet och detta kräver att du betalar för gas med ETH. Genom att flytta dina subgrafer till Arbitrum kommer alla framtida uppdateringar av din subgraf att kräva mycket lägre gasavgifter. De lägre avgifterna, och det faktum att curation bonding-kurvorna på L2 är platta, gör det också lättare för andra curatorer att kurera på din subgraf, vilket ökar belöningarna för Indexers på din subgraf. Denna miljö med lägre kostnader gör det också billigare för indexerare att indexera och betjäna din subgraf. Indexeringsbelöningar kommer att öka på Arbitrum och minska på Ethereums mainnet under de kommande månaderna, så fler och fler indexerare kommer att överföra sin andel och sätta upp sin verksamhet på L2.
+
+## Förstå vad som händer med signal, din L1 subgraf och frågewebbadresser
+
+Att överföra en subgraf till Arbitrum använder Arbitrum GRT-bryggan, som i sin tur använder den inhemska Arbitrum-bryggan, för att skicka subgrafen till L2. "Överföringen" kommer att fasa ut subgrafen på mainnet och skicka informationen för att återskapa subgrafen på L2 med hjälp av bryggan. Den kommer också att inkludera subgrafägarens signalerade GRT, som måste vara mer än noll för att bryggan ska acceptera överföringen.
+
+När du väljer att överföra subgrafen kommer detta att konvertera hela subgrafens kurationssignal till GRT. Detta motsvarar att "avskriva" subgrafen på mainnet. GRT som motsvarar din kuration kommer att skickas till L2 tillsammans med subgrafen, där de kommer att användas för att skapa signaler å dina vägnar.
+
+Andra kuratorer kan välja om de vill ta tillbaka sin del av GRT eller också överföra den till L2 för att få en signal på samma subgraf. Om en subgrafägare inte överför sin subgraf till L2 och manuellt fasar ut den via ett kontraktsanrop, kommer Curatorer att meddelas och kommer att kunna dra tillbaka sin curation.
+
+Så snart subgrafen har överförts, eftersom all kuration konverteras till GRT, kommer indexerare inte längre att få belöningar för att indexera subgrafen. Det kommer dock att finnas indexerare som kommer 1) att fortsätta visa överförda subgrafer i 24 timmar och 2) omedelbart börja indexera subgrafen på L2. Eftersom dessa indexerare redan har subgrafen indexerad, borde det inte finnas något behov av att vänta på att subgrafen ska synkroniseras, och det kommer att vara möjligt att fråga L2-subgrafen nästan omedelbart.
+
+Förfrågningar till L2-subgrafen kommer att behöva göras till en annan URL (på `arbitrum-gateway.thegraph.com`), men L1-URL:n fortsätter att fungera i minst 48 timmar. Efter det kommer L1-gatewayen att vidarebefordra frågor till L2-gatewayen (under en tid), men detta kommer att lägga till latens så det rekommenderas att byta alla dina frågor till den nya URL:en så snart som möjligt.
+
+## Välja din L2 plånbok
+
+När du publicerade din subgraf på mainnet använde du en ansluten plånbok för att skapa subgrafen, och denna plånbok äger NFT som representerar denna subgraf och låter dig publicera uppdateringar.
+
+När du överför subgrafen till Arbitrum kan du välja en annan plånbok som kommer att äga denna subgraf NFT på L2.
+
+Om du använder en "vanlig" plånbok som MetaMask (ett externt ägt konto eller EOA, d.v.s. en plånbok som inte är ett smart kontrakt), så är detta valfritt och det rekommenderas att behålla samma ägaradress som i L1.
+
+Om du använder en smart kontraktsplånbok, som en multisig (t.ex. ett kassaskåp), är det obligatoriskt att välja en annan L2-plånboksadress, eftersom det är mest troligt att det här kontot bara finns på mainnet och att du inte kommer att kunna göra transaktioner på Arbitrum med denna plånbok. Om du vill fortsätta använda en smart kontraktsplånbok eller multisig, skapa en ny plånbok på Arbitrum och använd dess adress som L2-ägare till din subgraf.
+
+**Det är mycket viktigt att använda en plånboksadress som du kontrollerar, och som kan göra transaktioner på Arbitrum. Annars kommer subgrafen att gå förlorad och kan inte återställas.**
+
+## Förbereder för överföringen: överbrygga lite ETH
+
+Att överföra subgrafen innebär att man skickar en transaktion genom bryggan och sedan utför en annan transaktion på Arbitrum. Den första transaktionen använder ETH på huvudnätet och inkluderar en del ETH för att betala för gas när meddelandet tas emot på L2. Men om denna gas är otillräcklig måste du göra om transaktionen och betala för gasen direkt på L2 (detta är "Steg 3: Bekräfta överföringen" nedan). Detta steg **måste utföras inom 7 dagar efter att överföringen påbörjats**. Dessutom kommer den andra transaktionen ("Steg 4: Avsluta överföringen på L2") att göras direkt på Arbitrum. Av dessa skäl behöver du lite ETH på en Arbitrum-plånbok. Om du använder ett multisig- eller smart kontraktskonto måste ETH: en finnas i den vanliga (EOA) plånboken som du använder för att utföra transaktionerna, inte på själva multisig plånboken.
+
+Du kan köpa ETH på vissa börser och ta ut den direkt till Arbitrum, eller så kan du använda Arbitrum-bryggan för att skicka ETH från en mainnet-plånbok till L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Eftersom gasavgifterna på Arbitrum är lägre bör du bara behöva en liten summa. Det rekommenderas att du börjar vid en låg tröskel (0.t.ex. 01 ETH) för att din transaktion ska godkännas.
+
+## Hitta subgrafen Överföringsverktyg
+
+Du kan hitta L2 Överföringsverktyg när du tittar på din subgrafs sida på Subgraf Studio:
+
+![Överföringsverktyg](/img/L2-transfer-tool1.png)
+
+Den är också tillgänglig på Explorer om du är ansluten till plånboken som äger en subgraf och på den subgrafens sida på Explorer:
+
+![Överför till L2](/img/transferToL2.png)
+
+Genom att klicka på knappen Överför till L2 öppnas överföringsverktyget där du kan starta överföringsprocessen.
+
+## Steg 1: Starta överföringen
+
+Innan du påbörjar överföringen måste du bestämma vilken adress som ska äga subgrafen på L2 (se "Välja din L2 plånbok" ovan), och det rekommenderas starkt att ha lite ETH för gas som redan är överbryggad på Arbitrum (se "Förbereda för överföringen: brygga" lite ETH" ovan).
+
+Observera också att överföring av subgrafen kräver att en signal som inte är noll på subgrafen med samma konto som äger subgrafen; om du inte har signalerat på subgrafen måste du lägga till lite curation (att lägga till en liten mängd som 1 GRT skulle räcka).
+
+Efter att ha öppnat överföringsverktyget kommer du att kunna ange L2-plånboksadressen i fältet "Mottagande plånboksadress" - **se till att du har angett rätt adress här**. Om du klickar på Transfer Subgraph kommer du att uppmana dig att utföra transaktionen på din plånbok (observera att ett ETH-värde ingår för att betala för L2-gas); detta kommer att initiera överföringen och fasa ut din L1-subgraf (se "Förstå vad som händer med signal, din L1-subgraf och sökadresser" ovan för mer information om vad som händer bakom kulisserna).
+
+Om du utför det här steget, **se till att du fortsätter tills du har slutfört steg 3 om mindre än 7 dagar, annars försvinner subgrafen och din signal-GRT.** Detta beror på hur L1-L2-meddelanden fungerar på Arbitrum: meddelanden som skickas genom bryggan är "omförsökbara biljetter" som måste utföras inom 7 dagar, och det första utförandet kan behöva ett nytt försök om det finns toppar i gaspriset på Arbitrum.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Steg 2: Väntar på att subgrafen ska komma till L2
+
+När du har startat överföringen måste meddelandet som skickar din L1 subgraf till L2 spridas genom Arbitrum bryggan. Detta tar cirka 20 minuter (bryggan väntar på att huvudnäts blocket som innehåller transaktionen är "säkert" från potentiella kedjereorganisationer).
+
+När denna väntetid är över kommer Arbitrum att försöka utföra överföringen automatiskt på L2 kontrakten.
+
+![Vänteskärm](/img/screenshotOfWaitScreenL2.png)
+
+## Steg 3: Bekräfta överföringen
+
+I de flesta fall kommer detta steg att utföras automatiskt eftersom L2-gasen som ingår i steg 1 borde vara tillräcklig för att utföra transaktionen som tar emot subgrafen på Arbitrum-kontrakten. I vissa fall är det dock möjligt att en topp i gaspriserna på Arbitrum gör att denna autoexekvering misslyckas. I det här fallet kommer "biljetten" som skickar din subgraf till L2 att vara vilande och kräver ett nytt försök inom 7 dagar.
+
+Om så är fallet måste du ansluta med en L2 plånbok som har lite ETH på Arbitrum, byta ditt plånboksnätverk till Arbitrum och klicka på "Bekräfta överföring" för att försöka genomföra transaktionen igen.
+
+![Bekräfta överföringen till L2](/img/confirmTransferToL2.png)
+
+## Steg 4: Avsluta överföringen på L2
+
+Vid det här laget har din subgraf och GRT tagits emot på Arbitrum, men subgrafen är inte publicerad ännu. Du måste ansluta med L2 plånboken som du valde som mottagande plånbok, byta ditt plånboksnätverk till Arbitrum och klicka på "Publicera subgraf"
+
+![Publicera subgrafen](/img/publishSubgraphL2TransferTools.png)
+
+![Vänta på att subgrafen ska publiceras](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+Detta kommer att publicera subgrafen så att indexerare som är verksamma på Arbitrum kan börja servera den. Det kommer också att skapa kurations signaler med hjälp av GRT som överfördes från L1.
+
+## Steg 5: Uppdatera sökfrågans URL
+
+Din subgraf har överförts till Arbitrum! För att fråga subgrafen kommer den nya webbadressen att vara:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Observera att subgraf-ID: t på Arbitrum kommer att vara ett annat än det du hade på mainnet, men du kan alltid hitta det på Explorer eller Studio. Som nämnts ovan (se "Förstå vad som händer med signal, dina L1-subgraf- och sökwebbadresser") kommer den gamla L1-URL: n att stödjas under en kort stund, men du bör byta dina frågor till den nya adressen så snart subgrafen har synkroniserats på L2.
+
+## Så här överför du din kuration till Arbitrum (L2)
+
+## Förstå vad som händer med curation vid subgraf överföringar till L2
+
+När ägaren av en subgraf överför en subgraf till Arbitrum, omvandlas all subgrafs signal till GRT samtidigt. Detta gäller för "auto-migrerad" signal, det vill säga signal som inte är specifik för en subgraf version eller utbyggnad men som följer den senaste versionen av en subgraf.
+
+Denna omvandling från signal till GRT är densamma som vad som skulle hända om subgrafägaren avskaffade subgrafen i L1. När subgrafen föråldras eller överförs, "bränns" all curation-signal samtidigt (med hjälp av curation bonding-kurvan) och den resulterande GRT hålls av GNS smarta kontraktet (det är kontraktet som hanterar subgrafuppgraderingar och automatisk migrerad signal). Varje kurator i det stycket har därför ett anspråk på den GRT som är proportionell mot antalet aktier de hade för stycket.
+
+En bråkdel av dessa BRT som motsvarar subgrafägaren skickas till L2 tillsammans med subgrafen.
+
+Vid denna tidpunkt kommer den kurerade BRT inte att samla på sig några fler frågeavgifter, så kuratorer kan välja att dra tillbaka sin BRT eller överföra den till samma subgraf på L2, där den kan användas för att skapa en ny kurationssignal. Det är ingen brådska att göra detta eftersom BRT kan hjälpa till på obestämd tid och alla får ett belopp som är proportionellt mot sina aktier, oavsett när de gör det.
+
+## Välja din L2 plånbok
+
+Om du bestämmer dig för att överföra din kurerade GRT till L2 kan du välja en annan plånbok som kommer att äga kurationssignalen på L2.
+
+Om du använder en "vanlig" plånbok som Metamask (ett externt ägt konto eller EOA, d.v.s. en plånbok som inte är ett smart kontrakt), så är detta valfritt och det rekommenderas att behålla samma Curator-adress som i L1.
+
+Om du använder en smart kontraktsplånbok, som en multisig (t.ex. ett kassaskåp), är det obligatoriskt att välja en annan L2-plånboksadress, eftersom det är mest troligt att det här kontot bara finns på mainnet och att du inte kommer att kunna göra transaktioner på Arbitrum med denna plånbok. Om du vill fortsätta använda en smart kontraktsplånbok eller multisig, skapa en ny plånbok på Arbitrum och använd dess adress som L2-mottagande plånboksadress.
+
+**Det är mycket viktigt att använda en plånboksadress som du kontrollerar och som kan göra transaktioner på Arbitrum, eftersom annars kurationen går förlorad och inte kan återställas.**
+
+## Skicka kuration till L2: Steg 1
+
+Innan du påbörjar överföringen måste du bestämma vilken adress som ska äga kurationen på L2 (se "Välja din L2-plånbok" ovan), och det rekommenderas att ha en del ETH för gas som redan är överbryggad på Arbitrum ifall du behöver försöka utföra exekveringen av meddelande på L2. Du kan köpa ETH på vissa börser och ta ut den direkt till Arbitrum, eller så kan du använda Arbitrum-bryggan för att skicka ETH från en mainnet-plånbok till L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - eftersom gasavgifterna på Arbitrum är så låga ska du bara behöva en liten summa, t.ex. 0,01 ETH kommer förmodligen att vara mer än tillräckligt.
+
+Om en subgraf som du kurerar till har överförts till L2 kommer du att se ett meddelande i Explorer som talar om att du kurerar till en överförd subgraf.
+
+När du tittar på subgraf sidan kan du välja att dra tillbaka eller överföra kurationen. Genom att klicka på "Överför signal till Arbitrum" öppnas överföringsverktyget.
+
+![Överföringssignal](/img/transferSignalL2TransferTools.png)
+
+Efter att ha öppnat överföringsverktyget kan du bli ombedd att lägga till lite ETH i din plånbok om du inte har någon. Då kommer du att kunna ange L2 plånboksadressen i fältet "Mottagande plånboksadress" - **se till att du har angett rätt adress här**. Om du klickar på Överför signal kommer du att uppmana dig att utföra transaktionen på din plånbok (observera att ett ETH-värde ingår för att betala för L2-gas); detta kommer att initiera överföringen.
+
+Om du utför det här steget, **se till att du fortsätter tills du har slutfört steg 3 om mindre än 7 dagar, annars försvinner din signal-GRT.** Detta beror på hur L1-L2-meddelanden fungerar på Arbitrum: meddelanden som skickas via bron är "återförsökbara biljetter" som måste utföras inom 7 dagar, och det första utförandet kan behöva ett nytt försök om det finns toppar i gaspriset på Arbitrum.
+
+## Skickar kuration till L2: steg 2
+
+Starta överföringen:
+
+![Skicka signal till L2](/img/sendingCurationToL2Step2First.png)
+
+När du har startat överföringen måste meddelandet som skickar din L1 kuration till L2 spridas genom Arbitrum bryggan. Detta tar cirka 20 minuter (bryggan väntar på att huvudnäts blocket som innehåller transaktionen är "säkert" från potentiella kedjereorganiseringar).
+
+När denna väntetid är över kommer Arbitrum att försöka utföra överföringen automatiskt på L2 kontrakten.
+
+![Sänder kurations signal till L2](/img/sendingCurationToL2Step2Second.png)
+
+## Skickar kuration till L2: steg 3
+
+I de flesta fall kommer detta steg att utföras automatiskt eftersom L2-gasen som ingår i steg 1 borde vara tillräcklig för att utföra transaktionen som får kurationen på Arbitrum-kontrakten. I vissa fall är det dock möjligt att en topp i gaspriserna på Arbitrum gör att denna autoexekvering misslyckas. I det här fallet kommer "biljetten" som skickar din kuration till L2 att vara vilande och kräver ett nytt försök inom 7 dagar.
+
+Om så är fallet måste du ansluta med en L2 plånbok som har lite ETH på Arbitrum, byta ditt plånboksnätverk till Arbitrum och klicka på "Bekräfta överföring" för att försöka genomföra transaktionen igen.
+
+![Skicka signal till L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Dra tillbaka din kuration på L1
+
+Om du föredrar att inte skicka din GRT till L2, eller om du hellre vill överbrygga GRT manuellt, kan du ta tillbaka din kurerade BRT på L1. På bannern på subgraf sidan väljer du "Ta tillbaka signal" och bekräftar transaktionen; GRT kommer att skickas till din kurator adress.

From 0953705dcd0801c17e11ba8ffd36d49f0ab7814a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:21 -0500
Subject: [PATCH 1058/3820] New translations l2-transfer-tools-guide.mdx
 (Turkish)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/tr/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/tr/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/tr/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..b663f736a511
--- /dev/null
+++ b/website/pages/tr/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: Katman2 Transfer Araçları Rehberi
+---
+
+Graph, Arbitrum One üzerinde Katman2'ye geçişi kolaylaştırmıştır. Her protokol katılımcısı için, tüm ağ katılımcıları adına Katman2'ye transferi sorunsuz hale getirmek için bir dizi Katman2 Transfer Aracı vardır. Bu araçlar, ne transfer ettiğinize bağlı olarak belirli bir dizi adımı izlemenizi gerektirecektir.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## Subgraph'ınızı Arbitrum'a nasıl transfer edebilirsiniz (Katman2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Subgraphlar'ınızı transfer etmenin faydaları
+
+Graph topluluğu ve çekirdek geliştiricileri geçtiğimiz yıl boyunca Arbitrum'a geçmek için [hazırlanıyordu] (https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305). Bir katman 2 veya "L2" blok zinciri olan Arbitrum, güvenliği Ethereum'dan devralmakla birlikte büyük ölçüde daha düşük gaz ücretleri sağlamaktadır.
+
+Subgraph'ınızı Graph Ağı'nda yayınladığınızda veya yükselttiğinizde, protokol üzerindeki akıllı sözleşmelerle etkileşime girersiniz ve bu ETH kullanarak gas ödemesi yapmayı gerektirir. Subgraphlar'ınızı Arbitrum'a taşıdığınızda, gelecekte subgraphlar'ınızda yapılacak tüm güncellemeler çok daha düşük gas ücretleri gerektirecektir. Daha düşük ücretler ve Katman2'deki kürasyon bağlanma eğrilerinin sabit olması, diğer Küratörlerin subgraph'ınızda kürasyon yapmasını kolaylaştırır ve subgraph'ınızdaki İndeksleyiciler için ödülleri artırır. Bu düşük maliyetli ortam, İndeksleyicilerin subgraph'ınızı indekslemesini ve hizmet vermesini de daha ucuz hale getirmektedir.. Önümüzdeki aylarda İndeksleme ödülleri Arbitrum'da artacak ve Ethereum ana ağında azalacaktır, bu nedenle gittikçe daha fazla İndeksleyici mevcut stake'lerini transfer edecek ve operasyonlarını Katman2'de başlatacaktır.
+
+## Sinyal, Katman1 subgraph'ınız ve sorgu URL'leri ile neler gerçekleştiğini anlama
+
+Bir subgraph'ı Arbitrum'a transfer etmek için Arbitrum GRT köprüsü kullanılmaktadır, bu köprüde subgraph'ı Katman2'ye göndermek için yerel Arbitrum köprüsünü kullanır. "transfer", ana ağdaki subgraph'ı kullanımdan kaldıracak ve köprüyü kullanarak Katman2'de subgraph'ı yeniden oluşturmak için bilgi gönderecektir. Aynı zamanda, köprünün transferi kabul etmesi için subgraph sahibinin sinyallenmiş GRT'sini de dahil edecektir ve bu değer sıfırdan büyük olmalıdır.
+
+Subgraph transfer etmeyi seçtiğinizde, bu, subgraph'ın tüm kürasyon sinyalini GRT'ye dönüştürecektir. Bu, ana ağdaki subgraph'ı "kullanımdan kaldırmaya" eşdeğerdir. Kürasyonunuza karşılık gelen GRT, subgraphla birlikte Katman2'ye gönderilecek ve burada sizin adınıza sinyal basmak için kullanılacaktır.
+
+Diğer Küratörler, GRT tokenlerinin bir bölümünü geri çekmeyi ya da aynı subgraph üzerinde sinyal basmak için Katman2'ye transfer etmeyi tercih edebilirler. Bir subgraph sahibi subgraph'ını Katman2'ye transfer edemezse ve bir sözleşme çağrısı yoluyla manuel olarak kullanımdan kaldırırsa, Küratörler bilgilendirilecek ve kürasyonlarını geri çekebileceklerdir.
+
+Subgraph transfer edilir edilmez, tüm kürasyon GRT'ye dönüştürüldüğünden, İndeksleyiciler artık subgraph'ı indekslemek için ödül almayacaktır. Ancak, 1) aktarılan subgraphlar'ı 24 saat boyunca sunmaya devam edecek ve 2) hemen Katman2'de subgraph'ı indekslemeye başlayacak İndeksleyiciler olacaktır. Bu İndeksleyiciler subgraph'ı zaten indekslediğinden, subgraph'ın senkronize olmasını beklemeye gerek kalmayacak ve Katman2 subgraph'ını neredeyse anında sorgulamak mümkün olacaktır.
+
+Katman2 subgraph'ına yönelik sorgular farklı bir URL üzerinden yapılmalıdır (arbitrum-gateway.thegraph.com). Ancak Katman1 URL'si en az 48 saat boyunca çalışmaya devam edecektir. Bu sürenin ardından, Katman1 ağ geçidi sorguları (bir süre için) Katman2 ağ geçidine iletecektir, fakat bu gecikmeye neden olacağından ötürü mümkün olan en kısa sürede tüm sorgularınızı yeni URL'ye geçirmeniz önerilir.
+
+## Katman2 cüzdanınızın seçimi
+
+Subgraph'ınızı ana ağ üzerinde yayınladığınızda, subgraph'ı oluşturmak için bağlı bir cüzdan kullandınız ve bu cüzdan, bu subgraph'ı temsil eden ve güncellemeleri yayınlamanıza izin veren NFT'nin sahibidir.
+
+Subgraph'ı Arbitrum'a transfer ederken, Katman2 üzerinde bu subgraph NFT'ye sahip olacak farklı bir cüzdan seçebilirsiniz.
+
+MetaMask gibi "genel" bir cüzdan (Harici Olarak Sahip Olunan Hesap veya EOA, yani akıllı sözleşme olmayan bir cüzdan) kullanıyorsanız, bu opsiyoneldir ve Katman1'deki ile aynı sahip adresini kullanmanız önerilir.
+
+Çoklu imza (örneğin Safe) gibi bir akıllı sözleşme cüzdanı kullanıyorsanız, farklı bir Katman2 cüzdan adresi seçmek zorunludur, çünkü büyük olasılıkla bu hesap yalnızca ana ağ üzerinde kullanılabilir ve bu cüzdanı kullanarak Arbitrum'da işlem yapamazsınız. Bir akıllı sözleşme cüzdanı veya çoklu imza cüzdanı kullanmaya devam etmek istiyorsanız, Arbitrum'da yeni bir cüzdan oluşturun ve adresini subgraph'ınızın Katman2 sahibi olarak kullanın.
+
+**Sizin kontrolünüzde ve Arbitrum üzerinde işlem yapabilen bir cüzdan adresi kullanmak oldukça önemlidir. Aksi takdirde, subgraph kaybolacak ve kurtarılamayacaktır.**
+
+## Transfer için hazırlık: Bir miktar ETH köprüleme
+
+Subgraph'ın transfer edilmesi, köprü üzerinden bir işlemin gönderilmesini ve ardından Arbitrum'da başka bir işlemin yürütülmesini içermektedir. İlk işlem ana ağda ETH kullanır ve mesaj Katman2'de alındığında gas için ödeme yapmak üzere bir miktar ETH içerir. Ancak, bu gas yetersizse, işlemi yeniden denemeniz ve gas için doğrudan Katman2'de ödeme yapmanız gerekecektir (bu, aşağıdaki "Adım 3: Transferi onaylama" dır). Bu adım **transferin başlamasından sonraki 7 gün içinde gerçekleştirilmelidir**. Ayrıca, ikinci işlem ("Adım 4: Katman2'de transferin tamamlanması") doğrudan Arbitrum'da gerçekleştirilecektir. Bu nedenlerden dolayı, Arbitrum cüzdanında bir miktar ETH'ye ihtiyacınız olacak. Bir çoklu imzalı veya akıllı sözleşme hesabı kullanıyorsanız, ETH'nin çoklu imza değil, işlemleri gerçekleştirmek için kullandığınız normal harici hesap (EOA) cüzdanında olması gerekecektir.
+
+Bazı borsalardan ETH satın alabilir ve doğrudan Arbitrum'a çekebilir veya bir ana ağ cüzdanından Katman2'ye ETH göndermek için Arbitrum köprüsünü kullanabilirsiniz: [bridge.arbitrum.io](http://bridge.arbitrum.io). Arbitrum'daki gas ücretleri daha düşük olduğundan, yalnızca küçük bir miktara ihtiyacınız olacaktır. İşleminizin onaylanması için düşük bir eşikten (ör. 0.01 ETH) başlamanız önerilir.
+
+## Subgraph Transfer Aracını bulma
+
+Subgraph Stüdyo'da subgraph'ınızın sayfasına bakarak Katman2 Transfer Aracını bulabilirsiniz:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+Ayrıca, bir subgraph'ın sahibi olan cüzdana bağlıysanız Gezgin'de ve Gezgin'deki subgraph'ın sayfasında da bulunmaktadır:
+
+![Transferring to L2](/img/transferToL2.png)
+
+Katman2'ye Transfer düğmesine tıkladığınızda transfer işlemini başlatabileceğiniz transfer aracı açılacaktır.
+
+## Adım 1: Transferin başlatılması
+
+Transfere başlamadan önce, Katman2'de hangi adresin subgraph'a sahip olacağına karar vermelisiniz (yukarıdaki "Katman2 cüzdanınızın seçimi" bölümüne bakın) ve Arbitrum'da halihazırda köprülenmiş gas için kullanacağınız bir miktar ETH bulundurmanız şiddetle tavsiye edilir (yukarıdaki "Transfer için hazırlık: Bir miktar ETH köprüleme" bölümüne bakın).
+
+Ayrıca, subgraph'ın sahibi olan hesabın bir subgraph transferi gerçekleştirebilmesi için ilgili subgraph üzerinde belirli bir sinyale sahip olması gerektiğini göz önünde bulundurun; eğer subgraph üzerinde sinyal vermediyseniz, biraz kürasyon eklemeniz gerekecektir (1 GRT gibi küçük bir miktar eklemek yeterli olacaktır).
+
+Transfer Aracını açtıktan sonra, Katman2 cüzdan adresini "Alıcı cüzdan adresi" alanına girebileceksiniz - **buraya doğru adresi girdiğinizden emin olun**. Subgraph'ı Transfer Et'e tıkladığınızda, cüzdanınızda işlemi gerçekleştirmeniz istenecektir (Katman2 gas'ı için ödeme yapmak üzere bir miktar ETH'nin dahil edildiğini unutmayın); bu, transferi başlatacak ve Katman1 subgraph'ınızı kullanımdan kaldıracaktır (perde arkasında neler olup bittiğine ilişkin daha fazla ayrıntı için yukarıdaki "Sinyal, Katman1 subgraph'ınız ve sorgu URL'leri ile neler gerçekleştiğini anlama" bölümüne bakın).
+
+Bu adımı uygularsanız, **3. adımı tamamlamak için yedi günden daha kısa bir sürede ilerlediğinizden mutlaka emin olmalısınız; aksi halde subgraph ve sinyal GRT'nizi kaybedeceksiniz.** Bunun nedeni Arbitrum'da Katman1-Katman2 mesajlaşmasının çalışma şeklidir: köprü üzerinden gönderilen mesajlar 7 gün içinde yürütülmesi gereken "yeniden denenebilir biletler"dir ve Arbitrum'da gas fiyatında ani artışlar olması durumunda ilk yürütmenin yeniden denenmesi gerekebilir.
+
+![L2’ye transferi başlatın](/img/startTransferL2.png)
+
+## Adım 2: Subgraph'ın Katman2'ye ulaşmasını bekleme
+
+Transferi başlattıktan sonra, Katman1 subgraph'ınızı Katman2'ye gönderen mesajın Arbitrum köprüsü üzerinden yayılması gerekir. Bu işlem yaklaşık 20 dakika sürer (köprü, işlemi içeren ana ağ bloğunun olası zincir yeniden düzenlemelerine karşı "güvenli" olmasını bekler).
+
+Bu bekleme süresi sona erdiğinde Arbitrum, Katman2 sözleşmelerinde transferi otomatik olarak yürütmeye çalışacaktır.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## Adım 3: Transferi onaylama
+
+Çoğu durumda, bu adım otomatik olarak yürütülecektir çünkü 1. adımda yer alan Katman2 gas'ı Arbitrum sözleşmelerinde subgraph'ı içeren işlemi yürütmek için yeterli olacaktır. Ancak bazı durumlarda, Arbitrum'daki gas fiyatlarındaki bir artış bu otomatik yürütmenin başarısız olmasına neden olabilir. Bu durumda, subgraph'ınızı Katman2'ye gönderen "bilet" beklemede olacak ve 7 gün içinde yeniden denenmesi gerekecektir.
+
+Durum buysa, Arbitrum'da bir miktar ETH bulunan bir Katman2 cüzdanı bağlanmanız, cüzdan ağınızı Arbitrum'a geçirmeniz ve işlemi yeniden denemek için "Transferi Onayla" seçeneğine tıklamanız gerekecektir.
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## Adım 4: Katman2'de transferin tamamlanması
+
+Bu noktada, subgraph'ınız ve GRT'niz Arbitrum'a ulaşmıştır, ancak subgraph henüz yayınlanmamıştır. Alıcı cüzdan olarak seçtiğiniz Katman2 cüzdanını bağlanmanız, cüzdan ağınızı Arbitrum'a geçirmeniz ve "Subgraph'ı Yayınla" seçeneğine tıklamanız gerekecektir.
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+Bu, Arbitrum üzerinde çalışan İndeksleyicilerin hizmet vermeye başlayabilmesi için subgraph'ı yayınlayacaktır. Ayrıca Katman1'den aktarılan GRT'yi kullanarak kürasyon sinyalini de basacaktır.
+
+## Adım 5: Sorgu URL'sini güncelleme
+
+Subgraph'ınız Arbitrum'a başarıyla transfer edildi! Subgraph'ı sorgulamak için yeni URL şu şekilde olacaktır:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Arbitrum'daki subgraph kimliğinin ana ağda sahip olduğunuzdan farklı olacağını unutmayın, ancak bunu her zaman Gezgin veya Stüdyo aracılığıyla bulabilirsiniz. Yukarıda belirtildiği gibi ("Sinyal, Katman1 subgraph'ınız ve sorgu URL'leri ile neler gerçekleştiğini anlama" bölümüne bakın) eski Katman1 URL'si kısa bir süre için desteklenecektir, ancak subgraph Katman2'de senkronize edilir edilmez sorgularınızı yeni adrese geçirmelisiniz.
+
+## Kürasyonunuzu Arbitrum'a nasıl transfer edebilirsiniz (Katman2)
+
+## Katman2'ye subgraph transferlerinde kürasyona ne olduğunu anlama
+
+Bir subgraph'ın sahibi subgraph'ı Arbitrum'a transfer ettiğinde, subgrpah'ın tüm sinyali aynı anda GRT'ye dönüştürülür. Bu, "otomatik olarak taşınan" sinyal, yani bir subgraph sürümüne veya dağıtımına özgü olmayan ancak bir subgraph'ın en son sürümünü takip eden sinyal için geçerlidir.
+
+Sinyalden GRT'ye bu dönüşüm, subgraph sahibinin subgraph'ı Katman1'de kullanımdan kaldırması durumunda gerçekleşecek olanla aynıdır. Subgraph kullanımdan kaldırıldığında veya transfer edildiğinde, tüm kürasyon sinyali aynı anda "yakılır" (kürasyon bağlanma eğrisi kullanılarak) ve ortaya çıkan GRT, GNS akıllı sözleşmesi (yani subgraph yükseltmelerini ve otomatik olarak taşınan sinyali işleyen sözleşme) tarafından tutulur. Bu nedenle, bu subgraph'daki her Küratör, subgraph için sahip oldukları stake miktarıyla orantılı olarak GRT üzerinde hak iddia eder.
+
+Bu GRT tokenlerin subgraph sahibine ilişkin bir bölümü, subgraph ile birlikte Katman2'ye iletilir.
+
+Bu noktada, küratörlüğü yapılan GRT daha fazla sorgu ücreti biriktirmeyecektir, bu nedenle Küratörler GRT'lerini geri çekmeyi veya yeni kürasyon sinyali basmak için kullanılabilecekleri Katman2'deki aynı subgraph'a transfer etmeyi seçebilirler. GRT süresiz bir şekilde kullanılabileceğinden ve ne zaman yaptıklarına bakılmaksızın herkes paylarıyla orantılı bir miktar alacağından bunu yapmak için acele etmeye gerek yoktur.
+
+## Katman2 cüzdanınızın seçimi
+
+Küratörlüğünü yaptığınız GRT'yi Katman2'ye transfer etmeye karar verirseniz, Katman2'deki küratörlük sinyaline sahip olacak farklı bir cüzdan seçebilirsiniz.
+
+Metamask gibi "genel" bir cüzdan (Harici Olarak Sahip Olunan Hesap veya EOA, yani akıllı sözleşme olmayan bir cüzdan) kullanıyorsanız, bu opsiyoneldir ve Katman1'deki ile aynı Küratör adresini kullanmanız önerilir.
+
+Çoklu imza (örneğin Safe) gibi bir akıllı sözleşme cüzdanı kullanıyorsanız, farklı bir Katman2 cüzdan adresi seçmek zorunludur, çünkü büyük olasılıkla bu hesap yalnızca ana ağ üzerinde kullanılabilir ve bu cüzdanı kullanarak Arbitrum'da işlem yapamazsınız. Bir akıllı sözleşme cüzdanı veya çoklu imza cüzdanı kullanmaya devam etmek istiyorsanız, Arbitrum'da yeni bir cüzdan oluşturun ve adresini Katman2 alıcı adresiniz olarak kullanın.
+
+**Sizin kontrolünüzde ve Arbitrum üzerinde işlem yapabilen bir cüzdan adresi kullanmak oldukça önemlidir. Aksi takdirde, kürasyon kaybolacak ve kurtarılamayacaktır.**
+
+## Katman2'ye kürasyon gönderme: Adım 1
+
+Transfere başlamadan önce, Katman2'deki kürasyonun hangi adrese ait olacağına karar vermelisiniz (yukarıdaki "Katman2 cüzdanınızın seçinmi" bölümüne bakın) ve mesajın Katman2'de yürütülmesini yeniden denemeniz gerektiğinde Arbitrum'da zaten köprülenmiş gas için kullanabileceğiniz bir miktar ETH bulundurmanız önerilir. Bazı borsalardan ETH satın alabilir ve doğrudan Arbitrum'a çekebilir veya bir ana ağ cüzdanından Katman2'ye ETH göndermek için Arbitrum köprüsünü kullanabilirsiniz: [bridge.arbitrum.io](http://bridge.arbitrum.io) - Arbitrum'daki gas ücretleri çok düşük olduğundan, yalnızca küçük bir miktara ihtiyacınız olacak, örneğin 0.01 ETH muhtemelen fazlasıyla yeterli olacaktır.
+
+Küratörlüğünü yaptığınız bir subgraph Katman2'ye transfer edilmişse, Gezgin'de transfer edilmiş bir subgraph'a küratörlük yaptığınızı belirten bir mesaj göreceksiniz.
+
+Subgraph sayfasına bakarken, kürasyonu geri çekmeyi veya transfer etmeyi seçebilirsiniz. "Sinyali Arbitrum'a Transfer Et" seçeneğine tıkladığınızda transfer aracı açılacaktır.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+Transfer Aracını açtıktan sonra, eğer hiç ETH'niz yoksa cüzdanınıza bir miktar ETH eklemeniz istenebilir. Daha sonra, katman2 cüzdan adresini "Alıcı cüzdan adresi" alanına girebileceksiniz - **buraya doğru adresi girdiğinizden emin olun**. Sinyal'i Transfer Et'e tıkladığınızda, cüzdanınızda işlemi gerçekleştirmeniz istenecektir (Katman2 gas'ı için ödeme yapmak üzere bir miktar ETH'nin dahil edildiğini unutmayın); bu, transferi başlatacaktır.
+
+Bu adımı uygularsanız, **3. adımı tamamlamak için yedi günden daha kısa bir sürede ilerlediğinizden mutlaka emin olmalısınız; aksi halde sinyal GRT'nizi kaybedeceksiniz.** Bunun nedeni Arbitrum'da Katman1-Katman2 mesajlaşmasının çalışma şeklidir: köprü üzerinden gönderilen mesajlar 7 gün içinde yürütülmesi gereken "yeniden denenebilir biletler"dir ve Arbitrum'da gas fiyatında ani artışlar olması durumunda ilk yürütmenin yeniden denenmesi gerekebilir.
+
+## Katman2'ye kürasyon gönderme: Adım 2
+
+Transferin başlatılması:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+Transferi başlattıktan sonra, Katman1 kürasyon'unuzu Katman2'ye gönderen mesajın Arbitrum köprüsü üzerinden yayılması gerekir. Bu işlem yaklaşık 20 dakika sürer (köprü, işlemi içeren ana ağ bloğunun olası zincir yeniden düzenlemelerine karşı "güvenli" olmasını bekler).
+
+Bu bekleme süresi sona erdiğinde Arbitrum, Katman2 sözleşmelerinde transferi otomatik olarak yürütmeye çalışacaktır.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Katman2'ye kürasyon gönderme: Adım 3
+
+Çoğu durumda, bu adım otomatik olarak yürütülecektir çünkü 1. adımda yer alan Katman2 gas'ı Arbitrum sözleşmelerinde kürasyon'u içeren işlemi yürütmek için yeterli olacaktır. Ancak bazı durumlarda, Arbitrum'daki gas fiyatlarındaki bir artış bu otomatik yürütmenin başarısız olmasına neden olabilir. Bu durumda, kürasyon'unuzu Katman2'ye gönderen "bilet" beklemede olacak ve 7 gün içinde yeniden denenmesi gerekecektir.
+
+Durum buysa, Arbitrum'da bir miktar ETH bulunan bir Katman2 cüzdanı bağlanmanız, cüzdan ağınızı Arbitrum'a geçirmeniz ve işlemi yeniden denemek için "Transferi Onayla" seçeneğine tıklamanız gerekecektir.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Katman1'deki kürasyonunuzu çekme
+
+GRT'nizi Katman2'ye göndermek istemiyorsanız veya manuel olarak köprülemeyi tercih ediyorsanız, Katman1'de kürasyonu gerçekleşmiş GRT'lerinizi çekebilirsiniz. Subgraph sayfasındaki afişte "Sinyali Çek" seçeneğini seçin ve işlemi onaylayın; GRT, Küratör adresinize gönderilecektir.

From 9c0a37c481063703af879bd07906e9ad7cde1e15 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:22 -0500
Subject: [PATCH 1059/3820] New translations l2-transfer-tools-guide.mdx
 (Ukrainian)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/uk/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/uk/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/uk/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..485f34a70c97
--- /dev/null
+++ b/website/pages/uk/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 Transfer Tools Guide
+---
+
+The Graph has made it easy to move to L2 on Arbitrum One. For each protocol participant, there are a set of L2 Transfer Tools to make transferring to L2 seamless for all network participants. These tools will require you to follow a specific set of steps depending on what you are transferring.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## How to transfer your subgraph to Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Benefits of transferring your subgraphs
+
+The Graph's community and core devs have [been preparing](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) to move to Arbitrum over the past year. Arbitrum, a layer 2 or "L2" blockchain, inherits the security from Ethereum but provides drastically lower gas fees.
+
+When you publish or upgrade your subgraph to The Graph Network, you're interacting with smart contracts on the protocol and this requires paying for gas using ETH. By moving your subgraphs to Arbitrum, any future updates to your subgraph will require much lower gas fees. The lower fees, and the fact that curation bonding curves on L2 are flat, also make it easier for other Curators to curate on your subgraph, increasing the rewards for Indexers on your subgraph. This lower-cost environment also makes it cheaper for Indexers to index and serve your subgraph. Indexing rewards will be increasing on Arbitrum and decreasing on Ethereum mainnet over the coming months, so more and more Indexers will be transferring their stake and setting up their operations on L2.
+
+## Understanding what happens with signal, your L1 subgraph and query URLs
+
+Transferring a subgraph to Arbitrum uses the Arbitrum GRT bridge, which in turn uses the native Arbitrum bridge, to send the subgraph to L2. The "transfer" will deprecate the subgraph on mainnet and send the information to re-create the subgraph on L2 using the bridge. It will also include the subgraph owner's signaled GRT, which must be more than zero for the bridge to accept the transfer.
+
+When you choose to transfer the subgraph, this will convert all of the subgraph's curation signal to GRT. This is equivalent to "deprecating" the subgraph on mainnet. The GRT corresponding to your curation will be sent to L2 together with the subgraph, where they will be used to mint signal on your behalf.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph. If a subgraph owner does not transfer their subgraph to L2 and manually deprecates it via a contract call, then Curators will be notified and will be able to withdraw their curation.
+
+As soon as the subgraph is transferred, since all curation is converted to GRT, Indexers will no longer receive rewards for indexing the subgraph. However, there will be Indexers that will 1) keep serving transferred subgraphs for 24 hours, and 2) immediately start indexing the subgraph on L2. Since these Indexers already have the subgraph indexed, there should be no need to wait for the subgraph to sync, and it will be possible to query the L2 subgraph almost immediately.
+
+Queries to the L2 subgraph will need to be done to a different URL (on `arbitrum-gateway.thegraph.com`), but the L1 URL will continue working for at least 48 hours. After that, the L1 gateway will forward queries to the L2 gateway (for some time), but this will add latency so it is recommended to switch all your queries to the new URL as soon as possible.
+
+## Choosing your L2 wallet
+
+When you published your subgraph on mainnet, you used a connected wallet to create the subgraph, and this wallet owns the NFT that represents this subgraph and allows you to publish updates.
+
+When transferring the subgraph to Arbitrum, you can choose a different wallet that will own this subgraph NFT on L2.
+
+If you're using a "regular" wallet like MetaMask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same owner address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 owner of your subgraph.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum. Otherwise, the subgraph will be lost and cannot be recovered.**
+
+## Preparing for the transfer: bridging some ETH
+
+Transferring the subgraph involves sending a transaction through the bridge, and then executing another transaction on Arbitrum. The first transaction uses ETH on mainnet, and includes some ETH to pay for gas when the message is received on L2. However, if this gas is insufficient, you will have to retry the transaction and pay for the gas directly on L2 (this is "Step 3: Confirming the transfer" below). This step **must be executed within 7 days of starting the transfer**. Moreover, the second transaction ("Step 4: Finishing the transfer on L2") will be done directly on Arbitrum. For these reasons, you will need some ETH on an Arbitrum wallet. If you're using a multisig or smart contract account, the ETH will need to be in the regular (EOA) wallet that you are using to execute the transactions, not on the multisig wallet itself.
+
+You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Since gas fees on Arbitrum are lower, you should only need a small amount. It is recommended that you start at a low threshold (0.e.g. 01 ETH) for your transaction to be approved.
+
+## Finding the subgraph Transfer Tool
+
+You can find the L2 Transfer Tool when you're looking at your subgraph's page on Subgraph Studio:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+It is also available on Explorer if you're connected with the wallet that owns a subgraph and on that subgraph's page on Explorer:
+
+![Transferring to L2](/img/transferToL2.png)
+
+Clicking on the Transfer to L2 button will open the transfer tool where you can start the transfer process.
+
+## Step 1: Starting the transfer
+
+Before starting the transfer, you must decide which address will own the subgraph on L2 (see "Choosing your L2 wallet" above), and it is strongly recommend having some ETH for gas already bridged on Arbitrum (see "Preparing for the transfer: bridging some ETH" above).
+
+Also please note transferring the subgraph requires having a nonzero amount of signal on the subgraph with the same account that owns the subgraph; if you haven't signaled on the subgraph you will have to add a bit of curation (adding a small amount like 1 GRT would suffice).
+
+After opening the Transfer Tool, you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Subgraph will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer and deprecate your L1 subgraph (see "Understanding what happens with signal, your L1 subgraph and query URLs" above for more details on what goes on behind the scenes).
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or the subgraph and your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retry-able tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Step 2: Waiting for the subgraph to get to L2
+
+After you start the transfer, the message that sends your L1 subgraph to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## Step 3: Confirming the transfer
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the subgraph on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your subgraph to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## Step 4: Finishing the transfer on L2
+
+At this point, your subgraph and GRT have been received on Arbitrum, but the subgraph is not published yet. You will need to connect using the L2 wallet that you chose as the receiving wallet, switch your wallet network to Arbitrum, and click "Publish Subgraph."
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+This will publish the subgraph so that Indexers that are operating on Arbitrum can start serving it. It will also mint curation signal using the GRT that were transferred from L1.
+
+## Step 5: Updating the query URL
+
+Your subgraph has been successfully transferred to Arbitrum! To query the subgraph, the new URL will be :
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Note that the subgraph ID on Arbitrum will be a different than the one you had on mainnet, but you can always find it on Explorer or Studio. As mentioned above (see "Understanding what happens with signal, your L1 subgraph and query URLs") the old L1 URL will be supported for a short while, but you should switch your queries to the new address as soon as the subgraph has been synced on L2.
+
+## How to transfer your curation to Arbitrum (L2)
+
+## Understanding what happens to curation on subgraph transfers to L2
+
+When the owner of a subgraph transfers a subgraph to Arbitrum, all of the subgraph's signal is converted to GRT at the same time. This applies to "auto-migrated" signal, i.e. signal that is not specific to a subgraph version or deployment but that follows the latest version of a subgraph.
+
+This conversion from signal to GRT is the same as what would happen if the subgraph owner deprecated the subgraph in L1. When the subgraph is deprecated or transferred, all curation signal is "burned" simultaneously (using the curation bonding curve) and the resulting GRT is held by the GNS smart contract (that is the contract that handles subgraph upgrades and auto-migrated signal). Each Curator on that subgraph therefore has a claim to that GRT proportional to the amount of shares they had for the subgraph.
+
+A fraction of these GRT corresponding to the subgraph owner is sent to L2 together with the subgraph.
+
+At this point, the curated GRT will not accrue any more query fees, so Curators can choose to withdraw their GRT or transfer it to the same subgraph on L2, where it can be used to mint new curation signal. There is no rush to do this as the GRT can be help indefinitely and everybody gets an amount proportional to their shares, irrespective of when they do it.
+
+## Choosing your L2 wallet
+
+If you decide to transfer your curated GRT to L2, you can choose a different wallet that will own the curation signal on L2.
+
+If you're using a "regular" wallet like Metamask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same Curator address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 receiving wallet address.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum, as otherwise the curation will be lost and cannot be recovered.**
+
+## Sending curation to L2: Step 1
+
+Before starting the transfer, you must decide which address will own the curation on L2 (see "Choosing your L2 wallet" above), and it is recommended having some ETH for gas already bridged on Arbitrum in case you need to retry the execution of the message on L2. You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - since gas fees on Arbitrum are so low, you should only need a small amount, e.g. 0.01 ETH will probably be more than enough.
+
+If a subgraph that you curate to has been transferred to L2, you will see a message on Explorer telling you that you're curating to a transferred subgraph.
+
+When looking at the subgraph page, you can choose to withdraw or transfer the curation. Clicking on "Transfer Signal to Arbitrum" will open the transfer tool.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+After opening the Transfer Tool, you may be prompted to add some ETH to your wallet if you don't have any. Then you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Signal will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer.
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retryable tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+## Sending curation to L2: step 2
+
+Starting the transfer:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+After you start the transfer, the message that sends your L1 curation to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Sending curation to L2: step 3
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the curation on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your curation to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Withdrawing your curation on L1
+
+If you prefer not to send your GRT to L2, or you'd rather bridge the GRT manually, you can withdraw your curated GRT on L1. On the banner on the subgraph page, choose "Withdraw Signal" and confirm the transaction; the GRT will be sent to your Curator address.

From 7822ab9ae90dd8f2009ef3ca7f8b50cdd02cf8b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:24 -0500
Subject: [PATCH 1060/3820] New translations l2-transfer-tools-guide.mdx
 (Chinese Simplified)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..9a5711b2d217
--- /dev/null
+++ b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2转移工具指南
+---
+
+The Graph has made it easy to move to L2 on Arbitrum One. For each protocol participant, there are a set of L2 Transfer Tools to make transferring to L2 seamless for all network participants. These tools will require you to follow a specific set of steps depending on what you are transferring.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## 如何将你的子图转移到 Arbitrum（L2）
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## 将子图转移到 Arbitrum 的好处
+
+过去一年里，Graph社区和核心开发人员一直在为迁移到 Arbitrum 做准备(https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) 。Arbitrum 是一种二层网络或“L2”区块链，继承了以太坊的安全性，但提供了大幅降低的燃气费用。
+
+当您将子图发布或升级到The Graph Network时，您将与协议上的智能合约进行交互，这需要使用以太币（ETH）支付燃气费用。通过将您的子图迁移到Arbitrum，将来对您的子图进行的任何更新将需要更低的燃气费用。较低的费用以及L2网络上平滑的曲线，使其他策展人更容易在您的子图上进行策展，从而增加了在您的子图上的索引人的奖励。这种较低成本的环境还使得索引器更便宜地对您的子图进行索引和服务。在接下来的几个月里，Arbitrum上的索引奖励将增加，而以太坊主网上的索引奖励将减少，因此越来越多的索引器将会将他们的质押迁移到L2网络并在该网络上设置运营。
+
+## 理解信号、你的 L1 子图和查询 URL 的变化
+
+将子图转移到 Arbitrum 使用了 Arbitrum GRT 跨链桥，该跨链桥又使用了本机的 Arbitrum 跨链桥，将子图发送到 L2。这个“转账”操作会废弃主网上的子图，并使用跨链桥将重建子图所需的信息发送到 L2。它还包括子图所有者的信号 GRT，跨链桥需要接受转账时，这些信号 GRT 必须大于零。
+
+当你选择转移子图时，这将把所有子图的策展信号转换为 GRT。这相当于在主网上“废弃”子图。与你的策展相对应的 GRT 将与子图一起发送到 L2，其中它们将被用于代表你铸造信号。
+
+其他策展人可以选择是否提取他们所占份额的 GRT，或者将其转移到 L2 上的同一子图上，以铸造新的策展信号。如果一个子图所有者不将他们的子图转移到 L2 并通过合约调用手动废弃它，那么策展人将收到通知并可以提取他们的策展。
+
+一旦子图转移完成，由于所有策展都转换为 GRT，索引人将不再因索引子图而获得奖励。但是，有些索引人会保持对转移的子图进行 24 小时的服务，并立即开始在 L2 上进行子图索引。由于这些索引人已经对子图进行了索引，所以无需等待子图同步，几乎可以立即查询 L2 子图。
+
+对 L2 子图的查询需要使用不同的 URL（on `arbitrum-gateway.thegraph.com`），但 L1 URL 将继续工作至少 48 小时。之后，L1 网关将把查询转发到 L2 网关（一段时间内），但这会增加延迟，因此建议尽快将所有查询切换到新的 URL。
+
+## 选择你的 L2 钱包
+
+当你在主网上发布子图时，你使用一个连接的钱包创建了子图，这个钱包拥有代表这个子图的 NFT，并允许你发布升级。
+
+当将子图转移到 Arbitrum 时，你可以选择一个不同的钱包在 L2 上持有这个子图 NFT 。
+
+如果你使用的是像 MetaMask 这样的“常规”钱包（外部拥有账户或 EOA，即不是智能合约钱包），那么这是可选的，建议保持与 L1 中相同的所有者地址。
+
+如果你使用的是智能合约钱包，比如多签钱包（例如 Safe），那么选择不同的 L2 钱包地址是必需的，因为这个账户很可能只存在于主网上，你将无法使用这个钱包在 Arbitrum 上进行交易。如果你想继续使用智能合约钱包或多签钱包，那么可以在 Arbitrum 上创建一个新的钱包，并使用其地址作为你的子图的 L2 所有者。
+
+**使用你能控制并且能在 Arbitrum 上进行交易的钱包地址非常重要，否则子图将丢失且无法恢复。**
+
+## 为转移做准备：转移一些 ETH
+
+转移子图涉及通过跨链桥发送一个交易，然后在 Arbitrum 上执行另一个交易。第一个交易使用主网上的 ETH，并包含一些 ETH 用于接收 L2 上的消息时支付燃气费用。然而，如果这个燃气费用不足，你将不得不重试交易，并直接在 L2 上支付燃气费用（这是下面的“第 3 步：确认转移”）。这一步必须在开始转移后的 7 天内执行。此外，第二个交易（“第 4 步：在 L2 上完成转移”）将直接在 Arbitrum 上执行。因此，你需要在 Arbitrum 钱包中拥有一些 ETH。如果你使用的是多签或智能合约账户，则 ETH 必须在你用于执行交易的常规（EOA）钱包中，而不是多签钱包本身。
+
+你可以在一些交易所购买 ETH，并直接将其提取到 Arbitrum，或者你可以使用 Arbitrum 跨链桥将 ETH 从主网钱包发送到 L2：[bridge.arbitrum.io](http://bridge.arbitrum.io)。由于 Arbitrum 上的燃气费用较低，你只需要一小笔资金即可。建议你设置一个较低的阈值（例如 0.01 ETH），以便你的交易得到批准。
+
+## 查找子图转移工具
+
+在 Subgraph Studio 查看你的子图页面时，你可以找到 L2 转移工具：
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+如果你使用拥有子图的钱包连接到 Explorer，你还可以在 Explorer 上的子图页面上找到它：
+
+![Transferring to L2](/img/transferToL2.png)
+
+点击 "Transfer to L2" 按钮将打开转移工具，在那里你可以开始转移进程。
+
+## 第 1 步：开始转移
+
+在开始转移之前，你必须决定哪个地址将在 L2 上拥有这个子图（参见上面的“选择你的 L2 钱包”），并且强烈建议提前转移一些 ETH到 Arbitrum （参见上面的“为转移做准备：转移一些 ETH”）
+
+另外，请注意转移子图需要在拥有与子图相同账户的非零信号 GRT 的情况下进行；如果你没有对子图发出信号，你将需要添加一点策展（添加少量，如 1 GRT 就足够）。
+
+在打开转移工具后，你将能够在“接收钱包地址”字段中输入 L2 钱包地址-请确保你在这里输入的地址是正确的。点击 "Transfer Subgraph" 将提示你在钱包上执行交易（注意，其中包含一定数量的 ETH，用于支付 L2 燃气费用）；这将启动转移并废弃你的 L1 子图（关于背后发生的详细信息，请参见上面的“理解信号、你的 L1 子图和查询 URL 的变化”）。
+
+如果你执行了此步骤，确保在 7 天内完成第 3 步，否则子图和你的信号 GRT 将会丢失。这是由于 L1-L2 消息在 Arbitrum 上的工作方式：通过跨链桥发送的消息是“可重试的票据”，必须在 7 天内执行。如果 Arbitrum 上的燃气价格飙升，初始执行可能需要重试。
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## 第 2 步：等待子图到达 L2
+
+在开始转移后，发送你的 L1 子图到 L2 的消息必须通过 Arbitrum 跨链桥传播。这大约需要 20 分钟（跨链桥会等待包含交易的主网区块在潜在的链重组方面是“安全”的）。
+
+等待时间结束后，Arbitrum 将尝试自动在 L2 合约上执行转移。
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## 第 3 步：确认转移
+
+在大多数情况下，这一步将自动执行，因为步骤 1 中包含的 L2 燃气应该足以执行在 Arbitrum 合约上接收子图的交易。但是，在某些情况下，Arbitrum 上的燃气价格激增可能导致此自动执行失败。在这种情况下，发送你的子图到 L2 的“票据”将处于挂起状态，并在 7 天内需要重试。
+
+如果是这种情况，你将需要使用在 Arbitrum 上有一些 ETH 的 L2 钱包进行连接，将你的钱包网络切换到 Arbitrum，并点击“Confirm Transfer”以重试交易。
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## 第 4 步：在 L2 上完成转移
+
+此时，你的子图和 GRT 已在 Arbitrum 上接收，但子图尚未发布。你需要使用你选择的 L2 钱包连接，将钱包网络切换到 Arbitrum，并点击“发布子图”。
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+这将发布子图，使在 Arbitrum 上运行的索引人可以开始提供服务。它还将使用从 L1 转移过来的 GRT 铸造策展信号。
+
+## 第 5 步：更新查询 URL
+
+你的子图已成功转移到 Arbitrum！要查询子图，新的 URL 将为：
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+请注意，Arbitrum 上的子图 ID 将与你在主网上的 ID 不同，但你始终可以在 Explorer 或 Studio 上找到它。如上所述（参见“理解信号、你的 L1 子图和查询 URL 的变化”），旧的 L1 URL 将在短期内支持，但一旦子图在 L2 上同步，应尽快切换查询到新的地址。
+
+## 如何将你的策展转移到 Arbitrum（L2）
+
+## 理解子图转移到 L2 时的策展处理
+
+当子图所有者将子图转移到 Arbitrum 时，所有子图的策展信号都会同时转换为 GRT。这适用于“自动迁移”的信号，即不特定于子图版本或部署的信号，而是遵循子图的最新版本。
+
+这种信号到 GRT 的转换与子图所有者在 L1 上废弃子图时会发生的情况相同。当子图被废弃或转移时，所有策展信号都将同时被“销毁”（使用策展绑定曲线），并且由 GNS 智能合约（负责子图升级和自动迁移信号的合约）持有产生的 GRT。因此，每个在子图上的策展人都对那些 GRT 有一个按份额比例的提取权。
+
+其中一部分与子图所有者对应的 GRT 会与子图一起发送到 L2。
+
+此时，策展的GRT将不再累积任何查询费用，因此，策展人可以选择撤回其GRT或将其转移到L2上的同一子图中，这样可以用于铸造新的策展信号。没有必要匆忙进行此操作，因为GRT可以无限期持有，每个人的份额比例无关紧要。
+
+## 选择你的 L2 钱包
+
+如果决定将策展的GRT转移到L2，可以选择一个不同的钱包作为L2上的策展信号的所有者。
+
+如果使用的是像 Metamask 这样的“普通”钱包（即外部拥有的账户或EOA，即不是智能合约钱包），则此操作是可选的，并建议保持与L1相同的策展人地址。
+
+如果你使用的是智能合约钱包，如多签钱包（例如 Safe），则必须选择不同的L2钱包地址，因为这个账户很可能仅存在于主网，无法使用此钱包在 Arbitrum 上进行交易。如果希望继续使用智能合约钱包或多签钱包，请在 Arbitrum 上创建一个新的钱包，并使用其地址作为L2接收钱包地址。
+
+**使用您自己控制的、可以在 Arbitrum 上进行交易的钱包地址非常重要，否则策展将丢失且无法恢复。**
+
+## 发送策展到L2：步骤1
+
+在开始转移之前，您必须决定哪个地址将在L2上拥有策展信号（参见上文的“选择您的L2钱包”），并建议您当需要在L2上重试消息执行时，提前转移一些用于手续费的 ETH到Arbitrum 上。您可以在某些交易所购买 ETH，并直接提款到 Arbitrum，或者您可以使用 Arbitrum 跨链桥将 ETH 从主网钱包发送到 L2： [bridge.arbitrum.io](http://bridge.arbitrum.io) - 由于 Arbitrum 上的燃料费用非常低，您可能只需要一小笔金额，例如 0.01 ETH 应该足够了。
+
+如果您策展的子图已经转移到L2，您将在Exploer上看到一条消息，告诉您正在为转移的子图进行策展。
+
+在查看子图页面时，您可以选择撤回或转移策展。点击“将信号转移到 Arbitrum”将打开转移工具。
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+打开转移工具后，如果您没有任何ETH，可能需要向您的钱包添加一些ETH。然后，您将能够在“Receiving wallet address”字段中输入L2钱包地址 - 请确保在此处输入正确的地址。点击转移信号将提示您在钱包上执行交易（注意，包含了一些ETH用于支付L2的燃料费）；这将启动转移过程。
+
+如果执行了此步骤，请确保在不到7天的时间内继续完成第3步，否则您的信号GRT将丢失。这是由于在Arbitrum上的L1-L2消息传递的工作方式：通过跨链桥发送的消息是“可重试的票据”，必须在7天内执行。如果Arbitrum的燃气价格出现波动，初始执行可能需要重试。
+
+## 发送策展到L2：步骤2
+
+开始转移：
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+在开始转移后，发送您的L1策展到L2的消息必须通过Arbitrum跨链桥传播。这大约需要20分钟（跨链桥等待包含交易的主网区块从潜在的链重组中“安全”）。
+
+等待时间结束后，Arbitrum 将尝试自动在 L2 合约上执行转移。
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## 将策展转移到L2：步骤3
+
+在大多数情况下，此步骤将自动执行，因为步骤1中包含的L2燃气应足以执行接收策展的交易。但是，在某些情况下，Arbitrum上燃气价格的激增可能导致此自动执行失败。在这种情况下，发送您的策展到L2的“票据”将处于待处理状态，并在7天内需要重试。
+
+如果是这种情况，你将需要使用在 Arbitrum 上有一些 ETH 的 L2 钱包进行连接，将你的钱包网络切换到 Arbitrum，并点击“Confirm Transfer”以重试交易。
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## 从L1上撤回您的策展
+
+如果您不希望将您的GRT发送到L2，或者您更愿意手动桥接GRT，您可以在L1上撤回您的策展GRT。在子图页面的横幅上，选择“撤回信号”并确认交易；GRT将被发送到您的策展者地址。

From f37a19f047c6899d1c1457490a15e5d2655d33c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:25 -0500
Subject: [PATCH 1061/3820] New translations l2-transfer-tools-guide.mdx (Urdu
 (Pakistan))

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/ur/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/ur/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/ur/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..038325aae861
--- /dev/null
+++ b/website/pages/ur/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 ٹرانسفر ٹولز گائڈ
+---
+
+گراف نے Arbitrum One پر L2 پر منتقل ہونا آسان کر دیا ہے۔ پروٹوکول کے شریک کے لیے، تمام نیٹ ورک کے شرکاء کے لیے L2 میں منتقلی کو ہموار بنانے کے لیے L2 ٹرانسفر ٹولز کا ایک سیٹ موجود ہے۔ یہ ٹولز آپ سے اس بات پر منحصر ہوں گے کہ آپ کیا منتقل کر رہے ہیں۔
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## اپنے سب گراف کو Arbitrum (L2) میں کیسے منتقل کریں
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## اپنے سب گرافس منتقل کرنے کے فوائد
+
+گراف کی کمیونٹی اور بنیادی ڈویلپرز پچھلے سال سے Arbitrum پر جانے کے [تیار کر رہے ہیں](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305)۔ Arbitrum، ایک لیئر 2 یا "L2" بلاکچین، ایتھیریم سے سیکورٹی وراثت میں ملتی ہے لیکن گیس کی فیس بہت کم فراہم کرتی ہے.
+
+جب آپ گراف نیٹ ورک پر اپنا سب گراف شائع یا اپ گریڈ کرتے ہیں، آپ پروٹوکول پر سمارٹ کنٹریکٹ کے ساتھ تعامل کر رہے ہوتے ہیں اور اس کے لیے ایتھیریم کا استعمال کرتے ہوئے گیس کی ادائیگی کی ضرورت ہوتی ہے۔ اپنا سب گراف Arbitrum پر منتقل کر کے، آپ کے سب گراف کی آئندہ کسی بھی اپ ڈیٹ کے لیے گیس کی بہت کم فیس درکار ہو گی۔ کم فیس، اور حقیقت یہ ہے کہ L2 پر کیوریشن بانڈنگ منحنی خطوط فلیٹ ہیں، کیوریٹرز کے لیے آپ کے سب گراف پر کیوریٹ کرنا آسان بناتے ہیں، جس سے آپ کے سب گراف پر انڈیکسرز کے لیے انعامات بڑھ جاتے ہیں۔ یہ کم لاگت والا ماحول بھی انڈیکسرز کے لیے آپ کے سب گراف کو انڈیکس کرنا اور پیش کرنا سستا بناتا ہے۔ Arbitrum پر انڈیکسنگ کے انعامات بڑھیں گے اور آنے والے مہینوں میں ایتھیریم مین نیٹ پر کم ہوں گے، اس لیے زیادہ سے زیادہ انڈیکسرز اپنے حصص کو منتقل کر رہے ہوں گے اور L2 پر اپنی کارروائیاں ترتیب دیں گے.
+
+## یہ سمجھنا کہ سگنل کے ساتھ کیا ہوتا ہے، آپ کا L1 سب گراف اور کیوری URLs
+
+سب گراف کو Arbitrum پر منتقل کرنا Arbitrum GRT بریج کا استعمال کرتا ہے، جو بدلے میں مقامی Arbitrum بریج استعمال کرتا ہے، سب گراف کو L2 پر بھیجنے کے لیے۔ "منتقلی" مین نیٹ پر سب گراف کو فرسودہ کر دے گی اور بریج کا استعمال کرتے ہوئے L2 پر سب گراف کو دوبارہ بنانے کے لیے معلومات بھیجے گی۔ اس میں سب گراف کے مالک کا سگنل شدہ GRT بھی شامل ہوگا، جو بریج کے لیے منتقلی کو قبول کرنے کے لیے صفر سے زیادہ ہونا چاہیے.
+
+جب آپ سب گراف کو منتقل کرنے کا انتخاب کرتے ہیں، یہ تمام سب گراف کے کیوریشن سگنلز کو GRT میں تبدیل کر دے گا۔ یہ مین نیٹ پر سب گراف کو "فرسودہ" کرنے کے مترادف ہے۔ آپ کے کیوریشن کے مطابق GRT سب گراف کے ساتھ L2 کو بھیجا جائے گا، جہاں ان کا استعمال آپ کی جانب سے سگنل دینے کے لیے کیا جائے گا.
+
+دوسرے کیوریٹرز یہ انتخاب کر سکتے ہیں کہ آیا اپنے GRT کا حصہ لینا ہے، یا اسی سب گراف پر اسے L2 پر منٹ سگنل پر منتقل کرنا ہے۔ اگر ایک سب گراف کا مالک اپنا سب گراف L2 میں منتقل نہیں کرتا ہے اور اسے کنٹریکٹ کال کے ذریعے دستی طور پر فرسودہ کرتا ہے، تو کیوریٹرز کو مطلع کیا جائے گا اور وہ اپنا کیوریشن واپس لے سکیں گے.
+
+جیسے ہی سب گراف منتقل ہو جائے گا، چونکہ تمام کیوریشن GRT میں تبدیل ہو چکی ہے، انڈیکسر کو سب گراف کو انڈیکس کرنے کے لیے مزید انعامات نہیں ملیں گے۔ البتہ، ایسے انڈیکسرز ہوں گے جو 1) منتقل ہونے والے سب گرافس کو 24 گھنٹوں تک پیش کرتے رہیں گے، اور 2) فوری طور پر L2 پر سب گراف انڈیکسنگ شروع کر دیں گے۔ چونکہ ان کے انڈیکسرز کے پاس پہلے سے ہی انڈیکسڈ سب گراف موجود ہے، اس لیے سب گراف کے مطابقت پذیر ہونے کا انتظار کرنے کی ضرورت نہیں ہے، اور L2 سب گراف سے تقریبآٓ فورآٓ کیوری کرنا ممکن ہو گا.
+
+L2 سب گراف سے متعلق کیوریز ایک مختلف لنک پر کرنے کی ضرورت ہوگی (`arbitrum-gateway.thegraph.com` پر)، لیکن L1 لنک کم از کم 48 گھنٹے تک کام کرتا رہے گا۔ اس کے بعد، L1 گیٹ وے کیوریز کو L2 گیٹ وے (کچھ وقت کے لیے) پر بھیجے گا، لیکن اس سے تاخیر میں اضافہ ہو جائے گا، اس لیے یہ تجویز کیا جاتا ہے کہ آپ اپنے تمام کیوریز کو جلد از جلد نئے لنک میں تبدیل کر دیں۔
+
+## اپنا L2 والیٹ منتخب کرنا
+
+کب آپ اپنا سب گراف مین نیٹ پر شائع کرتے ہیں، آپ نے اپنا سب گراف بنانے کے لیے کنیکٹڈ والیٹ کا استعمال کیا، اور یہ والیٹ NFT کا مالک ہے جو اس سب گراف کی نمائندگی کرتا ہے اور آپ کو اپ ڈیٹس شائع کرنے کی اجازت دیتا ہے۔
+
+جب سب گراف کو Arbitrum پر منتقل کر رہے ہوں، آپ مختلف والیٹ استعمال کر سکتے ہیں جو L2 پر اس سب گراف NFT کا مالک ہو گا۔
+
+اگر آپ میٹا ماسک کی طرح ایک عام والیٹ استعمال کر رہے ہیں (ایک بیرونی ملکیتی اکاؤنٹ یا EOA، یعنی ایک والیٹ جو سمارٹ کنٹریکٹ نہیں ہے)، تو یہ اختیاری ہے اور یہ نصیحت کی جاتی ہے کہ مالک کا وہی ایڈریس رکھا جائے جو L1 میں ہے۔
+
+اگر آپ سمارٹ کنٹریکٹ والیٹ کا استعمال کر رہے ہیں، جیسے کہ ملٹی سگ (مثال کے طور پر ایک تجوری)، پھر ایک مختلف والیٹ ایڈریس کا استعمال کرنا ضروری ہے، کیونکہ یہ زیادہ امکان ہیں کہ اکاؤنٹ صرف مین نیٹ پر ہو گا اور آپ Arbitrum پر اس والیٹ کا استعمال کرتے ہوئے ٹرانزیکشنز نہیں کر پائیں گے۔ اگر آپ سمارٹ کنٹریکٹ والیٹ یا ملٹی سگ کا استعمال جاری رکھنا چاہتے ہیں، Arbitrum پر نیا والیٹ بنائیں اور اس کا ایڈریس اپنے سب گراف کا L2 مالک ہونے کی حیثیت سے استعمال کریں۔
+
+**یہ بہت ضروری ہے کہ آپ جو والیٹ ایڈریس استعمال کریں اس کا کنٹرول آپ کے پاس ہو، اور جو Arbitrum پر ٹرانزیکشنز کر سکے۔ ورنہ، سب گراف کھو جائے گا اور بازیافت نہیں ہو پائے گا۔**
+
+## منتقلی کی تیاری: کچھ ایتھیریم بریج کرنا
+
+سب گراف کی منتقلی میں بریج کے ذریعے ٹرانزیکشن بھیجنا شامل ہے، اور پھر Arbitrum پر ایک اور ٹرانزیکشن کو انجام دینا۔ پہلی ٹرانزیکشن مین نیٹ پر ایتھیریم کا استعمال کرتی ہے، اور L2 پر پیغام موصول ہونے پر گیس کی ادائیگی کے لیے کچھ ایتھیریم شامل کرتا ہے۔ تاہم، اگر یہ گیس ناکافی ہے، تو آپ کو ٹرانزیکشن کی دوبارہ کوشش کرنی ہوگی اور براہ راست L2 پر گیس کی ادائیگی کرنی ہوگی (یہ ذیل میں "مرحلہ 3: منتقلی کی تصدیق" ہے)۔ یہ مرحلہ **منتقلی شروع کرنے کے 7 دنوں کے اندر انجام دیا جانا چاہیے**۔ مزید یہ کہ، دوسری ٹرانزیکشن ("مرحلہ 4: L2 پر منتقلی کو ختم کرنا") براہ راست Arbitrum پر کیا جائے گا۔ ان وجوہات کی بناء پر، آپ کو Arbitrum والیٹ پر کچھ ایتھیریم کی ضرورت ہوگی۔ اگر آپ ملٹی سگ یا سمارٹ کنٹریکٹ اکاؤنٹ استعمال کر رہے ہیں، تو ایتھیریم کو باقاعدہ (EOA) والیٹ میں ہونا چاہیے جسے آپ ٹرانزیکشن کو انجام دینے کے لیے استعمال کر رہے ہیں، نہ کہ ملٹی سگ والیٹ پر۔
+
+آپ کچھ ایکسچینجیز سے ایتھیریم خرید سکتے ہیں اور سیدھا اسے Arbitrum میں مگوا سکتے ہیں، یا آپ ایتھیریم کو مین نیٹ والیٹ سے L2 پر Arbitrum بریج کا استعمال کرتے ہوئے کر سکتے ہیں: [bridge.arbitrum.io](http://bridge.arbitrum.io)۔ چونکہ Arbitrum پر گیس فیس کم ہوتے ہے، آپ کو صرف چھوٹی سی مقدار کی ضرورت پڑے گی۔ یہ تجویز کیا جاتا ہے کہ آپ اپنی ٹرانزیکشن کی منظوری کے لیے کم حد (مثال کے طور پر 0.01 ایتھیریم) سے شروع کریں۔
+
+## سب گراف ٹرانسفر ٹول تلاش کرنا
+
+آپ L2 ٹرانسفر ٹول تلاش کر سکتے ہیں جب آپ سب گراف سٹوڈیو پر اپنا سب گراف کا پیج دیکھ رہے ہوں گے۔
+
+![ٹرانسفر ٹول](/img/L2-transfer-tool1.png)
+
+یہ ایکسپلورر پر بھی دستیاب ہے اگر آپ اس والیٹ سے کنیکٹڈ ہیں جس کے پاس سب گراف ہے اور ایکسپلورر پر اس سب گراف کے پیج پر:
+
+![L2 پر منتقل کرنا](/img/transferToL2.png)
+
+L2 پر منتقل کرنے کے بٹن پر کلک کرنے سے ٹرانسفر ٹول کھل جائے گا جہاں آپ منتقلی کا عمل شروع کر سکتے ہیں۔
+
+## مرحلہ 1: منتقلی شروع کرنا
+
+منتقلی شروع کرنے سے پہلے، آپ کو یہ فیصلہ کرنا ہو گا کہ L2 پر کون سا ایڈریس سب گراف کا مالک ہو گا (اوپر "اپنے L2 والیٹ کا انتخاب" دیکھیں)، اور یہ پرزور مشورہ دیا جاتا ہے کہ Arbitrum پر پہلے سے ہی گیس کے لیے کچھ ایتھیریم رکھیں (دیکھیں "منتقلی کی تیاری: کچھ ایتھیریم بریج کرنا" اوپر)۔
+
+یہ بھی نوٹ کریں کہ سب گراف کی منتقلی کے لیے سب گراف پر اسی اکاؤنٹ کے ساتھ سگنل کی غیر صفر مقدار کی ضرورت ہوتی ہے جس کے پاس سب گراف ہے۔ اگر آپ نے سب گراف پر اشارہ نہیں کیا ہے تو آپ کو تھوڑا سا کیوریشن شامل کرنا پڑے گا (ایک چھوٹی سی رقم جیسے ایک GRT شامل کرنا کافی ہوگا)۔
+
+ٹرانسفر ٹول کھولنے کے بعد، آپ L2 والیٹ ایڈریس کو "ریسیونگ والیٹ ایڈریس" فیلڈ میں داخل کرنے کے قابل ہو جائیں گے- ** یقینی بنائیں کہ آپ نے یہاں درست ایڈریس لکھا ہے**۔ ٹرانسفر سب گراف پر کلک کرنے سے آپ کو اپنے والیٹ پر ٹرانزیکشن کرنے کا اشارہ ملے گا (نوٹ کریں کہ L2 گیس کی ادائیگی کے لیے کچھ ایتھیریم ویلیو شامل ہے)؛ یہ منتقلی کا آغاز کرے گا اور آپ کے L1 سب گراف کو فرسودہ کر دے گا (پردے کے پیچھے کیا ہو رہا ہے اس کے بارے میں مزید تفصیلات کے لیے اوپر دیکھیں "سگنل کے ساتھ کیا ہوتا ہے، آپ کا L1 سب گراف اور کیوری لنکس" دیکھیں)۔
+
+اگر آپ اس قدم پر عمل کرتے ہیں، تو **یقینی بنائیں کہ آپ 7 دنوں سے بھی کم وقت میں مرحلہ 3 مکمل کرنے تک آگے بڑھیں، ورنہ سب گراف اور آپ کا سگنل GRT ضائع ہو جائے گا۔** یہ اس وجہ سے ہے کہ L1-L2 پیغام رسانی Arbitrum پر کیسے کام کرتی ہے: پیغامات جو بریج کے ذریعے بھیجے گئے "دوبارہ کوشش کے قابل ٹکٹ" ہیں جن پر عمل درآمد 7 دنوں کے اندر ہونا ضروری ہے، اور اگر Arbitrum پر گیس کی قیمت میں اضافہ ہوتا ہے تو ابتدائی عمل درآمد کے لیے دوبارہ کوشش کی ضرورت پڑ سکتی ہے۔
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## مرحلہ 2: سب گراف کے L2 تک پہنچنے کا انتظار کرنا
+
+منتقلی شروع کرنے بعد، وہ پیغام جو آپ کا L1 سب گراف L2 کو بھیجتا ہے اسے Arbitrum بریج کے ذریعے پھیلانا چاہیے۔ اس میں تقریبآٓ 20 منٹ لگتے ہیں (بریج مین نیٹ بلاک کا انتظار کرتا ہے جس میں ٹرانزیکشن کو ممکنہ چین کی بحالی سے "محفوظ" رکھا جاتا ہے)۔
+
+انتظار کا وقت ختم ہونے کے بعد، Arbitrum L2 کنٹریکٹس پر منتقلی کو خودکار طریقے سے انجام دینے کی کوشش کرے گا۔
+
+![ویٹ سکرین](/img/screenshotOfWaitScreenL2.png)
+
+## مرحلہ 3: منتقلی کی تصدیق کرنا
+
+زیادہ تر معاملات میں، یہ مرحلہ خود بخود عمل میں آجائے گا کیونکہ مرحلہ 1 میں شامل L2 گیس اس ٹرانزیکشن کو انجام دینے کے لیے کافی ہونی چاہیے جو Arbitrum کنٹریکٹس پر سب گراف وصول کرتی ہے۔ تاہم، بعض صورتوں میں، یہ ممکن ہے کہ Arbitrum پر گیس کی قیمتوں میں اضافہ اس خود کار طریقے سے عمل کو ناکام بنادے۔ اس صورت میں، "ٹکٹ" جو آپ کے سب گراف کو L2 پر بھیجتا ہے زیر التواء رہے گا اور اسے 7 دنوں کے اندر دوبارہ کوشش کرنے کی ضرورت ہوگی۔
+
+اس صورت میں، آپ کو L2 والیٹ کنیکٹ کرنے کی ضرورت پڑے گی جس میں Arbitrum میں تھوڑا ایتھیریم موجود ہو، اپنے والیٹ نیٹ ورک کو Arbitrum میں سویچ کریں، اور "کنفرم ٹرانسفر" کو ٹرانزیکشن دہرانے کے لیے دبائیں.
+
+![L2 میں منتقلی کی تصدیق کریں](/img/confirmTransferToL2.png)
+
+## مرحلہ 4: L2 پر منتقلی ختم کریں
+
+اس موقع پر، آپ کا سب گراف اور GRT آپ کے Arbitrum میں موصول ہو چکے ہیں، لیکن سب گراف ابھی تک شائع نہیں ہوا۔ آپ کو L2 والیٹ کا استعمال کرتے ہوئے منسلک کرنے کی ضرورت ہو گی جسے آپ نے وصول کرنے والے والیٹ کے طور پر منتخب کیا ہے، اپنے والیٹ نیٹ ورک کو Arbitrum میں سویچ کریں ، اور "سب گراف شائع کریں" پر کلک کریں۔
+
+![سب گراف شائع کریں](/img/publishSubgraphL2TransferTools.png)
+
+![سب گراف کے شائع ہونے کا انتظار کریں](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+یہ سب گراف کو شائع کرے گا تا کہ انڈیکسرز جو Arbitrum پر کام کر رہے ہیں اسے پیش کرنا شروع کر سکیں۔ یہ GRT کا استعمال کرتے ہوئے کیوریشن سگنل بھی دے گا جو L1 سے منتقل کیا گیا ہے.
+
+## مرحلہ 5: کیوری لنک اپ ڈیٹ کریں
+
+آپ کا سب گراف کامیابی کے ساتھ Arbitrum پر منتقل کر دیا گیا ہے! سب گراف کو کیوری کرنے کے لیے، نیا لنگ ہو گا:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+نوٹ کریں کہ Arbitrum پر سب گراف ID آپ کے مین نیٹ پر موجود ایک سے مختلف ہوگی، لیکن آپ اسے ہمیشہ ایکسپلورر یا سٹوڈیو پر تلاش کر سکتے ہیں۔ جیسا کہ اوپر بتایا گیا ہے (دیکھیں "سگنل کے ساتھ کیا ہوتا ہے، آپ کے L1 سب گراف اور کیوری والے لنکس") پرانا L1 لنک تھوڑی دیر کے لیے سپورٹ کیا جائے گا، لیکن آپ کو اپنی کیوریز کو نئے ایڈریس پر تبدیل کر دینا چاہیے جیسے ہی سب گراف کی مطابقت پذیری L2 پر ہو جائے گی.
+
+## اپنی کیوریشن کو کیسے Arbitrum (L2) پر منتقل کیا جائے
+
+## یہ سمجھنا کہ L2 میں سب گراف کی منتقلی پر کیوریشن کا کیا ہوتا ہے
+
+جب سب گراف کا مالک سب گراف کو Arbitrum پر منتقل کرتا ہے، سب گراف کے تمام سگنلز اسی وقت GRT میں تبدیل ہو جاتے ہیں۔ یہ "آٹو مائیگریٹڈ" پر لاگو ہوتا ہے، یعنی وہ سگنل جو سب گراف ورزن یا تعیناتی کے لیے مخصوص نہیں ہے لیکن یہ سب گراف کے تازہ ترین ورزن کی پیروی کرتا ہے۔
+
+سگنل سے GRT میں یہ تبدیلی وہی ہے جیسا کہ اگر سب گراف کے مالک نے L1 میں سب گراف کو فرسودہ کیا تو کیا ہوگا۔ جب سب گراف کو فرسودہ یا منتقل کیا جاتا ہے، تو تمام کیوریشن سگنل بیک وقت "برن" ہو جاتے ہیں (کیوریشن بانڈنگ کریو کا استعمال کرتے ہوئے) اور نتیجے میں GRT سمارٹ کنٹریکٹ GNS کے پاس ہوتا ہے (یہ وہ کنٹریکٹ ہے جو سب گراف اپ گریڈ اور خودکار منتقلی سگنل کو ہینڈل کرتا ہے)۔ اس لیے اس سب گراف پر ہر کیوریٹر کا دعویٰ ہے کہ وہ سب گراف کے حصص کی مقدار کے متناسب GRT پر ہے۔
+
+سب گراف کے مالک کے مطابق ان GRT کا ایک حصہ سب گراف کے ساتھ L2 کو بھیجا جاتا ہے۔
+
+اس مقام پر، کیویرٹڈ GRT مزید کیوری کی فیس جمع نہیں کرے گا، لہذا کیوریٹرز اپنا GRT واپس لینے یا اسے L2 پر اسی سب گراف میں منتقل کرنے کا انتخاب کر سکتے ہیں، جہاں اسے نئے کیویریشن سگنل کے لیے استعمال کیا جا سکتا یے۔ ایسا کرنے میں کوئی جلدی نہیں ہے کیونکہ GRT غیر معینہ مدت کے لیے مدد کی جا سکتی ہے اور ہر کسی کو اس کے حصص کے متناسب رقم ملتی ہے، چاہے وہ ایسا کرتے ہی کیوں نہ ہوں۔
+
+## اپنا L2 والیٹ منتخب کرنا
+
+اگر آپ اپنے کیوریٹڈ GRT کو L2 پر منتقل کرنے کا فیصلہ کرتے ہیں، آپ الگ والیٹ کا انتخاب کر سکتے ہیں جو کیوریشن سگنل کا مالک ہو گا۔
+
+اگر آپ میٹا ماسک کی طرح "عام" والیٹ استعمال کر رہے ہیں (ایک بیرونی ملکیتی اکاؤنٹ یا EOA، یعنی ایک والیٹ جو سمارٹ کنٹریکٹ نہیں ہے)، تو یہ اختیاری اور یہ نصیحت کی جاتی ہے کہ وہی کیوریٹر ایڈریس استعمال کیا جائے جو L1 میں استعمال کیا تھا۔
+
+اگر آپ سمارٹ کنٹریکٹ والیٹ استعمال کر رہے ہیں، جیسے ملٹی سگ(مثال کے طور پر سیف)، پھر کوئی الگ والیٹ استعمال کرنا ضروری ہو گا، کیوں کے زیادہ امکان ہے کہ یہ اکاؤنٹ صرف مین نیٹ پر ہے اور آپ اس والیٹ کا استعمال کرتے ہوئے Arbitrum پر کوئی ٹرانزیکشن نہیں کر پائیں گے۔ اگر آپ سمارٹ کنٹریکٹ یا ملٹی سگ کا استعمال جاری رکھنا چاہتے ہیں، Arbitrum پر نیا والیٹ بنائیں اور اس کا ایڈریس L2 وصول کرنے والے والیٹ ایڈریس کے طور پر استعمال کریں۔
+
+**یہ بہت ضروری ہے کہ آپ وہی والیٹ استعمال کریں جس پر آپ کا کنٹرول ہے، اور جو Arbitrum پر ٹرانزیکشن کر پائیں، کیونکہ بصورت دیگر کیوریشن ضائع ہو جائے گی اور بازیافت نہیں ہو سکتی۔**
+
+## کیوریشن سگنل L2 پر بھیجنا: مرحلہ 1
+
+منتقلی شروع کرنے سے پہلے، آپ کو یہ فیصلہ کرنا ہوگا کہ L2 پر کیوریشن کا کون سا ایڈریس ہوگا (اوپر "اپنے L2 والیٹ کا انتخاب" دیکھیں)، اور یہ تجویز کی جاتی ہے کہ اگر آپ کو L2 پر پیغام کے نفاذ کی دوبارہ کوشش کرنے کی ضرورت ہو تو Arbitrum پر پہلے سے ہی بریج شدہ گیس کے لیے کچھ ایتھیریم رکھیں۔ آپ کچھ ایکسچینجز پر ایتھیریم خرید سکتے ہیں اور اسے براہ راست Arbitrum میں واپس لے سکتے ہیں، یا آپ ایتھیریم کو مین نیٹ والیٹ سے L2 پر بھیجنے کے لیے Arbitrum بریج کا استعمال کر سکتے ہیں: [bridge.arbitrum.io](http://bridge.arbitrum.io) - چونکہ Arbitrum پر گیس کی فیس بہت کم ہیں، آپ کو صرف تھوڑی سی رقم کی ضرورت ہوگی، جیسے۔ 0.01 ایتھیریم شاید کافی سے زیادہ ہو گا۔
+
+اگر جو سب گراف آپ کیویرٹ کر رہے ہیں L2 پر منتقل ہو گیا ہے، آپ ایکسپلورر پر ایک میسج دیکھیں گے جو بتا رہا ہو گا کہ آپ منتقل ہوئے سب گراف پر کیوریٹ کر رہے ہیں۔
+
+سب گراف پیج پر دیکھتے ہوئے، آپ کیوریشن واپس لینے یا منتقل کرنے کا انتخاب کر سکتے ہیں۔ "Arbitrum پر سگنل منتقل کریں" پر کلک کرنے سے ٹرانسفر ٹول کھل جائے گا۔
+
+![ٹرانسفر سگنل](/img/transferSignalL2TransferTools.png)
+
+ٹرانسفر ٹول کھولنے کے بعد، اگر آپ کے پاس نہیں ہے تو آپ کو اپنے والیٹ میں کچھ ایتھیریم شامل کرنے کے لیے کہا جا سکتا ہے۔ پھر آپ L2 والیٹ ایڈریس کو "ریسیونگ والیٹ ایڈریس" فیلڈ میں داخل کرنے کے قابل ہو جائیں گے - **یقینی بنائیں کہ آپ نے یہاں درست ایڈریس درج کیا ہے**۔ ٹرانسفر سگنل پر کلک کرنے سے آپ کو اپنے والیٹ پر ٹرانزیکشن کرنے کا اشارہ ملے گا (نوٹ کریں کہ L2 گیس کی ادائیگی کے لیے کچھ ایتھیریم ویلیو شامل ہے)؛ یہ منتقلی شروع کرے گا.
+
+اگر آپ اس قدم پر عمل کرتے ہیں، **یقینی بنائیں کہ آپ 7 دنوں سے بھی کم وقت میں مرحلہ 3 مکمل کرنے تک آگے بڑھیں گے، ورنہ آپ کے سگنل GRT ضائع ہو جائیں گے۔**یہ Arbitrum پر L1-L2 پیغام رسائی کے کام کرنے کے طریقے کی وجہ سے ہے: پیغامات جو اس کے ذریعے بھیجے جاتے ہیں۔ بریج "دوبارہ کوشش کے قابل ٹکٹس" ہیں جن کو 7 دنوں کے اندر مکمل کرنا ضروری ہے، اور اگر Arbitrum پر گیس کی قیمت میں اضافہ ہوتا ہے تو ابتدائی عملدرآمد کے لیے دوبارہ کوشش کی ضرورت پڑ سکتی ہے۔
+
+## L2 پر کیوریشن بھیجنا: مرحلہ 2
+
+منتقلی شروع کرنا:
+
+![L2 پر سگنل بھیجیں](/img/sendingCurationToL2Step2First.png)
+
+منتقلی شروع کرنے کے بعد، وہ پیغام جو آپ کا L1 کیوریشن L2 کو بھیجتا ہے اسے Arbitrum بریج کے ذریعے پھیلانا چاہیے۔ اس کو تقریبآٓ 20 منٹ لگیں گے(بریج مین نیٹ بلاک کا انتظار کرتا ہے جس میں ٹرانزیکشن کو ممکنہ چین کی بحالی سے "محفوظ" رکھا جاتا ہے)۔
+
+انتظار کا وقت ختم ہونے کے بعد، Arbitrum L2 کنٹریکٹس پر منتقلی کو خودکار طریقے سے انجام دینے کی کوشش کرے گا۔
+
+![L2 پر کیوریشن سگنل بھیجنا](/img/sendingCurationToL2Step2Second.png)
+
+## L2 پر کیوریشن بھیجنا: مرحلہ 3
+
+زیادہ تر معاملات میں، یہ مرحلہ خود بخود عمل میں آجائے گا کیونکہ مرحلہ 1 میں شامل L2 گیس اس ٹرانزیکشن کو انجام دینے کے لیے کافی ہونی چاہیے جو Arbitrum کنٹریکٹس پر کیوریشن حاصل کرتی ہے۔ تاہم، بعض صورتوں میں، یہ ممکن ہے کہ Arbitrum پر گیس کی قیمتوں میں اضافہ اس خود کار طریقے سے عمل کو ناکام بنادے۔ اس صورت میں، "ٹکٹ" جو آپ کی کیوریشن L2 کو بھیجتی ہے وہ زیر التواء رہے گی اور 7 دنوں کے اندر دوبارہ کوشش کی ضرورت ہوگی۔
+
+اس صورت میں، آپ کو L2 والیٹ کنیکٹ کرنے کی ضرورت پڑے گی جس میں Arbitrum میں تھوڑا ایتھیریم موجود ہو، اپنے والیٹ نیٹ ورک کو Arbitrum میں سویچ کریں، اور "کنفرم ٹرانسفر" کو ٹرانزیکشن دہرانے کے لیے دبائیں.
+
+![L2 پر سگنل بھیجیں](/img/L2TransferToolsFinalCurationImage.png)
+
+## L1 پر اپنی کیوریشن واپس لینا
+
+اگر آپ اپنے GRT کو L2 پر نہیں بھیجنا پسند کرتے ہیں، یا آپ GRT کو دستی طور پر بریج کرنا چاہتے ہیں، تو آپ L1 پر اپنا کیوریٹ شدہ GRT واپس لے سکتے ہیں۔ سب گراف کے پیج پر بینر پر، "سگنل واپس لیں" کا انتخاب کریں اور ٹرانزیکشن کی تصدیق کریں۔ GRT آپ کے کیوریٹر کے ایڈریس پر بھیج دیا جائے گا۔

From ab839eff557277b35ad53672504228ec6568bdd3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:26 -0500
Subject: [PATCH 1062/3820] New translations l2-transfer-tools-guide.mdx
 (Vietnamese)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/vi/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/vi/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/vi/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..0c17876881d9
--- /dev/null
+++ b/website/pages/vi/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: Hướng dẫn sử dụng công cụ chuyển L2
+---
+
+The Graph has made it easy to move to L2 on Arbitrum One. For each protocol participant, there are a set of L2 Transfer Tools to make transferring to L2 seamless for all network participants. These tools will require you to follow a specific set of steps depending on what you are transferring.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## How to transfer your subgraph to Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Benefits of transferring your subgraphs
+
+The Graph's community and core devs have [been preparing](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) to move to Arbitrum over the past year. Arbitrum, a layer 2 or "L2" blockchain, inherits the security from Ethereum but provides drastically lower gas fees.
+
+When you publish or upgrade your subgraph to The Graph Network, you're interacting with smart contracts on the protocol and this requires paying for gas using ETH. By moving your subgraphs to Arbitrum, any future updates to your subgraph will require much lower gas fees. The lower fees, and the fact that curation bonding curves on L2 are flat, also make it easier for other Curators to curate on your subgraph, increasing the rewards for Indexers on your subgraph. This lower-cost environment also makes it cheaper for Indexers to index and serve your subgraph. Indexing rewards will be increasing on Arbitrum and decreasing on Ethereum mainnet over the coming months, so more and more Indexers will be transferring their stake and setting up their operations on L2.
+
+## Understanding what happens with signal, your L1 subgraph and query URLs
+
+Transferring a subgraph to Arbitrum uses the Arbitrum GRT bridge, which in turn uses the native Arbitrum bridge, to send the subgraph to L2. The "transfer" will deprecate the subgraph on mainnet and send the information to re-create the subgraph on L2 using the bridge. It will also include the subgraph owner's signaled GRT, which must be more than zero for the bridge to accept the transfer.
+
+When you choose to transfer the subgraph, this will convert all of the subgraph's curation signal to GRT. This is equivalent to "deprecating" the subgraph on mainnet. The GRT corresponding to your curation will be sent to L2 together with the subgraph, where they will be used to mint signal on your behalf.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph. If a subgraph owner does not transfer their subgraph to L2 and manually deprecates it via a contract call, then Curators will be notified and will be able to withdraw their curation.
+
+As soon as the subgraph is transferred, since all curation is converted to GRT, Indexers will no longer receive rewards for indexing the subgraph. However, there will be Indexers that will 1) keep serving transferred subgraphs for 24 hours, and 2) immediately start indexing the subgraph on L2. Since these Indexers already have the subgraph indexed, there should be no need to wait for the subgraph to sync, and it will be possible to query the L2 subgraph almost immediately.
+
+Queries to the L2 subgraph will need to be done to a different URL (on `arbitrum-gateway.thegraph.com`), but the L1 URL will continue working for at least 48 hours. After that, the L1 gateway will forward queries to the L2 gateway (for some time), but this will add latency so it is recommended to switch all your queries to the new URL as soon as possible.
+
+## Chọn ví L2 của bạn
+
+When you published your subgraph on mainnet, you used a connected wallet to create the subgraph, and this wallet owns the NFT that represents this subgraph and allows you to publish updates.
+
+When transferring the subgraph to Arbitrum, you can choose a different wallet that will own this subgraph NFT on L2.
+
+Nếu bạn đang sử dụng ví "thông thường" như MetaMask (Tài khoản thuộc sở hữu bên ngoài hoặc EOA, tức là ví không phải là hợp đồng thông minh), thì đây là tùy chọn và bạn nên giữ cùng địa chỉ chủ sở hữu như trong L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 owner of your subgraph.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum. Otherwise, the subgraph will be lost and cannot be recovered.**
+
+## Preparing for the transfer: bridging some ETH
+
+Transferring the subgraph involves sending a transaction through the bridge, and then executing another transaction on Arbitrum. The first transaction uses ETH on mainnet, and includes some ETH to pay for gas when the message is received on L2. However, if this gas is insufficient, you will have to retry the transaction and pay for the gas directly on L2 (this is "Step 3: Confirming the transfer" below). This step **must be executed within 7 days of starting the transfer**. Moreover, the second transaction ("Step 4: Finishing the transfer on L2") will be done directly on Arbitrum. For these reasons, you will need some ETH on an Arbitrum wallet. If you're using a multisig or smart contract account, the ETH will need to be in the regular (EOA) wallet that you are using to execute the transactions, not on the multisig wallet itself.
+
+You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Since gas fees on Arbitrum are lower, you should only need a small amount. It is recommended that you start at a low threshold (0.e.g. 01 ETH) for your transaction to be approved.
+
+## Finding the subgraph Transfer Tool
+
+You can find the L2 Transfer Tool when you're looking at your subgraph's page on Subgraph Studio:
+
+![công cụ chuyển](/img/L2-transfer-tool1.png)
+
+It is also available on Explorer if you're connected with the wallet that owns a subgraph and on that subgraph's page on Explorer:
+
+![Chuyển sang L2](/img/transferToL2.png)
+
+Nhấp vào nút Chuyển sang L2 sẽ mở công cụ chuyển nơi bạn có thể bắt đầu quá trình chuyển.
+
+## Step 1: Starting the transfer
+
+Before starting the transfer, you must decide which address will own the subgraph on L2 (see "Choosing your L2 wallet" above), and it is strongly recommend having some ETH for gas already bridged on Arbitrum (see "Preparing for the transfer: bridging some ETH" above).
+
+Also please note transferring the subgraph requires having a nonzero amount of signal on the subgraph with the same account that owns the subgraph; if you haven't signaled on the subgraph you will have to add a bit of curation (adding a small amount like 1 GRT would suffice).
+
+After opening the Transfer Tool, you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Subgraph will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer and deprecate your L1 subgraph (see "Understanding what happens with signal, your L1 subgraph and query URLs" above for more details on what goes on behind the scenes).
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or the subgraph and your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retry-able tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Step 2: Waiting for the subgraph to get to L2
+
+After you start the transfer, the message that sends your L1 subgraph to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Màn hình chờ](/img/screenshotOfWaitScreenL2.png)
+
+## Step 3: Confirming the transfer
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the subgraph on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your subgraph to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Xác nhận chuyển sang L2](/img/confirmTransferToL2.png)
+
+## Step 4: Finishing the transfer on L2
+
+At this point, your subgraph and GRT have been received on Arbitrum, but the subgraph is not published yet. You will need to connect using the L2 wallet that you chose as the receiving wallet, switch your wallet network to Arbitrum, and click "Publish Subgraph."
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+This will publish the subgraph so that Indexers that are operating on Arbitrum can start serving it. It will also mint curation signal using the GRT that were transferred from L1.
+
+## Bước 5: Cập nhật URL truy vấn
+
+Your subgraph has been successfully transferred to Arbitrum! To query the subgraph, the new URL will be :
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Note that the subgraph ID on Arbitrum will be a different than the one you had on mainnet, but you can always find it on Explorer or Studio. As mentioned above (see "Understanding what happens with signal, your L1 subgraph and query URLs") the old L1 URL will be supported for a short while, but you should switch your queries to the new address as soon as the subgraph has been synced on L2.
+
+## How to transfer your curation to Arbitrum (L2)
+
+## Understanding what happens to curation on subgraph transfers to L2
+
+When the owner of a subgraph transfers a subgraph to Arbitrum, all of the subgraph's signal is converted to GRT at the same time. This applies to "auto-migrated" signal, i.e. signal that is not specific to a subgraph version or deployment but that follows the latest version of a subgraph.
+
+This conversion from signal to GRT is the same as what would happen if the subgraph owner deprecated the subgraph in L1. When the subgraph is deprecated or transferred, all curation signal is "burned" simultaneously (using the curation bonding curve) and the resulting GRT is held by the GNS smart contract (that is the contract that handles subgraph upgrades and auto-migrated signal). Each Curator on that subgraph therefore has a claim to that GRT proportional to the amount of shares they had for the subgraph.
+
+A fraction of these GRT corresponding to the subgraph owner is sent to L2 together with the subgraph.
+
+At this point, the curated GRT will not accrue any more query fees, so Curators can choose to withdraw their GRT or transfer it to the same subgraph on L2, where it can be used to mint new curation signal. There is no rush to do this as the GRT can be help indefinitely and everybody gets an amount proportional to their shares, irrespective of when they do it.
+
+## Chọn ví L2 của bạn
+
+If you decide to transfer your curated GRT to L2, you can choose a different wallet that will own the curation signal on L2.
+
+If you're using a "regular" wallet like Metamask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same Curator address as in L1.
+
+Nếu bạn đang sử dụng ví hợp đồng thông minh, chẳng hạn như multisig (ví dụ: Safe), thì việc chọn địa chỉ ví L2 khác là bắt buộc, vì rất có thể tài khoản này chỉ tồn tại trên mạng chính và bạn sẽ không thể thực hiện giao dịch trên Arbitrum bằng ví này. Nếu bạn muốn tiếp tục sử dụng ví hợp đồng thông minh hoặc multisig, hãy tạo một ví mới trên Arbitrum và sử dụng địa chỉ của nó làm địa chỉ ví nhận L2.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum, as otherwise the curation will be lost and cannot be recovered.**
+
+## Sending curation to L2: Step 1
+
+Before starting the transfer, you must decide which address will own the curation on L2 (see "Choosing your L2 wallet" above), and it is recommended having some ETH for gas already bridged on Arbitrum in case you need to retry the execution of the message on L2. You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - since gas fees on Arbitrum are so low, you should only need a small amount, e.g. 0.01 ETH will probably be more than enough.
+
+If a subgraph that you curate to has been transferred to L2, you will see a message on Explorer telling you that you're curating to a transferred subgraph.
+
+When looking at the subgraph page, you can choose to withdraw or transfer the curation. Clicking on "Transfer Signal to Arbitrum" will open the transfer tool.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+After opening the Transfer Tool, you may be prompted to add some ETH to your wallet if you don't have any. Then you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Signal will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer.
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retryable tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+## Sending curation to L2: step 2
+
+Starting the transfer:
+
+![Gửi tín hiệu tới L2](/img/sendingCurationToL2Step2First.png)
+
+After you start the transfer, the message that sends your L1 curation to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Sending curation to L2: step 3
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the curation on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your curation to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Gửi tín hiệu tới L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Withdrawing your curation on L1
+
+If you prefer not to send your GRT to L2, or you'd rather bridge the GRT manually, you can withdraw your curated GRT on L1. On the banner on the subgraph page, choose "Withdraw Signal" and confirm the transaction; the GRT will be sent to your Curator address.

From 3f42e525a5469a792389ce77918d819828d19703 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:27 -0500
Subject: [PATCH 1063/3820] New translations l2-transfer-tools-guide.mdx
 (Marathi)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/mr/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/mr/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/mr/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..91359ac2a7ff
--- /dev/null
+++ b/website/pages/mr/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 Transfer Tools Guide
+---
+
+ग्राफने Arbitrum One वर L2 वर जाणे सोपे केले आहे. प्रत्येक प्रोटोकॉल सहभागीसाठी, सर्व नेटवर्क सहभागींसाठी L2 मध्ये हस्तांतरण अखंडपणे करण्यासाठी L2 हस्तांतरण साधनांचा संच आहे. तुम्ही काय हस्तांतरित करत आहात त्यानुसार या साधनांसाठी तुम्हाला चरणांच्या विशिष्ट संचाचे अनुसरण करणे आवश्यक आहे.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## तुमचा सबग्राफ आर्बिट्रम (L2) वर कसा हस्तांतरित करायचा
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## तुमचे सबग्राफ हस्तांतरित करण्याचे फायदे
+
+मागील वर्षापासून, The Graph चे समुदाय आणि मुख्य डेव्हलपर [been preparing](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305)करीत होते त्याच्या गोष्टीसाठी आर्बिट्रमवर जाण्याची. आर्बिट्रम, एक श्रेणी 2 किंवा "L2" ब्लॉकचेन, ईथेरियमकिडून सुरक्षा अनुभवतो परंतु काही लोअर गॅस फी प्रदान करतो.
+
+जेव्हा तुम्ही आपल्या सबग्राफला The Graph Network वर प्रकाशित किंवा अपग्रेड करता तेव्हा, तुम्ही प्रोटोकॉलवरच्या स्मार्ट कॉन्ट्रॅक्ट्ससोबत संवाद साधता आहात आणि हे ईथ वापरून गॅससाठी पैसे देता येतात. आर्बिट्रमवर तुमच्या सबग्राफला हल्लीक अपडेट्सची आवश्यकता असल्यामुळे आपल्याला खूप कमी गॅस फी परतण्यात आलेली आहे. या कमी फीस, आणि लोअर करण्याची बंद पट आर्बिट्रमवर असल्याचे, तुमच्या सबग्राफवर इतर क्युरेटरसाठी सुविधा असताना तुमच्या सबग्राफवर कुणासही क्युरेशन करणे सोपे होते, आणि तुमच्या सबग्राफवर इंडेक्सरसाठी पुरस्कारांची वाढ होतील. या किमतीसवर्गीय वातावरणात इंडेक्सरसाठी सबग्राफला सूचीबद्ध करणे आणि सेव करणे सोपे होते. आर्बिट्रमवर इंडेक्सिंग पुरस्कारे आणि ईथेरियम मेननेटवर किमतीची वाढ होणारी आहेत, आणि यामुळे अगदी अधिक इंडेक्सरस त्याची स्थानिकता हस्तांतरित करत आहेत आणि त्यांचे ऑपरेशन्स L2 वर स्थापित करत आहेत.".
+
+## सिग्नल, तुमचा L1 सबग्राफ आणि क्वेरी URL सह काय होते हे समजून घेणे
+
+सबग्राफला आर्बिट्रमवर हस्तांतरित करण्यासाठी, आर्बिट्रम GRT सेतूक वापरला जातो, ज्याच्या परत आर्बिट्रमच्या मूळ सेतूकाचा वापर केला जातो, सबग्राफला L2 वर पाठवण्यासाठी. "हस्तांतरण" मुख्यनेटवर सबग्राफची वैल्यू कमी करणारा आहे आणि सेतूकाच्या ब्रिजच्या माध्यमातून लॉकल 2 वर सबग्राफ पुन्हा तयार करण्याची माहिती पाठवण्यात आली आहे. त्यामुळे हा "हस्तांतरण" मुख्यनेटवरील सबग्राफला अस्तित्वातून टाकेल आणि त्याची माहिती ब्रिजवार L2 वर पुन्हा तयार करण्यात आली आहे. हस्तांतरणात सबग्राफ मालकाची संकेतित GRT समाविष्ट केली आहे, ज्याची उपसंकेतित GRT मूळ सेतूकाच्या ब्रिजकडून हस्तांतरित करण्यासाठी जास्तीत जास्त शून्यापेक्षा असणे आवश्यक आहे.
+
+जेव्हा तुम्ही सबग्राफला हस्तांतरित करण्याची निवड करता, हे सबग्राफचे सर्व क्युरेशन सिग्नल GRT मध्ये रूपांतरित होईल. ह्याचे मुख्यनेटवर "अप्रामाणिक" घेण्याच्या अर्थाने आहे. तुमच्या क्युरेशनसह संबंधित GRT सबग्राफसह पाठवली जाईल, त्यामुळे त्यांचा L2 वर पाठवला जाईल, त्यातून त्यांचा नमूद कुंडला तयार केला जाईल.
+
+इतर क्युरेटरस स्वत: त्यांच्या भागाचा GRT परत घेण्याची किंवा त्याच्या एकल सबग्राफवर त्यांच्या सिग्नल तयार करण्यासाठी हस्तांतरित करण्याची पर्वानगी देऊ शकतात. जर सबग्राफ मालक त्याच्या सबग्राफला L2 वर हस्तांतरित करत नसता आणि त्याच्या कॉन्ट्रॅक्ट कॉलद्वारे मौना करतो, तर क्युरेटरसला सूचना दिली जाईल आणि त्यांना आपल्याच्या क्युरेशनची परवानगी वापरून परत घेतली जाईल.
+
+सबग्राफ हस्तांतरित केल्यानंतर, क्युरेशन सर्व GRT मध्ये रूपांतरित केल्यामुळे इंडेक्सरसला सबग्राफच्या इंडेक्सिंगसाठी पुरस्कार मिळवत नाही. परंतु, 24 तासांसाठी हस्तांतरित केलेल्या सबग्राफवर सेवा देणारे इंडेक्सर असतील आणि 2) L2 वर सबग्राफची इंडेक्सिंग प्रारंभ करतील. ह्या इंडेक्सरसांच्या पासून आधीपासूनच सबग्राफची इंडेक्सिंग आहे, म्हणून सबग्राफ सिंक होण्याची वाटचाल नसल्याची आवश्यकता नसून, आणि L2 सबग्राफची क्वेरी करण्यासाठी त्याच्यासाठी वाटचाल नसेल.
+
+L2 सबग्राफला क्वेरीसाठी वेगवेगळे URL वापरण्याची आवश्यकता आहे ('arbitrum-gateway.thegraph.com' वरील), परंतु L1 URL किमान 48 तासांसाठी काम करणार आहे. त्यानंतर, L1 गेटवे वेगवेगळ्या क्वेरीला L2 गेटवेला पुर्वानुमान देईल (काही कालावधीसाठी), परंतु त्यामुळे द्रुतिकरण वाढतो, म्हणजे तुमच्या क्वेरीस सर्व किंवा नवीन URL वर स्विच करणे शक्य आहे.
+
+## तुमचे L2 वॉलेट निवडत आहे
+
+तुम्ही तुमच्या सबग्राफची मेननेटवर प्रकाशित केल्यास, तुम्ही सबग्राफ तयार करण्यासाठी एक संयुक्त केलेल्या वॉलेटचा वापर केला होता, आणि हा वॉलेट हा सबग्राफ प्रतिनिधित्व करणारा NFT मिळवतो, आणि तुम्हाला अपडेट प्रकाशित करण्याची परवानगी देतो.
+
+सबग्राफ आर्बिट्रममध्ये हस्तांतरित करताना, तुम्ही वेगळे वॉलेट निवडू शकता जे L2 वर या सबग्राफ NFT चे मालक असेल.
+
+आपल्याला "सामान्य" वॉलेट वापरत आहे किंवा MetaMask (एक बाह्यिकपणे मालकीत खाता किंवा EOA, अर्थात स्मार्ट कॉन्ट्रॅक्ट नसलेला वॉलेट), तर ह्या निवडनीय आहे आणि L1 मध्ये असलेल्या समान मालकीचे पत्ते ठेवणे शिफारसले जाते.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 owner of your subgraph.
+
+**तुम्हाला एक वॉलेट पत्ता वापरण्याची महत्त्वाची आहे ज्याच्या तुम्ही नियंत्रण असता आणि त्याने Arbitrum वर व्यवहार करू शकतो. अन्यथा, सबग्राफ गमावला जाईल आणि त्याची पुनर्प्राप्ती केली जाऊ शकणार नाही.**
+
+## हस्तांतरणाची तयारी: काही ETH ब्रिजिंग
+
+सबग्राफला हस्तांतरित करण्यासाठी एक ट्रॅन्झॅक्शन सेंड करण्यात आल्यामुळे ब्रिजद्वारे एक ट्रॅन्झॅक्शन आणि नंतर आर्बिट्रमवर दुसर्या ट्रॅन्झॅक्शन चालवावा लागतो. पहिल्या ट्रॅन्झॅक्शनमध्ये मुख्यनेटवर ETH वापरले जाते, आणि L2 वर संदेश प्राप्त होण्यात आल्यावर गॅस देण्यासाठी काही ETH समाविष्ट केले जाते. हेच गॅस कमी असल्यास, तर तुम्ही ट्रॅन्झॅक्शन पुन्हा प्रयत्न करून लॅटन्सीसाठी त्याच्यावर थेट पैसे द्यायला हवे, त्याच्यामुळे हे "चरण 3: हस्तांतरणाची पुष्टी करणे" असते (खालीलपैकी). ह्या कदाचित्का **तुम्ही हस्तांतरण सुरू केल्याच्या 7 दिवसांच्या आत** हे प्रक्रिया पुर्ण करणे आवश्यक आहे. इतरत्र, दुसऱ्या ट्रॅन्झॅक्शन ("चरण 4: L2 वर हस्तांतरण समाप्त करणे") ही आपल्याला खासगी आर्बिट्रमवर आणण्यात आली आहे. ह्या कारणांसाठी, तुम्हाला किमानपर्यंत काही ETH आवश्यक आहे, एक मल्टीसिग किंवा स्मार्ट कॉन्ट्रॅक्ट खात्याच्या आवश्यक आहे, ETH रोजच्या (EOA) वॉलेटमध्ये असणे आवश्यक आहे, ज्याचा तुम्ही ट्रॅन्झॅक्शन चालवण्यासाठी वापरता, मल्टीसिग वॉलेट स्वत: नसतो.
+
+तुम्ही किमानतरी एक्सचेंजेसवर ETH खरेदी करू शकता आणि त्याच्यामध्ये सीधे Arbitrum वर विद्यमान ठेवू शकता, किंवा तुम्ही Arbitrum ब्रिजवापरून ETH मुख्यनेटवरील एक वॉलेटपासून L2 वर पाठवू शकता: bridge.arbitrum.io. आर्बिट्रमवर गॅस फीस खूप कमी आहेत, म्हणजे तुम्हाला फक्त थोडेसे फक्त आवश्यक आहे. तुमच्या ट्रॅन्झॅक्शनसाठी मंजूरी मिळविण्यासाठी तुम्हाला किमान अंतरावर (उदा. 0.01 ETH) सुरुवात करणे शिफारसले जाते.
+
+## सबग्राफ ट्रान्सफर टूल शोधत आहे
+
+तुम्ही सबग्राफ स्टुडिओवर तुमच्या सबग्राफचे पेज पाहता तेव्हा तुम्हाला L2 ट्रान्सफर टूल सापडेल:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+हे तयार आहे Explorer वर, आपल्याला जर तुमच्याकडून एक सबग्राफच्या मालकीची वॉलेट असेल आणि Explorer सह कनेक्ट केले तर, आणि त्या सबग्राफच्या पृष्ठावर Explorer वरून मिळवू शकता:
+
+![Transferring to L2](/img/transferToL2.png)
+
+ट्रान्सफर टू L2 बटणावर क्लिक केल्याने ट्रान्सफर टूल उघडेल जिथे तुम्ही ट्रान्सफर प्रक्रिया सुरू करू शकता.
+
+## पायरी 1: हस्तांतरण सुरू करत आहे
+
+हस्तांतरण सुरू करण्यापूर्वी, तुम्ही L2 वर सबग्राफच्या मालकपत्रक्षयक्षमतेचे निर्णय करावे लागेल (वरील "तुमच्या L2 वॉलेटची निवड" पहा), आणि आपल्याला आर्बिट्रमवर पुर्न ठेवण्यासाठी आधीपासून काही ETH असणे अत्यंत शिफारसले जाते (वरील "हस्तांतरण साठी प्राप्ती करणे: काही ETH हस्तांतरित करणे" पहा).
+
+कृपया लक्षात घ्या की सबग्राफ हस्तांतरित करण्यासाठी सबग्राफवर आपल्याला त्याच्या मालकपत्रक्षयक्षमतेसह अगदीच सिग्नल असावे; जर तुम्हाला सबग्राफवर सिग्नल केलेलं नसलं तर तुम्हाला थोडीसी क्युरेशन वाढवावी (एक थोडीसी असांतर किंवा 1 GRT आढवंच काही आहे).
+
+हस्तांतरण साधन उघडण्यात आल्यावर, तुम्ही "प्राप्ति वॉलेट पत्ता" क्षेत्रात L2 वॉलेट पत्ता भरू शकता - **तुम्ही येथे योग्य पत्ता नोंदवला आहे हे खात्री करा**. सबग्राफ हस्तांतरित करण्याच्या वर्तमानीत तुम्ही आपल्या वॉलेटवर ट्रॅन्झॅक्शन सुरू करण्याच्या आवश्यकता आहे (लक्षात घ्या की L2 गॅससाठी काही ETH मूळ आहे); हे हस्तांतरणाच्या प्रक्रियेचे सुरूवात करेल आणि आपल्या L1 सबग्राफला कमी करेल (अद्यतनसाठी "सिग्न.
+
+जर तुम्ही हे कदम पूर्ण करता आहात, नुकसान होऊ नये हे सुनिश्चित करा की 7 दिवसांपेक्षा कमी वेळेत पुन्हा आपल्या क्रियान्वयनाचा तपास करा, किंवा सबग्राफ आणि तुमच्या सिग्नल GRT नष्ट होईल. हे त्याच्या कारणे आहे की आर्बिट्रमवर L1-L2 संदेशाचा कसा काम करतो: ब्रिजद्वारे पाठवलेले संदेश "पुन्हा प्रयत्नीय पर्यायपत्रे" आहेत ज्याचा क्रियान्वयन 7 दिवसांच्या आत अंदाजपत्री केला पाहिजे, आणि सुरुवातीचा क्रियान्वयन, आर्बिट्रमवर गॅस दरात वाढ असल्यास, पुन्हा प्रयत्न करण्याची आवश्यकता असेल.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## पायरी 2: सबग्राफ L2 वर येण्याची वाट पाहत आहे
+
+तुम्ही हस्तांतरण सुरू केल्यानंतर, तुमच्या L1 सबग्राफला L2 वर हस्तांतरित करण्याचे संदेश Arbitrum ब्रिजद्वारे प्रसारित होणे आवश्यक आहे. हे किंवा. 20 मिनिटे लागतात (ब्रिज त्या व्यक्तिमत्वीकृत आहे की L1 मेननेट ब्लॉक जो लेनदार चेन reorgs साठी "सुरक्षित" आहे, त्यातील संदेश किंवा लेनदार चेन reorgs साठी "सुरक्षित" आहे, त्यातील संदेश होऊन जातो).
+
+ही प्रतीक्षा वेळ संपल्यानंतर, आर्बिट्रम L2 करारांवर हस्तांतरण स्वयं-अंमलबजावणी करण्याचा प्रयत्न करेल.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## पायरी 3: हस्तांतरणाची पुष्टी करणे
+
+अधिकांश प्रकरणात, आपल्याला प्राथमिकपणे संघटित ल2 गॅस असेल, ज्यामुळे सबग्राफला आर्बिट्रम कॉन्ट्रॅक्टवर प्राप्त करण्याच्या ट्रॅन्झॅक्शनची स्वत: क्रियारत झाली पाहिजे. कितीतरी प्रकरणात, आर्बिट्रमवर गॅस दरात वाढ असल्यामुळे ह्या स्वत: क्रियान्वितीत अयशस्वीता आपल्याला काहीतरी किंवा काहीतरी संभावना आहे. ह्या प्रकारे, आपल्या सबग्राफला L2 वर पाठवण्याच्या "पर्यायपत्रास" क्रियारत बसण्यासाठी अपूर्ण ठरेल आणि 7 दिवसांच्या आत पुन्हा प्रयत्न करण्याची आवश्यकता आहे.
+
+असे असल्यास, तुम्हाला आर्बिट्रमवर काही ETH असलेले L2 वॉलेट वापरून कनेक्ट करावे लागेल, तुमचे वॉलेट नेटवर्क आर्बिट्रमवर स्विच करा आणि व्यवहाराचा पुन्हा प्रयत्न करण्यासाठी "हस्तांतरण पुष्टी करा" वर क्लिक करा.
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## पायरी 4: L2 वर हस्तांतरण पूर्ण करणे
+
+आता, आपला सबग्राफ आणि GRT आर्बिट्रमवर प्राप्त झालेले आहेत, परंतु सबग्राफ अद्याप प्रकाशित झालेला नाही. आपल्याला प्राप्ति वॉलेटसाठी निवडलेल्या L2 वॉलेटशी कनेक्ट करण्याची आवश्यकता आहे, आपला वॉलेट नेटवर्क आर्बिट्रमवर स्विच करण्याची आणि "पब्लिश सबग्राफ" वर क्लिक करण्याची आवश्यकता आहे
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+हे सबग्राफ प्रकाशित करेल आहे, त्यामुळे त्याचे सेवन करणारे इंडेक्सर्स आर्बिट्रमवर संचालित आहेत, आणि त्यामुळे ला ट्रान्सफर केलेल्या GRT वापरून संवाद सिग्नल क्युरेशन निर्माणित केले जाईल.
+
+## पायरी 5: क्वेरी URL अपडेट करत आहे
+
+तुमचा सबग्राफ आर्बिट्रममध्ये यशस्वीरित्या हस्तांतरित केला गेला आहे! सबग्राफची क्वेरी करण्यासाठी, नवीन URL असेल:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+लक्षात घ्या की आर्बिट्रमवर सबग्राफचे ID मुख्यनेटवर आपल्याला आहे आणि त्याच्या परिपर्यंत आपल्याला आर्बिट्रमवर आहे, परंतु आपल्याला वेगवेगळा सबग्राफ ID असेल, परंतु तुम्ही सदैव तो Explorer किंवा Studio वर शोधू शकता. उपरोक्त (वरील "सिग्नलसह, आपल्या L1 सबग्राफसह आणि क्वेरी URLसह काय करता येईल" पहा) म्हणजे पुराणे L1 URL थोडेसे वेळाने समर्थित राहील, परंतु आपल्याला सबग्राफ L2 वर सिंक केल्यानंतर आपल्या क्वेरीजला त्वरित नवीन पत्ता देणे शिफारसले जाते.
+
+## तुमचे क्युरेशन आर्बिट्रम (L2) वर कसे हस्तांतरित करावे
+
+## L2 मध्ये सबग्राफ ट्रान्सफरवरील क्युरेशनचे काय होते हे समजून घेणे
+
+सबग्राफच्या मालकाने सबग्राफला आर्बिट्रमवर हस्तांतरित केल्यास, सर्व सबग्राफच्या सिग्नलला एकाच वेळी GRT मध्ये रूपांतरित केला जातो. ही "ऑटो-माइग्रेटेड" सिग्नलसाठी लागू होते, अर्थात सबग्राफाच्या कोणत्याही संस्करण किंवा डिप्लॉयमेंटसाठी नसलेली सिग्नल किंवा नवीन संस्करणाच्या आधीच्या सबग्राफच्या आवृत्तीस पुरावीत केली जाते.
+
+सिग्नलपासून GRTमध्ये असे रूपांतरण होण्याचे त्याचे आपल्याला उदाहरण दिले आहे ज्याच्यासाठी जर सबग्राफमालक सबग्राफला L1मध्ये पुरावा दिला तर. सबग्राफ विकल्प किंवा हस्तांतरित केला जाता तेव्हा सर्व सिग्नलला समयानुसार "दहन" केला जातो (क्युरेशन बोंडिंग कर्वच्या वापराने) आणि निकाललेल्या GRTने GNS स्मार्ट कॉन्ट्रॅक्टने (जो सबग्राफ अपग्रेड्स आणि ऑटो-माइग्रेटेड सिग्नलच्या व्यवस्थापनासाठी जबाबदार आहे) साठवलेले आहे. प्रत्येक क्युरेटरने त्या सबग्राफसाठी कितीशेअर्स आहेत त्या प्रमाणे त्याच्याकडे गणना असते, आणि त्यामुळे त्याच्या शेअर्सचा GRTचा दावा असतो.
+
+सबग्राफ मालकाशी संबंधित या GRT चा एक अंश सबग्राफसह L2 ला पाठविला जातो.
+
+आत्ताच, संशोधित GRTमध्ये कोणतीही अधिक क्वेरी फीस घटना आहे नसून, क्युरेटर्सला आपली GRT वापरण्याची किंवा त्याची L2वर त्याच्या आपल्या वर्णनासाठी हस्तांतरित करण्याची पर्वानगी आहे, ज्याच्या माध्यमातून नवीन क्युरेशन सिग्नल तयार केला जाऊ शकतो. हे करण्यासाठी त्वरित किंवा अनिश्चित काळासाठी कोणतीही जरूरत नाही कारण GRT अनश्वास पाहिजे आणि प्रत्येकाला त्याच्या शेअर्सच्या प्रमाणानुसार एक निश्चित वस्तु मिळणार आहे, कोणत्या वेळीही.
+
+## तुमचे L2 वॉलेट निवडत आहे
+
+जर आपल्याला आपल्या संवादनिर्मित GRT ला L2 वर हस्तांतरित करायचं निवडलं तर, तुम्ही L2 वर संवादनिर्मित सिग्नलच्या मालकीच्या वॉलेटसाठी विविध वॉलेट निवडू शकता.
+
+आपल्याला जर "सामान्य" वॉलेट वापरत आहे, जसे Metamask (एक बाह्यिकपणे मालकपत्रक्षमतेचे खाते किंवा EOA किंवा हे एक स्मार्ट कॉन्ट्रॅक्ट नसलेले वॉलेट), तर हे वैकल्पिक आहे आणि शिफारसलेले आहे की तुम्ही L1मध्ये असलेल्या त्या जुन्य क्युरेटर पत्त्याचा वापर करण्यात आनंद घ्यावा.
+
+आपल्याला स्मार्ट कॉन्ट्रॅक्ट वॉलेट वापरत आहे, उदाहरणार्थ, मल्टिसिग (उदा. Safe), तर वेगवेगळा L2 वॉलेट पत्त्याचा वापर करणे अनिवार्य आहे, कारण अत्यंत संभावित आहे की हे खाते केवळ मुख्यनेटवर आहे आणि आपल्याला यात्रा करता येणार नाही किंवा आपल्याला या वॉलेटवर Arbitrum वर्तनी करण्याची क्षमता नसून. जर आपल्याला स्मार्ट कॉन्ट्रॅक्ट वॉलेट किंवा मल्टिसिगचे वापर करत आहे, तर आर्बिट्रमवर एक नवीन वॉलेट तयार करून त्याचा पत्ता लवकरच वापरा आणि त्याच्या L2 प्राप्ति वॉलेट पत्त्याचा वापर करा.
+
+**तुम्हाला एक वॉलेट पत्ता वापरण्याची महत्त्वाची आहे ज्याच्या तुम्ही नियंत्रण असता आणि त्याने Arbitrum वर व्यवहार करू शकतो, अन्यथा संवादना गमावली जाईल आणि त्याची पुनर्प्राप्ती केली जाऊ शकणार नाही.**
+
+## L2 वर क्युरेशन पाठवत आहे: पायरी 1
+
+हस्तांतरण सुरू करण्यापूर्वी, तुम्ही त्याच्या L2 वर क्युरेशनचा मालक होणारा पत्ता निवडणे आवश्यक आहे (वरील "तुमच्या L2 वॉलेटची निवड" पाहा), आणि आर्बिट्रमवर संदेशाच्या क्रियान्वयनाचा पुन्हा प्रयत्न केल्यास लागणारे गॅससाठी काही ETH आधीच्या पुलाकीत सांडलेले असले पर्याय सुरुवातीच्या वेळी किंवा पुन्हा प्रयत्नीय पर्यायसाठी. आपल्याला काही एक्सचेंजवरून ETH खरेदी करून त्याची तुमच्या आर्बिट्रमवर स्थानांतरित करून सुरू आहे, किंवा आपल्याला मुख्यनेटवरून L2 वर ETH पाठवण्याच्या आर्बिट्रम ब्रिजचा वापर करून किंवा ETH खरेदी करून L2 वर पाठवण्याच्या कामाकरीत करण्याची शक्यता आहे: [bridge.arbitrum.io](http://bridge.arbitrum.io)- आर्बिट्रमवर गॅस दरात तोंड असल्यामुळे, तुम्हाला केवळ किंवा 0.01 ETH ची किंमत दरम्यानची आवश्यकता असेल.
+
+आपल्याला संवादित केलेल्या सबग्राफ्टला L2 वर हस्तांतरित केले आहे तर, आपल्याला एक संदेश दिलेला जाईल ज्याच्या माध्यमातून Explorer वरून आपल्याला सांगण्यात येईल की आपण हस्तांतरित सबग्राफ्टच्या संवादनी आहात.
+
+सबग्राफ्ट पेज पाहताना, आपण संवादनाची पुनर्प्राप्ती किंवा हस्तांतरित करण्याचा निवड करू शकता. "Transfer Signal to Arbitrum" वर क्लिक केल्यास, हस्तांतरण साधने उघडतील.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+हस्तांतरण साधन उघडण्यानंतर, जर आपल्याला कोणतेही ETH नसेल तर आपल्याला आपल्या वॉलेटमध्ये किंवा खात्यात किंवा वॉलेटमध्ये किंवा आपल्याला कोणत्याही ETH असल्याची प्रवृत्ति किंवा कोणतीही वस्तु जाहीर केली जात नाही. त्यानंतर, आपल्याला "प्राप्ती वॉलेट पत्ता" फील्डमध्ये L2 वॉलेट पत्ता दाखल करण्याची क्षमता आहे - **तुम्हाला येथे योग्य पत्ता दिलेला आहे ते सुनिश्चित करा.** "सिग्नल हस्तांतरण" वर क्लिक केल्यास, आपल्याला आपल्या वॉलेटवर व्यवस्थापन क्रिया केल्याची प्रवृत्ति केली जाईल (ध्यान द्या की किंवा त्यात किंवा L2 गॅससाठी किंवा तो जोडलेले काही ETH मूल्य असतील); हे हस्तांतरण सुरू करेल.
+
+आपल्याला हे पायथ्याच्या आयातनाची प्रक्रिया केली तरी, **तुम्हाला सुनिश्चित करा की 7 दिवसांपेक्षा कमी काळात प्रक्रिया पूर्ण करण्याच्या प्रमाणे पुढे जाता यावा, किंवा आपली सिग्नल GRT गमावली जाईल.** ह्या आर्बिट्रमवर एल1-एल2 संदेशपासून कसे काम करते, हे कारण: ब्रिजद्वारे पाठवलेले संदेश "पुन्हा प्रयत्नने सुसंगत" तिकिट आहेत, त्याच्या आयातनापासून 7 दिवसांमध्ये काम करण्याची आवश्यकता आहे, आणि त्यामुळे आर्बिट्रमवर गॅसच्या किंमतीमध्ये उच्चता असल्यास प्रारंभिक प्रयत्नास पुन्हा प्रयत्नीय पर्याय आवश्यक असू शकतो.
+
+## L2 वर क्युरेशन पाठवत आहे: पायरी 2
+
+हस्तांतरण सुरू करत आहे:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+तुम्ही हस्तांतरण सुरू केल्यानंतर, तुमच्या L1 क्युरेशनला L2मध्ये पाठवणारा संदेश आर्बिट्रम ब्रिजमाध्ये प्रसारित होण्याची आवश्यकता आहे. ह्याच्या प्रक्रियेत संदेशीला अनुमती दिली जाते की तो मुख्यनेटवरील ट्रांझॅक्शनच्या "सुरक्षित" ब्लॉकमध्ये प्रसारित होईल (संभाव्य श्रॅणी पुनर्व्यवस्थापनांपासून "सुरक्षित" आहे). हे किंवा किंवा 20 मिनिटे लागतात (ब्रिजला प्रमाणे, व्यायामच्या पुनर्व्यवस्थापनांकिंवा संभाव्य जलसंचारांकिंवा संबंधित प्रक्रियांकिंवा आपल्याला काही दिल्याच्या अनुमती दिलेल्या आहेत).
+
+ही प्रतीक्षा वेळ संपल्यानंतर, आर्बिट्रम L2 करारांवर हस्तांतरण स्वयं-अंमलबजावणी करण्याचा प्रयत्न करेल.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## L2 वर क्युरेशन पाठवत आहे: पायरी 3
+
+अधिकांशपेक्षा आपल्याला ह्या पायथ्याच्या आयातनाच्या प्रक्रियेचा या पायथ्यात स्वतः क्रियान्वित होईल, किंवा प्रवेशणीला तसेच समाविष्ट केलेल्या L2 गॅससाठी पर्याप्त असावा आहे, आर्बिट्रमच्या करारांवर क्रियान्वित केलेल्या ट्रांझॅक्शनला. किंवा किंवा, किंवा, किंवा, आर्बिट्रमवर गॅसच्या किंमतीमध्ये वाढीसाठी किंवा दिल्याने ह्या स्वतः क्रियान्वयाच्या प्रक्रियेस संपल्याच्या पायथ्यात याची अपवादज असू शकते. हे प्रकरण असल्यास, आपल्याला L2 वर कुरेशन पाठवता येईल तो प्रलंबित असून, 7 दिवसांच्या आताच्या पुन्हा प्रयत्नाची आवश्यकता असेल.
+
+असे असल्यास, तुम्हाला आर्बिट्रमवर काही ETH असलेले L2 वॉलेट वापरून कनेक्ट करावे लागेल, तुमचे वॉलेट नेटवर्क आर्बिट्रमवर स्विच करा आणि व्यवहाराचा पुन्हा प्रयत्न करण्यासाठी "हस्तांतरण पुष्टी करा" वर क्लिक करा.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## L1 वर तुमचे क्युरेशन मागे घेत आहे
+
+जर आपल्याला आपल्या GRT ला L2 वर पाठवायचं आवडत नसलं तर किंवा आपल्याला GRT ला मॅन्युअली ब्रिज करण्याची प्राथमिकता आहे, तर आपल्याला L1 वरील आपल्या क्युरेटेड GRT ला काढून घ्यायला दिले आहे. सबग्राफच्या पृष्ठाच्या बॅनरवरून "Withdraw Signal" निवडा आणि व्यवस्थापन प्रक्रियेची पुष्टी करा; GRT आपल्या क्युरेटर पत्त्याला पाठविला जाईल.

From 4ad26d04e4245993e5c45d88157e83b91264c7b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:28 -0500
Subject: [PATCH 1064/3820] New translations l2-transfer-tools-guide.mdx
 (Hindi)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/hi/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/hi/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/hi/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..21ee64e62ac4
--- /dev/null
+++ b/website/pages/hi/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 Transfer Tools Guide
+---
+
+The Graph has made it easy to move to L2 on Arbitrum One. For each protocol participant, there are a set of L2 Transfer Tools to make transferring to L2 seamless for all network participants. These tools will require you to follow a specific set of steps depending on what you are transferring.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## अपने सबग्राफ को आर्बिट्रम (L2) में कैसे स्थानांतरित करें
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## अपने सबग्राफ़ स्थानांतरित करने के लाभ
+
+ग्राफ़ का समुदाय और मुख्य डेवलपर पिछले वर्ष से आर्बिट्रम में जाने की तैयारी कर रहे हैं (https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305)। आर्बिट्रम, एक परत 2 या "एल2" ब्लॉकचेन, एथेरियम से सुरक्षा प्राप्त करता है लेकिन काफी कम गैस शुल्क प्रदान करता है।
+
+जब आप अपने सबग्राफ को दी ग्राफ नेटवर्क पर प्रकाशित या अपग्रेड करते हैं, तो आप प्रोटोकॉल पर स्मार्ट कॉन्ट्रैक्ट्स के साथ इंटरैक्ट कर रहे होते हैं और इसके लिए ईथरियम (ETH) का उपयोग करके गैस के लिए भुगतान करना आवश्यक होता है। अपने सबग्राफ को Arbitrum पर स्थानांतरित करके, आपके सबग्राफ के किसी भी भविष्य के अपडेट के लिए गैस शुल्क बहुत कम होगा। कम शुल्कों के साथ, और L2 पर क्यूरेशन बॉन्डिंग कर्व्स फ्लैट होने के कारण, अन्य क्यूरेटर्स को भी आपके सबग्राफ पर क्यूरेट करने में आसानी होगी, जिससे आपके सबग्राफ पर इंडेक्सर्स के लिए पुरस्कार बढ़ेंगे। इस कम लागत वाले वातावरण से इंडेक्सर्स को आपके सबग्राफ को इंडेक्स करने और सेव करने में सस्तापन होगा। आगामी महीनों में Arbitrum पर इंडेक्सिंग पुरस्कार बढ़ जाएगा और ईथिरियम मेननेट पर कम हो जाएगा, इसलिए और भी अधिक इंडेक्सर्स अपने स्टेक को स्थानांतरित करेंगे और उनके संचालन को L2 पर सेटअप करेंगे।
+
+## सिग्नल, आपके L1 सबग्राफ और क्वेरी URL के साथ जो होता है, उसे समझने की प्रक्रिया:
+
+Transferring a subgraph to Arbitrum uses the Arbitrum GRT bridge, which in turn uses the native Arbitrum bridge, to send the subgraph to L2. The "transfer" will deprecate the subgraph on mainnet and send the information to re-create the subgraph on L2 using the bridge. It will also include the subgraph owner's signaled GRT, which must be more than zero for the bridge to accept the transfer.
+
+जब आप सबग्राफ को स्थानांतरित करने का विकल्प चुनते हैं, तो यह सबग्राफ के सभी क्यूरेशन सिग्नल को GRT में रूपांतरित कर देगा। इसका मतलब है कि मुख्यनेट पर सबग्राफ को "विलीन" किया जाएगा। आपके क्यूरेशन के अनुरूप GRT को सबग्राफ के साथ L2 पर भेजा जाएगा, जहां वे आपके प्रतिनिधित्व में सिग्नल निर्माण करने के लिए उपयोग होंगे।
+
+अन्य क्यूरेटर्स का विकल्प होता है कि क्या वे अपने अंशिक GRT को विद्वेष्टित करें या उसे भी L2 पर स्थानांतरित करें ताकि वे उसी सबग्राफ पर सिग्नल निर्मित कर सकें। अगर कोई सबग्राफ का मालिक अपने सबग्राफ को L2 पर स्थानांतरित नहीं करता है और अधिकारिक रूप से उसे एक कॉन्ट्रैक्ट कॉल के माध्यम से विलीन करता है, तो क्यूरेटर्स को सूचित किया जाएगा और उन्हें उनके क्यूरेशन को वापस लेने का अधिकार होगा।
+
+Subgraph को स्थानांतरित करते ही, curation को GRT में रूपांतरित किये जाने के कारण Indexers को subgraph को index करने के लिए अब और rewards नहीं मिलेगा। हालांकि, ऐसे Indexers भी होंगे जो 1) स्थानांतरित subgraphs की सेवा 24 घंटे तक करते रहेंगे और 2) तुरंत L2 पर subgraph को indexing करने की प्रारंभ करेंगे। क्योंकि इन Indexers ने पहले से ही subgraph को indexed किया होता है, इसलिए subgraph को sync करने की प्रतीक्षा करने की आवश्यकता नहीं होगी, और L2 subgraph को तकनीकी रूप से तुरंत carry किया जा सकेगा।
+
+L2 सबग्राफ के क्वेरी को एक विभिन्न URL पर ( 'arbitrum-gateway.thegraph.com' पर) किया जाना चाहिए, लेकिन L1 URL काम करना जारी रखेगा कम से कम 48 घंटे तक। उसके बाद, L1 गेटवे क्वेरी को L2 गेटवे के लिए आगे प्रेषित करेगा (कुछ समय के लिए), लेकिन इससे लैटेंसी बढ़ सकती है, इसलिए संभावना है कि आपको सभी क्वेरी को नए URL पर जल्द से जल्द स्विच कर लेने की सिफारिश की जाए।
+
+## अपना L2 वॉलेट चुनना
+
+जब आपने मुख्यनेट पर अपने सबग्राफ को प्रकाशित किया, तो आपने एक कनेक्टेड वॉलेट का उपयोग सबग्राफ बनाने के लिए किया और यह वॉलेट वह NFT स्वामित्व करता है जो इस सबग्राफ का प्रतिनिधित्व करता है और आपको अपडेट प्रकाशित करने की अनुमति देता है।
+
+सबग्राफ को Arbitrum पर स्थानांतरित करते समय, आप एक विभिन्न वॉलेट का चयन कर सकते हैं जो L2 पर इस सबग्राफ NFT का स्वामित्व करेगा।
+
+अगर आप "सामान्य" wallet जैसे MetaMask का उपयोग कर रहे हैं (जिसे बाह्यिक अधिकारित खाता या EOA कहा जाता है, यानी एक wallet जो smart contract नहीं है), तो यह वैकल्पिक है और सिफारिश की जाती है कि आप L1 में के समान मालिक पता बनाए रखें।बटुआ
+
+अगर आप स्मार्ट कॉन्ट्रैक्ट वॉलेट का उपयोग कर रहे हैं, जैसे कि मल्टिसिग (उदाहरणस्वरूप, एक सेफ), तो एक विभिन्न L2 वॉलेट पता चुनना अनिवार्य है, क्योंकि यह बहुत संभावना है कि यह खाता केवल मुख्यनेट पर मौजूद है और आप इस वॉलेट का उपयोग अर्बिट्रम पर लेन-देन करने के लिए नहीं कर सकते हैं। अगर आप स्मार्ट कॉन्ट्रैक्ट वॉलेट या मल्टिसिग का उपयोग करना चाहते हैं, तो अर्बिट्रम पर एक नया वॉलेट बनाएं और उसका पता अपने सबग्राफ के L2 मालिक के रूप में उपयोग करें।
+
+**यह महत्वपूर्ण है कि आप एक वॉलेट पता का उपयोग करें जिस पर आपका नियंत्रण है, और जिससे आप अर्बिट्रम पर लेन-देन कर सकते हैं। अन्यथा, सबग्राफ हानि हो जाएगा और उसे पुनः प्राप्त नहीं किया जा सकता।**
+
+## स्थानांतरण के लिए तैयारी: कुछ ETH को ब्रिज करना
+
+सबग्राफ को स्थानांतरित करने में एक लेन-देन को ब्रिज के माध्यम से भेजना शामिल है, और फिर अर्बिट्रम पर एक और लेन-देन को प्रारंभ करना। पहली लेन-देन मुख्यनेट पर ETH का उपयोग करता है, और जब संदेश L2 पर प्राप्त होता है, तो गैस के भुगतान के लिए कुछ ETH को शामिल करता है। हालांकि, अगर यह गैस पर्याप्त नहीं होता है, तो आपको लेन-देन को पुनः प्रयास करना होगा और गैस के लिए सीधे L2 पर भुगतान करना होगा (यह "चरण 3: स्थानांतरण की पुष्टि करना" है, नीचे दिए गए हैं)। यह कदम **स्थानांतरण की प्रारंभिक करने के 7 दिनों के भीतर कार्यान्वित किया जाना चाहिए।** इसके अलावा, दूसरी लेन-देन ("चरण 4: L2 पर स्थानांतरण को समाप्त करना") को सीधे अर्बिट्रम पर किया जाएगा। इन कारणों से, आपको किसी एक Arbitrum वॉलेट पर कुछ ETH की आवश्यकता होगी। यदि आप मल्टिसिग या स्मार्ट कॉन्ट्रैक्ट खाता का उपयोग कर रहे हैं, तो ETH को उन्हीं सामान्य (EOA) वॉलेट में होना चाहिए जिसका आप लेन-देन कार्यान्वित करने के लिए उपयोग कर रहे हैं, मल्टिसिग वॉलेट में नहीं।
+
+आप कुछ एक्सचेंजों पर ETH खरीद सकते हैं और उसे सीधे अर्बिट्रम में विद्वेष्टित कर सकते हैं, या आप अर्बिट्रम ब्रिज का उपयोग करके ETH को मुख्यनेट वॉलेट से L2 में भेज सकते हैं: [bridge.arbitrum.io](http://bridge.arbitrum.io)। क्योंकि अर्बिट्रम पर गैस शुल्क कम होते हैं, आपको केवल थोड़ी सी राशि की आवश्यकता होनी चाहिए। यह सिफारिश की जाती है कि आप अपने लेन-देन को स्वीकृति प्राप्त करने के लिए कम थ्रेशहोल्ड (उदाहरणस्वरूप 0.01 ETH) से प्रारंभ करें।
+
+## सबग्राफ ट्रांसफर टूल ढूँढना
+
+आप सबग्राफ स्टूडियो पर अपने सबग्राफ के पेज को देखते समय L2 ट्रांसफर टूल पा सकते हैं:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+यह भी उपलब्ध है एक्सप्लोरर पर अगर आप ऐसे वॉलेट से कनेक्ट हो जाते हैं जिसका सबग्राफ का स्वामित्व है, और उस सबग्राफ के पेज पर एक्सप्लोरर पर:
+
+![Transferring to L2](/img/transferToL2.png)
+
+"L2 पर स्थानांतरित करें" बटन पर क्लिक करने से स्थानांतरण टूल खुल जाएगा, जहाँ आप स्थानांतरण प्रक्रिया को आरंभ कर सकते हैं |
+
+## चरण 1: स्थानांतरण की प्रारंभिक कदम
+
+स्थानांतरण की प्रारंभिक करने से पहले, आपको तय करना होगा कि L2 पर सबग्राफ का स्वामित्व किस पते पर होगा (ऊपर "अपने L2 वॉलेट का चयन करना" देखें), और यह मजबूती से सिफारिश की जाती है कि अर्बिट्रम पर गैस के लिए कुछ ETH ब्रिज कर दिया गया हो (ऊपर "स्थानांतरण की तैयारी: कुछ ETH को ब्रिज करना" देखें)।
+
+यह भी ध्यान दें कि सबग्राफ को स्थानांतरित करने के लिए सबग्राफ के साथ एक ही खाते में कोई भी सिग्नल की गई राशि होनी चाहिए; अगर आपने सबग्राफ पर सिग्नल नहीं किया है तो आपको थोड़ी सी क्यूरेशन जोड़नी होगी (एक छोटी राशि जैसे 1 GRT जोड़ना काफी होगा)।
+
+स्थानांतरण टूल खोलने के बाद, आपको "प्राप्ति वॉलेट पता" फ़ील्ड में L2 वॉलेट पता दर्ज करने की अनुमति मिलेगी - **सुनिश्चित करें कि आपने यहाँ सही पता डाला है।** "सबग्राफ स्थानांतरित करें" पर क्लिक करने से आपको अपने वॉलेट पर लेन-देन कार्यान्वित करने के लिए प्रोम्प्ट किया जाएगा (ध्यान दें कि L2 गैस के भुगतान के लिए कुछ ETH मान शामिल है)। इससे स्थानांतरण प्रारंभ होगा और आपका L1 सबग्राफ विलीन हो जाएगा (इसके पीछे के प्रक्रिया के बारे में अधिक जानकारी के लिए "सिग्नल, आपके L1 सबग्राफ और क्वेरी URL के साथ क्या होता है की समझ" देखें)।
+
+इस कदम को कार्यान्वित करते समय, **सुनिश्चित करें कि आप 7 दिन से कम समय में चरण 3 को पूरा करने जाते हैं, अन्यथा सबग्राफ और आपका सिग्नल GRT हानि हो सकते हैं।** यह अर्बिट्रम पर L1-L2 संदेशिकरण कैसे काम करता है के कारण है: ब्रिज के माध्यम से भेजे गए संदेश "पुनः प्रयासनीय टिकट" होते हैं जिन्हें 7 दिन के भीतर कार्यान्वित किया जाना चाहिए, और पहले कार्यान्वयन में अगर अर्बिट्रम पर गैस की मूल्य में वृद्धि होती है तो पुनः प्रयास की आवश्यकता हो सकती है।
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## चरण 2: सबग्राफ को L2 तक पहुँचने की प्रतीक्षा करना
+
+जब आप स्थानांतरण की प्रारंभिक करते हैं, तो आपके L1 सबग्राफ को L2 भेजने वाले संदेश को अर्बिट्रम ब्रिज के माध्यम से प्रसारित होना चाहिए। यह लगभग 20 मिनट लगता है (ब्रिज मुख्यनेट ब्लॉक को "सुरक्षित" बनाने के लिए प्रत्येक लेनदेन के मुख्यनेट ब्लॉक के लिए प्रतीक्षा करता है, जिसमें संभावित चेन रीआर्ग से बचाया जा सकता है)।
+
+इस प्रतीक्षा काल के बाद, अर्बिट्रम ल2 अनुबंधों पर स्थानांतरण को स्वतः कार्यान्वित करने का प्रयास करेगा।
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## चरण 3: स्थानांतरण की पुष्टि करना
+
+अधिकांश मामलों में, यह कदम स्वचालित रूप से क्रियान्वित हो जाएगा क्योंकि स्टेप 1 में शामिल एल2 गैस काफी होता है ताकि आर्बिट्रम कॉन्ट्रैक्ट पर सबग्राफ प्राप्त करने वाले लेनदेन को क्रियान्वित किया जा सके। हालांकि, कुछ मामलों में, यह संभावित है कि आर्बिट्रम पर गैस मूल्यों में एक उछाल के कारण यह स्वचालित क्रियान्वित होने में विफल हो सकता है। इस मामले में, जो "टिकट" आपके सबग्राफ को एल2 पर भेजता है, वह लंबित हो जाएगा और 7 दिनों के भीतर पुनः प्रयास की आवश्यकता होगी।
+
+यदि यह मामला आपके साथ होता है, तो आपको ऐसे L2 वॉलेट का उपयोग करके कनेक्ट करना होगा जिसमें आर्बिट्रम पर कुछ ETH हो, अपनी वॉलेट नेटवर्क को आर्बिट्रम पर स्विच करना होगा, और "पुनः प्रायोग की पुष्टि करें" पर क्लिक करके लेन-देन को पुनः प्रयास करने के लिए।
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## चरण 4: L2 पर स्थानांतरण समाप्त करना
+
+इस बिंदु पर, आपका सबग्राफ और GRT आर्बिट्रम पर प्राप्त हो चुके हैं, लेकिन सबग्राफ अबतक प्रकाशित नहीं हुआ है। आपको वह एल2 वॉलेट का उपयोग करके कनेक्ट करना होगा जिसे आपने प्राप्ति वॉलेट के रूप में चुना है, अपने वॉलेट नेटवर्क को आर्बिट्रम पर स्विच करना होगा, और "पब्लिश सबग्राफ" पर क्लिक करना होगा।
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+इससे सबग्राफ प्रकाशित हो जाएगा ताकि Arbitrum पर काम करने वाले इंडेक्सर उसकी सेवा करना शुरू कर सकें। यह भी उसी GRT का करेशन सिग्नल मिन्ट करेगा जो L1 से स्थानांतरित हुए थे।
+
+## Step 5: query Step 5 को Update करना
+
+आपकी सबग्राफ सफलतापूर्वक Arbitrum में स्थानांतरित की गई है! सबग्राफ का प्रश्न करने के लिए, नया URL होगा:
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+ध्यान दें कि आर्बिट्रम पर सबग्राफ आईडी मुख्यनेट पर जितना भिन्न होगा, लेकिन आप हमेशा इसे एक्सप्लोरर या स्टूडियो पर ढूंढ सकते हैं। जैसा कि पहले उल्लिखित किया गया है ("सिग्नल, आपके L1 सबग्राफ और क्वेरी URL के साथ क्या होता है" देखें), पुराना L1 URL कुछ समय तक समर्थित किया जाएगा, लेकिन आपको सबग्राफ को L2 पर सिंक होने के बाद नए पते पर अपने क्वेरी को स्विच कर देना चाहिए।
+
+## अपने क्यूरेशन को आर्बिट्रम (L2) में कैसे स्थानांतरित करें
+
+## यह समझना कि एल2 में सबग्राफ़ स्थानांतरण पर क्यूरेशन का क्या होता है
+
+जब कोई सबग्राफ के मालिक सबग्राफ को आर्बिट्रम पर ट्रांसफर करते हैं, तो सबग्राफ की सभी सिग्नल को एक साथ GRT में रूपांतरित किया जाता है। यह "ऑटो-माइग्रेटेड" सिग्नल के लिए भी लागू होता है, अर्थात्, सिग्नल जो सबग्राफ के किसी वर्शन या डिप्लॉयमेंट के लिए विशिष्ट नहीं है, लेकिन जो सबग्राफ के नवीनतम संस्करण का पालन करते हैं।
+
+सिग्नल से GRT में इस परिवर्तन को वही होता है जो होता है अगर सबग्राफ के मालिक ने L1 में सबग्राफ को विच्छेद किया होता। जब सबग्राफ को विच्छेदित या स्थानांतरित किया जाता है, तो सभी क्यूरेशन सिग्नल को समयानुसार "जलाया" जाता है (क्यूरेशन बॉन्डिंग कर्व का उपयोग करके) और परिणित GRT को GNS स्मार्ट कॉन्ट्रैक्ट द्वारा रखा जाता है (जो सबग्राफ अपग्रेड और ऑटो-माइग्रेटेड सिग्नल को संभालता है)। इस प्रकार, उस सबग्राफ के प्रत्येक क्यूरेटर के पास उस GRT का दावा होता है जो उनके लिए उपग्रहानुशासित था।
+
+इन जीआरटी की एक भाग, जो सबग्राफ के मालिक के संवर्ग के साथ मेल खाते हैं, वह एल2 में भेजे जाते हैं।
+
+इस बिंदु पर, क्यूरेटेड GRT को अब और क्वेरी शुल्क नहीं बढ़ेंगे, इसलिए क्यूरेटर्स अपने GRT को वापस निकालने का चयन कर सकते हैं या उसे L2 पर उसी सबग्राफ में ट्रांसफर कर सकते हैं, जहां उसे नई क्यूरेशन सिग्नल बनाने के लिए उपयोग किया जा सकता है। इसे करने के लिए कोई जल्दी नहीं है क्योंकि GRT को अनिश्चितकाल तक रखा जा सकता है और हर कोई अपने हिस्से के अनुपात में एक निश्चित राशि प्राप्त करता है, चाहे वो जब भी करे।
+
+## अपना L2 वॉलेट चुनना
+
+अगर आप निर्णय लेते हैं कि आप अपने करेशित जीआरटी को L2 में स्थानांतरित करना चाहते हैं, तो आप एक ऐसे wallet का चयन कर सकते हैं जो L2 में curation signal के मालिक होगा।
+
+अगर आप "सामान्य" वॉलेट जैसे Metamask का उपयोग कर रहे हैं (एक बाहरी स्वामित संकेतक खाता या EOA, अर्थात एक वॉलेट जो एक स्मार्ट कॉन्ट्रैक्ट नहीं है), तो यह वैकल्पिक है और सिफारिश की जाती है कि आप वैसे ही करेशक पता रखें जैसा L1 में है।
+
+अगर आप एक स्मार्ट कॉन्ट्रैक्ट वॉलेट का उपयोग कर रहे हैं, जैसे कि मल्टिसिग (उदाहरणस्वरूप, एक सेफ), तो एक विभिन्न L2 वॉलेट पता चुनना अनिवार्य है, क्योंकि यह संभावना है कि यह खाता केवल मुख्यनेट पर मौजूद होता है और आप इस वॉलेट का उपयोग अर्बिट्रम पर लेनदेन करने के लिए नहीं कर सकेंगे। यदि आप एक स्मार्ट कॉन्ट्रैक्ट वॉलेट या मल्टिसिग का उपयोग करना चाहते हैं, तो अर्बिट्रम पर एक नया वॉलेट बनाएं और इसका पता L2 प्राप्ति वॉलेट पते के रूप में उपयोग करें।
+
+**यह बहुत महत्वपूर्ण है कि आप एक ऐसे वॉलेट पता का उपयोग करें जिसे आप नियंत्रण में रखते हैं, और जो Arbitrum पर लेन-देन कर सकता है, क्योंकि अन्यथा करेशन खो जाएगा और इसे पुनर्प्राप्त नहीं किया जा सकता है।**
+
+## क्यूरेशन को L2 पर भेजा जा रहा है: चरण 1
+
+ट्रांसफर शुरू करने से पहले, आपको निर्णय लेना होगा कि L2 पर क्यूरेशन किस पते का स्वामित्व करेगा (ऊपर "अपने L2 वॉलेट का चयन करना" देखें), और संदेश को L2 पर पुनः क्रियान्वित करने की आवश्यकता पड़ने पर आपके पास गैस के लिए पहले से ही कुछ ETH होने की सिफारिश की जाती है। आप कुछ एक्सचेंजों पर ETH खरीद सकते हैं और उसे सीधे Arbitrum पर निकाल सकते हैं, या आप मुख्यनेट वॉलेट से L2 में ETH भेजने के लिए आर्बिट्रम ब्रिज का उपयोग कर सकते हैं: [bridge.arbitrum.io](http://bridge.arbitrum.io) - क्योंकि आर्बिट्रम पर गैस शुल्क इतने कम होते हैं, तो आपको केवल थोड़ी सी राशि की आवश्यकता होगी, जैसे कि 0.01 ETH शायद पर्याप्त हो।
+
+अगर वह सबग्राफ जिसे आप करेशन कर रहे हैं L2 पर स्थानांतरित किया गया है, तो आपको एक संदेश दिखाई देगा जो आपको एक स्थानांतरित सबग्राफ करेशन की जानकारी देगा।
+
+सबग्राफ पेज को देखते समय, आपको करेशन को वापस लेने या स्थानांतरित करने का चयन करने का विकल्प होता है। "Transfer Signal to Arbitrum" पर क्लिक करने से स्थानांतरण उपकरण खुल जाता है।
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+ट्रांसफर टूल खोलने के बाद, आपको यदि आपके पास कोई ETH नहीं है तो अपने वॉलेट में कुछ ETH जोड़ने के लिए कह सकता है। फिर आप "प्राप्ति वॉलेट पता" क्षेत्र में L2 वॉलेट पता दर्ज कर सकेंगे - **यहाँ सही पता दर्ज किया है यह सुनिश्चित करें।** "सिग्नल ट्रांसफर" पर क्लिक करने पर आपको अपने वॉलेट पर लेनदेन को पूरा करने के लिए कहा जा सकता है (ध्यान दें कि L2 गैस के लिए कुछ ETH मूल्य शामिल होता है); यह ट्रांसफर को प्रारंभ करेगा।
+
+अगर आप इस कदम को पूरा करते हैं, ध्यान दें कि 7 दिनों से कम समय में स्टेप 3 पूरा करना आवश्यक है, अन्यथा आपका सिग्नल GRT खो जाएगा। यह आर्बिट्रम पर L1-L2 संदेशन काम कैसे करता है के कारण है: जो संदेश ब्रिज के माध्यम से भेजे जाते हैं, वे "पुनर्प्रयासी टिकट" होते हैं जिन्हें 7 दिनों के भीतर क्रियान्वित किया जाना चाहिए, और प्रारंभिक क्रियान्वयन के लिए यदि आर्बिट्रम पर गैस मूल्य में वृद्धि होती है, तो पुनर्प्रयास की आवश्यकता हो सकती है।
+
+## क्यूरेशन को L2 पर भेजा जा रहा है: चरण 2
+
+स्थानांतरण प्रारंभ करना:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+जब आप ट्रांसफर को प्रारंभ करते हैं, आपके L1 क्यूरेशन को L2 में भेजने वाले संदेश को आर्बिट्रम ब्रिज के माध्यम से प्रसारित होने की आवश्यकता होती है। यह लगभग 20 मिनट लेता है (ब्रिज मुख्यनेट ब्लॉक को देखता है जिसमें लेनदेन शामिल है, और संभावित चेन रीआर्ग से "सुरक्षित" होता है)।
+
+इस प्रतीक्षा काल के बाद, अर्बिट्रम ल2 अनुबंधों पर स्थानांतरण को स्वतः कार्यान्वित करने का प्रयास करेगा।
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## क्यूरेशन को L2 पर भेजा जा रहा है: चरण 3
+
+अधिकांश मामलों में, यह कदम स्वतः क्रियान्वित हो जाएगा क्योंकि स्टेप 1 में शामिल L2 गैस की पर्याप्तता होनी चाहिए जो सौदे पर क्यूरेशन प्राप्ति क्रियान्वित करता है। हालांकि, कुछ मामलों में, आर्बिट्रम पर गैस मूल्यों में वृद्धि के कारण यह स्वतः क्रियान्वित नहीं हो सकता है। इस मामले में, जो "टिकट" आपके क्यूरेशन को L2 पर भेजता है, वह पैंडिंग हो जाएगा और 7 दिनों के भीतर पुनः प्रयास की आवश्यकता होगी।
+
+यदि यह मामला आपके साथ होता है, तो आपको ऐसे L2 वॉलेट का उपयोग करके कनेक्ट करना होगा जिसमें आर्बिट्रम पर कुछ ETH हो, अपनी वॉलेट नेटवर्क को आर्बिट्रम पर स्विच करना होगा, और "पुनः प्रायोग की पुष्टि करें" पर क्लिक करके लेन-देन को पुनः प्रयास करने के लिए।
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## L1 पर अपना कार्यकाल वापस ले रहा हूँ
+
+अगर आप चाहते हैं कि आप अपने GRT को L2 पर नहीं भेजें, या फिर आप पसंद करते हैं कि GRT को मैन्युअल रूप से ब्रिज करें, तो आप अपने क्यूरेटेड GRT को L1 पर निकाल सकते हैं। सबग्राफ पृष्ठ पर बैनर पर, "सिग्नल निकालें" चुनें और लेनदेन की पुष्टि करें; GRT आपके क्यूरेटर पते पर भेज दिया जाएगा।

From f7ad4270fd6d17760543529ceed32a03745b14b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:29 -0500
Subject: [PATCH 1065/3820] New translations l2-transfer-tools-guide.mdx
 (Swahili)

---
 .../arbitrum/l2-transfer-tools-guide.mdx      | 165 ++++++++++++++++++
 1 file changed, 165 insertions(+)
 create mode 100644 website/pages/sw/archived/arbitrum/l2-transfer-tools-guide.mdx

diff --git a/website/pages/sw/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/sw/archived/arbitrum/l2-transfer-tools-guide.mdx
new file mode 100644
index 000000000000..485f34a70c97
--- /dev/null
+++ b/website/pages/sw/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -0,0 +1,165 @@
+---
+title: L2 Transfer Tools Guide
+---
+
+The Graph has made it easy to move to L2 on Arbitrum One. For each protocol participant, there are a set of L2 Transfer Tools to make transferring to L2 seamless for all network participants. These tools will require you to follow a specific set of steps depending on what you are transferring.
+
+Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+
+## How to transfer your subgraph to Arbitrum (L2)
+
+<VideoEmbed youtube="R8_vz4lx2Co" />
+
+## Benefits of transferring your subgraphs
+
+The Graph's community and core devs have [been preparing](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) to move to Arbitrum over the past year. Arbitrum, a layer 2 or "L2" blockchain, inherits the security from Ethereum but provides drastically lower gas fees.
+
+When you publish or upgrade your subgraph to The Graph Network, you're interacting with smart contracts on the protocol and this requires paying for gas using ETH. By moving your subgraphs to Arbitrum, any future updates to your subgraph will require much lower gas fees. The lower fees, and the fact that curation bonding curves on L2 are flat, also make it easier for other Curators to curate on your subgraph, increasing the rewards for Indexers on your subgraph. This lower-cost environment also makes it cheaper for Indexers to index and serve your subgraph. Indexing rewards will be increasing on Arbitrum and decreasing on Ethereum mainnet over the coming months, so more and more Indexers will be transferring their stake and setting up their operations on L2.
+
+## Understanding what happens with signal, your L1 subgraph and query URLs
+
+Transferring a subgraph to Arbitrum uses the Arbitrum GRT bridge, which in turn uses the native Arbitrum bridge, to send the subgraph to L2. The "transfer" will deprecate the subgraph on mainnet and send the information to re-create the subgraph on L2 using the bridge. It will also include the subgraph owner's signaled GRT, which must be more than zero for the bridge to accept the transfer.
+
+When you choose to transfer the subgraph, this will convert all of the subgraph's curation signal to GRT. This is equivalent to "deprecating" the subgraph on mainnet. The GRT corresponding to your curation will be sent to L2 together with the subgraph, where they will be used to mint signal on your behalf.
+
+Other Curators can choose whether to withdraw their fraction of GRT, or also transfer it to L2 to mint signal on the same subgraph. If a subgraph owner does not transfer their subgraph to L2 and manually deprecates it via a contract call, then Curators will be notified and will be able to withdraw their curation.
+
+As soon as the subgraph is transferred, since all curation is converted to GRT, Indexers will no longer receive rewards for indexing the subgraph. However, there will be Indexers that will 1) keep serving transferred subgraphs for 24 hours, and 2) immediately start indexing the subgraph on L2. Since these Indexers already have the subgraph indexed, there should be no need to wait for the subgraph to sync, and it will be possible to query the L2 subgraph almost immediately.
+
+Queries to the L2 subgraph will need to be done to a different URL (on `arbitrum-gateway.thegraph.com`), but the L1 URL will continue working for at least 48 hours. After that, the L1 gateway will forward queries to the L2 gateway (for some time), but this will add latency so it is recommended to switch all your queries to the new URL as soon as possible.
+
+## Choosing your L2 wallet
+
+When you published your subgraph on mainnet, you used a connected wallet to create the subgraph, and this wallet owns the NFT that represents this subgraph and allows you to publish updates.
+
+When transferring the subgraph to Arbitrum, you can choose a different wallet that will own this subgraph NFT on L2.
+
+If you're using a "regular" wallet like MetaMask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same owner address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 owner of your subgraph.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum. Otherwise, the subgraph will be lost and cannot be recovered.**
+
+## Preparing for the transfer: bridging some ETH
+
+Transferring the subgraph involves sending a transaction through the bridge, and then executing another transaction on Arbitrum. The first transaction uses ETH on mainnet, and includes some ETH to pay for gas when the message is received on L2. However, if this gas is insufficient, you will have to retry the transaction and pay for the gas directly on L2 (this is "Step 3: Confirming the transfer" below). This step **must be executed within 7 days of starting the transfer**. Moreover, the second transaction ("Step 4: Finishing the transfer on L2") will be done directly on Arbitrum. For these reasons, you will need some ETH on an Arbitrum wallet. If you're using a multisig or smart contract account, the ETH will need to be in the regular (EOA) wallet that you are using to execute the transactions, not on the multisig wallet itself.
+
+You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io). Since gas fees on Arbitrum are lower, you should only need a small amount. It is recommended that you start at a low threshold (0.e.g. 01 ETH) for your transaction to be approved.
+
+## Finding the subgraph Transfer Tool
+
+You can find the L2 Transfer Tool when you're looking at your subgraph's page on Subgraph Studio:
+
+![transfer tool](/img/L2-transfer-tool1.png)
+
+It is also available on Explorer if you're connected with the wallet that owns a subgraph and on that subgraph's page on Explorer:
+
+![Transferring to L2](/img/transferToL2.png)
+
+Clicking on the Transfer to L2 button will open the transfer tool where you can start the transfer process.
+
+## Step 1: Starting the transfer
+
+Before starting the transfer, you must decide which address will own the subgraph on L2 (see "Choosing your L2 wallet" above), and it is strongly recommend having some ETH for gas already bridged on Arbitrum (see "Preparing for the transfer: bridging some ETH" above).
+
+Also please note transferring the subgraph requires having a nonzero amount of signal on the subgraph with the same account that owns the subgraph; if you haven't signaled on the subgraph you will have to add a bit of curation (adding a small amount like 1 GRT would suffice).
+
+After opening the Transfer Tool, you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Subgraph will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer and deprecate your L1 subgraph (see "Understanding what happens with signal, your L1 subgraph and query URLs" above for more details on what goes on behind the scenes).
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or the subgraph and your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retry-able tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+![Start the transfer to L2](/img/startTransferL2.png)
+
+## Step 2: Waiting for the subgraph to get to L2
+
+After you start the transfer, the message that sends your L1 subgraph to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Wait screen](/img/screenshotOfWaitScreenL2.png)
+
+## Step 3: Confirming the transfer
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the subgraph on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your subgraph to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Confirm the transfer to L2](/img/confirmTransferToL2.png)
+
+## Step 4: Finishing the transfer on L2
+
+At this point, your subgraph and GRT have been received on Arbitrum, but the subgraph is not published yet. You will need to connect using the L2 wallet that you chose as the receiving wallet, switch your wallet network to Arbitrum, and click "Publish Subgraph."
+
+![Publish the subgraph](/img/publishSubgraphL2TransferTools.png)
+
+![Wait for the subgraph to be published](/img/waitForSubgraphToPublishL2TransferTools.png)
+
+This will publish the subgraph so that Indexers that are operating on Arbitrum can start serving it. It will also mint curation signal using the GRT that were transferred from L1.
+
+## Step 5: Updating the query URL
+
+Your subgraph has been successfully transferred to Arbitrum! To query the subgraph, the new URL will be :
+
+`https://arbitrum-gateway.thegraph.com/api/[api-key]/subgraphs/id/[l2-subgraph-id]`
+
+Note that the subgraph ID on Arbitrum will be a different than the one you had on mainnet, but you can always find it on Explorer or Studio. As mentioned above (see "Understanding what happens with signal, your L1 subgraph and query URLs") the old L1 URL will be supported for a short while, but you should switch your queries to the new address as soon as the subgraph has been synced on L2.
+
+## How to transfer your curation to Arbitrum (L2)
+
+## Understanding what happens to curation on subgraph transfers to L2
+
+When the owner of a subgraph transfers a subgraph to Arbitrum, all of the subgraph's signal is converted to GRT at the same time. This applies to "auto-migrated" signal, i.e. signal that is not specific to a subgraph version or deployment but that follows the latest version of a subgraph.
+
+This conversion from signal to GRT is the same as what would happen if the subgraph owner deprecated the subgraph in L1. When the subgraph is deprecated or transferred, all curation signal is "burned" simultaneously (using the curation bonding curve) and the resulting GRT is held by the GNS smart contract (that is the contract that handles subgraph upgrades and auto-migrated signal). Each Curator on that subgraph therefore has a claim to that GRT proportional to the amount of shares they had for the subgraph.
+
+A fraction of these GRT corresponding to the subgraph owner is sent to L2 together with the subgraph.
+
+At this point, the curated GRT will not accrue any more query fees, so Curators can choose to withdraw their GRT or transfer it to the same subgraph on L2, where it can be used to mint new curation signal. There is no rush to do this as the GRT can be help indefinitely and everybody gets an amount proportional to their shares, irrespective of when they do it.
+
+## Choosing your L2 wallet
+
+If you decide to transfer your curated GRT to L2, you can choose a different wallet that will own the curation signal on L2.
+
+If you're using a "regular" wallet like Metamask (an Externally Owned Account or EOA, i.e. a wallet that is not a smart contract), then this is optional and it is recommended to keep the same Curator address as in L1.
+
+If you're using a smart contract wallet, like a multisig (e.g. a Safe), then choosing a different L2 wallet address is mandatory, as it is most likely that this account only exists on mainnet and you will not be able to make transactions on Arbitrum using this wallet. If you want to keep using a smart contract wallet or multisig, create a new wallet on Arbitrum and use its address as the L2 receiving wallet address.
+
+**It is very important to use a wallet address that you control, and that can make transactions on Arbitrum, as otherwise the curation will be lost and cannot be recovered.**
+
+## Sending curation to L2: Step 1
+
+Before starting the transfer, you must decide which address will own the curation on L2 (see "Choosing your L2 wallet" above), and it is recommended having some ETH for gas already bridged on Arbitrum in case you need to retry the execution of the message on L2. You can buy ETH on some exchanges and withdraw it directly to Arbitrum, or you can use the Arbitrum bridge to send ETH from a mainnet wallet to L2: [bridge.arbitrum.io](http://bridge.arbitrum.io) - since gas fees on Arbitrum are so low, you should only need a small amount, e.g. 0.01 ETH will probably be more than enough.
+
+If a subgraph that you curate to has been transferred to L2, you will see a message on Explorer telling you that you're curating to a transferred subgraph.
+
+When looking at the subgraph page, you can choose to withdraw or transfer the curation. Clicking on "Transfer Signal to Arbitrum" will open the transfer tool.
+
+![Transfer signal](/img/transferSignalL2TransferTools.png)
+
+After opening the Transfer Tool, you may be prompted to add some ETH to your wallet if you don't have any. Then you will be able to input the L2 wallet address into the "Receiving wallet address" field - **make sure you've entered the correct address here**. Clicking on Transfer Signal will prompt you to execute the transaction on your wallet (note some ETH value is included to pay for L2 gas); this will initiate the transfer.
+
+If you execute this step, **make sure you proceed until completing step 3 in less than 7 days, or your signal GRT will be lost.** This is due to how L1-L2 messaging works on Arbitrum: messages that are sent through the bridge are "retryable tickets" that must be executed within 7 days, and the initial execution might need a retry if there are spikes in the gas price on Arbitrum.
+
+## Sending curation to L2: step 2
+
+Starting the transfer:
+
+![Send signal to L2](/img/sendingCurationToL2Step2First.png)
+
+After you start the transfer, the message that sends your L1 curation to L2 must propagate through the Arbitrum bridge. This takes approximately 20 minutes (the bridge waits for the mainnet block containing the transaction to be "safe" from potential chain reorgs).
+
+Once this wait time is over, Arbitrum will attempt to auto-execute the transfer on the L2 contracts.
+
+![Sending curation signal to L2](/img/sendingCurationToL2Step2Second.png)
+
+## Sending curation to L2: step 3
+
+In most cases, this step will auto-execute as the L2 gas included in step 1 should be sufficient to execute the transaction that receives the curation on the Arbitrum contracts. In some cases, however, it is possible that a spike in gas prices on Arbitrum causes this auto-execution to fail. In this case, the "ticket" that sends your curation to L2 will be pending and require a retry within 7 days.
+
+If this is the case, you will need to connect using an L2 wallet that has some ETH on Arbitrum, switch your wallet network to Arbitrum, and click on "Confirm Transfer" to retry the transaction.
+
+![Send signal to L2](/img/L2TransferToolsFinalCurationImage.png)
+
+## Withdrawing your curation on L1
+
+If you prefer not to send your GRT to L2, or you'd rather bridge the GRT manually, you can withdraw your curated GRT on L1. On the banner on the subgraph page, choose "Withdraw Signal" and confirm the transaction; the GRT will be sent to your Curator address.

From aff25e15fdb496c43de6154f6eda4dfa06ffb331 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:30 -0500
Subject: [PATCH 1066/3820] New translations sunrise.mdx (Romanian)

---
 website/pages/ro/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/ro/archived/sunrise.mdx

diff --git a/website/pages/ro/archived/sunrise.mdx b/website/pages/ro/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/ro/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 7dafe335999dbefb0a1db77a146afe1f0f053392 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:31 -0500
Subject: [PATCH 1067/3820] New translations sunrise.mdx (French)

---
 website/pages/fr/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/fr/archived/sunrise.mdx

diff --git a/website/pages/fr/archived/sunrise.mdx b/website/pages/fr/archived/sunrise.mdx
new file mode 100644
index 000000000000..69849570e085
--- /dev/null
+++ b/website/pages/fr/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## À propos de l'indexeur de mise à niveau
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Pourquoi Edge & Node exécutent-ils l'indexeur de mise à niveau ?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### Que signifie la mise à niveau de l'indexeur pour les indexeurs existants ?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+L'indexeur de mise à niveau active les chaînes sur le réseau qui n'étaient auparavant prises en charge que sur le service hébergé. Par conséquent, il élargit la portée et la disponibilité des données pouvant être interrogées sur le réseau.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 15ea4a0e7e29e76ab2008f7066983ed93fde2604 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:32 -0500
Subject: [PATCH 1068/3820] New translations sunrise.mdx (Spanish)

---
 website/pages/es/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/es/archived/sunrise.mdx

diff --git a/website/pages/es/archived/sunrise.mdx b/website/pages/es/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/es/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From a4a9033d7c78249e46faa6010d542d9a5796c9c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:33 -0500
Subject: [PATCH 1069/3820] New translations sunrise.mdx (Arabic)

---
 website/pages/ar/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/ar/archived/sunrise.mdx

diff --git a/website/pages/ar/archived/sunrise.mdx b/website/pages/ar/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/ar/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 45235541498f1238a7d64e19531d4e69490a2eba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:34 -0500
Subject: [PATCH 1070/3820] New translations sunrise.mdx (Czech)

---
 website/pages/cs/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/cs/archived/sunrise.mdx

diff --git a/website/pages/cs/archived/sunrise.mdx b/website/pages/cs/archived/sunrise.mdx
new file mode 100644
index 000000000000..ff6e948c0d9a
--- /dev/null
+++ b/website/pages/cs/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Časté dotazy po východu slunce + aktualizace na síť Graf
+---
+
+> Poznámka: Východ slunce decentralizovaných dat skončil 12. června 2024.
+
+## Jaký byl úsvit decentralizovaných dat?
+
+Úsvit decentralizovaných dat byla iniciativa, kterou vedla společnost Edge & Node. Tato iniciativa umožnila vývojářům podgrafů bezproblémově přejít na decentralizovanou síť Graf.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### Co se stalo s hostovanou službou?
+
+Koncové body dotazů hostované služby již nejsou k dispozici a vývojáři nemohou v hostované službě nasadit nové podgrafy.
+
+Během procesu aktualizace mohli vlastníci podgrafů hostovaných služeb aktualizovat své podgrafy na síť Graf. Vývojáři navíc mohli nárokovat automatickou aktualizaci podgrafů.
+
+### Měla tato aktualizace vliv na Podgraf Studio?
+
+Ne, na Podgraf Studio neměl Sunrise vliv. Podgrafy byly okamžitě k dispozici pro dotazování, a to díky aktualizačnímu indexeru, který využívá stejnou infrastrukturu jako hostovaná služba.
+
+### Proč byly podgrafy zveřejněny na Arbitrum, začalo indexovat jinou síť?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## O Upgrade Indexer
+
+> Aktualizace Indexer je v současné době aktivní.
+
+Upgrade Indexer byl implementován za účelem zlepšení zkušeností s upgradem podgrafů z hostované služby do sit' Graf a podpory nových verzí stávajících podgrafů, které dosud nebyly indexovány.
+
+### Co dělá upgrade Indexer?
+
+- Zavádí řetězce, které ještě nezískaly odměnu za indexaci v síti Graf, a zajišťuje, aby byl po zveřejnění podgrafu co nejrychleji k dispozici indexátor pro obsluhu dotazů.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexátoři, kteří provozují upgrade indexátoru, tak činí jako veřejnou službu pro podporu nových podgrafů a dalších řetězců, kterým chybí indexační odměny, než je Rada grafů schválí.
+
+### Proč Edge & Node spouští aktualizaci Indexer?
+
+Edge & Node historicky udržovaly hostovanou službu, a proto již mají synchronizovaná data pro podgrafy hostované služby.
+
+### Co znamená upgrade indexeru pro stávající indexery?
+
+Řetězce, které byly dříve podporovány pouze v hostované službě, byly vývojářům zpřístupněny v síti Graf nejprve bez odměn za indexování.
+
+Tato akce však uvolnila poplatky za dotazy pro všechny zájemce o indexování a zvýšila počet podgrafů zveřejněných v síti Graf. V důsledku toho mají indexátoři více příležitostí indexovat a obsluhovat tyto podgrafy výměnou za poplatky za dotazy, a to ještě předtím, než jsou odměny za indexování pro řetězec povoleny.
+
+Upgrade Indexer také poskytuje komunitě Indexer informace o potenciální poptávce po podgrafech a nových řetězcích v síti grafů.
+
+### Co to znamená pro delegáti?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+Aktualizace Indexeru umožňuje podporu blockchainů v síti, které byly dříve dostupné pouze v rámci hostované služby. Tímto se rozšiřuje rozsah a dostupnost dat, která lze v síti dotazovat.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 8933906ae307f6ba9d6b8dff2bb1d38a14f38c07 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:35 -0500
Subject: [PATCH 1071/3820] New translations sunrise.mdx (German)

---
 website/pages/de/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/de/archived/sunrise.mdx

diff --git a/website/pages/de/archived/sunrise.mdx b/website/pages/de/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/de/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 86379dbb535126bccc749c8d0b1b41f6eca1aaaf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:37 -0500
Subject: [PATCH 1072/3820] New translations sunrise.mdx (Italian)

---
 website/pages/it/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/it/archived/sunrise.mdx

diff --git a/website/pages/it/archived/sunrise.mdx b/website/pages/it/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/it/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 7340558d225b51d697152a828c41e89cd7f09aad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:38 -0500
Subject: [PATCH 1073/3820] New translations sunrise.mdx (Japanese)

---
 website/pages/ja/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/ja/archived/sunrise.mdx

diff --git a/website/pages/ja/archived/sunrise.mdx b/website/pages/ja/archived/sunrise.mdx
new file mode 100644
index 000000000000..0ffb746a1721
--- /dev/null
+++ b/website/pages/ja/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### なぜEdge & Nodeはアップグレード・インデクサーを実行しているのか？
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### これはデリゲーターにとって何を意味するのか？
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 18863a4929297e8a1474f9877d508a4e540f600d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:39 -0500
Subject: [PATCH 1074/3820] New translations sunrise.mdx (Korean)

---
 website/pages/ko/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/ko/archived/sunrise.mdx

diff --git a/website/pages/ko/archived/sunrise.mdx b/website/pages/ko/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/ko/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 8cccff0a85d94e267973ff796878b5efbfe334fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:40 -0500
Subject: [PATCH 1075/3820] New translations sunrise.mdx (Dutch)

---
 website/pages/nl/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/nl/archived/sunrise.mdx

diff --git a/website/pages/nl/archived/sunrise.mdx b/website/pages/nl/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/nl/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 992937c747a3173d788f95f08d69edd78cf6d684 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:41 -0500
Subject: [PATCH 1076/3820] New translations sunrise.mdx (Polish)

---
 website/pages/pl/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/pl/archived/sunrise.mdx

diff --git a/website/pages/pl/archived/sunrise.mdx b/website/pages/pl/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/pl/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 61d3a2dfa5818ca79a7f4ed7ae7a726695708d14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:42 -0500
Subject: [PATCH 1077/3820] New translations sunrise.mdx (Portuguese)

---
 website/pages/pt/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/pt/archived/sunrise.mdx

diff --git a/website/pages/pt/archived/sunrise.mdx b/website/pages/pt/archived/sunrise.mdx
new file mode 100644
index 000000000000..fcce15ecd28d
--- /dev/null
+++ b/website/pages/pt/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Perguntas Frequentes sobre o Pós-Nascer do Sol + Atualizações para a Graph Network
+---
+
+> Nota: O Nascer do Sol dos Dados Descentralizados foi encerrado em 12 de junho de 2024.
+
+## O Que Foi o Nascer do Sol dos Dados Descentralizados?
+
+O Nascer do Sol dos Dados Descentralizados foi uma iniciativa liderada pela Edge & Node, com a meta de garantir que os programadores de subgraphs fizessem uma atualização suave para a rede descentralizada do The Graph.
+
+Este plano teve base em desenvolvimentos anteriores do ecossistema do The Graph, e incluiu um Indexador de atualização para servir queries em subgraphs recém-editados.
+
+### O que aconteceu com o serviço hospedado?
+
+Os endpoints de query do serviço hospedado não estão mais disponíveis, e programadores não podem mais editar subgraphs novos no serviço hospedado.
+
+Durante o processo de atualização, donos de subgraphs no serviço hospedado puderam atualizar os seus subgraphs até a Graph Network. Além disto, programadores podiam resgatar subgraphs atualizados automaticamente.
+
+### O Subgraph Studio foi atingido por esta atualização?
+
+Não, o Subgraph Studio não foi impactado pelo Nascer do Sol. Os subgraphs estavam disponíveis imediatamente para queries, movidos pelo Indexador de atualização, que usa a mesma infraestrutura do serviço hospedado.
+
+### Por que subgraphs eram publicados ao Arbitrum, eles começaram a indexar uma rede diferente?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## Sobre o Indexador de Atualização
+
+> O Indexador de Atualização está atualmente ativo.
+
+O Indexador de atualização foi construído para melhorar a experiência de atualizar subgraphs do serviço hospedado à Graph Network e apoiar novas versões de subgraphs existentes que ainda não foram indexados.
+
+### O que o Indexador de atualização faz?
+
+- Ele inicializa chains que ainda não tenham recompensas de indexação na Graph Network, e garante que um Indexador esteja disponível para servir queries o mais rápido possível após a publicação de um subgraph.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexadores que operam um Indexador de atualização o fazem como um serviço público, para apoiar novos subgraphs e chains adicionais que não tenham recompensas de indexação antes da aprovação do Graph Council.
+
+### Porque a Edge & Node executa o Indexador de atualização?
+
+A Edge & Node operou historicamente o serviço hospedado, e como resultado, já sincronizou os dados de subgraphs do serviço hospedado.
+
+### O que o Indexador de atualização significa para Indexadores existentes?
+
+Chains que antes só eram apoiadas no serviço hospedado foram disponibilizadas para programadores na Graph Network, inicialmente, sem recompensas de indexação.
+
+Porém, esta ação liberou taxas de query para qualquer Indexador interessado e aumentou o número de subgraphs publicados na Graph Network. Como resultado, Indexadores têm mais oportunidades para indexar e servir estes subgraphs em troca de taxas de query, antes mesmo da ativação de recompensas de indexação para uma chain.
+
+O Indexador de atualização também fornece à comunidade de Indexadores informações sobre a demanda em potencial para subgraphs e novas chains na Graph Network.
+
+### O que isto significa para Delegantes?
+
+O Indexador de atualização oferece uma forte oportunidade para Delegantes. Como ele permitiu que mais subgraphs fossem atualizados do serviço hospedado até a Graph Network, os Delegantes podem se beneficiar do aumento na atividade da rede.
+
+### O Indexador de atualização concorreu com Indexadores existentes para recompensas?
+
+Não, o Indexador de atualização só aloca a quantidade mínima por subgraph e não coleta recompensas de indexação.
+
+Ele opera numa base de "necessidade" e serve como uma reserva até que uma cota de qualidade de serviço seja alcançada por, no mínimo, três outros Indexadores na rede para chains e subgraphs respetivos.
+
+### Como isto afeta os programadores de subgraph?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### Como o Indexador de atualizações beneficia consumidores de dados?
+
+O Indexador de atualização ativa, na rede, chains que antes só tinham apoio no serviço hospedado. Assim, ele aumenta o alcance e a disponibilidade de dados que podem ser consultados na rede.
+
+### Como o Indexador de atualização precifica queries?
+
+O Indexador de atualização precifica queries no preço do mercado, para não influenciar o mercado de taxas de queries.
+
+### Quando o Indexador de atualização parará de apoiar um subgraph?
+
+O Indexador de atualização apoia um subgraph até que, no mínimo, 3 outros indexadores sirvam queries feitas nele com êxito e consistência.
+
+Além disto, o Indexador de atualização para de apoiar um subgraph se ele não tiver sido consultado nos últimos 30 dias.
+
+Outros Indexadores são incentivados a apoiar subgraphs com o volume de query atual. O volume de query ao Indexador de atualização deve se aproximar de zero, já que ele tem um tamanho de alocação pequeno e outros Indexadores devem ser escolhidos por queries antes disso.

From bd75a801cfa58ddcc3c8471bbaf89d5e072c5ece Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:43 -0500
Subject: [PATCH 1078/3820] New translations sunrise.mdx (Russian)

---
 website/pages/ru/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/ru/archived/sunrise.mdx

diff --git a/website/pages/ru/archived/sunrise.mdx b/website/pages/ru/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/ru/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 04229fde7c5b4b90a04fb933451141bfe39cf894 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:44 -0500
Subject: [PATCH 1079/3820] New translations sunrise.mdx (Swedish)

---
 website/pages/sv/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/sv/archived/sunrise.mdx

diff --git a/website/pages/sv/archived/sunrise.mdx b/website/pages/sv/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/sv/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From aaf1d3fbad2400152900b627701d8e1f214e7d1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:44 -0500
Subject: [PATCH 1080/3820] New translations sunrise.mdx (Turkish)

---
 website/pages/tr/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/tr/archived/sunrise.mdx

diff --git a/website/pages/tr/archived/sunrise.mdx b/website/pages/tr/archived/sunrise.mdx
new file mode 100644
index 000000000000..91c6e09fd7c6
--- /dev/null
+++ b/website/pages/tr/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Yükseltme İndeksleyicisini neden Edge & Node çalıştırıyor?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### Bu Delegatörler için ne anlama gelmektedir?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 833cc82b91e4fff899eec752d4e51e8ff91dae65 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:45 -0500
Subject: [PATCH 1081/3820] New translations sunrise.mdx (Ukrainian)

---
 website/pages/uk/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/uk/archived/sunrise.mdx

diff --git a/website/pages/uk/archived/sunrise.mdx b/website/pages/uk/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/uk/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From c431adfd075626282f4b0bd49ff849a21b1fe306 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:46 -0500
Subject: [PATCH 1082/3820] New translations sunrise.mdx (Chinese Simplified)

---
 website/pages/zh/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/zh/archived/sunrise.mdx

diff --git a/website/pages/zh/archived/sunrise.mdx b/website/pages/zh/archived/sunrise.mdx
new file mode 100644
index 000000000000..0e7fafa344d0
--- /dev/null
+++ b/website/pages/zh/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### 为什么 Edge & Node 运行升级索引人？
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### 这对于委托人来说意味着什么？
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From a0f78c34e8fac4eff4289437878e91a08cdefe20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:47 -0500
Subject: [PATCH 1083/3820] New translations sunrise.mdx (Urdu (Pakistan))

---
 website/pages/ur/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/ur/archived/sunrise.mdx

diff --git a/website/pages/ur/archived/sunrise.mdx b/website/pages/ur/archived/sunrise.mdx
new file mode 100644
index 000000000000..9591fa169909
--- /dev/null
+++ b/website/pages/ur/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### ایج اور نوڈ اپ گریڈ انڈیکسر کیوں چلا رہا ہے؟
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### ڈیلیگیٹرز کے لیے اس کا کیا مطلب ہے؟
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 229d9c340997a20417bf78ee2575818f986520bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:49 -0500
Subject: [PATCH 1084/3820] New translations sunrise.mdx (Vietnamese)

---
 website/pages/vi/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/vi/archived/sunrise.mdx

diff --git a/website/pages/vi/archived/sunrise.mdx b/website/pages/vi/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/vi/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 78424a3a5c7140837ba7d24cdfbd8a978a9788f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:50 -0500
Subject: [PATCH 1085/3820] New translations sunrise.mdx (Marathi)

---
 website/pages/mr/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/mr/archived/sunrise.mdx

diff --git a/website/pages/mr/archived/sunrise.mdx b/website/pages/mr/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/mr/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From ebba8bb49561ebc7c8f197e722b5cc5b989746ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:51 -0500
Subject: [PATCH 1086/3820] New translations sunrise.mdx (Hindi)

---
 website/pages/hi/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/hi/archived/sunrise.mdx

diff --git a/website/pages/hi/archived/sunrise.mdx b/website/pages/hi/archived/sunrise.mdx
new file mode 100644
index 000000000000..3d0b56717d5f
--- /dev/null
+++ b/website/pages/hi/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: पोस्ट-सनराइज + The Graph Network में अपग्रेडिंग FAQ
+---
+
+> नोट: Decentralized Data का Sunrise 12 जून, 2024 को समाप्त हो गया।
+
+## विकेंद्रीकृत डेटा का सूर्योदय क्या था?
+
+"Decentralized Data का उदय" Edge & Node द्वारा आरंभ की गई एक पहल थी। इस पहल ने subgraph डेवलपर्स को The Graph के विकेंद्रीकृत नेटवर्क में सहजता से अपग्रेड करने में सक्षम बनाया।
+
+इस योजना ने The Graph इकोसिस्टम के पिछले विकासों पर आधारित किया, जिसमें नए प्रकाशित सबग्राफ पर क्वेरी सर्व करने के लिए एक अपग्रेडेड इंडेक्सर शामिल था।
+
+### Hosted service का क्या होगा?
+
+होस्टेड सेवा के क्वेरी एंडपॉइंट अब उपलब्ध नहीं हैं, और डेवलपर्स होस्टेड सेवा पर नए सबग्राफ्स को तैनात नहीं कर सकते हैं।
+
+अपग्रेड प्रक्रिया के दौरान, होस्टेड सर्विस सबग्राफ के मालिक अपने सबग्राफ को The Graph Network पर अपग्रेड कर सकते थे। इसके अतिरिक्त, डेवलपर्स ऑटो-अपग्रेड किए गए सबग्राफ को क्लेम करने में सक्षम थे।
+
+### क्या इस अपग्रेड से Subgraph Studio प्रभावित हुआ था?
+
+नहीं, सबग्राफ स्टूडियो पर Sunrise का कोई प्रभाव नहीं पड़ा। सबग्राफ तुरंत क्वेरी के लिए उपलब्ध थे, जो अपग्रेड किए गए Indexer द्वारा संचालित हैं, जो उसी इंफ्रास्ट्रक्चर का उपयोग करता है जैसा Hosted Service में होता है।
+
+### सबग्राफ्स को Arbitrum पर क्यों प्रकाशित किया गया, क्या इसने एक अलग नेटवर्क को इंडेक्स करना शुरू किया?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> अपग्रेड Indexer वर्तमान में सक्रिय है।
+
+अपग्रेड Indexer को Hosted Service से The Graph Network में सबग्राफ़्स के अपग्रेड करने के अनुभव को सुधारने और उन मौजूदा सबग्राफ़्स के नए संस्करणों का समर्थन करने के लिए लागू किया गया था जो अभी तक इंडेक्स नहीं किए गए थे।
+
+### अपग्रेड Indexer क्या करता है?
+
+- यह उन चेन को बूटस्ट्रैप करता है जिन्हें अभी तक The Graph Network पर इंडेक्सिंग पुरस्कार नहीं मिले हैं और यह सुनिश्चित करता है कि एक Indexer उपलब्ध हो ताकि एक Subgraph प्रकाशित होने के तुरंत बाद क्वेरी को यथाशीघ्र सेवा दी जा सके।
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- जो Indexer अपग्रेड इंडेक्सर का संचालन करते हैं, वे नए सबग्राफ़ और अतिरिक्त चेन का समर्थन करने के लिए एक सार्वजनिक सेवा के रूप में ऐसा करते हैं जो इंडेक्सिंग पुरस्कारों की कमी का सामना कर रहे हैं, जब तक कि The Graph काउंसिल उन्हें मंजूरी नहीं देती।
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node ने ऐतिहासिक रूप से होस्टेड सेवा का प्रबंधन किया है और, परिणामस्वरूप, उनके पास होस्टेड सेवा के सबग्राफ के लिए पहले से ही समन्वयित डेटा है।
+
+### What does the upgrade indexer mean for existing Indexers?
+
+पहले केवल होस्टेड सेवा पर समर्थित चेन अब बिना indexing पुरस्कार के डेवलपर्स के लिएT he Graph Network पर उपलब्ध कराई गईं।
+
+हालांकि, इस कार्रवाई ने किसी भी इच्छुक Indexer के लिए क्वेरी शुल्क को अनलॉक कर दिया और The Graph Network पर प्रकाशित सबग्राफ की संख्या बढ़ा दी। परिणामस्वरूप, Indexers के पास इन सबग्राफ को इंडेक्स करने और सेवा देने के लिए अधिक अवसर हैं, जो कि क्वेरी शुल्क के बदले में हैं, यहां तक कि जब तक किसी चेन के लिए इंडेक्सिंग इनाम सक्षम नहीं होते।
+
+अपग्रेड इंडेक्सर Indexer समुदाय को The Graph Network पर सबग्राफ और नए चेन की संभावित मांग के बारे में जानकारी भी प्रदान करता है।
+
+### What does this mean for Delegators?
+
+अपग्रेड Indexer डेलीगेटर्स के लिए एक शक्तिशाली अवसर प्रदान करता है। क्योंकि इससे अधिक सबग्राफ को होस्टेड सेवा से The Graph Network में अपग्रेड करने की अनुमति मिली, डेलीगेटर्स को बढ़ी हुई नेटवर्क गतिविधि का लाभ मिलता है।
+
+### क्या अपग्रेड किया गया Indexer मौजूदा Indexer के साथ पुरस्कारों के लिए प्रतिस्पर्धा करता था?
+
+नहीं, अपग्रेड किया गया Indexer केवल प्रति Subgraph न्यूनतम राशि आवंटित करता है और indexing पुरस्कार एकत्र नहीं करता है।
+
+यह "आवश्यकता अनुसार" आधार पर काम करता है, एक बैकअप के रूप में कार्य करता है जब तक कि नेटवर्क में संबंधित चेन और सबग्राफ के लिए कम से कम तीन अन्य Indexer द्वारा पर्याप्त सेवा गुणवत्ता प्राप्त नहीं की जाती।
+
+### यह Subgraph डेवलपर्स को कैसे प्रभावित करता है?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### अपग्रेड Indexer डेटा उपभोक्ताओं को कैसे लाभ पहुंचाता है?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### अपग्रेड Indexer क्वेरीज़ की कीमत कैसे तय करता है?
+
+अपग्रेड में Indexer बाज़ार दर पर क्वेरीज़ की कीमत तय करता है ताकि क्वेरी शुल्क बाज़ार पर कोई प्रभाव न पड़े।
+
+### अपग्रेड Indexer कब एक Subgraph का समर्थन करना बंद करेगा?
+
+अपग्रेड Indexer एक Subgraph का समर्थन करता है जब तक कि कम से कम 3 अन्य Indexers सफलतापूर्वक और लगातार किए गए प्रश्नों का उत्तर नहीं देते।
+
+इसके अतिरिक्त, अपग्रेड Indexer एक Subgraph का समर्थन करना बंद कर देता है यदि उसे पिछले 30 दिनों में क्वेरी नहीं किया गया है।
+
+अन्य Indexer को उन सबग्राफ का समर्थन करने के लिए प्रोत्साहित किया जाता है जिनमें निरंतर क्वेरी वॉल्यूम होता है। अपग्रेड Indexer के लिए क्वेरी वॉल्यूम शून्य की ओर बढ़ना चाहिए, क्योंकि इसका आवंटन आकार छोटा होता है, और क्वेरी के लिए अन्य Indexer को प्राथमिकता दी जानी चाहिए।

From d50af9b6136ae3f7f85c47801061f1387979a3c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:52 -0500
Subject: [PATCH 1087/3820] New translations sunrise.mdx (Swahili)

---
 website/pages/sw/archived/sunrise.mdx | 79 +++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 website/pages/sw/archived/sunrise.mdx

diff --git a/website/pages/sw/archived/sunrise.mdx b/website/pages/sw/archived/sunrise.mdx
new file mode 100644
index 000000000000..f9419c36d642
--- /dev/null
+++ b/website/pages/sw/archived/sunrise.mdx
@@ -0,0 +1,79 @@
+---
+title: Post-Sunrise + Upgrading to The Graph Network FAQ
+---
+
+> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+
+## What was the Sunrise of Decentralized Data?
+
+The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+
+This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+
+### What happened to the hosted service?
+
+The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+
+During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+
+### Was Subgraph Studio impacted by this upgrade?
+
+No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+
+### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+
+The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+
+## About the Upgrade Indexer
+
+> The upgrade Indexer is currently active.
+
+The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+
+### What does the upgrade Indexer do?
+
+- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
+- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+
+### Why is Edge & Node running the upgrade Indexer?
+
+Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+
+### What does the upgrade indexer mean for existing Indexers?
+
+Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+
+However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+
+The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+
+### What does this mean for Delegators?
+
+The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+
+### Did the upgrade Indexer compete with existing Indexers for rewards?
+
+No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+
+It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+
+### How does this affect subgraph developers?
+
+Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+
+### How does the upgrade Indexer benefit data consumers?
+
+The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+
+### How does the upgrade Indexer price queries?
+
+The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+
+### When will the upgrade Indexer stop supporting a subgraph?
+
+The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+
+Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+
+Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.

From 3fe3c30b31305e3f4cf81c4ce45d16ea683df87e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:53 -0500
Subject: [PATCH 1088/3820] New translations contracts.mdx (Romanian)

---
 website/pages/ro/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ro/contracts.mdx

diff --git a/website/pages/ro/contracts.mdx b/website/pages/ro/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/ro/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From e924d7741778c514b4b7dcbd8fea39b28544859d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:54 -0500
Subject: [PATCH 1089/3820] New translations contracts.mdx (French)

---
 website/pages/fr/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/fr/contracts.mdx

diff --git a/website/pages/fr/contracts.mdx b/website/pages/fr/contracts.mdx
new file mode 100644
index 000000000000..3d712558cfe9
--- /dev/null
+++ b/website/pages/fr/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Contrats du Protocole
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Ci-dessous, les contrats déployés qui alimentent The Graph Network. Visitez le [dépôt officiel des contrats](https://github.com/graphprotocol/contracts) pour en savoir plus.
+
+## Arbitrum
+
+Il s'agit du déploiement principal de The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Réseau principal
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+Il s'agit du testnet principal pour The Graph Network. Le testnet est principalement utilisé par les développeurs principaux et les participants de l'écosystème à des fins de test. Il n'y a aucune garantie de service ou de disponibilité sur les testnets de The Graph.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 0571f82eac73f42966d3006eb167ff700403e360 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:55 -0500
Subject: [PATCH 1090/3820] New translations contracts.mdx (Spanish)

---
 website/pages/es/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/es/contracts.mdx

diff --git a/website/pages/es/contracts.mdx b/website/pages/es/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/es/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 84ed7d8f00b0963c30e5b1908676409f1c635fcd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:56 -0500
Subject: [PATCH 1091/3820] New translations contracts.mdx (Arabic)

---
 website/pages/ar/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ar/contracts.mdx

diff --git a/website/pages/ar/contracts.mdx b/website/pages/ar/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/ar/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 10c58af65886fd2a09e7e524390c1a529b32da7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:57 -0500
Subject: [PATCH 1092/3820] New translations contracts.mdx (Czech)

---
 website/pages/cs/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/cs/contracts.mdx

diff --git a/website/pages/cs/contracts.mdx b/website/pages/cs/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/cs/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 21511e2531cf092f70f1100f09473d776dfef88d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:58 -0500
Subject: [PATCH 1093/3820] New translations contracts.mdx (German)

---
 website/pages/de/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/de/contracts.mdx

diff --git a/website/pages/de/contracts.mdx b/website/pages/de/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/de/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 810ab6e29da2b1fc4e357e04002874020af3b7d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:03:59 -0500
Subject: [PATCH 1094/3820] New translations contracts.mdx (Italian)

---
 website/pages/it/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/it/contracts.mdx

diff --git a/website/pages/it/contracts.mdx b/website/pages/it/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/it/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From f64d8d481cb01ec488792fd79bbc5be61f1f67df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:00 -0500
Subject: [PATCH 1095/3820] New translations contracts.mdx (Japanese)

---
 website/pages/ja/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ja/contracts.mdx

diff --git a/website/pages/ja/contracts.mdx b/website/pages/ja/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/ja/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 58f510332f2cf7796d0a756cf9691bfb06329366 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:01 -0500
Subject: [PATCH 1096/3820] New translations contracts.mdx (Korean)

---
 website/pages/ko/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ko/contracts.mdx

diff --git a/website/pages/ko/contracts.mdx b/website/pages/ko/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/ko/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 4cc37b74c1f68ff14d1ab41c255fc30bcb9b5bca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:02 -0500
Subject: [PATCH 1097/3820] New translations contracts.mdx (Dutch)

---
 website/pages/nl/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/nl/contracts.mdx

diff --git a/website/pages/nl/contracts.mdx b/website/pages/nl/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/nl/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 0f4efee366de33e01dbedbf55cd16496d457f197 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:03 -0500
Subject: [PATCH 1098/3820] New translations contracts.mdx (Polish)

---
 website/pages/pl/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/pl/contracts.mdx

diff --git a/website/pages/pl/contracts.mdx b/website/pages/pl/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/pl/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 20c67a3560452a5f33924da7cc14ac46b3c8ad4b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:04 -0500
Subject: [PATCH 1099/3820] New translations contracts.mdx (Portuguese)

---
 website/pages/pt/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/pt/contracts.mdx

diff --git a/website/pages/pt/contracts.mdx b/website/pages/pt/contracts.mdx
new file mode 100644
index 000000000000..c739c555ad21
--- /dev/null
+++ b/website/pages/pt/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Contratos de Protocolo
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Abaixo estão os contratos lançados que alimentam a Graph Network. Confira o [repositório oficial de contratos](https://github.com/graphprotocol/contracts) para aprender mais.
+
+## Arbitrum
+
+Este é o lançamento principal da Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+Esta é a testnet primária para a Graph Network. A testnet é usada predominantemente pelo núcleo de programação e por participantes do ecossistema para testes. Não há garantia de serviço ou disponibilidade nas testnets do The Graph.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 6e35b39441a9a4087d9e00a21959cfd2fda83991 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:05 -0500
Subject: [PATCH 1100/3820] New translations contracts.mdx (Russian)

---
 website/pages/ru/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ru/contracts.mdx

diff --git a/website/pages/ru/contracts.mdx b/website/pages/ru/contracts.mdx
new file mode 100644
index 000000000000..f4baf22afafd
--- /dev/null
+++ b/website/pages/ru/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Арбитрум
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From bbd83b4fa663738b288bc1d2d1159d93fb9d578e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:06 -0500
Subject: [PATCH 1101/3820] New translations contracts.mdx (Swedish)

---
 website/pages/sv/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/sv/contracts.mdx

diff --git a/website/pages/sv/contracts.mdx b/website/pages/sv/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/sv/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 1410030d7fec6926d94dc4edc47f764d67ed3125 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:07 -0500
Subject: [PATCH 1102/3820] New translations contracts.mdx (Turkish)

---
 website/pages/tr/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/tr/contracts.mdx

diff --git a/website/pages/tr/contracts.mdx b/website/pages/tr/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/tr/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From bcad852a77c861d83cb04c3a2e36e00a12af3a6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:08 -0500
Subject: [PATCH 1103/3820] New translations contracts.mdx (Ukrainian)

---
 website/pages/uk/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/uk/contracts.mdx

diff --git a/website/pages/uk/contracts.mdx b/website/pages/uk/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/uk/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From a15557654057da74c71b6c82ec01c9849edb5a8d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:09 -0500
Subject: [PATCH 1104/3820] New translations contracts.mdx (Chinese Simplified)

---
 website/pages/zh/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/zh/contracts.mdx

diff --git a/website/pages/zh/contracts.mdx b/website/pages/zh/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/zh/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 05bdccf4c26cf1c8302ee75de3b4b61853eba31d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:10 -0500
Subject: [PATCH 1105/3820] New translations contracts.mdx (Urdu (Pakistan))

---
 website/pages/ur/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ur/contracts.mdx

diff --git a/website/pages/ur/contracts.mdx b/website/pages/ur/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/ur/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From c15d28afbf4c3cea8ee07b7a461233f4d5f8ca54 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:11 -0500
Subject: [PATCH 1106/3820] New translations contracts.mdx (Vietnamese)

---
 website/pages/vi/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/vi/contracts.mdx

diff --git a/website/pages/vi/contracts.mdx b/website/pages/vi/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/vi/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From e354d426a1b863599bb96f162fc9455c6edf9d40 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:12 -0500
Subject: [PATCH 1107/3820] New translations contracts.mdx (Marathi)

---
 website/pages/mr/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/mr/contracts.mdx

diff --git a/website/pages/mr/contracts.mdx b/website/pages/mr/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/mr/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 58e0efa1531f02cb0833e77db36017b7fda3a769 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:13 -0500
Subject: [PATCH 1108/3820] New translations contracts.mdx (Hindi)

---
 website/pages/hi/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/hi/contracts.mdx

diff --git a/website/pages/hi/contracts.mdx b/website/pages/hi/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/hi/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From 063644f44ad7b14f4dfdf75562f31837e4a11b86 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:14 -0500
Subject: [PATCH 1109/3820] New translations contracts.mdx (Swahili)

---
 website/pages/sw/contracts.mdx | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/sw/contracts.mdx

diff --git a/website/pages/sw/contracts.mdx b/website/pages/sw/contracts.mdx
new file mode 100644
index 000000000000..d2255f3af336
--- /dev/null
+++ b/website/pages/sw/contracts.mdx
@@ -0,0 +1,29 @@
+---
+title: Protocol Contracts
+---
+
+import { ProtocolContractsTable } from '@/src/contracts'
+
+Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+
+## Arbitrum
+
+This is the principal deployment of The Graph Network.
+
+<ProtocolContractsTable networkId={42161} />
+
+## Mainnet
+
+This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+
+<ProtocolContractsTable networkId={1} />
+
+## Arbitrum Sepolia
+
+This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+
+<ProtocolContractsTable networkId={421614} />
+
+## Sepolia
+
+<ProtocolContractsTable networkId={11155111} />

From bb578d2ff27087a4f9f0b8c6ae9cb6db4b22f262 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:15 -0500
Subject: [PATCH 1110/3820] New translations chain-integration-overview.mdx
 (Romanian)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/ro/indexing/chain-integration-overview.mdx

diff --git a/website/pages/ro/indexing/chain-integration-overview.mdx b/website/pages/ro/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..77141e82b34a
--- /dev/null
+++ b/website/pages/ro/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From f3ac8e535a6c982747741e4aee9d14e2c2dce8e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:16 -0500
Subject: [PATCH 1111/3820] New translations chain-integration-overview.mdx
 (French)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/fr/indexing/chain-integration-overview.mdx

diff --git a/website/pages/fr/indexing/chain-integration-overview.mdx b/website/pages/fr/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..7f31c5af51aa
--- /dev/null
+++ b/website/pages/fr/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Aperçu du processus d'intégration de la chaîne
+---
+
+Un processus d'intégration transparent et basé sur la gouvernance a été conçu pour les équipes blockchain recherchant [l'intégration avec le protocole The Graph](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). Il s'agit d'un processus en trois phases, comme résumé ci-dessous.
+
+## Étape 1. Intégration technique
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Les équipes lancent le processus d'intégration du protocole en créant un fil de discussion sur le forum [ici](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (sous-catégorie Nouvelles sources de données sous Gouvernance et GIPs ). L'utilisation du modèle de forum par défaut est obligatoire.
+
+## Étape 2. Validation de l'intégration
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Les Graph Indexeurs testent l'intégration sur le réseau de testnet du graph.
+- Les développeurs principaux et les indexeurs surveillent la stabilité, les performances et le déterminisme des données.
+
+## Étape 3. Intégration du réseau principal
+
+- Les équipes proposent l'intégration du mainnet en soumettant une proposition d'amélioration du graphique (GIP) et en lançant une demande d'extraction (PR) sur la [matrice de support des fonctionnalités](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support -matrix.md) (plus de détails sur le lien).
+- The Graph Council examine la demande et approuve la prise en charge du mainnet, fournissant ainsi une étape 2 réussie et des commentaires positifs de la communauté.
+
+---
+
+Si le processus semble intimidant, ne vous inquiétez pas ! La Graph Foundation s'engage à soutenir les intégrateurs en favorisant la collaboration, en leur offrant des informations essentielles et en les guidant à travers différentes étapes, y compris la navigation dans les processus de gouvernance tels que les propositions d'amélioration de Graph (GIP) et les demandes d'extraction. Si vous avez des questions, veuillez contacter [info@thegraph.foundation](mailto:info@thegraph.foundation) ou via Discord (soit Pedro, membre de la Graph Foundation, IndexerDAO ou d'autres développeurs principaux).
+
+Prêt à façonner l’avenir de The Graph Network ? [Démarrez votre proposition](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) maintenant et faites partie de la révolution web3 !
+
+---
+
+## Questions fréquemment posées
+
+### 1. Quel est le rapport avec le [GIP World of Data Services](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761) ?
+
+Ce processus est lié au service de données Subgraph, applicable uniquement aux nouvelles « sources de données » de Subgraph.
+
+### 2. Que se passe-t-il si la prise en charge de Firehose et Substreams intervient après que le réseau est pris en charge sur le mainnet ?
+
+Cela n’aurait un impact que sur la prise en charge du protocole pour l’indexation des récompenses sur les subgraphs alimentés par Substreams. La nouvelle implémentation de Firehose nécessiterait des tests sur testnet, en suivant la méthodologie décrite pour l'étape 2 de ce GIP. De même, en supposant que l'implémentation soit performante et fiable, un PR sur la [Matrice de support des fonctionnalités](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) serait requis ( Fonctionnalité de sous-graphe « Sous-flux de sources de données »), ainsi qu'un nouveau GIP pour la prise en charge du protocole pour l'indexation des récompenses. N'importe qui peut créer le PR et le GIP ; la Fondation aiderait à obtenir l'approbation du Conseil.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+Le temps nécessaire à la mise en réseau principal devrait être de plusieurs semaines, variant en fonction du temps de développement de l'intégration, de la nécessité ou non de recherches supplémentaires, de tests et de corrections de bugs et, comme toujours, du calendrier du processus de gouvernance qui nécessite les commentaires de la communauté.
+
+La prise en charge du protocole pour l'indexation des récompenses dépend de la bande passante des parties prenantes pour procéder aux tests, à la collecte de commentaires et à la gestion des contributions à la base de code principale, le cas échéant. Ceci est directement lié à la maturité de l'intégration et à la réactivité de l'équipe d'intégration (qui peut ou non être l'équipe derrière la mise en œuvre de RPC/Firehose). La Fondation est là pour vous accompagner tout au long du processus.
+
+### 4. Comment les priorités seront-elles gérées ?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From f188bb6bddf1cafc3b388848c5dcab77944ad27f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:17 -0500
Subject: [PATCH 1112/3820] New translations chain-integration-overview.mdx
 (Spanish)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/es/indexing/chain-integration-overview.mdx

diff --git a/website/pages/es/indexing/chain-integration-overview.mdx b/website/pages/es/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..77141e82b34a
--- /dev/null
+++ b/website/pages/es/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From e0d11def9e89a820914ab648e91409d5b97c7ecf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:18 -0500
Subject: [PATCH 1113/3820] New translations chain-integration-overview.mdx
 (Arabic)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/ar/indexing/chain-integration-overview.mdx

diff --git a/website/pages/ar/indexing/chain-integration-overview.mdx b/website/pages/ar/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..e6b95ec0fc17
--- /dev/null
+++ b/website/pages/ar/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: نظرة عامة حول عملية التكامل مع الشبكة
+---
+
+تم تصميم عملية تكامل قائمة على الحوكمة وبشفافية لفرق سلاسل الكتل التي تسعى للإندماج مع بروتوكول الغراف (https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). إنها عملية مكونة من 3 مراحل، كما هو ملخص أدناه.
+
+## المرحلة الأولى: التكامل التقني
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- تستهل الفرق عملية التكامل مع البروتوكول من خلال إنشاء موضوع في المنتدى هنا(https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (الفئة الفرعية "مصادر البيانات الجديدة" تحت قسم "الحوكمة واقتراحات تحسين الغراف"). استخدام قالب المنتدى الافتراضي إلزامي.
+
+## المرحلة الثانية: التحقق من صحة التكامل
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- مفهرسو الغراف يختبرون التكامل على شبكة إختبار الغراف.
+- يقوم المطورون الأساسيون والمفهرسون بمراقبة استقرار، وأداء، وحتمية البيانات.
+
+## المرحلة الثالثة: التكامل مع الشبكة الرئيسية
+
+- يتم اقتراح التكامل مع الشبكة الرئيسية من قبل الفرق عن طريق تقديم اقتراح تحسين الغراف (GIP) واستهلال طلب سحب (PR) على مصفوفة دعم الميزات (https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md)(لمزيد من التفاصيل، يرجى زيارة الرابط).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+إذا بدت العملية مربكة، فلا تقلق! تلتزم مؤسسة الغراف بدعم المتكاملين من خلال تعزيز التعاون وتوفير المعلومات الجوهرية وتوجيههم خلال مراحل مختلفة، بما في ذلك توجيههم خلال عمليات الحوكمة مثل اقتراحات تحسين الغراف وطلبات السحب. إذا كان لديك أسئلة، فيرجى التواصل مع [info@thegraph.foundation](mailto:info@thegraph.foundation) أو من خلال ديسكورد (باستطاعتك التواصل مع بيدرو، عضو مؤسسة الغراف، أو IndexerDAO أو المطورين الأساسيين الآخرين).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## الأسئلة الشائعة
+
+### 1. كيف يتعلق هذا بـ مقترح تحسين الغراف "خدمات عالم البيانات" (https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)؟
+
+هذه العملية مرتبطة بخدمة بيانات الغراف الفرعي، وهي مطبقة فقط على مصادر بيانات الغراف الفرعي الجديد.
+
+### 2. ماذا يحدث إذا تم دعم فايرهوز و سبستريمز بعد أن تم دعم الشبكة على الشبكة الرئيسية؟
+
+هذا سيؤثر فقط على دعم البروتوكول لمكافآت الفهرسة على الغرافات الفرعية المدعومة من سبستريمز. تنفيذ الفايرهوز الجديد سيحتاج إلى الفحص على شبكة الاختبار، وفقًا للمنهجية الموضحة للمرحلة الثانية في هذا المقترح لتحسين الغراف. وعلى نحو مماثل، وعلى افتراض أن التنفيذ فعال وموثوق به، سيتتطالب إنشاء طلب سحب على [مصفوفة دعم الميزات] (https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) ("مصادر بيانات سبستريمز" ميزة للغراف الفرعي)، بالإضافة إلى مقترح جديد لتحسين الغراف، لدعم البروتوكول لمكافآت الفهرسة. يمكن لأي شخص إنشاء طلب السحب ومقترح تحسين الغراف؛ وسوف تساعد المؤسسة في الحصول على موافقة المجلس.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+يُتوقع أن يستغرق الوصول إلى الشبكة الرئيسية عدة أسابيع، وذلك يعتمد على وقت تطوير التكامل، وما إذا كانت هناك حاجة إلى بحوث إضافية، واختبارات وإصلاحات الأخطاء، وكذلك توقيت عملية الحوكمة التي تتطلب ملاحظات المجتمع كما هو الحال دائمًا.
+
+يعتمد دعم البروتوكول لمكافآت الفهرسة على قدرة أصحاب الحصص في المضي قدماً في عمليات الفحص وجمع الملاحظات ومعالجة المساهمات في قاعدة الكود الأساسية، إذا كان ذلك قابلاً للتطبيق. هذا مرتبط مباشرة بنضج عملية التكامل ومدى استجابة فريق التكامل (والذي قد يكون أو قد لا يكون نفس الفريق المسؤول عن تنفيذ إجراء الإستدعاء عن بعد\الفايرهوز). المؤسسة هنا لمساعدة الدعم خلال العملية بأكملها.
+
+### 4. كيف سيتم التعامل مع الأولويات؟
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 6dd0c098b35260ce54931ee88863bea41d5283bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:19 -0500
Subject: [PATCH 1114/3820] New translations chain-integration-overview.mdx
 (Czech)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/cs/indexing/chain-integration-overview.mdx

diff --git a/website/pages/cs/indexing/chain-integration-overview.mdx b/website/pages/cs/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..e048421d7ad9
--- /dev/null
+++ b/website/pages/cs/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Přehled procesu integrace řetězce
+---
+
+Pro blockchainové týmy, které usilují o [integraci s protokolem The Graph](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468), byl navržen transparentní a na správě založený integrační proces. Jedná se o třífázový proces, jak je shrnuto níže.
+
+## Fáze 1. Technická integrace
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Týmy zahájí proces integrace protokolu vytvořením vlákna na fóru [zde](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (podkategorie Nové zdroje dat v části Správa a GIP). Použití výchozí šablony Fóra je povinné.
+
+## Fáze 2. Ověřování integrace
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graf Indexers testují integraci na testovací síti Grafu.
+- Vývojáři jádra a indexátoři sledují stabilitu, výkon a determinismus dat.
+
+## Fáze 3. Integrace Mainnet
+
+- Týmy navrhují integraci mainnetu tak, že podají návrh na vylepšení grafu (Graph Improvement Proposal, GIP) a iniciují žádost o stažení (pull request, PR) v [matici podpory funkcí](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (více informací na tomto odkazu).
+- Rada pro graf přezkoumá žádost a schválí podporu mainnetu, čímž zajistí úspěšnou 2. fázi a pozitivní zpětnou vazbu od komunity.
+
+---
+
+Pokud vám tento proces připadá skličující, nebojte se! Nadace Graph Foundation se zavázala podporovat integrátory tím, že podporuje spolupráci, nabízí důležité informace a provází je různými fázemi, včetně navigace v procesech správy, jako jsou návrhy na zlepšení grafů (Graph Improvement Proposals, GIP) a žádosti o stažení. Pokud máte dotazy, obraťte se na [info@thegraph.foundation](mailto:info@thegraph.foundation) nebo prostřednictvím služby Discord (buď na Pedra, člena The Graph Foundation, IndexerDAO, nebo na další vývojáře jádra).
+
+Jste připraveni ovlivnit budoucnost sítě Grafu? [Začněte s návrhem](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) a staňte se součástí web3 revoluce!
+
+---
+
+## Často kladené otázky
+
+### 1. Jak to souvisí s [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+Tento proces souvisí se službou Datová služba podgrafů a vztahuje se pouze na nové `zdroje dat` podgrafu.
+
+### 2. Co se stane, když podpora Firehose & Substreams přijde až poté, co bude síť podporována v mainnet?
+
+To by mělo vliv pouze na podporu protokolu pro indexování odměn na podgrafech s podsílou. Novou implementaci Firehose by bylo třeba testovat v testnetu podle metodiky popsané pro fázi 2 v tomto GIP. Podobně, za předpokladu, že implementace bude výkonná a spolehlivá, by bylo nutné provést PR na [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (`Substreams data sources` Subgraph Feature) a také nový GIP pro podporu protokolu pro indexování odměn. PR a GIP může vytvořit kdokoli; nadace by pomohla se schválením Radou.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+Očekává se, že doba do uvedení do mainnetu bude trvat několik týdnů a bude se lišit v závislosti na době vývoje integrace, na tom, zda bude zapotřebí další výzkum, testování a opravy chyb, a jako vždy na načasování procesu řízení, který vyžaduje zpětnou vazbu od komunity.
+
+Podpora protokolu pro odměny za indexování závisí na šířce pásma zúčastněných stran, aby bylo možné pokračovat v testování, shromažďování zpětné vazby a případném zpracování příspěvků do hlavní databáze. To přímo souvisí s vyspělostí integrace a s tím, jak pohotově reaguje integrační tým (který může, ale nemusí být týmem stojícím za implementací RPC/Firehose). Nadace je tu od toho, aby pomohla s podporou během celého procesu.
+
+### 4. Jak budou řešeny priority?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 95635b42708c88d9af239e6b0fd6125a7796da57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:20 -0500
Subject: [PATCH 1115/3820] New translations chain-integration-overview.mdx
 (German)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/de/indexing/chain-integration-overview.mdx

diff --git a/website/pages/de/indexing/chain-integration-overview.mdx b/website/pages/de/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..77141e82b34a
--- /dev/null
+++ b/website/pages/de/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 79e9b72e18ec3efaf87c9f4e406a739983043d44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:21 -0500
Subject: [PATCH 1116/3820] New translations chain-integration-overview.mdx
 (Italian)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/it/indexing/chain-integration-overview.mdx

diff --git a/website/pages/it/indexing/chain-integration-overview.mdx b/website/pages/it/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..77141e82b34a
--- /dev/null
+++ b/website/pages/it/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 1e2f670d64dae080f7d9b02fb1756324ae9fece5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:22 -0500
Subject: [PATCH 1117/3820] New translations chain-integration-overview.mdx
 (Japanese)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/ja/indexing/chain-integration-overview.mdx

diff --git a/website/pages/ja/indexing/chain-integration-overview.mdx b/website/pages/ja/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..c9349b7a24e5
--- /dev/null
+++ b/website/pages/ja/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: チェーン統合プロセスの概要
+---
+
+透明性のあるガバナンスベースの統合プロセスは、[integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468) を求めるブロックチェーン チーム向けに設計されました。 以下に要約するように、これは 3 段階のプロセスです。
+
+## ステージ 1. 技術的統合
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- チームは、プロトコルの統合プロセスを開始するために、[here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71)のフォーラムスレッドを作成します（Governance & GIPsの下にあるNew Data Sourcesのサブカテゴリ内）。デフォルトのフォーラムテンプレートの使用が必須です。
+
+## ステージ 2. 統合の検証
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexer は、The Graph のテストネットで統合をテストします。
+- コア開発者とインデクサーは、安定性、パフォーマンス、およびデータの決定性を監視します。
+
+## ステージ 3. メインネットの統合
+
+- チームは、メインネット統合を提案するために、Graph Improvement Proposal (GIP) を提出し、[feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) に関するプルリクエスト（PR）を開始します（詳細はリンクを参照）。
+- Graph Council はリクエストを検討してメインネットのサポートを承認し、ステージ 2 の成功とコミュニティからの肯定的なフィードバックを提供します。
+
+---
+
+もしプロセスが難しそうに見える場合でも、心配しないでください！Graph Foundationは、協力を促進し、必要な情報を提供し、Graph Improvement Proposals（GIP）やプルリクエストなどのガバナンスプロセスを含むさまざまな段階でガイドすることにコミットしています。質問がある場合は、[info@thegraph.foundation](mailto:info@thegraph.foundation) またはDiscord（Pedro、The Graph Foundationメンバー、IndexerDAO、その他のコア開発者など）を通じてお問い合わせください。
+
+The Graph Network の未来を形作る準備はできていますか? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) 今すぐ、Web3 革命の一員になりましょう。
+
+---
+
+## よくある質問
+
+### 1. これは [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761) とどのように関連していますか?
+
+このプロセスは、新しいサブグラフの「データソース」にのみ適用される、サブグラフデータサービスに関連しています。
+
+### 2. ネットワークがメインネットでサポートされた後に Firehose とサブストリームのサポートが追加された場合はどうなりますか?
+
+これは、サブストリームで動作するサブグラフに対するインデックスリワードのプロトコルサポートに影響を与えるものです。新しいFirehoseの実装は、このGIPのステージ2に概説されている方法論に従って、テストネットでテストされる必要があります。同様に、実装がパフォーマンスが良く信頼性があると仮定して、[Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md)へのPR（「Substreamsデータソース」サブグラフ機能）が必要です。また、インデックスリワードのプロトコルサポートに関する新しいGIPも必要です。誰でもPRとGIPを作成できますが、Foundationは評議会の承認をサポートします。
+
+### 3. How much time will the process of reaching full protocol support take?
+
+メインネットへの移行にかかる時間は、統合開発の進捗によるもの、追加の調査が必要かどうか、テストとバグ修正、そして常にコミュニティのフィードバックを必要とするガバナンスプロセスのタイミングに応じて異なりますが、数週間を予想しています。
+
+インデックスリワードのプロトコルサポートは、テスト、フィードバックの収集、および必要な場合のコアコードベースへの貢献の取り扱いに関わる関係者の能力に依存します。これは、統合の成熟度と、統合チームのレスポンスの良さ（RPC/Firehose実装の背後にいるかどうかは問わない）に直接関連しています。Foundationは、プロセス全体を通じてサポートを提供するためにここにいます。
+
+### 4. 優先順位はどのように扱われますか?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 2f32b4ed3d48e03412bef097efb8bb2ac3c975d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:23 -0500
Subject: [PATCH 1118/3820] New translations chain-integration-overview.mdx
 (Korean)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/ko/indexing/chain-integration-overview.mdx

diff --git a/website/pages/ko/indexing/chain-integration-overview.mdx b/website/pages/ko/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..77141e82b34a
--- /dev/null
+++ b/website/pages/ko/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From b7e79c2b6a31b460d8d7ed3fd7745d5592b1a374 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:24 -0500
Subject: [PATCH 1119/3820] New translations chain-integration-overview.mdx
 (Dutch)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/nl/indexing/chain-integration-overview.mdx

diff --git a/website/pages/nl/indexing/chain-integration-overview.mdx b/website/pages/nl/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..77141e82b34a
--- /dev/null
+++ b/website/pages/nl/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 9a266fd7dba6498046ff4a7fc789f4377a2eb5e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:25 -0500
Subject: [PATCH 1120/3820] New translations chain-integration-overview.mdx
 (Polish)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/pl/indexing/chain-integration-overview.mdx

diff --git a/website/pages/pl/indexing/chain-integration-overview.mdx b/website/pages/pl/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..77141e82b34a
--- /dev/null
+++ b/website/pages/pl/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 9f76e238d4b05f5dec9e16e9d7cbf5c3ff0f8f3a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:26 -0500
Subject: [PATCH 1121/3820] New translations chain-integration-overview.mdx
 (Portuguese)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/pt/indexing/chain-integration-overview.mdx

diff --git a/website/pages/pt/indexing/chain-integration-overview.mdx b/website/pages/pt/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..21b1b2d99b14
--- /dev/null
+++ b/website/pages/pt/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Visão Geral do Processo de Integração de Chains
+---
+
+Um processo de integração transparente e baseado em governança foi desenhado por equipas de blockchain que procuram [a integração com o protocolo do Graph](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). É um processo de três fases, como resumido abaixo.
+
+## Fase 1. Integração Técnica
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Equipas iniciam o processo de integração de protocolo com a criação de um tópico de Fórum [aqui](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (Nova subcategoria de Fontes de Dados sob Governança e GIPs). O uso do modelo padrão do Fórum é obrigatório.
+
+## Fase 2. Validação de Integração
+
+- Equipas colaboram com o núcleo de programadores, com a Graph Foundation, e com operadores de interfaces gráficas e gateways de redes, como o [Subgraph Studio](https://thegraph.com/studio/), para garantir um processo de integração suave. Isto envolve a providência da infraestrutura de backend necessária, como o JSON RPC da chain a ser integrada, Firehose ou os endpoints de Substreams. Equipas que querem evitar a autohospedagem de tal infraestrutura podem usar a comunidade de operadores de nodes do The Graph (Indexadores) para fazê-lo, com qual a Foundation pode oferecer ajuda.
+- Indexadores do Graph testam a integração na testnet do The Graph.
+- O núcleo de programadores e os Indexadores monitoram a estabilidade, a performance e o determinismo dos dados.
+
+## Fase 3. Integração da Mainnet
+
+- As equipas propõem integração à mainnet com o envio de uma Proposta de Melhoria do Graph (GIP) e o início de um pull request (PR) no [matrix de apoio de funções](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (mais detalhes no link).
+- O Conselho do Graph revisa o pedido e aprova o apoio à mainnet, providenciando uma Fase 2 com êxito e aprovação da comunidade.
+
+---
+
+Se o processo parece difícil, não se preocupe! A Graph Foundation está comprometida com o apoio de integradores com o incentivo à colaboração, ofertas de informações essenciais, e guiá-los através de várias fases, incluindo a navegação de processos de governança, como Propostas de Melhoria do Graph (GIPs) e pull requests. Caso tenha alguma pergunta, entre em contacto no [info@thegraph.foundation](mailto:info@thegraph.foundation) ou através do Discord (por ex., Pedro, membro da Graph Foundation, IndexerDAO, ou outros programadores do núcleo).
+
+Tens o que é necessário para moldar o futuro da Graph Network? [Comece a sua proposta](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) agora e faça parte da revolução web3!
+
+---
+
+## Perguntas frequentes
+
+### 1. Que relação isto tem com a [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+Este processo é relacionado ao Serviço de Dados de Subgraph, no momento aplicável apenas para novas `Fontes de Dados` de Subgraph.
+
+### 2. O que acontece se o apoio ao Firehose e Substreams chegar após a rede ser apoiada na mainnet?
+
+Isto só impactaria o apoio do protocolo a recompensas de indexação em subgraphs movidos a Substreams. A nova implementação do Firehose precisaria de testes na testnet, seguindo a metodologia sublinhada na Fase 2 deste GIP. De maneira parecida, ao assumir que a implementação seja confiável e de bom desempenho, um PR no [Matrix de Apoio de Funções](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) seria requerido (A função de Subgraph `Substreams data sources`), assim como um novo GIP para apoio do protocolo a recompensas de indexação. Qualquer pessoa pode criar o PR e a GIP; a Foundation ajudaria com o apoio do Conselho.
+
+### 3. Quando tempo demora a conclusão do processo de alcance ao apoio total a protocolos?
+
+Espera-se que leve várias semanas, com variação a depender do tempo da programação da integração, da necessidade de pesquisas adicionais, testes e bugfixes, e como sempre, o timing do processo de governança que exige deliberações da comunidade.
+
+O apoio do protocolo às recompensas de indexação depende da banda dos acionistas para seguir com os testes, recepção de feedback, e gerenciamento de contribuições ao código-base central, se aplicável. Isto é ligado directamente à maturidade da integração e o quão responsiva a equipa de integração é (que pode ou não ser a equipa por trás da implementação do RPC/Firehose). A Foundation está aqui para ajudar durante todo o processo.
+
+### 4. Como as prioridades serão administradas?
+
+Assim como no passo #3, dependerá do preparo geral e da banda dos acionistas envolvidos. Por exemplo, uma nova chain, com uma implementação nova do Firehose, pode demorar mais que as integrações que já foram testadas ou estão mais adiantadas no processo de governança.

From efa0d45ea792bebad880df100e29bf7d23b88f3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:27 -0500
Subject: [PATCH 1122/3820] New translations chain-integration-overview.mdx
 (Russian)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/ru/indexing/chain-integration-overview.mdx

diff --git a/website/pages/ru/indexing/chain-integration-overview.mdx b/website/pages/ru/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..cb7944b336ae
--- /dev/null
+++ b/website/pages/ru/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+Прозрачный и основанный на управлении процесс интеграции был разработан для команд блокчейнов, стремящихся к [интеграции с протоколом The Graph] (https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). Это трехэтапный процесс, как описано ниже.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 9f265d22d4bc405c876ca55cca3e6241159ad801 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:28 -0500
Subject: [PATCH 1123/3820] New translations chain-integration-overview.mdx
 (Swedish)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/sv/indexing/chain-integration-overview.mdx

diff --git a/website/pages/sv/indexing/chain-integration-overview.mdx b/website/pages/sv/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..147468f7dc17
--- /dev/null
+++ b/website/pages/sv/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Översikt över Kedjeintegrationsprocessen
+---
+
+En transparent och styrbaserad integrationsprocess utformades för blockchain-team som söker [integration med The Graf-protokollet](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). Det är en process i 3 faser, sammanfattad nedan.
+
+## Fas 1. Teknisk Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Team startar protokollintegrationsprocessen genom att skapa en Forumtråd [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (Ny Datakällor underkategori under Governance & GIPs). Att använda standardforummallen är obligatoriskt.
+
+## Fas 2. Integrationsvalidering
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graf Indexers testar integrationen på The Graphs testnät.
+- Kärnutvecklare och Indexers övervakar stabilitet, prestanda och datadeterminism.
+
+## Fas 3. Mainnet-integration
+
+- Team föreslår mainnet-integration genom att skicka in en Graph Improvement Proposal (GIP) och starta en pull request (PR) på [funktionsstödsmatrisen](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (mer detaljer på länken).
+- The Graf Council granskar begäran och godkänner mainnet-stöd, förutsatt en framgångsrik Fas 2 och positiv feedback från gemenskapen.
+
+---
+
+Om processen verkar skrämmande, oroa dig inte! The Graph Foundation är engagerad i att stödja integratörer genom att främja samarbete, erbjuda väsentlig information och vägleda dem genom olika faser, inklusive att navigera genom styrdighetsprocesser som Graph Improvement Proposals (GIPs) och pull requests. Om du har frågor, var god kontakta [info@thegraph.foundation](mailto:info@thegraph.foundation) eller via Discord (antingen Pedro, The Graph Foundation-medlem, IndexerDAO eller andra kärnutvecklare).
+
+Redo att forma framtiden för The Graf Nätverk? [Börja ditt förslag](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) nu och bli en del av web3-revolutionen!
+
+---
+
+## Vanliga frågor
+
+### 1. Hur förhåller sig detta till [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+Denna process är relaterad till Subgraf Data Service och gäller endast nya Subgraf `Data Källor`.
+
+### 2. Vad händer om stöd för Firehose & Substreams kommer efter det att nätverket stöds på mainnet?
+
+Detta skulle endast påverka protokollstödet för indexbelöningar på Substreams-drivna subgrafer. Den nya Firehose-implementeringen skulle behöva testas på testnätet, enligt den metodik som beskrivs för Fas 2 i detta GIP. På liknande sätt, förutsatt att implementationen är prestanda- och tillförlitlig, skulle en PR på [Funktionsstödsmatrisen](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) krävas (`Substreams data sources` Subgraf Feature), liksom en ny GIP för protokollstöd för indexbelöningar. Vem som helst kan skapa PR och GIP; Stiftelsen skulle hjälpa till med Rådets godkännande.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+Tiden till mainnet förväntas vara flera veckor, varierande baserat på tidpunkten för integrationsutveckling, om ytterligare forskning krävs, testning och buggfixar, och, som alltid, timingen av styrdighetsprocessen som kräver gemenskapens återkoppling.
+
+Protokollstöd för indexbelöningar beror på intressenternas bandbredd att fortsätta med testning, insamling av återkoppling och hantering av bidrag till kärnkodbasen, om det är tillämpligt. Detta är direkt kopplat till integrationens mognad och hur responsivt integreringsteamet är (som kan vara eller inte vara teamet bakom RPC/Firehose-implementeringen). Stiftelsen är här för att hjälpa till med stöd genom hela processen.
+
+### 4. Hur kommer prioriteringar att hanteras?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From e027ed344a33ed8101aae3243f864a0293ea6b73 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:29 -0500
Subject: [PATCH 1124/3820] New translations chain-integration-overview.mdx
 (Turkish)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/tr/indexing/chain-integration-overview.mdx

diff --git a/website/pages/tr/indexing/chain-integration-overview.mdx b/website/pages/tr/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..db50f7b8e673
--- /dev/null
+++ b/website/pages/tr/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Zincir Entegrasyon Sürecine Genel Bakış
+---
+
+Blok zinciri ekiplerinin [Graph protokolüyle entegrasyon](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468) arayışı için şeffaf ve yönetişim odaklı bir entegrasyon süreci tasarlandı. Bu, aşağıda özetlendiği gibi 3 aşamalı bir süreçten oluşmaktadır.
+
+## Aşama 1. Teknik Entegrasyon
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Ekipler, protokol entegrasyon sürecini bir Forum başlığı oluşturarak başlatır [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (Yönetişim ve GIP'ler altındaki Yeni Veri Kaynakları alt kategorisi). Varsayılan Forum şablonunun kullanılması zorunludur.
+
+## Aşama 2. Entegrasyon Doğrulaması
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph İndeksleyicileri, entegrasyonu Graph'ın test ağında test eder.
+- Çekirdek geliştiriciler ve İndeksleyiciler kararlılığı, performansı ve veri belirleyiciliğini izler.
+
+## Aşama 3. Ana Ağ Entegrasyonu
+
+- Ekipler, bir Graph İyileştirme Teklifi (GIP) göndererek ve [özellik destek matrisinde](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) bir pull request (PR) başlatarak ana ağ entegrasyonu önermektedir (daha fazla ayrıntı bağlantıda).
+- Graph Konseyi talebi inceler, başarılı bir 2. Aşama ve olumlu topluluk geri bildirimi sağlayarak ana ağ desteğini onaylar.
+
+---
+
+Süreç göz korkutucu görünüyorsa endişelenmeyin! Graph Vakfı, işbirliğini teşvik edip, gerekli bilgileri sunar ve yönetişim süreçlerinde gezinmek, Graph İyileştirme Teklifleri (GIPs) ve pull requests de dahil olmak üzere çeşitli aşamalarda entegratörlere rehberlik ederek onları desteklemeye odaklanmıştır. Sorularınız varsa, lütfen [info@thegraph.foundation](mailto:info@thegraph.foundation) adresi veya Discord (Graph Vakfı üyesi Pedro, IndexerDAO veya diğer çekirdek geliştiricilerden birine) aracılığıyla bize ulaşın.
+
+Graph Ağı'nın geleceğini şekillendirmeye hazır mısınız? Şimdi [Teklifinizi başlatın] (https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) ve web3 devriminin bir parçası olun!
+
+---
+
+## Sıkça Sorulan Sorular
+
+### 1. Bunun [World of Data Services teklifi (GIP)] (https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761) ile ilişkisi nedir?
+
+Bu süreç Subgraph Veri Hizmeti ile ilgilidir ve yalnızca yeni Subgraph `Veri Kaynakları` için geçerlidir.
+
+### 2. Firehose & Substreams desteği, ağ ana ağda desteklendikten sonra gelirse ne olur?
+
+Bu, yalnızca Substreams destekli subgraphlar'da ödüllerin indekslenmesi için protokol desteğini etkileyecektir. Yeni Firehose uygulamasının, bu GIP'de Aşama 2 için özetlenen metodolojiyi izleyerek testnet üzerinde test edilmesi gerekecektir. Benzer şekilde, uygulamanın performanslı ve güvenilir olduğu varsayıldığı takdirde, [Özellik Destek Matrisi] (https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) üzerinde bir PR (`Substreams veri kaynakları` Subgraph Özelliği) ve ödüllerin indekslenmesi amacıyla protokol desteği için yeni bir GIP gerekecektir. PR ve GIP'yi herkes oluşturabilir; Vakıf, Konsey onayı konusunda yardımcı olacaktır.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+Ana ağa geçiş süresinin entegrasyon geliştirme süresine, ek araştırma gerekip gerekmediğine, test ve hata düzeltmelerine ve her zaman olduğu gibi topluluk geri bildirimi gerektiren yönetişim sürecinin zamanlamasına bağlı olarak değişmek kaydıyla birkaç hafta olması beklenmektedir.
+
+İndeksleme ödülleri için protokol desteği, paydaşların test etme, geri bildirim toplama ve varsa çekirdek kod tabanına katkıları ele alma konusundaki bant genişliğine bağlıdır. Bu, entegrasyonun olgunluğuna ve entegrasyon ekibinin ne kadar duyarlı olduğu (RPC/Firehose uygulamasının arkasındaki ekip olabilir veya olmayabilir) ile doğrudan ilişkilidir. Vakıf, sürecin tamamı boyunca destek sağlamak için buradadır.
+
+### 4. Öncelikler nasıl ele alınacak?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From b0b9aca2d7f717944d34ddbd7f358dd100bb88c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:30 -0500
Subject: [PATCH 1125/3820] New translations chain-integration-overview.mdx
 (Ukrainian)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/uk/indexing/chain-integration-overview.mdx

diff --git a/website/pages/uk/indexing/chain-integration-overview.mdx b/website/pages/uk/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..77141e82b34a
--- /dev/null
+++ b/website/pages/uk/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 30d5542fccfa028ba2bc15114cf8300ae7eb6af3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:31 -0500
Subject: [PATCH 1126/3820] New translations chain-integration-overview.mdx
 (Chinese Simplified)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/zh/indexing/chain-integration-overview.mdx

diff --git a/website/pages/zh/indexing/chain-integration-overview.mdx b/website/pages/zh/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..3caa15d11f90
--- /dev/null
+++ b/website/pages/zh/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: 链集成过程概述
+---
+
+为寻求与[The Graph协议集成](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468)的区块链团队设计了一个透明且基于治理的集成过程，总结如下，分为3个阶段。
+
+## 阶段1：技术集成
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- 团队通过在[here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71)（治理与GIPs下的新数据源子类别）创建一个论坛帖子来启动协议集成过程。强制使用默认的论坛模板。
+
+## 阶段2：集成验证
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph索引人在The Graph的测试网上测试集成。
+- 核心开发者和索引人监控稳定性、性能和数据确定性。
+
+## 阶段3：主网集成
+
+- 团队通过提交一个Graph Improvement Proposal (GIP) 并在 [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) 上发起一个拉取请求 (PR) 来提议主网集成（更多详细信息请查看链接）。
+- The Graph Council（The Graph理事会）审查请求，并在成功完成第2阶段并获得积极社区反馈的情况下批准主网支持。
+
+---
+
+如果整个流程看起来令人望而生畏，不用担心！The Graph Foundation致力于通过促进合作、提供重要信息并指导各个阶段的过程来支持集成者，包括引导他们参与治理流程，如Graph Improvement Proposals (GIPs) 和拉取请求。如果您有任何问题，请通过 [info@thegraph.foundation](mailto:info@thegraph.foundation) 或通过Discord（可以联系Pedro、The Graph Foundation成员、IndexerDAO或其他核心开发者）与我们联系。
+
+准备好塑造The Graph Network的未来了吗？[立即开始您的提案](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md)，成为Web3革命的一部分吧！
+
+---
+
+## 常见问题
+
+### 1.这与[数据服务全球改进提案](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)有何关联？
+
+这个过程与子图数据服务相关，仅适用于新的子图“数据源”。
+
+### 2. 如果在主网上支持网络之后再支持 Firehose 和 Substreams，会发生什么情况？
+
+这只会影响 Substreams 驱动的子图上的索引奖励的协议支持。新的 Firehose 实现需要在测试网上进行测试，遵循了本 GIP 中第二阶段所概述的方法论。同样地，假设实现是高性能且可靠的，那么需要在 [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) 上提出 PR（`Substreams 数据源` 子图特性），以及一个新的 GIP 来支持索引奖励的协议。任何人都可以创建这个 PR 和 GIP；基金会将协助获得理事会的批准。
+
+### 3. How much time will the process of reaching full protocol support take?
+
+主网上线预计还有数周时间，具体取决于集成开发的时间、是否需要额外的研究、测试和漏洞修复，以及始终如一地需要社区反馈的治理过程的时间。
+
+索引奖励的协议支持取决于利益相关者继续进行测试、收集反馈以及处理对核心代码库的贡献（如果适用）的带宽。这与集成的成熟程度以及集成团队的响应能力直接相关（可能是RPC/Firehose实施背后的团队，也可能不是）。基金会将在整个过程中提供支持。
+
+### 4. 如何处理优先事项？
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From fbc1d799d0d07320e1656764d655d58241cbacf2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:32 -0500
Subject: [PATCH 1127/3820] New translations chain-integration-overview.mdx
 (Urdu (Pakistan))

---
 .../indexing/chain-integration-overview.mdx   | 50 +++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 website/pages/ur/indexing/chain-integration-overview.mdx

diff --git a/website/pages/ur/indexing/chain-integration-overview.mdx b/website/pages/ur/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..f02f86479860
--- /dev/null
+++ b/website/pages/ur/indexing/chain-integration-overview.mdx
@@ -0,0 +1,50 @@
+---
+title: چین انٹیگریشن کے عمل کا جائزہ
+---
+
+ایک شفاف اور گورننس پر مبنی انٹیگریشن کا عمل بلاک چین ٹیموں کے لیے ڈیزائن کیا گیا تھا جو [ گراف پروٹوکول کے ساتھ انٹیگریشن] (https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468) کی تلاش میں تھے۔ یہ ایک 3 مرحلے کا عمل ہے، جیسا کہ ذیل میں خلاصہ کیا گیا ہے.
+
+## مرحلہ 1. تکنیکی انٹیگریشن
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- ٹیمیں فورم تھریڈ بنا کر پروٹوکول انٹیگریشن کا عمل شروع کرتی ہیں [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71)(گورننس اور GIPs کے تحت نئے ڈیٹا ذرائع ذیلی زمرہ)
+  ۔ پہلے سے طے شدہ فورم ٹیمپلیٹ کا استعمال لازمی ہے.
+
+## مرحلہ 2۔ انٹیگریشن کی توثیق
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- گراف انڈیکسرز گراف کے ٹیسٹ نیٹ پر انٹیگریشن کی جانچ کرتے ہیں.
+- کور ڈویلپرز اور انڈیکسرز استحکام، کارکردگی، اور ڈیٹا کے تعین کی نگرانی کرتے ہیں.
+
+## مرحلہ 3۔ مین نیٹ انٹیگریشن
+
+- ٹیمیں گراف میں بہتری کی تجویز (GIP) جمع کر کے اور [فیچر سپورٹ میٹرکس] (https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) پر پل کی درخواست (PR) شروع کرکے مین نیٹ انٹیگریشن کی تجویز پیش کرتی ہیں۔ (مزید تفصیلات لنک پر).
+- گراف کونسل درخواست کا جائزہ لیتی ہے اور مین نیٹ سپورٹ کو منظور کرتی ہے، ایک کامیاب مرحلہ 2 اور مثبت کمیونٹی فیڈ بیک فراہم کرتی ہے.
+
+---
+
+اگر عمل مشکل لگتا ہے، تو پریشان نہ ہوں! گراف فاؤنڈیشن تعاون کو فروغ دے کر، ضروری معلومات کی پیشکش کرکے، اور مختلف مراحل میں ان کی رہنمائی کرکے انٹیگریٹرز کی مدد کرنے کے لیے پرعزم ہے، بشمول گراف کی بہتری کی تجاویز (GIPs) اور پل کی درخواستوں جیسے گورننس کے عمل کو نیویگیٹ کرنا۔ اگر آپ کے سوالات ہیں، تو براہ کرم [info@thegraph.foundation](mailto:info@thegraph.foundation) یا ڈسکارڈ (یا تو Pedro، گراف فاؤنڈیشن کے رکن، انڈیکسرDAO، یا دیگر بنیادی ڈویلپرز) کے ذریعے رابطہ کریں.
+
+گراف نیٹ ورک کے مستقبل کی تشکیل کے لیے تیار ہیں؟ [اپنی تجویز شروع کریں](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) ابھی اور ویب 3 انقلاب کا حصہ بنیں!
+
+---
+
+## اکثر پوچھے گئے سوالات
+
+### 1. اس کا [ڈیٹا سروسز کی دنیا GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761) سے کیا تعلق ہے؟
+
+یہ عمل سب گراف ڈیٹا سروس سے متعلق ہے، جو صرف نئے سب گراف `ڈیٹا سورسز` پر لاگو ہوتا ہے.
+
+### 2. اگر مین نیٹ پر نیٹ ورک سپورٹ ہونے کے بعد فائر ہوز اور سب سٹریم سپورٹ آجائے تو کیا ہوگا؟
+
+یہ صرف سب سٹریمزسے چلنے والے سب گرافس پر انڈیکسنگ کے انعامات کے لیے پروٹوکول سپورٹ کو متاثر کرے گا۔ اس GIP میں اسٹیج 2 کے لیے بیان کردہ طریقہ کار کے بعد، نئے فائر ہوز کے نفاذ کو ٹیسٹ نیٹ پر جانچ کی ضرورت ہوگی۔ اسی طرح، یہ فرض کرتے ہوئے کہ نفاذ پرفارمنس اور قابل اعتماد ہے، [فیچر سپورٹ میٹرکس](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) پر ایک PR کی ضرورت ہوگی ( 'سب سٹریمز ڈیٹا سورسز' سب گراف فیچر)، نیز انڈیکسنگ انعامات کے لیے پروٹوکول سپورٹ کے لیے ایک نیا GIP۔ کوئی بھی PR اور GIP بنا سکتا ہے۔ فاؤنڈیشن کونسل کی منظوری میں مدد کرے گی.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+مین نیٹ کرنے کا وقت کئی ہفتوں کا متوقع ہے، انٹیگریشن کی ترقی کے وقت کی بنیاد پر مختلف ہوتا ہے، چاہے اضافی تحقیق کی ضرورت ہو، جانچ اور بگ فکسز، اور ہمیشہ کی طرح، گورننس کے عمل کا وقت جس کے لیے کمیونٹی فیڈ بیک کی ضرورت ہوتی ہے.
+
+انڈیکسنگ انعامات کے لیے پروٹوکول سپورٹ اسٹیک ہولڈرز کی بینڈوتھ پر منحصر ہے کہ اگر قابل اطلاق ہو تو بنیادی کوڈبیس میں ٹیسٹنگ، فیڈ بیک اکٹھا کرنے، اور تعاون کو سنبھالنے کے لیے۔ یہ براہ راست انٹیگریشن کی پختگی سے منسلک ہے اور انٹیگریشن کی ٹیم کتنی ذمہ دار ہے (جو RPC/فائر ہوز کے نفاذ کے پیچھے ٹیم ہوسکتی ہے یا نہیں)۔ فاؤنڈیشن پورے عمل میں مدد کے لیے حاضر ہے.
+
+### 4. ترجیحات کو کس طرح سنبھالا جائے گا؟
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 0ea404e30ddab568ec0bc9039664a6b2130f2aec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:33 -0500
Subject: [PATCH 1128/3820] New translations chain-integration-overview.mdx
 (Vietnamese)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/vi/indexing/chain-integration-overview.mdx

diff --git a/website/pages/vi/indexing/chain-integration-overview.mdx b/website/pages/vi/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..77141e82b34a
--- /dev/null
+++ b/website/pages/vi/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 171f6dc79bf4380d42eece94017e37fbd0ca5a1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:34 -0500
Subject: [PATCH 1129/3820] New translations chain-integration-overview.mdx
 (Marathi)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/mr/indexing/chain-integration-overview.mdx

diff --git a/website/pages/mr/indexing/chain-integration-overview.mdx b/website/pages/mr/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..77141e82b34a
--- /dev/null
+++ b/website/pages/mr/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From b666b9d19a44a0ea6341597ba4f6aa18ce06348c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:35 -0500
Subject: [PATCH 1130/3820] New translations chain-integration-overview.mdx
 (Hindi)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/hi/indexing/chain-integration-overview.mdx

diff --git a/website/pages/hi/indexing/chain-integration-overview.mdx b/website/pages/hi/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..5c770235ff7c
--- /dev/null
+++ b/website/pages/hi/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- टीमें ग्राफ फाउंडेशन और ग्राफिकल यूजर इंटरफेस (GUIs) और नेटवर्क गेटवे के संचालकों के साथ सहयोग करती हैं, जैसे कि [Subgraph Studio](https://thegraph.com/studio/)। इसमें आवश्यक बैकएंड इंफ्रास्ट्रक्चर प्रदान करने शामिल है, जैसे कि एकीकृत चेन के JSON RPC या Firehose एंडपॉइंट्स। ऐसे टीमें जो ऐसी इंफ्रास्ट्रक्चर का स्वयं होस्टिंग नहीं करना चाहती हैं, वे ग्राफ की नोड ऑपरेटर (Indexer) की समुदाय का उपयोग कर सकती हैं, जिसमें फाउंडेशन मदद कर सकता है।
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. पूर्ण प्रोटोकॉल समर्थन तक पहुंचने की प्रक्रिया में कितना समय लगेगा?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+\#3 के समान, यह समग्र तत्परता और शामिल हितधारकों की क्षमता पर निर्भर करेगा। उदाहरण के लिए, एक नए चेन के साथ एक नई Firehose कार्यान्वयन को उन एकीकरणों की तुलना में अधिक समय लग सकता है जो पहले से ही परीक्षण किए जा चुके हैं या जो शासन प्रक्रिया में आगे बढ़ चुके हैं।

From a1e1e8252a0d193c061abc3ca5c7bd1b0e92f68b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:36 -0500
Subject: [PATCH 1131/3820] New translations chain-integration-overview.mdx
 (Swahili)

---
 .../indexing/chain-integration-overview.mdx   | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 website/pages/sw/indexing/chain-integration-overview.mdx

diff --git a/website/pages/sw/indexing/chain-integration-overview.mdx b/website/pages/sw/indexing/chain-integration-overview.mdx
new file mode 100644
index 000000000000..77141e82b34a
--- /dev/null
+++ b/website/pages/sw/indexing/chain-integration-overview.mdx
@@ -0,0 +1,49 @@
+---
+title: Chain Integration Process Overview
+---
+
+A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+
+## Stage 1. Technical Integration
+
+- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+
+## Stage 2. Integration Validation
+
+- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Graph Indexers test the integration on The Graph's testnet.
+- Core developers and Indexers monitor stability, performance, and data determinism.
+
+## Stage 3. Mainnet Integration
+
+- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
+- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+
+---
+
+If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+
+Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+
+---
+
+## Frequently Asked Questions
+
+### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+
+This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+
+### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+
+This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+
+### 3. How much time will the process of reaching full protocol support take?
+
+The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+
+Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+
+### 4. How will priorities be handled?
+
+Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.

From 2f8e641e49b87db4d0a501197640ba59a8f2b54e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:37 -0500
Subject: [PATCH 1132/3820] New translations new-chain-integration.mdx
 (Romanian)

---
 .../ro/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ro/indexing/new-chain-integration.mdx

diff --git a/website/pages/ro/indexing/new-chain-integration.mdx b/website/pages/ro/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..695f07957a69
--- /dev/null
+++ b/website/pages/ro/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testing an EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From cc658509a11272ef7024a581158bb382d37c35a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:38 -0500
Subject: [PATCH 1133/3820] New translations new-chain-integration.mdx (French)

---
 .../fr/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/fr/indexing/new-chain-integration.mdx

diff --git a/website/pages/fr/indexing/new-chain-integration.mdx b/website/pages/fr/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..c1a8c1952bbb
--- /dev/null
+++ b/website/pages/fr/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Tester un EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Configuration Graph Node
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Créez un exemple de subgraph simple. Certaines options sont ci-dessous :
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node devrait synchroniser le subgraph déployé s'il n'y a pas d'erreurs. Laissez-lui le temps de se synchroniser, puis envoyez des requêtes GraphQL au point de terminaison de l'API indiqué dans les journaux.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From b56480e0009157f8e78748b10e5ef78b0dafb8c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:39 -0500
Subject: [PATCH 1134/3820] New translations new-chain-integration.mdx
 (Spanish)

---
 .../es/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/es/indexing/new-chain-integration.mdx

diff --git a/website/pages/es/indexing/new-chain-integration.mdx b/website/pages/es/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..4d4a51ff22b6
--- /dev/null
+++ b/website/pages/es/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Probando un EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, en una solicitud por lotes JSON-RPC
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Configuración del Graph Node
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Crea un subgrafo simple de prueba. Algunas opciones están a continuación:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node debería sincronizar el subgrafo implementado si no hay errores. Dale tiempo para que se sincronice y luego envíe algunas queries GraphQL al punto final de la API impreso en los registros.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From e7e72f9f9522d0e98bec88c5fabce6b0afcea464 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:41 -0500
Subject: [PATCH 1135/3820] New translations new-chain-integration.mdx (Arabic)

---
 .../ar/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ar/indexing/new-chain-integration.mdx

diff --git a/website/pages/ar/indexing/new-chain-integration.mdx b/website/pages/ar/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..c75ec800a485
--- /dev/null
+++ b/website/pages/ar/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### اختبار استدعاء إجراء عن بُعد باستخدام تمثيل كائنات جافا سكريبت لآلة الإيثريوم الافتراضية (EVM JSON-RPC)
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`، ضمن طلب دفعة استدعاء الإجراء عن بُعد باستخدام تمثيل كائنات جافا سكريبت
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## تكوين عقدة الغراف
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [استنسخ عقدة الغراف](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. قم بإنشاء مثالًا بسيطًا للغراف الفرعي. بعض الخيارات المتاحة هي كالتالي:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+إذا لم تكن هناك أخطاء يجب أن يقوم عقدة الغراف بمزامنة الغراف الفرعي المنشور. قم بمنحه بعض الوقت لإتمام عملية المزامنة، ثم قم بإرسال بعض استعلامات لغة الإستعلام للغراف (GraphQL) إلى نقطة نهاية واجهة برمجة التطبيقات الموجودة في السجلات.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From e65040b4556c02aeed5c939f26f726656f984669 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:41 -0500
Subject: [PATCH 1136/3820] New translations new-chain-integration.mdx (Czech)

---
 .../cs/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/cs/indexing/new-chain-integration.mdx

diff --git a/website/pages/cs/indexing/new-chain-integration.mdx b/website/pages/cs/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..b5a8b76ebf06
--- /dev/null
+++ b/website/pages/cs/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testování EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Config uzlu grafu
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Vytvořte jednoduchý příklad podgrafu. Některé možnosti jsou uvedeny níže:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Pokud nedošlo k chybám, měl by uzel Graf synchronizovat nasazený podgraf. Dejte mu čas na synchronizaci a poté odešlete několik dotazů GraphQL na koncový bod API vypsaný v protokolech.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 0a3cf3202b8309107ff358feda17ffc9e438a289 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:42 -0500
Subject: [PATCH 1137/3820] New translations new-chain-integration.mdx (German)

---
 .../de/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/de/indexing/new-chain-integration.mdx

diff --git a/website/pages/de/indexing/new-chain-integration.mdx b/website/pages/de/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..695f07957a69
--- /dev/null
+++ b/website/pages/de/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testing an EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 299b898399143937f034e9ad234169d8d58c0e6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:44 -0500
Subject: [PATCH 1138/3820] New translations new-chain-integration.mdx
 (Italian)

---
 .../it/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/it/indexing/new-chain-integration.mdx

diff --git a/website/pages/it/indexing/new-chain-integration.mdx b/website/pages/it/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..695f07957a69
--- /dev/null
+++ b/website/pages/it/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testing an EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From a480a6d73fed27ecbf97184965da0403c98bdbca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:45 -0500
Subject: [PATCH 1139/3820] New translations new-chain-integration.mdx
 (Japanese)

---
 .../ja/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ja/indexing/new-chain-integration.mdx

diff --git a/website/pages/ja/indexing/new-chain-integration.mdx b/website/pages/ja/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..d53ed7dd1147
--- /dev/null
+++ b/website/pages/ja/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### EVM JSON-RPC のテスト
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node の設定
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. 簡単なサブグラフの例を作成します。 いくつかのオプションを以下に示します。
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Nodeはエラーがない場合、デプロイされたサブグラフを同期するはずです。同期が完了するのを待ってから、ログに表示されたAPIエンドポイントに対していくつかのGraphQLクエリを送信してください。
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From ca556cf0625e5e5276cff70552c53d590e87b830 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:46 -0500
Subject: [PATCH 1140/3820] New translations new-chain-integration.mdx (Korean)

---
 .../ko/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ko/indexing/new-chain-integration.mdx

diff --git a/website/pages/ko/indexing/new-chain-integration.mdx b/website/pages/ko/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..695f07957a69
--- /dev/null
+++ b/website/pages/ko/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testing an EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 10b56bcf9851054f3fc1020aa26a72b8b3af7500 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:47 -0500
Subject: [PATCH 1141/3820] New translations new-chain-integration.mdx (Dutch)

---
 .../nl/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/nl/indexing/new-chain-integration.mdx

diff --git a/website/pages/nl/indexing/new-chain-integration.mdx b/website/pages/nl/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..695f07957a69
--- /dev/null
+++ b/website/pages/nl/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testing an EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 11ea8e5a7458a4a1bbd84001be7c4c0c97c41377 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:48 -0500
Subject: [PATCH 1142/3820] New translations new-chain-integration.mdx (Polish)

---
 .../pl/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/pl/indexing/new-chain-integration.mdx

diff --git a/website/pages/pl/indexing/new-chain-integration.mdx b/website/pages/pl/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..695f07957a69
--- /dev/null
+++ b/website/pages/pl/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testing an EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 262fd296dd0311f877b7b380e86240879d6a1557 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:49 -0500
Subject: [PATCH 1143/3820] New translations new-chain-integration.mdx
 (Portuguese)

---
 .../pt/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/pt/indexing/new-chain-integration.mdx

diff --git a/website/pages/pt/indexing/new-chain-integration.mdx b/website/pages/pt/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..2d86905acd7f
--- /dev/null
+++ b/website/pages/pt/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: Integração de Chains Novas
+---
+
+Chains podem trazer apoio a subgraphs para os seus ecossistemas ao iniciar uma nova integração de `graph-node`. Subgraphs são ferramentas poderosas de indexação que abrem infinitas possibilidades a programadores. O Graph Node já indexa dados das chains listadas aqui. Caso tenha interesse numa nova integração, há 2 estratégias para ela:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: Todas as soluções de integração do Firehose incluem Substreams, um motor de transmissão de grande escala com base no Firehose com apoio nativo ao `graph-node`, o que permite transformações paralelizadas.
+
+> Note que enquanto a abordagem recomendada é o desenvolvimento de um novo Firehose para todas as chains novas, ele só é requerido para chains que não sejam EVMs.
+
+## Estratégias de Integração
+
+### 1. EVM JSON-RPC
+
+Se a blockchain for equivalente a EVM e o cliente/node expor a API padrão de JSON-RPC, o Graph Node deve poder indexar a nova chain.
+
+#### Como testar uma EVM JSON-RPC
+
+Para que o Graph Node possa ingerir dados de uma chain EVM, o node RPC deve expor os seguintes métodos em EVM JSON-RPC:
+
+- `eth_getLogs`
+- `eth_call` (para blocos históricos, com EIP-1898 - requer node de arquivo)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, em um pedido conjunto em JSON-RPC
+- `trace_filter` (opcional, para que o Graph Node tenha apoio a handlers de chamada)\*
+
+### 2. Integração do Firehose
+
+O [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) é uma camada de extração de última geração, que coleta históricos em streams e arquivos planos em tempo real. A tecnologia do Firehose substitui estas chamadas de API com um fluxo de dados que utilizam um modelo de empurrão que envia dados ao node de indexação mais rapidamente. Isto ajuda a aumentar a velocidade da sincronização e da indexação.
+
+O método principal de integrar o Firehose a chains é uma estratégia de polling de RPC. O nosso algoritmo de polling preverá quando um bloco novo irá chegar, e aumentará o ritmo em que ele verifica por um novo bloco quando se aproximar daquela hora, o que o faz uma solução de baixa latência muito eficiente. Para ajuda com a integração e a manutenção do Firehose, contacte a [equipa do StreamingFast](https://www.streamingfast.io/firehose-integration-program). Novas chains e os seus integrantes apreciarão a [consciência de fork](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) e as capacidades imensas de indexação paralelizada que o Firehose e os Substreams trazem ao seu ecossistema.
+
+> NOTA: Todas as integrações feitas pela equipa da StreamingFast incluem manutenção para o protocolo de réplica do Firehose no banco de código da chain. O StreamingFast rastreia todas as mudanças e lança binários quando o código é mudado, pelo programador ou pela StreamingFast. Isto inclui o lançamento de binários do Firehose/Substreams para o protocolo, a manutenção dos módulos de Substreams para o modelo de bloco da chain, e o lançamento de binários para o node da blockchain com a instrumentação, caso necessária.
+
+#### Instrumentação Específica do Firehose para chains EVM (`geth`)
+
+Para chains EVM, há um nível mais profundo de dados que podem ser alcançados através do [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0) `geth`, uma colaboração entre a Go-Ethereum e a StreamingFast, na construção de um sistema de traços rico e de alto throughput. O Live Tracer é a solução mais compreensiva, o que resulta em detalhes de blocos [Estendidos](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425). Isto permite novos paradigmas de indexação, como correspondência de padrões de eventos com base em mudanças no estado, chamadas, árvores de chamadas de parentes, ou o acionamento de eventos com base nas mudanças nas próprias variáveis em um contrato inteligente.
+
+![Bloco base x bloco Estendido](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTA: Esta melhoria no Firehose requer que chains usem o motor de EVM na `versão geth 1.13.0` adiante.
+
+## Considerações de EVM - Diferença entre JSON-RPC e Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- Todas essas chamadas `getLogs` e roundtrips são substituídas por um único fluxo que chega no coração do `graph-node`, um modelo de bloco único para todos os subgraphs que processa.
+
+> NOTA: Uma integração baseada no Firehose para chains EVM ainda exigirá que os Indexadores executem o node RPC de arquivo da chain para indexar subgraphs corretamente. Isto é porque o Firehose não pode fornecer estados de contratos inteligentes que são tipicamente acessíveis pelo método RPC  `eth_call` . (Vale lembrar que eth_calls não são uma boa prática para programadores)
+
+## Como Configurar um Graph Node
+
+Configurar um Graph Node é tão fácil quanto preparar o seu ambiente local. Quando o seu ambiente local estiver pronto, será possível testar a integração com a edição local de um subgraph.
+
+1. [Clone o Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modifique [esta linha](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) para ela incluir o nome da nova rede e a URL do EVM JSON-RPC
+
+   > Não mude o nome do env var. Ele deve permanecer como `ethereum` mesmo se o nome da rede for diferente.
+
+3. Execute um node IPFS ou use aquele usado pelo The Graph: https://api.thegraph.com/ipfs/
+
+### Como testar um JSON-RPC com a edição local de um subgraph
+
+1. Instale a [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Crie um subgraph de exemplo simples. Aqui estão algumas opções:
+   1. O contrato inteligente e o subgraph [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) pré-inclusos são bons pontos de partida
+   2. Inicie um subgraph local a partir de qualquer contrato inteligente existente ou de um ambiente de programação em solidity [com o uso do Hardhat com um plugin do Graph](https://github.com/graphprotocol/hardhat-graph)
+3. Adapte o `subgraph.yaml` resultante com a mudança do  `dataSources.network` para o mesmo nome passado anteriormente ao Graph Node.
+4. Crie o seu subgraph no Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Edite o seu subgraph no Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+O Graph Node deve então sincronizar o subgraph lançado caso não haja erros. Deixe-o sincronizar por um tempo, e depois envie alguns queries em GraphQL ao endpoint da API produzido pelos logs.
+
+## Subgraphs movidos por Substreams
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 45a440979df53facedef2aa6f57022184735a5a2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:50 -0500
Subject: [PATCH 1144/3820] New translations new-chain-integration.mdx
 (Russian)

---
 .../ru/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ru/indexing/new-chain-integration.mdx

diff --git a/website/pages/ru/indexing/new-chain-integration.mdx b/website/pages/ru/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..695f07957a69
--- /dev/null
+++ b/website/pages/ru/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testing an EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 597d40adbd64f8cbce374a18e7b469b5e10c6af6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:51 -0500
Subject: [PATCH 1145/3820] New translations new-chain-integration.mdx
 (Swedish)

---
 .../sv/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/sv/indexing/new-chain-integration.mdx

diff --git a/website/pages/sv/indexing/new-chain-integration.mdx b/website/pages/sv/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..9e35237d4922
--- /dev/null
+++ b/website/pages/sv/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testa en EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, i en JSON-RPC batch-begäran
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graf Node-konfiguration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Klona Graf Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Skapa en enkel exempelsubgraf. Några alternativ är nedan:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graf Node bör synkronisera den distribuerade subgrafen om det inte finns några fel. Ge det tid att synkronisera, och skicka sedan några GraphQL-begäranden till API-slutpunkten som skrivs ut i loggarna.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 8ddf48aeb90bec013d84eda9387fb3485811f7a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:52 -0500
Subject: [PATCH 1146/3820] New translations new-chain-integration.mdx
 (Turkish)

---
 .../tr/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/tr/indexing/new-chain-integration.mdx

diff --git a/website/pages/tr/indexing/new-chain-integration.mdx b/website/pages/tr/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..1fff8115bab0
--- /dev/null
+++ b/website/pages/tr/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### EVM JSON-RPC'yi test etme
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, bir JSON-RPC toplu talebinde
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Graph Düğümü'nü Klonlayın](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Basit bir örnek subgraph oluşturun. Bazı seçenekler aşağıdadır:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Herhangi bir hata olmadığı takdirde Graph Düğü'mü dağıtılan subgraph'ı senkronize ediyor olmalıdır. Senkronizasyon için zaman tanıyın, ardından kayıtlarla yazdırılan API uç noktasına bazı GraphQL sorguları gönderin.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 41ade50988b1ae701979faddc72030115c38b26f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:53 -0500
Subject: [PATCH 1147/3820] New translations new-chain-integration.mdx
 (Ukrainian)

---
 .../uk/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/uk/indexing/new-chain-integration.mdx

diff --git a/website/pages/uk/indexing/new-chain-integration.mdx b/website/pages/uk/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..695f07957a69
--- /dev/null
+++ b/website/pages/uk/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testing an EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 5586e6fa1286b0de8c9e5b66173edd840918ea49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:54 -0500
Subject: [PATCH 1148/3820] New translations new-chain-integration.mdx (Chinese
 Simplified)

---
 .../zh/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/zh/indexing/new-chain-integration.mdx

diff --git a/website/pages/zh/indexing/new-chain-integration.mdx b/website/pages/zh/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..c900f4b153df
--- /dev/null
+++ b/website/pages/zh/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### 测试EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, 在JSON-RPC批量请求中
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node配置
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. 创建一个简单的示例子图。以下是一些选项：
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+如果没有错误，Graph Node应该正在同步部署的子图。给它一些时间来同步，然后向API端点发送一些GraphQL查询。
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 0023c5f763b9848ddec6a5bcbe04e4c716c4ea49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:55 -0500
Subject: [PATCH 1149/3820] New translations new-chain-integration.mdx (Urdu
 (Pakistan))

---
 .../ur/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/ur/indexing/new-chain-integration.mdx

diff --git a/website/pages/ur/indexing/new-chain-integration.mdx b/website/pages/ur/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..f92f8ce2a25f
--- /dev/null
+++ b/website/pages/ur/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### EVM JSON-RPC کی ٹیسٹ کرنا
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## گراف نوڈ کنفگریشن
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [گراف نوڈ کی نقل بنائیں](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. ایک سادہ مثالی سب گراف بنائیں۔ کچھ آپشنز ذیل میں ہیں:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+اگر کوئی خرابی نہیں ہے تو گراف نوڈ کو تعینات سب گراف کو ہم آہنگ کرنا چاہیے۔ اسے مطابقت پذیری کے لیے وقت دیں، پھر لاگز میں پرنٹ کردہ API اینڈ پوائنٹ پر کچھ GraphQL کیوریز بھیجیں۔
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 450f305304a8aa1039231eb28f3b4ad677f1963b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:56 -0500
Subject: [PATCH 1150/3820] New translations new-chain-integration.mdx
 (Vietnamese)

---
 .../vi/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/vi/indexing/new-chain-integration.mdx

diff --git a/website/pages/vi/indexing/new-chain-integration.mdx b/website/pages/vi/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..695f07957a69
--- /dev/null
+++ b/website/pages/vi/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testing an EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From e88296ebd13a3ba6dcfffd7f7d016a1c2805af2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:57 -0500
Subject: [PATCH 1151/3820] New translations new-chain-integration.mdx
 (Marathi)

---
 .../mr/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/mr/indexing/new-chain-integration.mdx

diff --git a/website/pages/mr/indexing/new-chain-integration.mdx b/website/pages/mr/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..695f07957a69
--- /dev/null
+++ b/website/pages/mr/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testing an EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From c6a457d67a9835058bd30770c7ff84ac3f21e618 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:58 -0500
Subject: [PATCH 1152/3820] New translations new-chain-integration.mdx (Hindi)

---
 .../hi/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/hi/indexing/new-chain-integration.mdx

diff --git a/website/pages/hi/indexing/new-chain-integration.mdx b/website/pages/hi/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..411961c10f5d
--- /dev/null
+++ b/website/pages/hi/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: नई श्रृंखला एकीकरण
+---
+
+चेन अपने पारिस्थितिकी तंत्र में सबग्राफ़ समर्थन लाने के लिए एक नया `graph-node` एकीकरण शुरू कर सकती हैं। सबग्राफ़ एक शक्तिशाली इंडेक्सिंग उपकरण हैं, जो डेवलपर्स के लिए संभावनाओं की एक नई दुनिया खोलते हैं। ग्राफ़ नोड पहले से ही यहाँ सूचीबद्ध चेन से डेटा को इंडेक्स करता है। यदि आप नए एकीकरण में रुचि रखते हैं, तो दो एकीकरण रणनीतियाँ हैं:
+
+1. EVM JSON-RPC
+2. Firehose: सभी Firehose एकीकरण समाधान में Substreams शामिल हैं, जो Firehose पर आधारित एक बड़े पैमाने पर स्ट्रीमिंग इंजन है, जिसमें स्वदेशी `graph-node` समर्थन है, जो समानांतर रूपांतरण की अनुमति देता है।
+
+> ध्यान दें कि जबकि अनुशंसित तरीका सभी नए चेन के लिए एक नया Firehose विकसित करना है, यह केवल गैर-EVM चेन के लिए आवश्यक है।
+
+## एकीकरण रणनीतियाँ
+
+### 1. EVM JSON-RPC
+
+यदि ब्लॉकचेन EVM समान है और क्लाइंट/नोड मानक EVM JSON-RPC API को एक्सपोज़ करता है, तो Graph Node को नए चेन को इंडेक्स करने में सक्षम होना चाहिए।
+
+#### Testing an EVM JSON-RPC
+
+Graph Node को EVM चेन से डेटा इन्गेस्ट करने के लिए, RPC नोड को निम्नलिखित EVM JSON-RPC विधियों को एक्सपोज़ करना होगा:
+
+- `eth_getLogs`
+- eth_call (ऐतिहासिक ब्लॉक्स के लिए, EIP-1898 के साथ - आर्काइव नोड की आवश्यकता)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- trace_filter (वैकल्पिक रूप से Graph Node को कॉल हैंडलर्स का समर्थन करने के लिए आवश्यक)
+
+### 2. Firehose एकीकरण
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) एक अगली पीढ़ी की निष्कर्षण परत है। यह फ्लैट फ़ाइलों में इतिहास एकत्र करता है और वास्तविक समय में स्ट्रीम करता है। Firehose तकनीक उन पॉलिंग API कॉल्स को एक डेटा स्ट्रीम से बदल देती है, जो एक पुश मॉडल का उपयोग करती है, जिससे डेटा को इंडेक्सिंग नोड तक तेजी से भेजा जा सके। यह सिंकिंग और इंडेक्सिंग की गति बढ़ाने में मदद करता है।
+
+फायरहोज़ को चेन में एकीकृत करने का प्राथमिक तरीका RPC पॉलिंग रणनीति का उपयोग करना है। हमारी पॉलिंग एल्गोरिदम नए ब्लॉक के आने का पूर्वानुमान लगाएगी और उस समय के करीब नए ब्लॉक के लिए जाँच करने की दर बढ़ा देगी, जिससे यह एक बहुत कम लेटेंसी और प्रभावी समाधान बन जाता है। फायरहोज़ के एकीकरण और रखरखाव में मदद के लिए, [स्ट्रीमिंगफास्ट टीम](https://www.streamingfast.io/firehose-integration-program) से संपर्क करें। नए चेन और उनके एकीकृतकर्ताओं को फायरहोज़ और सबस्ट्रीम द्वारा उनके पारिस्थितिकी तंत्र में लाए गए [फोर्क जागरूकता](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) और विशाल समानांतर इंडेक्सिंग क्षमताओं की सराहना होगी।
+
+> नोट: StreamingFast टीम द्वारा की गई सभी एकीकरणों में श्रृंखला के कोडबेस में Firehose प्रतिकृति प्रोटोकॉल के लिए रखरखाव शामिल है।StreamingFast किसी भी परिवर्तन को ट्रैक करता है और जब आप कोड बदलते हैं और जब StreamingFastकोड बदलता है, तो बाइनरी जारी करता है। इसमें प्रोटोकॉल के लिए Firehose/Substreamsबाइनरी जारी करना, श्रृंखला के ब्लॉक मॉडल के लिए Substreamsमॉड्यूल को बनाए रखना, और आवश्यकता होने पर ब्लॉकचेन नोड के लिए इंस्ट्रुमेंटेशन के साथ बाइनरी जारी करना शामिल है।
+
+#### ईवीएम (`geth`) चेन के लिए विशिष्ट फायरहोज़ इंस्ट्रूमेंटेशन
+
+EVM चेन के लिए, एक गहरे स्तर के डेटा को प्राप्त करने के लिए `geth` [लाइव-ट्रेसर](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0) का उपयोग किया जाता है, जो गो-एथेरियम और स्ट्रीमिंगफास्ट के बीच सहयोग है, जो उच्च थ्रूपुट और समृद्ध लेनदेन ट्रेसिंग प्रणाली बनाने के लिए है। लाइव ट्रेसर सबसे व्यापक समाधान है, जो [विस्तारित](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) ब्लॉक विवरण का परिणाम है। यह नए इंडेक्सिंग पैरेडाइम्स की अनुमति देता है, जैसे राज्य परिवर्तनों, कॉल्स, पैरेंट कॉल ट्रीज़ के आधार पर घटनाओं का पैटर्न मिलाना, या स्मार्ट कॉन्ट्रैक्ट में वास्तविक वेरिएबल्स में बदलाव के आधार पर घटनाओं को ट्रिगर करना।
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> नोट: Firehose में यह सुधार तब आवश्यक है जब चेन EVM इंजन `geth संस्करण 1.13.0` और उससे ऊपर का उपयोग करें।
+
+## EVM विचार - JSON-RPC और Firehose के बीच का अंतर
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- सभी `getLogs` कॉल्स और राउंडट्रिप्स को एकल स्ट्रीम द्वारा प्रतिस्थापित किया जाता है, जो सीधे `graph-node` के केंद्र में पहुंचती है; यह एकल ब्लॉक मॉडल सभी सबग्राफ्स के लिए काम करता है जिन्हें यह प्रोसेस करता है।
+
+> **NOTE**: EVM chains के लिए Firehose-based integration के लिए अभी भी Indexers को chain के संग्रह RPC node को subgraph को ठीक से index करने के लिए चलाने की आवश्यकता होगी। यह `eth_call` RPC विधि द्वारा आम तौर पर पहुंच योग्य smart contract स्थिति प्रदान करने में Firehosesकी असमर्थता के कारण है। (It's worth reminding that eth_calls are [not a good practice for developers](/))
+
+## Graph Node Configuration
+
+ग्राफ नोड को कॉन्फ़िगर करना आपके स्थानीय वातावरण को तैयार करने के समान आसान है। एक बार जब आपका स्थानीय वातावरण सेट हो जाता है, तो आप एक उपग्राफ को स्थानीय रूप से डिप्लॉय करके एकीकरण का परीक्षण कर सकते हैं।
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. नए network नाम और EVM JSON RPC अनुरूप URL को शामिल करने के लिए [this line] (https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) को संशोधित करें
+
+   > कृपया पर्यावरण चर ethereum को खुद नाम में बदलें नहीं। यही रहना चाहिए, चाहे network का नाम भिन्न हो।
+
+3. एक IPFS node चलाएं या उसे The Graph द्वारा उपयोग किया जाने वाले node का उपयोग करें: https://api.thegraph.com/ipfs/
+
+### EVM JSON-RPC का परीक्षण करने के लिए स्थानीय रूप से एक Subgraph तैनात करना
+
+1. [graph-cli] स्थापित करें(https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. Pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract और subgraph एक अच्छा शुरुआती बिंदु है
+   2. किसी भी मौजूदा smart contract या solidity dev वातावरण से एक local subgraph को Bootstrap करें [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. परिणामी `subgraph.yaml` को [`dataSources.network`](http://dataSources.network) को उसी नाम में बदलकर अनुकूलित करें जो पहले Graph Node पर दिया गया था।
+4. अपने subgraph को Graph Node में बनाएँ: graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT
+5. अपने 'subgraph' को Graph Node पर प्रकाशित करें: graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## सबस्ट्रीम-संचालित सबग्राफ की सेवा
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From fd0d01c6e180578b3e70c4761046165a5cc91774 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:04:59 -0500
Subject: [PATCH 1153/3820] New translations new-chain-integration.mdx
 (Swahili)

---
 .../sw/indexing/new-chain-integration.mdx     | 80 +++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 website/pages/sw/indexing/new-chain-integration.mdx

diff --git a/website/pages/sw/indexing/new-chain-integration.mdx b/website/pages/sw/indexing/new-chain-integration.mdx
new file mode 100644
index 000000000000..695f07957a69
--- /dev/null
+++ b/website/pages/sw/indexing/new-chain-integration.mdx
@@ -0,0 +1,80 @@
+---
+title: New Chain Integration
+---
+
+Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+
+1. **EVM JSON-RPC**
+2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+
+> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+
+## Integration Strategies
+
+### 1. EVM JSON-RPC
+
+If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+
+#### Testing an EVM JSON-RPC
+
+For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+
+- `eth_getLogs`
+- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_getBlockByNumber`
+- `eth_getBlockByHash`
+- `net_version`
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+
+### 2. Firehose Integration
+
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+
+#### Specific Firehose Instrumentation for EVM (`geth`) chains
+
+For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+
+![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+
+> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+
+## EVM considerations - Difference between JSON-RPC & Firehose
+
+While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+
+- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+
+> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+
+## Graph Node Configuration
+
+Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+
+   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+
+3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+
+### Testing an EVM JSON-RPC by locally deploying a subgraph
+
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Create a simple example subgraph. Some options are below:
+   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
+   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
+3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
+4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+
+Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+
+## Substreams-powered Subgraphs
+
+For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 495ce42c6f666618549759633af57ee920858a7c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:00 -0500
Subject: [PATCH 1154/3820] New translations supported-network-requirements.mdx
 (Romanian)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/ro/indexing/supported-network-requirements.mdx

diff --git a/website/pages/ro/indexing/supported-network-requirements.mdx b/website/pages/ro/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..afbf755c0a5a
--- /dev/null
+++ b/website/pages/ro/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 083a51c7a379ffc1b9951d10b6e6c121ad37159e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:01 -0500
Subject: [PATCH 1155/3820] New translations supported-network-requirements.mdx
 (French)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/fr/indexing/supported-network-requirements.mdx

diff --git a/website/pages/fr/indexing/supported-network-requirements.mdx b/website/pages/fr/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..8df2bb4bc660
--- /dev/null
+++ b/website/pages/fr/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Réseau    | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 2c01ea3c0c88b632e30cb38387d2b7b417e205a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:02 -0500
Subject: [PATCH 1156/3820] New translations supported-network-requirements.mdx
 (Spanish)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/es/indexing/supported-network-requirements.mdx

diff --git a/website/pages/es/indexing/supported-network-requirements.mdx b/website/pages/es/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..c06461d981d6
--- /dev/null
+++ b/website/pages/es/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Red       | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 5c87ba3e897dde7a935ad07a54c7c72f3141a3e2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:03 -0500
Subject: [PATCH 1157/3820] New translations supported-network-requirements.mdx
 (Arabic)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/ar/indexing/supported-network-requirements.mdx

diff --git a/website/pages/ar/indexing/supported-network-requirements.mdx b/website/pages/ar/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..811fb2a8cec7
--- /dev/null
+++ b/website/pages/ar/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| بوليجون   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From d725de87a14b75b2ac6ea7e02d0887247deff2f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:05 -0500
Subject: [PATCH 1158/3820] New translations supported-network-requirements.mdx
 (Czech)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/cs/indexing/supported-network-requirements.mdx

diff --git a/website/pages/cs/indexing/supported-network-requirements.mdx b/website/pages/cs/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..efbee1c17750
--- /dev/null
+++ b/website/pages/cs/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Síť       | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 741510c7d35da42300c7a42ec3149c420169a681 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:06 -0500
Subject: [PATCH 1159/3820] New translations supported-network-requirements.mdx
 (German)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/de/indexing/supported-network-requirements.mdx

diff --git a/website/pages/de/indexing/supported-network-requirements.mdx b/website/pages/de/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..afbf755c0a5a
--- /dev/null
+++ b/website/pages/de/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From a296fbc5b936386611648e5534973672778726a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:07 -0500
Subject: [PATCH 1160/3820] New translations supported-network-requirements.mdx
 (Italian)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/it/indexing/supported-network-requirements.mdx

diff --git a/website/pages/it/indexing/supported-network-requirements.mdx b/website/pages/it/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..88be77e74cc8
--- /dev/null
+++ b/website/pages/it/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| La rete   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 0bd947fae821e1d7349cfb0c523207843b2d9e55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:08 -0500
Subject: [PATCH 1161/3820] New translations supported-network-requirements.mdx
 (Japanese)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/ja/indexing/supported-network-requirements.mdx

diff --git a/website/pages/ja/indexing/supported-network-requirements.mdx b/website/pages/ja/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..99ceda419e06
--- /dev/null
+++ b/website/pages/ja/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| ネットワーク    | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 43c58b78c3e68ba96612b774bc2f941bd8c7ba35 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:09 -0500
Subject: [PATCH 1162/3820] New translations supported-network-requirements.mdx
 (Korean)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/ko/indexing/supported-network-requirements.mdx

diff --git a/website/pages/ko/indexing/supported-network-requirements.mdx b/website/pages/ko/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..afbf755c0a5a
--- /dev/null
+++ b/website/pages/ko/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 6f638cc99e41e06f51ec15069fc00073db618712 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:10 -0500
Subject: [PATCH 1163/3820] New translations supported-network-requirements.mdx
 (Dutch)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/nl/indexing/supported-network-requirements.mdx

diff --git a/website/pages/nl/indexing/supported-network-requirements.mdx b/website/pages/nl/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..4a5d2fa8f364
--- /dev/null
+++ b/website/pages/nl/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Netwerk   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 9a159a46a0eef943e2e2182f800243ca7d66ac32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:11 -0500
Subject: [PATCH 1164/3820] New translations supported-network-requirements.mdx
 (Polish)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/pl/indexing/supported-network-requirements.mdx

diff --git a/website/pages/pl/indexing/supported-network-requirements.mdx b/website/pages/pl/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..afbf755c0a5a
--- /dev/null
+++ b/website/pages/pl/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From e057d0f5fac11ef40c73c89778ab97c030f34834 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:12 -0500
Subject: [PATCH 1165/3820] New translations supported-network-requirements.mdx
 (Portuguese)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/pt/indexing/supported-network-requirements.mdx

diff --git a/website/pages/pt/indexing/supported-network-requirements.mdx b/website/pages/pt/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..c1bd4433f1d7
--- /dev/null
+++ b/website/pages/pt/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Requisitos de Redes Apoiadas
+---
+
+| Rede      | Guias                                                                                                                                                                                                                                                                                            | Requisitos de sistema                                                                                                                                                | Recompensas de Indexação |
+| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------: |
+| Arbitrum  | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Guia Docker](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                | CPU de 4+ núcleos<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= SSD NVMe com mais de 8 TiB<br /> _última atualização em agosto de 2023_                                |             ✅            |
+| Avalanche | [Guia Docker](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                      | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> SSD NVMe com mais de 5 TiB<br /> _última atualização em agosto de 2023_                        |             ✅            |
+| Base      | [Guia Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [Guia GETH Baremetal](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [Guia GETH Docker](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | CPU de 8+ núcleos<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> mais 4.5TB (NVMe preferido)<br /> _última atualização em 14 de maio de 2024_                    |             ✅            |
+| Binance   | [Guia Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                    | CPU de 8 núcleos e 16 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> NVMe SSD com mais de 14 TiB<br /> _última atualização em 22 de junho de 2024_                 |             ✅            |
+| Celo      | [Guia Docker](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                           | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= SSD NVMe com mais de 2 TiB<br /> _última atualização em agosto de 2023_                     |             ✅            |
+| Ethereum  | [Guia Docker](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                | Frequência de clock maior que número de núcleos<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> Mais de 3TB (NVMe recomendado)<br /> _última atualização em agosto de 2023_ |             ✅            |
+| Fantom    | [Guia Docker](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                         | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> SSD NVMe com mais de 13 TiB<br /> _última atualização em agosto de 2023_                       |             ✅            |
+| Gnosis    | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                            | CPU de 6 núcleos e 12 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> NVMe SSD com mais de 3 TiB<br /> _última atualização em agosto de 2023_                       |             ✅            |
+| Linea     | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                    | CPU de 4+ núcleos<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= SSD NVMe com mais de 1 TiB<br /> _última atualização em 2 de abril de 2024_                            |             ✅            |
+| Optimism  | [Guia Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [Guia GETH Baremetal](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [Guia GETH Docker](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | CPU de 4 núcleos e 8 threads<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> SSD NVMe com mais de 8 TiB<br /> _última atualização em agosto de 2023_                        |             ✅            |
+| Polygon   | [Guia Docker](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                        | CPU de 16 núcleos<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= SSD NVMe com mais de 10 TiB<br /> _última atualização em agosto de 2023_                               |             ✅            |
+| Scroll    | [Guia Baremetal](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Guia Docker](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                    | CPU de 4 núcleos e 8 threads<br /> Debian 12<br /> 16GB+ RAM<br /> SSD NVMe com mais de 1 TiB<br /> _última atualização em 3 de abril de 2024_                       |             ✅            |

From 295c89957cc61b53df8ab330841fe8237495efac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:13 -0500
Subject: [PATCH 1166/3820] New translations supported-network-requirements.mdx
 (Russian)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/ru/indexing/supported-network-requirements.mdx

diff --git a/website/pages/ru/indexing/supported-network-requirements.mdx b/website/pages/ru/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..21a6f62ebb20
--- /dev/null
+++ b/website/pages/ru/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Сеть      | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Арбитрум  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 72b50131ecbc493252d35bfd75c09fe0420ad7ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:14 -0500
Subject: [PATCH 1167/3820] New translations supported-network-requirements.mdx
 (Swedish)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/sv/indexing/supported-network-requirements.mdx

diff --git a/website/pages/sv/indexing/supported-network-requirements.mdx b/website/pages/sv/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..f6c91108bac9
--- /dev/null
+++ b/website/pages/sv/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Nätverk   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From c03b954fbb0ffc4c3cf3db559521e50ee63ee39f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:15 -0500
Subject: [PATCH 1168/3820] New translations supported-network-requirements.mdx
 (Turkish)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/tr/indexing/supported-network-requirements.mdx

diff --git a/website/pages/tr/indexing/supported-network-requirements.mdx b/website/pages/tr/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..73adcca0dded
--- /dev/null
+++ b/website/pages/tr/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Ağ        | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 5b0d70e66d485877ddd12c98270a51f9b2c029fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:16 -0500
Subject: [PATCH 1169/3820] New translations supported-network-requirements.mdx
 (Ukrainian)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/uk/indexing/supported-network-requirements.mdx

diff --git a/website/pages/uk/indexing/supported-network-requirements.mdx b/website/pages/uk/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..afbf755c0a5a
--- /dev/null
+++ b/website/pages/uk/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 7aad7c8c6422e3349a8c17ee96d1606beecbd702 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:17 -0500
Subject: [PATCH 1170/3820] New translations supported-network-requirements.mdx
 (Chinese Simplified)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/zh/indexing/supported-network-requirements.mdx

diff --git a/website/pages/zh/indexing/supported-network-requirements.mdx b/website/pages/zh/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..d9e844cbbe43
--- /dev/null
+++ b/website/pages/zh/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| 网络        | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| 以太坊       | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 2e4f4a2767cca99bdaa7fc102d89ad6291e15cba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:18 -0500
Subject: [PATCH 1171/3820] New translations supported-network-requirements.mdx
 (Urdu (Pakistan))

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/ur/indexing/supported-network-requirements.mdx

diff --git a/website/pages/ur/indexing/supported-network-requirements.mdx b/website/pages/ur/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..ee345dee7c3f
--- /dev/null
+++ b/website/pages/ur/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| نیٹ ورک   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From d072917ab1adbeaec2baca166cc31199eb9a066d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:19 -0500
Subject: [PATCH 1172/3820] New translations supported-network-requirements.mdx
 (Vietnamese)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/vi/indexing/supported-network-requirements.mdx

diff --git a/website/pages/vi/indexing/supported-network-requirements.mdx b/website/pages/vi/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..a8305e895706
--- /dev/null
+++ b/website/pages/vi/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Mạng lưới | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 71f6fd7ac7b0e3dc9d749a17602584d78d805e80 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:20 -0500
Subject: [PATCH 1173/3820] New translations supported-network-requirements.mdx
 (Marathi)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/mr/indexing/supported-network-requirements.mdx

diff --git a/website/pages/mr/indexing/supported-network-requirements.mdx b/website/pages/mr/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..8d20c31f3fc5
--- /dev/null
+++ b/website/pages/mr/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Network  | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| हिमस्खलन | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base     | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo     | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| इथरियम   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| फॅन्टम   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis   | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| आशावाद   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| बहुभुज   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll   | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From ef63de082e0972cddcf8321f3dc0fb8903d61fc6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:21 -0500
Subject: [PATCH 1174/3820] New translations supported-network-requirements.mdx
 (Hindi)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/hi/indexing/supported-network-requirements.mdx

diff --git a/website/pages/hi/indexing/supported-network-requirements.mdx b/website/pages/hi/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..29673e7529a7
--- /dev/null
+++ b/website/pages/hi/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| नेटवर्क   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _अंतिम बार अपडेट किया गया 22 जून 2024_    |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 57fabdcdbd20e5889e19d32f4cd3320e6581f219 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:23 -0500
Subject: [PATCH 1175/3820] New translations supported-network-requirements.mdx
 (Swahili)

---
 .../supported-network-requirements.mdx         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 website/pages/sw/indexing/supported-network-requirements.mdx

diff --git a/website/pages/sw/indexing/supported-network-requirements.mdx b/website/pages/sw/indexing/supported-network-requirements.mdx
new file mode 100644
index 000000000000..afbf755c0a5a
--- /dev/null
+++ b/website/pages/sw/indexing/supported-network-requirements.mdx
@@ -0,0 +1,18 @@
+---
+title: Supported Network Requirements
+---
+
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |

From 18afa691d85f9245ef208e2c9e4af5963f5a57d6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:24 -0500
Subject: [PATCH 1176/3820] New translations firehose.mdx (Romanian)

---
 .../pages/ro/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ro/indexing/tooling/firehose.mdx

diff --git a/website/pages/ro/indexing/tooling/firehose.mdx b/website/pages/ro/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..0f0fdebbafd0
--- /dev/null
+++ b/website/pages/ro/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Getting Started
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From e4e8164af15c7d94ddf03da11f3975f9775df025 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:25 -0500
Subject: [PATCH 1177/3820] New translations firehose.mdx (French)

---
 .../pages/fr/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/fr/indexing/tooling/firehose.mdx

diff --git a/website/pages/fr/indexing/tooling/firehose.mdx b/website/pages/fr/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..29d1eb45128e
--- /dev/null
+++ b/website/pages/fr/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extrait, transforme et enregistre les données de la blockchain dans une stratégie très performante basée sur des fichiers. Les développeurs de blockchain peuvent ensuite accéder aux données extraites par Firehose par le biais de flux de données binaires. Firehose est destiné à remplacer la couche d'extraction de données blockchain originale de The Graph.
+
+## Documentation Firehose
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Démarrage
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Élargissez vos connaissances
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 5a8a830ee144afed0cb296c03d5d78f6ad7c4ff1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:26 -0500
Subject: [PATCH 1178/3820] New translations firehose.mdx (Spanish)

---
 .../pages/es/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/es/indexing/tooling/firehose.mdx

diff --git a/website/pages/es/indexing/tooling/firehose.mdx b/website/pages/es/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..3839c6178514
--- /dev/null
+++ b/website/pages/es/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Empezando
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From fe67dabf9810c0b8f025ca3d9ac25fe5e16775bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:27 -0500
Subject: [PATCH 1179/3820] New translations firehose.mdx (Arabic)

---
 .../pages/ar/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ar/indexing/tooling/firehose.mdx

diff --git a/website/pages/ar/indexing/tooling/firehose.mdx b/website/pages/ar/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..0f0fdebbafd0
--- /dev/null
+++ b/website/pages/ar/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Getting Started
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 7c08aea7299a4482d45b162e653302d35bfb759d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:27 -0500
Subject: [PATCH 1180/3820] New translations firehose.mdx (Czech)

---
 .../pages/cs/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/cs/indexing/tooling/firehose.mdx

diff --git a/website/pages/cs/indexing/tooling/firehose.mdx b/website/pages/cs/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..56623899121b
--- /dev/null
+++ b/website/pages/cs/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extrahuje, transformuje a ukládá data blockchainu ve vysoce výkonné strategii založené na souborech. Vývojáři blockchainu pak mohou k datům extrahovaným pomocí Firehose přistupovat prostřednictvím binárních datových proudů. Firehose má stát jako náhrada původní vrstvy pro extrakci blockchainových dat Graf.
+
+## Dokumentace Firehose
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Začínáme
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Rozšiřte své znalosti
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From fbe33040591d9130239a22b590048d2d67e2e6a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:28 -0500
Subject: [PATCH 1181/3820] New translations firehose.mdx (German)

---
 .../pages/de/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/de/indexing/tooling/firehose.mdx

diff --git a/website/pages/de/indexing/tooling/firehose.mdx b/website/pages/de/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..0f0fdebbafd0
--- /dev/null
+++ b/website/pages/de/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Getting Started
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 513411efc311c7c800adc0bf4a3ab1eeff9855bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:29 -0500
Subject: [PATCH 1182/3820] New translations firehose.mdx (Italian)

---
 .../pages/it/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/it/indexing/tooling/firehose.mdx

diff --git a/website/pages/it/indexing/tooling/firehose.mdx b/website/pages/it/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..0f0fdebbafd0
--- /dev/null
+++ b/website/pages/it/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Getting Started
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 850a374bc7f668b444c0521ffaa9378253601dfb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:30 -0500
Subject: [PATCH 1183/3820] New translations firehose.mdx (Japanese)

---
 .../pages/ja/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ja/indexing/tooling/firehose.mdx

diff --git a/website/pages/ja/indexing/tooling/firehose.mdx b/website/pages/ja/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..dcb3f088e675
--- /dev/null
+++ b/website/pages/ja/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehoseはブロックチェーンのデータを抽出し、変換し、非常にパフォーマンスの高いファイルベースの戦略で保存します。ブロックチェーン開発者は、Firehoseによって抽出されたデータにバイナリ・データ・ストリームを通じてアクセスすることができる。Firehoseは、The Graphのオリジナルのブロックチェーンデータ抽出レイヤーの代替となることを意図しています。
+
+## Firehose ドキュメンテーション
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### はじめに
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### 知識を広げよう
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 890d1ab4f5f09600ca1ded6071c43e0c3ef020a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:31 -0500
Subject: [PATCH 1184/3820] New translations firehose.mdx (Korean)

---
 .../pages/ko/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ko/indexing/tooling/firehose.mdx

diff --git a/website/pages/ko/indexing/tooling/firehose.mdx b/website/pages/ko/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..0f0fdebbafd0
--- /dev/null
+++ b/website/pages/ko/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Getting Started
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From e9bd2169aa6d52b87fe51b7319089530e3e7c51e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:32 -0500
Subject: [PATCH 1185/3820] New translations firehose.mdx (Dutch)

---
 .../pages/nl/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/nl/indexing/tooling/firehose.mdx

diff --git a/website/pages/nl/indexing/tooling/firehose.mdx b/website/pages/nl/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..0f0fdebbafd0
--- /dev/null
+++ b/website/pages/nl/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Getting Started
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From d2ba493ff890b109a4bd2ccc7855b02525a31e3a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:33 -0500
Subject: [PATCH 1186/3820] New translations firehose.mdx (Polish)

---
 .../pages/pl/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/pl/indexing/tooling/firehose.mdx

diff --git a/website/pages/pl/indexing/tooling/firehose.mdx b/website/pages/pl/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..0f0fdebbafd0
--- /dev/null
+++ b/website/pages/pl/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Getting Started
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 0b70bdddcfdc1ed7453f03c4bec75b4e0f49b632 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:34 -0500
Subject: [PATCH 1187/3820] New translations firehose.mdx (Portuguese)

---
 .../pages/pt/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/pt/indexing/tooling/firehose.mdx

diff --git a/website/pages/pt/indexing/tooling/firehose.mdx b/website/pages/pt/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..4ab94a3ff649
--- /dev/null
+++ b/website/pages/pt/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+O Firehose extrai, transforma e salva dados de blockchain em uma estratégia baseada em arquivos e de alto desempenho. Os programadores de blockchain podem então acessar dados extraídos pelo Firehose através de streams de dados binários. A intenção do Firehose é substituir a camada original de extração de dados de blockchain do The Graph.
+
+## Documentação do Firehose
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Como Começar
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expanda o Seu Conhecimento
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 2e7a58f059f4b66149f86d79adf853ffdf56a73f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:35 -0500
Subject: [PATCH 1188/3820] New translations firehose.mdx (Russian)

---
 .../pages/ru/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ru/indexing/tooling/firehose.mdx

diff --git a/website/pages/ru/indexing/tooling/firehose.mdx b/website/pages/ru/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..1986d99aa807
--- /dev/null
+++ b/website/pages/ru/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Начало работы
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 78e986badb52a26dadea84addb32e3747bc0fb08 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:37 -0500
Subject: [PATCH 1189/3820] New translations firehose.mdx (Swedish)

---
 .../pages/sv/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/sv/indexing/tooling/firehose.mdx

diff --git a/website/pages/sv/indexing/tooling/firehose.mdx b/website/pages/sv/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..cb1de091c391
--- /dev/null
+++ b/website/pages/sv/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Komma igång
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 3115a27a91c1f6965b1c02579c6702f06153bea3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:38 -0500
Subject: [PATCH 1190/3820] New translations firehose.mdx (Turkish)

---
 .../pages/tr/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/tr/indexing/tooling/firehose.mdx

diff --git a/website/pages/tr/indexing/tooling/firehose.mdx b/website/pages/tr/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..686b37df1c43
--- /dev/null
+++ b/website/pages/tr/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose, blok zinciri verilerini yüksek performanslı dosya tabanlı bir stratejiyle çıkarır, dönüştürür ve kaydeder. Blok zinciri geliştiricileri daha sonra Firehose tarafından çıkarılan verilere ikili veri akışları üzerinden erişebilir. Firehose'un Graph'ın orijinal blok zinciri veri çıkarma katmanının yerine geçmesi amaçlanmıştır.
+
+## Firehose Dökümantasyonu
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Buradan Başlayın
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Bilgi Dağarcığınızı Genişletin
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 3f9360f5a5589d1e26d045c13617d1199dbd6664 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:38 -0500
Subject: [PATCH 1191/3820] New translations firehose.mdx (Ukrainian)

---
 .../pages/uk/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/uk/indexing/tooling/firehose.mdx

diff --git a/website/pages/uk/indexing/tooling/firehose.mdx b/website/pages/uk/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..0f0fdebbafd0
--- /dev/null
+++ b/website/pages/uk/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Getting Started
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 91f207b08e491132369a8deebafca127991b9def Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:39 -0500
Subject: [PATCH 1192/3820] New translations firehose.mdx (Chinese Simplified)

---
 .../pages/zh/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/zh/indexing/tooling/firehose.mdx

diff --git a/website/pages/zh/indexing/tooling/firehose.mdx b/website/pages/zh/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..6e8c9b46a23c
--- /dev/null
+++ b/website/pages/zh/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### 开始
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### 知识拓展
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 4cb15269e5456c0112c79a4ad2f98ed661cb3be7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:40 -0500
Subject: [PATCH 1193/3820] New translations firehose.mdx (Urdu (Pakistan))

---
 .../pages/ur/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ur/indexing/tooling/firehose.mdx

diff --git a/website/pages/ur/indexing/tooling/firehose.mdx b/website/pages/ur/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..8b1591e1d015
--- /dev/null
+++ b/website/pages/ur/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### شروع ہوا چاہتا ہے
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### اپنے علم کو وسعت دیں
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From ceffc463954d7b9840ba6ed874acf8bdfec13186 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:42 -0500
Subject: [PATCH 1194/3820] New translations firehose.mdx (Vietnamese)

---
 .../pages/vi/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/vi/indexing/tooling/firehose.mdx

diff --git a/website/pages/vi/indexing/tooling/firehose.mdx b/website/pages/vi/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..0f0fdebbafd0
--- /dev/null
+++ b/website/pages/vi/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Getting Started
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From a3d4072a7e86112a404d9ce19b8a3ad3f90d1c2d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:43 -0500
Subject: [PATCH 1195/3820] New translations firehose.mdx (Marathi)

---
 .../pages/mr/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/mr/indexing/tooling/firehose.mdx

diff --git a/website/pages/mr/indexing/tooling/firehose.mdx b/website/pages/mr/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..6b643f84a0e0
--- /dev/null
+++ b/website/pages/mr/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### प्रारंभ करणे
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 22c367e6851be61701a43c94ceefa837f6d1f9f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:44 -0500
Subject: [PATCH 1196/3820] New translations firehose.mdx (Hindi)

---
 .../pages/hi/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/hi/indexing/tooling/firehose.mdx

diff --git a/website/pages/hi/indexing/tooling/firehose.mdx b/website/pages/hi/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..199ab7661bb4
--- /dev/null
+++ b/website/pages/hi/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### शुरू करना
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 3303c4a1341cea76b2dcb25368430108697541af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:45 -0500
Subject: [PATCH 1197/3820] New translations firehose.mdx (Swahili)

---
 .../pages/sw/indexing/tooling/firehose.mdx    | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/sw/indexing/tooling/firehose.mdx

diff --git a/website/pages/sw/indexing/tooling/firehose.mdx b/website/pages/sw/indexing/tooling/firehose.mdx
new file mode 100644
index 000000000000..0f0fdebbafd0
--- /dev/null
+++ b/website/pages/sw/indexing/tooling/firehose.mdx
@@ -0,0 +1,24 @@
+---
+title: Firehose
+---
+
+![Firehose Logo](/img/firehose-logo.png)
+
+Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+
+The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+
+Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+
+## Firehose Documentation
+
+The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+
+### Getting Started
+
+- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
+- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+
+### Expand Your Knowledge
+
+- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.

From 796ad07fd5ed31018d37a9d1707bafcbbd0e8023 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:46 -0500
Subject: [PATCH 1198/3820] New translations graphcast.mdx (Romanian)

---
 .../pages/ro/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ro/indexing/tooling/graphcast.mdx

diff --git a/website/pages/ro/indexing/tooling/graphcast.mdx b/website/pages/ro/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..4072877a1257
--- /dev/null
+++ b/website/pages/ro/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introduction
+
+Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+
+Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+
+The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
+- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
+- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
+- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+
+### Learn More
+
+If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From 5e81ef764846d8ac65087b297b84ce11ae7bddc7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:47 -0500
Subject: [PATCH 1199/3820] New translations graphcast.mdx (French)

---
 .../pages/fr/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/fr/indexing/tooling/graphcast.mdx

diff --git a/website/pages/fr/indexing/tooling/graphcast.mdx b/website/pages/fr/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..5edccfb10588
--- /dev/null
+++ b/website/pages/fr/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Présentation
+
+Y a-t-il quelque chose que vous aimeriez apprendre ou partager avec vos collègues indexeurs de manière automatisée, mais c'est trop compliqué ou coûte trop cher ?
+
+Actuellement, le coût de diffusion d’informations vers d’autres participants au réseau est déterminé par les frais de gaz sur la blockchain Ethereum. Graphcast résout ce problème en agissant comme un outil de communication peer-to-peer (P2P) décentralisé et distribué en option qui permet aux indexeurs du réseau d'échanger des informations en temps réel. Le coût de l’échange de messages P2P est proche de zéro, sans aucune garantie d’intégrité des données. Néanmoins, Graphcast vise à fournir des garanties de validité du message (c'est-à-dire que le message est valide et signé par un participant au protocole connu) avec un espace de conception ouvert de modèles de réputation.
+
+Le SDK Graphcast (Software Development Kit) permet aux développeurs de créer des radios, qui sont des applications basées sur les potins que les indexeurs peuvent exécuter dans un but donné. Nous avons également l'intention de créer quelques radios (ou de fournir une assistance à d'autres développeurs/équipes qui souhaitent créer des radios) pour les cas d'utilisation suivants :
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Réalisation d'enchères et coordination pour les subgraphs, les substreams, et les données Firehose de synchronisation de distorsion provenant d'autres indexeurs.
+- Auto-rapport sur l'analyse des requêtes actives, y compris les volumes de requêtes de subgraphs, les volumes de frais, etc.
+- Auto-rapport sur l'analyse de l'indexation, y compris le temps d'indexation des subgraphs, les coûts des gaz de traitement, les erreurs d'indexation rencontrées, etc.
+- Auto-déclaration sur les informations de la pile, y compris la version du graph-node, la version Postgres, la version du client Ethereum, etc.
+
+### En savoir plus
+
+Si vous souhaitez en savoir plus sur Graphcast, [consultez la documentation ici] (https://docs.graphops.xyz/graphcast/intro)

From f3cfc35db477b1479a5b341bc8250a101da16ba4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:48 -0500
Subject: [PATCH 1200/3820] New translations graphcast.mdx (Spanish)

---
 .../pages/es/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/es/indexing/tooling/graphcast.mdx

diff --git a/website/pages/es/indexing/tooling/graphcast.mdx b/website/pages/es/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..3da74365af91
--- /dev/null
+++ b/website/pages/es/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introducción
+
+¿Quieres aprender o compartir algo con tus colegas Indexadores de forma automática pero es demasiado engorroso o cuesta mucho gas?
+
+En la actualidad, el costo de transmitir información a otros participantes de la red es determinado por los costos de gas en la Blockchain de Ethereum. Graphcast resuelve este problema al actuar como una herramienta de comunicación descentralizada, distribuida peer-to-peer (P2P), que permite a los Indexadores intercambiar información a través de la red en tiempo real. El costo de intercambiar mensajes P2P es casi nulo, pero no garantiza la integridad de los datos. Sin embargo, Graphcast tiene como objetivo brindar garantías de validez del mensaje (por ej. que el mensaje es válido y está firmado por un participante del protocolo conocido) con un espacio de modelos de reputación de diseño abierto.
+
+El Graphcast SDK (Kit de Desarrollo de Software) permite a los desarrolladores construir Radios, que son aplicaciones impulsadas por gossip que los Indexadores pueden utilizar con una finalidad específica. También queremos crear algunas Radios (o dar soporte a otros desarrolladores/equipos que deseen construir Radios) para los siguientes casos de uso:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Llevar a cabo subastas y coordinar warp-syncing de datos de subgrafos, substreams y Firehose de otros Indexadores.
+- Autoinforme sobre análisis de consultas activas, incluidos volúmenes de consultas de subgrafos, volúmenes de tarifas, etc.
+- Generar informes propios sobre análisis del proceso de indexación, que incluyan período de indexación de subgrafos, costos de gas handler, indexación de errores encontrados, etc.
+- Generar informes propios sobre información de stack que incluyan versión del graph-node, la versión de Postgres, la versión del cliente de Ethereum, etc.
+
+### Aprende más
+
+Si quieres aprender más sobre Graphcast, [consulta los documentos aquí.](https://docs.graphops.xyz/graphcast/intro)

From d39af9449a8cd0ce8cf895f7b99684ef9b48718a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:49 -0500
Subject: [PATCH 1201/3820] New translations graphcast.mdx (Arabic)

---
 .../pages/ar/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ar/indexing/tooling/graphcast.mdx

diff --git a/website/pages/ar/indexing/tooling/graphcast.mdx b/website/pages/ar/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..8fc00976ec28
--- /dev/null
+++ b/website/pages/ar/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## مقدمة
+
+Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+
+Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+
+The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
+- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
+- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
+- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+
+### Learn More
+
+If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From b8077d12dfaaa1da58a4a53a156a6ce14d06f451 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:50 -0500
Subject: [PATCH 1202/3820] New translations graphcast.mdx (Czech)

---
 .../pages/cs/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/cs/indexing/tooling/graphcast.mdx

diff --git a/website/pages/cs/indexing/tooling/graphcast.mdx b/website/pages/cs/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..aec7d84070c3
--- /dev/null
+++ b/website/pages/cs/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Úvod
+
+Rádi byste se něco naučili nebo se o to podělili s ostatními indexátory automatizovaným způsobem, ale je to příliš náročné nebo to stojí příliš mnoho plyn?
+
+V současné době jsou náklady na vysílání informací ostatním účastníkům sítě určovány poplatky za plyn v blockchainu Ethereum. Graphcast tento problém řeší tím, že funguje jako volitelný decentralizovaný, distribuovaný komunikační nástroj peer-to-peer (P2P), který umožňuje indexerům v celé síti vyměňovat si informace v reálném čase. Náklady na výměnu P2P zpráv jsou téměř nulové, kompromisem je absence záruk integrity dat. Nicméně Graphcast si klade za cíl poskytovat záruky platnosti zpráv (tj. že zpráva je platná a podepsaná známým účastníkem protokolu) s otevřeným prostorem pro návrh reputačních modelů.
+
+Graphcast SDK (Vývoj softwaru Kit) umožňuje vývojářům vytvářet rádia, což jsou aplikace napájené drby, které mohou indexery spouštět k danému účelu. Máme také v úmyslu vytvořit několik Radios (nebo poskytnout podporu jiným vývojářům/týmům, které chtějí Radios vytvořit) pro následující případy použití:
+
+- Křížová kontrola integrity dat subgrafu v reálném čase ([Podgraf Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Provádění aukcí a koordinace pro warp synchronizaci podgrafů, substreamů a dat Firehose z jiných Indexerů.
+- Vlastní hlášení o analýze aktivních dotazů, včetně objemů požadavků na dílčí grafy, objemů poplatků atd.
+- Vlastní hlášení o analýze indexování, včetně času indexování podgrafů, nákladů na plyn obsluhy, zjištěných chyb indexování atd.
+- Vlastní hlášení informací o zásobníku včetně verze grafového uzlu, verze Postgres, verze klienta Ethereum atd.
+
+### Dozvědět se více
+
+Pokud se chcete o Graphcast dozvědět více, [podívejte se na dokumentaci zde] (https://docs.graphops.xyz/graphcast/intro)

From 7d237a576dae7229ca2e4826267e6e5f1c7d57a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:51 -0500
Subject: [PATCH 1203/3820] New translations graphcast.mdx (German)

---
 .../pages/de/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/de/indexing/tooling/graphcast.mdx

diff --git a/website/pages/de/indexing/tooling/graphcast.mdx b/website/pages/de/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..4072877a1257
--- /dev/null
+++ b/website/pages/de/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introduction
+
+Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+
+Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+
+The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
+- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
+- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
+- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+
+### Learn More
+
+If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From 416ba603578e1cb3180b5f75b2ad249c19f45691 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:52 -0500
Subject: [PATCH 1204/3820] New translations graphcast.mdx (Italian)

---
 .../pages/it/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/it/indexing/tooling/graphcast.mdx

diff --git a/website/pages/it/indexing/tooling/graphcast.mdx b/website/pages/it/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..6d0cd00b7784
--- /dev/null
+++ b/website/pages/it/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introduzione
+
+C'è qualcosa che vorreste imparare o condividere con i vostri colleghi Indexer in modo automatico, ma è troppo fastidioso o costa troppo gas?
+
+Attualmente, il costo per trasmettere informazioni ad altri partecipanti alla rete è determinato dalle tariffe del gas sulla blockchain di Ethereum. Graphcast risolve questo problema agendo come strumento di comunicazione decentralizzato e distribuito peer-to-peer (P2P) opzionale che consente agli indexer della rete di scambiare informazioni in tempo reale. Il costo dello scambio di messaggi P2P è prossimo allo zero, con lo svantaggio di non avere garanzie di integrità dei dati. Tuttavia, Graphcast mira a fornire garanzie di validità dei messaggi (cioè che il messaggio sia valido e firmato da un partecipante noto al protocollo) con uno spazio di progettazione aperto di modelli di reputazione.
+
+L'SDK (Software Development Kit) di Graphcast consente agli sviluppatori di creare radio, che sono applicazioni alimentate da gossip che gli indexer possono eseguire per servire un determinato scopo. Intendiamo inoltre creare alcune radio (o fornire supporto ad altri sviluppatori/team che desiderano creare radio) per i seguenti casi d'uso:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conduzione di aste e coordinamento per la sincronizzazione warp di subgraph, substream e dati Firehose da altri indexer.
+- Autodichiarazione sulle analisi delle query attive, compresi i volumi delle richieste di subgraph, i volumi delle commissioni, ecc.
+- Autodichiarazione sull'analisi dell'indicizzazione, compresi i tempi di indicizzazione dei subgraph, i costi del gas per i gestori, gli errori di indicizzazione riscontrati, ecc.
+- Autodichiarazione delle informazioni sullo stack, tra cui la versione del graph-node, la versione di Postgres, la versione del client Ethereum, ecc.
+
+### Scopri di più
+
+Se volete saperne di più su Graphcast, [consultate la documentazione qui.](https://docs.graphops.xyz/graphcast/intro)

From d0b565685adf6b6c42540663d9d98b151f9eab79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:53 -0500
Subject: [PATCH 1205/3820] New translations graphcast.mdx (Japanese)

---
 .../pages/ja/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ja/indexing/tooling/graphcast.mdx

diff --git a/website/pages/ja/indexing/tooling/graphcast.mdx b/website/pages/ja/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..b9d89010f922
--- /dev/null
+++ b/website/pages/ja/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: グラフキャスト
+---
+
+## イントロダクション
+
+自動化された方法で仲間のインデクサーから学びたい、または仲間と共有したいことはありますか, しかし、それは手間がかかりすぎたり、ガス代がかかりすぎたりしますか?
+
+現在、他のネットワーク参加者に情報をブロードキャストするためのコストは、イーサリアム ブロックチェーンのガス料金によって決定されます。 Graphcast は、オプションの分散型分散ピアツーピア (P2P) 通信ツールとして機能することで、この問題を解決します。これにより、ネットワーク全体のインデクサーがリアルタイムで情報を交換できるようになります。 P2P メッセージを交換するコストはほぼゼロですが、データの完全性が保証されないというトレードオフがあります。それにもかかわらず、Graphcast は、レピュテーション モデルのオープン デザイン スペースを使用して、メッセージの有効性の保証 (つまり、メッセージが有効であり、既知のプロトコル参加者によって署名されていること) を提供することを目指しています。
+
+Graphcast SDK (ソフトウェア開発キット) を使用すると、開発者はラジオを構築できます。これは、インデクサーが特定の目的を果たすために実行できる、ゴシップを利用したアプリケーションです。また、次のユースケースのために、いくつかのラジオを作成する (または、ラジオを作成したい他の開発者/チームにサポートを提供する) 予定です:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- サブグラフ、サブストリーム、および他のインデクサーからの Firehose データをワープ同期するためのオークションと調整の実施。
+- サブグラフのリクエスト量、料金の量などを含む、アクティブなクエリ分析に関する自己報告。
+- サブグラフのインデックス作成時間、ハンドラー ガスのコスト、発生したインデックス作成エラーなどを含む、インデックス作成分析に関する自己報告。
+- グラフノードのバージョン、Postgres のバージョン、Ethereum クライアントのバージョンなどを含むスタック情報の自己報告。
+
+### もっと詳しく知る
+
+Graphcast の詳細については、[こちらのドキュメントをご覧ください](https://docs.graphops.xyz/graphcast/intro)。

From 4cc972e03ae80fac1ecffe53f2e8a7f37329f3c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:54 -0500
Subject: [PATCH 1206/3820] New translations graphcast.mdx (Korean)

---
 .../pages/ko/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ko/indexing/tooling/graphcast.mdx

diff --git a/website/pages/ko/indexing/tooling/graphcast.mdx b/website/pages/ko/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..4072877a1257
--- /dev/null
+++ b/website/pages/ko/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introduction
+
+Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+
+Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+
+The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
+- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
+- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
+- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+
+### Learn More
+
+If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From 596eb6cacb1caf05e9a4e3ccbda96de2b3ddbceb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:55 -0500
Subject: [PATCH 1207/3820] New translations graphcast.mdx (Dutch)

---
 .../pages/nl/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/nl/indexing/tooling/graphcast.mdx

diff --git a/website/pages/nl/indexing/tooling/graphcast.mdx b/website/pages/nl/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..4072877a1257
--- /dev/null
+++ b/website/pages/nl/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introduction
+
+Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+
+Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+
+The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
+- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
+- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
+- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+
+### Learn More
+
+If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From 6ac35212f8688e9d52b62f1ce600607a11e0c653 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:56 -0500
Subject: [PATCH 1208/3820] New translations graphcast.mdx (Polish)

---
 .../pages/pl/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/pl/indexing/tooling/graphcast.mdx

diff --git a/website/pages/pl/indexing/tooling/graphcast.mdx b/website/pages/pl/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..18639dc9acc8
--- /dev/null
+++ b/website/pages/pl/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Wstęp
+
+Czy jest coś, czego chciałbyś/chciałabyś się dowiedzieć lub czym chciałbyś/chciałabyś podzielić się z indekserami w bardziej zautomatyzowany sposób, ale wydaje Ci się to zawracaniem głowy lub kosztuje za dużo gazu?
+
+Obecnie koszt przekazywania informacji innym uczestnikom sieci jest uzależniony od opłat za gaz w sieci blockchain Ethereum. Graphcast rozwiązuje ten problem umożliwiając praktycznie bezpłatną wymianę wiadomości P2P (ang. peer-to-peer - równy z równym) między indekserami różnych sieci w czasie rzeczywistym. Choć koszt wymiany takich wiadomości P2P jest bliski zeru to jednak brakuje gwarancji integralności danych. Niemniej jednak, Graphcast dąży do zapewnienia wiarygodności wiadomości (tzn.gwarancji że wiadomość jest poprawna i podpisana przez znanego uczestnika protokołu) przy jednoczesnym zachowaniu otwartego modelu reputacji.
+
+SDK Graphcast (Software Development Kit) umożliwia programistom budowanie "Radios", czyli aplikacji opartych na przekazywaniu plotek, które indekserzy mogą uruchamiać w celu spełnienia określonego zadania. Planujemy również stworzyć kilka takich aplikacji Radios (lub udzielać wsparcia innym programistom/zespołom, które chcą w ich budowaniu uczestniczyć) dla następujących przypadków użycia:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Przeprowadzanie aukcji i koordynacja synchronizacji warp subgrafów, substreamów oraz danych Firehose od innych indekserów.
+- Raportowanie na temat aktywnej analizy zapytań, w tym wolumenów zapytań do subgrafów, wolumenów opłat itp.
+- Raportowanie na temat analizy indeksowania, w tym czasu indeksowania subgrafów, kosztów gazu dla osób obsługujących zapytanie, napotkanych błędów indeksowania itp.
+- Raportowanie informacji na temat stosu, w tym wersji graph-node, wersji Postgres oraz wersji klienta Ethereum itp.
+
+### Dowiedz się więcej
+
+Jeśli chcesz dowiedzieć się więcej o Graphcast, [zapoznaj się z dokumentacją tutaj.](https://docs.graphops.xyz/graphcast/intro)

From 5b604bdf295ccb48a4a18eac9391a2f5429a54c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:57 -0500
Subject: [PATCH 1209/3820] New translations graphcast.mdx (Portuguese)

---
 .../pages/pt/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/pt/indexing/tooling/graphcast.mdx

diff --git a/website/pages/pt/indexing/tooling/graphcast.mdx b/website/pages/pt/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..e57b6b206900
--- /dev/null
+++ b/website/pages/pt/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introdução
+
+Há algo que gostaria de aprender ou compartilhar com os seus colegas Indexadores de uma maneira automatizada, mas isto leva muito esforço ou custa muito gas?
+
+Atualmente, o custo de transmitir informações para outros participantes de rede é determinado por taxas de gas na blockchain Ethereum. O Graphcast resolve este problema ao agir como uma ferramenta de comunicação peer-to-peer (P2P) descentralizada e distribuída, que permite que Indexadores pela rede troquem informações em tempo real. O custo de trocar mensagens P2P é quase zero, porém não garante a integridade de dados. Mesmo assim, o Graphcast visa oferecer garantias de validade de mensagens (por ex., que a mensagem é válida e assinada por um participante conhecido do protocolo) com um espaço de design de modelos de reputação aberto.
+
+O SDK (Kit de Programação de Software) do Graphcast permite aos programadores construir Rádios, que são aplicativos movidos a mexericos, que os Indexers podem executar por um certo propósito. Nós também pretendemos criar alguns Rádios (ou oferecer apoio para outros programadores/outras equipas que desejam construir Rádios) para os seguintes casos de uso:
+
+- Verificação em tempo real de integridade dos dados de um subgraph ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Condução de leilões e coordenação para a sincronização de subgraphs, substreams e dados do Firehose de outros Indexers.
+- Autorrelatos em analíticas ativas de queries, inclusive volumes de pedidos de subgraphs, volumes de taxas, etc.
+- Autorrelatos em analíticas de indexação, como tempo de indexação de subgraphs, custos de gas de handlers, erros encontrados, etc.
+- Autorrelatos em informações de stack, incluindo versão do graph-node, versão do Postgres, versão do cliente Ethereum, etc.
+
+### Aprenda Mais
+
+Se quiser aprender mais sobre o Graphcast, [confira a documentação aqui.](https://docs.graphops.xyz/graphcast/intro)

From c944d6ec30dda0f348c1a0288d8b694a7c7c678f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:58 -0500
Subject: [PATCH 1210/3820] New translations graphcast.mdx (Russian)

---
 .../pages/ru/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ru/indexing/tooling/graphcast.mdx

diff --git a/website/pages/ru/indexing/tooling/graphcast.mdx b/website/pages/ru/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..a49399997208
--- /dev/null
+++ b/website/pages/ru/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introduction
+
+Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+
+Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+
+The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
+- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
+- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
+- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+
+### Узнать больше
+
+If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From a3c10693f05ccc157be00f1cc983165cd6ae6e43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:05:59 -0500
Subject: [PATCH 1211/3820] New translations graphcast.mdx (Swedish)

---
 .../pages/sv/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/sv/indexing/tooling/graphcast.mdx

diff --git a/website/pages/sv/indexing/tooling/graphcast.mdx b/website/pages/sv/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..843b713c1bd0
--- /dev/null
+++ b/website/pages/sv/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introduktion
+
+Finns det något du skulle vilja lära dig från eller dela med dina medindexare på ett automatiserat sätt, men det är för mycket besvär eller kostar för mycket gas?
+
+För närvarande avgörs kostnaden för att sända information till andra nätverksdeltagare av gasavgifter på Ethereum-blockkedjan. Graphcast löser detta problem genom att agera som ett frivilligt decentraliserat, distribuerat peer-to-peer (P2P) kommunikationsverktyg som möjliggör utbyte av information i realtid mellan indexare över nätverket. Kostnaden för att utbyta P2P-meddelanden är nära noll, med avvägningen av att det inte finns några garantier för datintegritet. Trots detta strävar Graphcast efter att tillhandahålla garantier för meddelandevaliditet (dvs. att meddelandet är giltigt och signerat av en känd protokolldeltagare) med ett öppet utrymme för design av ryktmodeller.
+
+Graphcast SDK (Utrustning för programvaruutveckling) gör det möjligt för utvecklare att bygga Radios, vilka är applikationer som drivs av gossipeffekt och som indexare kan köra för att tjäna ett visst syfte. Vi avser också att skapa några Radios (eller ge stöd åt andra utvecklare/team som önskar bygga Radios) för följande användningsområden:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Genomföra auktioner och koordinering för warp-synkronisering av delgrafer, delströmmar och Firehose-data från andra indexare.
+- Självrapportering om aktiv frågeanalys, inklusive delgrafförfrågningsvolym, avgiftsvolym etc.
+- Självrapportering om indexeringanalys, inklusive tid för delgrafindexering, gasavgifter för handler, påträffade indexeringsfel etc.
+- Självrapportering om stackinformation inklusive graph-node-version, Postgres-version, Ethereum-klientversion etc.
+
+### Lär dig mer
+
+Om du vill lära dig mer om Graphcast, [kolla in dokumentationen här.](https://docs.graphops.xyz/graphcast/intro)

From dd6834816e66437ceef2dcd71e009a5722b41065 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:01 -0500
Subject: [PATCH 1212/3820] New translations graphcast.mdx (Turkish)

---
 .../pages/tr/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/tr/indexing/tooling/graphcast.mdx

diff --git a/website/pages/tr/indexing/tooling/graphcast.mdx b/website/pages/tr/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..1ddae707e52e
--- /dev/null
+++ b/website/pages/tr/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Giriş
+
+Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+
+Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+
+The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
+- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
+- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
+- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+
+### Learn More
+
+If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From aaf6e73298c24c955ab931d4c98be9b36c32894f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:02 -0500
Subject: [PATCH 1213/3820] New translations graphcast.mdx (Ukrainian)

---
 .../pages/uk/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/uk/indexing/tooling/graphcast.mdx

diff --git a/website/pages/uk/indexing/tooling/graphcast.mdx b/website/pages/uk/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..4072877a1257
--- /dev/null
+++ b/website/pages/uk/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introduction
+
+Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+
+Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+
+The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
+- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
+- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
+- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+
+### Learn More
+
+If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From 9d9bd6ad99ec9c0833ed25661e5556d733090105 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:03 -0500
Subject: [PATCH 1214/3820] New translations graphcast.mdx (Chinese Simplified)

---
 .../pages/zh/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/zh/indexing/tooling/graphcast.mdx

diff --git a/website/pages/zh/indexing/tooling/graphcast.mdx b/website/pages/zh/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..d8eeb0aa957a
--- /dev/null
+++ b/website/pages/zh/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## 介绍
+
+有什么你想以自动化的方式向其他索引人学习或分享的东西吗？但这太麻烦或太费gas了？
+
+目前，向其他网络参与者广播信息的成本由以太坊区块链上的gas费用决定。Graphcast通过充当一个可选的去中心化、分布式对等（P2P）通信工具来解决这个问题，该工具允许网络上的索引人实时交换信息。在没有数据完整性保证的情况下，交换P2P消息的成本几乎为零。尽管如此，Graphcast旨在通过信誉模型的开放设计空间提供消息有效性保证（即消息是有效的，并由已知的协议参与者签名）。
+
+Graphcast SDK（软件开发工具包）允许开发人员构建Radio，这是一种使用gossip协议的应用程序，索引人可以运行这些应用程序来服务于特定的目的。我们还打算为以下用例创建一些Radio（或为希望构建Radio的其他开发人员/团队提供支持）：
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- \-对来自其他索引人的warp同步中的子图、子流和Firehose数据进行拍卖和协调。
+- \-主动查询分析的自我报告，包括子图请求量、费用量等。
+- \-索引分析的自我报告，包括子图索引时间、处理程序gas成本、遇到的索引错误等。
+- \-自报栈信息，包括graph节点版本、Postgres版本、以太坊客户端版本等。
+
+### 了解更多
+
+如果您想了解更多关于Graphcast的信息， [请查看此处的文档。](https://docs.graphops.xyz/graphcast/intro)

From 05ef043ee00d63598734752243bb0392fc61464f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:04 -0500
Subject: [PATCH 1215/3820] New translations graphcast.mdx (Urdu (Pakistan))

---
 .../pages/ur/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ur/indexing/tooling/graphcast.mdx

diff --git a/website/pages/ur/indexing/tooling/graphcast.mdx b/website/pages/ur/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..4a7b5e2c4cfd
--- /dev/null
+++ b/website/pages/ur/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: گراف کاسٹ
+---
+
+## تعارف
+
+کیا کوئی ایسی چیز ہے جس سے آپ سیکھنا چاہتے ہیں یا اپنے ساتھی انڈیکسرز کے ساتھ خودکار طریقے سے شیئر کرنا چاہتے ہیں، لیکن یہ بہت زیادہ پریشانی ہے یا بہت زیادہ گیس کی قیمت ہے؟
+
+فی الحال، نیٹ ورک کے دیگر شرکاء کو معلومات نشر کرنے کی لاگت کا تعین ایتھیریم بلاکچین پر گیس کی فیس سے کیا جاتا ہے۔ گراف کاسٹ اس مسئلے کو ایک اختیاری ڈیسینٹرالائزڈ، تقسیم شدہ پیئر ٹو پیئر (P2P) کمیونیکیشن ٹول کے طور پر حل کرتا ہے جو پورے نیٹ ورک کے انڈیکسرز کو حقیقی وقت میں معلومات کا تبادلہ کرنے کی اجازت دیتا ہے۔ P2P پیغامات کے تبادلے کی لاگت صفر کے قریب ہے، بغیر کسی ڈیٹا کی سالمیت کی ضمانت کے ٹریڈ آف کے ساتھ۔ بہر حال، گراف کاسٹ کا مقصد ساکھ کے ماڈلز کی کھلی ڈیزائن کی جگہ کے ساتھ پیغام کی درستگی کی ضمانتیں فراہم کرنا ہے (یعنی یہ کہ پیغام درست ہے اور ایک معروف پروٹوکول شریک کے ذریعے دستخط شدہ ہے).
+
+گراف کاسٹ SDK (سافٹ ویئر ڈویلپمنٹ کٹ) ڈویلپرز کو ریڈیو بنانے کی اجازت دیتا ہے، جو گپ شپ سے چلنے والی ایپلیکیشنز ہیں جنہیں انڈیکسرز ایک مقررہ مقصد کی تکمیل کے لیے چلا سکتے ہیں۔ ہم مندرجہ ذیل استعمال کے معاملات کے لیے چند ریڈیوز بنانے کا ارادہ رکھتے ہیں (یا دیگر ڈویلپرز/ٹیموں کو مدد فراہم کرتے ہیں جو ریڈیو بنانا چاہتے ہیں):
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- دوسرے انڈیکسرز سے وارپ سنکنگ سب گرافس، سب اسٹریمز، اور فائر ہوز ڈیٹا کے لیے نیلامی اور کوآرڈینیشن کا انعقاد.
+- فعال کیوری کے تجزیات پر خود رپورٹنگ، بشمول سب گراف کی درخواست والیوم، فیس والیوم وغیرہ.
+- انڈیکسنگ کے تجزیات پر خود رپورٹنگ، بشمول سب گراف انڈیکسنگ کا وقت، ہینڈلر گیس کے اخراجات، انڈیکسنگ کی غلطیوں کا سامنا کرنا وغیرہ.
+- اسٹیک کی معلومات پر خود رپورٹنگ بشمول گراف نوڈ ورژن، Postgres ورژن، ایتھیریم کلائنٹ ورژن، وغیرہ.
+
+### مزید جانیے
+
+اگر آپ گراف کاسٹ کے بارے میں مزید جاننا چاہتے ہیں تو، [یہاں دستاویزات چیک کریں.](https://docs.graphops.xyz/graphcast/intro)

From d86e9b87ac3f32bc24b74aa5e9b3ec6e623c2f87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:05 -0500
Subject: [PATCH 1216/3820] New translations graphcast.mdx (Vietnamese)

---
 .../pages/vi/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/vi/indexing/tooling/graphcast.mdx

diff --git a/website/pages/vi/indexing/tooling/graphcast.mdx b/website/pages/vi/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..2c523a014098
--- /dev/null
+++ b/website/pages/vi/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Giới thiệu
+
+Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+
+Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+
+The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
+- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
+- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
+- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+
+### Learn More
+
+If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From 2b18f48571981f277d73cb492dd714b24873bd41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:06 -0500
Subject: [PATCH 1217/3820] New translations graphcast.mdx (Marathi)

---
 .../pages/mr/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/mr/indexing/tooling/graphcast.mdx

diff --git a/website/pages/mr/indexing/tooling/graphcast.mdx b/website/pages/mr/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..281104f50781
--- /dev/null
+++ b/website/pages/mr/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introduction
+
+Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+
+सध्या, इतर नेटवर्क सहभागींना माहिती प्रसारित करण्याची किंमत इथरियम ब्लॉकचेनवरील गॅस फीद्वारे निर्धारित केली जाते. ग्राफकास्ट पर्यायी विकेंद्रित, वितरित पीअर-टू-पीअर (P2P) संप्रेषण साधन म्हणून कार्य करून या समस्येचे निराकरण करते जे संपूर्ण नेटवर्कवरील इंडेक्सर्सना रिअल टाइममध्ये माहितीची देवाणघेवाण करण्यास अनुमती देते. P2P संदेशांची देवाणघेवाण करण्याची किंमत शून्याच्या जवळ आहे, कोणत्याही डेटा अखंडतेची हमी नसतानाही. तरीसुद्धा, ग्राफकास्टचे उद्दिष्ट आहे की मेसेज वैधता हमी प्रदान करणे (म्हणजे संदेश वैध आहे आणि एखाद्या ज्ञात प्रोटोकॉल सहभागीने स्वाक्षरी केलेला आहे) प्रतिष्ठा मॉडेल्सच्या खुल्या डिझाइन स्पेससह.
+
+ग्राफकास्ट SDK (सॉफ्टवेअर डेव्हलपमेंट किट) विकसकांना रेडिओ तयार करण्यास अनुमती देते, जे गॉसिप-शक्तीवर चालणारे अनुप्रयोग आहेत जे निर्देशांक दिलेल्या उद्देशासाठी चालवू शकतात. खालील वापराच्या प्रकरणांसाठी काही रेडिओ तयार करण्याचा आमचा मानस आहे (किंवा रेडिओ तयार करू इच्छिणाऱ्या इतर विकासकांना/संघांना समर्थन पुरवणे):
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
+- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
+- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
+- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+
+### Learn More
+
+तुम्हाला ग्राफकास्टबद्दल अधिक जाणून घ्यायचे असल्यास, [येथे दस्तऐवजीकरण पहा.](https://docs.graphops.xyz/graphcast/intro)

From f3ed4b44a258cf6bb9ec9510d969407309cca5f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:07 -0500
Subject: [PATCH 1218/3820] New translations graphcast.mdx (Hindi)

---
 .../pages/hi/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/hi/indexing/tooling/graphcast.mdx

diff --git a/website/pages/hi/indexing/tooling/graphcast.mdx b/website/pages/hi/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..beec8cbeeb3f
--- /dev/null
+++ b/website/pages/hi/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: ग्राफकास्ट
+---
+
+## Introduction
+
+क्या कोई ऐसी चीज है जिसे आप स्वचालित तरीके से अपने साथी इंडेक्सर्स से सीखना या साझा करना चाहते हैं, लेकिन यह बहुत अधिक परेशानी है या बहुत अधिक लागत है?
+
+वर्तमान में, अन्य नेटवर्क प्रतिभागियों को सूचना प्रसारित करने की लागत एथेरियम ब्लॉकचेन पर गैस शुल्क द्वारा निर्धारित की जाती है। ग्राफकास्ट एक वैकल्पिक विकेन्द्रीकृत, वितरित पीयर-टू-पीयर (पी2पी) संचार उपकरण के रूप में कार्य करके इस समस्या को हल करता है जो पूरे नेटवर्क में इंडेक्सर्स को वास्तविक समय में सूचनाओं का आदान-प्रदान करने की अनुमति देता है। P2P संदेशों के आदान-प्रदान की लागत शून्य के करीब है, जिसमें डेटा अखंडता की कोई गारंटी नहीं है। फिर भी, ग्राफकास्ट का उद्देश्य प्रतिष्ठा मॉडल के खुले डिजाइन स्थान के साथ संदेश वैधता गारंटी प्रदान करना है (यानी कि संदेश वैध है और ज्ञात प्रोटोकॉल प्रतिभागी द्वारा हस्ताक्षरित है)।
+
+ग्राफकास्ट एसडीके (सॉफ्टवेयर डेवलपमेंट किट) डेवलपर्स को रेडियो बनाने की अनुमति देता है, जो गपशप-संचालित अनुप्रयोग हैं जो इंडेक्सर्स किसी दिए गए उद्देश्य को पूरा करने के लिए चला सकते हैं। हम निम्नलिखित उपयोग के मामलों के लिए कुछ रेडियो बनाने का भी इरादा रखते हैं (या अन्य डेवलपर्स/टीमों को सहायता प्रदान करते हैं जो रेडियो बनाना चाहते हैं):
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- अन्य इंडेक्सर्स से ताना सिंकिंग सबग्राफ, सबस्ट्रीम और फायरहोज डेटा के लिए नीलामी और समन्वय आयोजित करना।
+- सक्रिय क्वेरी एनालिटिक्स पर स्व-रिपोर्टिंग, जिसमें सबग्राफ अनुरोध मात्रा, शुल्क मात्रा आदि शामिल हैं।
+- इंडेक्सिंग एनालिटिक्स पर सेल्फ-रिपोर्टिंग, जिसमें सबग्राफ इंडेक्सिंग टाइम, हैंडलर गैस कॉस्ट, इंडेक्सिंग एरर, आदि शामिल हैं।
+- ग्राफ-नोड संस्करण, पोस्टग्रेज संस्करण, एथेरियम क्लाइंट संस्करण, आदि सहित स्टैक जानकारी पर स्व-रिपोर्टिंग।
+
+### और अधिक जानें
+
+यदि आप ग्राफ़कास्ट के बारे में अधिक जानना चाहते हैं, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From b9982c586ea8cdf8195d1186bde845761459fdbf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:08 -0500
Subject: [PATCH 1219/3820] New translations graphcast.mdx (Swahili)

---
 .../pages/sw/indexing/tooling/graphcast.mdx   | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/sw/indexing/tooling/graphcast.mdx

diff --git a/website/pages/sw/indexing/tooling/graphcast.mdx b/website/pages/sw/indexing/tooling/graphcast.mdx
new file mode 100644
index 000000000000..4072877a1257
--- /dev/null
+++ b/website/pages/sw/indexing/tooling/graphcast.mdx
@@ -0,0 +1,21 @@
+---
+title: Graphcast
+---
+
+## Introduction
+
+Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+
+Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+
+The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+
+- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
+- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
+- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
+- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+
+### Learn More
+
+If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From 8c88e5ef8d340256aa175604301c04e6a253d01c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:09 -0500
Subject: [PATCH 1220/3820] New translations benefits.mdx (Romanian)

---
 website/pages/ro/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/ro/resources/benefits.mdx

diff --git a/website/pages/ro/resources/benefits.mdx b/website/pages/ro/resources/benefits.mdx
new file mode 100644
index 000000000000..eea83da90bbc
--- /dev/null
+++ b/website/pages/ro/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Here is an analysis:
+
+## Why You Should Use The Graph Network
+
+- Significantly lower monthly costs
+- $0 infrastructure setup costs
+- Superior uptime
+- Access to hundreds of independent Indexers around the world
+- 24/7 technical support by global community
+
+## The Benefits Explained
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|        Cost Comparison       |               Self Hosted               |                        Rețeaua The Graph                        |
+| :--------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |              $350 per month             |                                $0                               |
+|          Query costs         |                   $0+                   |                           $0 per month                          |
+| Engineering time<sup>†</sup> |              $400 per month             | None, built into the network with globally distributed Indexers |
+|       Queries per month      |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                    $0                   |                          $0<sup>‡</sup>                         |
+|        Infrastructure        |               Centralized               |                          Decentralized                          |
+|     Geographic redundancy    |        $750+ per additional node        |                             Included                            |
+|            Uptime            |                  Varies                 |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" />$750+ |                                $0                               |
+
+## Medium Volume User (~3M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                |                        Rețeaua The Graph                        |
+| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |               $350 per month               |                                $0                               |
+|          Query costs         |               $500 per month               |                          $120 per month                         |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities       |                            ~3,000,000                           |
+|        Cost per query        |                     $0                     |                             $0.00004                            |
+|        Infrastructure        |                 Centralized                |                          Decentralized                          |
+|      Engineering expense     |                $200 per hour               |                             Included                            |
+|     Geographic redundancy    |  $1,200 in total costs per additional node |                             Included                            |
+|            Uptime            |                   Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $1,650+ |                               $120                              |
+
+## High Volume User (~30M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                 |                        Rețeaua The Graph                        |
+| :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |          $1100 per month, per node          |                                $0                               |
+|          Query costs         |                    $4000                    |                         $1,200 per month                        |
+|    Number of nodes needed    |                      10                     |                          Not applicable                         |
+| Engineering time<sup>†</sup> |           $6,000 or more per month          | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                      $0                     |                             $0.00004                            |
+|        Infrastructure        |                 Centralized                 |                          Decentralized                          |
+|     Geographic redundancy    |  $1,200 in total costs per additional node  |                             Included                            |
+|            Uptime            |                    Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+
+\*including costs for backup: $50-$100 per month
+
+<sup>†</sup>Engineering time based on $200 per hour assumption
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 57a4fa085c31cfec95d33ad276f0f99e18a13608 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:10 -0500
Subject: [PATCH 1221/3820] New translations benefits.mdx (French)

---
 website/pages/fr/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/fr/resources/benefits.mdx

diff --git a/website/pages/fr/resources/benefits.mdx b/website/pages/fr/resources/benefits.mdx
new file mode 100644
index 000000000000..b233bb058c89
--- /dev/null
+++ b/website/pages/fr/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+Le réseau décentralisé de The Graph a été conçu et affiné pour créer une expérience d'indexation et d'interrogation robuste, et il s'améliore chaque jour grâce à des milliers de contributeurs à travers le monde.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Voici une analyse :
+
+## Pourquoi devriez-vous utiliser le réseau Graph
+
+- Des coûts mensuels nettement réduits
+- 0 $ de frais de configuration de l'infrastructure
+- Disponibilité supérieure
+- Accès à des centaines d’indexeurs indépendants à travers le monde
+- Assistance technique 24h/24 et 7j/7 par la communauté mondiale
+
+## Les avantages expliqués
+
+### Lower & more Flexible Cost Structure
+
+Pas de contrat. Pas de frais mensuels. Vous ne payez que pour les requêtes que vous utilisez, avec un coût moyen par requête de 40 $ par million de requêtes (~0,00004 $ par requête). Les requêtes sont facturées en USD et payées en GRT ou par carte de crédit.
+
+Les coûts d'interrogation peuvent varier ; le coût indiqué est la moyenne au moment de la publication (mars 2024).
+
+## Utilisateur à faible volume (moins de 100 000 requêtes par mois)
+
+|         Cost Comparison        |               Auto-hébergé              |                              The Graph Network                              |
+| :----------------------------: | :-------------------------------------: | :-------------------------------------------------------------------------: |
+|    Coût mensuel du serveur\*   |              350 $ au mois              |                                     0 $                                     |
+|        Frais de requête        |                  - 0 $                  |                                 0$ par mois                                 |
+| Temps d'ingénierie<sup>†</sup> |              400 $ au mois              | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
+|        Requêtes au mois        |        Limité aux capacités infra       |                            100 000 (Plan Gratuit)                           |
+|        Tarif par requête       |                   0 $                   |                                0$<sup>‡</sup>                               |
+|         Infrastructure         |               Centralisée               |                                Décentralisée                                |
+|   La redondance géographique   |      750$+ par nœud complémentaire      |                                   Compris                                   |
+|     Temps de disponibilité     |                 Variable                |                                   - 99.9%                                   |
+|    Total des coûts mensuels    | <span className="highlight-row" />$750+ |                                     0 $                                     |
+
+## Utilisateur à volume moyen (~3M requêtes par mois)
+
+|         Cost Comparison        |                Auto-hébergé                |                              The Graph Network                              |
+| :----------------------------: | :----------------------------------------: | :-------------------------------------------------------------------------: |
+|    Coût mensuel du serveur\*   |                350 $ au mois               |                                     0 $                                     |
+|        Frais de requête        |                500 $ au mois               |                                120$ par mois                                |
+| Temps d'ingénierie<sup>†</sup> |                800 $ au mois               | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
+|        Requêtes au mois        |         Limité aux capacités infra         |                                  ~3,000,000                                 |
+|        Tarif par requête       |                     0 $                    |                                   $0.00004                                  |
+|         Infrastructure         |                 Centralisée                |                                Décentralisée                                |
+|       Frais d'ingénierie       |                200 $ au mois               |                                   Compris                                   |
+|   La redondance géographique   | 1 200 $ coût total par nœud supplémentaire |                                   Compris                                   |
+|     Temps de disponibilité     |                  Variable                  |                                   - 99.9%                                   |
+|    Total des coûts mensuels    | <span className="highlight-row" /> $1,650+ |                                     120$                                    |
+
+## Utilisateur à volume élevé (~30M requêtes par mois)
+
+|         Cost Comparison        |                 Auto-hébergé                |                              The Graph Network                              |
+| :----------------------------: | :-----------------------------------------: | :-------------------------------------------------------------------------: |
+|    Coût mensuel du serveur\*   |           1100 $ au mois, par nœud          |                                     0 $                                     |
+|        Frais de requête        |                    4000 $                   |                               1 200 $ par mois                              |
+|  Nombre de nœuds obligatoires  |                      10                     |                                  Sans objet                                 |
+| Temps d'ingénierie<sup>†</sup> |            6000 $ ou plus au mois           | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
+|        Requêtes au mois        |          Limité aux capacités infra         |                                 ~30,000,000                                 |
+|        Tarif par requête       |                     0 $                     |                                   $0.00004                                  |
+|         Infrastructure         |                 Centralisée                 |                                Décentralisée                                |
+|   La redondance géographique   |  1 200 $ coût total par nœud supplémentaire |                                   Compris                                   |
+|     Temps de disponibilité     |                   Variable                  |                                   - 99.9%                                   |
+|    Total des coûts mensuels    | <span className="highlight-row" /> $11,000+ |                                    1,200$                                   |
+
+\*y compris les coûts de sauvegarde : $50-$ à 100 dollars au mois
+
+<sup>†</sup>Temps d'ingénierie basé sur une hypothèse de 200 $ de l'heure
+
+<sup>‡</sup>Reflète le coût pour le consommateur de données. Les frais de requête sont toujours payés aux Indexeurs pour les requêtes du Plan Gratuit.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Émettre un signal sur un subgraph est un cout net, nul optionnel et unique (par exemple, 1 000 $ de signal peuvent être conservés sur un subgraph, puis retirés - avec la possibilité de gagner des revenus au cours du processus).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Commencez tout de suite, sans installation, sans frais généraux et sans matériel. De plus, vous n'avez pas à vous soucier des temps d'arrêt dus à une infrastructure centralisée, ce qui vous laisse plus de temps pour vous concentrer sur votre produit principal. Vous n'avez pas non plus besoin de serveurs de secours, de dépannage ou d'autres ressources techniques coûteuses.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From d0373a9ec8f2b7f099bc256f70127ff9281df7e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:11 -0500
Subject: [PATCH 1222/3820] New translations benefits.mdx (Spanish)

---
 website/pages/es/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/es/resources/benefits.mdx

diff --git a/website/pages/es/resources/benefits.mdx b/website/pages/es/resources/benefits.mdx
new file mode 100644
index 000000000000..ee665d56a5b6
--- /dev/null
+++ b/website/pages/es/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+La red descentralizada de The Graph ha sido diseñada y refinada para crear una experiencia sólida de indexación y consulta, y está mejorando cada día gracias a miles de contribuyentes en todo el mundo.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Aqui hay un analisis:
+
+## Por qué deberías usar The Graph Network
+
+- Significantly lower monthly costs
+- Costos de configuración de infraestructura de $0
+- Tiempo de actividad superior
+- Access to hundreds of independent Indexers around the world
+- Soporte técnico 24/7 por parte de la comunidad global
+
+## Los beneficios explicados
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|       Comparación de costos      |                Self Hosted                |                           The Graph Network                           |
+| :------------------------------: | :---------------------------------------: | :-------------------------------------------------------------------: |
+|   Costo mensual del servidor\*   |                $350 por mes               |                                   $0                                  |
+|        Costos de consulta        |                    $0+                    |                              $0 per month                             |
+| Tiempo de ingeniería<sup>†</sup> |                $400 por mes               | Ninguno, integrado en la red con Indexadores distribuidos globalmente |
+|         Consultas por mes        | Limitado a capacidades de infraestructura |                          100,000 (Free Plan)                          |
+|        Costo por consulta        |                     $0                    |                             $0<sup>‡</sup>                            |
+|          Infraestructura         |                Centralizado               |                            Descentralizado                            |
+|      Redundancia geográfica      |          $750+ por nodo adicional         |                                Incluido                               |
+|        Tiempo de actividad       |                   Varía                   |                                 99.9%+                                |
+|     Costos mensuales totales     |  <span className="highlight-row" />$750+  |                                   $0                                  |
+
+## Medium Volume User (~3M queries per month)
+
+|       Comparación de costos      |                 Self Hosted                 |                           The Graph Network                           |
+| :------------------------------: | :-----------------------------------------: | :-------------------------------------------------------------------: |
+|   Costo mensual del servidor\*   |                 $350 por mes                |                                   $0                                  |
+|        Costos de consulta        |                 $500 por mes                |                             $120 per month                            |
+| Tiempo de ingeniería<sup>†</sup> |                 $800 por mes                | Ninguno, integrado en la red con Indexadores distribuidos globalmente |
+|         Consultas por mes        |  Limitado a capacidades de infraestructura  |                               ~3,000,000                              |
+|        Costo por consulta        |                      $0                     |                                $0.00004                               |
+|          Infraestructura         |                 Centralizado                |                            Descentralizado                            |
+|       Gastos de ingeniería       |                $200 por hora                |                                Incluido                               |
+|      Redundancia geográfica      | $1,200 en costos totales por nodo adicional |                                Incluido                               |
+|        Tiempo de actividad       |                    Varía                    |                                 99.9%+                                |
+|     Costos mensuales totales     |  <span className="highlight-row" /> $1,650+ |                                  $120                                 |
+
+## High Volume User (~30M queries per month)
+
+|       Comparación de costos      |                 Self Hosted                 |                           The Graph Network                           |
+| :------------------------------: | :-----------------------------------------: | :-------------------------------------------------------------------: |
+|   Costo mensual del servidor\*   |           $1100 por mes, por nodo           |                                   $0                                  |
+|        Costos de consulta        |                    $4000                    |                            $1,200 per month                           |
+|    Número de nodos necesarios    |                      10                     |                               No aplica                               |
+| Tiempo de ingeniería<sup>†</sup> |             $6,000 o más por mes            | Ninguno, integrado en la red con Indexadores distribuidos globalmente |
+|         Consultas por mes        |  Limitado a capacidades de infraestructura  |                              ~30,000,000                              |
+|        Costo por consulta        |                      $0                     |                                $0.00004                               |
+|          Infraestructura         |                 Centralizado                |                            Descentralizado                            |
+|      Redundancia geográfica      | $1,200 en costos totales por nodo adicional |                                Incluido                               |
+|        Tiempo de actividad       |                    Varía                    |                                 99.9%+                                |
+|     Costos mensuales totales     | <span className="highlight-row" /> $11,000+ |                                 $1,200                                |
+
+\*incluidos los costos de copia de seguridad: $50-$100 por mes
+
+<sup>†</sup>Tiempo de ingeniería basado en un supuesto de $200 por hora
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+La señal de curación en un subgrafo es una acción opcional de única vez y no tiene costo neto (por ejemplo, se pueden curar $1k en señales en un subgrafo y luego retirarlas, con el potencial de obtener retornos en el proceso).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Tarifas de instalación cero. Comienza de inmediato sin costos generales ni de instalación. Sin requisitos de hardware. Sin interrupciones debido a la infraestructura centralizada y más tiempo para concentrarte en tu producto principal. No se necesitan servidores de respaldo, resolución de problemas ni costosos recursos de ingeniería.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 42ad7ade876454af5c84d332f0ef747a92bd60e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:12 -0500
Subject: [PATCH 1223/3820] New translations benefits.mdx (Arabic)

---
 website/pages/ar/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/ar/resources/benefits.mdx

diff --git a/website/pages/ar/resources/benefits.mdx b/website/pages/ar/resources/benefits.mdx
new file mode 100644
index 000000000000..12756a15ceca
--- /dev/null
+++ b/website/pages/ar/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Here is an analysis:
+
+## Why You Should Use The Graph Network
+
+- Significantly lower monthly costs
+- $0 infrastructure setup costs
+- Superior uptime
+- Access to hundreds of independent Indexers around the world
+- 24/7 technical support by global community
+
+## The Benefits Explained
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|        Cost Comparison       |               Self Hosted               |                        The Graph Network                        |
+| :--------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |              $350 per month             |                                $0                               |
+|          Query costs         |                   $0+                   |                           $0 per month                          |
+| Engineering time<sup>†</sup> |              $400 per month             | None, built into the network with globally distributed Indexers |
+|       Queries per month      |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                    $0                   |                          $0<sup>‡</sup>                         |
+|        البنية الأساسية       |               Centralized               |                          Decentralized                          |
+|     Geographic redundancy    |        $750+ per additional node        |                             Included                            |
+|            Uptime            |                  Varies                 |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" />$750+ |                                $0                               |
+
+## Medium Volume User (~3M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                |                        The Graph Network                        |
+| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |               $350 per month               |                                $0                               |
+|          Query costs         |               $500 per month               |                          $120 per month                         |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities       |                            ~3,000,000                           |
+|        Cost per query        |                     $0                     |                             $0.00004                            |
+|        البنية الأساسية       |                 Centralized                |                          Decentralized                          |
+|      Engineering expense     |                $200 per hour               |                             Included                            |
+|     Geographic redundancy    |  $1,200 in total costs per additional node |                             Included                            |
+|            Uptime            |                   Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $1,650+ |                               $120                              |
+
+## High Volume User (~30M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                 |                        The Graph Network                        |
+| :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |          $1100 per month, per node          |                                $0                               |
+|          Query costs         |                    $4000                    |                         $1,200 per month                        |
+|    Number of nodes needed    |                      10                     |                          Not applicable                         |
+| Engineering time<sup>†</sup> |           $6,000 or more per month          | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                      $0                     |                             $0.00004                            |
+|        البنية الأساسية       |                 Centralized                 |                          Decentralized                          |
+|     Geographic redundancy    |  $1,200 in total costs per additional node  |                             Included                            |
+|            Uptime            |                    Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+
+\*including costs for backup: $50-$100 per month
+
+<sup>†</sup>Engineering time based on $200 per hour assumption
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 44298b975987e5ba5ad51990715eec724835b6b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:13 -0500
Subject: [PATCH 1224/3820] New translations benefits.mdx (Czech)

---
 website/pages/cs/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/cs/resources/benefits.mdx

diff --git a/website/pages/cs/resources/benefits.mdx b/website/pages/cs/resources/benefits.mdx
new file mode 100644
index 000000000000..d0a916cdb5ca
--- /dev/null
+++ b/website/pages/cs/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+Decentralizovaná síť Grafu byla navržena a zdokonalena tak, aby umožňovala robustní indexování a dotazování - a díky tisícům přispěvatelů z celého světa se každým dnem zlepšuje.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Zde je analýza:
+
+## Proč byste měli používat síť Graf
+
+- Significantly lower monthly costs
+- Náklady na zřízení infrastruktury ve výši $0
+- Vynikající doba provozu
+- Přístup ke stovkám nezávislých indexátorů po celém světě
+- 24/7 technická podpora globální komunity
+
+## Vysvětlení výhod
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|       Srovnání nákladů      |             Vlastní hostitel            |                       The Graph Network                       |
+| :-------------------------: | :-------------------------------------: | :-----------------------------------------------------------: |
+| Měsíční náklady na server\* |               $350 měsíčně              |                               $0                              |
+|    Náklady na dotazování    |                   $0+                   |                          $0 per month                         |
+|  Inženýrský čas<sup>†</sup> |               $400 měsíčně              | Žádné, zabudované do sítě s globálně distribuovanými indexery |
+|       Dotazy za měsíc       |       Omezeno na infra schopnosti       |                      100,000 (Free Plan)                      |
+|    Náklady na jeden dotaz   |                    $0                   |                         $0<sup>‡</sup>                        |
+|        Infrastruktura       |              Centralizovaný             |                        Decentralizované                       |
+|    Geografická redundancy   |         $750+ Usd za další uzel         |                            Zahrnuto                           |
+|       Provozuschopnost      |                  Různé                  |                             99.9%+                            |
+|   Celkové měsíční náklady   | <span className="highlight-row" />$750+ |                               $0                              |
+
+## Medium Volume User (~3M queries per month)
+
+|       Srovnání nákladů      |              Vlastní hostitel              |                       The Graph Network                       |
+| :-------------------------: | :----------------------------------------: | :-----------------------------------------------------------: |
+| Měsíční náklady na server\* |                $350 měsíčně                |                               $0                              |
+|    Náklady na dotazování    |                $500 měsíčně                |                         $120 per month                        |
+|  Inženýrský čas<sup>†</sup> |                $800 měsíčně                | Žádné, zabudované do sítě s globálně distribuovanými indexery |
+|       Dotazy za měsíc       |         Omezeno na infra schopnosti        |                           ~3,000,000                          |
+|    Náklady na jeden dotaz   |                     $0                     |                            $0.00004                           |
+|        Infrastruktura       |               Centralizovaný               |                        Decentralizované                       |
+|      Výdaje inženýrskou     |               $200 za hodinu               |                            Zahrnuto                           |
+|    Geografická redundancy   |   $1,200 celkových nákladů na další uzel   |                            Zahrnuto                           |
+|       Provozuschopnost      |                    Různé                   |                             99.9%+                            |
+|   Celkové měsíční náklady   | <span className="highlight-row" /> $1,650+ |                              $120                             |
+
+## High Volume User (~30M queries per month)
+
+|       Srovnání nákladů      |               Vlastní hostitel              |                       The Graph Network                       |
+| :-------------------------: | :-----------------------------------------: | :-----------------------------------------------------------: |
+| Měsíční náklady na server\* |            $1100 měsíčně za uzel            |                               $0                              |
+|    Náklady na dotazování    |                    $4000                    |                        $1,200 per month                       |
+|    Počet potřebných uzlů    |                      10                     |                          Nepoužije se                         |
+|  Inženýrský čas<sup>†</sup> |          6$, 000 nebo více měsíčně          | Žádné, zabudované do sítě s globálně distribuovanými indexery |
+|       Dotazy za měsíc       |         Omezeno na infra schopnosti         |                          ~30,000,000                          |
+|    Náklady na jeden dotaz   |                      $0                     |                            $0.00004                           |
+|        Infrastruktura       |                Centralizovaný               |                        Decentralizované                       |
+|    Geografická redundancy   |    $1,200 celkových nákladů na další uzel   |                            Zahrnuto                           |
+|       Provozuschopnost      |                    Různé                    |                             99.9%+                            |
+|   Celkové měsíční náklady   | <span className="highlight-row" /> $11,000+ |                             $1,200                            |
+
+\*včetně nákladů na zálohování: $50-$100 měsíčně
+
+<sup>†</sup>Inženýrský čas na základě předpokladu $200 za hodinu
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Kurátorování signálu na podgrafu je volitelný jednorázový čistý nulový náklad (např. na podgrafu lze kurátorovat signál v hodnotě $1k a později jej stáhnout - s potenciálem získat v tomto procesu výnosy).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Nulové instalační poplatky. Začněte ihned pracovat bez jakýchkoli nákladů na zřízení nebo režijních nákladů. Žádné hardwarové požadavky. Žádné výpadky kvůli centralizované infrastruktuře a více času na soustředění se na váš hlavní produkt . Žádná potřeba záložních serverů, řešení problémů nebo drahých technických zdrojů.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From d54f8d83f191bdb1b9b9d2af6770210c59ccc8f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:14 -0500
Subject: [PATCH 1225/3820] New translations benefits.mdx (German)

---
 website/pages/de/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/de/resources/benefits.mdx

diff --git a/website/pages/de/resources/benefits.mdx b/website/pages/de/resources/benefits.mdx
new file mode 100644
index 000000000000..c035f6636b1b
--- /dev/null
+++ b/website/pages/de/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Here is an analysis:
+
+## Why You Should Use The Graph Network
+
+- Significantly lower monthly costs
+- $0 infrastructure setup costs
+- Superior uptime
+- Access to hundreds of independent Indexers around the world
+- 24/7 technical support by global community
+
+## The Benefits Explained
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|        Cost Comparison       |               Self Hosted               |                        The Graph Network                        |
+| :--------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |              $350 per month             |                                $0                               |
+|          Query costs         |                   $0+                   |                           $0 per month                          |
+| Engineering time<sup>†</sup> |              $400 per month             | None, built into the network with globally distributed Indexers |
+|       Queries per month      |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                    $0                   |                          $0<sup>‡</sup>                         |
+|         Infrastruktur        |               Centralized               |                          Decentralized                          |
+|     Geographic redundancy    |        $750+ per additional node        |                             Included                            |
+|            Uptime            |                  Varies                 |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" />$750+ |                                $0                               |
+
+## Medium Volume User (~3M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                |                        The Graph Network                        |
+| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |               $350 per month               |                                $0                               |
+|          Query costs         |               $500 per month               |                          $120 per month                         |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities       |                            ~3,000,000                           |
+|        Cost per query        |                     $0                     |                             $0.00004                            |
+|         Infrastruktur        |                 Centralized                |                          Decentralized                          |
+|      Engineering expense     |                $200 per hour               |                             Included                            |
+|     Geographic redundancy    |  $1,200 in total costs per additional node |                             Included                            |
+|            Uptime            |                   Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $1,650+ |                               $120                              |
+
+## High Volume User (~30M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                 |                        The Graph Network                        |
+| :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |          $1100 per month, per node          |                                $0                               |
+|          Query costs         |                    $4000                    |                         $1,200 per month                        |
+|    Number of nodes needed    |                      10                     |                          Not applicable                         |
+| Engineering time<sup>†</sup> |           $6,000 or more per month          | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                      $0                     |                             $0.00004                            |
+|         Infrastruktur        |                 Centralized                 |                          Decentralized                          |
+|     Geographic redundancy    |  $1,200 in total costs per additional node  |                             Included                            |
+|            Uptime            |                    Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+
+\*including costs for backup: $50-$100 per month
+
+<sup>†</sup>Engineering time based on $200 per hour assumption
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 31be3caac6f592e1540eee1c9c00b71bc4fcd17d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:15 -0500
Subject: [PATCH 1226/3820] New translations benefits.mdx (Italian)

---
 website/pages/it/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/it/resources/benefits.mdx

diff --git a/website/pages/it/resources/benefits.mdx b/website/pages/it/resources/benefits.mdx
new file mode 100644
index 000000000000..da8330a62c99
--- /dev/null
+++ b/website/pages/it/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+La rete decentralizzata di The Graph è stata progettata e perfezionata per creare una solida esperienza di indicizzazione e query, e migliora ogni giorno grazie a migliaia di collaboratori in tutto il mondo.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Ecco l'analisi:
+
+## Perché si dovrebbe usare The Graph Network
+
+- Significantly lower monthly costs
+- $0 di costi di installazione dell'infrastruttura
+- Tempo di attività superiore
+- Access to hundreds of independent Indexers around the world
+- Assistenza tecnica 24/7 da parte della comunità globale
+
+## I vantaggi spiegati
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|           Confronto costi          |               Self Hosted               |                               The Graph Network                               |
+| :--------------------------------: | :-------------------------------------: | :---------------------------------------------------------------------------: |
+|     Costo mensile del server\*     |               $350 al mese              |                                       $0                                      |
+|           Costi di query           |                   $0+                   |                                  $0 per month                                 |
+| Tempo di progettazione<sup>†</sup> |               $400 al mese              | Nessuno, integrato nella rete con indicizzatori distribuiti a livello globale |
+|            Query al mese           |     Limitato alle capacità di infra     |                              100,000 (Free Plan)                              |
+|           Costo per query          |                    $0                   |                                 $0<sup>‡</sup>                                |
+|           Infrastruttura           |              Centralizzato              |                                Decentralizzato                                |
+|        Ridondanza geografica       |        $750+ per nodo aggiuntivo        |                                    Incluso                                    |
+|          Tempo di attività         |                Variabile                |                                     99.9%+                                    |
+|        Costo totale mensile        | <span className="highlight-row" />$750+ |                                       $0                                      |
+
+## Medium Volume User (~3M queries per month)
+
+|           Confronto costi          |                 Self Hosted                |                               The Graph Network                               |
+| :--------------------------------: | :----------------------------------------: | :---------------------------------------------------------------------------: |
+|     Costo mensile del server\*     |                $350 al mese                |                                       $0                                      |
+|           Costi di query           |                $500 al mese                |                                 $120 per month                                |
+| Tempo di progettazione<sup>†</sup> |                $800 al mese                | Nessuno, integrato nella rete con indicizzatori distribuiti a livello globale |
+|            Query al mese           |       Limitato alle capacità di infra      |                                   ~3,000,000                                  |
+|           Costo per query          |                     $0                     |                                    $0.00004                                   |
+|           Infrastruttura           |                Centralizzato               |                                Decentralizzato                                |
+|         Costi di ingegneria        |                $200 all'ora                |                                    Incluso                                    |
+|        Ridondanza geografica       | $1.200 di costi totali per nodo aggiuntivo |                                    Incluso                                    |
+|          Tempo di attività         |                  Variabile                 |                                     99.9%+                                    |
+|        Costo totale mensile        | <span className="highlight-row" /> $1,650+ |                                      $120                                     |
+
+## High Volume User (~30M queries per month)
+
+|           Confronto costi          |                 Self Hosted                 |                               The Graph Network                               |
+| :--------------------------------: | :-----------------------------------------: | :---------------------------------------------------------------------------: |
+|     Costo mensile del server\*     |           $1100 al mese, per nodo           |                                       $0                                      |
+|           Costi di query           |                    $4000                    |                                $1,200 per month                               |
+|      Numero di nodi necessari      |                      10                     |                                Non applicabile                                |
+| Tempo di progettazione<sup>†</sup> |             $6.000 o più al mese            | Nessuno, integrato nella rete con indicizzatori distribuiti a livello globale |
+|            Query al mese           |       Limitato alle capacità di infra       |                                  ~30,000,000                                  |
+|           Costo per query          |                      $0                     |                                    $0.00004                                   |
+|           Infrastruttura           |                Centralizzato                |                                Decentralizzato                                |
+|        Ridondanza geografica       |  $1.200 di costi totali per nodo aggiuntivo |                                    Incluso                                    |
+|          Tempo di attività         |                  Variabile                  |                                     99.9%+                                    |
+|        Costo totale mensile        | <span className="highlight-row" /> $11,000+ |                                     $1,200                                    |
+
+\*inclusi i costi per il backup: $50-$100 al mese
+
+<sup>†</sup> Tempo di progettazione basato su un'ipotesi di $200 all'ora
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+La curation del segnale su un subgraph è opzionale, una tantum, a costo zero (ad esempio, $1.000 in segnale possono essere curati su un subgraph e successivamente ritirati, con un potenziale di guadagno nel processo).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Zero costi di configurazione. Iniziate subito senza costi di configurazione o spese generali. Nessun requisito hardware. Nessuna interruzione a causa dell'infrastruttura centralizzata, e più tempo per concentrarsi sul prodotto principale. Non sono necessari i server di backup, risoluzione dei problemi o risorse ingegneristiche costose.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From d5972cafa8b4ea8ba351de5a6be4f3104f374ee4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:16 -0500
Subject: [PATCH 1227/3820] New translations benefits.mdx (Japanese)

---
 website/pages/ja/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/ja/resources/benefits.mdx

diff --git a/website/pages/ja/resources/benefits.mdx b/website/pages/ja/resources/benefits.mdx
new file mode 100644
index 000000000000..731131e7cdc2
--- /dev/null
+++ b/website/pages/ja/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+Graph の分散型ネットワークは、堅牢なインデックス作成とクエリのエクスペリエンスを作成するために設計および改良されており、世界中の何千人もの貢献者のおかげで、毎日改善されています。
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+ここに分析があります：
+
+## グラフネットワークを使うべき理由
+
+- Significantly lower monthly costs
+- インフラ構築費用0ドル
+- 優れたアップタイム
+- 世界中の数百の独立系インデクサーへのアクセス
+- グローバルコミュニティによる24時間365日の技術サポート
+
+## 以下に利点を説明します
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|          コスト比較          |                  セルフホスト                 |              グラフネットワーク              |
+| :---------------------: | :-------------------------------------: | :---------------------------------: |
+|         月額サーバー代         |                  $350/月                 |                  $0                 |
+|          クエリコスト         |                   $0+                   |             $0 per month            |
+| エンジニアリングタイム<sup>†</sup> |                  $400/月                 | なし/ グローバルに分散されたインデクサーでネットワークに組み込まれる |
+|         月ごとのクエリ         |                インフラ機能に限定                |         100,000 (Free Plan)         |
+|        クエリごとのコスト        |                    $0                   |            $0<sup>‡</sup>           |
+|        インフラストラクチャ       |                  集中管理型                  |                 分散型                 |
+|         地理的な冗長性         |              追加1ノードにつき$750+             |                 含まれる                |
+|          アップタイム         |                 バリエーション                 |                99.9%+               |
+|          月額費用合計         | <span className="highlight-row" />$750+ |                  $0                 |
+
+## Medium Volume User (~3M queries per month)
+
+|          コスト比較          |                   セルフホスト                   |              グラフネットワーク              |
+| :---------------------: | :----------------------------------------: | :---------------------------------: |
+|         月額サーバー代         |                   $350/月                   |                  $0                 |
+|          クエリコスト         |                   $500/月                   |            $120 per month           |
+| エンジニアリングタイム<sup>†</sup> |                   $800/月                   | なし/ グローバルに分散されたインデクサーでネットワークに組み込まれる |
+|         月ごとのクエリ         |                  インフラ機能に限定                 |              ~3,000,000             |
+|        クエリごとのコスト        |                     $0                     |               $0.00004              |
+|        インフラストラクチャ       |                    集中管理型                   |                 分散型                 |
+|       エンジニアリングコスト       |                   $200/時                   |                 含まれる                |
+|         地理的な冗長性         |             ノード追加1台につき合計1,200ドル            |                 含まれる                |
+|          アップタイム         |                   バリエーション                  |                99.9%+               |
+|          月額費用合計         | <span className="highlight-row" /> $1,650+ |                 $120                |
+
+## High Volume User (~30M queries per month)
+
+|          コスト比較          |                    セルフホスト                   |              グラフネットワーク              |
+| :---------------------: | :-----------------------------------------: | :---------------------------------: |
+|         月額サーバー代         |                $1100/月（ノードごと）               |                  $0                 |
+|          クエリコスト         |                    $4000                    |           $1,200 per month          |
+|          必要ノード数         |                      10                     |                 該当なし                |
+| エンジニアリングタイム<sup>†</sup> |                   $6,000/月                  | なし/ グローバルに分散されたインデクサーでネットワークに組み込まれる |
+|         月ごとのクエリ         |                  インフラ機能に限定                  |             ~30,000,000             |
+|        クエリごとのコスト        |                      $0                     |               $0.00004              |
+|        インフラストラクチャ       |                    集中管理型                    |                 分散型                 |
+|         地理的な冗長性         |             ノード追加1台につき合計1,200ドル             |                 含まれる                |
+|          アップタイム         |                   バリエーション                   |                99.9%+               |
+|          月額費用合計         | <span className="highlight-row" /> $11,000+ |                $1,200               |
+
+\*バックアップ費用含む：月額$50〜$100
+
+<sup>†</sup>エンジニアリング・タイム1時間あたり$200の仮定に基づく
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+サブグラフ上のシグナルのキュレーションは、オプションで1回限り、ネットゼロのコストで可能です（例えば、$1,000のシグナルをサブグラフ上でキュレーションし、後で引き出すことができ、その過程でリターンを得る可能性があります）。
+
+## No Setup Costs & Greater Operational Efficiency
+
+セットアップ費用ゼロ。セットアップや諸経費が不要で、すぐに使い始めることができます。ハードウェアは必要ありません。集中管理されたインフラストラクチャによる障害もなく、より多くの時間をコア製品に集中させることができます。バックアップサーバー、トラブルシューティング、高価なエンジニアリングリソースは必要ありません。
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 6770b8f6140648ae92b5abdd4eaa642c953959ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:17 -0500
Subject: [PATCH 1228/3820] New translations benefits.mdx (Korean)

---
 website/pages/ko/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/ko/resources/benefits.mdx

diff --git a/website/pages/ko/resources/benefits.mdx b/website/pages/ko/resources/benefits.mdx
new file mode 100644
index 000000000000..1d4d1ac5ff96
--- /dev/null
+++ b/website/pages/ko/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Here is an analysis:
+
+## Why You Should Use The Graph Network
+
+- Significantly lower monthly costs
+- $0 infrastructure setup costs
+- Superior uptime
+- Access to hundreds of independent Indexers around the world
+- 24/7 technical support by global community
+
+## The Benefits Explained
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|        Cost Comparison       |               Self Hosted               |                          The Graph 네트워크                         |
+| :--------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |              $350 per month             |                                $0                               |
+|          Query costs         |                   $0+                   |                           $0 per month                          |
+| Engineering time<sup>†</sup> |              $400 per month             | None, built into the network with globally distributed Indexers |
+|       Queries per month      |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                    $0                   |                          $0<sup>‡</sup>                         |
+|        Infrastructure        |               Centralized               |                          Decentralized                          |
+|     Geographic redundancy    |        $750+ per additional node        |                             Included                            |
+|            Uptime            |                  Varies                 |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" />$750+ |                                $0                               |
+
+## Medium Volume User (~3M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                |                          The Graph 네트워크                         |
+| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |               $350 per month               |                                $0                               |
+|          Query costs         |               $500 per month               |                          $120 per month                         |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities       |                            ~3,000,000                           |
+|        Cost per query        |                     $0                     |                             $0.00004                            |
+|        Infrastructure        |                 Centralized                |                          Decentralized                          |
+|      Engineering expense     |                $200 per hour               |                             Included                            |
+|     Geographic redundancy    |  $1,200 in total costs per additional node |                             Included                            |
+|            Uptime            |                   Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $1,650+ |                               $120                              |
+
+## High Volume User (~30M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                 |                          The Graph 네트워크                         |
+| :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |          $1100 per month, per node          |                                $0                               |
+|          Query costs         |                    $4000                    |                         $1,200 per month                        |
+|    Number of nodes needed    |                      10                     |                          Not applicable                         |
+| Engineering time<sup>†</sup> |           $6,000 or more per month          | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                      $0                     |                             $0.00004                            |
+|        Infrastructure        |                 Centralized                 |                          Decentralized                          |
+|     Geographic redundancy    |  $1,200 in total costs per additional node  |                             Included                            |
+|            Uptime            |                    Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+
+\*including costs for backup: $50-$100 per month
+
+<sup>†</sup>Engineering time based on $200 per hour assumption
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From c1411d6e03cad146114fdd3b0bd88350ad0af58e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:19 -0500
Subject: [PATCH 1229/3820] New translations benefits.mdx (Dutch)

---
 website/pages/nl/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/nl/resources/benefits.mdx

diff --git a/website/pages/nl/resources/benefits.mdx b/website/pages/nl/resources/benefits.mdx
new file mode 100644
index 000000000000..661af3c47910
--- /dev/null
+++ b/website/pages/nl/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+Het gedecentraliseerde netwerk van The Graph is ontworpen en verfijnd om een robuuste ervaring te creëren bij het indexeren en opvragen van data. Het netwerk wordt iedere dag sterker door de duizenden bijdragers wereldwijd.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Hier is een analyse:
+
+## Waarom jij het Graph Network zou moeten gebruiken
+
+- Significantly lower monthly costs
+- Geen kosten voor het opzetten van infrastructuur
+- Superieure beschikbaarheid
+- Toegang tot honderden onafhankelijke Indexers wereldwijd
+- 24/7 technische ondersteuning door de wereldwijde Graph Netwerk gemeenschap
+
+## De voordelen uitgelegd
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|     Kostenvergelijking     |               Zelf hosten               |                                         De Graph Netwerk                                         |
+| :------------------------: | :-------------------------------------: | :----------------------------------------------------------------------------------------------: |
+|  Maandelijkse serverkosten |              $350 per maand             |                                                $0                                                |
+|         Querykosten        |                   $0+                   |                                           $0 per month                                           |
+| Onderhoud tijd<sup>†</sup> |              $400 per maand             | Geen, deze kosten worden opgevangen door het wereldwijd gedistribueerde netwerk van indexeerders |
+|  Aantal queries per maand  |  Beperkt tot infrastructuurcapaciteiten |                                        100,000 (Free Plan)                                       |
+|      Kosten per query      |                    $0                   |                                          $0<sup>‡</sup>                                          |
+|       Infrastructuur       |             Gecentraliseerd             |                                         Gedecentraliseerd                                        |
+|  Geografische redundantie  |           $750+ per extra node          |                                            Inbegrepen                                            |
+|           Uptime           |                Wisselend                |                                              99,9%+                                              |
+| Totale maandelijkse kosten | <span className="highlight-row" />$750+ |                                                $0                                                |
+
+## Medium Volume User (~3M queries per month)
+
+|      Kostenvergelijking     |                 Zelf hosten                |                                         De Graph Netwerk                                         |
+| :-------------------------: | :----------------------------------------: | :----------------------------------------------------------------------------------------------: |
+|  Maandelijkse serverkosten  |               $350 per maand               |                                                $0                                                |
+|         Querykosten         |               $500 per maand               |                                          $120 per month                                          |
+|  Onderhoud tijd<sup>†</sup> |               $800 per maand               | Geen, deze kosten worden opgevangen door het wereldwijd gedistribueerde netwerk van indexeerders |
+|   Aantal queries per maand  |   Beperkt tot infrastructuurcapaciteiten   |                                            ~3,000,000                                            |
+|       Kosten per query      |                     $0                     |                                             $0.00004                                             |
+|        Infrastructuur       |               Gecentraliseerd              |                                         Gedecentraliseerd                                        |
+| Technische personeelskosten |                $200 per uur                |                                            Inbegrepen                                            |
+|   Geografische redundantie  |     $1200 totale kosten per extra node     |                                            Inbegrepen                                            |
+|            Uptime           |                  Wisselend                 |                                              99,9%+                                              |
+|  Totale maandelijkse kosten | <span className="highlight-row" /> $1,650+ |                                               $120                                               |
+
+## High Volume User (~30M queries per month)
+
+|     Kostenvergelijking     |                 Zelf hosten                 |                                         De Graph Netwerk                                         |
+| :------------------------: | :-----------------------------------------: | :----------------------------------------------------------------------------------------------: |
+|  Maandelijkse serverkosten |          $1100 per maand, per node          |                                                $0                                                |
+|         Querykosten        |                    $4000                    |                                         $1,200 per month                                         |
+|   Aantal benodigde nodes   |                      10                     |                                        Niet van toepassing                                       |
+| Onderhoud tijd<sup>†</sup> |           $6000 of meer per maand           | Geen, deze kosten worden opgevangen door het wereldwijd gedistribueerde netwerk van indexeerders |
+|  Aantal queries per maand  |    Beperkt tot infrastructuurcapaciteiten   |                                            ~30,000,000                                           |
+|      Kosten per query      |                      $0                     |                                             $0.00004                                             |
+|       Infrastructuur       |               Gecentraliseerd               |                                         Gedecentraliseerd                                        |
+|  Geografische redundantie  |      $1200 totale kosten per extra node     |                                            Inbegrepen                                            |
+|           Uptime           |                  Wisselend                  |                                              99,9%+                                              |
+| Totale maandelijkse kosten | <span className="highlight-row" /> $11,000+ |                                              $1,200                                              |
+
+\*inclusief kosten voor een back-up: $50-$100 per maand
+
+<sup>†</sup>Onderhoud tijd gebaseerd op $200 per uur
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Signaal cureren op een subgraph is een optionele eenmalige, kostenneutrale actie (bijv. $1000 aan signaal kan worden gecureerd op een subgraph en later worden opgenomen - met het potentieel om rendementen te verdienen tijdens het proces).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Geen voorafgaande kosten. Begin direct zonder voorafgaande- of overheadkosten. Geen hardwarevereisten. Geen uitval door gecentraliseerde infrastructuur, en meer tijd om je te concentreren op je kernproduct. Geen noodzaak voor back-up servers, probleemoplossing of dure engineeringtijd.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 4bf383dcdd0e6c770599f4de361d3d05b7440047 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:20 -0500
Subject: [PATCH 1230/3820] New translations benefits.mdx (Polish)

---
 website/pages/pl/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/pl/resources/benefits.mdx

diff --git a/website/pages/pl/resources/benefits.mdx b/website/pages/pl/resources/benefits.mdx
new file mode 100644
index 000000000000..8242856b35ec
--- /dev/null
+++ b/website/pages/pl/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Here is an analysis:
+
+## Why You Should Use The Graph Network
+
+- Significantly lower monthly costs
+- $0 infrastructure setup costs
+- Superior uptime
+- Access to hundreds of independent Indexers around the world
+- 24/7 technical support by global community
+
+## The Benefits Explained
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|        Cost Comparison       |               Self Hosted               |                          Sieć The Graph                         |
+| :--------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |              $350 per month             |                                $0                               |
+|          Query costs         |                   $0+                   |                           $0 per month                          |
+| Engineering time<sup>†</sup> |              $400 per month             | None, built into the network with globally distributed Indexers |
+|       Queries per month      |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                    $0                   |                          $0<sup>‡</sup>                         |
+|        Infrastructure        |               Centralized               |                          Decentralized                          |
+|     Geographic redundancy    |        $750+ per additional node        |                             Included                            |
+|            Uptime            |                  Varies                 |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" />$750+ |                                $0                               |
+
+## Medium Volume User (~3M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                |                          Sieć The Graph                         |
+| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |               $350 per month               |                                $0                               |
+|          Query costs         |               $500 per month               |                          $120 per month                         |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities       |                            ~3,000,000                           |
+|        Cost per query        |                     $0                     |                             $0.00004                            |
+|        Infrastructure        |                 Centralized                |                          Decentralized                          |
+|      Engineering expense     |                $200 per hour               |                             Included                            |
+|     Geographic redundancy    |  $1,200 in total costs per additional node |                             Included                            |
+|            Uptime            |                   Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $1,650+ |                               $120                              |
+
+## High Volume User (~30M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                 |                          Sieć The Graph                         |
+| :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |          $1100 per month, per node          |                                $0                               |
+|          Query costs         |                    $4000                    |                         $1,200 per month                        |
+|    Number of nodes needed    |                      10                     |                          Not applicable                         |
+| Engineering time<sup>†</sup> |           $6,000 or more per month          | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                      $0                     |                             $0.00004                            |
+|        Infrastructure        |                 Centralized                 |                          Decentralized                          |
+|     Geographic redundancy    |  $1,200 in total costs per additional node  |                             Included                            |
+|            Uptime            |                    Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+
+\*including costs for backup: $50-$100 per month
+
+<sup>†</sup>Engineering time based on $200 per hour assumption
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 04ba1b9929c1ae2b96eeceabe1468e0ad6765ff6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:21 -0500
Subject: [PATCH 1231/3820] New translations benefits.mdx (Portuguese)

---
 website/pages/pt/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/pt/resources/benefits.mdx

diff --git a/website/pages/pt/resources/benefits.mdx b/website/pages/pt/resources/benefits.mdx
new file mode 100644
index 000000000000..e49e63cfaeb6
--- /dev/null
+++ b/website/pages/pt/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+A rede descentralizada do The Graph é construída e refinada para criar uma experiência robusta de indexação e consultas—e ela melhora diariamente, graças a milhares de contribuintes ao redor do mundo.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Aqui está uma análise:
+
+## Por Que Usar a Graph Network?
+
+- Custos mensais significativamente reduzidos
+- Zero custos de preparação de infraestrutura
+- Mais tempo de disponibilidade
+- Acesso a centenas de Indexadores independentes ao redor do mundo
+- Suporte técnico 24 horas pela comunidade global
+
+## Os Benefícios
+
+### Lower & more Flexible Cost Structure
+
+Nada de contratos ou taxas mensais. Só pague pelos queries que usa — com um custo-por-query de $40 dólares por milhão de queries (cerca de $0.0004 por query). Estes tem preços em Dólar (USD), pagos em GRT ou cartão de crédito.
+
+Os custos de query podem variar; o custo citado é o normal até o fechamento da publicação (Março de 2024).
+
+## Utilizador de Baixo Volume (menos de 100 mil queries por mês)
+
+|       Comparação de Custos      |             Auto-hospedagem             |                         The Graph Network                         |
+| :-----------------------------: | :-------------------------------------: | :---------------------------------------------------------------: |
+|    Custo mensal de servidor\*   |               $350 por mês              |                                 $0                                |
+|         Custos de query         |                   $0+                   |                             $0 por mês                            |
+| Tempo de engenharia<sup>†</sup> |               $400 por mês              | Nenhum, embutido na rede com Indexadores distribuídos globalmente |
+|         Queries por mês         |  Limitadas pelas capabilidades da infra |                       100 mil (Plano Grátis)                      |
+|         Custo por query         |                    $0                   |                           $0<sup>‡</sup>                          |
+|          Infraestutura          |               Centralizada              |                          Descentralizada                          |
+|      Redundância geográfica     |         $750+ por node adicional        |                              Incluída                             |
+|     Uptime (disponibilidade)    |                  Varia                  |                               99.9%+                              |
+|      Custos mensais totais      | <span className="highlight-row" />$750+ |                                 $0                                |
+
+## Utilizador de Volume Médio (cerca de 3 milhões de queries por mês)
+
+|       Comparação de Custos      |               Auto-hospedagem              |                         The Graph Network                         |
+| :-----------------------------: | :----------------------------------------: | :---------------------------------------------------------------: |
+|    Custo mensal de servidor\*   |                $350 por mês                |                                 $0                                |
+|         Custos de query         |                $500 por mês                |                            $120 por mês                           |
+| Tempo de engenharia<sup>†</sup> |                $800 por mês                | Nenhum, embutido na rede com Indexadores distribuídos globalmente |
+|         Queries por mês         |   Limitadas pelas capabilidades da infra   |                             ~3 milhões                            |
+|         Custo por query         |                     $0                     |                              $0.00004                             |
+|          Infraestutura          |                Centralizada                |                          Descentralizada                          |
+|       Custo de engenharia       |                $200 por hora               |                              Incluída                             |
+|      Redundância geográfica     | $1.200 em custos totais por node adicional |                              Incluída                             |
+|     Uptime (disponibilidade)    |                    Varia                   |                               99.9%+                              |
+|      Custos mensais totais      | <span className="highlight-row" /> $1,650+ |                                $120                               |
+
+## Utilizador de Volume Alto (cerca de 30 milhões de queries por mês)
+
+|       Comparação de Custos      |               Auto-hospedagem               |                         The Graph Network                         |
+| :-----------------------------: | :-----------------------------------------: | :---------------------------------------------------------------: |
+|    Custo mensal de servidor\*   |           $1.100 por mês, por node          |                                 $0                                |
+|         Custos de query         |                    $4.000                   |                           $1,200 por mês                          |
+|    Número de nodes necessário   |                      10                     |                           Não se aplica                           |
+| Tempo de engenharia<sup>†</sup> |            $6.000 ou mais por mês           | Nenhum, embutido na rede com Indexadores distribuídos globalmente |
+|         Queries por mês         |    Limitadas pelas capabilidades da infra   |                        Cerca de 30 milhões                        |
+|         Custo por query         |                      $0                     |                              $0.00004                             |
+|          Infraestutura          |                 Centralizada                |                          Descentralizada                          |
+|      Redundância geográfica     |  $1.200 em custos totais por node adicional |                              Incluída                             |
+|     Uptime (disponibilidade)    |                    Varia                    |                               99.9%+                              |
+|      Custos mensais totais      | <span className="highlight-row" /> $11,000+ |                               $1.200                              |
+
+\*com custos de backup incluídos: $50-$100 por mês
+
+<sup>†</sup>Tempo de engenharia baseado numa hipótese de $200 por hora
+
+<sup>‡</sup>Reflete o custo ao consumidor de dados. Taxas de query ainda são pagas a Indexadores por queries do Plano Grátis.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Curar um sinal em um subgraph é um custo opcional, único, e zero-líquido (por ex., $1 mil em um subgraph pode ser curado em um subgraph, e depois retirado — com potencial para ganhar retornos no processo).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Zero taxas de setup. Comece imediatamente, sem custos de setup ou gerais. Nenhum requisito de hardware. Zero falhas por infraestruturas centralizadas, e mais tempo para se concentrar no seu produto principal. Não há necessidade de servidores de backup, solução de problemas ou recursos caríssimos de engenharia.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 45642d0779450d39fc889ec0bd45f5fa9adfd690 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:22 -0500
Subject: [PATCH 1232/3820] New translations benefits.mdx (Russian)

---
 website/pages/ru/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/ru/resources/benefits.mdx

diff --git a/website/pages/ru/resources/benefits.mdx b/website/pages/ru/resources/benefits.mdx
new file mode 100644
index 000000000000..07788994cd81
--- /dev/null
+++ b/website/pages/ru/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+Децентрализованная сеть Graph была спроектирована и усовершенствована для создания надежной системы индексации и запросов — и с каждым днем она становится лучше благодаря тысячам участников по всему миру.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Вот анализ:
+
+## Почему Вы должны использовать сеть The Graph
+
+- Significantly lower monthly costs
+- затраты на установку инфраструктуры в размере $0
+- Превосходное время безотказной работы
+- Access to hundreds of independent Indexers around the world
+- 24/7 техническая поддержка со стороны глобального сообщества
+
+## Преимущества
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|         Сравнение затрат        |         Самостоятельный хостинг         |                          Сеть The Graph                         |
+| :-----------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
+| Ежемесячная стоимость сервера\* |               $350 в месяц              |                                $0                               |
+|        Стоимость запроса        |                   $0+                   |                           $0 per month                          |
+|   Время разработки<sup>†</sup>  |               $400 в месяц              | Никто, встроен в сеть с глобально распределенными индексаторами |
+|         Запросы в месяц         |  Ограничен возможностями инфраструктуры |                       100,000 (Free Plan)                       |
+|     Стоимость одного запроса    |                    $0                   |                          $0<sup>‡</sup>                         |
+|          Infrastructure         |             Централизованная            |                        Децентрализованная                       |
+|   Географическая избыточность   |   $750+ за каждую дополнительную ноду   |                             Включено                            |
+|     Время безотказной работы    |               Варьируется               |                              99.9%+                             |
+|    Общие ежемесячные расходы    | <span className="highlight-row" />$750+ |                                $0                               |
+
+## Medium Volume User (~3M queries per month)
+
+|         Сравнение затрат        |                    Самостоятельный хостинг                    |                          Сеть The Graph                         |
+| :-----------------------------: | :-----------------------------------------------------------: | :-------------------------------------------------------------: |
+| Ежемесячная стоимость сервера\* |                          $350 в месяц                         |                                $0                               |
+|        Стоимость запроса        |                          $500 в месяц                         |                          $120 per month                         |
+|   Время разработки<sup>†</sup>  |                          $800 в месяц                         | Никто, встроен в сеть с глобально распределенными индексаторами |
+|         Запросы в месяц         |             Ограничен возможностями инфраструктуры            |                            ~3,000,000                           |
+|     Стоимость одного запроса    |                               $0                              |                             $0.00004                            |
+|          Infrastructure         |                        Централизованная                       |                        Децентрализованная                       |
+|        Инженерные расходы       |                           $200 в час                          |                             Включено                            |
+|   Географическая избыточность   | общие затраты на каждую дополнительную ноду составляют $1,200 |                             Включено                            |
+|     Время безотказной работы    |                          Варьируется                          |                              99.9%+                             |
+|    Общие ежемесячные расходы    |           <span className="highlight-row" /> $1,650+          |                               $120                              |
+
+## High Volume User (~30M queries per month)
+
+|         Сравнение затрат        |                    Самостоятельный хостинг                    |                          Сеть The Graph                         |
+| :-----------------------------: | :-----------------------------------------------------------: | :-------------------------------------------------------------: |
+| Ежемесячная стоимость сервера\* |                     $1100 в месяц за ноду                     |                                $0                               |
+|        Стоимость запроса        |                             $4000                             |                         $1,200 per month                        |
+|    Необходимое количество нод   |                               10                              |                           Не подходит                           |
+|   Время разработки<sup>†</sup>  |                   $6,000 или больше в месяц                   | Никто, встроен в сеть с глобально распределенными индексаторами |
+|         Запросы в месяц         |             Ограничен возможностями инфраструктуры            |                           ~30,000,000                           |
+|     Стоимость одного запроса    |                               $0                              |                             $0.00004                            |
+|          Infrastructure         |                        Централизованная                       |                        Децентрализованная                       |
+|   Географическая избыточность   | общие затраты на каждую дополнительную ноду составляют $1,200 |                             Включено                            |
+|     Время безотказной работы    |                          Варьируется                          |                              99.9%+                             |
+|    Общие ежемесячные расходы    |          <span className="highlight-row" /> $11,000+          |                              $1,200                             |
+
+\* включая расходы на резервное копирование: $50-$100 в месяц
+
+<sup>†</sup>Время разработки основано на предположении о $200 в час
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Курирование сигнала на субграфе - это необязательная единовременная стоимость, равная нулю (например, сигнал стоимостью 1 тыс. долларов может быть курирован на субграфе, а затем отозван - с возможностью получения прибыли в процессе).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Нулевая плата за установку. Приступайте к работе немедленно, без каких-либо затрат на настройку или накладные расходы. Никаких требований к оборудованию. Отсутствие перебоев в работе из-за централизованной инфраструктуры и больше времени для концентрации на вашем основном продукте. Нет необходимости в резервных серверах, устранении неполадок или дорогостоящих инженерных ресурсах.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From c9b34931418e6372cac4c8b4083f6763cbe7d4eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:23 -0500
Subject: [PATCH 1233/3820] New translations benefits.mdx (Swedish)

---
 website/pages/sv/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/sv/resources/benefits.mdx

diff --git a/website/pages/sv/resources/benefits.mdx b/website/pages/sv/resources/benefits.mdx
new file mode 100644
index 000000000000..2b1d61e66e17
--- /dev/null
+++ b/website/pages/sv/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+The Graphs decentraliserade nätverk har utformats och finslipats för att skapa en robust indexering och frågeupplevelse - och det blir bättre för varje dag tack vare tusentals bidragsgivare runt om i världen.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Här är en analys:
+
+## Varför Du Bör Använda The Graph Nätverk
+
+- Significantly lower monthly costs
+- $0 infrastrukturinstallationskostnader
+- Överlägsen drifttid
+- Tillgång till hundratals oberoende indexerare runt om i världen
+- Teknisk support dygnet runt via global community
+
+## Fördelarna förklarade
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|       Kostnadsjämförelse      |                Egen Värd                |                       The Graph Nätverk                       |
+| :---------------------------: | :-------------------------------------: | :-----------------------------------------------------------: |
+| Månatlig kostnad för server\* |              $350 per månad             |                               $0                              |
+|       Kostnad för frågor      |                   $0+                   |                          $0 per month                         |
+|  Konstruktionstid<sup>†</sup> |              $400 per månad             | Ingen, inbyggd i nätverket med globalt distribuerade Indexers |
+|        Frågor per månad       |      Begränsad till infra kapacitet     |                      100,000 (Free Plan)                      |
+|       Kostnad per fråga       |                    $0                   |                         $0<sup>‡</sup>                        |
+|         Infrastruktur         |              Centraliserad              |                        Decentraliserad                        |
+|      Geografisk redundans     |           $750+ per extra nod           |                           Inkluderat                          |
+|            Drifttid           |                Varierande               |                             99.9%+                            |
+|      Total Månadskostnad      | <span className="highlight-row" />$750+ |                               $0                              |
+
+## Medium Volume User (~3M queries per month)
+
+|       Kostnadsjämförelse      |                  Egen Värd                 |                       The Graph Nätverk                       |
+| :---------------------------: | :----------------------------------------: | :-----------------------------------------------------------: |
+| Månatlig kostnad för server\* |               $350 per månad               |                               $0                              |
+|       Kostnad för frågor      |               $500 per månad               |                         $120 per month                        |
+|  Konstruktionstid<sup>†</sup> |               $800 per månad               | Ingen, inbyggd i nätverket med globalt distribuerade Indexers |
+|        Frågor per månad       |       Begränsad till infra kapacitet       |                           ~3,000,000                          |
+|       Kostnad per fråga       |                     $0                     |                            $0.00004                           |
+|         Infrastruktur         |                Centraliserad               |                        Decentraliserad                        |
+| Kostnader för ingenjörsarbete |               $200 per timme               |                           Inkluderat                          |
+|      Geografisk redundans     |   $1,200 i totala kostnader per extra nod  |                           Inkluderat                          |
+|            Drifttid           |                 Varierande                 |                             99.9%+                            |
+|      Total Månadskostnad      | <span className="highlight-row" /> $1,650+ |                              $120                             |
+
+## High Volume User (~30M queries per month)
+
+|       Kostnadsjämförelse      |                  Egen Värd                  |                       The Graph Nätverk                       |
+| :---------------------------: | :-----------------------------------------: | :-----------------------------------------------------------: |
+| Månatlig kostnad för server\* |           $1100 per månad, per nod          |                               $0                              |
+|       Kostnad för frågor      |                    $4000                    |                        $1,200 per month                       |
+|     Antal noder som behövs    |                      10                     |                         Ej tillämpligt                        |
+|  Konstruktionstid<sup>†</sup> |          $6,000 eller mer per månad         | Ingen, inbyggd i nätverket med globalt distribuerade Indexers |
+|        Frågor per månad       |        Begränsad till infra kapacitet       |                          ~30,000,000                          |
+|       Kostnad per fråga       |                      $0                     |                            $0.00004                           |
+|         Infrastruktur         |                Centraliserad                |                        Decentraliserad                        |
+|      Geografisk redundans     |   $1,200 i totala kostnader per extra nod   |                           Inkluderat                          |
+|            Drifttid           |                  Varierande                 |                             99.9%+                            |
+|      Total Månadskostnad      | <span className="highlight-row" /> $11,000+ |                             $1,200                            |
+
+\*inklusive kostnader för backup: $50-$100 per månad
+
+<sup>†</sup>Ingenjörstid baserad på antagandet $200 per timme
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Att kurera signal på en subgraf är en valfri engångskostnad med noll nettokostnad (t.ex. $1k i signal kan kurera på en subgraf och senare dras tillbaka - med potential att tjäna avkastning i processen).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Inga installationsavgifter. Kom igång direkt utan installations- eller overheadkostnader. Inga hårdvarukrav. Inga avbrott på grund av centraliserad infrastruktur och mer tid att fokusera på din kärnprodukt. Ingen nödvändighet för backup-servrar, felsökning eller dyra ingenjörsresurser.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 566f047c510d4367beea3ec2e85d4b0ce7e68455 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:24 -0500
Subject: [PATCH 1234/3820] New translations benefits.mdx (Turkish)

---
 website/pages/tr/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/tr/resources/benefits.mdx

diff --git a/website/pages/tr/resources/benefits.mdx b/website/pages/tr/resources/benefits.mdx
new file mode 100644
index 000000000000..3e2f4d46fb45
--- /dev/null
+++ b/website/pages/tr/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Here is an analysis:
+
+## Why You Should Use The Graph Network
+
+- Significantly lower monthly costs
+- $0 infrastructure setup costs
+- Superior uptime
+- Dünya çapındaki yüzlerce bağımsız İndeksleyiciye erişim
+- 24/7 technical support by global community
+
+## The Benefits Explained
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|        Cost Comparison       |               Self Hosted               |                            Graph Ağı                            |
+| :--------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |              $350 per month             |                                $0                               |
+|          Query costs         |                   $0+                   |                           $0 per month                          |
+| Engineering time<sup>†</sup> |              $400 per month             | None, built into the network with globally distributed Indexers |
+|       Queries per month      |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                    $0                   |                          $0<sup>‡</sup>                         |
+|            Altyapı           |               Centralized               |                          Decentralized                          |
+|     Geographic redundancy    |        $750+ per additional node        |                             Included                            |
+|            Uptime            |                  Varies                 |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" />$750+ |                                $0                               |
+
+## Medium Volume User (~3M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                |                            Graph Ağı                            |
+| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |               $350 per month               |                                $0                               |
+|          Query costs         |               $500 per month               |                          $120 per month                         |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities       |                            ~3,000,000                           |
+|        Cost per query        |                     $0                     |                             $0.00004                            |
+|            Altyapı           |                 Centralized                |                          Decentralized                          |
+|      Engineering expense     |                $200 per hour               |                             Included                            |
+|     Geographic redundancy    |  $1,200 in total costs per additional node |                             Included                            |
+|            Uptime            |                   Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $1,650+ |                               $120                              |
+
+## High Volume User (~30M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                 |                            Graph Ağı                            |
+| :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |          $1100 per month, per node          |                                $0                               |
+|          Query costs         |                    $4000                    |                         $1,200 per month                        |
+|    Number of nodes needed    |                      10                     |                          Not applicable                         |
+| Engineering time<sup>†</sup> |           $6,000 or more per month          | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                      $0                     |                             $0.00004                            |
+|            Altyapı           |                 Centralized                 |                          Decentralized                          |
+|     Geographic redundancy    |  $1,200 in total costs per additional node  |                             Included                            |
+|            Uptime            |                    Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+
+\*including costs for backup: $50-$100 per month
+
+<sup>†</sup>Engineering time based on $200 per hour assumption
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 2259e105119d62ab17d28a5c7ceeb49f970da794 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:25 -0500
Subject: [PATCH 1235/3820] New translations benefits.mdx (Ukrainian)

---
 website/pages/uk/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/uk/resources/benefits.mdx

diff --git a/website/pages/uk/resources/benefits.mdx b/website/pages/uk/resources/benefits.mdx
new file mode 100644
index 000000000000..ef5b5e4c10fc
--- /dev/null
+++ b/website/pages/uk/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Here is an analysis:
+
+## Чому вам слід використовувати мережу Graph
+
+- Significantly lower monthly costs
+- $0 витрат на налаштування інфраструктури
+- Високий час безвідмовної роботи
+- Access to hundreds of independent Indexers around the world
+- Технічна підтримка 24/7 від глобальної спільноти
+
+## The Benefits Explained
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|         Порівняння вартості послуг        |             Самостійний хостинг            |                            Graph мережа                           |
+| :---------------------------------------: | :----------------------------------------: | :---------------------------------------------------------------: |
+|        Щомісячна плата за сервер\*        |               $350 на місяць               |                                 $0                                |
+|              Вартість запитів             |                     $0+                    |                            $0 per month                           |
+| Час технічного обслуговування<sup>†</sup> |               $400 на місяць               | Немає, вбудовані в мережу з глобально розподіленими індексаторами |
+|        Кількість запитів за місяць        | Обмежується інфраструктурними можливостями |                        100,000 (Free Plan)                        |
+|           Вартість одного запиту          |                     $0                     |                           $0<sup>‡</sup>                          |
+|               Інфраструктура              |               Централізована               |                          Децентралізована                         |
+|          Географічне резервування         |        $750+ за кожну додаткову ноду       |                              Включено                             |
+|          Час безвідмовної роботи          |                 Варіюється                 |                               99.9%+                              |
+|      Загальна сума щомісячних витрат      |   <span className="highlight-row" />$750+  |                                 $0                                |
+
+## Medium Volume User (~3M queries per month)
+
+|         Порівняння вартості послуг        |               Самостійний хостинг               |                            Graph мережа                           |
+| :---------------------------------------: | :---------------------------------------------: | :---------------------------------------------------------------: |
+|        Щомісячна плата за сервер\*        |                  $350 на місяць                 |                                 $0                                |
+|              Вартість запитів             |                  $500 на місяць                 |                           $120 per month                          |
+| Час технічного обслуговування<sup>†</sup> |                  $800 на місяць                 | Немає, вбудовані в мережу з глобально розподіленими індексаторами |
+|        Кількість запитів за місяць        |    Обмежується інфраструктурними можливостями   |                             ~3,000,000                            |
+|           Вартість одного запиту          |                        $0                       |                              $0.00004                             |
+|               Інфраструктура              |                  Централізована                 |                          Децентралізована                         |
+|         Інженерно-технічні витрати        |                  $200 на годину                 |                              Включено                             |
+|          Географічне резервування         | $1,200 загальних витрат на кожну додаткову ноду |                              Включено                             |
+|          Час безвідмовної роботи          |                    Варіюється                   |                               99.9%+                              |
+|      Загальна сума щомісячних витрат      |    <span className="highlight-row" /> $1,650+   |                                $120                               |
+
+## High Volume User (~30M queries per month)
+
+|         Порівняння вартості послуг        |               Самостійний хостинг               |                            Graph мережа                           |
+| :---------------------------------------: | :---------------------------------------------: | :---------------------------------------------------------------: |
+|        Щомісячна плата за сервер\*        |          $1100 на місяць, за одну ноду          |                                 $0                                |
+|              Вартість запитів             |                      $4000                      |                          $1,200 per month                         |
+|          Кількість необхідних нод         |                        10                       |                           Не стосується                           |
+| Час технічного обслуговування<sup>†</sup> |            $6,000 і більше на місяць            | Немає, вбудовані в мережу з глобально розподіленими індексаторами |
+|        Кількість запитів за місяць        |    Обмежується інфраструктурними можливостями   |                            ~30,000,000                            |
+|           Вартість одного запиту          |                        $0                       |                              $0.00004                             |
+|               Інфраструктура              |                  Централізована                 |                          Децентралізована                         |
+|          Географічне резервування         | $1,200 загальних витрат на кожну додаткову ноду |                              Включено                             |
+|          Час безвідмовної роботи          |                    Варіюється                   |                               99.9%+                              |
+|      Загальна сума щомісячних витрат      |   <span className="highlight-row" /> $11,000+   |                               $1,200                              |
+
+\*включаючи витрати на резервне копіювання: $50-$100 на місяць
+
+<sup>†</sup>Час технічного обслуговування, розрахований на основі припущення $200 за годину
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Кураторство сигналу на підграфі є опціональною одноразовою послугою з нульовою вартістю (наприклад, сигнал на суму 1 тис. доларів можна розмістити на підграфі, а потім вивести — з можливістю отримання прибутку в цьому процесі).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Нульова комісія за налаштування. Почніть роботу негайно без витрат на налаштування та інших додаткових витрат. Ніяких жорстких вимог до апаратного обладнання. Відсутність перебоїв через централізовану інфраструктуру та більше часу для концентрації на основному продукті. Нема потреби в резервних серверах, усуненні несправностей або дорогих інженерно-технічних послугах.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 1f074ef026f2096ba60d511a8d39940d0515697b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:26 -0500
Subject: [PATCH 1236/3820] New translations benefits.mdx (Chinese Simplified)

---
 website/pages/zh/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/zh/resources/benefits.mdx

diff --git a/website/pages/zh/resources/benefits.mdx b/website/pages/zh/resources/benefits.mdx
new file mode 100644
index 000000000000..c0d0ce976e33
--- /dev/null
+++ b/website/pages/zh/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+Graph的去中心化网络经过精心设计和完善，创造了强大的索引和查询体验，由于世界各地成千上万的贡献者，它每天都在变得更好。
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+以下是分析：
+
+## 为什么要使用Graph网络
+
+- Significantly lower monthly costs
+- 基础设施设置成本为0美元
+- 超群的正常运行时间
+- Access to hundreds of independent Indexers around the world
+- 全球社区24/7的技术支持
+
+## 好处解释
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|       成本比较       |                   自托管                   |        Graph网络        |
+| :--------------: | :-------------------------------------: | :-------------------: |
+|    每月服务器费用 \*    |                 每月350美元                 |          0美元          |
+|       查询成本       |                   $0+                   |      $0 per month     |
+| 工程时间<sup>†</sup> |                 400美元每月                 | 没有，内置在具有全球去中心化索引者的网络中 |
+|       每月查询       |                受限于基础设施能力                |  100,000 (Free Plan)  |
+|      每个查询的成本     |                   0美元                   |     $0<sup>‡</sup>    |
+|       基础设施       |                   中心化                   |          去中心化         |
+|       异地备援       |              每个额外节点 $750 +              |          包括在内         |
+|      正常工作时间      |                    变量                   |         99.9%+        |
+|       每月总成本      | <span className="highlight-row" />$750+ |          0美元          |
+
+## Medium Volume User (~3M queries per month)
+
+|       成本比较       |                     自托管                    |        Graph网络        |
+| :--------------: | :----------------------------------------: | :-------------------: |
+|    每月服务器费用 \*    |                   每月350美元                  |          0美元          |
+|       查询成本       |                   每月500美元                  |     $120 per month    |
+| 工程时间<sup>†</sup> |                   每月800美元                  | 没有，内置在具有全球去中心化索引者的网络中 |
+|       每月查询       |                  受限于基础设施能力                 |       ~3,000,000      |
+|      每个查询的成本     |                     0美元                    |        $0.00004       |
+|       基础设施       |                     中心化                    |          去中心化         |
+|       工程费用       |                  每小时200美元                  |          包括在内         |
+|       异地备援       |              每个额外节点的总成本为1200美元             |          包括在内         |
+|      正常工作时间      |                     变量                     |         99.9%+        |
+|       每月总成本      | <span className="highlight-row" /> $1,650+ |          $120         |
+
+## High Volume User (~30M queries per month)
+
+|       成本比较       |                     自托管                     |        Graph网络        |
+| :--------------: | :-----------------------------------------: | :-------------------: |
+|    每月服务器费用 \*    |                 1100美元每月每节点                 |          0美元          |
+|       查询成本       |                    4000美元                   |    $1,200 per month   |
+|      需要的节点数量     |                      10                     |          不适用          |
+| 工程时间<sup>†</sup> |                 每月6000美元或以上                 | 没有，内置在具有全球去中心化索引者的网络中 |
+|       每月查询       |                  受限于基础设施能力                  |      ~30,000,000      |
+|      每个查询的成本     |                     0美元                     |        $0.00004       |
+|       基础设施       |                     中心化                     |          去中心化         |
+|       异地备援       |              每个额外节点的总成本为1200美元              |          包括在内         |
+|      正常工作时间      |                      变量                     |         99.9%+        |
+|       每月总成本      | <span className="highlight-row" /> $11,000+ |         $1,200        |
+
+- 包括后备费用: 每月$50-$100美元
+
+<sup>†</sup>按每小时200美元的假设计算的工程时间
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+在一个子图上策划信号是一个可选一次性净零成本(例如，1千美元的信号可以在一个子图上管理，然后撤回ーー在这个过程中有可能获得回报)。
+
+## No Setup Costs & Greater Operational Efficiency
+
+零安装费。立即开始，没有设置或间接费用。没有硬件要求。没有由于集中式基础设施而导致的中断，并且有更多的时间专注于您的核心产品。不需要备份服务器、故障排除或昂贵的工程资源。
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 3a52d12727470dbfc99cceed801d07734effaf55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:27 -0500
Subject: [PATCH 1237/3820] New translations benefits.mdx (Urdu (Pakistan))

---
 website/pages/ur/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/ur/resources/benefits.mdx

diff --git a/website/pages/ur/resources/benefits.mdx b/website/pages/ur/resources/benefits.mdx
new file mode 100644
index 000000000000..ee2c4ee130cc
--- /dev/null
+++ b/website/pages/ur/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+گراف کے ڈیسینٹرالائزڈ نیٹ ورک کو ایک مضبوط انڈیکسنگ اور کیوری کا تجربہ بنانے کے لیے انجنیئر اور بہتر بنایا گیا ہے — اور یہ دنیا بھر میں ہزاروں تعاون کرنے والوں کی بدولت ہر روز بہتر ہوتا جا رہا ہے.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+یہاں ایک تجزیہ ہے:
+
+## آپ کو گراف نیٹ ورک کیوں استعمال کرنا چاہئے
+
+- Significantly lower monthly costs
+- $0 بنیادی ڈھانچے کے سیٹ اپ کے اخراجات
+- اعلی اپ ٹائم
+- Access to hundreds of independent Indexers around the world
+- عالمی برادری کی طرف سے 24/7 تکنیکی مدد
+
+## فوائد کی وضاحت کی
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|       اخراجات کا موازنہ      |                خود میزبان               |                                The Graph Network                                |
+| :--------------------------: | :-------------------------------------: | :-----------------------------------------------------------------------------: |
+|    ماہانہ سرور کی قیمت/\*    |              $350 فی مہینہ              |                                        $0                                       |
+|      استفسار کے اخراجات      |                   $0+                   |                                   $0 per month                                  |
+| انجینئرنگ کا وقت<sup>†</sup> |              $400 فی مہینہ              | کوئی بھی نہیں، عالمی سطح پر تقسیم شدہ انڈیکسرز کے ساتھ نیٹ ورک میں بنایا گیا ہے |
+|        فی مہینہ سوالات       |         بنیادی صلاحیتوں تک محدود        |                               100,000 (Free Plan)                               |
+|         قیمت فی سوال         |                    $0                   |                                  $0<sup>‡</sup>                                 |
+|          انفراسٹرکچر         |                سینٹرلائزڈ               |                                   ڈیسینٹرلائزڈ                                  |
+|      جغرافیائی فالتو پن      |            $750+ فی اضافی نوڈ           |                                       شامل                                      |
+|            اپ ٹائم           |                اتار چڑھاو               |                                      99.9%+                                     |
+|       کل ماہانہ اخراجات      | <span className="highlight-row" />$750+ |                                        $0                                       |
+
+## Medium Volume User (~3M queries per month)
+
+|       اخراجات کا موازنہ      |                 خود میزبان                 |                                The Graph Network                                |
+| :--------------------------: | :----------------------------------------: | :-----------------------------------------------------------------------------: |
+|    ماہانہ سرور کی قیمت/\*    |                $350 فی مہینہ               |                                        $0                                       |
+|      استفسار کے اخراجات      |                $500 فی مہینہ               |                                  $120 per month                                 |
+| انجینئرنگ کا وقت<sup>†</sup> |                $800 فی مہینہ               | کوئی بھی نہیں، عالمی سطح پر تقسیم شدہ انڈیکسرز کے ساتھ نیٹ ورک میں بنایا گیا ہے |
+|        فی مہینہ سوالات       |          بنیادی صلاحیتوں تک محدود          |                                    ~3,000,000                                   |
+|         قیمت فی سوال         |                     $0                     |                                     $0.00004                                    |
+|          انفراسٹرکچر         |                 سینٹرلائزڈ                 |                                   ڈیسینٹرلائزڈ                                  |
+|     انجینئرنگ کے اخراجات     |                $200 فی گھنٹہ               |                                       شامل                                      |
+|      جغرافیائی فالتو پن      |     فی اضافی نوڈ کل اخراجات میں $1,200     |                                       شامل                                      |
+|            اپ ٹائم           |                 اتار چڑھاو                 |                                      99.9%+                                     |
+|       کل ماہانہ اخراجات      | <span className="highlight-row" /> $1,650+ |                                       $120                                      |
+
+## High Volume User (~30M queries per month)
+
+|       اخراجات کا موازنہ      |                  خود میزبان                 |                                The Graph Network                                |
+| :--------------------------: | :-----------------------------------------: | :-----------------------------------------------------------------------------: |
+|    ماہانہ سرور کی قیمت/\*    |            $1100 فی مہینہ، فی نوڈ           |                                        $0                                       |
+|      استفسار کے اخراجات      |                    $4000                    |                                 $1,200 per month                                |
+|    نوڈس کی تعداد درکار ہے    |                      10                     |                                 قابل اطلاق نہیں                                 |
+| انجینئرنگ کا وقت<sup>†</sup> |        $6,000 یا اس سے زیادہ فی مہینہ       | کوئی بھی نہیں، عالمی سطح پر تقسیم شدہ انڈیکسرز کے ساتھ نیٹ ورک میں بنایا گیا ہے |
+|        فی مہینہ سوالات       |           بنیادی صلاحیتوں تک محدود          |                                   ~30,000,000                                   |
+|         قیمت فی سوال         |                      $0                     |                                     $0.00004                                    |
+|          انفراسٹرکچر         |                  سینٹرلائزڈ                 |                                   ڈیسینٹرلائزڈ                                  |
+|      جغرافیائی فالتو پن      |      فی اضافی نوڈ کل اخراجات میں $1,200     |                                       شامل                                      |
+|            اپ ٹائم           |                  اتار چڑھاو                 |                                      99.9%+                                     |
+|       کل ماہانہ اخراجات      | <span className="highlight-row" /> $11,000+ |                                      $1,200                                     |
+
+/\*بیک اپ کے اخراجات سمیت: $50-$100 فی مہینہ
+
+<sup>†</sup>$200 فی گھنٹہ کے مفروضے کی بنیاد پر انجینئرنگ کا وقت
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+سب گراف پر کیوریٹنگ سگنل ایک اختیاری ایک بار، خالص صفر لاگت ہے (مثال کے طور پر، $1k سگنل کو سب گراف پر کیوریٹ کیا جا سکتا ہے، اور بعد میں واپس لیا جا سکتا ہے—اس عمل میں منافع کمانے کی صلاحیت کے ساتھ).
+
+## No Setup Costs & Greater Operational Efficiency
+
+صفر سیٹ اپ فیس . بغیر کسی سیٹ اپ یا اوور ہیڈ اخراجات کے فوراً شروع کریں۔کوئی ہارڈ ویئر کی ضرورت نہیں ہے. مرکزی انفراسٹرکچر کی وجہ سے کوئی بندش نہیں،اور اپنی بنیادی مصنوعات پر توجہ دینے کے لیے زیادہ وقت ۔بیک اپ سرورز، ٹربل شوٹنگ، یا مہنگے انجینئرنگ وسائل کی ضرورت نہیں.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From f225ef8f467f71ebd05be1f99174c61a8744fa55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:28 -0500
Subject: [PATCH 1238/3820] New translations benefits.mdx (Vietnamese)

---
 website/pages/vi/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/vi/resources/benefits.mdx

diff --git a/website/pages/vi/resources/benefits.mdx b/website/pages/vi/resources/benefits.mdx
new file mode 100644
index 000000000000..eb4479d6083f
--- /dev/null
+++ b/website/pages/vi/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Here is an analysis:
+
+## Why You Should Use The Graph Network
+
+- Significantly lower monthly costs
+- $0 infrastructure setup costs
+- Superior uptime
+- Access to hundreds of independent Indexers around the world
+- 24/7 technical support by global community
+
+## The Benefits Explained
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|        Cost Comparison       |               Self Hosted               |                          Mạng The Graph                         |
+| :--------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |              $350 per month             |                                $0                               |
+|          Query costs         |                   $0+                   |                           $0 per month                          |
+| Engineering time<sup>†</sup> |              $400 per month             | None, built into the network with globally distributed Indexers |
+|       Queries per month      |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                    $0                   |                          $0<sup>‡</sup>                         |
+|         Cơ sở hạ tầng        |               Centralized               |                          Decentralized                          |
+|     Geographic redundancy    |        $750+ per additional node        |                             Included                            |
+|            Uptime            |                  Varies                 |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" />$750+ |                                $0                               |
+
+## Medium Volume User (~3M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                |                          Mạng The Graph                         |
+| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |               $350 per month               |                                $0                               |
+|          Query costs         |               $500 per month               |                          $120 per month                         |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities       |                            ~3,000,000                           |
+|        Cost per query        |                     $0                     |                             $0.00004                            |
+|         Cơ sở hạ tầng        |                 Centralized                |                          Decentralized                          |
+|      Engineering expense     |                $200 per hour               |                             Included                            |
+|     Geographic redundancy    |  $1,200 in total costs per additional node |                             Included                            |
+|            Uptime            |                   Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $1,650+ |                               $120                              |
+
+## High Volume User (~30M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                 |                          Mạng The Graph                         |
+| :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |          $1100 per month, per node          |                                $0                               |
+|          Query costs         |                    $4000                    |                         $1,200 per month                        |
+|    Number of nodes needed    |                      10                     |                          Not applicable                         |
+| Engineering time<sup>†</sup> |           $6,000 or more per month          | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                      $0                     |                             $0.00004                            |
+|         Cơ sở hạ tầng        |                 Centralized                 |                          Decentralized                          |
+|     Geographic redundancy    |  $1,200 in total costs per additional node  |                             Included                            |
+|            Uptime            |                    Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+
+\*including costs for backup: $50-$100 per month
+
+<sup>†</sup>Engineering time based on $200 per hour assumption
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From c2b656e0d911a19703cd50ad9c5e470c9d1d0114 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:29 -0500
Subject: [PATCH 1239/3820] New translations benefits.mdx (Marathi)

---
 website/pages/mr/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/mr/resources/benefits.mdx

diff --git a/website/pages/mr/resources/benefits.mdx b/website/pages/mr/resources/benefits.mdx
new file mode 100644
index 000000000000..d0d63b48418e
--- /dev/null
+++ b/website/pages/mr/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+ग्राफचे विकेंद्रित नेटवर्क एक मजबूत अनुक्रमणिका आणि क्वेरी अनुभव तयार करण्यासाठी अभियंता आणि परिष्कृत केले गेले आहे — आणि जगभरातील हजारो योगदानकर्त्यांमुळे ते दररोज चांगले होत आहे.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+येथे एक विश्लेषण आहे:
+
+## आपण आलेख नेटवर्क का वापरावे
+
+- Significantly lower monthly costs
+- $0 पायाभूत सुविधा सेटअप खर्च
+- उत्कृष्ट अपटाइम
+- Access to hundreds of independent Indexers around the world
+- जागतिक समुदायाद्वारे 24/7 तांत्रिक समर्थन
+
+## फायदे स्पष्ट केले
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|         खर्चाची तुलना        |            स्वत: होस्ट केलेले           |                               आलेख नेटवर्क                               |
+| :--------------------------: | :-------------------------------------: | :----------------------------------------------------------------------: |
+|     मासिक सर्व्हर खर्च\*     |                दरमहा $350               |                                    $0                                    |
+|          क्वेरी खर्च         |                   $0+                   |                               $0 per month                               |
+| अभियांत्रिकी वेळ<sup>†</sup> |                दरमहा $400               | काहीही नाही, जागतिक स्तरावर वितरित इंडेक्सर्ससह नेटवर्कमध्ये तयार केलेले |
+|      प्रति महिना प्रश्न      |      इन्फ्रा क्षमतांपुरती मर्यादित      |                            100,000 (Free Plan)                           |
+|       प्रति क्वेरी खर्च      |                    $0                   |                              $0<sup>‡</sup>                              |
+|        Infrastructure        |                केंद्रीकृत               |                                विकेंद्रित                                |
+|       भौगोलिक रिडंडंसी       |         प्रति अतिरिक्त नोड $750+        |                                 समाविष्ट                                 |
+|            अपटाइम            |                  बदलते                  |                                  99.9%+                                  |
+|        एकूण मासिक खर्च       | <span className="highlight-row" />$750+ |                                    $0                                    |
+
+## Medium Volume User (~3M queries per month)
+
+|         खर्चाची तुलना        |             स्वत: होस्ट केलेले             |                               आलेख नेटवर्क                               |
+| :--------------------------: | :----------------------------------------: | :----------------------------------------------------------------------: |
+|     मासिक सर्व्हर खर्च\*     |                 दरमहा $350                 |                                    $0                                    |
+|          क्वेरी खर्च         |                 दरमहा $500                 |                              $120 per month                              |
+| अभियांत्रिकी वेळ<sup>†</sup> |                 दरमहा $800                 | काहीही नाही, जागतिक स्तरावर वितरित इंडेक्सर्ससह नेटवर्कमध्ये तयार केलेले |
+|      प्रति महिना प्रश्न      |        इन्फ्रा क्षमतांपुरती मर्यादित       |                                ~3,000,000                                |
+|       प्रति क्वेरी खर्च      |                     $0                     |                                 $0.00004                                 |
+|        Infrastructure        |                 केंद्रीकृत                 |                                विकेंद्रित                                |
+|       अभियांत्रिकी खर्च      |               $200 प्रति तास               |                                 समाविष्ट                                 |
+|       भौगोलिक रिडंडंसी       |    प्रति अतिरिक्त नोड एकूण खर्चात $1,200   |                                 समाविष्ट                                 |
+|            अपटाइम            |                    बदलते                   |                                  99.9%+                                  |
+|        एकूण मासिक खर्च       | <span className="highlight-row" /> $1,650+ |                                   $120                                   |
+
+## High Volume User (~30M queries per month)
+
+|         खर्चाची तुलना        |              स्वत: होस्ट केलेले             |                               आलेख नेटवर्क                               |
+| :--------------------------: | :-----------------------------------------: | :----------------------------------------------------------------------: |
+|     मासिक सर्व्हर खर्च\*     |         प्रति नोड, प्रति महिना $1100        |                                    $0                                    |
+|          क्वेरी खर्च         |                    $4000                    |                             $1,200 per month                             |
+|     आवश्यक नोड्सची संख्या    |                      10                     |                                 लागू नाही                                |
+| अभियांत्रिकी वेळ<sup>†</sup> |           दरमहा $6,000 किंवा अधिक           | काहीही नाही, जागतिक स्तरावर वितरित इंडेक्सर्ससह नेटवर्कमध्ये तयार केलेले |
+|      प्रति महिना प्रश्न      |        इन्फ्रा क्षमतांपुरती मर्यादित        |                                ~30,000,000                               |
+|       प्रति क्वेरी खर्च      |                      $0                     |                                 $0.00004                                 |
+|        Infrastructure        |                  केंद्रीकृत                 |                                विकेंद्रित                                |
+|       भौगोलिक रिडंडंसी       |    प्रति अतिरिक्त नोड एकूण खर्चात $1,200    |                                 समाविष्ट                                 |
+|            अपटाइम            |                    बदलते                    |                                  99.9%+                                  |
+|        एकूण मासिक खर्च       | <span className="highlight-row" /> $11,000+ |                                  $1,200                                  |
+
+\*बॅकअपच्या खर्चासह: $50-$100 प्रति महिना
+
+<sup>†</sup>अभियांत्रिकी वेळ $200 प्रति तास गृहीत धरून
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+सबग्राफवर क्युरेटिंग सिग्नल हा पर्यायी एक-वेळचा, निव्वळ-शून्य खर्च आहे (उदा., $1k सिग्नल सबग्राफवर क्युरेट केला जाऊ शकतो आणि नंतर मागे घेतला जाऊ शकतो—प्रक्रियेत परतावा मिळविण्याच्या संभाव्यतेसह).
+
+## No Setup Costs & Greater Operational Efficiency
+
+शून्य सेटअप शुल्क. कोणत्याही सेटअप किंवा ओव्हरहेड खर्चाशिवाय त्वरित प्रारंभ करा. हार्डवेअर आवश्यकता नाही. केंद्रीकृत पायाभूत सुविधांमुळे कोणतेही आउटेज नाही आणि तुमच्या मुख्य उत्पादनावर लक्ष केंद्रित करण्यासाठी अधिक वेळ. बॅकअप सर्व्हर, समस्यानिवारण किंवा महागड्या अभियांत्रिकी संसाधनांची आवश्यकता नाही.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 55d77a9c1c689354c1e670f7a78bf26d9586ece8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:30 -0500
Subject: [PATCH 1240/3820] New translations benefits.mdx (Hindi)

---
 website/pages/hi/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/hi/resources/benefits.mdx

diff --git a/website/pages/hi/resources/benefits.mdx b/website/pages/hi/resources/benefits.mdx
new file mode 100644
index 000000000000..282eed66eab5
--- /dev/null
+++ b/website/pages/hi/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+ग्राफ़ के विकेन्द्रीकृत नेटवर्क को एक मजबूत अनुक्रमण और क्वेरी अनुभव बनाने के लिए इंजीनियर और परिष्कृत किया गया है - और यह दुनिया भर के हजारों योगदानकर्ताओं के लिए हर दिन बेहतर हो रहा है।
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+यहाँ एक विश्लेषण है:
+
+## आपको ग्राफ़ नेटवर्क का उपयोग क्यों करना चाहिए
+
+- Significantly lower monthly costs
+- $0 इंफ्रास्ट्रक्चर सेटअप लागत
+- सुपीरियर अपटाइम
+- Access to hundreds of independent Indexers around the world
+- वैश्विक समुदाय द्वारा 24/7 तकनीकी सहायता
+
+## लाभ समझाया
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|           लागत तुलना           |           स्वयं होस्ट किया गया          |                            The Graph Network                           |
+| :----------------------------: | :-------------------------------------: | :--------------------------------------------------------------------: |
+|       मासिक सर्वर लागत\*       |              $350 प्रति माह             |                                   $0                                   |
+|           पूछताछ लागत          |                   $0+                   |                              $0 per month                              |
+| इंजीनियरिंग का समय<sup>†</sup> |             $ 400 प्रति माह             | कोई नहीं, विश्व स्तर पर वितरित इंडेक्सर्स के साथ नेटवर्क में बनाया गया |
+|        प्रति माह प्रश्न        |        इन्फ्रा क्षमताओं तक सीमित        |                           100,000 (Free Plan)                          |
+|        लागत प्रति क्वेरी       |                    $0                   |                             $0<sup>‡</sup>                             |
+|         आधारभूत संरचना         |                केंद्रीकृत               |                              विकेन्द्रीकृत                             |
+|         भौगोलिक अतिरेक         |         $750+ प्रति अतिरिक्त नोड        |                                  शामिल                                 |
+|             अपटाइम             |                  भिन्न                  |                                 99.9%+                                 |
+|         कुल मासिक लागत         | <span className="highlight-row" />$750+ |                                   $0                                   |
+
+## Medium Volume User (~3M queries per month)
+
+|           लागत तुलना           |            स्वयं होस्ट किया गया            |                            The Graph Network                           |
+| :----------------------------: | :----------------------------------------: | :--------------------------------------------------------------------: |
+|       मासिक सर्वर लागत\*       |               $350 प्रति माह               |                                   $0                                   |
+|           पूछताछ लागत          |               $ 500 प्रति माह              |                             $120 per month                             |
+| इंजीनियरिंग का समय<sup>†</sup> |               $800 प्रति माह               | कोई नहीं, विश्व स्तर पर वितरित इंडेक्सर्स के साथ नेटवर्क में बनाया गया |
+|        प्रति माह प्रश्न        |          इन्फ्रा क्षमताओं तक सीमित         |                               ~3,000,000                               |
+|        लागत प्रति क्वेरी       |                     $0                     |                                $0.00004                                |
+|         आधारभूत संरचना         |                 केंद्रीकृत                 |                              विकेन्द्रीकृत                             |
+|        इंजीनियरिंग खर्च        |              $ 200 प्रति घंटा              |                                  शामिल                                 |
+|         भौगोलिक अतिरेक         |   प्रति अतिरिक्त नोड कुल लागत में $1,200   |                                  शामिल                                 |
+|             अपटाइम             |                    भिन्न                   |                                 99.9%+                                 |
+|         कुल मासिक लागत         | <span className="highlight-row" /> $1,650+ |                                  $120                                  |
+
+## High Volume User (~30M queries per month)
+
+|           लागत तुलना           |             स्वयं होस्ट किया गया            |                            The Graph Network                           |
+| :----------------------------: | :-----------------------------------------: | :--------------------------------------------------------------------: |
+|       मासिक सर्वर लागत\*       |          $1100 प्रति माह, प्रति नोड         |                                   $0                                   |
+|           पूछताछ लागत          |                    $4000                    |                            $1,200 per month                            |
+|     आवश्यक नोड्स की संख्या     |                      10                     |                             Not applicable                             |
+| इंजीनियरिंग का समय<sup>†</sup> |           $6,000 or more per month          | कोई नहीं, विश्व स्तर पर वितरित इंडेक्सर्स के साथ नेटवर्क में बनाया गया |
+|        प्रति माह प्रश्न        |          इन्फ्रा क्षमताओं तक सीमित          |                               ~30,000,000                              |
+|        लागत प्रति क्वेरी       |                      $0                     |                                $0.00004                                |
+|         आधारभूत संरचना         |                  केंद्रीकृत                 |                              विकेन्द्रीकृत                             |
+|         भौगोलिक अतिरेक         |    प्रति अतिरिक्त नोड कुल लागत में $1,200   |                                  शामिल                                 |
+|             अपटाइम             |                    भिन्न                    |                                 99.9%+                                 |
+|         कुल मासिक लागत         | <span className="highlight-row" /> $11,000+ |                                 $1,200                                 |
+
+\*बैकअप की लागत सहित: $50-$100 प्रति माह
+
+<sup>†</sup>इंजीनियरिंग समय $200 प्रति घंटे की धारणा पर आधारित है
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+एक सबग्राफ पर क्यूरेटिंग सिग्नल एक वैकल्पिक वन-टाइम, नेट-जीरो कॉस्ट है (उदाहरण के लिए, सिग्नल में $1k को सबग्राफ पर क्यूरेट किया जा सकता है, और बाद में वापस ले लिया जाता है - प्रक्रिया में रिटर्न अर्जित करने की क्षमता के साथ)।
+
+## No Setup Costs & Greater Operational Efficiency
+
+शून्य सेटअप शुल्क। बिना किसी सेटअप या ओवरहेड लागत के तुरंत आरंभ करें। कोई हार्डवेयर आवश्यकताएँ नहीं। केंद्रीकृत बुनियादी ढांचे के कारण कोई आउटेज नहीं, और अपने मूल उत्पाद पर ध्यान केंद्रित करने के लिए अधिक समय। बैकअप सर्वर, समस्या निवारण या महंगे इंजीनियरिंग संसाधनों की कोई आवश्यकता नहीं है।
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 1bb6f20dadf415f4c7e9117528b38ce31f0e9c4c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:31 -0500
Subject: [PATCH 1241/3820] New translations benefits.mdx (Swahili)

---
 website/pages/sw/resources/benefits.mdx | 92 +++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 website/pages/sw/resources/benefits.mdx

diff --git a/website/pages/sw/resources/benefits.mdx b/website/pages/sw/resources/benefits.mdx
new file mode 100644
index 000000000000..067e4ef592a8
--- /dev/null
+++ b/website/pages/sw/resources/benefits.mdx
@@ -0,0 +1,92 @@
+---
+title: The Graph vs. Self Hosting
+socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
+---
+
+The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
+
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+
+Here is an analysis:
+
+## Why You Should Use The Graph Network
+
+- Significantly lower monthly costs
+- $0 infrastructure setup costs
+- Superior uptime
+- Access to hundreds of independent Indexers around the world
+- 24/7 technical support by global community
+
+## The Benefits Explained
+
+### Lower & more Flexible Cost Structure
+
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+
+## Low Volume User (less than 100,000 queries per month)
+
+|        Cost Comparison       |               Self Hosted               |                        The Graph Network                        |
+| :--------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |              $350 per month             |                                $0                               |
+|          Query costs         |                   $0+                   |                           $0 per month                          |
+| Engineering time<sup>†</sup> |              $400 per month             | None, built into the network with globally distributed Indexers |
+|       Queries per month      |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                    $0                   |                          $0<sup>‡</sup>                         |
+|        Infrastructure        |               Centralized               |                          Decentralized                          |
+|     Geographic redundancy    |        $750+ per additional node        |                             Included                            |
+|            Uptime            |                  Varies                 |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" />$750+ |                                $0                               |
+
+## Medium Volume User (~3M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                |                        The Graph Network                        |
+| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |               $350 per month               |                                $0                               |
+|          Query costs         |               $500 per month               |                          $120 per month                         |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities       |                            ~3,000,000                           |
+|        Cost per query        |                     $0                     |                             $0.00004                            |
+|        Infrastructure        |                 Centralized                |                          Decentralized                          |
+|      Engineering expense     |                $200 per hour               |                             Included                            |
+|     Geographic redundancy    |  $1,200 in total costs per additional node |                             Included                            |
+|            Uptime            |                   Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $1,650+ |                               $120                              |
+
+## High Volume User (~30M queries per month)
+
+|        Cost Comparison       |                 Self Hosted                 |                        The Graph Network                        |
+| :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |          $1100 per month, per node          |                                $0                               |
+|          Query costs         |                    $4000                    |                         $1,200 per month                        |
+|    Number of nodes needed    |                      10                     |                          Not applicable                         |
+| Engineering time<sup>†</sup> |           $6,000 or more per month          | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                      $0                     |                             $0.00004                            |
+|        Infrastructure        |                 Centralized                 |                          Decentralized                          |
+|     Geographic redundancy    |  $1,200 in total costs per additional node  |                             Included                            |
+|            Uptime            |                    Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+
+\*including costs for backup: $50-$100 per month
+
+<sup>†</sup>Engineering time based on $200 per hour assumption
+
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+
+Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process).
+
+## No Setup Costs & Greater Operational Efficiency
+
+Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources.
+
+## Reliability & Resiliency
+
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From ad629c49887a67b53e4b7736c5757e90b0569639 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:32 -0500
Subject: [PATCH 1242/3820] New translations glossary.mdx (Romanian)

---
 website/pages/ro/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/ro/resources/glossary.mdx

diff --git a/website/pages/ro/resources/glossary.mdx b/website/pages/ro/resources/glossary.mdx
new file mode 100644
index 000000000000..fa813b659730
--- /dev/null
+++ b/website/pages/ro/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossary
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 37f72add955f793ef4ac289b179fddc0c387d2a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:33 -0500
Subject: [PATCH 1243/3820] New translations glossary.mdx (French)

---
 website/pages/fr/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/fr/resources/glossary.mdx

diff --git a/website/pages/fr/resources/glossary.mdx b/website/pages/fr/resources/glossary.mdx
new file mode 100644
index 000000000000..359c0cb2aee2
--- /dev/null
+++ b/website/pages/fr/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossaire
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 5a91eec6e78cd33292dc6c18ae0c4e36b6fb879b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:34 -0500
Subject: [PATCH 1244/3820] New translations glossary.mdx (Spanish)

---
 website/pages/es/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/es/resources/glossary.mdx

diff --git a/website/pages/es/resources/glossary.mdx b/website/pages/es/resources/glossary.mdx
new file mode 100644
index 000000000000..fdca3b093220
--- /dev/null
+++ b/website/pages/es/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glosario
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 91ae63e9d994dd17f9b3fc49359ad612d8495a6a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:35 -0500
Subject: [PATCH 1245/3820] New translations glossary.mdx (Arabic)

---
 website/pages/ar/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/ar/resources/glossary.mdx

diff --git a/website/pages/ar/resources/glossary.mdx b/website/pages/ar/resources/glossary.mdx
new file mode 100644
index 000000000000..dde52c37403a
--- /dev/null
+++ b/website/pages/ar/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: قائمة المصطلحات
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 8ba368bcb0f7129dcbdff65173180d0ec0e84ba8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:36 -0500
Subject: [PATCH 1246/3820] New translations glossary.mdx (Czech)

---
 website/pages/cs/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/cs/resources/glossary.mdx

diff --git a/website/pages/cs/resources/glossary.mdx b/website/pages/cs/resources/glossary.mdx
new file mode 100644
index 000000000000..ead2fbb3e17b
--- /dev/null
+++ b/website/pages/cs/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glosář
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From a4fb65b9fe735de947a27ffb59e6fa3c31d34b06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:37 -0500
Subject: [PATCH 1247/3820] New translations glossary.mdx (German)

---
 website/pages/de/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/de/resources/glossary.mdx

diff --git a/website/pages/de/resources/glossary.mdx b/website/pages/de/resources/glossary.mdx
new file mode 100644
index 000000000000..fa813b659730
--- /dev/null
+++ b/website/pages/de/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossary
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 73dee4b84ce816d4ac64b7cc2181eebf6f112e49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:38 -0500
Subject: [PATCH 1248/3820] New translations glossary.mdx (Italian)

---
 website/pages/it/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/it/resources/glossary.mdx

diff --git a/website/pages/it/resources/glossary.mdx b/website/pages/it/resources/glossary.mdx
new file mode 100644
index 000000000000..fa813b659730
--- /dev/null
+++ b/website/pages/it/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossary
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From f4a9251bf9a7f445fee545a5c776d6f8a6770d95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:39 -0500
Subject: [PATCH 1249/3820] New translations glossary.mdx (Japanese)

---
 website/pages/ja/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/ja/resources/glossary.mdx

diff --git a/website/pages/ja/resources/glossary.mdx b/website/pages/ja/resources/glossary.mdx
new file mode 100644
index 000000000000..baab87472fce
--- /dev/null
+++ b/website/pages/ja/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: 用語集
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 883c879308f620b9ba534382b602a6f2325234f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:40 -0500
Subject: [PATCH 1250/3820] New translations glossary.mdx (Korean)

---
 website/pages/ko/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/ko/resources/glossary.mdx

diff --git a/website/pages/ko/resources/glossary.mdx b/website/pages/ko/resources/glossary.mdx
new file mode 100644
index 000000000000..fa813b659730
--- /dev/null
+++ b/website/pages/ko/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossary
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 20cbe8934c0c5bea1d1713840e22ac93e9328f3a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:41 -0500
Subject: [PATCH 1251/3820] New translations glossary.mdx (Dutch)

---
 website/pages/nl/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/nl/resources/glossary.mdx

diff --git a/website/pages/nl/resources/glossary.mdx b/website/pages/nl/resources/glossary.mdx
new file mode 100644
index 000000000000..fa813b659730
--- /dev/null
+++ b/website/pages/nl/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossary
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From ca8bb119b447b6310bb09935cb1f2756efcf0a92 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:42 -0500
Subject: [PATCH 1252/3820] New translations glossary.mdx (Polish)

---
 website/pages/pl/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/pl/resources/glossary.mdx

diff --git a/website/pages/pl/resources/glossary.mdx b/website/pages/pl/resources/glossary.mdx
new file mode 100644
index 000000000000..fa813b659730
--- /dev/null
+++ b/website/pages/pl/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossary
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From b230c8972fab0f1b14a9d4ce15cd39664ec13e7c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:43 -0500
Subject: [PATCH 1253/3820] New translations glossary.mdx (Portuguese)

---
 website/pages/pt/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/pt/resources/glossary.mdx

diff --git a/website/pages/pt/resources/glossary.mdx b/website/pages/pt/resources/glossary.mdx
new file mode 100644
index 000000000000..1f4454d73975
--- /dev/null
+++ b/website/pages/pt/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossário
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From e7aa7bbf3d3c3c7dc13c42dafae5b21d976261a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:44 -0500
Subject: [PATCH 1254/3820] New translations glossary.mdx (Russian)

---
 website/pages/ru/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/ru/resources/glossary.mdx

diff --git a/website/pages/ru/resources/glossary.mdx b/website/pages/ru/resources/glossary.mdx
new file mode 100644
index 000000000000..fa813b659730
--- /dev/null
+++ b/website/pages/ru/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossary
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From b9d1399f411dca8f6c070e3d78863f9020ecb3d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:45 -0500
Subject: [PATCH 1255/3820] New translations glossary.mdx (Swedish)

---
 website/pages/sv/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/sv/resources/glossary.mdx

diff --git a/website/pages/sv/resources/glossary.mdx b/website/pages/sv/resources/glossary.mdx
new file mode 100644
index 000000000000..b6cf29493dc3
--- /dev/null
+++ b/website/pages/sv/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Ordlista
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 2d0122554b459176e1559e21b07b6f69be27fd56 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:46 -0500
Subject: [PATCH 1256/3820] New translations glossary.mdx (Turkish)

---
 website/pages/tr/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/tr/resources/glossary.mdx

diff --git a/website/pages/tr/resources/glossary.mdx b/website/pages/tr/resources/glossary.mdx
new file mode 100644
index 000000000000..fa813b659730
--- /dev/null
+++ b/website/pages/tr/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossary
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 63d355e89e1c9eba94797340084d70682d15a40f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:47 -0500
Subject: [PATCH 1257/3820] New translations glossary.mdx (Ukrainian)

---
 website/pages/uk/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/uk/resources/glossary.mdx

diff --git a/website/pages/uk/resources/glossary.mdx b/website/pages/uk/resources/glossary.mdx
new file mode 100644
index 000000000000..96e2835ae2aa
--- /dev/null
+++ b/website/pages/uk/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Глосарій
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 8eeb62a022199bd58f6c613a9ffb1ecb3db7946b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:48 -0500
Subject: [PATCH 1258/3820] New translations glossary.mdx (Chinese Simplified)

---
 website/pages/zh/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/zh/resources/glossary.mdx

diff --git a/website/pages/zh/resources/glossary.mdx b/website/pages/zh/resources/glossary.mdx
new file mode 100644
index 000000000000..987d665b3c69
--- /dev/null
+++ b/website/pages/zh/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: 术语汇编
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 7a1d36e228a78f443ea54ed765704a96366d41b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:49 -0500
Subject: [PATCH 1259/3820] New translations glossary.mdx (Urdu (Pakistan))

---
 website/pages/ur/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/ur/resources/glossary.mdx

diff --git a/website/pages/ur/resources/glossary.mdx b/website/pages/ur/resources/glossary.mdx
new file mode 100644
index 000000000000..79b2da2f0e65
--- /dev/null
+++ b/website/pages/ur/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: لغت
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From dfad94f9b58ca30b67f614b743eb4c1571fd8537 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:50 -0500
Subject: [PATCH 1260/3820] New translations glossary.mdx (Vietnamese)

---
 website/pages/vi/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/vi/resources/glossary.mdx

diff --git a/website/pages/vi/resources/glossary.mdx b/website/pages/vi/resources/glossary.mdx
new file mode 100644
index 000000000000..fa813b659730
--- /dev/null
+++ b/website/pages/vi/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossary
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 442bedfa488810e75bfba0f5f6429378f96ec251 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:51 -0500
Subject: [PATCH 1261/3820] New translations glossary.mdx (Marathi)

---
 website/pages/mr/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/mr/resources/glossary.mdx

diff --git a/website/pages/mr/resources/glossary.mdx b/website/pages/mr/resources/glossary.mdx
new file mode 100644
index 000000000000..fa813b659730
--- /dev/null
+++ b/website/pages/mr/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossary
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From d65dccdbfc72603d8ac2a13883fe5f0e714b2a8b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:52 -0500
Subject: [PATCH 1262/3820] New translations glossary.mdx (Hindi)

---
 website/pages/hi/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/hi/resources/glossary.mdx

diff --git a/website/pages/hi/resources/glossary.mdx b/website/pages/hi/resources/glossary.mdx
new file mode 100644
index 000000000000..ceec54c67cbe
--- /dev/null
+++ b/website/pages/hi/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: शब्दकोष
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 106314f316f18ec689027e331b3f3321fdddc40d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:53 -0500
Subject: [PATCH 1263/3820] New translations glossary.mdx (Swahili)

---
 website/pages/sw/resources/glossary.mdx | 81 +++++++++++++++++++++++++
 1 file changed, 81 insertions(+)
 create mode 100644 website/pages/sw/resources/glossary.mdx

diff --git a/website/pages/sw/resources/glossary.mdx b/website/pages/sw/resources/glossary.mdx
new file mode 100644
index 000000000000..fa813b659730
--- /dev/null
+++ b/website/pages/sw/resources/glossary.mdx
@@ -0,0 +1,81 @@
+---
+title: Glossary
+---
+
+- **The Graph**: A decentralized protocol for indexing and querying data.
+
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+
+- **Data Consumer**: Any application or user that queries a subgraph.
+
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 6d7673f390fce8d266e84f8bd57368747e966555 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:54 -0500
Subject: [PATCH 1264/3820] New translations assemblyscript-migration-guide.mdx
 (Romanian)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/ro/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/ro/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ro/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..85f6903a6c69
--- /dev/null
+++ b/website/pages/ro/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript Migration Guide
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+That will enable subgraph developers to use newer features of the AS language and standard library.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Features
+
+### New functionality
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimizations
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Other
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## How to upgrade?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Follow the rest of the guide to fix the language breaking changes.
+5. Run `codegen` and `deploy` again.
+
+## Breaking changes
+
+### Nullability
+
+On the older version of AssemblyScript, you could create code like this:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+However on the newer version, because the value is nullable, it requires you to check, like this:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Or force it like this:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+If you are unsure which to choose, we recommend always using the safe version. If the value doesn't exist you might want to just do an early if statement with a return in you subgraph handler.
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+However now this isn't possible anymore, and the compiler returns this error:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+You'll need to rename your duplicate variables if you had variable shadowing.
+
+### Null Comparisons
+
+By doing the upgrade on your subgraph, sometimes you might get errors like these:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+The same applies if you're doing != instead of ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+However this only works in two scenarios:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting on class inheritance (subclass → superclass)
+
+Examples:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting on class inheritance (superclass → subclass)
+- Between two types that share a superclass
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Also we've added a few more static methods in some types to ease casting, they are:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Nullability check with property access
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+Which outputs this error:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Operator overloading with property access
+
+If you try to sum (for example) a nullable type (from a property access) with a non nullable one, the AssemblyScript compiler instead of giving a compile time error warning that one of the values is nullable, it just compiles silently, giving chance for the code to break at runtime.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+We've opened a issue on the AssemblyScript compiler for this, but for now if you do these kind of operations in your subgraph mappings, you should change them to do a null check before it.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Value initialization
+
+If you have any code like this:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+It will compile but break at runtime, that happens because the value hasn't been initialized, so make sure your subgraph has initialized their values, like this:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Also if you have nullable properties in a GraphQL entity, like this:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+And you have code similar to this:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Class property initialization
+
+If you export any classes with properties that are other classes (declared by you or by the standard library) like this:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Array initialization
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Or you should mutate it via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Other
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From f3e6e15e6a4bac9444c7cc73062e32f4b3b813c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:55 -0500
Subject: [PATCH 1265/3820] New translations assemblyscript-migration-guide.mdx
 (French)

---
 .../assemblyscript-migration-guide.mdx        | 523 ++++++++++++++++++
 1 file changed, 523 insertions(+)
 create mode 100644 website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..48954cbf16cd
--- /dev/null
+++ b/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,523 @@
+---
+title: Guide de migration de l'AssemblyScript
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+Cela permettra aux développeurs de subgraph d'utiliser les nouvelles fonctionnalités du langage AS et de la bibliothèque standard.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Fonctionnalités
+
+### Nouvelle fonctionnalité
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimizations
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Autre
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## Comment mettre à niveau ?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# si vous l'avez installé globalement
+npm install --global @graphprotocol/graph-cli@latest
+
+# ou dans votre subgraph si vous l'avez comme dépendance de développement
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Suivez le reste du guide pour corriger les changements de langue.
+5. Run `codegen` and `deploy` again.
+
+## Modifications radicales
+
+### Nullability
+
+Sur l'ancienne version d'AssemblyScript, vous pouviez créer du code comme celui-ci :
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+Cependant, sur la version la plus récente, comme la valeur est nullable, vous devez vérifier, comme ceci :
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` n'est plus nul
+}
+```
+
+Ou forcez-le comme ceci :
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+Si vous ne savez pas lequel choisir, nous vous recommandons de toujours utiliser la version sécurisée. Si la valeur n'existe pas, vous souhaiterez peut-être simplement effectuer une instruction if précoce avec un retour dans votre gestionnaire de subgraph.
+
+### Ombrage variable
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+Cependant, cela n'est plus possible et le compilateur renvoie cette erreur :
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+Vous devrez renommer vos variables en double si vous conservez une observation de variables.
+
+### Comparaisons nulles
+
+En effectuant la mise à niveau sur votre subgraph, vous pouvez parfois obtenir des erreurs comme celles-ci :
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+La même chose s'applique si vous faites != au lieu de ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+Cependant, cela ne fonctionne que dans deux scénarios :
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting sur l'héritage de classe (sous-classe → superclasse)
+
+Les Exemples:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting sur l'héritage de classe (superclasse → sous-classe)
+- Entre deux types qui partagent une superclasse
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// supprimer la possibilité de valeur nulle (nullability)
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // suppression sûre de null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Nous avons également ajouté quelques méthodes statiques supplémentaires dans certains types pour faciliter la diffusion, à savoir :
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Vérification de nullité avec accès à la propriété
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// ou
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // ne compile pas
+```
+
+Ce qui génère cette erreur :
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+Pour résoudre ce problème, vous pouvez créer une variable pour l'accès à cette propriété afin que le compilateur puisse effectuer la vérification magique de la nullité :
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compile sans problème :)
+```
+
+### Surcharge de l'opérateur avec accès à la propriété
+
+Si vous essayez de additionner (par exemple) un type nullable (à partir d'un accès à une propriété) avec un type non nullable, le compilateur AssemblyScript au lieu de donner une erreur de compilation avertissant que l'une des valeurs est nullable, il compile simplement silencieusement, donnant une chance pour que le code soit interrompu au moment de l'exécution.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // donne une erreur de compilation concernant la nullité
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // ne donne pas d'erreurs de compilation comme il se doit
+```
+
+Nous avons ouvert un problème sur le compilateur AssemblyScript pour cela, mais pour l'instant, si vous effectuez ce type d'opérations dans vos mappages de subgraph, vous devez les modifier pour effectuer une vérification nulle avant.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // maintenant `n` est garanti comme étant un BigInt
+```
+
+### Initialisation de valeur
+
+Si vous avez un code comme celui-ci :
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+Il sera compilé mais s'arrêtera au moment de l'exécution, cela se produit parce que la valeur n'a pas été initialisée, alors assurez-vous que votre subgraph a initialisé ses valeurs, comme ceci :
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+De plus, si vous avez des propriétés nullables dans une entité GraphQL, comme ceci :
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+Et vous avez un code similaire à celui-ci :
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+    total = new Total('latest') // initialise déjà les propriétés non-nullables
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Initialisation de la propriété de classe
+
+Si vous exportez des classes avec des propriétés qui sont d'autres classes (déclarées par vous ou par la bibliothèque standard), comme ceci :
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// ou
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// ou
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Initialisation du tableau
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+En fonction des types que vous utilisez, par exemple les types nullables, et de la manière dont vous y accédez, vous pourriez rencontrer une erreur d'exécution comme celle-ci :
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Ou vous devriez le muter via index :
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### Schéma GraphQL
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Vous ne pouvez désormais plus définir de champs dans vos types qui sont des listes non nullables. Si vous avez un schéma comme celui-ci :
+
+```graphql
+type Something @entity {
+    id: Bytes!
+}
+
+type MyEntity @entity {
+    id: Bytes!
+    invalidField: [Something]! # n'est plus valide
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valide
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Autre
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 0c4dbff9a10e61cea63be397482cec628f954246 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:56 -0500
Subject: [PATCH 1266/3820] New translations assemblyscript-migration-guide.mdx
 (Spanish)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/es/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/es/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/es/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..354d8c68a3e8
--- /dev/null
+++ b/website/pages/es/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: Guía de Migración de AssemblyScript
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+Esto permitirá a los desarrolladores de subgrafos utilizar las nuevas características del lenguaje AS y la librería estándar.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Características
+
+### Nueva Funcionalidad
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimizaciones
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Otros
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## ¿Cómo actualizar?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# si lo tiene instalada de forma global
+npm install --global @graphprotocol/graph-cli@latest
+
+# o desde su subgrafo si lo tiene como dependencia
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Sigue el resto de la guía para arreglar los cambios que rompen el lenguaje.
+5. Run `codegen` and `deploy` again.
+
+## Rompiendo los esquemas
+
+### Anulabilidad
+
+En la versión anterior de AssemblyScript, podías crear un código como el siguiente:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+Sin embargo, en la versión más reciente, debido a que el valor es anulable, es necesario que lo compruebes, así:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+O forzarlo así:
+
+```typescript
+let maybeValue = load()! // rompiendo el runtime si el valor es nulo
+
+maybeValue.aMethod()
+```
+
+Si no estás seguro de cuál elegir, te recomendamos que utilices siempre la versión segura. Si el valor no existe, es posible que quieras hacer una declaración if temprana con un retorno en tu handler de subgrafo.
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+Sin embargo, ahora esto ya no es posible, y el compilador devuelve este error:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+Tendrás que cambiar el nombre de las variables duplicadas si tienes una variable shadowing.
+
+### Comparaciones Nulas
+
+Al hacer la actualización en un subgrafo, a veces pueden aparecer errores como estos:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+Lo mismo ocurre si haces != en lugar de ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+Sin embargo, esto solo funciona en dos casos:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting en la herencia de clases (subclase → superclase)
+
+Ejemplos:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting en la herencia de clases (superclase → subclase)
+- Entre dos tipos que comparten una superclase
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// eliminar anulabilidad
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // sabe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+También hemos añadido algunos métodos estáticos en algunos tipos para facilitar el casting, son:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Comprobación de anulabilidad con acceso a la propiedad
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// o
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+Lo que produce este error:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+Para solucionar este problema, puedes crear una variable para ese acceso a la propiedad de manera que el compilador pueda hacer la magia de la comprobación de nulidad:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Sobrecarga de operadores con acceso a propiedades
+
+Si intentas sumar (por ejemplo) un tipo anulable (desde un acceso a una propiedad) con otro no anulable, el compilador de AssemblyScript en lugar de dar un error en el tiempo de compilación advirtiendo que uno de los valores es anulable, simplemente compila en silencio, dando oportunidad a que el código se rompa en tiempo de ejecución.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+Hemos abierto un tema en el compilador de AssemblyScript para esto, pero por ahora si haces este tipo de operaciones en tus mapeos de subgrafos, deberías cambiarlos para hacer una comprobación de nulos antes de ello.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Inicialización del valor
+
+Si tienes algún código como este:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+Compilará pero se romperá en tiempo de ejecución, eso ocurre porque el valor no ha sido inicializado, así que asegúrate de que tu subgrafo ha inicializado sus valores, así:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+También si tienes propiedades anulables en una entidad GraphQL, como esta:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+Y tienes un código similar a este:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // justo luego de haber iniciado la propiedad de no-anulable
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Inicialización de las propiedades de la clase
+
+Si exportas alguna clase con propiedades que son otras clases (declaradas por ti o por la librería estándar) así:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// o
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Inicialización de Array
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Dependiendo de los tipos que estés utilizando, por ejemplo los anulables, y de cómo estés accediendo a ellos, podrías encontrarte con un error de ejecución como este:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+O debería mutar a través de un índice:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### Esquema GraphQL
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Ahora ya no puedes definir campos en tus tipos que sean Listas No Anulables. Si tienes un esquema como este:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Otros
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 74f4e124bbde66fcf8b00efeb352b7c7f4a15841 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:57 -0500
Subject: [PATCH 1267/3820] New translations assemblyscript-migration-guide.mdx
 (Arabic)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/ar/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/ar/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ar/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..9fe263f2f8b2
--- /dev/null
+++ b/website/pages/ar/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: دليل ترحيل AssemblyScript
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+سيمكن ذلك لمطوري ال Subgraph من استخدام مميزات أحدث للغة AS والمكتبة القياسية.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## مميزات
+
+### وظائف جديدة
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### التحسينات
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### آخر
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## كيف تقوم بالترقية؟
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. اتبع بقية الدليل لاصلاح التغييرات الهامة في اللغة.
+5. Run `codegen` and `deploy` again.
+
+## تغييرات هامة
+
+### Nullability
+
+في الإصدار الأقدم من AssemblyScript ، يمكنك إنشاء كود مثل هذا:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+ولكن في الإصدار الأحدث ، نظرًا لأن القيمة nullable ، فإنها تتطلب منك التحقق ، مثل هذا:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+أو إجباره على هذا النحو:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+إذا لم تكن متأكدا من اختيارك ، فنحن نوصي دائما باستخدام الإصدار الآمن. إذا كانت القيمة غير موجودة ، فقد ترغب في القيام بعبارة if المبكرة مع قيمة راجعة في معالج الـ subgraph الخاص بك.
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+لكن هذا لم يعد ممكنًا الآن ، ويرجع المترجم بهذا الخطأ:
+
+```typescript
+'ERROR TS2451: Cannot redeclare block-scoped variable 'a
+
+; let a = a + b
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+ستحتاج إلى إعادة تسمية المتغيرات المكررة إذا كان لديك variable shadowing.
+
+### مقارانات Null
+
+من خلال إجراء الترقية على ال Subgraph الخاص بك ، قد تحصل أحيانًا على أخطاء مثل هذه:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+الأمر نفسه ينطبق إذا كنت تفعل =! بدلاً من ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+لكن هذا لا يعمل إلا في سيناريوهين:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting على وراثة الفئة (subclass → superclass)
+
+أمثلة:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting وراثة الفئة (superclass → subclass)
+- بين نوعين يشتركان في فئة superclass
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Also we've added a few more static methods in some types to ease casting, they are:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### التحقق من Nullability مع الوصول الى الخاصية
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+الذي يخرج هذا الخطأ:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+لإصلاح هذه المشكلة ، يمكنك إنشاء متغير للوصول إلى الخاصية حتى يتمكن المترجم من القيام بعملية التحقق من الـ nullability:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### التحميل الزائد للمشغل مع الوصول للخاصية
+
+(على سبيل المثال) إذا حاولت جمع نوع nullable (من وصول خاصية) مع نوع nullable ، فإن مترجم AssemblyScript بدلاً من إعطاء خطأ في وقت التحويل يحذر من أن إحدى القيم nullable، وبما أنه يقوم فقط بالترجمة بصمت ، فإنه يتيح الفرصة للكود للتوقف في وقت التشغيل.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+لقد فتحنا مشكلة في مترجم AssemblyScript ، ولكن في الوقت الحالي إذا أجريت هذا النوع من العمليات في Subgraph mappings ، فيجب عليك تغييرها لإجراء فحص ل null قبل ذلك.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### تهيئة القيمة
+
+إذا كان لديك أي كود مثل هذا:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+سيتم تجميعها لكنها ستتوقف في وقت التشغيل ، وهذا يحدث لأن القيمة لم تتم تهيئتها ، لذا تأكد من أن ال subgraph قد قام بتهيئة قيمها ، على النحو التالي:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+وأيضًا إذا كانت لديك خصائص ل nullable في كيان GraphQL ، مثل هذا:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+ولديك كود مشابه لهذا:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### تهيئة خاصية الفئة
+
+إذا قمت بتصدير (export) أي فئات ذات خصائص فئات أخرى (تم تعريفها بواسطتك أو بواسطة المكتبة القياسية) مثل هذا:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Array initialization
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Or you should mutate it via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### آخر
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 7ad58f985f4cd9a7fb91681ff0e3c810b9798ebd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:06:58 -0500
Subject: [PATCH 1268/3820] New translations assemblyscript-migration-guide.mdx
 (Czech)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/cs/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/cs/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/cs/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..756873dd8fbb
--- /dev/null
+++ b/website/pages/cs/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: Průvodce migrací AssemblyScript
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+To umožní vývojářům podgrafů používat novější funkce jazyka AS a standardní knihovny.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Funkce
+
+### Nové funkce
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimalizace
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Jiný
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## Jak provést upgrade?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Postupujte podle zbytku příručky a opravte změny, které narušují jazyk.
+5. Run `codegen` and `deploy` again.
+
+## Prolomení změn
+
+### Nullability
+
+Ve starší verzi AssemblyScript bylo možné vytvořit kód takto:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+V novější verzi je však hodnota nulovatelná a je nutné ji zkontrolovat takto:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Nebo si to vynuťte takto:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+Pokud si nejste jisti, kterou verzi zvolit, doporučujeme vždy použít bezpečnou verzi. Pokud hodnota neexistuje, možná budete chtít provést pouze časný příkaz if s návratem v obsluze podgrafu.
+
+### Proměnlivé stínování
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+Nyní to však již není možné a překladač vrací tuto chybu:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+Pokud jste použili stínování proměnných, musíte duplicitní proměnné přejmenovat.
+
+### Nulová srovnání
+
+Při aktualizaci podgrafu může někdy dojít k těmto chybám:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+Totéž platí, pokud místo == použijete !=.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+To však funguje pouze ve dvou případech:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting na dědičnost tříd (podtřída → nadtřída)
+
+Příklady:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting při dědění tříd (nadtřída → podtřída)
+- Mezi dvěma typy, které mají společnou nadtřídu
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Také jsme přidali několik dalších statických metod v některých typy abychom usnadnili odlévání, jsou to:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Kontrola nulovatelnosti s přístupem k vlastnostem
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+Který vypíše tuto chybu:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+Chcete-li tento problém vyřešit, můžete vytvořit proměnnou pro přístup k této vlastnosti, aby překladač mohl provést kouzlo kontroly nulovatelnosti:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Přetěžování operátorů s přístupem k vlastnostem
+
+Pokud se pokusíte sečíst (například) nullable typ (z přístupu k vlastnosti) s typem, který nullable není, kompilátor jazyka AssemblyScript namísto toho, aby při kompilaci zobrazil varování, že jedna z hodnot je nullable, provede tichou kompilaci, čímž se kód může za běhu pokazit.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+Otevřeli jsme kvůli tomu problém v kompilátoru jazyka AssemblyScript, ale zatím platí, že pokud provádíte tyto operace v mapování podgrafů, měli byste je změnit tak, aby se před nimi provedla kontrola null.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Inicializace hodnot
+
+Pokud máte nějaký takový kód:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+Zkompiluje se, ale za běhu se přeruší, což se stane, protože hodnota nebyla inicializována, takže se ujistěte, že váš podgraf inicializoval své hodnoty, například takto:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Také pokud máte v entitě GraphQL nulovatelné vlastnosti, jako je tato:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+A máte kód podobný tomuto:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Inicializace vlastností třídy
+
+Pokud exportujete třídy s vlastnostmi, které jsou jinými třídami (deklarovanými vámi nebo standardní knihovnou), jako je tento:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Inicializace polí
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+V závislosti na typech, které používáte, např. nulovatelných, a na způsobu přístupu k nim se můžete setkat s chybou běhu, jako je tato:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Nebo byste ho měli zmutovat pomocí indexu:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### Schéma GraphQL
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Nyní již nelze v typech definovat pole, která jsou nenulovatelnými seznamy. Pokud máte takovéto schéma:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Jiný
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From f5928c655ea746561a26401d3c34eba309f396ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:00 -0500
Subject: [PATCH 1269/3820] New translations assemblyscript-migration-guide.mdx
 (German)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..fb1ad8beb382
--- /dev/null
+++ b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript Migration Guide
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+That will enable subgraph developers to use newer features of the AS language and standard library.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Features
+
+### New functionality
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimizations
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Other
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## How to upgrade?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Follow the rest of the guide to fix the language breaking changes.
+5. Run `codegen` and `deploy` again.
+
+## Breaking changes
+
+### Nullability
+
+On the older version of AssemblyScript, you could create code like this:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+However on the newer version, because the value is nullable, it requires you to check, like this:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Or force it like this:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+If you are unsure which to choose, we recommend always using the safe version. If the value doesn't exist you might want to just do an early if statement with a return in you subgraph handler.
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+However now this isn't possible anymore, and the compiler returns this error:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+You'll need to rename your duplicate variables if you had variable shadowing.
+
+### Null Comparisons
+
+By doing the upgrade on your subgraph, sometimes you might get errors like these:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+The same applies if you're doing != instead of ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+However this only works in two scenarios:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting on class inheritance (subclass → superclass)
+
+Examples:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting on class inheritance (superclass → subclass)
+- Between two types that share a superclass
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Also we've added a few more static methods in some types to ease casting, they are:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Nullability check with property access
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// oder
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+Which outputs this error:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Operator overloading with property access
+
+If you try to sum (for example) a nullable type (from a property access) with a non nullable one, the AssemblyScript compiler instead of giving a compile time error warning that one of the values is nullable, it just compiles silently, giving chance for the code to break at runtime.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+We've opened a issue on the AssemblyScript compiler for this, but for now if you do these kind of operations in your subgraph mappings, you should change them to do a null check before it.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Value initialization
+
+If you have any code like this:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+It will compile but break at runtime, that happens because the value hasn't been initialized, so make sure your subgraph has initialized their values, like this:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Also if you have nullable properties in a GraphQL entity, like this:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+And you have code similar to this:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Class property initialization
+
+If you export any classes with properties that are other classes (declared by you or by the standard library) like this:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// oder
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// oder
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Array initialization
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Or you should mutate it via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Other
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 716df8b833b0aa70e06e3ca9b8aa9542be5162e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:01 -0500
Subject: [PATCH 1270/3820] New translations assemblyscript-migration-guide.mdx
 (Italian)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/it/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/it/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/it/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..5cef32e4a79f
--- /dev/null
+++ b/website/pages/it/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: Guida alla migrazione di AssemblyScript
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+Ciò consentirà agli sviluppatori di subgraph di utilizzare le nuove caratteristiche del linguaggio AS e della libreria standard.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Caratteristiche
+
+### Nuova funzionalità
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Ottimizzazioni
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Altro
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## Come aggiornare?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# se è installato globalmente 
+npm install --global @graphprotocol/graph-cli@latest
+
+# o nel proprio subgraph, se è una dipendenza di dev
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Seguire il resto della guida per correggere le modifiche alla lingua.
+5. Run `codegen` and `deploy` again.
+
+## Cambiamenti di rottura
+
+### Nullabilità
+
+Nella versione precedente di AssemblyScript, era possibile creare codice come questo:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+Tuttavia, nella versione più recente, poiché il valore è nullable, è necessario effettuare un controllo, come questo:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Oppure forzarla in questo modo:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+Se non si è sicuri di quale scegliere, si consiglia di utilizzare sempre la versione sicura. Se il valore non esiste, si potrebbe fare una dichiarazione if anticipata con un ritorno nel gestore del subgraph.
+
+### Shadowing della variabile
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+Tuttavia ora questo non è più possibile e il compilatore restituisce questo errore:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+È necessario rinominare le variabili duplicate se si dispone di un'ombreggiatura delle variabili.
+
+### Confronti nulli
+
+Eseguendo l'aggiornamento sul subgraph, a volte si possono ottenere errori come questi:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+Lo stesso vale se si fa != invece di ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+Tuttavia, questo funziona solo in due scenari:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting sull'ereditarietà delle classi (subclasse → superclasse)
+
+Examples:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting sull'ereditarietà delle classi (superclasse → subclasse)
+- Tra due tipi che condividono una superclasse
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// rimuovere la nullità
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Inoltre abbiamo aggiunto alcuni metodi statici in alcuni tipi per facilitare il casting, che sono:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Verifica della nullità con accesso alle proprietà
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // non viene compilato
+```
+
+Che produce questo errore:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+Per risolvere questo problema, si può creare una variabile per l'accesso alla proprietà, in modo che il compilatore possa fare la magia del controllo di annullabilità:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // viene compilato benissimo :)
+```
+
+### Sovraccarico dell'operatore con accesso alle proprietà
+
+Se si tenta di sommare (ad esempio) un tipo nullable (da un accesso a una proprietà) con uno non nullable, il compilatore di AssemblyScript, invece di dare un avviso di errore in fase di compilazione sul fatto che uno dei valori è nullable, si limita a compilare in silenzio, dando la possibilità che il codice si interrompa in fase di esecuzione.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // non dà errori in fase di compilazione come dovrebbe
+```
+
+Abbiamo aperto un problema sul compilatore AssemblyScript per questo, ma per il momento se fate questo tipo di operazioni nelle vostre mappature di subgraph, dovreste modificarle in modo da fare un controllo di null prima di esse.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // ora `n` è garantito essere un BigInt
+```
+
+### Inizializzazione del valore
+
+Se si dispone di codice come questo:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+Verrà compilato ma si interromperà in fase di esecuzione, perché il valore non è stato inizializzato, quindi assicuratevi che il vostro subgraph abbia inizializzato i suoi valori, in questo modo:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Inoltre, se si hanno proprietà nullable in un'entità GraphQL, come questa:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+E avete un codice simile a questo:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // inizializza già le proprietà non nulle
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Inizializzazione delle proprietà della classe
+
+Se si esportano classi con proprietà che sono altre classi (dichiarate dall'utente o dalla libreria standard) come questa:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Inizializzazione del Array
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+A seconda dei tipi utilizzati, ad esempio quelli nullable, e del modo in cui vi si accede, si potrebbe verificare un errore di runtime come questo:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Oppure si dovrebbe mutare tramite indice:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### Schema GraphQL
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Ora non è più possibile definire campi nei tipi che sono elenchi non nulli. Se si ha uno schema come questo:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Altro
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 84b81cbe700a7e2f97898360a78a53cca674381f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:02 -0500
Subject: [PATCH 1271/3820] New translations assemblyscript-migration-guide.mdx
 (Japanese)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/ja/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/ja/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ja/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..88e5aea91168
--- /dev/null
+++ b/website/pages/ja/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript マイグレーションガイド
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+これにより、サブグラフの開発者は、AS 言語と標準ライブラリの新しい機能を使用できるようになります。
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## 特徴
+
+### 新機能
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### 最適化
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### その他
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## アップグレードの方法
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. ガイドの残りの部分に従って、言語の変更を修正します。
+5. Run `codegen` and `deploy` again.
+
+## 変更点
+
+### ヌル可能性
+
+古いバージョンの AssemblyScript では、以下のようなコードを作ることができました:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+しかし、新しいバージョンでは、値が nullable であるため、次のようにチェックする必要があります:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+あるいは、次のように強制します:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+どちらを選択すべきか迷った場合は、常に安全なバージョンを使用することをお勧めします。 値が存在しない場合は、サブグラフハンドラの中で return を伴う初期の if 文を実行するとよいでしょう。
+
+### 変数シャドウイング
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+et a = 10
+let b = 20
+let a = a + b
+```
+
+しかし、現在はこれができなくなり、コンパイラは次のようなエラーを返します。
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+変数シャドウイングを行っていた場合は、重複する変数の名前を変更する必要があります。
+
+### Null 比較
+
+サブグラフのアップグレードを行うと、時々以下のようなエラーが発生することがあります。
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+== の代わりに != を実行している場合も同様です。
+
+### 鋳造
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+しかし、これは 2 つのシナリオでしか機能しません。
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- クラス継承のアップキャスティング（サブクラス → スーパークラス）
+
+例
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- クラス継承のダウンキャスト（スーパークラス → サブクラス）
+- スーパークラスを共有する 2 つの型の間
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+また、キャストを容易にするために、いくつかの型にスタティックメソッドを追加しました。
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### プロパティアクセスによる Nullability チェック
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ?
+```
+
+すると、このようなエラーが出力されます。
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+この問題を解決するには、そのプロパティアクセスのための変数を作成して、コンパイラが nullability check のマジックを行うようにします。
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data :)
+```
+
+### プロパティアクセスによるオペレーターオーバーロード
+
+たとえば、(プロパティ アクセスからの) null 許容型と null 非許容型を合計しようとすると、AssemblyScript コンパイラは、値の 1 つが null 許容であるというコンパイル時のエラー警告を表示する代わりに、黙ってコンパイルします。実行時にコードが壊れる可能性を与えます。
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+この件に関して、アセンブリ・スクリプト・コンパイラーに問題を提起しましたが、 今のところ、もしサブグラフ・マッピングでこの種の操作を行う場合には、 その前に NULL チェックを行うように変更してください。
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### 値の初期化
+
+もし、このようなコードがあった場合:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+これは、値が初期化されていないために起こります。したがって、次のようにサブグラフが値を初期化していることを確認してください。
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+また、以下のように GraphQL のエンティティに Nullable なプロパティがある場合も同様です。
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+そして、以下のようなコードになります:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### クラスのプロパティの初期化
+
+以下のように、他のクラス（自分で宣言したものや標準ライブラリで宣言したもの）のプロパティを持つクラスをエクスポートした場合、そのクラスのプロパティを初期化します:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### 配列の初期化
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+使用している型(例えば null 可能な型) とそのアクセス方法によっては、次のようなランタイムエラーに遭遇する可能性があります。
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+あるいは、インデックス経由で変異させるべきでしょう：
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQLスキーマ
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+この変更により、Non-Nullable Listのフィールドを型に定義することができなくなりました。仮に、以下のようなスキーマがあった場合：
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### その他
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 3b5de2886648bde0aa43f8a8ca5c1f3aa8469f19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:03 -0500
Subject: [PATCH 1272/3820] New translations assemblyscript-migration-guide.mdx
 (Korean)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/ko/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/ko/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ko/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..85f6903a6c69
--- /dev/null
+++ b/website/pages/ko/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript Migration Guide
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+That will enable subgraph developers to use newer features of the AS language and standard library.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Features
+
+### New functionality
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimizations
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Other
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## How to upgrade?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Follow the rest of the guide to fix the language breaking changes.
+5. Run `codegen` and `deploy` again.
+
+## Breaking changes
+
+### Nullability
+
+On the older version of AssemblyScript, you could create code like this:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+However on the newer version, because the value is nullable, it requires you to check, like this:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Or force it like this:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+If you are unsure which to choose, we recommend always using the safe version. If the value doesn't exist you might want to just do an early if statement with a return in you subgraph handler.
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+However now this isn't possible anymore, and the compiler returns this error:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+You'll need to rename your duplicate variables if you had variable shadowing.
+
+### Null Comparisons
+
+By doing the upgrade on your subgraph, sometimes you might get errors like these:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+The same applies if you're doing != instead of ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+However this only works in two scenarios:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting on class inheritance (subclass → superclass)
+
+Examples:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting on class inheritance (superclass → subclass)
+- Between two types that share a superclass
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Also we've added a few more static methods in some types to ease casting, they are:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Nullability check with property access
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+Which outputs this error:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Operator overloading with property access
+
+If you try to sum (for example) a nullable type (from a property access) with a non nullable one, the AssemblyScript compiler instead of giving a compile time error warning that one of the values is nullable, it just compiles silently, giving chance for the code to break at runtime.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+We've opened a issue on the AssemblyScript compiler for this, but for now if you do these kind of operations in your subgraph mappings, you should change them to do a null check before it.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Value initialization
+
+If you have any code like this:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+It will compile but break at runtime, that happens because the value hasn't been initialized, so make sure your subgraph has initialized their values, like this:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Also if you have nullable properties in a GraphQL entity, like this:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+And you have code similar to this:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Class property initialization
+
+If you export any classes with properties that are other classes (declared by you or by the standard library) like this:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Array initialization
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Or you should mutate it via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Other
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 4e5b5d656aeeeff638fa252e44672e785cfecb2f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:04 -0500
Subject: [PATCH 1273/3820] New translations assemblyscript-migration-guide.mdx
 (Dutch)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/nl/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/nl/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/nl/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..85f6903a6c69
--- /dev/null
+++ b/website/pages/nl/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript Migration Guide
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+That will enable subgraph developers to use newer features of the AS language and standard library.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Features
+
+### New functionality
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimizations
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Other
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## How to upgrade?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Follow the rest of the guide to fix the language breaking changes.
+5. Run `codegen` and `deploy` again.
+
+## Breaking changes
+
+### Nullability
+
+On the older version of AssemblyScript, you could create code like this:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+However on the newer version, because the value is nullable, it requires you to check, like this:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Or force it like this:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+If you are unsure which to choose, we recommend always using the safe version. If the value doesn't exist you might want to just do an early if statement with a return in you subgraph handler.
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+However now this isn't possible anymore, and the compiler returns this error:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+You'll need to rename your duplicate variables if you had variable shadowing.
+
+### Null Comparisons
+
+By doing the upgrade on your subgraph, sometimes you might get errors like these:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+The same applies if you're doing != instead of ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+However this only works in two scenarios:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting on class inheritance (subclass → superclass)
+
+Examples:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting on class inheritance (superclass → subclass)
+- Between two types that share a superclass
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Also we've added a few more static methods in some types to ease casting, they are:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Nullability check with property access
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+Which outputs this error:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Operator overloading with property access
+
+If you try to sum (for example) a nullable type (from a property access) with a non nullable one, the AssemblyScript compiler instead of giving a compile time error warning that one of the values is nullable, it just compiles silently, giving chance for the code to break at runtime.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+We've opened a issue on the AssemblyScript compiler for this, but for now if you do these kind of operations in your subgraph mappings, you should change them to do a null check before it.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Value initialization
+
+If you have any code like this:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+It will compile but break at runtime, that happens because the value hasn't been initialized, so make sure your subgraph has initialized their values, like this:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Also if you have nullable properties in a GraphQL entity, like this:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+And you have code similar to this:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Class property initialization
+
+If you export any classes with properties that are other classes (declared by you or by the standard library) like this:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Array initialization
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Or you should mutate it via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Other
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 3ca64e92d2ee72f665db75044a2e3b52df2519b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:05 -0500
Subject: [PATCH 1274/3820] New translations assemblyscript-migration-guide.mdx
 (Polish)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/pl/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/pl/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/pl/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..85f6903a6c69
--- /dev/null
+++ b/website/pages/pl/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript Migration Guide
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+That will enable subgraph developers to use newer features of the AS language and standard library.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Features
+
+### New functionality
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimizations
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Other
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## How to upgrade?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Follow the rest of the guide to fix the language breaking changes.
+5. Run `codegen` and `deploy` again.
+
+## Breaking changes
+
+### Nullability
+
+On the older version of AssemblyScript, you could create code like this:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+However on the newer version, because the value is nullable, it requires you to check, like this:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Or force it like this:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+If you are unsure which to choose, we recommend always using the safe version. If the value doesn't exist you might want to just do an early if statement with a return in you subgraph handler.
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+However now this isn't possible anymore, and the compiler returns this error:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+You'll need to rename your duplicate variables if you had variable shadowing.
+
+### Null Comparisons
+
+By doing the upgrade on your subgraph, sometimes you might get errors like these:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+The same applies if you're doing != instead of ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+However this only works in two scenarios:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting on class inheritance (subclass → superclass)
+
+Examples:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting on class inheritance (superclass → subclass)
+- Between two types that share a superclass
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Also we've added a few more static methods in some types to ease casting, they are:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Nullability check with property access
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+Which outputs this error:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Operator overloading with property access
+
+If you try to sum (for example) a nullable type (from a property access) with a non nullable one, the AssemblyScript compiler instead of giving a compile time error warning that one of the values is nullable, it just compiles silently, giving chance for the code to break at runtime.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+We've opened a issue on the AssemblyScript compiler for this, but for now if you do these kind of operations in your subgraph mappings, you should change them to do a null check before it.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Value initialization
+
+If you have any code like this:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+It will compile but break at runtime, that happens because the value hasn't been initialized, so make sure your subgraph has initialized their values, like this:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Also if you have nullable properties in a GraphQL entity, like this:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+And you have code similar to this:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Class property initialization
+
+If you export any classes with properties that are other classes (declared by you or by the standard library) like this:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Array initialization
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Or you should mutate it via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Other
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 59a0213b3d5e853c405435c79c44843dde357e94 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:06 -0500
Subject: [PATCH 1275/3820] New translations assemblyscript-migration-guide.mdx
 (Portuguese)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/pt/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/pt/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/pt/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..165055c46822
--- /dev/null
+++ b/website/pages/pt/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: Guia de Migração do AssemblyScript
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+Isto permitirá que os programadores de subgraph usem recursos mais novos da linguagem AS e da sua biblioteca normal.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Recursos
+
+### Novas funcionalidades
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Otimizações
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Outros
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## Como atualizar?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# caso o tenha instalado globalmente
+npm install --global @graphprotocol/graph-cli@latest
+
+# ou no seu subgraph se o tiver como dependência de desenvolvimento
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Siga o resto do guia para consertar as mudanças frágeis na linguagem.
+5. Run `codegen` and `deploy` again.
+
+## Breaking changes (mudanças frágeis)
+
+### Anulabilidade
+
+Na versão mais antiga do AssemblyScript, podias criar códigos assim:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+Mas na versão mais nova, como o valor é anulável, ele exige que confira, assim:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+...ou o force deste jeito:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+Se não tiver certeza de qual escolher, é sempre bom usar a versão segura. Se o valor não existir, pode fazer uma declaração <code>if</code> precoce com um retorno no seu handler de subgraph.
+
+### Sombreamento Varíavel
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+Porém, isto não é mais possível, e o compilador retorna este erro:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+Renomeie as suas variáveis duplicadas, se tinha o sombreamento variável.
+
+### Comparações de Nulos
+
+Ao fazer a atualização no seu subgraph, às vezes aparecem erros como este:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+O mesmo acontece se fizer o != em vez de ==.
+
+### Casting (Conversão de tipos)
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+Porém, isto só funciona em dois casos:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting em herança de classe (subclass → superclass)
+
+Exemplos:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting em herança de classe (superclass → subclass)
+- Entre dois tipos que compartilham uma superclasse
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove anulabilidade
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Também adicionamos alguns métodos estáticos em alguns tipos para facilitar o casting, sendo:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Checagem de anulabilidade com acesso à propriedade
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// ou
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+O que retorna este erro:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+Para consertar este problema, vale criar uma variável para aquele acesso à propriedade, para que o compilador faça a magia da checagem de anulabilidade:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Sobrecarga de operador com acesso à propriedade
+
+Se tentar somar (por exemplo) um tipo anulável (de um acesso de propriedade) com um não-anulável, em vez de soltar um aviso de erro de tempo de compilação a dizer que um dos valores é anulável, o compilador AssemblyScript só compilará em silêncio, o que abre chances para o código quebrar em meio ao tempo de execução.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // dá o erro de tempo de complação sobre anulabilidade
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // não dá erros de tempo de compilação como deveria
+```
+
+Nós abrimos um problema no compilador AssemblyScript para isto, mas por enquanto, se fizer estes tipos de operações nos seus mapeamentos de subgraph, vale mudá-las para fazer uma checagem de anulação antes delas.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // agora o `n` é garantido a ser um BigInt
+```
+
+### Inicialização de valor
+
+Se tiver algum código como este:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+Ele fará a compilação, mas quebrará no tempo de execução porque o valor não foi inicializado. Tenha certeza de que o seu subgraph inicializou os seus valores, como assim:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+E também se tiver propriedades anuláveis numa entidade GraphQL, como assim:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+E tiver código parecido com este:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // já inicializa propriedades não-anuláveis
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Iniciação de propriedade de classe
+
+Se exportar quaisquer classes com propriedades que sejam outras classes (declaradas por você ou pela biblioteca padrão) como esta:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// ou
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// ou
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Iniciação de arranjo
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Dependendo dos tipos que usa, por ex., anuláveis, e como os acessa, pode encontrar um erro de tempo de execução como este:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Ou pode mudá-lo através do index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### Schema GraphQL
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Agora não há mais como definir campos nos seus tipos que são Listas Não Anuláveis. Se tiver um schema como este:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Outros
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From e287eb0b2c721eea4687f4905acb206c2f135178 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:07 -0500
Subject: [PATCH 1276/3820] New translations assemblyscript-migration-guide.mdx
 (Russian)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/ru/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/ru/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ru/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..c52b3b97cda2
--- /dev/null
+++ b/website/pages/ru/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: Руководство по миграции AssemblyScript
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+Это позволит разработчикам субграфов использовать более новые возможности языка AS и стандартной библиотеки.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Особенности
+
+### Новый функционал
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Оптимизации
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Прочее
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## Как выполнить обновление?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# если он у Вас установлен глобально
+npm install --global @graphprotocol/graph-cli@latest
+
+# или в Вашем субграфе, если он у Вас как зависимость dev
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Следуйте остальной части руководства, чтобы исправить языковые изменения.
+5. Run `codegen` and `deploy` again.
+
+## Критические изменения
+
+### Обнуляемость
+
+В более старой версии AssemblyScript можно было создать такой код:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+Однако в новой версии, поскольку значение обнуляемо, требуется проверка, например, такая:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Или принудительно вот такая:
+
+```typescript
+let maybeValue = load()! // прерывается во время выполнения, если значение равно null
+
+maybeValue.aMethod()
+```
+
+Если Вы не уверены, что выбрать, мы рекомендуем всегда использовать безопасную версию. Если значение не существует, Вы можете просто выполнить раннее выражение if с возвратом в обработчике субграфа.
+
+### Затенение переменных
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+Однако теперь это больше невозможно, и компилятор возвращает эту ошибку:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+Вам нужно будет переименовать дублированные переменные, если Вы используете затенение переменных.
+
+### Нулевые сравнения
+
+Выполняя обновление своего субграфа, иногда Вы можете получить такие ошибки:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+Подобное относится к случаям, когда вместо == используется !=.
+
+### Кастинг
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+Однако это работает только в двух случаях:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Укрупнение по наследованию классов (subclass → superclass)
+
+Примеры:
+
+```typescript
+// примитивный кастинг
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Понижение уровня наследования классов (superclass → subclass)
+- Между двумя типами, имеющими общий супер класс
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// удалить значение NULL
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // безопасно удалить значение NULL
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Также мы добавили еще несколько статических методов в некоторые типы, чтобы облегчить кастинг:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Проверка нулевого значения с доступом к свойству
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// или
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // не компилируется
+```
+
+В результате чего выдается ошибка:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+Чтобы решить эту проблему, Вы можете создать переменную для доступа к этому свойству, чтобы компилятор мог выполнять проверку допустимости значений NULL:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // компилируется просто отлично :)
+```
+
+### Перегрузка оператора при доступе к свойствам
+
+Если Вы попытаетесь суммировать (например) тип, допускающий значение Null (из доступа к свойству), с типом, не допускающим значение Null, компилятор AssemblyScript вместо того, чтобы выдать предупреждение об ошибке компиляции, предупреждающую, что одно из значений допускает значение Null, просто компилируется молча, давая возможность сломать код во время выполнения.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // выдает ошибку времени компиляции о возможности обнуления
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // не выдает ошибок времени компиляции, как это должно быть
+```
+
+Мы открыли вопрос по этому поводу для компилятора AssemblyScript, но пока, если Вы выполняете подобные операции в своих мэппингах субграфов, Вам следует изменить их так, чтобы перед этим выполнялась проверка на нулевое значение.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // теперь `n` гарантированно будет BigInt
+```
+
+### Инициализация значения
+
+Если у Вас есть такой код:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+Он будет скомпилирован, но сломается во время выполнения. Это происходит из-за того, что значение не было инициализировано, поэтому убедитесь, что Ваш субграф инициализировал свои значения, например так:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Также, если у Вас есть свойства, допускающие значение NULL, в объекте GraphQL, например:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+И у Вас есть код, аналогичный этому:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // уже инициализирует свойства, не допускающие значения NULL
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Инициализация свойств класса
+
+Если Вы экспортируете какие-либо классы со свойствами, которые являются другими классами (декларированными Вами или стандартной библиотекой), то это выглядит следующим образом:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// или
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// или
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Инициализация массива
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+В зависимости от используемых типов, например, допускающих значение NULL, и способа доступа к ним, можно столкнуться с ошибкой времени выполнения, подобной этой:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Или Вы должны изменить его через индекс:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### Схема GraphQL
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Теперь Вы больше не можете определять поля в своих типах, которые являются списками, не допускающими значение NULL. Если у Вас такая схема:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Прочее
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 9dcdde73cbf19560e38b46b3f0ccf04085ae577f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:08 -0500
Subject: [PATCH 1277/3820] New translations assemblyscript-migration-guide.mdx
 (Swedish)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/sv/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/sv/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/sv/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..fc50d5646a33
--- /dev/null
+++ b/website/pages/sv/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript Migrationsguide
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+Det kommer att möjliggöra för undergrafutvecklare att använda nyare funktioner i AS-språket och standardbiblioteket.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Funktioner
+
+### Ny funktionalitet
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimeringar
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Annat
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## Hur uppgraderar du?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# om du har den globalt installerad
+npm install --global @graphprotocol/graph-cli@latest
+
+# eller i din subgraf om du har det som ett utvecklingsberoende
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Följ resten av guiden för att åtgärda språkbrytande ändringar.
+5. Run `codegen` and `deploy` again.
+
+## Språkbrytande ändringar
+
+### Nullbarhet
+
+I den äldre versionen av AssemblyScript kunde du skapa kod som detta:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+Men i den nyare versionen, eftersom värdet är nullable, måste du kontrollera, så här:
+
+```typescript
+let maybeValue = load();
+
+if (maybeValue) {
+  maybeValue.aMethod(); // `maybeValue` is not null anymore
+}
+```
+
+Eller gör så här:
+
+```typescript
+let maybeValue = load()!; // bryts i runtime om värdet är null
+
+maybeValue.aMethod()
+```
+
+Om du är osäker på vilken du ska välja, rekommenderar vi alltid att använda den säkra versionen. Om värdet inte finns kanske du bara vill göra ett tidigt villkorligt uttalande med en retur i din undergrafshanterare.
+
+### Variabelskuggning
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10;
+let b = 20;
+let a = a + b
+```
+
+Men nu är detta inte längre möjligt, och kompilatorn returnerar detta fel:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+Du måste döpa om dina duplicerade variabler om du hade variabelskuggning.
+
+### Jämförelser med nollvärden
+
+När du gör uppgraderingen av din subgraf kan du ibland få fel som dessa:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+Samma gäller om du använder != istället för ==.
+
+### Kasting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+Detta fungerar dock endast i två scenarier:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Uppkasting vid klassarv (underklass → överklass)
+
+Exempel:
+
+```typescript
+// primitive casting
+let a: usize = 10;
+let b: isize = 5;
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting vid arv av klasser (superklass → subklass)
+- Mellan två typer som delar en superklass
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// ta bort ogiltighet
+let previousBalance = AccountBalance.load(balanceId); // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance; // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Vi har också lagt till några fler statiska metoder i vissa typer för att underlätta kastning, de är:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Kontroll av nollställbarhet med tillgång till egendom
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = "data";
+
+let somethingOrElse = something ? something : "else";
+
+// or
+
+let somethingOrElse;
+
+if (something) {
+  somethingOrElse = something;
+} else {
+  somethingOrElse = "else";
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container();
+container.data = "data";
+
+let somethingOrElse: string = container.data ? container.data : "else"; // Kompilerar inte
+```
+
+Vilket ger detta fel:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+För att åtgärda problemet kan du skapa en variabel för den egenskapen så att kompilatorn kan utföra den magiska nollbarhetskontrollen:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container();
+container.data = "data";
+
+let data = container.data;
+
+let somethingOrElse: string = data ? data : "else"; // kompilerar helt okej :)
+```
+
+### Operatörsöverladdning med egenskapsaccess
+
+Om du försöker summera (till exempel) en nullable typ (från en property access) med en non nullable, kommer AssemblyScript-kompilatorn istället för att ge en kompileringsfelsvarning om att ett av värdena är nullable, bara att kompilera tyst, vilket gör att koden kan gå sönder vid körning.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator("+")
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2);
+let y: BigInt | null = null;
+
+x + y; // ge kompileringsfel om ogiltighet
+
+let wrapper = new Wrapper(y);
+
+wrapper.n = wrapper.n + x; // ger inte kompileringsfel som det borde
+```
+
+Vi har öppnat en fråga om AssemblyScript-kompilatorn för detta, men om du gör den här typen av operationer i dina subgraf-mappningar bör du ändra dem så att de gör en null-kontroll innan den.
+
+```typescript
+let wrapper = new Wrapper(y);
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0);
+}
+
+wrapper.n = wrapper.n + x; // nu är `n` garanterat ett BigInt
+```
+
+### Initialisering av värde
+
+Om du har någon kod som denna:
+
+```typescript
+var value: Type; // null
+value.x = 10;
+value.y = "content"
+```
+
+Det kommer att kompilera men brytas vid körning, det händer eftersom värdet inte har initialiserats, så se till att din subgraf har initialiserat sina värden, så här:
+
+```typescript
+var value = new Type(); // initialized
+value.x = 10;
+value.y = "content"
+```
+
+Även om du har nullable properties i en GraphQL-entitet, som denna:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+Och du har en kod som liknar den här:
+
+```typescript
+let total = Total.load("latest");
+
+if (total === null) {
+  total = new Total("latest")
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load("latest")
+
+if (total === null) {
+  total = new Total("latest")
+  total.amount = BigInt.fromI32(0);
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load("latest");
+
+if (total === null) {
+  total = new Total("latest"); // initierar redan icke-nullställbara egenskaper
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Initialisering av klassegenskaper
+
+Om du exporterar några klasser med egenskaper som är andra klasser (deklarerade av dig eller av standardbiblioteket) på det här sättet:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing;
+
+  constructor(value: Thing) {
+    this.value = value;
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing;
+}
+```
+
+### Initialisering av Array
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Beroende på vilka typer du använder, t.ex. nullable-typer, och hur du kommer åt dem, kan du stöta på ett runtime-fel som det här:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Eller så bör du mutera den via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL-schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Nu kan du inte längre definiera fält i dina typer som är Non-Nullable Lists. Om du har ett schema som detta:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Annat
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 46629e1013e745df237d524125ccd5cb17e150ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:10 -0500
Subject: [PATCH 1278/3820] New translations assemblyscript-migration-guide.mdx
 (Turkish)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..a8bb2e376807
--- /dev/null
+++ b/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript Migration Guide
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+That will enable subgraph developers to use newer features of the AS language and standard library.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Features
+
+### New functionality
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimizations
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Other
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## How to upgrade?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Follow the rest of the guide to fix the language breaking changes.
+5. Run `codegen` and `deploy` again.
+
+## Breaking changes
+
+### Nullability
+
+On the older version of AssemblyScript, you could create code like this:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+However on the newer version, because the value is nullable, it requires you to check, like this:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Or force it like this:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+If you are unsure which to choose, we recommend always using the safe version. If the value doesn't exist you might want to just do an early if statement with a return in you subgraph handler.
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+However now this isn't possible anymore, and the compiler returns this error:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+You'll need to rename your duplicate variables if you had variable shadowing.
+
+### Null Comparisons
+
+By doing the upgrade on your subgraph, sometimes you might get errors like these:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+The same applies if you're doing != instead of ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+However this only works in two scenarios:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting on class inheritance (subclass → superclass)
+
+Örnekler:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting on class inheritance (superclass → subclass)
+- Between two types that share a superclass
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Also we've added a few more static methods in some types to ease casting, they are:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Nullability check with property access
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+Which outputs this error:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Operator overloading with property access
+
+If you try to sum (for example) a nullable type (from a property access) with a non nullable one, the AssemblyScript compiler instead of giving a compile time error warning that one of the values is nullable, it just compiles silently, giving chance for the code to break at runtime.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+We've opened a issue on the AssemblyScript compiler for this, but for now if you do these kind of operations in your subgraph mappings, you should change them to do a null check before it.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Value initialization
+
+If you have any code like this:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+It will compile but break at runtime, that happens because the value hasn't been initialized, so make sure your subgraph has initialized their values, like this:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Also if you have nullable properties in a GraphQL entity, like this:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+And you have code similar to this:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Class property initialization
+
+If you export any classes with properties that are other classes (declared by you or by the standard library) like this:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Array initialization
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Or you should mutate it via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Other
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From dba0e8f328a2064b6342f5c0ab88315ad466949b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:11 -0500
Subject: [PATCH 1279/3820] New translations assemblyscript-migration-guide.mdx
 (Ukrainian)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/uk/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/uk/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/uk/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..85f6903a6c69
--- /dev/null
+++ b/website/pages/uk/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript Migration Guide
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+That will enable subgraph developers to use newer features of the AS language and standard library.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Features
+
+### New functionality
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimizations
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Other
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## How to upgrade?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Follow the rest of the guide to fix the language breaking changes.
+5. Run `codegen` and `deploy` again.
+
+## Breaking changes
+
+### Nullability
+
+On the older version of AssemblyScript, you could create code like this:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+However on the newer version, because the value is nullable, it requires you to check, like this:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Or force it like this:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+If you are unsure which to choose, we recommend always using the safe version. If the value doesn't exist you might want to just do an early if statement with a return in you subgraph handler.
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+However now this isn't possible anymore, and the compiler returns this error:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+You'll need to rename your duplicate variables if you had variable shadowing.
+
+### Null Comparisons
+
+By doing the upgrade on your subgraph, sometimes you might get errors like these:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+The same applies if you're doing != instead of ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+However this only works in two scenarios:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting on class inheritance (subclass → superclass)
+
+Examples:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting on class inheritance (superclass → subclass)
+- Between two types that share a superclass
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Also we've added a few more static methods in some types to ease casting, they are:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Nullability check with property access
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+Which outputs this error:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Operator overloading with property access
+
+If you try to sum (for example) a nullable type (from a property access) with a non nullable one, the AssemblyScript compiler instead of giving a compile time error warning that one of the values is nullable, it just compiles silently, giving chance for the code to break at runtime.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+We've opened a issue on the AssemblyScript compiler for this, but for now if you do these kind of operations in your subgraph mappings, you should change them to do a null check before it.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Value initialization
+
+If you have any code like this:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+It will compile but break at runtime, that happens because the value hasn't been initialized, so make sure your subgraph has initialized their values, like this:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Also if you have nullable properties in a GraphQL entity, like this:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+And you have code similar to this:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Class property initialization
+
+If you export any classes with properties that are other classes (declared by you or by the standard library) like this:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Array initialization
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Or you should mutate it via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Other
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From e88a18a4ab27dc4ea4c66386bc9b3b8e71c8a848 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:12 -0500
Subject: [PATCH 1280/3820] New translations assemblyscript-migration-guide.mdx
 (Chinese Simplified)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..77c37c29dd7d
--- /dev/null
+++ b/website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript 迁移指南
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+这将使子图开发人员能够使用 AS 语言和标准库的更新特性。
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## 特征
+
+### 新功能
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### 优化
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### 其他
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## 如何升级？
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. 参考指南的其余部分修复语言更改带来的问题。
+5. Run `codegen` and `deploy` again.
+
+## 重大变化
+
+### 可空性
+
+在旧版本的 AssemblyScript 上，您可以创建如下代码：
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+但是在较新的版本中，由于该值可以为空，因此需要您进行检查，如下所示：
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+或者像这样编写代码：
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+如果您不确定选择哪个，我们建议始终使用安全的方式。 如果该值不存在，您可能只想在您的子图处理程序中，尽早执行一个带有 return 的 if 语句进行检查。
+
+### 变量遮蔽
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+但是现在这不可能了，编译器会返回这个错误：
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+如果您有变量遮蔽的情况，则需要重命名重名变量。
+
+### 空值比较
+
+对子图进行升级后，有时您可能会遇到如下错误：
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+如果您使用 != 而不是 ==，这同样适用。
+
+### 强制转换
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+但是，这只适用于两种情况：
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- 在类继承时向上转换（子类 → 超类）
+
+例子：
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- 在类继承时向下转换（超类 → 子类）
+- 在共享超类的两种类型之间
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+我们还在某些类型中添加了一些静态方法来简化转换，它们是：
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### 使用属性访问进行可空性检查
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+输出此错误：
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+要解决此问题，您可以为该属性访问创建一个变量，以便编译器可以执行可空性检查：
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### 具有属性访问的运算符重载
+
+如果您尝试将可空类型（来自属性访问）与不可空类型相加，AssemblyScript 编译器不会给出编译时错误警告其中一个值可以为空，它只是静默编译，这会导致代码在运行时可能出现问题。
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+我们为此在 AssemblyScript 编译器上提出了一个 issue，但现在如果您在子图映射中执行此类操作，您应该在之前进行空值检查。
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### 值初始化
+
+如果您有这样的代码：
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+代码将编译成功，但在运行时会出现问题，这是因为值尚未初始化，因此请确保您的子图已初始化变量的值，如下所示：
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+此外，如果您在 GraphQL 实体中有可为空的属性，如下所示：
+
+```graphql
+type Total @entity {
+  id: Id!
+  amount: BigInt
+}
+```
+
+同时，您有类似这样的代码：
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### 类属性初始化
+
+如果您导出任何具有其他类（由您或标准库声明）的属性的类，如下所示：
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### 数组初始化
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+根据您使用的类型，例如可以为空的类型，以及访问它们的方式，您可能会遇到类似下面这样的运行时错误:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+或者，你可以通过索引对其进行改变:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL 模式
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+现在，您不再能够在类型中定义属于非空列表的字段。如果您有这样的模式:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### 其他
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 2f3841b7d9015e8db512495df6fa550cbdf6819e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:13 -0500
Subject: [PATCH 1281/3820] New translations assemblyscript-migration-guide.mdx
 (Urdu (Pakistan))

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/ur/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/ur/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/ur/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..8a354cb1c231
--- /dev/null
+++ b/website/pages/ur/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: اسمبلی سکرپٹ مائیگریشن گائیڈ
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+وہ سب گراف ڈویلپرز کو اسمبلی لینگوج اور سٹینڈرڈ لائبریری کی نئ خصوصیات استعمال کرنے پر فعال کرے گا.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## خصوصیات
+
+### نئ خصوصیت
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### اصلاح
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### دوسرا
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## اپ گریڈ کیسے کریں؟
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. زبان کو توڑنے والی تبدیلیوں کو ٹھیک کرنے کے لیے بقیہ گائیڈ پر عمل کریں.
+5. Run `codegen` and `deploy` again.
+
+## بریکنگ تبدیلیاں
+
+### کالعدم ہونا
+
+اسمبلی اسکرپٹ کے پرانے ورژن پر، آپ اس طرح کا کوڈ بنا سکتے ہیں:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+تاہم نئے ورژن پر، کیونکہ ویلیو کالعدم ہے، اس کے لیے آپ کو اس طرح چیک کرنے کی ضرورت ہے:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+یا اسے اس طرح فورس کریں:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+اگر آپ کو یقین نہیں ہے کہ کون سا انتخاب کرنا ہے، تو ہم ہمیشہ محفوظ ورژن استعمال کرنے کی تجویز کرتے ہیں۔ اگر ویلیو موجود نہیں ہے تو آپ اپنے سب گراف ہینڈلر میں واپسی کے ساتھ صرف ابتدائی اف سٹیٹمینٹ کرنا چاہتے ہیں.
+
+### متغیر شیڈونگ
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+تاہم اب یہ ممکن نہیں ہے، اور کمپائلر یہ غلطی واپس کرتا ہے:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+اگر آپ کے پاس متغیر شیڈونگ ہے تو آپ کو اپنے ڈپلیکیٹ متغیرات کا نام تبدیل کرنے کی ضرورت ہوگی.
+
+### کالعدم موازنہ
+
+اپنے سب گراف پر اپ گریڈ کرنے سے، بعض اوقات آپ کو اس طرح کی غلطیاں مل سکتی ہیں:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+اگر آپ == کی بجائے != کر رہے ہیں تو بھی یہی لاگو ہوتا ہے.
+
+### کاسٹنگ
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+تاہم یہ صرف دو صورتوں میں کام کرتا ہے:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- کلاس وراثت پر اپکاسٹنگ (سپر کلاس → سب کلاس)
+
+مثالیں:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- طبقاتی وراثت میں کمی ( سب کلاس → سپر کلاس)
+- دو قسموں کے درمیان جو ایک سپر کلاس کا اشتراک کرتے ہیں
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+نیز ہم نے کاسٹنگ کو آسان بنانے کے لیے کچھ اقسام میں کچھ مزید جامد طریقے شامل کیے ہیں، وہ یہ ہیں:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### پراپرٹی ایکسیس کے ساتھ منسوخی کی جانچ
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+جو اس غلطی کو ظاہر کرتا ہے:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+اس مسئلے کو حل کرنے کے لیے، آپ اس پراپرٹی تک رسائی کے لیے ایک متغیر بنا سکتے ہیں تاکہ مرتب کرنے والا منسوخی چیک میجک کر سکے:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### پراپرٹی ایکسیس کے ساتھ آپریٹر اوور لوڈنگ
+
+اگر آپ (مثال کے طور پر) ایک غیر منسوخ قسم (پراپرٹی ایکسیس سے) کو ایک غیر کالعدم کے ساتھ جمع کرنے کی کوشش کرتے ہیں، تو اسمبلی اسکرپٹ کمپائلر کمپائل ٹائم ایرر انتباہ دینے کے بجائے کہ ایک قدر کالعدم ہے، یہ صرف خاموشی سے مرتب کرتا ہے، موقع دیتے ہوئے رن ٹائم پر کوڈ کے ٹوٹنے کے لیے.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+ہم نے اس کے لیے اسمبلی اسکرپٹ کمپائلر پر ایک ایشو کھولا ہے، لیکن ابھی کے لیے اگر آپ اپنی سب گراف میپنگز میں اس قسم کی کارروائیاں کرتے ہیں، تو آپ کو اس سے پہلے ایک کالعدم چیک کرنے کے لیے انہیں تبدیل کرنا چاہیے.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### ویلیو کی ابتدا
+
+اگر آپ کے پاس اس طرح کا کوڈ ہے:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+یہ کمپائل کرے گا لیکن رن ٹائم پر ٹوٹ جائے گا، ایسا اس لیے ہوتا ہے کیونکہ ویلیو شروع نہیں کی گئی ہے، اس لیے یقینی بنائیں کہ آپ کے سب گراف نے اپنی ویلیوس کی ابتدا کی ہے، اس طرح:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+نیز اگر آپ کے پاس گراف کیو ایل ہستی میں کالعدم خصوصیات ہیں، اس طرح:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+اور آپ کے پاس اس سے ملتا جلتا کوڈ ہے:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### کلاس پراپرٹی کی شروعات
+
+اگر آپ ایسی خصوصیات کے ساتھ کسی بھی کلاس کو برآمد کرتے ہیں جو دوسری کلاسیں ہیں (آپ کے ذریعہ یا معیاری لائبریری کے ذریعہ اعلان کردہ) اس طرح:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### ایرے شروع کرنا
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+ان اقسام پر منحصر ہے جو آپ استعمال کر رہے ہیں، مثال کے طور پر کالعدم، اور آپ ان تک کیسے رسائی حاصل کر رہے ہیں، آپ کو رن ٹائم غلطی کا سامنا کرنا پڑ سکتا ہے اس طرح:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+یا آپ کو اسے انڈیکس کے ذریعے تبدیل کرنا چاہئے:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### گراف کیو ایل اسکیما
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+اب آپ اپنی اقسام میں ان فیلڈز کی وضاحت نہیں کر سکتے جو کہ غیر منسوخ فہرست ہیں۔ اگر آپ کے پاس اس طرح کا سکیما ہے:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### دوسرا
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 3ffabe7390729833325c38297b51d5d74b8acc97 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:14 -0500
Subject: [PATCH 1282/3820] New translations assemblyscript-migration-guide.mdx
 (Vietnamese)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/vi/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/vi/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/vi/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..20f0fcfaf8e8
--- /dev/null
+++ b/website/pages/vi/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: Hướng dẫn Di chuyển AssemblyScript
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+Điều đó sẽ cho phép các nhà phát triển subgrap sử dụng các tính năng mới hơn của ngôn ngữ AS và thư viện chuẩn.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Các đặc điểm
+
+### Chức năng mới
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Tối ưu hóa
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Khác
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## Làm thế nào để nâng cấp?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# nếu bạn đã cài đặt nó trên toàn cầu
+npm install --global @graphprotocol/graph-cli@latest
+
+# hoặc trong subgraph của bạn nếu bạn có nó như một phụ thuộc của nhà phát triển
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Làm theo phần còn lại của hướng dẫn để sửa các thay đổi về lỗi ngôn ngữ.
+5. Run `codegen` and `deploy` again.
+
+## Thay đổi đột phá
+
+### Vô hiệu
+
+Trên phiên bản AssemblyScript cũ hơn, bạn có thể tạo mã như sau:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+Tuy nhiên, trên phiên bản mới hơn, vì giá trị là nullable, nó yêu cầu bạn kiểm tra, như sau:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Hoặc buộc nó như thế này:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+Nếu bạn không chắc nên chọn cái nào, chúng tôi khuyên bạn nên luôn sử dụng phiên bản an toàn. Nếu giá trị không tồn tại, bạn có thể chỉ muốn thực hiện câu lệnh if sớm với trả về trong trình xử lý subgraph của bạn.
+
+### Variable Shadowing (Che khuất Biến)
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+Tuy nhiên, bây giờ điều này không còn khả thi nữa và trình biên dịch trả về lỗi này:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+Bạn sẽ cần đổi tên các biến trùng lặp của mình nếu bạn có che biến.
+
+### So sánh Null
+
+Bằng cách thực hiện nâng cấp trên subgraph của bạn, đôi khi bạn có thể gặp các lỗi như sau:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+Điều tương tự cũng áp dụng nếu bạn đang làm != Thay vì ==.
+
+### Ép kiểu (Casting)
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+Tuy nhiên, điều này chỉ hoạt động trong hai trường hợp:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting về kế thừa lớp (lớp con → lớp cha) (subclass → superclass)
+
+Các ví dụ:
+
+```typescript
+// primitive casting (ép kiểu nguyên bản)
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting về kế thừa lớp (lớp con → lớp cha) (subclass → superclass)
+- Giữa hai loại chia sẻ lớp cha
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// loại bỏ khả năng vô hiệu
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Ngoài ra, chúng tôi đã thêm một vài phương thức tĩnh trong một số kiểu để dễ dàng ép kiểu, chúng là:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Kiểm tra tính vô hiệu với quyền truy cập thuộc tính
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// hoặc
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // không biên dịch
+```
+
+Đầu ra lỗi này:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+Để khắc phục sự cố này, bạn có thể tạo một biến cho quyền truy cập thuộc tính đó để trình biên dịch có thể thực hiện phép thuật kiểm tra tính nullability:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // biên dịch tốt :)
+```
+
+### Quá tải toán tử với quyền truy cập thuộc tính
+
+Nếu bạn cố gắng tính tổng (ví dụ) một kiểu nullable (từ quyền truy cập thuộc tính) với một kiểu không thể nullable, trình biên dịch AssemblyScript thay vì đưa ra cảnh báo lỗi thời gian biên dịch rằng một trong các giá trị là nullable, nó chỉ biên dịch âm thầm, tạo cơ hội để mã bị phá vỡ trong thời gian chạy.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+Chúng tôi đã giải quyết vấn đề trên trình biên dịch AssemblyScript cho vấn đề này, nhưng hiện tại nếu bạn thực hiện các loại hoạt động này trong ánh xạ subgraph của mình, bạn nên thay đổi chúng để thực hiện kiểm tra rỗng trước nó.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Khởi tạo giá trị
+
+Nếu bạn có bất kỳ mã nào như thế này:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+Nó sẽ biên dịch nhưng bị hỏng trong thời gian chạy, điều đó xảy ra vì giá trị chưa được khởi tạo, vì vậy hãy đảm bảo rằng subgraph của bạn đã khởi tạo các giá trị của chúng, như sau:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Ngoài ra, nếu bạn có thuộc tính nullable trong thực thể GraphQL, như sau:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+Và bạn có mã tương tự như sau:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Khởi tạo thuộc tính lớp
+
+Nếu bạn xuất bất kỳ lớp nào có thuộc tính là các lớp khác (do bạn hoặc thư viện chuẩn khai báo) như thế này:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Array initialization
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Or you should mutate it via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Khác
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 180812d3da55be1c8623ba422404dbea9e76188e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:15 -0500
Subject: [PATCH 1283/3820] New translations assemblyscript-migration-guide.mdx
 (Marathi)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/mr/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/mr/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/mr/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..b989c4de4c11
--- /dev/null
+++ b/website/pages/mr/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript Migration Guide
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+हे सबग्राफ विकसकांना AS भाषा आणि मानक लायब्ररीची नवीन वैशिष्ट्ये वापरण्यास सक्षम करेल.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Features
+
+### New functionality
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimizations
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Other
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## How to upgrade?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Follow the rest of the guide to fix the language breaking changes.
+5. Run `codegen` and `deploy` again.
+
+## Breaking changes
+
+### Nullability
+
+On the older version of AssemblyScript, you could create code like this:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+However on the newer version, because the value is nullable, it requires you to check, like this:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Or force it like this:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+तुम्हाला कोणती निवड करायची याची खात्री नसल्यास, आम्ही नेहमी सुरक्षित आवृत्ती वापरण्याची शिफारस करतो. जर मूल्य अस्तित्वात नसेल तर तुम्ही तुमच्या सबग्राफ हँडलरमध्ये रिटर्नसह फक्त लवकर इफ स्टेटमेंट करू इच्छित असाल.
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+However now this isn't possible anymore, and the compiler returns this error:
+
+```typescript
+त्रुटी TS2451: ब्लॉक-स्कोप केलेले व्हेरिएबल 'a' पुन्हा घोषित करू शकत नाही
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+You'll need to rename your duplicate variables if you had variable shadowing.
+
+### Null Comparisons
+
+By doing the upgrade on your subgraph, sometimes you might get errors like these:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+The same applies if you're doing != instead of ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+However this only works in two scenarios:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting on class inheritance (subclass → superclass)
+
+उदाहरणे:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting on class inheritance (superclass → subclass)
+- Between two types that share a superclass
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Also we've added a few more static methods in some types to ease casting, they are:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Nullability check with property access
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+Which outputs this error:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Operator overloading with property access
+
+जर तुम्ही (उदाहरणार्थ) रद्द करता येण्याजोगा प्रकार (प्रॉपर्टी ऍक्सेसमधून) नॉन-नलेबल असलेल्या प्रकाराची बेरीज करण्याचा प्रयत्न केला, तर असेंबलीस्क्रिप्ट कंपाइलर संकलित वेळेची त्रुटी चेतावणी देण्याऐवजी मूल्यांपैकी एक रद्द करण्यायोग्य आहे, तो संधी देऊन शांतपणे संकलित करतो. कोड रनटाइममध्ये खंडित होण्यासाठी.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+आम्ही यासाठी असेंबलीस्क्रिप्ट कंपायलरवर एक समस्या उघडली आहे, परंतु आत्ता तुम्ही तुमच्या सबग्राफ मॅपिंगमध्ये अशा प्रकारचे ऑपरेशन करत असल्यास, तुम्ही त्यापूर्वी शून्य तपासणी करण्यासाठी ते बदलले पाहिजेत.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Value initialization
+
+If you have any code like this:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+It will compile but break at runtime, that happens because the value hasn't been initialized, so make sure your subgraph has initialized their values, like this:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Also if you have nullable properties in a GraphQL entity, like this:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+And you have code similar to this:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Class property initialization
+
+If you export any classes with properties that are other classes (declared by you or by the standard library) like this:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Array initialization
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Or you should mutate it via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Other
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From e921622b25f606562bae26fa24baa53e701b1aa7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:16 -0500
Subject: [PATCH 1284/3820] New translations assemblyscript-migration-guide.mdx
 (Hindi)

---
 .../assemblyscript-migration-guide.mdx        | 523 ++++++++++++++++++
 1 file changed, 523 insertions(+)
 create mode 100644 website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..dd7cfd2e6444
--- /dev/null
+++ b/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,523 @@
+---
+title: असेंबलीस्क्रिप्ट माइग्रेशन गाइड
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+यह सबग्राफ डेवलपर्स को एएस भाषा और मानक पुस्तकालय की नई सुविधाओं का उपयोग करने में सक्षम करेगा।
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## विशेषताएँ
+
+### नई कार्यक्षमता
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### अनुकूलन
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### अन्य
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## कैसे करें अपग्रेड?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. भाषा संबंधी परिवर्तनों को ठीक करने के लिए शेष मार्गदर्शिका का पालन करें।
+5. Run `codegen` and `deploy` again.
+
+## ब्रेकिंग परिवर्तन
+
+### Nullability
+
+असेंबलीस्क्रिप्ट के पुराने संस्करण पर, आप इस तरह कोड बना सकते हैं:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+हालाँकि नए संस्करण पर, क्योंकि मान अशक्त है, इसके लिए आपको जाँच करने की आवश्यकता है, जैसे:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+या इसे इस तरह मजबूर करें:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+यदि आप अनिश्चित हैं कि किसे चुनना है, तो हम हमेशा सुरक्षित संस्करण का उपयोग करने की सलाह देते हैं। यदि मान मौजूद नहीं है, तो आप अपने सबग्राफ हैंडलर में वापसी के साथ एक शुरुआती if स्टेटमेंट करना चाहते हैं।
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+हालाँकि अब यह संभव नहीं है, और संकलक इस त्रुटि को लौटाता है:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+यदि आपके पास वेरिएबल शैडोइंग है, तो आपको अपने डुप्लिकेट वेरिएबल्स का नाम बदलने की आवश्यकता होगी।
+
+### Null Comparisons
+
+अपने सबग्राफ पर अपग्रेड करने से, कभी-कभी आपको इस तरह की त्रुटियाँ मिल सकती हैं:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+यदि आप == के बजाय != कर रहे हैं तो वही लागू होता है।
+
+### कास्टिंग
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+However this only works in two scenarios:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- क्लास इनहेरिटेंस (सबक्लास → सुपरक्लास) पर अपकास्टिंग
+
+उदाहरण:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- क्लास इनहेरिटेंस (सुपरक्लास → सबक्लास) पर डाउनकास्टिंग
+- एक सुपरक्लास साझा करने वाले दो प्रकारों के बीच
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+साथ ही, हमने कास्टिंग को आसान बनाने के लिए कुछ प्रकारों में कुछ और स्थैतिक विधियाँ जोड़ी हैं, वे हैं:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Nullability check with property access
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+जो इस त्रुटि को आउटपुट करता है:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+```
+
+इस समस्या को ठीक करने के लिए, आप उस प्रॉपर्टी एक्सेस के लिए एक वेरिएबल बना सकते हैं ताकि कंपाइलर अशक्तता जांच जादू कर सके:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### प्रॉपर्टी एक्सेस के साथ ऑपरेटर ओवरलोडिंग
+
+यदि आप एक अशक्त प्रकार के साथ एक अशक्त प्रकार (एक संपत्ति के उपयोग से) का योग करने की कोशिश करते हैं, तो असेंबलीस्क्रिप्ट कंपाइलर एक संकलन समय त्रुटि चेतावनी देने के बजाय यह चेतावनी देता है कि मानों में से एक अशक्त है, यह सिर्फ चुपचाप संकलित करता है, मौका देता है कोड रनटाइम पर टूटने के लिए।
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+हमने इसके लिए असेंबलीस्क्रिप्ट कंपाइलर पर एक मुद्दा खोला है, लेकिन अभी के लिए यदि आप अपने सबग्राफ मैपिंग में इस तरह के ऑपरेशन करते हैं, तो आपको इससे पहले एक अशक्त जांच करने के लिए उन्हें बदलना चाहिए।
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### मूल्य आरंभीकरण
+
+यदि आपके पास ऐसा कोई कोड है:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+यह संकलित होगा लेकिन रनटाइम पर टूट जाएगा, ऐसा इसलिए होता है क्योंकि मान प्रारंभ नहीं किया गया है, इसलिए सुनिश्चित करें कि आपके सबग्राफ ने उनके मानों को प्रारंभ किया है, जैसे:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+इसके अलावा, यदि आपके पास एक ग्राफक्यूएल इकाई में अशक्त गुण हैं, जैसे:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+और आपके पास इसके समान कोड है:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### क्लास प्रॉपर्टी इनिशियलाइज़ेशन
+
+यदि आप किसी भी वर्ग को गुणों के साथ निर्यात करते हैं जो अन्य वर्ग हैं (आपके द्वारा या मानक पुस्तकालय द्वारा घोषित) इस तरह:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### सरणी आरंभीकरण
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+आपके द्वारा उपयोग किए जा रहे प्रकारों के आधार पर, उदाहरण के लिए अशक्त वाले, और आप उन्हें कैसे एक्सेस कर रहे हैं, आपको इस तरह की रनटाइम त्रुटि का सामना करना पड़ सकता है:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+या आपको इसे इंडेक्स के माध्यम से बदलना चाहिए:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### ग्राफक्यूएल स्कीमा
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+अब आप अपने प्रकारों में उन क्षेत्रों को परिभाषित नहीं कर सकते हैं जो गैर-शून्य सूची हैं। यदि आपके पास ऐसा स्कीमा है:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### अन्य
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 736c4b996c62f21e3fa7b39b5e32e220373fb9ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:17 -0500
Subject: [PATCH 1285/3820] New translations assemblyscript-migration-guide.mdx
 (Swahili)

---
 .../assemblyscript-migration-guide.mdx        | 524 ++++++++++++++++++
 1 file changed, 524 insertions(+)
 create mode 100644 website/pages/sw/resources/release-notes/assemblyscript-migration-guide.mdx

diff --git a/website/pages/sw/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/sw/resources/release-notes/assemblyscript-migration-guide.mdx
new file mode 100644
index 000000000000..85f6903a6c69
--- /dev/null
+++ b/website/pages/sw/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -0,0 +1,524 @@
+---
+title: AssemblyScript Migration Guide
+---
+
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+
+That will enable subgraph developers to use newer features of the AS language and standard library.
+
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+
+## Features
+
+### New functionality
+
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+
+### Optimizations
+
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+
+### Other
+
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+
+## How to upgrade?
+
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+
+```yaml
+...
+dataSources:
+  ...
+    mapping:
+      ...
+      apiVersion: 0.0.6
+      ...
+```
+
+2. Update the `graph-cli` you're using to the `latest` version by running:
+
+```bash
+# if you have it globally installed
+npm install --global @graphprotocol/graph-cli@latest
+
+# or in your subgraph if you have it as a dev dependency
+npm install --save-dev @graphprotocol/graph-cli@latest
+```
+
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+
+```bash
+npm install --save @graphprotocol/graph-ts@latest
+```
+
+4. Follow the rest of the guide to fix the language breaking changes.
+5. Run `codegen` and `deploy` again.
+
+## Breaking changes
+
+### Nullability
+
+On the older version of AssemblyScript, you could create code like this:
+
+```typescript
+function load(): Value | null { ... }
+
+let maybeValue = load();
+maybeValue.aMethod();
+```
+
+However on the newer version, because the value is nullable, it requires you to check, like this:
+
+```typescript
+let maybeValue = load()
+
+if (maybeValue) {
+  maybeValue.aMethod() // `maybeValue` is not null anymore
+}
+```
+
+Or force it like this:
+
+```typescript
+let maybeValue = load()! // breaks in runtime if value is null
+
+maybeValue.aMethod()
+```
+
+If you are unsure which to choose, we recommend always using the safe version. If the value doesn't exist you might want to just do an early if statement with a return in you subgraph handler.
+
+### Variable Shadowing
+
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+
+```typescript
+let a = 10
+let b = 20
+let a = a + b
+```
+
+However now this isn't possible anymore, and the compiler returns this error:
+
+```typescript
+ERROR TS2451: Cannot redeclare block-scoped variable 'a'
+
+ let a = a + b;
+ ~~~~~~~~~~~~~
+in assembly/index.ts(4,3)
+```
+
+You'll need to rename your duplicate variables if you had variable shadowing.
+
+### Null Comparisons
+
+By doing the upgrade on your subgraph, sometimes you might get errors like these:
+
+```typescript
+ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
+     if (decimals == null) {
+                     ~~~~
+ in src/mappings/file.ts(41,21)
+```
+
+To solve you can simply change the `if` statement to something like this:
+
+```typescript
+  if (!decimals) {
+
+  // or
+
+  if (decimals === null) {
+```
+
+The same applies if you're doing != instead of ==.
+
+### Casting
+
+The common way to do casting before was to just use the `as` keyword, like this:
+
+```typescript
+let byteArray = new ByteArray(10)
+let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+```
+
+However this only works in two scenarios:
+
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Upcasting on class inheritance (subclass → superclass)
+
+Examples:
+
+```typescript
+// primitive casting
+let a: usize = 10
+let b: isize = 5
+let c: usize = a + (b as usize)
+```
+
+```typescript
+// upcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <Uint8Array>bytes // same as: bytes as Uint8Array
+```
+
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+
+- Downcasting on class inheritance (superclass → subclass)
+- Between two types that share a superclass
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+// <Bytes>uint8Array // breaks in runtime :(
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+// <ByteArray>bytes // breaks in runtime :(
+```
+
+For those cases, you can use the `changetype<T>` function:
+
+```typescript
+// downcasting on class inheritance
+class Bytes extends Uint8Array {}
+
+let uint8Array = new Uint8Array(2)
+changetype<Bytes>(uint8Array) // works :)
+```
+
+```typescript
+// between two types that share a superclass
+class Bytes extends Uint8Array {}
+class ByteArray extends Uint8Array {}
+
+let bytes = new Bytes(2)
+changetype<ByteArray>(bytes) // works :)
+```
+
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+
+```typescript
+// remove nullability
+let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
+
+if (previousBalance != null) {
+  return previousBalance as AccountBalance // safe remove null
+}
+
+let newBalance = new AccountBalance(balanceId)
+```
+
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+
+Also we've added a few more static methods in some types to ease casting, they are:
+
+- Bytes.fromByteArray
+- Bytes.fromUint8Array
+- BigInt.fromByteArray
+- ByteArray.fromBigInt
+
+### Nullability check with property access
+
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+
+```typescript
+let something: string | null = 'data'
+
+let somethingOrElse = something ? something : 'else'
+
+// or
+
+let somethingOrElse
+
+if (something) {
+  somethingOrElse = something
+} else {
+  somethingOrElse = 'else'
+}
+```
+
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+```
+
+Which outputs this error:
+
+```typescript
+ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
+
+   let somethingOrElse: string = container.data ? container.data : "else";
+                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+
+To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
+
+```typescript
+class Container {
+  data: string | null
+}
+
+let container = new Container()
+container.data = 'data'
+
+let data = container.data
+
+let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+```
+
+### Operator overloading with property access
+
+If you try to sum (for example) a nullable type (from a property access) with a non nullable one, the AssemblyScript compiler instead of giving a compile time error warning that one of the values is nullable, it just compiles silently, giving chance for the code to break at runtime.
+
+```typescript
+class BigInt extends Uint8Array {
+  @operator('+')
+  plus(other: BigInt): BigInt {
+    // ...
+  }
+}
+
+class Wrapper {
+  public constructor(public n: BigInt | null) {}
+}
+
+let x = BigInt.fromI32(2)
+let y: BigInt | null = null
+
+x + y // give compile time error about nullability
+
+let wrapper = new Wrapper(y)
+
+wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+```
+
+We've opened a issue on the AssemblyScript compiler for this, but for now if you do these kind of operations in your subgraph mappings, you should change them to do a null check before it.
+
+```typescript
+let wrapper = new Wrapper(y)
+
+if (!wrapper.n) {
+  wrapper.n = BigInt.fromI32(0)
+}
+
+wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+```
+
+### Value initialization
+
+If you have any code like this:
+
+```typescript
+var value: Type // null
+value.x = 10
+value.y = 'content'
+```
+
+It will compile but break at runtime, that happens because the value hasn't been initialized, so make sure your subgraph has initialized their values, like this:
+
+```typescript
+var value = new Type() // initialized
+value.x = 10
+value.y = 'content'
+```
+
+Also if you have nullable properties in a GraphQL entity, like this:
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt
+}
+```
+
+And you have code similar to this:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest')
+  total.amount = BigInt.fromI32(0)
+}
+
+total.tokens = total.tokens + BigInt.fromI32(1)
+```
+
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+
+```graphql
+type Total @entity {
+  id: Bytes!
+  amount: BigInt!
+}
+```
+
+```typescript
+let total = Total.load('latest')
+
+if (total === null) {
+  total = new Total('latest') // already initializes non-nullable properties
+}
+
+total.amount = total.amount + BigInt.fromI32(1)
+```
+
+### Class property initialization
+
+If you export any classes with properties that are other classes (declared by you or by the standard library) like this:
+
+```typescript
+class Thing {}
+
+export class Something {
+  value: Thing
+}
+```
+
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+
+```typescript
+export class Something {
+  constructor(public value: Thing) {}
+}
+
+// or
+
+export class Something {
+  value: Thing
+
+  constructor(value: Thing) {
+    this.value = value
+  }
+}
+
+// or
+
+export class Something {
+  value!: Thing
+}
+```
+
+### Array initialization
+
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+```
+
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+
+```
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+```
+
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+
+```typescript
+let arr = new Array<string>(0) // []
+
+arr.push('something') // ["something"]
+```
+
+Or you should mutate it via index:
+
+```typescript
+let arr = new Array<string>(5) // ["", "", "", "", ""]
+
+arr[0] = 'something' // ["something", "", "", "", ""]
+```
+
+### GraphQL schema
+
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+
+Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something]! # no longer valid
+}
+```
+
+You'll have to add an `!` to the member of the List type, like this:
+
+```graphql
+type Something @entity {
+  id: Bytes!
+}
+
+type MyEntity @entity {
+  id: Bytes!
+  invalidField: [Something!]! # valid
+}
+```
+
+This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+
+### Other
+
+- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From b3d0b660d373ac526c481326422c50e2e91ff0e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:19 -0500
Subject: [PATCH 1286/3820] New translations
 graphql-validations-migration-guide.mdx (Romanian)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/ro/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/ro/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/ro/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..4d909e8970a8
--- /dev/null
+++ b/website/pages/ro/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL Validations migration guide
+---
+
+Soon `graph-node` will support 100% coverage of the [GraphQL Validations specification](https://spec.graphql.org/June2018/#sec-Validation).
+
+Previous versions of `graph-node` did not support all validations and provided more graceful responses - so, in cases of ambiguity, `graph-node` was ignoring invalid GraphQL operations components.
+
+GraphQL Validations support is the pillar for the upcoming new features and the performance at scale of The Graph Network.
+
+It will also ensure determinism of query responses, a key requirement on The Graph Network.
+
+**Enabling the GraphQL Validations will break some existing queries** sent to The Graph API.
+
+To be compliant with those validations, please follow the migration guide.
+
+> ⚠️ If you do not migrate your queries before the validations are rolled out, they will return errors and possibly break your frontends/clients.
+
+## Migration guide
+
+You can use the CLI migration tool to find any issues in your GraphQL operations and fix them. Alternatively you can update the endpoint of your GraphQL client to use the `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` endpoint. Testing your queries against this endpoint will help you find the issues in your queries.
+
+> Not all subgraphs will need to be migrated, if you are using [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) or [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), they already ensure that your queries are valid.
+
+## Migration CLI tool
+
+**Most of the GraphQL operations errors can be found in your codebase ahead of time.**
+
+For this reason, we provide a smooth experience for validating your GraphQL operations during development or in CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) is a simple CLI tool that helps validate GraphQL operations against a given schema.
+
+### **Getting started**
+
+You can run the tool as follows:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notes:**
+
+- Set or replace $GITHUB_USER, $SUBGRAPH_NAME with the appropriate values. Like: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- The preview schema URL (https://api-next.thegraph.com/) provided is heavily rate-limited and will be sunset once all users have migrated to the new version. **Do not use it in production.**
+- Operations are identified in files with the following extensions [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### CLI output
+
+The `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI tool will output any GraphQL operations errors as follows:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+For each error, you will find a description, file path and position, and a link to a solution example (see the following section).
+
+## Run your local queries against the preview schema
+
+We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on.
+
+You can try out queries by sending them to:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+or
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+To work on queries that have been flagged as having validation errors, you can use your favorite GraphQL query tool, like Altair or [GraphiQL](https://cloud.hasura.io/public/graphiql), and try your query out. Those tools will also mark those errors in their UI, even before you run it.
+
+## How to solve issues
+
+Below, you will find all the GraphQL validations errors that could occur on your existing GraphQL operations.
+
+### GraphQL variables, operations, fragments, or arguments must be unique
+
+We applied rules for ensuring that an operation includes a unique set of GraphQL variables, operations, fragments, and arguments.
+
+A GraphQL operation is only valid if it does not contain any ambiguity.
+
+To achieve that, we need to ensure that some components in your GraphQL operation must be unique.
+
+Here's an example of a few invalid operations that violates these rules:
+
+**Duplicate Query name (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Or name the two queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Overlapping Fields
+
+A GraphQL selection set is considered valid only if it correctly resolves the eventual result set.
+
+If a specific selection set, or a field, creates ambiguity either by the selected field or by the arguments used, the GraphQL service will fail to validate the operation.
+
+Here are a few examples of invalid operations that violate this rule:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Also, in more complex use-cases, you might violate this rule by using two fragments that might cause a conflict in the eventually expected set:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[You can read more about the algorithm here.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Unused Variables or Fragments
+
+A GraphQL operation is also considered valid only if all operation-defined components (variables, fragments) are used.
+
+Here are a few examples for GraphQL operations that violates these rules:
+
+**Unused variable** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Invalid or missing Selection-Set (#ScalarLeafsRule)
+
+Also, a GraphQL field selection is only valid if the following is validated:
+
+- An object field must-have selection set specified.
+- An edge field (scalar, enum) must not have a selection set specified.
+
+Here are a few examples of violations of these rules with the following Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Incorrect Arguments values (#VariablesInAllowedPositionRule)
+
+GraphQL operations that pass hard-coded values to arguments must be valid, based on the value defined in the schema.
+
+Here are a few examples of invalid operations that violate these rules:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Unknown Type, Variable, Fragment, or Directive (#UnknownX)
+
+The GraphQL API will raise an error if any unknown type, variable, fragment, or directive is used.
+
+Those unknown references must be fixed:
+
+- rename if it was a typo
+- otherwise, remove
+
+### Fragment: invalid spread or definition
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+
+A Fragment cannot be spread on a non-applicable type.
+
+Example, we cannot apply a `Cat` fragment to the `Dog` type:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)**
+
+All Fragment must be defined upon (using `on ...`) a composite type, in short: object, interface, or union.
+
+The following examples are invalid, since defining fragments on scalars is invalid.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Directives usage
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+
+Only GraphQL directives (`@...`) supported by The Graph API can be used.
+
+Here is an example with The GraphQL supported directives:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` are not supported._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+
+The directives supported by The Graph can only be used once per location.
+
+The following is invalid (and redundant):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 2ea133746bb1c080f6a1ace72067cfe8e013e5d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:20 -0500
Subject: [PATCH 1287/3820] New translations
 graphql-validations-migration-guide.mdx (French)

---
 .../graphql-validations-migration-guide.mdx   | 536 ++++++++++++++++++
 1 file changed, 536 insertions(+)
 create mode 100644 website/pages/fr/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/fr/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/fr/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..567231e0bedf
--- /dev/null
+++ b/website/pages/fr/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,536 @@
+---
+title: Guide de migration des validations GraphQL
+---
+
+Bientôt, `graph-node` supportera 100% de la couverture de la [Spécification des validations GraphQL] (https://spec.graphql.org/June2018/#sec-Validation).
+
+Les versions précédentes de `graph-node` ne prenaient pas en charge toutes les validations et fournissaient des réponses plus gracieuses - ainsi, en cas d'ambiguïté, `graph-node` ignorait les composants d'opérations GraphQL non valides.
+
+La prise en charge de GraphQL Validations est le pilier des nouvelles fonctionnalités à venir et des performances à grande échelle de The Graph Network.
+
+Il garantira également le déterminisme des réponses aux requêtes, une exigence clé sur The Graph Network.
+
+**L'activation des validations GraphQL interrompra certaines requêtes existantes** envoyées à l'API Graph.
+
+Pour être conforme à ces validations, veuillez suivre le guide de migration.
+
+> ⚠️ Si vous ne migrez pas vos requêtes avant le déploiement des validations, elles renverront des erreurs et éventuellement casseront vos frontends/clients.
+
+## Guide de migration
+
+Vous pouvez utiliser l'outil de migration CLI pour rechercher tous les problèmes dans vos opérations GraphQL et les résoudre. Vous pouvez également mettre à jour le point de terminaison de votre client GraphQL pour utiliser le point de terminaison « https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME ». Tester vos requêtes sur ce point de terminaison vous aidera à trouver les problèmes dans vos requêtes.
+
+> Tous les subgraphs n'auront pas besoin d'être migrés si vous utilisez [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) ou [GraphQL Code Generator](https://the-guild.dev /graphql/codegen), ils garantissent déjà que vos requêtes sont valides.
+
+## Outil CLI de migration
+
+**La plupart des erreurs d'opérations GraphQL peuvent être trouvées à l'avance dans votre base de code.**
+
+Pour cette raison, nous offrons une expérience fluide pour valider vos opérations GraphQL pendant le développement ou dans CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) est un outil CLI simple qui permet de valider les opérations GraphQL par rapport à un schéma donné.
+
+### **Commencer**
+
+Vous pouvez exécuter l'outil comme suit :
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notes:**
+
+- Définissez ou remplacez $GITHUB_USER, $SUBGRAPH_NAME par les valeurs appropriées. Comme : [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- L'URL du schéma d'aperçu (https://api-next.thegraph.com/) fournie est fortement limitée en débit et sera supprimée une fois que tous les utilisateurs auront migré vers la nouvelle version. **Ne l'utilisez pas en production.**
+- Les opérations sont identifiées dans les fichiers avec les extensions suivantes [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx `, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (option `-o`).
+
+### Sortie CLI
+
+L'outil CLI `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` affichera toutes les erreurs d'opérations GraphQL comme suit :
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+Pour chaque erreur, vous trouverez une description, le chemin et la position du fichier, ainsi qu'un lien vers un exemple de solution (voir la section suivante).
+
+## Exécutez vos requêtes locales sur le schéma d'aperçu
+
+Nous fournissons un point de terminaison « https://api-next.thegraph.com/ » qui exécute une version « graph-node » dont les validations sont activées.
+
+Vous pouvez tester des requêtes en les envoyant à :
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+ou bien
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+Pour travailler sur des requêtes signalées comme comportant des erreurs de validation, vous pouvez utiliser votre outil de requête GraphQL préféré, comme Altair ou [GraphiQL](https://cloud.hasura.io/public/graphiql), et essayer votre requête. Ces outils marqueront également ces erreurs dans leur interface utilisateur, avant même que vous ne l'exécutiez.
+
+## Comment résoudre les problèmes
+
+Ci-dessous, vous trouverez toutes les erreurs de validation GraphQL qui pourraient survenir sur vos opérations GraphQL existantes.
+
+### Les variables, opérations, fragments ou arguments GraphQL doivent être uniques
+
+Nous avons appliqué des règles pour garantir qu'une opération inclut un ensemble unique de variables, d'opérations, de fragments et d'arguments GraphQL.
+
+Une opération GraphQL n'est valide que si elle ne contient aucune ambiguïté.
+
+Pour y parvenir, nous devons nous assurer que certains composants de votre opération GraphQL doivent être uniques.
+
+Voici un exemple de quelques opérations non valides qui enfreignent ces règles :
+
+**Nom de requête en double (#UniqueOperationNamesRule)**
+
+```graphql
+# L'opération suivante a violé UniqueOperationName
+# règle, puisque nous avons une seule opération avec 2 requêtes
+# avec le même nom
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+   # renommer la deuxième requête
+  name
+}
+```
+
+**Nom de fragment en double (#UniqueFragmentNamesRule)**
+
+```graphql
+# L'opération suivante a violé la règle UniqueFragmentName
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assigner un nom unique au fragment
+  metadata
+}
+
+fragment MyFieldsName { # assigner un nom unique au fragment
+  nom
+}
+```
+
+**Variable en double (#UniqueVariableNamesRule)**
+
+```graphql
+# L'opération suivante viole le UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+   # conserver la variable pertinente (ici : `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Nom d'argument en double (#UniqueArgument)**
+
+```graphql
+# L'opération suivante a violé les UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Requête anonyme en double (#LoneAnonymousOperationRule)**
+
+De plus, l'utilisation de deux opérations anonymes violera la règle « LoneAnonymousOperation » en raison d'un conflit dans la structure de réponse :
+
+```graphql
+# Cela échouera s'il est exécuté ensemble dans
+# une seule opération avec les deux requêtes suivantes :
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Ou nommez les deux requêtes :
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Chevauchement des domaines
+
+Un jeu de sélection GraphQL n'est considéré comme valide que s'il résout correctement l'éventuel jeu de résultats.
+
+Si un ensemble de sélection spécifique, ou un champ, crée une ambiguïté soit par le champ sélectionné, soit par les arguments utilisés, le service GraphQL ne parviendra pas à valider l'opération.
+
+Voici quelques exemples d'opérations non valides qui enfreignent cette règle :
+
+**Conflit d'alias de champs (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# L'alias des champs peut provoquer des conflits, soit avec
+# d'autres alias ou d'autres champs qui existent sur le
+# Schéma GraphQL.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    nickname: name
+    originalName: name # alias du champ `name` original
+  }
+}
+```
+
+\*_Champs en conflit avec des arguments (#OverlappingFieldsCanBeMergedRule)_
+
+```graphql
+# Différents arguments peuvent conduire à des données différentes,
+# donc nous ne pouvons pas supposer que les champs seront les mêmes. 
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+De plus, dans des cas d'utilisation plus complexes, vous pourriez enfreindre cette règle en utilisant deux fragments susceptibles de provoquer un conflit dans l'ensemble finalement attendu :
+
+```graphql
+query {
+  # Finalement, nous avons deux définitions de "x", pointant
+  # vers des champs différents !
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+En plus de cela, les directives GraphQL côté client comme `@skip` et `@include` peuvent conduire à une ambiguïté, par exemple :
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+```
+
+[Vous pouvez en savoir plus sur l'algorithme ici.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Variables ou fragments inutilisés
+
+Une opération GraphQL n'est également considérée comme valide que si tous les composants définis par l'opération (variables, fragments) sont utilisés.
+
+Voici quelques exemples d'opérations GraphQL qui enfreignent ces règles :
+
+**Variable inutilisée** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalide, car $someVar n'est jamais utilisé.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Fragment inutilisé** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalide, car le fragment AllFields n'est jamais utilisé.
+query something {
+  someData
+}
+
+fragment AllFields { # inutilisé :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalide, car le fragment AllFields n'est jamais utilisé.
+query something {
+  someData
+}
+
+# retirer le fragment `AllFields`
+```
+
+### Ensemble de sélection invalide ou manquant (#ScalarLeafsRule)
+
+De plus, une sélection de champ GraphQL n'est valide que si les éléments suivants sont validés :
+
+- Un champ d'objet doit avoir un ensemble de sélection spécifié.
+- Un champ de bord (scalaire, énumération) ne doit pas avoir de jeu de sélection spécifié.
+
+Voici quelques exemples de violations de ces règles avec le schéma suivant :
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Ensemble de sélection invalide**
+
+```graphql
+query {
+  user {
+    id { # Invalide, car "id" est de type ID et n'a pas de sous-champs
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Ensemble de sélection manquant**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` nécessite un ensemble de sélection pour les sous-champs!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Valeurs d'arguments incorrectes (#VariablesInAllowedPositionRule)
+
+Les opérations GraphQL qui transmettent des valeurs codées en dur aux arguments doivent être valides, en fonction de la valeur définie dans le schéma.
+
+Voici quelques exemples d'opérations non valides qui enfreignent ces règles :
+
+```graphql
+query purposes {
+  # Si "name" est défini comme "String" dans le schéma,
+  # cette requête échouera lors de la validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# Cela pourrait également se produire lorsqu'une variable incorrecte est définie :
+
+query purposes($name: Int!) {
+  # Si "name" est défini comme `String` dans le schéma,
+  # cette requête échouera lors de la validation, car la
+  # variable utilisée est de type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Type, Variable, Fragment ou Directive connu (#UnknownX)
+
+L'API GraphQL générera une erreur si un type, une variable, un fragment ou une directive inconnu est utilisé.
+
+Ces références inconnues doivent être corrigées :
+
+- renommer si c'était une faute de frappe
+- sinon, supprimez
+
+### Fragment : diffusion ou définition non valide
+
+**Propagation de fragments non valide (#PossibleFragmentSpreadsRule)**
+
+Un Fragment ne peut pas être réparti sur un type non applicable.
+
+Exemple, nous ne pouvons pas appliquer un fragment `Cat` au type `Dog` :
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Définition de fragment non valide (#FragmentsOnCompositeTypesRule)**
+
+Tout Fragment doit être défini sur (en utilisant `on ...`) un type composite, en bref : objet, interface ou union.
+
+Les exemples suivants ne sont pas valides, car la définition de fragments sur des scalaires n'est pas valide.
+
+```graphql
+fragment fragOnScalar on Int {
+  # nous ne pouvons pas définir un fragment sur un scalaire (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` n'est pas un sous-type de `Dog`
+    somethingElse
+  }
+}
+```
+
+### Utilisation des directives
+
+**La directive ne peut pas être utilisée à cet emplacement (#KnownDirectivesRule)**
+
+Seules les directives GraphQL (« @... ») prises en charge par l'API Graph peuvent être utilisées.
+
+Voici un exemple avec les directives prises en charge par GraphQL :
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Remarque : `@stream`, `@live`, `@defer` ne sont pas pris en charge._
+
+**La directive ne peut être utilisée qu'une seule fois à cet emplacement (#UniqueDirectivesPerLocationRule)**
+
+Les directives prises en charge par The Graph ne peuvent être utilisées qu'une seule fois par emplacement.
+
+Ce qui suit n'est pas valide (et redondant) :
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 3fc689fd33c83cc501d1c73d4768b3e88fcced13 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:21 -0500
Subject: [PATCH 1288/3820] New translations
 graphql-validations-migration-guide.mdx (Spanish)

---
 .../graphql-validations-migration-guide.mdx   | 535 ++++++++++++++++++
 1 file changed, 535 insertions(+)
 create mode 100644 website/pages/es/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/es/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/es/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..292c60a70cf9
--- /dev/null
+++ b/website/pages/es/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,535 @@
+---
+title: Guía de migración de Validaciones GraphQL
+---
+
+Pronto `graph-node` admitirá una cobertura del 100% de la [especificación de validaciones GraphQL](https://spec.graphql.org/June2018/#sec-Validation).
+
+Versiones anteriores de `graph-node` no soportaban todas las validaciones y proporcionaban respuestas más gráciles, por lo que en casos de ambigüedad, `graph-node` ignoraba componentes inválidos de operaciones GraphQL.
+
+El soporte de Validaciones GraphQL es el pilar para las próximas nuevas características y el rendimiento a escala de The Graph Network.
+
+También asegurará la determinismo de las respuestas de las consultas, un requisito clave en The Graph Network.
+
+**Habilitar las Validaciones GraphQL romperá algunas consultas existentes** enviadas a la API de The Graph.
+
+Para ser compatible con esas validaciones, por favor sigue la guía de migración.
+
+> ⚠️ Si no migras tus consultas antes de que se implementen las validaciones, estas devolverán errores y podrían romper tus interfaces de usuario/clientes.
+
+## Guía de migración
+
+Puedes utilizar la herramienta de migración CLI para encontrar cualquier problema en tus operaciones GraphQL y solucionarlo. Alternativamente, puedes actualizar el endpoint de tu cliente GraphQL para usar el endpoint `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME`. Probar tus consultas contra este endpoint te ayudará a encontrar los problemas en tus consultas.
+
+> No todos los subgrafos deberán migrarse, si estás utilizando [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) o [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), ya se aseguran de que tus consultas sean válidas.
+
+## Herramienta de migración de la línea de comandos
+
+**La mayoría de los errores en las operaciones de GraphQL pueden ser encontrados en tu código previamente.**
+
+Por esta razón, brindamos una experiencia fluida para validar tus operaciones de GraphQL durante el desarrollo o en CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) es una herramienta CLI simple que ayuda a validar operaciones de GraphQL contra un esquema dado.
+
+### **Empezando**
+
+Puedes ejecutar la herramienta de la siguiente manera:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notas:**
+
+- Configura o reemplaza $GITHUB_USER, $SUBGRAPH_NAME con los valores apropiados. Por ejemplo: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- La URL del esquema de vista previa (https://api-next.thegraph.com/) proporcionada tiene una limitación de tasa alta y se descontinuará una vez que todos los usuarios se hayan migrado a la nueva versión. **No lo uses en producción.**
+- Las operaciones se identifican en archivos con las siguientes extensiones [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (opción `-o`).
+
+### Salida del CLI
+
+La herramienta de línea de comandos `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` mostrará cualquier error en las operaciones GraphQL de la siguiente manera:
+
+![Error de salida del CLI](https://i.imgur.com/x1cBdhq.png)
+
+Por cada error, encontrarás una descripción, una ruta de archivo y posición, y un enlace a un ejemplo de solución (ver la siguiente sección).
+
+## Ejecuta tus consultas locales contra el esquema de vista previa
+
+Proporcionamos un punto final `https://api-next.thegraph.com/` que ejecuta una versión de `graph-node` que tiene las validaciones activadas.
+
+Puedes probar tus consultas enviándolas a:
+
+- `https://api-next.thegraph.com/subgraphs/id`
+
+o
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+Para trabajar en consultas que hayan sido identificadas como teniendo errores de validación, puedes usar tu herramienta de consulta GraphQL favorita, como Altair o [GraphiQL](https://cloud.hasura.io/public/graphiql), y probar tu consulta. Esas herramientas también marcarán esos errores en su interfaz de usuario, incluso antes de ejecutarlos.
+
+## Como resolver problemas
+
+A continuación, encontrará todos los posibles errores de validación de GraphQL que podrían ocurrir en sus operaciones de GraphQL existentes.
+
+### Las variables, operaciones, fragmentos o argumentos GraphQL deben ser únicos
+
+Aplicamos reglas para garantizar que una operación incluye un conjunto único de variables GraphQL, operaciones, fragmentos y argumentos.
+
+Una operación GraphQL solo es válida si no contiene ninguna ambigüedad.
+
+Para lograr eso, necesitamos asegurarnos de que algunos componentes en su operación de GraphQL sean únicos.
+
+Aquí hay un ejemplo de algunas operaciones inválidas que violan estas reglas:
+
+**Nombre de consulta duplicado (#UniqueOperationNamesRule)**
+
+```graphql
+# La siguiente operación viola la regla UniqueOperationName,
+# ya que tenemos una sola operación con 2 consultas con el mismo nombre
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solución:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Nombre de Fragmento Duplicado (#UniqueFragmentNamesRule)**
+
+```graphql
+# La siguiente operación violó la regla UniqueFragmentName
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solución:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # asignar un nombre único al fragmento  metadatos
+}
+
+fragment MyFieldsName { #asigna un nombre único al fragment name
+}
+```
+
+**Nombre de variable duplicado (#UniqueVariableNamesRule)**
+
+```graphql
+# La siguiente operación viola la regla UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solución:_
+
+```graphql
+query myData($id: String) {
+  # Manten la variable relevante (aquí: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Nombre de argumento duplicado (#UniqueArgument)**
+
+```graphql
+# La siguiente operacion, violó la consulta UniqueArguments
+myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solución:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Consulta anonima duplicada (#LoneAnonymousOperationRule)**
+
+Además, el uso de dos operaciones anónimas violará la regla `LoneAnonymousOperation` debido al conflicto en la estructura de respuesta:
+
+```graphql
+# Esto fallará si se ejecuta en conjunto en
+# una sola operación con las siguientes dos consultas:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solución:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+O nombra las dos consultas:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Campos superpuestos
+
+Un conjunto de selección de GraphQL se considera válido solo si resuelve correctamente el conjunto de resultados final.
+
+Si un conjunto de selección específico o un campo crea ambigüedad ya sea por el campo seleccionado o por los argumentos utilizados, el servicio GraphQL no podrá validar la operación.
+
+Aquí hay algunos ejemplos de operaciones inválidas que violan estas reglas:
+
+**Alias de campos en conflicto (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Poner alias a los campos puede causar conflictos
+# ya sea con otros alias o con otros campos que existen en el esquema de GraphQL.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solución:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias el original `name` field
+  }
+}
+```
+
+**Campos en conflicto con argumentos (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Diferentes argumentos pueden llevar a diferentes datos,
+# asi que no podemos asumir que los capos serán los mismos.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solución:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Además, en casos de uso más complejos, se puede violar esta regla al utilizar dos fragmentos que puedan causar un conflicto en el conjunto de resultados esperado:
+
+```graphql
+query {
+  # Eventualmente, tenemos dos "x" definiciones, apuntando
+  # para diferentes campos!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+Además de eso, las directivas GraphQL del lado del cliente como `@skip` y `@include` podrían causar ambigüedad, por ejemplo:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[Puedes leer mas sobre el algoritmo aqui.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Variables o fragmentos no utilizados
+
+Una operación GraphQL también se considera válida solo si se utilizan todos los componentes definidos en la operación (variables, fragmentos).
+
+Aquí hay algunos ejemplos de operaciones de GraphQL que violan estas reglas:
+
+**Variable no utilizada** (#NoUnusedVariablesRule)
+
+```graphql
+# Inválido, porque $someVar nunca se usa.
+consulta algo($someVar: String) {
+  someData
+}
+```
+
+_Solución:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Fragmento no Utilizado** (#NoUnusedFragmentsRule)
+
+```graphql
+#Inválido, ya que el fragmento AllFields nunca se utiliza.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solución:_
+
+```graphql
+# Invalido, porque el fragmento AllFields nunca se utiliza.
+query something {
+  someData
+}
+
+# elimina el fragmento `AllFields`
+```
+
+### Conjunto de selección inválido o faltante (#ScalarLeafsRule)
+
+Además, una selección de campos GraphQL solo es válida si se valida lo siguiente:
+
+- Un campo de objeto debe tener un conjunto de selección especificado.
+- Un campo de borde (escalar, enum) no debe tener un conjunto de selección especificado.
+
+Aquí hay algunos ejemplos de violaciones de estas reglas con el siguiente esquema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Conjunto de Selección Inválido**
+
+```graphql
+query {
+  user {
+    id { # Invalido, porque "id" es de tipo ID y no tiene sub-campos
+
+    }
+  }
+}
+```
+
+_Solución:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Falta el Conjunto de Selección**
+
+```graphql
+query {
+  user {
+    id
+    image # 'image' requiere un conjunto de selección para subcampos!
+
+  }
+}
+```
+
+_Solución:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Argumentos de valores incorrectos(#VariablesInAllowedPositionRule)
+
+Las operaciones de GraphQL que pasan valores codificados a los argumentos deben ser válidas, basadas en el valor definido en el esquema.
+
+Aquí hay algunos ejemplos de operaciones inválidas que violan estas reglas:
+
+```graphql
+query purposes {
+  # si "name" esta definido como "String"  en el esquema,
+  # Esta consulta fallará durante la validación.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# Esto también puede suceder cuando se define una variable incorrecta:
+query purposes($name: Int!) {
+  # si "name" esta definido como `String` en el esquema,
+  # esta consulta fallara durante la validación, por que la
+  # variable usada es de tipo `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Tipo, Variable, Fragmento o Directiva Desconocida (#UnknownX)
+
+La API de GraphQL generará un error si se utiliza algún tipo, variable, fragmento o directiva desconocido.
+
+Esas referencias desconocidas deben ser corregidas:
+
+- renombrar si fue un error tipográfico
+- de lo contrario, elimina
+
+### Fragmento: expansión o definición inválida
+
+**Extensión de fragmento no válida (#PossibleFragmentSpreadsRule)**
+
+Un fragmento no puede ser aplicado en un tipo no correspondiente.
+
+Por ejemplo, no podemos aplicar un fragmento `Cat` al tipo `Dog`:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Definicion de fragento inválida (#FragmentsOnCompositeTypesRule)**
+
+Todos los fragmentos deben definirse en (usando `on ...`) un tipo compuesto, en resumen: objeto, interfaz o unión.
+
+Los siguientes ejemplos son inválidos, ya que definir fragmentos en escalares es inválido.
+
+```graphql
+fragment fragOnScalar on Int {
+ # no podemos definir un fragmento sobre un escalar
+(`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` no es un subtipo de `Dog`
+    somethingElse
+  }
+}
+```
+
+### Uso de directivas
+
+**La directiva no puede ser utilizada en esta ubicación (#KnownDirectivesRule)**
+
+Solo las directivas GraphQL (`@...`) soportadas por la API de The Graph pueden ser utilizadas.
+
+Aqui hay un ejemplo con The GraphQL con las directivas soportadas:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` no son soportadas._
+
+**La directiva no puede ser utilizada en esta ubicación (#UniqueDirectivesPerLocationRule)**
+
+Los directivas soportados por The Graph solo se pueden usar una vez por ubicación.
+
+La siguiente es inválida (y redundante):
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```

From 5cc467cb3dc4bb501e6b90b6c00cc734cb7463c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:22 -0500
Subject: [PATCH 1289/3820] New translations
 graphql-validations-migration-guide.mdx (Arabic)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/ar/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/ar/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/ar/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..4d909e8970a8
--- /dev/null
+++ b/website/pages/ar/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL Validations migration guide
+---
+
+Soon `graph-node` will support 100% coverage of the [GraphQL Validations specification](https://spec.graphql.org/June2018/#sec-Validation).
+
+Previous versions of `graph-node` did not support all validations and provided more graceful responses - so, in cases of ambiguity, `graph-node` was ignoring invalid GraphQL operations components.
+
+GraphQL Validations support is the pillar for the upcoming new features and the performance at scale of The Graph Network.
+
+It will also ensure determinism of query responses, a key requirement on The Graph Network.
+
+**Enabling the GraphQL Validations will break some existing queries** sent to The Graph API.
+
+To be compliant with those validations, please follow the migration guide.
+
+> ⚠️ If you do not migrate your queries before the validations are rolled out, they will return errors and possibly break your frontends/clients.
+
+## Migration guide
+
+You can use the CLI migration tool to find any issues in your GraphQL operations and fix them. Alternatively you can update the endpoint of your GraphQL client to use the `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` endpoint. Testing your queries against this endpoint will help you find the issues in your queries.
+
+> Not all subgraphs will need to be migrated, if you are using [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) or [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), they already ensure that your queries are valid.
+
+## Migration CLI tool
+
+**Most of the GraphQL operations errors can be found in your codebase ahead of time.**
+
+For this reason, we provide a smooth experience for validating your GraphQL operations during development or in CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) is a simple CLI tool that helps validate GraphQL operations against a given schema.
+
+### **Getting started**
+
+You can run the tool as follows:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notes:**
+
+- Set or replace $GITHUB_USER, $SUBGRAPH_NAME with the appropriate values. Like: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- The preview schema URL (https://api-next.thegraph.com/) provided is heavily rate-limited and will be sunset once all users have migrated to the new version. **Do not use it in production.**
+- Operations are identified in files with the following extensions [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### CLI output
+
+The `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI tool will output any GraphQL operations errors as follows:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+For each error, you will find a description, file path and position, and a link to a solution example (see the following section).
+
+## Run your local queries against the preview schema
+
+We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on.
+
+You can try out queries by sending them to:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+or
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+To work on queries that have been flagged as having validation errors, you can use your favorite GraphQL query tool, like Altair or [GraphiQL](https://cloud.hasura.io/public/graphiql), and try your query out. Those tools will also mark those errors in their UI, even before you run it.
+
+## How to solve issues
+
+Below, you will find all the GraphQL validations errors that could occur on your existing GraphQL operations.
+
+### GraphQL variables, operations, fragments, or arguments must be unique
+
+We applied rules for ensuring that an operation includes a unique set of GraphQL variables, operations, fragments, and arguments.
+
+A GraphQL operation is only valid if it does not contain any ambiguity.
+
+To achieve that, we need to ensure that some components in your GraphQL operation must be unique.
+
+Here's an example of a few invalid operations that violates these rules:
+
+**Duplicate Query name (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Or name the two queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Overlapping Fields
+
+A GraphQL selection set is considered valid only if it correctly resolves the eventual result set.
+
+If a specific selection set, or a field, creates ambiguity either by the selected field or by the arguments used, the GraphQL service will fail to validate the operation.
+
+Here are a few examples of invalid operations that violate this rule:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Also, in more complex use-cases, you might violate this rule by using two fragments that might cause a conflict in the eventually expected set:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[You can read more about the algorithm here.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Unused Variables or Fragments
+
+A GraphQL operation is also considered valid only if all operation-defined components (variables, fragments) are used.
+
+Here are a few examples for GraphQL operations that violates these rules:
+
+**Unused variable** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Invalid or missing Selection-Set (#ScalarLeafsRule)
+
+Also, a GraphQL field selection is only valid if the following is validated:
+
+- An object field must-have selection set specified.
+- An edge field (scalar, enum) must not have a selection set specified.
+
+Here are a few examples of violations of these rules with the following Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Incorrect Arguments values (#VariablesInAllowedPositionRule)
+
+GraphQL operations that pass hard-coded values to arguments must be valid, based on the value defined in the schema.
+
+Here are a few examples of invalid operations that violate these rules:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Unknown Type, Variable, Fragment, or Directive (#UnknownX)
+
+The GraphQL API will raise an error if any unknown type, variable, fragment, or directive is used.
+
+Those unknown references must be fixed:
+
+- rename if it was a typo
+- otherwise, remove
+
+### Fragment: invalid spread or definition
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+
+A Fragment cannot be spread on a non-applicable type.
+
+Example, we cannot apply a `Cat` fragment to the `Dog` type:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)**
+
+All Fragment must be defined upon (using `on ...`) a composite type, in short: object, interface, or union.
+
+The following examples are invalid, since defining fragments on scalars is invalid.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Directives usage
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+
+Only GraphQL directives (`@...`) supported by The Graph API can be used.
+
+Here is an example with The GraphQL supported directives:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` are not supported._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+
+The directives supported by The Graph can only be used once per location.
+
+The following is invalid (and redundant):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 15ef15f62630bd8fad348429ae4c4344ec814d54 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:24 -0500
Subject: [PATCH 1290/3820] New translations
 graphql-validations-migration-guide.mdx (Czech)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/cs/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/cs/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/cs/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..7f273724aff4
--- /dev/null
+++ b/website/pages/cs/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: Průvodce migrací na GraphQL Validace
+---
+
+Brzy bude `graph-node` podporovat 100% pokrytí [GraphQL Validations specifikace](https://spec.graphql.org/June2018/#sec-Validation).
+
+Předchozí verze `graph-node` nepodporovaly všechny validace a neposkytovaly šetrnější odpovědi - v případě nejednoznačnosti tak `graph-node` ignoroval neplatné komponenty operací GraphQL.
+
+Podpora ověřování GraphQL je pilířem pro nadcházející nové funkce a výkon v měřítku Síť Graph.
+
+Zajistí také determinismus odpovědí na dotazy, což je klíčový požadavek sítě Graf.
+
+**Povolení ověřování GraphQL naruší některé existující dotazy** odeslané do Grafu API.
+
+Chcete-li být v souladu s těmito validacemi, postupujte podle průvodce migrací.
+
+> ⚠️ Pokud neprovedete migraci dotazů před zavedením validací, budou vracet chyby a možná rozbijí vaše frontends/klienty.
+
+## Průvodce migrací
+
+Pomocí migračního nástroje CLI můžete najít případné problémy v operacích GraphQL a opravit je. Případně můžete aktualizovat koncový bod svého klienta GraphQL tak, aby používal koncový bod `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME`. Testování dotazů proti tomuto koncovému bodu vám pomůže najít problémy ve vašich dotazech.
+
+> Není nutné migrovat všechny podgrafy, pokud používáte [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) nebo [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), ty již zajistí, že vaše dotazy jsou platné.
+
+## Migrační nástroj CLI
+
+**Většinu chyb při operacích GraphQL můžete najít ve své kódové základně předem.**
+
+Z tohoto důvodu poskytujeme hladký průběh ověřování operací GraphQL během vývoje nebo v CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) je jednoduchý nástroj CLI, který pomáhá ověřovat operace GraphQL proti danému schéma.
+
+### **začínáme**
+
+Nástroj můžete spustit následujícím způsobem:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Poznámky:**
+
+- Nastavte nebo nahraďte $GITHUB_USER, $SUBGRAPH_NAME příslušnými hodnotami. Jako např: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- Poskytnutá adresa URL náhledového schématu (https://api-next.thegraph.com/) je silně omezená a po přechodu všech uživatelů na novou verzi bude ukončena. **Nepoužívejte jej v produkčním provozu**
+- Operace jsou identifikovány v souborech s následujícími příponami [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### Výstup CLI
+
+Nástroj `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI vypíše všechny chyby operací GraphQL takto:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+U každé chyby naleznete popis, cestu a pozici souboru a odkaz na příklad řešení (viz následující část).
+
+## Spouštění místních dotazů proti schéma náhledu
+
+Poskytujeme koncový bod `https://api-next.thegraph.com/`, který spouští verzi `graph-node` se zapnutými validacemi.
+
+Dotazy si můžete vyzkoušet zasláním na:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+nebo
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+Chcete-li pracovat s dotazy, které byly označeny jako dotazy s chybami validace, můžete použít svůj oblíbený nástroj pro dotazy GraphQL, například Altair nebo [GraphiQL](https://cloud.hasura.io/public/graphiql), a vyzkoušet svůj dotaz. Tyto nástroje také tyto chyby označí ve svém uživatelském rozhraní, a to ještě předtím, než jej spustíte.
+
+## Jak řešit problémy
+
+Níže naleznete všechny chyby validace GraphQL, které se mohou vyskytnout u vašich stávajících operací GraphQL.
+
+### Proměnné, operace, fragmenty nebo argumenty jazyka GraphQL musí být jedinečné
+
+Použili jsme pravidla pro zajištění toho, aby operace obsahovala jedinečnou sadu proměnných GraphQL, operací, fragmentů a argumentů.
+
+Operace GraphQL je platná pouze tehdy, pokud neobsahuje žádnou nejednoznačnost.
+
+Abychom toho dosáhli, musíme zajistit, aby některé součásti operace GraphQL byly jedinečné.
+
+Zde je příklad několika neplatných operací, které porušují tato pravidla:
+
+**Duplicitní název dotazu (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Řešení:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicitní název fragmentu (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Řešení:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicitní název proměnné (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Řešení:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Řešení:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicitní anonymní dotaz (#LoneAnonymousOperationRule)**
+
+Použitím dvou anonymních operací se také poruší pravidlo `LoneAnonymousOperation` kvůli konfliktu ve struktuře odpovědi:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Řešení:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Nebo tyto dva dotazy pojmenujte:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Překrývající pole
+
+Výběrová sada GraphQL je považována za platnou, pouze pokud správně řeší případnou sadu výsledků.
+
+Pokud konkrétní výběrová sada nebo pole způsobí nejednoznačnost buď vybraného pole, nebo použitých argumentů, služba GraphQL operaci neověří.
+
+Zde je několik příkladů neplatných operací, které toto pravidlo porušují:
+
+**Překrývající se aliasy polí (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Řešení:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Konfliktní pole s argumenty (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Řešení:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Ve složitějších případech použití můžete toto pravidlo porušit také použitím dvou fragmentů, které by mohly způsobit konflikt v očekávané sadě:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+Kromě toho mohou vést k nejasnostem například direktivy GraphQL na straně klienta jako `@skip` a `@include`:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[Více informací o algoritmu najdete zde.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Nepoužívané proměnné nebo fragmenty
+
+Operace GraphQL je také považována za platnou, pouze pokud jsou použity všechny součásti definované operací (proměnné, fragmenty).
+
+Zde je několik příkladů operací GraphQL, které tato pravidla porušují:
+
+**Nepoužitá proměnná** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Řešení:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Nepoužitý fragment**(#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Řešení:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Neplatná nebo chybějící výběrová sada (#ScalarLeafsRule)
+
+Výběr pole GraphQL je také platný pouze v případě, že je potvrzeno následující:
+
+- Pole objektu musí mít zadanou výběrovou sadu.
+- Okrajové pole (skalár, enum) nesmí mít zadanou výběrovou sadu.
+
+Zde je několik příkladů porušení těchto pravidel s následujícím schématem:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Neplatná výběrová sada**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Řešení:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Chybějící výběrová sada**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Řešení:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Nesprávné hodnoty argumentů (#VariablesInAllowedPositionRule)
+
+Operace GraphQL, které předávají pevně zadané hodnoty argumentů, musí být platné na základě hodnoty definované ve schéma.
+
+Zde je několik příkladů neplatných operací, které porušují tato pravidla:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Neznámý typ, proměnná, fragment nebo směrnice (#UnknownX)
+
+Pokud je použit neznámý typ, proměnná, fragment nebo direktiva, rozhraní GraphQL API vyhodí chybu.
+
+Tyto neznámé odkazy je třeba opravit:
+
+- přejmenovat, pokud se jedná o překlep
+- v opačném případě odstraňte
+
+### Fragment: neplatné rozšíření nebo definice
+
+**Neplatné rozložení fragmentů (#PossibleFragmentSpreadsRule)**
+
+Fragment nelze rozložit na nepoužitelný typ.
+
+Příklad: fragment `Kočka` nemůžeme použít na typ `Pes`:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Neplatná definice fragmentu (#FragmentsOnCompositeTypesRule)**
+
+Všechny fragmenty musí být definovány na (pomocí `on ...`) složeném typu, zkráceně: objektu, rozhraní nebo svazu.
+
+Následující příklady jsou neplatné, protože definování fragmentů na skalárech je neplatné.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Použití směrnic
+
+**Direktiv nelze na tomto místě použít (#KnownDirectivesRule)**
+
+Lze použít pouze direktivy GraphQL (`@...`) podporované Graf API.
+
+Zde je příklad s direktivami podporovanými GraphQL:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Poznámka: `@stream`, `@live`, `@defer` nejsou podporovány._
+
+**Direktiv lze v tomto umístění použít pouze jednou (#UniqueDirectivesPerLocationRule)**
+
+Směrnice podporované nástrojem Grafu lze v jednom umístění použít pouze jednou.
+
+Následující text je neplatný (a nadbytečný):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 3d60927608b59885b98b5ed7b13ca2b41b0082c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:25 -0500
Subject: [PATCH 1291/3820] New translations
 graphql-validations-migration-guide.mdx (German)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/de/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/de/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/de/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..ee37b90c5576
--- /dev/null
+++ b/website/pages/de/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL Validations migration guide
+---
+
+Soon `graph-node` will support 100% coverage of the [GraphQL Validations specification](https://spec.graphql.org/June2018/#sec-Validation).
+
+Previous versions of `graph-node` did not support all validations and provided more graceful responses - so, in cases of ambiguity, `graph-node` was ignoring invalid GraphQL operations components.
+
+GraphQL Validations support is the pillar for the upcoming new features and the performance at scale of The Graph Network.
+
+It will also ensure determinism of query responses, a key requirement on The Graph Network.
+
+**Enabling the GraphQL Validations will break some existing queries** sent to The Graph API.
+
+To be compliant with those validations, please follow the migration guide.
+
+> ⚠️ If you do not migrate your queries before the validations are rolled out, they will return errors and possibly break your frontends/clients.
+
+## Migration guide
+
+You can use the CLI migration tool to find any issues in your GraphQL operations and fix them. Alternatively you can update the endpoint of your GraphQL client to use the `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` endpoint. Testing your queries against this endpoint will help you find the issues in your queries.
+
+> Not all subgraphs will need to be migrated, if you are using [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) or [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), they already ensure that your queries are valid.
+
+## Migration CLI tool
+
+**Most of the GraphQL operations errors can be found in your codebase ahead of time.**
+
+For this reason, we provide a smooth experience for validating your GraphQL operations during development or in CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) is a simple CLI tool that helps validate GraphQL operations against a given schema.
+
+### **Getting started**
+
+You can run the tool as follows:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notes:**
+
+- Set or replace $GITHUB_USER, $SUBGRAPH_NAME with the appropriate values. Like: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- The preview schema URL (https://api-next.thegraph.com/) provided is heavily rate-limited and will be sunset once all users have migrated to the new version. **Do not use it in production.**
+- Operations are identified in files with the following extensions [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### CLI output
+
+The `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI tool will output any GraphQL operations errors as follows:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+For each error, you will find a description, file path and position, and a link to a solution example (see the following section).
+
+## Run your local queries against the preview schema
+
+We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on.
+
+You can try out queries by sending them to:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+or
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+To work on queries that have been flagged as having validation errors, you can use your favorite GraphQL query tool, like Altair or [GraphiQL](https://cloud.hasura.io/public/graphiql), and try your query out. Those tools will also mark those errors in their UI, even before you run it.
+
+## How to solve issues
+
+Below, you will find all the GraphQL validations errors that could occur on your existing GraphQL operations.
+
+### GraphQL variables, operations, fragments, or arguments must be unique
+
+We applied rules for ensuring that an operation includes a unique set of GraphQL variables, operations, fragments, and arguments.
+
+A GraphQL operation is only valid if it does not contain any ambiguity.
+
+To achieve that, we need to ensure that some components in your GraphQL operation must be unique.
+
+Here's an example of a few invalid operations that violates these rules:
+
+**Duplicate Query name (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Lösung:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Lösung:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Lösung:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Lösung:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Lösung:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Or name the two queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Overlapping Fields
+
+A GraphQL selection set is considered valid only if it correctly resolves the eventual result set.
+
+If a specific selection set, or a field, creates ambiguity either by the selected field or by the arguments used, the GraphQL service will fail to validate the operation.
+
+Here are a few examples of invalid operations that violate this rule:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Lösung:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Lösung:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Also, in more complex use-cases, you might violate this rule by using two fragments that might cause a conflict in the eventually expected set:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[You can read more about the algorithm here.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Unused Variables or Fragments
+
+A GraphQL operation is also considered valid only if all operation-defined components (variables, fragments) are used.
+
+Here are a few examples for GraphQL operations that violates these rules:
+
+**Unused variable** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Lösung:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Lösung:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Invalid or missing Selection-Set (#ScalarLeafsRule)
+
+Also, a GraphQL field selection is only valid if the following is validated:
+
+- An object field must-have selection set specified.
+- An edge field (scalar, enum) must not have a selection set specified.
+
+Here are a few examples of violations of these rules with the following Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Lösung:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Lösung:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Incorrect Arguments values (#VariablesInAllowedPositionRule)
+
+GraphQL operations that pass hard-coded values to arguments must be valid, based on the value defined in the schema.
+
+Here are a few examples of invalid operations that violate these rules:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Unknown Type, Variable, Fragment, or Directive (#UnknownX)
+
+The GraphQL API will raise an error if any unknown type, variable, fragment, or directive is used.
+
+Those unknown references must be fixed:
+
+- rename if it was a typo
+- otherwise, remove
+
+### Fragment: invalid spread or definition
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+
+A Fragment cannot be spread on a non-applicable type.
+
+Example, we cannot apply a `Cat` fragment to the `Dog` type:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)**
+
+All Fragment must be defined upon (using `on ...`) a composite type, in short: object, interface, or union.
+
+The following examples are invalid, since defining fragments on scalars is invalid.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Directives usage
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+
+Only GraphQL directives (`@...`) supported by The Graph API can be used.
+
+Here is an example with The GraphQL supported directives:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` are not supported._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+
+The directives supported by The Graph can only be used once per location.
+
+Folgendes ist ungültig (und überflüssig):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 642ac6d3ee1207ba252c4d95ab8da1fde1b12cf9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:26 -0500
Subject: [PATCH 1292/3820] New translations
 graphql-validations-migration-guide.mdx (Italian)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/it/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/it/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/it/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..6fe94d495069
--- /dev/null
+++ b/website/pages/it/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: Guida alla migrazione delle validazione GraphQL
+---
+
+Presto `graph-node` supporterà il 100% di copertura delle specifiche [Specifiche delle validation GraphQL] (https://spec.graphql.org/June2018/#sec-Validation).
+
+Le versioni precedenti di `graph-node` non supportavano tutte le validation e fornivano risposte più aggraziate, per cui, in caso di ambiguità, `graph-node` ignorava i componenti delle operazioni GraphQL non validi.
+
+Il supporto delle validation GraphQL è il pilastro delle nuove funzionalità e delle prestazioni su scala di The Graph Network.
+
+Garantirà inoltre il determinismo delle risposte alle query, un requisito fondamentale per The Graph Network.
+
+**L'abilitazione delle validation GraphQL interromperà alcune query esistenti** inviate all'API The Graph.
+
+Per essere conformi a tali validation, seguire la guida alla migrazione.
+
+> ⚠️ Se non si migrano le query prima dell'introduzione delle validation, queste restituiranno errori e potrebbero interrompere i frontend/client.
+
+## Guida alla migrazione
+
+È possibile utilizzare lo strumento di migrazione CLI per trovare eventuali problemi nelle operazioni GraphQL e risolverli. In alternativa, è possibile aggiornare l'endpoint del client GraphQL per utilizzare l'endpoint `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME`. Testare le query con questo endpoint vi aiuterà a trovare i problemi nelle vostre query.
+
+> Non è necessario migrare tutti i subgraph; se si utilizza [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) o [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), questi garantiscono già la validità delle query.
+
+## Strumento CLI di migrazione
+
+**La maggior parte degli errori delle operazioni GraphQL può essere individuata in anticipo nella propria codebase.**
+
+Per questo motivo, forniamo un'esperienza agevole per la validating delle operazioni GraphQL durante lo sviluppo o in CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) è un semplice strumento CLI che aiuta a validare le operazioni GraphQL rispetto a un determinato schema.
+
+### **Per cominciare**
+
+Lo strumento può essere eseguito nel modo seguente:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Note:**
+
+- Impostare o sostituire $GITHUB_USER, $SUBGRAPH_NAME con i valori appropriati. Ad esempio: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- L'URL dello schema di anteprima (https://api-next.thegraph.com/) fornito è fortemente limitato e verrà abbandonato una volta che tutti gli utenti saranno migrati alla nuova versione. **Non usarlo in produzione.**
+- Le operazioni sono identificate in file con le seguenti estensioni [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (opzione `-o`).
+
+### Output CLI
+
+Lo strumento `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI mostrerà gli errori delle operazioni GraphQL come segue:
+
+![Output di errore da CLI](https://i.imgur.com/x1cBdhq.png)
+
+Per ogni errore sono disponibili una descrizione, il percorso e la posizione del file e un link a un esempio di soluzione (vedere la sezione seguente).
+
+## Eseguire le query locali sullo schema di anteprima
+
+Forniamo un endpoint `https://api-next.thegraph.com/` che esegue una versione di `graph-node` con le validation attivate.
+
+È possibile provare le query inviandole a:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+or
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+Per lavorare sulle query che sono state contrassegnate da errori di validazione, si può usare il proprio strumento preferito di query GraphQL, come Altair o [GraphiQL](https://cloud.hasura.io/public/graphiql), e provare la query. Questi strumenti segnaleranno gli errori nella loro interfaccia utente, anche prima dell'esecuzione.
+
+## Come risolvere i problemi
+
+Di seguito sono riportati tutti gli errori di validation GraphQL che potrebbero verificarsi nelle operazioni GraphQL esistenti.
+
+### Le variabili, le operazioni, i frammenti o gli argomenti di GraphQL devono essere unici
+
+Abbiamo applicato regole per garantire che un'operazione includa un set unico di variabili GraphQL, operazioni, frammenti e argomenti.
+
+Un'operazione GraphQL è valida solo se non contiene alcuna ambiguità.
+
+A tal fine, è necessario garantire che alcuni componenti dell'operazione GraphQL siano unici.
+
+Ecco un esempio di alcune operazioni non valide che violano queste regole:
+
+**Nome della query duplicato (#UniqueOperationNamesRule)**
+
+```graphql
+# La seguente operazione ha violato la regola UniqueOperationName
+# la regola UniqueOperationName poiché abbiamo una singola operazione con 2 query
+# con lo stesso nome
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Soluzione:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  #  rinominare la seconda query
+  name
+}
+```
+
+**Nome del frammento duplicato (#UniqueFragmentNamesRule)**
+
+```graphql
+# L'operazione seguente ha violato
+# la regola UniqueFragmentName.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Soluzione:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assegna un nome unico al frammento
+  metadati
+}
+
+fragment MyFieldsName { # assegna un nome unico al frammento
+  nome
+}
+```
+
+**Nome variabile duplicato (#UniqueVariableNamesRule)**
+
+```graphql
+# L'operazione seguente viola la norma UniqueVariables.
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Soluzione:_
+
+```graphql
+query myData($id: String) {
+  # mantiene la variabile rilevante (qui: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Nome dell'argomento duplicato (#UniqueArgument)**
+
+```graphql
+# L'operazione seguente ha violato la norma UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Soluzione:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicazione della query anonima (#LoneAnonymousOperationRule)**
+
+Inoltre, l'uso di due operazioni anonime violerà la norma `LoneAnonymousOperation`, a causa di un conflitto nella struttura della risposta:
+
+```graphql
+# Questa operazione fallirà se eseguita insieme in
+# un'unica operazione con le due query seguenti:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Soluzione:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Oppure dare un nome alle due query:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Campi sovrapposti
+
+Un set di selezione GraphQL è considerato valido solo se risolve correttamente l'eventuale set di risultati.
+
+Se uno specifico set di selezione, o un campo, crea ambiguità sia per il campo selezionato che per gli argomenti utilizzati, il servizio GraphQL non riuscirà a validare l'operazione.
+
+Ecco alcuni esempi di operazioni non valide che violano questa regola:
+
+**Alias di campi in conflitto (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# L'aliasing dei campi potrebbe causare conflitti, sia con
+# altri alias o con altri campi che esistono nello
+# schema GraphQL.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Soluzione:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Campi in conflitto con gli argomenti (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Argomenti diversi possono portare a dati diversi,
+# quindi non possiamo presumere che i campi siano gli stessi.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Soluzione:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Inoltre, in casi d'uso più complessi, si potrebbe violare questa regola utilizzando due frammenti che potrebbero causare un conflitto nell'insieme atteso:
+
+```graphql
+query {
+  # Alla fine, abbiamo due definizioni di "x", che puntano
+  # a campi diversi!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+Inoltre, le direttive GraphQL lato client come `@skip` e `@include` potrebbero portare ad ambiguità, ad esempio:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[Per saperne di più sull'algoritmo, consultare qui.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Variabili o frammenti non utilizzati
+
+Un'operazione GraphQL è considerata valida solo se vengono utilizzati tutti i componenti definiti dall'operazione (variabili, frammenti).
+
+Ecco alcuni esempi di operazioni GraphQL che violano queste regole:
+
+**Variabile inutilizzata** (#NoUnusedVariablesRule)
+
+```graphql
+# Non valido, perché $someVar non viene mai utilizzato.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Soluzione:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Frammento non utilizzato** (#NoUnusedFragmentsRule)
+
+```graphql
+# Non valido, perché il frammento AllFields non viene mai utilizzato.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Soluzione:_
+
+```graphql
+# Non valido, perché il frammento AllFields non viene mai utilizzato.
+query something {
+  someData
+}
+
+# rimuovere il frammento `AllFields`
+```
+
+### Set di selezione non valido o mancante (#ScalarLeafsRule)
+
+Inoltre, la selezione di un campo GraphQL è valida solo se il seguente è validato:
+
+- Un campo oggetto deve avere un set di selezione specificato.
+- Un campo bordo (scalare, enum) non deve avere un set di selezione specificato.
+
+Ecco alcuni esempi di violazione di queste regole con il seguente schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Set di selezione non valido**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Soluzione:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Set di selezione mancante**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Soluzione:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Valori degli argomenti non corretti (#VariablesInAllowedPositionRule)
+
+Le operazioni GraphQL che passano valori codificati agli argomenti devono essere validi, in base al valore definito nello schema.
+
+Ecco alcuni esempi di operazioni non valide che violano queste regole:
+
+```graphql
+scopi della query {
+  # Se "name" è definito come "String" nello schema,
+  # questa query fallirà durante la validazione.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# Questo può accadere anche quando viene definita una variabile non corretta:
+
+scopi della query ($name: Int!) {
+  # Se "name" è definito come `String` nello schema,
+  # questa query fallirà durante la validazione, perché la
+  # variabile utilizzata è di tipo `Int`.
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Tipo, variabile, frammento o direttiva sconosciuti (#UnknownX)
+
+L'API GraphQL solleverà un errore se viene utilizzato un tipo, una variabile, un frammento o una direttiva sconosciuti.
+
+Questi riferimenti sconosciuti devono essere corretti:
+
+- rinominare se si tratta di un errore di battitura
+- altrimenti, rimuovere
+
+### Frammento: diffusione o definizione non valida
+
+**Diffusione del frammento non valida (#PossibleFragmentSpreadsRule)**
+
+Un frammento non può essere distribuito su un tipo non applicabile.
+
+Ad esempio, non si può applicare un frammento `Cat` al tipo `Dog`:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Definizione di frammento non valida (#FragmentsOnCompositeTypesRule)**
+
+Tutti i frammenti devono essere definiti su (usando `on ...`) un tipo composito, in breve: oggetto, interfaccia o unione.
+
+Gli esempi seguenti non sono validi, poiché la definizione di frammenti su scalari non è valida.
+
+```graphql
+fragment fragOnScalar on Int {
+  # non possiamo definire un frammento su uno scalare (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` non è un subtipo di `Dog`
+    somethingElse
+  }
+}
+```
+
+### Utilizzo delle direttive
+
+**La direttiva non può essere utilizzata in questa sede (#KnownDirectivesRule)**
+
+È possibile utilizzare solo le direttive GraphQL (`@...`) supportate da Graph API.
+
+Ecco un esempio con le direttive supportate da GraphQL:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Nota: `@stream`, `@live`, `@defer` non sono supportati._
+
+**La direttiva può essere utilizzata una sola volta in questo luogo (#UniqueDirectivesPerLocationRule)**
+
+Le direttive supportate da The Graph possono essere utilizzate una sola volta per ogni posizione.
+
+Il seguente non è valido (e ridondante):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 086bbb8753a23a0755d0ddb7a8b18e3d57dad77b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:27 -0500
Subject: [PATCH 1293/3820] New translations
 graphql-validations-migration-guide.mdx (Japanese)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/ja/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/ja/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/ja/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..9a8bcf34625f
--- /dev/null
+++ b/website/pages/ja/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL 検証移行ガイド
+---
+
+まもなく「graph-node」は [GraphQL Validations 仕様](https://spec.graphql.org/June2018/#sec-Validation) を 100% カバーします。
+
+以前のバージョンの「graph-node」は、すべての検証をサポートしておらず、より適切な応答を提供していました。そのため、あいまいな場合、「graph-node」は無効な GraphQL 操作コンポーネントを無視していました。
+
+GraphQL Validations サポートは、今後の新機能と The Graph Network の大規模なパフォーマンスの柱です。
+
+また、The Graph Network の重要な要件であるクエリ応答の決定性も保証されます。
+
+**GraphQL Validations を有効にすると、The Graph API に送信された既存のクエリの一部が壊れます**。
+
+これらの検証に準拠するには、移行ガイドに従ってください。
+
+> ⚠️ 検証がロールアウトされる前にクエリを移行しないと、エラーが返され、フロントエンド/クライアントが壊れる可能性があります。
+
+## 移行ガイド
+
+CLI 移行ツールを使用して、GraphQL 操作の問題を見つけて修正できます。または、GraphQL クライアントのエンドポイントを更新して、`https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` エンドポイントを使用することもできます。このエンドポイントに対してクエリをテストすると、クエリの問題を見つけるのに役立ちます。
+
+> [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) または [GraphQL Code Generator](https://the-guild.dev) を使用している場合、すべてのサブグラフを移行する必要はありません。 /graphql/codegen)、クエリが有効であることを既に確認しています。
+
+## 移行 CLI ツール
+
+**GraphQL 操作エラーのほとんどは、事前にコードベースで見つけることができます。**
+
+このため、開発中または CI で GraphQL 操作を検証するためのスムーズなエクスペリエンスを提供します。
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) は、特定のスキーマに対して GraphQL 操作を検証するのに役立つシンプルな CLI ツールです。
+
+### **入門**
+
+ツールは次のように実行できます。
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**ノート：**
+
+- $GITHUB_USER、$SUBGRAPH_NAME を適切な値に設定または置き換えます。のように: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- 提供されているプレビュー スキーマ URL (https://api-next.thegraph.com/) は大幅にレート制限されており、すべてのユーザーが新しいバージョンに移行すると廃止されます。 **本番環境では使用しないでください。**
+- 操作は、次の拡張子を持つファイルで識別されます [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx `, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` オプション)。
+
+### CLI 出力
+
+`[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI ツールは、GraphQL 操作エラーを次のように出力します。
+
+![CLIからのエラー出力](https://i.imgur.com/x1cBdhq.png)
+
+エラーごとに、説明、ファイル パスと位置、および解決例へのリンクが表示されます (次のセクションを参照)。
+
+## プレビュー スキーマに対してローカル クエリを実行する
+
+検証がオンになっている「graph-node」バージョンを実行するエンドポイント「https://api-next.thegraph.com/」を提供します。
+
+クエリを次の宛先に送信して試すことができます。
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+または
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+検証エラーがあるとフラグが立てられたクエリを処理するには、Altair や [GraphiQL](https://cloud.hasura.io/public/graphiql) などの好きな GraphQL クエリ ツールを使用して、クエリを試してみてください。これらのツールは、実行前であっても、UI でこれらのエラーをマークします。
+
+## 問題を解決する方法
+
+以下に、既存の GraphQL 操作で発生する可能性があるすべての GraphQL 検証エラーを示します。
+
+### GraphQL の変数、操作、フラグメント、または引数は一意である必要があります
+
+操作に GraphQL 変数、操作、フラグメント、および引数の一意のセットが含まれるようにするためのルールを適用しました。
+
+GraphQL 操作は、あいまいさが含まれていない場合にのみ有効です。
+
+これを実現するには、GraphQL 操作の一部のコンポーネントが一意でなければならないことを確認する必要があります。
+
+これらの規則に違反するいくつかの無効な操作の例を次に示します。
+
+**クエリ名が重複しています (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_解決：_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**フラグメント名の重複 (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_解決：_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**重複した変数名 (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_解決：_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**引数名が重複しています (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_解決：_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**重複した匿名クエリ (#LoneAnonymousOperationRule)**
+
+また、2 つの匿名操作を使用すると、応答構造の競合により、「LoneAnonymousOperation」ルールに違反します。
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_解決：_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+または、2 つのクエリに名前を付けます。
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### 重複するフィールド
+
+GraphQL 選択セットは、最終的な結果セットを正しく解決する場合にのみ有効と見なされます。
+
+特定の選択セットまたはフィールドが、選択されたフィールドまたは使用された引数のいずれかによってあいまいさを生み出す場合、GraphQL サービスは操作の検証に失敗します。
+
+この規則に違反する無効な操作の例をいくつか示します。
+
+**競合するフィールド エイリアス (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_解決：_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**引数を持つフィールドの競合 (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_解決：_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+また、より複雑なユースケースでは、最終的に予想されるセットで競合を引き起こす可能性のある 2 つのフラグメントを使用して、この規則に違反する可能性があります。
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+それに加えて、`@skip` や `@include` などのクライアント側の GraphQL ディレクティブは、あいまいさにつながる可能性があります。次に例を示します。
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[アルゴリズムの詳細については、こちらをご覧ください](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### 未使用の変数またはフラグメント
+
+GraphQL 操作も、操作で定義されたすべてのコンポーネント (変数、フラグメント) が使用されている場合にのみ有効と見なされます。
+
+これらのルールに違反する GraphQL 操作の例をいくつか示します:
+
+**未使用の変数** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_解決：_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**未使用のフラグメント** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_解決：_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### 無効または欠落している選択セット (#ScalarLeafsRule)
+
+また、GraphQL フィールドの選択は、以下が検証された場合にのみ有効です:
+
+- オブジェクト フィールドには選択セットが指定されている必要があります。
+- エッジ フィールド (スカラー、列挙型) には、選択セットが指定されていてはなりません。
+
+次のスキーマでこれらの規則に違反する例をいくつか示します:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**無効な選択セット**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_解決：_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**選択セットがありません**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_解決：_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### 引数の値が正しくない (#VariablesInAllowedPositionRule)
+
+ハードコーディングされた値を引数に渡す GraphQL 操作は、スキーマで定義された値に基づいて有効である必要があります。
+
+これらの規則に違反する無効な操作の例をいくつか示します:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### 不明な型、変数、フラグメント、またはディレクティブ (#UnknownX)
+
+不明なタイプ、変数、フラグメント、またはディレクティブが使用されている場合、GraphQL API はエラーを発生させます。
+
+これらの不明な参照は修正する必要があります:
+
+- タイプミスだった場合の名前の変更
+- それ以外の場合は、削除します
+
+### フラグメント: 無効なスプレッドまたは定義
+
+**無効なフラグメント スプレッド (#PossibleFragmentSpreadsRule)**
+
+Fragment は、適用できない型に展開できません。
+
+たとえば、`Cat` フラグメントを `Dog` タイプに適用することはできません。
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**無効なフラグメント定義 (#FragmentsOnCompositeTypesRule)**
+
+すべての Fragment は、(`on ...` を使用して) 複合型、つまり、オブジェクト、インターフェイス、またはユニオンで定義する必要があります。
+
+スカラーでのフラグメントの定義は無効であるため、次の例は無効です。
+
+```graphql
+ragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### ディレクティブの使用
+
+**ディレクティブはこの場所では使用できません (#KnownDirectivesRule)**
+
+The Graph API でサポートされている GraphQL ディレクティブ (`@...`) のみを使用できます。
+
+以下は、GraphQL がサポートするディレクティブの例です:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_注: `@stream`、`@live`、`@defer` はサポートされていません。
+
+**ディレクティブは、この場所で 1 回だけ使用できます (#UniqueDirectivesPerLocationRule)**
+
+The Graph でサポートされているディレクティブは、場所ごとに 1 回だけ使用できます。
+
+以下は無効です (そして冗長です):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From c7e192ff6533937314fd5a6dea15ff268c28387f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:28 -0500
Subject: [PATCH 1294/3820] New translations
 graphql-validations-migration-guide.mdx (Korean)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/ko/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/ko/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/ko/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..4d909e8970a8
--- /dev/null
+++ b/website/pages/ko/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL Validations migration guide
+---
+
+Soon `graph-node` will support 100% coverage of the [GraphQL Validations specification](https://spec.graphql.org/June2018/#sec-Validation).
+
+Previous versions of `graph-node` did not support all validations and provided more graceful responses - so, in cases of ambiguity, `graph-node` was ignoring invalid GraphQL operations components.
+
+GraphQL Validations support is the pillar for the upcoming new features and the performance at scale of The Graph Network.
+
+It will also ensure determinism of query responses, a key requirement on The Graph Network.
+
+**Enabling the GraphQL Validations will break some existing queries** sent to The Graph API.
+
+To be compliant with those validations, please follow the migration guide.
+
+> ⚠️ If you do not migrate your queries before the validations are rolled out, they will return errors and possibly break your frontends/clients.
+
+## Migration guide
+
+You can use the CLI migration tool to find any issues in your GraphQL operations and fix them. Alternatively you can update the endpoint of your GraphQL client to use the `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` endpoint. Testing your queries against this endpoint will help you find the issues in your queries.
+
+> Not all subgraphs will need to be migrated, if you are using [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) or [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), they already ensure that your queries are valid.
+
+## Migration CLI tool
+
+**Most of the GraphQL operations errors can be found in your codebase ahead of time.**
+
+For this reason, we provide a smooth experience for validating your GraphQL operations during development or in CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) is a simple CLI tool that helps validate GraphQL operations against a given schema.
+
+### **Getting started**
+
+You can run the tool as follows:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notes:**
+
+- Set or replace $GITHUB_USER, $SUBGRAPH_NAME with the appropriate values. Like: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- The preview schema URL (https://api-next.thegraph.com/) provided is heavily rate-limited and will be sunset once all users have migrated to the new version. **Do not use it in production.**
+- Operations are identified in files with the following extensions [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### CLI output
+
+The `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI tool will output any GraphQL operations errors as follows:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+For each error, you will find a description, file path and position, and a link to a solution example (see the following section).
+
+## Run your local queries against the preview schema
+
+We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on.
+
+You can try out queries by sending them to:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+or
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+To work on queries that have been flagged as having validation errors, you can use your favorite GraphQL query tool, like Altair or [GraphiQL](https://cloud.hasura.io/public/graphiql), and try your query out. Those tools will also mark those errors in their UI, even before you run it.
+
+## How to solve issues
+
+Below, you will find all the GraphQL validations errors that could occur on your existing GraphQL operations.
+
+### GraphQL variables, operations, fragments, or arguments must be unique
+
+We applied rules for ensuring that an operation includes a unique set of GraphQL variables, operations, fragments, and arguments.
+
+A GraphQL operation is only valid if it does not contain any ambiguity.
+
+To achieve that, we need to ensure that some components in your GraphQL operation must be unique.
+
+Here's an example of a few invalid operations that violates these rules:
+
+**Duplicate Query name (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Or name the two queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Overlapping Fields
+
+A GraphQL selection set is considered valid only if it correctly resolves the eventual result set.
+
+If a specific selection set, or a field, creates ambiguity either by the selected field or by the arguments used, the GraphQL service will fail to validate the operation.
+
+Here are a few examples of invalid operations that violate this rule:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Also, in more complex use-cases, you might violate this rule by using two fragments that might cause a conflict in the eventually expected set:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[You can read more about the algorithm here.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Unused Variables or Fragments
+
+A GraphQL operation is also considered valid only if all operation-defined components (variables, fragments) are used.
+
+Here are a few examples for GraphQL operations that violates these rules:
+
+**Unused variable** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Invalid or missing Selection-Set (#ScalarLeafsRule)
+
+Also, a GraphQL field selection is only valid if the following is validated:
+
+- An object field must-have selection set specified.
+- An edge field (scalar, enum) must not have a selection set specified.
+
+Here are a few examples of violations of these rules with the following Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Incorrect Arguments values (#VariablesInAllowedPositionRule)
+
+GraphQL operations that pass hard-coded values to arguments must be valid, based on the value defined in the schema.
+
+Here are a few examples of invalid operations that violate these rules:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Unknown Type, Variable, Fragment, or Directive (#UnknownX)
+
+The GraphQL API will raise an error if any unknown type, variable, fragment, or directive is used.
+
+Those unknown references must be fixed:
+
+- rename if it was a typo
+- otherwise, remove
+
+### Fragment: invalid spread or definition
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+
+A Fragment cannot be spread on a non-applicable type.
+
+Example, we cannot apply a `Cat` fragment to the `Dog` type:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)**
+
+All Fragment must be defined upon (using `on ...`) a composite type, in short: object, interface, or union.
+
+The following examples are invalid, since defining fragments on scalars is invalid.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Directives usage
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+
+Only GraphQL directives (`@...`) supported by The Graph API can be used.
+
+Here is an example with The GraphQL supported directives:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` are not supported._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+
+The directives supported by The Graph can only be used once per location.
+
+The following is invalid (and redundant):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From a09ca12aaac5dfbe50ba856580e08a32fc8d7174 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:29 -0500
Subject: [PATCH 1295/3820] New translations
 graphql-validations-migration-guide.mdx (Dutch)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/nl/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/nl/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/nl/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..4d909e8970a8
--- /dev/null
+++ b/website/pages/nl/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL Validations migration guide
+---
+
+Soon `graph-node` will support 100% coverage of the [GraphQL Validations specification](https://spec.graphql.org/June2018/#sec-Validation).
+
+Previous versions of `graph-node` did not support all validations and provided more graceful responses - so, in cases of ambiguity, `graph-node` was ignoring invalid GraphQL operations components.
+
+GraphQL Validations support is the pillar for the upcoming new features and the performance at scale of The Graph Network.
+
+It will also ensure determinism of query responses, a key requirement on The Graph Network.
+
+**Enabling the GraphQL Validations will break some existing queries** sent to The Graph API.
+
+To be compliant with those validations, please follow the migration guide.
+
+> ⚠️ If you do not migrate your queries before the validations are rolled out, they will return errors and possibly break your frontends/clients.
+
+## Migration guide
+
+You can use the CLI migration tool to find any issues in your GraphQL operations and fix them. Alternatively you can update the endpoint of your GraphQL client to use the `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` endpoint. Testing your queries against this endpoint will help you find the issues in your queries.
+
+> Not all subgraphs will need to be migrated, if you are using [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) or [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), they already ensure that your queries are valid.
+
+## Migration CLI tool
+
+**Most of the GraphQL operations errors can be found in your codebase ahead of time.**
+
+For this reason, we provide a smooth experience for validating your GraphQL operations during development or in CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) is a simple CLI tool that helps validate GraphQL operations against a given schema.
+
+### **Getting started**
+
+You can run the tool as follows:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notes:**
+
+- Set or replace $GITHUB_USER, $SUBGRAPH_NAME with the appropriate values. Like: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- The preview schema URL (https://api-next.thegraph.com/) provided is heavily rate-limited and will be sunset once all users have migrated to the new version. **Do not use it in production.**
+- Operations are identified in files with the following extensions [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### CLI output
+
+The `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI tool will output any GraphQL operations errors as follows:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+For each error, you will find a description, file path and position, and a link to a solution example (see the following section).
+
+## Run your local queries against the preview schema
+
+We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on.
+
+You can try out queries by sending them to:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+or
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+To work on queries that have been flagged as having validation errors, you can use your favorite GraphQL query tool, like Altair or [GraphiQL](https://cloud.hasura.io/public/graphiql), and try your query out. Those tools will also mark those errors in their UI, even before you run it.
+
+## How to solve issues
+
+Below, you will find all the GraphQL validations errors that could occur on your existing GraphQL operations.
+
+### GraphQL variables, operations, fragments, or arguments must be unique
+
+We applied rules for ensuring that an operation includes a unique set of GraphQL variables, operations, fragments, and arguments.
+
+A GraphQL operation is only valid if it does not contain any ambiguity.
+
+To achieve that, we need to ensure that some components in your GraphQL operation must be unique.
+
+Here's an example of a few invalid operations that violates these rules:
+
+**Duplicate Query name (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Or name the two queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Overlapping Fields
+
+A GraphQL selection set is considered valid only if it correctly resolves the eventual result set.
+
+If a specific selection set, or a field, creates ambiguity either by the selected field or by the arguments used, the GraphQL service will fail to validate the operation.
+
+Here are a few examples of invalid operations that violate this rule:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Also, in more complex use-cases, you might violate this rule by using two fragments that might cause a conflict in the eventually expected set:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[You can read more about the algorithm here.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Unused Variables or Fragments
+
+A GraphQL operation is also considered valid only if all operation-defined components (variables, fragments) are used.
+
+Here are a few examples for GraphQL operations that violates these rules:
+
+**Unused variable** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Invalid or missing Selection-Set (#ScalarLeafsRule)
+
+Also, a GraphQL field selection is only valid if the following is validated:
+
+- An object field must-have selection set specified.
+- An edge field (scalar, enum) must not have a selection set specified.
+
+Here are a few examples of violations of these rules with the following Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Incorrect Arguments values (#VariablesInAllowedPositionRule)
+
+GraphQL operations that pass hard-coded values to arguments must be valid, based on the value defined in the schema.
+
+Here are a few examples of invalid operations that violate these rules:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Unknown Type, Variable, Fragment, or Directive (#UnknownX)
+
+The GraphQL API will raise an error if any unknown type, variable, fragment, or directive is used.
+
+Those unknown references must be fixed:
+
+- rename if it was a typo
+- otherwise, remove
+
+### Fragment: invalid spread or definition
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+
+A Fragment cannot be spread on a non-applicable type.
+
+Example, we cannot apply a `Cat` fragment to the `Dog` type:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)**
+
+All Fragment must be defined upon (using `on ...`) a composite type, in short: object, interface, or union.
+
+The following examples are invalid, since defining fragments on scalars is invalid.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Directives usage
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+
+Only GraphQL directives (`@...`) supported by The Graph API can be used.
+
+Here is an example with The GraphQL supported directives:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` are not supported._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+
+The directives supported by The Graph can only be used once per location.
+
+The following is invalid (and redundant):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 8d8b9ed203be89bbb588e49e74d5b9a3314570ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:30 -0500
Subject: [PATCH 1296/3820] New translations
 graphql-validations-migration-guide.mdx (Polish)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/pl/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/pl/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/pl/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..4d909e8970a8
--- /dev/null
+++ b/website/pages/pl/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL Validations migration guide
+---
+
+Soon `graph-node` will support 100% coverage of the [GraphQL Validations specification](https://spec.graphql.org/June2018/#sec-Validation).
+
+Previous versions of `graph-node` did not support all validations and provided more graceful responses - so, in cases of ambiguity, `graph-node` was ignoring invalid GraphQL operations components.
+
+GraphQL Validations support is the pillar for the upcoming new features and the performance at scale of The Graph Network.
+
+It will also ensure determinism of query responses, a key requirement on The Graph Network.
+
+**Enabling the GraphQL Validations will break some existing queries** sent to The Graph API.
+
+To be compliant with those validations, please follow the migration guide.
+
+> ⚠️ If you do not migrate your queries before the validations are rolled out, they will return errors and possibly break your frontends/clients.
+
+## Migration guide
+
+You can use the CLI migration tool to find any issues in your GraphQL operations and fix them. Alternatively you can update the endpoint of your GraphQL client to use the `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` endpoint. Testing your queries against this endpoint will help you find the issues in your queries.
+
+> Not all subgraphs will need to be migrated, if you are using [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) or [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), they already ensure that your queries are valid.
+
+## Migration CLI tool
+
+**Most of the GraphQL operations errors can be found in your codebase ahead of time.**
+
+For this reason, we provide a smooth experience for validating your GraphQL operations during development or in CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) is a simple CLI tool that helps validate GraphQL operations against a given schema.
+
+### **Getting started**
+
+You can run the tool as follows:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notes:**
+
+- Set or replace $GITHUB_USER, $SUBGRAPH_NAME with the appropriate values. Like: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- The preview schema URL (https://api-next.thegraph.com/) provided is heavily rate-limited and will be sunset once all users have migrated to the new version. **Do not use it in production.**
+- Operations are identified in files with the following extensions [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### CLI output
+
+The `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI tool will output any GraphQL operations errors as follows:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+For each error, you will find a description, file path and position, and a link to a solution example (see the following section).
+
+## Run your local queries against the preview schema
+
+We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on.
+
+You can try out queries by sending them to:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+or
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+To work on queries that have been flagged as having validation errors, you can use your favorite GraphQL query tool, like Altair or [GraphiQL](https://cloud.hasura.io/public/graphiql), and try your query out. Those tools will also mark those errors in their UI, even before you run it.
+
+## How to solve issues
+
+Below, you will find all the GraphQL validations errors that could occur on your existing GraphQL operations.
+
+### GraphQL variables, operations, fragments, or arguments must be unique
+
+We applied rules for ensuring that an operation includes a unique set of GraphQL variables, operations, fragments, and arguments.
+
+A GraphQL operation is only valid if it does not contain any ambiguity.
+
+To achieve that, we need to ensure that some components in your GraphQL operation must be unique.
+
+Here's an example of a few invalid operations that violates these rules:
+
+**Duplicate Query name (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Or name the two queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Overlapping Fields
+
+A GraphQL selection set is considered valid only if it correctly resolves the eventual result set.
+
+If a specific selection set, or a field, creates ambiguity either by the selected field or by the arguments used, the GraphQL service will fail to validate the operation.
+
+Here are a few examples of invalid operations that violate this rule:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Also, in more complex use-cases, you might violate this rule by using two fragments that might cause a conflict in the eventually expected set:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[You can read more about the algorithm here.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Unused Variables or Fragments
+
+A GraphQL operation is also considered valid only if all operation-defined components (variables, fragments) are used.
+
+Here are a few examples for GraphQL operations that violates these rules:
+
+**Unused variable** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Invalid or missing Selection-Set (#ScalarLeafsRule)
+
+Also, a GraphQL field selection is only valid if the following is validated:
+
+- An object field must-have selection set specified.
+- An edge field (scalar, enum) must not have a selection set specified.
+
+Here are a few examples of violations of these rules with the following Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Incorrect Arguments values (#VariablesInAllowedPositionRule)
+
+GraphQL operations that pass hard-coded values to arguments must be valid, based on the value defined in the schema.
+
+Here are a few examples of invalid operations that violate these rules:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Unknown Type, Variable, Fragment, or Directive (#UnknownX)
+
+The GraphQL API will raise an error if any unknown type, variable, fragment, or directive is used.
+
+Those unknown references must be fixed:
+
+- rename if it was a typo
+- otherwise, remove
+
+### Fragment: invalid spread or definition
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+
+A Fragment cannot be spread on a non-applicable type.
+
+Example, we cannot apply a `Cat` fragment to the `Dog` type:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)**
+
+All Fragment must be defined upon (using `on ...`) a composite type, in short: object, interface, or union.
+
+The following examples are invalid, since defining fragments on scalars is invalid.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Directives usage
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+
+Only GraphQL directives (`@...`) supported by The Graph API can be used.
+
+Here is an example with The GraphQL supported directives:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` are not supported._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+
+The directives supported by The Graph can only be used once per location.
+
+The following is invalid (and redundant):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 3a609a0704003caf5b0237471c3913f0824b3dcb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:31 -0500
Subject: [PATCH 1297/3820] New translations
 graphql-validations-migration-guide.mdx (Portuguese)

---
 .../graphql-validations-migration-guide.mdx   | 543 ++++++++++++++++++
 1 file changed, 543 insertions(+)
 create mode 100644 website/pages/pt/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/pt/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/pt/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..75c8799b9286
--- /dev/null
+++ b/website/pages/pt/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,543 @@
+---
+title: Guia de migração de Validações GraphQL
+---
+
+Em breve, o `graph-node` apoiará a cobertura total da [especificação de Validações GraphQL](https://spec.graphql.org/June2018/#sec-Validation).
+
+As versões anteriores do `graph-node` não apoiavam todas as validações, e forneciam respostas mais suaves — então, em casos de ambiguidade, o `graph-node` ignorava componentes de operação inválidos do GraphQL.
+
+O apoio a Validações do GraphQL é o pilar para os futuros novos recursos e o desempenho em escala da Graph Network.
+
+Ele também garantirá o determinismo de respostas de consultas, um requisito importante na Graph Network.
+
+**Ativar as Validações GraphQL quebrará alguns queries existentes** enviadas à API do The Graph.
+
+Para cumprir tais validações, por favor siga o guia de migração.
+
+> ⚠️ Se não migrar os seus queries antes de ativar as validações, eles retornarão erros e possivelmente quebrarão os seus frontends/clientes.
+
+## Guia de migração
+
+Pode usar a ferramenta de migração em CLI para encontrar e consertar quaisquer problemas nas suas operações no GraphQL. De outra forma, pode atualizar o endpoint do seu cliente GraphQL para usar o endpoint `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME`. Testar os seus queries perante este endpoint ajudará-lhe a encontrar os problemas neles presentes.
+
+> Nem todos os Subgraphs precisam ser migrados; se usar o [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) ou o [Gerador de Código GraphQL](https://the-guild.dev/graphql/codegen), eles já garantirão que os seus queries sejam válidos.
+
+## Ferramenta CLI de migração
+
+**A maioria dos erros de operação em GraphQL podem ser encontrados na sua base de código com antecedência.**
+
+Portanto, provemos uma experiência suave para validar as suas operações GraphQL durante a programação ou em CI.
+
+O [`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) é uma ferramenta CLI (interface de linha de comando) simples que ajuda a validar operações GraphQL perante um schema.
+
+### **Primeiros passos**
+
+Pode executar a ferramenta da seguinte forma:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notas:**
+
+- Configure ou substitua $GITHUB_USER e $SUBGRAPH_NAME com os valores adequados. Por exemplo: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- A URL de prévia do schema (https://api-next.thegraph.com/) fornecida tem um rate-limit alto e será aposentada quando todos os utilizadores migrarem à versão nova. **Não a use na produção.**
+- As operações são identificadas em arquivos com as seguintes extensões: [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### Output em CLI
+
+A ferramenta de CLI `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` mostrará quaisquer erros de operação em GraphQL na seguinte forma:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+Para cada erro, serão exibidos uma descrição, caminho e posição de arquivo, e um atalho para um exemplo de solução (veja a secção seguinte).
+
+## Execute os seus queries locais contra o schema de prévia
+
+Nós fornecemos um endpoint `https://api-next.thegraph.com/` que executa uma versão `graph-node` com as validações ativadas.
+
+Para testar queries, é só enviá-las para:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+ou
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+Para trabalhar com consultas marcadas com erros de validação, pode usar a sua ferramenta de query no GraphQL favorita, como Altair ou [GraphiQL](https://cloud.hasura.io/public/graphiql), e testar o seu query. Estas ferramentas também marcarão tais erros na sua interface, antes mesmo de executá-la.
+
+## Como resolver problemas
+
+Abaixo, encontrará todos os erros de validação GraphQL que podem ocorrer nas suas operações em GraphQL.
+
+### Variáveis, operações, fragments, ou argumentos devem ser originais
+
+Nós aplicamos regras para garantir que uma operação inclua um conjunto único de variáveis, operações, fragmentos e argumentos.
+
+Uma operação GraphQL só é válida se não conter nenhuma ambiguidade.
+
+Para alcançar isto, devemos garantir que alguns componentes na sua operação GraphQL sejam únicos e originais.
+
+Veja algumas operações inválidas que violam estas regras:
+
+**Nome duplicado de Query (#UniqueOperationNamesRule)**
+
+```graphql
+# A seguinte operação violou a regra  UniqueOperationName
+# já que temos uma operação única com 2 queries
+# com o mesmo nome
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solução:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # renomeie o segundo query
+  name
+}
+```
+
+**Nome de Fragment duplicado (#UniqueFragmentNamesRule)**
+
+```graphql
+# A seguinte operação violou a regra de
+# UniqueFragmentName.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solução:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # dê um nome único ao fragmento
+  metadata
+}
+
+fragment MyFieldsName { # dê um nome único ao fragmento
+  name
+}
+```
+
+**Nome de variável duplicado (#UniqueVariableNamesRule)**
+
+```graphql
+# A seguinte operação viola a UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solução:_
+
+```graphql
+query myData($id: String) {
+  # mantenha a variável relevante (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Nome de argumento duplicado (#UniqueArgument)**
+
+```graphql
+# A seguinte operação violou a UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solução:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Query anónimo duplicado (#LoneAnonymousOperationRule)**
+
+Aliás, usar duas operações anónimas violará a regra `LoneAnonymousOperation` devido a um conflito na estrutura das respostas:
+
+```graphql
+# Isto falhará se executado junto com uma
+# operação única com os dois queries a seguir:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solução:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Ou nomeie os dois queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Campos sobrepostos
+
+Uma seleção GraphQL só é considerada válida se ela resolver corretamente o conjunto eventual de resultados.
+
+Se um conjunto de seleção, ou um campo, em específico criar ambiguidades, seja pelo campo selecionado ou pelos argumentos usados, o serviço GraphQL não conseguirá validar a operação.
+
+Aqui estão alguns exemplos de operações inválidas que violam esta regra:
+
+**Apelidos de campos em conflito (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Dar apelidos a campos pode causar conflitos,
+# seja com outros apelidos ou outros campos que
+# existam no schema GraphQL.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solução:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # apelide o campo `name` original
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+(Campos em conflito com argumentos)
+
+```graphql
+# Argumentos diferentes podem levar a dados diferentes,
+# então não podemos presumir que os campos serão os mesmos.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solução:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Aliás, em casos de uso mais complexos, é possível violar esta regra ao usar dois fragmentos que possam causar um conflito no conjunto esperado afinal:
+
+```graphql
+query {
+  # Eventualmente, temos duas definições "x",
+  # a apontar para campos diferentes!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+Além disso, diretivas client-side no GraphQL como `@skip` e `@include` podem levar a ambiguidades, por exemplo:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[Leia mais sobre o algoritmo aqui.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Variáveis ou Fragments Não Usados
+
+Uma operação GraphQL só é considerada válida se todos os componentes definidos pela operação (variáveis, fragments) forem usados.
+
+Veja alguns exemplos de operações GraphQL que violam estas regras:
+
+**Variável sem uso** (#NoUnusedVariablesRule)
+
+```graphql
+# Inválida, porque o $someVar nunca é usado.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solução:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Fragment sem uso** (#NoUnusedFragmentsRule)
+
+```graphql
+# Inválida, porque o fragmento AllFields nunca é usado.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solução:_
+
+```graphql
+# Inválida, porque o fragmento AllFields nunca é usado.
+query something {
+  someData
+}
+
+# retire o fragmento `AllFields`
+```
+
+### Conjunto de seleção inválido ou em falta (#ScalarLeafsRule)
+
+Aliás, uma seleção de campo GraphQL só é válida se o seguinte for validado:
+
+- Um campo de objeto deve ter um conjunto de seleção especificado.
+- Um campo de margem (scalar, enum) não deve ter um conjunto de seleção especificado.
+
+Aqui estão alguns exemplos de violações destas regras com o seguinte Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Conjunto de seleções inválido**
+
+```graphql
+query {
+  user {
+    id { # Inválido por que "id" é do tipo ID e não tem subcampos
+
+    }
+  }
+}
+```
+
+_Solução:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Conjunto de seleções em falta**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` exige um conjunto de seleção para subcampos!
+  }
+}
+```
+
+_Solução:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Valores de Arguments incorretos (#VariablesInAllowedPositionRule)
+
+Operações GraphQL que passam valores em código rígido para argumentos devem ser válidas, com base no valor definido no schema.
+
+Aqui estão alguns exemplos de operações inválidas que violam estas regras:
+
+```graphql
+query purposes {
+  # Se o "name" for definido como "String" no schema,
+  # esta consulta falhará durante a validação.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# Isto também pode acontecer quando uma variável incorreta é definida:
+
+query purposes($name: Int!) {
+  # Se o "name" for definido como `String` no schema,
+  # esta consulta falhará durante a validação, porque a
+  # variável usada é do tipo `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Tipo, Varíavel, Fragment, ou Diretiva desconhecido (#UnknownX)
+
+A API do GraphQL levantará um erro se houver uso de qualquer tipo, variável, fragmento ou diretiva desconhecidos.
+
+Estas referências desconhecidas devem ser consertadas:
+
+- renomeie se for um erro gramatical
+- caso contrário, remova
+
+### Fragment: invalid spread or definition
+(Fragment: espalhamento ou definição inválidos)
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+(Espalhamento de fragment inválido)
+
+Um Fragment não pode ser espalhado em um tipo não aplicável.
+
+Por exemplo, não podemos aplicar um fragmento `Cat` no tipo `Dog`:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Definição de Fragment inválida (#FragmentsOnCompositeTypesRule)**
+
+Todos os Fragments devem ser definidos sobre um tipo composto (com `on ...`), ou seja: objeto, interface ou união.
+
+Os seguintes exemplos são inválidos, já que definir fragments em scalars é inválido.
+
+```graphql
+fragment fragOnScalar on Int {
+  # não podemos definir um fragment sobre um scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` não é um subtipo de `Dog`
+    somethingElse
+  }
+}
+```
+
+### Uso de Diretivas
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+(A diretiva não pode ser usada neste local)
+
+Apenas diretivas GraphQL (`@...`) apoiadas pela API do The Graph podem ser usadas.
+
+Aqui está um exemplo com as diretivas apoiadas pelo GraphQL:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Nota: `@stream`, `@live`, e `@defer` não têm apoio._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+(A diretiva só pode ser usada neste local uma vez)
+
+As diretivas apoiadas pelo The Graph só podem ser usadas uma vez por local.
+
+O seguinte é inválido (e redundante):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 70dcade30e969ea78f8ff7c9dd66f1f49934a3fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:32 -0500
Subject: [PATCH 1298/3820] New translations
 graphql-validations-migration-guide.mdx (Russian)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/ru/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/ru/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/ru/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..25238b858a50
--- /dev/null
+++ b/website/pages/ru/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: Руководство по переходу на валидацию GraphQL
+---
+
+Вскоре `graph-node` будет поддерживать 100-процентное покрытие [спецификации GraphQL Validation] (https://spec.graphql.org/June2018/#sec-Validation).
+
+Предыдущие версии `graph-node` не поддерживали все валидации и предоставляли более обтекаемые ответы, поэтому в случаях неоднозначности `graph-node` игнорировал недопустимые компоненты операций GraphQL.
+
+Поддержка валидации GraphQL является основой для будущих новых функций и производительности в масштабе The Graph Network.
+
+Это также обеспечит детерминизм ответов на запросы, что является ключевым требованием в сети The Graph.
+
+**Включение валидации GraphQL нарушит работу некоторых существующих запросов**, отправленных в API The Graph.
+
+Чтобы выполнить эти валидации, следуйте руководству по миграции.
+
+> ⚠️ Если Вы не перенесете свои запросы до развертывания валидаций, они будут возвращать ошибки и, возможно, повредят ваши интерфейсы/клиенты.
+
+## Руководство по миграции
+
+Вы можете использовать инструмент миграции CLI, чтобы найти любые проблемы в операциях GraphQL и исправить их. В качестве альтернативы вы можете обновить конечную точку своего клиента GraphQL, чтобы использовать конечную точку `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME`. Проверка запросов на этой конечной точке поможет Вам обнаружить проблемы в Ваших запросах.
+
+> Не все субграфы нужно будет переносить, если Вы используете [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) или [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), они уже гарантируют корректность Ваших запросов.
+
+## CLI-инструмент миграции
+
+**Большинство ошибок операций GraphQL можно обнаружить в Вашей кодовой базе заранее.**
+
+По этой причине мы обеспечиваем беспрепятственный процесс валидации Ваших операций GraphQL во время разработки или в CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) — это простой инструмент командной строки, который помогает проверять операции GraphQL по заданной схеме.
+
+### **Начало работы**
+
+Вы можете запустить инструмент следующим образом:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Примечания:**
+
+- Установите или замените $GITHUB_USER, $SUBGRAPH_NAME соответствующими значениями. Например: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- Предоставленный URL-адрес схемы предварительного просмотра (https://api-next.thegraph.com/) сильно ограничен по скорости и будет удален после того, как все пользователи перейдут на новую версию. **Не используйте его в рабочей среде.**
+- Операции идентифицируются в файлах со следующими расширениями [`.graphql`,] (https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader) [`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### Вывод CLI
+
+Инструмент CLI `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` будет выводить любые ошибки операций GraphQL следующим образом:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+Для каждой ошибки Вы найдете описание, путь к файлу и его положение, а также ссылку на пример решения (см. следующий раздел).
+
+## Выполняйте локальные запросы по схеме предварительного просмотра
+
+Мы предоставляем конечную точку `https://api-next.thegraph.com/`, которая запускает версию `graph-node` с включенной валидацией.
+
+Вы можете опробовать запросы, отправив их по адресу:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+или
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+Чтобы работать с запросами, которые были помечены как имеющие ошибки валидации, Вы можете использовать свой любимый инструмент запросов GraphQL, например Altair или [GraphiQL](https://cloud.hasura.io/public/graphiql) и попробовать свой запрос. Эти инструменты также будут отмечать ошибки в своем пользовательском интерфейсе еще до того, как Вы их запустите.
+
+## Как решить проблемы
+
+Ниже Вы найдете все ошибки валидации GraphQL, которые могут возникнуть в Ваших операциях GraphQL.
+
+### Переменные, операции, фрагменты или аргументы GraphQL должны быть уникальными
+
+Мы применили правила, гарантирующие, что операция включает уникальный набор переменных, операций, фрагментов и аргументов GraphQL.
+
+Операция GraphQL действительна только в том случае, если она не содержит какой-либо неоднозначности.
+
+Для этого нам нужно убедиться, что некоторые компоненты в Вашей операции GraphQL уникальны.
+
+Ниже приведен пример нескольких недопустимых операций, нарушающих эти правила:
+
+**Повторяющееся имя запроса (#UniqueOperationNamesRule)**
+
+```graphql
+# Следующая операция нарушила UniqueOperationName
+# правило, так как у нас одна операция с 2-мя запросами
+# с тем же именем
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Решение:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Повторяющееся имя фрагмента (#UniqueFragmentNamesRule)**
+
+```graphql
+# Следующая операция нарушила UniqueFragmentName
+# правило.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Решение:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # присвоить фрагменту уникальное имя
+  metadata
+}
+
+fragment MyFieldsName { # присвоить фрагменту уникальное имя
+  name
+}
+```
+
+**Повторяющееся имя переменной (#UniqueVariableNamesRule)**
+
+```graphql
+# Следующая операция нарушает UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Решение:_
+
+```graphql
+query myData($id: String) {
+  # сохранить соответствующую переменную (здесь: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Повторяющееся имя аргумента (#UniqueArgument)**
+
+```graphql
+# Следующая операция нарушила UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Решение:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Повторяющийся анонимный запрос (#LoneAnonymousOperationRule)**
+
+Кроме того, использование двух анонимных операций нарушит правило LoneAnonymousOperation из-за конфликта в структуре ответа:
+
+```graphql
+# Это приведет к ошибке, если выполнить их вместе в
+# одной операции со следующими двумя запросами:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Решение:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Или назовите эти два запроса:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Перекрывающиеся поля
+
+Набор выбора GraphQL считается допустимым, только если он правильно разрешает конечный набор результатов.
+
+Если конкретный набор элементов или поле создают неоднозначность либо из-за выбранного поля, либо из-за используемых аргументов, служба GraphQL не сможет валидировать операцию.
+
+Вот несколько примеров недопустимых операций, нарушающих это правило:
+
+**Псевдонимы конфликтующих полей (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Псевдонимы полей могут вызвать конфликты либо с
+# другими псевдонимами или другими полями, существующими в
+# схеме GraphQL.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Решение:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Конфликтующие поля с аргументами (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Разные аргументы могут привести к разным данным,
+# поэтому мы не можем предположить, что поля будут одинаковыми.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Решение:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Кроме того, в более сложных случаях использования Вы можете нарушить это правило, используя два фрагмента, которые могут вызвать конфликт в ожидаемом в конечном итоге наборе:
+
+```graphql
+query {
+ # В конце концов, у нас есть два определения "x", указывающие
+ # на разные поля!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+Кроме того, директивы GraphQL на стороне клиента, такие как `@skip` и `@include`, могут привести к неоднозначности, например:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[Подробнее об алгоритме можно прочитать здесь.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Неиспользуемые переменные или фрагменты
+
+Операция GraphQL также считается действительной, только если используются все определенные в операции компоненты (переменные, фрагменты).
+
+Вот несколько примеров операций GraphQL, которые нарушают эти правила:
+
+**Неиспользуемая переменная** (#NoUnusedVariablesRule)
+
+```graphql
+# Неверно, потому что $someVar никогда не используется.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Решение:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Неиспользуемый фрагмент** (#NoUnusedFragmentsRule)
+
+```graphql
+# Неверно, так как фрагмент AllFields никогда не используется.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Решение:_
+
+```graphql
+# Неверно, так как фрагмент AllFields никогда не используется.
+query something {
+  someData
+}
+
+# удалить фрагмент `AllFields`
+```
+
+### Недопустимый или отсутствующий набор элементов выбора (#ScalarLeafsRule)
+
+Кроме того, выбор поля GraphQL действителен только в том случае, если подтверждено следующее:
+
+- Поле объекта должно иметь заданный набор выбора.
+- Краевое поле (скалярное, перечислимое) не должно иметь заданного набора выбора.
+
+Вот несколько примеров нарушения этих правил со следующей схемой:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Недопустимый набор выбора**
+
+```graphql
+query {
+  user {
+    id { # Неверно, так как "id" имеет тип ID и не имеет подполей
+
+    }
+  }
+}
+```
+
+_Решение:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Отсутствует набор выбора**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` требует набора выбора для подполей!
+  }
+}
+```
+
+_Решение:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Неверные значения аргументов (#VariablesInAllowedPositionRule)
+
+Операции GraphQL, которые передают жестко запрограммированные значения в аргументы, должны быть допустимыми на основе значения, определенного в схеме.
+
+Вот несколько примеров недопустимых операций, нарушающих эти правила:
+
+```graphql
+query purposes {
+  # Если в схеме "name" определено как "String",
+   # этот запрос не пройдёт валидацию.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# Это также может произойти, если определена неверная переменная:
+
+query purposes($name: Int!) {
+  # Если "name" определено в схеме как `String`,
+   # этот запрос не пройдёт валидацию, потому что
+   # используемая переменная имеет тип `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Неизвестный тип, переменная, фрагмент или директива (#UnknownX)
+
+API GraphQL вызовет ошибку, если используется какой-либо неизвестный тип, переменная, фрагмент или директива.
+
+Эти неизвестные ссылки необходимо исправить:
+
+- переименуйте, если это опечатка
+- в противном случае удалите
+
+### Фрагмент: недопустимый спред или определение
+
+**Неверный разворот фрагмента (#PossibleFragmentSpreadsRule)**
+
+Фрагмент не может быть распространен на неприменимый тип.
+
+Например, мы не можем применить фрагмент `Cat` к типу `Dog`:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Недопустимое определение фрагмента (#FragmentsOnCompositeTypesRule)**
+
+Все фрагменты должны быть определены (используя `on ...`) для составного типа, короче говоря: для объекта, интерфейса или объединения.
+
+Следующие примеры недопустимы, так как определение фрагментов на скалярах недопустимо.
+
+```graphql
+fragment fragOnScalar on Int {
+  # мы не можем определить фрагмент на скаляре (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` не является подтипом `Dog`
+    somethingElse
+  }
+}
+```
+
+### Применение директив
+
+**Директива не может быть использована в данном месте (#KnownDirectivesRule)**
+
+Можно использовать только директивы GraphQL ("@..."), поддерживаемые The Graph API.
+
+Вот пример с директивами, поддерживаемыми GraphQL:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Примечание: `@stream`, `@live`, `@defer` не поддерживаются._
+
+**Директива может быть использована в этом месте только один раз (#UniqueDirectivesPerLocationRule)**
+
+Директивы, поддерживаемые The Graph, можно использовать только один раз в каждом месте.
+
+Следующее является недопустимым (и избыточным):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 78337d63c0369d0e68fd28af1bd324e3aebb3984 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:34 -0500
Subject: [PATCH 1299/3820] New translations
 graphql-validations-migration-guide.mdx (Swedish)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/sv/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/sv/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/sv/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..25d4c50249e1
--- /dev/null
+++ b/website/pages/sv/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: Migrationsguide för GraphQL-validering
+---
+
+Snart kommer `graph-node` att stödja 100 % täckning av [GraphQL Valideringsspecifikationen](https://spec.graphql.org/June2018/#sec-Validation).
+
+Tidigare versioner av `graph-node` stödde inte alla valideringar och gav mer graciösa svar - så, i fall av oklarheter, ignorerade `graph-node` ogiltiga komponenter för GraphQL-operationer.
+
+Stöd för GraphQL Validering är grundläggande för de kommande nya funktionerna och prestanda vid skala för The Graph Network.
+
+Det kommer också att säkerställa determinism för frågesvar, en nyckelkrav på The Graph Nätverk.
+
+**Att aktivera GraphQL Validering kommer att bryta några befintliga frågor** som skickas till The Graph API.
+
+För att vara i linje med dessa valideringar, följ migrationsguiden.
+
+> ⚠️ Om du inte migrerar dina frågor innan valideringarna tas i bruk kommer de att returnera fel och eventuellt bryta dina frontends/klienter.
+
+## Migrationsguide
+
+Du kan använda CLI-migrationsverktyget för att hitta eventuella problem i dina GraphQL-operationer och åtgärda dem. Alternativt kan du uppdatera ändpunkten för din GraphQL-klient att använda ändpunkten `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME`. Att testa dina frågor mot denna ändpunkt kommer att hjälpa dig att hitta problemen i dina frågor.
+
+> Inte alla subgrafer behöver migreras, om du använder [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) eller [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), ser de redan till att dina frågor är giltiga.
+
+## Migrations-CLI-verktyg
+
+**De flesta felen i GraphQL-operationer kan hittas i din kodbas i förväg.**
+
+Av den anledningen erbjuder vi en smidig upplevelse för validering av dina GraphQL-operationer under utveckling eller i CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) är ett enkelt CLI-verktyg som hjälper till att validera GraphQL-operationer mot ett givet schema.
+
+### **Komma igång**
+
+Du kan köra verktyget enligt följande:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Noteringar:**
+
+- Ange eller ersätt $GITHUB_USER, $SUBGRAPH_NAME med lämpliga värden. Som: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- Förhandsgranskningsschema-URL:en (https://api-next.thegraph.com/) som tillhandahålls har en hög begränsning för antal begäranden och kommer att fasas ut när alla användare har migrerat till den nya versionen. **Använd den inte i produktion.**
+- Operationer identifieras i filer med följande filändelser [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` alternativ).
+
+### CLI-utdata
+
+Verktyget `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` för CLI kommer att ge utdata för eventuella fel i GraphQL-operationer enligt följande:
+
+![Felutdata från CLI](https://i.imgur.com/x1cBdhq.png)
+
+För varje fel hittar du en beskrivning, filväg och position, samt en länk till ett exempel på lösning (se följande avsnitt).
+
+## Kör dina lokala frågor mot förhandsgranskningschemat
+
+Vi tillhandahåller en ändpunkt `https://api-next.thegraph.com/` som kör en `graph-node`-version med aktiverad validering.
+
+Du kan prova att skicka frågor till:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+eller
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+För att arbeta med frågor som har markerats med valideringsfel kan du använda din favorit-GraphQL-frågeverktyg, som Altair eller [GraphiQL](https://cloud.hasura.io/public/graphiql), och testa din fråga. Dessa verktyg kommer även att markera dessa fel i sitt användargränssnitt, även innan du kör det.
+
+## Hur man löser problem
+
+Här nedan finner du alla fel för validering av GraphQL som kan uppstå i dina befintliga GraphQL-operationer.
+
+### GraphQL-variabler, operationer, fragment eller argument måste vara unika
+
+Vi har tillämpat regler för att säkerställa att en operation inkluderar en unik uppsättning GraphQL-variabler, operationer, fragment och argument.
+
+En GraphQL-operation är endast giltig om den inte innehåller någon oklarhet.
+
+För att uppnå detta måste vi säkerställa att vissa komponenter i din GraphQL-operation måste vara unika.
+
+Här är ett exempel på några ogiltiga operationer som bryter mot dessa regler:
+
+**Dubbel frågenamn (#UniqueOperationNamesRule)**
+
+```graphql
+# Följande åtgärd bröt mot UniqueOperationName
+# regeln, eftersom vi har en enda åtgärd med 2 frågor
+# med samma namn
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # Byt namn på den andra sökningen
+  namn
+}
+```
+
+**Duplikat Fragmentets namn (#UniqueFragmentNamesRule)**
+
+```graphql
+# Följande åtgärd bröt mot regeln UniqueFragmentName
+# regel.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # tilldela ett unikt namn till fragmentet
+  metadata
+}
+
+fragment MyFieldsName { # tilldela ett unikt namn till fragmentet
+  namn
+}
+```
+
+**Dubbla variabelnamn (#UniqueVariableNamesRule)**
+
+```graphql
+# Följande operation strider mot UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # behålla den relevanta variabeln (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Dubbelnamn på argument (#UniqueArgument)**
+
+```graphql
+# Följande åtgärd bröt mot UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Dubbel anonym fråga (#LoneAnonymousOperationRule)**
+
+Att använda två anonyma operationer bryter också mot regeln `LoneAnonymousOperation` på grund av konflikt i svarsstrukturen:
+
+```graphql
+# Detta kommer att misslyckas om det utförs tillsammans i
+# en enda operation med följande två frågor:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Eller namnge de två frågorna:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Överlappande fält
+
+En GraphQL-urvalsuppsättning anses endast vara giltig om den korrekt löser den slutliga resultatuppsättningen.
+
+Om en specifik urvalsuppsättning, eller ett fält, skapar tvetydighet antingen genom det valda fältet eller genom de argument som används, kommer GraphQL-tjänsten att misslyckas med att validera operationen.
+
+Här är några exempel på ogiltiga operationer som bryter mot denna regel:
+
+**Aliaser för motstridiga fält (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasfält kan orsaka konflikter, antingen med
+# andra alias eller andra fält som finns i
+# GraphQL-schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Motstridiga fält med argument (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Olika argument kan leda till olika data,
+# så vi kan inte anta att fälten kommer att vara desamma.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+I mer komplexa användningsfall kan du också bryta mot denna regel genom att använda två fragment som kan orsaka en konflikt i den slutligen förväntade uppsättningen:
+
+```graphql
+query {
+  # Till slut har vi två "x"-definitioner, som pekar
+  # till olika fält!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+Dessutom kan GraphQL-direktiv på klientsidan som `@skip` och `@include` leda till tvetydigheter, till exempel:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[Du kan läsa mer om algoritmen här] (https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Oanvända variabler eller fragment
+
+En GraphQL-operation anses också vara giltig endast om alla operationsdefinierade komponenter (variabler, fragment) används.
+
+Här är några exempel på GraphQL-operationer som bryter mot dessa regler:
+
+**Oanvänd variabel** (#NoUnusedVariablesRule)
+
+```graphql
+# Ogiltig, eftersom $someVar aldrig används.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Oanvänt fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, eftersom fragmentet AllFields aldrig används.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalid, eftersom fragmentet AllFields aldrig används.
+query something {
+  someData
+}
+
+# ta bort `AllFields` fragmentet
+```
+
+### Ogiltig eller saknad urvalsuppsättning (#ScalarLeafsRule)
+
+Dessutom är ett GraphQL-fältval endast giltigt om följande är validerat:
+
+- Ett objektfält måste ha en valuppsättning angiven.
+- Ett edge-fält (scalar, enum) får inte ha en specificerad urvalsuppsättning.
+
+Här är några exempel på brott mot dessa regler med följande Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Ogiltig urvalsuppsättning**
+
+```graphql
+query {
+  user {
+    id { # Invalid, eftersom "id" är av typen ID och inte xhar underfält
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missande urvalsgrupp**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` kräver en urvalssats för underfält!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Felaktiga argumentvärden (#VariablesInAllowedPositionRule)
+
+GraphQL-operationer som skickar hårdkodade värden till argument måste vara giltiga, baserat på det värde som definieras i schemat.
+
+Här följer några exempel på ogiltiga operationer som bryter mot dessa regler:
+
+```graphql
+query purposes {
+  # Om "name" är definierat som "String" i schemat,
+  # kommer denna fråga att misslyckas under valideringen.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# Detta kan också hända när en felaktig variabel definieras:
+
+query purposes($name: Int!) {
+  # Om "name" är definierat som `String` i schemat,
+  # kommer denna fråga att misslyckas under valideringen, eftersom
+  # variabeln som används är av typen `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Okänd typ, variabel, fragment eller direktiv (#UnknownX)
+
+GraphQL API kommer att ge ett felmeddelande om någon okänd typ, variabel, fragment eller direktiv används.
+
+Dessa okända referenser måste åtgärdas:
+
+- Byt namn om det var ett stavfel
+- annars, ta bort
+
+### Fragment: ogiltig spridning eller definition
+
+**Ogiltig spridning av fragment (#PossibleFragmentSpreadsRule)**
+
+Ett Fragment kan inte spridas på en icke tillämplig typ.
+
+Exempel: Vi kan inte tillämpa ett `Cat`-fragment på `Dog`-typen:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Ogiltig fragmentdefinition (#FragmentsOnCompositeTypesRule)**
+
+Alla Fragment måste definieras på (med `on ...`) en sammansatt typ, kort sagt: objekt, gränssnitt eller union.
+
+Följande exempel är ogiltiga, eftersom det är ogiltigt att definiera fragment på skalärer.
+
+```graphql
+fragment fragOnScalar on Int {
+# vi kan inte definiera ett fragment på en skalär (`Int`)
+  något
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` är inte en subtyp av `Dog`
+    somethingElse
+  }
+}
+```
+
+### Användning av direktiv
+
+**Direktiv kan inte användas på denna plats (#KnownDirectivesRule)**
+
+Endast GraphQL-direktiv (`@...`) som stöds av The Graph API kan användas.
+
+Här är ett exempel med de GraphQL-direktiv som stöds:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` stöds inte._
+
+**Direktivet kan endast användas en gång på denna plats (#UniqueDirectivesPerLocationRule)**
+
+De direktiv som stöds av The Graf kan endast användas en gång per plats.
+
+Följande är ogiltigt (och överflödigt):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 92f3852bb566ea6d5fc42df8c2d9791decd59b42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:35 -0500
Subject: [PATCH 1300/3820] New translations
 graphql-validations-migration-guide.mdx (Turkish)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/tr/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/tr/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/tr/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..3d1d0f76fb6b
--- /dev/null
+++ b/website/pages/tr/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL Validasyon Geçiş Kılavuzu
+---
+
+Yakında "graph-node", [GraphQL Validasyon Özelliklerinin](https://spec.graphql.org/June2018/#sec-Validation)'in %100'ünü destekleyecektir.
+
+"graph-node"un önceki sürümleri tüm doğrulamaları desteklemiyordu ve daha zarif yanıtlar veriyordu - bu nedenle, belirsizlik durumlarında "graph-node" geçersiz GraphQL işlem bileşenlerini görmezden geliyordu.
+
+GraphQL validasyon desteği, yaklaşan yeni özelliklerin ve Graph Ağı ölçeğindeki performansın temel direğidir.
+
+Ayrıca, Graph ağında önemli bir gereklilik olan sorgu yanıtlarının belirleyiciliğini de sağlayacaktır.
+
+**GraphQL validasyonlarını etkinleştirmek, Graph API'ye gönderilen bazı mevcut sorguları bozacaktır**.
+
+Bu doğrulamalarla uyumlu olmak için lütfen taşıma kılavuzunu takip edin.
+
+> ⚠️ Doğrulamalar kullanıma sunulmadan önce sorgularınızı taşımazsanız, bunlar hata döndürecek ve muhtemelen ön uçlarınızı/istemcilerinizi bozacaktır.
+
+## Taşıma Kılavuzu
+
+GraphQL işlemlerinizdeki sorunları bulmak ve düzeltmek için CLI taşıma aracını kullanabilirsiniz. Alternatif olarak, `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` uç noktasını kullanmak için GraphQL istemcinizin uç noktasını güncelleyebilirsiniz. Sorgularınızı bu uç noktaya göre test etmek, sorgularınızdaki sorunları bulmanıza yardımcı olacaktır.
+
+> Tüm subgraph'lerin taşınması gerekmez, [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) or [GraphQL Code Generator](https://the-guild.dev/graphql/codegen) kullanıyorsanız zaten sorgularınızın geçerli olmasını sağlarlar.
+
+## Geçiş CLI Aracı
+
+**GraphQL işlem hatalarının çoğu kod tabanınızda önceden bulunabilir.**
+
+Bu nedenle, geliştirme sırasında veya CI'de GraphQL işlemlerinizi doğrulamak için sorunsuz bir deneyim sağlıyoruz.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate), GraphQL işlemlerini belirli bir şemaya göre doğrulamaya yardımcı olan basit bir CLI aracıdır.
+
+### **Başlarken**
+
+Aracı aşağıdaki gibi çalıştırabilirsiniz:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notlar:**
+
+- $GITHUB_USER, $SUBGRAPH_NAME değerini uygun değerlerle ayarlayın veya değiştirin. [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks) gibi.
+- Sağlanan önizleme şeması URL'si (https://api-next.thegraph.com/) büyük oranda hız sınırlamasına sahiptir ve tüm kullanıcılar yeni sürüme geçtikten sonra kullanımdan kaldırılacaktır. **Çıktıda kullanmayın.**
+- İşlemler, aşağıdaki [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option) uzantılarına sahip dosyalarda tanımlanır.
+
+### CLI Çıktısı
+
+`[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI aracı, tüm GraphQL işlemleri hatalarını aşağıdaki gibi verir:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+Her hata için bir açıklama, dosya yolu ve konumu ve bir çözüm örneğine bağlantı bulacaksınız (aşağıdaki bölüme göz atın).
+
+## Yerel sorgularınızı önizleme şemasına göre çalıştırın
+
+Doğrulamaların açık olduğu bir "Graph Node" sürümünü çalıştıran bir uç nokta `https://api-next.thegraph.com/` sağlıyoruz.
+
+Sorguları şu adrese göndererek deneyebilirsiniz:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+yada
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+Doğrulama hataları içerdiği işaretlenen sorgular üzerinde çalışmak için Altair veya [GraphiQL](https://cloud.hasura.io/public/graphiql) gibi en sevdiğiniz GraphQL sorgulama aracını kullanabilir ve sorgunuzu deneyebilirsiniz. Bu araçlar, siz çalıştırmadan önce bile kullanıcı arayüzlerinde bu hataları işaretleyecektir.
+
+## Sorunları nasıl çözeceğiz?
+
+Aşağıda, mevcut GraphQL işlemlerinizde meydana gelebilecek tüm GraphQL doğrulama hatalarını bulacaksınız.
+
+### GraphQL değişkenleri, işlemleri, parçaları veya bağımsız değişkenleri benzersiz olmalıdır
+
+Bir işlemin benzersiz bir GraphQL değişkenleri, işlemler, parçalar ve bağımsız değişkenler kümesi içermesini sağlamak için kurallar uyguladık.
+
+Bir GraphQL işlemi, yalnızca herhangi bir belirsizlik içermiyorsa geçerlidir.
+
+Bunu başarmak için, GraphQL işleminizdeki bazı bileşenlerin benzersiz olmasını sağlamamız gerekiyor.
+
+Aşağıda, bu kuralları ihlal eden birkaç geçersiz işleme örnek verilmiştir:
+
+**Yinelenen Sorgu Adı (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Ayrıca, iki anonim işlemin kullanılması, yanıt yapısındaki çakışma nedeniyle `LoneAnonymousOperation` kuralını ihlal edecektir:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Veya iki sorguyu adlandırın:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Çakışan Alanlar
+
+Bir GraphQL seçim seti, yalnızca nihai sonuç setini doğru bir şekilde çözerse geçerli kabul edilir.
+
+Belirli bir seçim kümesi veya bir alan, seçilen alan veya kullanılan bağımsız değişkenler nedeniyle belirsizlik yaratırsa, GraphQL hizmeti işlemi doğrulamada başarısız olur.
+
+Bu kuralı ihlal eden geçersiz işlemlere birkaç örnek:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Ayrıca, daha karmaşık kullanım durumlarında, sonunda beklenen kümede bir çakışmaya neden olabilecek iki parça kullanarak bu kuralı ihlal edebilirsiniz:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+Buna ek olarak, "@skip" ve "@include" gibi müşteri tarafı GraphQL yönergeleri belirsizliğe yol açabilir, örneğin:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[Algoritma hakkında daha fazla bilgiyi buradan edinebilirsiniz.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Kullanılmayan Değişkenler veya Parçalar
+
+Bir GraphQL işlemi, yalnızca tüm işlem tanımlı bileşenler (değişkenler, parçalar) kullanılıyorsa geçerli kabul edilir.
+
+İşte bu kuralları ihlal eden GraphQL işlemleri için birkaç örnek:
+
+**Kullanılmayan Değişken** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Geçersiz veya Eksik Seçim Kümesi (#ScalarLeafsRule)
+
+Ayrıca, bir GraphQL alan seçimi yalnızca aşağıdakiler doğrulanırsa geçerlidir:
+
+- Bir nesne alanında olması gereken seçim kümesi belirtildi.
+- Bir kenar alanı (scalar, enum) belirtilen bir seçim kümesine sahip olmamalıdır.
+
+Aşağıda, aşağıdaki şema ile bu kuralların ihlaline ilişkin birkaç örnek verilmiştir:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Yanlış Bağımsız Değişken Değerleri (#VariablesInAllowedPositionRule)
+
+Sabit kodlu değerleri bağımsız değişkenlere ileten GraphQL işlemleri, şemada tanımlanan değere göre geçerli olmalıdır.
+
+Aşağıda, bu kuralları ihlal eden geçersiz işlemlere ilişkin birkaç örnek verilmiştir:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# Bu, yanlış bir değişken tanımlandığında da olabilir:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Bilinmeyen Tür, Değişken, Parça veya Yönerge (#UnknownX)
+
+Herhangi bir bilinmeyen tür, değişken, parça veya yönerge kullanılırsa GraphQL API bir hata verir.
+
+Bu bilinmeyen referanslar düzeltilmelidir:
+
+- bir yazım hatasıysa yeniden adlandır
+- aksi halde kaldır
+
+### Parça: Geçersiz Yayılma Veya Tanım
+
+**Geçersiz Parça Yayılması (#PossibleFragmentSpreadsRule)**
+
+Bir parça, geçerli olmayan bir türe yayılamaz.
+
+Örnek olarak, "Dog" türüne bir "Cat" parçası uygulayamayız:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Geçersiz Fragment Tanımı (#FragmentsOnCompositeTypesRule)**
+
+Tüm parçalar ('on ...' kullanılarak) bir bileşik tipte tanımlanmalıdır, kısacası: nesne, arayüz veya birleşim.
+
+Aşağıdaki örnekler geçersizdir, çünkü skalerler üzerinde parça tanımlama geçersizdir.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Direktif kullanımı
+
+**Yönerge bu konumda kullanılamaz (#KnownDirectivesRule)**
+
+Yalnızca Graph API tarafından desteklenen GraphQL yönergeleri ("@...") kullanılabilir.
+
+İşte GraphQL tarafından desteklenen direktiflere bir örnek:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Not: `@stream`, `@live`, `@defer` desteklenmez._
+
+**Yönerge bu konumda yalnızca bir kez kullanılabilir (#UniqueDirectivesPerLocationRule)**
+
+Graph tarafından desteklenen direktifler, lokasyon başına sadece bir kez kullanılabilir.
+
+Aşağıdakiler geçersiz (ve gereksiz):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From b13b7b3e1765b6d1edff185563639c04053d0349 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:36 -0500
Subject: [PATCH 1301/3820] New translations
 graphql-validations-migration-guide.mdx (Ukrainian)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/uk/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/uk/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/uk/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..4d909e8970a8
--- /dev/null
+++ b/website/pages/uk/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL Validations migration guide
+---
+
+Soon `graph-node` will support 100% coverage of the [GraphQL Validations specification](https://spec.graphql.org/June2018/#sec-Validation).
+
+Previous versions of `graph-node` did not support all validations and provided more graceful responses - so, in cases of ambiguity, `graph-node` was ignoring invalid GraphQL operations components.
+
+GraphQL Validations support is the pillar for the upcoming new features and the performance at scale of The Graph Network.
+
+It will also ensure determinism of query responses, a key requirement on The Graph Network.
+
+**Enabling the GraphQL Validations will break some existing queries** sent to The Graph API.
+
+To be compliant with those validations, please follow the migration guide.
+
+> ⚠️ If you do not migrate your queries before the validations are rolled out, they will return errors and possibly break your frontends/clients.
+
+## Migration guide
+
+You can use the CLI migration tool to find any issues in your GraphQL operations and fix them. Alternatively you can update the endpoint of your GraphQL client to use the `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` endpoint. Testing your queries against this endpoint will help you find the issues in your queries.
+
+> Not all subgraphs will need to be migrated, if you are using [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) or [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), they already ensure that your queries are valid.
+
+## Migration CLI tool
+
+**Most of the GraphQL operations errors can be found in your codebase ahead of time.**
+
+For this reason, we provide a smooth experience for validating your GraphQL operations during development or in CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) is a simple CLI tool that helps validate GraphQL operations against a given schema.
+
+### **Getting started**
+
+You can run the tool as follows:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notes:**
+
+- Set or replace $GITHUB_USER, $SUBGRAPH_NAME with the appropriate values. Like: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- The preview schema URL (https://api-next.thegraph.com/) provided is heavily rate-limited and will be sunset once all users have migrated to the new version. **Do not use it in production.**
+- Operations are identified in files with the following extensions [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### CLI output
+
+The `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI tool will output any GraphQL operations errors as follows:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+For each error, you will find a description, file path and position, and a link to a solution example (see the following section).
+
+## Run your local queries against the preview schema
+
+We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on.
+
+You can try out queries by sending them to:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+or
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+To work on queries that have been flagged as having validation errors, you can use your favorite GraphQL query tool, like Altair or [GraphiQL](https://cloud.hasura.io/public/graphiql), and try your query out. Those tools will also mark those errors in their UI, even before you run it.
+
+## How to solve issues
+
+Below, you will find all the GraphQL validations errors that could occur on your existing GraphQL operations.
+
+### GraphQL variables, operations, fragments, or arguments must be unique
+
+We applied rules for ensuring that an operation includes a unique set of GraphQL variables, operations, fragments, and arguments.
+
+A GraphQL operation is only valid if it does not contain any ambiguity.
+
+To achieve that, we need to ensure that some components in your GraphQL operation must be unique.
+
+Here's an example of a few invalid operations that violates these rules:
+
+**Duplicate Query name (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Or name the two queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Overlapping Fields
+
+A GraphQL selection set is considered valid only if it correctly resolves the eventual result set.
+
+If a specific selection set, or a field, creates ambiguity either by the selected field or by the arguments used, the GraphQL service will fail to validate the operation.
+
+Here are a few examples of invalid operations that violate this rule:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Also, in more complex use-cases, you might violate this rule by using two fragments that might cause a conflict in the eventually expected set:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[You can read more about the algorithm here.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Unused Variables or Fragments
+
+A GraphQL operation is also considered valid only if all operation-defined components (variables, fragments) are used.
+
+Here are a few examples for GraphQL operations that violates these rules:
+
+**Unused variable** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Invalid or missing Selection-Set (#ScalarLeafsRule)
+
+Also, a GraphQL field selection is only valid if the following is validated:
+
+- An object field must-have selection set specified.
+- An edge field (scalar, enum) must not have a selection set specified.
+
+Here are a few examples of violations of these rules with the following Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Incorrect Arguments values (#VariablesInAllowedPositionRule)
+
+GraphQL operations that pass hard-coded values to arguments must be valid, based on the value defined in the schema.
+
+Here are a few examples of invalid operations that violate these rules:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Unknown Type, Variable, Fragment, or Directive (#UnknownX)
+
+The GraphQL API will raise an error if any unknown type, variable, fragment, or directive is used.
+
+Those unknown references must be fixed:
+
+- rename if it was a typo
+- otherwise, remove
+
+### Fragment: invalid spread or definition
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+
+A Fragment cannot be spread on a non-applicable type.
+
+Example, we cannot apply a `Cat` fragment to the `Dog` type:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)**
+
+All Fragment must be defined upon (using `on ...`) a composite type, in short: object, interface, or union.
+
+The following examples are invalid, since defining fragments on scalars is invalid.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Directives usage
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+
+Only GraphQL directives (`@...`) supported by The Graph API can be used.
+
+Here is an example with The GraphQL supported directives:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` are not supported._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+
+The directives supported by The Graph can only be used once per location.
+
+The following is invalid (and redundant):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 7a2a012440aba51e722cb6ecbb230e401c81f461 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:37 -0500
Subject: [PATCH 1302/3820] New translations
 graphql-validations-migration-guide.mdx (Chinese Simplified)

---
 .../graphql-validations-migration-guide.mdx   | 539 ++++++++++++++++++
 1 file changed, 539 insertions(+)
 create mode 100644 website/pages/zh/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/zh/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/zh/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..8c4d5c52d93a
--- /dev/null
+++ b/website/pages/zh/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,539 @@
+---
+title: GraphQL验证迁移指南
+---
+
+很快，“graph-节点”将支持[GraphQL验证规范]的100%覆盖率(https://spec.graphql.org/June2018/#sec-验证）。
+
+“graph-节点”的早期版本不支持所有验证，并提供了更优雅的响应——因此，在出现歧义的情况下，“graph-节点”会忽略无效的GraphQL操作组件。
+
+GraphQL验证支持是即将推出的新功能和Graph网络规模性能的支柱。
+
+它还将确保查询响应的确定性，这是Graph网络的一个关键要求。
+
+**启用GraphQL验证将中断发送到Graph API的一些现有查询**。
+
+为了符合这些验证，请遵循迁移指南。
+
+> > ⚠️ 如果您不在验证推出之前迁移查询，它们将返回错误，并可能破坏您的前端/客户端。
+
+## 迁移指南
+
+您可以使用CLI迁移工具查找GraphQL操作中的任何问题并进行修复。或者，您可以更新GraphQL客户端的端点，以使用`https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME`端点。针对此端点测试查询将帮助您发现查询中的问题。
+
+> > 如果您使用[GraphQL ESlint]，并不是所有的子图都需要迁移(https://the-guild.dev/graphql/eslint/docs)或[GraphQL代码生成器](https://the-guild.dev/graphql/codegen)，它们已经确保了您的查询是有效的。
+
+## 迁移CLI工具
+
+**大多数GraphQL操作错误都可以提前在代码库中找到**
+
+因此，我们在开发过程中或在CI中为验证GraphQL操作提供了流畅的体验。
+
+[`@graphql验证/cli`](https://github.com/saihaj/graphql-validate)是一个简单的CLI工具，有助于根据给定的模式验证GraphQL操作。
+
+### **入门**
+
+您可以按如下方式运行该工具：
+
+```bash
+npx@graphql验证/cli-shttps://api-npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**注意事项：**
+
+- \-使用适当的值设置或替换$GITHUB_USER、$SUBGRAPH_NAME。类似：[`artblocks/artblocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- \-预览架构URL(https://api-next.thegraph.com/)所提供的是速率严重受限，并且一旦所有用户都迁移到新版本，就将是逐步关闭期。**不要在生产中使用它**
+- \-操作在具有以下扩展名的文件中标识[`.graphql`，](https://www.graphql-tools.com/docs/schema-loading#graphql-文件加载器）[`.ts`，`.tsx`，`.js`，`jsx`](https://www.graphql-tools.com/docs/schema-loading#code-文件加载程序）（“-o”选项）。
+
+### CLI输出
+
+`[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)`CLI工具将输出任何GraphQL操作错误，如下所示：
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+对于每个错误，您都会找到一个描述、文件路径和位置，以及到解决方案示例的链接（请参阅以下部分）。
+
+## 根据预览模式运行本地查询
+
+我们提供了一个端点`https://api-next.thegraph.com/`它运行一个启用了验证的“graph-节点”版本。
+
+您可以尝试将查询发送到：
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+或者
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+要处理标记为存在验证错误的查询，可以使用您最喜欢的GraphQL查询工具，如Altair或[GraphiQL](https://cloud.hasura.io/public/graphiql)，然后尝试您的查询。这些工具还会在用户界面中标记这些错误，甚至在您运行之前。
+
+## 如何解决问题
+
+下面，您将发现现有GraphQL操作中可能发生的所有GraphQL验证错误。
+
+### GraphQL变量、操作、片段或参数必须是唯一的
+
+我们应用了规则来确保操作包含一组唯一的GraphQL变量、操作、片段和参数。
+
+GraphQL操作只有在不包含任何歧义的情况下才有效。
+
+为了实现这一点，我们需要确保GraphQL操作中的某些组件必须是唯一的。
+
+以下是一些违反这些规则的无效操作的示例：
+
+**重复查询名称（#UniqueOperationNamesRule）**
+
+```graphql
+#以下操作违反了UniqueOperationName
+#规则，因为我们有一个带有2个查询的单个操作
+#具有相同的名称
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_解决方案:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # 重新给第二个查询命名
+  name
+}
+```
+
+**重复操作名称（#UniqueOperationNamesRule）**
+
+```graphql
+#以下操作违反了UniqueOperationName
+#规则。
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_解决方案:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**重复变量名称（#UniqueOperationNamesRule）**
+
+```graphql
+#以下操作违反了UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_解决方案:_
+
+```graphql
+query myData($id: String) {
+  # 保持相关变量(这里是: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**重复参数名称（#UniqueOperationNamesRule）**
+
+```graphql
+#以下操作违反了UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_解决方案:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**重复的匿名查询（#LoneAnonymousOperationRule）**
+
+此外，由于响应结构中的冲突，使用两个匿名操作将违反“LoneAnonymousOperation”规则：
+
+```graphql
+#如果在中一起执行，则此操作将失败
+#具有以下两个查询的单个操作：
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_解决方案:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+或者命名两个查询：
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### 重叠域
+
+GraphQL选择集只有在正确解析最终结果集时才被视为有效。
+
+如果特定的选择集或字段由于所选字段或使用的参数而产生歧义，GraphQL服务将无法验证该操作。
+
+以下是一些违反这些规则的无效操作的示例：
+
+**字段别名冲突（#OverlappingFieldsCanBeMergedRule）**
+
+```graphql
+#别名字段可能会导致冲突，或者
+#存在的其他别名或其他字段
+#在GraphQL模式上。
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_解决方案:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # 是原名 `name` 的别名
+  }
+}
+```
+
+**参数字段冲突（#OverlappingFieldsCanBeMergedRule）**
+
+```graphql
+#不同的参数可能导致不同的数据，
+#所以我们不能假设字段是相同的。
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_解决方案:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+此外，在更复杂的用例中，您可能会使用两个片段来违反此规则，这两个片段可能会在最终预期的集合中引起冲突：
+
+```graphql
+query {
+  # 最终，我们有两个"x"的定义，指向
+  # 不同的域!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+除此之外，客户端GraphQL指令（如“@skip”和“@include”）可能会导致歧义，例如：
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[您可以在此处阅读有关算法的更多信息。](https://spec.graphql.org/June2018/#sec-字段选择合并）
+
+### 未使用的变量或片段
+
+只有当使用了所有操作定义的组件（变量、片段）时，GraphQL操作才被认为是有效的。
+
+以下是一些违反这些规则的无效操作的示例：
+
+**未使用的变量**（#NoUnusedVariablesRule）
+
+````graphql
+#无效，因为从未使用过$someVar。
+查询某物（$someVar: String）{
+某些数据
+}
+
+```
+````
+
+_解决方案:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**未使用的片段**（#NoUnusedFragmentsRule）
+
+```graphql
+#无效，因为片段AllFields从未使用过。
+询问某事{
+  someData
+}
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_解决方案:_
+
+```graphql
+#无效，因为片段AllFields从未使用过。
+询问某事{
+  someData
+}
+
+#删除`AllFields'片段
+```
+
+### 无效或缺少选择集（#ScalarLeafsRule）
+
+此外，GraphQL字段选择只有在以下内容得到验证时才有效：
+
+- 指定了对象字段的必备选择集。
+- 边缘字段（标量、枚举）不能指定选择集。
+
+以下是下列模式违反这些规则的几个示例：
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**无效的选择集**
+
+```graphql
+query {
+  user {
+    id { # 无效, 因为"id"是ID类型且没有子域
+
+    }
+  }
+}
+```
+
+_解决方案:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**缺少选择集**
+
+```graphql
+query {
+  user {
+    id
+    image # `image`需要一个子域的选择集
+  }
+}
+```
+
+_解决方案:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### 参数值不正确（#VariablesInAllowedPositionRule）
+
+根据模式中定义的值，将硬编码值传递给参数的GraphQL操作必须有效。
+
+以下是一些违反这些规则的无效操作的示例：
+
+```graphql
+query purposes {
+  # 如果“name”在模式中被定义为“String”，
+  #此查询将在验证过程中失败。
+  purpose(name: 1) {
+    id
+  }
+}
+
+#当定义了不正确的变量时，也可能发生这种情况：
+
+query purposes($name: Int!) {
+  #如果“name”在模式中被定义为“String”，
+  #此查询将在验证期间失败，因为
+  #使用的变量类型为`Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### 未知类型、变量、片段或指令（#UnknownX）
+
+如果使用任何未知类型、变量、片段或指令，GraphQLAPI将引发错误。
+
+必须修复这些未知引用：
+
+- 如果是打字错误，请重命名
+- 否则，请删除
+
+### 片段：无效的排列或定义
+
+**无效的片段排列（#PossibleFragmentSpreadsRule）**
+
+片段不能在不适用的类型上展开。
+
+例如，我们不能将“Cat”片段应用于“Dog”类型：
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**片段定义无效（#FragmentsOnCompositeTypesRule）**
+
+所有Fragment都必须在复合类型上定义（使用“on…”），简而言之：对象、接口或并集。
+
+以下示例无效，因为在标量上定义fragment是无效的。
+
+```graphql
+fragment fragOnScalar on Int {
+  # 不能在标量`int`上定义`fragment`
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` 不是`Dog`的子类型
+    somethingElse
+  }
+}
+```
+
+### 指令使用
+
+**指令不能在此位置使用（#KnownDirectivesRule）**
+
+只能使用Graph API支持的GraphQL指令（`@…`）。
+
+以下是GraphQL支持的指令示例：
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_注意：不支持“@stream”、“@live”和“@defer”_
+
+**指令在此位置只能使用一次（#UniqueDirectivesPerLocationRule）**
+
+The Graph支持的指令在每个位置只能使用一次。
+
+以下内容无效（并且是多余的）：
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From f936175dd8e31140bd2d26859b0dae92ceb5e142 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:38 -0500
Subject: [PATCH 1303/3820] New translations
 graphql-validations-migration-guide.mdx (Urdu (Pakistan))

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/ur/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/ur/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/ur/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..3d1289e29dd2
--- /dev/null
+++ b/website/pages/ur/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL کی توثیق کی منتقلی گائیڈ
+---
+
+جلد ہی `گراف نوڈ` [GraphQL توثیق کی تفصیلات](https://spec.graphql.org/June2018/#sec-Validation) کی 100% کوریج کو سپورٹ کرے گا.
+
+`گراف نوڈ` کے پچھلے ورژن تمام توثیقوں کی حمایت نہیں کرتے تھے اور زیادہ خوبصورت جوابات فراہم کرتے تھے - لہذا، ابہام کی صورت میں، `گراف نوڈ` غلط گراف کیو ایل
+ آپریشن کے اجزاء کو نظر انداز کر رہا تھا.
+
+GraphQL ویلیڈیشن سپورٹ آنے والی نئی خصوصیات اور گراف نیٹ ورک کے پیمانے پر کارکردگی کا ایک ستون ہے.
+
+یہ کیوری کے جوابات کے تعین کو بھی یقینی بنائے گا، جو گراف نیٹ ورک پر ایک اہم ضرورت ہے.
+
+**GraphQL کی توثیق کو فعال کرنے سے کچھ موجودہ کیوریز ختم ہو جائیں گے** جو گراف API کو بھیجے گئے ہیں.
+
+ان توثیقوں کی تعمیل کرنے کے لیے، براہ کرم مائگریشن گائیڈ پر عمل کریں.
+
+> ⚠️ اگر آپ اپنے کیوریز کو توثیق کرنے سے پہلے منتقل نہیں کرتے ہیں، تو وہ غلطیاں واپس کریں گے اور ممکنہ طور پر آپ کے فرنٹ اینڈ/کلائنٹس کو توڑ دیں گے.
+
+## مائیگریشن گائیڈ
+
+آپ اپنے GraphQL آپریشنز میں کسی بھی مسئلے کو تلاش کرنے اور انہیں ٹھیک کرنے کے لیے CLI مائیگریشن ٹول استعمال کر سکتے ہیں۔ متبادل طور پر آپ `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` اینڈ پوائنٹ استعمال کرنے کے لیے اپنے GraphQL کلائنٹ کے اینڈ پوائنٹ کو اپ ڈیٹ کر سکتے ہیں۔ اس اختتامی نقطہ کے خلاف اپنے کیوریز کی جانچ کرنے سے آپ کو اپنے کیوریز میں مسائل تلاش کرنے میں مدد ملے گی.
+
+> اگر آپ [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) یا [ GraphQL کوڈ جنریٹر] (//https://the-guild.dev) استعمال کر رہے ہیں تو تمام سب گراف کو منتقل کرنے کی ضرورت نہیں ہوگی۔ /graphql/codegen، وہ پہلے ہی اس بات کو یقینی بناتے ہیں کہ آپ کے کیوریز درست ہیں.
+
+## مائیگریشن CLI ٹول
+
+**GraphQL آپریشنز کی زیادہ تر خرابیاں آپ کے کوڈ بیس میں وقت سے پہلے پائی جا سکتی ہیں۔**
+
+اس وجہ سے، ہم ترقی کے دوران یا CI میں آپ کے GraphQL آپریشنز کی توثیق کرنے کے لیے ایک ہموار تجربہ فراہم کرتے ہیں.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) ایک سادہ سی ایل آئی ٹول ہے جو دیئے گئے اسکیما کے خلاف GraphQL آپریشنز کی توثیق کرنے میں مدد کرتا ہے.
+
+### **شروع ہوا چاہتا ہے**
+
+آپ اس آلے کو اس طرح چلا سکتے ہیں:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**نوٹس:**
+
+- $GITHUB_USER، $SUBGRAPH_NAME کو مناسب اقدار کے ساتھ سیٹ یا تبدیل کریں۔ جیسے: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- پیش نظارہ اسکیما URL (https://api-next.thegraph.com/) فراہم کردہ بہت زیادہ شرح سے محدود ہے اور تمام صارفین کے نئے ورژن پر منتقل ہونے کے بعد غروب ہو جائے گا۔ **اسے پیداوار میں استعمال نہ کریں۔**
+- مندرجہ ذیل ایکسٹینشنز [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx کے ساتھ فائلوں میں آپریشنز کی شناخت کی جاتی ہے۔ `, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` آپشن).
+
+### CLI آؤٹ پٹ
+
+`[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI ٹول کسی بھی گراف کیو ایل آپریشن کی خرابیوں کو اس طرح آؤٹ پٹ کرے گا:
+
+![CLI سے خرابی کی پیداوار](https://i.imgur.com/x1cBdhq.png)
+
+ہر غلطی کے لیے، آپ کو تفصیل، فائل کا راستہ اور پوزیشن، اور حل کی مثال کا لنک ملے گا (مندرجہ ذیل سیکشن دیکھیں).
+
+## اپنے مقامی کیوریز کو پیش نظارہ اسکیما کے خلاف چلائیں
+
+ہم ایک اینڈ پوائنٹ فراہم کرتے ہیں `https://api-next.thegraph.com/` جو ایک `گراف نوڈ` ورژن چلاتا ہے جس کی توثیق آن ہے.
+
+آپ کیوریز کو ان پر بھیج کر آزما سکتے ہیں:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+یا
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+ان کیوریز پر کام کرنے کے لیے جن کو توثیق کی خرابیوں کے طور پر نشان زد کیا گیا ہے، آپ اپنا پسندیدہ GraphQL کیوریز کا ٹول استعمال کر سکتے ہیں، جیسے الٹیر یا [GraphiQL](https://cloud.hasura.io/public/graphiql)، اور اپنے کیوری کو آزمائیں۔ وہ ٹولز ان غلطیوں کو اپنے UI میں بھی نشان زد کریں گے، یہاں تک کہ آپ اسے چلانے سے پہلے.
+
+## مسائل کو حل کرنے کا طریقہ
+
+ذیل میں، آپ کو GraphQL کی توثیق کی وہ تمام خرابیاں ملیں گی جو آپ کے موجودہ GraphQL آپریشنز میں ہو سکتی ہیں.
+
+### GraphQL متغیرات، آپریشنز، ٹکڑے، یا دلائل منفرد ہونے چاہئیں
+
+ہم نے اس بات کو یقینی بنانے کے لیے قواعد لاگو کیے ہیں کہ آپریشن میں GraphQL متغیرات، آپریشنز، ٹکڑوں اور دلائل کا ایک منفرد سیٹ شامل ہے.
+
+GraphQL آپریشن صرف اس صورت میں درست ہے جب اس میں کوئی ابہام نہ ہو.
+
+اس کو حاصل کرنے کے لیے، ہمیں یہ یقینی بنانا ہوگا کہ آپ کے GraphQL آپریشن میں کچھ اجزاء منفرد ہونے چاہئیں.
+
+یہاں چند غلط کارروائیوں کی ایک مثال ہے جو ان اصولوں کی خلاف ورزی کرتی ہیں:
+
+**نقل کیوری کا نام (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_حل:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**ڈپلیکیٹ ٹکڑے کا نام (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_حل:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**ڈپلیکیٹ متغیر نام (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_حل:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**ڈپلیکیٹ دلیل کا نام (#Unique Argument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_حل:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**ڈپلیکیٹ گمنام کیوری (#LoneAnonymousOperationRule)**
+
+نیز، جوابی ڈھانچے میں تضاد کی وجہ سے دو گمنام آپریشنز کا استعمال 'LoneAnonymousOperation' اصول کی خلاف ورزی کرے گا:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_حل:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+یا دو کیوریز کا نام دیں:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### اوور لیپنگ فیلڈز
+
+GraphQL سلیکشن سیٹ صرف اس صورت میں درست سمجھا جاتا ہے جب یہ حتمی نتیجہ سیٹ کو درست طریقے سے حل کرتا ہے.
+
+اگر کوئی مخصوص سلیکشن سیٹ، یا فیلڈ، منتخب فیلڈ یا استعمال شدہ دلائل کے ذریعے ابہام پیدا کرتا ہے، تو GraphQL سروس آپریشن کی توثیق کرنے میں ناکام ہو جائے گی.
+
+یہاں غلط کاروائیوں کی چند مثالیں ہیں جو اس اصول کی خلاف ورزی کرتی ہیں:
+
+**متضاد فیلڈز عرفی نام (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_حل:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+```
+
+**دلائل کے ساتھ متضاد فیلڈز (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_حل:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+اس کے علاوہ، زیادہ پیچیدہ استعمال کے معاملات میں، آپ دو ٹکڑے استعمال کر کے اس اصول کی خلاف ورزی کر سکتے ہیں جو بالآخر متوقع سیٹ میں تنازعہ کا سبب بن سکتے ہیں:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+اس کے علاوہ، کلائنٹ سائڈ گراف کیو ایل ڈائریکٹیو جیسے `@skip` اور `@include` ابہام کا باعث بن سکتے ہیں، مثال کے طور پر:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[آپ الگورتھم کے بارے میں یہاں مزید پڑھ سکتے ہیں۔](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### غیر استعمال شدہ متغیرات یا ٹکڑے
+
+GraphQL آپریشن کو بھی صرف اسی صورت میں درست سمجھا جاتا ہے جب آپریشن سے متعین تمام اجزاء (متغیرات، ٹکڑے) استعمال کیے جائیں.
+
+یہاں GraphQL آپریشنز کے لیے چند مثالیں ہیں جو ان اصولوں کی خلاف ورزی کرتی ہیں:
+
+**غیر استعمال شدہ متغیر** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_حل:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**غیر استعمال شدہ ٹکڑا** (#NoUnused FragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_حل:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### غلط یا غائب سلیکشن سیٹ (#ScalarLeafsRule)
+
+نیز، GraphQL فیلڈ کا انتخاب صرف اس صورت میں درست ہے جب درج ذیل کی توثیق کی گئی ہو:
+
+- ایک آبجیکٹ فیلڈ میں انتخاب کا سیٹ ہونا ضروری ہے.
+- ایک کنارے والے فیلڈ (اسکیلر، اینم) میں انتخابی سیٹ متعین نہیں ہونا چاہیے.
+
+درج ذیل اسکیما کے ساتھ ان قواعد کی خلاف ورزیوں کی چند مثالیں یہ ہیں:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**غلط سلیکشن سیٹ**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_حل:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**موجود سلیکشن سیٹ**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_حل:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### غلط دلائل کی قدریں (#VariablesInAllowedPositionRule)
+
+GraphQL آپریشنز جو ہارڈ کوڈ شدہ اقدار کو آرگیومینٹس میں منتقل کرتے ہیں، اسکیما میں بیان کردہ قدر کی بنیاد پر درست ہونے چاہئیں.
+
+یہاں غلط کارروائیوں کی چند مثالیں ہیں جو ان اصولوں کی خلاف ورزی کرتی ہیں:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### نامعلوم قسم، متغیر، ٹکڑا، یا ہدایت (#UnknownX)
+
+اگر کوئی نامعلوم قسم، متغیر، ٹکڑا، یا ہدایت کا استعمال کیا جاتا ہے تو GraphQL API ایک خرابی پیدا کرے گا.
+
+ان نامعلوم حوالہ جات کو درست کرنا ضروری ہے:
+
+- اگر یہ ٹائپنگ کی غلطی تھی تو نام تبدیل کریں
+- دوسری صورت میں، ہٹا دیں
+
+### ٹکڑا: غلط پھیلاؤ یا تعریف
+
+**غلط فریگمنٹ اسپریڈ (#PossibleFragmentSpreadsRule)**
+
+ایک ٹکڑا ایک غیر قابل اطلاق قسم پر پھیلایا نہیں جا سکتا.
+
+مثال کے طور پر، ہم 'کتے' کی قسم پر 'بلی' کے ٹکڑے کا اطلاق نہیں کر سکتے ہیں:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**فریگمنٹ کی غلط تعریف (#FragmentsOnCompositeTypesRule)**
+
+تمام ٹکڑوں کو ایک جامع قسم پر (`آن...` کا استعمال کرتے ہوئے) بیان کیا جانا چاہیے، مختصر میں: آبجیکٹ، انٹرفیس، یا یونین.
+
+درج ذیل مثالیں غلط ہیں، کیونکہ اسکیلرز پر ٹکڑوں کی وضاحت کرنا غلط ہے.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### ہدایات کا استعمال
+
+**ہدایت کو اس مقام پر استعمال نہیں کیا جا سکتا (#KnownDirectivesRule)**
+
+صرف GraphQL ڈائریکٹیو (`@...`) کو استعمال کیا جا سکتا ہے جو گراف API کے ذریعے تعاون یافتہ ہیں.
+
+GraphQL کی معاونت والی ہدایات کے ساتھ ایک مثال یہ ہے:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_نوٹ: `@stream`، `@live`، `@defer` تعاون یافتہ نہیں ہیں۔_
+
+**ہدایت کو اس مقام پر صرف ایک بار استعمال کیا جا سکتا ہے (#UniqueDirectivesPerLocationRule)**
+
+گراف کی طرف سے تعاون یافتہ ہدایات فی مقام صرف ایک بار استعمال کی جا سکتی ہیں.
+
+درج ذیل غلط ہے (اور بے کار):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 57db76b75fe35509619b83ab90751bd6dcc64740 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:39 -0500
Subject: [PATCH 1304/3820] New translations
 graphql-validations-migration-guide.mdx (Vietnamese)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/vi/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/vi/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/vi/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..4d909e8970a8
--- /dev/null
+++ b/website/pages/vi/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL Validations migration guide
+---
+
+Soon `graph-node` will support 100% coverage of the [GraphQL Validations specification](https://spec.graphql.org/June2018/#sec-Validation).
+
+Previous versions of `graph-node` did not support all validations and provided more graceful responses - so, in cases of ambiguity, `graph-node` was ignoring invalid GraphQL operations components.
+
+GraphQL Validations support is the pillar for the upcoming new features and the performance at scale of The Graph Network.
+
+It will also ensure determinism of query responses, a key requirement on The Graph Network.
+
+**Enabling the GraphQL Validations will break some existing queries** sent to The Graph API.
+
+To be compliant with those validations, please follow the migration guide.
+
+> ⚠️ If you do not migrate your queries before the validations are rolled out, they will return errors and possibly break your frontends/clients.
+
+## Migration guide
+
+You can use the CLI migration tool to find any issues in your GraphQL operations and fix them. Alternatively you can update the endpoint of your GraphQL client to use the `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` endpoint. Testing your queries against this endpoint will help you find the issues in your queries.
+
+> Not all subgraphs will need to be migrated, if you are using [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) or [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), they already ensure that your queries are valid.
+
+## Migration CLI tool
+
+**Most of the GraphQL operations errors can be found in your codebase ahead of time.**
+
+For this reason, we provide a smooth experience for validating your GraphQL operations during development or in CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) is a simple CLI tool that helps validate GraphQL operations against a given schema.
+
+### **Getting started**
+
+You can run the tool as follows:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notes:**
+
+- Set or replace $GITHUB_USER, $SUBGRAPH_NAME with the appropriate values. Like: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- The preview schema URL (https://api-next.thegraph.com/) provided is heavily rate-limited and will be sunset once all users have migrated to the new version. **Do not use it in production.**
+- Operations are identified in files with the following extensions [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### CLI output
+
+The `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI tool will output any GraphQL operations errors as follows:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+For each error, you will find a description, file path and position, and a link to a solution example (see the following section).
+
+## Run your local queries against the preview schema
+
+We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on.
+
+You can try out queries by sending them to:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+or
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+To work on queries that have been flagged as having validation errors, you can use your favorite GraphQL query tool, like Altair or [GraphiQL](https://cloud.hasura.io/public/graphiql), and try your query out. Those tools will also mark those errors in their UI, even before you run it.
+
+## How to solve issues
+
+Below, you will find all the GraphQL validations errors that could occur on your existing GraphQL operations.
+
+### GraphQL variables, operations, fragments, or arguments must be unique
+
+We applied rules for ensuring that an operation includes a unique set of GraphQL variables, operations, fragments, and arguments.
+
+A GraphQL operation is only valid if it does not contain any ambiguity.
+
+To achieve that, we need to ensure that some components in your GraphQL operation must be unique.
+
+Here's an example of a few invalid operations that violates these rules:
+
+**Duplicate Query name (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Or name the two queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Overlapping Fields
+
+A GraphQL selection set is considered valid only if it correctly resolves the eventual result set.
+
+If a specific selection set, or a field, creates ambiguity either by the selected field or by the arguments used, the GraphQL service will fail to validate the operation.
+
+Here are a few examples of invalid operations that violate this rule:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Also, in more complex use-cases, you might violate this rule by using two fragments that might cause a conflict in the eventually expected set:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[You can read more about the algorithm here.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Unused Variables or Fragments
+
+A GraphQL operation is also considered valid only if all operation-defined components (variables, fragments) are used.
+
+Here are a few examples for GraphQL operations that violates these rules:
+
+**Unused variable** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Invalid or missing Selection-Set (#ScalarLeafsRule)
+
+Also, a GraphQL field selection is only valid if the following is validated:
+
+- An object field must-have selection set specified.
+- An edge field (scalar, enum) must not have a selection set specified.
+
+Here are a few examples of violations of these rules with the following Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Incorrect Arguments values (#VariablesInAllowedPositionRule)
+
+GraphQL operations that pass hard-coded values to arguments must be valid, based on the value defined in the schema.
+
+Here are a few examples of invalid operations that violate these rules:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Unknown Type, Variable, Fragment, or Directive (#UnknownX)
+
+The GraphQL API will raise an error if any unknown type, variable, fragment, or directive is used.
+
+Those unknown references must be fixed:
+
+- rename if it was a typo
+- otherwise, remove
+
+### Fragment: invalid spread or definition
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+
+A Fragment cannot be spread on a non-applicable type.
+
+Example, we cannot apply a `Cat` fragment to the `Dog` type:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)**
+
+All Fragment must be defined upon (using `on ...`) a composite type, in short: object, interface, or union.
+
+The following examples are invalid, since defining fragments on scalars is invalid.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Directives usage
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+
+Only GraphQL directives (`@...`) supported by The Graph API can be used.
+
+Here is an example with The GraphQL supported directives:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` are not supported._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+
+The directives supported by The Graph can only be used once per location.
+
+The following is invalid (and redundant):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 1175212d595eda8362dab0831df4b6acfc3d4999 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:40 -0500
Subject: [PATCH 1305/3820] New translations
 graphql-validations-migration-guide.mdx (Marathi)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/mr/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/mr/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/mr/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..b0540fd8bbc8
--- /dev/null
+++ b/website/pages/mr/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL Validations migration guide
+---
+
+Soon `graph-node` will support 100% coverage of the [GraphQL Validations specification](https://spec.graphql.org/June2018/#sec-Validation).
+
+`graph-node` च्या मागील आवृत्त्यांनी सर्व प्रमाणीकरणांना समर्थन दिले नाही आणि अधिक सुंदर प्रतिसाद दिले - म्हणून, संदिग्धतेच्या बाबतीत, `graph-node` अवैध GraphQL ऑपरेशन घटकांकडे दुर्लक्ष करत आहे.
+
+GraphQL Validations support is the pillar for the upcoming new features and the performance at scale of The Graph Network.
+
+It will also ensure determinism of query responses, a key requirement on The Graph Network.
+
+**Enabling the GraphQL Validations will break some existing queries** sent to The Graph API.
+
+To be compliant with those validations, please follow the migration guide.
+
+> ⚠️ If you do not migrate your queries before the validations are rolled out, they will return errors and possibly break your frontends/clients.
+
+## स्थलांतर मार्गदर्शक
+
+तुमच्या GraphQL ऑपरेशन्समधील समस्या शोधण्यासाठी आणि त्यांचे निराकरण करण्यासाठी तुम्ही CLI माइग्रेशन टूल वापरू शकता. वैकल्पिकरित्या तुम्ही `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` एंडपॉइंट वापरण्यासाठी तुमच्या GraphQL क्लायंटचा एंडपॉइंट अपडेट करू शकता. या एंडपॉइंटवर तुमच्या क्वेरींची चाचणी केल्याने तुम्हाला तुमच्या क्वेरींमधील समस्या शोधण्यात मदत होईल.
+
+> तुम्ही [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) किंवा [GraphQL कोड जनरेटर](https://the-guild.dev) वापरत असल्यास, सर्व उपग्राफ स्थलांतरित करण्याची गरज नाही /graphql/codegen), ते तुमच्या क्वेरी वैध असल्याची खात्री करतात.
+
+## Migration CLI tool
+
+**Most of the GraphQL operations errors can be found in your codebase ahead of time.**
+
+For this reason, we provide a smooth experience for validating your GraphQL operations during development or in CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) हे एक साधे CLI साधन आहे जे दिलेल्या स्कीमावर GraphQL ऑपरेशन्स प्रमाणित करण्यात मदत करते.
+
+### **Getting started**
+
+You can run the tool as follows:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notes:**
+
+- योग्य मूल्यांसह $GITHUB_USER, $SUBGRAPH_NAME सेट किंवा पुनर्स्थित करा. जसे: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- प्रिव्ह्यू स्कीमा URL (https://api-next.thegraph.com/) प्रदान केली आहे हे खूप प्रमाणात मर्यादित आहे आणि सर्व वापरकर्ते नवीन आवृत्तीवर स्थलांतरित झाल्यावर सूर्यास्त होईल. **उत्पादनात वापरू नका.**
+- खालील विस्तार [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx सह फायलींमध्ये ऑपरेशन ओळखले जातात `, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` पर्याय).
+
+### CLI output
+
+The `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI tool will output any GraphQL operations errors as follows:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+For each error, you will find a description, file path and position, and a link to a solution example (see the following section).
+
+## Run your local queries against the preview schema
+
+We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on.
+
+You can try out queries by sending them to:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+किंवा
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+प्रमाणीकरण त्रुटी म्हणून ध्वजांकित केलेल्या क्वेरींवर कार्य करण्यासाठी, तुम्ही तुमचे आवडते GraphQL क्वेरी टूल वापरू शकता, जसे की Altair किंवा [GraphiQL](https://cloud.hasura.io/public/graphiql), आणि तुमची क्वेरी वापरून पहा. ती साधने तुम्ही चालवण्यापूर्वीच त्यांच्या UI मध्ये त्या त्रुटी देखील चिन्हांकित करतील.
+
+## समस्यांचे निराकरण कसे करावे
+
+Below, you will find all the GraphQL validations errors that could occur on your existing GraphQL operations.
+
+### GraphQL variables, operations, fragments, or arguments must be unique
+
+We applied rules for ensuring that an operation includes a unique set of GraphQL variables, operations, fragments, and arguments.
+
+A GraphQL operation is only valid if it does not contain any ambiguity.
+
+To achieve that, we need to ensure that some components in your GraphQL operation must be unique.
+
+Here's an example of a few invalid operations that violates these rules:
+
+**Duplicate Query name (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Or name the two queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Overlapping Fields
+
+A GraphQL selection set is considered valid only if it correctly resolves the eventual result set.
+
+If a specific selection set, or a field, creates ambiguity either by the selected field or by the arguments used, the GraphQL service will fail to validate the operation.
+
+Here are a few examples of invalid operations that violate this rule:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Also, in more complex use-cases, you might violate this rule by using two fragments that might cause a conflict in the eventually expected set:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[You can read more about the algorithm here.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Unused Variables or Fragments
+
+A GraphQL operation is also considered valid only if all operation-defined components (variables, fragments) are used.
+
+Here are a few examples for GraphQL operations that violates these rules:
+
+**Unused variable** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### अवैध किंवा गहाळ निवड-सेट (#ScalarLeafsRule)
+
+Also, a GraphQL field selection is only valid if the following is validated:
+
+- An object field must-have selection set specified.
+- An edge field (scalar, enum) must not have a selection set specified.
+
+Here are a few examples of violations of these rules with the following Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Incorrect Arguments values (#VariablesInAllowedPositionRule)
+
+GraphQL operations that pass hard-coded values to arguments must be valid, based on the value defined in the schema.
+
+Here are a few examples of invalid operations that violate these rules:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Unknown Type, Variable, Fragment, or Directive (#UnknownX)
+
+The GraphQL API will raise an error if any unknown type, variable, fragment, or directive is used.
+
+Those unknown references must be fixed:
+
+- rename if it was a typo
+- otherwise, remove
+
+### तुकडा: अवैध स्प्रेड किंवा परिभाषा
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+
+A Fragment cannot be spread on a non-applicable type.
+
+Example, we cannot apply a `Cat` fragment to the `Dog` type:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)**
+
+All Fragment must be defined upon (using `on ...`) a composite type, in short: object, interface, or union.
+
+The following examples are invalid, since defining fragments on scalars is invalid.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Directives usage
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+
+Only GraphQL directives (`@...`) supported by The Graph API can be used.
+
+Here is an example with The GraphQL supported directives:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` are not supported._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+
+The directives supported by The Graph can only be used once per location.
+
+The following is invalid (and redundant):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 1ac319c4f61f57cad4f170e388291515dd358627 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:41 -0500
Subject: [PATCH 1306/3820] New translations
 graphql-validations-migration-guide.mdx (Hindi)

---
 .../graphql-validations-migration-guide.mdx   | 539 ++++++++++++++++++
 1 file changed, 539 insertions(+)
 create mode 100644 website/pages/hi/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/hi/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/hi/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..71a47e6e2ac3
--- /dev/null
+++ b/website/pages/hi/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,539 @@
+---
+title: ग्राफक्यूएल सत्यापन माइग्रेशन गाइड
+---
+
+जल्द ही `ग्राफ़-नोड` [ग्राफ़क्यूएल सत्यापन विनिर्देश] (https://spec.graphql.org/June2018/#sec-Validation) के 100% कवरेज का समर्थन करेगा।
+
+`ग्राफ़-नोड` के पिछले संस्करण सभी सत्यापनों का समर्थन नहीं करते थे और अधिक सुंदर प्रतिक्रियाएँ प्रदान करते थे - इसलिए, अस्पष्टता के मामलों में, `ग्राफ़-नोड` अमान्य ग्राफ़क्यूएल संचालन घटकों की अनदेखी कर रहा था।
+
+ग्राफक्यूएल सत्यापन समर्थन आगामी नई सुविधाओं और ग्राफ नेटवर्क के पैमाने पर प्रदर्शन के लिए स्तंभ है।
+
+यह क्वेरी प्रतिक्रियाओं के निर्धारण को भी सुनिश्चित करेगा, जो कि ग्राफ नेटवर्क पर एक प्रमुख आवश्यकता है।
+
+**GraphQL Validations को सक्षम करने से कुछ मौजूदा क्वेरीज़ टूट जाएंगी** जो ग्राफ़ API को भेजी गई हैं।
+
+उन मान्यताओं का अनुपालन करने के लिए, कृपया माइग्रेशन गाइड का पालन करें।
+
+> ⚠️ यदि आप सत्यापन शुरू होने से पहले अपने प्रश्नों को माइग्रेट नहीं करते हैं, तो वे त्रुटियां लौटाएंगे और संभवत: आपके फ़्रंटएंड/क्लाइंट को तोड़ देंगे।
+
+## प्रवासन गाइड
+
+आप अपने ग्राफक्यूएल संचालन में किसी भी समस्या का पता लगाने और उन्हें ठीक करने के लिए सीएलआई माइग्रेशन टूल का उपयोग कर सकते हैं। वैकल्पिक रूप से आप `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` समापन बिंदु का उपयोग करने के लिए अपने ग्राफ़िकल क्लाइंट के समापन बिंदु को अपडेट कर सकते हैं। इस समापन बिंदु के विरुद्ध अपने प्रश्नों का परीक्षण करने से आपको अपने प्रश्नों में समस्याओं का पता लगाने में मदद मिलेगी।
+
+> अगर आप [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) या [GraphQL Code Generator](https://the-guild.dev) का इस्तेमाल कर रहे हैं, तो सभी सबग्राफ को माइग्रेट करने की ज़रूरत नहीं है /graphql/codegen), वे पहले से ही सुनिश्चित करते हैं कि आपके प्रश्न मान्य हैं।
+
+## माइग्रेशन सीएलआई टूल
+
+**ज्यादातर ग्राफक्यूएल संचालन त्रुटियां समय से पहले आपके कोडबेस में पाई जा सकती हैं।**
+
+इस कारण से, हम विकास के दौरान या सीआई में आपके ग्राफक्यूएल संचालन को मान्य करने के लिए एक सहज अनुभव प्रदान करते हैं।
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) एक सरल सीएलआई उपकरण है जो किसी दिए गए स्कीमा के खिलाफ ग्राफक्यूएल संचालन को मान्य करने में मदद करता है।
+
+### शुरू करना
+
+आप टूल को निम्नानुसार चला सकते हैं:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**टिप्पणियाँ:**
+
+- $GITHUB_USER, $SUBGRAPH_NAME को उपयुक्त मानों के साथ सेट करें या बदलें। जैसे: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- प्रदान किया गया पूर्वावलोकन स्कीमा URL (https://api-next.thegraph.com/) अत्यधिक दर-सीमित है और एक बार सभी उपयोगकर्ताओं के नए संस्करण में माइग्रेट हो जाने के बाद समाप्त हो जाएगा। **उत्पादन में इसका उपयोग न करें।**
+- निम्नलिखित एक्सटेंशन वाली फाइलों में संचालन की पहचान की जाती है [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx `, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` विकल्प)।
+
+### सीएलआई आउटपुट
+
+`[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` सीएलआई टूल किसी भी ग्राफक्यूएल संचालन त्रुटियों को निम्नानुसार आउटपुट करेगा:
+
+![सीएलआई से त्रुटि आउटपुट](https://i.imgur.com/x1cBdhq.png)
+
+प्रत्येक त्रुटि के लिए, आपको विवरण, फ़ाइल पथ और स्थिति, और समाधान उदाहरण के लिए एक लिंक मिलेगा (निम्न अनुभाग देखें)।
+
+## अपने स्थानीय प्रश्नों को पूर्वावलोकन स्कीमा के विरुद्ध चलाएँ
+
+We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on.
+
+आप उन्हें भेजकर प्रश्नों को आज़मा सकते हैं:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+या
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+उन प्रश्नों पर काम करने के लिए जिन्हें सत्यापन त्रुटियों के रूप में फ़्लैग किया गया है, आप Altair या [GraphiQL](https://cloud.hasura.io/public/graphiql) जैसे अपने पसंदीदा ग्राफ़क्यूएल क्वेरी टूल का उपयोग कर सकते हैं, और अपनी क्वेरी को आज़मा सकते हैं। वे उपकरण आपके चलाने से पहले ही उन त्रुटियों को उनके UI में चिह्नित कर देंगे।
+
+## मुद्दों को कैसे हल करें
+
+नीचे, आपको वे सभी ग्राफ़िकल सत्यापन त्रुटियां मिलेंगी जो आपके मौजूदा ग्राफ़िकल ऑपरेशंस पर हो सकती हैं।
+
+### ग्राफक्यूएल चर, संचालन, टुकड़े या तर्क अद्वितीय होने चाहिए
+
+हमने यह सुनिश्चित करने के लिए नियम लागू किए हैं कि एक ऑपरेशन में ग्राफक्यूएल चर, संचालन, टुकड़े और तर्कों का एक अनूठा सेट शामिल है।
+
+एक ग्राफकॉल ऑपरेशन तभी मान्य होता है जब उसमें कोई अस्पष्टता न हो।
+
+इसे प्राप्त करने के लिए, हमें यह सुनिश्चित करने की आवश्यकता है कि आपके ग्राफकॉल ऑपरेशन में कुछ घटक अद्वितीय होने चाहिए।
+
+इन नियमों का उल्लंघन करने वाली कुछ अमान्य कार्रवाइयों का उदाहरण यहां दिया गया है:
+
+**Duplicate Query name (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Or name the two queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### ओवरलैपिंग फील्ड्स
+
+एक ग्राफक्यूएल चयन सेट को तभी वैध माना जाता है जब वह अंतिम परिणाम सेट को सही ढंग से हल करता है।
+
+यदि कोई विशिष्ट चयन सेट, या कोई फ़ील्ड, चयनित फ़ील्ड या उपयोग किए गए तर्कों द्वारा अस्पष्टता बनाता है, तो ग्राफ़कॉल सेवा ऑपरेशन को मान्य करने में विफल हो जाएगी।
+
+इस नियम का उल्लंघन करने वाली अमान्य कार्रवाइयों के कुछ उदाहरण यहां दिए गए हैं:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+साथ ही, अधिक जटिल उपयोग-मामले में, आप दो टुकड़ों का उपयोग करके इस नियम का उल्लंघन कर सकते हैं जो अंततः अपेक्षित सेट में विरोध का कारण बन सकता है:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[एल्गोरिथ्म के बारे में आप यहां और पढ़ सकते हैं।](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### अप्रयुक्त चर या टुकड़े
+
+एक ग्राफक्यूएल ऑपरेशन को भी केवल तभी वैध माना जाता है जब सभी ऑपरेशन-परिभाषित घटकों (चर, टुकड़े) का उपयोग किया जाता है।
+
+इन नियमों का उल्लंघन करने वाले ग्राफ़िकल ऑपरेशंस के कुछ उदाहरण यहां दिए गए हैं:
+
+**Unused variable** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+No translations matched your search
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Invalid or missing Selection-Set (#ScalarLeafsRule)
+
+इसके अलावा, एक ग्राफक्यूएल फ़ील्ड चयन केवल तभी मान्य होता है जब निम्नलिखित मान्य हो:
+
+- ऑब्जेक्ट फ़ील्ड में चयन सेट निर्दिष्ट होना चाहिए।
+- एक एज फ़ील्ड (स्केलर, एनम) में निर्दिष्ट चयन सेट नहीं होना चाहिए।
+
+निम्नलिखित स्कीमा के साथ इन नियमों के उल्लंघन के कुछ उदाहरण यहां दिए गए हैं:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Incorrect Arguments values (#VariablesInAllowedPositionRule)
+
+स्कीमा में परिभाषित मान के आधार पर तर्कों के लिए हार्ड-कोडेड मानों को पास करने वाले ग्राफ़िकल ऑपरेशंस को मान्य होना चाहिए।
+
+यहां इन नियमों का उल्लंघन करने वाली अमान्य कार्रवाइयों के कुछ उदाहरण दिए गए हैं:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Unknown Type, Variable, Fragment, or Directive (#UnknownX)
+
+यदि किसी अज्ञात प्रकार, चर, खंड या निर्देश का उपयोग किया जाता है, तो ग्राफकलाइन एपीआई एक त्रुटि उत्पन्न करेगा।
+
+उन अज्ञात संदर्भों को ठीक किया जाना चाहिए:
+
+- नाम बदलें अगर यह एक टाइपो था
+- अन्यथा हटा दें
+
+### फ़्रैगमेंट: अमान्य फैलाव या परिभाषा
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+
+एक फ़्रैगमेंट को गैर-लागू प्रकार पर नहीं फैलाया जा सकता है।
+
+Example, we cannot apply a `Cat` fragment to the `Dog` type:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)**
+
+सभी फ़्रैगमेंट को परिभाषित किया जाना चाहिए (`on ...` का उपयोग करके) एक समग्र प्रकार, संक्षेप में: ऑब्जेक्ट, इंटरफ़ेस, या यूनियन।
+
+निम्नलिखित उदाहरण अमान्य हैं, क्योंकि स्केलर्स पर अंशों को परिभाषित करना अमान्य है।
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Directives usage
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+
+Only GraphQL directives (`@...`) supported by The Graph API can be used.
+
+यहाँ द ग्राफक्यूएल समर्थित निर्देशों के साथ एक उदाहरण दिया गया है:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` are not supported._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+
+ग्राफ़ द्वारा समर्थित निर्देश प्रति स्थान केवल एक बार उपयोग किए जा सकते हैं।
+
+The following is invalid (and redundant):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 578f6a231b54e41d273c68ca1394d3aa88773270 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:42 -0500
Subject: [PATCH 1307/3820] New translations
 graphql-validations-migration-guide.mdx (Swahili)

---
 .../graphql-validations-migration-guide.mdx   | 538 ++++++++++++++++++
 1 file changed, 538 insertions(+)
 create mode 100644 website/pages/sw/resources/release-notes/graphql-validations-migration-guide.mdx

diff --git a/website/pages/sw/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/sw/resources/release-notes/graphql-validations-migration-guide.mdx
new file mode 100644
index 000000000000..4d909e8970a8
--- /dev/null
+++ b/website/pages/sw/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -0,0 +1,538 @@
+---
+title: GraphQL Validations migration guide
+---
+
+Soon `graph-node` will support 100% coverage of the [GraphQL Validations specification](https://spec.graphql.org/June2018/#sec-Validation).
+
+Previous versions of `graph-node` did not support all validations and provided more graceful responses - so, in cases of ambiguity, `graph-node` was ignoring invalid GraphQL operations components.
+
+GraphQL Validations support is the pillar for the upcoming new features and the performance at scale of The Graph Network.
+
+It will also ensure determinism of query responses, a key requirement on The Graph Network.
+
+**Enabling the GraphQL Validations will break some existing queries** sent to The Graph API.
+
+To be compliant with those validations, please follow the migration guide.
+
+> ⚠️ If you do not migrate your queries before the validations are rolled out, they will return errors and possibly break your frontends/clients.
+
+## Migration guide
+
+You can use the CLI migration tool to find any issues in your GraphQL operations and fix them. Alternatively you can update the endpoint of your GraphQL client to use the `https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME` endpoint. Testing your queries against this endpoint will help you find the issues in your queries.
+
+> Not all subgraphs will need to be migrated, if you are using [GraphQL ESlint](https://the-guild.dev/graphql/eslint/docs) or [GraphQL Code Generator](https://the-guild.dev/graphql/codegen), they already ensure that your queries are valid.
+
+## Migration CLI tool
+
+**Most of the GraphQL operations errors can be found in your codebase ahead of time.**
+
+For this reason, we provide a smooth experience for validating your GraphQL operations during development or in CI.
+
+[`@graphql-validate/cli`](https://github.com/saihaj/graphql-validate) is a simple CLI tool that helps validate GraphQL operations against a given schema.
+
+### **Getting started**
+
+You can run the tool as follows:
+
+```bash
+npx @graphql-validate/cli -s https://api-next.thegraph.com/subgraphs/name/$GITHUB_USER/$SUBGRAPH_NAME -o *.graphql
+```
+
+**Notes:**
+
+- Set or replace $GITHUB_USER, $SUBGRAPH_NAME with the appropriate values. Like: [`artblocks/art-blocks`](https://api.thegraph.com/subgraphs/name/artblocks/art-blocks)
+- The preview schema URL (https://api-next.thegraph.com/) provided is heavily rate-limited and will be sunset once all users have migrated to the new version. **Do not use it in production.**
+- Operations are identified in files with the following extensions [`.graphql`,](https://www.graphql-tools.com/docs/schema-loading#graphql-file-loader)[`.ts`, `.tsx`, `.js`, `jsx`](https://www.graphql-tools.com/docs/schema-loading#code-file-loader) (`-o` option).
+
+### CLI output
+
+The `[@graphql-validate/cli](https://github.com/saihaj/graphql-validate)` CLI tool will output any GraphQL operations errors as follows:
+
+![Error output from CLI](https://i.imgur.com/x1cBdhq.png)
+
+For each error, you will find a description, file path and position, and a link to a solution example (see the following section).
+
+## Run your local queries against the preview schema
+
+We provide an endpoint `https://api-next.thegraph.com/` that runs a `graph-node` version that has validations turned on.
+
+You can try out queries by sending them to:
+
+- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+
+or
+
+- `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
+
+To work on queries that have been flagged as having validation errors, you can use your favorite GraphQL query tool, like Altair or [GraphiQL](https://cloud.hasura.io/public/graphiql), and try your query out. Those tools will also mark those errors in their UI, even before you run it.
+
+## How to solve issues
+
+Below, you will find all the GraphQL validations errors that could occur on your existing GraphQL operations.
+
+### GraphQL variables, operations, fragments, or arguments must be unique
+
+We applied rules for ensuring that an operation includes a unique set of GraphQL variables, operations, fragments, and arguments.
+
+A GraphQL operation is only valid if it does not contain any ambiguity.
+
+To achieve that, we need to ensure that some components in your GraphQL operation must be unique.
+
+Here's an example of a few invalid operations that violates these rules:
+
+**Duplicate Query name (#UniqueOperationNamesRule)**
+
+```graphql
+# The following operation violated the UniqueOperationName
+# rule, since we have a single operation with 2 queries
+# with the same name
+query myData {
+  id
+}
+
+query myData {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+}
+
+query myData2 {
+  # rename the second query
+  name
+}
+```
+
+**Duplicate Fragment name (#UniqueFragmentNamesRule)**
+
+```graphql
+# The following operation violated the UniqueFragmentName
+# rule.
+query myData {
+  id
+  ...MyFields
+}
+
+fragment MyFields {
+  metadata
+}
+
+fragment MyFields {
+  name
+}
+```
+
+_Solution:_
+
+```graphql
+query myData {
+  id
+  ...MyFieldsName
+  ...MyFieldsMetadata
+}
+
+fragment MyFieldsMetadata { # assign a unique name to fragment
+  metadata
+}
+
+fragment MyFieldsName { # assign a unique name to fragment
+  name
+}
+```
+
+**Duplicate variable name (#UniqueVariableNamesRule)**
+
+```graphql
+# The following operation violates the UniqueVariables
+query myData($id: String, $id: Int) {
+  id
+  ...MyFields
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: String) {
+  # keep the relevant variable (here: `$id: String`)
+  id
+  ...MyFields
+}
+```
+
+**Duplicate argument name (#UniqueArgument)**
+
+```graphql
+# The following operation violated the UniqueArguments
+query myData($id: ID!) {
+  userById(id: $id, id: "1") {
+    id
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query myData($id: ID!) {
+  userById(id: $id) {
+    id
+  }
+}
+```
+
+**Duplicate anonymous query (#LoneAnonymousOperationRule)**
+
+Also, using two anonymous operations will violate the `LoneAnonymousOperation` rule due to conflict in the response structure:
+
+```graphql
+# This will fail if executed together in
+# a single operation with the following two queries:
+query {
+  someField
+}
+
+query {
+  otherField
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  someField
+  otherField
+}
+```
+
+Or name the two queries:
+
+```graphql
+query FirstQuery {
+  someField
+}
+
+query SecondQuery {
+  otherField
+}
+```
+
+### Overlapping Fields
+
+A GraphQL selection set is considered valid only if it correctly resolves the eventual result set.
+
+If a specific selection set, or a field, creates ambiguity either by the selected field or by the arguments used, the GraphQL service will fail to validate the operation.
+
+Here are a few examples of invalid operations that violate this rule:
+
+**Conflicting fields aliases (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Aliasing fields might cause conflicts, either with
+# other aliases or other fields that exist on the
+# GraphQL schema.
+query {
+  dogs {
+    name: nickname
+    name
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    name: nickname
+    originalName: name # alias the original `name` field
+  }
+}
+```
+
+**Conflicting fields with arguments (#OverlappingFieldsCanBeMergedRule)**
+
+```graphql
+# Different arguments might lead to different data,
+# so we can't assume the fields will be the same.
+query {
+  dogs {
+    doesKnowCommand(dogCommand: SIT)
+    doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  dogs {
+    knowsHowToSit: doesKnowCommand(dogCommand: SIT)
+    knowsHowToHeel: doesKnowCommand(dogCommand: HEEL)
+  }
+}
+```
+
+Also, in more complex use-cases, you might violate this rule by using two fragments that might cause a conflict in the eventually expected set:
+
+```graphql
+query {
+  # Eventually, we have two "x" definitions, pointing
+  # to different fields!
+  ...A
+  ...B
+}
+
+fragment A on Type {
+  x: a
+}
+
+fragment B on Type {
+  x: b
+}
+```
+
+In addition to that, client-side GraphQL directives like `@skip` and `@include` might lead to ambiguity, for example:
+
+```graphql
+fragment mergeSameFieldsWithSameDirectives on Dog {
+  name @include(if: true)
+  name @include(if: false)
+}
+```
+
+[You can read more about the algorithm here.](https://spec.graphql.org/June2018/#sec-Field-Selection-Merging)
+
+### Unused Variables or Fragments
+
+A GraphQL operation is also considered valid only if all operation-defined components (variables, fragments) are used.
+
+Here are a few examples for GraphQL operations that violates these rules:
+
+**Unused variable** (#NoUnusedVariablesRule)
+
+```graphql
+# Invalid, because $someVar is never used.
+query something($someVar: String) {
+  someData
+}
+```
+
+_Solution:_
+
+```graphql
+query something {
+  someData
+}
+```
+
+**Unused Fragment** (#NoUnusedFragmentsRule)
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+fragment AllFields { # unused :(
+  name
+  age
+}
+```
+
+_Solution:_
+
+```graphql
+# Invalid, because fragment AllFields is never used.
+query something {
+  someData
+}
+
+# remove the `AllFields` fragment
+```
+
+### Invalid or missing Selection-Set (#ScalarLeafsRule)
+
+Also, a GraphQL field selection is only valid if the following is validated:
+
+- An object field must-have selection set specified.
+- An edge field (scalar, enum) must not have a selection set specified.
+
+Here are a few examples of violations of these rules with the following Schema:
+
+```graphql
+type Image {
+  url: String!
+}
+
+type User {
+  id: ID!
+  avatar: Image!
+}
+
+type Query {
+  user: User!
+}
+```
+
+**Invalid Selection-Set**
+
+```graphql
+query {
+  user {
+    id { # Invalid, because "id" is of type ID and does not have sub-fields
+
+    }
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+  }
+}
+```
+
+**Missing Selection-Set**
+
+```graphql
+query {
+  user {
+    id
+    image # `image` requires a Selection-Set for sub-fields!
+  }
+}
+```
+
+_Solution:_
+
+```graphql
+query {
+  user {
+    id
+    image {
+      src
+    }
+  }
+}
+```
+
+### Incorrect Arguments values (#VariablesInAllowedPositionRule)
+
+GraphQL operations that pass hard-coded values to arguments must be valid, based on the value defined in the schema.
+
+Here are a few examples of invalid operations that violate these rules:
+
+```graphql
+query purposes {
+  # If "name" is defined as "String" in the schema,
+  # this query will fail during validation.
+  purpose(name: 1) {
+    id
+  }
+}
+
+# This might also happen when an incorrect variable is defined:
+
+query purposes($name: Int!) {
+  # If "name" is defined as `String` in the schema,
+  # this query will fail during validation, because the
+  # variable used is of type `Int`
+  purpose(name: $name) {
+    id
+  }
+}
+```
+
+### Unknown Type, Variable, Fragment, or Directive (#UnknownX)
+
+The GraphQL API will raise an error if any unknown type, variable, fragment, or directive is used.
+
+Those unknown references must be fixed:
+
+- rename if it was a typo
+- otherwise, remove
+
+### Fragment: invalid spread or definition
+
+**Invalid Fragment spread (#PossibleFragmentSpreadsRule)**
+
+A Fragment cannot be spread on a non-applicable type.
+
+Example, we cannot apply a `Cat` fragment to the `Dog` type:
+
+```graphql
+query {
+	dog {
+		...CatSimple
+  }
+}
+
+fragment CatSimple on Cat {
+  # ...
+}
+```
+
+**Invalid Fragment definition (#FragmentsOnCompositeTypesRule)**
+
+All Fragment must be defined upon (using `on ...`) a composite type, in short: object, interface, or union.
+
+The following examples are invalid, since defining fragments on scalars is invalid.
+
+```graphql
+fragment fragOnScalar on Int {
+  # we cannot define a fragment upon a scalar (`Int`)
+  something
+}
+
+fragment inlineFragOnScalar on Dog {
+  ... on Boolean {
+    # `Boolean` is not a subtype of `Dog`
+    somethingElse
+  }
+}
+```
+
+### Directives usage
+
+**Directive cannot be used at this location (#KnownDirectivesRule)**
+
+Only GraphQL directives (`@...`) supported by The Graph API can be used.
+
+Here is an example with The GraphQL supported directives:
+
+```graphql
+query {
+  dog {
+    name @include(true)
+    age @skip(true)
+  }
+}
+```
+
+_Note: `@stream`, `@live`, `@defer` are not supported._
+
+**Directive can only be used once at this location (#UniqueDirectivesPerLocationRule)**
+
+The directives supported by The Graph can only be used once per location.
+
+The following is invalid (and redundant):
+
+```graphql
+query {
+  dog {
+    name @include(true) @include(true)
+  }
+}
+```

From 8f6b613edc35cdc467d19dc9ef436895bb9ed517 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:43 -0500
Subject: [PATCH 1308/3820] New translations curating.mdx (Romanian)

---
 website/pages/ro/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/ro/resources/roles/curating.mdx

diff --git a/website/pages/ro/resources/roles/curating.mdx b/website/pages/ro/resources/roles/curating.mdx
new file mode 100644
index 000000000000..8e6416b6d57e
--- /dev/null
+++ b/website/pages/ro/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curating
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## How to Signal
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+A curator can choose to signal on a specific subgraph version, or they can choose to have their signal automatically migrate to the newest production build of that subgraph. Both are valid strategies and come with their own pros and cons.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Risks
+
+1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
+   - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Curation FAQs
+
+### 1. What % of query fees do Curators earn?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. How do I decide which subgraphs are high quality to signal on?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. What’s the cost of updating a subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. How often can I update my subgraph?
+
+It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+
+### 5. Can I sell my curation shares?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Still confused? Check out our Curation video guide below:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 795929b2e7cc961b808cc8c378d7cb22d907f854 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:44 -0500
Subject: [PATCH 1309/3820] New translations curating.mdx (French)

---
 website/pages/fr/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/fr/resources/roles/curating.mdx

diff --git a/website/pages/fr/resources/roles/curating.mdx b/website/pages/fr/resources/roles/curating.mdx
new file mode 100644
index 000000000000..bd3b64ba0d3e
--- /dev/null
+++ b/website/pages/fr/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curation
+---
+
+Les Curateurs jouent un rôle essentiel dans l'économie décentralisée de The Graph. Ils utilisent leur connaissance de l'écosystème web3 pour évaluer et signaler les subgraphs qui devraient être indexés par The Graph Network. à travers Graph Explorer, les Curateurs consultent les données du réseau pour prendre des décisions de signalisation. En retour, The Graph Network récompense les Curateurs qui signalent des subgraphs de bonne qualité en leur reversant une partie des frais de recherche générés par ces subgraphs. La quantité de GRT signalée est l'une des principales considérations des Indexeurs lorsqu'ils déterminent les subgraphs à indexer.
+
+## Que signifie "le signalement" pour The Graph Network?
+
+Avant que les consommateurs ne puissent interroger un subgraphs, celui-ci doit être indexé. C'est ici que la curation entre en jeu. Afin que les Indexeurs puissent gagner des frais de requête substantiels sur des subgraphs de qualité, ils doivent savoir quels subgraphs indexer. Lorsque les Curateurs signalent un subgraphs , ils indiquent aux Indexeurs qu'un subgraphs est demandé et de qualité suffisante pour être indexé.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Les signaux des Curateurs sont représentés par des jetons ERC20 appelés Graph Curation Shares (GCS). Ceux qui veulent gagner plus de frais de requête doivent signaler leurs GRT aux subgraphs qui, selon eux, généreront un flux important de frais pour le réseau. Les Curateurs ne peuvent pas être réduits pour mauvais comportement, mais il y a une taxe de dépôt sur les Curateurs pour dissuader les mauvaises décisions pouvant nuire à l'intégrité du réseau. Les Curateurs gagneront également moins de frais de requête s'ils sélectionnent un subgraph de mauvaise qualité car il y aura moins de requêtes à traiter ou moins d'Indexeurs pour les traiter.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+Lors du signalement, les Curateurs peuvent décider de signaler une version spécifique du subgraph ou de signaler en utilisant l'auto-migration. S'ils signalent en utilisant l'auto-migration, les parts d'un Curateur seront toujours mises à jour vers la dernière version publiée par le développeur. S'ils décident de signaler une version spécifique, les parts resteront toujours sur cette version spécifique.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Les Indexeurs peuvent trouver des subgraphs à indexer en fonction des signaux de curation qu'ils voient dans Graph Explorer (capture d'écran ci-dessous).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## Comment signaler
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+Un curateur peut choisir de signaler une version spécifique d'un sugraph ou de faire migrer automatiquement son signal vers la version de production la plus récente de ce subgraph. Ces deux stratégies sont valables et comportent leurs propres avantages et inconvénients.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+La migration automatique de votre signal vers la version de production la plus récente peut s'avérer utile pour vous assurer que vous continuez à accumuler des frais de requête. Chaque fois que vous effectuez une curation, une taxe de curation de 1 % est appliquée. Vous paierez également une taxe de curation de 0,5 % à chaque migration. Les développeurs de subgraphs sont découragés de publier fréquemment de nouvelles versions - ils doivent payer une taxe de curation de 0,5 % sur toutes les parts de curation migrées automatiquement.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Retrait de vos GRT
+
+Les Curateurs ont la possibilité de retirer leur GRT signalé à tout moment.
+
+Contrairement au processus de délégation, si vous décidez de retirer vos GRT signalés, vous n'aurez pas un délai d'attente et vous recevrez le montant total (moins la taxe de curation de 1%).
+
+Une fois qu'un Curateur retire ses signaux, les Indexeurs peuvent choisir de continuer à indexer le subgraph, même s'il n'y a actuellement aucun GRT signalé actif.
+
+Cependant, il est recommandé que les Curateurs laissent leur GRT signalé en place non seulement pour recevoir une partie des frais de requête, mais aussi pour assurer la fiabilité et la disponibilité du subgraph.
+
+## Risques
+
+1. Le marché des requêtes est intrinsèquement jeune chez The Graph et il y a un risque que votre %APY soit inférieur à vos attentes en raison de la dynamique naissante du marché.
+2. Frais de curation - lorsqu'un Curateur signale des GRT sur un subgraph, il doit s'acquitter d'une taxe de curation de 1%. Cette taxe est brûlée.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. Un subgraph peut échouer à cause d'un bug. Un subgraph qui échoue n'accumule pas de frais de requête. Par conséquent, vous devrez attendre que le développeur corrige le bogue et déploie une nouvelle version.
+   - Si vous êtes abonné à la version la plus récente d'un subgraph, vos parts migreront automatiquement vers cette nouvelle version. Cela entraînera une taxe de curation de 0,5 %.
+   - Si vous avez signalé sur une version spécifique d'un subgraph et qu'elle échoue, vous devrez brûler manuellement vos parts de curation. Vous pouvez alors signaler sur la nouvelle version du subgraph, encourant ainsi une taxe de curation de 1%.
+
+## FAQs sur la Curation
+
+### 1. Quel pourcentage des frais de requête les Curateurs perçoivent-ils?
+
+En signalant sur un subgraph, vous gagnerez une part de tous les frais de requête générés par le subgraph. 10% de tous les frais de requête vont aux Curateurs au prorata de leurs parts de curation. Ces 10% sont soumis à la gouvernance.
+
+### 2. Comment décider quels sont les subgraphs de haute qualité sur lesquels on peut émettre un signal ?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Les Curateurs peuvent utiliser leur compréhension d'un réseau pour essayer de prédire comment un subgraph individuel peut générer un volume de requêtes plus élevé ou plus faible à l'avenir
+- Les Curateurs doivent également comprendre les métriques disponibles via Graph Explorer. Des métriques telles que le volume de requêtes passées et l'identité du développeur du subgraph peuvent aider à déterminer si un subgraph mérite ou non d'être signalé.
+
+### 3. Quel est le coût de la mise à jour d'un subgraph ?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. À quelle fréquence puis-je mettre à jour mon subgraph ?
+
+Il est conseillé de ne pas mettre à jour vos subgraphs trop fréquemment. Voir la question ci-dessus pour plus de détails.
+
+### 5. Puis-je vendre mes parts de curateurs ?
+
+Les parts de curation ne peuvent pas être "achetées" ou "vendues" comme d'autres jetons ERC20 que vous pourriez connaître. Elles ne peuvent être que mintée (créees) ou brûlées (détruites).
+
+En tant que Curateur sur Arbitrum, vous êtes assuré de récupérer les GRT que vous avez initialement déposé (moins la taxe).
+
+### 6. Suis-je éligible à une subvention de curation?
+
+Les subventions de curation sont déterminées individuellement au cas par cas. Si vous avez besoin d'assistance avec la curation, veuillez envoyer une demande à l'adresse support@thegraph.zendesk.com.
+
+Vous ne savez toujours pas où vous en êtes ? Regardez notre guide vidéo sur la curation ci-dessous :
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 37352e41f161551d6b2e0b9fd9e6c63c858791fb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:45 -0500
Subject: [PATCH 1310/3820] New translations curating.mdx (Spanish)

---
 website/pages/es/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/es/resources/roles/curating.mdx

diff --git a/website/pages/es/resources/roles/curating.mdx b/website/pages/es/resources/roles/curating.mdx
new file mode 100644
index 000000000000..892d9ee4d4b2
--- /dev/null
+++ b/website/pages/es/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curación
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## Cómo señalar
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+Un curador puede optar por señalar una versión especifica de un subgrafo, o puede optar por que su señal migre automáticamente a la versión de producción mas reciente de ese subgrafo. Ambas son estrategias válidas y tienen sus pros y sus contras.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Hacer que tu señal migre automáticamente a la más reciente compilación de producción puede ser valioso para asegurarse de seguir acumulando tarifas de consulta. Cada vez que curas, se incurre en un impuesto de curación del 1%. También pagarás un impuesto de curación del 0,5% en cada migración. Se desaconseja a los desarrolladores de Subgrafos que publiquen con frecuencia nuevas versiones - tienen que pagar un impuesto de curación del 0,5% en todas las acciones de curación auto-migradas.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Riesgos
+
+1. El mercado de consultas es inherentemente joven en The Graph y existe el riesgo de que su APY (Rentabilidad anualizada) sea más bajo de lo esperado debido a la dinámica del mercado que recién está empezando.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. Un subgrafo puede fallar debido a un error. Un subgrafo fallido no acumula tarifas de consulta. Como resultado, tendrás que esperar hasta que el desarrollador corrija el error e implemente una nueva versión.
+   - Si estás suscrito a la versión más reciente de un subgrafo, tus acciones se migrarán automáticamente a esa nueva versión. Esto incurrirá un impuesto de curación del 0.5%.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Preguntas frecuentes sobre Curación
+
+### 1. ¿Qué porcentaje de las tasas de consulta ganan los curadores?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. ¿Cómo decido qué subgrafos son de alta calidad para señalar?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. What’s the cost of updating a subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. How often can I update my subgraph?
+
+It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+
+### 5. ¿Puedo vender mis acciones de curación?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+¿Sigues confundido? Te invitamos a echarle un vistazo a nuestra guía en un vídeo que aborda todo sobre la curación:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From f3046b9c151c7b79c8bfcf2a1e0154d30f60a439 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:46 -0500
Subject: [PATCH 1311/3820] New translations curating.mdx (Arabic)

---
 website/pages/ar/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/ar/resources/roles/curating.mdx

diff --git a/website/pages/ar/resources/roles/curating.mdx b/website/pages/ar/resources/roles/curating.mdx
new file mode 100644
index 000000000000..148a5fcf8f93
--- /dev/null
+++ b/website/pages/ar/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curating
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## كيفية الإشارة
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+يمكن للمنسق الإشارة إلى إصدار معين ل subgraph ، أو يمكنه اختيار أن يتم ترحيل migrate إشاراتهم تلقائيا إلى أحدث إصدار لهذا ال subgraph. كلاهما استراتيجيات سليمة ولها إيجابيات وسلبيات.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## المخاطر
+
+1. سوق الاستعلام يعتبر حديثا في The Graph وهناك خطر من أن يكون٪ APY الخاص بك أقل مما تتوقع بسبب ديناميكيات السوق الناشئة.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. يمكن أن يفشل ال subgraph بسبب خطأ. ال subgraph الفاشل لا يمكنه إنشاء رسوم استعلام. نتيجة لذلك ، سيتعين عليك الانتظار حتى يصلح المطور الخطأ وينشر إصدارا جديدا.
+   - إذا كنت مشتركا في أحدث إصدار من subgraph ، فسيتم ترحيل migrate أسهمك تلقائيا إلى هذا الإصدار الجديد. هذا سيتحمل ضريبة تنسيق بنسبة 0.5٪.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## الأسئلة الشائعة حول التنسيق
+
+### 1. ما هي النسبة المئوية لرسوم الاستعلام التي يكسبها المنسقون؟
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. كيف يمكنني تقرير ما إذا كان ال subgraph عالي الجودة لكي أقوم بالإشارة إليه؟
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. What’s the cost of updating a subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. How often can I update my subgraph?
+
+It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+
+### 5. هل يمكنني بيع أسهم التنسيق الخاصة بي؟
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+لازلت مشوشا؟ راجع فيديو دليل التنسيق أدناه:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 30cdd773567ea6d1b46cf8d00bfac7cd70b45995 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:47 -0500
Subject: [PATCH 1312/3820] New translations curating.mdx (Czech)

---
 website/pages/cs/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/cs/resources/roles/curating.mdx

diff --git a/website/pages/cs/resources/roles/curating.mdx b/website/pages/cs/resources/roles/curating.mdx
new file mode 100644
index 000000000000..b66ccf5669ff
--- /dev/null
+++ b/website/pages/cs/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Kurátorování
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## Jak signalizovat
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+Kurátor si může zvolit, zda bude signalizovat na konkrétní verzi podgrafu, nebo zda se jeho signál automaticky přenese na nejnovější produkční sestavení daného podgrafu. Obě strategie jsou platné a mají své výhody i nevýhody.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Automatická migrace signálu na nejnovější produkční sestavení může být cenná, protože zajistí, že se poplatky za dotazy budou neustále zvyšovat. Při každém kurátorství se platí 1% kurátorský poplatek. Při každé migraci také zaplatíte 0,5% kurátorskou daň. Vývojáři podgrafu jsou odrazováni od častého publikování nových verzí - musí zaplatit 0.5% kurátorskou daň ze všech automaticky migrovaných kurátorských podílů.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Rizika
+
+1. Trh s dotazy je v Graf ze své podstaty mladý a existuje riziko, že vaše %APY může být nižší, než očekáváte, v důsledku dynamiky rodícího se trhu.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. Podgraf může selhat kvůli chybě. Za neúspěšný podgraf se neúčtují poplatky za dotaz. V důsledku toho budete muset počkat, až vývojář chybu opraví a nasadí novou verzi.
+   - Pokud jste přihlášeni k odběru nejnovější verze podgrafu, vaše sdílené položky se automaticky přemigrují na tuto novou verzi. Při tom bude účtována 0,5% kurátorská daň.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Nejčastější dotazy ke kurátorství
+
+### 1. Kolik % z poplatků za dotazy kurátoři vydělávají?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. Jak se rozhodnu, které podgrafy jsou kvalitní a na kterých je třeba signalizovat?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. Jaké jsou náklady na aktualizaci podgrafu?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. Jak často mohu svůj podgraf aktualizovat?
+
+Doporučujeme, abyste podgrafy neaktualizovali příliš často. Další podrobnosti naleznete v otázce výše.
+
+### 5. Mohu prodat své kurátorské podíly?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Stále jste zmateni? Podívejte se na našeho videoprůvodce kurátorstvím níže
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 89e80ef7594503bf28fa6c066807b373fb3e10a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:48 -0500
Subject: [PATCH 1313/3820] New translations curating.mdx (German)

---
 website/pages/de/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/de/resources/roles/curating.mdx

diff --git a/website/pages/de/resources/roles/curating.mdx b/website/pages/de/resources/roles/curating.mdx
new file mode 100644
index 000000000000..8e6416b6d57e
--- /dev/null
+++ b/website/pages/de/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curating
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## How to Signal
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+A curator can choose to signal on a specific subgraph version, or they can choose to have their signal automatically migrate to the newest production build of that subgraph. Both are valid strategies and come with their own pros and cons.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Risks
+
+1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
+   - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Curation FAQs
+
+### 1. What % of query fees do Curators earn?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. How do I decide which subgraphs are high quality to signal on?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. What’s the cost of updating a subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. How often can I update my subgraph?
+
+It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+
+### 5. Can I sell my curation shares?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Still confused? Check out our Curation video guide below:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 8c695f54b46c7e200a64e804649d1232f86246ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:49 -0500
Subject: [PATCH 1314/3820] New translations curating.mdx (Italian)

---
 website/pages/it/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/it/resources/roles/curating.mdx

diff --git a/website/pages/it/resources/roles/curating.mdx b/website/pages/it/resources/roles/curating.mdx
new file mode 100644
index 000000000000..14cb8ca81f89
--- /dev/null
+++ b/website/pages/it/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curating
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## Come segnalare
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+Un curator può scegliere di segnalare su una versione specifica del subgraph, oppure può scegliere di far migrare automaticamente il proprio segnale alla versione di produzione più recente di quel subgraph. Entrambe le strategie sono valide e hanno i loro pro e contro.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+La migrazione automatica del segnale alla più recente versione di produzione può essere utile per garantire l'accumulo di tariffe di query. Ogni volta che si effettua una curation, si paga una tassa di curation del 1%. Si pagherà anche una tassa di curation del 0,5% per ogni migrazione. Gli sviluppatori di subgraph sono scoraggiati dal pubblicare frequentemente nuove versioni: devono pagare una tassa di curation del 0,5% su tutte le quote di curation auto-migrate.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Rischi
+
+1. Il mercato delle query è intrinsecamente giovane per The Graph e c'è il rischio che la vostra %APY possa essere inferiore a quella prevista a causa delle dinamiche di mercato nascenti.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. Un subgraph può fallire a causa di un bug. Un subgraph fallito non matura commissioni della query. Di conseguenza, si dovrà attendere che lo sviluppatore risolva il bug e distribuisca una nuova versione.
+   - Se siete iscritti alla versione più recente di un subgraph, le vostre quote di partecipazione migreranno automaticamente a quella nuova versione. Questo comporta una tassa di curation di 0,5%.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## FAQ sulla curation
+
+### 1. Quale % delle tariffe di query guadagnano i curator?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. Come si fa a decidere quali subgraph sono di alta qualità da segnalare?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. Qual è il costo dell'aggiornamento di un subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. Con quale frequenza posso aggiornare il mio subgraph?
+
+Si suggerisce di non aggiornare i subgraph troppo frequentemente. Si veda la domanda precedente per maggiori dettagli.
+
+### 5. Posso vendere le mie quote di curation?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Ancora confusi? Date un'occhiata alla nostra video-guida sulla Curation:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 375ee22de404a17c5d28f8614ea76020c1f0b871 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:50 -0500
Subject: [PATCH 1315/3820] New translations curating.mdx (Japanese)

---
 website/pages/ja/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/ja/resources/roles/curating.mdx

diff --git a/website/pages/ja/resources/roles/curating.mdx b/website/pages/ja/resources/roles/curating.mdx
new file mode 100644
index 000000000000..f0e7b5329cb4
--- /dev/null
+++ b/website/pages/ja/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: キュレーティング
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## シグナルの出し方
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+キュレーターは、特定のサブグラフのバージョンでシグナルを出すことも、そのサブグラフの最新のプロダクションビルドに自動的にシグナルを移行させることも可能ですます。 どちらも有効な戦略であり、それぞれに長所と短所があります。
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+シグナルを最新のプロダクションビルドに自動的に移行させることは、クエリー料金の発生を確実にするために有効です。 キュレーションを行うたびに、1％のキュレーション税が発生します。 また、移行ごとに 0.5%のキュレーション税を支払うことになります。 つまり、サブグラフの開発者が、頻繁に新バージョンを公開することは推奨されません。 自動移行された全てのキュレーションシェアに対して、0.5%のキュレーション税を支払わなければならないからです。
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## リスク
+
+1. The Graph では、クエリ市場は本質的に歴史が浅く、初期の市場ダイナミクスのために、あなたの%APY が予想より低くなるリスクがあります。
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. サブグラフはバグで失敗することがあります。 失敗したサブグラフは、クエリフィーが発生しません。 結果的に、開発者がバグを修正して新しいバージョンを展開するまで待たなければならなくなります。
+   - サブグラフの最新バージョンに加入している場合、シェアはその新バージョンに自動移行します。 これには 0.5％のキュレーション税がかかります。
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## キューレーション FAQ
+
+### 1. キュレータはクエリフィーの何％を獲得できますか？
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. シグナルを出すのに適した質の高いサブグラフはどのようにして決めるのですか？
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. サブグラフの更新にかかるコストはいくらですか?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. サブグラフはどれくらいの頻度で更新できますか?
+
+サブグラフをあまり頻繁に更新しないことをお勧めします。詳細については、上記の質問を参照してください。
+
+### 5. キュレーションのシェアを売却することはできますか？
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+まだ不明点がありますか？ その他の不明点に関しては、 以下のキュレーションビデオガイドをご覧ください：
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 742041474616ae6eda59b873c6d55d1832683202 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:52 -0500
Subject: [PATCH 1316/3820] New translations curating.mdx (Korean)

---
 website/pages/ko/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/ko/resources/roles/curating.mdx

diff --git a/website/pages/ko/resources/roles/curating.mdx b/website/pages/ko/resources/roles/curating.mdx
new file mode 100644
index 000000000000..8e6416b6d57e
--- /dev/null
+++ b/website/pages/ko/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curating
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## How to Signal
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+A curator can choose to signal on a specific subgraph version, or they can choose to have their signal automatically migrate to the newest production build of that subgraph. Both are valid strategies and come with their own pros and cons.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Risks
+
+1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
+   - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Curation FAQs
+
+### 1. What % of query fees do Curators earn?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. How do I decide which subgraphs are high quality to signal on?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. What’s the cost of updating a subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. How often can I update my subgraph?
+
+It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+
+### 5. Can I sell my curation shares?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Still confused? Check out our Curation video guide below:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 1aa0fe693e7e38cfc6d98accacea953e2419686a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:53 -0500
Subject: [PATCH 1317/3820] New translations curating.mdx (Dutch)

---
 website/pages/nl/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/nl/resources/roles/curating.mdx

diff --git a/website/pages/nl/resources/roles/curating.mdx b/website/pages/nl/resources/roles/curating.mdx
new file mode 100644
index 000000000000..e7e30125d8d5
--- /dev/null
+++ b/website/pages/nl/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Cureren
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## Hoe werkt het Signaleren
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+Een curator kan ervoor kiezen om een signaal af te geven voor een specifieke subgraph versie, of ze kunnen ervoor kiezen om hun signaal automatisch te laten migreren naar de nieuwste versie van de subgraph. Beide strategieën hebben voordelen en nadelen.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Automatische migratie van je signalering naar de nieuwste subgraphversie kan waardevol zijn om ervoor te zorgen dat je querykosten blijft ontvangen. Elke keer dat je signaleert, wordt een curatiebelasting van 1% in rekening gebracht. Je betaalt ook een curatiebelasting van 0,5% bij elke migratie. Subgraphontwikkelaars worden ontmoedigd om vaak nieuwe versies te publiceren - ze moeten een curatiebelasting van 0,5% betalen voor alle automatisch gemigreerde curatie-aandelen.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Risico's
+
+1. De querymarkt is nog jong bij het Graph Netwerk en er bestaat een risico dat je %APY lager kan zijn dan je verwacht door opkomende marktdynamiek.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. Een subgraph kan stuk gaan door een bug. Een subgraph die stuk is gegenereerd geen querykosten. Als gevolg hiervan moet je wachten tot de ontwikkelaar de bug repareert en een nieuwe versie implementeert.
+   - Als je bent geabonneerd op de nieuwste versie van een subgraph, worden je curatieaandelen automatisch gemigreerd naar die nieuwe versie. Er is een curatiebelasting van 0,5%.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Veelgestelde Vragen over Curatie
+
+### Welk percentage van de querykosten verdienen curatoren?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### Hoe bepaal ik welke subgraphs van hoge kwaliteit zijn om op te signaleren?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### Wat zijn de kosten voor het updaten van een subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### Hoe vaak kan ik mijn subgraph updaten?
+
+Het wordt aanbevolen om je subgraphs niet te vaak bij te werken. Zie de bovenstaande vraag voor meer details.
+
+### Kan ik mijn curatieaandelen verkopen?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Nog in de war? Bekijk onze Curatie videogids hieronder:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From b0a64860e097e9eafeca594fefd3e70ba688ca07 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:54 -0500
Subject: [PATCH 1318/3820] New translations curating.mdx (Polish)

---
 website/pages/pl/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/pl/resources/roles/curating.mdx

diff --git a/website/pages/pl/resources/roles/curating.mdx b/website/pages/pl/resources/roles/curating.mdx
new file mode 100644
index 000000000000..8e6416b6d57e
--- /dev/null
+++ b/website/pages/pl/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curating
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## How to Signal
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+A curator can choose to signal on a specific subgraph version, or they can choose to have their signal automatically migrate to the newest production build of that subgraph. Both are valid strategies and come with their own pros and cons.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Risks
+
+1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
+   - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Curation FAQs
+
+### 1. What % of query fees do Curators earn?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. How do I decide which subgraphs are high quality to signal on?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. What’s the cost of updating a subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. How often can I update my subgraph?
+
+It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+
+### 5. Can I sell my curation shares?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Still confused? Check out our Curation video guide below:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 7b9fef31470cc009b9f33ba12d8c37263feed052 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:55 -0500
Subject: [PATCH 1319/3820] New translations curating.mdx (Portuguese)

---
 website/pages/pt/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/pt/resources/roles/curating.mdx

diff --git a/website/pages/pt/resources/roles/curating.mdx b/website/pages/pt/resources/roles/curating.mdx
new file mode 100644
index 000000000000..80e9b490037f
--- /dev/null
+++ b/website/pages/pt/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curadorias
+---
+
+Curadores são importantes para a economia descentralizada do The Graph. Eles utilizam o seu conhecimento do ecossistema web3 para avaliar e sinalizar nos subgraphs que devem ser indexados pela Graph Network. Através do Graph Explorer, Curadores visualizam dados de rede para tomar decisões sobre sinalizações. Em troca, a Graph Network recompensa Curadores que sinalizam em subgraphs de alta qualidade com uma parte das taxas de query geradas por estes subgraphs. A quantidade de GRT sinalizada é uma das considerações mais importantes para Indexadores ao determinar quais subgraphs indexar.
+
+## O que a Sinalização Significa para a Graph Network?
+
+Antes que consumidores possam indexar um subgraph, ele deve ser indexado. É aqui que entra a curadoria. Para que Indexadores ganhem taxas de query substanciais em subgraphs de qualidade, eles devem saber quais subgraphs indexar. Quando Curadores sinalizam um subgraph, isto diz aos Indexadores que um subgraph está em demanda e tem qualidade suficiente para ser indexado.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Sinais de curador são representados como tokens ERC20 chamados de Ações de Curadoria do Graph (GCS). Quem quiser ganhar mais taxas de query devem sinalizar o seu GRT a subgraphs que apostam que gerará um fluxo forte de taxas á rede. Curadores não podem ser cortados por mau comportamento, mas há uma taxa de depósito em Curadores para desincentivar más decisões que possam ferir a integridade da rede. Curadores também ganharão menos taxas de query se curarem um subgraph de baixa qualidade, já que haverão menos queries a processar ou menos Indexadores para processá-las.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+Ao sinalizar, Curadores podem decidir entre sinalizar numa versão específica do subgraph ou sinalizar com a automigração. Caso sinalizem com a automigração, as ações de um curador sempre serão atualizadas à versão mais recente publicada pelo programador. Se decidirem sinalizar numa versão específica, as ações sempre permanecerão nesta versão específica.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Os indexadores podem achar subgraphs para indexar com base em sinais de curadoria que veem no Graph Explorer (imagem abaixo).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## Como Sinalizar
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+Um curador pode escolher sinalizar uma versão específica de subgraph, ou pode automaticamente migrar o seu sinal à versão mais recente desse subgraph. Ambas estratégias são válidas, e vêm com as suas próprias vantagens e desvantagens.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Ter um sinal que migra automaticamente à build mais recente de um subgraph pode ser bom para garantir o acúmulo de taxas de consulta. Toda vez que cura, é incorrida uma taxa de 1% de curadoria. Também pagará uma taxa de 0.5% em toda migração. É recomendado que rogramadores de subgraphs evitem editar novas versões com frequência - eles devem pagar uma taxa de curadoria de 0.5% em todas as ações de curadoria auto-migradas.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Como Sacar o Seu GRT
+
+Curadores têm a opção de sacar o seu GRT sinalizado a qualquer momento.
+
+Ao contrário do processo de delegação, se decidir sacar o seu GRT sinalizado, você não precisará esperar um período de recarga, e receberá a quantidade completa (menos a taxa de curadoria de 1%).
+
+Quando um curador retira o seu sinal, Indexadores podem escolher continuar a indexar o subgraph, mesmo se não houver no momento nenhum GRT sinalizado.
+
+Porém, é recomendado que curadores deixem o seu GRT no lugar, não apenas para receber uma porção das taxas de query, mas também para garantir a confiança e disponibilidade do subgraph.
+
+## Riscos
+
+1. O mercado de consulta é jovem por natureza no The Graph, e há sempre o risco do seu rendimento anual ser menor que o esperado devido às dinâmicas nascentes do mercado.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. Um subgraph pode falhar devido a um erro de código. Um subgraph falho não acumula taxas de consulta. Portanto, espere até o programador consertar o erro e lançar uma nova versão.
+   - Caso se inscreva à versão mais recente de um subgraph, suas ações migrarão automaticamente a esta versão nova. Isto incorrerá uma taxa de curadoria de 0.5%.
+   - Se sinalizou em um subgraph específico e ele falhou, deverá queimar as suas ações de curadoria manualmente. Será então possível sinalizar na nova versão do subgraph, o que incorre uma taxa de curadoria de 1%.
+
+## Perguntas Frequentes sobre Curadoria
+
+### 1. Qual a % das taxas de query que os Curadores ganham?
+
+Ao sinalizar em um subgraph, ganhará parte de todas as taxas de query geradas pelo subgraph. 10% de todas as taxas de curadoria vão aos Curadores, pro-rata às suas ações de curadoria. Estes 10% são sujeitos à governança.
+
+### 2. Como decidir quais subgraphs são de qualidade alta para sinalizar?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. Qual o custo de atualizar um subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. Com que frequência posso atualizar o meu subgraph?
+
+Não atualize os seus subgraphs com frequência excessiva. Veja a questão acima para mais detalhes.
+
+### 5. Posso vender as minhas ações de curadoria?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+Como um Curador no Arbitrum, é garantido que você receberá o GRT que depositou inicialmente (menos a taxa).
+
+### 6. Tenho direito a uma bolsa de curadoria?
+
+Bolsas de curadoria são determinadas individualmente. Se precisar de ajuda com a curadoria, entre em contacto em support@thegraph.zendesk.com.
+
+Ainda não percebeu? Confira o nosso guia em vídeo sobre a Curadoria abaixo:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From d8115c30280c1ac7e78f8bd64cc3c0b2abb31782 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:56 -0500
Subject: [PATCH 1320/3820] New translations curating.mdx (Russian)

---
 website/pages/ru/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/ru/resources/roles/curating.mdx

diff --git a/website/pages/ru/resources/roles/curating.mdx b/website/pages/ru/resources/roles/curating.mdx
new file mode 100644
index 000000000000..85c4540d96e3
--- /dev/null
+++ b/website/pages/ru/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Кураторство
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## Как подавать Сигнал
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+Куратор может выбрать конкретную версию подграфа для сигнализации, или же он может выбрать автоматическую миграцию своего сигнала на самую новую рабочую сборку этого подграфа. Оба варианта являются допустимыми стратегиями и имеют свои плюсы и минусы.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Автоматическая миграция вашего сигнала на самую новую рабочую сборку может быть ценной, чтобы гарантировать непрерывное начисление комиссий за запросы. Каждый раз, когда вы осуществляете курирование, взимается комиссия в размере 1%. Вы также заплатите комиссию в размере 0,5% при каждой миграции. Разработчикам подграфов не рекомендуется часто публиковать новые версии - они должны заплатить комиссию на курирование в размере 0,5% на все автоматически мигрированные доли курации.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Риски
+
+1. Рынок запросов в The Graph по своей сути молод, и существует риск того, что ваш %APY может оказаться ниже, чем вы ожидаете, из-за зарождающейся динамики рынка.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. Подграф может выйти из строя из-за ошибки. За неудавшийся подграф не начисляется плата за запрос. В результате вам придется ждать, пока разработчик исправит ошибку и выложит новую версию.
+   - Если вы подписаны на новейшую версию подграфа, ваши общие ресурсы автоматически перейдут на эту новую версию. При этом будет взиматься кураторская комиссия в размере 0,5%.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Часто задаваемые вопросы по кураторству
+
+### 1. Какой % от оплаты за запрос получают кураторы?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. Как определить, какие подграфы являются высококачественными, чтобы подавать на них сигналы?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. Какова стоимость обновления подграфа?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. Как часто я могу обновлять свой подграф?
+
+Рекомендуется не обновлять свои подграфы слишком часто. См. выше для более подробной информации.
+
+### 5. Могу ли я продать свои кураторские доли?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Вы все еще в замешательстве? Ознакомьтесь с нашим видеоруководством по кураторству:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 814e2f4cd0ac1e74ad3c34003fdd411a0305c255 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:57 -0500
Subject: [PATCH 1321/3820] New translations curating.mdx (Swedish)

---
 website/pages/sv/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/sv/resources/roles/curating.mdx

diff --git a/website/pages/sv/resources/roles/curating.mdx b/website/pages/sv/resources/roles/curating.mdx
new file mode 100644
index 000000000000..12561d349d05
--- /dev/null
+++ b/website/pages/sv/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Kuratering
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## Hur man Signaliserar
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+En kurator kan välja att signalera på en specifik subgrafversion, eller så kan de välja att ha sin signal automatiskt migrerad till den nyaste produktionsversionen av den subgrafen. Båda är giltiga strategier och har sina egna för- och nackdelar.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Att ha din signal automatiskt migrerad till den nyaste produktionsversionen kan vara värdefullt för att säkerställa att du fortsätter att ackumulera frågeavgifter. Varje gång du signalerar åläggs en kuratoravgift på 1%. Du kommer också att betala en kuratoravgift på 0,5% vid varje migration. Subgrafutvecklare uppmanas att inte publicera nya versioner för ofta - de måste betala en kuratoravgift på 0,5% på alla automatiskt migrerade kuratorandelar.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Risker
+
+1. Frågemarknaden är i grunden ung på The Graph och det finns en risk att din %APY kan vara lägre än du förväntar dig på grund av tidiga marknadsmekanik.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. En subgraf kan misslyckas på grund av en bugg. En misslyckad subgraf genererar inte frågeavgifter. Som ett resultat måste du vänta tills utvecklaren rättar felet och distribuerar en ny version.
+   - Om du prenumererar på den nyaste versionen av en subgraf kommer dina andelar automatiskt att migreras till den nya versionen. Detta kommer att medföra en kuratoravgift på 0,5%.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Kurations-FAQ
+
+### 1. Vilken % av frågeavgifterna tjänar Kuratorer?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. Hur bestämmer jag vilka subgrafer av hög kvalitet att signalera på?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. Vad kostar det att uppdatera en subgraf?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. Hur ofta kan jag uppdatera min subgraf?
+
+Det föreslås att du inte uppdaterar dina subgrafer för ofta. Se frågan ovan för mer information.
+
+### 5. Kan jag sälja mina kuratorandelar?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Fortfarande förvirrad? Kolla in vår videohandledning om kurering nedan:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From c35d2b1449efe1a233cfc2f36f48afe9be3739b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:58 -0500
Subject: [PATCH 1322/3820] New translations curating.mdx (Turkish)

---
 website/pages/tr/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/tr/resources/roles/curating.mdx

diff --git a/website/pages/tr/resources/roles/curating.mdx b/website/pages/tr/resources/roles/curating.mdx
new file mode 100644
index 000000000000..7b1be8eea61b
--- /dev/null
+++ b/website/pages/tr/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curating
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## How to Signal
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+A curator can choose to signal on a specific subgraph version, or they can choose to have their signal automatically migrate to the newest production build of that subgraph. Both are valid strategies and come with their own pros and cons.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Risks
+
+1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
+   - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Curation FAQs
+
+### 1. What % of query fees do Curators earn?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. How do I decide which subgraphs are high quality to signal on?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. Bir subgraph'ı güncellemenin maliyeti nedir?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. Subgraph'ımı ne sıklıkla güncelleyebilirim?
+
+Subgraph'ınızı çok sık güncellememeniz önerilir. Daha fazla ayrıntı için yukarıdaki soruya bakın.
+
+### 5. Can I sell my curation shares?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Still confused? Check out our Curation video guide below:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 5e6c566143167e21a4e4d334138397b2da6a863f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:07:59 -0500
Subject: [PATCH 1323/3820] New translations curating.mdx (Ukrainian)

---
 website/pages/uk/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/uk/resources/roles/curating.mdx

diff --git a/website/pages/uk/resources/roles/curating.mdx b/website/pages/uk/resources/roles/curating.mdx
new file mode 100644
index 000000000000..1b9e3b14f609
--- /dev/null
+++ b/website/pages/uk/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Кураторство
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## Як сигналізувати
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+Куратор може обрати подання сигналу на певну версію підграфа, або ж він може обрати автоматичне перенесення сигналу на найновішу версію цього підграфа. Обидва варіанти є прийнятними та мають свої плюси та мінуси.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Автоматичне переміщення вашого сигналу на найновішу версію може бути корисним для того, щоб ви продовжували нараховувати комісію за запити. Кожного разу, коли ви здійснюєте кураторську роботу, стягується плата за в розмірі 1%. Ви також сплачуєте 0,5% за кураторство, за кожну міграцію. Розробникам підграфів не рекомендується часто публікувати нові версії - вони повинні сплачувати 0.5% кураторам за всі автоматично переміщені частки кураторів.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Ризики
+
+1. Ринок запитів за своєю суттю молодий в Graph, і існує ризик того, що ваш %APY може бути нижчим, ніж ви очікуєте, через динаміку ринку, що зароджується.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. Підграф може не працювати через різноманітні помилки (баги). Підграф, що не працює не стягує комісію за запити. В результаті вам доведеться почекати, поки розробник виправить усі помилки й випустить нову версію.
+   - Якщо ви підключені до найновішої версії підграфу, ваші частки будуть автоматично перенесені до цієї нової версії. При цьому буде стягуватися податок на в розмірі 0,5%.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Часті запитання про кураторство
+
+### 1. Який % від комісії за запити отримують куратори?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. Як вирішити, які підграфи є якісними для подачі сигналу?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. What’s the cost of updating a subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. How often can I update my subgraph?
+
+It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+
+### 5. Чи можу я продати свої частки куратора?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Все ще спантеличені? Перегляньте нашу відео інструкцію нижче:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From bae6b29ecc74ef9262e3a1bf9fa8ec819e8f9d0e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:00 -0500
Subject: [PATCH 1324/3820] New translations curating.mdx (Chinese Simplified)

---
 website/pages/zh/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/zh/resources/roles/curating.mdx

diff --git a/website/pages/zh/resources/roles/curating.mdx b/website/pages/zh/resources/roles/curating.mdx
new file mode 100644
index 000000000000..3bb4ed8d4181
--- /dev/null
+++ b/website/pages/zh/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: 策展
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## 如何进行信号处理
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+策展人可以选择在特定的子图版本上发出信号，或者他们可以选择让他们的策展份额自动迁移到该子图的最新生产版本。 这两种策略都是有效的，都有各自的优点和缺点。
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+让你的策展份额自动迁移到最新的生产构建，对确保你不断累积查询费用是有价值的。 每次你策展时，都会产生 1%的策展税。 每次迁移时，你也将支付 0.5%的策展税。 不鼓励子图开发人员频繁发布新版本--他们必须为所有自动迁移的策展份额支付 0.5%的策展税。
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## 风险
+
+1. 在Graph，查询市场本来就很年轻，由于市场动态刚刚开始，你的年收益率可能低于你的预期，这是有风险的。
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. 一个子图可能由于错误而失败。 一个失败的子图不会累积查询费用。 因此，你必须等待，直到开发人员修复错误并部署一个新的版本。
+   - 如果你订阅了一个子图的最新版本，你的份额将自动迁移到该新版本。 这将产生 0.5%的策展税。
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## 策展常见问题
+
+### 1. 策展人能赚取多少百分比的查询费？
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. 如何决定哪些子图是高质量的信号？
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. 升级一个子图的成本是多少？
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. 我可以多频繁的升级子图？
+
+建议你不要太频繁地升级子图。 更多细节请见上面的问题。
+
+### 5. 我可以出售我的策展份额吗？
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+还有困惑吗？ 点击下面查看管理视频指导：
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 453fd437225a61a0a9ab41f4bb357bbf11e22049 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:02 -0500
Subject: [PATCH 1325/3820] New translations curating.mdx (Urdu (Pakistan))

---
 website/pages/ur/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/ur/resources/roles/curating.mdx

diff --git a/website/pages/ur/resources/roles/curating.mdx b/website/pages/ur/resources/roles/curating.mdx
new file mode 100644
index 000000000000..5463a994ebd7
--- /dev/null
+++ b/website/pages/ur/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: کیورٹنگ
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## سگنل کرنے کا طریقہ
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+ایک کیوریٹر مخصوص سب گراف ورژن پر سگنل دینے کا انتخاب کر سکتا ہے، یا وہ اپنے سگنل کو خود بخود اس سب گراف کی جدید ترین پروڈکشن بلڈ میں منتقل کرنے کا انتخاب کر سکتا ہے۔ دونوں درست حکمت عملی ہیں اور ان کے اپنے فوائد اور نقصانات کے ساتھ آتے ہیں.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+آپ کے سگنل کو خود بخود جدید ترین پروڈکشن کی تعمیر میں منتقل کرنا اس بات کو یقینی بنانے کے لیے قابل قدر ہو سکتا ہے کہ آپ کیوری کی فیس جمع کرتے رہیں۔ جب بھی آپ کیوریشن کرتے ہیں، 1% کیوریشن ٹیکس لاگو ہوتا ہے۔ آپ ہر دفعہ منتقلی پر 0.5% کا کیوریشن ٹیکس ادا کریں گے. سب گراف ڈویلپرز کو نئے ورژنز کثرت سے شائع کرنے کی حوصلہ شکنی کی جاتی ہے - انہیں تمام خود کار طریقے سے منتقل کیوریشن شیئرز پر 0.5% کیوریشن ٹیکس ادا کرنا پڑتا ہے.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## خطرات
+
+1. گراف میں کیوری کی مارکیٹ فطری طور پر جوان ہے اور اس بات کا خطرہ ہے کہ آپ کا %APY مارکیٹ کی نئی حرکیات کی وجہ سے آپ کی توقع سے کم ہو سکتا ہے.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. ایک سب گراف ایک بگ کی وجہ سے ناکام ہو سکتا ہے. ایک ناکام سب گراف کیوری کی فیس جمع نہیں کرتا ہے. اس کے نتیجے میں،آپ کو انتظار کرنا پڑے گاجب تک کہ ڈویلپر اس بگ کو کو ٹھیک نہیں کرتا اور نیا ورژن تعینات کرتا ہے.
+   - اگر آپ نےسب گراف کے نۓ ورژن کو سبسکرائب کیا ہے. آپ کے حصص خود بخود اس نئے ورژن میں منتقل ہو جائیں گے۔ اس پر 0.5% کیوریشن ٹیکس لگے گا.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## کیوریشن کے اکثر پوچھے گئے سوالات
+
+### 1. کیوریٹرز کتنی % کیوری فیس کماتے ہیں؟
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. میں یہ کیسے طے کروں کہ کون سے سب گرافس اعلیٰ معیار کے ہیں؟
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. سب گراف کو اپ ڈیٹ کرنے کی کیا قیمت ہے؟
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. میں اپنے سب گراف کو کتنی بار اپ گریڈ کر سکتا ہوں؟
+
+یہ تجویز کی جاتی ہے کہ آپ اپنے سب گراف کو کثرت سے اپ گریڈ نہ کریں۔ مزید تفصیلات کو لیے اوپر والا سوال دیکھیں۔
+
+### 5. کیا میں اپنے کیوریشن شیئرز بیچ سکتا ہوں؟
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+ابھی بھی الجھن میں ہیں، ذیل میں ہماری کیوریشن ویڈیو گائیڈ دیکھیں:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From dbadf6d0eb156abf1dfe60384718e5745b1fd45c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:03 -0500
Subject: [PATCH 1326/3820] New translations curating.mdx (Vietnamese)

---
 website/pages/vi/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/vi/resources/roles/curating.mdx

diff --git a/website/pages/vi/resources/roles/curating.mdx b/website/pages/vi/resources/roles/curating.mdx
new file mode 100644
index 000000000000..4cecc4b549e6
--- /dev/null
+++ b/website/pages/vi/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curating
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## Làm thế nào để phát tín hiệu
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+Curator có thể chọn phát tín hiệu trên một phiên bản subgraph cụ thể hoặc họ có thể chọn để tín hiệu của họ tự động chuyển sang bản dựng sản xuất mới nhất của subgraph đó. Cả hai đều là những chiến lược hợp lệ và đi kèm với những ưu và nhược điểm của riêng chúng.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Những rủi ro
+
+1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. Một subgraph có thể thất bại do một lỗi. Một subgraph thất bại không tích lũy phí truy vấn. Do đó, bạn sẽ phải đợi cho đến khi nhà phát triển sửa lỗi và triển khai phiên bản mới.
+   - Nếu bạn đã đăng ký phiên bản mới nhất của một subgraph, các cổ phần của bạn sẽ tự động chuyển sang phiên bản mới đó. Điều này sẽ phát sinh một khoản thuế curation 0.5%.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Câu hỏi thường gặp về Curation
+
+### 1. Curator kiếm được bao nhiêu % phí truy vấn?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. Làm cách nào để tôi quyết định xem các subgraph nào có chất lượng cao để báo hiệu?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. What’s the cost of updating a subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. How often can I update my subgraph?
+
+It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+
+### 5. Tôi có thể bán cổ phần curation của mình không?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Vẫn còn thắc mắc? Xem video hướng dẫn Curation của chúng tôi bên dưới:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From 0f7e957eece2490b76ae0fcb398e35610dda6cf0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:04 -0500
Subject: [PATCH 1327/3820] New translations curating.mdx (Marathi)

---
 website/pages/mr/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/mr/resources/roles/curating.mdx

diff --git a/website/pages/mr/resources/roles/curating.mdx b/website/pages/mr/resources/roles/curating.mdx
new file mode 100644
index 000000000000..bbb551af354d
--- /dev/null
+++ b/website/pages/mr/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: क्युरेटिंग
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## सिग्नल कसे करावे
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+क्युरेटर विशिष्ट सबग्राफ आवृत्तीवर सिग्नल करणे निवडू शकतो किंवा ते त्यांचे सिग्नल त्या सबग्राफच्या नवीनतम उत्पादन बिल्डमध्ये स्वयंचलितपणे स्थलांतरित करणे निवडू शकतात. दोन्ही वैध धोरणे आहेत आणि त्यांच्या स्वतःच्या साधक आणि बाधकांसह येतात.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+तुमचा सिग्नल नवीनतम प्रोडक्शन बिल्डवर आपोआप स्थलांतरित होणे हे तुम्ही क्वेरी फी जमा करत असल्याचे सुनिश्चित करण्यासाठी मौल्यवान असू शकते. प्रत्येक वेळी तुम्ही क्युरेट करता तेव्हा 1% क्युरेशन कर लागतो. तुम्ही प्रत्येक स्थलांतरावर 0.5% क्युरेशन कर देखील द्याल. सबग्राफ विकसकांना वारंवार नवीन आवृत्त्या प्रकाशित करण्यापासून परावृत्त केले जाते - त्यांना सर्व स्वयं-स्थलांतरित क्युरेशन शेअर्सवर 0.5% क्युरेशन कर भरावा लागतो.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## जोखीम
+
+1. द ग्राफमध्ये क्वेरी मार्केट मूळतः तरुण आहे आणि नवीन मार्केट डायनॅमिक्समुळे तुमचा %APY तुमच्या अपेक्षेपेक्षा कमी असण्याचा धोका आहे.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. बगमुळे सबग्राफ अयशस्वी होऊ शकतो. अयशस्वी सबग्राफ क्वेरी शुल्क जमा करत नाही. परिणामी, विकसक बगचे निराकरण करेपर्यंत आणि नवीन आवृत्ती तैनात करेपर्यंत तुम्हाला प्रतीक्षा करावी लागेल.
+   - तुम्ही सबग्राफच्या नवीनतम आवृत्तीचे सदस्यत्व घेतले असल्यास, तुमचे शेअर्स त्या नवीन आवृत्तीमध्ये स्वयंचलितपणे स्थलांतरित होतील. यावर 0.5% क्युरेशन कर लागेल.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## क्युरेशन FAQs
+
+### 1. क्युरेटर्स किती % क्वेरी फी मिळवतात?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. कोणते सबग्राफ उच्च दर्जाचे आहेत हे मी कसे ठरवू?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. What’s the cost of updating a subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. How often can I update my subgraph?
+
+It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+
+### 5. मी माझे क्युरेशन शेअर्स विकू शकतो का?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+अजूनही गोंधळलेले? खाली आमचे क्युरेशन व्हिडिओ मार्गदर्शक पहा:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From fa4ff98c6db55ae0637d6f3a35a978b1a46359ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:05 -0500
Subject: [PATCH 1328/3820] New translations curating.mdx (Hindi)

---
 website/pages/hi/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/hi/resources/roles/curating.mdx

diff --git a/website/pages/hi/resources/roles/curating.mdx b/website/pages/hi/resources/roles/curating.mdx
new file mode 100644
index 000000000000..e54b89d37803
--- /dev/null
+++ b/website/pages/hi/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: क्यूरेटिंग
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## सिग्नल कैसे करें
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+एक क्यूरेटर एक विशिष्ट सबग्राफ संस्करण पर संकेत देना चुन सकता है, या वे अपने सिग्नल को स्वचालित रूप से उस सबग्राफ के नवीनतम उत्पादन निर्माण में माइग्रेट करना चुन सकते हैं। दोनों मान्य रणनीतियाँ हैं और अपने स्वयं के पेशेवरों और विपक्षों के साथ आती हैं।
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+अपने सिग्नल को स्वचालित रूप से नवीनतम उत्पादन बिल्ड में माइग्रेट करना यह सुनिश्चित करने के लिए मूल्यवान हो सकता है कि आप क्वेरी शुल्क अर्जित करते रहें। हर बार जब आप क्यूरेट करते हैं, तो 1% क्यूरेशन टैक्स लगता है। आप हर माइग्रेशन पर 0.5% क्यूरेशन टैक्स भी देंगे। सबग्राफ डेवलपर्स को बार-बार नए संस्करण प्रकाशित करने से हतोत्साहित किया जाता है - उन्हें सभी ऑटो-माइग्रेटेड क्यूरेशन शेयरों पर 0.5% क्यूरेशन टैक्स देना पड़ता है।
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## जोखिम
+
+1. क्वेरी बाजार द ग्राफ में स्वाभाविक रूप से युवा है और इसमें जोखिम है कि नवजात बाजार की गतिशीलता के कारण आपका %APY आपकी अपेक्षा से कम हो सकता है।
+2. क्यूरेशन शुल्क  - जब कोई क्यूरेटर किसी सबग्राफ़ पर GRT सिग्नल करता है, तो उसे 1% क्यूरेशन टैक्स देना होता है। यह शुल्क जला दिया जाता है।
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. बग के कारण सबग्राफ विफल हो सकता है। एक विफल सबग्राफ क्वेरी शुल्क अर्जित नहीं करता है। नतीजतन, आपको तब तक इंतजार करना होगा जब तक कि डेवलपर बग को ठीक नहीं करता है और एक नया संस्करण तैनात करता है।
+   - यदि आपने सबग्राफ के नवीनतम संस्करण की सदस्यता ली है, तो आपके शेयर उस नए संस्करण में स्वत: माइग्रेट हो जाएंगे। इस पर 0.5% क्यूरेशन टैक्स लगेगा।
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## अवधि पूछे जाने वाले प्रश्न
+
+### 1. क्यूरेटर क्वेरी फीस का कितना % कमाते हैं?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. मैं यह कैसे तय करूं कि कौन से सबग्राफ सिग्नल देने के लिए उच्च गुणवत्ता वाले हैं?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- क्यूरेटर नेटवर्क की अपनी समझ का उपयोग करके यह अनुमान लगाने की कोशिश कर सकते हैं कि भविष्य में कोई विशेष सबग्राफ़ अधिक या कम क्वेरी वॉल्यूम कैसे उत्पन्न कर सकता है।
+- क्यूरेटर को Graph Explorer के माध्यम से उपलब्ध मेट्रिक्स को भी समझना चाहिए। जैसे कि पिछले क्वेरी वॉल्यूम और सबग्राफ़ डेवलपर कौन है, ये मेट्रिक्स यह तय करने में मदद कर सकते हैं कि किसी सबग्राफ़ पर सिग्नलिंग करना उचित है या नहीं।
+
+### 3. What’s the cost of updating a subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. How often can I update my subgraph?
+
+It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+
+### 5. क्या मैं अपने क्यूरेशन शेयर बेच सकता हूँ?
+
+क्यूरेशन शेयरों को अन्य ERC20 टोकनों की तरह "खरीदा" या "बेचा" नहीं जा सकता, जिन्हें आप जानते होंगे। इन्हें केवल मिंट (निर्मित) या बर्न (नष्ट) किया जा सकता है।
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+अभी भी उलझन में? नीचे हमारे क्यूरेशन वीडियो गाइड देखें:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From e2a1afa43733612acbb625fcb28d834c0d784b5b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:06 -0500
Subject: [PATCH 1329/3820] New translations curating.mdx (Swahili)

---
 website/pages/sw/resources/roles/curating.mdx | 89 +++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 website/pages/sw/resources/roles/curating.mdx

diff --git a/website/pages/sw/resources/roles/curating.mdx b/website/pages/sw/resources/roles/curating.mdx
new file mode 100644
index 000000000000..8e6416b6d57e
--- /dev/null
+++ b/website/pages/sw/resources/roles/curating.mdx
@@ -0,0 +1,89 @@
+---
+title: Curating
+---
+
+Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+
+## What Does Signaling Mean for The Graph Network?
+
+Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+
+Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+
+Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+## How to Signal
+
+Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+
+A curator can choose to signal on a specific subgraph version, or they can choose to have their signal automatically migrate to the newest production build of that subgraph. Both are valid strategies and come with their own pros and cons.
+
+Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+
+Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares.
+
+> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+
+## Withdrawing your GRT
+
+Curators have the option to withdraw their signaled GRT at any time.
+
+Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+
+Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+
+However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+
+## Risks
+
+1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
+2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
+   - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
+   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+
+## Curation FAQs
+
+### 1. What % of query fees do Curators earn?
+
+By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+
+### 2. How do I decide which subgraphs are high quality to signal on?
+
+Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+
+- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
+- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+
+### 3. What’s the cost of updating a subgraph?
+
+Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+
+### 4. How often can I update my subgraph?
+
+It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+
+### 5. Can I sell my curation shares?
+
+Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+
+As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+
+### 6. Am I eligible for a curation grant?
+
+Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+
+Still confused? Check out our Curation video guide below:
+
+<VideoEmbed youtube="VytTEcf0dxQ" />

From eb28c1a4635bd2ee6298e702b41b83b42f58008c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:07 -0500
Subject: [PATCH 1330/3820] New translations delegating.mdx (Romanian)

---
 .../pages/ro/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/ro/resources/roles/delegating.mdx

diff --git a/website/pages/ro/resources/roles/delegating.mdx b/website/pages/ro/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..eda60369e00a
--- /dev/null
+++ b/website/pages/ro/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegating
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Delegator Guide
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+- A video guide showing the steps to delegate in the Graph Network UI
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The delegation tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The delegation unbonding period
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Considering the delegation capacity
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 01e84716167abe4c5f878cf44474bd7135ca2057 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:08 -0500
Subject: [PATCH 1331/3820] New translations delegating.mdx (French)

---
 .../pages/fr/resources/roles/delegating.mdx   | 142 ++++++++++++++++++
 1 file changed, 142 insertions(+)
 create mode 100644 website/pages/fr/resources/roles/delegating.mdx

diff --git a/website/pages/fr/resources/roles/delegating.mdx b/website/pages/fr/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..59296a754d98
--- /dev/null
+++ b/website/pages/fr/resources/roles/delegating.mdx
@@ -0,0 +1,142 @@
+---
+title: Délégation
+---
+
+Les Délégateurs sont des participants au réseau qui délèguent (c'est-à-dire "stakent") des GRT à un ou plusieurs Indexeurs.
+
+- Ils aident à sécuriser le réseau sans exécuter eux-mêmes un Graph Node.
+
+- Ils gagnent une partie des frais de requête et des récompenses d'un Indexeur en lui déléguant des GRT.
+
+## Comment ça marche?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Guide du délégué
+
+Apprenez comment être un délégateur efficace dans The Graph Network.
+
+Les Délégateurs partagent les gains du protocole aux côtés de tous les indexeurs en fonction de leur participation déléguée. Par conséquent, ils doivent faire preuve de discernement pour choisir les indexeurs en fonction de plusieurs facteurs.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+Ce guide comporte trois sections:
+
+- Les risques de la délégation de jetons dans The Graph Network
+- Comment calculer les rendements escomptés en tant que délégué
+- Un guide vidéo montrant les étapes pour déléguer dans l'interface utilisateur du réseau graph
+
+## Risques de délégation
+
+Les principaux risques liés à la fonction de délégué dans le protocole sont transmis ci-dessous.
+
+### La taxe de délégation
+
+Les délégués ne peuvent pas être licenciés en cas de mauvais comportement, mais ils sont soumis à une taxe visant à décourager les mauvaises décisions susceptibles de nuire à l'intégrité du réseau.
+
+En tant que Délégateur, il est important de comprendre ce qui suit :
+
+- Vous serez facturé 0,5% chaque fois que vous déléguez. Cela signifie que si vous déléguez 1,000 GRT, vous brûlerez automatiquement 5 GRT.
+
+- Pour être en sécurité, vous devriez calculer votre retour potentiel lorsque vous déléguez à un Indexeur. Par exemple, vous pourriez calculer combien de jours il faudra avant d'avoir récupéré la taxe de 0,5% sur votre délégation.
+
+### La période de découplage de la délégation
+
+Chaque fois qu'un Délégateur veut se désengager, ses jetons sont soumis à une période de d'attente de 28 jours. Cela signifie qu'ils ne peuvent pas transférer leurs jetons ou gagner des récompenses pendant 28 jours.
+
+### Pourquoi ceci est t-il important?
+
+Si vous choisissez un Indexeur qui n'est pas fiable ou qui ne fait pas du bon travail, vous voudrez vous désengager. Cela signifie que vous perdrez beaucoup d'opportunités de gagner des récompenses, ce qui peut être aussi mauvais que de brûler des GRT. Par conséquent, il est recommandé de choisir judicieusement un Indexeur.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Choisir un indexeur digne de confiance avec une rémunération équitable pour les délégués
+
+Pour comprendre comment choisir un Indexeur fiable, vous devez comprendre les paramètres de Délégation.
+
+#### Paramètres de Délégation
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - Si la part de récompense d'un indexeur est fixée à 100%, en tant que délégateur, vous recevrez 0 récompense d'indexation.
+  - Si elle est fixée à 80%, en tant que Délégateur, vous recevrez 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+Comme vous pouvez le voir, pour choisir le bon Indexeur, vous devez prendre en compte plusieurs éléments.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Beaucoup d'Indexeurs sont très actifs sur Discord et seront heureux de répondre à vos questions.
+- Beaucoup d'entre eux indexent depuis des mois et font de leur mieux pour aider les Délégateurs à obtenir un bon retour, car cela améliore la santé et le succès du réseau.
+
+## Calcul du rendement attendu par les Délégateurs
+
+Un Délégateur doit considérer les facteurs suivants pour déterminer un rendement :
+
+- Considérer la capacité d'un Indexeur à utiliser les jetons délégués dont il dispose.
+  - Si un Indexeur n'alloue pas tous les jetons disponibles, ils ne gagnent pas le maximum de profit qu'ils pourraient obtenir pour lui même ou ses Déléguateurs.
+- Soyez attentif aux premiers jours de la délégation.
+  - Un Indexeur peut choisir de fermer une allocation et de collecter des récompenses à tout moment entre 1 et 28 jours. Il est possible qu'un indexeur ait encore beaucoup de récompenses à collecter, de sorte que le total de ses récompenses est faible.
+
+### Considérant la réduction des frais d'interrogation et la réduction des frais d'indexation
+
+Vous devriez choisir un Indexeur qui est transparent et honnête dans la fixation de ses frais de requête et de ses réductions de frais d'indexation. Vous devez également examiner le Paramètre délai de récupérations pour voir de combien de temps vous disposez. Une fois cela fait, il est facile de calculer le montant des récompenses que vous obtenez.
+
+La formule est :
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Compte tenu du pool de délégation de l'indexeur
+
+Les Déléguateurs doivent considérer la proportion du Pool de Délégation qu'ils possèdent.
+
+Toutes les récompenses de délégation sont partagées de manière égale, avec un rééquilibrage du pool basé sur le montant que le Déléguateur a déposé dans le pool.
+
+Cela donne au Déléguateur une part du pool :
+
+![Share formula](/img/Share-Forumla.png)
+
+> La formule ci-dessus montre qu'il est possible pour un Indexeur offrant seulement 20% aux Déléguateurs de fournir une meilleure récompense qu'un Indexeur donnant 90%. Il suffit de faire les calculs pour déterminer la meilleure récompense.
+
+### Compte tenu de la capacité de délégation
+
+Enfin, considérez la capacité de délégation. Actuellement, le Ratio de Délégation est fixé à 16.
+
+#### Pourquoi est-ce important?
+
+Cela signifie que si un Indexeur a staké 1 000 000 GRT, sa Capacité de Délégation est de 16 000 000 GRT de tokens délégués qu'ils peuvent utiliser dans le protocole. Tous les tokens délégués au-delà de ce montant dilueront toutes les récompenses des Déléguateurs.
+
+Imaginez un Indexeur avec 100 000 000 GRT délégués à lui, mais sa capacité est seulement de 16 000 000 GRT. Cela signifie effectivement que 84 000 000 de GRT ne sont pas utilisés pour gagner des tokens. Ainsi, les Déléguateurs et les Indexeurs gagnent moins de récompenses qu'ils pourraient.
+
+Par conséquent, un Déléguateur doit toujours considérer la Capacité de Délégation d'un Indexeur et en tenir compte dans leur prise de décision.
+
+## FAQ et bugs pour les délégants
+
+### Bug MetaMask « Transaction en attente »
+
+1. Lorsque j'essaie de déléguer ma transaction dans MetaMask, elle apparaît comme « En attente » ( "Pending") ou « En file d'attente » ( "Queued")
+    plus longtemps que prévu. Que devrais-je faire?
+
+Parfois, les tentatives de déléguer aux Indexeurs via MetaMask peuvent échouer et entraîner des périodes prolongées de tentatives de transaction "Pending" ou "Queued".
+
+#### Exemple
+
+Imaginons que vous tentiez de déléguer avec des frais de gaz insuffisants par rapport aux prix actuels.
+
+- Cette action peut entraîner l'affichage de la tentative de transaction comme "En attente" dans votre portefeuille MetaMask pendant plus de 15 minutes. Dans ce cas, vous pouvez essayer des transactions ultérieures, mais elles ne seront traitées que lorsque la transaction initiale sera minée, car les transactions pour une adresse doivent être traitées dans l'ordre.
+- Dans de tels cas, ces transactions peuvent être annulées dans MetaMask, mais les tentatives de transactions accumuleront des frais de gas sans aucune garantie que les tentatives ultérieures seront réussies.
+
+Une solution simple à ce problème consiste à redémarrer le navigateur (par exemple, en utilisant "abort:restart" dans la barre d'adresse), ce qui annulera toutes les tentatives précédentes sans que le gaz ne soit soustrait du portefeuille. Plusieurs utilisateurs ayant rencontré ce problème ont signalé des transactions réussies après avoir redémarré leur navigateur et tenté de déléguer.
+
+## Guide Vidéo
+
+Ce guide vidéo passe en revue cette page tout en interagissant avec l'interface utilisateur.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 0dfa3fdd2fbc9e6c1699ab34d54f23f11eafd459 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:09 -0500
Subject: [PATCH 1332/3820] New translations delegating.mdx (Spanish)

---
 .../pages/es/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/es/resources/roles/delegating.mdx

diff --git a/website/pages/es/resources/roles/delegating.mdx b/website/pages/es/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..4eff3906805e
--- /dev/null
+++ b/website/pages/es/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegar
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Guía del Delegador
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- Los riesgos de delegar tokens en la red de The Graph
+- Cómo calcular los rendimientos que te esperan siendo Delegador
+- Una guía en video que muestra los pasos para delegar en la interfaz de usuario de Graph Network
+
+## Riesgos de la Delegación
+
+A continuación se enumeran los principales riesgos de ser un Delegador en el protocolo.
+
+### La tarifa de delegación
+
+Los Delegadores no pueden ser recortados por mal comportamiento, pero existe un impuesto sobre los Delegadores para desincentivar la toma de malas decisiones que puedan perjudicar la integridad de la red.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### El período de unbonding (desvinculación) de la delegación
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Elige un Indexador fiable, que pague recompensas justas a sus Delegadores
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Siempre ten en cuenta la tarifa por consulta y el recorte de recompensas para el Indexador
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Tener en cuenta el pool de delegación de cada Indexador
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Considerar la capacidad de delegación
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Preguntas Frecuentes del Delegador y Errores
+
+### Error de "Transacción Pendiente" en MetaMask
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Ejemplo
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 5873ea9c40597a19d232c36a82fd898154a5bbd7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:10 -0500
Subject: [PATCH 1333/3820] New translations delegating.mdx (Arabic)

---
 .../pages/ar/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/ar/resources/roles/delegating.mdx

diff --git a/website/pages/ar/resources/roles/delegating.mdx b/website/pages/ar/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..8ef41bbd6bdf
--- /dev/null
+++ b/website/pages/ar/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegating
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## دليل المفوض
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- مخاطر تفويض التوكن في شبكة The Graph
+- كيفية حساب العوائد المتوقعة كمفوض
+- A video guide showing the steps to delegate in the Graph Network UI
+
+## Delegation Risks
+
+القائمة أدناه هي المخاطر الرئيسية لكونك مفوضا في البروتوكول.
+
+### رسوم التفويض
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### فترة إلغاء التفويض
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### اختيار مفهرس جدير بالثقة مع عائد جيد للمفوضين
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### النظر في اقتطاع رسوم الاستعلام query fee cut واقتطاع رسوم الفهرسة indexing fee cut
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### النظر في أسهم تفويض المفهرس
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### النظر في سعة التفويض (delegation capacity)
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 08815e6d46670fe11bcb5c6afb27fa9d3eeded8b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:11 -0500
Subject: [PATCH 1334/3820] New translations delegating.mdx (Czech)

---
 .../pages/cs/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/cs/resources/roles/delegating.mdx

diff --git a/website/pages/cs/resources/roles/delegating.mdx b/website/pages/cs/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..7684f08f5fe2
--- /dev/null
+++ b/website/pages/cs/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegování
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Průvodce delegáta
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- Rizika delegování tokenů v síti Graf
+- Jak vypočítat očekávané výnosy jako delegát
+- Videoprůvodce ukazující kroky delegování v UI sit' Graf
+
+## Rizika delegování
+
+Níže jsou uvedena hlavní rizika plynoucí z delegáta v protokolu.
+
+### Delegační daň
+
+Delegáti nemohou být za špatné chování kráceni, ale existuje daň pro delegáty, která má odradit od špatného rozhodování, jež by mohlo poškodit integritu sítě.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### Konec období vázanosti delegací
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Výběr důvěryhodného indexátora se spravedlivou odměnou pro delegáty
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### S ohledem na snížení poplatků za dotaz a indexaci
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Zohlednění fondu delegování indexátoru
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Vzhledem ke kapacitě delegace
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## FAQ a chyby delegáta
+
+### Chyba MetaMask "Čekající transakce"
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Příklad
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From aa18ed24b83e0658a7e064b2abfa50117a6c576f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:12 -0500
Subject: [PATCH 1335/3820] New translations delegating.mdx (German)

---
 .../pages/de/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/de/resources/roles/delegating.mdx

diff --git a/website/pages/de/resources/roles/delegating.mdx b/website/pages/de/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..5fa99f101641
--- /dev/null
+++ b/website/pages/de/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegating
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Delegator Guide
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+- A video guide showing the steps to delegate in the Graph Network UI
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The delegation tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The delegation unbonding period
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Considering the delegation capacity
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Beispiel
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 39241f155d1a7f7f070224ffc07ede81bb3ab5f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:13 -0500
Subject: [PATCH 1336/3820] New translations delegating.mdx (Italian)

---
 .../pages/it/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/it/resources/roles/delegating.mdx

diff --git a/website/pages/it/resources/roles/delegating.mdx b/website/pages/it/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..cb65d530d4e1
--- /dev/null
+++ b/website/pages/it/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegazione
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Guida per i delegator
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- I rischi della delegazione dei token in The Graph Network
+- Come calcolare i rendimenti previsti come Delegator
+- Una guida video che mostra i passi per delegare nel UI di The Graph Network
+
+## Rischi di delegazione
+
+Di seguito sono elencati i principali rischi essere il Delegator nel protocollo.
+
+### La tassa di delegazione
+
+I delegator non possono essere penalizzati per un comportamento scorretto, ma c'è una tassa sui delegator per disincentivare un processo decisionale insufficiente che potrebbero danneggiare l'integrità della rete.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### Il periodo di sblocco di delegazione
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Scegliere un Indexer affidabile con una giusta ricompensa per i Delegator
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Considerando la riduzione delle tariffe di query e la riduzione delle tariffe di indicizzazione
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considerando il delegation pool del Indexer
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Considerando la capacità di delegazione
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## FAQ e bug dei Delegator
+
+### MetaMask "Transazione in sospeso" Bug
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Esempio
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 45d38e1703d7ca0a856624b0fa6493705b869156 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:14 -0500
Subject: [PATCH 1337/3820] New translations delegating.mdx (Japanese)

---
 .../pages/ja/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/ja/resources/roles/delegating.mdx

diff --git a/website/pages/ja/resources/roles/delegating.mdx b/website/pages/ja/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..069ec6803b59
--- /dev/null
+++ b/website/pages/ja/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: 委任
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## デリゲーターガイド
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- グラフネットワークでトークンをデリゲートすることのリスク
+- デリゲーターとしての期待リターンの計算方法
+- グラフネットワークの UI でデリゲートする手順のビデオガイド
+
+## デリゲーションリスク
+
+以下にリストされているのは、プロトコルで委任者になることの主なリスクです。
+
+### デリゲーション手数料
+
+デリゲーターは悪意の行動をしてもスラッシュされないが、デリゲーターにはデポジット税が課せられ、ネットワークの整合性を損なう可能性のある悪い意思決定を抑止します。
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### 委任期間無制限
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### デリゲーターに公平な報酬を支払う信頼できるインデクサーの選択
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### クエリフィーのカットとインデックスフィーのカットの検討
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### インデクサーのデリゲーションプールを考慮する
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### デリゲーションの容量を考慮する
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## デリゲーターに関するFAQと不具合
+
+### MetaMask "Pending Transaction "バグ
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### 例
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 3ccff091bb3e88511218019d6792ff76505521b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:15 -0500
Subject: [PATCH 1338/3820] New translations delegating.mdx (Korean)

---
 .../pages/ko/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/ko/resources/roles/delegating.mdx

diff --git a/website/pages/ko/resources/roles/delegating.mdx b/website/pages/ko/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..eda60369e00a
--- /dev/null
+++ b/website/pages/ko/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegating
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Delegator Guide
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+- A video guide showing the steps to delegate in the Graph Network UI
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The delegation tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The delegation unbonding period
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Considering the delegation capacity
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 9c4a8c3206bf251f132645ac6af96d0decb499e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:16 -0500
Subject: [PATCH 1339/3820] New translations delegating.mdx (Dutch)

---
 .../pages/nl/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/nl/resources/roles/delegating.mdx

diff --git a/website/pages/nl/resources/roles/delegating.mdx b/website/pages/nl/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..83cc07b364cd
--- /dev/null
+++ b/website/pages/nl/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegeren
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Delegeerder Gids
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- De risico's van het delegeren van tokens in het Graph Netwerk
+- Hoe je verwachte opbrengsten als Delegeerder berekent
+- Een videogids die de stappen laat zien om te delegeren in het Graph Netwerk
+
+## Delegatie Risico's
+
+Hieronder staan de belangrijkste risico's van het zijn van een Delegeerder in het protocol.
+
+### Delegatiebelasting
+
+Delegeerders kunnen niet worden gestraft voor slecht gedrag, maar er is een belasting voor Delegeerders om slechte besluitvorming die de integriteit van het netwerk kan schaden te ontmoedigen.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### Delegatieontbindingsperiode
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Het kiezen van een betrouwbare Indexeerder met een eerlijke beloningsuitbetaling voor Delegeerders
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Rekening houden met de query fee aandeel en indexing fee aandeel
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Rekening houden met de delegatie pool van een Indexeerder
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Rekening houden met de delegatiecapaciteit
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Veelgestelde vragen van Delegeerders en Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 20f6b706aa4bafeea4d4c689d9e3cbe87c5716a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:17 -0500
Subject: [PATCH 1340/3820] New translations delegating.mdx (Polish)

---
 .../pages/pl/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/pl/resources/roles/delegating.mdx

diff --git a/website/pages/pl/resources/roles/delegating.mdx b/website/pages/pl/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..eda60369e00a
--- /dev/null
+++ b/website/pages/pl/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegating
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Delegator Guide
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+- A video guide showing the steps to delegate in the Graph Network UI
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The delegation tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The delegation unbonding period
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Considering the delegation capacity
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From bd0c2ea34c124da077b2455300923c6e5b741933 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:18 -0500
Subject: [PATCH 1341/3820] New translations delegating.mdx (Portuguese)

---
 .../pages/pt/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/pt/resources/roles/delegating.mdx

diff --git a/website/pages/pt/resources/roles/delegating.mdx b/website/pages/pt/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..44ef4ee4730b
--- /dev/null
+++ b/website/pages/pt/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegação
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Guia do Delegante
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+Há três secções neste guia:
+
+- Os riscos de delegar tokens na Graph Network
+- Como calcular retornos esperados como um Delegante
+- Um guia de vídeo que mostra como delegar na interface da Graph Network
+
+## Riscos de Delegação
+
+Veja abaixo os riscos principais de ser um Delegante no protocolo.
+
+### A taxa de delegação
+
+Os Delegantes não podem ser punidos por mau comportamento, mas há uma taxa sobre Delegantes, para desencorajar más decisões que possam ferir a integridade da rede.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### O período de separação da delegação
+
+Se um Delegado quiser cancelar a sua delegação, seus tokens estarão sujeitos a um período de 28 dias sem transferência, e também não poderá ganhar quaisquer recompensas por este período.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Como escolher um Indexador de confiança, com um pagamento justo para Delegantes
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Como considerar as porções das taxas de query e de indexação
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Como considerar o pool de delegação do Indexador
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Como considerar a capacidade de delegação
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Assim, um Delegante deve sempre considerar a Capacidade de Delegação de um Indexador, e levá-la em conta ao tomar decisões.
+
+## Erros e Perguntas Frequentes sobre Delegação
+
+### Erro de "Transação Pendente" no MetaMask
+
+1. Quando eu tento delegar a minha transação no MetaMask, ela aparece como "Pendente" ou "Na Fila" por mais tempo que o esperado. O que devo fazer?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Exemplo
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 55bbd01a9dfd9d8c514e001745cdae0fd7f009f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:20 -0500
Subject: [PATCH 1342/3820] New translations delegating.mdx (Russian)

---
 .../pages/ru/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/ru/resources/roles/delegating.mdx

diff --git a/website/pages/ru/resources/roles/delegating.mdx b/website/pages/ru/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..cd5356074a7f
--- /dev/null
+++ b/website/pages/ru/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Делегирование
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Инструкция Делегатора
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- Риски связанные с делегацией в сети The Graph
+- Как расчитать примерный доход
+- Видео ролик показывающий как делегировать через веб интерфейс The Graph сети
+
+## Риски делегации
+
+Ниже указаны основные риски Делегатора.
+
+### Комиссия на делегацию
+
+Делегаторы не могут быть наказаны за некорректное поведение, но они уплачивают комиссию на делегацию, который должен стимулировать обдуманный выбор Индексатора для делегации.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### Период unbonding (разблокировки) делегирования
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Выбор надежного Индексатора со справедливым распределением вознаграждений для Делегаторов
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Учёт среза комиссии за запросы и срез вознаграждения за индексацию
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Осмотр пула делегирования индексатора
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Учёт возможности делегирования
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Частые вопросы и баги
+
+### Ошибка Метамаска "Pending Transaction"
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Пример
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From b24c2094cda8fab438f2d3cc3f5340a3896603f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:21 -0500
Subject: [PATCH 1343/3820] New translations delegating.mdx (Swedish)

---
 .../pages/sv/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/sv/resources/roles/delegating.mdx

diff --git a/website/pages/sv/resources/roles/delegating.mdx b/website/pages/sv/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..9d79c46931b0
--- /dev/null
+++ b/website/pages/sv/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegera
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Delegateringsguide
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- Riskerna med att delegera tokens i The Graph-nätverket
+- Hur man beräknar förväntad avkastning som Delegater
+- En videohandledning som visar stegen för att delegera i Graf Nätverk UI
+
+## Delegationsrisker
+
+Här nedan listas huvudriskerna med att vara en Delegater i protokollet.
+
+### Delegationsavgiften
+
+Delegater kan inte "slashas" för dåligt beteende, men det finns en avgift för Delegater för att avskräcka dåligt beslutsfattande som kan skada nätverkets integritet.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### Perioden för upphävande av delegering
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Att välja en pålitlig Indexer med en rättvis belöningsutbetalning till Delegater
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Att överväga frågebetalningsavgiften och indexeringsavgiften
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Att överväga Indexer's delegeringspool
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Att överväga delegeringskapaciteten
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Delegaters FAQ och buggar
+
+### Metamask "Väntande transaktion" bugg
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Exempel
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 6234b334902cdbcf1c36d77c875ff10466957812 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:22 -0500
Subject: [PATCH 1344/3820] New translations delegating.mdx (Turkish)

---
 .../pages/tr/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/tr/resources/roles/delegating.mdx

diff --git a/website/pages/tr/resources/roles/delegating.mdx b/website/pages/tr/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..a7be05b9f698
--- /dev/null
+++ b/website/pages/tr/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegating
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Delegator Guide
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+- A video guide showing the steps to delegate in the Graph Network UI
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The delegation tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The delegation unbonding period
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Considering the delegation capacity
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Örnek
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 259cd0613a1136856f5bc6d368c2ccb42155f9ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:23 -0500
Subject: [PATCH 1345/3820] New translations delegating.mdx (Ukrainian)

---
 .../pages/uk/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/uk/resources/roles/delegating.mdx

diff --git a/website/pages/uk/resources/roles/delegating.mdx b/website/pages/uk/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..cf629b9b7048
--- /dev/null
+++ b/website/pages/uk/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Делегування
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Гайд для делегатів
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- Ризики делегування токенів в мережі Graph
+- Як розрахувати можливі прибутки як делегат
+- Відеоінструкція, що демонструє кроки з делегування в інтерфейсі мережі Graph
+
+## Ризики, пов'язані з делегуванням
+
+Нижче перераховані основні ризики, пов'язані з участю делегата в протоколі.
+
+### Штраф на делегування
+
+Делегати не можуть бути виключені за погану поведінку, але існує певний штраф для них, щоб позбавити стимулу щодо прийняття поганих рішень, які можуть зашкодити цілісності мережі.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### Період розблокування делегації
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Вибір надійного індексатора зі справедливою винагородою для делегатів
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Розглянемо питання про отримання частини винагороди за індексацію та за запити
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Розглянемо пул делегацій індексатора
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Розглянемо ліміт делегування
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Поширені запитання та баги
+
+### Баг в гаманці MetaMask "Pending Transaction"
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 37605e5b3f9c342a64d10cbdc6ead4beea3014fb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:24 -0500
Subject: [PATCH 1346/3820] New translations delegating.mdx (Chinese
 Simplified)

---
 .../pages/zh/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/zh/resources/roles/delegating.mdx

diff --git a/website/pages/zh/resources/roles/delegating.mdx b/website/pages/zh/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..8f1538cffbcc
--- /dev/null
+++ b/website/pages/zh/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: 委托
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## 委托人指南
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- 在 Graph 网络中委托代币的风险
+- 如何计算作为委托人的预期回报
+- 展示在Graph 网络界面中进行委托步骤的视频指南
+
+## 委托风险
+
+下面列出了作为协议中的委托人的主要风险。
+
+### 委托费用
+
+委托人不能因为不良行为而被取消，但对委托有税，以抑制可能损害网络完整性的不良决策。
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### 委托解约期
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### 选择一个为委托人提供公平的奖励分配的值得信赖的索引人
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### 考虑到查询费用的分成和索引费用的分成
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### 考虑索引人委托池
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### 考虑委托容量
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## 委托人常见问题和错误
+
+### MetaMask“待定交易”错误
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### 示例
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 633c0ca9ab9f8e3fc5dda02dd37aea7127737f31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:25 -0500
Subject: [PATCH 1347/3820] New translations delegating.mdx (Urdu (Pakistan))

---
 .../pages/ur/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/ur/resources/roles/delegating.mdx

diff --git a/website/pages/ur/resources/roles/delegating.mdx b/website/pages/ur/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..a1f89b513d63
--- /dev/null
+++ b/website/pages/ur/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: ڈیلیگیٹنگ
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## ڈیلیگیٹر گائیڈ
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- گراف نیٹ ورک میں ٹوکن ڈیلیگ کرنے کے خطرات
+- بطور ڈیلیگیٹر متوقع واپسی کا حساب کیسے لگائیں
+- ایک ویڈیو گائیڈ جو گراف نیٹ ورک UI میں نمائندگی کرنے کے اقدامات دکھا رہا ہے
+
+## ڈیلیگیشن کے خطرات
+
+پروٹوکول میں ڈیلیگیٹر ہونےکے اہم خطرات مندرجہ ذیل ہیں.
+
+### ڈیلیگیشن ٹیکس
+
+برے رویۓ پر ڈیلیگیٹرز کو نہیں چھوڑا جا سکتا، لیکن ناقص فیصلہ سازی کی حوصلہ شکنی کے لیے ڈیلیگیٹرز پر ٹیکس ہے جو نیٹ ورک کی سالمیت کو نقصان پہنچا سکتا ہے.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### وفد کی بندش کی مدت
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### ڈیلیگیٹرز کے لیے منصفانہ انعامی ادائیگی کے ساتھ ایک قابل اعتماد انڈیکسر کا انتخاب کرنا
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### کیوری فیس میں کمی اور انڈیکسنگ کی فیس میں کمی پر غور کرنا
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### انڈیکسر کے ڈیلیگیشن پول پر غور کرنا
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### ڈیلیگیشن کی صلاحیت کو مدنظر رکھتے ہوئے
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## ڈیلیگیٹر کے اکثر پوچھے گئے سوالات اور بگز
+
+### میٹا ماسک "پینڈنگ ٹرانزیکشن" بگ
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### مثال
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 86513beeddfb6b19bbe9215f7a4a45fc5411c01f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:26 -0500
Subject: [PATCH 1348/3820] New translations delegating.mdx (Vietnamese)

---
 .../pages/vi/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/vi/resources/roles/delegating.mdx

diff --git a/website/pages/vi/resources/roles/delegating.mdx b/website/pages/vi/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..02bde6f7a84a
--- /dev/null
+++ b/website/pages/vi/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegating
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Hướng dẫn Delegator
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- Rủi ro của việc ủy quyền token trong Mạng The Graph
+- Cách tính lợi nhuận kỳ vọng với tư cách là delegator
+- A video guide showing the steps to delegate in the Graph Network UI
+
+## Rủi ro Ủy quyền
+
+Lưu ý quan trọng là mỗi lần bạn ủy quyền, bạn sẽ bị tính phí 0.5%. Nghĩa là nếu bạn đang ủy quyền 1000 GRT, bạn sẽ tự động đốt 5 GRT.
+
+### Phí ủy quyền
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### Khoảng thời gian bỏ ràng buộc ủy quyền
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Chọn một indexer đáng tin cậy với phần thưởng hợp lý cho delegator
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Xem xét Phần cắt Phí Truy vấn và Phần cắt Phí indexing
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Xem xét Delegation pool của Indexer
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Xem xét Delegation Capacity (Năng lực Ủy quyền)
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Ví dụ
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 49a18c7d2445a68772c2d283f6188a3fd80fec42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:27 -0500
Subject: [PATCH 1349/3820] New translations delegating.mdx (Marathi)

---
 .../pages/mr/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/mr/resources/roles/delegating.mdx

diff --git a/website/pages/mr/resources/roles/delegating.mdx b/website/pages/mr/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..694c6c52a9a7
--- /dev/null
+++ b/website/pages/mr/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegating
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Delegator Guide
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+- A video guide showing the steps to delegate in the Graph Network UI
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The delegation tax
+
+वाईट वर्तनासाठी प्रतिनिधींना कमी केले जाऊ शकत नाही, परंतु नेटवर्कच्या अखंडतेला हानी पोहोचवणाऱ्या खराब निर्णयक्षमतेला प्रोत्साहन देण्यासाठी प्रतिनिधींवर कर लावला जातो.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The delegation unbonding period
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Considering the delegation capacity
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### उदाहरण
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 35e8a36d2a0ee8b298a1271f88adba3e78345822 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:29 -0500
Subject: [PATCH 1350/3820] New translations delegating.mdx (Hindi)

---
 .../pages/hi/resources/roles/delegating.mdx   | 142 ++++++++++++++++++
 1 file changed, 142 insertions(+)
 create mode 100644 website/pages/hi/resources/roles/delegating.mdx

diff --git a/website/pages/hi/resources/roles/delegating.mdx b/website/pages/hi/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..efe4a7054943
--- /dev/null
+++ b/website/pages/hi/resources/roles/delegating.mdx
@@ -0,0 +1,142 @@
+---
+title: Delegating
+---
+
+Delegator नेटवर्क के प्रतिभागी होते हैं जो एक या अधिक इंडेक्सर्स को जीआरटी (GRT) का प्रतिनिधित्व (यानी, "स्टेक") करते हैं।
+
+- वे बिना खुद Graph Node चलाए नेटवर्क को सुरक्षित रखने में मदद करते हैं।
+
+- वे इंडेक्सर को डेलीगेट करके उनकी क्वेरी फीस और पुरस्कार का एक हिस्सा कमाते हैं।
+
+## यह कैसे काम करता है?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## प्रतिनिधि गाइड
+
+The Graph Network में एक प्रभावशाली Delegator बनने के लिए सीखें।
+
+Delegator अपने डेलीगेटेड स्टेक के आधार पर सभी Indexer के साथ प्रोटोकॉल की कमाई साझा करते हैं। इसलिए, उन्हें कई कारकों के आधार पर Indexer का चयन करने के लिए अपने सर्वोत्तम विवेक का उपयोग करना चाहिए।
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- ग्राफ़ नेटवर्क में टोकन सौंपने का जोखिम
+- प्रतिनिधि के रूप में अपेक्षित रिटर्न की गणना कैसे करें
+- ग्राफ़ नेटवर्क UI में प्रत्यायोजित करने के चरण दिखाने वाली एक वीडियो मार्गदर्शिका
+
+## Delegation Risks
+
+प्रोटोकॉल में प्रतिनिधि होने के मुख्य जोखिमों की सूची नीचे दी गई है।
+
+### The delegation tax
+
+प्रतिनिधियों को खराब व्यवहार के लिए कम नहीं किया जा सकता है, लेकिन खराब निर्णय लेने को हतोत्साहित करने के लिए प्रतिनिधियों पर एक कर है जो नेटवर्क की अखंडता को नुकसान पहुंचा सकता है।
+
+एक Delegator के रूप में, निम्नलिखित बातों को समझना महत्वपूर्ण है:
+
+- आपसे हर बार डेलीगेट करने पर 0.5% चार्ज किया जाएगा। इसका मतलब है कि यदि आप 1,000 GRT डेलीगेट करते हैं, तो आप स्वचालित रूप से 5 GRT बर्न कर देंगे।
+
+- सुरक्षित रहने के लिए, आपको Indexer को डेलीगेट करते समय अपने संभावित रिटर्न की गणना करनी चाहिए। उदाहरण के लिए, आप यह गणना कर सकते हैं कि आपके डेलीगेशन पर 0.5% कर वापस कमाने में कितने दिन लगेंगे।
+
+### प्रतिनिधिमंडल बंधन अवधि
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### यह क्यों महत्वपूर्ण है?
+
+यदि आप किसी ऐसे Indexer का चयन करते हैं जो विश्वसनीय नहीं है या अच्छा काम नहीं कर रहा है, तो आप डेलीगेट को रद्द करना चाहेंगे। इसका मतलब है कि आप पुरस्कार कमाने के कई अवसर खो देंगे, जो GRT को जलाने के समान बुरा हो सकता है। परिणामस्वरूप, यह अनुशंसा की जाती है कि आप एक Indexer का चयन समझदारी से करें।
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### डेलीगेटर्स के लिए उचित इनाम भुगतान के साथ एक भरोसेमंद इंडेक्सर चुनना
+
+एक विश्वसनीय Indexer को चुनने के लिए आपको डेलीगेशन पैरामीटर्स को समझना आवश्यक है।
+
+#### डेलीगेशन पैरामीटर
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - यदि किसी Indexer का पुरस्कार कट 100% पर सेट है, तो एक Delegator के रूप में, आपको 0 इंडेक्सिंग पुरस्कार मिलेंगे।
+  - यदि इसे 80% पर सेट किया गया है, तो एक Delegator के रूप में, आप 20% प्राप्त करेंगे।
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+यहाँ आप देख सकते हैं, सही Indexer चुनने के लिए, आपको कई चीजों पर विचार करना होगा।
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- बहुत से Indexers डिस्कॉर्ड में बहुत सक्रिय हैं और आपकी पूछताछ का जवाब देने में खुश होंगे।
+- उनमें से कई महीनों से इंडेक्सिंग कर रहे हैं, और वे Delegators को अच्छा लाभ कमाने में मदद करने के लिए अपना सर्वश्रेष्ठ कर रहे हैं, क्योंकि इससे नेटवर्क की स्वास्थ्य और सफलता में सुधार होता है।
+
+## यहाँ पर 'Delegators' की अपेक्षित लाभ की गणना की जा रही है।
+
+एक Delegator को एक वापसी निर्धारित करने के लिए निम्नलिखित कारकों पर विचार करना चाहिए:
+
+- एक Indexer की यह क्षमता है कि वह अपने पास उपलब्ध Delegated टोकन का उपयोग कर सके।
+  - यदि एक Indexer सभी उपलब्ध टोकन आवंटित नहीं कर रहा है, तो वे अपने लिए या अपने Delegators के लिए अधिकतम लाभ अर्जित नहीं कर रहे हैं।
+- पहले कुछ दिनों में डेलिगेटिंग पर ध्यान दें।
+  - एक Indexer किसी भी समय 1 से 28 दिनों के बीच एक आवंटन बंद करने और पुरस्कार एकत्र करने का विकल्प चुन सकता है। यह संभव है कि एक Indexer के पास अभी भी बहुत सारे पुरस्कार हों जिन्हें उन्हें एकत्र करना है, इसलिए उनके कुल पुरस्कार कम हो सकते हैं।
+
+### प्रश्न शुल्क में कटौती और अनुक्रमण शुल्क में कटौती को ध्यान में रखते हुए
+
+आपको एक ऐसा Indexer चुनना चाहिए जो अपनी क्वेरी शुल्क और इंडेक्सिंग शुल्क कटौती को निर्धारित करने में पारदर्शी और ईमानदार हो। इसके बाद, आप पैरामीटर्स कूलडाउन समय को देखना चाहिए कि आपके पास कितना समय बफर है। इसके बाद, अपने प्राप्त पुरस्कारों की गणना करना सरल है।
+
+सूत्र है:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### अनुक्रमणिका के प्रतिनिधिमंडल पूल को ध्यान में रखते हुए
+
+Delegators को प्रतिनिधि पूल में उनके स्वामित्व के अनुपात पर विचार करना चाहिए।
+
+सभी 'प्रतिनिधि पुरस्कार' समान रूप से साझा किए जाते हैं, और पूल में पुनर्संतुलन उस राशि के आधार पर होता है जो Delegator ने पूल में जमा की होती है।
+
+यह Delegator को पूल का हिस्सा देता है:
+
+![Share formula](/img/Share-Forumla.png)
+
+> उपरोक्त सूत्र यह दर्शाता है कि एक Indexer जो केवल 20% को Delegators को प्रदान कर रहा है, एक Indexer की तुलना में बेहतर पुरस्कार प्रदान कर सकता है जो 90% दे रहा है। बस गणना करें ताकि सर्वश्रेष्ठ पुरस्कार निर्धारित हो सके।
+
+### प्रतिनिधिमंडल की क्षमता को ध्यान में रखते हुए
+
+अंत में, प्राधिकरण क्षमता पर विचार करें। वर्तमान में, प्राधिकरण अनुपात 16 पर सेट है।
+
+#### यह क्यों मायने रखता है?
+
+यह मतलब है कि यदि एक Indexer ने 1,000,000 GRT स्टेक किया है, तो उनकी Delegation Capacity 16,000,000 GRT के अधिग्रहित टोकनों की है जिसका वे प्रोटोकॉल में उपयोग कर सकते हैं। इस मात्रा से अधिक कोई भी अधिग्रहित टोकन सभी Delegator पुरस्कारों को पतला कर देगा।
+
+एक Indexer के पास 100,000,000 GRT उनके लिए नामांकित हैं, लेकिन उनकी क्षमता केवल 16,000,000 GRT है। इसका मतलब है कि प्रभावी रूप से, 84,000,000 GRT टोकन उपयोग में नहीं हैं जिससे टोकन कमाई नहीं हो रही है। इसलिए, दोनों Delegators और Indexers उन पुरस्कारों को कम कमा रहे हैं जो वे कमा सकते थे।
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## प्रतिनिधि अक्सर पूछे जाने वाले प्रश्न और बग
+
+### मेटामास्क "लंबित लेन-देन" बग
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+MetaMask के माध्यम से Indexers को प्रतिनिधित्व देने के प्रयास कभी-कभी विफल हो सकते हैं और इसके परिणामस्वरूप "Pending" या "Queued" लेनदेन के प्रयासों के लिए लंबे समय तक रुकावट हो सकती है।
+
+#### उदाहरण
+
+अगर आप वर्तमान कीमतों के सापेक्ष अपर्याप्त गैस शुल्क के साथ डेलीगेट करने का प्रयास करते हैं।
+
+- यह क्रिया आपके MetaMask वॉलेट में लेनदेन के प्रयास को "Pending" के रूप में 15+ मिनट तक प्रदर्शित कर सकती है। जब ऐसा होता है, तो आप बाद के लेनदेन करने का प्रयास कर सकते हैं, लेकिन ये केवल तब तक संसाधित होंगे जब तक प्रारंभिक लेनदेन खनन नहीं किया गया है, क्योंकि किसी पते के लिए लेनदेन को क्रम में संसाधित करना आवश्यक है।
+- इस प्रकार के मामलों में, इन लेनदेन को MetaMask में रद्द किया जा सकता है, लेकिन लेनदेन के प्रयास गैस शुल्क को जमा करेंगे बिना यह गारंटी कि बाद के प्रयास सफल होंगे।
+
+इस बग का एक सरल समाधान ब्राउज़र को पुनः प्रारंभ करना है (उदाहरण के लिए, पता बार में "abort
+" का उपयोग करना), जो सभी पिछले प्रयासों को रद्द कर देगा बिना गैस को वॉलेट से घटाए। कई उपयोगकर्ताओं ने जिन्होंने इस समस्या का सामना किया है, उन्होंने अपने ब्राउज़र को पुनः प्रारंभ करने और 'delegation' करने का प्रयास करने के बाद सफल लेनदेन की रिपोर्ट की है।
+
+## वीडियो गाइड
+
+इस वीडियो गाइड इस पृष्ठ की समीक्षा करता है जबकि UI के साथ बातचीत करता है।
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 7010763723ba4ea7bbaf6f069d5d2bcdfa9a0aa8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:30 -0500
Subject: [PATCH 1351/3820] New translations delegating.mdx (Swahili)

---
 .../pages/sw/resources/roles/delegating.mdx   | 141 ++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 website/pages/sw/resources/roles/delegating.mdx

diff --git a/website/pages/sw/resources/roles/delegating.mdx b/website/pages/sw/resources/roles/delegating.mdx
new file mode 100644
index 000000000000..eda60369e00a
--- /dev/null
+++ b/website/pages/sw/resources/roles/delegating.mdx
@@ -0,0 +1,141 @@
+---
+title: Delegating
+---
+
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+
+- They help secure the network without running a Graph Node themselves.
+
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+
+## How does this work?
+
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+
+## Delegator Guide
+
+Learn how to be an effective Delegator in The Graph Network.
+
+Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+
+> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+
+There are three sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+- A video guide showing the steps to delegate in the Graph Network UI
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The delegation tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The delegation unbonding period
+
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+#### Delegation Parameters
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+As you can see, in order to choose the right Indexer, you must consider multiple things.
+
+- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
+- Many Indexers are very active in Discord and will be happy to answer your questions.
+- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+
+## Calculating Delegators Expected Return
+
+A Delegator must consider the following factors to determine a return:
+
+- Consider an Indexer's ability to use the Delegated tokens available to them.
+  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
+- Pay attention to the first few days of delegating.
+  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+### Considering the delegation capacity
+
+Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+
+#### Why does this matter?
+
+This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+
+Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+
+Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+
+## Video Guide
+
+This video guide reviews this page while interacting with the UI.
+
+<VideoEmbed youtube="2G7S2gdURdc" />

From 921247f347c9e3e7d29edf541a24cd706a1276b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:31 -0500
Subject: [PATCH 1352/3820] New translations tokenomics.mdx (Romanian)

---
 website/pages/ro/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/ro/resources/tokenomics.mdx

diff --git a/website/pages/ro/resources/tokenomics.mdx b/website/pages/ro/resources/tokenomics.mdx
new file mode 100644
index 000000000000..f9c7dda46ce3
--- /dev/null
+++ b/website/pages/ro/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics of The Graph Network
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Overview
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curators - Find the best subgraphs for Indexers
+
+3. Developers - Build & query subgraphs
+
+4. Indexers - Backbone of blockchain data
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Creating a subgraph
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Querying an existing subgraph
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 97d33d5f4cd21674ae355def0e131ee00ce39793 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:32 -0500
Subject: [PATCH 1353/3820] New translations tokenomics.mdx (French)

---
 website/pages/fr/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/fr/resources/tokenomics.mdx

diff --git a/website/pages/fr/resources/tokenomics.mdx b/website/pages/fr/resources/tokenomics.mdx
new file mode 100644
index 000000000000..8b52c831c858
--- /dev/null
+++ b/website/pages/fr/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Les tokenomiques du réseau The Graph
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Aperçu
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Spécificités⁠
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curateurs - Trouver les meilleurs subgraphs pour les indexeurs
+
+3. Developers - Build & query subgraphs
+
+4. Indexeurs - épine dorsale des données de la blockchain
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Création d'un subgraph
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Interroger un subgraph existant
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 678a9855bac2ce54ab4977b10155147a45fb9ad3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:33 -0500
Subject: [PATCH 1354/3820] New translations tokenomics.mdx (Spanish)

---
 website/pages/es/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/es/resources/tokenomics.mdx

diff --git a/website/pages/es/resources/tokenomics.mdx b/website/pages/es/resources/tokenomics.mdx
new file mode 100644
index 000000000000..98016d9456c7
--- /dev/null
+++ b/website/pages/es/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics de The Graph Network
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Descripción
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curadores - Encuentran los mejores subgrafos para los Indexadores
+
+3. Developers - Build & query subgraphs
+
+4. Indexadores: Son la columna vertebral de los datos de la blockchain
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Creación de un subgrafo
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Consulta de un subgrafo existente
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 816c078b35a12f3d1babbcf52595f6c5e6b8d3ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:34 -0500
Subject: [PATCH 1355/3820] New translations tokenomics.mdx (Arabic)

---
 website/pages/ar/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/ar/resources/tokenomics.mdx

diff --git a/website/pages/ar/resources/tokenomics.mdx b/website/pages/ar/resources/tokenomics.mdx
new file mode 100644
index 000000000000..46c28d19e926
--- /dev/null
+++ b/website/pages/ar/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: اقتصاد التوكن (Tokenomics) لشبكة الغراف
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## نظره عامة
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. المنسقون (Curators) - يبحثون عن أفضل subgraphs للمفهرسين
+
+3. Developers - Build & query subgraphs
+
+4. المفهرسون (Indexers) - العمود الفقري لبيانات blockchain
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### إنشاء subgraph
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### الاستعلام عن subgraph موجود
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 229b8c9f0a32751ff8eb5faa15a579f655dbe211 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:35 -0500
Subject: [PATCH 1356/3820] New translations tokenomics.mdx (Czech)

---
 website/pages/cs/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/cs/resources/tokenomics.mdx

diff --git a/website/pages/cs/resources/tokenomics.mdx b/website/pages/cs/resources/tokenomics.mdx
new file mode 100644
index 000000000000..10ce61c54a15
--- /dev/null
+++ b/website/pages/cs/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics sítě grafů
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Přehled
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Kurátoři - nalezení nejlepších podgrafů pro indexátory
+
+3. Developers - Build & query subgraphs
+
+4. Indexery - páteř blockchainových dat
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Vytvoření podgrafu
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Dotazování na existující podgraf
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 8b3a790353b949a4bca75b5fe7acff76dc408fbf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:36 -0500
Subject: [PATCH 1357/3820] New translations tokenomics.mdx (German)

---
 website/pages/de/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/de/resources/tokenomics.mdx

diff --git a/website/pages/de/resources/tokenomics.mdx b/website/pages/de/resources/tokenomics.mdx
new file mode 100644
index 000000000000..ad73a800a803
--- /dev/null
+++ b/website/pages/de/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics des The Graph Netzwerks
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Overview
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Besonderheiten
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Kuratoren - Finden Sie die besten Untergraphen für Indexer
+
+3. Developers - Build & query subgraphs
+
+4. Indexer - Das Rückgrat der Blockchain-Daten
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Erstellung eines Untergraphen
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Abfrage eines vorhandenen Untergraphen
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 50b2edc1622cfdb6d20d3634aea9955b926eef8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:37 -0500
Subject: [PATCH 1358/3820] New translations tokenomics.mdx (Italian)

---
 website/pages/it/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/it/resources/tokenomics.mdx

diff --git a/website/pages/it/resources/tokenomics.mdx b/website/pages/it/resources/tokenomics.mdx
new file mode 100644
index 000000000000..b9813072b0f1
--- /dev/null
+++ b/website/pages/it/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics di The Graph Network
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Panoramica
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curator - Trovare i migliori subgraph per gli Indexer
+
+3. Developers - Build & query subgraphs
+
+4. Indexer - Struttura portante dei dati della blockchain
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Creare un subgraph
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Eseguire query di un subgraph esistente
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 633d769f17df826f3d9cdb95e10fb183804059d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:38 -0500
Subject: [PATCH 1359/3820] New translations tokenomics.mdx (Japanese)

---
 website/pages/ja/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/ja/resources/tokenomics.mdx

diff --git a/website/pages/ja/resources/tokenomics.mdx b/website/pages/ja/resources/tokenomics.mdx
new file mode 100644
index 000000000000..c793850666e7
--- /dev/null
+++ b/website/pages/ja/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: グラフネットワークのトークノミクス
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## 概要
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. キュレーター - インデクサーのために最適なサブグラフを見つける。
+
+3. Developers - Build & query subgraphs
+
+4. インデクサー - ブロックチェーンデータのバックボーン
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### サブグラフの作成
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### 既存のサブグラフのクエリ
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From b943b974a9e83a49e0e8927313bddd0f87b438a8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:39 -0500
Subject: [PATCH 1360/3820] New translations tokenomics.mdx (Korean)

---
 website/pages/ko/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/ko/resources/tokenomics.mdx

diff --git a/website/pages/ko/resources/tokenomics.mdx b/website/pages/ko/resources/tokenomics.mdx
new file mode 100644
index 000000000000..f9c7dda46ce3
--- /dev/null
+++ b/website/pages/ko/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics of The Graph Network
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Overview
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curators - Find the best subgraphs for Indexers
+
+3. Developers - Build & query subgraphs
+
+4. Indexers - Backbone of blockchain data
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Creating a subgraph
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Querying an existing subgraph
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From b81f35f04ee4c51da4764800d61b1fd426d1fc61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:40 -0500
Subject: [PATCH 1361/3820] New translations tokenomics.mdx (Dutch)

---
 website/pages/nl/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/nl/resources/tokenomics.mdx

diff --git a/website/pages/nl/resources/tokenomics.mdx b/website/pages/nl/resources/tokenomics.mdx
new file mode 100644
index 000000000000..f9c7dda46ce3
--- /dev/null
+++ b/website/pages/nl/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics of The Graph Network
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Overview
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curators - Find the best subgraphs for Indexers
+
+3. Developers - Build & query subgraphs
+
+4. Indexers - Backbone of blockchain data
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Creating a subgraph
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Querying an existing subgraph
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 76fb736afba24f35111b6d4cc799f92c046ff1d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:41 -0500
Subject: [PATCH 1362/3820] New translations tokenomics.mdx (Polish)

---
 website/pages/pl/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/pl/resources/tokenomics.mdx

diff --git a/website/pages/pl/resources/tokenomics.mdx b/website/pages/pl/resources/tokenomics.mdx
new file mode 100644
index 000000000000..f9c7dda46ce3
--- /dev/null
+++ b/website/pages/pl/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics of The Graph Network
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Overview
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curators - Find the best subgraphs for Indexers
+
+3. Developers - Build & query subgraphs
+
+4. Indexers - Backbone of blockchain data
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Creating a subgraph
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Querying an existing subgraph
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 5205dd20637b9a2c71ce661a9d603e993f24c83e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:42 -0500
Subject: [PATCH 1363/3820] New translations tokenomics.mdx (Portuguese)

---
 website/pages/pt/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/pt/resources/tokenomics.mdx

diff --git a/website/pages/pt/resources/tokenomics.mdx b/website/pages/pt/resources/tokenomics.mdx
new file mode 100644
index 000000000000..53ffc18bfee5
--- /dev/null
+++ b/website/pages/pt/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomia da Graph Network
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Visão geral
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Especificações
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curadores — Encontram os melhores subgraphs para Indexadores
+
+3. Developers - Build & query subgraphs
+
+4. Indexadores — Rede de transporte de dados em blockchain
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Como criar um Subgraph
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Como fazer queries um Subgraph existente
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 6ec1051ed2985d42c6575264b5a503ce833f354f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:43 -0500
Subject: [PATCH 1364/3820] New translations tokenomics.mdx (Russian)

---
 website/pages/ru/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/ru/resources/tokenomics.mdx

diff --git a/website/pages/ru/resources/tokenomics.mdx b/website/pages/ru/resources/tokenomics.mdx
new file mode 100644
index 000000000000..041c7aff24b5
--- /dev/null
+++ b/website/pages/ru/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Токеномика сети The Graph
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Обзор
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Специфические особенности
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Кураторы - Ищут лучшие субграфы для Индексаторов
+
+3. Developers - Build & query subgraphs
+
+4. Индексаторы - Магистральный канал передачи данных блокчейна
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Создание субграфа
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Запрос к существующему субграфу
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 54184a27e23b0ee977385a8c67f21df361378aae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:44 -0500
Subject: [PATCH 1365/3820] New translations tokenomics.mdx (Swedish)

---
 website/pages/sv/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/sv/resources/tokenomics.mdx

diff --git a/website/pages/sv/resources/tokenomics.mdx b/website/pages/sv/resources/tokenomics.mdx
new file mode 100644
index 000000000000..b9d546c3082a
--- /dev/null
+++ b/website/pages/sv/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics för The Graf Nätverk
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Översikt
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Kuratorer - Hitta de bästa subgrafterna för Indexers
+
+3. Developers - Build & query subgraphs
+
+4. Indexers - Grundvalen för blockkedjedata
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Skapa en subgraf
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Fråga en befintlig subgraf
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From a1e7085a914da2cbb2c39dc358c8b8f65d8c8414 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:45 -0500
Subject: [PATCH 1366/3820] New translations tokenomics.mdx (Turkish)

---
 website/pages/tr/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/tr/resources/tokenomics.mdx

diff --git a/website/pages/tr/resources/tokenomics.mdx b/website/pages/tr/resources/tokenomics.mdx
new file mode 100644
index 000000000000..758d42ef8a37
--- /dev/null
+++ b/website/pages/tr/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics of The Graph Network
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Genel Bakış
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Ayrıntılar
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curators - Find the best subgraphs for Indexers
+
+3. Developers - Build & query subgraphs
+
+4. Indexers - Backbone of blockchain data
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Subgraph oluşturma
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Mevcut bir subgraph'ı sorgulama
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 1cf93755071f60d94cb841032d81ef54dcd10f84 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:46 -0500
Subject: [PATCH 1367/3820] New translations tokenomics.mdx (Ukrainian)

---
 website/pages/uk/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/uk/resources/tokenomics.mdx

diff --git a/website/pages/uk/resources/tokenomics.mdx b/website/pages/uk/resources/tokenomics.mdx
new file mode 100644
index 000000000000..c37dd3e8caf8
--- /dev/null
+++ b/website/pages/uk/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Токеноміка мережі The Graph
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Overview
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Куратори - знаходять найкращі підграфи для індексаторів
+
+3. Developers - Build & query subgraphs
+
+4. Індексатори - кістяк блокчейн-даних
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Creating a subgraph
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Querying an existing subgraph
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 6b05788375ea42c2f7397f899ae9f91a3de498ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:47 -0500
Subject: [PATCH 1368/3820] New translations tokenomics.mdx (Chinese
 Simplified)

---
 website/pages/zh/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/zh/resources/tokenomics.mdx

diff --git a/website/pages/zh/resources/tokenomics.mdx b/website/pages/zh/resources/tokenomics.mdx
new file mode 100644
index 000000000000..f9977252fef3
--- /dev/null
+++ b/website/pages/zh/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Graph网络的代币经济学
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## 概述
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. 策展人-为索引人找到最佳子图
+
+3. Developers - Build & query subgraphs
+
+4. 索引人-区块链数据的主干
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### 创建子图
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### 查询现存子图
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 9df4edb6f3347b5af9cf148f543d514281cbe9eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:48 -0500
Subject: [PATCH 1369/3820] New translations tokenomics.mdx (Urdu (Pakistan))

---
 website/pages/ur/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/ur/resources/tokenomics.mdx

diff --git a/website/pages/ur/resources/tokenomics.mdx b/website/pages/ur/resources/tokenomics.mdx
new file mode 100644
index 000000000000..2cb50ba0c791
--- /dev/null
+++ b/website/pages/ur/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: گراف نیٹ ورک کے ٹوکنومکس
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## جائزہ
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. کیوریٹرز - انڈیکسرز کے لیے بہترین سب گراف تلاش کریں
+
+3. Developers - Build & query subgraphs
+
+4. انڈیکسرز - بلاکچین ڈیٹا کی ریڑھ کی ہڈی
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### سب گراف بنائیں
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### موجودہ سب گراف کو کیوری کریں
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 76d404816ca678d58361022d6c597f072122420b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:49 -0500
Subject: [PATCH 1370/3820] New translations tokenomics.mdx (Vietnamese)

---
 website/pages/vi/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/vi/resources/tokenomics.mdx

diff --git a/website/pages/vi/resources/tokenomics.mdx b/website/pages/vi/resources/tokenomics.mdx
new file mode 100644
index 000000000000..08008893010d
--- /dev/null
+++ b/website/pages/vi/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics of The Graph Network
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Tổng quan
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curators - Find the best subgraphs for Indexers
+
+3. Developers - Build & query subgraphs
+
+4. Indexers - Backbone of blockchain data
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Creating a subgraph
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Querying an existing subgraph
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 1ab99eb79fca48b2ce0d569538c74c5f25b7a315 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:51 -0500
Subject: [PATCH 1371/3820] New translations tokenomics.mdx (Marathi)

---
 website/pages/mr/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/mr/resources/tokenomics.mdx

diff --git a/website/pages/mr/resources/tokenomics.mdx b/website/pages/mr/resources/tokenomics.mdx
new file mode 100644
index 000000000000..ef95231c29d7
--- /dev/null
+++ b/website/pages/mr/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: ग्राफ नेटवर्कचे टोकनॉमिक्स
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## सविश्लेषण
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. क्युरेटर - इंडेक्सर्ससाठी सर्वोत्तम सबग्राफ शोधा
+
+3. Developers - Build & query subgraphs
+
+4. इंडेक्सर्स - ब्लॉकचेन डेटाचा कणा
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### सबग्राफ तयार करणे
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### विद्यमान सबग्राफची चौकशी करत आहे
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 5fa5ffed69c32b3fb15c25db89fa8a0ed3470b2d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:51 -0500
Subject: [PATCH 1372/3820] New translations tokenomics.mdx (Hindi)

---
 website/pages/hi/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/hi/resources/tokenomics.mdx

diff --git a/website/pages/hi/resources/tokenomics.mdx b/website/pages/hi/resources/tokenomics.mdx
new file mode 100644
index 000000000000..4a0b60ee9ad9
--- /dev/null
+++ b/website/pages/hi/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: ग्राफ नेटवर्क के टोकनोमिक्स
+description: The Graph Network को शक्तिशाली टोकनोमिक्स द्वारा प्रोत्साहित किया जाता है। यहां बताया गया है कि GRT, The Graph का मूल कार्य उपयोगिता टोकन, कैसे काम करता है।
+---
+
+## अवलोकन
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## विशिष्टताएँ
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curators - Find the best subgraphs for Indexers
+
+3. Developers - Build & query subgraphs
+
+4. इंडेक्सर्स - ब्लॉकचेन डेटा की रीढ़
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### सबग्राफ बनाना
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### किसी मौजूदा सबग्राफ को क्वेरी करना
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 3d333b349e1ba833de6c0671adac1972a8b98fd7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:52 -0500
Subject: [PATCH 1373/3820] New translations tokenomics.mdx (Swahili)

---
 website/pages/sw/resources/tokenomics.mdx | 102 ++++++++++++++++++++++
 1 file changed, 102 insertions(+)
 create mode 100644 website/pages/sw/resources/tokenomics.mdx

diff --git a/website/pages/sw/resources/tokenomics.mdx b/website/pages/sw/resources/tokenomics.mdx
new file mode 100644
index 000000000000..f9c7dda46ce3
--- /dev/null
+++ b/website/pages/sw/resources/tokenomics.mdx
@@ -0,0 +1,102 @@
+---
+title: Tokenomics of The Graph Network
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+---
+
+## Overview
+
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+
+## Specifics
+
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+
+## The Roles of Network Participants
+
+There are four primary network participants:
+
+1. Delegators - Delegate GRT to Indexers & secure the network
+
+2. Curators - Find the best subgraphs for Indexers
+
+3. Developers - Build & query subgraphs
+
+4. Indexers - Backbone of blockchain data
+
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
+
+## Delegators (Passively earn GRT)
+
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+
+## Curators (Earn GRT)
+
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+
+## Developers
+
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+
+### Creating a subgraph
+
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+
+### Querying an existing subgraph
+
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+
+1% of the query fees paid to the network are burned.
+
+## Indexers (Earn GRT)
+
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+
+Indexers can earn GRT rewards in two ways:
+
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+
+## Token Supply: Burning & Issuance
+
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+
+![Total burned GRT](/img/total-burned-grt.jpeg)
+
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+
+## Improving the Protocol
+
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 6bb697a1b3e927435c94cb0dec329dcdbb399302 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:54 -0500
Subject: [PATCH 1374/3820] New translations billing.mdx (Romanian)

---
 website/pages/ro/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/billing.mdx

diff --git a/website/pages/ro/subgraphs/billing.mdx b/website/pages/ro/subgraphs/billing.mdx
new file mode 100644
index 000000000000..55e8f4dc762b
--- /dev/null
+++ b/website/pages/ro/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Billing
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Add and withdraw GRT from your account balance.
+- Keep track of your balances based on how much GRT you have added to your account balance, how much you have removed, and your invoices.
+- Automatically pay invoices based on query fees generated, as long as there is enough GRT in your account balance.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Adding GRT using a multisig wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From bc52213ec399481403f92af1367158456f755cbb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:55 -0500
Subject: [PATCH 1375/3820] New translations billing.mdx (French)

---
 website/pages/fr/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/billing.mdx

diff --git a/website/pages/fr/subgraphs/billing.mdx b/website/pages/fr/subgraphs/billing.mdx
new file mode 100644
index 000000000000..72324e599899
--- /dev/null
+++ b/website/pages/fr/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Facturation
+---
+
+## Querying Plans
+
+Il y a deux plans à utiliser lorsqu'on interroge les subgraphs sur le réseau de The Graph.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Paiements de Requêtes avec Carte de Crédit⁠
+
+- Pour mettre en place la facturation par carte de crédit/débit, les utilisateurs doivent accéder à Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Cliquez sur le bouton "Connecter le portefeuille" dans le coin supérieur droit de la page. Vous serez redirigé vers la page de sélection des portefeuilles. Sélectionnez votre portefeuille et cliquez sur "Connecter".
+  3. Choisissez « Mettre à niveau votre abonnement » si vous effectuez une mise à niveau depuis le plan gratuit, ou choisissez « Gérer l'abonnement » si vous avez déjà ajouté des GRT à votre solde de facturation par le passé. Ensuite, vous pouvez estimer le nombre de requêtes pour obtenir une estimation du prix, mais ce n'est pas une étape obligatoire.
+  4. Pour choisir un paiement par carte de crédit, choisissez “Credit card” comme mode de paiement et remplissez les informations de votre carte de crédit. Ceux qui ont déjà utilisé Stripe peuvent utiliser la fonctionnalité Link pour remplir automatiquement leurs informations.
+- Les factures seront traitées à la fin de chaque mois et nécessitent une carte de crédit valide enregistrée sur votre compte pour toute requête au-delà du quota du plan gratuit.
+
+## Paiements de Requêtes avec du GRT
+
+Les utilisateurs de subgraphs peuvent utiliser le jeton natif de The Graph (GRT) pour payer les requêtes sur le réseau The Graph. Avec le GRT, les factures seront traitées à la fin de chaque mois et nécessiteront un solde suffisant de GRT pour effectuer des requêtes au-delà du quota du plan gratuit de 100 000 requêtes mensuelles. Vous devrez payer les frais générés par vos clés API. En utilisant le contrat de facturation, vous pourrez :
+
+- Ajoutez et retirez du GRT du solde de votre compte.
+- Gardez une trace de vos soldes en fonction du montant de GRT que vous avez ajouté au solde de votre compte, du montant que vous avez supprimé et de vos factures.
+- Payez automatiquement les factures en fonction des frais de requête générés, à condition qu'il y ait suffisamment de GRT dans le solde de votre compte.
+
+### GRT sur Arbitrum ou Ethereum
+
+Le système de facturation de The Graph accepte le GRT sur Arbitrum, et les utilisateurs auront besoin d'ETH sur Arbitrum pour payer leurs frais de gaz. Bien que le protocole The Graph ait commencé sur Ethereum Mainnet, toute l'activité, y compris les contrats de facturation, est maintenant sur Arbitrum One.
+
+L'utilisation du GRT sur Arbitrum est nécessaire pour le paiement des requêtes. Voici quelques options pour en acquérir :
+
+- Si vous avez déjà des GRT sur Ethereum, vous pouvez les bridge vers Arbitrum. Vous pouvez le faire via l'option de bridge de GRT fournie dans Subgraph Studio ou en utilisant l'un des bridges suivants :
+
+- [Le Bridge Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- Si vous possédez déjà des actifs sur Arbitrum, vous pouvez les échanger contre du GRT via un protocole d'échange comme Uniswap.
+
+- Alternativement, vous pouvez acquérir du GRT directement sur Arbitrum via un échange décentralisé.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Une fois que vous avez transféré du GRT, vous pouvez l'ajouter à votre solde de facturation.
+
+### Ajout de GRT à l'aide d'un portefeuille
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Cliquez sur le bouton "Connecter le portefeuille" dans le coin supérieur droit de la page. Vous serez redirigé vers la page de sélection des portefeuilles. Sélectionnez votre portefeuille et cliquez sur "Connecter".
+3. Cliquez sur le bouton « Manage » situé dans le coin supérieur droit. Les nouveaux utilisateurs verront l'option « Upgrade to Growth plan » (Passer au plan de croissance), tandis que les utilisateurs existants devront sélectionner « Deposit from wallet » (Déposer depuis le portefeuille).
+4. Utilisez le curseur pour estimer le nombre de requêtes que vous prévoyez d’effectuer sur une base mensuelle.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choisissez "Cryptocurrency". Le GRT est actuellement la seule cryptomonnaie acceptée sur le réseau The Graph.
+6. Sélectionnez le nombre de mois pour lesquels vous souhaitez effectuer un paiement anticipé.
+   - Le paiement anticipé ne vous engage pas sur une utilisation future. Vous ne serez facturé que pour ce que vous utiliserez et vous pourrez retirer votre solde à tout moment.
+7. Choisissez le réseau à partir duquel vous déposez vos GRT. Les GRT sur Arbitrum ou Ethereum sont tous deux acceptables.
+8. Cliquez sur "Autoriser l'accès au GRT" puis spécifiez le montant de GRT qui peut être prélevé de votre portefeuille.
+   - Si vous payez à l'avance pour plusieurs mois, vous devez autoriser l'accès au montant correspondant. Cette interaction ne coûtera aucun gaz.
+9. Enfin, cliquez sur « Add GRT to Billing Balance ». Cette transaction nécessitera des ETH sur Arbitrum pour couvrir les coûts du gaz.
+
+- Notez que les GRT déposés depuis Arbitrum seront traités en quelques instants tandis que les GRT déposés depuis Ethereum prendront environ 15-20 minutes pour être traités. Une fois la transaction confirmée, vous verrez les GRT ajoutés à votre solde de compte.
+
+### Retirer des GRT en utilisant un portefeuille
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Cliquez sur le bouton "Connect Wallet" dans le coin supérieur droit de la page. Sélectionnez votre portefeuille et cliquez sur "Connect".
+3. Cliquez sur le bouton « Gérer » dans le coin supérieur droit de la page. Sélectionnez « Retirer des GRT ». Un panneau latéral apparaîtra.
+4. Entrez le montant de GRT que vous voudriez retirer.
+5. Cliquez 'Withdraw GRT' pour retirer les GRT de votre solde de compte. Signez la transaction associée dans votre portefeuille. Cela coûtera du gaz. Les GRT seront envoyés à votre portefeuille Arbitrum.
+6. Une fois que la transaction est confirmée, vous verrez le GRT qu'on a retiré de votre solde du compte dans votre portefeuille Arbitrum.
+
+### Ajout de GRT à l'aide d'un portefeuille multisig
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Cliquez sur le bouton « Manage » situé dans le coin supérieur droit. Les nouveaux utilisateurs verront l'option « Upgrade to Growth plan » (Passer au plan de croissance), tandis que les utilisateurs existants devront sélectionner « Deposit from wallet » (Déposer depuis le portefeuille).
+4. Utilisez le curseur pour estimer le nombre de requêtes que vous prévoyez d’effectuer sur une base mensuelle.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choisissez "Cryptocurrency". Le GRT est actuellement la seule cryptomonnaie acceptée sur le réseau The Graph.
+6. Sélectionnez le nombre de mois pour lesquels vous souhaitez effectuer un paiement anticipé.
+   - Le paiement anticipé ne vous engage pas sur une utilisation future. Vous ne serez facturé que pour ce que vous utiliserez et vous pourrez retirer votre solde à tout moment.
+7. Choisissez le réseau à partir duquel vous déposez vos GRT. Les GRT sur Arbitrum ou Ethereum, les deux sont acceptables. 8. Cliquez sur "Allow GRT Access", et puis spécifiez le montant de GRT qui peut être prélevé de votre portefeuille.
+   - Si vous payez à l'avance pour plusieurs mois, vous devez autoriser l'accès au montant correspondant. Cette interaction ne coûtera aucun gaz.
+8. Enfin, cliquez sur « Add GRT to Billing Balance ». Cette transaction nécessitera des ETH sur Arbitrum pour couvrir les coûts du gaz.
+
+- Notez que les GRT déposés depuis Arbitrum seront traités en quelques instants tandis que les GRT déposés depuis Ethereum prendront environ 15-20 minutes pour être traités. Une fois la transaction confirmée, vous verrez les GRT ajoutés à votre solde de compte.
+
+## Obtenir du GRT
+
+Cette section vous montrera comment obtenir du GRT pour payer les frais de requête.
+
+### Coinbase
+
+Voici un guide étape par étape pour acheter de GRT sur Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Dès que vous aurez créé un compte, vous devrez vérifier votre identité par le biais d'un processus connu sous le nom de KYC (Know Your Customer ou Connaître Votre Client). Il s'agit d'une procédure standard pour toutes les plateformes d'échange de crypto-monnaies centralisées ou dépositaires.
+3. Une fois votre identité vérifiée, vous pouvez acheter des GRT. Pour ce faire, cliquez sur le bouton « Acheter/Vendre » en haut à droite de la page.
+4. Sélectionnez la devise que vous souhaitez acheter. Sélectionnez GRT.
+5. Sélectionnez le mode de paiement. Sélectionnez votre mode de paiement préféré.
+6. Sélectionnez la quantité de GRT que vous souhaitez acheter.
+7. Vérifiez votre achat. Vérifiez votre achat et cliquez sur "Buy GRT".
+8. Confirmez votre achat. Confirmez votre achat et vous aurez acheté des GRT avec succès.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - Pour transférer les GRT dans votre portefeuille, cliquez sur le bouton "Accounts" en haut à droite de la page.
+   - Cliquez sur le bouton "Send" à côté du compte GRT.
+   - Entrez le montant de GRT que vous souhaitez envoyer et l'adresse du portefeuille vers laquelle vous souhaitez l'envoyer.
+   - Cliquez sur "Continue" et confirmez votre transaction. -Veuillez noter que pour des montants d'achat plus importants, Coinbase peut vous demander d'attendre 7 à 10 jours avant de transférer le montant total vers un portefeuille.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+Ceci est un guide étape par étape pour l'achat des GRT sur Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Dès que vous aurez créé un compte, vous devrez vérifier votre identité par le biais d'un processus connu sous le nom de KYC (Know Your Customer ou Connaître Votre Client). Il s'agit d'une procédure standard pour toutes les plateformes d'échange de crypto-monnaies centralisées ou dépositaires.
+3. Une fois votre identité vérifiée, vous pouvez acheter des GRT. Pour ce faire, cliquez sur le bouton « Acheter maintenant » sur la bannière de la page d'accueil.
+4. Vous accéderez à une page où vous pourrez sélectionner la devise que vous souhaitez acheter. Sélectionnez GRT.
+5. Choisissez votre mode de paiement préféré. Vous pourrez payer avec différentes devises fiduciaires telles que l'euro, le dollar américain, etc.
+6. Sélectionnez la quantité de GRT que vous souhaitez acheter.
+7. Confirmez votre achat et cliquez sur « Acheter des GRT ».
+8. Confirmez votre achat et vous pourrez voir vos GRT dans votre portefeuille Binance Spot.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Cliquez sur le bouton « portefeuille », cliquez sur retrait et sélectionnez GRT.
+   - Saisissez le montant de GRT que vous souhaitez envoyer et l'adresse du portefeuille sur liste blanche à laquelle vous souhaitez l'envoyer.
+   - Cliquer sur « Continuer » et confirmez votre transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+Voici comment vous pouvez acheter des GRT sur Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Sélectionnez le jeton dont vous souhaitez échanger. Sélectionnez ETH.
+3. Sélectionnez le jeton vers lequel vous souhaitez échanger. Sélectionnez GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Entrez le montant d'ETH que vous souhaitez échanger.
+5. Cliquez sur « Échanger ».
+6. Confirmez la transaction dans votre portefeuille et attendez qu'elle soit traitée.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Obtenir de l'Ether⁠
+
+Cette section vous montrera comment obtenir de l'Ether (ETH) pour payer les frais de transaction ou les coûts de gaz. L'ETH est nécessaire pour exécuter des opérations sur le réseau Ethereum telles que le transfert de jetons ou l'interaction avec des contrats.
+
+### Coinbase
+
+Ce sera un guide étape par étape pour acheter de l'ETH sur Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Une fois que vous avez créé un compte, vérifiez votre identité via un processus appelé KYC (ou Know Your Customer). l s'agit d'une procédure standard pour toutes les plateformes d'échange de crypto-monnaies centralisées ou dépositaires.
+3. Une fois que vous avez vérifié votre identité, achetez de l'ETH en cliquant sur le bouton « Acheter/Vendre » en haut à droite de la page.
+4. Choisissez la devise que vous souhaitez acheter. Sélectionnez ETH.
+5. Sélectionnez votre mode de paiement préféré.
+6. Entrez le montant d'ETH que vous souhaitez acheter.
+7. Vérifiez votre achat et cliquez sur « Acheter des Ethereum ».
+8. Confirmez votre achat et vous aurez acheté avec succès de l'ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - Pour transférer l'ETH vers votre portefeuille, cliquez sur le bouton « Comptes » en haut à droite de la page.
+   - Cliquez sur le bouton « Envoyer » à côté du compte ETH.
+   - Entrez le montant d'ETH que vous souhaitez envoyer et l'adresse du portefeuille vers lequel vous souhaitez l'envoyer.
+   - Assurez-vous que vous envoyez à votre adresse de portefeuille Ethereum sur Arbitrum One.
+   - Cliquer sur « Continuer » et confirmez votre transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+Ce sera un guide étape par étape pour acheter des ETH sur Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Une fois que vous avez créé un compte, vérifiez votre identité via un processus appelé KYC (ou Know Your Customer). l s'agit d'une procédure standard pour toutes les plateformes d'échange de crypto-monnaies centralisées ou dépositaires.
+3. Une fois que vous avez vérifié votre identité, achetez des ETH en cliquant sur le bouton « Acheter maintenant » sur la bannière de la page d'accueil.
+4. Choisissez la devise que vous souhaitez acheter. Sélectionnez ETH.
+5. Sélectionnez votre mode de paiement préféré.
+6. Entrez le montant d'ETH que vous souhaitez acheter.
+7. Vérifiez votre achat et cliquez sur « Acheter des Ethereum ».
+8. Confirmez votre achat et vous verrez votre ETH dans votre portefeuille Binance Spot.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - Pour retirer l'ETH vers votre portefeuille, ajoutez l'adresse de votre portefeuille à la liste blanche de retrait.
+   - Cliquez sur le bouton « portefeuille », cliquez sur retirer et sélectionnez ETH.
+   - Entrez le montant d'ETH que vous souhaitez envoyer et l'adresse du portefeuille sur liste blanche à laquelle vous souhaitez l'envoyer.
+   - Assurez-vous que vous envoyez à votre adresse de portefeuille Ethereum sur Arbitrum One.
+   - Cliquer sur « Continuer » et confirmez votre transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## FAQ sur la facturation
+
+### De combien de requêtes aurai-je besoin ?
+
+Vous n'avez pas besoin de savoir à l'avance combien de requêtes vous aurez besoin. Vous ne serez facturé que pour ce que vous utilisez et vous pourrez retirer des GRT de votre compte à tout moment.
+
+Nous vous recommandons de surestimer le nombre de requêtes dont vous aurez besoin afin de ne pas avoir à recharger votre solde fréquemment. Pour les applications de petite et moyenne taille, une bonne estimation consiste à commencer par 1 à 2 millions de requêtes par mois et à surveiller de près l'utilisation au cours des premières semaines. Pour les applications plus grandes, une bonne estimation consiste à utiliser le nombre de visites quotidiennes que reçoit votre site multiplié par le nombre de requêtes que votre page la plus active effectue à son ouverture.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Puis-je retirer du GRT de mon solde de facturation ?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### Que se passe-t-il lorsque mon solde de facturation est épuisé ? Vais-je recevoir un avertissement ?
+
+Vous recevrez plusieurs notifications par e-mail avant que votre solde de facturation ne soit épuisé.

From 028a89886663fe5e3debeb984f5d374cfe276616 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:56 -0500
Subject: [PATCH 1376/3820] New translations billing.mdx (Spanish)

---
 website/pages/es/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/es/subgraphs/billing.mdx

diff --git a/website/pages/es/subgraphs/billing.mdx b/website/pages/es/subgraphs/billing.mdx
new file mode 100644
index 000000000000..a88cb8dae63c
--- /dev/null
+++ b/website/pages/es/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Facturación
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Haz clic en el botón "Conectar wallet" en la esquina superior derecha de la página. Serás redirigido a la página de selección de wallet. Selecciona tu wallet y haz clic en "Conectar".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Agregar y retirar GRT de tu saldo de cuenta.
+- Llevar un registro de tus saldos en función de la cantidad de GRT que hayas agregado a tu saldo de cuenta, la cantidad que hayas retirado y tus facturas.
+- Paga automáticamente las facturas basadas en las tarifas de consulta generadas, siempre y cuando haya suficiente GRT en tu saldo de cuenta.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Haz clic en el botón "Conectar wallet" en la esquina superior derecha de la página. Serás redirigido a la página de selección de wallet. Selecciona tu wallet y haz clic en "Conectar".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Añadir GRT utilizando una wallet multisig
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 42865cc6655f2bd5dc096ac3aef2fc2751a639d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:57 -0500
Subject: [PATCH 1377/3820] New translations billing.mdx (Arabic)

---
 website/pages/ar/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/billing.mdx

diff --git a/website/pages/ar/subgraphs/billing.mdx b/website/pages/ar/subgraphs/billing.mdx
new file mode 100644
index 000000000000..d68fb16ecc6e
--- /dev/null
+++ b/website/pages/ar/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: الفوترة
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. انقر على زر "توصيل المحفظة" في الزاوية اليمنى العليا من الصفحة. ستتم إعادة توجيهك إلى صفحة اختيار المحفظة. حدد محفظتك وانقر على "توصيل".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- إضافة وسحب GRT من رصيد حسابك.
+- تتبع أرصدتك بناءً على مقدار GRT الذي أضفته إلى رصيد حسابك ، والمبلغ الذي قمت بإزالته ، وفواتيرك.
+- دفع الفواتير تلقائيًا بناءً على رسوم الاستعلام التي تم إنشاؤها ، طالما أن هناك ما يكفي من GRT في رصيد حسابك.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. انقر على زر "توصيل المحفظة" في الزاوية اليمنى العليا من الصفحة. ستتم إعادة توجيهك إلى صفحة اختيار المحفظة. حدد محفظتك وانقر على "توصيل".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### إضافة GRT باستخدام محفظة متعددة التوقيع (multisig wallet)
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From c3cd222f0c366c0d6fc1fc3640c28699902209c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:58 -0500
Subject: [PATCH 1378/3820] New translations billing.mdx (Czech)

---
 website/pages/cs/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/billing.mdx

diff --git a/website/pages/cs/subgraphs/billing.mdx b/website/pages/cs/subgraphs/billing.mdx
new file mode 100644
index 000000000000..3e80baf646c3
--- /dev/null
+++ b/website/pages/cs/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Fakturace
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Klikněte na tlačítko "Připojit peněženku" v pravém horním rohu stránky. Budete přesměrováni na stránku pro výběr peněženky. Vyberte svou peněženku a klikněte na "Připojit".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Přidávat a vybírat GRT ze zůstatku na účtu.
+- Sledujte své zůstatky na základě toho, kolik GRT jste přidali k zůstatku na účtu, kolik jste odebrali a na základě faktur.
+- Automatická úhrada faktur na základě vygenerovaných poplatků za dotazy, pokud je na vašem účtu dostatek GRT.
+
+### GRT on Arbitrum or Ethereum
+
+Fakturační systém Graf přijímá GRT na Arbitrum a uživatelé budou potřebovat ETH na Arbitrum, aby mohli zaplatit za plyn. Zatímco protokol Graf začínal na Ethereum Mainnet, veškerá činnost, včetně smluv o vyúčtování, je nyní na Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- Pokud již máte GRT na platformě Ethereum, můžete ji přemostit na Arbitrum. Můžete tak učinit pomocí možnosti přemostění GRT, která je k dispozici v podgraf Studio, nebo pomocí jednoho z následujících přemostění:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Klikněte na tlačítko "Připojit peněženku" v pravém horním rohu stránky. Budete přesměrováni na stránku pro výběr peněženky. Vyberte svou peněženku a klikněte na "Připojit".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Přidání GRT pomocí multisig peněženky
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+Toto bude průvodce krok za krokem pro nákup ETH na Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Jakmile ověříte svou totožnost, zakupte ETH kliknutím na tlačítko "Koupit nyní" na banneru domovské stránky.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Potvrďte nákup a v peněžence Binance Spot se vám zobrazí ETH.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Klikněte na tlačítko "peněženka", klikněte na vybrat a vyberte ETH.
+   - Zadejte částku ETH, kterou chcete poslat, a adresu peněženky, na kterou ji chcete poslat.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 6b62cd1768cec256399c6144317c2c5ce6230448 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:08:59 -0500
Subject: [PATCH 1379/3820] New translations billing.mdx (German)

---
 website/pages/de/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/de/subgraphs/billing.mdx

diff --git a/website/pages/de/subgraphs/billing.mdx b/website/pages/de/subgraphs/billing.mdx
new file mode 100644
index 000000000000..12d9c64f1f42
--- /dev/null
+++ b/website/pages/de/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Billing
+---
+
+## Querying Plans
+
+Es gibt zwei Pläne für die Abfrage von Subgraphen in The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Abfrage Zahlungen mit Kreditkarte
+
+- Um die Abrechnung mit Kredit-/Debitkarten einzurichten, müssen die Benutzer Subgraph Studio (https://thegraph.com/studio/) aufrufen
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+  3. Wählen Sie „ Upgrade Plan“, wenn Sie vom Free Plan upgraden oder wählen Sie „Manage Plan“, wenn Sie GRT bereits in der Vergangenheit zu Ihrem Abrechnungssaldo hinzugefügt haben. Als Nächstes können Sie die Anzahl der Abfragen schätzen, um einen Kostenvoranschlag zu erhalten, dieser Schritt ist jedoch nicht erforderlich.
+  4. Um eine Zahlung per Kreditkarte zu wählen, wählen Sie „Kreditkarte“ als Zahlungsmethode und geben Sie Ihre Kreditkartendaten ein. Diejenigen, die Stripe bereits verwendet haben, können die Funktion „Link“ verwenden, um ihre Daten automatisch auszufüllen.
+- Die Rechnungen werden am Ende eines jeden Monats erstellt. Für alle Abfragen, die über das kostenlose Kontingent hinausgehen, muss eine aktive Kreditkarte hinterlegt sein.
+
+## Abfrage von Zahlungen mit GRT
+
+Subgraph-Nutzer können The Graph Token (oder GRT) verwenden, um für Abfragen im The Graph Network zu bezahlen. Mit GRT werden Rechnungen am Ende eines jeden Monats bearbeitet und erfordern ein ausreichendes Guthaben an GRT, um Abfragen über die Free-Plan-Quote von 100.000 monatlichen Abfragen hinaus durchzuführen. Sie müssen die von Ihren API-Schlüsseln generierten Gebühren bezahlen. Mit dem Abrechnungsvertrag können Sie:
+
+- Add and withdraw GRT from your account balance.
+- Keep track of your balances based on how much GRT you have added to your account balance, how much you have removed, and your invoices.
+- Automatically pay invoices based on query fees generated, as long as there is enough GRT in your account balance.
+
+### GRT auf Arbitrum oder Ethereum
+
+Das Abrechnungssystem von The Graph akzeptiert GRT auf Arbitrum, und die Nutzer benötigen ETH auf Arbitrum, um ihr Gas zu bezahlen. Während das The Graph-Protokoll auf dem Ethereum Mainnet begann, finden alle Aktivitäten, einschließlich der Abrechnungsverträge, nun auf Arbitrum One statt.
+
+Um für Abfragen zu bezahlen, brauchen Sie GRT auf Arbitrum. Hier sind ein paar verschiedene Möglichkeiten, dies zu erreichen:
+
+- Wenn Sie bereits GRT auf Ethereum haben, können Sie es zu Arbitrum überbrücken. Sie können dieses über GRT-Bridging-Option in Subgraph Studio tun oder eine der folgenden Bridges verwenden:
+
+- [Die Arbitrum-Brücke] (https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- Wenn du bereits Assets auf Arbitrum hast, kannst du sie über ein Swapping-Protokoll wie Uniswap in GRT tauschen.
+
+- Alternativ können Sie GRT auch direkt auf Arbitrum über einen dezentralen Handelsplatz erwerben.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Sobald Sie GRT überbrücken, können Sie es zu Ihrem Rechnungssaldo hinzufügen.
+
+### Hinzufügen von GRT mit einer Wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+3. Wählen Sie die Schaltfläche „ Manage “ in der oberen rechten Ecke. Erstmalige Nutzer sehen die Option „Upgrade auf den Wachstumsplan“, während wiederkehrende Nutzer auf „Von der Wallet einzahlen“ klicken.
+4. Verwenden Sie den Slider, um die Anzahl der Abfragen zu schätzen, die Sie monatlich erwarten.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Wählen Sie „Kryptowährung“. GRT ist derzeit die einzige Kryptowährung, die im The Graph Network akzeptiert wird.
+6. Wählen Sie die Anzahl der Monate, die Sie im Voraus bezahlen möchten.
+   - Die Zahlung im Voraus verpflichtet Sie nicht zu einer zukünftigen Nutzung. Ihnen wird nur das berechnet, was Sie verbrauchen, und Sie können Ihr Guthaben jederzeit abheben.
+7. Wählen Sie das Netzwerk, über das Sie Ihr GRT einzahlen. GRT auf Arbitrum oder Ethereum sind beide akzeptabel.
+8. Klicken Sie auf „GRT-Zugriff zulassen“ und geben Sie dann die Menge an GRT an, die von Ihrer Wallet genommen werden kann.
+   - Wenn Sie für mehrere Monate im Voraus bezahlen, müssen Sie den Zugriff auf den Betrag erlauben, der diesem Betrag entspricht. Diese Interaktion kostet kein Gas.
+9. Zum Schluss klicken Sie auf „GRT zu Rechnungssaldo hinzufügen“. Für diese Transaktion wird ETH auf Arbitrum benötigt, um die Gaskosten zu decken.
+
+- Beachten Sie, dass GRT, die von Arbitrum eingezahlt werden, innerhalb weniger Augenblicke verarbeitet werden, während GRT, die von Ethereum eingezahlt werden, etwa 15-20 Minuten zur Verarbeitung benötigen. Sobald die Transaktion bestätigt wurde, wird das GRT zu Ihrem Kontostand hinzugefügt.
+
+### GRT über eine Wallet abheben
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Klicken Sie auf die Schaltfläche „Connect Wallet“ in der oberen rechten Ecke der Seite. Wählen Sie Ihre Wallet aus und klicken Sie auf „Verbinden“.
+3. Klicken Sie auf die Schaltfläche „Verwalten“ in der oberen rechten Ecke der Seite. Wählen Sie „GRT abheben“. Ein Seitenfenster wird angezeigt.
+4. Geben Sie den Betrag der GRT ein, den Sie abheben möchten.
+5. Klicken Sie auf „GRT abheben“, um die GRT von Ihrem Kontostand abzuheben. Unterschreiben Sie die zugehörige Transaktion in Ihrer Wallet. Dies kostet Gas. Die GRT werden an Ihre Arbitrum Wallet gesendet.
+6. Sobald die Transaktion bestätigt ist, werden die GRT von Ihrem Kontostand in Ihrem Arbitrum Wallet abgezogen.
+
+### Adding GRT using a multisig wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Wählen Sie die Schaltfläche „ Manage “ in der oberen rechten Ecke. Erstmalige Nutzer sehen die Option „Upgrade auf den Wachstumsplan“, während wiederkehrende Nutzer auf „Von der Wallet einzahlen“ klicken.
+4. Verwenden Sie den Slider, um die Anzahl der Abfragen zu schätzen, die Sie monatlich erwarten.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Wählen Sie „Kryptowährung“. GRT ist derzeit die einzige Kryptowährung, die im The Graph Network akzeptiert wird.
+6. Wählen Sie die Anzahl der Monate, die Sie im Voraus bezahlen möchten.
+   - Die Zahlung im Voraus verpflichtet Sie nicht zu einer zukünftigen Nutzung. Ihnen wird nur das berechnet, was Sie verbrauchen, und Sie können Ihr Guthaben jederzeit abheben.
+7. Wählen Sie das Netzwerk, über das Sie Ihr GRT einzahlen. GRT auf Arbitrum oder Ethereum sind beide akzeptabel. 8. Klicken Sie auf „GRT-Zugang erlauben“ und geben Sie dann den Betrag an GRT an, der von Ihrer Wallet genommen werden kann.
+   - Wenn Sie für mehrere Monate im Voraus bezahlen, müssen Sie den Zugriff auf den Betrag erlauben, der diesem Betrag entspricht. Diese Interaktion kostet kein Gas.
+8. Zum Schluss klicken Sie auf „GRT zu Rechnungssaldo hinzufügen“. Für diese Transaktion wird ETH auf Arbitrum benötigt, um die Gaskosten zu decken.
+
+- Beachten Sie, dass GRT, die von Arbitrum eingezahlt werden, innerhalb weniger Augenblicke verarbeitet werden, während GRT, die von Ethereum eingezahlt werden, etwa 15-20 Minuten zur Verarbeitung benötigen. Sobald die Transaktion bestätigt wurde, wird das GRT zu Ihrem Kontostand hinzugefügt.
+
+## GRT abrufen
+
+In diesem Abschnitt erfahren Sie, wie Sie GRT dazu bringen können, die Abfragegebühren zu bezahlen.
+
+### Coinbase
+
+Dies ist eine Schritt-für-Schritt-Anleitung für den Kauf von GRT auf Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Sobald Sie ein Konto erstellt haben, müssen Sie Ihre Identität durch ein Verfahren verifizieren, das als KYC (oder Know Your Customer) bekannt ist. Dies ist ein Standardverfahren für alle zentralisierten oder verwahrten Krypto-Börsen.
+3. Sobald Sie Ihre Identität überprüft haben, können Sie GRT kaufen. Dazu klicken Sie auf die Schaltfläche „Kaufen/Verkaufen“ oben rechts auf der Seite.
+4. Wählen Sie die Währung, die Sie kaufen möchten. Wählen Sie GRT.
+5. Wählen Sie die Zahlungsmethode aus. Wählen Sie Ihre bevorzugte Zahlungsmethode aus.
+6. Wählen Sie die Menge an GRT, die Sie kaufen möchten.
+7. Überprüfen Sie Ihren Einkauf. Überprüfen Sie Ihren Einkauf und klicken Sie auf „GRT kaufen“.
+8. Bestätigen Sie Ihren Kauf. Bestätigen Sie Ihren Kauf und Sie haben GRT erfolgreich gekauft.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - Um GRT auf Ihre Wallet zu übertragen, klicken Sie auf die Schaltfläche „Konten“ oben rechts auf der Seite.
+   - Klicken Sie auf die Schaltfläche „Senden“ neben dem GRT Konto.
+   - Geben Sie den Betrag an GRT ein, den Sie senden möchten, und die Wallet-Adresse, an die Sie ihn senden möchten.
+   - Klicken Sie auf „Weiter“ und bestätigen Sie Ihre Transaktion. -Bitte beachten Sie, dass Coinbase Sie bei größeren Kaufbeträgen möglicherweise 7-10 Tage warten lässt, bevor Sie den vollen Betrag in eine Krypto-Wallet überweisen.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+Dies ist eine Schritt-für-Schritt-Anleitung für den Kauf von GRT auf Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Sobald Sie ein Konto erstellt haben, müssen Sie Ihre Identität durch ein Verfahren verifizieren, das als KYC (oder Know Your Customer) bekannt ist. Dies ist ein Standardverfahren für alle zentralisierten oder verwahrten Krypto-Börsen.
+3. Sobald Sie Ihre Identität überprüft haben, können Sie GRT kaufen. Dazu klicken Sie auf die Schaltfläche „Jetzt kaufen“ auf dem Banner der Homepage.
+4. Sie werden zu einer Seite weitergeleitet, auf der Sie die Währung auswählen können, die Sie kaufen möchten. Wählen Sie GRT.
+5. Wählen Sie Ihre bevorzugte Zahlungsmethode. Sie können mit verschiedenen Fiat-Währungen wie Euro, US-Dollar und mehr bezahlen.
+6. Wählen Sie die Menge an GRT, die Sie kaufen möchten.
+7. Überprüfen Sie Ihren Kauf und klicken Sie auf „GRT kaufen“.
+8. Bestätigen Sie Ihren Kauf und Sie werden Ihr GRT in Ihrer Binance Spot Wallet sehen können.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Klicken Sie auf die Schaltfläche „Wallet“, klicken Sie auf Abheben und wählen Sie GRT.
+   - Geben Sie den GRT-Betrag ein, den Sie senden möchten, und die Wallet-Adresse, die auf der Whitelist steht.
+   - Klicken Sie auf „Weiter“ und bestätigen Sie Ihre Transaktion.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+So können Sie GRT auf Uniswap kaufen.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Wählen Sie den Token, von dem Sie tauschen möchten. Wählen Sie ETH.
+3. Wählen Sie den Token, in den Sie tauschen möchten. Wählen Sie GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Geben Sie den Betrag an ETH ein, den Sie tauschen möchten.
+5. Klicken Sie auf „Swap“.
+6. Bestätigen Sie die Transaktion in Ihrer Wallet und warten Sie auf die Abwicklung der Transaktion.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Ether erhalten
+
+In diesem Abschnitt erfahren Sie, wie Sie Ether (ETH) erhalten können, um Transaktionsgebühren oder Gaskosten zu bezahlen. ETH ist notwendig, um Operationen im Ethereum-Netzwerk auszuführen, wie z. B. die Übertragung von Token oder die Interaktion mit Verträgen.
+
+### Coinbase
+
+Dies ist eine Schritt-für-Schritt-Anleitung für den Kauf von GRT auf Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Sobald Sie ein Konto erstellt haben, müssen Sie Ihre Identität durch ein Verfahren verifizieren, das als KYC (oder Know Your Customer) bekannt ist. Dies ist ein Standardverfahren für alle zentralisierten oder verwahrten Krypto-Börsen.
+3. Sobald Sie Ihre Identität bestätigt haben, können Sie ETH kaufen, indem Sie auf die Schaltfläche „Kaufen/Verkaufen“ oben rechts auf der Seite klicken.
+4. Wählen Sie die Währung, die Sie kaufen möchten. Wählen Sie ETH.
+5. Wählen Sie die gewünschte Zahlungsmethode.
+6. Geben Sie die Menge an ETH ein, die Sie kaufen möchten.
+7. Überprüfen Sie Ihren Kauf und klicken Sie auf „ETH kaufen“.
+8. Bestätigen Sie Ihren Kauf und Sie haben erfolgreich ETH gekauft.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - Um die ETH auf Ihre Wallet zu übertragen, klicken Sie auf die Schaltfläche „Konten“ oben rechts auf der Seite.
+   - Klicken Sie auf die Schaltfläche „Senden“ neben dem ETH-Konto.
+   - Geben Sie den ETH-Betrag ein, den Sie senden möchten, und die Wallet-Adresse, an die Sie ihn senden möchten.
+   - Stellen Sie sicher, dass Sie an Ihre Ethereum Wallet Adresse auf Arbitrum One senden.
+   - Klicken Sie auf „Weiter“ und bestätigen Sie Ihre Transaktion.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+Dies ist eine Schritt-für-Schritt-Anleitung für den Kauf von ETH auf Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Sobald Sie ein Konto erstellt haben, müssen Sie Ihre Identität durch ein Verfahren verifizieren, das als KYC (oder Know Your Customer) bekannt ist. Dies ist ein Standardverfahren für alle zentralisierten oder verwahrten Krypto-Börsen.
+3. Sobald Sie Ihre Identität verifiziert haben, kaufen Sie ETH, indem Sie auf die Schaltfläche „Jetzt kaufen“ auf dem Banner der Homepage klicken.
+4. Wählen Sie die Währung, die Sie kaufen möchten. Wählen Sie ETH.
+5. Wählen Sie die gewünschte Zahlungsmethode.
+6. Geben Sie die Menge an ETH ein, die Sie kaufen möchten.
+7. Überprüfen Sie Ihren Kauf und klicken Sie auf „ETH kaufen“.
+8. Bestätigen Sie Ihren Kauf und Sie werden Ihre ETH in Ihrer Binance Spot Wallet sehen.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - Um die ETH auf Ihre Wallet abzuheben, fügen Sie die Adresse Ihrer Wallet zur Abhebungs-Whitelist hinzu.
+   - Klicken Sie auf die Schaltfläche „Wallet“, klicken Sie auf „withdraw“ und wählen Sie ETH.
+   - Geben Sie den ETH-Betrag ein, den Sie senden möchten, und die Adresse der Wallet, die auf der Whitelist steht, an die Sie den Betrag senden möchten.
+   - Stellen Sie sicher, dass Sie an Ihre Ethereum Wallet Adresse auf Arbitrum One senden.
+   - Klicken Sie auf „Weiter“ und bestätigen Sie Ihre Transaktion.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## FAQs zur Rechnungsstellung
+
+### Wie viele Abfragen benötige ich?
+
+Sie müssen nicht im Voraus wissen, wie viele Abfragen Sie benötigen werden. Ihnen wird nur das berechnet, was Sie verbrauchen, und Sie können jederzeit GRT von Ihrem Konto abheben.
+
+Wir empfehlen Ihnen, die Anzahl der Abfragen, die Sie benötigen, zu überschlagen, damit Sie Ihr Guthaben nicht häufig aufstocken müssen. Eine gute Schätzung für kleine bis mittelgroße Anwendungen ist, mit 1 Mio. bis 2 Mio. Abfragen pro Monat zu beginnen und die Nutzung in den ersten Wochen genau zu überwachen. Bei größeren Anwendungen ist es sinnvoll, die Anzahl der täglichen Besuche auf Ihrer Website mit der Anzahl der Abfragen zu multiplizieren, die Ihre aktivste Seite beim Öffnen auslöst.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Kann ich GRT von meinem Rechnungssaldo abheben?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### Was passiert, wenn mein Guthaben aufgebraucht ist? Werde ich eine Warnung erhalten?
+
+Sie erhalten mehrere E-Mail-Benachrichtigungen, bevor Ihr Guthaben aufgebraucht ist.

From 99ce11eb4d57387c192ec0e57801eff72bbc44f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:00 -0500
Subject: [PATCH 1380/3820] New translations billing.mdx (Italian)

---
 website/pages/it/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/it/subgraphs/billing.mdx

diff --git a/website/pages/it/subgraphs/billing.mdx b/website/pages/it/subgraphs/billing.mdx
new file mode 100644
index 000000000000..55e8f4dc762b
--- /dev/null
+++ b/website/pages/it/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Billing
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Add and withdraw GRT from your account balance.
+- Keep track of your balances based on how much GRT you have added to your account balance, how much you have removed, and your invoices.
+- Automatically pay invoices based on query fees generated, as long as there is enough GRT in your account balance.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Adding GRT using a multisig wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 8273b3e5ec72da33a08ae41859a6e6019a97966a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:02 -0500
Subject: [PATCH 1381/3820] New translations billing.mdx (Japanese)

---
 website/pages/ja/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/billing.mdx

diff --git a/website/pages/ja/subgraphs/billing.mdx b/website/pages/ja/subgraphs/billing.mdx
new file mode 100644
index 000000000000..26ec84048154
--- /dev/null
+++ b/website/pages/ja/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: 請求書
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. ページ右上の「Connect Wallet」をクリックします。ウォレット選択ページに遷移します。ウォレットを選択し、「Connect」をクリックします。
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- アカウント残高から GRT を追加および引き出します。
+- アカウント残高に追加した GRT の量、削除した量、および請求書に基づいて、残高を追跡します。
+- アカウント残高に十分な GRT がある限り、生成されたクエリ料金に基づいて請求書を自動的に支払います。
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. ページ右上の「Connect Wallet」をクリックします。ウォレット選択ページに遷移します。ウォレットを選択し、「Connect」をクリックします。
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### マルチシグウォレットを使ったGRTの追加
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+これは、BinanceでETHを購入するためのステップバイステップのガイドになります。
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. 身元を確認したら、ホームページバナーの「Buy Now」ボタンをクリックしてETHを購入してください。
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. 購入を確認すると、BinanceのSpotウォレットにETHが表示されます。
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - 「ウォレット」ボタンをクリックし、その後「引き出し」をクリックし、ETHを選択してください。
+   - 送金したいETHの金額と送金先のホワイトリストに登録されているウォレットアドレスを入力してください。
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 170361c1215765ebe42bbfbd7c15f563dab478f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:03 -0500
Subject: [PATCH 1382/3820] New translations billing.mdx (Korean)

---
 website/pages/ko/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/billing.mdx

diff --git a/website/pages/ko/subgraphs/billing.mdx b/website/pages/ko/subgraphs/billing.mdx
new file mode 100644
index 000000000000..55e8f4dc762b
--- /dev/null
+++ b/website/pages/ko/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Billing
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Add and withdraw GRT from your account balance.
+- Keep track of your balances based on how much GRT you have added to your account balance, how much you have removed, and your invoices.
+- Automatically pay invoices based on query fees generated, as long as there is enough GRT in your account balance.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Adding GRT using a multisig wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 45075e5ced108fca77318d10b58c28f6e11bd5f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:04 -0500
Subject: [PATCH 1383/3820] New translations billing.mdx (Dutch)

---
 website/pages/nl/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/billing.mdx

diff --git a/website/pages/nl/subgraphs/billing.mdx b/website/pages/nl/subgraphs/billing.mdx
new file mode 100644
index 000000000000..55e8f4dc762b
--- /dev/null
+++ b/website/pages/nl/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Billing
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Add and withdraw GRT from your account balance.
+- Keep track of your balances based on how much GRT you have added to your account balance, how much you have removed, and your invoices.
+- Automatically pay invoices based on query fees generated, as long as there is enough GRT in your account balance.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Adding GRT using a multisig wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From e9c51c4c65de15e0abcaecf5b06dac08460dea44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:05 -0500
Subject: [PATCH 1384/3820] New translations billing.mdx (Polish)

---
 website/pages/pl/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/billing.mdx

diff --git a/website/pages/pl/subgraphs/billing.mdx b/website/pages/pl/subgraphs/billing.mdx
new file mode 100644
index 000000000000..d823cb3d0e48
--- /dev/null
+++ b/website/pages/pl/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Billing
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Add and withdraw GRT from your account balance.
+- Keep track of your balances based on how much GRT you have added to your account balance, how much you have removed, and your invoices.
+- Automatically pay invoices based on query fees generated, as long as there is enough GRT in your account balance.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [Przeniesienie do](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Adding GRT using a multisig wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 11a17ad01c2fe924965c1af4182ae5242920b1e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:06 -0500
Subject: [PATCH 1385/3820] New translations billing.mdx (Portuguese)

---
 website/pages/pt/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/billing.mdx

diff --git a/website/pages/pt/subgraphs/billing.mdx b/website/pages/pt/subgraphs/billing.mdx
new file mode 100644
index 000000000000..996983a535ec
--- /dev/null
+++ b/website/pages/pt/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Cobranças
+---
+
+## Querying Plans
+
+Há dois planos disponíveis para queries de subgraphs na Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Pagamentos de Queries com cartão de crédito
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página. Isto levará à página de seleção de carteira; lá, selecione a sua carteira e clique em "Connect".
+  3. Escolha "atualizar plano" se está a atualizar do Plano Grátis, ou escolha "Gerir plano" se já adicionou GRT ao seu saldo de cobrança no passado. Depois, é possível estimar o número de queries para conseguir uma estimativa de preço, mas isto não é obrigatório.
+  4. Para escolher um pagamento em cartão de crédito, escolha "Cartão de crédito" como o método de pagamento e preencha os campos. Quem já usou o Stripe antes poderá preencher os seus detalhes automaticamente com o recurso Link.
+- Os recibos serão processados ao fim de cada mês e exigem um cartão de crédito ativo para todas as queries além da cota do plano grátis.
+
+## Pagamentos de Queries com GRT
+
+Utilizadores de subgraph podem utilizar o The Graph Token (ou GRT) para pagar por queries na Graph Network. Com o GRT, recibos serão processados ao fim de cada mês e exigirão um saldo suficiente em GRT para realizar queries além da cota de 100 mil queries grátis do Plano Grátis. Você precisará pagar taxas geradas das suas chaves API. Com o contrato de cobrança, será possível:
+
+- Depositar e sacar GRT do seu saldo.
+- Acompanhar os seus balanços com base em quanto GRT depositou ao seu saldo, quanto retirou, e nos seus recibos.
+- Pagar recibos automaticamente com base nas taxas de query geradas, desde que tenha GRT suficiente no seu saldo.
+
+### GRT no Arbitrum ou Ethereum
+
+O sistema de cobranças do The Graph aceita GRT no Arbitrum, e utilizadores precisarão de ETH no Arbitrum para pagar pelo seu gas. O protocolo do The Graph começou na Mainnet do Ethereum, mas todas as atividades, que incluem os contratos de cobranças, agora se encontram no Arbitrum One.
+
+Para pagar por queries, é necessário ter GRT no Arbitrum. Veja algumas maneiras diferentes de adquirir o token:
+
+- Caso já tenha GRT no Ethereum, é possível enviá-lo ao Arbitrum via bridge. Isto pode ser feito via a opção de bridging de GRT providenciada no Subgraph Studio ou uma das seguintes bridges:
+
+- [Bridge no Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- Caso tenha outros ativos no Arbitrum, é possível trocá-los por GRT através de um protocolo de troca como o Uniswap.
+
+- Também é possível adquirir GRT diretamente no Arbitrum via uma exchange descentralizada.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Quando fizeres bridge do GRT, será possível adicioná-lo ao seu saldo de cobranças.
+
+### Depósitos de GRT com uma carteira
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página. Isto levará à página de seleção de carteira; lá, selecione a sua carteira e clique em "Connect".
+3. Selecione o botão "Manage" (Gerir) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
+4. Use o slider para estimar o número de queries que espera fazer mensalmente.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Escolha "Criptomoedas". Atualmente, o GRT é a única criptomoeda aceita na Graph Network.
+6. Selecione o número de meses que deseja pagar antecipadamente.
+   - Pagamentos antecipados não te comprometem a usos futuros. Você só será cobrado pelo que usa, e pode sacar o seu saldo a qualquer hora.
+7. Escolha a rede da qual o seu GRT será depositado. Vale tanto GRT do Arbitrum quanto do Ethereum.
+8. Clique "Allow GRT Access" (Permitir Acesso ao GRT) e depois especifique a quantidade de GRT que pode ser retirada da sua carteira.
+   - Se pagar múltiplos meses antecipadamente, permita o acesso à quantia que corresponde àquela quantidade. Esta interação não custará gas.
+9. Por último, clique em "Add GRT to Billing Balance" (Adicionar GRT ao Saldo de Cobranças). Esta transação precisará de GRT no Arbitrum para cobrir os custos de gas.
+
+- Note que o GRT depositado do Arbitrum será processado dentro de alguns momentos, enquanto o GRT depositado do Ethereum levará cerca de 15 a 20 min para processar. Quando a transação for confirmada, verás o GRT adicionado ao seu saldo.
+
+### Saques de GRT com carteira
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página, selecione a sua carteira e clique em "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Insira a quantia de GRT que quer sacar.
+5. Clique em 'Withdraw GRT' (Sacar GRT) para sacar o GRT do seu saldo. Assine a transação associada na sua carteira — isto custa gas. O GRT será enviado à sua carteira Arbitrum.
+6. Quando a transação for confirmada, verá o GRT sacado do seu saldo na sua carteira Arbitrum.
+
+### Depósitos de GRT com uma carteira multisig
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Selecione o botão "Manage" (Gerir) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
+4. Use o slider para estimar o número de queries que espera fazer mensalmente.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Escolha "Criptomoedas". Atualmente, o GRT é a única criptomoeda aceita na Graph Network.
+6. Selecione o número de meses que deseja pagar antecipadamente.
+   - Pagamentos antecipados não te comprometem a usos futuros. Você só será cobrado pelo que usa, e pode sacar o seu saldo a qualquer hora.
+7. Escolha a rede da qual o seu GRT será depositado. GRT do Arbitrum e do Ethereum são aceitáveis. Clique "Allow GRT Access" (Permitir Acesso ao GRT) e depois especifique a quantidade de GRT que pode ser retirada da sua carteira.
+   - Se pagar múltiplos meses antecipadamente, permita o acesso à quantia que corresponde àquela quantidade. Esta interação não custará gas.
+8. Por último, clique em "Add GRT to Billing Balance" (Adicionar GRT ao Saldo de Cobranças). Esta transação precisará de GRT no Arbitrum para cobrir os custos de gas.
+
+- Note que o GRT depositado do Arbitrum será processado dentro de alguns momentos, enquanto o GRT depositado do Ethereum levará cerca de 15 a 20 min para processar. Quando a transação for confirmada, verás o GRT adicionado ao seu saldo.
+
+## Como Adquirir GRT
+
+Esta seção explicará como adquirir GRT para pagar taxas de query.
+
+### Coinbase
+
+Este é um guia passo a passo sobre como comprar GRT na Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Quando tiver criado uma conta, precisará verificar a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este é um processo comum em todas as exchanges de cripto, centralizadas ou custodiais.
+3. Após verificar a sua identidade, poderá comprar GRT no botão "Comprar/Vender", no canto superior direito da página.
+4. Selecione a moeda que deseja comprar — no caso, GRT.
+5. Selecione o seu método de pagamento preferido.
+6. Selecione a quantia de GRT que deseja comprar.
+7. Verifique a sua compra, e após verificar, clique em "Comprar GRT".
+8. Confirme a sua compra, e o GRT será comprado com sucesso.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - Para transferir o GRT à sua carteira, clique no botão "Contas" no canto superior direito da página.
+   - Clique em "Enviar", próximo à conta de GRT.
+   - Insira a quantia de GRT que deseja enviar, e o endereço da carteira que a receberá.
+   - Clique em "Continuar" e confirme a sua transação. Nota: para compras maiores, a Coinbase pode demorar de 7 a 10 dias antes de transferir a quantia completa a uma carteira.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+Este é um guia passo a passo para comprar GRT na Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Quando tiver criado uma conta, precisará verificar a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este é um processo comum em todas as exchanges de cripto, centralizadas ou custodiais.
+3. Após verificar a sua identidade, poderá comprar GRT no botão "Comprar Agora", no canto superior direito da página.
+4. O botão levará-lhe a uma página onde pode selecionar a moeda que deseja comprar. Selecione GRT.
+5. Selecione o seu método de pagamento preferido. Poderá pagar com moedas fiduciárias diferentes, como Euro, Dólar americano, e mais.
+6. Selecione a quantia de GRT que deseja comprar.
+7. Verifique a sua compra e clique em "Comprar GRT".
+8. Confirme a sua compra, e logo o seu GRT aparecerá na sua Carteira Spot da Binance.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Clique no botão "wallet", clique em "sacar", e selecione GRT.
+   - Insira a quantia de GRT que deseja enviar, e o endereço da carteira na whitelist à qual quer enviar.
+   - Clique em "Continuar" e confirme a sua transação.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+Este é um guia passo a passo sobre como comprar GRT no Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Selecione o token que quer trocar — no caso, ETH.
+3. Selecione o token pelo que quer trocar — no caso, GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Insira a quantia de ETH que deseja trocar.
+5. Clique em "Swap".
+6. Confirme a transação na sua carteira e espere que a transação seja processada.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Como adquirir Ether
+
+Esta seção explicará como adquirir Ether (ETH) para pagar por taxas de transação ou gas. É necessário ter ETH para executar operações na rede Ethereum, como a transferência de tokens ou interação com contratos.
+
+### Coinbase
+
+Este é um guia passo a passo sobre como comprar ETH na Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Quando tiver criado uma conta, verifique a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este processo é comum em todas as corretoras de cripto, centralizadas ou custodiais.
+3. Após verificar a sua identidade, compre ETH no botão "Comprar/Vender", no canto superior direito da página.
+4. Selecione a moeda que deseja comprar — no caso, ETH.
+5. Selecione o seu método de pagamento preferido.
+6. Insira a quantia de ETH que deseja comprar.
+7. Reveja a sua compra e clique em "Comprar ETH".
+8. Confirme a sua compra, e o ETH será adquirido com sucesso.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - Para transferir o ETH à sua carteira, clique no botão "Contas" no canto superior direito da página.
+   - Clique em "Enviar", próximo à conta de ETH.
+   - Insira a quantia de ETH que deseja enviar, e o endereço da carteira que a receberá.
+   - Certifique-se que enviará ao endereço da sua carteira de Ethereum no Arbitrum One.
+   - Clique em "Continuar" e confirme a sua transação.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+Este é um guia passo a passo sobre como comprar ETH na Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Quando tiver criado uma conta, verifique a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este processo é comum em todas as corretoras de cripto, centralizadas ou custodiais.
+3. Após verificar a sua identidade, poderá comprar ETH no botão "Comprar/Vender", no banner da página principal.
+4. Selecione a moeda que deseja comprar — no caso, ETH.
+5. Selecione o seu método de pagamento preferido.
+6. Insira a quantia de ETH que deseja comprar.
+7. Reveja a sua compra e clique em "Comprar ETH".
+8. Confirme a sua compra, e o seu ETH aparecerá na sua Carteira Spot da Binance.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - Para sacar o ETH à sua carteira, adicione o endereço da sua carteira à whitelist de saques.
+   - Clique no botão "wallet", clique em "sacar" (withdraw), e selecione ETH.
+   - Insira a quantia de ETH que deseja enviar, e o endereço da carteira na whitelist à qual quer enviar.
+   - Certifique-se que enviará ao endereço da sua carteira de Ethereum no Arbitrum One.
+   - Clique em "Continuar" e confirme a sua transação.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Perguntas Frequentes Sobre Cobranças
+
+### De quantas queries precisarei?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+Recomendamos estimar mais queries do que necessário para que não precise encher o seu saldo com frequência. Uma boa estimativa para aplicativos pequenos ou médios é começar com 1 a 2 milhões de queries por mês e monitorar atenciosamente o uso nas primeiras semanas. Para aplicativos maiores, uma boa estimativa consiste em utilizar o número de visitas diárias ao seu site multiplicado ao número de queries que a sua página mais ativa faz ao abrir.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Posso sacar GRT do meu saldo de cobrança?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+Serão enviadas várias notificações de email antes do seu saldo de cobrança ser esvaziado.

From dd1a6a79de44e45d7d2f3f9cf518c9fe624e60a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:07 -0500
Subject: [PATCH 1386/3820] New translations billing.mdx (Russian)

---
 website/pages/ru/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/billing.mdx

diff --git a/website/pages/ru/subgraphs/billing.mdx b/website/pages/ru/subgraphs/billing.mdx
new file mode 100644
index 000000000000..44c5951debe1
--- /dev/null
+++ b/website/pages/ru/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Выставление счетов
+---
+
+## Querying Plans
+
+Существует два плана для выполнения запросов к субграфам в The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Оплата запросов с помощью кредитной карты
+
+- Чтобы настроить оплату с помощью кредитных/дебетовых карт, пользователи должны зайти в Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Нажмите на кнопку «Connect Wallet» в правом верхнем углу страницы. Вы будете перенаправлены на страницу выбора кошелька. Выберите свой кошелек и нажмите «Connect».
+  3. Выберите «Обновление плана», если Вы переходите с бесплатного плана, или «Управление планом», если Вы уже ранее добавили GRT на свой баланс для оплаты. Далее Вы можете оценить количество запросов, чтобы получить примерную стоимость, но это не обязательный шаг.
+  4. Чтобы выбрать оплату кредитной картой, выберите «Credit card» как способ оплаты и заполните информацию о своей карте. Те, кто ранее использовал Stripe, могут воспользоваться функцией Link для автоматического заполнения данных.
+- Счета будут выставляться в конце каждого месяца, и для всех запросов сверх квоты бесплатного плана потребуется активная кредитная карта.
+
+## Оплата запросов с помощью GRT
+
+Пользователи субграфов могут использовать токен The Graph (GRT) для оплаты запросов в The Graph Network. При использовании GRT счета будут выставляться в конце каждого месяца, и потребуется достаточный баланс GRT для выполнения запросов, превышающих квоту бесплатного плана в 100,000 запросов в месяц. Вам нужно будет оплатить комиссии, которые генерируются Вашими API-ключами. С помощью платежного контракта Вы сможете:
+
+- Добавлять и списывать токены GRT с Вашего платежного баланса.
+- Отслеживать баланс своих счетов на основе того, сколько токенов GRT Вы добавили к своему платежному балансу и сколько удалили.
+- Автоматически оплачивать счета на основе сгенерированных комиссий за запросы, если на Вашем платежном балансе достаточно токенов GRT.
+
+### GRT на Arbitrum или Ethereum
+
+Платежная система The Graph принимает GRT на Arbitrum, и пользователям потребуется ETH на Arbitrum для оплаты газа. Хотя протокол The Graph изначально был запущен на основной сети Ethereum, вся активность, включая платежные контракты, теперь проходит на Arbitrum One.
+
+Для оплаты запросов Вам потребуется GRT на Arbitrum. Вот несколько способов, как это можно сделать:
+
+- Если у Вас уже есть GRT на Ethereum, Вы можете перенести его на Arbitrum. Вы можете сделать это через опцию переноса GRT, доступную в Subgraph Studio, или с помощью одного из следующих мостов:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- Если у Вас уже есть активы на Arbitrum, Вы можете обменять их на GRT через протокол обмена, такой как Uniswap.
+
+- В качестве альтернативы, Вы можете приобрести GRT напрямую на Arbitrum через децентрализованную биржу.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+После переноса GRT Вы можете добавить его на баланс для оплаты.
+
+### Добавление токенов GRT с помощью кошелька
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Нажмите на кнопку «Connect Wallet» в правом верхнем углу страницы. Вы будете перенаправлены на страницу выбора кошелька. Выберите свой кошелек и нажмите «Connect».
+3. Нажмите кнопку «Управление» в правом верхнем углу. Новые пользователи увидят опцию «Обновить до плана Роста», а те, кто пользовался ранее — «Пополнение с кошелька».
+4. Используйте ползунок, чтобы оценить количество запросов, которое Вы планируете выполнять ежемесячно.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Выберите «Криптовалюта». В настоящее время GRT — единственная криптовалюта, принимаемая в The Graph Network.
+6. Выберите количество месяцев, за которые Вы хотели бы внести предоплату.
+   - Предоплата не обязывает Вас к дальнейшему использованию. С Вас будет взиматься плата только за то, что Вы используете, и Вы сможете вывести свой баланс в любое время.
+7. Выберите сеть, из которой Вы вносите свой GRT. Принимаются GRT как на Arbitrum, так и на Ethereum.
+8. Нажмите «Разрешить доступ к GRT», а затем укажите количество GRT, которое может быть списано с Вашего кошелька.
+   - Если Вы вносите предоплату за несколько месяцев, Вам нужно разрешить доступ к сумме, которая соответствует этому количеству. За это действие газ взиматься не будет.
+9. В заключение, нажмите «Добавить GRT в платежный баланс». Эта транзакция потребует ETH на Arbitrum для покрытия затрат на газ.
+
+- Обратите внимание, что GRT, переведенные из Arbitrum, будут обработаны в течение нескольких секунд, в то время как GRT, переведенные из Ethereum, займут около 15-20 минут. Как только транзакция будет подтверждена, Вы увидите GRT на балансе своего аккаунта.
+
+### Вывод токенов GRT с помощью кошелька
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Нажмите на кнопку «Подключить кошелек» в правом верхнем углу страницы. Выберите свой кошелек и нажмите «Подключить».
+3. Нажмите кнопку «Управление» в правом верхнем углу страницы. Выберите «Вывести GRT». Появится боковая панель.
+4. Введите сумму GRT, которую хотите вывести.
+5. Нажмите «Вывести GRT», чтобы вывести токены GRT со своего платежного баланса. Подпишите соответствующую транзакцию в своем кошельке. За это потребуется оплата комиссии сети. Токены GRT будут отправлены на Ваш кошелек Arbitrum.
+6. Как только транзакция будет подтверждена, Вы увидите токены GRT выведенные с Вашего платежного баланса в своем кошельке Arbitrum.
+
+### Добавление токенов GRT с помощью кошелька с мультиподписью
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Нажмите кнопку «Управление» в правом верхнем углу. Новые пользователи увидят опцию «Обновить до плана Роста», а те, кто пользовался ранее — «Пополнение с кошелька».
+4. Используйте ползунок, чтобы оценить количество запросов, которое Вы планируете выполнять ежемесячно.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Выберите «Криптовалюта». В настоящее время GRT — единственная криптовалюта, принимаемая в The Graph Network.
+6. Выберите количество месяцев, за которые Вы хотели бы внести предоплату.
+   - Предоплата не обязывает Вас к дальнейшему использованию. С Вас будет взиматься плата только за то, что Вы используете, и Вы сможете вывести свой баланс в любое время.
+7. Выберите сеть, из которой Вы вносите свой GRT. Принимаются GRT как на Arbitrum, так и на Ethereum. 8. Нажмите «Разрешить доступ к GRT», а затем укажите количество GRT, которое может быть списано с Вашего кошелька.
+   - Если Вы вносите предоплату за несколько месяцев, Вам нужно разрешить доступ к сумме, которая соответствует этому количеству. За это действие газ взиматься не будет.
+8. В заключение, нажмите «Добавить GRT в платежный баланс». Эта транзакция потребует ETH на Arbitrum для покрытия затрат на газ.
+
+- Обратите внимание, что GRT, переведенные из Arbitrum, будут обработаны в течение нескольких секунд, в то время как GRT, переведенные из Ethereum, займут около 15-20 минут. Как только транзакция будет подтверждена, Вы увидите GRT на балансе своего аккаунта.
+
+## Получение GRT
+
+В этом разделе показано, как оплачивать комиссии за запросы с помощью токенов GRT.
+
+### Coinbase
+
+Далее будет представлено пошаговое руководство по приобретению токена GRT на Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. После того как Вы создали учетную запись, Вам нужно будет подтвердить свою личность с помощью процесса, известного как KYC (или Know Your Customer). Это стандартная процедура для всех централизованных или кастодиальных криптобирж.
+3. После того как Вы подтвердили свою личность, Вы можете приобрести токены ETH нажав на кнопку "Купить/Продать" в правом верхнем углу страницы.
+4. Выберите валюту, которую хотите купить. Выберите GRT.
+5. Выберите способ оплаты. Выберите предпочитаемый способ оплаты.
+6. Выберите количество токенов GRT, которое хотите приобрести.
+7. Проверьте все данные о приобретении. Проверьте все данные о приобретении и нажмите «Купить GRT».
+8. Подтвердите покупку. Подтвердите покупку - Вы успешно приобрели токены GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - Чтобы перевести токены GRT на свой кошелек, нажмите кнопку «Учетные записи» в правом верхнем углу страницы.
+   - Нажмите на кнопку «Отправить» рядом с учетной записью GRT.
+   - Введите сумму GRT, которую хотите отправить, и адрес кошелька, на который хотите её отправить.
+   - Нажмите «Продолжить» и подтвердите транзакцию. -Обратите внимание, что при больших суммах покупки Coinbase может потребовать от Вас подождать 7-10 дней, прежде чем переведет полную сумму на кошелек.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+Далее будет представлено пошаговое руководство по приобретению токена GRT на Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. После того как Вы создали учетную запись, Вам нужно будет подтвердить свою личность с помощью процесса, известного как KYC (или Know Your Customer). Это стандартная процедура для всех централизованных или кастодиальных криптобирж.
+3. После того как Вы подтвердили свою личность, Вы можете приобрести токены GRT. Вы можете сделать это, нажав на кнопку «Купить сейчас» на баннере главной страницы.
+4. Вы попадете на страницу, где сможете выбрать валюту, которую хотите приобрести. Выберите GRT.
+5. Выберите предпочитаемый способ оплаты. Вы сможете расплатиться различными фиатными валютами, такими как евро, доллары США и т. д.
+6. Выберите количество токенов GRT, которое хотите приобрести.
+7. Проверьте все данные о приобретении и нажмите «Купить GRT».
+8. Подтвердите покупку, и Вы сможете увидеть GRT в своем кошельке Binance Spot.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Нажмите на кнопку «кошелек», нажмите «вывести» и выберите GRT.
+   - Введите сумму GRT, которую хотите отправить, и адрес кошелька из белого списка, на который Вы хотите её отправить.
+   - Нажмите «Продолжить» и подтвердите транзакцию.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+Так Вы можете приобрести GRT на Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Выберите токен, который хотите обменять. Выберите ETH.
+3. Выберите токен, на который хотите произвести обмен. Выберите GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Введите количество ETH, которое хотите обменять.
+5. Нажмите «Обменять».
+6. Подтвердите транзакцию в своем кошельке и дождитесь ее обработки.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Получение Ether
+
+В этом разделе показано, как с помощью Ethereum (ETH) оплачивать транзакционные сборы или расходы комиссии сети. ETH необходим для выполнения операций в сети Ethereum, таких, как передача токенов или взаимодействие с контрактами.
+
+### Coinbase
+
+Далее будет представлено пошаговое руководство по приобретению токена ETH на Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. После того как Вы создали учетную запись, Вам нужно будет подтвердить свою личность с помощью процесса, известного как KYC (или Know Your Customer). Это стандартная процедура для всех централизованных или кастодиальных криптобирж.
+3. После того как Вы подтвердили свою личность, Вы можете приобрести токены ETH нажав на кнопку "Купить/Продать" в правом верхнем углу страницы.
+4. Выберите валюту, которую хотите купить. Выберите ETH.
+5. Выберите предпочитаемый способ оплаты.
+6. Введите количество ETH, которое хотите приобрести.
+7. Проверьте все данные о приобретении и нажмите «Купить ETH».
+8. Подтвердите покупку. Вы успешно приобрели токены ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - Чтобы перевести ETH на свой кошелек, нажмите кнопку «Учетные записи» в правом верхнем углу страницы.
+   - Нажмите на кнопку «Отправить» рядом с учетной записью ETH.
+   - Введите сумму ETH которую хотите отправить, и адрес кошелька, на который хотите её отправить.
+   - Убедитесь, что делаете перевод на адрес своего Ethereum-кошелька в сети Arbitrum One.
+   - Нажмите «Продолжить» и подтвердите транзакцию.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. После того как Вы создали учетную запись, Вам нужно будет подтвердить свою личность с помощью процесса, известного как KYC (или Know Your Customer). Это стандартная процедура для всех централизованных или кастодиальных криптобирж.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Выберите валюту, которую хотите купить. Выберите ETH.
+5. Выберите предпочитаемый способ оплаты.
+6. Введите количество ETH, которое хотите приобрести.
+7. Проверьте все данные о приобретении и нажмите «Купить ETH».
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - Чтобы вывести ETH на свой кошелек, добавьте адрес кошелька в белый список вывода.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Убедитесь, что делаете перевод на адрес своего Ethereum-кошелька в сети Arbitrum One.
+   - Нажмите «Продолжить» и подтвердите транзакцию.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Часто задаваемые вопросы по выставлению счетов
+
+### Сколько запросов мне понадобится?
+
+Вам не нужно заранее знать, сколько запросов Вам понадобится. С Вас будет взиматься плата только за фактически использованные запросы, и Вы сможете вывести GRT со своего счета в любое время.
+
+Мы рекомендуем переоценить количество запросов, чтобы Вам не приходилось часто пополнять баланс. Хорошей оценкой для небольших и средних приложений будет начать с 1–2 млн запросов в месяц и внимательно следить за использованием в первые недели. Для более крупных приложений хорошей оценкой будет использовать количество ежедневных посещений Вашего сайта, умноженное на количество запросов, которые делает Ваша самая активная страница при открытии.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Могу ли я вывести GRT со своего платежного баланса?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### Что произойдет, когда мой платежный баланс закончится? Получу ли я предупреждение?
+
+Вы получите несколько уведомлений по электронной почте перед тем, как Ваш платежный баланс обнулится.

From a6f253e9c25d35eab24c937ddef8740453e47093 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:08 -0500
Subject: [PATCH 1387/3820] New translations billing.mdx (Swedish)

---
 website/pages/sv/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/billing.mdx

diff --git a/website/pages/sv/subgraphs/billing.mdx b/website/pages/sv/subgraphs/billing.mdx
new file mode 100644
index 000000000000..3105b5e15a6b
--- /dev/null
+++ b/website/pages/sv/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Fakturering
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Klicka på knappen "Anslut plånbok" längst upp till höger på sidan. Du kommer att omdirigeras till sidan för plånboksval. Välj din plånbok och klicka på "Anslut".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Lägga till och ta ut GRT från ditt kontosaldo.
+- Hålla koll på dina saldon baserat på hur mycket GRT du har lagt till på ditt kontosaldo, hur mycket du har tagit bort och dina fakturor.
+- Automatiskt betala fakturor baserat på genererade frågeavgifter, så länge det finns tillräckligt med GRT på ditt kontosaldo.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Klicka på knappen "Anslut plånbok" längst upp till höger på sidan. Du kommer att omdirigeras till sidan för plånboksval. Välj din plånbok och klicka på "Anslut".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Lägga till GRT med en multisig-plånbok
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+Detta kommer att vara en stegvis guide för att köpa ETH på Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. När du har verifierat din identitet kan du köpa ETH genom att klicka på knappen "Köp nu" på startsidan.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Bekräfta ditt köp och du kommer att se din ETH i din Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Klicka på knappen "plånbok", klicka på "Ta ut" och välj ETH.
+   - Ange det belopp av ETH du vill skicka och den vitlistade plånboksadressen du vill skicka det till.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 8fb5256ff7ea152abe582ad883331be291ecac6a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:09 -0500
Subject: [PATCH 1388/3820] New translations billing.mdx (Turkish)

---
 website/pages/tr/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/billing.mdx

diff --git a/website/pages/tr/subgraphs/billing.mdx b/website/pages/tr/subgraphs/billing.mdx
new file mode 100644
index 000000000000..58920349c6ac
--- /dev/null
+++ b/website/pages/tr/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Faturalandırma
+---
+
+## Querying Plans
+
+The Graph Ağı'nda subgraph'leri sorgulamak için kullanabileceğiniz iki plan bulunmaktadır.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Kredi kartı ile sorgu ödemeleri
+
+- Kredi/banka kartları ile faturalandırmayı ayarlamak için, kullanıcıların Subgraph Studio'ya (https://thegraph.com/studio/) erişmeleri gerekir
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Sayfanın sağ üst köşesindeki "Cüzdanı Bağla" düğmesine tıklayın. Cüzdan seçim sayfasına yönlendirileceksiniz. Cüzdanınızı seçin ve "Bağlan" a tıklayın.
+  3. Ücretsiz Plan'dan yükseltme yapıyorsanız "Planı Yükselt" seçeneğini, daha önce faturalandırma bakiyenize GRT eklediyseniz "Planı Yönet" seçeneğini seçin. Sonrasında, sorgu sayısını tahmin ederek bir fiyat tahmini alabilirsiniz, ancak bu zorunlu bir adım değildir.
+  4. Kredi kartı ödemesini seçmek için, ödeme yöntemi olarak "Kredi kartı" seçeneğini seçin ve kredi kartı bilgilerinizi doldurun. Daha önce Stripe kullananlar, bilgilerini otomatik doldurmak için Link özelliğini kullanabilirler.
+- Faturalar her ayın sonunda işlenecek ve Ücretsiz Plan kotasını aşan tüm sorgular için sistemde aktif bir kredi kartı bulunması gerekecektir.
+
+## GRT ile Sorgu Ödemeleri
+
+Subgraph kullanıcıları, The Graph Ağında sorgular için ödeme yapmak amacıyla The Graph Token (GRT) kullanabilirler. GRT ile faturalar her ayın sonunda işlenecek ve 100.000 aylık sorgu limiti olan Ücretsiz Plan kotasının ötesindeki sorgular için yeterli GRT bakiyesi bulunması gerekecek. API anahtarlarınızdan kaynaklanan ücretleri ödemeniz gerekecek. Faturalandırma sözleşmesini kullanarak şunları yapabileceksiniz:
+
+- Hesap bakiyenizden GRT ekleyin ve çekin.
+- Hesap bakiyenize ne kadar GRT eklediğiniz, ne kadar çektiğiniz ve faturalarınıza göre bakiyelerinizi takip edin.
+- Hesap bakiyenizde yeterli GRT olduğu sürece, oluşturulan sorgu ücretlerine göre faturaları otomatik olarak ödeyin.
+
+### Ethereum ya da Arbitrum Ağında GRT
+
+The Graph'in faturalandırma sistemi, Arbitrum ağı üzerinde GRT ile ödeme alır. Kullanıcıların gaz ücretlerini ödemek için Arbitrum üzerinde ETH'ye ihtiyaçları olacaktır. The Graph protokolü, başlangıçta Ethereum Mainnet üzerinde başlatılmış olsa da, faturalandırma sözleşmeleri de dahil olmak üzere tüm faaliyetler artık Arbitrum One üzerinde gerçekleştirilmektedir.
+
+Sorgu ödemelerini yapmak için Arbitrum üzerinde GRT'ye ihtiyacınız var. İşte GRT elde etmenin birkaç farklı yolu:
+
+- Ethereum üzerinde halihazırda GRT'leriniz varsa, bunları Arbitrum'a köprüleyebilirsiniz. Bu işlemi Subgraph Studio'da sunulan GRT köprüleme seçeneği aracılığıyla veya aşağıdaki köprülerden birini kullanarak yapabilirsiniz:
+
+- [Arbitrum Köprüsü](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- Arbitrum üzerinde zaten varlıklarınız varsa, Uniswap gibi bir takas protokolü aracılığıyla bunları GRT ile takas edebilirsiniz.
+
+- Alternatif olarak, GRT'yi doğrudan Arbitrum üzerinde merkeziyetsiz bir borsa aracılığıyla edinebilirsiniz.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+GRT'yi köprüledikten sonra faturalandırma bakiyenize ekleyebilirsiniz.
+
+### Bir cüzdan kullanarak GRT ekleme
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Sayfanın sağ üst köşesindeki "Cüzdanı Bağla" düğmesine tıklayın. Cüzdan seçim sayfasına yönlendirileceksiniz. Cüzdanınızı seçin ve "Bağlan" a tıklayın.
+3. Sağ üst köşedeki 'Yönet' düğmesine tıklayın. İlk kez kullanıyorsanız 'Büyüme Planına Yükselt' seçeneğini göreceksiniz. Daha önce işlem yaptıysanız 'Cüzdandan Yatır' seçeneğine tıklayın.
+4. Kaydırıcıyı kullanarak aylık olarak yapmayı beklediğiniz sorgu sayısını tahmin edin.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. "Kriptopara" seçeneğini seçin. Şu anda The Graph Ağı'nda kabul edilen tek kriptopara GRT'dir.
+6. Peşin ödeme yapmak istediğiniz ay sayısını seçin.
+   - Peşin ödeme yapmak, gelecekte kullanım zorunluluğu getirmez. Yalnızca kullandığınız kadar ücretlendirilirsiniz ve bakiyenizi istediğiniz zaman çekebilirsiniz.
+7. GRT yatıracağınız ağı seçin. Arbitrum veya Ethereum üzerindeki GRT kabul edilmektedir.
+8. "Allow GRT Access" düğmesine tıklayın ve ardından cüzdanınızdan çekilebilecek GRT miktarını belirtin.
+   - Eğer birden fazla ay için peşin ödeme yapıyorsanız, o tutara karşılık gelen miktar için erişime izin vermelisiniz. Bu işlem herhangi bir gas ücreti gerektirmez.
+9. Son olarak, "GRT'yi Faturalandırma Bakiyesine Ekle" düğmesine tıklayın. Bu işlem için gas ücretlerini karşılamak üzere Arbitrum üzerinde ETH'ye ihtiyacınız olacak.
+
+- Arbitrum'dan yatırılan GRT'nin işlenmesi birkaç dakika içinde tamamlanırken, Ethereum'dan yatırılan GRT'nin işlenmesi yaklaşık 15-20 dakika sürecektir. İşlem onaylandıktan sonra GRT'nin hesap bakiyenize eklendiğini göreceksiniz.
+
+### Bir cüzdan kullanarak GRT çekme
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Sayfanın sağ üst köşesindeki "Cüzdanı Bağla" düğmesine tıklayın. Cüzdanınızı seçin ve "Bağlan" düğmesine tıklayın.
+3. Sayfanın sağ üst köşesindeki "Yönet" düğmesine tıklayın. "GRT Çek" seçeneğini seçin. Bir yan panel açılacaktır.
+4. Çekmek istediğiniz GRT miktarını girin.
+5. "Çek GRT" düğmesine tıklayarak GRT'yi hesap bakiyenizden çekin. İlgili işlemi cüzdanınızda imzalayın. Bu işlem gas ücreti gerektirecektir. GRT, Arbitrum cüzdanınıza gönderilecektir.
+6. İşlem onaylandıktan sonra, GRT'nin hesap bakiyenizden çekildiğini ve Arbitrum cüzdanınıza aktarıldığını göreceksiniz.
+
+### Multisig cüzdanı kullanarak GRT ekleme
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Sağ üst köşedeki 'Yönet' düğmesine tıklayın. İlk kez kullanıyorsanız 'Büyüme Planına Yükselt' seçeneğini göreceksiniz. Daha önce işlem yaptıysanız 'Cüzdandan Yatır' seçeneğine tıklayın.
+4. Kaydırıcıyı kullanarak aylık olarak yapmayı beklediğiniz sorgu sayısını tahmin edin.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. "Kriptopara" seçeneğini seçin. Şu anda The Graph Ağı'nda kabul edilen tek kriptopara GRT'dir.
+6. Peşin ödeme yapmak istediğiniz ay sayısını seçin.
+   - Peşin ödeme yapmak, gelecekte kullanım zorunluluğu getirmez. Yalnızca kullandığınız kadar ücretlendirilirsiniz ve bakiyenizi istediğiniz zaman çekebilirsiniz.
+7. GRT yatıracağınız ağı seçin. Arbitrum veya Ethereum üzerindeki GRT kabul edilmektedir. 8. "GRT Erişimine İzin Ver" düğmesine tıklayın ve ardından cüzdanınızdan çekilebilecek GRT miktarını belirtin.
+   - Eğer birden fazla ay için peşin ödeme yapıyorsanız, o tutara karşılık gelen miktar için erişime izin vermelisiniz. Bu işlem herhangi bir gas ücreti gerektirmez.
+8. Son olarak, "GRT'yi Faturalandırma Bakiyesine Ekle" düğmesine tıklayın. Bu işlem için gas ücretlerini karşılamak üzere Arbitrum üzerinde ETH'ye ihtiyacınız olacak.
+
+- Arbitrum'dan yatırılan GRT'nin işlenmesi birkaç dakika içinde tamamlanırken, Ethereum'dan yatırılan GRT'nin işlenmesi yaklaşık 15-20 dakika sürecektir. İşlem onaylandıktan sonra GRT'nin hesap bakiyenize eklendiğini göreceksiniz.
+
+## GRT Edinme
+
+Bu bölüm, sorgu ücretlerini ödemek için nasıl GRT edinebileceğinizi anlatacaktır.
+
+### Coinbase
+
+Bu kılavuz, Coinbase üzerinden GRT satın alma işlemini adım adım açıklayacaktır.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Bir hesap oluşturduktan sonra, kimliğinizi KYC (Müşterini Tanı) olarak bilinen bir süreçle doğrulamanız gerekecek. KYC, tüm merkezi veya emanetçi kripto borsaları için standart bir prosedürdür.
+3. Kimliğinizi doğruladıktan sonra GRT satın alabilirsiniz. Bunu sayfanın sağ üst köşesindeki "Al/Sat" düğmesine tıklayarak yapabilirsiniz.
+4. Satın almak istediğiniz para birimini seçin. GRT'yi seçin.
+5. Ödeme yöntemini seçin. Tercih ettiğiniz ödeme yöntemini seçin.
+6. Satın almak istediğiniz GRT miktarını seçin.
+7. Satın alımınızı gözden geçirin. Satın alımınızı gözden geçirin ve "GRT Satın Al" düğmesine tıklayın.
+8. Satın alımınızı onaylayın. Satın alımınızı onaylayın, böylece başarılı bir şekilde GRT satın almış olacaksınız.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - GRT'yi cüzdanınıza transfer etmek için, sayfanın sağ üst köşesindeki "Hesaplar" düğmesine tıklayın.
+   - GRT hesabının yanındaki "Gönder" düğmesine tıklayın.
+   - Göndermek istediğiniz GRT miktarını ve göndermek istediğiniz cüzdan adresini girin.
+   - "Devam" düğmesine tıklayın ve işleminizi onaylayın. -Lütfen unutmayın, yüksek tutarda satın alım durumunda Coinbase, tam tutarı bir cüzdana transfer etmeden önce 7-10 gün beklemenizi isteyebilir.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+Bu kılavuz, Binance üzerinden GRT satın alma işlemini adım adım açıklayacaktır.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Bir hesap oluşturduktan sonra, kimliğinizi KYC (Müşterini Tanı) olarak bilinen bir süreçle doğrulamanız gerekecek. KYC, tüm merkezi veya emanetçi kripto borsaları için standart bir prosedürdür.
+3. Kimliğinizi doğruladıktan sonra GRT satın alabilirsiniz. Bunu, ana sayfa banner'ındaki "Şimdi Satın Al" düğmesine tıklayarak yapabilirsiniz.
+4. Satın almak istediğiniz para birimini seçebileceğiniz bir sayfaya yönlendirileceksiniz. GRT'yi seçin.
+5. Tercih ettiğiniz ödeme yöntemini seçin. Euro, ABD Doları ve diğer birçok itibari para birimiyle ödeme yapabileceksiniz.
+6. Satın almak istediğiniz GRT miktarını seçin.
+7. Satın alımınızı gözden geçirin ve "GRT Satın Al" düğmesine tıklayın.
+8. Satın alımınızı onaylayın, ardından GRT'nizi Binance Spot Cüzdanınızda görüntüleyebilirsiniz.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - "Cüzdan" düğmesine tıklayın, ardından "Çekim" seçeneğine tıklayın ve GRT'yi seçin.
+   - Göndermek istediğiniz GRT miktarını ve beyaz listeye eklenmiş cüzdan adresini girin.
+   - "Devam" düğmesine tıklayın ve işleminizi onaylayın.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+Bu kılavuz, Uniswap üzerinden GRT satın alma işlemini adım adım açıklayacaktır.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Baz para birimi olarak kullanılacak token'ı seçin. ETH'yi seçin.
+3. Satın almak istediğiniz token'ı seçin. GRT'yi seçin.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Takas etmek istediğiniz ETH miktarını girin.
+5. "Swap" butonuna tıklayın.
+6. İşlemi cüzdanınızda onaylayın ve işlemin tamamlanmasını bekleyin.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Ether Edinme
+
+Bu bölüm, işlem ücretlerini veya gas maliyetlerini ödemek için nasıl Ether (ETH) edinebileceğinizi anlatacaktır. Ethereum ağı üzerinde token transferi yapmak veya akıllı sözleşmelerle etkileşime geçmek gibi işlemleri gerçekleştirmek için ETH gereklidir.
+
+### Coinbase
+
+Bu kılavuz, Coinbase üzerinden ETH satın alma işlemini adım adım açıklayacaktır.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Bir hesap oluşturduktan sonra, kimliğinizi KYC (Müşterini Tanı) olarak bilinen bir süreçle doğrulamanız gerekecek. Bu, tüm merkezi veya emanetçi kripto borsaları için standart bir prosedürdür.
+3. Kimliğinizi doğruladıktan sonra, sayfanın sağ üst köşesindeki "Al/Sat" düğmesine tıklayarak ETH satın alın.
+4. Satın almak istediğiniz para birimini seçin. ETH seçin.
+5. Tercih ettiğiniz ödeme yöntemini seçin.
+6. Satın almak istediğiniz ETH miktarını girin.
+7. Satın alımınızı gözden geçirin ve "ETH Satın Al" düğmesine tıklayın.
+8. Satın alımınızı onaylayın, böylece ETH'yi başarıyla satın almış olacaksınız.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - ETH'yi cüzdanınıza transfer etmek için, sayfanın sağ üst köşesindeki "Hesaplar" düğmesine tıklayın.
+   - ETH hesabının yanındaki "Gönder" düğmesine tıklayın.
+   - Göndermek istediğiniz ETH miktarını ve göndermek istediğiniz cüzdan adresini girin.
+   - Gönderdiğiniz adresin Arbitrum One üzerindeki Ethereum cüzdan adresiniz olduğundan emin olun.
+   - "Devam" düğmesine tıklayın ve işleminizi onaylayın.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+Bu, Binance'de ETH satın almak için adım adım bir rehberdir.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Bir hesap oluşturduktan sonra, kimliğinizi KYC (Müşterini Tanı) olarak bilinen bir süreçle doğrulamanız gerekecek. Bu, tüm merkezi veya emanetçi kripto borsaları için standart bir prosedürdür.
+3. Kimliğinizi doğruladıktan sonra, ana sayfa afişindeki "Şimdi Satın Al" düğmesine tıklayarak ETH satın alın.
+4. Satın almak istediğiniz para birimini seçin. ETH seçin.
+5. Tercih ettiğiniz ödeme yöntemini seçin.
+6. Satın almak istediğiniz ETH miktarını girin.
+7. Satın alımınızı gözden geçirin ve "ETH Satın Al" düğmesine tıklayın.
+8. Satın alımınızı onaylayın ve ETH'nizi Binance Spot Cüzdanınızda görüceksiniz.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - ETH'yi cüzdanınıza çekmek için cüzdan adresinizi çekim beyaz listesine ekleyin. Daha fazla bilgi için buraya tıklayın.
+   - "Cüzdan" düğmesine tıklayın, para çekme seçeneğine tıklayın ve ETH'yi seçin.
+   - Göndermek istediğiniz ETH miktarını ve göndermek istediğiniz güvenilir adresler listesindeki cüzdan adresini girin.
+   - Gönderdiğiniz adresin Arbitrum One üzerindeki Ethereum cüzdan adresiniz olduğundan emin olun.
+   - "Devam" düğmesine tıklayın ve işleminizi onaylayın.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Faturalandırma Hakkında SSS
+
+### Kaç sorguya ihtiyacım olacak?
+
+Kaç sorguya ihtiyacınız olacağını önceden bilmeniz gerekmez. Yalnızca kullandığınız kadar ücretlendirilirsiniz ve istediğiniz zaman hesabınızdan GRT çekebilirsiniz.
+
+Sorgu sayısını fazla tahmin etmenizi öneririz, böylece bakiyenizi sık sık doldurmak zorunda kalmazsınız. Küçük ve orta ölçekli uygulamalar için iyi bir başlangıç tahmini, aylık 1M-2M sorgu ile başlamak ve ilk haftalarda kullanımı yakından izlemektir. Daha büyük uygulamalar için iyi bir tahmin, sitenizin günlük ziyaret sayısını, en aktif sayfanızın açılışta yaptığı sorgu sayısı ile çarpmaktır.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Faturalandırma bakiyemden GRT çekebilir miyim?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### Faturalandırma bakiyem tükendiğinde ne olur? Bir uyarı alacak mıyım?
+
+Faturalandırma bakiyeniz tükenmeden önce birkaç e-posta bildirimi alacaksınız.

From 0532923b7dd7453d53907da58a82ec4d3d5c2d73 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:10 -0500
Subject: [PATCH 1389/3820] New translations billing.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/billing.mdx

diff --git a/website/pages/uk/subgraphs/billing.mdx b/website/pages/uk/subgraphs/billing.mdx
new file mode 100644
index 000000000000..e75de920ae66
--- /dev/null
+++ b/website/pages/uk/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Білінг
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Натисніть на кнопку "Connect Wallet" у правому верхньому куті сторінки. Ви будете перенаправлені на сторінку вибору гаманця. Виберіть той, який вам підходить, і натисніть кнопку "Connect".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Поповнювати та виводити GRT з балансу вашого акаунту.
+- Відстежувати баланс на основі того, скільки GRT ви внесли на рахунок, яку кількість зняли, а також на основі виставлених інвойсів.
+- Автоматично оплачувати інвойси на основі сформованих комісій за запити, якщо на балансі вашого рахунку достатньо GRT.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Натисніть на кнопку "Connect Wallet" у правому верхньому куті сторінки. Ви будете перенаправлені на сторінку вибору гаманця. Виберіть той, який вам підходить, і натисніть кнопку "Connect".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Поповнення GRT за допомогою гаманця з мультипідписами
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 07d762db3bddb7fdd26236d95e8ad25fe8da30d0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:11 -0500
Subject: [PATCH 1390/3820] New translations billing.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/billing.mdx

diff --git a/website/pages/zh/subgraphs/billing.mdx b/website/pages/zh/subgraphs/billing.mdx
new file mode 100644
index 000000000000..76a949784a34
--- /dev/null
+++ b/website/pages/zh/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: 计费
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. 单击页面右上角的“Connect Wallet”（连接钱包）按钮。您将被重定向到钱包选择页面。选择您的钱包，然后单击“Connect”（连接）。
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- 从您的账户余额中添加和提取GRT。
+- 根据您的账户添加的GRT数量、移除的数量和发票，跟踪您的余额。
+- 只要您的账单余额中有足够的GRT，就可以根据生成的查询费用自动支付发票。
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. 单击页面右上角的“Connect Wallet”（连接钱包）按钮。您将被重定向到钱包选择页面。选择您的钱包，然后单击“Connect”（连接）。
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### 使用多签钱包添加GRT
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. 一旦您完成了身份验证，您可以通过在首页横幅上点击“立即购买”按钮来购买ETH。
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. 确认您的购买，您将能够在Binance现货钱包中看到您的ETH。
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - 单击“钱包”按钮，单击提取，然后选择ETH。
+   - 输入您要发送的ETH金额和您要发送到的白名单钱包地址。
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 3a442cf88c873756d79eff0eacae2e944d50a611 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:12 -0500
Subject: [PATCH 1391/3820] New translations billing.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/billing.mdx

diff --git a/website/pages/ur/subgraphs/billing.mdx b/website/pages/ur/subgraphs/billing.mdx
new file mode 100644
index 000000000000..6cddf92fa043
--- /dev/null
+++ b/website/pages/ur/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: بلنگ
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. صفحہ کے اوپری دائیں کونے میں "کنیکٹ والیٹ" بٹن پر کلک کریں۔ آپ کو والیٹ کے انتخاب کے صفحہ پر بھیج دیا جائے گا۔ اپنا والیٹ منتخب کریں اور "کنیکٹ" پر کلک کریں.
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- اپنے اکاؤنٹ بیلنس سے GRT شامل کریں اور نکالیں.
+- آپ نے اپنے اکاؤنٹ بیلنس میں کتنا GRT شامل کیا ہے، آپ نے کتنا ہٹایا ہے، اور اپنے انوائسز کی بنیاد پر اپنے بیلنس کا پتہ رکھیں.
+- جب تک آپ کے اکاؤنٹ بیلنس میں کافی GRT موجود ہے، خود بخود انوائسز تیار کی گئی کیوری کی فیس کی بنیاد پر ادا کریں.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. صفحہ کے اوپری دائیں کونے میں "کنیکٹ والیٹ" بٹن پر کلک کریں۔ آپ کو والیٹ کے انتخاب کے صفحہ پر بھیج دیا جائے گا۔ اپنا والیٹ منتخب کریں اور "کنیکٹ" پر کلک کریں.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### ملٹی سگ والیٹ کا استعمال کرتے ہوئے GRT شامل کرنا
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+یہ بائنینس پر ایتھیریم کی خریداری کے لیے مرحلہ وار گائیڈ ہوگا.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. اپنی شناخت کی تصدیق کرنے کے بعد، ہوم پیج بینر پر "اب خریدیں" بٹن پر کلک کرکے ایتھیریم خریدیں.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. اپنی خریداری کی تصدیق کریں اور آپ اپنے بائننس اسپاٹ والیٹ میں اپنا ایتھیریم دیکھیں گے.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - "والیٹ" بٹن پر کلک کریں، واپس لینے پر کلک کریں، اور ایتھیریم کو منتخب کریں.
+   - ایتھیریم کی وہ رقم درج کریں جسے آپ بھیجنا چاہتے ہیں اور وائٹ لسٹ شدہ والیٹ ایڈریس جس پر آپ اسے بھیجنا چاہتے ہیں.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 7b401061ccc293bbca418abd0de41e1cf9f74cfc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:13 -0500
Subject: [PATCH 1392/3820] New translations billing.mdx (Vietnamese)

---
 website/pages/vi/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/billing.mdx

diff --git a/website/pages/vi/subgraphs/billing.mdx b/website/pages/vi/subgraphs/billing.mdx
new file mode 100644
index 000000000000..55e8f4dc762b
--- /dev/null
+++ b/website/pages/vi/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Billing
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Add and withdraw GRT from your account balance.
+- Keep track of your balances based on how much GRT you have added to your account balance, how much you have removed, and your invoices.
+- Automatically pay invoices based on query fees generated, as long as there is enough GRT in your account balance.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Adding GRT using a multisig wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From ba8bb6360bbbb4aacabcb55fd217b00311a5fba9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:14 -0500
Subject: [PATCH 1393/3820] New translations billing.mdx (Marathi)

---
 website/pages/mr/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/billing.mdx

diff --git a/website/pages/mr/subgraphs/billing.mdx b/website/pages/mr/subgraphs/billing.mdx
new file mode 100644
index 000000000000..060426d3d0eb
--- /dev/null
+++ b/website/pages/mr/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Billing
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. पृष्ठाच्या वरच्या उजव्या कोपर्यात "कनेक्ट वॉलेट" बटणावर क्लिक करा. तुम्हाला वॉलेट निवड पृष्ठावर पुनर्निर्देशित केले जाईल. तुमचे वॉलेट निवडा आणि "कनेक्ट" वर क्लिक करा.
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Add and withdraw GRT from your account balance.
+- तुम्ही तुमच्या खात्यातील शिल्लकमध्ये किती GRT जोडले आहे, तुम्ही किती काढले आहे आणि तुमच्या इनव्हॉइसवर आधारित तुमच्या शिल्लकांचा मागोवा ठेवा.
+- जोपर्यंत तुमच्या खात्यातील शिल्लक पुरेशी GRT आहे तोपर्यंत व्युत्पन्न केलेल्या क्वेरी शुल्कावर आधारित चलन स्वयंचलितपणे भरा.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. पृष्ठाच्या वरच्या उजव्या कोपर्यात "कनेक्ट वॉलेट" बटणावर क्लिक करा. तुम्हाला वॉलेट निवड पृष्ठावर पुनर्निर्देशित केले जाईल. तुमचे वॉलेट निवडा आणि "कनेक्ट" वर क्लिक करा.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Adding GRT using a multisig wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 38919acfc269e4d254e61327bfd1c4c334027673 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:15 -0500
Subject: [PATCH 1394/3820] New translations billing.mdx (Hindi)

---
 website/pages/hi/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/billing.mdx

diff --git a/website/pages/hi/subgraphs/billing.mdx b/website/pages/hi/subgraphs/billing.mdx
new file mode 100644
index 000000000000..aa6549e7164d
--- /dev/null
+++ b/website/pages/hi/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: बिलिंग
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- क्रेडिट/डेबिट कार्ड के साथ बिलिंग सेट करने के लिए, उपयोगकर्ताओं को **Subgraph Studio** (https://thegraph.com/studio/) पर जाना चाहिए।
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. पृष्ठ के ऊपरी दाएं कोने पर "कनेक्ट वॉलेट" बटन पर क्लिक करें। आपको बटुआ चयन पृष्ठ पर पुनर्निर्देशित किया जाएगा। अपना बटुआ चुनें और "कनेक्ट" पर क्लिक करें।
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- अपने खाते की शेष राशि से जीआरटी जोड़ें और निकालें।
+- आपने अपने खाते की शेष राशि में कितना GRT जोड़ा है, आपने कितना निकाला है, और अपने चालानों के आधार पर अपनी शेष राशि का ट्रैक रखें।
+- जब तक आपके खाते की शेष राशि में पर्याप्त GRT है, उत्पन्न क्वेरी शुल्क के आधार पर स्वचालित रूप से चालान का भुगतान करें।
+
+### GRT on Arbitrum or Ethereum
+
+The Graph का बिलिंग सिस्टम Arbitrum पर GRT स्वीकार करता है, और उपयोगकर्ताओं को गैस के लिए Arbitrum पर ETHकी आवश्यकता होगी। जबकि The Graph प्रोटोकॉल Ethereum Mainnet पर शुरू हुआ था, अब सभी गतिविधियाँ, जिसमें बिलिंग कॉन्ट्रैक्ट्स शामिल हैं, Arbitrum One पर हैं।
+
+क्वेरियों के लिए भुगतान करने के लिए, आपको Arbitrum पर GRT की आवश्यकता है। इसे प्राप्त करने के लिए कुछ विभिन्न तरीके यहां दिए गए हैं:
+
+- यदि आपके पास पहले से Ethereum पर GRT है, तो आप इसे Arbitrum पर ब्रिज कर सकते हैं। आप इसे Subgraph Studio में उपलब्ध GRT ब्रिजिंग विकल्प के माध्यम से या निम्नलिखित में से किसी एक ब्रिज का उपयोग करके कर सकते हैं:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- यदि आपके पास पहले से Arbitrum पर संपत्तियाँ हैं, तो आप उन्हें Uniswap जैसे स्वैपिंग प्रोटोकॉल के माध्यम से GRT के लिए स्वैप कर सकते हैं।
+
+- वैकल्पिक रूप से, आप एक विकेंद्रीकृत एक्सचेंज के माध्यम से Arbitrum पर सीधे GRT प्राप्त कर सकते हैं।
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+एक बार जब आप GRT को ब्रिज करते हैं, तो आप इसे अपने बिलिंग बैलेंस में जोड़ सकते हैं।
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. पृष्ठ के ऊपरी दाएं कोने पर "कनेक्ट वॉलेट" बटन पर क्लिक करें। आपको बटुआ चयन पृष्ठ पर पुनर्निर्देशित किया जाएगा। अपना बटुआ चुनें और "कनेक्ट" पर क्लिक करें।
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. पृष्ठ के ऊपरी दाएं कोने में "मैनेज" बटन पर क्लिक करें। "GRT निकालें" चुनें। एक साइड पैनल दिखाई देगा।
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### मल्टीसिग वॉलेट का उपयोग करके जीआरटी जोड़ना
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+आपको यह पहले से नहीं जानना होगा कि आपको कितनी क्वेरीज़ की आवश्यकता होगी। आपको केवल उसी के लिए चार्ज किया जाएगा जो आप उपयोग करते हैं, और आप कभी भी अपने खाते से GRT निकाल सकते हैं।
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### जब मेरा बिलिंग बैलेंस खत्म हो जाता है, तो क्या होगा? क्या मुझे कोई चेतावनी मिलेगी?
+
+You will receive several email notifications before your billing balance runs out.

From 88d1bb750ec05b7edeb695cebdd74ef64d8b0e04 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:16 -0500
Subject: [PATCH 1395/3820] New translations billing.mdx (Swahili)

---
 website/pages/sw/subgraphs/billing.mdx | 214 +++++++++++++++++++++++++
 1 file changed, 214 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/billing.mdx

diff --git a/website/pages/sw/subgraphs/billing.mdx b/website/pages/sw/subgraphs/billing.mdx
new file mode 100644
index 000000000000..55e8f4dc762b
--- /dev/null
+++ b/website/pages/sw/subgraphs/billing.mdx
@@ -0,0 +1,214 @@
+---
+title: Billing
+---
+
+## Querying Plans
+
+There are two plans to use when querying subgraphs on The Graph Network.
+
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+
+<VideoEmbed youtube="Nn771WagX2I" />
+
+## Query Payments with credit card
+
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+  2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
+  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
+- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+
+## Query Payments with GRT
+
+Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+
+- Add and withdraw GRT from your account balance.
+- Keep track of your balances based on how much GRT you have added to your account balance, how much you have removed, and your invoices.
+- Automatically pay invoices based on query fees generated, as long as there is enough GRT in your account balance.
+
+### GRT on Arbitrum or Ethereum
+
+The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+
+To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+
+- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+
+- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+
+- [TransferTo](https://transferto.xyz/swap)
+
+- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+
+- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+
+Once you bridge GRT, you can add it to your billing balance.
+
+### Adding GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. You'll be redirected to the wallet selection page. Select your wallet and click on "Connect".
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
+8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+### Withdrawing GRT using a wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+4. Enter the amount of GRT you would like to withdraw.
+5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
+6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+
+### Adding GRT using a multisig wallet
+
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
+4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
+6. Select the number of months you would like to prepay.
+   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
+   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
+8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+
+- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+
+## Getting GRT
+
+This section will show you how to get GRT to pay for query fees.
+
+### Coinbase
+
+This will be a step by step guide for purchasing GRT on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select GRT.
+5. Select the payment method. Select your preferred payment method.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase. Review your purchase and click "Buy GRT".
+8. Confirm your purchase. Confirm your purchase and you will have successfully purchased GRT.
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the GRT to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the GRT account.
+   - Enter the amount of GRT you want to send and the wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction. -Please note that for larger purchase amounts, Coinbase may require you to wait 7-10 days before transferring the full amount to a wallet.
+
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing GRT on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
+4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
+5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
+6. Select the amount of GRT you want to purchase.
+7. Review your purchase and click "Buy GRT".
+8. Confirm your purchase and you will be able to see your GRT in your Binance Spot Wallet.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select GRT.
+   - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+### Uniswap
+
+This is how you can purchase GRT on Uniswap.
+
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+2. Select the token you want to swap from. Select ETH.
+3. Select the token you want to swap to. Select GRT.
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+4. Enter the amount of ETH you want to swap.
+5. Click "Swap".
+6. Confirm the transaction in your wallet and you wait for the transaction to process.
+
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+
+## Getting Ether
+
+This section will show you how to get Ether (ETH) to pay for transaction fees or gas costs. ETH is necessary to execute operations on the Ethereum network such as transferring tokens or interacting with contracts.
+
+### Coinbase
+
+This will be a step by step guide for purchasing ETH on Coinbase.
+
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will have successfully purchased ETH.
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+   - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
+   - Click on the "Send" button next to the ETH account.
+   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+
+### Binance
+
+This will be a step by step guide for purchasing ETH on Binance.
+
+1. Go to [Binance](https://www.binance.com/en) and create an account.
+2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
+4. Select the currency you want to purchase. Select ETH.
+5. Select your preferred payment method.
+6. Enter the amount of ETH you want to purchase.
+7. Review your purchase and click "Buy ETH".
+8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Click on the "wallet" button, click withdraw, and select ETH.
+   - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
+   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
+   - Click "Continue" and confirm your transaction.
+
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+
+## Billing FAQs
+
+### How many queries will I need?
+
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+
+We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+
+### Can I withdraw GRT from my billing balance?
+
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+
+### What happens when my billing balance runs out? Will I get a warning?
+
+You will receive several email notifications before your billing balance runs out.

From 922e34662dbbc85b3f068d126bd79b971825194a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:18 -0500
Subject: [PATCH 1396/3820] New translations arweave.mdx (Romanian)

---
 .../pages/ro/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/arweave.mdx b/website/pages/ro/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..2372025621d1
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Building Subgraphs on Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+In this guide, you will learn how to build and deploy Subgraphs to index the Arweave blockchain.
+
+## What is Arweave?
+
+The Arweave protocol allows developers to store data permanently and that is the main difference between Arweave and IPFS, where IPFS lacks the feature; permanence, and files stored on Arweave can't be changed or deleted.
+
+Arweave already has built numerous libraries for integrating the protocol in a number of different programming languages. For more information you can check:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## What are Arweave Subgraphs?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Building an Arweave Subgraph
+
+To be able to build and deploy Arweave Subgraphs, you need two packages:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraph's components
+
+There are three components of a subgraph:
+
+### 1. Manifest - `subgraph.yaml`
+
+Defines the data sources of interest, and how they should be processed. Arweave is a new kind of data source.
+
+### 2. Schema - `schema.graphql`
+
+Here you define which data you want to be able to query after indexing your Subgraph using GraphQL. This is actually similar to a model for an API, where the model defines the structure of a request body.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+This is the logic that determines how data should be retrieved and stored when someone interacts with the data sources you are listening to. The data gets translated and is stored based off the schema you have listed.
+
+During subgraph development there are two key commands:
+
+```
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave data sources introduce an optional source.owner field, which is the public key of an Arweave wallet
+
+Arweave data sources support two types of handlers:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> The source.owner can be the owner's address, or their Public Key.
+>
+> Transactions are the building blocks of the Arweave permaweb and they are objects created by end-users.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Querying an Arweave Subgraph
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here is an example subgraph for reference:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### Can a subgraph index Arweave and other chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can I index the stored files on Arweave?
+
+Currently, The Graph is only indexing Arweave as a blockchain (its blocks and transactions).
+
+### Can I identify Bundlr bundles in my subgraph?
+
+This is not currently supported.
+
+### How can I filter transactions to a specific account?
+
+The source.owner can be the user's public key or account address.
+
+### What is the current encryption format?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From c9a81134d1653e57f6fa690ac7068d2e666609b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:19 -0500
Subject: [PATCH 1397/3820] New translations arweave.mdx (French)

---
 .../pages/fr/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/arweave.mdx b/website/pages/fr/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..e803b644d2cf
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Construction de subgraphs pour Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+Dans ce guide, vous apprendrez comment créer et déployer des subgraphs pour indexer la blockchain Arweave.
+
+## Qu’est-ce qu’Arweave ?
+
+Arweave est un protocole qui permet aux développeurs de stocker des données de façon permanente. C'est cette caractéristique qui constitue la principale différence entre Arweave et IPFS. En effet, IPFS n'a pas la caractéristique de permanence, et les fichiers stockés sur Arweave ne peuvent pas être modifiés ou supprimés.
+
+Arweave a déjà construit de nombreuses bibliothèques pour intégrer le protocole dans plusieurs langages de programmation différents. Pour plus d'informations, vous pouvez consulter :
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## À quoi servent les subgraphes d'Arweave ?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Construire un subgraph Arweave
+
+Pour pouvoir créer et déployer des Arweave Subgraphs, vous avez besoin de deux packages :
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Caractéristique des subgraphs
+
+Il y a trois composants d'un subgraph :
+
+### 1. Manifest - `subgraph.yaml`
+
+Définit les sources de données intéressantes et la manière dont elles doivent être traitées. Arweave est un nouveau type de source de données.
+
+### 2. Schema - `schema.graphql`
+
+Vous définissez ici les données que vous souhaitez pouvoir interroger après avoir indexé votre subgraph à l'aide de GraphQL. Ceci est en fait similaire à un modèle pour une API, où le modèle définit la structure d'un corps de requête.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+Il s'agit de la logique qui détermine comment les données doivent être récupérées et stockées lorsqu'une personne interagit avec les sources de données que vous interrogez. Les données sont traduites et stockées sur la base du schema que vous avez répertorié.
+
+Lors du développement du subgraph, il y a deux commandes clés :
+
+```
+$ graph codegen # génère des types à partir du fichier de schéma identifié dans le manifeste
+$ graph build # génère le Web Assembly à partir des fichiers AssemblyScript, et prépare tous les fichiers de subgraphes dans un dossier /build
+```
+
+## Définition du manifeste du subgraph
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # lien vers le fichier de schéma
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph ne supporte que le Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # La clé publique d'un porte-monnaie Arweave
+      startBlock: 0 # mettez cette valeur à 0 pour commencer l'indexation à partir de la genèse de la chaîne.
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # lien vers le fichier contenant les mappages d'Assemblyscript
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # le nom de la fonction dans le fichier de mapping
+      transactionHandlers:
+        - handler: handleTx # le nom de la fonction dans le fichier de mapping
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Les sources de données Arweave introduisent un champ source.owner facultatif, qui est la clé publique d'un portefeuille Arweave
+
+Les sources de données Arweave prennent en charge deux types de gestionnaires :
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> Source.owner peut être l’adresse du propriétaire ou sa clé publique.
+>
+> Les transactions sont les éléments constitutifs du permaweb Arweave et ce sont des objets créés par les utilisateurs finaux.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Définition de schéma
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## Cartographies AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Déploiement d'un subgraph Arweave dans Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Interroger un subgraph d'Arweave
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Exemples de subgraphs
+
+Voici un exemple de modèle subgraph :
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## Questions fréquemment posées
+
+### Un subgraph peut-il indexer Arweave et d'autres chaînes ?
+
+Non, un subgraph ne peut supporter que les sources de données d'une seule chaîne/réseau.
+
+### Puis-je indexer les fichiers enregistrés sur Arweave ?
+
+Actuellement, The Graph n'indexe Arweave qu'en tant que blockchain (ses blocs et ses transactions).
+
+### Puis-je identifier les bundles de Bundlr dans mon subgraph ?
+
+Cette fonction n'est pas prise en charge actuellement.
+
+### Comment puis-je filtrer les transactions sur un compte spécifique ?
+
+La source.owner peut être la clé publique de l'utilisateur ou l'adresse de son compte.
+
+### Quel est le format de chiffrement actuel ?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 8f1ee12bd3e300d4c5c21e4ed25ffde6095506e5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:20 -0500
Subject: [PATCH 1398/3820] New translations arweave.mdx (Spanish)

---
 .../pages/es/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/es/subgraphs/cookbook/arweave.mdx b/website/pages/es/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..73dff8fd44bb
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Construyendo Subgrafos en Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+En esta guía, aprenderás a construir y deployar subgrafos para indexar la blockchain de Arweave.
+
+## ¿Qué es Arweave?
+
+El protocolo Arweave permite a los developers almacenar datos de forma permanente y esa es la principal diferencia entre Arweave e IPFS, donde IPFS carece de la característica; permanencia, y los archivos almacenados en Arweave no pueden ser modificados o eliminados.
+
+Arweave ya ha construido numerosas bibliotecas para integrar el protocolo en varios lenguajes de programación. Para más información puede consultar:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## ¿Qué son los subgrafos Arweave?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Construcción de un subgrafo Arweave
+
+Para poder construir y deployar subgrafos Arweave, necesita dos paquetes:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Componentes del subgrafo
+
+Hay tres componentes de un subgrafo:
+
+### 1. Manifest - `subgraph.yaml`
+
+Define las fuentes de datos de interés y cómo deben ser procesadas. Arweave es un nuevo tipo de fuente de datos.
+
+### 2. Schema - `schema.graphql`
+
+Aquí defines qué datos quieres poder consultar después de indexar tu Subgrafo usando GraphQL. Esto es en realidad similar a un modelo para una API, donde el modelo define la estructura de un cuerpo de solicitud.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+Esta es la lógica que determina cómo los datos deben ser recuperados y almacenados cuando alguien interactúa con las fuentes de datos que estás escuchando. Los datos se traducen y se almacenan basándose en el esquema que has listado.
+
+Durante el desarrollo del subgrafo hay dos comandos clave:
+
+```
+$ graph codegen # genera tipos a partir del archivo de esquema identificado en el manifiesto
+$ graph build # genera Web Assembly a partir de los archivos de AssemblyScript y prepara todos los archivos de subgrafo en una carpeta /build
+```
+
+## Definición de manifiesto del subgrafo
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+descripción: Indexación de bloques Arweave
+esquema:
+   file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+     source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Las fuentes de datos de Arweave introducen un campo opcional "source.owner", que es la clave pública de una billetera Arweave
+
+Las fuentes de datos de Arweave admiten dos tipos de handlers:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> El source.owner puede ser la dirección del propietario o su clave pública.
+>
+> Las transacciones son los bloques de construcción de la permaweb de Arweave y son objetos creados por los usuarios finales.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Definición de esquema
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## Asignaciones de AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Consultando un subgrafo de Arweave
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Subgrafos de ejemplo
+
+A continuación se muestra un ejemplo de subgrafo como referencia:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## Preguntas frecuentes
+
+### ¿Puede un subgrafo indexar Arweave y otras cadenas?
+
+No, un subgrafo sólo puede admitir fuentes de datos de una cadena/red.
+
+### ¿Puedo indexar los archivos almacenados en Arweave?
+
+Actualmente, The Graph sólo indexa Arweave como blockchain (sus bloques y transacciones).
+
+### ¿Puedo identificar los paquetes de Bundlr en mi subgrafo?
+
+Actualmente no se admite.
+
+### ¿Cómo puedo filtrar las transacciones a una cuenta específica?
+
+El source.owner puede ser la clave pública del usuario o la dirección de la cuenta.
+
+### ¿Cuál es el formato actual de encriptación?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 37f38068e86295bce1061f1c77c5c3c27c03af20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:21 -0500
Subject: [PATCH 1399/3820] New translations arweave.mdx (Arabic)

---
 .../pages/ar/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/arweave.mdx b/website/pages/ar/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..d141d4e3a27d
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Building Subgraphs on Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+In this guide, you will learn how to build and deploy Subgraphs to index the Arweave blockchain.
+
+## What is Arweave?
+
+The Arweave protocol allows developers to store data permanently and that is the main difference between Arweave and IPFS, where IPFS lacks the feature; permanence, and files stored on Arweave can't be changed or deleted.
+
+Arweave already has built numerous libraries for integrating the protocol in a number of different programming languages. For more information you can check:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## What are Arweave Subgraphs?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Building an Arweave Subgraph
+
+To be able to build and deploy Arweave Subgraphs, you need two packages:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraph's components
+
+There are three components of a subgraph:
+
+### 1. Manifest - `subgraph.yaml`
+
+Defines the data sources of interest, and how they should be processed. Arweave is a new kind of data source.
+
+### 2. Schema - `schema.graphql`
+
+Here you define which data you want to be able to query after indexing your Subgraph using GraphQL. This is actually similar to a model for an API, where the model defines the structure of a request body.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+This is the logic that determines how data should be retrieved and stored when someone interacts with the data sources you are listening to. The data gets translated and is stored based off the schema you have listed.
+
+During subgraph development there are two key commands:
+
+```
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+## تعريف Subgraph Manifest
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave data sources introduce an optional source.owner field, which is the public key of an Arweave wallet
+
+Arweave data sources support two types of handlers:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> The source.owner can be the owner's address, or their Public Key.
+>
+> Transactions are the building blocks of the Arweave permaweb and they are objects created by end-users.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## تعريف المخطط
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Querying an Arweave Subgraph
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## أمثلة على الـ Subgraphs
+
+Here is an example subgraph for reference:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## الأسئلة الشائعة
+
+### Can a subgraph index Arweave and other chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can I index the stored files on Arweave?
+
+Currently, The Graph is only indexing Arweave as a blockchain (its blocks and transactions).
+
+### Can I identify Bundlr bundles in my subgraph?
+
+This is not currently supported.
+
+### How can I filter transactions to a specific account?
+
+The source.owner can be the user's public key or account address.
+
+### What is the current encryption format?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 6519a1eb7dc8ae416af6f56d1385e904df2df488 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:22 -0500
Subject: [PATCH 1400/3820] New translations arweave.mdx (Czech)

---
 .../pages/cs/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/arweave.mdx b/website/pages/cs/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..d59897ad4e03
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Vytváření podgrafů na Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+V této příručce se dozvíte, jak vytvořit a nasadit subgrafy pro indexování blockchainu Arweave.
+
+## Co je Arweave?
+
+Protokol Arweave umožňuje vývojářům ukládat data trvale a to je hlavní rozdíl mezi Arweave a IPFS, kde IPFS tuto funkci postrádá; trvalé uložení a soubory uložené na Arweave nelze měnit ani mazat.
+
+Společnost Arweave již vytvořila řadu knihoven pro integraci protokolu do řady různých programovacích jazyků. Další informace naleznete zde:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## Co jsou podgrafy Arweave?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Vytvoření podgrafu Arweave
+
+Abyste mohli sestavit a nasadit Arweave Subgraphs, potřebujete dva balíčky:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Komponenty podgrafu
+
+Podgraf má tři Komponenty:
+
+### 1. Manifest - `subgraph.yaml`
+
+Definuje zdroje dat, které jsou předmětem zájmu, a způsob jejich zpracování. Arweave je nový druh datového zdroje.
+
+### 2. Schema - `schema.graphql`
+
+Zde definujete, na která data se chcete po indexování subgrafu pomocí jazyka GraphQL dotazovat. Je to vlastně podobné modelu pro API, kde model definuje strukturu těla požadavku.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+Jedná se o logiku, která určuje, jak mají být data načtena a uložena, když někdo komunikuje se zdroji dat, kterým nasloucháte. Data se přeloží a uloží na základě schématu, které jste uvedli.
+
+Při vývoji podgrafů existují dva klíčové příkazy:
+
+```
+$ graph codegen # generuje typy ze souboru se schématem identifikovaným v manifestu
+$ graph build # vygeneruje webové sestavení ze souborů AssemblyScript a připraví všechny dílčí soubory do složky /build
+```
+
+## Definice podgrafu Manifest
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Zdroje dat Arweave obsahují nepovinné pole source.owner, což je veřejný klíč peněženky Arweave
+
+Datové zdroje Arweave podporují dva typy zpracovatelů:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> Source.owner může být adresa vlastníka nebo jeho veřejný klíč.
+>
+> Transakce jsou stavebními kameny permaweb Arweave a jsou to objekty vytvořené koncovými uživateli.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Definice schématu
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript Mapování
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Nasazení podgrafu Arweave v Podgraf Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Dotazování podgrafu Arweave
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Příklady podgrafů
+
+Zde je příklad podgrafu pro referenci:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### Může podgraf indexovat Arweave a další řetězce?
+
+Ne, podgraf může podporovat zdroje dat pouze z jednoho řetězce/sítě.
+
+### Mohu indexovat uložené soubory v Arweave?
+
+V současné době The Graph indexuje pouze Arweave jako blockchain (jeho bloky a transakce).
+
+### Mohu identifikovat svazky Bundlr ve svém podgrafu?
+
+Toto není aktuálně podporováno.
+
+### Jak mohu filtrovat transakce na určitý účet?
+
+Source.owner může být veřejný klíč uživatele nebo adresa účtu.
+
+### Jaký je aktuální formát šifrování?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From d43395eddb71fbe26168d2b9ebfd0f55ebb901e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:23 -0500
Subject: [PATCH 1401/3820] New translations arweave.mdx (German)

---
 .../pages/de/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/de/subgraphs/cookbook/arweave.mdx b/website/pages/de/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..02dd4f8398fc
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Building Subgraphs on Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+In this guide, you will learn how to build and deploy Subgraphs to index the Arweave blockchain.
+
+## What is Arweave?
+
+The Arweave protocol allows developers to store data permanently and that is the main difference between Arweave and IPFS, where IPFS lacks the feature; permanence, and files stored on Arweave can't be changed or deleted.
+
+Arweave already has built numerous libraries for integrating the protocol in a number of different programming languages. For more information you can check:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## What are Arweave Subgraphs?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Building an Arweave Subgraph
+
+To be able to build and deploy Arweave Subgraphs, you need two packages:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraph's components
+
+There are three components of a subgraph:
+
+### 1. Manifest - `subgraph.yaml`
+
+Defines the data sources of interest, and how they should be processed. Arweave is a new kind of data source.
+
+### 2. Schema - `schema.graphql`
+
+Here you define which data you want to be able to query after indexing your Subgraph using GraphQL. This is actually similar to a model for an API, where the model defines the structure of a request body.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+This is the logic that determines how data should be retrieved and stored when someone interacts with the data sources you are listening to. The data gets translated and is stored based off the schema you have listed.
+
+During subgraph development there are two key commands:
+
+```
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+## Subgraf-Manifest-Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave data sources introduce an optional source.owner field, which is the public key of an Arweave wallet
+
+Arweave data sources support two types of handlers:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> The source.owner can be the owner's address, or their Public Key.
+>
+> Transactions are the building blocks of the Arweave permaweb and they are objects created by end-users.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Schema-Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript-Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Querying an Arweave Subgraph
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Beispiele von Subgrafen
+
+Here is an example subgraph for reference:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### Can a subgraph index Arweave and other chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can I index the stored files on Arweave?
+
+Currently, The Graph is only indexing Arweave as a blockchain (its blocks and transactions).
+
+### Can I identify Bundlr bundles in my subgraph?
+
+This is not currently supported.
+
+### How can I filter transactions to a specific account?
+
+The source.owner can be the user's public key or account address.
+
+### What is the current encryption format?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From e240542a007f5901d6908b22746eed705de48198 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:24 -0500
Subject: [PATCH 1402/3820] New translations arweave.mdx (Italian)

---
 .../pages/it/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/it/subgraphs/cookbook/arweave.mdx b/website/pages/it/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..2372025621d1
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Building Subgraphs on Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+In this guide, you will learn how to build and deploy Subgraphs to index the Arweave blockchain.
+
+## What is Arweave?
+
+The Arweave protocol allows developers to store data permanently and that is the main difference between Arweave and IPFS, where IPFS lacks the feature; permanence, and files stored on Arweave can't be changed or deleted.
+
+Arweave already has built numerous libraries for integrating the protocol in a number of different programming languages. For more information you can check:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## What are Arweave Subgraphs?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Building an Arweave Subgraph
+
+To be able to build and deploy Arweave Subgraphs, you need two packages:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraph's components
+
+There are three components of a subgraph:
+
+### 1. Manifest - `subgraph.yaml`
+
+Defines the data sources of interest, and how they should be processed. Arweave is a new kind of data source.
+
+### 2. Schema - `schema.graphql`
+
+Here you define which data you want to be able to query after indexing your Subgraph using GraphQL. This is actually similar to a model for an API, where the model defines the structure of a request body.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+This is the logic that determines how data should be retrieved and stored when someone interacts with the data sources you are listening to. The data gets translated and is stored based off the schema you have listed.
+
+During subgraph development there are two key commands:
+
+```
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave data sources introduce an optional source.owner field, which is the public key of an Arweave wallet
+
+Arweave data sources support two types of handlers:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> The source.owner can be the owner's address, or their Public Key.
+>
+> Transactions are the building blocks of the Arweave permaweb and they are objects created by end-users.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Querying an Arweave Subgraph
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here is an example subgraph for reference:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### Can a subgraph index Arweave and other chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can I index the stored files on Arweave?
+
+Currently, The Graph is only indexing Arweave as a blockchain (its blocks and transactions).
+
+### Can I identify Bundlr bundles in my subgraph?
+
+This is not currently supported.
+
+### How can I filter transactions to a specific account?
+
+The source.owner can be the user's public key or account address.
+
+### What is the current encryption format?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 51cd4f42e6cec6d9bc88cc56943c31a81c535ebc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:25 -0500
Subject: [PATCH 1403/3820] New translations arweave.mdx (Japanese)

---
 .../pages/ja/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/arweave.mdx b/website/pages/ja/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..db68d023752a
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Arweaveでのサブグラフ構築
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+このガイドでは、Arweaveブロックチェーンのインデックスを作成するためのサブグラフの構築とデプロイ方法について学びます。
+
+## Arweaveとは？
+
+Arweave プロトコルは、開発者がデータを永久に保存することを可能にし、それが Arweave と IPFS の主な違いです。IPFSは永続性に欠ける一方、Arweaveに保存されたファイルは変更も削除もできません。
+
+Arweaveは既に、さまざまなプログラミング言語でプロトコルを統合するための多数のライブラリを構築しています。詳細については、次を確認できます。
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## Arweaveサブグラフとは？
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Arweave サブグラフの作成
+
+Arweaveのサブグラフを構築し展開できるようにするためには、2つのパッケージが必要です。
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## サブグラフのコンポーネント
+
+サブグラフには3つの構成要素があります:
+
+### 1. Manifest - `subgraph.yaml`
+
+対象のデータ ソースとその処理方法を定義します。 Arweave は新しい種類のデータ ソースです。
+
+### 2. Schema - `schema.graphql`
+
+ここでは、GraphQL を使用してサブグラフにインデックスを付けた後にクエリできるようにするデータを定義します。これは実際には API のモデルに似ており、モデルはリクエスト本文の構造を定義します。
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+これは、リスニングしているデータソースと誰かがやりとりするときに、データをどのように取得し、保存するかを決定するロジックです。データは変換され、あなたがリストアップしたスキーマに基づいて保存されます。
+
+サブグラフの開発には 2 つの重要なコマンドがあります:
+
+```
+$ graph codegen # マニフェストで識別されたようにファイルから型を生成します
+$ グラフ ビルド # AssemblyScript ファイルから Web アセンブリを生成し、/build フォルダにすべてのサブグラフ ファイルを準備します
+```
+
+## サブグラフマニフェストの定義
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave データ ソースには、オプションの source.owner フィールドが導入されています。これは、Arweave ウォレットの公開鍵です。
+
+Arweaveデータソースは 2 種類のハンドラーをサポートしています:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> Source.owner は、所有者のアドレスまたは公開鍵にすることができます。
+>
+> トランザクションはArweave permawebの構成要素であり、エンドユーザーによって作成されるオブジェクトです。
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## スキーマ定義
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript マッピング
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Arweaveサブグラフのクエリ
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## サブグラフの例
+
+参考までにサブグラフの例を紹介します:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## よくある質問
+
+### サブグラフは Arweave やその他のチェーンにインデックスを付けることができますか?
+
+いいえ、サブグラフは 1 つのチェーン/ネットワークのデータソースのみをサポートします。
+
+### 保存されたファイルをArweaveでインデックス化することはできますか？
+
+現在、The Graph は Arweave をブロックチェーン (ブロックとトランザクション) としてのみインデックス化しています。
+
+### 自分のサブグラフにあるBundlrバンドルは特定できるのか？
+
+現在はサポートされていません。
+
+### トランザクションを特定のアカウントにフィルターするにはどうすればよいですか?
+
+Source.ownerには、ユーザの公開鍵またはアカウントアドレスを指定することができます。
+
+### 現在の暗号化フォーマットは？
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From e65fef78a34e5a2486c98dbeeb607d1d18c2d5e5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:26 -0500
Subject: [PATCH 1404/3820] New translations arweave.mdx (Korean)

---
 .../pages/ko/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/arweave.mdx b/website/pages/ko/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..2372025621d1
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Building Subgraphs on Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+In this guide, you will learn how to build and deploy Subgraphs to index the Arweave blockchain.
+
+## What is Arweave?
+
+The Arweave protocol allows developers to store data permanently and that is the main difference between Arweave and IPFS, where IPFS lacks the feature; permanence, and files stored on Arweave can't be changed or deleted.
+
+Arweave already has built numerous libraries for integrating the protocol in a number of different programming languages. For more information you can check:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## What are Arweave Subgraphs?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Building an Arweave Subgraph
+
+To be able to build and deploy Arweave Subgraphs, you need two packages:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraph's components
+
+There are three components of a subgraph:
+
+### 1. Manifest - `subgraph.yaml`
+
+Defines the data sources of interest, and how they should be processed. Arweave is a new kind of data source.
+
+### 2. Schema - `schema.graphql`
+
+Here you define which data you want to be able to query after indexing your Subgraph using GraphQL. This is actually similar to a model for an API, where the model defines the structure of a request body.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+This is the logic that determines how data should be retrieved and stored when someone interacts with the data sources you are listening to. The data gets translated and is stored based off the schema you have listed.
+
+During subgraph development there are two key commands:
+
+```
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave data sources introduce an optional source.owner field, which is the public key of an Arweave wallet
+
+Arweave data sources support two types of handlers:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> The source.owner can be the owner's address, or their Public Key.
+>
+> Transactions are the building blocks of the Arweave permaweb and they are objects created by end-users.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Querying an Arweave Subgraph
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here is an example subgraph for reference:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### Can a subgraph index Arweave and other chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can I index the stored files on Arweave?
+
+Currently, The Graph is only indexing Arweave as a blockchain (its blocks and transactions).
+
+### Can I identify Bundlr bundles in my subgraph?
+
+This is not currently supported.
+
+### How can I filter transactions to a specific account?
+
+The source.owner can be the user's public key or account address.
+
+### What is the current encryption format?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 5843b3582f010d6a068f8c1b4c507817140b4f51 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:27 -0500
Subject: [PATCH 1405/3820] New translations arweave.mdx (Dutch)

---
 .../pages/nl/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/arweave.mdx b/website/pages/nl/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..1ff7fdd460fc
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Bouwen van Subgraphs op Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+In deze gids, zul je leren hoe je Subgraphs bouwt en implementeer om de Arweave blockchain te indexeren.
+
+## Wat is Arweave?
+
+Het Arweave protocol stelt ontwikkelaars in staat om gegevens permanent op te slaan, dat is het voornaamste verschil tussen Arweave en IPFS, waar IPFS deze functie mist, en bestanden die op Arweave zijn opgeslagen, kunnen niet worden gewijzigd of verwijderd.
+
+Arweave heeft al talloze bibliotheken gebouwd voor het integreren van het protocol in verschillende programmeertalen. Voor meer informatie kun je kijken op:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## Wat zijn Arweave Subgraphs?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Bouwen van een Arweave Subgraph
+
+Voor het kunnen bouwen en implementeren van Arweave Subgraphs, heb je twee paketten nodig:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraph's componenten
+
+Er zijn drie componenten van een subgraph:
+
+### 1. Manifest - `subgraph.yaml`
+
+Definieert gegevensbronnen die van belang zijn en hoe deze verwerkt moeten worden. Arweave is een nieuw type gegevensbron.
+
+### 2. Schema - `schema.graphql`
+
+Hier definieer je welke gegevens je wilt kunnen opvragen na het indexeren van je subgraph door het gebruik van GraphQL. Dit lijkt eigenlijk op een model voor een API, waarbij het model de structuur van een verzoek definieert.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+Dit is de logica die definieert hoe data zou moeten worden opgevraagd en opgeslagen wanneer iemand met de gegevens communiceert waarnaar jij aan het luisteren bent. De gegevens worden vertaald en is opgeslagen gebaseerd op het schema die je genoteerd hebt.
+
+Tijdens subgraph ontwikkeling zijn er twee belangrijke commando's:
+
+```
+$ graph codegen # genereert types van het schema bestand die geïdentificeerd is in het manifest
+$ graph build # genereert Web Assembly vanuit de AssemblyScript-bestanden, en bereidt alle Subgraph-bestanden voor in een /build map
+```
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersie: 0.0.5
+omschrijving: Arweave Blocks Indexing
+schema:
+  bestand: ./schema.graphql # link to the schema file
+dataSources:
+  - type: arweave
+    naam: arweave-blocks
+    netwerk: arweave-mainnet # The Graph only supports Arweave Mainnet
+    bron:
+      eigenaar: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    toewijzing:
+      apiVersie: 0.0.5
+      taal: wasm/assemblyscript
+      bestand: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entiteit:
+        - Block
+        - Transaction
+      blockAfhandelaar:
+        - afhandelaar: handleBlock # the function name in the mapping file
+      transactieAfhandelaar:
+        - afhandelaar: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave data bronnen introduceert een optionele bron.eigenaar veld, dat de openbare sleutel is van een Arweave wallet
+
+Arweave data bronnen ondersteunt twee typen verwerkers:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> The source.owner can be the owner's address, or their Public Key.
+>
+> Transactions are the building blocks of the Arweave permaweb and they are objects created by end-users.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Querying an Arweave Subgraph
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here is an example subgraph for reference:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### Can a subgraph index Arweave and other chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can I index the stored files on Arweave?
+
+Currently, The Graph is only indexing Arweave as a blockchain (its blocks and transactions).
+
+### Can I identify Bundlr bundles in my subgraph?
+
+This is not currently supported.
+
+### How can I filter transactions to a specific account?
+
+The source.owner can be the user's public key or account address.
+
+### What is the current encryption format?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From af76c17c74bf5a9dc130a2a356b6f4f95fb63740 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:28 -0500
Subject: [PATCH 1406/3820] New translations arweave.mdx (Polish)

---
 .../pages/pl/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/arweave.mdx b/website/pages/pl/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..2372025621d1
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Building Subgraphs on Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+In this guide, you will learn how to build and deploy Subgraphs to index the Arweave blockchain.
+
+## What is Arweave?
+
+The Arweave protocol allows developers to store data permanently and that is the main difference between Arweave and IPFS, where IPFS lacks the feature; permanence, and files stored on Arweave can't be changed or deleted.
+
+Arweave already has built numerous libraries for integrating the protocol in a number of different programming languages. For more information you can check:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## What are Arweave Subgraphs?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Building an Arweave Subgraph
+
+To be able to build and deploy Arweave Subgraphs, you need two packages:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraph's components
+
+There are three components of a subgraph:
+
+### 1. Manifest - `subgraph.yaml`
+
+Defines the data sources of interest, and how they should be processed. Arweave is a new kind of data source.
+
+### 2. Schema - `schema.graphql`
+
+Here you define which data you want to be able to query after indexing your Subgraph using GraphQL. This is actually similar to a model for an API, where the model defines the structure of a request body.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+This is the logic that determines how data should be retrieved and stored when someone interacts with the data sources you are listening to. The data gets translated and is stored based off the schema you have listed.
+
+During subgraph development there are two key commands:
+
+```
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave data sources introduce an optional source.owner field, which is the public key of an Arweave wallet
+
+Arweave data sources support two types of handlers:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> The source.owner can be the owner's address, or their Public Key.
+>
+> Transactions are the building blocks of the Arweave permaweb and they are objects created by end-users.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Querying an Arweave Subgraph
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here is an example subgraph for reference:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### Can a subgraph index Arweave and other chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can I index the stored files on Arweave?
+
+Currently, The Graph is only indexing Arweave as a blockchain (its blocks and transactions).
+
+### Can I identify Bundlr bundles in my subgraph?
+
+This is not currently supported.
+
+### How can I filter transactions to a specific account?
+
+The source.owner can be the user's public key or account address.
+
+### What is the current encryption format?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From b859e4119d3d348d9c966eabe6b9f50ac6573942 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:29 -0500
Subject: [PATCH 1407/3820] New translations arweave.mdx (Portuguese)

---
 .../pages/pt/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/arweave.mdx b/website/pages/pt/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..3bc1d017e7e2
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Construindo Subgraphs no Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+Neste guia, você aprenderá como construir e lançar Subgraphs para indexar a blockchain Arweave.
+
+## O que é o Arweave?
+
+O protocolo Arweave permite que programadores armazenem dados permanentemente. Esta é a grande diferença entre o Arweave e o IPFS, considerando que o IPFS não tem esta característica; a permanência, e os arquivos armazenados no Arweave, não podem ser mudados ou apagados.
+
+O Arweave já construiu várias bibliotecas para integrar o protocolo num número de línguas de programação diferentes. Para mais informações, pode-se conferir:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## O que são Subgraphs no Arweave?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Construindo um Subgraph no Arweave
+
+Para construir e lançar Subgraphs no Arweave, são necessários dois pacotes:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Os componentes de um subgraph
+
+Um subgraph tem três componentes:
+
+### 1. Manifest - `subgraph.yaml`
+
+Define as fontes de dados de interesse, e como elas devem ser processadas. O Arweave é uma nova categoria de fontes de dados.
+
+### 2. Schema - `schema.graphql`
+
+Aqui é possível definir quais dados queres consultar após indexar o seu subgraph utilizando o GraphQL. Isto é como um modelo para uma API, onde o modelo define a estrutura de um órgão de requisito.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+Esta é a lógica que determina como os dados devem ser retirados e armazenados quando alguém interage com as fontes de dados que estás a escutar. Os dados são traduzidos e armazenados baseados no schema que listaste.
+
+Durante o desenvolvimento de um subgraph, existem dois comandos importantes:
+
+```
+$ graph codegen # gera tipos do arquivo de schema identificado no manifest
+$ graph build # gera Web Assembly dos arquivos AssemblyScript, e prepara todos os arquivos do subgraph em uma pasta /build
+```
+
+## Definição de Manifest de Subgraph
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link ao arquivo schema
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph apoia apenas a Mainnet do Arweave
+    source:
+      owner: 'ID-OF-AN-OWNER' # A chave pública de uma carteira no Arweave
+      startBlock: 0 # coloque isto como 0 para começar a indexar da gênese da chain
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link ao arquivo com os mapeamentos no Assemblyscript
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # o nome da função no arquivo de mapeamento
+      transactionHandlers:
+        - handler: handleTx # o nome da função no arquivo de mapeamento
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Fontes de dados no Arweave introduzem um campo <code>source.owner</code> opcional, a chave pública de uma carteira no Arweave
+
+Fontes de dados no Arweave apoiam duas categorias de <i>handlers</i>:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> O <code>source.owner</code> pode ser o endereço do dono, ou sua Chave Pública.
+>
+> Transações são os blocos de construção da permaweb do Arweave, além de serem objetos criados para utilizadores finais.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Definição de Schema
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## Mapeamentos em AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Como lançar um Subgraph no Arweave ao Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Consultando um Subgraph no Arweave
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Exemplos de Subgraphs
+
+Aqui está um exemplo de subgraph para referência:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## Perguntas Frequentes
+
+### Um subgraph pode indexar o Arweave e outras chains?
+
+Não, um subgraph só pode apoiar fontes de dados de apenas uma chain/rede.
+
+### Posso indexar os arquivos armazenados no Arweave?
+
+Atualmente, The Graph apenas indexa o Arweave como uma blockchain (seus blocos e transações).
+
+### Posso identificar pacotes do Bundlr em meu subgraph?
+
+Isto não é apoiado no momento.
+
+### Como posso filtrar transações para uma conta específica?
+
+O <code>source.owner</code> pode ser a chave pública ou o endereço da conta do utilizador.
+
+### Qual é o formato atual de encriptação?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From e2441fb58f0804ac66c27a912367c9fd7501743c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:30 -0500
Subject: [PATCH 1408/3820] New translations arweave.mdx (Russian)

---
 .../pages/ru/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/arweave.mdx b/website/pages/ru/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..dea4407166df
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Создание Субграфов на Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+Из этого руководства Вы узнаете, как создавать и развертывать субграфы для индексации блокчейна Arweave.
+
+## Что такое Arweave?
+
+Протокол Arweave позволяет разработчикам хранить данные на постоянной основе, и в этом основное различие между Arweave и IPFS, поскольку в IPFS отсутствует функция постоянства, а файлы, хранящиеся в Arweave, не могут быть изменены или удалены.
+
+Arweave уже создала множество библиотек для интеграции протокола на нескольких различных языках программирования. С дополнительной информацией Вы можете ознакомиться:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## Что такое субграфы Arweave?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Построение Субграфа на Arweave
+
+Чтобы иметь возможность создавать и развертывать Субграфы на Arweave, Вам понадобятся два пакета:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Составляющие Субграфов
+
+Существует 3 компонента субграфа:
+
+### 1. Manifest - `subgraph.yaml`
+
+Определяет источники данных, представляющие интерес, и то, как они должны обрабатываться. Arweave - это новый вид источника данных.
+
+### 2. Schema - `schema.graphql`
+
+Здесь Вы определяете, какие данные хотите иметь возможность запрашивать после индексации своего субграфа с помощью GraphQL. На самом деле это похоже на модель для API, где модель определяет структуру тела запроса.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+Это логика, которая определяет, как данные должны извлекаться и храниться, когда кто-то взаимодействует с источниками данных, которые Вы отслеживаете. Данные переводятся и сохраняются в соответствии с указанной Вами схемой.
+
+Во время разработки субграфа есть две ключевые команды:
+
+```
+$ graph codegen # генерирует типы из файла схемы, указанного в манифесте
+$ graph build # генерирует Web Assembly из файлов AssemblyScript и подготавливает все файлы субграфа в папке /build
+```
+
+## Определение манифеста субграфа
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # ссылка на файл схемы
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph поддерживает только Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # Открытый ключ кошелька Arweave
+      startBlock: 0 # установите это значение на 0, чтобы начать индексацию с генезиса чейна
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # ссылка на файл с мэппингами Assemblyscript
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # имя функции в файле мэппинга
+      transactionHandlers:
+        - handler: handleTx # имя функции в файле мэппинга
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Источники данных Arweave содержат необязательное поле source.owner, которое является открытым ключом кошелька Arweave
+
+Источники данных Arweave поддерживают два типа обработчиков:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> Source.owner может быть адресом владельца или его Публичным ключом.
+>
+> Транзакции являются строительными блоками Arweave permaweb, и они представляют собой объекты, созданные конечными пользователями.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Определение схемы
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## Мэппинги AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Развертывание субграфа Arweave в Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Запрос субграфа Arweave
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Примеры субграфов
+
+Ниже приведен пример субграфа для справки:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## Часто задаваемые вопросы
+
+### Может ли субграф индексировать Arweave и другие чейны?
+
+Нет, субграф может поддерживать источники данных только из одного чейна/сети.
+
+### Могу ли я проиндексировать сохраненные файлы в Arweave?
+
+В настоящее время The Graph индексирует Arweave только как блокчейн (его блоки и транзакции).
+
+### Могу ли я идентифицировать связки Bundle в своем субграфе?
+
+В настоящее время это не поддерживается.
+
+### Как я могу отфильтровать транзакции по определенному аккаунту?
+
+Source.owner может быть открытым ключом пользователя или адресом учетной записи.
+
+### Каков текущий формат шифрования?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 4f884d5164c9b99af7e1603d4428c0d60fa9cfb7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:32 -0500
Subject: [PATCH 1409/3820] New translations arweave.mdx (Swedish)

---
 .../pages/sv/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/arweave.mdx b/website/pages/sv/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..8a78a4ffa184
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Bygga subgrafer på Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+I den här guiden kommer du att lära dig hur du bygger och distribuerar subgrafer för att indexera Weaver-blockkedjan.
+
+## Vad är Arweave?
+
+Arweave-protokollet tillåter utvecklare att lagra data permanent och det är den största skillnaden mellan Arweave och IPFS, där IPFS saknar funktionen; beständighet och filer lagrade på Arweave kan inte ändras eller raderas.
+
+Arweave har redan byggt ett flertal bibliotek för att integrera protokollet i ett antal olika programmeringsspråk. För mer information kan du kolla:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## Vad är Arweave-subgrafer?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Bygga en Arweave-subgraf
+
+För att kunna bygga och distribuera Arweave Subgraphs behöver du två paket:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraphs komponenter
+
+Det finns tre komponenter i en subgraf:
+
+### 1. Manifest - `subgraph.yaml`
+
+Definierar datakällorna av intresse och hur de ska behandlas. Arweave är en ny typ av datakälla.
+
+### 2. Schema - `schema.graphql`
+
+Här definierar du vilken data du vill kunna fråga efter att du har indexerat din subgrafer med GraphQL. Detta liknar faktiskt en modell för ett API, där modellen definierar strukturen för en begäran.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+Detta är logiken som avgör hur data ska hämtas och lagras när någon interagerar med datakällorna du lyssnar på. Data översätts och lagras utifrån det schema du har listat.
+
+Under subgrafutveckling finns det två nyckelkommandon:
+
+```
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+## Definition av subgraf manifestet
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave datakällor introducerar ett valfritt source.owner fält, som är den publika nyckeln till en Arweave plånbok
+
+Arweave datakällor stöder två typer av hanterare:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> De source.owner kan vara ägarens adress eller deras publika nyckel.
+>
+> Transaktioner är byggstenarna i Arweave permaweb och de är objekt skapade av slutanvändare.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript mappningar
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Fråga efter en Arweave-subgraf
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Exempel på subgrafer
+
+Här är ett exempel på subgraf som referens:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### Kan en subgraf indexera Arweave och andra kedjor?
+
+Nej, en subgraf kan bara stödja datakällor från en kedja/nätverk.
+
+### Kan jag indexera de lagrade filerna på Arweave?
+
+För närvarande indexerar The Graph bara Arweave som en blockkedja (dess block och transaktioner).
+
+### Kan jag identifiera Bundlr buntar i min subgraf?
+
+Detta stöds inte för närvarande.
+
+### Hur kan jag filtrera transaktioner till ett specifikt konto?
+
+Source.owner kan vara användarens publika nyckel eller kontoadress.
+
+### Vad är det aktuella krypteringsformatet?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 2f17ebfef6b37e8fbbbbb6920d6baf56653eae00 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:33 -0500
Subject: [PATCH 1410/3820] New translations arweave.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/arweave.mdx b/website/pages/tr/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..d3eedc2a7dda
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Arweave Üzerinde Subgraphlar Oluşturma
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+Bu rehberde, Arweave blok zincirini indekslemek için nasıl Subgraphs oluşturacağınızı ve dağıtacağınızı öğreneceksiniz.
+
+## Arweave Nedir?
+
+Arweave protokolü geliştiricilere verileri kalıcı olarak depolama imkanı sağlar ve bu, Arweave ile IPFS arasındaki temel farktır. IPFS'de böyle bir özellik bulunmaz; yani IPFS'te depolanan dosyalar kalıcı değildir ve Arweave'de depolanan dosyalar değiştirilemez veya silinemez.
+
+Arweave, protokolü farklı programlama dillerine entegre etmek için halihazırda çok sayıda kütüphane oluşturmuştur. Daha fazla bilgi için şurayı kontrol edebilirsiniz:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## Arweave Subgraphları Nedir?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Bir Arweave Subgraph'ı Oluşturma
+
+Arweave Subgraphları oluşturabilmek ve dağıtabilmek için iki pakete ihtiyacınız vardır:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraph'ın bileşenleri
+
+Bir subgraph'ın üç bileşeni vardır:
+
+### 1. Manifest - `subgraph.yaml`
+
+İlgilenilen veri kaynaklarını ve bunların nasıl işlenmesi gerektiğini tanımlar. Arweave yeni bir veri kaynağı türüdür.
+
+### 2. Schema - `schema.graphql`
+
+Burada, GraphQL kullanarak Subgraph'ınızı indeksledikten sonra hangi verileri sorgulayabilmek istediğinizi tanımlarsınız. Bu aslında, modelin bir istek gövdesinin yapısını tanımladığı bir API modeline benzer.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+Bu, birisi sizin etkinliklerini gözlemlediğiniz veri kaynaklarıyla etkileşimde bulunduğunda verinin nasıl alınması ve depolanması gerektiğini belirleyen mantıktır. Veri çevrilir ve belirttiğiniz şemaya göre depolanır.
+
+Subgraph geliştirme sırasında iki anahtar komut vardır:
+
+```
+$ graph codegen # manifest'de tanımlanan şema dosyasından tipleri üretir
+$ graph build # AssemblyScript dosyalarından Web Assembly oluşturur ve tüm subgraph dosyalarını bir /build klasöründe hazırlar
+```
+
+## Subgraph Manifest Tanımı
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # şema dosyasına bağlantı
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # Graph yalnızca Arweave Ana Ağı'nı destekler
+    source:
+      owner: 'ID-OF-AN-OWNER' # Bir Arweave cüzdanının açık anahtarı
+      startBlock: 0 # indekslemeyi zincir oluşumundan başlatmak için bunu 0 olarak ayarlayın
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # Assemblyscript eşleştirmelerinin bulunduğu dosyaya bağlantı
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # eşleştirme dosyasındaki fonksiyon adı
+      transactionHandlers:
+        - handler: handleTx # eşleştirme dosyasındaki fonksiyon adı
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave veri kaynakları, bir Arweave cüzdanının genel anahtarı olan opsiyonel bir source.owner alanı sunar
+
+Arweave veri kaynakları iki tür işleyiciyi destekler:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> source.owner, sahibin adresi veya Genel Anahtarı olabilir.
+>
+> İşlemler Arweave permaweb'in yapı taşlarıdır ve son kullanıcılar tarafından oluşturulan nesnelerdir.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Şema Tanımı
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript Eşlemeleri
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Arweave Subgraph'ını Sorgulama
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Örnek Subgraph'ler
+
+İşte referans olması için örnek bir subgraph:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## SSS
+
+### Bir subgraph Arweave ve diğer zincirleri indeksleyebilir mi?
+
+Hayır, bir subgraph yalnızca bir zincirden/ağdan veri kaynaklarını destekleyebilir.
+
+### Depolanmış dosyaları Arweave üzerinde indeksleyebilir miyim?
+
+Şu anda Graph, Arweave'yi yalnızca bir blok zinciri (blokları ve işlemleri) olarak indekslemektedir.
+
+### Subgraph'ımdaki Bundlr paketlerini tanımlayabilir miyim?
+
+Bu şu anda desteklenmemektedir.
+
+### İşlemleri belirli bir hesaba özel olarak nasıl filtreleyebilirim?
+
+source.owner kullanıcının genel anahtarı veya hesap adresi olabilir.
+
+### Mevcut şifreleme formatı nedir?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 81963459677f602eff2fc33aaa6279485ec40a1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:34 -0500
Subject: [PATCH 1411/3820] New translations arweave.mdx (Ukrainian)

---
 .../pages/uk/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/arweave.mdx b/website/pages/uk/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..6b54757440a0
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Building Subgraphs on Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+In this guide, you will learn how to build and deploy Subgraphs to index the Arweave blockchain.
+
+## What is Arweave?
+
+The Arweave protocol allows developers to store data permanently and that is the main difference between Arweave and IPFS, where IPFS lacks the feature; permanence, and files stored on Arweave can't be changed or deleted.
+
+Arweave already has built numerous libraries for integrating the protocol in a number of different programming languages. For more information you can check:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## What are Arweave Subgraphs?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Building an Arweave Subgraph
+
+To be able to build and deploy Arweave Subgraphs, you need two packages:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraph's components
+
+There are three components of a subgraph:
+
+### 1. Manifest - `subgraph.yaml`
+
+Defines the data sources of interest, and how they should be processed. Arweave is a new kind of data source.
+
+### 2. Schema - `schema.graphql`
+
+Here you define which data you want to be able to query after indexing your Subgraph using GraphQL. This is actually similar to a model for an API, where the model defines the structure of a request body.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+This is the logic that determines how data should be retrieved and stored when someone interacts with the data sources you are listening to. The data gets translated and is stored based off the schema you have listed.
+
+During subgraph development there are two key commands:
+
+```
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+## Визначення маніфесту підграфів
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave data sources introduce an optional source.owner field, which is the public key of an Arweave wallet
+
+Arweave data sources support two types of handlers:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> The source.owner can be the owner's address, or their Public Key.
+>
+> Transactions are the building blocks of the Arweave permaweb and they are objects created by end-users.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Визначення схеми
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Querying an Arweave Subgraph
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Приклади підграфів
+
+Here is an example subgraph for reference:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### Can a subgraph index Arweave and other chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can I index the stored files on Arweave?
+
+Currently, The Graph is only indexing Arweave as a blockchain (its blocks and transactions).
+
+### Can I identify Bundlr bundles in my subgraph?
+
+This is not currently supported.
+
+### How can I filter transactions to a specific account?
+
+The source.owner can be the user's public key or account address.
+
+### What is the current encryption format?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 673dd2ae099b73a0783a90ec56325b04492798ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:35 -0500
Subject: [PATCH 1412/3820] New translations arweave.mdx (Chinese Simplified)

---
 .../pages/zh/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/arweave.mdx b/website/pages/zh/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..bc4c08e85b11
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: 在 Arweave 上构建子图
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+在本指南中，您将学习如何构建和部署子图以索引Arweave区块链。
+
+## Arweave是什么？
+
+Arweave 协议允许开发者永久存储数据，这是 Arweave 和 IPFS 的主要区别，IPFS 没有这个特性，永久性和存储在 Arweave 上的文件不能被更改或删除。
+
+Arweave 已经构建了许多库，用于将协议集成到许多不同的编程语言中。更多信息可以查看:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## Arweave子图是什么？
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## 构建 Arweave 子图
+
+为了能够构建和部署 Arweave 子图，您需要两个包:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## 子图的组成部分
+
+一个子图有三个组成部分:
+
+### 1. Manifest - `subgraph.yaml`
+
+定义感兴趣的数据源，以及如何处理它们。Arweave是一种新型数据源。
+
+### 2. Schema - `schema.graphql`
+
+在这里，您可以定义在使用 GraphQL 索引子图之后希望能够查询的数据。这实际上类似于 API 的模型，其中模型定义了请求主体的结构。
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+这种逻辑决定了当有人与您正在监听的数据源进行交互时，应该如何检索和存储数据。数据将被翻译并根据您列出的模式进行存储。
+
+在子图开发过程中，有两个关键命令：
+
+```
+$ graph codegen # 从清单中标识的模式文件生成类型
+$ graph build # 从 AssemblyScript 文件生成 Web Assembly，并在 /build 文件夹中准备所有子图文件
+```
+
+## 子图清单定义
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave 数据源引入了一个可选的 source. owner 字段，它是 Arweave 钱包的公钥
+
+Arweave 数据源支持两种类型的处理程序:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> Source.Owner 可以是所有者的地址，也可以是他们的公钥。
+>
+> 交易是 Arweave permaweb 的构建区块，它们是终端用户创建的对象。
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## 模式定义
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript 映射
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## 查询 Arweave 子图
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## 示例子图
+
+下面是一个子图的例子，以供参考:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## 常见问题
+
+### 子图可以索引 Arweave 和其他链吗？
+
+不，子图只能支持来自一个链/网络的数据源。
+
+### 我可以索引存储在 Arweave 上的文件吗？
+
+目前，Graph 只是将 Arweave 索引为区块链(它的区块和交易)。
+
+### 我可以识别我的子图中的 Bundlr 包吗？
+
+目前还不支持。
+
+### 如何筛选特定账户的交易？
+
+Source.owner可以是用户的公钥或账户地址。
+
+### 当前的加密格式是什么？
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From a3bb482325fef2715541fcfaa84cd3cde2b49a2e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:36 -0500
Subject: [PATCH 1413/3820] New translations arweave.mdx (Urdu (Pakistan))

---
 .../pages/ur/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/arweave.mdx b/website/pages/ur/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..035056b7f5a6
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: بناۓ گئے سب گرافز آرویو(Arweave) پر
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+اس گائڈ میں، آپ سیکھیں گے کہ آرویو(Arweave) بلاکچین کو انڈیکس کرنے کیلئے سب گرافز بنانے اور مستعمل کرنے کا طریقہ کار کیسے ہے۔
+
+## آرویو(Arweave) کیا ہے؟
+
+آرویو (Arweave) پروٹوکول ڈیولپرز کو اجازت دیتا کے وہ ڈیٹا کو مستقل طور پر اسٹور کرے اور یہی آرویو(Arweave) اور IPFS میں سب سے بڑا فرق ہے،جہاں IPFS میں خصوصیئت کی کمی ہے؛مستقل مزاجی ، اور فایلز جو آرویو(Arweave) پر اسٹور ہوتی ہیں بدل یا ختم نہیں ہو سکتی.
+
+آرویو(Arweave) نے پہلے ہی بہت سی کتابخانےاں تیار کی ہیں جو مختلف پروگرامنگ زبانوں میں پروٹوکول کو اندر ملانے کے لئے بنائی گئی ہیں۔ مزید معلومات کے لئے آپ یہ چیک کر سکتے ہیں:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## آرویو(Arweave) سب گرافز کیا ہوتے ہیں؟
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## آرویو(Arweave) سب گراف بنانا
+
+آرویو کے سب گراف بنانے اور تعینات کرنے کے لئے،آپ کو دو پیکجوں کی ضرورت ہے:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## سب گراف کے حصے
+
+سب گراف کے تین حصے ہیں:
+
+### 1. Manifest - `subgraph.yaml`
+
+دلچسپی کے ڈیٹا کے ذرایع کو بیان کرتا ہے،اور کیسے ان پر کاروائ کی جاۓ۔ آرویو ایک نئ طرح کا ڈیٹا کا ذریعہ ہے.
+
+### 2. Schema - `schema.graphql`
+
+یہاں آپ بیان کرتے ہیں کے کونسا ڈیٹا آپ کے سب گراف کا کیوری گراف کیو ایل کا استعمال کرتے ہوۓ کر سکے۔یہ دراصل اے پی آی(API) کے ماڈل سے ملتا ہے،جہاں ماڈل درخواست کے جسم کے ڈھانچے کو بیان کرتا ہے.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+یہ وہ منطق جو اس بات کا پتہ لگاتا ہے کے کیسے ڈیٹا کو بازیافت اور مہفوظ کیا جاۓ جب کوئ اس ڈیٹا کے ذخیرہ سے تعامل کرے جسے آپ سن رہے ہیں۔اس ڈیٹا کا ترجمہ کیا جاتا ہے اور آپ کے درج کردہ اسکیما کی بنیاد پر مہفوظ کیا جاتا ہے.
+
+سب گراف کی ترقی کے دوران دو اہم کمانڈز ہیں:
+
+```
+$graph codegen # ظاہر میں شناخت کردہ اسکیما فائل سے اقسام تیار کرتا ہے۔
+$graph build # اسمبلی سکرپٹ فائلوں سے ویب اسمبلی تیار کرتا ہے، اور تمام ذیلی گراف فائلوں کو /build فولڈر میں تیار کرتا ہے۔
+```
+
+## سب گراف مینی فیسٹ کی تعریف
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- آرویو ڈیٹا کے ذرائع ایک اختیاری source.owner فیلڈ متعارف کراتے ہیں، جو آرویو والیٹ کی عوامی کلید ہے
+
+آرویو ڈیٹا کے ذرائع دو قسم کے ہینڈلرز کو سپورٹ کرتے ہیں:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> Source.owner مالک کا پتہ، یا ان کی عوامی کلید ہو سکتا ہے.
+>
+> ٹرانزیکشنز آرویو پرما ویب کے تعمیراتی بلاکس ہیں اور یہ آخری صارفین کے ذریعہ تخلیق کردہ اشیاء ہیں.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## اسکیما کی تعریف
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## اسمبلی اسکرپٹ سب میپنک
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## آرویو سب گراف سے کیوری کرنا
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## سب گراف کی مثال
+
+حوالہ کے لیے سب گراف کی ایک مثال یہ ہے:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### کیا ایک سب گراف آرویو اور دیگر چینس کو انڈیکس کر سکتا ہے؟
+
+نہیں، ایک سب گراف صرف ایک چین/نیٹ ورک سے ڈیٹا کے ذرائع کو سپورٹ کر سکتا ہے.
+
+### کیا میں آرویو پر ذخیرہ شدہ فائلوں کو انڈیکس کر سکتا ہوں؟
+
+فی الحال، دی گراف صرف آرویو کو بلاک چین (اس کے بلاکس اور لین دین) کے طور پر ترتیب دے رہا ہے.
+
+### کیا میں اپنے سب گراف میں Bundlr کے بنڈلوں کی شناخت کر سکتا ہوں؟
+
+یہ فی الحال سپورٹڈ نہیں ہے.
+
+### میں کسی مخصوص اکاؤنٹ میں لین دین کو کیسے فلٹر کر سکتا ہوں؟
+
+Source.owner صارف کی عوامی کلید یا اکاؤنٹ ایڈریس ہو سکتا ہے.
+
+### موجودہ خفیہ کاری کا فارمیٹ کیا ہے؟
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From be003c69f63ae7e714265dacbc7427ae578ef783 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:37 -0500
Subject: [PATCH 1414/3820] New translations arweave.mdx (Vietnamese)

---
 .../pages/vi/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/arweave.mdx b/website/pages/vi/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..dc006d5e68dc
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Building Subgraphs on Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+In this guide, you will learn how to build and deploy Subgraphs to index the Arweave blockchain.
+
+## What is Arweave?
+
+The Arweave protocol allows developers to store data permanently and that is the main difference between Arweave and IPFS, where IPFS lacks the feature; permanence, and files stored on Arweave can't be changed or deleted.
+
+Arweave already has built numerous libraries for integrating the protocol in a number of different programming languages. For more information you can check:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## What are Arweave Subgraphs?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Building an Arweave Subgraph
+
+To be able to build and deploy Arweave Subgraphs, you need two packages:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraph's components
+
+There are three components of a subgraph:
+
+### 1. Manifest - `subgraph.yaml`
+
+Defines the data sources of interest, and how they should be processed. Arweave is a new kind of data source.
+
+### 2. Schema - `schema.graphql`
+
+Here you define which data you want to be able to query after indexing your Subgraph using GraphQL. This is actually similar to a model for an API, where the model defines the structure of a request body.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+This is the logic that determines how data should be retrieved and stored when someone interacts with the data sources you are listening to. The data gets translated and is stored based off the schema you have listed.
+
+During subgraph development there are two key commands:
+
+```
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave data sources introduce an optional source.owner field, which is the public key of an Arweave wallet
+
+Arweave data sources support two types of handlers:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> The source.owner can be the owner's address, or their Public Key.
+>
+> Transactions are the building blocks of the Arweave permaweb and they are objects created by end-users.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Querying an Arweave Subgraph
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here is an example subgraph for reference:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## CÂU HỎI THƯỜNG GẶP
+
+### Can a subgraph index Arweave and other chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can I index the stored files on Arweave?
+
+Currently, The Graph is only indexing Arweave as a blockchain (its blocks and transactions).
+
+### Can I identify Bundlr bundles in my subgraph?
+
+This is not currently supported.
+
+### How can I filter transactions to a specific account?
+
+The source.owner can be the user's public key or account address.
+
+### What is the current encryption format?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 25756ac650eef3375de24be23173eec6148c8bf6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:38 -0500
Subject: [PATCH 1415/3820] New translations arweave.mdx (Marathi)

---
 .../pages/mr/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/arweave.mdx b/website/pages/mr/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..2b43324539b9
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Arweave वर सबग्राफ तयार करणे
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+या मार्गदर्शकामध्ये, तुम्ही Arweave ब्लॉकचेन इंडेक्स करण्यासाठी सबग्राफ कसे तयार करावे आणि कसे तैनात करावे ते शिकाल.
+
+## Arweave काय आहे?
+
+Arweave प्रोटोकॉल विकसकांना कायमस्वरूपी डेटा संचयित करण्याची परवानगी देतो आणि Arweave आणि IPFS मधील मुख्य फरक आहे, जेथे IPFS मध्ये वैशिष्ट्याचा अभाव आहे; कायमस्वरूपी, आणि Arweave वर संचयित केलेल्या फायली बदलल्या किंवा हटवल्या जाऊ शकत नाहीत.
+
+अनेक वेगवेगळ्या प्रोग्रामिंग भाषांमध्ये प्रोटोकॉल समाकलित करण्यासाठी Arweave ने आधीच असंख्य लायब्ररी तयार केल्या आहेत. अधिक माहितीसाठी तुम्ही तपासू शकता:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## Arweave Subgraphs काय आहेत?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Arweave Subgraph तयार करणे
+
+Arweave Subgraphs तयार आणि तैनात करण्यात सक्षम होण्यासाठी, तुम्हाला दोन पॅकेजेसची आवश्यकता आहे:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## सबग्राफचे घटक
+
+सबग्राफचे तीन घटक आहेत:
+
+### 1. Manifest - `subgraph.yaml`
+
+स्वारस्य असलेल्या डेटा स्रोतांची व्याख्या करते आणि त्यांची प्रक्रिया कशी करावी. Arweave हा एक नवीन प्रकारचा डेटा स्रोत आहे.
+
+### 2. Schema - `schema.graphql`
+
+GraphQL वापरून तुमचा सबग्राफ इंडेक्स केल्यानंतर तुम्ही कोणता डेटा क्वेरी करू इच्छिता ते येथे तुम्ही परिभाषित करता. हे प्रत्यक्षात API च्या मॉडेलसारखेच आहे, जेथे मॉडेल विनंती मुख्य भागाची रचना परिभाषित करते.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+जेव्हा तुम्ही ऐकत असलेल्या डेटा स्रोतांशी कोणीतरी संवाद साधते तेव्हा डेटा कसा पुनर्प्राप्त आणि संग्रहित केला जावा हे हे तर्कशास्त्र आहे. डेटा अनुवादित केला जातो आणि तुम्ही सूचीबद्ध केलेल्या स्कीमावर आधारित संग्रहित केला जातो.
+
+सबग्राफ विकासादरम्यान दोन प्रमुख आज्ञा आहेत:
+
+```
+$ graph codegen # मॅनिफेस्टमध्ये ओळखल्या गेलेल्या स्कीमा फाइलमधून प्रकार व्युत्पन्न करते
+$ graph build # असेंबलीस्क्रिप्ट फायलींमधून वेब असेंब्ली तयार करते आणि /बिल्ड फोल्डरमध्ये सर्व सबग्राफ फाइल्स तयार करते
+```
+
+## सबग्राफ मॅनिफेस्ट व्याख्या
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave डेटा स्रोत पर्यायी source.owner फील्ड सादर करतात, जी Arweave वॉलेटची सार्वजनिक की आहे
+
+Arweave डेटा स्रोत दोन प्रकारच्या हँडलरला समर्थन देतात:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> source.owner हा मालकाचा पत्ता किंवा त्यांची सार्वजनिक की असू शकतो.
+>
+> व्यवहार हे Arweave permaweb चे बिल्डिंग ब्लॉक्स आहेत आणि ते अंतिम वापरकर्त्यांनी तयार केलेल्या वस्तू आहेत.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## स्कीमा व्याख्या
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## असेंबलीस्क्रिप्ट मॅपिंग
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## प्रश्न करत आहे Arweave सबग्राफ
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## उदाहरणे सबग्राफ
+
+संदर्भासाठी येथे एक उदाहरण उपग्राफ आहे:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### सबग्राफ इंडेक्स Arweave आणि इतर साखळी करू शकता?
+
+नाही, सबग्राफ केवळ एका साखळी/नेटवर्कमधील डेटा स्रोतांना समर्थन देऊ शकतो.
+
+### मी Arweave वर संग्रहित फाइल्स अनुक्रमित करू शकतो?
+
+सध्या, ग्राफ फक्त ब्लॉकचेन (त्याचे ब्लॉक्स आणि व्यवहार) म्हणून Arweave अनुक्रमित करत आहे.
+
+### Currently, The Graph फक्त blockchain (त्याचे blocks आणि transactions) म्हणून Arweave अनुक्रमित करत आहे?
+
+हे सध्या समर्थित नाही.
+
+### मी विशिष्ट खात्यातील व्यवहार कसे फिल्टर करू शकतो?
+
+source.owner वापरकर्त्याची सार्वजनिक की किंवा खाते पत्ता असू शकतो.
+
+### सध्याचे एन्क्रिप्शन स्वरूप काय आहे?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 4c85cecffb97cec66f1aaca3a91fa1a3edbe564a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:39 -0500
Subject: [PATCH 1416/3820] New translations arweave.mdx (Hindi)

---
 .../pages/hi/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/arweave.mdx b/website/pages/hi/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..2d0d6442ef88
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: आरवीव पर सब-ग्राफ्र्स बनाना
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+इस गाइड में आप आरवीव ब्लॉकचेन पर सब ग्राफ्स बनाना और डेप्लॉय करना सीखेंगे!
+
+## आरवीव क्या है?
+
+आरवीव प्रोटोकॉल डेवेलपर्स को स्थायी तौर पर डाटा स्टोर करने की क्षमता देता है जो कि IPFS और आरवीव के बीच का मुख्या अंतर भी है, जहाँ IPFS में इस क्षमता की कमी है, वहीँ आरवीवे पर फाइल्स डिलीट या बदली नहीं जा सकती |
+
+अरवीव द्वारा पहले से ही कई लाइब्रेरी विभिन्न प्रोग्रामिंग भाषाओं में विकशित की गई हैं| अधिक जानकारी के लिए आप इनका रुख कर सकते हैं:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## आरवीवे सब ग्राफ्स क्या हैं?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## एक आरवीव सब ग्राफ बनाना
+
+आरवीवे पर सब ग्राफ बनाने के लिए हमे दो पैकेजेस की जरूरत है:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## सब ग्राफ के कॉम्पोनेन्ट
+
+सब ग्राफ के तीन कॉम्पोनेन्ट होते हैं:
+
+### 1. Manifest - `subgraph.yaml`
+
+डाटा का स्रोत्र और उनको प्रोसेस करने के बारे में बताता है| आरवीव एक नए प्रकार का डाटा सोर्स है|
+
+### 2. Schema - `schema.graphql`
+
+यहाँ आप बताते हैं की आप कौन सा डाटा इंडेक्सिंग के बाद क्वेरी करना चाहते हैं| दरसअल यह एक API के मॉडल जैसा है, जहाँ मॉडल द्वारा रिक्वेस्ट बॉडी का स्ट्रक्चर परिभाषित किया जाता है|
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+यह किसी के द्वारा इस्तेमाल किये जा रहे डाटा सोर्स से डाटा को पुनः प्राप्त करने और स्टोर करने के लॉजिक को बताता है| डाटा अनुवादित होकर आपके द्वारा सूचीबद्ध स्कीमा के अनुसार स्टोर हो जाता है|
+
+सब ग्राफ को बनाते वक़्त दो मुख्य कमांड हैं:
+
+```
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+## सब ग्राफ मैनिफेस्ट की परिभाषा
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- अरवीव डाटा सोर्स द्वारा एक वैकल्पिक source.owner फील्ड लाया गया, जो की एक आरवीव वॉलेट का मपब्लिक key है|
+
+आरवीव डाटा सोर्स द्वारा दो प्रकार के हैंडलर्स उपयोग किये जा सकते हैं:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> यहां source.owner ओनर का एड्रेस या उनका पब्लिक की हो सकता है|
+>
+> ट्रांसक्शन आरवीव परमावेब के लिए निर्माण खंड (बिल्डिंग ब्लॉक्स) की तरह होते हैं और एन्ड-यूजर के द्वारा बनाये गए ऑब्जेक्ट होते हैं|
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## स्कीमा की परिभाषा
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## असेंबली स्क्रिप्ट मैप्पिंग्स
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## आरवीव सब-ग्राफ क्वेरी करना
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## सब-ग्राफ के उदाहरण
+
+सहायता के एक सब-ग्राफ का उदाहरण
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## सामान्य प्रश्न
+
+### क्या एक सब-ग्राफ आरवीव और बाकी चेन्स को इंडेक्स कर सकता है?
+
+नहीं, एक सब-ग्राफ केवल एक चेन/नेटवर्क से डाटा सोर्स को सपोर्ट कर सकता है
+
+### क्या मैं आरवीव पर स्टोर की फाइल्स को इंडेक्स कर सकता हूँ?
+
+वर्तमान में द ग्राफ आरवीव को केवल एक ब्लॉकचेन की तरह इंडेक्स करता है (उसके ब्लॉक्स और ट्रांसक्शन्स)|
+
+### क्या मैं अपने सब-ग्राफ में Bundlr बंडल्स को पहचान सकता हूँ?
+
+यह वर्तमान में सपोर्टेड नहीं है|
+
+### क्या मैं किसी विशिष्ट अकाउंट से ट्रांसक्शन्स छाँट सकता हूँ?
+
+एक यूजर का पब्लिक की या अकाउंट एड्रेस source.owner हो सकता है
+
+### वर्तमान एन्क्रिप्शन फॉर्मेट क्या है?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 049037bdc79fd46a4a857dc530287eac299e4ff4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:40 -0500
Subject: [PATCH 1417/3820] New translations arweave.mdx (Swahili)

---
 .../pages/sw/subgraphs/cookbook/arweave.mdx   | 239 ++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/arweave.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/arweave.mdx b/website/pages/sw/subgraphs/cookbook/arweave.mdx
new file mode 100644
index 000000000000..2372025621d1
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/arweave.mdx
@@ -0,0 +1,239 @@
+---
+title: Building Subgraphs on Arweave
+---
+
+> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+
+In this guide, you will learn how to build and deploy Subgraphs to index the Arweave blockchain.
+
+## What is Arweave?
+
+The Arweave protocol allows developers to store data permanently and that is the main difference between Arweave and IPFS, where IPFS lacks the feature; permanence, and files stored on Arweave can't be changed or deleted.
+
+Arweave already has built numerous libraries for integrating the protocol in a number of different programming languages. For more information you can check:
+
+- [Arwiki](https://arwiki.wiki/#/en/main)
+- [Arweave Resources](https://www.arweave.org/build)
+
+## What are Arweave Subgraphs?
+
+The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+
+[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+
+## Building an Arweave Subgraph
+
+To be able to build and deploy Arweave Subgraphs, you need two packages:
+
+1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
+2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+
+## Subgraph's components
+
+There are three components of a subgraph:
+
+### 1. Manifest - `subgraph.yaml`
+
+Defines the data sources of interest, and how they should be processed. Arweave is a new kind of data source.
+
+### 2. Schema - `schema.graphql`
+
+Here you define which data you want to be able to query after indexing your Subgraph using GraphQL. This is actually similar to a model for an API, where the model defines the structure of a request body.
+
+The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### 3. AssemblyScript Mappings - `mapping.ts`
+
+This is the logic that determines how data should be retrieved and stored when someone interacts with the data sources you are listening to. The data gets translated and is stored based off the schema you have listed.
+
+During subgraph development there are two key commands:
+
+```
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Arweave Blocks Indexing
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: arweave
+    name: arweave-blocks
+    network: arweave-mainnet # The Graph only supports Arweave Mainnet
+    source:
+      owner: 'ID-OF-AN-OWNER' # The public key of an Arweave wallet
+      startBlock: 0 # set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      file: ./src/blocks.ts # link to the file with the Assemblyscript mappings
+      entities:
+        - Block
+        - Transaction
+      blockHandlers:
+        - handler: handleBlock # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTx # the function name in the mapping file
+```
+
+- Arweave subgraphs introduce a new kind of data source (`arweave`)
+- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave data sources introduce an optional source.owner field, which is the public key of an Arweave wallet
+
+Arweave data sources support two types of handlers:
+
+- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
+- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+
+> The source.owner can be the owner's address, or their Public Key.
+>
+> Transactions are the building blocks of the Arweave permaweb and they are objects created by end-users.
+>
+> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+
+## Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+## AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  timestamp: u64
+  lastRetarget: u64
+  height: u64
+  indepHash: Bytes
+  nonce: Bytes
+  previousBlock: Bytes
+  diff: Bytes
+  hash: Bytes
+  txRoot: Bytes
+  txs: Bytes[]
+  walletList: Bytes
+  rewardAddr: Bytes
+  tags: Tag[]
+  rewardPool: Bytes
+  weaveSize: Bytes
+  blockSize: Bytes
+  cumulativeDiff: Bytes
+  hashListMerkle: Bytes
+  poa: ProofOfAccess
+}
+
+class Transaction {
+  format: u32
+  id: Bytes
+  lastTx: Bytes
+  owner: Bytes
+  tags: Tag[]
+  target: Bytes
+  quantity: Bytes
+  data: Bytes
+  dataSize: Bytes
+  dataRoot: Bytes
+  signature: Bytes
+  reward: Bytes
+}
+```
+
+Block handlers receive a `Block`, while transactions receive a `Transaction`.
+
+Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+
+## Deploying an Arweave Subgraph in Subgraph Studio
+
+Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+
+```bash
+graph deploy --access-token <your-access-token>
+```
+
+## Querying an Arweave Subgraph
+
+The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here is an example subgraph for reference:
+
+- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+
+## FAQ
+
+### Can a subgraph index Arweave and other chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can I index the stored files on Arweave?
+
+Currently, The Graph is only indexing Arweave as a blockchain (its blocks and transactions).
+
+### Can I identify Bundlr bundles in my subgraph?
+
+This is not currently supported.
+
+### How can I filter transactions to a specific account?
+
+The source.owner can be the user's public key or account address.
+
+### What is the current encryption format?
+
+Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+
+The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+
+```
+const base64Alphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "+", "/"
+];
+
+const base64UrlAlphabet = [
+	"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M",
+	"N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z",
+	"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m",
+	"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z",
+	"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_"
+];
+
+function bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string {
+	let alphabet = urlSafe? base64UrlAlphabet : base64Alphabet;
+
+	let result = '', i: i32, l = bytes.length;
+	for (i = 2; i < l; i += 3) {
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[((bytes[i - 1] & 0x0F) << 2) | (bytes[i] >> 6)];
+		result += alphabet[bytes[i] & 0x3F];
+	}
+	if (i === l + 1) { // 1 octet yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[(bytes[i - 2] & 0x03) << 4];
+		if (!urlSafe) {
+			result += "==";
+		}
+	}
+	if (!urlSafe && i === l) { // 2 octets yet to write
+		result += alphabet[bytes[i - 2] >> 2];
+		result += alphabet[((bytes[i - 2] & 0x03) << 4) | (bytes[i - 1] >> 4)];
+		result += alphabet[(bytes[i - 1] & 0x0F) << 2];
+		if (!urlSafe) {
+			result += "=";
+		}
+	}
+	return result;
+}
+```

From 718bdc2d422a9b2e609d3681d8fb18eae5afe290 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:41 -0500
Subject: [PATCH 1418/3820] New translations avoid-eth-calls.mdx (Romanian)

---
 .../ro/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/ro/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 80ab2dd278d214c907bf5b2705acf8f063916c13 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:42 -0500
Subject: [PATCH 1419/3820] New translations avoid-eth-calls.mdx (French)

---
 .../fr/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..598d82680af5
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Meilleure Pratique Subgraph 4 - Améliorer la Vitesse d'Indexation en Évitant les eth_calls
+---
+
+## TLDR
+
+Les `eth_calls` sont des appels qui peuvent être faits depuis un subgraph vers un nœud Ethereum. Ces appels prennent un temps considérable pour renvoyer des données, ralentissant ainsi l'indexation. Si possible, concevez des smart contracts pour émettre toutes les données dont vous avez besoin afin de ne pas avoir à utiliser des `eth_calls`.
+
+## Pourquoi Éviter les `eth_calls` est une Bonne Pratique
+
+Les subgraphs sont optimisés pour indexer les données des événements émis par les smart contracts. Un subgraph peut également indexer les données provenant d'un `eth_call`, cependant, cela peut considérablement ralentir l'indexation du subgraph car les `eth_call` nécessitent de faire des appels externes aux smart contracts. La réactivité de ces appels dépend non pas du subgraph mais de la connectivité et de la réactivité du nœud Ethereum interrogé. En minimisant ou en éliminant les `eth_call` dans nos subgraphs, nous pouvons améliorer considérablement notre vitesse d'indexation.
+
+### À quoi ressemble un eth_call ?
+
+Les `eth_calls` sont souvent nécessaires lorsque les données requises pour un subgraph ne sont pas disponibles par le biais d'événements émis. Par exemple, considérons un scénario où un subgraph doit identifier si les tokens ERC20 font partie d'un pool spécifique, mais le contrat n'émet qu'un événement `Transfer` de base et n'émet pas un événement contenant les données dont nous avons besoin :
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+Ceci est beaucoup plus performant car cela a éliminé le besoin de `eth_calls`.
+
+## Comment Optimiser les `eth_calls`
+
+Si la modification du smart contract n'est pas possible et que les `eth_calls` sont nécessaires, lisez "[Améliorer les Performances d'Indexation du Subgraph Facilement : Réduire les eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” par Simon Emanuel Schmid pour apprendre diverses stratégies sur la façon d'optimiser les `eth_calls`.
+
+## Réduire le Surcharge d'Exécution des `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Actuellement, les `eth_calls` ne peuvent être déclarés que pour les gestionnaires d'événements. Dans le manifeste, écrivez
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From fd2ab4cc755ded2d5a4ecc812c0a01665746a78f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:43 -0500
Subject: [PATCH 1420/3820] New translations avoid-eth-calls.mdx (Spanish)

---
 .../es/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/es/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/es/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From cda362e19478b99232a666fc138953c083cc0573 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:44 -0500
Subject: [PATCH 1421/3820] New translations avoid-eth-calls.mdx (Arabic)

---
 .../ar/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/ar/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From c0a8c7876c946ae2683631788ebc16676b5d9a1e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:45 -0500
Subject: [PATCH 1422/3820] New translations avoid-eth-calls.mdx (Czech)

---
 .../cs/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/cs/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..da01b6cad361
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Doporučený postup pro podgraf 4 - Zlepšení rychlosti indexování vyhnutím se eth_calls
+---
+
+## TLDR
+
+`eth_calls` jsou volání, která lze provést z podgrafu do uzlu Ethereum. Tato volání zabírají značnou dobu, než vrátí data, což zpomaluje indexování. Pokud je to možné, navrhněte chytré kontrakty tak, aby emitovaly všechna potřebná data, takže nebudete muset používat `eth_calls`.
+
+## Proč je dobré se vyhnout `eth_calls`
+
+Podgraf jsou optimalizovány pro indexování dat událostí emitovaných z chytré smlouvy. Podgraf může také indexovat data pocházející z `eth_call`, což však může indexování podgrafu výrazně zpomalit, protože `eth_calls` vyžadují externí volání chytrých smluv. Odezva těchto volání nezávisí na podgrafu, ale na konektivitě a odezvě dotazovaného uzlu Ethereum. Minimalizací nebo eliminací eth_calls v našich podgrafech můžeme výrazně zvýšit rychlost indexování.
+
+### Jak vypadá eth_call?
+
+`eth_calls` jsou často nutné, pokud data potřebná pro podgraf nejsou dostupná prostřednictvím emitovaných událostí. Uvažujme například scénář, kdy podgraf potřebuje zjistit, zda jsou tokeny ERC20 součástí určitého poolu, ale smlouva emituje pouze základní událost `Transfer` a neemituje událost, která by obsahovala data, která potřebujeme:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Předpokládejme, že příslušnost tokenů k poolu je určena stavovou proměnnou s názvem `getPoolInfo`. V takovém případě bychom k dotazu na tato data potřebovali použít příkaz `eth_call`:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+To je funkční, ale není to ideální, protože to zpomaluje indexování našeho podgrafu.
+
+## Jak odstranit `eth_calls`
+
+V ideálním případě by měl být inteligentní kontrakt aktualizován tak, aby v rámci událostí vysílal všechna potřebná data. Například úprava inteligentního kontraktu tak, aby v události obsahoval informace o bazénu, by mohla odstranit potřebu `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+Díky této aktualizaci může podgraf přímo indexovat požadovaná data bez externích volání:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+To je mnohem výkonnější, protože to odstranilo potřebu `eth_calls`.
+
+## Jak optimalizovat `eth_calls`
+
+Pokud úprava inteligentního kontraktu není možná a `eth_calls` jsou nutné, přečtěte si článek "[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)" od Simon Emanuel Schmid, kde se dozvíte různé strategie, jak optimalizovat `eth_calls`.
+
+## Snížení běhové režie `eth_calls`
+
+U `eth_calls`, které nelze odstranit, lze jejich režii za běhu minimalizovat jejich deklarací v manifestu. Když `graph-node` zpracovává blok, provede všechny deklarované `eth_calls` paralelně před spuštěním obslužných programů. Volání, která nejsou deklarována, se při běhu obslužných programů provádějí postupně. Zlepšení běhu je způsobeno tím, že se volání provádějí paralelně, nikoliv sekvenčně - to pomáhá zkrátit celkový čas strávený voláním, ale zcela ho neeliminuje.
+
+V současné době lze `eth_calls` deklarovat pouze pro obsluhy událostí. V manifestu napište
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+Žlutě zvýrazněná část je deklarace volání. Část před dvojtečkou je pouze textový popisek, který se používá pouze pro chybová hlášení. Část za dvojtečkou má tvar `Contract[address].function(params)`. Přípustné hodnoty pro adresu a params jsou `event.address` a `event.params.<name>`.
+
+Samotná obslužná rutina přistupuje k výsledku tohoto `eth_call` přesně tak, jak je uvedeno v předchozí části, a to navázáním na smlouvu a provedením volání. graph-node cachuje výsledky deklarovaných `eth_call` v paměti a volání obslužné rutiny získá výsledek z této paměťové cache místo skutečného volání RPC.
+
+Poznámka: Deklarované eth_calls lze provádět pouze v podgraf s verzí specVersion >= 1.2.0.
+
+## Závěr
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From e4531f087b1f1374aee8284e4c36cf85b2031c23 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:46 -0500
Subject: [PATCH 1423/3820] New translations avoid-eth-calls.mdx (German)

---
 .../de/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/de/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/de/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 258ff5f392a0386a359dcaf61f2444c7098abc1f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:47 -0500
Subject: [PATCH 1424/3820] New translations avoid-eth-calls.mdx (Italian)

---
 .../it/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/it/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/it/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 5ae2b8005a9f3bd3c3352fa761ead50973ab4162 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:48 -0500
Subject: [PATCH 1425/3820] New translations avoid-eth-calls.mdx (Japanese)

---
 .../ja/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/ja/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 8e42462bafd751f5eea48fb656001ce737e88c90 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:49 -0500
Subject: [PATCH 1426/3820] New translations avoid-eth-calls.mdx (Korean)

---
 .../ko/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/ko/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 386407dcc23fced4c81c79410e53dc04fffbc2bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:50 -0500
Subject: [PATCH 1427/3820] New translations avoid-eth-calls.mdx (Dutch)

---
 .../nl/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/nl/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From f50310d6b24be3058c92b6efe85e27db4b820da9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:51 -0500
Subject: [PATCH 1428/3820] New translations avoid-eth-calls.mdx (Polish)

---
 .../pl/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/pl/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 904ce79cfc5ce85dfe91fb78b61aa51bd66ceb02 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:52 -0500
Subject: [PATCH 1429/3820] New translations avoid-eth-calls.mdx (Portuguese)

---
 .../pt/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/pt/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..fd40eb79c13c
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Melhores Práticas de Subgraph Parte 4 - Como Melhorar a Velocidade da Indexação ao Evitar eth_calls
+---
+
+## TLDR
+
+`eth_calls` são chamadas feitas de um subgraph a um node no Ethereum. Estas chamadas levam um bom tempo para retornar dados, o que retarda a indexação. Se possível, construa contratos inteligentes para emitir todos os dados necessários, para que não seja necessário usar `eth_calls`.
+
+## Por que Evitar `eth_calls` É uma Boa Prática
+
+Subgraphs são otimizados para indexar dados de eventos emitidos de contratos inteligentes. Um subgraph também pode indexar os dados que vêm de uma `eth_call`, mas isto pode atrasar muito a indexação de um subgraph, já que `eth_calls` exigem a realização de chamadas externas para contratos inteligentes. A capacidade de respostas destas chamadas depende não apenas do subgraph, mas também da conectividade e das respostas do node do Ethereum a ser consultado. Ao minimizar ou eliminar `eth_calls` nos nossos subgraphs, podemos melhorar muito a nossa velocidade de indexação.
+
+### Como É Um `eth_call`?
+
+`eth_calls` tendem a ser necessárias quando os dados requeridos por um subgraph não estão disponíveis via eventos emitidos. Por exemplo, vamos supor que um subgraph precisa identificar se tokens ERC20 são parte de um pool específico, mas o contrato só emite um evento `Transfer` básico e não emite um evento que contém os dados que precisamos:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suponhamos que a filiação de pool dos tokens seja determinada por um variável de estado chamado `getPoolInfo`. Neste caso, precisaríamos usar uma `eth_call` para consultar estes dados:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Atrele a instância de contrato ERC20 ao endereço dado:
+  let instance = ERC20.bind(event.address)
+
+  // Retire a informação do pool via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+Isto é funcional, mas não ideal, já que ele atrasa a indexação do nosso subgraph.
+
+## Como Eliminar `eth_calls`
+
+Idealmente, o contrato inteligente deve ser atualizado para emitir todos os dados necessários dentro de eventos. Por exemplo, modificar o contrato inteligente para incluir informações de pools no evento pode eliminar a necessidade de `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+Com esta atualização, o subgraph pode indexar directamente os dados exigidos sem chamadas externas:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+Assim, o desempenho melhora muito por eliminar a necessidade de `eth_calls`.
+
+## Como Otimizar `eth_calls`
+
+Se não for possível modificar o contrato inteligente e se `eth_calls` forem necessários, leia “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” para aprender várias estratégias sobre como otimizar `eth_calls`.
+
+## Como Reduzir o Overhead de Runtime de `eth_calls`
+
+Para `eth_calls` que não podem ser eliminadas, o overhead de runtime que elas introduzem pode ser minimizado ao declará-las no manifest. Quando o`graph-node` processa um bloco, ele realiza todas as `eth_calls` em paralelo antes da execução dos handlers. Chamadas não declaradas são executadas em sequência quando os handlers são executados. A melhoria do runtime vem da execução das chamadas em paralelo, e não em sequência - isto ajuda a reduzir o tempo total gasto em chamadas, mas não o elimina por completo.
+
+Atualmente, `eth_calls` só podem ser declaradas para handlers de evento. No manifest, escreva
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+A porção destacada em amarelo é a declaração de chamada. A parte antes dos dois pontos é apenas um rótulo de texto usado só para mensagens de erro. A parte após os dois pontos tem a forma `Contract[address].function(params)`. Valores permissíveis para address e params são `event.address` e `event.params.<name>`.
+
+O próprio handler acessa o resultado desta `eth_call` exatamente como na secção anterior ao atrelar ao contrato e fazer a chamada. o graph-node coloca em cache os resultados de `eth_calls` na memória e a chamada do handler terirará o resultado disto no cache de memória em vez de fazer uma chamada de RPC real.
+
+Nota: `eth_calls` declaradas só podem ser feitas em subgraphs com specVersion maior que 1.2.0.
+
+## Conclusão
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 4825048f62beab2cff2ae215e6cf3c68bc22c7c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:53 -0500
Subject: [PATCH 1430/3820] New translations avoid-eth-calls.mdx (Russian)

---
 .../ru/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..80ecc6482f4b
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## Краткое содержание
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` часто необходимы, когда данные, требуемые для субграфа, недоступны через сгенерированные события. Например, рассмотрим ситуацию, когда субграфу нужно определить, являются ли токены ERC20 частью определенного пула, но контракт генерирует только базовое событие `Transfer` и не создает событие, содержащее нужные нам данные:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Предположим, что принадлежность токенов к пулу определяется переменной состояния с именем `getPoolInfo`. В этом случае нам потребуется использовать `eth_call`, чтобы запросить эти данные:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Привязка экземпляра контракта ERC20 к указанному адресу:
+  let instance = ERC20.bind(event.address)
+
+  // Получение информации о пуле с помощью eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+С этим обновлением субграф может напрямую индексировать необходимые данные без внешних вызовов:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## Как оптимизировать `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+Для тех `eth_calls`, которые нельзя устранить, накладные расходы на их выполнение можно минимизировать, объявив их в манифесте. Когда `graph-node` обрабатывает блок, все объявленные `eth_calls` выполняются параллельно до запуска обработчиков. Вызовы, не объявленные в манифесте, выполняются последовательно во время работы обработчиков. Улучшение производительности достигается за счет параллельного выполнения вызовов, а не последовательного, что помогает сократить общее время, затраченное на вызовы, но не устраняет его полностью.
+
+В настоящее время `eth_calls` можно объявлять только для обработчиков событий. В манифесте нужно написать
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+Часть, выделенная желтым, — это объявление вызова. Часть до двоеточия — это текстовая метка, которая используется только в сообщениях об ошибках. Часть после двоеточия имеет форму `Contract[address].function(params)`. Допустимыми значениями для адреса и параметров являются `event.address` и `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Примечание: Объявленные `eth_calls` могут быть выполнены только в субграфах с версией спецификации >= 1.2.0.
+
+## Заключение
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From cc6be15f9a29c626a3ac7fe6e0c708098291bba4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:54 -0500
Subject: [PATCH 1431/3820] New translations avoid-eth-calls.mdx (Swedish)

---
 .../sv/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/sv/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From fc5e6f6d11e0f3b2bdb6be6b01729ae8bf1e6af1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:55 -0500
Subject: [PATCH 1432/3820] New translations avoid-eth-calls.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 5b09516deaa812b0699914d8732d4a2669c9e008 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:56 -0500
Subject: [PATCH 1433/3820] New translations avoid-eth-calls.mdx (Ukrainian)

---
 .../uk/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/uk/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 323d32bfc2a85a700761eb19d12459a01c346245 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:57 -0500
Subject: [PATCH 1434/3820] New translations avoid-eth-calls.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 7806e2f17cc152a6769b1fa36cfe87ad89713d44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:58 -0500
Subject: [PATCH 1435/3820] New translations avoid-eth-calls.mdx (Urdu
 (Pakistan))

---
 .../ur/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/ur/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From d97d9788a41e3c2c3729c7364b123929fe691382 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:09:59 -0500
Subject: [PATCH 1436/3820] New translations avoid-eth-calls.mdx (Vietnamese)

---
 .../vi/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/vi/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 4d935b77e0948b24c11acb1894d3382b14a4435c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:01 -0500
Subject: [PATCH 1437/3820] New translations avoid-eth-calls.mdx (Marathi)

---
 .../mr/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/mr/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From c533294a5590bedab7afd014705612e35c6c44bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:05 -0500
Subject: [PATCH 1438/3820] New translations avoid-eth-calls.mdx (Hindi)

---
 .../hi/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/hi/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..5e86a234262a
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: सबग्राफ सर्वोत्तम प्रथा 4 - eth_calls से बचकर अनुक्रमण गति में सुधार करें
+---
+
+## TLDR
+
+eth_calls वे कॉल हैं जो एक Subgraph से Ethereum नोड पर किए जा सकते हैं। ये कॉल डेटा लौटाने में महत्वपूर्ण समय लेते हैं, जिससे indexing धीमी हो जाती है। यदि संभव हो, तो स्मार्ट कॉन्ट्रैक्ट्स को इस तरह से डिजाइन करें कि वे सभी आवश्यक डेटा उत्पन्न करें ताकि आपको eth_calls का उपयोग न करना पड़े।
+
+## Eth_calls से बचना एक सर्वोत्तम अभ्यास क्यों है
+
+Subgraphs को स्मार्ट कॉन्ट्रैक्ट्स से निकले हुए इवेंट डेटा को इंडेक्स करने के लिए ऑप्टिमाइज़ किया गया है। एक subgraph ‘eth_call’ से आने वाले डेटा को भी इंडेक्स कर सकता है, लेकिन इससे subgraph इंडेक्सिंग काफी धीमी हो सकती है क्योंकि ‘eth_calls’ के लिए स्मार्ट कॉन्ट्रैक्ट्स को एक्सटर्नल कॉल्स करने की आवश्यकता होती है। इन कॉल्स की प्रतिक्रिया subgraph पर निर्भर नहीं करती, बल्कि उस Ethereum नोड की कनेक्टिविटी और प्रतिक्रिया पर निर्भर करती है, जिसे क्वेरी किया जा रहा है। हमारे subgraphs में ‘eth_calls’ को कम करके या पूरी तरह से समाप्त करके, हम अपने इंडेक्सिंग स्पीड में उल्लेखनीय सुधार कर सकते हैं।
+
+### एक eth_call कैसा दिखता है?
+
+eth_calls अक्सर तब आवश्यक होते हैं जब subgraph के लिए आवश्यक डेटा इमिटेड इवेंट्स के माध्यम से उपलब्ध नहीं होता है। उदाहरण के लिए, एक ऐसा परिदृश्य मानें जहां एक subgraph को यह पहचानने की आवश्यकता है कि क्या ERC20 टोकन एक विशेष पूल का हिस्सा हैं, लेकिन कॉन्ट्रैक्ट केवल एक बुनियादी Transfer इवेंट इमिट करता है और वह इवेंट इमिट नहीं करता जिसमें हमें आवश्यक डेटा हो:
+
+```yaml
+इवेंट Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+मान लें कि टोकन्स की पूल सदस्यता एक state वेरिएबल getPoolInfo द्वारा निर्धारित होती है। इस मामले में, हमें इस डेटा को क्वेरी करने के लिए एक eth_call का उपयोग करना होगा:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // दिए गए पते पर ERC20 कॉन्ट्रैक्ट इंस्टेंस को बाइंड करें:
+  let instance = ERC20.bind(event.address)
+
+  // eth_call के जरिए पूल जानकारी प्राप्त करें
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+यह कार्यात्मक है, हालांकि यह आदर्श नहीं है क्योंकि यह हमारे subgraph की indexing को धीमा कर देता है।
+
+## Eth_calls को कैसे समाप्त करें
+
+आदर्श रूप से, स्मार्ट कॉन्ट्रैक्ट को सभी आवश्यक डेटा को इवेंट्स के भीतर प्रकट करने के लिए अपडेट किया जाना चाहिए। उदाहरण के लिए, स्मार्ट कॉन्ट्रैक्ट में इवेंट में पूल जानकारी शामिल करने के लिए संशोधन करने से eth_calls की आवश्यकता को समाप्त किया जा सकता है:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+इस अपडेट के साथ, subgraph आवश्यक डेटा को बिना बाहरी कॉल के सीधे अनुक्रमित कर सकता है:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+यह बहुत अधिक प्रदर्शनकारी है क्योंकि इसने eth_calls की आवश्यकता को समाप्त कर दिया है।
+
+## Eth_calls को ऑप्टिमाइज़ करने का तरीका
+
+यदि स्मार्ट कॉन्ट्रैक्ट में परिवर्तन करना संभव नहीं है और eth_calls की आवश्यकता है, तो विभिन्न रणनीतियों को सीखने के लिए Improve Subgraph Indexing Performance Easily: Reduce eth_calls पढ़ें जो eth_calls को ऑप्टिमाइज़ करने के तरीके बताती है।
+
+## Eth_calls के रनटाइम ओवरहेड को कम करना
+
+जिन eth_calls को समाप्त नहीं किया जा सकता है, उनके द्वारा उत्पन्न रनटाइम ओवरहेड को मैनिफेस्ट में घोषित करके कम किया जा सकता है। जब graph-node एक ब्लॉक को प्रोसेस करता है, तो यह हैंडलर्स के चलने से पहले सभी घोषित eth_calls को समानांतर में प्रदर्शन करता है। जो कॉल घोषित नहीं हैं, वे हैंडलर्स के चलने के समय अनुक्रमिक रूप से निष्पादित होते हैं। रनटाइम में सुधार समानांतर में कॉल्स को करने से आता है, न कि अनुक्रमिक रूप से - यह कुल समय को कम करने में मदद करता है, लेकिन इसे पूरी तरह से समाप्त नहीं करता है।
+
+वर्तमान में, eth_calls को केवल event handlers के लिए घोषित किया जा सकता है। मैनिफेस्ट में, लिखें
+
+```yaml
+इवेंट: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+हैंडलर: handleTransferWithPool
+कॉल्स:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+पीले रंग में हाइलाइट किया गया हिस्सा कॉल डिक्लेरेशन है। कॉल के पहले वाले हिस्से में जो टेक्स्ट लेबल है, वह केवल त्रुटि संदेशों के लिए उपयोग किया जाता है। कॉल के बाद वाला हिस्सा Contract[address].function(params) के रूप में होता है। address और params के लिए मान `event.address` और `event.params.<name>` अनुमेय हैं।
+
+Handler स्वयं इस eth_call के परिणाम तक ठीक उसी तरह पहुंचता है जैसे पिछले अनुभाग में, अनुबंध से बाइंडिंग करके और कॉल करके। graph-node घोषित eth_calls के परिणामों को मेमोरी में कैश करता है और हैंडलर से कॉल इस मेमोरी कैश से परिणाम प्राप्त करेगा, बजाय इसके कि एक वास्तविक RPC कॉल की जाए।
+
+नोट: घोषित eth_calls केवल उन subgraphs में किए जा सकते हैं जिनका specVersion >= 1.2.0 है।
+
+## निष्कर्ष
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From c3011aab7d58d9d78c63bf7f041862224f9248ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:06 -0500
Subject: [PATCH 1439/3820] New translations avoid-eth-calls.mdx (Swahili)

---
 .../sw/subgraphs/cookbook/avoid-eth-calls.mdx | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/avoid-eth-calls.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/sw/subgraphs/cookbook/avoid-eth-calls.mdx
new file mode 100644
index 000000000000..a0613bf2b69f
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -0,0 +1,116 @@
+---
+title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+---
+
+## TLDR
+
+`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+
+## Why Avoiding `eth_calls` Is a Best Practice
+
+Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+
+### What Does an eth_call Look Like?
+
+`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+
+```yaml
+event Transfer(address indexed from, address indexed to, uint256 value);
+```
+
+Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, Transfer } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransfer(event: Transfer): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  // Bind the ERC20 contract instance to the given address:
+  let instance = ERC20.bind(event.address)
+
+  // Retrieve pool information via eth_call
+  let poolInfo = instance.getPoolInfo(event.params.to)
+
+  transaction.pool = poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is functional, however is not ideal as it slows down our subgraph’s indexing.
+
+## How to Eliminate `eth_calls`
+
+Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+
+```
+event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
+```
+
+With this update, the subgraph can directly index the required data without external calls:
+
+```typescript
+import { Address } from '@graphprotocol/graph-ts'
+import { ERC20, TransferWithPool } from '../generated/ERC20/ERC20'
+import { TokenTransaction } from '../generated/schema'
+
+export function handleTransferWithPool(event: TransferWithPool): void {
+  let transaction = new TokenTransaction(event.transaction.hash.toHex())
+
+  transaction.pool = event.params.poolInfo.toHexString()
+  transaction.from = event.params.from.toHexString()
+  transaction.to = event.params.to.toHexString()
+  transaction.value = event.params.value
+
+  transaction.save()
+}
+```
+
+This is much more performant as it has eliminated the need for `eth_calls`.
+
+## How to Optimize `eth_calls`
+
+If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+
+## Reducing the Runtime Overhead of `eth_calls`
+
+For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+
+Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+
+```yaml
+event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
+handler: handleTransferWithPool
+calls:
+  ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
+```
+
+The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+
+The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+
+Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+
+## Conclusion
+
+You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 6376745dfce553362f6f5ce7b89a5aa102504f00 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:07 -0500
Subject: [PATCH 1440/3820] New translations cosmos.mdx (Romanian)

---
 .../pages/ro/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/cosmos.mdx b/website/pages/ro/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..5ccf1025ca47
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Building Subgraphs on Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## What are Cosmos subgraphs?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+There are four types of handlers supported in Cosmos subgraphs:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Even though all data can be accessed with a block handler, other handlers enable subgraph developers to process data in a much more granular way.
+
+## Building a Cosmos subgraph
+
+### Subgraph Dependencies
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Subgraph Main Components
+
+There are three key parts when it comes to defining a subgraph:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Each handler type comes with its own data structure that is passed as an argument to a mapping function.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Message decoding
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Creating and building a Cosmos subgraph
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Deploying a Cosmos subgraph
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Querying a Cosmos subgraph
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Supported Cosmos Blockchains
+
+### Cosmos Hub
+
+#### What is Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Networks
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### What is Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Networks
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From e9318737b449aac8358a60de73c509b7a5b1371a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:08 -0500
Subject: [PATCH 1441/3820] New translations cosmos.mdx (French)

---
 .../pages/fr/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/cosmos.mdx b/website/pages/fr/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..962fc4bd1758
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Création de subgraphes sur Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## Que sont les subgraphs de Cosmos ?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+Il existe quatre types de gestionnaires pris en charge dans les subgraphs de Cosmos :
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Même si toutes les données sont accessibles avec un gestionnaire de blocs, des gestionnaires tiers permettent aux développeurs de subgraphs de traiter les données de manière beaucoup plus précise.
+
+## Création d'un subgraph ciblant Cosmos
+
+### Dépendances des subgraphs
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Composants principaux du subgraph
+
+La définition d'un subgraph comporte trois éléments clés :
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Définition du manifeste du subgraph
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+version spec : 0.0.5
+description : Exemple de subgraph Cosmos
+schéma:
+   fichier : ./schema.graphql # lien vers le fichier de schéma
+les sources de données:
+   - genre : cosmos
+     nom : CosmosHub
+     réseau : cosmoshub-4 # Cela changera pour chaque blockchain basée sur le cosmos. Dans ce cas, l’exemple utilise le mainnet Cosmos Hub.
+     source:
+       startBlock : 0 # Requis pour Cosmos, définissez-le sur 0 pour démarrer l'indexation à partir de la genèse de la chaîne
+     cartographie :
+       Version api : 0.0.7
+       langage : wasm/assemblyscript
+       gestionnaires de blocs :
+         - handler: handleNewBlock # le nom de la fonction dans le fichier de mappage
+       Gestionnaires d'événements :
+         - event : récompenses # le type d'événement qui sera géré
+           handler: handleReward # le nom de la fonction dans le fichier de mappage
+       Gestionnaires de transactions :
+         - handler: handleTransaction # le nom de la fonction dans le fichier de mappage
+       Gestionnaires de messages :
+         - message : /cosmos.staking.v1beta1.MsgDelegate # le type d'un message
+           handler : handleMsgDelegate # le nom de la fonction dans le fichier de mappage
+       fichier : ./src/mapping.ts # lien vers le fichier avec les mappages Assemblyscript
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Définition de schéma
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### Cartographies AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Chaque structure de type de gestionnaire transmise en tant qu'argument à une fonction de mappage.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Décodage des messages
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Création et construction d'un subgraph Cosmos
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ codegen graph
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ construction de graph
+```
+
+## Déploiement d'un subgraph Cosmos
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visitez Subgraph Studio pour créer un nouveau subgraph.
+
+```bash
+graph deploy nom-du-subgraph
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create nom-du-subgraph --node http://localhost:8020
+```
+
+```bash
+graph deploy nom-du-subgraph --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Interroger un subgraph de Cosmos
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Blockchains Cosmos prises en charge
+
+### Cosmos Hub
+
+#### Qu'est-ce qu'un Cosmos Hub ?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Les Réseaux
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> La prise en charge d'Osmosis dans Graph Node et sur Subgraph Studio est en bêta : veuillez contacter l'équipe de The Graph pour toute question sur la création de subgraphs Osmosis !
+
+#### Qu’est-ce que l’osmose ?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Les Réseaux
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Exemples de subgraphs
+
+Voici quelques exemples de subgraphs pour référence :
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 977bcb174dca4514173636e4faec80db9190ebbc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:09 -0500
Subject: [PATCH 1442/3820] New translations cosmos.mdx (Spanish)

---
 .../pages/es/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/es/subgraphs/cookbook/cosmos.mdx b/website/pages/es/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..3e8c35df064f
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Construyendo subgrafos en Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## ¿Qué son los subgrafos de Cosmos?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+Hay cuatro tipos de handlers admitidos en los subgrafos de Cosmos:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Aunque se puede acceder a todos los datos con un handler de bloques, otros handlers permiten a los developers de subgrafos procesar datos de una manera mucho más granular.
+
+## Construyendo un subgrafo de Cosmos
+
+### Dependencias de subgrafos
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Componentes principales del subgrafo
+
+Hay tres partes clave cuando se trata de definir un subgrafo:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Definición de manifiesto del subgrafo
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Definición de esquema
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### Asignaciones de AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Cada tipo de handler viene con su propia estructura de datos que se pasa como argumento a una función de mapping.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Decodificación de mensajes
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Crear y construir un subgrafo de Cosmos
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Deployando un subgrafo de Cosmos
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Consultar un subgrafo de Cosmos
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Blockchains Cosmos compatibles
+
+### Cosmos Hub
+
+#### ¿Qué es Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Networks
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### ¿Qué es Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Networks
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Subgrafos de ejemplo
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 94d2c31e674767219945dabb786b72b17d9b6697 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:10 -0500
Subject: [PATCH 1443/3820] New translations cosmos.mdx (Arabic)

---
 .../pages/ar/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/cosmos.mdx b/website/pages/ar/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..29cd28d488a6
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Building Subgraphs on Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## What are Cosmos subgraphs?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+There are four types of handlers supported in Cosmos subgraphs:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Even though all data can be accessed with a block handler, other handlers enable subgraph developers to process data in a much more granular way.
+
+## Building a Cosmos subgraph
+
+### Subgraph Dependencies
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Subgraph Main Components
+
+There are three key parts when it comes to defining a subgraph:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### تعريف Subgraph Manifest
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### تعريف المخطط
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Each handler type comes with its own data structure that is passed as an argument to a mapping function.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Message decoding
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Creating and building a Cosmos subgraph
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Deploying a Cosmos subgraph
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Querying a Cosmos subgraph
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Supported Cosmos Blockchains
+
+### Cosmos Hub
+
+#### What is Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### الشبكات
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### What is Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### الشبكات
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## أمثلة على الـ Subgraphs
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From daf73182239e89fd0ab19169e6ae17c2baaf24a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:11 -0500
Subject: [PATCH 1444/3820] New translations cosmos.mdx (Czech)

---
 .../pages/cs/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/cosmos.mdx b/website/pages/cs/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..0274cc6b5370
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Vytváření podgrafů v Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## Co jsou podgrafy Cosmos?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+V podgrafech Cosmos jsou podporovány čtyři typy ovladačů:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Přestože ke všem datům lze přistupovat pomocí blokové obsluhy, jiné obsluhy umožňují vývojářům podgrafů zpracovávat data mnohem podrobnějším způsobem.
+
+## Sestavení podgrafu Cosmos
+
+### Závislosti podgrafů
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Hlavní součásti subgrafu
+
+Při definování podgrafu existují tři klíčové části:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Definice podgrafu Manifest
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Definice schématu
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mapování
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Každý typ obslužné rutiny má svou vlastní datovou strukturu, která se předává jako argument mapovací funkci.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Dekódování zpráv
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Vytvoření a sestavení podgrafu Cosmos
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Nasazení podgrafu Cosmos
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Navštivte Studio podgrafů a vytvořte nový podgraf.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Dotazování podgrafu Cosmos
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Podporované blockchainy Cosmos
+
+### Cosmos Hub
+
+#### Co je Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Sítě
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Podpora Osmosis v uzel grafua v Podgraph Studio je ve fázi beta: s případnými dotazy ohledně vytváření podgrafů Osmosis se obraťte na grafový tým!
+
+#### Co je osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Sítě
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Příklady podgrafů
+
+Zde je několik příkladů podgrafů:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From f5158506eb4d05f3b16b16721f68a75bf1f59eaa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:12 -0500
Subject: [PATCH 1445/3820] New translations cosmos.mdx (German)

---
 .../pages/de/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/de/subgraphs/cookbook/cosmos.mdx b/website/pages/de/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..d2c95ef10f58
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Erstellen von Subgrafen auf Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## Was sind Cosmos-Subgrafen?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+In Cosmos-Subgrafen werden vier Arten von Handlern unterstützt:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Obwohl man mit einem Block-Handler auf alle Daten zugegriffen werden kann, ermöglichen andere Handler den Subgrafen-Entwicklern, Daten viel detaillierter zu verarbeiten.
+
+## Erstellen eines Subgrafen auf Cosmos
+
+### Subgraf-Abhängigkeiten
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Hauptkomponenten des Subgrafen
+
+Bei der Definition eines Subgrafen gibt es drei Schlüsselelemente:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Subgraf-Manifest-Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # Link zur Schemadatei
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # Dies wird sich für jede kosmosbasierte Blockchain ändern. In diesem Fall verwendet das Beispiel das Cosmos Hub-Mainnet.
+    source:
+      startBlock: 0 # Erforderlich für Cosmos, setzen Sie dies auf 0, um die Indizierung ab dem Chain-Genesis zu starten
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # der Funktionsname in der Zuordnungsdatei
+      eventHandlers:
+        - event: rewards # die Art des Ereignisses, das behandelt wird
+          handler: handleReward # der Funktionsname in der Zuordnungsdatei
+      transactionHandlers:
+        - handler: handleTransaction # der Funktionsname in der Zuordnungsdatei
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # die Art einer Meldung
+          handler: handleMsgDelegate # der Funktionsname in der Zuordnungsdatei
+      file: ./src/mapping.ts # Link zur Datei mit den Assemblyscript-Zuordnungen
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Schema-Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript-Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Jeder Handler-Typ verfügt über eine eigene Datenstruktur, die als Argument an eine Zuordnungsfunktion übergeben wird.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Nachrichtendecodierung
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Creating and building a Cosmos subgraph
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Bereitstellen eines Subgrafen auf Cosmos
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Querying a Cosmos subgraph
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Unterstützte Cosmos-Blockchains
+
+### Cosmos Hub
+
+#### Was ist Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Netzwerke
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### What is Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Netzwerke
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Beispiele von Subgrafen
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 1c5d6e69397a4905146c81fbac0db4b998790caf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:13 -0500
Subject: [PATCH 1446/3820] New translations cosmos.mdx (Italian)

---
 .../pages/it/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/it/subgraphs/cookbook/cosmos.mdx b/website/pages/it/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..5ccf1025ca47
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Building Subgraphs on Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## What are Cosmos subgraphs?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+There are four types of handlers supported in Cosmos subgraphs:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Even though all data can be accessed with a block handler, other handlers enable subgraph developers to process data in a much more granular way.
+
+## Building a Cosmos subgraph
+
+### Subgraph Dependencies
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Subgraph Main Components
+
+There are three key parts when it comes to defining a subgraph:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Each handler type comes with its own data structure that is passed as an argument to a mapping function.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Message decoding
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Creating and building a Cosmos subgraph
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Deploying a Cosmos subgraph
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Querying a Cosmos subgraph
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Supported Cosmos Blockchains
+
+### Cosmos Hub
+
+#### What is Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Networks
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### What is Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Networks
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 2983b0a67ab07bd993bc0929a8a0bd43114806e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:14 -0500
Subject: [PATCH 1447/3820] New translations cosmos.mdx (Japanese)

---
 .../pages/ja/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/cosmos.mdx b/website/pages/ja/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..008060749aa6
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Cosmosでのサブグラフ構築
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## Cosmosのサブグラフとは何ですか？
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+Cosmosのサブグラフでサポートされているハンドラーは4種類あります。
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+ブロックハンドラーでは全てのデータにアクセスできますが、その他のハンドラーでは、サブグラフの開発者がよりきめ細かくデータを処理することができます。
+
+## Cosmosサブグラフの構築
+
+### サブグラフの依存関係
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### サブグラフの主な構成要素
+
+サブグラフの定義には、3つの重要な部分があります。
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### サブグラフマニフェストの定義
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### スキーマ定義
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript マッピング
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+各ハンドラタイプは独自のデータ構造を持ち、マッピング関数の引数として渡されます。
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### メッセージ・デコーディング
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Cosmosサブグラフの作成と構築
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Cosmosサブグラフの展開
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Cosmosサブグラフのクエリ
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Cosmosブロックチェーンに対応
+
+### コスモスハブ
+
+#### コスモスハブとは？
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### ネットワーク
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### Osmosisとは?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### ネットワーク
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## サブグラフの例
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 08c501654b7cacbca1600a5660359ec0e51e5106 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:15 -0500
Subject: [PATCH 1448/3820] New translations cosmos.mdx (Korean)

---
 .../pages/ko/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/cosmos.mdx b/website/pages/ko/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..5ccf1025ca47
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Building Subgraphs on Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## What are Cosmos subgraphs?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+There are four types of handlers supported in Cosmos subgraphs:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Even though all data can be accessed with a block handler, other handlers enable subgraph developers to process data in a much more granular way.
+
+## Building a Cosmos subgraph
+
+### Subgraph Dependencies
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Subgraph Main Components
+
+There are three key parts when it comes to defining a subgraph:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Each handler type comes with its own data structure that is passed as an argument to a mapping function.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Message decoding
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Creating and building a Cosmos subgraph
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Deploying a Cosmos subgraph
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Querying a Cosmos subgraph
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Supported Cosmos Blockchains
+
+### Cosmos Hub
+
+#### What is Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Networks
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### What is Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Networks
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From fa2208505f4fe7948e0a13bac7d276ed68f8fc46 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:16 -0500
Subject: [PATCH 1449/3820] New translations cosmos.mdx (Dutch)

---
 .../pages/nl/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/cosmos.mdx b/website/pages/nl/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..5ccf1025ca47
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Building Subgraphs on Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## What are Cosmos subgraphs?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+There are four types of handlers supported in Cosmos subgraphs:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Even though all data can be accessed with a block handler, other handlers enable subgraph developers to process data in a much more granular way.
+
+## Building a Cosmos subgraph
+
+### Subgraph Dependencies
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Subgraph Main Components
+
+There are three key parts when it comes to defining a subgraph:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Each handler type comes with its own data structure that is passed as an argument to a mapping function.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Message decoding
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Creating and building a Cosmos subgraph
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Deploying a Cosmos subgraph
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Querying a Cosmos subgraph
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Supported Cosmos Blockchains
+
+### Cosmos Hub
+
+#### What is Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Networks
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### What is Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Networks
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From ea6338843aaa3fcdba7559ff01f40edd4f42759c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:18 -0500
Subject: [PATCH 1450/3820] New translations cosmos.mdx (Polish)

---
 .../pages/pl/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/cosmos.mdx b/website/pages/pl/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..5ccf1025ca47
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Building Subgraphs on Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## What are Cosmos subgraphs?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+There are four types of handlers supported in Cosmos subgraphs:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Even though all data can be accessed with a block handler, other handlers enable subgraph developers to process data in a much more granular way.
+
+## Building a Cosmos subgraph
+
+### Subgraph Dependencies
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Subgraph Main Components
+
+There are three key parts when it comes to defining a subgraph:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Each handler type comes with its own data structure that is passed as an argument to a mapping function.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Message decoding
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Creating and building a Cosmos subgraph
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Deploying a Cosmos subgraph
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Querying a Cosmos subgraph
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Supported Cosmos Blockchains
+
+### Cosmos Hub
+
+#### What is Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Networks
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### What is Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Networks
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From cf32513d487099f1c85faf584971005dd60f5707 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:19 -0500
Subject: [PATCH 1451/3820] New translations cosmos.mdx (Portuguese)

---
 .../pages/pt/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/cosmos.mdx b/website/pages/pt/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..928061cc9c7a
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Construção de Subgraphs no Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## O que são subgraphs no Cosmos?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+Existem quatro categorias de handlers apoiados em subgraphs no Cosmos:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Apesar de todos os dados poderem ser acessados com um block handler, outros handlers permitem a programadores de subgraphs processar dados de uma maneira muito mais granular.
+
+## Como construir um subgraph no Cosmos
+
+### Dependências de Subgraph
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Componentes Principais de Subgraph
+
+Quando definir um subgraph, estes três componentes serão muito importantes:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Definição de Manifest de Subgraph
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Exemplo de Subgraph no Cosmos
+schema:
+  file: ./schema.graphql # link ao arquivo schema
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # Isto mudará para cada blockchain baseada no Cosmos. Neste caso, o exemplo usa a mainnet Cosmos Hub.
+    source:
+      startBlock: 0 # Exigido para o Cosmos, coloque o valor de 0 para começar a indexar desde o gênese da chain
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # o nome da função no arquivo de mapeamento
+      eventHandlers:
+        - event: rewards # o tipo de evento que será lidado
+          handler: handleReward # o nome da função no arquivo de mapeamento
+      transactionHandlers:
+        - handler: handleTransaction # o nome da função no arquivo de mapeamento
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # o tipo de uma mensagem
+          handler: handleMsgDelegate # o nome da função no arquivo de mapeamento
+      file: ./src/mapping.ts # link ao arquivo com os mapeamentos em AssemblyScript
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Definição de Schema
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### Mapeamentos em AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Cada tipo de handler vem com a sua própria estrutura de dados, a ser passada como argumento a uma função de mapeamento.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Descodificação de mensagens
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Criação e construção de um subgraph no Cosmos
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Lançamento de um subgraph no Cosmos
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Crie um novo subgraph no Subgraph Studio.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Consulta a um subgraph no Cosmos
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Apoio a Blockchains no Cosmos
+
+### Cosmos Hub
+
+#### O que é Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Redes
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> O apoio ao Osmosis no Graph Node e no Subgraph Studio está em beta. Caso tenha dúvidas sobre construir subgraphs no Osmosis, por favor contacte a equipa do Graph!
+
+#### O que é Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Redes
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Exemplos de Subgraphs
+
+Aqui estão alguns exemplos de subgraphs para referência:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From e5c144bca86b5963f2d1a29a62bda0c3fea09ca7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:20 -0500
Subject: [PATCH 1452/3820] New translations cosmos.mdx (Russian)

---
 .../pages/ru/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/cosmos.mdx b/website/pages/ru/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..01fa7ffd710f
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Создание субграфов на Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## Что такое субграфы на Cosmos?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+Существует четыре типа обработчиков, поддерживаемых в субграфах Cosmos:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Хотя доступ ко всем данным можно получить с помощью обработчика блоков, другие обработчики позволяют разработчикам субграфов обрабатывать данные гораздо более детально.
+
+## Создание субграфа на Cosmos
+
+### Зависимости субграфа
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Основные компоненты субграфа
+
+Когда дело доходит до определения субграфа, имеется три ключевых момента:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Определение манифеста субграфа
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # ссылка на файл схемы
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # это будет меняться для каждого блокчейна, основанного на Cosmos. В данном случае в примере используется основная сеть Cosmos Hub.
+    source:
+      startBlock: 0 # требуется для Cosmos, установите для этого параметра значение 0, чтобы начать индексирование с начального блока генезиса чейна.
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # имя функции в мэппинг-файле
+      eventHandlers:
+        - event: rewards # тип события, которое будет обрабатываться
+          handler: handleReward # имя функции в мэппинг-файле
+      transactionHandlers:
+        - handler: handleTransaction # имя функции в мэппинг-файле
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # тип сообщения
+          handler: handleMsgDelegate # имя функции в мэппинг-файле
+      file: ./src/mapping.ts # ссылка на мэппинг-файл скрипта сборки
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Определение схемы
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### Мэппинги AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Каждый тип обработчика имеет свою собственную структуру данных, которая передается в качестве аргумента функции мэппинга.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Расшифровка сообщений
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Создание и построение субграфа на Cosmos
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Развертывание субграфа на Cosmos
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Посетите Subgraph Studio, чтобы создать новый субграф.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Запрос субграфа на Cosmos
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Поддерживаемые блокчейны Cosmos
+
+### Cosmos Hub
+
+#### Что такое Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Сети
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Поддержка Osmosis в Graph Node и Subgraph Studio находится в стадии бета-тестирования: обращайтесь к команде the Graph по любым вопросам, касающимся создания субграфов Osmosis!
+
+#### Что такое Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Сети
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Примеры субграфов
+
+Вот несколько примеров субграфов для справки:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 394480596fe0d01d1ac10c458b66723052c90d11 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:21 -0500
Subject: [PATCH 1453/3820] New translations cosmos.mdx (Swedish)

---
 .../pages/sv/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/cosmos.mdx b/website/pages/sv/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..75e5475585f3
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Bygga subgrafer på Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## Vad är Cosmos subgrafer?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+Det finns fyra typer av hanterare som stöds i Cosmos subgrafer:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Även om all data kan nås med en blockhanterare, gör andra hanterare det möjligt för subgraf utvecklare att behandla data på ett mycket mer detaljerat sätt.
+
+## Bygga en Cosmos subgraf
+
+### Subgraf beroenden
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Subgraf Huvudkomponenter
+
+Det finns tre viktiga delar när det gäller att definiera en subgraf:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Definition av subgraf manifestet
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript mappningar
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Varje hanterartyp kommer med sin egen datastruktur som skickas som ett argument till en mappningsfunktion.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Meddelan avkodning
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Skapa och bygga en Cosmos subgraf
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Distribuera en Cosmos subgraf
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Fråga efter en Cosmos subgraf
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Stöds Cosmos Blockchains
+
+### Cosmos Hub
+
+#### Vad är Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Nätverk
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### Vad är Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Nätverk
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Exempel på subgrafer
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From f640b2cde0bb9e0ea2df6d9edf747531a6aa9a75 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:22 -0500
Subject: [PATCH 1454/3820] New translations cosmos.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/cosmos.mdx b/website/pages/tr/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..0416f80e3f8b
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Cosmos'ta Subgraph'ler Oluşturma
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## Cosmos subgraph'leri nelerdir?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+Cosmos subgraph'lerinde desteklenen dört tür işleyici vardır:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Tüm verilere bir blok işleyici ile erişilebilmesine rağmen, diğer işleyiciler, subgraph geliştiricilerin verileri çok daha ayrıntılı bir şekilde işlemesine olanak tanır.
+
+## Cosmos subgraph'i inşa etme
+
+### Subgraph Gereksinimleri
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Subgraph Ana Bileşenleri
+
+Bir subgraph'i tanımlama noktasında üç anahtar kısım vardır:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Subgraph Manifest Tanımı
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Şema Tanımı
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Eşlemeleri
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Her işleyici türü, bir eşleme işlevine bağımsız değişken olarak iletilen kendi veri yapısıyla birlikte gelir.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Mesaj çözme
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Bir Cosmos subgraph'i inşa etme ve oluşturma
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Bir Cosmos subgraph'ini deploy etme
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Bir Cosmos subgraph'ini sorgulama
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Desteklenen Cosmos Blok Zincirleri
+
+### Cosmos Hub
+
+#### Cosmos Hub Nedir?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Ağlar
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### Osmosis Nedir?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Ağlar
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Örnek Subgraph'ler
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 6095328127575ad82112396a61195fb265ace326 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:23 -0500
Subject: [PATCH 1455/3820] New translations cosmos.mdx (Ukrainian)

---
 .../pages/uk/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/cosmos.mdx b/website/pages/uk/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..3e335b9d60c2
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Розробка підграфів на Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## Що таке Cosmos підграфи?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+У підграфах на Cosmos підтримується чотири типи обробників:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Хоча до всіх даних можна отримати доступ за допомогою блок-обробника, інші обробники дозволяють розробникам підграфів обробляти дані у значно детальніший спосіб.
+
+## Розробка підграфів на Cosmos
+
+### Subgraph Dependencies
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Основні компоненти підграфа
+
+Визначення підграфа складається з трьох ключових компонентів:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Визначення маніфесту підграфів
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Визначення схеми
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Кожен тип обробника має власну структуру даних, яка передається як аргумент функції маппінгу.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Розшифровка повідомлень
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Створення та побудова підграфа на Cosmos
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Розгортання підграфа на Cosmos
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Запит до Cosmos підграфа
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Блокчейни, що підтримуються Cosmos
+
+### Cosmos Hub
+
+#### Що таке Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Мережі
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### Що таке Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Мережі
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Приклади підграфів
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From f7084c51845060bbcd9dc9891276ecbdef187e6b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:24 -0500
Subject: [PATCH 1456/3820] New translations cosmos.mdx (Chinese Simplified)

---
 .../pages/zh/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/cosmos.mdx b/website/pages/zh/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..125dac19a9ef
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: 在 Cosmos上构建子图
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## Cosmos 子图是什么？
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+Cosmos 子图目前支持四种类型的处理程序：
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+尽管所有数据都可以通过区块处理程序访问，但其他处理程序使子图开发人员能够以更细粒度的方式处理数据。
+
+## 构建 Cosmos 子图
+
+### 子图依赖关系
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### 子图的主要组成部分
+
+定义子图有三个关键部分:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### 子图清单定义
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql #指向模式文件的链接
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # 映射文件中的函数名称
+      eventHandlers:
+        - event: rewards #将要处理的事件类型
+          handler: handleReward # 映射文件中的函数名称
+      transactionHandlers:
+        - handler: handleTransaction # 映射文件中的函数名称
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # 消息的类型
+          handler: handleMsgDelegate #映射文件中的函数名称
+      file: ./src/mapping.ts #指向包含Assemblyscript映射的文件的链接
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### 模式定义
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript 映射
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+每个处理程序类型都有自己的数据结构，这些数据结构作为参数传递给映射函数。
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### 消息解码
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## 创建和构建 Cosmos 子图
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## 部署 Cosmos 子图
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## 查询 Cosmos 子图
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## 受支持的Cosmos区块链
+
+### Cosmos Hub
+
+#### 什么是Cosmos Hub？
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### 网络
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### Osmosis是什么？
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### 网络
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## 示例子图
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From c4c3136b808794cc0598e80b3637aca1ced9716a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:25 -0500
Subject: [PATCH 1457/3820] New translations cosmos.mdx (Urdu (Pakistan))

---
 .../pages/ur/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/cosmos.mdx b/website/pages/ur/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..e6cdbe1a2dac
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: کوزموس پر سب گراف بنانا
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## کوزموس کے سب گراف کیا ہیں ؟
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+کوزموس سب گراف میں چار قسم کے ہینڈلرز کی حمایت کی جاتی ہے:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+اگرچہ تمام ڈیٹا تک بلاک ہینڈلر کے ذریعے رسائی حاصل کی جا سکتی ہے، دوسرے ہینڈلرز سب گراف ڈویلپرز کو زیادہ دانے دار طریقے سے ڈیٹا پر کارروائی کرنے کے قابل بناتے ہیں.
+
+## کوزموس سب گراف کی تعمیر
+
+### سب گراف انحصار
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### سب گراف کے مین اجزاء
+
+جب سب گراف کی وضاحت کی بات آتی ہے تو تین اہم حصے ہوتے ہیں:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### سب گراف مینی فیسٹ کی تعریف
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### اسکیما کی تعریف
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### اسمبلی اسکرپٹ سب میپنک
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+ہر ہینڈلر کی قسم اس کے اپنے ڈیٹا ڈھانچے کے ساتھ آتی ہے جو میپنگ فنکشن کی دلیل کے طور پر پاس کی جاتی ہے.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### پیغام کی ضابطہ کشائی
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## کوزموس سب گراف بنانا اور تعمیر کرنا
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## کوزموس سب گراف کو تعینات کرنا
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## ایک کوزموس سب گراف کو کیوری کرنا
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## تعاون یافتہ کوزموس بلاکچین
+
+### کوزموس ہب
+
+#### کوزموس ہب کیا ہے؟
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### نیٹ ورکس
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### اوسموسس
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### اوسموسس کیا ہے؟
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### نیٹ ورکس
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## سب گراف کی مثال
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From e21a2e5d23778b95ecb6e70faa2637f6e071b41e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:26 -0500
Subject: [PATCH 1458/3820] New translations cosmos.mdx (Vietnamese)

---
 .../pages/vi/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/cosmos.mdx b/website/pages/vi/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..1d68d3cdf7f0
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Building Subgraphs on Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## What are Cosmos subgraphs?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+There are four types of handlers supported in Cosmos subgraphs:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Even though all data can be accessed with a block handler, other handlers enable subgraph developers to process data in a much more granular way.
+
+## Building a Cosmos subgraph
+
+### Subgraph Dependencies
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Subgraph Main Components
+
+There are three key parts when it comes to defining a subgraph:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Each handler type comes with its own data structure that is passed as an argument to a mapping function.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Message decoding
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Creating and building a Cosmos subgraph
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Deploying a Cosmos subgraph
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Querying a Cosmos subgraph
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Supported Cosmos Blockchains
+
+### Cosmos Hub
+
+#### What is Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Các Mạng
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### What is Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Các Mạng
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From fe7681a459d540b46f3e5f4769d82b31ba147a8b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:27 -0500
Subject: [PATCH 1459/3820] New translations cosmos.mdx (Marathi)

---
 .../pages/mr/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/cosmos.mdx b/website/pages/mr/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..16b5b216fd3a
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: कॉसमॉस वर सबग्राफ तयार करणे
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## कॉसमॉस सबग्राफ काय आहेत?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+कॉसमॉस सबग्राफमध्ये चार प्रकारचे हँडलर समर्थित आहेत:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+जरी सर्व डेटा ब्लॉक हँडलरने ऍक्सेस केला जाऊ शकतो, इतर हँडलर्स सबग्राफ डेव्हलपरला डेटावर अधिक बारीक पद्धतीने प्रक्रिया करण्यास सक्षम करतात.
+
+## कॉसमॉस सबग्राफ तयार करणे
+
+### सबग्राफ अवलंबित्व
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### सबग्राफ मुख्य घटक
+
+सबग्राफ परिभाषित करताना तीन प्रमुख भाग आहेत:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### सबग्राफ मॅनिफेस्ट व्याख्या
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### स्कीमा व्याख्या
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### असेंबलीस्क्रिप्ट मॅपिंग
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+प्रत्येक हँडलर प्रकार त्याच्या स्वतःच्या डेटा स्ट्रक्चरसह येतो जो मॅपिंग फंक्शनला युक्तिवाद म्हणून पास केला जातो.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### संदेश डीकोडिंग
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## कॉसमॉस सबग्राफ तयार करणे आणि तयार करणे
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ आलेख कोडजेन
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ आलेख बिल्ड
+```
+
+## कॉसमॉस सबग्राफ तैनात करणे
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## कॉसमॉस सबग्राफची चौकशी करत आहे
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## समर्थित कॉसमॉस ब्लॉकचेन
+
+### कॉसमॉस हब
+
+#### कॉसमॉस हब म्हणजे काय?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### नेटवर्क्स
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### ऑस्मोसिस
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### ऑस्मोसिस म्हणजे काय?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### नेटवर्क्स
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## उदाहरणे सबग्राफ
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 16d8fe30de806760168b929c67f87ee603c32696 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:28 -0500
Subject: [PATCH 1460/3820] New translations cosmos.mdx (Hindi)

---
 .../pages/hi/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/cosmos.mdx b/website/pages/hi/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..ed1e762363fc
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: कॉसमॉस पर सब-ग्राफ्स बनाना
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## कॉसमॉस सब-ग्राफ्स क्या होते हैं?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+कॉसमॉस सब-ग्राफ्स में कुल चार प्रकार के हैंडलर्स सहयोगी हैं:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+जबकि सारा डाटा एक ब्लॉक हैंडलर की मदद से प्राप्त किया जा सकता है, बाकी हैंडलर्स सब-ग्राफ डेवलपरों को डाटा अधिक बारीक तरह से प्रोसेस करने में सहायता करते हैं|
+
+## एक कॉसमॉस सब-ग्राफ बनाना
+
+### सब-ग्राफ्स की निर्भरता
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### सब-ग्राफ के मुख्या कॉम्पोनेन्ट
+
+सब-ग्राफ्स को परिभासित करने के तीन मुख्या अंग हैं:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### सब ग्राफ मैनिफेस्ट की परिभाषा
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### स्कीमा की परिभाषा
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### असेंबली स्क्रिप्ट मैप्पिंग्स
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+हर हैंडलर प्रकार अपने खुद के डाटा स्ट्रक्चर के साथ आता है जिसे आर्गुमेंट की तरह मैपिंग फंक्शन में पास किया जा सकता है|
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### मैसेज डिकोडिंग
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## कॉसमॉस सब-ग्राफ्स बनाना और निर्माण करना
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## एक कॉसमॉस सब-ग्राफ डेप्लॉय करना
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## कॉसमॉस सब-ग्राफ को क्वेरी करना
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## समर्थित कॉसमॉस ब्लॉकचेन्स
+
+### कॉसमॉस हब
+
+#### कॉसमॉस हब क्या है?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### नेटवर्क्स
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### ऑस्मोसिस
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### ऑस्मोसिस क्या है?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### नेटवर्क्स
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## सब-ग्राफ के उदाहरण
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From fb040d038977db62b38cca77c8e7786941f613f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:29 -0500
Subject: [PATCH 1461/3820] New translations cosmos.mdx (Swahili)

---
 .../pages/sw/subgraphs/cookbook/cosmos.mdx    | 257 ++++++++++++++++++
 1 file changed, 257 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/cosmos.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/cosmos.mdx b/website/pages/sw/subgraphs/cookbook/cosmos.mdx
new file mode 100644
index 000000000000..5ccf1025ca47
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/cosmos.mdx
@@ -0,0 +1,257 @@
+---
+title: Building Subgraphs on Cosmos
+---
+
+This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+
+## What are Cosmos subgraphs?
+
+The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+
+There are four types of handlers supported in Cosmos subgraphs:
+
+- **Block handlers** run whenever a new block is appended to the chain.
+- **Event handlers** run when a specific event is emitted.
+- **Transaction handlers** run when a transaction occurs.
+- **Message handlers** run when a specific message occurs.
+
+Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+
+> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+>
+> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+>
+> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+
+Even though all data can be accessed with a block handler, other handlers enable subgraph developers to process data in a much more granular way.
+
+## Building a Cosmos subgraph
+
+### Subgraph Dependencies
+
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+
+### Subgraph Main Components
+
+There are three key parts when it comes to defining a subgraph:
+
+**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+
+**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+
+**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+
+```yaml
+specVersion: 0.0.5
+description: Cosmos Subgraph Example
+schema:
+  file: ./schema.graphql # link to the schema file
+dataSources:
+  - kind: cosmos
+    name: CosmosHub
+    network: cosmoshub-4 # This will change for each cosmos-based blockchain. In this case, the example uses the Cosmos Hub mainnet.
+    source:
+      startBlock: 0 # Required for Cosmos, set this to 0 to start indexing from chain genesis
+    mapping:
+      apiVersion: 0.0.7
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      eventHandlers:
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
+      transactionHandlers:
+        - handler: handleTransaction # the function name in the mapping file
+      messageHandlers:
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
+- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```tsx
+class Block {
+  header: Header
+  evidence: EvidenceList
+  resultBeginBlock: ResponseBeginBlock
+  resultEndBlock: ResponseEndBlock
+  transactions: Array<TxResult>
+  validatorUpdates: Array<Validator>
+}
+
+class EventData {
+  event: Event
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionData {
+  tx: TxResult
+  block: HeaderOnlyBlock
+}
+
+class MessageData {
+  message: Any
+  block: HeaderOnlyBlock
+  tx: TransactionContext
+}
+
+class TransactionContext {
+  hash: Bytes
+  index: u32
+  code: u32
+  gasWanted: i64
+  gasUsed: i64
+}
+
+class HeaderOnlyBlock {
+  header: Header
+}
+
+class Header {
+  version: Consensus
+  chainId: string
+  height: u64
+  time: Timestamp
+  lastBlockId: BlockID
+  lastCommitHash: Bytes
+  dataHash: Bytes
+  validatorsHash: Bytes
+  nextValidatorsHash: Bytes
+  consensusHash: Bytes
+  appHash: Bytes
+  lastResultsHash: Bytes
+  evidenceHash: Bytes
+  proposerAddress: Bytes
+  hash: Bytes
+}
+
+class TxResult {
+  height: u64
+  index: u32
+  tx: Tx
+  result: ResponseDeliverTx
+  hash: Bytes
+}
+
+class Event {
+  eventType: string
+  attributes: Array<EventAttribute>
+}
+
+class Any {
+  typeUrl: string
+  value: Bytes
+}
+```
+
+Each handler type comes with its own data structure that is passed as an argument to a mapping function.
+
+- Block handlers receive the `Block` type.
+- Event handlers receive the `EventData` type.
+- Transaction handlers receive the `TransactionData` type.
+- Message handlers receive the `MessageData` type.
+
+As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+
+You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+
+### Message decoding
+
+It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+
+An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+
+## Creating and building a Cosmos subgraph
+
+The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+
+```bash
+$ graph codegen
+```
+
+Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+
+```bash
+$ graph build
+```
+
+## Deploying a Cosmos subgraph
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+**Subgraph Studio**
+
+Visit the Subgraph Studio to create a new subgraph.
+
+```bash
+graph deploy subgraph-name
+```
+
+**Local Graph Node (based on default configuration):**
+
+```bash
+graph create subgraph-name --node http://localhost:8020
+```
+
+```bash
+graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
+```
+
+## Querying a Cosmos subgraph
+
+The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Supported Cosmos Blockchains
+
+### Cosmos Hub
+
+#### What is Cosmos Hub?
+
+The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+
+#### Networks
+
+Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+
+### Osmosis
+
+> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+
+#### What is Osmosis?
+
+[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+
+#### Networks
+
+Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+
+[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+
+[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+
+[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 110d692f7cedfecfd9eb082fb5d7863273b62121 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:30 -0500
Subject: [PATCH 1462/3820] New translations derivedfrom.mdx (Romanian)

---
 .../ro/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/derivedfrom.mdx b/website/pages/ro/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 1af3f8231235f64c8c8a2bdc5828d0899d1c110e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:31 -0500
Subject: [PATCH 1463/3820] New translations derivedfrom.mdx (French)

---
 .../fr/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx b/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From b89a453b52b487ec2da67886135d4d36a6ca7019 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:32 -0500
Subject: [PATCH 1464/3820] New translations derivedfrom.mdx (Spanish)

---
 .../es/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/es/subgraphs/cookbook/derivedfrom.mdx b/website/pages/es/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From e51540618d8770e5180e9e9e9ef54735a2c60206 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:33 -0500
Subject: [PATCH 1465/3820] New translations derivedfrom.mdx (Arabic)

---
 .../ar/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/derivedfrom.mdx b/website/pages/ar/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 46833355ec7ed6df77bf94007acc8e25af290d60 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:34 -0500
Subject: [PATCH 1466/3820] New translations derivedfrom.mdx (Czech)

---
 .../cs/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/derivedfrom.mdx b/website/pages/cs/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..64d50cae3431
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Podgraf Doporučený postup 2 - Zlepšení indexování a rychlosti dotazů pomocí @derivedFrom
+---
+
+## TLDR
+
+Pole ve vašem schématu mohou skutečně zpomalit výkon podgrafu, pokud jejich počet přesáhne tisíce položek. Pokud je to možné, měla by se při použití polí používat direktiva `@derivedFrom`, která zabraňuje vzniku velkých polí, zjednodušuje obslužné programy a snižuje velikost jednotlivých entit, čímž výrazně zvyšuje rychlost indexování a výkon dotazů.
+
+## Jak používat směrnici `@derivedFrom`
+
+Stačí ve schématu za pole přidat směrnici `@derivedFrom`. Takto:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` vytváří efektivní vztahy typu one-to-many, které umožňují dynamické přiřazení entity k více souvisejícím entitám na základě pole v související entitě. Tento přístup odstraňuje nutnost ukládat duplicitní data na obou stranách vztahu, čímž se podgraf stává efektivnějším.
+
+### Příklad případu použití pro `@derivedFrom`
+
+Příkladem dynamicky rostoucího pole je blogovací platforma, kde "příspěvek“ může mít mnoho "komentářů“.
+
+Začněme s našimi dvěma entitami, `příspěvek` a `Komentář`
+
+Bez optimalizace byste to mohli implementovat takto pomocí pole:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Taková pole budou efektivně ukládat další data komentářů na straně Post vztahu.
+
+Zde vidíte, jak vypadá optimalizovaná verze s použitím `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Pouhým přidáním direktivy `@derivedFrom` bude toto schéma ukládat "Komentáře“ pouze na straně "Komentáře“ vztahu a nikoli na straně "Příspěvek“ vztahu. Pole se ukládají napříč jednotlivými řádky, což umožňuje jejich výrazné rozšíření. To může vést k obzvláště velkým velikostem, pokud je jejich růst neomezený.
+
+Tím se nejen zefektivní náš podgraf, ale také se odemknou tři funkce:
+
+1. Můžeme se zeptat na `Post` a zobrazit všechny jeho komentáře.
+
+2. Můžeme provést zpětné vyhledávání a dotazovat se na jakýkoli `Komentář` a zjistit, ze kterého příspěvku pochází.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Závěr
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 09e63943e5a260cabcc1f3ae85da7efef734ae68 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:35 -0500
Subject: [PATCH 1467/3820] New translations derivedfrom.mdx (German)

---
 .../de/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/de/subgraphs/cookbook/derivedfrom.mdx b/website/pages/de/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 9a5da8559ece70580eab2bcc42d26a39f1513f69 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:36 -0500
Subject: [PATCH 1468/3820] New translations derivedfrom.mdx (Italian)

---
 .../it/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/it/subgraphs/cookbook/derivedfrom.mdx b/website/pages/it/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From a75911451c5c80f720e3ec98b9aab11f17b4b5f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:37 -0500
Subject: [PATCH 1469/3820] New translations derivedfrom.mdx (Japanese)

---
 .../ja/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/derivedfrom.mdx b/website/pages/ja/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 2ea9e89a44af6f9692948c9a63acfdfe8f1004c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:38 -0500
Subject: [PATCH 1470/3820] New translations derivedfrom.mdx (Korean)

---
 .../ko/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/derivedfrom.mdx b/website/pages/ko/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 6c1a6591ac5a2f0ca9d1d9c7f73dd2970a4b7865 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:39 -0500
Subject: [PATCH 1471/3820] New translations derivedfrom.mdx (Dutch)

---
 .../nl/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/derivedfrom.mdx b/website/pages/nl/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From fa608b73dce29f5ab1ead4084752215b90f5e941 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:41 -0500
Subject: [PATCH 1472/3820] New translations derivedfrom.mdx (Polish)

---
 .../pl/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/derivedfrom.mdx b/website/pages/pl/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From fce567c4b642ade79437dcc1064504cbd39f0c96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:42 -0500
Subject: [PATCH 1473/3820] New translations derivedfrom.mdx (Portuguese)

---
 .../pt/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/derivedfrom.mdx b/website/pages/pt/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..4e667ee2ecf0
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Boas Práticas de Subgraph 2 - Melhorar a Indexação e a Capacidade de Resposta de Queries com @derivedFrom
+---
+
+## TLDR
+
+O desempenho de um subgraph pode ser muito atrasado por arranjos no seu schema, já que esses podem crescer além dos milhares de entradas. Se possível, a diretiva `@derivedFrom` deve ser usada ao usar arranjos, já que ela impede a formação de grandes arranjos, simplifica handlers e reduz o tamanho de entidades individuais, o que melhora muito a velocidade da indexação e o desempenho dos queries.
+
+## Como Usar a Diretiva `@derivedFrom`
+
+Você só precisa adicionar uma diretiva `@derivedFrom` após o seu arranjo no seu schema. Assim:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+o `@derivedFrom` cria relações eficientes de um-para-muitos, o que permite que uma entidade se associe dinamicamente com muitas entidades relacionadas com base em um campo na entidade relacionada. Esta abordagem faz com que ambos os lados do relacionamento não precisem armazenar dados duplicados e aumenta a eficácia do subgraph.
+
+### Exemplo de Caso de Uso para `@derivedFrom`
+
+Um exemplo de um arranjo que cresce dinamicamente é uma plataforma de blogs onde um "Post" pode ter vários "Comments" (comentários).
+
+Vamos começar com as nossas duas entidades, `Post` e `Comment`
+
+Sem otimização, seria possível implementá-la assim com um arranjo:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arranjos como este, efetivamente, armazenarão dados extras de Comments no lado do Post no relacionamento.
+
+Aqui está uma versão otimizada que usa o `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Ao adicionar a diretiva `@derivedFrom`, este schema só armazenará os "Comentários" no lado "Comments" do relacionamento, e não no lado "Post". Os arranjos são armazenados em fileiras individuais, o que os faz crescer significativamente. Se o seu crescimento não for contido, isto pode permitir que o tamanho fique excessivamente grande.
+
+Isto não só aumenta a eficiência do nosso subgraph, mas também desbloqueia três características:
+
+1. Podemos fazer um query sobre o `Post` e ver todos os seus comentários.
+
+2. Podemos fazer uma pesquisa reversa e um query sobre qualquer `Comment`, para ver de qual post ele vem.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusão
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 1d42a5f89e45006cc4e56904282d052dacd1a64a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:43 -0500
Subject: [PATCH 1474/3820] New translations derivedfrom.mdx (Russian)

---
 .../ru/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx b/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..52a99ea31495
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## Краткое содержание
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Пример использования @derivedFrom
+
+Пример динамически растущего массива — это платформа для блогов, где у "Поста" может быть много "Комментариев".
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Вот как будет выглядеть оптимизированная версия с использованием @derivedFrom:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+Это не только сделает наш субграф более эффективным, но и откроет три возможности:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Заключение
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 10ba380baafc15d62c82af3b41e36aaf7525ad8f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:44 -0500
Subject: [PATCH 1475/3820] New translations derivedfrom.mdx (Swedish)

---
 .../sv/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/derivedfrom.mdx b/website/pages/sv/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 6eb985468cf155824ae711526248d19d24f6ece7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:45 -0500
Subject: [PATCH 1476/3820] New translations derivedfrom.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 4f8c1c35b5fe982a769e8e06b8fdaf0d03c757ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:46 -0500
Subject: [PATCH 1477/3820] New translations derivedfrom.mdx (Ukrainian)

---
 .../uk/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/derivedfrom.mdx b/website/pages/uk/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 11272535d9a0555d9cb835d34247870798ed275e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:47 -0500
Subject: [PATCH 1478/3820] New translations derivedfrom.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/derivedfrom.mdx b/website/pages/zh/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 256299c24a87c6a32bdd994492b8b870a0461ef3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:48 -0500
Subject: [PATCH 1479/3820] New translations derivedfrom.mdx (Urdu (Pakistan))

---
 .../ur/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/derivedfrom.mdx b/website/pages/ur/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 2346e079052d2e7142b7cb4f21a6745700660b46 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:49 -0500
Subject: [PATCH 1480/3820] New translations derivedfrom.mdx (Vietnamese)

---
 .../vi/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/derivedfrom.mdx b/website/pages/vi/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From dbfaed76af2d7b4ac1f123b49a21542dce21593a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:50 -0500
Subject: [PATCH 1481/3820] New translations derivedfrom.mdx (Marathi)

---
 .../mr/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/derivedfrom.mdx b/website/pages/mr/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 3125905f8ae1b73c1b10d5701cfadf16b8db8787 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:51 -0500
Subject: [PATCH 1482/3820] New translations derivedfrom.mdx (Hindi)

---
 .../hi/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/derivedfrom.mdx b/website/pages/hi/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..21d5d32fb68f
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph सर्वोत्तम प्रथा 2 - @derivedFrom का उपयोग करके अनुक्रमण और क्वेरी की प्रतिक्रियाशीलता में सुधार करें।
+---
+
+## TLDR
+
+आपके स्कीमा में ऐरे हजारों प्रविष्टियों से बढ़ने पर एक सबग्राफ के प्रदर्शन को वास्तव में धीमा कर सकते हैं। यदि संभव हो, तो @derivedFrom निर्देशिका का उपयोग करना चाहिए जब आप ऐरे का उपयोग कर रहे हों, क्योंकि यह बड़े ऐरे के निर्माण को रोकता है, हैंडलरों को सरल बनाता है और व्यक्तिगत संस्थाओं के आकार को कम करता है, जिससे अनुक्रमण गति और प्रश्न प्रदर्शन में महत्वपूर्ण सुधार होता है।
+
+## @derivedFrom निर्देशिका का उपयोग कैसे करें
+
+आपको बस अपने स्कीमा में अपने एरे के बाद एक @derivedFrom निर्देशिका जोड़ने की आवश्यकता है। ऐसा:
+
+```graphql
+टिप्पणियाँ : [Comment!]! @derivedFrom(field: “post”)
+```
+
+@derivedFrom कुशल एक से कई संबंध बनाता है, जिससे एक इकाई को संबंधित इकाई में एक फ़ील्ड के आधार पर कई संबंधित इकाइयों के साथ गतिशील रूप से संबंध बनाने की अनुमति मिलती है। यह दृष्टिकोण रिश्ते के दोनों पक्षों को डुप्लिकेट डेटा संग्रहीत करने की आवश्यकता को समाप्त करता है, जिससे subgraph अधिक कुशल बन जाता है।
+
+### @derivedFrom के लिए उदाहरण उपयोग मामला
+
+एक गतिशील रूप से बढ़ने वाले ऐरे का एक उदाहरण एक ब्लॉगिंग प्लेटफ़ॉर्म है जहाँ एक “Post” के कई “Comments” हो सकते हैं।
+
+आइए हम अपनी दो संस्थाओं, Post और Comment के साथ शुरू करते हैं।
+
+बिना ऑप्टिमाइजेशन के, आप इसे एक ऐरे के साथ इस प्रकार लागू कर सकते हैं:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+इस तरह के ऐरे प्रभावी रूप से संबंध के पोस्ट पक्ष पर अतिरिक्त Comments डेटा को संग्रहीत करेंगे।
+
+यहाँ एक अनुकूलित संस्करण है जो @derivedFrom का उपयोग करता है:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+बस @derivedFrom निर्देश जोड़ने से, यह स्कीमा केवल संबंध के “Comments” पक्ष पर “Comments” को संग्रहीत करेगा और संबंध के “Post” पक्ष पर नहीं। ऐरे व्यक्तिगत पंक्तियों में संग्रहीत होते हैं, जिससे उन्हें काफी विस्तार करने की अनुमति मिलती है। यदि उनका विकास अनियंत्रित है, तो इससे विशेष रूप से बड़े आकार हो सकते हैं।
+
+यह न केवल हमारे subgraph को अधिक प्रभावी बनाएगा, बल्कि यह तीन विशेषताओं को भी अनलॉक करेगा:
+
+1. हम Post को क्वेरी कर सकते हैं और इसके सभी कमेंट्स देख सकते हैं।
+
+2. हम एक रिवर्स लुकअप कर सकते हैं और किसी भी Comment को क्वेरी कर सकते हैं और देख सकते हैं कि यह किस पोस्ट से आया है।
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## निष्कर्ष
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From e57accea014e252c15c7534b202db867205d1fb5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:52 -0500
Subject: [PATCH 1483/3820] New translations derivedfrom.mdx (Swahili)

---
 .../sw/subgraphs/cookbook/derivedfrom.mdx     | 88 +++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/derivedfrom.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/derivedfrom.mdx b/website/pages/sw/subgraphs/cookbook/derivedfrom.mdx
new file mode 100644
index 000000000000..22845a8d7dd2
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/derivedfrom.mdx
@@ -0,0 +1,88 @@
+---
+title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+---
+
+## TLDR
+
+Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+
+## How to Use the `@derivedFrom` Directive
+
+You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+
+```graphql
+comments: [Comment!]! @derivedFrom(field: "post")
+```
+
+`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+
+### Example Use Case for `@derivedFrom`
+
+An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+
+Let’s start with our two entities, `Post` and `Comment`
+
+Without optimization, you could implement it like this with an array:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]!
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+}
+```
+
+Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+
+Here’s what an optimized version looks like using `@derivedFrom`:
+
+```graphql
+type Post @entity {
+  id: Bytes!
+  title: String!
+  content: String!
+  comments: [Comment!]! @derivedFrom(field: "post")
+}
+
+type Comment @entity {
+  id: Bytes!
+  content: String!
+  post: Post!
+}
+```
+
+Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+
+This will not only make our subgraph more efficient, but it will also unlock three features:
+
+1. We can query the `Post` and see all of its comments.
+
+2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+
+3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+
+## Conclusion
+
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From adcbd860ba80cf042ac3b1999e7189c73bdbf5b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:53 -0500
Subject: [PATCH 1484/3820] New translations enums.mdx (Romanian)

---
 website/pages/ro/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/enums.mdx b/website/pages/ro/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..a10970c1539f
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Additional Resources
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 5f17d377c254f2845292ee114b595691eb001c89 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:54 -0500
Subject: [PATCH 1485/3820] New translations enums.mdx (French)

---
 website/pages/fr/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/enums.mdx b/website/pages/fr/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..581ebd57e7cd
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Pourquoi est-ce un problème ?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Ressources complémentaires
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 329f28d050b02d326425f499b60ef122d40d1bf5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:55 -0500
Subject: [PATCH 1486/3820] New translations enums.mdx (Spanish)

---
 website/pages/es/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/es/subgraphs/cookbook/enums.mdx b/website/pages/es/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..29b5b2d0bf38
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Recursos Adicionales
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 5039352a717d6542183f49dce36d82a865f49925 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:56 -0500
Subject: [PATCH 1487/3820] New translations enums.mdx (Arabic)

---
 website/pages/ar/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/enums.mdx b/website/pages/ar/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..9508aa864b6c
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## مصادر إضافية
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 48d580a08001f585a170cff1604b2fd4a5317ab8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:57 -0500
Subject: [PATCH 1488/3820] New translations enums.mdx (Czech)

---
 website/pages/cs/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/enums.mdx b/website/pages/cs/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..71f3f784a0eb
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Další zdroje
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 55688c959f9153f0256b83570cb1f4675fb42c27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:58 -0500
Subject: [PATCH 1489/3820] New translations enums.mdx (German)

---
 website/pages/de/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/de/subgraphs/cookbook/enums.mdx b/website/pages/de/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..8db81193d949
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Warum ist das ein Problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Additional Resources
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From c80c8fbd4bf4dbcaabe0e4546f52408016f4c11d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:10:59 -0500
Subject: [PATCH 1490/3820] New translations enums.mdx (Italian)

---
 website/pages/it/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/it/subgraphs/cookbook/enums.mdx b/website/pages/it/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..a10970c1539f
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Additional Resources
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 6cec545f152658a367c47662d3dd60cd01c3d3df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:01 -0500
Subject: [PATCH 1491/3820] New translations enums.mdx (Japanese)

---
 website/pages/ja/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/enums.mdx b/website/pages/ja/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..8df21d2960f9
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## その他のリソース
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 987b1b68b53b6f8f120278720f02c76cfbc5d424 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:02 -0500
Subject: [PATCH 1492/3820] New translations enums.mdx (Korean)

---
 website/pages/ko/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/enums.mdx b/website/pages/ko/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..a10970c1539f
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Additional Resources
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From f035c5528ca09dcfa080cdde2691f3fc7a8547be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:03 -0500
Subject: [PATCH 1493/3820] New translations enums.mdx (Dutch)

---
 website/pages/nl/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/enums.mdx b/website/pages/nl/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..a10970c1539f
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Additional Resources
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 279a26f09cc331e61f41c43b3b4e1640cf6ad775 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:04 -0500
Subject: [PATCH 1494/3820] New translations enums.mdx (Polish)

---
 website/pages/pl/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/enums.mdx b/website/pages/pl/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..a10970c1539f
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Additional Resources
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From c3fffda8483947491a504327e4f03bb26b0e5c5f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:05 -0500
Subject: [PATCH 1495/3820] New translations enums.mdx (Portuguese)

---
 website/pages/pt/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/enums.mdx b/website/pages/pt/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..ddfda1aae5bd
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Por que isto é um problema?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Outros Recursos
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 47470b1792271f1ff1cea99c6587a2bbde1dab16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:06 -0500
Subject: [PATCH 1496/3820] New translations enums.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/enums.mdx b/website/pages/ru/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..bf4f37f4152a
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Почему это является проблемой?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Дополнительные ресурсы
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From c46f1db3142ea881c5fbf5a02d592246bf14cb5e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:08 -0500
Subject: [PATCH 1497/3820] New translations enums.mdx (Swedish)

---
 website/pages/sv/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/enums.mdx b/website/pages/sv/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..2fc0efcc5831
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Ytterligare resurser
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From b03830d8dda4d133b85a0185c229e7897ae0102f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:09 -0500
Subject: [PATCH 1498/3820] New translations enums.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/enums.mdx b/website/pages/tr/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..99d1a01a02c0
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Bu neden bir sorun?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Ek Kaynaklar
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From cf74f2a05e6a2435cb9b77a3153b016ef1d35ac2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:10 -0500
Subject: [PATCH 1499/3820] New translations enums.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/enums.mdx b/website/pages/uk/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..4fa07dc05765
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Додаткові матеріали
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 9d29ce806600fe4a97238d39c0fe1a01ff29f4ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:11 -0500
Subject: [PATCH 1500/3820] New translations enums.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/enums.mdx b/website/pages/zh/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..43d1ad4cc0c2
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## 其他资源
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 70cee17f159bca8d06e77b6bd1eecb60b0139040 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:12 -0500
Subject: [PATCH 1501/3820] New translations enums.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/enums.mdx b/website/pages/ur/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..8991c45dd81a
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## اضافی وسائل
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 21eff58d2e2236fc7c068e906eeed23fb18be200 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:14 -0500
Subject: [PATCH 1502/3820] New translations enums.mdx (Vietnamese)

---
 website/pages/vi/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/enums.mdx b/website/pages/vi/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..a10970c1539f
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Additional Resources
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 6330b0edd4e0c16908f3ff721299dde7f9ed81ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:15 -0500
Subject: [PATCH 1503/3820] New translations enums.mdx (Marathi)

---
 website/pages/mr/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/enums.mdx b/website/pages/mr/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..081add904f9a
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## अतिरिक्त संसाधने
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 8732507bb69ec19594ab82d74eaaefc5481e88de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:16 -0500
Subject: [PATCH 1504/3820] New translations enums.mdx (Hindi)

---
 website/pages/hi/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/enums.mdx b/website/pages/hi/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..c542f7d54f90
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### यह एक समस्या क्यों है?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Additional Resources
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From 2dd8317a5bd42778dff4894233ead4cea6446243 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:17 -0500
Subject: [PATCH 1505/3820] New translations enums.mdx (Swahili)

---
 website/pages/sw/subgraphs/cookbook/enums.mdx | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/enums.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/enums.mdx b/website/pages/sw/subgraphs/cookbook/enums.mdx
new file mode 100644
index 000000000000..a10970c1539f
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/enums.mdx
@@ -0,0 +1,274 @@
+---
+title: Categorize NFT Marketplaces Using Enums
+---
+
+Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+
+## What are Enums?
+
+Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+
+### Example of Enums in Your Schema
+
+If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+
+You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+
+Here's what an enum definition might look like in your schema, based on the example above:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+
+To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+
+## Benefits of Using Enums
+
+- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
+- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+
+### Without Enums
+
+If you choose to define the type as a string instead of using an Enum, your code might look like this:
+
+```graphql
+type Token @entity {
+  id: ID!
+  tokenId: BigInt!
+  owner: Bytes! # Owner of the token
+  tokenStatus: String! # String field to track token status
+  timestamp: BigInt!
+}
+```
+
+In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+
+#### Why is this a problem?
+
+- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+
+### With Enums
+
+Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+
+Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+
+## Defining Enums for NFT Marketplaces
+
+> Note: The following guide uses the CryptoCoven NFT smart contract.
+
+To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+
+```gql
+# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+enum Marketplace {
+  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
+  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
+  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
+  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
+  # ...and other marketplaces
+}
+```
+
+## Using Enums for NFT Marketplaces
+
+Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+
+For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+
+### Implementing a Function for NFT Marketplaces
+
+Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+
+```ts
+export function getMarketplaceName(marketplace: Marketplace): string {
+  // Using if-else statements to map the enum value to a string
+  if (marketplace === Marketplace.OpenSeaV1) {
+    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+  } else if (marketplace === Marketplace.OpenSeaV2) {
+    return 'OpenSeaV2'
+  } else if (marketplace === Marketplace.SeaPort) {
+    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+  } else if (marketplace === Marketplace.LooksRare) {
+    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
+    // ... and other market places
+  }
+}
+```
+
+## Best Practices for Using Enums
+
+- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- **Documentation:** Add comments to enum to clarify their purpose and usage.
+
+## Using Enums in Queries
+
+Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+
+**Specifics**
+
+- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
+- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+
+### Sample Queries
+
+#### Query 1: Account With The Highest NFT Marketplace Interactions
+
+This query does the following:
+
+- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
+- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+
+```gql
+{
+  accounts(first: 1, orderBy: uniqueMarketplacesCount, orderDirection: desc) {
+    id
+    sendCount
+    receiveCount
+    totalSpent
+    uniqueMarketplacesCount
+    marketplaces {
+      marketplace # This field returns the enum value representing the marketplace
+    }
+  }
+}
+```
+
+#### Returns
+
+This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+
+```gql
+{
+  "data": {
+    "accounts": [
+      {
+        "id": "0xb3abc96cb9a61576c03c955d75b703a890a14aa0",
+        "sendCount": "44",
+        "receiveCount": "44",
+        "totalSpent": "1197500000000000000",
+        "uniqueMarketplacesCount": "7",
+        "marketplaces": [
+          {
+            "marketplace": "OpenSeaV1"
+          },
+          {
+            "marketplace": "OpenSeaV2"
+          },
+          {
+            "marketplace": "GenieSwap"
+          },
+          {
+            "marketplace": "CryptoCoven"
+          },
+          {
+            "marketplace": "Unknown"
+          },
+          {
+            "marketplace": "LooksRare"
+          },
+          {
+            "marketplace": "NFTX"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+#### Query 2: Most Active Marketplace for CryptoCoven transactions
+
+This query does the following:
+
+- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+
+```gql
+{
+  marketplaceInteractions(first: 1, orderBy: transactionCount, orderDirection: desc) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 2
+
+The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "Unknown",
+        "transactionCount": "222"
+      }
+    ]
+  }
+}
+```
+
+#### Query 3: Marketplace Interactions with High Transaction Counts
+
+This query does the following:
+
+- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+
+```gql
+{
+  marketplaceInteractions(
+    first: 4
+    orderBy: transactionCount
+    orderDirection: desc
+    where: { transactionCount_gt: "100", marketplace_not: "Unknown" }
+  ) {
+    marketplace
+    transactionCount
+  }
+}
+```
+
+#### Result 3
+
+Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+
+```gql
+{
+  "data": {
+    "marketplaceInteractions": [
+      {
+        "marketplace": "NFTX",
+        "transactionCount": "201"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "148"
+      },
+      {
+        "marketplace": "CryptoCoven",
+        "transactionCount": "117"
+      },
+      {
+        "marketplace": "OpenSeaV1",
+        "transactionCount": "111"
+      }
+    ]
+  }
+}
+```
+
+## Additional Resources
+
+For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From decf1777b1e795234f4fc9911facd4335d658548 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:18 -0500
Subject: [PATCH 1506/3820] New translations grafting-hotfix.mdx (Romanian)

---
 .../ro/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/ro/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..a0bd3f4ab1c2
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Overview
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Additional Resources
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 9bfe66be79fcd501b5beff10ddc9c9bf677f055d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:19 -0500
Subject: [PATCH 1507/3820] New translations grafting-hotfix.mdx (French)

---
 .../fr/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/fr/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..9c5e7b4c4051
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Aperçu
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Ressources complémentaires
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 3cdf767e703721294c61461a2eef8db29b438b17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:20 -0500
Subject: [PATCH 1508/3820] New translations grafting-hotfix.mdx (Spanish)

---
 .../es/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/es/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/es/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..ddf69bb91735
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Descripción
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Recursos Adicionales
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 69db736d7c1f05b4c3ef2a8bec3f4e4e3eed3eb3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:21 -0500
Subject: [PATCH 1509/3820] New translations grafting-hotfix.mdx (Arabic)

---
 .../ar/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/ar/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..2bbe296c724a
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### نظره عامة
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## مصادر إضافية
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 8741ce2d8f711fd2f038e5bbfc5754c002a4ac1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:23 -0500
Subject: [PATCH 1510/3820] New translations grafting-hotfix.mdx (Czech)

---
 .../cs/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/cs/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..934f1dd419c3
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Přehled
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Závěr
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Další zdroje
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 0678017358b16282aa9adb4111833f9656f3fb5e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:24 -0500
Subject: [PATCH 1511/3820] New translations grafting-hotfix.mdx (German)

---
 .../de/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..a0bd3f4ab1c2
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Overview
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Additional Resources
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From df534d7808704dc855159bec23574743d44bb2b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:25 -0500
Subject: [PATCH 1512/3820] New translations grafting-hotfix.mdx (Italian)

---
 .../it/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/it/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/it/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..53c1bae83194
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Panoramica
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Additional Resources
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From a76173ec09b444a9839f296dccfb497888d10fd2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:26 -0500
Subject: [PATCH 1513/3820] New translations grafting-hotfix.mdx (Japanese)

---
 .../ja/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/ja/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..ce3e717c103a
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### 概要
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## その他のリソース
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From c276f6e9b560af945af4df8d25c4695b8f8d036b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:27 -0500
Subject: [PATCH 1514/3820] New translations grafting-hotfix.mdx (Korean)

---
 .../ko/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/ko/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..a0bd3f4ab1c2
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Overview
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Additional Resources
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 109a0c3abdf9d4aeeb04168c209ca9d42f1f5d8b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:28 -0500
Subject: [PATCH 1515/3820] New translations grafting-hotfix.mdx (Dutch)

---
 .../nl/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/nl/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..a0bd3f4ab1c2
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Overview
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Additional Resources
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 0e7546efec00552dcba61cc791fbeb6c4d51d2e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:29 -0500
Subject: [PATCH 1516/3820] New translations grafting-hotfix.mdx (Polish)

---
 .../pl/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/pl/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..a0bd3f4ab1c2
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Overview
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Additional Resources
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From b5faef286dca9bf6e4009e478b6ae9d0cca01314 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:30 -0500
Subject: [PATCH 1517/3820] New translations grafting-hotfix.mdx (Portuguese)

---
 .../pt/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/pt/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..b09d54c13373
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Visão geral
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusão
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Outros Recursos
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From b7c7bcb4dc0713f37a138bb26e9b78aa7fb6c31b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:31 -0500
Subject: [PATCH 1518/3820] New translations grafting-hotfix.mdx (Russian)

---
 .../ru/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..37a0180f89e1
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## Краткое содержание
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Обзор
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Заключение
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Дополнительные ресурсы
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From e0869755d03313208d3fabebe9ed97a7876a6060 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:32 -0500
Subject: [PATCH 1519/3820] New translations grafting-hotfix.mdx (Swedish)

---
 .../sv/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/sv/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..cd68f5b32a38
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Översikt
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Ytterligare resurser
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 588ed252781a02fc14c5e68ba80bedbbf112c98b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:33 -0500
Subject: [PATCH 1520/3820] New translations grafting-hotfix.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..1169b1e2b4eb
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Genel Bakış
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Ek Kaynaklar
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 60636df727b0405a1ab35fefd96ba2106ebea108 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:35 -0500
Subject: [PATCH 1521/3820] New translations grafting-hotfix.mdx (Ukrainian)

---
 .../uk/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/uk/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..55f8f96e3cd4
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Overview
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Додаткові матеріали
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 1bf846ef305e8a6bf0b6cc253b487d310a8872ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:36 -0500
Subject: [PATCH 1522/3820] New translations grafting-hotfix.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/zh/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..8153e7143816
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### 概述
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## 其他资源
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From b8682e060eb15fa9ab5e2946ee2832dd71989fe8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:37 -0500
Subject: [PATCH 1523/3820] New translations grafting-hotfix.mdx (Urdu
 (Pakistan))

---
 .../ur/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/ur/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..780d7ad3f827
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### جائزہ
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## اضافی وسائل
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 86c55af5d9a302aa982bf40a1f42653daef5741b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:38 -0500
Subject: [PATCH 1524/3820] New translations grafting-hotfix.mdx (Vietnamese)

---
 .../vi/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/vi/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..ddf32cc35aa6
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Tổng quan
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Additional Resources
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 4c8881d5bf0559a09d4e458c22af0c4e47569ba5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:39 -0500
Subject: [PATCH 1525/3820] New translations grafting-hotfix.mdx (Marathi)

---
 .../mr/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/mr/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..1aa5dfadb745
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### सविश्लेषण
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## अतिरिक्त संसाधने
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 9d2b3e8dfc3c726d0051ef87d402f9d55044a667 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:40 -0500
Subject: [PATCH 1526/3820] New translations grafting-hotfix.mdx (Hindi)

---
 .../hi/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/hi/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..6758fbeb327e
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### अवलोकन
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## निष्कर्ष
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Additional Resources
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 2619141bbd4857a0f9e178dd8ea8c2c11cc7913a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:41 -0500
Subject: [PATCH 1527/3820] New translations grafting-hotfix.mdx (Swahili)

---
 .../sw/subgraphs/cookbook/grafting-hotfix.mdx | 186 ++++++++++++++++++
 1 file changed, 186 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/grafting-hotfix.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/sw/subgraphs/cookbook/grafting-hotfix.mdx
new file mode 100644
index 000000000000..a0bd3f4ab1c2
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/grafting-hotfix.mdx
@@ -0,0 +1,186 @@
+---
+title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+---
+
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+
+### Overview
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+
+## Benefits of Grafting for Hotfixes
+
+1. **Rapid Deployment**
+
+   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
+   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+
+2. **Data Preservation**
+
+   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+
+3. **Efficiency**
+   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
+   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+
+## Best Practices When Using Grafting for Hotfixes
+
+1. **Initial Deployment Without Grafting**
+
+   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
+   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+
+2. **Implementing the Hotfix with Grafting**
+
+   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
+   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
+   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
+   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+
+3. **Post-Hotfix Actions**
+
+   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
+   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
+     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+
+4. **Important Considerations**
+   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Tip**: Use the block number of the last correctly processed event.
+   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
+   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+
+## Example: Deploying a Hotfix with Grafting
+
+Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+
+1. **Failed Subgraph Manifest (subgraph.yaml)**
+
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: OldSmartContract
+       network: sepolia
+       source:
+         address: '0xOldContractAddress'
+         abi: Lock
+         startBlock: 5000000
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/OldLock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleOldWithdrawal
+         file: ./src/old-lock.ts
+   ```
+
+2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+   ```yaml
+   specVersion: 1.0.0
+   schema:
+     file: ./schema.graphql
+   dataSources:
+     - kind: ethereum/contract
+       name: NewSmartContract
+       network: sepolia
+       source:
+         address: '0xNewContractAddress'
+         abi: Lock
+         startBlock: 6000001 # Block after the last indexed block
+       mapping:
+         kind: ethereum/events
+         apiVersion: 0.0.7
+         language: wasm/assemblyscript
+         entities:
+           - Withdrawal
+         abis:
+           - name: Lock
+             file: ./abis/Lock.json
+         eventHandlers:
+           - event: Withdrawal(uint256,uint256)
+             handler: handleWithdrawal
+         file: ./src/lock.ts
+   features:
+     - grafting
+   graft:
+     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
+     block: 6000000 # Last successfully indexed block
+   ```
+
+**Explanation:**
+
+- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
+- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
+- **Grafting Configuration**:
+  - **base**: Deployment ID of the failed subgraph.
+  - **block**: Block number where grafting should begin.
+
+3. **Deployment Steps**
+
+   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
+   - **Deploy the Subgraph**:
+     - Authenticate with the Graph CLI.
+     - Deploy the new subgraph using `graph deploy`.
+
+4. **Post-Deployment**
+   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
+   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+
+## Warnings and Cautions
+
+While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+
+- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
+- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+
+### Risk Management
+
+- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Testing**: Always test grafting in a development environment before deploying to production.
+
+## Conclusion
+
+Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+
+- **Quickly Recover** from critical errors without re-indexing.
+- **Preserve Historical Data**, maintaining continuity for applications and users.
+- **Ensure Service Availability** by minimizing downtime during critical fixes.
+
+However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+
+## Additional Resources
+
+- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
+- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+
+By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 03518b5579a6a25d1e70ab37276b71f443204a7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:42 -0500
Subject: [PATCH 1528/3820] New translations grafting.mdx (Romanian)

---
 .../pages/ro/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/grafting.mdx b/website/pages/ro/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..57d5169830a7
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Replace a Contract and Keep its History With Grafting
+---
+
+In this guide, you will learn how to build and deploy new subgraphs by grafting existing subgraphs.
+
+## What is Grafting?
+
+Grafting reuses the data from an existing subgraph and starts indexing it at a later block. This is useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. Also, it can be used when adding a feature to a subgraph that takes long to index from scratch.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+For more information, you can check:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## Building an Existing Subgraph
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Grafting Manifest Definition
+
+Grafting requires adding two new items to the original subgraph manifest:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Deploying the Base Subgraph
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It returns something like this:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Once you have verified the subgraph is indexing properly, you can quickly update the subgraph with grafting.
+
+## Deploying the Grafting Subgraph
+
+The graft replacement subgraph.yaml will have a new contract address. This could happen when you update your dapp, redeploy a contract, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It should return the following:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Additional Resources
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 59c7d1fa0c540795815a86a1fa4567cc91626fbb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:43 -0500
Subject: [PATCH 1529/3820] New translations grafting.mdx (French)

---
 .../pages/fr/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/grafting.mdx b/website/pages/fr/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..8d8e1206de5f
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Remplacer un contrat et conserver son historique grâce au « greffage »
+---
+
+Dans ce guide, vous apprendrez à construire et à déployer de nouveaux subgraphs en utilisant le greffage sur des subgraphs existants.
+
+## Qu'est-ce qu'une greffe ?
+
+C'est une méthode qui réutilise les données d'un subgraph existant et commence à les indexer à un bloc ultérieur. Elle est utile lors du développement pour contourner rapidement les erreurs simples dans les mappings ou pour remettre temporairement en service un subgraph existant qui a échoué. Elle peut également être utilisée pour ajouter une fonctionnalité à un subgraphe dont l'indexation depuis la genèse prend un temps considérable.
+
+Le subgraph greffé peut utiliser un schema GraphQL qui n'est pas identique à celui du subgraph de base, mais simplement compatible avec lui. Il doit s'agir d'un schema de subgraph valide en tant que tel, mais il peut s'écarter du schema du subgraph de base de la manière suivante :
+
+- Il ajoute ou supprime des types d'entité
+- Il supprime les attributs des types d'entité
+- Il ajoute des attributs nullables aux types d'entités
+- Il transforme les attributs non nullables en attributs nuls
+- Cela ajoute des valeurs aux énumérations
+- Il ajoute ou supprime des interfaces
+- Cela change pour quels types d'entités une interface est implémentée
+
+Pour plus d’informations, vous pouvez vérifier :
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+Dans ce tutoriel, nous couvrirons un cas d'utilisation de base. Nous remplacerons un contrat existant par un contrat identique (avec une nouvelle adresse, mais le même code). Ensuite, nous grefferons le subgraph existant sur le subgraph "de base" qui suit le nouveau contrat.
+
+## Remarque importante sur le greffage lors de la mise à niveau vers le réseau
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Pourquoi est-ce important?
+
+Le greffage est une fonctionnalité puissante qui vous permet de "greffer" un subgraph sur un autre, transférant efficacement les données historiques du subgraph existant vers une nouvelle version. Il n'est pas possible de greffer un subgraph de The Graph Network vers Subgraph Studio.
+
+### Les meilleures pratiques
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+En respectant ces lignes directrices, vous minimisez les risques et vous vous assurez que le processus de migration se déroule sans heurts.
+
+## Création d'un subgraph existant
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Définition du manifeste du subgraph
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Définition de manifeste de greffage
+
+Le greffage nécessite l'ajout de deux nouveaux éléments au manifeste du subgraph original :
+
+```yaml
+---
+features:
+  - grafting # nom de la fonctionnalité
+graft:
+  base: Qm... # ID du subgraph de base
+  block: 5956000 # numéro du bloc
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Déploiement du subgraph de base
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Une fois terminé, vérifiez que le subgraph s'indexe correctement. Si vous exécutez la commande suivante dans The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Cela renvoie quelque chose comme ceci :
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Une fois que vous avez vérifié que le subgraph s'indexe correctement, vous pouvez rapidement le mettre à jour grâce à la méthode du graffage.
+
+## Déploiement du subgraph greffé
+
+Le subgraph.yaml de remplacement du greffon aura une nouvelle adresse de contrat. Cela peut arriver lorsque vous mettez à jour votre dapp, redéployez un contrat, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Une fois terminé, vérifiez que le subgraph s'indexe correctement. Si vous exécutez la commande suivante dans The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Le résultat devrait être le suivant :
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Félicitations ! Vous avez réussi à greffer un subgraph sur un autre subgraph.
+
+## Ressources complémentaires
+
+Si vous souhaitez acquérir plus d'expérience avec le greffage, voici quelques exemples pour des contrats populaires :
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 2381afc1a83f985f46f78fac6e7f846f56462ae1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:44 -0500
Subject: [PATCH 1530/3820] New translations grafting.mdx (Spanish)

---
 .../pages/es/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/es/subgraphs/cookbook/grafting.mdx b/website/pages/es/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..4a98c7ab352b
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Reemplazar un contrato y mantener su historia con el grafting
+---
+
+En esta guía, aprenderás a construir y deployar nuevos subgrafos mediante grafting (injerto) de subgrafos existentes.
+
+## ¿Qué es el Grafting?
+
+El grafting reutiliza los datos de un subgrafo existente y comienza a indexarlo en un bloque posterior. Esto es útil durante el desarrollo para superar rápidamente errores simples en los mapeos o para hacer funcionar temporalmente un subgrafo existente después de que haya fallado. También se puede utilizar cuando se añade un feature a un subgrafo que tarda en indexarse desde cero.
+
+El subgrafo grafteado puede utilizar un esquema GraphQL que no es idéntico al del subgrafo base, sino simplemente compatible con él. Tiene que ser un esquema de subgrafo válido por sí mismo, pero puede diferir del esquema del subgrafo base de las siguientes maneras:
+
+- Agrega o elimina tipos de entidades
+- Elimina los atributos de los tipos de entidad
+- Agrega atributos anulables a los tipos de entidad
+- Convierte los atributos no anulables en atributos anulables
+- Añade valores a los enums
+- Agrega o elimina interfaces
+- Cambia para qué tipos de entidades se implementa una interfaz
+
+Para más información, puedes consultar:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## Construcción de un subgrafo existente
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Definición de manifiesto del subgrafo
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Definición del manifiesto de grafting
+
+El grafting requiere añadir dos nuevos items al manifiesto original del subgrafo:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Deploy del subgrafo base
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Una vez que hayas terminado, verifica que el subgrafo se está indexando correctamente. Si ejecutas el siguiente comando en The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Devuelve algo como esto:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Una vez que hayas verificado que el subgrafo se está indexando correctamente, puedes actualizar rápidamente el subgrafo con grafting.
+
+## Deploy del subgrafo grafting
+
+El subgraph.yaml de sustitución del graft tendrá una nueva dirección de contrato. Esto podría ocurrir cuando actualices tu dApp, vuelvas a deployar un contrato, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Una vez que hayas terminado, verifica que el subgrafo se está indexando correctamente. Si ejecutas el siguiente comando en The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Debería devolver lo siguiente:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Recursos Adicionales
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 85648d80e4f876cf9baa1fa26edd081d01d2027d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:45 -0500
Subject: [PATCH 1531/3820] New translations grafting.mdx (Arabic)

---
 .../pages/ar/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/grafting.mdx b/website/pages/ar/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..704e7df3f3f6
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Replace a Contract and Keep its History With Grafting
+---
+
+In this guide, you will learn how to build and deploy new subgraphs by grafting existing subgraphs.
+
+## What is Grafting?
+
+Grafting reuses the data from an existing subgraph and starts indexing it at a later block. This is useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. Also, it can be used when adding a feature to a subgraph that takes long to index from scratch.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- يضيف أو يزيل أنواع الكيانات
+- يزيل الصفات من أنواع الكيانات
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- يغير للكيانات التي يتم تنفيذ الواجهة لها
+
+For more information, you can check:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## Building an Existing Subgraph
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## تعريف Subgraph Manifest
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Grafting Manifest Definition
+
+Grafting requires adding two new items to the original subgraph manifest:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Deploying the Base Subgraph
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It returns something like this:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Once you have verified the subgraph is indexing properly, you can quickly update the subgraph with grafting.
+
+## Deploying the Grafting Subgraph
+
+The graft replacement subgraph.yaml will have a new contract address. This could happen when you update your dapp, redeploy a contract, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It should return the following:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## مصادر إضافية
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From ecccbfc93eacbaf230cc090fa0307022046495ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:46 -0500
Subject: [PATCH 1532/3820] New translations grafting.mdx (Czech)

---
 .../pages/cs/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/grafting.mdx b/website/pages/cs/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..ca0ab0367451
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Nahrazení smlouvy a zachování její historie pomocí roubování
+---
+
+V této příručce se dozvíte, jak vytvářet a nasazovat nové podgrafy roubováním stávajících podgrafů.
+
+## Co je to roubování?
+
+Při roubování se znovu použijí data z existujícího podgrafu a začne se indexovat v pozdějším bloku. To je užitečné během vývoje, abyste se rychle dostali přes jednoduché chyby v mapování nebo abyste dočasně znovu zprovoznili existující podgraf po jeho selhání. Také ji lze použít při přidávání funkce do podgrafu, které trvá dlouho, než se indexuje od začátku.
+
+Štěpovaný podgraf může používat schéma GraphQL, které není totožné se schématem základního podgrafu, ale je s ním pouze kompatibilní. Musí to být platné schéma podgrafu jako takové, ale může se od schématu základního podgrafu odchýlit následujícími způsoby:
+
+- Přidává nebo odebírá typy entit
+- Odstraňuje atributy z typů entit
+- Přidává nulovatelné atributy k typům entit
+- Mění nenulovatelné atributy na nulovatelné atributy
+- Přidává hodnoty do enums
+- Přidává nebo odebírá rozhraní
+- Mění se, pro které typy entit je rozhraní implementováno
+
+Další informace naleznete na:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Důležité upozornění k roubování při aktualizaci na síť
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Proč je to důležité?
+
+Štěpování je výkonná funkce, která umožňuje "naroubovat" jeden podgraf na druhý, čímž efektivně přenese historická data ze stávajícího podgrafu do nové verze. Podgraf není možné naroubovat ze Sítě grafů zpět do Podgraf Studio.
+
+### Osvědčené postupy
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+Dodržováním těchto pokynů minimalizujete rizika a zajistíte hladší průběh migrace.
+
+## Vytvoření existujícího podgrafu
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Definice podgrafu Manifest
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Definice manifestu roubování
+
+Roubování vyžaduje přidání dvou nových položek do původního manifestu podgrafu:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Nasazení základního podgrafu
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Po dokončení ověřte, zda se podgraf správně indexuje. Pokud spustíte následující příkaz v The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Vrátí něco takového:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Jakmile ověříte, že se podgraf správně indexuje, můžete jej rychle aktualizovat pomocí roubování.
+
+## Nasazení podgrafu roubování
+
+Náhradní podgraf.yaml bude mít novou adresu smlouvy. K tomu může dojít při aktualizaci dapp, novém nasazení kontraktu atd.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Po dokončení ověřte, zda se podgraf správně indexuje. Pokud spustíte následující příkaz v The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Měla by vrátit následující:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Gratulujeme! Úspěšně jste naroubovali podgraf na jiný podgraf.
+
+## Další zdroje
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 0ae57e47ba6a95e02b1279233d2ae1000137727a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:47 -0500
Subject: [PATCH 1533/3820] New translations grafting.mdx (German)

---
 .../pages/de/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/de/subgraphs/cookbook/grafting.mdx b/website/pages/de/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..593ab8880977
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Replace a Contract and Keep its History With Grafting
+---
+
+In this guide, you will learn how to build and deploy new subgraphs by grafting existing subgraphs.
+
+## What is Grafting?
+
+Grafting reuses the data from an existing subgraph and starts indexing it at a later block. This is useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. Also, it can be used when adding a feature to a subgraph that takes long to index from scratch.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+For more information, you can check:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## Building an Existing Subgraph
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Subgraf-Manifest-Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Grafting Manifest Definition
+
+Grafting requires adding two new items to the original subgraph manifest:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Deploying the Base Subgraph
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It returns something like this:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Once you have verified the subgraph is indexing properly, you can quickly update the subgraph with grafting.
+
+## Deploying the Grafting Subgraph
+
+The graft replacement subgraph.yaml will have a new contract address. This could happen when you update your dapp, redeploy a contract, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It should return the following:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Additional Resources
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 686542accf1c112461f48df54d19730d0ec02c69 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:48 -0500
Subject: [PATCH 1534/3820] New translations grafting.mdx (Italian)

---
 .../pages/it/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/it/subgraphs/cookbook/grafting.mdx b/website/pages/it/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..57d5169830a7
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Replace a Contract and Keep its History With Grafting
+---
+
+In this guide, you will learn how to build and deploy new subgraphs by grafting existing subgraphs.
+
+## What is Grafting?
+
+Grafting reuses the data from an existing subgraph and starts indexing it at a later block. This is useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. Also, it can be used when adding a feature to a subgraph that takes long to index from scratch.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+For more information, you can check:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## Building an Existing Subgraph
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Grafting Manifest Definition
+
+Grafting requires adding two new items to the original subgraph manifest:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Deploying the Base Subgraph
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It returns something like this:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Once you have verified the subgraph is indexing properly, you can quickly update the subgraph with grafting.
+
+## Deploying the Grafting Subgraph
+
+The graft replacement subgraph.yaml will have a new contract address. This could happen when you update your dapp, redeploy a contract, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It should return the following:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Additional Resources
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From b5b91ade36a445f246dd6c1059c0f71eda27e770 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:50 -0500
Subject: [PATCH 1535/3820] New translations grafting.mdx (Japanese)

---
 .../pages/ja/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/grafting.mdx b/website/pages/ja/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..0be8b13c8dbd
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: グラフティングでコントラクトを取り替え、履歴を残す
+---
+
+このガイドでは、既存のサブグラフをグラフティングして新しいサブグラフを構築し、配備する方法を学びます。
+
+## グラフティングとは？
+
+グラフティングは、既存のサブグラフからデータを再利用し、後のブロックからインデックスを作成します。これは、開発中にマッピングの単純なエラーを素早く乗り越えるため、または、既存のサブグラフが失敗した後に一時的に再び動作させるために有用です。また、ゼロからインデックスを作成するのに時間がかかる機能をサブグラフに追加する場合にも使用できます。
+
+グラフト化されたサブグラフは、ベースとなるサブグラフのスキーマと同一ではなく、単に互換性のある GraphQL スキーマを使用することができます。また、それ自体は有効なサブグラフのスキーマでなければなりませんが、以下の方法でベースサブグラフのスキーマから逸脱することができます。
+
+- エンティティタイプを追加または削除する
+- エンティティタイプから属性を削除する
+- 属性を追エンティティタイプに nullable加する
+- null 化できない属性を null 化できる属性に変更する
+- enums に値を追加する
+- インターフェースの追加または削除
+- インターフェースがどのエンティティタイプに実装されるかを変更する
+
+詳しくは、こちらでご確認ください。
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## ネットワークにアップグレードする際の移植に関する重要な注意事項
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### 何でこれが大切ですか？
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### ベストプラクティス
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+これらのガイドラインに従うことで、リスクを最小限に抑え、よりスムーズな移行プロセスを確保できます。
+
+## 既存のサブグラフの構築
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## サブグラフマニフェストの定義
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## グラフティングマニフェストの定義
+
+グラフティングは、元のサブグラフ・マニフェストに新しい2つの項目を追加する必要があります。
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## ベースサブグラフの起動
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. 終了後、サブグラフが正しくインデックスされていることを確認します。The Graph Playgroundで以下のコマンドを実行すると、サブグラフが正常にインデックスされます。
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+このようなものが返ってきます：
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+サブグラフが正しくインデックスされていることを確認したら、グラフティングで素早くサブグラフを更新することができます。
+
+## グラフティングサブグラフの展開
+
+グラフト置換されたsubgraph.yamlは、新しいコントラクトのアドレスを持つことになります。これは、ダンプを更新したり、コントラクトを再デプロイしたりしたときに起こりうることです。
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. 終了後、サブグラフが正しくインデックスされていることを確認します。The Graph Playgroundで以下のコマンドを実行すると、サブグラフが正常にインデックスされます。
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+以下のように返ってくるはずです：
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## その他のリソース
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From d7f5793f78d56cebc43c9b18fb366a8e2102f3a7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:51 -0500
Subject: [PATCH 1536/3820] New translations grafting.mdx (Korean)

---
 .../pages/ko/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/grafting.mdx b/website/pages/ko/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..57d5169830a7
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Replace a Contract and Keep its History With Grafting
+---
+
+In this guide, you will learn how to build and deploy new subgraphs by grafting existing subgraphs.
+
+## What is Grafting?
+
+Grafting reuses the data from an existing subgraph and starts indexing it at a later block. This is useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. Also, it can be used when adding a feature to a subgraph that takes long to index from scratch.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+For more information, you can check:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## Building an Existing Subgraph
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Grafting Manifest Definition
+
+Grafting requires adding two new items to the original subgraph manifest:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Deploying the Base Subgraph
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It returns something like this:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Once you have verified the subgraph is indexing properly, you can quickly update the subgraph with grafting.
+
+## Deploying the Grafting Subgraph
+
+The graft replacement subgraph.yaml will have a new contract address. This could happen when you update your dapp, redeploy a contract, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It should return the following:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Additional Resources
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 3bd30af2d252fa027d28b20fe403716fd093e706 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:52 -0500
Subject: [PATCH 1537/3820] New translations grafting.mdx (Dutch)

---
 .../pages/nl/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/grafting.mdx b/website/pages/nl/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..57d5169830a7
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Replace a Contract and Keep its History With Grafting
+---
+
+In this guide, you will learn how to build and deploy new subgraphs by grafting existing subgraphs.
+
+## What is Grafting?
+
+Grafting reuses the data from an existing subgraph and starts indexing it at a later block. This is useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. Also, it can be used when adding a feature to a subgraph that takes long to index from scratch.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+For more information, you can check:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## Building an Existing Subgraph
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Grafting Manifest Definition
+
+Grafting requires adding two new items to the original subgraph manifest:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Deploying the Base Subgraph
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It returns something like this:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Once you have verified the subgraph is indexing properly, you can quickly update the subgraph with grafting.
+
+## Deploying the Grafting Subgraph
+
+The graft replacement subgraph.yaml will have a new contract address. This could happen when you update your dapp, redeploy a contract, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It should return the following:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Additional Resources
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From c0f751feb16bd70f74c18529ad72ed996e558767 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:53 -0500
Subject: [PATCH 1538/3820] New translations grafting.mdx (Polish)

---
 .../pages/pl/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/grafting.mdx b/website/pages/pl/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..57d5169830a7
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Replace a Contract and Keep its History With Grafting
+---
+
+In this guide, you will learn how to build and deploy new subgraphs by grafting existing subgraphs.
+
+## What is Grafting?
+
+Grafting reuses the data from an existing subgraph and starts indexing it at a later block. This is useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. Also, it can be used when adding a feature to a subgraph that takes long to index from scratch.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+For more information, you can check:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## Building an Existing Subgraph
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Grafting Manifest Definition
+
+Grafting requires adding two new items to the original subgraph manifest:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Deploying the Base Subgraph
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It returns something like this:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Once you have verified the subgraph is indexing properly, you can quickly update the subgraph with grafting.
+
+## Deploying the Grafting Subgraph
+
+The graft replacement subgraph.yaml will have a new contract address. This could happen when you update your dapp, redeploy a contract, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It should return the following:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Additional Resources
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 41c1563f422744b45ef5b2f9c245aa26aded5bc9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:54 -0500
Subject: [PATCH 1539/3820] New translations grafting.mdx (Portuguese)

---
 .../pages/pt/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/grafting.mdx b/website/pages/pt/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..97809af300ce
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Como Substituir um Contrato e Manter a sua História com Enxertos
+---
+
+Neste guia, aprenda como construir e lançar novos subgraphs com o enxerto de subgraphs existentes.
+
+## O que é Enxerto?
+
+O processo de enxerto reutiliza os dados de um subgraph existente e o indexa em um bloco seguinte. Isto é útil durante o desenvolvimento para rapidamente superar erros simples nos mapeamentos, ou fazer um subgraph existente funcionar temporariamente após ele ter falhado. Ele também pode ser usado ao adicionar uma característica a um subgraph que demora para ser indexado do zero.
+
+O subgraph enxertado pode usar um schema GraphQL que não é idêntico ao schema do subgraph base, mas é apenas compatível com ele. Ele deve ser um schema válido no seu próprio mérito, mas pode desviar do schema do subgraph base nas seguintes maneiras:
+
+- Ele adiciona ou remove tipos de entidade
+- Ele retira atributos de tipos de entidade
+- Ele adiciona atributos anuláveis a tipos de entidade
+- Ele transforma atributos não anuláveis em atributos anuláveis
+- Ele adiciona valores a enums
+- Ele adiciona ou remove interfaces
+- Ele muda os tipos de entidades para qual implementar uma interface
+
+Para mais informações, confira:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+Neste tutorial, cobriremos um caso de uso básico. Substituiremos um contrato existente com um contrato idêntico (com um novo endereço, mas o mesmo código). Depois, enxertaremos o subgraph existente ao subgraph "base" que rastreará o novo contrato.
+
+## Notas Importantes sobre Enxertos ao Migrar Para a Graph Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Qual a Importância Disto?
+
+Isto é um recurso poderoso que permite que os programadores "enxertem" um subgraph em outro, o que, efetivamente, transfere dados históricos do subgraph existente até uma versão nova. Não é possível enxertar um subgraph da Graph Network de volta ao Subgraph Studio.
+
+### Boas práticas
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+Ao aderir a estas diretrizes, dá para minimizar riscos e garantir um processo de migração mais suave.
+
+## Como Construir um Subgraph Existente
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Definição de Manifest de Subgraph
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Definição de Manifest de Enxertos
+
+Enxertos exigem a adição de dois novos itens ao manifest do subgraph original:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Como Lançar o Subgraph Base
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Ao terminar, verifique que o subgraph está a indexar corretamente. Se executar o seguinte comando no The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Ele deve retornar algo assim:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Após verificar que o subgraph está a indexar corretamente, será possível atualizar rapidamente o subgraph com o enxerto.
+
+## Como Lançar o Subgraph de Enxerto
+
+O subgraph.yaml do substituto terá um novo endereço de contrato. Isto pode acontecer quando atualizar o seu dapp, relançar um contrato, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Ao terminar, verifique que o subgraph está a indexar corretamente. Se executar o seguinte comando no The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Ele deve retornar algo como:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Parabéns! Enxertaste um subgraph em outro subgraph.
+
+## Outros Recursos
+
+Caso queira mais experiência com enxertos, veja alguns exemplos de contratos populares:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From d49aa6c348a35b3897f22b96cdd772e06b5f2ac6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:55 -0500
Subject: [PATCH 1540/3820] New translations grafting.mdx (Russian)

---
 .../pages/ru/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/grafting.mdx b/website/pages/ru/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..b78dd3b31720
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Замените контракт и сохраните его историю с помощью Grafting
+---
+
+Из этого руководства Вы узнаете, как создавать и развертывать новые субграфы путем графтинга (переноса) существующих субграфов.
+
+## Что такое Grafting?
+
+При графтинге (переносе) повторно используются данные из существующего субрафа и начинается их индексация в более позднем блоке. Это может быть полезно в период разработки, чтобы быстро устранить простые ошибки в мэппинге или временно восстановить работу существующего субграфа после его сбоя. Кроме того, его можно использовать при добавлении в субграф функции, индексация которой с нуля занимает много времени.
+
+Перенесённый субграф может использовать схему GraphQL, которая не идентична схеме базового субграфа, а просто совместима с ней. Это должна быть автономно действующая схема субграфа, но она может отличаться от схемы базового субграфа следующим образом:
+
+- Она добавляет или удаляет типы объектов
+- Она удаляет атрибуты из типов объектов
+- Она добавляет обнуляемые атрибуты к типам объектов
+- Она превращает необнуляемые атрибуты в обнуляемые
+- Она добавляет значения в перечисления
+- Она добавляет или удаляет интерфейсы
+- Она изменяется в зависимости от того, под какой тип объектов реализован интерфейс
+
+Для получения дополнительной информации Вы можете перейти:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+В этом руководстве мы рассмотрим базовый случай использования. Мы заменим существующий контракт идентичным (с новым адресом, но с тем же кодом). Затем подключим существующий субграф к "базовому" субграфу, который отслеживает новый контракт.
+
+## Важное примечание о Grafting при обновлении до сети
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Почему это важно?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Лучшие практики
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+Соблюдая эти рекомендации, Вы минимизируете риски и обеспечите более плавный процесс миграции.
+
+## Создание существующего субграфа
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Определение манифеста субграфа
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Определение Манифеста Grafting
+
+Grafting требует добавления двух новых элементов в исходный манифест субграфа:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Развертывание базового субграфа
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. После завершения убедитесь, что субграф правильно индексируется. Если Вы запустите следующую команду в The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Отклик будет подобным этому:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Убедившись, что субграф индексируется правильно, Вы можете быстро обновить его с помощью графтинга.
+
+## Развертывание grafting субграфа
+
+Замененный subgraph.yaml будет иметь новый адрес контракта. Это может произойти, когда Вы обновите свое децентрализованное приложение, повторно развернете контракт и т. д.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. После завершения убедитесь, что субграф правильно индексируется. Если Вы запустите следующую команду в The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Это должно привести к следующему результату:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Поздравляем! Вы успешно перенесли один субграф в другой.
+
+## Дополнительные ресурсы
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From f6bf001a24054b69d134381e607429af0cf2ae8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:56 -0500
Subject: [PATCH 1541/3820] New translations grafting.mdx (Swedish)

---
 .../pages/sv/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/grafting.mdx b/website/pages/sv/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..e43fd73014c3
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Byt ut ett kontrakt och behåll dess historia med ympning
+---
+
+I den här guiden kommer du att lära dig hur du bygger och distribuerar nya subgrafer genom att ympa befintliga subgrafer.
+
+## Vad är ympning?
+
+Ympning återanvänder data från en befintlig subgraf och börjar indexera den vid ett senare block. Detta är användbart under utveckling för att snabbt komma förbi enkla fel i mappningarna eller för att tillfälligt få en befintlig subgraf att fungera igen efter att den har misslyckats. Det kan också användas när du lägger till en funktion till en subgraf som tar lång tid att indexera från början.
+
+Den ympade subgrafen kan använda ett GraphQL-schema som inte är identiskt med det i bas subgrafen, utan bara är kompatibelt med det. Det måste vara ett giltigt subgraf schema i sig, men kan avvika från bas undergrafens schema på följande sätt:
+
+- Den lägger till eller tar bort entitetstyper
+- Det tar bort attribut från entitetstyper
+- Det tar bort attribut från entitetstyper
+- Det förvandlar icke-nullbara attribut till nullbara attribut
+- Det lägger till värden till enums
+- Den lägger till eller tar bort gränssnitt
+- Det ändrar för vilka entitetstyper ett gränssnitt implementeras
+
+För mer information kan du kontrollera:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Viktig anmärkning om ympning vid uppgradering till nätverket
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Varför är detta viktigt?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Bästa praxis
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+Genom att följa dessa riktlinjer minimerar du riskerna och säkerställer en smidigare migreringsprocess.
+
+## Bygga en befintlig subgraf
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Definition av subgraf manifestet
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Ympnings manifest Definition
+
+Ympning kräver att två nya objekt läggs till i det ursprungliga subgraf manifestet:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Distribuera Bas Subgraf
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. När du är klar kontrollerar du att subgrafen indexerar korrekt. Om du kör följande kommando i The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Den returnerar ungefär så här:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+När du har verifierat att subgrafen indexerar korrekt kan du snabbt uppdatera subgrafen med ympning.
+
+## Utplacering av ympning subgraf
+
+Transplantatersättningen subgraph.yaml kommer att ha en ny kontraktsadress. Detta kan hända när du uppdaterar din dapp, omdisponerar ett kontrakt, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. När du är klar kontrollerar du att subgrafen indexerar korrekt. Om du kör följande kommando i The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Det bör returnera följande:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Ytterligare resurser
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 80a5cf78f93eaf12029ed0d94f57aacab1c117ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:57 -0500
Subject: [PATCH 1542/3820] New translations grafting.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/grafting.mdx b/website/pages/tr/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..27e55907955a
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Bir Sözleşmeyi Değiştirin ve Graftlama ile Geçmişini Koruyun
+---
+
+Bu rehberde, mevcut subgraphları graftlayarak yeni subgraphları nasıl oluşturacağınızı ve dağıtacağınızı öğreneceksiniz.
+
+## Graftlama Nedir?
+
+Graftlama, mevcut bir subgraph'daki verileri yeniden kullanır ve daha sonraki bir blokta indekslemeye başlar. Bu, geliştirme sırasında eşleştirmelerdeki basit hataları hızlı bir şekilde geçmek veya mevcut bir subgraph'ın başarısız olduktan sonra geçici olarak tekrar çalışmasını sağlamak için kullanışlıdır. Ayrıca, sıfırdan indekslenmesi uzun süren bir subgraph'a bir özellik eklerken de kullanılabilir.
+
+Graftlanan subgraph, temel subgraphla tamamen aynı olmayan, ancak onunla uyumlu olan bir GraphQL şeması kullanabilir. Kendi başına geçerli bir subgraph şeması olmalıdır, ancak şu şekillerde temel subgraph şemasından sapabilir:
+
+- Varlık türlerini ekler veya kaldırır
+- Varlık türlerinden öznitelikleri kaldırır
+- Varlık türlerine null yapılabilir öznitelikler ekler
+- Null yapılamayan öznitelikleri null yapılabilir özniteliklere dönüştürür
+- Numaralandırmalara değerler ekler
+- Arayüzleri ekler veya kaldırır
+- Arayüzün hangi varlık türleri için uygulandığını değiştirir
+
+Daha fazla bilgi için kontrol edebilirsiniz:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Ağa Yükseltme Durumunda Graftlamaya İlişkin Önemli Not
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Bu Neden Önemli?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### En İyi Uygulamalar
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+Bu yönergelere uyarak riskleri en aza indirebilir ve daha sorunsuz bir taşıma süreci geçirebilirsiniz.
+
+## Mevcut Bir Subgraph'ı Oluşturma
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Subgraph Manifest Tanımı
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Graftlama Manifest Tanımı
+
+Graftlama, orijinal subgraph bildirimine iki yeni öğe eklemeyi gerektirir:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Temel Subgraph'ı Dağıtma
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Tamamlandığında, subgraph'ın doğru bir şekilde indekslendiğinden emin olun. Eğer aşağıdaki komutu Graph Test Alanında(Playground) çalıştırırsanız
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Şuna benzer bir şey döndürür:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Subgraph'ın düzgün bir şekilde indekslendiğini doğruladıktan sonra, subgraph'ı graftlama ile hızlı bir şekilde güncelleyebilirsiniz.
+
+## Graftlama Subgraph'ını Dağıtma
+
+Graft yerine geçen subgraph.yaml yeni bir sözleşme adresine sahip olacaktır. Bu, merkeziyetsiz uygulamanızı güncellediğinizde, bir sözleşmeyi yeniden dağıttığınızda vb. gerçekleşebilir.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Tamamlandığında, subgraph'ın doğru bir şekilde indekslendiğinden emin olun. Eğer aşağıdaki komutu Graph Test Alanında(Playground) çalıştırırsanız
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Aşağıdakileri döndürmelidir:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Ek Kaynaklar
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From bcb3236add7a5203afa830a8d47dc8611999fcc0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:58 -0500
Subject: [PATCH 1543/3820] New translations grafting.mdx (Ukrainian)

---
 .../pages/uk/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/grafting.mdx b/website/pages/uk/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..5455042183df
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Замініть контракт та збережіть його історію за допомогою графтингу
+---
+
+У цьому гайді ви дізнаєтеся, як створювати та розгортати нові підграфи шляхом поєднання наявних підграфів.
+
+## Що таке Grafting?
+
+При цьому процесі повторно використовуються дані з наявного підграфа і починається їх індексування з наступного блоку. Це корисно під час розробки для швидкого усунення простих помилок у схемах або для тимчасового відновлення працездатності наявного підграфа після його збою. Також його можна використовувати при додаванні об'єкта до підграфа, індексація якого з нуля займає багато часу.
+
+Підграф, утворений в результаті може використовувати схему GraphQL, яка не є ідентичною схемі базового підграфа, а лише сумісною з нею. Вона повинна бути валідною схемою підграфа сама по собі, але може відхилятися від схеми базового підграфа у такому випадку:
+
+- Додає або видаляє типи елементів
+- Видаляє атрибути з типів елементів
+- Додає до типів об'єктів атрибути, які можна скасувати
+- Перетворює атрибути, які не можна скасувати, на атрибути, які можна скасувати
+- Додає значення до переліків
+- Додає або видаляє інтерфейси
+- Визначає, для яких типів елементів реалізовано інтерфейс
+
+Для отримання додаткової інформації ви можете ознайомитися:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Важливе зауваження щодо графтингу при оновленні в мережі
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Чому це так важливо?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Найкращі практики
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+Дотримуючись цих рекомендацій, ви мінімізуєте ризики та забезпечите безперешкодний процес міграції.
+
+## Побудова наявного підграфа
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Визначення маніфесту підграфів
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Визначення Grafting Manifest
+
+Графтинг вимагає додавання двох нових елементів до оригінального маніфесту підграфів:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Розгортання базового підграфа
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Закінчивши, перевірте, чи правильно індексується підграф. Ви можете зробити це запустивши наступну команду у вікні The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Це повертає щось на зразок цього:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Після того, як ви переконалися, що підграф індексується належним чином, ви можете швидко оновити його за допомогою графтингу.
+
+## Розгортання підграфів для графтингу
+
+При цьому процесі підрозділ subgraph.yaml матиме нову адресу контракту. Це може статися, коли ви оновлюєте децентралізований додаток, перерозподіляєте контракт тощо.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Закінчивши, перевірте, чи правильно індексується підграф. Ви можете зробити це запустивши наступну команду у вікні The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+Це має повернути наступне:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Додаткові матеріали
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From b8e8c9eec53e4bb96e3c73cc5c57e099c10c2367 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:11:59 -0500
Subject: [PATCH 1544/3820] New translations grafting.mdx (Chinese Simplified)

---
 .../pages/zh/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/grafting.mdx b/website/pages/zh/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..ac570d8c20d5
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: 用嫁接替换合约并保持合约的历史
+---
+
+在本指南中，您将学习如何通过嫁接现有的子图来构建和部署新的子图。
+
+## 什么是嫁接？
+
+嫁接重用现有子图中的数据，并开始在稍后的区块中对其进行索引。这在开发过程中非常有用，可以快速克服映射中的简单错误，或者在现有子图失败后暂时使其重新工作。此外，当向子图添加特性时可以使用它，因为从头开始索引需要很长时间。
+
+嫁接子图可以使用一个 GraphQL 模式 schema，该模式与基子图之一不同，但仅与基子图兼容。它本身必须是一个有效的子图模式，但是可以通过以下方式偏离基子图的模式：
+
+- 它添加或删除实体类型
+- 它从实体类型中删除属性
+- 它将可为空的属性添加到实体类型
+- 它将不可为空的属性转换为可空的属性
+- 它将值添加到枚举类型中
+- 它添加或删除接口
+- 它改变了实现接口的实体类型
+
+有关详情，请参阅:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## 构建现有子图
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## 子图清单定义
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## 嫁接清单定义
+
+嫁接需要在原始子图清单中添加两个新项:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## 部署基子图
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. 完成后，验证子图是否正确索引。如果在Graph Playground中运行下列指令。
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+它返回的结果是这样的:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+一旦您验证了子图是正确的索引，您可以快速更新子图与嫁接。
+
+## 部署嫁接子图
+
+嫁接替代Subgraph.yaml将获得一个新的合约地址。这可能发生在更新dapp、重新部署合约等时。
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. 完成后，验证子图是否正确索引。如果在Graph Playground中运行下列指令。
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+它返回的结果是这样的:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## 其他资源
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 52a7f9fe96c34aa12cab5de532b14d6b95463700 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:00 -0500
Subject: [PATCH 1545/3820] New translations grafting.mdx (Urdu (Pakistan))

---
 .../pages/ur/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/grafting.mdx b/website/pages/ur/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..6cda9bfe1f6e
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: ایک کنٹریکٹ کو تبدیل کریں اور اس کی تاریخ کو گرافٹنگ کے ساتھ رکھیں
+---
+
+اس گائیڈ میں، آپ سیکھیں گے کہ موجودہ سب گراف کو گرافٹنگ کرکے نئے سب گراف کیسے بنائے اور ان کو تعینات کریں.
+
+## گرافٹنگ کیا ہے؟
+
+گرافٹنگ موجودہ سب گراف سے ڈیٹا کو دوبارہ استعمال کرتا ہے اور اسے بعد کے بلاک میں انڈیکس کرنا شروع کرتا ہے۔ میپنگ میں ماضی کی سادہ غلطیوں کو تیزی سے حاصل کرنے یا کسی موجودہ سب گراف کے ناکام ہونے کے بعد اسے عارضی طور پر دوبارہ کام کرنے کے لیے یہ ترقی کے دوران مفید ہے۔ نیز، اس کا استعمال کسی سب گراف میں فیچر شامل کرتے وقت کیا جا سکتا ہے جو شروع سے انڈیکس میں زیادہ وقت لیتا ہے.
+
+گرافٹڈ سب گراف ایک گراف کیو ایل اسکیما استعمال کرسکتا ہے جو بیس سب گراف میں سے ایک سے مماثل نہیں ہے، لیکن اس کے ساتھ محض مطابقت رکھتا ہے۔ اسے اپنے طور پر ایک درست سب گراف سکیما ہونا چاہیے، لیکن درج ذیل طریقوں سے بنیادی سب گراف کے سکیما سے انحراف ہو سکتا ہے:
+
+- یہ ہستی کی اقسام کو جوڑتا یا ہٹاتا ہے
+- یہ ہستی کی اقسام سے صفات کو ہٹاتا ہے
+- یہ ہستی کی قسموں میں کالعدم صفات کو شامل کرتا ہے
+- یہ غیر کالعدم صفات کو کالعدم صفات میں بدل دیتا ہے
+- یہ enums میں اقدار کا اضافہ کرتا ہے
+- یہ انٹرفیس کو جوڑتا یا ہٹاتا ہے
+- یہ تبدیل ہوتا ہے جس کے لیے ایک انٹرفیس لاگو کیا جاتا ہے
+
+مزید معلومات کے لۓ، آپ دیکہ سکتے ہیں:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## نیٹ ورک میں اپ گریڈ کرتے وقت گرافٹنگ پر اہم نوٹ
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### یہ کیوں اہم ہے؟
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### بہترین طریقے
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+ان رہنما خطوط پر عمل پیرا ہو کر، آپ خطرات کو کم کرتے ہیں اور منتقلی کے ایک ہموار عمل کو یقینی بناتے ہیں.
+
+## ایک موجودہ سب گراف بنانا
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## سب گراف مینی فیسٹ کی تعریف
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## گرافٹنگ مینی فیسٹ کی تعریف
+
+گرافٹنگ کے لیے اصل سب گراف مینی فیسٹ میں دو نئے آئٹمز شامل کرنے کی ضرورت ہے:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## بیس سب گراف تعینات کرنا
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. ایک دفعہ ختم ہو جاۓ، تصدیق کریں کے سب گراف صحیح سے انڈیکس ہو رہا ہے. اگر آپ درج کمانڈ گراف پلے گراونڈ میں چلائیں
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+یہ کچھ اس طرح لوٹاتا ہے:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+ایک بار آپ نے تصدیق کر لی کے سب گراف صحیح سے انڈیکس ہو رہا، آپ جلدی سے گرافٹنگ سے اسے اپڈیٹ کر سکتے ہیں.
+
+## گرافٹنگ سب گراف کو تعینات کرنا
+
+گرافٹ متبادل subgraph.yaml کے پاس ایک نیا کنٹریکٹ ایڈریس ہوگا۔ یہ اس وقت ہو سکتا ہے جب آپ اپنے ڈیپ کو اپ ڈیٹ کرتے ہیں، کسی کنٹریکٹ کو دوبارہ استعمال کرتے ہیں، وغیر.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. ایک دفعہ ختم ہو جاۓ، تصدیق کریں کے سب گراف صحیح سے انڈیکس ہو رہا ہے. اگر آپ درج کمانڈ گراف پلے گراونڈ میں چلائیں
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+اسے مندرجہ ذیل کو واپس کرنا چاہئے:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## اضافی وسائل
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 00cc7d25f93ec0cf2e7f515e60ec9fbddb0aa368 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:01 -0500
Subject: [PATCH 1546/3820] New translations grafting.mdx (Vietnamese)

---
 .../pages/vi/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/grafting.mdx b/website/pages/vi/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..2d9b2a16a1ef
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Replace a Contract and Keep its History With Grafting
+---
+
+In this guide, you will learn how to build and deploy new subgraphs by grafting existing subgraphs.
+
+## What is Grafting?
+
+Grafting reuses the data from an existing subgraph and starts indexing it at a later block. This is useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. Also, it can be used when adding a feature to a subgraph that takes long to index from scratch.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- Nó thay đổi đối với loại thực thể nào mà một giao diện được triển khai
+
+For more information, you can check:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## Building an Existing Subgraph
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Grafting Manifest Definition
+
+Grafting requires adding two new items to the original subgraph manifest:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Deploying the Base Subgraph
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It returns something like this:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Once you have verified the subgraph is indexing properly, you can quickly update the subgraph with grafting.
+
+## Deploying the Grafting Subgraph
+
+The graft replacement subgraph.yaml will have a new contract address. This could happen when you update your dapp, redeploy a contract, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It should return the following:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Additional Resources
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 3cf45f6b40f16d4c15da6b3cb4a9536a6e9064ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:02 -0500
Subject: [PATCH 1547/3820] New translations grafting.mdx (Marathi)

---
 .../pages/mr/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/grafting.mdx b/website/pages/mr/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..3ceb7d2c7901
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: करार बदला आणि त्याचा इतिहास ग्राफ्टिंगसह ठेवा
+---
+
+या मार्गदर्शकामध्ये, तुम्ही विद्यमान सबग्राफ्सचे ग्राफ्टिंग करून नवीन सबग्राफ कसे तयार करावे आणि कसे तैनात करावे ते शिकाल.
+
+## ग्राफ्टिंग म्हणजे काय?
+
+ग्राफ्टिंग विद्यमान सबग्राफमधील डेटा पुन्हा वापरते आणि नंतरच्या ब्लॉकमध्ये अनुक्रमित करणे सुरू करते. मॅपिंगमध्ये भूतकाळातील साध्या चुका लवकर मिळवण्यासाठी किंवा विद्यमान सबग्राफ अयशस्वी झाल्यानंतर तात्पुरते काम करण्यासाठी हे विकासादरम्यान उपयुक्त आहे. तसेच, स्क्रॅचपासून इंडेक्स होण्यास बराच वेळ घेणार्‍या सबग्राफमध्ये वैशिष्ट्य जोडताना ते वापरले जाऊ शकते.
+
+ग्राफ्टेड सबग्राफ GraphQL स्कीमा वापरू शकतो जो बेस सबग्राफपैकी एकाशी एकसारखा नसतो, परंतु त्याच्याशी फक्त सुसंगत असतो. ती स्वतःच्या अधिकारात वैध सबग्राफ स्कीमा असणे आवश्यक आहे, परंतु खालील प्रकारे बेस सबग्राफच्या स्कीमापासून विचलित होऊ शकते:
+
+- हे घटक प्रकार जोडते किंवा काढून टाकते
+- हे घटक प्रकारातील गुणधर्म काढून टाकते
+- हे अस्तित्व प्रकारांमध्ये रद्द करण्यायोग्य विशेषता जोडते
+- हे नॉन-नलेबल अॅट्रिब्यूट्सना न्युलेबल अॅट्रिब्यूट्समध्ये बदलते
+- हे enums मध्ये मूल्ये जोडते
+- हे इंटरफेस जोडते किंवा काढून टाकते
+- कोणत्या घटकासाठी इंटरफेस लागू केला जातो ते बदलते
+
+अधिक माहितीसाठी, तुम्ही तपासू शकता:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## विद्यमान सबग्राफ तयार करणे
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## सबग्राफ मॅनिफेस्ट व्याख्या
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Grafting मॅनिफेस्ट व्याख्या
+
+ग्राफ्टिंगसाठी मूळ सबग्राफ मॅनिफेस्टमध्ये दोन नवीन आयटम जोडणे आवश्यक आहे:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## बेस सबग्राफ तैनात करणे
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. एकदा पूर्ण झाल्यावर, सबग्राफ योग्यरित्या अनुक्रमित होत असल्याचे सत्यापित करा. जर तुम्ही ग्राफ प्लेग्राउंडमध्ये खालील आदेश चालवलात
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+हे असे काहीतरी परत करते:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+एकदा तुम्ही सबग्राफ व्यवस्थित इंडेक्स करत असल्याची पडताळणी केल्यानंतर, तुम्ही ग्राफ्टिंगसह सबग्राफ त्वरीत अपडेट करू शकता.
+
+## ग्राफ्टिंग सबग्राफ तैनात करणे
+
+कलम बदली subgraph.yaml मध्ये नवीन करार पत्ता असेल. जेव्हा तुम्ही तुमचा dapp अपडेट करता, करार पुन्हा लागू करता तेव्हा असे होऊ शकते.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. एकदा पूर्ण झाल्यावर, सबग्राफ योग्यरित्या अनुक्रमित होत असल्याचे सत्यापित करा. जर तुम्ही ग्राफ प्लेग्राउंडमध्ये खालील आदेश चालवलात
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It should return the following:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## अतिरिक्त संसाधने
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 6eb9e80e41bfa2c5a505c62c2435909f5b8a8173 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:03 -0500
Subject: [PATCH 1548/3820] New translations grafting.mdx (Hindi)

---
 .../pages/hi/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/grafting.mdx b/website/pages/hi/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..c0703bcfb101
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: एक कॉन्ट्रैक्ट बदलें और उसका इतिहास ग्राफ्टिंग के साथ रखें
+---
+
+इस गाइड में, आप सीखेंगे कि मौजूदा सबग्राफ को ग्राफ्ट करके नए सबग्राफ कैसे बनाएं और तैनात करें।
+
+## ग्राफ्टिंग क्या है?
+
+ग्राफ्टिंग एक वर्तमान सब-ग्राफ के डाटा का दोबारा इस्तेमाल करता है और उसे बाद के ब्लॉक्स में इंडेक्स करना चालू कर देता है| यह विकास की प्रक्रिया में उपयोगी है क्यूंकि इसकी वजह से मैप्पिंग्स में छोटी-मोटी त्रुटियों से छुटकारा पाया जा सकता है या फिर एक मौजूदा सब-ग्राफ को विफल होने के बाद दोबारा चालू किया जा सकता है| साथ हीं, इसका इस्तेमाल ऐसे सब-ग्राफ में कोई खूबी जोड़ते वक़्त भी किया जा सकता है जिसमे शुरुआत से इंडेक्स करने में काफी लम्बा वक़्त लगता हो|
+
+ग्राफ्टेड सबग्राफ एक ग्राफक्यूएल स्कीमा का उपयोग कर सकता है जो बेस सबग्राफ के समान नहीं है, लेकिन इसके अनुकूल हो। यह अपने आप में एक मान्य सबग्राफ स्कीमा होना चाहिए, लेकिन निम्नलिखित तरीकों से बेस सबग्राफ के स्कीमा से विचलित हो सकता है:
+
+- यह इकाई के प्रकारों को जोड़ या हटा सकता है|
+- यह इकाई प्रकारों में से गुणों को हटाता है|
+- यह प्रभावहीन गुणों को इकाई प्रकारों में जोड़ता है|
+- यह प्रभाव वाले गुणों को प्रभावहीन गुणों में बदल देता है|
+- यह इनम्स में महत्व देता है|
+- यह इंटरफेस जोड़ता या हटाता है|
+- यह कि, किन इकाई प्रकारों के लिए इंटरफ़ेस लागू होगा, इसे बदल देता है|
+
+अधिक जानकारी के लिए आप देख सकते हैं:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+इस ट्यूटोरियल में, हम एक बुनियादी उपयोग मामले को कवर करेंगे। हम एक मौजूदा कॉन्ट्रैक्ट को एक समान कॉन्ट्रैक्ट (नए पते के साथ, लेकिन वही कोड) से बदलेंगे। फिर, मौजूदा Subgraph को "बेस" Subgraph पर जोड़ेंगे, जो नए कॉन्ट्रैक्ट को ट्रैक करता है।
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting एक शक्तिशाली विशेषता है जो आपको एक सबग्राफ़ को दूसरे पर "graft" करने की अनुमति देती है, जिससे मौजूदा सबग्राफ़ से नए संस्करण में ऐतिहासिक डेटा को प्रभावी ढंग से स्थानांतरित किया जा सके।The Graph Network से सबग्राफ़ को Subgraph Studioमें वापस graft करना संभव नहीं है।
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## एक मौजूदा सब-ग्राफ बनाना
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## सब ग्राफ मैनिफेस्ट की परिभाषा
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## ग्राफ्टिंग मैनिफेस्ट की परिभाषा
+
+ग्राफ्टिंग करने के लिए मूल सब-ग्राफ मैनिफेस्ट में 2 नई चीज़ें जोड़ने की आवश्यकता है:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## बेस सब-ग्राफ को तैनात करना
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. एक बार पूरा होने पर, सत्यापित करें की इंडेक्सिंग सही ढंग से हो गयी है| यदि आप निम्न कमांड ग्राफ प्लेग्राउंड में चलाते हैं
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+तो हमे कुछ ऐसा दिखता है:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+एक बार आपका सत्यापित सब-ग्राफ ढंग से इंडेक्स हो जाता है तो आप बिना किसी देरी के अपना सब-ग्राफ को ग्राफ्टिंग से अपडेट कर सकते हैं|
+
+## ग्राफ्टिंग सब-ग्राफ तैनात करना
+
+ग्राफ्ट प्रतिस्तापित subgraph.yaml में एक नया कॉन्ट्रैक्ट एड्रेस होगा| यह तब हो सकता है जब आप अपना डैप अपडेट करें, कॉन्ट्रैक्ट को दोबारा तैनात करें, इत्यादि|
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. एक बार पूरा होने पर, सत्यापित करें की इंडेक्सिंग सही ढंग से हो गयी है| यदि आप निम्न कमांड ग्राफ प्लेग्राउंड में चलाते हैं
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+आपको यह वापस मिलना चाहिए:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Additional Resources
+
+यदि आप grafting के साथ अधिक अनुभव प्राप्त करना चाहते हैं, तो यहां कुछ लोकप्रिय कॉन्ट्रैक्ट्स के उदाहरण दिए गए हैं:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 4275add7dbe2ef0ed964af7fc80d6e4b4cc17cae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:05 -0500
Subject: [PATCH 1549/3820] New translations grafting.mdx (Swahili)

---
 .../pages/sw/subgraphs/cookbook/grafting.mdx  | 202 ++++++++++++++++++
 1 file changed, 202 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/grafting.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/grafting.mdx b/website/pages/sw/subgraphs/cookbook/grafting.mdx
new file mode 100644
index 000000000000..57d5169830a7
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/grafting.mdx
@@ -0,0 +1,202 @@
+---
+title: Replace a Contract and Keep its History With Grafting
+---
+
+In this guide, you will learn how to build and deploy new subgraphs by grafting existing subgraphs.
+
+## What is Grafting?
+
+Grafting reuses the data from an existing subgraph and starts indexing it at a later block. This is useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed. Also, it can be used when adding a feature to a subgraph that takes long to index from scratch.
+
+The grafted subgraph can use a GraphQL schema that is not identical to the one of the base subgraph, but merely compatible with it. It has to be a valid subgraph schema in its own right, but may deviate from the base subgraph's schema in the following ways:
+
+- It adds or removes entity types
+- It removes attributes from entity types
+- It adds nullable attributes to entity types
+- It turns non-nullable attributes into nullable attributes
+- It adds values to enums
+- It adds or removes interfaces
+- It changes for which entity types an interface is implemented
+
+For more information, you can check:
+
+- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+
+In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+
+## Important Note on Grafting When Upgrading to the Network
+
+> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+
+### Why Is This Important?
+
+Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+
+### Best Practices
+
+**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+
+**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+
+By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
+
+## Building an Existing Subgraph
+
+Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+
+- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+
+> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+
+## Subgraph Manifest Definition
+
+The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+
+```yaml
+specVersion: 0.0.4
+schema:
+  file: ./schema.graphql
+dataSources:
+  - kind: ethereum
+    name: Lock
+    network: sepolia
+    source:
+      address: '0xb3aabe721794b85fe4e72134795c2f93b4eb7e63'
+      abi: Lock
+      startBlock: 5955690
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Withdrawal
+      abis:
+        - name: Lock
+          file: ./abis/Lock.json
+      eventHandlers:
+        - event: Withdrawal(uint256,uint256)
+          handler: handleWithdrawal
+      file: ./src/lock.ts
+```
+
+- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
+- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
+- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+
+## Grafting Manifest Definition
+
+Grafting requires adding two new items to the original subgraph manifest:
+
+```yaml
+---
+features:
+  - grafting # feature name
+graft:
+  base: Qm... # subgraph ID of base subgraph
+  block: 5956000 # block number
+```
+
+- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+
+The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+
+## Deploying the Base Subgraph
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
+2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+3. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It returns something like this:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      }
+    ]
+  }
+}
+```
+
+Once you have verified the subgraph is indexing properly, you can quickly update the subgraph with grafting.
+
+## Deploying the Grafting Subgraph
+
+The graft replacement subgraph.yaml will have a new contract address. This could happen when you update your dapp, redeploy a contract, etc.
+
+1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+4. Once finished, verify the subgraph is indexing properly. If you run the following command in The Graph Playground
+
+```graphql
+{
+  withdrawals(first: 5) {
+    id
+    amount
+    when
+  }
+}
+```
+
+It should return the following:
+
+```
+{
+  "data": {
+    "withdrawals": [
+      {
+        "id": "0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d0a000000",
+        "amount": "0",
+        "when": "1716394824"
+      },
+      {
+        "id": "0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc45203000000",
+        "amount": "0",
+        "when": "1716394848"
+      },
+      {
+        "id": "0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af06000000",
+        "amount": "0",
+        "when": "1716429732"
+      }
+    ]
+  }
+}
+```
+
+You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+
+Congrats! You have successfully grafted a subgraph onto another subgraph.
+
+## Additional Resources
+
+If you want more experience with grafting, here are a few examples for popular contracts:
+
+- [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
+- [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
+- [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
+
+To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+
+> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)

From 67ea295c2a37190ac03aef0e30f33bbdc4ee16f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:06 -0500
Subject: [PATCH 1550/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Romanian)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ro/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 747df26f9cad496534ae5873af9c1679729015bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:07 -0500
Subject: [PATCH 1551/3820] New translations
 immutable-entities-bytes-as-ids.mdx (French)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/fr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..0f6be0be5afe
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### Quand ne pas utiliser les Entités Immuables
+
+Si vous avez un champ comme `status` qui doit être modifié au fil du temps, alors vous ne devriez pas rendre l'entité immuable. Autrement, vous devriez utiliser des entités immuables dès que possible.
+
+## Bytes comme IDs
+
+Chaque entité nécessite un ID. Dans l'exemple précédent, nous pouvons voir que l'ID est déjà du type Bytes.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+Bien que d'autres types d'ID soient possibles, tels que String et Int8, il est recommandé d'utiliser le type Bytes pour tous les IDs en raison des chaînes de caractères prenant deux fois plus d'espace que les chaînes Byte pour stocker des données binaires, et les comparaisons de chaînes de caractères UTF-8 doivent tenir compte de la locale, ce qui est beaucoup plus coûteux que la comparaison binaire utilisée pour comparer les chaînes de caractères Byte.
+
+### Raisons de ne pas utiliser les Bytes comme IDs
+
+1. Si les IDs d'entité doivent être lisibles par les humains, comme les IDs numériques auto-incrémentés ou les chaînes lisibles, les Bytes pour les IDs ne doivent pas être utilisés.
+2. Si nous intégrons des données d'un subgraph avec un autre modèle de données qui n'utilise pas les Bytes comme IDs, les Bytes comme IDs ne doivent pas être utilisés.
+3. Les améliorations de performances d'indexation et de recherche ne sont pas souhaitées.
+
+### Concatenation Avec Bytes comme IDs
+
+Il est courant dans de nombreux subgraphs d'utiliser la concaténation de chaînes de caractères pour combiner deux propriétés d'un événement en un seul ID, comme utiliser `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`.. Cependant, comme cela retourne une chaîne de caractères, cela nuit considérablement à la performance d'indexation et de recherche des subgraphs.
+
+Au lieu de cela, nous devrions utiliser la méthode `concatI32()` pour concaténer les propriétés des événements. Cette stratégie donne un ID de type Bytes beaucoup plus performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Tri avec Bytes comme IDs
+
+Le tri utilisant les Bytes comme IDs n'est pas optimal, comme le montre cet exemple de requête et de réponse.
+
+Requête:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Réponse de la requête:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+Les IDs sont renvoyés sous forme hexadécimale.
+
+Pour améliorer le tri, nous devrions créer un autre champ sur l'entité qui est un BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+Ceci permettra d'optimiser le tri de manière séquentielle.
+
+Requête:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Réponse de la requête:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+L'utilisation à la fois d' Entités immuables et de Bytes en tant qu'IDs a montré une amélioration marquée de l'efficacité des subgraphs. Plus précisément, des tests ont mis en évidence une augmentation de 28% des performances des requêtes et une accélération de 48% des vitesses d'indexation.
+
+En savoir plus sur l'utilisation des Entités immuables et des Bytes en tant qu'IDs dans cet article de blog de David Lutterkort, un ingénieur logiciel chez Edge & Node : [Deux améliorations simples des performances des subgraphs](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From f399fc0c7e3d7566569e9a0341a5e5fafed3907c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:08 -0500
Subject: [PATCH 1552/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Spanish)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/es/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/es/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 87fed49b184f35378c3c81229bf8585be7ac0c7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:09 -0500
Subject: [PATCH 1553/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Arabic)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ar/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 61c70114939ccb4b914d858af8dd9603d0f83acf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:10 -0500
Subject: [PATCH 1554/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Czech)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/cs/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..2a6c8035ee74
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Osvědčený postup 3 - Zlepšení indexování a výkonu dotazů pomocí neměnných entit a bytů jako ID
+---
+
+## TLDR
+
+Použití neměnných entit a bytů pro ID v našem souboru `schema.graphql` [výrazně zlepšuje ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) rychlost indexování a výkonnost dotazů.
+
+## Nezměnitelné entity
+
+Aby byla entita neměnná, jednoduše k ní přidáme `(immutable: true)`.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+Tím, že je entita `Transfer` neměnná, je grafový uzel schopen ji zpracovávat efektivněji, což zvyšuje rychlost indexování a odezvu dotazů.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Pod kapotou
+
+Mutabilní entity mají "rozsah bloku", který udává jejich platnost. Aktualizace těchto entit vyžaduje, aby uzel grafu upravil rozsah bloků předchozích verzí, což zvyšuje zatížení databáze. Dotazy je také třeba filtrovat, aby byly nalezeny pouze živé entity. Neměnné entity jsou rychlejší, protože jsou všechny živé, a protože se nebudou měnit, nejsou při zápisu nutné žádné kontroly ani aktualizace a při dotazech není nutné žádné filtrování.
+
+### Kdy nepoužívat nezměnitelné entity
+
+Pokud máte pole, jako je `status`, které je třeba v průběhu času měnit, neměli byste entitu učinit neměnnou. Jinak byste měli používat neměnné entity, kdykoli je to možné.
+
+## Bajty jako IDs
+
+Každá entita vyžaduje ID. V předchozím příkladu vidíme, že ID je již typu Bytes.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+I když jsou možné i jiné typy ID, například String a Int8, doporučuje se pro všechna ID používat typ Bytes, protože pro uložení binárních dat zabírají znakové řetězce dvakrát více místa než řetězce Byte a při porovnávání znakových řetězců UTF-8 se musí brát v úvahu locale, což je mnohem dražší než bytewise porovnávání používané pro porovnávání řetězců Byte.
+
+### Důvody, proč nepoužívat bajty jako IDs
+
+1. Pokud musí být IDs entit čitelné pro člověka, například automaticky doplňované číselné IDs nebo čitelné řetězce, neměly by být použity bajty pro IDs.
+2. Při integraci dat podgrafu s jiným datovým modelem, který nepoužívá bajty jako IDs, by se bajty jako IDs neměly používat.
+3. Zlepšení výkonu indexování a dotazování není žádoucí.
+
+### Konkatenace s byty jako IDs
+
+V mnoha podgrafech se běžně používá spojování řetězců ke spojení dvou vlastností události do jediného ID, například pomocí `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. Protože se však tímto způsobem vrací řetězec, značně to zhoršuje indexování podgrafů a výkonnost dotazování.
+
+Místo toho bychom měli použít metodu `concatI32()` pro spojování vlastností událostí. Výsledkem této strategie je ID `Bytes`, které je mnohem výkonnější.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Třídění s bajty jako ID
+
+Třídění pomocí bajtů jako IDs není optimální, jak je vidět v tomto příkladu dotazu a odpovědi.
+
+Dotaz:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Odpověď na dotaz:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+ID jsou vrácena v hex.
+
+Abychom zlepšili třídění, měli bychom v entitě vytvořit další pole, které bude BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+To umožní postupnou optimalizaci třídění.
+
+Dotaz:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Odpověď na dotaz:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Závěr
+
+Bylo prokázáno, že použití neměnných entit i bytů jako ID výrazně zvyšuje efektivitu podgrafů. Testy konkrétně ukázaly až 28% nárůst výkonu dotazů a až 48% zrychlení indexace.
+
+Více informací o používání nezměnitelných entit a bytů jako ID najdete v tomto příspěvku na blogu Davida Lutterkorta, softwarového inženýra ve společnosti Edge & Node: [Dvě jednoduchá vylepšení výkonu podgrafu](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 4ee947d4690a820574e1cd17341422822faabeb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:11 -0500
Subject: [PATCH 1555/3820] New translations
 immutable-entities-bytes-as-ids.mdx (German)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/de/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/de/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 18457155b3692e7e2c0aef8bdda5845bb49cbaa9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:12 -0500
Subject: [PATCH 1556/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Italian)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/it/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/it/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 79741b74c54e26c46fce4e47cc2a6c01a4827feb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:13 -0500
Subject: [PATCH 1557/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Japanese)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ja/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 2810a0441db2daaad325f1406c3b701306784d34 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:14 -0500
Subject: [PATCH 1558/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Korean)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ko/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 4b9145e36e645bf65b73863b552473493d75254a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:16 -0500
Subject: [PATCH 1559/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Dutch)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/nl/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From b5f4d7a16654c1962e24fe96c3006fc2dafddbc0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:17 -0500
Subject: [PATCH 1560/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Polish)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/pl/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 4ef51e011814f9ef904f503f78db0f7a1f9c1def Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:17 -0500
Subject: [PATCH 1561/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Portuguese)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/pt/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..ab5b757ccd84
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Boas Práticas de Subgraph 3 - Como Melhorar o Desempenho da Indexação e de Queries com Entidades Imutáveis e Bytes como IDs
+---
+
+## TLDR
+
+Usar Entidades Imutáveis e Bytes como IDs no nosso arquivo `schema.graphql` [acelera muito](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) a indexação e o desempenho das queries.
+
+## Entidades Imutáveis
+
+Para fazer uma entidade imutável, basta adicionar `(immutable: true)` a uma entidade.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+Ao tornar a entidade `Transfer` imutável, o graph-node pode processá-la com mais eficácia, o que melhora as velocidades de indexação e a capacidade de resposta das queries.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### De dentro da casca
+
+Entidades mutáveis tem um `block range` (alcance de bloco) que indica a sua validade. Atualizar estas entidades exige que o graph-node ajuste o alcance de bloco de versões anteriores, o que aumenta a carga de trabalho do banco de dados. Queries também precisam de filtragem para encontrar apenas entidades vivas. Entidades imutáveis são mais rápidas por serem todas vivas, e como não mudam, nenhuma verificação ou atualização é necessária durante a escrita, e nenhuma filtragem é necessária durante queries.
+
+### Quando não usar Entidades Imutáveis
+
+Se tiver um campo como `status` que precise ser gradualmente modificado, então esta entidade não deve ser imutável. Fora isto, é recomendado usar entidades imutáveis sempre que possível.
+
+## Bytes como IDs
+
+Toda entidade requer uma ID. No exemplo anterior, vemos que a ID já é do tipo Bytes.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+Enquanto outros tipos de IDs são possíveis, como String e Int8, recomendamos usar o tipo Bytes para todas as IDs porque strings de caracteres ocupam o dobro do espaço ocupado por strings de Byte para armazenar dados, e comparações de strings de caracteres em UTF-8 devem levar em conta o local, que é muito mais caro que a comparação em byte usada para comparar strings em Byte.
+
+### Razões para Não Usar Bytes como IDs
+
+1. Se IDs de entidade devem ser legíveis para humanos, como IDs numéricas automaticamente incrementadas ou strings legíveis, então Bytes como IDs não devem ser usados.
+2. Em caso de integração dos dados de um subgraph com outro modelo de dados que não usa Bytes como IDs, então Bytes como IDs não devem ser usados.
+3. Melhorias no desempenho de indexação e queries não são desejáveis.
+
+### Concatenação com Bytes como IDs
+
+É comum em vários subgraphs usar a concatenação de strings para combinar duas propriedades de um evento em uma ID única, como o uso de `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. Mas como isto retorna um string, isto impede muito o desempenho da indexação e queries de subgraphs.
+
+Em vez disto, devemos usar o método `concatI32()` para concatenar propriedades de evento. Esta estratégia resulta numa ID `Bytes` que tem um desempenho muito melhor.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Organização com Bytes como IDs
+
+A organização com Bytes como IDs não é o melhor recurso, como visto neste exemplo de query e resposta.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Resposta de query:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+As IDs são retornadas como hex.
+
+Para melhorar a organização, devemos criar outro campo na entidade que seja um BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+Isto otimizará sequencialmente a organização.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Resposta de query:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusão
+
+É comprovado que usar Entidades Imutáveis e Bytes como IDs aumenta muito a eficiência de subgraphs. Especificamente, segundo testes, houve um aumento de até 28% no desempenho de queries e uma aceleração de até 48% em velocidades de indexação.
+
+Leia mais sobre o uso de Entidades Imutáveis e Bytes como IDs nesta publicação por David Lutterkort, Engenheiro de Software na Edge & Node: [Duas Melhorias Simples no Desempenho de Subgraphs](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 9c55f8b96dd035a8a00d6e66d247003e5dea9334 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:19 -0500
Subject: [PATCH 1562/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Russian)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..ebe5e47b36e9
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## Краткое содержание
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Заключение
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 6504472b022850062951c6f896c91efa8ee493c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:20 -0500
Subject: [PATCH 1563/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Swedish)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/sv/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From b0c4936e2e99e03755193d0446d557698aca001a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:21 -0500
Subject: [PATCH 1564/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Turkish)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 67bf0ae7c90d8c4191ade823f5a8e288019e9312 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:22 -0500
Subject: [PATCH 1565/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Ukrainian)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/uk/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 8f435203a5b87255259f30d232a16719ca05ad25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:23 -0500
Subject: [PATCH 1566/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Chinese Simplified)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/zh/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From c61cd762ab353cad582df303fee75f474dde78af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:24 -0500
Subject: [PATCH 1567/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Urdu (Pakistan))

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ur/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 27d485f6d0985645e6b26700dea305fb7205814f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:25 -0500
Subject: [PATCH 1568/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Vietnamese)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/vi/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 98c46bb264bf3b6cee4aa7d8ad84fde31a735236 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:26 -0500
Subject: [PATCH 1569/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Marathi)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/mr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 4dfd34ca6a340575dd30bc476f09d30d3cad9031 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:27 -0500
Subject: [PATCH 1570/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Hindi)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/hi/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..54e8b9e68a8c
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: सबग्राफ सर्वश्रेष्ठ प्रथा 3 - अपरिवर्तनीय संस्थाओं और बाइट्स को आईडी के रूप में उपयोग करके अनुक्रमण और क्वेरी प्रदर्शन में सुधार करें।
+---
+
+## TLDR
+
+हमारे schema.graphql फ़ाइल में अमूर्त एंटिटीज और आईडी के लिए बाइट्स का उपयोग सूचक गति और क्वेरी प्रदर्शन में [महत्वपूर्ण सुधार](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) करता है।
+
+## अमूर्त एंटिटीज
+
+एक एंटिटी को अमूर्त बनाने के लिए, हम बस एंटिटी में (immutable: true) जोड़ते हैं।
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+Transfer एंटिटी को अमूर्त बनाने से, graph-node एंटिटी को अधिक कुशलता से संसाधित कर सकता है, जिससे indexing गति और क्वेरी की प्रतिक्रिया में सुधार होता है।
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### हुड के नीचे
+
+परिवर्तनीय एंटिटियों में एक ‘ब्लॉक रेंज’ होती है जो उनकी वैधता को इंगित करती है। इन एंटिटियों को अपडेट करने के लिए ग्राफ नोड को पिछले संस्करणों की ब्लॉक रेंज को समायोजित करना पड़ता है, जिससे डेटाबेस का कार्यभार बढ़ जाता है। क्वेरियों को भी केवल जीवित एंटिटियों को खोजने के लिए फ़िल्टर करने की आवश्यकता होती है। अमूर्त एंटिटियाँ तेज होती हैं क्योंकि ये सभी जीवित होती हैं और चूंकि ये नहीं बदलेंगी, लिखते समय किसी भी चेक या अपडेट की आवश्यकता नहीं होती, और क्वेरियों के दौरान कोई फ़िल्टरिंग की आवश्यकता नहीं होती।
+
+### अमूर्त एंटिटीज का उपयोग कब न करें
+
+अगर आपके पास एक ऐसा फ़ील्ड है जैसे status जिसे समय के साथ संशोधित करने की आवश्यकता है, तो आपको एंटिटी को अमूर्त नहीं बनाना चाहिए। अन्यथा, आपको जब भी संभव हो, अमूर्त एंटिटीज का उपयोग करना चाहिए।
+
+## Bytes को IDs के रूप में
+
+हर एंटिटी के लिए एक ID की आवश्यकता होती है। पिछले उदाहरण में, हम देख सकते हैं कि ID पहले से ही Bytes प्रकार की है।
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+हालांकि IDs के लिए अन्य प्रकार संभव हैं, जैसे String और Int8, लेकिन सभी IDs के लिए Bytes प्रकार का उपयोग करने की सिफारिश की जाती है क्योंकि चरित्र स्ट्रिंग्स को बाइनरी डेटा संग्रहीत करने के लिए बाइट स्ट्रिंग्स की तुलना में दोगुना स्थान चाहिए, और UTF-8 चरित्र स्ट्रिंग्स की तुलना करते समय स्थानीय भाषा का ध्यान रखना आवश्यक है, जो बाइट स्ट्रिंग्स की तुलना के लिए उपयोग की जाने वाली बाइटवाइज तुलना की तुलना में बहुत अधिक महंगा है।
+
+### IDs के रूप में Bytes का उपयोग न करने के कारण
+
+1. यदि एंटिटी IDs मानव-पठनीय होने चाहिए, जैसे कि ऑटो-इंक्रीमेंटेड न्यूमेरिकल IDs या पठनीय स्ट्रिंग्स, तो IDs के लिए Bytes का उपयोग नहीं किया जाना चाहिए।
+2. यदि किसी subgraph के डेटा को दूसरे डेटा मॉडल के साथ एकीकृत किया जा रहा है जो IDs के रूप में Bytes का उपयोग नहीं करता है, तो Bytes के रूप में IDs का उपयोग नहीं किया जाना चाहिए।
+3. Indexing और क्वेरीिंग प्रदर्शन में सुधार की आवश्यकता नहीं है।
+
+### Bytes के रूप में IDs के साथ जोड़ना
+
+बहुत से subgraphs में एक ID में दो प्रॉपर्टीज को जोड़ने के लिए स्ट्रिंग संयोजन का उपयोग करना एक सामान्य प्रथा है, जैसे कि event.transaction.hash.toHex() + "-" + event.logIndex.toString() का उपयोग करना। हालांकि, चूंकि यह एक स्ट्रिंग लौटाता है, यह subgraph इंडेक्सिंग और क्वेरी प्रदर्शन में महत्वपूर्ण रूप से बाधा डालता है।
+
+इसके बजाय, हमें event properties को जोड़ने के लिए concatI32() method का उपयोग करना चाहिए। यह रणनीति एक Bytes ID उत्पन्न करती है जो बहुत अधिक performant होती है।
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Bytes के रूप में IDs के साथ क्रमबद्ध करना
+
+Bytes को IDs के रूप में उपयोग करके क्रमबद्ध करना इस उदाहरण क्वेरी और प्रतिक्रिया में देखे गए अनुसार उपयुक्त नहीं है।
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+प्रश्न प्रतिक्रिया: 
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+IDs,hex के रूप में वापस किए जाते हैं।
+
+क्रमबद्धता में सुधार करने के लिए, हमें इकाई पर एक और फ़ील्ड बनानी चाहिए जो एक BigInt हो।
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+इससे क्रमबद्धता को क्रमिक रूप से अनुकूलित करने की अनुमति मिलेगी।
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+प्रश्न प्रतिक्रिया: 
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## निष्कर्ष
+
+Immutable Entities और Bytes को IDs के रूप में उपयोग करने से subgraph की दक्षता में उल्लेखनीय सुधार हुआ है। विशेष रूप से, परीक्षणों ने क्वेरी प्रदर्शन में 28% तक की वृद्धि और indexing स्पीड में 48% तक की तेजी को उजागर किया है।
+
+इस ब्लॉग पोस्ट में, Edge & Node के सॉफ़्टवेयर इंजीनियर डेविड लुटरकोर्ट द्वारा Immutable Entities और Bytes को IDs के रूप में उपयोग करने के बारे में और अधिक पढ़ें: [दो सरल Subgraph प्रदर्शन सुधार।](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 8dfef3c7600b5dd9da20487bc265f7b411b0f7ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:28 -0500
Subject: [PATCH 1571/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Swahili)

---
 .../immutable-entities-bytes-as-ids.mdx       | 190 ++++++++++++++++++
 1 file changed, 190 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/sw/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
new file mode 100644
index 000000000000..3a9ba309dd27
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -0,0 +1,190 @@
+---
+title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+---
+
+## TLDR
+
+Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+
+## Immutable Entities
+
+To make an entity immutable, we simply add `(immutable: true)` to an entity.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+
+Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+
+### Under the hood
+
+Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+
+### When not to use Immutable Entities
+
+If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+
+## Bytes as IDs
+
+Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+
+```graphql
+type Transfer @entity(immutable: true) {
+  id: Bytes!
+  from: Bytes!
+  to: Bytes!
+  value: BigInt!
+}
+```
+
+While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+
+### Reasons to Not Use Bytes as IDs
+
+1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
+2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
+3. Indexing and querying performance improvements are not desired.
+
+### Concatenating With Bytes as IDs
+
+It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+
+Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+
+```typescript
+export function handleTransfer(event: TransferEvent): void {
+  let entity = new Transfer(event.transaction.hash.concatI32(event.logIndex.toI32()))
+  entity.from = event.params.from
+  entity.to = event.params.to
+  entity.value = event.params.value
+
+  entity.blockNumber = event.block.number
+  entity.blockTimestamp = event.block.timestamp
+  entity.transactionHash = event.transaction.hash
+
+  entity.save()
+}
+```
+
+### Sorting With Bytes as IDs
+
+Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: id) {
+    id
+    from
+    to
+    value
+  }
+}
+```
+
+Query response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x00010000",
+        "from": "0xabcd...",
+        "to": "0x1234...",
+        "value": "256"
+      },
+      {
+        "id": "0x00020000",
+        "from": "0xefgh...",
+        "to": "0x5678...",
+        "value": "512"
+      },
+      {
+        "id": "0x01000000",
+        "from": "0xijkl...",
+        "to": "0x9abc...",
+        "value": "1"
+      }
+    ]
+  }
+}
+```
+
+The IDs are returned as hex.
+
+To improve sorting, we should create another field on the entity that is a BigInt.
+
+```graphql
+type Transfer @entity {
+  id: Bytes!
+  from: Bytes! # address
+  to: Bytes! # address
+  value: BigInt! # unit256
+  tokenId: BigInt! # uint256
+}
+```
+
+This will allow for sorting to be optimized sequentially.
+
+Query:
+
+```graphql
+{
+  transfers(first: 3, orderBy: tokenId) {
+    id
+    tokenId
+  }
+}
+```
+
+Query Response:
+
+```json
+{
+  "data": {
+    "transfers": [
+      {
+        "id": "0x…",
+        "tokenId": "1"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "2"
+      },
+      {
+        "id": "0x…",
+        "tokenId": "3"
+      }
+    ]
+  }
+}
+```
+
+## Conclusion
+
+Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+
+Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 03eb68c15c5419b476a364f7831d126096bfc39b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:29 -0500
Subject: [PATCH 1572/3820] New translations near.mdx (Romanian)

---
 website/pages/ro/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/near.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/near.mdx b/website/pages/ro/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..6060eb27e761
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Building Subgraphs on NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## What is NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## What are NEAR subgraphs?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Block handlers: these are run on every new block
+- Receipt handlers: run every time a message is executed at a specified account
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> A Receipt is the only actionable object in the system. When we talk about "processing a transaction" on the NEAR platform, this eventually means "applying receipts" at some point.
+
+## Building a NEAR Subgraph
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
+
+There are three aspects of subgraph definition:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+During subgraph development there are two key commands:
+
+```bash
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR data sources support two types of handlers:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Deploying a NEAR Subgraph
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+The node configuration will depend on where the subgraph is being deployed.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Local Graph Node (based on default configuration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexing NEAR with a Local Graph Node
+
+Running a Graph Node that indexes NEAR has the following operational requirements:
+
+- NEAR Indexer Framework with Firehose instrumentation
+- NEAR Firehose Component(s)
+- Graph Node with Firehose endpoint configured
+
+We will provide more information on running the above components soon.
+
+## Querying a NEAR Subgraph
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### How does the beta work?
+
+NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email near@thegraph.com so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can subgraphs react to more specific triggers?
+
+Currently, only Block and Receipt triggers are supported. We are investigating triggers for function calls to a specified account. We are also interested in supporting event triggers, once NEAR has native event support.
+
+### Will receipt handlers trigger for accounts and their sub-accounts?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+
+This is not supported. We are evaluating whether this functionality is required for indexing.
+
+### Can I use data source templates in my NEAR subgraph?
+
+This is not currently supported. We are evaluating whether this functionality is required for indexing.
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+Pending functionality is not yet supported for NEAR subgraphs. In the interim, you can deploy a new version to a different "named" subgraph, and then when that is synced with the chain head, you can redeploy to your primary "named" subgraph, which will use the same underlying deployment ID, so the main subgraph will be instantly synced.
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## References
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From fe266fa937375d0080e0b2988f7be95667c55ddd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:31 -0500
Subject: [PATCH 1573/3820] New translations near.mdx (French)

---
 website/pages/fr/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/near.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/near.mdx b/website/pages/fr/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..25195833a0d5
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Construction de subgraphs sur NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## Que signifie NEAR ?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## Que sont les subgraphs NEAR ?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Gestionnaires de blocs : ceux-ci sont exécutés à chaque nouveau bloc
+- Gestionnaires de reçus : exécutés à chaque fois qu'un message est exécuté sur un compte spécifié
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> Un reçu est le seul objet actionnable dans le système. Lorsque nous parlons de "traitement d'une transaction" sur la plateforme NEAR, cela signifie en fin de compte "appliquer des reçus" à un moment ou à un autre.
+
+## Construction d'un subgraph NEAR
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> La construction d'un subgraph NEAR est très similaire à la construction d'un subgraph qui indexe Ethereum.
+
+La définition d'un subgraph comporte trois aspects :
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+Lors du développement du subgraph, il y a deux commandes clés :
+
+```bash
+$ graph codegen # génère des types à partir du fichier de schéma identifié dans le manifeste
+$ graph build # génère le Web Assembly à partir des fichiers AssemblyScript, et prépare tous les fichiers de subgraphes dans un dossier /build
+```
+
+### Définition du manifeste du subgraph
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion : 0.0.2
+schema :
+  file : ./src/schema.graphql # lien vers le fichier de schéma
+dataSources :
+  - kind : near
+    network : near-mainnet
+    source :
+      account : app.good-morning.near # Cette source de données surveillera ce compte
+      startBlock : 10662188 # Requis pour NEAR
+    mapping :
+      apiVersion : 0.0.5
+      language : wasm/assemblyscript
+      blockHandlers :
+        - handler : handleNewBlock # le nom de la fonction dans le fichier de mapping
+      receiptHandlers :
+        - handler : handleReceipt # le nom de la fonction dans le fichier de mappage
+      file : ./src/mapping.ts # lien vers le fichier contenant les mappings Assemblyscript
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+comptes:
+   préfixes :
+     - application
+     - bien
+   suffixes :
+     - matin.près
+     - matin.testnet
+```
+
+Les fichiers de données NEAR prennent en charge deux types de gestionnaires :
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Définition de schéma
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### Cartographies AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Déploiement d'un subgraph NEAR
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio et l'Indexeur de mise à niveau sur The Graph Network prennent en charge actuellement l'indexation du mainnet et du testnet NEAR en bêta, avec les noms de réseau suivants :
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+La configuration du nœud dépend de l'endroit où le subgraph est déployé.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Nœud Graph local ( en fonction de la configuration par défaut)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Une fois que votre subgraph a été déployé, il sera indexé par le nœud The Graph. Vous pouvez vérifier sa progression en interrogeant le subgraph lui-même :
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexation de NEAR avec un nœud The graph local
+
+L'exécution d'un nœud de Graph qui indexe NEAR répond aux exigences opérationnelles suivantes :
+
+- Cadre d'indexation NEAR avec instrumentation Firehose
+- Composant(s) du NEAR Firehose
+- Nœud Gaph avec point d'extrémité Firehose configuré
+
+Nous fournirons bientôt plus d'informations sur l'utilisation des composants ci-dessus.
+
+## Interrogation d'un subgraph NEAR
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Exemples de subgraphs
+
+Voici quelques exemples de subgraphs pour référence :
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## Questions fréquemment posées
+
+### Comment fonctionne la bêta ?
+
+Le support de NEAR est en version bêta, ce qui signifie qu'il peut y avoir des changements dans l'API alors que nous continuons à travailler sur l'amélioration de l'intégration. Veuillez envoyer un e-mail à near@thegraph.com pour que nous puissions vous aider à construire des subgraphs NEAR et vous tenir au courant des derniers développements !
+
+### Un subgraph peut-il indexer à la fois les chaînes NEAR et EVM ?
+
+Non, un subgraph ne peut supporter que les sources de données d'une seule chaîne/réseau.
+
+### Les subgraphs peuvent-ils réagir à des déclencheurs plus spécifiques ?
+
+Actuellement, seuls les déclencheurs de blocage et de réception sont pris en charge. Nous étudions les déclencheurs pour les appels de fonction à un compte spécifique. Nous souhaitons également prendre en charge les déclencheurs d'événements, une fois que NEAR disposera d'un support natif pour les événements.
+
+### Les gestionnaires de reçus se déclencheront-ils pour les comptes et leurs sous-comptes ?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+comptes:
+   suffixes :
+     - mintbase1.near
+```
+
+### Les subgraphs NEAR peuvent-ils faire des appels de view aux comptes NEAR pendant les mappings?
+
+Cette fonction n'est pas prise en charge. Nous sommes en train d'évaluer si cette fonctionnalité est nécessaire pour l'indexation.
+
+### Puis-je utiliser des modèles de sources de données dans mon subgraph NEAR ?
+
+Ceci n’est actuellement pas pris en charge. Nous évaluons si cette fonctionnalité est requise pour l'indexation.
+
+### Les subgraphs Ethereum supportent les versions "pending" et "current", comment puis-je déployer une version "pending" d'un subgraph NEAR ?
+
+La fonctionnalité "pending" n'est pas encore prise en charge pour les subgraphs NEAR. Dans l'intervalle, vous pouvez déployer une nouvelle version dans un autre subgraph "named", puis, lorsque celui-ci est synchronisé avec la tête de chaîne, vous pouvez redéployer dans votre subgraph principal "named", qui utilisera le même ID de déploiement sous-jacent, de sorte que le subgraph principal sera instantanément synchronisé.
+
+### Ma question n'a pas reçu de réponse, où puis-je obtenir plus d'aide concernant la création de subgraphs NEAR ?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## Les Références
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From fdc6d9a99ad6d6b6d9befded09685c2bb07314fb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:32 -0500
Subject: [PATCH 1574/3820] New translations near.mdx (Spanish)

---
 website/pages/es/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/near.mdx

diff --git a/website/pages/es/subgraphs/cookbook/near.mdx b/website/pages/es/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..8dd12116fc09
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Construcción de subgrafos en NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## ¿Qué es NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## ¿Qué son los subgrafos NEAR?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Handlers de bloques: se ejecutan en cada nuevo bloque
+- Handlers de recibos: se realizan cada vez que se ejecuta un mensaje en una cuenta específica
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> Un recibo es el único objeto procesable del sistema. Cuando hablamos de "procesar una transacción" en la plataforma NEAR, esto significa eventualmente "aplicar recibos" en algún momento.
+
+## Construcción de un subgrafo NEAR
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Construir un subgrafo NEAR es muy similar a construir un subgrafo que indexa Ethereum.
+
+Hay tres aspectos de la definición de subgrafo:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+Durante el desarrollo del subgrafo hay dos comandos clave:
+
+```bash
+$ graph codegen # genera tipos a partir del archivo de esquema identificado en el manifiesto
+$ graph build # genera Web Assembly a partir de los archivos de AssemblyScript y prepara todos los archivos de subgrafo en una carpeta /build
+```
+
+### Definición de manifiesto del subgrafo
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+Las fuentes de datos NEAR admiten dos tipos de handlers:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Definición de esquema
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### Asignaciones de AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Deployando un subgrafo NEAR
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+La configuración del nodo dependerá de dónde se implemente el subgrafo.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Graph Node Local (basado en la configuración predeterminada)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Una vez que se haya implementado su subgrafo, Graph Node lo indexará. Puede comprobar su progreso consultando el propio subgrafo:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexación NEAR con un Graph Node local
+
+Ejecutar un Graph Node que indexa NEAR tiene los siguientes requisitos operativos:
+
+- NEAR Indexer Framework con instrumentación Firehose
+- Componente(s) NEAR Firehose
+- Graph Node con endpoint de Firehose configurado
+
+Pronto proporcionaremos más información sobre cómo ejecutar los componentes anteriores.
+
+## Consultando un subgrafo NEAR
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Subgrafos de ejemplo
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## Preguntas frecuentes
+
+### ¿Cómo funciona la beta?
+
+El soporte NEAR está en versión beta, lo que significa que puede haber cambios en la API a medida que continuamos trabajando para mejorar la integración. Envíe un correo electrónico a near@thegraph.com para que podamos ayudarlo a crear subgrafos NEAR y mantenerte actualizado sobre los últimos desarrollos!
+
+### ¿Puede un subgrafo indexar las cadenas NEAR y EVM?
+
+No, un subgrafo sólo puede admitir fuentes de datos de una cadena/red.
+
+### ¿Pueden los subgrafos reaccionar a activadores más específicos?
+
+Actualmente, solo se admiten los activadores de Bloque y Recibo. Estamos investigando activadores para llamadas a funciones a una cuenta específica. También estamos interesados en admitir activadores de eventos, una vez que NEAR tenga soporte nativo para eventos.
+
+### ¿Se activarán los handlers de recibos para las cuentas y sus subcuentas?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### ¿Pueden los subgrafos NEAR realizar view calls a cuentas NEAR durante las asignaciones?
+
+Esto no es compatible. Estamos evaluando si esta funcionalidad es necesaria para la indexación.
+
+### ¿Puedo usar plantillas de fuente de datos en mi subgrafo NEAR?
+
+Esto no es compatible actualmente. Estamos evaluando si esta funcionalidad es necesaria para la indexación.
+
+### Los subgrafos de Ethereum admiten versiones "pendientes" y "actuales", ¿cómo puedo implementar una versión "pendiente" de un subgrafo NEAR?
+
+La funcionalidad pendiente aún no es compatible con los subgrafos NEAR. Mientras tanto, puedes implementar una nueva versión en un subgrafo "nombrado" diferente y luego, cuando se sincroniza con el encabezado de la cadena, puedes volver a implementarlo en su subgrafo principal "nombrado", que usará el mismo ID de implementación subyacente, por lo que el subgrafo principal se sincronizará instantáneamente.
+
+### Mi pregunta no ha sido respondida, ¿dónde puedo obtener más ayuda para crear subgrafos NEAR?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## Referencias
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 7409559db9cf58d5a538d4ce242ad093872e87da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:33 -0500
Subject: [PATCH 1575/3820] New translations near.mdx (Arabic)

---
 website/pages/ar/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/near.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/near.mdx b/website/pages/ar/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..f85a5666639c
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: بناء Subgraphs على NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## ما هو NEAR؟
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## ماهي NEAR subgraphs؟
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- معالجات الكتل(Block handlers): يتم تشغيلها على كل كتلة جديدة
+- معالجات الاستلام (Receipt handlers): يتم تشغيلها في كل مرة يتم فيها تنفيذ رسالة على حساب محدد
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> الاستلام (Receipt) هو الكائن الوحيد القابل للتنفيذ في النظام. عندما نتحدث عن "معالجة الإجراء" على منصة NEAR ، فإن هذا يعني في النهاية "تطبيق الاستلامات" في مرحلة ما.
+
+## بناء NEAR Subgraph
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
+
+هناك ثلاثة جوانب لتعريف الـ subgraph:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+During subgraph development there are two key commands:
+
+```bash
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+### تعريف Subgraph Manifest
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+مصادر بيانات NEAR تدعم نوعين من المعالجات:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### تعريف المخطط
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## نشر NEAR Subgraph
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+The node configuration will depend on where the subgraph is being deployed.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Local Graph Node (based on default configuration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+بمجرد نشر الـ subgraph الخاص بك ، سيتم فهرسته بواسطة Graph Node. يمكنك التحقق من تقدمه عن طريق الاستعلام عن الـ subgraph نفسه:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexing NEAR with a Local Graph Node
+
+تشغيل Graph Node التي تقوم بفهرسة NEAR لها المتطلبات التشغيلية التالية:
+
+- NEAR Indexer Framework مع أجهزة Firehose
+- مكونات NEAR Firehose
+- تكوين Graph Node مع Firehose endpoint
+
+سوف نقدم المزيد من المعلومات حول تشغيل المكونات أعلاه قريبًا.
+
+## الاستعلام عن NEAR Subgraph
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## أمثلة على الـ Subgraphs
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## الأسئلة الشائعة
+
+### How does the beta work?
+
+NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email near@thegraph.com so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can subgraphs react to more specific triggers?
+
+حاليًا ، يتم دعم مشغلات الكتلة(Block) والاستلام(Receipt). نحن نبحث في مشغلات استدعاءات الدوال لحساب محدد. نحن مهتمون أيضًا بدعم مشغلات الأحداث ، بمجرد حصول NEAR على دعم محلي للأحداث.
+
+### Will receipt handlers trigger for accounts and their sub-accounts?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+
+هذا غير مدعوم. نحن بصدد تقييم ما إذا كانت هذه الميزة مطلوبة للفهرسة.
+
+### Can I use data source templates in my NEAR subgraph?
+
+هذا غير مدعوم حاليا. نحن بصدد تقييم ما إذا كانت هذه الميزة مطلوبة للفهرسة.
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+الوظيفة المعلقة ليست مدعومة لـ NEAR subgraphs. وفي غضون ذلك ، يمكنك نشر إصدار جديد على subgraph مختلف "مسمى" ، وبعد ذلك عندما تتم مزامنته مع رأس السلسلة ، يمكنك إعادة النشر إلى الـ subgraph الأساسي "المسمى" ، والذي سيستخدم نفس ID النشر الأساسي ، لذلك ستتم مزامنة الـ subgraph الرئيسي على الفور.
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## المراجع
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 0d48a40ad9410c39395115b32155a6ff4458f208 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:34 -0500
Subject: [PATCH 1576/3820] New translations near.mdx (Czech)

---
 website/pages/cs/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/near.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/near.mdx b/website/pages/cs/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..dc65c11da629
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Vytváření podgrafů v NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## Co je NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## Co jsou podgrafy NEAR?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Obsluhy bloků: jsou spouštěny při každém novém bloku.
+- Obsluhy příjmu: spouštějí se pokaždé, když je zpráva provedena na zadaném účtu.
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> Příjemka je jediným objektem, který lze v systému použít. Když na platformě NEAR hovoříme o "zpracování transakce", znamená to v určitém okamžiku "použití účtenky".
+
+## Sestavení podgrafu NEAR
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Vytváření subgrafu NEAR je velmi podobné vytváření subgrafu, který indexuje Ethereum.
+
+Definice podgrafů má tři aspekty:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+Při vývoji podgrafů existují dva klíčové příkazy:
+
+```bash
+$ graph codegen # generuje typy ze souboru se schématem identifikovaným v manifestu
+$ graph build # vygeneruje webové sestavení ze souborů AssemblyScript a připraví všechny dílčí soubory do složky /build
+```
+
+### Definice podgrafu Manifest
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+Zdroje dat NEAR podporují dva typy zpracovatelů:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Definice schématu
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mapování
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Nasazení podgrafu NEAR
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+Konfigurace uzlů závisí na tom, kde je podgraf nasazen.
+
+### Podgraf Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Místní uzel grafu (na základě výchozí konfigurace)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Jakmile je podgraf nasazen, bude indexován pomocí Graph Node. Jeho průběh můžete zkontrolovat dotazem na samotný podgraf:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexování NEAR pomocí místního uzlu grafu
+
+Spuštění grafu uzlu, který indexuje NEAR, má následující provozní požadavky:
+
+- Framework NEAR Indexer s instrumentací Firehose
+- Komponenta(y) NEAR Firehose
+- Uzel Graph s nakonfigurovaným koncovým bodem Firehose
+
+Brzy vám poskytneme další informace o provozu výše uvedených komponent.
+
+## Dotazování podgrafu NEAR
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Příklady podgrafů
+
+Zde je několik příkladů podgrafů:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### Jak funguje beta verze?
+
+Podpora NEAR je ve fázi beta, což znamená, že v API může dojít ke změnám, protože budeme pokračovat ve zdokonalování integrace. Napište nám prosím na adresu near@thegraph.com, abychom vás mohli podpořit při vytváření podgrafů NEAR a informovat vás o nejnovějším vývoji!
+
+### Může podgraf indexovat řetězce NEAR i EVM?
+
+Ne, podgraf může podporovat zdroje dat pouze z jednoho řetězce/sítě.
+
+### Mohou podgrafy reagovat na specifičtější spouštěče?
+
+V současné době jsou podporovány pouze spouštěče Blok a Příjem. Zkoumáme spouštěče pro volání funkcí na zadaném účtu. Máme také zájem o podporu spouštěčů událostí, jakmile bude mít NEAR nativní podporu událostí.
+
+### Budou se obsluhy příjmu spouštět pro účty a jejich podúčty?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Mohou podgrafy NEAR během mapování volat zobrazení na účty NEAR?
+
+To není podporováno. Vyhodnocujeme, zda je tato funkce pro indexování nutná.
+
+### Mohu v podgrafu NEAR používat šablony zdrojů dat?
+
+Tato funkce není v současné době podporována. Vyhodnocujeme, zda je tato funkce pro indexování nutná.
+
+### Podgrafy Ethereum podporují verze "pending" a "current", jak mohu nasadit verzi "pending" podgrafu NEAR?
+
+Pro podgrafy NEAR zatím nejsou podporovány čekající funkce. V mezidobí můžete novou verzi nasadit do jiného "pojmenovaného" podgrafu a po jeho synchronizaci s hlavou řetězce ji můžete znovu nasadit do svého hlavního "pojmenovaného" podgrafu, který bude používat stejné ID nasazení, takže hlavní podgraf bude okamžitě synchronizován.
+
+### Moje otázka nebyla zodpovězena, kde mohu získat další pomoc při vytváření podgrafů NEAR?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## Odkazy:
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From eedb0949443be728b390c67a3427cec2c28f0439 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:35 -0500
Subject: [PATCH 1577/3820] New translations near.mdx (German)

---
 website/pages/de/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/near.mdx

diff --git a/website/pages/de/subgraphs/cookbook/near.mdx b/website/pages/de/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..d748e4787563
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Building Subgraphs on NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## What is NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## What are NEAR subgraphs?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Block handlers: these are run on every new block
+- Receipt handlers: run every time a message is executed at a specified account
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> A Receipt is the only actionable object in the system. When we talk about "processing a transaction" on the NEAR platform, this eventually means "applying receipts" at some point.
+
+## Building a NEAR Subgraph
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
+
+There are three aspects of subgraph definition:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+During subgraph development there are two key commands:
+
+```bash
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+### Subgraf-Manifest-Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR data sources support two types of handlers:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Schema-Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript-Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Deploying a NEAR Subgraph
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+The node configuration will depend on where the subgraph is being deployed.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Local Graph Node (based on default configuration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexing NEAR with a Local Graph Node
+
+Running a Graph Node that indexes NEAR has the following operational requirements:
+
+- NEAR Indexer Framework with Firehose instrumentation
+- NEAR Firehose Component(s)
+- Graph Node with Firehose endpoint configured
+
+We will provide more information on running the above components soon.
+
+## Querying a NEAR Subgraph
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Beispiele von Subgrafen
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### How does the beta work?
+
+NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email near@thegraph.com so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can subgraphs react to more specific triggers?
+
+Currently, only Block and Receipt triggers are supported. We are investigating triggers for function calls to a specified account. We are also interested in supporting event triggers, once NEAR has native event support.
+
+### Will receipt handlers trigger for accounts and their sub-accounts?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+
+This is not supported. We are evaluating whether this functionality is required for indexing.
+
+### Can I use data source templates in my NEAR subgraph?
+
+This is not currently supported. We are evaluating whether this functionality is required for indexing.
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+Pending functionality is not yet supported for NEAR subgraphs. In the interim, you can deploy a new version to a different "named" subgraph, and then when that is synced with the chain head, you can redeploy to your primary "named" subgraph, which will use the same underlying deployment ID, so the main subgraph will be instantly synced.
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## References
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 0d1361328e3b14893d77c22324bbb32adc2ed3ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:36 -0500
Subject: [PATCH 1578/3820] New translations near.mdx (Italian)

---
 website/pages/it/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/near.mdx

diff --git a/website/pages/it/subgraphs/cookbook/near.mdx b/website/pages/it/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..809574aa81cd
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Building Subgraphs on NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## What is NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## What are NEAR subgraphs?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Block handlers: these are run on every new block
+- Receipt handlers: run every time a message is executed at a specified account
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> A Receipt is the only actionable object in the system. When we talk about "processing a transaction" on the NEAR platform, this eventually means "applying receipts" at some point.
+
+## Building a NEAR Subgraph
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
+
+There are three aspects of subgraph definition:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+During subgraph development there are two key commands:
+
+```bash
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR data sources support two types of handlers:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Deploying a NEAR Subgraph
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+The node configuration will depend on where the subgraph is being deployed.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Local Graph Node (based on default configuration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexing NEAR with a Local Graph Node
+
+Running a Graph Node that indexes NEAR has the following operational requirements:
+
+- NEAR Indexer Framework with Firehose instrumentation
+- NEAR Firehose Component(s)
+- Graph Node with Firehose endpoint configured
+
+We will provide more information on running the above components soon.
+
+## Querying a NEAR Subgraph
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### How does the beta work?
+
+NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email near@thegraph.com so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can subgraphs react to more specific triggers?
+
+Currently, only Block and Receipt triggers are supported. We are investigating triggers for function calls to a specified account. We are also interested in supporting event triggers, once NEAR has native event support.
+
+### Will receipt handlers trigger for accounts and their sub-accounts?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+
+This is not supported. We are evaluating whether this functionality is required for indexing.
+
+### Can I use data source templates in my NEAR subgraph?
+
+This is not currently supported. We are evaluating whether this functionality is required for indexing.
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+Pending functionality is not yet supported for NEAR subgraphs. In the interim, you can deploy a new version to a different "named" subgraph, and then when that is synced with the chain head, you can redeploy to your primary "named" subgraph, which will use the same underlying deployment ID, so the main subgraph will be instantly synced.
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## Riferimenti
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 4f9cf64877f008acdb1dcdb016ec24f1656248d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:37 -0500
Subject: [PATCH 1579/3820] New translations near.mdx (Japanese)

---
 website/pages/ja/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/near.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/near.mdx b/website/pages/ja/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..63b6ed756c7c
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: NEAR でサブグラフを作成する
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## NEAR とは？
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## NEAR サブグラフとは？
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- ブロックハンドラ：新しいブロックごとに実行されます
+- レシートハンドラ：指定されたアカウントでメッセージが実行されるたびに実行されます
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> レシートは、システム内で唯一実行可能なオブジェクトです。NEAR プラットフォームで「トランザクションの処理」といえば、最終的にはどこかの時点で「レシートの適用」を意味します。
+
+## NEAR サブグラフの構築
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> NEAR サブグラフの構築は、Ethereum のインデックスを作成するサブグラフの構築と非常によく似ています。
+
+サブグラフの定義には 3 つの側面があります:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+サブグラフの開発には 2 つの重要なコマンドがあります:
+
+```bash
+$ graph codegen # マニフェストで識別されたようにファイルから型を生成します
+$ グラフ ビルド # AssemblyScript ファイルから Web アセンブリを生成し、/build フォルダにすべてのサブグラフ ファイルを準備します
+```
+
+### サブグラフマニフェストの定義
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR データソースは 2 種類のハンドラーをサポートしています:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### スキーマ定義
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript マッピング
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## NEAR サブグラフの展開
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+ノードの構成は、サブグラフがどこにディプロイされるかによって異なります。
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### ローカル グラフ ノード (デフォルト構成に基づく)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+デプロイされたサブグラフは、Graph Node によってインデックス化され、その進捗状況は、サブグラフ自体にクエリして確認できます:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### ローカル グラフ ノードを使用した NEAR のインデックス作成
+
+NEAR のインデックスを作成するグラフノードの運用には、以下のような運用要件があります:
+
+- NEAR Indexer Framework と Firehose instrumentation
+- NEAR Firehose コンポーネント
+- Firehose エンドポイントが設定されたグラフノード
+
+上記のコンポーネントの運用については、近日中に詳しくご紹介します。
+
+## NEAR サブグラフへのクエリ
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## サブグラフの例
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## よくある質問
+
+### ベータ版はどのように機能しますか?
+
+NEAR サポートはベータ版です。統合の改善を続ける中で、API に変更が加えられる可能性があります。NEAR サブグラフの構築をサポートし、最新の開発状況をお知らせしますので、near@thegraph.comまでメールをお送りください。
+
+### サブグラフは NEAR チェーンと EVM チェーンの両方にインデックスを付けることができますか?
+
+いいえ、サブグラフは 1 つのチェーン/ネットワークのデータソースのみをサポートします。
+
+### サブグラフはより具体的なトリガーに反応できますか?
+
+現在、ブロックとレシートのトリガーのみがサポートされています。指定されたアカウントへのファンクションコールのトリガーを検討しています。また、NEAR がネイティブイベントをサポートするようになれば、イベントトリガーのサポートも検討しています。
+
+### 領収書ハンドラーは、アカウントとそのサブアカウントに対してトリガーされますか?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### NEAR サブグラフは、マッピング中に NEAR アカウントへのビュー呼び出しを行うことができますか?
+
+これはサポートされていません。この機能がインデックス作成に必要かどうかを評価しています。
+
+### NEAR サブグラフでデータ ソース テンプレートを使用できますか?
+
+これは現在サポートされていません。この機能がインデックス作成に必要かどうかを評価しています。
+
+### Ethereum サブグラフは「保留中」バージョンと「現在」バージョンをサポートしていますが、NEAR サブグラフの「保留中」バージョンをデプロイするにはどうすればよいですか?
+
+「pending」は、NEAR サブグラフではまだサポートされていません。暫定的に、新しいバージョンを別の「named」サブグラフにデプロイし、それがチェーンヘッドと同期したときに、メインの「named」サブグラフに再デプロイすることができます。
+
+### 私の質問に対する回答がありません。NEAR サブグラフの作成に関するヘルプはどこで入手できますか?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## 参考文献
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From fd628224e7c40c8dd7f4b0bed692fda0edd1da5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:38 -0500
Subject: [PATCH 1580/3820] New translations near.mdx (Korean)

---
 website/pages/ko/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/near.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/near.mdx b/website/pages/ko/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..6060eb27e761
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Building Subgraphs on NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## What is NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## What are NEAR subgraphs?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Block handlers: these are run on every new block
+- Receipt handlers: run every time a message is executed at a specified account
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> A Receipt is the only actionable object in the system. When we talk about "processing a transaction" on the NEAR platform, this eventually means "applying receipts" at some point.
+
+## Building a NEAR Subgraph
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
+
+There are three aspects of subgraph definition:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+During subgraph development there are two key commands:
+
+```bash
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR data sources support two types of handlers:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Deploying a NEAR Subgraph
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+The node configuration will depend on where the subgraph is being deployed.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Local Graph Node (based on default configuration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexing NEAR with a Local Graph Node
+
+Running a Graph Node that indexes NEAR has the following operational requirements:
+
+- NEAR Indexer Framework with Firehose instrumentation
+- NEAR Firehose Component(s)
+- Graph Node with Firehose endpoint configured
+
+We will provide more information on running the above components soon.
+
+## Querying a NEAR Subgraph
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### How does the beta work?
+
+NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email near@thegraph.com so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can subgraphs react to more specific triggers?
+
+Currently, only Block and Receipt triggers are supported. We are investigating triggers for function calls to a specified account. We are also interested in supporting event triggers, once NEAR has native event support.
+
+### Will receipt handlers trigger for accounts and their sub-accounts?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+
+This is not supported. We are evaluating whether this functionality is required for indexing.
+
+### Can I use data source templates in my NEAR subgraph?
+
+This is not currently supported. We are evaluating whether this functionality is required for indexing.
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+Pending functionality is not yet supported for NEAR subgraphs. In the interim, you can deploy a new version to a different "named" subgraph, and then when that is synced with the chain head, you can redeploy to your primary "named" subgraph, which will use the same underlying deployment ID, so the main subgraph will be instantly synced.
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## References
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 53da569a7b31c84c0b35fe6a5b65e9e5cf8c17b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:39 -0500
Subject: [PATCH 1581/3820] New translations near.mdx (Dutch)

---
 website/pages/nl/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/near.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/near.mdx b/website/pages/nl/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..75f966e7a597
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Building Subgraphs on NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## What is NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## What are NEAR subgraphs?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Block handlers: these are run on every new block
+- Receipt handlers: run every time a message is executed at a specified account
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> A Receipt is the only actionable object in the system. When we talk about "processing a transaction" on the NEAR platform, this eventually means "applying receipts" at some point.
+
+## Building a NEAR Subgraph
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
+
+There are three aspects of subgraph definition:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+Tijdens subgraph ontwikkeling zijn er twee belangrijke commando's:
+
+```bash
+$ graph codegen # genereert types van het schema bestand die geïdentificeerd is in het manifest
+$ graph build # genereert Web Assembly vanuit de AssemblyScript-bestanden, en bereidt alle Subgraph-bestanden voor in een /build map
+```
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR data sources support two types of handlers:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Deploying a NEAR Subgraph
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+The node configuration will depend on where the subgraph is being deployed.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Local Graph Node (based on default configuration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexing NEAR with a Local Graph Node
+
+Running a Graph Node that indexes NEAR has the following operational requirements:
+
+- NEAR Indexer Framework with Firehose instrumentation
+- NEAR Firehose Component(s)
+- Graph Node with Firehose endpoint configured
+
+We will provide more information on running the above components soon.
+
+## Querying a NEAR Subgraph
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### How does the beta work?
+
+NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email near@thegraph.com so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can subgraphs react to more specific triggers?
+
+Currently, only Block and Receipt triggers are supported. We are investigating triggers for function calls to a specified account. We are also interested in supporting event triggers, once NEAR has native event support.
+
+### Will receipt handlers trigger for accounts and their sub-accounts?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+
+This is not supported. We are evaluating whether this functionality is required for indexing.
+
+### Can I use data source templates in my NEAR subgraph?
+
+This is not currently supported. We are evaluating whether this functionality is required for indexing.
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+Pending functionality is not yet supported for NEAR subgraphs. In the interim, you can deploy a new version to a different "named" subgraph, and then when that is synced with the chain head, you can redeploy to your primary "named" subgraph, which will use the same underlying deployment ID, so the main subgraph will be instantly synced.
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## References
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From a966dc69f57ad28dcb37999564945a54da98fdb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:40 -0500
Subject: [PATCH 1582/3820] New translations near.mdx (Polish)

---
 website/pages/pl/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/near.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/near.mdx b/website/pages/pl/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..6060eb27e761
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Building Subgraphs on NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## What is NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## What are NEAR subgraphs?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Block handlers: these are run on every new block
+- Receipt handlers: run every time a message is executed at a specified account
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> A Receipt is the only actionable object in the system. When we talk about "processing a transaction" on the NEAR platform, this eventually means "applying receipts" at some point.
+
+## Building a NEAR Subgraph
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
+
+There are three aspects of subgraph definition:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+During subgraph development there are two key commands:
+
+```bash
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR data sources support two types of handlers:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Deploying a NEAR Subgraph
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+The node configuration will depend on where the subgraph is being deployed.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Local Graph Node (based on default configuration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexing NEAR with a Local Graph Node
+
+Running a Graph Node that indexes NEAR has the following operational requirements:
+
+- NEAR Indexer Framework with Firehose instrumentation
+- NEAR Firehose Component(s)
+- Graph Node with Firehose endpoint configured
+
+We will provide more information on running the above components soon.
+
+## Querying a NEAR Subgraph
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### How does the beta work?
+
+NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email near@thegraph.com so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can subgraphs react to more specific triggers?
+
+Currently, only Block and Receipt triggers are supported. We are investigating triggers for function calls to a specified account. We are also interested in supporting event triggers, once NEAR has native event support.
+
+### Will receipt handlers trigger for accounts and their sub-accounts?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+
+This is not supported. We are evaluating whether this functionality is required for indexing.
+
+### Can I use data source templates in my NEAR subgraph?
+
+This is not currently supported. We are evaluating whether this functionality is required for indexing.
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+Pending functionality is not yet supported for NEAR subgraphs. In the interim, you can deploy a new version to a different "named" subgraph, and then when that is synced with the chain head, you can redeploy to your primary "named" subgraph, which will use the same underlying deployment ID, so the main subgraph will be instantly synced.
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## References
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From bf20f4e501e154e0731a77fed4b3c8445f057576 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:42 -0500
Subject: [PATCH 1583/3820] New translations near.mdx (Portuguese)

---
 website/pages/pt/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/near.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/near.mdx b/website/pages/pt/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..b9a7d95269f4
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Construção de Subgraphs na NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## O que é NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## O que são subgraphs na NEAR?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Handlers de blocos: executados em todos os blocos novos
+- Handlers de recibos: Executados sempre que uma mensagem é executada numa conta especificada
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> Um Recibo é o único objeto acionável no sistema. Quando falamos de "processar uma transação" na plataforma NEAR, em algum ponto isto eventualmente significa "aplicar recibos".
+
+## Construindo um Subgraph no NEAR
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Construir um subgraph NEAR é um processo muito parecido com a construção de um subgraph que indexa o Ethereum.
+
+Há três aspectos de definição de subgraph:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+Durante o desenvolvimento de um subgraph, existem dois comandos importantes:
+
+```bash
+$ graph codegen # gera tipos do arquivo de schema identificado no manifest
+$ graph build # gera Web Assembly dos arquivos AssemblyScript, e prepara todos os arquivos do subgraph em uma pasta /build
+```
+
+### Definição de Manifest de Subgraph
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link para o arquivo de schema
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # Esta fonte de dados monitorará esta conta
+      startBlock: 10662188 # Necessário para a NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # nome da função no arq. de mapeamento
+      receiptHandlers:
+        - handler: handleReceipt # nome da função no arq. de mapeamento
+      file: ./src/mapping.ts # link ao arq. com os mapeamentos de Assemblyscript
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+As fontes de dados na NEAR apoiam duas categorias de handlers:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Definição de Schema
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### Mapeamentos em AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Lançando um Subgraph na NEAR
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+O Subgraph Studio e o Indexador de atualização na Graph Network apoiam atualmente a indexação da mainnet e da testnet do NEAR em beta, com os seguintes nomes de rede:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+A configuração do nódulo dependerá de onde o subgraph será lançado.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Graph Node local (baseado na configuração padrão)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Quando o seu subgraph for lançado, ele será indexado pelo Graph Node. O seu progresso pode ser conferido com um query no próprio subgraph:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Como indexar a NEAR com um Graph Node local
+
+Executar um Graph Node que indexa a NEAR exige estes requisitos opcionais:
+
+- NEAR Indexer Framework (Estrutura de Indexer) com instrumentação Firehose
+- Componente(s) de Firehose no NEAR
+- Graph Node com endpoint Firehose configurado
+
+Em breve, falaremos mais sobre como executar os componentes acima.
+
+## Como Consultar um Subgraph na NEAR
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Exemplos de Subgraphs
+
+Aqui estão alguns exemplos de subgraphs para referência:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## Perguntas Frequentes
+
+### Como o beta funciona?
+
+O apoio à NEAR está em beta; podem ocorrer mais mudanças na API enquanto continuamos a melhorar a integração. Por favor, contacte-nos em near@thegraph.com para podermos apoiar-te na construção de subgraphs no NEAR e avisar-te sobre os acontecimentos mais recentes!
+
+### Um subgraph pode indexar chains da NEAR e da EVM?
+
+Não, um subgraph só pode apoiar fontes de dados de apenas uma chain/rede.
+
+### Os subgraphs podem reagir a gatilhos mais específicos?
+
+Atualmente, só há apoio a gatilhos de Blocos e Recibos. Estamos a investigar gatilhos para chamadas de função a uma conta específica. Também temos interesse em apoiar gatilhos de eventos, quando a NEAR receber apoio nativo a eventos.
+
+### Handlers de recibos ativarão para contas e subcontas?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Subgraphs na NEAR podem fazer chamadas de vistoria para contas NEAR durante os mapeamentos?
+
+Não há apoio a isto. Estamos a avaliar se esta funcionalidade é necessária para indexação.
+
+### Posso usar modelos de fontes de dados no meu subgraph na NEAR?
+
+Não há apoio a isto no momento. Estamos a avaliar se esta funcionalidade é necessária para indexação.
+
+### Subgraphs no Ethereum apoiam versões "pendentes" e "atuais". Como posso lançar uma versão "pendente" de um subgraph no NEAR?
+
+No momento, não há apoio à funcionalidade de pendências para subgraphs na NEAR. Entretanto, podes lançar uma nova versão para um subgraph de "nome" diferente, e quando este for sincronizado com a cabeça da chain, podes relançá-la para seu subgraph de "nome" primário, que usará o mesmo ID de lançamento subjacente — e aí, o subgraph principal sincronizará instantaneamente.
+
+### A minha pergunta não foi respondida. Onde posso conseguir mais ajuda sobre construir subgraphs na NEAR?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## Referências
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From e4d87afe5cf5220625e54798a68808a889edf798 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:43 -0500
Subject: [PATCH 1584/3820] New translations near.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/near.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/near.mdx b/website/pages/ru/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..6956ccaa3c4c
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Создание субграфов на NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## Что такое NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## Что такое NEAR подграфы?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Обработчики блоков: они запускаются для каждого нового блока
+- Обработчики квитанций: запускаются каждый раз, когда сообщение выполняется в указанной учетной записи
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> Квитанция - это единственный объект, к которому можно применить действие в системе. Когда мы говорим об "обработке транзакции" на платформе NEAR, это в конечном итоге означает "применение квитанций" в какой-то момент.
+
+## Создание NEAR подграфа
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Построение NEAR сабграфа очень похоже на построение сабграфа, индексирующего Ethereum.
+
+Существует три аспекта определения подграфа:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+Во время разработки субграфа есть две ключевые команды:
+
+```bash
+$ graph codegen # генерирует типы из файла схемы, указанного в манифесте
+$ graph build # генерирует Web Assembly из файлов AssemblyScript и подготавливает все файлы субграфа в папке /build
+```
+
+### Определение манифеста субграфа
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+Источники данных NEAR поддерживают два типа обработчиков:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Определение схемы
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### Мэппинги AssemblyScript
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Развертывание NEAR субграфа
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+Конфигурация ноды будет зависеть от того, где развертывается подграф.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Local Graph Node (based on default configuration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Как только ваш подграф будет развернут, он будет проиндексирован Graph Node. Вы можете проверить его прогресс, сделав запрос к самому субграфу:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexing NEAR with a Local Graph Node
+
+Запуск ноды Graph, который индексирует NEAR, имеет следующие эксплуатационные требования:
+
+- Фреймворк NEAR Indexer с инструментарием Firehose
+- Компонент(ы) NEAR Firehose
+- Graph Node с настроенным эндпоинтом Firehose
+
+В ближайшее время мы предоставим более подробную информацию о запуске вышеуказанных компонентов.
+
+## Запрос NEAR подграфа
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Примеры субграфов
+
+Вот несколько примеров субграфов для справки:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## Часто задаваемые вопросы
+
+### How does the beta work?
+
+Поддержка NEAR находится в стадии бета-тестирования, что означает, что в API могут быть внесены изменения, поскольку мы продолжаем работать над улучшением интеграции. Пожалуйста, напишите по электронной почте near@thegraph.com чтобы мы могли поддержать вас в создании NEAR подграфов и держать вас в курсе последних разработок!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+Нет, субграф может поддерживать источники данных только из одного чейна/сети.
+
+### Can subgraphs react to more specific triggers?
+
+В настоящее время поддерживаются только триггеры Block и Receipt. Мы исследуем триггеры для вызовов функций к указанной учетной записи. Мы также заинтересованы в поддержке триггеров событий, когда NEAR обладает собственной поддержкой событий.
+
+### Will receipt handlers trigger for accounts and their sub-accounts?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+
+Это не поддерживается. Мы оцениваем, требуется ли эта функциональность для индексации.
+
+### Can I use data source templates in my NEAR subgraph?
+
+В настоящее время это не поддерживается. Мы оцениваем, требуется ли эта функциональность для индексации.
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+Ожидающая функциональность еще не поддерживается для NEAR подграфов. Тем временем вы можете развернуть новую версию на другом "именованном" подграфе, а затем, когда она будет синхронизирована с заголовком чейна, вы можете повторно развернуть ее на свой основной "именованный" подграф, который будет использовать тот же базовый идентификатор развертывания, поэтому основной субграф будет мгновенно синхронизирован.
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## Ссылки
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From e317b170cc8ee5a52dbec2e50c36ea892575d551 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:44 -0500
Subject: [PATCH 1585/3820] New translations near.mdx (Swedish)

---
 website/pages/sv/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/near.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/near.mdx b/website/pages/sv/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..833a4b7c997d
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Bygger subgrafer på NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## Vad är NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## Vad är NEAR subgrafer?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Blockhanterare: dessa körs på varje nytt block
+- Kvittohanterare: körs varje gång ett meddelande körs på ett angivet konto
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> Ett kvitto är det enda handlingsbara objektet i systemet. När vi pratar om att "bearbeta en transaktion" på NEAR plattformen betyder det så småningom att "tillämpa kvitton" någon gång.
+
+## Att bygga en NEAR Subgraf
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Att bygga en NEAR subgraf är mycket lik att bygga en subgraf som indexerar Ethereum.
+
+Det finns tre aspekter av subgraf definition:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+Under subgrafutveckling finns det två nyckelkommandon:
+
+```bash
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+### Definition av subgraf manifestet
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR datakällor stöder två typer av hanterare:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript mappningar
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Utplacera en NEAR Subgraf
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+Nodkonfigurationen beror på var subgrafen distribueras.
+
+### Subgraf Studion
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Lokal graf nod (baserat på standardkonfiguration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+När din subgraf har distribuerats kommer den att indexeras av Graph Node. Du kan kontrollera dess framsteg genom att fråga själva subgrafen:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexering av NEAR med en lokal grafnod
+
+Att köra en Graph Node som indexerar NEAR har följande operativa krav:
+
+- NEAR Indexer Framework med Firehose-instrumentering
+- NEAR Brandslangskomponent(er)
+- Graf Nod med Firehose ändpunkt konfigurerad
+
+Vi kommer snart att ge mer information om hur du kör ovanstående komponenter.
+
+## Fråga efter en NEAR subgraf
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Exempel på subgrafer
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### Hur fungerar betan?
+
+NEAR stödet är i beta, vilket innebär att det kan bli ändringar i API:t när vi fortsätter att arbeta med att förbättra integrationen. Skicka ett e-postmeddelande till near@thegraph.com så att vi kan hjälpa dig att bygga NEAR subgrafer och hålla dig uppdaterad om den senaste utvecklingen!
+
+### Kan en subgraf indexera både NEAR och EVM kedjor?
+
+Nej, en subgraf kan bara stödja datakällor från en kedja/nätverk.
+
+### Kan subgrafer reagera på mer specifika triggers?
+
+För närvarande stöds endast blockerings- och kvittoutlösare. Vi undersöker utlösare för funktionsanrop till ett specificerat konto. Vi är också intresserade av att stödja eventutlösare, när NEAR har inbyggt eventsupport.
+
+### Kommer kvittohanterare att utlösa för konton och deras underkonton?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Kan NEAR subgrafer göra visningsanrop till NEAR konton under mappningar?
+
+Detta stöds inte. Vi utvärderar om denna funktionalitet krävs för indexering.
+
+### Kan jag använda data källmallar i min NEAR subgraf?
+
+Detta stöds inte för närvarande. Vi utvärderar om denna funktionalitet krävs för indexering.
+
+### Ethereum subgrafer stöder "väntande" och "nuvarande" versioner, hur kan jag distribuera en "väntande" version av en NEAR subgraf?
+
+Väntande funktionalitet stöds ännu inte för NEAR subgrafer. Under tiden kan du distribuera en ny version till en annan "namngiven" subgraf, och när den sedan synkroniseras med kedjehuvudet kan du distribuera om till din primära "namngivna" subgraf, som kommer att använda samma underliggande implementerings-ID, så huvudsubgrafen synkroniseras omedelbart.
+
+### Min fråga har inte besvarats, var kan jag få mer hjälp med att bygga NEAR subgrafer?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## Referenser
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From a8f5f94a511f8d162cb2355fc0c0afd43bdfbb2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:45 -0500
Subject: [PATCH 1586/3820] New translations near.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/near.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/near.mdx b/website/pages/tr/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..3d6114dbb11b
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: NEAR Üzerinde Subgraphlar Oluşturma
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## NEAR Nedir?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## NEAR subgraphları nedir?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Blok işleyicileri: Bunlar her yeni blokta çalışır
+- Makbuz işleyicileri: Belirli bir hesapta her mesaj yürütüldüğünde çalışır
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> Makbuz, sistemdeki eyleme geçirilebilir tek nesnedir. NEAR platformunda "bir işlemin işlenmesinden" bahsettiğimizde, bu nihayetinde bir noktada "makbuzların uygulanması" anlamına gelir.
+
+## NEAR Subgraph'ı Oluşturma
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Bir NEAR subgraph'ı oluşturmak, Ethereum'u indeksleyen bir subgraph oluşturmakla çok benzerdir.
+
+Subgraph tanımının üç yönü vardır:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+Subgraph geliştirme sırasında iki anahtar komut vardır:
+
+```bash
+$ graph codegen # manifest'de tanımlanan şema dosyasından tipleri üretir
+$ graph build # AssemblyScript dosyalarından Web Assembly oluşturur ve tüm subgraph dosyalarını bir /build klasöründe hazırlar
+```
+
+### Subgraph Manifest Tanımı
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # şema dosyasına bağlantı
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # Bu veri kaynağı bu hesabı izleyecektir
+      startBlock: 10662188 # NEAR için gereklidir
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # eşleştirme dosyasındaki fonksiyon adı
+      receiptHandlers:
+        - handler: handleReceipt # eşleştirme dosyasındaki fonksiyon adı
+      file: ./src/mapping.ts # Assemblyscript eşleştirmelerinin bulunduğu dosyaya bağlantı
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR veri kaynakları iki tür işleyiciyi destekler:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Şema Tanımı
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Eşlemeleri
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## NEAR Subgraph'ını Dağıtma
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+Düğüm yapılandırması, subgraph'ın nerede dağıtıldığına bağlı olacaktır.
+
+### Subgraph Stüdyosu
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Yerel Graph Düğümü (varsayılan yapılandırmaya göre)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Subgraph'ınız dağıtıldıktan sonra Graph Düğüme tarafından indekslenecektir. Subgraph'ın kendisini sorgulayarak ilerlemesini kontrol edebilirsiniz:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### NEAR'ı Yerel Graph Düğümü ile İndeksleme
+
+NEAR'ı indeksleyen bir Graph Düğümü çalıştırmanın aşağıdaki operasyonel gereksinimleri vardır:
+
+- Firehose enstrümantasyonu ile NEAR İndeksleyici Çerçevesi
+- NEAR Firehose Bileşen(ler)i
+- Firehose uç noktası yapılandırılmış Graph Düğümü
+
+Yukarıdaki bileşenlerin çalıştırılması hakkında yakında daha fazla bilgi vereceğiz.
+
+## NEAR Subgraph'ını Sorgulama
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Örnek Subgraph'ler
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## SSS
+
+### Beta nasıl çalışır?
+
+NEAR desteği beta aşamasındadır, bu da entegrasyonu geliştirmek için çalışmaya devam ederken API'de değişiklikler olabileceği anlamına gelir. NEAR subgraphları oluştururken size destek olabilmemiz ve en son gelişmelerden sizi haberdar edebilmemiz için lütfen near@thegraph.com adresine e-posta gönderin!
+
+### Bir subgraph hem NEAR hem de EVM zincirlerini indeksleyebilir mi?
+
+Hayır, bir subgraph yalnızca bir zincirden/ağdan veri kaynaklarını destekleyebilir.
+
+### Subgraphlar daha spesifik tetikleyicilere tepki verebilir mi?
+
+Şu anda yalnızca Blok ve Makbuz tetikleyicileri desteklenmektedir. Belirli bir hesaba yapılan fonksiyon çağrıları için tetikleyicileri araştırma aşamasındayız. NEAR yerel olay desteğine sahip oldu takdirde, olay tetikleyicilerini desteklemekle de ilgileneceğiz.
+
+### Makbuz işleyicileri hesaplar ve bunların alt hesapları için tetiklenecek mi?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### NEAR subgraphları eşleştirmeler sırasında NEAR hesaplarına görünüm çağrıları yapabilir mi?
+
+Bu desteklenmemektedir. Bu fonksiyonelliğin indeksleme için gerekli olup olmadığını değerlendiriyoruz.
+
+### NEAR subgraph'ımda veri kaynağı şablonları kullanabilir miyim?
+
+Bu şu anda desteklenmemektedir. Bu fonksiyonelliğin indeksleme için gerekli olup olmadığını değerlendiriyoruz.
+
+### Ethereum subgraphları "beklemedeki" ve "mevcut" sürümleri destekler, bir NEAR subgraph'ının "beklemedeki" sürümünü nasıl dağıtabilirim?
+
+Bekleme fonksiyonelliği henüz NEAR subgraphları için desteklenmemektedir. Bu arada, farklı "adlandırılmış" bir subgraph'a yeni bir sürüm dağıtabilir ve daha sonra bu zincir başı ile senkronize edildiğinde, aynı temel dağıtım ID'sini kullanacak olan birincil "adlandırılmış" subgraph'ınıza yeniden dağıtabilirsiniz. Böylece ana subgraph anında senkronize olur.
+
+### Sorum yanıtlanmadı, NEAR subgraphları oluşturma konusunda nereden daha fazla yardım alabilirim?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## Referanslar
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From f4ec0d920c7a7234addbffe7c6ae839d7abf0c17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:46 -0500
Subject: [PATCH 1587/3820] New translations near.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/near.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/near.mdx b/website/pages/uk/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..a94bd9531fdb
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Building Subgraphs on NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## What is NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## What are NEAR subgraphs?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Block handlers: these are run on every new block
+- Receipt handlers: run every time a message is executed at a specified account
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> A Receipt is the only actionable object in the system. When we talk about "processing a transaction" on the NEAR platform, this eventually means "applying receipts" at some point.
+
+## Building a NEAR Subgraph
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
+
+There are three aspects of subgraph definition:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+During subgraph development there are two key commands:
+
+```bash
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+### Визначення маніфесту підграфів
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR data sources support two types of handlers:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Визначення схеми
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Deploying a NEAR Subgraph
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+The node configuration will depend on where the subgraph is being deployed.
+
+### Субграф Студія
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Local Graph Node (based on default configuration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexing NEAR with a Local Graph Node
+
+Running a Graph Node that indexes NEAR has the following operational requirements:
+
+- NEAR Indexer Framework with Firehose instrumentation
+- NEAR Firehose Component(s)
+- Graph Node with Firehose endpoint configured
+
+We will provide more information on running the above components soon.
+
+## Querying a NEAR Subgraph
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Приклади підграфів
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### How does the beta work?
+
+NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email near@thegraph.com so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can subgraphs react to more specific triggers?
+
+Currently, only Block and Receipt triggers are supported. We are investigating triggers for function calls to a specified account. We are also interested in supporting event triggers, once NEAR has native event support.
+
+### Will receipt handlers trigger for accounts and their sub-accounts?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+
+This is not supported. We are evaluating whether this functionality is required for indexing.
+
+### Can I use data source templates in my NEAR subgraph?
+
+This is not currently supported. We are evaluating whether this functionality is required for indexing.
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+Pending functionality is not yet supported for NEAR subgraphs. In the interim, you can deploy a new version to a different "named" subgraph, and then when that is synced with the chain head, you can redeploy to your primary "named" subgraph, which will use the same underlying deployment ID, so the main subgraph will be instantly synced.
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## References
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From e0072ec03a63003b9dbf795adaf34b60f00b0cb3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:47 -0500
Subject: [PATCH 1588/3820] New translations near.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/near.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/near.mdx b/website/pages/zh/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..d4d431b3db37
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: 在 NEAR 上构建子图
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## NEAR 是什么？
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## NEAR 子图是什么？
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- 区块处理器: 这些处理程序在每个新区块上运行。
+- 收据处理器: 每次在指定账户上一个消息被执行时运行。
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> Receipt 是系统中唯一可操作的对象。 当我们在 NEAR 平台上谈论“处理交易”时，这最终意味着在某个时候“应用收据”。
+
+## 构建 NEAR 子图
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> 构建 NEAR 子图与构建索引以太坊的子图非常相似。
+
+子图定义包括三个方面：
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+在子图开发过程中，有两个关键命令：
+
+```bash
+$ graph codegen # 从清单中标识的模式文件生成类型
+$ graph build # 从 AssemblyScript 文件生成 Web Assembly，并在 /build 文件夹中准备所有子图文件
+```
+
+### 子图清单定义
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR 数据源支持两种类型的处理程序：
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### 模式定义
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript 映射
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## 部署 NEAR 子图
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+节点配置将取决于子图的部署位置。
+
+### 子图工作室
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### 本地Graph节点（基于默认配置）
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+部署子图后，它将由 Graph节点索引。 您可以通过查询子图本身来检查其进度：
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### 使用本地Graph节点索引 NEAR
+
+运行索引 NEAR 的 Graph节点有以下操作要求：
+
+- 带有 Firehose 工具的 NEAR 索引人框架
+- NEAR Firehose 组件
+- 配置了 Firehose 端点的Graph节点
+
+我们将很快提供有关运行上述组件的更多信息。
+
+## 查询 NEAR 子图
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## 示例子图
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## 常见问题
+
+### 测试版是如何工作的？
+
+NEAR 支持处于测试阶段，这意味着随着我们继续致力于改进集成，API 可能会发生变化。 请发送电子邮件至 near@thegraph.com，以便我们支持您构建 NEAR 子图，并让您了解最新进展！
+
+### 子图可以同时索引 NEAR 和 EVM 链吗？
+
+不，子图只能支持来自一个链/网络的数据源。
+
+### 子图可以对更具体的触发器做出反应吗？
+
+目前，仅支持 Block 和 Receipt 触发器。 我们正在调查对指定帐户的函数调用的触发器。 一旦 NEAR 拥有原生事件支持，我们也对支持事件触发器感兴趣。
+
+### 接受处理程序会触发账户及其子账户吗？
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### NEAR 子图可以在映射期间对 NEAR 帐户进行视图调用吗？
+
+这是不支持的。 我们正在评估索引是否需要此功能。
+
+### 我可以在 NEAR 子图中使用数据源模板吗？
+
+目前不支持此功能。 我们正在评估索引是否需要此功能。
+
+### 以太坊子图支持“待定”和“当前”版本，如何部署 NEAR 子图的“待定”版本？
+
+NEAR 子图尚不支持挂起的功能。 在此期间，您可以将新版本部署到不同的“命名”子图，然后当它与链头同步时，您可以重新部署到您的主“命名”子图，它将使用相同的底层部署 ID，所以 主子图将立即同步。
+
+### 我的问题尚未得到解答，在哪里可以获得更多构建 NEAR 子图的帮助？
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## 参考
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From e51abe11335e2425a479718421f7d0d34c1b32f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:48 -0500
Subject: [PATCH 1589/3820] New translations near.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/near.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/near.mdx b/website/pages/ur/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..3ff637ebf556
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: سب گرافس کو NEAR پر بنانا
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## NEAR کیا ہے؟
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## NEAR سب گراف کیا ہیں؟
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- بلاک ہینڈلرز: یہ ہر نۓ بلاک پر چلتے ہیں
+- ریسیپٹ ہینڈلرز: ہر بار جب کسی مخصوص اکاؤنٹ پر کوئی پیغام عمل میں آۓ تو چلتا ہے
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> نظام میں ایک ریسیپٹ واحد قابل عمل شے ہے۔ جب ہم NEAR پلیٹ فارم پر "ایک ٹرانزیکشن پر کارروائی" کے بارے میں بات کرتے ہیں، تو اس کا مطلب بالآخر کسی وقت "ریسیپٹ لگانا" ہوتا ہے.
+
+## NEAR سب گراف بنانا
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> NEAR سب گراف کی تعمیر ایک سب گراف بنانے کے مترادف ہے جو ایتھریم کو انڈیکس کرتا ہے.
+
+سب گراف کی تعریف کے تین پہلو ہیں:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+سب گراف کی ترقی کے دوران دو اہم کمانڈز ہیں:
+
+```bash
+$graph codegen # ظاہر میں شناخت کردہ اسکیما فائل سے اقسام تیار کرتا ہے۔
+$graph build # اسمبلی سکرپٹ فائلوں سے ویب اسمبلی تیار کرتا ہے، اور تمام ذیلی گراف فائلوں کو /build فولڈر میں تیار کرتا ہے۔
+```
+
+### سب گراف مینی فیسٹ کی تعریف
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+قریبی ڈیٹا ذرائع دو قسم کے ہینڈلرز کی حمایت کرتے ہیں:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### اسکیما کی تعریف
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### اسمبلی اسکرپٹ سب میپنک
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## NEAR سب گراف کی تعیناتی
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+نوڈ کنفیگریشن کا انحصار اس بات پر ہوگا کہ سب گراف کہاں تعینات کیا جا رہا ہے.
+
+### سب گراف سٹوڈیو
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### مقامی گراف نوڈ (پہلے سے طے شدہ ترتیب پر مبنی)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+ایک دفعہ آپ کا سب گراف تعینات ہو جاۓ، گراف نوڈ اسے انڈیکس کرے گا. آپ سب گراف سے ہی کیوری کرکے اس کی پیشرفت چیک کرسکتے ہیں:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### NEAR کو مقامی گراف نوڈ سے انڈیکس کرنا
+
+ایک گراف نوڈ چلانا جو NEAR کو انڈیکس کرتا ہے اس کے لیے درج ذیل آپریشنل تقاضے ہوتے ہیں:
+
+- فائر ہوز انسٹرومینٹیشن کے ساتھ NEAR انڈیکسر فریم ورک
+- NEAR فائر ہوز اجزاء
+- فائر ہوز اینڈ پوائنٹ کے ساتھ گراف نوڈ کنفیگر ہو گیا
+
+ہم جلد ہی مندرجہ بالا اجزاء کو چلانے کے بارے میں مزید معلومات فراہم کریں گے.
+
+## NEAR سب گراف کا کیوری کرنا
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## سب گراف کی مثال
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### بیٹا کیسے کام کرتا ہے؟
+
+NEAR سپورٹ بیٹا میں ہے، جس کا مطلب ہے کہ API میں تبدیلیاں ہو سکتی ہیں کیونکہ ہم انضمام کو بہتر بنانے پر کام جاری رکھے ہوئے ہیں۔ براہ کرم near@thegraph.com پر ای میل کریں تاکہ ہم NEAR سب گراف بنانے میں آپ کی مدد کر سکیں، اور آپ کو تازہ ترین پیش رفت سے آگاہ رکھ سکیں!
+
+### کیا ایک سب گراف دونو NEAR اور EVM چینز کو انڈیکس ہو سکتا ہے؟
+
+نہیں، ایک سب گراف صرف ایک چین/نیٹ ورک سے ڈیٹا کے ذرائع کو سپورٹ کر سکتا ہے.
+
+### کیا سب گراف زیادہ مخصوص محرکات پر ردعمل ظاہر کر سکتے ہیں؟
+
+فی الحال، صرف بلاک اور رسید کے محرکات تعاون یافتہ ہیں۔ ہم ایک مخصوص اکاؤنٹ پر فنکشن کالز کے محرکات کی چھان بین کر رہے ہیں۔ ہم ایونٹ کے محرکات کو سپورٹ کرنے میں بھی دلچسپی رکھتے ہیں، ایک بار جب NEAR کو مقامی ایونٹ سپورٹ مل جائے.
+
+### کیا رسید ہینڈلرز اکاؤنٹس اور ان کے سب اکاؤنٹس کو متحرک کریں گے؟
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### کیا میپنگ کے دوران NEAR سب گرافس NEAR اکاؤنٹس کو ویو کال کر سکتے ہیں؟
+
+یہ تعاون یافتہ نہیں ہے۔ ہم اس بات کا جائزہ لے رہے ہیں کہ آیا یہ فعالیت انڈیکسنگ کے لیے درکار ہے.
+
+### کیا میں اپنے NEAR سب گراف میں ڈیٹا سورس ٹیمپلیٹس استعمال کر سکتا ہوں؟
+
+یہ فی الحال تعاون یافتہ نہیں ہے۔ ہم اس بات کا جائزہ لے رہے ہیں کہ آیا یہ فعالیت اشاریہ سازی کے لیے درکار ہے.
+
+### ایتھیریم سب گرافس "پینڈنگ" اور "موجودہ" ورژن کی حمایت کرتے ہیں، میں NEAR سب گراف کے "پینڈنگ" ورژن کو کیسے تعینات کر سکتا ہوں؟
+
+زیر التواء فعالیت ابھی تک NEAR سب گراف کے لیے تعاون یافتہ نہیں ہے۔ عبوری طور پر، آپ ایک نئے ورژن کو ایک مختلف "نام والے" سب گراف میں تعینات کر سکتے ہیں، اور پھر جب وہ چین ہیڈ کے ساتھ مطابقت پذیر ہو جاتا ہے، تو آپ اپنے بنیادی "نام والے" سب گراف پر دوبارہ تعینات کر سکتے ہیں، جو اسی بنیادی تعیناتی ID کو استعمال کرے گا، لہذا مرکزی سب گراف کو فوری طور پر ہم آہنگ کیا جائے گا.
+
+### میرے سوال کا جواب نہیں دیا گیا ہے، مجھے NEAR سب گراف بنانے میں مزید مدد کہاں سے مل سکتی ہے؟
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## حوالہ جات
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 19dda89d43fd30155af249a1beadb25cc8b2d6c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:49 -0500
Subject: [PATCH 1590/3820] New translations near.mdx (Vietnamese)

---
 website/pages/vi/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/near.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/near.mdx b/website/pages/vi/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..f1d49d720590
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Building Subgraphs on NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## What is NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## What are NEAR subgraphs?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Block handlers: these are run on every new block
+- Receipt handlers: run every time a message is executed at a specified account
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> A Receipt is the only actionable object in the system. When we talk about "processing a transaction" on the NEAR platform, this eventually means "applying receipts" at some point.
+
+## Building a NEAR Subgraph
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
+
+There are three aspects of subgraph definition:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+During subgraph development there are two key commands:
+
+```bash
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR data sources support two types of handlers:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Deploying a NEAR Subgraph
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+The node configuration will depend on where the subgraph is being deployed.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Local Graph Node (based on default configuration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexing NEAR with a Local Graph Node
+
+Running a Graph Node that indexes NEAR has the following operational requirements:
+
+- NEAR Indexer Framework with Firehose instrumentation
+- NEAR Firehose Component(s)
+- Graph Node with Firehose endpoint configured
+
+We will provide more information on running the above components soon.
+
+## Querying a NEAR Subgraph
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## CÂU HỎI THƯỜNG GẶP
+
+### How does the beta work?
+
+NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email near@thegraph.com so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can subgraphs react to more specific triggers?
+
+Currently, only Block and Receipt triggers are supported. We are investigating triggers for function calls to a specified account. We are also interested in supporting event triggers, once NEAR has native event support.
+
+### Will receipt handlers trigger for accounts and their sub-accounts?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+
+This is not supported. We are evaluating whether this functionality is required for indexing.
+
+### Can I use data source templates in my NEAR subgraph?
+
+This is not currently supported. We are evaluating whether this functionality is required for indexing.
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+Pending functionality is not yet supported for NEAR subgraphs. In the interim, you can deploy a new version to a different "named" subgraph, and then when that is synced with the chain head, you can redeploy to your primary "named" subgraph, which will use the same underlying deployment ID, so the main subgraph will be instantly synced.
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## References
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 9c5f55ccab8238999a3234e50fcd33349a687f75 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:50 -0500
Subject: [PATCH 1591/3820] New translations near.mdx (Marathi)

---
 website/pages/mr/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/near.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/near.mdx b/website/pages/mr/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..6e790fdcb0cf
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: NEAR वर सबग्राफ तयार करणे
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## जवळ म्हणजे काय?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## NEAR subgraphs म्हणजे काय?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- ब्लॉक हँडलर: हे प्रत्येक नवीन ब्लॉकवर चालवले जातात
+- पावती हँडलर्स: निर्दिष्ट खात्यावर संदेश कार्यान्वित झाल्यावर प्रत्येक वेळी चालवा
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> प्रणालीमध्ये पावती ही एकमेव क्रिया करण्यायोग्य वस्तू आहे. जेव्हा आम्ही जवळच्या प्लॅटफॉर्मवर "व्यवहारावर प्रक्रिया करणे" बद्दल बोलतो, तेव्हा याचा अर्थ शेवटी "पावत्या लागू करणे" असा होतो.
+
+## एक NEAR सबग्राफतयार करणे
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> NEAR सबग्राफ तयार करणे, याची प्रक्रिया इथेरियमवरील सबग्राफ तयार करण्याशी खूप सामान्यतेने सादर करते.
+
+सबग्राफ व्याख्येचे तीन पैलू आहेत:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+सबग्राफ विकासादरम्यान दोन प्रमुख आज्ञा आहेत:
+
+```bash
+$ graph codegen # मॅनिफेस्टमध्ये ओळखल्या गेलेल्या स्कीमा फाइलमधून प्रकार व्युत्पन्न करते
+$ graph build # असेंबलीस्क्रिप्ट फायलींमधून वेब असेंब्ली तयार करते आणि /बिल्ड फोल्डरमध्ये सर्व सबग्राफ फाइल्स तयार करते
+```
+
+### सबग्राफ मॅनिफेस्ट व्याख्या
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+जवळील डेटा स्रोत दोन प्रकारच्या हँडलरला समर्थन देतात:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### स्कीमा व्याख्या
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### असेंबलीस्क्रिप्ट मॅपिंग
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## NEAR सबग्राफ डिप्लॉय करण्यासाठी
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+नोड कॉन्फिगरेशन सबग्राफ कोठे तैनात केले जात आहे यावर अवलंबून असेल.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### स्थानिक आलेख नोड (डीफॉल्ट कॉन्फिगरेशनवर आधारित)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+एकदा तुमचा सबग्राफ तैनात केला गेला की, तो ग्राफ नोडद्वारे अनुक्रमित केला जाईल. तुम्ही सबग्राफवरच क्वेरी करून त्याची प्रगती तपासू शकता:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### स्थानिक ग्राफ नोडशी NEAR चे सूचीकरण करणे
+
+NEAR ची अनुक्रमणिका देणारा आलेख नोड चालवण्यासाठी खालील ऑपरेशनल आवश्यकता आहेत:
+
+- फायरहोस इंस्ट्रुमेंटेशनसह इंडेक्सर फ्रेमवर्क जवळ
+- NEAR फायरहोज घटकाज(वळ)
+- फायरहोस एंडपॉइंटसह आलेख नोड कॉन्फिगर केले आहे
+
+वरील घटक चालवण्याबाबत आम्ही लवकरच अधिक माहिती देऊ.
+
+## NEAR सबग्राफची क्वेरी करणे
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## उदाहरणे सबग्राफ
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### बीटा कसे कार्य करते?
+
+NEAR सपोर्ट बीटामध्ये आहे, याचा अर्थ असा की API मध्ये बदल होऊ शकतात कारण आम्ही एकत्रीकरण सुधारण्यासाठी काम करत आहोत. कृपया near@thegraph.com वर ईमेल करा जेणेकरुन आम्‍ही तुम्‍हाला जवळचे सबग्राफ तयार करण्‍यात मदत करू शकू आणि तुम्‍हाला नवीनतम घडामोडींबद्दल अद्ययावत ठेवू शकू!
+
+### सबग्राफ इंडेक्स NEAR आणि EVM दोन्ही चेन करू शकतो का?
+
+नाही, सबग्राफ केवळ एका साखळी/नेटवर्कमधील डेटा स्रोतांना समर्थन देऊ शकतो.
+
+### सबग्राफ अधिक विशिष्ट ट्रिगरवर प्रतिक्रिया देऊ शकतात?
+
+सध्या, फक्त ब्लॉक आणि पावती ट्रिगर समर्थित आहेत. आम्ही एका निर्दिष्ट खात्यावर फंक्शन कॉलसाठी ट्रिगर तपासत आहोत. आम्‍हाला इव्‍हेंट ट्रिगरला सपोर्ट करण्‍यात देखील रस आहे, एकदा NEAR ला नेटिव्ह इव्‍हेंट सपोर्ट असेल.
+
+### पावती हँडलर खाती आणि त्यांच्या उप-खात्यांसाठी ट्रिगर करतील का?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### मॅपिंग दरम्यान NEAR subgraphs NEAR खात्यांना व्ह्यू कॉल करू शकतात?
+
+हे समर्थित नाही. अनुक्रमणिकेसाठी ही कार्यक्षमता आवश्यक आहे का याचे आम्ही मूल्यमापन करत आहोत.
+
+### NEARのサブグラフでデータソーステンプレートを使用できますか?
+
+हे सध्या समर्थित नाही. अनुक्रमणिकेसाठी ही कार्यक्षमता आवश्यक आहे का याचे आम्ही मूल्यमापन करत आहोत.
+
+### イーサリアムのサブグラフでは、「pending」および「current」のバージョンがサポートされていますが、NEARのサブグラフの「pending」バージョンをどのようにデプロイできるでしょうか?
+
+NEARサブグラフの「保留中」機能はまだサポートされていません。その間、異なる「名前付き」サブグラフに新しいバージョンをデプロイし、それがチェーンヘッドと同期された後、主要な「名前付き」サブグラフに再デプロイすることができます。この場合、同じ基礎となるデプロイメントIDを使用するため、メインのサブグラフは即座に同期されます.
+
+### माझा प्रश्न उत्तर दिला नाही, NEAR सबग्राफ तयार करण्यासाठी अधिक मदत कुठे मिळेल?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## संदर्भ
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From a9b230ac4ab39719bd76e03d3d868ee084ea589d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:51 -0500
Subject: [PATCH 1592/3820] New translations near.mdx (Hindi)

---
 website/pages/hi/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/near.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/near.mdx b/website/pages/hi/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..e1312d32879d
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: NEAR पर सबग्राफ बनाना
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## NEAR क्या है?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## NEAR सबग्राफ क्या हैं?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- ब्लॉक हैंडलर्स: ये हर नए ब्लॉक पर चलते हैं
+- रसीद हैंडलर: किसी निर्दिष्ट खाते पर संदेश निष्पादित होने पर हर बार चलें
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> रसीद सिस्टम में एकमात्र कार्रवाई योग्य वस्तु है। जब हम NEAR प्लेटफॉर्म पर "एक लेन-देन को संसाधित करने" के बारे में बात करते हैं, तो अंततः इसका अर्थ किसी बिंदु पर "रसीदें लागू करना" होता है।
+
+## NEAR सबग्राफ बनाना
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> NEAR सबग्राफ का निर्माण वह सबग्राफ के निर्माण के समान है जो एथेरियम को अनुक्रमित करता है।
+
+सबग्राफ परिभाषा के तीन पहलू हैं:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+सब ग्राफ को बनाते वक़्त दो मुख्य कमांड हैं:
+
+```bash
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+### सब ग्राफ मैनिफेस्ट की परिभाषा
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR डेटा स्रोत दो प्रकार के हैंडलर का समर्थन करते हैं:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### स्कीमा की परिभाषा
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### असेंबली स्क्रिप्ट मैप्पिंग्स
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## एक NEAR सबग्राफ की तैनाती
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+नोड कॉन्फ़िगरेशन इस बात पर निर्भर करेगा कि सबग्राफ को कहाँ तैनात किया जा रहा है।
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### स्थानीय ग्राफ़ नोड (डिफ़ॉल्ट कॉन्फ़िगरेशन पर आधारित)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+एक बार आपका सबग्राफ तैनात हो जाने के बाद, इसे ग्राफ़ नोड द्वारा अनुक्रमित किया जाएगा। आप सबग्राफ को क्वेरी करके इसकी प्रगति की जांच कर सकते हैं:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### एक स्थानीय ग्राफ़ नोड के साथ NEAR को अनुक्रमणित करना
+
+NEAR को अनुक्रमित करने वाले ग्राफ़ नोड को चलाने के लिए निम्नलिखित परिचालन आवश्यकताएँ हैं:
+
+- Firehose इंस्ट्रूमेंटेशन के साथ NEAR इंडेक्सर फ्रेमवर्क
+- NEAR Firehose कंपोनेंट्(स)
+- Firehose एंडपॉइन्ट के साथ ग्राफ़ नोड कॉन्फ़िगर किया गया
+
+हम जल्द ही उपरोक्त कंपोनेंट्स को चलाने के बारे में और जानकारी प्रदान करेंगे।
+
+## NEAR सबग्राफ को क्वेरी करना
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## सब-ग्राफ के उदाहरण
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## सामान्य प्रश्न
+
+### बीटा कैसे काम करता है?
+
+NEAR समर्थन बीटा में है, जिसका मतलब है कि एपीआई में बदलाव हो सकते हैं क्योंकि हम इंटीग्रेशन में सुधार पर काम करना जारी रखेंगे। कृपया near@thegraph.com पर ईमेल करें ताकि हम NEAR सबग्राफ बनाने में आपकी सहायता कर सकें, और आपको नवीनतम विकासों के बारे में अपडेट रख सकें!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+नहीं, एक सब-ग्राफ केवल एक चेन/नेटवर्क से डाटा सोर्स को सपोर्ट कर सकता है
+
+### क्या सबग्राफ अधिक विशिष्ट ट्रिगर्स पर प्रतिक्रिया कर सकते हैं?
+
+वर्तमान में, केवल अवरोधित करें और प्राप्त करें ट्रिगर समर्थित हैं। हम एक निर्दिष्ट खाते में फ़ंक्शन कॉल के लिए ट्रिगर्स की जांच कर रहे हैं। एक बार जब NEAR को नेटिव ईवेंट समर्थन मिल जाता है, तो हम ईवेंट ट्रिगर्स का समर्थन करने में भी रुचि रखते हैं।
+
+### क्या रसीद हैंडलर खातों और उनके उप-खातों के लिए ट्रिगर करेंगे?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### क्या मैपिंग के दौरान NEAR सबग्राफ, NEAR खातों को व्यू कॉल कर सकते हैं?
+
+यह समर्थित नहीं है। हम मूल्यांकन कर रहे हैं कि अनुक्रमण के लिए यह कार्यक्षमता आवश्यक है या नहीं।
+
+### क्या मैं अपने NEAR सबग्राफ में डेटा स्रोत टेम्प्लेट का उपयोग कर सकता हूँ?
+
+यह वर्तमान में समर्थित नहीं है। हम मूल्यांकन कर रहे हैं कि अनुक्रमण के लिए यह कार्यक्षमता आवश्यक है या नहीं।
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+NEAR सबग्राफ के लिए पेंडिंग कार्यक्षमता अभी तक समर्थित नहीं है। अंतरिम में, आप एक अलग "नामित" सबग्राफ के लिए एक नया संस्करण तैनात कर सकते हैं, और फिर जब वह चेन हेड के साथ सिंक हो जाता है, तो आप अपने प्राथमिक "नामित" सबग्राफ में फिर से तैनात कर सकते हैं, जो उसी अंतर्निहित डेप्लॉयमेंट आईडी का उपयोग करेगा, इसलिए मुख्य सबग्राफ तुरंत सिंक हो जाएगा।
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## संदर्भ
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 750efa7af754dd94bca70e24a08218bf4d9d7fdd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:52 -0500
Subject: [PATCH 1593/3820] New translations near.mdx (Swahili)

---
 website/pages/sw/subgraphs/cookbook/near.mdx | 283 +++++++++++++++++++
 1 file changed, 283 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/near.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/near.mdx b/website/pages/sw/subgraphs/cookbook/near.mdx
new file mode 100644
index 000000000000..6060eb27e761
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/near.mdx
@@ -0,0 +1,283 @@
+---
+title: Building Subgraphs on NEAR
+---
+
+This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+
+## What is NEAR?
+
+[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+
+## What are NEAR subgraphs?
+
+The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+
+Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+
+- Block handlers: these are run on every new block
+- Receipt handlers: run every time a message is executed at a specified account
+
+[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+
+> A Receipt is the only actionable object in the system. When we talk about "processing a transaction" on the NEAR platform, this eventually means "applying receipts" at some point.
+
+## Building a NEAR Subgraph
+
+`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+
+`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+
+NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+
+> Building a NEAR subgraph is very similar to building a subgraph that indexes Ethereum.
+
+There are three aspects of subgraph definition:
+
+**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+
+**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+
+**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+
+During subgraph development there are two key commands:
+
+```bash
+$ graph codegen # generates types from the schema file identified in the manifest
+$ graph build # generates Web Assembly from the AssemblyScript files, and prepares all the subgraph files in a /build folder
+```
+
+### Subgraph Manifest Definition
+
+The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+
+```yaml
+specVersion: 0.0.2
+schema:
+  file: ./src/schema.graphql # link to the schema file
+dataSources:
+  - kind: near
+    network: near-mainnet
+    source:
+      account: app.good-morning.near # This data source will monitor this account
+      startBlock: 10662188 # Required for NEAR
+    mapping:
+      apiVersion: 0.0.5
+      language: wasm/assemblyscript
+      blockHandlers:
+        - handler: handleNewBlock # the function name in the mapping file
+      receiptHandlers:
+        - handler: handleReceipt # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
+```
+
+- NEAR subgraphs introduce a new `kind` of data source (`near`)
+- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+
+```yaml
+accounts:
+  prefixes:
+    - app
+    - good
+  suffixes:
+    - morning.near
+    - morning.testnet
+```
+
+NEAR data sources support two types of handlers:
+
+- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+
+### Schema Definition
+
+Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+
+### AssemblyScript Mappings
+
+The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+
+NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+
+```typescript
+
+class ExecutionOutcome {
+      gasBurnt: u64,
+      blockHash: Bytes,
+      id: Bytes,
+      logs: Array<string>,
+      receiptIds: Array<Bytes>,
+      tokensBurnt: BigInt,
+      executorId: string,
+  }
+
+class ActionReceipt {
+      predecessorId: string,
+      receiverId: string,
+      id: CryptoHash,
+      signerId: string,
+      gasPrice: BigInt,
+      outputDataReceivers: Array<DataReceiver>,
+      inputDataIds: Array<CryptoHash>,
+      actions: Array<ActionValue>,
+  }
+
+class BlockHeader {
+      height: u64,
+      prevHeight: u64,// Always zero when version < V3
+      epochId: Bytes,
+      nextEpochId: Bytes,
+      chunksIncluded: u64,
+      hash: Bytes,
+      prevHash: Bytes,
+      timestampNanosec: u64,
+      randomValue: Bytes,
+      gasPrice: BigInt,
+      totalSupply: BigInt,
+      latestProtocolVersion: u32,
+  }
+
+class ChunkHeader {
+      gasUsed: u64,
+      gasLimit: u64,
+      shardId: u64,
+      chunkHash: Bytes,
+      prevBlockHash: Bytes,
+      balanceBurnt: BigInt,
+  }
+
+class Block {
+      author: string,
+      header: BlockHeader,
+      chunks: Array<ChunkHeader>,
+  }
+
+class ReceiptWithOutcome {
+      outcome: ExecutionOutcome,
+      receipt: ActionReceipt,
+      block: Block,
+  }
+```
+
+These types are passed to block & receipt handlers:
+
+- Block handlers will receive a `Block`
+- Receipt handlers will receive a `ReceiptWithOutcome`
+
+Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+
+This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+
+## Deploying a NEAR Subgraph
+
+Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+
+Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+
+- `near-mainnet`
+- `near-testnet`
+
+More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+
+As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+
+Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+
+```sh
+$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+```
+
+The node configuration will depend on where the subgraph is being deployed.
+
+### Subgraph Studio
+
+```sh
+graph auth
+graph deploy <subgraph-name>
+```
+
+### Local Graph Node (based on default configuration)
+
+```sh
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+```
+
+Once your subgraph has been deployed, it will be indexed by Graph Node. You can check its progress by querying the subgraph itself:
+
+```graphql
+{
+  _meta {
+    block {
+      number
+    }
+  }
+}
+```
+
+### Indexing NEAR with a Local Graph Node
+
+Running a Graph Node that indexes NEAR has the following operational requirements:
+
+- NEAR Indexer Framework with Firehose instrumentation
+- NEAR Firehose Component(s)
+- Graph Node with Firehose endpoint configured
+
+We will provide more information on running the above components soon.
+
+## Querying a NEAR Subgraph
+
+The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+
+## Example Subgraphs
+
+Here are some example subgraphs for reference:
+
+[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+
+[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+
+## FAQ
+
+### How does the beta work?
+
+NEAR support is in beta, which means that there may be changes to the API as we continue to work on improving the integration. Please email near@thegraph.com so that we can support you in building NEAR subgraphs, and keep you up to date on the latest developments!
+
+### Can a subgraph index both NEAR and EVM chains?
+
+No, a subgraph can only support data sources from one chain/network.
+
+### Can subgraphs react to more specific triggers?
+
+Currently, only Block and Receipt triggers are supported. We are investigating triggers for function calls to a specified account. We are also interested in supporting event triggers, once NEAR has native event support.
+
+### Will receipt handlers trigger for accounts and their sub-accounts?
+
+If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+
+```yaml
+accounts:
+  suffixes:
+    - mintbase1.near
+```
+
+### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+
+This is not supported. We are evaluating whether this functionality is required for indexing.
+
+### Can I use data source templates in my NEAR subgraph?
+
+This is not currently supported. We are evaluating whether this functionality is required for indexing.
+
+### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+
+Pending functionality is not yet supported for NEAR subgraphs. In the interim, you can deploy a new version to a different "named" subgraph, and then when that is synced with the chain head, you can redeploy to your primary "named" subgraph, which will use the same underlying deployment ID, so the main subgraph will be instantly synced.
+
+### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+
+If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+
+## References
+
+- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 940025c6d99888d9b08f74967f08e3204ca47337 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:53 -0500
Subject: [PATCH 1594/3820] New translations pruning.mdx (Romanian)

---
 .../pages/ro/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/pruning.mdx b/website/pages/ro/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 6d92207deab6988f758583f337680d110c61fd78 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:54 -0500
Subject: [PATCH 1595/3820] New translations pruning.mdx (French)

---
 .../pages/fr/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/pruning.mdx b/website/pages/fr/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..352de8a9f1d0
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Meilleure Pratique Subgraph 1 - Améliorer la Vitesse des Requêtes avec le Pruning de Subgraph
+---
+
+## TLDR
+
+[Le pruning](/developing/creating-a-subgraph/#prune) (élagage) retire les entités archivées de la base de données des subgraphs jusqu'à un bloc donné, et retirer les entités inutilisées de la base de données d'un subgraph améliorera souvent de manière spectaculaire les performances de requête d'un subgraph. L'utilisation de `indexerHints` est un moyen simple de réaliser le pruning d'un subgraph.
+
+## Comment effectuer le Pruning d'un subgraph avec `indexerHints`
+
+Ajoutez une section appelée `indexerHints` dans le manifest.
+
+`indexerHints` dispose de trois options de `prune` :
+
+- `prune: auto`: Conserve l'historique minimum nécessaire tel que défini par l'Indexeur, optimisant ainsi les performances des requêtes. C'est le paramètre généralement recommandé et celui par défaut pour tous les subgraphs créés par `graph-cli` >= 0.66.0.
+- `prune: <Nombre de blocs à conserver>`: Définit une limite personnalisée sur le nombre de blocs historiques à conserver.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+Nous pouvons ajouter `indexerHints` à nos subgraphs en mettant à jour notre `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Points Importants
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+L'élagage en utilisant `indexerHints` est une meilleure bonne pour le développement de subgraphs, offrant des améliorations significatives des performances des requêtes.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 50b9365cf3d55b1b5c834dbf2a8214c2c3ffe441 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:56 -0500
Subject: [PATCH 1596/3820] New translations pruning.mdx (Spanish)

---
 .../pages/es/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/es/subgraphs/cookbook/pruning.mdx b/website/pages/es/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 357e6f3cc9d9219c21ff15e35538bd9a9888e3da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:57 -0500
Subject: [PATCH 1597/3820] New translations pruning.mdx (Arabic)

---
 .../pages/ar/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/pruning.mdx b/website/pages/ar/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 18540eff2850e5e78f07f6de893c3bd70e25b534 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:58 -0500
Subject: [PATCH 1598/3820] New translations pruning.mdx (Czech)

---
 .../pages/cs/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/pruning.mdx b/website/pages/cs/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..9b4d7133f5b2
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Doporučený postup 1 - Zlepšení rychlosti dotazu pomocí ořezávání podgrafů
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) odstraní archivní entity z databáze podgrafu až do daného bloku a odstranění nepoužívaných entit z databáze podgrafu zlepší výkonnost dotazu podgrafu, často výrazně. Použití `indexerHints` je snadný způsob, jak podgraf ořezat.
+
+## Jak prořezat podgraf pomocí `indexerHints`
+
+Přidejte do manifestu sekci `indexerHints`.
+
+`indexerHints` má tři možnosti `prune`:
+
+- `prune: auto`: Udržuje minimální potřebnou historii nastavenou indexátorem, čímž optimalizuje výkon dotazu. Toto je obecně doporučené nastavení a je výchozí pro všechny podgrafy vytvořené pomocí `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Nastaví vlastní omezení počtu historických bloků, které se mají zachovat.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+Aktualizací souboru `subgraph.yaml` můžeme do podgrafů přidat `indexerHints`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Důležité úvahy
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Závěr
+
+Ořezávání pomocí `indexerHints` je osvědčeným postupem pro vývoj podgrafů, který nabízí významné zlepšení výkonu dotazů.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From cff5f7755b03f2bc076bf9297033154d75c3f878 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:12:59 -0500
Subject: [PATCH 1599/3820] New translations pruning.mdx (German)

---
 .../pages/de/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/de/subgraphs/cookbook/pruning.mdx b/website/pages/de/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 651caf4caa2c28ca1b2ab23120119634b408b97a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:00 -0500
Subject: [PATCH 1600/3820] New translations pruning.mdx (Italian)

---
 .../pages/it/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/it/subgraphs/cookbook/pruning.mdx b/website/pages/it/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 0c89d73dff84231b4c8a31248c1f9438a8ae46da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:01 -0500
Subject: [PATCH 1601/3820] New translations pruning.mdx (Japanese)

---
 .../pages/ja/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/pruning.mdx b/website/pages/ja/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 28b17553239354c222901ae9c7d6f164352ce850 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:02 -0500
Subject: [PATCH 1602/3820] New translations pruning.mdx (Korean)

---
 .../pages/ko/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/pruning.mdx b/website/pages/ko/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From e3ea155305b4128694d27654612c170f1e78694a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:04 -0500
Subject: [PATCH 1603/3820] New translations pruning.mdx (Dutch)

---
 .../pages/nl/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/pruning.mdx b/website/pages/nl/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 7d5fd64a7a5f7d764e2ec3089fc71dc3eff0b069 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:05 -0500
Subject: [PATCH 1604/3820] New translations pruning.mdx (Polish)

---
 .../pages/pl/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/pruning.mdx b/website/pages/pl/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 876bd3f2c5ed8bc415226a8e70dadeb898feb7c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:06 -0500
Subject: [PATCH 1605/3820] New translations pruning.mdx (Portuguese)

---
 .../pages/pt/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/pruning.mdx b/website/pages/pt/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..ea95a8663387
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Boas Práticas de Subgraph 1 - Acelerar Queries com Pruning
+---
+
+## TLDR
+
+O [pruning](/developing/creating-a-subgraph/#prune) retira entidades de arquivo do banco de dados de um subgraph até um bloco especificado; e retirar entidades não usadas do banco de dados de um subgraph tende a melhorar muito o desempenho de queries de um subgraph. Usar o `indexerHints` é uma maneira fácil de fazer o pruning de um subgraph.
+
+## Como Fazer Pruning de um Subgraph com `indexerHints`
+
+Adicione uma secção chamada `indexerHints` ao manifest.
+
+O `indexerHints` tem três opções de `prune`:
+
+- `prune: auto`: Guarda o histórico mínimo necessário, conforme configurado pelo Indexador, para otimizar o desempenho dos queries. Esta é a configuração geralmente recomendada e é padrão para todos os subgraphs criados pela `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Determina um limite personalizado no número de blocos históricos a serem retidos.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+Podemos adicionar `indexerHints` aos nossos subgraphs ao atualizar o nosso `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Considerações Importantes
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusão
+
+O pruning com `indexerHints` é uma boa prática para o desenvolvimento de subgraphs que oferece melhorias significativas no desempenho de queries.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 83a504ead76bc588c36a66f42488c2fe8e3c3a27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:07 -0500
Subject: [PATCH 1606/3820] New translations pruning.mdx (Russian)

---
 .../pages/ru/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/pruning.mdx b/website/pages/ru/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..42775eb9f7fe
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## Краткое содержание
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Заключение
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 8ed683ba5a3dff6634bcfef728a5b6d823ec3d06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:08 -0500
Subject: [PATCH 1607/3820] New translations pruning.mdx (Swedish)

---
 .../pages/sv/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/pruning.mdx b/website/pages/sv/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 482c0b4c90cbc9a15c32c4723808c3c58d7b6ddc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:09 -0500
Subject: [PATCH 1608/3820] New translations pruning.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/pruning.mdx b/website/pages/tr/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 6266acdafbec9858ae7d9d72475dd873719fbd33 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:10 -0500
Subject: [PATCH 1609/3820] New translations pruning.mdx (Ukrainian)

---
 .../pages/uk/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/pruning.mdx b/website/pages/uk/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 6b2caff93f5ec65c8a243e7f8f78b3d0ec4fdc6f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:12 -0500
Subject: [PATCH 1610/3820] New translations pruning.mdx (Chinese Simplified)

---
 .../pages/zh/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/pruning.mdx b/website/pages/zh/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 8c0c387bbc53d76b4d86d0307f67ed0277cb1bbf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:13 -0500
Subject: [PATCH 1611/3820] New translations pruning.mdx (Urdu (Pakistan))

---
 .../pages/ur/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/pruning.mdx b/website/pages/ur/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From bf5922ef3d397f79eb18ad0d002446a0bcb66c31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:14 -0500
Subject: [PATCH 1612/3820] New translations pruning.mdx (Vietnamese)

---
 .../pages/vi/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/pruning.mdx b/website/pages/vi/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 7ebc506ce1992c8efa8475faafb72593668fc38e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:15 -0500
Subject: [PATCH 1613/3820] New translations pruning.mdx (Marathi)

---
 .../pages/mr/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/pruning.mdx b/website/pages/mr/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 9fd5237f18c5b14c9b1ddbbc72d9fc88b192d2e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:16 -0500
Subject: [PATCH 1614/3820] New translations pruning.mdx (Hindi)

---
 .../pages/hi/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/pruning.mdx b/website/pages/hi/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..25564734c2d1
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: सबग्राफ बेस्ट प्रैक्टिस 1 - सबग्राफ प्रूनिंग के साथ क्वेरी की गति में सुधार करें
+---
+
+## TLDR
+
+Pruning(/developing/creating-a-subgraph/#prune), subgraph के डेटाबेस से दिए गए ब्लॉक तक की archival entities को हटाता है, और unused entities को subgraph के डेटाबेस से हटाने से subgraph की query performance में सुधार होगा, अक्सर काफी हद तक। indexerHints का उपयोग करना subgraph को prune करने का एक आसान तरीका है।
+
+## IndexerHints के साथ subgraph को prune करने का तरीका
+
+Manifest में एक section को indexerHints के नाम से जोड़ें।
+
+indexerHints में तीन prune विकल्प होते हैं:
+
+- prune: auto: आवश्यक न्यूनतम इतिहास को बनाए रखता है जैसा कि Indexer द्वारा निर्धारित किया गया है, जो क्वेरी प्रदर्शन को अनुकूलित करता है। यह सामान्यतः अनुशंसित सेटिंग है और यह सभी subgraphs के लिए डिफ़ॉल्ट है जो graph-cli >= 0.66.0 द्वारा बनाए गए हैं।
+- `prune: <Number of blocks to retain>`: ऐतिहासिक ब्लॉकों को बनाए रखने की संख्या पर एक कस्टम सीमा निर्धारित करता है।
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+हम अपने 'subgraph' में indexerHints जोड़ सकते हैं हमारे subgraph.yaml को अपडेट करके:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## महत्वपूर्ण विचार
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## निष्कर्ष
+
+Pruning का उपयोग indexerHints से करना एक सर्वोत्तम प्रथा है subgraph विकास के लिए, जो महत्वपूर्ण क्वेरी प्रदर्शन सुधार प्रदान करता है।
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 0118612414fd600fc7b10826ddf130ea4333716b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:19 -0500
Subject: [PATCH 1615/3820] New translations pruning.mdx (Swahili)

---
 .../pages/sw/subgraphs/cookbook/pruning.mdx   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/pruning.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/pruning.mdx b/website/pages/sw/subgraphs/cookbook/pruning.mdx
new file mode 100644
index 000000000000..c6b1217db9a5
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/pruning.mdx
@@ -0,0 +1,55 @@
+---
+title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+---
+
+## TLDR
+
+[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+
+## How to Prune a Subgraph With `indexerHints`
+
+Add a section called `indexerHints` in the manifest.
+
+`indexerHints` has three `prune` options:
+
+- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+
+We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+
+```yaml
+specVersion: 1.0.0
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Contract
+    network: mainnet
+```
+
+## Important Considerations
+
+- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+
+- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+
+## Conclusion
+
+Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 20ae22a94fa0b7801fe6bf0502e8dfede6264c27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:20 -0500
Subject: [PATCH 1616/3820] New translations secure-api-keys-nextjs.mdx
 (Romanian)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/ro/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..fc7e0ff52eb4
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Overview
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Prerequisites
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 1b5b4a13875a48900f159664bb8d1f4839c83c65 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:22 -0500
Subject: [PATCH 1617/3820] New translations secure-api-keys-nextjs.mdx
 (French)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/fr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..10a7c38dbcdc
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: Comment sécuriser les clés d'API en utilisant les composants serveur de Next.js
+---
+
+## Aperçu
+
+Nous pouvons utiliser [les composants serveur de Next.js](https://nextjs.org/docs/app/building-your-application/rendering/server-components) pour sécuriser correctement notre clé API contre l'exposition dans le frontend de notre dapp. Pour augmenter encore la sécurité de notre clé API, nous pouvons également [restreindre notre clé API à certains subgraphs ou domaines dans Subgraph Studio.](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+Dans ce guide pratique, nous allons passer en revue la création d'un composant de serveur Next.js qui interroge un subgraph tout en masquant la clé API du frontend.
+
+### Mise en garde
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Conditions préalables
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From f3c5f56536378d604b5c5993de39a4b977dd29bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:23 -0500
Subject: [PATCH 1618/3820] New translations secure-api-keys-nextjs.mdx
 (Spanish)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/es/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/es/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..35f83bb861f7
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Descripción
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Prerrequisitos
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 956d2850fe01dd342cfe79f4d1587b919fe3a5a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:24 -0500
Subject: [PATCH 1619/3820] New translations secure-api-keys-nextjs.mdx
 (Arabic)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/ar/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..618edf25ee0f
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## نظره عامة
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### المتطلبات الأساسية
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 0ee69a4d0bd664b1acce1d2d02b95e838a4a0594 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:25 -0500
Subject: [PATCH 1620/3820] New translations secure-api-keys-nextjs.mdx (Czech)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/cs/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..efc07a2489df
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: Jak zabezpečit klíče API pomocí komponent serveru Next.js
+---
+
+## Přehled
+
+K řádnému zabezpečení našeho klíče API před odhalením ve frontendu naší aplikace můžeme použít [komponenty serveru Next.js](https://nextjs.org/docs/app/building-your-application/rendering/server-components). Pro další zvýšení zabezpečení našeho klíče API můžeme také [omezit náš klíč API na určité podgrafy nebo domény v Podgraf Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+V této kuchařce probereme, jak vytvořit serverovou komponentu Next.js, která se dotazuje na podgraf a zároveň skrývá klíč API před frontend.
+
+### Upozornění
+
+- Součásti serveru Next.js nechrání klíče API před odčerpáním pomocí útoků typu odepření služby.
+- Brány Graf síť mají zavedené strategie detekce a zmírňování odepření služby, avšak použití serverových komponent může tyto ochrany oslabit.
+- Server komponenty Next.js přinášejí rizika centralizace, protože může dojít k výpadku serveru.
+
+### Proč je to důležité
+
+Ve standardní aplikaci React mohou být klíče API obsažené v kódu frontendu vystaveny na straně klienta, což představuje bezpečnostní riziko. Soubory `.env` se sice běžně používají, ale plně klíče nechrání, protože kód Reactu se spouští na straně klienta a vystavuje klíč API v hlavičkách. Serverové komponenty Next.js tento problém řeší tím, že citlivé operace zpracovávají na straně serveru.
+
+### Použití vykreslování na straně klienta k dotazování podgrafu
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Požadavky
+
+- Klíč API od [Subgraph Studio](https://thegraph.com/studio)
+- Základní znalosti Next.js a React.
+- Existující projekt Next.js, který používá [App Router](https://nextjs.org/docs/app).
+
+## Kuchařka krok za krokem
+
+### Krok 1: Nastavení proměnných prostředí
+
+1. V kořeni našeho projektu Next.js vytvořte soubor `.env.local`.
+2. Přidejte náš klíč API: `API_KEY=<api_key_here>`.
+
+### Krok 2: Vytvoření součásti serveru
+
+1. V adresáři `components` vytvořte nový soubor `ServerComponent.js`.
+2. K nastavení komponenty serveru použijte přiložený ukázkový kód.
+
+### Krok 3: Implementace požadavku API na straně serveru
+
+Do souboru `ServerComponent.js` přidejte následující kód:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Krok 4: Použití komponenty serveru
+
+1. V našem souboru stránky (např. `pages/index.js`) importujte `ServerComponent`.
+2. Vykreslení komponenty:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Krok 5: Spusťte a otestujte náš Dapp
+
+Spusťte naši aplikaci Next.js pomocí `npm run dev`. Ověřte, že serverová komponenta načítá data bez vystavení klíče API.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Závěr
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 14cf8b1a60b5dc005004491cb592e83029e2a681 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:26 -0500
Subject: [PATCH 1621/3820] New translations secure-api-keys-nextjs.mdx
 (German)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..fc7e0ff52eb4
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Overview
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Prerequisites
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 16b1483132b5ddd0a65469c33c08b59ac6a39922 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:27 -0500
Subject: [PATCH 1622/3820] New translations secure-api-keys-nextjs.mdx
 (Italian)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/it/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/it/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..fba106e6eaf6
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Panoramica
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Prerequisites
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 01da700939e9f37e652d9860d2854ff9cc0f85fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:28 -0500
Subject: [PATCH 1623/3820] New translations secure-api-keys-nextjs.mdx
 (Japanese)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/ja/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..e9b5174536c2
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## 概要
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### 前提条件
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 6ee50433c5b35df2ddeffb26e964f25e91e87ff6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:29 -0500
Subject: [PATCH 1624/3820] New translations secure-api-keys-nextjs.mdx
 (Korean)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/ko/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..fc7e0ff52eb4
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Overview
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Prerequisites
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From b033529a92720e2b91b5e6e6bbd4a02f8c5ca4d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:31 -0500
Subject: [PATCH 1625/3820] New translations secure-api-keys-nextjs.mdx (Dutch)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/nl/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..fc7e0ff52eb4
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Overview
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Prerequisites
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 6dd3d382866077cec5e7f7a4b9259a4d311ab0ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:32 -0500
Subject: [PATCH 1626/3820] New translations secure-api-keys-nextjs.mdx
 (Polish)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/pl/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..fc7e0ff52eb4
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Overview
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Prerequisites
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 25bef5b97d31cee8fca8593a7902272915e6cc4c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:34 -0500
Subject: [PATCH 1627/3820] New translations secure-api-keys-nextjs.mdx
 (Portuguese)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/pt/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..2fefb98cbe36
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: Como Proteger Chaves de API com Componentes do Servidor Next.js
+---
+
+## Visão geral
+
+Podemos proteger a nossa chave API no frontend do nosso dApp com [componentes do servidor Next.js](https://nextjs.org/docs/app/building-your-application/rendering/server-components). Para ainda mais segurança, também podemos [restringir a nossa chave API a certos domínios ou subgraphs no Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+Neste manual, veremos como criar um componente de servidor Next.js que faz queries em um subgraph enquanto esconde a chave API do frontend.
+
+### Porém...
+
+- Componentes de servidor Next.js não protegem chaves API de extrações durante ataques DDoS (negação distribuída de serviço).
+- Os gateways da Graph Network têm estratégias prontas de mitigação e deteção de negação de serviço, mas o uso de componentes de servidor pode enfraquecer estas proteções.
+- Componentes de servidor Next.js introduzem riscos de centralização, possibilitando uma derruba do servidor.
+
+### Por Que é Necessário
+
+Num aplicativo de React normal, chaves API incluídas no código do frontend podem ser expostas ao lado do cliente, o que apresenta um risco de segurança. É normal o uso de arquivos `.env`, mas estes não protegem as chaves por completo, já que o código do React é executado no lado do cliente (client-side), o que expõe a chave API nos headers. Os componentes do servidor Next.js abordam este problema via a execução de operações sensíveis server-side.
+
+### Como usar renderização client-side para fazer queries em um subgraph
+
+![Renderização client-side](/img/api-key-client-side-rendering.png)
+
+### Pré-requisitos
+
+- Uma chave API do [Subgraph Studio](https://thegraph.com/studio)
+- Conhecimentos básicos de Next.js e React.
+- Um projeto Next.js existente que use o [App Router](https://nextjs.org/docs/app).
+
+## Manual Passo a Passo
+
+### Passo 1: Prepare Variáveis de Ambiente
+
+1. Na raiz do nosso projeto Next.js, crie um arquivo `env.local`.
+2. Adicione a nossa chave API: `API_KEY=<api_key_here>`.
+
+### Passo 2: Crie um Componente de Servidor
+
+1. No nosso diretório `components`, crie um arquivo novo, `ServerComponent.js`.
+2. Use o exemplo de código acima para preparar o componente do servidor.
+
+### Passo 3: Implemente o Pedido da API Server-Side
+
+No `ServerComponent.js`, adicione o seguinte código:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Passo 4: Utilize o Componente do Servidor
+
+1. No nosso arquivo de página (por ex., `pages/index.js`), importe `Server Component`.
+2. Renderize o componente:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Passo 5: Execute e Teste o Nosso dApp
+
+Inicie o nosso aplicativo Next.js com `npm run dev`. Verifique se o componente do servidor retira dados sem expor a chave API.
+
+![Renderização server-side](/img/api-key-server-side-rendering.png)
+
+### Conclusão
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From e5ebb834256513e279716476793093b7a6eb7f9c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:35 -0500
Subject: [PATCH 1628/3820] New translations secure-api-keys-nextjs.mdx
 (Russian)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..5dbc5989e24b
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: Как обезопасить API-ключи с использованием серверных компонентов Next.js
+---
+
+## Обзор
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+В этом руководстве мы рассмотрим, как создать серверный компонент Next.js, который запрашивает субграф, одновременно скрывая API-ключ от фронтенда.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Серверные компоненты Next.js вносят риски централизации, так как сервер может выйти из строя.
+
+### Почему это необходимо
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Использование рендеринга на клиентской стороне для запроса к субграфу
+
+![Рендеринг на клиентской стороне](/img/api-key-client-side-rendering.png)
+
+### Предварительные требования
+
+- API-ключ от [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- Существующий проект Next.js, который использует [App Router](https://nextjs.org/docs/app).
+
+## Пошаговое руководство
+
+### Step 1: Set Up Environment Variables
+
+1. В корневой папке нашего проекта Next.js создайте файл `.env.local`.
+2. Добавьте наш API-ключ: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. В директории `components` создайте новый файл `ServerComponent.js`.
+2. Используйте приведённый пример кода для настройки серверного компонента.
+
+### Step 3: Implement Server-Side API Request
+
+В файл `ServerComponent.js` добавьте следующий код:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Отрендерите компонент:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Запустите наше приложение Next.js с помощью команды `npm run dev`. Убедитесь, что серверный компонент запрашивает данные, не раскрывая API-ключ.
+
+![Рендеринг на стороне сервера](/img/api-key-server-side-rendering.png)
+
+### Заключение
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 1290fd37e697b61896cb27ff56e1f4f5699d2e14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:36 -0500
Subject: [PATCH 1629/3820] New translations secure-api-keys-nextjs.mdx
 (Swedish)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/sv/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..00334a8801c5
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Översikt
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Förutsättningar
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From cdeb9ca435eb85ffa681ceec358a098306359532 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:37 -0500
Subject: [PATCH 1630/3820] New translations secure-api-keys-nextjs.mdx
 (Turkish)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..d258a3d2bd1c
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Genel Bakış
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Ön Koşullar
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From cbd8ddcef6a1c2508e9a592da329774dffdf3f80 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:38 -0500
Subject: [PATCH 1631/3820] New translations secure-api-keys-nextjs.mdx
 (Ukrainian)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/uk/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..fc7e0ff52eb4
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Overview
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Prerequisites
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 3240291cc9e7bc9e4f0d8940201155b7aee32ba7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:39 -0500
Subject: [PATCH 1632/3820] New translations secure-api-keys-nextjs.mdx
 (Chinese Simplified)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..ad2aa7315e87
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## 概述
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### 先决条件
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From d609f11bc377c3f77520f5ef868956c65d237bd8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:40 -0500
Subject: [PATCH 1633/3820] New translations secure-api-keys-nextjs.mdx (Urdu
 (Pakistan))

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/ur/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..d278d72cd06b
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## جائزہ
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### شرطیں
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From c09f6ab11833133cd3cee3152305d5f78bba38be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:41 -0500
Subject: [PATCH 1634/3820] New translations secure-api-keys-nextjs.mdx
 (Vietnamese)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/vi/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..314a1d413c91
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Tổng quan
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Điều kiện tiên quyết
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 649ef1de9fdb7724c1eb73f0d41db845458e1a21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:42 -0500
Subject: [PATCH 1635/3820] New translations secure-api-keys-nextjs.mdx
 (Marathi)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/mr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..ec45a7a5c6fc
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## सविश्लेषण
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### पूर्वतयारी
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From f5c88e839e59903da760bea4cbf21ada4518ebb1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:43 -0500
Subject: [PATCH 1636/3820] New translations secure-api-keys-nextjs.mdx (Hindi)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/hi/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..76d23572ec46
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: कैसे सुरक्षित करें API Keys का उपयोग करके Next.js Server Components
+---
+
+## अवलोकन
+
+हम Next.js server components(https://nextjs.org/docs/app/building-your-application/rendering/server-components) का उपयोग करके अपने dapp के frontend में API key को exposure से सुरक्षित रख सकते हैं। API key की सुरक्षा को और बढ़ाने के लिए, हम Subgraph Studio में अपनी API key को कुछ subgraphs या domains तक सीमित कर सकते हैं(/cookbook/upgrading-a-subgraph/#securing-your-api-key)
+
+इस cookbook में, हम यह समझेंगे कि कैसे एक Next.js server component बनाया जाए जो subgraph से query करता है, साथ ही API key को frontend से छिपाने का तरीका भी शामिल है।
+
+### चेतावनी
+
+- Next.js सर्वर घटक डिनायल ऑफ़ सर्विस अटैक का उपयोग करके API कुंजियों को समाप्त होने से सुरक्षित नहीं कर सकते।
+- The Graph Network gateways में सेवा को बाधित करने के हमलों का पता लगाने और उन्हें रोकने की रणनीतियाँ मौजूद हैं, हालांकि server components का उपयोग करने से ये सुरक्षा कमजोर हो सकती है।
+- Next.js server components केंद्रीकरण के जोखिम प्रस्तुत करते हैं क्योंकि सर्वर बंद हो सकता है।
+
+### यह क्यों आवश्यक है
+
+एक मानक React एप्लिकेशन में, फ्रंटेंड कोड में शामिल API कुंजियाँ क्लाइंट-साइड पर उजागर हो सकती हैं, जिससे सुरक्षा का जोखिम बढ़ता है। जबकि.env फ़ाइलें सामान्यत: उपयोग की जाती हैं, ये कुंजियों की पूरी सुरक्षा नहीं करतीं क्योंकि React का कोड क्लाइंट साइड पर निष्पादित होता है, जो API कुंजी को हेडर में उजागर करता है। Next.js सर्वर घटक इस मुद्दे का समाधान करते हैं द्वारा संवेदनशील कार्यों को सर्वर-साइड पर संभालना।
+
+### क्लाइंट-साइड रेंडरिंग का उपयोग करके एक subgraph को क्वेरी करना
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### आवश्यक शर्तें
+
+-  [Subgraph Studio](https://thegraph.com/studio) से एक API कुंजी
+- Next.js और React का बुनियादी ज्ञान
+- एक मौजूदा Next.js प्रोजेक्ट जो App Router (https://nextjs.org/docs/app). का उपयोग करता है।
+
+## स्टेप-बाय-स्टेप कुकबुक
+
+### चरण 1: पर्यावरण चर सेट करें
+
+1. हमारे Next.js प्रोजेक्ट की जड़ में, एक.env.local फ़ाइल बनाएं।
+2. हमारा API कुंजी जोड़ें: `API_KEY=<api_key_here>`.
+
+### चरण 2: एक सर्वर घटक बनाएं
+
+1. हमारे components निर्देशिका में, एक नया फ़ाइल बनाएं, ServerComponent.js।
+2. प्रदान किए गए उदाहरण कोड का उपयोग करके सर्वर घटक सेट करें।
+
+### चरण 3: सर्वर-साइड API अनुरोध को लागू करें
+
+ServerComponent.js में, निम्नलिखित कोड जोड़ें:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### चरण 4: सर्वर घटक का उपयोग करें
+
+1. हमारी पृष्ठ फ़ाइल (जैसे, pages/index.js) में ServerComponent आयात करें।
+2. कंपोनेंट को रेंडर करें:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### चरण 5: हमारा Dapp चलाएँ और परीक्षण करें
+
+अपने Next.js एप्लिकेशन को npm run dev का उपयोग करके प्रारंभ करें। सत्यापित करें कि सर्वर कंपोनेंट डेटा प्राप्त कर रहा है बिना API कुंजी को उजागर किए।
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### निष्कर्ष
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 5024f2bfb9b3436d33497879710f60eed636e8a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:44 -0500
Subject: [PATCH 1637/3820] New translations secure-api-keys-nextjs.mdx
 (Swahili)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 123 ++++++++++++++++++
 1 file changed, 123 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/secure-api-keys-nextjs.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/sw/subgraphs/cookbook/secure-api-keys-nextjs.mdx
new file mode 100644
index 000000000000..fc7e0ff52eb4
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -0,0 +1,123 @@
+---
+title: How to Secure API Keys Using Next.js Server Components
+---
+
+## Overview
+
+We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+
+In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+
+### Caveats
+
+- Next.js server components do not protect API keys from being drained using denial of service attacks.
+- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js server components introduce centralization risks as the server can go down.
+
+### Why It's Needed
+
+In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+
+### Using client-side rendering to query a subgraph
+
+![Client-side rendering](/img/api-key-client-side-rendering.png)
+
+### Prerequisites
+
+- An API key from [Subgraph Studio](https://thegraph.com/studio)
+- Basic knowledge of Next.js and React.
+- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+
+## Step-by-Step Cookbook
+
+### Step 1: Set Up Environment Variables
+
+1. In our Next.js project root, create a `.env.local` file.
+2. Add our API key: `API_KEY=<api_key_here>`.
+
+### Step 2: Create a Server Component
+
+1. In our `components` directory, create a new file, `ServerComponent.js`.
+2. Use the provided example code to set up the server component.
+
+### Step 3: Implement Server-Side API Request
+
+In `ServerComponent.js`, add the following code:
+
+```javascript
+const API_KEY = process.env.API_KEY
+
+export default async function ServerComponent() {
+  const response = await fetch(
+    `https://gateway-arbitrum.network.thegraph.com/api/${API_KEY}/subgraphs/id/HUZDsRpEVP2AvzDCyzDHtdc64dyDxx8FQjzsmqSg4H3B`,
+    {
+      method: 'POST',
+      headers: {
+        'Content-Type': 'application/json',
+      },
+      body: JSON.stringify({
+        query: /* GraphQL */ `
+          {
+            factories(first: 5) {
+              id
+              poolCount
+              txCount
+              totalVolumeUSD
+            }
+          }
+        `,
+      }),
+    },
+  )
+
+  const responseData = await response.json()
+  const data = responseData.data
+
+  return (
+    <div>
+      <h1>Server Component</h1>
+      {data ? (
+        <ul>
+          {data.factories.map((factory) => (
+            <li key={factory.id}>
+              <p>ID: {factory.id}</p>
+              <p>Pool Count: {factory.poolCount}</p>
+              <p>Transaction Count: {factory.txCount}</p>
+              <p>Total Volume USD: {factory.totalVolumeUSD}</p>
+            </li>
+          ))}
+        </ul>
+      ) : (
+        <p>Loading data...</p>
+      )}
+    </div>
+  )
+}
+```
+
+### Step 4: Use the Server Component
+
+1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+2. Render the component:
+
+```javascript
+import ServerComponent from './components/ServerComponent'
+
+export default function Home() {
+  return (
+    <main>
+      <ServerComponent />
+    </main>
+  )
+}
+```
+
+### Step 5: Run and Test Our Dapp
+
+Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+
+![Server-side rendering](/img/api-key-server-side-rendering.png)
+
+### Conclusion
+
+By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From cda57b4e6f7c21f68bbfe0fbd658db7b4a2a2dab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:45 -0500
Subject: [PATCH 1638/3820] New translations subgraph-debug-forking.mdx
 (Romanian)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/ro/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..6610f19da66d
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Quick and Easy Subgraph Debugging Using Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, what is it?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## What?! How?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Please, show me some code!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+The usual way to attempt a fix is:
+
+1. Make a change in the mappings source, which you believe will solve the issue (while I know it won't).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Wait for it to sync-up.
+4. If it breaks again go back to 1, otherwise: Hooray!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Make a change in the mappings source, which you believe will solve the issue.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. If it breaks again, go back to 1, otherwise: Hooray!
+
+Now, you may have 2 questions:
+
+1. fork-base what???
+2. Forking who?!
+
+And I answer:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Forking is easy, no need to sweat:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+So, here is what I do:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 10d6206e2529245a3f6ac4d02a6471e6807ee74c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:46 -0500
Subject: [PATCH 1639/3820] New translations subgraph-debug-forking.mdx
 (French)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/fr/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..cedcf3ece5c4
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Débogage rapide et facile des subgraph à l'aide de Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## D'accord, qu'est-ce que c'est ?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## Quoi ? Comment ?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## S'il vous plaît, montrez-moi du code !
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar introuvable!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+La méthode habituelle pour tenter de résoudre le problème est la suivante :
+
+1. Apportez une modification à la source des mappages, ce qui, selon vous, résoudra le problème (même si je sais que ce ne sera pas le cas).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Attendez qu’il soit synchronisé.
+4. S'il se casse à nouveau, revenez au point 1, sinon : Hourra !
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Apportez une modification à la source des mappings qui, selon vous, résoudra le problème.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. S'il casse à nouveau, revenez à 1, sinon : Hourra !
+
+Maintenant, vous pouvez avoir 2 questions :
+
+1. base de fourche quoi ???
+2. Fourcher qui ?!
+
+Je réponds :
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Fourcher est facile, pas besoin de transpirer :
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+Voici donc ce que je fais :
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+     --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+     --ethereum-rpc NOM_RÉSEAU : [CAPABILITIES] :URL \
+     --ipfs 127.0.0.1:5001
+     --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. J'inspecte les logs générés par le Graph Node local et, Hourra!, tout semble fonctionner.
+5. Je déploie mon subgraph, désormais débarrassé de tout bug, sur un Graph Node distant et vis heureux pour toujours ! (Malheureusement pas de patates, mais c’est la vie…)

From 4ef1fb34910ea4c1bede569480ce44932b704141 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:47 -0500
Subject: [PATCH 1640/3820] New translations subgraph-debug-forking.mdx
 (Spanish)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/es/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/es/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..163a16d59e00
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Debugging rápido y sencillo de subgrafos mediante Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## ¿Bien, qué es?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## ¡¿Qué?! ¿Cómo?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## ¡Por favor, muéstrame algo de código!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+La forma habitual de intentar una solución es:
+
+1. Realiza un cambio en la fuente de mapeos, que crees que resolverá el problema (aunque sé que no lo hará).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Espera a que se sincronice.
+4. Si se vuelve a romper vuelve a 1, de lo contrario: ¡Hurra!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Realiza un cambio en la fuente de mapeos, que crees que resolverá el problema.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. Si se vuelve a romper, vuelve a 1, de lo contrario: ¡Hurra!
+
+Ahora, puedes tener 2 preguntas:
+
+1. fork-base que???
+2. Bifurcando a quien?!
+
+Y yo respondo:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Bifurcar es fácil, no hay necesidad de sudar:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+Entonces, esto es lo que hago:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From f53fffada78d8683d6124480e077ae5a1c60cd76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:49 -0500
Subject: [PATCH 1641/3820] New translations subgraph-debug-forking.mdx
 (Arabic)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/ar/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..3bacc1f60003
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Quick and Easy Subgraph Debugging Using Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## حسنا، ما هو؟
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## ماذا؟! كيف؟
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## من فضلك ، أرني بعض الأكواد!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+الطريقة المعتادة لمحاولة الإصلاح هي:
+
+1. إجراء تغيير في مصدر الـ mappings ، والذي تعتقد أنه سيحل المشكلة (وأنا أعلم أنه لن يحلها).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. الانتظار حتى تتم المزامنة.
+4. إذا حدثت المشكلة مرة أخرى ، فارجع إلى 1!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. قم بإجراء تغيير في مصدر الـ mappings ، والذي تعتقد أنه سيحل المشكلة.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. إذا حدثت المشكلة مرة أخرى ، فارجع إلى 1!
+
+الآن ، قد يكون لديك سؤالان:
+
+1. ماهو fork-base؟؟؟
+2. ما الذي نقوم بتفريعه (Forking)؟!
+
+وأنا أجيب:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. الـتفريع سهل ، فلا داعي للقلق:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+لذلك ، هذا ما أفعله:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 2ab91427a769699507fff050f8cc80e8699724e2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:49 -0500
Subject: [PATCH 1642/3820] New translations subgraph-debug-forking.mdx (Czech)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/cs/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..4673b362c360
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Rychlé a snadné ladění podgrafů pomocí vidliček
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, co to je?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## Co?! Jak?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Ukažte mi prosím nějaký kód!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+Obvyklý způsob, jak se pokusit o opravu, je:
+
+1. Proveďte změnu ve zdroji mapování, která podle vás problém vyřeší (zatímco já vím, že ne).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Počkejte na synchronizaci.
+4. Pokud se opět rozbije, vraťte se na 1, jinak: Hurá!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Proveďte změnu ve zdroji mapování, která podle vás problém vyřeší.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. Pokud se opět rozbije, vraťte se na 1, jinak: Hurá!
+
+Nyní můžete mít 2 otázky:
+
+1. fork-base co???
+2. Vidličkování kdo?!
+
+A já odpovídám:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Vidličkování je snadné, není třeba se potit:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+Takže to dělám takhle:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. Zkontroluji protokoly vytvořené místním graf uzlem a hurá, zdá se, že vše funguje.
+5. Nasadím svůj nyní již bezchybný podgraf do vzdáleného uzlu Graf a žiji šťastně až do smrti! (bez brambor)

From 873ca697c7e0278444cc80b06f0c41bcf5050b06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:50 -0500
Subject: [PATCH 1643/3820] New translations subgraph-debug-forking.mdx
 (German)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/de/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/de/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..6610f19da66d
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Quick and Easy Subgraph Debugging Using Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, what is it?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## What?! How?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Please, show me some code!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+The usual way to attempt a fix is:
+
+1. Make a change in the mappings source, which you believe will solve the issue (while I know it won't).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Wait for it to sync-up.
+4. If it breaks again go back to 1, otherwise: Hooray!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Make a change in the mappings source, which you believe will solve the issue.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. If it breaks again, go back to 1, otherwise: Hooray!
+
+Now, you may have 2 questions:
+
+1. fork-base what???
+2. Forking who?!
+
+And I answer:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Forking is easy, no need to sweat:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+So, here is what I do:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 342b009923e3d31e807d957a3c3804b3a0138cf7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:51 -0500
Subject: [PATCH 1644/3820] New translations subgraph-debug-forking.mdx
 (Italian)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/it/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/it/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..6610f19da66d
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Quick and Easy Subgraph Debugging Using Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, what is it?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## What?! How?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Please, show me some code!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+The usual way to attempt a fix is:
+
+1. Make a change in the mappings source, which you believe will solve the issue (while I know it won't).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Wait for it to sync-up.
+4. If it breaks again go back to 1, otherwise: Hooray!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Make a change in the mappings source, which you believe will solve the issue.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. If it breaks again, go back to 1, otherwise: Hooray!
+
+Now, you may have 2 questions:
+
+1. fork-base what???
+2. Forking who?!
+
+And I answer:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Forking is easy, no need to sweat:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+So, here is what I do:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 29d08cc5394e0bcb508c268600a57adaa4da059a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:53 -0500
Subject: [PATCH 1645/3820] New translations subgraph-debug-forking.mdx
 (Japanese)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/ja/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..7d4e4d6a6e6f
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: フォークを用いた迅速かつ容易なサブグラフのデバッグ
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## さて、それは何でしょうか？
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## その方法は？
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## コードを見てみましょう
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+通常の試すであろう修正方法：
+
+1. マッピングソースを変更して問題の解決を試す（解決されないことは分かっていても）
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. 同期を待つ
+4. 再び問題が発生した場合は、1に戻る
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. マッピングのソースを変更し、問題を解決する
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. もし再度、壊れる場合1に戻る
+
+さて、ここで2つの疑問が生じます：
+
+1. フォークベースとは？
+2. フォーキングは誰ですか？
+
+回答：
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. フォーキングは簡単であり煩雑な手間はありません
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+そこで、以下の通りです：
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From dba0fa743e04571f23974b631ce76668d4deb5ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:54 -0500
Subject: [PATCH 1646/3820] New translations subgraph-debug-forking.mdx
 (Korean)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/ko/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..6610f19da66d
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Quick and Easy Subgraph Debugging Using Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, what is it?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## What?! How?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Please, show me some code!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+The usual way to attempt a fix is:
+
+1. Make a change in the mappings source, which you believe will solve the issue (while I know it won't).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Wait for it to sync-up.
+4. If it breaks again go back to 1, otherwise: Hooray!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Make a change in the mappings source, which you believe will solve the issue.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. If it breaks again, go back to 1, otherwise: Hooray!
+
+Now, you may have 2 questions:
+
+1. fork-base what???
+2. Forking who?!
+
+And I answer:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Forking is easy, no need to sweat:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+So, here is what I do:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 3fa93f48085b29297daaf7982df4250b1c935c8f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:55 -0500
Subject: [PATCH 1647/3820] New translations subgraph-debug-forking.mdx (Dutch)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/nl/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..6610f19da66d
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Quick and Easy Subgraph Debugging Using Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, what is it?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## What?! How?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Please, show me some code!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+The usual way to attempt a fix is:
+
+1. Make a change in the mappings source, which you believe will solve the issue (while I know it won't).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Wait for it to sync-up.
+4. If it breaks again go back to 1, otherwise: Hooray!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Make a change in the mappings source, which you believe will solve the issue.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. If it breaks again, go back to 1, otherwise: Hooray!
+
+Now, you may have 2 questions:
+
+1. fork-base what???
+2. Forking who?!
+
+And I answer:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Forking is easy, no need to sweat:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+So, here is what I do:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 23e01eac9cb5f07ea18bfaf6415490fb3878e788 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:56 -0500
Subject: [PATCH 1648/3820] New translations subgraph-debug-forking.mdx
 (Polish)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/pl/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..6610f19da66d
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Quick and Easy Subgraph Debugging Using Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, what is it?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## What?! How?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Please, show me some code!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+The usual way to attempt a fix is:
+
+1. Make a change in the mappings source, which you believe will solve the issue (while I know it won't).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Wait for it to sync-up.
+4. If it breaks again go back to 1, otherwise: Hooray!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Make a change in the mappings source, which you believe will solve the issue.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. If it breaks again, go back to 1, otherwise: Hooray!
+
+Now, you may have 2 questions:
+
+1. fork-base what???
+2. Forking who?!
+
+And I answer:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Forking is easy, no need to sweat:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+So, here is what I do:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 886004fa2808663e65c9560317196c4a59a49eee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:57 -0500
Subject: [PATCH 1649/3820] New translations subgraph-debug-forking.mdx
 (Portuguese)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/pt/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..04e9a23e9ad7
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Debugging de Subgraphs Rápido e Fácil Com Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, o que é isso?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## O quê?! Como?!
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Por favor, quero ver códigos!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+A maneira mais comum de tentar consertar este erro é:
+
+1. Fazer uma mudança na fonte dos mapeamentos, que talvez possa resolver o problema (mas é claro que não vai).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Esperar que ele se sincronize.
+4. Se quebrar novamente, volte ao passo 1. Se não: Eba!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Faça uma mudança na fonte dos mapeamentos, que talvez possa resolver o problema.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. Se quebrar novamente, volte ao passo 1. Se não: Eba!
+
+Agora, você deve ter duas perguntas:
+
+1. Que fork-base???
+2. Forkar quem?!
+
+E eu respondo:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Forking é fácil, não precisa se preocupar:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+Aqui está o que eu faço:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. Eu verifico os logs produzidos pelo Graph Node local e... eba! Parece que deu tudo certo.
+5. Lanço o meu subgraph, agora livre de bugs, a um Graph Node remoto e vivo feliz para sempre! (mas sem batatas)

From 3b78d28515dbb4330a4c109473b3ef0199015c34 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:13:58 -0500
Subject: [PATCH 1650/3820] New translations subgraph-debug-forking.mdx
 (Russian)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..c39cddd8250d
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Быстрая и простая отладка подграфа с использованием форков
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## И так, что это?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## Что? Как?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Пожалуйста, покажите мне какой-нибудь код!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+Обычный способ попытаться исправить это:
+
+1. Внести изменения в источник сопоставлений, которые, по вашему мнению, решат проблему (в то время как я знаю, что это не так).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Подождать, пока он синхронизируется.
+4. Если он снова сломается, вернуться к пункту 1, в противном случае: Ура!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Внесите изменения в источник сопоставлений, которые, по вашему мнению, решат проблему.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. Если он снова сломается, вернитесь к пункту 1, в противном случае: Ура!
+
+Сейчас у вас может появиться 2 вопроса:
+
+1. fork-base что???
+2. Форкнуть кого?!
+
+И я вам отвечаю:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Форк - это просто, особо не нужно потеть:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+Итак, вот что я делаю:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 8b449ba6b6c90b463ceb6b3d1edf99d1fc888b21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:00 -0500
Subject: [PATCH 1651/3820] New translations subgraph-debug-forking.mdx
 (Swedish)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/sv/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..aee8ecf8791f
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Snabb och enkel subgraf felsökning med gafflar
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, vad är det?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## Vad?! Hur?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Snälla, visa mig lite kod!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+Det vanliga sättet att försöka fixa är:
+
+1. Gör en förändring i mappningskällan, som du tror kommer att lösa problemet (även om jag vet att det inte kommer att göra det).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Vänta tills det synkroniseras.
+4. Om den går sönder igen gå tillbaka till 1, annars: Hurra!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Gör en ändring i mappningskällan som du tror kommer att lösa problemet.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. Om den går sönder igen, gå tillbaka till 1, annars: Hurra!
+
+Nu kanske du har 2 frågor:
+
+1. gaffelbas vad???
+2. Forking vem?!
+
+Och jag svarar:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Gaffling är lätt, du behöver inte svettas:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+Så här är vad jag gör:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From a247fcbada19b02f661cc5c8bf5211d5688d3a42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:01 -0500
Subject: [PATCH 1652/3820] New translations subgraph-debug-forking.mdx
 (Turkish)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..ba011ead30dc
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Fork Kullanarak Hızlı ve Kolay Subgraph Hata Ayıklama
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Peki, nedir bu Subgraph Forklama?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## Ne?! Nasıl?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Lütfen bana biraz kod göster!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+Genellikle düzeltmeyi denemek için yol şudur:
+
+1. Eşleştirme kaynağında, sorunu çözeceğine inandığınız bir değişiklik yapın (ama ben çözmeyeceğini biliyorum).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Senkronize olması için bekleyin.
+4. Tekrar sorunla karşılaşırsanız 1. aşamaya geri dönün, aksi takdirde: Yaşasın!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Eşleştirme kaynağında, sorunu çözeceğine inandığınız bir değişiklik yapın.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. Tekrar sorunla karşılaşırsanız 1. aşamaya geri dönün, aksi takdirde: Yaşasın!
+
+Şimdi, 2 sorunuz olabilir:
+
+1. fork temelli ne???
+2. Kimi forkluyoruz?!
+
+Ve ben cevap veriyorum:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Forklama kolay, ter dökmeye gerek yok:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+İşte benim ne yaptığım:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From db9d933c0a677f70b4fe11545d7b5171605da605 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:02 -0500
Subject: [PATCH 1653/3820] New translations subgraph-debug-forking.mdx
 (Ukrainian)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/uk/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..6610f19da66d
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Quick and Easy Subgraph Debugging Using Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, what is it?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## What?! How?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Please, show me some code!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+The usual way to attempt a fix is:
+
+1. Make a change in the mappings source, which you believe will solve the issue (while I know it won't).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Wait for it to sync-up.
+4. If it breaks again go back to 1, otherwise: Hooray!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Make a change in the mappings source, which you believe will solve the issue.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. If it breaks again, go back to 1, otherwise: Hooray!
+
+Now, you may have 2 questions:
+
+1. fork-base what???
+2. Forking who?!
+
+And I answer:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Forking is easy, no need to sweat:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+So, here is what I do:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From d883255cbeb898ed06b398175f37ffb2d8f88fec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:03 -0500
Subject: [PATCH 1654/3820] New translations subgraph-debug-forking.mdx
 (Chinese Simplified)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..654785ae49dc
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: 使用分叉快速轻松地调试子图
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## 首先，让我们来看什么是子图分叉
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## 让我们看看这是如何做到的？
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## 下面让我们看一下代码示例
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+尝试修复的常用方法是：
+
+1. 在映射源中进行更改，你认为这将解决问题（但我知道它不会）。
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. 等待同步。
+4. 如果它再次中断，则返回 第1步，否则：搞定！
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. 按照你认为可以解决问题的方法，在映射源中进行更改。
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. 如果它再次中断，则返回 第1步，否则：搞定！
+
+现在，你可能有 2 个问题：
+
+1. 子分叉集是什么???
+2. 分叉什么?!
+
+回答如下：
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. 分叉容易，不要紧张：
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+所以，我是这么做的：
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 13947804d1d3fe45e5e2c21f503cf7153df899b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:04 -0500
Subject: [PATCH 1655/3820] New translations subgraph-debug-forking.mdx (Urdu
 (Pakistan))

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/ur/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..7a0dadaa4dfe
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: فورکس کا استعمال کرتے ہوۓ تیز اور آسان ڈیبگنگ
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## ٹھیک ہے، یہ ہے کیا؟
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## کیا؟! کیسے؟
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## براۓ مہربانی، مجہے کچھ کوڈ دکھائیں!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+درست کرنے کی کوشش کرنے کا معمول کا طریقہ یہ ہے:
+
+1. میپنگ کے ماخذ میں تبدیلی کریں، جس کے بارے میں آپ کو یقین ہے کہ مسئلہ حل ہو جائے گا (جبکہ میں جانتا ہوں کہ ایسا نہیں ہوگا).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. اس کے مطابقت پذیر ہونے کا انتظار کریں.
+4. اگر یہ دوبارہ ٹوٹ جاتا ہے تو 1 پر واپس جائیں، ورنہ: ہورے!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. میپنگ کے ماخذ میں تبدیلی کریں، جس سے آپ کو یقین ہے کہ مسئلہ حل ہو جائے گا.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. اگر یہ دوبارہ ٹوٹ جاتا ہے، تو 1 پر واپس جائیں، ورنہ: ہورے!
+
+اب، آپ کے پاس 2 سوالات ہوسکتے ہیں:
+
+1. فورک بیس کیا؟؟؟
+2. فورکنگ کون؟!
+
+اور میرا جواب:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. فورکنگ آسان ہے، پریشان ہونے کی ضرورت نہیں ہے:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+تو، یہاں میں کیا کرتا ہوں:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 1b8379c039e7075bf736b6b953265a12c994db5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:05 -0500
Subject: [PATCH 1656/3820] New translations subgraph-debug-forking.mdx
 (Vietnamese)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/vi/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..6610f19da66d
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Quick and Easy Subgraph Debugging Using Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, what is it?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## What?! How?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Please, show me some code!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+The usual way to attempt a fix is:
+
+1. Make a change in the mappings source, which you believe will solve the issue (while I know it won't).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Wait for it to sync-up.
+4. If it breaks again go back to 1, otherwise: Hooray!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Make a change in the mappings source, which you believe will solve the issue.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. If it breaks again, go back to 1, otherwise: Hooray!
+
+Now, you may have 2 questions:
+
+1. fork-base what???
+2. Forking who?!
+
+And I answer:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Forking is easy, no need to sweat:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+So, here is what I do:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 3deefa5e621b3d867959723da980546c434bc7ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:06 -0500
Subject: [PATCH 1657/3820] New translations subgraph-debug-forking.mdx
 (Marathi)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/mr/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..3c7f2ec051e3
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: फॉर्क्स वापरून जलद आणि सुलभ सबग्राफ डीबगिंग
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## ठीक आहे, ते काय आहे?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## काय?! कसे?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## कृपया, मला काही कोड दाखवा!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+निराकरण करण्याचा प्रयत्न करण्याचा नेहमीचा मार्ग आहे:
+
+1. मॅपिंग स्त्रोतामध्ये बदल करा, जो तुम्हाला विश्वास आहे की समस्या सोडवेल (जेव्हा मला माहित आहे की ते होणार नाही).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. ते समक्रमित होण्याची प्रतीक्षा करा.
+4. तो पुन्हा खंडित झाल्यास 1 वर परत जा, अन्यथा: हुर्रे!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. मॅपिंग स्त्रोतामध्ये बदल करा, जो तुम्हाला विश्वास आहे की समस्या सोडवेल.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. तो पुन्हा खंडित झाल्यास, 1 वर परत जा, अन्यथा: हुर्रे!
+
+आता, तुमच्याकडे 2 प्रश्न असू शकतात:
+
+1. fork-base काय???
+2. फोर्किंग होईल कोणासोबत?!
+
+आणि मी उत्तर देतो:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. काटा काढणे सोपे आहे, घाम गाळण्याची गरज नाही:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+तर, मी काय करतो ते येथे आहे:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From a58cc4f46193fb9a3b9ed738f75fb55c85859f79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:07 -0500
Subject: [PATCH 1658/3820] New translations subgraph-debug-forking.mdx (Hindi)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/hi/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..0dc044459311
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: फोर्क्स का उपयोग करके त्वरित और आसान सबग्राफ डिबगिंग
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## ठीक है वो क्या है?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## क्या?! कैसे?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## कृपया मुझे कुछ कोड दिखाओ!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+फिक्स का प्रयास करने का सामान्य तरीका है:
+
+1. मैपिंग सोर्स में बदलाव करें, जो आपको लगता है कि समस्या का समाधान करेगा (जबकि मुझे पता है कि यह नहीं होगा)।
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. इसके सिंक-अप होने की प्रतीक्षा करें।
+4. यदि यह फिर से टूट जाता है तो 1 पर वापस जाएँ, अन्यथा: हुर्रे!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. मैपिंग सोर्स में परिवर्तन करें, जिसके बारे में आपको लगता है कि इससे समस्या हल हो जाएगी.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. यदि यह फिर से ब्रेक जाता है, तो 1 पर वापस जाएँ, अन्यथा: हुर्रे!
+
+अब, आपके 2 प्रश्न हो सकते हैं:
+
+1. फोर्क-बेस क्या???
+2. फोर्किंग कौन?!
+
+और मैं उत्तर देता हूं:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. फोर्किंग आसान है, पसीना बहाने की जरूरत नहीं:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+तो, यहाँ मैं क्या करता हूँ:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 7eeb10bf597c59471665f5128aa7bff3a017387f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:08 -0500
Subject: [PATCH 1659/3820] New translations subgraph-debug-forking.mdx
 (Swahili)

---
 .../cookbook/subgraph-debug-forking.mdx       | 101 ++++++++++++++++++
 1 file changed, 101 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/subgraph-debug-forking.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/sw/subgraphs/cookbook/subgraph-debug-forking.mdx
new file mode 100644
index 000000000000..6610f19da66d
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -0,0 +1,101 @@
+---
+title: Quick and Easy Subgraph Debugging Using Forks
+---
+
+As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+
+## Ok, what is it?
+
+**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+
+In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+
+## What?! How?
+
+When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+
+In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+
+## Please, show me some code!
+
+To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+
+Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+
+```tsx
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id.toHex().toString())
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let gravatar = Gravatar.load(event.params.id.toI32().toString())
+  if (gravatar == null) {
+    log.critical('Gravatar not found!', [])
+    return
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+
+The usual way to attempt a fix is:
+
+1. Make a change in the mappings source, which you believe will solve the issue (while I know it won't).
+2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+3. Wait for it to sync-up.
+4. If it breaks again go back to 1, otherwise: Hooray!
+
+It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+
+Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+
+0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+1. Make a change in the mappings source, which you believe will solve the issue.
+2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+3. If it breaks again, go back to 1, otherwise: Hooray!
+
+Now, you may have 2 questions:
+
+1. fork-base what???
+2. Forking who?!
+
+And I answer:
+
+1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+2. Forking is easy, no need to sweat:
+
+```bash
+$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+
+So, here is what I do:
+
+1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+
+```
+$ cargo run -p graph-node --release -- \
+    --postgres-url postgresql://USERNAME[:PASSWORD]@localhost:5432/graph-node \
+    --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL \
+    --ipfs 127.0.0.1:5001
+    --fork-base https://api.thegraph.com/subgraphs/id/
+```
+
+2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+
+```bash
+$ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
+```
+
+4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
+5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)

From 588adadf46e14681cd39e81fc1d1b4ecd82a8314 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:09 -0500
Subject: [PATCH 1660/3820] New translations subgraph-uncrashable.mdx
 (Romanian)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/ro/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..0cc91a0fa2c3
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Safe Subgraph Code Generator
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Why integrate with Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 57f27550538501c0cc7e065ee7a09212b1a5dfee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:10 -0500
Subject: [PATCH 1661/3820] New translations subgraph-uncrashable.mdx (French)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/fr/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..fadcd9b98faf
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Générateur de code de subgraph sécurisé
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Pourquoi intégrer Subgraph Uncrashable ?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- Le cadre comprend également un moyen (via le fichier de configuration) de créer des fonctions de définition personnalisées, mais sûres, pour des groupes de variables d'entité. De cette façon, il est impossible pour l'utilisateur de charger/utiliser une entité de graph obsolète et il est également impossible d'oublier de sauvegarder ou définissez une variable requise par la fonction.
+
+- Les logs d'avertissement sont enregistrés sous forme de logs indiquant où il y a une violation de la logique du subgraph pour aider à corriger le problème afin d'assurer l'exactitude des données.
+
+Subgraph Uncrashable peut être exécuté en tant qu'indicateur facultatif à l'aide de la commande Graph CLI codegen.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 6bbb811a154377a5c35ae5cbd1da5c1f8e2cf087 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:11 -0500
Subject: [PATCH 1662/3820] New translations subgraph-uncrashable.mdx (Spanish)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/es/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/es/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..59b33568a1f2
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Generador de código de subgrafo seguro
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## ¿Por qué integrarse con Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- El marco también incluye una forma (a través del archivo de configuración) para crear funciones de establecimiento personalizadas, pero seguras, para grupos de variables de entidad. De esta forma, es imposible que el usuario cargue/utilice una entidad gráfica obsoleta y también es imposible olvidarse de guardar o configurar una variable requerida por la función.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable se puede ejecutar como un indicador opcional mediante el comando codegen Graph CLI.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 04525242e4fe91d6d3b455234404e9c5fa234473 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:13 -0500
Subject: [PATCH 1663/3820] New translations subgraph-uncrashable.mdx (Arabic)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/ar/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..0cc91a0fa2c3
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Safe Subgraph Code Generator
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Why integrate with Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From c402393e067bcb22d119fa7c17173865cacd52d0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:14 -0500
Subject: [PATCH 1664/3820] New translations subgraph-uncrashable.mdx (Czech)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/cs/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..53750dd1cbee
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Generátor kódu bezpečného podgrafu
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Proč se integrovat s aplikací Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- Framework také obsahuje způsob (prostřednictvím konfiguračního souboru), jak vytvořit vlastní, ale bezpečné funkce setteru pro skupiny proměnných entit. Tímto způsobem není možné, aby uživatel načetl/použil zastaralou entitu grafu, a také není možné zapomenout uložit nebo nastavit proměnnou, kterou funkce vyžaduje.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Podgraf Uncrashable lze spustit jako volitelný příznak pomocí příkazu Graph CLI codegen.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 7fefa1649e5b6e02577056ef81020ccdbd66fe65 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:15 -0500
Subject: [PATCH 1665/3820] New translations subgraph-uncrashable.mdx (German)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/de/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/de/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..0cc91a0fa2c3
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Safe Subgraph Code Generator
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Why integrate with Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From edc28793ab9b716d13f41f0dcfdfdae25e53757d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:16 -0500
Subject: [PATCH 1666/3820] New translations subgraph-uncrashable.mdx (Italian)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/it/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/it/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..0cc91a0fa2c3
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Safe Subgraph Code Generator
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Why integrate with Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 28431edd7e9642ffac0137bd60718128ca0f7a8f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:16 -0500
Subject: [PATCH 1667/3820] New translations subgraph-uncrashable.mdx
 (Japanese)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/ja/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..74d66b27fcaa
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: 安全なサブグラフのコード生成
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Subgraph Uncrashable と統合する理由
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- また、このフレームワークには、エンティティ変数のグループに対して、カスタムだが安全なセッター関数を作成する方法が（設定ファイルを通じて）含まれています。この方法では、ユーザーが古いグラフ・エンティティをロード/使用することは不可能であり、また、関数が必要とする変数の保存や設定を忘れることも不可能です。
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashableは、Graph CLI codegenコマンドでオプションのフラグとして実行することができます。
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 7f1e71beb37e7909300059e77a5d3ddaa08ee975 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:19 -0500
Subject: [PATCH 1668/3820] New translations subgraph-uncrashable.mdx (Korean)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/ko/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..0cc91a0fa2c3
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Safe Subgraph Code Generator
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Why integrate with Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 7d07e7d031b8fffb4dc81dcf83b1394b83fcc2ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:20 -0500
Subject: [PATCH 1669/3820] New translations subgraph-uncrashable.mdx (Dutch)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/nl/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..0cc91a0fa2c3
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Safe Subgraph Code Generator
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Why integrate with Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 10ee52ca40e25cc820ce53ecbec5be4f977b5d81 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:21 -0500
Subject: [PATCH 1670/3820] New translations subgraph-uncrashable.mdx (Polish)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/pl/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..0cc91a0fa2c3
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Safe Subgraph Code Generator
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Why integrate with Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From b9418ae094539e3d687dc9ef90d37aafd35db98c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:22 -0500
Subject: [PATCH 1671/3820] New translations subgraph-uncrashable.mdx
 (Portuguese)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/pt/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..7f0a48eb91ab
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Gerador de Código Seguro para Subgraphs
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Por que integrar com a Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- A estrutura também inclui uma maneira (através do arquivo de configuração) de criar funções personalizadas, mas seguras, para configurar grupos de variáveis de entidade. Desta maneira, é impossível que o utilizador carregue/use uma entidade de graph obsoleta, e também é impossível esquecer de salvar ou determinar uma variável exigida pela função.
+
+- Logs de aviso são registrados como logs que indicam onde há uma quebra de lógica no subgraph, para ajudar a consertar o problema e garantir a segurança dos dados.
+
+A Subgraph Uncrashable pode ser executada como flag opcional usando o comando codegen no Graph CLI.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From a9ab1a2a688e315bb399d6db298712a716631651 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:23 -0500
Subject: [PATCH 1672/3820] New translations subgraph-uncrashable.mdx (Russian)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..508f2e66bfd8
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Генератор кода безопасного подграфа
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Why integrate with Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- Фреймворк также включает способ (через config-файл) создания пользовательских, но безопасных функций установки для групп переменных объектов. Таким образом, пользователь не сможет загрузить/использовать устаревшую graph entity, и также невозможно забыть о сохранении или установке переменной, которая требуется функцией.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable можно запустить как необязательный флаг с помощью команды Graph CLI codegen.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From ad5273b6e3c426a4f385e66283b3c782bf6562e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:24 -0500
Subject: [PATCH 1673/3820] New translations subgraph-uncrashable.mdx (Swedish)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/sv/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..ce8e87ecfd46
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Säker subgraf kodgenerator
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Varför integrera med Subgraf Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- Ramverket innehåller också ett sätt (via konfigurationsfilen) att skapa anpassade, men säkra, sätterfunktioner för grupper av entitetsvariabler. På så sätt är det omöjligt för användaren att ladda/använda en inaktuell grafenhet och det är också omöjligt att glömma att spara eller ställa in en variabel som krävs av funktionen.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable kan köras som en valfri flagga med kommandot Graph CLI codegen.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 4bd2d75c72d90159bd1e23ccc2a582adc0362704 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:25 -0500
Subject: [PATCH 1674/3820] New translations subgraph-uncrashable.mdx (Turkish)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..8b9f4a425710
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Güvenli Subgraph Kod Oluşturucu
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Neden Subgraph Uncrashable'ı entegre etmelisiniz?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- Framework ayrıca unsur değişkenleri grupları için özel, ancak güvenli ayarlayıcı fonksiyonları oluşturmanın bir yolunu (yapılandırma dosyası aracılığıyla) içerir. Bu sayede, kullanıcının eski bir graph unsurunu yüklemesi/kullanması ve ayrıca fonksiyonun gerektirdiği bir değişkeni kaydetmeyi veya ayarlamayı unutması imkansız hale gelir.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable, Graph CLI codegen komutu kullanılarak isteğe bağlı bir bayrak olarak çalıştırılabilir.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 1697c2f10839ab69a21c13bb069288349e1eea44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:26 -0500
Subject: [PATCH 1675/3820] New translations subgraph-uncrashable.mdx
 (Ukrainian)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/uk/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..0cc91a0fa2c3
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Safe Subgraph Code Generator
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Why integrate with Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From af41785da7f5c5d7bfbab3aae4a3e673515eb599 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:27 -0500
Subject: [PATCH 1676/3820] New translations subgraph-uncrashable.mdx (Chinese
 Simplified)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/zh/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..959ec7b532cc
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: 安全子图代码生成器
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## 为什么要整合子图使其不崩溃？
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- 该框架还包括一种方法(通过配置文件) 为实体变量组创建自定义但安全的 setter 函数。这样，用户就不可能加载/使用过时的图形实体，也不可能忘记保存或设置函数所需的变量。
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+使用 Graph CLI codegen 命令，Subgraph Uncrashable 可以作为一个可选标志运行。
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 51af8b955f55cbf6f862565cfc0e835ae4ca7f84 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:29 -0500
Subject: [PATCH 1677/3820] New translations subgraph-uncrashable.mdx (Urdu
 (Pakistan))

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/ur/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..1ce722e5639d
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: محفوظ سب گراف کوڈ جنریٹر
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## سب گراف ان کریش ایبل کے ساتھ کیوں ضم کیا جائے؟
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- فریم ورک میں ہستی متغیرات کے گروپس کے لیے حسب ضرورت، لیکن محفوظ، سیٹر فنکشنز بنانے کا ایک طریقہ (کنفگ فائل کے ذریعے) بھی شامل ہے۔ اس طرح صارف کے لیے کسی باسی گراف ہستی کو لوڈ/استعمال کرنا ناممکن ہے اور فنکشن کے لیے مطلوبہ متغیر کو محفوظ کرنا یا سیٹ کرنا بھولنا بھی ناممکن ہے.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+گراف CLI کوڈجن کمانڈ کا استعمال کرتے ہوئے سب گراف ان کریش ایبل کو اختیاری پرچم کے طور پر چلایا جا سکتا ہے.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 0afbbd1d6245efb118609a2e1613c3da78530951 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:30 -0500
Subject: [PATCH 1678/3820] New translations subgraph-uncrashable.mdx
 (Vietnamese)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/vi/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..0cc91a0fa2c3
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Safe Subgraph Code Generator
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Why integrate with Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 99ebc242dbe649b761f726f28b8ad475b205cd7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:31 -0500
Subject: [PATCH 1679/3820] New translations subgraph-uncrashable.mdx (Marathi)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/mr/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..9a7e3d9f008e
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: सुरक्षित सबग्राफ कोड जनरेटर
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Subgraph Uncrashable सह समाकलित का?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- फ्रेमवर्कमध्ये एंटिटी व्हेरिएबल्सच्या गटांसाठी सानुकूल, परंतु सुरक्षित, सेटर फंक्शन्स तयार करण्याचा मार्ग (कॉन्फिग फाइलद्वारे) देखील समाविष्ट आहे. अशा प्रकारे वापरकर्त्याला जुना आलेख घटक लोड करणे/वापरणे अशक्य आहे आणि फंक्शनसाठी आवश्यक असलेले व्हेरिएबल सेव्ह करणे किंवा सेट करणे विसरणे देखील अशक्य आहे.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+ग्राफ CLI codegen कमांड वापरून Subgraph Uncrashable हा पर्यायी ध्वज म्हणून चालवला जाऊ शकतो.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From cd41386a4c136b66b079c0654cf48ddc6e94ad48 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:32 -0500
Subject: [PATCH 1680/3820] New translations subgraph-uncrashable.mdx (Hindi)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/hi/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..ace90495aef8
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: सुरक्षित सबग्राफ कोड जेनरेटर
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## सबग्राफ अनक्रैशेबल के साथ एकीकृत क्यों करें?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- फ्रेमवर्क में इकाई वैरिएबल के समूहों के लिए कस्टम, लेकिन सुरक्षित, सेटर फ़ंक्शन बनाने का एक तरीका (कॉन्फिग फ़ाइल के माध्यम से) भी शामिल है। इस तरह उपयोगकर्ता के लिए एक पुरानी ग्राफ़ इकाई को लोड/उपयोग करना असंभव है और फ़ंक्शन द्वारा आवश्यक वैरिएबल को सहेजना या सेट करना भूलना भी असंभव है।
+
+- चेतावनी लॉग को लॉग के रूप में रिकॉर्ड किया जाता है, जो यह इंगित करता है कि Subgraph लॉजिक में कहां उल्लंघन हो रहा है, ताकि समस्या को ठीक किया जा सके और डेटा की सटीकता सुनिश्चित हो सके।
+
+सबग्राफ अनक्रैशेबल को ग्राफ़ CLI codegen कमांड का उपयोग करके एक वैकल्पिक फ़्लैग के रूप में चलाया जा सकता है।
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From acc113b7ff02882106f136270eb152dd59dc56b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:33 -0500
Subject: [PATCH 1681/3820] New translations subgraph-uncrashable.mdx (Swahili)

---
 .../cookbook/subgraph-uncrashable.mdx         | 29 +++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/subgraph-uncrashable.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/sw/subgraphs/cookbook/subgraph-uncrashable.mdx
new file mode 100644
index 000000000000..0cc91a0fa2c3
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -0,0 +1,29 @@
+---
+title: Safe Subgraph Code Generator
+---
+
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+
+## Why integrate with Subgraph Uncrashable?
+
+- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+
+- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+
+- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+**Key Features**
+
+- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+
+- The framework also includes a way (via the config file) to create custom, but safe, setter functions for groups of entity variables. This way it is impossible for the user to load/use a stale graph entity and it is also impossible to forget to save or set a variable that is required by the function.
+
+- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+
+Subgraph Uncrashable can be run as an optional flag using the Graph CLI codegen command.
+
+```sh
+graph codegen -u [options] [<subgraph-manifest>]
+```
+
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From 3fe1022c2eae8785527d807486654fcf1b187c98 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:34 -0500
Subject: [PATCH 1682/3820] New translations substreams-powered-subgraphs.mdx
 (Romanian)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ro/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From 410ed1e8f9dfb5b1b862e1f8789916665b4d1eb2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:36 -0500
Subject: [PATCH 1683/3820] New translations substreams-powered-subgraphs.mdx
 (French)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/fr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..8b5249d6f202
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Subgraphs alimentés par Substreams
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Exigences
+
+Ce livre de recettes nécessite [yarn](https://yarnpkg.com/), [les dépendances nécessaires pour le développement local de Substreams](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), et la dernière version de Graph CLI (>=0.52.0) :
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Obtenir le livre de cuisine
+
+> Ce guide utilise ce [subgraph alimenté par Substreams comme référence] (https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Définir un package Substreams
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+Le package Substreams en question détecte les déploiements de contrats sur Mainnet Ethereum, en suivant le bloc de création et l'horodatage de tous les contrats nouvellement déployés. Pour ce faire, il existe un type `Contract` dédié dans `/proto/example.proto` ([en savoir plus sur la définition des tampons de protocole](https://protobuf.dev/programming-guides/proto3/#simple)) :
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+La logique de base du paquet Substreams est un module `map_contract` dans `lib.rs`, qui traite chaque bloc, filtrant les appels Create qui n'ont pas été réversibles, et retournant des `Contrats` :
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+Un package Substreams peut être utilisé par un subgraph tant qu'il possède un module qui produit des changements d'entité compatibles. Le paquet Substreams de l'exemple a un module supplémentaire `graph_out` dans `lib.rs` qui renvoie une sortie `substreams_entity_change::pb::entity::EntityChanges`, qui peut être traitée par Graph Node.
+
+> Le crate `substreams_entity_change` a aussi une fonction `Tables` dédiée pour générer simplement des changements d'entités ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). Les changements d'entités générés doivent être compatibles avec les entités `schema.graphql` définies dans le `subgraph.graphql` du subgraph correspondant.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+Ces types et modules sont regroupés dans `substreams.yaml` :
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # le nom à utiliser dans le .spkg
+  version: v1.0.1 # la version à utiliser lors de la création du .spkg
+
+imports: # dépendances
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # spécifie les types personnalisés à utiliser par les modules Substreams
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # spécifiez les modules avec leurs entrées et sorties.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # ce type peut être consommé par Graph Node
+```
+
+Vous pouvez vérifier le « flux » global d'un bloc, vers « map_contract » et « graph_out » en exécutant « substreams graph » :
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+Pour préparer ce module Substreams à être utilisé par un subgraph, vous devez exécuter les commandes suivantes :
+
+```bash
+yarn substreams:protogen # génère des types dans /src/pb
+yarn substreams:build # construit les substreams
+yarn substreams:package # empaquette les substreams dans un fichier .spkg
+
+# alternativement, yarn substreams:prepare appelle toutes les commandes ci-dessus
+```
+
+> Ces scripts sont définis dans le fichier `package.json` si vous voulez comprendre les commandes substreams sous-jacentes
+
+Cela génère un fichier `spkg` basé sur le nom et la version du paquet provenant de `substreams.yaml`. Le fichier `spkg` contient toutes les informations dont Graph Node a besoin pour ingérer ce paquet Substreams.
+
+> Si vous mettez à jour le module Substreams, en fonction des modifications apportées, vous devrez peut-être exécuter tout ou partie des commandes ci-dessus pour que le paquet `spkg` soit à jour.
+
+## Définition d'un subgraph alimenté par les courants de Substreams
+
+Les subgraphs alimentés par Substreams introduisent un nouveau type de source de données, "substreams". De tels subgraphs ne peuvent avoir qu'une seule source de données.
+
+Cette source de données doit spécifier le réseau indexé, le paquet Substreams (`spkg`) en tant qu'emplacement de fichier relatif, et le module au sein de ce paquet Substreams qui produit des changements d'entités compatibles avec le subgraph (dans ce cas, `map_entity_changes`, du paquet Substreams ci-dessus). Le mapping est spécifié, mais identifie simplement le type de mapping ("substreams/graph-entities") et l'apiVersion.
+
+> Actuellement, Subgraph Studio et The Graph Network prennent en charge les subgraphs alimentés par Substreams qui indexent le `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+Le `subgraph.yaml` fait également référence à un fichier de schéma. Les exigences pour ce fichier sont inchangées, mais les entités spécifiées doivent être compatibles avec les changements d'entités produits par le module Substreams référencé dans le `subgraph.yaml`.
+
+```graphql
+type Contrat @entity {
+  id: ID!
+
+  "La date et l'heure de déploiement du contrat"
+  horodatage: String!
+
+  "Le numéro de bloc du déploiement du contrat"
+  numéroDeBloc: BigInt!
+}
+```
+
+Le `subgraph. yaml` fait également référence à un fichier de schéma. Les exigences pour ce fichier sont inchangées, mais les entités spécifiées doivent être compatibles avec les changements d'entités produits par le module Substreams référencé dans `subgraph. yaml`.
+
+> Les subgraphs alimentés par Substreams indexant le mainnet Ethereum peuvent être déployés sur le [Subgraph Studio] (https://thegraph.com/studio/).
+
+```bash
+yarn install # installe graph-cli
+yarn subgraph:build # construit le subgraph
+yarn subgraph:deploy # déploie le subgraph
+```
+
+Voilà, c'est fait ! Vous avez construit et déployé un subgraph alimenté par Substreams.
+
+## Servir des subgraphs alimentés par Substreams
+
+Afin de servir des subgraphs alimentés par Substreams, Graph Node doit être configuré avec un fournisseur Substreams pour le réseau concerné, ainsi qu'un Firehose ou un RPC pour suivre la tête de chaîne. Ces fournisseurs peuvent être configurés via un fichier `config.toml` :
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "fournisseur-substreams-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exempletokenici" }},
+  { label = "fournisseur-firehose-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exempletokenici" }},
+]
+```

From 4a9866a8eaa98c313a0cd41c8bf32ca6f29143f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:37 -0500
Subject: [PATCH 1684/3820] New translations substreams-powered-subgraphs.mdx
 (Spanish)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/es/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/es/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From f87584b2dcc5b8b97cde66b1b502493a27e3b0f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:38 -0500
Subject: [PATCH 1685/3820] New translations substreams-powered-subgraphs.mdx
 (Arabic)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ar/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From 0d16196e67ce6894352171a862cc02a7a019b8c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:39 -0500
Subject: [PATCH 1686/3820] New translations substreams-powered-subgraphs.mdx
 (Czech)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/cs/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..6136aca4a52e
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Podgrafy napájen substreamů
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Požadavky
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Získejte kuchařku
+
+> Tato kuchařka používá tento [Substreams-powered subgraph jako referenci](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Definování balíčku Substreams
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+Dotyčný balíček Substreams detekuje nasazení kontraktů na Mainnet Ethereum a sleduje blok vytvoření a časové razítko všech nově nasazených kontraktů. K tomu je v souboru `/proto/example.proto` ([více informací o definování protokolových bufferů](https://protobuf.dev/programming-guides/proto3/#simple)) vyhrazen typ `Contract`:
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+Jádrem logiky balíčku Substreams je modul `map_contract` v souboru `lib.rs`, který zpracovává každý blok, filtruje volání Create, která nebyla vrácena, a vrací `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+Balíček Substreams může být použit podgrafem, pokud má modul, který vypisuje kompatibilní změny entit. Příklad balíčku Substreams má v `lib.rs` další modul `graph_out`, který vrací výstup `substreams_entity_change::pb::entity::EntityChanges`, který může zpracovat Graph Node.
+
+> Bedna `substreams_entity_change` má také speciální funkci `Tables` pro jednoduché generování změn entit ([dokumentace](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). Vygenerované změny entit musí být kompatibilní s entitami `schema.graphql` definovanými v `subgraph.graphql` příslušného podgrafu.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+Tyto typy a moduly jsou sdruženy v souboru `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+Celkový "tok" z bloku do `map_contract` a `graph_out` můžete zkontrolovat spuštěním `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+Chcete-li tento balíček Substreams připravit ke spotřebě podgrafem, musíte spustit následující příkazy:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> Tyto skripty jsou definovány v souboru `package.json`, pokud chcete porozumět základním příkazům substreamů
+
+Tím se vygeneruje soubor `spkg` na základě názvu a verze balíčku ze souboru `substreams.yaml`. Soubor `spkg` obsahuje všechny informace, které Grafu uzel potřebuje k požití tohoto balíčku Substreams.
+
+> Pokud aktualizujete balíček Substreams, může být v závislosti na provedených změnách nutné spustit některé nebo všechny výše uvedené příkazy, aby byl balíček `spkg` aktuální.
+
+## Definování podgrafu poháněný substreamů
+
+Subgrafy poháněné substreamy představují nový typ datového zdroje s názvem "substreams". Tyto subgrafy mohou mít pouze jeden datový zdroj.
+
+Tento zdroj dat musí specifikovat indexovanou síť, balíček Substreams (`spkg`) jako relativní umístění souboru a modul v rámci tohoto balíčku Substreams, který vytváří změny entit kompatibilní s podgrafem (v tomto případě `map_entity_changes` z výše uvedeného balíčku Substreams). Mapování je specifikováno, ale jednoduše identifikuje druh mapování ("substreams/graph-entities") a apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+Soubor `subgraph.yaml` také odkazuje na soubor se schématem. Požadavky na tento soubor se nemění, ale zadané entity musí být kompatibilní se změnami entit vytvořenými modulem Substreams, na který odkazuje soubor `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Vzhledem k výše uvedenému mohou vývojáři podgrafů použít rozhraní Graph CLI k nasazení tohoto podgrafu poháněného substreamy.
+
+> Subgrafy poháněné substreamy indexující hlavní síť Ethereum mohou být nasazeny do [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+Hotovo! Postavil(a) jste a nasadil(a) podgraf poháněný substreamy.
+
+## Obsluha podgrafů poháněných substreamy
+
+Aby bylo možné servírovat subgrafy napájené Substreams, musí být Graph Node nakonfigurován s poskytovatelem Substreams pro příslušnou síť a také s Firehose nebo RPC pro sledování hlavy řetězce. Tyto poskytovatele lze nakonfigurovat pomocí souboru `config.toml`:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From 80ce8865584d32294f9169a812dab155f8cc50a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:40 -0500
Subject: [PATCH 1687/3820] New translations substreams-powered-subgraphs.mdx
 (German)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/de/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/de/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From 64a447adb755696264ee0f15b12cbde655fc0122 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:41 -0500
Subject: [PATCH 1688/3820] New translations substreams-powered-subgraphs.mdx
 (Italian)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/it/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/it/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From eb9a4da5db5adf066b9ba7ac342c807e011d890b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:42 -0500
Subject: [PATCH 1689/3820] New translations substreams-powered-subgraphs.mdx
 (Japanese)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 225 ++++++++++++++++++
 1 file changed, 225 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ja/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..fd61c3750c20
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,225 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## 要件
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## 料理本を入手
+
+> このクックブックでは、この [Substreams-powered subgraph を参考として](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph) を使用します。
+
+```
+グラフ初期化 --from-example substreams-powered-subgraph
+```
+
+## サブストリームパッケージの定義
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+問題の Substreams パッケージは、メインネット イーサリアム上のコントラクトのデプロイメントを検出し、新しくデプロイされたすべてのコントラクトの作成ブロックとタイムスタンプを追跡します。これを行うには、`/proto/example.proto` に専用の `Contract` タイプがあります ([プロトコル バッファーの定義の詳細](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+Substreams パッケージのコア ロジックは、`lib.rs` の `map_contract` モジュールです。これは、すべてのブロックを処理し、元に戻されなかった Create 呼び出しをフィルタリングして、`Contracts` を返します。
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+```
+
+Substreams パッケージは、互換性のあるエンティティの変更を出力するモジュールを持っている限り、サブグラフで使用できます。サンプルの Substreams パッケージには、「lib.rs」内に追加の「graph_out」モジュールがあり、グラフ ノードで処理できる「substreams_entity_change::pb::entity::EntityChanges」出力を返します。
+
+> 「substreams_entity_change」クレートには、エンティティの変更を単純に生成するための専用の「Tables」関数もあります ([[documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html))。生成されたエンティティ変更は、対応するサブグラフの `subgraph.graphql` で定義された `schema.graphql` エンティティと互換性がある必要があります。
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+これらの型とモジュールは `substreams.yaml` にまとめられています。
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+`substreams chart` を実行することで、ブロックから `map_contract`、`graph_out` までの全体的な「フロー」を確認できます。
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+この Substreams パッケージをサブグラフで使用できるように準備するには、次のコマンドを実行する必要があります。
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> 基礎となるサブストリーム コマンドを理解したい場合は、これらのスクリプトは「package.json」ファイルで定義されます。
+
+これにより、「substreams.yaml」のパッケージ名とバージョンに基づいて「spkg」ファイルが生成されます。 「spkg」ファイルには、グラフ ノードがこのサブストリーム パッケージを取り込むために必要なすべての情報が含まれています。
+
+> Substreams パッケージを更新する場合、加えた変更に応じて、`spkg` を最新にするために上記のコマンドの一部またはすべてを実行する必要がある場合があります。
+
+## サブストリームによって動作するサブグラフの定義
+
+サブストリームによって動作するサブグラフは、新しい "substreams" というデータソースの kind を導入します。このようなサブグラフは、ただ1つのデータソースのみを持つことができます
+
+このデータ ソースは、インデックス付きネットワーク、相対的なファイルの場所としての Substreams パッケージ (`spkg`)、およびサブグラフ互換のエンティティ変更を生成するその Substreams パッケージ内のモジュール (この場合は、上記の Substreams パッケージからの `map_entity_changes`) を指定する必要があります。マッピングは指定されていますが、単にマッピングの種類 (「サブストリーム/グラフ エンティティ」) と apiVersion を識別するだけです。
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+`subgraph.yaml` もスキーマ ファイルを参照します。このファイルの要件は変更されていませんが、指定されたエンティティは、`subgraph.yaml` で参照される Substreams モジュールによって生成されるエンティティの変更と互換性がある必要があります。
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+上記を考慮すると、サブグラフ開発者は Graph CLI を使用して、このサブストリームを利用したサブグラフをデプロイできます。
+
+> サブストリームを利用したサブグラフのインデックス作成メインネット Ethereum は、[Subgraph Studio](https://thegraph.com/studio/) にデプロイできます。
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+それでおしまい！サブストリームを利用したサブグラフを構築してデプロイしました。
+
+## サブストリームを利用したサブグラフの提供
+
+サブストリームを利用したサブグラフを提供するには、チェーン ヘッドを追跡するための Firehose または RPC だけでなく、関連するネットワークのサブストリーム プロバイダーを使用してグラフ ノードを構成する必要があります。これらのプロバイダーは、「config.toml」ファイル経由で設定できます。
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From afde4d6d1bfa08dadbed6670fe7c4b558dbe6570 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:43 -0500
Subject: [PATCH 1690/3820] New translations substreams-powered-subgraphs.mdx
 (Korean)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ko/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From a84fcc4215b04215306f5f136dd9788ceab8e43f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:45 -0500
Subject: [PATCH 1691/3820] New translations substreams-powered-subgraphs.mdx
 (Dutch)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/nl/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From 5ba33277b34ddf7a500b1bd0886f22dad7f50e41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:47 -0500
Subject: [PATCH 1692/3820] New translations substreams-powered-subgraphs.mdx
 (Polish)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/pl/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From d4ca535bbed8c0f28e87f59ee40136cce4c5cff0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:48 -0500
Subject: [PATCH 1693/3820] New translations substreams-powered-subgraphs.mdx
 (Portuguese)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/pt/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..2a784be23286
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Subgraphs movidos por substreams
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requisitos
+
+Este manual precisa de: [yarn](https://yarnpkg.com/); [as dependências necessárias para o desenvolvimento local da Substreams](https://substreams.streamingfast.io/documentation/consume/installing-the-cli); e a versão mais recente do Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## O manual
+
+> Este manual usa este [subgraph movido pelo Substreams como referência](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Como definir um pacote de Substreams
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+O pacote de Substreams em questão deteta publicações de contratos na Mainnet do Ethereum, com rastreio do bloco de criação e horas para todos os contratos recém-lançados. Para fazer isto, há um tipo dedicado de `Contrato` no `/proto/example.proto` ([aprenda mais sobre a definição de Buffers de Protocolo](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+A lógica central do pacote de Substreams é um módulo `map_contract` em `lib.rs`, que processa cada bloco, assim filtrando chamadas de Criação que não foram revertidas e retornando `Contratos`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+Um pacote de Substreams também pode ser usado por um subgraph enquanto tiver um módulo que gere mudanças de entidade compatíveis. O pacote de Substreams usado como exemplo tem um módulo `graph_out` adicional no `lib.rs` que retorna um `substreams_entity_change::pb::entity::EntityChanges`, que pode então ser processado pelo Graph Node.
+
+> O `substreams_entity_change` também tem uma função `Tables` dedicada à geração simples de mudanças de entidade ([documentação](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). As Mudanças de Entidade geradas devem ser compatíveis com as entidades `schema.graphql` definidas no `subgraph.graphql` do subgraph correspondente.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+Estes tipos e módulos são juntados no `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # o nome a ser usado no .spkg
+  version: v1.0.1 # a versão a ser usada na criação do .spkg
+
+imports: # dependências
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # especifica tipos personalizados a serem usados por módulos Substreams
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # especifica módulos com suas entradas e saídas
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # este tipo pode ser consumido pelo Graph Node
+```
+
+Podes conferir o "fluxo" geral de um Bloco, de `map_contract` a `graph_out` ao executar o `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+Para preparar este pacote de Substreams para consumo por um subgraph, os seguintes comandos devem ser executados:
+
+```bash
+yarn substreams:protogen # gera tipos no /src/pb
+yarn substreams:build # constroi as substreams
+yarn substreams:package # empacota as substreams em um arquivo .spkg
+
+# como alternativa, o yarn substreams:prepare chama todos os comandos acima
+```
+
+> Estes scripts são definidos no pacote `package.json` se quiser entender os comandos subjacentes
+
+Isto gera um arquivo `spkg` baseado no nome e na versão do pacote da `substreams.yaml`. O arquivo `spkg` tem toda a informação necessária para que o Graph Node ingeste este pacote Substreams.
+
+> Em caso de atualização do pacote de Substreams, dependendo das mudanças feitas, pode ser necessário executar alguns dos — ou todos — os comandos acima para que o `spkg` esteja atualizado.
+
+## Definição de um subgraph movido a Substreams
+
+Subgraphs movidos a Substreams introduzem um novo `tipo` de fonte de dados, "substreams". Tais subgraphs só podem ter uma fonte de dados.
+
+Esta fonte de dados deve especificar a rede indexada, o pacote de Substreams ('spkg') como um local relativo de arquivos, e o módulo dentro daquele pacote de Substreams que produz mudanças de entidade compatíveis com o subgraph (neste caso 'map_entity_changes', do pacote de Substreams acima). O mapeamento é especificado, mas apenas identifica o tipo de mapeamento ("substreams/graph-entities") e a apiVersion.
+
+> Atualmente, o Subgraph Studio e a Graph Network apoiam subgraphs movidos a Substreams que indexam a `mainnet` (Mainnet do Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+O 'subgraph.yaml' também referencia um arquivo schema. Os requerimentos para este arquivo são os mesmos, mas as entidades especificadas devem ser compatíveis com as mudanças de entidade produzidas pelo módulo de Substreams referenciados no 'subgraph.yaml'.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Vendo acima, os programadores de subgraph podem usar a Graph CLI para editar este subgraph movido pelo Substreams.
+
+> Subgraphs movidos a substreams que indexam a mainnet do Ethereum podem ser editados ao [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # instala o graph-cli
+yarn subgraph:build # constroi o subgraph
+yarn subgraph:deploy # publica o subgraph
+```
+
+Pronto! Está construído e editado um subgraph movido a Substreams.
+
+## Servindo subgraphs movidos por substreams
+
+Para poder servir subgraphs movidos a Substreams, o Graph Node deve ser configurado com um provedor de Substreams para a rede relevante, assim como um Firehose ou RPC para rastrear a cabeça da chain. Estes provedores podem ser configurados através de um arquivo 'config.toml':
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From f4a616f00935e17bd42871e7e63f252b22a11ac6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:49 -0500
Subject: [PATCH 1694/3820] New translations substreams-powered-subgraphs.mdx
 (Russian)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ru/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..41a190869890
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Субграфы, работающие на основе субпотоков (Substreams)
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Требования
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Используйте справочный материал
+
+> В качестве справочного материала здесь используется этот [субграф на основе субпотоков в качестве ссылки](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Определение пакета субпотоков
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+Рассматриваемый пакет Substreams обнаруживает развертывания контрактов в основной сети Ethereum, отслеживая блок создания и временную метку для всех вновь развернутых контрактов. Для этого в `/proto/example.proto` есть специальный тип `Contract` ([узнайте больше об определении Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+Основной логикой пакета Substreams является модуль `map_contract` в `lib.rs `, который обрабатывает каждый блок, фильтруя вызовы Create, которые не были отменены, возвращая `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+Пакет Substreams может использоваться субграфом, если у него есть модуль, который выдает совместимые изменения объектов. В примере пакета Substreams есть дополнительный модуль `graph_out` в `lib.rs` который возвращает выходные данные `substreams_entity_change::pb::entity::EntityChanges`, которые могут быть обработаны Graph Node.
+
+> В крейте `substreams_entity_change` также есть специальная функция `Tables` для простой генерации изменений объектов ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). Сгенерированные изменения объектов должны быть совместимы с объектами `schema.graphql`, определенными в `subgraph.graphql` соответствующего субграфа.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+Эти типы и модули объединены в `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+Вы можете проверить общий "поток" из Блока от `map_contract` до `graph_out`, запустив `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+Чтобы подготовить этот пакет субпотоков к использованию субграфом, необходимо выполнить следующие команды:
+
+```bash
+yarn substreams:protogen # генерирует типы в /src/pb
+yarn substreams:build # создает субпотоки
+yarn substreams:package # упаковывает субпотоки в файл .spkg
+
+# в качестве альтернативы, yarn substreams:prepare вызывают все вышеперечисленные команды
+```
+
+> Эти скрипты определены в файле `package.json`, если вы хотите понять базовые команды субпотоков
+
+При этом создается файл `spkg` на основе имени и версии пакета из `substreams.yaml`. Файл `spkg` содержит всю информацию, которая необходима Graph Node для приема этого пакета субпотоков.
+
+> Если Вы обновите пакет субпотоков, в зависимости от внесенных Вами изменений, Вам может потребоваться выполнить некоторые или все вышеперечисленные команды, чтобы `spkg` был обновлен.
+
+## Определение субграфа, работающего на основе субпотоков
+
+Субграфы, работающие на основе на субпотоков, вводят в употребление новый "вид" источника данных - "субпотоки". Такие субграфы могут иметь только один источник данных.
+
+В этом источнике данных должна быть указана индексированная сеть, пакет Substreams (`spkg`) в качестве относительного местоположения файла и модуль в этом пакете Substreams, который производит совместимые с субграфами изменения объектов (в данном случае `map_entity_changes` из пакета Substreams, указанного выше). Мэппинг указан, но просто идентифицирует вид мэппинга ("substreams/graph-entities") и apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+`subgraph.yaml` также ссылается на файл схемы. Требования к этому файлу не изменились, но указанные объекты должны быть совместимы с изменениями объектов, произведенными модулем Substreams, на который ссылается `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Учитывая вышеизложенное, разработчики субграфов могут использовать Graph CLI для развертывания этого субграфа, работающего на основе субпотоков.
+
+> Субграфы, работающие на основе субпотоков, индексирующие основную сеть Ethereum, могут быть развернуты в [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+Вот и все! Вы создали и развернули субграф, работающий на основе субпотоков.
+
+## Обслуживание субграфов, работающих на основе субпотоков
+
+Для обслуживания субграфов, работающих на основе субпотоков, Graph Node должен быть сконфигурирован с соответствующей сетью провайдера субпотоков, а также с Firehose или RPC для отслеживания головного блока чейна. Эти провайдеры могут быть настроены с помощью файла `config.toml`:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From d1ed8f8b638154b4e0cbf0f3e16dbd0cf857376c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:50 -0500
Subject: [PATCH 1695/3820] New translations substreams-powered-subgraphs.mdx
 (Swedish)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/sv/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..c9f70597e367
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-drivna subgrafer
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Krav
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Skaffa kokboken
+
+> Den här kokboken använder denna [Substreams-powered subgraph som referens](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Definiera ett Substreams-paket
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+Substreams-paketet i fråga upptäcker kontraktsdistributioner på Mainnet Ethereum, spårar skapandeblocket och tidsstämpeln för alla nyligen distribuerade kontrakt. För att göra detta finns det en dedikerad "kontrakt"-typ i "/proto/example.proto" ([läs mer om att definiera protokollbuffertar](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+Kärnlogiken i Substreams-paketet är en `map_contract`-modul i `lib.rs`, som bearbetar varje block, filtrerar efter Skapa-anrop som inte återgick, returnerar `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+Ett Substreams-paket kan användas av en subgraf så länge det har en modul som matar ut kompatibla enhetsändringar. Exemplet på Substreams-paketet har en extra `graph_out`-modul i `lib.rs` som returnerar en `substreams_entity_change::pb::entity::EntityChanges`-utdata, som kan bearbetas av Graph Node.
+
+> "substreams_entity_change"-lådan har också en dedikerad "Tables"-funktion för att helt enkelt generera entitetsändringar ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). Entitetsändringarna som genereras måste vara kompatibla med "schema.graphql"-entiteterna som definieras i "subgraph.graphql" i motsvarande subgraf.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+Dessa typer och moduler dras ihop i `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+Du kan kontrollera det övergripande "flödet" från ett block, till `map_contract` till `graph_out` genom att köra `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+För att förbereda detta Substreams paket för konsumtion av en subgraf måste du köra följande kommandon:
+
+```bash
+yarn substreams:protogen # genererar typer i /src/pb
+yarn substreams:build # bygger substreams
+yarn substreams:package # paketerar substreams i en .spkg-fil
+
+# alternativt anropar yarn substreams:prepare alla ovanstående kommandon
+```
+
+> Dessa skript definieras i filen `package.json` om du vill förstå de underliggande substreams-kommandona
+
+Detta genererar en `spkg`-fil baserat på paketnamnet och versionen från `substreams.yaml`. `spkg`-filen har all information som Graph Node behöver för att mata in detta Substreams-paket.
+
+> Om du uppdaterar Substreams-paketet, beroende på de ändringar du gör, kan du behöva köra några eller alla ovanstående kommandon så att `spkg` är uppdaterad.
+
+## Definiera en Substream-driven subgraf
+
+Substreams-drivna subgrafer introducerar en ny "typ" av datakälla, "substreams". Sådana subgrafer kan bara ha en datakälla.
+
+Denna datakälla måste ange det indexerade nätverket, Substreams-paketet ("spkg") som en relativ filplats och modulen i det Substreams-paketet som producerar subgrafkompatibla entitetsändringar (i detta fall "map_entity_changes", från Substreams-paketet ovan). Mappningen är specificerad, men identifierar helt enkelt mappningstypen ("substreams/graph-entities") och apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+`subgraph.yaml` refererar också till en schemafil. Kraven för denna fil är oförändrade, men de angivna entiteterna måste vara kompatibla med entitetsändringarna som produceras av Substreams-modulen som refereras till i `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "Tidsstämpeln när kontraktet implementerades"
+  timestamp: String!
+
+  "Blocknummer för kontraktsimplementeringen"
+  blockNumber: BigInt!
+}
+```
+
+Med tanke på ovanstående kan subgraf utvecklare använda Graph CLI för att distribuera denna Substreams-drivna subgraf.
+
+> Underströmsdrivna subgrafer som indexerar mainnet Ethereum kan distribueras till [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # bygg subgrafen
+yarn subgraph:deploy # deploy the subgraph
+```
+
+Det är allt! Du har byggt och distribuerat en Substreams-drivna subgraf.
+
+## Visa substreams-drivna subgrafer
+
+För att kunna betjäna Substreams-drivna subgrafer måste Graph Node konfigureras med en Substreams-leverantör för det relevanta nätverket, samt en Firehose eller RPC för att spåra kedjehuvudet. Dessa leverantörer kan konfigureras via en `config.toml`-fil:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From 2d1a76e3bacda7f1eeee9e49a5a8008a685a5e7d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:52 -0500
Subject: [PATCH 1696/3820] New translations substreams-powered-subgraphs.mdx
 (Turkish)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/tr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..60cd07a2973d
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams destekli subgraphlar
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Gereksinimler
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Cookbook'u edinin
+
+> Bu rehber, bu [Substreams destekli subgraph'ı referans](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph) olarak kullanmaktadır.
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Bir Substreams paketi tanımlama
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+Bahsi geçen Substreams paketi, Ethereum Ana Ağı'nda kontrat dağıtımlarını algılar ve yeni oluşturulan kontratlar için oluşturma bloğunu ve zaman damgasını takip eder. Bunun için `/proto/example.proto` içinde buna özel bir `Contract` türü bulunmaktadır ([Protokol Buffers tanımlama hakkında daha fazla bilgi edinin](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+Substreams paketinin temel mantığı, her bloğu işleyen, Create çağrıları için bir filtreleme yapan ve geri dönüş olarak `Contracts` verisini döndüren `lib.rs` içindeki bulunan `map_contract` modülüdür:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+Bir Substreams paketi, uyumlu varlık değişiklikleri üreten bir modüle sahip olduğu sürece bir subgraph tarafından kullanılabilir. Örnek Substreams paketi, `lib.rs` dosyasında ek bir `graph_out` modülüne sahiptir ve Graph Düğümü tarafından işlenebilen `substreams_entity_change::pb::entity::EntityChanges` çıktısını döndürür.
+
+> `substreams_entity_change` paketi ayrıca varlık değişiklikleri oluşturmak için özel bir `Tables` işlevine sahiptir ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). Oluşturulan Varlık Değişiklikleri, buna karşılık gelen subgraph'ın `subgraph.graphql` dosyasında tanımlanan `schema.graphql` varlıklarıyla uyumlu olmalıdır.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+Bu türler ve modüller `substreams.yaml` dosyasında bir araya getirilir:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+`substreams graph` komutunu çalıştırarak bir Bloktan `map_contract`'a ve ardından `graph_out`'a genel "akışı" kontrol edebilirsiniz:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+Bu Substreams paketini bir subgraph tarafından kullanılmak üzere hazırlamak için aşağıdaki komutları çalıştırmanız gerekir:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> Substreams komutlarının temelini anlamak isterseniz, bu komutlar, `package.json` dosyasında tanımlanmıştır
+
+Bu,`substreams.yaml` dosyasındaki paket adı ve sürümden hareketle bir `spkg` dosyası oluşturur. `spkg` dosyası, Graph Düğümü'nün bu Substreams paketini alabilmesi için gereken tüm bilgilere sahiptir.
+
+> Substreams paketini güncellerseniz, yaptığınız değişikliklere bağlı olarak `spkg`'yı güncel tutmak için yukarıdaki komutların bazılarını veya tümünü çalıştırmanız gerekebilir.
+
+## Substreams Destekli Bir Subgraph Tanımlama
+
+Substreams destekli subgraphlar yeni bir veri kaynağı türü('kind') olan "substreams"'i sunar. Bu tür subgraphlar yalnızca bir veri kaynağına sahip olabilir.
+
+Bu veri kaynağı indekslenen ağı, Substreams paketi (`spkg`) olarak ilgili bir dosya konumu ve Substreams paketinin subgraph uyumlu varlık değişiklikleri üreten modülü belirtmelidir (bu durumda yukarıdaki Substreams paketinden `map_entity_changes`). Eşleştirme belirtilmiştir, fakat yalnızca eşleştirme türünü ("substreams/graph-entities") ve apiVersion'ı tanımlar.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+`subgraph.yaml` dosyası ayrıca bir şema dosyasına referans verir. Bu dosyanın gereksinimleri değişmemiş olmasına rağmen, `subgraph.yaml` içinde referans verilen Substreams modülü tarafından üretilen varlık değişiklikleriyle uyumlu olmalıdır.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Yukarıdakiler verildiğinde, subgraph geliştiricileri Graph CLI kullanarak bu Substreams destekli subgraph'ı dağıtabilir.
+
+> Ethereum Ana Ağını indeksleyen Substreams destekli subgraphlar, [Subgraph Stüdyo'ya](https://thegraph.com/studio/) dağıtılabilir.
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+Bu kadar! Bir Substreams destekli subgraph oluşturup dağıttınız.
+
+## Substreams destekli subgraphlar'ın sunulması
+
+Substreams destekli subgraphlar'ı sunabilmek için Graph Düğümü'nün ilgili ağ için bir Substreams sağlayıcısı ve zincir başını takip etmek için bir Firehose veya RPC yapılandırılması gerekmektedir. Bu sağlayıcılar, bir `config.toml` dosyası aracılığıyla yapılandırılabilir:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From 5e78258cbd4541f8837407df040e7cb74f0fd9e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:53 -0500
Subject: [PATCH 1697/3820] New translations substreams-powered-subgraphs.mdx
 (Ukrainian)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/uk/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From 21ee9a2d5bff38d4104ce876ab52a3f84c523a0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:54 -0500
Subject: [PATCH 1698/3820] New translations substreams-powered-subgraphs.mdx
 (Chinese Simplified)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/zh/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..35b5d34c9bb2
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: 基于Substreams的子图
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## 要求
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## 获取手册
+
+> 本手册使用这个基于Substreams的子图[Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph)作为参考。
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## 定义Substreams包
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+该Substreams包可以检测以太坊主网上的合约部署，并跟踪所有新部署合约的创建块和时间戳。为此，在/proto/example.proto中有一个专门的Contract类型（了解更多关于定义Protocol Buffers的信息[learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)）：
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+Substreams包的核心逻辑是lib.rs中的map_contract模块，它处理每个区块，过滤未回滚的Create调用，并返回Contracts：
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+只要Substreams包有一个模块输出与子图兼容的实体变更，就可以被子图使用。示例Substreams包中还有一个额外的graph_out模块在lib.rs中，它返回一个substreams_entity_change::pb::entity::EntityChanges输出，Graph Node可以处理该输出。
+
+> Substreams_entity_change crate还有一个专门的Tables函数，用于生成实体变更（文档[documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)）。生成的实体变更必须与相应子图的subgraph.graphql中定义的schema.graphql实体兼容。
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+这些类型和模块在substreams.yaml中汇集在一起：
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+您可以通过运行substreams graph来检查从区块到map_contract到graph_out的整体"流程"：
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+为了准备这个Substreams包供子图使用，您必须运行以下命令：
+
+```bash
+yarn substreams:protogen # 生成/src/pb中的类型
+yarn substreams:build # 构建Substreams
+yarn substreams:package # 将Substreams打包成.spkg文件
+
+# 或者，yarn substreams:prepare会调用上述所有命令
+```
+
+> 这些脚本在package.json文件中定义，如果想了解底层的Substreams命令，可以查看这些脚本。
+
+这将根据substreams.yaml中的包名称和版本生成一个spkg文件。spkg文件包含了Graph Node需要获取此Substreams包的所有信息。
+
+> 如果您更新了Substreams包，根据所做的更改，您可能需要运行部分或全部上述命令，以使spkg保持更新。
+
+## 定义一个基于Substreams的子图
+
+Substreams-powered subgraphs引入了一种名为"substreams"的新型数据源。这样的子图只能包含一个数据源。
+
+基于Substreams的子图引入了一种新的数据源类型，"substreams"。这样的子图只能有一个数据源。该数据源必须指定Substreams网络、Substreams包（spkg）的相对文件位置，以及该Substreams包中生成子图兼容实体变更的模块（在本例中为map_entity_changes）。映射是指定的，但只是标识了映射类型（"substreams/graph-entities"）和apiVersion。
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+Subgraph.yaml还引用了一个模式文件。对于这个文件的要求没有变化，但是指定的实体必须与subgraph.yaml中引用的Substreams模块生成的实体变更兼容。
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+有了以上内容，子图开发者可以使用Graph CLI部署这个基于Substreams的子图。
+
+> 基于Substreams的子图索引以太坊主网可以部署到[Subgraph Studio](https://thegraph.com/studio/)。
+
+```bash
+yarn install # 安装graph-cli
+yarn subgraph:build # 构建子图
+yarn subgraph:deploy # 部署子图
+```
+
+就是这样！您已经构建并部署了一个基于Substreams的子图。
+
+## 服务基于Substreams的子图
+
+为了服务基于Substreams的子图，Graph Node必须配置与相关网络的Substreams提供程序，以及用于跟踪链头的Firehose或RPC。这些提供程序可以通过config.toml文件进行配置：
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From 3e445469b28a18de1e13c82080fc6f3764853d93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:55 -0500
Subject: [PATCH 1699/3820] New translations substreams-powered-subgraphs.mdx
 (Urdu (Pakistan))

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ur/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..9643d1f73bf5
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: سب سٹریمز سے چلنے والے سب گرافس
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## تقاضے
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## کک بک حاصل کریں
+
+> یہ کک بک اس [سب اسٹریم سے چلنے والے سب گراف کو بطور حوالہ استعمال کرتی ہے](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## سب سٹریمز پیکیج کی وضاحت کرنا
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+زیر بحث سب اسٹریمز پیکیج مینیٹ ایتھیریم پر کنٹریکٹ کی تعیناتیوں کا پتہ لگاتا ہے، تمام نئے تعینات کردہ کنٹریکٹس کے لیے تخلیق بلاک اور ٹائم اسٹیمپ کا پتہ لگاتا ہے۔ ایسا کرنے کے لیے، `/proto/example.proto` ([پروٹوکول بفرز کی تعریف کرنے کے بارے میں مزید جانیں](https://protobuf.dev/programming-guides/proto3/#simple)) میں ایک مخصوص `Contract` قسم ہے:
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+سب اسٹریمز پیکج کی بنیادی منطق `lib.rs` میں ایک `map_contract` ماڈیول ہے، جو ہر بلاک پر کارروائی کرتا ہے، ایسی کالز تخلیق کرنے کے لئے فلٹر کرتا ہے جو واپس نہیں آتیں، `Contracts` واپس کرتی ہیں:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+سب اسٹریمز پیکیج کو سب گراف کے ذریعہ استعمال کیا جاسکتا ہے جب تک کہ اس میں ایک ماڈیول موجود ہو جو ہم آہنگ ہستی کی تبدیلیوں کو آؤٹ پٹ کرتا ہے۔ مثال کے سب سٹریمز پیکیج میں `lib.rs` میں ایک اضافی `graph_out` ماڈیول ہے جو `substreams_entity_change::pb::entity::EntityChanges` آؤٹ پٹ لوٹاتا ہے، جس پر گراف نوڈ کے ذریعے کارروائی کی جا سکتی ہے.
+
+> 'substreams_entity_change' کریٹ میں صرف ہستی کی تبدیلیاں پیدا کرنے کے لیے ایک وقف کردہ 'Tables' فنکشن ہے ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). تخلیق کردہ ہستی کی تبدیلیاں متعلقہ سب گراف کے `subgraph.graphql` میں بیان کردہ `schema.graphql` اداروں کے ساتھ ہم آہنگ ہونی چاہئیں.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+ان اقسام اور ماڈیولز کو `substreams.yaml` میں ایک ساتھ کھینچا جاتا ہے:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+آپ 'سب اسٹریمز گراف' کو چلا کر ایک بلاک سے `map_contract` سے `graph_out` تک مجموعی طور پر "فلو" کو چیک کر سکتے ہیں:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+سب اسٹریمز کے ذریعے استعمال کے لیے اس سب اسٹریم پیکیج کو تیار کرنے کے لیے، آپ کو درج ذیل کمانڈز چلانے چاہئیں:
+
+```bash
+yarn substreams:protogen # /src/pb میں قسمیں تیار کرتا ہے
+yarn substreams:build # سب سٹریمز بناتا ہے
+yarn substreams:package # سب اسٹریمز کو .spkg فائل میں پیک کرتا ہے
+
+# متبادل طور پر، یارن سب سٹریمز: مندرجہ بالا تمام کمانڈز کو کالز تیار کریں
+```
+
+> ان اسکرپٹس کی وضاحت `package.json` فائل میں کی گئی ہے اگر آپ بنیادی سب سٹریمز کی کمانڈ کو سمجھنا چاہتے ہیں
+
+یہ 'substreams.yaml' سے پیکیج کے نام اور ورژن کی بنیاد پر ایک `spkg` فائل تیار کرتا ہے۔ `spkg` فائل میں وہ تمام معلومات ہیں جن کی گراف نوڈ کو اس سب سٹریمز پیکیج کو ہضم کرنے کی ضرورت ہے.
+
+> اگر آپ سب اسٹریم پیکج کو اپ ڈیٹ کرتے ہیں تو، آپ کی تبدیلیوں پر منحصر ہے، آپ کو مندرجہ بالا کچھ یا سبھی کمانڈز چلانے کی ضرورت پڑسکتی ہے تاکہ `spkg` اپ ٹو ڈیٹ رہے.
+
+## سب اسٹریمز سے چلنے والے سب گراف کی وضاحت کرنا
+
+سب اسٹریمز سے چلنے والے سب گرافس ڈیٹا کے ذریعہ کی ایک نئی `kind` متعارف کراتے ہیں، "سب اسٹریمز"۔ اس طرح کے سب گرافس میں صرف ایک ڈیٹا سورس ہو سکتا ہے.
+
+اس ڈیٹا سورس کو انڈیکسڈ نیٹ ورک، سب اسٹریم پیکیج (`spkg`) کو متعلقہ فائل لوکیشن کے طور پر اور اس سب اسٹریم پیکیج کے اندر موجود ماڈیول کی وضاحت کرنی چاہیے جو سب سٹریمز سے مطابقت رکھنے والی ہستی کی تبدیلیاں (اس صورت میں `map_entity_changes`، اوپر سب اسٹریمز پیکیج سے)۔ میپنگ کی وضاحت کی گئی ہے، لیکن صرف میپنگ کی قسم ("substreams/graph-entities") اور apiVersion کی شناخت کرتا ہے.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+`subgraph.yaml` ایک سکیما فائل کا بھی حوالہ دیتا ہے۔ اس فائل کے تقاضے غیر تبدیل شدہ ہیں، لیکن متعین کردہ ہستیوں کو `subgraph.yaml` میں حوالہ کردہ سب سٹریمز ماڈیول کے ذریعہ تیار کردہ ہستی کی تبدیلیوں کے ساتھ ہم آہنگ ہونا چاہئے.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+مندرجہ بالا کو دیکھتے ہوئے، سب گراف ڈویلپرز اس سب اسٹریمز سے چلنے والے سب گراف کو تعینات کرنے کے لیے گراف CLI استعمال کر سکتے ہیں.
+
+> سب اسٹریمز سے چلنے والے سب گرافس کو انڈیکس کرنے والے مین نیٹ ایتھیریم کو [سب گراف اسٹوڈیو](https://thegraph.com/studio/) میں تعینات کیا جا سکتا ہے.
+
+```bash
+yarn install # graph-cli انسٹال کریں
+yarn subgraph:build # سب گراف کی تعمیر کریں
+yarn subgraph:deploy # سب گراف کو تعینات کریں
+```
+
+یہی ہے! آپ نے سب اسٹریمز سے چلنے والا سب گراف بنایا اور تعینات کیا ہے.
+
+## سب اسٹریمز سے چلنے والے سب گرافس کی خدمت کرنا
+
+سب اسٹریمز سے چلنے والے سب اسٹریمز کو پیش کرنے کے لیے، گراف نوڈ کو متعلقہ نیٹ ورک کے لیے سب اسٹریمز فراہم کنندہ کے ساتھ کنفیگر کیا جانا چاہیے، ساتھ ہی ساتھ چین ہیڈ کو ٹریک کرنے کے لیے فائر ہوز یا RPC کا ہونا چاہیے۔ ان فراہم کنندگان کو ایک `config.toml` فائل کے ذریعے ترتیب دیا جا سکتا ہے:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From cab8d2e5a7cc1bd8122441ac821477db1dafd5b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:57 -0500
Subject: [PATCH 1700/3820] New translations substreams-powered-subgraphs.mdx
 (Vietnamese)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/vi/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From cd4a7298f71efadf476f0981861d70406fb1d573 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:58 -0500
Subject: [PATCH 1701/3820] New translations substreams-powered-subgraphs.mdx
 (Marathi)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/mr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From 2db9ff1a29d01b38aae407a1f65cd71d7504af72 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:14:59 -0500
Subject: [PATCH 1702/3820] New translations substreams-powered-subgraphs.mdx
 (Hindi)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/hi/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From b0fa5ba488dfc49d25e9a87060be96c917d32b08 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:00 -0500
Subject: [PATCH 1703/3820] New translations substreams-powered-subgraphs.mdx
 (Swahili)

---
 .../cookbook/substreams-powered-subgraphs.mdx | 226 ++++++++++++++++++
 1 file changed, 226 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/substreams-powered-subgraphs.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/sw/subgraphs/cookbook/substreams-powered-subgraphs.mdx
new file mode 100644
index 000000000000..84e1b0adfd3b
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -0,0 +1,226 @@
+---
+title: Substreams-powered subgraphs
+---
+
+[Substreams](/substreams/introduction/) is a new framework for processing blockchain data, developed by StreamingFast for The Graph Network. A substreams modules can output entity changes, which are compatible with Subgraph entities. A subgraph can use such a Substreams module as a data source, bringing the indexing speed and additional data of Substreams to subgraph developers.
+
+## Requirements
+
+This cookbook requires [yarn](https://yarnpkg.com/), [the dependencies necessary for local Substreams development](https://substreams.streamingfast.io/documentation/consume/installing-the-cli), and the latest version of Graph CLI (>=0.52.0):
+
+```
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get the cookbook
+
+> This cookbook uses this [Substreams-powered subgraph as a reference](https://github.com/graphprotocol/graph-tooling/tree/main/examples/substreams-powered-subgraph).
+
+```
+graph init --from-example substreams-powered-subgraph
+```
+
+## Defining a Substreams package
+
+A Substreams package is composed of types (defined as [Protocol Buffers](https://protobuf.dev/)), modules (written in Rust), and a `substreams.yaml` file which references the types, and specifies how modules are triggered. [Visit the Substreams documentation to learn more about Substreams development](/substreams/introduction/), and check out [awesome-substreams](https://github.com/pinax-network/awesome-substreams) and the [Substreams cookbook](https://github.com/pinax-network/substreams-cookbook) for more examples.
+
+The Substreams package in question detects contract deployments on Mainnet Ethereum, tracking the creation block and timestamp for all newly deployed contracts. To do this, there is a dedicated `Contract` type in `/proto/example.proto` ([learn more about defining Protocol Buffers](https://protobuf.dev/programming-guides/proto3/#simple)):
+
+```proto
+syntax = "proto3";
+
+package example;
+
+message Contracts {
+  repeated Contract contracts = 1;
+}
+
+message Contract {
+    string address = 1;
+    uint64 blockNumber = 2;
+    string timestamp = 3;
+    uint64 ordinal = 4;
+}
+```
+
+The core logic of the Substreams package is a `map_contract` module in `lib.rs`, which processes every block, filtering for Create calls which did not revert, returning `Contracts`:
+
+```rust
+#[substreams::handlers::map]
+fn map_contract(block: eth::v2::Block) -> Result<Contracts, substreams::errors::Error> {
+    let contracts = block
+        .transactions()
+        .flat_map(|tx| {
+            tx.calls
+                .iter()
+                .filter(|call| !call.state_reverted)
+                .filter(|call| call.call_type == eth::v2::CallType::Create as i32)
+                .map(|call| Contract {
+                    address: format!("0x{}", Hex(&call.address)),
+                    block_number: block.number,
+                    timestamp: block.timestamp_seconds().to_string(),
+                    ordinal: tx.begin_ordinal,
+                })
+        })
+        .collect();
+    Ok(Contracts { contracts })
+}
+```
+
+A Substreams package can be used by a subgraph as long as it has a module which outputs compatible entity changes. The example Substreams package has an additional `graph_out` module in `lib.rs` which returns a `substreams_entity_change::pb::entity::EntityChanges` output, which can be processed by Graph Node.
+
+> The `substreams_entity_change` crate also has a dedicated `Tables` function for simply generating entity changes ([documentation](https://docs.rs/substreams-entity-change/1.2.2/substreams_entity_change/tables/index.html)). The Entity Changes generated must be compatible with the `schema.graphql` entities defined in the `subgraph.graphql` of the corresponding subgraph.
+
+```rust
+#[substreams::handlers::map]
+pub fn graph_out(contracts: Contracts) -> Result<EntityChanges, substreams::errors::Error> {
+    // hash map of name to a table
+    let mut tables = Tables::new();
+
+    for contract in contracts.contracts.into_iter() {
+        tables
+            .create_row("Contract", contract.address)
+            .set("timestamp", contract.timestamp)
+            .set("blockNumber", contract.block_number);
+    }
+
+    Ok(tables.to_entity_changes())
+}
+```
+
+These types and modules are pulled together in `substreams.yaml`:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: 'substreams_test' # the name to be used in the .spkg
+  version: v1.0.1 # the version to use when creating the .spkg
+
+imports: # dependencies
+  entity: https://github.com/streamingfast/substreams-entity-change/releases/download/v0.2.1/substreams-entity-change-v0.2.1.spkg
+
+protobuf: # specifies custom types for use by Substreams modules
+  files:
+    - example.proto
+  importPaths:
+    - ./proto
+
+binaries:
+  default:
+    type: wasm/rust-v1
+    file: ./target/wasm32-unknown-unknown/release/substreams.wasm
+
+modules: # specify modules with their inputs and outputs.
+  - name: map_contract
+    kind: map
+    inputs:
+      - source: sf.ethereum.type.v2.Block
+    output:
+      type: proto:test.Contracts
+
+  - name: graph_out
+    kind: map
+    inputs:
+      - map: map_contract
+    output:
+      type: proto:substreams.entity.v1.EntityChanges # this type can be consumed by Graph Node
+```
+
+You can check the overall "flow" from a Block, to `map_contract` to `graph_out` by running `substreams graph`:
+
+```mermaid
+graph TD;
+  map_contract[map: map_contract];
+  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_contract;
+  graph_out[map: graph_out];
+  map_contract --> graph_out;
+```
+
+To prepare this Substreams package for consumption by a subgraph, you must run the following commands:
+
+```bash
+yarn substreams:protogen # generates types in /src/pb
+yarn substreams:build # builds the substreams
+yarn substreams:package # packages the substreams in a .spkg file
+
+# alternatively, yarn substreams:prepare calls all of the above commands
+```
+
+> These scripts are defined in the `package.json` file if you want to understand the underlying substreams commands
+
+This generates a `spkg` file based on the package name and version from `substreams.yaml`. The `spkg` file has all the information which Graph Node needs to ingest this Substreams package.
+
+> If you update the Substreams package, depending on the changes you make, you may need to run some or all of the above commands so that the `spkg` is up to date.
+
+## Defining a Substreams-powered subgraph
+
+Substreams-powered subgraphs introduce a new `kind` of data source, "substreams". Such subgraphs can only have one data source.
+
+This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
+
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+
+```yaml
+specVersion: 0.0.4
+description: Ethereum Contract Tracking Subgraph (powered by Substreams)
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: schema.graphql
+dataSources:
+  - kind: substreams
+    name: substream_test
+    network: mainnet
+    source:
+      package:
+        moduleName: graph_out
+        file: substreams-test-v1.0.1.spkg
+    mapping:
+      kind: substreams/graph-entities
+      apiVersion: 0.0.5
+```
+
+The `subgraph.yaml` also references a schema file. The requirements for this file are unchanged, but the entities specified must be compatible with the entity changes produced by the Substreams module referenced in the `subgraph.yaml`.
+
+```graphql
+type Contract @entity {
+  id: ID!
+
+  "The timestamp when the contract was deployed"
+  timestamp: String!
+
+  "The block number of the contract deployment"
+  blockNumber: BigInt!
+}
+```
+
+Given the above, subgraph developers can use Graph CLI to deploy this Substreams-powered subgraph.
+
+> Substreams-powered subgraphs indexing mainnet Ethereum can be deployed to the [Subgraph Studio](https://thegraph.com/studio/).
+
+```bash
+yarn install # install graph-cli
+yarn subgraph:build # build the subgraph
+yarn subgraph:deploy # deploy the subgraph
+```
+
+That's it! You have built and deployed a Substreams-powered subgraph.
+
+## Serving Substreams-powered subgraphs
+
+In order to serve Substreams-powered subgraphs, Graph Node must be configured with a Substreams provider for the relevant network, as well as a Firehose or RPC to track the chain head. These providers can be configured via a `config.toml` file:
+
+```toml
+[chains.mainnet]
+shard = "main"
+protocol = "ethereum"
+provider = [
+  { label = "substreams-provider-mainnet",
+    details = { type = "substreams",
+    url = "https://mainnet-substreams-url.grpc.substreams.io/",
+    token = "exampletokenhere" }},
+  { label = "firehose-provider-mainnet",
+    details = { type = "firehose",
+    url = "https://mainnet-firehose-url.grpc.firehose.io/",
+    token = "exampletokenhere" }},
+]
+```

From 3553a7c8d5541a100116e15aec54e7f327aa2022 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:01 -0500
Subject: [PATCH 1704/3820] New translations timeseries.mdx (Romanian)

---
 .../ro/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/timeseries.mdx b/website/pages/ro/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..0168be53d7ed
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Overview
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Example:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Example:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Example:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Example:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From f9bd22baebf34605451ed27991bd38af3afe5397 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:04 -0500
Subject: [PATCH 1705/3820] New translations timeseries.mdx (French)

---
 .../fr/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/timeseries.mdx b/website/pages/fr/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..09dff67d307e
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Aperçu
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Points Importants
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+L'exemple:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+L'exemple:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+L'exemple:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+L'exemple:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From a54b67baba9e4857a525bf099dbda7a7a23ff156 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:06 -0500
Subject: [PATCH 1706/3820] New translations timeseries.mdx (Spanish)

---
 .../es/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/es/subgraphs/cookbook/timeseries.mdx b/website/pages/es/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..1dd08ab764d1
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Descripción
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Ejemplo:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Ejemplo:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Ejemplo:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Ejemplo:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 3da025edcd9d6cc8e44e5bd89990063765d903a8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:07 -0500
Subject: [PATCH 1707/3820] New translations timeseries.mdx (Arabic)

---
 .../ar/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/timeseries.mdx b/website/pages/ar/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..03ac4f323fa4
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## نظره عامة
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Example:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Example:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Example:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Example:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 9d653137bcc73fe7cd59a1200378cf644faabe51 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:08 -0500
Subject: [PATCH 1708/3820] New translations timeseries.mdx (Czech)

---
 .../cs/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/timeseries.mdx b/website/pages/cs/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..7178891769da
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Přehled
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Důležité úvahy
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Příklad:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Příklad:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Příklad:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Příklad:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Závěr
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 85389f3a836e830f1ff676752a6d475d9034ae14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:09 -0500
Subject: [PATCH 1709/3820] New translations timeseries.mdx (German)

---
 .../de/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/de/subgraphs/cookbook/timeseries.mdx b/website/pages/de/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..0168be53d7ed
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Overview
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Example:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Example:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Example:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Example:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From bdc1a2ff09374fc0cb9d9b4e21de7edce19fdd85 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:10 -0500
Subject: [PATCH 1710/3820] New translations timeseries.mdx (Italian)

---
 .../it/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/it/subgraphs/cookbook/timeseries.mdx b/website/pages/it/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..eeb246a2b3d0
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Panoramica
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Example:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Example:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Example:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Example:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 3ea47ca70ff62731e55be6de00873ebfa7ecd806 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:11 -0500
Subject: [PATCH 1711/3820] New translations timeseries.mdx (Japanese)

---
 .../ja/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/timeseries.mdx b/website/pages/ja/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..6ebf5e48a235
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## 概要
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+例：
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+例：
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+例：
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+例：
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From be108d2dd081e438548ad1978de2d24e5d707594 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:12 -0500
Subject: [PATCH 1712/3820] New translations timeseries.mdx (Korean)

---
 .../ko/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/timeseries.mdx b/website/pages/ko/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..0168be53d7ed
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Overview
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Example:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Example:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Example:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Example:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From d96dcbc76a28628e4b6b19409f3d614282ec896c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:13 -0500
Subject: [PATCH 1713/3820] New translations timeseries.mdx (Dutch)

---
 .../nl/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/timeseries.mdx b/website/pages/nl/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..0168be53d7ed
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Overview
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Example:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Example:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Example:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Example:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 79465f8b80678b64cb9772e2e63b2547fe336faf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:14 -0500
Subject: [PATCH 1714/3820] New translations timeseries.mdx (Polish)

---
 .../pl/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/timeseries.mdx b/website/pages/pl/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..0168be53d7ed
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Overview
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Example:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Example:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Example:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Example:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From c6a447edd94bfe5cc1856bfcc756f4be22d7cdcb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:15 -0500
Subject: [PATCH 1715/3820] New translations timeseries.mdx (Portuguese)

---
 .../pt/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/timeseries.mdx b/website/pages/pt/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..9c2a8632c5b6
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Visão geral
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Considerações Importantes
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Exemplo:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Exemplo:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Exemplo:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Exemplo:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusão
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 91aa454543f8c8f2d9cc7598f8de93eff269a541 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:16 -0500
Subject: [PATCH 1716/3820] New translations timeseries.mdx (Russian)

---
 .../ru/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/timeseries.mdx b/website/pages/ru/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..99228ae7d56d
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## Краткое содержание
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Обзор
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Пример:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Пример:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Пример:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Пример:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Заключение
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From bf3a23d2b5595ef4c8a609366f9ba5db2b177b3f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:18 -0500
Subject: [PATCH 1717/3820] New translations timeseries.mdx (Swedish)

---
 .../sv/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/timeseries.mdx b/website/pages/sv/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..76678087aca2
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Översikt
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Exempel:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Exempel:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Exempel:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Exempel:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From e59bfaabdf5cec434ada17f7aca63b09464c01ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:19 -0500
Subject: [PATCH 1718/3820] New translations timeseries.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/timeseries.mdx b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..e7b242bfa2f3
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Genel Bakış
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Örnek:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Örnek:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Örnek:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Örnek:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 5c370fb021b84909a20c499c5e9c16aad05ef87a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:20 -0500
Subject: [PATCH 1719/3820] New translations timeseries.mdx (Ukrainian)

---
 .../uk/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/timeseries.mdx b/website/pages/uk/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..0168be53d7ed
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Overview
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Example:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Example:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Example:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Example:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 28dd51e56101fba023609953d33f3844be79f3af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:21 -0500
Subject: [PATCH 1720/3820] New translations timeseries.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/timeseries.mdx b/website/pages/zh/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..7ac1de481272
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## 概述
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+例子:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+例子:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+例子:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+例子:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 85fa33cd0028e77717e99dc73b175aff9e33b8b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:22 -0500
Subject: [PATCH 1721/3820] New translations timeseries.mdx (Urdu (Pakistan))

---
 .../ur/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/timeseries.mdx b/website/pages/ur/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..5049667a8d5c
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## جائزہ
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+مثال:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+مثال:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+مثال:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+مثال:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 1e4f3194fb74d6d0fae77fb46729a9f0b5c9a7f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:23 -0500
Subject: [PATCH 1722/3820] New translations timeseries.mdx (Vietnamese)

---
 .../vi/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/timeseries.mdx b/website/pages/vi/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..4a55ac2bcd5a
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Tổng quan
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Example:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Example:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Example:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Example:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 84611dd6fa157c9936f98aad15381148500b0fd2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:24 -0500
Subject: [PATCH 1723/3820] New translations timeseries.mdx (Marathi)

---
 .../mr/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/timeseries.mdx b/website/pages/mr/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..aef1fe57ac5f
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## सविश्लेषण
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+उदाहरण:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+उदाहरण:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+उदाहरण:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+उदाहरण:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 7ea6eb2dffcac4ebfed6ff50353edc95082c06bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:25 -0500
Subject: [PATCH 1724/3820] New translations timeseries.mdx (Hindi)

---
 .../hi/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/timeseries.mdx b/website/pages/hi/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..1e4dfb156048
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## अवलोकन
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### महत्वपूर्ण विचार
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+उदाहरण:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+उदाहरण:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+उदाहरण:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+उदाहरण:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### निष्कर्ष
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 46356ac94f40a7b0b8cc47b0953c7fa2e7793cb5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:26 -0500
Subject: [PATCH 1725/3820] New translations timeseries.mdx (Swahili)

---
 .../sw/subgraphs/cookbook/timeseries.mdx      | 194 ++++++++++++++++++
 1 file changed, 194 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/timeseries.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/timeseries.mdx b/website/pages/sw/subgraphs/cookbook/timeseries.mdx
new file mode 100644
index 000000000000..0168be53d7ed
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/timeseries.mdx
@@ -0,0 +1,194 @@
+---
+title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+---
+
+## TLDR
+
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+
+## Overview
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
+
+1. Improved Indexing Time
+
+- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+
+2. Simplified Mapping Code
+
+- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
+- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+
+3. Dramatically Faster Queries
+
+- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+
+### Important Considerations
+
+- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
+- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
+- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+
+## How to Implement Timeseries and Aggregations
+
+### Defining Timeseries Entities
+
+A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+
+- Immutable: Timeseries entities are always immutable.
+- Mandatory Fields:
+  - `id`: Must be of type `Int8!` and is auto-incremented.
+  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+
+Example:
+
+```graphql
+type Data @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  price: BigDecimal!
+}
+```
+
+### Defining Aggregation Entities
+
+An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+
+- Annotation Arguments:
+  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+
+Example:
+
+```graphql
+type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
+  id: Int8!
+  timestamp: Timestamp!
+  sum: BigDecimal! @aggregate(fn: "sum", arg: "price")
+}
+```
+
+In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+
+### Querying Aggregated Data
+
+Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+
+Example:
+
+```graphql
+{
+  tokenStats(
+    interval: "hour"
+    where: { token: "0x1234567890abcdef", timestamp_gte: "1704164640000000", timestamp_lt: "1704251040000000" }
+  ) {
+    id
+    timestamp
+    token {
+      id
+    }
+    totalVolume
+    priceUSD
+    count
+  }
+}
+```
+
+### Using Dimensions in Aggregations
+
+Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+
+Example:
+
+### Timeseries Entity
+
+```graphql
+type TokenData @entity(timeseries: true) {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  amount: BigDecimal!
+  priceUSD: BigDecimal!
+}
+```
+
+### Aggregation Entity with Dimension
+
+```graphql
+type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
+  id: Int8!
+  timestamp: Timestamp!
+  token: Token!
+  totalVolume: BigDecimal! @aggregate(fn: "sum", arg: "amount")
+  priceUSD: BigDecimal! @aggregate(fn: "last", arg: "priceUSD")
+  count: Int8! @aggregate(fn: "count", cumulative: true)
+}
+```
+
+- Dimension Field: token groups the data, so aggregates are computed per token.
+- Aggregates:
+  - totalVolume: Sum of amount.
+  - priceUSD: Last recorded priceUSD.
+  - count: Cumulative count of records.
+
+### Aggregation Functions and Expressions
+
+Supported aggregation functions:
+
+- sum
+- count
+- min
+- max
+- first
+- last
+
+### The arg in @aggregate can be
+
+- A field name from the timeseries entity.
+- An expression using fields and constants.
+
+### Examples of Aggregation Expressions
+
+- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+
+Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+
+### Query Parameters
+
+- interval: Specifies the time interval (e.g., "hour").
+- where: Filters based on dimensions and timestamp ranges.
+- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+
+### Notes
+
+- Sorting: Results are automatically sorted by timestamp and id in descending order.
+- Current Data: An optional current argument can include the current, partially filled interval.
+
+### Conclusion
+
+Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+
+- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
+- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
+- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+
+By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+
+## Subgraph Best Practices 1-6
+
+1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+
+2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+
+3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+
+4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+
+5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+
+6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)

From 0d9aa05e2479e20fd5332d8a5ec8ced1898352a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:27 -0500
Subject: [PATCH 1726/3820] New translations transfer-to-the-graph.mdx
 (Romanian)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/ro/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..194deb018404
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Example
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Additional Resources
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 2794c59899276baa60f90238dfcf805d9add8a25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:28 -0500
Subject: [PATCH 1727/3820] New translations transfer-to-the-graph.mdx (French)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/fr/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..78f59e46c7df
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Interroger votre Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Exemple
+
+[Subgraph Ethereum CryptoPunks](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) par Messari:
+
+![L'URL de requête](/img/cryptopunks-screenshot-transfer.png)
+
+L'URL de requête pour ce subgraph est :
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**votre-propre-clé-Api**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Maintenant, il vous suffit de remplir **votre propre clé API** pour commencer à envoyer des requêtes GraphQL à ce point de terminaison.
+
+### Obtenir votre propre clé API
+
+Vous pouvez créer des clés API dans Subgraph Studio sous le menu "API Keys" en haut de la page :
+
+![clés API](/img/Api-keys-screenshot.png)
+
+### Surveiller l'état du Subgraph
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Ressources complémentaires
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 4a845ed22316ed331655ff19164332eedf50839a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:29 -0500
Subject: [PATCH 1728/3820] New translations transfer-to-the-graph.mdx
 (Spanish)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/es/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/es/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..339032915f35
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Ejemplo
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Recursos Adicionales
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From f73a735986023680e3cf9ad2b21a0d82a4510293 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:30 -0500
Subject: [PATCH 1729/3820] New translations transfer-to-the-graph.mdx (Arabic)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/ar/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..f713ec3a5e76
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Example
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### مصادر إضافية
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 26fed6bf5ae4dc5331370d614fed97329cb90a8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:31 -0500
Subject: [PATCH 1730/3820] New translations transfer-to-the-graph.mdx (Czech)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/cs/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..3e4f8eee8ccf
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Použitím [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Příklad
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Další zdroje
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 831ab17feae8f71d78add74d24d05d634ae25d30 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:32 -0500
Subject: [PATCH 1731/3820] New translations transfer-to-the-graph.mdx (German)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/de/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/de/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..dc39d7be27b7
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Gehen Sie zu [Subgraph Studio] (https://thegraph.com/studio/) und verbinden Sie Ihre Wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Verwendung von [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Beispiel
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Additional Resources
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From f954d7e17dd2ffcd42d1c1b8a5e7c0b43fbefaac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:33 -0500
Subject: [PATCH 1732/3820] New translations transfer-to-the-graph.mdx
 (Italian)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/it/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/it/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..4c435d24f56c
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Esempio
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Additional Resources
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 4bc11e8463c04fefd89cd02d172698be06f5c07d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:35 -0500
Subject: [PATCH 1733/3820] New translations transfer-to-the-graph.mdx
 (Japanese)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/ja/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..6ef52284a5f5
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### 例
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### その他のリソース
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 4284de74dc470ff62f2d5bb7fe02c40fe75ba8a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:36 -0500
Subject: [PATCH 1734/3820] New translations transfer-to-the-graph.mdx (Korean)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/ko/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..194deb018404
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Example
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Additional Resources
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 2ea5f8913686f6dd6d469a31ffeb543dbbbb44f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:37 -0500
Subject: [PATCH 1735/3820] New translations transfer-to-the-graph.mdx (Dutch)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/nl/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..194deb018404
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Example
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Additional Resources
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From f90ddd5020d565c1507322d296e944eef85bc132 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:38 -0500
Subject: [PATCH 1736/3820] New translations transfer-to-the-graph.mdx (Polish)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/pl/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..194deb018404
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Example
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Additional Resources
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 5ee373d82d4f165717905120e4e74395fe47c94f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:39 -0500
Subject: [PATCH 1737/3820] New translations transfer-to-the-graph.mdx
 (Portuguese)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/pt/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..292d1f663b2f
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Uso de [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Exemplo
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Outros Recursos
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 19a9b817e1277462f7398523746383ec1cd3ad8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:40 -0500
Subject: [PATCH 1738/3820] New translations transfer-to-the-graph.mdx
 (Russian)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..a6af8dbadb20
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Перейдите в [Subgraph Studio](https://thegraph.com/studio/) и подключите свой кошелек.
+- Нажмите "Создать субграф". Рекомендуется называть субграф с использованием Заглавного регистра: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Использование [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Пример
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Дополнительные ресурсы
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 2b5d3e5a851f867a5e121d3ce419f1c231b12d85 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:41 -0500
Subject: [PATCH 1739/3820] New translations transfer-to-the-graph.mdx
 (Swedish)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/sv/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..f06ed1722258
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Exempel
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Ytterligare resurser
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 3325cd958065761c3f9d6479e5b210adeb44118a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:42 -0500
Subject: [PATCH 1740/3820] New translations transfer-to-the-graph.mdx
 (Turkish)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..7dab066a6fce
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- [Subgraph Studio](https://thegraph.com/studio/)'ya gidin ve cüzdanınızı bağlayın.
+- "Subgraph Oluştur" düğmesine tıklayın. Subgraph'in adını başlık formunda vermeniz önerilir: "Subgraph Adı Ağ Adı".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+[npm](https://www.npmjs.com/) kullanarak:
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Örnek
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Ek Kaynaklar
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From b96b80c99f3224aa705d3fb5c22fb1149c1c3e35 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:44 -0500
Subject: [PATCH 1741/3820] New translations transfer-to-the-graph.mdx
 (Ukrainian)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/uk/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..aed61c2c695b
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Example
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Додаткові матеріали
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 190a9c76cc701c40c44acad111ccc8f14a2b4121 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:45 -0500
Subject: [PATCH 1742/3820] New translations transfer-to-the-graph.mdx (Chinese
 Simplified)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/zh/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..497dc254ddf1
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### 示例
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### 其他资源
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 6c038e5eb4b17bf0a9819c4c5445de918e59fa47 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:46 -0500
Subject: [PATCH 1743/3820] New translations transfer-to-the-graph.mdx (Urdu
 (Pakistan))

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/ur/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..43fd50c14672
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+[npm](https://www.npmjs.com/) کا استعمال:
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### مثال
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### اضافی وسائل
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 0181e1b83d02ff6e718ebfe0431f292942c753fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:47 -0500
Subject: [PATCH 1744/3820] New translations transfer-to-the-graph.mdx
 (Vietnamese)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/vi/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..78493fe55b06
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Ví dụ
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Additional Resources
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 3a2249d61d0c96cc5796747dd115362b10536288 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:48 -0500
Subject: [PATCH 1745/3820] New translations transfer-to-the-graph.mdx
 (Marathi)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/mr/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..d31f9d8864b5
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### उदाहरण
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### अतिरिक्त संसाधने
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From e4dac809f5ef07bc1bdabf8d911f04ed7c3ec776 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:49 -0500
Subject: [PATCH 1746/3820] New translations transfer-to-the-graph.mdx (Hindi)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..cf3381b17419
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- [Subgraph Studio](https://thegraph.com/studio/) पर जाएँ और अपने वॉलेट को कनेक्ट करें।
+- "एक सबग्राफ बनाएं" पर क्लिक करें। सबग्राफ का नाम टाइटल केस में रखनाrecommended है: "सबग्राफ नाम चेन नाम"।
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### उदाहरण
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Additional Resources
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From a31a4144919fb407c55d149eb22845f9147c8099 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:50 -0500
Subject: [PATCH 1747/3820] New translations transfer-to-the-graph.mdx
 (Swahili)

---
 .../cookbook/transfer-to-the-graph.mdx        | 104 ++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/transfer-to-the-graph.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/sw/subgraphs/cookbook/transfer-to-the-graph.mdx
new file mode 100644
index 000000000000..194deb018404
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -0,0 +1,104 @@
+---
+title: Tranfer to The Graph
+---
+
+Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+
+## Benefits of Switching to The Graph
+
+- Use the same subgraph that your apps already use with zero-downtime migration.
+- Increase reliability from a global network supported by 100+ Indexers.
+- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+
+## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+
+1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+
+## 1. Set Up Your Studio Environment
+
+### Create a Subgraph in Subgraph Studio
+
+- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+
+### Install the Graph CLI⁠
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run the following command:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Use the following command to create a subgraph in Studio using the CLI:
+
+```sh
+graph init --product subgraph-studio
+```
+
+### Authenticate Your Subgraph
+
+In The Graph CLI, use the auth command seen in Subgraph Studio:
+
+```sh
+graph auth <your-auth-code>
+```
+
+## 2. Deploy Your Subgraph to Studio
+
+If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+
+In The Graph CLI, run the following command:
+
+```sh
+graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+
+```
+
+> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+
+## 3. Publish Your Subgraph to The Graph Network
+
+![publish button](/img/publish-sub-transfer.png)
+
+### Query Your Subgraph
+
+> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+
+You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+
+#### Example
+
+[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+
+![Query URL](/img/cryptopunks-screenshot-transfer.png)
+
+The query URL for this subgraph is:
+
+```sh
+https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+```
+
+Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+
+### Getting your own API Key
+
+You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+
+![API keys](/img/Api-keys-screenshot.png)
+
+### Monitor Subgraph Status
+
+Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+
+### Additional Resources
+
+- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 36edfde5302f4db7fd4852249843104039b6d8f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:51 -0500
Subject: [PATCH 1748/3820] New translations assemblyscript-mappings.mdx
 (Romanian)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/ro/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/ro/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..2ac894695fe1
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Overview
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Writing Mappings
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Recommended IDs for Creating New Entities
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## Code Generation
+
+In order to make it easy and type-safe to work with smart contracts, events and entities, the Graph CLI can generate AssemblyScript types from the subgraph's GraphQL schema and the contract ABIs included in the data sources.
+
+This is done with
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 585391402173de0cf63d4edb594fbc8ff9cf56dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:52 -0500
Subject: [PATCH 1749/3820] New translations assemblyscript-mappings.mdx
 (French)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..22d69907dbd2
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Aperçu
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Écriture de mappages
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### ID recommandés pour la création de nouvelles entités
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Traitement des entités ayant des identifiants identiques
+
+Lors de la création et de l'enregistrement d'une nouvelle entité, si une entité avec le même ID existe déjà, les propriétés de la nouvelle entité sont toujours préférées lors du processus de fusion. Cela signifie que l'entité existante sera mise à jour avec les valeurs de la nouvelle entité.
+
+Si une valeur nulle est intentionnellement définie pour un champ de la nouvelle entité avec le même ID, l'entité existante sera mise à jour avec la valeur nulle.
+
+Si aucune valeur n'est définie pour un champ de la nouvelle entité avec le même ID, le champ aura également la valeur null.
+
+## Génération de code
+
+Afin de faciliter et de sécuriser le travail avec les contrats intelligents, les événements et les entités, la CLI Graph peut générer des types AssemblyScript à partir du schéma GraphQL du subgraph et des ABI de contrat inclus dans les sources de données.
+
+Cela se fait avec
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // La classe de contrat :
+  Gravity,
+  // Les classes d'événements :
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 854edb8473f72a7f197cba73c6dcedfb43f1b88c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:53 -0500
Subject: [PATCH 1750/3820] New translations assemblyscript-mappings.mdx
 (Spanish)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/es/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/es/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..792a6521f82d
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Descripción
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Escribir Mappings
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### ID recomendados para la creación de nuevas entidades
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## Generación de código
+
+Para que trabajar con contratos inteligentes, eventos y entidades sea fácil y seguro desde el punto de vista de los tipos, Graph CLI puede generar tipos AssemblyScript a partir del esquema GraphQL del subgrafo y de las ABIs de los contratos incluidas en las fuentes de datos.
+
+Esto se hace con
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 2b2a9ac42e4c2ba6daf3bf1328a59414072aaf07 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:54 -0500
Subject: [PATCH 1751/3820] New translations assemblyscript-mappings.mdx
 (Arabic)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/ar/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/ar/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..2518d7620204
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## نظره عامة
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## كتابة الـ Mappings
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### الـ IDs الموصى بها لإنشاء كيانات جديدة
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## توليد الكود
+
+In order to make it easy and type-safe to work with smart contracts, events and entities, the Graph CLI can generate AssemblyScript types from the subgraph's GraphQL schema and the contract ABIs included in the data sources.
+
+This is done with
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+'import { Gravatar } from '../generated/schema
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 31e292f88df57d47be457e1e7f318e05747cc2c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:56 -0500
Subject: [PATCH 1752/3820] New translations assemblyscript-mappings.mdx
 (Czech)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/cs/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/cs/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..fad0d6ebaa1a
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Přehled
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Psát mapování
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Doporučené IDa pro vytváření nových Entity
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Zpracování entit se stejnými ID
+
+Pokud při vytváření a ukládání nové entity již existuje entita se stejným ID, jsou při slučování vždy upřednostněny vlastnosti nové entity. To znamená, že existující entita bude aktualizována hodnotami z nové entity.
+
+Pokud je pro pole v nové entitě se stejným ID záměrně nastavena nulová hodnota, bude stávající entita aktualizována s nulovou hodnotou.
+
+Pokud není pro pole v nové entitě se stejným ID nastavena žádná hodnota, bude pole rovněž nulové.
+
+## Generování kódu
+
+Aby byla práce s inteligentními smlouvami, událostmi a entitami snadná a typově bezpečná, může Graf CLI generovat typy AssemblyScript ze schématu GraphQL podgrafu a ABI smluv obsažených ve zdrojích dat.
+
+To se provádí pomocí
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 1f02354e0839ba32f5af744832b17eae9c90c6d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:57 -0500
Subject: [PATCH 1753/3820] New translations assemblyscript-mappings.mdx
 (German)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/de/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/de/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..2ac894695fe1
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Overview
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Writing Mappings
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Recommended IDs for Creating New Entities
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## Code Generation
+
+In order to make it easy and type-safe to work with smart contracts, events and entities, the Graph CLI can generate AssemblyScript types from the subgraph's GraphQL schema and the contract ABIs included in the data sources.
+
+This is done with
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 912a193ed6174239b0907733df1c77a90b63a1e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:58 -0500
Subject: [PATCH 1754/3820] New translations assemblyscript-mappings.mdx
 (Italian)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/it/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/it/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..23271ae9c85c
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Panoramica
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Scrivere le mappature
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### ID consigliati per la creazione di nuove entità
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## Generazione del codice
+
+Per rendere semplice e sicuro il lavoro con gli smart contract, gli eventi e le entità, la Graph CLI può generare tipi AssemblyScript dallo schema GraphQL del subgraph e dagli ABI dei contratti inclusi nelle data source.
+
+Questo viene fatto con
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From d05ecd4cc86a7b57a652506eb4ebcea1935701ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:15:59 -0500
Subject: [PATCH 1755/3820] New translations assemblyscript-mappings.mdx
 (Japanese)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/ja/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/ja/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..50b664c86f3b
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## 概要
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## マッピングの記述
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### 新規エンティティ作成時の推奨 ID
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## コード生成
+
+スマートコントラクト、イベント、エンティティを簡単かつタイプセーフに扱うために、Graph CLIはサブグラフのGraphQLスキーマとデータソースに含まれるコントラクトABIからAssemblyScriptタイプを生成することができます。
+
+これを行うためには
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From ac4893e9719c75a1e2cd27e23f6327a140703f9d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:00 -0500
Subject: [PATCH 1756/3820] New translations assemblyscript-mappings.mdx
 (Korean)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/ko/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/ko/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..2ac894695fe1
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Overview
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Writing Mappings
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Recommended IDs for Creating New Entities
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## Code Generation
+
+In order to make it easy and type-safe to work with smart contracts, events and entities, the Graph CLI can generate AssemblyScript types from the subgraph's GraphQL schema and the contract ABIs included in the data sources.
+
+This is done with
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From ff4c369fbe151c0011cc91f63a59994da2314306 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:01 -0500
Subject: [PATCH 1757/3820] New translations assemblyscript-mappings.mdx
 (Dutch)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/nl/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/nl/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..2ac894695fe1
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Overview
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Writing Mappings
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Recommended IDs for Creating New Entities
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## Code Generation
+
+In order to make it easy and type-safe to work with smart contracts, events and entities, the Graph CLI can generate AssemblyScript types from the subgraph's GraphQL schema and the contract ABIs included in the data sources.
+
+This is done with
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 61e1eaa5ca1eafcfbb406d6807ca3393b91e13c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:02 -0500
Subject: [PATCH 1758/3820] New translations assemblyscript-mappings.mdx
 (Polish)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/pl/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/pl/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..2ac894695fe1
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Overview
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Writing Mappings
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Recommended IDs for Creating New Entities
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## Code Generation
+
+In order to make it easy and type-safe to work with smart contracts, events and entities, the Graph CLI can generate AssemblyScript types from the subgraph's GraphQL schema and the contract ABIs included in the data sources.
+
+This is done with
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 810c32a390b0f5d9bd145f5bfa58bbe5e40626b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:03 -0500
Subject: [PATCH 1759/3820] New translations assemblyscript-mappings.mdx
 (Portuguese)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/pt/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/pt/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..e7d972a9d0bf
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Visão geral
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Como Escrever Mapeamentos
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### IDs Recomendadas para Criar Novas Entidades
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Gestão de entidades com IDs idênticas
+
+Ao criar e salvar uma nova entidade, se já houver uma com a mesma ID, vale sempre usar as propriedades da nova entidade durante o processo de fusão. Isto significa que a entidade existente será atualizada com os valores da entidade nova.
+
+Se um valor nulo for propositadamente determinado para um campo na nova entidade com a mesma ID, a entidade existente será atualizada com o valor nulo.
+
+Se nenhum valor for inserido para um campo na nova entidade com a mesma ID, o campo também resultará em nulo.
+
+## Geração de Código
+
+Para tornar mais fácil e seguro a tipos o trabalho com contratos inteligentes, eventos e entidades, o Graph CLI pode gerar tipos de AssemblyScript a partir do schema GraphQL do subgraph e das ABIs de contratos incluídas nas fontes de dados.
+
+Isto é feito com
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // Classe do contrato:
+  Gravity,
+  // Classes de eventos:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 96845c3677bf505ebb01c01a327b6be8bcf4de0b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:04 -0500
Subject: [PATCH 1760/3820] New translations assemblyscript-mappings.mdx
 (Russian)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/ru/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/ru/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..e4c398204f2e
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Обзор
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Написание мэппингов
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Рекомендуемые идентификаторы для создания новых объектов
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Обработка объектов с одинаковыми идентификаторами
+
+При создании и сохранении нового объекта, если объект с таким же идентификатором уже существует, в процессе слияния приоритетны свойства нового объекта. Это означает, что существующий объект будет обновлен значениями из нового объекта.
+
+Если для поля нового объекта с тем же идентификатором намеренно установлено нулевое значение, существующий объект будет обновлен с использованием нулевого значения.
+
+Если для поля в новом объекте с тем же идентификатором не установлено значение, поле также будет иметь значение null.
+
+## Генерация кода
+
+Для упрощения и обеспечения безопасности типов при работе со смарт-контрактами, событиями и объектами Graph CLI может генерировать типы AssemblyScript на основе схемы GraphQL субграфа и ABI контрактов, включенных в источники данных.
+
+Это делается с помощью
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 16d73ed85c1416dd815d0a78d9b76b53eb522c95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:05 -0500
Subject: [PATCH 1761/3820] New translations assemblyscript-mappings.mdx
 (Swedish)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/sv/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/sv/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..646645e79ccc
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Översikt
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Skriv Mappningar
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from "../generated/Gravity/Gravity";
+import { Gravatar } from "../generated/schema";
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id);
+  gravatar.owner = event.params.owner;
+  gravatar.displayName = event.params.displayName;
+  gravatar.imageUrl = event.params.imageUrl;
+  gravatar.save();
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id;
+  let gravatar = Gravatar.load(id);
+  if (gravatar == null) {
+    gravatar = new Gravatar(id);
+  }
+  gravatar.owner = event.params.owner;
+  gravatar.displayName = event.params.displayName;
+  gravatar.imageUrl = event.params.imageUrl;
+  gravatar.save();
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Rekommenderade ID:n för att skapa nya entiteter
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## Kodgenerering
+
+För att göra det enkelt och typsäkert att arbeta med smarta kontrakt, händelser och entiteter kan Graph CLI generera AssemblyScript-typer från subgrafens GraphQL-schema och kontrakts-ABIn som ingår i datakällorna.
+
+Detta görs med
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from "../generated/Gravity/Gravity";
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from "../generated/schema"
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 56e9a9ffdf3b75a41e3b1194643ab6a835ed7fda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:06 -0500
Subject: [PATCH 1762/3820] New translations assemblyscript-mappings.mdx
 (Turkish)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/tr/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/tr/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..d3182334749c
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Genel Bakış
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Eşleştirmeleri Yazma
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Yeni Varlıklar Oluşturmak için Önerilen Kimlikler(IDs)
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Aynı ID'ye sahip varlıkların işlenmesi
+
+Yeni bir varlık oluşturup kaydederken, aynı ID'ye sahip bir varlık zaten mevcutsa, birleştirme sürecinde her zaman yeni varlığın özellikleri tercih edilir. Bu, mevcut varlığın yeni varlıktan gelen değerlerle güncelleneceği anlamına gelir.
+
+Eğer aynı ID'ye sahip yeni bir varlıkta bir alana kasıtlı olarak null değeri atanmışsa, mevcut varlıkta bu alan null değeriyle güncellenir.
+
+Eğer aynı ID'ye sahip yeni bir varlıkta bir alan için değer atanmamışsa, o alan da null olacaktır.
+
+## Kod Oluşturma
+
+Akıllı sözleşmeler, olaylar ve varlıklarla çalışmayı kolay ve tip güvenli hale getirmek amacıyla Graph CLI, subgraph'ın GraphQL şemasından ve veri kaynaklarında bulunan sözleşme ABI'lerinden AssemblyScript türleri oluşturabilir.
+
+Bununla yapılır
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // Kontrat sınıfı:
+  Gravity,
+  // Olayların sınıfları:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 6365df93abedde0d5c54c5386c28153b1b05e5b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:07 -0500
Subject: [PATCH 1763/3820] New translations assemblyscript-mappings.mdx
 (Ukrainian)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/uk/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/uk/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..2ac894695fe1
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Overview
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Writing Mappings
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Recommended IDs for Creating New Entities
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## Code Generation
+
+In order to make it easy and type-safe to work with smart contracts, events and entities, the Graph CLI can generate AssemblyScript types from the subgraph's GraphQL schema and the contract ABIs included in the data sources.
+
+This is done with
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 42a1223aade03d0d3621a53ed218593faef5df7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:08 -0500
Subject: [PATCH 1764/3820] New translations assemblyscript-mappings.mdx
 (Chinese Simplified)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/zh/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/zh/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..88028e162e55
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## 概述
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## 编写映射
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### 用于创建新实体的推荐 ID
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## 代码生成
+
+为了使与智能合约、事件和实体的代码编写工作变得简单且类型安全，Graph CLI 可以从子图的 GraphQL 模式和数据源中包含的合约 ABI 生成 AssemblyScript 类型。
+
+这可以通过以下命令实现
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 7c6656f4fdf6c487acde5d404c87dbea54850ca5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:09 -0500
Subject: [PATCH 1765/3820] New translations assemblyscript-mappings.mdx (Urdu
 (Pakistan))

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/ur/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/ur/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..28f2936bb14f
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## جائزہ
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## میپنگ لکھنا
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### نئ ہستیوں بنانے کے لیے تجویز کردہ IDs
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## کوڈ تخلیق کرنا
+
+سمارٹ کنٹریکٹس، ایوینٹس اور ہستیوں کے ساتھ کام کرنا آسان اور ٹائپ محفوظ بنانے کے لیے، گراف CLI ڈیٹا کے ذرائع میں شامل سب گراف کے GraphQL اسکیما اور کنٹریکٹ ABIs سے اسمبلی سکرپٹ کی قسمیں تیار کر سکتا ہے.
+
+اس کے ساتھ کیا جاتا ہے
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 0bd5f51b25dbc8d2b6f190f5561bebcb97269946 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:11 -0500
Subject: [PATCH 1766/3820] New translations assemblyscript-mappings.mdx
 (Vietnamese)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/vi/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/vi/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..8a1d491a50fd
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Tổng quan
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Viết Ánh xạ
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Các ID được Đề xuất để tạo các Thực thể Mới
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## Tạo mã
+
+In order to make it easy and type-safe to work with smart contracts, events and entities, the Graph CLI can generate AssemblyScript types from the subgraph's GraphQL schema and the contract ABIs included in the data sources.
+
+This is done with
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From df98f98ffcab61ff0b827998680df782672777b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:12 -0500
Subject: [PATCH 1767/3820] New translations assemblyscript-mappings.mdx
 (Marathi)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/mr/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/mr/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..682aec0ae2a5
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## सविश्लेषण
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## मॅपिंग लेखन
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### नवीन संस्था तयार करण्यासाठी शिफारस केलेले आयडी
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## कोड जनरेशन
+
+स्मार्ट कॉन्ट्रॅक्ट्स, इव्हेंट्स आणि संस्थांसोबत काम करणे सोपे आणि टाइप-सुरक्षित करण्यासाठी, ग्राफ CLI सबग्राफच्या GraphQL स्कीमा आणि डेटा स्रोतांमध्ये समाविष्ट केलेल्या कॉन्ट्रॅक्ट ABIs मधून असेंबलीस्क्रिप्ट प्रकार व्युत्पन्न करू शकतो.
+
+यासह केले जाते
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From a476ad861ff25132711b96620bc7c6c92738eb67 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:13 -0500
Subject: [PATCH 1768/3820] New translations assemblyscript-mappings.mdx
 (Hindi)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/hi/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/hi/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..38441c623127
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## अवलोकन
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## मैपिंग लिखना
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### नई संस्थाओं को बनाने के लिए अनुशंसित आईडी
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### एक समान आईडी वाले एंटिटीज़ का प्रबंधन
+
+जब एक नई इकाई बनाते और सहेजते हैं, यदि एक ही ID वाली इकाई पहले से मौजूद है, तो मर्ज प्रक्रिया के दौरान नई इकाई के गुणों को हमेशा प्राथमिकता दी जाती है। इसका मतलब है कि मौजूदा इकाई को नई इकाई के मानों के साथ अपडेट किया जाएगा।
+
+यदि एक नया एन्टिटी जिसमें समान ID है, के लिए किसी फील्ड के लिए जानबूझकर एक null मान सेट किया जाता है, तो मौजूदा एन्टिटी को null मान के साथ अपडेट किया जाएगा।
+
+यदि समान ID वाली नई entity में किसी field के लिए कोई मान set नहीं किया गया है, तो field का result भी null हो जाएगा।
+
+## कोड जनरेशन
+
+स्मार्ट कॉन्ट्रैक्ट्स, इवेंट्स और एंटिटीज के साथ काम करना आसान और टाइप-सेफ बनाने के लिए, ग्राफ सीएलआई सबग्राफ के ग्राफक्यूएल स्कीमा और डेटा स्रोतों में शामिल कॉन्ट्रैक्ट एबीआई से असेंबलीस्क्रिप्ट प्रकार उत्पन्न कर सकता है।
+
+इसके साथ किया जाता है
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From ab2fadab6519248ae300e65262c6454c664f197a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:14 -0500
Subject: [PATCH 1769/3820] New translations assemblyscript-mappings.mdx
 (Swahili)

---
 .../creating/assemblyscript-mappings.mdx      | 113 ++++++++++++++++++
 1 file changed, 113 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/creating/assemblyscript-mappings.mdx

diff --git a/website/pages/sw/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/sw/subgraphs/developing/creating/assemblyscript-mappings.mdx
new file mode 100644
index 000000000000..2ac894695fe1
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -0,0 +1,113 @@
+---
+title: Writing AssemblyScript Mappings
+---
+
+## Overview
+
+The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+
+## Writing Mappings
+
+For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+
+In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+
+```javascript
+import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
+import { Gravatar } from '../generated/schema'
+
+export function handleNewGravatar(event: NewGravatar): void {
+  let gravatar = new Gravatar(event.params.id)
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+
+export function handleUpdatedGravatar(event: UpdatedGravatar): void {
+  let id = event.params.id
+  let gravatar = Gravatar.load(id)
+  if (gravatar == null) {
+    gravatar = new Gravatar(id)
+  }
+  gravatar.owner = event.params.owner
+  gravatar.displayName = event.params.displayName
+  gravatar.imageUrl = event.params.imageUrl
+  gravatar.save()
+}
+```
+
+The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+
+The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+
+### Recommended IDs for Creating New Entities
+
+It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+
+- `transfer.id = event.transaction.hash`
+
+- `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
+
+- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+
+```typescript
+let dayID = event.block.timestamp.toI32() / 86400
+let id = Bytes.fromI32(dayID)
+```
+
+- Convert constant addresses to `Bytes`.
+
+`const id = Bytes.fromHexString('0xdead...beef')`
+
+There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+
+### Handling of entities with identical IDs
+
+When creating and saving a new entity, if an entity with the same ID already exists, the properties of the new entity are always preferred during the merge process. This means that the existing entity will be updated with the values from the new entity.
+
+If a null value is intentionally set for a field in the new entity with the same ID, the existing entity will be updated with the null value.
+
+If no value is set for a field in the new entity with the same ID, the field will result in null as well.
+
+## Code Generation
+
+In order to make it easy and type-safe to work with smart contracts, events and entities, the Graph CLI can generate AssemblyScript types from the subgraph's GraphQL schema and the contract ABIs included in the data sources.
+
+This is done with
+
+```sh
+graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+```
+
+but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+
+```sh
+# Yarn
+yarn codegen
+
+# NPM
+npm run codegen
+```
+
+This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+
+```javascript
+import {
+  // The contract class:
+  Gravity,
+  // The events classes:
+  NewGravatar,
+  UpdatedGravatar,
+} from '../generated/Gravity/Gravity'
+```
+
+In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+
+```javascript
+import { Gravatar } from '../generated/schema'
+```
+
+> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+
+Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.

From 92b6b7e726acd5a23d88ae2f74f8e61ed26b6a1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:15 -0500
Subject: [PATCH 1770/3820] New translations install-the-cli.mdx (Romanian)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/ro/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/ro/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..7d44ff8b2ee6
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Install the Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Overview
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Getting Started
+
+### Install the Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run one of the following commands:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Creează un Subgraf
+
+### From an Existing Contract
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### From an Example Subgraph
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+The ABI file(s) must match your contract(s). There are a few ways to obtain ABI files:
+
+- If you are building your own project, you will likely have access to your most current ABIs.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 4f5156c2c028e67dc878e4d6e340551838c3bc66 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:17 -0500
Subject: [PATCH 1771/3820] New translations install-the-cli.mdx (French)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..900b8d9e8f7d
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Installation du Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Aperçu
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Démarrage
+
+### Installation du Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+Sur votre machine locale, exécutez l'une des commandes suivantes :
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Créer un subgraph
+
+### À partir d'un contrat existant
+
+La commande suivante crée un subgraph qui indexe tous les événements d'un contrat existant :
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- La commande tente de récupérer l'ABI du contrat depuis Etherscan.
+
+  - Graph CLI repose sur un endpoint RPC public. Bien que des échecs occasionnels soient attendus, les réessais résolvent généralement ce problème. Si les échecs persistent, envisagez d'utiliser un ABI local.
+
+- Si certains arguments optionnels manquent, il vous guide à travers un formulaire interactif.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### À partir d'un exemple de subgraph
+
+La commande suivante initialise un nouveau projet à partir d'un exemple de subgraph :
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Spécificités⁠
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Récupération des ABIs
+
+Le(s) fichier(s) ABI doivent correspondre à votre(vos) contrat(s). Il existe plusieurs façons d'obtenir des fichiers ABI :
+
+- Si vous construisez votre propre projet, vous aurez probablement accès à vos ABI les plus récents.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## Versions disponibles de SpecVersion
+
+| Version | Notes de version                                                                                                                                                         |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Ajout de la prise en charge des gestionnaires d'événement ayant accès aux reçus de transactions.                                                                         |
+|  0.0.4  | Ajout de la prise en charge du management des fonctionnalités de subgraph.                                                                                               |

From fe11ae80ec0a2b00c63be2826c73ace1eb716574 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:18 -0500
Subject: [PATCH 1772/3820] New translations install-the-cli.mdx (Spanish)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/es/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/es/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..b605e2194260
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Instalar The Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Descripción
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Empezando
+
+### Instalar The Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+En tu dispositivo, ejecuta alguno de los siguientes comandos:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Crear un Subgrafo
+
+### Desde un Contrato Existente
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### De un Subgrafo de Ejemplo
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+Los archivos ABI deben coincidir con tu(s) contrato(s). Hay varias formas de obtener archivos ABI:
+
+- Si estás construyendo tu propio proyecto, es probable que tengas acceso a tus ABIs más actuales.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Version | Notas del lanzamiento                                                                                                                                                    |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From ec73fedcab61147316492f2677686cfedf313fdc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:19 -0500
Subject: [PATCH 1773/3820] New translations install-the-cli.mdx (Arabic)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/ar/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/ar/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..ce78d54e83b6
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: قم بتثبيت Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## نظره عامة
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Getting Started
+
+### قم بتثبيت Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run one of the following commands:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## إنشاء الـ Subgraph
+
+### من عقد موجود
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### من مثال Subgraph
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+يجب أن تتطابق ملف (ملفات) ABI مع العقد (العقود) الخاصة بك. هناك عدة طرق للحصول على ملفات ABI:
+
+- إذا كنت تقوم ببناء مشروعك الخاص ، فمن المحتمل أن تتمكن من الوصول إلى أحدث ABIs.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| الاصدار | ملاحظات الإصدار                                                                                                                                                          |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From e3455bfc91e0c1c2cb74a5557b6034194652ec12 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:20 -0500
Subject: [PATCH 1774/3820] New translations install-the-cli.mdx (Czech)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/cs/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/cs/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..48d32263b2f7
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Instalace Graf CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Přehled
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Začínáme
+
+### Instalace Graf CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+V místním počítači spusťte jeden z následujících příkazů:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Vytvoření podgrafu
+
+### Ze stávající smlouvy
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### Z příkladu podgrafu
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+Soubor(y) ABI se musí shodovat s vaší smlouvou. Soubory ABI lze získat několika způsoby:
+
+- Pokud vytváříte vlastní projekt, budete mít pravděpodobně přístup k nejaktuálnějším ABI.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Verze | Poznámky vydání                                                                                                                                                          |
+| :---: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+| 0.0.9 | Supports `endBlock` feature                                                                                                                                              |
+| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+| 0.0.6 | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+| 0.0.5 | Added support for event handlers having access to transaction receipts.                                                                                                  |
+| 0.0.4 | Added support for managing subgraph features.                                                                                                                            |

From bba2b2ff5d813969d12b00a8f4942af1801a160d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:21 -0500
Subject: [PATCH 1775/3820] New translations install-the-cli.mdx (German)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/de/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/de/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..174686f9672f
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Install the Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Overview
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Getting Started
+
+### Install the Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+Führen Sie einen der folgenden Befehle auf Ihrem lokalen Computer aus:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Create a Subgraph
+
+### From an Existing Contract
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### From an Example Subgraph
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Besonderheiten
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+The ABI file(s) must match your contract(s). There are a few ways to obtain ABI files:
+
+- If you are building your own project, you will likely have access to your most current ABIs.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From d218acf531eefeb0aaea3ddc74e3e3d21cbc2936 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:22 -0500
Subject: [PATCH 1776/3820] New translations install-the-cli.mdx (Italian)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/it/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/it/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..9b601cf35472
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Installare the Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Panoramica
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Getting Started
+
+### Installare the Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run one of the following commands:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Create a Subgraph
+
+### Da un contratto esistente
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### Da un subgraph di esempio
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+I file ABI devono corrispondere al vostro contratto. Esistono diversi modi per ottenere i file ABI:
+
+- Se state costruendo il vostro progetto, probabilmente avrete accesso alle ABI più recenti.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Versione | Note di rilascio                                                                                                                                                         |
+| :------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|   1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|   1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|   1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|   0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|   0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|   0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|   0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|   0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|   0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 520a5c4095d06ef1442813ccd28c7a43202c4236 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:23 -0500
Subject: [PATCH 1777/3820] New translations install-the-cli.mdx (Japanese)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/ja/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/ja/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..342b849853e8
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Graph CLI のインストール
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## 概要
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## はじめに
+
+### Graph CLI のインストール
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+ローカル マシンで、次のいずれかのコマンドを実行します。
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## サブグラフの作成
+
+### 既存のコントラクトから
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### サブグラフの例から
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+ABI ファイルは、契約内容と一致している必要があります。ABI ファイルを入手するにはいくつかの方法があります:
+
+- 自分のプロジェクトを構築している場合は、最新の ABI にアクセスできる可能性があります。
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| バージョン | リリースノート                                                                                                                                                                  |
+| :---: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+| 0.0.9 | Supports `endBlock` feature                                                                                                                                              |
+| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+| 0.0.6 | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+| 0.0.5 | Added support for event handlers having access to transaction receipts.                                                                                                  |
+| 0.0.4 | Added support for managing subgraph features.                                                                                                                            |

From bf09e1535962a7d554dd6a09c3792b8c7d9c80fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:24 -0500
Subject: [PATCH 1778/3820] New translations install-the-cli.mdx (Korean)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/ko/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/ko/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..4fd6483f544b
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Install the Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Overview
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Getting Started
+
+### Install the Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run one of the following commands:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Create a Subgraph
+
+### From an Existing Contract
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### From an Example Subgraph
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+The ABI file(s) must match your contract(s). There are a few ways to obtain ABI files:
+
+- If you are building your own project, you will likely have access to your most current ABIs.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 5143fd340f7eccdf49004d58a3f5583e30d8a11a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:25 -0500
Subject: [PATCH 1779/3820] New translations install-the-cli.mdx (Dutch)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/nl/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/nl/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..29e224e65481
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Install the Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Overview
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Getting Started
+
+### Install the Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run one of the following commands:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Creëer een Subgraph
+
+### From an Existing Contract
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### From an Example Subgraph
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+The ABI file(s) must match your contract(s). There are a few ways to obtain ABI files:
+
+- If you are building your own project, you will likely have access to your most current ABIs.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 75668bc0a960d2553485198f292a5a283f7192c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:26 -0500
Subject: [PATCH 1780/3820] New translations install-the-cli.mdx (Polish)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/pl/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/pl/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..4411e4801279
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Install the Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Overview
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Getting Started
+
+### Install the Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run one of the following commands:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Jak stworzyć subgraf
+
+### From an Existing Contract
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### From an Example Subgraph
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+The ABI file(s) must match your contract(s). There are a few ways to obtain ABI files:
+
+- If you are building your own project, you will likely have access to your most current ABIs.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 1b64942625d068530641641f377d8055c793287b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:27 -0500
Subject: [PATCH 1781/3820] New translations install-the-cli.mdx (Portuguese)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/pt/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/pt/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..738451f93b44
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Como instalar o Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Visão geral
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Como Começar
+
+### Como instalar o Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+Execute um dos seguintes comandos na sua máquina local:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Crie um Subgraph
+
+### De um Contrato Existente
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### De um Exemplo de Subgraph
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Especificações
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+Os arquivos da ABI devem combinar com o(s) seu(s) contrato(s). Há algumas maneiras de obter estes arquivos:
+
+- Caso construa o seu próprio projeto, provavelmente terá acesso às suas ABIs mais recentes.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Versão | Notas de atualização                                                                                                                                                     |
+| :----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9 | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6 | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5 | Adicionado apoio a handlers de eventos com acesso a recibos de transação.                                                                                                |
+|  0.0.4 | Adicionado apoio à gestão de recursos de subgraph.                                                                                                                       |

From 75617246304558d5bfd81c5efb109cf1838cd0f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:28 -0500
Subject: [PATCH 1782/3820] New translations install-the-cli.mdx (Russian)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/ru/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/ru/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..d796cfc9771a
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Установка Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Обзор
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Начало работы
+
+### Установка Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+Выполните одну из следующих команд на своём локальном компьютере:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Создайте субграф
+
+### Из существующего контракта
+
+Следующая команда создает субграф, индексирующий все события существующего контракта:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- Команда пытается получить ABI контракта из Etherscan.
+
+  - Интерфейс командной строки The Graph использует общедоступную конечную точку RPC. Несмотря на то, что возможны периодические сбои, повторные попытки обычно решают эту проблему. Если сбои продолжаются, рассмотрите возможность использования локального ABI.
+
+- Если какой-либо из необязательных аргументов отсутствует, Вам будет предложено воспользоваться интерактивной формой.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### Из примера подграфа
+
+Следующая команда инициализирует новый проект на примере субграфа:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Специфические особенности
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Получение ABIs
+
+Файл(ы) ABI должен(ы) соответствовать Вашему контракту (контрактам). Существует несколько способов получения файлов ABI:
+
+- Если Вы создаете свой собственный проект, у Вас, скорее всего, будет доступ к наиболее актуальным ABIS.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## Релизы SpecVersion
+
+| Версия | Примечания к релизу                                                                                                                                                      |
+| :----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9 | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6 | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5 | Добавлена поддержка обработчиков событий, имеющих доступ к чекам транзакций.                                                                                             |
+|  0.0.4 | Добавлена ​​поддержка управления функциями субграфа.                                                                                                                     |

From 102f36470109ff0e01dacd0526634b9c7084b842 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:30 -0500
Subject: [PATCH 1783/3820] New translations install-the-cli.mdx (Swedish)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/sv/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/sv/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..fb162d4f4390
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Installera Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Översikt
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Komma igång
+
+### Installera Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+Kör ett av följande kommandon på din lokala dator:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Skapa en Subgraf
+
+### Från ett befintligt avtal
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### Från ett exempel på en undergraf
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+ABI-filerna måste matcha ditt/dina kontrakt. Det finns några olika sätt att få ABI-filer:
+
+- Om du bygger ditt eget projekt har du förmodligen tillgång till dina senaste ABIs.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Version | Versionsanteckningar                                                                                                                                                     |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From ccf0ee71b68a58390097f75a2df50729bff0b571 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:31 -0500
Subject: [PATCH 1784/3820] New translations install-the-cli.mdx (Turkish)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/tr/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/tr/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..abda1be0f656
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Graph CLI'ı Yükleyin
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Genel Bakış
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Buradan Başlayın
+
+### Graph CLI'ı Yükleyin
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+Yerel makinenizde aşağıdaki komutlardan birini çalıştırın:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Subgraph Oluştur
+
+### Mevcut Bir Sözleşmeden
+
+Aşağıdaki komut, mevcut bir sözleşmenin tüm olaylarını endeksleyen bir subgraph oluşturur:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- Bu komut, sözleşme ABI'sini Etherscan’den almaya çalışır.
+
+  - Graph CLI, bir umumi RPC uç noktasına bağlıdır. Ara sıra başarısızlık beklenebilir, ancak genellikle yeniden denemeler sorunu çözer. Sorunlar devam ederse, yerel bir ABI kullanmayı düşünün.
+
+- İsteğe bağlı argümanlar eksikse, komut sizi bir etkileşimli forma yönlendirir.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### Örnek Bir Subgraph'ten
+
+Aşağıdaki komut, örnek bir subgraph'ten yeni bir proje ilklendirir:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Ayrıntılar
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### ABI’lerin Elde Edilmesi
+
+ABI dosya(lar)ı sözleşme(ler) inizle uygun olmalıdır. ABI dosyalarını edinmek için birkaç yol vardır:
+
+- Kendi projenizi oluşturuyorsanız, muhtemelen en güncel ABI'lerinize erişiminiz olacaktır.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Sürümleri
+
+| Sürüm | Sürüm Notları                                                                                                                                                            |
+| :---: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+| 0.0.9 | Supports `endBlock` feature                                                                                                                                              |
+| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+| 0.0.6 | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+| 0.0.5 | İşleyicilerin işlem makbuzlarına erişim desteği eklendi.                                                                                                                 |
+| 0.0.4 | Subgraph özelliklerini yönetme desteği eklendi.                                                                                                                          |

From 8c832ce22aa8b6bb31f07df12c6177d19fbc1290 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:32 -0500
Subject: [PATCH 1785/3820] New translations install-the-cli.mdx (Ukrainian)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/uk/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/uk/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..72176bc552bf
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Install the Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Overview
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Getting Started
+
+### Install the Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+На вашому локальному комп'ютері запустіть одну з наведених нижче команд:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Створення субграфа
+
+### From an Existing Contract
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### From an Example Subgraph
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+The ABI file(s) must match your contract(s). There are a few ways to obtain ABI files:
+
+- If you are building your own project, you will likely have access to your most current ABIs.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 4b0c2d1a8f53af84293dd25c4d75bbec4f1794ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:33 -0500
Subject: [PATCH 1786/3820] New translations install-the-cli.mdx (Chinese
 Simplified)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/zh/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/zh/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..577be7a5feeb
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: 安装 Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## 概述
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## 开始
+
+### 安装 Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+在本地计算机上，运行以下命令之一：
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## 创建子图
+
+### 基于现有合约
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### 基于子图示例
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+ABI 文件必须与您的合约相匹配。 获取 ABI 文件的方法有以下几种：
+
+- 如果您正在构建自己的项目，您可以获取最新的 ABI。
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+|   版本  | Release 说明                                                                                                                                                               |
+| :---: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+| 0.0.9 | Supports `endBlock` feature                                                                                                                                              |
+| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+| 0.0.6 | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+| 0.0.5 | Added support for event handlers having access to transaction receipts.                                                                                                  |
+| 0.0.4 | Added support for managing subgraph features.                                                                                                                            |

From b13bb248888b6fee16fda855fe4e6b83917b73cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:34 -0500
Subject: [PATCH 1787/3820] New translations install-the-cli.mdx (Urdu
 (Pakistan))

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/ur/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/ur/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..d70293bb6e89
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: گراف CLI انسٹال کریں
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## جائزہ
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## شروع ہوا چاہتا ہے
+
+### گراف CLI انسٹال کریں
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+اپنی مقامی مشین پر، درج زیل کمانڈز میں سے ایک کو رن کریں:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## سب گراف بنائیں
+
+### ایک موجودہ کنٹریکٹ سے
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### ایک مثالی سب گراف سے
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+ABI فائل (فائلیں) آپ کے کنٹریکٹ (کنٹریکٹس) سے مماثل ہونی چاہیں. ABI کی فائلیں حاصل کرنے کے چند طریقے ہیں:
+
+- اگر آپ اپنا پراجیکٹ خود بنا رہے ہیں، تو ممکنہ طور پر آپ کو اپنے حالیہ ABIs تک رسائی حاصل ہوگی.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+|  ورزن | جاری کردہ نوٹس                                                                                                                                                           |
+| :---: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1.2.0 | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+| 1.1.0 | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+| 1.0.0 | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+| 0.0.9 | Supports `endBlock` feature                                                                                                                                              |
+| 0.0.8 | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+| 0.0.7 | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+| 0.0.6 | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+| 0.0.5 | Added support for event handlers having access to transaction receipts.                                                                                                  |
+| 0.0.4 | Added support for managing subgraph features.                                                                                                                            |

From da4611af7e58f9c89215cbf908ddaa15237b8e1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:35 -0500
Subject: [PATCH 1788/3820] New translations install-the-cli.mdx (Vietnamese)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/vi/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/vi/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..a3ce4d94137f
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Cài đặt Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Tổng quan
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Getting Started
+
+### Cài đặt Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run one of the following commands:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Tạo một Subgraph
+
+### From an Existing Contract
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### From an Example Subgraph
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+(Các) tệp ABI phải khớp với (các) hợp đồng của bạn. Có một số cách để lấy tệp ABI:
+
+- Nếu bạn đang xây dựng dự án của riêng mình, bạn có thể sẽ có quyền truy cập vào các ABI mới nhất của mình.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Phiên bản | Ghi chú phát hành                                                                                                                                                        |
+| :-------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|   1.2.0   | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|   1.1.0   | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|   1.0.0   | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|   0.0.9   | Supports `endBlock` feature                                                                                                                                              |
+|   0.0.8   | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|   0.0.7   | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|   0.0.6   | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|   0.0.5   | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|   0.0.4   | Added support for managing subgraph features.                                                                                                                            |

From 103e2a00ba06875567e463334cbb55afc041864c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:37 -0500
Subject: [PATCH 1789/3820] New translations install-the-cli.mdx (Marathi)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/mr/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/mr/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..421b1b1e2c1c
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Install the Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## सविश्लेषण
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## प्रारंभ करणे
+
+### Install the Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+तुमच्या स्थानिक मशीनवर, खालीलपैकी एक कमांड चालवा:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## सबग्राफ तयार करा
+
+### विद्यमान करारातून
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### सबग्राफच्या उदाहरणावरून
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+The ABI file(s) must match your contract(s). There are a few ways to obtain ABI files:
+
+- If you are building your own project, you will likely have access to your most current ABIs.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| आवृत्ती | रिलीझ नोट्स                                                                                                                                                              |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 7cb3152afe9d8cafd2a3a4b42c03185453424d0f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:38 -0500
Subject: [PATCH 1790/3820] New translations install-the-cli.mdx (Hindi)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/hi/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/hi/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..8a093b985cc3
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: . ग्राफ़ सीएलआई इनस्टॉल करें
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## अवलोकन
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## शुरू करना
+
+### . ग्राफ़ सीएलआई इनस्टॉल करें
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+अपनी स्थानीय मशीन पर, निम्न आदेशों में से कोई एक चलाएँ:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## एक सबग्राफ बनाएं
+
+### एक मौजूदा कॉन्ट्रैक्ट से
+
+यह कमांड एक subgraph बनाता है जो एक मौजूदा कॉन्ट्रैक्ट के सभी इवेंट्स को इंडेक्स करता है:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- कमांड Etherscan से कॉन्ट्रैक्ट ABI को पुनः प्राप्त करने की कोशिश करता है।
+
+  - The Graph CLI एक सार्वजनिक RPC एंडपॉइंट पर निर्भर करता है। जबकि कुछ असफलताएँ अपेक्षित हैं, पुनः प्रयास आमतौर पर इस समस्या को हल कर देते हैं। यदि असफलताएँ बनी रहती हैं, तो एक स्थानीय ABI का उपयोग करने पर विचार करें।
+
+- यदि कोई वैकल्पिक तर्क गायब है, तो यह आपको एक इंटरैक्टिव फॉर्म के माध्यम से मार्गदर्शन करता है।
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### एक उदाहरण सबग्राफ से
+
+निम्नलिखित कमांड एक उदाहरण subgraph से एक नया प्रोजेक्ट प्रारंभ करता है:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### विशिष्टताएँ
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### एबीआई प्राप्त करना
+
+एबीआई फाइल(फाइलों) को आपके अनुबंध(ओं) से मेल खाना चाहिए। ABI फ़ाइलें प्राप्त करने के कुछ तरीके हैं:
+
+- यदि आप अपना खुद का प्रोजेक्ट बना रहे हैं, तो आपके पास अपने सबसे मौजूदा एबीआई तक पहुंच होने की संभावना है।
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## स्पेकवर्जन रिलीज़
+
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | घटना हैंडलरों को लेनदेन रसीदों तक पहुंच प्रदान करने के लिए समर्थन जोड़ा गया है।                                                                                          |
+|  0.0.4  | घटना हैंडलरों को लेनदेन रसीदों तक पहुंच प्रदान करने के लिए समर्थन जोड़ा गया है।                                                                                          |

From 2a9b6690ea05cf6651fc7dedaa588f45ba8811de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:39 -0500
Subject: [PATCH 1791/3820] New translations install-the-cli.mdx (Swahili)

---
 .../developing/creating/install-the-cli.mdx   | 119 ++++++++++++++++++
 1 file changed, 119 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/creating/install-the-cli.mdx

diff --git a/website/pages/sw/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/sw/subgraphs/developing/creating/install-the-cli.mdx
new file mode 100644
index 000000000000..4fd6483f544b
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/creating/install-the-cli.mdx
@@ -0,0 +1,119 @@
+---
+title: Install the Graph CLI
+---
+
+> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+
+## Overview
+
+The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+
+## Getting Started
+
+### Install the Graph CLI
+
+The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+On your local machine, run one of the following commands:
+
+#### Using [npm](https://www.npmjs.com/)
+
+```bash
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+#### Using [yarn](https://yarnpkg.com/)
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+
+## Create a Subgraph
+
+### From an Existing Contract
+
+The following command creates a subgraph that indexes all events of an existing contract:
+
+```sh
+graph init \
+  --product subgraph-studio
+  --from-contract <CONTRACT_ADDRESS> \
+  [--network <ETHEREUM_NETWORK>] \
+  [--abi <FILE>] \
+  <SUBGRAPH_SLUG> [<DIRECTORY>]
+```
+
+- The command tries to retrieve the contract ABI from Etherscan.
+
+  - The Graph CLI relies on a public RPC endpoint. While occasional failures are expected, retries typically resolve this issue. If failures persist, consider using a local ABI.
+
+- If any of the optional arguments are missing, it guides you through an interactive form.
+
+- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+
+### From an Example Subgraph
+
+The following command initializes a new project from an example subgraph:
+
+```sh
+graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
+```
+
+- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+
+- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+
+### Add New `dataSources` to an Existing Subgraph
+
+`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+
+Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+
+```sh
+graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
+
+Options:
+
+      --abi <path>              Path to the contract ABI (default: download from Etherscan)
+      --contract-name           Name of the contract (default: Contract)
+      --merge-entities          Whether to merge entities with the same name (default: false)
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+#### Specifics
+
+The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+
+- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+
+  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+
+  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+
+- The contract `address` will be written to the `networks.json` for the relevant network.
+
+> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+
+### Getting The ABIs
+
+The ABI file(s) must match your contract(s). There are a few ways to obtain ABI files:
+
+- If you are building your own project, you will likely have access to your most current ABIs.
+- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
+- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+
+## SpecVersion Releases
+
+| Version | Release notes                                                                                                                                                            |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
+|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
+|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
+|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
+|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
+|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
+|  0.0.5  | Added support for event handlers having access to transaction receipts.                                                                                                  |
+|  0.0.4  | Added support for managing subgraph features.                                                                                                                            |

From 8a20fdc7b52e413a4442b56fb3b07ffd3c470172 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:40 -0500
Subject: [PATCH 1792/3820] New translations ql-schema.mdx (Romanian)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/ro/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ro/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..8e5789d66650
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Overview
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Good Example
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Bad Example
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Optional and Required Fields
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Built-In Scalar Types
+
+#### GraphQL Supported Scalars
+
+The following scalars are supported in the GraphQL API:
+
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+You can also create enums within a schema. Enums have the following syntax:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Entity Relationships
+
+An entity may have a relationship to one or more other entities in your schema. These relationships may be traversed in your queries. Relationships in The Graph are unidirectional. It is possible to simulate bidirectional relationships by defining a unidirectional relationship on either "end" of the relationship.
+
+Relationships are defined on entities just like any other field except that the type specified is that of another entity.
+
+#### One-To-One Relationships
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### One-To-Many Relationships
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Reverse Lookups
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived. Storing the relationship this way, rather than storing an array of entities on the 'many' side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.
+
+#### Example
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Many-To-Many Relationships
+
+For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.
+
+#### Example
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+This approach requires that queries descend into one additional level to retrieve, for example, the organizations for users:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+This more elaborate way of storing many-to-many relationships will result in less data stored for the subgraph, and therefore to a subgraph that is often dramatically faster to index and to query.
+
+### Adding comments to the schema
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Defining Fulltext Search Fields
+
+Fulltext search queries filter and rank entities based on a text search input. Fulltext queries are able to return matches for similar words by processing the query text input into stems before comparing them to the indexed text data.
+
+A fulltext query definition includes the query name, the language dictionary used to process the text fields, the ranking algorithm used to order the results, and the fields included in the search. Each fulltext query may span multiple fields, but all included fields must be from a single entity type.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Languages supported
+
+Choosing a different language will have a definitive, though sometimes subtle, effect on the fulltext search API. Fields covered by a fulltext query field are examined in the context of the chosen language, so the lexemes produced by analysis and search queries vary from language to language. For example: when using the supported Turkish dictionary "token" is stemmed to "toke" while, of course, the English dictionary will stem it to "token".
+
+Supported language dictionaries:
+
+| Code   | Dictionary |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Portuguese |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### Ranking Algorithms
+
+Supported algorithms for ordering results:
+
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | Use the match quality (0-1) of the fulltext query to order the results. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From 0389954ef5fc15e9f52b6fdb8be0ee40898a6e74 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:41 -0500
Subject: [PATCH 1793/3820] New translations ql-schema.mdx (French)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx b/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..4f107ff5f682
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Aperçu
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Définition des entités
+
+Avant de définir des entités, il est important de prendre du recul et de réfléchir à la manière dont vos données sont structurées et liées.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- Il peut être utile d'imaginer les entités comme des "objets contenant des données", plutôt que comme des événements ou des fonctions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- Par défaut, les entités sont mutables, ce qui signifie que les mappages peuvent charger des entités existantes, les modifier et stocker une nouvelle version de cette entité.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - Si des changements se produisent dans le même bloc où l'entité a été créée, alors les mappages peuvent effectuer des changements sur les entités immuables. Les entités immuables sont beaucoup plus rapides à écrire et à interroger, donc elles devraient être utilisées chaque fois que c'est possible.
+
+#### Bon exemple
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Mauvais exemple
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Champs facultatifs et obligatoires
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Types scalaires intégrés
+
+#### Scalaires pris en charge par GraphQL
+
+Les scalaires suivants sont supportés dans l'API GraphQL :
+
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Tableau d'octets, représenté sous forme de chaîne hexadécimale. Couramment utilisé pour les hachages et adresses Ethereum.                                                                                       |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+Vous pouvez également créer des énumérations dans un schéma. Les énumérations ont la syntaxe suivante :
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Relations entre entités
+
+Une entité peut avoir une relation avec une ou plusieurs autres entités de votre schéma. Ces relations pourront être parcourues dans vos requêtes. Les relations dans The Graph sont unidirectionnelles. Il est possible de simuler des relations bidirectionnelles en définissant une relation unidirectionnelle à chaque « extrémité » de la relation.
+
+Les relations sont définies sur les entités comme n'importe quel autre champ sauf que le type spécifié est celui d'une autre entité.
+
+#### Relations individuelles
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### Relations un-à-plusieurs
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Recherches inversées
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+Pour les relations un-à-plusieurs, la relation doit toujours être stockée du côté « un » et le côté « plusieurs » doit toujours être dérivé. Stocker la relation de cette façon, plutôt que de stocker un tableau d'entités du côté « plusieurs », entraînera des performances considérablement meilleures pour l'indexation et l'interrogation du sous-graphe. En général, le stockage de tableaux d’entités doit être évité autant que possible.
+
+#### Exemple
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Relations plusieurs-à-plusieurs
+
+Pour les relations plusieurs-à-plusieurs, telles que les utilisateurs pouvant appartenir à un nombre quelconque d'organisations, la manière la plus simple, mais généralement pas la plus performante, de modéliser la relation consiste à créer un tableau dans chacune des deux entités impliquées. Si la relation est symétrique, un seul côté de la relation doit être stocké et l’autre côté peut être dérivé.
+
+#### Exemple
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+Cette approche nécessite que les requêtes descendent vers un niveau supplémentaire pour récupérer, par exemple, les organisations des utilisateurs :
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+       # ceci est une entité UserOrganization
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+Cette manière plus élaborée de stocker des relations plusieurs-à-plusieurs entraînera moins de données stockées pour le subgraph, et donc vers un subgraph qui est souvent considérablement plus rapide à indexer et à interroger.
+
+### Ajouter des commentaires au schéma
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # identifiant unique et clé primaire de l'entité
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Définir les champs de recherche en texte intégral
+
+Les requêtes de recherche en texte intégral filtrent et classent les entités en fonction d'une entrée de recherche de texte. Les requêtes en texte intégral sont capables de renvoyer des correspondances pour des mots similaires en traitant le texte de la requête saisi en radicaux avant de les comparer aux données textuelles indexées.
+
+Une définition de requête en texte intégrale inclut le nom de la requête, le dictionnaire de langue utilisé pour traiter les champs de texte, l'algorithme de classement utilisé pour classer les résultats et les champs inclus dans la recherche. Chaque requête en texte intégral peut s'étendre sur plusieurs champs, mais tous les champs inclus doivent provenir d'un seul type d'entité.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Langues prises en charge
+
+Le choix d'une langue différente aura un effet définitif, bien que parfois subtil, sur l'API de recherche en texte intégral. Les champs couverts par un champ de requête en texte intégral sont examinés dans le contexte de la langue choisie, de sorte que les lexèmes produits par les requêtes d'analyse et de recherche varient d'une langue à l'autre. Par exemple : lorsque vous utilisez le dictionnaire turc pris en charge, "token" est dérivé de "toke", tandis que, bien sûr, le dictionnaire anglais le dérivera de "token".
+
+Dictionnaires de langues pris en charge :
+
+| Code   | Dictionnaire |
+| ------ | ------------ |
+| simple | General      |
+| da     | Danish       |
+| nl     | Dutch        |
+| en     | English      |
+| fi     | Finnish      |
+| fr     | French       |
+| de     | German       |
+| hu     | Hungarian    |
+| it     | Italian      |
+| no     | Norwegian    |
+| pt     | Portugais    |
+| ro     | Romanian     |
+| ru     | Russian      |
+| es     | Spanish      |
+| sv     | Swedish      |
+| tr     | Turkish      |
+
+### Algorithmes de classement
+
+Algorithmes de classement:
+
+| Algorithm     | Description                                                                                           |
+| ------------- | ----------------------------------------------------------------------------------------------------- |
+| rank          | Utilisez la qualité de correspondance (0-1) de la requête en texte intégral pour trier les résultats. |
+| proximitéRang | Similar to rank but also includes the proximity of the matches.                                       |

From 71848f8d7f2162e7e75447e9328a4a1243aee8c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:42 -0500
Subject: [PATCH 1794/3820] New translations ql-schema.mdx (Spanish)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/es/subgraphs/developing/creating/ql-schema.mdx b/website/pages/es/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..92e15ea31fe5
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Descripción
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Un buen ejemplo
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Un mal ejemplo
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Campos opcionales y obligatorios
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Tipos de Scalars incorporados
+
+#### GraphQL admite Scalars
+
+The following scalars are supported in the GraphQL API:
+
+| Tipo         | Descripción                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, representado como un string hexadecimal. Comúnmente utilizado para los hashes y direcciones de Ethereum.                                                                                             |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+También puedes crear enums dentro de un esquema. Los enums tienen la siguiente sintaxis:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Relaciones entre Entidades
+
+Una entidad puede tener una relación con otra u otras entidades de su esquema. Estas relaciones pueden ser recorridas en sus consultas. Las relaciones en The Graph son unidireccionales. Es posible simular relaciones bidireccionales definiendo una relación unidireccional en cada "extremo" de la relación.
+
+Las relaciones se definen en las entidades como cualquier otro campo, salvo que el tipo especificado es el de otra entidad.
+
+#### Relaciones Uno a Uno
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### Relaciones one-to-many
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Búsquedas Inversas
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+En el caso de las relaciones one-to-many, la relación debe almacenarse siempre en el lado "one", y el lado "many" debe derivarse siempre. Almacenar la relación de esta manera, en lugar de almacenar una array de entidades en el lado "many", resultará en un rendimiento dramáticamente mejor tanto para la indexación como para la consulta del subgrafo. En general, debe evitarse, en la medida de lo posible, el almacenamiento de arrays de entidades.
+
+#### Ejemplo
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Relaciones de many-to-many
+
+Para las relaciones de many-to-many, como los usuarios pueden pertenecer a cualquier número de organizaciones, la forma más directa, pero generalmente no la más eficaz, de modelar la relación es en un array en cada una de las dos entidades implicadas. Si la relación es simétrica, sólo es necesario almacenar un lado de la relación y el otro puede derivarse.
+
+#### Ejemplo
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+Este enfoque requiere que las consultas desciendan a un nivel adicional para recuperar, por ejemplo, las organizaciones para los usuarios:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+Esta forma más elaborada de almacenar las relaciones many-to-many se traducirá en menos datos almacenados para el subgrafo y, por tanto, en un subgrafo que suele ser mucho más rápido de indexar y consultar.
+
+### Agregar comentarios al esquema
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Definición de campos de búsqueda de texto completo
+
+Las consultas de búsqueda de texto completo filtran y clasifican las entidades basándose en una entrada de búsqueda de texto. Las consultas de texto completo pueden devolver coincidencias de palabras similares procesando el texto de la consulta en stems antes de compararlo con los datos del texto indexado.
+
+La definición de una consulta de texto completo incluye el nombre de la consulta, el diccionario lingüístico utilizado para procesar los campos de texto, el algoritmo de clasificación utilizado para ordenar los resultados y los campos incluidos en la búsqueda. Cada consulta de texto completo puede abarcar varios campos, pero todos los campos incluidos deben ser de un solo tipo de entidad.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Idiomas admitidos
+
+La elección de un idioma diferente tendrá un efecto definitivo, aunque a veces sutil, en la API de búsqueda de texto completo. Los campos cubiertos por un campo de consulta de texto completo se examinan en el contexto de la lengua elegida, por lo que los lexemas producidos por las consultas de análisis y búsqueda varían de un idioma a otro. Por ejemplo: al utilizar el diccionario turco compatible, "token" se convierte en "toke", mientras que el diccionario inglés lo convierte en "token".
+
+Diccionarios de idiomas admitidos:
+
+| Code   | Diccionario |
+| ------ | ----------- |
+| simple | General     |
+| da     | Danish      |
+| nl     | Dutch       |
+| en     | English     |
+| fi     | Finnish     |
+| fr     | French      |
+| de     | German      |
+| hu     | Hungarian   |
+| it     | Italian     |
+| no     | Norwegian   |
+| pt     | Portugués   |
+| ro     | Romanian    |
+| ru     | Russian     |
+| es     | Spanish     |
+| sv     | Swedish     |
+| tr     | Turkish     |
+
+### Algoritmos de Clasificación
+
+Algoritmos admitidos para ordenar los resultados:
+
+| Algorithm           | Description                                                                                        |
+| ------------------- | -------------------------------------------------------------------------------------------------- |
+| rank                | Usa la calidad de coincidencia (0-1) de la consulta de texto completo para ordenar los resultados. |
+| rango de proximidad | Similar to rank but also includes the proximity of the matches.                                    |

From 2589af410de23873e36fc6f4eec5c8a29b1e87a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:43 -0500
Subject: [PATCH 1795/3820] New translations ql-schema.mdx (Arabic)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/ar/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ar/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..922905fc45b2
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## نظره عامة
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### مثال جيد
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### مثال سيئ
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### الحقول الاختيارية والمطلوبة
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+'Null value resolved for non-null field 'name
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### أنواع المقاييس المضمنة
+
+#### المقاييس المدعومة من GraphQL
+
+The following scalars are supported in the GraphQL API:
+
+| النوع        | الوصف                                                                                                                                                                                                            |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | مصفوفة Byte ، ممثلة كسلسلة سداسية عشرية. يشيع استخدامها في Ethereum hashes وعناوينه.                                                                                                                             |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+You can also create enums within a schema. Enums have the following syntax:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### علاقات الكيانات
+
+An entity may have a relationship to one or more other entities in your schema. These relationships may be traversed in your queries. Relationships in The Graph are unidirectional. It is possible to simulate bidirectional relationships by defining a unidirectional relationship on either "end" of the relationship.
+
+Relationships are defined on entities just like any other field except that the type specified is that of another entity.
+
+#### العلاقات واحد-لواحد
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### علاقات واحد-لمتعدد
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### البحث العكسي
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived. Storing the relationship this way, rather than storing an array of entities on the 'many' side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.
+
+#### Example
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### علاقات متعدد_لمتعدد
+
+For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.
+
+#### Example
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+This approach requires that queries descend into one additional level to retrieve, for example, the organizations for users:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+This more elaborate way of storing many-to-many relationships will result in less data stored for the subgraph, and therefore to a subgraph that is often dramatically faster to index and to query.
+
+### إضافة تعليقات إلى المخطط (schema)
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## تعريف حقول البحث عن النص الكامل
+
+Fulltext search queries filter and rank entities based on a text search input. Fulltext queries are able to return matches for similar words by processing the query text input into stems before comparing them to the indexed text data.
+
+A fulltext query definition includes the query name, the language dictionary used to process the text fields, the ranking algorithm used to order the results, and the fields included in the search. Each fulltext query may span multiple fields, but all included fields must be from a single entity type.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## اللغات المدعومة
+
+Choosing a different language will have a definitive, though sometimes subtle, effect on the fulltext search API. Fields covered by a fulltext query field are examined in the context of the chosen language, so the lexemes produced by analysis and search queries vary from language to language. For example: when using the supported Turkish dictionary "token" is stemmed to "toke" while, of course, the English dictionary will stem it to "token".
+
+Supported language dictionaries:
+
+| Code   | القاموس    |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Portuguese |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### خوارزميات التصنيف
+
+Supported algorithms for ordering results:
+
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | استخدم جودة مطابقة استعلام النص-الكامل (0-1) لترتيب النتائج.            |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From 97d1cd69d1d01e1827c9f8f49672fcc147d624d9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:44 -0500
Subject: [PATCH 1796/3820] New translations ql-schema.mdx (Czech)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/cs/subgraphs/developing/creating/ql-schema.mdx b/website/pages/cs/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..e3cf65716868
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Přehled
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Dobrý příklad
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Špatný příklad
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Nepovinná a povinná pole
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Vyřešení nulové hodnoty pro pole 'name', které není nulové
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Vestavěné typy skalárů
+
+#### Podporované skaláry GraphQL
+
+The following scalars are supported in the GraphQL API:
+
+| Typ          | Popis                                                                                                                                                                                                            |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Pole bajtů reprezentované jako hexadecimální řetězec. Běžně se používá pro hashe a adresy Ethereum.                                                                                                              |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+Výčty můžete vytvářet také v rámci schématu. Syntaxe enumů je následující:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Vztahy entit
+
+Entita může mít vztah k jedné nebo více jiným entitám ve vašem schématu. Tyto vztahy lze procházet v dotazech. Vztahy v Graf jsou jednosměrné. Obousměrné vztahy je možné simulovat definováním jednosměrného vztahu na obou "koncích" vztahu.
+
+Vztahy se definují u entit stejně jako u jiných polí s tím rozdílem, že zadaný typ je typ jiné entity.
+
+#### Vztahy jeden na jednoho
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### Vztahy jeden k mnoha
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Zpětné vyhledávání
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+U vztahů typu "jeden k mnoha" by měl být vztah vždy uložen na straně "jeden" a strana "mnoho" by měla být vždy odvozena. Uložení vztahu tímto způsobem namísto uložení pole entit na straně "mnoho" povede k výrazně lepšímu výkonu jak při indexování, tak při dotazování na podgraf. Obecně platí, že ukládání polí entit je třeba se vyhnout, pokud je to praktické.
+
+#### Příklad
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Vztahy mnoho k mnoha
+
+Pro vztahy mnoho-více, jako jsou uživatelé, z nichž každý může patřit do libovolného počtu organizací, je nejjednodušší, ale obecně ne nejvýkonnější, modelovat vztah jako pole v každé z obou zúčastněných entit. Pokud je vztah symetrický, je třeba uložit pouze jednu stranu vztahu a druhou stranu lze odvodit.
+
+#### Příklad
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+Tento přístup vyžaduje, aby dotazy sestupovaly do další úrovně, aby bylo možné získat například organizace pro uživatele:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+Tento propracovanější způsob ukládání vztahů mnoho-více vede k menšímu množství dat uložených pro podgraf, a tedy k podgrafu, který je často výrazně rychlejší při indexování a dotazování.
+
+### Přidání komentářů do schématu
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Definování polí fulltextového vyhledávání
+
+Fulltextové vyhledávací dotazy filtrují a řadí entity na základě textového vyhledávacího vstupu. Fulltextové dotazy jsou schopny vracet shody podobných slov tím, že zpracovávají vstupní text dotazu do kmenů před jejich porovnáním s indexovanými textovými daty.
+
+Definice fulltextového dotazu obsahuje název dotazu, jazykový slovník použitý ke zpracování textových polí, algoritmus řazení použitý k seřazení výsledků a pole zahrnutá do vyhledávání. Každý fulltextový dotaz může zahrnovat více polí, ale všechna zahrnutá pole musí být z jednoho typu entity.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Podporované jazyky
+
+Výběr jiného jazyka bude mít na rozhraní API fulltextového vyhledávání rozhodující, i když někdy nenápadný vliv. Pole zahrnutá do pole fulltextového dotazu jsou zkoumána v kontextu zvoleného jazyka, takže lexémy vytvořené analýzou a vyhledávacími dotazy se v jednotlivých jazycích liší. Například: při použití podporovaného tureckého slovníku je "token" odvozeno od "toke", zatímco anglický slovník jej samozřejmě odvozuje od "token".
+
+Podporované jazykové slovníky:
+
+| Code       | Slovník    |
+| ---------- | ---------- |
+| jednoduchý | General    |
+| da         | Danish     |
+| nl         | Dutch      |
+| en         | English    |
+| fi         | Finnish    |
+| fr         | French     |
+| de         | German     |
+| hu         | Hungarian  |
+| it         | Italian    |
+| no         | Norwegian  |
+| pt         | Portuguese |
+| ro         | Romanian   |
+| ru         | Russian    |
+| es         | Spanish    |
+| sv         | Swedish    |
+| tr         | Turkish    |
+
+### Algoritmy řazení
+
+Podporované algoritmy pro řazení výsledků:
+
+| Algorithm     | Description                                                              |
+| ------------- | ------------------------------------------------------------------------ |
+| rank          | Pro seřazení výsledků použijte kvalitu shody (0-1) fulltextového dotazu. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.          |

From c6275373eca493ee646996a9e8919481ba205c87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:45 -0500
Subject: [PATCH 1797/3820] New translations ql-schema.mdx (German)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/de/subgraphs/developing/creating/ql-schema.mdx b/website/pages/de/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..c4543695571c
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Overview
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Good Example
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Bad Example
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Optional and Required Fields
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Built-In Scalar Types
+
+#### GraphQL Supported Scalars
+
+The following scalars are supported in the GraphQL API:
+
+| Type         | Beschreibung                                                                                                                                                                                                     |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+You can also create enums within a schema. Enums have the following syntax:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Entity Relationships
+
+An entity may have a relationship to one or more other entities in your schema. These relationships may be traversed in your queries. Relationships in The Graph are unidirectional. It is possible to simulate bidirectional relationships by defining a unidirectional relationship on either "end" of the relationship.
+
+Relationships are defined on entities just like any other field except that the type specified is that of another entity.
+
+#### One-To-One Relationships
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### One-To-Many Relationships
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Reverse Lookups
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived. Storing the relationship this way, rather than storing an array of entities on the 'many' side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.
+
+#### Beispiel
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Many-To-Many Relationships
+
+For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.
+
+#### Beispiel
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+This approach requires that queries descend into one additional level to retrieve, for example, the organizations for users:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+This more elaborate way of storing many-to-many relationships will result in less data stored for the subgraph, and therefore to a subgraph that is often dramatically faster to index and to query.
+
+### Adding comments to the schema
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Defining Fulltext Search Fields
+
+Fulltext search queries filter and rank entities based on a text search input. Fulltext queries are able to return matches for similar words by processing the query text input into stems before comparing them to the indexed text data.
+
+A fulltext query definition includes the query name, the language dictionary used to process the text fields, the ranking algorithm used to order the results, and the fields included in the search. Each fulltext query may span multiple fields, but all included fields must be from a single entity type.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Languages supported
+
+Choosing a different language will have a definitive, though sometimes subtle, effect on the fulltext search API. Fields covered by a fulltext query field are examined in the context of the chosen language, so the lexemes produced by analysis and search queries vary from language to language. For example: when using the supported Turkish dictionary "token" is stemmed to "toke" while, of course, the English dictionary will stem it to "token".
+
+Supported language dictionaries:
+
+| Code   | Dictionary |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Portuguese |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### Ranking Algorithms
+
+Supported algorithms for ordering results:
+
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | Use the match quality (0-1) of the fulltext query to order the results. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From c4853c885c6d90891dce4ea7393a2b59a9273227 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:46 -0500
Subject: [PATCH 1798/3820] New translations ql-schema.mdx (Italian)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/it/subgraphs/developing/creating/ql-schema.mdx b/website/pages/it/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..0801ce841eaa
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Panoramica
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Buon esempio
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Cattivo esempio
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Campi opzionali e obbligatori
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Tipi scalari integrati
+
+#### Scalari supportati da GraphQL
+
+The following scalars are supported in the GraphQL API:
+
+| Tipo         | Descrizione                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, rappresentato come una stringa esadecimale. Comunemente utilizzato per gli hash e gli indirizzi di Ethereum.                                                                                         |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enum
+
+È possibile creare enum anche all'interno di uno schema. Gli enum hanno la seguente sintassi:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Relazioni tra entità
+
+Un'entità può avere una relazione con una o più altre entità dello schema. Queste relazioni possono essere attraversate nelle query. Le relazioni in The Graph sono unidirezionali. È possibile simulare relazioni bidirezionali definendo una relazione unidirezionale su entrambe le "estremità" della relazione.
+
+Le relazioni sono definite sulle entità come qualsiasi altro campo, tranne per il fatto che il tipo specificato è quello di un'altra entità.
+
+#### Rapporti uno-a-uno
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### Relazioni uno-a-molti
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Ricerche inverse
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+Per le relazioni uno-a-molti, la relazione deve sempre essere memorizzata sul lato "uno" e il lato "molti" deve sempre essere derivato. Memorizzare la relazione in questo modo, piuttosto che memorizzare un array di entità sul lato "molti", migliorerà notevolmente le prestazioni sia per l'indicizzazione che per l'interrogazione del subgraph. In generale, la memorizzazione di array di entità dovrebbe essere evitata per quanto possibile.
+
+#### Esempio
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Relazioni molti-a-molti
+
+Per le relazioni molti-a-molti, come ad esempio gli utenti che possono appartenere a un numero qualsiasi di organizzazioni, il modo più semplice, ma generalmente non il più performante, di modellare la relazione è come un array in ciascuna delle due entità coinvolte. Se la relazione è simmetrica, è necessario memorizzare solo un lato della relazione e l'altro lato può essere derivato.
+
+#### Esempio
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+Questo approccio richiede che le query scendano di un ulteriore livello per recuperare, ad esempio, le organizzazioni degli utenti:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+Questo modo più elaborato di memorizzare le relazioni molti-a-molti si traduce in una minore quantità di dati memorizzati per il subgraph e quindi in un subgraph che spesso è molto più veloce da indicizzare e da effettuare query.
+
+### Aggiungere commenti allo schema
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Definizione dei campi di ricerca fulltext
+
+Le query di ricerca fulltext filtrano e classificano le entità in base a un input di ricerca testuale. Le query full-text sono in grado di restituire corrispondenze per parole simili, elaborando il testo della query in gambi prima di confrontarli con i dati di testo indicizzati.
+
+La definizione di una query fulltext include il nome della query, il dizionario linguistico utilizzato per elaborare i campi di testo, l'algoritmo di classificazione utilizzato per ordinare i risultati e i campi inclusi nella ricerca. Ogni query fulltext può comprendere più campi, ma tutti i campi inclusi devono appartenere a un unico tipo di entità.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Lingue supportate
+
+La scelta di una lingua diversa avrà un effetto definitivo, anche se talvolta sottile, sull'API di ricerca fulltext. I campi coperti da una query fulltext vengono esaminati nel contesto della lingua scelta, quindi i lessemi prodotti dall'analisi e dalle query di ricerca variano da lingua a lingua. Ad esempio, quando si utilizza il dizionario turco supportato, "token" viene ridotto a "toke", mentre il dizionario inglese lo riduce a "token".
+
+Dizionari linguistici supportati:
+
+| Code     | Dizionario |
+| -------- | ---------- |
+| semplice | General    |
+| da       | Danish     |
+| nl       | Dutch      |
+| en       | English    |
+| fi       | Finnish    |
+| fr       | French     |
+| de       | German     |
+| hu       | Hungarian  |
+| it       | Italian    |
+| no       | Norwegian  |
+| pt       | Portoghese |
+| ro       | Romanian   |
+| ru       | Russian    |
+| es       | Spanish    |
+| sv       | Swedish    |
+| tr       | Turkish    |
+
+### Algoritmi di classificazione
+
+Algoritmi supportati per ordinare i risultati:
+
+| Algorithm     | Description                                                                                   |
+| ------------- | --------------------------------------------------------------------------------------------- |
+| rank          | Utilizza la qualità della corrispondenza (0-1) della query fulltext per ordinare i risultati. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.                               |

From 0fcb3fea0b4ead6071b7f38892a8a0d361a9fc8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:48 -0500
Subject: [PATCH 1799/3820] New translations ql-schema.mdx (Japanese)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/ja/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ja/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..46cd45e7dc01
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## 概要
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### 良い例
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### 悪い例
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### 任意フィールドと必須フィールド
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null 以外のフィールド 'name' の null 値が解決されました
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### 組み込みの Scalar タイプ
+
+#### GraphQL がサポートする Scalar
+
+The following scalars are supported in the GraphQL API:
+
+| タイプ          | 説明書き                                                                                                                                                                                                             |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte 配列で、16 進数の文字列で表されます。Ethereum のハッシュやアドレスによく使われます。                                                                                                                                                            |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+スキーマ内に enums を作成することもできます。enums は次のような構文になっています:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### エンティティのリレーションシップ
+
+エンティティは、スキーマ内の 1 つ以上の他のエンティティとリレーションシップを持つことができます。これらの関係は、クエリの中で走査されることがあります。The Graph のリレーションシップは単方向です。リレーションシップのどちらかの "端 "に単方向のリレーションシップを定義することで、双方向のリレーションシップをシミュレートすることができます。
+
+リレーションシップは、指定されたタイプが他のエンティティのものであることを除けば、他のフィールドと同様にエンティティに定義されます。
+
+#### 1 対 1 のリレーションシップ
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### 1 対多のリレーションシップ
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### 逆引き(Reverse lookups)
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+1 対多の関係では、関係は常に「1」側に格納され、「多」側は常に派生されるべきです。「多」側にエンティティの配列を格納するのではなく、このように関係を格納することで、サブグラフのインデックス作成と問い合わせの両方で劇的にパフォーマンスが向上します。一般的に、エンティティの配列を保存することは、現実的に可能な限り避けるべきです。
+
+#### 例
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### 多対多のリレーションシップ
+
+ユーザーがそれぞれ任意の数の組織に所属しているような多対多の関係の場合、関係をモデル化する最も簡単な方法は、関係する 2 つのエンティティのそれぞれに配列として格納することですが、一般的には最もパフォーマンスの高い方法ではありません。対称的な関係であれば、関係の片側のみを保存する必要があり、もう片側は派生させることができます。
+
+#### 例
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+このアプローチでは、例えばユーザーの組織を取得するために、クエリをさらに 1 つのレベルに下げる必要があります:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+このように多対多の関係をより精巧に保存する方法では、サブグラフに保存されるデータが少なくなるため、サブグラフのインデックス作成や問い合わせが劇的に速くなります。
+
+### スキーマへのコメントの追加
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## フルテキスト検索フィールド（Full Text Search）の定義
+
+フルテキスト検索クエリは、テキスト検索入力に基づいてエンティティをフィルタリングし、ランク付けします。フルテキストクエリは、インデックス化されたテキストデータと比較する前に、クエリテキストの入力をステム処理することで、類似した単語のマッチを返すことができます。
+
+フルテキストクエリの定義には、クエリ名、テキストフィールドの処理に使用される言語辞書、結果の順序付けに使用されるランキングアルゴリズム、および検索に含まれるフィールドが含まれます。各フルテキスト・クエリは複数のフィールドにまたがることができますが、含まれるフィールドはすべて単一のエンティティ・タイプのものでなければなりません。
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## 対応言語
+
+異なる言語を選択すると、フルテキスト検索 API に決定的な影響を与えますが、場合によっては微妙な影響もあります。フルテキストクエリフィールドでカバーされるフィールドは、選択された言語のコンテキストで検査されるため、分析や検索クエリで生成される語彙は言語ごとに異なります。たとえば、サポートされているトルコ語辞書を使用した場合、"token "は "toke "にステム処理されますが、もちろん英語辞書では "token "にステム処理されます。
+
+サポートされている言語の辞書:
+
+| Code   | 辞書         |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | ポルトガル語     |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### ランキングアルゴリズム
+
+サポートされている結果の順序付けのアルゴリズム:
+
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | フルテキストクエリのマッチ品質 (0-1) を使用して結果を並べ替えます。                                   |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From 7c06616775204713d43c2b43de8f864a039574fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:49 -0500
Subject: [PATCH 1800/3820] New translations ql-schema.mdx (Korean)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/ko/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ko/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..8e5789d66650
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Overview
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Good Example
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Bad Example
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Optional and Required Fields
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Built-In Scalar Types
+
+#### GraphQL Supported Scalars
+
+The following scalars are supported in the GraphQL API:
+
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+You can also create enums within a schema. Enums have the following syntax:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Entity Relationships
+
+An entity may have a relationship to one or more other entities in your schema. These relationships may be traversed in your queries. Relationships in The Graph are unidirectional. It is possible to simulate bidirectional relationships by defining a unidirectional relationship on either "end" of the relationship.
+
+Relationships are defined on entities just like any other field except that the type specified is that of another entity.
+
+#### One-To-One Relationships
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### One-To-Many Relationships
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Reverse Lookups
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived. Storing the relationship this way, rather than storing an array of entities on the 'many' side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.
+
+#### Example
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Many-To-Many Relationships
+
+For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.
+
+#### Example
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+This approach requires that queries descend into one additional level to retrieve, for example, the organizations for users:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+This more elaborate way of storing many-to-many relationships will result in less data stored for the subgraph, and therefore to a subgraph that is often dramatically faster to index and to query.
+
+### Adding comments to the schema
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Defining Fulltext Search Fields
+
+Fulltext search queries filter and rank entities based on a text search input. Fulltext queries are able to return matches for similar words by processing the query text input into stems before comparing them to the indexed text data.
+
+A fulltext query definition includes the query name, the language dictionary used to process the text fields, the ranking algorithm used to order the results, and the fields included in the search. Each fulltext query may span multiple fields, but all included fields must be from a single entity type.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Languages supported
+
+Choosing a different language will have a definitive, though sometimes subtle, effect on the fulltext search API. Fields covered by a fulltext query field are examined in the context of the chosen language, so the lexemes produced by analysis and search queries vary from language to language. For example: when using the supported Turkish dictionary "token" is stemmed to "toke" while, of course, the English dictionary will stem it to "token".
+
+Supported language dictionaries:
+
+| Code   | Dictionary |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Portuguese |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### Ranking Algorithms
+
+Supported algorithms for ordering results:
+
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | Use the match quality (0-1) of the fulltext query to order the results. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From 0566123d60f072a99b14983d096fcaaed1deec91 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:50 -0500
Subject: [PATCH 1801/3820] New translations ql-schema.mdx (Dutch)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/nl/subgraphs/developing/creating/ql-schema.mdx b/website/pages/nl/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..8e5789d66650
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Overview
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Good Example
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Bad Example
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Optional and Required Fields
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Built-In Scalar Types
+
+#### GraphQL Supported Scalars
+
+The following scalars are supported in the GraphQL API:
+
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+You can also create enums within a schema. Enums have the following syntax:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Entity Relationships
+
+An entity may have a relationship to one or more other entities in your schema. These relationships may be traversed in your queries. Relationships in The Graph are unidirectional. It is possible to simulate bidirectional relationships by defining a unidirectional relationship on either "end" of the relationship.
+
+Relationships are defined on entities just like any other field except that the type specified is that of another entity.
+
+#### One-To-One Relationships
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### One-To-Many Relationships
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Reverse Lookups
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived. Storing the relationship this way, rather than storing an array of entities on the 'many' side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.
+
+#### Example
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Many-To-Many Relationships
+
+For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.
+
+#### Example
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+This approach requires that queries descend into one additional level to retrieve, for example, the organizations for users:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+This more elaborate way of storing many-to-many relationships will result in less data stored for the subgraph, and therefore to a subgraph that is often dramatically faster to index and to query.
+
+### Adding comments to the schema
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Defining Fulltext Search Fields
+
+Fulltext search queries filter and rank entities based on a text search input. Fulltext queries are able to return matches for similar words by processing the query text input into stems before comparing them to the indexed text data.
+
+A fulltext query definition includes the query name, the language dictionary used to process the text fields, the ranking algorithm used to order the results, and the fields included in the search. Each fulltext query may span multiple fields, but all included fields must be from a single entity type.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Languages supported
+
+Choosing a different language will have a definitive, though sometimes subtle, effect on the fulltext search API. Fields covered by a fulltext query field are examined in the context of the chosen language, so the lexemes produced by analysis and search queries vary from language to language. For example: when using the supported Turkish dictionary "token" is stemmed to "toke" while, of course, the English dictionary will stem it to "token".
+
+Supported language dictionaries:
+
+| Code   | Dictionary |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Portuguese |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### Ranking Algorithms
+
+Supported algorithms for ordering results:
+
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | Use the match quality (0-1) of the fulltext query to order the results. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From 87cd863e8c4d860f99e868435bec2229738b814c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:51 -0500
Subject: [PATCH 1802/3820] New translations ql-schema.mdx (Polish)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/pl/subgraphs/developing/creating/ql-schema.mdx b/website/pages/pl/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..8e5789d66650
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Overview
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Good Example
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Bad Example
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Optional and Required Fields
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Built-In Scalar Types
+
+#### GraphQL Supported Scalars
+
+The following scalars are supported in the GraphQL API:
+
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+You can also create enums within a schema. Enums have the following syntax:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Entity Relationships
+
+An entity may have a relationship to one or more other entities in your schema. These relationships may be traversed in your queries. Relationships in The Graph are unidirectional. It is possible to simulate bidirectional relationships by defining a unidirectional relationship on either "end" of the relationship.
+
+Relationships are defined on entities just like any other field except that the type specified is that of another entity.
+
+#### One-To-One Relationships
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### One-To-Many Relationships
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Reverse Lookups
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived. Storing the relationship this way, rather than storing an array of entities on the 'many' side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.
+
+#### Example
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Many-To-Many Relationships
+
+For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.
+
+#### Example
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+This approach requires that queries descend into one additional level to retrieve, for example, the organizations for users:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+This more elaborate way of storing many-to-many relationships will result in less data stored for the subgraph, and therefore to a subgraph that is often dramatically faster to index and to query.
+
+### Adding comments to the schema
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Defining Fulltext Search Fields
+
+Fulltext search queries filter and rank entities based on a text search input. Fulltext queries are able to return matches for similar words by processing the query text input into stems before comparing them to the indexed text data.
+
+A fulltext query definition includes the query name, the language dictionary used to process the text fields, the ranking algorithm used to order the results, and the fields included in the search. Each fulltext query may span multiple fields, but all included fields must be from a single entity type.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Languages supported
+
+Choosing a different language will have a definitive, though sometimes subtle, effect on the fulltext search API. Fields covered by a fulltext query field are examined in the context of the chosen language, so the lexemes produced by analysis and search queries vary from language to language. For example: when using the supported Turkish dictionary "token" is stemmed to "toke" while, of course, the English dictionary will stem it to "token".
+
+Supported language dictionaries:
+
+| Code   | Dictionary |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Portuguese |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### Ranking Algorithms
+
+Supported algorithms for ordering results:
+
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | Use the match quality (0-1) of the fulltext query to order the results. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From b9a64ddacb8ba70c25b1113d0683d951a98f299c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:52 -0500
Subject: [PATCH 1803/3820] New translations ql-schema.mdx (Portuguese)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/pt/subgraphs/developing/creating/ql-schema.mdx b/website/pages/pt/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..68f010a59b9e
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Visão geral
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Bom Exemplo
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Mau Exemplo
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Campos Opcionais e Obrigatórios
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Tipos Embutidos de Escalar
+
+#### Escalares Apoiados pelo GraphQL
+
+The following scalars are supported in the GraphQL API:
+
+| Tipo         | Descrição                                                                                                                                                                                                        |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Arranjo de bytes, representado como string hexadecimal. Usado frequentemente por hashes e endereços no Ethereum.                                                                                                 |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+Também pode criar enums dentro de um schema. Enums têm a seguinte sintaxe:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Relacionamentos de Entidades
+
+Uma entidade pode ter relacionamentos com uma ou mais entidades no seu schema; estes podem ser tratados nas suas consultas. Os relacionamentos no The Graph são unidirecionais, e é possível simular relacionamentos bidirecionais ao definir um relacionamento unidirecional em cada "lado" do relacionamento projetado.
+
+Relacionamentos são definidos em entidades como qualquer outro campo, sendo que o tipo especificado é o de outra entidade.
+
+#### Relacionamentos Um-com-Um
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### Relacionamentos Um-com-Vários
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Buscas Reversas
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+Para relacionamentos um-com-vários, o relacionamento sempre deve ser armazenado no lado 'um', e o lado 'vários' deve sempre ser derivado. Armazenar o relacionamento desta maneira, em vez de armazenar um arranjo de entidades no lado 'vários', melhorará dramaticamente o desempenho para o indexing e os queries no subgraph. Em geral, evite armazenar arranjos de entidades enquanto for prático.
+
+#### Exemplo
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Relacionamentos Vários-com-Vários
+
+Para relacionamentos vários-com-vários, como um conjunto de utilizadores em que cada um pertence a qualquer número de organizações, o relacionamento é mais simplesmente — mas não mais eficientemente — modelado como um arranjo em cada uma das duas entidades envolvidas. Se o relacionamento for simétrico, apenas um lado do relacionamento precisa ser armazenado, e o outro lado pode ser derivado.
+
+#### Exemplo
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+Esta abordagem requer que os queries desçam a um nível adicional para retirar, por exemplo, as organizações para utilizadores:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # isto é uma entidade UserOrganization
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+Esta maneira mais elaborada de armazenar relacionamentos vários-com-vários armazenará menos dados para o subgraph, portanto, o subgraph ficará muito mais rápido de indexar e consultar.
+
+### Como adicionar comentários ao schema
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # identificador único e chave primária da entidade
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Como Definir Campos de Busca Fulltext
+
+Buscas fulltext filtram e ordenam entidades baseadas num texto inserido. Queries fulltext podem retornar resultados para palavras semelhantes ao processar o texto inserido antes de compará-los aos dados do texto indexado.
+
+Uma definição de query fulltext inclui: o nome do query, o dicionário do idioma usado para processar os campos de texto, o algoritmo de ordem usado para ordenar os resultados, e os campos incluídos na busca. Todo query fulltext pode ter vários campos, mas todos os campos incluídos devem ser de um único tipo de entidade.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Idiomas apoiados
+
+Escolher um idioma diferente terá um efeito definitivo, porém às vezes sutil, na API da busca fulltext. Campos cobertos por um campo de query fulltext serão examinados no contexto do idioma escolhido, para que os lexemas produzidos pela análise e pelos queries de busca variem de idioma para idioma. Por exemplo: ao usar o dicionário turco, "token" é abreviado para "toke" enquanto, claro, o dicionário em inglês o categorizará como "token".
+
+Dicionários apoiados:
+
+| Code   | Dicionário |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Português  |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### Algoritmos de Ordem
+
+Algoritmos apoiados para a organização de resultados:
+
+| Algorithm     | Description                                                                       |
+| ------------- | --------------------------------------------------------------------------------- |
+| rank          | Organiza os resultados pela qualidade da correspondência (0-1) da busca fulltext. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.                   |

From f00a1a31e4cfeed283e75db99ea996fd32f23f8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:54 -0500
Subject: [PATCH 1804/3820] New translations ql-schema.mdx (Russian)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/ru/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ru/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..d5f5ceaf86c8
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Обзор
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Определение Объектов
+
+Прежде чем определять объекты, важно сделать шаг назад и задуматься над тем, как структурированы и связаны Ваши данные.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- Может быть полезно представить объекты как «объекты, содержащие данные», а не как события или функции.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- По умолчанию объекты изменяемы, то есть мэппинги могут загружать существующие объекты, изменять и сохранять их новую версию.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - Если изменения происходят в том же блоке, в котором был создан объект, то мэппинги могут вносить изменения в неизменяемые объекты. Неизменяемые объекты гораздо быстрее записываются и запрашиваются, поэтому их следует использовать, когда это возможно.
+
+#### Удачный пример
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Неудачный пример
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Дополнительные и обязательные поля
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Встроенные скалярные типы
+
+#### Поддерживаемые GraphQL скаляры
+
+В API GraphQL поддерживаются следующие скаляры:
+
+| Тип          | Описание                                                                                                                                                                                                         |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Массив байтов, представленный в виде шестнадцатеричной строки. Обычно используется для хэшей и адресов Ethereum.                                                                                                 |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Перечисления
+
+Вы также можете создавать перечисления внутри схемы. Перечисления имеют следующий синтаксис:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Связи объектов
+
+Объект может иметь связь с одним или несколькими другими объектами в Вашей схеме. Эти связи могут быть использованы в Ваших запросах. Связи в The Graph являются однонаправленными. Можно смоделировать двунаправленные связи, определив однонаправленную связь на любом "конце" связи.
+
+Связи определяются для объектов точно так же, как и для любого другого поля, за исключением того, что в качестве типа указывается тип другого объекта.
+
+#### Связи "Один к одному"
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### Связи "Один ко многим"
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Обратные запросы
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+Для связей "один ко многим" связь всегда должна храниться на стороне "один", а сторона "многие" всегда должна быть производной. Такое сохранение связи, вместо хранения массива объектов на стороне "многие", приведет к значительному повышению производительности как при индексации, так и при запросах к субграфам. В общем, следует избегать хранения массивов объектов настолько, насколько это возможно.
+
+#### Пример
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Связи "Многие ко многим"
+
+Для связей "многие ко многим", таких, например, как пользователи, каждый из которых может принадлежать к любому числу организаций, наиболее простым, но, как правило, не самым производительным способом моделирования связей является создание массива в каждом из двух задействованных объектов. Если связь симметрична, то необходимо сохранить только одну сторону связи, а другая сторона может быть выведена.
+
+#### Пример
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+Этот подход требует, чтобы запросы опускались на один дополнительный уровень для получения, например, сведений об организациях для пользователей:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+Такой более сложный способ хранения связей "многие ко многим" приведет к уменьшению объема хранимых данных для субграфа и, следовательно, к тому, что субграф будет значительно быстрее индексироваться и запрашиваться.
+
+### Добавление комментариев к схеме
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  #уникальный идентификатор и первичный ключ объекта
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Определение полей полнотекстового поиска
+
+Полнотекстовые поисковые запросы фильтруют и ранжируют объекты на основе введенных данных текстового запроса. Полнотекстовые запросы способны возвращать совпадения по схожим словам путем обработки текста запроса в виде строк перед сравнением с индексированными текстовыми данными.
+
+Определение полнотекстового запроса включает в себя название запроса, словарь языка, используемый для обработки текстовых полей, алгоритм ранжирования, используемый для упорядочивания результатов, и поля, включенные в поиск. Каждый полнотекстовый запрос может охватывать несколько полей, но все включенные поля должны относиться к одному типу объекта.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Поддерживаемые языки
+
+Выбор другого языка окажет решающее, хотя иногда и неуловимое влияние на API полнотекстового поиска. Поля, охватываемые полем полнотекстового запроса, рассматриваются в контексте выбранного языка, поэтому лексемы, полученные в результате анализа и поисковых запросов, варьируются от языка к языку. Например: при использовании поддерживаемого турецкого словаря "token" переводится как "toke", в то время как, конечно, словарь английского языка переводит его в "token".
+
+Поддерживаемые языковые словари:
+
+| Code    | Словарь       |
+| ------- | ------------- |
+| простой | General       |
+| da      | Danish        |
+| nl      | Dutch         |
+| en      | English       |
+| fi      | Finnish       |
+| fr      | French        |
+| de      | German        |
+| hu      | Hungarian     |
+| it      | Italian       |
+| no      | Norwegian     |
+| pt      | Португальский |
+| ro      | Romanian      |
+| ru      | Russian       |
+| es      | Spanish       |
+| sv      | Swedish       |
+| tr      | Turkish       |
+
+### Алгоритмы ранжирования
+
+Поддерживаемые алгоритмы для упорядочивания результатов:
+
+| Algorithm     | Description                                                                                    |
+| ------------- | ---------------------------------------------------------------------------------------------- |
+| rank          | Используйте качество соответствия (0-1) полнотекстового запроса, чтобы упорядочить результаты. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.                                |

From 85f7857b2c9ecc6fc17dbae2aaf401e8a34e9c74 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:55 -0500
Subject: [PATCH 1805/3820] New translations ql-schema.mdx (Swedish)

---
 .../developing/creating/ql-schema.mdx         | 317 ++++++++++++++++++
 1 file changed, 317 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/sv/subgraphs/developing/creating/ql-schema.mdx b/website/pages/sv/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..9d615c96a165
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,317 @@
+---
+title: The Graph QL Schema
+---
+
+## Översikt
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Bra exempel
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Dåligt exempel
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Valfria och obligatoriska fält
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Inbyggda Skalartyper
+
+#### GraphQL-Stödda Skalartyper
+
+The following scalars are supported in the GraphQL API:
+
+| Typ          | Beskrivning                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Bytematris, representerad som en hexadecimal sträng. Vanligt används för Ethereum-hashar och adresser.                                                                                                           |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+Du kan också skapa enums inom ett schema. Enums har följande syntax:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Entitetsrelationer
+
+En entitet kan ha en relation till en eller flera andra entiteter i ditt schema. Dessa relationer kan traverseras i dina frågor. Relationer i The Graph är enriktade. Det är möjligt att simulera dubbelriktade relationer genom att definiera en enriktad relation på antingen den ena "änden" av relationen.
+
+Relationer definieras på entiteter precis som vilket annat fält som helst, förutom att den specificerade typen är en annan entitet.
+
+#### En-till-en-relationer
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### En-till-många-relationer
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Omvända sökningar
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+För en-till-många-relationer bör relationen alltid lagras på 'en'-sidan, och 'många'-sidan bör alltid härledas. Att lagra relationen på detta sätt, istället för att lagra en array av entiteter på 'många'-sidan, kommer att resultera i dramatiskt bättre prestanda både för indexering och för frågning av subgraphen. Generellt sett bör lagring av arrayer av entiteter undvikas så mycket som är praktiskt möjligt.
+
+#### Exempel
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Många-till-många-relationer
+
+För många-till-många-relationer, som till exempel användare som var och en kan tillhöra ett antal organisationer, är det mest raka, men generellt sett inte den mest prestanda-optimerade, sättet att modellera relationen som en array i vardera av de två entiteter som är involverade. Om relationen är symmetrisk behöver bara ena sidan av relationen lagras och den andra sidan kan härledas.
+
+#### Exempel
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+Detta tillvägagångssätt kräver att frågorna går ner till ytterligare en nivå för att hämta t. ex. organisationer för användare:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+Detta mer avancerade sätt att lagra många-till-många-relationer kommer att leda till att mindre data lagras för subgrafen, och därför till en subgraf som ofta är dramatiskt snabbare att indexera och att fråga.
+
+### Lägga till kommentarer i schemat
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Definiera fält för fulltextsökning
+
+Fulltextsökningar filtrerar och rangordnar entiteter baserat på en textinmatning för sökning. Fulltextförfrågningar kan returnera träffar för liknande ord genom att bearbeta söktexten till stammar innan de jämförs med den indexerade textdata.
+
+En fulltextförfrågningsdefinition inkluderar förfrågningsnamnet, ordboken som används för att bearbeta textfälten, rangordningsalgoritmen som används för att ordna resultaten och fälten som ingår i sökningen. Varje fulltextförfrågan kan omfatta flera fält, men alla inkluderade fält måste vara från en enda entitetstyp.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [
+      {
+        entity: "Band"
+        fields: [{ name: "name" }, { name: "description" }, { name: "bio" }]
+      }
+    ]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Stödda språk
+
+Att välja ett annat språk kommer att ha en definitiv, om än ibland subtil, effekt på fulltext-sök-API:en. Fält som omfattas av en fulltextförfrågningsfunktion granskas i kontexten av det valda språket, så lexem som produceras av analys och sökfrågor varierar från språk till språk. Till exempel: när det används det stödda turkiska ordboken "token" så avstamsas det till "toke", medan engelska ordboken självklart avstammar det till "token".
+
+Stödda språkordböcker:
+
+| Code   | Ordbok       |
+| ------ | ------------ |
+| enkel  | General      |
+| da     | Danish       |
+| nl     | Dutch        |
+| en     | English      |
+| fi     | Finnish      |
+| fr     | French       |
+| de     | German       |
+| hu     | Hungarian    |
+| it     | Italian      |
+| no     | Norwegian    |
+| pt     | Portugisiska |
+| ro     | Romanian     |
+| ru     | Russian      |
+| es     | Spanish      |
+| sv     | Swedish      |
+| tr     | Turkish      |
+
+### Rankningsalgoritmer
+
+Stödda algoritmer för att ordna resultat:
+
+| Algorithm     | Description                                                                        |
+| ------------- | ---------------------------------------------------------------------------------- |
+| rank          | Använd matchningskvaliteten (0-1) från fulltextförfrågan för att ordna resultaten. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.                    |

From 486fdff1124c731784a17b1d87d116ba93d6c6cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:56 -0500
Subject: [PATCH 1806/3820] New translations ql-schema.mdx (Turkish)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/tr/subgraphs/developing/creating/ql-schema.mdx b/website/pages/tr/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..ce1cc82dfc1c
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Genel Bakış
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Varlıkları Tanımlama
+
+Varlıkları tanımlamadan önce, verilerinizin nasıl yapılandırıldığını ve nasıl bağlantılı olduğunu düşünmek önemlidir.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- Varlıkları, olaylar veya fonksiyonlar yerine “veri içeren nesneler” olarak düşünmek faydalı olabilir.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- Varsayılan olarak, varlıklar değiştirilebilirdir; yani, eşlemeler halihazırda mevcut varlıkları yükleyebilir, onları modifiye edebilir ve o varlığın yeni bir sürümünü saklayabilir.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - Varlığın oluşturulduğu blok içinde değişiklikler gerçekleşirse, eşlemeler değişmez varlıkları değiştirebilir. Değişmez varlıklar çok daha hızlı yazılabilir ve sorgulanabilir olduğundan, mümkün olduğunca kullanılmaları önerilir.
+
+#### İyi Bir Örnek
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Kötü Bir Örnek
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Opsiyonel ve Zorunlu Alanlar
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Gömülü Skaler(Scalar) Türler
+
+#### GraphQL'in Desteklediği Skalerler
+
+GraphQL API'sinde desteklenen skalarlardan bazıları şunlardır:
+
+| Tür          | Tanım                                                                                                                                                                                                            |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte dizisi, onaltılık bir dizgi olarak temsil edilir. Ethereum hash değerleri ve adresleri için yaygın olarak kullanılır.                                                                                       |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Numaralandırmalar
+
+Ayrıca bir şema içinde numaralandırmalar da oluşturabilirsiniz. Numaralandırmalar aşağıdaki sözdizimine sahiptir:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Varlık İlişkileri
+
+Bir varlık, şemanızdaki bir veya daha fazla başka varlıkla ilişkili olabilir. Bu ilişkiler, sorgularınızda çaprazlanabilir. Graph'taki ilişkiler tek yönlüdür. İki yönlü ilişkileri simüle etmek, ilişkinin herhangi biri "son" üzerinde tek yönlü bir ilişki tanımlayarak mümkündür.
+
+İlişkiler, belirtilen türün başka bir varlığın türü olması dışında, diğer tüm alanlarda olduğu gibi varlıklar üzerinde tanımlanır.
+
+#### Bire Bir İlişkiler
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### Birden Çoğa İlişkiler
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Tersine Aramalar
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+Birden çoğa ilişkileriiçin, ilişki her zaman 'birden' tarafında depolanmalı ve her zaman 'çoğa' tarafında türetilmelidir. İlişkinin 'çoğa' tarafında bir dizi varlık depolamak yerine bu şekilde saklanması, subgraph indeksleme ve sorgulaması adına önemli ölçüde daha iyi performans sağlayacaktır. Genel olarak, varlık dizilerini depolamaktan mümkün olduğunca sakınılması gerekmektedir.
+
+#### Örnek
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Çoktan Çoğa İlişkiler
+
+Kullanıcıların her birinin birden çok kuruluşa mensup olabileceği gibi çoktan çoğa ilişkilerde, ilişkiyi modellemenin en basit fakat pek verimli olmayan yolu, ilişkide yer alan iki varlıkta da bir dizi olarak saklamaktır. İlişki simetrik ise, ilişkinin yalnızca bir tarafının saklanması gerekir ve diğer taraf türetilebilir.
+
+#### Örnek
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+Bu yaklaşım, örneğin kullanıcılar için kuruluşları almak için sorguların ek bir seviyeye inmesini gerektirir:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+Çoktan çoğa ilişkileri depolamanın daha ayrıntılı bu yolu, subgraph için depolanan veri miktarının azalmasına ve bu sonucunda genellikle indekslenmesi ve sorgulanması önemli ölçüde daha hızlı olan bir subgraph sağlayacaktır.
+
+### Şemaya notlar/yorumlar ekleme
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # # varlığın benzersiz tanımlayıcısı ve birincil anahtarı
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Tam Metinde Arama Alanlarını Tanımlama
+
+Tam metinde arama sorguları, metin arama girdisine dayanarak varlıkları filtreler ve sıralar. Tam metin sorguları, sorgu metni girişini indekslenmiş metin verileriyle karşılaştırmadan önce köklere işleyerek benzer kelimeler için eşleşmeler döndürebilir.
+
+Tam metin sorgusu tanımı, sorgu adı, metin alanlarını işlemek için kullanılan dil sözlüğü, sonuçları sıralamak için kullanılan sıralama algoritması ve aramaya dahil edilen alanları içerir. Her tam metin sorgusu birden fazla alana yayılabilir, ancak dahil edilen tüm alanlar tek bir varlık türünden olmalıdır.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Desteklenen diller
+
+Farklı bir dil seçmek, tam metin arama API'sı üzerinde bazen az olsa da kesin bir etkiye sahip olacaktır. Tam metin sorgu alanı tarafından kapsanan alanlar, seçilen dile bağlı olarak incelenir, bu nedenle analiz ve arama sorguları tarafından üretilen sözlükbirimleri dilden dile değişir. Örneğin: desteklenen Türkçe sözlük kullanıldığında "token" kelimesi "toke" olarak kök alınırken, elbette İngilizce sözlük "token" olarak kök alacaktır.
+
+Desteklenen dil sözlükleri:
+
+| Code   | Sözlük     |
+| ------ | ---------- |
+| yalın  | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Portekizce |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### Algoritmaları Sıralama
+
+Sonuçları sıralamak için desteklenen algoritmalar:
+
+| Algorithm     | Description                                                                         |
+| ------------- | ----------------------------------------------------------------------------------- |
+| rank          | Sonuçları sıralamak için tam metin sorgusunun eşleştirme kalitesini (0-1) kullanın. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.                     |

From 3d4ef34b379c66532f77eb3475a4c5cc169526e7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:57 -0500
Subject: [PATCH 1807/3820] New translations ql-schema.mdx (Ukrainian)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/uk/subgraphs/developing/creating/ql-schema.mdx b/website/pages/uk/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..8e5789d66650
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Overview
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Good Example
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Bad Example
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Optional and Required Fields
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Built-In Scalar Types
+
+#### GraphQL Supported Scalars
+
+The following scalars are supported in the GraphQL API:
+
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+You can also create enums within a schema. Enums have the following syntax:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Entity Relationships
+
+An entity may have a relationship to one or more other entities in your schema. These relationships may be traversed in your queries. Relationships in The Graph are unidirectional. It is possible to simulate bidirectional relationships by defining a unidirectional relationship on either "end" of the relationship.
+
+Relationships are defined on entities just like any other field except that the type specified is that of another entity.
+
+#### One-To-One Relationships
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### One-To-Many Relationships
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Reverse Lookups
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived. Storing the relationship this way, rather than storing an array of entities on the 'many' side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.
+
+#### Example
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Many-To-Many Relationships
+
+For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.
+
+#### Example
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+This approach requires that queries descend into one additional level to retrieve, for example, the organizations for users:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+This more elaborate way of storing many-to-many relationships will result in less data stored for the subgraph, and therefore to a subgraph that is often dramatically faster to index and to query.
+
+### Adding comments to the schema
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Defining Fulltext Search Fields
+
+Fulltext search queries filter and rank entities based on a text search input. Fulltext queries are able to return matches for similar words by processing the query text input into stems before comparing them to the indexed text data.
+
+A fulltext query definition includes the query name, the language dictionary used to process the text fields, the ranking algorithm used to order the results, and the fields included in the search. Each fulltext query may span multiple fields, but all included fields must be from a single entity type.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Languages supported
+
+Choosing a different language will have a definitive, though sometimes subtle, effect on the fulltext search API. Fields covered by a fulltext query field are examined in the context of the chosen language, so the lexemes produced by analysis and search queries vary from language to language. For example: when using the supported Turkish dictionary "token" is stemmed to "toke" while, of course, the English dictionary will stem it to "token".
+
+Supported language dictionaries:
+
+| Code   | Dictionary |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Portuguese |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### Ranking Algorithms
+
+Supported algorithms for ordering results:
+
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | Use the match quality (0-1) of the fulltext query to order the results. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From a28cee380ced0bfb9851d0d249a615b1af42620a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:58 -0500
Subject: [PATCH 1808/3820] New translations ql-schema.mdx (Chinese Simplified)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/zh/subgraphs/developing/creating/ql-schema.mdx b/website/pages/zh/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..0fa078ea48e8
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## 概述
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### 好代码的例子
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity {
+  id: Id!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### 坏榜样
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### 可选和必选字段
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### 内置标量类型
+
+#### GraphQL 支持的标量
+
+The following scalars are supported in the GraphQL API:
+
+| 类型           | 描述                                                                                                                                                                                                               |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | 字节数组，表示为十六进制字符串。 通常用于以太坊hash和地址。                                                                                                                                                                                 |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### 枚举类型
+
+您还可以在模式中创建枚举类型。 枚举类型具有以下语法：
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### 实体关系
+
+一个实体可能与模式中的一个或多个其他实体发生联系。 您可以在您的查询中遍历这些联系。 Graph 中的联系是单向的。 可以通过在关系的任一“端”上定义单向关系来模拟双向关系。
+
+关系是在实体上定义的，就像任何其他字段一样，除了指定的类型是另一个实体类型。
+
+#### 一对一关系
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### 一对多关系
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### 反向查找
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+对于一对多关系，关系应始终存储在“一”端，而“多”端应始终派生。 以这种方式存储关系，而不是在“多”端存储实体数组，将大大提高索引和查询子图的性能。 通常，应尽可能避免存储实体数组。
+
+#### 示例
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### 多对多关系
+
+对于多对多关系，例如每个可能属于任意数量的组织的用户，对关系建模的最直接，但通常不是最高效的方法，是在所涉及的两个实体中的每一个中定义数组。 如果关系是对称的，则只需要存储关系的一侧联系，就可以导出另一侧。
+
+#### 示例
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+这种方法要求查询下降一个额外的级别来检索，例如，用户的组织：
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+这种存储多对多关系的更精细的方式将导致为子图存储的数据更少，因此子图的索引和查询速度通常会大大加快。
+
+### 向模式添加注释
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## 定义全文搜索字段
+
+全文搜索查询根据文本搜索输入来过滤和排列实体。 通过在与索引文本数据进行比较之前，将查询文本输入处理到词干中，全文查询能够返回相似词的匹配项。
+
+全文查询定义包括查询名称、用于处理文本字段的语言词典、用于对结果进行排序的排序算法，以及搜索中包含的字段。 每个全文查询可能跨越多个字段，但所有包含的字段必须来自单个实体类型。
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## 支持的语言
+
+选择不同的语言将对全文搜索 API 产生明确的（尽管有时是微妙的）影响。 全文查询字段涵盖的字段将会在所选语言的内容中进行检查，因此分析和搜索查询产生的词位因语言而异。 例如：当使用支持的土耳其语词典时，“token”的词干为“toke”，而英语词典当然会认为其词干为“token”。
+
+支持的语言词典：
+
+| Code   | 词典         |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | 葡萄牙语       |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### 排序算法
+
+支持的排序结果算法：
+
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | 使用全文查询的匹配质量 (0-1) 对结果进行排序。                                              |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From d8793b919e602da8c808abc4f3d3c23597827f2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:16:59 -0500
Subject: [PATCH 1809/3820] New translations ql-schema.mdx (Urdu (Pakistan))

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/ur/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ur/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..96ac1cf2f2ce
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## جائزہ
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### اچھی مثال
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### بری مثال
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### اختیاری اور مطلوبہ فیلڈز
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+غیر صفر فیلڈ 'name' کے لیے خالی ویلیو حل ہو گئی
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### بلٹ ان اسکیلر اقسام
+
+#### GraphQL حمایت یافتہ اسکیلرز
+
+The following scalars are supported in the GraphQL API:
+
+| قسم          | تفصیل                                                                                                                                                                                                            |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array، ایک ہیکساڈیسیمل سٹرنگ کے طور پر پیش کیا جاتا ہے. عام طور پر Ethereum hashes اور ایڈریسیس کے لیے استعمال ہوتا ہے.                                                                                     |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+آپ اسکیما کے اندر enums بھی بنا سکتے ہیں. Enums میں درج ذیل نحو ہے:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### ہستی کے تعلقات
+
+آپ کے اسکیما میں ایک ہستی کا ایک یا زیادہ دیگر ہستیوں سے تعلق ہو سکتا ہے. یہ تعلق آپ کے کیوریز میں شامل ہو سکتے ہیں۔ گراف میں تعلق یک طرفہ ہوتے ہیں۔ تعلق کے کسی بھی "اختتام" پر یک طرفہ تعلق کی وضاحت کرکے دو طرفہ تعلق کی تقلید کرنا ممکن ہے.
+
+تعلقات کی تعریف کسی دوسری فیلڈ کی طرح ہستیوں پر کی جاتی ہے سوائے اس کے کہ مخصوص کردہ قسم کسی اور ہستی کی ہو.
+
+#### ون-ٹو-ون تعلقات
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### ون-ٹو-مینی تعلقات
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### ریورس لک اپس
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+ون-ٹو-مینی تعلقات کے لیے، تعلق کو ہمیشہ 'ون' سائیڈ پر رکھنا چاہیے، اور 'مینی' سائیڈ کو ہمیشہ اخذ کیا جانا چاہیے۔ 'مینی' سائیڈ پر ہستیوں کی ایک ایرے کو ذخیرہ کرنے کے بجائے اس طرح سے تعلق کو ذخیرہ کرنے کے نتیجے میں سب گراف کی انڈیکسنگ اور کیوریز دونوں کے لیے نمایاں طور پر بہتر کارکردگی ہوگی۔ عام طور پر، ہستیوں کی ایریز کو ذخیرہ کرنے سے اتنا ہی گریز کیا جانا چاہیے جتنا کہ عملی ہو.
+
+#### مثال
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### ون-ٹو-مینی تعلقات
+
+مینی-ٹو-مینی تعلقات کے لیے، جیسے کہ صارفین جن میں سے ہر ایک کا تعلق کسی بھی تعداد میں تنظیموں سے ہو سکتا ہے، سب سے سیدھا، لیکن عام طور پر سب سے زیادہ پرفارمنس نہیں، تعلق کو ماڈل کرنے کا طریقہ شامل دونوں ہستیوں میں سے ہر ایک میں ایک ایرے کے طور پر ہے۔ اگر تعلق ہم آہنگ ہے تو، رشتے کے صرف ایک رخ کو ذخیرہ کرنے کی ضرورت ہے اور دوسری طرف اخذ کیا جا سکتا ہے.
+
+#### مثال
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+اس نقطہ نظر کا تقاضا ہے کہ کیوریز کو بازیافت کرنے کے لیے ایک اضافی سطح پر اتریں، مثال کے طور پر، صارفین کے لیے تنظیمیں:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+Many-to-many تعلقات کو ذخیرہ کرنے کے اس زیادہ وسیع طریقے کے نتیجے میں سب گراف کے لیے کم ڈیٹا ذخیرہ کیا جائے گا، اور اس لیے ایک سب گراف میں جو اکثر نمایاں طور پر انڈیکس اور کیوری کے لیے تیز تر ہوتا ہے.
+
+### اسکیما میں کامینٹس شامل کرنا
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## فل ٹیکسٹ سرچ فیلڈز کی وضاحت کرنا
+
+ٹیکسٹ سرچ ان پٹ کی بنیاد پر فل ٹیکسٹ سرچ کیوریز ہستیوں کو فلٹر اور رینک کرتی ہیں. فل ٹیکسٹ کیوریز انڈیکس شدہ ٹیکسٹ ڈیٹا سے موازنہ کرنے سے پہلے کیوری کے متن کے ان پٹ کو سٹیمز میں پروسیس کرکے ملتے جلتے الفاظ کے میچز واپس کرنے کے قابل ہیں.
+
+فل ٹیکسٹ کیوری کی تعریف میں کیوری کا نام، ٹیکسٹ فیلڈز پر کارروائی کرنے کے لیے استعمال ہونے والی زبات کی لغت، نتائج کو ترتیب دینے کے لیے استعمال ہونے والا رینکنگ ایلگورتھم، اور تلاش میں شامل فیلڈز شامل ہیں. ہر فل ٹیکسٹ کیوری ایک سے زیادہ فیلڈز پر محیط ہو سکتا ہے، لیکن تمام شامل فیلڈز ایک ہی ہستی کی قسم سے ہونے چاہئیں.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## تعاون یافتہ زبانیں ہیں
+
+ایک مختلف زبان کا انتخاب فل ٹیکسٹ کی تلاش کی API پر حتمی، اگرچہ بعض اوقات لطیف، اثر رکھتا ہے۔ فل ٹیکسٹ کیوری والے فیلڈز کا احاطہ منتخب کردہ زبان کے تناظر میں کیا جاتا ہے، اس لیے تجزیہ اور تلاش کی کیوریز کے ذریعہ تیار کردہ لیگزیمز زبان سے دوسری زبان میں مختلف ہوتے ہیں۔ مثال کے طور پر: جب تعاون یافتہ ترکی لغت کا استعمال کرتے ہوئے "ٹوکن" کو "ٹوک" کے لیے سٹیم کیا جاتا ہے، جب کہ، یقیناً، انگریزی لغت اسے "ٹوکن" پر سٹیم کرے گی.
+
+معاون زبانوں کی لغت:
+
+| Code   | Dictionary |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | پرتگالی    |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### درجہ بندی الگورتھم
+
+نتائج ترتیب دینے کے لیے معاون الگورتھم:
+
+| Algorithm     | Description                                                                 |
+| ------------- | --------------------------------------------------------------------------- |
+| rank          | نتائج ترتیب دینے کے لیے فل ٹیکسٹ کیوری کے میچ کوالٹی (1-0) کا استعمال کریں. |
+| قربت کا درجہ  | Similar to rank but also includes the proximity of the matches.             |

From 30efd87aeceb1f4586f02c25360629c7ec517e59 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:00 -0500
Subject: [PATCH 1810/3820] New translations ql-schema.mdx (Vietnamese)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/vi/subgraphs/developing/creating/ql-schema.mdx b/website/pages/vi/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..35b49bcb5f4f
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Tổng quan
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Ví dụ tốt
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Ví dụ tồi
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Các trường tùy chọn và bắt buộc
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Giá trị rỗng (null) được giải quyết cho trường không phải null 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Các loại vô hướng tích hợp
+
+#### GraphQL Vô hướng được hỗ trợ
+
+The following scalars are supported in the GraphQL API:
+
+| Loại         | Miêu tả                                                                                                                                                                                                          |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Mảng byte, được biểu diễn dưới dạng chuỗi thập lục phân. Thường được sử dụng cho các mã băm và địa chỉ Ethereum.                                                                                                 |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+You can also create enums within a schema. Enums have the following syntax:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Mối quan hệ thực thể
+
+An entity may have a relationship to one or more other entities in your schema. These relationships may be traversed in your queries. Relationships in The Graph are unidirectional. It is possible to simulate bidirectional relationships by defining a unidirectional relationship on either "end" of the relationship.
+
+Relationships are defined on entities just like any other field except that the type specified is that of another entity.
+
+#### Mối quan hệ một-một
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### Mối quan hệ một-nhiều
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Tra cứu ngược
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived. Storing the relationship this way, rather than storing an array of entities on the 'many' side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.
+
+#### Ví dụ
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Mối quan hệ nhiều-nhiều
+
+For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.
+
+#### Ví dụ
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+This approach requires that queries descend into one additional level to retrieve, for example, the organizations for users:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+This more elaborate way of storing many-to-many relationships will result in less data stored for the subgraph, and therefore to a subgraph that is often dramatically faster to index and to query.
+
+### Adding comments to the schema
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Xác định các Trường Tìm kiếm toàn Văn bản
+
+Fulltext search queries filter and rank entities based on a text search input. Fulltext queries are able to return matches for similar words by processing the query text input into stems before comparing them to the indexed text data.
+
+A fulltext query definition includes the query name, the language dictionary used to process the text fields, the ranking algorithm used to order the results, and the fields included in the search. Each fulltext query may span multiple fields, but all included fields must be from a single entity type.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Các ngôn ngữ được hỗ trợ
+
+Choosing a different language will have a definitive, though sometimes subtle, effect on the fulltext search API. Fields covered by a fulltext query field are examined in the context of the chosen language, so the lexemes produced by analysis and search queries vary from language to language. For example: when using the supported Turkish dictionary "token" is stemmed to "toke" while, of course, the English dictionary will stem it to "token".
+
+Supported language dictionaries:
+
+| Code   | Từ điển    |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Portuguese |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### Thuật toán Xếp hạng
+
+Supported algorithms for ordering results:
+
+| Algorithm     | Description                                                                     |
+| ------------- | ------------------------------------------------------------------------------- |
+| rank          | Sử dụng chất lượng đối sánh (0-1) của truy vấn toàn văn bản để sắp xếp kết quả. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.                 |

From 516c23474d75045b09b06490613df6476aa2c9eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:02 -0500
Subject: [PATCH 1811/3820] New translations ql-schema.mdx (Marathi)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/mr/subgraphs/developing/creating/ql-schema.mdx b/website/pages/mr/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..9439044d14b6
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## सविश्लेषण
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### उत्तम उदाहरण
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### वाईट उदाहरण
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### पर्यायी आणि आवश्यक फील्ड
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+नॉन-नल फील्ड 'नावासाठी शून्य मूल्य सोडवले
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### अंगभूत स्केलर प्रकार
+
+#### ग्राफक्यूएल समर्थित स्केलर
+
+The following scalars are supported in the GraphQL API:
+
+| प्रकार       | वर्णन                                                                                                                                                                                                            |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### एनम्स
+
+You can also create enums within a schema. Enums have the following syntax:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### अस्तित्व संबंध
+
+एखाद्या घटकाचा तुमच्या स्कीमामधील एक किंवा अधिक इतर घटकांशी संबंध असू शकतो. हे नातेसंबंध तुमच्या प्रश्नांमध्ये असू शकतात. आलेखामधील संबंध दिशाहीन आहेत. नात्याच्या "शेवट" वर एकदिशात्मक संबंध परिभाषित करून द्विदिशात्मक संबंधांचे अनुकरण करणे शक्य आहे.
+
+Relationships are defined on entities just like any other field except that the type specified is that of another entity.
+
+#### वन-टू-वन संबंध
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### एक-ते-अनेक संबंध
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### उलटे लुकअप
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+एक-ते-अनेक संबंधांसाठी, संबंध नेहमी 'एका' बाजूला साठवले पाहिजेत आणि 'अनेक' बाजू नेहमी काढल्या पाहिजेत. 'अनेक' बाजूंवर संस्थांचा अ‍ॅरे संचयित करण्याऐवजी अशा प्रकारे नातेसंबंध संचयित केल्याने, अनुक्रमणिका आणि सबग्राफ क्वेरी या दोन्हीसाठी नाटकीयरित्या चांगले कार्यप्रदर्शन होईल. सर्वसाधारणपणे, घटकांचे अ‍ॅरे संग्रहित करणे जितके व्यावहारिक आहे तितके टाळले पाहिजे.
+
+#### उदाहरण
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### अनेक-ते-अनेक संबंध
+
+अनेक-ते-अनेक नातेसंबंधांसाठी, जसे की वापरकर्ते जे कोणत्याही संस्थेशी संबंधित असू शकतात, सर्वात सरळ, परंतु सामान्यतः सर्वात कार्यक्षम नसतात, संबंध मॉडेल करण्याचा मार्ग समाविष्ट असलेल्या दोन घटकांपैकी प्रत्येकामध्ये एक अॅरे आहे. नातेसंबंध सममितीय असल्यास, नातेसंबंधाची फक्त एक बाजू संग्रहित करणे आवश्यक आहे आणि दुसरी बाजू मिळवता येते.
+
+#### उदाहरण
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+This approach requires that queries descend into one additional level to retrieve, for example, the organizations for users:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+अनेक-ते-अनेक संबंध संचयित करण्याच्या या अधिक विस्तृत मार्गामुळे सबग्राफसाठी कमी डेटा संग्रहित केला जाईल आणि म्हणूनच अनुक्रमणिका आणि क्वेरीसाठी नाटकीयरित्या वेगवान असलेल्या सबग्राफमध्ये.
+
+### स्कीमामध्ये टिप्पण्या जोडत आहे
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## पूर्ण मजकूर शोध फील्ड परिभाषित करणे
+
+मजकूर शोध इनपुटवर आधारित फुलटेक्स्ट शोध क्वेरी फिल्टर आणि रँक घटक. फुलटेक्स्ट क्वेरी अनुक्रमित मजकूर डेटाशी तुलना करण्यापूर्वी स्टेममध्ये क्वेरी मजकूर इनपुटवर प्रक्रिया करून समान शब्दांसाठी जुळणी परत करण्यास सक्षम आहेत.
+
+पूर्ण मजकूर क्वेरी व्याख्येमध्ये क्वेरीचे नाव, मजकूर फील्डवर प्रक्रिया करण्यासाठी वापरला जाणारा भाषा शब्दकोष, परिणाम ऑर्डर करण्यासाठी वापरले जाणारे रँकिंग अल्गोरिदम आणि शोधामध्ये समाविष्ट फील्ड समाविष्ट असतात. प्रत्येक फुलटेक्स्ट क्वेरी एकाधिक फील्डमध्ये असू शकते, परंतु सर्व समाविष्ट फील्ड एकाच घटक प्रकारातील असणे आवश्यक आहे.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## भाषा समर्थित
+
+भिन्न भाषा निवडल्याने पूर्ण मजकूर शोध API वर निश्चित, काहीवेळा सूक्ष्म असले तरी परिणाम होईल. फुलटेक्स्ट क्वेरी फील्डद्वारे कव्हर केलेले फील्ड निवडलेल्या भाषेच्या संदर्भात तपासले जातात, म्हणून विश्लेषण आणि शोध क्वेरीद्वारे तयार केलेले लेक्सेम भाषेनुसार भिन्न असतात. उदाहरणार्थ: समर्थित तुर्की शब्दकोश वापरताना "टोकन" हे "टोक" वर स्टेम केले जाते, तर अर्थातच, इंग्रजी शब्दकोश "टोकन" वर स्टेम करेल.
+
+समर्थित भाषा शब्दकोश:
+
+| Code   | शब्दकोश    |
+| ------ | ---------- |
+| सोपे   | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | पोर्तुगीज  |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### रँकिंग अल्गोरिदम
+
+परिणाम ऑर्डर करण्यासाठी समर्थित अल्गोरिदम:
+
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | निकाल ऑर्डर करण्यासाठी फुलटेक्स्ट क्वेरीची जुळणी गुणवत्ता (0-1) वापरा.  |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From d83256bbeab33b20003686c25e8de5416c205825 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:03 -0500
Subject: [PATCH 1812/3820] New translations ql-schema.mdx (Hindi)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/hi/subgraphs/developing/creating/ql-schema.mdx b/website/pages/hi/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..86b348a2d8b9
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## अवलोकन
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### संपत्ति परिभाषित करना
+
+इससे पहले कि आप एन्टिटीज को परिभाषित करें, यह महत्वपूर्ण है कि आप एक कदम पीछे हटें और सोचें कि आपका डेटा कैसे संरचित और लिंक किया गया है।
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- यह उपयोगी हो सकता है कि संस्थाओं की कल्पना 'डेटा' समाहित करने वाले वस्तुओं के रूप में की जाए, न कि घटनाओं या कार्यों के रूप में।
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- डिफ़ॉल्ट रूप से, संस्थाएँ परिवर्तनीय होती हैं, जिसका अर्थ है कि मैपिंग मौजूदा संस्थाओं को लोड कर सकती हैं, उन्हें संशोधित कर सकती हैं और उस संस्थान के एक नए संस्करण को संग्रहीत कर सकती हैं।
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - अगर किसी एंटिटी को बनाने वाले उसी ब्लॉक में परिवर्तन होते हैं, तो मैपिंग्स अम्यूटेबल एंटिटीज़ में परिवर्तन कर सकती हैं। अम्यूटेबल एंटिटीज़ को लिखने और क्वेरी करने में बहुत तेज़ होती हैं, इसलिए इन्हें संभव होने पर उपयोग करना चाहिए।
+
+#### अच्छा उदाहरण
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### खराब उदाहरण
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### वैकल्पिक और आवश्यक फ़ील्ड
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+गैर-शून्य फ़ील्ड 'नाम' के लिए हल किया गया शून्य मान
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### बिल्ट-इन स्केलर प्रकार
+
+#### ग्राफक्यूएल समर्थित स्केलर्स
+
+नीचे दिए गए स्केलर्स GraphQL API में समर्थित हैं:
+
+| प्रकार       | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | बाइट सरणी, एक हेक्साडेसिमल स्ट्रिंग के रूप में दर्शाया गया है। आमतौर पर एथेरियम हैश और पतों के लिए उपयोग किया जाता है।                                                                                           |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+आप स्कीमा के भीतर एनम भी बना सकते हैं। Enums में निम्न सिंटैक्स होता है:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### निकाय संबंध
+
+एक इकाई का आपकी स्कीमा में एक या अधिक अन्य संस्थाओं से संबंध हो सकता है। आपके प्रश्नों में इन संबंधों का पता लगाया जा सकता है। ग्राफ़ में रिश्ते यूनिडायरेक्शनल हैं। रिश्ते के किसी भी "अंत" पर एक यूनिडायरेक्शनल रिश्ते को परिभाषित करके द्विपक्षीय संबंधों को अनुकरण करना संभव है।
+
+संस्थाओं पर संबंधों को किसी अन्य क्षेत्र की तरह ही परिभाषित किया जाता है सिवाय इसके कि निर्दिष्ट प्रकार किसी अन्य इकाई का है।
+
+#### एक-से-एक संबंध
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### एक से कई रिश्ते
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### रिवर्स लुकअप
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+एक-से-अनेक संबंधों के लिए, संबंध को हमेशा 'एक' पक्ष में संग्रहीत किया जाना चाहिए, और 'अनेक' पक्ष हमेशा निकाला जाना चाहिए। संबंधों को इस तरह से संग्रहीत करने के बजाय, 'अनेक' पक्ष पर संस्थाओं की एक सरणी संग्रहीत करने के परिणामस्वरूप, सबग्राफ को अनुक्रमित करने और क्वेरी करने दोनों के लिए नाटकीय रूप से बेहतर प्रदर्शन होगा। सामान्य तौर पर, संस्थाओं की सरणियों को संग्रहीत करने से जितना संभव हो उतना बचा जाना चाहिए।
+
+#### उदाहरण
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### अनेक-से-अनेक संबंध
+
+मैनी-टू-मैनी संबंधों के लिए, जैसे कि प्रत्येक उपयोगकर्ता किसी भी संख्या में संगठनों से संबंधित हो सकता है, सबसे सरल, लेकिन आम तौर पर सबसे अधिक प्रदर्शनकारी नहीं, संबंध को मॉडल करने का तरीका शामिल दो संस्थाओं में से प्रत्येक में एक सरणी के रूप में है। यदि संबंध सममित है, तो संबंध के केवल एक पक्ष को संग्रहित करने की आवश्यकता है और दूसरे पक्ष को व्युत्पन्न किया जा सकता है।
+
+#### उदाहरण
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+इस दृष्टिकोण के लिए आवश्यक है कि प्रश्नों को पुनः प्राप्त करने के लिए एक अतिरिक्त स्तर में उतरना पड़े, उदाहरण के लिए, उपयोगकर्ताओं के लिए संगठन:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+मैनी-टू-मैनी संबंधों को संग्रहीत करने के इस अधिक विस्तृत तरीके के परिणामस्वरूप सबग्राफ के लिए कम डेटा संग्रहीत होगा, और इसलिए एक सबग्राफ के लिए जो अक्सर इंडेक्स और क्वेरी के लिए नाटकीय रूप से तेज़ होता है।
+
+### स्कीमा में टिप्पणियां जोड़ना
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## फुलटेक्स्ट सर्च फील्ड्स को परिभाषित करना
+
+पूर्ण पाठ खोज क्वेरी फ़िल्टर करती है और पाठ खोज इनपुट के आधार पर संस्थाओं को रैंक करती है। अनुक्रमित टेक्स्ट डेटा से तुलना करने से पहले क्वेरी टेक्स्ट इनपुट को तने में संसाधित करके पूर्ण टेक्स्ट क्वेरी समान शब्दों के लिए मैच वापस करने में सक्षम हैं।
+
+एक पूर्ण पाठ क्वेरी परिभाषा में क्वेरी का नाम, पाठ फ़ील्ड को संसाधित करने के लिए उपयोग किया जाने वाला भाषा शब्दकोश, परिणामों को क्रमबद्ध करने के लिए उपयोग किया जाने वाला रैंकिंग एल्गोरिदम और खोज में शामिल फ़ील्ड शामिल हैं। प्रत्येक पूर्ण-पाठ क्वेरी में कई फ़ील्ड शामिल हो सकते हैं, लेकिन सभी शामिल फ़ील्ड एक इकाई प्रकार से होने चाहिए।
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## भाषाओं का समर्थन किया
+
+एक अलग भाषा का चयन एक निश्चित, हालांकि कभी-कभी सूक्ष्म, पूर्ण पाठ खोज एपीआई पर प्रभाव डालेगा। पूर्ण-पाठ क्वेरी फ़ील्ड द्वारा कवर किए गए फ़ील्ड को चुनी हुई भाषा के संदर्भ में जांचा जाता है, इसलिए विश्लेषण और खोज क्वेरी द्वारा उत्पन्न शब्दांश भाषा से भाषा में भिन्न होते हैं। उदाहरण के लिए: समर्थित तुर्की शब्दकोश "टोकन" का उपयोग करते समय "टोकन" के लिए स्टेम किया जाता है, जबकि निश्चित रूप से, अंग्रेजी शब्दकोश इसे "टोकन" के लिए स्टेम करेगा।
+
+समर्थित भाषा शब्दकोश:
+
+| Code   | शब्दकोष    |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | पुर्तगाली  |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### रैंकिंग एल्गोरिदम
+
+परिणाम ऑर्डर करने के लिए समर्थित एल्गोरिदम:
+
+| Algorithm     | Description                                                                               |
+| ------------- | ----------------------------------------------------------------------------------------- |
+| rank          | परिणामों को व्यवस्थित करने के लिए पूर्ण पाठ क्वेरी की मिलान गुणवत्ता (0-1) का उपयोग करें। |
+| proximityRank | Similar to rank but also includes the proximity of the matches.                           |

From 9b57b4d9ba6ecb8186bfa5d7a2800860088acdd2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:04 -0500
Subject: [PATCH 1813/3820] New translations ql-schema.mdx (Swahili)

---
 .../developing/creating/ql-schema.mdx         | 312 ++++++++++++++++++
 1 file changed, 312 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/creating/ql-schema.mdx

diff --git a/website/pages/sw/subgraphs/developing/creating/ql-schema.mdx b/website/pages/sw/subgraphs/developing/creating/ql-schema.mdx
new file mode 100644
index 000000000000..8e5789d66650
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/creating/ql-schema.mdx
@@ -0,0 +1,312 @@
+---
+title: The Graph QL Schema
+---
+
+## Overview
+
+The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+
+> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+
+### Defining Entities
+
+Before defining entities, it is important to take a step back and think about how your data is structured and linked.
+
+- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- It may be useful to imagine entities as "objects containing data", rather than as events or functions.
+- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
+- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- By default, entities are mutable, meaning that mappings can load existing entities, modify them and store a new version of that entity.
+  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - If changes happen in the same block in which the entity was created, then mappings can make changes to immutable entities. Immutable entities are much faster to write and to query so they should be used whenever possible.
+
+#### Good Example
+
+The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+
+```graphql
+type Gravatar @entity(immutable: true) {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+  accepted: Boolean
+}
+```
+
+#### Bad Example
+
+The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+
+```graphql
+type GravatarAccepted @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+
+type GravatarDeclined @entity {
+  id: Bytes!
+  owner: Bytes
+  displayName: String
+  imageUrl: String
+}
+```
+
+#### Optional and Required Fields
+
+Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+
+```
+Null value resolved for non-null field 'name'
+```
+
+Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+
+For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+
+### Built-In Scalar Types
+
+#### GraphQL Supported Scalars
+
+The following scalars are supported in the GraphQL API:
+
+| Type         | Description                                                                                                                                                                                                      |
+| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Byte array, represented as a hexadecimal string. Commonly used for Ethereum hashes and addresses.                                                                                                                |
+| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
+| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
+| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
+| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
+| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
+| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
+| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+
+### Enums
+
+You can also create enums within a schema. Enums have the following syntax:
+
+```graphql
+enum TokenStatus {
+  OriginalOwner
+  SecondOwner
+  ThirdOwner
+}
+```
+
+Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+
+More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+
+### Entity Relationships
+
+An entity may have a relationship to one or more other entities in your schema. These relationships may be traversed in your queries. Relationships in The Graph are unidirectional. It is possible to simulate bidirectional relationships by defining a unidirectional relationship on either "end" of the relationship.
+
+Relationships are defined on entities just like any other field except that the type specified is that of another entity.
+
+#### One-To-One Relationships
+
+Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+
+```graphql
+type Transaction @entity(immutable: true) {
+  id: Bytes!
+  transactionReceipt: TransactionReceipt
+}
+
+type TransactionReceipt @entity(immutable: true) {
+  id: Bytes!
+  transaction: Transaction
+}
+```
+
+#### One-To-Many Relationships
+
+Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+### Reverse Lookups
+
+Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+
+For one-to-many relationships, the relationship should always be stored on the 'one' side, and the 'many' side should always be derived. Storing the relationship this way, rather than storing an array of entities on the 'many' side, will result in dramatically better performance for both indexing and querying the subgraph. In general, storing arrays of entities should be avoided as much as is practical.
+
+#### Example
+
+We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+
+```graphql
+type Token @entity(immutable: true) {
+  id: Bytes!
+  tokenBalances: [TokenBalance!]! @derivedFrom(field: "token")
+}
+
+type TokenBalance @entity {
+  id: Bytes!
+  amount: Int!
+  token: Token!
+}
+```
+
+#### Many-To-Many Relationships
+
+For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.
+
+#### Example
+
+Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [User!]!
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [Organization!]! @derivedFrom(field: "members")
+}
+```
+
+A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+
+```graphql
+type Organization @entity {
+  id: Bytes!
+  name: String!
+  members: [UserOrganization!]! @derivedFrom(field: "organization")
+}
+
+type User @entity {
+  id: Bytes!
+  name: String!
+  organizations: [UserOrganization!] @derivedFrom(field: "user")
+}
+
+type UserOrganization @entity {
+  id: Bytes! # Set to `user.id.concat(organization.id)`
+  user: User!
+  organization: Organization!
+}
+```
+
+This approach requires that queries descend into one additional level to retrieve, for example, the organizations for users:
+
+```graphql
+query usersWithOrganizations {
+  users {
+    organizations {
+      # this is a UserOrganization entity
+      organization {
+        name
+      }
+    }
+  }
+}
+```
+
+This more elaborate way of storing many-to-many relationships will result in less data stored for the subgraph, and therefore to a subgraph that is often dramatically faster to index and to query.
+
+### Adding comments to the schema
+
+As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+
+```graphql
+type MyFirstEntity @entity {
+  # unique identifier and primary key of the entity
+  id: Bytes!
+  address: Bytes!
+}
+```
+
+## Defining Fulltext Search Fields
+
+Fulltext search queries filter and rank entities based on a text search input. Fulltext queries are able to return matches for similar words by processing the query text input into stems before comparing them to the indexed text data.
+
+A fulltext query definition includes the query name, the language dictionary used to process the text fields, the ranking algorithm used to order the results, and the fields included in the search. Each fulltext query may span multiple fields, but all included fields must be from a single entity type.
+
+To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+
+```graphql
+type _Schema_
+  @fulltext(
+    name: "bandSearch"
+    language: en
+    algorithm: rank
+    include: [{ entity: "Band", fields: [{ name: "name" }, { name: "description" }, { name: "bio" }] }]
+  )
+
+type Band @entity {
+  id: Bytes!
+  name: String!
+  description: String!
+  bio: String
+  wallet: Address
+  labels: [Label!]!
+  discography: [Album!]!
+  members: [Musician!]!
+}
+```
+
+The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+
+```graphql
+query {
+  bandSearch(text: "breaks & electro & detroit") {
+    id
+    name
+    description
+    wallet
+  }
+}
+```
+
+> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+
+## Languages supported
+
+Choosing a different language will have a definitive, though sometimes subtle, effect on the fulltext search API. Fields covered by a fulltext query field are examined in the context of the chosen language, so the lexemes produced by analysis and search queries vary from language to language. For example: when using the supported Turkish dictionary "token" is stemmed to "toke" while, of course, the English dictionary will stem it to "token".
+
+Supported language dictionaries:
+
+| Code   | Dictionary |
+| ------ | ---------- |
+| simple | General    |
+| da     | Danish     |
+| nl     | Dutch      |
+| en     | English    |
+| fi     | Finnish    |
+| fr     | French     |
+| de     | German     |
+| hu     | Hungarian  |
+| it     | Italian    |
+| no     | Norwegian  |
+| pt     | Portuguese |
+| ro     | Romanian   |
+| ru     | Russian    |
+| es     | Spanish    |
+| sv     | Swedish    |
+| tr     | Turkish    |
+
+### Ranking Algorithms
+
+Supported algorithms for ordering results:
+
+| Algorithm     | Description                                                             |
+| ------------- | ----------------------------------------------------------------------- |
+| rank          | Use the match quality (0-1) of the fulltext query to order the results. |
+| proximityRank | Similar to rank but also includes the proximity of the matches.         |

From 9bad43074e6671791da56b5a420f52cc8bf2a7e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:06 -0500
Subject: [PATCH 1814/3820] New translations subgraph-manifest.mdx (Romanian)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/ro/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/ro/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..a42a50973690
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Overview
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+The important entries to update for the manifest are:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Call Handlers
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Call handlers will only trigger in one of two cases: when the function specified is called by an account other than the contract itself or when it is marked as external in Solidity and called as part of another function in the same contract.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Defining a Call Handler
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Mapping Function
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Block Handlers
+
+In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a pre-defined filter.
+
+### Supported Filters
+
+#### Call Filter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+The absence of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Mapping Function
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Anonymous Events
+
+If you need to process anonymous events in Solidity, that can be achieved by providing the topic 0 of the event, as in the example:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Transaction Receipts in Event Handlers
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+The triggers for a data source within a block are ordered using the following process:
+
+1. Event and call triggers are first ordered by transaction index within the block.
+2. Event and call triggers within the same transaction are ordered using a convention: event triggers first then call triggers, each type respecting the order they are defined in the manifest.
+3. Block triggers are run after event and call triggers, in the order they are defined in the manifest.
+
+These ordering rules are subject to change.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Data Source Templates
+
+A common pattern in EVM-compatible smart contracts is the use of registry or factory contracts, where one contract creates, manages, or references an arbitrary number of other contracts that each have their own state and events.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Data Source for the Main Contract
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Data Source Templates for Dynamically Created Contracts
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Instantiating a Data Source Template
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> If prior blocks contain data relevant to the new data source, it is best to index that data by reading the current state of the contract and creating entities representing that state at the time the new data source is created.
+
+### Data Source Context
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Start Blocks
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Search for the contract by entering its address in the search bar.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Load the transaction details page where you'll find the start block for that contract.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From f783fffa78e015832fb830dc9f682d923c913b88 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:07 -0500
Subject: [PATCH 1815/3820] New translations subgraph-manifest.mdx (French)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/fr/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/fr/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..3edebaf3385e
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Aperçu
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+Un seul subgraph peut :
+
+- Indexer les données de plusieurs contrats intelligents (mais pas de plusieurs réseaux).
+
+- Indexer des données de fichiers IPFS en utilisant des File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+version spec : 0.0.4
+description : Gravatar pour Ethereum
+référentiel : https://github.com/graphprotocol/graph-tooling
+schéma:
+   fichier : ./schema.graphql
+indexeurConseils :
+   tailler : automatique
+les sources de données:
+   - genre : ethereum/contrat
+     nom: Gravité
+     réseau : réseau principal
+     source:
+       adresse : '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+       abi : Gravité
+       bloc de démarrage : 6175244
+       bloc de fin : 7175245
+     contexte:
+       foo :
+         tapez : Booléen
+         données : vrai
+       bar:
+         tapez : chaîne
+         données : 'barre'
+     cartographie :
+       genre : ethereum/événements
+       Version api : 0.0.6
+       langage : wasm/assemblyscript
+       entités :
+         -Gravatar
+       abis :
+         - nom : Gravité
+           fichier : ./abis/Gravity.json
+       Gestionnaires d'événements :
+         - événement : NewGravatar(uint256,adresse,chaîne,chaîne)
+           gestionnaire : handleNewGravatar
+         - événement : UpdatedGravatar (uint256, adresse, chaîne, chaîne)
+           gestionnaire : handleUpdatedGravatar
+       Gestionnaires d'appels :
+         - fonction : createGravatar(string,string)
+           gestionnaire : handleCreateGravatar
+       gestionnaires de blocs :
+         - gestionnaire : handleBlock
+         - gestionnaire : handleBlockWithCall
+           filtre:
+             genre : appeler
+       fichier : ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+Les entrées importantes à mettre à jour pour le manifeste sont :
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Gestionnaires d'événements
+
+Les gestionnaires d'événements dans un subgraph réagissent à des événements spécifiques émis par des contrats intelligents sur la blockchain et déclenchent des gestionnaires définis dans le manifeste du subgraph. Ceci permet aux subgraphs de traiter et de stocker les données des événements selon une logique définie.
+
+### Définition d'un gestionnaire d'événements
+
+Un gestionnaire d'événements est déclaré dans une source de données dans la configuration YAML du subgraph. Il spécifie quels événements écouter et la fonction correspondante à exécuter lorsque ces événements sont détectés.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Filtre de rubrique optionnel qui filtre uniquement les événements avec la rubrique spécifiée.
+```
+
+## Gestionnaires d'appels
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Les gestionnaires d'appels ne se déclencheront que dans l'un des deux cas suivants : lorsque la fonction spécifiée est appelée par un compte autre que le contrat lui-même ou lorsqu'elle est marquée comme externe dans Solidity et appelée dans le cadre d'une autre fonction du même contrat.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Définir un gestionnaire d'appels
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Fonction de cartographie
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Block Handlers
+
+En plus de s'abonner à des événements de contrat ou à des appels de fonction, un subgraph peut souhaiter mettre à jour ses données à mesure que de nouveaux blocs sont ajoutés à la chaîne. Pour y parvenir, un subgraph peut exécuter une fonction après chaque bloc ou après des blocs correspondant à un filtre prédéfini.
+
+### Filtres pris en charge
+
+#### Filtre d'appel
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+L'absence de filtre pour un gestionnaire de bloc garantira que le gestionnaire est appelé à chaque bloc. Une source de données ne peut contenir qu'un seul gestionnaire de bloc pour chaque type de filtre.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Filtre d'interrogation
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Le filtre Once
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+Le gestionnaire défini avec le filtre once ne sera appelé qu'une seule fois avant l'exécution de tous les autres gestionnaires. Cette configuration permet au subgraph d'utiliser le gestionnaire comme gestionnaire d'initialisation, effectuant des tâches spécifiques au début de l'indexation.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Fonction de cartographie
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Événements anonymes
+
+Si vous devez traiter des événements anonymes dans Solidity, cela peut être réalisé en fournissant le sujet 0 de l'événement, comme dans l'exemple :
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Reçus de transaction dans les gestionnaires d'événements
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Ordre de déclenchement des gestionnaires
+
+Les déclencheurs d'une source de données au sein d'un bloc sont classés à l'aide du processus suivant :
+
+1. Les déclencheurs d'événements et d'appels sont d'abord classés par index de transaction au sein du bloc.
+2. Les déclencheurs d'événements et d'appels au sein d'une même transaction sont classés selon une convention : les déclencheurs d'événements d'abord, puis les déclencheurs d'appel, chaque type respectant l'ordre dans lequel ils sont définis dans le manifeste.
+3. Les déclencheurs de bloc sont exécutés après les déclencheurs d'événement et d'appel, dans l'ordre dans lequel ils sont définis dans le manifeste.
+
+Ces règles de commande sont susceptibles de changer.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Modèles de sources de données
+
+Un modèle courant dans les contrats intelligents compatibles EVM est l'utilisation de contrats de registre ou d'usine, dans lesquels un contrat crée, gère ou référence un nombre arbitraire d'autres contrats qui ont chacun leur propre état et leurs propres événements.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Source de données pour le contrat principal
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Modèles de source de données pour les contrats créés dynamiquement
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Instanciation d'un modèle de source de données
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Commence à indexer l'échange ; `event.params.exchange` est le
+  // adresse du nouveau contrat d'échange
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> Si les blocs précédents contiennent des données pertinentes pour la nouvelle source de données, il est préférable d'indexer ces données en lisant l'état actuel du contrat et en créant des entités représentant cet état au moment de la création de la nouvelle source de données.
+
+### Data Source Context
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Blocs de démarrage
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Recherchez le contrat en saisissant son adresse dans la barre de recherche.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Chargez la page des détails de la transaction où vous trouverez le bloc de départ de ce contrat.
+
+## Conseils pour l'indexeur
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. Un nombre spécifique : Fixe une limite personnalisée au nombre de blocs historiques à conserver.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> Le terme "historique" dans ce contexte des subgraphs concerne le stockage des données qui reflètent les anciens états des entités mutables.
+
+L'historique à partir d'un bloc donné est requis pour :
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rembobiner le subgraph jusqu'à ce bloc
+
+Si les données historiques à partir du bloc ont été purgées, les capacités ci-dessus ne seront pas disponibles.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+Pour conserver une quantité spécifique de données historiques :
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+Préserver l'histoire complète des États de l'entité :
+
+```
+indexerHints:
+  prune: never
+```

From dc048b943761605def0b03523f6c41d56b0eea44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:08 -0500
Subject: [PATCH 1816/3820] New translations subgraph-manifest.mdx (Spanish)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/es/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/es/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..c825906fef29
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Descripción
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+Las entradas importantes a actualizar para el manifiesto son:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Call Handlers
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Los call handlers solo se activarán en uno de estos dos casos: cuando la función especificada sea llamada por una cuenta distinta del propio contrato o cuando esté marcada como externa en Solidity y sea llamada como parte de otra función en el mismo contrato.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Definición de un Call Handler
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Función mapeo
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Handlers de bloques
+
+Además de suscribirse a eventos del contracto o calls de funciones, un subgrafo puede querer actualizar sus datos a medida que se añaden nuevos bloques a la cadena. Para ello, un subgrafo puede ejecutar una función después de cada bloque o después de los bloques que coincidan con un filtro predefinido.
+
+### Filtros admitidos
+
+#### Call Filter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+La ausencia de un filtro para un handler de bloque asegurará que el handler sea llamado en cada bloque. Una fuente de datos solo puede contener un handler de bloque para cada tipo de filtro.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Función mapeo
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Eventos anónimos
+
+Si necesitas procesar eventos anónimos en Solidity, puedes hacerlo proporcionando el tema 0 del evento, como en el ejemplo:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Recepción de transacciones en Event Handlers
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+Las triggers de una fuente de datos dentro de un bloque se ordenan mediante el siguiente proceso:
+
+1. Las triggers de eventos y calls se ordenan primero por el índice de la transacción dentro del bloque.
+2. Los triggers de eventos y calls dentro de la misma transacción se ordenan siguiendo una convención: primero los triggers de eventos y luego los de calls, respetando cada tipo el orden en que se definen en el manifiesto.
+3. Las triggers de bloques se ejecutan después de las triggers de eventos y calls, en el orden en que están definidos en el manifiesto.
+
+Estas normas de orden están sujetas a cambios.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Plantillas para fuentes de datos
+
+Un patrón común en los contratos inteligentes de Ethereum es el uso de contratos de registro o fábrica, donde un contrato crea, gestiona o hace referencia a un número arbitrario de otros contratos que tienen cada uno su propio estado y eventos.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Fuente de Datos para el Contrato Principal
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Plantillas de fuentes de datos para contratos creados dinámicamente
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Instanciación de una plantilla de fuente de datos
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> Si los bloques anteriores contienen datos relevantes para la nueva fuente de datos, lo mejor es indexar esos datos leyendo el estado actual del contrato y creando entidades que representen ese estado en el momento de crear la nueva fuente de datos.
+
+### Contexto de la fuente de datos
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Bloques iniciales
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Busca el contrato introduciendo su dirección en la barra de búsqueda.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Carga la página de detalles de la transacción, donde encontrarás el bloque inicial de ese contrato.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From aae9c455c02bbb082f2d6a569c92754a76263889 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:09 -0500
Subject: [PATCH 1817/3820] New translations subgraph-manifest.mdx (Arabic)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/ar/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/ar/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..ba893838ca4e
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## نظره عامة
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+الإدخالات الهامة لتحديث manifest هي:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## معالجات الاستدعاء(Call Handlers)
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Call handlers will only trigger in one of two cases: when the function specified is called by an account other than the contract itself or when it is marked as external in Solidity and called as part of another function in the same contract.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### تعريف معالج الاستدعاء
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### دالة الـ Mapping
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## معالجات الكتلة
+
+In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a pre-defined filter.
+
+### الفلاتر المدعومة
+
+#### Call Filter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+The absence of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### دالة الـ Mapping
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## أحداث الـ مجهول
+
+If you need to process anonymous events in Solidity, that can be achieved by providing the topic 0 of the event, as in the example:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Transaction Receipts in Event Handlers
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+يتم ترتيب المشغلات (triggers) لمصدر البيانات داخل الكتلة باستخدام العملية التالية:
+
+1. يتم ترتيب triggers الأحداث والاستدعاءات أولا من خلال فهرس الإجراء داخل الكتلة.
+2. Event and call triggers within the same transaction are ordered using a convention: event triggers first then call triggers, each type respecting the order they are defined in the manifest.
+3. يتم تشغيل مشغلات الكتلة بعد مشغلات الحدث والاستدعاء، بالترتيب المحدد في الـ manifest.
+
+قواعد الترتيب هذه عرضة للتغيير.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## قوالب مصدر البيانات
+
+A common pattern in EVM-compatible smart contracts is the use of registry or factory contracts, where one contract creates, manages, or references an arbitrary number of other contracts that each have their own state and events.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### مصدر البيانات للعقد الرئيسي
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### قوالب مصدر البيانات للعقود التي تم إنشاؤها ديناميكيا
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### إنشاء قالب مصدر البيانات
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> إذا كانت الكتل السابقة تحتوي على بيانات ذات صلة بمصدر البيانات الجديد ، فمن الأفضل فهرسة تلك البيانات من خلال قراءة الحالة الحالية للعقد وإنشاء كيانات تمثل تلك الحالة في وقت إنشاء مصدر البيانات الجديد.
+
+### سياق مصدر البيانات
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## كتل البدء
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. ابحث عن العقد بإدخال عنوانه في شريط البحث.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. قم بتحميل صفحة تفاصيل الإجراء(transaction) حيث ستجد كتلة البدء لذلك العقد.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From f65777c48d9d63d098928c67ff60f191c20d9f5c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:10 -0500
Subject: [PATCH 1818/3820] New translations subgraph-manifest.mdx (Czech)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/cs/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/cs/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..a434110b4282
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Přehled
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+Důležité položky, které je třeba v manifestu aktualizovat, jsou:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Zpracovatelé hovorů
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Obsluhy volání se spustí pouze v jednom ze dvou případů: když je zadaná funkce volána jiným účtem než samotnou smlouvou nebo když je v Solidity označena jako externí a volána jako součást jiné funkce ve stejné smlouvě.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Definice obsluhy volání
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Funkce mapování
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Obsluha bloků
+
+Kromě přihlášení k událostem smlouvy nebo volání funkcí může podgraf chtít aktualizovat svá data, když jsou do řetězce přidány nové bloky. Za tímto účelem může podgraf spustit funkci po každém bloku nebo po blocích, které odpovídají předem definovanému filtru.
+
+### Podporované filtry
+
+#### Filtr volání
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+Protože pro obsluhu bloku neexistuje žádný filtr, zajistí, že obsluha bude volána každý blok. Zdroj dat může obsahovat pouze jednu blokovou obsluhu pro každý typ filtru.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Filtr dotazování
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Jednou Filtr
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+Definovaný obslužná rutina s filtrem once bude zavolána pouze jednou před spuštěním všech ostatních rutin. Tato konfigurace umožňuje, aby podgraf používal obslužný program jako inicializační obslužný, který provádí specifické úlohy na začátku indexování.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Funkce mapování
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Anonymní události
+
+Pokud potřebujete v Solidity zpracovávat anonymní události, lze toho dosáhnout zadáním tématu 0 události, jak je uvedeno v příkladu:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Potvrzení transakcí v obslužných rutinách událostí
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Pořadí spouštěcích Handlers
+
+Spouštěče pro zdroj dat v rámci bloku jsou seřazeny podle následujícího postupu:
+
+1. Spouštěče událostí a volání jsou nejprve seřazeny podle indexu transakce v rámci bloku.
+2. Spouštěče událostí a volání v rámci jedné transakce jsou seřazeny podle konvence: nejprve spouštěče událostí a poté spouštěče volání, přičemž každý typ dodržuje pořadí, v jakém jsou definovány v manifestu.
+3. Spouštěče bloků jsou spuštěny po spouštěčích událostí a volání, v pořadí, v jakém jsou definovány v manifestu.
+
+Tato pravidla objednávání se mohou změnit.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Šablony zdrojů dat
+
+Běžným vzorem v inteligentních smlouvách kompatibilních s EVM je používání registrů nebo továrních smluv, kdy jedna smlouva vytváří, spravuje nebo odkazuje na libovolný počet dalších smluv, z nichž každá má svůj vlastní stav a události.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Zdroj dat pro hlavní smlouvu
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Šablony zdrojů dat pro dynamicky vytvářené smlouvy
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Instancování šablony zdroje dat
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> Pokud předchozí bloky obsahují data relevantní pro nový zdroj dat, je nejlepší tato data indexovat načtením aktuálního stavu smlouvy a vytvořením entit reprezentujících tento stav v době vytvoření nového zdroje dat.
+
+### Kontext zdroje dat
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Výchozí bloky
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Vyhledejte smlouvu zadáním její adresy do vyhledávacího řádku.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Načtěte stránku s podrobnostmi o transakci, kde najdete počáteční blok pro danou smlouvu.
+
+## Tipy indexátor
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prořezávat
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. Konkrétní číslo: Nastaví vlastní limit počtu historických bloků, které se mají zachovat.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+Uchování určitého množství historických dat:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+Zachování kompletní historie entitních států:
+
+```
+indexerHints:
+  prune: never
+```

From eece3839b5881e26e321b598686a4e910fc46fbc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:11 -0500
Subject: [PATCH 1819/3820] New translations subgraph-manifest.mdx (German)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/de/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/de/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..caeba44d5358
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Overview
+
+Das Subgraph-Manifest, `subgraph.yaml`, definiert die Smart Contracts und das Netzwerk, die Ihr Subgraph indizieren wird, die Ereignisse aus diesen Verträgen, auf die geachtet werden soll, und wie die Ereignisdaten auf Entitäten abgebildet werden, die Graph Node speichert und abfragen kann.
+
+Die **Subgraph-Definition** besteht aus den folgenden Dateien:
+
+- subgraph.yaml": Enthält das Manifest des Subgraphen
+
+- schema.graphql": Ein GraphQL-Schema, das die für Ihren Subgraph gespeicherten Daten definiert und festlegt, wie sie über GraphQL abgefragt werden können
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph-Fähigkeiten
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+The important entries to update for the manifest are:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Call Handlers
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Call handlers will only trigger in one of two cases: when the function specified is called by an account other than the contract itself or when it is marked as external in Solidity and called as part of another function in the same contract.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Defining a Call Handler
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Mapping Function
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Block Handlers
+
+In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a pre-defined filter.
+
+### Supported Filters
+
+#### Call Filter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+The absence of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Mapping Function
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Anonymous Events
+
+If you need to process anonymous events in Solidity, that can be achieved by providing the topic 0 of the event, as in the example:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Transaction Receipts in Event Handlers
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+The triggers for a data source within a block are ordered using the following process:
+
+1. Event and call triggers are first ordered by transaction index within the block.
+2. Event and call triggers within the same transaction are ordered using a convention: event triggers first then call triggers, each type respecting the order they are defined in the manifest.
+3. Block triggers are run after event and call triggers, in the order they are defined in the manifest.
+
+These ordering rules are subject to change.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Data Source Templates
+
+A common pattern in EVM-compatible smart contracts is the use of registry or factory contracts, where one contract creates, manages, or references an arbitrary number of other contracts that each have their own state and events.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Data Source for the Main Contract
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Data Source Templates for Dynamically Created Contracts
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Instantiating a Data Source Template
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> If prior blocks contain data relevant to the new data source, it is best to index that data by reading the current state of the contract and creating entities representing that state at the time the new data source is created.
+
+### Data Source Context
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Start Blocks
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Search for the contract by entering its address in the search bar.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Load the transaction details page where you'll find the start block for that contract.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From 7c21693ce5e4e4e1cd68d34071c3d6b45501b88f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:12 -0500
Subject: [PATCH 1820/3820] New translations subgraph-manifest.mdx (Italian)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/it/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/it/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..d8b9c415b293
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Panoramica
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+Le voci importanti da aggiornare per il manifesto sono:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Gestori di chiamate
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+I gestori di chiamate si attivano solo in uno dei due casi: quando la funzione specificata viene chiamata da un conto diverso dal contratto stesso o quando è contrassegnata come esterna in Solidity e chiamata come parte di un'altra funzione nello stesso contratto.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Definire un gestore di chiamate
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Funzione di mappatura
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Gestori di blocchi
+
+Oltre a sottoscrivere eventi di contratto o chiamate di funzione, un subgraph può voler aggiornare i propri dati quando nuovi blocchi vengono aggiunti alla chain. A tale scopo, un subgraph può eseguire una funzione dopo ogni blocco o dopo i blocchi che corrispondono a un filtro predefinito.
+
+### Filtri supportati
+
+#### Filtro di chiamata
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+L'assenza di un filtro per un gestore di blocchi garantisce che il gestore venga chiamato a ogni blocco. Una data source può contenere un solo gestore di blocchi per ogni tipo di filtro.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Filtro di polling
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Filtro once
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+Il gestore definito con il filtro once sarà chiamato una sola volta prima dell'esecuzione di tutti gli altri gestori. Questa configurazione consente al subgraph di utilizzare il gestore come gestore di inizializzazione, eseguendo compiti specifici all'inizio dell'indicizzazione.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Funzione di mappatura
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Eventi anonimi
+
+Se è necessario elaborare eventi anonimi in Solidity, è possibile farlo fornendo l'argomento 0 dell'evento, come nell'esempio:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Ricevute di transazione nei gestori di eventi
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+I trigger per una data source all'interno di un blocco sono ordinati secondo il seguente processo:
+
+1. I trigger di eventi e chiamate sono ordinati prima per indice di transazione all'interno del blocco.
+2. I trigger di eventi e chiamate all'interno della stessa transazione sono ordinati secondo una convenzione: prima i trigger di eventi e poi quelli di chiamate, rispettando l'ordine in cui sono definiti nel manifesto.
+3. I trigger di blocco vengono eseguiti dopo i trigger di evento e di chiamata, nell'ordine in cui sono definiti nel manifesto.
+
+Queste regole di ordinazione sono soggette a modifiche.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Modelli di Data Source
+
+Un modello comune negli smart contract compatibili con EVM è l'uso di contratti di registro o di fabbrica, in cui un contratto crea, gestisce o fa riferimento a un numero arbitrario di altri contratti che hanno ciascuno il proprio stato e i propri eventi.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Data Source per il contratto principale
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Modelli di data source per contratti creati dinamicamente
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Istanziare un modello di data source
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> Se i blocchi precedenti contengono dati rilevanti per la nuova data source, è meglio indicizzare tali dati leggendo lo stato attuale del contratto e creando entità che rappresentino tale stato al momento della creazione della nuova data source.
+
+### Contesto del Data Source
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Blocchi di partenza
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Cercare il contratto inserendo l'indirizzo nella barra di ricerca.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Caricare la pagina dei dettagli della transazione, dove si trova il blocco iniziale per quel contratto.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From e1936031f48337370dc3a2480816c4afafd07138 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:14 -0500
Subject: [PATCH 1821/3820] New translations subgraph-manifest.mdx (Japanese)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/ja/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/ja/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..1fc82b54930d
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## 概要
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+マニフェストを更新する重要な項目は以下の通りです:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## コールハンドラー
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+コールハンドラーは、次の 2 つのケースのいずれかでのみトリガされます：指定された関数がコントラクト自身以外のアカウントから呼び出された場合、または Solidity で外部としてマークされ、同じコントラクト内の別の関数の一部として呼び出された場合。
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### コールハンドラーの定義
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### マッピング関数
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## ブロック・ハンドラー
+
+コントラクトイベントやファンクションコールの購読に加えて、サブグラフは、新しいブロックがチェーンに追加されると、そのデータを更新したい場合があります。これを実現するために、サブグラフは各ブロックの後、あるいは事前に定義されたフィルタにマッチしたブロックの後に、関数を実行することができます。
+
+### 対応フィルター
+
+#### 通話フィルター
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+ブロックハンドラーにフィルターがない場合、ハンドラーはブロックごとに呼び出されます。1 つのデータソースには、各フィルタータイプに対して 1 つのブロックハンドラーしか含めることができません。
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### ポーリングフィルター
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### ワンスフィルター
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+Once フィルターを使用して定義されたハンドラーは、他のすべてのハンドラーが実行される前に 1 回だけ呼び出されます。 この構成により、サブグラフはハンドラーを初期化ハンドラーとして使用し、インデックス作成の開始時に特定のタスクを実行できるようになります。
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### マッピング関数
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## 匿名イベント
+
+Solidity で匿名イベントを処理する必要がある場合は、例のようにイベントのトピック 0 を提供することで実現できます:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## イベントハンドラにおけるトランザクションレシーブ
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+ブロック内のデータソースのトリガーは、以下のプロセスを使用して順序付けられます:
+
+1. イベントとコールのトリガーは、ブロック内のトランザクションインデックスで最初に並べられます。
+2. 同じトランザクション内のイベントトリガーとコールトリガーは、マニフェストで定義されている順序にしたがって、イベントトリガーが先、コールトリガーが後という規則で並べられます。
+3. ブロックトリガーは、イベントトリガーとコールトリガーの後に、マニフェストで定義されている順番で実行されます。
+
+これらの順序規則は変更されることがあります。
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## データソーステンプレート
+
+EVM 互換のスマート コントラクトの一般的なパターンは、レジストリ コントラクトまたはファクトリ コントラクトの使用です。1 つのコントラクトが、それぞれ独自の状態とイベントを持つ任意の数の他のコントラクトを作成、管理、または参照します。
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### メインコントラクトのデータソース
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### 動的に作成されるコントラクトのデータソーステンプレート
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### データソーステンプレートのインスタンス化
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> 以前のブロックに新しいデータソースに関連するデータが含まれている場合は、コントラクトの現在の状態を読み取り、新しいデータソースが作成された時点でその状態を表すエンティティを作成することで、そのデータにインデックスを付けることが最善です。
+
+### データソースコンテクスト
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## スタートブロック(start Blocks)
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. 検索バーにアドレスを入力してコントラクトを検索します。
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. トランザクションの詳細ページを読み込んで、そのコントラクトの開始ブロックを見つけます。
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From 00c81b9bc1035e4b07cc9305bd1fd139ad98b0db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:15 -0500
Subject: [PATCH 1822/3820] New translations subgraph-manifest.mdx (Korean)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/ko/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/ko/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..a42a50973690
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Overview
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+The important entries to update for the manifest are:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Call Handlers
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Call handlers will only trigger in one of two cases: when the function specified is called by an account other than the contract itself or when it is marked as external in Solidity and called as part of another function in the same contract.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Defining a Call Handler
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Mapping Function
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Block Handlers
+
+In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a pre-defined filter.
+
+### Supported Filters
+
+#### Call Filter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+The absence of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Mapping Function
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Anonymous Events
+
+If you need to process anonymous events in Solidity, that can be achieved by providing the topic 0 of the event, as in the example:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Transaction Receipts in Event Handlers
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+The triggers for a data source within a block are ordered using the following process:
+
+1. Event and call triggers are first ordered by transaction index within the block.
+2. Event and call triggers within the same transaction are ordered using a convention: event triggers first then call triggers, each type respecting the order they are defined in the manifest.
+3. Block triggers are run after event and call triggers, in the order they are defined in the manifest.
+
+These ordering rules are subject to change.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Data Source Templates
+
+A common pattern in EVM-compatible smart contracts is the use of registry or factory contracts, where one contract creates, manages, or references an arbitrary number of other contracts that each have their own state and events.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Data Source for the Main Contract
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Data Source Templates for Dynamically Created Contracts
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Instantiating a Data Source Template
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> If prior blocks contain data relevant to the new data source, it is best to index that data by reading the current state of the contract and creating entities representing that state at the time the new data source is created.
+
+### Data Source Context
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Start Blocks
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Search for the contract by entering its address in the search bar.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Load the transaction details page where you'll find the start block for that contract.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From 9dba962fb94e0e02f7367911e81251f3efb2941f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:16 -0500
Subject: [PATCH 1823/3820] New translations subgraph-manifest.mdx (Dutch)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/nl/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/nl/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..a42a50973690
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Overview
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+The important entries to update for the manifest are:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Call Handlers
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Call handlers will only trigger in one of two cases: when the function specified is called by an account other than the contract itself or when it is marked as external in Solidity and called as part of another function in the same contract.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Defining a Call Handler
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Mapping Function
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Block Handlers
+
+In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a pre-defined filter.
+
+### Supported Filters
+
+#### Call Filter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+The absence of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Mapping Function
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Anonymous Events
+
+If you need to process anonymous events in Solidity, that can be achieved by providing the topic 0 of the event, as in the example:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Transaction Receipts in Event Handlers
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+The triggers for a data source within a block are ordered using the following process:
+
+1. Event and call triggers are first ordered by transaction index within the block.
+2. Event and call triggers within the same transaction are ordered using a convention: event triggers first then call triggers, each type respecting the order they are defined in the manifest.
+3. Block triggers are run after event and call triggers, in the order they are defined in the manifest.
+
+These ordering rules are subject to change.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Data Source Templates
+
+A common pattern in EVM-compatible smart contracts is the use of registry or factory contracts, where one contract creates, manages, or references an arbitrary number of other contracts that each have their own state and events.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Data Source for the Main Contract
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Data Source Templates for Dynamically Created Contracts
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Instantiating a Data Source Template
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> If prior blocks contain data relevant to the new data source, it is best to index that data by reading the current state of the contract and creating entities representing that state at the time the new data source is created.
+
+### Data Source Context
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Start Blocks
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Search for the contract by entering its address in the search bar.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Load the transaction details page where you'll find the start block for that contract.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From ee6c02455a2015a25402c03f37cdad33b3af9b2f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:17 -0500
Subject: [PATCH 1824/3820] New translations subgraph-manifest.mdx (Polish)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/pl/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/pl/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..a42a50973690
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Overview
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+The important entries to update for the manifest are:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Call Handlers
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Call handlers will only trigger in one of two cases: when the function specified is called by an account other than the contract itself or when it is marked as external in Solidity and called as part of another function in the same contract.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Defining a Call Handler
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Mapping Function
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Block Handlers
+
+In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a pre-defined filter.
+
+### Supported Filters
+
+#### Call Filter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+The absence of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Mapping Function
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Anonymous Events
+
+If you need to process anonymous events in Solidity, that can be achieved by providing the topic 0 of the event, as in the example:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Transaction Receipts in Event Handlers
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+The triggers for a data source within a block are ordered using the following process:
+
+1. Event and call triggers are first ordered by transaction index within the block.
+2. Event and call triggers within the same transaction are ordered using a convention: event triggers first then call triggers, each type respecting the order they are defined in the manifest.
+3. Block triggers are run after event and call triggers, in the order they are defined in the manifest.
+
+These ordering rules are subject to change.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Data Source Templates
+
+A common pattern in EVM-compatible smart contracts is the use of registry or factory contracts, where one contract creates, manages, or references an arbitrary number of other contracts that each have their own state and events.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Data Source for the Main Contract
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Data Source Templates for Dynamically Created Contracts
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Instantiating a Data Source Template
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> If prior blocks contain data relevant to the new data source, it is best to index that data by reading the current state of the contract and creating entities representing that state at the time the new data source is created.
+
+### Data Source Context
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Start Blocks
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Search for the contract by entering its address in the search bar.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Load the transaction details page where you'll find the start block for that contract.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From c5b702c6dcf71dbb0a28191fa85b0c4e6849f876 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:18 -0500
Subject: [PATCH 1825/3820] New translations subgraph-manifest.mdx (Portuguese)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/pt/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/pt/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..2a4c3af44fe4
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Visão geral
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+As entradas importantes para atualizar para o manifest são:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Handlers de Eventos
+
+Handlers de eventos em um subgraph reagem a eventos específicos emitidos por contratos inteligentes na blockchain e acionam handlers definidos no manifest do subgraph. Isto permite que subgraphs processem e armazenem dados conforme a lógica definida.
+
+### Como Definir um Handler de Evento
+
+Um handler de evento é declarado dentro de uma fonte de dados na configuração YAML do subgraph. Ele especifica quais eventos devem ser escutados e a função correspondente a ser executada quando estes eventos forem detetados.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Filtro de tópico opcional que só filtra eventos com o tópico especificado.
+```
+
+## Handlers de chamada
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Handlers de chamadas só serão ativados em um de dois casos: quando a função especificada é chamada por uma conta que não for do próprio contrato, ou quando ela é marcada como externa no Solidity e chamada como parte de outra função no mesmo contrato.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Como Definir um Handler de Chamada
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Função de Mapeamento
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Handlers de Blocos
+
+Além de se inscrever a eventos de contratos ou chamadas para funções, um subgraph também pode querer atualizar os seus dados enquanto novos blocos são afixados à chain. Para isto, um subgraph pode executar uma função após cada bloco, ou após blocos que correspondem a um filtro predefinido.
+
+### Filtros Apoiados
+
+#### Filtro Call
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+A ausência de um filtro para um handler de blocos garantirá que o handler seja chamado a todos os blocos. Uma fonte de dados só pode conter um handler de bloco para cada tipo de filtro.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Filtro Polling
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Filtro Once
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+O handler definido com o filtro once só será chamado uma única vez antes da execução de todos os outros handlers (por isto, o nome "once" / "uma vez"). Esta configuração permite que o subgraph use o handler como um handler de inicialização, para realizar tarefas específicas no começo da indexação.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Função de Mapeamento
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Eventos Anónimos
+
+Caso precise processar eventos anónimos no Solidity, isto é possível ao fornecer o topic 0 do evento, como no seguinte exemplo:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Recibos de Transação em Handlers de Eventos
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Ordem de Handlers de Gatilhos
+
+Os gatilhos para uma fonte de dados dentro de um bloco são ordenados com o seguinte processo:
+
+1. Gatilhos de evento e chamada são, primeiro, ordenados por índice de transação no bloco.
+2. Gatilhos de evento e chamada dentro da mesma transação são ordenados a usar uma convenção: primeiro, gatilhos de evento, e depois, de chamada, cada tipo a respeitar a ordem em que são definidos no manifest.
+3. Gatilhos de blocos são executados após gatilhos de evento e chamada, na ordem em que são definidos no manifest.
+
+Estas regras de organização estão sujeitas à mudança.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Modelos de Fontes de Dados
+
+Um padrão comum em contratos inteligentes compatíveis com EVMs é o uso de contratos de registro ou fábrica. Nisto, um contrato cria, gesta ou refere a um número arbitrário de outros contratos, cada um com o seu próprio estado e eventos.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Fonte de Dados para o Contrato Principal
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Modelos de Fontes de Dados para Contratos Criados Dinamicamente
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... outros campos de fonte para o contrato principal ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Como Instanciar um Modelo de Fontes de Dados
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Comece a indexar a troca; `event.params.exchange` é o
+  // endereço do novo contrato de troca
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> Se blocos anteriores conterem dados relevantes à nova fonte, é melhor indexá-los ao ler o estado atual do contrato e criar entidades que representem aquele estado na hora que a nova fonte de dados for criada.
+
+### Contextos de Fontes de Dados
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Blocos Iniciais
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Procure pelo contrato ao inserir o seu endereço na barra de busca.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Carregue a página dos detalhes da transação, onde encontrará o bloco inicial para aquele contrato.
+
+## IndexerHints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. Um número específico: Determina um limite personalizado no número de blocos históricos a guardar.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> O termo "histórico", neste contexto de subgraphs, refere-se ao armazenamento de dados que refletem os estados antigos de entidades mutáveis.
+
+O histórico, desde um bloco especificado, é necessário para:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rebobinar o subgraph de volta àquele bloco
+
+Se os dados históricos desde aquele bloco tiverem passado por pruning, as capacidades acima não estarão disponíveis.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+Para reter uma quantidade específica de dados históricos:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+Para preservar o histórico completo dos estados da entidade:
+
+```
+indexerHints:
+  prune: never
+```

From f01770457645dce50f6a2a3f27cf24fe149fdb22 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:19 -0500
Subject: [PATCH 1826/3820] New translations subgraph-manifest.mdx (Russian)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/ru/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/ru/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..a8f1a728f47a
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Обзор
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+Один субграф может:
+
+- Индексировать данные из нескольких смарт-контрактов (но не из нескольких сетей).
+
+- Индексировать данные из файлов IPFS с помощью источников файловых данных.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+Важными элементами манифеста, которые необходимо обновить, являются:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Обработчики событий
+
+Обработчики событий в субграфе реагируют на конкретные события, генерируемые смарт-контрактами в блокчейне, и запускают обработчики, определенные в манифесте подграфа. Это позволяет субграфам обрабатывать и хранить данные о событиях в соответствии с определенной логикой.
+
+### Определение обработчика событий
+
+Обработчик событий объявлен внутри источника данных в конфигурации YAML субграфа. Он определяет, какие события следует прослушивать, и соответствующую функцию, которую необходимо выполнить при обнаружении этих событий.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Обработчики вызовов
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Обработчики вызовов срабатывают только в одном из двух случаев: когда указанная функция вызывается учетной записью, отличной от самого контракта, или когда она помечена как внешняя в Solidity и вызывается как часть другой функции в том же контракте.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Определение обработчика вызова
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Функция мэппинга
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Обработчики блоков
+
+В дополнение к подписке на события контракта или вызовы функций, субграф может захотеть обновить свои данные по мере добавления в цепочку новых блоков. Чтобы добиться этого, субграф может запускать функцию после каждого блока или после блоков, соответствующих заранее определенному фильтру.
+
+### Поддерживаемые фильтры
+
+#### Фильтр вызовов
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+Отсутствие фильтра для обработчика блоков гарантирует, что обработчик вызывается для каждого блока. Источник данных может содержать только один обработчик блоков для каждого типа фильтра.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Фильтр опроса
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Однократный фильтр
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+Определенный обработчик с однократным фильтром будет вызываться только один раз перед запуском всех остальных обработчиков. Эта конфигурация позволяет субграфу использовать обработчик в качестве обработчика инициализации, выполняя определенные задачи в начале индексирования.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Функция мэппинга
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Анонимные события
+
+Если Вам нужно обрабатывать анонимные события в Solidity, это можно сделать, указав тему события 0, как показано в примере:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Подтверждения транзакций в обработчиках событий
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Порядок запуска обработчиков
+
+Триггеры для источника данных внутри блока упорядочиваются с помощью следующего процесса:
+
+1. Триггеры событий и вызовов сначала упорядочиваются по индексу транзакции внутри блока.
+2. Триггеры событий и вызовов в рамках одной транзакции упорядочиваются по следующему принципу: сначала триггеры событий, затем триггеры вызовов, причем для каждого типа соблюдается тот порядок, в котором они определены в манифесте.
+3. Триггеры блоков запускаются после триггеров событий и вызовов в том порядке, в котором они определены в манифесте.
+
+Эти правила оформления заказа могут быть изменены.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Шаблоны источников данных
+
+Распространенным шаблоном в смарт-контрактах, совместимых с EVM, является использование реестровых или заводских контрактов, когда один контракт создает, управляет или ссылается на произвольное количество других контрактов, каждый из которых имеет свое собственное состояние и события.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Источник данных для основного контракта
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Шаблоны источников данных для динамически создаваемых контрактов
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Создание шаблона источника данных
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> Если предыдущие блоки содержат данные, относящиеся к новому источнику данных, лучше всего проиндексировать эти данные, считывая текущее состояние контракта и создавая объекты, представляющие это состояние на момент создания нового источника данных.
+
+### Контекст источника данных
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Стартовые блоки
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Найдите контракт, введя его адрес в строке поиска.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Загрузите страницу сведений о транзакции, где Вы найдете начальный блок для этого контракта.
+
+## Подсказки индексатору
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Сокращение
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. Конкретное число: устанавливает индивидуальный лимит на количество сохраняемых исторических блоков.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> Термин «история» в контексте субграфов означает хранение данных, отражающих старые состояния изменяемых объектов.
+
+История данного блока необходима для:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Отката субграфа обратно к этому блоку
+
+Если исторические данные на момент создания блока были удалены, вышеупомянутые возможности будут недоступны.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+Чтобы сохранить определенный объем исторических данных:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+Чтобы сохранить полную историю состояний объекта, выполните следующее:
+
+```
+indexerHints:
+  prune: never
+```

From 457ee1df17e0103beb4efa8b31e771d58b81b2dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:21 -0500
Subject: [PATCH 1827/3820] New translations subgraph-manifest.mdx (Swedish)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/sv/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/sv/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..4111e4def981
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Översikt
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+De viktiga posterna att uppdatera för manifestet är:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Anropsbehandlare
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Anropsbehandlare utlöses endast i ett av två fall: när den specificerade funktionen anropas av ett konto som inte är kontraktet självt eller när den är markerad som extern i Solidity och anropas som en del av en annan funktion i samma kontrakt.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Definiera en Anropsbehandlare
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: "0x731a10897d267e19b34503ad902d0a29173ba4b1"
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Kartläggningsfunktion
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from "../generated/Gravity/Gravity";
+import { Transaction } from "../generated/schema";
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash;
+  let transaction = new Transaction(id);
+  transaction.displayName = call.inputs._displayName;
+  transaction.imageUrl = call.inputs._imageUrl;
+  transaction.save();
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Blockbehandlare
+
+Förutom att prenumerera på kontrakts händelser eller funktionsanrop kan en subgraf vilja uppdatera sina data när nya block läggs till i kedjan. För att uppnå detta kan en subgraf köra en funktion efter varje block eller efter block som matchar en fördefinierad filter.
+
+### Stödda filter
+
+#### Anropsfilter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+Avsaknaden av ett filter för en blockhanterare kommer att säkerställa att hanteraren kallas för varje block. En datakälla kan endast innehålla en blockhanterare för varje filttyp.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: "0x731a10897d267e19b34503ad902d0a29173ba4b1"
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Undersökningsfilter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### En Gång Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+Den definierade hanteraren med filtret once kommer att anropas endast en gång innan alla andra hanterare körs. Denna konfiguration gör det möjligt för subgrafen att använda hanteraren som en initialiseringshanterare, som utför specifika uppgifter i början av indexeringen.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8("initial"));
+  data.data = "Setup data here";
+  data.save();
+}
+```
+
+### Kartläggningsfunktion
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from "@graphprotocol/graph-ts";
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash;
+  let entity = new Block(id);
+  entity.save();
+}
+```
+
+## Anonyma händelser
+
+Om du behöver behandla anonyma händelser i Solidity kan du göra det genom att ange händelsens ämne 0, som i exemplet:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Transaktionskvitton i Händelsehanterare
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+Utlösarna för en datakälla inom ett block ordnas med hjälp av följande process:
+
+1. Händelse- och anropsutlösare ordnas först efter transaktionsindex inom blocket.
+2. Händelse- och anropsutlösare inom samma transaktion ordnas med hjälp av en konvention: händelseutlösare först, sedan anropsutlösare, varje typ respekterar ordningen de definieras i manifestet.
+3. Blockutlösare körs efter händelse- och anropsutlösare, i den ordning de definieras i manifestet.
+
+Dessa ordningsregler kan komma att ändras.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Datakällmallar
+
+En vanlig mönster i EVM-kompatibla smarta kontrakt är användningen av register- eller fabrikskontrakt, där ett kontrakt skapar, hanterar eller hänvisar till ett godtyckligt antal andra kontrakt som var och en har sin egen stat och händelser.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Datakälla för huvudkontraktet
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: "0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95"
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Datakällmallar för dynamiskt skapade kontrakt
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Instansiering av en mall för datakälla
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from "../generated/templates";
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange);
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> Om tidigare block innehåller data som är relevanta för den nya datakällan, är det bäst att indexera dessa data genom att läsa kontraktets aktuella status och skapa enheter som representerar denna status vid den tidpunkt då den nya datakällan skapas.
+
+### Kontext för datakälla
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from "../generated/templates";
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext();
+  context.setString("tradingPair", event.params.tradingPair);
+  Exchange.createWithContext(event.params.exchange, context);
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from "@graphprotocol/graph-ts";
+
+let context = dataSource.context();
+let tradingPair = context.getString("tradingPair")
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Startblock
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: "0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95"
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Sök efter kontraktet genom att ange dess adress i sökfältet.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Ladda sidan med transaktionsdetaljer där du hittar startblocket för det kontraktet.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From 2191033f1f6b5b5bb11265d12497b92080a5b64d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:22 -0500
Subject: [PATCH 1828/3820] New translations subgraph-manifest.mdx (Turkish)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/tr/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/tr/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..88693e796ef6
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Genel Bakış
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+Tek bir subgraph:
+
+- Birden fazla akıllı sözleşmeden veri endeksleyebilir (fakat birden fazla ağdan endeksleyemez).
+
+- IPFS dosyalarından Dosya Veri Kaynakları kullanarak veri endeksleyebilir.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+Manifest için güncellenmesi gereken önemli girdiler şunlardır:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Olay İşleyicileri
+
+Bir subgraph'in olay işleyicileri, blokzincir üzerindeki akıllı sözleşmeler tarafından yayılan belirli olaylara tepki verir, ve subgraph'in manifesto dosyasında tanımlanan işleyicileri tetikler. Bu, subgraph'lerin tanımlanmış mantığa göre olay verilerini işlemesini ve depolamasını sağlar.
+
+### Olay İşleyici Tanımlama
+
+Bir olay işleyici, subgraph'in YAML yapılandırmasında bir veri kaynağı içinde tanımlanır. Hangi olayların dinleneceğini ve bu olaylar algılandığında hangi fonksiyonun çalıştırılacağını belirtir.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Opsiyonel konu filtresi, sadece verilen konuyu içeren olayları filtreler.
+```
+
+## Çağrı İşleyicileri
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Çağrı işleyicileri yalnızca iki durumdan birinde tetiklenir: belirtilen işlevin sözleşme tarafından değil, başka bir hesap tarafından çağrılması durumunda veya Solidity'de harici olarak işaretlenip aynı sözleşmenin başka bir işlevinin bir parçası olarak çağrılması durumunda yalnızca tetiklenir.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Bir Çağrı İşleyici Tanımlama
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Eşleştirme fonksiyonu
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Blok İşleyicileri
+
+Bir subgraph, sözleşme olaylarına veya işlev çağrılarına abone olmanın yanı sıra, zincire yeni bloklar eklendikçe verilerini güncellemek isteyebilir. Bu işlemi gerçekleştirmek için a subgraph, her blok sonrasında veya önceden tanımlanmış bir filtreye uygun bloklardan sonra bir işlev çalıştırabilir.
+
+### Desteklenen Filtreler
+
+#### Çağrı Filtresi
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+Bir blok işleyicisi için filtre olmaması, işleyicinin her blok için çağrılacağı anlamına gelir. Bir veri kaynağı, her filtre türü için yalnızca bir blok işleyicisi içerebilir.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filtresi
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filtresi
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+Once filtresi ile tanımlanan işleyici, diğer tüm işleyiciler çalışmadan önce yalnızca bir kez çağrılacaktır. Bu yapılandırma, subgraph'ın işleyiciyi indekslemenin başlangıcında belirli görevleri yerine getirmesine olanak sağlayan bir başlatma işleyicisi olarak kullanmasına yarar.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Eşleştirme fonksiyonu
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Anonim Olaylar
+
+Solidity'de anonim olayları işlemek gerekiyorsa, örnekte olduğu gibi, olayın topic 0'ını sağlayarak bunu başarabilirsiniz:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Olay İşleyicilerinde İşlem Makbuzları
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## İşleyicilerin Tetiklenme Sırası
+
+Bir bloktaki veri kaynağı için tetikleyiciler şu işlemlerle sıralanır:
+
+1. Olay ve çağrı tetikleyicileri, öncelikle bloktaki işlem indeksine göre sıralanır.
+2. Aynı işlemdeki olay ve çağrı tetikleyicileri, bir kurala göre sıralanır: önce olay tetikleyicileri, ardından çağrı tetikleyicileri olmak üzere her tür manifest'te tanımlandıkları sıraya göre sıralanır.
+3. Blok tetikleyicileri, olay ve çağrı tetikleyicilerinden sonra manifest'te tanımlandıkları sırada göre çalıştırılır.
+
+Bu sıralama kuralları değişebilir.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Veri Kaynağı Şablonları
+
+EVM uyumlu akıllı sözleşmelerde yaygın bir model, kayıt (registry) veya fabrika (factory) sözleşmelerinin kullanılmasıdır. Böylece ana sözleşme, kendi durumuna ve olaylarına sahip istenilen sayıda diğer sözleşmeyi oluşturur, yönetir veya bunlara referans verir.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Ana Sözleşme için Veri Kaynağı
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Dinamik Olarak Oluşturulan Sözleşmeler için Veri Kaynağı Şablonları
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Bir Veri Kaynağı Şablonunun Örneklenmesi
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Borsayı indekslemeye başlayın; "event.params.exchange"
+  // yeni borsa sözleşmesinin adresi
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> Eğer önceki bloklar, yeni veri kaynağı için ilgili veri içeriyorsa, o veriyi indekslemek için sözleşmenin mevcut durumunu okuyarak ve yeni veri kaynağı oluşturulurken o zaman dilimindeki durumu temsil eden varlıklar oluşturarak yapmak en iyisidir.
+
+### Veri Kaynağı Bağlamı
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Başlangıç Blokları
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Arama çubuğuna adresini girerek sözleşmeyi arayın.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. İşlem detayları sayfasını yükleyin ve bu sözleşme için başlangıç bloğunu bulacaksınız.
+
+## Endeksleyici İpuçları
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Budama
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. Belirli bir sayı: Verilen sayıyı saklanacak tarihsel blok sayısı olarak ayarlar.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> Subgraph'lerde "geçmiş" terimi, bu bağlamda, değiştirilebilir varlıkların eski durumlarına dair verilerin saklanmasıyla ilgilidir.
+
+Verilen bir bloktaki geçmiş, şu durumlar için gereklidir:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Subgraph'i verilen bloka geri sarmak
+
+Eğer verilen bloktaki tarihsel veri budanmışsa yukarıdaki özellikler kullanılamayacaktır.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+Belirli bir miktarda tarihsel veri saklamak için:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+Varlık durumlarının tam geçmişini korumak için:
+
+```
+indexerHints:
+  prune: never
+```

From 2ce2c0c4080b4d9e878ce20d770072db4034b9bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:23 -0500
Subject: [PATCH 1829/3820] New translations subgraph-manifest.mdx (Ukrainian)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/uk/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/uk/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..a42a50973690
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Overview
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+The important entries to update for the manifest are:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Call Handlers
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Call handlers will only trigger in one of two cases: when the function specified is called by an account other than the contract itself or when it is marked as external in Solidity and called as part of another function in the same contract.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Defining a Call Handler
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Mapping Function
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Block Handlers
+
+In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a pre-defined filter.
+
+### Supported Filters
+
+#### Call Filter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+The absence of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Mapping Function
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Anonymous Events
+
+If you need to process anonymous events in Solidity, that can be achieved by providing the topic 0 of the event, as in the example:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Transaction Receipts in Event Handlers
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+The triggers for a data source within a block are ordered using the following process:
+
+1. Event and call triggers are first ordered by transaction index within the block.
+2. Event and call triggers within the same transaction are ordered using a convention: event triggers first then call triggers, each type respecting the order they are defined in the manifest.
+3. Block triggers are run after event and call triggers, in the order they are defined in the manifest.
+
+These ordering rules are subject to change.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Data Source Templates
+
+A common pattern in EVM-compatible smart contracts is the use of registry or factory contracts, where one contract creates, manages, or references an arbitrary number of other contracts that each have their own state and events.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Data Source for the Main Contract
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Data Source Templates for Dynamically Created Contracts
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Instantiating a Data Source Template
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> If prior blocks contain data relevant to the new data source, it is best to index that data by reading the current state of the contract and creating entities representing that state at the time the new data source is created.
+
+### Data Source Context
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Start Blocks
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Search for the contract by entering its address in the search bar.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Load the transaction details page where you'll find the start block for that contract.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From f12aeabaf09900111f1a071282c162d219a22369 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:24 -0500
Subject: [PATCH 1830/3820] New translations subgraph-manifest.mdx (Chinese
 Simplified)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/zh/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/zh/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..486f06a4c248
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## 概述
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+清单中要更新的重要条目是：
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## 调用处理程序
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+调用处理程序只会在以下两种情况之一触发：当指定的函数被合约本身以外的账户调用时，或者当它在 Solidity 中被标记为外部，并作为同一合约中另一个函数的一部分被调用时。
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### 定义调用处理程序
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### 映射函数
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## 区块处理程序
+
+除了订阅合约事件或函数调用之外，子图可能还希望在将新区块附加到链上时更新其数据。 为了实现这一点，子图可以在每个区块之后，或匹配预定义过滤器的区块之后，运行一个函数。
+
+### 支持的过滤器
+
+#### 调用筛选器
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+块处理程序没有过滤器将确保每个块都调用处理程序。对于每种过滤器类型，一个数据源只能包含一个块处理程序。
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### 投票筛选器
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### 一次性筛选器
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+带有 "once filter" 的所定义处理程序将在所有其他处理程序运行之前仅被调用一次。这种配置允许子图将该处理程序用作初始化处理程序，在索引开始时执行特定任务。
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### 映射函数
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## 匿名事件
+
+如果您需要在 Solidity 中处理匿名事件，可以通过提供事件的主题 0 来实现，如示例所示：
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## 事件处理程序中的交易接收
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+区块内数据源的触发器使用以下流程进行排序：
+
+1. 事件和调用触发器首先按区块内的交易索引排序。
+2. 同一交易中的事件和调用触发器使用约定进行排序：首先是事件触发器，然后是调用触发器，每种类型都遵循它们在清单中定义的顺序。
+3. 区块触发器按照它们在清单中定义的顺序，在事件和调用触发器之后运行。
+
+这些排序规则可能会发生变化。
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## 数据源模板
+
+EVM兼容智能合约中的一种常见模式是使用注册表或工厂合约，其中一个合约创建、管理或引用任意数量的其他合约，每个合约都有自己的状态和事件。
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### 主合约的数据源
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### 动态创建合约的数据源模板
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### 实例化数据源模板
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> 如果先前的区块包含与新数据源相关的数据，最好通过读取合约的当前状态，并在创建新数据源时创建表示该状态的实体来索引该数据。
+
+### 数据源背景
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## 起始区块
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. 通过在搜索栏中输入合约地址来搜索合约。
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. 加载交易详情页面，您将在其中找到该合约的起始区块。
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From 03681d2d8f5b14b1edb581b353c6eab7b91745e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:25 -0500
Subject: [PATCH 1831/3820] New translations subgraph-manifest.mdx (Urdu
 (Pakistan))

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/ur/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/ur/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..de8a303b302d
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## جائزہ
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+مینی فیسٹ کے لیے اپ ڈیٹ کرنے کے لیے اہم اندراجات یہ ہیں:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## کال ہینڈلرز
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+کال ہینڈلرز صرف دو صورتوں میں سے ایک میں ٹرگر کریں گے: جب مخصوص کردہ فنکشن کو کنٹریکٹ کے علاوہ کسی دوسرے اکاؤنٹ سے کال جاتا ہے یا جب اسے سولیڈیٹی میں بیرونی کے طور پر نشان زد کیا جاتا ہے اور اسی کنٹریکٹ میں کسی دوسرے فنکشن کے حصے کے طور پر کال کیا جاتا ہے.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### کال ہینڈلر کی تعریف
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### میپنگ فنکشن
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## بلاک ہینڈلرز
+
+کنٹریکٹ ایونٹس یا فنکشن کالز کو سبسکرائب کرنے کے علاوہ، ایک سب گراف اپنے ڈیٹا کو اپ ڈیٹ کرنا چاہتا ہے جیسے جیسے چین میں نئے بلاکس شامل ہوتے ہیں. اس کو حاصل کرنے کے لیے ایک سب گراف ہر بلاک کے بعد یا پہلے سے طے شدہ فلٹر سے مماثل بلاکس کے بعد ایک فنکشن چلا سکتا ہے.
+
+### معاون فلٹرز
+
+#### کال فلٹر
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+بلاک ہینڈلر کے لیے فلٹر کی عدم موجودگی اس بات کو یقینی بنائے گی کہ ہینڈلر کو ہر بلاک کے لیے کال کیا جاتا ہے. ڈیٹا سورس میں ہر فلٹر کی قسم کے لیے صرف ایک بلاک ہینڈلر ہو سکتا ہے.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### پولنگ فلٹر
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### ونس فلٹر
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+ایک بار فلٹر کے ساتھ متعین ہینڈلر کو دوسرے تمام ہینڈلرز کے چلنے سے پہلے صرف ایک بار کال کیا جائے گا۔ یہ کنفیگریشن سب گراف کو انڈیکسنگ کے آغاز میں مخصوص کاموں کو انجام دیتے ہوئے، ہینڈلر کو ابتدائیہ ہینڈلر کے طور پر استعمال کرنے کی اجازت دیتی ہے.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### میپنگ فنکشن
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## گمنام ایونٹس
+
+اگر آپ کو سولیڈیٹی میں گمنام ایوینٹس پر کارروائی کرنے کی ضرورت ہے، تو یہ ایونٹ کا عنوان 0 فراہم کرکے حاصل کیا جاسکتا ہے، جیسا کہ مثال میں:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## ایونٹ ہینڈلرز میں ٹرانزیکشن کی رسیدیں
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+بلاک کے اندر ڈیٹا سورس کے لیے محرکات درج ذیل عمل کا استعمال کرتے ہوئے ترتیب دیے گئے ہیں:
+
+1. ایونٹ اور کال ٹریگرز کو پہلے بلاک کے اندر ٹرانزیکشن انڈیکس سے ترتیب دیا جاتا ہے.
+2. ایک ہی ٹرانزیکشن کے اندر ایونٹ اور کال ٹرگرز کو روایت کا استعمال کرتے ہوئے ترتیب دیا جاتا ہے: پہلے ایونٹ ٹرگرز پھر کال ٹرگرز، ہر قسم اس ترتیب کا احترام کرتی ہے جس کی وضاحت مینی فیسٹ میں کی گئی ہے.
+3. بلاک ٹریگرز ایونٹ اور کال ٹریگرز کے بعد چلائے جاتے ہیں، اس ترتیب میں جس کی وضاحت مینی فیسٹ میں کی گئی ہے.
+
+ترتیب دینے کے یہ اصول تبدیل کیے جا سکتے ہیں.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## ڈیٹا سورس ٹیمپلیٹس
+
+EVM سے مطابقت رکھنے والے سمارٹ کنٹریکٹس میں ایک عام نمونہ رجسٹری یا فیکٹری کنٹریکٹس کا استعمال ہے، جہاں ایک کنٹریکٹ دوسرے کنٹریکٹس کی صوابدیدی تعداد کو تخلیق کرتا ہے، ان کا انتظام کرتا ہے یا حوالہ دیتا ہے جن میں سے ہر ایک کی اپنی ریاست اور واقعات ہوتے ہیں.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### مرکزی کنٹریکٹ کے لیے ڈیٹا سورس
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### متحرک طور پر بنائے گئے کنٹریکٹس کے لیے ڈیٹا سورس ٹیمپلیٹس
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### ڈیٹا سورس ٹیمپلیٹ کو شروع کرنا
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> اگر پہلے والے بلاکس میں نئے ڈیٹا سورس سے متعلقہ ڈیٹا ہوتا ہے، تو یہ بہترین ہے کہ کنٹریکٹ کی موجودہ حالت کو پڑھ کر اور ڈیٹا کا نیا سورس بننے کے وقت اس سٹیٹ کی نمائندگی کرنے والی اینٹیٹیز بنا کر اس ڈیٹا کو انڈیکس کریں.
+
+### ڈیٹا سورس سیاق و سباق
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## بلاکس شروع کریں
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. سرچ بار میں اس کا ایڈریس درج کرکے کنٹریکٹ کو تلاش کریں.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. ٹرانزیکشن کی تفصیلات کا صفحہ لوڈ کریں جہاں آپ کو اس کنٹریکٹ کے لیے اسٹارٹ بلاک ملے گا.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From e9a16c2011c82b1daea77dfcb5a2f8739d0959e7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:26 -0500
Subject: [PATCH 1832/3820] New translations subgraph-manifest.mdx (Vietnamese)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/vi/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/vi/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..01ca69dbcd4b
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Tổng quan
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+Các mục nhập quan trọng cần cập nhật cho tệp kê khai là:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Trình xử lý lệnh gọi
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Call handlers will only trigger in one of two cases: when the function specified is called by an account other than the contract itself or when it is marked as external in Solidity and called as part of another function in the same contract.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Xác định một Trình xử lý lệnh gọi
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Chức năng Ánh xạ
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Trình xử lý Khối
+
+In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a pre-defined filter.
+
+### Bộ lọc được hỗ trợ
+
+#### Call Filter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+The absence of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Chức năng Ánh xạ
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Sự kiện Ẩn danh
+
+If you need to process anonymous events in Solidity, that can be achieved by providing the topic 0 of the event, as in the example:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Transaction Receipts in Event Handlers
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+Các trình kích hoạt cho nguồn dữ liệu trong một khối được sắp xếp theo quy trình sau:
+
+1. Trình kích hoạt sự kiện và cuộc gọi được sắp xếp đầu tiên theo chỉ mục giao dịch trong khối.
+2. Event and call triggers within the same transaction are ordered using a convention: event triggers first then call triggers, each type respecting the order they are defined in the manifest.
+3. Trình kích hoạt chặn được chạy sau trình kích hoạt sự kiện và cuộc gọi, theo thứ tự chúng được xác định trong tệp kê khai.
+
+These ordering rules are subject to change.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Mẫu Nguồn Dữ liệu
+
+A common pattern in EVM-compatible smart contracts is the use of registry or factory contracts, where one contract creates, manages, or references an arbitrary number of other contracts that each have their own state and events.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Nguồn Dữ liệu cho Hợp đồng Chính
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Mẫu Nguồn Dữ liệu cho các Hợp đồng được Tạo Tự động
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Khởi tạo một Mẫu Nguồn Dữ liệu
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> Nếu các khối trước đó chứa dữ liệu có liên quan đến nguồn dữ liệu mới, tốt nhất là lập chỉ mục dữ liệu đó bằng cách đọc trạng thái hiện tại của hợp đồng và tạo các thực thể đại diện cho trạng thái đó tại thời điểm nguồn dữ liệu mới được tạo.
+
+### Bối cảnh Nguồn Dữ liệu
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Khối Bắt đầu
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Tìm kiếm hợp đồng bằng cách nhập địa chỉ của nó vào thanh tìm kiếm.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Tải trang chi tiết giao dịch nơi bạn sẽ tìm thấy khối bắt đầu cho hợp đồng đó.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From 0a09bf58b99e2ac13957877e617fb119cb21f61a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:27 -0500
Subject: [PATCH 1833/3820] New translations subgraph-manifest.mdx (Marathi)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/mr/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/mr/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..a09668000af7
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## सविश्लेषण
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+मॅनिफेस्टसाठी अद्यतनित करण्याच्या महत्त्वाच्या नोंदी आहेत:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## हँडलर्सना कॉल करा
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+कॉल हँडलर्स फक्त दोनपैकी एका प्रकरणात ट्रिगर होतील: जेव्हा निर्दिष्ट केलेल्या फंक्शनला कॉन्ट्रॅक्ट व्यतिरिक्त इतर खात्याद्वारे कॉल केले जाते किंवा जेव्हा ते सॉलिडिटीमध्ये बाह्य म्हणून चिन्हांकित केले जाते आणि त्याच कॉन्ट्रॅक्टमधील दुसर्‍या फंक्शनचा भाग म्हणून कॉल केले जाते.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### कॉल हँडलरची व्याख्या
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### मॅपिंग कार्य
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## ब्लॉक हँडलर
+
+कॉन्ट्रॅक्ट इव्हेंट्स किंवा फंक्शन कॉल्सची सदस्यता घेण्याव्यतिरिक्त, सबग्राफला त्याचा डेटा अद्यतनित करायचा असेल कारण साखळीमध्ये नवीन ब्लॉक्स जोडले जातात. हे साध्य करण्यासाठी सबग्राफ प्रत्येक ब्लॉकनंतर किंवा पूर्व-परिभाषित फिल्टरशी जुळणार्‍या ब्लॉक्सनंतर फंक्शन चालवू शकतो.
+
+### समर्थित फिल्टर
+
+#### Call Filter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+ब्लॉक हँडलरसाठी फिल्टरची अनुपस्थिती हे सुनिश्चित करेल की हँडलरला प्रत्येक ब्लॉक म्हटले जाईल. डेटा स्त्रोतामध्ये प्रत्येक फिल्टर प्रकारासाठी फक्त एक ब्लॉक हँडलर असू शकतो.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### मॅपिंग कार्य
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## अनामिक घटना
+
+तुम्हाला सॉलिडिटीमध्ये निनावी इव्हेंटवर प्रक्रिया करायची असल्यास, ते इव्हेंटचा विषय 0 प्रदान करून प्राप्त केले जाऊ शकते, उदाहरणार्थ:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Transaction Receipts in Event Handlers
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+The triggers for a data source within a block are ordered using the following process:
+
+1. Event and call triggers are first ordered by transaction index within the block.
+2. समान व्यवहारामधील इव्हेंट आणि कॉल ट्रिगर्स एक नियम वापरून ऑर्डर केले जातात: प्रथम इव्हेंट ट्रिगर नंतर कॉल ट्रिगर, प्रत्येक प्रकार मॅनिफेस्टमध्ये परिभाषित केलेल्या क्रमाचा आदर करतो.
+3. Block triggers are run after event and call triggers, in the order they are defined in the manifest.
+
+These ordering rules are subject to change.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## डेटा स्रोत टेम्पलेट्स
+
+EVM-सुसंगत स्मार्ट कॉन्ट्रॅक्ट्समधील एक सामान्य नमुना म्हणजे नोंदणी किंवा फॅक्टरी कॉन्ट्रॅक्टचा वापर, जिथे एक करार तयार करतो, व्यवस्थापित करतो किंवा इतर करारांची अनियंत्रित संख्या संदर्भित करतो ज्या प्रत्येकाची स्वतःची स्थिती आणि घटना असतात.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### मुख्य करारासाठी डेटा स्रोत
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Data Source Templates for Dynamically Created Contracts
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### डेटा स्रोत टेम्पलेट इन्स्टंट करणे
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> पूर्वीच्या ब्लॉक्समध्ये नवीन डेटा स्रोताशी संबंधित डेटा असल्यास, कराराची वर्तमान स्थिती वाचून आणि नवीन डेटा स्रोत तयार करताना त्या स्थितीचे प्रतिनिधित्व करणारी संस्था तयार करून तो डेटा अनुक्रमित करणे सर्वोत्तम आहे.
+
+### डेटा स्रोत संदर्भ
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## ब्लॉक सुरू करा
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Search for the contract by entering its address in the search bar.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Load the transaction details page where you'll find the start block for that contract.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From 559f848266608537f6bf1753332016e76235f414 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:29 -0500
Subject: [PATCH 1834/3820] New translations subgraph-manifest.mdx (Hindi)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/hi/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/hi/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..9315b0d0b218
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## अवलोकन
+
+subgraph मैनिफेस्ट, subgraph.yaml, उन स्मार्ट कॉन्ट्रैक्ट्स और नेटवर्क को परिभाषित करता है जिन्हें आपका subgraph इंडेक्स करेगा, इन कॉन्ट्रैक्ट्स से ध्यान देने योग्य इवेंट्स, और इवेंट डेटा को उन संस्थाओं के साथ मैप करने का तरीका जिन्हें Graph Node स्टोर करता है और जिन्हें क्वेरी करने की अनुमति देता है।
+
+**subgraph definition** में निम्नलिखित फ़ाइलें शामिल हैं:
+
+- subgraph.yaml: में subgraph मैनिफेस्ट शामिल है
+
+- schema.graphql: एक GraphQL स्कीमा जो आपके लिए डेटा को परिभाषित करता है और इसे GraphQL के माध्यम से क्वेरी करने का तरीका बताता है.
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph क्षमताएँ
+
+एक सिंगल subgraph कर सकता है:
+
+- कई स्मार्ट कॉन्ट्रैक्ट्स से डेटा को इंडेक्स करें (लेकिन कई नेटवर्क नहीं)।
+
+- IPFS फ़ाइलों से डेटा को डेटा स्रोत फ़ाइलें  का उपयोग करके अनुक्रमित करें।
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+मेनिफेस्ट के लिए अद्यतन करने के लिए महत्वपूर्ण प्रविष्टियां हैं:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## आयोजन Handlers
+
+Event handlers एक subgraph में स्मार्ट कॉन्ट्रैक्ट्स द्वारा ब्लॉकचेन पर उत्पन्न होने वाले विशिष्ट घटनाओं पर प्रतिक्रिया करते हैं और subgraph के मैनिफेस्ट में परिभाषित हैंडलर्स को ट्रिगर करते हैं। इससे subgraphs को परिभाषित लॉजिक के अनुसार घटना डेटा को प्रोसेस और स्टोर करने की अनुमति मिलती है।
+
+### इवेंट हैंडलर को परिभाषित करना
+
+एक event handler को डेटा स्रोत के भीतर subgraph के YAML configuration में घोषित किया जाता है। यह निर्दिष्ट करता है कि कौन से events पर ध्यान देना है और उन events का पता चलने पर कार्यान्वित करने के लिए संबंधित function क्या है।
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## कॉल हैंडलर्स
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+कॉल हैंडलर केवल दो मामलों में से एक में ट्रिगर होंगे: जब निर्दिष्ट फ़ंक्शन को अनुबंध के अलावा किसी अन्य खाते द्वारा कॉल किया जाता है या जब इसे सॉलिडिटी में बाहरी के रूप में चिह्नित किया जाता है और उसी अनुबंध में किसी अन्य फ़ंक्शन के भाग के रूप में कॉल किया जाता है।
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### कॉल हैंडलर को परिभाषित करना
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### मानचित्रण समारोह
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## ब्लॉक हैंडलर
+
+Contract events या function calls की सदस्यता लेने के अलावा, एक subgraph अपने data को update करना चाह सकता है क्योंकि chain में नए blocks जोड़े जाते हैं। इसे प्राप्त करने के लिए एक subgraph every block के बाद या pre-defined filter से match होन वाले block के बाद एक function चला सकता है।
+
+### समर्थित फ़िल्टर
+
+#### कॉल फ़िल्टर
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+ब्लॉक हैंडलर के लिए फ़िल्टर की अनुपस्थिति सुनिश्चित करेगी कि हैंडलर को प्रत्येक ब्लॉक कहा जाता है। डेटा स्रोत में प्रत्येक फ़िल्टर प्रकार के लिए केवल एक ब्लॉक हैंडलर हो सकता है।
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### मतदान फ़िल्टर
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once फ़िल्टर
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+'once' फ़िल्टर के साथ परिभाषित हैंडलर केवल एक बार सभी अन्य हैंडलर्स चलने से पहले कॉल किया जाएगा। यह कॉन्फ़िगरेशन 'subgraph' को प्रारंभिक हैंडलर के रूप में उपयोग करने की अनुमति देता है, जिससे 'indexing' के शुरू होने पर विशिष्ट कार्य किए जा सकते हैं।
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### मानचित्रण समारोह
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## अनाम घटनाएँ
+
+यदि आपको अनाम घटनाओं को सॉलिडिटी में संसाधित करने की आवश्यकता है, तो इसे घटना के विषय 0 प्रदान करके प्राप्त किया जा सकता है, जैसा कि उदाहरण में है:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## इवेंट हैंडलर में लेनदेन रसीदें
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## ट्रिगरिंग हैंडलर्स का क्रम
+
+निम्नलिखित प्रक्रिया का उपयोग करके एक ब्लॉक के भीतर डेटा स्रोत के लिए ट्रिगर्स का आदेश दिया गया है:
+
+1. ईवेंट और कॉल ट्रिगर्स को पहले ब्लॉक के भीतर ट्रांजैक्शन इंडेक्स द्वारा ऑर्डर किया जाता है।
+2. एक ही लेन-देन के भीतर ईवेंट और कॉल ट्रिगर्स को एक कन्वेंशन का उपयोग करके ऑर्डर किया जाता है: ईवेंट पहले ट्रिगर करता है फिर ट्रिगर्स को कॉल करता है, प्रत्येक प्रकार के ऑर्डर का सम्मान करते हुए उन्हें मेनिफेस्ट में परिभाषित किया जाता है।
+3. ब्लॉक ट्रिगर इवेंट और कॉल ट्रिगर के बाद चलाए जाते हैं, जिस क्रम में उन्हें मेनिफेस्ट में परिभाषित किया गया है।
+
+ये आदेश नियम परिवर्तन के अधीन हैं।
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## डेटा स्रोत टेम्पलेट्स
+
+ईवीएम-संगत स्मार्ट अनुबंधों में एक सामान्य पैटर्न रजिस्ट्री या फ़ैक्टरी अनुबंधों का उपयोग होता है, जहां एक अनुबंध अन्य अनुबंधों की मनमानी संख्या का निर्माण, प्रबंधन या संदर्भ करता है, जिनमें से प्रत्येक का अपना राज्य और ईवेंट होता है।
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### मुख्य अनुबंध के लिए डेटा स्रोत
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### गतिशील रूप से बनाए गए अनुबंधों के लिए डेटा स्रोत टेम्प्लेट
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### डेटा स्रोत टेम्प्लेट को इंस्टेंट करना
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> यदि पिछले ब्लॉक में नए डेटा स्रोत के लिए प्रासंगिक डेटा है, तो उस डेटा को अनुबंध की वर्तमान स्थिति को पढ़कर और नए डेटा स्रोत के निर्माण के समय उस स्थिति का प्रतिनिधित्व करने वाली संस्थाओं का निर्माण करना सबसे अच्छा है।
+
+### डेटा स्रोत प्रसंग
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Start Blocks
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. खोज बार में उसका पता दर्ज करके अनुबंध की खोज करें।
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. लेन-देन विवरण पृष्ठ लोड करें जहां आपको उस अनुबंध के लिए प्रारंभ ब्लॉक मिलेगा।
+
+## Indexer संकेत
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. एक विशेष संख्या: ऐतिहासिक ब्लॉकों की एक कस्टम सीमा निर्धारित करता है जिन्हें बनाए रखा जाना है।
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> इस संदर्भ में "history" का अर्थ उन आंकड़ों को संग्रहीत करने से है जो 'mutable' संस्थाओं की पुरानी स्थितियों को दर्शाते हैं।
+
+दिए गए ब्लॉक के रूप में इतिहास की आवश्यकता है:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- उस ब्लॉक पर 'subgraph' को वापस लाना
+
+यदि ब्लॉक के रूप में ऐतिहासिक डेटा को प्रून किया गया है, तो उपरोक्त क्षमताएँ उपलब्ध नहीं होंगी।
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+विशिष्ट मात्रा में ऐतिहासिक डेटा बनाए रखने के लिए:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+पूरे 'entity' राज्यों का इतिहास बनाए रखने के लिए:
+
+```
+indexerHints:
+  prune: never
+```

From b0e42b9107971518923b6445d4724031e4c4e56f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:30 -0500
Subject: [PATCH 1835/3820] New translations subgraph-manifest.mdx (Swahili)

---
 .../developing/creating/subgraph-manifest.mdx | 534 ++++++++++++++++++
 1 file changed, 534 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/creating/subgraph-manifest.mdx

diff --git a/website/pages/sw/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/sw/subgraphs/developing/creating/subgraph-manifest.mdx
new file mode 100644
index 000000000000..a42a50973690
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -0,0 +1,534 @@
+---
+title: Subgraph Manifest
+---
+
+## Overview
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+
+### Subgraph Capabilities
+
+A single subgraph can:
+
+- Index data from multiple smart contracts (but not multiple networks).
+
+- Index data from IPFS files using File Data Sources.
+
+- Add an entry for each contract that requires indexing to the `dataSources` array.
+
+The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+
+For the example subgraph listed above, `subgraph.yaml` is:
+
+```yaml
+specVersion: 0.0.4
+description: Gravatar for Ethereum
+repository: https://github.com/graphprotocol/graph-tooling
+schema:
+  file: ./schema.graphql
+indexerHints:
+  prune: auto
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      abi: Gravity
+      startBlock: 6175244
+      endBlock: 7175245
+    context:
+      foo:
+        type: Bool
+        data: true
+      bar:
+        type: String
+        data: 'bar'
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: NewGravatar(uint256,address,string,string)
+          handler: handleNewGravatar
+        - event: UpdatedGravatar(uint256,address,string,string)
+          handler: handleUpdatedGravatar
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCall
+          filter:
+            kind: call
+      file: ./src/mapping.ts
+```
+
+## Subgraph Entries
+
+> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+
+The important entries to update for the manifest are:
+
+- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+
+- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+
+- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+
+- `features`: a list of all used [feature](#experimental-features) names.
+
+- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+
+- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+
+- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+
+- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+
+- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+
+- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+
+- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+
+- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+
+- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+
+- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+
+A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+
+## Event Handlers
+
+Event handlers in a subgraph react to specific events emitted by smart contracts on the blockchain and trigger handlers defined in the subgraph's manifest. This enables subgraphs to process and store event data according to defined logic.
+
+### Defining an Event Handler
+
+An event handler is declared within a data source in the subgraph's YAML configuration. It specifies which events to listen for and the corresponding function to execute when those events are detected.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      eventHandlers:
+        - event: Approval(address,address,uint256)
+          handler: handleApproval
+        - event: Transfer(address,address,uint256)
+          handler: handleTransfer
+          topic1: ['0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045', '0xc8dA6BF26964aF9D7eEd9e03E53415D37aA96325'] # Optional topic filter which filters only events with the specified topic.
+```
+
+## Call Handlers
+
+While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+
+Call handlers will only trigger in one of two cases: when the function specified is called by an account other than the contract itself or when it is marked as external in Solidity and called as part of another function in the same contract.
+
+> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+
+### Defining a Call Handler
+
+To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      callHandlers:
+        - function: createGravatar(string,string)
+          handler: handleCreateGravatar
+```
+
+The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+
+### Mapping Function
+
+Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+
+```typescript
+import { CreateGravatarCall } from '../generated/Gravity/Gravity'
+import { Transaction } from '../generated/schema'
+
+export function handleCreateGravatar(call: CreateGravatarCall): void {
+  let id = call.transaction.hash
+  let transaction = new Transaction(id)
+  transaction.displayName = call.inputs._displayName
+  transaction.imageUrl = call.inputs._imageUrl
+  transaction.save()
+}
+```
+
+The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+
+## Block Handlers
+
+In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a pre-defined filter.
+
+### Supported Filters
+
+#### Call Filter
+
+```yaml
+filter:
+  kind: call
+```
+
+_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+
+> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+
+The absence of a filter for a block handler will ensure that the handler is called every block. A data source can only contain one block handler for each filter type.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: dev
+    source:
+      address: '0x731a10897d267e19b34503ad902d0a29173ba4b1'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      entities:
+        - Gravatar
+        - Transaction
+      abis:
+        - name: Gravity
+          file: ./abis/Gravity.json
+      blockHandlers:
+        - handler: handleBlock
+        - handler: handleBlockWithCallToContract
+          filter:
+            kind: call
+```
+
+#### Polling Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleBlock
+    filter:
+      kind: polling
+      every: 10
+```
+
+The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+
+#### Once Filter
+
+> **Requires `specVersion` >= 0.0.8**
+>
+> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+
+```yaml
+blockHandlers:
+  - handler: handleOnce
+    filter:
+      kind: once
+```
+
+The defined handler with the once filter will be called only once before all other handlers run. This configuration allows the subgraph to use the handler as an initialization handler, performing specific tasks at the start of indexing.
+
+```ts
+export function handleOnce(block: ethereum.Block): void {
+  let data = new InitialData(Bytes.fromUTF8('initial'))
+  data.data = 'Setup data here'
+  data.save()
+}
+```
+
+### Mapping Function
+
+The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+
+```typescript
+import { ethereum } from '@graphprotocol/graph-ts'
+
+export function handleBlock(block: ethereum.Block): void {
+  let id = block.hash
+  let entity = new Block(id)
+  entity.save()
+}
+```
+
+## Anonymous Events
+
+If you need to process anonymous events in Solidity, that can be achieved by providing the topic 0 of the event, as in the example:
+
+```yaml
+eventHandlers:
+  - event: LogNote(bytes4,address,bytes32,bytes32,uint256,bytes)
+    topic0: '0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31'
+    handler: handleGive
+```
+
+An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+
+## Transaction Receipts in Event Handlers
+
+Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+
+To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+
+```yaml
+eventHandlers:
+  - event: NewGravatar(uint256,address,string,string)
+    handler: handleNewGravatar
+    receipt: true
+```
+
+Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+
+## Order of Triggering Handlers
+
+The triggers for a data source within a block are ordered using the following process:
+
+1. Event and call triggers are first ordered by transaction index within the block.
+2. Event and call triggers within the same transaction are ordered using a convention: event triggers first then call triggers, each type respecting the order they are defined in the manifest.
+3. Block triggers are run after event and call triggers, in the order they are defined in the manifest.
+
+These ordering rules are subject to change.
+
+> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+## Data Source Templates
+
+A common pattern in EVM-compatible smart contracts is the use of registry or factory contracts, where one contract creates, manages, or references an arbitrary number of other contracts that each have their own state and events.
+
+The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+
+### Data Source for the Main Contract
+
+First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: Factory
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - Directory
+      abis:
+        - name: Factory
+          file: ./abis/factory.json
+      eventHandlers:
+        - event: NewExchange(address,address)
+          handler: handleNewExchange
+```
+
+### Data Source Templates for Dynamically Created Contracts
+
+Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: Factory
+    # ... other source fields for the main contract ...
+templates:
+  - name: Exchange
+    kind: ethereum/contract
+    network: mainnet
+    source:
+      abi: Exchange
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/exchange.ts
+      entities:
+        - Exchange
+      abis:
+        - name: Exchange
+          file: ./abis/exchange.json
+      eventHandlers:
+        - event: TokenPurchase(address,uint256,uint256)
+          handler: handleTokenPurchase
+        - event: EthPurchase(address,uint256,uint256)
+          handler: handleEthPurchase
+        - event: AddLiquidity(address,uint256,uint256)
+          handler: handleAddLiquidity
+        - event: RemoveLiquidity(address,uint256,uint256)
+          handler: handleRemoveLiquidity
+```
+
+### Instantiating a Data Source Template
+
+In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  // Start indexing the exchange; `event.params.exchange` is the
+  // address of the new exchange contract
+  Exchange.create(event.params.exchange)
+}
+```
+
+> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+>
+> If prior blocks contain data relevant to the new data source, it is best to index that data by reading the current state of the contract and creating entities representing that state at the time the new data source is created.
+
+### Data Source Context
+
+Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+
+```typescript
+import { Exchange } from '../generated/templates'
+
+export function handleNewExchange(event: NewExchange): void {
+  let context = new DataSourceContext()
+  context.setString('tradingPair', event.params.tradingPair)
+  Exchange.createWithContext(event.params.exchange, context)
+}
+```
+
+Inside a mapping of the `Exchange` template, the context can then be accessed:
+
+```typescript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+let context = dataSource.context()
+let tradingPair = context.getString('tradingPair')
+```
+
+There are setters and getters like `setString` and `getString` for all value types.
+
+## Start Blocks
+
+The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+
+```yaml
+dataSources:
+  - kind: ethereum/contract
+    name: ExampleSource
+    network: mainnet
+    source:
+      address: '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
+      abi: ExampleContract
+      startBlock: 6627917
+    mapping:
+      kind: ethereum/events
+      apiVersion: 0.0.6
+      language: wasm/assemblyscript
+      file: ./src/mappings/factory.ts
+      entities:
+        - User
+      abis:
+        - name: ExampleContract
+          file: ./abis/ExampleContract.json
+      eventHandlers:
+        - event: NewEvent(address,address)
+          handler: handleNewEvent
+```
+
+> **Note:** The contract creation block can be quickly looked up on Etherscan:
+>
+> 1. Search for the contract by entering its address in the search bar.
+> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 3. Load the transaction details page where you'll find the start block for that contract.
+
+## Indexer Hints
+
+The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+
+> This feature is available from `specVersion: 1.0.0`
+
+### Prune
+
+`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+
+1. `"never"`: No pruning of historical data; retains the entire history.
+2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+3. A specific number: Sets a custom limit on the number of historical blocks to retain.
+
+```
+ indexerHints:
+  prune: auto
+```
+
+> The term "history" in this context of subgraphs is about storing data that reflects the old states of mutable entities.
+
+History as of a given block is required for:
+
+- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
+- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Rewinding the subgraph back to that block
+
+If historical data as of the block has been pruned, the above capabilities will not be available.
+
+> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+
+For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+
+To retain a specific amount of historical data:
+
+```
+ indexerHints:
+  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+```
+
+To preserve the complete history of entity states:
+
+```
+indexerHints:
+  prune: never
+```

From 80b15ddc731e0dddecfb772205c51cc4e317b112 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:31 -0500
Subject: [PATCH 1836/3820] New translations multiple-networks.mdx (Romanian)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/ro/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/ro/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..4f7dcd3864e8
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Deploying the subgraph to multiple networks
+
+In some cases, you will want to deploy the same subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+This is what your networks config file should look like:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Now we can run one of the following commands:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Using subgraph.yaml template
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+and
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Subgraph Studio subgraph archive policy
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Every subgraph affected with this policy has an option to bring the version in question back.
+
+## Checking subgraph health
+
+If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From 8c1c40241f0f0fa9965ff1b580723679c3f3a5b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:32 -0500
Subject: [PATCH 1837/3820] New translations multiple-networks.mdx (French)

---
 .../deploying/multiple-networks.mdx           | 240 ++++++++++++++++++
 1 file changed, 240 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/fr/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/fr/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..ad2fc10ea4c6
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,240 @@
+---
+title: Déploiement d'un subgraph sur plusieurs réseaux
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Déploiement du subgraph sur plusieurs réseaux
+
+Dans certains cas, vous souhaiterez déployer le même subgraph sur plusieurs réseaux sans dupliquer tout son code. Le principal défi qui en découle est que les adresses contractuelles sur ces réseaux sont différentes.
+
+### En utilisant `graph-cli`
+
+Les commandes `graph build` (depuis la version `v0.29.0`) et `graph deploy` (depuis la version `v0.32.0`) acceptent deux nouvelles options:
+
+```sh
+Options:
+
+      --network <nom>          Configuration du réseau à utiliser à partir du fichier de configuration des réseaux
+      --network-file <chemin>  Chemin du fichier de configuration des réseaux (par défaut : "./networks.json")
+```
+
+Vous pouvez utiliser l'option `--network` pour spécifier une configuration de réseau à partir d'un fichier standard `json` (par défaut networks.json) pour facilement mettre à jour votre subgraph pendant le développement.
+
+> Note : La commande `init` générera désormais automatiquement un fichier networks.json en se basant sur les informations fournies. Vous pourrez ensuite mettre à jour les réseaux existants ou en ajouter de nouveaux.
+
+Si vous n'avez pas de fichier `networks.json`, vous devrez en créer un manuellement avec la structure suivante :
+
+```json
+{
+    "network1": { // le nom du réseau
+        "dataSource1": { // le nom de la source de données
+            "address": "0xabc...", // l'adresse du contrat (facultatif)
+            "startBlock": 123456 // le bloc de départ (facultatif)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note : Vous n'avez besoin de spécifier aucun des `templates` (si vous en avez) dans le fichier de configuration, uniquement les `dataSources`. Si des `templates` sont déclarés dans le fichier `subgraph.yaml`, leur réseau sera automatiquement mis à jour vers celui spécifié avec l'option `--network`.
+
+Supposons maintenant que vous souhaitiez déployer votre subgraph sur les réseaux `mainnet` et `sepolia`, et que ceci est votre fichier subgraph.yaml :
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Voici à quoi devrait ressembler votre fichier de configuration réseau :
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Nous pouvons maintenant exécuter l'une des commandes suivantes :
+
+```sh
+# En utilisant le fichier networks.json par défaut
+yarn build --network sepolia
+
+ # En utilisant un fichier personnalisé
+yarn build --network sepolia --network-file chemin/à/configurer
+```
+
+La commande `build` mettra à jour votre fichier `subgraph.yaml` avec la configuration `sepolia` puis recompilera le subgraph. Votre fichier `subgraph.yaml` devrait maintenant ressembler à ceci:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Vous êtes maintenant prêt à utiliser la commande `yarn deploy`.
+
+> Note : Comme mentionné précédemment, depuis `graph-cli 0.32.0`, vous pouvez directement exécuter `yarn deploy` avec l'option `--network`:
+
+```sh
+# En utilisant le fichier networks.json par défaut
+yarn deploy --network sepolia
+
+ # En utilisant un fichier personnalisé
+yarn deploy --network sepolia --network-file chemin/à/configurer
+```
+
+### Utilisation du modèle subgraph.yaml
+
+Une façon de paramétrer des aspects tels que les adresses de contrat en utilisant des versions plus anciennes de `graph-cli` est de générer des parties de celui-ci avec un système de creation de modèle comme [Mustache](https://mustache.github.io/) ou [Handlebars](https://handlebarsjs.com/).
+
+Pour illustrer cette approche, supposons qu'un subgraph doive être déployé sur le réseau principal (mainnet) et sur Sepolia en utilisant des adresses de contrat différentes. Vous pourriez alors définir deux fichiers de configuration fournissant les adresses pour chaque réseau :
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+et
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Avec ceci, vous remplacerez le nom du réseau et les adresses dans le manifeste par des variables de type `{{network}}` et `{{address}}` et renommer le manifeste par exemple `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Pour générer un manifeste pour l'un ou l'autre réseau, vous pourriez ajouter deux commandes supplémentaires au fichier `package.json` ainsi qu'une dépendance à `mustache` :
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+Pour déployer ce subgraph pour mainnet ou Sepolia, vous devez simplement exécuter l'une des deux commandes suivantes :
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+Un exemple fonctionnel de ceci peut être trouvé [ici](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+Note : Cette approche peut également être appliquée à des situations plus complexes, dans lesquelles il est nécessaire de remplacer plus que les adresses des contrats et les noms de réseau ou où il est nécessaire de générer des mappages ou alors des ABI à partir de modèles également.
+
+Cela vous donnera le `chainHeadBlock` que vous pouvez comparer avec le `latestBlock` sur votre subgraph pour vérifier s'il est en retard. `synced` vous informe si le subgraph a déjà rattrapé la chaîne. `health` peut actuellement prendre les valeurs de `healthy` si aucune erreur ne s'est produite, ou `failed` s'il y a eu une erreur qui a stoppé la progression du subgraph. Dans ce cas, vous pouvez vérifier le champ `fatalError` pour les détails sur cette erreur.
+
+## Politique d'archivage des subgraphs de Subgraph Studio
+
+Une version de subgraph dans Studio est archivée si et seulement si elle répond aux critères suivants :
+
+- La version n'est pas publiée sur le réseau (ou en attente de publication)
+- La version a été créée il y a 45 jours ou plus
+- Le subgraph n'a pas été interrogé depuis 30 jours
+
+De plus, lorsqu'une nouvelle version est déployée, si le subgraph n'a pas été publié, la version N-2 du subgraph est archivée.
+
+Chaque subgraph concerné par cette politique dispose d'une option de restauration de la version en question.
+
+## Vérification de l'état des subgraphs
+
+Si un subgraph se synchronise avec succès, c'est un bon signe qu'il continuera à bien fonctionner pour toujours. Cependant, de nouveaux déclencheurs sur le réseau peuvent amener votre subgraph à rencontrer une condition d'erreur non testée ou il peut commencer à prendre du retard en raison de problèmes de performances ou de problèmes avec les opérateurs de nœuds.
+
+Graph Node expose un endpoint GraphQL que vous pouvez interroger pour vérifier l'état de votre subgraph. Sur le service hébergé, il est disponible à l'adresse `https://api.thegraph.com/index-node/graphql`. Sur un nœud local, il est disponible sur le port `8030/graphql` par défaut. Le schéma complet de cet endpoint peut être trouvé [ici](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Voici un exemple de requête qui vérifie l'état de la version actuelle d'un subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+Cela vous donnera le `chainHeadBlock` que vous pouvez comparer avec le `latestBlock` sur votre subgraph pour vérifier s'il est en retard. `synced` vous informe si le subgraph a déjà rattrapé la chaîne. `health` peut actuellement prendre les valeurs de `healthy` si aucune erreur ne s'est produite, ou `failed` s'il y a eu une erreur qui a stoppé la progression du subgraph. Dans ce cas, vous pouvez vérifier le champ `fatalError` pour les détails sur cette erreur.

From 3094651da35f9928b01e1e03222bd3c822c3aeb3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:33 -0500
Subject: [PATCH 1838/3820] New translations multiple-networks.mdx (Spanish)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/es/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/es/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..c206beeb8fb3
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Desplegando el subgráfo en múltiples redes
+
+En algunos casos, querrás desplegar el mismo subgrafo en múltiples redes sin duplicar todo su código. El principal reto que conlleva esto es que las direcciones de los contratos en estas redes son diferentes.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Este es el aspecto que debe tener el archivo de configuración de tu red:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Ahora podemos ejecutar uno de los siguientes comandos:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Usando la plantilla subgraph.yaml
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+y
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Política de archivo de subgrafos en Subgraph Studio
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Cada subgrafo afectado por esta política tiene una opción para recuperar la versión en cuestión.
+
+## Comprobando la salud del subgrafo
+
+Si un subgrafo se sincroniza con éxito, es una buena señal de que seguirá funcionando bien para siempre. Sin embargo, los nuevos activadores en la red pueden hacer que tu subgrafo alcance una condición de error no probada o puede comenzar a retrasarse debido a problemas de rendimiento o problemas con los operadores de nodos.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From 09c4f6cd06cd4fe0fdeb3c22ed5416b9f36b8625 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:34 -0500
Subject: [PATCH 1839/3820] New translations multiple-networks.mdx (Arabic)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/ar/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/ar/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..4f7dcd3864e8
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Deploying the subgraph to multiple networks
+
+In some cases, you will want to deploy the same subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+This is what your networks config file should look like:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Now we can run one of the following commands:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Using subgraph.yaml template
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+and
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Subgraph Studio subgraph archive policy
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Every subgraph affected with this policy has an option to bring the version in question back.
+
+## Checking subgraph health
+
+If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From 77064dcfa42e10b913174e7fa90cc3989b340c5b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:36 -0500
Subject: [PATCH 1840/3820] New translations multiple-networks.mdx (Czech)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/cs/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/cs/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..77f05e1ad499
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Nasazení podgrafu do více sítí
+
+V některých případech budete chtít nasadit stejný podgraf do více sítí, aniž byste museli duplikovat celý jeho kód. Hlavním problémem, který s tím souvisí, je skutečnost, že smluvní adresy v těchto sítích jsou různé.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Takto by měl vypadat konfigurační soubor sítě:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Nyní můžeme spustit jeden z následujících příkazů:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Použití šablony subgraph.yaml
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+a
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Zásady archivace subgrafů Subgraph Studio
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Každý podgraf ovlivněný touto zásadou má možnost vrátit danou verzi zpět.
+
+## Kontrola stavu podgrafů
+
+Pokud se podgraf úspěšně synchronizuje, je to dobré znamení, že bude dobře fungovat navždy. Nové spouštěče v síti však mohou způsobit, že se podgraf dostane do neověřeného chybového stavu, nebo může začít zaostávat kvůli problémům s výkonem či operátory uzlů.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From a13cfd8c857d1f64ff861f74a23bae6ab1d5de56 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:37 -0500
Subject: [PATCH 1841/3820] New translations multiple-networks.mdx (German)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..4f7dcd3864e8
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Deploying the subgraph to multiple networks
+
+In some cases, you will want to deploy the same subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+This is what your networks config file should look like:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Now we can run one of the following commands:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Using subgraph.yaml template
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+and
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Subgraph Studio subgraph archive policy
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Every subgraph affected with this policy has an option to bring the version in question back.
+
+## Checking subgraph health
+
+If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From 43dc7e94d1ae1b11d781698c093c9e631da12d73 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:38 -0500
Subject: [PATCH 1842/3820] New translations multiple-networks.mdx (Italian)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/it/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/it/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..0bcbe1eddc43
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Distribuzione del subgraph su più reti
+
+In alcuni casi, si desidera distribuire lo stesso subgraph su più reti senza duplicare tutto il suo codice. Il problema principale è che gli indirizzi dei contratti su queste reti sono diversi.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // il nome della rete
+        "dataSource1": { // il nome del dataSource
+            "address": "0xabc...", // l'indirizzo del contratto (opzionale)
+            "startBlock": 123456 // il startBlock (opzionale)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Questo è l'aspetto del file di configurazione delle reti:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Ora possiamo eseguire uno dei seguenti comandi:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Utilizzo del template subgraph.yaml
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+e
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Politica di archiviazione dei subgraph di Subgraph Studio
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Ogni subgraph colpito da questa politica ha un'opzione per recuperare la versione in questione.
+
+## Verifica dello stato di salute del subgraph
+
+Se un subgraph si sincronizza con successo, è un buon segno che continuerà a funzionare bene per sempre. Tuttavia, nuovi trigger sulla rete potrebbero far sì che il subgraph si trovi in una condizione di errore non testata o che inizi a rimanere indietro a causa di problemi di prestazioni o di problemi con gli operatori dei nodi.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From 1212787ff689b1d5bd716fa4d3a63c0f1cbb6286 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:39 -0500
Subject: [PATCH 1843/3820] New translations multiple-networks.mdx (Japanese)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/ja/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/ja/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..53c7dcfbd86b
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## サブグラフを複数のネットワークにデプロイする
+
+場合によっては、すべてのコードを複製せずに、同じサブグラフを複数のネットワークに展開する必要があります。これに伴う主な課題は、これらのネットワークのコントラクト アドレスが異なることです。
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+ネットワーク設定ファイルはこのようになっているはずです:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+これで、次のいずれかのコマンドを実行できるようになりました:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### subgraph.yamlテンプレートの使用
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+and/と
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Subgraph Studio・サブグラフ・アーカイブポリシー
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+このポリシーで影響を受けるすべてのサブグラフには、問題のバージョンを戻すオプションがあります。
+
+## サブグラフのヘルスチェック
+
+サブグラフが正常に同期された場合、それはそれが永久に正常に動作し続けることを示す良い兆候です。ただし、ネットワーク上の新しいトリガーにより、サブグラフがテストされていないエラー状態に陥ったり、パフォーマンスの問題やノード オペレーターの問題により遅れが生じたりする可能性があります。
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From f3487e15f45fe8c836c8332dd3a5d0e2531ada9e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:40 -0500
Subject: [PATCH 1844/3820] New translations multiple-networks.mdx (Korean)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/ko/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/ko/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..4f7dcd3864e8
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Deploying the subgraph to multiple networks
+
+In some cases, you will want to deploy the same subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+This is what your networks config file should look like:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Now we can run one of the following commands:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Using subgraph.yaml template
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+and
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Subgraph Studio subgraph archive policy
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Every subgraph affected with this policy has an option to bring the version in question back.
+
+## Checking subgraph health
+
+If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From 77379713e992ede30f1305c800c5e6d73aea0f6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:41 -0500
Subject: [PATCH 1845/3820] New translations multiple-networks.mdx (Dutch)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/nl/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/nl/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..4f7dcd3864e8
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Deploying the subgraph to multiple networks
+
+In some cases, you will want to deploy the same subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+This is what your networks config file should look like:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Now we can run one of the following commands:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Using subgraph.yaml template
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+and
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Subgraph Studio subgraph archive policy
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Every subgraph affected with this policy has an option to bring the version in question back.
+
+## Checking subgraph health
+
+If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From 82c9c32cb2dda7a3fa821ebfa35084b9b9901ea0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:42 -0500
Subject: [PATCH 1846/3820] New translations multiple-networks.mdx (Polish)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/pl/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/pl/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..4f7dcd3864e8
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Deploying the subgraph to multiple networks
+
+In some cases, you will want to deploy the same subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+This is what your networks config file should look like:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Now we can run one of the following commands:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Using subgraph.yaml template
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+and
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Subgraph Studio subgraph archive policy
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Every subgraph affected with this policy has an option to bring the version in question back.
+
+## Checking subgraph health
+
+If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From c7a77828359b4a287e06471e8e2c46c2f66d8052 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:43 -0500
Subject: [PATCH 1847/3820] New translations multiple-networks.mdx (Portuguese)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/pt/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/pt/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..7164b6d5a83c
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Como lançar o subgraph a várias redes
+
+Em alguns casos, irá querer lançar o mesmo subgraph a várias redes sem duplicar o seu código completo. O grande desafio nisto é que os endereços de contrato nestas redes são diferentes.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // nome da rede
+        "dataSource1": { // nome do dataSource
+            "address": "0xabc...", // endereço do contrato (opcional)
+            "startBlock": 123456 // bloco inicial (opcional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+O seu arquivo de config de redes deve ficar assim:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Agora podemos executar um dos seguintes comandos:
+
+```sh
+# Usar o arquivo networks.json padrão
+yarn build --network sepolia
+
+# Usar arquivo com nome personalizado
+yarn build --network sepolia --network-file local/do/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Usar o arquivo networks.json padrão
+yarn deploy --network sepolia
+
+# Usar arquivo com nome personalizado
+yarn deploy --network sepolia --network-file local/do/config
+```
+
+### Como usar o template subgraph.yaml
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+Por exemplo, vamos supor que um subgraph deve ser lançado à mainnet e à Sepolia, através de diferentes endereços de contratos. Então, seria possível definir dois arquivos de config ao fornecer os endereços para cada rede:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+e
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+Para lançar este subgraph à mainnet ou à Sepolia, apenas um dos seguintes comandos precisaria ser executado:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Política de arqivamento do Subgraph Studio
+
+Uma versão de subgraph no Studio é arquivada se, e apenas se, atender aos seguintes critérios:
+
+- A versão não foi publicada na rede (ou tem a publicação pendente)
+- A versão foi criada há 45 dias ou mais
+- O subgraph não foi consultado em 30 dias
+
+Além disto, quando uma nova versão é editada, se o subgraph ainda não foi publicado, então a versão N-2 do subgraph é arquivada.
+
+Todos os subgraphs afetados por esta política têm a opção de trazer de volta a versão em questão.
+
+## Como conferir a saúde do subgraph
+
+Se um subgraph for sincronizado com sucesso, isto indica que ele continuará a rodar bem para sempre. Porém, novos gatilhos na rede podem revelar uma condição de erro não testada, ou ele pode começar a se atrasar por problemas de desempenho ou com os operadores de nodes.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From c47e6841ac3794d5ed7f28ef5253d5309ff804fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:45 -0500
Subject: [PATCH 1848/3820] New translations multiple-networks.mdx (Russian)

---
 .../deploying/multiple-networks.mdx           | 240 ++++++++++++++++++
 1 file changed, 240 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/ru/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/ru/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..8ae55fbd8bcc
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,240 @@
+---
+title: Развертывание субграфа в нескольких сетях
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Развертывание подграфа в нескольких сетях
+
+В некоторых случаях вы захотите развернуть один и тот же подграф в нескольких сетях, не дублируя весь его код. Основная проблема, возникающая при этом, заключается в том, что адреса контрактов в этих сетях разные.
+
+### Использование `graph-cli`
+
+Как `graph build` (начиная с `v0.29.0`), так и `graph deploy` (начиная с `v0.32.0`) допускают две новые опции:
+
+```sh
+Опции:
+      ...
+      --network <name> Конфигурация сети для использования из файла конфигурации сетей
+      --network-file <path> Путь к файлу конфигурации сетей (по умолчанию: "./networks.json")
+```
+
+Вы можете использовать опцию `--network` для указания конфигурации сети из стандартного файла `json` (по умолчанию используется `networks.json`), чтобы легко обновлять свой субграф во время разработки.
+
+> Примечание: Команда `init` теперь автоматически сгенерирует `networks.json` на основе предоставленной информации. Затем Вы сможете обновить существующие или добавить дополнительные сети.
+
+Если у Вас нет файла `networks.json`, Вам нужно будет вручную создать его со следующей структурой:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Примечание: Вам не нужно указывать ни один из `templates` (если они у Вас есть) в файле конфигурации, только `dataSources`. Если есть какие-либо `templates`, объявленные в файле `subgraph.yaml`, их сеть будет автоматически обновлена до указанной с помощью опции `--network`.
+
+Теперь давайте предположим, что Вы хотите иметь возможность развернуть свой субграф в сетях `mainnet` и `sepolia`, и это Ваш `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Вот как должен выглядеть файл конфигурации ваших сетей:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Теперь мы можем запустить одну из следующих команд:
+
+```sh
+# Использование стандартного файла networks.json
+yarn build --network sepolia
+
+# Использование файла с пользовательским именем
+yarn build --network sepolia --network-file path/to/config
+```
+
+Команда `build` обновит Ваш `subgraph.yaml` конфигурацией `sepolia`, а затем повторно скомпилирует субграф. Ваш файл `subgraph.yaml` теперь должен выглядеть следующим образом:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Теперь Вы готовы выполнить команду `yarn deploy`.
+
+> Примечание: Как упоминалось ранее, начиная с версии `graph-cli 0.32.0` Вы можете напрямую выполнить команду `yarn deploy` с опцией `--network`:
+
+```sh
+# Использование стандартного файла networks.json
+yarn deploy --network sepolia
+
+# Использование файла с пользовательским именем
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Использование шаблона subgraph.yaml
+
+Одним из способов параметризации таких аспектов, как адреса контрактов, с использованием старых версий `graph-cli` является генерация его частей с помощью системы шаблонов, такой как [Mustache](https://mustache.github.io/) или [Handlebars](https://handlebarsjs.com/).
+
+Чтобы проиллюстрировать этот подход, давайте предположим, что субграф должен быть развернут в майннете и в сети Sepolia с использованием разных адресов контракта. Затем Вы можете определить два файла конфигурации, содержащие адреса для каждой сети:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+и
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Наряду с этим, необходимо заменить имя сети и адреса в манифесте на variable placeholders `{{network}}` и `{{address}}` и переименовать манифест, например, `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Чтобы сгенерировать манифест для любой сети, можно добавить две дополнительные команды в `package.json` вместе с зависимостью от `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+Чтобы развернуть этот субграф для основной сети или сети Sepolia, Вам нужно просто запустить одну из двух следующих команд:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+Наглядный пример можно найти [здесь](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Примечание:** Этот подход также можно применять в более сложных ситуациях, когда необходимо заменить не только адреса контрактов и сетевые имена, но и сгенерировать мэппинги или ABI из шаблонов.
+
+Это предоставит Вам `chainHeadBlock`, который Вы сможете сравнить с `latestBlock` своего субграфа, чтобы проверить, не отстает ли он. `synced` сообщает, попал ли субграф в чейн. `health` в настоящее время может принимать значения `healthy`, если ошибки отсутствуют, или `failed`, если произошла ошибка, остановившая работу субграфа. В этом случае Вы можете проверить поле `fatalError` для получения подробной информации об этой ошибке.
+
+## Политика архивирования подграфов в Subgraph Studio
+
+Версия субграфа в Studio архивируется, если и только если выполняются следующие критерии:
+
+- Версия не опубликована в сети (или ожидает публикации)
+- Версия была создана 45 или более дней назад
+- Субграф не запрашивался в течение 30 дней
+
+Кроме того, когда развертывается новая версия, если субграф не был опубликован, то версия N-2 субграфа архивируется.
+
+У каждого подграфа, затронутого этой политикой, есть возможность вернуть соответствующую версию обратно.
+
+## Проверка работоспособности подграфа
+
+Если подграф успешно синхронизируется, это хороший признак того, что он будет работать надёжно. Однако новые триггеры в сети могут привести к тому, что ваш подграф попадет в состояние непроверенной ошибки, или он может начать отставать из-за проблем с производительностью или проблем с операторами нод.
+
+Graph Node предоставляет конечную точку GraphQL, которую Вы можете запросить для проверки статуса своего субграфа. В хостинговом сервисе он доступен по адресу `https://api.thegraph.com/index-node/graphql`. На локальной ноде он по умолчанию доступен через порт `8030/graphql`. Полную схему для этой конечной точки можно найти [здесь](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Вот пример запроса, проверяющего состояние текущей версии субграфа:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+Это предоставит Вам `chainHeadBlock`, который Вы сможете сравнить с `latestBlock` своего субграфа, чтобы проверить, не отстает ли он. `synced` сообщает, попал ли субграф в чейн. `health` в настоящее время может принимать значения `healthy`, если ошибки отсутствуют, или `failed`, если произошла ошибка, остановившая работу субграфа. В этом случае Вы можете проверить поле `fatalError` для получения подробной информации об этой ошибке.

From 79212eefe357f3fdb109c4f2966b8e7dae530a91 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:46 -0500
Subject: [PATCH 1849/3820] New translations multiple-networks.mdx (Swedish)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/sv/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/sv/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..8be847bc8fab
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Distribuera undergrafen till flera nätverk
+
+I vissa fall vill du distribuera samma undergraf till flera nätverk utan att duplicera all dess kod. Den största utmaningen med detta är att kontraktsadresserna på dessa nätverk är olika.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // nätverkets namn
+        "dataSource1": { // namn på datakällan
+            "address": "0xabc...", // Avtalets adress (frivillig uppgift)
+            "startBlock": 123456 // startBlock (valfritt)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Så här ska nätverkets konfigurationsfil se ut:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Nu kan vi köra något av följande kommandon:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Använda subgraph.yaml mallen
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+och
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Subgraph Studio subgraf arkivpolitik
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Varje subgraf som påverkas av denna policy har en möjlighet att ta tillbaka versionen i fråga.
+
+## Kontroll av undergrafens hälsa
+
+Om en subgraf synkroniseras framgångsrikt är det ett gott tecken på att den kommer att fortsätta att fungera bra för alltid. Nya triggers i nätverket kan dock göra att din subgraf stöter på ett otestat feltillstånd eller så kan den börja halka efter på grund av prestandaproblem eller problem med nodoperatörerna.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From 26ea41fbe494f9764f0617b313b0352a789eb6f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:47 -0500
Subject: [PATCH 1850/3820] New translations multiple-networks.mdx (Turkish)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/tr/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/tr/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..2241675eac10
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Bir Subgraph'i Birden Fazla Ağda Dağıtma
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Subgraph'i Birden Fazla Ağda Dağıtma
+
+Bazı durumlarda, tüm kodu tekrarlamak zorunda olmadan aynı subgraph'i birden fazla ağda yayına almak isteyebilirsiniz. Bunu yapmaktaki temel zorluk, sözleşme kodu tamamen aynı olsa dahi, farklı ağlardaki sözleşme adreslerinin farklı olmasıdır.
+
+### `graph-cli` Kullanarak
+
+Hem `graph build` (`v0.29.0`'dan itibaren) hem de `graph deploy` (`v0.32.0`'dan itibaren) komutları iki yeni seçeneği kabul eder:
+
+```sh
+Seçenekler:
+
+      ...
+      --network <name>          Ağ yapılandırmasını networks config dosyasını kullanarak yapmak için
+      --network-file <path>     Ağ yapılandırma dosya yolu (varsayılan: "./networks.json")
+```
+
+`--network` seçeneğini, geliştirme sırasında subgraph'inizi kolayca güncellemek amacıyla, bir `json` standart dosyası kullanarak bir ağ yapılandırması belirlemek için kullanabilirsiniz. (Varsayılan olarak `networks.json` dosyasını kullanır.)
+
+> Not: Artık, `init` komutu, sağlanan bilgilere dayanarak otomatik olarak bir `networks.json` dosyası oluşturmaktadır. Daha sonra mevcut ağları güncelleyebilir veya yeni ağlar ekleyebilirsiniz.
+
+Eğer bir `networks.json` dosyanız yoksa, aşağıdaki yapı ile manuel olarak oluşturmanız gerekecek:
+
+```json
+{
+    "network1": { // ağ adı
+        "dataSource1": { //veri kaynağı adı
+            "address": "0xabc...", // sözleşme adresi (isteğe bağlı)
+            "startBlock": 123456 // başlangıç bloku (isteğe bağlı)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Not: Yapılandırma dosyasında `templates` (şablonlar, eğer varsa) kısmını doldurmanıza gerek yoktur, yalnızca `dataSources` (veri kaynaklarını) belirtmelisiniz. Eğer `subgraph.yaml` dosyasında `templates` kısmı tanımlanmışsa, bunların ağı `--network` seçeneği ile belirtilen ağa otomatik olarak güncellenecektir.
+
+Şimdi, subgraph'inizi `mainnet` ve `sepolia` ağlarında dağıtmak istediğinizi varsayalım ve `subgraph.yaml` dosyanız aşağıdaki gibi olsun\`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Ağ yapılandırma dosyanız şu şekilde olmalıdır:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Şimdi aşağıdaki komutlardan birini çalıştırabilirsiniz:
+
+```sh
+# Varsayılan networks.json dosyasını kullanarak
+yarn build --network sepolia
+
+# Özel adlandırılmış bir dosya kullanarak
+yarn build --network sepolia --network-file path/to/config
+```
+
+`build` komutu, `subgraph.yaml` dosyanızı `sepolia` yapılandırmasıyla güncelleyip ardından subgraph'i yeniden derleyecektir. `subgraph.yaml` dosyanız artık şöyle görünmelidir:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Artık `yarn deploy` komutunu çalıştırmaya hazırsınız.
+
+> Not: Daha önce de belirtildiği gibi, `graph-cli 0.32.0` sürümünden itibaren `yarn deploy` komutunu doğrudan `--network` seçeneğiyle çalıştırabilirsiniz:
+
+```sh
+# Varsayılan networks.json dosyasını kullanarak
+yarn deploy --network sepolia
+
+# Özel adlandırılmış bir dosya kullanarak
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### <code>subgraph.yaml</code> şablonunu kullanarak:
+
+Daha eski `graph-cli` sürümlerini kullanarak kontrat adresleri gibi unsurları parametrize etmenin bir yolu, bunların bir kısmını [Mustache](https://mustache.github.io/) veya [Handlebar](https://handlebarsjs.com/) gibi bir şablonlama sistemiyle oluşturmaktır.
+
+Bu yaklaşımı açıklamak için, bir subgraph'in mainnet ve Sepolia ağlarına farklı sözleşme adresleri ile dağıtılması gerektiğini varsayalım. Her ağ için adresleri sağlayan iki yapılandırma dosyası tanımlayabilirsiniz:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+ve
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Bununla birlikte, ağ adını ve adresleri manifesto içinde `{{network}}` ve `{{address}}` gibi değişken yer tutucularla değiştirir ve manifestoyu örneğin `subgraph.template.yaml` olarak yeniden adlandırırsınız:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Her iki ağ için de bir manifesto oluşturmak amacıyla, `package.json` dosyasına `mustache` gereksinimiyle birlikte iki ek komut ekleyebilirsiniz:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+Bu subgraph'i mainnet veya Sepolia üzerinde yayına almak için artık aşağıdaki iki komuttan birini çalıştırabilirsiniz:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+Bunun çalışan bir örneğini [burada](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759) bulabilirsiniz.
+
+**Not**: Bu yaklaşım, sözleşme adresleri ve ağ adlarının ötesinde daha fazla değişiklik yapmanın, veya şablonlardan mapping ya da ABI'ler oluşturmanın gerekli olduğu, daha karmaşık durumlara da uygulanabilir.
+
+Bu işlem, subgraph'inizin geride kalıp kalmadığını kontrol etmek için `chainHeadBlock` değerini subgraph'inizdeki `latestBlock` ile karşılaştırmanızı sağlar. `synced`, subgraph'in zincire daha önce hiç yetişip yetişmediğini belirtir. `health` ise şu anda hata olmadığında `healthy` ve bir hata nedeniyle subgraph'in ilerlemesi durduğunda `failed` değerlerini alabilir. Bu durumda, hataya dair ayrıntılar için `fatalError` alanını kontrol edebilirsiniz.
+
+## Subgraph Studio Subgraph Arşivleme Politikası
+
+Studio’daki bir subgraph sürümü yalnızca aşağıdaki kriterleri karşılaması durumunda arşivlenir:
+
+- Sürüm ağa yayımlanmamıştır (veya yayım askıda kalmıştır)
+- Sürüm, 45 gün veya daha uzun bir süre önce oluşturulmuştur
+- Subgraph son 30 gündür sorgulanmamıştır
+
+Ek olarak, yeni bir sürüm yayına alındığında, eğer subgraph yayımlanmadıysa, subgraph’in N-2 sürümü arşivlenir.
+
+Bu politika kapsamında etkilenen her subgraph, ilgili sürümü geri getirme seçeneğine sahiptir.
+
+## Subgraph durumunu kontrol etme
+
+Bir subgraph'in başarıyla senkronize olması, sonsuza kadar sorunsuz çalışmaya devam edeceğine dair iyi bir işarettir. Ancak, ağdaki yeni tetikleyiciler subgraph'inizin test edilmemiş bir hata durumuna düşmesine neden olabilir, veya performans sorunları ya da düğüm operatörlerindeki sorunlar nedeniyle subgraph geride kalmaya başlayabilir.
+
+Graph Düğümü, subgraph'inizin durumunu kontrol etmek için sorgu yapabileceğiniz bir GraphQL uç noktası sunar. Sağlayıcı hizmetinde bu uç nokta `https://api.thegraph.com/index-node/graphql` adresinde bulunmaktadır. Yerel bir düğümde ise varsayılan olarak `8030/graphql` portunda erişilebilir. Bu uç noktanın tam şemasına [buradan](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql) ulaşabilirsiniz. İşte bir subgraph'in güncel sürümünün durumunu kontrol eden örnek bir sorgu:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+Bu işlem, subgraph'inizin geride kalıp kalmadığını kontrol etmek için `chainHeadBlock` değerini subgraph'inizdeki `latestBlock` ile karşılaştırmanızı sağlar. `synced`, subgraph'in zincire daha önce hiç yetişip yetişmediğini belirtir. `health` ise şu anda hata olmadığında `healthy` ve bir hata nedeniyle subgraph'in ilerlemesi durduğunda `failed` değerlerini alabilir. Bu durumda, hataya dair ayrıntılar için `fatalError` alanını kontrol edebilirsiniz.

From 993aa8cc05da90da279a20106af1490466419b2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:48 -0500
Subject: [PATCH 1851/3820] New translations multiple-networks.mdx (Ukrainian)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/uk/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/uk/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..4f7dcd3864e8
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Deploying the subgraph to multiple networks
+
+In some cases, you will want to deploy the same subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+This is what your networks config file should look like:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Now we can run one of the following commands:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Using subgraph.yaml template
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+and
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Subgraph Studio subgraph archive policy
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Every subgraph affected with this policy has an option to bring the version in question back.
+
+## Checking subgraph health
+
+If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From 745bdc37bfec09dfb5c86113df14a0eee41cd781 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:49 -0500
Subject: [PATCH 1852/3820] New translations multiple-networks.mdx (Chinese
 Simplified)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/zh/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/zh/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..3608f13cb405
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## 将子图部署到多个网络
+
+在某些情况下，您需要将相同的子图部署到多个网络，而不复制其所有代码。随之而来的主要挑战是这些网络上的合约地址不同。
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+您的网络配置文件应该是这样的:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+现在我们可以运行以下命令之一:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### 使用 subgraph.yaml 模板
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+和
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## 子图工作室子图封存策略
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+受此策略影响的每个子图都有一个选项，可以回复有问题的版本。
+
+## 检查子图状态
+
+如果子图成功同步，这是一个好信号，表明它将永远运行良好。然而，网络上的新触发器可能会导致子图遇到未经测试的错误条件，或者由于性能问题或节点操作符的问题，子图开始落后。
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From bd026081fb8ae553e97a139528dccf0417c57fbc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:50 -0500
Subject: [PATCH 1853/3820] New translations multiple-networks.mdx (Urdu
 (Pakistan))

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/ur/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/ur/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..0f23c9bdb044
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## سب گراف کو متعدد نیٹ ورکس پر تعینات کرنا
+
+کچھ معاملات میں، آپ ایک ہی سب گراف کو متعدد نیٹ ورکس پر اس کے تمام کوڈ کی نقل کیے بغیر تعینات کرنا چاہیں گے۔ اس کے ساتھ آنے والا بنیادی چیلنج یہ ہے کہ ان نیٹ ورکس پر کنٹریکٹ ایڈریس مختلف ہیں.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+آپ کے نیٹ ورکس کی تشکیل فائل کو اس طرح نظر آنا چاہئے:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+اب ہم زیل میں دی گئ کمانڈز میں سے ایک چلا سکتے ہیں:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Subgraph.yaml ٹیمپلیٹ استعمال کرنا
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+اور
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## سب گراف سٹوڈیو سب گراف آرکائیو پالیسی
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+اس پالیسی سے متاثر ہونے والے ہر سب گراف کے پاس زیر بحث ورژن کو واپس لانے کا اختیار ہے.
+
+## سب گراف کی صحت کی جانچ کرنا
+
+اگر ایک سب گراف کامیابی کے ساتھ مطابقت پذیر ہوتا ہے، تو یہ ایک اچھی علامت ہے کہ یہ ہمیشہ کے لیے اچھی طرح چلتا رہے گا۔ تاہم، نیٹ ورک پر نئے محرکات آپ کے سب گراف کو بغیر جانچ کی خرابی کی حالت کو نشانہ بنا سکتے ہیں یا کارکردگی کے مسائل یا نوڈ آپریٹرز کے ساتھ مسائل کی وجہ سے یہ پیچھے پڑنا شروع کر سکتا ہے.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From b109f52849abc1194de1bb5e1e83897e2766b25d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:51 -0500
Subject: [PATCH 1854/3820] New translations multiple-networks.mdx (Vietnamese)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/vi/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/vi/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..4f7dcd3864e8
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Deploying the subgraph to multiple networks
+
+In some cases, you will want to deploy the same subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+This is what your networks config file should look like:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Now we can run one of the following commands:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Using subgraph.yaml template
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+and
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Subgraph Studio subgraph archive policy
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Every subgraph affected with this policy has an option to bring the version in question back.
+
+## Checking subgraph health
+
+If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From ae5d644f9e550e81c12867310febe06bd8de8cff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:52 -0500
Subject: [PATCH 1855/3820] New translations multiple-networks.mdx (Marathi)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/mr/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/mr/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..8d85033aeb01
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## एकाधिक नेटवर्कवर सबग्राफ तैनात करणे
+
+काही प्रकरणांमध्ये, तुम्हाला समान सबग्राफ एकाधिक नेटवर्कवर त्याच्या कोडची नक्कल न करता उपयोजित करायचा असेल. यासह येणारे मुख्य आव्हान हे आहे की या नेटवर्कवरील कराराचे पत्ते वेगळे आहेत.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+तुमची नेटवर्क कॉन्फिगरेशन फाइल अशी दिसली पाहिजे:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+आता आपण खालीलपैकी एक कमांड रन करू शकतो:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### वापरत आहे subgraph.yaml टेम्पलेट
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+आणि
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## सबग्राफ स्टुडिओ सबग्राफ संग्रहण धोरण
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+या धोरणामुळे प्रभावित झालेल्या प्रत्येक सबग्राफला प्रश्नातील आवृत्ती परत आणण्याचा पर्याय आहे.
+
+## सबग्राफ आरोग्य तपासत आहे
+
+जर सबग्राफ यशस्वीरित्या समक्रमित झाला, तर ते कायमचे चांगले चालत राहण्याचे चांगले चिन्ह आहे. तथापि, नेटवर्कवरील नवीन ट्रिगर्समुळे तुमच्या सबग्राफची चाचणी न केलेली त्रुटी स्थिती येऊ शकते किंवा कार्यप्रदर्शन समस्यांमुळे किंवा नोड ऑपरेटरमधील समस्यांमुळे ते मागे पडू शकते.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From 4df407ffca572ddadafaaf0376719b101f557a8f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:54 -0500
Subject: [PATCH 1856/3820] New translations multiple-networks.mdx (Hindi)

---
 .../deploying/multiple-networks.mdx           | 242 ++++++++++++++++++
 1 file changed, 242 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/hi/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/hi/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..3e03014aba51
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,242 @@
+---
+title: मल्टीपल नेटवर्क्स पर एक Subgraph डिप्लॉय करना
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## सबग्राफ को कई नेटवर्क पर तैनात करना
+
+कुछ मामलों में, आप एक ही सबग्राफ को इसके सभी कोड को डुप्लिकेट किए बिना कई नेटवर्क पर तैनात करना चाहेंगे। इसके साथ आने वाली मुख्य चुनौती यह है कि इन नेटवर्कों पर अनुबंध के पते अलग-अलग हैं।
+
+### graph-cli का उपयोग करते हुए
+
+दोनों graph build (v0.29.0 से) और graph deploy (v0.32.0 से) दो नए विकल्प स्वीकार करते हैं:
+
+```sh
+विकल्प:
+
+      ...
+      --network <name>          नेटवर्क कॉन्फ़िगरेशन का उपयोग करें जो नेटवर्क कॉन्फ़िग फ़ाइल से हो
+      --network-file <path>     नेटवर्क्स कॉन्फ़िग फ़ाइल का पथ (डिफ़ॉल्ट: "./networks.json")
+
+```
+
+आप --network विकल्प का उपयोग करके एक नेटवर्क कॉन्फ़िगरेशन को एक json मानक फ़ाइल (डिफ़ॉल्ट रूप से networks.json) से निर्दिष्ट कर सकते हैं ताकि विकास के दौरान आसानी से अपने subgraph को अपडेट किया जा सके
+
+> ध्यान दें: init कमांड अब दी गई जानकारी के आधार पर एक networks.json को स्वचालित रूप से उत्पन्न करेगा। इसके बाद आप मौजूदा नेटवर्क को अपडेट कर सकेंगे या अतिरिक्त नेटवर्क जोड़ सकेंगे।
+
+अगर आपके पास networks.json फ़ाइल नहीं है, तो आपको इसे मैन्युअल रूप से निम्नलिखित संरचना के साथ बनाना होगा:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> ध्यान दें: आपको किसी भी 'templates' (यदि आपके पास कोई है) को config फ़ाइल में निर्दिष्ट करने की आवश्यकता नहीं है, केवल 'dataSources' को। यदि 'subgraph.yaml' फ़ाइल में कोई 'templates' घोषित किए गए हैं, तो उनका नेटवर्क स्वचालित रूप से उस नेटवर्क में अपडेट हो जाएगा जो 'network' विकल्प के साथ निर्दिष्ट किया गया है।
+
+मान लीजिए कि आप अपने subgraph को mainnet और sepolia नेटवर्क पर डिप्लॉय करना चाहते हैं, और यह आपका subgraph.yaml है:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+आपकी नेटवर्क कॉन्फ़िग फ़ाइल इस तरह दिखनी चाहिए:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+अब हम निम्न में से कोई एक कमांड चला सकते हैं:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+build कमांड आपके subgraph.yaml को sepolia कॉन्फ़िगरेशन के साथ अपडेट करेगा और फिर से subgraph को पुनः-कंपाइल करेगा। आपका subgraph.yaml फ़ाइल अब इस प्रकार दिखना चाहिए:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+अब आप yarn deploy के लिए तैयार हैं।
+
+> नोट: जैसा कि पहले बताया गया है, graph-cli 0.32.0 से, आप सीधे yarn deploy को --network विकल्प के साथ चला सकते हैं:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Subgraph.yaml टेम्पलेट का उपयोग करना
+
+एक तरीका है 'graph-cli' के पुराने संस्करणों का उपयोग करके अनुबंध पते जैसी विशेषताओं को पैरामीटरित करना, जो कि एक टेम्पलेटिंग सिस्टम जैसे Mustache (https://mustache.github.io/) या Handlebars (https://handlebarsjs.com/) के साथ इसके कुछ हिस्सों को जनरेट करना है।
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+और
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+साथ ही, आप नेटवर्क नाम और पते को मैनिफेस्ट में वेरिएबल प्लेसहोल्डर्स `{{network}}` और `{{address}}` से बदल देंगे और मैनिफेस्ट का नाम बदलकर उदाहरण के लिए subgraph.template.yaml रख देंगे:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+एक मैनिफेस्ट बनाने के लिए, आप package.json में दो अतिरिक्त कमांड जोड़ सकते हैं, साथ ही mustache पर एक निर्भरता भी डाल सकते हैं:
+
+```json
+
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+मेननेट:
+yarn prepare && yarn deploy
+
+सेपोलिया:
+yarn prepare && yarn deploy
+```
+
+एक कामकाजी उदाहरण इसे यहां पाया जा सकता है here (https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+यह दृष्टिकोण अधिक जटिल परिस्थितियों में भी लागू किया जा सकता है, जहां अनुबंध पते और नेटवर्क नामों के अलावा अधिक को प्रतिस्थापित करने की आवश्यकता होती है या जहां टेम्पलेट से मैपिंग या ABIs उत्पन्न करने की आवश्यकता होती है।
+
+यह आपको chainHeadBlock देगा जिसे आप अपने subgraph पर latestBlock के साथ तुलना कर सकते हैं यह जाँचने के लिए कि क्या यह पीछे चल रहा है। synced यह बताता है कि क्या subgraph कभी श्रृंखला के साथ मेल खा गया है। health वर्तमान में दो मान ले सकता है: healthy अगर कोई त्रुटियाँ नहीं हुई हैं, या failed अगर कोई त्रुटि हुई है जिसने subgraph की प्रगति को रोक दिया है। इस स्थिति में, आप इस त्रुटि के विवरण के लिए fatalError फ़ील्ड की जांच कर सकते हैं।
+
+## सबग्राफ स्टूडियो सबग्राफ संग्रह नीति
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+इस नीति से प्रभावित प्रत्येक सबग्राफ के पास विचाराधीन संस्करण को वापस लाने का विकल्प है।
+
+## सबग्राफ स्वास्थ्य की जाँच करना
+
+यदि एक सबग्राफ सफलतापूर्वक सिंक हो जाता है, तो यह एक अच्छा संकेत है कि यह हमेशा के लिए अच्छी तरह से चलता रहेगा। हालांकि, नेटवर्क पर नए ट्रिगर्स के कारण आपका सबग्राफ एक अनुपयोगी त्रुटि स्थिति में आ सकता है या यह प्रदर्शन समस्याओं या नोड ऑपरेटरों के साथ समस्याओं के कारण पीछे पड़ना शुरू हो सकता है।
+
+Graph Node एक GraphQL endpoint को उजागर करता है जिसे आप अपने subgraph की स्थिति की जांच करने के लिए क्वेरी कर सकते हैं। होस्टेड सेवा पर, यह https://api.thegraph.com/index-node/graphql पर उपलब्ध है। एक स्थानीय नोड पर, यह डिफ़ॉल्ट रूप से पोर्ट 8030/graphql पर उपलब्ध है। इस endpoint के लिए पूरा स्कीमा यहां (https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql) पाया जा सकता है। यहां एक उदाहरण क्वेरी है जो एक subgraph के वर्तमान संस्करण की स्थिति की जांच करती है:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+यह आपको chainHeadBlock देगा जिसे आप अपने subgraph पर latestBlock के साथ तुलना कर सकते हैं यह जाँचने के लिए कि क्या यह पीछे चल रहा है। synced यह बताता है कि क्या subgraph कभी श्रृंखला के साथ मेल खा गया है। health वर्तमान में दो मान ले सकता है: healthy अगर कोई त्रुटियाँ नहीं हुई हैं, या failed अगर कोई त्रुटि हुई है जिसने subgraph की प्रगति को रोक दिया है। इस स्थिति में, आप इस त्रुटि के विवरण के लिए fatalError फ़ील्ड की जांच कर सकते हैं।

From 9d330e270e2a0e911d05f747eb4d20f64f91c1fb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:55 -0500
Subject: [PATCH 1857/3820] New translations multiple-networks.mdx (Swahili)

---
 .../deploying/multiple-networks.mdx           | 241 ++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/deploying/multiple-networks.mdx

diff --git a/website/pages/sw/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/sw/subgraphs/developing/deploying/multiple-networks.mdx
new file mode 100644
index 000000000000..4f7dcd3864e8
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/deploying/multiple-networks.mdx
@@ -0,0 +1,241 @@
+---
+title: Deploying a Subgraph to Multiple Networks
+---
+
+This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+
+## Deploying the subgraph to multiple networks
+
+In some cases, you will want to deploy the same subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.
+
+### Using `graph-cli`
+
+Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+
+```sh
+Options:
+
+      ...
+      --network <name>          Network configuration to use from the networks config file
+      --network-file <path>     Networks config file path (default: "./networks.json")
+```
+
+You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+
+> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+
+If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+
+```json
+{
+    "network1": { // the network name
+        "dataSource1": { // the dataSource name
+            "address": "0xabc...", // the contract address (optional)
+            "startBlock": 123456 // the startBlock (optional)
+        },
+        "dataSource2": {
+            "address": "0x123...",
+            "startBlock": 123444
+        }
+    },
+    "network2": {
+        "dataSource1": {
+            "address": "0x987...",
+            "startBlock": 123
+        },
+        "dataSource2": {
+            "address": "0xxyz..",
+            "startBlock": 456
+        }
+    },
+    ...
+}
+```
+
+> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+
+Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    source:
+      address: '0x123...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+This is what your networks config file should look like:
+
+```json
+{
+  "mainnet": {
+    "Gravity": {
+      "address": "0x123..."
+    }
+  },
+  "sepolia": {
+    "Gravity": {
+      "address": "0xabc..."
+    }
+  }
+}
+```
+
+Now we can run one of the following commands:
+
+```sh
+# Using default networks.json file
+yarn build --network sepolia
+
+# Using custom named file
+yarn build --network sepolia --network-file path/to/config
+```
+
+The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: sepolia
+    source:
+      address: '0xabc...'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+Now you are ready to `yarn deploy`.
+
+> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+
+```sh
+# Using default networks.json file
+yarn deploy --network sepolia
+
+# Using custom named file
+yarn deploy --network sepolia --network-file path/to/config
+```
+
+### Using subgraph.yaml template
+
+One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+
+To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+
+```json
+{
+  "network": "mainnet",
+  "address": "0x123..."
+}
+```
+
+and
+
+```json
+{
+  "network": "sepolia",
+  "address": "0xabc..."
+}
+```
+
+Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+
+```yaml
+# ...
+dataSources:
+  - kind: ethereum/contract
+    name: Gravity
+    network: mainnet
+    network: {{network}}
+    source:
+      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
+      address: '{{address}}'
+      abi: Gravity
+    mapping:
+      kind: ethereum/events
+```
+
+In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+
+```json
+{
+  ...
+  "scripts": {
+    ...
+    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
+    "prepare:sepolia": "mustache config/sepolia.json subgraph.template.yaml > subgraph.yaml"
+  },
+  "devDependencies": {
+    ...
+    "mustache": "^3.1.0"
+  }
+}
+```
+
+To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+
+```sh
+# Mainnet:
+yarn prepare:mainnet && yarn deploy
+
+# Sepolia:
+yarn prepare:sepolia && yarn deploy
+```
+
+A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+
+**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+
+## Subgraph Studio subgraph archive policy
+
+A subgraph version in Studio is archived if and only if it meets the following criteria:
+
+- The version is not published to the network (or pending publish)
+- The version was created 45 or more days ago
+- The subgraph hasn't been queried in 30 days
+
+In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+
+Every subgraph affected with this policy has an option to bring the version in question back.
+
+## Checking subgraph health
+
+If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.
+
+Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+
+```graphql
+{
+  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
+    synced
+    health
+    fatalError {
+      message
+      block {
+        number
+        hash
+      }
+      handler
+    }
+    chains {
+      chainHeadBlock {
+        number
+      }
+      latestBlock {
+        number
+      }
+    }
+  }
+}
+```
+
+This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.

From e3b450b16e9673875de36dd37228f976131d20d2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:56 -0500
Subject: [PATCH 1858/3820] New translations subgraph-studio-faq.mdx (Romanian)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/ro/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/ro/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..8761f7a31bf6
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Subgraph Studio FAQs
+---
+
+## 1. What is Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. How do I create an API Key?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Can I create multiple API Keys?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. How do I restrict a domain for an API Key?
+
+After creating an API Key, in the Security section, you can define the domains that can query a specific API Key.
+
+## 5. Can I transfer my subgraph to another owner?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Note that you will no longer be able to see or edit the subgraph in Studio once it has been transferred.
+
+## 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Remember that you can create an API key and query any subgraph published to the network, even if you build a subgraph yourself. These queries via the new API key, are paid queries as any other on the network.

From 2b28b4772dffb998da6186aaec9bfa1f6a239c61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:57 -0500
Subject: [PATCH 1859/3820] New translations subgraph-studio-faq.mdx (French)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/fr/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/fr/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..1d4c32ccc75e
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Subgraph Studio FAQ
+---
+
+## 1. Qu'est-ce que Subgraph Studio ?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. Comment créer une clé API ?
+
+Pour créer une API, allez dans Subgraph Studio et connectez votre portefeuille. Vous pourrez cliquer sur l'onglet des clés API en haut. Là, vous pourrez créer une clé API.
+
+## 3. Puis-je créer plusieurs clés API ?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. Comment limiter un domaine pour une clé API ? ?
+
+Après avoir créé une clé API, dans la section Sécurité, vous pouvez définir les domaines qui peuvent interroger une clé API spécifique.
+
+## Puis-je transférer mon subgraph à un autre propriétaire ?
+
+Oui, les subgraphs qui ont été publiés sur Arbitrum One peuvent être transférés vers un nouveau portefeuille ou un Multisig. Vous pouvez le faire en cliquant sur les trois points à côté du bouton 'Publish' sur la page des détails du subgraph et en sélectionnant 'Transfer ownership'.
+
+Notez que vous ne pourrez plus voir ou modifier le subgraph dans Studio une fois qu'il aura été transféré.
+
+## Comment trouver les URL de requête pour les sugraphs si je ne suis pas le développeur du subgraph que je veux utiliser ?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+N'oubliez pas que vous pouvez créer une clé API et interroger n'importe quel subgraph publié sur le réseau, même si vous créez vous-même un subgraph. Ces requêtes via la nouvelle clé API, sont des requêtes payantes comme n'importe quelle autre sur le réseau.

From 5ec089f8d33b3cc7c23a8e8fa16eefbc0ed65232 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:58 -0500
Subject: [PATCH 1860/3820] New translations subgraph-studio-faq.mdx (Spanish)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/es/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/es/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..14174cc468bf
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Preguntas Frecuentes sobre Subgraph Studio
+---
+
+## 1. ¿Qué es Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. ¿Cómo creo una clave API?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. ¿Puedo crear múltiples claves de API?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. ¿Cómo restrinjo un dominio para una clave API?
+
+Después de crear una clave de API, en la sección Seguridad, puedes definir los dominios que pueden consultar una clave de API específica.
+
+## 5. ¿Puedo transferir mi subgrafo a otro propietario?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Ten en cuenta que ya no podrás ver o editar el subgrafo en Studio una vez que haya sido transferido.
+
+## 6. ¿Cómo encuentro URLs de consulta para subgrafos si no soy el desarrollador del subgrafo que quiero usar?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Recuerda que puedes crear una clave API y consultar cualquier subgrafo publicado en la red, incluso si tú mismo construyes un subgrafo. Estas consultas a través de la nueva clave API, son consultas pagadas como cualquier otra en la red.

From 635c094cd914dd9000e9ba968e0e5644acb5a936 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:17:59 -0500
Subject: [PATCH 1861/3820] New translations subgraph-studio-faq.mdx (Arabic)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/ar/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/ar/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..74c0228e4093
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: الأسئلة الشائعة حول الفرعيةرسم بياني استوديو
+---
+
+## 1. What is Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. How do I create an API Key?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Can I create multiple API Keys?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. How do I restrict a domain for an API Key?
+
+After creating an API Key, in the Security section, you can define the domains that can query a specific API Key.
+
+## 5. Can I transfer my subgraph to another owner?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Note that you will no longer be able to see or edit the subgraph in Studio once it has been transferred.
+
+## 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+تذكر أنه يمكنك إنشاء API key والاستعلام عن أي subgraph منشور على الشبكة ، حتى إذا قمت ببناء subgraph بنفسك. حيث أن الاستعلامات عبر API key الجديد ، هي استعلامات مدفوعة مثل أي استعلامات أخرى على الشبكة.

From 998e90f3f4a6d99e6a437064788caf1967c121b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:00 -0500
Subject: [PATCH 1862/3820] New translations subgraph-studio-faq.mdx (Czech)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/cs/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/cs/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..a67af0f6505e
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: FAQs Podgraf Studio
+---
+
+## 1. Co je Podgraf Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. Jak vytvořím klíč API?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Mohu vytvořit více klíčů API?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. Jak omezím doménu pro klíč API?
+
+Po vytvoření klíče API můžete v části Zabezpečení definovat domény, které se mohou dotazovat na konkrétní klíč API.
+
+## 5. Mohu svůj podgraf převést na jiného vlastníka?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Všimněte si, že po přenesení podgrafu jej již nebudete moci ve Studio zobrazit ani upravovat.
+
+## 6. Jak najdu adresy URL dotazů pro podgrafy, pokud nejsem Vývojář podgrafu, který chci použít?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Nezapomeňte, že si můžete vytvořit klíč API a dotazovat se na libovolný podgraf zveřejněný v síti, i když si podgraf vytvoříte sami. Tyto dotazy prostřednictvím nového klíče API jsou placené dotazy jako jakékoli jiné v síti.

From b99e2bac3138dc01ae4b14608a9b7960e2840e52 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:01 -0500
Subject: [PATCH 1863/3820] New translations subgraph-studio-faq.mdx (German)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..7006d1662338
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Subgraph Studio-FAQs
+---
+
+## 1. Was ist Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. Wie erstelle ich einen API-Schlüssel?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Kann ich mehrere API-Schlüssel erstellen?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. How do I restrict a domain for an API Key?
+
+Nachdem Sie einen API-Schlüssel erstellt haben, können Sie im Abschnitt Sicherheit die Domänen definieren, die einen bestimmten API-Schlüssel abfragen können.
+
+## 5. Kann ich meinen Subgrafen an einen anderen Eigentümer übertragen?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Beachten Sie, dass Sie den Subgrafen nach der Übertragung nicht mehr in Studio sehen oder bearbeiten können.
+
+## 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Denken Sie daran, dass Sie einen API-Schlüssel erstellen und jeden im Netzwerk veröffentlichten Subgrafen abfragen können, auch wenn Sie selbst einen Subgrafen erstellen. Diese Abfragen über den neuen API-Schlüssel sind wie alle anderen im Netzwerk kostenpflichtige Abfragen.

From a3cffb040c8e905f2fd8e3f6b2eb14eb839f76ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:02 -0500
Subject: [PATCH 1864/3820] New translations subgraph-studio-faq.mdx (Italian)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/it/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/it/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..66453e221c08
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: FAQ di Subgraph Studio
+---
+
+## 1. Che cos'è Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. Come si crea una chiave API?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Posso creare più chiavi API?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. Come si limita un dominio per una chiave API?
+
+Dopo aver creato una chiave API, nella sezione Sicurezza è possibile definire i domini che possono eseguire query di una specifica chiave API.
+
+## 5. Posso trasferire il mio subgraph a un altro proprietario?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Si noti che non sarà più possibile vedere o modificare il subgraph nel Studio una volta trasferito.
+
+## 6. Come posso trovare gli URL di query per i subgraph se non sono lo sviluppatore del subgraph che voglio usare?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Si ricorda che è possibile creare una chiave API ed eseguire query del qualsiasi subgraph pubblicato sulla rete, anche se si costruisce un subgraph da soli. Queste query tramite la nuova chiave API sono a pagamento, come tutte le altre sulla rete.

From 13ce9a4cc208d10078b66e4441f862a0ef6feb56 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:03 -0500
Subject: [PATCH 1865/3820] New translations subgraph-studio-faq.mdx (Japanese)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/ja/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/ja/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..5810742c4ec4
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: サブグラフスタジオFAQ
+---
+
+## 1. サブグラフスタジオとは？
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. API キーを作成するにはどうすればよいですか?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. 複数の API キーを作成できますか?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. API キーのドメインを制限するにはどうすればよいですか?
+
+API キーを作成後、「セキュリティ」セクションで、特定の API キーにクエリ可能なドメインを定義できます。
+
+## 5. 自分のサブグラフを他のオーナーに譲渡することはできますか？
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+サブグラフが転送されると、Studio でサブグラフを表示または編集できなくなることに注意してください。
+
+## 6. 使用したいサブグラフの開発者ではない場合、サブグラフのクエリ URL を見つけるにはどうすればよいですか?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+APIキーを作成すると、自分でサブグラフを構築した場合でも、ネットワークに公開されているすべてのサブグラフにクエリを実行できることを覚えておいてください。新しい API キーを介したこれらのクエリは、ネットワーク上の他のクエリと同様に支払われます。

From 509da4489b7c729f057bf9ad34811ace7a3dff20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:04 -0500
Subject: [PATCH 1866/3820] New translations subgraph-studio-faq.mdx (Korean)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/ko/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/ko/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..8761f7a31bf6
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Subgraph Studio FAQs
+---
+
+## 1. What is Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. How do I create an API Key?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Can I create multiple API Keys?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. How do I restrict a domain for an API Key?
+
+After creating an API Key, in the Security section, you can define the domains that can query a specific API Key.
+
+## 5. Can I transfer my subgraph to another owner?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Note that you will no longer be able to see or edit the subgraph in Studio once it has been transferred.
+
+## 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Remember that you can create an API key and query any subgraph published to the network, even if you build a subgraph yourself. These queries via the new API key, are paid queries as any other on the network.

From 3eb447aed99654a3b6365b2f31cbec718381a63c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:05 -0500
Subject: [PATCH 1867/3820] New translations subgraph-studio-faq.mdx (Dutch)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/nl/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/nl/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..8761f7a31bf6
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Subgraph Studio FAQs
+---
+
+## 1. What is Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. How do I create an API Key?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Can I create multiple API Keys?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. How do I restrict a domain for an API Key?
+
+After creating an API Key, in the Security section, you can define the domains that can query a specific API Key.
+
+## 5. Can I transfer my subgraph to another owner?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Note that you will no longer be able to see or edit the subgraph in Studio once it has been transferred.
+
+## 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Remember that you can create an API key and query any subgraph published to the network, even if you build a subgraph yourself. These queries via the new API key, are paid queries as any other on the network.

From 8b5d77a6bcf6ae8944e9b798f884728302da32c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:06 -0500
Subject: [PATCH 1868/3820] New translations subgraph-studio-faq.mdx (Polish)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/pl/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/pl/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..8761f7a31bf6
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Subgraph Studio FAQs
+---
+
+## 1. What is Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. How do I create an API Key?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Can I create multiple API Keys?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. How do I restrict a domain for an API Key?
+
+After creating an API Key, in the Security section, you can define the domains that can query a specific API Key.
+
+## 5. Can I transfer my subgraph to another owner?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Note that you will no longer be able to see or edit the subgraph in Studio once it has been transferred.
+
+## 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Remember that you can create an API key and query any subgraph published to the network, even if you build a subgraph yourself. These queries via the new API key, are paid queries as any other on the network.

From 6ea393cfc0b987f5212d6f51d4b5df0c9babe707 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:07 -0500
Subject: [PATCH 1869/3820] New translations subgraph-studio-faq.mdx
 (Portuguese)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/pt/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/pt/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..57c66e49c2e0
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Perguntas Frequentes do Subgraph Studio
+---
+
+## 1. O que é o Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. Como criar uma Chave de API?
+
+Para criar uma API, navegue até o Subgraph Studio e conecte a sua carteira. Logo, clique na aba API Keys (Chaves de API); lá poderá criar uma chave API.
+
+## 3. Posso criar várias Chaves de API?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. Como restringir um domínio para uma Chave de API?
+
+Após criar uma Chave de API, na seção de Segurança (Security), pode definir os domínios que podem consultar uma Chave de API específica.
+
+## 5. Posso transferir meu subgraph para outro dono?
+
+Sim. Subgraphs editados no Arbitrum One podem ser transferidos para uma nova carteira ou uma Multisig. Para isto, clique nos três pontos próximos ao botão 'Publish' (Publicar) na página de detalhes do subgraph e selecione 'Transfer ownership' (Transferir titularidade).
+
+Note que após a transferência, não poderá mais ver ou alterar o subgraph no Studio.
+
+## 6. Se eu não for o programador do subgraph que quero usar, como encontro URLs de query para subgraphs?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Lembre-se que, mesmo se construir um subgraph por conta própria, ainda poderá criar uma chave de API e consultar qualquer subgraph publicado na rede. Estes queries através da nova chave API são pagos, como quaisquer outros na rede.

From c3681b3e74c7b6fa9c1cdc208606811241e4e632 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:08 -0500
Subject: [PATCH 1870/3820] New translations subgraph-studio-faq.mdx (Russian)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/ru/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/ru/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..4e0eee2dba2d
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Часто задаваемые вопросы о Subgraph Studio
+---
+
+## 1. Что такое Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. Как создать ключ API?
+
+Чтобы создать API, перейдите в Subgraph Studio и подключите свой кошелек. Вы сможете щелкнуть вкладку API-ключи вверху. Там Вы сможете создать ключ API.
+
+## 3. Могу ли я создать несколько ключей API?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. Как мне настроить ограничения домена для ключа API?
+
+После создания ключа API в разделе «Безопасность» Вы можете определить домены, которые могут запрашивать определенный ключ API.
+
+## 5. Могу ли я передать свой субграф другому владельцу?
+
+Да, субграфы, которые были опубликованы в Arbitrum One, могут быть перенесены в новый кошелек или на кошелек с мультиподписью. Вы можете сделать это, щелкнув три точки рядом с кнопкой «Опубликовать» на странице сведений о субграфе и выбрав «Передать право собственности».
+
+Обратите внимание, что Вы больше не сможете просматривать или редактировать субграф в Studio после его переноса.
+
+## 6. Как мне найти URL-адреса запросов для субграфов, если я не являюсь разработчиком субграфа, который хочу использовать?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Помните, что Вы можете создать ключ API и запрашивать любой субграф, опубликованный в сети, даже если сами создаете субграф. Эти запросы через новый ключ API являются платными, как и любые другие в сети.

From aef9d293ee8bf80c32bb95ef6fe23e086f5d10a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:09 -0500
Subject: [PATCH 1871/3820] New translations subgraph-studio-faq.mdx (Swedish)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/sv/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/sv/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..f2d35d39c1ee
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Vanliga frågor om Subgraf Studio
+---
+
+## 1. Vad är Subgraf Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. Hur skapar jag en API-nyckel?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Kan jag skapa flera API-nycklar?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. Hur begränsar jag en domän för en API-nyckel?
+
+När du har skapat en API-nyckel kan du i avsnittet Säkerhet definiera vilka domäner som kan ställa frågor till en specifik API-nyckel.
+
+## 5. Kan jag överföra min subgraf till en annan ägare?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Observera att du inte längre kommer att kunna se eller redigera undergrafen i Studio när den har överförts.
+
+## 6. Hur hittar jag fråge-URL: er för undergrafer om jag inte är utvecklaren av den undergraf jag vill använda?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Kom ihåg att du kan skapa en API-nyckel och ställa frågor till alla undergrafer som publicerats i nätverket, även om du själv har byggt en undergraf. Dessa förfrågningar via den nya API-nyckeln är betalda förfrågningar som alla andra i nätverket.

From 447e47e52fbd17b02e32dadcbd3f9262197424a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:10 -0500
Subject: [PATCH 1872/3820] New translations subgraph-studio-faq.mdx (Turkish)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/tr/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/tr/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..dc5b2fb87f0a
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Subgrap Studio Hakkında SSS
+---
+
+## 1. Subgraph Stüdyo Nedir?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. API Anahtarını Nasıl Oluşturabilirim?
+
+Bir API oluşturmak için Subgraph Studio'ya gidin ve cüzdanınızı bağlayın. Üst kısımda API anahtarları sekmesine tıklayabilirsiniz. Orada bir API anahtarı oluşturabileceksiniz.
+
+## 3. Birden Çok API Anahtarı Oluşturabilir miyim?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. API Anahtarı için Domain'i Nasıl Kısıtlarım?
+
+Bir API Anahtarı oluşturduktan sonra, Güvenlik bölümünde belirli bir API Anahtarını sorgulayabilecek alanları tanımlayabilirsiniz.
+
+## 5. Subgraph'ımı Başka Birine Devredebilir miyim?
+
+Evet, Arbitrum One'da yayımlanmış subgraph'ler yeni bir cüzdana veya bir Multisig'e aktarılabilir. Bunu, subgraph'in ayrıntılar sayfasında 'Yayımla' düğmesinin yanındaki üç noktaya tıklayıp 'Sahipliği devret' seçeneğini seçerek yapabilirsiniz.
+
+Subgraph'i devrettikten sonra onu Studio'da artık göremeyeceğinizi veya düzenleyemeyeceğinizi unutmayın.
+
+## 6. Kullanmak İstediğim Subgraph'ın Geliştiricisi Değilsem, bu Subgraphlar için Sorgu URL'lerini Nasıl Bulabilirim?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Unutmayın, bir API anahtarı oluşturarak ağda yayımlanmış herhangi bir subgraph'i sorgulayabilirsiniz; bu durum, kendi subgraph'inizi oluşturmuş olsanız bile geçerlidir. Bu yeni API anahtarı üzerinden yapılan sorgular, ağdaki diğer sorgular gibi ücretlidir.

From 2d0de6850a1e839d220f5c6fbf17a7a414340ec4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:11 -0500
Subject: [PATCH 1873/3820] New translations subgraph-studio-faq.mdx
 (Ukrainian)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/uk/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/uk/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..8761f7a31bf6
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Subgraph Studio FAQs
+---
+
+## 1. What is Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. How do I create an API Key?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Can I create multiple API Keys?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. How do I restrict a domain for an API Key?
+
+After creating an API Key, in the Security section, you can define the domains that can query a specific API Key.
+
+## 5. Can I transfer my subgraph to another owner?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Note that you will no longer be able to see or edit the subgraph in Studio once it has been transferred.
+
+## 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Remember that you can create an API key and query any subgraph published to the network, even if you build a subgraph yourself. These queries via the new API key, are paid queries as any other on the network.

From 57dc6f2f242dfd4cfc04e5c7ae21b4abe1fc6cb8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:12 -0500
Subject: [PATCH 1874/3820] New translations subgraph-studio-faq.mdx (Chinese
 Simplified)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/zh/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/zh/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..b8d40e2f2dc3
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: 子图工作室常见问题
+---
+
+## 1. 什么是 Subgraph Studio？
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. 如何创建 API 密钥？
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. 我可以创建多个 API 密钥吗？
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. 如何为 API 密钥限制域？
+
+在创建 API 密钥之后，可以在安全部分中定义可以查询特定 API 密钥的域。
+
+## 5. 我可以把我的子图转给其他所有者吗？
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+请注意，一旦传输了子图，您将无法在工作室中查看或编辑该子图。
+
+## 6. 如果我不是要使用的子图的开发人员，如何查找子图的查询URL？
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+请记住，你可以创建一个 API 密钥并查询发布到网络上的任何子图，即使你自己建立了一个子图。 这些通过新的 API 密钥进行的查询，与网络上的任何其他查询一样，都是付费查询。

From 39103d054cc29989a1bcdab7b2c9c5f6c6ab1837 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:13 -0500
Subject: [PATCH 1875/3820] New translations subgraph-studio-faq.mdx (Urdu
 (Pakistan))

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/ur/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/ur/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..3edb3d799ad3
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: سب گراف سٹوڈیو کے اکثر پوچھے گئے سوالات
+---
+
+## 1. سب گراف سٹوڈیو کیا ہے؟
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. میں ایک API کلید کیسے بنا سکتا ہوں؟
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. کیا میں ایک سے زیادہ API کلیدیں بنا سکتا ہوں؟
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. میں API کلید کے لیے ڈومین کو کیسے محدود کروں؟
+
+ایک API کلید بنانے کے بعد، سیکورٹی سیکشن میں، آپ ان ڈومینز کی وضاحت کر سکتے ہیں جو ایک مخصوص API کلید سے استفسار کر سکتے ہیں.
+
+## 5. کیا میں اپنا سب گراف کسی دوسرے مالک کو منتقل کر سکتا ہوں؟
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+نوٹ کریں کہ ایک بار منتقل ہونے کے بعد آپ سٹوڈیو میں سب گراف کو دیکھنے یا اس میں ترمیم کرنے کے قابل نہیں رہیں گے.
+
+## 6. اگر میں اس سب گراف کا ڈویلپر نہیں ہوں جسے میں استعمال کرنا چاہتا ہوں تو میں سب گراف کے لیے کیوری کے URLs کیسے تلاش کروں؟
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+یاد رکھیں کہ آپ ایک API کلید بنا سکتے ہیں اور نیٹ ورک پر شائع ہونے والے کسی بھی سب گراف سے کیوری کر سکتے ہیں، چاہے آپ خود ایک سب گراف بناتے ہوں۔ نئی API کلید کے ذریعے یہ کیوریز، نیٹ ورک پر کسی دوسرے کی طرح ادائیگی کے سوالات ہیں.

From d3b7c3b693215c1b31f576988e0b7509cab960e5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:15 -0500
Subject: [PATCH 1876/3820] New translations subgraph-studio-faq.mdx
 (Vietnamese)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/vi/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/vi/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..8761f7a31bf6
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Subgraph Studio FAQs
+---
+
+## 1. What is Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. How do I create an API Key?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Can I create multiple API Keys?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. How do I restrict a domain for an API Key?
+
+After creating an API Key, in the Security section, you can define the domains that can query a specific API Key.
+
+## 5. Can I transfer my subgraph to another owner?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Note that you will no longer be able to see or edit the subgraph in Studio once it has been transferred.
+
+## 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Remember that you can create an API key and query any subgraph published to the network, even if you build a subgraph yourself. These queries via the new API key, are paid queries as any other on the network.

From 97d272ea7aa265bc3c0d727ba1b6aef3e1bfe7fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:16 -0500
Subject: [PATCH 1877/3820] New translations subgraph-studio-faq.mdx (Marathi)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/mr/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/mr/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..f5729fb6cfa8
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: सबग्राफ स्टुडिओ FAQ
+---
+
+## 1. सबग्राफ स्टुडिओ म्हणजे काय?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. मी API की कशी तयार करू?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. मी एकाधिक API की तयार करू शकतो?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. मी API की साठी डोमेन कसे प्रतिबंधित करू?
+
+API की तयार केल्यानंतर, सिक्युरिटी विभागात, तुम्ही डोमेन परिभाषित करू शकता जे विशिष्ट क्वेरी करू शकतात API.
+
+## 5. मी माझा सबग्राफ दुसर्‍या मालकाकडे हस्तांतरित करू शकतो का?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+लक्षात ठेवा की एकदा स्‍टुडिओमध्‍ये सबग्राफ स्‍थानांतरित केल्‍यानंतर तुम्‍ही तो पाहू किंवा संपादित करू शकणार नाही.
+
+## 6. मला वापरायचा असलेल्या सबग्राफचा मी विकसक नसल्यास सबग्राफसाठी क्वेरी URL कसे शोधू?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+लक्षात ठेवा की तुम्ही API की तयार करू शकता आणि नेटवर्कवर प्रकाशित केलेल्या कोणत्याही सबग्राफची क्वेरी करू शकता, जरी तुम्ही स्वतः सबग्राफ तयार केला असला तरीही. नवीन API की द्वारे या क्वेरी, नेटवर्कवरील इतर कोणत्याही सशुल्क क्वेरी आहेत.

From 91989f936c72836e4e7c935468ac92dda86a3281 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:17 -0500
Subject: [PATCH 1878/3820] New translations subgraph-studio-faq.mdx (Hindi)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/hi/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/hi/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..9901cc26d73f
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: सबग्राफ स्टूडियो अक्सर पूछे जाने वाले प्रश्न
+---
+
+## 1. सबग्राफ स्टूडियो क्या है?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. मैं एक एपीआई कुंजी कैसे बना सकता हूँ?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. क्या मैं कई एपीआई कुंजियां बना सकता हूं?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. मैं एपीआई कुंजी के लिए डोमेन को कैसे प्रतिबंधित करूं?
+
+एपीआई key बनाने के बाद, सुरक्षा अनुभाग में, आप उन डोमेन को परिभाषित कर सकते हैं जो किसी विशिष्ट एपीआई key को क्वेरी कर सकते हैं।
+
+## 5. क्या मैं अपना सबग्राफ किसी अन्य स्वामी को स्थानांतरित कर सकता हूं?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+ध्यान दें कि एक बार स्थानांतरित हो जाने के बाद आप स्टूडियो में सबग्राफ को देख या संपादित नहीं कर पाएंगे।
+
+## 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+याद रखें कि आप एक एपीआई key बना सकते हैं और नेटवर्क पर प्रकाशित किसी सबग्राफ को क्वेरी कर सकते हैं, भले ही आप स्वयं एक सबग्राफ बनाते हों। नई एपीआई key के माध्यम से ये प्रश्न, नेटवर्क पर किसी अन्य के रूप में भुगतान किए गए प्रश्न हैं।

From d99cba1e95413165a2a70706d431d415a619405d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:18 -0500
Subject: [PATCH 1879/3820] New translations subgraph-studio-faq.mdx (Swahili)

---
 .../deploying/subgraph-studio-faq.mdx         | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/deploying/subgraph-studio-faq.mdx

diff --git a/website/pages/sw/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/sw/subgraphs/developing/deploying/subgraph-studio-faq.mdx
new file mode 100644
index 000000000000..8761f7a31bf6
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -0,0 +1,31 @@
+---
+title: Subgraph Studio FAQs
+---
+
+## 1. What is Subgraph Studio?
+
+[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+
+## 2. How do I create an API Key?
+
+To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+
+## 3. Can I create multiple API Keys?
+
+Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+
+## 4. How do I restrict a domain for an API Key?
+
+After creating an API Key, in the Security section, you can define the domains that can query a specific API Key.
+
+## 5. Can I transfer my subgraph to another owner?
+
+Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+
+Note that you will no longer be able to see or edit the subgraph in Studio once it has been transferred.
+
+## 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use?
+
+You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+
+Remember that you can create an API key and query any subgraph published to the network, even if you build a subgraph yourself. These queries via the new API key, are paid queries as any other on the network.

From 9522e53b4607b7ed25b477e1441052444ce8cc74 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:19 -0500
Subject: [PATCH 1880/3820] New translations using-subgraph-studio.mdx
 (Romanian)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/ro/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/ro/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..5aea3f59986b
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Create and manage your API keys for specific subgraphs
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get Started
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Subgraph Compatibility with The Graph Network
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- Must not use any of the following features:
+  - ipfs.cat & ipfs.map
+  - Non-fatal errors
+  - Grafting
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph Auth
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Automatic Archiving of Subgraph Versions
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 0dcbaa32d7e88c4869549dae4a95b88a60dde20d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:20 -0500
Subject: [PATCH 1881/3820] New translations using-subgraph-studio.mdx (French)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..93e302e70554
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Apprenez à déployer votre subgraph sur Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Présentation de Subgraph Studio
+
+Dans [Subgraph Studio](https://thegraph.com/studio/), vous pouvez faire ce qui suit:
+
+- Voir une liste des subgraphs que vous avez créés
+- Gérer, voir les détails et visualiser l'état d'un subgraph spécifique
+- Créez et gérez vos clés API pour des subgraphs spécifiques
+- Limitez vos clés API à des domaines spécifiques et autorisez uniquement certains Indexers à les utiliser pour effectuer des requêtes
+- Créer votre subgraph
+- Déployer votre subgraph en utilisant The Graph CLI
+- Tester votre subgraph dans l'environnement de test
+- Intégrer votre subgraph en staging en utilisant l'URL de requête du développement
+- Publier votre subgraph sur The Graph Network
+- Gérer votre facturation
+
+## Installer The Graph CLI
+
+Avant de déployer, vous devez installer The Graph CLI.
+
+Vous devez avoir [Node.js](https://nodejs.org/) et un gestionnaire de packages de votre choix (`npm`, `yarn` ou `pnpm`) installés pour utiliser The Graph CLI. Vérifiez la version la [plus récente](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) de l'outil CLI.
+
+### Installation avec yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Installation avec npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Commencer
+
+1. Ouvrez [Subgraph Studio](https://thegraph.com/studio/).
+2. Connectez votre portefeuille pour vous connecter.
+   - Vous pouvez le faire via MetaMask, Coinbase Wallet, WalletConnect ou Safe.
+3. Après vous être connecté, votre clé de déploiement unique sera affichée sur la page des détails de votre subgraph.
+   - La clé de déploiement vous permet de publier vos subgraphs ou de gérer vos clés d'API et votre facturation. Elle est unique mais peut être régénérée si vous pensez qu'elle a été compromise.
+
+> Important : Vous avez besoin d'une clé API pour interroger les subgraphs
+
+### Comment créer un subgraph dans Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Compatibilité des subgraphs avec le réseau de The Graph
+
+Pour être pris en charge par les Indexeurs sur The Graph Network, les subgraphs doivent :
+
+- Index a [supported network](/supported-networks/)
+- Ne doit utiliser aucune des fonctionnalités suivantes :
+  - ipfs.cat & ipfs.map
+  - Erreurs non fatales
+  - Greffage
+
+## Initialisez votre Subgraph
+
+Une fois que votre subgraph a été créé dans Subgraph Studio, vous pouvez initialiser son code via la CLI en utilisant cette commande :
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+Vous pouvez trouver la valeur `<SUBGRAPH_SLUG>` sur la page des détails de votre subgraph dans Subgraph Studio, voir l'image ci-dessous :
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+Après avoir exécuté la commande `graph init`, ilvous sera demandé de saisir l'adresse du contrat, le réseau, et un ABI que vous souhaitez interroger. Cela générera un nouveau dossier sur votre machine locale avec quelques codes de base pour commencer à travailler sur votre subgraph. Vous pouvez ensuite finaliser votre subgraph pour vous assurer qu'il fonctionne comme prévu.
+
+## Authentification The Graph
+
+Avant de pouvoir déployer votre subgraph sur Subgraph Studio, vous devez vous connecter à votre compte via la CLI. Pour le faire, vous aurez besoin de votre clé de déploiement, que vous pouvez trouver sur la page des détails de votre subgraph.
+
+Ensuite, utilisez la commande suivante pour vous authentifier depuis la CLI :
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Déploiement d'un Subgraph
+
+Une fois prêt, vous pouvez déployer votre subgraph sur Subgraph Studio.
+
+> Déployer un subgraph avec la CLI le pousse vers le Studio, où vous pouvez le tester et mettre à jour les métadonnées. Cette action ne publiera pas votre subgraph sur le réseau décentralisé.
+
+Utilisez la commande CLI suivante pour déployer votre subgraph :
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+Après avoir exécuté cette commande, la CLI demandera une étiquette de version.
+
+- Il est fortement recommandé d'utiliser [semver](https://semver.org/) pour le versionnage, comme `0.0.1`. Cela dit, vous êtes libre de choisir n'importe quelle chaîne de caractère comme version telle que v1, version1 ou asdf.
+- Les étiquettes que vous créez seront visibles dans Graph Explorer et pourront être utilisées par les Curateurs pour décider s'ils veulent signaler sur une version spécifique ou non, donc choisissez-les judicieusement.
+
+## Tester votre Subgraph
+
+Après le déploiement, vous pouvez tester votre subgraph (soit dans Subgraph Studio, soit dans votre propre application, avec l'URL de requête du déploiement), déployer une autre version, mettre à jour les métadonnées, et publier sur [Graph Explorer](https://thegraph.com/explorer) lorsque vous êtes prêt.
+
+Utilisez Subgraph Studio pour vérifier les journaux (logs) sur le tableau de bord et rechercher les erreurs éventuelles de votre subgraph.
+
+## Publiez votre subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versionning de votre subgraph avec le CLI
+
+Si vous souhaitez mettre à jour votre subgraph, vous pouvez faire ce qui suit :
+
+- Vous pouvez déployer une nouvelle version dans Studio en utilisant la CLI (cette version sera privée à ce stade).
+- Une fois que vous en êtes satisfait, vous pouvez publier votre nouveau déploiement sur [Graph Explorer](https://thegraph.com/explorer).
+- Cette action créera une nouvelle version de votre subgraph sur laquelle les Curateurs pourront commencer à signaler et que les Indexeurs pourront indexer.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Archivage automatique des versions de subgraphs
+
+Chaque fois que vous déployez une nouvelle version de subgraph dans Subgraph Studio, la version précédente sera archivée. Les versions archivées ne seront pas indexées/synchronisées et ne pourront donc pas être interrogées. Vous pouvez désarchiver une version de votre subgraph dans Subgraph Studio.
+
+> Remarque : les versions précédentes des subgraphs non publiés mais déployés dans Studio seront automatiquement archivées.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 833323c45924d69498b728ed1546f94eb48b1cb0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:21 -0500
Subject: [PATCH 1882/3820] New translations using-subgraph-studio.mdx
 (Spanish)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/es/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/es/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..c613f808a4ec
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Crear y gestionar sus claves API para subgrafos específicos
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Comenzar
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Compatibilidad de los Subgrafos con The Graph Network
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- No debe utilizar ninguna de las siguientes funciones:
+  - ipfs.cat & ipfs.map
+  - Errores no fatales
+  - Grafting
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph Auth
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Archivado Automático de Versiones de Subgrafos
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 2a81c6f6bf153ae6964203c6f19ac0a47e847193 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:22 -0500
Subject: [PATCH 1883/3820] New translations using-subgraph-studio.mdx (Arabic)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/ar/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/ar/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..541b6eb16f12
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- إنشاء وإدارة مفاتيح API الخاصة بك لـ subgraphs محددة
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get Started
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### توافق الـ Subgraph مع شبكة The Graph
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- يجب ألا تستخدم أيًا من الميزات التالية:
+  - ipfs.cat & ipfs.map
+  - أخطاء غير فادحة
+  - Grafting
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph Auth
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## الأرشفة التلقائية لإصدارات الـ Subgraph
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 7f380b0bd05452abf5eedf97fbe8d5c5f3cabafb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:23 -0500
Subject: [PATCH 1884/3820] New translations using-subgraph-studio.mdx (Czech)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/cs/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/cs/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..f29afdb9a55f
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Vytváření a správa klíčů API pro konkrétní podgrafy
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Začněte
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### Jak vytvořit podgraf v Podgraf Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Kompatibilita podgrafů se sítí grafů
+
+Aby mohly být podgrafy podporovány indexátory v síti grafů, musí:
+
+- Index a [supported network](/supported-networks/)
+- Nesmí používat žádnou z následujících funkcí:
+  - ipfs.cat & ipfs.map
+  - Nefatální
+  - Roubování
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Autorizace grafu
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Automatická archivace verzí podgrafů
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 27192dfb82de8b7e8efadf9abf272eeb4b7ea2b0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:24 -0500
Subject: [PATCH 1885/3820] New translations using-subgraph-studio.mdx (German)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..6bc3ea433d1f
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Erfahren Sie, wie Sie Ihren Subgraph in Subgraph Studio bereitstellen können.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Überblick
+
+In [Subgraph Studio] (https://thegraph.com/studio/) können Sie Folgendes tun:
+
+- Eine Liste der von Ihnen erstellten Subgraphs anzeigen
+- Verwalten, Anzeigen von Details und Visualisieren des Status eines bestimmten Subgraphen
+- Erstellen und verwalten Sie Ihre API-Schlüssel für bestimmte Subgraphen
+- Schränken Sie Ihre API-Schlüssel auf bestimmte Domains ein und erlauben Sie nur bestimmten Indexern die Abfrage mit diesen Schlüsseln
+- Erstellen Sie Ihren Subgraph
+- Verteilen Sie Ihren Subgraph mit The Graph CLI
+- Testen Sie Ihren Subgraph in der „Playground“-Umgebung
+- Integrieren Sie Ihren Subgraph in Staging unter Verwendung der Entwicklungsabfrage-URL
+- Veröffentlichen Sie Ihren Subgraph auf The Graph Network
+- Verwalten Sie Ihre Rechnungen
+
+## Installieren der Graph-CLI
+
+Vor der Bereitstellung müssen Sie The Graph CLI installieren.
+
+Sie müssen [Node.js](https://nodejs.org/) und einen Paketmanager Ihrer Wahl (`npm`, `yarn` oder `pnpm`) installiert haben, um The Graph CLI zu verwenden. Prüfen Sie, ob die [aktuellste](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI-Version installiert ist.
+
+### Installieren mit yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Installieren mit npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Los geht’s
+
+1. Öffnen Sie [Subgraph Studio] (https://thegraph.com/studio/).
+2. Verbinden Sie Ihre Wallet, um sich anzumelden.
+   - Sie können dies über MetaMask, Coinbase Wallet, WalletConnect oder Safe tun.
+3. Nachdem Sie sich angemeldet haben, wird Ihr eindeutiger Verteilungsschlüssel auf der Detailseite Ihres Subgraphen angezeigt.
+   - Mit dem Bereitstellungsschlüssel können Sie Ihre Subgraphs veröffentlichen oder Ihre API-Schlüssel und Abrechnungen verwalten. Er ist einmalig, kann aber neu generiert werden, wenn Sie glauben, dass er kompromittiert wurde.
+
+> Wichtig: Sie benötigen einen API-Schlüssel, um Subgraphs abzufragen
+
+### So erstellen Sie einen Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Kompatibilität von Subgraphs mit dem The Graph Network
+
+Um von Indexern auf The Graph Network unterstützt zu werden, müssen Subgraphen:
+
+- Index a [supported network](/supported-networks/)
+- Sie dürfen keine der folgenden Funktionen verwenden:
+  - ipfs.cat & ipfs.map
+  - Non-fatal errors
+  - Grafting
+
+## Initialisieren Ihres Subgraphen
+
+Sobald Ihr Subgraph in Subgraph Studio erstellt wurde, können Sie seinen Code über die CLI mit diesem Befehl initialisieren:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+Sie finden den Wert `<SUBGRAPH_SLUG>` auf der Detailseite Ihres Subgraphs in Subgraph Studio, siehe Abbildung unten:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+Nachdem Sie `graph init` ausgeführt haben, werden Sie aufgefordert, die Vertragsadresse, das Netzwerk und eine ABI einzugeben, die Sie abfragen möchten. Daraufhin wird ein neuer Ordner auf Ihrem lokalen Rechner erstellt, der einige grundlegende Codes enthält, um mit der Arbeit an Ihrem Subgraph zu beginnen. Anschließend können Sie Ihren Subgraph fertigstellen, um sicherzustellen, dass er wie erwartet funktioniert.
+
+## Graph Auth
+
+Bevor Sie Ihren Subgraph in Subgraph Studio bereitstellen können, müssen Sie sich bei Ihrem Konto in der CLI anmelden. Dazu benötigen Sie Ihren Bereitstellungsschlüssel, den Sie auf der Seite mit den Details Ihres Subgraphen finden.
+
+Verwenden Sie dann den folgenden Befehl, um sich über die CLI zu authentifizieren:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Bereitstellen eines Subgraphs
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Automatic Archiving of Subgraph Versions
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From e811df5ddd18bc41d0e940a6e5e5f6f8c57cae64 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:25 -0500
Subject: [PATCH 1886/3820] New translations using-subgraph-studio.mdx
 (Italian)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/it/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/it/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..6e6bf910d246
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Creare e gestire le chiavi API per specifici subgraph
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Iniziare
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### Come creare un subgraph nel Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Compatibilità del subgraph con The Graph Network
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- Non deve utilizzare nessuna delle seguenti funzioni:
+  - ipfs.cat & ipfs.map
+  - Errori non fatali
+  - Grafting
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph Auth
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Archiviazione automatica delle versioni del subgraph
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From f1acb7808ef585f42db7fe25978b818947204f53 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:26 -0500
Subject: [PATCH 1887/3820] New translations using-subgraph-studio.mdx
 (Japanese)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/ja/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/ja/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..2087f539902c
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- 特定のサブグラフ用の API キーの作成と管理
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## 始めましょう
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### Subgraph Studio でサブグラフを作成する方法
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Subgraph と The Graph Network の互換性
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- 以下の機能のいずれも使用してはいけません:
+  - ipfs.cat & ipfs.map
+  - 致命的でないエラー
+  - Grafting
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## グラフ認証
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## サブグラフのバージョンの自動アーカイブ
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 7f513bfa5a49d32df595b8df07881b4f2b9a7c1f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:28 -0500
Subject: [PATCH 1888/3820] New translations using-subgraph-studio.mdx (Korean)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/ko/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/ko/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..5aea3f59986b
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Create and manage your API keys for specific subgraphs
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get Started
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Subgraph Compatibility with The Graph Network
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- Must not use any of the following features:
+  - ipfs.cat & ipfs.map
+  - Non-fatal errors
+  - Grafting
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph Auth
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Automatic Archiving of Subgraph Versions
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 9fdf831aeecf6e4260287b004c37df713eee657e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:29 -0500
Subject: [PATCH 1889/3820] New translations using-subgraph-studio.mdx (Dutch)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/nl/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/nl/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..c83cd5a22f10
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Create and manage your API keys for specific subgraphs
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Begin
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Subgraph Compatibility with The Graph Network
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- Must not use any of the following features:
+  - ipfs.cat & ipfs.map
+  - Non-fatal errors
+  - Grafting
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph Auth
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Automatic Archiving of Subgraph Versions
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From de20c7158669c5b5775047cd4456bf1ba125cf1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:30 -0500
Subject: [PATCH 1890/3820] New translations using-subgraph-studio.mdx (Polish)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/pl/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/pl/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..e64bd1e9ee7a
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Create and manage your API keys for specific subgraphs
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Jak zacząć?
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Subgraph Compatibility with The Graph Network
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- Must not use any of the following features:
+  - ipfs.cat & ipfs.map
+  - Non-fatal errors
+  - Grafting
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph Auth
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Automatic Archiving of Subgraph Versions
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From c082eff09ff95df44b4cae2b43787624df13294b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:31 -0500
Subject: [PATCH 1891/3820] New translations using-subgraph-studio.mdx
 (Portuguese)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/pt/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/pt/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..43b2acf07791
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Criar e gerir as suas chaves de API para subgraphs específicos
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Como Começar
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### Como Criar um Subgraph no Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Compatibilidade de Subgraph com a Graph Network
+
+Para ter apoio de Indexadores na Graph Network, os subgraphs devem:
+
+- Index a [supported network](/supported-networks/)
+- Não deve usar quaisquer das seguintes características:
+  - ipfs.cat & ipfs.map
+  - Erros não-fatais
+  - Enxertos
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Autenticação
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Arquivamento Automático de Versões de Subgraphs
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 5a33dc8c875ad0521d16c1cd03e21c5c35f99b35 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:32 -0500
Subject: [PATCH 1892/3820] New translations using-subgraph-studio.mdx
 (Russian)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/ru/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/ru/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..e17d0a91f706
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Узнайте, как развернуть свой субграф в Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Обзор Subgraph Studio
+
+В [Subgraph Studio](https://thegraph.com/studio/) Вы можете выполнять следующие действия:
+
+- Просматривать список созданных Вами субграфов
+- Управлять, просматривать детали и визуализировать статус конкретного субграфа
+- Создание и управление ключами API для определенных подграфов
+- Ограничивать использование своих API-ключей определенными доменами и разрешать только определенным индексаторам выполнять запросы с их помощью
+- Создавать свой субграф
+- Развертывать свой субграф, используя The Graph CLI
+- Тестировать свой субграф в тестовой среде Playground
+- Интегрировать свой субграф на стадии разработки, используя URL запроса разработки
+- Публиковать свой субграф в The Graph Network
+- Управлять своими платежами
+
+## Установка The Graph CLI
+
+Перед развертыванием необходимо установить The Graph CLI.
+
+Для использования The Graph CLI у Вас должны быть установлены [Node.js](https://nodejs.org/) и менеджер пакетов на Ваш выбор (`npm`, `yarn` или `pnpm`). Проверьте у себя наличие [самой последней](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) версии CLI.
+
+### Установка с помощью yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Установка с помощью npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Начнем
+
+1. Откройте [Subgraph Studio](https://thegraph.com/studio/).
+2. Подключите свой кошелек для входа.
+   - Вы можете это сделать через MetaMask, Coinbase Wallet, WalletConnect или Safe.
+3. После входа в систему Ваш уникальный ключ развертывания будет отображаться на странице сведений о Вашем субграфе.
+   - Ключ развертывания позволяет публиковать субграфы, а также управлять вашими API-ключами и оплатой. Он уникален, но может быть восстановлен, если Вы подозреваете, что он был взломан.
+
+> Важно: для выполнения запросов к субграфам необходим API-ключ
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Совместимость подграфов с сетью Graph
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- Не должны использовать ни одну из следующих функций:
+  - ipfs.cat & ipfs.map
+  - Нефатальные ошибки
+  - Grafting
+
+## Инициализация Вашего Субграфа
+
+После создания субграфа в Subgraph Studio Вы можете инициализировать его код через CLI с помощью следующей команды:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+Значение `<SUBGRAPH_SLUG>` можно найти на странице сведений о субграфе в Subgraph Studio, см. изображение ниже:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+После запуска `graph init` Вам будет предложено ввести адрес контракта, сеть и ABI, которые Вы хотите запросить. Это приведет к созданию новой папки на Вашем локальном компьютере с базовым кодом для начала работы над субграфом. Затем Вы можете завершить работу над своим субграфом, чтобы убедиться, что он функционирует должным образом.
+
+## Аутентификация в Graph
+
+Прежде чем Вы сможете развернуть свой субграф в Subgraph Studio, Вам будет необходимо войти в свою учетную запись в CLI. Для этого Вам понадобится ключ развертывания, который Вы сможете найти на странице сведений о субграфе.
+
+После этого используйте следующую команду для аутентификации через CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Развертывание субграфа
+
+Когда будете готовы, Вы сможете развернуть свой субграф в Subgraph Studio.
+
+> Развертывание субграфа с помощью CLI отправляет его в Studio, где Вы сможете протестировать его и обновить метаданные. Это действие не приводит к публикации субграфа в децентрализованной сети.
+
+Используйте следующую команду CLI для развертывания своего субграфа:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+После выполнения этой команды CLI запросит метку версии.
+
+- Настоятельно рекомендуется использовать [semver](https://semver.org/) для управления версиями типа `0.0.1`. При этом Вы можете выбрать любую строку в качестве версии, например: `v1`, `version1` или `asdf`.
+- Созданные вами метки будут видны в Graph Explorer, и кураторы смогут использовать их для принятия решения, сигнализировать на определенную версию или нет, поэтому выбирайте метки с умом.
+
+## Тестирование Вашего субграфа
+
+После развертывания Вы можете протестировать свой субграф (в Subgraph Studio или в собственном приложении, используя URL-адрес запроса на развертывание), развернуть другую версию, обновить метаданные и, когда будете готовы, опубликовать в [Graph Explorer](https://thegraph.com/explorer).
+
+Используйте Subgraph Studio, чтобы проверить логи на панели управления и обнаружить возможные ошибки в своем субграфе.
+
+## Публикация Вашего субграфа
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Управление версиями Вашего субграфа с помощью CLI
+
+Если Вы хотите обновить свой субграф, Вы можете сделать следующее:
+
+- Вы можете развернуть новую версию в Studio, используя CLI (на этом этапе она будет только приватной).
+- Если результат Вас устроит, Вы можете опубликовать новое развертывание в [Graph Explorer](https://thegraph.com/explorer).
+- Это действие создаст новую версию вашего субграфа, о которой Кураторы смогут начать сигнализировать, а Индексаторы — индексировать.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Автоматическое архивирование версий подграфа
+
+Каждый раз, когда Вы развертываете новую версию субграфа в Subgraph Studio, предыдущая версия архивируется. Архивированные версии не будут проиндексированы/синхронизированы и, следовательно, их нельзя будет запросить. Вы можете разархивировать архивированную версию своего субграфа в Subgraph Studio.
+
+> Примечание: предыдущие версии непубликованных субграфов, развернутых в Studio, будут автоматически архивированы.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 961908ef58b5939d3acfac0aec5cfc3d23cf85db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:33 -0500
Subject: [PATCH 1893/3820] New translations using-subgraph-studio.mdx
 (Swedish)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/sv/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/sv/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..3f5e6b3af34a
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Skapa och hantera API nycklar för specifika undergrafer
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Komma igång
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### Hur man skapar en subgraf i Subgraf Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Kompatibilitet mellan undergrafer och grafnätet
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- Får inte använda någon av följande egenskaper:
+  - ipfs.cat & ipfs.map
+  - Icke dödliga fel
+  - Ympning
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Auth för grafer
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Automatisk arkivering av versioner av undergrafer
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 80fb135cedb307265fb9e2d7f09d62e22dbb4e42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:34 -0500
Subject: [PATCH 1894/3820] New translations using-subgraph-studio.mdx
 (Turkish)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/tr/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/tr/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..2d04432740f2
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Subgraph'inizi Subgraph Studio'da dağıtma adımlarını öğrenin.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio'ya Genel Bakış
+
+[Subgraph Studio](https://thegraph.com/studio/)'da aşağıdakileri yapabilirsiniz:
+
+- Oluşturmuş olduğunuz sugraph'lerin listesini görüntülemek
+- Belirli bir subgraph'i yönetmek, subgraph'in detaylarını görmek ve durumunu görüntülemek
+- Belirli subgraph'ler için API anahtarlarınızı oluşturmak ve yönetmek
+- API anahtarlarınızı belirli alanlara sınırlamak ve yalnızca belirli Endeksleyicilerin bu anahtarlarla sorgulama yapmasına izin vermek
+- Subgraph'inizi oluşturmak
+- Subgraph'inizi The Graph CLI'yi kullanarak dağıtmak
+- Subgraph'inizi playground ortamında test etmek
+- Geliştirme sorgu URL'sini kullanarak subgraph’inizi hazırlama ortamına entegre etmek
+- Subgraph'inizi The Graph Ağında yayımlamak
+- Faturalarınızı yönetmek
+
+## The Graph CLI'yi Yükleme
+
+Dağıtmadan önce The Graph CLI'yi yüklemeniz gerekmektedir.
+
+The Graph CLI'yi kullanmak için bilgisayarınızda [Node.js](https://nodejs.org/) ve tercih ettiğiniz bir paket yöneticisi (`npm`, `yarn` veya `pnpm`) kurulu olmalıdır. CLI'ın [en son](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) sürümünü kontrol edin.
+
+### yarn ile kurulum
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### npm ile kurulum
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Başlayalım
+
+1. [Subgraph Studio](https://thegraph.com/studio/)'yu açın.
+2. Giriş yapmak için cüzdanınızı bağlayın.
+   - Cüzdan bağlamak için MetaMask, Conbase Wallet, WalletConnect ya da Safe kullanabilirsiniz.
+3. Giriş yaptıktan sonra, benzersiz yayına alma anahtarınız subgraph ayrıntıları sayfasında görünecektir.
+   - Dağıtma anahtarınız subgraph'lerinizi yayımlamanızı veya API anahtarlarınızı ve faturanızı yönetmenizi sağlar. Dağıtma anahtarınız benzersizdir; ancak anahtarınızın ele geçirildiğini düşünüyorsanız bu anahtarı yeniden yaratabilirsiniz.
+
+> Önemli not: Subgraph'leri sorgulamak için bir API anahtarına sahip olmanız gerekmektedir
+
+### Subgraph Stüdyo'da Subgraph Nasıl Oluşturulur
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### The Graph Ağı ile Subgraph Uyumluluğu
+
+Subgraph'lerin Graph Ağı Endeksleyicileri tarafından desteklenebilmesi için şu gereklilikleri karşılaması gerekir:
+
+- Index a [supported network](/supported-networks/)
+- Aşağıdaki özelliklerden hiçbirini kullanmamalı:
+  - ipfs.cat & ipfs.map
+  - Ölümcül Olmayan Hatalar
+  - Graftlama
+
+## Subgraph'inizi İlklendirme
+
+Subgraph’iniz Subgraph Studio’da oluşturulduktan sonra, aşağıdaki komutla CLI üzerinden subgraph kodunu ilklendirebilirsiniz:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+`<SUBGRAPH_SLUG>` değerini Subgraph Studio’daki subgraph ayrıntı sayfanızda bulabilirsiniz; aşağıdaki resme bakın:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+`graph init` komutunu çalıştırdıktan sonra sorgulamak istediğiniz kontrat adresini, ağı ve ABI’yi girmeniz istenecektir. Bu komut, yerel makinenizde subgraph’inizle çalışmaya başlamanız için bazı temel kodları içeren yeni bir klasör oluşturacaktır. Sonrasında subgraph'inizi işlevselliğini test ederek nihayetlendirebilirsiniz.
+
+## Graph Auth
+
+Subgraph’inizi Subgraph Studio’da yayına alabilmek için önce CLI üzerinden hesabınıza giriş yapmanız gerekmektedir. Bunun için, subgraph ayrıntıları sayfanızda bulabileceğiniz yayına alma anahtarınıza ihtiyacınız olacak.
+
+CLI üzerinden kimlik doğrulaması yapmak için aşağıdaki komutu kullanın:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Bir Subgraph’i Dağıtma
+
+Hazır olduğunuzda subgraph’inizi Subgraph Studio’da dağıtabilirsiniz.
+
+> CLI ile bir subgraph dağıtmak, onu Studio’ya iletir; burada subgraph'i test edip meta verilerini güncelleyebilirsiniz. Bu işlem, subgraph’inizi merkeziyetsiz ağda yayımlamaz.
+
+Subgraph’inizi dağıtmak için aşağıdaki CLI komutunu kullanın:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+Bu komutu çalıştırdıktan sonra CLI sizden bir sürüm etiketi isteyecektir.
+
+- Sürüm etiketlemede [semver](https://semver.org/) (örn. 0.0.1) kullanmanız tavsiye edilir. Ancak `v1`, `version1` veya `asfdf` gibi başka bir dize de seçebilirsiniz.
+- Oluşturduğunuz etiketler Graph Gezgini'nde görünür olacak. Küratörler bu etiketlere göre belirli bir sürüme sinyal verip vermemeyi kararlaştırabilirler; bu nedenle seçimlerinizi dikkatle yapın.
+
+## Subgraph’inizi Test Etme
+
+Yayına aldıktan sonra, subgraph’inizi (Subgraph Studio’da veya sorgu URL’si ile kendi uygulamanızda) test edebilir, yeni bir sürüm yayına alabilir, meta verileri güncelleyebilir ve hazır olduğunuzda [Graph Gezgini](https://thegraph.com/explorer)'nde yayımlayabilirsiniz.
+
+Subgraph Studio’da günlükleri kontrol ederek subgraph’inizle ilgili hataları görebilirsiniz.
+
+## Subgraph’inizi Yayımlama
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## CLI ile Subgraph’inizi Sürümleme
+
+Subgraph’inizi güncellemek isterseniz, aşağıdaki adımları izleyebilirsiniz:
+
+- CLI kullanarak Studio’da yeni bir sürüm dağıtabilirsiniz (bu sürüm yalnızca özel olarak kalacaktır).
+- Memnun kaldığınızda, yeni dağıtımınızı [Graph Gezgini](https://thegraph.com/explorer)'nde yayımlayabilirsiniz.
+- Bu işlem, küratörlerin sinyal vermeye başlayabileceği ve Endeksleyicilerin endeksleyebileceği, subgraph'inizin yeni bir sürümünü oluşturur.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Subgraph Sürümlerinin Otomatik Arşivlenmesi
+
+Subgraph Studio’da yeni bir subgraph sürümü yayına aldığınızda, önceki sürüm arşivlenecektir. Arşivlenen sürümler endekslenmez/senkronize edilmez ve bu nedenle sorgulanamaz. Subgraph’inizin arşivlenen bir sürümünü Subgraph Studio'da arşivden çıkarabilirsiniz.
+
+> Not: Studio’da yayına alınan ancak yayımlanmamış subgraph'lerin önceki sürümlerinin otomatik olarak arşivlenecektir.
+
+![Subgraph Studio - Arşivden Çıkarma](/img/Unarchive.png)

From 63b23b4dd3bcc335f6fabd7ab775dd15f4df61a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:35 -0500
Subject: [PATCH 1895/3820] New translations using-subgraph-studio.mdx
 (Ukrainian)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/uk/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/uk/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..734f0ff310a6
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Create and manage your API keys for specific subgraphs
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Розпочати роботу
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Subgraph Compatibility with The Graph Network
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- Must not use any of the following features:
+  - ipfs.cat & ipfs.map
+  - Non-fatal errors
+  - Grafting
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph Auth
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Automatic Archiving of Subgraph Versions
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From efe6a633568c08d6779320583a0fdaa84157eb67 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:36 -0500
Subject: [PATCH 1896/3820] New translations using-subgraph-studio.mdx (Chinese
 Simplified)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/zh/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/zh/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..1af5b20335fc
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- 为特定子图创建和管理 API 密钥
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## 开始
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### 如何在子图工作室中创建子图
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### 子图与图形网络的兼容性
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- 不得使用以下任何功能：
+  - ipfs.cat & ipfs.map
+  - 非致命错误
+  - 嫁接
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph 认证
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## 子图版本的自动归档
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 26534c86637aeba8a0fa0268cc77c2b860a24f75 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:37 -0500
Subject: [PATCH 1897/3820] New translations using-subgraph-studio.mdx (Urdu
 (Pakistan))

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/ur/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/ur/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..53a8fd587b08
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- مخصوص سب گرافس کے لۓ API کیز بنائیں اور ان کا انتظام کریں
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## شروع کریں
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### گراف نیٹ ورک کے ساتھ سب گراف مطابقت
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- درج ذیل خصوصیات میں سے کوئی بھی استعمال نہیں کرنا چاہیے:
+  - ipfs.cat & ipfs.map
+  - Non-fatal errors
+  - گرافٹنگ
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph Auth
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## سب گراف ورژن کی خودکار آرکائیونگ
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 54f2b9badd5edabf9832f050b930f32b09e3383a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:38 -0500
Subject: [PATCH 1898/3820] New translations using-subgraph-studio.mdx
 (Vietnamese)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/vi/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/vi/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..5f2dd8d22f5c
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Create and manage your API keys for specific subgraphs
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Bắt đầu
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Subgraph Compatibility with The Graph Network
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- Must not use any of the following features:
+  - ipfs.cat & ipfs.map
+  - Lỗi không nghiêm trọng
+  - Ghép
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph Auth
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Automatic Archiving of Subgraph Versions
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From ae3ce02ea23d0d3452904ccc0c66ab62752ce7c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:39 -0500
Subject: [PATCH 1899/3820] New translations using-subgraph-studio.mdx
 (Marathi)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/mr/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/mr/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..562bb233cfe5
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- विशिष्ट सबग्राफसाठी तुमच्या API की तयार करा आणि व्यवस्थापित करा
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## सुरु करूया
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### ग्राफ नेटवर्कसह सबग्राफ सुसंगतता
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- खालीलपैकी कोणतीही वैशिष्ट्ये वापरू नयेत:
+  - ipfs.cat & ipfs.map
+  - गैर-घातक त्रुटी
+  - कलम करणे
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## आलेख प्रमाणीकरण
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## सबग्राफ आवृत्त्यांचे स्वयंचलित संग्रहण
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 78e88ba84070d32bae3e27e593a7088d3ec8a3d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:40 -0500
Subject: [PATCH 1900/3820] New translations using-subgraph-studio.mdx (Hindi)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/hi/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/hi/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..729136d7d90e
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+अपने subgraph को Subgraph Studio में डिप्लॉय करना सीखें।
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio का अवलोकन
+
+In <a href="https://thegraph.com/studio/">Subgraph Studio</a>,आप निम्नलिखित कर सकते हैं:
+
+- आपने बनाए गए subgraphs की सूची देखें
+- एक विशेष subgraph की स्थिति को प्रबंधित करें, विवरण देखें और दृश्य रूप में प्रदर्शित करें
+- विशिष्ट सबग्राफ के लिए अपनी एपीआई keys बनाएं और प्रबंधित करें
+- अपने API कुंजी को विशेष डोमेन तक सीमित करें और केवल कुछ Indexers को उनके साथ क्वेरी करने की अनुमति दें
+- अपना subgraph बनाएं
+- अपने subgraph को The Graph CLI का उपयोग करके डिप्लॉय करें
+- अपने 'subgraph' को 'playground' वातावरण में टेस्ट करें
+- अपने स्टेजिंग में 'subgraph' को विकास क्वेरी URL का उपयोग करके एकीकृत करें 
+- अपने subgraph को The Graph Network पर प्रकाशित करें
+- अपने बिलिंग को प्रबंधित करें
+
+## The Graph CLI स्थापित करें
+
+Deploy करने से पहले, आपको The Graph CLI इंस्टॉल करना होगा।
+
+आपको The Graph CLI का उपयोग करने के लिए Node.js(https://nodejs.org/)  और आपकी पसंद का पैकेज मैनेजर (npm, yarn या pnpm) स्थापित होना चाहिए। सबसे हालिया (https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI संस्करण की जांच करें।
+
+### इंस्टॉल करें 'yarn' के साथ
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### इंस्टॉल करें 'npm' के साथ
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get Started
+
+1. खोलें [Subgraph Studio](https://thegraph.com/studio/).
+2. अपने वॉलेट से साइन इन करें।
+   - आप इसे MetaMask, Coinbase Wallet, WalletConnect, या Safe के माध्यम से कर सकते हैं।
+3. साइन इन करने के बाद, आपका यूनिक डिप्लॉय की आपकी subgraph विवरण पृष्ठ पर प्रदर्शित होगा।
+   - Deploy key आपको अपने subgraphs को प्रकाशित करने या अपने API keys और billing को प्रबंधित करने की अनुमति देता है। यह अद्वितीय है लेकिन यदि आपको लगता है कि यह समझौता किया गया है, तो इसे पुनः उत्पन्न किया जा सकता है।
+
+> महत्वपूर्ण: आपको subgraphs को क्वेरी करने के लिए एक API कुंजी की आवश्यकता है
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### ग्राफ नेटवर्क के साथ सबग्राफ अनुकूलता
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- निम्नलिखित सुविधाओं में से किसी का उपयोग नहीं करना चाहिए:
+  - ipfs.cat & ipfs.map
+  - गैर-घातक त्रुटियाँ
+  - ग्राफ्टिंग
+
+## अपने Subgraph को प्रारंभ करें
+
+एक बार जब आपका subgraph Subgraph Studio में बना दिया गया है, तो आप इस कमांड का उपयोग करके CLI के माध्यम से इसके कोड को प्रारंभ कर सकते हैं:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+आप `<SUBGRAPH_SLUG>` मान को अपने subgraph विवरण पृष्ठ पर Subgraph Studio में पा सकते हैं, नीचे दी गई छवि देखें:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+`graph init` चलाने के बाद, आपसे संपर्क पता, नेटवर्क, और एक ABI इनपुट करने के लिए कहा जाएगा जिसे आप क्वेरी करना चाहते हैं। यह आपके स्थानीय मशीन पर एक नया फोल्डर उत्पन्न करेगा जिसमें आपके Subgraph पर काम करना शुरू करने के लिए कुछ मूल कोड होगा। आप फिर अपने Subgraph को अंतिम रूप दे सकते हैं ताकि यह सुनिश्चित किया जा सके कि यह अपेक्षित रूप से काम करता है।
+
+## ग्राफ प्रमाणीकरण
+
+अपने subgraph को Subgraph Studio पर डिप्लॉय करने से पहले, आपको CLI के भीतर अपने खाते में लॉग इन करना होगा। ऐसा करने के लिए, आपको अपना deploy key चाहिए होगा, जिसे आप अपने subgraph विवरण पृष्ठ के तहत पा सकते हैं।
+
+फिर, CLI से प्रमाणित करने के लिए निम्नलिखित आदेश का उपयोग करें:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Subgraph डिप्लॉय करना
+
+जब आप तैयार हों, तो आप अपना subgraph को Subgraph Studio पर डिप्लॉय कर सकते हैं।
+
+> CLI का उपयोग करके subgraph को डिप्लॉय करना उसे Studio में पुश करता है, जहां आप इसे टेस्ट कर सकते हैं और मेटाडेटा को अपडेट कर सकते हैं। यह क्रिया आपके subgraph को विकेंद्रीकृत नेटवर्क पर प्रकाशित नहीं करेगी।
+
+निम्नलिखित CLI कमांड का उपयोग करके अपना subgraph डिप्लॉय करें:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+यह कमांड चलाने के बाद, CLI एक वर्शन लेबल मांगेगा।
+
+- यह दृढ़ता से अनुशंसा की जाती है कि वर्शनिंग के लिए semver(https://semver.org/) का उपयोग किया जाए जैसे 0.0.1। फिर भी, आप किसी भी स्ट्रिंग को वर्शन के रूप में चुनने के लिए स्वतंत्र हैं जैसे v1, version1, या asdf।
+- जो लेबल आप बनाएंगे, वे Graph Explorer में दिखाई देंगे और Curators द्वारा उपयोग किए जा सकते हैं ताकि वे यह निर्णय ले सकें कि वे किसी विशेष संस्करण पर संकेत देना चाहते हैं या नहीं, इसलिए उन्हें सोच-समझकर चुनें।
+
+## अपने Subgraph का परीक्षण करें
+
+डिप्लॉय करने के बाद, आप अपने subgraph का परीक्षण कर सकते हैं (या तो Subgraph Studio में या अपने ऐप में, डिप्लॉयमेंट क्वेरी URL के साथ), एक और संस्करण डिप्लॉय करें, मेटाडेटा को अपडेट करें, और जब आप तैयार हों, तो Graph Explorer(https://thegraph.com/explorer) पर प्रकाशित करें।
+
+Subgraph Studio का उपयोग करके डैशबोर्ड पर लॉग्स की जांच करें और अपने subgraph के साथ किसी भी त्रुटियों की तलाश करें।
+
+## अपने Subgraph को प्रकाशित करें
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## अपने Subgraph को CLI के साथ संस्करण बनाना
+
+यदि आप अपने subgraph को अपडेट करना चाहते हैं, तो आप निम्नलिखित कर सकते हैं:
+
+- आप स्टूडियो में CLI का उपयोग करके एक नया संस्करण डिप्लॉय कर सकते हैं (इस समय यह केवल निजी होगा)।
+- एक बार जब आप इससे संतुष्ट हो जाएं, तो आप अपने नए डिप्लॉयमेंट को Graph Explorer(https://thegraph.com/explorer). पर प्रकाशित कर सकते हैं।
+- यह क्रिया आपके नए संस्करण का निर्माण करेगी जिसे Curators सिग्नल करना शुरू कर सकते हैं और Indexers अनुक्रमित कर सकते हैं।
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## सबग्राफ संस्करणों का स्वचालित संग्रह
+
+जब भी आप Subgraph Studio में एक नया subgraph संस्करण डिप्लॉय करते हैं, तो पिछले संस्करण को आर्काइव कर दिया जाएगा। आर्काइव किए गए संस्करणों को इंडेक्स/सिंक नहीं किया जाएगा और इसलिए उन्हें क्वेरी नहीं किया जा सकता। आप Subgraph Studio में अपने subgraph के आर्काइव किए गए संस्करण को अनआर्काइव कर सकते हैं।
+
+> नोट: स्टूडियो में डिप्लॉय किए गए गैर-प्रकाशित subgraphs के पिछले संस्करणों को स्वचालित रूप से आर्काइव किया जाएगा।
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 2ff10f4434f6bf0d503560f2189b917e5235e8d6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:41 -0500
Subject: [PATCH 1901/3820] New translations using-subgraph-studio.mdx
 (Swahili)

---
 .../deploying/using-subgraph-studio.mdx       | 137 ++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/deploying/using-subgraph-studio.mdx

diff --git a/website/pages/sw/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/sw/subgraphs/developing/deploying/using-subgraph-studio.mdx
new file mode 100644
index 000000000000..5aea3f59986b
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -0,0 +1,137 @@
+---
+title: Deploying Using Subgraph Studio
+---
+
+Learn how to deploy your subgraph to Subgraph Studio.
+
+> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+
+## Subgraph Studio Overview
+
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Create and manage your API keys for specific subgraphs
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
+
+## Install The Graph CLI
+
+Before deploying, you must install The Graph CLI.
+
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+
+### Install with yarn
+
+```bash
+yarn global add @graphprotocol/graph-cli
+```
+
+### Install with npm
+
+```bash
+npm install -g @graphprotocol/graph-cli
+```
+
+## Get Started
+
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+
+> Important: You need an API key to query subgraphs
+
+### How to Create a Subgraph in Subgraph Studio
+
+<VideoEmbed youtube="nGIFuC69bSA" />
+
+> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+
+### Subgraph Compatibility with The Graph Network
+
+In order to be supported by Indexers on The Graph Network, subgraphs must:
+
+- Index a [supported network](/supported-networks/)
+- Must not use any of the following features:
+  - ipfs.cat & ipfs.map
+  - Non-fatal errors
+  - Grafting
+
+## Initialize Your Subgraph
+
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+
+```bash
+graph init <SUBGRAPH_SLUG>
+```
+
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+
+![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
+
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+
+## Graph Auth
+
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+
+Then, use the following command to authenticate from the CLI:
+
+```bash
+graph auth <DEPLOY KEY>
+```
+
+## Deploying a Subgraph
+
+Once you are ready, you can deploy your subgraph to Subgraph Studio.
+
+> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+
+Use the following CLI command to deploy your subgraph:
+
+```bash
+graph deploy <SUBGRAPH_SLUG>
+```
+
+After running this command, the CLI will ask for a version label.
+
+- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
+- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+
+## Testing Your Subgraph
+
+After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+
+Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+
+## Publish Your Subgraph
+
+In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+## Versioning Your Subgraph with the CLI
+
+If you want to update your subgraph, you can do the following:
+
+- You can deploy a new version to Studio using the CLI (it will only be private at this point).
+- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
+- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+
+You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+
+> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+
+## Automatic Archiving of Subgraph Versions
+
+Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+
+> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+
+![Subgraph Studio - Unarchive](/img/Unarchive.png)

From cc0e2a1e133a9f262a8261b133695495b92d61f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:42 -0500
Subject: [PATCH 1902/3820] New translations developer-faq.mdx (Romanian)

---
 .../ro/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/ro/subgraphs/developing/developer-faq.mdx b/website/pages/ro/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..2a027a39d2c6
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. What is a subgraph?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Can I change the GitHub account associated with my subgraph?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+You have to redeploy the subgraph, but if the subgraph ID (IPFS hash) doesn't change, it won't have to sync from the beginning.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Within a subgraph, the events are always processed in the order they appear in the blocks, regardless of whether that is across multiple contracts or not.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+You can run the following command:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Yes! Try the following command, substituting "organization/subgraphName" with the organization under it is published and the name of your subgraph:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 8694b0af5e013cb3eeb6681616b74f1b481d265c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:43 -0500
Subject: [PATCH 1903/3820] New translations developer-faq.mdx (French)

---
 .../fr/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/fr/subgraphs/developing/developer-faq.mdx b/website/pages/fr/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..ce99dc6f5cdf
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+Cette page résume certaines des questions les plus courantes pour les développeurs construisant sur The Graph.
+
+## Relatif aux Subgraphs
+
+### 1. Qu'est-ce qu'un subgraph ?
+
+Un subgraph est une API personnalisée construite sur des données blockchain. Les subgraphs sont interrogés en utilisant le langage de requête GraphQL et sont déployés sur Graph Node en utilisant Graph CLI. Une fois déployés et publiés sur le réseau décentralisé de The Graph, les Indexeurs traitent les subgraphs et les rendent disponibles pour que les consommateurs de subgraphs puissent les interroger.
+
+### 2. Quelle est la première étape pour créer un subgraph ?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Suis-je toujours en mesure de créer un subgraph si mes smart contracts n'ont pas d'événements ?
+
+Il est fortement recommandé de structurer vos smart contracts pour avoir des événements associés aux données que vous souhaitez interroger. Les gestionnaires d'événements du subgraph sont déclenchés par des événements de contrat et constituent le moyen le plus rapide de récupérer des données utiles.
+
+Si les contrats avec lesquels vous travaillez ne contiennent pas d'événements, votre subgraph peut utiliser des gestionnaires d'appels et de blocs pour déclencher l'indexation. Cependant, ceci n'est pas recommandé, car les performances seront nettement plus lentes.
+
+### 4. Puis-je modifier le compte GitHub associé à mon subgraph ?
+
+Non. Une fois un subgraph créé, le compte GitHub associé ne peut pas être modifié. Veuillez vous assurer de bien prendre en compte ce détail avant de créer votre subgraph.
+
+### 5. Comment mettre à jour un subgraph sur le mainnet ?
+
+Vous pouvez déployer une nouvelle version de votre subgraph sur Subgraph Studio en utilisant la CLI. Cette action maintient votre subgraph privé, mais une fois que vous en êtes satisfait, vous pouvez le publier sur Graph Explorer. Cela créera une nouvelle version de votre subgraph sur laquelle les Curateurs pourront commencer à signaler.
+
+### 6. Est-il possible de dupliquer un subgraph vers un autre compte ou endpoint sans le redéployer ?
+
+Vous devez redéployer le subgraph, mais si l'ID de subgraph (hachage IPFS) ne change pas, il n'aura pas à se synchroniser depuis le début.
+
+### 7. Comment puis-je appeler une fonction d'un contrat ou accéder à une variable d'état publique depuis mes mappages de subgraph ?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Actuellement non, car les mappages sont écrits en AssemblyScript.
+
+Une solution alternative possible serait de stocker des données brutes dans des entités et à effectuer une logique nécessitant des bibliothèques JS sur le client.
+
+### 9. Lorsqu'on écoute plusieurs contrats, est-il possible de sélectionner l'ordre des contrats pour écouter les événements ?
+
+Dans un subgraph, les événements sont toujours traités dans l'ordre dans lequel ils apparaissent dans les blocs, que ce soit sur plusieurs contrats ou non.
+
+### 10. En quoi les modèles sont-ils différents des sources de données ?
+
+Les modèles vous permettent de créer rapidement des sources de données , pendant que votre subgraph est en cours d'indexation. Votre contrat peut générer de nouveaux contrats à mesure que les gens interagissent avec lui. Étant donné que vous connaissez la structure de ces contrats (ABI, événements, etc.) à l'avance, vous pouvez définir comment vous souhaitez les indexer dans un modèle. Lorsqu'ils sont générés, votre subgraph créera une source de données dynamique en fournissant l'adresse du contrat.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. Dans quel ordre les gestionnaires d'événements, de blocs et d'appels sont-ils déclenchés pour une source de données ?
+
+Les gestionnaires d'événements et d'appels sont d'abord classés par index de transaction à l'intérieur du bloc. Les gestionnaires d'événements et d'appels au sein d'une même transaction sont ordonnés selon une convention : d'abord les gestionnaires d'événements, puis les gestionnaires d'appels, chaque type respectant l'ordre défini dans le manifeste. Les gestionnaires de blocs sont exécutés après les gestionnaires d'événements et d'appels, dans l'ordre où ils sont définis dans le manifeste. Ces règles d'ordre sont également susceptibles d'être modifiées.
+
+Lorsque de nouvelles sources de données dynamiques sont créées, les gestionnaires définis pour les sources de données dynamiques ne commenceront à être traités qu'une fois que tous les gestionnaires de sources de données existantes auront été traités, et ils se répéteront dans la même séquence chaque fois qu'ils seront déclenchés.
+
+### 13. Comment puis-je m'assurer que j'utilise la dernière version de graph-node pour mes déploiements en local ?
+
+Vous pouvez exécuter la commande suivante :
+
+```sh
+docker pull graphprotocol/graph-node:dernier
+```
+
+> Remarque : docker / docker-compose utilisera toujours la version de graph-node qui a été téléchargée la première fois que vous l'avez exécuté, alors assurez-vous d'être à jour avec la dernière version de graph-node.
+
+### 14. Quelle est la méthode recommandée pour créer des Ids "autogénérés" pour une entité pendant la gestion des événements ?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Puis-je supprimer mon subgraph ?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Relatif au Réseau
+
+### 16. Quels réseaux sont supportés par The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Est-il possible de faire la différence entre les réseaux (mainnet, Sepolia, local) dans les gestionnaires d'événements?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+importez { dataSource } de '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Prenez-vous en charge les gestionnaires de blocs et d'appels sur Sepolia?
+
+Oui. Sepolia prend en charge les gestionnaires de blocs, les gestionnaires d'appels et les gestionnaires d'événements. Il convient de noter que les gestionnaires d'événements sont beaucoup plus performants que les deux autres gestionnaires, et ils sont pris en charge sur tous les réseaux compatibles EVM.
+
+## Indexing & Querying Related
+
+### 19. Est-il possible de spécifier à partir de quel bloc commencer l'indexation?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. Quels sont quelques conseils pour augmenter les performances d'indexation? Mon subgraph prend beaucoup de temps à se synchroniser
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Existe-t-il un moyen d'interroger directement le subgraph pour déterminer le dernier numéro de bloc qu'il a indexé?
+
+Oui ! Essayez la commande suivante, en remplaçant "organization/subgraphName" par l'organisation sous laquelle elle est publiée et le nom de votre subgraphe :
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/ index-node/graphql
+```
+
+### 22. Existe-t-il une limite au nombre d'objets que The Graph peut retourner par requête?
+
+Par défaut, les réponses aux requêtes sont limitées à 100 éléments par collection. Si vous voulez en recevoir plus, vous pouvez aller jusqu'à 1000 éléments par collection et au-delà, vous pouvez paginer avec :
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Divers
+
+### 24. Est-il possible d'utiliser Apollo Federation sur graph-node?
+
+La fédération n'est pas encore supportée. Pour le moment, vous pouvez utiliser la fusion de schémas, soit sur le client, soit via un service proxy.
+
+### 25. Je veux contribuer ou ajouter un problème GitHub. Où puis-je trouver les dépôts open source?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 23bdc7135ee92cadafd10b76a8e04c2c121532de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:44 -0500
Subject: [PATCH 1904/3820] New translations developer-faq.mdx (Spanish)

---
 .../es/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/es/subgraphs/developing/developer-faq.mdx b/website/pages/es/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..048a9eef2d06
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. ¿Qué es un subgrafo?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. ¿Puedo cambiar la cuenta de GitHub asociada con mi subgrafo?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+Tienes que volver a realizar el deploy del subgrafo, pero si el ID del subgrafo (hash IPFS) no cambia, no tendrá que sincronizarse desde el principio.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Dentro de un subgrafo, los eventos se procesan siempre en el orden en que aparecen en los bloques, independientemente de que sea a través de múltiples contratos o no.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+Puedes ejecutar el siguiente comando:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+¡Sí es posible! Prueba el siguiente comando, sustituyendo "organization/subgraphName" por la organización bajo la que se publica y el nombre de tu subgrafo:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 0f2efc54e70d8ce4580e5f48b7a8967739d37252 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:46 -0500
Subject: [PATCH 1905/3820] New translations developer-faq.mdx (Arabic)

---
 .../ar/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/ar/subgraphs/developing/developer-faq.mdx b/website/pages/ar/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..2609dabc7e89
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. What is a subgraph?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Can I change the GitHub account associated with my subgraph?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+يجب عليك إعادة نشر ال الفرعيةرسم بياني ، ولكن إذا لم يتغير الفرعيةرسم بياني (ID (IPFS hash ، فلن يضطر إلى المزامنة من البداية.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+ضمن ال Subgraph ، تتم معالجة الأحداث دائمًا بالترتيب الذي تظهر به في الكتل ، بغض النظر عما إذا كان ذلك عبر عقود متعددة أم لا.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+يمكنك تشغيل الأمر التالي:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+'import { dataSource } from '@graphprotocol/graph-ts
+
+()dataSource.network
+()dataSource.address
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+نعم! جرب الأمر التالي ، مع استبدال "Organization / subgraphName" بالمؤسسة واسم الـ subgraph الخاص بك:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From b1967dacf15b8f98ac5e7c526ff6645539269e95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:47 -0500
Subject: [PATCH 1906/3820] New translations developer-faq.mdx (Czech)

---
 .../cs/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/cs/subgraphs/developing/developer-faq.mdx b/website/pages/cs/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..6423a0e2b3e3
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. Co je to podgraf?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Mohu změnit účet GitHub přidružený k mému podgrafu?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+Podgraf musíte znovu nasadit, ale pokud se ID podgrafu (hash IPFS) nezmění, nebude se muset synchronizovat od začátku.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+V rámci podgrafu se události zpracovávají vždy v pořadí, v jakém se objevují v blocích, bez ohledu na to, zda se jedná o více smluv.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Obsluhy událostí a volání jsou nejprve seřazeny podle indexu transakce v rámci bloku. Obsluhy událostí a volání v rámci téže transakce jsou seřazeny podle konvence: nejprve obsluhy událostí, pak obsluhy volání, přičemž každý typ dodržuje pořadí, v jakém jsou definovány v manifestu. Obsluhy bloků se spouštějí po obsluhách událostí a volání v pořadí, v jakém jsou definovány v manifestu. I tato pravidla řazení se mohou měnit.
+
+Při vytváření nových dynamických zdrojů dat se obslužné rutiny definované pro dynamické zdroje dat začnou zpracovávat až po zpracování všech existujících obslužných rutin zdrojů dat a budou se opakovat ve stejném pořadí, kdykoli budou spuštěny.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+Můžete spustit následující příkaz:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Ano! Vyzkoušejte následující příkaz, přičemž "organization/subgraphName" nahraďte názvem organizace, pod kterou je publikován, a názvem vašeho podgrafu:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 61c07ea8a4add7763b4aa6eb4f3ebe08e5c1dc87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:48 -0500
Subject: [PATCH 1907/3820] New translations developer-faq.mdx (German)

---
 .../de/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/de/subgraphs/developing/developer-faq.mdx b/website/pages/de/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..2a027a39d2c6
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. What is a subgraph?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Can I change the GitHub account associated with my subgraph?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+You have to redeploy the subgraph, but if the subgraph ID (IPFS hash) doesn't change, it won't have to sync from the beginning.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Within a subgraph, the events are always processed in the order they appear in the blocks, regardless of whether that is across multiple contracts or not.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+You can run the following command:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Yes! Try the following command, substituting "organization/subgraphName" with the organization under it is published and the name of your subgraph:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 703cf93779ee5fbabb233980f3085d89a0cfe69e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:49 -0500
Subject: [PATCH 1908/3820] New translations developer-faq.mdx (Italian)

---
 .../it/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/it/subgraphs/developing/developer-faq.mdx b/website/pages/it/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..2a027a39d2c6
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. What is a subgraph?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Can I change the GitHub account associated with my subgraph?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+You have to redeploy the subgraph, but if the subgraph ID (IPFS hash) doesn't change, it won't have to sync from the beginning.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Within a subgraph, the events are always processed in the order they appear in the blocks, regardless of whether that is across multiple contracts or not.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+You can run the following command:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Yes! Try the following command, substituting "organization/subgraphName" with the organization under it is published and the name of your subgraph:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From e61ede0b57c86c133a83b427137d87c28fac66b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:50 -0500
Subject: [PATCH 1909/3820] New translations developer-faq.mdx (Japanese)

---
 .../ja/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/ja/subgraphs/developing/developer-faq.mdx b/website/pages/ja/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..86b6f7d4cedc
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. サブグラフとは
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. サブグラフに関連付けられている GitHub アカウントを変更できますか?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+サブグラフを再デプロイする必要がありますが、サブグラフの ID（IPFS ハッシュ）が変わらなければ、最初から同期する必要はありません。
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+サブグラフ内では、複数のコントラクトにまたがっているかどうかにかかわらず、イベントは常にブロックに表示される順序で処理されます。
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+以下のコマンドを実行してください:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+はい、あります。organization/subgraphName」を公開先の組織とサブグラフの名前に置き換えて、以下のコマンドを実行してみてください:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 83746afddc7ba98b1bcb9cee7a10e216e0632b7f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:51 -0500
Subject: [PATCH 1910/3820] New translations developer-faq.mdx (Korean)

---
 .../ko/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/ko/subgraphs/developing/developer-faq.mdx b/website/pages/ko/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..2a027a39d2c6
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. What is a subgraph?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Can I change the GitHub account associated with my subgraph?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+You have to redeploy the subgraph, but if the subgraph ID (IPFS hash) doesn't change, it won't have to sync from the beginning.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Within a subgraph, the events are always processed in the order they appear in the blocks, regardless of whether that is across multiple contracts or not.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+You can run the following command:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Yes! Try the following command, substituting "organization/subgraphName" with the organization under it is published and the name of your subgraph:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From e2ea122d0402a36353cb1b364f4dca5b12e9dc4f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:52 -0500
Subject: [PATCH 1911/3820] New translations developer-faq.mdx (Dutch)

---
 .../nl/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/nl/subgraphs/developing/developer-faq.mdx b/website/pages/nl/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..2a027a39d2c6
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. What is a subgraph?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Can I change the GitHub account associated with my subgraph?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+You have to redeploy the subgraph, but if the subgraph ID (IPFS hash) doesn't change, it won't have to sync from the beginning.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Within a subgraph, the events are always processed in the order they appear in the blocks, regardless of whether that is across multiple contracts or not.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+You can run the following command:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Yes! Try the following command, substituting "organization/subgraphName" with the organization under it is published and the name of your subgraph:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From f515359fff5c119d846b470631e0d5a401cccf3e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:53 -0500
Subject: [PATCH 1912/3820] New translations developer-faq.mdx (Polish)

---
 .../pl/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/pl/subgraphs/developing/developer-faq.mdx b/website/pages/pl/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..2a027a39d2c6
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. What is a subgraph?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Can I change the GitHub account associated with my subgraph?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+You have to redeploy the subgraph, but if the subgraph ID (IPFS hash) doesn't change, it won't have to sync from the beginning.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Within a subgraph, the events are always processed in the order they appear in the blocks, regardless of whether that is across multiple contracts or not.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+You can run the following command:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Yes! Try the following command, substituting "organization/subgraphName" with the organization under it is published and the name of your subgraph:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 3a69e77c0e4434616fed423b3880a2d7a51dc82e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:54 -0500
Subject: [PATCH 1913/3820] New translations developer-faq.mdx (Portuguese)

---
 .../pt/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/pt/subgraphs/developing/developer-faq.mdx b/website/pages/pt/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..a29bf02830be
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. O que é um subgraph?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Posso mudar a conta do GitHub associada ao meu subgraph?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+Deve relançar o subgraph, mas se a ID do subgraph (hash IPFS) não mudar, ele não precisará sincronizar do começo.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Dentro de um subgraph, os eventos são sempre processados na ordem em que aparecem nos blocos, mesmo sendo ou não através de vários contratos.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Primeiro, handlers de eventos e chamadas são organizados pelo índice de transações dentro do bloco. Handlers de evento e chamada dentro da mesma transação são organizados com uma convenção: handlers de eventos primeiro e depois handlers de chamadas, com cada tipo a respeitar a ordem em que são definidos no manifest. Handlers de blocos são executados após handlers de eventos e chamadas, na ordem em que são definidos no manifest. Estas regras de organizações estão sujeitas a mudanças.
+
+Com a criação de novas fontes de dados dinâmicas, os handlers definidos para fontes de dados dinâmicas só começarão a processar após o processamento dos handlers das fontes, e se repetirão na mesma sequência sempre que acionados.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+Podes executar o seguinte comando:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Sim. O Sepolia apoia handlers de blocos, chamadas e eventos. Vale notar que handlers de eventos têm desempenho muito melhor do que os outros dois e têm apoio em todas as redes compatíveis com EVMs.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Sim! Execute o seguinte comando, com "organization/subgraphName" substituído com a organização sob a qual ele foi publicado e o nome do seu subgraph:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From db63825e7dbb4a853c49d3729d8f92b4c806e7b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:55 -0500
Subject: [PATCH 1914/3820] New translations developer-faq.mdx (Russian)

---
 .../ru/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/ru/subgraphs/developing/developer-faq.mdx b/website/pages/ru/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..e6d45ce8402c
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+На этой странице собраны некоторые из наиболее частых вопросов для разработчиков, использующих The Graph.
+
+## Вопросы, связанные с субграфом
+
+### 1. Что такое субграф?
+
+Субграф - это пользовательский API, построенный на данных блокчейна. Субграфы запрашиваются с использованием языка запросов GraphQL и развертываются на Graph Node с помощью Graph CLI. После развертывания и публикации в децентрализованной сети The Graph индексаторы обрабатывают субграфы и делают их доступными для запросов потребителей субграфов.
+
+### 2. Каков первый шаг в создании субграфа?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Могу ли я создать субграф, если в моих смарт-контрактах нет событий?
+
+Настоятельно рекомендуется структурировать смарт-контракты так, чтобы они содержали события, связанные с данными, которые вы хотите запросить. Обработчики событий в субграфе срабатывают на события контракта и являются самым быстрым способом получения нужных данных.
+
+Если контракты, с которыми Вы работаете, не содержат событий, Ваш субграф может использовать обработчики вызовов и блоков для запуска индексации. Хотя это не рекомендуется, так как производительность будет существенно ниже.
+
+### 4. Могу ли я изменить учетную запись GitHub, связанную с моим субграфом?
+
+Нет. После создания субграфа связанная с ним учетная запись GitHub не может быть изменена. Пожалуйста, учтите это перед созданием субграфа.
+
+### 5. Как обновить субграф в майннете?
+
+Вы можете развернуть новую версию своего субграфа в Subgraph Studio с помощью интерфейса командной строки (CLI). Это действие сохраняет конфиденциальность вашего субграфа, но, если результат Вас удовлетворит, Вы сможете опубликовать его в Graph Explorer. При этом будет создана новая версия Вашего субграфа, на которую Кураторы смогут начать подавать сигналы.
+
+### 6. Можно ли дублировать субграф на другую учетную запись или конечную точку без повторного развертывания?
+
+Вы должны повторно развернуть субграф, но если идентификатор субграфа (хэш IPFS) не изменится, его не нужно будет синхронизировать с самого начала.
+
+### 7. Как вызвать контрактную функцию или получить доступ к публичной переменной состояния из моих мэппингов субграфа?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+В настоящее время нет, так как мэппинги написаны на языке AssemblyScript.
+
+Одним из возможных альтернативных решений является хранение необработанных данных в объектах и выполнение логики, для которой требуются библиотеки JS на клиенте.
+
+### 9. При прослушивании нескольких контрактов, возможно ли выбрать порядок прослушивания событий контрактов?
+
+Внутри субграфа события всегда обрабатываются в том порядке, в котором они появляются в блоках, независимо от того, относится ли это к нескольким контрактам или нет.
+
+### 10. Чем шаблоны отличаются от источников данных?
+
+Шаблоны позволяют Вам быстро создавать источники данных, пока Ваш субграф индексируется. Ваш контракт может создавать новые контракты по мере того, как люди будут с ним взаимодействовать. Поскольку форма этих контрактов (ABI, события и т. д.) известна заранее, Вы сможете определить, как Вы хотите индексировать их в шаблоне. Когда они будут сгенерированы, Ваш субграф создаст динамический источник данных, предоставив адрес контракта.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. В каком порядке вызываются обработчики событий, блоков и вызовов для источника данных?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. Как убедиться, что я использую последнюю версию graph-node для своих локальных развертываний?
+
+Вы можете запустить следующую команду:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Примечание: docker / docker-compose всегда будет использовать ту версию graph-node, которая была получена при первом запуске, поэтому убедитесь, что используете последнюю версию graph-node.
+
+### 14. Каков рекомендуемый способ создания "автоматически сгенерированных" идентификаторов для объекта при обработке событий?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Могу ли я удалить свой субграф?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Вопросы, связанный с сетью
+
+### 16. Какие сети поддерживает The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Можно ли различать сети (майннет, Sepolia, локальную) внутри обработчиков событий?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Поддерживаете ли Вы обработчики блоков и вызовов на Sepolia?
+
+Да. Sepolia поддерживает обработчики блоков, обработчики вызовов и обработчики событий. Следует отметить, что обработчики событий намного более эффективны, чем два других обработчика, и они поддерживаются в каждой сети, совместимой с EVM.
+
+## Indexing & Querying Related
+
+### 19. Можно ли указать, с какого блока следует начинать индексирование?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. Есть ли какие-либо советы по увеличению производительности индексирования? Синхронизация моего субграфа занимает очень много времени
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Есть ли способ напрямую запросить субграф, чтобы определить номер последнего проиндексированного блока?
+
+Да! Попробуйте выполнить следующую команду, заменив "organization/subgraphName" на название организации, под которой она опубликована, и имя Вашего субграфа:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Есть ли ограничение на количество объектов, которые The Graph может вернуть за один запрос?
+
+По умолчанию ответы на запросы ограничены 100 единицами на коллекцию. Если Вы хотите получить больше, Вы можете довести количество до 1000 единиц на коллекцию, а для получения ещё большего количества можно использовать пагинацию:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Прочее
+
+### 24. Можно ли использовать Apollo Federation поверх graph-node?
+
+Federation пока не поддерживается. В настоящее время Вы можете использовать объединение схем либо на клиенте, либо через прокси-сервис.
+
+### 25. Я хочу внести свой вклад или добавить задачу на GitHub. Где я могу найти репозитории с открытым исходным кодом?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From aa9e2d72bc6cc89a309ecaff501fabb325d91077 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:56 -0500
Subject: [PATCH 1915/3820] New translations developer-faq.mdx (Swedish)

---
 .../sv/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/sv/subgraphs/developing/developer-faq.mdx b/website/pages/sv/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..ae3e8e005a81
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. Vad är en subgraf?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Kan jag ändra det GitHub-konto som är kopplat till min subgraf?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+Du måste distribuera om subgrafen, men om subgrafens ID (IPFS-hash) inte ändras behöver den inte synkroniseras från början.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Inom en subgraf behandlas händelser alltid i den ordning de visas i blocken, oavsett om det är över flera kontrakt eller inte.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+Du kan köra följande kommando:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from "@graphprotocol/graph-ts"
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Ja! Prova följande kommando och ersätt "organization/subgraphName" med organisationen under vilken den är publicerad och namnet på din subgraf:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 108750c9e1f04bad50140626b767e8f135ab3af6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:57 -0500
Subject: [PATCH 1916/3820] New translations developer-faq.mdx (Turkish)

---
 .../tr/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/tr/subgraphs/developing/developer-faq.mdx b/website/pages/tr/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..e0175ff82871
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+Bu sayfa, The Graph üzerinde geliştirme yapan geliştiricilerin sunduğu en yaygın soruların bazılarını özetlemektedir.
+
+## Subgraph ile İlgili Sorular
+
+### 1. Subgraph nedir?
+
+Bir subgraph, blokzinciri verilerine dayalı olarak oluşturulmuş özel yapım bir API’dir. Subgraph'ler, GraphQL sorgu dili kullanılarak sorgulanır ve The Graph CLI kullanılarak bir Graph Düğümü'nde yayına alınır. Dağıtılıp The Graph’in merkeziyetsiz ağına yayımlandığında, Endeksleyiciler subgraph'leri işler ve sorgu yapmaları için kullanıcıların erişimine sunar.
+
+### 2. Subgraph oluşturmanın ilk adımı nedir?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Akıllı sözleşmelerim olay içermiyorsa yine de subgraph oluşturabilir miyim?
+
+Akıllı sözleşmelerinizi, sorgulamak istediğiniz verilerle ilişkili olaylara sahip olacak şekilde yapılandırmanız şiddetle önerilir. Subgraph içindeki olay işleyicileri sözleşme olayları tarafından tetiklenir ve kullanışlı verilere erişmenin en hızlı yolu bu işleyicileri kullanmaktır.
+
+Eğer çalıştığınız sözleşmeler olay içermiyorsa, subgraph’inizin endekslenmesini çağrı ve blok işleyicileri kullanarak tetikleyebilirsiniz. Ancak bu tavsiye edilmeyen bir yöntemdir ve performansı önemli ölçüde yavaşlatacaktır.
+
+### 4. Subgraph'ımla ilişkili GitHub hesabını değiştirebilir miyim?
+
+Hayır. Bir subgraph oluşturulduktan sonra, ilişkili GitHub hesabı değiştirilemez. Bu nedenle, subgraph oluşturmadan önce bunu dikkatlice düşünmelisiniz.
+
+### 5. Mainnet'teki bir subgraph nasıl güncellenir?
+
+CLI'yi kullanarak Subgraph Studio’ya yeni bir subgraph sürümü dağıtabilirsiniz. Bu işlem subgraph’inizi gizli olarak tutar, ancak memnun kaldığınızda Graph Gezgini’nde yayımlayabilirsiniz. Bu, Küratörlerin sinyal vermeye başlayabileceği yeni bir subgraph sürümü oluşturur.
+
+### 6. Bir subgraph’i yeniden dağıtmadan başka bir hesaba veya uç noktaya kopyalayabilir miyim?
+
+Subgraph’i yeniden dağıtmanız gerekir ancak subgraph ID'si (IPFS hash’i) değişmezse, senkronizasyona baştan başlamanıza gerek kalmaz.
+
+### 7. Subgraph eşlemelerinden sözleşme fonksiyonunu nasıl çağırabilir veya bir genel durum değişkenine nasıl erişebilirim?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Eşleyiciler AssemblyScript ile yazıldığından dolayı şu anda mümkün değil.
+
+Bunun alternatif bir çözümü, verileri varlıklarda ham halde depolayıp, JS kütüphanelerine ihtiyaç duyan işlemleri istemci üzerinde gerçekleştirmektir.
+
+### 9. Birden fazla sözleşmeyi dinlerken, olayları dinlenecek sözleşmelerin sırasını seçmek mümkün müdür?
+
+Bir subgraph içindeki olaylar, birden fazla sözleşme üzerinde olup olmamaya bakmaksızın her zaman bloklarda göründükleri sırayla işlenir.
+
+### 10. Şablonlar veri kaynaklarından ne açıdan farklıdır?
+
+Şablonlar, subgraph’iniz endeksleme yaparken veri kaynaklarını hızlıca oluşturmanızı sağlar. Sözleşmeniz, kullanıcılar etkileşime girdikçe yeni sözleşmeler yaratabilir. Bu sözleşmelerin yapısını (ABI, olaylar vb.) önceden bildiğinizden, onları nasıl endekslemek istediğinizi bir şablonda tanımlayabilirsiniz. Yeni sözleşmeler oluşturulduğunda, subgraph’iniz sözleşme adresini tespit ederek dinamik bir veri kaynağı oluşturacaktır.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. Bir veri kaynağı için olay, blok ve çağrı işleyicileri hangi sırayla tetiklenir?
+
+Olay ve çağrı işleyicileri, öncelikle blok içindeki işlem indisine göre sıralanır. Aynı işlem içindeki olay ve çağrı işleyicileri, şu sıralama kuralına düzenlenir: önce olay işleyicileri, ardından çağrı işleyicileri gelir; her tür kendi içinde manifestoda tanımlandığı sıraya uyar. Blok işleyicileri, olay ve çağrı işleyicilerinden sonra çalıştırılır ve manifestoda tanımlandıkları sıraya göre gerçekleştirilir. Ayrıca, bu sıralama kuralları değişime tabi olabilir.
+
+Yeni dinamik veri kaynakları oluşturulduğunda, dinamik veri kaynakları için tanımlanan işleyiciler yalnızca mevcut tüm veri kaynağı işleyicileri işlendiğinde işlemeye başlar ve her tetiklendiğinde aynı sırada tekrar eder.
+
+### 13. Yerel çalışma ortamımda graph-node'un en son sürümünü kullandığımdan nasıl emin olabilirim?
+
+Aşağıdaki komutu çalıştırabilirsiniz:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Not: docker / docker-compose, ilk çalıştırdığınızda çekilen graph-node sürümünü kullanmaya devam edecektir. Bu yüzden en son graph-node sürümünü kullandığınızdan emin olun.
+
+### 14. Olayları işlerken bir varlık için "otomatik oluşturulan" id'leri yaratmanın önerilen yolu nedir?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Subgraph'imi silebilir miyim?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Ağ ile İlgili Sorular
+
+### 16. The Graph hangi ağları desteklemektedir?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Olay işleyicileri içerisinde ağlar (mainnet, Sepolia, yerel) arasında ayrım yapmak mümkün müdür?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Sepolia ağında blok ve çağrı işleyicilerini destekliyor musunuz?
+
+Evet. Sepolia, blok işleyicileri, çağrı işleyicileri ve olay işleyicilerini destekler. Olay işleyicilerinin diğer iki işleyiciye göre çok daha yüksek performansa sahip olduğu ve tüm EVM uyumlu ağlarda desteklendiği unutulmamalıdır.
+
+## Indexing & Querying Related
+
+### 19. Endekslemeye hangi bloktan başlanacağını belirtmek mümkün müdür?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. Endeksleme performansını artırmak için ipuçları var mı? Subgraph'imin senkronize edilmesi çok uzun zaman alıyor
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Subgraph üzerinde doğrudan sorgulama yaparak endekslenmiş en son blok numarasını öğrenmenin bir yolu var mı?
+
+Var! Aşağıdaki komutu, "organization/subgraphName" kısmına subgraph'inizi yayımladığınız organizasyon adını ve subgraph'inizin adını koyarak deneyin:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. The Graph'in sorgu başına kaç nesne döndürebileceğine dair bir sınır var mı?
+
+Varsayılan olarak, sorgu yanıtları koleksiyon başına 100 ögeyle sınırlıdır. Daha fazlasını almak istiyorsanız koleksiyon başına 1000 ögeye kadar çıkabilirsiniz. Daha da fazlası için şu şekilde sayfalama yapabilirsiniz:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Diğer
+
+### 24. Apollo Federation'ı graph-node üzerinde kullanmak mümkün mü?
+
+Federation henüz desteklenmiyor. Şu anda, şema birleştirme yöntemini ya istemci tarafında ya da bir proxy hizmeti aracılığıyla kullanabilirsiniz.
+
+### 25. Katkıda bulunmak veya bir GitHub issue'su eklemek istiyorum. Açık kaynak kod depolarını nerede bulabilirim?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From d76dbda7e852706f1e2a65a1666362c0a37c2234 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:18:59 -0500
Subject: [PATCH 1917/3820] New translations developer-faq.mdx (Ukrainian)

---
 .../uk/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/uk/subgraphs/developing/developer-faq.mdx b/website/pages/uk/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..2a027a39d2c6
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. What is a subgraph?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Can I change the GitHub account associated with my subgraph?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+You have to redeploy the subgraph, but if the subgraph ID (IPFS hash) doesn't change, it won't have to sync from the beginning.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Within a subgraph, the events are always processed in the order they appear in the blocks, regardless of whether that is across multiple contracts or not.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+You can run the following command:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Yes! Try the following command, substituting "organization/subgraphName" with the organization under it is published and the name of your subgraph:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 0abce79e1d923798ed5f451826bc90149eea1645 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:00 -0500
Subject: [PATCH 1918/3820] New translations developer-faq.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/zh/subgraphs/developing/developer-faq.mdx b/website/pages/zh/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..0d4fdd68f6e0
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 什么是子图？
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. 我可以更改与我的子图关联的 GitHub 账户吗？
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+您必须重新部署子图，但如果子图 ID（IPFS hash）没有更改，则不必从头开始同步。
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+在子图中，无论是否跨多个合约，事件始终按照它们在区块中出现的顺序进行处理的。
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+您可以运行以下命令：
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+是的！ 请尝试以下命令，并将“organization/subgraphName”替换为发布的组织和子图名称：
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 427b1f8739b4c31496ad7efd5c248c3d8c9ea96a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:01 -0500
Subject: [PATCH 1919/3820] New translations developer-faq.mdx (Urdu
 (Pakistan))

---
 .../ur/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/ur/subgraphs/developing/developer-faq.mdx b/website/pages/ur/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..d1132de6c9b3
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### سب گراف کیا ہے؟
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. کیا میں گٹ ہب کا اکاونٹ بدل سکتا ہوں جو میرے سب گراف کے ساتھ وابستہ ہے؟
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+آپ کو سب گراف کو دوبارہ تعینات کرنا ہوگا، لیکن اگر سب گراف ID (IPFS ہیش) تبدیل نہیں ہوتا ہے، تو اسے شروع سے مطابقت پذیر نہیں ہونا پڑے گا.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+سب گراف کے اندر، ایونٹس کو ہمیشہ اسی ترتیب سے پروسیس کیا جاتا ہے جس ترتیب سے وہ بلاکس میں ظاہر ہوتے ہیں، قطع نظر اس کے کہ یہ متعدد کنٹریکٹس میں ہے یا نہیں.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+آپ زیل میں دی گئ کمانڈ چلا سکتے ہیں:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+جی ہاں! مندرجہ ذیل کمانڈ کو آزمائیں، "تنظیم/سب گراف نام" کو اس کے تحت شائع ہونے والی تنظیم کے ساتھ تبدیل کرتے ہوئے اور آپ کے سب گراف کا نام:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 0e026ebcd2d9ec9f74c60302f80737c39240ee17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:02 -0500
Subject: [PATCH 1920/3820] New translations developer-faq.mdx (Vietnamese)

---
 .../vi/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/vi/subgraphs/developing/developer-faq.mdx b/website/pages/vi/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..977ff1ff9372
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. What is a subgraph?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Can I change the GitHub account associated with my subgraph?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+Bạn phải triển khai lại subgraph, nhưng nếu ID subgraph (mã băm IPFS) không thay đổi, nó sẽ không phải đồng bộ hóa từ đầu.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Trong một subgraph, các sự kiện luôn được xử lý theo thứ tự chúng xuất hiện trong các khối, bất kể điều đó có qua nhiều hợp đồng hay không.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+Bạn có thể chạy lệnh sau:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Có! Hãy thử lệnh sau, thay thế "organization/subgraphName" bằng tổ chức dưới nó được xuất bản và tên của subgraph của bạn:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From ad4ebaec10b465507f3244e9ea09875409a849e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:03 -0500
Subject: [PATCH 1921/3820] New translations developer-faq.mdx (Marathi)

---
 .../mr/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/mr/subgraphs/developing/developer-faq.mdx b/website/pages/mr/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..14945c00fe1f
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. सबग्राफ म्हणजे काय?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. मी माझ्या सबग्राफशी संबंधित गिटहब खाते बदलू शकतो का?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+तुम्हाला सबग्राफ पुन्हा तैनात करावा लागेल, परंतु सबग्राफ आयडी (IPFS हॅश) बदलत नसल्यास, त्याला सुरुवातीपासून सिंक करण्याची गरज नाही.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+सबग्राफमध्‍ये, इव्‍हेंट नेहमी ब्लॉकमध्‍ये दिसण्‍याच्‍या क्रमाने संसाधित केले जातात, ते एकाधिक कॉन्ट्रॅक्टमध्‍ये असले किंवा नसले तरीही.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+तुम्ही खालील आदेश चालवू शकता:
+
+```sh
+डॉकर पुल ग्राफप्रोटोकॉल/ग्राफ-नोड:नवीनतम
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+होय! खालील आदेश वापरून पहा, "संस्था/सबग्राफनेम" च्या जागी त्याखालील संस्था प्रकाशित झाली आहे आणि तुमच्या सबग्राफचे नाव:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { साखळी { नवीनतम ब्लॉक { hash number }}}"}' https://api.thegraph.com/ index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From c4ff8010f6b6a2e87305a216f50973d6f5f12c5f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:04 -0500
Subject: [PATCH 1922/3820] New translations developer-faq.mdx (Hindi)

---
 .../hi/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/hi/subgraphs/developing/developer-faq.mdx b/website/pages/hi/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..81e2119a623f
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+यह पृष्ठ 'The Graph' पर निर्माण कर रहे डेवलपर्स के लिए कुछ सामान्य प्रश्नों का सारांश प्रस्तुत करता है।
+
+## सबग्रह संबंधित
+
+### 1. सबग्राफ क्या है?
+
+एक subgraph एक कस्टम API है जो ब्लॉकचेन डेटा पर आधारित है। subgraphs को GraphQL क्वेरी भाषा का उपयोग करके क्वेरी किया जाता है और इन्हें The Graph CLI का उपयोग करके Graph Node पर तैनात किया जाता है। एक बार तैनात और The Graph के विकेन्द्रीकृत नेटवर्क पर प्रकाशित होने के बाद, Indexers subgraphs को प्रोसेस करते हैं और उन्हें subgraph उपभोक्ताओं के लिए क्वेरी करने के लिए उपलब्ध कराते हैं।
+
+### 2. एक Subgraph बनाने का पहला कदम क्या है?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. क्या मैं अभी भी एक subgraph बना सकता हूँ यदि मेरी स्मार्ट कॉन्ट्रैक्ट्स में कोई इवेंट्स नहीं हैं?
+
+यह अत्यधिक अनुशंसित है कि आप अपने स्मार्ट अनुबंधों को इस तरह से संरचित करें कि उन डेटा के साथ घटनाएँ हों जिनमें आपकी रुचि है। अनुबंध की घटनाओं द्वारा संचालित 'event handlers' को Subgraph में ट्रिगर किया जाता है और यह उपयोगी डेटा प्राप्त करने का सबसे तेज़ तरीका है।
+
+अगर आप जिन अनुबंधों के साथ काम कर रहे हैं, उनमें घटनाएँ नहीं हैं, तो आपका subgraph कॉल और ब्लॉक हैंडलर्स का उपयोग कर सकता है ताकि इंडेक्सिंग को ट्रिगर किया जा सके। हालाँकि, यह अनुशंसित नहीं है, क्योंकि प्रदर्शन काफी धीमा होगा।
+
+### 4. क्या मैं अपने सबग्राफ से जुड़े GitHub खाते को बदल सकता हूँ?
+
+एक बार जब एक subgraph बनाया जाता है, तो संबंधित GitHub खाता नहीं बदला जा सकता है। कृपया अपने subgraph को बनाने से पहले इसे ध्यान से विचार करें।
+
+### 5. मैं मुख्य नेटवर्क पर एक subgraph को कैसे अपडेट करूँ?
+
+आप अपने subgraph का नया संस्करण Subgraph Studio में CLI का उपयोग करके डिप्लॉय कर सकते हैं। यह क्रिया आपके subgraph को निजी रखती है, लेकिन जब आप इससे खुश हों, तो आप Graph Explorer में इसे प्रकाशित कर सकते हैं। इससे आपके subgraph का एक नया संस्करण बनेगा जिस पर Curators सिग्नल करना शुरू कर सकते हैं।
+
+### 6. एक Subgraph को दूसरे खाते या एंडपॉइंट पर बिना पुनः तैनात किए डुप्लिकेट करना संभव है?
+
+आपको सबग्राफ को फिर से तैनात करना होगा, लेकिन अगर सबग्राफ आईडी (आईपीएफएस हैश) नहीं बदलता है, तो इसे शुरुआत से सिंक नहीं करना पड़ेगा।
+
+### 7. आप अपने subgraph mappings से एक contract function को कैसे कॉल करें या एक सार्वजनिक state variable तक कैसे पहुँचें?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+AssemblyScript में वर्तमान में मैपिंग्स नहीं लिखी जा रही हैं।
+
+एक संभावित वैकल्पिक समाधान यह है कि कच्चे डेटा को एंटिटीज़ में स्टोर किया जाए और जो लॉजिक JS पुस्तकालय की आवश्यकता होती है, उसे क्लाइंट पर किया जाए।
+
+### 9. कई कॉन्ट्रैक्ट सुनते समय, क्या घटनाओं को सुनने के लिए कॉन्ट्रैक्ट के क्रम का चयन करना संभव है?
+
+एक सबग्राफ के भीतर, घटनाओं को हमेशा उसी क्रम में संसाधित किया जाता है जिस क्रम में वे ब्लॉक में दिखाई देते हैं, भले ही वह कई अनुबंधों में हो या नहीं।
+
+### 10. टेम्प्लेट्स और डेटा स्रोतों में क्या अंतर है?
+
+Templates आपको डेटा स्रोतों को तेजी से बनाने की अनुमति देते हैं, जबकि आपका subgraph इंडेक्सिंग कर रहा है। आपका कॉन्ट्रैक्ट नए कॉन्ट्रैक्ट उत्पन्न कर सकता है जब लोग इसके साथ इंटरैक्ट करते हैं। चूंकि आप उन कॉन्ट्रैक्टों का आकार (ABI, इवेंट, आदि) पहले से जानते हैं, आप यह निर्धारित कर सकते हैं कि आप उन्हें एक टेम्पलेट में कैसे इंडेक्स करना चाहते हैं। जब वे उत्पन्न होते हैं, तो आपका subgraph कॉन्ट्रैक्ट पते को प्रदान करके एक डायनामिक डेटा स्रोत बनाएगा।
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. एक डेटा स्रोत के लिए इवेंट, ब्लॉक और कॉल हैंडलर्स को किस क्रम में ट्रिगर किया जाता है?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. यह सुनिश्चित करने के लिए कि मैं अपने स्थानीय डिप्लॉयमेंट के लिए graph-node का नवीनतम संस्करण उपयोग कर रहा हूँ?
+
+आप निम्न आदेश चला सकते हैं:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> ध्यान दें: docker / docker-compose हमेशा उसी graph-node संस्करण का उपयोग करेगा जिसे आपने पहली बार इसे चलाने पर खींचा था, इसलिए सुनिश्चित करें कि आप graph-node के नवीनतम संस्करण के साथ अपडेट हैं।
+
+### 14. इवेंट्स को हैंडल करते समय एक एंटिटी के लिए "स्वतः उत्पन्न" आईडी बनाने का अनुशंसित तरीका क्या है?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. क्या मैं अपना subgraph हटा सकता हूँ?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## नेटवर्क से संबंधित।
+
+### 16. The Graph द्वारा समर्थित नेटवर्क कौन से हैं?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. क्या इवेंट हैंडलर्स के भीतर नेटवर्क (mainnet, Sepolia, local) के बीच अंतर करना संभव है?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. क्या आप Sepolia पर block और call handlers का समर्थन करते हैं?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. क्या यह संभव है कि किस ब्लॉक से इंडेक्सिंग शुरू की जाए?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. यहां कुछ सुझाव दिए गए हैं ताकि इंडेक्सिंग का प्रदर्शन बढ़ सके। मेरा subgraph बहुत लंबे समय तक सिंक होने में समय ले रहा है।
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. क्या कोई तरीका है कि 'subgraph' को सीधे क्वेरी करके यह पता लगाया जा सके कि उसने कौन सा लेटेस्ट ब्लॉक नंबर इंडेक्स किया है?
+
+हाँ! निम्न आदेश का प्रयास करें, "संगठन/सबग्राफनाम" को उस संगठन के साथ प्रतिस्थापित करें जिसके अंतर्गत वह प्रकाशित है और आपके सबग्राफ का नाम:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. क्या The Graph एक क्वेरी में कितने ऑब्जेक्ट्स वापस कर सकता है, इस पर कोई सीमा है?
+
+डिफ़ॉल्ट रूप से, क्वेरी उत्तर हर संग्रह के लिए 100 आइटम तक सीमित होते हैं। यदि आप अधिक प्राप्त करना चाहते हैं, तो आप 1000 आइटम तक जा सकते हैं और उसके बाद, आप पेजिनेट कर सकते हैं:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## विविध 
+
+### क्या Apollo Federation  का उपयोग graph-node के ऊपर किया जा सकता है?
+
+Federation अभी समर्थित नहीं है। फिलहाल, आप schema stitching का उपयोग कर सकते हैं, या तो क्लाइंट पर या एक प्रॉक्सी सेवा के माध्यम से।
+
+### 25. मैं योगदान देना चाहता हूँ या कोई GitHub मुद्दा जोड़ना चाहता हूँ। मुझे ओपन सोर्स रिपॉज़िटरीज़ कहाँ मिल सकती हैं?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 5d9bd4b6f4519a42c600cf1861d26d25a04aefcc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:06 -0500
Subject: [PATCH 1923/3820] New translations developer-faq.mdx (Swahili)

---
 .../sw/subgraphs/developing/developer-faq.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/developer-faq.mdx

diff --git a/website/pages/sw/subgraphs/developing/developer-faq.mdx b/website/pages/sw/subgraphs/developing/developer-faq.mdx
new file mode 100644
index 000000000000..2a027a39d2c6
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/developer-faq.mdx
@@ -0,0 +1,147 @@
+---
+title: Developer FAQ
+---
+
+This page summarizes some of the most common questions for developers building on The Graph.
+
+## Subgraph Related
+
+### 1. What is a subgraph?
+
+A subgraph is a custom API built on blockchain data. Subgraphs are queried using the GraphQL query language and are deployed to a Graph Node using The Graph CLI. Once deployed and published to The Graph's decentralized network, Indexers process subgraphs and make them available for subgraph consumers to query.
+
+### 2. What is the first step to create a subgraph?
+
+To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 3. Can I still create a subgraph if my smart contracts don't have events?
+
+It is highly recommended that you structure your smart contracts to have events associated with data you are interested in querying. Event handlers in the subgraph are triggered by contract events and are the fastest way to retrieve useful data.
+
+If the contracts you work with do not contain events, your subgraph can use call and block handlers to trigger indexing. However, this is not recommended, as performance will be significantly slower.
+
+### 4. Can I change the GitHub account associated with my subgraph?
+
+No. Once a subgraph is created, the associated GitHub account cannot be changed. Please make sure to carefully consider this before creating your subgraph.
+
+### 5. How do I update a subgraph on mainnet?
+
+You can deploy a new version of your subgraph to Subgraph Studio using the CLI. This action maintains your subgraph private, but once you’re happy with it, you can publish to Graph Explorer. This will create a new version of your subgraph that Curators can start signaling on.
+
+### 6. Is it possible to duplicate a subgraph to another account or endpoint without redeploying?
+
+You have to redeploy the subgraph, but if the subgraph ID (IPFS hash) doesn't change, it won't have to sync from the beginning.
+
+### 7. How do I call a contract function or access a public state variable from my subgraph mappings?
+
+Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+
+### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+
+Not currently, as mappings are written in AssemblyScript.
+
+One possible alternative solution to this is to store raw data in entities and perform logic that requires JS libraries on the client.
+
+### 9. When listening to multiple contracts, is it possible to select the contract order to listen to events?
+
+Within a subgraph, the events are always processed in the order they appear in the blocks, regardless of whether that is across multiple contracts or not.
+
+### 10. How are templates different from data sources?
+
+Templates allow you to create data sources quickly, while your subgraph is indexing. Your contract might spawn new contracts as people interact with it. Since you know the shape of those contracts (ABI, events, etc.) upfront, you can define how you want to index them in a template. When they are spawned, your subgraph will create a dynamic data source by supplying the contract address.
+
+Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+
+### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+
+Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+
+You can also use `graph add` command to add a new dataSource.
+
+### 12. In what order are the event, block, and call handlers triggered for a data source?
+
+Event and call handlers are first ordered by transaction index within the block. Event and call handlers within the same transaction are ordered using a convention: event handlers first then call handlers, each type respecting the order they are defined in the manifest. Block handlers are run after event and call handlers, in the order they are defined in the manifest. Also these ordering rules are subject to change.
+
+When new dynamic data source are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+
+### 13. How do I make sure I'm using the latest version of graph-node for my local deployments?
+
+You can run the following command:
+
+```sh
+docker pull graphprotocol/graph-node:latest
+```
+
+> Note: docker / docker-compose will always use whatever graph-node version was pulled the first time you ran it, so make sure you're up to date with the latest version of graph-node.
+
+### 14. What is the recommended way to build "autogenerated" ids for an entity when handling events?
+
+If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+
+### 15. Can I delete my subgraph?
+
+Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+
+## Network Related
+
+### 16. What networks are supported by The Graph?
+
+You can find the list of the supported networks [here](/supported-networks/).
+
+### 17. Is it possible to differentiate between networks (mainnet, Sepolia, local) within event handlers?
+
+Yes. You can do this by importing `graph-ts` as per the example below:
+
+```javascript
+import { dataSource } from '@graphprotocol/graph-ts'
+
+dataSource.network()
+dataSource.address()
+```
+
+### 18. Do you support block and call handlers on Sepolia?
+
+Yes. Sepolia supports block handlers, call handlers and event handlers. It should be noted that event handlers are far more performant than the other two handlers, and they are supported on every EVM-compatible network.
+
+## Indexing & Querying Related
+
+### 19. Is it possible to specify what block to start indexing on?
+
+Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 20. What are some tips to increase the performance of indexing? My subgraph is taking a very long time to sync
+
+Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+
+### 21. Is there a way to query the subgraph directly to determine the latest block number it has indexed?
+
+Yes! Try the following command, substituting "organization/subgraphName" with the organization under it is published and the name of your subgraph:
+
+```sh
+curl -X POST -d '{ "query": "{indexingStatusForCurrentVersion(subgraphName: \"organization/subgraphName\") { chains { latestBlock { hash number }}}}"}' https://api.thegraph.com/index-node/graphql
+```
+
+### 22. Is there a limit to how many objects The Graph can return per query?
+
+By default, query responses are limited to 100 items per collection. If you want to receive more, you can go up to 1000 items per collection and beyond that, you can paginate with:
+
+```graphql
+someCollection(first: 1000, skip: <number>) { ... }
+```
+
+### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+
+Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+
+## Miscellaneous
+
+### 24. Is it possible to use Apollo Federation on top of graph-node?
+
+Federation is not supported yet. At the moment, you can use schema stitching, either on the client or via a proxy service.
+
+### 25. I want to contribute or add a GitHub issue. Where can I find the open source repositories?
+
+- [graph-node](https://github.com/graphprotocol/graph-node)
+- [graph-tooling](https://github.com/graphprotocol/graph-tooling)
+- [graph-docs](https://github.com/graphprotocol/docs)
+- [graph-client](https://github.com/graphprotocol/graph-client)

From 5ffcb72be6c78ccea441fceebe5157bd508aace8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:06 -0500
Subject: [PATCH 1924/3820] New translations introduction.mdx (Romanian)

---
 .../ro/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/introduction.mdx

diff --git a/website/pages/ro/subgraphs/developing/introduction.mdx b/website/pages/ro/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..a3dea2c9a29d
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Overview
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 28bfb191e07e1f6fc8e4f86c757249431a5c3340 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:07 -0500
Subject: [PATCH 1925/3820] New translations introduction.mdx (French)

---
 .../fr/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/introduction.mdx

diff --git a/website/pages/fr/subgraphs/developing/introduction.mdx b/website/pages/fr/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..c9a871b50377
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Aperçu
+
+En tant que développeur, vous avez besoin de données pour construire et alimenter votre d'Api. Interroger et indexer des données blockchain constitue un défi, mais The Graph fournit une solution à ce problème.
+
+Sur The Graph, vous pouvez :
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Utiliser GraphQL pour interroger des subgraphs existants.
+
+### Qu'est-ce que GraphQL ?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Actions des Développeurs
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Créer des subgraphs personnalisés pour répondre à des besoins de données spécifiques, permettant une meilleure évolutivité et flexibilité pour les autres développeurs.
+- Déployer, publier et signaler vos subgraphs au sein de The Graph Network.
+
+### Que sont les subgraphs ?
+
+Un subgraph est une API personnalisée construite sur des données blockchain. Il extrait des données d'une blockchain, les traite et les stocke afin qu'elles puissent être facilement interrogées via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From baf214b7e156c4b2345101db918f9ba9a8c071d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:08 -0500
Subject: [PATCH 1926/3820] New translations introduction.mdx (Spanish)

---
 .../es/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/introduction.mdx

diff --git a/website/pages/es/subgraphs/developing/introduction.mdx b/website/pages/es/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..42cb9340fddb
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Descripción
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 4312b826e1f7d686debe94600dd6a7c06ebede17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:09 -0500
Subject: [PATCH 1927/3820] New translations introduction.mdx (Arabic)

---
 .../ar/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/introduction.mdx

diff --git a/website/pages/ar/subgraphs/developing/introduction.mdx b/website/pages/ar/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..5738a9e70677
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## نظره عامة
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From df8d8ae0e5759185cb51a5ad3158a6c98486ea2f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:10 -0500
Subject: [PATCH 1928/3820] New translations introduction.mdx (Czech)

---
 .../cs/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/introduction.mdx

diff --git a/website/pages/cs/subgraphs/developing/introduction.mdx b/website/pages/cs/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..337cb3be74ee
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Přehled
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From ca715b763676e72593e436f852a3c8cca4f8c45e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:11 -0500
Subject: [PATCH 1929/3820] New translations introduction.mdx (German)

---
 .../de/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/introduction.mdx

diff --git a/website/pages/de/subgraphs/developing/introduction.mdx b/website/pages/de/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..a3dea2c9a29d
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Overview
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 1fb90ad32320a77634a8a2d0db5bd0ddafcc1f99 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:12 -0500
Subject: [PATCH 1930/3820] New translations introduction.mdx (Italian)

---
 .../it/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/introduction.mdx

diff --git a/website/pages/it/subgraphs/developing/introduction.mdx b/website/pages/it/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..f162b67fae40
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Panoramica
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From e02b25d52660048498a6851af0097a6f5c0b4496 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:13 -0500
Subject: [PATCH 1931/3820] New translations introduction.mdx (Japanese)

---
 .../ja/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/introduction.mdx

diff --git a/website/pages/ja/subgraphs/developing/introduction.mdx b/website/pages/ja/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..a4dc1fd671e7
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## 概要
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From b10ebb6dba2bb283a2a8878fd26d37011b57f303 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:14 -0500
Subject: [PATCH 1932/3820] New translations introduction.mdx (Korean)

---
 .../ko/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/introduction.mdx

diff --git a/website/pages/ko/subgraphs/developing/introduction.mdx b/website/pages/ko/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..a3dea2c9a29d
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Overview
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 9ec56655e643a4df0e435292bacc007e7a9b0140 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:15 -0500
Subject: [PATCH 1933/3820] New translations introduction.mdx (Dutch)

---
 .../nl/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/introduction.mdx

diff --git a/website/pages/nl/subgraphs/developing/introduction.mdx b/website/pages/nl/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..a3dea2c9a29d
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Overview
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 4b8f451b296c6fdde24eb96d3152c73f91d079c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:16 -0500
Subject: [PATCH 1934/3820] New translations introduction.mdx (Polish)

---
 .../pl/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/introduction.mdx

diff --git a/website/pages/pl/subgraphs/developing/introduction.mdx b/website/pages/pl/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..a3dea2c9a29d
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Overview
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From f0588c683a4c078cc2b491e174e83ea7cf5ad97d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:17 -0500
Subject: [PATCH 1935/3820] New translations introduction.mdx (Portuguese)

---
 .../pt/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/introduction.mdx

diff --git a/website/pages/pt/subgraphs/developing/introduction.mdx b/website/pages/pt/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..1c5b6172fc5c
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Visão geral
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 28d35d3676c23bcfe79a570f3f772f104faa6f04 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:18 -0500
Subject: [PATCH 1936/3820] New translations introduction.mdx (Russian)

---
 .../ru/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/introduction.mdx

diff --git a/website/pages/ru/subgraphs/developing/introduction.mdx b/website/pages/ru/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..0171f49bfb8b
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Обзор
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 0b3c72b5753e38f632916e036a08750095d55b9a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:19 -0500
Subject: [PATCH 1937/3820] New translations introduction.mdx (Swedish)

---
 .../sv/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/introduction.mdx

diff --git a/website/pages/sv/subgraphs/developing/introduction.mdx b/website/pages/sv/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..4a7a65f6deb5
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Översikt
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 9a8713408c520bf4ed0b06a139931f1c402957ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:20 -0500
Subject: [PATCH 1938/3820] New translations introduction.mdx (Turkish)

---
 .../tr/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/introduction.mdx

diff --git a/website/pages/tr/subgraphs/developing/introduction.mdx b/website/pages/tr/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..296fa0514ee2
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Genel Bakış
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 14744ec94a5df3a365012ed4d2e9a4bc53e6a4da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:21 -0500
Subject: [PATCH 1939/3820] New translations introduction.mdx (Ukrainian)

---
 .../uk/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/introduction.mdx

diff --git a/website/pages/uk/subgraphs/developing/introduction.mdx b/website/pages/uk/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..a3dea2c9a29d
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Overview
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 540fba62565e754d2c4da687c4d3dc1a4f6f331b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:22 -0500
Subject: [PATCH 1940/3820] New translations introduction.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/introduction.mdx

diff --git a/website/pages/zh/subgraphs/developing/introduction.mdx b/website/pages/zh/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..5e6983f7305e
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## 概述
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 823f3c98a2a36905dcba5a7bd1af92e258e7cea8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:23 -0500
Subject: [PATCH 1941/3820] New translations introduction.mdx (Urdu (Pakistan))

---
 .../ur/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/introduction.mdx

diff --git a/website/pages/ur/subgraphs/developing/introduction.mdx b/website/pages/ur/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..fdf956ba83fc
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## جائزہ
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 647892a625cde2525d591344feb30ac64ccbfdba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:24 -0500
Subject: [PATCH 1942/3820] New translations introduction.mdx (Vietnamese)

---
 .../vi/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/introduction.mdx

diff --git a/website/pages/vi/subgraphs/developing/introduction.mdx b/website/pages/vi/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..1295d844275f
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Tổng quan
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 713027d535e7c3b7689fd10c959cba8db920c9ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:25 -0500
Subject: [PATCH 1943/3820] New translations introduction.mdx (Marathi)

---
 .../mr/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/introduction.mdx

diff --git a/website/pages/mr/subgraphs/developing/introduction.mdx b/website/pages/mr/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..94b4d9fd9c21
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## सविश्लेषण
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 5816141e1247e225c3d1121ac3bfa7d3b00831ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:26 -0500
Subject: [PATCH 1944/3820] New translations introduction.mdx (Hindi)

---
 .../hi/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/introduction.mdx

diff --git a/website/pages/hi/subgraphs/developing/introduction.mdx b/website/pages/hi/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..f684a41ac777
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## अवलोकन
+
+एक डेवलपर के रूप में, आपको अपने dapp को बनाने और शक्ति प्रदान करने के लिए डेटा की आवश्यकता होती है। ब्लॉकचेन डेटा को क्वेरी करना और इंडेक्स करना चुनौतीपूर्ण होता है, लेकिन The Graph इस समस्या का समाधान प्रदान करता है।
+
+The Graph पर, आप:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. मौजूदा subgraphs को क्वेरी करने के लिए GraphQL का उपयोग करें।
+
+### GraphQL क्या है?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### डेवलपर क्रियाएँ
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- विशिष्ट डेटा आवश्यकताओं को पूरा करने के लिए कस्टम सबग्राफ़ बनाएं, जिससे अन्य डेवलपर्स के लिए स्केलेबिलिटी और लचीलापन में सुधार हो सके।
+- अपने subgraphs को The Graph Network में तैनात करें, प्रकाशित करें और संकेत दें।
+
+### सबग्राफ़ क्या हैं?
+
+एक Subgraph एक कस्टम API है जो ब्लॉकचेन डेटा पर आधारित होता है। यह ब्लॉकचेन से डेटा निकालता है, उसे प्रोसेस करता है, और उसे इस तरह से संग्रहित करता है कि उसे GraphQL के माध्यम से आसानी से क्वेरी किया जा सके।
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From 699e032d541c784fcadc5f9d3b65d76b4ebcfe51 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:27 -0500
Subject: [PATCH 1945/3820] New translations introduction.mdx (Swahili)

---
 .../sw/subgraphs/developing/introduction.mdx  | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/introduction.mdx

diff --git a/website/pages/sw/subgraphs/developing/introduction.mdx b/website/pages/sw/subgraphs/developing/introduction.mdx
new file mode 100644
index 000000000000..a3dea2c9a29d
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/introduction.mdx
@@ -0,0 +1,30 @@
+---
+title: Introduction to Subgraph Development
+---
+
+To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+
+## Overview
+
+As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+
+On The Graph, you can:
+
+1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+2. Use GraphQL to query existing subgraphs.
+
+### What is GraphQL?
+
+- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+
+### Developer Actions
+
+- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
+- Deploy, publish and signal your subgraphs within The Graph Network.
+
+### What are subgraphs?
+
+A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+
+Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From df3278c14d3b67b6b08bb0e35d1ba4799295d0be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:28 -0500
Subject: [PATCH 1946/3820] New translations deleting-a-subgraph.mdx (Romanian)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/ro/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/ro/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..5a4ac15e07fd
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Curators will not be able to signal on the subgraph anymore.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From eab97e0e45e521fdb81636389d1f1d43a2c8beb4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:29 -0500
Subject: [PATCH 1947/3820] New translations deleting-a-subgraph.mdx (French)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..b9c7f99a89a7
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Étape par Étape
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Les curateurs ne seront plus en mesure de signaler le subgraph.
+- Les Curateurs qui ont déjà signalé sur le subgraph peuvent retirer leur signal à un prix moyen par action.
+- Deleted subgraphs will show an error message.

From 263163a6db1c7305ddd3c6efb4b50eb48e199d78 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:31 -0500
Subject: [PATCH 1948/3820] New translations deleting-a-subgraph.mdx (Spanish)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/es/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/es/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..972a4f552c25
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Los Curadores ya no podrán señalar en el subgrafo.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From 4a9e030b8db53e635e3747b053e4bff6f034500c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:32 -0500
Subject: [PATCH 1949/3820] New translations deleting-a-subgraph.mdx (Arabic)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/ar/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/ar/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..5a4ac15e07fd
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Curators will not be able to signal on the subgraph anymore.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From ddcd91749818018647f46865fc6ec4879b4075ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:33 -0500
Subject: [PATCH 1950/3820] New translations deleting-a-subgraph.mdx (Czech)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/cs/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/cs/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..77896e36a45d
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Kurátoři již nebudou moci signalizovat na podgrafu.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From a8f5d728015e5d3050b8929b9cf193936a9ed979 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:34 -0500
Subject: [PATCH 1951/3820] New translations deleting-a-subgraph.mdx (German)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/de/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/de/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..91c22f7c44ba
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Schritt für Schritt
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Curators will not be able to signal on the subgraph anymore.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From 3daf730e4c7a7a27d99df308cfe565d45ce2fb74 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:35 -0500
Subject: [PATCH 1952/3820] New translations deleting-a-subgraph.mdx (Italian)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/it/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/it/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..90a2eb4b7d33
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- I Curator non potranno più segnalare il subgraph.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From bb527d6b8b359bc6633a18704d1ece94392da6b5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:36 -0500
Subject: [PATCH 1953/3820] New translations deleting-a-subgraph.mdx (Japanese)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/ja/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/ja/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..6a9aef388d02
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- キュレーターは、サブグラフにシグナルを送ることができなくなります。
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From 5197088749defbe326464185c3a072b6161c15d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:37 -0500
Subject: [PATCH 1954/3820] New translations deleting-a-subgraph.mdx (Korean)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/ko/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/ko/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..5a4ac15e07fd
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Curators will not be able to signal on the subgraph anymore.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From ddf21a455012af4f08a3955d08e1ab3cb54f3cef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:38 -0500
Subject: [PATCH 1955/3820] New translations deleting-a-subgraph.mdx (Dutch)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/nl/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/nl/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..5a4ac15e07fd
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Curators will not be able to signal on the subgraph anymore.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From 1442e59b3e1f363ed6f54096da731a40cda8e88b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:39 -0500
Subject: [PATCH 1956/3820] New translations deleting-a-subgraph.mdx (Polish)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/pl/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/pl/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..5a4ac15e07fd
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Curators will not be able to signal on the subgraph anymore.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From fe32f728ac45501ae6a70bd1e3a12bc279e2f482 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:41 -0500
Subject: [PATCH 1957/3820] New translations deleting-a-subgraph.mdx
 (Portuguese)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/pt/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/pt/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..d5305fe2cfbe
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Passo a Passo
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Os curadores não poderão mais sinalizar no subgraph depreciado.
+- Curadores que já sinalizaram no subgraph poderão retirar a sua sinalização a um preço de ação normal.
+- Deleted subgraphs will show an error message.

From 28c0fad85163cf25d1852212dd48d4ceb7dd7ff8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:42 -0500
Subject: [PATCH 1958/3820] New translations deleting-a-subgraph.mdx (Russian)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/ru/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/ru/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..5787620c079a
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Пошаговое руководство
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Кураторы больше не смогут сигналить на сабграф.
+- Кураторы, уже подавшие сигнал на субграф, могут отозвать свой сигнал по средней цене доли.
+- Deleted subgraphs will show an error message.

From d7fc83932aec1a387aba16ab97c507db66875aa0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:43 -0500
Subject: [PATCH 1959/3820] New translations deleting-a-subgraph.mdx (Swedish)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/sv/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/sv/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..ae778febe161
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Kuratorer kommer inte längre kunna signalera på subgrafet.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From 58cd9200ae9444e4575d6468fa9fc5d0cf8b19fd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:44 -0500
Subject: [PATCH 1960/3820] New translations deleting-a-subgraph.mdx (Turkish)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/tr/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/tr/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..e4564fc247f2
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Adım Adım
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Curators will not be able to signal on the subgraph anymore.
+- Subgraph'e halihazırda sinyal vermiş küratörler, sinyallerini ortalama hisse fiyatından geri çekebilir.
+- Deleted subgraphs will show an error message.

From a36c4279500fb6b6ae765a05acc14a93e62f5312 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:45 -0500
Subject: [PATCH 1961/3820] New translations deleting-a-subgraph.mdx
 (Ukrainian)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/uk/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/uk/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..5a4ac15e07fd
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Curators will not be able to signal on the subgraph anymore.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From 321f17e5e495293917692470d3b30d8f33063b42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:46 -0500
Subject: [PATCH 1962/3820] New translations deleting-a-subgraph.mdx (Chinese
 Simplified)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/zh/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/zh/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..dff170e3730f
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- 策展人将无法再对该子图发出信号。
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From e0be4cc12ef111197454db6fdf1b0ccfd7f2d906 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:47 -0500
Subject: [PATCH 1963/3820] New translations deleting-a-subgraph.mdx (Urdu
 (Pakistan))

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/ur/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/ur/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..f078c166db88
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- کیوریٹرز اب سب گراف پر سگنل نہیں دے سکیں گے.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From b9f965fd250e1cb994ac582474f7d2a71322c819 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:48 -0500
Subject: [PATCH 1964/3820] New translations deleting-a-subgraph.mdx
 (Vietnamese)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/vi/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/vi/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..5a4ac15e07fd
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Curators will not be able to signal on the subgraph anymore.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From ab81cc20f32a22ec01a9a5cbeb9a7a3ed2b4777a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:49 -0500
Subject: [PATCH 1965/3820] New translations deleting-a-subgraph.mdx (Marathi)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/mr/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/mr/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..cabf1261970a
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- क्युरेटर यापुढे सबग्राफवर सिग्नल करू शकणार नाहीत.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From c57c72510fb8e3e868d30e2835de68e17803a685 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:50 -0500
Subject: [PATCH 1966/3820] New translations deleting-a-subgraph.mdx (Hindi)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/hi/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/hi/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..e0889b86b0ab
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## चरण-दर-चरण
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- क्यूरेटर अब सबग्राफ पर संकेत नहीं दे पाएंगे।
+- Subgraph पर पहले से संकेत कर चुके Curators औसत शेयर मूल्य पर अपना संकेत वापस ले सकते हैं।
+- Deleted subgraphs will show an error message.

From b5d1768c8d50011c0c35b37b78aa40dc2a760abd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:51 -0500
Subject: [PATCH 1967/3820] New translations deleting-a-subgraph.mdx (Swahili)

---
 .../managing/deleting-a-subgraph.mdx          | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/managing/deleting-a-subgraph.mdx

diff --git a/website/pages/sw/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/sw/subgraphs/developing/managing/deleting-a-subgraph.mdx
new file mode 100644
index 000000000000..5a4ac15e07fd
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -0,0 +1,31 @@
+---
+title: Deleting a Subgraph
+---
+
+Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+
+> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+
+## Step-by-Step
+
+1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+
+2. Click on the three-dots to the right of the "publish" button.
+
+3. Click on the option to "delete this subgraph":
+
+   ![Delete-subgraph](/img/Delete-subgraph.png)
+
+4. Depending on the subgraph's status, you will be prompted with various options.
+
+   - If the subgraph is not published, simply click “delete” and confirm.
+   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+
+> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+
+### Important Reminders
+
+- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Curators will not be able to signal on the subgraph anymore.
+- Curators that already signaled on the subgraph can withdraw their signal at an average share price.
+- Deleted subgraphs will show an error message.

From d06f99cbcd84524bdb4f2646229bbc4ce489c84a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:52 -0500
Subject: [PATCH 1968/3820] New translations publishing-a-subgraph.mdx
 (Romanian)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/ro/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/ro/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..36ac9f489a78
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publishing a Subgraph to the Decentralized Network
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Updating metadata for a published subgraph
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 91de0cc8722e4602dc07452aadd9d17938abf21a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:53 -0500
Subject: [PATCH 1969/3820] New translations publishing-a-subgraph.mdx (French)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/fr/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/fr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..25e96d09f14c
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publication d'un subgraph sur le réseau décentralisé
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+Lorsque vous publiez un subgraph sur le réseau décentralisé, vous le rendez disponible pour :
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publication à partir de Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+Toutes les versions publiées d'un subgraph existant peuvent :
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Mise à jour des métadonnées d'un subgraph publié
+
+- Après avoir publié votre subgraph sur le réseau décentralisé, vous pouvez mettre à jour les métadonnées à tout moment dans Subgraph Studio.
+- Une fois que vous avez enregistré vos modifications et publié les mises à jour, elles apparaîtront dans Graph Explorer.
+- Il est important de noter que ce processus ne créera pas une nouvelle version puisque votre déploiement n'a pas changé.
+
+## Publication à partir de la CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Ouvrez le `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. Une fenêtre s'ouvrira, vous permettant de connecter votre portefeuille, d'ajouter des métadonnées et de déployer votre subgraph finalisé sur le réseau de votre choix.
+
+![cli-ui](/img/cli-ui.png)
+
+### Personnalisation de votre déploiement
+
+Vous pouvez uploader votre build de subgraph sur un nœud IPFS spécifique et personnaliser davantage votre déploiement avec les options suivantes :
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Ajout de signal à votre subgraph
+
+Les développeurs peuvent ajouter des signaux GRT à leurs subgraphs pour inciter les Indexeurs à interroger le subgraph.
+
+- Si un subgraph est éligible aux récompenses d'indexation, les Indexeurs qui fournissent une "preuve d'indexation" recevront une récompense en GRT, basée sur la quantité de GRT signalée.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Ajouter un signal à un subgraph non éligible aux récompenses n'attirera pas d'Indexeurs supplémentaires.
+>
+> Si votre subgraph est éligible aux récompenses, il est recommandé de curer votre propre subgraph avec au moins 3 000 GRT afin d'attirer des indexeurs supplémentaires pour indexer votre subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+Lors du signalement, les Curateurs peuvent décider de signaler une version spécifique du subgraph ou de signaler en utilisant l'auto-migration. S'ils signalent en utilisant l'auto-migration, les parts d'un Curateur seront toujours mises à jour vers la dernière version publiée par le développeur. S'ils décident de signaler une version spécifique, les parts resteront toujours sur cette version spécifique.
+
+Les Indexeurs peuvent trouver des subgraphs à indexer en fonction des signaux de curation qu'ils voient dans Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio vous permet d'ajouter des signaux à votre subgraph en ajoutant des GRT au pool de curation de votre subgraph dans la même transaction où il est publié.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternativement, vous pouvez ajouter des signaux GRT à un subgraph publié à partir de Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From cf60336ab222d7f32daa92857400556ae1b3b100 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:54 -0500
Subject: [PATCH 1970/3820] New translations publishing-a-subgraph.mdx
 (Spanish)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/es/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/es/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..acec898396c2
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publicación de un subgrafo en la Red Descentralizada
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Actualización de los metadatos de un subgrafo publicado
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 11c304a63352288ba246dfec587addf83687d724 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:55 -0500
Subject: [PATCH 1971/3820] New translations publishing-a-subgraph.mdx (Arabic)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/ar/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/ar/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..36ac9f489a78
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publishing a Subgraph to the Decentralized Network
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Updating metadata for a published subgraph
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From a81c9e50d407ae84ea97138a247c64b78f0f71ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:56 -0500
Subject: [PATCH 1972/3820] New translations publishing-a-subgraph.mdx (Czech)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/cs/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/cs/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..a9d45f734d18
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Zveřejnění podgrafu v decentralizované síti
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Aktualizace metadata publikovaného podgrafu
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Přidání signálu do podgrafu
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Přidání signálu do podgrafu, který nemá nárok na odměny, nepřiláká další indexátory.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Případně můžete přidat signál GRT do publikovaného podgrafu z Průzkumníka grafů.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 1da2717cfafa95848f3413f355553ec9f38cf559 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:57 -0500
Subject: [PATCH 1973/3820] New translations publishing-a-subgraph.mdx (German)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..bc605e4e3705
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publishing a Subgraph to the Decentralized Network
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Updating metadata for a published subgraph
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Öffnen Sie den `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 010489fcf845f17af09033772cb9a91bbb2b8e45 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:58 -0500
Subject: [PATCH 1974/3820] New translations publishing-a-subgraph.mdx
 (Italian)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/it/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/it/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..d28a5e0a2490
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Pubblicare un subgraph nella rete decentralizzata
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Aggiornamento dei metadati per un subgraph pubblicato
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 2bf8613e0ec30f885a9476db21a052d856c70339 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:19:59 -0500
Subject: [PATCH 1975/3820] New translations publishing-a-subgraph.mdx
 (Japanese)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/ja/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/ja/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..9b71c25363b6
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: 分散型ネットワークへのサブグラフの公開
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### パブリッシュされたサブグラフのメタデータの更新
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 40b97a75ddfc7381ecb3c6123a2059d78394a7be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:00 -0500
Subject: [PATCH 1976/3820] New translations publishing-a-subgraph.mdx (Korean)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/ko/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/ko/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..36ac9f489a78
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publishing a Subgraph to the Decentralized Network
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Updating metadata for a published subgraph
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 700599144406b753770b07879c0a50b5bcd2d946 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:01 -0500
Subject: [PATCH 1977/3820] New translations publishing-a-subgraph.mdx (Dutch)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/nl/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/nl/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..36ac9f489a78
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publishing a Subgraph to the Decentralized Network
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Updating metadata for a published subgraph
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 9418224facffa25668b75b44f32729ff17e9f455 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:02 -0500
Subject: [PATCH 1978/3820] New translations publishing-a-subgraph.mdx (Polish)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/pl/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/pl/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..36ac9f489a78
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publishing a Subgraph to the Decentralized Network
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Updating metadata for a published subgraph
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 26f4507bf83dbeb70a208933b78ce7cfd5a8bf00 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:03 -0500
Subject: [PATCH 1979/3820] New translations publishing-a-subgraph.mdx
 (Portuguese)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/pt/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/pt/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..b40bd3b0a3cb
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Como Editar um Subgraph na Rede Descentralizada
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+Ao editar um subgraph à rede descentralizada, ele será disponibilizado para:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Edição do Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+Todas as versões editadas de um subgraph existente podem:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Como atualizar metadados para um subgraph editado
+
+- Após editar o seu subgraph à rede descentralizada, será possível editar os metadados a qualquer hora no Subgraph Studio.
+- Após salvar as suas mudanças e publicar as atualizações, elas aparecerão no Graph Explorer.
+- É importante notar que este processo não criará uma nova versão, já que a sua edição não terá mudado.
+
+## Publicação da CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. Uma janela será aberta para o programador conectar a sua carteira, adicionar metadados e lançar o seu subgraph finalizado a uma rede de sua escolha.
+
+![cli-ui](/img/cli-ui.png)
+
+### Como personalizar o seu lançamento
+
+É possível enviar a sua build a um node IPFS específico e personalizar ainda mais o seu lançamento com as seguintes flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Como adicionar sinal ao seu subgraph
+
+Programadores podem adicionar sinal de GRT aos seus subgraphs para incentivar Indexadores a consultarem o subgraph.
+
+- Se um subgraph for elegível para recompensas de indexação, Indexadores que providenciarem uma "prova de indexação" receberão uma recompensa em GRT com base na quantidade de GRT sinalizada.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adicionar sinais a um subgraph que não for elegível não atrairá mais Indexadores.
+>
+> Se o seu subgraph for elegível a recompensas, recomendamos que cure o seu próprio subgraph com, no mínimo, 3000 GRT para atrair mais Indexadores ao seu subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+Ao sinalizar, Curadores podem decidir entre sinalizar numa versão específica do subgraph ou sinalizar com a automigração. Caso sinalizem com a automigração, as ações de um curador sempre serão atualizadas à versão mais recente publicada pelo programador. Se decidirem sinalizar numa versão específica, as ações sempre permanecerão nesta versão específica.
+
+Os indexadores podem achar subgraphs para indexar com base em sinais de curadoria que veem no Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+O Subgraph Studio lhe permite adicionar sinais ao seu subgraph ao adicionar GRT ao pool de curadoria na mesma transação em que são publicados.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Como alternativa, é possível adicionar sinais em GRT a um subgraph editado a partir do Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 7018d856737bbf3414bc05f107d9610fa80cee62 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:04 -0500
Subject: [PATCH 1980/3820] New translations publishing-a-subgraph.mdx
 (Russian)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/ru/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/ru/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..e3b0ed81b9f9
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Публикация подграфа в децентрализованной сети
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Updating metadata for a published subgraph
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Откройте `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From a8859c040518eda44405edd169a6da115ca55e9f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:05 -0500
Subject: [PATCH 1981/3820] New translations publishing-a-subgraph.mdx
 (Swedish)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/sv/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/sv/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..709f954cad6b
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publicera en Subgraph på Det Decentraliserade Nätverket
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Uppdatera metadata för en publicerad subgraph
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 9e826f6474ef8bec652282a150b53eefcfc6cbb5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:07 -0500
Subject: [PATCH 1982/3820] New translations publishing-a-subgraph.mdx
 (Turkish)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..fae52524322d
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publishing a Subgraph to the Decentralized Network
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Yayınlanan bir subgraph için üst veri güncelleme
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. `graph-cli`yi açın.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From e622894ccc993ec4e9a4d0b7bf0e463022503574 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:08 -0500
Subject: [PATCH 1983/3820] New translations publishing-a-subgraph.mdx
 (Ukrainian)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/uk/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/uk/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..36ac9f489a78
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publishing a Subgraph to the Decentralized Network
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Updating metadata for a published subgraph
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 0b66a69491936c86a9205cfd78cc00bca0e89cbe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:09 -0500
Subject: [PATCH 1984/3820] New translations publishing-a-subgraph.mdx (Chinese
 Simplified)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/zh/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/zh/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..0f9ff32e92d1
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: 向去中心化的网络发布子图
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### 更新已发布的子图的元数据
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From b6959563e85330ae668329586de829a3f0ef4102 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:10 -0500
Subject: [PATCH 1985/3820] New translations publishing-a-subgraph.mdx (Urdu
 (Pakistan))

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/ur/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/ur/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..a32fa938fb8e
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: ڈیسینٹرلائزڈ نیٹ ورک پر سب گراف شائع کرنا
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### شائع شدہ سب گراف کے لیے میٹا ڈیٹا کو اپ ڈیٹ کرنا
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 3bfe2273ada2707d8052aa0260fccb180e4d4ac5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:11 -0500
Subject: [PATCH 1986/3820] New translations publishing-a-subgraph.mdx
 (Vietnamese)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/vi/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/vi/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..36ac9f489a78
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publishing a Subgraph to the Decentralized Network
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Updating metadata for a published subgraph
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From a3a55fbd9526a5ae99bd59fe4bccfa83798b1c5a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:12 -0500
Subject: [PATCH 1987/3820] New translations publishing-a-subgraph.mdx
 (Marathi)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/mr/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/mr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..e7754f78d80e
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: विकेंद्रीकृत नेटवर्कवर सबग्राफ प्रकाशित करणे
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### प्रकाशित सबग्राफसाठी मेटाडेटा अपडेट करत आहे
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From f9bff25dd9a84b1a4aca5cbaf9cf280cef20cb09 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:13 -0500
Subject: [PATCH 1988/3820] New translations publishing-a-subgraph.mdx (Hindi)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/hi/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/hi/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..60a448149d22
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: विकेंद्रीकृत नेटवर्क के लिए एक सबग्राफ प्रकाशित करना
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+जब आप एक subgraph को विकेंद्रीकृत नेटवर्क पर प्रकाशित करते हैं, तो आप इसे उपलब्ध कराते हैं:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Subgraph Studio से प्रकाशित
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+एक मौजूदा subgraph के सभी प्रकाशित संस्करण कर सकते हैं:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### प्रकाशित सबग्राफ के लिए मेटाडेटा अपडेट करना
+
+- अपने सबग्राफ को विकेंद्रीकृत नेटवर्क पर प्रकाशित करने के बाद, आप Subgraph Studio में किसी भी समय मेटाडेटा को अपडेट कर सकते हैं।
+- एक बार जब आप अपने परिवर्तनों को सहेज लेते हैं और अपडेट प्रकाशित कर देते हैं, तो वे Graph Explorer में दिखाई देंगे।
+- यह ध्यान रखना महत्वपूर्ण है कि इस प्रक्रिया से कोई नया संस्करण नहीं बनेगा क्योंकि आपका डिप्लॉयमेंट नहीं बदला है।
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. `graph-cli` खोलें।
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. एक विंडो खुलेगी, जो आपको अपनी वॉलेट कनेक्ट करने, मेटाडेटा जोड़ने, और अपने अंतिम Subgraph को आपकी पसंद के नेटवर्क पर डिप्लॉय करने की अनुमति देगी।
+
+![cli-ui](/img/cli-ui.png)
+
+### अपने डिप्लॉयमेंट को अनुकूलित करना
+
+आप अपने Subgraph बिल्ड को एक विशेष IPFSनोड पर अपलोड कर सकते हैं और निम्नलिखित फ्लैग्स के साथ अपने डिप्लॉयमेंट को और अनुकूलित कर सकते हैं:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+डेवलपर्स अपने Subgraph में GRT सिग्नल जोड़ सकते हैं ताकि Indexer को Subgraph पर क्वेरी करने के लिए प्रेरित किया जा सके।
+
+- यदि कोई Subgraph इंडेक्सिंग पुरस्कारों के लिए पात्र है, तो जो Indexer "इंडेक्सिंग का प्रमाण" प्रदान करते हैं, उन्हें संकेतित GRTकी मात्रा के आधार पर GRT पुरस्कार मिलेगा।
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> यदि आपका Subgraph पुरस्कारों के लिए पात्र है, तो यह अनुशंसा की जाती है कि आप अपने Subgraph को कम से कम 3,000 GRT के साथ क्यूरेट करें ताकि अधिक Indexer को आपके सबग्राफ़ को इंडेक्स करने के लिए आकर्षित किया जा सके।
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio आपको अपने सबग्राफ़ में सिग्नल जोड़ने की सुविधा देता है, जिसमें आप अपने सबग्राफ़ के क्यूरेशन पूल में उसी लेन-देन के साथ GRT जोड़ सकते हैं, जब इसे प्रकाशित किया जाता है.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From dee7054914df60eadaf4b7732ee23a2bd392afc6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:14 -0500
Subject: [PATCH 1989/3820] New translations publishing-a-subgraph.mdx
 (Swahili)

---
 .../publishing/publishing-a-subgraph.mdx      | 94 +++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/publishing/publishing-a-subgraph.mdx

diff --git a/website/pages/sw/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/sw/subgraphs/developing/publishing/publishing-a-subgraph.mdx
new file mode 100644
index 000000000000..36ac9f489a78
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -0,0 +1,94 @@
+---
+title: Publishing a Subgraph to the Decentralized Network
+---
+
+Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+
+When you publish a subgraph to the decentralized network, you make it available for:
+
+- [Curators](/resources/roles/curating/) to begin curating it.
+- [Indexers](/indexing/overview/) to begin indexing it.
+
+<VideoEmbed youtube="satdwdbvzAQ" />
+
+Check out the list of [supported networks](/supported-networks/).
+
+## Publishing from Subgraph Studio
+
+1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
+2. Click on the **Publish** button
+3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+
+All published versions of an existing subgraph can:
+
+- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+
+- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+
+### Updating metadata for a published subgraph
+
+- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
+- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
+- It's important to note that this process will not create a new version since your deployment has not changed.
+
+## Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+
+1. Open the `graph-cli`.
+2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+### Customizing your deployment
+
+You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+
+```
+USAGE
+  $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
+    <value>]
+
+FLAGS
+  -h, --help                   Show CLI help.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
+  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
+  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+                               <options: arbitrum-one|arbitrum-sepolia>
+  --subgraph-id=<value>        Subgraph ID to publish to.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+
+```
+
+## Adding signal to your subgraph
+
+Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+
+- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+
+- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+- Specific supported networks can be checked [here](/supported-networks/).
+
+> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+>
+> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+
+The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+
+When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+
+Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+
+![Explorer subgraphs](/img/explorer-subgraphs.png)
+
+Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+
+![Curation Pool](/img/curate-own-subgraph-tx.png)
+
+Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+
+![Signal from Explorer](/img/signal-from-explorer.png)
+
+Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 605e958fd4bf6a982bb51b955e1b3f3d7b2f9602 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:15 -0500
Subject: [PATCH 1990/3820] New translations subgraphs.mdx (Romanian)

---
 .../ro/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/ro/subgraphs/developing/subgraphs.mdx b/website/pages/ro/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..951ec74234d1
--- /dev/null
+++ b/website/pages/ro/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraphs
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Subgraph Lifecycle
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From f27e1621dd594f6cc11e291dc7aff49b90b99686 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:16 -0500
Subject: [PATCH 1991/3820] New translations subgraphs.mdx (French)

---
 .../fr/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/fr/subgraphs/developing/subgraphs.mdx b/website/pages/fr/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..2328038d075f
--- /dev/null
+++ b/website/pages/fr/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraphs
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Flux du cycle de vie des subgraphes
+
+Voici un aperçu général du cycle de vie d'un subgraph :
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 3662ae88172a60b81308b2709b558c57c29836b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:17 -0500
Subject: [PATCH 1992/3820] New translations subgraphs.mdx (Spanish)

---
 .../es/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/es/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/es/subgraphs/developing/subgraphs.mdx b/website/pages/es/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..f7046bd367c7
--- /dev/null
+++ b/website/pages/es/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgrafos
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Ciclo de vida de un Subgrafo
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 58c3f9a896eeea8bda6b933bdf10f0c69ace2666 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:18 -0500
Subject: [PATCH 1993/3820] New translations subgraphs.mdx (Arabic)

---
 .../ar/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/ar/subgraphs/developing/subgraphs.mdx b/website/pages/ar/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..b52ec5cd2843
--- /dev/null
+++ b/website/pages/ar/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraphs
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## دورة حياة الـ Subgraph
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 6122e0e7ca3acc8540a5f5bb609f6e72b8b061f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:19 -0500
Subject: [PATCH 1994/3820] New translations subgraphs.mdx (Czech)

---
 .../cs/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/cs/subgraphs/developing/subgraphs.mdx b/website/pages/cs/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..f197aabdc49c
--- /dev/null
+++ b/website/pages/cs/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Podgrafy
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Životní cyklus podgrafů
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From cefe4c698d5db5c6b5b106971128817fdd5f8526 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:20 -0500
Subject: [PATCH 1995/3820] New translations subgraphs.mdx (German)

---
 .../de/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/de/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/de/subgraphs/developing/subgraphs.mdx b/website/pages/de/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..9e5dc5f613a6
--- /dev/null
+++ b/website/pages/de/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraphs
+---
+
+## Was ist ein Subgraph?
+
+Ein Subgraph ist eine benutzerdefinierte, offene API, die Daten aus einer Blockchain extrahiert, verarbeitet und so speichert, dass sie einfach über GraphQL abgefragt werden können.
+
+### Subgraph-Fähigkeiten
+
+- **Zugangsdaten:** Subgraphs ermöglichen die Abfrage und Indizierung von Blockchain-Daten für web3.
+- **Build:** Entwickler können Subgraphs für The Graph Network erstellen, bereitstellen und veröffentlichen. Um loszulegen, schauen Sie sich den Subgraph Entwickler [Quick Start](quick-start/) an.
+- **Index & Abfrage:** Sobald ein Subgraph indiziert ist, kann jeder ihn abfragen. Alle im Netzwerk veröffentlichten Subgraphen können im [Graph Explorer] (https://thegraph.com/explorer) untersucht und abgefragt werden.
+
+## Innerhalb eines Subgraph
+
+Das Subgraph-Manifest, `subgraph.yaml`, definiert die Smart Contracts und das Netzwerk, die Ihr Subgraph indizieren wird, die Ereignisse aus diesen Verträgen, auf die geachtet werden soll, und wie die Ereignisdaten auf Entitäten abgebildet werden, die Graph Node speichert und abfragen kann.
+
+Die **Subgraph-Definition** besteht aus den folgenden Dateien:
+
+- subgraph.yaml": Enthält das Manifest des Subgraphen
+
+- schema.graphql": Ein GraphQL-Schema, das die für Ihren Subgraph gespeicherten Daten definiert und festlegt, wie sie über GraphQL abgefragt werden können
+
+- mapping.ts\`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) Code, der die Ereignisdaten in die in Ihrem Schema definierten Entitäten übersetzt
+
+Um mehr über die einzelnen Komponenten eines Subgraphs zu erfahren, lesen Sie bitte [Erstellen eines Subgraphs](/developing/creating-a-subgraph/).
+
+## Subgraph Lebenszyklus
+
+Hier ist ein allgemeiner Überblick über den Lebenszyklus eines Subgraphs:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Entwicklung
+
+1. [Einen Subgraph erstellen](/entwickeln/einen-subgraph-erstellen/)
+2. [Einen Subgraph bereitstellen](/deploying/deploying-a-subgraph-to-studio/)
+3. [Testen eines Subgraphen](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 446fc510114775ac8dcda7aa9c6d631ae74aa851 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:21 -0500
Subject: [PATCH 1996/3820] New translations subgraphs.mdx (Italian)

---
 .../it/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/it/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/it/subgraphs/developing/subgraphs.mdx b/website/pages/it/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..80352fc29ed5
--- /dev/null
+++ b/website/pages/it/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraph
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Ciclo di vita del subgraph
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 5630847da4571b89a37ab958ed23fbe162540689 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:22 -0500
Subject: [PATCH 1997/3820] New translations subgraphs.mdx (Japanese)

---
 .../ja/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/ja/subgraphs/developing/subgraphs.mdx b/website/pages/ja/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..9f1d50744aab
--- /dev/null
+++ b/website/pages/ja/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: サブグラフ
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## サブグラフのライフサイクル
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From bb5448b36c5ad044543df56662ea1c8226940293 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:24 -0500
Subject: [PATCH 1998/3820] New translations subgraphs.mdx (Korean)

---
 .../ko/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/ko/subgraphs/developing/subgraphs.mdx b/website/pages/ko/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..951ec74234d1
--- /dev/null
+++ b/website/pages/ko/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraphs
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Subgraph Lifecycle
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 6a084109837dd64749f3936c22236514565ca69d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:25 -0500
Subject: [PATCH 1999/3820] New translations subgraphs.mdx (Dutch)

---
 .../nl/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/nl/subgraphs/developing/subgraphs.mdx b/website/pages/nl/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..951ec74234d1
--- /dev/null
+++ b/website/pages/nl/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraphs
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Subgraph Lifecycle
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From bf2696fdbc711b359675c68c6fc0e49226d4c27b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:26 -0500
Subject: [PATCH 2000/3820] New translations subgraphs.mdx (Polish)

---
 .../pl/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/pl/subgraphs/developing/subgraphs.mdx b/website/pages/pl/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..b81dc8a2d83e
--- /dev/null
+++ b/website/pages/pl/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgrafy
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Subgraph Lifecycle
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 2f3a8e7fa56cb4d8213a332b65c81eab16e797c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:27 -0500
Subject: [PATCH 2001/3820] New translations subgraphs.mdx (Portuguese)

---
 .../pt/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/pt/subgraphs/developing/subgraphs.mdx b/website/pages/pt/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..22a51938b6ac
--- /dev/null
+++ b/website/pages/pt/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraphs
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Ciclo de Vida de um Subgraph
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From f3c6a9e7d834f34ccca1d2162e60fb462e827462 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:28 -0500
Subject: [PATCH 2002/3820] New translations subgraphs.mdx (Russian)

---
 .../ru/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/ru/subgraphs/developing/subgraphs.mdx b/website/pages/ru/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..0b72ece0f8ec
--- /dev/null
+++ b/website/pages/ru/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Субграфы
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Жизненный цикл подграфа
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 79d9794efd0b9f598ac57c1e3a02cb77cc67ebbe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:29 -0500
Subject: [PATCH 2003/3820] New translations subgraphs.mdx (Swedish)

---
 .../sv/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/sv/subgraphs/developing/subgraphs.mdx b/website/pages/sv/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..33fc3b2aeb08
--- /dev/null
+++ b/website/pages/sv/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraffar
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Livscykel för undergrafer
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From e5ef90cdd3e5647ff6fa6b360ff38201b9f7194e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:30 -0500
Subject: [PATCH 2004/3820] New translations subgraphs.mdx (Turkish)

---
 .../tr/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/tr/subgraphs/developing/subgraphs.mdx b/website/pages/tr/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..60c15e0e487e
--- /dev/null
+++ b/website/pages/tr/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraph'ler
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Subgraph Yaşam Döngüsü
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 87235c6e0b9f954feac57c74f8a263f091afe727 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:31 -0500
Subject: [PATCH 2005/3820] New translations subgraphs.mdx (Ukrainian)

---
 .../uk/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/uk/subgraphs/developing/subgraphs.mdx b/website/pages/uk/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..598118d01b51
--- /dev/null
+++ b/website/pages/uk/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Підграфи
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Subgraph Lifecycle
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 01e4d657d2107a104a19d18bd7a0b5f038bb5a73 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:32 -0500
Subject: [PATCH 2006/3820] New translations subgraphs.mdx (Chinese Simplified)

---
 .../zh/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/zh/subgraphs/developing/subgraphs.mdx b/website/pages/zh/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..1541bf9c2dd0
--- /dev/null
+++ b/website/pages/zh/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: 子图
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## 子图生命周期
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From b51c00ff6c530d3be5ddef11023b2326c9c71380 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:33 -0500
Subject: [PATCH 2007/3820] New translations subgraphs.mdx (Urdu (Pakistan))

---
 .../ur/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/ur/subgraphs/developing/subgraphs.mdx b/website/pages/ur/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..25961936c677
--- /dev/null
+++ b/website/pages/ur/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: سب گراف
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## سب گراف لائف سائیکل
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From c44ab573cbd45ae5473af08e47a36fd9493f2c25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:34 -0500
Subject: [PATCH 2008/3820] New translations subgraphs.mdx (Vietnamese)

---
 .../vi/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/vi/subgraphs/developing/subgraphs.mdx b/website/pages/vi/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..951ec74234d1
--- /dev/null
+++ b/website/pages/vi/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraphs
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Subgraph Lifecycle
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 9b34cbebdfe126aa77df6eb007811fcf3284780a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:35 -0500
Subject: [PATCH 2009/3820] New translations subgraphs.mdx (Marathi)

---
 .../mr/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/mr/subgraphs/developing/subgraphs.mdx b/website/pages/mr/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..5b18ec8cf748
--- /dev/null
+++ b/website/pages/mr/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraphs
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## सबग्राफ लाइफसायकल
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From f72a0e4d9e408c280db03892399ee1845abf23de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:36 -0500
Subject: [PATCH 2010/3820] New translations subgraphs.mdx (Hindi)

---
 .../hi/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/hi/subgraphs/developing/subgraphs.mdx b/website/pages/hi/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..153754823989
--- /dev/null
+++ b/website/pages/hi/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: सबग्राफ
+---
+
+## Subgraph क्या है?
+
+एक subgraph एक कस्टम, ओपन API है जो एक ब्लॉकचेन से डेटा निकालता है, उसे प्रोसेस करता है, और उसे इस तरह से स्टोर करता है कि उसे GraphQL के माध्यम से आसानी से क्वेरी किया जा सके।
+
+### Subgraph क्षमताएँ
+
+- डेटा एक्सेस करें: Subgraphs web3 के लिए ब्लॉकचेन डेटा के क्वेरी और इंडेक्सिंग को सक्षम बनाते हैं।
+- बनाएँ: डेवलपर्स The Graph Network पर subgraphs बना सकते हैं, डिप्लॉय कर सकते हैं और प्रकाशित कर सकते हैं। शुरुआत करने के लिए, subgraph डेवलपर Quick Start(quick-start/) देखें।
+- इंडेक्स और क्वेरी: एक बार जब एक subgraph को इंडेक्स किया जाता है, तो कोई भी इसे क्वेरी कर सकता है।GraphExplorer(https://thegraph.com/explorer) में नेटवर्क पर प्रकाशित सभी subgraphs का अन्वेषण और क्वेरी करें।
+
+## एक Subgraph के अंदर
+
+subgraph मैनिफेस्ट, subgraph.yaml, उन स्मार्ट कॉन्ट्रैक्ट्स और नेटवर्क को परिभाषित करता है जिन्हें आपका subgraph इंडेक्स करेगा, इन कॉन्ट्रैक्ट्स से ध्यान देने योग्य इवेंट्स, और इवेंट डेटा को उन संस्थाओं के साथ मैप करने का तरीका जिन्हें Graph Node स्टोर करता है और जिन्हें क्वेरी करने की अनुमति देता है।
+
+**subgraph definition** में निम्नलिखित फ़ाइलें शामिल हैं:
+
+- subgraph.yaml: में subgraph मैनिफेस्ट शामिल है
+
+- schema.graphql: एक GraphQL स्कीमा जो आपके लिए डेटा को परिभाषित करता है और इसे GraphQL के माध्यम से क्वेरी करने का तरीका बताता है.
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+प्रत्येक उपग्राफ घटक के बारे में अधिक जानने के लिए, देखें creating a subgraph(/developing/creating-a-subgraph/).
+
+## सबग्राफ जीवनचक्र
+
+यहाँ एक Subgraph के जीवनचक्र का सामान्य अवलोकन है।
+
+![Subgraph जीवनचक्र ](/img/subgraph-lifecycle.png)
+
+## सबग्राफ विकास
+
+1. [एक subgraph बनाएँ](/developing/creating-a-subgraph/)
+2. [डिप्लॉय a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [एक 'subgraph' का परीक्षण करें](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From 9410eba354a4f421c49bff14790dc95ee62759b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:37 -0500
Subject: [PATCH 2011/3820] New translations subgraphs.mdx (Swahili)

---
 .../sw/subgraphs/developing/subgraphs.mdx     | 86 +++++++++++++++++++
 1 file changed, 86 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/developing/subgraphs.mdx

diff --git a/website/pages/sw/subgraphs/developing/subgraphs.mdx b/website/pages/sw/subgraphs/developing/subgraphs.mdx
new file mode 100644
index 000000000000..951ec74234d1
--- /dev/null
+++ b/website/pages/sw/subgraphs/developing/subgraphs.mdx
@@ -0,0 +1,86 @@
+---
+title: Subgraphs
+---
+
+## What is a Subgraph?
+
+A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+
+### Subgraph Capabilities
+
+- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
+- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
+- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+
+## Inside a Subgraph
+
+The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+
+The **subgraph definition** consists of the following files:
+
+- `subgraph.yaml`: Contains the subgraph manifest
+
+- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+
+- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+
+To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+
+## Subgraph Lifecycle
+
+Here is a general overview of a subgraph’s lifecycle:
+
+![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+
+## Subgraph Development
+
+1. [Create a subgraph](/developing/creating-a-subgraph/)
+2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+
+### Build locally
+
+Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+
+### Deploy to Subgraph Studio
+
+Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+
+- Use its staging environment to index the deployed subgraph and make it available for review.
+- Verify that your subgraph doesn't have any indexing errors and works as expected.
+
+### Publish to the Network
+
+When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+
+- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
+- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
+- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+
+### Add Curation Signal for Indexing
+
+Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+
+#### What is signal?
+
+- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
+- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+
+### Querying & Application Development
+
+Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+
+Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+
+### Updating Subgraphs
+
+To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+
+- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
+- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+
+### Deleting & Transferring Subgraphs
+
+If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).

From a1a5e01d05c22d530cd3c3f633b4012119339bf1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:38 -0500
Subject: [PATCH 2012/3820] New translations explorer.mdx (Romanian)

---
 website/pages/ro/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/explorer.mdx

diff --git a/website/pages/ro/subgraphs/explorer.mdx b/website/pages/ro/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..433821560d85
--- /dev/null
+++ b/website/pages/ro/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraphs
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Signal/Un-signal on subgraphs
+- View more details such as charts, current deployment ID, and other metadata
+- Switch versions to explore past iterations of the subgraph
+- Query subgraphs via GraphQL
+- Test subgraphs in the playground
+- View the Indexers that are indexing on a certain subgraph
+- Subgraph stats (allocations, Curators, etc)
+- View the entity who published the subgraph
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Participants
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexers
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity - the maximum amount of delegated stake the Indexer can productively accept. An excess delegated stake cannot be used for allocations or rewards calculations.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Indexer Rewards - this is the total indexer rewards earned by the Indexer and their Delegators over all time. Indexer rewards are paid through GRT issuance.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curators
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- The date the Curator started curating
+- The number of GRT that was deposited
+- The number of shares a Curator owns
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegators
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- The number of Indexers a Delegator is delegating towards
+- A Delegator’s original delegation
+- The rewards they have accumulated but have not withdrawn from the protocol
+- The realized rewards they withdrew from the protocol
+- Total amount of GRT they have currently in the protocol
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Network
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Overview
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- The current total network stake
+- The stake split between the Indexers and their Delegators
+- Total supply, minted, and burned GRT since the network inception
+- Total Indexing rewards since the inception of the protocol
+- Protocol parameters such as curation reward, inflation rate, and more
+- Current epoch rewards and fees
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epochs
+
+In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
+
+- Epoch start or end block
+- Query fees generated and indexing rewards collected during a specific epoch
+- Epoch status, which refers to the query fee collection and distribution and can have different states:
+  - The active epoch is the one in which Indexers are currently allocating stake and collecting query fees
+  - The settling epochs are the ones in which the state channels are being settled. This means that the Indexers are subject to slashing if the consumers open disputes against them.
+  - The distributing epochs are the epochs in which the state channels for the epochs are being settled and Indexers can claim their query fee rebates.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Your User Profile
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Profile Overview
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Subgraphs Tab
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Indexing Tab
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+This section will also include details about your net Indexer rewards and net query fees. You’ll see the following metrics:
+
+- Delegated Stake - the stake from Delegators that can be allocated by you but cannot be slashed
+- Total Query Fees - the total fees that users have paid for queries served by you over time
+- Indexer Rewards - the total amount of Indexer rewards you have received, in GRT
+- Fee Cut - the % of query fee rebates that you will keep when you split with Delegators
+- Rewards Cut - the % of Indexer rewards that you will keep when splitting with Delegators
+- Owned - your deposited stake, which could be slashed for malicious or incorrect behavior
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Delegating Tab
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+In the first half of the page, you can see your delegation chart, as well as the rewards-only chart. To the left, you can see the KPIs that reflect your current delegation metrics.
+
+The Delegator metrics you’ll see here in this tab include:
+
+- Total delegation rewards
+- Total unrealized rewards
+- Total realized rewards
+
+In the second half of the page, you have the delegations table. Here you can see the Indexers that you delegated towards, as well as their details (such as rewards cuts, cooldown, etc).
+
+With the buttons on the right side of the table, you can manage your delegation - delegate more, undelegate, or withdraw your delegation after the thawing period.
+
+Keep in mind that this chart is horizontally scrollable, so if you scroll all the way to the right, you can also see the status of your delegation (delegating, undelegating, withdrawable).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Curating Tab
+
+In the Curation tab, you’ll find all the subgraphs you’re signaling on (thus enabling you to receive query fees). Signaling allows Curators to highlight to Indexers which subgraphs are valuable and trustworthy, thus signaling that they need to be indexed on.
+
+Within this tab, you’ll find an overview of:
+
+- All the subgraphs you're curating on with signal details
+- Share totals per subgraph
+- Query rewards per subgraph
+- Updated at date details
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Your Profile Settings
+
+Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
+
+- Operators take limited actions in the protocol on the Indexer's behalf, such as opening and closing allocations. Operators are typically other Ethereum addresses, separate from their staking wallet, with gated access to the network that Indexers can personally set
+- Delegation parameters allow you to control the distribution of GRT between you and your Delegators.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From f0ee5fffd946ce4ed51a25434ab38c6cf47217f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:39 -0500
Subject: [PATCH 2013/3820] New translations explorer.mdx (French)

---
 website/pages/fr/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/explorer.mdx

diff --git a/website/pages/fr/subgraphs/explorer.mdx b/website/pages/fr/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..3f8ddc58ea66
--- /dev/null
+++ b/website/pages/fr/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Découvrez Graph Explorer et accédez au monde des subgraphs et des données réseau.
+
+Graph Explorer se compose de plusieurs parties où vous pouvez interagir avec d'autres développeurs de subgraphs, développeurs de dapps, Curateurs, Indexeurs et Délégateurs.
+
+## Guide Vidéo
+
+Pour une vue d'ensemble de Graph Explorer, consultez la vidéo ci-dessous :
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraphs
+
+Après avoir terminé le déploiement et la publication de votre subgraph dans Subgraph Studio, cliquez sur l'onglet "subgraphs" en haut de la barre de navigation pour accéder aux éléments suivants :
+
+- Vos propres subgraphs terminés
+- Les subgraphs publiés par d'autres
+- Le subgraph exact que vous voulez (basé sur la date de création, le montant du signal ou le nom).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+Lorsque vous cliquez sur un subgraph, vous pourrez faire ce qui suit :
+
+- Tester des requêtes dans le l'environnement de test et utiliser les détails du réseau pour prendre des décisions éclairées.
+- Signaler des GRT sur votre propre subgraph ou sur les subgraphs des autres pour informer les Indexeurs de son importance et de sa qualité.
+- Ceci est crucial car le signalement sur un subgraph l'incite à être indexé, ce qui signifie qu'il finira par apparaître sur le réseau pour servir des requêtes.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+Sur la page dédiée de chaque subgraph, vous pouvez faire ce qui suit :
+
+- Signal/Un-signal sur les subgraphs
+- Afficher plus de détails tels que des graphs, l'ID de déploiement actuel et d'autres métadonnées
+- Passer d'une version à l'autre pour explorer les itérations passées du subgraph
+- Interroger les subgraphs via GraphQL
+- Tester les subgraphs dans le playground
+- Afficher les indexeurs qui indexent sur un certain subgraph
+- Statistiques du subgraph (allocations, conservateurs, etc.)
+- Afficher l'entité qui a publié le subgraph
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Participants
+
+Cette section offre une vue d'ensemble de tous les "participants", ce qui inclut tous ceux qui participent au réseau, tels que les Indexeurs, les Délégateurs et les Curateurs.
+
+### 1. Indexeurs
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Les Indexeurs sont la colonne vertébrale du protocole. Ils stakent sur les subgraphs, les indexent et servent les requêtes à quiconque consomme les subgraphs.
+
+Dans le tableau des Indexeurs, vous pouvez voir les paramètres de délégation des Indexeurs, leur staking, combien ils ont staké sur chaque subgraph et combien de revenus ils ont généré à partir des frais de requête et des récompenses d'indexation.
+
+**Specifics**
+
+- Query Fee Cut - le % des frais de requête que l'Indexeur conserve lors de la répartition avec les Délégateurs.
+- Effective Reward Cut - la réduction des récompenses d'indexation appliquée au pool de délégation. Si elle est négative, cela signifie que l'Indexeur donne une partie de ses récompenses. Si elle est positive, cela signifie que l'Indexeur garde une partie de ses récompenses.
+- Cooldown Remaining - le temps restant avant que l'Indexeur puisse modifier les paramètres de délégation ci-dessus. Les périodes de cooldown sont définies par les Indexeurs lorsqu'ils mettent à jour leurs paramètres de délégation.
+- Owned - Il s'agit du staking de l'Indexeur, qui peut être partiellement confisquée en cas de comportement malveillant ou incorrect.
+- Delegated - Le staking des Délégateurs qui peut être allouée par l'Indexeur, mais ne peut pas être confisquée.
+- Allocated - Le staking les Indexeurs allouent activement aux subgraphs qu'ils indexent.
+- Available Delegation Capacity - le staking délégué que les Indexeurs peuvent encore recevoir avant d'être sur-délégués.
+- Capacité de délégation maximale : montant maximum de participation déléguée que l'indexeur peut accepter de manière productive. Une mise déléguée excédentaire ne peut pas être utilisée pour le calcul des allocations ou des récompenses.
+- Query Fees - il s'agit du total des frais que les utilisateurs finaux ont payés pour les requêtes d'un Indexeur au fil du temps.
+- Récompenses de l'indexeur - il s'agit du total des récompenses de l'indexeur gagnées par l'indexeur et ses délégués sur toute la durée. Les récompenses des indexeurs sont payées par l'émission de GRT.
+
+Les Indexeurs peuvent gagner à la fois des frais de requête et des récompenses d'indexation. Fonctionnellement, cela se produit lorsque les participants au réseau délèguent des GRT à un Indexeur. Cela permet aux Indexeurs de recevoir des frais de requête et des récompenses en fonction de leurs paramètres d'Indexeur.
+
+- Les paramètres d'indexation peuvent être définis en cliquant sur le côté droit du tableau ou en accédant au profil d'un Indexeur et en cliquant sur le bouton "Delegate ".
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curateurs
+
+Les Curateurs analysent les subgraphs pour identifier ceux de la plus haute qualité. Une fois qu'un Curateur a trouvé un subgraph potentiellement de haute qualité, il peut le curer en le signalant sur sa courbe de liaison. Ce faisant, les Curateurs informent les Indexeurs des subgraphs de haute qualité qui doivent être indexés.
+
+- Les Curateurs peuvent être des membres de la communauté, des consommateurs de données ou même des développeurs de subgraphs qui signalent leurs propres subgraphs en déposant des jetons GRT dans une courbe de liaison.
+  - En déposant des GRT, les Curateurs mintent des actions de curation d'un subgraph. En conséquence, ils peuvent gagner une partie des frais de requête générés par le subgraph sur lequel ils ont signalé.
+  - La courbe de liaison incite les Curateurs à curer les sources de données de la plus haute qualité.
+
+Dans le tableau des Curateurs ci-dessous, vous pouvez voir :
+
+- La date à laquelle le curateur a commencé à organiser
+- Le nombre de GRT déposés
+- Nombre d'actions détenues par un curateur
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Délégués
+
+Les Délégateurs jouent un rôle clé dans le maintien de la sécurité et de la décentralisation de The Graph Network. Ils participent au réseau en déléguant (c'est-à-dire en "stakant") des jetons GRT à un ou plusieurs Indexeurs.
+
+- Sans Délégateurs, les Indexeurs sont moins susceptibles de gagner des récompenses et des frais importants. Par conséquent, les Indexeurs attirent les Délégateurs en leur offrant une partie de leurs récompenses d'indexation et de leurs frais de requête.
+- Les Délégateurs sélectionnent leurs Indexeurs selon divers critères, telles que les performances passées, les taux de récompense d'indexation et le partage des frais.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+Dans le tableau des Délégateurs, vous pouvez voir les Délégateurs actifs dans la communauté et les métriques importantes :
+
+- Le nombre d’indexeurs auxquels un délégant délègue
+- Délégation originale d’un délégant
+- Les récompenses qu'ils ont accumulées mais qu'ils n'ont pas retirées du protocole
+- Les récompenses obtenues qu'ils ont retirées du protocole
+- Quantité totale de GRT qu'ils ont actuellement dans le protocole
+- La date de leur dernière délégation
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Réseau
+
+Dans cette section, vous pouvez consulter les indicateurs clés de performance (KPI) globaux du réseau et passer en mode par époque (epoch) pour analyser plus en détail les métriques du réseau. Ces informations vous donneront une vision de l’évolution des performances du réseau du réseau au fil du temps.
+
+### Aperçu
+
+La section d'aperçu présente à la fois toutes les métriques actuelles du réseau et certaines métriques cumulatives au fil du temps :
+
+- L’enjeu total actuel du réseau
+- La répartition des enjeux entre les indexeurs et leurs délégués
+- Approvisionnement total, GRT frappés et brûlés depuis la création du réseau
+- Récompenses totales de l'indexation depuis la création du protocole
+- Paramètres du protocole tels que la récompense de la curation, le taux d'inflation, etc
+- Récompenses et frais de l'époque actuelle
+
+Quelques détails clés à noter :
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Époques
+
+Dans la section Époques, vous pouvez analyser, époque par époque, des métriques telles que :
+
+- Bloc de début ou de fin d'époque
+- Frais de requête générés et récompenses d'indexation collectées au cours d'une époque spécifique
+- Le statut de l'époque, qui fait référence à la collecte et à la distribution de la redevance d'interrogation, peut présenter différents états :
+  - L'époque active est celle où les indexeurs sont en train d'allouer des enjeux et de collecter des frais de requête
+  - Les époques de règlement sont celles au cours desquelles les canaux d'État sont réglées. Cela signifie que les indexeurs sont soumis à des réductions si les consommateurs ouvrent des litiges à leur encontre.
+  - Les époques de distribution sont les époques au cours desquelles les canaux d'État pour les époques sont réglés et les indexeurs peuvent réclamer leurs remises sur les frais de requête.
+  - Les époques finalisées sont les époques qui n'ont plus de remboursements de frais de requête à réclamer par les Indexeurs.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Votre profil d'utilisateur
+
+Votre profil personnel est l'endroit où vous pouvez voir votre activité sur le réseau, quel que soit votre rôle sur le réseau. Votre portefeuille crypto agira comme votre profil utilisateur, et avec le tableau de bord utilisateur, vous pourrez voir les onglets suivants :
+
+### Aperçu du profil
+
+Dans cette section, vous pouvez voir ce qui suit :
+
+- Toutes les actions en cours que vous avez effectuées.
+- Les informations de votre profil, description et site web (si vous en avez ajouté un).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Onglet Subgraphs
+
+Dans l'onglet Subgraphs, vous verrez vos subgraphs publiés.
+
+> Ceci n'inclura pas les subgraphs déployés avec la CLI à des fins de test. Les subgraphs n'apparaîtront que lorsqu'ils sont publiés sur le réseau décentralisé.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Onglet Indexation
+
+Dans l'onglet Indexation, vous trouverez un tableau avec toutes les allocations actives et historiques via-à-vis des subgraphs. Vous trouverez également des graphiques où vous pourrez voir et analyser vos performances passées en tant qu'Indexeur.
+
+Cette section comprendra également des détails sur vos récompenses nettes d'indexeur et vos frais de requête nets. Vous verrez les métriques suivantes :
+
+- Participation déléguée - la participation des délégués qui peut être allouée par vous mais ne peut pas être réduite
+- Total des frais de requête - le total des frais payés par les utilisateurs pour les requêtes que vous leur avez adressées au fil du temps
+- Récompenses de l'indexeur - le montant total des récompenses de l'indexeur que vous avez reçues, en GRT
+- Réduction des frais : % de remise sur les frais de requête que vous conserverez lors de votre séparation avec les délégués
+- Récompenses de l'indexeur - le montant total des récompenses de l'indexeur que vous avez reçues, en GRT
+- Possédé : votre mise déposée, qui pourrait être réduite en cas de comportement malveillant ou incorrect
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Onglet Délégation
+
+Les Délégateurs sont importants pour The Graph Network. Ils doivent utiliser leurs connaissances pour choisir un Indexeur qui fournira un bon rendement sur les récompenses.
+
+Dans l'onglet Délégateurs, vous pouvez trouver les détails de vos délégations actives et historiques, ainsi que les métriques des Indexeurs vers lesquels vous avez délégué.
+
+Dans la première moitié de la page, vous pouvez voir votre diagramme de délégation, ainsi que le diagramme des récompenses uniquement. À gauche, vous pouvez voir les indicateurs clés de performance qui reflètent vos paramètres de délégation actuels.
+
+Les métriques du délégué que vous verrez ici dans cet onglet incluent :
+
+- Récompenses totales de la délégation
+- Récompenses totales non réalisées
+- Récompenses totales réalisées
+
+Dans la seconde moitié de la page, vous avez le tableau des délégations. Ici, vous pouvez voir les indexeurs auxquels vous avez délégué, ainsi que leurs détails (tels que les réductions de récompenses, le temps de recharge, etc.).
+
+Les boutons situés à droite du tableau vous permettent de gérer votre délégation - déléguer davantage, dé-déléguer ou retirer votre délégation après la période de dégel.
+
+Gardez à l'esprit que ce graph peut être parcouru horizontalement, donc si vous le faites défiler jusqu'à la droite, vous pouvez également voir le statut de votre délégation (en cours de délégation, non-déléguée, en cours de retrait).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Onglet Conservation
+
+Dans l'onglet Curation, vous trouverez tous les subgraphs vous signalez (vous permettant ainsi de recevoir des frais de requête). La signalisation permet aux conservateurs de mettre en évidence aux indexeurs quels subgraphs sont précieux et dignes de confiance, signalant ainsi qu'ils doivent être indexés.
+
+Dans cet onglet, vous trouverez un aperçu de :
+
+- Tous les subgraphs sur lesquels vous êtes en train de curer avec les détails du signal
+- Partager les totaux par subgraph
+- Récompenses de requête par subraph
+- Détails mis à jour
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Paramètres de votre profil
+
+Dans votre profil utilisateur, vous pourrez gérer les détails de votre profil personnel (comme la configuration d'un nom ENS). Si vous êtes un indexeur, vous avez encore plus accès aux paramètres à portée de main. Dans votre profil utilisateur, vous pourrez configurer vos paramètres et opérateurs de délégation.
+
+- Les opérateurs effectuent des actions limitées dans le protocole au nom de l'indexeur, telles que l'ouverture et la clôture des allocations. Les opérateurs sont généralement d'autres adresses Ethereum, distinctes de leur portefeuille de jalonnement, avec un accès sécurisé au réseau que les indexeurs peuvent définir personnellement
+- Les paramètres de délégation vous permettent de contrôler la répartition des GRT entre vous et vos délégués.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+En tant que portail officiel dans le monde des données décentralisées, Graph Explorer vous permet de prendre diverses actions, quel que soit votre rôle dans le réseau. Vous pouvez accéder aux paramètres de votre profil en ouvrant le menu déroulant à côté de votre adresse, puis en cliquant sur le bouton Paramètres.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 5f181aae56a086496794e76fe0f0ef0f4907c6cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:40 -0500
Subject: [PATCH 2014/3820] New translations explorer.mdx (Spanish)

---
 website/pages/es/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/es/subgraphs/explorer.mdx

diff --git a/website/pages/es/subgraphs/explorer.mdx b/website/pages/es/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..4c929faa896b
--- /dev/null
+++ b/website/pages/es/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgrafos
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Señalar/dejar de señalar un subgrafo
+- Ver más detalles como gráficos, ID de implementación actual y otros metadatos
+- Cambiar de versión para explorar iteraciones pasadas del subgrafo
+- Consultar subgrafos a través de GraphQL
+- Probar subgrafos en el playground
+- Ver los Indexadores que están indexando en un subgrafo determinado
+- Estadísticas de subgrafo (asignaciones, Curadores, etc.)
+- Ver la entidad que publicó el subgrafo
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Participantes
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexadores
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity: la cantidad máxima de participación delegada que el Indexador puede aceptar de forma productiva. Un exceso de participación delegada no puede utilizarse para asignaciones o cálculos de recompensas.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Indexer Rewards: este es el total de recompensas del Indexador obtenidas por el Indexador y sus Delegadores durante todo el tiempo que trabajaron en conjunto. Las recompensas de los Indexadores se pagan mediante la emisión de GRT.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curadores
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- La fecha en que el Curador comenzó a curar
+- El número de GRT que se depositaron
+- El número de participaciones que posee un Curador
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegadores
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- El número de Indexadores a los que delega este Delegador
+- La delegación principal de un Delegador
+- Las recompensas que han ido acumulando, pero que aún no han retirado del protocolo
+- Las recompensas realizadas, es decir, las que ya retiraron del protocolo
+- Cantidad total de GRT que tienen actualmente dentro del protocolo
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Red
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Descripción
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- La cantidad total de stake que circula en estos momentos
+- La participación que se divide entre los Indexadores y sus Delegadores
+- Suministro total, GRT anclados y quemados desde el comienzo de la red
+- Recompensas totales de Indexación desde el comienzo del protocolo
+- Parámetros del protocolo como las recompensas de curación, tasa de inflación y más
+- Recompensas y tarifas del ciclo actual
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Ciclos (epochs)
+
+En la sección de Epochs, puedes analizar, por cada epoch, métricas como:
+
+- Inicio de ciclo o bloque final
+- Tarifas de consulta generadas y recompensas de indexación recolectadas durante un ciclo específico
+- Estado del ciclo, el cual se refiere al cobro y distribución de la tarifa de consulta y puede tener diferentes estados:
+  - El ciclo activo es aquel en la que los indexadores actualmente asignan su participación (staking) y cobran tarifas por consultas
+  - Los ciclos liquidados son aquellos en los que ya se han liquidado las recompensas y demás métricas. Esto significa que los Indexadores están sujetos a recortes si los consumidores abren disputas en su contra.
+  - Los ciclos de distribución son los ciclos en los que los canales correspondientes a los ciclos son establecidos y los Indexadores pueden reclamar sus reembolsos correspondientes a las tarifas de consulta.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Tu perfil de usuario
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Información general del perfil
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Pestaña de subgrafos
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Pestaña de indexación
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+Esta sección también incluirá detalles sobre las recompensas netas que obtienes como Indexador y las tarifas netas que recibes por cada consulta. Verás las siguientes métricas:
+
+- Delegated Stake: la participación de los Delegados que puedes asignar pero que no se puede recortar
+- Total Query Fees: las tarifas totales que los usuarios han pagado por las consultas que has atendido durante tu participación
+- Indexer Rewards: la cantidad total de recompensas que el Indexador ha recibido, se valora en GRT
+- Fee Cut: es el porcentaje que obtendrás por las consultas que has atendido, estos se distribuyen al cerrar un ciclo o cuando te separes de tus delegadores
+- Rewards Cut: este es el porcentaje de recompensas que dividirás con tus delegadores una vez se cierre el ciclo
+- Owned: tu stake depositado, que podría reducirse por un comportamiento malicioso o incorrecto en la red
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Pestaña de delegación
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+En la primera mitad de la página, puedes ver tu gráfico de delegación, así como el gráfico de recompensas históricas. A la izquierda, puedes ver los KPI que reflejan tus métricas de delegación actuales.
+
+Las métricas de Delegador que verás aquí en esta pestaña incluyen:
+
+- Recompensas totales de delegación (Total delegation rewards)
+- Recompensas totales no realizadas (Total unrealized rewards)
+- Recompensas totales realizadas (Total realized rewards)
+
+En la segunda mitad de la página, tienes la tabla de delegaciones. Aquí puedes ver los Indexadores a los que delegaste, así como sus detalles (como recortes de recompensas, tiempo de enfriamiento, etc.).
+
+Con los botones en el lado derecho de la tabla, puedes administrar tu delegación: delegar más, quitar tu delegación o retirar tu delegación después del período de descongelación.
+
+Con los botones situados al lado derecho de la tabla, puedes administrar tu delegación: delegar más, anular la delegación actual o retirar tu delegación después del período de descongelación.
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Pestaña de curación
+
+En la pestaña Curación, encontrarás todos los subgrafos a los que estás señalando (lo que te permite recibir tarifas de consulta). La señalización permite a los Curadores destacar un subgrafo importante y fiable a los Indexadores, dándoles a entender que debe ser indexado.
+
+Dentro de esta pestaña, encontrarás una descripción general de:
+
+- Todos los subgrafos que estás curando con detalles de la señalización actual
+- Participaciones totales en cada subgrafo
+- Recompensas de consulta por cada subgrafo
+- Actualizaciones de los subgrafos
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Configuración de tu perfil
+
+Dentro de tu perfil de usuario, podrás administrar los detalles de tu perfil personal (como configurar un nombre de ENS). Si eres un Indexador, tienes aún más acceso a la configuración al alcance de tu mano. En tu perfil de usuario, podrás configurar los parámetros y operadores de tu delegación.
+
+- Los operadores toman acciones limitadas en el protocolo en nombre del Indexador, como abrir y cerrar asignaciones. Los operadores suelen ser otras direcciones de Ethereum, separadas de su billetera de staking, con acceso cerrado a la red que los Indexadores pueden configurar personalmente
+- Los parámetros de delegación te permiten controlar la distribución de GRT entre tu y tus Delegadores.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 560fff331b870b035b117733dde25776d21ce363 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:41 -0500
Subject: [PATCH 2015/3820] New translations explorer.mdx (Arabic)

---
 website/pages/ar/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/explorer.mdx

diff --git a/website/pages/ar/subgraphs/explorer.mdx b/website/pages/ar/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..1ebc61b13dfe
--- /dev/null
+++ b/website/pages/ar/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraphs
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- أشر/الغي الإشارة على Subgraphs
+- اعرض المزيد من التفاصيل مثل المخططات و ال ID الحالي وبيانات التعريف الأخرى
+- بدّل بين الإصدارات وذلك لاستكشاف التكرارات السابقة ل subgraphs
+- استعلم عن subgraphs عن طريق GraphQL
+- اختبار subgraphs في playground
+- اعرض المفهرسين الذين يفهرسون Subgraphs معين
+- إحصائيات subgraphs (المخصصات ، المنسقين ، إلخ)
+- اعرض من قام بنشر ال Subgraphs
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## المشاركون
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexers
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity - the maximum amount of delegated stake the Indexer can productively accept. An excess delegated stake cannot be used for allocations or rewards calculations.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- مكافآت المفهرس Indexer Rewards - هو مجموع مكافآت المفهرس التي حصل عليها المفهرس ومفوضيهم Delegators. تدفع مكافآت المفهرس ب GRT.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 3. المفوضون Delegators
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- التاريخ الذي بدأ فيه المنسق بالتنسق
+- عدد ال GRT الذي تم إيداعه
+- عدد الأسهم التي يمتلكها المنسق
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. المفوضون Delegators
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- عدد المفهرسين المفوض إليهم
+- التفويض الأصلي للمفوض Delegator’s original delegation
+- المكافآت التي جمعوها والتي لم يسحبوها من البروتوكول
+- المكافآت التي تم سحبها من البروتوكول
+- كمية ال GRT التي يمتلكونها حاليا في البروتوكول
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Network
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### نظره عامة
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- إجمالي حصة الشبكة الحالية
+- الحصة المقسمة بين المفهرسين ومفوضيهم
+- إجمالي العرض ،و الصك ،وال GRT المحروقة منذ بداية الشبكة
+- إجمالي مكافآت الفهرسة منذ بداية البروتوكول
+- بارامترات البروتوكول مثل مكافأة التنسيق ومعدل التضخم والمزيد
+- رسوم ومكافآت الفترة الحالية
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### الفترات Epochs
+
+In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
+
+- بداية الفترة أو نهايتها
+- مكافآت رسوم الاستعلام والفهرسة التي تم جمعها خلال فترة معينة
+- حالة الفترة، والتي تشير إلى رسوم الاستعلام وتوزيعها ويمكن أن يكون لها حالات مختلفة:
+  - الفترة النشطة هي الفترة التي يقوم فيها المفهرسون حاليا بتخصيص الحصص وتحصيل رسوم الاستعلام
+  - فترات التسوية هي تلك الفترات التي يتم فيها تسوية قنوات الحالة state channels. هذا يعني أن المفهرسين يكونون عرضة للشطب إذا فتح المستخدمون اعتراضات ضدهم.
+  - فترات التوزيع هي تلك الفترات التي يتم فيها تسوية قنوات الحالة للفترات ويمكن للمفهرسين المطالبة بخصم رسوم الاستعلام الخاصة بهم.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## ملف تعريف المستخدم الخاص بك
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### نظرة عامة على الملف الشخصي
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### تبويب ال Subgraphs
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### تبويب الفهرسة
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+هذا القسم سيتضمن أيضا تفاصيل حول صافي مكافآت المفهرس ورسوم الاستعلام الصافي الخاصة بك. سترى المقاييس التالية:
+
+- الحصة المفوضة Delegated Stake - هي الحصة المفوضة من قبل المفوضين والتي يمكنك تخصيصها ولكن لا يمكن شطبها
+- إجمالي رسوم الاستعلام Total Query Fees - هو إجمالي الرسوم التي دفعها المستخدمون مقابل الاستعلامات التي قدمتها بمرور الوقت
+- مكافآت المفهرس Indexer Rewards - هو المبلغ الإجمالي لمكافآت المفهرس التي تلقيتها ك GRT
+- اقتطاع الرسوم Fee Cut -هي النسبة المئوية لخصوم رسوم الاستعلام التي ستحتفظ بها عند التقسيم مع المفوضين
+- اقتطاع المكافآت Rewards Cut -هي النسبة المئوية لمكافآت المفهرس التي ستحتفظ بها عند التقسيم مع المفوضين
+- مملوكة Owned - هي حصتك المودعة ، والتي يمكن شطبها بسبب السلوك الضار أو غير الصحيح
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### تبويب التفويض Delegating Tab
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+في النصف الأول من الصفحة ، يمكنك رؤية مخطط التفويض الخاص بك ، بالإضافة إلى مخطط المكافآت فقط. إلى اليسار ، يمكنك رؤية KPIs التي تعكس مقاييس التفويض الحالية.
+
+مقاييس التفويض التي ستراها هنا في علامة التبويب هذه تشمل ما يلي:
+
+- إجمالي مكافآت التفويض
+- إجمالي المكافآت الغير محققة
+- إجمالي المكافآت المحققة
+
+في النصف الثاني من الصفحة ، لديك جدول التفويضات. هنا يمكنك رؤية المفهرسين الذين فوضتهم ، بالإضافة إلى تفاصيلهم (مثل المكافآت المقتطعة rewards cuts، و cooldown ، الخ).
+
+باستخدام الأزرار الموجودة على الجانب الأيمن من الجدول ، يمكنك إدارة التفويض - تفويض المزيد أو إلغاء التفويض أو سحب التفويض بعد فترة الإذابة.
+
+باستخدام الأزرار الموجودة على الجانب الأيمن من الجدول ، يمكنك إدارة تفويضاتك أو تفويض المزيد أو إلغاء التفويض أو سحب التفويض بعد فترة الذوبان thawing.
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### تبويب التنسيق Curating
+
+في علامة التبويب Curation ، ستجد جميع ال subgraphs التي تشير إليها (مما يتيح لك تلقي رسوم الاستعلام). الإشارة تسمح للمنسقين التوضيح للمفهرسين ماهي ال subgraphs ذات الجودة العالية والموثوقة ، مما يشير إلى ضرورة فهرستها.
+
+ضمن علامة التبويب هذه ، ستجد نظرة عامة حول:
+
+- جميع ال subgraphs التي تقوم بتنسيقها مع تفاصيل الإشارة
+- إجمالي الحصة لكل subgraph
+- مكافآت الاستعلام لكل subgraph
+- تحديث في تفاصيل التاريخ
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## إعدادات ملف التعريف الخاص بك
+
+ضمن ملف تعريف المستخدم الخاص بك ، ستتمكن من إدارة تفاصيل ملفك الشخصي (مثل إعداد اسم ENS). إذا كنت مفهرسا ، فستستطيع الوصول إلى إعدادت أكثر. في ملف تعريف المستخدم الخاص بك ، ستتمكن من إعداد بارامترات التفويض والمشغلين.
+
+- Operators تتخذ إجراءات محدودة في البروتوكول نيابة عن المفهرس ، مثل عمليات فتح وإغلاق المخصصات. Operators هي عناوين Ethereum أخرى ، منفصلة عن محفظة staking الخاصة بهم ، مع بوابة وصول للشبكة التي يمكن للمفهرسين تعيينها بشكل شخصي
+- تسمح لك بارامترات التفويض بالتحكم في توزيع GRT بينك وبين المفوضين.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 81f742a28b78f8215bacadd75b4328d74e5a3c4b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:43 -0500
Subject: [PATCH 2016/3820] New translations explorer.mdx (Czech)

---
 website/pages/cs/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/explorer.mdx

diff --git a/website/pages/cs/subgraphs/explorer.mdx b/website/pages/cs/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..4f6d3cc9f97c
--- /dev/null
+++ b/website/pages/cs/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Průzkumník grafů
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Podgrafy
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Signál/nesignál na podgraf
+- Zobrazit další podrobnosti, například grafy, ID aktuálního nasazení a další metadata
+- Přepínání verzí pro zkoumání minulých iterací podgrafu
+- Dotazování na podgrafy prostřednictvím GraphQL
+- Testování podgrafů na hřišti
+- Zobrazení indexátorů, které indexují na určitém podgrafu
+- Statistiky podgrafů (alokace, kurátoři atd.)
+- Zobrazení subjektu, který podgraf zveřejnil
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Účastníci
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexery
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Maximální kapacita delegování - maximální množství delegovaných podílů, které může indexátor produktivně přijmout. Nadměrný delegovaný podíl nelze použít pro alokace nebo výpočty odměn.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Odměny indexátorů - jedná se o celkové odměny indexátorů, které indexátor a jeho delegáti získali za celou dobu. Odměny indexátorů jsou vypláceny prostřednictvím vydání GRT.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Kurátoři
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- Datum, kdy kurátor zahájil kurátorskou činnost
+- Počet uložených GRT
+- Počet akcií, které kurátor vlastní
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegáti
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- Počet indexátorů, na které deleguje delegát
+- Původní delegace delegát
+- Odměny, které nashromáždili, ale z protokolu si je nevyzvedli
+- Realizované odměny odstranili z protokolu
+- Celkové množství GRT, které mají v současné době v protokolu
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Síť
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Přehled
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- Současný celkový podíl v síti
+- Rozdělení stake mezi indexátory a jejich delegátory
+- Celková nabídka, vytěžené a spálené GRT od založení sítě
+- Celkové odměny za indexaci od zavedení protokolu
+- Parametry protokolu, jako je odměna za kurátorství, míra inflace a další
+- Odměny a poplatky současné epochy
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epochs
+
+V části Epochy můžete na základě jednotlivých epoch analyzovat metriky, jako jsou:
+
+- Počáteční nebo koncový blok epoch
+- Poplatky za dotazy vygenerované a odměny za indexování vybrané během určité epoch
+- Stav epoch, který se týká výběru a distribuce poplatků za dotaz a může mít různé stavy:
+  - Aktivní epocha je ta, ve které indexéry právě přidělují podíl a vybírají poplatky za dotazy
+  - Epoch zúčtování jsou ty, ve kterých se zúčtovávají stavové kanály. To znamená, že indexátoři podléhají krácení, pokud proti nim spotřebitelé zahájí spory.
+  - Distribuční epochy jsou epochy, ve kterých se vypořádávají státní kanály pro epochy a indexátoři si mohou nárokovat slevy z poplatků za dotazy.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Váš uživatelský profil
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Přehled profilů
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Tab Podgrafy
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Tab Indexování
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+Tato část bude také obsahovat podrobnosti o vašich čistých odměnách za indexování a čistých poplatcích za dotazy. Zobrazí se následující metriky:
+
+- Delegovaná sázka – sázka od delegátů, kterou můžete přidělit vy, ale nelze ji snížit
+- Celkové poplatky za dotazy - celkové poplatky, které uživatelé zaplatili za dotazy, které jste obsloužili v průběhu času
+- Odměny indexátora - celková částka odměn indexátora, kterou jste obdrželi, v GRT
+- Fee Cut - % slevy z poplatku za dotaz, které si ponecháte při rozdělení s delegáty
+- Rozdělení odměn - % odměn indexátorů, které si ponecháte při dělení s delegáty
+- Ve vlastnictví - váš vložený vklad, který může být snížen za škodlivé nebo nesprávné chování
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Tab Delegování
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+V první polovině stránky vidíte graf delegování a také graf odměn. Vlevo vidíte klíčové ukazatele výkonnosti, které odrážejí vaše aktuální metriky delegování.
+
+Metriky delegáta, které uvidíte na této tab, zahrnují:
+
+- Celkové odměny za delegování
+- Nerealizované odměny celkem
+- Celkové realizované odměny
+
+V druhé polovině stránky je tabulka delegací. Zde vidíte indexátory, které jste delegovali, a také jejich podrobnosti (například snížení odměn, zkrácení doby platnosti atd.).
+
+Pomocí tlačítek na pravé straně tabulky můžete spravovat delegování - delegovat více, zrušit delegování nebo stáhnout delegování po uplynutí doby rozmrazení.
+
+Nezapomeňte, že tento graf lze horizontálně posouvat, takže pokud se posunete úplně doprava, uvidíte také stav svého delegování (delegování, nedelegování, odvolání).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Tab Kurátorství
+
+Na kartě Kurátorství najdete všechny dílčí grafy, na které signalizujete (a které vám tak umožňují přijímat poplatky za dotazy). Signalizace umožňuje kurátorům upozornit indexátory na to, které podgrafy jsou hodnotné a důvěryhodné, a tím signalizovat, že je třeba je indexovat.
+
+Na této tab najdete přehled:
+
+- Všechny dílčí podgrafy, na kterých kurátor pracuje, s podrobnostmi o signálu
+- Celkové podíly na podgraf
+- Odměny za dotaz na podgraf
+- Aktualizováno v detailu data
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Nastavení profilu
+
+Ve svém uživatelském profilu budete moci spravovat své osobní údaje (například nastavit jméno ENS). Jste-li indexátorem, máte k dispozici ještě více nastavení. Ve svém uživatelském profilu budete moci nastavit parametry delegování a operátory.
+
+- Operátoři provádějí v protokolu jménem indexátoru omezené akce, například otevírají a zavírají alokace. Operátoři jsou obvykle jiné adresy Ethereum, oddělené od jejich stakingové peněženky, s uzavřeným přístupem do sítě, který si indexátoři mohou osobně nastavit
+- Parametry delegování umožňují řídit rozdělení GRT mezi vás a vaše delegáty.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From aded55f6fdd62b26a459048d480099dc9e22cb7c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:44 -0500
Subject: [PATCH 2017/3820] New translations explorer.mdx (German)

---
 website/pages/de/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/de/subgraphs/explorer.mdx

diff --git a/website/pages/de/subgraphs/explorer.mdx b/website/pages/de/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..433821560d85
--- /dev/null
+++ b/website/pages/de/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraphs
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Signal/Un-signal on subgraphs
+- View more details such as charts, current deployment ID, and other metadata
+- Switch versions to explore past iterations of the subgraph
+- Query subgraphs via GraphQL
+- Test subgraphs in the playground
+- View the Indexers that are indexing on a certain subgraph
+- Subgraph stats (allocations, Curators, etc)
+- View the entity who published the subgraph
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Participants
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexers
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity - the maximum amount of delegated stake the Indexer can productively accept. An excess delegated stake cannot be used for allocations or rewards calculations.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Indexer Rewards - this is the total indexer rewards earned by the Indexer and their Delegators over all time. Indexer rewards are paid through GRT issuance.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curators
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- The date the Curator started curating
+- The number of GRT that was deposited
+- The number of shares a Curator owns
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegators
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- The number of Indexers a Delegator is delegating towards
+- A Delegator’s original delegation
+- The rewards they have accumulated but have not withdrawn from the protocol
+- The realized rewards they withdrew from the protocol
+- Total amount of GRT they have currently in the protocol
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Network
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Overview
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- The current total network stake
+- The stake split between the Indexers and their Delegators
+- Total supply, minted, and burned GRT since the network inception
+- Total Indexing rewards since the inception of the protocol
+- Protocol parameters such as curation reward, inflation rate, and more
+- Current epoch rewards and fees
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epochs
+
+In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
+
+- Epoch start or end block
+- Query fees generated and indexing rewards collected during a specific epoch
+- Epoch status, which refers to the query fee collection and distribution and can have different states:
+  - The active epoch is the one in which Indexers are currently allocating stake and collecting query fees
+  - The settling epochs are the ones in which the state channels are being settled. This means that the Indexers are subject to slashing if the consumers open disputes against them.
+  - The distributing epochs are the epochs in which the state channels for the epochs are being settled and Indexers can claim their query fee rebates.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Your User Profile
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Profile Overview
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Subgraphs Tab
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Indexing Tab
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+This section will also include details about your net Indexer rewards and net query fees. You’ll see the following metrics:
+
+- Delegated Stake - the stake from Delegators that can be allocated by you but cannot be slashed
+- Total Query Fees - the total fees that users have paid for queries served by you over time
+- Indexer Rewards - the total amount of Indexer rewards you have received, in GRT
+- Fee Cut - the % of query fee rebates that you will keep when you split with Delegators
+- Rewards Cut - the % of Indexer rewards that you will keep when splitting with Delegators
+- Owned - your deposited stake, which could be slashed for malicious or incorrect behavior
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Delegating Tab
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+In the first half of the page, you can see your delegation chart, as well as the rewards-only chart. To the left, you can see the KPIs that reflect your current delegation metrics.
+
+The Delegator metrics you’ll see here in this tab include:
+
+- Total delegation rewards
+- Total unrealized rewards
+- Total realized rewards
+
+In the second half of the page, you have the delegations table. Here you can see the Indexers that you delegated towards, as well as their details (such as rewards cuts, cooldown, etc).
+
+With the buttons on the right side of the table, you can manage your delegation - delegate more, undelegate, or withdraw your delegation after the thawing period.
+
+Keep in mind that this chart is horizontally scrollable, so if you scroll all the way to the right, you can also see the status of your delegation (delegating, undelegating, withdrawable).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Curating Tab
+
+In the Curation tab, you’ll find all the subgraphs you’re signaling on (thus enabling you to receive query fees). Signaling allows Curators to highlight to Indexers which subgraphs are valuable and trustworthy, thus signaling that they need to be indexed on.
+
+Within this tab, you’ll find an overview of:
+
+- All the subgraphs you're curating on with signal details
+- Share totals per subgraph
+- Query rewards per subgraph
+- Updated at date details
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Your Profile Settings
+
+Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
+
+- Operators take limited actions in the protocol on the Indexer's behalf, such as opening and closing allocations. Operators are typically other Ethereum addresses, separate from their staking wallet, with gated access to the network that Indexers can personally set
+- Delegation parameters allow you to control the distribution of GRT between you and your Delegators.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 582eed1682509467070340a5a64c364bd0078f0a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:45 -0500
Subject: [PATCH 2018/3820] New translations explorer.mdx (Italian)

---
 website/pages/it/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/it/subgraphs/explorer.mdx

diff --git a/website/pages/it/subgraphs/explorer.mdx b/website/pages/it/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..71e18f6737c0
--- /dev/null
+++ b/website/pages/it/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraph
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Segnala/non segnala i subgraph
+- Visualizza ulteriori dettagli, come grafici, ID di distribuzione corrente e altri metadati
+- Cambia versione per esplorare le iterazioni passate del subgraph
+- Consulta i subgraph tramite GraphQL
+- Test dei subgraph nel playground
+- Visualizza gli Indexer che stanno indicizzando su un determinato subgraph
+- Statistiche del subgraph (allocazione, Curator, ecc.)
+- Visualizza l'entità che ha pubblicato il subgraph
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Partecipanti
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexer
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity - l'importo massimo di stake delegato che l'Indexer può accettare in modo produttivo. Uno stake delegato in eccesso non può essere utilizzato per l'allocazione o per il calcolo dei premi.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Indexer Rewards - è il totale delle ricompense dell'Indexer guadagnate dall'Indexer e dai suoi Delegator in tutto il tempo. Le ricompense degli Indexer vengono pagate tramite l'emissione di GRT.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curator
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- La data in cui il Curator ha iniziato a curare
+- Il numero di GRT depositato
+- Il numero di azioni possedute da un Curator
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegator
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- Il numero di Indexer verso cui un Delegator sta delegando
+- La delega originale di un Delegator
+- Le ricompense che hanno accumulato ma non ritirato dal protocollo
+- Le ricompense realizzate ritirate dal protocollo
+- Quantità totale di GRT che hanno attualmente nel protocollo
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## La rete
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Panoramica
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- L'attuale stake totale della rete
+- La ripartizione dello stake tra gli Indexer e i loro Delegator
+- Fornitura totale, coniata e bruciata di GRT dall'inizio della rete
+- Ricompense totali dell'indicizzazione dall'inizio del protocollo
+- Parametri di protocollo come la ricompensa per la curation, il tasso di inflazione e altro ancora
+- Premi e commissioni dell'epoca attuale
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epoche
+
+Nella sezione Epoche è possibile analizzare su base epocale metriche come:
+
+- Blocco di inizio o fine epoca
+- Tariffe di query generate e ricompense di indicizzazione raccolte durante un'epoca specifica
+- Stato dell'epoca, che si riferisce alla raccolta e alla distribuzione delle tariffe di query e può avere diversi stati:
+  - L'epoca attiva è quella in cui gli Indexer stanno allocando le stake e riscuotendo le tariffe di query
+  - Le epoche di assestamento sono quelle in cui i canali di stato sono in fase di definizione. Ciò significa che gli Indexer sono soggetti a taglio se i consumatori aprono controversie contro di loro.
+  - Le epoche di distribuzione sono le epoche in cui i canali di stato per le epoche vengono regolati e gli Indexer possono richiedere gli sconti sulle tariffe di query.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Il profilo utente
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Panoramica del profilo
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Scheda di subgraph
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Scheda di indicizzazione
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+Questa sezione include anche i dettagli sui compensi netti degli Indexer e sulle tariffe nette di query. Verranno visualizzate le seguenti metriche:
+
+- Delegated Stake (stake delegato)- lo stake dei Delegator che può essere assegnata dall'utente, ma che non può essere tagliata
+- Total Query Fees (totale delle tariffe di query)- il totale delle tariffe che gli utenti hanno pagato per le query servite da voi nel tempo
+- Indexer Rewards (ricompense dell'Indexer) - l'importo totale delle ricompense dell'Indexer ricevuti, in GRT
+- Fee Cut (percentuale delle tariffe) - la percentuale dei rimborsi delle tariffe di query che si trattiene quando si divide con i Delegator
+- Rewards Cut (percentuale delle ricompense) - la percentuale delle ricompense dell'Indexer che verrà trattenuta quando si divide con i Delegator
+- Owned (di proprietà)- la quota depositata, che potrebbe essere tagliata in caso di comportamento dannoso o scorretto
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Scheda di delege
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+Nella prima metà della pagina è possibile vedere il grafico delle deleghe e quello dei sole ricompense. A sinistra, si possono vedere i KPI che riflettono le metriche delle delega attuali.
+
+Le metriche del Delegator visualizzate in questa scheda includono:
+
+- Ricompense di delega totali
+- Ricompense totali non realizzate
+- Ricomepsne totali realizzate
+
+Nella seconda metà della pagina si trova la tabella dei Delegator. Qui si possono vedere gli Indexer verso i quali si è delegata la delega, nonché i loro dettagli (come le percentuali delle ricompense, il cooldown, ecc.).
+
+Con i pulsanti sul lato destro della tabella è possibile gestire la delega - delegare di più, non delegare o ritirare la delega dopo il periodo di scongelamento.
+
+Tenete presente che questo grafico è scorrevole orizzontalmente, quindi se scorrete fino a destra, potete anche vedere lo stato della vostra delegazione (delegante, non delegante, revocabile).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Scheda di curation
+
+Nella scheda di Curation si trovano tutti i subgraph sui quali si sta effettuando una segnalazione (che consente di ricevere commissioni della query). La segnalazione consente ai curator di evidenziare agli Indexer quali subgraph sono di valore e affidabili, segnalando così la necessità di indicizzarli.
+
+All'interno di questa scheda è presente una panoramica di:
+
+- Tutti i subgraph su cui si effettua la curation con i dettagli del segnale
+- Totali delle quote per subgraph
+- Ricompense della query per subgraph
+- Aggiornamento attuale dei dettagli
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Impostazioni del profilo
+
+All'interno del vostro profilo utente, potrete gestire i dettagli del vostro profilo personale (come impostare un nome ENS). Se siete un Indexer, avrete ancora più accesso alle impostazioni a portata di mano. Nel vostro profilo utente, potrete impostare i parametri di delegazione e gli operatori.
+
+- Gli operatori compiono azioni limitate nel protocollo per conto dell'Indexer, come l'apertura e la chiusura delle allocation. Gli operatori sono in genere altri indirizzi Ethereum, separati dal loro wallet di staking, con un accesso limitato alla rete che gli Indexer possono impostare personalmente
+- I parametri di delega vi permettono di controllare la distribuzione di GRT tra voi e i vostri Delegator.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 78b9dcbcbb48415cce8239c549b416a2c730bdf1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:46 -0500
Subject: [PATCH 2019/3820] New translations explorer.mdx (Japanese)

---
 website/pages/ja/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/explorer.mdx

diff --git a/website/pages/ja/subgraphs/explorer.mdx b/website/pages/ja/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..ceb760528c04
--- /dev/null
+++ b/website/pages/ja/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: グラフエクスプローラ
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## サブグラフ
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- サブグラフのシグナル/アンシグナル
+- チャート、現在のデプロイメント ID、その他のメタデータなどの詳細情報の表示
+- バージョンを切り替えて、サブグラフの過去のイテレーションを調べる
+- GraphQL によるサブグラフのクエリ
+- プレイグラウンドでのサブグラフのテスト
+- 特定のサブグラフにインデクシングしているインデクサーの表示
+- サブグラフの統計情報（割り当て数、キュレーターなど）
+- サブグラフを公開したエンティティの表示
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## 参加者
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. インデクサー（Indexers）
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity - インデクサーが生産的に受け入れることができる委任されたステークの最大量。超過した委任されたステークは、割り当てや報酬の計算には使用できません。
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Indexer Rewards - インデクサーとそのデリゲーターが過去に獲得したインデクサー報酬の総額。 インデクサー報酬は GRT の発行によって支払われます
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. キュレーター
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- キュレーターがキュレーションを開始した日付
+- デポジットされた GRT の数
+- キュレーターが所有するシェア数
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. デリゲーター
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- デリゲーターがデリゲーションしているインデクサー数
+- デリゲーターの最初のデリゲーション内容
+- デリゲーターが蓄積したがプロトコルから引き出していない報酬
+- プロトコルから撤回済みの報酬
+- 現在プロトコルに保持している GRT 総量
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## ネットワーク
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### 概要
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- 現在のネットワーク全体のステーク額
+- インデクサーとデリゲーター間のステーク配分
+- ネットワーク開始以来の総供給量、ミント量、バーン GRT
+- プロトコルの開始以降のインデックス報酬総額
+- キュレーション報酬、インフレーション・レートなどのプロトコルパラメータ
+- 現在のエポックの報酬と料金
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### エポック
+
+エポックセクションでは、エポックごとに以下のようなメトリクスを分析できます：
+
+- エポックの開始または終了ブロック
+- 特定のエポックで発生したクエリーフィーと収集されたインデクシングリワード
+- エポックステータス： クエリフィーの徴収と分配に関するもので、さまざまな状態がある
+  - アクティブエポックとは、インデクサーが現在ステークを割り当て、クエリフィーを収集しているエポックのこと
+  - 決済エポックとは、状態のチャンネルを決済しているエポックのこと。 つまり、消費者がインデクサーに対して異議を唱えた場合、インデクサーはスラッシュされる可能性があるということ
+  - 分配エポックとは、そのエポックの状態チャンネルが確定し、インデクサーがクエリフィーのリベートを請求できるようになるエポックのこと
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## ユーザープロファイル
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### プロフィールの概要
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### サブグラフタブ
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### インデックスタブ
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+このセクションには、インデクサー報酬とクエリフィーの詳細も含まれます。 以下のような指標が表示されます：
+
+- Delegated Stake - あなたが割り当てることができるデリゲーターからのステークですが、スラッシュされることはできません
+- Total Query Fees - 提供したクエリに対してユーザーが支払った料金の合計額
+- Indexer Rewards - 受け取ったインデクサー報酬の総額（GRT）
+- Fee Cut - デリゲーターとの分配時に保持するクエリフィーリベートの割合
+- Rewards Cut - デリゲーターとの分配時に保有するインデクサー報酬の割合
+- Owned - 預けているステークであり、悪質な行為や不正行為があった場合にスラッシュされる可能性がある
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### デリゲーションタブ
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+ページの前半には、自分のデリゲーションチャートと報酬のみのチャートが表示されています。 左側には、現在のデリゲーションメトリクスを反映した KPI が表示されています。
+
+このタブに表示される委任者の指標には、次のものがあります。
+
+- デリゲーション報酬の合計
+- 未実現報酬の合計
+- 実現報酬の合計
+
+ページの後半には、デリゲーションテーブルがあります。 ここには、あなたがデリゲートしたインデクサーとその詳細（報酬のカットやクールダウンなど）が表示されています。
+
+テーブルの右側にあるボタンで、デリゲートを管理することができます。追加でデリゲートする、デリゲートを解除する、解凍期間後にデリゲートを取り消すなどの操作が可能です。
+
+このグラフは水平方向にスクロールできるので、右端までスクロールすると、委任のステータス (委任中、委任解除中、取り消し可能) も表示されることに注意してください。
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### キュレーションタブ
+
+[キュレーション] タブには、シグナルを送信しているすべてのサブグラフが表示されます (これにより、クエリ料金を受け取ることができます)。シグナリングにより、キュレーターはどのサブグラフが価値があり信頼できるかをインデクサーに強調表示し、それらをインデックス化する必要があることを知らせることができます。
+
+このタブでは、以下の概要を見ることができます：
+
+- キュレーションしている全てのサブグラフとシグナルの詳細
+- サブグラフごとのシェアの合計
+- サブグラフごとのクエリ報酬
+- 日付詳細に更新済み
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## プロフィールの設定
+
+ユーザープロフィールでは、個人的なプロフィールの詳細（ENS ネームの設定など）を管理することができます。 インデクサーの方は、さらに多くの設定が可能です。 ユーザープロファイルでは、デリゲーションパラメーターとオペレーターを設定することができます。
+
+- オペレーターは、インデクサーに代わって、割り当ての開始や終了など、プロトコル上の限定的なアクションを行います。 オペレーターは通常、ステーキングウォレットとは別の他の Ethereum アドレスで、インデクサーが個人的に設定できるネットワークへのゲート付きアクセス権を持っています。
+- 「Delegation parameters」では、自分とデリゲーターの間で GRT の分配をコントロールすることができます。
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From b5081a0418d568985cbebe511f1b60f4b0539f61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:47 -0500
Subject: [PATCH 2020/3820] New translations explorer.mdx (Korean)

---
 website/pages/ko/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/explorer.mdx

diff --git a/website/pages/ko/subgraphs/explorer.mdx b/website/pages/ko/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..433821560d85
--- /dev/null
+++ b/website/pages/ko/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraphs
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Signal/Un-signal on subgraphs
+- View more details such as charts, current deployment ID, and other metadata
+- Switch versions to explore past iterations of the subgraph
+- Query subgraphs via GraphQL
+- Test subgraphs in the playground
+- View the Indexers that are indexing on a certain subgraph
+- Subgraph stats (allocations, Curators, etc)
+- View the entity who published the subgraph
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Participants
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexers
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity - the maximum amount of delegated stake the Indexer can productively accept. An excess delegated stake cannot be used for allocations or rewards calculations.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Indexer Rewards - this is the total indexer rewards earned by the Indexer and their Delegators over all time. Indexer rewards are paid through GRT issuance.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curators
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- The date the Curator started curating
+- The number of GRT that was deposited
+- The number of shares a Curator owns
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegators
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- The number of Indexers a Delegator is delegating towards
+- A Delegator’s original delegation
+- The rewards they have accumulated but have not withdrawn from the protocol
+- The realized rewards they withdrew from the protocol
+- Total amount of GRT they have currently in the protocol
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Network
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Overview
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- The current total network stake
+- The stake split between the Indexers and their Delegators
+- Total supply, minted, and burned GRT since the network inception
+- Total Indexing rewards since the inception of the protocol
+- Protocol parameters such as curation reward, inflation rate, and more
+- Current epoch rewards and fees
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epochs
+
+In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
+
+- Epoch start or end block
+- Query fees generated and indexing rewards collected during a specific epoch
+- Epoch status, which refers to the query fee collection and distribution and can have different states:
+  - The active epoch is the one in which Indexers are currently allocating stake and collecting query fees
+  - The settling epochs are the ones in which the state channels are being settled. This means that the Indexers are subject to slashing if the consumers open disputes against them.
+  - The distributing epochs are the epochs in which the state channels for the epochs are being settled and Indexers can claim their query fee rebates.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Your User Profile
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Profile Overview
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Subgraphs Tab
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Indexing Tab
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+This section will also include details about your net Indexer rewards and net query fees. You’ll see the following metrics:
+
+- Delegated Stake - the stake from Delegators that can be allocated by you but cannot be slashed
+- Total Query Fees - the total fees that users have paid for queries served by you over time
+- Indexer Rewards - the total amount of Indexer rewards you have received, in GRT
+- Fee Cut - the % of query fee rebates that you will keep when you split with Delegators
+- Rewards Cut - the % of Indexer rewards that you will keep when splitting with Delegators
+- Owned - your deposited stake, which could be slashed for malicious or incorrect behavior
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Delegating Tab
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+In the first half of the page, you can see your delegation chart, as well as the rewards-only chart. To the left, you can see the KPIs that reflect your current delegation metrics.
+
+The Delegator metrics you’ll see here in this tab include:
+
+- Total delegation rewards
+- Total unrealized rewards
+- Total realized rewards
+
+In the second half of the page, you have the delegations table. Here you can see the Indexers that you delegated towards, as well as their details (such as rewards cuts, cooldown, etc).
+
+With the buttons on the right side of the table, you can manage your delegation - delegate more, undelegate, or withdraw your delegation after the thawing period.
+
+Keep in mind that this chart is horizontally scrollable, so if you scroll all the way to the right, you can also see the status of your delegation (delegating, undelegating, withdrawable).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Curating Tab
+
+In the Curation tab, you’ll find all the subgraphs you’re signaling on (thus enabling you to receive query fees). Signaling allows Curators to highlight to Indexers which subgraphs are valuable and trustworthy, thus signaling that they need to be indexed on.
+
+Within this tab, you’ll find an overview of:
+
+- All the subgraphs you're curating on with signal details
+- Share totals per subgraph
+- Query rewards per subgraph
+- Updated at date details
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Your Profile Settings
+
+Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
+
+- Operators take limited actions in the protocol on the Indexer's behalf, such as opening and closing allocations. Operators are typically other Ethereum addresses, separate from their staking wallet, with gated access to the network that Indexers can personally set
+- Delegation parameters allow you to control the distribution of GRT between you and your Delegators.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 4247ea4055189479d327c3670f7f302c8435275f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:48 -0500
Subject: [PATCH 2021/3820] New translations explorer.mdx (Dutch)

---
 website/pages/nl/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/explorer.mdx

diff --git a/website/pages/nl/subgraphs/explorer.mdx b/website/pages/nl/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..038fab07925a
--- /dev/null
+++ b/website/pages/nl/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Verkenner
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraphs
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Het toevoegen/weghalen van signaal op een subgraph
+- Details zoals grafieken, huidige implementatie-ID en andere metadata
+- Schakel tussen versies om eerdere iteraties van de subgraph te verkennen
+- Query subgraphs via GraphQL
+- Subgraphs testen in de playground
+- Bekijk de indexeerders die indexeren op een bepaalde subgraph
+- Subgraphstatistieken (allocaties, curatoren, etc.)
+- Bekijk de entiteit die de subgraph heeft gepubliceerd
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Deelnemers
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexers
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity - het maximale bedrag aan gedelegeerde inzet dat de Indexer productief kan accepteren. Een teveel aan gedelegeerde inzet kan niet worden gebruikt voor allocaties of beloningsberekeningen.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Indexer Rewards - dit zijn de totale indexerbeloningen die door de Indexer en hun Delegeerders zijn verdiend. Indexerbeloningen worden uitbetaald via de uitgifte van GRT.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curatoren
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- De datum waarop de curator is begonnen met cureren
+- Het gestorte aantal GRT
+- Het aantal curator-aandelen in het bezit van de curator
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegators
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- Het aantal Indexeerders waaraan een Delegator heeft gedelegeerd
+- De oorspronkelijke delegatie van een Delegator
+- De beloningen die ze hebben opgebouwd, maar nog niet hebben opgenomen uit het protocol
+- De gerealiseerde beloningen die ze uit het protocol hebben opgenomen
+- Het totale bedrag aan GRT dat ze momenteel in het protocol hebben
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Netwerk
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Overview
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- De huidige totale hoeveelheid GRT in het netwerk
+- De verdeling van de GRT tussen Indexeerders en hun Delegators
+- Totale voorraad, gemunt en verbrand GRT sinds de start van het netwerk
+- Totale indexeringsbeloningen sinds de start van het protocol
+- Protocolparameters zoals curatiebeloningen, inflatiepercentage, en meer
+- Huidige epoch beloningen en kosten
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epochs
+
+In de Epochs afdeling kun je per epoch verschillende metrieken analyseren, zoals:
+
+- Start- of eindblock van de epoch
+- Gegenereerde querykosten en verzamelde indexeringsbeloningen tijden een specifieke epoch
+- Epoch status, verwijst naar de verzameling en distributie van querykosten en zich in verschillende staten kan bevinden:
+  - De actieve epoch is degene waarin Indexers momenteel Grt toewijzen en querykosten verzamelen
+  - De afhandelende epochs zijn die waarin de state channels worden afgehandeld. Dit betekent dat Indexers te maken kunnen krijgen met slashing als consumenten geschillen tegen hen openen.
+  - De distribuerende epochs zijn de epochs waarin de state channels voor de epochs worden afgehandeld en Indexeerders hun querykostenkorting kunnen claimen.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Uw Gebruikersprofiel
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Profieloverzicht
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Subgraph Tab
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Indexing Tab
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+Dit gedeelte bevat ook details over uw netto indexeringsbeloningen en netto querykosten. U zult de volgende metrics zien:
+
+- Gedelegeerde GRT - de GRT van Delegators die door u kan worden toegewezen, maar die niet kan worden geslashed
+- Totale Querykosten - de totale kosten die door gebruikers in de loop van de tijd hebben betaald voor queries die door u zijn verwerkt
+- Indexer-beloningen - het totale bedrag aan Indexer-beloningen dat u heeft ontvangen, in GRT
+- Fee Cut - het percentage van de query fee rebates dat u houdt wanneer u het splitst met Delegators
+- Reward Cut - het % van Indexer-beloningen dat u houdt bij het splitsen met Delegators
+- Owned - jouw eigen gestorte inzet, die kan worden geslashed voor kwaadaardig of incorrect gedrag
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Delegating Tab
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+In de eerste helft van de pagina kunt u uw delegatiegrafiek zien, evenals de alleen-beloningen-grafiek. Aan de linkerkant kun u de KPI's zien die uw huidige delegatiemetrics weerspiegelen.
+
+De Delegator-metrieken die u hier in deze tab zult zien, omvatten:
+
+- Totale delegatiebeloningen
+- Totale niet-gerealiseerde beloningen
+- Totaal gerealiseerde beloningen
+
+In de tweede helft van de pagina heeft u de delegatietabel. Hier kunt u de Indexeerders zien waarnaar u hebt gedelegeerd, evenals hun parameters (zoals beloningsverlagingen, afkoelperiode, enz.).
+
+Met de knoppen aan de rechterkant van de tabel kunt u uw delegatie beheren - meer delegeren, stoppen met delegeren of uw delegatie opnemen na de ontdooiperiode.
+
+Houd er rekening mee dat deze grafiek horizontaal scrollbaar is, dus als u helemaal naar rechts scrolt, kunt u ook de status van uw delegatie zien (delegeren, ontdooien, opneembaar).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Curating Tab
+
+Op de Curating Tab vind je alle subgraphs waarop je signaleert (dit stelt je in staat om querykosten te ontvangen). Singaleren stelt Curatoren in staat om aan Indexeerders te laten zien welke subgraphs waardevol en betrouwbaar zijn, wat aangeeft dat ze geïndexeerd moeten worden.
+
+Binnen deze tab vind je een overzicht van:
+
+- Alle subgraphs waarop je cureert met signaaldetails
+- Totale aandelen per subgraph
+- Querybeloningen per subgraph
+- Gegevens van de bijwerkdatum
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Jouw profielinstellingen
+
+Binnen je gebruikersprofiel kun je je persoonlijke profielgegevens beheren (zoals het instellen van een ENS-naam). Als je een Indexeerder bent, heb je nog meer toegang tot instellingen binnen handbereik. In je gebruikersprofiel kun je je delegatieparameters en operators instellen.
+
+- Operators nemen beperkte acties in het protocol namens de Indexer, zoals het openen en sluiten van allocaties. Operators zijn doorgaans andere Ethereum-adressen, los van hun wallet die inzet, met beperkte toegang tot het netwerk die Indexeerders persoonlijk kunnen instellen
+- Delegatieparameters stellen je in staat om de verdeling van GRT tussen jou en je Delegators te regelen.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 440e85dc448c18c788d976f31f911ceecfd597a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:49 -0500
Subject: [PATCH 2022/3820] New translations explorer.mdx (Polish)

---
 website/pages/pl/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/explorer.mdx

diff --git a/website/pages/pl/subgraphs/explorer.mdx b/website/pages/pl/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..c10068643631
--- /dev/null
+++ b/website/pages/pl/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgrafy
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Signal/Un-signal on subgraphs
+- View more details such as charts, current deployment ID, and other metadata
+- Switch versions to explore past iterations of the subgraph
+- Query subgraphs via GraphQL
+- Test subgraphs in the playground
+- View the Indexers that are indexing on a certain subgraph
+- Subgraph stats (allocations, Curators, etc)
+- View the entity who published the subgraph
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Participants
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexers
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity - the maximum amount of delegated stake the Indexer can productively accept. An excess delegated stake cannot be used for allocations or rewards calculations.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Indexer Rewards - this is the total indexer rewards earned by the Indexer and their Delegators over all time. Indexer rewards are paid through GRT issuance.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curators
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- The date the Curator started curating
+- The number of GRT that was deposited
+- The number of shares a Curator owns
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegators
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- The number of Indexers a Delegator is delegating towards
+- A Delegator’s original delegation
+- The rewards they have accumulated but have not withdrawn from the protocol
+- The realized rewards they withdrew from the protocol
+- Total amount of GRT they have currently in the protocol
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Network
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Overview
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- The current total network stake
+- The stake split between the Indexers and their Delegators
+- Total supply, minted, and burned GRT since the network inception
+- Total Indexing rewards since the inception of the protocol
+- Protocol parameters such as curation reward, inflation rate, and more
+- Current epoch rewards and fees
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epochs
+
+In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
+
+- Epoch start or end block
+- Query fees generated and indexing rewards collected during a specific epoch
+- Epoch status, which refers to the query fee collection and distribution and can have different states:
+  - The active epoch is the one in which Indexers are currently allocating stake and collecting query fees
+  - The settling epochs are the ones in which the state channels are being settled. This means that the Indexers are subject to slashing if the consumers open disputes against them.
+  - The distributing epochs are the epochs in which the state channels for the epochs are being settled and Indexers can claim their query fee rebates.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Your User Profile
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Profile Overview
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Subgraphs Tab
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Indexing Tab
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+This section will also include details about your net Indexer rewards and net query fees. You’ll see the following metrics:
+
+- Delegated Stake - the stake from Delegators that can be allocated by you but cannot be slashed
+- Total Query Fees - the total fees that users have paid for queries served by you over time
+- Indexer Rewards - the total amount of Indexer rewards you have received, in GRT
+- Fee Cut - the % of query fee rebates that you will keep when you split with Delegators
+- Rewards Cut - the % of Indexer rewards that you will keep when splitting with Delegators
+- Owned - your deposited stake, which could be slashed for malicious or incorrect behavior
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Delegating Tab
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+In the first half of the page, you can see your delegation chart, as well as the rewards-only chart. To the left, you can see the KPIs that reflect your current delegation metrics.
+
+The Delegator metrics you’ll see here in this tab include:
+
+- Total delegation rewards
+- Total unrealized rewards
+- Total realized rewards
+
+In the second half of the page, you have the delegations table. Here you can see the Indexers that you delegated towards, as well as their details (such as rewards cuts, cooldown, etc).
+
+With the buttons on the right side of the table, you can manage your delegation - delegate more, undelegate, or withdraw your delegation after the thawing period.
+
+Keep in mind that this chart is horizontally scrollable, so if you scroll all the way to the right, you can also see the status of your delegation (delegating, undelegating, withdrawable).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Curating Tab
+
+In the Curation tab, you’ll find all the subgraphs you’re signaling on (thus enabling you to receive query fees). Signaling allows Curators to highlight to Indexers which subgraphs are valuable and trustworthy, thus signaling that they need to be indexed on.
+
+Within this tab, you’ll find an overview of:
+
+- All the subgraphs you're curating on with signal details
+- Share totals per subgraph
+- Query rewards per subgraph
+- Updated at date details
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Your Profile Settings
+
+Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
+
+- Operators take limited actions in the protocol on the Indexer's behalf, such as opening and closing allocations. Operators are typically other Ethereum addresses, separate from their staking wallet, with gated access to the network that Indexers can personally set
+- Delegation parameters allow you to control the distribution of GRT between you and your Delegators.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 9db5a7996052e6737a3eed83e8703783fecd8126 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:50 -0500
Subject: [PATCH 2023/3820] New translations explorer.mdx (Portuguese)

---
 website/pages/pt/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/explorer.mdx

diff --git a/website/pages/pt/subgraphs/explorer.mdx b/website/pages/pt/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..ed92cd1a8712
--- /dev/null
+++ b/website/pages/pt/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraphs
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Sinalização/cancelamento de sinais em subgraphs
+- Ver mais detalhes como gráficos, ID de lançamento atual, e outros metadados
+- Trocar versões para explorar iterações passadas do subgraph
+- Consultar subgraphs através do GraphQL
+- Testar subgraphs no playground
+- Ver os indexadores que indexam em um certo subgraph
+- Estatísticas do subgraph (alocações, Curadores, etc.)
+- Visualizar a entidade que publicou o subgraph
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Participantes
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexadores
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Capacidade Máxima de Delegação — a quantidade máxima de stake delegado que o Indexador pode aceitar produtivamente. Um excesso de stake delegado não pode ser usado para alocações ou cálculos de recompensas.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Recompensas de Indexador — as recompensas totais recebidas pelo Indexador e pelos Delegantes temporalmente. As recompensas de Indexador são pagas pela emissão de GRT.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curadores
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- A data em que o Curador começou a curar
+- O número de GRT depositado
+- O número de ações que um Curador tem
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegantes
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- O número de Indexadores aos quais um Delegante delega
+- A delegação original de um Delegante
+- As recompensas que acumularam, mas não sacaram, do protocolo
+- As recompensas realizadas que sacaram do protocolo
+- A quantidade total de GRT que têm no protocolo no momento
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Rede
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Visão geral
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- O stake total atual da rede
+- O stake dividido entre os Indexadores e os seus Delegantes
+- Total de GRT cunhado, queimado e na reserva desde a criação da rede
+- Total de recompensas de Indexação desde a origem do protocolo
+- Parâmetros de protocolo como recompensas de curadoria, ritmo de inflação, e mais
+- Recompensas e taxas na epoch atual
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epochs
+
+Na seção de Epochs, pode analisar, numa base por epoch, métricas como:
+
+- Bloco inicial ou final de uma epoch
+- Taxas de query geradas e recompensas de indexação colecionadas durante uma epoch específica
+- Estado da epoch, que refere à coleção e distribuição de taxas de query, e pode ter situações diferentes:
+  - A epoch ativa é aquela em que os Indexadores atualmente alocam stake e colecionam taxas de query
+  - As epochs de estabelecimento são aquelas em que os canais de estado são estabelecidos. Portanto, os Indexadores são sujeitos a cortes caso os consumidores abram disputas contra eles.
+  - Nas epochs de distribuição, são estabelecidos os canais de estado para as epochs, e os Indexadores podem reivindicar os seus rebates de taxas de query.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Seu Perfil de Utilizador
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Resumo do Perfil
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Aba de Subgraphs
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Aba de Indexação
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+Esta secção também incluirá detalhes sobre as suas recompensas de Indexador e taxas de consulta. Verá as seguintes métricas:
+
+- Stake Delegado — O stake de Delegados que pode ser alocado por você, mas não pode ser cortado
+- Taxas Totais de Query — as taxas totais que os utilizadores pagaram por consultas que serviu temporalmente
+- Recompensas de Indexador — a quantia total de recompensas de Indexador que recebeu, em GRT
+- Porção de Taxa — a % dos rebates das taxas de query que guardará ao dividir com os Delegantes
+- Porção de Recompensas — a % dos rebates das recompensas de Indexador que guarda ao dividir com os Delegantes
+- Títulos — o seu stake depositado, que pode ser cortado por comportamento malicioso ou incorreto
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Aba de Delegação
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+Na primeira metade da página estão o seu gráfico de delegação e um gráfico só de recompensas. Na esquerda, pode ver os KPIs (indicadores de desempenho) que refletem as suas métricas atuais de delegação.
+
+As métricas de Delegado nesta aba incluem:
+
+- Recompensas totais de delegação
+- Recompensas não realizadas
+- Recompensas realizadas
+
+Na segunda metade da página está a tábua de delegações. Aqui, pode ver os Indexadores aos quais delegou, assim como os seus detalhes (como porções de recompensas, tempo de recarga, etc.).
+
+Com os botões no lado direito da tábua, pode gestar a sua delegação — delegar mais, cancelar delegações, ou retirar a sua delegação após o período de degelo.
+
+Lembre-se que este gráfico pode ser rolado horizontalmente, então se rolar totalmente à direita, pode ver o estado da sua delegação (a delegar, a cancelar, sacável).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Aba de Curadoria
+
+Na aba de Curadoria, ncontrará todos os subgraphs nos quais sinaliza (assim, capaz de receber taxas de consulta). A sinalização permite que os Curadores destaquem aos Indexadores quais subgraphs são valiosos e confiáveis, e assim, indicar que eles devem ser indexados.
+
+Dentro desta aba está um resumo de:
+
+- Todos os subgraphs que cura, com detalhes de sinalização
+- Totais de ações por subgraph
+- Recompensas de query por subgraph
+- Detalhes de datas de atualização
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Configurações do Seu Perfil
+
+Dentro do seu perfil de utilizador, poderá configurar os detalhes do seu perfil pessoal (como a configuração de um nome ENS). Se fores um Indexador, terá ainda mais acesso às configurações no alcance dos seus dedos. Em seu perfil de utilizador, poderá configurar os seus parâmetros de delegação e os seus operadores.
+
+- Os Operadores tomam ações limitadas no protocolo em nome do Indexador, como abertura e fechamento de alocações. Os operadores tendem a ser outros endereços do Ethereum, separados da sua carteira de staking, com acesso guardado à rede que pode ser configurado pessoalmente pelos Indexadores
+- Parâmetros de delegação que permitem controlar a distribuição de GRT entre você e os seus Delegantes.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+Como o seu portal oficial no mundo dos dados descentralizados, o Graph Explorer permite-lhe tomar uma variedade de ações, independente do seu papel na rede. Pode acessar as suas configurações do perfil ao abrir o menu próximo ao seu endereço, e depois, clicar no botão de Configurações.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 825daa5a95052f74da9a959df4bffe1687346a11 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:52 -0500
Subject: [PATCH 2024/3820] New translations explorer.mdx (Russian)

---
 website/pages/ru/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/explorer.mdx

diff --git a/website/pages/ru/subgraphs/explorer.mdx b/website/pages/ru/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..5a42b6201dce
--- /dev/null
+++ b/website/pages/ru/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Субграфы
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Сигнал/снятие сигнала на субграфах
+- Просмотр дополнительных сведений, таких как диаграммы, текущий идентификатор развертывания и другие метаданные
+- Переключение версии с целью изучения прошлых итераций субграфа
+- Запрос субграфов через GraphQL
+- Тестовые субграфы на тренировочной площадке
+- Просмотр индексаторов, индексирующих определенный субграф
+- Статистика субграфов (распределения, кураторы и т. д.)
+- Просмотр объекта, опубликовавшего субграф
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Участники
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Индексаторы
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Максимальная емкость делегирования — максимальная сумма делегированной доли, которую Индексатор может продуктивно принять. Избыточная делегированная ставка не может быть использована для распределения или расчета вознаграждений.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Вознаграждения Индексатора — это общая сумма вознаграждений Индексатора, полученная им и его Делегаторами за все время. Вознаграждения Индексаторов выплачиваются посредством выпуска GRT.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Кураторы
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- Дату начала курирования
+- Количество GRT, которое было внесено
+- Количество акций, которыми владеет Куратор
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Делегаторы
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- Количество Индексаторов, к которым делегирует Делегатор
+- Первоначальная делегация Делегатора
+- Накопленные ими вознаграждения, которые они не вывели из протокола
+- Реализованные вознаграждения, которые они сняли с протокола
+- Общее количество GRT, которое у них имеется в настоящее время в протоколе
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Сеть
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Обзор
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- Текущая общая доля сети
+- Доля распределяется между Индексаторами и их Делегаторами
+- Общий запас, отчеканенные и сожженные GRT с момента создания сети
+- Общее вознаграждение за индексацию с момента создания протокола
+- Параметры протокола, такие как вознаграждение за курирование, уровень инфляции и т. д
+- Награды и сборы текущей эпохи
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Эпохи
+
+В разделе «Эпохи» Вы можете анализировать по эпохам такие показатели, как:
+
+- Начало или конец блока эпохи
+- Комиссионные за запросы и вознаграждения за индексацию, полученные в течение определенной эпохи
+- Статус эпохи, который относится к сбору и распределению комиссионных за запросы и может иметь разные состояния:
+  - Активная эпоха - это та, в которой Индексаторы в настоящее время выделяют ставки и собирают комиссионные за запросы
+  - Эпохи урегулирования — это эпохи, в которых используются государственные каналы. Это означает, что Индексаторы могут столкнуться с сокращением своих GRT, если потребители откроют против них споры.
+  - Эпохи распределения - это эпохи, в которых состояния каналов для эпох регулируются, и Индексаторы могут требовать скидки на комиссию за запросы.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Ваш профиль пользователя
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Обзор профиля
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Вкладка "Субграфы"
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Вкладка "Индексирование"
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+Этот раздел также будет содержать подробную информацию о Ваших чистых вознаграждениях Индексатора и чистой комиссии за запросы. Вы увидите следующие показатели:
+
+- Делегированная ставка — ставка Делегаторов, которую Вы можете выделить, но не можете уменьшить
+- Общая комиссия за запросы — общая сумма комиссий, которую пользователи платили за запросы, обслуживаемые Вами за определенный период времени
+- Вознаграждения Индексатора – общая сумма полученных Вами вознаграждений Индексатора в GRT
+- Сокращение комиссии — процент скидки на комиссию за запросы, который Вы сохраните при разделении с Делегаторами
+- Сокращение вознаграждений — процент вознаграждений Индексатора, который Вы сохраните при разделении с Делегаторами
+- Собственность — Ваша внесенная ставка, которая может быть уменьшена за злонамеренное или неправильное поведение
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Вкладка "Делегирование"
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+В первой половине страницы Вы можете увидеть диаграмму делегирования, а также диаграмму только вознаграждений. Слева Вы можете увидеть ключевые показатели эффективности, которые отражают Ваши текущие показатели делегирования.
+
+Метрики делегатора, которые Вы увидите на этой вкладке, включают:
+
+- Общую сумму вознаграждений за делегирование
+- Общее количество нереализованных наград
+- Общее количество реализованных наград
+
+Во второй половине страницы находится таблица делегирования. Здесь Вы можете увидеть Индексаторов, которым Вы делегировали полномочия, а также подробную информацию о них (например, сокращение вознаграждений, время восстановления и т. д.).
+
+С помощью кнопок в правой части таблицы Вы можете управлять своим делегированием: делегировать больше, отменить делегирование или отозвать свое делегирование после разморозки.
+
+Имейте в виду, что эта диаграмма прокручивается по горизонтали, поэтому, если Вы прокрутите ее до конца вправо, Вы также сможете увидеть статус своего делегирования (делегирование, отмена делегирования, возможность отзыва).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Вкладка "Курирование"
+
+На вкладке «Курирование» Вы найдете все субграфы, на которые Вы подаете сигналы (что позволит Вам получать комиссию за запросы). Сигнализация позволяет Кураторам указывать Индексаторам, какие субграфы являются ценными и заслуживающими доверия, тем самым сигнализируя о том, что их необходимо проиндексировать.
+
+На данной вкладке Вы найдете обзор:
+
+- Всех субграфов, которые Вы курируете, с подробной информацией о сигнале
+- Общего количества акций на субграф
+- Вознаграждений за запрос за субграф
+- Даты обновления данных
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Параметры Вашего профиля
+
+В Вашем пользовательском профиле Вы сможете управлять деталями своего личного профиля (например, настройкой имени ENS). Если Вы Индексатор, у Вас есть еще больше возможностей для доступа к настройкам. В Вашем пользовательском профиле Вы сможете настроить параметры делегирования и операторов.
+
+- Операторы выполняют ограниченные действия в протоколе от имени Индексатора, такие как открытие и закрытие распределения. Операторами обычно являются другие адреса Ethereum, отдельные от их кошелька для ставок, с ограниченным доступом к сети, который Индексаторы могут настроить лично
+- Параметры делегирования позволяют Вам контролировать распределение GRT между Вами и Вашими Делегаторами.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From bf48e53135cd1c4e0056654c97b693e8189544e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:53 -0500
Subject: [PATCH 2025/3820] New translations explorer.mdx (Swedish)

---
 website/pages/sv/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/explorer.mdx

diff --git a/website/pages/sv/subgraphs/explorer.mdx b/website/pages/sv/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..dece06cd1472
--- /dev/null
+++ b/website/pages/sv/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graf Utforskaren
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraffar
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Signalera/Sluta signalera på subgraffar
+- Visa mer detaljer som diagram, aktuell distributions-ID och annan metadata
+- Växla versioner för att utforska tidigare iterationer av subgraffen
+- Fråga subgraffar via GraphQL
+- Testa subgraffar i lekplatsen
+- Visa indexerare som indexerar på en viss subgraff
+- Subgraffstatistik (tilldelningar, kuratorer, etc.)
+- Visa enheten som publicerade subgraffen
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Deltagare
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexerare
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Maximal delegeringskapacitet - den maximala mängden delegerad insats som indexeraren produktivt kan acceptera. Överskjuten delegerad insats kan inte användas för tilldelningar eller beräkningar av belöningar.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Indexeringsbelöningar - detta är de totala indexeringsbelöningarna som indexeraren och deras delegater har tjänat över tid. Indexeringsbelöningar betalas genom GRT-utgivning.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Kuratorer
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- Datumet då kuratorn började kurera
+- Antalet GRT som deponerades
+- Antalet andelar en kurator äger
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegater
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- Antal indexerare en delegat delegerar till
+- En delegats ursprungliga delegation
+- Belöningar de har ackumulerat men inte har dragit tillbaka från protokollet
+- De realiserade belöningarna de drog tillbaka från protokollet
+- Totalt belopp av GRT som de för närvarande har i protokollet
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Nätverk
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Översikt
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- Nuvarande totala nätverksinsats
+- Insatsen fördelad mellan indexerare och deras delegater
+- Totalt utbud, myntade och brända GRT sedan nätverkets start
+- Totala indexeringsbelöningar sedan protokollets början
+- Protokollparametrar såsom kuratorbelöning, inflationstakt och mer
+- Nuvarande epokbelöningar och avgifter
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epoker
+
+I avsnittet Epoker kan du analysera på en per-epok-basis, metriker som:
+
+- Epokens start- eller slutblock
+- Frågeavgifter som genererats och indexeringsbelöningar som samlats in under en specifik epok
+- Epokstatus, som hänvisar till frågeavgiftsinsamling och distribution och kan ha olika tillstånd:
+  - Den aktiva epoken är den där indexerare för närvarande allokerar insats och samlar frågeavgifter
+  - De avvecklande epokerna är de där statliga kanaler avvecklas. Detta innebär att indexerare är föremål för straff om användarna öppnar tvister mot dem.
+  - De distribuerande epokerna är de epoker där statliga kanaler för epokerna avvecklas och indexerare kan kräva sina frågeavgiftsrabatter.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Din användarprofil
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Profilöversikt
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Subgraffar-fliken
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Indexeringstabell
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+I det här avsnittet hittar du också information om dina nettobelöningar som indexerare och nettovärdaravgifter. Du kommer att se följande metriker:
+
+- Delegerad insats - insatsen från delegater som kan tilldelas av dig men inte kan straffas
+- Totala frågeavgifter - de totala avgifter som användare har betalat för frågor som du har serverat över tid
+- Indexeringsbelöningar - den totala mängd indexeringsbelöningar du har fått, i GRT
+- Avgiftsskärning - den procentandel av frågeavgiftsrabatter som du kommer att behålla när du delar med delegater
+- Belöningsrabatt - den procentandel av indexeringsbelöningar som du kommer att behålla när du delar med delegater
+- Ägd - din deponerade insats, som kan straffas för skadligt eller felaktigt beteende
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Delegattabell
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+I den första halvan av sidan kan du se din delegatdiagram, liksom diagrammet för endast belöningar. Till vänster kan du se KPI:er som återspeglar dina aktuella delegationsmetriker.
+
+De delegatmetriker du kommer att se här i den här fliken inkluderar:
+
+- Totala delegationsbelöningar
+- Totala orealiserade belöningar
+- Totala realiserade belöningar
+
+I den andra halvan av sidan har du delegattabellen. Här kan du se indexerarna som du har delegerat till, samt deras detaljer (som belönningsskärningar, nedkylning, etc).
+
+Med knapparna på höger sida av tabellen kan du hantera din delegation - delegera mer, avdelegatera eller ta tillbaka din delegation efter upptiningstiden.
+
+Kom ihåg att denna tabell kan rullas horisontellt, så om du rullar hela vägen till höger kan du också se status för din delegation (delegering, avdelegering, återkallelig).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Kureringstabell
+
+I Kureringstabellen hittar du alla subgraffar du signalerar på (vilket gör det möjligt för dig att ta emot frågeavgifter). Signalering gör att kuratorer kan informera indexerare om vilka subgraffar som är värdefulla och pålitliga, vilket signalerar att de bör indexerats.
+
+Inom den här fliken hittar du en översikt över:
+
+- Alla subgraffar du signalerar på med signaldetaljer
+- Andelar totalt per subgraff
+- Frågebelöningar per subgraff
+- Uppdaterade datumdetaljer
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Dina profilinställningar
+
+Inom din användarprofil kommer du att kunna hantera dina personliga profiluppgifter (som att ställa in ett ENS-namn). Om du är indexerare har du ännu mer åtkomst till inställningar inom räckhåll. I din användarprofil kan du ställa in dina delegationsparametrar och operatörer.
+
+- Operatörer tar begränsade åtgärder i protokollet på indexerarens vägnar, såsom att öppna och stänga tilldelningar. Operatörer är vanligtvis andra Ethereum-adresser, separata från deras stakningsplånbok, med gated access till nätverket som indexerare personligen kan ställa in
+- Delegationsparametrar låter dig kontrollera fördelningen av GRT mellan dig och dina delegater.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From cabd2556f5596b21a9e2efe51452720b4597155b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:54 -0500
Subject: [PATCH 2026/3820] New translations explorer.mdx (Turkish)

---
 website/pages/tr/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/explorer.mdx

diff --git a/website/pages/tr/subgraphs/explorer.mdx b/website/pages/tr/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..d91ee86d2aa8
--- /dev/null
+++ b/website/pages/tr/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Gezgini
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraph'ler
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Subgraphlar üzerinde sinyal/sinyalsizlik
+- Grafikler, mevcut dağıtım kimliği ve diğer üst veri gibi daha fazla ayrıntı görüntüleme
+- Subgraph'ın geçmiş yinelemelerini keşfetmek için sürümleri değiştirme
+- GraphQL aracılığıyla subgraphlar'ı sorgulama
+- Test alanında(playground) subgraphlar'ı test etme
+- Belirli bir subgraph üzerinde indeksleme yapan İndeksleyicileri görüntüleme
+- Subgraph istatistikleri (tahsisler, Küratörler, vb.)
+- Subgraph'ı yayınlayan varlığı görüntüleme
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Katılımcılar
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. İndeksleyiciler
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Maksimum Delegasyon Kapasitesi - Endekserin verimli bir şekilde kabul edebileceği en yüksek delegasyon miktarıdır. Fazla delege edilmiş pay, tahsisler veya ödül hesaplamaları için kullanılamaz.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- İndeksleyici Ödülleri - bu, İndeksleyici ve Delegatörler tarafından tüm zaman boyunca kazanılan toplam indeksleyici ödülleridir. İndeksleyici ödülleri GRT ihracı yoluyla ödenir.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Küratörler
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- Küratör'ün küratörlüğe başladığı tarih
+- Yatırılan GRT sayısı
+- Küratör'ün sahip olduğu hisse sayısı
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegatörler
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- Bir Delegatör'ün delege ettiği İndeksleyici sayısı
+- Bir Delegatör'ün orijinal delegasyonu
+- Biriktirdikleri ancak protokolden çekmedikleri ödüller
+- Protokolden çekildiler gerçekleşmiş ödüller
+- Şu anda protokolde bulunan sahip oldukları toplam GRT miktarı
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Ağ
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Genel Bakış
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- Mevcut toplam ağ payı
+- İndeksleyiciler ve Delegatörler arasındaki pay paylaşımı
+- Ağın başlangıcından bu yana toplam arz, basılan ve yakılan GRT
+- Protokolün başlangıcından bu yana toplam İndeksleme ödülleri
+- Kürasyon ödülü, enflasyon oranı ve daha fazlası gibi protokol parametreleri
+- Mevcut dönem ödülleri ve ücretleri
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Dönemler
+
+Dönemler bölümünde, aşağıdaki gibi metrikleri dönem bazında analiz edebilirsiniz:
+
+- Dönem başlangıç veya bitiş bloğu
+- Belirli bir dönem boyunca oluşturulan sorgu ücretleri ve toplanan indeksleme ödülleri
+- Sorgu ücreti toplama ve dağıtımını ifade eden ve farklı durumlara sahip olabilen dönem durumu:
+  - Aktif dönem, İndeksleyicilerin halihazırda pay tahsis ettiği ve sorgu ücretlerini topladığı dönemdir
+  - Uzlaşma dönemleri, bildirim kanallarının uzlaştırıldığı dönemlerdir. Bu, kullanıcıların kendilerine karşı itirazda bulunması halinde İndeksleyicilerin kesintiye maruz kalacağı anlamına gelir.
+  - Dağıtım dönemleri, bildirim kanallarının dönemler için yerleştiği ve İndeksleyicilerin sorgu ücreti iadelerini talep edebildiği dönemlerdir.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Kullanıcı Profiliniz
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Profile Genel Bakış
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Subgraphlar Sekmesi
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### İndeksleme Sekmesi
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+Bu bölümde ayrıca net İndeksleyici ödülleriniz ve sorgu ücretlerinizle ilgili ayrıntılar da yer alacaktır. Aşağıdaki metrikleri göreceksiniz:
+
+- Delege Edilen Pay - delegatörler'in sizin tarafınızdan tahsis edilebilen fakat kesilemeyen payları
+- Toplam Sorgu Ücretleri - kullanıcıların zaman içinde sizin tarafınızdan sunulan sorgular için ödedikleri toplam ücretler
+- İndeksleyici Ödülleri - GRT olarak aldığınız İndeksleyici ödüllerinin toplam tutarı
+- Ücret Kesintisi - Delegatörlerle ayrıldığınızda elinizde kalacak sorgu ücreti iadelerinin yüzdesi
+- Ödül Kesintisi - Delegatörlerle ayrılırken İndeksleyici ödüllerinin elinizde kalacak yüzdesi
+- Depozito - kötü niyetli veya yanlış davranışlarınız sonucu kesilebilecek yatırılmış payınız
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Delegasyon Sekmesi
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+Sayfanın ilk yarısında, delegasyon grafiğinizin yanı sıra yalnızca ödül grafiğini de görebilirsiniz. Sol tarafta, mevcut delegasyon metriklerinizi yansıtan APG'leri görebilirsiniz.
+
+Bu sekmede göreceğiniz Delegatör metrikleri şunları içermektedir:
+
+- Toplam delegasyon ödülleri
+- Toplam gerçekleşmemiş ödüller
+- Toplam gerçekleşmiş ödüller
+
+Sayfanın ikinci yarısında delegasyonlar tablosu yer alır. Burada delege ettiğiniz İndeksleyicileri ve ayrıntılarını (ödül kesintileri, bekleme süreleri vb.) görebilirsiniz.
+
+Tablonun sağ tarafındaki düğmelerle delegasyonunuzu yönetebilirsiniz - daha fazla delege edebilir, delegasyonunuzu geri alabilir veya serbest kalma döneminden sonra delegasyonunuzu geri çekebilirsiniz.
+
+Bu grafiğin yatay olarak kaydırılabilir olduğunu unutmayın, bu nedenle sağa doğru kaydırırsanız, delegasyonunuzun durumunu da görebilirsiniz (delege edilen, delegeden çıkarılan, geri çekilebilir).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Kürasyon Sekmesi
+
+Kürasyon sekmesinde, sinyal verdiğiniz (sonucunda sorgu ücreti almanızı sağlayan) tüm subgraphlar'ı bulacaksınız. Sinyalleme, Küratörlerin İndeksleyicilere hangi subgraphlar'ın değerli ve güvenilir olduğunu belirtmesine ve böylece indekslenmeleri gerektiğinin belirtilmesine olanak tanır.
+
+Bu sekmede, aşağıdakilerin genel bir bakışını bulacaksınız:
+
+- Sinyal ayrıntılarıyla birlikte küratörlüğünü yaptığınız tüm subgraphlar
+- Subraph başına pay toplamları
+- Subgraph başına sorgu ödülleri
+- Güncelleme tarih detayları
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Profil Ayarlarınız
+
+Kullanıcı profilinizde, kişisel profil ayrıntılarınızı yönetebileceksiniz (bir ENS adı almak gibi). Eğer bir İndeksleyiciyseniz, daha fazla ayara erişiminiz olacaktır. Kullanıcı profilinizde, delegasyon parametrelerinizi ve operatörlerinizi ayarlayabileceksiniz.
+
+- Operatörler, İndeksleyici adına protokolde tahsislerin açılması ve kapatılması gibi sınırlı işlemlerde bulunur. Operatörler tipik olarak, stake cüzdanlarından ayrı, İndeksleyicilerin kişisel olarak ayarlayabileceği ağa kontrollü bir şekilde erişime sahip diğer Ethereum adresleridir
+- Delegasyon parametreleri, GRT'nin siz ve Delegatörleriniz arasındaki dağılımını kontrol etmenizi sağlar.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From b80a9828612384862e41aa8a262be5471f9bc18f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:55 -0500
Subject: [PATCH 2027/3820] New translations explorer.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/explorer.mdx

diff --git a/website/pages/uk/subgraphs/explorer.mdx b/website/pages/uk/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..e70122cdc018
--- /dev/null
+++ b/website/pages/uk/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Підграфи
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Наявність/відсутність сигналу на підграфах
+- Перегляд додаткових відомостей, таких як діаграми, поточний ID розгортання та інші ключові параметри
+- Перемикання версій для дослідження минулих ітерацій підграфа
+- Запит до підграфів через GraphQL
+- Тестування підграфів в інтерактивному середовищі
+- Перегляд індексаторів, які індексують певний підграф
+- Статистика підграфів (розподіл коштів, куратори тощо)
+- Переглянути особу, яка опублікувала підграф
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Учасники
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Індексатори
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity - the maximum amount of delegated stake the Indexer can productively accept. An excess delegated stake cannot be used for allocations or rewards calculations.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Indexer Rewards - this is the total indexer rewards earned by the Indexer and their Delegators over all time. Indexer rewards are paid through GRT issuance.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curators
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- The date the Curator started curating
+- The number of GRT that was deposited
+- The number of shares a Curator owns
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegators
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- The number of Indexers a Delegator is delegating towards
+- A Delegator’s original delegation
+- The rewards they have accumulated but have not withdrawn from the protocol
+- The realized rewards they withdrew from the protocol
+- Total amount of GRT they have currently in the protocol
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Network
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Overview
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- The current total network stake
+- The stake split between the Indexers and their Delegators
+- Total supply, minted, and burned GRT since the network inception
+- Total Indexing rewards since the inception of the protocol
+- Protocol parameters such as curation reward, inflation rate, and more
+- Current epoch rewards and fees
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epochs
+
+In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
+
+- Epoch start or end block
+- Query fees generated and indexing rewards collected during a specific epoch
+- Epoch status, which refers to the query fee collection and distribution and can have different states:
+  - The active epoch is the one in which Indexers are currently allocating stake and collecting query fees
+  - The settling epochs are the ones in which the state channels are being settled. This means that the Indexers are subject to slashing if the consumers open disputes against them.
+  - The distributing epochs are the epochs in which the state channels for the epochs are being settled and Indexers can claim their query fee rebates.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Your User Profile
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Profile Overview
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Subgraphs Tab
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Indexing Tab
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+This section will also include details about your net Indexer rewards and net query fees. You’ll see the following metrics:
+
+- Delegated Stake - the stake from Delegators that can be allocated by you but cannot be slashed
+- Total Query Fees - the total fees that users have paid for queries served by you over time
+- Indexer Rewards - the total amount of Indexer rewards you have received, in GRT
+- Fee Cut - the % of query fee rebates that you will keep when you split with Delegators
+- Rewards Cut - the % of Indexer rewards that you will keep when splitting with Delegators
+- Owned - your deposited stake, which could be slashed for malicious or incorrect behavior
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Delegating Tab
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+In the first half of the page, you can see your delegation chart, as well as the rewards-only chart. To the left, you can see the KPIs that reflect your current delegation metrics.
+
+The Delegator metrics you’ll see here in this tab include:
+
+- Total delegation rewards
+- Total unrealized rewards
+- Total realized rewards
+
+In the second half of the page, you have the delegations table. Here you can see the Indexers that you delegated towards, as well as their details (such as rewards cuts, cooldown, etc).
+
+With the buttons on the right side of the table, you can manage your delegation - delegate more, undelegate, or withdraw your delegation after the thawing period.
+
+Keep in mind that this chart is horizontally scrollable, so if you scroll all the way to the right, you can also see the status of your delegation (delegating, undelegating, withdrawable).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Curating Tab
+
+In the Curation tab, you’ll find all the subgraphs you’re signaling on (thus enabling you to receive query fees). Signaling allows Curators to highlight to Indexers which subgraphs are valuable and trustworthy, thus signaling that they need to be indexed on.
+
+Within this tab, you’ll find an overview of:
+
+- All the subgraphs you're curating on with signal details
+- Share totals per subgraph
+- Query rewards per subgraph
+- Updated at date details
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Your Profile Settings
+
+Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
+
+- Operators take limited actions in the protocol on the Indexer's behalf, such as opening and closing allocations. Operators are typically other Ethereum addresses, separate from their staking wallet, with gated access to the network that Indexers can personally set
+- Delegation parameters allow you to control the distribution of GRT between you and your Delegators.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From d33376343e9cd85c4855fdae6bb2bf9ffcc6db94 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:56 -0500
Subject: [PATCH 2028/3820] New translations explorer.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/explorer.mdx

diff --git a/website/pages/zh/subgraphs/explorer.mdx b/website/pages/zh/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..6cfc5fc25fe9
--- /dev/null
+++ b/website/pages/zh/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph 浏览器
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## 子图
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- 子图上的信号/非信号
+- 查看详细信息，例如图表、当前部署 ID 和其他元数据
+- 切换版本以探索子图的历史迭代
+- 通过 GraphQL 查询子图
+- 在面板上测试子图
+- 查看在某个子图上建立索引的索引人
+- 子图统计信息（分配、策展人等）
+- 查看发布子图的实体
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## 参与者
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. 索引人
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- 最大委托容量 - 索引人可以有效接受的最大委托份额数量。 超出的委托权益不能用于分配或奖励计算。
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- 索引人奖励 - 这是索引者及其委托者在所有时间获得的总索引人奖励。 索引人奖励通过 GRT 发行支付。
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. 策展人
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- 策展人开始策展的日期
+- 已存入的 GRT 数量
+- 策展人拥有的股份数量
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. 委托人
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- 委托人委托给的索引人数量
+- 委托人的原始委托
+- 协议中已经产生但没有提现的奖励
+- 从协议中提取的已实现奖励
+- 目前在协议中的 GRT 总量
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## 网络
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### 概述
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- 当前网络总份额
+- 索引人和他们的委托人之间的份额分配
+- 自网络成立以来的总供应量、铸造和消耗的 GRT
+- 自协议成立以来的总索引奖励
+- 协议参数，例如管理奖励、通货膨胀率等
+- 当前时期奖励和费用
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### 时期
+
+在时期部分，您可以在每个时期的基础上分析指标，例如：
+
+- 时期开始或结束区块
+- 在特定时期产生的查询费用和索引奖励
+- 时期状态，指的是查询费用的收取和分配，可以有不同的状态：
+  - 活跃时期是索引人目前正在分配权益并收取查询费用的时期
+  - 稳定时期是状态通道正在稳定的时期。 这意味着如果消费者对他们提出争议，索引人将受到严厉惩罚。
+  - 分发时期是时期的状态通道正在结算的时期，索引人可以要求他们的查询费用回扣。
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## 您的用户资料
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### 个人资料概览
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### 子图标签
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### 索引标签
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+本节还将包括有关您的净索引人奖励和净查询费用的详细信息。 您将看到以下指标：
+
+- 已委托份额 - 委托人的份额，您可以分配但不能被削减
+- 总查询费用 - 用户在一段时间内为您提供的查询支付的总费用
+- 索引人奖励- 您收到的索引人奖励总额，以 GRT 为单位
+- 费用削减 - 当您与委托人拆分时，您将保留的查询费用回扣百分比
+- 奖励削减 - 与委托人拆分时您将保留的索引人奖励的百分比
+- 已拥有 - 您存入的股份，可能会因恶意或不正确的行为而被削减
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### 委托标签
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+在页面的前半部分，您可以看到您的委托图表，以及仅奖励图表。 在左侧，您可以看到反映您当前委托指标的 KPI。
+
+您将在此选项卡中看到的委托人指标包括：
+
+- 总委托奖励
+- 未实现的总奖励
+- 已实现的总奖励
+
+在页面的后半部分，您将看到委托标签。 在这里，您可以看到您委托给的索引人，以及它们的详细信息（例如奖励削减、冷却时间等）。
+
+通过表格右侧的按钮，你可以管理你的委托--更多的委托，取消委托，或在解冻期后撤回你的委托。
+
+请记住，此图表是可水平滚动的，因此如果您一直向右滚动，您还可以看到您的授权状态（委派、取消委派、可撤回）。
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### 策展标签
+
+在策展选项卡中，您将找到您正在发送信号的所有子图（从而使您能够接收查询费用）。 信号允许策展人向索引人突出显示哪些子图有价值和值得信赖，从而表明它们需要被索引。
+
+在此选项卡中，您将找到以下内容的概述：
+
+- 您正在管理的所有带有信号细节的子图
+- 每个子图的共享总数
+- 查询每个子图的奖励
+- 更新日期详情
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## 设置您的个人资料
+
+在您的用户配置文件中，您将能够管理您的个人配置文件详细信息（例如设置 ENS 名称）。 如果您是 索引人，则可以轻松访问更多设置。 在您的用户配置文件中，您将能够设置您的委托参数和操作员。
+
+- 操作员代表索引人在协议中采取有限的操作，例如打开和关闭分配。 操作员通常是其他以太坊地址，与他们的抵押钱包分开，可以访问索引人可以亲自设置的网络。
+- 委托参数允许您控制 GRT 在您和您的委托人之间的分配。
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 2ebc46de2fa5545b3734acf893d7c0a4bfb17078 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:57 -0500
Subject: [PATCH 2029/3820] New translations explorer.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/explorer.mdx

diff --git a/website/pages/ur/subgraphs/explorer.mdx b/website/pages/ur/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..ceadc154655b
--- /dev/null
+++ b/website/pages/ur/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: گراف ایکسپلورر
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## سب گراف
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- سب گرافس پر سگنل/غیر سگنل
+- مزید تفصیلات دیکھیں جیسے چارٹس، موجودہ تعیناتی ID، اور دیگر میٹا ڈیٹا
+- سب گراف کی ماضی کی تکرار کو دریافت کرنے کے لیے ورژنز کو تبدیل کریں
+- GraphQL کے ذریعے سب گرافس سے کیوری کریں
+- پلے گراؤنڈ میں سب گراف کو جانچیں
+- انڈیکسرز دیکھیں جو کسی خاص سب گراف پر انڈیکس کر رہے ہیں
+- سب گراف کے اعدادوشمار (مختصات، کیوریٹرز، وغیرہ)
+- اس ہستی کو دیکھیں جس نے سب گراف کوشائع کیا
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## امیدوار
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### انڈیکسرز
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- زیادہ سے زیاد ڈیلیلگیشن صلاحیت - ڈیلیلگیٹڈ حصص کی زیادہ سے زیادہ مقدار کو انڈیکسر نتیجہ خیز طور پر قبول کر سکتا ہے۔ ایک اضافی حصص کو مختص کرنے یا انعامات کے حساب کتاب کے لیے استعمال نہیں کیا جا سکتا.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- انڈیکسرز کے انعامات - یہ انڈیکسر اور ان کے ڈیلیگیٹرز کی طرف سے ہر وقت کمائے گئے کل انڈیکسر انعامات ہیں۔ انڈیکسر انعامات GRT کے اجراء کے ذریعے ادا کیے جاتے ہیں.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### کیوریٹرز
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- جس تاریخ کیوریٹر نے کیوریٹنگ شروع کی
+- GRT کا نمبر جو جمع کیا گیا تھا
+- ایک کیوریٹر کے حصص کی تعداد
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### ڈیلیگیٹرز
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- انڈیکسرز کی تعداد جن کی طرف ایک ڈیلیگیٹر ڈیلیٹ کر رہا ہے
+- ایک ڈیلیگیٹر کی حقیقی ڈیلیگیشن
+- وہ انعامات جو انہوں نے جمع کر لیے ہیں لیکن پروٹوکول سے دستبردار نہیں ہوئے ہیں
+- وہ انعامات جو انہوں نے پروٹوکول سے واپس لے لیے
+- پروٹوکول میں ان کے پاس موجود GRT کی کل رقم
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## نیٹ ورک
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### جائزہ
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- موجودہ کل نیٹ ورک کا حصہ
+- انڈیکسرز اور ان کے ڈیلیگیٹرز کے درمیان حصص کی تقسیم
+- نیٹ ورک کے آغاز کے بعد سے کل سپلائی، ٹکسال، اور جلائی گئی GRT
+- پروٹوکول کے آغاز کے بعد سے کل ایڈیکسنگ کے انعامات
+- پروٹوکول کے پیرامیٹرز جیسے کیوریشن انعام، افراط زر کی شرح، اور مزید
+- موجودہ دور کے انعامات اور فیس
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### ایپوکس
+
+ایپوکس سیکشن میں، آپ فی اپوچ کی بنیاد پر تجزیہ کر سکتے ہیں، میٹرکس جیسے:
+
+- ایپوک آغاز یا اینڈ بلاک
+- ایک مخصوص ایپوک کے دوران جمع کردہ کیوری کی فیس اور انڈیکسنگ انعامات
+- ایپوک کی حیثیت، جس سے مراد کیوری فیس کی وصولی اور تقسیم ہے اور اس کی مختلف حالتیں ہوسکتی ہیں:
+  - فعال ایپوک وہ ہے جس میں انڈیکسرز فی الحال حصص مختص کر رہے ہیں اور کیوری کی فیس جمع کر رہے ہیں
+  - طے پانے والے اپوچس وہ ہیں جن میں ریاستی چینلز آباد ہو رہے ہیں۔ اس کا مطلب یہ ہے کہ اگر صارفین ان کے خلاف تنازعات کھولتے ہیں تو انڈیکسرز کو کم کیا جا سکتا ہے.
+  - تقسیم کرنے والے اپوچس وہ ایپوکس ہیں جن میں ایپوکس کے لیے ریاستی چینلز طے کیے جا رہے ہیں اور انڈیکسرز اپنی کیوری کی فیس میں چھوٹ کا دعویٰ کر سکتے ہیں.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## آپ کا صارف پروفائل
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### پروفائل کا جائزہ
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### سب گرافس ٹیب
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### انڈیکسنگ ٹیب
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+اس حصے میں آپ کے نیٹ انڈیکسر انعامات اور نیٹ استفسار کی فیس کے بارے میں تفصیلات بھی شامل ہوں گی۔ آپ کو درج ذیل میٹرکس نظر آئیں گے:
+
+- ڈیلیگیٹڈ اسٹیک - ڈیلیگیٹرز کی طرف سے وہ داؤ جو آپ کے ذریعہ مختص کیا جاسکتا ہے لیکن اسے کم نہیں کیا جاسکتا
+- کل کیوری کی فیس - وہ کل فیس جو صارفین نے وقت کے ساتھ آپ کے ذریعہ پیش کردہ کیوریز کے لیے ادا کی ہیں
+- انڈیکسر انعامات - GRT میں آپ کو موصول ہونے والے انڈیکسر انعامات کی کل رقم
+- فیس کٹ - کیوری کی فیس کی چھوٹ کا % جو آپ ڈیلیگیٹرز کے ساتھ الگ ہونے پر رکھیں گے
+- ریوارڈز کٹ - انڈیکسر انعامات کا % جو آپ ڈیلیگیٹرز کے ساتھ تقسیم کرتے وقت رکھیں گے
+- ملکیت - آپ کا جمع کردہ حصہ، جو بدنیتی پر مبنی یا غلط رویے کی وجہ سے کم کیا جا سکتا ہے
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### ڈیلگیٹنگ ٹیب
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+صفحہ کے پہلے نصف میں، آپ اپنے ڈیلیگیشن چارٹ کے ساتھ ساتھ صرف انعامات کا چارٹ دیکھ سکتے ہیں، بائیں طرف، آپ KPIs دیکھ سکتے ہیں جو آپ کی موجودہ ڈیلیگیشن میٹرکس کی عکاسی کرتے ہیں.
+
+ڈیلیگیٹر میٹرکس جو آپ یہاں اس ٹیب میں دیکھیں گے ان میں شامل ہیں:
+
+- کل ڈیلیگیشن انعامات
+- کل غیر حقیقی انعامات
+- کل حقیقی انعامات
+
+صفحہ کے دوسرے حصے میں، آپ کے پاس ڈیلیگیشنز ٹیبل ہے. یہاں آپ انڈیکسرز کو دیکھ سکتے ہیں جنہیں آپ نے ڈیلیگیٹ کیا ہے۔ نیز ان کی تفصیلات (جیسے انعامات میں کمی، کولڈاؤن وغیرہ).
+
+ٹیبل کی دائیں جانب بٹنوں کے ساتھ، آپ اپنی ڈیلیگیشن کا انتظام کرسکتے ہیں - مزید ڈیلیگیٹ کریں، عن ڈیلیگیٹ، یہ پگھلنے کے خطرے کے بعد اپنی ڈیلیگیشن کو واپس لے لیں.
+
+ذہن میں رکھیں کہ یہ چارٹ افقی طور پر سکرول کرنے کے قابل ہے، لہذا اگر آپ پورے راستے سے دائیں طرف سکرول کرتے ہیں، تو آپ اپنی ڈیلیگیشن کی حیثیت بھی دیکھ سکتے ہیں ( ڈیلیگیٹنگ، غیر ڈیلیگیٹنگ، واپس لینے کے قابل).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### کیوریٹنگ ٹیب
+
+کیوریشن ٹیب میں، آپ کو وہ تمام سب گراف مل جائیں گے جن پر آپ سگنل دے رہے ہیں (اس طرح آپ کو کیوری کی فیس وصول کرنے کے قابل بناتے ہیں). سگنلنگ کیوریٹرز کو انڈیکسرز کو نمایاں کرنے کی اجازت دیتا ہے کے کون سے سب گرافس قابل قدر اور قابل اعتماد ہیں، اس طرح یہ اشارہ کرتا ہے کہ انہیں انڈیکس کرنے کی ضرورت ہے.
+
+اس ٹیب کے اندر، آپ کو ایک جائزہ ملے گا:
+
+- سگنل کی تفصیلات کے ساتھ آپ جن سب گرافس کو کیورٹنگ کر رہے ہیں
+- فی سب گراف کا مجموعی اشتراک کریں
+- استفسار کے انعامات فی سب گراف
+- تاریخ کی تفصیلات پر اپ ڈیٹ کیا گیا
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## آپ کے پروفائل کی ترتیبات
+
+اپنے صارف پروفائل کے اندر، آپ اپنی ذاتی پروفائل کی تفصیلات کا نظم کر سکیں گے (جیسے ENS نام ترتیب دینا)۔ اگر آپ ایک انڈیکسر ہیں، تو آپ کو اپنی انگلیوں پر ترتیبات تک اور بھی زیادہ رسائی حاصل ہے۔ اپنے صارف پروفائل میں، آپ اپنے ڈیلیگیشن پیرامیٹرز اور آپریٹرز کو ترتیب دے سکیں گے.
+
+- آپریٹرز انڈیکسر کی جانب سے پروٹوکول میں محدود کاڑوائیاں کرتے ہیں، جیسے کہ مختص کھولنا اور بند کرنا. آپریٹرز عام طور پر دوسرے ایتھریم ایڈریس ہوتے ہیں، جو ان کے اسٹیکنگ والیٹ سے الگ ہوتے ہیں،نیٹ ورک تک رسائی کے ساتھ جسے انڈیکسرز ذاتی طور پر سیٹ کر سکتے ہیں
+- ڈیلیگیشن پیرامیٹرز آپ کو اپنے اور آپ کے ڈیلیگیٹرز کے درمیان GRT کی تقسیم کو کنٹرول کرنے کی اجازت دیتے ہیں.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 3ae8469e7e87e9e0d0213b46ac41a974b2756d81 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:58 -0500
Subject: [PATCH 2030/3820] New translations explorer.mdx (Vietnamese)

---
 website/pages/vi/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/explorer.mdx

diff --git a/website/pages/vi/subgraphs/explorer.mdx b/website/pages/vi/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..51f1856ae915
--- /dev/null
+++ b/website/pages/vi/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Trình khám phá Graph
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraphs
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Báo hiệu / Hủy báo hiệu trên subgraph
+- Xem thêm chi tiết như biểu đồ, ID triển khai hiện tại và siêu dữ liệu khác
+- Chuyển đổi giữa các phiên bản để khám phá các lần bản trước đây của subgraph
+- Truy vấn subgraph qua GraphQL
+- Thử subgraph trong playground
+- Xem các Indexers đang lập chỉ mục trên một subgraph nhất định
+- Thống kê Subgraph (phân bổ, Curators, v.v.)
+- Xem pháp nhân đã xuất bản subgraph
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Những người tham gia
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexers
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity - the maximum amount of delegated stake the Indexer can productively accept. An excess delegated stake cannot be used for allocations or rewards calculations.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Thưởng Indexer - đây là tổng phần thưởng indexer mà Indexer và các Delegator của họ kiếm được cho đến hiện tại. Phần thưởng Indexer được trả thông qua việc phát hành GRT.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curators
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- Ngày Curator bắt đầu curate
+- Số GRT đã được nạp
+- Số cổ phần một Curator sở hữu
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegators
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- Số lượng Indexers mà một Delegator đang ủy quyền cho
+- Ủy quyền ban đầu của Delegator
+- Phần thưởng họ đã tích lũy nhưng chưa rút khỏi giao thức
+- Phần thưởng đã ghi nhận ra mà họ rút khỏi giao thức
+- Tổng lượng GRT mà họ hiện có trong giao thức
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Mạng lưới
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Tổng quan
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- Tổng stake mạng hiện tại
+- Phần chia stake giữa Indexer và các Delegator của họ
+- Tổng cung GRT, lượng được đúc và đốt kể từ khi mạng lưới thành lập
+- Tổng phần thưởng Indexing kể từ khi bắt đầu giao thức
+- Các thông số giao thức như phần thưởng curation, tỷ lệ lạm phát,...
+- Phần thưởng và phí của epoch hiện tại
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epochs
+
+In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
+
+- Khối bắt đầu hoặc kết thúc của Epoch
+- Phí truy vấn được tạo và phần thưởng indexing được thu thập trong một epoch cụ thể
+- Trạng thái Epoch, đề cập đến việc thu và phân phối phí truy vấn và có thể có các trạng thái khác nhau:
+  - Epoch đang hoạt động là epoch mà Indexer hiện đang phân bổ cổ phần và thu phí truy vấn
+  - Epoch đang giải quyết là những epoch mà các kênh trạng thái đang được giải quyết. Điều này có nghĩa là Indexers có thể bị phạt cắt giảm nếu người tiêu dùng công khai tranh chấp chống lại họ.
+  - Epoch đang phân phối là epoch trong đó các kênh trạng thái cho các epoch đang được giải quyết và Indexer có thể yêu cầu hoàn phí truy vấn của họ.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Hồ sơ Người dùng của bạn
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Tổng quan Hồ sơ
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Tab Subgraphs
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Tab Indexing
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+Phần này cũng sẽ bao gồm thông tin chi tiết về phần thưởng Indexer ròng của bạn và phí truy vấn ròng. Bạn sẽ thấy các số liệu sau:
+
+- Stake được ủy quyền - phần stake từ Delegator có thể được bạn phân bổ nhưng không thể bị phạt cắt giảm (slashed)
+- Total Query Fees - the total fees that users have paid for queries served by you over time
+- Phần thưởng Indexer - tổng số phần thưởng Indexer bạn đã nhận được, tính bằng GRT
+- Phần Cắt Phí - lượng % hoàn phí phí truy vấn mà bạn sẽ giữ lại khi ăn chia với Delegator
+- Phần Cắt Thưởng - lượng % phần thưởng Indexer mà bạn sẽ giữ lại khi ăn chia với Delegator
+- Được sở hữu - số stake đã nạp của bạn, có thể bị phạt cắt giảm (slashed) vì hành vi độc hại hoặc không chính xác
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Tab Delegating
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+Trong nửa đầu của trang, bạn có thể thấy biểu đồ ủy quyền của mình, cũng như biểu đồ chỉ có phần thưởng. Ở bên trái, bạn có thể thấy các KPI phản ánh các chỉ số ủy quyền hiện tại của bạn.
+
+Các chỉ số Delegator mà bạn sẽ thấy ở đây trong tab này bao gồm:
+
+- Total delegation rewards
+- Tổng số phần thưởng chưa ghi nhận
+- Tổng số phần thưởng đã ghi được
+
+Trong nửa sau của trang, bạn có bảng ủy quyền. Tại đây, bạn có thể thấy các Indexer mà bạn đã ủy quyền, cũng như thông tin chi tiết của chúng (chẳng hạn như phần cắt thưởng, thời gian chờ, v.v.).
+
+Với các nút ở bên phải của bảng, bạn có thể quản lý ủy quyền của mình - ủy quyền nhiều hơn, hủy bỏ hoặc rút lại ủy quyền của bạn sau khoảng thời gian rã đông (thawing period).
+
+Lưu ý rằng biểu đồ này có thể cuộn theo chiều ngang, vì vậy nếu bạn cuộn hết cỡ sang bên phải, bạn cũng có thể thấy trạng thái ủy quyền của mình (ủy quyền, hủy ủy quyền, có thể rút lại).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Tab Curating
+
+Trong tab Curation, bạn sẽ tìm thấy tất cả các subgraph mà bạn đang báo hiệu (do đó cho phép bạn nhận phí truy vấn). Báo hiệu cho phép Curator đánh dấu cho Indexer biết những subgraph nào có giá trị và đáng tin cậy, do đó báo hiệu rằng chúng cần được lập chỉ mục.
+
+Trong tab này, bạn sẽ tìm thấy tổng quan về:
+
+- Tất cả các subgraph bạn đang quản lý với các chi tiết về tín hiệu
+- Tổng cổ phần trên mỗi subgraph
+- Phần thưởng truy vấn cho mỗi subgraph
+- Chi tiết ngày được cập nhật
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Cài đặt Hồ sơ của bạn
+
+Trong hồ sơ người dùng của mình, bạn sẽ có thể quản lý chi tiết hồ sơ cá nhân của mình (như thiết lập tên ENS). Nếu bạn là Indexer, bạn thậm chí có nhiều quyền truy cập hơn vào các cài đặt trong tầm tay của mình. Trong hồ sơ người dùng của mình, bạn sẽ có thể thiết lập các tham số ủy quyền và operator của mình.
+
+- Operators (Người vận hành) thực hiện các hành động được hạn chế trong giao thức thay mặt cho Indexer, chẳng hạn như mở và đóng phân bổ. Operators thường là các địa chỉ Ethereum khác, tách biệt với ví đặt staking của họ, với quyền truy cập được kiểm soát vào mạng mà Indexer có thể cài đặt cá nhân
+- Tham số ủy quyền cho phép bạn kiểm soát việc phân phối GRT giữa bạn và các Delegator của bạn.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 15c97a93fad454adba0c95f5370d003dac725d56 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:20:59 -0500
Subject: [PATCH 2031/3820] New translations explorer.mdx (Marathi)

---
 website/pages/mr/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/explorer.mdx

diff --git a/website/pages/mr/subgraphs/explorer.mdx b/website/pages/mr/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..2441a410b179
--- /dev/null
+++ b/website/pages/mr/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraphs
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Signal/Un-signal on subgraphs
+- चार्ट, वर्तमान उपयोजन आयडी आणि इतर मेटाडेटा यासारखे अधिक तपशील पहा
+- Switch versions to explore past iterations of the subgraph
+- GraphQL द्वारे सबग्राफ क्वेरी करा
+- Test subgraphs in the playground
+- View the Indexers that are indexing on a certain subgraph
+- Subgraph stats (allocations, Curators, etc)
+- View the entity who published the subgraph
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Participants
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexers
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- कमाल डेलिगेशन क्षमता - इंडेक्सर उत्पादकपणे स्वीकारू शकणारी जास्तीत जास्त डेलिगेटेड स्टेक. वाटप किंवा बक्षिसे गणनेसाठी जास्तीचा वाटप केला जाऊ शकत नाही.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- इंडेक्सर रिवॉर्ड्स - हे इंडेक्सर आणि त्यांच्या प्रतिनिधींनी सर्वकाळात मिळवलेले एकूण इंडेक्सर रिवॉर्ड्स आहेत. इंडेक्सर रिवॉर्ड्स GRT जारी करून दिले जातात.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curators
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- The date the Curator started curating
+- The number of GRT that was deposited
+- The number of shares a Curator owns
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegators
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- The number of Indexers a Delegator is delegating towards
+- A Delegator’s original delegation
+- The rewards they have accumulated but have not withdrawn from the protocol
+- The realized rewards they withdrew from the protocol
+- Total amount of GRT they have currently in the protocol
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Network
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### सविश्लेषण
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- The current total network stake
+- The stake split between the Indexers and their Delegators
+- Total supply, minted, and burned GRT since the network inception
+- Total Indexing rewards since the inception of the protocol
+- Protocol parameters such as curation reward, inflation rate, and more
+- Current epoch rewards and fees
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epochs
+
+In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
+
+- Epoch start or end block
+- Query fees generated and indexing rewards collected during a specific epoch
+- Epoch status, which refers to the query fee collection and distribution and can have different states:
+  - सक्रिय युग असा आहे ज्यामध्ये इंडेक्सर्स सध्या स्टेक वाटप करत आहेत आणि क्वेरी फी गोळा करत आहेत
+  - सेटलिंग युग हे असे आहेत ज्यामध्ये राज्य वाहिन्या सेटल होत आहेत. याचा अर्थ असा की जर ग्राहकांनी त्यांच्या विरुद्ध विवाद उघडले तर निर्देशांक कमी केले जातील.
+  - वितरण युग हे असे युग आहेत ज्यामध्ये युगांसाठी राज्य चॅनेल सेटल केले जात आहेत आणि इंडेक्सर्स त्यांच्या क्वेरी फी सवलतीचा दावा करू शकतात.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Your User Profile
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Profile Overview
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Subgraphs Tab
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Indexing Tab
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+या विभागात तुमच्या निव्वळ इंडेक्सर रिवॉर्ड्स आणि नेट क्वेरी फीबद्दल तपशील देखील समाविष्ट असतील. तुम्हाला खालील मेट्रिक्स दिसतील:
+
+- Delegated Stake - the stake from Delegators that can be allocated by you but cannot be slashed
+- एकूण क्वेरी शुल्क - वापरकर्त्यांनी वेळोवेळी तुमच्याद्वारे दिलेल्या क्वेरींसाठी भरलेले एकूण शुल्क
+- Indexer Rewards - the total amount of Indexer rewards you have received, in GRT
+- फी कट - तुम्ही डेलिगेटर्ससह विभक्त झाल्यावर तुम्ही ठेवू शकणार्‍या क्वेरी फी सवलतींचा %
+- Rewards Cut - the % of Indexer rewards that you will keep when splitting with Delegators
+- मालकीचा - तुमचा जमा केलेला हिस्सा, जो दुर्भावनापूर्ण किंवा चुकीच्या वर्तनासाठी कमी केला जाऊ शकतो
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Delegating Tab
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+पृष्‍ठाच्या पूर्वार्धात, तुम्‍ही तुमच्‍या डेलिगेशन चार्ट तसेच रिवॉर्ड-ओन्ली चार्ट पाहू शकता. डावीकडे, तुम्ही KPI पाहू शकता जे तुमचे वर्तमान प्रतिनिधीत्व मेट्रिक्स दर्शवतात.
+
+या टॅबमध्ये तुम्हाला येथे दिसणार्‍या डेलिगेटर मेट्रिक्समध्ये हे समाविष्ट आहे:
+
+- एकूण प्रतिनिधीत्व बक्षिसे
+- Total unrealized rewards
+- Total realized rewards
+
+पृष्ठाच्या दुसऱ्या सहामाहीत, आपल्याकडे प्रतिनिधी टेबल आहे. येथे तुम्ही ज्या निर्देशांकांना तुम्ही नियुक्त केले आहे, तसेच त्यांचे तपशील (जसे की रिवॉर्ड कट, कूलडाउन इ.) पाहू शकता.
+
+टेबलच्या उजव्या बाजूला असलेल्या बटणांच्या सहाय्याने, तुम्ही तुमचे प्रतिनिधीमंडळ व्यवस्थापित करू शकता - वितळण्याच्या कालावधीनंतर तुमचे प्रतिनिधीमंडळ अधिक प्रतिनिधी, अस्वीकृत किंवा मागे घेऊ शकता.
+
+लक्षात ठेवा की हा चार्ट क्षैतिजरित्या स्क्रोल करण्यायोग्य आहे, म्हणून तुम्ही उजवीकडे स्क्रोल केल्यास, तुम्ही तुमच्या प्रतिनिधीची स्थिती देखील पाहू शकता (प्रतिनिधी, अस्वीकृत, मागे घेण्यायोग्य).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Curating Tab
+
+क्युरेशन टॅबमध्ये, तुम्ही सिग्नल करत असलेले सर्व सबग्राफ तुम्हाला सापडतील (अशा प्रकारे तुम्हाला क्वेरी शुल्क प्राप्त करण्यास सक्षम करते). सिग्नलिंगमुळे क्युरेटर्स इंडेक्सर्सना कोणते सबग्राफ मौल्यवान आणि विश्वासार्ह आहेत हे ठळकपणे दाखवू देते, अशा प्रकारे ते इंडेक्स केले जाणे आवश्यक असल्याचे संकेत देते.
+
+या टॅबमध्ये, तुम्हाला याचे विहंगावलोकन मिळेल:
+
+- All the subgraphs you're curating on with signal details
+- Share totals per subgraph
+- Query rewards per subgraph
+- Updated at date details
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Your Profile Settings
+
+तुमच्या वापरकर्ता प्रोफाइलमध्ये, तुम्ही तुमचे वैयक्तिक प्रोफाइल तपशील व्यवस्थापित करण्यास सक्षम असाल (जसे की ENS नाव सेट करणे). तुम्ही इंडेक्सर असल्यास, तुमच्या बोटांच्या टोकावर असलेल्या सेटिंग्जमध्ये तुम्हाला आणखी प्रवेश आहे. तुमच्या वापरकर्ता प्रोफाइलमध्ये, तुम्ही तुमचे डेलिगेशन पॅरामीटर्स आणि ऑपरेटर सेट करू शकाल.
+
+- ऑपरेटर इंडेक्सरच्या वतीने प्रोटोकॉलमध्ये मर्यादित कृती करतात, जसे की वाटप उघडणे आणि बंद करणे. ऑपरेटर हे सामान्यत: इतर इथरियम पत्ते असतात, जे त्यांच्या स्टॅकिंग वॉलेटपासून वेगळे असतात, इंडेक्सर्स वैयक्तिकरित्या सेट करू शकणार्‍या नेटवर्कवर गेट केलेला प्रवेश असतो
+- Delegation parameters allow you to control the distribution of GRT between you and your Delegators.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From ce20e8674dceba94bf4516bd568f5d4269c0ee25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:00 -0500
Subject: [PATCH 2032/3820] New translations explorer.mdx (Hindi)

---
 website/pages/hi/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/explorer.mdx

diff --git a/website/pages/hi/subgraphs/explorer.mdx b/website/pages/hi/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..76bf5d58cf7a
--- /dev/null
+++ b/website/pages/hi/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+The Graph Explorer के बारे में जानें और सबग्राफ और नेटवर्क डेटा की दुनिया तक पहुंचें।
+
+Graph Explorer कई भागों में बंटा हुआ है जहां आप अन्य डेवलपर्स, dapp डेवलपर्स, Curators, Indexers और Delegators के साथ बातचीत कर सकते हैं।
+
+## वीडियो गाइड
+
+Graph Explorer का सामान्य अवलोकन करने के लिए, नीचे दिए गए वीडियो को देखें:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## सबग्राफ
+
+जैसे ही आप Subgraph Studio में अपना subgraph डिप्लॉय और पब्लिश कर लें, नेविगेशन बार के शीर्ष पर स्थित "subgraphs tab” पर क्लिक करें ताकि आप निम्नलिखित तक पहुंच सकें:
+
+- आपके अपने तैयार किए गए subgraphs
+- दूसरों द्वारा प्रकाशित subgraphs
+- आपके पास जिस विशेष subgraph की आवश्यकता है (निर्माण की तारीख, सिग्नल राशि, या नाम के आधार पर)।
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+जब आप एक subgraph पर क्लिक करते हैं, तो आप निम्नलिखित कर सकेंगे:
+
+- प्लेग्राउंड में परीक्षण प्रश्न करें और सूचनापूर्ण निर्णय लेने के लिए नेटवर्क विवरण का उपयोग करें।
+- अपने स्वयं के subgraph या दूसरों के subgraphs पर GRT का सिग्नल दें ताकि indexers इसकी महत्ता और गुणवत्ता के बारे में जागरूक हो सकें।
+- यह महत्वपूर्ण है क्योंकि एक subgraph पर संकेत देना इसे अनुक्रमित करने के लिए प्रोत्साहित करता है, जिसका अर्थ है कि यह अंततः नेटवर्क पर क्वेरीज़ को सेवा देने के लिए सामने आएगा।
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+हर subgraph के समर्पित पृष्ठ पर, आप निम्नलिखित कार्य कर सकते हैं:
+
+- सबग्राफ पर सिग्नल/अन-सिग्नल
+- चार्ट, वर्तमान परिनियोजन आईडी और अन्य मेटाडेटा जैसे अधिक विवरण देखें
+- सबग्राफ के पिछले पुनरावृत्तियों का पता लगाने के लिए संस्करणों को स्विच करें
+- ग्राफ़क्यूएल के माध्यम से क्वेरी सबग्राफ
+- खेल के मैदान में टेस्ट सबग्राफ
+- उन अनुक्रमणकों को देखें जो एक निश्चित सबग्राफ पर अनुक्रमणित कर रहे हैं
+- सबग्राफ आँकड़े (आवंटन, क्यूरेटर, आदि)
+- उस इकाई को देखें जिसने सबग्राफ प्रकाशित किया था
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## प्रतिभागियों
+
+यह अनुभाग सभी 'participants' का एक दृष्टिकोण प्रदान करता है, जिसमें नेटवर्क में भाग लेने वाले सभी लोग शामिल हैं, जैसे Indexers, Delegators और Curators।
+
+### 1. इंडेक्सर्स
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexer प्रोटोकॉल की रीढ़ हैं। वे सबग्राफ पर स्टेक करते हैं, उन्हें इंडेक्स करते हैं, और उन सभी को प्रश्न प्रदान करते हैं जो सबग्राफ का उपभोग करते हैं।
+
+Indexers तालिका में, आप Indexers के डेलीगेशन पैरामीटर, उनकी स्टेक, प्रत्येक subgraph के लिए उन्होंने कितना स्टेक किया है, और उन्होंने प्रश्न शुल्क और इंडेक्सिंग पुरस्कारों से कितना राजस्व प्राप्त किया है, देख सकते हैं।
+
+**Specifics**
+
+- क्वेरी फ़ी कट - वह % जो क्वेरी फ़ी रिबेट्स का हिस्सा है जो Indexer, Delegators के साथ बाँटते समय रखता है।
+- प्रभावी पुरस्कार कट - वह इंडेक्सिंग पुरस्कार कट जो डेलीगेशन पूल पर लागू होता है। यदि यह नकारात्मक है, तो इसका मतलब है कि इंडेक्सर अपने पुरस्कारों का एक हिस्सा दे रहा है। यदि यह सकारात्मक है, तो इसका मतलब है कि Indexer अपने कुछ पुरस्कार रख रहा है।
+- कूलडाउन शेष - वह समय जो उपरोक्त डेलीगेशन पैरामीटर को बदलने के लिए Indexer को बचा है। कूलडाउन अवधि वे होती हैं जो Indexers अपने डेलीगेशन पैरामीटर को अपडेट करते समय सेट करते हैं।
+- यह है Indexer का जमा किया गया हिस्सेदारी, जिसे दुष्ट या गलत व्यवहार के लिए काटा जा सकता है।
+- प्रतिनिधि - 'Delegators' से स्टेक जो 'Indexers' द्वारा आवंटित किया जा सकता है, लेकिन इसे स्लैश नहीं किया जा सकता।
+- आवंटित- वह स्टेक है जिसे Indexers उन subgraphs के लिए सक्रिय रूप से आवंटित कर रहे हैं जिन्हें वे इंडेक्स कर रहे हैं।
+- अवेलबल डेलीगेशन कैपेसिटी - वह मात्रा जो डेलीगेटेड स्टेक है, जो Indexers अभी भी प्राप्त कर सकते हैं इससे पहले कि वे ओवर-डेलीगेटेड हो जाएं।
+- अधिकतम प्रत्यायोजन क्षमता - प्रत्यायोजित हिस्सेदारी की अधिकतम राशि जिसे इंडेक्सर उत्पादक रूप से स्वीकार कर सकता है। आवंटन या पुरस्कार गणना के लिए एक अतिरिक्त प्रत्यायोजित हिस्सेदारी का उपयोग नहीं किया जा सकता है।
+- क्वेरी शुल्क - यह कुल शुल्क है जो अंतिम उपयोगकर्ताओं ने सभी समय में एक Indexer से क्वेरी के लिए भुगतान किया है।
+- इंडेक्सर रिवार्ड्स - यह इंडेक्सर और उनके प्रतिनिधियों द्वारा हर समय अर्जित किए गए कुल इंडेक्सर पुरस्कार हैं। इंडेक्सर पुरस्कार का भुगतान जीआरटी जारी करने के माध्यम से किया जाता है।
+
+Indexers दोनों क्वेरी फीस और इंडेक्सिंग पुरस्कार कमा सकते हैं। कार्यात्मक रूप से, यह तब होता है जब नेटवर्क प्रतिभागी GRT को एक Indexer को सौंपते हैं। इससे Indexers को उनके Indexer पैरामीटर के आधार पर क्वेरी फीस और पुरस्कार प्राप्त होते हैं।
+
+- इंडेक्सिंग पैरामीटर को टेबल के दाहिने ओर क्लिक करके या किसी इंडेक्सर के प्रोफ़ाइल में जाकर 'Delegate' बटन पर क्लिक करके सेट किया जा सकता है।
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. क्यूरेटर
+
+क्यूरेटर subgraphs का विश्लेषण करते हैं ताकि यह पहचान सकें कि कौन से subgraphs उच्चतम गुणवत्ता के हैं। एक बार जब एक क्यूरेटर एक संभावित उच्च गुणवत्ता वाले subgraph को खोज लेता है, तो वे इसके बॉन्डिंग कर्व पर सिग्नल देकर इसे क्यूरेट कर सकते हैं। ऐसा करके, क्यूरेटर इंडेक्सर्स को बताते हैं कि कौन से subgraphs उच्च गुणवत्ता के हैं और उन्हें इंडेक्स किया जाना चाहिए।
+
+- क्यूरेटर समुदाय के सदस्य, डेटा उपभोक्ता, या यहां तक कि अपने Subgraphs पर संकेत देने के लिए GRT टोकन को बॉन्डिंग कर्व में जमा करके अपने स्वयं के Subgraph पर संकेत देने वाले सबग्रह डेवलपर्स भी हो सकते हैं।
+  - GRT जमा करके, Curators एक subgraph के curation shares का निर्माण करते हैं। इसके परिणामस्वरूप, वे उस subgraph से उत्पन्न query fees का एक भाग अर्जित कर सकते हैं जिस पर उन्होंने संकेत दिया है।
+  - "Bonding curve" क्यूरेटर्स को सबसे उच्च गुणवत्ता वाले डेटा स्रोतों को क्यूरेट करने के लिए प्रोत्साहित करता है।
+
+यहां 'Curator' तालिका में नीचे दी गई जानकारी को देख सकते हैं:
+
+- क्यूरेटर द्वारा क्यूरेट करना शुरू करने की तारीख
+- जमा किए गए जीआरटी की संख्या
+- एक क्यूरेटर के शेयरों की संख्या
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. प्रतिनिधि
+
+The Graph Network की सुरक्षा और विकेंद्रीकरण को बनाए रखने में Delegators की महत्वपूर्ण भूमिका होती है। वे नेटवर्क में भाग लेते हैं 'delegating' (यानी, 'staking') करके और GRT tokens को एक या एक से अधिक Indexers को सौंपते हैं।
+
+- Indexers के बिना, Delegators को महत्वपूर्ण पुरस्कार और शुल्क कमाने की संभावना कम होती है। इसलिए, Indexers अपने 'indexing rewards' और 'query fees' का एक हिस्सा देकर Delegators को आकर्षित करते हैं।
+- डेलीगेटर्स विभिन्न कारकों के आधार पर इंडेक्सर्स का चयन करते हैं, जैसे कि पिछले प्रदर्शन, इंडेक्सिंग इनाम दरें, और क्वेरी शुल्क कट।
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+Delegators तालिका में आप समुदाय में सक्रिय Delegators और महत्वपूर्ण मैट्रिक्स देख सकते हैं:
+
+- एक डेलीगेटर कितने इंडेक्सर्स की ओर डेलिगेट कर रहा है
+- एक प्रतिनिधि का मूल प्रतिनिधिमंडल
+- उन्होंने जो पुरस्कार जमा किए हैं, लेकिन प्रोटोकॉल से वापस नहीं लिए हैं
+- एहसास हुआ पुरस्कार वे प्रोटोकॉल से वापस ले लिया
+- वर्तमान में उनके पास प्रोटोकॉल में जीआरटी की कुल राशि है
+- वे आखिरी बार 'delegated' की तारीख
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## नेटवर्क
+
+इस अनुभाग में, आप वैश्विक KPI देख सकते हैं और प्रति-युग आधार पर स्विच करने की क्षमता को देख सकते हैं और नेटवर्क मेट्रिक्स का अधिक विस्तार से विश्लेषण कर सकते हैं। ये विवरण आपको यह समझने में मदद करेंगे कि नेटवर्क समय के साथ कैसा प्रदर्शन कर रहा है।
+
+### अवलोकन
+
+ओवरव्यू सेक्शन में वर्तमान नेटवर्क मैट्रिक्स और समय के साथ कुछ संचयी मैट्रिक्स दोनों शामिल हैं:
+
+- वर्तमान कुल नेटवर्क हिस्सेदारी
+- इंडेक्सर्स और उनके प्रतिनिधियों के बीच हिस्सेदारी विभाजित हो गई
+- नेटवर्क की स्थापना के बाद से कुल आपूर्ति, खनन, और जला जीआरटी
+- प्रोटोकॉल की स्थापना के बाद से कुल अनुक्रमण पुरस्कार
+- प्रोटोकॉल पैरामीटर जैसे क्यूरेशन रिवॉर्ड, महंगाई दर और बहुत कुछ
+- वर्तमान युग पुरस्कार और शुल्क
+
+कुछ महत्वपूर्ण विवरण नोट करने के लिए:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### अवधियों को
+
+युग खंड में, आप प्रति युग के आधार पर विश्लेषण कर सकते हैं, जैसे मीट्रिक:
+
+- युग प्रारंभ या अंत ब्लॉक
+- एक विशिष्ट युग के दौरान एकत्र की गई क्वेरी फीस और इंडेक्सिंग पुरस्कार
+- एपोच स्थिति, जो क्वेरी शुल्क संग्रह और वितरण को संदर्भित करती है और इसके अलग-अलग राज्य हो सकते हैं:
+  - सक्रिय युग वह है जिसमें इंडेक्सर्स वर्तमान में हिस्सेदारी आवंटित कर रहे हैं और क्वेरी फीस जमा कर रहे हैं
+  - बसने वाले युग वे हैं जिनमें राज्य चैनलों को बसाया जा रहा है। इसका मतलब यह है कि अगर उपभोक्ता उनके खिलाफ विवाद खोलते हैं तो इंडेक्सर्स स्लैशिंग के अधीन हैं।
+  - वितरण युग ऐसे युग हैं जिनमें युगों के लिए राज्य चैनल तय किए जा रहे हैं और अनुक्रमणकर्ता अपनी क्वेरी शुल्क छूट का दावा कर सकते हैं।
+  - अंतिम चरण वे चरण हैं जिनमें Indexers द्वारा दावा करने के लिए कोई प्रश्न शुल्क छूट शेष नहीं है।
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## आपका उपयोगकर्ता प्रोफ़ाइल
+
+आपकी व्यक्तिगत प्रोफ़ाइल वह स्थान है जहां आप अपने नेटवर्क गतिविधि को देख सकते हैं, चाहे आपकी भूमिका नेटवर्क पर कुछ भी हो। आपका क्रिप्टो वॉलेट आपके उपयोगकर्ता प्रोफ़ाइल के रूप में कार्य करेगा, और उपयोगकर्ता डैशबोर्ड के साथ, आप निम्नलिखित टैब देख सकेंगे:
+
+### प्रोफ़ाइल अवलोकन
+
+इस खंड में, आप निम्नलिखित देख सकते हैं:
+
+- आपकी वर्तमान क्रियाओं में से कोई भी आपने किया है।
+- आपकी प्रोफ़ाइल जानकारी, विवरण, और वेबसाइट (यदि आपने एक जोड़ी है)।
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### सबग्राफ टैब
+
+सबग्राफ टैब में, आप अपने प्रकाशित सबग्राफ को देखेंगे।
+
+> यह उन subgraphs को शामिल नहीं करेगा जो परीक्षण उद्देश्यों के लिए CLI के साथ तैनात किए गए हैं। subgraphs तब ही दिखाई देंगे जब उन्हें विकेंद्रीकृत नेटवर्क पर प्रकाशित किया जाएगा।
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### अनुक्रमण टैब
+
+इंडेक्सिंग टैब में, आपको एक तालिका मिलेगी जिसमें सभी सक्रिय और ऐतिहासिक आवंटन सबग्राफ के प्रति हैं। आप चार्ट भी पाएंगे जहां आप एक Indexerके रूप में अपने पिछले प्रदर्शन को देख और विश्लेषण कर सकते हैं।
+
+इस खंड में आपके नेट इंडेक्सर रिवार्ड्स और नेट क्वेरी फीस के विवरण भी शामिल होंगे। आपको ये मेट्रिक दिखाई देंगे:
+
+- प्रत्यायोजित हिस्सेदारी - प्रतिनिधियों की हिस्सेदारी जो आपके द्वारा आवंटित की जा सकती है लेकिन कम नहीं की जा सकती
+- कुल प्रश्न शुल्क - कुल शुल्क जो उपयोगकर्ताओं ने समय के साथ आपके द्वारा की गई प्रश्नों के लिए भुगतान किया है
+- इंडेक्सर रिवार्ड्स - जीआरटी में आपको प्राप्त इंडेक्सर रिवार्ड्स की कुल राशि
+- शुल्क में कटौती - क्वेरी शुल्क का % छूट जो आप डेलीगेटर्स के साथ अलग होने पर रखेंगे
+- रिवार्ड्स कट - इंडेक्सर रिवार्ड्स का वह % जिसे आप डेलीगेटर्स के साथ विभाजित करते समय रखेंगे
+- स्वामित्व - यह इंडेक्सर की जमा हिस्सेदारी है, जिसे दुर्भावनापूर्ण या गलत व्यवहार के लिए घटाया जा सकता है
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### प्रतिनिधि टैब
+
+Delegator ,The Graph नेटवर्क के लिए महत्वपूर्ण हैं। उन्हें अपने ज्ञान का उपयोग करके एक इंडेक्सर का चयन करना चाहिए जो पुरस्कारों पर स्वस्थ रिटर्न प्रदान करेगा।
+
+डेलीगेटर्स टैब में, आप अपनी सक्रिय और ऐतिहासिक डेलीगेशंस का विवरण पा सकते हैं, साथ ही उन Indexers के मेट्रिक्स भी जिनकी ओर आपने डेलीगेट किया है।
+
+पृष्ठ के पहले भाग में, आप अपना प्रतिनिधिमंडल चार्ट और साथ ही केवल-पुरस्कार चार्ट देख सकते हैं। बाईं ओर, आप वे KPI देख सकते हैं जो आपके वर्तमान डेलिगेशन मेट्रिक्स को दर्शाते हैं।
+
+इस टैब में आप यहां जो डेलिगेटर मेट्रिक्स देखेंगे उनमें शामिल हैं:
+
+- कुल प्रतिनिधिमंडल पुरस्कार
+- कुल अचेतन पुरस्कार
+- कुल एहसास पुरस्कार
+
+पृष्ठ के दूसरे भाग में, आपके पास प्रतिनिधि तालिका है। यहां आप उन इंडेक्स को देख सकते हैं जिन्हें आपने प्रत्यायोजित किया है, साथ ही उनके विवरण (जैसे रिवॉर्ड कट, कूलडाउन, आदि)।
+
+तालिका के दाईं ओर स्थित बटनों के साथ, आप अपने प्रतिनिधिमंडल का प्रबंधन कर सकते हैं - अधिक प्रतिनिधि, अप्रतिबंधित, या पिघलने की अवधि के बाद अपने प्रतिनिधिमंडल को वापस ले सकते हैं।
+
+ध्यान रखें कि यह चार्ट क्षैतिज रूप से स्क्रॉल करने योग्य है, इसलिए यदि आप दाईं ओर स्क्रॉल करते हैं, तो आप अपने प्रतिनिधिमंडल की स्थिति भी देख सकते हैं (प्रतिनिधि, अविभाजित, वापस लेने योग्य)।
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### क्यूरेटिंग टैब
+
+क्यूरेशन टैब में, आपको वे सभी सबग्राफ मिलेंगे जिन पर आप संकेत कर रहे हैं (इस प्रकार आपको क्वेरी शुल्क प्राप्त करने में सक्षम बनाता है)। सिग्नलिंग क्यूरेटर को इंडेक्सर्स को हाइलाइट करने की अनुमति देता है जो उपग्राफ मूल्यवान और भरोसेमंद हैं, इस प्रकार संकेत देते हैं कि उन्हें अनुक्रमित करने की आवश्यकता है।
+
+इस टैब के भीतर, आपको इसका अवलोकन मिलेगा:
+
+- सभी सबग्राफ आप सिग्नल विवरण के साथ क्यूरेट कर रहे हैं
+- प्रति सबग्राफ शेयर योग
+- क्वेरी पुरस्कार प्रति सबग्राफ
+- दिनांक विवरण पर अद्यतन किया गया
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## आपकी प्रोफ़ाइल सेटिंग्स
+
+अपने उपयोगकर्ता प्रोफ़ाइल के भीतर, आप अपने व्यक्तिगत प्रोफ़ाइल विवरण (जैसे ENS नाम सेट करना) प्रबंधित करने में सक्षम होंगे। यदि आप एक इंडेक्सर हैं, तो आपके पास अपनी उंगलियों पर सेटिंग्स तक और भी अधिक पहुंच है। अपने उपयोगकर्ता प्रोफ़ाइल में, आप अपने प्रतिनिधि पैरामीटर और ऑपरेटर सेट अप करने में सक्षम होंगे।
+
+- ऑपरेटर इंडेक्सर की ओर से प्रोटोकॉल में सीमित कार्रवाई करते हैं, जैसे आवंटन खोलना और बंद करना। ऑपरेटर आमतौर पर अन्य एथेरियम पते होते हैं, जो उनके स्टेकिंग वॉलेट से अलग होते हैं, नेटवर्क तक गेटेड एक्सेस के साथ जिसे इंडेक्सर्स व्यक्तिगत रूप से सेट कर सकते हैं
+- प्रत्यायोजन पैरामीटर की सहायता से आप अपने और अपने प्रतिनियुक्तियों के बीच GRT के वितरण को नियंत्रित कर सकते हैं.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From d9549b9161fabcd2727514fb5a58ab96e654edbe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:01 -0500
Subject: [PATCH 2033/3820] New translations explorer.mdx (Swahili)

---
 website/pages/sw/subgraphs/explorer.mdx | 236 ++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/explorer.mdx

diff --git a/website/pages/sw/subgraphs/explorer.mdx b/website/pages/sw/subgraphs/explorer.mdx
new file mode 100644
index 000000000000..433821560d85
--- /dev/null
+++ b/website/pages/sw/subgraphs/explorer.mdx
@@ -0,0 +1,236 @@
+---
+title: Graph Explorer
+---
+
+Learn about The Graph Explorer and access the world of subgraphs and network data.
+
+Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+
+## Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />
+
+## Subgraphs
+
+After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+
+- Your own finished subgraphs
+- Subgraphs published by others
+- The exact subgraph you want (based on the date created, signal amount, or name).
+
+![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+
+When you click into a subgraph, you will be able to do the following:
+
+- Test queries in the playground and be able to leverage network details to make informed decisions.
+- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+![Explorer Image 2](/img/Subgraph-Details.png)
+
+On each subgraph’s dedicated page, you can do the following:
+
+- Signal/Un-signal on subgraphs
+- View more details such as charts, current deployment ID, and other metadata
+- Switch versions to explore past iterations of the subgraph
+- Query subgraphs via GraphQL
+- Test subgraphs in the playground
+- View the Indexers that are indexing on a certain subgraph
+- Subgraph stats (allocations, Curators, etc)
+- View the entity who published the subgraph
+
+![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+
+## Participants
+
+This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+### 1. Indexers
+
+![Explorer Image 4](/img/Indexer-Pane.png)
+
+Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+
+In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+
+**Specifics**
+
+- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
+- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
+- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
+- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
+- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
+- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Max Delegation Capacity - the maximum amount of delegated stake the Indexer can productively accept. An excess delegated stake cannot be used for allocations or rewards calculations.
+- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Indexer Rewards - this is the total indexer rewards earned by the Indexer and their Delegators over all time. Indexer rewards are paid through GRT issuance.
+
+Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+
+- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+
+To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+
+![Indexing details pane](/img/Indexing-Details-Pane.png)
+
+### 2. Curators
+
+Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+
+- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
+  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
+  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+
+In the The Curator table listed below you can see:
+
+- The date the Curator started curating
+- The number of GRT that was deposited
+- The number of shares a Curator owns
+
+![Explorer Image 6](/img/Curation-Overview.png)
+
+If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+
+### 3. Delegators
+
+Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+
+- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
+- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+
+![Explorer Image 7](/img/Delegation-Overview.png)
+
+In the Delegators table you can see the active Delegators in the community and important metrics:
+
+- The number of Indexers a Delegator is delegating towards
+- A Delegator’s original delegation
+- The rewards they have accumulated but have not withdrawn from the protocol
+- The realized rewards they withdrew from the protocol
+- Total amount of GRT they have currently in the protocol
+- The date they last delegated
+
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+
+## Network
+
+In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+
+### Overview
+
+The overview section has both all the current network metrics and some cumulative metrics over time:
+
+- The current total network stake
+- The stake split between the Indexers and their Delegators
+- Total supply, minted, and burned GRT since the network inception
+- Total Indexing rewards since the inception of the protocol
+- Protocol parameters such as curation reward, inflation rate, and more
+- Current epoch rewards and fees
+
+A few key details to note:
+
+- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
+- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+
+![Explorer Image 8](/img/Network-Stats.png)
+
+### Epochs
+
+In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
+
+- Epoch start or end block
+- Query fees generated and indexing rewards collected during a specific epoch
+- Epoch status, which refers to the query fee collection and distribution and can have different states:
+  - The active epoch is the one in which Indexers are currently allocating stake and collecting query fees
+  - The settling epochs are the ones in which the state channels are being settled. This means that the Indexers are subject to slashing if the consumers open disputes against them.
+  - The distributing epochs are the epochs in which the state channels for the epochs are being settled and Indexers can claim their query fee rebates.
+  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+
+![Explorer Image 9](/img/Epoch-Stats.png)
+
+## Your User Profile
+
+Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+
+### Profile Overview
+
+In this section, you can view the following:
+
+- Any of your current actions you've done.
+- Your profile information, description, and website (if you added one).
+
+![Explorer Image 10](/img/Profile-Overview.png)
+
+### Subgraphs Tab
+
+In the Subgraphs tab, you’ll see your published subgraphs.
+
+> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+
+![Explorer Image 11](/img/Subgraphs-Overview.png)
+
+### Indexing Tab
+
+In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+
+This section will also include details about your net Indexer rewards and net query fees. You’ll see the following metrics:
+
+- Delegated Stake - the stake from Delegators that can be allocated by you but cannot be slashed
+- Total Query Fees - the total fees that users have paid for queries served by you over time
+- Indexer Rewards - the total amount of Indexer rewards you have received, in GRT
+- Fee Cut - the % of query fee rebates that you will keep when you split with Delegators
+- Rewards Cut - the % of Indexer rewards that you will keep when splitting with Delegators
+- Owned - your deposited stake, which could be slashed for malicious or incorrect behavior
+
+![Explorer Image 12](/img/Indexer-Stats.png)
+
+### Delegating Tab
+
+Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+
+In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+
+In the first half of the page, you can see your delegation chart, as well as the rewards-only chart. To the left, you can see the KPIs that reflect your current delegation metrics.
+
+The Delegator metrics you’ll see here in this tab include:
+
+- Total delegation rewards
+- Total unrealized rewards
+- Total realized rewards
+
+In the second half of the page, you have the delegations table. Here you can see the Indexers that you delegated towards, as well as their details (such as rewards cuts, cooldown, etc).
+
+With the buttons on the right side of the table, you can manage your delegation - delegate more, undelegate, or withdraw your delegation after the thawing period.
+
+Keep in mind that this chart is horizontally scrollable, so if you scroll all the way to the right, you can also see the status of your delegation (delegating, undelegating, withdrawable).
+
+![Explorer Image 13](/img/Delegation-Stats.png)
+
+### Curating Tab
+
+In the Curation tab, you’ll find all the subgraphs you’re signaling on (thus enabling you to receive query fees). Signaling allows Curators to highlight to Indexers which subgraphs are valuable and trustworthy, thus signaling that they need to be indexed on.
+
+Within this tab, you’ll find an overview of:
+
+- All the subgraphs you're curating on with signal details
+- Share totals per subgraph
+- Query rewards per subgraph
+- Updated at date details
+
+![Explorer Image 14](/img/Curation-Stats.png)
+
+## Your Profile Settings
+
+Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
+
+- Operators take limited actions in the protocol on the Indexer's behalf, such as opening and closing allocations. Operators are typically other Ethereum addresses, separate from their staking wallet, with gated access to the network that Indexers can personally set
+- Delegation parameters allow you to control the distribution of GRT between you and your Delegators.
+
+![Explorer Image 15](/img/Profile-Settings.png)
+
+As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>

From 2ef301e2e232d4709b7664d94ec813a77e61c374 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:02 -0500
Subject: [PATCH 2034/3820] New translations best-practices.mdx (Romanian)

---
 .../ro/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/ro/subgraphs/querying/best-practices.mdx b/website/pages/ro/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..3736fa32faeb
--- /dev/null
+++ b/website/pages/ro/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Querying Best Practices
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Querying a GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+Unlike REST API, a GraphQL API is built upon a Schema that defines which queries can be performed.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Any variable assigned to an argument must match its type.
+- In a given list of variables, each of them must be unique.
+- All defined variables must be used.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Sending a query to a GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### Always write static queries
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Leverage GraphQL Fragments
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL Fragment do's and don'ts
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Example:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- and more!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 206ec4b76e18d64f519927a85ea9e97ad4c00139 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:03 -0500
Subject: [PATCH 2035/3820] New translations best-practices.mdx (French)

---
 .../fr/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/fr/subgraphs/querying/best-practices.mdx b/website/pages/fr/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..4c9ac69b2af4
--- /dev/null
+++ b/website/pages/fr/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Bonnes pratiques d'interrogation
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Interroger une API GraphQL
+
+### The Anatomy of a GraphQL Query
+
+Contrairement à l'API REST, une API GraphQL repose sur un schéma qui définit les requêtes qui peuvent être effectuées.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Toute variable affectée à un argument doit correspondre à son type.
+- Dans une liste de variables donnée, chacune d’elles doit être unique.
+- Toutes les variables définies doivent être utilisées.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Envoi d'une requête à une API GraphQL
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Gestion des subgraphs inter-chaînes : interrogation à partir de plusieurs subgraphs en une seule requête
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Résultat entièrement typé
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Les meilleures pratiques
+
+### Écrivez toujours des requêtes statiques
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- Lorsque vous interrogez les API GraphQL, pensez toujours à interroger uniquement les champs qui seront réellement utilisés.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Tirer parti des fragments GraphQL
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# nous définissons un fragment (sous-type) sur Transcoder
+# pour factoriser les champs répétés dans la requête
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### Bonnes pratiques et erreurs à éviter avec les fragments GraphQL
+
+### La base du fragment doit être un type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### Comment diffuser un fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+L'exemple:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Erreur ! `VoteItem` ne peut pas être étendu sur le type `Transcoder`
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Définir Fragment comme une unité commerciale atomique de données
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# fragment de base (utilisé principalement pour les listes)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# fragment étendu (lors de l'interrogation d'une vue détaillée d'un vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### Explorateurs Web GraphQL
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### Linting GraphQL
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- et plus !
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### Plugins IDE
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From b3b7406aabe8949b9abe434aff23a2c2ceb5a2be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:04 -0500
Subject: [PATCH 2036/3820] New translations best-practices.mdx (Spanish)

---
 .../es/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/es/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/es/subgraphs/querying/best-practices.mdx b/website/pages/es/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..2091619aa25f
--- /dev/null
+++ b/website/pages/es/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Mejores Prácticas para Consultas
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Consulta de una API GraphQL
+
+### The Anatomy of a GraphQL Query
+
+A diferencia de la API REST, una API GraphQL se basa en un esquema que define las consultas que se pueden realizar.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Cualquier variable asignada a un argumento debe coincidir con su tipo.
+- En una lista dada de variables, cada una de ellas debe ser única.
+- Deben utilizarse todas las variables definidas.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Envío de una consulta a una API GraphQL
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Manejo de subgrafos cross-chain: Consulta de varios subgrafos en una sola consulta
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Resultado completamente tipificado
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### Escribe siempre consultas estáticas
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Aprovechar los GraphQL Fragments
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### Qué hacer y qué no hacer con los GraphQL Fragments
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Ejemplo:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### Exploradores web GraphQL
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- ¡y mucho más!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### Plugins IDE
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 8ff0570ef1c029848d6c3331e24ab539730ab970 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:06 -0500
Subject: [PATCH 2037/3820] New translations best-practices.mdx (Arabic)

---
 .../ar/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/ar/subgraphs/querying/best-practices.mdx b/website/pages/ar/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..ba7439d7752d
--- /dev/null
+++ b/website/pages/ar/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: أفضل الممارسات للاستعلام
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## الاستعلام عن واجهة برمجة تطبيقات GraphQL
+
+### The Anatomy of a GraphQL Query
+
+على عكس REST API ، فإن GraphQL API مبنية على مخطط يحدد الاستعلامات التي يمكن تنفيذها.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- يجب أن يكون أي متغير تم تعيينه لوسيط متطابقًا مع نوعه.
+- في قائمة المتغيرات المعطاة ، يجب أن يكون كل واحد منها فريدًا.
+- يجب استخدام جميع المتغيرات المحددة.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### إرسال استعلام إلى GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- التعامل مع ال subgraph عبر السلاسل: الاستعلام من عدة subgraphs عبر استعلام واحد
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- نتيجة مكتوبة بالكامل
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### اكتب دائمًا استعلامات ثابتة
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### الاستفادة من أجزاء GraphQL
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### ما يجب فعله وما لا يجب فعله في GraphQL Fragment
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Example:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- و اكثر!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 80b5c26d0d0a1dfc8ed711e71b72687e8ed4c08e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:07 -0500
Subject: [PATCH 2038/3820] New translations best-practices.mdx (Czech)

---
 .../cs/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/cs/subgraphs/querying/best-practices.mdx b/website/pages/cs/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..114ca91306f9
--- /dev/null
+++ b/website/pages/cs/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Osvědčené postupy dotazování
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Dotazování GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+Na rozdíl od rozhraní REST API je GraphQL API postaveno na schématu, které definuje, jaké dotazy lze provádět.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Každá proměnná přiřazená argumentu musí odpovídat jeho typu.
+- V daném seznamu proměnných musí být každá z nich jedinečná.
+- Musí být použity všechny definované proměnné.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Odeslání dotazu na GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Manipulace s podgrafy napříč řetězci: Dotazování z více podgrafů v jednom dotazu
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Plně zadaný výsledekv
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Osvědčené postupy
+
+### Vždy pište statické dotazy
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- Při dotazování na GraphQL vždy myslete na to, abyste dotazovali pouze pole, která budou skutečně použita.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Využití fragmentů GraphQL
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### Co dělat a nedělat s fragmenty GraphQL
+
+### Základem fragmentu musí být typ
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### Jak šířit fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Příklad:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Definice fragmentu jako atomické obchodní jednotky dat
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### Weboví průzkumníci GraphQL
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- a další!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE zásuvné
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 347ff23bd7ef80d17682f95d2e297e22de497a3a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:08 -0500
Subject: [PATCH 2039/3820] New translations best-practices.mdx (German)

---
 .../de/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/de/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/de/subgraphs/querying/best-practices.mdx b/website/pages/de/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..3736fa32faeb
--- /dev/null
+++ b/website/pages/de/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Querying Best Practices
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Querying a GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+Unlike REST API, a GraphQL API is built upon a Schema that defines which queries can be performed.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Any variable assigned to an argument must match its type.
+- In a given list of variables, each of them must be unique.
+- All defined variables must be used.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Sending a query to a GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### Always write static queries
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Leverage GraphQL Fragments
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL Fragment do's and don'ts
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Example:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- and more!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From f436fcc88369621445a77563afa29b7659779578 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:09 -0500
Subject: [PATCH 2040/3820] New translations best-practices.mdx (Italian)

---
 .../it/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/it/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/it/subgraphs/querying/best-practices.mdx b/website/pages/it/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..5e1f5a183b3c
--- /dev/null
+++ b/website/pages/it/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Querying Best Practices
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Effettuare query con API GraphQL
+
+### The Anatomy of a GraphQL Query
+
+A differenza del REST API, un GraphQL API si basa su uno schema che definisce le query che possono essere eseguite.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Qualsiasi variabile assegnata a un argomento deve corrispondere al suo tipo.
+- In un determinato elenco di variabili, ciascuna di esse deve essere unica.
+- Tutte le variabili definite devono essere utilizzate.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Invio di una query a un API GraphQL
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Gestione dei subgraph a cross-chain: effettuare query di più subgraph in un'unica query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Risultato completamente tipizzato
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### Scrivere sempre query statiche
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- Quando si interrogano le GraphQL API, si deve sempre pensare di effettuare query di solo i campi che verranno effettivamente utilizzati.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Sfruttare i frammenti GraphQL
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### I frammenti GraphQL da fare e da non fare
+
+### La base del frammento deve essere un tipo
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### Come diffondere un frammento
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Example:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Definire il frammento come unità aziendale atomica di dati
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### Esploratori web GraphQL
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### Linting di GraphQL
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- e altro ancora!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### Plugin IDE
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 488cc8e4c73be8f6383b419b5a8516ce5e06510e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:10 -0500
Subject: [PATCH 2041/3820] New translations best-practices.mdx (Japanese)

---
 .../ja/subgraphs/querying/best-practices.mdx  | 486 ++++++++++++++++++
 1 file changed, 486 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/ja/subgraphs/querying/best-practices.mdx b/website/pages/ja/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..2866e3ccb933
--- /dev/null
+++ b/website/pages/ja/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,486 @@
+---
+title: クエリのベストプラクティス
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## GraphQL APIのクエリ
+
+### The Anatomy of a GraphQL Query
+
+REST APIとは異なり、GraphQL APIは実行可能なクエリを定義するSchemaをベースに構築されています。
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- 引数に代入される変数は、その型と一致しなければなりません。
+- 与えられた変数のリストにおいて、各変数は一意でなければなりません。
+- 定義された変数はすべて使用する必要があります。
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### GraphQL APIへのクエリの送信
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- クロスチェーンのサブグラフ処理：1回のクエリで複数のサブグラフからクエリを実行可能
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- 完全なタイプ付け結果
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## ベストプラクティス
+
+### 常に静的なクエリを記述
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- GraphQL APIをクエリする際には、実際に使用するフィールドのみをクエリするように常に考えてください。
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### GraphQLフラグメントの活用
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQLフラグメントの注意点
+
+### フラグメントベースは型である必要があります
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### フラグメントを拡散する方法
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+例：
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### フラグメントをデータのアトミックなビジネス単位として定義する
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL ウェブベースのエクスプローラ
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- ともっと
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 1863cddcebaade882f5b3b738639350f3f954f40 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:11 -0500
Subject: [PATCH 2042/3820] New translations best-practices.mdx (Korean)

---
 .../ko/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/ko/subgraphs/querying/best-practices.mdx b/website/pages/ko/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..3736fa32faeb
--- /dev/null
+++ b/website/pages/ko/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Querying Best Practices
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Querying a GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+Unlike REST API, a GraphQL API is built upon a Schema that defines which queries can be performed.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Any variable assigned to an argument must match its type.
+- In a given list of variables, each of them must be unique.
+- All defined variables must be used.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Sending a query to a GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### Always write static queries
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Leverage GraphQL Fragments
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL Fragment do's and don'ts
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Example:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- and more!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 5b5e90a82dabc92a858e03ac6f8406d059d9716f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:12 -0500
Subject: [PATCH 2043/3820] New translations best-practices.mdx (Dutch)

---
 .../nl/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/nl/subgraphs/querying/best-practices.mdx b/website/pages/nl/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..3736fa32faeb
--- /dev/null
+++ b/website/pages/nl/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Querying Best Practices
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Querying a GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+Unlike REST API, a GraphQL API is built upon a Schema that defines which queries can be performed.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Any variable assigned to an argument must match its type.
+- In a given list of variables, each of them must be unique.
+- All defined variables must be used.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Sending a query to a GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### Always write static queries
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Leverage GraphQL Fragments
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL Fragment do's and don'ts
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Example:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- and more!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 57b43355b05c73dbc77b713a1b4049fcf885e9b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:13 -0500
Subject: [PATCH 2044/3820] New translations best-practices.mdx (Polish)

---
 .../pl/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/pl/subgraphs/querying/best-practices.mdx b/website/pages/pl/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..3736fa32faeb
--- /dev/null
+++ b/website/pages/pl/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Querying Best Practices
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Querying a GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+Unlike REST API, a GraphQL API is built upon a Schema that defines which queries can be performed.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Any variable assigned to an argument must match its type.
+- In a given list of variables, each of them must be unique.
+- All defined variables must be used.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Sending a query to a GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### Always write static queries
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Leverage GraphQL Fragments
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL Fragment do's and don'ts
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Example:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- and more!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From b2dfb0ba9991f4c0dd033e1ca7d41f100c093c0a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:14 -0500
Subject: [PATCH 2045/3820] New translations best-practices.mdx (Portuguese)

---
 .../pt/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/pt/subgraphs/querying/best-practices.mdx b/website/pages/pt/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..4f939b79b731
--- /dev/null
+++ b/website/pages/pt/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Etiqueta de Query
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Queries numa API GraphQL
+
+### The Anatomy of a GraphQL Query
+
+Ao contrário da REST API, uma API GraphQL é construída em cima de um Schema que define quais queries podem ser realizados.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" expressa um Selection-Set, estamos a consultar campos do `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Qualquer variável apontada a um argumento deve corresponder ao seu tipo.
+- Em uma lista dada de variáveis, cada uma delas deve ser única.
+- Todas as variáveis definidas devem ser usadas.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Como enviar um query a uma API GraphQL
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Gestão de Subgraph Cross-chain: Queries de múltiplos subgraphs numa única consulta
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Resultado totalmente digitado
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Boas práticas
+
+### Sempre escreva consultas estáticas
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Pergunte pelo que queres
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- Ao consultar APIs GraphQL, sempre considere fazer query apenas dos campos que serão usados.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use uma única query para pedir vários registros
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine múltiplas queries em um único pedido
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Como Aproveitar Fragmentos GraphQL
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# nós definimos um fragmento (subtipo) no Transcoder
+# para fatorizar campos repetidos no query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### O que fazer e o que não fazer em Fragments GraphQL
+
+### A base do fragment deve ser um tipo
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### Como espalhar um Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Exemplo:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Defina o Fragment como uma unidade de negócios atômica de dados
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### Exploradores do GraphQL baseados em web
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- e mais!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### Plugins IDE
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 930a12159470a25edbce94f3b08b36f5ca79b3fb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:15 -0500
Subject: [PATCH 2046/3820] New translations best-practices.mdx (Russian)

---
 .../ru/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/ru/subgraphs/querying/best-practices.mdx b/website/pages/ru/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..8b9721a393e8
--- /dev/null
+++ b/website/pages/ru/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Querying Best Practices
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Querying a GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+Unlike REST API, a GraphQL API is built upon a Schema that defines which queries can be performed.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Any variable assigned to an argument must match its type.
+- In a given list of variables, each of them must be unique.
+- All defined variables must be used.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Sending a query to a GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Лучшие практики
+
+### Always write static queries
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Leverage GraphQL Fragments
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL Fragment do's and don'ts
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Пример:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- and more!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 06dcc98f459e3bb1677076315b1444463de2ed7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:16 -0500
Subject: [PATCH 2047/3820] New translations best-practices.mdx (Swedish)

---
 .../sv/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/sv/subgraphs/querying/best-practices.mdx b/website/pages/sv/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..6f593237dc85
--- /dev/null
+++ b/website/pages/sv/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Bästa praxis för förfrågningar
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Att fråga ett GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+Till skillnad från REST API bygger ett GraphQL API på ett schema som definierar vilka frågor som kan utföras.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" uttrycker en Selection-Set, vi frågar efter fält från `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Varje variabel som tilldelas ett argument måste matcha dess typ.
+- I en given lista med variabler måste var och en av dem vara unik.
+- Alla definierade variabler måste användas.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Att skicka en fråga till ett GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Hantering av subgrafer över olika blockkedjor: Frågehantering från flera subgrafer i en enda fråga
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fullt typad resultat
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from "../.graphclient";
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`;
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables);
+  // `result` är fullständigt typad!
+  console.log(result);
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Bästa praxis
+
+### Skriv alltid statiska frågor
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id;
+const fields = ["id", "owner"];
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join("\n")}
+  }
+}
+`;
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from "your-favorite-graphql-client";
+
+const id = params.id;
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`;
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from "your-favorite-graphql-client";
+
+const id = params.id;
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- När du frågar GraphQL API:er, tänk alltid på att endast fråga efter de fält som faktiskt kommer att användas.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # kommer att ge upp till 100 tokens
+    id
+    transactions {
+      # kommer att ge upp till 100 transaktioner
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Dra nytta av GraphQL-fragment
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# vi definierar ett fragment (subtyp) på Transcoder
+# att faktorisera upprepade fält i frågan
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### Dos and Don'ts för GraphQL Fragment
+
+### Fragmentbas måste vara en typ
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### Hur man sprider ett fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Exempel:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Fel! `VoteItem` kan inte spridas på `Transcoder` typ
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Definiera fragment som en atomisk affärsenhet för data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# utökat fragment (vid förfrågan om en detaljerad vy av en omröstning)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### Webbaserade GraphQL-upptäckare
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- och mer!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE-tillägg
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From f50ae0fe1e41670f46644958907e066bf1fb27cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:18 -0500
Subject: [PATCH 2048/3820] New translations best-practices.mdx (Turkish)

---
 .../tr/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/tr/subgraphs/querying/best-practices.mdx b/website/pages/tr/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..8f3a056e900e
--- /dev/null
+++ b/website/pages/tr/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Querying Best Practices
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Querying a GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+Unlike REST API, a GraphQL API is built upon a Schema that defines which queries can be performed.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Any variable assigned to an argument must match its type.
+- In a given list of variables, each of them must be unique.
+- All defined variables must be used.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Sending a query to a GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## En İyi Uygulamalar
+
+### Always write static queries
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- GraphQL API'leri sorgularken, her zaman sadece gerçekten kullanılacak alanları sorgulamayı düşünmelisiniz.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Leverage GraphQL Fragments
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL Fragment do's and don'ts
+
+### Fragment tabanı bir tip olmalıdır
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### Fragment Nasıl Yayılır
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Örnek:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Fragment'ı atomik bir veri iş birimi olarak tanımlayın
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- and more!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 722500c2f477e6f138df9a8c62a9d103a051871a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:19 -0500
Subject: [PATCH 2049/3820] New translations best-practices.mdx (Ukrainian)

---
 .../uk/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/uk/subgraphs/querying/best-practices.mdx b/website/pages/uk/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..ae0fff305e31
--- /dev/null
+++ b/website/pages/uk/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Найкращі практики виконання запитів
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Запити в GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+На відміну від REST API, GraphQL API побудований на основі Schema, яка визначає, які запити можуть бути виконані.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Будь-яка змінна, що присвоюється параметру, повинна відповідати його типу.
+- У заданому списку змінних кожна з них має бути унікальною.
+- Всі задані змінні повинні бути використаними.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Відправлення запиту до GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Робота з кросс-чейн підграфами: Отримання інформації з декількох підграфів за один запит
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Повністю введений результат
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Найкращі практики
+
+### Завжди пишіть статичні запити
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- Запитуючи API GraphQL, завжди запитуйте тільки ті поля, які дійсно будуть використовуватися.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Використання фрагментів GraphQL
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### Фрагмент GraphQL, що можна і що не можна робити
+
+### База фрагменту повинна бути типом
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### Як розповсюдити Фрагмент
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Example:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Визначте фрагмент як атомну бізнес-одиницю даних
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- та більше!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### Плагіни IDE
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From cf6affd6e07008945dcbfc451a6a23a5e711f852 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:20 -0500
Subject: [PATCH 2050/3820] New translations best-practices.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/zh/subgraphs/querying/best-practices.mdx b/website/pages/zh/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..801a461c7414
--- /dev/null
+++ b/website/pages/zh/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: 查询最佳实践
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## 查询GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+与REST API不同，GraphQL API构建在定义可以执行哪些查询的模式之上。
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" 代表一个选择集, 我们正在从`queryName`查询域。
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- 分配给参数的任何变量都必须匹配其类型。
+- 在给定的变量列表中，每个变量必须是唯一的。
+- 必须使用所有已定义的变量。
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### 向 GraphQL API 发送查询
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- 跨链子图处理: 在一个查询中从多个子图进行查询
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- 完全类型化的结果
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### 始终编写静态查询
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- 在查询GraphQL API时，请始终考虑只查询实际使用的字段。
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # 获取最多100个token
+    id
+    transactions {
+      # 获取最多100个交易
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### 利用GraphQL片段
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# 我们在代码转换器定义了一个碎片（子类型）
+# 将查询中重复的域分解
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL片段的注意事项
+
+### 片段必须是一种类型
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### 如何传播片段
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+例子:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### 将片段定义为数据的原子业务单元。
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (主要在上架中使用)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (当查询投票中一个选项的细节)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL基于web的浏览器
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- 还有更多！
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE插件
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From de6c8ebf23e597e507e5946b4a14c851dd40ffb8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:21 -0500
Subject: [PATCH 2051/3820] New translations best-practices.mdx (Urdu
 (Pakistan))

---
 .../ur/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/ur/subgraphs/querying/best-practices.mdx b/website/pages/ur/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..7b60a12c440f
--- /dev/null
+++ b/website/pages/ur/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: بہترین طریقوں سے کیوری کرنا
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## ایک GraphQL API کا کیوری کرنا
+
+### The Anatomy of a GraphQL Query
+
+REST API کے برعکس، ایک GraphQL API ایک اسکیما پر بنایا گیا ہے جو اس بات کی وضاحت کرتا ہے کہ کون سے کیوری کیے جا سکتے ہیں.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- کسی دلیل کو تفویض کردہ کوئی بھی متغیر اس کی قسم سے مماثل ہونا چاہیے.
+- متغیرات کی دی گئی فہرست میں، ان میں سے ہر ایک منفرد ہونا چاہیے.
+- تمام متعین متغیرات کو استعمال کیا جانا چاہیے.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### GraphQL API کو ایک کیوری بھیجنا
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- کراس چین سب گراف ہینڈلنگ: ایک کیوری میں متعدد سب گرافس سے کیوری کرنا
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- مکمل طور پر ٹائپ شدہ نتیجہ
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## بہترین طریقے
+
+### ہمیشہ جامد کیوریز لکھیں
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- GraphQL APIs سے کیوری کرتے وقت، ہمیشہ صرف ان فیلڈز سے کیوری کرنے کے بارے میں سوچیں جو حقیقت میں استعمال ہوں گے.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### لیوریج GraphQL فریگمنٹس
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL فریگمنٹ کیا کریں اور نہ کریں
+
+### فریگمنٹ بیس ایک ٹائپ کا ہونا چاہیے
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### فریگمینٹ پھیلانے کا طریقہ
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+مثال:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### فریگمنٹ کو ڈیٹا کی ایٹم بزنس یونٹ کے طور پر بیان کریں
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL ویب پر مبنی ایکسپلوررز
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL لنٹنگ
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- اور مزید!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 03bea4bc0f652a32f6099d8ea73f18ad5fb220b0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:22 -0500
Subject: [PATCH 2052/3820] New translations best-practices.mdx (Vietnamese)

---
 .../vi/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/vi/subgraphs/querying/best-practices.mdx b/website/pages/vi/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..3736fa32faeb
--- /dev/null
+++ b/website/pages/vi/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Querying Best Practices
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Querying a GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+Unlike REST API, a GraphQL API is built upon a Schema that defines which queries can be performed.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Any variable assigned to an argument must match its type.
+- In a given list of variables, each of them must be unique.
+- All defined variables must be used.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Sending a query to a GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### Always write static queries
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Leverage GraphQL Fragments
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL Fragment do's and don'ts
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Example:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- and more!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 13b0b622b813e87034f21d9dbf27b761fd8227cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:23 -0500
Subject: [PATCH 2053/3820] New translations best-practices.mdx (Marathi)

---
 .../mr/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/mr/subgraphs/querying/best-practices.mdx b/website/pages/mr/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..c2e39380c4fe
--- /dev/null
+++ b/website/pages/mr/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Querying Best Practices
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Querying a GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+REST API च्या विपरीत, GraphQL API एका स्कीमावर तयार केले जाते जे कोणत्या क्वेरी पूर्ण केल्या जाऊ शकतात हे परिभाषित करते.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Any variable assigned to an argument must match its type.
+- In a given list of variables, each of them must be unique.
+- All defined variables must be used.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Sending a query to a GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### Always write static queries
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Leverage GraphQL Fragments
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL Fragment do's and don'ts
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+उदाहरण:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- and more!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From 6ddd40f456beb742dc435edb8e29fb84e3c4ebe2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:24 -0500
Subject: [PATCH 2054/3820] New translations best-practices.mdx (Hindi)

---
 .../hi/subgraphs/querying/best-practices.mdx  | 486 ++++++++++++++++++
 1 file changed, 486 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/hi/subgraphs/querying/best-practices.mdx b/website/pages/hi/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..0a3110ebff92
--- /dev/null
+++ b/website/pages/hi/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,486 @@
+---
+title: सर्वोत्तम प्रथाओं को क्वेरी करना
+---
+
+The Graph ब्लॉकचेन से डेटा क्वेरी करने का एक विकेन्द्रीकृत तरीका प्रदान करता है। इसका डेटा एक GraphQL API के माध्यम से एक्सपोज़ किया जाता है, जिससे इसे GraphQL भाषा के साथ क्वेरी करना आसान हो जाता है।
+
+GraphQL भाषा के आवश्यक नियमों और सर्वोत्तम प्रथाओं को सीखें ताकि आप अपने subgraph को अनुकूलित कर सकें।
+
+---
+
+## ग्राफ़कॉल एपीआई को क्वेरी करना
+
+### GraphQL Query की संरचना
+
+REST API के विपरीत, एक रेखांकन API एक स्कीमा पर बनाया गया है जो परिभाषित करता है कि कौन से प्रश्न किए जा सकते हैं।
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## GraphQL क्वेरी लिखने के नियम
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- किसी तर्क को असाइन किया गया कोई भी चर उसके प्रकार से मेल खाना चाहिए।
+- चरों की दी गई सूची में, उनमें से प्रत्येक अद्वितीय होना चाहिए।
+- सभी परिभाषित चर का उपयोग किया जाना चाहिए।
+
+> ध्यान दें: इन नियमों का पालन न करने पर The Graph API से त्रुटि होगी।
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### एक ग्राफ़क्यूएल एपीआई के लिए एक प्रश्न भेजना
+
+GraphQL एक भाषा और प्रथाओं का सेट है जो HTTP के माध्यम से संचालित होता है।
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- क्रॉस-चेन सबग्राफ हैंडलिंग: एक ही क्वेरी में कई सबग्राफ से पूछताछ
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- पूरी तरह से टाइप किया गया परिणाम
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### हमेशा स्टैटिक क्वेश्चन लिखें
+
+एक सामान्य (खराब) प्रथा है कि क्वेरी स्ट्रिंग्स को निम्नलिखित तरीके से गतिशील रूप से बनाया जाए:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+इसी कारण, यह अनुशंसा की जाती है कि हमेशा क्वेरीज़ को स्थिर स्ट्रिंग्स के रूप में लिखा जाए।
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### स्टेटिक क्वेरीज़ में फ़ील्ड्स को शर्तानुसार कैसे शामिल करें
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### आप जो चाहते हैं वह मांगें
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- सुनिश्चित करें कि क्वेरीज़ केवल उतने ही एंटिटीज़ लाएँ जितनी आपको वास्तव में आवश्यकता है। डिफ़ॉल्ट रूप से, क्वेरीज़ एक संग्रह में 100 एंटिटीज़ लाएँगी, जो आमतौर पर उपयोग में लाई जाने वाली मात्रा से अधिक होती है, जैसे कि उपयोगकर्ता को प्रदर्शित करने के लिए। यह न केवल एक क्वेरी में शीर्ष-स्तरीय संग्रहों पर लागू होता है, बल्कि एंटिटीज़ के नेस्टेड संग्रहों पर भी अधिक लागू होता है।
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### एक ही क्वेरी का उपयोग करके कई रिकॉर्ड्स का अनुरोध करें
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### एकल अनुरोध में कई क्वेरियों को संयोजित करें।
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### लीवरेज ग्राफक्यूएल फ़्रैगमेंट
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- बड़ी क्वेरीज़ पढ़ने में कठिन होती हैं।
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### ग्राफकॉल फ्रैगमेंट क्या करें और क्या न करें
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+उदाहरण:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- जब समान लेकिन भिन्न फ़ील्ड्स को दोहराया जाता है, तो कई फ़्रैगमेंट्स बनाएं, उदाहरण के लिए:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### ग्राफक्यूएल वेब-आधारित खोजकर्ता
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### ग्राफक्यूएल लाइनिंग
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- और अधिक!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### आईडीई प्लगइन्स
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- सिंटैक्स हाइलाइटिंग
+- ऑटो-कंप्लीट सुझाव
+- स्कीमा के खिलाफ मान्यता
+- निबंध
+- फ्रैगमेंट्स और इनपुट टाइप्स के लिए परिभाषा पर जाएं।
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- सिंटैक्स हाइलाइटिंग
+- ऑटो-कंप्लीट सुझाव
+- स्कीमा के खिलाफ मान्यता
+- निबंध
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From f60190da9f3aacde3f68ce9f023795ecc5e1d248 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:25 -0500
Subject: [PATCH 2055/3820] New translations best-practices.mdx (Swahili)

---
 .../sw/subgraphs/querying/best-practices.mdx  | 488 ++++++++++++++++++
 1 file changed, 488 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/querying/best-practices.mdx

diff --git a/website/pages/sw/subgraphs/querying/best-practices.mdx b/website/pages/sw/subgraphs/querying/best-practices.mdx
new file mode 100644
index 000000000000..3736fa32faeb
--- /dev/null
+++ b/website/pages/sw/subgraphs/querying/best-practices.mdx
@@ -0,0 +1,488 @@
+---
+title: Querying Best Practices
+---
+
+The Graph provides a decentralized way to query data from blockchains. Its data is exposed through a GraphQL API, making it easier to query with the GraphQL language.
+
+Learn the essential GraphQL language rules and best practices to optimize your subgraph.
+
+---
+
+## Querying a GraphQL API
+
+### The Anatomy of a GraphQL Query
+
+Unlike REST API, a GraphQL API is built upon a Schema that defines which queries can be performed.
+
+For example, a query to get a token using the `token` query will look as follows:
+
+```graphql
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+```
+
+which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+
+```json
+{
+  "token": {
+    "id": "...",
+    "owner": "..."
+  }
+}
+```
+
+GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+
+The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+
+```graphql
+query [operationName]([variableName]: [variableType]) {
+  [queryName]([argumentName]: [variableName]) {
+    # "{ ... }" express a Selection-Set, we are querying fields from `queryName`.
+    [field]
+    [field]
+  }
+}
+```
+
+## Rules for Writing GraphQL Queries
+
+- Each `queryName` must only be used once per operation.
+- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
+- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [Graph Explorer](/subgraphs/explorer/).
+- Any variable assigned to an argument must match its type.
+- In a given list of variables, each of them must be unique.
+- All defined variables must be used.
+
+> Note: Failing to follow these rules will result in an error from The Graph API.
+
+For a complete list of rules with code examples, check out [GraphQL Validations guide](/resources/release-notes/graphql-validations-migration-guide/).
+
+### Sending a query to a GraphQL API
+
+GraphQL is a language and set of conventions that transport over HTTP.
+
+It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+
+However, as mentioned in ["Querying from an Application"](/subgraphs/querying/from-an-application/), it's recommended to use `graph-client`, which supports the following unique features:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+Here's how to query The Graph with `graph-client`:
+
+```tsx
+import { execute } from '../.graphclient'
+
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+const variables = { id: '1' }
+
+async function main() {
+  const result = await execute(query, variables)
+  // `result` is fully typed!
+  console.log(result)
+}
+
+main()
+```
+
+More GraphQL client alternatives are covered in ["Querying from an Application"](/subgraphs/querying/from-an-application/).
+
+---
+
+## Best Practices
+
+### Always write static queries
+
+A common (bad) practice is to dynamically build query strings as follows:
+
+```tsx
+const id = params.id
+const fields = ['id', 'owner']
+const query = `
+query GetToken {
+  token(id: ${id}) {
+    ${fields.join('\n')}
+  }
+}
+`
+
+// Execute query...
+```
+
+While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+
+- it makes it **harder to understand** the query as a whole
+- developers are **responsible for safely sanitizing the string interpolation**
+- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
+- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+
+For this reason, it is recommended to always write queries as static strings:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!) {
+  token(id: $id) {
+    id
+    owner
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+  },
+})
+```
+
+Doing so brings **many advantages**:
+
+- **Easy to read and maintain** queries
+- The GraphQL **server handles variables sanitization**
+- **Variables can be cached** at server-level
+- **Queries can be statically analyzed by tools** (more on this in the following sections)
+
+### How to include fields conditionally in static queries
+
+You might want to include the `owner` field only on a particular condition.
+
+For this, you can leverage the `@include(if:...)` directive as follows:
+
+```tsx
+import { execute } from 'your-favorite-graphql-client'
+
+const id = params.id
+const query = `
+query GetToken($id: ID!, $includeOwner: Boolean) {
+  token(id: $id) {
+    id
+    owner @include(if: $includeOwner)
+  }
+}
+`
+
+const result = await execute(query, {
+  variables: {
+    id,
+    includeOwner: true,
+  },
+})
+```
+
+> Note: The opposite directive is `@skip(if: ...)`.
+
+### Ask for what you want
+
+GraphQL became famous for its "Ask for what you want" tagline.
+
+For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+
+- When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+- Make sure queries only fetch as many entities as you actually need. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+
+For example, in the following query:
+
+```graphql
+query listTokens {
+  tokens {
+    # will fetch up to 100 tokens
+    id
+    transactions {
+      # will fetch up to 100 transactions
+      id
+    }
+  }
+}
+```
+
+The response could contain 100 transactions for each of the 100 tokens.
+
+If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+
+### Use a single query to request multiple records
+
+By default, subgraphs have a singular entity for one record. For multiple records, use the plural entities and filter: `where: {id_in:[X,Y,Z]}` or `where: {volume_gt:100000}`
+
+Example of inefficient querying:
+
+```graphql
+query SingleRecord {
+  entity(id: X) {
+    id
+    name
+  }
+}
+query SingleRecord {
+  entity(id: Y) {
+    id
+    name
+  }
+}
+```
+
+Example of optimized querying:
+
+```graphql
+query ManyRecords {
+  entities(where: { id_in: [X, Y] }) {
+    id
+    name
+  }
+}
+```
+
+### Combine multiple queries in a single request
+
+Your application might require querying multiple types of data as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const tokensQuery = `
+query GetTokens {
+  tokens(first: 50) {
+    id
+    owner
+  }
+}
+`
+const countersQuery = `
+query GetCounters {
+  counters {
+    id
+    value
+  }
+}
+`
+
+const [tokens, counters] = Promise.all(
+  [
+    tokensQuery,
+    countersQuery,
+  ].map(execute)
+)
+```
+
+While this implementation is totally valid, it will require two round trips with the GraphQL API.
+
+Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+
+```graphql
+import { execute } from "your-favorite-graphql-client"
+
+const query = `
+query GetTokensandCounters {
+  tokens(first: 50) {
+    id
+    owner
+  }
+  counters {
+    id
+    value
+  }
+}
+`
+
+const  { result: { tokens, counters } } = execute(query)
+```
+
+This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+
+### Leverage GraphQL Fragments
+
+A helpful feature to write GraphQL queries is GraphQL Fragment.
+
+Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      id
+      active
+      status
+    }
+    oldDelegate {
+      id
+      active
+      status
+    }
+  }
+}
+```
+
+Such repeated fields (`id`, `active`, `status`) bring many issues:
+
+- More extensive queries become harder to read.
+- When using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+
+A refactored version of the query would be the following:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...DelegateItem
+    }
+    oldDelegate {
+      ...DelegateItem
+    }
+  }
+}
+
+# we define a fragment (subtype) on Transcoder
+# to factorize repeated fields in the query
+fragment DelegateItem on Transcoder {
+  id
+  active
+  status
+}
+```
+
+Using GraphQL `fragment` will improve readability (especially at scale) and result in better TypeScript types generation.
+
+When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+
+### GraphQL Fragment do's and don'ts
+
+### Fragment base must be a type
+
+A Fragment cannot be based on a non-applicable type, in short, **on type not having fields**:
+
+```graphql
+fragment MyFragment on BigInt {
+  # ...
+}
+```
+
+`BigInt` is a **scalar** (native "plain" type) that cannot be used as a fragment's base.
+
+#### How to spread a Fragment
+
+Fragments are defined on specific types and should be used accordingly in queries.
+
+Example:
+
+```graphql
+query {
+  bondEvents {
+    id
+    newDelegate {
+      ...VoteItem # Error! `VoteItem` cannot be spread on `Transcoder` type
+    }
+    oldDelegate {
+      ...VoteItem
+    }
+  }
+}
+
+fragment VoteItem on Vote {
+  id
+  voter
+}
+```
+
+`newDelegate` and `oldDelegate` are of type `Transcoder`.
+
+It is not possible to spread a fragment of type `Vote` here.
+
+#### Define Fragment as an atomic business unit of data
+
+GraphQL `Fragment`s must be defined based on their usage.
+
+For most use-case, defining one fragment per type (in the case of repeated fields usage or type generation) is sufficient.
+
+Here is a rule of thumb for using fragments:
+
+- When fields of the same type are repeated in a query, group them in a `Fragment`.
+- When similar but different fields are repeated, create multiple fragments, for instance:
+
+```graphql
+# base fragment (mostly used in listing)
+fragment Voter on Vote {
+  id
+  voter
+}
+
+# extended fragment (when querying a detailed view of a vote)
+fragment VoteWithPoll on Vote {
+  id
+  voter
+  choiceID
+  poll {
+    id
+    proposal
+  }
+}
+```
+
+---
+
+## The Essential Tools
+
+### GraphQL web-based explorers
+
+Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+
+If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altairgraphql.dev/) and [GraphiQL](https://graphiql-online.com/graphiql).
+
+### GraphQL Linting
+
+In order to keep up with the mentioned above best practices and syntactic rules, it is highly recommended to use the following workflow and IDE tools.
+
+**GraphQL ESLint**
+
+[GraphQL ESLint](https://the-guild.dev/graphql/eslint/docs/getting-started) will help you stay on top of GraphQL best practices with zero effort.
+
+[Setup the "operations-recommended"](https://the-guild.dev/graphql/eslint/docs/configs) config will enforce essential rules such as:
+
+- `@graphql-eslint/fields-on-correct-type`: is a field used on a proper type?
+- `@graphql-eslint/no-unused variables`: should a given variable stay unused?
+- and more!
+
+This will allow you to **catch errors without even testing queries** on the playground or running them in production!
+
+### IDE plugins
+
+**VSCode and GraphQL**
+
+The [GraphQL VSCode extension](https://marketplace.visualstudio.com/items?itemName=GraphQL.vscode-graphql) is an excellent addition to your development workflow to get:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+- Go to definition for fragments and input types
+
+If you are using `graphql-eslint`, the [ESLint VSCode extension](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) is a must-have to visualize errors and warnings inlined in your code correctly.
+
+**WebStorm/Intellij and GraphQL**
+
+The [JS GraphQL plugin](https://plugins.jetbrains.com/plugin/8097-graphql/) will significantly improve your experience while working with GraphQL by providing:
+
+- Syntax highlighting
+- Autocomplete suggestions
+- Validation against schema
+- Snippets
+
+For more information on this topic, check out the [WebStorm article](https://blog.jetbrains.com/webstorm/2019/04/featured-plugin-js-graphql/) which showcases all the plugin's main features.

From b3e5ef1b9ec5037a773e34fe2a7bfb4319aac947 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:26 -0500
Subject: [PATCH 2056/3820] New translations distributed-systems.mdx (Romanian)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/ro/subgraphs/querying/distributed-systems.mdx b/website/pages/ro/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..85337206bfd3
--- /dev/null
+++ b/website/pages/ro/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Distributed Systems
+---
+
+The Graph is a protocol implemented as a distributed system.
+
+Connections fail. Requests arrive out of order. Different computers with out-of-sync clocks and states process related requests. Servers restart. Re-orgs happen between requests. These problems are inherent to all distributed systems but are exacerbated in systems operating at a global scale.
+
+Consider this example of what may occur if a client polls an Indexer for the latest data during a re-org.
+
+1. Indexer ingests block 8
+2. Request served to the client for block 8
+3. Indexer ingests block 9
+4. Indexer ingests block 10A
+5. Request served to the client for block 10A
+6. Indexer detects reorg to 10B and rolls back 10A
+7. Request served to the client for block 9
+8. Indexer ingests block 10B
+9. Indexer ingests block 11
+10. Request served to the client for block 11
+
+From the point of view of the Indexer, things are progressing forward logically. Time is moving forward, though we did have to roll back an uncle block and play the block under consensus forward on top of it. Along the way, the Indexer serves requests using the latest state it knows about at that time.
+
+From the point of view of the client, however, things appear chaotic. The client observes that the responses were for blocks 8, 10, 9, and 11 in that order. We call this the "block wobble" problem. When a client experiences block wobble, data may appear to contradict itself over time. The situation worsens when we consider that Indexers do not all ingest the latest blocks simultaneously, and your requests may be routed to multiple Indexers.
+
+It is the responsibility of the client and server to work together to provide consistent data to the user. Different approaches must be used depending on the desired consistency as there is no one right program for every problem.
+
+Reasoning through the implications of distributed systems is hard, but the fix may not be! We've established APIs and patterns to help you navigate some common use-cases. The following examples illustrate those patterns but still elide details required by production code (like error handling and cancellation) to not obfuscate the main ideas.
+
+## Polling for updated data
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Fetching a set of related items
+
+Another use-case is retrieving a large set or, more generally, retrieving related items across multiple requests. Unlike the polling case (where the desired consistency was to move forward in time), the desired consistency is for a single point in time.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Note that in case of a re-org, the client will need to retry from the first request to update the block hash to a non-uncle block.

From 7ad3b5ee241f534348a75577ce718fac062806d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:28 -0500
Subject: [PATCH 2057/3820] New translations distributed-systems.mdx (French)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/fr/subgraphs/querying/distributed-systems.mdx b/website/pages/fr/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..7c1f4526f7dc
--- /dev/null
+++ b/website/pages/fr/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Systèmes distribués
+---
+
+Le graph est un protocole mis en œuvre sous la forme d'un système distribué.
+
+Les connexions échouent. Les demandes arrivent dans le désordre. Différents ordinateurs dont les horloges et les états ne sont pas synchronisés traitent les demandes correspondantes. Les serveurs redémarrent. Des réorgs se produisent entre les demandes. Ces problèmes sont inhérents à tous les systèmes distribués, mais ils sont exacerbés dans les systèmes fonctionnant à l'échelle mondiale.
+
+Considérez cet exemple de ce qui peut se produire si un client interroge un indexeur pour connaître les dernières données lors d'une réorganisation.
+
+1. L'indexeur ingère le bloc 8
+2. Demande transmise au client pour le bloc 8
+3. L'indexeur ingère le bloc 9
+4. L'indexeur ingère le bloc 10A
+5. Demande transmise au client pour le bloc 10A
+6. L'indexeur détecte la réorganisation à 10B et annule 10A
+7. Demande transmise au client pour le bloc 9
+8. L'indexeur ingère le bloc 10B
+9. L'indexeur ingère le bloc 11
+10. Demande transmise au client pour le bloc 11
+
+Du point de vue de l'indexeur, les choses progressent logiquement. Le temps avance, bien que nous ayons dû revenir en arrière sur un bloc oncle et faire avancer le bloc faisant l'objet d'un consensus par-dessus. En cours de route, l'indexeur répond aux demandes en utilisant le dernier état dont il a connaissance à ce moment-là.
+
+Mais du point de vue du client, les choses semblent chaotiques. Le client observe que les réponses concernaient les blocs 8, 10, 9 et 11 dans cet ordre. Nous appelons cela le problème de « l’oscillation du bloc ». Lorsqu'un client subit une oscillation de blocage, les données peuvent sembler se contredire au fil du temps. La situation s'aggrave lorsque l'on considère que les indexeurs n'ingèrent pas tous les derniers blocs simultanément et que vos requêtes peuvent être acheminées vers plusieurs indexeurs.
+
+Il est de la responsabilité du client et du serveur de travailler ensemble pour fournir des données cohérentes à l'utilisateur. Différentes approches doivent être utilisées en fonction de la cohérence souhaitée, car il n’existe pas de programme adapté à chaque problème.
+
+Il est difficile de raisonner sur les implications des systèmes distribués, mais la solution ne l'est pas nécessairement ! Nous avons établi des API et des modèles pour vous aider à naviguer dans certains cas d'utilisation courants. Les exemples suivants illustrent ces modèles tout en éludant les détails requis par le code de production (comme la gestion des erreurs et l'annulation) afin de ne pas obscurcir les idées principales.
+
+## Demande de données actualisées
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Récupérer un ensemble d'éléments liés
+
+Un autre cas d'utilisation est la récupération d'un grand ensemble ou, plus généralement, la récupération d'éléments liés entre plusieurs requêtes. Contrairement au cas des sondages (où la cohérence souhaitée était d'avancer dans le temps), la cohérence souhaitée est pour un seul point dans le temps.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Il convient de noter qu'en cas de réorganisation, le client devra réessayer à partir de la première demande de mise à jour du hachage du bloc vers un bloc qui n'a pas été supprimé.

From ffd087934998c0888428d2a94339d9ac94760d57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:29 -0500
Subject: [PATCH 2058/3820] New translations distributed-systems.mdx (Spanish)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/es/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/es/subgraphs/querying/distributed-systems.mdx b/website/pages/es/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..037048e73f08
--- /dev/null
+++ b/website/pages/es/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Sistemas Distribuidos
+---
+
+The Graph es un protocolo implementado como un sistema distribuido.
+
+Las conexiones fallan. Las solicitudes llegan fuera de orden. Diferentes computadoras con relojes y estados desincronizados procesan solicitudes relacionadas. Los servidores se reinician. Las reorganizaciones se producen entre las solicitudes. Estos problemas son inherentes a todos los sistemas distribuidos, pero se agravan en los sistemas que funcionan a escala mundial.
+
+Considera este ejemplo de lo que puede ocurrir si un cliente pregunta a un Indexador por los últimos datos durante una reorganización.
+
+1. El indexador ingiere el bloque 8
+2. Solicitud servida al cliente para el bloque 8
+3. El indexador ingiere el bloque 9
+4. El indexador ingiere el bloque 10A
+5. Solicitud servida al cliente para el bloque 10A
+6. El indexador detecta la reorganización a 10B y revierte 10A
+7. Solicitud servida al cliente para el bloque 9
+8. El indexador ingiere el bloque 10B
+9. El indexador ingiere el bloque 11
+10. Solicitud servida al cliente para el bloque 11
+
+Desde el punto de vista del indexador, las cosas avanzan lógicamente. El tiempo avanza, aunque tuvimos que revertir un bloque uncle y jugar el bloque bajo consenso hacia adelante encima de él. En el camino, el Indexador sirve las peticiones utilizando el último estado que conoce en ese momento.
+
+Sin embargo, desde el punto de vista del cliente, las cosas parecen caóticas. El cliente observa que las respuestas fueron para los bloques 8, 10, 9 y 11 en ese orden. Lo llamamos el problema del "block wobble" (bamboleo del bloque). Cuando un cliente experimenta un bamboleo de bloques, los datos pueden parecer contradecirse a lo largo del tiempo. La situación se agrava si tenemos en cuenta que no todos los indexadores ingieren los últimos bloques de forma simultánea, y tus peticiones pueden ser dirigidas a varios indexadores.
+
+Es responsabilidad del cliente y del servidor trabajar juntos para proporcionar datos coherentes al usuario. Hay que utilizar diferentes enfoques en función de la consistencia deseada, ya que no existe un programa adecuado para todos los problemas.
+
+Razonar las implicaciones de los sistemas distribuidos es difícil, pero la solución puede no serlo! Hemos establecido APIs y patrones para ayudarte a navegar por algunos casos de uso comunes. Los siguientes ejemplos ilustran estos patrones pero eluden los detalles requeridos por el código de producción (como el manejo de errores y la cancelación) para no ofuscar las ideas principales.
+
+## Sondeo de datos actualizados
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Obtención de un conjunto de elementos relacionados
+
+Otro caso de uso es la recuperación de un conjunto grande o, más generalmente, la recuperación de elementos relacionados a través de múltiples solicitudes. A diferencia del caso del sondeo (en el que la consistencia deseada era avanzar en el tiempo), la consistencia deseada es para un único punto en el tiempo.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Ten en cuenta que en caso de reorganización, el cliente tendrá que reintentar desde la primera solicitud para actualizar el hash del bloque a un bloque no-uncle.

From d554808afbbb2baacadc30349eba6d37f88c42ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:30 -0500
Subject: [PATCH 2059/3820] New translations distributed-systems.mdx (Arabic)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/ar/subgraphs/querying/distributed-systems.mdx b/website/pages/ar/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..885bfec84e80
--- /dev/null
+++ b/website/pages/ar/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: الانظمة الموزعة
+---
+
+The Graph هو بروتوكول يتم تنفيذه كنظام موزع.
+
+فشل الاتصالات،ووصول الطلبات خارج الترتيب،وأجهزة الكمبيوتر المختلفة ذات الساعات غير المتزامنة ، والخوادم التي تعيد التشغيل ،وحدوث عمليات إعادة التنظيم بين الطلبات. هذه المشاكل متأصلة في جميع الأنظمة الموزعة ولكنها تتفاقم في الأنظمة التي تعمل على نطاق عالمي.
+
+ضع في اعتبارك هذا المثال لما قد يحدث إذا قام العميل بـ polls للمفهرس للحصول على أحدث البيانات أثناء إعادة التنظيم.
+
+1. المفهرس يأخذ الكتلة 8
+2. تقديم الطلب للعميل لـ block 8
+3. المفهرس يأخذ block 9
+4. المفهرس يأخذ block 10A
+5. تقديم الطلب للعميل لـ block 10A
+6. يكتشف المفهرس عملية التنظيم لـ 10B ويسترجع 10A
+7. تقديم الطلب للعميل لـ block 9
+8. المفهرس يأخذ block 10B
+9. المفهرس يأخذ block 11
+10. تقديم الطلب للعميل لـ block 11
+
+من وجهة نظر المفهرس ، تسير الأمور إلى الأمام بشكل منطقي. حيث أن الوقت يمضي قدما ، على الرغم من أننا اضطررنا إلى التراجع عن كتلة الـ uncle وتشغيل الكتلة وفقا للاتفاق ، ويقدم المفهرس الطلبات باستخدام أحدث حالة يعرفها في ذلك الوقت.
+
+لكن من وجهة نظر العميل ، تبدو الأمور مشوشة. يلاحظ العميل أن الردود كانت للكتل 8 و 10 و 9 و 11 بهذا الترتيب. نسمي هذا مشكلة "تذبذب الكتلة". عندما يواجه العميل تذبذبا في الكتلة ، فقد تظهر البيانات متناقضة مع نفسها بمرور الوقت. يزداد الموقف سوءا عندما نعتبر أن المفهرسين لا يستوعبون جميع الكتل الأخيرة في وقت واحد ، وقد يتم توجيه طلباتك إلى عدة مفهرسين.
+
+تقع على عاتق العميل والخادم مسؤولية العمل معا لتوفير بيانات متسقة للمستخدم. يجب استخدام طرق مختلفة اعتمادا على الاتساق المطلوب حيث لا يوجد برنامج واحد مناسب لكل مشكلة.
+
+الاستنتاج من خلال الآثار المترتبة على الأنظمة الموزعة أمر صعب ، لكن الإصلاح قد لا يكون كذلك! لقد أنشأنا APIs وأنماطا لمساعدتك على تصفح بعض حالات الاستخدام الشائعة. توضح الأمثلة التالية هذه الأنماط ولكنها لا تزال تتجاهل التفاصيل التي يتطلبها كود الإنتاج (مثل معالجة الأخطاء والإلغاء) حتى لا يتم تشويش الأفكار الرئيسية.
+
+## Polling للبيانات المحدثة
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## جلب مجموعة من العناصر المرتبطة
+
+حالة أخرى هي جلب مجموعة كبيرة أو بشكل عام جلب العناصر المرتبطة عبر طلبات متعددة. على عكس حالة الـ polling (حيث كان التناسق المطلوب هو المضي قدما في الزمن) ، فإن التناسق المطلوب هو لنقطة واحدة في الزمن.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+لاحظ أنه في حالة إعادة التنظيم ، سيحتاج العميل إلى إعادة المحاولة من الطلب الأول لتحديث hash الكتلة إلى كتلة non-uncle.

From a93803fd1f6d477271dfe9c557c49f58aa2d4bf8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:31 -0500
Subject: [PATCH 2060/3820] New translations distributed-systems.mdx (Czech)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/cs/subgraphs/querying/distributed-systems.mdx b/website/pages/cs/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..8ba61d134a48
--- /dev/null
+++ b/website/pages/cs/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Distribuované systémy
+---
+
+Graf je protokol implementovaný jako distribuovaný systém.
+
+Připojení selhávají. Požadavky přicházejí mimo pořadí. Různé počítače s nesynchronizovanými hodinami a stavy zpracovávají související požadavky. Servery se restartují. Mezi požadavky dochází k opětovným Re-orgs. Tyto problémy jsou vlastní všem distribuovaným systémům, ale v systémech pracujících v globálním měřítku se ještě zhoršují.
+
+Vezměme si tento příklad toho, co může nastat, pokud se klient dotazuje indexeru na nejnovější data během re-org.
+
+1. Indexer zpracovat blok 8
+2. Požadavek doručený klientovi pro blok 8
+3. Indexer požívá blok 9
+4. Indexer požívá blok 10A
+5. Požadavek doručený klientovi pro blok 10A
+6. Indexer zjistí reorg na 10B a vrátí zpět 10A
+7. Požadavek doručený klientovi pro blok 9
+8. Indexer požívá blok 10B
+9. Indexer požívá blok 11
+10. Požadavek doručený klientovi pro blok 11
+
+Z pohledu indexátora postupují věci logicky vpřed. Čas se posouvá vpřed, i když jsme museli vrátit blok strýce a přehrát na něj blok v rámci konsensu vpřed. Po cestě Indexer obsluhuje požadavky pomocí nejnovějšího stavu, o kterém v danou chvíli ví.
+
+Z pohledu klienta se však situace jeví jako chaotická. Klient si všimne, že odpovědi se týkaly bloků 8, 10, 9 a 11 v tomto pořadí. Tomu říkáme problém "kmitání bloků". Když klient zažije blokové kmitání, může se zdát, že si data v průběhu času odporují. Situace se ještě zhorší, když uvážíme, že všechny indexátory nepřijímají nejnovější bloky současně a vaše požadavky mohou být směrovány k více indexátorům.
+
+Je odpovědností klienta a serveru, aby spolupracovali a poskytovali uživateli konzistentní data. V závislosti na požadované konzistenci je třeba použít různé přístupy, protože pro každý problém neexistuje jeden správný program.
+
+Uvažovat o důsledcích distribuovaných systémů je těžké, ale náprava možná není! Vytvořili jsme API a vzory, které vám pomohou orientovat se v některých běžných případech použití. Následující příklady ilustrují tyto vzory, ale přesto opomíjejí detaily vyžadované produkčním kódem (jako je zpracování chyb a zrušení), aby nebyly zastřeny hlavní myšlenky.
+
+## Polling for updated data
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Získání sady souvisejících položek
+
+Dalším případem použití je načítání velkého souboru nebo obecněji načítání souvisejících položek ve více požadavcích. Na rozdíl od případu dotazování (kde byla požadovaná konzistence pro posun v čase) je požadovaná konzistence pro jeden bod v čase.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Všimněte si, že v případě reorganizace bude muset klient zopakovat první požadavek na aktualizaci hashe bloku na blok, který není strýčkem.

From 8b35d192d9b973ea9ad385a432e78f1cf2a51b41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:32 -0500
Subject: [PATCH 2061/3820] New translations distributed-systems.mdx (German)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/de/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/de/subgraphs/querying/distributed-systems.mdx b/website/pages/de/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..85337206bfd3
--- /dev/null
+++ b/website/pages/de/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Distributed Systems
+---
+
+The Graph is a protocol implemented as a distributed system.
+
+Connections fail. Requests arrive out of order. Different computers with out-of-sync clocks and states process related requests. Servers restart. Re-orgs happen between requests. These problems are inherent to all distributed systems but are exacerbated in systems operating at a global scale.
+
+Consider this example of what may occur if a client polls an Indexer for the latest data during a re-org.
+
+1. Indexer ingests block 8
+2. Request served to the client for block 8
+3. Indexer ingests block 9
+4. Indexer ingests block 10A
+5. Request served to the client for block 10A
+6. Indexer detects reorg to 10B and rolls back 10A
+7. Request served to the client for block 9
+8. Indexer ingests block 10B
+9. Indexer ingests block 11
+10. Request served to the client for block 11
+
+From the point of view of the Indexer, things are progressing forward logically. Time is moving forward, though we did have to roll back an uncle block and play the block under consensus forward on top of it. Along the way, the Indexer serves requests using the latest state it knows about at that time.
+
+From the point of view of the client, however, things appear chaotic. The client observes that the responses were for blocks 8, 10, 9, and 11 in that order. We call this the "block wobble" problem. When a client experiences block wobble, data may appear to contradict itself over time. The situation worsens when we consider that Indexers do not all ingest the latest blocks simultaneously, and your requests may be routed to multiple Indexers.
+
+It is the responsibility of the client and server to work together to provide consistent data to the user. Different approaches must be used depending on the desired consistency as there is no one right program for every problem.
+
+Reasoning through the implications of distributed systems is hard, but the fix may not be! We've established APIs and patterns to help you navigate some common use-cases. The following examples illustrate those patterns but still elide details required by production code (like error handling and cancellation) to not obfuscate the main ideas.
+
+## Polling for updated data
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Fetching a set of related items
+
+Another use-case is retrieving a large set or, more generally, retrieving related items across multiple requests. Unlike the polling case (where the desired consistency was to move forward in time), the desired consistency is for a single point in time.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Note that in case of a re-org, the client will need to retry from the first request to update the block hash to a non-uncle block.

From 56aa288bb53048d5670878a21b5659b06484349d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:33 -0500
Subject: [PATCH 2062/3820] New translations distributed-systems.mdx (Italian)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/it/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/it/subgraphs/querying/distributed-systems.mdx b/website/pages/it/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..1c265ac6cd2c
--- /dev/null
+++ b/website/pages/it/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Sistemi distribuiti
+---
+
+The Graph è un protocollo implementato come sistema distribuito.
+
+Le connessioni falliscono. Le richieste arrivano in ordine sparso. Computer diversi con orologi e stati non sincronizzati elaborano richieste correlate. I server si riavviano. Tra una richiesta e l'altra si verificano delle riorganizzazioni. Questi problemi sono inerenti a tutti i sistemi distribuiti, ma sono esacerbati nei sistemi che operano su scala globale.
+
+Si consideri questo esempio di ciò che può accadere se un cliente interroga un Indexer per ottenere i dati più recenti durante una riorganizzazione.
+
+1. L'Indexer inserisce il blocco 8
+2. Richiesta servita al cliente per il blocco 8
+3. L'Indexer inserisce il blocco 9
+4. L'Indexer inserisce il blocco 10A
+5. Richiesta servita al cliente per il blocco 10A
+6. L'Indexer rileva la riorganizzazione a 10B e fa rollback di 10A
+7. Richiesta servita al cliente per il blocco 9
+8. L'Indexer inserisce il blocco 10B
+9. L'Indexer inserisce il blocco 11
+10. Richiesta servita al cliente per il blocco 11
+
+Dal punto di vista dell'Indexer, le cose stanno procedendo in modo logico. Il tempo sta avanzando, anche se abbiamo dovuto fare un rollback di un blocco sconosciuto e riprodurre il blocco sotto consenso in avanti sopra di esso. Lungo il percorso, l'Indexer serve le richieste utilizzando lo stato più recente che conosce in quel momento.
+
+Dal punto di vista del cliente, tuttavia, la situazione appare caotica. Il cliente osserva che le risposte sono state date per i blocchi 8, 10, 9 e 11 in questo ordine. Questo è il cosiddetto problema del "block wobble". Quando un cliente sperimenta il block wobble, i dati possono sembrare contraddirsi nel tempo. La situazione peggiora se si considera che gli Indexer non ingeriscono tutti i blocchi più recenti contemporaneamente e le richieste possono essere indirizzate a più Indexer.
+
+È responsabilità del cliente e del server lavorare insieme per fornire dati coerenti all'utente. È necessario utilizzare approcci diversi a seconda della coerenza desiderata, poiché non esiste un unico programma giusto per ogni problema.
+
+Ragionare sulle implicazioni dei sistemi distribuiti è difficile, ma la soluzione potrebbe non esserlo! Abbiamo creato delle API e dei modelli per aiutarvi a navigare in alcuni casi d'uso comuni. Gli esempi che seguono illustrano questi modelli, ma eludono i dettagli richiesti dal codice di produzione (come la gestione degli errori e la cancellazione) per non offuscare le idee principali.
+
+## Polling per i dati aggiornati
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Recuperare una serie di elementi correlati
+
+Un altro caso d'uso è il recupero di un grande serie oppure, più in generale, il recupero di elementi correlati tra più richieste. A differenza del caso del polling (in cui la consistenza desiderata era quella di andare avanti nel tempo), la consistenza desiderata riguarda un singolo punto nel tempo.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Si noti che, in caso di riorganizzazione, il cliente dovrà riprovare a partire dalla prima richiesta di aggiornamento dell'hash del blocco a un blocco non-uncle.

From ef4610281e7cb05cd422a6e0ad6c7ac9ebb54b20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:34 -0500
Subject: [PATCH 2063/3820] New translations distributed-systems.mdx (Japanese)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/ja/subgraphs/querying/distributed-systems.mdx b/website/pages/ja/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..9eb304f11024
--- /dev/null
+++ b/website/pages/ja/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: 分散システム
+---
+
+グラフは、分散システムとして実装されたプロトコルです。
+
+接続に失敗する。リクエストの順番が狂う。時計や状態が同期していない別のコンピュータが、関連するリクエストを処理する。サーバーが再起動する。リクエストとリクエストの間に「再衝突」が起こる。これらの問題は、すべての分散システムに固有のものですが、グローバルな規模で運用されているシステムでは、さらに悪化します。
+
+re-org 中にクライアントがインデクサに最新のデータを要求した場合の例を考えてみましょう。
+
+1. インデクサーがブロック 8 を取り込む
+2. クライアントにブロック 8 のリクエストを送信
+3. インデクサーがブロック 9 を取り込む
+4. インデクサーがブロック 10A を取り込む
+5. ブロック 10A のクライアントにリクエストが提供される
+6. インデクサーは 10B への reorg を検出し、10A をロールバックする
+7. ブロック 9 に対してクライアントへのリクエストを提供
+8. インデクサーがブロック 10B を取り込む
+9. インデクサーがブロック 11 を取り込む
+10. ブロック 11 のクライアントにリクエストを提供
+
+インデクサーの視点では、物事が論理的に進んでいます。時間は進んでいますが、アンクルブロックを巻き戻して、その上にコンセンサス中のブロックを再生する必要がありました。その間、インデクサーは、その時点で知っている最新の状態を使ってリクエストに対応します。
+
+クライアントから見ると、事態は混沌としているように見えます。クライアントは、ブロック 8、10、9、11 の順に応答があったことを確認します。これを「block wobble」問題と呼んでいます。block wobble が発生すると、データが時間とともに矛盾していくように見えることがあります。インデクサがすべての最新ブロックを同時に取り込むわけではないことを考えると、状況は悪化し、クライアントのリクエストは複数のインデクサーにルーティングされる可能性があります。
+
+一貫性のあるデータをユーザーに提供するには、クライアントとサーバーが協力して取り組む必要があります。すべての問題に対して正しいプログラムは存在しないため、必要な一貫性に応じて異なるアプローチを使用する必要があります。
+
+分散システムの意味を理解するのは難しいですが、解決するのは難しいことではありません。私たちは、一般的な使用例をナビゲートするための API とパターンを確立しました。以下の例では、これらのパターンを説明していますが、本番コードで必要とされる詳細（エラー処理やキャンセルなど）は省略していますので、主旨を理解していただくことはできません。
+
+## 更新データのポーリング
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## 関連するアイテムのセットの取得
+
+もうひとつのケースは、大規模なセットを取得することで、一般的には、複数のリクエストにわたって関連するアイテムを取得するケースです。ポーリングの場合（時間を進めて一貫性を保つ必要があった）とは異なり、必要な一貫性はある時点でのものです。
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+なお、re-org が発生した場合、クライアントは最初のリクエストから再試行して、ブロックハッシュをアンクルではないブロックに更新する必要があります。

From 3a05b6455c55710d9d941d0bd0d76ffefda5d0e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:35 -0500
Subject: [PATCH 2064/3820] New translations distributed-systems.mdx (Korean)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/ko/subgraphs/querying/distributed-systems.mdx b/website/pages/ko/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..85337206bfd3
--- /dev/null
+++ b/website/pages/ko/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Distributed Systems
+---
+
+The Graph is a protocol implemented as a distributed system.
+
+Connections fail. Requests arrive out of order. Different computers with out-of-sync clocks and states process related requests. Servers restart. Re-orgs happen between requests. These problems are inherent to all distributed systems but are exacerbated in systems operating at a global scale.
+
+Consider this example of what may occur if a client polls an Indexer for the latest data during a re-org.
+
+1. Indexer ingests block 8
+2. Request served to the client for block 8
+3. Indexer ingests block 9
+4. Indexer ingests block 10A
+5. Request served to the client for block 10A
+6. Indexer detects reorg to 10B and rolls back 10A
+7. Request served to the client for block 9
+8. Indexer ingests block 10B
+9. Indexer ingests block 11
+10. Request served to the client for block 11
+
+From the point of view of the Indexer, things are progressing forward logically. Time is moving forward, though we did have to roll back an uncle block and play the block under consensus forward on top of it. Along the way, the Indexer serves requests using the latest state it knows about at that time.
+
+From the point of view of the client, however, things appear chaotic. The client observes that the responses were for blocks 8, 10, 9, and 11 in that order. We call this the "block wobble" problem. When a client experiences block wobble, data may appear to contradict itself over time. The situation worsens when we consider that Indexers do not all ingest the latest blocks simultaneously, and your requests may be routed to multiple Indexers.
+
+It is the responsibility of the client and server to work together to provide consistent data to the user. Different approaches must be used depending on the desired consistency as there is no one right program for every problem.
+
+Reasoning through the implications of distributed systems is hard, but the fix may not be! We've established APIs and patterns to help you navigate some common use-cases. The following examples illustrate those patterns but still elide details required by production code (like error handling and cancellation) to not obfuscate the main ideas.
+
+## Polling for updated data
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Fetching a set of related items
+
+Another use-case is retrieving a large set or, more generally, retrieving related items across multiple requests. Unlike the polling case (where the desired consistency was to move forward in time), the desired consistency is for a single point in time.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Note that in case of a re-org, the client will need to retry from the first request to update the block hash to a non-uncle block.

From fc0749b7d596178863ffb4cd9d8b5e129491555a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:36 -0500
Subject: [PATCH 2065/3820] New translations distributed-systems.mdx (Dutch)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/nl/subgraphs/querying/distributed-systems.mdx b/website/pages/nl/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..85337206bfd3
--- /dev/null
+++ b/website/pages/nl/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Distributed Systems
+---
+
+The Graph is a protocol implemented as a distributed system.
+
+Connections fail. Requests arrive out of order. Different computers with out-of-sync clocks and states process related requests. Servers restart. Re-orgs happen between requests. These problems are inherent to all distributed systems but are exacerbated in systems operating at a global scale.
+
+Consider this example of what may occur if a client polls an Indexer for the latest data during a re-org.
+
+1. Indexer ingests block 8
+2. Request served to the client for block 8
+3. Indexer ingests block 9
+4. Indexer ingests block 10A
+5. Request served to the client for block 10A
+6. Indexer detects reorg to 10B and rolls back 10A
+7. Request served to the client for block 9
+8. Indexer ingests block 10B
+9. Indexer ingests block 11
+10. Request served to the client for block 11
+
+From the point of view of the Indexer, things are progressing forward logically. Time is moving forward, though we did have to roll back an uncle block and play the block under consensus forward on top of it. Along the way, the Indexer serves requests using the latest state it knows about at that time.
+
+From the point of view of the client, however, things appear chaotic. The client observes that the responses were for blocks 8, 10, 9, and 11 in that order. We call this the "block wobble" problem. When a client experiences block wobble, data may appear to contradict itself over time. The situation worsens when we consider that Indexers do not all ingest the latest blocks simultaneously, and your requests may be routed to multiple Indexers.
+
+It is the responsibility of the client and server to work together to provide consistent data to the user. Different approaches must be used depending on the desired consistency as there is no one right program for every problem.
+
+Reasoning through the implications of distributed systems is hard, but the fix may not be! We've established APIs and patterns to help you navigate some common use-cases. The following examples illustrate those patterns but still elide details required by production code (like error handling and cancellation) to not obfuscate the main ideas.
+
+## Polling for updated data
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Fetching a set of related items
+
+Another use-case is retrieving a large set or, more generally, retrieving related items across multiple requests. Unlike the polling case (where the desired consistency was to move forward in time), the desired consistency is for a single point in time.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Note that in case of a re-org, the client will need to retry from the first request to update the block hash to a non-uncle block.

From 213c5562d00f2fcddd5ffd34cbd4d8d104974bfc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:37 -0500
Subject: [PATCH 2066/3820] New translations distributed-systems.mdx (Polish)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/pl/subgraphs/querying/distributed-systems.mdx b/website/pages/pl/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..85337206bfd3
--- /dev/null
+++ b/website/pages/pl/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Distributed Systems
+---
+
+The Graph is a protocol implemented as a distributed system.
+
+Connections fail. Requests arrive out of order. Different computers with out-of-sync clocks and states process related requests. Servers restart. Re-orgs happen between requests. These problems are inherent to all distributed systems but are exacerbated in systems operating at a global scale.
+
+Consider this example of what may occur if a client polls an Indexer for the latest data during a re-org.
+
+1. Indexer ingests block 8
+2. Request served to the client for block 8
+3. Indexer ingests block 9
+4. Indexer ingests block 10A
+5. Request served to the client for block 10A
+6. Indexer detects reorg to 10B and rolls back 10A
+7. Request served to the client for block 9
+8. Indexer ingests block 10B
+9. Indexer ingests block 11
+10. Request served to the client for block 11
+
+From the point of view of the Indexer, things are progressing forward logically. Time is moving forward, though we did have to roll back an uncle block and play the block under consensus forward on top of it. Along the way, the Indexer serves requests using the latest state it knows about at that time.
+
+From the point of view of the client, however, things appear chaotic. The client observes that the responses were for blocks 8, 10, 9, and 11 in that order. We call this the "block wobble" problem. When a client experiences block wobble, data may appear to contradict itself over time. The situation worsens when we consider that Indexers do not all ingest the latest blocks simultaneously, and your requests may be routed to multiple Indexers.
+
+It is the responsibility of the client and server to work together to provide consistent data to the user. Different approaches must be used depending on the desired consistency as there is no one right program for every problem.
+
+Reasoning through the implications of distributed systems is hard, but the fix may not be! We've established APIs and patterns to help you navigate some common use-cases. The following examples illustrate those patterns but still elide details required by production code (like error handling and cancellation) to not obfuscate the main ideas.
+
+## Polling for updated data
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Fetching a set of related items
+
+Another use-case is retrieving a large set or, more generally, retrieving related items across multiple requests. Unlike the polling case (where the desired consistency was to move forward in time), the desired consistency is for a single point in time.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Note that in case of a re-org, the client will need to retry from the first request to update the block hash to a non-uncle block.

From 3f759ed2f59d3279f5a0eab49823b8ae7e20be56 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:38 -0500
Subject: [PATCH 2067/3820] New translations distributed-systems.mdx
 (Portuguese)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/pt/subgraphs/querying/distributed-systems.mdx b/website/pages/pt/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..8079b790e97a
--- /dev/null
+++ b/website/pages/pt/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Sistemas Distribuídos
+---
+
+O The Graph é um protocolo implementado como um sistema distribuído.
+
+Conexões falham. Pedidos chegam fora da ordem. Computadores diferentes, com relógios e estados fora de sincronia, processam pedidos relacionados. Servidores reiniciam. Reorganizações acontecem entre pedidos. Estes problemas são inerentes a todos os sistemas distribuídos, mas pioram em sistemas que operam em uma escala global.
+
+Considere este exemplo do que pode ocorrer se um cliente consultar um Indexador sobre os dados mais recentes durante uma reorganização.
+
+1. Indexador ingere o bloco 8
+2. Pedido servido ao cliente para o bloco 8
+3. Indexador ingere o bloco 9
+4. Indexador ingere o bloco 10A
+5. Pedido servido ao cliente para o bloco 10A
+6. Indexador deteta reorganização ao 10B e faz rollback para o 10A
+7. Pedido servido ao cliente para o bloco 9
+8. Indexador ingere o bloco 10B
+9. Indexador ingere o bloco 11
+10. Pedido servido ao cliente para o bloco 11
+
+Do ponto de vista do Indexador, está tudo a progredir logicamente. O tempo move-se para frente, porém tivemos que fazer rollback num bloco uncle e reproduzir o bloco sob consenso à frente, ainda por cima. No caminho, o Indexador serve pedidos com o último estado de que tem ciência naquela hora.
+
+Do ponto de vista do cliente, no entanto, tudo parece caótico. O cliente observa que as respostas foram para os blocos 8, 10, 9 e 11 naquela ordem — o problema do "bloco bambo". Quando um cliente experiencia um bloco bambo, os dados podem aparentar se contradizer temporalmente. Isto só piora quando consideramos que os Indexadores não ingerem os blocos mais recentes simultaneamente, e os seus pedidos podem ser encaminhados para vários Indexadores.
+
+É responsabilidade do cliente e do servidor trabalharem juntos para fornecer dados consistentes ao utilizador. Métodos diferentes devem ser usados, a depender da consistência desejada, já que não há um único programa correto para todos os problemas.
+
+Raciocinar as implicações de sistemas distribuídos é difícil, mas a solução pode não ser! Nós estabelecemos APIs e padrões para ajudar-lhe a navegar alguns casos de uso comuns. Os seguintes exemplos ilustram esses padrões, mas ainda omitem detalhes exigidos pelo código de produção (como gestão de erros e cancelamento) para não ofuscar as ideias principais.
+
+## Consulta por dados atualizados
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Como retirar um conjunto de itens relacionados
+
+Outro caso de uso é o retiro de um grande conjunto, ou mais geralmente, de itens relacionados em múltiplos pedidos. Ao contrário do caso da consulta (onde a consistência desejada era acelerar no tempo), a consistência desejada é para um único ponto no tempo.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Note que em caso de uma reorganização, o cliente deve tentar novamente a partir do primeiro pedido, para atualizar o hash do bloco a um block que não é uncle.

From 917aafe7b4f0dff315db3abbcf236ba25c240e44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:39 -0500
Subject: [PATCH 2068/3820] New translations distributed-systems.mdx (Russian)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/ru/subgraphs/querying/distributed-systems.mdx b/website/pages/ru/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..3f3bfe6e3087
--- /dev/null
+++ b/website/pages/ru/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Распределенные системы
+---
+
+The Graph - это протокол, реализованный в виде распределенной системы.
+
+Соединения терпят неудачу. Запросы поступают не по порядку. Разные компьютеры с несинхронизированными часами и состояниями обрабатывают связанные запросы. Серверы перезапускаются. Реорганизации происходят между запросами. Эти проблемы присущи всем распределенным системам, но усугубляются в системах, работающих в глобальном масштабе.
+
+Рассмотрим этот пример того, что может произойти, если клиент запрашивает у Индексатора последние данные во время реорганизации.
+
+1. Индексатор обрабатывает блок 8
+2. Запрос, отправленный клиенту для блока 8
+3. Индексатор обрабатывает блок 9
+4. Индексатор обрабатывает блок 10A
+5. Запрос, отправленный клиенту для блока 10A
+6. Индексатор обнаруживает реорганизацию на 10B и откатывается на 10A
+7. Запрос, отправленный клиенту для блока 9
+8. Индексатор обрабатывает блок 10B
+9. Индексатор обрабатывает блок 11
+10. Запрос, отправленный клиенту для блока 11
+
+С точки зрения Индексатора, все логично продвигается вперед. Время движется вперед, хотя нам и пришлось откатить незавершенный блок и воспроизвести консенсусный блок поверх него. Попутно индексатор обслуживает запросы, используя последнее состояние, о котором ему известно на данный момент.
+
+Однако с точки зрения клиента все выглядит хаотично. Клиент замечает, что ответы были для блоков 8, 10, 9 и 11 в таком порядке. Мы называем это проблемой "колебания блока". Когда клиент испытывает колебания блока, со временем может показаться, что данные противоречат сами себе. Ситуация ухудшается, если учесть, что не все Индексаторы принимают последние блоки одновременно, и ваши запросы могут быть перенаправлены нескольким Индексаторам.
+
+Клиент и сервер несут ответственность за совместную работу по предоставлению пользователю согласованных данных. Необходимо использовать различные подходы в зависимости от желаемой согласованности, поскольку не существует единой правильной программы для каждой проблемы.
+
+Рассуждать о последствиях распределенных систем сложно, но исправления может и не быть! Мы создали API и шаблоны, чтобы помочь вам ориентироваться в некоторых распространенных вариантах использования. Следующие примеры иллюстрируют эти шаблоны, но по-прежнему исключают детали, требуемые производственным кодом (например, обработку ошибок и отмену), чтобы не запутывать основные идеи.
+
+## Опрос для получения обновленных данных
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Выборка набора связанных элементов
+
+Другим вариантом использования является извлечение большого набора или, в более общем плане, извлечение связанных элементов по нескольким запросам. В отличие от случая опроса (где желаемая согласованность заключалась в продвижении вперед во времени), желаемая согласованность относится к одному моменту времени.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Обратите внимание, что в случае реорганизации клиент должен будет повторить попытку с первого запроса, чтобы обновить хэш блока до необработанного блока.

From 47190d08d33c8ae92fcfbe79c730077f9690276b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:40 -0500
Subject: [PATCH 2069/3820] New translations distributed-systems.mdx (Swedish)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/sv/subgraphs/querying/distributed-systems.mdx b/website/pages/sv/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..c3eedefd4565
--- /dev/null
+++ b/website/pages/sv/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Distribuerade System
+---
+
+The Graph är ett protokoll implementerat som ett distribuerat system.
+
+Anslutningar misslyckas. Förfrågningar anländer i fel ordning. Olika datorer med osynkroniserade klockor och tillstånd bearbetar relaterade förfrågningar. Servrar startar om. Omorganiseringar inträffar mellan förfrågningar. Dessa problem är inneboende för alla distribuerade system men förvärras i system som opererar globalt.
+
+Betrakta detta exempel på vad som kan inträffa om en klient undersöker en Indexer för den senaste datan under en omorganiseringar.
+
+1. Indexer bearbetar block 8
+2. Förfrågan serveras till klienten för block 8
+3. Indexer bearbetar block 9
+4. Indexer bearbetar block 10A
+5. Förfrågan serveras till klienten för block 10A
+6. Indexer upptäcker omorganiseringar till 10B och rullar tillbaka 10A
+7. Förfrågan serveras till klienten för block 9
+8. Indexer bearbetar block 10B
+9. Indexer bearbetar block 11
+10. Förfrågan serveras till klienten för block 11
+
+Ur Indexerns synvinkel fortskrider saker logiskt framåt. Tiden går framåt, även om vi var tvungna att rulla tillbaka ett uncle-block och spela in blocket under konsensus framåt ovanpå det. Under vägen serverar Indexern förfrågningar med den senaste informationen den känner till vid den tiden.
+
+Ur klientens synvinkel verkar dock saker kaotiska. Klienten observerar att svaren var för block 8, 10, 9 och 11 i den ordningen. Vi kallar detta "block wobble"-problemet. När en klient upplever block wobble kan data verka motsäga sig över tiden. Situationen förvärras när vi tänker på att Indexers inte alla bearbetar de senaste blocken samtidigt, och dina förfrågningar kan routas till flera Indexers.
+
+Det är klientens och serverns ansvar att samarbeta för att ge användaren konsekvent data. Olika metoder måste användas beroende på önskad konsekvens, eftersom det inte finns ett rätt program för varje problem.
+
+Att resonera kring följderna av distribuerade system är svårt, men lösningen behöver inte vara det! Vi har etablerat API:er och mönster för att hjälpa dig hantera några vanliga användningsfall. Följande exempel illustrerar dessa mönster, men utesluter fortfarande detaljer som krävs av produktionskod (som felhantering och avbokning) för att inte försvåra huvudidéerna.
+
+## Polla efter uppdaterad data
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Hämta en uppsättning relaterade objekt
+
+Ett annat användningsfall är att hämta en stor uppsättning eller mer generellt att hämta relaterade objekt över flera förfrågningar. Till skillnad från fallet med att hämta uppdaterade data (där önskad konsekvens var att gå framåt i tiden), är önskad konsekvens här att få data från en enda tidpunkt.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Observera att i händelse av en omorganisation måste klienten försöka igen från den första begäran för att uppdatera blockhashen till ett icke-farbrorblock.

From 67f406a773fe100cbb04c101e1d8b59277db1019 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:42 -0500
Subject: [PATCH 2070/3820] New translations distributed-systems.mdx (Turkish)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/tr/subgraphs/querying/distributed-systems.mdx b/website/pages/tr/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..85337206bfd3
--- /dev/null
+++ b/website/pages/tr/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Distributed Systems
+---
+
+The Graph is a protocol implemented as a distributed system.
+
+Connections fail. Requests arrive out of order. Different computers with out-of-sync clocks and states process related requests. Servers restart. Re-orgs happen between requests. These problems are inherent to all distributed systems but are exacerbated in systems operating at a global scale.
+
+Consider this example of what may occur if a client polls an Indexer for the latest data during a re-org.
+
+1. Indexer ingests block 8
+2. Request served to the client for block 8
+3. Indexer ingests block 9
+4. Indexer ingests block 10A
+5. Request served to the client for block 10A
+6. Indexer detects reorg to 10B and rolls back 10A
+7. Request served to the client for block 9
+8. Indexer ingests block 10B
+9. Indexer ingests block 11
+10. Request served to the client for block 11
+
+From the point of view of the Indexer, things are progressing forward logically. Time is moving forward, though we did have to roll back an uncle block and play the block under consensus forward on top of it. Along the way, the Indexer serves requests using the latest state it knows about at that time.
+
+From the point of view of the client, however, things appear chaotic. The client observes that the responses were for blocks 8, 10, 9, and 11 in that order. We call this the "block wobble" problem. When a client experiences block wobble, data may appear to contradict itself over time. The situation worsens when we consider that Indexers do not all ingest the latest blocks simultaneously, and your requests may be routed to multiple Indexers.
+
+It is the responsibility of the client and server to work together to provide consistent data to the user. Different approaches must be used depending on the desired consistency as there is no one right program for every problem.
+
+Reasoning through the implications of distributed systems is hard, but the fix may not be! We've established APIs and patterns to help you navigate some common use-cases. The following examples illustrate those patterns but still elide details required by production code (like error handling and cancellation) to not obfuscate the main ideas.
+
+## Polling for updated data
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Fetching a set of related items
+
+Another use-case is retrieving a large set or, more generally, retrieving related items across multiple requests. Unlike the polling case (where the desired consistency was to move forward in time), the desired consistency is for a single point in time.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Note that in case of a re-org, the client will need to retry from the first request to update the block hash to a non-uncle block.

From e50056d2af63df5514350b95f2539893ffbce851 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:43 -0500
Subject: [PATCH 2071/3820] New translations distributed-systems.mdx
 (Ukrainian)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/uk/subgraphs/querying/distributed-systems.mdx b/website/pages/uk/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..98f62b33bc9a
--- /dev/null
+++ b/website/pages/uk/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Розподілені системи
+---
+
+The Graph - це протокол, що реалізований як розподілена система.
+
+З'єднання не вдається. Запити поступають не за порядком. Різні комп'ютери з неузгодженими часовими та становими процесами обробляють пов'язані між собою запити. Сервери перезавантажуються. Між запитами відбуваються реорганізації. Ці проблеми притаманні всім розподіленим системам, але вони поглиблюються в системах, що працюють в глобальному масштабі.
+
+Розглянемо на цьому прикладі, що може статися, якщо клієнт запросить в індексатора останні дані під час повторної реорганізації.
+
+1. Індексатор індексує блок 8
+2. Запит від клієнта для блоку 8 обробляється
+3. Індексатор індексує блок 9
+4. Індексатор індексує блок 10А
+5. Запит від клієнта для блоку 10А обробляється
+6. Індексатор знаходить перерозподіл на блоці 10B і відкочується на 10A
+7. Запит від клієнта для блоку 9 обробляється
+8. Індексатор індексує блок 10В
+9. Індексатор індексує блок 11
+10. Запит від клієнта для блоку 11 обробляється
+
+З точки зору Індексатора, все розвивається цілком логічно. Час рухається вперед, хоча нам довелося відкотити старий блок назад і відтворити блок за принципом консенсусу на його основі. Протягом цього часу Індексатор обслуговує запити, використовуючи останній відомий йому актуальний статус.
+
+З точки зору клієнта, щоправда, все виглядає хаотично. Клієнт зауважив, що відповіді були для блоків 8, 10, 9 та 11, саме в такому порядку. Ми називаємо це проблемою "block wobble" або "коливанням блоків". Коли клієнт стикається з цим, дані можуть з часом суперечити один одному. Ситуація погіршується, якщо врахувати те, що Індексатори не індексують останні блоки одночасно разом, і ваші запити можуть бути направлені до декількох різних Індексаторів.
+
+Клієнт і сервер несуть відповідальність за спільну роботу з метою надання користувачеві узгоджених даних. Залежно від бажаної послідовності необхідно використовувати різні підходи, оскільки не існує єдиної правильної стратегії для розв'язання кожної проблеми.
+
+Складно зрозуміти наслідки використання розподілених систем, але рішення може взагалі не існувати! Ми створили API та шаблони, які допоможуть вам орієнтуватися в найбільш поширених варіантах використання. Наступні приклади ілюструють ці шаблони, але все ж не розкривають деталей, необхідних у програмному коді (наприклад, обробка та усунення помилок), щоб не затьмарити основні ідеї.
+
+## Запит на отримання оновлених даних
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Отримання взаємопов'язаних елементів
+
+Ще один випадок використання - пошук великого набору або, в більш широкому розумінні, пошук пов'язаних елементів за кількома запитами. На відміну від випадку з запитом (де необхідна узгодженість полягала в тому, щоб переміщатися вперед у часі), бажана узгодженість стосується лише одного конкретного моменту в часі.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Зауважте, що у випадку повторної операції клієнту потрібно буде повторити спробу з першого запиту, щоб оновити хеш блоку до не старого або попереднього блоку.

From 0687aea5883f42462f66fc002c61e81bc4682ab1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:44 -0500
Subject: [PATCH 2072/3820] New translations distributed-systems.mdx (Chinese
 Simplified)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/zh/subgraphs/querying/distributed-systems.mdx b/website/pages/zh/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..10acf15d56be
--- /dev/null
+++ b/website/pages/zh/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: 分布式系统
+---
+
+Graph 是分布式系统实现的协议。
+
+连接可能失败。 请求无序到达。 具有不同步时钟和状态的很多计算机在处理相关请求。 服务器重新启动。 重组发生在请求之间。以上这些问题是所有分布式系统所固有的，但在全球范围内运行的系统中会更加严重。
+
+考虑这个例子，如果客户端在重组期间轮询索引人以获取最新数据，可能会发生什么。
+
+1. 索引人获取区块 8
+2. 区块 8 的数据传送给客户端
+3. 索引人获取区块 9
+4. 索引人获取区块 10A
+5. 区块 10A 的数据传送给客户端
+6. 索引人检测到区块重组到 10B 并回转到 10A
+7. 区块 9 的数据传送给客户端
+8. 索引人获取区块 10B
+9. 索引人获取区块 11
+10. 区块 11 的数据传送给客户端
+
+从索引人的角度来看，事情进展得完全合乎逻辑。 时间不断前行，尽管我们确实必须回滚一个相邻区块，并在共识下处理该区块。 在此过程中，索引人使用它当时知道的最新状态为请求提供服务。
+
+然而，从客户的角度来看，事情却显得很混乱。 客户端观察到响应依次是区块 8、10、9 和 11。 我们称之为“区块摆动”问题。 当客户端遇到区块摆动时，数据可能会随着时间的推移而自相矛盾。 当考虑到索引人不会同时获取最新区块，并且您的请求可能会被路由到多个索引人的时候，情况会变得更糟。
+
+客户端和服务器有责任协同工作，以便向用户提供一致的数据。 根据所需的一致性目标的不同，我们必须使用不同的方法，因为没有一个适合所有问题的完美解决方案。
+
+通过分布式系统的影响进行推理是困难的，但修复可能不是！ 我们已经建立了一些 API 和模式来帮助您解决一些常见的用例。 以下示例说明了这些模式，但仍然省略了生产代码所需的细节（如错误处理和消除），以免混淆主要思想。
+
+## 轮询更新的数据
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## 获取一组相关项目
+
+另一个用例是检索一个更大的集合，或者更一般地说，跨多个请求检索相关项目。 与轮询案例（所需的一致性是及时向前进行）不同，此用例所需的一致性是针对单个时间点的。
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+请注意，在重组的情况下，客户端将需要从第一个请求重试，以将区块hash更新为非相邻区块。

From eeb0f0ed335fb05fb5cb6faced6305843f391628 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:45 -0500
Subject: [PATCH 2073/3820] New translations distributed-systems.mdx (Urdu
 (Pakistan))

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/ur/subgraphs/querying/distributed-systems.mdx b/website/pages/ur/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..fe8aa4b50d2b
--- /dev/null
+++ b/website/pages/ur/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: تقسیم شدہ نظام
+---
+
+گراف ایک پروٹوکول ہے جسے تقسیم شدہ نظام کے طور پر لاگو کیا جاتا ہے.
+
+رابطے ناکام ہو جاتے ہیں۔ درخواستیں آرڈر سے باہر آتی ہیں۔ غیر مطابقت پذیر گھڑیوں کے ساتھ مختلف کمپیوٹرز اور سٹیٹس سے متعلقہ درخواستوں پر کارروائی کرتے ہیں۔ سرورز دوبارہ شروع ہو جاتے ہیں۔ درخواستوں کے درمیان دوبارہ تنظیمیں ہوتی ہیں۔ یہ مسائل تمام تقسیم شدہ نظاموں میں موروثی ہیں لیکن عالمی سطح پر کام کرنے والے نظاموں میں مزید بڑھ جاتے ہیں.
+
+اس مثال پر غور کریں کہ اگر کوئی کلائنٹ دوبارہ تنظیم کے دوران تازہ ترین ڈیٹا کے لیے انڈیکسر کو پول کرتا ہے تو کیا ہو سکتا ہے.
+
+1. انڈیکسر بلاک 8 انجیسٹ کرتا ہے
+2. بلاک 8 کے لیے کلائنٹ کو درخواست دی گئی
+3. انڈیکسر بلاک 9 کو انجیسٹ کرتا ہے
+4. انڈیکسر بلاک 10A کو انجیسٹ کرتا ہے
+5. بلاک 10A کے لیے کلائنٹ کو درخواست دی گئی
+6. انڈیکسر 10B کو دوبارہ ترتیب دینے کا پتہ لگاتا ہے اور 10A کو واپس کرتا ہے
+7. بلاک 9 کے لیے کلائنٹ کو درخواست دی گئی
+8. انڈیکسر بلاک 10B کو انجیسٹ کرتا ہے
+9. انڈیکسر بلاک 11 کو انجیسٹ کرتا ہے
+10. بلاک 11 کے لیے کلائنٹ کو درخواست دی گئی
+
+انڈیکسر کے نقطہ نظر سے، چیزیں منطقی طور پر آگے بڑھ رہی ہیں. وقت آگے بڑھ رہا ہے، حالانکہ ہمیں انکل بلاک کو رول بیک کرنا پڑا اور اتفاق رائے کے تحت بلاک کو آگے بڑھانا پڑا۔ راستے میں، انڈیکسر اس تازہ ترین حالت کا استعمال کرتے ہوئے درخواستیں پیش کرتا ہے جس کے بارے میں اسے اس وقت معلوم ہوتا ہے.
+
+کلائنٹ کے نقطہ نظر سے، تاہم، چیزیں افراتفری نظر آتی ہیں. کلائنٹ کا مشاہدہ ہے کہ جوابات اس ترتیب میں بلاکس 8، 10، 9، اور 11 کے لیے تھے۔ ہم اسے "بلاک وابل" مسئلہ کہتے ہیں۔ جب ایک کلائنٹ کو بلاک وبل کا تجربہ ہوتا ہے، تو وقت گزرنے کے ساتھ ڈیٹا خود سے متصادم دکھائی دے سکتا ہے۔ صورت حال اس وقت مزید خراب ہو جاتی ہے جب ہم غور کرتے ہیں کہ انڈیکسرز سبھی تازہ ترین بلاکس کو ایک ساتھ نہیں لیتے ہیں، اور آپ کی درخواستیں متعدد انڈیکسرز کو بھیجی جا سکتی ہیں.
+
+صارف کو مستقل ڈیٹا فراہم کرنے کے لیے مل کر کام کرنا کلائنٹ اور سرور کی ذمہ داری ہے۔ مطلوبہ مستقل مزاجی کے لحاظ سے مختلف طریقوں کا استعمال کیا جانا چاہیے کیونکہ ہر مسئلے کے لیے کوئی ایک صحیح پروگرام نہیں ہے.
+
+تقسیم شدہ نظاموں کے مضمرات کے ذریعے استدلال کرنا مشکل ہے، لیکن درست نہیں ہو سکتا! ہم نے APIs اور پیٹرن قائم کیے ہیں تاکہ آپ کو کچھ عام استعمال کے معاملات کا پتہ لگانے میں مدد ملے۔ مندرجہ ذیل مثالیں ان نمونوں کی وضاحت کرتی ہیں لیکن پھر بھی پروڈکشن کوڈ (جیسے غلطی سے نمٹنے اور منسوخی) کے لیے درکار تفصیلات کو واضح کرتی ہیں تاکہ مرکزی خیالات کو مبہم نہ کیا جا سکے.
+
+## تازہ ترین ڈیٹا کے لیے پولنگ
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## متعلقہ اشیاء کا ایک سیٹ لانا
+
+ایک اور استعمال کا معاملہ ایک بڑے سیٹ کو بازیافت کرنا یا عام طور پر متعدد درخواستوں میں متعلقہ اشیاء کو بازیافت کرنا ہے۔ پولنگ کیس کے برعکس (جہاں مطلوبہ مستقل مزاجی وقت کے ساتھ آگے بڑھنا تھی)، مطلوبہ مستقل مزاجی وقت میں ایک نقطہ کے لیے ہوتی ہے.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+نوٹ کریں کہ دوبارہ تنظیم کی صورت میں، کلائنٹ کو بلاک ہیش کو نان انکل بلاک میں اپ ڈیٹ کرنے کی پہلی درخواست سے دوبارہ کوشش کرنے کی ضرورت ہوگی.

From b0a5592467f23d30c8e6d20f96910ac2332834e2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:46 -0500
Subject: [PATCH 2074/3820] New translations distributed-systems.mdx
 (Vietnamese)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/vi/subgraphs/querying/distributed-systems.mdx b/website/pages/vi/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..d31203987237
--- /dev/null
+++ b/website/pages/vi/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Hệ thống phân tán
+---
+
+The Graph là một giao thức được thực hiện như một hệ thống phân tán.
+
+Kết nối không thành công. Yêu cầu đến không theo thứ tự. Các máy tính khác nhau có đồng hồ và trạng thái không đồng bộ sẽ xử lý các yêu cầu liên quan. Máy chủ khởi động lại. Tổ chức lại xảy ra giữa các yêu cầu. Những vấn đề này vốn có đối với tất cả các hệ thống phân tán nhưng ngày càng trầm trọng hơn trong các hệ thống hoạt động ở quy mô toàn cầu.
+
+Hãy xem xét ví dụ này về những gì có thể xảy ra nếu một máy khách thăm dò một Indexer để biết dữ liệu mới nhất trong một lần tổ chức lại (re-org).
+
+1. Indexer nhập khối 8
+2. Yêu cầu được cung cấp cho máy khách đối với khối 8
+3. Indexer nhập khối 9
+4. Indexer nhập khối 10A
+5. Yêu cầu được cung cấp cho máy khách đối với khối 10A
+6. Indexer phát hiện reorg đến 10B và cuộn lại 10A
+7. Yêu cầu được cung cấp cho máy khách đối với khối 9
+8. Indexer nhập khối 10B
+9. Indexer nhập khối 11
+10. Yêu cầu được cung cấp cho máy khách đối với khối 11
+
+Theo quan điểm của Indexer, mọi thứ đang tiến triển về phía trước một cách hợp lý. Thời gian đang trôi về phía trước, mặc dù chúng tôi đã phải quay lại một khối chú và chơi khối dưới sự đồng thuận về phía trên của nó. Trên đường đi, Trình lập chỉ mục phục vụ các yêu cầu bằng cách sử dụng trạng thái mới nhất mà nó biết tại thời điểm đó.
+
+Tuy nhiên, từ quan điểm của máy khách, mọi thứ có vẻ hỗn loạn. Máy khách nhận thấy rằng các câu trả lời dành cho các khối 8, 10, 9 và 11 theo thứ tự đó. Chúng ta gọi đây là vấn đề "khối chao đảo". Khi khách hàng gặp phải trường hợp khối bị lung lay, dữ liệu có thể mâu thuẫn với chính nó theo thời gian. Tình hình trở nên tồi tệ hơn khi chúng ta nhận thấy rằng các Indexer không nhập các khối mới nhất đồng thời và các yêu cầu của bạn có thể được chuyển đến nhiều Indexer.
+
+Máy khách và máy chủ có trách nhiệm làm việc cùng nhau để cung cấp dữ liệu nhất quán cho người dùng. Các cách tiếp cận khác nhau phải được sử dụng tùy thuộc vào tính nhất quán mong muốn vì không có một chương trình phù hợp cho mọi vấn đề.
+
+Việc lý luận thông qua các tác động của hệ thống phân tán là khó, nhưng có thể không khắc phục được! Chúng tôi đã thiết lập các API và mẫu để giúp bạn điều hướng một số trường hợp sử dụng phổ biến. Các ví dụ sau minh họa các mẫu đó nhưng vẫn giải thích các chi tiết theo yêu cầu của mã sản xuất (như xử lý lỗi và hủy bỏ) để không làm xáo trộn các ý chính.
+
+## Thăm dò dữ liệu cập nhật
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Tìm nạp một tập hợp các mục liên quan
+
+Một ca sử dụng khác là truy xuất một tập hợp lớn hay nói chung là truy xuất các mục có liên quan qua nhiều yêu cầu. Không giống như trường hợp thăm dò ý kiến (trong đó tính nhất quán mong muốn được tiến hành kịp thời), tính nhất quán mong muốn dành cho một thời điểm duy nhất.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Lưu ý rằng trong trường hợp tổ chức lại (re-org), khách hàng sẽ cần thử lại từ yêu cầu đầu tiên để cập nhật băm khối thành một khối không phải là non-uncle block.

From 807ab7dbc725015835ee39ca09af2e37669251ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:47 -0500
Subject: [PATCH 2075/3820] New translations distributed-systems.mdx (Marathi)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/mr/subgraphs/querying/distributed-systems.mdx b/website/pages/mr/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..0931cfb05a96
--- /dev/null
+++ b/website/pages/mr/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Distributed Systems
+---
+
+The Graph is a protocol implemented as a distributed system.
+
+कनेक्शन अयशस्वी. विनंत्या क्रमाबाहेर येतात. आउट-ऑफ-सिंक घड्याळे असलेले भिन्न संगणक आणि राज्य संबंधित विनंत्यांवर प्रक्रिया करतात. सर्व्हर रीस्टार्ट. विनंत्यांदरम्यान पुनर्संचयित होतात. या समस्या सर्व वितरित प्रणालींमध्ये अंतर्भूत आहेत परंतु जागतिक स्तरावर कार्यरत असलेल्या प्रणालींमध्ये या समस्या अधिकच वाढल्या आहेत.
+
+Consider this example of what may occur if a client polls an Indexer for the latest data during a re-org.
+
+1. Indexer ingests block 8
+2. Request served to the client for block 8
+3. Indexer ingests block 9
+4. Indexer ingests block 10A
+5. Request served to the client for block 10A
+6. Indexer detects reorg to 10B and rolls back 10A
+7. Request served to the client for block 9
+8. Indexer ingests block 10B
+9. Indexer ingests block 11
+10. Request served to the client for block 11
+
+इंडेक्सरच्या दृष्टिकोनातून, गोष्टी तार्किकदृष्ट्या पुढे जात आहेत. वेळ पुढे सरकत आहे, जरी आम्हाला अंकल ब्लॉक मागे घ्यावा लागला आणि त्याच्या वरच्या बाजूने एकमताने ब्लॉक खेळला गेला. वाटेत, इंडेक्सर त्यावेळेस माहित असलेली नवीनतम स्थिती वापरून विनंती करतो.
+
+From the point of view of the client, however, things appear chaotic. The client observes that the responses were for blocks 8, 10, 9, and 11 in that order. We call this the "block wobble" problem. When a client experiences block wobble, data may appear to contradict itself over time. The situation worsens when we consider that Indexers do not all ingest the latest blocks simultaneously, and your requests may be routed to multiple Indexers.
+
+वापरकर्त्याला सातत्यपूर्ण डेटा प्रदान करण्यासाठी एकत्र काम करणे ही क्लायंट आणि सर्व्हरची जबाबदारी आहे. इच्छित सुसंगततेवर अवलंबून भिन्न पध्दती वापरणे आवश्यक आहे कारण प्रत्येक समस्येसाठी कोणताही एक योग्य कार्यक्रम नाही.
+
+डिस्ट्रिब्युटेड सिस्टम्सच्या परिणामांद्वारे तर्क करणे कठीण आहे, परंतु निराकरण होऊ शकत नाही! तुम्हाला काही सामान्य वापर-केस नेव्हिगेट करण्यात मदत करण्यासाठी आम्ही API आणि नमुने स्थापित केले आहेत. खालील उदाहरणे ते नमुने स्पष्ट करतात परंतु तरीही मुख्य कल्पना अस्पष्ट न करण्यासाठी उत्पादन कोड (जसे की त्रुटी हाताळणे आणि रद्द करणे) आवश्यक असलेले तपशील स्पष्ट करतात.
+
+## Polling for updated data
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Fetching a set of related items
+
+आणखी एक वापर-केस म्हणजे एक मोठा संच पुनर्प्राप्त करणे किंवा, अधिक सामान्यपणे, एकाधिक विनंत्यांमधून संबंधित आयटम पुनर्प्राप्त करणे. मतदान प्रकरणाच्या विपरीत (जेथे इच्छित सातत्य वेळेत पुढे जाणे होते), इच्छित सातत्य वेळेत एका बिंदूसाठी असते.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+लक्षात ठेवा की री-ऑर्गच्या बाबतीत, क्लायंटला ब्लॉक हॅश नॉन-अंकल ब्लॉकवर अपडेट करण्यासाठी पहिल्या विनंतीपासून पुन्हा प्रयत्न करणे आवश्यक आहे.

From 4979df131133a16ae8e0828f2613c49e50547e8f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:48 -0500
Subject: [PATCH 2076/3820] New translations distributed-systems.mdx (Hindi)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/hi/subgraphs/querying/distributed-systems.mdx b/website/pages/hi/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..0f530ebacba4
--- /dev/null
+++ b/website/pages/hi/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: वितरित प्रणाली
+---
+
+ग्राफ़ एक वितरित प्रणाली के रूप में कार्यान्वित प्रोटोकॉल है।
+
+कनेक्शन विफल। अनुरोध आदेश से बाहर आते हैं। आउट-ऑफ-सिंक घड़ियों वाले विभिन्न कंप्यूटर और राज्य संबंधित अनुरोधों को संसाधित करते हैं। सर्वर पुनरारंभ करें। अनुरोधों के बीच पुन: संगठन होते हैं। ये समस्याएँ सभी वितरित प्रणालियों में निहित हैं, लेकिन वैश्विक स्तर पर संचालित प्रणालियों में अधिक हैं।
+
+इस उदाहरण पर विचार करें कि क्या हो सकता है यदि कोई ग्राहक किसी पुन: संगठन के दौरान नवीनतम डेटा के लिए एक अनुक्रमणिका का चुनाव करता है।
+
+1. इंडेक्सर ब्लॉक 8 को निगलता है
+2. क्लाइंट को ब्लॉक 8 के लिए अनुरोध दिया गया
+3. इंडेक्सर ब्लॉक 9 को निगलता है
+4. इंडेक्सर ब्लॉक 10A को निगलता है
+5. ग्राहक को ब्लॉक 10A के लिए अनुरोध दिया गया
+6. इंडेक्सर 10B पर रीऑर्ग का पता लगाता है और 10A को रोल बैक करता है
+7. क्लाइंट को ब्लॉक 9 के लिए अनुरोध दिया गया
+8. इंडेक्सर ब्लॉक 10बी लेता है
+9. इंडेक्सर ब्लॉक 11 को निगलता है
+10. ग्राहक को ब्लॉक 11 के लिए अनुरोध दिया गया
+
+इंडेक्सर की दृष्टि से चीजें तार्किक रूप से आगे बढ़ रही हैं। समय आगे बढ़ रहा है, हालांकि हमें एक अंकल ब्लॉक को वापस रोल करना पड़ा और इसके शीर्ष पर आम सहमति के तहत ब्लॉक खेलना पड़ा। रास्ते में, इंडेक्सर उस समय के बारे में नवीनतम स्थिति का उपयोग करके अनुरोधों को पूरा करता है।
+
+हालाँकि, क्लाइंट के दृष्टिकोण से, चीजें अव्यवस्थित दिखाई देती हैं। क्लाइंट देखता है कि प्रतिक्रियाएँ उसी क्रम में ब्लॉक 8, 10, 9 और 11 के लिए थीं। हम इसे "ब्लॉक वॉबल" समस्या कहते हैं। जब कोई क्लाइंट ब्लॉक डगमगाने का अनुभव करता है, तो डेटा समय के साथ विरोधाभासी प्रतीत हो सकता है। स्थिति तब और खराब हो जाती है जब हम यह मानते हैं कि सभी अनुक्रमणिकाएँ एक साथ नवीनतम ब्लॉकों को ग्रहण नहीं करती हैं, और आपके अनुरोध एकाधिक अनुक्रमणकों को भेजे जा सकते हैं।
+
+उपयोगकर्ता को लगातार डेटा प्रदान करने के लिए एक साथ काम करना क्लाइंट और सर्वर की जिम्मेदारी है। वांछित स्थिरता के आधार पर विभिन्न दृष्टिकोणों का उपयोग किया जाना चाहिए क्योंकि हर समस्या के लिए कोई एक सही कार्यक्रम नहीं है।
+
+वितरित सिस्टम के प्रभाव के माध्यम से तर्क करना कठिन है, लेकिन समाधान नहीं हो सकता है! हमने कुछ सामान्य उपयोग-मामलों को नेविगेट करने में आपकी सहायता के लिए API और पैटर्न स्थापित किए हैं। निम्नलिखित उदाहरण उन पैटर्नों को चित्रित करते हैं लेकिन फिर भी मुख्य विचारों को अस्पष्ट नहीं करने के लिए उत्पादन कोड (जैसे त्रुटि प्रबंधन और रद्दीकरण) द्वारा आवश्यक विवरणों को दूर करते हैं।
+
+## अद्यतन डेटा के लिए मतदान
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## संबंधित वस्तुओं का एक सेट लाया जा रहा है
+
+एक अन्य उपयोग-मामला एक बड़े सेट को पुनः प्राप्त कर रहा है, या अधिक सामान्यतः, कई अनुरोधों में संबंधित वस्तुओं को पुनः प्राप्त कर रहा है। मतदान के मामले के विपरीत (जहां वांछित स्थिरता समय में आगे बढ़ने के लिए थी), वांछित स्थिरता समय में एक बिंदु के लिए है।
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+ध्यान दें कि री-ऑर्गन के मामले में, क्लाइंट को ब्लॉक हैश को गैर-अंकल ब्लॉक में अपडेट करने के पहले अनुरोध से पुनः प्रयास करने की आवश्यकता होगी।

From ea20e32116bd7cb013da20221abef0172d08d0ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:49 -0500
Subject: [PATCH 2077/3820] New translations distributed-systems.mdx (Swahili)

---
 .../querying/distributed-systems.mdx          | 134 ++++++++++++++++++
 1 file changed, 134 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/querying/distributed-systems.mdx

diff --git a/website/pages/sw/subgraphs/querying/distributed-systems.mdx b/website/pages/sw/subgraphs/querying/distributed-systems.mdx
new file mode 100644
index 000000000000..85337206bfd3
--- /dev/null
+++ b/website/pages/sw/subgraphs/querying/distributed-systems.mdx
@@ -0,0 +1,134 @@
+---
+title: Distributed Systems
+---
+
+The Graph is a protocol implemented as a distributed system.
+
+Connections fail. Requests arrive out of order. Different computers with out-of-sync clocks and states process related requests. Servers restart. Re-orgs happen between requests. These problems are inherent to all distributed systems but are exacerbated in systems operating at a global scale.
+
+Consider this example of what may occur if a client polls an Indexer for the latest data during a re-org.
+
+1. Indexer ingests block 8
+2. Request served to the client for block 8
+3. Indexer ingests block 9
+4. Indexer ingests block 10A
+5. Request served to the client for block 10A
+6. Indexer detects reorg to 10B and rolls back 10A
+7. Request served to the client for block 9
+8. Indexer ingests block 10B
+9. Indexer ingests block 11
+10. Request served to the client for block 11
+
+From the point of view of the Indexer, things are progressing forward logically. Time is moving forward, though we did have to roll back an uncle block and play the block under consensus forward on top of it. Along the way, the Indexer serves requests using the latest state it knows about at that time.
+
+From the point of view of the client, however, things appear chaotic. The client observes that the responses were for blocks 8, 10, 9, and 11 in that order. We call this the "block wobble" problem. When a client experiences block wobble, data may appear to contradict itself over time. The situation worsens when we consider that Indexers do not all ingest the latest blocks simultaneously, and your requests may be routed to multiple Indexers.
+
+It is the responsibility of the client and server to work together to provide consistent data to the user. Different approaches must be used depending on the desired consistency as there is no one right program for every problem.
+
+Reasoning through the implications of distributed systems is hard, but the fix may not be! We've established APIs and patterns to help you navigate some common use-cases. The following examples illustrate those patterns but still elide details required by production code (like error handling and cancellation) to not obfuscate the main ideas.
+
+## Polling for updated data
+
+The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+
+We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+
+```javascript
+/// Updates the protocol.paused variable to the latest
+/// known value in a loop by fetching it using The Graph.
+async function updateProtocolPaused() {
+  // It's ok to start with minBlock at 0. The query will be served
+  // using the latest block available. Setting minBlock to 0 is the
+  // same as leaving out that argument.
+  let minBlock = 0
+
+  for (;;) {
+    // Schedule a promise that will be ready once
+    // the next Ethereum block will likely be available.
+    const nextBlock = new Promise((f) => {
+      setTimeout(f, 14000)
+    })
+
+    const query = `
+        query GetProtocol($minBlock: Int!) {
+            protocol(block: { number_gte: $minBlock }  id: "0") {
+              paused
+            }
+            _meta {
+                block {
+                    number
+                }
+            }
+        }`
+
+    const variables = { minBlock }
+    const response = await graphql(query, variables)
+    minBlock = response._meta.block.number
+
+    // TODO: Do something with the response data here instead of logging it.
+    console.log(response.protocol.paused)
+
+    // Sleep to wait for the next block
+    await nextBlock
+  }
+}
+```
+
+## Fetching a set of related items
+
+Another use-case is retrieving a large set or, more generally, retrieving related items across multiple requests. Unlike the polling case (where the desired consistency was to move forward in time), the desired consistency is for a single point in time.
+
+Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+
+```javascript
+/// Gets a list of domain names from a single block using pagination
+async function getDomainNames() {
+  // Set a cap on the maximum number of items to pull.
+  let pages = 5
+  const perPage = 1000
+
+  // The first query will get the first page of results and also get the block
+  // hash so that the remainder of the queries are consistent with the first.
+  const listDomainsQuery = `
+    query ListDomains($perPage: Int!) {
+        domains(first: $perPage) {
+            name
+            id
+        }
+        _meta {
+            block {
+                hash
+            }
+        }
+    }`
+
+  let data = await graphql(listDomainsQuery, { perPage })
+  let result = data.domains.map((d) => d.name)
+  let blockHash = data._meta.block.hash
+
+  let query
+  // Continue fetching additional pages until either we run into the limit of
+  // 5 pages total (specified above) or we know we have reached the last page
+  // because the page has fewer entities than a full page.
+  while (data.domains.length == perPage && --pages) {
+    let lastID = data.domains[data.domains.length - 1].id
+    query = `
+        query ListDomains($perPage: Int!, $lastID: ID!, $blockHash: Bytes!) {
+            domains(first: $perPage, where: { id_gt: $lastID }, block: { hash: $blockHash }) {
+                name
+                id
+            }
+        }`
+
+    data = await graphql(query, { perPage, lastID, blockHash })
+
+    // Accumulate domain names into the result
+    for (domain of data.domains) {
+      result.push(domain.name)
+    }
+  }
+  return result
+}
+```
+
+Note that in case of a re-org, the client will need to retry from the first request to update the block hash to a non-uncle block.

From 562c4b75a8097ae1da6168ba4feec78f9a9b659b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:50 -0500
Subject: [PATCH 2078/3820] New translations from-an-application.mdx (Romanian)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/ro/subgraphs/querying/from-an-application.mdx b/website/pages/ro/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..2e9b52d3dac7
--- /dev/null
+++ b/website/pages/ro/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Querying from an Application
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Pasul 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Pasul 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Pasul 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Pagination
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Pasul 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Pasul 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Pasul 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- Extensible design (easing adding new capabilities on top of it)
+- Lightweight bundle (~5x lighter than Apollo Client)
+- Support for file uploads and offline mode
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Pasul 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Pasul 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 6cf5d21de40260e18b6bfc05d9aa3f32f662b262 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:51 -0500
Subject: [PATCH 2079/3820] New translations from-an-application.mdx (French)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/fr/subgraphs/querying/from-an-application.mdx b/website/pages/fr/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..bc87a498bf7c
--- /dev/null
+++ b/website/pages/fr/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Interrogation à partir d'une application
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Gestion des subgraphs inter-chaînes : interrogation à partir de plusieurs subgraphs en une seule requête
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Résultat entièrement typé
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Étape 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Étape 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # celle-ci provient de compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # celle-ci provient de uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Étape 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Pagination
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Étape 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Étape 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Étape 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Système de cache flexible
+- Conception extensible (facilitant l’ajout de nouvelles fonctionnalités par-dessus)
+- Offre légère (~ 5 fois plus légère que Apollo Client)
+- Prise en charge des téléchargements de fichiers et du mode hors ligne
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Étape 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Étape 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From fb3ac23074a30b4d626dd56e0bbaacee8c0868eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:52 -0500
Subject: [PATCH 2080/3820] New translations from-an-application.mdx (Spanish)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/es/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/es/subgraphs/querying/from-an-application.mdx b/website/pages/es/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..b5eef7144695
--- /dev/null
+++ b/website/pages/es/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Consultar desde una Aplicación
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Manejo de subgrafos cross-chain: Consulta de varios subgrafos en una sola consulta
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Resultado completamente tipificado
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Paso 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Paso 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Paso 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Paginación
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Paso 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Paso 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Paso 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system (Sistema de caché flexible)
+- Extensible design (Diseño extensible, que facilita agregar nuevas capacidades encima)
+- Lightweight bundle (Paquete ligero, ~5 veces más ligero que Apollo Client)
+- Soporte para carga de archivos y modo fuera de línea
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Paso 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Paso 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 70e1d36c4fa7b7ad7dc571892fc37ff7cbae0886 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:53 -0500
Subject: [PATCH 2081/3820] New translations from-an-application.mdx (Arabic)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/ar/subgraphs/querying/from-an-application.mdx b/website/pages/ar/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..41f4681825c5
--- /dev/null
+++ b/website/pages/ar/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: الاستعلام من التطبيق
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- التعامل مع ال subgraph عبر السلاسل: الاستعلام من عدة subgraphs عبر استعلام واحد
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- نتيجة مكتوبة بالكامل
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Step 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Step 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Step 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Pagination
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Step 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Step 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- Extensible design (easing adding new capabilities on top of it)
+- Lightweight bundle (~5x lighter than Apollo Client)
+- Support for file uploads and offline mode
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Step 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 1e8119b557146732986c8dc6743541b7863c0e2f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:54 -0500
Subject: [PATCH 2082/3820] New translations from-an-application.mdx (Czech)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/cs/subgraphs/querying/from-an-application.mdx b/website/pages/cs/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..fea08439d6a5
--- /dev/null
+++ b/website/pages/cs/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Dotazování z aplikace
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Podgraf Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Průzkumník grafů
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Manipulace s podgrafy napříč řetězci: Dotazování z více podgrafů v jednom dotazu
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Plně zadaný výsledekv
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Krok 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Krok 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Krok 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Stránkování
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Krok 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Krok 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Krok 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexibilní systém mezipaměti
+- Rozšiřitelný design (usnadňuje přidávání nových funkcí)
+- Lehký svazek (~5x lehčí než Apollo Client)
+- Podpora nahrávání souborů a režimu offline
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Krok 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Krok 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 77cd1360d772951c32aee1ce0663433e31b1c436 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:55 -0500
Subject: [PATCH 2083/3820] New translations from-an-application.mdx (German)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/de/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/de/subgraphs/querying/from-an-application.mdx b/website/pages/de/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..510accf3c883
--- /dev/null
+++ b/website/pages/de/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Querying from an Application
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Schritt 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Schritt 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Schritt 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Pagination
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Schritt 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Schritt 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Schritt 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- Extensible design (easing adding new capabilities on top of it)
+- Lightweight bundle (~5x lighter than Apollo Client)
+- Support for file uploads and offline mode
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Schritt 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Schritt 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 7da66f81713d2f4e59a325b3f9340915aa35307c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:56 -0500
Subject: [PATCH 2084/3820] New translations from-an-application.mdx (Italian)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/it/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/it/subgraphs/querying/from-an-application.mdx b/website/pages/it/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..7f4abd991e48
--- /dev/null
+++ b/website/pages/it/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Eseguire una query da un'applicazione
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Gestione dei subgraph a cross-chain: effettuare query di più subgraph in un'unica query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Risultato completamente tipizzato
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Step 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Step 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Step 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Impaginazione
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Step 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Step 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Sistema di cache flessibile
+- Design estensibile (facilita l'aggiunta di nuove funzionalità)
+- Bundle leggero (~5 volte più leggero del Apollo Сlient)
+- Supporto per il caricamento di file e la modalità offline
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Step 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 58bc65d73496d22c8704b44c87d715e5fb09c71f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:57 -0500
Subject: [PATCH 2085/3820] New translations from-an-application.mdx (Japanese)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/ja/subgraphs/querying/from-an-application.mdx b/website/pages/ja/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..21f5c1eedd9a
--- /dev/null
+++ b/website/pages/ja/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: アプリケーションからのクエリ
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### グラフエクスプローラ
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- クロスチェーンのサブグラフ処理：1回のクエリで複数のサブグラフからクエリを実行可能
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- 完全なタイプ付け結果
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### ステップ1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### ステップ2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### ステップ 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- ページネーション
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### ステップ1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### ステップ2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### ステップ 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- 柔軟なキャッシュ システム
+- Extensible design（新しい機能の追加を容易にする）
+- Lightweight bundle（Apollo Clientの約5倍の軽さ）
+- ファイルアップロードとオフラインモードに対応
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### ステップ1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### ステップ2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 07760d08f6defe4a7e9d807280a7ded71a434c78 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:58 -0500
Subject: [PATCH 2086/3820] New translations from-an-application.mdx (Korean)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/ko/subgraphs/querying/from-an-application.mdx b/website/pages/ko/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..a9f8162ebcf0
--- /dev/null
+++ b/website/pages/ko/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Querying from an Application
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Step 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Step 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Step 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Pagination
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Step 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Step 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- Extensible design (easing adding new capabilities on top of it)
+- Lightweight bundle (~5x lighter than Apollo Client)
+- Support for file uploads and offline mode
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Step 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 589c8093c3caca7bfb451d2a8864c708aa96b8e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:21:59 -0500
Subject: [PATCH 2087/3820] New translations from-an-application.mdx (Dutch)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/nl/subgraphs/querying/from-an-application.mdx b/website/pages/nl/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..45c84601b934
--- /dev/null
+++ b/website/pages/nl/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Querying from an Application
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Verkenner
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Stap 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Stap 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Stap 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Pagination
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Stap 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Stap 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Stap 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- Extensible design (easing adding new capabilities on top of it)
+- Lightweight bundle (~5x lighter than Apollo Client)
+- Support for file uploads and offline mode
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Stap 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Stap 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From a6048c819a6f4c193f2aeece21490f65c0fbf7c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:00 -0500
Subject: [PATCH 2088/3820] New translations from-an-application.mdx (Polish)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/pl/subgraphs/querying/from-an-application.mdx b/website/pages/pl/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..2198e511b69e
--- /dev/null
+++ b/website/pages/pl/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Querying from an Application
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Krok 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Krok 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Krok 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Pagination
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Krok 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Krok 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Krok 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- Extensible design (easing adding new capabilities on top of it)
+- Lightweight bundle (~5x lighter than Apollo Client)
+- Support for file uploads and offline mode
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Krok 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Krok 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 1eb7210042529fc4467504f593020ba5ce242049 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:01 -0500
Subject: [PATCH 2089/3820] New translations from-an-application.mdx
 (Portuguese)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/pt/subgraphs/querying/from-an-application.mdx b/website/pages/pt/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..eaefab543ac5
--- /dev/null
+++ b/website/pages/pt/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Como Fazer Queries de um Aplicativo
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Gestão de Subgraph Cross-chain: Queries de múltiplos subgraphs numa única consulta
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Resultado totalmente digitado
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Passo 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# ou, com NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Passo 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # este vem do compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # este vem do uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Passo 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Paginação
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Passo 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Passo 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Passo 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Sistema de cache flexível
+- Design extensível (mais fácil adicionar novas capacidades em cima dele)
+- Pacote leve (cerca de 5x mais leve que o Apollo)
+- Apoio para envios de arquivo e modo offline
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Passo 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Passo 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From d17cd80cfb1ac0fee0b150a27a416bff3cfa67e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:02 -0500
Subject: [PATCH 2090/3820] New translations from-an-application.mdx (Russian)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/ru/subgraphs/querying/from-an-application.mdx b/website/pages/ru/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..a0f1fde989db
--- /dev/null
+++ b/website/pages/ru/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Querying from an Application
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Шаг 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Шаг 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Шаг 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Пагинация
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Шаг 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Шаг 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Шаг 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- Extensible design (easing adding new capabilities on top of it)
+- Lightweight bundle (~5x lighter than Apollo Client)
+- Support for file uploads and offline mode
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Шаг 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Шаг 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 87332615f33b0bf8e4257aff4b79f3a2ad4508d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:03 -0500
Subject: [PATCH 2091/3820] New translations from-an-application.mdx (Swedish)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/sv/subgraphs/querying/from-an-application.mdx b/website/pages/sv/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..2a846eb05d74
--- /dev/null
+++ b/website/pages/sv/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Att göra förfrågningar från en Applikation
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraf Studion
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graf Utforskaren
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Hantering av subgrafer över olika blockkedjor: Frågehantering från flera subgrafer i en enda fråga
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fullt typad resultat
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Steg 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Steg 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # den här kommer från compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # den här kommer från uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Steg 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Paginering
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Steg 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Steg 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Steg 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexibelt cachelagersystem
+- Utbyggbar design (förenklar tillägg av nya funktioner på toppen)
+- Lättviktsbundle (~5 gånger lättare än Apollo-klienten)
+- Stöd för filöverföringar och offline-läge
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Steg 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Steg 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from "urql";
+
+const APIURL = "https://api.thegraph.com/subgraphs/name/username/subgraphname";
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`;
+
+const client = createClient({
+  url: APIURL,
+});
+
+const data = await client.query(tokensQuery).toPromise()
+```

From e8c2557839791d778b1c9c5bb64331b468242e45 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:04 -0500
Subject: [PATCH 2092/3820] New translations from-an-application.mdx (Turkish)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/tr/subgraphs/querying/from-an-application.mdx b/website/pages/tr/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..66d3fd5ceb52
--- /dev/null
+++ b/website/pages/tr/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Querying from an Application
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Stüdyosu
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Gezgini
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### 1. Adım
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### 2. Adım
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### 3. Adım
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Sayfalandırma
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### 1. Adım
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### 2. Adım
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### 3. Adım
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- Extensible design (easing adding new capabilities on top of it)
+- Lightweight bundle (~5x lighter than Apollo Client)
+- Support for file uploads and offline mode
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### 1. Adım
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### 2. Adım
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From bf0f71e42da977a3bc41c4db443a43f29e52a1a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:05 -0500
Subject: [PATCH 2093/3820] New translations from-an-application.mdx
 (Ukrainian)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/uk/subgraphs/querying/from-an-application.mdx b/website/pages/uk/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..621351066664
--- /dev/null
+++ b/website/pages/uk/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Отримання запиту з додатка
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Субграф Студія
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Робота з кросс-чейн підграфами: Отримання інформації з декількох підграфів за один запит
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Повністю введений результат
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Step 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Step 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Step 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Pagination
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Step 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Step 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Гнучка кеш-система
+- Динамічний дизайн (полегшує додавання нових функцій)
+- Полегшений варіант (приблизно в 5 разів легший за Apollo Client)
+- Підтримка завантаження файлів та офлайн-режиму
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Step 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 94ab676b19ff4f71c1ff645af6e42cc9a2aaaf52 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:06 -0500
Subject: [PATCH 2094/3820] New translations from-an-application.mdx (Chinese
 Simplified)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/zh/subgraphs/querying/from-an-application.mdx b/website/pages/zh/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..fe6f55cf7e8c
--- /dev/null
+++ b/website/pages/zh/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: 从应用程序中进行查询
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### 子图工作室
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph 浏览器
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- 跨链子图处理: 在一个查询中从多个子图进行查询
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- 完全类型化的结果
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### 步骤1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### 步骤2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  #来自uniswap-v2的查询
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### 步骤3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- 分页
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### 步骤1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### 步骤2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### 步骤3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- 灵活的缓存系统
+- 可扩展设计(使在它上面添加新功能变得容易)
+- 轻量级捆绑包(比 Apollo Client 小约5倍)
+- 支持文件上传和离线模式
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### 步骤1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### 步骤2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 3b71201af8afaf53fb0786711affb9d7940451a7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:07 -0500
Subject: [PATCH 2095/3820] New translations from-an-application.mdx (Urdu
 (Pakistan))

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/ur/subgraphs/querying/from-an-application.mdx b/website/pages/ur/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..edad71b9c05f
--- /dev/null
+++ b/website/pages/ur/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: ایپلیکیشن سے کیوری
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### سب گراف سٹوڈیو
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### گراف ایکسپلورر
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- کراس چین سب گراف ہینڈلنگ: ایک کیوری میں متعدد سب گرافس سے کیوری کرنا
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- مکمل طور پر ٹائپ شدہ نتیجہ
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### پہلا قدم
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### دوسرا قدم
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### تیسرا قدم
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+گراف کلائنٹ کی تعمیر
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- صفحہ بندی
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### پہلا قدم
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### دوسرا قدم
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### تیسرا قدم
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- لچکدار کیش سسٹم
+- قابل توسیع ڈیزائن (اس کے اوپر نئی صلاحیتوں کو شامل کرنے میں آسانی)
+- ہلکا پھلکا بنڈل (اپولو کلائنٹ سے ~5x ہلکا)
+- فائل اپ لوڈز اور آف لائن موڈ کے لیے سپورٹ
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### پہلا قدم
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### دوسرا قدم
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 11a9b5c614b7845b9e76d9ec88631e1d79ad356d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:09 -0500
Subject: [PATCH 2096/3820] New translations from-an-application.mdx
 (Vietnamese)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/vi/subgraphs/querying/from-an-application.mdx b/website/pages/vi/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..91c7faf04ea2
--- /dev/null
+++ b/website/pages/vi/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Truy vấn từ một ứng dụng
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Trình khám phá Graph
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Step 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Step 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Step 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Pagination
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Step 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Step 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- Extensible design (easing adding new capabilities on top of it)
+- Lightweight bundle (~5x lighter than Apollo Client)
+- Support for file uploads and offline mode
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Step 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 0614d9392d01dad33f70d0b54838a0de1717fb1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:10 -0500
Subject: [PATCH 2097/3820] New translations from-an-application.mdx (Marathi)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/mr/subgraphs/querying/from-an-application.mdx b/website/pages/mr/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..cd8f118b6db8
--- /dev/null
+++ b/website/pages/mr/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Querying from an Application
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### 1 ली पायरी
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### पायरी 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### पायरी 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Pagination
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### 1 ली पायरी
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### पायरी 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### पायरी 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- Extensible design (easing adding new capabilities on top of it)
+- Lightweight bundle (~5x lighter than Apollo Client)
+- Support for file uploads and offline mode
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### 1 ली पायरी
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### पायरी 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From feef5718732e6912546a4502ed9fc38bf17c1254 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:11 -0500
Subject: [PATCH 2098/3820] New translations from-an-application.mdx (Hindi)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/hi/subgraphs/querying/from-an-application.mdx b/website/pages/hi/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..011c56be7050
--- /dev/null
+++ b/website/pages/hi/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: एक एप्लिकेशन से क्वेरी करना
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- क्रॉस-चेन सबग्राफ हैंडलिंग: एक ही क्वेरी में कई सबग्राफ से पूछताछ
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- पूरी तरह से टाइप किया गया परिणाम
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### स्टेप 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### चरण 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### चरण 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- पृष्ठ पर अंक लगाना
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### स्टेप 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### चरण 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### चरण 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- एक्स्टेंसिबल डिज़ाइन (इसके शीर्ष पर नई क्षमताओं को जोड़ना आसान)
+- लाइटवेट बंडल (अपोलो क्लाइंट की तुलना में ~ 5x हल्का)
+- फ़ाइल अपलोड और ऑफ़लाइन मोड के लिए समर्थन
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### स्टेप 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### चरण 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From 35c472bf0b25d38cb206ce45f6a2c4df5527c526 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:12 -0500
Subject: [PATCH 2099/3820] New translations from-an-application.mdx (Swahili)

---
 .../querying/from-an-application.mdx          | 289 ++++++++++++++++++
 1 file changed, 289 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/querying/from-an-application.mdx

diff --git a/website/pages/sw/subgraphs/querying/from-an-application.mdx b/website/pages/sw/subgraphs/querying/from-an-application.mdx
new file mode 100644
index 000000000000..a9f8162ebcf0
--- /dev/null
+++ b/website/pages/sw/subgraphs/querying/from-an-application.mdx
@@ -0,0 +1,289 @@
+---
+title: Querying from an Application
+---
+
+Learn how to query The Graph from your application.
+
+## Getting GraphQL Endpoint
+
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+
+### Subgraph Studio
+
+```
+https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
+```
+
+### Graph Explorer
+
+```
+https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
+```
+
+With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+
+## Using Popular GraphQL Clients
+
+### Graph Client
+
+The Graph is providing its own GraphQL client, `graph-client` that supports unique features such as:
+
+- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
+- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Fully typed result
+
+> Note: `graph-client` is integrated with other popular GraphQL clients such as Apollo and URQL, which are compatible with environments such as React, Angular, Node.js, and React Native. As a result, using `graph-client` will provide you with an enhanced experience for working with The Graph.
+
+### Fetch Data with Graph Client
+
+Let's look at how to fetch data from a subgraph with `graph-client`:
+
+#### Step 1
+
+Install The Graph Client CLI in your project:
+
+```sh
+yarn add -D @graphprotocol/client-cli
+# or, with NPM:
+npm install --save-dev @graphprotocol/client-cli
+```
+
+#### Step 2
+
+Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+
+```graphql
+query ExampleQuery {
+  # this one is coming from compound-v2
+  markets(first: 7) {
+    borrowRate
+    cash
+    collateralFactor
+  }
+  # this one is coming from uniswap-v2
+  pair(id: "0x00004ee988665cdda9a1080d5792cecd16dc1220") {
+    id
+    token0 {
+      id
+      symbol
+      name
+    }
+    token1 {
+      id
+      symbol
+      name
+    }
+  }
+}
+```
+
+#### Step 3
+
+Create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+
+```yaml
+# .graphclientrc.yml
+sources:
+  - name: uniswapv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+  - name: compoundv2
+    handler:
+      graphql:
+        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+
+documents:
+  - ./src/example-query.graphql
+```
+
+#### Step 4
+
+Run the following The Graph Client CLI command to generate typed and ready to use JavaScript code:
+
+```sh
+graphclient build
+```
+
+#### Step 5
+
+Update your `.ts` file to use the generated typed GraphQL documents:
+
+```tsx
+import React, { useEffect } from 'react'
+// ...
+// we import types and typed-graphql document from the generated code (`..graphclient/`)
+import { ExampleQueryDocument, ExampleQueryQuery, execute } from '../.graphclient'
+
+function App() {
+  const [data, setData] = React.useState<ExampleQueryQuery>()
+
+  useEffect(() => {
+    execute(ExampleQueryDocument, {}).then((result) => {
+      setData(result?.data)
+    })
+  }, [setData])
+  return (
+    <div className="App">
+      <header className="App-header">
+        <img src={logo} className="App-logo" alt="logo" />
+        <p>Graph Client Example</p>
+        <fieldset>
+          {data && (
+            <form>
+              <label>Data</label>
+              <br />
+              <textarea value={JSON.stringify(data, null, 2)} readOnly rows={25} />
+            </form>
+          )}
+        </fieldset>
+      </header>
+    </div>
+  )
+}
+
+export default App
+```
+
+> **Important Note:** `graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you can [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples). However, if you choose to go with another client, keep in mind that **you won't be able to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+
+### Apollo Client
+
+[Apollo client](https://www.apollographql.com/docs/) is a common GraphQL client on front-end ecosystems. It's available for React, Angular, Vue, Ember, iOS, and Android.
+
+Although it's the heaviest client, it has many features to build advanced UI on top of GraphQL:
+
+- Advanced error handling
+- Pagination
+- Data prefetching
+- Optimistic UI
+- Local state management
+
+### Fetch Data with Apollo Client
+
+Let's look at how to fetch data from a subgraph with Apollo client:
+
+#### Step 1
+
+Install `@apollo/client` and `graphql`:
+
+```sh
+npm install @apollo/client graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
+
+const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = new ApolloClient({
+  uri: APIURL,
+  cache: new InMemoryCache(),
+})
+
+client
+  .query({
+    query: gql(tokensQuery),
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+#### Step 3
+
+To use variables, you can pass in a `variables` argument to the query:
+
+```javascript
+const tokensQuery = `
+  query($first: Int, $orderBy: BigInt, $orderDirection: String) {
+    tokens(
+      first: $first, orderBy: $orderBy, orderDirection: $orderDirection
+    ) {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+client
+  .query({
+    query: gql(tokensQuery),
+    variables: {
+      first: 10,
+      orderBy: 'createdAtTimestamp',
+      orderDirection: 'desc',
+    },
+  })
+  .then((data) => console.log('Subgraph data: ', data))
+  .catch((err) => {
+    console.log('Error fetching data: ', err)
+  })
+```
+
+### URQL Overview
+
+[URQL](https://formidable.com/open-source/urql/) is available within Node.js, React/Preact, Vue, and Svelte environments, with some more advanced features:
+
+- Flexible cache system
+- Extensible design (easing adding new capabilities on top of it)
+- Lightweight bundle (~5x lighter than Apollo Client)
+- Support for file uploads and offline mode
+
+### Fetch data with URQL
+
+Let's look at how to fetch data from a subgraph with URQL:
+
+#### Step 1
+
+Install `urql` and `graphql`:
+
+```sh
+npm install urql graphql
+```
+
+#### Step 2
+
+Query the API with the following code:
+
+```javascript
+import { createClient } from 'urql'
+
+const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+
+const tokensQuery = `
+  query {
+    tokens {
+      id
+      tokenID
+      contentURI
+      metadataURI
+    }
+  }
+`
+
+const client = createClient({
+  url: APIURL,
+})
+
+const data = await client.query(tokensQuery).toPromise()
+```

From dde6639fad284905ecc850f7325e31849c288255 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:13 -0500
Subject: [PATCH 2100/3820] New translations introduction.mdx (Romanian)

---
 .../ro/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/querying/introduction.mdx

diff --git a/website/pages/ro/subgraphs/querying/introduction.mdx b/website/pages/ro/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..4a0a6e29f4c4
--- /dev/null
+++ b/website/pages/ro/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Querying The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 8045a94d76697a807da22cefe5c2e8ade0e87419 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:14 -0500
Subject: [PATCH 2101/3820] New translations introduction.mdx (French)

---
 .../fr/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/querying/introduction.mdx

diff --git a/website/pages/fr/subgraphs/querying/introduction.mdx b/website/pages/fr/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..f30a125cc465
--- /dev/null
+++ b/website/pages/fr/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Interroger The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 861779a0b4ccc610dea9b27597cca239f55a6b2f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:15 -0500
Subject: [PATCH 2102/3820] New translations introduction.mdx (Spanish)

---
 .../es/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/es/subgraphs/querying/introduction.mdx

diff --git a/website/pages/es/subgraphs/querying/introduction.mdx b/website/pages/es/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..2f4033f89fca
--- /dev/null
+++ b/website/pages/es/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Consultando The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From df32f24d589fa22d1e3e4ab61561cc9808d9f54a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:16 -0500
Subject: [PATCH 2103/3820] New translations introduction.mdx (Arabic)

---
 .../ar/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/querying/introduction.mdx

diff --git a/website/pages/ar/subgraphs/querying/introduction.mdx b/website/pages/ar/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..4a0a6e29f4c4
--- /dev/null
+++ b/website/pages/ar/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Querying The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 35ffa605d3f95984901671182d9706cbab4e8ee9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:17 -0500
Subject: [PATCH 2104/3820] New translations introduction.mdx (Czech)

---
 .../cs/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/querying/introduction.mdx

diff --git a/website/pages/cs/subgraphs/querying/introduction.mdx b/website/pages/cs/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..ee7b3a1eef3f
--- /dev/null
+++ b/website/pages/cs/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Dotazování na graf
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 878434f28957eab5b46ed233d4fcf85368155791 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:18 -0500
Subject: [PATCH 2105/3820] New translations introduction.mdx (German)

---
 .../de/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/de/subgraphs/querying/introduction.mdx

diff --git a/website/pages/de/subgraphs/querying/introduction.mdx b/website/pages/de/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..4a0a6e29f4c4
--- /dev/null
+++ b/website/pages/de/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Querying The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From e605f3299adc9c2a1dca5f2461a363ab975b1126 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:19 -0500
Subject: [PATCH 2106/3820] New translations introduction.mdx (Italian)

---
 .../it/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/it/subgraphs/querying/introduction.mdx

diff --git a/website/pages/it/subgraphs/querying/introduction.mdx b/website/pages/it/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..bc68455214de
--- /dev/null
+++ b/website/pages/it/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Effettuare query di The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From ef6c74f6de557981ce3717370cfeefec37798e1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:20 -0500
Subject: [PATCH 2107/3820] New translations introduction.mdx (Japanese)

---
 .../ja/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/querying/introduction.mdx

diff --git a/website/pages/ja/subgraphs/querying/introduction.mdx b/website/pages/ja/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..e1ba5197b374
--- /dev/null
+++ b/website/pages/ja/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: The Graphのクエリ
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 73c8f5fd27c465d5fa2def70b9c69f292e5fc2d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:21 -0500
Subject: [PATCH 2108/3820] New translations introduction.mdx (Korean)

---
 .../ko/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/querying/introduction.mdx

diff --git a/website/pages/ko/subgraphs/querying/introduction.mdx b/website/pages/ko/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..4a0a6e29f4c4
--- /dev/null
+++ b/website/pages/ko/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Querying The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 53afdbadc9f7716ba9630d8d9042286168e55789 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:23 -0500
Subject: [PATCH 2109/3820] New translations introduction.mdx (Dutch)

---
 .../nl/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/querying/introduction.mdx

diff --git a/website/pages/nl/subgraphs/querying/introduction.mdx b/website/pages/nl/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..4a0a6e29f4c4
--- /dev/null
+++ b/website/pages/nl/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Querying The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 50611360267c8748f8ba0fbd45c9fa5439ab79c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:24 -0500
Subject: [PATCH 2110/3820] New translations introduction.mdx (Polish)

---
 .../pl/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/querying/introduction.mdx

diff --git a/website/pages/pl/subgraphs/querying/introduction.mdx b/website/pages/pl/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..4a0a6e29f4c4
--- /dev/null
+++ b/website/pages/pl/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Querying The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 473c119b7b6261413616c729ed9269c2056fe368 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:25 -0500
Subject: [PATCH 2111/3820] New translations introduction.mdx (Portuguese)

---
 .../pt/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/querying/introduction.mdx

diff --git a/website/pages/pt/subgraphs/querying/introduction.mdx b/website/pages/pt/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..b21639a155ef
--- /dev/null
+++ b/website/pages/pt/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Queries no The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Nota: Se encontrar erros 405 com um pedido GET ao URL do Graph Explorer, use um pedido POST.
+
+Cada subgraph publicado à Graph Network tem um URL singular de query no Graph Explorer para fazer queries diretos que podem ser encontrados ao navegar até a página de detalhes do subgraph e clicar no botão "Query" no canto superior direito.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 44790a9fe832fcd7e34c2e09ffce08bb6101b481 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:26 -0500
Subject: [PATCH 2112/3820] New translations introduction.mdx (Russian)

---
 .../ru/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/querying/introduction.mdx

diff --git a/website/pages/ru/subgraphs/querying/introduction.mdx b/website/pages/ru/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..789069d0d033
--- /dev/null
+++ b/website/pages/ru/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Запрос The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 7ea492522b14657bb775a97e68d88c5ca8760fe1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:27 -0500
Subject: [PATCH 2113/3820] New translations introduction.mdx (Swedish)

---
 .../sv/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/querying/introduction.mdx

diff --git a/website/pages/sv/subgraphs/querying/introduction.mdx b/website/pages/sv/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..88e0a21e5cb4
--- /dev/null
+++ b/website/pages/sv/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Fråga The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From d1e7d2d5e8601e19110a9bf2566a3a8e9cf59414 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:28 -0500
Subject: [PATCH 2114/3820] New translations introduction.mdx (Turkish)

---
 .../tr/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/querying/introduction.mdx

diff --git a/website/pages/tr/subgraphs/querying/introduction.mdx b/website/pages/tr/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..4a0a6e29f4c4
--- /dev/null
+++ b/website/pages/tr/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Querying The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From ea14143b696f52414d36b83eb8ae768308de0ab9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:29 -0500
Subject: [PATCH 2115/3820] New translations introduction.mdx (Ukrainian)

---
 .../uk/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/querying/introduction.mdx

diff --git a/website/pages/uk/subgraphs/querying/introduction.mdx b/website/pages/uk/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..4a0a6e29f4c4
--- /dev/null
+++ b/website/pages/uk/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Querying The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 74f742f616d77067817f6fe351799257ea99d6cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:30 -0500
Subject: [PATCH 2116/3820] New translations introduction.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/querying/introduction.mdx

diff --git a/website/pages/zh/subgraphs/querying/introduction.mdx b/website/pages/zh/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..118a1fe934c2
--- /dev/null
+++ b/website/pages/zh/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: 查询Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 6fe4d896a51a5769e675e90dfab582386a15a098 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:30 -0500
Subject: [PATCH 2117/3820] New translations introduction.mdx (Urdu (Pakistan))

---
 .../ur/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/querying/introduction.mdx

diff --git a/website/pages/ur/subgraphs/querying/introduction.mdx b/website/pages/ur/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..83b1bbd59519
--- /dev/null
+++ b/website/pages/ur/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: گراف سے کیوری کرنا
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 6d1affa28c6765b3aadb39e273de070c0076c911 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:31 -0500
Subject: [PATCH 2118/3820] New translations introduction.mdx (Vietnamese)

---
 .../vi/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/querying/introduction.mdx

diff --git a/website/pages/vi/subgraphs/querying/introduction.mdx b/website/pages/vi/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..4a0a6e29f4c4
--- /dev/null
+++ b/website/pages/vi/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Querying The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 7308763c5c30103a58ac01017b56664df67a55cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:32 -0500
Subject: [PATCH 2119/3820] New translations introduction.mdx (Marathi)

---
 .../mr/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/querying/introduction.mdx

diff --git a/website/pages/mr/subgraphs/querying/introduction.mdx b/website/pages/mr/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..4a0a6e29f4c4
--- /dev/null
+++ b/website/pages/mr/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Querying The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 1dd5c70389f10ff9ee76b2cac9c1c65b9637f9b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:33 -0500
Subject: [PATCH 2120/3820] New translations introduction.mdx (Hindi)

---
 .../hi/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/querying/introduction.mdx

diff --git a/website/pages/hi/subgraphs/querying/introduction.mdx b/website/pages/hi/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..ac50838549a7
--- /dev/null
+++ b/website/pages/hi/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: ग्राफ़ को क्वेरी करना
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From fa40a6a824a4efca60b8204cd226f202b4b8311d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:34 -0500
Subject: [PATCH 2121/3820] New translations introduction.mdx (Swahili)

---
 .../sw/subgraphs/querying/introduction.mdx    | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/querying/introduction.mdx

diff --git a/website/pages/sw/subgraphs/querying/introduction.mdx b/website/pages/sw/subgraphs/querying/introduction.mdx
new file mode 100644
index 000000000000..4a0a6e29f4c4
--- /dev/null
+++ b/website/pages/sw/subgraphs/querying/introduction.mdx
@@ -0,0 +1,21 @@
+---
+title: Querying The Graph
+---
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+
+![Query Subgraph Button](/img/query-button-screenshot.png)
+
+![Query Subgraph URL](/img/query-url-screenshot.png)
+
+Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
+
+As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+
+Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).

From 86f63320b27e969ca24adad325a8011738e68dc5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:35 -0500
Subject: [PATCH 2122/3820] New translations managing-api-keys.mdx (Romanian)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/ro/subgraphs/querying/managing-api-keys.mdx b/website/pages/ro/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..f7aff33ea926
--- /dev/null
+++ b/website/pages/ro/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Managing your API keys
+---
+
+## Overview
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Edit your key name
+   - Regenerate API keys
+   - View the current usage of the API key with stats:
+     - Number of queries
+     - Amount of GRT spent
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - View and manage the domain names authorized to use your API key
+   - Assign subgraphs that can be queried with your API key

From 4ed4492b372339efc9b6a6281d5c1302b7a57d7c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:36 -0500
Subject: [PATCH 2123/3820] New translations managing-api-keys.mdx (French)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/fr/subgraphs/querying/managing-api-keys.mdx b/website/pages/fr/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..d44a65306dc1
--- /dev/null
+++ b/website/pages/fr/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Gérer vos clés API
+---
+
+## Aperçu
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Modifiez le nom de votre clé
+   - Régénérer les clés API
+   - Affichez l'utilisation actuelle de la clé API avec les statistiques :
+     - Nombre de requêtes
+     - Montant de GRT dépensé
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - Visualisez et gérez les noms de domaine autorisés à utiliser votre clé API
+   - Attribuez des subgraphs qui peuvent être interrogés avec votre clé API

From e1dd2c0cc7945c57857dfc0ef34a367a992e1afa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:37 -0500
Subject: [PATCH 2124/3820] New translations managing-api-keys.mdx (Spanish)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/es/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/es/subgraphs/querying/managing-api-keys.mdx b/website/pages/es/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..cdbad6cb7c81
--- /dev/null
+++ b/website/pages/es/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Administración de tus claves API
+---
+
+## Descripción
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Editar el nombre de tu clave
+   - Regenerar las claves API
+   - Ver el uso actual de la clave API con estadísticas:
+     - Número de consultas
+     - Cantidad de GRT gastado
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - Ver y administrar los nombres de dominio autorizados a utilizar tu clave API
+   - Asignar subgrafos que puedan ser consultados con tu clave API

From 5988178b31c1e400598cd133ad1258ce1dfcc2dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:38 -0500
Subject: [PATCH 2125/3820] New translations managing-api-keys.mdx (Arabic)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/ar/subgraphs/querying/managing-api-keys.mdx b/website/pages/ar/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..f23017bf015e
--- /dev/null
+++ b/website/pages/ar/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Managing your API keys
+---
+
+## نظره عامة
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - تعديل اسم المفتاح الخاص بك
+   - إعادة إنشاء مفاتيح API
+   - عرض الاستخدام الحالي لمفتاح API مع الإحصائيات:
+     - عدد الاستعلامات
+     - كمية GRT التي تم صرفها
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - عرض وإدارة أسماء النطاقات المصرح لها باستخدام مفتاح API الخاص بك
+   - تعيين الـ subgraphs التي يمكن الاستعلام عنها باستخدام مفتاح API الخاص بك

From ff0cd9f9d8169231b57f6fb6b90922e44fd1b5c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:39 -0500
Subject: [PATCH 2126/3820] New translations managing-api-keys.mdx (Czech)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/cs/subgraphs/querying/managing-api-keys.mdx b/website/pages/cs/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..0f5721e5cbcb
--- /dev/null
+++ b/website/pages/cs/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Správa klíčů API
+---
+
+## Přehled
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Úprava názvu klíče
+   - Regenerace klíčů API
+   - Zobrazení aktuálního využití klíče API se statsi:
+     - Počet dotazů
+     - Výše vynaložených GRT
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - Zobrazení a správa názvů domén oprávněných používat váš klíč API
+   - Přiřazení podgrafů, na které se lze dotazovat pomocí klíče API

From e529c6be1117ebabd2f28e43ba39257c90e6e662 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:40 -0500
Subject: [PATCH 2127/3820] New translations managing-api-keys.mdx (German)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/de/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/de/subgraphs/querying/managing-api-keys.mdx b/website/pages/de/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..f7aff33ea926
--- /dev/null
+++ b/website/pages/de/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Managing your API keys
+---
+
+## Overview
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Edit your key name
+   - Regenerate API keys
+   - View the current usage of the API key with stats:
+     - Number of queries
+     - Amount of GRT spent
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - View and manage the domain names authorized to use your API key
+   - Assign subgraphs that can be queried with your API key

From 2a993998813417a74aa63cd064ecca054937a4f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:41 -0500
Subject: [PATCH 2128/3820] New translations managing-api-keys.mdx (Italian)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/it/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/it/subgraphs/querying/managing-api-keys.mdx b/website/pages/it/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..ea42572de442
--- /dev/null
+++ b/website/pages/it/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Gestione delle chiavi API
+---
+
+## Panoramica
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Modificare il nome della chiave
+   - Rigenerare le chiavi API
+   - Visualizza l'utilizzo attuale della chiave API con le statistiche:
+     - Numero di query
+     - Importo di GRT speso
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - Visualizzare e gestire i nomi di dominio autorizzati a utilizzare la chiave API
+   - Assegnare i subgraph che possono essere interrogati con la chiave API

From ed7383318d14a53cadba40bc08db8b7b938596ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:42 -0500
Subject: [PATCH 2129/3820] New translations managing-api-keys.mdx (Japanese)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/ja/subgraphs/querying/managing-api-keys.mdx b/website/pages/ja/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..fc7402c28349
--- /dev/null
+++ b/website/pages/ja/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: API キーの管理
+---
+
+## 概要
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - キー名の編集
+   - API キーの再生成
+   - API キーの現在の使用状況を統計で表示:
+     - クエリの数
+     - 使用した GRT の量
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - API キーの使用を許可されたドメイン名の表示と管理
+   - API キーでクエリ可能なサブグラフの割り当て

From 49898a725b7e7db763d287e4c3f7f6b5cafa94b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:43 -0500
Subject: [PATCH 2130/3820] New translations managing-api-keys.mdx (Korean)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/ko/subgraphs/querying/managing-api-keys.mdx b/website/pages/ko/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..f7aff33ea926
--- /dev/null
+++ b/website/pages/ko/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Managing your API keys
+---
+
+## Overview
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Edit your key name
+   - Regenerate API keys
+   - View the current usage of the API key with stats:
+     - Number of queries
+     - Amount of GRT spent
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - View and manage the domain names authorized to use your API key
+   - Assign subgraphs that can be queried with your API key

From cb9f138fd785d3ed13fc90e13ffd03f65baafd9d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:44 -0500
Subject: [PATCH 2131/3820] New translations managing-api-keys.mdx (Dutch)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/nl/subgraphs/querying/managing-api-keys.mdx b/website/pages/nl/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..f7aff33ea926
--- /dev/null
+++ b/website/pages/nl/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Managing your API keys
+---
+
+## Overview
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Edit your key name
+   - Regenerate API keys
+   - View the current usage of the API key with stats:
+     - Number of queries
+     - Amount of GRT spent
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - View and manage the domain names authorized to use your API key
+   - Assign subgraphs that can be queried with your API key

From 128a6936d9793ce8e2225f742c3f90cc5000745f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:45 -0500
Subject: [PATCH 2132/3820] New translations managing-api-keys.mdx (Polish)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/pl/subgraphs/querying/managing-api-keys.mdx b/website/pages/pl/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..f7aff33ea926
--- /dev/null
+++ b/website/pages/pl/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Managing your API keys
+---
+
+## Overview
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Edit your key name
+   - Regenerate API keys
+   - View the current usage of the API key with stats:
+     - Number of queries
+     - Amount of GRT spent
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - View and manage the domain names authorized to use your API key
+   - Assign subgraphs that can be queried with your API key

From f303465fe3c2630d6529b15cef67a1fdb90e18c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:46 -0500
Subject: [PATCH 2133/3820] New translations managing-api-keys.mdx (Portuguese)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/pt/subgraphs/querying/managing-api-keys.mdx b/website/pages/pt/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..0592d611312d
--- /dev/null
+++ b/website/pages/pt/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Como gerir as suas chaves de API
+---
+
+## Visão geral
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Renomear chave API
+- Regenerar chave API
+- Apagar chave API
+- Gestar limite de gastos: este é um limite opcional de gastos mensais para uma chave API, em USD. Este limite é por período de cobrança (mês do calendário).
+
+### API Key Details
+
+É possível clicar numa chave API individual para exibir a sua página de Detalhes:
+
+1. Under the **Overview** section, you can:
+   - Alterar o nome da sua chave
+   - Regenerar chaves de API
+   - Ver o uso atual da chave de API com estatísticas:
+     - Número de queries
+     - Quantia de GRT gasta
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - Visualizar e gerir os nomes de domínio autorizados a usar a sua chave de API
+   - Apontar subgraphs que podem ser sujeitos a queries com a sua chave de API

From d6a03bdb083b9061a4359a67a9cc91d991273415 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:47 -0500
Subject: [PATCH 2134/3820] New translations managing-api-keys.mdx (Russian)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/ru/subgraphs/querying/managing-api-keys.mdx b/website/pages/ru/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..002aa22be689
--- /dev/null
+++ b/website/pages/ru/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Управление вашими ключами API
+---
+
+## Обзор
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Отредактируйте свое ключевое имя
+   - Регенерировать ключи API
+   - Просмотр текущего использования ключа API со статистикой:
+     - Количество запросов
+     - Количество потраченных GRT
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - Просматривайте доменные имена, авторизованные для использования вашего API-ключа, и управляйте ими
+   - Назначьте субграфы, которые могут быть запрошены с помощью вашего API-ключа

From 2b7247fb82a0680bc559063208244b861e38cd15 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:48 -0500
Subject: [PATCH 2135/3820] New translations managing-api-keys.mdx (Swedish)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/sv/subgraphs/querying/managing-api-keys.mdx b/website/pages/sv/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..3c3ad4ba152e
--- /dev/null
+++ b/website/pages/sv/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Hantera dina API-nycklar
+---
+
+## Översikt
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Redigera nyckelns namn
+   - Återgenerera API-nycklar
+   - Visa aktuell användning av API-nyckeln med statistik:
+     - Antal förfrågningar
+     - Mängd GRT spenderad
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - Visa och hantera domännamn som har auktoriserats att använda din API-nyckel
+   - Koppla subgrafer som kan frågas med din API-nyckel

From 5364ff1f4995b197456bab0cf6be1b65e833c791 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:50 -0500
Subject: [PATCH 2136/3820] New translations managing-api-keys.mdx (Turkish)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/tr/subgraphs/querying/managing-api-keys.mdx b/website/pages/tr/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..f8ece448a813
--- /dev/null
+++ b/website/pages/tr/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Managing your API keys
+---
+
+## Genel Bakış
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Edit your key name
+   - Regenerate API keys
+   - View the current usage of the API key with stats:
+     - Number of queries
+     - Amount of GRT spent
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - View and manage the domain names authorized to use your API key
+   - Assign subgraphs that can be queried with your API key

From 1d738a1ac31f03e32f5997af01706e2d943f63ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:51 -0500
Subject: [PATCH 2137/3820] New translations managing-api-keys.mdx (Ukrainian)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/uk/subgraphs/querying/managing-api-keys.mdx b/website/pages/uk/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..26ab619d9279
--- /dev/null
+++ b/website/pages/uk/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Управління API-ключами
+---
+
+## Overview
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Змінювати ім'я вашого ключа
+   - Повторно створити API-ключі
+   - Переглянути поточне використання API-ключа з такою статистикою:
+     - Кількість запитів
+     - Кількість витрачених GRT
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - Переглядати доменні імена, яким дозволено використовувати ваш API-ключ та керувати цими іменами
+   - Призначати підграфи, з яких можна отримувати запити за допомогою API-ключа

From 56105cb05fb07cd4c78549ba5943b13ec8fdfb9f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:52 -0500
Subject: [PATCH 2138/3820] New translations managing-api-keys.mdx (Chinese
 Simplified)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/zh/subgraphs/querying/managing-api-keys.mdx b/website/pages/zh/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..381ed2a67447
--- /dev/null
+++ b/website/pages/zh/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: 管理您的 API 密钥
+---
+
+## 概述
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - 编辑您的密钥名称
+   - 重新生成 API 密钥
+   - 使用统计信息查看 API 密钥的当前使用情况：
+     - 查询数
+     - 花费的 GRT 金额
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - 查看和管理授权使用您的 API 密钥的域名
+   - 分配可以使用您的 API 密钥查询的子图

From 1772ec3f3b4a494764ccdff60fa2ab893de3d1f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:53 -0500
Subject: [PATCH 2139/3820] New translations managing-api-keys.mdx (Urdu
 (Pakistan))

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/ur/subgraphs/querying/managing-api-keys.mdx b/website/pages/ur/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..505edb314906
--- /dev/null
+++ b/website/pages/ur/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: اپنی API کلیدوں کا انتظام کرنا
+---
+
+## جائزہ
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - اپنی کلید کے نام کو ترمیم دیں
+   - API کلیدوں کو دوبارہ سے بنائیں
+   - اعدادوشمار کے ساتھ API کلید کا موجودہ استعمال دیکھیں:
+     - کیوریز کی تعداد
+     - GRT کو تعداد جو خرچ ہوئ ہے
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - اپنی API کلید استعمال کرنے کے لیے مجاز ڈومین ناموں کو دیکھیں اور ان کا نظم کریں
+   - سب گراف تفویض کریں جن سے آپ کی API کلید سے کیوری کیا جا سکتا ہے

From 53d7189e1598ec26bfa942345b8e5a10f385931d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:54 -0500
Subject: [PATCH 2140/3820] New translations managing-api-keys.mdx (Vietnamese)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/vi/subgraphs/querying/managing-api-keys.mdx b/website/pages/vi/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..7798f96071eb
--- /dev/null
+++ b/website/pages/vi/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Managing your API keys
+---
+
+## Tổng quan
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Edit your key name
+   - Regenerate API keys
+   - View the current usage of the API key with stats:
+     - Number of queries
+     - Amount of GRT spent
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - View and manage the domain names authorized to use your API key
+   - Assign subgraphs that can be queried with your API key

From 866f1196081f5b42b2f8712b4573cfccc20edb9e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:54 -0500
Subject: [PATCH 2141/3820] New translations managing-api-keys.mdx (Marathi)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/mr/subgraphs/querying/managing-api-keys.mdx b/website/pages/mr/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..945a4add2851
--- /dev/null
+++ b/website/pages/mr/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Managing your API keys
+---
+
+## सविश्लेषण
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Edit your key name
+   - Regenerate API keys
+   - View the current usage of the API key with stats:
+     - Number of queries
+     - Amount of GRT spent
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - View and manage the domain names authorized to use your API key
+   - Assign subgraphs that can be queried with your API key

From 5cce79d95a905786d708ea893fdc3a98fd0e985b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:55 -0500
Subject: [PATCH 2142/3820] New translations managing-api-keys.mdx (Hindi)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/hi/subgraphs/querying/managing-api-keys.mdx b/website/pages/hi/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..4f36f067d89d
--- /dev/null
+++ b/website/pages/hi/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: अपनी एपीआई कुंजियों का प्रबंधन
+---
+
+## अवलोकन
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - अपना कुंजी नाम संपादित करें
+   - एपीआई कुंजियों को पुन: उत्पन्न करें
+   - आंकड़ों के साथ एपीआई कुंजी का वर्तमान उपयोग देखें:
+     - प्रश्नों की संख्या
+     - जीआरटी की राशि खर्च की गई
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - अपनी API कुंजी का उपयोग करने के लिए प्राधिकृत डोमेन नाम देखें और प्रबंधित करें
+   - सबग्राफ असाइन करें जिन्हें आपकी एपीआई कुंजी से पूछा जा सकता है

From 2beaacae889545c1569638cce4d0685063b5d09c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:56 -0500
Subject: [PATCH 2143/3820] New translations managing-api-keys.mdx (Swahili)

---
 .../subgraphs/querying/managing-api-keys.mdx  | 34 +++++++++++++++++++
 1 file changed, 34 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/querying/managing-api-keys.mdx

diff --git a/website/pages/sw/subgraphs/querying/managing-api-keys.mdx b/website/pages/sw/subgraphs/querying/managing-api-keys.mdx
new file mode 100644
index 000000000000..f7aff33ea926
--- /dev/null
+++ b/website/pages/sw/subgraphs/querying/managing-api-keys.mdx
@@ -0,0 +1,34 @@
+---
+title: Managing your API keys
+---
+
+## Overview
+
+API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
+
+### Create and Manage API Keys
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
+
+The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+
+You can click the "three dots" menu to the right of a given API key to:
+
+- Rename API key
+- Regenerate API key
+- Delete API key
+- Manage spending limit: this is an optional monthly spending limit for a given API key, in USD. This limit is per billing period (calendar month).
+
+### API Key Details
+
+You can click on an individual API key to view the Details page:
+
+1. Under the **Overview** section, you can:
+   - Edit your key name
+   - Regenerate API keys
+   - View the current usage of the API key with stats:
+     - Number of queries
+     - Amount of GRT spent
+2. Under the **Security** section, you can opt into security settings depending on the level of control you’d like to have. Specifically, you can:
+   - View and manage the domain names authorized to use your API key
+   - Assign subgraphs that can be queried with your API key

From b505b7e561ee65c3394eccc34c674b99e0eca44d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:57 -0500
Subject: [PATCH 2144/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Romanian)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/ro/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/ro/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/ro/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From c2c86a92c802bc75f5fda1bea021ad664dc21451 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:58 -0500
Subject: [PATCH 2145/3820] New translations subgraph-id-vs-deployment-id.mdx
 (French)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/fr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/fr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..91eb7ec02307
--- /dev/null
+++ b/website/pages/fr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Identifiant du Subgraph VS. Identifiant de déploiement
+---
+
+Un Subgraph est identifié par un identifiant Subgraph (Subpgraph ID), et chaque version de ce subgraph est identifiée par un identifiant de déploiement (Deployment ID).
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Identifiant de déploiement
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Exemple d'endpoint utilisant l'identifiant de déploiement:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Identifiant du Subgraph
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 8aef2d53cf0c79ec5516d2a5c55f16a90a7249b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:22:59 -0500
Subject: [PATCH 2146/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Spanish)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/es/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/es/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/es/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/es/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 1687c3e4bc30fcdf7e10c146fd67df57bd33e524 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:01 -0500
Subject: [PATCH 2147/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Arabic)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/ar/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/ar/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/ar/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From f84a0ebaae0c989f04f90bc11847111a325886ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:02 -0500
Subject: [PATCH 2148/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Czech)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/cs/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/cs/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..7bef9e129e33
--- /dev/null
+++ b/website/pages/cs/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: ID podgrafu vs. ID nasazení
+---
+
+Podgraf je identifikován ID podgrafu a každá verze podgrafu je identifikována ID nasazení.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## ID nasazení
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Příklad koncového bodu, který používá ID nasazení:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## ID podgrafu
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 51f47ee0c73335febcc1e5b23738372176ae0d77 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:03 -0500
Subject: [PATCH 2149/3820] New translations subgraph-id-vs-deployment-id.mdx
 (German)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/de/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/de/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/de/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/de/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From df8cd1b4977862de36a98c92be68a89c35246585 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:04 -0500
Subject: [PATCH 2150/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Italian)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/it/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/it/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/it/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/it/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 9aae3851720a8fbaf73397bc84f53291ff07deba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:05 -0500
Subject: [PATCH 2151/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Japanese)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/ja/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/ja/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..d1964ae0764b
--- /dev/null
+++ b/website/pages/ja/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+サブグラフはサブグラフIDで識別され、サブグラフの各バージョンはデプロイメントIDで識別されます。
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Deployment ID を使用するエンドポイントの例：
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 9bbd6c3c7b742fe78461b1edb01860393c21c6aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:06 -0500
Subject: [PATCH 2152/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Korean)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/ko/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/ko/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/ko/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 7ffaac9631f6978cd1b4a948046af58b71d76511 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:07 -0500
Subject: [PATCH 2153/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Dutch)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/nl/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/nl/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/nl/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 5312928136b9c2c8ec6d0a3c13b875643aa53a73 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:08 -0500
Subject: [PATCH 2154/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Polish)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/pl/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/pl/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/pl/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 3245f4ec836d995b1d61f7af899a9a4c86989318 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:09 -0500
Subject: [PATCH 2155/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Portuguese)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/pt/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/pt/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..110f95ff2f23
--- /dev/null
+++ b/website/pages/pt/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: ID de Subgraph contra ID de Lançamento
+---
+
+Um subgraph é identificado por uma ID de Subgraph, e cada versão do subgraph é identificada por uma ID de Lançamento.
+
+Ao consultar um subgraph, qualquer das IDs pode ser usada, mas recomendamos usar a ID de Lançamento (Deployment ID) pela sua habilidade de especificar uma versão específica de um subgraph.
+
+Aqui estão algumas diferenças importantes entre as duas IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## ID de Lançamento
+
+A ID de Lançamento é o hash IPFS do arquivo manifest compilado, que refere a outros arquivos no IPFS em vez de URLS relativas no computador. Por exemplo, o manifest compilado pode ser acessado via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. Para mudar a ID de Lançamento, basta atualizar o arquivo manifest, por ex., modificar o arquivo de descrição como descrito na [documentação do manifest de subgraph](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+Quando queries são feitas com a ID de Lançamento de um subgraph, especificamos uma versão daquele subgraph para buscar. Usar a ID de Lançamento para consultar uma versão específica de subgraph resulta em um setup mais sofisticado e robusto, já que há controle total sobre a versão do subgraph a ser consultada. Porém, isto resulta na necessidade de atualizar o código de queries manualmente toda vez que uma nova versão do subgraph é editada.
+
+Exemplo de endpoint que usa ID de Lançamento:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## ID de Subgraph
+
+A ID de Subgraph é uma identificadora única para um subgraph. Ela permanece constante entre todas as versões de um subgraph. É recomendado usar a ID do Subgraph para consultar a versão mais recente de um subgraph, mas há obstáculos.
+
+Saiba que realizar queries com a ID do Subgraph pode fazer com que queries sejam respondidas por uma versão mais antiga do subgraph, porque a nova versão precisaria de mais tempo para sincronizar. Além disto, novas versões podem introduzir mudanças que podem quebrar o schema.
+
+Exemplo de endpoint que usa a ID de Subgraph: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 7de88567e423437f535fd2d285897a3997c67c1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:10 -0500
Subject: [PATCH 2156/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Russian)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/ru/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/ru/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/ru/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 2e741c7dd759f926025de0ce9d53a53070301040 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:11 -0500
Subject: [PATCH 2157/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Swedish)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/sv/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/sv/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/sv/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 5f55847507f273407504e58f1115f150ea2a245c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:12 -0500
Subject: [PATCH 2158/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Turkish)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/tr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/tr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/tr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From c67df34d3f5b4acceda4c09e3570d2ea0a8dc7a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:13 -0500
Subject: [PATCH 2159/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Ukrainian)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/uk/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/uk/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/uk/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From f384bc2e062674223d5211ed504b1d607a835c45 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:14 -0500
Subject: [PATCH 2160/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Chinese Simplified)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/zh/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/zh/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/zh/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 64abe10741bfbf9ffd35c1414c31af90ec28e4a2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:15 -0500
Subject: [PATCH 2161/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Urdu (Pakistan))

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/ur/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/ur/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..14128acd1789
--- /dev/null
+++ b/website/pages/ur/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: سب گراف شناخت بمقابلہ تعیناتی شناخت
+---
+
+سب گراف کی شناخت سب گراف شناخت کے ذریعے کی جاتی ہے، اور سب گراف کے ہر ورژن کی شناخت ایک تعیناتی شناخت سے ہوتی ہے۔
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## تعیناتی شناخت
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+مثالی اینڈ پوائنٹ جو سب گراف شناخت استعمال کرتا ہے:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## سب گراف شناخت
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 136d566ab128155db7d0fae6d2d47aa8b20d5da1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:16 -0500
Subject: [PATCH 2162/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Vietnamese)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/vi/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/vi/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/vi/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 439bfa8126930ed11f74da8144fcf721825e2638 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:17 -0500
Subject: [PATCH 2163/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Marathi)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/mr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/mr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/mr/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 20398634dd26a6fd13360248f562d69a10a1dafc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:18 -0500
Subject: [PATCH 2164/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Hindi)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/hi/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/hi/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/hi/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From b8e76ee682036f45ed2dbe673be900b4a19a8abd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:20 -0500
Subject: [PATCH 2165/3820] New translations subgraph-id-vs-deployment-id.mdx
 (Swahili)

---
 .../querying/subgraph-id-vs-deployment-id.mdx | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/querying/subgraph-id-vs-deployment-id.mdx

diff --git a/website/pages/sw/subgraphs/querying/subgraph-id-vs-deployment-id.mdx b/website/pages/sw/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
new file mode 100644
index 000000000000..103e470e14da
--- /dev/null
+++ b/website/pages/sw/subgraphs/querying/subgraph-id-vs-deployment-id.mdx
@@ -0,0 +1,27 @@
+---
+title: Subgraph ID vs Deployment ID
+---
+
+A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+
+When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+
+Here are some key differences between the two IDs: ![](/img/subgraph-id-vs-deployment-id.png)
+
+## Deployment ID
+
+The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+
+When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+
+Example endpoint that uses Deployment ID:
+
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/deployments/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
+
+## Subgraph ID
+
+The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+
+Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+
+Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`

From 52dfc3debf6604bae72c41376945708e95a68d64 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:21 -0500
Subject: [PATCH 2166/3820] New translations quick-start.mdx (Romanian)

---
 website/pages/ro/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/quick-start.mdx

diff --git a/website/pages/ro/subgraphs/quick-start.mdx b/website/pages/ro/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..13af8f0deb42
--- /dev/null
+++ b/website/pages/ro/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Quick Start
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Prerequisites
+
+- A crypto wallet
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Install the Graph CLI
+
+On your local machine, run one of the following commands:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+See the following screenshot for an example for what to expect when initializing your subgraph:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Once your subgraph is written, run the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From b0111ffb00e9b1924778e7dabd53adc94abba7c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:22 -0500
Subject: [PATCH 2167/3820] New translations quick-start.mdx (French)

---
 website/pages/fr/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/quick-start.mdx

diff --git a/website/pages/fr/subgraphs/quick-start.mdx b/website/pages/fr/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..be5c7e50bc6b
--- /dev/null
+++ b/website/pages/fr/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Démarrage rapide
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Conditions préalables
+
+- Un portefeuille crypto
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Installez la CLI Graph
+
+Sur votre machine locale, exécutez l'une des commandes suivantes :
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+La capture d'écran suivante donne un exemple de ce qui vous attend lors de l'initialisation de votre subgraph :
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Déployer votre subgraph
+
+N'oubliez pas que déployer n'est pas la même chose que publier.
+
+Lorsque vous déployez un subgraph, vous le poussez vers [Subgraph Studio](https://thegraph.com/studio/), où vous pouvez le tester, le mettre en scène/préproduction et l'examiner.
+
+Lorsque vous publiez un subgraph, vous le publiez sur la blockchain vers le réseau décentralisé.
+
+Une fois votre subgraph écrit, exécutez les commandes suivantes :
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authentifiez-vous et déployez votre subgraph. La clé de déploiement se trouve sur la page du subgraph dans Subgraph Studio.
+
+![Clé de déploiement](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Examiner votre subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Exécuter un exemple de requête.
+- Analyser votre subgraph dans le tableau de bord pour vérifier les informations.
+- Vérifier les logs sur le tableau de bord pour voir si des erreurs surviennent avec votre subgraph. Les logs d'un subgraph opérationnel ressembleront à ceci :
+
+  ![Logs du subgraph](/img/subgraph-logs-image.png)
+
+### 7. Publier votre subgraph sur The Graph Network⁠
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publier avec Subgraph Studio⁠
+
+Pour publier votre subgraph, cliquez sur le bouton "Publish" dans le tableau de bord.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Sélectionnez le réseau sur lequel vous souhaitez publier votre subgraph.
+
+#### Publication à partir de la CLI
+
+À partir de la version 0.73.0, vous pouvez également publier votre subgraph avec Graph CLI.
+
+Ouvrez le `graph-cli`.
+
+Utilisez les commandes suivantes :
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. Une fenêtre s'ouvrira, vous permettant de connecter votre portefeuille, d'ajouter des métadonnées et de déployer votre subgraph finalisé sur le réseau de votre choix.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Ajout de signal à votre subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - Cette action améliore la qualité du service, réduit la latence et renforce la redondance et la disponibilité du réseau pour votre subgraph.
+
+2. Si éligibles aux récompenses d'indexation, les Indexeurs reçoivent des récompenses en GRT proportionnelles au montant signalé.
+
+   - Il est recommandé de curer au moins 3 000 GRT pour attirer 3 Indexeurs. Vérifiez l'éligibilité aux récompenses en fonction de l'utilisation des fonctionnalités du subgraph et des réseaux supportés.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+Pour économiser sur les frais de gas, vous pouvez curer votre subgraph dans la même transaction que celle où vous le publiez en sélectionnant cette option :
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Interroger votre subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From f5757c8f6c374e330021e214c662ec9ecacf501f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:23 -0500
Subject: [PATCH 2168/3820] New translations quick-start.mdx (Spanish)

---
 website/pages/es/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/es/subgraphs/quick-start.mdx

diff --git a/website/pages/es/subgraphs/quick-start.mdx b/website/pages/es/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..7baa8638c0b1
--- /dev/null
+++ b/website/pages/es/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Comienzo Rapido
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Prerrequisitos
+
+- Una wallet crypto
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Instala the graph CLI
+
+En tu dispositivo, ejecuta alguno de los siguientes comandos:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+Ve la siguiente captura para un ejemplo de que debes de esperar cuando inicializes tu subgrafo:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Una vez escrito tu subgrafo, ejecuta los siguientes comandos:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From f09d7a1039e995595b83e5a4ef18aaceaff8cd6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:24 -0500
Subject: [PATCH 2169/3820] New translations quick-start.mdx (Arabic)

---
 website/pages/ar/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/quick-start.mdx

diff --git a/website/pages/ar/subgraphs/quick-start.mdx b/website/pages/ar/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..0c5cde32121a
--- /dev/null
+++ b/website/pages/ar/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: بداية سريعة
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## المتطلبات الأساسية
+
+- محفظة عملات رقمية
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Install the Graph CLI
+
+On your local machine, run one of the following commands:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> يمكنك العثور على الأوامر المتعلقة بالغراف الفرعي الخاص بك على صفحة الغراف الفرعي في (سبغراف استوديو) (https://thegraph.com/studio).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+يرجى مراجعة الصورة المرفقة كمثال عن ما يمكن توقعه عند تهيئة غرافك الفرعي:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+عند كتابة غرافك الفرعي، قم بتنفيذ الأوامر التالية:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From 34197e9f3c23d926e830b14e9d3262d03d9b4998 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:25 -0500
Subject: [PATCH 2170/3820] New translations quick-start.mdx (Czech)

---
 website/pages/cs/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/quick-start.mdx

diff --git a/website/pages/cs/subgraphs/quick-start.mdx b/website/pages/cs/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..40e3d4ff4d74
--- /dev/null
+++ b/website/pages/cs/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Rychlé spuštění
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Požadavky
+
+- Kryptopeněženka
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Nainstalujte Graph CLI
+
+V místním počítači spusťte jeden z následujících příkazů:
+
+Použitím [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Použitím [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> Příkazy pro konkrétní podgraf najdete na stránce podgrafu v [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+Na následujícím snímku najdete příklad toho, co můžete očekávat při inicializaci podgrafu:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Jakmile je podgraf napsán, spusťte následující příkazy:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Přidání signálu do podgrafu
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From 1629d64aa01ee256c59b8617d642abbbc0668767 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:26 -0500
Subject: [PATCH 2171/3820] New translations quick-start.mdx (German)

---
 website/pages/de/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/de/subgraphs/quick-start.mdx

diff --git a/website/pages/de/subgraphs/quick-start.mdx b/website/pages/de/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..f65232b018dc
--- /dev/null
+++ b/website/pages/de/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Schnellstart
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Prerequisites
+
+- Eine Krypto-Wallet
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Gehen Sie zu [Subgraph Studio] (https://thegraph.com/studio/) und verbinden Sie Ihre Wallet.
+
+Mit Subgraph Studio können Sie Subgraphen erstellen, verwalten, bereitstellen und veröffentlichen sowie API-Schlüssel erstellen und verwalten.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Installieren der Graph-CLI
+
+Führen Sie einen der folgenden Befehle auf Ihrem lokalen Computer aus:
+
+Verwendung von [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Verwendung von [yarn] (https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> Die Befehle für Ihren spezifischen Subgraphen finden Sie auf der Subgraphen-Seite in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+Mit dem folgenden Befehl wird Ihr Subgraph aus einem bestehenden Vertrag initialisiert:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+Der folgende Screenshot zeigt ein Beispiel dafür, was Sie bei der Initialisierung Ihres Untergraphen ( Subgraph ) erwarten können:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - definiert, welche Datenquellen Ihr Subgraph indizieren wird.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (mapping.ts) - Dies ist der Code, der die Daten aus Ihren Datenquellen in die im Schema definierten Entitäten übersetzt.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Denken Sie daran, dass die Bereitstellung nicht dasselbe ist wie die Veröffentlichung.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Sobald Ihr Subgraph geschrieben ist, führen Sie die folgenden Befehle aus:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Führen Sie eine Testabfrage durch.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Veröffentlichung mit Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Öffnen Sie den `graph-cli`.
+
+Verwenden Sie die folgenden Befehle:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. Indexer erhalten GRT Rewards auf der Grundlage des signalisierten Betrags, wenn sie für Indexing Rewards in Frage kommen.
+
+   - Es wird empfohlen, mindestens 3.000 GRT zu kuratieren, um 3 Indexer anzuziehen. Prüfen Sie die Berechtigung zum Reward anhand der Nutzung der Subgraph-Funktionen und der unterstützten Netzwerke.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph veröffentlichen](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From abdd95e022b505b35f421afedae1fb01f3178de4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:27 -0500
Subject: [PATCH 2172/3820] New translations quick-start.mdx (Italian)

---
 website/pages/it/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/it/subgraphs/quick-start.mdx

diff --git a/website/pages/it/subgraphs/quick-start.mdx b/website/pages/it/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..13af8f0deb42
--- /dev/null
+++ b/website/pages/it/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Quick Start
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Prerequisites
+
+- A crypto wallet
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Install the Graph CLI
+
+On your local machine, run one of the following commands:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+See the following screenshot for an example for what to expect when initializing your subgraph:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Once your subgraph is written, run the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From e5c32b15057b09df5507b2ac481e4f3a74ef4a68 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:28 -0500
Subject: [PATCH 2173/3820] New translations quick-start.mdx (Japanese)

---
 website/pages/ja/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/quick-start.mdx

diff --git a/website/pages/ja/subgraphs/quick-start.mdx b/website/pages/ja/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..88602845e7ae
--- /dev/null
+++ b/website/pages/ja/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: クイックスタート
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## 前提条件
+
+- クリプトウォレット
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Graph CLI をインストールする
+
+ローカル マシンで、次のいずれかのコマンドを実行します。
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> 特定のサブグラフのコマンドは、[Subgraph Studio](https://thegraph.com/studio/) のサブグラフ ページで見つけることができます。
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+サブグラフを初期化する際に予想されることの例については、次のスクリーンショットを参照してください。
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+サブグラフが作成されたら、次のコマンドを実行します。
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From b4b41423cbbfd05cb11d498d60ca8035b6289ec4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:29 -0500
Subject: [PATCH 2174/3820] New translations quick-start.mdx (Korean)

---
 website/pages/ko/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/quick-start.mdx

diff --git a/website/pages/ko/subgraphs/quick-start.mdx b/website/pages/ko/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..13af8f0deb42
--- /dev/null
+++ b/website/pages/ko/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Quick Start
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Prerequisites
+
+- A crypto wallet
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Install the Graph CLI
+
+On your local machine, run one of the following commands:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+See the following screenshot for an example for what to expect when initializing your subgraph:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Once your subgraph is written, run the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From 705b8081b2dd5b78c9ea23c524a1b6244f101d7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:30 -0500
Subject: [PATCH 2175/3820] New translations quick-start.mdx (Dutch)

---
 website/pages/nl/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/quick-start.mdx

diff --git a/website/pages/nl/subgraphs/quick-start.mdx b/website/pages/nl/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..d18b354df77c
--- /dev/null
+++ b/website/pages/nl/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Snelle Start
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Prerequisites
+
+- A crypto wallet
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Install the Graph CLI
+
+On your local machine, run one of the following commands:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+See the following screenshot for an example for what to expect when initializing your subgraph:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Once your subgraph is written, run the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From d10eaca44d9724519209d0b0f8cd0f67ee58b550 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:31 -0500
Subject: [PATCH 2176/3820] New translations quick-start.mdx (Polish)

---
 website/pages/pl/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/quick-start.mdx

diff --git a/website/pages/pl/subgraphs/quick-start.mdx b/website/pages/pl/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..02801a7032a6
--- /dev/null
+++ b/website/pages/pl/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: " Na start"
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Prerequisites
+
+- A crypto wallet
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Install the Graph CLI
+
+On your local machine, run one of the following commands:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+See the following screenshot for an example for what to expect when initializing your subgraph:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Once your subgraph is written, run the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From 5cc06f24e25b1bf6e9dbf35f78bac9e6428ef46d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:32 -0500
Subject: [PATCH 2177/3820] New translations quick-start.mdx (Portuguese)

---
 website/pages/pt/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/quick-start.mdx

diff --git a/website/pages/pt/subgraphs/quick-start.mdx b/website/pages/pt/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..7a98b37dc814
--- /dev/null
+++ b/website/pages/pt/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Começo Rápido
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Pré-requisitos
+
+- Uma carteira de criptomoedas
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Como instalar o Graph CLI
+
+Execute um dos seguintes comandos na sua máquina local:
+
+Uso de [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Uso de [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> Veja comandos para o seu subgraph específico na página do subgraph no [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+Veja a imagem a seguir para um exemplo do que esperar quando for inicializar o seu subgraph:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Quando o seu subgraph estiver escrito, execute os seguintes comandos:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Logs do subgraph](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publicação da CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. Uma janela será aberta para o programador conectar a sua carteira, adicionar metadados e lançar o seu subgraph finalizado a uma rede de sua escolha.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Como adicionar sinal ao seu subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Queries no seu subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From c74adb1c1b6775ead6388d89b5e0718ff46524ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:33 -0500
Subject: [PATCH 2178/3820] New translations quick-start.mdx (Russian)

---
 website/pages/ru/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/quick-start.mdx

diff --git a/website/pages/ru/subgraphs/quick-start.mdx b/website/pages/ru/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..c78e441da896
--- /dev/null
+++ b/website/pages/ru/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Быстрый старт
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Предварительные требования
+
+- Криптовалютный кошелек
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Перейдите в [Subgraph Studio](https://thegraph.com/studio/) и подключите свой кошелек.
+
+Subgraph Studio позволяет создавать, управлять, развертывать и публиковать субграфы, а также создавать и управлять API-ключами.
+
+Нажмите "Создать субграф". Рекомендуется называть субграф с использованием Заглавного регистра: "Subgraph Name Chain Name".
+
+### 2. Установка Graph CLI
+
+Выполните одну из следующих команд на своём локальном компьютере:
+
+Использование [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Использование [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Инициализация Вашего cубграфа
+
+> Вы можете найти команды для своего конкретного субграфа на странице субграфа в [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+Следующая команда инициализирует ваш субграф из существующего контракта:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+При инициализации субграфа CLI запросит у Вас следующую информацию:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+На следующем скриншоте показан пример того, чего следует ожидать при инициализации субграфа:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+Команда `init` на предыдущем шаге создает шаблон субграфа, который Вы можете использовать в качестве отправной точки для его разработки.
+
+При внесении изменений в субграф Вы будете работать в основном с тремя файлами:
+
+- Манифест (`subgraph.yaml`) — определяет, какие источники данных Ваш субграф будет индексировать.
+- Схема (`schema.graphql`) - Схема GraphQL определяет, какие данные Вы хотите извлечь из субграфа.
+- AssemblyScript Mappings (mapping.ts) - это код, который преобразует данные из Ваших источников данных в объекты, определенные в схеме.
+
+Для получения более детальной информации о том, как создать свой субграф, ознакомьтесь с разделом [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Развертывание Вашего субграфа
+
+Помните, развертывание — это не то же самое, что публикация.
+
+Когда Вы развертываете субграф, Вы загружаете его в [Subgraph Studio](https://thegraph.com/studio/), где можете его протестировать, подготовить и просмотреть.
+
+Когда Вы публикуете субграф, Вы публикуете его в децентрализованной сети на чейне.
+
+После того как Ваш субграф будет написан, выполните следующие команды:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Аутентифицируйте и разверните свой субграф. Ключ развертывания можно найти на странице Subgraph в Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Просмотр Вашего субграфа
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Запустить пример запроса.
+- Проанализировать Ваш субграф на панели управления для проверки информации.
+- Проверить логи на панели управления, чтобы убедиться, нет ли ошибок в Вашем субграфе. Логи рабочего субграфа будут выглядеть следующим образом:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### Публикация Вашего субграфа в сети The Graph
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Публикация с помощью Subgraph Studio
+
+Чтобы опубликовать свой субграф, нажмите кнопку «Опубликовать» на панели управления.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Выберите сеть, в которую хотите опубликовать свой субграф.
+
+#### Publishing from the CLI
+
+Начиная с версии 0.73.0, Вы также можете публиковать свой субграф с помощью Graph CLI.
+
+Откройте `graph-cli`.
+
+Используйте следующие команды:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - Это действие улучшает качество обслуживания, снижает задержку и увеличивает надежность и доступность сети для Вашего субграфа.
+
+2. Если индексаторы имеют право на получение вознаграждений за индексацию, они получат вознаграждения в GRT, в соответствии с количеством поданного сигнала.
+
+   - Рекомендуется добавить как минимум 3,000 GRT, чтобы привлечь 3 индексаторов. Проверьте право на вознаграждение на основе использования функций субграфа и поддерживаемых сетей.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+Чтобы сэкономить на расходах на газ, Вы можете курировать свой субграф в той же транзакции, в которой Вы его публикуете, выбрав эту опцию:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Запрос Вашего субграфа
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From 7351e4dc6631be36ac1d29d0de7f62448ac47fa4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:34 -0500
Subject: [PATCH 2179/3820] New translations quick-start.mdx (Swedish)

---
 website/pages/sv/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/quick-start.mdx

diff --git a/website/pages/sv/subgraphs/quick-start.mdx b/website/pages/sv/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..4cde193daafd
--- /dev/null
+++ b/website/pages/sv/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Snabbstart
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Förutsättningar
+
+- En kryptoplånbok
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Installera Graph CLI
+
+Kör ett av följande kommandon på din lokala dator:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+Se följande skärmdump för ett exempel för vad du kan förvänta dig när du initierar din subgraf:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+När din subgraf är skriven, kör följande kommandon:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From a16df9b364705d5482e34c22d3ddd7e9b86b8a38 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:36 -0500
Subject: [PATCH 2180/3820] New translations quick-start.mdx (Turkish)

---
 website/pages/tr/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/quick-start.mdx

diff --git a/website/pages/tr/subgraphs/quick-start.mdx b/website/pages/tr/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..96a7e63b1f92
--- /dev/null
+++ b/website/pages/tr/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Hızlı Başlangıç
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Ön Koşullar
+
+- Bir kripto cüzdanı
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+[Subgraph Studio](https://thegraph.com/studio/)'ya gidin ve cüzdanınızı bağlayın.
+
+Subgraph Studio, subgraph oluşturmanıza, yönetmenize, yayına almanıza ve yayımlamanıza, ayrıca API anahtarlarını oluşturmanıza ve yönetmenize olanak tanır.
+
+"Subgraph Oluştur" düğmesine tıklayın. Subgraph'in adını başlık formunda vermeniz önerilir: "Subgraph Adı Ağ Adı".
+
+### 2. Graph CLI'yi yükleyin
+
+Yerel makinenizde aşağıdaki komutlardan birini çalıştırın:
+
+[npm](https://www.npmjs.com/) kullanarak:
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+[yarn](https://yarnpkg.com/) kullanarak:
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Subgraph'inizi başlatın
+
+> Size ait spesifik subgraph'le ilgili komutları [Subgraph Studio](https://thegraph.com/studio/)'daki subgraph sayfasında bulabilirsiniz.
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+Aşağıdaki komut, subgraph'inizi mevcut bir akıllı sözleşmeden başlatır:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+Subgraph'inizi başlattığınızda, CLI sizden aşağıdaki bilgileri isteyecektir:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+Subgraph'ınızı başlatırken neyle karşılaşacağınıza dair bir örnek için aşağıdaki ekran görüntüsüne bakın:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+Önceki adımda `init` komutu, subgraph'inizi oluşturmak için kullanabileceğiniz bir iskelet subgraph yaratır.
+
+Subgraph'inizde değişiklik yaparken, ağırlıklı olarak üç dosya ile çalışacaksınız:
+
+- Manifesto (`subgraph.yaml`): Subgraph'inizin hangi veri kaynaklarını endeksleyeceğini tanımlar.
+- Şema (`schema.graphql`): Subgraph'ten hangi veriyi almak istediğinizi tanımlar.
+- AssemblyScript Eşlemeleri (`mapping.ts`): Veri kaynaklarınızdan gelen veriyi şemada tanımlanan varlıklara dönüştürür.
+
+Subgraph yazımı hakkında ayrıntılı bilgi için [Subgraph Oluşturma](/developing/creating-a-subgraph/) sayfasına göz atın.
+
+### 5. Subgraph'inizi yayına alın
+
+Unutmayın; yayına almak, yayımlamakla aynı şey değildir.
+
+Bir subgraph'i yayına aldığınızda, onu [Subgraph Studio](https://thegraph.com/studio/)'ya gönderirsiniz; burada subgraph'i test edebilir, yayına almaya hazırlayabilir ve inceleyebilirsiniz.
+
+Bir subgraph'i yayımladığınızda, onu merkeziyetsiz ağda, zincir üzerinde yayımlamış olursunuz.
+
+Subgraph'ınız yazıldıktan sonra aşağıdaki komutları çalıştırın:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Subgraph'inizi kimlik doğrulayıp yayına alın. Yayına alma anahtarını, Subgraph Studio'daki subgraph sayfasında bulabilirsiniz.
+
+![Yayına alma anahtarı](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Subgraph'inizi gözden geçirin
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Örnek bir sorgu çalıştırabilirsiniz.
+- Subgraph'iniz hakkında bilgi kontrol etmek için kontrol panelini analiz edebilirsiniz.
+- Subgraph'inizde hata olup olmadığını görmek için kontrol panelindeki kayıtları kontrol edin. Çalışan bir subgraph'in kayıtları şu şekilde görünecektir:
+
+  ![Subgraph kayıtları](/img/subgraph-logs-image.png)
+
+### 7. Subgraph'inizi The Graph Ağında yayımlayın
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Subgraph Studio ile yayımlama
+
+Subgraph'inizi yayımlamak için, kontrol panelindeki Yayımla düğmesine tıklayın.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Subgraph'inizi yayımlamak istediğiniz ağı seçin.
+
+#### Publishing from the CLI
+
+Sürüm 0.73.0 itibarıyla, subgraph'inizi Graph CLI ile de yayımlayabilirsiniz.
+
+`graph-cli`yi açın.
+
+Şu komutları kullanın:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - Bu işlem, hizmet kalitesini artırır, gecikmeyi azaltır ve subgraph'inizin ağdaki yedekliliğini ve müsaitliğini artırır.
+
+2. Endeksleme ödüllerine hak kazanan Endeksleyiciler sinyal miktarına bağlı olarak GRT ödülü alırlar.
+
+   - En az 3 Endeksleyici çekmek için en az 3.000 GRT küratörlük yapmanız önerilir. Subgraph özelliği kullanımı ve desteklenen ağlara bağlı olarak ödül hak kazanımlarının nasıl dağıtıldığını kontrol edin.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+Gas maliyetlerinden tasarruf etmek için, subgraph'inizi küratörlük işlemini, yayımlama işlemiyle aynı anda yapabilirsiniz. Bunun için şu seçeneği seçin:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Subgraph'inizi sorgulama
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From 0ad6493824ba98afe0ef78d56e0617b1dca95ab0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:37 -0500
Subject: [PATCH 2181/3820] New translations quick-start.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/quick-start.mdx

diff --git a/website/pages/uk/subgraphs/quick-start.mdx b/website/pages/uk/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..f97d3c023d90
--- /dev/null
+++ b/website/pages/uk/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Швидкий старт
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Prerequisites
+
+- Криптогаманець
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Встановлення Graph CLI
+
+На вашому локальному комп'ютері запустіть одну з наведених нижче команд:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+На наступному скриншоті ви можете побачити, чого варто очікувати при ініціалізації вашого підграфа:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Як тільки ваш підграф буде написаний, виконайте наступні команди:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From 29a4cf2b677f4730630da1f02fe798b9f216374b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:38 -0500
Subject: [PATCH 2182/3820] New translations quick-start.mdx (Chinese
 Simplified)

---
 website/pages/zh/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/quick-start.mdx

diff --git a/website/pages/zh/subgraphs/quick-start.mdx b/website/pages/zh/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..90b4a43d6fef
--- /dev/null
+++ b/website/pages/zh/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: 快速开始
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## 先决条件
+
+- 一个加密钱包
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. 安装 Graph CLI
+
+在本地计算机上，运行以下命令之一：
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> 您可以在[Subgraph Studio](https://thegraph.com/studio/)的子图页面找到针对您特定子图的命令。
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+请参阅下面的屏幕截图，以获取初始化子图时所需的示例：
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+一旦您的子图被编写好，请运行以下命令：
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From e7b31c5931681340bcfdebbf0a85a561ce797950 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:40 -0500
Subject: [PATCH 2183/3820] New translations quick-start.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/quick-start.mdx

diff --git a/website/pages/ur/subgraphs/quick-start.mdx b/website/pages/ur/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..5998de2fad57
--- /dev/null
+++ b/website/pages/ur/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: فورا شروع کریں
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## شرطیں
+
+- ایک کرپٹو والیٹ
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. گراف CLI انسٹال کریں
+
+اپنی مقامی مشین پر، درج زیل کمانڈز میں سے ایک کو رن کریں:
+
+[npm](https://www.npmjs.com/) کا استعمال:
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+[yarn](https://yarnpkg.com/) کا استعمال:
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> آپ اپنے مخصوص سب گراف کے لیے سب گراف کے پیج پر [سب گراف سٹوڈیو](https://thegraph.com/studio/) میں کمانڈز تلاش کر سکتے ہیں.
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+اپنے سب گراف کو شروع کرتے وقت کیا توقع کی جائے اس کی مثال کے لیے درج ذیل اسکرین شاٹ دیکھیں:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+ایک بار آپ کا سب گراف لکھا جائے، درج ذیل کمانڈز رن کریں:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![سب گراف لاگز](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From 1260540d1c9afc13da5c276810864bf365b9f6bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:42 -0500
Subject: [PATCH 2184/3820] New translations quick-start.mdx (Vietnamese)

---
 website/pages/vi/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/quick-start.mdx

diff --git a/website/pages/vi/subgraphs/quick-start.mdx b/website/pages/vi/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..e41c12dfdc4c
--- /dev/null
+++ b/website/pages/vi/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Bắt đầu nhanh
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Điều kiện tiên quyết
+
+- A crypto wallet
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Install the Graph CLI
+
+On your local machine, run one of the following commands:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+See the following screenshot for an example for what to expect when initializing your subgraph:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Once your subgraph is written, run the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From e1fe88edd71acf0bc37bfe0ff66a63be304702c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:43 -0500
Subject: [PATCH 2185/3820] New translations quick-start.mdx (Marathi)

---
 website/pages/mr/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/quick-start.mdx

diff --git a/website/pages/mr/subgraphs/quick-start.mdx b/website/pages/mr/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..40ecc489c838
--- /dev/null
+++ b/website/pages/mr/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: क्विक स्टार्ट
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## पूर्वतयारी
+
+- एक क्रिप्टो वॉलेट
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. आलेख CLI स्थापित करा
+
+तुमच्या स्थानिक मशीनवर, खालीलपैकी एक कमांड चालवा:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+तुमचा सबग्राफ सुरू करताना काय अपेक्षा करावी याच्या उदाहरणासाठी खालील स्क्रीनशॉट पहा:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+तुमचा सबग्राफ लिहिल्यानंतर, खालील आदेश चालवा:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From 451b03fe173c2998f4983c1b815aff7416ee96e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:44 -0500
Subject: [PATCH 2186/3820] New translations quick-start.mdx (Hindi)

---
 website/pages/hi/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/quick-start.mdx

diff --git a/website/pages/hi/subgraphs/quick-start.mdx b/website/pages/hi/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..7728088cdfd8
--- /dev/null
+++ b/website/pages/hi/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: जल्दी शुरू
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## आवश्यक शर्तें
+
+- एक क्रिप्टो वॉलेट
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+[Subgraph Studio](https://thegraph.com/studio/) पर जाएँ और अपने वॉलेट को कनेक्ट करें।
+
+Subgraph Studio आपको सबग्राफ़ बनाने, प्रबंधित करने, तैनात करने और प्रकाशित करने की सुविधा देता है, साथ ही API कुंजी बनाने और प्रबंधित करने की भी अनुमति देता है।
+
+"एक सबग्राफ बनाएं" पर क्लिक करें। सबग्राफ का नाम टाइटल केस में रखनाrecommended है: "सबग्राफ नाम चेन नाम"।
+
+### 2. ग्राफ़ सीएलआई स्थापित करें
+
+अपनी स्थानीय मशीन पर, निम्न आदेशों में से कोई एक चलाएँ:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. अपना Subgraph इनिशियलाइज़ करें
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+निम्नलिखित आदेश एक मौजूदा अनुबंध से आपके Subgraph को प्रारंभ करता है:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+जब आप अपने subgraph को प्रारंभ करते हैं, CLI आपसे निम्नलिखित जानकारी मांगेगा:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+अपने सबग्राफ को इनिशियलाइज़ करते समय क्या अपेक्षा की जाए, इसके उदाहरण के लिए निम्न स्क्रीनशॉट देखें:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+पिछले चरण में `init` कमांड एक स्कैफोल्ड Subgraph बनाता है जिसे आप अपने Subgraph को बनाने के लिए प्रारंभिक बिंदु के रूप में उपयोग कर सकते हैं।
+
+जब आप Subgraph में बदलाव करते हैं, तो आप मुख्य रूप से तीन फाइलों के साथ काम करेंगे:
+
+- Manifest (subgraph.yaml) - मेनिफेस्ट परिभाषित करता है कि आपका Subgraph किस डेटा सोर्स को अनुक्रमित करेगा
+- Schema (schema.graphql) - ग्राफक्यूएल स्कीमा परिभाषित करता है कि आप Subgraph से कौन सा डेटा प्राप्त करना चाहते हैं
+- असेंबलीस्क्रिप्ट मैपिंग (mapping.ts) - यह वह कोड है जो स्कीमा में परिभाषित इकाई के लिए आपके डेटा सोर्स से डेटा का अनुवाद करता है।
+
+अपने उपग्राफ को लिखने के लिए विस्तृत विवरण के लिए, [सबग्राफ बनाना](/developing/creating-a-subgraph/) देखें।
+
+### 5. अपने Subgraph का परीक्षण करें
+
+याद रखें, तैनाती और प्रकाशन एक समान नहीं हैं।
+
+जब आप एक सबग्राफ तैनात करते हैं, तो आप इसे [सबग्राफ स्टूडियो](https://thegraph.com/studio/) पर भेजते हैं, जहां आप इसे परीक्षण, चरणबद्ध और समीक्षा कर सकते हैं।
+
+जब आप एक Subgraph प्रकाशित करते हैं, तो आप इसे विकेंद्रीकृत नेटवर्क पर ऑन-चेन प्रकाशित कर रहे हैं।
+
+एक बार आपका सबग्राफ लिखे जाने के बाद, निम्नलिखित कमांड चलाएँ:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+अपने सबग्राफ को प्रमाणित और तैनात करें। तैनाती key सबग्राफ स्टूडियो में सबग्राफ पेज पर पाई जा सकती है।
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. अपने Subgraph का परीक्षण करें
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- एक नमूना क्वेरी चलाएँ।
+- अपने Subgraph का विश्लेषण करने के लिए डैशबोर्ड में जानकारी देखें।
+- लॉग आपको बताएंगे कि क्या आपके Subgraph में कोई त्रुटि है। एक ऑपरेशनल Subgraph के लॉग इस तरह दिखेंगे:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. अपने Subgraph को ग्राफ़ के The Graph Network पर प्रकाशित करें
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Subgraph Studio से प्रकाशित
+
+अपने subgraph को प्रकाशित करने के लिए, डैशबोर्ड में Publish बटन पर क्लिक करें।
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+उस नेटवर्क का चयन करें जिस पर आप अपना Subgraph प्रकाशित करना चाहते हैं।
+
+#### Publishing from the CLI
+
+Version 0.73.0 के अनुसार, आप अपने subgraph को graph-cli के साथ भी publish कर सकते हैं।
+
+`graph-cli` खोलें।
+
+निम्नलिखित कमांड का उपयोग करें:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. एक विंडो खुलेगी, जो आपको अपनी वॉलेट कनेक्ट करने, मेटाडेटा जोड़ने, और अपने अंतिम Subgraph को आपकी पसंद के नेटवर्क पर डिप्लॉय करने की अनुमति देगी।
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - यह कार्रवाई सेवा की गुणवत्ता में सुधार करती है, विलंबता को कम करती है, और आपके Subgraph के लिए नेटवर्क की पुनरावृत्ति और उपलब्धता को बढ़ाती है।
+
+2. यदि इंडेक्सिंग पुरस्कारों के लिए योग्य हैं, तो Indexers संकेतित राशि के आधार पर GRT पुरस्कार प्राप्त करते हैं।
+
+   - कम से कम 3,000 GRT का चयन करना अनुशंसित है ताकि 3 Indexer को आकर्षित किया जा सके। Subgraph फ़ीचर उपयोग और समर्थित नेटवर्क के आधार पर पुरस्कार पात्रता की जांच करें।
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+गैस लागत को बचाने के लिए, आप इसे प्रकाशित करते समय अपने Subgraph को उसी लेनदेन में क्यूरेट कर सकते हैं, इस विकल्प का चयन करके:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From 59936b5ad4643f6d510f430a6986915a1b329fba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:45 -0500
Subject: [PATCH 2187/3820] New translations quick-start.mdx (Swahili)

---
 website/pages/sw/subgraphs/quick-start.mdx | 184 +++++++++++++++++++++
 1 file changed, 184 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/quick-start.mdx

diff --git a/website/pages/sw/subgraphs/quick-start.mdx b/website/pages/sw/subgraphs/quick-start.mdx
new file mode 100644
index 000000000000..13af8f0deb42
--- /dev/null
+++ b/website/pages/sw/subgraphs/quick-start.mdx
@@ -0,0 +1,184 @@
+---
+title: Quick Start
+---
+
+Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
+
+## Prerequisites
+
+- A crypto wallet
+- A smart contract address on a [supported network](/supported-networks/)
+- [Node.js](https://nodejs.org/) installed
+- A package manager of your choice (`npm`, `yarn` or `pnpm`)
+
+## How to Build a Subgraph
+
+### 1. Create a subgraph in Subgraph Studio
+
+Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+
+Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
+
+Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+
+### 2. Install the Graph CLI
+
+On your local machine, run one of the following commands:
+
+Using [npm](https://www.npmjs.com/):
+
+```sh
+npm install -g @graphprotocol/graph-cli@latest
+```
+
+Using [yarn](https://yarnpkg.com/):
+
+```sh
+yarn global add @graphprotocol/graph-cli
+```
+
+### 3. Initialize your subgraph
+
+> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
+
+The `graph init` command will automatically create a scaffold of a subgraph based on your contract's events.
+
+The following command initializes your subgraph from an existing contract:
+
+```sh
+graph init
+```
+
+If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+
+When you initialize your subgraph, the CLI will ask you for the following information:
+
+- **Protocol**: Choose the protocol your subgraph will be indexing data from.
+- **Subgraph slug**: Create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
+- **Directory**: Choose a directory to create your subgraph in.
+- **Ethereum network** (optional): You may need to specify which EVM-compatible network your subgraph will be indexing data from.
+- **Contract address**: Locate the smart contract address you’d like to query data from.
+- **ABI**: If the ABI is not auto-populated, you will need to input it manually as a JSON file.
+- **Start Block**: You should input the start block to optimize subgraph indexing of blockchain data. Locate the start block by finding the block where your contract was deployed.
+- **Contract Name**: Input the name of your contract.
+- **Index contract events as entities**: It is suggested that you set this to true, as it will automatically add mappings to your subgraph for every emitted event.
+- **Add another contract** (optional): You can add another contract.
+
+See the following screenshot for an example for what to expect when initializing your subgraph:
+
+![Subgraph command](/img/CLI-Example.png)
+
+### 4. Edit your subgraph
+
+The `init` command in the previous step creates a scaffold subgraph that you can use as a starting point to build your subgraph.
+
+When making changes to the subgraph, you will mainly work with three files:
+
+- Manifest (`subgraph.yaml`) - defines what data sources your subgraph will index.
+- Schema (`schema.graphql`) - defines what data you wish to retrieve from the subgraph.
+- AssemblyScript Mappings (`mapping.ts`) - translates data from your data sources to the entities defined in the schema.
+
+For a detailed breakdown on how to write your subgraph, check out [Creating a Subgraph](/developing/creating-a-subgraph/).
+
+### 5. Deploy your subgraph
+
+Remember, deploying is not the same as publishing.
+
+When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
+
+When you publish a subgraph, you are publishing it onchain to the decentralized network.
+
+Once your subgraph is written, run the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+````
+
+Authenticate and deploy your subgraph. The deploy key can be found on the subgraph's page in Subgraph Studio.
+
+![Deploy key](/img/subgraph-studio-deploy-key.jpg)
+
+````
+```sh
+
+graph auth <DEPLOY_KEY>
+
+graph deploy <SUBGRAPH_SLUG>
+```
+````
+
+The CLI will ask for a version label. It's strongly recommended to use [semantic versioning](https://semver.org/), e.g. `0.0.1`.
+
+### 6. Review your subgraph
+
+If you’d like to test your subgraph before publishing it, you can use [Subgraph Studio](https://thegraph.com/studio/) to do the following:
+
+- Run a sample query.
+- Analyze your subgraph in the dashboard to check information.
+- Check the logs on the dashboard to see if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+
+  ![Subgraph logs](/img/subgraph-logs-image.png)
+
+### 7. Publish your subgraph to The Graph Network
+
+Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+
+#### Publishing with Subgraph Studio
+
+To publish your subgraph, click the Publish button in the dashboard.
+
+![Publish a subgraph on Subgraph Studio](/img/publish-sub-transfer.png)
+
+Select the network to which you would like to publish your subgraph.
+
+#### Publishing from the CLI
+
+As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
+
+Open the `graph-cli`.
+
+Use the following commands:
+
+````
+```sh
+graph codegen && graph build
+```
+
+Then,
+
+```sh
+graph publish
+```
+````
+
+3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+
+![cli-ui](/img/cli-ui.png)
+
+To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+
+#### Adding signal to your subgraph
+
+1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
+
+   - This action improves quality of service, reduces latency, and enhances network redundancy and availability for your subgraph.
+
+2. If eligible for indexing rewards, Indexers receive GRT rewards based on the signaled amount.
+
+   - It’s recommended to curate at least 3,000 GRT to attract 3 Indexers. Check reward eligibility based on subgraph feature usage and supported networks.
+
+To learn more about curation, read [Curating](/resources/roles/curating/).
+
+To save on gas costs, you can curate your subgraph in the same transaction you publish it by selecting this option:
+
+![Subgraph publish](/img/studio-publish-modal.png)
+
+### 8. Query your subgraph
+
+You now have access to 100,000 free queries per month with your subgraph on The Graph Network!
+
+You can query your subgraph by sending GraphQL queries to its Query URL, which you can find by clicking the Query button.
+
+For more information about querying data from your subgraph, read [Querying The Graph](/subgraphs/querying/introduction/).

From 471d8df5ff8c83345d30b1b6b37db34886291dc1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:46 -0500
Subject: [PATCH 2188/3820] New translations introduction.mdx (Romanian)

---
 website/pages/ro/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ro/substreams/introduction.mdx

diff --git a/website/pages/ro/substreams/introduction.mdx b/website/pages/ro/substreams/introduction.mdx
new file mode 100644
index 000000000000..4fd0efb697aa
--- /dev/null
+++ b/website/pages/ro/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Getting Started
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 18b0d6020df18d000a98d9f8ed7b37e33eaae98d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:47 -0500
Subject: [PATCH 2189/3820] New translations introduction.mdx (French)

---
 website/pages/fr/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/fr/substreams/introduction.mdx

diff --git a/website/pages/fr/substreams/introduction.mdx b/website/pages/fr/substreams/introduction.mdx
new file mode 100644
index 000000000000..7ebdc90df818
--- /dev/null
+++ b/website/pages/fr/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## Le fonctionnement de Substreams en 4 étapes
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Documentation des Substreams
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Démarrage
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Élargissez vos connaissances
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 19e4e7e2196fd828fdf085480002f1ef93767228 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:48 -0500
Subject: [PATCH 2190/3820] New translations introduction.mdx (Spanish)

---
 website/pages/es/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/es/substreams/introduction.mdx

diff --git a/website/pages/es/substreams/introduction.mdx b/website/pages/es/substreams/introduction.mdx
new file mode 100644
index 000000000000..aca614fd3de9
--- /dev/null
+++ b/website/pages/es/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Empezando
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 7a6058f62c81b03c9bae8d273af40288e479a84a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:49 -0500
Subject: [PATCH 2191/3820] New translations introduction.mdx (Arabic)

---
 website/pages/ar/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ar/substreams/introduction.mdx

diff --git a/website/pages/ar/substreams/introduction.mdx b/website/pages/ar/substreams/introduction.mdx
new file mode 100644
index 000000000000..4fd0efb697aa
--- /dev/null
+++ b/website/pages/ar/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Getting Started
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 2de8c4a736cc7963001dc92988cf5415eeb6f6c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:50 -0500
Subject: [PATCH 2192/3820] New translations introduction.mdx (Czech)

---
 website/pages/cs/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/cs/substreams/introduction.mdx

diff --git a/website/pages/cs/substreams/introduction.mdx b/website/pages/cs/substreams/introduction.mdx
new file mode 100644
index 000000000000..8a6fd77d4e05
--- /dev/null
+++ b/website/pages/cs/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## Jak funguje Substreams ve 4 krocích
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Dokumentace Substreams
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Začínáme
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Rozšiřte své znalosti
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 1d2c2f82c6eeec59018aa15dffb89a9eb92fef54 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:51 -0500
Subject: [PATCH 2193/3820] New translations introduction.mdx (German)

---
 website/pages/de/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/de/substreams/introduction.mdx

diff --git a/website/pages/de/substreams/introduction.mdx b/website/pages/de/substreams/introduction.mdx
new file mode 100644
index 000000000000..4fd0efb697aa
--- /dev/null
+++ b/website/pages/de/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Getting Started
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From c87229cfbbab3bc9c32fa3ceeb99ce2027b672a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:52 -0500
Subject: [PATCH 2194/3820] New translations introduction.mdx (Italian)

---
 website/pages/it/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/it/substreams/introduction.mdx

diff --git a/website/pages/it/substreams/introduction.mdx b/website/pages/it/substreams/introduction.mdx
new file mode 100644
index 000000000000..4fd0efb697aa
--- /dev/null
+++ b/website/pages/it/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Getting Started
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 15c5320721ba94964fd0c37fea4f1de40b421f23 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:53 -0500
Subject: [PATCH 2195/3820] New translations introduction.mdx (Japanese)

---
 website/pages/ja/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ja/substreams/introduction.mdx

diff --git a/website/pages/ja/substreams/introduction.mdx b/website/pages/ja/substreams/introduction.mdx
new file mode 100644
index 000000000000..f614c157879d
--- /dev/null
+++ b/website/pages/ja/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## サブストリームの4つのステップ
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams ドキュメンテーション
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### はじめに
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### 知識を広げよう
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 6893b6dcbad4c067656a54f783cff5967ad5dc32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:54 -0500
Subject: [PATCH 2196/3820] New translations introduction.mdx (Korean)

---
 website/pages/ko/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ko/substreams/introduction.mdx

diff --git a/website/pages/ko/substreams/introduction.mdx b/website/pages/ko/substreams/introduction.mdx
new file mode 100644
index 000000000000..4fd0efb697aa
--- /dev/null
+++ b/website/pages/ko/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Getting Started
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 3b73aee12527abc331f14a1f95126aa02cfd4e5c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:55 -0500
Subject: [PATCH 2197/3820] New translations introduction.mdx (Dutch)

---
 website/pages/nl/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/nl/substreams/introduction.mdx

diff --git a/website/pages/nl/substreams/introduction.mdx b/website/pages/nl/substreams/introduction.mdx
new file mode 100644
index 000000000000..4fd0efb697aa
--- /dev/null
+++ b/website/pages/nl/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Getting Started
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 15147a78b70f05f3023899b0b5b4a78ca81e11cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:56 -0500
Subject: [PATCH 2198/3820] New translations introduction.mdx (Polish)

---
 website/pages/pl/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/pl/substreams/introduction.mdx

diff --git a/website/pages/pl/substreams/introduction.mdx b/website/pages/pl/substreams/introduction.mdx
new file mode 100644
index 000000000000..4fd0efb697aa
--- /dev/null
+++ b/website/pages/pl/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Getting Started
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 229ae25ca9a8031ceaaedb2c0187a78c3e13de7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:57 -0500
Subject: [PATCH 2199/3820] New translations introduction.mdx (Portuguese)

---
 website/pages/pt/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/pt/substreams/introduction.mdx

diff --git a/website/pages/pt/substreams/introduction.mdx b/website/pages/pt/substreams/introduction.mdx
new file mode 100644
index 000000000000..6436b653cd96
--- /dev/null
+++ b/website/pages/pt/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## Como o Substreams funciona em 4 passos
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Documentação do Substreams
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Como Começar
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expanda o Seu Conhecimento
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From bcdbcb6de6cf4f56f3af44d5117e6ff28ac69bcc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:58 -0500
Subject: [PATCH 2200/3820] New translations introduction.mdx (Russian)

---
 website/pages/ru/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ru/substreams/introduction.mdx

diff --git a/website/pages/ru/substreams/introduction.mdx b/website/pages/ru/substreams/introduction.mdx
new file mode 100644
index 000000000000..4ab50472e4f0
--- /dev/null
+++ b/website/pages/ru/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Начало работы
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From d21b94262d2644438f65120d3b652295c2d8622e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:23:59 -0500
Subject: [PATCH 2201/3820] New translations introduction.mdx (Swedish)

---
 website/pages/sv/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/sv/substreams/introduction.mdx

diff --git a/website/pages/sv/substreams/introduction.mdx b/website/pages/sv/substreams/introduction.mdx
new file mode 100644
index 000000000000..21bf04c38eb0
--- /dev/null
+++ b/website/pages/sv/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Komma igång
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From c88178709fcfd2070735287be7343739bc8b26e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:00 -0500
Subject: [PATCH 2202/3820] New translations introduction.mdx (Turkish)

---
 website/pages/tr/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/tr/substreams/introduction.mdx

diff --git a/website/pages/tr/substreams/introduction.mdx b/website/pages/tr/substreams/introduction.mdx
new file mode 100644
index 000000000000..b9a4ce5b3203
--- /dev/null
+++ b/website/pages/tr/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## Substreams Nasıl Çalışır - 4 Adımda
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Dökümantasyonu
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Buradan Başlayın
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Bilgi Dağarcığınızı Genişletin
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 269bf0dd61f92b553ec1ba672873beb24c65a5e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:01 -0500
Subject: [PATCH 2203/3820] New translations introduction.mdx (Ukrainian)

---
 website/pages/uk/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/uk/substreams/introduction.mdx

diff --git a/website/pages/uk/substreams/introduction.mdx b/website/pages/uk/substreams/introduction.mdx
new file mode 100644
index 000000000000..4fd0efb697aa
--- /dev/null
+++ b/website/pages/uk/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Getting Started
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From b1419ee3d61076a4e92352f94ebc1816a3fea8eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:02 -0500
Subject: [PATCH 2204/3820] New translations introduction.mdx (Chinese
 Simplified)

---
 website/pages/zh/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/zh/substreams/introduction.mdx

diff --git a/website/pages/zh/substreams/introduction.mdx b/website/pages/zh/substreams/introduction.mdx
new file mode 100644
index 000000000000..204b62272f81
--- /dev/null
+++ b/website/pages/zh/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## 子流的工作原理分为四个步骤
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## 子流文档
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### 开始
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### 知识拓展
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From a51d1b7d09f70fbbe4a63746a7a3230a855bbf96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:03 -0500
Subject: [PATCH 2205/3820] New translations introduction.mdx (Urdu (Pakistan))

---
 website/pages/ur/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ur/substreams/introduction.mdx

diff --git a/website/pages/ur/substreams/introduction.mdx b/website/pages/ur/substreams/introduction.mdx
new file mode 100644
index 000000000000..1995c2feae36
--- /dev/null
+++ b/website/pages/ur/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## سب سٹریمز 4 مراحل میں کیسے کام کرتا ہے۔
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## سب سٹریمز دستاویزات
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### شروع ہوا چاہتا ہے
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### اپنے علم کو وسعت دیں
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 9840a46fbfb535fd839b357ef281107a021cc777 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:04 -0500
Subject: [PATCH 2206/3820] New translations introduction.mdx (Vietnamese)

---
 website/pages/vi/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/vi/substreams/introduction.mdx

diff --git a/website/pages/vi/substreams/introduction.mdx b/website/pages/vi/substreams/introduction.mdx
new file mode 100644
index 000000000000..4fd0efb697aa
--- /dev/null
+++ b/website/pages/vi/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Getting Started
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From faf4ec078794553b5bfcdee1d0d62dc962eb1be4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:05 -0500
Subject: [PATCH 2207/3820] New translations introduction.mdx (Marathi)

---
 website/pages/mr/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/mr/substreams/introduction.mdx

diff --git a/website/pages/mr/substreams/introduction.mdx b/website/pages/mr/substreams/introduction.mdx
new file mode 100644
index 000000000000..8ea62ed22e98
--- /dev/null
+++ b/website/pages/mr/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### प्रारंभ करणे
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 6ba261f97fbff7cae54bedd7106e88a462cf4221 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:06 -0500
Subject: [PATCH 2208/3820] New translations introduction.mdx (Hindi)

---
 website/pages/hi/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/hi/substreams/introduction.mdx

diff --git a/website/pages/hi/substreams/introduction.mdx b/website/pages/hi/substreams/introduction.mdx
new file mode 100644
index 000000000000..1931389e00f5
--- /dev/null
+++ b/website/pages/hi/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams एक शक्तिशाली ब्लॉकचेन indexing तकनीक है जो The Graph Network में प्रदर्शन और स्केलेबिलिटी को बढ़ाने के लिए डिज़ाइन की गई है। यह निम्नलिखित सुविधाएँ प्रदान करती है:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### शुरू करना
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams रजिस्ट्र्री
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 6f2dde6bb60730e57eda0faf61daed8bc04f7253 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:07 -0500
Subject: [PATCH 2209/3820] New translations introduction.mdx (Swahili)

---
 website/pages/sw/substreams/introduction.mdx | 52 ++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/sw/substreams/introduction.mdx

diff --git a/website/pages/sw/substreams/introduction.mdx b/website/pages/sw/substreams/introduction.mdx
new file mode 100644
index 000000000000..4fd0efb697aa
--- /dev/null
+++ b/website/pages/sw/substreams/introduction.mdx
@@ -0,0 +1,52 @@
+---
+title: Introduction to Substreams
+---
+
+![Substreams Logo](/img/substreams-logo.png)
+
+Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+
+- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
+- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+
+## How Substreams Works in 4 Steps
+
+1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
+
+   ```rust
+   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+       let header = blk.header.as_ref().unwrap();
+
+       Ok(MyBlock {
+           number: blk.number,
+           hash: Hex::encode(&blk.hash),
+           parent_hash: Hex::encode(&header.parent_hash),
+       })
+   }
+   ```
+
+2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+
+3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
+
+4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
+
+## Substreams Documentation
+
+The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+
+To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+
+### Getting Started
+
+- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
+- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+
+### Expand Your Knowledge
+
+- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+
+### Substreams Registry
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 7f41c292791dcd746081b71f5bb2a3fc23430002 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:08 -0500
Subject: [PATCH 2210/3820] New translations introduction.mdx (Romanian)

---
 .../pages/ro/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/ro/substreams/sps/introduction.mdx

diff --git a/website/pages/ro/substreams/sps/introduction.mdx b/website/pages/ro/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/ro/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From e2200baab4cc3878ddaca49a3cc7ed04d8ff698a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:09 -0500
Subject: [PATCH 2211/3820] New translations introduction.mdx (French)

---
 .../pages/fr/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/fr/substreams/sps/introduction.mdx

diff --git a/website/pages/fr/substreams/sps/introduction.mdx b/website/pages/fr/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/fr/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 8f6c7b72d6dfb5596648b831af14cc27ba872b6c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:10 -0500
Subject: [PATCH 2212/3820] New translations introduction.mdx (Spanish)

---
 .../pages/es/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/es/substreams/sps/introduction.mdx

diff --git a/website/pages/es/substreams/sps/introduction.mdx b/website/pages/es/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/es/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 4aeedab8d17a51870758b4eef548799bc6a27c4b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:11 -0500
Subject: [PATCH 2213/3820] New translations introduction.mdx (Arabic)

---
 .../pages/ar/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/ar/substreams/sps/introduction.mdx

diff --git a/website/pages/ar/substreams/sps/introduction.mdx b/website/pages/ar/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/ar/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 31acd441ce0bb57f12fd84f337526e27a8912e15 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:12 -0500
Subject: [PATCH 2214/3820] New translations introduction.mdx (Czech)

---
 .../pages/cs/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/cs/substreams/sps/introduction.mdx

diff --git a/website/pages/cs/substreams/sps/introduction.mdx b/website/pages/cs/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/cs/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 2630eb0f7e734124030483e6709bdb18221deeff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:13 -0500
Subject: [PATCH 2215/3820] New translations introduction.mdx (German)

---
 .../pages/de/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/de/substreams/sps/introduction.mdx

diff --git a/website/pages/de/substreams/sps/introduction.mdx b/website/pages/de/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/de/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 2e53bb5693f0ca9a627b0551e719482d6b4435c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:14 -0500
Subject: [PATCH 2216/3820] New translations introduction.mdx (Italian)

---
 .../pages/it/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/it/substreams/sps/introduction.mdx

diff --git a/website/pages/it/substreams/sps/introduction.mdx b/website/pages/it/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/it/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From e1a803ef5dbc80a8c5074df280fe82659f925375 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:15 -0500
Subject: [PATCH 2217/3820] New translations introduction.mdx (Japanese)

---
 .../pages/ja/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/ja/substreams/sps/introduction.mdx

diff --git a/website/pages/ja/substreams/sps/introduction.mdx b/website/pages/ja/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/ja/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 8a8e9d5ff273ce3e8af2662301dfb42d2ccb626f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:16 -0500
Subject: [PATCH 2218/3820] New translations introduction.mdx (Korean)

---
 .../pages/ko/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/ko/substreams/sps/introduction.mdx

diff --git a/website/pages/ko/substreams/sps/introduction.mdx b/website/pages/ko/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/ko/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 3881dad8a2e46926da595db7ade53ba756890ad5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:17 -0500
Subject: [PATCH 2219/3820] New translations introduction.mdx (Dutch)

---
 .../pages/nl/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/nl/substreams/sps/introduction.mdx

diff --git a/website/pages/nl/substreams/sps/introduction.mdx b/website/pages/nl/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/nl/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 71f7034ab218a8a2ba906a485aee182de75e7e7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:18 -0500
Subject: [PATCH 2220/3820] New translations introduction.mdx (Polish)

---
 .../pages/pl/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/pl/substreams/sps/introduction.mdx

diff --git a/website/pages/pl/substreams/sps/introduction.mdx b/website/pages/pl/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/pl/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 3ad9f1d516eb7b9d781ac0205e23b951e17943f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:19 -0500
Subject: [PATCH 2221/3820] New translations introduction.mdx (Portuguese)

---
 .../pages/pt/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/pt/substreams/sps/introduction.mdx

diff --git a/website/pages/pt/substreams/sps/introduction.mdx b/website/pages/pt/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/pt/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 4107bcc0914980d59e86235b09ecf2b3ad655111 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:20 -0500
Subject: [PATCH 2222/3820] New translations introduction.mdx (Russian)

---
 .../pages/ru/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/ru/substreams/sps/introduction.mdx

diff --git a/website/pages/ru/substreams/sps/introduction.mdx b/website/pages/ru/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/ru/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From b4064797308eb47891e3bc2071ab3747bf0db075 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:21 -0500
Subject: [PATCH 2223/3820] New translations introduction.mdx (Swedish)

---
 .../pages/sv/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/sv/substreams/sps/introduction.mdx

diff --git a/website/pages/sv/substreams/sps/introduction.mdx b/website/pages/sv/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/sv/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 7fc5123478ba4edeebe28977d737f890778b03c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:22 -0500
Subject: [PATCH 2224/3820] New translations introduction.mdx (Turkish)

---
 .../pages/tr/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/tr/substreams/sps/introduction.mdx

diff --git a/website/pages/tr/substreams/sps/introduction.mdx b/website/pages/tr/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/tr/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 1b6cef3fb97b35f5f8e567ebf774a2e292ee2492 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:23 -0500
Subject: [PATCH 2225/3820] New translations introduction.mdx (Ukrainian)

---
 .../pages/uk/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/uk/substreams/sps/introduction.mdx

diff --git a/website/pages/uk/substreams/sps/introduction.mdx b/website/pages/uk/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/uk/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 689304bcb0a2d8f7ee7a08bf29c6b3441544328e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:24 -0500
Subject: [PATCH 2226/3820] New translations introduction.mdx (Chinese
 Simplified)

---
 .../pages/zh/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/zh/substreams/sps/introduction.mdx

diff --git a/website/pages/zh/substreams/sps/introduction.mdx b/website/pages/zh/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/zh/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 43554fc8b5ce4aea971713a6b43829da9b2bfc60 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:25 -0500
Subject: [PATCH 2227/3820] New translations introduction.mdx (Urdu (Pakistan))

---
 .../pages/ur/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/ur/substreams/sps/introduction.mdx

diff --git a/website/pages/ur/substreams/sps/introduction.mdx b/website/pages/ur/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/ur/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 9b8ec8277083d9e74ac996d3bd39085bab95b189 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:26 -0500
Subject: [PATCH 2228/3820] New translations introduction.mdx (Vietnamese)

---
 .../pages/vi/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/vi/substreams/sps/introduction.mdx

diff --git a/website/pages/vi/substreams/sps/introduction.mdx b/website/pages/vi/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/vi/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From edf33072fdf02ca11f737711491faf53b386d9ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:27 -0500
Subject: [PATCH 2229/3820] New translations introduction.mdx (Marathi)

---
 .../pages/mr/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/mr/substreams/sps/introduction.mdx

diff --git a/website/pages/mr/substreams/sps/introduction.mdx b/website/pages/mr/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/mr/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From 48ed0b572e92be1f07f2e246e952ce129b6d1b63 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:28 -0500
Subject: [PATCH 2230/3820] New translations introduction.mdx (Hindi)

---
 .../pages/hi/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/hi/substreams/sps/introduction.mdx

diff --git a/website/pages/hi/substreams/sps/introduction.mdx b/website/pages/hi/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..6ec6fc500928
--- /dev/null
+++ b/website/pages/hi/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+Substreams पैकेज (.spkg) का उपयोग करके, आपका subgraph पूर्व-सूचीबद्ध ब्लॉकचेन डेटा के एक स्ट्रीम तक पहुंच प्राप्त करता है। यह विशेष रूप से बड़े या जटिल ब्लॉकचेन नेटवर्क के साथ डेटा हैंडलिंग को अधिक कुशल और स्केलेबल बनाता है।
+
+इस तकनीक को सक्षम करने के दो तरीके हैं:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Entity Changes (https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out) का उपयोग करके: Substreams में अधिक लॉजिक लिखने से, आप सीधे graph-node में मॉड्यूल का आउटपुट प्राप्त कर सकते हैं। graph-node में, आप Substreams डेटा का उपयोग करके अपने उपग्रह संस्थाएं बना सकते हैं।
+
+यह वास्तव में इस पर निर्भर करता है कि आप अपनी लॉजिक को कहाँ रखते हैं, subgraph या Substreams में। ध्यान रखें कि यदि आपकी लॉजिक अधिकतर Substreams में है, तो इससे एक पैरेललाइज़्ड मॉडल का लाभ मिलता है, जबकि ट्रिगर्स graph-node में लाइनर रूप से उपभोग किए जाएंगे।
+
+नीचे दिए गए लिंक पर जाएं How-To गाइड्स के लिए जो आपको कोड-जनरेशन टूलिंग का उपयोग करके अपना पहला एंड-टू-एंड प्रोजेक्ट तेजी से बनाने में मदद करेंगे:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From fc8d56019d0bcbe477b7b13251b22bd50bda4b48 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:29 -0500
Subject: [PATCH 2231/3820] New translations introduction.mdx (Swahili)

---
 .../pages/sw/substreams/sps/introduction.mdx  | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 website/pages/sw/substreams/sps/introduction.mdx

diff --git a/website/pages/sw/substreams/sps/introduction.mdx b/website/pages/sw/substreams/sps/introduction.mdx
new file mode 100644
index 000000000000..bacd601bd011
--- /dev/null
+++ b/website/pages/sw/substreams/sps/introduction.mdx
@@ -0,0 +1,19 @@
+---
+title: Introduction to Substreams-Powered Subgraphs
+---
+
+By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+There are two methods of enabling this technology:
+
+Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+
+It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+
+Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+
+- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
+- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
+- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)

From b5f48dc992b48952d5490ffd206cfaf175ab7e00 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:30 -0500
Subject: [PATCH 2232/3820] New translations sps-faq.mdx (Romanian)

---
 website/pages/ro/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/ro/substreams/sps/sps-faq.mdx

diff --git a/website/pages/ro/substreams/sps/sps-faq.mdx b/website/pages/ro/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..18248fc069df
--- /dev/null
+++ b/website/pages/ro/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From cd98ec785921879f3e32f70739f488b5b57555e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:31 -0500
Subject: [PATCH 2233/3820] New translations sps-faq.mdx (French)

---
 website/pages/fr/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/fr/substreams/sps/sps-faq.mdx

diff --git a/website/pages/fr/substreams/sps/sps-faq.mdx b/website/pages/fr/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..2c25f5608eb4
--- /dev/null
+++ b/website/pages/fr/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## Que sont les sous-flux ?
+
+Développé par [StreamingFast](https://www.streamingfast.io/), Substreams est un moteur de traitement extrêmement puissant capable de consommer des flux riches de données blockchain. Substreams vous permet de raffiner et de structurer les données blockchain pour une digestion rapide et fluide par les applications des utilisateurs finaux. Plus précisément, Substreams est un moteur agnostique à la blockchain, parallélisé et axé sur le streaming, servant de couche de transformation des données blockchain. Propulsé par [Firehose](https://firehose.streamingfast.io/), il permet aux développeurs d'écrire des modules Rust, de s'appuyer sur des modules communautaires, de fournir une indexation très performante, et de [diriger(sink)](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) leurs données vers n'importe quelle destination.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## Qu'est-ce qu'un subgraph alimenté par des courants de fond ?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+Si vous êtes déjà familiarisé avec le développement de subgraphs, notez que les subgraphs alimentés par Substreams peuvent ensuite être interrogés, comme s'ils avaient été produits par la couche de transformation AssemblyScript, avec tous les avantages de Subgraph, comme la fourniture d'une API GraphQL dynamique et flexible.
+
+## En quoi les subgraphs alimentés par les courants secondaires sont-ils différents des subgraphs ?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## Quels sont les avantages de l'utilisation de subgraphs alimentés par des courants descendants ?
+
+Les subgraphs alimentés par Substreams combinent tous les avantages de Substreams avec la capacité d'intérrogation des subgraphs. Ils apportent une plus grande composabilité (la capacité des composants d'un système à être modifié et recombiné en une autre structure afin de répondre à des besoins précis.) et une indexation haute performance à The Graph. Ils permettent également de nouveaux cas d'utilisation de données; par exemple, une fois que vous avez construit votre subgraph alimenté par Substreams, vous pouvez réutiliser vos [modules Substreams](https://substreams.streamingfast.io/documentation/develop/manifest-modules) pour produire des sorties vers différents [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) tels que PostgreSQL, MongoDB et Kafka.
+
+## Quels sont les avantages de Substreams ?
+
+L'utilisation de Substreams présente de nombreux avantages, notamment:
+
+- Composable : Vous pouvez empiler les modules Substreams comme des blocs LEGO et construire des modules communautaires pour affiner les données publiques.
+
+- Indexation haute performance : Indexation plus rapide d'un ordre de grandeur grâce à des grappes d'opérations parallèles à grande échelle (comme BigQuery).
+
+- Sortez vos données n'importe où : Transférez vos données où vous le souhaitez : PostgreSQL, MongoDB, Kafka, subgraphs, fichiers plats, Google Sheets.
+
+- Programmable : Utilisez du code pour personnaliser l'extraction, effectuer des agrégations au moment de la transformation et modéliser vos résultats pour plusieurs puits.
+
+- Accès à des données supplémentaires qui ne sont pas disponibles dans le cadre de la RPC JSON
+
+- Tous les avantages du Firehose.
+
+## Tous les avantages du Firehose?
+
+Développé par [StreamingFast] (https://www.streamingfast.io/), le Firehose est une couche d'extraction de données de blockchain conçue à partir de zéro pour traiter l'historique complet des blockchains à des vitesses jusqu'alors inconnues . Obtenez une approche basée sur les fichiers et le streaming, il s'agit d'un composant essentiel de la suite de technologies open-source de StreamingFast et de la base de Substreams.
+
+Consultez la [documentation] (https://firehose.streamingfast.io/) pour en savoir plus sur le Firehose.
+
+## Quels sont les avantages du Firehose ?
+
+L'utilisation de Firehose présente de nombreux avantages, notamment:
+
+- Temps de latence le plus faible et pas d'interrogation : Les nœuds Firehose sont conçus pour faire la course afin de diffuser les données en bloc en premier, selon le principe "streaming-first".
+
+- Prévient les temps d'arrêt : Conçu dès le départ pour une haute disponibilité.
+
+- Ne manquez jamais le rythme : Le curseur du flux Firehose est conçu pour gérer les bifurcations et pour reprendre là où vous vous êtes arrêté dans n'importe quelle condition.
+
+- Modèle de données le plus riche :   Meilleur modèle de données qui inclut les changements de solde, l'arbre d'appel complet, les transactions internes, les journaux, les changements de stockage, les coûts du gaz, etc.
+
+- Exploite les fichiers plats : Les données de la blockchain sont extraites dans des fichiers plats, la ressource informatique la moins chère et la plus optimisée disponible.
+
+## Où les développeurs peuvent-ils trouver plus d'informations sur les subgraphs alimentés par Substreams et sur Substreams ?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+Le [dernier outil Substreams Codegen ](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) vous permettra de lancer un projet Substreams sans aucun code.
+
+## Quel est le rôle des modules Rust dans Substreams ?
+
+Les modules Rust sont l'équivalent des mappeurs AssemblyScript dans les subgraphs. Ils sont compilés dans WASM de la même manière, mais le modèle de programmation permet une exécution parallèle. Ils définissent le type de transformations et d'agrégations que vous souhaitez appliquer aux données brutes de la blockchain.
+
+Consultez [ documentation des modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) pour plus de détails.
+
+## Qu'est-ce qui rend Substreams composable ?
+
+Lors de l'utilisation de Substreams, la composition a lieu au niveau de la couche de transformation, ce qui permet de réutiliser les modules mis en cache.
+
+Par exemple, Alice peut créer un module de prix DEX, Bob peut l'utiliser pour créer un agrégateur de volume pour certains jetons qui l'intéressent, et Lisa peut combiner quatre modules de prix DEX individuels pour créer un oracle de prix. Une seule requête Substreams regroupera tous ces modules individuels, les reliera entre eux, pour offrir un flux de données beaucoup plus raffiné. Ce flux peut ensuite être utilisé pour alimenter un subgraph et être interrogé par les consommateurs.
+
+## Comment pouvez-vous créer et déployer un Subgraph basé sur Substreams ?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Où puis-je trouver des exemples de subgraphs et de subgraphs alimentés par des substreams ?
+
+Vous pouvez visiter [ce repo Github] (https://github.com/pinax-network/awesome-substreams) pour trouver des exemples de Substreams et de subgraphs alimentés par Substreams.
+
+## Que signifient les subgraphs et les subgraphs alimentés par des substreams pour le réseau graph ?
+
+L'intégration promet de nombreux avantages, notamment une indexation extrêmement performante et une plus grande composabilité grâce à l'exploitation des modules de la communauté et à leur développement.

From 16b6f72c7d0626ffa2a63ed8a8641e645bf1d282 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:32 -0500
Subject: [PATCH 2234/3820] New translations sps-faq.mdx (Spanish)

---
 website/pages/es/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/es/substreams/sps/sps-faq.mdx

diff --git a/website/pages/es/substreams/sps/sps-faq.mdx b/website/pages/es/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..18248fc069df
--- /dev/null
+++ b/website/pages/es/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 94a1c37d6b33d83b13fcaee25590f042421f78f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:33 -0500
Subject: [PATCH 2235/3820] New translations sps-faq.mdx (Arabic)

---
 website/pages/ar/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/ar/substreams/sps/sps-faq.mdx

diff --git a/website/pages/ar/substreams/sps/sps-faq.mdx b/website/pages/ar/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..f276258f5dc1
--- /dev/null
+++ b/website/pages/ar/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## ما هي الغرافات الفرعية المدعومة بسبستريمز؟
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+إذا كنت على دراية بتطوير الغراف الفرعي، فإن الغرافات الفرعية المدعومة بواسطة سبستريمز يمكن استعلامها بنفس الطريقة كما لو أنها تم إنتاجها بواسطة طبقة تحويل لغة أسيمبلي اسكريبت، بالإضافة إلى جميع فوائد الغراف الفرعي، مثل توفير واجهة برمجة تطبيقات ديناميكية ومرنة للغة استعلام الغراف.
+
+## كيف تختلف الغرافات الفرعية التي تعمل بسبستريمز عن الغرافات الفرعية؟
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## ما هي فوائد استخدام الغرافات الفرعية المدعومة بسبستريمز؟
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## ماهي فوائد سبستريمز؟
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- التوجيه لأي مكان: يمكنك توجيه بياناتك لأي مكان ترغب فيه: بوستجريسكيو، مونغو دي بي، كافكا، الغرافات الفرعية، الملفات المسطحة، جداول جوجل.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- الوصول إلى بيانات إضافية غير متاحة كجزء من إجراء الإستدعاء عن بعد للترميز الكائني لجافاسكريبت
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+تم تطوير فايرهوز بواسطة [StreamingFast] (https://www.streamingfast.io/) وهو طبقة استخراج بيانات سلاسل الكتل مصممة من الصفر لمعالجة كامل تاريخ سلاسل الكتل بسرعات لم يشهدها من قبل. يوفر نهجاً قائماً على الملفات وأولوية-التدفق، وهو مكون أساسي في مجموعة تقنيات ستريمنج فاست مفتوحة المصدر والأساس لسبستريمز.
+
+انتقل إلى [الوثائق](https://firehose.streamingfast.io/) لمعرفة المزيد حول فايرهوز.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- أقل تأخير وعدم الاستقصاء: بطريقة قائمة على أولوية-التدفق، تم تصميم نقاط فايرهوز للتسابق لدفع بيانات الكتلة أولاً.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- يستفيد من الملفات المسطحة: يتم استخراج بيانات سلسلة الكتل إلى ملفات مسطحة، وهي أرخص وأكثر موارد الحوسبة تحسيناً.
+
+## أين يمكن للمطورين الوصول إلى مزيد من المعلومات حول الغرافات الفرعية المدعومة بسبستريمز و سبستريمز؟
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+تعتبر وحدات رست مكافئة لمعينات أسمبلي اسكريبت في الغرافات الفرعية. يتم ترجمتها إلى ويب أسيمبلي بنفس الطريقة، ولكن النموذج البرمجي يسمح بالتنفيذ الموازي. تحدد وحدات رست نوع التحويلات والتجميعات التي ترغب في تطبيقها على بيانات سلاسل الكتل الخام.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+على سبيل المثال، يمكن لأحمد بناء وحدة أسعار اسواق الصرف اللامركزية، ويمكن لإبراهيم استخدامها لبناء مجمِّع حجم للتوكن المهتم بها، ويمكن لآدم دمج أربع وحدات أسعار ديكس فردية لإنشاء مورد أسعار. سيقوم طلب واحد من سبستريمز بتجميع جميع هذه الوحدات الفردية، وربطها معًا لتقديم تدفق بيانات أكثر تطوراً ودقة. يمكن استخدام هذا التدفق لملءغراف فرعي ويمكن الاستعلام عنه من قبل المستخدمين.
+
+## كيف يمكنك إنشاء ونشر غراف فرعي مدعوم بسبستريمز؟
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## أين يمكنني العثور على أمثلة على سبستريمز والغرافات الفرعية المدعومة بسبستريمز؟
+
+يمكنك زيارة [جيت هب](https://github.com/pinax-network/awesome-substreams) للعثور على أمثلة للسبستريمز والغرافات الفرعية المدعومة بسبستريمز.
+
+## ماذا تعني السبستريمز والغرافات الفرعية المدعومة بسبستريمز بالنسبة لشبكة الغراف؟
+
+إن التكامل مع سبستريمز والغرافات الفرعية المدعومة بسبستريمز واعدة بالعديد من الفوائد، بما في ذلك عمليات فهرسة عالية الأداء وقابلية أكبر للتركيبية من خلال استخدام وحدات المجتمع والبناء عليها.

From 4b0e9a94c6b1d84738587054a107ed7db1bda5f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:34 -0500
Subject: [PATCH 2236/3820] New translations sps-faq.mdx (Czech)

---
 website/pages/cs/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/cs/substreams/sps/sps-faq.mdx

diff --git a/website/pages/cs/substreams/sps/sps-faq.mdx b/website/pages/cs/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..9411df5bab8a
--- /dev/null
+++ b/website/pages/cs/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## Co jsou substreamu?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## Co jsou substreamu napájen podgrafy?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+Pokud jste již obeznámeni s vývojem podgrafů, pak vězte, že na podgrafy vytvořené pomocí Substreams se lze dotazovat stejně, jako kdyby byly vytvořeny transformační vrstvou AssemblyScript, se všemi výhodami Subgraphu, jako je poskytování dynamického a flexibilního GraphQL API.
+
+## Jak se liší substream, které jsou napájeny podgrafy, od podgrafů?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## Jaké jsou výhody používání substreamu, které jsou založeny na podgraf?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## Jaké jsou výhody Substreams?
+
+Používání ubstreams má mnoho výhod, mimo jiné:
+
+- Složitelný: Moduly Substreams můžete skládat na sebe jako kostky LEGO, stavět na komunitních moduly a dále vylepšovat veřejná data.
+
+- Vysoce výkonné indexování: Řádově rychlejší indexování prostřednictvím rozsáhlých klastrů paralelních operací (viz BigQuery).
+
+- Umyvadlo kdekoli: Data můžete ukládat kamkoli chcete: Vložte data do PostgreSQL, MongoDB, Kafka, podgrafy, ploché soubory, tabulky Google.
+
+- Programovatelné: Pomocí kódu můžete přizpůsobit extrakci, provádět agregace v čase transformace a modelovat výstup pro více zdrojů.
+
+- Přístup k dalším údajům, které nejsou k dispozici jako součást JSON RPC
+
+- Všechny výhody Firehose.
+
+## Co je Firehose?
+
+Firehose, vyvinutý společností [StreamingFast](https://www.streamingfast.io/), je vrstva pro extrakci dat z blockchainu, která byla od základu navržena tak, aby zpracovávala celou historii blockchainu dosud nevídanou rychlostí. Poskytuje přístup založený na souborech a streamování v první řadě a je klíčovou součástí sady open-source technologií StreamingFast a základem pro Substreams.
+
+Další informace o Firehose najdete v [dokumentaci](https://firehose.streamingfast.io/).
+
+## Jaké jsou výhody Firehose?
+
+Používání Firehose přináší mnoho výhod, včetně:
+
+- Nejnižší latence a žádné dotazování: Uzly Firehose jsou navrženy tak, aby se předháněly v odesílání blokových dat jako první.
+
+- Předchází výpadkům: Navrženo od základu pro vysokou dostupnost.
+
+- Nikdy nezmeškáte ani minutu: Proudový kurzor Firehose je navržen tak, aby si poradil s rozcestími a pokračoval tam, kde jste skončili, za jakýchkoli podmínek.
+
+- Nejbohatší datový model:  Nejlepší datový model, který zahrnuje změny zůstatku, celý strom volání, interní transakce, protokoly, změny v úložišti, náklady na plyn a další.
+
+- Využívá ploché soubory: Blockchain data jsou extrahována do plochých souborů, což je nejlevnější a nejoptimálnější dostupný výpočetní zdroj.
+
+## Kde mohou vývojáři získat více informací o substreamu, které jsou založeny na podgraf a substreamu?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## Jaká je role modulů Rust v Substreamu?
+
+Moduly Rust jsou ekvivalentem mapovačů AssemblyScript v podgraf. Jsou kompilovány do WASM podobným způsobem, ale programovací model umožňuje paralelní provádění. Definují druh transformací a agregací, které chcete aplikovat na surová data blockchainu.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## Co dělá Substreamy složitelnými?
+
+Při použití substreamů probíhá kompozice na transformační vrstvě, což umožňuje opakované použití modulů uložených v mezipaměti.
+
+Jako příklad může Alice vytvořit cenový modul DEX, Bob jej může použít k vytvoření agregátoru objemu pro některé tokeny, které ho zajímají, a Lisa může zkombinovat čtyři jednotlivé cenové moduly DEX a vytvořit cenové orákulum. Jediný požadavek Substreams zabalí všechny moduly těchto jednotlivců, propojí je dohromady a nabídne mnohem sofistikovanější tok dat. Tento proud pak může být použit k naplnění podgrafu a může být dotazován spotřebiteli.
+
+## Jak můžete vytvořit a nasadit Substreams využívající podgraf?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Kde najdu příklady podgrafů Substreams a Substreams-powered?
+
+Příklady podgrafů Substreams a Substreams-powered najdete na [tomto repozitáři Github](https://github.com/pinax-network/awesome-substreams).
+
+## Co znamenají substreams a podgrafy napájené substreams pro síť grafů?
+
+Integrace slibuje mnoho výhod, včetně extrémně výkonného indexování a větší složitelnosti díky využití komunitních modulů a stavění na nich.

From 03410bf7a98a4e9e6bdf6163158e4e39bf1171d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:35 -0500
Subject: [PATCH 2237/3820] New translations sps-faq.mdx (German)

---
 website/pages/de/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/de/substreams/sps/sps-faq.mdx

diff --git a/website/pages/de/substreams/sps/sps-faq.mdx b/website/pages/de/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..18248fc069df
--- /dev/null
+++ b/website/pages/de/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 7961eab730ecc1a8d56bd0ba52d3aab1d19e95e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:37 -0500
Subject: [PATCH 2238/3820] New translations sps-faq.mdx (Italian)

---
 website/pages/it/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/it/substreams/sps/sps-faq.mdx

diff --git a/website/pages/it/substreams/sps/sps-faq.mdx b/website/pages/it/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..18248fc069df
--- /dev/null
+++ b/website/pages/it/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 702d06bec5c1fbda8e3e09145faa1718a008b653 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:38 -0500
Subject: [PATCH 2239/3820] New translations sps-faq.mdx (Japanese)

---
 website/pages/ja/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/ja/substreams/sps/sps-faq.mdx

diff --git a/website/pages/ja/substreams/sps/sps-faq.mdx b/website/pages/ja/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..40696a284f37
--- /dev/null
+++ b/website/pages/ja/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## サブストリームとは何ですか?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## サブストリームによって動作するサブグラフは何ですか？
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+すでにサブグラフ開発に​​精通している場合は、AssemblyScript 変換層によって生成されたかのように、サブストリームを利用したサブグラフをクエリできることに注意してください。動的で柔軟な GraphQL API の提供など、サブグラフのすべての利点が得られます。
+
+## サブストリームを利用したサブグラフはサブグラフとどう違うのでしょうか?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## サブストリームを利用したサブグラフを使用する利点は何ですか?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## サブストリームの利点は何ですか?
+
+サブストリームを使用すると、次のような多くの利点があります。
+
+- コンポーザブル: レゴ ブロックのようなサブストリーム モジュールを積み重ね、コミュニティ モジュールを基にして公開データをさらに洗練させることができます。
+
+- 高パフォーマンスのインデックス作成: 並列操作の大規模なクラスター (BigQuery を考えてください) を通じて、桁違いに高速なインデックス作成を実現します。
+
+- 場所を選ばずにデータをどこにでも沈める: PostgreSQL、MongoDB、Kafka、サブグラフ、フラットファイル、Googleシート。
+
+- プログラム可能: コードを使用して抽出をカスタマイズし、変換時の集計を実行し、複数のシンクの出力をモデル化します。
+
+- JSON RPC の一部として利用できない追加データへのアクセス
+
+- Firehose のすべての利点。
+
+## 消防ホースとは何ですか?
+
+[StreamingFast](https://www.streamingfast.io/) によって開発された Firehose は、ブロックチェーンの全履歴をこれまで見たことのない速度で処理するためにゼロから設計されたブロックチェーン データ抽出レイヤーです。ファイルベースでストリーミングファーストのアプローチを提供するこれは、StreamingFast のオープンソース テクノロジ スイートの中核コンポーネントであり、サブストリームの基盤です。
+
+Firehose の詳細については、[documentation](https://firehose.streamingfast.io/) にアクセスしてください。
+
+## 消防ホースの利点は何ですか?
+
+Firehose を使用すると、次のような多くの利点があります。
+
+- 最低のレイテンシーとポーリングなし: ストリーミングファーストの方式で、Firehose ノードはブロック データを最初にプッシュするために競合するように設計されています。
+
+- ダウンタイムの防止: 高可用性を実現するためにゼロから設計されています。
+
+- ビートを見逃すことはありません: Firehose ストリーム カーソルは、フォークを処理し、どのような状況でも中断したところから続行するように設計されています。
+
+- 最も豊富なデータ モデル: 残高の変更、完全なコール ツリー、内部トランザクション、ログ、ストレージの変更、ガス料金などが含まれる最適なデータ モデル。
+
+- フラット ファイルの活用: ブロックチェーン データは、利用可能な最も安価で最適化されたコンピューティング リソースであるフラット ファイルに抽出されます。
+
+## 開発者は、サブストリームを利用したサブグラフとサブストリームに関する詳細情報にどこでアクセスできますか?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## サブストリームにおけるRustモジュールの役割は何ですか?
+
+Rust モジュールは、サブグラフの AssemblyScript マッパーに相当します。これらは同様の方法で WASM にコンパイルされますが、プログラミング モデルにより並列実行が可能になります。これらは、生のブロックチェーン データに適用する変換と集計の種類を定義します。
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## サブストリームを構成可能にするものは何ですか?
+
+サブストリームを使用すると、変換レイヤーで合成が行われ、キャッシュされたモジュールを再利用できるようになります。
+
+例として、AliceはDEX価格モジュールを構築し、Bobはそれを使用して興味のあるいくつかのトークンのボリューム集計モジュールを構築し、Lisaは4つの個々のDEX価格モジュールを組み合わせて価格オラクルを作成することができます。単一のSubstreamsリクエストは、これらの個々のモジュールをまとめ、リンクしてより洗練されたデータのストリームを提供します。そのストリームはその後、サブグラフを作成し、消費者によってクエリされることができます。
+
+## サブストリームを利用したサブグラフを構築してデプロイするにはどうすればよいでしょうか?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## サブストリームおよびサブストリームを利用したサブグラフの例はどこで見つけることができますか?
+
+[この Github リポジトリ](https://github.com/pinax-network/awesome-substreams) にアクセスして、サブストリームとサブストリームを利用したサブグラフの例を見つけることができます。
+
+## SubstreamsとSubstreamsを活用したサブグラフがThe Graph Networkにとってどのような意味を持つのでしょうか？
+
+この統合は、非常に高いパフォーマンスのインデクシングと、コミュニティモジュールを活用し、それらを基に構築することによる大きな組み合わせ可能性を含む多くの利点を約束しています。

From 2a5ad2119cd95ba1843fe0bcdbefbc3ac664d138 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:39 -0500
Subject: [PATCH 2240/3820] New translations sps-faq.mdx (Korean)

---
 website/pages/ko/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/ko/substreams/sps/sps-faq.mdx

diff --git a/website/pages/ko/substreams/sps/sps-faq.mdx b/website/pages/ko/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..18248fc069df
--- /dev/null
+++ b/website/pages/ko/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From f8fec313be735be77aa499a944ae69c914c6d118 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:39 -0500
Subject: [PATCH 2241/3820] New translations sps-faq.mdx (Dutch)

---
 website/pages/nl/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/nl/substreams/sps/sps-faq.mdx

diff --git a/website/pages/nl/substreams/sps/sps-faq.mdx b/website/pages/nl/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..18248fc069df
--- /dev/null
+++ b/website/pages/nl/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 2abf14b089d48e2bf2b46fb142f1e21f84ccef14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:40 -0500
Subject: [PATCH 2242/3820] New translations sps-faq.mdx (Polish)

---
 website/pages/pl/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/pl/substreams/sps/sps-faq.mdx

diff --git a/website/pages/pl/substreams/sps/sps-faq.mdx b/website/pages/pl/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..18248fc069df
--- /dev/null
+++ b/website/pages/pl/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From b9ba178076cbd6209bdc0032e25558a0093d7092 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:41 -0500
Subject: [PATCH 2243/3820] New translations sps-faq.mdx (Portuguese)

---
 website/pages/pt/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/pt/substreams/sps/sps-faq.mdx

diff --git a/website/pages/pt/substreams/sps/sps-faq.mdx b/website/pages/pt/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..55ba2bdea1a9
--- /dev/null
+++ b/website/pages/pt/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## O que são Substreams?
+
+Desenvolvido pela [StreamingFast](https://www.streamingfast.io/), o Substreams é um motor de processamento de poder excepcional, capaz de consumir fluxos ricos de dados em blockchain. O Substreams lhe permite refinar e moldar dados em blockchain para serem digeridos rápida e suavemente por aplicativos de utilizador final. Mais especificamente, o Substreams é um motor paralelizado e agnóstico a blockchains, que põe transmissões em primeiro lugar e serve como uma camada de transformação de dados em blockchain. Movido pelo [Firehose](https://firehose.streamingfast.io/), ele permite que programadores escrevam módulos em Rust, construam sobre módulos da comunidade, providenciem indexações de altíssimo desempenho, e mandar seus dados para qualquer destino com [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink).
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## O que são subgraphs movidos por substreams?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+Se você já for familiar com a programação de subgraphs, então note que subgraphs movidos a Substreams podem ser consultados do mesmo jeito que se tivessem sido produzidos pela camada de transformação em AssemblyScript, com todos os benefícios do Subgraph, como a providência de uma API GraphQL dinâmica e flexível.
+
+## Como subgraphs movidos a Substreams são diferentes de subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## Quais os benefícios do uso de subgraphs movidos a Substreams?
+
+Subgraphs movidos a Substreams combinam todos os benefícios do Substreams com o potencial de query de subgraphs. Eles também trazem mais composabilidade e indexação de alto desempenho ao The Graph. Eles também resultam em novos casos de uso de dados; por exemplo, após construir o seu Subgraph movido a Substreams, você pode reutilizar os seus [módulos de Substreams](https://substreams.streamingfast.io/documentation/develop/manifest-modules) para usar [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) diferentes, como PostgreSQL, MongoDB e Kafka.
+
+## Quais os benefícios do Substreams?
+
+Usar o Substreams incorre muitos benefícios, que incluem:
+
+- Compostável: Você pode empilhar módulos de Substreams como se fossem blocos de LEGO, e construir em cima de módulos da comunidade, para refinar dados públicos.
+
+- Indexação de alto desempenho: Indexação muito mais rápida através de clusters de larga escala de operações paralelas (como o BigQuery).
+
+- Mergulho em qualquer lugar: Mergulhe seus dados onde quiser: PostgreSQL, MongoDB, Kafka, subgraphs, arquivos planos, Google Sheets.
+
+- Programável: Use códigos para personalizar a extração, realizar agregações de tempo de transformação, e modelar o seu resultado para vários sinks.
+
+- Acesso a dados tradicionais que não são disponíveis como parte do RPC em JSON
+
+- Todos os benefícios do Firehose.
+
+## O que é o Firehose?
+
+Desenvolvido pela [StreamingFast](https://www.streamingfast.io/), o Firehose é uma camada de extração de dados em blockchain desenhada do zero para processar o histórico completo de blockchains em velocidades nunca antes vistas. Com uma abordagem baseada em arquivos e que dá prioridade a transmissões, ele é um componente central do conjunto de tecnologias de código aberto da StreamingFast, e a fundação do Substreams.
+
+Confira a [documentação](https://firehose.streamingfast.io/) para aprender mais sobre o Firehose.
+
+## Quais os benefícios do Firehose?
+
+Há muitos benefícios do uso do Firehose, que incluem:
+
+- Latência menor: De forma que prioriza as transmissões, os nodes do Firehouse são desenhados para correrem para revelar os dados do bloco em primeiro lugar.
+
+- Evita downtimes: Desenhado do zero para Alta Disponibilidade.
+
+- Não perde nada: O cursor de transmissões do Firehose é desenhado para lidar com forks e continuar de onde você parou em qualquer condição.
+
+- Modelo rico de dados:  O melhor modelo de dados, que inclui as mudanças de saldo, a árvore de chamadas completa, transações internas, logs, mudanças de armazenamento, custos de gas, e mais.
+
+- Uso de arquivos planos: Dados de blockchain são extraídos em arquivos planos, o recurso de computação mais barato e otimizado disponível.
+
+## Onde programadores podem acessar mais informações sobre Substreams e subgraphs movidos a Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+A [ferramenta de Codegen no Substreams mais recente](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) permitirá ao programador inicializar um projeto no Substreams sem a necessidade de código.
+
+## Qual é o papel de módulos em Rust no Substreams?
+
+Módulos de Rust são o equivalente aos mapeadores em AssemblyScript em subgraphs. Eles são compilados em WASM de forma parecida, mas o modelo de programação permite execuções paralelas. Eles definem a categoria de transformações e agregações que você quer aplicar aos dados de blockchain crus.
+
+Veja a [documentação dos módulos](https://substreams.streamingfast.io/documentation/develop/manifest-modules) para mais detalhes.
+
+## O que faz o Substreams compostável?
+
+Ao usar o Substreams, a composição é realizada na camada de transformação, permitindo o uso de módulos em cache.
+
+Como exemplo, Fulana pode construir um módulo de preço de DEX, Sicrano pode usá-lo para construir um agregador de volume para alguns tokens do seu interesse, e Beltrana pode combinar quatro módulos de preço de DEX individuais para criar um oráculo de preço. Um único pedido do Substreams empacotará todos estes módulos e os interligará para oferecer uma transmissão de dados muito mais refinada. Aquela transmissão pode então ser usada para popular um subgraph, e ser consultada pelos consumidores.
+
+## Como construir e publicar um Subgraph movido a Substreams?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Onde posso encontrar exemplos de Substreams e subgraphs movidos a Substreams?
+
+Você pode visitar [este repo do Github](https://github.com/pinax-network/awesome-substreams) para encontrar exemplos de Substreams e subgraphs movidos a Substreams.
+
+## O que Substreams e subgraphs movidos a Substreams significam para a Graph Network?
+
+A integração promete vários benefícios, incluindo indexações de altíssimo desempenho e mais composabilidade com o uso de módulos de comunidade e construção por cima deles.

From 5202339173cd39e92aa63875653e005a4c5f36d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:42 -0500
Subject: [PATCH 2244/3820] New translations sps-faq.mdx (Russian)

---
 website/pages/ru/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/ru/substreams/sps/sps-faq.mdx

diff --git a/website/pages/ru/substreams/sps/sps-faq.mdx b/website/pages/ru/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..7238752cd5f1
--- /dev/null
+++ b/website/pages/ru/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## Что такое субпотоки?
+
+Substreams (Субпотоки), разработанные [StreamingFast](https://www.streamingfast.io/), представляют собой исключительно мощный механизм обработки, способный потреблять обширные потоки блокчейн-данных. Субпотоки позволяют оптимизировать и формировать данные блокчейна для быстрого и бесперебойного использования приложениями конечных пользователей. В частности, Субпотоки - это независимый от блокчейна, распараллеленный и ориентированный на потоковую передачу движок, служащий в качестве уровня преобразования данных блокчейна. Работая на базе [Firehose](https://firehose.streamingfast.io), он позволяет разработчикам писать модули на языке Rust, использовать модули сообщества,обеспечивать крайне высокую производительность индексирования и [отправлять](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) свои данные в любое место.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## Что такое субграфы, работающие на основе Субпотоков?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+Если Вы уже знакомы с разработкой субграфов, обратите внимание на то, что к тому же можно запрашивать субграфы, работающие на основе Субпотоков, точно так же, как если бы они были созданы на уровне преобразования AssemblyScript, со всеми преимуществами Субграфа, такими как предоставление динамического и гибкого GraphQL API.
+
+## Чем субграфы, работающие на основе Субпотоков, отличаются от субграфов?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## Каковы преимущества использования субграфов, работающих на основе Субпотоков?
+
+Субграфы, работающие на основе Субпотоков, сочетают в себе все преимущества Субпотоков с возможностью запроса субграфов.Они обеспечивают более высокую совместимость и высокопроизводительное индексирование в The Graph. Они также позволяют создавать новые варианты использования данных; например, после того, как Вы создали свой субграф на базе Субпотоков, Вы можете повторно использовать свои [модули Субпотоков](https://substreams.streamingfast.io/documentation/develop/manifest-modules) для вывода в разные [приёмники](https://substreams.streamingfast.io/reference-and-specs/manifests#sink), такие как PostgreSQL, MongoDB и Kafka.
+
+## В чем преимущества Субпотоков?
+
+Использование Субпотоков имеет много преимуществ, в том числе:
+
+- Компонуемость: Вы можете объединять модули Субпотоков, как блоки LEGO, и опираться на модули сообщества, дополнительно уточняя общедоступные данные.
+
+- Высокопроизводительное индексирование: индексирование на порядки быстрее благодаря крупномасштабным кластерам параллельных операций (как пример, BigQuery).
+
+- Возможность загружать куда угодно: Загружайте Ваши данные в любое удобное для Вас место: PostgreSQL, MongoDB, Kafka, субграфы, плоские файлы, Google Sheets.
+
+- Программируемость: Используйте код для настройки извлечения, выполнения агрегирования во время преобразования и моделирования выходных данных для нескольких приемников.
+
+- Доступ к дополнительным данным, недоступным в составе JSON RPC
+
+- Все преимущества Firehose.
+
+## Что такое Firehose?
+
+Firehose, разработанный [StreamingFast](https://www.streamingfast.io/), представляет собой уровень извлечения данных блокчейна, разработанный с нуля для обработки полной истории блокчейнов на ранее невиданных скоростях. Обеспечивая подход, основанный на файлах и потоковой передаче, он является основным компонентом пакета технологий Streamingfast с открытым исходным кодом и основой для Субпотоков.
+
+Перейдите к [documentation](https://firehose.streamingfast.io/), чтобы узнать больше о Firehose.
+
+## В чем преимущества Firehose?
+
+Использование Firehose имеет много преимуществ, в том числе:
+
+- Наименьшая задержка и отсутствие опроса: В режиме потоковой передачи узлы Firehose спроектированы таким образом, чтобы первыми передавать данные блока.
+
+- Предотвращает простои: Разработан с нуля для обеспечения высокой доступности.
+
+- Никогда не пропустите ни одного момента: Курсор потока Firehose предназначен для обработки форков и продолжения работы с того места, где Вы остановились, в любых условиях.
+
+- Богатейшая модель данных:  Лучшая модель данных, которая включает изменения баланса, полное дерево вызовов, внутренние транзакции, логи, изменения в хранилище, затраты на газ и многое другое.
+
+- Использует плоские файлы: Данные блокчейна извлекаются в плоские файлы — самый дешевый и наиболее оптимизированный доступный вычислительный ресурс.
+
+## Где разработчики могут получить доступ к дополнительной информации о субграфах работающих на основе Субпотоков и о Субпотоках?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+[Новейший инструмент Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) позволит Вам загрузить проект Substreams без использования какого-либо кода.
+
+## Какова роль модулей Rust в Субпотоках?
+
+Модули Rust - это эквивалент мапперов AssemblyScript в субграфах. Они компилируются в WASM аналогичным образом, но модель программирования допускает параллельное выполнение. Они определяют, какие преобразования и агрегации необходимо применить к необработанным данным блокчейна.
+
+Подробную информацию см. в [документации по модулям](https://substreams.streamingfast.io/documentation/develop/manifest-modules).
+
+## Что делает Субпотоки компонуемыми?
+
+При использовании Субпотоков компоновка происходит на уровне преобразования, что позволяет повторно использовать кэшированные модули.
+
+Например, Алиса может создать ценовой модуль DEX, Боб может использовать его для создания агрегатора объемов для некоторых интересующих его токенов, а Лиза может объединить четыре отдельных ценовых модуля DEX, чтобы создать ценовой оракул. Один запрос Субпотоков упакует все эти отдельные модули, свяжет их вместе, чтобы предложить гораздо более уточненный поток данных. Затем этот поток может быть использован для заполнения субграфа и запрашиваться потребителями.
+
+## Как Вы можете создать и развернуть субграф, работающий на основе Субпотоков?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Где я могу найти примеры Субпотоков и субграфов, работающих на основе Субпотоков?
+
+Вы можете посетить [этот репозиторий на Github](https://github.com/pinax-network/awesome-substreams), чтобы найти примеры Субпотоков и субграфов, работающих на основе Субпотоков.
+
+## Что означают Субпотоки и субграфы, работающие на основе Субпотоков, для сети The Graph?
+
+Интеграция обещает множество преимуществ, включая чрезвычайно высокопроизводительную индексацию и большую компонуемость за счет использования модулей сообщества и развития на их основе.

From cbb7e66c8f2d0fb6648c3ad803d89da639539af6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:43 -0500
Subject: [PATCH 2245/3820] New translations sps-faq.mdx (Swedish)

---
 website/pages/sv/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/sv/substreams/sps/sps-faq.mdx

diff --git a/website/pages/sv/substreams/sps/sps-faq.mdx b/website/pages/sv/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..4207af84beb7
--- /dev/null
+++ b/website/pages/sv/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## Vad är Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## Vad är Substreams-drivna subgrafer?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+Om du redan är bekant med utveckling av subgrafer kan du notera att Substreams-drivna subgrafer sedan kan frågas på samma sätt som om de hade producerats av AssemblyScript omvandlingslagret, med alla fördelar med subgrafer, som att tillhandahålla en dynamisk och flexibel GraphQL API.
+
+## Hur skiljer sig Substreams-drivna subgrafer från subgrafer?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## Vilka fördelar har användning av Substreams-drivna subgrafer?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## Vilka fördelar har Substreams?
+
+Det finns många fördelar med att använda Substreams, inklusive:
+
+- Sammansättbarhet: Du kan stapla Substreams-moduler som LEGO-block och bygga på gemenskapsmoduler för att ytterligare förädla offentliga data.
+
+- Högpresterande indexering: Ordervärden snabbare indexering genom storskaliga kluster av parallella operationer (tänk BigQuery).
+
+- Utdata var som helst: Du kan sänka dina data var som helst du vill: PostgreSQL, MongoDB, Kafka, subgrafer, platta filer, Google Sheets.
+
+- Programmerbarhet: Använd kod för att anpassa extrahering, utföra transformationsbaserade aggregeringar och modellera din utdata för flera sänkar.
+
+- Tillgång till ytterligare data som inte är tillgänglig som en del av JSON RPC
+
+- Alla fördelar med Firehose.
+
+## Vad är Firehose?
+
+Utvecklat av [StreamingFast](https://www.streamingfast.io/), är Firehose ett blockkedjedata-extraktionslager som är utformat från grunden för att bearbeta blockkedjans fullständiga historik med hastigheter som tidigare inte var skådade. Genom att erbjuda en filbaserad och strömningsorienterad metod är det en kärnkomponent i StreamingFasts svit med öppen källkodstekniker och grunden för Substreams.
+
+Gå till [documentation](https://firehose.streamingfast.io/) för att lära dig mer om Firehose.
+
+## Vilka fördelar har Firehose?
+
+Det finns många fördelar med att använda Firehose, inklusive:
+
+- Lägsta latens och ingen avfrågning: I en strömningsorienterad stil är Firehose-noderna utformade för att snabbt skicka ut blockdata.
+
+- Förebygger driftstopp: Designat från grunden för hög tillgänglighet.
+
+- Missa aldrig en händelse: Firehose-strömmens markör är utformad för att hantera gafflar och att fortsätta där du avslutade under alla förhållanden.
+
+- Rikaste datamodell:  Bästa datamodell som inkluderar balansändringar, hela anropsträdet, interna transaktioner, loggar, lagringsändringar, gasavgifter och mer.
+
+- Använder platta filer: Blockkedjedata extraheras till platta filer, den billigaste och mest optimerade datorkällan som finns tillgänglig.
+
+## Var kan utvecklare få mer information om Substreams-drivna subgrafer och Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## Vad är rollen för Rust-moduler i Substreams?
+
+Rust-moduler är motsvarigheten till AssemblyScript-mappers i subgrafer. De kompileras till WASM på ett liknande sätt, men programmeringsmodellen tillåter parallell körning. De definierar vilken typ av omvandlingar och aggregeringar du vill tillämpa på råblockkedjedata.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## Vad gör Substreams sammansättbart?
+
+Vid användning av Substreams sker sammansättningen på omvandlingsnivån, vilket gör att cachade moduler kan återanvändas.
+
+Som exempel kan Alice bygga en DEX-prismodul, Bob kan använda den för att bygga en volymaggregator för vissa intressanta tokens, och Lisa kan kombinera fyra individuella DEX-prismoduler för att skapa en prisoracle. En enda Substreams-begäran kommer att paketera alla dessa individuella moduler, länka dem samman, för att erbjuda en mycket mer förädlad dataström. Den strömmen kan sedan användas för att fylla i en subgraf och frågas av användare.
+
+## Hur kan man bygga och distribuera en Substreams-drivna subgraf?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Var kan jag hitta exempel på Substreams och Substreams-drivna subgrafer?
+
+Du kan besöka [detta Github-repo](https://github.com/pinax-network/awesome-substreams) för att hitta exempel på Substreams och Substreams-drivna subgrafer.
+
+## Vad innebär Substreams och Substreams-drivna subgrafer för The Graph Network?
+
+Integrationen lovar många fördelar, inklusive extremt högpresterande indexering och ökad sammansättbarhet genom att dra nytta av gemenskapsmoduler och bygga vidare på dem.

From e6b5a6d02077c8e172d319fbcbd8da62c58957bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:45 -0500
Subject: [PATCH 2246/3820] New translations sps-faq.mdx (Turkish)

---
 website/pages/tr/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/tr/substreams/sps/sps-faq.mdx

diff --git a/website/pages/tr/substreams/sps/sps-faq.mdx b/website/pages/tr/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..e0d4b0e29a50
--- /dev/null
+++ b/website/pages/tr/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## Substreams nedir?
+
+[StreamingFast](https://www.streamingfast.io/) tarafından geliştirilen Substreams, zengin blokzinciri veri akışlarını işleyebilen son derece güçlü bir işlem motorudur. Substreams, blokzinciri verilerini son kullanıcı uygulamaları tarafından hızlı ve sorunsuz bir şekilde işlenmek üzere rafine etmenizi ve şekillendirmenizi sağlar. Daha spesifik olmak gerekirse, Substreams, farklı blokzincirleriyle uyumlu, paralelleştirilmiş ve akış öncelikli bir motor olup bir blokzinciri veri dönüşüm katmanı olarak işlev görür. [Firehose](https://firehose.streamingfast.io/) tarafından desteklenen Substreams, geliştiricilerin Rust modülleri yazmasına, topluluk modüllerini kullanarak geliştirme yapmasına, son derece yüksek performanslı endeksleme sağlamasına ve verilerini herhangi bir yere yönlendirmesine ([sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink)) olanak tanır.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## Substreams destekli subgraphlar nelerdir?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+Eğer subgraph geliştirme konusun aşina iseniz, aklınızda bulundurun ki, Substreams destekli subgraphlar AssemblyScript dönüştürme katmanı tarafından üretilmiş gibi sorgulanabilir ve dinamik ve esnek bir GraphQL API sağlayarak Subgraph avantajlarından yararlanabilir.
+
+## Substreams destekli subgraphlar'ın normal subgraphlar'dan farkı nedir?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## Substreams destekli subgraphlar kullanmanın avantajları nelerdir?
+
+Substreams destekli subgraph'ler, Substreams'in tüm avantajlarını subgraph'lerin sorgulanabilirliğiyle birleştirir. Bu yaklaşım, The Graph'e daha fazla birleştirilebilirlik ve yüksek performanslı endeksleme sağlar. Ayrıca, yeni veri kullanım senaryolarını mümkün kılar. Örneğin, Substreams destekli subgraph'inizi oluşturduktan sonra, [Substreams modüllerinizi](https://substreams.streamingfast.io/documentation/develop/manifest-modules) PostgreSQL, MongoDB ve Kafka gibi farklı [veri hedeflerine](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) çıktı almak için yeniden kullanabilirsiniz.
+
+## Substreams'in faydaları nelerdir?
+
+Substreams kullanmanın birçok faydası vardır, bunlar şunlardır:
+
+- Birleştirilebilir: Substreams modüllerini LEGO blokları gibi birleştirebilir ve topluluk modüllerine dayanarak açık verileri daha da ayrıntılayabilirsiniz.
+
+- Yüksek performanslı indeksleme: Büyük ölçekli paralel işlemler sayesinde sıradan işlemlere göre onlarca kat daha hızlı indeksleme sağlar (BigQuery gibi).
+
+- Her yere veri gönderme: Verilerinizi PostgreSQL, MongoDB, Kafka, subgraphlar, düz dosyalar, Google Sheets gibi herhangi bir yere gönderebilirsiniz.
+
+- Programlanabilir: Kod kullanarak çıkarma işlemlerini özelleştirmek, dönüşüm zamanında toplamalar yapmak ve çıktınızı birden çok hedef için modelleyebilirsiniz.
+
+- JSON RPC'nin parçası olmayan ek verilere erişim sağlar
+
+- Firehose'un tüm faydalarından yararlanır.
+
+## Firehose nedir?
+
+[StreamingFast](https://www.streamingfast.io/) tarafından geliştirilen Firehose, daha önce görülmemiş hızlarda blok zincirinin baştan sona, tam geçmişini işlemek için tasarlanmış bir blok zinciri veri çıkarma katmanıdır. Dosya tabanlı ve akışa odaklı bir yaklaşım sunarak, StreamingFast'in açık kaynaklı teknolojilerinin temel bileşenlerinden biridir ve Substreamler'in temelini oluşturur.
+
+Firehose hakkında daha fazla bilgi için [documentation](https://firehose.streamingfast.io/) gidin.
+
+## Firehose'un faydaları nelerdir?
+
+Firehose kullanmanın birçok faydası vardır, bunlar şunlardır:
+
+- En düşük gecikme ve sorgulama yok: Akışa odaklı bir şekilde, Firehose düğümleri blok verilerini ilk olarak dışarıya göndermek üzere tasarlanmıştır.
+
+- Kesintisiz çalışma: Yüksek Erişilebilirlik için baştan sona tasarlanmıştır.
+
+- Hiçbir şeyi kaçırmaz: Firehose akış imleci, fork durumlarını ele almak ve herhangi bir durumda kaldığınız yerden devam etmek için tasarlanmıştır.
+
+- En zengin veri modeli: Bakiye değişikliklerini, tam çağrı ağacını, dahili işlemleri, kayıtları, depolama değişikliklerini, gaz maliyetlerini ve daha fazlasını içeren en iyi veri modeli.
+
+- Düz dosyalardan yararlanma: Blok zinciri verileri düz dosyalara çıkarılır, en ucuz ve en optimize hesaplama kaynağı kullanılır.
+
+## Geliştiriciler, Substreams destekli subgraphlar ve Substreams hakkında daha fazla bilgiye nereden erişebilir geliştiriciler?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+[En son sürüm Substreams Codegen aracı](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6), hiç kod yazmadan bir Substreams projesi başlatmanıza olanak tanır.
+
+## Rust modüllerinin Substreams içindeki rolü nedir?
+
+Rust modülleri, Subgraphs'teki AssemblyScript eşleştiricilerinin karşılığıdır. WASM'ye benzer şekilde derlenirler, ancak programlama modelleri paralel yürütme için olanak sağlar. Rust modülleri, ham blok zinciri verilerine uygulamak istediğiniz dönüşümleri ve birleştirmeleri tanımlar.
+
+Detaylar için [modüller dokümantasyonuna](https://substreams.streamingfast.io/documentation/develop/manifest-modules) bakın.
+
+## Substreams'i birleştirilebilir yapan nedir?
+
+Substream kullanırken, kompozisyon dönüşüm katmanında gerçekleşir ve önbelleğe alınmış modüllerin tekrar kullanılmasına olanak sağlar.
+
+Örnek olarak, Alice bir merkeziyetsiz borsa fiyat modülü oluşturabilir, Bob ilgisini çeken bazı tokenler için bir hacim aggregator inşa edebilir ve Lisa dört bireysel merkeziyetsiz borsa fiyat modülünü bir araya getirerek bir fiyat oracle'ı oluşturabilir. Tek bir Substreams talebi, tüm bu bireylerin modüllerini bir araya getirir, birleştirir ve çok daha sofistike bir veri akışı sunar. Bu akış daha sonra bir subgraph'ı doldurmak ve tüketiciler tarafından sorgulanmak için kullanılabilir.
+
+## Bir Substreams destekli Subgraph nasıl oluşturulur ve dağıtılır?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Substreams ve Substreams destekli subgraphlar ile ilgili örnekleri nerede bulubilirim?
+
+Substreams ve Substreams destekli subgraphlar ile ilgili örnekleri bulmak için [bu Github deposunu](https://github.com/pinax-network/awesome-substreams) ziyaret edebilirsiniz.
+
+## Substreams ve Substreams destekli subgraphlar, Graph Ağı için ne anlam ifade etmektedir?
+
+Bu entegrasyon, topluluk modüllerinden yararlanarak son derece yüksek performanslı indeksleme ve daha fazla birleştirme yapma avantajları sunar.

From d969bae57864e03fa9bf896297e7c14bce454f41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:46 -0500
Subject: [PATCH 2247/3820] New translations sps-faq.mdx (Ukrainian)

---
 website/pages/uk/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/uk/substreams/sps/sps-faq.mdx

diff --git a/website/pages/uk/substreams/sps/sps-faq.mdx b/website/pages/uk/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..18248fc069df
--- /dev/null
+++ b/website/pages/uk/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 3217a6ec4504836c2345b8d979daa94edeea233c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:47 -0500
Subject: [PATCH 2248/3820] New translations sps-faq.mdx (Chinese Simplified)

---
 website/pages/zh/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/zh/substreams/sps/sps-faq.mdx

diff --git a/website/pages/zh/substreams/sps/sps-faq.mdx b/website/pages/zh/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..9b8f6b2dd205
--- /dev/null
+++ b/website/pages/zh/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## 什么是Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## 什么是基于Substreams的子图？
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+如果您已经熟悉子图（Subgraph）开发，那么请注意，基于Substreams的子图可以被查询，就像它是由AssemblyScript转换层生成的一样，具有所有子图的优势，比如提供动态和灵活的GraphQL API。
+
+## 基于Substreams的子图和普通子图有什么区别？
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## 使用基于Substeams的子图的优势是什么？
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## Substreams的优势是什么？
+
+使用Substreams有许多好处，包括：
+
+- 可组合的: Substreams模块具有可组合性，就像乐高积木一样，您可以将它们堆叠起来，并在社区模块的基础上构建，进一步细化公共数据。
+
+- 高性能索引：大规模并行操作（类似于BigQuery）能够使索引速度提升数个数量级。
+
+- 任意传输：将您的数据传输到您想要的任何地方：PostgreSQL、MongoDB、Kafka、子图、平面文件、Google Sheets等。
+
+- 可编程：使用代码自定义提取、进行转换时聚合，并为多个传输目标建模输出。
+
+- 访问不作为JSON RPC的一部分的附加数据。
+
+- Firehose的全部好处。
+
+## 什么是Firehose?
+
+Firehose是由[StreamingFast](https://www.streamingfast.io/)开发的区块链数据提取层，从零开始设计，以前所未有的速度处理区块链的完整历史。它提供基于文件和流式优先的方法，是StreamingFast开源技术套件的核心组件，也是Substreams的基础。
+
+请访问[documentation](https://firehose.streamingfast.io/)，了解更多关于Firehose的信息。
+
+## Firehose的优势是什么？
+
+使用Firehose有许多好处，包括：
+
+- 最低延迟和无需轮询：Firehose节点以流优先的方式设计，竞相将块数据推送出去。
+
+- 防止宕机：从头开始为高可用性而设计。
+
+- 不会错过任何数据：Firehose流游标设计用于处理分叉，并在任何情况下都可以继续从上次离开的地方开始。
+
+- 最丰富的数据模型：包含余额变化、完整的调用树、内部交易、日志、存储变更、燃气费用等最佳数据模型。
+
+- 利用平面文件：将区块链数据提取到平面文件中，这是目前最便宜、最优化的计算资源。
+
+## 开发人员在哪里可以获得关于Substreams-powered子图和Substreams的更多信息？
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## Rust模块在Substreams中扮演什么角色？
+
+Rust模块相当于子图中的AssemblyScript mappers。它们以类似的方式编译为WASM，但编程模型允许并行执行。它们定义了您想要对原始区块链数据应用的转换和聚合类型。
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## 什么使Substreams具有组合性？
+
+在使用Substreams时，组合发生在转换层，从而使得缓存模块可以被重复使用。
+
+举例来说，Alice可以构建一个DEX价格模块，Bob可以使用它来构建一种感兴趣的代币的交易量聚合器，Lisa可以将四个单独的DEX价格模块组合起来创建一个价格预言机。一个单独的Substreams请求将打包所有这些个人模块，并将它们链接在一起，提供一个更加精细的数据流。然后可以使用该数据流填充子图，并由消费者查询。
+
+## 如何构建和部署Substreams-powered子图？
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## 在哪里可以找到Substreams和Substreams-powered子图的示例？
+
+您可以访问此 [this Github repo](https://github.com/pinax-network/awesome-substreams) 以找到Substreams和Substreams-powered子图的示例。
+
+## Substreams和Substreams-powered子图对于The Graph Network意味着什么？
+
+这种集成带来许多好处，包括通过利用社区模块和在其上构建的组合性来实现极高性能的索引。

From 8f9228d192a38c955745ab930a7527630bf03ed0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:48 -0500
Subject: [PATCH 2249/3820] New translations sps-faq.mdx (Urdu (Pakistan))

---
 website/pages/ur/substreams/sps/sps-faq.mdx | 94 +++++++++++++++++++++
 1 file changed, 94 insertions(+)
 create mode 100644 website/pages/ur/substreams/sps/sps-faq.mdx

diff --git a/website/pages/ur/substreams/sps/sps-faq.mdx b/website/pages/ur/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..8d8164713d3b
--- /dev/null
+++ b/website/pages/ur/substreams/sps/sps-faq.mdx
@@ -0,0 +1,94 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## سب اسٹریمز کیا ہیں؟
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## سب سٹریمز سے چلنے والے سب گرافس کیا ہیں؟
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+اگر آپ سب گراف ڈیولپمنٹ سے پہلے ہی واقف ہیں، تو نوٹ کریں کہ سب سٹریمز سے چلنے والے سب گرافس کے بارے میں کیوری کیا جا سکتا ہے، بالکل اسی طرح جیسے اسے اسمبلی اسکرپٹ ٹرانسفارمیشن لیئر کے ذریعے تیار کیا گیا ہو، جیسے کہ ایک متحرک اور لچکدار GraphQL API فراہم کرنا.
+
+## سب سٹریمز سے چلنے والے سب گرافس سب گراف سے کیسے مختلف ہیں؟
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## سب سٹریمز سے چلنے والے سب گرافس استعمال کرنے کے کیا فوائد ہیں؟
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## سب سٹریمز کے فوائد کہاں ہیں؟
+
+سب سٹریمز کو استعمال کرنے کے بہت سے فوائد ہیں، بشمول:
+
+- کمپوز ایبل: آپ سب سٹریمز ماڈیولز جیسے LEGO بلاکس کو اسٹیک کر سکتے ہیں، اور عوامی ڈیٹا کو مزید بہتر کرتے ہوئے کمیونٹی ماڈیول بنا سکتے ہیں.
+
+- اعلی کارکردگی کی انڈیکسنگ: متوازی کارروائیوں کے بڑے پیمانے پر کلسٹرز کے ذریعے تیز تر انڈیکسنگ کے آرڈرز (سوچیں BigQuery).
+
+- کہیں بھی سینک: اپنے ڈیٹا کو جہاں چاہیں سینک: PostgreSQL، MongoDB، Kafka، سب گرافس، فلیٹ فائلز، Google Sheets.
+
+- قابل پروگرام: اسے اپنی مرضی کے مطابق بنانے کے لیے کوڈ کریں، دو ٹرانسفارم ٹائم ایگریگیشنز، اور متعدد حواس کے لیے اپنے آؤٹ پٹ کو ماڈل کریں.
+
+- اضافی ڈیٹا تک رسائی جو JSON RPC کے حصے کے طور پر دستیاب نہیں ہے
+
+- Firehose کے تمام فوائد.
+
+## Firehose کیا ہے؟
+
+[StreamingFast](https://www.streamingfast.io/) کے ذریعے تیار کردہ، Firehose ایک بلاکچین ڈیٹا نکالنے کی پرت ہے جسے شروع سے بلاکچینز کی مکمل تاریخ کو اس رفتار سے پروسیس کرنے کے لیے ڈیزائن کیا گیا ہے جو پہلے نظر نہیں آتی تھیں۔ فائلوں پر مبنی اور سٹریمنگ فرسٹ اپروچ فراہم کرنا، یہ سٹریمنگ فاسٹ کے اوپن سورس ٹیکنالوجیز کے سوٹ کا بنیادی جزو اور سب اسٹریمز کی بنیاد ہے.
+
+Firehose کے بارے میں مزید جاننے کے لیے[documentation]
+(https://firehose.streamingfast.io/) پر جائیں.
+
+## Firehose کے کیا فوائد ہیں؟
+
+Firehose استعمال کرنے کے بہت سے فوائد ہیں، بشمول:
+
+- سب سے کم تاخیر اور کوئی پولنگ نہیں: اسٹریمنگ کے پہلے انداز میں، Firehose نوڈس کو پہلے بلاک ڈیٹا کو آگے بڑھانے کی دوڑ کے لیے ڈیزائن کیا گیا ہے.
+
+- ڈاؤن ٹائمز کو روکتا ہے: اعلی دستیابی کے لیے زمین سے ڈیزائن کیا گیا ہے.
+
+- کبھی بھی بیٹ مت چھوڑیں: Firehose سٹریم کرسر کو فورکس ہینڈل کرنے اور کسی بھی حالت میں وہیں سے جاری رکھنے کے لیے بنایا گیا ہے جہاں آپ نے چھوڑا تھا.
+
+- امیرترین ڈیٹا ماڈل: بہترین ڈیٹا ماڈل جس میں بیلنس کی تبدیلیاں، مکمل کال ٹری، اندرونی ٹرانزیکشن، لاگز، اسٹوریج کی تبدیلیاں، گیس کی قیمتیں اور بہت کچھ شامل ہے.
+
+- فلیٹ فائلوں کا فائدہ اٹھاتا ہے: بلاکچین ڈیٹا کو فلیٹ فائلوں میں نکالا جاتا ہے، جو دستیاب سب سے سستا اور بہترین کمپیوٹنگ وسیلہ ہے.
+
+## ڈویلپرز سب سٹریمز سے چلنے والے سب گرافس اور سب سٹریمز کے بارے میں مزید معلومات کہاں تک رسائی حاصل کرسکتے ہیں؟
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## سب سٹریمز میں Rust ماڈیولز کا کیا کردار ہے؟
+
+زنگ ماڈیول سب گراف میں اسمبلی اسکرپٹ میپرز کے مساوی ہیں۔ وہ اسی طرح WASM پر مرتب کیے گئے ہیں، لیکن پروگرامنگ ماڈل متوازی عمل درآمد کی اجازت دیتا ہے۔ وہ اس قسم کی تبدیلیوں اور مجموعوں کی وضاحت کرتے ہیں جسے آپ خام بلاکچین ڈیٹا پر لاگو کرنا چاہتے ہیں.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## سب سٹریمز کو کمپوز ایبل کیا بناتا ہے؟
+
+سب سٹریمز کا استعمال کرتے وقت، کمپوزیشن ٹرانسفارمیشن لیئر پر ہوتی ہے جو کیشڈ ماڈیولز کو دوبارہ استعمال کرنے کے قابل بناتی ہے.
+
+مثال کے طور پر، ایلس DEX پرائس ماڈیول بنا سکتی ہے، باب اپنی دلچسپی کے کچھ ٹوکنز کے لیے حجم ایگریگیٹر بنانے کے لیے اسے استعمال کر سکتا ہے، اور لیزا قیمت اوریکل بنانے کے لیے چار انفرادی DEX قیمت ماڈیول کو جوڑ سکتی ہے۔ ایک واحد سب سٹریمز کی درخواست ان تمام افراد کے ماڈیولز کو پیک کرے گی، ان کو آپس میں جوڑ دے گی، تاکہ ڈیٹا کا بہت زیادہ بہتر سلسلہ پیش کیا جا سکے۔ اس سلسلے کو پھر سب گراف کو آباد کرنے کے لیے استعمال کیا جا سکتا ہے، اور صارفین اس سے کیوریز کر سکتے ہیں.
+
+## آپ سب سٹریمز سے چلنے والے سب گراف کو کیسے بنا اور تعینات کر سکتے ہیں؟
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## مجھے سب سٹریمز اور سب سٹریمز سے چلنے والے سب گرافس کی مثالیں کہاں مل سکتی ہیں؟
+
+آپ سب سٹریمز اور سب سٹریم سے چلنے والے سب گرافس کی مثالیں تلاش کرنے کے لیے [یہ گٹ ہب ریپو](https://github.com/pinax-network/awesome-substreams) ملاحظہ کر سکتے ہیں.
+
+## گراف نیٹ ورک کے لیے سب سٹریمز اور سب سٹریمز سے چلنے والے سب گرافس کا کیا مطلب ہے؟
+
+انضمام بہت سے فوائد کا وعدہ کرتا ہے، بشمول انتہائی اعلی کارکردگی کی انڈیکسنگ اور کمیونٹی ماڈیولز کا فائدہ اٹھا کر اور ان پر تعمیر کرنے کے ذریعے زیادہ کمپوز ایبلٹی.

From 64c66c412d5404f52539e7358f2936aea4a237b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:49 -0500
Subject: [PATCH 2250/3820] New translations sps-faq.mdx (Vietnamese)

---
 website/pages/vi/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/vi/substreams/sps/sps-faq.mdx

diff --git a/website/pages/vi/substreams/sps/sps-faq.mdx b/website/pages/vi/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..18248fc069df
--- /dev/null
+++ b/website/pages/vi/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 16fe0cc03a967d790bc3bc5d10e2e38984f1ce87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:50 -0500
Subject: [PATCH 2251/3820] New translations sps-faq.mdx (Marathi)

---
 website/pages/mr/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/mr/substreams/sps/sps-faq.mdx

diff --git a/website/pages/mr/substreams/sps/sps-faq.mdx b/website/pages/mr/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..18248fc069df
--- /dev/null
+++ b/website/pages/mr/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From bd90582e1741a8f3ee90bb94d8543d3778621a43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:51 -0500
Subject: [PATCH 2252/3820] New translations sps-faq.mdx (Hindi)

---
 website/pages/hi/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/hi/substreams/sps/sps-faq.mdx

diff --git a/website/pages/hi/substreams/sps/sps-faq.mdx b/website/pages/hi/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..7bdb0c0857b2
--- /dev/null
+++ b/website/pages/hi/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+[नवीनतम Substreams Codegen टूल](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) आपको बिना किसी कोड के एक Substreams प्रोजेक्ट शुरू करने की अनुमति देगा।
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From f1b1a6e49cb3a52e5bc57f73e470bd4e6664e75f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:52 -0500
Subject: [PATCH 2253/3820] New translations sps-faq.mdx (Swahili)

---
 website/pages/sw/substreams/sps/sps-faq.mdx | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 website/pages/sw/substreams/sps/sps-faq.mdx

diff --git a/website/pages/sw/substreams/sps/sps-faq.mdx b/website/pages/sw/substreams/sps/sps-faq.mdx
new file mode 100644
index 000000000000..18248fc069df
--- /dev/null
+++ b/website/pages/sw/substreams/sps/sps-faq.mdx
@@ -0,0 +1,93 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. Substreams allow you to refine and shape blockchain data for fast and seamless digestion by end-user applications. More specifically, Substreams is a blockchain-agnostic, parallelized, and streaming-first engine, serving as a blockchain data transformation layer. Powered by the [Firehose](https://firehose.streamingfast.io/), it ​​enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) their data anywhere.
+
+Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, then note that Substreams-powered subgraphs can then be queried, just as if it had been produced by the AssemblyScript transformation layer, with all the Subgraph benefits, like providing a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://substreams.streamingfast.io/documentation/develop/manifest-modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://substreams.streamingfast.io/documentation/develop/manifest-modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From e4c0900bca6c9b80ba778c82b83f32ad6e7f19fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:53 -0500
Subject: [PATCH 2254/3820] New translations tutorial.mdx (Romanian)

---
 website/pages/ro/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/ro/substreams/sps/tutorial.mdx

diff --git a/website/pages/ro/substreams/sps/tutorial.mdx b/website/pages/ro/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..495298871a22
--- /dev/null
+++ b/website/pages/ro/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From c4bdbd1ec6e2b1f7295018ab49c2de693405d283 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:54 -0500
Subject: [PATCH 2255/3820] New translations tutorial.mdx (French)

---
 website/pages/fr/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/fr/substreams/sps/tutorial.mdx

diff --git a/website/pages/fr/substreams/sps/tutorial.mdx b/website/pages/fr/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..2b4aaa27a8ca
--- /dev/null
+++ b/website/pages/fr/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Conditions préalables
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 28fa90d4478fef2401e68f24db4980966da69193 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:55 -0500
Subject: [PATCH 2256/3820] New translations tutorial.mdx (Spanish)

---
 website/pages/es/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/es/substreams/sps/tutorial.mdx

diff --git a/website/pages/es/substreams/sps/tutorial.mdx b/website/pages/es/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..b52cd3cf42e3
--- /dev/null
+++ b/website/pages/es/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Prerrequisitos
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 54eedb648a629725f3f71331ef7a6cbedd727cb7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:56 -0500
Subject: [PATCH 2257/3820] New translations tutorial.mdx (Arabic)

---
 website/pages/ar/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/ar/substreams/sps/tutorial.mdx

diff --git a/website/pages/ar/substreams/sps/tutorial.mdx b/website/pages/ar/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..3c1909f87ac8
--- /dev/null
+++ b/website/pages/ar/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## المتطلبات الأساسية
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 8b6df715c5bc9640ff0fb0f1948b9b42223fa800 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:57 -0500
Subject: [PATCH 2258/3820] New translations tutorial.mdx (Czech)

---
 website/pages/cs/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/cs/substreams/sps/tutorial.mdx

diff --git a/website/pages/cs/substreams/sps/tutorial.mdx b/website/pages/cs/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..a25f86fd5aa6
--- /dev/null
+++ b/website/pages/cs/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Požadavky
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Závěr
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 91b351b3a9ab58dd7804a7bab7e7bddc67bab8fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:58 -0500
Subject: [PATCH 2259/3820] New translations tutorial.mdx (German)

---
 website/pages/de/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/de/substreams/sps/tutorial.mdx

diff --git a/website/pages/de/substreams/sps/tutorial.mdx b/website/pages/de/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..495298871a22
--- /dev/null
+++ b/website/pages/de/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 9e6771ea880017cb5fb3fca7cb4dd55f2bb20298 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:24:59 -0500
Subject: [PATCH 2260/3820] New translations tutorial.mdx (Italian)

---
 website/pages/it/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/it/substreams/sps/tutorial.mdx

diff --git a/website/pages/it/substreams/sps/tutorial.mdx b/website/pages/it/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..495298871a22
--- /dev/null
+++ b/website/pages/it/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 84c74cf9f8f153656df8226bfa5a2299d7686185 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:00 -0500
Subject: [PATCH 2261/3820] New translations tutorial.mdx (Japanese)

---
 website/pages/ja/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/ja/substreams/sps/tutorial.mdx

diff --git a/website/pages/ja/substreams/sps/tutorial.mdx b/website/pages/ja/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..7c513edec723
--- /dev/null
+++ b/website/pages/ja/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## 前提条件
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 243de22b985abf8f6639bdea02d97dfb2d23a031 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:01 -0500
Subject: [PATCH 2262/3820] New translations tutorial.mdx (Korean)

---
 website/pages/ko/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/ko/substreams/sps/tutorial.mdx

diff --git a/website/pages/ko/substreams/sps/tutorial.mdx b/website/pages/ko/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..495298871a22
--- /dev/null
+++ b/website/pages/ko/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 9c5d55130afe820c823773cedafef362d2209d7c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:02 -0500
Subject: [PATCH 2263/3820] New translations tutorial.mdx (Dutch)

---
 website/pages/nl/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/nl/substreams/sps/tutorial.mdx

diff --git a/website/pages/nl/substreams/sps/tutorial.mdx b/website/pages/nl/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..495298871a22
--- /dev/null
+++ b/website/pages/nl/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From de74b46683e86f3ac805f6b3eb3ceaf01f9b69c6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:03 -0500
Subject: [PATCH 2264/3820] New translations tutorial.mdx (Polish)

---
 website/pages/pl/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/pl/substreams/sps/tutorial.mdx

diff --git a/website/pages/pl/substreams/sps/tutorial.mdx b/website/pages/pl/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..495298871a22
--- /dev/null
+++ b/website/pages/pl/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 33b5622a8be520a9daf60079b2eb58e45251f8fb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:04 -0500
Subject: [PATCH 2265/3820] New translations tutorial.mdx (Portuguese)

---
 website/pages/pt/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/pt/substreams/sps/tutorial.mdx

diff --git a/website/pages/pt/substreams/sps/tutorial.mdx b/website/pages/pt/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..503fcdeab65e
--- /dev/null
+++ b/website/pages/pt/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Pré-requisitos
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusão
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 6da57a38077b311b6c0ebc4e23858d9d63431209 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:07 -0500
Subject: [PATCH 2266/3820] New translations tutorial.mdx (Russian)

---
 website/pages/ru/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/ru/substreams/sps/tutorial.mdx

diff --git a/website/pages/ru/substreams/sps/tutorial.mdx b/website/pages/ru/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..e91d5c217ef7
--- /dev/null
+++ b/website/pages/ru/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Предварительные требования
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Заключение
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From de6e67fc563dba885716772484981a55e118561a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:08 -0500
Subject: [PATCH 2267/3820] New translations tutorial.mdx (Swedish)

---
 website/pages/sv/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/sv/substreams/sps/tutorial.mdx

diff --git a/website/pages/sv/substreams/sps/tutorial.mdx b/website/pages/sv/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..f0419707408a
--- /dev/null
+++ b/website/pages/sv/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Förutsättningar
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From d96a5b169e46238038c1435aab2e00bc36d01f37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:11 -0500
Subject: [PATCH 2268/3820] New translations tutorial.mdx (Turkish)

---
 website/pages/tr/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/tr/substreams/sps/tutorial.mdx

diff --git a/website/pages/tr/substreams/sps/tutorial.mdx b/website/pages/tr/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..4301c586e460
--- /dev/null
+++ b/website/pages/tr/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Ön Koşullar
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 6d70d6e578d549ced3ee7db007f070969b73002b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:13 -0500
Subject: [PATCH 2269/3820] New translations tutorial.mdx (Ukrainian)

---
 website/pages/uk/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/uk/substreams/sps/tutorial.mdx

diff --git a/website/pages/uk/substreams/sps/tutorial.mdx b/website/pages/uk/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..495298871a22
--- /dev/null
+++ b/website/pages/uk/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 688ae14cc8f93c69483a97a0808444d0ab9cba23 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:13 -0500
Subject: [PATCH 2270/3820] New translations tutorial.mdx (Chinese Simplified)

---
 website/pages/zh/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/zh/substreams/sps/tutorial.mdx

diff --git a/website/pages/zh/substreams/sps/tutorial.mdx b/website/pages/zh/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..657a4d2402e2
--- /dev/null
+++ b/website/pages/zh/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## 先决条件
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 5efad598ce1d7d1a8b627db30a9f5c55a6aaa146 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:14 -0500
Subject: [PATCH 2271/3820] New translations tutorial.mdx (Urdu (Pakistan))

---
 website/pages/ur/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/ur/substreams/sps/tutorial.mdx

diff --git a/website/pages/ur/substreams/sps/tutorial.mdx b/website/pages/ur/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..604c864981b7
--- /dev/null
+++ b/website/pages/ur/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## شرطیں
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From bac472c7b6fe8fd52d77432ea416b12288ef121a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:15 -0500
Subject: [PATCH 2272/3820] New translations tutorial.mdx (Vietnamese)

---
 website/pages/vi/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/vi/substreams/sps/tutorial.mdx

diff --git a/website/pages/vi/substreams/sps/tutorial.mdx b/website/pages/vi/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..3ed429e6133b
--- /dev/null
+++ b/website/pages/vi/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Điều kiện tiên quyết
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 32c49354f5df8e179508826222d2028851fe829a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:16 -0500
Subject: [PATCH 2273/3820] New translations tutorial.mdx (Marathi)

---
 website/pages/mr/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/mr/substreams/sps/tutorial.mdx

diff --git a/website/pages/mr/substreams/sps/tutorial.mdx b/website/pages/mr/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..7ea6674d7884
--- /dev/null
+++ b/website/pages/mr/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## पूर्वतयारी
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From e9a88d00f065662dc8baf3d4026113ed4e739777 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:18 -0500
Subject: [PATCH 2274/3820] New translations tutorial.mdx (Hindi)

---
 website/pages/hi/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/hi/substreams/sps/tutorial.mdx

diff --git a/website/pages/hi/substreams/sps/tutorial.mdx b/website/pages/hi/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..2f9eab3900f0
--- /dev/null
+++ b/website/pages/hi/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "ट्यूटोरियल: Solana पर एक Substreams-शक्ति वाले Subgraph सेट करें"
+---
+
+## आवश्यक शर्तें
+
+'शुरू करने से पहले, सुनिश्चित करें कि:'
+
+- अपने विकास पर्यावरण को सेट अप करने के लिए Getting Started Guide(https://github.com/streamingfast/substreams-starter) को पूरा करें, एक Dev Container का उपयोग करके।
+- The Graph और मूल ब्लॉकचेन अवधारणाओं जैसे कि लेनदेन और Protobufs से परिचित रहें।
+
+## चरण 1: अपने प्रोजेक्ट को प्रारंभ करें
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. अपने Dev Container को खोलें और अपने प्रोजेक्ट को शुरू करने के लिए निम्नलिखित कमांड चलाएं:
+
+   ```bash
+   substreams प्रारंभ करें
+   ```
+
+2. "Minimal" प्रोजेक्ट विकल्प चुनें।
+
+3. substreams.yaml फ़ाइल की सामग्री को निम्नलिखित कॉन्फ़िगरेशन से बदलें, जो SPL टोकन प्रोग्राम आईडी पर Orca अकाउंट के लेनदेन को फ़िल्टर करता है:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## चरण 2: Subgraph Manifest उत्पन्न करें
+
+एक बार जब प्रोजेक्ट इनिशियलाइज़ हो जाए, Dev Container में निम्नलिखित कमांड चलाकर subgraph मैनिफेस्ट जेनरेट करें: 
+
+```bash
+'सबस्ट्रीम्स कोडजेन' subgraph
+```
+
+आप subgraph.yaml मैनिफेस्ट बनाएंगे जो डेटा स्रोत के रूप में Substreams पैकेज को इम्पोर्ट करता है:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## चरण 3: schema.graphql में संस्थाएँ परिभाषित करें
+
+अपने सबग्राफ एंटिटीज़ में सहेजने के लिए फ़ील्ड्स को परिभाषित करें, schema.graphql फ़ाइल को अपडेट करके। यहाँ एक उदाहरण है:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+यह स्कीमा एक MyTransfer एंटिटी को परिभाषित करता है जिसमें फ़ील्ड्स जैसे कि id, amount, source, designation, और signers शामिल हैं।
+
+## चरण 4: mappings.ts में Substreams डेटा को संभालें
+
+प्रोटोकॉल वस्तुओं के जनित होने के साथ, आप अब 'mappings.ts' फ़ाइल में डिकोडेड सबस्ट्रीम डेटा को संभाल सकते हैं, जो कि './src' निर्देशिका में पाई जाती है। नीचे दिया गया उदाहरण दिखाता है कि कैसे 'Orca' खाता आईडी से जुड़े गैर-व्युत्पन्न ट्रांसफर को सबग्राफ संस्थाओं में निकाला जा सकता है:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## चरण 5: Protobuf फ़ाइलें उत्पन्न करें
+
+AssemblyScript में Protobuf ऑब्जेक्ट बनाने के लिए, निम्नलिखित कमांड चलाएँ:
+
+```bash
+npm चलाएँ protogen
+```
+
+यह कमांड Protobuf परिभाषाओं को AssemblyScript में परिवर्तित करता है, जिससे आप उन्हें हैंडलर में उपयोग कर सकते हैं।
+
+## निष्कर्ष
+
+आपने सफलतापूर्वक एक ट्रिगर-आधारित Substreams-शक्ति वाला subgraph स्थापित कर लिया है जो एक Solana SPL टोकन के लिए है। अब आप अपने विशिष्ट उपयोग के मामले के अनुसार अपने स्कीमा, मैपिंग और मॉड्यूल को और अनुकूलित कर सकते हैं।
+
+अधिक उन्नत अनुकूलन और ऑप्टिमाइजेशन के लिए, आधिकारिक Substreams documentation(https://substreams.streamingfast.io/tutorials/solana) देखें।

From 61d8753715b0d9d3bf31fd06907146a07cdbc497 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:19 -0500
Subject: [PATCH 2275/3820] New translations tutorial.mdx (Swahili)

---
 website/pages/sw/substreams/sps/tutorial.mdx | 140 +++++++++++++++++++
 1 file changed, 140 insertions(+)
 create mode 100644 website/pages/sw/substreams/sps/tutorial.mdx

diff --git a/website/pages/sw/substreams/sps/tutorial.mdx b/website/pages/sw/substreams/sps/tutorial.mdx
new file mode 100644
index 000000000000..495298871a22
--- /dev/null
+++ b/website/pages/sw/substreams/sps/tutorial.mdx
@@ -0,0 +1,140 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+## Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+## Step 1: Initialize Your Project
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+## Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+## Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+## Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+## Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+## Conclusion
+
+You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From c6091020702068ac6b1078868cc4d69b8eb132b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:19 -0500
Subject: [PATCH 2276/3820] New translations supported-networks.mdx (Romanian)

---
 website/pages/ro/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ro/supported-networks.mdx

diff --git a/website/pages/ro/supported-networks.mdx b/website/pages/ro/supported-networks.mdx
new file mode 100644
index 000000000000..ccdebbd3ea16
--- /dev/null
+++ b/website/pages/ro/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Rețele suportate
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 69ca54560c53203a5a1dc4650a7449b196cc1625 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:20 -0500
Subject: [PATCH 2277/3820] New translations supported-networks.mdx (French)

---
 website/pages/fr/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/fr/supported-networks.mdx

diff --git a/website/pages/fr/supported-networks.mdx b/website/pages/fr/supported-networks.mdx
new file mode 100644
index 000000000000..906f9bd2d87f
--- /dev/null
+++ b/website/pages/fr/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Réseaux pris en charge
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio repose sur la stabilité et la fiabilité des technologies sous-jacentes, comme les endpoints JSON-RPC, Firehose et Substreams.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- Si un subgraph a été publié via la CLI et repris par un Indexer, il pourrait techniquement être interrogé même sans support, et des efforts sont en cours pour simplifier davantage l'intégration de nouveaux réseaux.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Exécution de Graph Node en local
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node peut également indexer d'autres protocoles via une intégration Firehose. Des intégrations Firehose ont été créées pour NEAR, Arweave et les réseaux basés sur Cosmos. De plus, Graph Node peut prendre en charge les subgraphs alimentés par Substreams pour tout réseau prenant en charge Substreams.

From 5fa5679283fd7dec6995580f9cd9047d095a6a27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:21 -0500
Subject: [PATCH 2278/3820] New translations supported-networks.mdx (Spanish)

---
 website/pages/es/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/es/supported-networks.mdx

diff --git a/website/pages/es/supported-networks.mdx b/website/pages/es/supported-networks.mdx
new file mode 100644
index 000000000000..7fa33f237309
--- /dev/null
+++ b/website/pages/es/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Redes Admitidas
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From feb850e04e41456d4179eb2a6687a587ebe24943 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:22 -0500
Subject: [PATCH 2279/3820] New translations supported-networks.mdx (Arabic)

---
 website/pages/ar/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ar/supported-networks.mdx

diff --git a/website/pages/ar/supported-networks.mdx b/website/pages/ar/supported-networks.mdx
new file mode 100644
index 000000000000..f334e4d10143
--- /dev/null
+++ b/website/pages/ar/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: الشبكات المدعومة
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 611c5f873df989936c4df1bbde81b88aa5bcaa31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:23 -0500
Subject: [PATCH 2280/3820] New translations supported-networks.mdx (Czech)

---
 website/pages/cs/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/cs/supported-networks.mdx

diff --git a/website/pages/cs/supported-networks.mdx b/website/pages/cs/supported-networks.mdx
new file mode 100644
index 000000000000..138af9a2c8b8
--- /dev/null
+++ b/website/pages/cs/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Podporované sítě
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From c05fa29c672eff3efbb6c633d2a4f0bc8bad8c25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:24 -0500
Subject: [PATCH 2281/3820] New translations supported-networks.mdx (German)

---
 website/pages/de/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/de/supported-networks.mdx

diff --git a/website/pages/de/supported-networks.mdx b/website/pages/de/supported-networks.mdx
new file mode 100644
index 000000000000..d2f36138a178
--- /dev/null
+++ b/website/pages/de/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Supported Networks
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From c7b05dbecee2c6bb373b4571b30bc0f5e78d34e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:25 -0500
Subject: [PATCH 2282/3820] New translations supported-networks.mdx (Italian)

---
 website/pages/it/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/it/supported-networks.mdx

diff --git a/website/pages/it/supported-networks.mdx b/website/pages/it/supported-networks.mdx
new file mode 100644
index 000000000000..d2f36138a178
--- /dev/null
+++ b/website/pages/it/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Supported Networks
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From b069b2c44804efcc68e74f1dbe4b883c07bcbf53 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:26 -0500
Subject: [PATCH 2283/3820] New translations supported-networks.mdx (Japanese)

---
 website/pages/ja/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ja/supported-networks.mdx

diff --git a/website/pages/ja/supported-networks.mdx b/website/pages/ja/supported-networks.mdx
new file mode 100644
index 000000000000..dd3f51c77baf
--- /dev/null
+++ b/website/pages/ja/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: サポートされているネットワーク
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 11739134e0cf56a5b653dfb56a66a13dae4c912c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:27 -0500
Subject: [PATCH 2284/3820] New translations supported-networks.mdx (Korean)

---
 website/pages/ko/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ko/supported-networks.mdx

diff --git a/website/pages/ko/supported-networks.mdx b/website/pages/ko/supported-networks.mdx
new file mode 100644
index 000000000000..d2f36138a178
--- /dev/null
+++ b/website/pages/ko/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Supported Networks
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From e55ca0df452cbba3a97d851469f542e0ec2b7efe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:28 -0500
Subject: [PATCH 2285/3820] New translations supported-networks.mdx (Dutch)

---
 website/pages/nl/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/nl/supported-networks.mdx

diff --git a/website/pages/nl/supported-networks.mdx b/website/pages/nl/supported-networks.mdx
new file mode 100644
index 000000000000..088e27acc68a
--- /dev/null
+++ b/website/pages/nl/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Ondersteunde Netwerken
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 23df2f611fb6e487052963a31ad1352c6212f66c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:29 -0500
Subject: [PATCH 2286/3820] New translations supported-networks.mdx (Polish)

---
 website/pages/pl/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/pl/supported-networks.mdx

diff --git a/website/pages/pl/supported-networks.mdx b/website/pages/pl/supported-networks.mdx
new file mode 100644
index 000000000000..b93eb3b51f21
--- /dev/null
+++ b/website/pages/pl/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Wspierane sieci
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 5a3983c90aa43615ecc66abd3dd76d3c6adcf3d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:30 -0500
Subject: [PATCH 2287/3820] New translations supported-networks.mdx
 (Portuguese)

---
 website/pages/pt/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/pt/supported-networks.mdx

diff --git a/website/pages/pt/supported-networks.mdx b/website/pages/pt/supported-networks.mdx
new file mode 100644
index 000000000000..32ef975a6537
--- /dev/null
+++ b/website/pages/pt/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Redes Apoiadas
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- O Subgraph Studio depende da estabilidade e da confiança das tecnologias subjacentes, por exemplo, JSON-RPC, Firehose e endpoints dos Substreams.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- Se um subgraph foi publicado via a CLI e visto por um Indexador, ele pode tecnicamente ser consultado mesmo sem apoio, e esforços estão a ser feitos para simplificar ainda mais a integração de novas redes.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Execução Local de Graph Nodes
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+O Graph Node também pode indexar outros protocolos via uma integração com Firehose. Integrações com Firehose também estão disponíveis para redes baseadas em Cosmos, Arweave e NEAR. Além disto, o Graph Node pode apoiar subgraphs movidos a Substreams para qualquer rede com apoio a Substreams.

From 58ee57581223a0106f69ef35135fa1a26b94c384 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:31 -0500
Subject: [PATCH 2288/3820] New translations supported-networks.mdx (Russian)

---
 website/pages/ru/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ru/supported-networks.mdx

diff --git a/website/pages/ru/supported-networks.mdx b/website/pages/ru/supported-networks.mdx
new file mode 100644
index 000000000000..49fdf4f940f6
--- /dev/null
+++ b/website/pages/ru/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Поддерживаемые сети
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio полагается на стабильность и надежность базовых технологий, например, таких, как JSON-RPC, Firehose и конечных точек Substreams.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- Если субграф был опубликован через CLI и выбран индексатором, технически его можно было бы запросить даже без поддержки, и в настоящее время предпринимаются усилия для упрощения интеграции новых сетей.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Локальный запуск Graph Node
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node также может индексировать другие протоколы через интеграцию с Firehose. Интеграции Firehose созданы для сетей на базе NEAR, Arweave и Cosmos. Кроме того, Graph Node может поддерживать субграфы на основе Substreams для любой сети с поддержкой Substreams.

From 3cc7ffd4a4706212e8f1bea2adb0e80df9340e24 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:33 -0500
Subject: [PATCH 2289/3820] New translations supported-networks.mdx (Swedish)

---
 website/pages/sv/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/sv/supported-networks.mdx

diff --git a/website/pages/sv/supported-networks.mdx b/website/pages/sv/supported-networks.mdx
new file mode 100644
index 000000000000..bcd81ae81313
--- /dev/null
+++ b/website/pages/sv/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Nätverk som stöds
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 8aa1fb09dfe80b66be52da598ba38faf6caff837 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:34 -0500
Subject: [PATCH 2290/3820] New translations supported-networks.mdx (Turkish)

---
 website/pages/tr/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/tr/supported-networks.mdx

diff --git a/website/pages/tr/supported-networks.mdx b/website/pages/tr/supported-networks.mdx
new file mode 100644
index 000000000000..32151f660dec
--- /dev/null
+++ b/website/pages/tr/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Desteklenen Ağlar
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio, örneğin JSON-RPC, Firehose ve Substreams uç noktaları gibi temel teknolojilerin istikrarlılığına ve güvenilirliğine bel bağlar.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- Bir subgraph CLI aracılığıyla yayımlandıysa ve bir Endeksleyici tarafından algılandıysa, teknik olarak, desteklenmeden de sorgulanabilir. Yeni ağların entegrasyonunu daha da kolaylaştırmak için çalışmalar devam etmektedir.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Graph Düğümünü yerel olarak çalıştırma
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Düğümü, Firehose entegrasyonu aracılığıyla diğer protokolleri de endeksleyebilir. NEAR, Arweave ve Cosmos tabanlı ağlar için Firehose entegrasyonları oluşturulmuştur. Ayrıca, Graph Düğümü, Substreams desteğine sahip herhangi bir ağ için Substreams destekli subgraph'leri de destekleyebilir.

From 52f30c2219776f390879b8e9d8d1cd66e2c8ecad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:35 -0500
Subject: [PATCH 2291/3820] New translations supported-networks.mdx (Ukrainian)

---
 website/pages/uk/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/uk/supported-networks.mdx

diff --git a/website/pages/uk/supported-networks.mdx b/website/pages/uk/supported-networks.mdx
new file mode 100644
index 000000000000..a17adec8c4b1
--- /dev/null
+++ b/website/pages/uk/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Мережі, які підтримуються
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 663b23ed87e4a223125ba03f85dc06cd3af53f65 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:36 -0500
Subject: [PATCH 2292/3820] New translations supported-networks.mdx (Chinese
 Simplified)

---
 website/pages/zh/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/zh/supported-networks.mdx

diff --git a/website/pages/zh/supported-networks.mdx b/website/pages/zh/supported-networks.mdx
new file mode 100644
index 000000000000..5607a08de64c
--- /dev/null
+++ b/website/pages/zh/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: 支持的网络
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 5dc074269242b617c8efb7b88538fa0bb37b00ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:37 -0500
Subject: [PATCH 2293/3820] New translations supported-networks.mdx (Urdu
 (Pakistan))

---
 website/pages/ur/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/ur/supported-networks.mdx

diff --git a/website/pages/ur/supported-networks.mdx b/website/pages/ur/supported-networks.mdx
new file mode 100644
index 000000000000..1e3c4aba1f58
--- /dev/null
+++ b/website/pages/ur/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: تعاون یافتہ نیٹ ورکس
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 8ce8f3b2f30e48b52d6a0caedffcb3f408b7505f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:38 -0500
Subject: [PATCH 2294/3820] New translations supported-networks.mdx
 (Vietnamese)

---
 website/pages/vi/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/vi/supported-networks.mdx

diff --git a/website/pages/vi/supported-networks.mdx b/website/pages/vi/supported-networks.mdx
new file mode 100644
index 000000000000..719fa4376efd
--- /dev/null
+++ b/website/pages/vi/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Mạng lưới được hỗ trợ
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 4bae3635b45d4c90e4d1ef8dbccd963da3f8b89c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:39 -0500
Subject: [PATCH 2295/3820] New translations supported-networks.mdx (Marathi)

---
 website/pages/mr/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/mr/supported-networks.mdx

diff --git a/website/pages/mr/supported-networks.mdx b/website/pages/mr/supported-networks.mdx
new file mode 100644
index 000000000000..d2f36138a178
--- /dev/null
+++ b/website/pages/mr/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Supported Networks
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 2ed03131ced39872353515cc107c44781d069519 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:40 -0500
Subject: [PATCH 2296/3820] New translations supported-networks.mdx (Hindi)

---
 website/pages/hi/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/hi/supported-networks.mdx

diff --git a/website/pages/hi/supported-networks.mdx b/website/pages/hi/supported-networks.mdx
new file mode 100644
index 000000000000..9a980a506766
--- /dev/null
+++ b/website/pages/hi/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: समर्थित नेटवर्क
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- सबग्राफ स्टूडियो निर्भर करता है अंतर्निहित प्रौद्योगिकियों की स्थिरता और विश्वसनीयता पर, जैसे JSON-RPC, फायरहोस और सबस्ट्रीम्स एंडपॉइंट्स।
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 5c414bb063c60925d5d867d3e1b963731a76d3f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:42 -0500
Subject: [PATCH 2297/3820] New translations supported-networks.mdx (Swahili)

---
 website/pages/sw/supported-networks.mdx | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 website/pages/sw/supported-networks.mdx

diff --git a/website/pages/sw/supported-networks.mdx b/website/pages/sw/supported-networks.mdx
new file mode 100644
index 000000000000..d2f36138a178
--- /dev/null
+++ b/website/pages/sw/supported-networks.mdx
@@ -0,0 +1,24 @@
+---
+title: Supported Networks
+---
+
+import { getStaticPropsForSupportedNetworks } from '@/src/buildGetStaticProps'
+import { SupportedNetworksTable } from '@/src/supportedNetworks'
+
+export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
+
+<SupportedNetworksTable networks={props.networks} />
+
+\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+
+- Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
+- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.
+- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+
+## Running Graph Node locally
+
+If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+
+Graph Node can also index other protocols, via a Firehose integration. Firehose integrations have been created for NEAR, Arweave and Cosmos-based networks. Additionally, Graph Node can support Substreams-powered subgraphs for any network with Substreams support.

From 7c5a59167688514de93f27fd7774a21798344379 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:43 -0500
Subject: [PATCH 2298/3820] New translations supported-networks.json (Romanian)

---
 website/pages/ro/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/ro/supported-networks.json

diff --git a/website/pages/ro/supported-networks.json b/website/pages/ro/supported-networks.json
new file mode 100644
index 000000000000..7b7376b2fbd7
--- /dev/null
+++ b/website/pages/ro/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Network",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Serviciu găzduit",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From 5d5426ee7d3f12aad46fa6d8914706e78242cb24 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:44 -0500
Subject: [PATCH 2299/3820] New translations supported-networks.json (French)

---
 website/pages/fr/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/fr/supported-networks.json

diff --git a/website/pages/fr/supported-networks.json b/website/pages/fr/supported-networks.json
new file mode 100644
index 000000000000..dd6bbee71dc6
--- /dev/null
+++ b/website/pages/fr/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Réseau",
+  "cliName": "Nom du CLI",
+  "chainId": "ID de la chaîne",
+  "hostedService": "Service hébergé",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Réseau décentralisé",
+  "integrationType": "Type d'intégration"
+}

From d85d6e4cd93217d09ae65de8de8db42aec2b5b93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:45 -0500
Subject: [PATCH 2300/3820] New translations supported-networks.json (Spanish)

---
 website/pages/es/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/es/supported-networks.json

diff --git a/website/pages/es/supported-networks.json b/website/pages/es/supported-networks.json
new file mode 100644
index 000000000000..2fc7f4852383
--- /dev/null
+++ b/website/pages/es/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Red",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Servicio Alojado",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From ff5c5ff8f893c2ada93e22e7a560aa97a2dad463 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:46 -0500
Subject: [PATCH 2301/3820] New translations supported-networks.json (Arabic)

---
 website/pages/ar/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/ar/supported-networks.json

diff --git a/website/pages/ar/supported-networks.json b/website/pages/ar/supported-networks.json
new file mode 100644
index 000000000000..3ef903c77b7c
--- /dev/null
+++ b/website/pages/ar/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Network",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "الخدمة المستضافة (Hosted Service)",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From 176e5a4e28cbec9f00c1968b7c56e1829dab7f38 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:47 -0500
Subject: [PATCH 2302/3820] New translations supported-networks.json (Czech)

---
 website/pages/cs/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/cs/supported-networks.json

diff --git a/website/pages/cs/supported-networks.json b/website/pages/cs/supported-networks.json
new file mode 100644
index 000000000000..2cda540608cf
--- /dev/null
+++ b/website/pages/cs/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Síť",
+  "cliName": "Název CLI",
+  "chainId": "ID řetězce",
+  "hostedService": "Hostovaná služba",
+  "subgraphStudio": "Podgraf Studio",
+  "decentralizedNetwork": "Decentralizovaná síť",
+  "integrationType": "Integration Type"
+}

From 7cb03b250207e9bf591d869cd3d3590087ebd00a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:48 -0500
Subject: [PATCH 2303/3820] New translations supported-networks.json (German)

---
 website/pages/de/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/de/supported-networks.json

diff --git a/website/pages/de/supported-networks.json b/website/pages/de/supported-networks.json
new file mode 100644
index 000000000000..9ae5a4b5aae8
--- /dev/null
+++ b/website/pages/de/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Network",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Hosted Service",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From 3f0268a46b167e8e0a1f90374375722ae7ac1d37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:49 -0500
Subject: [PATCH 2304/3820] New translations supported-networks.json (Italian)

---
 website/pages/it/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/it/supported-networks.json

diff --git a/website/pages/it/supported-networks.json b/website/pages/it/supported-networks.json
new file mode 100644
index 000000000000..6fe6b7a50217
--- /dev/null
+++ b/website/pages/it/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "La rete",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Hosted Service",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From bb434e47f23ed359c5bdbed441bafd43810834ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:50 -0500
Subject: [PATCH 2305/3820] New translations supported-networks.json (Japanese)

---
 website/pages/ja/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/ja/supported-networks.json

diff --git a/website/pages/ja/supported-networks.json b/website/pages/ja/supported-networks.json
new file mode 100644
index 000000000000..97aca55c7ea5
--- /dev/null
+++ b/website/pages/ja/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "ネットワーク",
+  "cliName": "CLI名",
+  "chainId": "チェーンID",
+  "hostedService": "ホステッド サービス",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "分散型ネットワーク",
+  "integrationType": "Integration Type"
+}

From 22efdbac5efeb4ddaf8d45c0741ddb114c4eff08 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:51 -0500
Subject: [PATCH 2306/3820] New translations supported-networks.json (Korean)

---
 website/pages/ko/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/ko/supported-networks.json

diff --git a/website/pages/ko/supported-networks.json b/website/pages/ko/supported-networks.json
new file mode 100644
index 000000000000..9ae5a4b5aae8
--- /dev/null
+++ b/website/pages/ko/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Network",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Hosted Service",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From eee21e5a549a352b0ac4353235d98e857e560510 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:52 -0500
Subject: [PATCH 2307/3820] New translations supported-networks.json (Dutch)

---
 website/pages/nl/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/nl/supported-networks.json

diff --git a/website/pages/nl/supported-networks.json b/website/pages/nl/supported-networks.json
new file mode 100644
index 000000000000..659095d1b81d
--- /dev/null
+++ b/website/pages/nl/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Netwerk",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Gehoste Dienst",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From c498153271df2bd547ed771d803fa0e28a13983a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:54 -0500
Subject: [PATCH 2308/3820] New translations supported-networks.json (Polish)

---
 website/pages/pl/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/pl/supported-networks.json

diff --git a/website/pages/pl/supported-networks.json b/website/pages/pl/supported-networks.json
new file mode 100644
index 000000000000..9ae5a4b5aae8
--- /dev/null
+++ b/website/pages/pl/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Network",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Hosted Service",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From 675e1a27cf551d0e7df64b049b071a203b3b1349 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:55 -0500
Subject: [PATCH 2309/3820] New translations supported-networks.json
 (Portuguese)

---
 website/pages/pt/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/pt/supported-networks.json

diff --git a/website/pages/pt/supported-networks.json b/website/pages/pt/supported-networks.json
new file mode 100644
index 000000000000..c491ed0859d2
--- /dev/null
+++ b/website/pages/pt/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Rede",
+  "cliName": "Nome na CLI",
+  "chainId": "ID da Chain",
+  "hostedService": "Serviço Hospedado",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Rede Descentralizada",
+  "integrationType": "Tipo de Integração"
+}

From 13140e2eb9426a884a531b37101161345ae929bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:56 -0500
Subject: [PATCH 2310/3820] New translations supported-networks.json (Russian)

---
 website/pages/ru/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/ru/supported-networks.json

diff --git a/website/pages/ru/supported-networks.json b/website/pages/ru/supported-networks.json
new file mode 100644
index 000000000000..452617529078
--- /dev/null
+++ b/website/pages/ru/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Сеть",
+  "cliName": "Название CLI",
+  "chainId": "ID чейна",
+  "hostedService": "Hosted Service",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Децентрализованная сеть",
+  "integrationType": "Тип интеграции"
+}

From 9ff8c69eb60069d242b5056a18b91c5a6dfe560a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:57 -0500
Subject: [PATCH 2311/3820] New translations supported-networks.json (Swedish)

---
 website/pages/sv/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/sv/supported-networks.json

diff --git a/website/pages/sv/supported-networks.json b/website/pages/sv/supported-networks.json
new file mode 100644
index 000000000000..37c7894ca8a0
--- /dev/null
+++ b/website/pages/sv/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Nätverk",
+  "cliName": "Kommandoradsgränssnitt namn",
+  "chainId": "Kedje-ID",
+  "hostedService": "Värdtjänster",
+  "subgraphStudio": "Subgraf Studion",
+  "decentralizedNetwork": "Decentraliserat Nätverk",
+  "integrationType": "Integration Type"
+}

From 68ec6562691eaf50b744b312642db9eb4e06ca90 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:58 -0500
Subject: [PATCH 2312/3820] New translations supported-networks.json (Turkish)

---
 website/pages/tr/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/tr/supported-networks.json

diff --git a/website/pages/tr/supported-networks.json b/website/pages/tr/supported-networks.json
new file mode 100644
index 000000000000..12a54cd5f729
--- /dev/null
+++ b/website/pages/tr/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Ağ",
+  "cliName": "CLI Adı",
+  "chainId": "Zincir Kimliği",
+  "hostedService": "Barındırılan hizmet",
+  "subgraphStudio": "Subgraph Stüdyosu",
+  "decentralizedNetwork": "Merkeziyetsiz Ağ",
+  "integrationType": "Entegrasyon Türü"
+}

From db1615c4a8a2e6f3bf5997296692d4bc63408aa2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:25:59 -0500
Subject: [PATCH 2313/3820] New translations supported-networks.json
 (Ukrainian)

---
 website/pages/uk/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/uk/supported-networks.json

diff --git a/website/pages/uk/supported-networks.json b/website/pages/uk/supported-networks.json
new file mode 100644
index 000000000000..db061a68623a
--- /dev/null
+++ b/website/pages/uk/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Network",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Хостинговий сервіс",
+  "subgraphStudio": "Субграф Студія",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From 98995252ed862f15dd590ccb53eba4d6a1ab6a0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:26:01 -0500
Subject: [PATCH 2314/3820] New translations supported-networks.json (Chinese
 Simplified)

---
 website/pages/zh/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/zh/supported-networks.json

diff --git a/website/pages/zh/supported-networks.json b/website/pages/zh/supported-networks.json
new file mode 100644
index 000000000000..1c262b09c338
--- /dev/null
+++ b/website/pages/zh/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "网络",
+  "cliName": "CLI名字",
+  "chainId": "链id",
+  "hostedService": "托管服务",
+  "subgraphStudio": "子图工作室",
+  "decentralizedNetwork": "去中心化网络",
+  "integrationType": "Integration Type"
+}

From 23e41d4903504f5a7161b5a35d7b029a6fd91f8d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:26:02 -0500
Subject: [PATCH 2315/3820] New translations supported-networks.json (Urdu
 (Pakistan))

---
 website/pages/ur/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/ur/supported-networks.json

diff --git a/website/pages/ur/supported-networks.json b/website/pages/ur/supported-networks.json
new file mode 100644
index 000000000000..1db47456c314
--- /dev/null
+++ b/website/pages/ur/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "نیٹ ورک",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Hosted Service",
+  "subgraphStudio": "سب گراف سٹوڈیو",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From 6ab1613301e4b01f8594787f04014dc118bc4f1d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:26:03 -0500
Subject: [PATCH 2316/3820] New translations supported-networks.json
 (Vietnamese)

---
 website/pages/vi/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/vi/supported-networks.json

diff --git a/website/pages/vi/supported-networks.json b/website/pages/vi/supported-networks.json
new file mode 100644
index 000000000000..1f754354dd99
--- /dev/null
+++ b/website/pages/vi/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Mạng lưới",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Dịch vụ được lưu trữ",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From ab187888b224ddd625913057adc7d19e30369af2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:26:04 -0500
Subject: [PATCH 2317/3820] New translations supported-networks.json (Marathi)

---
 website/pages/mr/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/mr/supported-networks.json

diff --git a/website/pages/mr/supported-networks.json b/website/pages/mr/supported-networks.json
new file mode 100644
index 000000000000..9ae5a4b5aae8
--- /dev/null
+++ b/website/pages/mr/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Network",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Hosted Service",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From 9ee2521002ed9b1db8abe73092c65e72a49442a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:26:05 -0500
Subject: [PATCH 2318/3820] New translations supported-networks.json (Hindi)

---
 website/pages/hi/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/hi/supported-networks.json

diff --git a/website/pages/hi/supported-networks.json b/website/pages/hi/supported-networks.json
new file mode 100644
index 000000000000..ac3bb6f048e9
--- /dev/null
+++ b/website/pages/hi/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "नेटवर्क",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Hosted Service",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From 71e73e213f89f587c3db9ab8c2a1644b6021d381 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 14:26:06 -0500
Subject: [PATCH 2319/3820] New translations supported-networks.json (Swahili)

---
 website/pages/sw/supported-networks.json | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 website/pages/sw/supported-networks.json

diff --git a/website/pages/sw/supported-networks.json b/website/pages/sw/supported-networks.json
new file mode 100644
index 000000000000..9ae5a4b5aae8
--- /dev/null
+++ b/website/pages/sw/supported-networks.json
@@ -0,0 +1,9 @@
+{
+  "network": "Network",
+  "cliName": "CLI Name",
+  "chainId": "Chain ID",
+  "hostedService": "Hosted Service",
+  "subgraphStudio": "Subgraph Studio",
+  "decentralizedNetwork": "Decentralized Network",
+  "integrationType": "Integration Type"
+}

From 23c7c342d8eea1d970c39e490c3017dcab1623c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:40:02 -0500
Subject: [PATCH 2320/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
index 5898077a6936..93512fa83f89 100644
--- a/website/pages/de/indexing/overview.mdx
+++ b/website/pages/de/indexing/overview.mdx
@@ -149,7 +149,7 @@ Note: To support agile scaling, it is recommended that query and indexing concer
 
 > **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
 
-#### Der Graph-Knoten
+#### Graph Node
 
 | Port | Zweck                                           | Routen                                         | CLI-Argument       | Umgebungsvariable |
 | ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | ----------------- |
@@ -297,7 +297,7 @@ kubectl config use-context $(kubectl config get-contexts --output='name'
 
 Deploy all resources with `kubectl apply -k $dir`.
 
-### Der Graph-Knoten
+### Graph Node
 
 [Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
 

From ec20ffdd5280fb97c7f43ab9a5a1d28ce5779a05 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:40:03 -0500
Subject: [PATCH 2321/3820] New translations overview.mdx (Italian)

---
 website/pages/it/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/it/indexing/overview.mdx b/website/pages/it/indexing/overview.mdx
index fcd01714bbb8..171e836778d6 100644
--- a/website/pages/it/indexing/overview.mdx
+++ b/website/pages/it/indexing/overview.mdx
@@ -340,7 +340,7 @@ cargo run -p graph-node --release -- \
 
 #### Come iniziare a usare Docker
 
-#### Prerequisites
+#### Prerequisiti
 
 - **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
 
@@ -459,7 +459,7 @@ docker run -p 18000:8000 -it indexer-agent:latest ...
 
 See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
 
-#### Usage
+#### Utilizzo
 
 > **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
 
@@ -531,7 +531,7 @@ graph indexer status
 
 The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
 
-#### Usage
+#### Utilizzo
 
 The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
 

From 8d5f22a3f04479cdb149761e354405448ef2eec8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:40:12 -0500
Subject: [PATCH 2322/3820] New translations overview.mdx (Dutch)

---
 website/pages/nl/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/nl/indexing/overview.mdx b/website/pages/nl/indexing/overview.mdx
index 7a90a3200a65..3659d48ee94f 100644
--- a/website/pages/nl/indexing/overview.mdx
+++ b/website/pages/nl/indexing/overview.mdx
@@ -340,7 +340,7 @@ cargo run -p graph-node --release -- \
 
 #### Starten met Docker
 
-#### Prerequisites
+#### Vereisten
 
 - **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
 
@@ -459,7 +459,7 @@ docker run -p 18000:8000 -it indexer-agent:latest ...
 
 See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
 
-#### Usage
+#### Gebruik
 
 > **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
 
@@ -531,7 +531,7 @@ graph indexer status
 
 The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
 
-#### Usage
+#### Gebruik
 
 The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
 

From a8d580fd093c2f536f18d12f97f70fd5c2a46c48 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:40:21 -0500
Subject: [PATCH 2323/3820] New translations overview.mdx (Turkish)

---
 website/pages/tr/indexing/overview.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/indexing/overview.mdx b/website/pages/tr/indexing/overview.mdx
index 9eaa60e5ac98..403b5e2f1abb 100644
--- a/website/pages/tr/indexing/overview.mdx
+++ b/website/pages/tr/indexing/overview.mdx
@@ -459,7 +459,7 @@ docker run -p 18000:8000 -it indexer-agent:latest ...
 
 See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
 
-#### Kullanış
+#### Kullanım
 
 > **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
 
@@ -531,7 +531,7 @@ graph indexer status
 
 The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
 
-#### Kullanış
+#### Kullanım
 
 The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
 

From 6d281cc27b6c8dc442148269174e0728d83a6e14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:40:23 -0500
Subject: [PATCH 2324/3820] New translations overview.mdx (Ukrainian)

---
 website/pages/uk/indexing/overview.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/uk/indexing/overview.mdx b/website/pages/uk/indexing/overview.mdx
index f296f9b15e07..3b3e09df18c7 100644
--- a/website/pages/uk/indexing/overview.mdx
+++ b/website/pages/uk/indexing/overview.mdx
@@ -10,7 +10,7 @@ GRT, які застейкані в протоколі, підлягають п
 
 <Difficulty level="ADVANCED" />
 
-## FAQ
+## Поширені запитання
 
 ### Яка мінімальна кількість GRT необхідна для того, щоб стати індексатором в мережі?
 
@@ -340,7 +340,7 @@ cargo run -p graph-node --release -- \
 
 #### Початок роботи з Docker
 
-#### Prerequisites
+#### Передумови
 
 - **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
 
@@ -459,7 +459,7 @@ docker run -p 18000:8000 -it indexer-agent:latest ...
 
 See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
 
-#### Usage
+#### Використання
 
 > **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
 
@@ -531,7 +531,7 @@ graph indexer status
 
 The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
 
-#### Usage
+#### Використання
 
 The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
 

From db854749ad8189ab18cb32a104e99948dad8e420 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:40:25 -0500
Subject: [PATCH 2325/3820] New translations overview.mdx (Urdu (Pakistan))

---
 website/pages/ur/indexing/overview.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ur/indexing/overview.mdx b/website/pages/ur/indexing/overview.mdx
index dba342e3bf8a..68171eb27f5e 100644
--- a/website/pages/ur/indexing/overview.mdx
+++ b/website/pages/ur/indexing/overview.mdx
@@ -10,7 +10,7 @@ title: Indexing Overview
 
 <Difficulty level="ADVANCED" />
 
-## FAQ
+## عمومی سوالات
 
 ### نیٹ ورک پر انڈیکسر بننے کے لیے کم از کم کتنا سٹیک درکار ہے?
 
@@ -340,7 +340,7 @@ cargo run -p graph-node --release -- \
 
 #### Docker کے ساتھ استعمال شروع کرنا
 
-#### شرطیں
+#### اولین ضروریات
 
 - **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
 

From 1a0c9112012068a971dd744361a271668da1983d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:40:31 -0500
Subject: [PATCH 2326/3820] New translations overview.mdx (Hindi)

---
 website/pages/hi/indexing/overview.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/hi/indexing/overview.mdx b/website/pages/hi/indexing/overview.mdx
index e157e17b9427..9dc77212b462 100644
--- a/website/pages/hi/indexing/overview.mdx
+++ b/website/pages/hi/indexing/overview.mdx
@@ -10,7 +10,7 @@ Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) i
 
 <Difficulty level="ADVANCED" />
 
-## सामान्य प्रश्न
+## FAQ
 
 ### नेटवर्क पर इंडेक्सर बनने के लिए आवश्यक न्यूनतम हिस्सेदारी क्या है?
 
@@ -149,7 +149,7 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 > **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
 
-#### Graph Node
+#### ग्राफ-नोड
 
 | Port | Purpose                                            | Routes                                         | CLI Argument       | Environment Variable |
 | ---- | -------------------------------------------------- | ---------------------------------------------- | ------------------ | -------------------- |
@@ -297,7 +297,7 @@ kubectl config use-context $(kubectl config get-contexts --output='name'
 
 Deploy all resources with `kubectl apply -k $dir`.
 
-### Graph Node
+### ग्राफ-नोड
 
 [Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
 
@@ -459,7 +459,7 @@ docker run -p 18000:8000 -it indexer-agent:latest ...
 
 See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
 
-#### प्रयोग
+#### Usage
 
 > **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
 
@@ -531,7 +531,7 @@ graph indexer status
 
 The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
 
-#### प्रयोग
+#### Usage
 
 The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
 

From 214adcac1d4ef75a2d0bb031e18be554bd933dd9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:40:38 -0500
Subject: [PATCH 2327/3820] New translations graph-node.mdx (German)

---
 website/pages/de/indexing/tooling/graph-node.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/indexing/tooling/graph-node.mdx b/website/pages/de/indexing/tooling/graph-node.mdx
index 9dedce36b46f..80b73f102d83 100644
--- a/website/pages/de/indexing/tooling/graph-node.mdx
+++ b/website/pages/de/indexing/tooling/graph-node.mdx
@@ -1,12 +1,12 @@
 ---
-title: Der Graph-Knoten
+title: Graph Node
 ---
 
 Graph Node ist die Komponente, die Subgrafen indiziert und die resultierenden Daten zur Abfrage über eine GraphQL-API verfügbar macht. Als solches ist es für den Indexer-Stack von zentraler Bedeutung, und der korrekte Betrieb des Graph-Knotens ist entscheidend für den Betrieb eines erfolgreichen Indexers.
 
 This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
 
-## Der Graph-Knoten
+## Graph Node
 
 [Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
 

From a34be47a9d5007a6794d6d5158fe9b17c8638ab0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:41:03 -0500
Subject: [PATCH 2328/3820] New translations graph-node.mdx (Hindi)

---
 website/pages/hi/indexing/tooling/graph-node.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/indexing/tooling/graph-node.mdx b/website/pages/hi/indexing/tooling/graph-node.mdx
index 6a95fb4ce462..3ee68e49d3a0 100644
--- a/website/pages/hi/indexing/tooling/graph-node.mdx
+++ b/website/pages/hi/indexing/tooling/graph-node.mdx
@@ -1,12 +1,12 @@
 ---
-title: Graph Node
+title: ग्राफ-नोड
 ---
 
 Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
 
 This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
 
-## Graph Node
+## ग्राफ-नोड
 
 [Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
 

From 2a1d45f552421ab4b95526326d2978afd0cad407 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:41:09 -0500
Subject: [PATCH 2329/3820] New translations unit-testing-framework.mdx
 (French)

---
 .../fr/subgraphs/developing/creating/unit-testing-framework.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
index 5528316d8f9f..a22190b21853 100644
--- a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -9,7 +9,7 @@ Learn how to use Matchstick, a unit testing framework developed by [LimeChain](h
 - It's written in Rust and optimized for high performance.
 - It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
 
-## Démarrage
+## Introduction
 
 ### Install Dependencies
 

From 8a7b0cf5cba36de3528f035c892ffa553ecaae29 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:41:42 -0500
Subject: [PATCH 2330/3820] New translations unit-testing-framework.mdx
 (German)

---
 .../subgraphs/developing/creating/unit-testing-framework.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx
index 2133c1d4b5c9..f929197ebe84 100644
--- a/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -55,7 +55,7 @@ You can use Matchstick on WSL both using the Docker approach and the binary appr
 static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
 ```
 
-or
+oder
 
 ```
 <PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
@@ -218,7 +218,7 @@ describe("handleNewGravatar()", () => {
 })
 ```
 
-or
+oder
 
 ```typescript
 test("handleNewGravatar() should create a new entity", () => {

From 838a67cfbb4e33634545effc3e3e6301b0aae81d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:41:44 -0500
Subject: [PATCH 2331/3820] New translations unit-testing-framework.mdx
 (Italian)

---
 .../developing/creating/unit-testing-framework.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/it/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/it/subgraphs/developing/creating/unit-testing-framework.mdx
index 2133c1d4b5c9..541f68b94dc9 100644
--- a/website/pages/it/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/it/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -9,7 +9,7 @@ Learn how to use Matchstick, a unit testing framework developed by [LimeChain](h
 - It's written in Rust and optimized for high performance.
 - It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
 
-## Getting Started
+## Per cominciare
 
 ### Install Dependencies
 
@@ -55,7 +55,7 @@ You can use Matchstick on WSL both using the Docker approach and the binary appr
 static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
 ```
 
-or
+oppure
 
 ```
 <PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
@@ -218,7 +218,7 @@ describe("handleNewGravatar()", () => {
 })
 ```
 
-or
+oppure
 
 ```typescript
 test("handleNewGravatar() should create a new entity", () => {
@@ -234,7 +234,7 @@ test("handleNewGravatar() should create a new entity", () => {
 
 Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
 
-Examples:
+Esempi:
 
 Code inside `beforeAll` will execute once before _all_ tests in the file.
 
@@ -418,7 +418,7 @@ describe('handleUpdatedGravatars', () => {
 
 Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
 
-Examples:
+Esempi:
 
 Code inside `afterEach` will execute after every test.
 
@@ -1293,7 +1293,7 @@ Using **Matchstick**, subgraph developers are able to run a script that will cal
 
 The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
 
-### Prerequisites
+### Prerequisiti
 
 To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
 
@@ -1311,7 +1311,7 @@ In order for that function to be visible (for it to be included in the `wat` fil
 export { handleNewGravatar }
 ```
 
-### Usage
+### Utilizzo
 
 Once that's all set up, to run the test coverage tool, simply run:
 

From a9b539e38977ace0573e5f4fcfbc95a8a5b47f09 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:41:52 -0500
Subject: [PATCH 2332/3820] New translations unit-testing-framework.mdx (Dutch)

---
 .../subgraphs/developing/creating/unit-testing-framework.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/nl/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/nl/subgraphs/developing/creating/unit-testing-framework.mdx
index 2133c1d4b5c9..70c1f2bcfc58 100644
--- a/website/pages/nl/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/nl/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -1293,7 +1293,7 @@ Using **Matchstick**, subgraph developers are able to run a script that will cal
 
 The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
 
-### Prerequisites
+### Vereisten
 
 To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
 
@@ -1311,7 +1311,7 @@ In order for that function to be visible (for it to be included in the `wat` fil
 export { handleNewGravatar }
 ```
 
-### Usage
+### Gebruik
 
 Once that's all set up, to run the test coverage tool, simply run:
 

From 14cd579fccc028865a5f350cf046744eee78198f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:41:59 -0500
Subject: [PATCH 2333/3820] New translations unit-testing-framework.mdx
 (Turkish)

---
 .../tr/subgraphs/developing/creating/unit-testing-framework.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/tr/subgraphs/developing/creating/unit-testing-framework.mdx
index 6968cbcc5e22..538ed6d6c6b6 100644
--- a/website/pages/tr/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/tr/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -1311,7 +1311,7 @@ In order for that function to be visible (for it to be included in the `wat` fil
 export { handleNewGravatar }
 ```
 
-### Kullanış
+### Kullanım
 
 Her şey hazır olduğunda, test kapsama aracını çalıştırmak için basitçe şunu çalıştırın:
 

From 6bdbcf840592d58e6b816d88a429c9609898324b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:42:00 -0500
Subject: [PATCH 2334/3820] New translations unit-testing-framework.mdx
 (Ukrainian)

---
 .../subgraphs/developing/creating/unit-testing-framework.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/uk/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/uk/subgraphs/developing/creating/unit-testing-framework.mdx
index 78df2c601459..7488f64a33c6 100644
--- a/website/pages/uk/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/uk/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -1293,7 +1293,7 @@ Using **Matchstick**, subgraph developers are able to run a script that will cal
 
 The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
 
-### Prerequisites
+### Передумови
 
 To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
 
@@ -1311,7 +1311,7 @@ In order for that function to be visible (for it to be included in the `wat` fil
 export { handleNewGravatar }
 ```
 
-### Usage
+### Використання
 
 Once that's all set up, to run the test coverage tool, simply run:
 

From 658954bd9b27e0a43e1f2a01ad2442a7bdf053a2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:42:01 -0500
Subject: [PATCH 2335/3820] New translations unit-testing-framework.mdx (Urdu
 (Pakistan))

---
 .../ur/subgraphs/developing/creating/unit-testing-framework.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/ur/subgraphs/developing/creating/unit-testing-framework.mdx
index 0effe170f354..b11522fb9702 100644
--- a/website/pages/ur/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/ur/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -1293,7 +1293,7 @@ Using **Matchstick**, subgraph developers are able to run a script that will cal
 
 The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
 
-### شرطیں
+### اولین ضروریات
 
 To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
 

From 6266ec33c6b7b218ebcd1e025171ac78d5b8a093 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:42:07 -0500
Subject: [PATCH 2336/3820] New translations unit-testing-framework.mdx (Hindi)

---
 .../hi/subgraphs/developing/creating/unit-testing-framework.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx
index 843caff9680f..ac80402ff9fa 100644
--- a/website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -1313,7 +1313,7 @@ In order for that function to be visible (for it to be included in the `wat` fil
 export { handleNewGravatar }
 ```
 
-### प्रयोग
+### Usage
 
 एक बार यह सब सेट हो जाने के बाद, परीक्षण कवरेज टूल चलाने के लिए, बस चलाएँ:
 

From 8366e210e60a3191af540849235301de76e51e37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:42:10 -0500
Subject: [PATCH 2337/3820] New translations python.mdx (French)

---
 website/pages/fr/subgraphs/querying/python.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/querying/python.mdx b/website/pages/fr/subgraphs/querying/python.mdx
index 56ad17c8a8be..d139839cacbc 100644
--- a/website/pages/fr/subgraphs/querying/python.mdx
+++ b/website/pages/fr/subgraphs/querying/python.mdx
@@ -6,7 +6,7 @@ Subgrounds est une librairie Python utilisée pour les requêtes Subgraph. Cette
 
 Subgrounds propose une API Python simplifiée afin de construire des requêtes GraphQL. Subgrounds automatise les workflows fastidieux comme la pagination, et donne aux utilisateurs avancés plus de pouvoir grâce à des transformations de schéma contrôlées.
 
-## Démarrage
+## Introduction
 
 Subgrounds nécessite Python 3.10 ou une version ultérieure. Subgrounds est disponible depuis [pypi](https://pypi.org/project/subgrounds/).
 

From b2eb7b697666108d1e8060b3dfed81bebef9316c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:42:15 -0500
Subject: [PATCH 2338/3820] New translations python.mdx (Italian)

---
 website/pages/it/subgraphs/querying/python.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/subgraphs/querying/python.mdx b/website/pages/it/subgraphs/querying/python.mdx
index 6468c62fc487..38d3af4c359d 100644
--- a/website/pages/it/subgraphs/querying/python.mdx
+++ b/website/pages/it/subgraphs/querying/python.mdx
@@ -6,7 +6,7 @@ Subgrounds è una libreria Python intuitiva per query dei subgraph, realizzata d
 
 Subgrounds offre una semplice API Pythonic per la creazione di query GraphQL, automatizza i flussi di lavoro più noiosi come la paginazione, e dà agli utenti avanzati la possibilità di effettuare trasformazioni controllate dello schema.
 
-## Getting Started
+## Per cominciare
 
 Subgrounds richiede Python 3.10 o superiore ed è disponibile su [pypi](https://pypi.org/project/subgrounds/).
 

From d73bb655cf6e0432263d027a97ed5069eda54d53 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:42:38 -0500
Subject: [PATCH 2339/3820] New translations arbitrum-faq.mdx (French)

---
 website/pages/fr/archived/arbitrum/arbitrum-faq.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/archived/arbitrum/arbitrum-faq.mdx b/website/pages/fr/archived/arbitrum/arbitrum-faq.mdx
index 6e037eab2211..b2f6d7382c61 100644
--- a/website/pages/fr/archived/arbitrum/arbitrum-faq.mdx
+++ b/website/pages/fr/archived/arbitrum/arbitrum-faq.mdx
@@ -20,11 +20,11 @@ La communauté Graph a décidé d'avancer avec Arbitrum l'année dernière aprè
 
 ## Que dois-je faire pour utiliser The Graph en L2 ?
 
-Le système de facturation de The Graph accepte le GRT sur Arbitrum, et les utilisateurs auront besoin d'ETH sur Arbitrum pour payer leurs frais de gaz. Bien que le protocole The Graph ait commencé sur Ethereum Mainnet, toute l'activité, y compris les contrats de facturation, est maintenant sur Arbitrum One.
+Le système de facturation de The Graph accepte le GRT sur Arbitrum, et les utilisateurs devront disposer d'ETH sur Arbitrum pour payer le gaz. Bien que le protocole The Graph ait commencé sur le réseau principal d'Ethereum, toutes les activités, y compris les contrats de facturation, sont désormais réalisées sur Arbitrum One.
 
 Par conséquent, pour payer les requêtes, vous avez besoin de GRT sur Arbitrum. Voici quelques façons d'y parvenir :
 
-- Si vous avez déjà des GRT sur Ethereum, vous pouvez les bridge vers Arbitrum. Vous pouvez le faire via l'option de bridge de GRT fournie dans Subgraph Studio ou en utilisant l'un des bridges suivants :
+- Si vous avez déjà des GRT sur Ethereum, vous pouvez les transférer vers Arbitrum. Vous pouvez le faire via l'option de transfert de GRT fournie dans Subgraph Studio ou en utilisant l'un des ponts suivants :
 
   - [Le Bridge Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161)
   - [TransferTo](https://transferto.xyz/swap)

From 25e1dad3716e10ce83f778c1263306c4951d6841 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:42:48 -0500
Subject: [PATCH 2340/3820] New translations arbitrum-faq.mdx (Portuguese)

---
 website/pages/pt/archived/arbitrum/arbitrum-faq.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pt/archived/arbitrum/arbitrum-faq.mdx b/website/pages/pt/archived/arbitrum/arbitrum-faq.mdx
index 9698a750905d..0c1ba5b192ef 100644
--- a/website/pages/pt/archived/arbitrum/arbitrum-faq.mdx
+++ b/website/pages/pt/archived/arbitrum/arbitrum-faq.mdx
@@ -20,11 +20,11 @@ A comunidade do The Graph prosseguiu com o Arbitrum no ano passado, após o resu
 
 ## O que preciso fazer para usar o The Graph na L2?
 
-O sistema de cobranças do The Graph aceita GRT no Arbitrum, e utilizadores precisarão de ETH no Arbitrum para pagar pelo seu gas. O protocolo do The Graph começou na Mainnet do Ethereum, mas todas as atividades, que incluem os contratos de cobranças, agora se encontram no Arbitrum One.
+O sistema de cobranças do The Graph aceita GRT no Arbitrum, e os utilizadores precisarão de ETH no Arbitrum para pagar pelo seu gas. Enquanto o protocolo do The Graph começou na Mainnet do Ethereum, todas as atividades, inclusive os contratos de cobranças, agora ficam no Arbitrum One.
 
 Portanto, para pagar por queries, é necessário GRT no Arbitrum. Aqui estão algumas maneiras diferentes de consegui-lo:
 
-- Caso já tenha GRT no Ethereum, é possível enviá-lo ao Arbitrum via bridge. Isto pode ser feito via a opção de bridging de GRT providenciada no Subgraph Studio ou uma das seguintes bridges:
+- Caso já tenha GRT no Ethereum, é possível enviá-lo ao Arbitrum via bridge. Isto é possível via a opção de bridging de GRT providenciada no Subgraph Studio ou uma das seguintes bridges:
 
   - [Bridge no Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161)
   - [TransferTo](https://transferto.xyz/swap)

From 0705b0012fbd393fa88cc900fcb89c30147e311c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:42:57 -0500
Subject: [PATCH 2341/3820] New translations arbitrum-faq.mdx (Turkish)

---
 website/pages/tr/archived/arbitrum/arbitrum-faq.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/archived/arbitrum/arbitrum-faq.mdx b/website/pages/tr/archived/arbitrum/arbitrum-faq.mdx
index 63db1affd745..ca32d52975dc 100644
--- a/website/pages/tr/archived/arbitrum/arbitrum-faq.mdx
+++ b/website/pages/tr/archived/arbitrum/arbitrum-faq.mdx
@@ -20,11 +20,11 @@ Graph topluluğu, geçen yıl [GIP-0031](https://forum.thegraph.com/t/gip-0031-a
 
 ## Graph'ı Katman2'de kullanmak için ne yapmam gerekiyor?
 
-The Graph'in faturalandırma sistemi, Arbitrum ağı üzerinde GRT ile ödeme alır. Kullanıcıların gaz ücretlerini ödemek için Arbitrum üzerinde ETH'ye ihtiyaçları olacaktır. The Graph protokolü, başlangıçta Ethereum Mainnet üzerinde başlatılmış olsa da, faturalandırma sözleşmeleri de dahil olmak üzere tüm faaliyetler artık Arbitrum One üzerinde gerçekleştirilmektedir.
+The Graph'in faturalandırma sistemi, Arbitrum ağı üzerinde GRT ile ödeme alır. Kullanıcıların gas ücretlerini ödemek için Arbitrum üzerinde ETH'ye ihtiyaçları olacaktır. The Graph protokolü, başlangıçta Ethereum Mainnet üzerinde başlatılmış olsa da, faturalandırma sözleşmeleri de dahil olmak üzere tüm faaliyetler artık Arbitrum One üzerinde gerçekleştirilmektedir.
 
 Dolayısıyla, sorgu ödemelerini yapmak için Arbitrum üzerinde GRT'ye ihtiyacınız var. İşte GRT elde etmenin birkaç farklı yolu:
 
-- Ethereum üzerinde halihazırda GRT'leriniz varsa, bunları Arbitrum'a köprüleyebilirsiniz. Bu işlemi Subgraph Studio'da sunulan GRT köprüleme seçeneği aracılığıyla veya aşağıdaki köprülerden birini kullanarak yapabilirsiniz:
+- Ethereum üzerinde zaten GRT'niz varsa, bunu Arbitrum'a köprüleyebilirsiniz. Bunu, Subgraph Studio'da sunulan GRT köprüleme seçeneği aracılığıyla veya aşağıdaki köprülerden birini kullanarak yapabilirsiniz:
 
   - [Arbitrum Köprüsü](https://bridge.arbitrum.io/?l2ChainId=42161)
   - [TransferTo](https://transferto.xyz/swap)

From 371d63feed39a01171fe92375eb8b217c511935a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:43:06 -0500
Subject: [PATCH 2342/3820] New translations arbitrum-faq.mdx (Hindi)

---
 website/pages/hi/archived/arbitrum/arbitrum-faq.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/archived/arbitrum/arbitrum-faq.mdx b/website/pages/hi/archived/arbitrum/arbitrum-faq.mdx
index 3c96c3cd78e2..17a0fc9ca167 100644
--- a/website/pages/hi/archived/arbitrum/arbitrum-faq.mdx
+++ b/website/pages/hi/archived/arbitrum/arbitrum-faq.mdx
@@ -20,11 +20,11 @@ The Graph community decided to move forward with Arbitrum last year after the ou
 
 ## What do I need to do to use The Graph on L2?
 
-The Graph का बिलिंग सिस्टम Arbitrum पर GRT स्वीकार करता है, और उपयोगकर्ताओं को गैस के लिए Arbitrum पर ETHकी आवश्यकता होगी। जबकि The Graph प्रोटोकॉल Ethereum Mainnet पर शुरू हुआ था, अब सभी गतिविधियाँ, जिसमें बिलिंग कॉन्ट्रैक्ट्स शामिल हैं, Arbitrum One पर हैं।
+The Graph का बिलिंग सिस्टम Arbitrum पर GRT को स्वीकार करता है, और उपयोगकर्ताओं को गैस के भुगतान के लिए Arbitrum  पर ETH की आवश्यकता होगी। जबकि The Graph प्रोटोकॉल Ethereum Mainnet पर शुरू हुआ, सभी गतिविधियाँ, जिसमें बिलिंग कॉन्ट्रैक्ट्स भी शामिल हैं, अब Arbitrum One पर हैं।
 
 अत: क्वेरीज़ के लिए भुगतान करने के लिए, आपको Arbitrum पर GRT की आवश्यकता है। इसे प्राप्त करने के कुछ विभिन्न तरीके यहाँ दिए गए हैं:
 
-- यदि आपके पास पहले से Ethereum पर GRT है, तो आप इसे Arbitrum पर ब्रिज कर सकते हैं। आप इसे Subgraph Studio में उपलब्ध GRT ब्रिजिंग विकल्प के माध्यम से या निम्नलिखित में से किसी एक ब्रिज का उपयोग करके कर सकते हैं:
+- यदि आपके पास पहले से  Ethereum पर GRT है, तो आप इसे Arbitrum पर ब्रिज कर सकते हैं। आप यह Subgraph Studio में प्रदान किए गए GRT ब्रिजिंग विकल्प के माध्यम से या निम्नलिखित में से किसी एक ब्रिज का उपयोग करके कर सकते हैं:
 
   - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
   - [TransferTo](https://transferto.xyz/swap)

From de6441f709c0f36a633b1936e687fdf1404ff208 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:44:04 -0500
Subject: [PATCH 2343/3820] New translations firehose.mdx (French)

---
 website/pages/fr/indexing/tooling/firehose.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/indexing/tooling/firehose.mdx b/website/pages/fr/indexing/tooling/firehose.mdx
index 29d1eb45128e..5eabbd66a503 100644
--- a/website/pages/fr/indexing/tooling/firehose.mdx
+++ b/website/pages/fr/indexing/tooling/firehose.mdx
@@ -14,7 +14,7 @@ Firehose extrait, transforme et enregistre les données de la blockchain dans un
 
 The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
 
-### Démarrage
+### Introduction
 
 - Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
 - Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.

From 3e1570aaed49ac7d3e7c5722b1c621beb897cefc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:44:10 -0500
Subject: [PATCH 2344/3820] New translations firehose.mdx (Italian)

---
 website/pages/it/indexing/tooling/firehose.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/indexing/tooling/firehose.mdx b/website/pages/it/indexing/tooling/firehose.mdx
index 0f0fdebbafd0..8ebcca2d0822 100644
--- a/website/pages/it/indexing/tooling/firehose.mdx
+++ b/website/pages/it/indexing/tooling/firehose.mdx
@@ -14,7 +14,7 @@ Firehose extracts, transforms and saves blockchain data in a highly performant f
 
 The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
 
-### Getting Started
+### Per cominciare
 
 - Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
 - Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.

From 09664d7ed8910be3582fe1ace143cac6d0b08be3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:44:28 -0500
Subject: [PATCH 2345/3820] New translations graphcast.mdx (Romanian)

---
 website/pages/ro/indexing/tooling/graphcast.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/indexing/tooling/graphcast.mdx b/website/pages/ro/indexing/tooling/graphcast.mdx
index 4072877a1257..cac63bbd9340 100644
--- a/website/pages/ro/indexing/tooling/graphcast.mdx
+++ b/website/pages/ro/indexing/tooling/graphcast.mdx
@@ -16,6 +16,6 @@ The Graphcast SDK (Software Development Kit) allows developers to build Radios,
 - Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
 - Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
 
-### Learn More
+### Află mai multe
 
 If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From ee76a24d876f980e1cdabe34d3b0f54b0a653f7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:44:38 -0500
Subject: [PATCH 2346/3820] New translations graphcast.mdx (Dutch)

---
 website/pages/nl/indexing/tooling/graphcast.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/indexing/tooling/graphcast.mdx b/website/pages/nl/indexing/tooling/graphcast.mdx
index 4072877a1257..cbc12c17f95b 100644
--- a/website/pages/nl/indexing/tooling/graphcast.mdx
+++ b/website/pages/nl/indexing/tooling/graphcast.mdx
@@ -16,6 +16,6 @@ The Graphcast SDK (Software Development Kit) allows developers to build Radios,
 - Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
 - Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
 
-### Learn More
+### Leer Meer
 
 If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From e58f743fe5d28da9c7878b7d3615d7bf13a60f0b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:44:40 -0500
Subject: [PATCH 2347/3820] New translations graphcast.mdx (Swedish)

---
 website/pages/sv/indexing/tooling/graphcast.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/indexing/tooling/graphcast.mdx b/website/pages/sv/indexing/tooling/graphcast.mdx
index 843b713c1bd0..213029e1836b 100644
--- a/website/pages/sv/indexing/tooling/graphcast.mdx
+++ b/website/pages/sv/indexing/tooling/graphcast.mdx
@@ -16,6 +16,6 @@ Graphcast SDK (Utrustning för programvaruutveckling) gör det möjligt för utv
 - Självrapportering om indexeringanalys, inklusive tid för delgrafindexering, gasavgifter för handler, påträffade indexeringsfel etc.
 - Självrapportering om stackinformation inklusive graph-node-version, Postgres-version, Ethereum-klientversion etc.
 
-### Lär dig mer
+### Läs mer
 
 Om du vill lära dig mer om Graphcast, [kolla in dokumentationen här.](https://docs.graphops.xyz/graphcast/intro)

From 6232cc5ed0659f4617cf0ba4447115ffa86b67ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:44:46 -0500
Subject: [PATCH 2348/3820] New translations firehose.mdx (Marathi)

---
 website/pages/mr/indexing/tooling/firehose.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/indexing/tooling/firehose.mdx b/website/pages/mr/indexing/tooling/firehose.mdx
index 6b643f84a0e0..333a00c1b32c 100644
--- a/website/pages/mr/indexing/tooling/firehose.mdx
+++ b/website/pages/mr/indexing/tooling/firehose.mdx
@@ -1,5 +1,5 @@
 ---
-title: Firehose
+title: फायरहोस
 ---
 
 ![Firehose Logo](/img/firehose-logo.png)

From a72b87e9469153128dd435b779380f6b1de6df7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:44:47 -0500
Subject: [PATCH 2349/3820] New translations graphcast.mdx (Turkish)

---
 website/pages/tr/indexing/tooling/graphcast.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/indexing/tooling/graphcast.mdx b/website/pages/tr/indexing/tooling/graphcast.mdx
index 1ddae707e52e..d0bce650e2ae 100644
--- a/website/pages/tr/indexing/tooling/graphcast.mdx
+++ b/website/pages/tr/indexing/tooling/graphcast.mdx
@@ -16,6 +16,6 @@ The Graphcast SDK (Software Development Kit) allows developers to build Radios,
 - Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
 - Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
 
-### Learn More
+### Daha Fazla Bilgi Edin
 
 If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)

From 6864027d556c13aac0657ad120d5537c0e1d30f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:44:50 -0500
Subject: [PATCH 2350/3820] New translations graphcast.mdx (Marathi)

---
 website/pages/mr/indexing/tooling/graphcast.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/mr/indexing/tooling/graphcast.mdx b/website/pages/mr/indexing/tooling/graphcast.mdx
index 281104f50781..46e7c77e864d 100644
--- a/website/pages/mr/indexing/tooling/graphcast.mdx
+++ b/website/pages/mr/indexing/tooling/graphcast.mdx
@@ -1,5 +1,5 @@
 ---
-title: Graphcast
+title: ग्राफकास्ट
 ---
 
 ## Introduction
@@ -16,6 +16,6 @@ Is there something you'd like to learn from or share with your fellow Indexers i
 - Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
 - Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
 
-### Learn More
+### अधिक जाणून घ्या
 
 तुम्हाला ग्राफकास्टबद्दल अधिक जाणून घ्यायचे असल्यास, [येथे दस्तऐवजीकरण पहा.](https://docs.graphops.xyz/graphcast/intro)

From dfb9dd4bd509493b5448de727e83f9123e9ea992 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:44:55 -0500
Subject: [PATCH 2351/3820] New translations graphcast.mdx (Hindi)

---
 website/pages/hi/indexing/tooling/graphcast.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/indexing/tooling/graphcast.mdx b/website/pages/hi/indexing/tooling/graphcast.mdx
index beec8cbeeb3f..216fc0a502c5 100644
--- a/website/pages/hi/indexing/tooling/graphcast.mdx
+++ b/website/pages/hi/indexing/tooling/graphcast.mdx
@@ -1,5 +1,5 @@
 ---
-title: ग्राफकास्ट
+title: Graphcast
 ---
 
 ## Introduction

From 9a676cfc7cbd9709b30a491548fabbe3ceb531a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:45:07 -0500
Subject: [PATCH 2352/3820] New translations assemblyscript-migration-guide.mdx
 (Italian)

---
 .../resources/release-notes/assemblyscript-migration-guide.mdx  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/it/resources/release-notes/assemblyscript-migration-guide.mdx
index 5cef32e4a79f..3b4b10c8454e 100644
--- a/website/pages/it/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/it/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -167,7 +167,7 @@ Tuttavia, questo funziona solo in due scenari:
 - Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
 - Upcasting sull'ereditarietà delle classi (subclasse → superclasse)
 
-Examples:
+Esempi:
 
 ```typescript
 // primitive casting

From 06c50c08ced541ad6c2c469c09f3e1da3ad441cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:45:11 -0500
Subject: [PATCH 2353/3820] New translations
 graphql-validations-migration-guide.mdx (German)

---
 .../release-notes/graphql-validations-migration-guide.mdx       | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/de/resources/release-notes/graphql-validations-migration-guide.mdx
index ee37b90c5576..31788f43b53c 100644
--- a/website/pages/de/resources/release-notes/graphql-validations-migration-guide.mdx
+++ b/website/pages/de/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -60,7 +60,7 @@ You can try out queries by sending them to:
 
 - `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
 
-or
+oder
 
 - `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
 

From c8118c0f34a0cb8000e75bc389bb556bc42059e7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:45:31 -0500
Subject: [PATCH 2354/3820] New translations
 graphql-validations-migration-guide.mdx (Italian)

---
 .../release-notes/graphql-validations-migration-guide.mdx       | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/it/resources/release-notes/graphql-validations-migration-guide.mdx
index 6fe94d495069..067bf445e437 100644
--- a/website/pages/it/resources/release-notes/graphql-validations-migration-guide.mdx
+++ b/website/pages/it/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -60,7 +60,7 @@ Forniamo un endpoint `https://api-next.thegraph.com/` che esegue una versione di
 
 - `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
 
-or
+oppure
 
 - `https://api-next.thegraph.com/subgraphs/name/<GITHUB_USER>/<SUBGRAPH_NAME>`
 

From 85a8827b39b07eb93062e6747f77f76367f4d3a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:45:58 -0500
Subject: [PATCH 2355/3820] New translations billing.mdx (French)

---
 website/pages/fr/subgraphs/billing.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/subgraphs/billing.mdx b/website/pages/fr/subgraphs/billing.mdx
index 72324e599899..7e7b53c41d3d 100644
--- a/website/pages/fr/subgraphs/billing.mdx
+++ b/website/pages/fr/subgraphs/billing.mdx
@@ -31,11 +31,11 @@ Les utilisateurs de subgraphs peuvent utiliser le jeton natif de The Graph (GRT)
 
 ### GRT sur Arbitrum ou Ethereum
 
-Le système de facturation de The Graph accepte le GRT sur Arbitrum, et les utilisateurs auront besoin d'ETH sur Arbitrum pour payer leurs frais de gaz. Bien que le protocole The Graph ait commencé sur Ethereum Mainnet, toute l'activité, y compris les contrats de facturation, est maintenant sur Arbitrum One.
+Le système de facturation de The Graph accepte le GRT sur Arbitrum, et les utilisateurs devront disposer d'ETH sur Arbitrum pour payer le gaz. Bien que le protocole The Graph ait commencé sur le réseau principal d'Ethereum, toutes les activités, y compris les contrats de facturation, sont désormais réalisées sur Arbitrum One.
 
 L'utilisation du GRT sur Arbitrum est nécessaire pour le paiement des requêtes. Voici quelques options pour en acquérir :
 
-- Si vous avez déjà des GRT sur Ethereum, vous pouvez les bridge vers Arbitrum. Vous pouvez le faire via l'option de bridge de GRT fournie dans Subgraph Studio ou en utilisant l'un des bridges suivants :
+- Si vous avez déjà des GRT sur Ethereum, vous pouvez les transférer vers Arbitrum. Vous pouvez le faire via l'option de transfert de GRT fournie dans Subgraph Studio ou en utilisant l'un des ponts suivants :
 
 - [Le Bridge Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161)
 

From f7de6e44d32ad20b155eadb404685bd9fbf616b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:46:12 -0500
Subject: [PATCH 2356/3820] New translations billing.mdx (Portuguese)

---
 website/pages/pt/subgraphs/billing.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pt/subgraphs/billing.mdx b/website/pages/pt/subgraphs/billing.mdx
index 996983a535ec..33de71abbce7 100644
--- a/website/pages/pt/subgraphs/billing.mdx
+++ b/website/pages/pt/subgraphs/billing.mdx
@@ -31,11 +31,11 @@ Utilizadores de subgraph podem utilizar o The Graph Token (ou GRT) para pagar po
 
 ### GRT no Arbitrum ou Ethereum
 
-O sistema de cobranças do The Graph aceita GRT no Arbitrum, e utilizadores precisarão de ETH no Arbitrum para pagar pelo seu gas. O protocolo do The Graph começou na Mainnet do Ethereum, mas todas as atividades, que incluem os contratos de cobranças, agora se encontram no Arbitrum One.
+O sistema de cobranças do The Graph aceita GRT no Arbitrum, e os utilizadores precisarão de ETH no Arbitrum para pagar pelo seu gas. Enquanto o protocolo do The Graph começou na Mainnet do Ethereum, todas as atividades, inclusive os contratos de cobranças, agora ficam no Arbitrum One.
 
 Para pagar por queries, é necessário ter GRT no Arbitrum. Veja algumas maneiras diferentes de adquirir o token:
 
-- Caso já tenha GRT no Ethereum, é possível enviá-lo ao Arbitrum via bridge. Isto pode ser feito via a opção de bridging de GRT providenciada no Subgraph Studio ou uma das seguintes bridges:
+- Caso já tenha GRT no Ethereum, é possível enviá-lo ao Arbitrum via bridge. Isto é possível via a opção de bridging de GRT providenciada no Subgraph Studio ou uma das seguintes bridges:
 
 - [Bridge no Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161)
 

From b5af0a2fd570c23b8ad7609327dd0c1cc75e396e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:46:21 -0500
Subject: [PATCH 2357/3820] New translations billing.mdx (Turkish)

---
 website/pages/tr/subgraphs/billing.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/subgraphs/billing.mdx b/website/pages/tr/subgraphs/billing.mdx
index 58920349c6ac..d0a57e07fb37 100644
--- a/website/pages/tr/subgraphs/billing.mdx
+++ b/website/pages/tr/subgraphs/billing.mdx
@@ -31,11 +31,11 @@ Subgraph kullanıcıları, The Graph Ağında sorgular için ödeme yapmak amac
 
 ### Ethereum ya da Arbitrum Ağında GRT
 
-The Graph'in faturalandırma sistemi, Arbitrum ağı üzerinde GRT ile ödeme alır. Kullanıcıların gaz ücretlerini ödemek için Arbitrum üzerinde ETH'ye ihtiyaçları olacaktır. The Graph protokolü, başlangıçta Ethereum Mainnet üzerinde başlatılmış olsa da, faturalandırma sözleşmeleri de dahil olmak üzere tüm faaliyetler artık Arbitrum One üzerinde gerçekleştirilmektedir.
+The Graph'in faturalandırma sistemi, Arbitrum ağı üzerinde GRT ile ödeme alır. Kullanıcıların gas ücretlerini ödemek için Arbitrum üzerinde ETH'ye ihtiyaçları olacaktır. The Graph protokolü, başlangıçta Ethereum Mainnet üzerinde başlatılmış olsa da, faturalandırma sözleşmeleri de dahil olmak üzere tüm faaliyetler artık Arbitrum One üzerinde gerçekleştirilmektedir.
 
 Sorgu ödemelerini yapmak için Arbitrum üzerinde GRT'ye ihtiyacınız var. İşte GRT elde etmenin birkaç farklı yolu:
 
-- Ethereum üzerinde halihazırda GRT'leriniz varsa, bunları Arbitrum'a köprüleyebilirsiniz. Bu işlemi Subgraph Studio'da sunulan GRT köprüleme seçeneği aracılığıyla veya aşağıdaki köprülerden birini kullanarak yapabilirsiniz:
+- Ethereum üzerinde zaten GRT'niz varsa, bunu Arbitrum'a köprüleyebilirsiniz. Bunu, Subgraph Studio'da sunulan GRT köprüleme seçeneği aracılığıyla veya aşağıdaki köprülerden birini kullanarak yapabilirsiniz:
 
 - [Arbitrum Köprüsü](https://bridge.arbitrum.io/?l2ChainId=42161)
 

From d4018109c0dc0021eeb2f84612bd29f06b45294d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:46:44 -0500
Subject: [PATCH 2358/3820] New translations arweave.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/cookbook/arweave.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/subgraphs/cookbook/arweave.mdx b/website/pages/uk/subgraphs/cookbook/arweave.mdx
index 6b54757440a0..b411f0324b8a 100644
--- a/website/pages/uk/subgraphs/cookbook/arweave.mdx
+++ b/website/pages/uk/subgraphs/cookbook/arweave.mdx
@@ -168,7 +168,7 @@ Here is an example subgraph for reference:
 
 - [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
 
-## FAQ
+## Поширені запитання
 
 ### Can a subgraph index Arweave and other chains?
 

From d0deb10bd6a667860981bae04bafdb7c36dab429 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:46:45 -0500
Subject: [PATCH 2359/3820] New translations arweave.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/cookbook/arweave.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/subgraphs/cookbook/arweave.mdx b/website/pages/ur/subgraphs/cookbook/arweave.mdx
index 035056b7f5a6..4173741429d0 100644
--- a/website/pages/ur/subgraphs/cookbook/arweave.mdx
+++ b/website/pages/ur/subgraphs/cookbook/arweave.mdx
@@ -168,7 +168,7 @@ The GraphQL endpoint for Arweave subgraphs is determined by the schema definitio
 
 - [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
 
-## FAQ
+## عمومی سوالات
 
 ### کیا ایک سب گراف آرویو اور دیگر چینس کو انڈیکس کر سکتا ہے؟
 

From 3a20ce80e3c57f684a56234eadc95b18d4aa298e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:46:51 -0500
Subject: [PATCH 2360/3820] New translations billing.mdx (Hindi)

---
 website/pages/hi/subgraphs/billing.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/subgraphs/billing.mdx b/website/pages/hi/subgraphs/billing.mdx
index aa6549e7164d..68a46a48cbbc 100644
--- a/website/pages/hi/subgraphs/billing.mdx
+++ b/website/pages/hi/subgraphs/billing.mdx
@@ -31,11 +31,11 @@ Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph
 
 ### GRT on Arbitrum or Ethereum
 
-The Graph का बिलिंग सिस्टम Arbitrum पर GRT स्वीकार करता है, और उपयोगकर्ताओं को गैस के लिए Arbitrum पर ETHकी आवश्यकता होगी। जबकि The Graph प्रोटोकॉल Ethereum Mainnet पर शुरू हुआ था, अब सभी गतिविधियाँ, जिसमें बिलिंग कॉन्ट्रैक्ट्स शामिल हैं, Arbitrum One पर हैं।
+The Graph का बिलिंग सिस्टम Arbitrum पर GRT को स्वीकार करता है, और उपयोगकर्ताओं को गैस के भुगतान के लिए Arbitrum  पर ETH की आवश्यकता होगी। जबकि The Graph प्रोटोकॉल Ethereum Mainnet पर शुरू हुआ, सभी गतिविधियाँ, जिसमें बिलिंग कॉन्ट्रैक्ट्स भी शामिल हैं, अब Arbitrum One पर हैं।
 
 क्वेरियों के लिए भुगतान करने के लिए, आपको Arbitrum पर GRT की आवश्यकता है। इसे प्राप्त करने के लिए कुछ विभिन्न तरीके यहां दिए गए हैं:
 
-- यदि आपके पास पहले से Ethereum पर GRT है, तो आप इसे Arbitrum पर ब्रिज कर सकते हैं। आप इसे Subgraph Studio में उपलब्ध GRT ब्रिजिंग विकल्प के माध्यम से या निम्नलिखित में से किसी एक ब्रिज का उपयोग करके कर सकते हैं:
+- यदि आपके पास पहले से  Ethereum पर GRT है, तो आप इसे Arbitrum पर ब्रिज कर सकते हैं। आप यह Subgraph Studio में प्रदान किए गए GRT ब्रिजिंग विकल्प के माध्यम से या निम्नलिखित में से किसी एक ब्रिज का उपयोग करके कर सकते हैं:
 
 - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
 

From 20d87a97de849e4231a1e406974add37c189f6a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:46:52 -0500
Subject: [PATCH 2361/3820] New translations arweave.mdx (Hindi)

---
 website/pages/hi/subgraphs/cookbook/arweave.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/cookbook/arweave.mdx b/website/pages/hi/subgraphs/cookbook/arweave.mdx
index 2d0d6442ef88..b51d9a5405bc 100644
--- a/website/pages/hi/subgraphs/cookbook/arweave.mdx
+++ b/website/pages/hi/subgraphs/cookbook/arweave.mdx
@@ -168,7 +168,7 @@ The GraphQL endpoint for Arweave subgraphs is determined by the schema definitio
 
 - [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
 
-## सामान्य प्रश्न
+## FAQ
 
 ### क्या एक सब-ग्राफ आरवीव और बाकी चेन्स को इंडेक्स कर सकता है?
 

From f1027083653346c0c4dc8b0a03e95551e4a04acd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:48:09 -0500
Subject: [PATCH 2362/3820] New translations near.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/subgraphs/cookbook/near.mdx b/website/pages/uk/subgraphs/cookbook/near.mdx
index a94bd9531fdb..a5b626a4fdbb 100644
--- a/website/pages/uk/subgraphs/cookbook/near.mdx
+++ b/website/pages/uk/subgraphs/cookbook/near.mdx
@@ -238,7 +238,7 @@ Here are some example subgraphs for reference:
 
 [NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
 
-## FAQ
+## Поширені запитання
 
 ### How does the beta work?
 

From 6e1350c26260f42e630564d4bd0bd0df89639375 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:48:11 -0500
Subject: [PATCH 2363/3820] New translations near.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/subgraphs/cookbook/near.mdx b/website/pages/ur/subgraphs/cookbook/near.mdx
index 3ff637ebf556..744e04bc4a81 100644
--- a/website/pages/ur/subgraphs/cookbook/near.mdx
+++ b/website/pages/ur/subgraphs/cookbook/near.mdx
@@ -238,7 +238,7 @@ Here are some example subgraphs for reference:
 
 [NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
 
-## FAQ
+## عمومی سوالات
 
 ### بیٹا کیسے کام کرتا ہے؟
 

From e37957ce52131025cabfa92bdefa98c9998d3280 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:48:23 -0500
Subject: [PATCH 2364/3820] New translations secure-api-keys-nextjs.mdx
 (Italian)

---
 website/pages/it/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/it/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index fba106e6eaf6..6c843497344c 100644
--- a/website/pages/it/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/it/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -22,7 +22,7 @@ In a standard React application, API keys included in the frontend code can be e
 
 ![Client-side rendering](/img/api-key-client-side-rendering.png)
 
-### Prerequisites
+### Prerequisiti
 
 - An API key from [Subgraph Studio](https://thegraph.com/studio)
 - Basic knowledge of Next.js and React.

From e468490fe321870149038000b333ba23671ef36e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:48:29 -0500
Subject: [PATCH 2365/3820] New translations secure-api-keys-nextjs.mdx (Dutch)

---
 website/pages/nl/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/nl/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index fc7e0ff52eb4..b7496835e1fb 100644
--- a/website/pages/nl/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/nl/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -22,7 +22,7 @@ In a standard React application, API keys included in the frontend code can be e
 
 ![Client-side rendering](/img/api-key-client-side-rendering.png)
 
-### Prerequisites
+### Vereisten
 
 - An API key from [Subgraph Studio](https://thegraph.com/studio)
 - Basic knowledge of Next.js and React.

From 4a406d66026aeaff2ff79257c7fb5233849a3eb3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:48:36 -0500
Subject: [PATCH 2366/3820] New translations secure-api-keys-nextjs.mdx
 (Ukrainian)

---
 website/pages/uk/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/uk/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index fc7e0ff52eb4..cbff7fc8d274 100644
--- a/website/pages/uk/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/uk/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -22,7 +22,7 @@ In a standard React application, API keys included in the frontend code can be e
 
 ![Client-side rendering](/img/api-key-client-side-rendering.png)
 
-### Prerequisites
+### Передумови
 
 - An API key from [Subgraph Studio](https://thegraph.com/studio)
 - Basic knowledge of Next.js and React.

From 3bfff379acc273d16d2d6d4d29d5771b6594324d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:48:37 -0500
Subject: [PATCH 2367/3820] New translations secure-api-keys-nextjs.mdx (Urdu
 (Pakistan))

---
 website/pages/ur/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/ur/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index d278d72cd06b..acaee6c34de9 100644
--- a/website/pages/ur/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/ur/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -22,7 +22,7 @@ In a standard React application, API keys included in the frontend code can be e
 
 ![Client-side rendering](/img/api-key-client-side-rendering.png)
 
-### شرطیں
+### اولین ضروریات
 
 - An API key from [Subgraph Studio](https://thegraph.com/studio)
 - Basic knowledge of Next.js and React.

From 736c3e1be7a7b587db79c9bfdcc3dfcd119dfffb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:48:39 -0500
Subject: [PATCH 2368/3820] New translations near.mdx (Hindi)

---
 website/pages/hi/subgraphs/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/cookbook/near.mdx b/website/pages/hi/subgraphs/cookbook/near.mdx
index e1312d32879d..6aab3eeedbb4 100644
--- a/website/pages/hi/subgraphs/cookbook/near.mdx
+++ b/website/pages/hi/subgraphs/cookbook/near.mdx
@@ -238,7 +238,7 @@ Here are some example subgraphs for reference:
 
 [NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
 
-## सामान्य प्रश्न
+## FAQ
 
 ### बीटा कैसे काम करता है?
 

From d871a5f1d01fae0799b273a8236f944cdd57995b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:49:36 -0500
Subject: [PATCH 2369/3820] New translations install-the-cli.mdx (French)

---
 .../pages/fr/subgraphs/developing/creating/install-the-cli.mdx  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx
index 900b8d9e8f7d..7f8b17eaceb3 100644
--- a/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx
@@ -8,7 +8,7 @@ title: Installation du Graph CLI
 
 The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
 
-## Démarrage
+## Introduction
 
 ### Installation du Graph CLI
 

From cc36a21362f56d6f56392c8fd2f1a680c8f7eb37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:49:42 -0500
Subject: [PATCH 2370/3820] New translations install-the-cli.mdx (Italian)

---
 .../pages/it/subgraphs/developing/creating/install-the-cli.mdx  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/it/subgraphs/developing/creating/install-the-cli.mdx
index 9b601cf35472..6a15118ec854 100644
--- a/website/pages/it/subgraphs/developing/creating/install-the-cli.mdx
+++ b/website/pages/it/subgraphs/developing/creating/install-the-cli.mdx
@@ -8,7 +8,7 @@ title: Installare the Graph CLI
 
 The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
 
-## Getting Started
+## Per cominciare
 
 ### Installare the Graph CLI
 

From b1a0170f40e841e04fda15c3e1777186624603de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:50:31 -0500
Subject: [PATCH 2371/3820] New translations using-subgraph-studio.mdx (French)

---
 .../fr/subgraphs/developing/deploying/using-subgraph-studio.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx
index 93e302e70554..65d07476f124 100644
--- a/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx
+++ b/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -63,7 +63,7 @@ Pour être pris en charge par les Indexeurs sur The Graph Network, les subgraphs
 - Ne doit utiliser aucune des fonctionnalités suivantes :
   - ipfs.cat & ipfs.map
   - Erreurs non fatales
-  - Greffage
+  - Grafting
 
 ## Initialisez votre Subgraph
 

From 356daded6c9bdf1f66fe300ff3e753c2d091cead Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:50:47 -0500
Subject: [PATCH 2372/3820] New translations using-subgraph-studio.mdx
 (Portuguese)

---
 .../pt/subgraphs/developing/deploying/using-subgraph-studio.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/pt/subgraphs/developing/deploying/using-subgraph-studio.mdx
index 43b2acf07791..f0efcd77c78c 100644
--- a/website/pages/pt/subgraphs/developing/deploying/using-subgraph-studio.mdx
+++ b/website/pages/pt/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -63,7 +63,7 @@ Para ter apoio de Indexadores na Graph Network, os subgraphs devem:
 - Não deve usar quaisquer das seguintes características:
   - ipfs.cat & ipfs.map
   - Erros não-fatais
-  - Enxertos
+  - Enxerto
 
 ## Initialize Your Subgraph
 

From abb80fe06296afa73f77264f1750eed60e5c8d57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:51:24 -0500
Subject: [PATCH 2373/3820] New translations subgraphs.mdx (Romanian)

---
 website/pages/ro/subgraphs/developing/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/subgraphs/developing/subgraphs.mdx b/website/pages/ro/subgraphs/developing/subgraphs.mdx
index 951ec74234d1..ff37e00042e6 100644
--- a/website/pages/ro/subgraphs/developing/subgraphs.mdx
+++ b/website/pages/ro/subgraphs/developing/subgraphs.mdx
@@ -1,5 +1,5 @@
 ---
-title: Subgraphs
+title: Subgrafuri
 ---
 
 ## What is a Subgraph?

From 75a90db2dd24216fd9525084ca3c9bb34cb5c2bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:51:51 -0500
Subject: [PATCH 2374/3820] New translations explorer.mdx (Romanian)

---
 website/pages/ro/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/subgraphs/explorer.mdx b/website/pages/ro/subgraphs/explorer.mdx
index 433821560d85..7e1bac046e02 100644
--- a/website/pages/ro/subgraphs/explorer.mdx
+++ b/website/pages/ro/subgraphs/explorer.mdx
@@ -12,7 +12,7 @@ For a general overview of Graph Explorer, check out the video below:
 
 <VideoEmbed youtube="u224xf7rEBY" />
 
-## Subgraphs
+## Subgrafuri
 
 After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
 

From dc00630093a8b48bfd942b679ac558030cf2886c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:51:56 -0500
Subject: [PATCH 2375/3820] New translations subgraphs.mdx (Italian)

---
 website/pages/it/subgraphs/developing/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/subgraphs/developing/subgraphs.mdx b/website/pages/it/subgraphs/developing/subgraphs.mdx
index 80352fc29ed5..a5d5fa16fd8e 100644
--- a/website/pages/it/subgraphs/developing/subgraphs.mdx
+++ b/website/pages/it/subgraphs/developing/subgraphs.mdx
@@ -1,5 +1,5 @@
 ---
-title: Subgraph
+title: Subgraphs
 ---
 
 ## What is a Subgraph?

From 3e659d0ad24d830f641f3deb5d427c42638c705f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:52:00 -0500
Subject: [PATCH 2376/3820] New translations explorer.mdx (Italian)

---
 website/pages/it/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/subgraphs/explorer.mdx b/website/pages/it/subgraphs/explorer.mdx
index 71e18f6737c0..7bbd7782278f 100644
--- a/website/pages/it/subgraphs/explorer.mdx
+++ b/website/pages/it/subgraphs/explorer.mdx
@@ -12,7 +12,7 @@ For a general overview of Graph Explorer, check out the video below:
 
 <VideoEmbed youtube="u224xf7rEBY" />
 
-## Subgraph
+## Subgraphs
 
 After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
 

From fd292e8a043bcf18065912d5c2787709827426bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:52:07 -0500
Subject: [PATCH 2377/3820] New translations subgraphs.mdx (Russian)

---
 website/pages/ru/subgraphs/developing/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/developing/subgraphs.mdx b/website/pages/ru/subgraphs/developing/subgraphs.mdx
index 0b72ece0f8ec..c998d7b4b13d 100644
--- a/website/pages/ru/subgraphs/developing/subgraphs.mdx
+++ b/website/pages/ru/subgraphs/developing/subgraphs.mdx
@@ -1,5 +1,5 @@
 ---
-title: Субграфы
+title: Подграфы
 ---
 
 ## What is a Subgraph?

From 602f0df41f665000ef0f51c5a123bcdb8f2eda8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:52:11 -0500
Subject: [PATCH 2378/3820] New translations explorer.mdx (Russian)

---
 website/pages/ru/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/explorer.mdx b/website/pages/ru/subgraphs/explorer.mdx
index 5a42b6201dce..66408d6f8c27 100644
--- a/website/pages/ru/subgraphs/explorer.mdx
+++ b/website/pages/ru/subgraphs/explorer.mdx
@@ -12,7 +12,7 @@ For a general overview of Graph Explorer, check out the video below:
 
 <VideoEmbed youtube="u224xf7rEBY" />
 
-## Субграфы
+## Подграфы
 
 After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
 

From 3fb4c111e87756c3f0a5988ab34c5b0037318fc7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:52:12 -0500
Subject: [PATCH 2379/3820] New translations subgraphs.mdx (Swedish)

---
 website/pages/sv/subgraphs/developing/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/subgraphs/developing/subgraphs.mdx b/website/pages/sv/subgraphs/developing/subgraphs.mdx
index 33fc3b2aeb08..a6fa5ca3a4f6 100644
--- a/website/pages/sv/subgraphs/developing/subgraphs.mdx
+++ b/website/pages/sv/subgraphs/developing/subgraphs.mdx
@@ -1,5 +1,5 @@
 ---
-title: Subgraffar
+title: Subgrafer
 ---
 
 ## What is a Subgraph?

From 7d0c7d587dd0a5f0ba3cf40ec1f797e3288dd9ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:52:15 -0500
Subject: [PATCH 2380/3820] New translations explorer.mdx (Swedish)

---
 website/pages/sv/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/subgraphs/explorer.mdx b/website/pages/sv/subgraphs/explorer.mdx
index dece06cd1472..f0d804ed354a 100644
--- a/website/pages/sv/subgraphs/explorer.mdx
+++ b/website/pages/sv/subgraphs/explorer.mdx
@@ -12,7 +12,7 @@ For a general overview of Graph Explorer, check out the video below:
 
 <VideoEmbed youtube="u224xf7rEBY" />
 
-## Subgraffar
+## Subgrafer
 
 After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
 

From 7f63bafa1481ea3ad87f54873f707a96ca7bfb06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:52:19 -0500
Subject: [PATCH 2381/3820] New translations subgraphs.mdx (Marathi)

---
 website/pages/mr/subgraphs/developing/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/subgraphs/developing/subgraphs.mdx b/website/pages/mr/subgraphs/developing/subgraphs.mdx
index 5b18ec8cf748..737fb1347ada 100644
--- a/website/pages/mr/subgraphs/developing/subgraphs.mdx
+++ b/website/pages/mr/subgraphs/developing/subgraphs.mdx
@@ -1,5 +1,5 @@
 ---
-title: Subgraphs
+title: सबग्राफ
 ---
 
 ## What is a Subgraph?

From 63c8a85fa091933e4c2ca2728333bb1e2795785a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:52:20 -0500
Subject: [PATCH 2382/3820] New translations subgraphs.mdx (Hindi)

---
 website/pages/hi/subgraphs/developing/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/developing/subgraphs.mdx b/website/pages/hi/subgraphs/developing/subgraphs.mdx
index 153754823989..88938cf949f2 100644
--- a/website/pages/hi/subgraphs/developing/subgraphs.mdx
+++ b/website/pages/hi/subgraphs/developing/subgraphs.mdx
@@ -1,5 +1,5 @@
 ---
-title: सबग्राफ
+title: Subgraphs
 ---
 
 ## Subgraph क्या है?

From 952de5e71800237cf565bbde38a149412ac5f462 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:52:22 -0500
Subject: [PATCH 2383/3820] New translations explorer.mdx (Marathi)

---
 website/pages/mr/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/subgraphs/explorer.mdx b/website/pages/mr/subgraphs/explorer.mdx
index 2441a410b179..2d931c2b43cb 100644
--- a/website/pages/mr/subgraphs/explorer.mdx
+++ b/website/pages/mr/subgraphs/explorer.mdx
@@ -12,7 +12,7 @@ For a general overview of Graph Explorer, check out the video below:
 
 <VideoEmbed youtube="u224xf7rEBY" />
 
-## Subgraphs
+## सबग्राफ
 
 After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
 

From 1c40c5444510f035422bbba4c97b981ecc0a2961 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:52:23 -0500
Subject: [PATCH 2384/3820] New translations explorer.mdx (Hindi)

---
 website/pages/hi/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/explorer.mdx b/website/pages/hi/subgraphs/explorer.mdx
index 76bf5d58cf7a..d16a6359625c 100644
--- a/website/pages/hi/subgraphs/explorer.mdx
+++ b/website/pages/hi/subgraphs/explorer.mdx
@@ -12,7 +12,7 @@ Graph Explorer का सामान्य अवलोकन करने क
 
 <VideoEmbed youtube="u224xf7rEBY" />
 
-## सबग्राफ
+## Subgraphs
 
 जैसे ही आप Subgraph Studio में अपना subgraph डिप्लॉय और पब्लिश कर लें, नेविगेशन बार के शीर्ष पर स्थित "subgraphs tab” पर क्लिक करें ताकि आप निम्नलिखित तक पहुंच सकें:
 

From 85084b7d0640d02011ca6a4dd8edd8cb2db017c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:53:19 -0500
Subject: [PATCH 2385/3820] New translations introduction.mdx (French)

---
 website/pages/fr/substreams/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/substreams/introduction.mdx b/website/pages/fr/substreams/introduction.mdx
index 7ebdc90df818..975805709e67 100644
--- a/website/pages/fr/substreams/introduction.mdx
+++ b/website/pages/fr/substreams/introduction.mdx
@@ -38,7 +38,7 @@ The official Substreams documentation is currently maintained by the StreamingFa
 
 To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
 
-### Démarrage
+### Introduction
 
 - In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
 - Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).

From 2df5e6b86650b120a97de024d5a712b969e993d9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:53:25 -0500
Subject: [PATCH 2386/3820] New translations quick-start.mdx (Italian)

---
 website/pages/it/subgraphs/quick-start.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/subgraphs/quick-start.mdx b/website/pages/it/subgraphs/quick-start.mdx
index 13af8f0deb42..5116a02ab024 100644
--- a/website/pages/it/subgraphs/quick-start.mdx
+++ b/website/pages/it/subgraphs/quick-start.mdx
@@ -4,7 +4,7 @@ title: Quick Start
 
 Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
 
-## Prerequisites
+## Prerequisiti
 
 - A crypto wallet
 - A smart contract address on a [supported network](/supported-networks/)

From 9daffb4e8122c2f4408f0ca213a120bce2b04d79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:53:31 -0500
Subject: [PATCH 2387/3820] New translations quick-start.mdx (Dutch)

---
 website/pages/nl/subgraphs/quick-start.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/subgraphs/quick-start.mdx b/website/pages/nl/subgraphs/quick-start.mdx
index d18b354df77c..6e2435436593 100644
--- a/website/pages/nl/subgraphs/quick-start.mdx
+++ b/website/pages/nl/subgraphs/quick-start.mdx
@@ -4,7 +4,7 @@ title: Snelle Start
 
 Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
 
-## Prerequisites
+## Vereisten
 
 - A crypto wallet
 - A smart contract address on a [supported network](/supported-networks/)

From 18911ddb49e133b7927bd0054e7c046980373a55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:53:37 -0500
Subject: [PATCH 2388/3820] New translations quick-start.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/quick-start.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/subgraphs/quick-start.mdx b/website/pages/uk/subgraphs/quick-start.mdx
index f97d3c023d90..e4e7de66f246 100644
--- a/website/pages/uk/subgraphs/quick-start.mdx
+++ b/website/pages/uk/subgraphs/quick-start.mdx
@@ -4,7 +4,7 @@ title: Швидкий старт
 
 Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
 
-## Prerequisites
+## Передумови
 
 - Криптогаманець
 - A smart contract address on a [supported network](/supported-networks/)

From 7d7b0c617b4f67703b6dfbf11aed632ac82104f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:53:39 -0500
Subject: [PATCH 2389/3820] New translations quick-start.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/quick-start.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/subgraphs/quick-start.mdx b/website/pages/ur/subgraphs/quick-start.mdx
index 5998de2fad57..5f1ebfb4a686 100644
--- a/website/pages/ur/subgraphs/quick-start.mdx
+++ b/website/pages/ur/subgraphs/quick-start.mdx
@@ -4,7 +4,7 @@ title: فورا شروع کریں
 
 Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
 
-## شرطیں
+## اولین ضروریات
 
 - ایک کرپٹو والیٹ
 - A smart contract address on a [supported network](/supported-networks/)

From 451bb8df55945ec5e87e936392a9f775c84ce5a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:53:47 -0500
Subject: [PATCH 2390/3820] New translations introduction.mdx (Italian)

---
 website/pages/it/substreams/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/substreams/introduction.mdx b/website/pages/it/substreams/introduction.mdx
index 4fd0efb697aa..52e584dc7947 100644
--- a/website/pages/it/substreams/introduction.mdx
+++ b/website/pages/it/substreams/introduction.mdx
@@ -38,7 +38,7 @@ The official Substreams documentation is currently maintained by the StreamingFa
 
 To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
 
-### Getting Started
+### Per cominciare
 
 - In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
 - Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).

From 33dcccd90f940deeae12609b82e81e21f6800979 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:54:14 -0500
Subject: [PATCH 2391/3820] New translations tutorial.mdx (Italian)

---
 website/pages/it/substreams/sps/tutorial.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/substreams/sps/tutorial.mdx b/website/pages/it/substreams/sps/tutorial.mdx
index 495298871a22..c7dd586b1e5a 100644
--- a/website/pages/it/substreams/sps/tutorial.mdx
+++ b/website/pages/it/substreams/sps/tutorial.mdx
@@ -2,7 +2,7 @@
 title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
-## Prerequisites
+## Prerequisiti
 
 Before starting, make sure to:
 

From 1847a526be2f3f1d5ed93295d761d94115de70de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:54:21 -0500
Subject: [PATCH 2392/3820] New translations tutorial.mdx (Dutch)

---
 website/pages/nl/substreams/sps/tutorial.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/substreams/sps/tutorial.mdx b/website/pages/nl/substreams/sps/tutorial.mdx
index 495298871a22..d0850fda915c 100644
--- a/website/pages/nl/substreams/sps/tutorial.mdx
+++ b/website/pages/nl/substreams/sps/tutorial.mdx
@@ -2,7 +2,7 @@
 title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
-## Prerequisites
+## Vereisten
 
 Before starting, make sure to:
 

From ef26f8416054667013b3a5cbc2cc9c39903a913a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:54:30 -0500
Subject: [PATCH 2393/3820] New translations tutorial.mdx (Ukrainian)

---
 website/pages/uk/substreams/sps/tutorial.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/substreams/sps/tutorial.mdx b/website/pages/uk/substreams/sps/tutorial.mdx
index 495298871a22..f0de7a0c9528 100644
--- a/website/pages/uk/substreams/sps/tutorial.mdx
+++ b/website/pages/uk/substreams/sps/tutorial.mdx
@@ -2,7 +2,7 @@
 title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
-## Prerequisites
+## Передумови
 
 Before starting, make sure to:
 

From 11b6b0969298d85b59560699050f75d2d3d5841a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 23 Dec 2024 15:54:31 -0500
Subject: [PATCH 2394/3820] New translations tutorial.mdx (Urdu (Pakistan))

---
 website/pages/ur/substreams/sps/tutorial.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/substreams/sps/tutorial.mdx b/website/pages/ur/substreams/sps/tutorial.mdx
index 604c864981b7..97d707d4c631 100644
--- a/website/pages/ur/substreams/sps/tutorial.mdx
+++ b/website/pages/ur/substreams/sps/tutorial.mdx
@@ -2,7 +2,7 @@
 title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
-## شرطیں
+## اولین ضروریات
 
 Before starting, make sure to:
 

From bda1b846f38262a668e989879c5aa322a8fdfe6e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 24 Dec 2024 07:58:20 -0500
Subject: [PATCH 2395/3820] New translations avoid-eth-calls.mdx (French)

---
 website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx
index 598d82680af5..95e3845bd852 100644
--- a/website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx
+++ b/website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -18,7 +18,7 @@ Les `eth_calls` sont souvent nécessaires lorsque les données requises pour un
 event Transfer(address indexed from, address indexed to, uint256 value);
 ```
 
-Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+Supposons que l'appartenance au pool des tokens soit déterminée par une variable d'état nommée `getPoolInfo`. Dans ce cas, nous devrions utiliser un `eth_call` pour interroger ces données :
 
 ```typescript
 import { Address } from '@graphprotocol/graph-ts'
@@ -28,10 +28,10 @@ import { TokenTransaction } from '../generated/schema'
 export function handleTransfer(event: Transfer): void {
   let transaction = new TokenTransaction(event.transaction.hash.toHex())
 
-  // Bind the ERC20 contract instance to the given address:
+  // Liez l'instance du contrat ERC20 à l'adresse donnée:
   let instance = ERC20.bind(event.address)
 
-  // Retrieve pool information via eth_call
+  // Récupérez les informations du pool via eth_call
   let poolInfo = instance.getPoolInfo(event.params.to)
 
   transaction.pool = poolInfo.toHexString()

From fb35e098c9f9077e5476c2a7881a97880f04a923 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 24 Dec 2024 09:19:49 -0500
Subject: [PATCH 2396/3820] New translations avoid-eth-calls.mdx (French)

---
 .../fr/subgraphs/cookbook/avoid-eth-calls.mdx    | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx
index 95e3845bd852..b9d94fc64566 100644
--- a/website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx
+++ b/website/pages/fr/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -43,17 +43,17 @@ export function handleTransfer(event: Transfer): void {
 }
 ```
 
-This is functional, however is not ideal as it slows down our subgraph’s indexing.
+Cela fonctionne, mais ce n'est pas idéal car cela ralentit l'indexation de notre subgraph.
 
-## How to Eliminate `eth_calls`
+## Comment Éliminer les `eth_calls`
 
-Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+Idéalement, le smart contract devrait être mis à jour pour émettre toutes les données nécessaires dans les événements. Par exemple, modifier le smart contract pour inclure les informations du pool dans l'événement pourrait éliminer le besoin de `eth_calls`:
 
 ```
 event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
 ```
 
-With this update, the subgraph can directly index the required data without external calls:
+Avec cette mise à jour, le subgraph peut indexer directement les données requises sans appels externes :
 
 ```typescript
 import { Address } from '@graphprotocol/graph-ts'
@@ -80,7 +80,7 @@ Si la modification du smart contract n'est pas possible et que les `eth_calls` s
 
 ## Réduire le Surcharge d'Exécution des `eth_calls`
 
-For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+Pour les `eth_calls` qui ne peuvent pas être éliminés, la surcharge d'exécution qu'ils introduisent peut être minimisée en les déclarant dans le manifeste. Lorsque `graph-node` traite un bloc, il exécute tous les `eth_calls` déclarés en parallèle avant que les gestionnaires (handlers) soient exécutés. Les appels qui ne sont pas déclarés sont exécutés séquentiellement lorsque les gestionnaires sont exécutés. L'amélioration de la durée d'exécution vient du fait que les appels sont effectués en parallèle plutôt que séquentiellement - cela aide à réduire le temps total passé en appels mais ne l'élimine pas complètement.
 
 Actuellement, les `eth_calls` ne peuvent être déclarés que pour les gestionnaires d'événements. Dans le manifeste, écrivez
 
@@ -91,11 +91,11 @@ calls:
   ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
 ```
 
-The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+La partie mise en évidence en jaune est la déclaration d'appel. La partie avant le deux-points est simplement une étiquette de texte utilisée uniquement pour les messages d'erreur. La partie après le deux-points a la forme `Contract[address].function(params)`. Les valeurs permises pour l'adresse et les paramètres sont `event.address` et `event.params.<name>`.
 
-The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+Le handler lui-même accède au résultat de ce `eth_call` exactement comme dans la section précédente en se liant au contrat et en effectuant l'appel. graph-node met en cache les résultats des `eth_calls` déclarés en mémoire et l'appel depuis le handler récupérera le résultat depuis ce cache en mémoire au lieu d'effectuer un appel RPC réel.
 
-Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+Note : Les eth_calls déclarés ne peuvent être effectués que dans les subgraphs avec specVersion >= 1.2.0.
 
 ## Conclusion
 

From b41a13dbf134872d3ef3659d664bf63db75e2499 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 24 Dec 2024 09:19:50 -0500
Subject: [PATCH 2397/3820] New translations derivedfrom.mdx (French)

---
 website/pages/fr/subgraphs/cookbook/derivedfrom.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx b/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx
index 22845a8d7dd2..0607a643bb37 100644
--- a/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx
@@ -4,21 +4,21 @@ title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By U
 
 ## TLDR
 
-Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+Les tableaux dans votre schéma peuvent vraiment ralentir les performances d'un subgraph lorsqu'ils dépassent des milliers d'entrées. Si possible, la directive `@derivedFrom` devrait être utilisée lors de l'utilisation des tableaux car elle empêche la formation de grands tableaux, simplifie les gestionnaires et réduit la taille des entités individuelles, améliorant considérablement la vitesse d'indexation et la performance des requêtes.
 
-## How to Use the `@derivedFrom` Directive
+## Comment Utiliser la Directive `@derivedFrom`
 
-You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+Il vous suffit d'ajouter une directive `@derivedFrom` après votre tableau dans votre schéma. Comme ceci :
 
 ```graphql
 comments: [Comment!]! @derivedFrom(field: "post")
 ```
 
-`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+`@derivedFrom` crée des relations efficaces de un à plusieurs, permettant à une entité de s'associer dynamiquement à plusieurs entités liées en fonction d'un champ dans l'entité liée. Cette approche élimine la nécessité pour les deux côtés de la relation de stocker des données dupliquées, rendant le subgraph plus efficace.
 
-### Example Use Case for `@derivedFrom`
+### Exemple de cas d'utilisation de `@derivedFrom`
 
-An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+Un exemple de tableau à croissance dynamique est une plateforme de blogs où un "Post" peut avoir de nombreux "Commentaires".
 
 Let’s start with our two entities, `Post` and `Comment`
 

From 5253030886dabbde063f27b96559a0f66066eb0b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 24 Dec 2024 10:37:04 -0500
Subject: [PATCH 2398/3820] New translations derivedfrom.mdx (French)

---
 .../fr/subgraphs/cookbook/derivedfrom.mdx      | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx b/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx
index 0607a643bb37..f2be322a704b 100644
--- a/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx
@@ -18,11 +18,11 @@ comments: [Comment!]! @derivedFrom(field: "post")
 
 ### Exemple de cas d'utilisation de `@derivedFrom`
 
-Un exemple de tableau à croissance dynamique est une plateforme de blogs où un "Post" peut avoir de nombreux "Commentaires".
+Un exemple de tableau à croissance dynamique est une plateforme de blogs où un "Post" peut avoir de nombreux "Comments"(Commentaires).
 
-Let’s start with our two entities, `Post` and `Comment`
+Commençons avec nos deux entités, `Post` et `Comment`
 
-Without optimization, you could implement it like this with an array:
+Sans optimisation, vous pourriez implémenter cela avec un tableau :
 
 ```graphql
 type Post @entity {
@@ -38,9 +38,9 @@ type Comment @entity {
 }
 ```
 
-Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+Les tableaux comme ceux-ci stockeront effectivement des données supplémentaires de Comments du côté Post de la relation.
 
-Here’s what an optimized version looks like using `@derivedFrom`:
+Voici à quoi ressemble une version optimisée utilisant `@derivedFrom`:
 
 ```graphql
 type Post @entity {
@@ -57,13 +57,13 @@ type Comment @entity {
 }
 ```
 
-Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+En ajoutant simplement la directive `@derivedFrom`, ce schéma ne stockera les "Comments" que du côté "Comments" de la relation et non du côté "Post" de la relation. Les tableaux sont stockés sur des lignes individuelles, ce qui leur permet de s'étendre de manière significative. Cela peut entraîner des tailles particulièrement grandes si leur croissance est illimitée.
 
-This will not only make our subgraph more efficient, but it will also unlock three features:
+Cela rendra non seulement notre subgraph plus efficace, mais débloquera également trois fonctionnalités :
 
-1. We can query the `Post` and see all of its comments.
+1. Nous pouvons interroger le `Post` et voir tous ses commentaires.
 
-2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+2. Nous pouvons faire une recherche inverse et interroger n'importe quel Commentaire et voir de quel post il provient.
 
 3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
 

From 1079ad85fa03e538cb7507946fcba84064115c8f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 25 Dec 2024 20:37:21 -0500
Subject: [PATCH 2399/3820] New translations enums.mdx (French)

---
 website/pages/fr/subgraphs/cookbook/enums.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/cookbook/enums.mdx b/website/pages/fr/subgraphs/cookbook/enums.mdx
index 581ebd57e7cd..a9529120096b 100644
--- a/website/pages/fr/subgraphs/cookbook/enums.mdx
+++ b/website/pages/fr/subgraphs/cookbook/enums.mdx
@@ -1,5 +1,5 @@
 ---
-title: Categorize NFT Marketplaces Using Enums
+title: Catégoriser les Marchés NFT à l’aide d’Enums
 ---
 
 Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.

From 65f20a1b91c3ef2c7806789a2e7c86b1d21f5440 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 26 Dec 2024 06:55:45 -0500
Subject: [PATCH 2400/3820] New translations enums.mdx (French)

---
 website/pages/fr/subgraphs/cookbook/enums.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/cookbook/enums.mdx b/website/pages/fr/subgraphs/cookbook/enums.mdx
index a9529120096b..790f4844bed2 100644
--- a/website/pages/fr/subgraphs/cookbook/enums.mdx
+++ b/website/pages/fr/subgraphs/cookbook/enums.mdx
@@ -1,5 +1,5 @@
 ---
-title: Catégoriser les Marchés NFT à l’aide d’Enums
+title: Catégoriser les marketplaces NFT à l’aide d’Enums
 ---
 
 Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.

From 43b291ab7ffac9cd36394b24aab7f248d3829e17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 26 Dec 2024 08:00:59 -0500
Subject: [PATCH 2401/3820] New translations unit-testing-framework.mdx
 (French)

---
 .../fr/subgraphs/developing/creating/unit-testing-framework.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
index a22190b21853..8966cd432eaa 100644
--- a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -1392,7 +1392,7 @@ This means you have used `console.log` in your code, which is not supported by A
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
 
-## Ressources complémentaires
+## Ressources supplémentaires
 
 For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
 

From 89ecc9b2fb38b67ebce5eeeb4116ec1dbc40f1e1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 26 Dec 2024 08:01:00 -0500
Subject: [PATCH 2402/3820] New translations enums.mdx (French)

---
 website/pages/fr/subgraphs/cookbook/enums.mdx | 146 +++++++++---------
 1 file changed, 73 insertions(+), 73 deletions(-)

diff --git a/website/pages/fr/subgraphs/cookbook/enums.mdx b/website/pages/fr/subgraphs/cookbook/enums.mdx
index 790f4844bed2..5784cb991330 100644
--- a/website/pages/fr/subgraphs/cookbook/enums.mdx
+++ b/website/pages/fr/subgraphs/cookbook/enums.mdx
@@ -2,19 +2,19 @@
 title: Catégoriser les marketplaces NFT à l’aide d’Enums
 ---
 
-Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+Utilisez des Enums pour rendre votre code plus propre et moins sujet aux erreurs. Voici un exemple complet d'utilisation des Enums sur les marketplaces NFT.
 
-## What are Enums?
+## Que sont les Enums ?
 
-Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+Les Enums, ou types d'énumération, sont un type de données spécifique qui vous permet de définir un ensemble de valeurs spécifiques et autorisées.
 
-### Example of Enums in Your Schema
+### Exemple d'Enums dans Votre Schéma
 
-If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+Si vous construisez un subgraph pour suivre l'historique de propriété des tokens sur une marketplace, chaque token peut passer par différentes propriétés, telles que`OriginalOwner`, `SecondOwner`, et `ThirdOwner`. En utilisant des enums, vous pouvez définir ces propriétés spécifiques, garantissant que seules des valeurs prédéfinies sont utilisées.
 
-You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+Vous pouvez définir des enums dans votre schéma et, une fois définis, vous pouvez utiliser la représentation en chaîne de caractères des valeurs enum pour définir un champ enum sur une entité.
 
-Here's what an enum definition might look like in your schema, based on the example above:
+Voici à quoi pourrait ressembler une définition d'enum dans votre schéma, basée sur l'exemple ci-dessus :
 
 ```graphql
 enum TokenStatus {
@@ -24,109 +24,109 @@ enum TokenStatus {
 }
 ```
 
-This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+Ceci signifie que lorsque vous utilisez le type `TokenStatus` dans votre schéma, vous attendez qu'il soit exactement l'une des valeurs prédéfinies : `OriginalOwner`, `SecondOwner`, ou `ThirdOwner`, garantissant la cohérence et la validité des données.
 
-To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+Pour en savoir plus sur les enums, consultez [Création d'un Subgraph](/developing/creating-a-subgraph/#enums) et [documentation GraphQL ](https://graphql.org/learn/schema/#enumeration-types).
 
-## Benefits of Using Enums
+## Avantages de l'Utilisation des Enums
 
-- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
-- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
-- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+- **Clarté** : Les enums fournissent des noms significatifs pour les valeurs, rendant les données plus faciles à comprendre.
+- **Validation** : Les enums imposent des définitions de valeurs strictes, empêchant les entrées de données invalides.
+- **Maintenabilité** : Lorsque vous avez besoin de changer ou d'ajouter de nouvelles catégories, les enums vous permettent de le faire de manière ciblée.
 
-### Without Enums
+### Sans Enums
 
-If you choose to define the type as a string instead of using an Enum, your code might look like this:
+Si vous choisissez de définir le type comme une chaîne de caractères au lieu d'utiliser un Enum, votre code pourrait ressembler à ceci :
 
 ```graphql
 type Token @entity {
   id: ID!
   tokenId: BigInt!
-  owner: Bytes! # Owner of the token
-  tokenStatus: String! # String field to track token status
+  owner: Bytes! # Propriétaire du jeton
+  tokenStatus: String! # Champ de type chaîne pour suivre l'état du jeton
   timestamp: BigInt!
 }
 ```
 
-In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+Dans ce schéma, `TokenStatus` est une simple chaîne de caractères sans valeurs spécifiques autorisées.
 
 #### Pourquoi est-ce un problème ?
 
-- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
-- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+- Il n'y a aucune restriction sur les valeurs de `TokenStatus` : n’importe quelle chaîne de caractères peut être affectée par inadvertance. Difficile donc de s'assurer que seules des valeurs valides comme comme `OriginalOwner`, `SecondOwner`, ou `ThirdOwner` soient utilisées.
+- Il est facile de faire des fautes de frappe comme `Orgnalowner` au lieu de `OriginalOwner`, rendant les données et les requêtes potentielles peu fiables.
 
-### With Enums
+### Avec Enums
 
-Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+Au lieu d'assigner des chaînes de caractères libres, vous pouvez définir un enum pour `TokenStatus` avec des valeurs spécifiques : `OriginalOwner`, `SecondOwner`, ou `ThirdOwner`. L'utilisation d'un enum garantit que seules les valeurs autorisées sont utilisées.
 
-Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+Les Enums assurent la sécurité des types, minimisent les risques de fautes de frappe et garantissent des résultats cohérents et fiables.
 
-## Defining Enums for NFT Marketplaces
+## Définition des Enums pour les Marketplaces NFT
 
-> Note: The following guide uses the CryptoCoven NFT smart contract.
+> Note: Le guide suivant utilise le smart contract CryptoCoven NFT.
 
-To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+Pour définir des enums pour les différents marketplaces où les NFTs sont échangés, utilisez ce qui suit dans votre schéma de subgraph :
 
 ```gql
-# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+# Enum pour les Marketplaces avec lesquelles le contrat CryptoCoven a interagi (probablement une vente ou un mint)
 enum Marketplace {
-  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
-  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
-  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
-  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
-  # ...and other marketplaces
+  OpenSeaV1 # Représente lorsque un NFT CryptoCoven est échangé sur la marketplace
+  OpenSeaV2 # Représente lorsque un NFT CryptoCoven est échangé sur la marketplace OpenSeaV2
+  SeaPort # Représente lorsque un NFT CryptoCoven est échangé sur la marketplace SeaPort
+  LooksRare # Représente lorsque un NFT CryptoCoven est échangé sur la marketplace LooksRare
+  # ...et d'autres marketplaces
 }
 ```
 
-## Using Enums for NFT Marketplaces
+## Utilisation des Enums pour les Marketplaces NFT
 
-Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+Une fois définis, les enums peuvent être utilisés tout au long de votre subgraph pour catégoriser les transactions ou les événements.
 
-For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+Par exemple, lors de la journalisation des ventes de NFT, vous pouvez spécifier la marketplace impliqué dans la transaction en utilisant l'enum.
 
-### Implementing a Function for NFT Marketplaces
+### Implémenter une Fonction pour les Marketplaces NFT
 
-Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+Voici comment vous pouvez implémenter une fonction pour récupérer le nom de la marketplace à partir de l'enum sous forme de chaîne de caractères :
 
 ```ts
 export function getMarketplaceName(marketplace: Marketplace): string {
-  // Using if-else statements to map the enum value to a string
+  // Utilisation des instructions if-else pour mapper la valeur de l'enum à une chaîne de caractères
   if (marketplace === Marketplace.OpenSeaV1) {
-    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+    return 'OpenSeaV1' // Si le marketplace est OpenSea, renvoie sa représentation en chaîne de caractères
   } else if (marketplace === Marketplace.OpenSeaV2) {
     return 'OpenSeaV2'
   } else if (marketplace === Marketplace.SeaPort) {
-    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+    return 'SeaPort' // Si le marketplace est SeaPort, renvoie sa représentation en chaîne de caractères
   } else if (marketplace === Marketplace.LooksRare) {
-    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
-    // ... and other market places
+    return 'LooksRare' // Si le marketplace est LooksRare, renvoie sa représentation en chaîne de caractères
+    // ... et d'autres marketplaces
   }
 }
 ```
 
-## Best Practices for Using Enums
+## Bonnes Pratiques pour l'Utilisation des Enums
 
-- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
-- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
-- **Documentation:** Add comments to enum to clarify their purpose and usage.
+- **Nommer avec cohérence** : Utilisez des noms clairs et descriptifs pour les valeurs d'enum pour améliorer la lisibilité.
+- **Gestion Centralisée** : Gardez les enums dans un fichier unique pour plus de cohérence. Ainsi, il est plus simple de les mettre à jour et de garantir qu’ils sont votre unique source de vérité.
+- **Documentation** : Ajoutez des commentaires aux enums pour clarifier leur objectif et leur utilisation.
 
-## Using Enums in Queries
+## Utilisation des Enums dans les Requêtes
 
-Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+Les enums dans les requêtes aident à améliorer la qualité des données et à rendre les résultats plus faciles à interpréter. Ils fonctionnent comme des filtres et des éléments de réponse, assurant la cohérence et réduisant les erreurs dans les valeurs des marketplaces.
 
-**Specifics**
+Spécificités
 
-- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
-- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+- **Filtrer avec des Enums**: Les Enums offrent des filtres clairs, vous permettant d’inclure ou d’exclure facilement des marketplaces spécifiques.
+- **Enums dans les Réponses**: Les Enums garantissent que seules des valeurs de marketplace reconnues sont renvoyées, ce qui rend les résultats standardisés et précis.
 
-### Sample Queries
+### Exemples de requêtes
 
-#### Query 1: Account With The Highest NFT Marketplace Interactions
+#### Requête 1 : Compte avec le Plus d'Interactions sur les Marketplaces NFT
 
-This query does the following:
+Cette requête fait ce qui suit :
 
-- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
-- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+- Elle trouve le compte avec le plus grand nombre unique d'interactions sur les marketplaces NFT, ce qui est excellent pour analyser l'activité inter-marketplaces.
+- Le champ marketplaces utilise l'enum marketplace, garantissant des valeurs de marketplace cohérentes et validées dans la réponse.
 
 ```gql
 {
@@ -137,15 +137,15 @@ This query does the following:
     totalSpent
     uniqueMarketplacesCount
     marketplaces {
-      marketplace # This field returns the enum value representing the marketplace
+      marketplace # Ce champ retourne la valeur enum représentant la marketplace
     }
   }
 }
 ```
 
-#### Returns
+#### Résultats
 
-This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+Cette réponse fournit les détails du compte et une liste des interactions uniques sur les marketplaces avec des valeurs enum pour une clarté standardisée :
 
 ```gql
 {
@@ -186,12 +186,12 @@ This response provides account details and a list of unique marketplace interact
 }
 ```
 
-#### Query 2: Most Active Marketplace for CryptoCoven transactions
+#### Requête 2 : Marketplace la Plus Active pour les Transactions CryptoCoven
 
-This query does the following:
+Cette requête fait ce qui suit :
 
-- It identifies the marketplace with the highest volume of CryptoCoven transactions.
-- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+- Elle identifie la marketplace avec le plus grand volume de transactions CryptoCoven.
+- Il utilise l'enum marketplace pour s'assurer que seuls les types de marketplace valides apparaissent dans la réponse, ajoutant fiabilité et cohérence à vos données.
 
 ```gql
 {
@@ -202,9 +202,9 @@ This query does the following:
 }
 ```
 
-#### Result 2
+#### Résultat 2
 
-The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+La réponse attendue inclut la marketplace et le nombre de transactions correspondant, en utilisant l'enum pour indiquer le type de marketplace :
 
 ```gql
 {
@@ -219,12 +219,12 @@ The expected response includes the marketplace and the corresponding transaction
 }
 ```
 
-#### Query 3: Marketplace Interactions with High Transaction Counts
+#### Requête 3: Interactions sur les marketplaces avec un haut volume de transactions
 
-This query does the following:
+Cette requête fait ce qui suit :
 
-- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
-- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+- Elle récupère les quatre principales marketplaces avec plus de 100 transactions, en excluant les marketplaces "Unknown".
+- Elle utilise des enums comme filtres pour s'assurer que seuls les types de marketplace valides sont inclus, augmentant ainsi la précision.
 
 ```gql
 {
@@ -240,9 +240,9 @@ This query does the following:
 }
 ```
 
-#### Result 3
+#### Résultat 3
 
-Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+La sortie attendue inclut les marketplaces qui répondent aux critères, chacune représentée par une valeur enum :
 
 ```gql
 {
@@ -269,6 +269,6 @@ Expected output includes the marketplaces that meet the criteria, each represent
 }
 ```
 
-## Ressources complémentaires
+## Ressources supplémentaires
 
-For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).
+Pour des informations supplémentaires, consultez le [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums) de ce guide.

From 961134833c6b27fccfc40981e9d68db08184f167 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 26 Dec 2024 08:01:01 -0500
Subject: [PATCH 2403/3820] New translations explorer.mdx (French)

---
 website/pages/fr/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/explorer.mdx b/website/pages/fr/subgraphs/explorer.mdx
index 3f8ddc58ea66..7cf76051a228 100644
--- a/website/pages/fr/subgraphs/explorer.mdx
+++ b/website/pages/fr/subgraphs/explorer.mdx
@@ -55,7 +55,7 @@ Les Indexeurs sont la colonne vertébrale du protocole. Ils stakent sur les subg
 
 Dans le tableau des Indexeurs, vous pouvez voir les paramètres de délégation des Indexeurs, leur staking, combien ils ont staké sur chaque subgraph et combien de revenus ils ont généré à partir des frais de requête et des récompenses d'indexation.
 
-**Specifics**
+Spécificités
 
 - Query Fee Cut - le % des frais de requête que l'Indexeur conserve lors de la répartition avec les Délégateurs.
 - Effective Reward Cut - la réduction des récompenses d'indexation appliquée au pool de délégation. Si elle est négative, cela signifie que l'Indexeur donne une partie de ses récompenses. Si elle est positive, cela signifie que l'Indexeur garde une partie de ses récompenses.

From 06b2c833c2bb54053b642aefadb04754617110f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 26 Dec 2024 09:03:30 -0500
Subject: [PATCH 2404/3820] New translations derivedfrom.mdx (French)

---
 website/pages/fr/subgraphs/cookbook/derivedfrom.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx b/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx
index f2be322a704b..91ad49d53794 100644
--- a/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/fr/subgraphs/cookbook/derivedfrom.mdx
@@ -1,5 +1,5 @@
 ---
-title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+title: Bonne pratique pour les subgraphs 2 - Améliorer la Réactivité de l'Indexation et des Requêtes en Utilisant @derivedFrom
 ---
 
 ## TLDR

From e2b828adb91c08c0d00912d9118aaea18bb0137f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 26 Dec 2024 09:03:34 -0500
Subject: [PATCH 2405/3820] New translations
 immutable-entities-bytes-as-ids.mdx (French)

---
 .../cookbook/immutable-entities-bytes-as-ids.mdx   | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/fr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/fr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
index 0f6be0be5afe..2955643c8a45 100644
--- a/website/pages/fr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/fr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -1,14 +1,14 @@
 ---
-title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+title: Bonne pratique pour les subgraphs 3 - Améliorer l'Indexation et les Performances de Recherche en Utilisant des Entités Immuables et des Bytes comme IDs
 ---
 
 ## TLDR
 
-Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+Utiliser des Entités Immuables et des Bytes pour les IDs dans notre fichier `schema.graphql` [améliore considérablement ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) la vitesse d'indexation et les performances de recherche.
 
-## Immutable Entities
+## Entités Immuables
 
-To make an entity immutable, we simply add `(immutable: true)` to an entity.
+Pour rendre une entité immuable, il suffit d'ajouter `(immutable: true)` à cette entité.
 
 ```graphql
 type Transfer @entity(immutable: true) {
@@ -19,13 +19,13 @@ type Transfer @entity(immutable: true) {
 }
 ```
 
-By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+En rendant l'entité `Transfer` immuable, graph-node est capable de traiter l'entité plus efficacement, améliorant la vitesse d'indexation et la réactivité des requêtes.
 
 Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
 
-### Under the hood
+### Sous le capot
 
-Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+Les entités mutables ont une "plage de blocs" indiquant leur validité. La mise à jour de ces entités nécessite que le graph node ajuste la plage de blocs des versions précédentes, augmentant la charge de travail de la base de données. Les requêtes nécessitent également un filtrage pour trouver uniquement les entités actives. Les entités immuables sont plus rapides car elles sont toutes actives et, puisqu'elles ne changeront pas, aucun contrôle ou mise à jour n'est requis lors de l'écriture, et aucun filtrage n'est requis pendant les requêtes.
 
 ### Quand ne pas utiliser les Entités Immuables
 

From ce1a2242a26076d3a4fa029324a93a302c353e89 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 26 Dec 2024 09:03:35 -0500
Subject: [PATCH 2406/3820] New translations secure-api-keys-nextjs.mdx
 (French)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 50 +++++++++----------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/website/pages/fr/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/fr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index 10a7c38dbcdc..86cf0b445240 100644
--- a/website/pages/fr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/fr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -10,39 +10,39 @@ Dans ce guide pratique, nous allons passer en revue la création d'un composant
 
 ### Mise en garde
 
-- Next.js server components do not protect API keys from being drained using denial of service attacks.
-- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
-- Next.js server components introduce centralization risks as the server can go down.
+- Les composants serveur de Next.js ne protègent pas les clés API contre les attaques de déni de service.
+- Les passerelles de The Graph Network disposent de stratégies de détection et d'atténuation des attaques de déni de service, cependant, l'utilisation des composants serveur peut affaiblir ces protections.
+- Les composants serveur de Next.js introduisent des risques de centralisation car le serveur peut tomber en panne.
 
-### Why It's Needed
+### Pourquoi est-ce nécessaire
 
-In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+Dans une application React standard, les clés API incluses dans le code frontend peuvent être exposées du côté client, posant un risque de sécurité. Bien que les fichiers `.env` soient couramment utilisés, ils ne protègent pas complètement les clés car le code de React est exécuté côté client, exposant ainsi la clé API dans les headers. Les composants serveur Next.js résolvent ce problème en gérant les opérations sensibles côté serveur.
 
-### Using client-side rendering to query a subgraph
+### Utilisation du rendu côté client pour interroger un subgraph
 
-![Client-side rendering](/img/api-key-client-side-rendering.png)
+![rendu côté client](/img/api-key-client-side-rendering.png)
 
 ### Conditions préalables
 
-- An API key from [Subgraph Studio](https://thegraph.com/studio)
-- Basic knowledge of Next.js and React.
-- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+- Une clé API provenant de [Subgraph Studio](https://thegraph.com/studio)
+- Une connaissance de base de Next.js et React.
+- Un projet Next.js existant qui utilise l'[App Router](https://nextjs.org/docs/app).
 
-## Step-by-Step Cookbook
+## Guide étape par étape
 
-### Step 1: Set Up Environment Variables
+### Étape 1 : Configurer les Variables d'Environnement
 
-1. In our Next.js project root, create a `.env.local` file.
-2. Add our API key: `API_KEY=<api_key_here>`.
+1. À la racine de notre projet Next.js, créer un fichier `.env.local` .
+2. Ajouter notre clé API :: `API_KEY=<cle_api_ici>`.
 
-### Step 2: Create a Server Component
+### Étape 2 : Créer un Composant Serveur
 
-1. In our `components` directory, create a new file, `ServerComponent.js`.
-2. Use the provided example code to set up the server component.
+1. Dans notre répertoire`components` , créer un nouveau fichier, `ServerComponent.js`.
+2. Utiliser le code exemple fourni pour configurer le composant serveur.
 
-### Step 3: Implement Server-Side API Request
+### Étape 3 : Implémenter la Requête API Côté Serveur
 
-In `ServerComponent.js`, add the following code:
+Dans `ServerComponent.js`, ajouter le code suivant :
 
 ```javascript
 const API_KEY = process.env.API_KEY
@@ -95,10 +95,10 @@ export default async function ServerComponent() {
 }
 ```
 
-### Step 4: Use the Server Component
+### Étape 4 : Utiliser le Composant Serveur
 
-1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
-2. Render the component:
+1. Dans notre fichier de page (par exemple, `pages/index.js`), importer `ServerComponent`.
+2. Rendu du composant:
 
 ```javascript
 import ServerComponent from './components/ServerComponent'
@@ -112,11 +112,11 @@ export default function Home() {
 }
 ```
 
-### Step 5: Run and Test Our Dapp
+### Étape 5 : Lancer et tester notre Dapp
 
-Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+Démarrez notre application Next.js en utilisant `npm run dev`. Vérifiez que le composant serveur récupère les données sans exposer la clé API.
 
-![Server-side rendering](/img/api-key-server-side-rendering.png)
+![Rendu côté serveur](/img/api-key-server-side-rendering.png)
 
 ### Conclusion
 

From e8f335d3d93d501ede0b7ce6ccdd93e4edb0460a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 26 Dec 2024 09:03:36 -0500
Subject: [PATCH 2407/3820] New translations transfer-to-the-graph.mdx (French)

---
 .../cookbook/transfer-to-the-graph.mdx        | 54 +++++++++----------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/website/pages/fr/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/fr/subgraphs/cookbook/transfer-to-the-graph.mdx
index 78f59e46c7df..d34a88327c64 100644
--- a/website/pages/fr/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/fr/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -1,72 +1,72 @@
 ---
-title: Tranfer to The Graph
+title: Transférer vers The Graph
 ---
 
-Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+Mettez rapidement à jour vos subgraphs depuis n'importe quelle plateforme vers [le réseau décentralisé de The Graph](https://thegraph.com/networks/).
 
-## Benefits of Switching to The Graph
+## Avantages du passage à The Graph
 
-- Use the same subgraph that your apps already use with zero-downtime migration.
-- Increase reliability from a global network supported by 100+ Indexers.
-- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+- Utilisez le même subgraph que vos applications utilisent déjà avec une migration sans interruption de service.
+- Améliorez la fiabilité grâce à un réseau mondial pris en charge par plus de 100 Indexers.
+- Bénéficiez d’un support ultra-rapide pour vos subgraphs 24/7, avec une équipe d’ingénieurs de garde.
 
-## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+## Mettez à jour votre Subgraph vers The Graph en 3 étapes simples
 
 1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
 2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
 3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
 
-## 1. Set Up Your Studio Environment
+## 1. Configurer votre environnement Studio
 
-### Create a Subgraph in Subgraph Studio
+### Créer un subgraph dans Subgraph Studio
 
-- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
-- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+- Accédez à [Subgraph Studio](https://thegraph.com/studio/) et connectez votre portefeuille.
+- Cliquez sur « Créer un subgraph ». Il est recommandé de nommer le subgraph en majuscule : « Nom du subgraph Nom de la chaîne ».
 
 > Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
-### Install the Graph CLI⁠
+### Installer Graph CLI
 
-You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+Vous devez avoir Node.js et un gestionnaire de paquets de votre choix (`npm` or `pnpm`) installés pour utiliser Graph CLI. Vérifiez la version la [plus récente](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) de CLI.
 
-On your local machine, run the following command:
+Sur votre machine locale, exécutez la commande suivante :
 
-Using [npm](https://www.npmjs.com/):
+Utilisation de [npm](https://www.npmjs.com/) :
 
 ```sh
 npm install -g @graphprotocol/graph-cli@latest
 ```
 
-Use the following command to create a subgraph in Studio using the CLI:
+Utilisez la commande suivante pour créer un subgraph dans Studio en utilisant CLI :
 
 ```sh
 graph init --product subgraph-studio
 ```
 
-### Authenticate Your Subgraph
+### Authentifiez votre subgraph
 
-In The Graph CLI, use the auth command seen in Subgraph Studio:
+Dans Graph CLI, utilisez la commande auth vue dans Subgraph Studio :
 
 ```sh
 graph auth <your-auth-code>
 ```
 
-## 2. Deploy Your Subgraph to Studio
+## 2. Déployez votre Subgraph sur Studio
 
-If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+Si vous avez votre code source, vous pouvez facilement le déployer sur Studio. Si vous ne l'avez pas, voici un moyen rapide de déployer votre subgraph.
 
-In The Graph CLI, run the following command:
+Dans Graph CLI, exécutez la commande suivante :
 
 ```sh
 graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
 
 ```
 
-> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+> **Note:**: Chaque subgraph a un hash IPFS (ID de déploiement), qui ressemble à ceci : "Qmasdfad...". Pour déployer, utilisez simplement ce **hash IPFS**. Vous serez invité à entrer une version (par exemple, v0.0.1).
 
-## 3. Publish Your Subgraph to The Graph Network
+## 3. Publier votre Subgraph sur The Graph Network
 
-![publish button](/img/publish-sub-transfer.png)
+![bouton de publication](/img/publish-sub-transfer.png)
 
 ### Interroger votre Subgraph
 
@@ -96,9 +96,9 @@ Vous pouvez créer des clés API dans Subgraph Studio sous le menu "API Keys" en
 
 ### Surveiller l'état du Subgraph
 
-Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+Une fois que vous avez mis à jour, vous pouvez accéder et gérer vos subgraphs dans [Subgraph Studio](https://thegraph.com/studio/) et explorer tous les subgraphs dans [The Graph Explorer](https://thegraph.com/networks/).
 
-### Ressources complémentaires
+### Ressources supplémentaires
 
 - To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
-- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).
+- Pour explorer toutes les façons d'optimiser et de personnaliser votre subgraph pour de meilleures performances, lisez plus sur [la création d'un subgraph ici](/developing/creating-a-subgraph/).

From 4b0c935d6c83e33c911f2059601cfc7710b4d656 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 26 Dec 2024 09:03:38 -0500
Subject: [PATCH 2408/3820] New translations quick-start.mdx (French)

---
 website/pages/fr/subgraphs/quick-start.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/subgraphs/quick-start.mdx b/website/pages/fr/subgraphs/quick-start.mdx
index be5c7e50bc6b..710214931cad 100644
--- a/website/pages/fr/subgraphs/quick-start.mdx
+++ b/website/pages/fr/subgraphs/quick-start.mdx
@@ -15,17 +15,17 @@ Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/
 
 ### 1. Create a subgraph in Subgraph Studio
 
-Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+Accédez à [Subgraph Studio](https://thegraph.com/studio/) et connectez votre portefeuille.
 
 Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
 
-Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+Cliquez sur « Créer un subgraph ». Il est recommandé de nommer le subgraph en majuscule : « Nom du subgraph Nom de la chaîne ».
 
 ### 2. Installez la CLI Graph
 
 Sur votre machine locale, exécutez l'une des commandes suivantes :
 
-Using [npm](https://www.npmjs.com/):
+Utilisation de [npm](https://www.npmjs.com/) :
 
 ```sh
 npm install -g @graphprotocol/graph-cli@latest

From 347dcda4cb1a9a4dbf9189106cfdce087492e8cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 8 Jan 2025 16:30:27 -0500
Subject: [PATCH 2409/3820] New translations billing.mdx (Portuguese)

---
 website/pages/pt/subgraphs/billing.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/pt/subgraphs/billing.mdx b/website/pages/pt/subgraphs/billing.mdx
index 33de71abbce7..6c5c8f08691c 100644
--- a/website/pages/pt/subgraphs/billing.mdx
+++ b/website/pages/pt/subgraphs/billing.mdx
@@ -2,20 +2,20 @@
 title: Cobranças
 ---
 
-## Querying Plans
+## Planos de Query
 
 Há dois planos disponíveis para queries de subgraphs na Graph Network.
 
-- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+- **Plano Grátis**: Inclui 100.000 queries grátis por mês, com acesso ilimitado ao ambiente de testes do Subgraph Studio. O plano é feito para entusiastas, participantes de hackathons, e para quem tem projetos paralelos para experimentar o The Graph antes de escalar o seu dapp.
 
-- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+- **Plano de Crescimento**: Inclui tudo no Plano Grátis, com todos os queries após a cota de 100.000 mensais exigindo pagamentos com cartão de crédito ou GRT. Este plano é flexível o suficiente para cobrir equipes que estabeleceram dapps numa variedade de casos de uso.
 
 <VideoEmbed youtube="Nn771WagX2I" />
 
 ## Pagamentos de Queries com cartão de crédito
 
-- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
-  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+- Para configurar o faturamento com cartões de crédito ou débito, os utilizadores podem acessar o Subgraph Studio. (https://thegraph.com/studio/)
+  1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
   2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página. Isto levará à página de seleção de carteira; lá, selecione a sua carteira e clique em "Connect".
   3. Escolha "atualizar plano" se está a atualizar do Plano Grátis, ou escolha "Gerir plano" se já adicionou GRT ao seu saldo de cobrança no passado. Depois, é possível estimar o número de queries para conseguir uma estimativa de preço, mas isto não é obrigatório.
   4. Para escolher um pagamento em cartão de crédito, escolha "Cartão de crédito" como o método de pagamento e preencha os campos. Quem já usou o Stripe antes poderá preencher os seus detalhes automaticamente com o recurso Link.
@@ -51,7 +51,7 @@ Quando fizeres bridge do GRT, será possível adicioná-lo ao seu saldo de cobra
 
 ### Depósitos de GRT com uma carteira
 
-1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
 2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página. Isto levará à página de seleção de carteira; lá, selecione a sua carteira e clique em "Connect".
 3. Selecione o botão "Manage" (Gerir) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
 4. Use o slider para estimar o número de queries que espera fazer mensalmente.
@@ -68,7 +68,7 @@ Quando fizeres bridge do GRT, será possível adicioná-lo ao seu saldo de cobra
 
 ### Saques de GRT com carteira
 
-1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
 2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página, selecione a sua carteira e clique em "Connect".
 3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
 4. Insira a quantia de GRT que quer sacar.

From 0d189161cfb79b30813223e163f5c2dd4a445bc1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 8 Jan 2025 17:39:29 -0500
Subject: [PATCH 2410/3820] New translations billing.mdx (Portuguese)

---
 website/pages/pt/subgraphs/billing.mdx | 54 +++++++++++++-------------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/website/pages/pt/subgraphs/billing.mdx b/website/pages/pt/subgraphs/billing.mdx
index 6c5c8f08691c..c51b23e115e8 100644
--- a/website/pages/pt/subgraphs/billing.mdx
+++ b/website/pages/pt/subgraphs/billing.mdx
@@ -45,7 +45,7 @@ Para pagar por queries, é necessário ter GRT no Arbitrum. Veja algumas maneira
 
 - Também é possível adquirir GRT diretamente no Arbitrum via uma exchange descentralizada.
 
-> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+> Esta seção presume que já tens GRT na sua carteira, e que estás na rede Arbitrum. Caso não tenha GRT, veja como adquirir o token [aqui](#getting-grt).
 
 Quando fizeres bridge do GRT, será possível adicioná-lo ao seu saldo de cobranças.
 
@@ -55,7 +55,7 @@ Quando fizeres bridge do GRT, será possível adicioná-lo ao seu saldo de cobra
 2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página. Isto levará à página de seleção de carteira; lá, selecione a sua carteira e clique em "Connect".
 3. Selecione o botão "Manage" (Gerir) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
 4. Use o slider para estimar o número de queries que espera fazer mensalmente.
-   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+   - Para sugestões sobre o número de queries a usar, veja a nossa página de **Perguntas Frequentes**.
 5. Escolha "Criptomoedas". Atualmente, o GRT é a única criptomoeda aceita na Graph Network.
 6. Selecione o número de meses que deseja pagar antecipadamente.
    - Pagamentos antecipados não te comprometem a usos futuros. Você só será cobrado pelo que usa, e pode sacar o seu saldo a qualquer hora.
@@ -70,18 +70,18 @@ Quando fizeres bridge do GRT, será possível adicioná-lo ao seu saldo de cobra
 
 1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
 2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página, selecione a sua carteira e clique em "Connect".
-3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+3. Clique o botão "Manage" (Preferências) no canto superior direito. Selecione "Withdraw GRT" (Sacar GRT) para abrir um painel lateral.
 4. Insira a quantia de GRT que quer sacar.
 5. Clique em 'Withdraw GRT' (Sacar GRT) para sacar o GRT do seu saldo. Assine a transação associada na sua carteira — isto custa gas. O GRT será enviado à sua carteira Arbitrum.
 6. Quando a transação for confirmada, verá o GRT sacado do seu saldo na sua carteira Arbitrum.
 
 ### Depósitos de GRT com uma carteira multisig
 
-1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
-2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
-3. Selecione o botão "Manage" (Gerir) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
+1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
+2. Clique em "Connect Wallet" (Conectar Carteira) no canto superior direito, selecione a sua carteira e clique em "Connect" (Conectar). Se usar o Gnosis-Safe, poderá conectar a sua multisig além da sua carteira de assinatura. Depois, assine a mensagem associada. Isto não custa gas.
+3. Selecione o botão "Manage" (Preferências) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
 4. Use o slider para estimar o número de queries que espera fazer mensalmente.
-   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+   - Para sugestões sobre o número de queries a usar, veja a nossa página de **Perguntas Frequentes**.
 5. Escolha "Criptomoedas". Atualmente, o GRT é a única criptomoeda aceita na Graph Network.
 6. Selecione o número de meses que deseja pagar antecipadamente.
    - Pagamentos antecipados não te comprometem a usos futuros. Você só será cobrado pelo que usa, e pode sacar o seu saldo a qualquer hora.
@@ -99,7 +99,7 @@ Esta seção explicará como adquirir GRT para pagar taxas de query.
 
 Este é um guia passo a passo sobre como comprar GRT na Coinbase.
 
-1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+1. Crie uma conta na [Coinbase](https://www.coinbase.com/).
 2. Quando tiver criado uma conta, precisará verificar a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este é um processo comum em todas as exchanges de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, poderá comprar GRT no botão "Comprar/Vender", no canto superior direito da página.
 4. Selecione a moeda que deseja comprar — no caso, GRT.
@@ -107,19 +107,19 @@ Este é um guia passo a passo sobre como comprar GRT na Coinbase.
 6. Selecione a quantia de GRT que deseja comprar.
 7. Verifique a sua compra, e após verificar, clique em "Comprar GRT".
 8. Confirme a sua compra, e o GRT será comprado com sucesso.
-9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+9. Poderá transferir o GRT da sua conta a carteiras na sua posse, como no [MetaMask](https://metamask.io/).
    - Para transferir o GRT à sua carteira, clique no botão "Contas" no canto superior direito da página.
    - Clique em "Enviar", próximo à conta de GRT.
    - Insira a quantia de GRT que deseja enviar, e o endereço da carteira que a receberá.
    - Clique em "Continuar" e confirme a sua transação. Nota: para compras maiores, a Coinbase pode demorar de 7 a 10 dias antes de transferir a quantia completa a uma carteira.
 
-You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+Saiba mais sobre adquirir GRT na Coinbase [aqui](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
 
 ### Binance
 
 Este é um guia passo a passo para comprar GRT na Binance.
 
-1. Go to [Binance](https://www.binance.com/en) and create an account.
+1. Crie uma conta na [Binance](https://www.binance.com/en).
 2. Quando tiver criado uma conta, precisará verificar a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este é um processo comum em todas as exchanges de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, poderá comprar GRT no botão "Comprar Agora", no canto superior direito da página.
 4. O botão levará-lhe a uma página onde pode selecionar a moeda que deseja comprar. Selecione GRT.
@@ -127,27 +127,27 @@ Este é um guia passo a passo para comprar GRT na Binance.
 6. Selecione a quantia de GRT que deseja comprar.
 7. Verifique a sua compra e clique em "Comprar GRT".
 8. Confirme a sua compra, e logo o seu GRT aparecerá na sua Carteira Spot da Binance.
-9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
-   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+9. Poderá sacar o GRT da sua conta para carteiras na sua posse, como no [MetaMask](https://metamask.io/).
+   - Para [sacar o GRT](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) e adicionar à sua carteira, adicione o endereço da sua carteira para a whitelist de saque.
    - Clique no botão "wallet", clique em "sacar", e selecione GRT.
    - Insira a quantia de GRT que deseja enviar, e o endereço da carteira na whitelist à qual quer enviar.
    - Clique em "Continuar" e confirme a sua transação.
 
-You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+Saiba mais sobre adquirir GRT na Binance [aqui](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
 
 ### Uniswap
 
 Este é um guia passo a passo sobre como comprar GRT no Uniswap.
 
-1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+1. Conecte a sua carteira à [Uniswap](https://app.uniswap.org/swap?chain=arbitrum).
 2. Selecione o token que quer trocar — no caso, ETH.
 3. Selecione o token pelo que quer trocar — no caso, GRT.
-   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+   - Verifique se está a trocar para o token correto. O endereço do contrato inteligente na Arbitrum One é: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
 4. Insira a quantia de ETH que deseja trocar.
 5. Clique em "Swap".
 6. Confirme a transação na sua carteira e espere que a transação seja processada.
 
-You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+Saiba mais sobre adquirir GRT na Uniswap [aqui](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
 
 ## Como adquirir Ether
 
@@ -157,7 +157,7 @@ Esta seção explicará como adquirir Ether (ETH) para pagar por taxas de transa
 
 Este é um guia passo a passo sobre como comprar ETH na Coinbase.
 
-1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+1. Crie uma conta na [Coinbase](https://www.coinbase.com/).
 2. Quando tiver criado uma conta, verifique a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este processo é comum em todas as corretoras de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, compre ETH no botão "Comprar/Vender", no canto superior direito da página.
 4. Selecione a moeda que deseja comprar — no caso, ETH.
@@ -165,20 +165,20 @@ Este é um guia passo a passo sobre como comprar ETH na Coinbase.
 6. Insira a quantia de ETH que deseja comprar.
 7. Reveja a sua compra e clique em "Comprar ETH".
 8. Confirme a sua compra, e o ETH será adquirido com sucesso.
-9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+9. Poderá transferir o ETH da sua conta na Coinbase a carteiras na sua posse, como no [MetaMask](https://metamask.io/).
    - Para transferir o ETH à sua carteira, clique no botão "Contas" no canto superior direito da página.
    - Clique em "Enviar", próximo à conta de ETH.
    - Insira a quantia de ETH que deseja enviar, e o endereço da carteira que a receberá.
    - Certifique-se que enviará ao endereço da sua carteira de Ethereum no Arbitrum One.
    - Clique em "Continuar" e confirme a sua transação.
 
-You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+Saiba mais sobre adquirir ETH na Coinbase [aqui](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
 
 ### Binance
 
 Este é um guia passo a passo sobre como comprar ETH na Binance.
 
-1. Go to [Binance](https://www.binance.com/en) and create an account.
+1. Crie uma conta na [Binance](https://www.binance.com/en).
 2. Quando tiver criado uma conta, verifique a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este processo é comum em todas as corretoras de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, poderá comprar ETH no botão "Comprar/Vender", no banner da página principal.
 4. Selecione a moeda que deseja comprar — no caso, ETH.
@@ -186,29 +186,29 @@ Este é um guia passo a passo sobre como comprar ETH na Binance.
 6. Insira a quantia de ETH que deseja comprar.
 7. Reveja a sua compra e clique em "Comprar ETH".
 8. Confirme a sua compra, e o seu ETH aparecerá na sua Carteira Spot da Binance.
-9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+9. Poderá sacar o ETH da sua conta para carteiras na sua posse, como no [MetaMask](https://metamask.io/).
    - Para sacar o ETH à sua carteira, adicione o endereço da sua carteira à whitelist de saques.
    - Clique no botão "wallet", clique em "sacar" (withdraw), e selecione ETH.
    - Insira a quantia de ETH que deseja enviar, e o endereço da carteira na whitelist à qual quer enviar.
    - Certifique-se que enviará ao endereço da sua carteira de Ethereum no Arbitrum One.
    - Clique em "Continuar" e confirme a sua transação.
 
-You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+Saiba mais sobre adquirir ETH na Binance [aqui](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
 
 ## Perguntas Frequentes Sobre Cobranças
 
 ### De quantas queries precisarei?
 
-You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+Não é necessário saber de quantos queries precisará com antecedência. O utilizador só será cobrado pelo que pode usar, e poderá sacar GRT da própria conta a qualquer hora.
 
 Recomendamos estimar mais queries do que necessário para que não precise encher o seu saldo com frequência. Uma boa estimativa para aplicativos pequenos ou médios é começar com 1 a 2 milhões de queries por mês e monitorar atenciosamente o uso nas primeiras semanas. Para aplicativos maiores, uma boa estimativa consiste em utilizar o número de visitas diárias ao seu site multiplicado ao número de queries que a sua página mais ativa faz ao abrir.
 
-Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+Utilizadores noviços e preexistentes podem consultar a equipa de Desenvolvimento Comercial (BD) da Edge & Node para saber mais sobre uso antecipado.
 
 ### Posso sacar GRT do meu saldo de cobrança?
 
-Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+Sim, sempre é possível sacar GRT do seu saldo de cobrança que já não tenha sido usado para queries. O contrato inteligente é projetado apenas para fazer bridge de GRT da mainnet Ethereum até a rede Arbitrum. Se quiser transferir o seu GRT do Arbitrum de volta à mainnet Ethereum, use a [bridge do Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161).
 
-### What happens when my billing balance runs out? Will I get a warning?
+### O que acontece se o meu saldo de cobrança esgotar? Receberei uma notificação?
 
 Serão enviadas várias notificações de email antes do seu saldo de cobrança ser esvaziado.

From 599e529b37087a0a468212677ee38c09301b5518 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 9 Jan 2025 18:51:52 -0500
Subject: [PATCH 2411/3820] New translations billing.mdx (Portuguese)

---
 website/pages/pt/subgraphs/billing.mdx | 68 +++++++++++++-------------
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/website/pages/pt/subgraphs/billing.mdx b/website/pages/pt/subgraphs/billing.mdx
index c51b23e115e8..33de71abbce7 100644
--- a/website/pages/pt/subgraphs/billing.mdx
+++ b/website/pages/pt/subgraphs/billing.mdx
@@ -2,20 +2,20 @@
 title: Cobranças
 ---
 
-## Planos de Query
+## Querying Plans
 
 Há dois planos disponíveis para queries de subgraphs na Graph Network.
 
-- **Plano Grátis**: Inclui 100.000 queries grátis por mês, com acesso ilimitado ao ambiente de testes do Subgraph Studio. O plano é feito para entusiastas, participantes de hackathons, e para quem tem projetos paralelos para experimentar o The Graph antes de escalar o seu dapp.
+- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
 
-- **Plano de Crescimento**: Inclui tudo no Plano Grátis, com todos os queries após a cota de 100.000 mensais exigindo pagamentos com cartão de crédito ou GRT. Este plano é flexível o suficiente para cobrir equipes que estabeleceram dapps numa variedade de casos de uso.
+- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
 
 <VideoEmbed youtube="Nn771WagX2I" />
 
 ## Pagamentos de Queries com cartão de crédito
 
-- Para configurar o faturamento com cartões de crédito ou débito, os utilizadores podem acessar o Subgraph Studio. (https://thegraph.com/studio/)
-  1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
+- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
+  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
   2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página. Isto levará à página de seleção de carteira; lá, selecione a sua carteira e clique em "Connect".
   3. Escolha "atualizar plano" se está a atualizar do Plano Grátis, ou escolha "Gerir plano" se já adicionou GRT ao seu saldo de cobrança no passado. Depois, é possível estimar o número de queries para conseguir uma estimativa de preço, mas isto não é obrigatório.
   4. Para escolher um pagamento em cartão de crédito, escolha "Cartão de crédito" como o método de pagamento e preencha os campos. Quem já usou o Stripe antes poderá preencher os seus detalhes automaticamente com o recurso Link.
@@ -45,17 +45,17 @@ Para pagar por queries, é necessário ter GRT no Arbitrum. Veja algumas maneira
 
 - Também é possível adquirir GRT diretamente no Arbitrum via uma exchange descentralizada.
 
-> Esta seção presume que já tens GRT na sua carteira, e que estás na rede Arbitrum. Caso não tenha GRT, veja como adquirir o token [aqui](#getting-grt).
+> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
 
 Quando fizeres bridge do GRT, será possível adicioná-lo ao seu saldo de cobranças.
 
 ### Depósitos de GRT com uma carteira
 
-1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
 2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página. Isto levará à página de seleção de carteira; lá, selecione a sua carteira e clique em "Connect".
 3. Selecione o botão "Manage" (Gerir) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
 4. Use o slider para estimar o número de queries que espera fazer mensalmente.
-   - Para sugestões sobre o número de queries a usar, veja a nossa página de **Perguntas Frequentes**.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
 5. Escolha "Criptomoedas". Atualmente, o GRT é a única criptomoeda aceita na Graph Network.
 6. Selecione o número de meses que deseja pagar antecipadamente.
    - Pagamentos antecipados não te comprometem a usos futuros. Você só será cobrado pelo que usa, e pode sacar o seu saldo a qualquer hora.
@@ -68,20 +68,20 @@ Quando fizeres bridge do GRT, será possível adicioná-lo ao seu saldo de cobra
 
 ### Saques de GRT com carteira
 
-1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
 2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página, selecione a sua carteira e clique em "Connect".
-3. Clique o botão "Manage" (Preferências) no canto superior direito. Selecione "Withdraw GRT" (Sacar GRT) para abrir um painel lateral.
+3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
 4. Insira a quantia de GRT que quer sacar.
 5. Clique em 'Withdraw GRT' (Sacar GRT) para sacar o GRT do seu saldo. Assine a transação associada na sua carteira — isto custa gas. O GRT será enviado à sua carteira Arbitrum.
 6. Quando a transação for confirmada, verá o GRT sacado do seu saldo na sua carteira Arbitrum.
 
 ### Depósitos de GRT com uma carteira multisig
 
-1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
-2. Clique em "Connect Wallet" (Conectar Carteira) no canto superior direito, selecione a sua carteira e clique em "Connect" (Conectar). Se usar o Gnosis-Safe, poderá conectar a sua multisig além da sua carteira de assinatura. Depois, assine a mensagem associada. Isto não custa gas.
-3. Selecione o botão "Manage" (Preferências) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
+1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+3. Selecione o botão "Manage" (Gerir) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
 4. Use o slider para estimar o número de queries que espera fazer mensalmente.
-   - Para sugestões sobre o número de queries a usar, veja a nossa página de **Perguntas Frequentes**.
+   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
 5. Escolha "Criptomoedas". Atualmente, o GRT é a única criptomoeda aceita na Graph Network.
 6. Selecione o número de meses que deseja pagar antecipadamente.
    - Pagamentos antecipados não te comprometem a usos futuros. Você só será cobrado pelo que usa, e pode sacar o seu saldo a qualquer hora.
@@ -99,7 +99,7 @@ Esta seção explicará como adquirir GRT para pagar taxas de query.
 
 Este é um guia passo a passo sobre como comprar GRT na Coinbase.
 
-1. Crie uma conta na [Coinbase](https://www.coinbase.com/).
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
 2. Quando tiver criado uma conta, precisará verificar a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este é um processo comum em todas as exchanges de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, poderá comprar GRT no botão "Comprar/Vender", no canto superior direito da página.
 4. Selecione a moeda que deseja comprar — no caso, GRT.
@@ -107,19 +107,19 @@ Este é um guia passo a passo sobre como comprar GRT na Coinbase.
 6. Selecione a quantia de GRT que deseja comprar.
 7. Verifique a sua compra, e após verificar, clique em "Comprar GRT".
 8. Confirme a sua compra, e o GRT será comprado com sucesso.
-9. Poderá transferir o GRT da sua conta a carteiras na sua posse, como no [MetaMask](https://metamask.io/).
+9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
    - Para transferir o GRT à sua carteira, clique no botão "Contas" no canto superior direito da página.
    - Clique em "Enviar", próximo à conta de GRT.
    - Insira a quantia de GRT que deseja enviar, e o endereço da carteira que a receberá.
    - Clique em "Continuar" e confirme a sua transação. Nota: para compras maiores, a Coinbase pode demorar de 7 a 10 dias antes de transferir a quantia completa a uma carteira.
 
-Saiba mais sobre adquirir GRT na Coinbase [aqui](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
 
 ### Binance
 
 Este é um guia passo a passo para comprar GRT na Binance.
 
-1. Crie uma conta na [Binance](https://www.binance.com/en).
+1. Go to [Binance](https://www.binance.com/en) and create an account.
 2. Quando tiver criado uma conta, precisará verificar a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este é um processo comum em todas as exchanges de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, poderá comprar GRT no botão "Comprar Agora", no canto superior direito da página.
 4. O botão levará-lhe a uma página onde pode selecionar a moeda que deseja comprar. Selecione GRT.
@@ -127,27 +127,27 @@ Este é um guia passo a passo para comprar GRT na Binance.
 6. Selecione a quantia de GRT que deseja comprar.
 7. Verifique a sua compra e clique em "Comprar GRT".
 8. Confirme a sua compra, e logo o seu GRT aparecerá na sua Carteira Spot da Binance.
-9. Poderá sacar o GRT da sua conta para carteiras na sua posse, como no [MetaMask](https://metamask.io/).
-   - Para [sacar o GRT](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) e adicionar à sua carteira, adicione o endereço da sua carteira para a whitelist de saque.
+9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
    - Clique no botão "wallet", clique em "sacar", e selecione GRT.
    - Insira a quantia de GRT que deseja enviar, e o endereço da carteira na whitelist à qual quer enviar.
    - Clique em "Continuar" e confirme a sua transação.
 
-Saiba mais sobre adquirir GRT na Binance [aqui](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
 
 ### Uniswap
 
 Este é um guia passo a passo sobre como comprar GRT no Uniswap.
 
-1. Conecte a sua carteira à [Uniswap](https://app.uniswap.org/swap?chain=arbitrum).
+1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
 2. Selecione o token que quer trocar — no caso, ETH.
 3. Selecione o token pelo que quer trocar — no caso, GRT.
-   - Verifique se está a trocar para o token correto. O endereço do contrato inteligente na Arbitrum One é: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
 4. Insira a quantia de ETH que deseja trocar.
 5. Clique em "Swap".
 6. Confirme a transação na sua carteira e espere que a transação seja processada.
 
-Saiba mais sobre adquirir GRT na Uniswap [aqui](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
 
 ## Como adquirir Ether
 
@@ -157,7 +157,7 @@ Esta seção explicará como adquirir Ether (ETH) para pagar por taxas de transa
 
 Este é um guia passo a passo sobre como comprar ETH na Coinbase.
 
-1. Crie uma conta na [Coinbase](https://www.coinbase.com/).
+1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
 2. Quando tiver criado uma conta, verifique a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este processo é comum em todas as corretoras de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, compre ETH no botão "Comprar/Vender", no canto superior direito da página.
 4. Selecione a moeda que deseja comprar — no caso, ETH.
@@ -165,20 +165,20 @@ Este é um guia passo a passo sobre como comprar ETH na Coinbase.
 6. Insira a quantia de ETH que deseja comprar.
 7. Reveja a sua compra e clique em "Comprar ETH".
 8. Confirme a sua compra, e o ETH será adquirido com sucesso.
-9. Poderá transferir o ETH da sua conta na Coinbase a carteiras na sua posse, como no [MetaMask](https://metamask.io/).
+9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
    - Para transferir o ETH à sua carteira, clique no botão "Contas" no canto superior direito da página.
    - Clique em "Enviar", próximo à conta de ETH.
    - Insira a quantia de ETH que deseja enviar, e o endereço da carteira que a receberá.
    - Certifique-se que enviará ao endereço da sua carteira de Ethereum no Arbitrum One.
    - Clique em "Continuar" e confirme a sua transação.
 
-Saiba mais sobre adquirir ETH na Coinbase [aqui](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
 
 ### Binance
 
 Este é um guia passo a passo sobre como comprar ETH na Binance.
 
-1. Crie uma conta na [Binance](https://www.binance.com/en).
+1. Go to [Binance](https://www.binance.com/en) and create an account.
 2. Quando tiver criado uma conta, verifique a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este processo é comum em todas as corretoras de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, poderá comprar ETH no botão "Comprar/Vender", no banner da página principal.
 4. Selecione a moeda que deseja comprar — no caso, ETH.
@@ -186,29 +186,29 @@ Este é um guia passo a passo sobre como comprar ETH na Binance.
 6. Insira a quantia de ETH que deseja comprar.
 7. Reveja a sua compra e clique em "Comprar ETH".
 8. Confirme a sua compra, e o seu ETH aparecerá na sua Carteira Spot da Binance.
-9. Poderá sacar o ETH da sua conta para carteiras na sua posse, como no [MetaMask](https://metamask.io/).
+9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
    - Para sacar o ETH à sua carteira, adicione o endereço da sua carteira à whitelist de saques.
    - Clique no botão "wallet", clique em "sacar" (withdraw), e selecione ETH.
    - Insira a quantia de ETH que deseja enviar, e o endereço da carteira na whitelist à qual quer enviar.
    - Certifique-se que enviará ao endereço da sua carteira de Ethereum no Arbitrum One.
    - Clique em "Continuar" e confirme a sua transação.
 
-Saiba mais sobre adquirir ETH na Binance [aqui](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
 
 ## Perguntas Frequentes Sobre Cobranças
 
 ### De quantas queries precisarei?
 
-Não é necessário saber de quantos queries precisará com antecedência. O utilizador só será cobrado pelo que pode usar, e poderá sacar GRT da própria conta a qualquer hora.
+You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
 
 Recomendamos estimar mais queries do que necessário para que não precise encher o seu saldo com frequência. Uma boa estimativa para aplicativos pequenos ou médios é começar com 1 a 2 milhões de queries por mês e monitorar atenciosamente o uso nas primeiras semanas. Para aplicativos maiores, uma boa estimativa consiste em utilizar o número de visitas diárias ao seu site multiplicado ao número de queries que a sua página mais ativa faz ao abrir.
 
-Utilizadores noviços e preexistentes podem consultar a equipa de Desenvolvimento Comercial (BD) da Edge & Node para saber mais sobre uso antecipado.
+Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
 
 ### Posso sacar GRT do meu saldo de cobrança?
 
-Sim, sempre é possível sacar GRT do seu saldo de cobrança que já não tenha sido usado para queries. O contrato inteligente é projetado apenas para fazer bridge de GRT da mainnet Ethereum até a rede Arbitrum. Se quiser transferir o seu GRT do Arbitrum de volta à mainnet Ethereum, use a [bridge do Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161).
+Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
 
-### O que acontece se o meu saldo de cobrança esgotar? Receberei uma notificação?
+### What happens when my billing balance runs out? Will I get a warning?
 
 Serão enviadas várias notificações de email antes do seu saldo de cobrança ser esvaziado.

From be3bcdf07e3a647722a56d4de101c6e0f3b86876 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 9 Jan 2025 21:24:12 -0500
Subject: [PATCH 2412/3820] New translations billing.mdx (Portuguese)

---
 website/pages/pt/subgraphs/billing.mdx | 68 +++++++++++++-------------
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/website/pages/pt/subgraphs/billing.mdx b/website/pages/pt/subgraphs/billing.mdx
index 33de71abbce7..3e4334ceec1d 100644
--- a/website/pages/pt/subgraphs/billing.mdx
+++ b/website/pages/pt/subgraphs/billing.mdx
@@ -2,20 +2,20 @@
 title: Cobranças
 ---
 
-## Querying Plans
+## Planos de Query
 
 Há dois planos disponíveis para queries de subgraphs na Graph Network.
 
-- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+- **Plano Grátis**: Inclui 100.000 queries grátis por mês, com acesso ilimitado ao ambiente de testes do Subgraph Studio. O plano é feito para entusiastas, participantes de hackathons, e para quem tem projetos paralelos para experimentar o The Graph antes de escalar o seu dapp.
 
-- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+- **Plano de Crescimento**: Inclui tudo no Plano Grátis, com todos os queries após a cota de 100.000 mensais exigindo pagamentos com cartão de crédito ou GRT. Este plano é flexível o suficiente para cobrir equipes que estabeleceram dapps numa variedade de casos de uso.
 
 <VideoEmbed youtube="Nn771WagX2I" />
 
 ## Pagamentos de Queries com cartão de crédito
 
-- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
-  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+- Para configurar opções de pagamento no cartão, os utilizadores devem acessar o Subgraph Studio (https://thegraph.com/studio/)
+  1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
   2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página. Isto levará à página de seleção de carteira; lá, selecione a sua carteira e clique em "Connect".
   3. Escolha "atualizar plano" se está a atualizar do Plano Grátis, ou escolha "Gerir plano" se já adicionou GRT ao seu saldo de cobrança no passado. Depois, é possível estimar o número de queries para conseguir uma estimativa de preço, mas isto não é obrigatório.
   4. Para escolher um pagamento em cartão de crédito, escolha "Cartão de crédito" como o método de pagamento e preencha os campos. Quem já usou o Stripe antes poderá preencher os seus detalhes automaticamente com o recurso Link.
@@ -45,17 +45,17 @@ Para pagar por queries, é necessário ter GRT no Arbitrum. Veja algumas maneira
 
 - Também é possível adquirir GRT diretamente no Arbitrum via uma exchange descentralizada.
 
-> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+> Esta seção presume que já tens GRT na sua carteira, e que estás na rede Arbitrum. Caso não tenha GRT, veja como adquirir o token [aqui](#getting-grt).
 
 Quando fizeres bridge do GRT, será possível adicioná-lo ao seu saldo de cobranças.
 
 ### Depósitos de GRT com uma carteira
 
-1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
 2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página. Isto levará à página de seleção de carteira; lá, selecione a sua carteira e clique em "Connect".
 3. Selecione o botão "Manage" (Gerir) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
 4. Use o slider para estimar o número de queries que espera fazer mensalmente.
-   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+   - Para sugestões sobre o número de queries que deve usar, veja a nossa página de **Perguntas Frequentes**.
 5. Escolha "Criptomoedas". Atualmente, o GRT é a única criptomoeda aceita na Graph Network.
 6. Selecione o número de meses que deseja pagar antecipadamente.
    - Pagamentos antecipados não te comprometem a usos futuros. Você só será cobrado pelo que usa, e pode sacar o seu saldo a qualquer hora.
@@ -68,20 +68,20 @@ Quando fizeres bridge do GRT, será possível adicioná-lo ao seu saldo de cobra
 
 ### Saques de GRT com carteira
 
-1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
 2. Clique no botão "Connect Wallet" (Conectar Carteira) no canto superior direito da página, selecione a sua carteira e clique em "Connect".
-3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
+3. Clique o botão "Manage" (Preferências) no canto superior direito. Selecione "Withdraw GRT" (Sacar GRT) para abrir um painel lateral.
 4. Insira a quantia de GRT que quer sacar.
 5. Clique em 'Withdraw GRT' (Sacar GRT) para sacar o GRT do seu saldo. Assine a transação associada na sua carteira — isto custa gas. O GRT será enviado à sua carteira Arbitrum.
 6. Quando a transação for confirmada, verá o GRT sacado do seu saldo na sua carteira Arbitrum.
 
 ### Depósitos de GRT com uma carteira multisig
 
-1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
-2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
-3. Selecione o botão "Manage" (Gerir) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
+1. Vá para a [página de cobrança do Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
+2. Clique em "Connect Wallet" (Conectar Carteira) no canto superior direito, selecione a sua carteira e clique em "Connect" (Conectar). Se usar o Gnosis-Safe, poderá conectar a sua multisig além da sua carteira de assinatura. Depois, assine a mensagem associada. Isto não tem custo de gas.
+3. Selecione o botão "Manage" (Preferências) perto do canto superior direito. Utilizadores noviços verão uma opção para "Upgrade to Growth Plan" (Atualizar para o Plano de Crescimento), enquanto os frequentes devem clicar em "Deposit from wallet" (Depositar de carteira).
 4. Use o slider para estimar o número de queries que espera fazer mensalmente.
-   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
+   - Para sugestões sobre o número de queries que deve usar, veja a nossa página de **Perguntas Frequentes**.
 5. Escolha "Criptomoedas". Atualmente, o GRT é a única criptomoeda aceita na Graph Network.
 6. Selecione o número de meses que deseja pagar antecipadamente.
    - Pagamentos antecipados não te comprometem a usos futuros. Você só será cobrado pelo que usa, e pode sacar o seu saldo a qualquer hora.
@@ -99,7 +99,7 @@ Esta seção explicará como adquirir GRT para pagar taxas de query.
 
 Este é um guia passo a passo sobre como comprar GRT na Coinbase.
 
-1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+1. Crie uma conta na [Coinbase](https://www.coinbase.com/).
 2. Quando tiver criado uma conta, precisará verificar a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este é um processo comum em todas as exchanges de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, poderá comprar GRT no botão "Comprar/Vender", no canto superior direito da página.
 4. Selecione a moeda que deseja comprar — no caso, GRT.
@@ -107,19 +107,19 @@ Este é um guia passo a passo sobre como comprar GRT na Coinbase.
 6. Selecione a quantia de GRT que deseja comprar.
 7. Verifique a sua compra, e após verificar, clique em "Comprar GRT".
 8. Confirme a sua compra, e o GRT será comprado com sucesso.
-9. You can transfer the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
+9. Poderá transferir o GRT da sua conta a carteiras na sua posse, como no [MetaMask](https://metamask.io/).
    - Para transferir o GRT à sua carteira, clique no botão "Contas" no canto superior direito da página.
    - Clique em "Enviar", próximo à conta de GRT.
    - Insira a quantia de GRT que deseja enviar, e o endereço da carteira que a receberá.
    - Clique em "Continuar" e confirme a sua transação. Nota: para compras maiores, a Coinbase pode demorar de 7 a 10 dias antes de transferir a quantia completa a uma carteira.
 
-You can learn more about getting GRT on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+Saiba mais sobre adquirir GRT na Coinbase [aqui](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
 
 ### Binance
 
 Este é um guia passo a passo para comprar GRT na Binance.
 
-1. Go to [Binance](https://www.binance.com/en) and create an account.
+1. Crie uma conta na [Binance](https://www.binance.com/en/).
 2. Quando tiver criado uma conta, precisará verificar a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este é um processo comum em todas as exchanges de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, poderá comprar GRT no botão "Comprar Agora", no canto superior direito da página.
 4. O botão levará-lhe a uma página onde pode selecionar a moeda que deseja comprar. Selecione GRT.
@@ -127,27 +127,27 @@ Este é um guia passo a passo para comprar GRT na Binance.
 6. Selecione a quantia de GRT que deseja comprar.
 7. Verifique a sua compra e clique em "Comprar GRT".
 8. Confirme a sua compra, e logo o seu GRT aparecerá na sua Carteira Spot da Binance.
-9. You can withdraw the GRT from your account to your wallet such as [MetaMask](https://metamask.io/).
-   - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
+9. Poderá sacar o GRT da sua conta para carteiras na sua posse, como no [MetaMask](https://metamask.io/).
+   - Para [sacar o GRT](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) e adicionar à sua carteira, adicione o endereço da sua carteira para a whitelist de saque.
    - Clique no botão "wallet", clique em "sacar", e selecione GRT.
    - Insira a quantia de GRT que deseja enviar, e o endereço da carteira na whitelist à qual quer enviar.
    - Clique em "Continuar" e confirme a sua transação.
 
-You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+Saiba mais sobre adquirir GRT na Binance [aqui](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
 
 ### Uniswap
 
 Este é um guia passo a passo sobre como comprar GRT no Uniswap.
 
-1. Go to [Uniswap](https://app.uniswap.org/swap?chain=arbitrum) and connect your wallet.
+1. Conecte a sua carteira à [Uniswap](https://app.uniswap.org/swap?chain=arbitrum).
 2. Selecione o token que quer trocar — no caso, ETH.
 3. Selecione o token pelo que quer trocar — no caso, GRT.
-   - Make sure you're swapping for the correct token. The GRT smart contract address on Arbitrum One is: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+   - Verifique se está a trocar para o token correto. O endereço do contrato inteligente na Arbitrum One é: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
 4. Insira a quantia de ETH que deseja trocar.
 5. Clique em "Swap".
 6. Confirme a transação na sua carteira e espere que a transação seja processada.
 
-You can learn more about getting GRT on Uniswap [here](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
+Saiba mais sobre adquirir GRT na Uniswap [aqui](https://support.uniswap.org/hc/en-us/articles/8370549680909-How-to-Swap-Tokens-).
 
 ## Como adquirir Ether
 
@@ -157,7 +157,7 @@ Esta seção explicará como adquirir Ether (ETH) para pagar por taxas de transa
 
 Este é um guia passo a passo sobre como comprar ETH na Coinbase.
 
-1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
+1. Crie uma conta na [Coinbase](https://www.coinbase.com/).
 2. Quando tiver criado uma conta, verifique a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este processo é comum em todas as corretoras de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, compre ETH no botão "Comprar/Vender", no canto superior direito da página.
 4. Selecione a moeda que deseja comprar — no caso, ETH.
@@ -165,20 +165,20 @@ Este é um guia passo a passo sobre como comprar ETH na Coinbase.
 6. Insira a quantia de ETH que deseja comprar.
 7. Reveja a sua compra e clique em "Comprar ETH".
 8. Confirme a sua compra, e o ETH será adquirido com sucesso.
-9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
+9. Poderá transferir o ETH da sua conta na Coinbase a carteiras na sua posse, como no [MetaMask](https://metamask.io/).
    - Para transferir o ETH à sua carteira, clique no botão "Contas" no canto superior direito da página.
    - Clique em "Enviar", próximo à conta de ETH.
    - Insira a quantia de ETH que deseja enviar, e o endereço da carteira que a receberá.
    - Certifique-se que enviará ao endereço da sua carteira de Ethereum no Arbitrum One.
    - Clique em "Continuar" e confirme a sua transação.
 
-You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+Saiba mais sobre adquirir ETH na Coinbase [aqui](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
 
 ### Binance
 
 Este é um guia passo a passo sobre como comprar ETH na Binance.
 
-1. Go to [Binance](https://www.binance.com/en) and create an account.
+1. Crie uma conta na [Binance](https://www.binance.com/en/).
 2. Quando tiver criado uma conta, verifique a sua identidade através do processo KYC (sigla em inglês para "Conheça o Seu Cliente"). Este processo é comum em todas as corretoras de cripto, centralizadas ou custodiais.
 3. Após verificar a sua identidade, poderá comprar ETH no botão "Comprar/Vender", no banner da página principal.
 4. Selecione a moeda que deseja comprar — no caso, ETH.
@@ -186,29 +186,29 @@ Este é um guia passo a passo sobre como comprar ETH na Binance.
 6. Insira a quantia de ETH que deseja comprar.
 7. Reveja a sua compra e clique em "Comprar ETH".
 8. Confirme a sua compra, e o seu ETH aparecerá na sua Carteira Spot da Binance.
-9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
+9. Poderá sacar o ETH da sua conta para carteiras na sua posse, como no [MetaMask](https://metamask.io/).
    - Para sacar o ETH à sua carteira, adicione o endereço da sua carteira à whitelist de saques.
    - Clique no botão "wallet", clique em "sacar" (withdraw), e selecione ETH.
    - Insira a quantia de ETH que deseja enviar, e o endereço da carteira na whitelist à qual quer enviar.
    - Certifique-se que enviará ao endereço da sua carteira de Ethereum no Arbitrum One.
    - Clique em "Continuar" e confirme a sua transação.
 
-You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+Saiba mais sobre adquirir ETH na Binance [aqui](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
 
 ## Perguntas Frequentes Sobre Cobranças
 
 ### De quantas queries precisarei?
 
-You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+Não é necessário saber de quantos queries precisará com antecedência. O utilizador só será cobrado pelo que pode usar, e poderá sacar GRT da própria conta a qualquer hora.
 
 Recomendamos estimar mais queries do que necessário para que não precise encher o seu saldo com frequência. Uma boa estimativa para aplicativos pequenos ou médios é começar com 1 a 2 milhões de queries por mês e monitorar atenciosamente o uso nas primeiras semanas. Para aplicativos maiores, uma boa estimativa consiste em utilizar o número de visitas diárias ao seu site multiplicado ao número de queries que a sua página mais ativa faz ao abrir.
 
-Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+Utilizadores noviços e preexistentes podem consultar a equipa de Desenvolvimento Comercial (BD) da Edge & Node para saber mais sobre uso antecipado.
 
 ### Posso sacar GRT do meu saldo de cobrança?
 
-Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+Sim, sempre é possível sacar GRT do seu saldo de cobrança que já não tenha sido usado para queries. O contrato inteligente é projetado apenas para fazer bridge de GRT da mainnet Ethereum até a rede Arbitrum. Se quiser transferir o seu GRT do Arbitrum de volta à mainnet Ethereum, use a [bridge do Arbitrum](https://bridge.arbitrum.io/?l2ChainId=42161).
 
-### What happens when my billing balance runs out? Will I get a warning?
+### O que acontece se o meu saldo de cobrança esgotar? Receberei uma notificação?
 
 Serão enviadas várias notificações de email antes do seu saldo de cobrança ser esvaziado.

From 79a4daf5c8075d4c1745b34e21a4ac90337dcd78 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 11 Jan 2025 06:31:12 -0500
Subject: [PATCH 2413/3820] New translations curating.mdx (Portuguese)

---
 website/pages/pt/resources/roles/curating.mdx | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/pt/resources/roles/curating.mdx b/website/pages/pt/resources/roles/curating.mdx
index 80e9b490037f..b92c9cefd7df 100644
--- a/website/pages/pt/resources/roles/curating.mdx
+++ b/website/pages/pt/resources/roles/curating.mdx
@@ -8,31 +8,31 @@ Curadores são importantes para a economia descentralizada do The Graph. Eles ut
 
 Antes que consumidores possam indexar um subgraph, ele deve ser indexado. É aqui que entra a curadoria. Para que Indexadores ganhem taxas de query substanciais em subgraphs de qualidade, eles devem saber quais subgraphs indexar. Quando Curadores sinalizam um subgraph, isto diz aos Indexadores que um subgraph está em demanda e tem qualidade suficiente para ser indexado.
 
-Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+Os Curadores trazem eficiência à Graph Network, e a [sinalização](#how-to-signal) é o processo que curadores usam para avisar aos Indexadores que um subgraph é bom para indexar. Os Indexadores podem confiar no sinal de um Curador, porque ao sinalizar, os Curadores mintam uma ação de curadoria para o subgraph, o que concede aos Curadores uma porção das futuras taxas de query movidas pelo subgraph.
 
 Sinais de curador são representados como tokens ERC20 chamados de Ações de Curadoria do Graph (GCS). Quem quiser ganhar mais taxas de query devem sinalizar o seu GRT a subgraphs que apostam que gerará um fluxo forte de taxas á rede. Curadores não podem ser cortados por mau comportamento, mas há uma taxa de depósito em Curadores para desincentivar más decisões que possam ferir a integridade da rede. Curadores também ganharão menos taxas de query se curarem um subgraph de baixa qualidade, já que haverão menos queries a processar ou menos Indexadores para processá-las.
 
-The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+O [Indexador de Atualização do Nascer do Sol](/sunrise/#what-is-the-upgrade-indexer) garante a indexação de todos os subgraphs; sinalizar GRT em um subgraph específico atrairá mais Indexadores a ele. Este incentivo para Indexadores através da curadoria visa melhorar a qualidade do serviço de queries através da redução de latência e do aprimoramento da disponibilidade de rede.
 
 Ao sinalizar, Curadores podem decidir entre sinalizar numa versão específica do subgraph ou sinalizar com a automigração. Caso sinalizem com a automigração, as ações de um curador sempre serão atualizadas à versão mais recente publicada pelo programador. Se decidirem sinalizar numa versão específica, as ações sempre permanecerão nesta versão específica.
 
-If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+Se precisar de ajuda com a curadoria para melhorar a qualidade do serviço, peça ajuda à equipa da Edge Node em support@thegraph.zendesk.com e especifique os subgraphs com que precisa de assistência.
 
 Os indexadores podem achar subgraphs para indexar com base em sinais de curadoria que veem no Graph Explorer (imagem abaixo).
 
-![Explorer subgraphs](/img/explorer-subgraphs.png)
+![Subgraphs do Explorer](/img/explorer-subgraphs.png)
 
 ## Como Sinalizar
 
-Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+Na aba "Curator" (Curador) do Graph Explorer, os curadores podem sinalizar e tirar sinal de certos subgraphs baseados nas estatísticas de rede. [Clique aqui](/subgraphs/explorer/) para um passo-a-passo deste processo no Graph Explorer.
 
 Um curador pode escolher sinalizar uma versão específica de subgraph, ou pode automaticamente migrar o seu sinal à versão mais recente desse subgraph. Ambas estratégias são válidas, e vêm com as suas próprias vantagens e desvantagens.
 
-Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+Sinalizar numa versão específica serve muito mais quando um subgraph é usado por vários dApps. Um dApp pode precisar atualizar o subgraph regularmente com novos recursos; outro dApp pode preferir usar uma versão mais antiga, porém melhor testada. Na curadoria inicial, é incorrida uma taxa de 1%.
 
 Ter um sinal que migra automaticamente à build mais recente de um subgraph pode ser bom para garantir o acúmulo de taxas de consulta. Toda vez que cura, é incorrida uma taxa de 1% de curadoria. Também pagará uma taxa de 0.5% em toda migração. É recomendado que rogramadores de subgraphs evitem editar novas versões com frequência - eles devem pagar uma taxa de curadoria de 0.5% em todas as ações de curadoria auto-migradas.
 
-> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+> \*\*Nota: O primeiro endereço a sinalizar um subgraph particular é considerado o primeiro curador e deverá realizar tarefas muito mais intensivas em gas do que o resto dos curadores seguintes — porque o primeiro curador inicializa os tokens de ação de curadoria, inicializa o bonding curve, e também transfere tokens no proxy do Graph.
 
 ## Como Sacar o Seu GRT
 
@@ -47,8 +47,8 @@ Porém, é recomendado que curadores deixem o seu GRT no lugar, não apenas para
 ## Riscos
 
 1. O mercado de consulta é jovem por natureza no The Graph, e há sempre o risco do seu rendimento anual ser menor que o esperado devido às dinâmicas nascentes do mercado.
-2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+2. Taxa de Curadoria - Quando um curador sinaliza GRT em um subgraph, ele incorre uma taxa de curadoria de 1%, que é queimada.
+3. (Só para o Ethereum) Quando os curadores queimam as suas ações para sacar GRT, o valor das ações restantes em GRT é diminuído. Perceba que, em alguns casos, os curadores podem decidir queimar todas as suas ações <strong x-id="1">de uma vez só</strong>. Isto pode ser comum se um programador de dApp parar de atualizar/melhorar as versões do seu subgraph e fazer queries nele, ou se um subgraph falhar. Portanto, é possível que os curadores restantes só sacarão uma fração do seu GRT inicial. Para um papel de rede com um perfil de risco menor, veja <a href="/network/delegating">Delegantes</a>.
 4. Um subgraph pode falhar devido a um erro de código. Um subgraph falho não acumula taxas de consulta. Portanto, espere até o programador consertar o erro e lançar uma nova versão.
    - Caso se inscreva à versão mais recente de um subgraph, suas ações migrarão automaticamente a esta versão nova. Isto incorrerá uma taxa de curadoria de 0.5%.
    - Se sinalizou em um subgraph específico e ele falhou, deverá queimar as suas ações de curadoria manualmente. Será então possível sinalizar na nova versão do subgraph, o que incorre uma taxa de curadoria de 1%.
@@ -61,14 +61,14 @@ Ao sinalizar em um subgraph, ganhará parte de todas as taxas de query geradas p
 
 ### 2. Como decidir quais subgraphs são de qualidade alta para sinalizar?
 
-Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+Achar subgraphs de alta qualidade é uma tarefa complexa, mas o processo pode ser abordado de várias formas diferentes. Como Curador, procure subgraphs confiáveis que movem volumes de query. Um subgraph confiável pode ser valioso se for completo, preciso, e apoiar as necessidades de dados de um dApp. Um subgraph mal arquitetado pode precisar de revisões ou reedições, além de correr risco de falhar. É importante que os Curadores verifiquem a arquitetura ou código de um subgraph, para averiguar se ele é valioso. Portanto:
 
-- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
-- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+- Os curadores podem usar o seu conhecimento de uma rede para tentar adivinhar como um subgraph individual pode gerar um volume maior ou menor de queries no futuro
+- Os curadores também devem entender as métricas disponíveis através do Graph Explorer. Métricas como o volume de queries passados e a identidade do programador do subgraph podem ajudar a determinar se um subgraph vale ou não o sinal.
 
 ### 3. Qual o custo de atualizar um subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+Migrar as suas ações de curadoria a uma nova versão de subgraph incorre uma taxa de curadoria de 1%. Os curadores podem escolher se inscrever na versão mais nova de um subgraph. Quando ações de curadores são automigradas a uma nova versão, os Curadores também pagarão metade da taxa de curadoria, por ex., 0.5%, porque a atualização de subgraphs é uma ação on-chain que custa gas.
 
 ### 4. Com que frequência posso atualizar o meu subgraph?
 
@@ -76,7 +76,7 @@ Não atualize os seus subgraphs com frequência excessiva. Veja a questão acima
 
 ### 5. Posso vender as minhas ações de curadoria?
 
-Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+Ações de curadoria não podem ser "compradas" ou "vendidas" como outros tokens de ERC-20; apenas mintadas (criadas) ou queimadas (destruídas).
 
 Como um Curador no Arbitrum, é garantido que você receberá o GRT que depositou inicialmente (menos a taxa).
 

From 0435100983597a2363641179fe01f620fb4663e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 11 Jan 2025 06:31:14 -0500
Subject: [PATCH 2414/3820] New translations delegating.mdx (Portuguese)

---
 .../pages/pt/resources/roles/delegating.mdx   | 102 +++++++++---------
 1 file changed, 50 insertions(+), 52 deletions(-)

diff --git a/website/pages/pt/resources/roles/delegating.mdx b/website/pages/pt/resources/roles/delegating.mdx
index 44ef4ee4730b..07f6f0017059 100644
--- a/website/pages/pt/resources/roles/delegating.mdx
+++ b/website/pages/pt/resources/roles/delegating.mdx
@@ -2,23 +2,23 @@
 title: Delegação
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+Delegantes são participantes de rede que delegam (ou seja, fazem "stake" de) GRT a um Indexador ou mais. Eles:
 
-- They help secure the network without running a Graph Node themselves.
+- Ajudam a manter a rede segura sem operar um Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+- Ganham uma porção das taxas de query e recompensas de um Indexador ao delegar para ele.
 
-## How does this work?
+## Como isto funciona?
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+O número de queries que um Indexador pode processar depende do seu próprio stake, **o stake delegado**, e o preço cobrado pelo Indexador para cada query, portanto: quanto mais stakes forem delegados, mais queries um Indexador tem o potencial de processar.
 
 ## Guia do Delegante
 
-Learn how to be an effective Delegator in The Graph Network.
+Aprenda como ser um Delegante eficiente na The Graph Network.
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Os Delegantes dividem as receitas do protocolo junto a todos os Indexadores, com base no stake delegado — portanto, eles devem usar do melhor julgamento para escolher Indexadores.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+> Este guia não cobre passos como a configuração do MetaMask. A comunidade do Ethereum fornece um recurso compreensivo sobre carteiras [neste link](https://ethereum.org/en/wallets/).
 
 Há três secções neste guia:
 
@@ -34,86 +34,84 @@ Veja abaixo os riscos principais de ser um Delegante no protocolo.
 
 Os Delegantes não podem ser punidos por mau comportamento, mas há uma taxa sobre Delegantes, para desencorajar más decisões que possam ferir a integridade da rede.
 
-As a Delegator, it's important to understand the following:
+Como Delegante, é importante entender que:
 
-- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+- Haverá uma cobrança de 0,5% sempre que delegar. Ou seja, ao delegar 1000 GRT, 5 GRT serão queimados automaticamente.
 
-- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+- Por segurança, calcule o seu retorno potencial quando delegar para um Indexador. Por exemplo, pode-se calcular o número de dias até que tenha recuperado a taxa de 0,5% da sua delegação.
 
 ### O período de separação da delegação
 
 Se um Delegado quiser cancelar a sua delegação, seus tokens estarão sujeitos a um período de 28 dias sem transferência, e também não poderá ganhar quaisquer recompensas por este período.
 
-### Why is this important?
+### Qual a Importância Disto?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+Se escolher um Indexador que não é confiável ou não está a fazer um bom trabalho, a melhor opção é retirar a delegação. Ou seja, perderá muitas oportunidades de recompensa, o que pode ser tão duro quanto queimar GRT — portanto, recomendamos que escolha os seus Indexadores com cuidado.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
-  unbonding period._
+  ![Unbonding de delegação](/img/Delegation-Unbonding.png) _Perceba a taxa de 0,5% na Interface de Delegação, assim como o período de unbonding de 28 dias._
 </div>
 
 ### Como escolher um Indexador de confiança, com um pagamento justo para Delegantes
 
-In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+Para entender como escolher um Indexador confiável, entenda os Parâmetros de Delegação.
 
-#### Delegation Parameters
+#### Parâmetros de Delegação
 
-- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
-  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
-  - If it is set to 80%, as a Delegator, you will receive 20%.
+- **Porção da Recompensa de Indexação** — A porção da recompensa que vai para o Indexador.
+  - Se a porção for configurada para 100%, como Delegante, você receberá 0 recompensas de indexação.
+  - Se for configurada para 80%, o Delegante receberá 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
-  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+  ![Porção da Recompensa de Indexação](/img/Indexing-Reward-Cut.png) *O Indexador no topo está a dar 90% das recompensas aos Delegantes. O do meio dá 20%. O mais baixo dá ~83% aos Delegantes.*
 </div>
 
-- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+- **Porção da Taxa de Query** — Parecido com a Porção da Recompensa de Indexação, mas se aplica aos retornos nas taxas de query coletadas pelo Indexador.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+Para escolher o Indexador certo, considere:
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Recomendamos altamente que explore o [Discord do The Graph](https://discord.gg/graphprotocol) para determinar quais Indexadores tem as melhores reputações sociais e técnicas, e quais recompensam os Delegantes consistentemente.
+- Muitos Indexadores estão ativos no Discord, e estão dispostos a responder as suas perguntas.
+- Muitos deles já indexam há meses, e fazem o melhor para ajudar os Delegantes a ganharem um bom retorno, já que isto melhora a saúde e o sucesso da rede.
 
-## Calculating Delegators Expected Return
+## Como calcular o retorno esperado dos Delegantes
 
-A Delegator must consider the following factors to determine a return:
+Um Delegante deve considerar os seguintes fatores para determinar retorno:
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+- A habilidade de um Indexador em usar os tokens delegados a ele.
+  - Se um Indexador não estiver a alocar todos os tokens disponíveis, ele não está ganhando o retorno máximo que poderia receber, para si mesmo ou para os seus Delegantes.
+- Preste atenção nos primeiros dias da delegação.
+  - Um Indexador pode escolher fechar uma alocação e recolher recompensas entre 1 e 28 dias. Um Indexador também pode ter muitas recompensas que ainda precisa resgatar, deixando o seu total de recompensas baixo.
 
 ### Como considerar as porções das taxas de query e de indexação
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+Escolha um Indexador com transparência e honestidade sobre as suas configurações de Taxa de Query e Porção de Taxa de Indexação. Também observe o Tempo de Espera de Parâmetros para ver quanto buffer de tempo tens. Feito tudo isso, será fácil calcular a quantidade de recompensas que receberá.
 
-The formula is:
+A fórmula é:
 
-![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+![Imagem de Delegação 3](/img/Delegation-Reward-Formula.png)
 
 ### Como considerar o pool de delegação do Indexador
 
-Delegators should consider the proportion of the Delegation Pool they own.
+Os Delegantes devem considerar a proporção do Fundo (Pool) de Delegação que possuem.
 
-All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+Todas as recompensas de delegação são divididas igualmente, com um reequilíbrio do pool baseado na quantia depositada no pool pelo Delegante.
 
-This gives the Delegator a share of the pool:
+Isto dá ao Delegante uma porção do pool:
 
-![Share formula](/img/Share-Forumla.png)
+![Fórmula de ações](/img/Share-Forumla.png)
 
-> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+> A fórmula acima prova que um Indexador que oferece apenas 20% aos Delegantes fornece uma recompensa melhor que um Indexador que dá 90%. Basta fazer as contas para determinar a melhor recompensa.
 
 ### Como considerar a capacidade de delegação
 
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+Por fim, considere a capacidade da delegação. Atualmente, a Proporção de Delegação está em 16.
 
-#### Why does this matter?
+#### Qual a importância disso?
 
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+Se um Indexador stakeou 1.000.000 GRT, sua Capacidade de Delegação é 16.000.000 GRT de tokens delegados que pode usar no protocolo. Quaisquer tokens delegados acima desta quantia irão diluir todas as recompensas de Delegante.
 
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+Imagine que um Indexador tem 100.000.000 GRT delegados a ele, e a sua capacidade é de apenas 16.000.000 GRT. Efetivamente, 84.000.000 tokens GRT não estão em uso para ganhar tokens. E tanto os Delegantes quanto os Indexadores ganham muito menos recompensas do que deveriam.
 
 Assim, um Delegante deve sempre considerar a Capacidade de Delegação de um Indexador, e levá-la em conta ao tomar decisões.
 
@@ -123,19 +121,19 @@ Assim, um Delegante deve sempre considerar a Capacidade de Delegação de um Ind
 
 1. Quando eu tento delegar a minha transação no MetaMask, ela aparece como "Pendente" ou "Na Fila" por mais tempo que o esperado. O que devo fazer?
 
-At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+Às vezes, tentativas de delegar a Indexadores via MetaMask podem falhar e deixar tentativas de transação "Pendentes" ou "Em Fila" por períodos prolongados.
 
 #### Exemplo
 
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+Vamos supor que você tente delegar com uma taxa de gas insuficiente, relativa aos preços atuais.
 
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+- Esta ação pode fazer com que a tentativa de transação fique "Pending" ("Pendente") na sua carteira do MetaMask por 15+ minutos. Quando isto acontecer, dá para tentar fazer mais transações, mas essas só serão processadas até a transação inicial ser minada, porque as transações para um endereço devem ser processadas em ordem.
+- Nesses casos, estas transações podem ser canceladas no MetaMask, mas as tentativas acumularão taxas de gas, sem garantia que quaisquer tentativas a seguir tenham algum sucesso.
 
-A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+Uma solução mais simples para este bug é a reinicialização do navegador (por ex., "abort:restart" na barra de endereço), o que cancelará todas as tentativas anteriores sem subtrair gas da carteira. Vários utilizadores que encontraram este problema relataram sucesso nas transações após reiniciar o seu navegador e tentar delegar.
 
-## Video Guide
+## Guia em Vídeo
 
-This video guide reviews this page while interacting with the UI.
+Esse guia em vídeo recapitula esta página ao mesmo tempo em que interage com a interface.
 
 <VideoEmbed youtube="2G7S2gdURdc" />

From 0faccac76cf5ace64715b0b36d6b0ffa91c421ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 11 Jan 2025 06:31:15 -0500
Subject: [PATCH 2415/3820] New translations publishing-a-subgraph.mdx
 (Portuguese)

---
 .../subgraphs/developing/publishing/publishing-a-subgraph.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/pt/subgraphs/developing/publishing/publishing-a-subgraph.mdx
index b40bd3b0a3cb..966d8cb9e3dd 100644
--- a/website/pages/pt/subgraphs/developing/publishing/publishing-a-subgraph.mdx
+++ b/website/pages/pt/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -81,7 +81,7 @@ Ao sinalizar, Curadores podem decidir entre sinalizar numa versão específica d
 
 Os indexadores podem achar subgraphs para indexar com base em sinais de curadoria que veem no Graph Explorer.
 
-![Explorer subgraphs](/img/explorer-subgraphs.png)
+![Subgraphs do Explorer](/img/explorer-subgraphs.png)
 
 O Subgraph Studio lhe permite adicionar sinais ao seu subgraph ao adicionar GRT ao pool de curadoria na mesma transação em que são publicados.
 

From b11fe872d39a02c551a1add61e7654441d0876c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 11 Jan 2025 06:31:16 -0500
Subject: [PATCH 2416/3820] New translations explorer.mdx (Portuguese)

---
 website/pages/pt/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs/explorer.mdx b/website/pages/pt/subgraphs/explorer.mdx
index ed92cd1a8712..776be30a50a3 100644
--- a/website/pages/pt/subgraphs/explorer.mdx
+++ b/website/pages/pt/subgraphs/explorer.mdx
@@ -6,7 +6,7 @@ Learn about The Graph Explorer and access the world of subgraphs and network dat
 
 Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
 
-## Video Guide
+## Guia em Vídeo
 
 For a general overview of Graph Explorer, check out the video below:
 

From decbfa3953097c625607a2f6f0826341c46c83b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 12 Jan 2025 13:01:22 -0500
Subject: [PATCH 2417/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index e3c31e6563ee..1a2c5de85e70 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -1,5 +1,5 @@
 ---
-title: Indexing Overview
+title: Vue d’ensemble de l’indexation
 ---
 
 Les indexeurs sont des opérateurs de nœuds dans The Graph Network qui mettent en jeu des jetons Graph (GRT) afin de fournir des services d'indexation et de traitement de requêtes. Les indexeurs perçoivent des frais de requête et des récompenses d'indexation pour leurs services. Ils perçoivent également des frais de requête qui sont réduits selon une fonction de remise exponentielle.

From c8147b497e0eeb55cd1b0ab0b5ba55401f76c735 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 12 Jan 2025 14:05:11 -0500
Subject: [PATCH 2418/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index 1a2c5de85e70..e2707122d505 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -20,11 +20,11 @@ La mise minimale pour un indexeur est actuellement fixée à 100 000 GRT.
 
 **Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
 
-**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+**Récompenses d'indexation** - Générées via une inflation annuelle de 3 % à l'échelle du protocole, les récompenses d'indexation sont distribuées aux Indexeurs qui indexent les déploiements de subgraph pour le réseau.
 
 ### Comment sont distribuées les récompenses d’indexation ?
 
-Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+Les récompenses d'indexation proviennent de l'inflation du protocole fixée à 3 % d'émission annuelle. Elles sont distribuées à travers les subgraphs en fonction de la proportion de tous les signaux de curation sur chacun, puis distribuées proportionnellement aux Indexeurs en fonction de leur participation allouée à ce subgraph. **Une allocation doit être fermée avec une preuve d'indexation (POI) valide, qui répond aux normes définies par la charte d'arbitrage pour être éligible aux récompenses**
 
 Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
 

From b233a09a061c6be31f8631d3ea120c603f2e635d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 12 Jan 2025 20:13:18 -0500
Subject: [PATCH 2419/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index e2707122d505..b5ce32c8c904 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -26,7 +26,7 @@ La mise minimale pour un indexeur est actuellement fixée à 100 000 GRT.
 
 Les récompenses d'indexation proviennent de l'inflation du protocole fixée à 3 % d'émission annuelle. Elles sont distribuées à travers les subgraphs en fonction de la proportion de tous les signaux de curation sur chacun, puis distribuées proportionnellement aux Indexeurs en fonction de leur participation allouée à ce subgraph. **Une allocation doit être fermée avec une preuve d'indexation (POI) valide, qui répond aux normes définies par la charte d'arbitrage pour être éligible aux récompenses**
 
-Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+De nombreux outils ont été créés par la communauté pour calculer les récompenses ; vous en trouverez une collection organisée dans la [collection Guides communautaires](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). Vous pouvez également trouver une liste à jour des outils dans les canaux #Delegators et #Indexers sur le [serveur Discord](https://discord.gg/graphprotocol). Nous proposons ici un [optimiseur d'allocation recommandé](https://github.com/graphprotocol/allocation-optimizer) intégré à la pile logicielle d'indexation.
 
 ### Qu'est-ce qu'une preuve d'indexation (POI) ?
 
@@ -38,7 +38,7 @@ Les allocations accumulent continuellement des récompenses pendant qu'elles son
 
 ### Les récompenses d’indexation en attente peuvent-elles être surveillées ?
 
-The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+Le contrat RewardsManager dispose d'une fonction en lecture seule [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) qui peut être utilisée pour vérifier les récompenses en attente pour une allocation spécifique.
 
 De nombreux tableaux de bord créés par la communauté incluent des valeurs de récompenses en attente et ils peuvent être facilement vérifiés manuellement en suivant ces étapes :
 

From 1e4704f55a4cec8e70cbe07c409a84fcb4132e49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 12 Jan 2025 21:15:50 -0500
Subject: [PATCH 2420/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 42 +++++++++++++-------------
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index b5ce32c8c904..0fd4e74ae207 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -42,7 +42,7 @@ Le contrat RewardsManager dispose d'une fonction en lecture seule [getRewards](h
 
 De nombreux tableaux de bord créés par la communauté incluent des valeurs de récompenses en attente et ils peuvent être facilement vérifiés manuellement en suivant ces étapes :
 
-1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+1. Interroger le [subgraph du mainnet] (https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) pour obtenir les identifiants de toutes les allocations actives :
 
 ```graphql
 query indexerAllocations {
@@ -58,28 +58,28 @@ query indexerAllocations {
 }
 ```
 
-Use Etherscan to call `getRewards()`:
+Utilisez Etherscan pour appeler la fonction `getRewards()` :
 
-- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+- Naviguer vers l'[interface Etherscan du contrat Rewards](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
 
 <!---->
 
-- To call `getRewards()`:
-  - Expand the **9. getRewards** dropdown.
-  - Enter the **allocationID** in the input.
-  - Click the **Query** button.
+- Pour appeler la fonction `getRewards()` :
+  - Développez la liste déroulante **9. getRewards**.
+  - Saisissez l'**allocationID** dans le champ de saisie.
+  - Cliquez sur le bouton **Query**.
 
 ### Que sont les litiges et où puis-je les consulter ?
 
 Les requêtes et les allocations de l'indexeur peuvent toutes deux être contestées sur The Graph pendant la période de contestation. Le délai de contestation varie selon le type de litige. Les requêtes/attestations ont une fenêtre de contestation de 7 époques, tandis que les allocations ont 56 époques. Passé ces délais, aucun litige ne peut être ouvert ni contre les attributions ni contre les requêtes. Lorsqu'un litige est ouvert, une caution d'un minimum de 10 000 GRT est exigée par les pêcheurs, qui sera verrouillée jusqu'à ce que le litige soit finalisé et qu'une résolution soit trouvée. Les pêcheurs sont tous les participants au réseau qui ouvrent des différends.
 
-Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+Les litiges ont **trois** issues possibles, tout comme le dépôt des Fishermen.
 
 - Si la contestation est rejetée, le GRT déposé par les Pêcheurs sera brûlé, et l'Indexeur contesté ne sera pas sabré.
 - Si le différend est réglé par un match nul, la caution du pêcheur sera restituée et l'indexeur contesté ne sera pas réduit.
 - Si la contestation est acceptée, le GRT déposé par les Pêcheurs sera restitué, l'Indexeur contesté sera réduit et les Pêcheurs gagneront 50% du GRT réduit.
 
-Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+Les litiges peuvent être consultés dans l'interface utilisateur sur la page de profil d'un Indexeur sous l'onglet « litiges ».
 
 ### Que sont les remises sur les frais de requête et quand sont-elles distribuées ?
 
@@ -168,9 +168,9 @@ Remarque : Pour prendre en charge la mise à l'échelle agile, il est recommand
 
 #### Agent indexeur
 
-| Port | Purpose                      | Routes | CLI Argument               | Environment Variable                    |
-| ---- | ---------------------------- | ------ | -------------------------- | --------------------------------------- |
-| 8000 | API de gestion des indexeurs | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+| Port | Objectif                     | Routes | Argument du CLI              | Variable d'environment                    |
+| ---- | ---------------------------- | ------ | ---------------------------- | ----------------------------------------- |
+| 8000 | API de gestion des indexeurs | /      | \--indexer-management-port   | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT`   |
 
 ### Configurer l'infrastructure du serveur à l'aide de Terraform sur Google Cloud
 
@@ -184,9 +184,9 @@ Remarque : Pour prendre en charge la mise à l'échelle agile, il est recommand
 
 #### Créer un projet Google Cloud
 
-- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+- Cloner ou naviguer vers le [dépôt de l'Indexeur](https://github.com/graphprotocol/indexer).
 
-- Navigate to the `./terraform` directory, this is where all commands should be executed.
+- Naviguez jusqu'au répertoire `./terraform`, c'est là que toutes les commandes doivent être exécutées.
 
 ```sh
 cd terraform
@@ -295,7 +295,7 @@ kubectl config use-context $(kubectl config get-contexts --output='name'
 
 - Read through all the files in `$dir` and adjust any values as indicated in the comments.
 
-Deploy all resources with `kubectl apply -k $dir`.
+Déployer toutes les ressources avec `kubectl apply -k $dir`.
 
 ### Nœud de The Graph
 
@@ -327,7 +327,7 @@ pg_ctl -D .postgres -l logfile start
 createdb graph-node
 ```
 
-2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+2. Clonez le repo [Graph Node](https://github.com/graphprotocol/graph-node) et compilez les sources en lançant `cargo build`
 
 3. Maintenant que toutes les dépendances sont configurées, démarrez le Graph Node :
 
@@ -733,11 +733,11 @@ default => 0.1 * $SYSTEM_LOAD;
 
 Exemple de calcul des coûts de requête utilisant le modèle ci-dessus :
 
-| Query                                                                        | Price   |
-| ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| Requête                                                                        | Prix    |
+| ------------------------------------------------------------------------------ | ------- |
+| { pairs(skip: 5000) { id } }                                                   | 0.5 GRT |
+| { tokens { symbol } }                                                          | 0.1 GRT |
+| { pairs(skip: 5000) { id } tokens { symbol } }                                 | 0.6 GRT |
 
 #### Application du modèle de coût
 

From 709d117eeb39d15411d97e7f67d4186c3d637bbf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 12 Jan 2025 21:15:51 -0500
Subject: [PATCH 2421/3820] New translations tap.mdx (French)

---
 website/pages/fr/indexing/tap.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/indexing/tap.mdx b/website/pages/fr/indexing/tap.mdx
index 773ddf96163a..fd4c8b214b2f 100644
--- a/website/pages/fr/indexing/tap.mdx
+++ b/website/pages/fr/indexing/tap.mdx
@@ -1,5 +1,5 @@
 ---
-title: TAP Migration Guide
+title: Guide de migration TAP
 ---
 
 Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
@@ -43,9 +43,9 @@ As long as you run `tap-agent` and `indexer-agent`, everything will be executed
 
 ## Blockchain Addresses
 
-### Contracts
+### Contrats
 
-| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| Contrat             | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
 | ------------------- | -------------------------------------------- | -------------------------------------------- |
 | TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
 | AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |

From 1d279539b3fd58e802882d2e71f43259919088e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 12 Jan 2025 21:15:52 -0500
Subject: [PATCH 2422/3820] New translations graph-node.mdx (French)

---
 website/pages/fr/indexing/tooling/graph-node.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/indexing/tooling/graph-node.mdx b/website/pages/fr/indexing/tooling/graph-node.mdx
index ed5733e07d22..1078990e9f46 100644
--- a/website/pages/fr/indexing/tooling/graph-node.mdx
+++ b/website/pages/fr/indexing/tooling/graph-node.mdx
@@ -58,7 +58,7 @@ pg_ctl -D .postgres -l logfile start
 createdb graph-node
 ```
 
-2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+2. Clonez le repo [Graph Node](https://github.com/graphprotocol/graph-node) et compilez les sources en lançant `cargo build`
 
 3. Maintenant que toutes les dépendances sont configurées, démarrez le Graph Node :
 

From b2dbb2babea964439c7f7c1dccf7214c674754ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:25 -0500
Subject: [PATCH 2423/3820] New translations substreams-powered-subgraphs.mdx
 (German)

---
 .../de/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/de/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/de/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/de/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 41650656b439cbb42e8010298ae69f8dec371dcc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:26 -0500
Subject: [PATCH 2424/3820] New translations substreams-powered-subgraphs.mdx
 (Portuguese)

---
 .../pt/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/pt/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 2a784be23286..f91c1ced2c16 100644
--- a/website/pages/pt/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/pt/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Subgraphs movidos a Substreams introduzem um novo `tipo` de fonte de dados, "sub
 
 Esta fonte de dados deve especificar a rede indexada, o pacote de Substreams ('spkg') como um local relativo de arquivos, e o módulo dentro daquele pacote de Substreams que produz mudanças de entidade compatíveis com o subgraph (neste caso 'map_entity_changes', do pacote de Substreams acima). O mapeamento é especificado, mas apenas identifica o tipo de mapeamento ("substreams/graph-entities") e a apiVersion.
 
-> Atualmente, o Subgraph Studio e a Graph Network apoiam subgraphs movidos a Substreams que indexam a `mainnet` (Mainnet do Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From baebc12d254af032aad337e264d936a582e9282f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:27 -0500
Subject: [PATCH 2425/3820] New translations substreams-powered-subgraphs.mdx
 (Romanian)

---
 .../ro/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ro/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/ro/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/ro/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 9704189733ff6c6bf51f662da59301cf719a8d1e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:28 -0500
Subject: [PATCH 2426/3820] New translations substreams-powered-subgraphs.mdx
 (French)

---
 .../fr/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/fr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 8b5249d6f202..5c632b187fb3 100644
--- a/website/pages/fr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/fr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Les subgraphs alimentés par Substreams introduisent un nouveau type de source d
 
 Cette source de données doit spécifier le réseau indexé, le paquet Substreams (`spkg`) en tant qu'emplacement de fichier relatif, et le module au sein de ce paquet Substreams qui produit des changements d'entités compatibles avec le subgraph (dans ce cas, `map_entity_changes`, du paquet Substreams ci-dessus). Le mapping est spécifié, mais identifie simplement le type de mapping ("substreams/graph-entities") et l'apiVersion.
 
-> Actuellement, Subgraph Studio et The Graph Network prennent en charge les subgraphs alimentés par Substreams qui indexent le `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 986957394aa3ba353707514a317bb86c29ef3858 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:30 -0500
Subject: [PATCH 2427/3820] New translations substreams-powered-subgraphs.mdx
 (Spanish)

---
 .../es/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/es/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/es/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/es/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From bdc792e18b307c76dd8268860f55c07c72aa09f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:31 -0500
Subject: [PATCH 2428/3820] New translations substreams-powered-subgraphs.mdx
 (Arabic)

---
 .../ar/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ar/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/ar/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/ar/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 7c0b3d9442e558b8084855ce0cf5eed9d97adcbd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:32 -0500
Subject: [PATCH 2429/3820] New translations substreams-powered-subgraphs.mdx
 (Czech)

---
 .../cs/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/cs/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 6136aca4a52e..ef95af07569f 100644
--- a/website/pages/cs/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/cs/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Subgrafy poháněné substreamy představují nový typ datového zdroje s názv
 
 Tento zdroj dat musí specifikovat indexovanou síť, balíček Substreams (`spkg`) jako relativní umístění souboru a modul v rámci tohoto balíčku Substreams, který vytváří změny entit kompatibilní s podgrafem (v tomto případě `map_entity_changes` z výše uvedeného balíčku Substreams). Mapování je specifikováno, ale jednoduše identifikuje druh mapování ("substreams/graph-entities") a apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 5d7ca8241a67b4b83fc73d034fdff83fd148df96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:33 -0500
Subject: [PATCH 2430/3820] New translations substreams-powered-subgraphs.mdx
 (Italian)

---
 .../it/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/it/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/it/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/it/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 30eb661d8d01b6880efaf03ac2583939acf16e6b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:34 -0500
Subject: [PATCH 2431/3820] New translations substreams-powered-subgraphs.mdx
 (Japanese)

---
 .../ja/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ja/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index fd61c3750c20..b0c3bdaf4447 100644
--- a/website/pages/ja/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/ja/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -157,7 +157,7 @@ yarn substreams:package # packages the substreams in a .spkg file
 
 このデータ ソースは、インデックス付きネットワーク、相対的なファイルの場所としての Substreams パッケージ (`spkg`)、およびサブグラフ互換のエンティティ変更を生成するその Substreams パッケージ内のモジュール (この場合は、上記の Substreams パッケージからの `map_entity_changes`) を指定する必要があります。マッピングは指定されていますが、単にマッピングの種類 (「サブストリーム/グラフ エンティティ」) と apiVersion を識別するだけです。
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From cf4a0b139669cfc9abd31748c9cfc4917d25f42a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:35 -0500
Subject: [PATCH 2432/3820] New translations substreams-powered-subgraphs.mdx
 (Korean)

---
 .../ko/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ko/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/ko/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/ko/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From fbe3d595634717f2788947640b2c6c6b065f4d22 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:37 -0500
Subject: [PATCH 2433/3820] New translations substreams-powered-subgraphs.mdx
 (Dutch)

---
 .../nl/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/nl/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/nl/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/nl/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 99f95485dff7977126e5320cc45206dd05d73082 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:38 -0500
Subject: [PATCH 2434/3820] New translations substreams-powered-subgraphs.mdx
 (Polish)

---
 .../pl/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/pl/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/pl/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/pl/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 410b9ba145d259cc2eff75b1070386c7bffe6d42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:39 -0500
Subject: [PATCH 2435/3820] New translations substreams-powered-subgraphs.mdx
 (Russian)

---
 .../ru/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ru/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 41a190869890..260e502908a7 100644
--- a/website/pages/ru/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/ru/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ yarn substreams:package # упаковывает субпотоки в файл
 
 В этом источнике данных должна быть указана индексированная сеть, пакет Substreams (`spkg`) в качестве относительного местоположения файла и модуль в этом пакете Substreams, который производит совместимые с субграфами изменения объектов (в данном случае `map_entity_changes` из пакета Substreams, указанного выше). Мэппинг указан, но просто идентифицирует вид мэппинга ("substreams/graph-entities") и apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From e5d1deb530a714a77563e3d151906656e51f51d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:40 -0500
Subject: [PATCH 2436/3820] New translations substreams-powered-subgraphs.mdx
 (Swedish)

---
 .../sv/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/sv/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index c9f70597e367..5c5b03096738 100644
--- a/website/pages/sv/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/sv/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-drivna subgrafer introducerar en ny "typ" av datakälla, "substreams"
 
 Denna datakälla måste ange det indexerade nätverket, Substreams-paketet ("spkg") som en relativ filplats och modulen i det Substreams-paketet som producerar subgrafkompatibla entitetsändringar (i detta fall "map_entity_changes", från Substreams-paketet ovan). Mappningen är specificerad, men identifierar helt enkelt mappningstypen ("substreams/graph-entities") och apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From c4e9f0086a2a57023bd04d70c46e33248f10a99b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:41 -0500
Subject: [PATCH 2437/3820] New translations substreams-powered-subgraphs.mdx
 (Turkish)

---
 .../tr/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/tr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 60cd07a2973d..5fa97e92eec4 100644
--- a/website/pages/tr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/tr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams destekli subgraphlar yeni bir veri kaynağı türü('kind') olan "sub
 
 Bu veri kaynağı indekslenen ağı, Substreams paketi (`spkg`) olarak ilgili bir dosya konumu ve Substreams paketinin subgraph uyumlu varlık değişiklikleri üreten modülü belirtmelidir (bu durumda yukarıdaki Substreams paketinden `map_entity_changes`). Eşleştirme belirtilmiştir, fakat yalnızca eşleştirme türünü ("substreams/graph-entities") ve apiVersion'ı tanımlar.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 79f9d4d80913f05bcd78dc3b568eca89715e0459 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:42 -0500
Subject: [PATCH 2438/3820] New translations substreams-powered-subgraphs.mdx
 (Ukrainian)

---
 .../uk/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/uk/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/uk/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/uk/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 7fe20fdab5621387f08aa18c172193297e4f72a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:43 -0500
Subject: [PATCH 2439/3820] New translations substreams-powered-subgraphs.mdx
 (Chinese Simplified)

---
 .../zh/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/zh/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 35b5d34c9bb2..39705720d1fc 100644
--- a/website/pages/zh/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/zh/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs引入了一种名为"substreams"的新型数据源
 
 基于Substreams的子图引入了一种新的数据源类型，"substreams"。这样的子图只能有一个数据源。该数据源必须指定Substreams网络、Substreams包（spkg）的相对文件位置，以及该Substreams包中生成子图兼容实体变更的模块（在本例中为map_entity_changes）。映射是指定的，但只是标识了映射类型（"substreams/graph-entities"）和apiVersion。
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 481e0b2676fc44ccdfb9fda9529118bb8a0f0605 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:44 -0500
Subject: [PATCH 2440/3820] New translations substreams-powered-subgraphs.mdx
 (Urdu (Pakistan))

---
 .../ur/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/ur/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 9643d1f73bf5..556a4d91604a 100644
--- a/website/pages/ur/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/ur/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ yarn substreams:package # سب اسٹریمز کو .spkg فائل میں پیک
 
 اس ڈیٹا سورس کو انڈیکسڈ نیٹ ورک، سب اسٹریم پیکیج (`spkg`) کو متعلقہ فائل لوکیشن کے طور پر اور اس سب اسٹریم پیکیج کے اندر موجود ماڈیول کی وضاحت کرنی چاہیے جو سب سٹریمز سے مطابقت رکھنے والی ہستی کی تبدیلیاں (اس صورت میں `map_entity_changes`، اوپر سب اسٹریمز پیکیج سے)۔ میپنگ کی وضاحت کی گئی ہے، لیکن صرف میپنگ کی قسم ("substreams/graph-entities") اور apiVersion کی شناخت کرتا ہے.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 1bf7c086d9e56302586d8be9b4b31a21d94d493c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:45 -0500
Subject: [PATCH 2441/3820] New translations substreams-powered-subgraphs.mdx
 (Vietnamese)

---
 .../vi/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/vi/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/vi/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/vi/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 2a834ad6072c082a34b49bf13e1b6bc80944a26a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:46 -0500
Subject: [PATCH 2442/3820] New translations substreams-powered-subgraphs.mdx
 (Marathi)

---
 .../mr/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/mr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/mr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/mr/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 5990790f3b2c7fac91d3c50d33f7551b898f2a33 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:47 -0500
Subject: [PATCH 2443/3820] New translations substreams-powered-subgraphs.mdx
 (Hindi)

---
 .../hi/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/hi/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/hi/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/hi/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From 6df299b2dc3dca35a5189b9a7c8e8cee59b499a8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 15:01:49 -0500
Subject: [PATCH 2444/3820] New translations substreams-powered-subgraphs.mdx
 (Swahili)

---
 .../sw/subgraphs/cookbook/substreams-powered-subgraphs.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/subgraphs/cookbook/substreams-powered-subgraphs.mdx b/website/pages/sw/subgraphs/cookbook/substreams-powered-subgraphs.mdx
index 84e1b0adfd3b..ef6f19df427b 100644
--- a/website/pages/sw/subgraphs/cookbook/substreams-powered-subgraphs.mdx
+++ b/website/pages/sw/subgraphs/cookbook/substreams-powered-subgraphs.mdx
@@ -158,7 +158,7 @@ Substreams-powered subgraphs introduce a new `kind` of data source, "substreams"
 
 This data source must specify the indexed network, the Substreams package (`spkg`) as a relative file location, and the module within that Substreams package which produces subgraph-compatible entity changes (in this case `map_entity_changes`, from the Substreams package above). The mapping is specified, but simply identifies the mapping kind ("substreams/graph-entities") and the apiVersion.
 
-> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs which index `mainnet` (Mainnet Ethereum).
+> Currently, Subgraph Studio and The Graph Network support Substreams-powered subgraphs. Review [supported networks](/supported-networks/) for additional details.
 
 ```yaml
 specVersion: 0.0.4

From fee41a4e6d0da59a958d003584887ea385b19397 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:03:47 -0500
Subject: [PATCH 2445/3820] New translations explorer.mdx (German)

---
 website/pages/de/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/de/subgraphs/explorer.mdx b/website/pages/de/subgraphs/explorer.mdx
index 433821560d85..94bf8f0c481d 100644
--- a/website/pages/de/subgraphs/explorer.mdx
+++ b/website/pages/de/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Overview
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgraphs
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Participants
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexers
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexers
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curators
+#### 2. Curators
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegators
+#### 3. Delegators
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - The number of Indexers a Delegator is delegating towards
-- A Delegator’s original delegation
+- A Delegator's original delegation
 - The rewards they have accumulated but have not withdrawn from the protocol
 - The realized rewards they withdrew from the protocol
 - Total amount of GRT they have currently in the protocol
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Network
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Overview
+#### Overview
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epochs
+#### Epochs
 
 In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
 
@@ -222,7 +234,7 @@ Within this tab, you’ll find an overview of:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Your Profile Settings
+### Your Profile Settings
 
 Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
 
@@ -234,3 +246,11 @@ Within your user profile, you’ll be able to manage your personal profile detai
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Additional Resources
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 3363823dbb807bd564c4a637dd16fb57da71bbf4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:03:50 -0500
Subject: [PATCH 2446/3820] New translations explorer.mdx (Portuguese)

---
 website/pages/pt/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/pt/subgraphs/explorer.mdx b/website/pages/pt/subgraphs/explorer.mdx
index 776be30a50a3..29a699d08a95 100644
--- a/website/pages/pt/subgraphs/explorer.mdx
+++ b/website/pages/pt/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Visão geral
 
-## Guia em Vídeo
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgraphs
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Participantes
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexadores
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexadores
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curadores
+#### 2. Curadores
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegantes
+#### 3. Delegantes
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - O número de Indexadores aos quais um Delegante delega
-- A delegação original de um Delegante
+- A Delegator's original delegation
 - As recompensas que acumularam, mas não sacaram, do protocolo
 - As recompensas realizadas que sacaram do protocolo
 - A quantidade total de GRT que têm no protocolo no momento
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Rede
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Visão geral
+#### Visão geral
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epochs
+#### Epochs
 
 Na seção de Epochs, pode analisar, numa base por epoch, métricas como:
 
@@ -222,7 +234,7 @@ Dentro desta aba está um resumo de:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Configurações do Seu Perfil
+### Configurações do Seu Perfil
 
 Dentro do seu perfil de utilizador, poderá configurar os detalhes do seu perfil pessoal (como a configuração de um nome ENS). Se fores um Indexador, terá ainda mais acesso às configurações no alcance dos seus dedos. Em seu perfil de utilizador, poderá configurar os seus parâmetros de delegação e os seus operadores.
 
@@ -234,3 +246,11 @@ Dentro do seu perfil de utilizador, poderá configurar os detalhes do seu perfil
 Como o seu portal oficial no mundo dos dados descentralizados, o Graph Explorer permite-lhe tomar uma variedade de ações, independente do seu papel na rede. Pode acessar as suas configurações do perfil ao abrir o menu próximo ao seu endereço, e depois, clicar no botão de Configurações.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Outros Recursos
+
+### Guia em Vídeo
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From fede9d31b3079500714ba82a46207eb276ab2c93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:03:51 -0500
Subject: [PATCH 2447/3820] New translations introduction.mdx (Portuguese)

---
 .../pt/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/pt/subgraphs/querying/introduction.mdx b/website/pages/pt/subgraphs/querying/introduction.mdx
index b21639a155ef..e1ddf89e2523 100644
--- a/website/pages/pt/subgraphs/querying/introduction.mdx
+++ b/website/pages/pt/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Queries no The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Nota: Se encontrar erros 405 com um pedido GET ao URL do Graph Explorer, use um pedido POST.
+## Visão geral
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Cada subgraph publicado à Graph Network tem um URL singular de query no Graph Explorer para fazer queries diretos que podem ser encontrados ao navegar até a página de detalhes do subgraph e clicar no botão "Query" no canto superior direito.
+## Especificações
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Nota: Se encontrar erros 405 com um pedido GET ao URL do Graph Explorer, use um pedido POST.
+
+### Outros Recursos
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From c5714fa99d53746b84a1f1e395c64ceb514925dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:03:55 -0500
Subject: [PATCH 2448/3820] New translations explorer.mdx (Romanian)

---
 website/pages/ro/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/ro/subgraphs/explorer.mdx b/website/pages/ro/subgraphs/explorer.mdx
index 7e1bac046e02..94bf8f0c481d 100644
--- a/website/pages/ro/subgraphs/explorer.mdx
+++ b/website/pages/ro/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Overview
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgrafuri
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Participants
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexers
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexers
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curators
+#### 2. Curators
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegators
+#### 3. Delegators
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - The number of Indexers a Delegator is delegating towards
-- A Delegator’s original delegation
+- A Delegator's original delegation
 - The rewards they have accumulated but have not withdrawn from the protocol
 - The realized rewards they withdrew from the protocol
 - Total amount of GRT they have currently in the protocol
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Network
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Overview
+#### Overview
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epochs
+#### Epochs
 
 In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
 
@@ -222,7 +234,7 @@ Within this tab, you’ll find an overview of:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Your Profile Settings
+### Your Profile Settings
 
 Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
 
@@ -234,3 +246,11 @@ Within your user profile, you’ll be able to manage your personal profile detai
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Additional Resources
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From b9a10304ccfea1ad9baff99f73bedf219c0167a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:03:56 -0500
Subject: [PATCH 2449/3820] New translations introduction.mdx (Romanian)

---
 .../ro/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/ro/subgraphs/querying/introduction.mdx b/website/pages/ro/subgraphs/querying/introduction.mdx
index 4a0a6e29f4c4..f8da55d13b70 100644
--- a/website/pages/ro/subgraphs/querying/introduction.mdx
+++ b/website/pages/ro/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Querying The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Overview
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Additional Resources
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 5aff37647999c955b9e4df759e280d005d53c64e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:03:58 -0500
Subject: [PATCH 2450/3820] New translations explorer.mdx (French)

---
 website/pages/fr/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/fr/subgraphs/explorer.mdx b/website/pages/fr/subgraphs/explorer.mdx
index 7cf76051a228..e21e0bb08603 100644
--- a/website/pages/fr/subgraphs/explorer.mdx
+++ b/website/pages/fr/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Découvrez Graph Explorer et accédez au monde des subgraphs et des données réseau.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer se compose de plusieurs parties où vous pouvez interagir avec d'autres développeurs de subgraphs, développeurs de dapps, Curateurs, Indexeurs et Délégateurs.
+## Aperçu
 
-## Guide Vidéo
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-Pour une vue d'ensemble de Graph Explorer, consultez la vidéo ci-dessous :
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgraphs
+### Subgraphs Page
 
-Après avoir terminé le déploiement et la publication de votre subgraph dans Subgraph Studio, cliquez sur l'onglet "subgraphs" en haut de la barre de navigation pour accéder aux éléments suivants :
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Vos propres subgraphs terminés
 - Les subgraphs publiés par d'autres
@@ -26,7 +26,8 @@ Lorsque vous cliquez sur un subgraph, vous pourrez faire ce qui suit :
 
 - Tester des requêtes dans le l'environnement de test et utiliser les détails du réseau pour prendre des décisions éclairées.
 - Signaler des GRT sur votre propre subgraph ou sur les subgraphs des autres pour informer les Indexeurs de son importance et de sa qualité.
-- Ceci est crucial car le signalement sur un subgraph l'incite à être indexé, ce qui signifie qu'il finira par apparaître sur le réseau pour servir des requêtes.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ Sur la page dédiée de chaque subgraph, vous pouvez faire ce qui suit :
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Participants
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-Cette section offre une vue d'ensemble de tous les "participants", ce qui inclut tous ceux qui participent au réseau, tels que les Indexeurs, les Délégateurs et les Curateurs.
+### Participants Page
 
-### 1. Indexeurs
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexeurs
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curateurs
+#### 2. Curateurs
 
 Les Curateurs analysent les subgraphs pour identifier ceux de la plus haute qualité. Une fois qu'un Curateur a trouvé un subgraph potentiellement de haute qualité, il peut le curer en le signalant sur sa courbe de liaison. Ce faisant, les Curateurs informent les Indexeurs des subgraphs de haute qualité qui doivent être indexés.
 
@@ -94,20 +106,20 @@ Dans le tableau des Curateurs ci-dessous, vous pouvez voir :
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Délégués
+#### 3. Délégués
 
 Les Délégateurs jouent un rôle clé dans le maintien de la sécurité et de la décentralisation de The Graph Network. Ils participent au réseau en déléguant (c'est-à-dire en "stakant") des jetons GRT à un ou plusieurs Indexeurs.
 
 - Sans Délégateurs, les Indexeurs sont moins susceptibles de gagner des récompenses et des frais importants. Par conséquent, les Indexeurs attirent les Délégateurs en leur offrant une partie de leurs récompenses d'indexation et de leurs frais de requête.
 - Les Délégateurs sélectionnent leurs Indexeurs selon divers critères, telles que les performances passées, les taux de récompense d'indexation et le partage des frais.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 Dans le tableau des Délégateurs, vous pouvez voir les Délégateurs actifs dans la communauté et les métriques importantes :
 
 - Le nombre d’indexeurs auxquels un délégant délègue
-- Délégation originale d’un délégant
+- A Delegator's original delegation
 - Les récompenses qu'ils ont accumulées mais qu'ils n'ont pas retirées du protocole
 - Les récompenses obtenues qu'ils ont retirées du protocole
 - Quantité totale de GRT qu'ils ont actuellement dans le protocole
@@ -115,11 +127,11 @@ Dans le tableau des Délégateurs, vous pouvez voir les Délégateurs actifs dan
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Réseau
+### Network Page
 
-Dans cette section, vous pouvez consulter les indicateurs clés de performance (KPI) globaux du réseau et passer en mode par époque (epoch) pour analyser plus en détail les métriques du réseau. Ces informations vous donneront une vision de l’évolution des performances du réseau du réseau au fil du temps.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Aperçu
+#### Aperçu
 
 La section d'aperçu présente à la fois toutes les métriques actuelles du réseau et certaines métriques cumulatives au fil du temps :
 
@@ -137,7 +149,7 @@ Quelques détails clés à noter :
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Époques
+#### Époques
 
 Dans la section Époques, vous pouvez analyser, époque par époque, des métriques telles que :
 
@@ -222,7 +234,7 @@ Dans cet onglet, vous trouverez un aperçu de :
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Paramètres de votre profil
+### Paramètres de votre profil
 
 Dans votre profil utilisateur, vous pourrez gérer les détails de votre profil personnel (comme la configuration d'un nom ENS). Si vous êtes un indexeur, vous avez encore plus accès aux paramètres à portée de main. Dans votre profil utilisateur, vous pourrez configurer vos paramètres et opérateurs de délégation.
 
@@ -234,3 +246,11 @@ Dans votre profil utilisateur, vous pourrez gérer les détails de votre profil
 En tant que portail officiel dans le monde des données décentralisées, Graph Explorer vous permet de prendre diverses actions, quel que soit votre rôle dans le réseau. Vous pouvez accéder aux paramètres de votre profil en ouvrant le menu déroulant à côté de votre adresse, puis en cliquant sur le bouton Paramètres.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Ressources supplémentaires
+
+### Guide Vidéo
+
+Pour une vue d'ensemble de Graph Explorer, consultez la vidéo ci-dessous :
+
+<VideoEmbed youtube="u224xf7rEBY" />

From beb6eac2f76d46a77602fc2de23901cfa41096e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:03:59 -0500
Subject: [PATCH 2451/3820] New translations introduction.mdx (French)

---
 .../fr/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/fr/subgraphs/querying/introduction.mdx b/website/pages/fr/subgraphs/querying/introduction.mdx
index f30a125cc465..0b27e12479c2 100644
--- a/website/pages/fr/subgraphs/querying/introduction.mdx
+++ b/website/pages/fr/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Interroger The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Aperçu
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Spécificités⁠
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Ressources supplémentaires
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 5eb9742bdc3c8cefe7427cee55831b37e51a6211 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:02 -0500
Subject: [PATCH 2452/3820] New translations explorer.mdx (Spanish)

---
 website/pages/es/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/es/subgraphs/explorer.mdx b/website/pages/es/subgraphs/explorer.mdx
index 4c929faa896b..6980559e8766 100644
--- a/website/pages/es/subgraphs/explorer.mdx
+++ b/website/pages/es/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Descripción
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgrafos
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Participantes
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexadores
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexadores
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curadores
+#### 2. Curadores
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegadores
+#### 3. Delegadores
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - El número de Indexadores a los que delega este Delegador
-- La delegación principal de un Delegador
+- A Delegator's original delegation
 - Las recompensas que han ido acumulando, pero que aún no han retirado del protocolo
 - Las recompensas realizadas, es decir, las que ya retiraron del protocolo
 - Cantidad total de GRT que tienen actualmente dentro del protocolo
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Red
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Descripción
+#### Descripción
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Ciclos (epochs)
+#### Ciclos (epochs)
 
 En la sección de Epochs, puedes analizar, por cada epoch, métricas como:
 
@@ -222,7 +234,7 @@ Dentro de esta pestaña, encontrarás una descripción general de:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Configuración de tu perfil
+### Configuración de tu perfil
 
 Dentro de tu perfil de usuario, podrás administrar los detalles de tu perfil personal (como configurar un nombre de ENS). Si eres un Indexador, tienes aún más acceso a la configuración al alcance de tu mano. En tu perfil de usuario, podrás configurar los parámetros y operadores de tu delegación.
 
@@ -234,3 +246,11 @@ Dentro de tu perfil de usuario, podrás administrar los detalles de tu perfil pe
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Recursos Adicionales
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From acb9044e746471addf3f35887d99cd36a61f427f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:06 -0500
Subject: [PATCH 2453/3820] New translations introduction.mdx (Spanish)

---
 .../es/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/es/subgraphs/querying/introduction.mdx b/website/pages/es/subgraphs/querying/introduction.mdx
index 2f4033f89fca..d46047c6e95c 100644
--- a/website/pages/es/subgraphs/querying/introduction.mdx
+++ b/website/pages/es/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Consultando The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Descripción
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Recursos Adicionales
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 6b83c73b1bae81dc05544dee70f5235e388fdff3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:08 -0500
Subject: [PATCH 2454/3820] New translations explorer.mdx (Arabic)

---
 website/pages/ar/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/ar/subgraphs/explorer.mdx b/website/pages/ar/subgraphs/explorer.mdx
index 1ebc61b13dfe..c272a7678a12 100644
--- a/website/pages/ar/subgraphs/explorer.mdx
+++ b/website/pages/ar/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## نظره عامة
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgraphs
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## المشاركون
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexers
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexers
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 3. المفوضون Delegators
+#### 3. المفوضون Delegators
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. المفوضون Delegators
+#### 3. المفوضون Delegators
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - عدد المفهرسين المفوض إليهم
-- التفويض الأصلي للمفوض Delegator’s original delegation
+- A Delegator's original delegation
 - المكافآت التي جمعوها والتي لم يسحبوها من البروتوكول
 - المكافآت التي تم سحبها من البروتوكول
 - كمية ال GRT التي يمتلكونها حاليا في البروتوكول
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Network
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### نظره عامة
+#### نظره عامة
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### الفترات Epochs
+#### الفترات Epochs
 
 In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
 
@@ -222,7 +234,7 @@ In the Delegators tab, you can find the details of your active and historical de
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## إعدادات ملف التعريف الخاص بك
+### إعدادات ملف التعريف الخاص بك
 
 ضمن ملف تعريف المستخدم الخاص بك ، ستتمكن من إدارة تفاصيل ملفك الشخصي (مثل إعداد اسم ENS). إذا كنت مفهرسا ، فستستطيع الوصول إلى إعدادت أكثر. في ملف تعريف المستخدم الخاص بك ، ستتمكن من إعداد بارامترات التفويض والمشغلين.
 
@@ -234,3 +246,11 @@ In the Delegators tab, you can find the details of your active and historical de
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## مصادر إضافية
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 55a5e75266a26d67020c8499ed551a260520ebf4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:09 -0500
Subject: [PATCH 2455/3820] New translations introduction.mdx (Arabic)

---
 .../ar/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/ar/subgraphs/querying/introduction.mdx b/website/pages/ar/subgraphs/querying/introduction.mdx
index 4a0a6e29f4c4..15865129c95a 100644
--- a/website/pages/ar/subgraphs/querying/introduction.mdx
+++ b/website/pages/ar/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Querying The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## نظره عامة
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### مصادر إضافية
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 68029e77ffe753c96578c3d8a9ec1cde2afc7b10 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:13 -0500
Subject: [PATCH 2456/3820] New translations explorer.mdx (Czech)

---
 website/pages/cs/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/cs/subgraphs/explorer.mdx b/website/pages/cs/subgraphs/explorer.mdx
index 4f6d3cc9f97c..7d1fa5d410e7 100644
--- a/website/pages/cs/subgraphs/explorer.mdx
+++ b/website/pages/cs/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Průzkumník grafů
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Přehled
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Podgrafy
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Účastníci
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexery
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexery
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Kurátoři
+#### 2. Kurátoři
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegáti
+#### 3. Delegáti
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - Počet indexátorů, na které deleguje delegát
-- Původní delegace delegát
+- A Delegator's original delegation
 - Odměny, které nashromáždili, ale z protokolu si je nevyzvedli
 - Realizované odměny odstranili z protokolu
 - Celkové množství GRT, které mají v současné době v protokolu
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Síť
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Přehled
+#### Přehled
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epochs
+#### Epochs
 
 V části Epochy můžete na základě jednotlivých epoch analyzovat metriky, jako jsou:
 
@@ -222,7 +234,7 @@ Na této tab najdete přehled:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Nastavení profilu
+### Nastavení profilu
 
 Ve svém uživatelském profilu budete moci spravovat své osobní údaje (například nastavit jméno ENS). Jste-li indexátorem, máte k dispozici ještě více nastavení. Ve svém uživatelském profilu budete moci nastavit parametry delegování a operátory.
 
@@ -234,3 +246,11 @@ Ve svém uživatelském profilu budete moci spravovat své osobní údaje (např
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Další zdroje
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 16efb4fbabb8dd309289782ef1ec5e3f51e2886e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:14 -0500
Subject: [PATCH 2457/3820] New translations introduction.mdx (Czech)

---
 .../cs/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/cs/subgraphs/querying/introduction.mdx b/website/pages/cs/subgraphs/querying/introduction.mdx
index ee7b3a1eef3f..0ae5311c443c 100644
--- a/website/pages/cs/subgraphs/querying/introduction.mdx
+++ b/website/pages/cs/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Dotazování na graf
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Přehled
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Další zdroje
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 217b06f3f5be2411e0d8cc23ea7440f8c9c1a563 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:16 -0500
Subject: [PATCH 2458/3820] New translations introduction.mdx (German)

---
 .../de/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/de/subgraphs/querying/introduction.mdx b/website/pages/de/subgraphs/querying/introduction.mdx
index 4a0a6e29f4c4..2d9bd76f182f 100644
--- a/website/pages/de/subgraphs/querying/introduction.mdx
+++ b/website/pages/de/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Querying The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Overview
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Besonderheiten
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Additional Resources
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 4695a3497f65434117c2a2932077aae8d721ba38 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:19 -0500
Subject: [PATCH 2459/3820] New translations explorer.mdx (Italian)

---
 website/pages/it/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/it/subgraphs/explorer.mdx b/website/pages/it/subgraphs/explorer.mdx
index 7bbd7782278f..e46e4884b488 100644
--- a/website/pages/it/subgraphs/explorer.mdx
+++ b/website/pages/it/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Panoramica
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgraphs
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Partecipanti
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexer
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexer
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curator
+#### 2. Curator
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegator
+#### 3. Delegator
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - Il numero di Indexer verso cui un Delegator sta delegando
-- La delega originale di un Delegator
+- A Delegator's original delegation
 - Le ricompense che hanno accumulato ma non ritirato dal protocollo
 - Le ricompense realizzate ritirate dal protocollo
 - Quantità totale di GRT che hanno attualmente nel protocollo
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## La rete
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Panoramica
+#### Panoramica
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epoche
+#### Epoche
 
 Nella sezione Epoche è possibile analizzare su base epocale metriche come:
 
@@ -222,7 +234,7 @@ All'interno di questa scheda è presente una panoramica di:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Impostazioni del profilo
+### Impostazioni del profilo
 
 All'interno del vostro profilo utente, potrete gestire i dettagli del vostro profilo personale (come impostare un nome ENS). Se siete un Indexer, avrete ancora più accesso alle impostazioni a portata di mano. Nel vostro profilo utente, potrete impostare i parametri di delegazione e gli operatori.
 
@@ -234,3 +246,11 @@ All'interno del vostro profilo utente, potrete gestire i dettagli del vostro pro
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Additional Resources
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 4a2b14650f74534be2f05957125eef215e316348 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:20 -0500
Subject: [PATCH 2460/3820] New translations introduction.mdx (Italian)

---
 .../it/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/it/subgraphs/querying/introduction.mdx b/website/pages/it/subgraphs/querying/introduction.mdx
index bc68455214de..62aa0b1ebb1f 100644
--- a/website/pages/it/subgraphs/querying/introduction.mdx
+++ b/website/pages/it/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Effettuare query di The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Panoramica
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Additional Resources
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From dded60558144f1b951bfa3d469665f4d477079a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:23 -0500
Subject: [PATCH 2461/3820] New translations explorer.mdx (Japanese)

---
 website/pages/ja/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/ja/subgraphs/explorer.mdx b/website/pages/ja/subgraphs/explorer.mdx
index ceb760528c04..c0356b47f077 100644
--- a/website/pages/ja/subgraphs/explorer.mdx
+++ b/website/pages/ja/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: グラフエクスプローラ
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## 概要
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## サブグラフ
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## 参加者
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. インデクサー（Indexers）
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. インデクサー（Indexers）
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. キュレーター
+#### 2. キュレーター
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. デリゲーター
+#### 3. デリゲーター
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - デリゲーターがデリゲーションしているインデクサー数
-- デリゲーターの最初のデリゲーション内容
+- A Delegator's original delegation
 - デリゲーターが蓄積したがプロトコルから引き出していない報酬
 - プロトコルから撤回済みの報酬
 - 現在プロトコルに保持している GRT 総量
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## ネットワーク
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### 概要
+#### 概要
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### エポック
+#### エポック
 
 エポックセクションでは、エポックごとに以下のようなメトリクスを分析できます：
 
@@ -222,7 +234,7 @@ In the Delegators tab, you can find the details of your active and historical de
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## プロフィールの設定
+### プロフィールの設定
 
 ユーザープロフィールでは、個人的なプロフィールの詳細（ENS ネームの設定など）を管理することができます。 インデクサーの方は、さらに多くの設定が可能です。 ユーザープロファイルでは、デリゲーションパラメーターとオペレーターを設定することができます。
 
@@ -234,3 +246,11 @@ In the Delegators tab, you can find the details of your active and historical de
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## その他のリソース
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From e0ee71969f90ae03d17ff22b9b5b2223f03c4f1e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:24 -0500
Subject: [PATCH 2462/3820] New translations introduction.mdx (Japanese)

---
 .../ja/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/ja/subgraphs/querying/introduction.mdx b/website/pages/ja/subgraphs/querying/introduction.mdx
index e1ba5197b374..c87c97144fe2 100644
--- a/website/pages/ja/subgraphs/querying/introduction.mdx
+++ b/website/pages/ja/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: The Graphのクエリ
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## 概要
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### その他のリソース
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From ea853f4f3d4d54e019ce1e7fe918f16e9996e42c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:27 -0500
Subject: [PATCH 2463/3820] New translations explorer.mdx (Korean)

---
 website/pages/ko/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/ko/subgraphs/explorer.mdx b/website/pages/ko/subgraphs/explorer.mdx
index 433821560d85..94bf8f0c481d 100644
--- a/website/pages/ko/subgraphs/explorer.mdx
+++ b/website/pages/ko/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Overview
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgraphs
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Participants
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexers
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexers
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curators
+#### 2. Curators
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegators
+#### 3. Delegators
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - The number of Indexers a Delegator is delegating towards
-- A Delegator’s original delegation
+- A Delegator's original delegation
 - The rewards they have accumulated but have not withdrawn from the protocol
 - The realized rewards they withdrew from the protocol
 - Total amount of GRT they have currently in the protocol
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Network
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Overview
+#### Overview
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epochs
+#### Epochs
 
 In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
 
@@ -222,7 +234,7 @@ Within this tab, you’ll find an overview of:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Your Profile Settings
+### Your Profile Settings
 
 Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
 
@@ -234,3 +246,11 @@ Within your user profile, you’ll be able to manage your personal profile detai
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Additional Resources
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From f6f40a84a78bec280af4dc9ba1bbabe313b99d20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:28 -0500
Subject: [PATCH 2464/3820] New translations introduction.mdx (Korean)

---
 .../ko/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/ko/subgraphs/querying/introduction.mdx b/website/pages/ko/subgraphs/querying/introduction.mdx
index 4a0a6e29f4c4..f8da55d13b70 100644
--- a/website/pages/ko/subgraphs/querying/introduction.mdx
+++ b/website/pages/ko/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Querying The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Overview
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Additional Resources
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 5485663b1804e29f8746007251e1b44c6fc6b5b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:31 -0500
Subject: [PATCH 2465/3820] New translations explorer.mdx (Dutch)

---
 website/pages/nl/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/nl/subgraphs/explorer.mdx b/website/pages/nl/subgraphs/explorer.mdx
index 038fab07925a..be421ea28c4c 100644
--- a/website/pages/nl/subgraphs/explorer.mdx
+++ b/website/pages/nl/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Verkenner
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Overview
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgraphs
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Deelnemers
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexers
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexers
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curatoren
+#### 2. Curatoren
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegators
+#### 3. Delegators
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - Het aantal Indexeerders waaraan een Delegator heeft gedelegeerd
-- De oorspronkelijke delegatie van een Delegator
+- A Delegator's original delegation
 - De beloningen die ze hebben opgebouwd, maar nog niet hebben opgenomen uit het protocol
 - De gerealiseerde beloningen die ze uit het protocol hebben opgenomen
 - Het totale bedrag aan GRT dat ze momenteel in het protocol hebben
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Netwerk
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Overview
+#### Overview
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epochs
+#### Epochs
 
 In de Epochs afdeling kun je per epoch verschillende metrieken analyseren, zoals:
 
@@ -222,7 +234,7 @@ Binnen deze tab vind je een overzicht van:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Jouw profielinstellingen
+### Jouw profielinstellingen
 
 Binnen je gebruikersprofiel kun je je persoonlijke profielgegevens beheren (zoals het instellen van een ENS-naam). Als je een Indexeerder bent, heb je nog meer toegang tot instellingen binnen handbereik. In je gebruikersprofiel kun je je delegatieparameters en operators instellen.
 
@@ -234,3 +246,11 @@ Binnen je gebruikersprofiel kun je je persoonlijke profielgegevens beheren (zoal
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Additional Resources
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 30ad0842bb42907bdac76dcd275894ba5d2275e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:32 -0500
Subject: [PATCH 2466/3820] New translations introduction.mdx (Dutch)

---
 .../nl/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/nl/subgraphs/querying/introduction.mdx b/website/pages/nl/subgraphs/querying/introduction.mdx
index 4a0a6e29f4c4..f8da55d13b70 100644
--- a/website/pages/nl/subgraphs/querying/introduction.mdx
+++ b/website/pages/nl/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Querying The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Overview
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Additional Resources
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 3be7a5ff495ae1622815e97003aa60c8eee6270d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:35 -0500
Subject: [PATCH 2467/3820] New translations explorer.mdx (Polish)

---
 website/pages/pl/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/pl/subgraphs/explorer.mdx b/website/pages/pl/subgraphs/explorer.mdx
index c10068643631..94bf8f0c481d 100644
--- a/website/pages/pl/subgraphs/explorer.mdx
+++ b/website/pages/pl/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Overview
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgrafy
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Participants
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexers
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexers
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curators
+#### 2. Curators
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegators
+#### 3. Delegators
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - The number of Indexers a Delegator is delegating towards
-- A Delegator’s original delegation
+- A Delegator's original delegation
 - The rewards they have accumulated but have not withdrawn from the protocol
 - The realized rewards they withdrew from the protocol
 - Total amount of GRT they have currently in the protocol
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Network
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Overview
+#### Overview
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epochs
+#### Epochs
 
 In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
 
@@ -222,7 +234,7 @@ Within this tab, you’ll find an overview of:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Your Profile Settings
+### Your Profile Settings
 
 Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
 
@@ -234,3 +246,11 @@ Within your user profile, you’ll be able to manage your personal profile detai
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Additional Resources
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From a597585cf6e5c14d86a46eec8966065b88672b0b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:36 -0500
Subject: [PATCH 2468/3820] New translations introduction.mdx (Polish)

---
 .../pl/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/pl/subgraphs/querying/introduction.mdx b/website/pages/pl/subgraphs/querying/introduction.mdx
index 4a0a6e29f4c4..f8da55d13b70 100644
--- a/website/pages/pl/subgraphs/querying/introduction.mdx
+++ b/website/pages/pl/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Querying The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Overview
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Additional Resources
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 37a93b425c26c9daa4a8b4c286b837361d604da1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:39 -0500
Subject: [PATCH 2469/3820] New translations explorer.mdx (Russian)

---
 website/pages/ru/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/ru/subgraphs/explorer.mdx b/website/pages/ru/subgraphs/explorer.mdx
index 66408d6f8c27..cf6588410a77 100644
--- a/website/pages/ru/subgraphs/explorer.mdx
+++ b/website/pages/ru/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Обзор
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Подграфы
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Участники
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Индексаторы
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Индексаторы
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Кураторы
+#### 2. Кураторы
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Делегаторы
+#### 3. Делегаторы
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - Количество Индексаторов, к которым делегирует Делегатор
-- Первоначальная делегация Делегатора
+- A Delegator's original delegation
 - Накопленные ими вознаграждения, которые они не вывели из протокола
 - Реализованные вознаграждения, которые они сняли с протокола
 - Общее количество GRT, которое у них имеется в настоящее время в протоколе
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Сеть
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Обзор
+#### Обзор
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Эпохи
+#### Эпохи
 
 В разделе «Эпохи» Вы можете анализировать по эпохам такие показатели, как:
 
@@ -222,7 +234,7 @@ In the Delegators tab, you can find the details of your active and historical de
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Параметры Вашего профиля
+### Параметры Вашего профиля
 
 В Вашем пользовательском профиле Вы сможете управлять деталями своего личного профиля (например, настройкой имени ENS). Если Вы Индексатор, у Вас есть еще больше возможностей для доступа к настройкам. В Вашем пользовательском профиле Вы сможете настроить параметры делегирования и операторов.
 
@@ -234,3 +246,11 @@ In the Delegators tab, you can find the details of your active and historical de
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Дополнительные ресурсы
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From d1ca85933beb5ee0a3e183e0b11397a43d777869 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:40 -0500
Subject: [PATCH 2470/3820] New translations introduction.mdx (Russian)

---
 .../ru/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/ru/subgraphs/querying/introduction.mdx b/website/pages/ru/subgraphs/querying/introduction.mdx
index 789069d0d033..ba488a78e21b 100644
--- a/website/pages/ru/subgraphs/querying/introduction.mdx
+++ b/website/pages/ru/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Запрос The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Обзор
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Специфические особенности
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Дополнительные ресурсы
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From a4957ebcfebfc4dc0a5cf899421b885a87fd1de9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:43 -0500
Subject: [PATCH 2471/3820] New translations explorer.mdx (Swedish)

---
 website/pages/sv/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/sv/subgraphs/explorer.mdx b/website/pages/sv/subgraphs/explorer.mdx
index f0d804ed354a..1d68a1a3e60f 100644
--- a/website/pages/sv/subgraphs/explorer.mdx
+++ b/website/pages/sv/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graf Utforskaren
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Översikt
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgrafer
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Deltagare
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexerare
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexerare
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Kuratorer
+#### 2. Kuratorer
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegater
+#### 3. Delegater
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - Antal indexerare en delegat delegerar till
-- En delegats ursprungliga delegation
+- A Delegator's original delegation
 - Belöningar de har ackumulerat men inte har dragit tillbaka från protokollet
 - De realiserade belöningarna de drog tillbaka från protokollet
 - Totalt belopp av GRT som de för närvarande har i protokollet
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Nätverk
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Översikt
+#### Översikt
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epoker
+#### Epoker
 
 I avsnittet Epoker kan du analysera på en per-epok-basis, metriker som:
 
@@ -222,7 +234,7 @@ Inom den här fliken hittar du en översikt över:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Dina profilinställningar
+### Dina profilinställningar
 
 Inom din användarprofil kommer du att kunna hantera dina personliga profiluppgifter (som att ställa in ett ENS-namn). Om du är indexerare har du ännu mer åtkomst till inställningar inom räckhåll. I din användarprofil kan du ställa in dina delegationsparametrar och operatörer.
 
@@ -234,3 +246,11 @@ Inom din användarprofil kommer du att kunna hantera dina personliga profiluppgi
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Ytterligare resurser
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 7aae4cd0b09a8cc95dead680e37acd0aad5e4aa9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:44 -0500
Subject: [PATCH 2472/3820] New translations introduction.mdx (Swedish)

---
 .../sv/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/sv/subgraphs/querying/introduction.mdx b/website/pages/sv/subgraphs/querying/introduction.mdx
index 88e0a21e5cb4..13b4e1764381 100644
--- a/website/pages/sv/subgraphs/querying/introduction.mdx
+++ b/website/pages/sv/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Fråga The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Översikt
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Ytterligare resurser
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 6eed249b7039eb82ad950c8e55cc447a52f2336b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:47 -0500
Subject: [PATCH 2473/3820] New translations explorer.mdx (Turkish)

---
 website/pages/tr/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/tr/subgraphs/explorer.mdx b/website/pages/tr/subgraphs/explorer.mdx
index d91ee86d2aa8..ea5de668e6a2 100644
--- a/website/pages/tr/subgraphs/explorer.mdx
+++ b/website/pages/tr/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Gezgini
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Genel Bakış
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgraph'ler
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Katılımcılar
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. İndeksleyiciler
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. İndeksleyiciler
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Küratörler
+#### 2. Küratörler
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegatörler
+#### 3. Delegatörler
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - Bir Delegatör'ün delege ettiği İndeksleyici sayısı
-- Bir Delegatör'ün orijinal delegasyonu
+- A Delegator's original delegation
 - Biriktirdikleri ancak protokolden çekmedikleri ödüller
 - Protokolden çekildiler gerçekleşmiş ödüller
 - Şu anda protokolde bulunan sahip oldukları toplam GRT miktarı
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Ağ
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Genel Bakış
+#### Genel Bakış
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Dönemler
+#### Dönemler
 
 Dönemler bölümünde, aşağıdaki gibi metrikleri dönem bazında analiz edebilirsiniz:
 
@@ -222,7 +234,7 @@ Bu sekmede, aşağıdakilerin genel bir bakışını bulacaksınız:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Profil Ayarlarınız
+### Profil Ayarlarınız
 
 Kullanıcı profilinizde, kişisel profil ayrıntılarınızı yönetebileceksiniz (bir ENS adı almak gibi). Eğer bir İndeksleyiciyseniz, daha fazla ayara erişiminiz olacaktır. Kullanıcı profilinizde, delegasyon parametrelerinizi ve operatörlerinizi ayarlayabileceksiniz.
 
@@ -234,3 +246,11 @@ Kullanıcı profilinizde, kişisel profil ayrıntılarınızı yönetebileceksin
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Ek Kaynaklar
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 226ade8f4b799190505976ece2c1cd984b559b4f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:48 -0500
Subject: [PATCH 2474/3820] New translations introduction.mdx (Turkish)

---
 .../tr/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/tr/subgraphs/querying/introduction.mdx b/website/pages/tr/subgraphs/querying/introduction.mdx
index 4a0a6e29f4c4..0ebd0ac2b737 100644
--- a/website/pages/tr/subgraphs/querying/introduction.mdx
+++ b/website/pages/tr/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Querying The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Genel Bakış
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Ayrıntılar
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Ek Kaynaklar
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From aaa6ca6b976b65c722bc7269920377d508e3d4ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:51 -0500
Subject: [PATCH 2475/3820] New translations explorer.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/uk/subgraphs/explorer.mdx b/website/pages/uk/subgraphs/explorer.mdx
index e70122cdc018..c12d5da4e90a 100644
--- a/website/pages/uk/subgraphs/explorer.mdx
+++ b/website/pages/uk/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Overview
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Підграфи
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Учасники
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Індексатори
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Індексатори
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curators
+#### 2. Curators
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegators
+#### 3. Delegators
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - The number of Indexers a Delegator is delegating towards
-- A Delegator’s original delegation
+- A Delegator's original delegation
 - The rewards they have accumulated but have not withdrawn from the protocol
 - The realized rewards they withdrew from the protocol
 - Total amount of GRT they have currently in the protocol
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Network
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Overview
+#### Overview
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epochs
+#### Epochs
 
 In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
 
@@ -222,7 +234,7 @@ Within this tab, you’ll find an overview of:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Your Profile Settings
+### Your Profile Settings
 
 Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
 
@@ -234,3 +246,11 @@ Within your user profile, you’ll be able to manage your personal profile detai
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Додаткові матеріали
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 3515e54e55ea53a4dee93ca3bdb1a06c6b24383a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:51 -0500
Subject: [PATCH 2476/3820] New translations introduction.mdx (Ukrainian)

---
 .../uk/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/uk/subgraphs/querying/introduction.mdx b/website/pages/uk/subgraphs/querying/introduction.mdx
index 4a0a6e29f4c4..126e44fdee35 100644
--- a/website/pages/uk/subgraphs/querying/introduction.mdx
+++ b/website/pages/uk/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Querying The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Overview
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Додаткові матеріали
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From b8cf37d5b699141ea003cea79cdcdef319c7147b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:54 -0500
Subject: [PATCH 2477/3820] New translations explorer.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/zh/subgraphs/explorer.mdx b/website/pages/zh/subgraphs/explorer.mdx
index 6cfc5fc25fe9..9da28e248eb9 100644
--- a/website/pages/zh/subgraphs/explorer.mdx
+++ b/website/pages/zh/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph 浏览器
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## 概述
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## 子图
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## 参与者
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. 索引人
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. 索引人
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. 策展人
+#### 2. 策展人
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. 委托人
+#### 3. 委托人
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - 委托人委托给的索引人数量
-- 委托人的原始委托
+- A Delegator's original delegation
 - 协议中已经产生但没有提现的奖励
 - 从协议中提取的已实现奖励
 - 目前在协议中的 GRT 总量
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## 网络
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### 概述
+#### 概述
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### 时期
+#### 时期
 
 在时期部分，您可以在每个时期的基础上分析指标，例如：
 
@@ -222,7 +234,7 @@ In the Delegators tab, you can find the details of your active and historical de
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## 设置您的个人资料
+### 设置您的个人资料
 
 在您的用户配置文件中，您将能够管理您的个人配置文件详细信息（例如设置 ENS 名称）。 如果您是 索引人，则可以轻松访问更多设置。 在您的用户配置文件中，您将能够设置您的委托参数和操作员。
 
@@ -234,3 +246,11 @@ In the Delegators tab, you can find the details of your active and historical de
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## 其他资源
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 320edab2f2876eb9ee886137df24f45ffe7d89c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:56 -0500
Subject: [PATCH 2478/3820] New translations introduction.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/zh/subgraphs/querying/introduction.mdx b/website/pages/zh/subgraphs/querying/introduction.mdx
index 118a1fe934c2..dac5f9d7db07 100644
--- a/website/pages/zh/subgraphs/querying/introduction.mdx
+++ b/website/pages/zh/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: 查询Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## 概述
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### 其他资源
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 5084fda77e251ace07c713b5e9fe4e4924ff37a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:04:59 -0500
Subject: [PATCH 2479/3820] New translations explorer.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/ur/subgraphs/explorer.mdx b/website/pages/ur/subgraphs/explorer.mdx
index ceadc154655b..7749bf1814f7 100644
--- a/website/pages/ur/subgraphs/explorer.mdx
+++ b/website/pages/ur/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: گراف ایکسپلورر
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## جائزہ
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## سب گراف
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## امیدوار
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### انڈیکسرز
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### انڈیکسرز
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### کیوریٹرز
+#### کیوریٹرز
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### ڈیلیگیٹرز
+#### ڈیلیگیٹرز
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - انڈیکسرز کی تعداد جن کی طرف ایک ڈیلیگیٹر ڈیلیٹ کر رہا ہے
-- ایک ڈیلیگیٹر کی حقیقی ڈیلیگیشن
+- A Delegator's original delegation
 - وہ انعامات جو انہوں نے جمع کر لیے ہیں لیکن پروٹوکول سے دستبردار نہیں ہوئے ہیں
 - وہ انعامات جو انہوں نے پروٹوکول سے واپس لے لیے
 - پروٹوکول میں ان کے پاس موجود GRT کی کل رقم
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## نیٹ ورک
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### جائزہ
+#### جائزہ
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### ایپوکس
+#### ایپوکس
 
 ایپوکس سیکشن میں، آپ فی اپوچ کی بنیاد پر تجزیہ کر سکتے ہیں، میٹرکس جیسے:
 
@@ -222,7 +234,7 @@ In the Delegators tab, you can find the details of your active and historical de
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## آپ کے پروفائل کی ترتیبات
+### آپ کے پروفائل کی ترتیبات
 
 اپنے صارف پروفائل کے اندر، آپ اپنی ذاتی پروفائل کی تفصیلات کا نظم کر سکیں گے (جیسے ENS نام ترتیب دینا)۔ اگر آپ ایک انڈیکسر ہیں، تو آپ کو اپنی انگلیوں پر ترتیبات تک اور بھی زیادہ رسائی حاصل ہے۔ اپنے صارف پروفائل میں، آپ اپنے ڈیلیگیشن پیرامیٹرز اور آپریٹرز کو ترتیب دے سکیں گے.
 
@@ -234,3 +246,11 @@ In the Delegators tab, you can find the details of your active and historical de
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## اضافی وسائل
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 74ec77daaf284bc37d462f654820e1bba73410e7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:05:00 -0500
Subject: [PATCH 2480/3820] New translations introduction.mdx (Urdu (Pakistan))

---
 .../ur/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/ur/subgraphs/querying/introduction.mdx b/website/pages/ur/subgraphs/querying/introduction.mdx
index 83b1bbd59519..8f715a9093e6 100644
--- a/website/pages/ur/subgraphs/querying/introduction.mdx
+++ b/website/pages/ur/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: گراف سے کیوری کرنا
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## جائزہ
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### اضافی وسائل
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From fbc3ea5ae42e97ba70e74ce44f77c1ceea34b17e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:05:03 -0500
Subject: [PATCH 2481/3820] New translations explorer.mdx (Vietnamese)

---
 website/pages/vi/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/vi/subgraphs/explorer.mdx b/website/pages/vi/subgraphs/explorer.mdx
index 51f1856ae915..048fa4b29df0 100644
--- a/website/pages/vi/subgraphs/explorer.mdx
+++ b/website/pages/vi/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Trình khám phá Graph
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Tổng quan
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgraphs
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Những người tham gia
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexers
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexers
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curators
+#### 2. Curators
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegators
+#### 3. Delegators
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - Số lượng Indexers mà một Delegator đang ủy quyền cho
-- Ủy quyền ban đầu của Delegator
+- A Delegator's original delegation
 - Phần thưởng họ đã tích lũy nhưng chưa rút khỏi giao thức
 - Phần thưởng đã ghi nhận ra mà họ rút khỏi giao thức
 - Tổng lượng GRT mà họ hiện có trong giao thức
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Mạng lưới
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Tổng quan
+#### Tổng quan
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epochs
+#### Epochs
 
 In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
 
@@ -222,7 +234,7 @@ Trong tab này, bạn sẽ tìm thấy tổng quan về:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Cài đặt Hồ sơ của bạn
+### Cài đặt Hồ sơ của bạn
 
 Trong hồ sơ người dùng của mình, bạn sẽ có thể quản lý chi tiết hồ sơ cá nhân của mình (như thiết lập tên ENS). Nếu bạn là Indexer, bạn thậm chí có nhiều quyền truy cập hơn vào các cài đặt trong tầm tay của mình. Trong hồ sơ người dùng của mình, bạn sẽ có thể thiết lập các tham số ủy quyền và operator của mình.
 
@@ -234,3 +246,11 @@ Trong hồ sơ người dùng của mình, bạn sẽ có thể quản lý chi t
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Additional Resources
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From ac8a755d3a5a813acc5c2712c2439390d3bdfc5f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:05:04 -0500
Subject: [PATCH 2482/3820] New translations introduction.mdx (Vietnamese)

---
 .../vi/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/vi/subgraphs/querying/introduction.mdx b/website/pages/vi/subgraphs/querying/introduction.mdx
index 4a0a6e29f4c4..c897963c375e 100644
--- a/website/pages/vi/subgraphs/querying/introduction.mdx
+++ b/website/pages/vi/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Querying The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Tổng quan
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Additional Resources
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 725c6b1a2af69ba7bab0291953e98db193483960 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:05:07 -0500
Subject: [PATCH 2483/3820] New translations explorer.mdx (Marathi)

---
 website/pages/mr/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/mr/subgraphs/explorer.mdx b/website/pages/mr/subgraphs/explorer.mdx
index 2d931c2b43cb..39ca874493c1 100644
--- a/website/pages/mr/subgraphs/explorer.mdx
+++ b/website/pages/mr/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## सविश्लेषण
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## सबग्राफ
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Participants
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexers
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexers
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curators
+#### 2. Curators
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegators
+#### 3. Delegators
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - The number of Indexers a Delegator is delegating towards
-- A Delegator’s original delegation
+- A Delegator's original delegation
 - The rewards they have accumulated but have not withdrawn from the protocol
 - The realized rewards they withdrew from the protocol
 - Total amount of GRT they have currently in the protocol
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Network
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### सविश्लेषण
+#### सविश्लेषण
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epochs
+#### Epochs
 
 In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
 
@@ -222,7 +234,7 @@ In the Delegators tab, you can find the details of your active and historical de
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Your Profile Settings
+### Your Profile Settings
 
 तुमच्या वापरकर्ता प्रोफाइलमध्ये, तुम्ही तुमचे वैयक्तिक प्रोफाइल तपशील व्यवस्थापित करण्यास सक्षम असाल (जसे की ENS नाव सेट करणे). तुम्ही इंडेक्सर असल्यास, तुमच्या बोटांच्या टोकावर असलेल्या सेटिंग्जमध्ये तुम्हाला आणखी प्रवेश आहे. तुमच्या वापरकर्ता प्रोफाइलमध्ये, तुम्ही तुमचे डेलिगेशन पॅरामीटर्स आणि ऑपरेटर सेट करू शकाल.
 
@@ -234,3 +246,11 @@ In the Delegators tab, you can find the details of your active and historical de
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## अतिरिक्त संसाधने
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 956baeb4fdc5269ff87158d6e6a89a28f92cda42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:05:08 -0500
Subject: [PATCH 2484/3820] New translations introduction.mdx (Marathi)

---
 .../mr/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/mr/subgraphs/querying/introduction.mdx b/website/pages/mr/subgraphs/querying/introduction.mdx
index 4a0a6e29f4c4..ec5ac623b0aa 100644
--- a/website/pages/mr/subgraphs/querying/introduction.mdx
+++ b/website/pages/mr/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Querying The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## सविश्लेषण
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### अतिरिक्त संसाधने
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 91ff461fd365cbbd25547d0e87ac9691e75f9de8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:05:11 -0500
Subject: [PATCH 2485/3820] New translations explorer.mdx (Hindi)

---
 website/pages/hi/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/hi/subgraphs/explorer.mdx b/website/pages/hi/subgraphs/explorer.mdx
index d16a6359625c..0fb509865a69 100644
--- a/website/pages/hi/subgraphs/explorer.mdx
+++ b/website/pages/hi/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-The Graph Explorer के बारे में जानें और सबग्राफ और नेटवर्क डेटा की दुनिया तक पहुंचें।
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer कई भागों में बंटा हुआ है जहां आप अन्य डेवलपर्स, dapp डेवलपर्स, Curators, Indexers और Delegators के साथ बातचीत कर सकते हैं।
+## अवलोकन
 
-## वीडियो गाइड
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-Graph Explorer का सामान्य अवलोकन करने के लिए, नीचे दिए गए वीडियो को देखें:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgraphs
+### Subgraphs Page
 
-जैसे ही आप Subgraph Studio में अपना subgraph डिप्लॉय और पब्लिश कर लें, नेविगेशन बार के शीर्ष पर स्थित "subgraphs tab” पर क्लिक करें ताकि आप निम्नलिखित तक पहुंच सकें:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - आपके अपने तैयार किए गए subgraphs
 - दूसरों द्वारा प्रकाशित subgraphs
@@ -26,7 +26,8 @@ Graph Explorer का सामान्य अवलोकन करने क
 
 - प्लेग्राउंड में परीक्षण प्रश्न करें और सूचनापूर्ण निर्णय लेने के लिए नेटवर्क विवरण का उपयोग करें।
 - अपने स्वयं के subgraph या दूसरों के subgraphs पर GRT का सिग्नल दें ताकि indexers इसकी महत्ता और गुणवत्ता के बारे में जागरूक हो सकें।
-- यह महत्वपूर्ण है क्योंकि एक subgraph पर संकेत देना इसे अनुक्रमित करने के लिए प्रोत्साहित करता है, जिसका अर्थ है कि यह अंततः नेटवर्क पर क्वेरीज़ को सेवा देने के लिए सामने आएगा।
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ Graph Explorer का सामान्य अवलोकन करने क
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## प्रतिभागियों
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-यह अनुभाग सभी 'participants' का एक दृष्टिकोण प्रदान करता है, जिसमें नेटवर्क में भाग लेने वाले सभी लोग शामिल हैं, जैसे Indexers, Delegators और Curators।
+### Participants Page
 
-### 1. इंडेक्सर्स
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. इंडेक्सर्स
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. क्यूरेटर
+#### 2. क्यूरेटर
 
 क्यूरेटर subgraphs का विश्लेषण करते हैं ताकि यह पहचान सकें कि कौन से subgraphs उच्चतम गुणवत्ता के हैं। एक बार जब एक क्यूरेटर एक संभावित उच्च गुणवत्ता वाले subgraph को खोज लेता है, तो वे इसके बॉन्डिंग कर्व पर सिग्नल देकर इसे क्यूरेट कर सकते हैं। ऐसा करके, क्यूरेटर इंडेक्सर्स को बताते हैं कि कौन से subgraphs उच्च गुणवत्ता के हैं और उन्हें इंडेक्स किया जाना चाहिए।
 
@@ -94,20 +106,20 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. प्रतिनिधि
+#### 3. प्रतिनिधि
 
 The Graph Network की सुरक्षा और विकेंद्रीकरण को बनाए रखने में Delegators की महत्वपूर्ण भूमिका होती है। वे नेटवर्क में भाग लेते हैं 'delegating' (यानी, 'staking') करके और GRT tokens को एक या एक से अधिक Indexers को सौंपते हैं।
 
 - Indexers के बिना, Delegators को महत्वपूर्ण पुरस्कार और शुल्क कमाने की संभावना कम होती है। इसलिए, Indexers अपने 'indexing rewards' और 'query fees' का एक हिस्सा देकर Delegators को आकर्षित करते हैं।
 - डेलीगेटर्स विभिन्न कारकों के आधार पर इंडेक्सर्स का चयन करते हैं, जैसे कि पिछले प्रदर्शन, इंडेक्सिंग इनाम दरें, और क्वेरी शुल्क कट।
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 Delegators तालिका में आप समुदाय में सक्रिय Delegators और महत्वपूर्ण मैट्रिक्स देख सकते हैं:
 
 - एक डेलीगेटर कितने इंडेक्सर्स की ओर डेलिगेट कर रहा है
-- एक प्रतिनिधि का मूल प्रतिनिधिमंडल
+- A Delegator's original delegation
 - उन्होंने जो पुरस्कार जमा किए हैं, लेकिन प्रोटोकॉल से वापस नहीं लिए हैं
 - एहसास हुआ पुरस्कार वे प्रोटोकॉल से वापस ले लिया
 - वर्तमान में उनके पास प्रोटोकॉल में जीआरटी की कुल राशि है
@@ -115,11 +127,11 @@ Delegators तालिका में आप समुदाय में स
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## नेटवर्क
+### Network Page
 
-इस अनुभाग में, आप वैश्विक KPI देख सकते हैं और प्रति-युग आधार पर स्विच करने की क्षमता को देख सकते हैं और नेटवर्क मेट्रिक्स का अधिक विस्तार से विश्लेषण कर सकते हैं। ये विवरण आपको यह समझने में मदद करेंगे कि नेटवर्क समय के साथ कैसा प्रदर्शन कर रहा है।
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### अवलोकन
+#### अवलोकन
 
 ओवरव्यू सेक्शन में वर्तमान नेटवर्क मैट्रिक्स और समय के साथ कुछ संचयी मैट्रिक्स दोनों शामिल हैं:
 
@@ -137,7 +149,7 @@ If you want to learn more about how to become a Delegator, check out the [offici
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### अवधियों को
+#### अवधियों को
 
 युग खंड में, आप प्रति युग के आधार पर विश्लेषण कर सकते हैं, जैसे मीट्रिक:
 
@@ -222,7 +234,7 @@ Delegator ,The Graph नेटवर्क के लिए महत्वप
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## आपकी प्रोफ़ाइल सेटिंग्स
+### आपकी प्रोफ़ाइल सेटिंग्स
 
 अपने उपयोगकर्ता प्रोफ़ाइल के भीतर, आप अपने व्यक्तिगत प्रोफ़ाइल विवरण (जैसे ENS नाम सेट करना) प्रबंधित करने में सक्षम होंगे। यदि आप एक इंडेक्सर हैं, तो आपके पास अपनी उंगलियों पर सेटिंग्स तक और भी अधिक पहुंच है। अपने उपयोगकर्ता प्रोफ़ाइल में, आप अपने प्रतिनिधि पैरामीटर और ऑपरेटर सेट अप करने में सक्षम होंगे।
 
@@ -234,3 +246,11 @@ Delegator ,The Graph नेटवर्क के लिए महत्वप
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Additional Resources
+
+### वीडियो गाइड
+
+Graph Explorer का सामान्य अवलोकन करने के लिए, नीचे दिए गए वीडियो को देखें:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 0cf058ad8bbf91d5695115fb995cbb1d98c6a18d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:05:13 -0500
Subject: [PATCH 2486/3820] New translations introduction.mdx (Hindi)

---
 .../hi/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/hi/subgraphs/querying/introduction.mdx b/website/pages/hi/subgraphs/querying/introduction.mdx
index ac50838549a7..80d5e4c3e21d 100644
--- a/website/pages/hi/subgraphs/querying/introduction.mdx
+++ b/website/pages/hi/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: ग्राफ़ को क्वेरी करना
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## अवलोकन
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## विशिष्टताएँ
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Additional Resources
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 6c38168175efbf5a77f4ac8e81e3a92ace490d92 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:05:16 -0500
Subject: [PATCH 2487/3820] New translations explorer.mdx (Swahili)

---
 website/pages/sw/subgraphs/explorer.mdx | 60 ++++++++++++++++---------
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/website/pages/sw/subgraphs/explorer.mdx b/website/pages/sw/subgraphs/explorer.mdx
index 433821560d85..94bf8f0c481d 100644
--- a/website/pages/sw/subgraphs/explorer.mdx
+++ b/website/pages/sw/subgraphs/explorer.mdx
@@ -2,19 +2,19 @@
 title: Graph Explorer
 ---
 
-Learn about The Graph Explorer and access the world of subgraphs and network data.
+Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators.
+## Overview
 
-## Video Guide
+Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
-For a general overview of Graph Explorer, check out the video below:
+## Inside Explorer
 
-<VideoEmbed youtube="u224xf7rEBY" />
+The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
 
-## Subgraphs
+### Subgraphs Page
 
-After you just finish deploying and publishing your subgraph in Subgraph Studio, click on the "subgraphs tab” at the top of the navigation bar to access the following:
+After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
 - Your own finished subgraphs
 - Subgraphs published by others
@@ -26,7 +26,8 @@ When you click into a subgraph, you will be able to do the following:
 
 - Test queries in the playground and be able to leverage network details to make informed decisions.
 - Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
-- This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+
+  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
@@ -43,11 +44,22 @@ On each subgraph’s dedicated page, you can do the following:
 
 ![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
 
-## Participants
+### Delegate Page
+
+On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+
+On this page, you can see the following:
+
+- Indexers who collected the most query fees
+- Indexers with the highest estimated APR
+
+Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
 
-This section provides a bird' s-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+### Participants Page
 
-### 1. Indexers
+This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+
+#### 1. Indexers
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
@@ -76,7 +88,7 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 ![Indexing details pane](/img/Indexing-Details-Pane.png)
 
-### 2. Curators
+#### 2. Curators
 
 Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
 
@@ -94,20 +106,20 @@ In the The Curator table listed below you can see:
 
 If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
 
-### 3. Delegators
+#### 3. Delegators
 
 Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
 
 - Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
 - Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It’s recommended to connect with the selected Indexers via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
 In the Delegators table you can see the active Delegators in the community and important metrics:
 
 - The number of Indexers a Delegator is delegating towards
-- A Delegator’s original delegation
+- A Delegator's original delegation
 - The rewards they have accumulated but have not withdrawn from the protocol
 - The realized rewards they withdrew from the protocol
 - Total amount of GRT they have currently in the protocol
@@ -115,11 +127,11 @@ In the Delegators table you can see the active Delegators in the community and i
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-## Network
+### Network Page
 
-In this section, you can see global KPIs and view the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-### Overview
+#### Overview
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 
@@ -137,7 +149,7 @@ A few key details to note:
 
 ![Explorer Image 8](/img/Network-Stats.png)
 
-### Epochs
+#### Epochs
 
 In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
 
@@ -222,7 +234,7 @@ Within this tab, you’ll find an overview of:
 
 ![Explorer Image 14](/img/Curation-Stats.png)
 
-## Your Profile Settings
+### Your Profile Settings
 
 Within your user profile, you’ll be able to manage your personal profile details (like setting up an ENS name). If you’re an Indexer, you have even more access to settings at your fingertips. In your user profile, you’ll be able to set up your delegation parameters and operators.
 
@@ -234,3 +246,11 @@ Within your user profile, you’ll be able to manage your personal profile detai
 As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+
+## Additional Resources
+
+### Video Guide
+
+For a general overview of Graph Explorer, check out the video below:
+
+<VideoEmbed youtube="u224xf7rEBY" />

From 966b435b6ee6c021b5954e2752e4c3944c8ca9a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 16:05:17 -0500
Subject: [PATCH 2488/3820] New translations introduction.mdx (Swahili)

---
 .../sw/subgraphs/querying/introduction.mdx    | 26 +++++++++++++------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/website/pages/sw/subgraphs/querying/introduction.mdx b/website/pages/sw/subgraphs/querying/introduction.mdx
index 4a0a6e29f4c4..f8da55d13b70 100644
--- a/website/pages/sw/subgraphs/querying/introduction.mdx
+++ b/website/pages/sw/subgraphs/querying/introduction.mdx
@@ -2,20 +2,30 @@
 title: Querying The Graph
 ---
 
-When a subgraph is published to The Graph Network, you can visit its subgraph details page on [Graph Explorer](https://thegraph.com/explorer) and use the "query" tab to explore the deployed GraphQL API for the subgraph, issuing queries and viewing the schema.
+To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities. You can learn about GraphQL querying best practices [here](/subgraphs/querying/best-practices/)
->
-> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+## Overview
+
+When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 
-Each subgraph published to The Graph Network has a unique query URL in Graph Explorer for making direct queries that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner.
+## Specifics
+
+Each subgraph published to The Graph Network has a unique query URL in Graph Explorer to make direct queries. You can find it by navigating to the subgraph details page and clicking on the "Query" button in the top right corner.
 
 ![Query Subgraph Button](/img/query-button-screenshot.png)
 
 ![Query Subgraph URL](/img/query-url-screenshot.png)
 
-Learn more about querying from an application [here](/subgraphs/querying/from-an-application/).
-
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
+You will notice that this query URL must use a unique API key. You can create and manage your API keys in [Subgraph Studio](https://thegraph.com/studio), under the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio/).
 
 Subgraph Studio users start on a Free Plan, which allows them to make 100,000 queries per month. Additional queries are available on the Growth Plan, which offers usage based pricing for additional queries, payable by credit card, or GRT on Arbitrum. You can learn more about billing [here](/subgraphs/billing/).
+
+> Please see the [Query API](/subgraphs/querying/graphql-api/) for a complete reference on how to query the subgraph's entities.
+>
+> Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
+
+### Additional Resources
+
+- Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
+- To query from an application, click [here](/subgraphs/querying/from-an-application/).
+- View [querying examples](https://github.com/graphprotocol/query-examples/tree/main).

From 12c9c01bd8fe783ef6723834a92202aff434e45e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 21:41:30 -0500
Subject: [PATCH 2489/3820] New translations arbitrum-faq.mdx (Chinese
 Simplified)

---
 website/pages/zh/archived/arbitrum/arbitrum-faq.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/zh/archived/arbitrum/arbitrum-faq.mdx b/website/pages/zh/archived/arbitrum/arbitrum-faq.mdx
index 1696ca24d7fe..cc912a21a269 100644
--- a/website/pages/zh/archived/arbitrum/arbitrum-faq.mdx
+++ b/website/pages/zh/archived/arbitrum/arbitrum-faq.mdx
@@ -16,7 +16,7 @@ By scaling The Graph on L2, network participants can now benefit from:
 
 Scaling the protocol smart contracts onto L2 allows network participants to interact more frequently at a reduced cost in gas fees. For example, Indexers can open and close allocations more frequently to index a greater number of subgraphs. Developers can deploy and update subgraphs more easily, and Delegators can delegate GRT more frequently. Curators can add or remove signal to a larger number of subgraphs–actions previously considered too cost-prohibitive to perform frequently due to gas.
 
-去年，The Graph社区在[GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) 讨论的结果之后，决定推进Arbitrum。
+去年，Graph社区在[GIP-0031](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) 讨论的结果之后，决定推进Arbitrum。
 
 ## 我需要做什么才能在L2上使用Graph？
 
@@ -49,7 +49,7 @@ All indexing rewards are now entirely on Arbitrum.
 
 All smart contracts have been thoroughly [audited](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/audits/OpenZeppelin/2022-07-graph-arbitrum-bridge-audit.pdf).
 
-所有事项已经经过了彻底测试，并制定了应急计划，以确保安全和无缝过渡。详细信息可以在这里 [here](https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20)找到。
+所有事项已经经过了彻底测试，并制定了应急计划，以确保安全和无缝过渡。详细信息可以在 [这里] (https://forum.thegraph.com/t/gip-0037-the-graph-arbitrum-deployment-with-linear-rewards-minted-in-l2/3551#risks-and-security-considerations-20)找到。
 
 ## Are existing subgraphs on Ethereum working?
 
@@ -57,7 +57,7 @@ All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/arc
 
 ## Does GRT have a new smart contract deployed on Arbitrum?
 
-是的，GRT在Arbitrum上有一个额外的智能合约[smart contract on Arbitrum](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)。然而，以太坊主网上的GRT合约 [GRT contract](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)将继续保持运营。
+是的，GRT在Arbitrum上有一个额外的[智能合约](https://arbiscan.io/address/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)。然而，以太坊主网上的 [GRT合约](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)将继续保持运营。
 
 ## Arbitrum账单常见问题解答
 
@@ -71,7 +71,7 @@ All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/arc
 
 ## 怎么知道Arbitrum 跨链桥是安全的？
 
-为确保所有用户的安全性和安全性，该跨链桥经过了严格的审计[heavily audited](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest)。
+为确保所有用户的安全性和安全性，该跨链桥经过了[严格的审计](https://code4rena.com/contests/2022-10-the-graph-l2-bridge-contest)。
 
 ## 如果从以太坊主网钱包添加新的GRT，需要做什么？
 

From 312e7aab815704700da6235103854d9ba6045107 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 13 Jan 2025 21:41:32 -0500
Subject: [PATCH 2490/3820] New translations l2-transfer-tools-faq.mdx (Chinese
 Simplified)

---
 .../pages/zh/archived/arbitrum/l2-transfer-tools-faq.mdx    | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/zh/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/zh/archived/arbitrum/l2-transfer-tools-faq.mdx
index 2d97f1524380..67247ad8cd2b 100644
--- a/website/pages/zh/archived/arbitrum/l2-transfer-tools-faq.mdx
+++ b/website/pages/zh/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -6,13 +6,13 @@ title: L2转移工具常见问题解答
 
 ### 什么是L2转移工具？
 
-The Graph 在将协议部署到 Arbitrum One 后，使参与者参与网络的成本降低了 26 倍。L2 转账工具是核心开发人员创建的，旨在简化转移到 Layer 2（二层网络）的过程。
+在将协议部署到 Arbitrum One 后，Graph 使参与者参与网络的成本降低了 26 倍。L2 转账工具是核心开发人员创建的，旨在简化转移到 Layer 2（二层网络）的过程。
 
 对于每个网络参与者，都提供了一套L2转账工具，以实现无缝的L2转移体验，避免解冻期或手动提取和桥接GRT代币。
 
-这些工具将要求您根据您在 The Graph 中的角色以及您要转移到 Layer 2 的内容，遵循一套特定的步骤。
+这些工具将要求您根据您在 Graph 中的角色以及您要转移到 Layer 2 的内容，遵循一套特定的步骤。
 
-### 我可以在以太坊主网上使用相同的钱包吗？
+### 我可以使用与以太坊主网上相同的钱包吗？
 
 If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
 

From f72a437504394fbeffde771e5e7e038ce1ec5aae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 14 Jan 2025 04:24:10 -0500
Subject: [PATCH 2491/3820] New translations l2-transfer-tools-guide.mdx
 (Chinese Simplified)

---
 .../pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx  | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
index 9a5711b2d217..b0bcc732a8a2 100644
--- a/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
+++ b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -6,15 +6,15 @@ The Graph has made it easy to move to L2 on Arbitrum One. For each protocol part
 
 Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
 
-## 如何将你的子图转移到 Arbitrum（L2）
+## 如何将你的子图转移到 Arbitrum (L2)
 
 <VideoEmbed youtube="R8_vz4lx2Co" />
 
 ## 将子图转移到 Arbitrum 的好处
 
-过去一年里，Graph社区和核心开发人员一直在为迁移到 Arbitrum 做准备(https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) 。Arbitrum 是一种二层网络或“L2”区块链，继承了以太坊的安全性，但提供了大幅降低的燃气费用。
+过去一年里，Graph社区和核心开发人员一直在为迁移到 Arbitrum [做准备](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) 。Arbitrum 是一种二层网络或“L2”区块链，继承了以太坊的安全性，但提供了大幅降低的燃气费用。
 
-当您将子图发布或升级到The Graph Network时，您将与协议上的智能合约进行交互，这需要使用以太币（ETH）支付燃气费用。通过将您的子图迁移到Arbitrum，将来对您的子图进行的任何更新将需要更低的燃气费用。较低的费用以及L2网络上平滑的曲线，使其他策展人更容易在您的子图上进行策展，从而增加了在您的子图上的索引人的奖励。这种较低成本的环境还使得索引器更便宜地对您的子图进行索引和服务。在接下来的几个月里，Arbitrum上的索引奖励将增加，而以太坊主网上的索引奖励将减少，因此越来越多的索引器将会将他们的质押迁移到L2网络并在该网络上设置运营。
+当您将子图发布或升级到Graph Network时，您将与协议上的智能合约进行交互，这需要使用以太币（ETH）支付燃气费用。通过将您的子图迁移到Arbitrum，将来对您的子图进行的任何更新将需要更低的燃气费用。较低的费用以及L2网络上平滑的曲线，使其他策展人更容易在您的子图上进行策展，从而增加了在您的子图上的索引人的奖励。这种较低成本的环境还使得索引器更便宜地对您的子图进行索引和服务。在接下来的几个月里，Arbitrum上的索引奖励将增加，而以太坊主网上的索引奖励将减少，因此越来越多的索引器将会将他们的质押迁移到L2网络并在该网络上设置运营。
 
 ## 理解信号、你的 L1 子图和查询 URL 的变化
 

From 00758b24fd1cb1c60df01d2cdbb3c0f4d4aae068 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 15 Jan 2025 03:54:34 -0500
Subject: [PATCH 2492/3820] New translations l2-transfer-tools-guide.mdx
 (Chinese Simplified)

---
 .../pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx    | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
index b0bcc732a8a2..2d0e57198860 100644
--- a/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
+++ b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -14,7 +14,7 @@ Some frequent questions about these tools are answered in the [L2 Transfer Tools
 
 过去一年里，Graph社区和核心开发人员一直在为迁移到 Arbitrum [做准备](https://forum.thegraph.com/t/gip-0031-arbitrum-grt-bridge/3305) 。Arbitrum 是一种二层网络或“L2”区块链，继承了以太坊的安全性，但提供了大幅降低的燃气费用。
 
-当您将子图发布或升级到Graph Network时，您将与协议上的智能合约进行交互，这需要使用以太币（ETH）支付燃气费用。通过将您的子图迁移到Arbitrum，将来对您的子图进行的任何更新将需要更低的燃气费用。较低的费用以及L2网络上平滑的曲线，使其他策展人更容易在您的子图上进行策展，从而增加了在您的子图上的索引人的奖励。这种较低成本的环境还使得索引器更便宜地对您的子图进行索引和服务。在接下来的几个月里，Arbitrum上的索引奖励将增加，而以太坊主网上的索引奖励将减少，因此越来越多的索引器将会将他们的质押迁移到L2网络并在该网络上设置运营。
+当您将子图发布或升级到Graph网络时，您将与协议上的智能合约进行交互，这需要使用以太币（ETH）支付燃气费用。通过将您的子图迁移到Arbitrum，将来对您的子图进行的任何更新将需要更低的燃气费用。较低的费用以及L2网络上平滑的曲线，使其他策展人更容易在您的子图上进行策展，从而增加了在您的子图上的索引人的奖励。这种较低成本的环境还使得索引人更便宜地对您的子图进行索引和服务。在接下来的几个月里，Arbitrum上的索引奖励将增加，而以太坊主网上的索引奖励将减少，因此越来越多的索引器将会将他们的质押迁移到L2网络并在该网络上设置运营。
 
 ## 理解信号、你的 L1 子图和查询 URL 的变化
 
@@ -52,7 +52,7 @@ Some frequent questions about these tools are answered in the [L2 Transfer Tools
 
 ![transfer tool](/img/L2-transfer-tool1.png)
 
-如果你使用拥有子图的钱包连接到 Explorer，你还可以在 Explorer 上的子图页面上找到它：
+如果你使用拥有子图的钱包连接到浏览器，你还可以在浏览器上的子图页面上找到它：
 
 ![Transferring to L2](/img/transferToL2.png)
 

From 797ab673882e0106f01e8f1c5172275ecfc6d401 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 15 Jan 2025 05:14:21 -0500
Subject: [PATCH 2493/3820] New translations l2-transfer-tools-guide.mdx
 (Chinese Simplified)

---
 .../pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx    | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
index 2d0e57198860..13603c5bcd0c 100644
--- a/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
+++ b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -130,13 +130,13 @@ Some frequent questions about these tools are answered in the [L2 Transfer Tools
 
 在开始转移之前，您必须决定哪个地址将在L2上拥有策展信号（参见上文的“选择您的L2钱包”），并建议您当需要在L2上重试消息执行时，提前转移一些用于手续费的 ETH到Arbitrum 上。您可以在某些交易所购买 ETH，并直接提款到 Arbitrum，或者您可以使用 Arbitrum 跨链桥将 ETH 从主网钱包发送到 L2： [bridge.arbitrum.io](http://bridge.arbitrum.io) - 由于 Arbitrum 上的燃料费用非常低，您可能只需要一小笔金额，例如 0.01 ETH 应该足够了。
 
-如果您策展的子图已经转移到L2，您将在Exploer上看到一条消息，告诉您正在为转移的子图进行策展。
+如果您策展的子图已经转移到L2，您将在浏览器上看到一条消息，告诉您正在为转移的子图进行策展。
 
 在查看子图页面时，您可以选择撤回或转移策展。点击“将信号转移到 Arbitrum”将打开转移工具。
 
 ![Transfer signal](/img/transferSignalL2TransferTools.png)
 
-打开转移工具后，如果您没有任何ETH，可能需要向您的钱包添加一些ETH。然后，您将能够在“Receiving wallet address”字段中输入L2钱包地址 - 请确保在此处输入正确的地址。点击转移信号将提示您在钱包上执行交易（注意，包含了一些ETH用于支付L2的燃料费）；这将启动转移过程。
+打开转移工具后，如果您没有任何ETH，可能需要向您的钱包添加一些ETH。然后，您将能够在“Receiving wallet address”字段中输入L2钱包地址 - 请确保在此处输入正确的地址。点击转移信号将提示您在钱包上执行交易（注意，包含了一些ETH用于支付L2的燃气费）；这将启动转移过程。
 
 如果执行了此步骤，请确保在不到7天的时间内继续完成第3步，否则您的信号GRT将丢失。这是由于在Arbitrum上的L1-L2消息传递的工作方式：通过跨链桥发送的消息是“可重试的票据”，必须在7天内执行。如果Arbitrum的燃气价格出现波动，初始执行可能需要重试。
 

From 0a3e0a39bf64e4455079a1e0ee88a704b4667d9e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 15 Jan 2025 10:37:04 -0500
Subject: [PATCH 2494/3820] New translations l2-transfer-tools-guide.mdx
 (Chinese Simplified)

---
 website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
index 13603c5bcd0c..c05e4d150d42 100644
--- a/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
+++ b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -24,7 +24,7 @@ Some frequent questions about these tools are answered in the [L2 Transfer Tools
 
 其他策展人可以选择是否提取他们所占份额的 GRT，或者将其转移到 L2 上的同一子图上，以铸造新的策展信号。如果一个子图所有者不将他们的子图转移到 L2 并通过合约调用手动废弃它，那么策展人将收到通知并可以提取他们的策展。
 
-一旦子图转移完成，由于所有策展都转换为 GRT，索引人将不再因索引子图而获得奖励。但是，有些索引人会保持对转移的子图进行 24 小时的服务，并立即开始在 L2 上进行子图索引。由于这些索引人已经对子图进行了索引，所以无需等待子图同步，几乎可以立即查询 L2 子图。
+一旦子图转移完成，由于所有策展都转换为 GRT，索引器将不再因索引子图而获得奖励。但是，有些索引器会保持对转移的子图进行 24 小时的服务，并立即开始在 L2 上进行子图索引。由于这些索引人已经对子图进行了索引，所以无需等待子图同步，几乎可以立即查询 L2 子图。
 
 对 L2 子图的查询需要使用不同的 URL（on `arbitrum-gateway.thegraph.com`），但 L1 URL 将继续工作至少 48 小时。之后，L1 网关将把查询转发到 L2 网关（一段时间内），但这会增加延迟，因此建议尽快将所有查询切换到新的 URL。
 

From 3cef2b454fbb38d681038439a937be98b48bb8cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 15 Jan 2025 10:37:05 -0500
Subject: [PATCH 2495/3820] New translations sunrise.mdx (Chinese Simplified)

---
 website/pages/zh/archived/sunrise.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/zh/archived/sunrise.mdx b/website/pages/zh/archived/sunrise.mdx
index 0e7fafa344d0..fe7014710776 100644
--- a/website/pages/zh/archived/sunrise.mdx
+++ b/website/pages/zh/archived/sunrise.mdx
@@ -1,10 +1,10 @@
 ---
-title: Post-Sunrise + Upgrading to The Graph Network FAQ
+title: 黎明后+升级到Graph网络常见问题
 ---
 
 > Note: The Sunrise of Decentralized Data ended June 12th, 2024.
 
-## What was the Sunrise of Decentralized Data?
+## 去中心化数据的黎明是什么？
 
 The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
 
@@ -36,7 +36,7 @@ The upgrade Indexer was implemented to improve the experience of upgrading subgr
 - It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
 - Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
 
-### 为什么 Edge & Node 运行升级索引人？
+### 为什么 Edge & Node 运行升级索引器？
 
 Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
 
@@ -48,7 +48,7 @@ However, this action unlocked query fees for any interested Indexer and increase
 
 The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
 
-### 这对于委托人来说意味着什么？
+### What does this mean for Delegators?
 
 The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
 

From 3dcd21219c5b29e90d8159e5d95b93c80027da0b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 15 Jan 2025 10:37:08 -0500
Subject: [PATCH 2496/3820] New translations graphcast.mdx (Chinese Simplified)

---
 website/pages/zh/indexing/tooling/graphcast.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/indexing/tooling/graphcast.mdx b/website/pages/zh/indexing/tooling/graphcast.mdx
index d8eeb0aa957a..6e29da450727 100644
--- a/website/pages/zh/indexing/tooling/graphcast.mdx
+++ b/website/pages/zh/indexing/tooling/graphcast.mdx
@@ -4,7 +4,7 @@ title: Graphcast
 
 ## 介绍
 
-有什么你想以自动化的方式向其他索引人学习或分享的东西吗？但这太麻烦或太费gas了？
+有什么你想以自动化的方式向其他索引人学习或分享的东西吗？但这太麻烦或太费燃气费了？
 
 目前，向其他网络参与者广播信息的成本由以太坊区块链上的gas费用决定。Graphcast通过充当一个可选的去中心化、分布式对等（P2P）通信工具来解决这个问题，该工具允许网络上的索引人实时交换信息。在没有数据完整性保证的情况下，交换P2P消息的成本几乎为零。尽管如此，Graphcast旨在通过信誉模型的开放设计空间提供消息有效性保证（即消息是有效的，并由已知的协议参与者签名）。
 

From 98571a1f86546885795c86eeca6dff1ea0e5fab4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 15 Jan 2025 19:32:12 -0500
Subject: [PATCH 2497/3820] New translations tap.mdx (Portuguese)

---
 website/pages/pt/indexing/tap.mdx | 180 +++++++++++++++---------------
 1 file changed, 90 insertions(+), 90 deletions(-)

diff --git a/website/pages/pt/indexing/tap.mdx b/website/pages/pt/indexing/tap.mdx
index 9296595074d3..a8f6b2d7d713 100644
--- a/website/pages/pt/indexing/tap.mdx
+++ b/website/pages/pt/indexing/tap.mdx
@@ -1,112 +1,112 @@
 ---
-title: TAP Migration Guide
+title: Como migrar para o TAP
 ---
 
-Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+Conheça o novo sistema de pagamentos do The Graph: **TAP — Timeline Aggregation Protocol** ("Protocolo de Agregação de Histórico"): um sistema de microtransações rápidas e eficientes, livre de confiança.
 
 ## Visão geral
 
-[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+O [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) é um programa modular que substituirá o sistema de pagamento Scalar atualmente em uso. Os recursos do TAP incluem:
 
-- Efficiently handles micropayments.
-- Adds a layer of consolidations to onchain transactions and costs.
-- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
-- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+- Processamento eficiente de micropagamentos.
+- Uma camada de consolidações para transações e custos na chain.
+- Controle total de recibos e pagamentos para Indexadores, garantindo pagamentos por queries.
+- Pontes de ligação descentralizadas e livres de confiança, melhorando o desempenho do `indexer-service` para grupos de remetentes.
 
 ## Especificações
 
-TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+O TAP permite que um remetente faça múltiplos pagamentos a um destinatário — os **TAP Receipts** ("Recibos do TAP") — que agrega os pagamentos em um, o **RAV — Receipt Aggregate Voucher** (Prova de Recibos Agregados). Este pagamento agregado pode ser verificado na blockchain, reduzindo o número de transações e simplificando o processo de pagamento.
 
-For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+Para cada query, a ponte de ligação enviará um `signed receipt` ("recibo assinado") para armazenar na sua base de dados. Estes queries serão então agregados por um `tap-agent` através de uma solicitação. Depois, você receberá um RAV. Para atualizar um RAV, envie-o com novos recibos para gerar um novo RAV com valor maior.
 
-### RAV Details
+### Detalhes de um RAV
 
-- It’s money that is waiting to be sent to the blockchain.
+- É dinheiro esperando ser enviado à blockchain.
 
-- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+- Ele continuará a enviar solicitações de agregação e evitará que o valor total de recibos não agregados passe do `amount willing to lose` ("quantia viável de perder").
 
-- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+- Cada RAV pode ser resgatado uma vez nos contratos; é por isto que são enviados após o fechamento da alocação.
 
-### Redeeming RAV
+### Como resgatar um RAV
 
-As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+Tudo será executado automaticamente enquanto `tap-agent` e `indexer-agent` forem executados. Veja um passo-a-passo do processo:
 
-1. An Indexer closes allocation.
+1. Um Indexador fecha uma alocação.
 
-2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+2. `<recently-closed-allocation-buffer> period, tap-agent` pega todos os recibos pendentes dessa alocação específica e solicita uma agregação para um RAV, marcando como `last` ("último").
 
-3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+3. O `indexer-agent` pega todos os últimos RAVs e manda solicitações de resgate à blockchain, que atualizará o valor de `redeem-at`.
 
-4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+4. Durante o período de `<finality-time>`, o `indexer-agent` monitora se a blockchain tem reorganizações que possam reverter a transação.
 
-   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+   - Se revertida, o RAV é reenviado à blockchain. Se não for revertida, é marcada como `final`.
 
-## Blockchain Addresses
+## Endereços de Blockchain
 
-### Contracts
+### Contratos
 
-| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
-| ------------------- | -------------------------------------------- | -------------------------------------------- |
-| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
-| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
-| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+| Contrato                  | Mainnet Arbitrum (42161)                     | Arbitrum Sepolia (421614)                    |
+| ------------------------- | -------------------------------------------- | -------------------------------------------- |
+| Verificador do TAP        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker       | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow                    | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
 
-### Gateway
+### Porta de Ligação
 
-| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
-| ---------- | --------------------------------------------- | --------------------------------------------- |
-| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
-| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
-| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+| Componente     | Mainnet Edge and Note (Mainnet Arbitrum)      | Testnet do Edge and Node (Arbitrum Sepolia)      |
+| -------------- | --------------------------------------------- | ------------------------------------------------ |
+| Remetente      | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`     |
+| Signatários    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`     |
+| Agregador      | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com`    |
 
 ### Requisitos
 
-In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+Além dos requisitos típicos para executar um indexador, é necessário um endpoint `tap-escrow-subgraph` para fazer queries de atualizações do TAP. É possível usar o The Graph Network para fazer queries ou se hospedar no seu `graph-node`.
 
-- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
-- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+- [Subgraph do TAP do The Graph — Arbitrum Sepolia (para a testnet do The Graph)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Subgraph do TAP do The Graph (para a mainnet do The Graph)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
 
-> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+> Nota: o `indexer-agent` atualmente não executa o indexamento deste subgraph como faz com o lançamento de subgraphs da rede. Portanto, ele deve ser anexado manualmente.
 
-## Migration Guide
+## Guia de migração
 
-### Software versions
+### Versões de software
 
-The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+O software necessário está [aqui](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
 
-### Steps
+### Passo a passo
 
-1. **Indexer Agent**
+1. **Agente Indexador**
 
-   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
-   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+   - Siga o [mesmo processo](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Insira o novo argumento `--tap-subgraph-endpoint` para ativar os novos caminhos de código e ativar o resgate de RAVs do TAP.
 
-2. **Indexer Service**
+2. **Serviço Indexador**
 
-   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
-   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+   - Substitua a sua configuração atual com o novo [rs do Serviço Indexador](https://github.com/graphprotocol/indexer-rs). Vale apena usar a [imagem recipiente](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Assim como a versão mais antiga, o Serviço Indexador pode ser horizontalmente escalado com facilidade. Neste caso, ainda não mantém memória.
 
-3. **TAP Agent**
+3. **Agente do TAP**
 
-   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Execute _uma_ instância do [Agente do TAP](https://github.com/graphprotocol/indexer-rs) constantemente. Recomendamos usar a [imagem recipiente](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
 
-4. **Configure Indexer Service and TAP Agent**
+4. **Configuração do Serviço Indexador e Agente do TAP**
 
-   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+   A configuração está num arquivo TOML compartilhado entre `indexer-service` e `tap-agent`, providenciada com o argumento `--config /path/to/config.toml`.
 
-   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+   Veja a íntegra da [configuração](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) e os [valores padrão](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
 
-For minimal configuration, use the following template:
+Para o mínimo de configuração, veja o exemplo abaixo:
 
 ```bash
-# You will have to change *all* the values below to match your setup.
+# Você deve mudar *todos* os valores abaixo para mudar sua configuração.
 #
-# Some of the config below are global graph network values, which you can find here:
+# O abaixo inclui valores globais da Graph Network, como visto aqui:
 # <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
 #
-# Pro tip: if you need to load some values from the environment into this config, you
-# can overwrite with environment variables. For example, the following can be replaced
-# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+# Fica a dica: se precisar carregar alguns variáveis do ambiente nesta configuração, você
+# pode substituí-los com variáveis do ambiente. Por exemplo: pode-se substituir
+# o abaixo por [PREFIX]_DATABASE_POSTGRESURL, onde PREFIX pode ser `INDEXER_SERVICE` ou `TAP_AGENT`:
 #
 # [database]
 # postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
@@ -116,9 +116,9 @@ indexer_address = "0x1111111111111111111111111111111111111111"
 operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
 
 [database]
-# The URL of the Postgres database used for the indexer components. The same database
-# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
-# the necessary tables.
+# A URL da base de dados Postgres usada para os componentes do indexador.
+# A mesma base de dados usada pelo `indexer-agent`. Espera-se que o `indexer-agent`
+# criará as tabelas necessárias.
 postgres_url = "postgres://postgres@postgres:5432/postgres"
 
 [graph_node]
@@ -128,11 +128,11 @@ query_url = "<http://graph-node:8000>"
 status_url = "<http://graph-node:8000/graphql>"
 
 [subgraphs.network]
-# Query URL for the Graph Network subgraph.
+# URL de query pro subgraph do Graph Network.
 query_url = "<http://example.com/network-subgraph>"
-# Optional, deployment to look for in the local `graph-node`, if locally indexed.
-# Locally indexing the subgraph is recommended.
-# NOTE: Use `query_url` or `deployment_id` only
+# Opcional, procure o lançamento no `graph-node` local, se localmente indexado.
+# Vale a pena indexar o subgraph localmente.
+# NOTA: Usar apenas `query_url` ou `deployment_id`
 deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
 
 [subgraphs.escrow]
@@ -144,50 +144,50 @@ query_url = "<http://example.com/network-subgraph>"
 deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
 
 [blockchain]
-# The chain ID of the network that the graph network is running on
+# ID de chain da rede que está a executar o Graph Network
 chain_id = 1337
-# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+# Endereço de contrato do verificador de prova de agregação de recibos do TAP.
 receipts_verifier_address = "0x2222222222222222222222222222222222222222"
 
 ########################################
-# Specific configurations to tap-agent #
+# Configurações específicas para o tap-agent #
 ########################################
 [tap]
-# This is the amount of fees you are willing to risk at any given time. For ex.
-# if the sender stops supplying RAVs for long enough and the fees exceed this
-# amount, the indexer-service will stop accepting queries from the sender
-# until the fees are aggregated.
-# NOTE: Use strings for decimal values to prevent rounding errors
-# e.g:
-# max_amount_willing_to_lose_grt = "0.1"
+# Esta é a quantia de taxas que você está disposto a arriscar. Por exemplo:
+# se o remetente parar de enviar RAVs por tempo suficiente e as taxas passarem
+# desta quantia, o indexer-service não aceitará mais queries deste remetente
+# até que as taxas sejam agregadas.
+# NOTA: Use strings para valores decimais, para evitar erros de arredondamento
+# Por exemplo:
+# max_amount_willing_to_lose_grt = "0,1"
 max_amount_willing_to_lose_grt = 20
 
 [tap.sender_aggregator_endpoints]
-# Key-Value of all senders and their aggregator endpoints
-# This one below is for the E&N testnet gateway for example.
-0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+# Valor-Chave de todos os remetentes e seus endpoints agregadores
+# Por exemplo, o abaixo é para a ponte de ligação do testnet Edge & Node.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://t
 ```
 
 Notas:
 
-- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
-- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+- Os valores de `tap.sender_aggregator_endpoints` estão na seção sobre [pontos de ligação](/indexing/tap/#gateway).
+- Os valores de `blockchain.receipts_verifier_address` devem ser usados conforme a [seção sobre endereços de blockchain](/indexing/tap/#contracts), usando a ID de chain apropriada.
 
-**Log Level**
+**Nível de Log**
 
-- You can set the log level by using the `RUST_LOG` environment variable.
-- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+- Os níveis de log podem ser ajustados pelo variável de ambiente `RUST_LOG`.
+- Recomendamos configurar para `RUST_LOG=indexer_tap_agent=debug,info`.
 
-## Monitoring
+## Monitoração
 
-### Metrics
+### Métricas
 
-All components expose the port 7300 to be queried by prometheus.
+Todos os componentes expõem a porta 7300 a queries do Prometheus.
 
-### Grafana Dashboard
+### Paineis de Controle com Grafana
 
-You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+O [painel de controlo do Grafana](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) pode ser baixado e importado.
 
-### Launchpad
+### Plataforma de Lançamento
 
-Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)
+Atualmente, há uma versão em obras do `indexer-rs` e `tap-agent` [aqui](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer).

From a4ddc57bccb518bcc7abc7178cf62b336d0921f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 09:32:34 -0500
Subject: [PATCH 2498/3820] New translations graph-node.mdx (Chinese
 Simplified)

---
 website/pages/zh/indexing/tooling/graph-node.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/indexing/tooling/graph-node.mdx b/website/pages/zh/indexing/tooling/graph-node.mdx
index 353ada8687dd..bccd6e534310 100644
--- a/website/pages/zh/indexing/tooling/graph-node.mdx
+++ b/website/pages/zh/indexing/tooling/graph-node.mdx
@@ -2,7 +2,7 @@
 title: Graph 节点
 ---
 
-Graph节点是索引子图的组件，并使生成的数据可通过GraphQL API进行查询。因此，它是索引人堆栈的中心，Graph节点的正确运作对于运行成功的索引人至关重要。
+Graph节点是索引子图的组件，并使生成的数据可通过GraphQL API进行查询。因此，它是索引器堆栈的中心，Graph节点的正确运作对于运行成功的索引器至关重要。
 
 This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
 

From 2f3a7c3a09d3cc3da0e8756fceba5decdf41f60e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:42 -0500
Subject: [PATCH 2499/3820] New translations from-an-application.mdx
 (Portuguese)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/pt/subgraphs/querying/from-an-application.mdx b/website/pages/pt/subgraphs/querying/from-an-application.mdx
index eaefab543ac5..87a57e48b69c 100644
--- a/website/pages/pt/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/pt/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Como Fazer Queries de um Aplicativo
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From b6c85f22b9c78183be7a0e2faed139b3b753c4b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:44 -0500
Subject: [PATCH 2500/3820] New translations from-an-application.mdx (Romanian)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/ro/subgraphs/querying/from-an-application.mdx b/website/pages/ro/subgraphs/querying/from-an-application.mdx
index 2e9b52d3dac7..4bf68fcf198b 100644
--- a/website/pages/ro/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ro/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Querying from an Application
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From d368eb481e4258c461f5747a1883f8f2df035e8d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:45 -0500
Subject: [PATCH 2501/3820] New translations from-an-application.mdx (French)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/fr/subgraphs/querying/from-an-application.mdx b/website/pages/fr/subgraphs/querying/from-an-application.mdx
index bc87a498bf7c..6243743e25fc 100644
--- a/website/pages/fr/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/fr/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Interrogation à partir d'une application
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From ae55d4b7809005bc28ce2e90de8671a2f0d31917 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:46 -0500
Subject: [PATCH 2502/3820] New translations from-an-application.mdx (Spanish)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/es/subgraphs/querying/from-an-application.mdx b/website/pages/es/subgraphs/querying/from-an-application.mdx
index b5eef7144695..644f53314dda 100644
--- a/website/pages/es/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/es/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Consultar desde una Aplicación
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From a1da3a815243a71f5a1ecc6ac2b0c14819725480 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:47 -0500
Subject: [PATCH 2503/3820] New translations from-an-application.mdx (Arabic)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/ar/subgraphs/querying/from-an-application.mdx b/website/pages/ar/subgraphs/querying/from-an-application.mdx
index 41f4681825c5..87e40d03caa4 100644
--- a/website/pages/ar/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ar/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: الاستعلام من التطبيق
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From aec89633fce0b41423297bce09e8f49ae41e28f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:48 -0500
Subject: [PATCH 2504/3820] New translations from-an-application.mdx (Czech)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/cs/subgraphs/querying/from-an-application.mdx b/website/pages/cs/subgraphs/querying/from-an-application.mdx
index fea08439d6a5..94bdc46311d4 100644
--- a/website/pages/cs/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/cs/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Dotazování z aplikace
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Podgraf Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Průzkumník grafů
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From f16014eaa9b793a74f8d2cfc5b45ff4536dec38a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:49 -0500
Subject: [PATCH 2505/3820] New translations from-an-application.mdx (German)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/de/subgraphs/querying/from-an-application.mdx b/website/pages/de/subgraphs/querying/from-an-application.mdx
index 510accf3c883..4cad958805b7 100644
--- a/website/pages/de/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/de/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Querying from an Application
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From b4d337e8257e7f09afa27622eca7b143805bd0e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:50 -0500
Subject: [PATCH 2506/3820] New translations from-an-application.mdx (Italian)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/it/subgraphs/querying/from-an-application.mdx b/website/pages/it/subgraphs/querying/from-an-application.mdx
index 7f4abd991e48..a0410d03c249 100644
--- a/website/pages/it/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/it/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Eseguire una query da un'applicazione
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From 990c4d4b0115e19b5e07ed72903d4051a50427b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:51 -0500
Subject: [PATCH 2507/3820] New translations from-an-application.mdx (Japanese)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/ja/subgraphs/querying/from-an-application.mdx b/website/pages/ja/subgraphs/querying/from-an-application.mdx
index 21f5c1eedd9a..78d6995c85cd 100644
--- a/website/pages/ja/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ja/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: アプリケーションからのクエリ
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### グラフエクスプローラ
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From f763a7c1eb80bf55ff0c87a10b001d92e2617ba3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:52 -0500
Subject: [PATCH 2508/3820] New translations from-an-application.mdx (Korean)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/ko/subgraphs/querying/from-an-application.mdx b/website/pages/ko/subgraphs/querying/from-an-application.mdx
index a9f8162ebcf0..6a3a13b8d141 100644
--- a/website/pages/ko/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ko/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Querying from an Application
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From c2497bf5bc05c850b93eef03208e900b95328ae0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:53 -0500
Subject: [PATCH 2509/3820] New translations from-an-application.mdx (Dutch)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/nl/subgraphs/querying/from-an-application.mdx b/website/pages/nl/subgraphs/querying/from-an-application.mdx
index 45c84601b934..7c5c99bc68ba 100644
--- a/website/pages/nl/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/nl/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Querying from an Application
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Verkenner
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From c9faf831e9a8ff3df8849d81a14d53186cd7bd70 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:54 -0500
Subject: [PATCH 2510/3820] New translations from-an-application.mdx (Polish)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/pl/subgraphs/querying/from-an-application.mdx b/website/pages/pl/subgraphs/querying/from-an-application.mdx
index 2198e511b69e..ea4138051254 100644
--- a/website/pages/pl/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/pl/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Querying from an Application
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From d57cbde81c90689c87ba0e378989c0c587af3bf4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:55 -0500
Subject: [PATCH 2511/3820] New translations from-an-application.mdx (Russian)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/ru/subgraphs/querying/from-an-application.mdx b/website/pages/ru/subgraphs/querying/from-an-application.mdx
index a0f1fde989db..e48aa0c6ffbf 100644
--- a/website/pages/ru/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ru/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Querying from an Application
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From 124fc75fb81e4cdc1ed7987ca035ccbaae454271 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:56 -0500
Subject: [PATCH 2512/3820] New translations from-an-application.mdx (Swedish)

---
 .../querying/from-an-application.mdx          | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/sv/subgraphs/querying/from-an-application.mdx b/website/pages/sv/subgraphs/querying/from-an-application.mdx
index 2a846eb05d74..56f70142ed52 100644
--- a/website/pages/sv/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/sv/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Att göra förfrågningar från en Applikation
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraf Studion
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graf Utforskaren
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -266,9 +266,9 @@ npm install urql graphql
 Query the API with the following code:
 
 ```javascript
-import { createClient } from "urql";
+import { createClient } from 'urql'
 
-const APIURL = "https://api.thegraph.com/subgraphs/name/username/subgraphname";
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -279,11 +279,11 @@ const tokensQuery = `
       metadataURI
     }
   }
-`;
+`
 
 const client = createClient({
   url: APIURL,
-});
+})
 
 const data = await client.query(tokensQuery).toPromise()
 ```

From 3c14f8907c5a89f21ecac3d405bc14065efad126 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:57 -0500
Subject: [PATCH 2513/3820] New translations from-an-application.mdx (Turkish)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/tr/subgraphs/querying/from-an-application.mdx b/website/pages/tr/subgraphs/querying/from-an-application.mdx
index 66d3fd5ceb52..6d175918c0de 100644
--- a/website/pages/tr/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/tr/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Querying from an Application
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Stüdyosu
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Gezgini
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From b5072467bcc18205539ef68200cf553574d21e47 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:23:59 -0500
Subject: [PATCH 2514/3820] New translations from-an-application.mdx
 (Ukrainian)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/uk/subgraphs/querying/from-an-application.mdx b/website/pages/uk/subgraphs/querying/from-an-application.mdx
index 621351066664..9268a2b9f5af 100644
--- a/website/pages/uk/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/uk/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Отримання запиту з додатка
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Субграф Студія
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From f0192caa36e2c1621cf596d4ee3c2ca9b5da093c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:24:00 -0500
Subject: [PATCH 2515/3820] New translations from-an-application.mdx (Chinese
 Simplified)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/zh/subgraphs/querying/from-an-application.mdx b/website/pages/zh/subgraphs/querying/from-an-application.mdx
index fe6f55cf7e8c..600e2ac1bc3f 100644
--- a/website/pages/zh/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/zh/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: 从应用程序中进行查询
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### 子图工作室
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph 浏览器
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From 4ef39e1b1f4f031cf43266b6838c3840bd9b44a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:24:01 -0500
Subject: [PATCH 2516/3820] New translations from-an-application.mdx (Urdu
 (Pakistan))

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/ur/subgraphs/querying/from-an-application.mdx b/website/pages/ur/subgraphs/querying/from-an-application.mdx
index edad71b9c05f..784aded3f229 100644
--- a/website/pages/ur/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ur/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: ایپلیکیشن سے کیوری
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### سب گراف سٹوڈیو
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### گراف ایکسپلورر
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From 0b67d35859cbdf07e0125fae2edf17fbda2cc1a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:24:02 -0500
Subject: [PATCH 2517/3820] New translations from-an-application.mdx
 (Vietnamese)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/vi/subgraphs/querying/from-an-application.mdx b/website/pages/vi/subgraphs/querying/from-an-application.mdx
index 91c7faf04ea2..644393dc5b57 100644
--- a/website/pages/vi/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/vi/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Truy vấn từ một ứng dụng
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Trình khám phá Graph
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From df7d8f203c24833da7afd7210cd47a6fbcc7f902 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:24:03 -0500
Subject: [PATCH 2518/3820] New translations from-an-application.mdx (Marathi)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/mr/subgraphs/querying/from-an-application.mdx b/website/pages/mr/subgraphs/querying/from-an-application.mdx
index cd8f118b6db8..3a8fa9c0c411 100644
--- a/website/pages/mr/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/mr/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Querying from an Application
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From a71b664f42b8839cf0b56a9d4f31cb9aebaf3005 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:24:04 -0500
Subject: [PATCH 2519/3820] New translations from-an-application.mdx (Hindi)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/hi/subgraphs/querying/from-an-application.mdx b/website/pages/hi/subgraphs/querying/from-an-application.mdx
index 011c56be7050..e219768992ea 100644
--- a/website/pages/hi/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/hi/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: एक एप्लिकेशन से क्वेरी करना
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From 23b07cf5efa6034d80b72c03679716866631d2bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 15:24:05 -0500
Subject: [PATCH 2520/3820] New translations from-an-application.mdx (Swahili)

---
 .../subgraphs/querying/from-an-application.mdx   | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/sw/subgraphs/querying/from-an-application.mdx b/website/pages/sw/subgraphs/querying/from-an-application.mdx
index a9f8162ebcf0..6a3a13b8d141 100644
--- a/website/pages/sw/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/sw/subgraphs/querying/from-an-application.mdx
@@ -4,17 +4,17 @@ title: Querying from an Application
 
 Learn how to query The Graph from your application.
 
-## Getting GraphQL Endpoint
+## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will be given the endpoint for your GraphQL API that should look something like this:
+Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
 
-### Subgraph Studio
+### Subgraph Studio Endpoint
 
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Graph Explorer
+### Network Endpoint
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
@@ -88,11 +88,11 @@ sources:
   - name: uniswapv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
   - name: compoundv2
     handler:
       graphql:
-        endpoint: https://api.thegraph.com/subgraphs/name/graphprotocol/compound-v2
+        endpoint: https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 
 documents:
   - ./src/example-query.graphql
@@ -179,7 +179,7 @@ Query the API with the following code:
 ```javascript
 import { ApolloClient, InMemoryCache, gql } from '@apollo/client'
 
-const APIURL = 'https://api.studio.thegraph.com/query//<SUBGRAPH_NAME>/'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {
@@ -268,7 +268,7 @@ Query the API with the following code:
 ```javascript
 import { createClient } from 'urql'
 
-const APIURL = 'https://api.thegraph.com/subgraphs/name/username/subgraphname'
+const APIURL = 'https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>'
 
 const tokensQuery = `
   query {

From a28b8699cc7e51f337140d8eab3cbdb144aee765 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:44 -0500
Subject: [PATCH 2521/3820] New translations triggers.mdx (Portuguese)

---
 website/pages/pt/substreams/sps/triggers.mdx | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/pt/substreams/sps/triggers.mdx b/website/pages/pt/substreams/sps/triggers.mdx
index a923fe40ec78..363f58e1db75 100644
--- a/website/pages/pt/substreams/sps/triggers.mdx
+++ b/website/pages/pt/substreams/sps/triggers.mdx
@@ -1,12 +1,12 @@
 ---
-title: Substreams Triggers
+title: Gatilhos do Substreams
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Com gatilhos personalizados, é possível enviar dados diretamente ao seu arquivo de mapeamentos e entidades do subgraph (assim como tabelas e campos), assim permitindo uso completo da camada do GraphQL. Para receber e processar esses dados no handler do seu subgraph, importe as definições do Protobuf emitidas pelo seu módulo do Substreams; isto garante uma gerência de dados eficiente e simplificada dentro da estrutura do subgraph.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+> Nota: se já não tiver feito isso, visite um dos guias aqui para armar o seu primeiro projeto no Recipiente de Programação.
 
-The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+O código a seguir demonstra como definir uma função `handleTransactions` num handler de subgraph. Esta função recebe bytes brutos do Substreams como um parâmetro e os decodifica num objeto `Transactions`. Uma nova entidade de subgraph é criada para cada transação.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
@@ -28,10 +28,10 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Você verá isto no arquivo `mappings.ts`:
 
-1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
-2. Looping over the transactions
-3. Create a new subgraph entity for every transaction
+1. Os bytes contendo dados do Substreams são descodificados no objeto `Transactions` gerado; este é usado como qualquer outro objeto AssemblyScript
+2. Um loop sobre as transações
+3. Uma nova entidade de subgraph é criada para cada transação
 
-To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).
+Para ver um exemplo detalhado de um subgraph baseado em gatilhos, [clique aqui](/substreams/sps/tutorial/).

From 8b5be40797980a051ce092b0a5aec2a4b260a443 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:45 -0500
Subject: [PATCH 2522/3820] New translations quick-start.mdx (Portuguese)

---
 website/pages/pt/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/pt/subgraphs/quick-start.mdx b/website/pages/pt/subgraphs/quick-start.mdx
index 7a98b37dc814..23980d4e71db 100644
--- a/website/pages/pt/subgraphs/quick-start.mdx
+++ b/website/pages/pt/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Quando o seu subgraph estiver escrito, execute os seguintes comandos:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From acb0d5578a263dc8eff5aefe302680094aa9812e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:46 -0500
Subject: [PATCH 2523/3820] New translations introduction.mdx (Portuguese)

---
 website/pages/pt/substreams/sps/introduction.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/pt/substreams/sps/introduction.mdx b/website/pages/pt/substreams/sps/introduction.mdx
index bacd601bd011..b9cfff942514 100644
--- a/website/pages/pt/substreams/sps/introduction.mdx
+++ b/website/pages/pt/substreams/sps/introduction.mdx
@@ -1,18 +1,18 @@
 ---
-title: Introduction to Substreams-Powered Subgraphs
+title: Introudução a Subgraphs Movidos pelo Substreams
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Ao usar um pacote Substreams (`.spkg`) como fonte de dados, o seu subgraph ganha acesso a um fluxo de dados de blockchain pré-indexados. Isto permite um tratamento de dados mais eficiente e escalável, especialmente com redes de blockchain grandes ou complexas.
 
-There are two methods of enabling this technology:
+Há dois metodos de ativar esta tecnologia:
 
-Using Substreams [triggers](/substreams/sps/triggers/): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+Usar [gatilhos](/substreams/sps/triggers/): Isto importa o modelo do Protobuf por um handler de subgraph, permitindo que o utilizador consuma de qualquer módulo do Substreams e mude toda a sua lógica para um subgraph. Este método cria as entidades diretamente no subgraph.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+[Mudanças de Entidade](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): Ao inserir mais da lógica no Substreams, pode-se alimentar o rendimento do módulo diretamente no graph-node. No graph-node, os dados do Substreams podem ser usados para criar as entidades do seu subgraph.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+É realmente uma questão de onde colocar a sua lógica: no subgráfico ou no Substreams. Lembre-se que ter mais da sua lógica nos Substreams tira proveito de um modelo paralelizado, enquanto os gatilhos serão consumidos linearmente no graph-node.
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visite os seguintes links para ver guias passo-a-passo, sobre usar ferramentas de geração de código para construir o seu primeiro projeto end-to-end rapidamente:
 
 - [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
 - [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)

From 416078c76ba6fa0ff94b1b7468d06b268d06f598 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:47 -0500
Subject: [PATCH 2524/3820] New translations sps-faq.mdx (Portuguese)

---
 website/pages/pt/substreams/sps/sps-faq.mdx | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/pt/substreams/sps/sps-faq.mdx b/website/pages/pt/substreams/sps/sps-faq.mdx
index 55ba2bdea1a9..1656c4bc42ff 100644
--- a/website/pages/pt/substreams/sps/sps-faq.mdx
+++ b/website/pages/pt/substreams/sps/sps-faq.mdx
@@ -1,24 +1,24 @@
 ---
-title: Substreams-Powered Subgraphs FAQ
+title: "Perguntas Frequentes: Subgraphs Movidos pelo Substreams"
 ---
 
 ## O que são Substreams?
 
 Desenvolvido pela [StreamingFast](https://www.streamingfast.io/), o Substreams é um motor de processamento de poder excepcional, capaz de consumir fluxos ricos de dados em blockchain. O Substreams lhe permite refinar e moldar dados em blockchain para serem digeridos rápida e suavemente por aplicativos de utilizador final. Mais especificamente, o Substreams é um motor paralelizado e agnóstico a blockchains, que põe transmissões em primeiro lugar e serve como uma camada de transformação de dados em blockchain. Movido pelo [Firehose](https://firehose.streamingfast.io/), ele permite que programadores escrevam módulos em Rust, construam sobre módulos da comunidade, providenciem indexações de altíssimo desempenho, e mandar seus dados para qualquer destino com [sink](https://substreams.streamingfast.io/reference-and-specs/manifests#sink).
 
-Go to the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+Para saber mais sobre o Substreams, veja a [documentação oficial](/substreams/introduction/).
 
 ## O que são subgraphs movidos por substreams?
 
-[Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs), which are compatible with subgraph entities.
+[Subgraphs movidos pelo Substreams](/subgraphs/cookbook/substreams-powered-subgraphs/) trazem o poder do Substreams aos queries de subgraphs. Ao publicar um subgraph movido pelo Substreams, os dados produzidos pelas transformações do Substreams podem [produzir mudanças de entidade](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) compatíveis com entidades de subgraph.
 
 Se você já for familiar com a programação de subgraphs, então note que subgraphs movidos a Substreams podem ser consultados do mesmo jeito que se tivessem sido produzidos pela camada de transformação em AssemblyScript, com todos os benefícios do Subgraph, como a providência de uma API GraphQL dinâmica e flexível.
 
 ## Como subgraphs movidos a Substreams são diferentes de subgraphs?
 
-Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+Os subgraphs são compostos de fontes de dados que especificam eventos on-chain, e como transformar estes eventos através de handlers escritos em AssemblyScript. Estes eventos são processados em sequência, com base na ordem em que acontecem na chain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+Por outro lado, subgraphs movidos a substreams têm uma única fonte de dados que referencia um pacote de substreams, processado pelo Graph Node. Substreams têm acesso a mais dados granulares on-chain em comparação a subgraphs convencionais, e também podem se beneficiar de um processamento paralelizado em massa, o que pode diminuir a espera do processamento.
 
 ## Quais os benefícios do uso de subgraphs movidos a Substreams?
 
@@ -62,9 +62,9 @@ Há muitos benefícios do uso do Firehose, que incluem:
 
 ## Onde programadores podem acessar mais informações sobre Substreams e subgraphs movidos a Substreams?
 
-The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+Para aprender como construir módulos do Substreams, leia a [documentação do Substreams](/substreams/introduction/).
 
-The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
+Para aprender como empacotar subgraphs e lançá-los no The Graph, veja a [documentação sobre subgraphs movidos pelo Substreams](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 A [ferramenta de Codegen no Substreams mais recente](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) permitirá ao programador inicializar um projeto no Substreams sem a necessidade de código.
 
@@ -82,7 +82,7 @@ Como exemplo, Fulana pode construir um módulo de preço de DEX, Sicrano pode us
 
 ## Como construir e publicar um Subgraph movido a Substreams?
 
-After [defining](/subgraphs/cookbook/substreams-powered-subgraphs/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+Após [definir](/subgraphs/cookbook/substreams-powered-subgraphs/) um subgraph movido pelo Substreams, pode-se usar a Graph CLI para lançá-lo np [Subgraph Studio](https://thegraph.com/studio/).
 
 ## Onde posso encontrar exemplos de Substreams e subgraphs movidos a Substreams?
 

From 204a7a35cb736bf63339d64f8570007352c4feb9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:48 -0500
Subject: [PATCH 2525/3820] New translations tutorial.mdx (Portuguese)

---
 website/pages/pt/substreams/sps/tutorial.mdx | 64 +++++++-------------
 1 file changed, 23 insertions(+), 41 deletions(-)

diff --git a/website/pages/pt/substreams/sps/tutorial.mdx b/website/pages/pt/substreams/sps/tutorial.mdx
index 503fcdeab65e..ced47a666e49 100644
--- a/website/pages/pt/substreams/sps/tutorial.mdx
+++ b/website/pages/pt/substreams/sps/tutorial.mdx
@@ -1,61 +1,43 @@
 ---
-title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+title: "Tutorial: Como Montar um Subgraph Movido a Substreams na Solana"
 ---
 
 ## Pré-requisitos
 
-Before starting, make sure to:
+Antes de começar:
 
-- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
-- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+- Complete o [Guia de Introdução](https://github.com/streamingfast/substreams-starter) para montar o seu ambiente de programação com um Recipiente de Programação.
+- Familiarize-se com o The Graph e conceitos básicos de blockchain, como transações e Protobufs.
 
-## Step 1: Initialize Your Project
+## Passo 1: Inicialize o Seu Projeto
 
 <VideoEmbed youtube="RmKi-Nq9E_A" />
 
-1. Open your Dev Container and run the following command to initialize your project:
+1. Para inicializar o seu projeto, abra o seu Recipiente e execute o seguinte comando:
 
    ```bash
    substreams init
    ```
 
-2. Select the "minimal" project option.
+2. Selecione a opção de projeto "minimal" (mínimo).
 
-3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+3. Troque os conteúdos do arquivo `substreams.yaml` gerado com a seguinte configuração, que filtra transações para a conta do Orca no ID de programa do token da SPL:
 
 ```yaml
-specVersion: v0.1.0
-package:
-  name: my_project_sol
-  version: v0.1.0
-
-imports: # Pass your spkg of interest
-  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
-
-modules:
-  - name: map_spl_transfers
-    use: solana:map_block # Select corresponding modules available within your spkg
-    initialBlock: 260000082
-
-  - name: map_transactions_by_programid
-    use: solana:solana:transactions_by_programid_without_votes
-
-network: solana-mainnet-beta
-
-params: # Modify the param fields to meet your needs
+params: # Modifique os parâmetros a seu gosto
   # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
   map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
 ```
 
-## Step 2: Generate the Subgraph Manifest
+## Passo 2: Crie o Manifest do Subgraph
 
-Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+Com o projeto inicializado, gere um manifest de subgraph com o seguinte comando no Recipiente de Programação:
 
 ```bash
 substreams codegen subgraph
 ```
 
-You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+Será gerado um manifest `subgraph.yaml` que importa o pacote do Substreams como uma fonte de dados:
 
 ```yaml
 ---
@@ -65,7 +47,7 @@ dataSources:
     network: solana-mainnet-beta
     source:
       package:
-        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        moduleName: map_spl_transfers # Módulo definido em substreams.yaml
         file: ./my-project-sol-v0.1.0.spkg
     mapping:
       apiVersion: 0.0.7
@@ -74,9 +56,9 @@ dataSources:
       handler: handleTriggers
 ```
 
-## Step 3: Define Entities in `schema.graphql`
+## Passo 3: Defina as Entidades em `schema.graphql`
 
-Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file. Here is an example:
+Para definir os campos a guardar nas suas entidades de subgraph, suba o arquivo `schema.graphql`. Por exemplo:
 
 ```graphql
 type MyTransfer @entity {
@@ -88,11 +70,11 @@ type MyTransfer @entity {
 }
 ```
 
-This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+Este schema define uma entidade `MyTransfer` com campos como `id`, `amount`, `source`, `designation`, e `signers`.
 
-## Step 4: Handle Substreams Data in `mappings.ts`
+## Passo 4: Controle Dados do Substreams no `mappings.ts`
 
-With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory. The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+Com os objetos do Protobuf gerados, agora é possível manusear os dados do Substreams no seu arquivo `mappings.ts`, no diretório `./src`. Veja um exemplo de como extrair as transferências não derivadas associadas à ID de conta do Orca para entidades de subgraphs:
 
 ```ts
 import { Protobuf } from 'as-proto/assembly'
@@ -123,18 +105,18 @@ export function handleTriggers(bytes: Uint8Array): void {
 }
 ```
 
-## Step 5: Generate Protobuf Files
+## Passo 5: Crie Arquivos de Protobuf
 
-To generate Protobuf objects in AssemblyScript, run the following command:
+Para gerar objetos do Protobuf no AssemblyScript, execute:
 
 ```bash
 npm run protogen
 ```
 
-This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+Este comando converte as definições do Protobuf em AssemblyScript, permitindo o uso destas no handler do subgraph.
 
 ## Conclusão
 
-You’ve successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can now further customize your schema, mappings, and modules to suit your specific use case.
+Parabéns! Está montado um subgraph movido a Substreams, baseado em gatilhos, para um token da SPL da Solana. Agora dá para personalizar mais o seu schema, seus mapeamentos, e os seus módulos de modo que combinem com o seu caso de uso específico.
 
-For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).
+Para otimizações e personalizações mais avançadas, veja a [documentação oficial do Substreams](https://substreams.streamingfast.io/tutorials/solana).

From 20223bcb8a07b479e38a680210bef1af8e092a42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:49 -0500
Subject: [PATCH 2526/3820] New translations quick-start.mdx (Romanian)

---
 website/pages/ro/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/ro/subgraphs/quick-start.mdx b/website/pages/ro/subgraphs/quick-start.mdx
index 13af8f0deb42..dc280ec699d3 100644
--- a/website/pages/ro/subgraphs/quick-start.mdx
+++ b/website/pages/ro/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Once your subgraph is written, run the following commands:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From 85551cd2b270463902636ee2ba72561253080da4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:50 -0500
Subject: [PATCH 2527/3820] New translations quick-start.mdx (French)

---
 website/pages/fr/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/fr/subgraphs/quick-start.mdx b/website/pages/fr/subgraphs/quick-start.mdx
index 710214931cad..21489fe8a58d 100644
--- a/website/pages/fr/subgraphs/quick-start.mdx
+++ b/website/pages/fr/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Déployer votre subgraph
 
-N'oubliez pas que déployer n'est pas la même chose que publier.
+> Remember, deploying is not the same as publishing.
 
-Lorsque vous déployez un subgraph, vous le poussez vers [Subgraph Studio](https://thegraph.com/studio/), où vous pouvez le tester, le mettre en scène/préproduction et l'examiner.
-
-Lorsque vous publiez un subgraph, vous le publiez sur la blockchain vers le réseau décentralisé.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Une fois votre subgraph écrit, exécutez les commandes suivantes :
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publier votre subgraph sur The Graph Network⁠
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publier avec Subgraph Studio⁠
 

From 20238eaea0044759a05b3e115e4a3031583a8d43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:51 -0500
Subject: [PATCH 2528/3820] New translations quick-start.mdx (Spanish)

---
 website/pages/es/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/es/subgraphs/quick-start.mdx b/website/pages/es/subgraphs/quick-start.mdx
index 7baa8638c0b1..2399c450fbcb 100644
--- a/website/pages/es/subgraphs/quick-start.mdx
+++ b/website/pages/es/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Una vez escrito tu subgrafo, ejecuta los siguientes comandos:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From 87aa0a43f5d39dffadac712c377bd0ab62e94b0a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:52 -0500
Subject: [PATCH 2529/3820] New translations quick-start.mdx (Arabic)

---
 website/pages/ar/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/ar/subgraphs/quick-start.mdx b/website/pages/ar/subgraphs/quick-start.mdx
index 0c5cde32121a..a18d778920bc 100644
--- a/website/pages/ar/subgraphs/quick-start.mdx
+++ b/website/pages/ar/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 عند كتابة غرافك الفرعي، قم بتنفيذ الأوامر التالية:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From ba1c8fd57443f5cdeaedeb8c8e412d3ced1593d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:54 -0500
Subject: [PATCH 2530/3820] New translations quick-start.mdx (Czech)

---
 website/pages/cs/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/cs/subgraphs/quick-start.mdx b/website/pages/cs/subgraphs/quick-start.mdx
index 40e3d4ff4d74..cb2871ab6171 100644
--- a/website/pages/cs/subgraphs/quick-start.mdx
+++ b/website/pages/cs/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Jakmile je podgraf napsán, spusťte následující příkazy:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From 8b76617e5d0d5e9bb26d7e6e4a87b0155b0fcf46 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:55 -0500
Subject: [PATCH 2531/3820] New translations quick-start.mdx (German)

---
 website/pages/de/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/de/subgraphs/quick-start.mdx b/website/pages/de/subgraphs/quick-start.mdx
index f65232b018dc..b392bb1149c1 100644
--- a/website/pages/de/subgraphs/quick-start.mdx
+++ b/website/pages/de/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ Mit dem folgenden Befehl wird Ihr Subgraph aus einem bestehenden Vertrag initial
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Denken Sie daran, dass die Bereitstellung nicht dasselbe ist wie die Veröffentlichung.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Sobald Ihr Subgraph geschrieben ist, führen Sie die folgenden Befehle aus:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Veröffentlichung mit Subgraph Studio
 

From bb3f86703e5f549000c02370080dc1e76b83c041 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:56 -0500
Subject: [PATCH 2532/3820] New translations quick-start.mdx (Italian)

---
 website/pages/it/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/it/subgraphs/quick-start.mdx b/website/pages/it/subgraphs/quick-start.mdx
index 5116a02ab024..f50aeb094116 100644
--- a/website/pages/it/subgraphs/quick-start.mdx
+++ b/website/pages/it/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Once your subgraph is written, run the following commands:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From 3a06d442cbd106fa88aed261be1b67b21f7baa72 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:57 -0500
Subject: [PATCH 2533/3820] New translations quick-start.mdx (Japanese)

---
 website/pages/ja/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/ja/subgraphs/quick-start.mdx b/website/pages/ja/subgraphs/quick-start.mdx
index 88602845e7ae..8ff623cf5dad 100644
--- a/website/pages/ja/subgraphs/quick-start.mdx
+++ b/website/pages/ja/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 サブグラフが作成されたら、次のコマンドを実行します。
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From 04fb88cdaad4615accd2b32c70a6272629a77b96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:58 -0500
Subject: [PATCH 2534/3820] New translations quick-start.mdx (Korean)

---
 website/pages/ko/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/ko/subgraphs/quick-start.mdx b/website/pages/ko/subgraphs/quick-start.mdx
index 13af8f0deb42..dc280ec699d3 100644
--- a/website/pages/ko/subgraphs/quick-start.mdx
+++ b/website/pages/ko/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Once your subgraph is written, run the following commands:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From 5277de199c404ef7d8a4259901c91da4d702ab39 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:09:59 -0500
Subject: [PATCH 2535/3820] New translations quick-start.mdx (Dutch)

---
 website/pages/nl/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/nl/subgraphs/quick-start.mdx b/website/pages/nl/subgraphs/quick-start.mdx
index 6e2435436593..299b2a3f4502 100644
--- a/website/pages/nl/subgraphs/quick-start.mdx
+++ b/website/pages/nl/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Once your subgraph is written, run the following commands:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From 78448eefd57730bb43156e07b188a64490a1f55f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:10:00 -0500
Subject: [PATCH 2536/3820] New translations quick-start.mdx (Polish)

---
 website/pages/pl/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/pl/subgraphs/quick-start.mdx b/website/pages/pl/subgraphs/quick-start.mdx
index 02801a7032a6..a441ade161c2 100644
--- a/website/pages/pl/subgraphs/quick-start.mdx
+++ b/website/pages/pl/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Once your subgraph is written, run the following commands:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From 2985dc011b003acd00bb7d95552e340de27b5850 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:10:01 -0500
Subject: [PATCH 2537/3820] New translations quick-start.mdx (Russian)

---
 website/pages/ru/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/ru/subgraphs/quick-start.mdx b/website/pages/ru/subgraphs/quick-start.mdx
index c78e441da896..e029315a3adf 100644
--- a/website/pages/ru/subgraphs/quick-start.mdx
+++ b/website/pages/ru/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The `graph init` command will automatically create a scaffold of a subgraph base
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 При инициализации субграфа CLI запросит у Вас следующую информацию:
 
@@ -82,11 +82,9 @@ If your contract was verified on Etherscan, then the ABI will automatically be c
 
 ### 5. Развертывание Вашего субграфа
 
-Помните, развертывание — это не то же самое, что публикация.
+> Remember, deploying is not the same as publishing.
 
-Когда Вы развертываете субграф, Вы загружаете его в [Subgraph Studio](https://thegraph.com/studio/), где можете его протестировать, подготовить и просмотреть.
-
-Когда Вы публикуете субграф, Вы публикуете его в децентрализованной сети на чейне.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 После того как Ваш субграф будет написан, выполните следующие команды:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### Публикация Вашего субграфа в сети The Graph
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Публикация с помощью Subgraph Studio
 

From 72f9dc5a7c93c4ccbea57eb453d1b9e2672afe34 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:10:02 -0500
Subject: [PATCH 2538/3820] New translations quick-start.mdx (Swedish)

---
 website/pages/sv/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/sv/subgraphs/quick-start.mdx b/website/pages/sv/subgraphs/quick-start.mdx
index 4cde193daafd..2184ca0984c7 100644
--- a/website/pages/sv/subgraphs/quick-start.mdx
+++ b/website/pages/sv/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 När din subgraf är skriven, kör följande kommandon:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From 59b0a71b1be2be0284a1ec0634252af09e35045d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:10:04 -0500
Subject: [PATCH 2539/3820] New translations quick-start.mdx (Turkish)

---
 website/pages/tr/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/tr/subgraphs/quick-start.mdx b/website/pages/tr/subgraphs/quick-start.mdx
index 96a7e63b1f92..f168fa1d9e55 100644
--- a/website/pages/tr/subgraphs/quick-start.mdx
+++ b/website/pages/tr/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ Aşağıdaki komut, subgraph'inizi mevcut bir akıllı sözleşmeden başlatır:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 Subgraph'inizi başlattığınızda, CLI sizden aşağıdaki bilgileri isteyecektir:
 
@@ -82,11 +82,9 @@ Subgraph yazımı hakkında ayrıntılı bilgi için [Subgraph Oluşturma](/deve
 
 ### 5. Subgraph'inizi yayına alın
 
-Unutmayın; yayına almak, yayımlamakla aynı şey değildir.
+> Remember, deploying is not the same as publishing.
 
-Bir subgraph'i yayına aldığınızda, onu [Subgraph Studio](https://thegraph.com/studio/)'ya gönderirsiniz; burada subgraph'i test edebilir, yayına almaya hazırlayabilir ve inceleyebilirsiniz.
-
-Bir subgraph'i yayımladığınızda, onu merkeziyetsiz ağda, zincir üzerinde yayımlamış olursunuz.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Subgraph'ınız yazıldıktan sonra aşağıdaki komutları çalıştırın:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Subgraph'inizi The Graph Ağında yayımlayın
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Subgraph Studio ile yayımlama
 

From f12c6f3992232701c53d6693ce8194430540cc99 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:10:05 -0500
Subject: [PATCH 2540/3820] New translations quick-start.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/uk/subgraphs/quick-start.mdx b/website/pages/uk/subgraphs/quick-start.mdx
index e4e7de66f246..750a05b74a2d 100644
--- a/website/pages/uk/subgraphs/quick-start.mdx
+++ b/website/pages/uk/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Як тільки ваш підграф буде написаний, виконайте наступні команди:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From cfeaa56430720ed9130c69cc6ce78367784fce74 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:10:06 -0500
Subject: [PATCH 2541/3820] New translations quick-start.mdx (Chinese
 Simplified)

---
 website/pages/zh/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/zh/subgraphs/quick-start.mdx b/website/pages/zh/subgraphs/quick-start.mdx
index 90b4a43d6fef..cb67c21570dd 100644
--- a/website/pages/zh/subgraphs/quick-start.mdx
+++ b/website/pages/zh/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 一旦您的子图被编写好，请运行以下命令：
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From c1870fb34c786f835c95dc8bdb7a14e3eb01e97f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:10:07 -0500
Subject: [PATCH 2542/3820] New translations quick-start.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/ur/subgraphs/quick-start.mdx b/website/pages/ur/subgraphs/quick-start.mdx
index 5f1ebfb4a686..6a31d74bea41 100644
--- a/website/pages/ur/subgraphs/quick-start.mdx
+++ b/website/pages/ur/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 ایک بار آپ کا سب گراف لکھا جائے، درج ذیل کمانڈز رن کریں:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From a3b5e0450221f16dd9f47e665a8a64d4eec1d239 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:10:08 -0500
Subject: [PATCH 2543/3820] New translations quick-start.mdx (Vietnamese)

---
 website/pages/vi/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/vi/subgraphs/quick-start.mdx b/website/pages/vi/subgraphs/quick-start.mdx
index e41c12dfdc4c..8394150dac02 100644
--- a/website/pages/vi/subgraphs/quick-start.mdx
+++ b/website/pages/vi/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Once your subgraph is written, run the following commands:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From 0c34a0e4c79cf7ce47ddb80d02518e0f965e66ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:10:09 -0500
Subject: [PATCH 2544/3820] New translations quick-start.mdx (Marathi)

---
 website/pages/mr/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/mr/subgraphs/quick-start.mdx b/website/pages/mr/subgraphs/quick-start.mdx
index 40ecc489c838..3236177accc4 100644
--- a/website/pages/mr/subgraphs/quick-start.mdx
+++ b/website/pages/mr/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 तुमचा सबग्राफ लिहिल्यानंतर, खालील आदेश चालवा:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From 474879abf8c1bed087458b504ed94614b850c7f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:10:10 -0500
Subject: [PATCH 2545/3820] New translations quick-start.mdx (Hindi)

---
 website/pages/hi/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/hi/subgraphs/quick-start.mdx b/website/pages/hi/subgraphs/quick-start.mdx
index 7728088cdfd8..b7f728ba813b 100644
--- a/website/pages/hi/subgraphs/quick-start.mdx
+++ b/website/pages/hi/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The `graph init` command will automatically create a scaffold of a subgraph base
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 जब आप अपने subgraph को प्रारंभ करते हैं, CLI आपसे निम्नलिखित जानकारी मांगेगा:
 
@@ -82,11 +82,9 @@ If your contract was verified on Etherscan, then the ABI will automatically be c
 
 ### 5. अपने Subgraph का परीक्षण करें
 
-याद रखें, तैनाती और प्रकाशन एक समान नहीं हैं।
+> Remember, deploying is not the same as publishing.
 
-जब आप एक सबग्राफ तैनात करते हैं, तो आप इसे [सबग्राफ स्टूडियो](https://thegraph.com/studio/) पर भेजते हैं, जहां आप इसे परीक्षण, चरणबद्ध और समीक्षा कर सकते हैं।
-
-जब आप एक Subgraph प्रकाशित करते हैं, तो आप इसे विकेंद्रीकृत नेटवर्क पर ऑन-चेन प्रकाशित कर रहे हैं।
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 एक बार आपका सबग्राफ लिखे जाने के बाद, निम्नलिखित कमांड चलाएँ:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. अपने Subgraph को ग्राफ़ के The Graph Network पर प्रकाशित करें
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Subgraph Studio से प्रकाशित
 

From 1648e8cf86e76bed28541b83f56e836274f3fd16 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 16 Jan 2025 17:10:11 -0500
Subject: [PATCH 2546/3820] New translations quick-start.mdx (Swahili)

---
 website/pages/sw/subgraphs/quick-start.mdx | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/website/pages/sw/subgraphs/quick-start.mdx b/website/pages/sw/subgraphs/quick-start.mdx
index 13af8f0deb42..dc280ec699d3 100644
--- a/website/pages/sw/subgraphs/quick-start.mdx
+++ b/website/pages/sw/subgraphs/quick-start.mdx
@@ -49,7 +49,7 @@ The following command initializes your subgraph from an existing contract:
 graph init
 ```
 
-If your contract was verified on Etherscan, then the ABI will automatically be created in the CLI.
+If your contract is verified on the respective blockscanner where it is deployed (such as [Etherscan](https://etherscan.io/)), then the ABI will automatically be created in the CLI.
 
 When you initialize your subgraph, the CLI will ask you for the following information:
 
@@ -82,11 +82,9 @@ For a detailed breakdown on how to write your subgraph, check out [Creating a Su
 
 ### 5. Deploy your subgraph
 
-Remember, deploying is not the same as publishing.
+> Remember, deploying is not the same as publishing.
 
-When you deploy a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it.
-
-When you publish a subgraph, you are publishing it onchain to the decentralized network.
+When you **deploy** a subgraph, you push it to [Subgraph Studio](https://thegraph.com/studio/), where you can test, stage and review it. A deployed subgraph's indexing is performed by the [Upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/), which is a single Indexer owned and operated by Edge & Node, rather than by the many decentralized Indexers in The Graph Network. A **deployed** subgraph is free to use, rate-limited, not visible to the public, and meant to be used for development, staging, and testing purposes.
 
 Once your subgraph is written, run the following commands:
 
@@ -123,7 +121,13 @@ If you’d like to test your subgraph before publishing it, you can use [Subgrap
 
 ### 7. Publish your subgraph to The Graph Network
 
-Publishing a subgraph to the decentralized network is an onchain action that makes your subgraph available for [Curators](/resources/roles/curating/) to curate it and [Indexers](/indexing/overview/) to index it.
+When your subgraph is ready for a production environment, you can publish it to the decentralized network. Publishing is an onchain action that does the following:
+
+- It makes your subgraph available to be to indexed by the decentralized [Indexers](/indexing/overview/) on The Graph Network.
+- It removes rate limits and makes your subgraph publicly searchable and queryable in [Graph Explorer](https://thegraph.com/explorer/).
+- It makes your subgraph available for [Curators](/resources/roles/curating/) to curate it.
+
+> The greater the amount of GRT you and others curate on your subgraph, the more Indexers will be incentivized to index your subgraph, improving the quality of service, reducing latency, and enhancing network redundancy for your subgraph.
 
 #### Publishing with Subgraph Studio
 

From b10bfd758cfd30b6ce0d7d9eb558875c26badf6e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 07:46:26 -0500
Subject: [PATCH 2547/3820] New translations graph-node.mdx (Chinese
 Simplified)

---
 website/pages/zh/indexing/tooling/graph-node.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/indexing/tooling/graph-node.mdx b/website/pages/zh/indexing/tooling/graph-node.mdx
index bccd6e534310..3b6f7312d874 100644
--- a/website/pages/zh/indexing/tooling/graph-node.mdx
+++ b/website/pages/zh/indexing/tooling/graph-node.mdx
@@ -304,7 +304,7 @@ However, in some instances, if an Ethereum node has provided incorrect data for
 
 #### 查询问题和错误
 
-一旦子图被索引，索引人就可以期望通过子图的专用查询端点来服务查询。如果索引人希望为大量查询量提供服务，建议使用专用查询节点，如果查询量非常大，索引人可能需要配置副本分片，以便查询不会影响索引过程。
+一旦子图被索引，索引器就可以期望通过子图的专用查询端点来服务查询。如果索引器希望为大量查询量提供服务，建议使用专用查询节点，如果查询量非常大，索引器可能需要配置副本分片，以便查询不会影响索引过程。
 
 然而，即使使用专用的查询节点和副本，某些查询也可能需要很长时间才能执行，在某些情况下还会增加内存使用量，并对其他用户的查询时间产生负面影响。
 

From d0b414d07766dcd395416669b5a87a19ddae471e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 09:24:07 -0500
Subject: [PATCH 2548/3820] New translations graph-node.mdx (Chinese
 Simplified)

---
 website/pages/zh/indexing/tooling/graph-node.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/indexing/tooling/graph-node.mdx b/website/pages/zh/indexing/tooling/graph-node.mdx
index 3b6f7312d874..590e4ed9be88 100644
--- a/website/pages/zh/indexing/tooling/graph-node.mdx
+++ b/website/pages/zh/indexing/tooling/graph-node.mdx
@@ -340,6 +340,6 @@ For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates f
 
 #### 删除子图
 
-> 这是一项新功能，将在Graph Node 0.29.x中提供。
+> 这是一项新功能，将在Graph节点0.29.x中提供。
 
 At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From 589875dcb608435fdd19ccd76b28dba50bef18ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 09:24:08 -0500
Subject: [PATCH 2549/3820] New translations chain-integration-overview.mdx
 (Chinese Simplified)

---
 .../pages/zh/indexing/chain-integration-overview.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/zh/indexing/chain-integration-overview.mdx b/website/pages/zh/indexing/chain-integration-overview.mdx
index 3caa15d11f90..425fdaced82a 100644
--- a/website/pages/zh/indexing/chain-integration-overview.mdx
+++ b/website/pages/zh/indexing/chain-integration-overview.mdx
@@ -7,22 +7,22 @@ title: 链集成过程概述
 ## 阶段1：技术集成
 
 - Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
-- 团队通过在[here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71)（治理与GIPs下的新数据源子类别）创建一个论坛帖子来启动协议集成过程。强制使用默认的论坛模板。
+- 团队通过在[此处](https://forum.thegraph.com/c/governance-gips/new-chain-support/71)（治理与GIPs下的新数据源子类别）创建一个论坛帖子来启动协议集成过程。强制使用默认的论坛模板。
 
 ## 阶段2：集成验证
 
 - Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
-- Graph索引人在The Graph的测试网上测试集成。
+- Graph索引人在Graph的测试网上测试集成。
 - 核心开发者和索引人监控稳定性、性能和数据确定性。
 
 ## 阶段3：主网集成
 
-- 团队通过提交一个Graph Improvement Proposal (GIP) 并在 [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) 上发起一个拉取请求 (PR) 来提议主网集成（更多详细信息请查看链接）。
-- The Graph Council（The Graph理事会）审查请求，并在成功完成第2阶段并获得积极社区反馈的情况下批准主网支持。
+- 团队通过提交一个Graph改进建议(GIP) 并在 特征支持矩阵](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) 上发起一个拉取请求 (PR) 来提议主网集成（更多详细信息请查看链接）。
+- Graph Council（Graph理事会）审查请求，并在成功完成第2阶段并获得积极社区反馈的情况下批准主网支持。
 
 ---
 
-如果整个流程看起来令人望而生畏，不用担心！The Graph Foundation致力于通过促进合作、提供重要信息并指导各个阶段的过程来支持集成者，包括引导他们参与治理流程，如Graph Improvement Proposals (GIPs) 和拉取请求。如果您有任何问题，请通过 [info@thegraph.foundation](mailto:info@thegraph.foundation) 或通过Discord（可以联系Pedro、The Graph Foundation成员、IndexerDAO或其他核心开发者）与我们联系。
+如果整个流程看起来令人望而生畏，不用担心！Graph 基金会致力于通过促进合作、提供重要信息并指导各个阶段的过程来支持集成者，包括引导他们参与治理流程，如Graph改进建议(GIPs) 和拉取请求。如果您有任何问题，请通过 [info@thegraph.foundation](mailto:info@thegraph.foundation) 或通过Discord（可以联系Pedro、Graph基金会成员、索引人DAO或其他核心开发者）与我们联系。
 
 准备好塑造The Graph Network的未来了吗？[立即开始您的提案](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md)，成为Web3革命的一部分吧！
 
@@ -36,7 +36,7 @@ title: 链集成过程概述
 
 ### 2. 如果在主网上支持网络之后再支持 Firehose 和 Substreams，会发生什么情况？
 
-这只会影响 Substreams 驱动的子图上的索引奖励的协议支持。新的 Firehose 实现需要在测试网上进行测试，遵循了本 GIP 中第二阶段所概述的方法论。同样地，假设实现是高性能且可靠的，那么需要在 [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) 上提出 PR（`Substreams 数据源` 子图特性），以及一个新的 GIP 来支持索引奖励的协议。任何人都可以创建这个 PR 和 GIP；基金会将协助获得理事会的批准。
+这只会影响 Substreams 驱动的子图上的索引奖励的协议支持。新的 Firehose 实现需要在测试网上进行测试，遵循了本 GIP 中第二阶段所概述的方法论。同样地，假设实现是高性能且可靠的，那么需要在 [特征支持矩阵](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) 上提出 PR（`Substreams 数据源` 子图特性），以及一个新的 GIP 来支持索引奖励的协议。任何人都可以创建这个 PR 和 GIP；基金会将协助获得理事会的批准。
 
 ### 3. How much time will the process of reaching full protocol support take?
 

From ab659ab041ddc42ae4158dfa92bc4832085d064a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:57:53 -0500
Subject: [PATCH 2550/3820] New translations glossary.mdx (Portuguese)

---
 website/pages/pt/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/pt/resources/glossary.mdx b/website/pages/pt/resources/glossary.mdx
index 1f4454d73975..2d3c0fef2eb3 100644
--- a/website/pages/pt/resources/glossary.mdx
+++ b/website/pages/pt/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossário
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From e96bdc0f1a4dd4897d8267de5664f8cea48f76da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:57:54 -0500
Subject: [PATCH 2551/3820] New translations delegating.mdx (Portuguese)

---
 .../pages/pt/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/pt/resources/roles/delegating.mdx b/website/pages/pt/resources/roles/delegating.mdx
index 07f6f0017059..afad641c7428 100644
--- a/website/pages/pt/resources/roles/delegating.mdx
+++ b/website/pages/pt/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegação
 ---
 
-Delegantes são participantes de rede que delegam (ou seja, fazem "stake" de) GRT a um Indexador ou mais. Eles:
+# Delegating GRT on The Graph Network
 
-- Ajudam a manter a rede segura sem operar um Graph Node.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- Ganham uma porção das taxas de query e recompensas de um Indexador ao delegar para ele.
+## Benefits of Delegating
 
-## Como isto funciona?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-O número de queries que um Indexador pode processar depende do seu próprio stake, **o stake delegado**, e o preço cobrado pelo Indexador para cada query, portanto: quanto mais stakes forem delegados, mais queries um Indexador tem o potencial de processar.
+## How Does Delegation Work?
 
-## Guia do Delegante
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Aprenda como ser um Delegante eficiente na The Graph Network.
 
@@ -24,13 +51,13 @@ Há três secções neste guia:
 
 - Os riscos de delegar tokens na Graph Network
 - Como calcular retornos esperados como um Delegante
-- Um guia de vídeo que mostra como delegar na interface da Graph Network
+- A video guide explaining
 
 ## Riscos de Delegação
 
 Veja abaixo os riscos principais de ser um Delegante no protocolo.
 
-### A taxa de delegação
+### The Delegation Tax
 
 Os Delegantes não podem ser punidos por mau comportamento, mas há uma taxa sobre Delegantes, para desencorajar más decisões que possam ferir a integridade da rede.
 
@@ -40,9 +67,13 @@ Como Delegante, é importante entender que:
 
 - Por segurança, calcule o seu retorno potencial quando delegar para um Indexador. Por exemplo, pode-se calcular o número de dias até que tenha recuperado a taxa de 0,5% da sua delegação.
 
-### O período de separação da delegação
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Se um Delegado quiser cancelar a sua delegação, seus tokens estarão sujeitos a um período de 28 dias sem transferência, e também não poderá ganhar quaisquer recompensas por este período.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Qual a Importância Disto?
 
@@ -123,13 +154,6 @@ Assim, um Delegante deve sempre considerar a Capacidade de Delegação de um Ind
 
 Às vezes, tentativas de delegar a Indexadores via MetaMask podem falhar e deixar tentativas de transação "Pendentes" ou "Em Fila" por períodos prolongados.
 
-#### Exemplo
-
-Vamos supor que você tente delegar com uma taxa de gas insuficiente, relativa aos preços atuais.
-
-- Esta ação pode fazer com que a tentativa de transação fique "Pending" ("Pendente") na sua carteira do MetaMask por 15+ minutos. Quando isto acontecer, dá para tentar fazer mais transações, mas essas só serão processadas até a transação inicial ser minada, porque as transações para um endereço devem ser processadas em ordem.
-- Nesses casos, estas transações podem ser canceladas no MetaMask, mas as tentativas acumularão taxas de gas, sem garantia que quaisquer tentativas a seguir tenham algum sucesso.
-
 Uma solução mais simples para este bug é a reinicialização do navegador (por ex., "abort:restart" na barra de endereço), o que cancelará todas as tentativas anteriores sem subtrair gas da carteira. Vários utilizadores que encontraram este problema relataram sucesso nas transações após reiniciar o seu navegador e tentar delegar.
 
 ## Guia em Vídeo

From ef00231ec46456acea6cb446e74f4ec04b76dc84 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:57:55 -0500
Subject: [PATCH 2552/3820] New translations from-an-application.mdx
 (Portuguese)

---
 .../pt/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/pt/subgraphs/querying/from-an-application.mdx b/website/pages/pt/subgraphs/querying/from-an-application.mdx
index 87a57e48b69c..076a023e86c4 100644
--- a/website/pages/pt/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/pt/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 5f79eb71672149f5b22d183bc1e1017a80ffabb3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:57:55 -0500
Subject: [PATCH 2553/3820] New translations from-an-application.mdx (Romanian)

---
 .../ro/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/ro/subgraphs/querying/from-an-application.mdx b/website/pages/ro/subgraphs/querying/from-an-application.mdx
index 4bf68fcf198b..708dcfde2fdc 100644
--- a/website/pages/ro/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ro/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 462887115d922848f74553890af0260c2d7920d9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:57:57 -0500
Subject: [PATCH 2554/3820] New translations from-an-application.mdx (French)

---
 .../fr/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/subgraphs/querying/from-an-application.mdx b/website/pages/fr/subgraphs/querying/from-an-application.mdx
index 6243743e25fc..d86768f27d33 100644
--- a/website/pages/fr/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/fr/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 07009420d634791a2bc4b765fc91de124354c75d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:57:58 -0500
Subject: [PATCH 2555/3820] New translations from-an-application.mdx (Spanish)

---
 .../es/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/es/subgraphs/querying/from-an-application.mdx b/website/pages/es/subgraphs/querying/from-an-application.mdx
index 644f53314dda..b36ffabaa3e6 100644
--- a/website/pages/es/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/es/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From c137ba1cb5b9fd4dafadee331a11dc24567059df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:57:59 -0500
Subject: [PATCH 2556/3820] New translations from-an-application.mdx (Arabic)

---
 .../ar/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/ar/subgraphs/querying/from-an-application.mdx b/website/pages/ar/subgraphs/querying/from-an-application.mdx
index 87e40d03caa4..767a2caa9021 100644
--- a/website/pages/ar/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ar/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 6b89c04588904d08dcdff9324ed57828868be740 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:00 -0500
Subject: [PATCH 2557/3820] New translations from-an-application.mdx (Czech)

---
 .../cs/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/cs/subgraphs/querying/from-an-application.mdx b/website/pages/cs/subgraphs/querying/from-an-application.mdx
index 94bdc46311d4..b5e719983167 100644
--- a/website/pages/cs/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/cs/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 27dc4ba437035f75d140bed93a59bb89a3a35edd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:01 -0500
Subject: [PATCH 2558/3820] New translations from-an-application.mdx (German)

---
 .../de/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/de/subgraphs/querying/from-an-application.mdx b/website/pages/de/subgraphs/querying/from-an-application.mdx
index 4cad958805b7..af85c4086630 100644
--- a/website/pages/de/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/de/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 6a3ef071eb9fbd9155aa0da3f8f013a9f8237744 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:02 -0500
Subject: [PATCH 2559/3820] New translations from-an-application.mdx (Italian)

---
 .../it/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/it/subgraphs/querying/from-an-application.mdx b/website/pages/it/subgraphs/querying/from-an-application.mdx
index a0410d03c249..d2ac36f09846 100644
--- a/website/pages/it/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/it/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 6595e15b11171ebaee3b49b704b458c5ff0d5926 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:03 -0500
Subject: [PATCH 2560/3820] New translations from-an-application.mdx (Japanese)

---
 .../ja/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/ja/subgraphs/querying/from-an-application.mdx b/website/pages/ja/subgraphs/querying/from-an-application.mdx
index 78d6995c85cd..226a9cd2d686 100644
--- a/website/pages/ja/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ja/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 6840bbedf6b3bc46dad781c6156bee0fc2596ab7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:04 -0500
Subject: [PATCH 2561/3820] New translations from-an-application.mdx (Korean)

---
 .../ko/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/ko/subgraphs/querying/from-an-application.mdx b/website/pages/ko/subgraphs/querying/from-an-application.mdx
index 6a3a13b8d141..681f6e6ba8d5 100644
--- a/website/pages/ko/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ko/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 6f0aee031313cd6618413969b23f034cd454e1ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:05 -0500
Subject: [PATCH 2562/3820] New translations from-an-application.mdx (Dutch)

---
 .../nl/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/nl/subgraphs/querying/from-an-application.mdx b/website/pages/nl/subgraphs/querying/from-an-application.mdx
index 7c5c99bc68ba..27ee9b282f9a 100644
--- a/website/pages/nl/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/nl/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From d898dce2a711f04900e77f6d0b17257be5dd8d79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:06 -0500
Subject: [PATCH 2563/3820] New translations from-an-application.mdx (Polish)

---
 .../pl/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/pl/subgraphs/querying/from-an-application.mdx b/website/pages/pl/subgraphs/querying/from-an-application.mdx
index ea4138051254..56be718d0fb8 100644
--- a/website/pages/pl/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/pl/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From acc8dc08ed32a1eb2495826ca1e33ee240be65d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:07 -0500
Subject: [PATCH 2564/3820] New translations from-an-application.mdx (Russian)

---
 .../ru/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/ru/subgraphs/querying/from-an-application.mdx b/website/pages/ru/subgraphs/querying/from-an-application.mdx
index e48aa0c6ffbf..75853752f129 100644
--- a/website/pages/ru/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ru/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 244e0861835dd87cae10cc0eefe90e897df16c6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:08 -0500
Subject: [PATCH 2565/3820] New translations from-an-application.mdx (Swedish)

---
 .../sv/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/sv/subgraphs/querying/from-an-application.mdx b/website/pages/sv/subgraphs/querying/from-an-application.mdx
index 56f70142ed52..ee0bb7a2fabe 100644
--- a/website/pages/sv/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/sv/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 7c706b724168370cb1cb69c5d91032ecaa124868 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:09 -0500
Subject: [PATCH 2566/3820] New translations from-an-application.mdx (Turkish)

---
 .../tr/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/tr/subgraphs/querying/from-an-application.mdx b/website/pages/tr/subgraphs/querying/from-an-application.mdx
index 6d175918c0de..6f45ffd8a451 100644
--- a/website/pages/tr/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/tr/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 4f28e43f85e5d7a6e129eeff84e3d650e0a82905 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:10 -0500
Subject: [PATCH 2567/3820] New translations from-an-application.mdx
 (Ukrainian)

---
 .../uk/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/uk/subgraphs/querying/from-an-application.mdx b/website/pages/uk/subgraphs/querying/from-an-application.mdx
index 9268a2b9f5af..a83bf2860737 100644
--- a/website/pages/uk/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/uk/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 04f758fb1bc235eccef11aef8ea8c63d318c7a73 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:11 -0500
Subject: [PATCH 2568/3820] New translations from-an-application.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/zh/subgraphs/querying/from-an-application.mdx b/website/pages/zh/subgraphs/querying/from-an-application.mdx
index 600e2ac1bc3f..f9b6bf63e45f 100644
--- a/website/pages/zh/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/zh/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 2310146e7e9425147c59f3d37ae9fbd9cd89d2ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:12 -0500
Subject: [PATCH 2569/3820] New translations from-an-application.mdx (Urdu
 (Pakistan))

---
 .../ur/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/ur/subgraphs/querying/from-an-application.mdx b/website/pages/ur/subgraphs/querying/from-an-application.mdx
index 784aded3f229..9e2b78e6e628 100644
--- a/website/pages/ur/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/ur/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 297019797fd55bce51ef49d8ac1b6ad6b64ff8e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:13 -0500
Subject: [PATCH 2570/3820] New translations from-an-application.mdx
 (Vietnamese)

---
 .../vi/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/vi/subgraphs/querying/from-an-application.mdx b/website/pages/vi/subgraphs/querying/from-an-application.mdx
index 644393dc5b57..af623acbabbe 100644
--- a/website/pages/vi/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/vi/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 7efd38afa53a5e5faf344b0323841f8069d0fe93 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:14 -0500
Subject: [PATCH 2571/3820] New translations from-an-application.mdx (Marathi)

---
 .../mr/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/mr/subgraphs/querying/from-an-application.mdx b/website/pages/mr/subgraphs/querying/from-an-application.mdx
index 3a8fa9c0c411..f867964cb39b 100644
--- a/website/pages/mr/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/mr/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 5deb44d232fcbee4daa362cd1597ca6ec90a9cbe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:15 -0500
Subject: [PATCH 2572/3820] New translations from-an-application.mdx (Hindi)

---
 .../hi/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/hi/subgraphs/querying/from-an-application.mdx b/website/pages/hi/subgraphs/querying/from-an-application.mdx
index e219768992ea..77b510466231 100644
--- a/website/pages/hi/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/hi/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From b185f71d4a24c93488add7144cc511f3fd5f5877 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:16 -0500
Subject: [PATCH 2573/3820] New translations from-an-application.mdx (Swahili)

---
 .../sw/subgraphs/querying/from-an-application.mdx    | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/website/pages/sw/subgraphs/querying/from-an-application.mdx b/website/pages/sw/subgraphs/querying/from-an-application.mdx
index 6a3a13b8d141..681f6e6ba8d5 100644
--- a/website/pages/sw/subgraphs/querying/from-an-application.mdx
+++ b/website/pages/sw/subgraphs/querying/from-an-application.mdx
@@ -6,21 +6,27 @@ Learn how to query The Graph from your application.
 
 ## Getting GraphQL Endpoints
 
-Once a subgraph is deployed to [Subgraph Studio](https://thegraph.com/studio/) or [Graph Explorer](https://thegraph.com/explorer), you will receive two GraphQL API endpoints that look like this:
+During the development process, you will receive a GraphQL API endpoint at two different stages: one for testing in Subgraph Studio, and another for making queries to The Graph Network in production.
 
 ### Subgraph Studio Endpoint
 
+After deploying your subgraph to [Subgraph Studio](https://thegraph.com/docs/en/subgraphs/developing/deploying/using-subgraph-studio/), you will receive an endpoint that looks like this:
+
 ```
 https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>
 ```
 
-### Network Endpoint
+> This endpoint is intended for testing purposes **only** and is rate-limited.
+
+### The Graph Network Endpoint
+
+After publishing your subgraph to the network, you will receive an endpoint that looks like this: :
 
 ```
 https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>
 ```
 
-With your GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with data indexed by the subgraph.
+> This endpoint is intended for active use on the network. It allows you to use various GraphQL client libraries to query the subgraph and populate your application with indexed data.
 
 ## Using Popular GraphQL Clients
 

From 5c043a74bda3a2840aa75d49f407be5ab2f06bd5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:17 -0500
Subject: [PATCH 2574/3820] New translations glossary.mdx (Romanian)

---
 website/pages/ro/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ro/resources/glossary.mdx b/website/pages/ro/resources/glossary.mdx
index fa813b659730..4dd1c7877e14 100644
--- a/website/pages/ro/resources/glossary.mdx
+++ b/website/pages/ro/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From fbe510a3a20c8cae722c3bcabf8e6faeccd29793 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:18 -0500
Subject: [PATCH 2575/3820] New translations delegating.mdx (Romanian)

---
 .../pages/ro/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/ro/resources/roles/delegating.mdx b/website/pages/ro/resources/roles/delegating.mdx
index eda60369e00a..de8c328e613d 100644
--- a/website/pages/ro/resources/roles/delegating.mdx
+++ b/website/pages/ro/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Delegator Guide
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
+- A video guide explaining
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 4aebf145f8daaa8a98ef86b5bf8cb3d8508d8013 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:19 -0500
Subject: [PATCH 2576/3820] New translations glossary.mdx (French)

---
 website/pages/fr/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/fr/resources/glossary.mdx b/website/pages/fr/resources/glossary.mdx
index 359c0cb2aee2..4e656d6f95bf 100644
--- a/website/pages/fr/resources/glossary.mdx
+++ b/website/pages/fr/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossaire
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From bb4a611ef7f7719d174e3283036e48480d79aede Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:20 -0500
Subject: [PATCH 2577/3820] New translations delegating.mdx (French)

---
 .../pages/fr/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/fr/resources/roles/delegating.mdx b/website/pages/fr/resources/roles/delegating.mdx
index 59296a754d98..ae9fbc3a95d1 100644
--- a/website/pages/fr/resources/roles/delegating.mdx
+++ b/website/pages/fr/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Délégation
 ---
 
-Les Délégateurs sont des participants au réseau qui délèguent (c'est-à-dire "stakent") des GRT à un ou plusieurs Indexeurs.
+# Delegating GRT on The Graph Network
 
-- Ils aident à sécuriser le réseau sans exécuter eux-mêmes un Graph Node.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- Ils gagnent une partie des frais de requête et des récompenses d'un Indexeur en lui déléguant des GRT.
+## Benefits of Delegating
 
-## Comment ça marche?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Guide du délégué
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Apprenez comment être un délégateur efficace dans The Graph Network.
 
@@ -24,13 +51,13 @@ Ce guide comporte trois sections:
 
 - Les risques de la délégation de jetons dans The Graph Network
 - Comment calculer les rendements escomptés en tant que délégué
-- Un guide vidéo montrant les étapes pour déléguer dans l'interface utilisateur du réseau graph
+- A video guide explaining
 
 ## Risques de délégation
 
 Les principaux risques liés à la fonction de délégué dans le protocole sont transmis ci-dessous.
 
-### La taxe de délégation
+### The Delegation Tax
 
 Les délégués ne peuvent pas être licenciés en cas de mauvais comportement, mais ils sont soumis à une taxe visant à décourager les mauvaises décisions susceptibles de nuire à l'intégrité du réseau.
 
@@ -40,9 +67,13 @@ En tant que Délégateur, il est important de comprendre ce qui suit :
 
 - Pour être en sécurité, vous devriez calculer votre retour potentiel lorsque vous déléguez à un Indexeur. Par exemple, vous pourriez calculer combien de jours il faudra avant d'avoir récupéré la taxe de 0,5% sur votre délégation.
 
-### La période de découplage de la délégation
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Chaque fois qu'un Délégateur veut se désengager, ses jetons sont soumis à une période de d'attente de 28 jours. Cela signifie qu'ils ne peuvent pas transférer leurs jetons ou gagner des récompenses pendant 28 jours.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Pourquoi ceci est t-il important?
 
@@ -126,13 +157,6 @@ Par conséquent, un Déléguateur doit toujours considérer la Capacité de Dél
 
 Parfois, les tentatives de déléguer aux Indexeurs via MetaMask peuvent échouer et entraîner des périodes prolongées de tentatives de transaction "Pending" ou "Queued".
 
-#### Exemple
-
-Imaginons que vous tentiez de déléguer avec des frais de gaz insuffisants par rapport aux prix actuels.
-
-- Cette action peut entraîner l'affichage de la tentative de transaction comme "En attente" dans votre portefeuille MetaMask pendant plus de 15 minutes. Dans ce cas, vous pouvez essayer des transactions ultérieures, mais elles ne seront traitées que lorsque la transaction initiale sera minée, car les transactions pour une adresse doivent être traitées dans l'ordre.
-- Dans de tels cas, ces transactions peuvent être annulées dans MetaMask, mais les tentatives de transactions accumuleront des frais de gas sans aucune garantie que les tentatives ultérieures seront réussies.
-
 Une solution simple à ce problème consiste à redémarrer le navigateur (par exemple, en utilisant "abort:restart" dans la barre d'adresse), ce qui annulera toutes les tentatives précédentes sans que le gaz ne soit soustrait du portefeuille. Plusieurs utilisateurs ayant rencontré ce problème ont signalé des transactions réussies après avoir redémarré leur navigateur et tenté de déléguer.
 
 ## Guide Vidéo

From e7ae130adeccea8c60f11e5a71f6085d087f1dc2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:22 -0500
Subject: [PATCH 2578/3820] New translations glossary.mdx (Spanish)

---
 website/pages/es/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/es/resources/glossary.mdx b/website/pages/es/resources/glossary.mdx
index fdca3b093220..0e4995589624 100644
--- a/website/pages/es/resources/glossary.mdx
+++ b/website/pages/es/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glosario
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From a4d9be5db324e65afe701703bfb4ff2b3ff8cff6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:23 -0500
Subject: [PATCH 2579/3820] New translations delegating.mdx (Spanish)

---
 .../pages/es/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/es/resources/roles/delegating.mdx b/website/pages/es/resources/roles/delegating.mdx
index 4eff3906805e..c5363ac41e1c 100644
--- a/website/pages/es/resources/roles/delegating.mdx
+++ b/website/pages/es/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegar
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Guía del Delegador
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - Los riesgos de delegar tokens en la red de The Graph
 - Cómo calcular los rendimientos que te esperan siendo Delegador
-- Una guía en video que muestra los pasos para delegar en la interfaz de usuario de Graph Network
+- A video guide explaining
 
 ## Riesgos de la Delegación
 
 A continuación se enumeran los principales riesgos de ser un Delegador en el protocolo.
 
-### La tarifa de delegación
+### The Delegation Tax
 
 Los Delegadores no pueden ser recortados por mal comportamiento, pero existe un impuesto sobre los Delegadores para desincentivar la toma de malas decisiones que puedan perjudicar la integridad de la red.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### El período de unbonding (desvinculación) de la delegación
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Ejemplo
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 0b368a159f533cc1acabe1955e92d0085ef690d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:24 -0500
Subject: [PATCH 2580/3820] New translations glossary.mdx (Arabic)

---
 website/pages/ar/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ar/resources/glossary.mdx b/website/pages/ar/resources/glossary.mdx
index dde52c37403a..06c7d215f934 100644
--- a/website/pages/ar/resources/glossary.mdx
+++ b/website/pages/ar/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: قائمة المصطلحات
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From a9349315635bd2a14302c35cbac680af67e19b74 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:25 -0500
Subject: [PATCH 2581/3820] New translations delegating.mdx (Arabic)

---
 .../pages/ar/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/ar/resources/roles/delegating.mdx b/website/pages/ar/resources/roles/delegating.mdx
index 8ef41bbd6bdf..e45467d230b2 100644
--- a/website/pages/ar/resources/roles/delegating.mdx
+++ b/website/pages/ar/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## دليل المفوض
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - مخاطر تفويض التوكن في شبكة The Graph
 - كيفية حساب العوائد المتوقعة كمفوض
-- A video guide showing the steps to delegate in the Graph Network UI
+- A video guide explaining
 
 ## Delegation Risks
 
 القائمة أدناه هي المخاطر الرئيسية لكونك مفوضا في البروتوكول.
 
-### رسوم التفويض
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### فترة إلغاء التفويض
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 3821a060cc7a28ebb224ef9f21d9297e1436dd59 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:26 -0500
Subject: [PATCH 2582/3820] New translations glossary.mdx (Czech)

---
 website/pages/cs/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/cs/resources/glossary.mdx b/website/pages/cs/resources/glossary.mdx
index ead2fbb3e17b..c6bbd9ea94fc 100644
--- a/website/pages/cs/resources/glossary.mdx
+++ b/website/pages/cs/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glosář
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 81ffca92c3d6b1250a033ee5dd89fa218a385284 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:27 -0500
Subject: [PATCH 2583/3820] New translations delegating.mdx (Czech)

---
 .../pages/cs/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/cs/resources/roles/delegating.mdx b/website/pages/cs/resources/roles/delegating.mdx
index 7684f08f5fe2..b7b2e15aa53d 100644
--- a/website/pages/cs/resources/roles/delegating.mdx
+++ b/website/pages/cs/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegování
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Průvodce delegáta
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - Rizika delegování tokenů v síti Graf
 - Jak vypočítat očekávané výnosy jako delegát
-- Videoprůvodce ukazující kroky delegování v UI sit' Graf
+- A video guide explaining
 
 ## Rizika delegování
 
 Níže jsou uvedena hlavní rizika plynoucí z delegáta v protokolu.
 
-### Delegační daň
+### The Delegation Tax
 
 Delegáti nemohou být za špatné chování kráceni, ale existuje daň pro delegáty, která má odradit od špatného rozhodování, jež by mohlo poškodit integritu sítě.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### Konec období vázanosti delegací
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Příklad
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 88d71385c28a85a9366770b62c102da2752594cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:28 -0500
Subject: [PATCH 2584/3820] New translations glossary.mdx (German)

---
 website/pages/de/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/de/resources/glossary.mdx b/website/pages/de/resources/glossary.mdx
index fa813b659730..4dd1c7877e14 100644
--- a/website/pages/de/resources/glossary.mdx
+++ b/website/pages/de/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 3c26bb57fa0adaec081edc97fe965d8fa4d686a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:29 -0500
Subject: [PATCH 2585/3820] New translations delegating.mdx (German)

---
 .../pages/de/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/de/resources/roles/delegating.mdx b/website/pages/de/resources/roles/delegating.mdx
index 5fa99f101641..de8c328e613d 100644
--- a/website/pages/de/resources/roles/delegating.mdx
+++ b/website/pages/de/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Delegator Guide
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
+- A video guide explaining
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Beispiel
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 78693d9c4b9c13285052c9666b7e59a5d6c58f2c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:30 -0500
Subject: [PATCH 2586/3820] New translations glossary.mdx (Italian)

---
 website/pages/it/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/it/resources/glossary.mdx b/website/pages/it/resources/glossary.mdx
index fa813b659730..4dd1c7877e14 100644
--- a/website/pages/it/resources/glossary.mdx
+++ b/website/pages/it/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 98e54a7ae198e1d1fa9661ab5e90d019a500dd03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:31 -0500
Subject: [PATCH 2587/3820] New translations delegating.mdx (Italian)

---
 .../pages/it/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/it/resources/roles/delegating.mdx b/website/pages/it/resources/roles/delegating.mdx
index cb65d530d4e1..6a3f67c87e48 100644
--- a/website/pages/it/resources/roles/delegating.mdx
+++ b/website/pages/it/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegazione
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Guida per i delegator
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - I rischi della delegazione dei token in The Graph Network
 - Come calcolare i rendimenti previsti come Delegator
-- Una guida video che mostra i passi per delegare nel UI di The Graph Network
+- A video guide explaining
 
 ## Rischi di delegazione
 
 Di seguito sono elencati i principali rischi essere il Delegator nel protocollo.
 
-### La tassa di delegazione
+### The Delegation Tax
 
 I delegator non possono essere penalizzati per un comportamento scorretto, ma c'è una tassa sui delegator per disincentivare un processo decisionale insufficiente che potrebbero danneggiare l'integrità della rete.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### Il periodo di sblocco di delegazione
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Esempio
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 1a83b90d35a5433a98fc2fd3569dea9d147f2d55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:32 -0500
Subject: [PATCH 2588/3820] New translations glossary.mdx (Japanese)

---
 website/pages/ja/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ja/resources/glossary.mdx b/website/pages/ja/resources/glossary.mdx
index baab87472fce..d8b838fcd2a7 100644
--- a/website/pages/ja/resources/glossary.mdx
+++ b/website/pages/ja/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: 用語集
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 7d41d982f50d332d082b9d35106bc57d5bb811fd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:33 -0500
Subject: [PATCH 2589/3820] New translations delegating.mdx (Japanese)

---
 .../pages/ja/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/ja/resources/roles/delegating.mdx b/website/pages/ja/resources/roles/delegating.mdx
index 069ec6803b59..2b781de3e817 100644
--- a/website/pages/ja/resources/roles/delegating.mdx
+++ b/website/pages/ja/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: 委任
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## デリゲーターガイド
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - グラフネットワークでトークンをデリゲートすることのリスク
 - デリゲーターとしての期待リターンの計算方法
-- グラフネットワークの UI でデリゲートする手順のビデオガイド
+- A video guide explaining
 
 ## デリゲーションリスク
 
 以下にリストされているのは、プロトコルで委任者になることの主なリスクです。
 
-### デリゲーション手数料
+### The Delegation Tax
 
 デリゲーターは悪意の行動をしてもスラッシュされないが、デリゲーターにはデポジット税が課せられ、ネットワークの整合性を損なう可能性のある悪い意思決定を抑止します。
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### 委任期間無制限
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### 例
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 76782bbf498cd4ca873f8aea8346c9702c156140 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:34 -0500
Subject: [PATCH 2590/3820] New translations glossary.mdx (Korean)

---
 website/pages/ko/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ko/resources/glossary.mdx b/website/pages/ko/resources/glossary.mdx
index fa813b659730..4dd1c7877e14 100644
--- a/website/pages/ko/resources/glossary.mdx
+++ b/website/pages/ko/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 4315873db20606e91df4fe8f39b37cd185bbe900 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:35 -0500
Subject: [PATCH 2591/3820] New translations delegating.mdx (Korean)

---
 .../pages/ko/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/ko/resources/roles/delegating.mdx b/website/pages/ko/resources/roles/delegating.mdx
index eda60369e00a..de8c328e613d 100644
--- a/website/pages/ko/resources/roles/delegating.mdx
+++ b/website/pages/ko/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Delegator Guide
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
+- A video guide explaining
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 1719ebf5d8061a4498964378b17ebab4da0df52b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:36 -0500
Subject: [PATCH 2592/3820] New translations glossary.mdx (Dutch)

---
 website/pages/nl/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/nl/resources/glossary.mdx b/website/pages/nl/resources/glossary.mdx
index fa813b659730..4dd1c7877e14 100644
--- a/website/pages/nl/resources/glossary.mdx
+++ b/website/pages/nl/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 842595dc654611659a4ce1ab5861ebebe1f21f37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:37 -0500
Subject: [PATCH 2593/3820] New translations delegating.mdx (Dutch)

---
 .../pages/nl/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/nl/resources/roles/delegating.mdx b/website/pages/nl/resources/roles/delegating.mdx
index 83cc07b364cd..7ae98f882684 100644
--- a/website/pages/nl/resources/roles/delegating.mdx
+++ b/website/pages/nl/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegeren
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Delegeerder Gids
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - De risico's van het delegeren van tokens in het Graph Netwerk
 - Hoe je verwachte opbrengsten als Delegeerder berekent
-- Een videogids die de stappen laat zien om te delegeren in het Graph Netwerk
+- A video guide explaining
 
 ## Delegatie Risico's
 
 Hieronder staan de belangrijkste risico's van het zijn van een Delegeerder in het protocol.
 
-### Delegatiebelasting
+### The Delegation Tax
 
 Delegeerders kunnen niet worden gestraft voor slecht gedrag, maar er is een belasting voor Delegeerders om slechte besluitvorming die de integriteit van het netwerk kan schaden te ontmoedigen.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### Delegatieontbindingsperiode
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 6d071042910cee16a7e3c1588546d0de314d1a3b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:38 -0500
Subject: [PATCH 2594/3820] New translations glossary.mdx (Polish)

---
 website/pages/pl/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/pl/resources/glossary.mdx b/website/pages/pl/resources/glossary.mdx
index fa813b659730..4dd1c7877e14 100644
--- a/website/pages/pl/resources/glossary.mdx
+++ b/website/pages/pl/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From e61dbb93db10e67fc66c88d7d605987264d37a3e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:39 -0500
Subject: [PATCH 2595/3820] New translations delegating.mdx (Polish)

---
 .../pages/pl/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/pl/resources/roles/delegating.mdx b/website/pages/pl/resources/roles/delegating.mdx
index eda60369e00a..de8c328e613d 100644
--- a/website/pages/pl/resources/roles/delegating.mdx
+++ b/website/pages/pl/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Delegator Guide
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
+- A video guide explaining
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 09b07ebb21e40f289609016c874cd170708ccfe7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:40 -0500
Subject: [PATCH 2596/3820] New translations glossary.mdx (Russian)

---
 website/pages/ru/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ru/resources/glossary.mdx b/website/pages/ru/resources/glossary.mdx
index fa813b659730..4dd1c7877e14 100644
--- a/website/pages/ru/resources/glossary.mdx
+++ b/website/pages/ru/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 55ca8c3f688fcdc66c3c825e41060282409673fd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:42 -0500
Subject: [PATCH 2597/3820] New translations delegating.mdx (Russian)

---
 .../pages/ru/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/ru/resources/roles/delegating.mdx b/website/pages/ru/resources/roles/delegating.mdx
index cd5356074a7f..a7dfd0051e00 100644
--- a/website/pages/ru/resources/roles/delegating.mdx
+++ b/website/pages/ru/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Делегирование
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Инструкция Делегатора
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - Риски связанные с делегацией в сети The Graph
 - Как расчитать примерный доход
-- Видео ролик показывающий как делегировать через веб интерфейс The Graph сети
+- A video guide explaining
 
 ## Риски делегации
 
 Ниже указаны основные риски Делегатора.
 
-### Комиссия на делегацию
+### The Delegation Tax
 
 Делегаторы не могут быть наказаны за некорректное поведение, но они уплачивают комиссию на делегацию, который должен стимулировать обдуманный выбор Индексатора для делегации.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### Период unbonding (разблокировки) делегирования
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Пример
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From e2061daf878ef31a58849be3e6b349300f0a2626 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:43 -0500
Subject: [PATCH 2598/3820] New translations glossary.mdx (Swedish)

---
 website/pages/sv/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/sv/resources/glossary.mdx b/website/pages/sv/resources/glossary.mdx
index b6cf29493dc3..7facf5d2ec88 100644
--- a/website/pages/sv/resources/glossary.mdx
+++ b/website/pages/sv/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Ordlista
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 234e28b5f69d59be9ac8e61dc3b1bf2ba01bbcda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:44 -0500
Subject: [PATCH 2599/3820] New translations delegating.mdx (Swedish)

---
 .../pages/sv/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/sv/resources/roles/delegating.mdx b/website/pages/sv/resources/roles/delegating.mdx
index 9d79c46931b0..a7fa595662cd 100644
--- a/website/pages/sv/resources/roles/delegating.mdx
+++ b/website/pages/sv/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegera
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Delegateringsguide
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - Riskerna med att delegera tokens i The Graph-nätverket
 - Hur man beräknar förväntad avkastning som Delegater
-- En videohandledning som visar stegen för att delegera i Graf Nätverk UI
+- A video guide explaining
 
 ## Delegationsrisker
 
 Här nedan listas huvudriskerna med att vara en Delegater i protokollet.
 
-### Delegationsavgiften
+### The Delegation Tax
 
 Delegater kan inte "slashas" för dåligt beteende, men det finns en avgift för Delegater för att avskräcka dåligt beslutsfattande som kan skada nätverkets integritet.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### Perioden för upphävande av delegering
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Exempel
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From dd0a214722234c531cf15778ce0be9b7e87a606a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:45 -0500
Subject: [PATCH 2600/3820] New translations glossary.mdx (Turkish)

---
 website/pages/tr/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/tr/resources/glossary.mdx b/website/pages/tr/resources/glossary.mdx
index fa813b659730..4dd1c7877e14 100644
--- a/website/pages/tr/resources/glossary.mdx
+++ b/website/pages/tr/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From e0fae27bd346b5402bf748a8dc76b19deff8d870 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:46 -0500
Subject: [PATCH 2601/3820] New translations delegating.mdx (Turkish)

---
 .../pages/tr/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/tr/resources/roles/delegating.mdx b/website/pages/tr/resources/roles/delegating.mdx
index a7be05b9f698..de8c328e613d 100644
--- a/website/pages/tr/resources/roles/delegating.mdx
+++ b/website/pages/tr/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Delegator Guide
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
+- A video guide explaining
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Örnek
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From bd7996813392067de10cd13402b2fd2656da4969 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:47 -0500
Subject: [PATCH 2602/3820] New translations glossary.mdx (Ukrainian)

---
 website/pages/uk/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/uk/resources/glossary.mdx b/website/pages/uk/resources/glossary.mdx
index 96e2835ae2aa..f67d04041687 100644
--- a/website/pages/uk/resources/glossary.mdx
+++ b/website/pages/uk/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Глосарій
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From ba0f84d7933c75dd341ff3164ff16d2fde0ff6ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:48 -0500
Subject: [PATCH 2603/3820] New translations delegating.mdx (Ukrainian)

---
 .../pages/uk/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/uk/resources/roles/delegating.mdx b/website/pages/uk/resources/roles/delegating.mdx
index cf629b9b7048..9d79eef569ce 100644
--- a/website/pages/uk/resources/roles/delegating.mdx
+++ b/website/pages/uk/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Делегування
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Гайд для делегатів
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - Ризики делегування токенів в мережі Graph
 - Як розрахувати можливі прибутки як делегат
-- Відеоінструкція, що демонструє кроки з делегування в інтерфейсі мережі Graph
+- A video guide explaining
 
 ## Ризики, пов'язані з делегуванням
 
 Нижче перераховані основні ризики, пов'язані з участю делегата в протоколі.
 
-### Штраф на делегування
+### The Delegation Tax
 
 Делегати не можуть бути виключені за погану поведінку, але існує певний штраф для них, щоб позбавити стимулу щодо прийняття поганих рішень, які можуть зашкодити цілісності мережі.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### Період розблокування делегації
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 4ef8d142456e895d605efb66d6ff46e20a54f5cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:49 -0500
Subject: [PATCH 2604/3820] New translations glossary.mdx (Chinese Simplified)

---
 website/pages/zh/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/zh/resources/glossary.mdx b/website/pages/zh/resources/glossary.mdx
index 987d665b3c69..38aac3e6a541 100644
--- a/website/pages/zh/resources/glossary.mdx
+++ b/website/pages/zh/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: 术语汇编
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From e0a73112e8c233df21af95060daa517aa10fcda0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:50 -0500
Subject: [PATCH 2605/3820] New translations delegating.mdx (Chinese
 Simplified)

---
 .../pages/zh/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/zh/resources/roles/delegating.mdx b/website/pages/zh/resources/roles/delegating.mdx
index 8f1538cffbcc..45906503eb43 100644
--- a/website/pages/zh/resources/roles/delegating.mdx
+++ b/website/pages/zh/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: 委托
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## 委托人指南
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - 在 Graph 网络中委托代币的风险
 - 如何计算作为委托人的预期回报
-- 展示在Graph 网络界面中进行委托步骤的视频指南
+- A video guide explaining
 
 ## 委托风险
 
 下面列出了作为协议中的委托人的主要风险。
 
-### 委托费用
+### The Delegation Tax
 
 委托人不能因为不良行为而被取消，但对委托有税，以抑制可能损害网络完整性的不良决策。
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### 委托解约期
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### 示例
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 07bc6cd6afe3bfd4834d4ed25596fc891605cc3d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:51 -0500
Subject: [PATCH 2606/3820] New translations glossary.mdx (Urdu (Pakistan))

---
 website/pages/ur/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ur/resources/glossary.mdx b/website/pages/ur/resources/glossary.mdx
index 79b2da2f0e65..e9feda2df120 100644
--- a/website/pages/ur/resources/glossary.mdx
+++ b/website/pages/ur/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: لغت
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 3dd80c16fc738b7cd98f94e5903c8142ee10f993 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:52 -0500
Subject: [PATCH 2607/3820] New translations delegating.mdx (Urdu (Pakistan))

---
 .../pages/ur/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/ur/resources/roles/delegating.mdx b/website/pages/ur/resources/roles/delegating.mdx
index a1f89b513d63..031bd470d330 100644
--- a/website/pages/ur/resources/roles/delegating.mdx
+++ b/website/pages/ur/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: ڈیلیگیٹنگ
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## ڈیلیگیٹر گائیڈ
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - گراف نیٹ ورک میں ٹوکن ڈیلیگ کرنے کے خطرات
 - بطور ڈیلیگیٹر متوقع واپسی کا حساب کیسے لگائیں
-- ایک ویڈیو گائیڈ جو گراف نیٹ ورک UI میں نمائندگی کرنے کے اقدامات دکھا رہا ہے
+- A video guide explaining
 
 ## ڈیلیگیشن کے خطرات
 
 پروٹوکول میں ڈیلیگیٹر ہونےکے اہم خطرات مندرجہ ذیل ہیں.
 
-### ڈیلیگیشن ٹیکس
+### The Delegation Tax
 
 برے رویۓ پر ڈیلیگیٹرز کو نہیں چھوڑا جا سکتا، لیکن ناقص فیصلہ سازی کی حوصلہ شکنی کے لیے ڈیلیگیٹرز پر ٹیکس ہے جو نیٹ ورک کی سالمیت کو نقصان پہنچا سکتا ہے.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### وفد کی بندش کی مدت
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### مثال
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 7e64f7649912c7ad2747225a43c933e307e661e1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:53 -0500
Subject: [PATCH 2608/3820] New translations glossary.mdx (Vietnamese)

---
 website/pages/vi/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/vi/resources/glossary.mdx b/website/pages/vi/resources/glossary.mdx
index fa813b659730..4dd1c7877e14 100644
--- a/website/pages/vi/resources/glossary.mdx
+++ b/website/pages/vi/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 4b13ff4f806dc4e1a6a930b6b5599aeb1ef3311a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:54 -0500
Subject: [PATCH 2609/3820] New translations delegating.mdx (Vietnamese)

---
 .../pages/vi/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/vi/resources/roles/delegating.mdx b/website/pages/vi/resources/roles/delegating.mdx
index 02bde6f7a84a..19b963c11321 100644
--- a/website/pages/vi/resources/roles/delegating.mdx
+++ b/website/pages/vi/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Hướng dẫn Delegator
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - Rủi ro của việc ủy quyền token trong Mạng The Graph
 - Cách tính lợi nhuận kỳ vọng với tư cách là delegator
-- A video guide showing the steps to delegate in the Graph Network UI
+- A video guide explaining
 
 ## Rủi ro Ủy quyền
 
 Lưu ý quan trọng là mỗi lần bạn ủy quyền, bạn sẽ bị tính phí 0.5%. Nghĩa là nếu bạn đang ủy quyền 1000 GRT, bạn sẽ tự động đốt 5 GRT.
 
-### Phí ủy quyền
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### Khoảng thời gian bỏ ràng buộc ủy quyền
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Ví dụ
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 4acc007a18fc0b762275f69f7139ba6cbe7ec0af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:55 -0500
Subject: [PATCH 2610/3820] New translations glossary.mdx (Marathi)

---
 website/pages/mr/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/mr/resources/glossary.mdx b/website/pages/mr/resources/glossary.mdx
index fa813b659730..4dd1c7877e14 100644
--- a/website/pages/mr/resources/glossary.mdx
+++ b/website/pages/mr/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From db49246e9900e312ff2593935e21426fc277a0f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:56 -0500
Subject: [PATCH 2611/3820] New translations delegating.mdx (Marathi)

---
 .../pages/mr/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/mr/resources/roles/delegating.mdx b/website/pages/mr/resources/roles/delegating.mdx
index 694c6c52a9a7..c724e40c9cf4 100644
--- a/website/pages/mr/resources/roles/delegating.mdx
+++ b/website/pages/mr/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Delegator Guide
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
+- A video guide explaining
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 वाईट वर्तनासाठी प्रतिनिधींना कमी केले जाऊ शकत नाही, परंतु नेटवर्कच्या अखंडतेला हानी पोहोचवणाऱ्या खराब निर्णयक्षमतेला प्रोत्साहन देण्यासाठी प्रतिनिधींवर कर लावला जातो.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### उदाहरण
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From ecc6e6fa092d6be3a239bb942d683fa765fe6372 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:57 -0500
Subject: [PATCH 2612/3820] New translations glossary.mdx (Hindi)

---
 website/pages/hi/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/hi/resources/glossary.mdx b/website/pages/hi/resources/glossary.mdx
index ceec54c67cbe..74d8754cb65f 100644
--- a/website/pages/hi/resources/glossary.mdx
+++ b/website/pages/hi/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: शब्दकोष
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From ce9997c394316228aea8b2fbf9e17471ac5dfb72 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:58 -0500
Subject: [PATCH 2613/3820] New translations delegating.mdx (Hindi)

---
 .../pages/hi/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/hi/resources/roles/delegating.mdx b/website/pages/hi/resources/roles/delegating.mdx
index efe4a7054943..bc1f10885f73 100644
--- a/website/pages/hi/resources/roles/delegating.mdx
+++ b/website/pages/hi/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegating
 ---
 
-Delegator नेटवर्क के प्रतिभागी होते हैं जो एक या अधिक इंडेक्सर्स को जीआरटी (GRT) का प्रतिनिधित्व (यानी, "स्टेक") करते हैं।
+# Delegating GRT on The Graph Network
 
-- वे बिना खुद Graph Node चलाए नेटवर्क को सुरक्षित रखने में मदद करते हैं।
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- वे इंडेक्सर को डेलीगेट करके उनकी क्वेरी फीस और पुरस्कार का एक हिस्सा कमाते हैं।
+## Benefits of Delegating
 
-## यह कैसे काम करता है?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## प्रतिनिधि गाइड
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 The Graph Network में एक प्रभावशाली Delegator बनने के लिए सीखें।
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - ग्राफ़ नेटवर्क में टोकन सौंपने का जोखिम
 - प्रतिनिधि के रूप में अपेक्षित रिटर्न की गणना कैसे करें
-- ग्राफ़ नेटवर्क UI में प्रत्यायोजित करने के चरण दिखाने वाली एक वीडियो मार्गदर्शिका
+- A video guide explaining
 
 ## Delegation Risks
 
 प्रोटोकॉल में प्रतिनिधि होने के मुख्य जोखिमों की सूची नीचे दी गई है।
 
-### The delegation tax
+### The Delegation Tax
 
 प्रतिनिधियों को खराब व्यवहार के लिए कम नहीं किया जा सकता है, लेकिन खराब निर्णय लेने को हतोत्साहित करने के लिए प्रतिनिधियों पर एक कर है जो नेटवर्क की अखंडता को नुकसान पहुंचा सकता है।
 
@@ -40,9 +67,13 @@ There are three sections in this guide:
 
 - सुरक्षित रहने के लिए, आपको Indexer को डेलीगेट करते समय अपने संभावित रिटर्न की गणना करनी चाहिए। उदाहरण के लिए, आप यह गणना कर सकते हैं कि आपके डेलीगेशन पर 0.5% कर वापस कमाने में कितने दिन लगेंगे।
 
-### प्रतिनिधिमंडल बंधन अवधि
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### यह क्यों महत्वपूर्ण है?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 MetaMask के माध्यम से Indexers को प्रतिनिधित्व देने के प्रयास कभी-कभी विफल हो सकते हैं और इसके परिणामस्वरूप "Pending" या "Queued" लेनदेन के प्रयासों के लिए लंबे समय तक रुकावट हो सकती है।
 
-#### उदाहरण
-
-अगर आप वर्तमान कीमतों के सापेक्ष अपर्याप्त गैस शुल्क के साथ डेलीगेट करने का प्रयास करते हैं।
-
-- यह क्रिया आपके MetaMask वॉलेट में लेनदेन के प्रयास को "Pending" के रूप में 15+ मिनट तक प्रदर्शित कर सकती है। जब ऐसा होता है, तो आप बाद के लेनदेन करने का प्रयास कर सकते हैं, लेकिन ये केवल तब तक संसाधित होंगे जब तक प्रारंभिक लेनदेन खनन नहीं किया गया है, क्योंकि किसी पते के लिए लेनदेन को क्रम में संसाधित करना आवश्यक है।
-- इस प्रकार के मामलों में, इन लेनदेन को MetaMask में रद्द किया जा सकता है, लेकिन लेनदेन के प्रयास गैस शुल्क को जमा करेंगे बिना यह गारंटी कि बाद के प्रयास सफल होंगे।
-
 इस बग का एक सरल समाधान ब्राउज़र को पुनः प्रारंभ करना है (उदाहरण के लिए, पता बार में "abort
 " का उपयोग करना), जो सभी पिछले प्रयासों को रद्द कर देगा बिना गैस को वॉलेट से घटाए। कई उपयोगकर्ताओं ने जिन्होंने इस समस्या का सामना किया है, उन्होंने अपने ब्राउज़र को पुनः प्रारंभ करने और 'delegation' करने का प्रयास करने के बाद सफल लेनदेन की रिपोर्ट की है।
 

From 355b052df3a3addc122cc8d7ceec04b8c31ef554 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:58:59 -0500
Subject: [PATCH 2614/3820] New translations glossary.mdx (Swahili)

---
 website/pages/sw/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/sw/resources/glossary.mdx b/website/pages/sw/resources/glossary.mdx
index fa813b659730..4dd1c7877e14 100644
--- a/website/pages/sw/resources/glossary.mdx
+++ b/website/pages/sw/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From e69121ac153db0efddccf56a98a7841a5e0ef5f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 13:59:00 -0500
Subject: [PATCH 2615/3820] New translations delegating.mdx (Swahili)

---
 .../pages/sw/resources/roles/delegating.mdx   | 58 +++++++++++++------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/website/pages/sw/resources/roles/delegating.mdx b/website/pages/sw/resources/roles/delegating.mdx
index eda60369e00a..de8c328e613d 100644
--- a/website/pages/sw/resources/roles/delegating.mdx
+++ b/website/pages/sw/resources/roles/delegating.mdx
@@ -2,17 +2,44 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+# Delegating GRT on The Graph Network
 
-- They help secure the network without running a Graph Node themselves.
+Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+## Benefits of Delegating
 
-## How does this work?
+- Strengthen the network’s security and scalability by supporting Indexers.  
+- Earn a portion of rewards generated by the Indexers.
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## How Does Delegation Work?
 
-## Delegator Guide
+An Indexer's ability to process queries and earn rewards depends on three key factors:  
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).  
+2. The total GRT delegated to them by Delegators.  
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
+
+For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
+
+## What Delegators Need to Know
+
+<VideoEmbed youtube="xcegvXxgR4Y" />
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -24,13 +51,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
+- A video guide explaining
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,9 +67,13 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Delegation Unbonding Period
+
+Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the unbonding period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
@@ -125,13 +156,6 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From f4664385c592b392905c510e9c7a284d9eb45acc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:50:06 -0500
Subject: [PATCH 2616/3820] New translations glossary.mdx (Portuguese)

---
 website/pages/pt/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/pt/resources/glossary.mdx b/website/pages/pt/resources/glossary.mdx
index 2d3c0fef2eb3..1f4454d73975 100644
--- a/website/pages/pt/resources/glossary.mdx
+++ b/website/pages/pt/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossário
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 22563108a8cf74fb60714e07a058acca1a0028fa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:50:09 -0500
Subject: [PATCH 2617/3820] New translations delegating.mdx (Portuguese)

---
 .../pages/pt/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/pt/resources/roles/delegating.mdx b/website/pages/pt/resources/roles/delegating.mdx
index afad641c7428..3bc11efac570 100644
--- a/website/pages/pt/resources/roles/delegating.mdx
+++ b/website/pages/pt/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegação
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Aprenda como ser um Delegante eficiente na The Graph Network.
 
@@ -51,13 +24,13 @@ Há três secções neste guia:
 
 - Os riscos de delegar tokens na Graph Network
 - Como calcular retornos esperados como um Delegante
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Riscos de Delegação
 
 Veja abaixo os riscos principais de ser um Delegante no protocolo.
 
-### The Delegation Tax
+### The delegation tax
 
 Os Delegantes não podem ser punidos por mau comportamento, mas há uma taxa sobre Delegantes, para desencorajar más decisões que possam ferir a integridade da rede.
 
@@ -67,13 +40,9 @@ Como Delegante, é importante entender que:
 
 - Por segurança, calcule o seu retorno potencial quando delegar para um Indexador. Por exemplo, pode-se calcular o número de dias até que tenha recuperado a taxa de 0,5% da sua delegação.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Qual a Importância Disto?
 
@@ -154,6 +123,13 @@ Assim, um Delegante deve sempre considerar a Capacidade de Delegação de um Ind
 
 Às vezes, tentativas de delegar a Indexadores via MetaMask podem falhar e deixar tentativas de transação "Pendentes" ou "Em Fila" por períodos prolongados.
 
+#### Exemplo
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 Uma solução mais simples para este bug é a reinicialização do navegador (por ex., "abort:restart" na barra de endereço), o que cancelará todas as tentativas anteriores sem subtrair gas da carteira. Vários utilizadores que encontraram este problema relataram sucesso nas transações após reiniciar o seu navegador e tentar delegar.
 
 ## Guia em Vídeo

From 35352763b541ea09565d4715174c3c9636a5ffb0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:51:59 -0500
Subject: [PATCH 2618/3820] New translations glossary.mdx (Romanian)

---
 website/pages/ro/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/ro/resources/glossary.mdx b/website/pages/ro/resources/glossary.mdx
index 4dd1c7877e14..fa813b659730 100644
--- a/website/pages/ro/resources/glossary.mdx
+++ b/website/pages/ro/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 23adceb0d1d6803ea02fb72409a64e05cbd4325b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:00 -0500
Subject: [PATCH 2619/3820] New translations delegating.mdx (Romanian)

---
 .../pages/ro/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/ro/resources/roles/delegating.mdx b/website/pages/ro/resources/roles/delegating.mdx
index de8c328e613d..eda60369e00a 100644
--- a/website/pages/ro/resources/roles/delegating.mdx
+++ b/website/pages/ro/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegating
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The Delegation Tax
+### The delegation tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From cdbd73c16a338bcec3741beea40ff75c672adc4b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:01 -0500
Subject: [PATCH 2620/3820] New translations glossary.mdx (French)

---
 website/pages/fr/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/fr/resources/glossary.mdx b/website/pages/fr/resources/glossary.mdx
index 4e656d6f95bf..359c0cb2aee2 100644
--- a/website/pages/fr/resources/glossary.mdx
+++ b/website/pages/fr/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossaire
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From d5f85efc0faf5871d9893505cdb8b86cb264a495 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:02 -0500
Subject: [PATCH 2621/3820] New translations delegating.mdx (French)

---
 .../pages/fr/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/fr/resources/roles/delegating.mdx b/website/pages/fr/resources/roles/delegating.mdx
index ae9fbc3a95d1..6db9cdee4dd3 100644
--- a/website/pages/fr/resources/roles/delegating.mdx
+++ b/website/pages/fr/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Délégation
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Apprenez comment être un délégateur efficace dans The Graph Network.
 
@@ -51,13 +24,13 @@ Ce guide comporte trois sections:
 
 - Les risques de la délégation de jetons dans The Graph Network
 - Comment calculer les rendements escomptés en tant que délégué
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Risques de délégation
 
 Les principaux risques liés à la fonction de délégué dans le protocole sont transmis ci-dessous.
 
-### The Delegation Tax
+### The delegation tax
 
 Les délégués ne peuvent pas être licenciés en cas de mauvais comportement, mais ils sont soumis à une taxe visant à décourager les mauvaises décisions susceptibles de nuire à l'intégrité du réseau.
 
@@ -67,13 +40,9 @@ En tant que Délégateur, il est important de comprendre ce qui suit :
 
 - Pour être en sécurité, vous devriez calculer votre retour potentiel lorsque vous déléguez à un Indexeur. Par exemple, vous pourriez calculer combien de jours il faudra avant d'avoir récupéré la taxe de 0,5% sur votre délégation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Pourquoi ceci est t-il important?
 
@@ -157,6 +126,13 @@ Par conséquent, un Déléguateur doit toujours considérer la Capacité de Dél
 
 Parfois, les tentatives de déléguer aux Indexeurs via MetaMask peuvent échouer et entraîner des périodes prolongées de tentatives de transaction "Pending" ou "Queued".
 
+#### Exemple
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 Une solution simple à ce problème consiste à redémarrer le navigateur (par exemple, en utilisant "abort:restart" dans la barre d'adresse), ce qui annulera toutes les tentatives précédentes sans que le gaz ne soit soustrait du portefeuille. Plusieurs utilisateurs ayant rencontré ce problème ont signalé des transactions réussies après avoir redémarré leur navigateur et tenté de déléguer.
 
 ## Guide Vidéo

From c8961c2e754ee47a66d963703c84f97abc69db89 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:03 -0500
Subject: [PATCH 2622/3820] New translations glossary.mdx (Spanish)

---
 website/pages/es/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/es/resources/glossary.mdx b/website/pages/es/resources/glossary.mdx
index 0e4995589624..fdca3b093220 100644
--- a/website/pages/es/resources/glossary.mdx
+++ b/website/pages/es/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glosario
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 49d50f9e2a6bf51e4e31bab7028d572b2464173e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:04 -0500
Subject: [PATCH 2623/3820] New translations delegating.mdx (Spanish)

---
 .../pages/es/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/es/resources/roles/delegating.mdx b/website/pages/es/resources/roles/delegating.mdx
index c5363ac41e1c..1470e14f300b 100644
--- a/website/pages/es/resources/roles/delegating.mdx
+++ b/website/pages/es/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegar
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - Los riesgos de delegar tokens en la red de The Graph
 - Cómo calcular los rendimientos que te esperan siendo Delegador
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Riesgos de la Delegación
 
 A continuación se enumeran los principales riesgos de ser un Delegador en el protocolo.
 
-### The Delegation Tax
+### The delegation tax
 
 Los Delegadores no pueden ser recortados por mal comportamiento, pero existe un impuesto sobre los Delegadores para desincentivar la toma de malas decisiones que puedan perjudicar la integridad de la red.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Ejemplo
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 75300150e6f610cf5c97886c56d660e397014024 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:06 -0500
Subject: [PATCH 2624/3820] New translations glossary.mdx (Arabic)

---
 website/pages/ar/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/ar/resources/glossary.mdx b/website/pages/ar/resources/glossary.mdx
index 06c7d215f934..dde52c37403a 100644
--- a/website/pages/ar/resources/glossary.mdx
+++ b/website/pages/ar/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: قائمة المصطلحات
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 2352ad10446d7dc10db6ad878f04b3bb4053b5d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:07 -0500
Subject: [PATCH 2625/3820] New translations delegating.mdx (Arabic)

---
 .../pages/ar/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/ar/resources/roles/delegating.mdx b/website/pages/ar/resources/roles/delegating.mdx
index e45467d230b2..59f79e78bcf2 100644
--- a/website/pages/ar/resources/roles/delegating.mdx
+++ b/website/pages/ar/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegating
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - مخاطر تفويض التوكن في شبكة The Graph
 - كيفية حساب العوائد المتوقعة كمفوض
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 القائمة أدناه هي المخاطر الرئيسية لكونك مفوضا في البروتوكول.
 
-### The Delegation Tax
+### The delegation tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From e75cc1b30f363a8eaf5175a543f501bdc5936b13 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:08 -0500
Subject: [PATCH 2626/3820] New translations glossary.mdx (Czech)

---
 website/pages/cs/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/cs/resources/glossary.mdx b/website/pages/cs/resources/glossary.mdx
index c6bbd9ea94fc..ead2fbb3e17b 100644
--- a/website/pages/cs/resources/glossary.mdx
+++ b/website/pages/cs/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glosář
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From cf0b4f5df588090f5bb1e4ccb38b9c848783459f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:09 -0500
Subject: [PATCH 2627/3820] New translations delegating.mdx (Czech)

---
 .../pages/cs/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/cs/resources/roles/delegating.mdx b/website/pages/cs/resources/roles/delegating.mdx
index b7b2e15aa53d..3d3ad1dfc5e8 100644
--- a/website/pages/cs/resources/roles/delegating.mdx
+++ b/website/pages/cs/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegování
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - Rizika delegování tokenů v síti Graf
 - Jak vypočítat očekávané výnosy jako delegát
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Rizika delegování
 
 Níže jsou uvedena hlavní rizika plynoucí z delegáta v protokolu.
 
-### The Delegation Tax
+### The delegation tax
 
 Delegáti nemohou být za špatné chování kráceni, ale existuje daň pro delegáty, která má odradit od špatného rozhodování, jež by mohlo poškodit integritu sítě.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Příklad
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From f28238f411df3ff2eb9c71d9bf6066b5f9367e9f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:15 -0500
Subject: [PATCH 2628/3820] New translations glossary.mdx (German)

---
 website/pages/de/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/de/resources/glossary.mdx b/website/pages/de/resources/glossary.mdx
index 4dd1c7877e14..fa813b659730 100644
--- a/website/pages/de/resources/glossary.mdx
+++ b/website/pages/de/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From aa3f26781f950caa1c6f027b4dde9f0f9b0d0528 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:16 -0500
Subject: [PATCH 2629/3820] New translations delegating.mdx (German)

---
 .../pages/de/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/de/resources/roles/delegating.mdx b/website/pages/de/resources/roles/delegating.mdx
index de8c328e613d..5fa99f101641 100644
--- a/website/pages/de/resources/roles/delegating.mdx
+++ b/website/pages/de/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegating
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The Delegation Tax
+### The delegation tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Beispiel
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 98b2282eb8e6a9259d7575400201512785a0974d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:39 -0500
Subject: [PATCH 2630/3820] New translations glossary.mdx (Italian)

---
 website/pages/it/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/it/resources/glossary.mdx b/website/pages/it/resources/glossary.mdx
index 4dd1c7877e14..fa813b659730 100644
--- a/website/pages/it/resources/glossary.mdx
+++ b/website/pages/it/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 41eda52cae7b463a1f4702485a0706611477fc27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:40 -0500
Subject: [PATCH 2631/3820] New translations delegating.mdx (Italian)

---
 .../pages/it/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/it/resources/roles/delegating.mdx b/website/pages/it/resources/roles/delegating.mdx
index 6a3f67c87e48..ba6e0319839b 100644
--- a/website/pages/it/resources/roles/delegating.mdx
+++ b/website/pages/it/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegazione
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - I rischi della delegazione dei token in The Graph Network
 - Come calcolare i rendimenti previsti come Delegator
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Rischi di delegazione
 
 Di seguito sono elencati i principali rischi essere il Delegator nel protocollo.
 
-### The Delegation Tax
+### The delegation tax
 
 I delegator non possono essere penalizzati per un comportamento scorretto, ma c'è una tassa sui delegator per disincentivare un processo decisionale insufficiente che potrebbero danneggiare l'integrità della rete.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Esempio
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 7fef91849c24c10adb6612d236a939b57e968be4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:41 -0500
Subject: [PATCH 2632/3820] New translations glossary.mdx (Japanese)

---
 website/pages/ja/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/ja/resources/glossary.mdx b/website/pages/ja/resources/glossary.mdx
index d8b838fcd2a7..baab87472fce 100644
--- a/website/pages/ja/resources/glossary.mdx
+++ b/website/pages/ja/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: 用語集
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 9560159b2d7f2ed3238be499b08f1161de97b687 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:43 -0500
Subject: [PATCH 2633/3820] New translations delegating.mdx (Japanese)

---
 .../pages/ja/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/ja/resources/roles/delegating.mdx b/website/pages/ja/resources/roles/delegating.mdx
index 2b781de3e817..604233139afd 100644
--- a/website/pages/ja/resources/roles/delegating.mdx
+++ b/website/pages/ja/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: 委任
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - グラフネットワークでトークンをデリゲートすることのリスク
 - デリゲーターとしての期待リターンの計算方法
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## デリゲーションリスク
 
 以下にリストされているのは、プロトコルで委任者になることの主なリスクです。
 
-### The Delegation Tax
+### The delegation tax
 
 デリゲーターは悪意の行動をしてもスラッシュされないが、デリゲーターにはデポジット税が課せられ、ネットワークの整合性を損なう可能性のある悪い意思決定を抑止します。
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### 例
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From ea657df5ef5de1d45716d219ac1bc148dc333ccf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:44 -0500
Subject: [PATCH 2634/3820] New translations glossary.mdx (Korean)

---
 website/pages/ko/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/ko/resources/glossary.mdx b/website/pages/ko/resources/glossary.mdx
index 4dd1c7877e14..fa813b659730 100644
--- a/website/pages/ko/resources/glossary.mdx
+++ b/website/pages/ko/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 857b6482dfab912b7f7470e66ec28f73b421d878 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:45 -0500
Subject: [PATCH 2635/3820] New translations delegating.mdx (Korean)

---
 .../pages/ko/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/ko/resources/roles/delegating.mdx b/website/pages/ko/resources/roles/delegating.mdx
index de8c328e613d..eda60369e00a 100644
--- a/website/pages/ko/resources/roles/delegating.mdx
+++ b/website/pages/ko/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegating
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The Delegation Tax
+### The delegation tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 219561c2cf999e028dd34274cf7ceec023a9cc05 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:46 -0500
Subject: [PATCH 2636/3820] New translations glossary.mdx (Dutch)

---
 website/pages/nl/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/nl/resources/glossary.mdx b/website/pages/nl/resources/glossary.mdx
index 4dd1c7877e14..fa813b659730 100644
--- a/website/pages/nl/resources/glossary.mdx
+++ b/website/pages/nl/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 65c196e177e0848b3c4b332857c31c459ff05a89 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:47 -0500
Subject: [PATCH 2637/3820] New translations delegating.mdx (Dutch)

---
 .../pages/nl/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/nl/resources/roles/delegating.mdx b/website/pages/nl/resources/roles/delegating.mdx
index 7ae98f882684..99bd3b78d432 100644
--- a/website/pages/nl/resources/roles/delegating.mdx
+++ b/website/pages/nl/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegeren
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - De risico's van het delegeren van tokens in het Graph Netwerk
 - Hoe je verwachte opbrengsten als Delegeerder berekent
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegatie Risico's
 
 Hieronder staan de belangrijkste risico's van het zijn van een Delegeerder in het protocol.
 
-### The Delegation Tax
+### The delegation tax
 
 Delegeerders kunnen niet worden gestraft voor slecht gedrag, maar er is een belasting voor Delegeerders om slechte besluitvorming die de integriteit van het netwerk kan schaden te ontmoedigen.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 23a26b435922b556ae5fa32d3217e9f8499dd776 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:48 -0500
Subject: [PATCH 2638/3820] New translations glossary.mdx (Polish)

---
 website/pages/pl/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/pl/resources/glossary.mdx b/website/pages/pl/resources/glossary.mdx
index 4dd1c7877e14..fa813b659730 100644
--- a/website/pages/pl/resources/glossary.mdx
+++ b/website/pages/pl/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 3aef9e609c3034da0e7a7ab426fbbbc032bc2ed8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:49 -0500
Subject: [PATCH 2639/3820] New translations delegating.mdx (Polish)

---
 .../pages/pl/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/pl/resources/roles/delegating.mdx b/website/pages/pl/resources/roles/delegating.mdx
index de8c328e613d..eda60369e00a 100644
--- a/website/pages/pl/resources/roles/delegating.mdx
+++ b/website/pages/pl/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegating
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The Delegation Tax
+### The delegation tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 40e1c3812c87e8ca34c184c7c780dd43af0c0264 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:50 -0500
Subject: [PATCH 2640/3820] New translations glossary.mdx (Russian)

---
 website/pages/ru/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/ru/resources/glossary.mdx b/website/pages/ru/resources/glossary.mdx
index 4dd1c7877e14..fa813b659730 100644
--- a/website/pages/ru/resources/glossary.mdx
+++ b/website/pages/ru/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 2fa19ea468c28d3b858c0d022e6dd7e691cffc38 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:51 -0500
Subject: [PATCH 2641/3820] New translations delegating.mdx (Russian)

---
 .../pages/ru/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/ru/resources/roles/delegating.mdx b/website/pages/ru/resources/roles/delegating.mdx
index a7dfd0051e00..ec31c0cd9420 100644
--- a/website/pages/ru/resources/roles/delegating.mdx
+++ b/website/pages/ru/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Делегирование
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - Риски связанные с делегацией в сети The Graph
 - Как расчитать примерный доход
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Риски делегации
 
 Ниже указаны основные риски Делегатора.
 
-### The Delegation Tax
+### The delegation tax
 
 Делегаторы не могут быть наказаны за некорректное поведение, но они уплачивают комиссию на делегацию, который должен стимулировать обдуманный выбор Индексатора для делегации.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Пример
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 866860451612226c09dba3957541db8a9efd52c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:52 -0500
Subject: [PATCH 2642/3820] New translations glossary.mdx (Swedish)

---
 website/pages/sv/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/sv/resources/glossary.mdx b/website/pages/sv/resources/glossary.mdx
index 7facf5d2ec88..b6cf29493dc3 100644
--- a/website/pages/sv/resources/glossary.mdx
+++ b/website/pages/sv/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Ordlista
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From bae70163a054edce8a891f9ea7415d5171b7c7d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:53 -0500
Subject: [PATCH 2643/3820] New translations delegating.mdx (Swedish)

---
 .../pages/sv/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/sv/resources/roles/delegating.mdx b/website/pages/sv/resources/roles/delegating.mdx
index a7fa595662cd..c024c25aee54 100644
--- a/website/pages/sv/resources/roles/delegating.mdx
+++ b/website/pages/sv/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegera
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - Riskerna med att delegera tokens i The Graph-nätverket
 - Hur man beräknar förväntad avkastning som Delegater
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegationsrisker
 
 Här nedan listas huvudriskerna med att vara en Delegater i protokollet.
 
-### The Delegation Tax
+### The delegation tax
 
 Delegater kan inte "slashas" för dåligt beteende, men det finns en avgift för Delegater för att avskräcka dåligt beslutsfattande som kan skada nätverkets integritet.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Exempel
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From fe2cb1a1b6f1f42ad17058823298ffa0ca7742c6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:55 -0500
Subject: [PATCH 2644/3820] New translations glossary.mdx (Turkish)

---
 website/pages/tr/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/tr/resources/glossary.mdx b/website/pages/tr/resources/glossary.mdx
index 4dd1c7877e14..fa813b659730 100644
--- a/website/pages/tr/resources/glossary.mdx
+++ b/website/pages/tr/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 32eae4a5551c410dfa43fb175ad49422c7a8acb7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:56 -0500
Subject: [PATCH 2645/3820] New translations delegating.mdx (Turkish)

---
 .../pages/tr/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/tr/resources/roles/delegating.mdx b/website/pages/tr/resources/roles/delegating.mdx
index de8c328e613d..a7be05b9f698 100644
--- a/website/pages/tr/resources/roles/delegating.mdx
+++ b/website/pages/tr/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegating
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The Delegation Tax
+### The delegation tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Örnek
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From f75440d2eb1710c40ed081b85a1484b881da1d8f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:57 -0500
Subject: [PATCH 2646/3820] New translations glossary.mdx (Ukrainian)

---
 website/pages/uk/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/uk/resources/glossary.mdx b/website/pages/uk/resources/glossary.mdx
index f67d04041687..96e2835ae2aa 100644
--- a/website/pages/uk/resources/glossary.mdx
+++ b/website/pages/uk/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Глосарій
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 6162114003ed1eac6aafc75f1b33d9d54b0ebd4e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:58 -0500
Subject: [PATCH 2647/3820] New translations delegating.mdx (Ukrainian)

---
 .../pages/uk/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/uk/resources/roles/delegating.mdx b/website/pages/uk/resources/roles/delegating.mdx
index 9d79eef569ce..48541d9117ed 100644
--- a/website/pages/uk/resources/roles/delegating.mdx
+++ b/website/pages/uk/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Делегування
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - Ризики делегування токенів в мережі Graph
 - Як розрахувати можливі прибутки як делегат
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Ризики, пов'язані з делегуванням
 
 Нижче перераховані основні ризики, пов'язані з участю делегата в протоколі.
 
-### The Delegation Tax
+### The delegation tax
 
 Делегати не можуть бути виключені за погану поведінку, але існує певний штраф для них, щоб позбавити стимулу щодо прийняття поганих рішень, які можуть зашкодити цілісності мережі.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 84b6bbb630de3eee4ca341d522b56e971dccf5f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:52:59 -0500
Subject: [PATCH 2648/3820] New translations glossary.mdx (Chinese Simplified)

---
 website/pages/zh/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/zh/resources/glossary.mdx b/website/pages/zh/resources/glossary.mdx
index 38aac3e6a541..987d665b3c69 100644
--- a/website/pages/zh/resources/glossary.mdx
+++ b/website/pages/zh/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: 术语汇编
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 3c348cb4679df0ac383bc6853dbd3ec0ff3f6c25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:00 -0500
Subject: [PATCH 2649/3820] New translations delegating.mdx (Chinese
 Simplified)

---
 .../pages/zh/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/zh/resources/roles/delegating.mdx b/website/pages/zh/resources/roles/delegating.mdx
index 45906503eb43..1f0d2a45d054 100644
--- a/website/pages/zh/resources/roles/delegating.mdx
+++ b/website/pages/zh/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: 委托
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - 在 Graph 网络中委托代币的风险
 - 如何计算作为委托人的预期回报
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## 委托风险
 
 下面列出了作为协议中的委托人的主要风险。
 
-### The Delegation Tax
+### The delegation tax
 
 委托人不能因为不良行为而被取消，但对委托有税，以抑制可能损害网络完整性的不良决策。
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### 示例
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 51325f073ddd90f7a5b747a70354eb66931ce2c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:01 -0500
Subject: [PATCH 2650/3820] New translations glossary.mdx (Urdu (Pakistan))

---
 website/pages/ur/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/ur/resources/glossary.mdx b/website/pages/ur/resources/glossary.mdx
index e9feda2df120..79b2da2f0e65 100644
--- a/website/pages/ur/resources/glossary.mdx
+++ b/website/pages/ur/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: لغت
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 28d0f94de7365a884865595acdde71630787ae6c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:02 -0500
Subject: [PATCH 2651/3820] New translations delegating.mdx (Urdu (Pakistan))

---
 .../pages/ur/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/ur/resources/roles/delegating.mdx b/website/pages/ur/resources/roles/delegating.mdx
index 031bd470d330..274d03e80ef0 100644
--- a/website/pages/ur/resources/roles/delegating.mdx
+++ b/website/pages/ur/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: ڈیلیگیٹنگ
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - گراف نیٹ ورک میں ٹوکن ڈیلیگ کرنے کے خطرات
 - بطور ڈیلیگیٹر متوقع واپسی کا حساب کیسے لگائیں
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## ڈیلیگیشن کے خطرات
 
 پروٹوکول میں ڈیلیگیٹر ہونےکے اہم خطرات مندرجہ ذیل ہیں.
 
-### The Delegation Tax
+### The delegation tax
 
 برے رویۓ پر ڈیلیگیٹرز کو نہیں چھوڑا جا سکتا، لیکن ناقص فیصلہ سازی کی حوصلہ شکنی کے لیے ڈیلیگیٹرز پر ٹیکس ہے جو نیٹ ورک کی سالمیت کو نقصان پہنچا سکتا ہے.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### مثال
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 55edbd3bf8f572a07d87fad4b408151b2e205522 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:04 -0500
Subject: [PATCH 2652/3820] New translations glossary.mdx (Vietnamese)

---
 website/pages/vi/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/vi/resources/glossary.mdx b/website/pages/vi/resources/glossary.mdx
index 4dd1c7877e14..fa813b659730 100644
--- a/website/pages/vi/resources/glossary.mdx
+++ b/website/pages/vi/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 81dc7dd29112f7d6ec3b50ed519672a664a5d628 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:05 -0500
Subject: [PATCH 2653/3820] New translations delegating.mdx (Vietnamese)

---
 .../pages/vi/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/vi/resources/roles/delegating.mdx b/website/pages/vi/resources/roles/delegating.mdx
index 19b963c11321..977224430174 100644
--- a/website/pages/vi/resources/roles/delegating.mdx
+++ b/website/pages/vi/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegating
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - Rủi ro của việc ủy quyền token trong Mạng The Graph
 - Cách tính lợi nhuận kỳ vọng với tư cách là delegator
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Rủi ro Ủy quyền
 
 Lưu ý quan trọng là mỗi lần bạn ủy quyền, bạn sẽ bị tính phí 0.5%. Nghĩa là nếu bạn đang ủy quyền 1000 GRT, bạn sẽ tự động đốt 5 GRT.
 
-### The Delegation Tax
+### The delegation tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Ví dụ
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 8e1a1368195b47a27b769e6b1f93f0ed3da9273b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:06 -0500
Subject: [PATCH 2654/3820] New translations glossary.mdx (Marathi)

---
 website/pages/mr/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/mr/resources/glossary.mdx b/website/pages/mr/resources/glossary.mdx
index 4dd1c7877e14..fa813b659730 100644
--- a/website/pages/mr/resources/glossary.mdx
+++ b/website/pages/mr/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 502022b8b8a2dff47e6bcd30dea50cd83d513507 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:07 -0500
Subject: [PATCH 2655/3820] New translations delegating.mdx (Marathi)

---
 .../pages/mr/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/mr/resources/roles/delegating.mdx b/website/pages/mr/resources/roles/delegating.mdx
index c724e40c9cf4..694c6c52a9a7 100644
--- a/website/pages/mr/resources/roles/delegating.mdx
+++ b/website/pages/mr/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegating
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The Delegation Tax
+### The delegation tax
 
 वाईट वर्तनासाठी प्रतिनिधींना कमी केले जाऊ शकत नाही, परंतु नेटवर्कच्या अखंडतेला हानी पोहोचवणाऱ्या खराब निर्णयक्षमतेला प्रोत्साहन देण्यासाठी प्रतिनिधींवर कर लावला जातो.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### उदाहरण
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 901957b9b9a8d1cff009a1ecb8d1379aa5e72de9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:08 -0500
Subject: [PATCH 2656/3820] New translations glossary.mdx (Hindi)

---
 website/pages/hi/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/hi/resources/glossary.mdx b/website/pages/hi/resources/glossary.mdx
index 74d8754cb65f..ceec54c67cbe 100644
--- a/website/pages/hi/resources/glossary.mdx
+++ b/website/pages/hi/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: शब्दकोष
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 44cdda5f7b9bdb49be1a63faa5a32bb3cf716efe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:09 -0500
Subject: [PATCH 2657/3820] New translations delegating.mdx (Hindi)

---
 .../pages/hi/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/hi/resources/roles/delegating.mdx b/website/pages/hi/resources/roles/delegating.mdx
index bc1f10885f73..1334fea687a8 100644
--- a/website/pages/hi/resources/roles/delegating.mdx
+++ b/website/pages/hi/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegating
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 The Graph Network में एक प्रभावशाली Delegator बनने के लिए सीखें।
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - ग्राफ़ नेटवर्क में टोकन सौंपने का जोखिम
 - प्रतिनिधि के रूप में अपेक्षित रिटर्न की गणना कैसे करें
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 प्रोटोकॉल में प्रतिनिधि होने के मुख्य जोखिमों की सूची नीचे दी गई है।
 
-### The Delegation Tax
+### The delegation tax
 
 प्रतिनिधियों को खराब व्यवहार के लिए कम नहीं किया जा सकता है, लेकिन खराब निर्णय लेने को हतोत्साहित करने के लिए प्रतिनिधियों पर एक कर है जो नेटवर्क की अखंडता को नुकसान पहुंचा सकता है।
 
@@ -67,13 +40,9 @@ There are three sections in this guide:
 
 - सुरक्षित रहने के लिए, आपको Indexer को डेलीगेट करते समय अपने संभावित रिटर्न की गणना करनी चाहिए। उदाहरण के लिए, आप यह गणना कर सकते हैं कि आपके डेलीगेशन पर 0.5% कर वापस कमाने में कितने दिन लगेंगे।
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### यह क्यों महत्वपूर्ण है?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 MetaMask के माध्यम से Indexers को प्रतिनिधित्व देने के प्रयास कभी-कभी विफल हो सकते हैं और इसके परिणामस्वरूप "Pending" या "Queued" लेनदेन के प्रयासों के लिए लंबे समय तक रुकावट हो सकती है।
 
+#### उदाहरण
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 इस बग का एक सरल समाधान ब्राउज़र को पुनः प्रारंभ करना है (उदाहरण के लिए, पता बार में "abort
 " का उपयोग करना), जो सभी पिछले प्रयासों को रद्द कर देगा बिना गैस को वॉलेट से घटाए। कई उपयोगकर्ताओं ने जिन्होंने इस समस्या का सामना किया है, उन्होंने अपने ब्राउज़र को पुनः प्रारंभ करने और 'delegation' करने का प्रयास करने के बाद सफल लेनदेन की रिपोर्ट की है।
 

From bba6b609132445c856717546b327ad4b43dd6225 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:10 -0500
Subject: [PATCH 2658/3820] New translations glossary.mdx (Swahili)

---
 website/pages/sw/resources/glossary.mdx | 2 --
 1 file changed, 2 deletions(-)

diff --git a/website/pages/sw/resources/glossary.mdx b/website/pages/sw/resources/glossary.mdx
index 4dd1c7877e14..fa813b659730 100644
--- a/website/pages/sw/resources/glossary.mdx
+++ b/website/pages/sw/resources/glossary.mdx
@@ -22,8 +22,6 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake. Additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m. Indexers can increase their Delegation Capacity by increasing their Indexer's Self-Stake.
-
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 8f7648e14eb27347065767f5c3121177a85863a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:12 -0500
Subject: [PATCH 2659/3820] New translations delegating.mdx (Swahili)

---
 .../pages/sw/resources/roles/delegating.mdx   | 58 ++++++-------------
 1 file changed, 17 insertions(+), 41 deletions(-)

diff --git a/website/pages/sw/resources/roles/delegating.mdx b/website/pages/sw/resources/roles/delegating.mdx
index de8c328e613d..eda60369e00a 100644
--- a/website/pages/sw/resources/roles/delegating.mdx
+++ b/website/pages/sw/resources/roles/delegating.mdx
@@ -2,44 +2,17 @@
 title: Delegating
 ---
 
-# Delegating GRT on The Graph Network
+Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
 
-Delegators play a crucial role on The Graph Network by delegating GRT to Indexers. This process supports network security and functionality without requiring Delegators to run a Graph Node.
+- They help secure the network without running a Graph Node themselves.
 
-## Benefits of Delegating
+- They earn a portion of an Indexer's query fees and rewards by delegating to them.
 
-- Strengthen the network’s security and scalability by supporting Indexers.  
-- Earn a portion of rewards generated by the Indexers.
+## How does this work?
 
-## How Does Delegation Work?
+The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:  
-
-1. The Indexer's Self-Stake (GRT staked by the Indexer).  
-2. The total GRT delegated to them by Delegators.  
-3. The price the Indexer sets for queries.
-
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards.
-
-### What is Delegation Capacity?
-
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
-
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated tokens.
-
-For example, if an Indexer has a Self-Stake of 1m GRT, their delegation capacity is 16m.
-
-### Why Does Delegation Capacity Matter?
-
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
-
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
-
-Indexers can increase their Delegation Capacity by their Self-Stake, thereby raising the limit for delegated tokens.
-
-## What Delegators Need to Know
-
-<VideoEmbed youtube="xcegvXxgR4Y" />
+## Delegator Guide
 
 Learn how to be an effective Delegator in The Graph Network.
 
@@ -51,13 +24,13 @@ There are three sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide explaining
+- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The Delegation Tax
+### The delegation tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -67,13 +40,9 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The Delegation Unbonding Period
-
-Whene a Delegator chooses to undelegate, their tokens are subject to a 28-day unbonding period.
+### The delegation unbonding period
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
-
-After the unbonding period, GRT will return to your crypto wallet.
+Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 ### Why is this important?
 
@@ -156,6 +125,13 @@ Therefore, a Delegator should always consider the Delegation Capacity of an Inde
 
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
+#### Example
+
+Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+
+- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
+- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
 
 ## Video Guide

From 6b11a86ea25d4a8692f2445d17acd0fbe9f58523 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:52 -0500
Subject: [PATCH 2660/3820] New translations grafting-hotfix.mdx (French)

---
 website/pages/fr/subgraphs/cookbook/grafting-hotfix.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/fr/subgraphs/cookbook/grafting-hotfix.mdx
index 9c5e7b4c4051..e16fd82a2fb4 100644
--- a/website/pages/fr/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/fr/subgraphs/cookbook/grafting-hotfix.mdx
@@ -164,7 +164,7 @@ Grafting is an effective strategy for deploying hotfixes in subgraph development
 
 However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
 
-## Ressources complémentaires
+## Ressources supplémentaires
 
 - **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
 - **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.

From f16c4b13d441f976d0a7d63a9ffbf0504963cb82 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 17 Jan 2025 15:53:54 -0500
Subject: [PATCH 2661/3820] New translations grafting.mdx (French)

---
 website/pages/fr/subgraphs/cookbook/grafting.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/cookbook/grafting.mdx b/website/pages/fr/subgraphs/cookbook/grafting.mdx
index 8d8e1206de5f..a81cf0ddf30a 100644
--- a/website/pages/fr/subgraphs/cookbook/grafting.mdx
+++ b/website/pages/fr/subgraphs/cookbook/grafting.mdx
@@ -189,7 +189,7 @@ You can see that the `graft-replacement` subgraph is indexing from older `graph-
 
 Félicitations ! Vous avez réussi à greffer un subgraph sur un autre subgraph.
 
-## Ressources complémentaires
+## Ressources supplémentaires
 
 Si vous souhaitez acquérir plus d'expérience avec le greffage, voici quelques exemples pour des contrats populaires :
 

From c11ca1b5f14b59b65c1f8466654a70b4a7c24a9d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 18 Jan 2025 10:08:54 -0500
Subject: [PATCH 2662/3820] New translations delegating.mdx (German)

---
 .../pages/de/resources/roles/delegating.mdx   | 54 +++++++++----------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/website/pages/de/resources/roles/delegating.mdx b/website/pages/de/resources/roles/delegating.mdx
index 5fa99f101641..c67be429d140 100644
--- a/website/pages/de/resources/roles/delegating.mdx
+++ b/website/pages/de/resources/roles/delegating.mdx
@@ -1,5 +1,5 @@
 ---
-title: Delegating
+title: Delegieren
 ---
 
 Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
@@ -14,50 +14,50 @@ The number of queries an Indexer can process depends on their own stake, **the d
 
 ## Delegator Guide
 
-Learn how to be an effective Delegator in The Graph Network.
+Erfahren Sie im The Graph Netzwerk, wie Sie ein effektiver Delegator sein können.
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Die Delegatoren teilen die Erträge des Protokolls mit allen Indexern auf der Grundlage ihres delegierten Einsatzes. Daher müssen sie nach bestem Wissen und Gewissen Indexer auf der Grundlage mehrerer Faktoren auswählen.
 
 > Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
 
-There are three sections in this guide:
+Dieser Leitfaden besteht aus drei Abschnitten:
 
-- The risks of delegating tokens in The Graph Network
-- How to calculate expected returns as a Delegator
+- Die Risiken der Übertragung von Token in The Graph Network
+- Wie man als Delegator die erwarteten Erträge berechnet
 - A video guide showing the steps to delegate in the Graph Network UI
 
-## Delegation Risks
+## Risiken bei der Delegation
 
-Listed below are the main risks of being a Delegator in the protocol.
+Nachfolgend sind die wichtigsten Risiken aufgeführt, die mit der Tätigkeit eines Delegators im Protokoll verbunden sind.
 
 ### The delegation tax
 
-Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+Delegatoren können nicht für schlechtes Verhalten bestraft werden, aber es gibt eine Steuer für Delegatoren, um von schlechten Entscheidungen abzuschrecken, die die Integrität des Netzes beeinträchtigen könnten.
 
-As a Delegator, it's important to understand the following:
+Als Delegator ist es wichtig, die folgenden Punkte zu verstehen:
 
-- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+- Bei jeder Delegation werden Ihnen 0,5 % berechnet. Das heißt, wenn Sie 1.000 GRT delegieren, verbrauchen Sie automatisch 5 GRT.
 
-- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+- Um auf Nummer sicher zu gehen, sollten Sie Ihre potenzielle Rendite berechnen, wenn Sie einen Indexer beauftragen. Als Beispiel könnten Sie berechnen, wie viele Tage es dauern wird, bis Sie die 0,5 % Steuer auf Ihre Delegation zurückverdient haben.
 
 ### The delegation unbonding period
 
 Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
 
-### Why is this important?
+### Warum ist das wichtig?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+Wenn Sie sich für einen Indexer entscheiden, der nicht vertrauenswürdig ist oder keine gute Arbeit leistet, werden Sie die Abtretung rückgängig machen wollen. Das bedeutet, dass Sie viele Möglichkeiten verlieren, Rewards zu verdienen, was genauso schlimm sein kann wie das Verbrennen von GRT. Daher sollten Sie einen Indexer mit Bedacht auswählen.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+### Auswahl eines vertrauenswürdigen Indexers mit einer fairen Reward-Ausschüttung für Delegatoren
 
-In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+Um zu verstehen, wie man einen vertrauenswürdigen Indexer auswählt, müssen Sie die Delegationsparameter verstehen.
 
-#### Delegation Parameters
+#### Parameter der Delegation
 
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
@@ -105,25 +105,25 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Considering the delegation capacity
+### Berücksichtigung der Delegationskapazität
 
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+Schließlich ist noch die Delegationskapazität zu berücksichtigen. Derzeit ist die Delegationsquote auf 16 festgelegt.
 
-#### Why does this matter?
+#### Warum ist das wichtig?
 
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+Das bedeutet, wenn ein Indexer 1.000.000 GRT eingesetzt hat, beträgt seine Delegationskapazität 16.000.000 GRT an delegierten Token, die er im Protokoll verwenden kann. Alle delegierten Token, die diesen Betrag überschreiten, verwässern alle Rewards des Delegators.
 
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+Stellen Sie sich einen Indexer vor, dem 100.000.000 GRT übertragen wurden, der aber nur über eine Kapazität von 16.000.000 GRT verfügt. Das bedeutet, dass 84.000.000 GRT-Tokens nicht genutzt werden, um Tokens zu verdienen. Sowohl die Delegatoren als auch die Indexer verdienen also weniger Rewards als sie könnten.
 
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+Daher sollte ein Delegator immer die Delegationskapazität eines Indexers in Betracht ziehen und diese in seine Entscheidungsfindung einbeziehen.
 
-## Delegator FAQs and Bugs
+## Delegator FAQs und Bugs
 
-### MetaMask "Pending Transaction" Bug
+### MetaMask-Fehler „Ausstehende Transaktion“
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+1. Wenn ich versuche, meine Transaktion in MetaMask zu delegieren, erscheint sie als „Pending“ ("Ausstehend") oder „Queued“ ("In der Warteschlange") länger als erwartet. Was sollte ich tun?
 
-At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+Gelegentlich können Versuche, Indexer über MetaMask zu delegieren, fehlschlagen und zu längeren Zeiträumen mit „Pending“ oder „Queued“ Transaktionsversuchen führen.
 
 #### Beispiel
 

From e043e75d4775d4606ee5ce6830e39f5adef6bf03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 18 Jan 2025 20:27:42 -0500
Subject: [PATCH 2663/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index 0fd4e74ae207..7e19a5ee43d2 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -18,7 +18,7 @@ La mise minimale pour un indexeur est actuellement fixée à 100 000 GRT.
 
 ### Quelles sont les sources de revenus pour un indexeur ?
 
-**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+**Remboursements des frais de requête** - Paiements pour le traitement des requêtes sur le réseau. Ces paiements sont gérés via des canaux d’état entre un Indexeur et une passerelle. Chaque demande de requête provenant d'une passerelle contient un paiement et la réponse correspondante, une preuve de validité du résultat de la requête.
 
 **Récompenses d'indexation** - Générées via une inflation annuelle de 3 % à l'échelle du protocole, les récompenses d'indexation sont distribuées aux Indexeurs qui indexent les déploiements de subgraph pour le réseau.
 

From eb4dfb2bed91b666ddc43b483bb2717a8ecacc44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 18 Jan 2025 20:27:44 -0500
Subject: [PATCH 2664/3820] New translations benefits.mdx (Portuguese)

---
 website/pages/pt/resources/benefits.mdx | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/pt/resources/benefits.mdx b/website/pages/pt/resources/benefits.mdx
index e49e63cfaeb6..6bff482edfa7 100644
--- a/website/pages/pt/resources/benefits.mdx
+++ b/website/pages/pt/resources/benefits.mdx
@@ -1,11 +1,11 @@
 ---
-title: The Graph vs. Self Hosting
+title: Rede do The Graph x Auto-hospedagem
 socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
 ---
 
 A rede descentralizada do The Graph é construída e refinada para criar uma experiência robusta de indexação e consultas—e ela melhora diariamente, graças a milhares de contribuintes ao redor do mundo.
 
-The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+As vantagens deste protocolo descentralizado não podem ser replicadas com a execução local de um `graph-node`. A Graph Network é mais estável, mais eficiente, e mais barata.
 
 Aqui está uma análise:
 
@@ -19,7 +19,7 @@ Aqui está uma análise:
 
 ## Os Benefícios
 
-### Lower & more Flexible Cost Structure
+### Estrutura Mais Flexível e Custo Menor
 
 Nada de contratos ou taxas mensais. Só pague pelos queries que usa — com um custo-por-query de $40 dólares por milhão de queries (cerca de $0.0004 por query). Estes tem preços em Dólar (USD), pagos em GRT ou cartão de crédito.
 
@@ -52,7 +52,7 @@ Os custos de query podem variar; o custo citado é o normal até o fechamento da
 |       Custo de engenharia       |                $200 por hora               |                              Incluída                             |
 |      Redundância geográfica     | $1.200 em custos totais por node adicional |                              Incluída                             |
 |     Uptime (disponibilidade)    |                    Varia                   |                               99.9%+                              |
-|      Custos mensais totais      | <span className="highlight-row" /> $1,650+ |                                $120                               |
+|      Custos mensais totais      | <span className="highlight-row" /> $1.650+ |                                $120                               |
 
 ## Utilizador de Volume Alto (cerca de 30 milhões de queries por mês)
 
@@ -67,7 +67,7 @@ Os custos de query podem variar; o custo citado é o normal até o fechamento da
 |          Infraestutura          |                 Centralizada                |                          Descentralizada                          |
 |      Redundância geográfica     |  $1.200 em custos totais por node adicional |                              Incluída                             |
 |     Uptime (disponibilidade)    |                    Varia                    |                               99.9%+                              |
-|      Custos mensais totais      | <span className="highlight-row" /> $11,000+ |                               $1.200                              |
+|      Custos mensais totais      | <span className="highlight-row" /> $11.000+ |                               $1.200                              |
 
 \*com custos de backup incluídos: $50-$100 por mês
 
@@ -75,18 +75,18 @@ Os custos de query podem variar; o custo citado é o normal até o fechamento da
 
 <sup>‡</sup>Reflete o custo ao consumidor de dados. Taxas de query ainda são pagas a Indexadores por queries do Plano Grátis.
 
-Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+Os custos estimados são apenas para subgraphs na Mainnet do Ethereum — os custos são maiores ao auto-hospedar um graph-node em outras redes. Alguns utilizadores devem atualizar o seu subgraph a uma versão mais recente. Até o fechamento deste texto, devido às taxas de gas do Ethereum, uma atualização custa cerca de 50 dólares. Note que as taxas de gás no [Arbitrum](/archived/arbitrum/arbitrum-faq/) são muito menores que as da mainnet do Ethereum.
 
 Curar um sinal em um subgraph é um custo opcional, único, e zero-líquido (por ex., $1 mil em um subgraph pode ser curado em um subgraph, e depois retirado — com potencial para ganhar retornos no processo).
 
-## No Setup Costs & Greater Operational Efficiency
+## Zero Custos de Preparação e Mais Eficiência Operacional
 
 Zero taxas de setup. Comece imediatamente, sem custos de setup ou gerais. Nenhum requisito de hardware. Zero falhas por infraestruturas centralizadas, e mais tempo para se concentrar no seu produto principal. Não há necessidade de servidores de backup, solução de problemas ou recursos caríssimos de engenharia.
 
-## Reliability & Resiliency
+## Confiabilidade e Resiliência
 
-The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+A rede descentralizada do The Graph permite que os utilizadores acessem redundâncias geográficas que não existem ao auto-hospedar um graph-node. Os queries são servidos de maneira confiável graças ao uptime de mais de 99.9%, alcançado por centenas de Indexadores independentes que protegem a rede globalmente.
 
-Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+Enfim: A Graph Network é mais barata e fácil de usar, e produz resultados melhores comparados à execução local de um graph-node.
 
-Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).
+Comece a usar a Graph Network hoje, e aprenda como [editar o seu subgraph na rede descentralizada do The Graph](/subgraphs/quick-start/).

From 18b2011141311db5fd56e944d7b4eeafda7548b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 04:33:29 -0500
Subject: [PATCH 2665/3820] New translations new-chain-integration.mdx (Chinese
 Simplified)

---
 website/pages/zh/indexing/new-chain-integration.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/indexing/new-chain-integration.mdx b/website/pages/zh/indexing/new-chain-integration.mdx
index c900f4b153df..f2162579560a 100644
--- a/website/pages/zh/indexing/new-chain-integration.mdx
+++ b/website/pages/zh/indexing/new-chain-integration.mdx
@@ -51,11 +51,11 @@ While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is a
 
 > NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
 
-## Graph Node配置
+## Graph节点配置
 
 Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
 
-1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+1. [克隆Graph节点](https://github.com/graphprotocol/graph-node)
 
 2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
 

From 96a2ff500a8751b10d855ab6b75465d429ca13b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 05:44:34 -0500
Subject: [PATCH 2666/3820] New translations new-chain-integration.mdx (Chinese
 Simplified)

---
 website/pages/zh/indexing/new-chain-integration.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/zh/indexing/new-chain-integration.mdx b/website/pages/zh/indexing/new-chain-integration.mdx
index f2162579560a..08629901b7d9 100644
--- a/website/pages/zh/indexing/new-chain-integration.mdx
+++ b/website/pages/zh/indexing/new-chain-integration.mdx
@@ -15,7 +15,7 @@ Chains can bring subgraph support to their ecosystem by starting a new `graph-no
 
 If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
 
-#### 测试EVM JSON-RPC
+#### Testing an EVM JSON-RPC
 
 For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
 
@@ -24,7 +24,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByNumber`
 - `eth_getBlockByHash`
 - `net_version`
-- `eth_getTransactionReceipt`, 在JSON-RPC批量请求中
+- `eth_getTransactionReceipt`, in a JSON-RPC batch request
 - `trace_filter` _(optionally required for Graph Node to support call handlers)_
 
 ### 2. Firehose Integration
@@ -73,8 +73,8 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
 5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
 
-如果没有错误，Graph Node应该正在同步部署的子图。给它一些时间来同步，然后向API端点发送一些GraphQL查询。
+如果没有错误，Graph节点应该正在同步部署的子图。给它一些时间来同步，然后向API端点发送一些GraphQL查询。
 
-## Substreams-powered Subgraphs
+## Substreams驱动的子图
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 68b88b92ed7d369189312f4186c250763239f52a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 05:44:35 -0500
Subject: [PATCH 2667/3820] New translations curating.mdx (German)

---
 website/pages/de/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/resources/roles/curating.mdx b/website/pages/de/resources/roles/curating.mdx
index 8e6416b6d57e..6124386665cf 100644
--- a/website/pages/de/resources/roles/curating.mdx
+++ b/website/pages/de/resources/roles/curating.mdx
@@ -1,5 +1,5 @@
 ---
-title: Curating
+title: Kuratieren
 ---
 
 Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.

From 140e12a7b91507fc6652325382057adde5e3198f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 08:22:38 -0500
Subject: [PATCH 2668/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index 7e19a5ee43d2..c0bbb80bb390 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -83,25 +83,25 @@ Les litiges peuvent être consultés dans l'interface utilisateur sur la page de
 
 ### Que sont les remises sur les frais de requête et quand sont-elles distribuées ?
 
-Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+Les frais de requêtes sont collectés par la passerelle et distribués aux indexeurs selon une fonction de remboursement exponentielle (voir la proposition GIP [ici](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). La fonction de remboursement exponentiel est proposée comme un moyen de garantir que les Indexeurs obtiennent le meilleur résultat en répondant fidèlement aux requêtes. Elle incite les indexeurs à allouer un montant élevé de staking (qui peut être réduit en cas d'erreur lors du service d'une requête) par rapport au montant des frais de requête qu'ils peuvent percevoir.
 
 Une fois qu'une allocation a été clôturée, les remises peuvent être réclamées par l'indexeur. Lors de la réclamation, les remises sur les frais de requête sont distribuées à l'indexeur et à leurs délégués en fonction de la réduction des frais de requête et de la fonction de remise exponentielle.
 
 ### Qu'est-ce que la réduction des frais de requête et la réduction des récompenses d'indexation ?
 
-The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+Les valeurs `queryFeeCut` et `indexingRewardCut` sont des paramètres de délégation que l'Indexeur peut définir avec les cooldownBlocks pour contrôler la distribution des GRT entre l'Indexeur et ses Délégateurs. Voir les dernières étapes de [Staking dans le protocol](/indexing/overview/#stake-in-the-protocol) pour les instructions sur la définition des paramètres de délégation.
 
-- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+- **queryFeeCut** - le pourcentage des remboursements de frais de requête qui sera distribué à l'Indexeur. Si cette valeur est fixée à 95 %, l'Indexeur recevra 95 % des frais de requête perçus lors de la clôture d'une allocation, les 5 % restants revenant aux Délégateurs.
 
-- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+- **indexingRewardCut** - le pourcentage des récompenses d'indexation qui sera distribué à l'Indexeur. Si cette valeur est fixée à 95 %, l'Indexeur recevra 95 % des récompenses d'indexation lorsqu'une allocation sera clôturée et les Délégateurs se partageront les 5 % restants.
 
 ### Comment les indexeurs savent-ils quels subgraphs indexer ?
 
 Les indexeurs peuvent se différencier en appliquant des techniques avancées pour prendre des décisions d'indexation de subgraphs, mais pour donner une idée générale, nous discuterons de plusieurs mesures clés utilisées pour évaluer les subgraphs du réseau :
 
-- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+- **Signal de curation** - La proportion du signal de curation du réseau appliquée à un subgraph particulier est un bon indicateur de l'intérêt porté à ce subgraph, en particulier pendant la phase de démarrage, lorsque le volume des requêtes augmente.
 
-- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+- **Frais de requête perçus** - Les données historiques relatives au volume des frais de requête perçus pour un subgraph spécifique constituent un bon indicateur de la demande future.
 
 - **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
 

From e1756682d1d5c95c88d39fa19b8ab51fd0b655f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 09:22:34 -0500
Subject: [PATCH 2669/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index c0bbb80bb390..b56c437f2f73 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -103,16 +103,16 @@ Les indexeurs peuvent se différencier en appliquant des techniques avancées po
 
 - **Frais de requête perçus** - Les données historiques relatives au volume des frais de requête perçus pour un subgraph spécifique constituent un bon indicateur de la demande future.
 
-- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+- **Montant staké** - Le fait de surveiller le comportement d'autres Indexeurs ou d'examiner les proportions du staking total alloué à des subgraph spécifiques peut permettre à un Indexeur de surveiller l'offre de requêtes de subgraph afin d'identifier les subgraphs dans lesquels le réseau se montre confiant ou les subgraphs pour lesquels un besoin d'offre supplémentaire est susceptible de se faire sentir.
 
-- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+- **Subgraph sans récompenses d'indexation** - Certains subgraphs ne génèrent pas de récompenses d'indexation, principalement parce qu'ils utilisent des fonctionnalités non prises en charge comme IPFS ou parce qu'ils interrogent un autre réseau en dehors du réseau mainnet. Vous verrez un message sur un subgraph s'il ne génère pas de récompenses d'indexation.
 
 ### Quelle est la configuration matérielle requise ?
 
-- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
-- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
-- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
-- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+- **Petit** - Suffisante pour commencer à indexer plusieurs subgraphs, il faudra probablement l'étendre.
+- **Standard** - Configuration par défaut, c'est ce qui est utilisé dans les manifestes de déploiement de l'exemple k8s/terraform.
+- **Moyen** - Indexeur de production prenant en charge 100 subgraphs et 200 à 500 requêtes par seconde.
+- **Grand** - Prêt à indexer tous les subgraphs actuellement utilisés et à répondre aux demandes du trafic correspondant.
 
 | Installation | Postgres<br />(CPUs) | Postgres<br />(mémoire en Gbs) | Postgres<br />(disque en TB) | VMs<br />(CPUs) | VMs<br />(mémoire en Gbs) |
 | ------------ | :------------------: | :----------------------------: | :--------------------------: | :-------------: | :-----------------------: |

From 18f1249018c822af63728ddd475710b7c01ef360 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 09:22:35 -0500
Subject: [PATCH 2670/3820] New translations arweave.mdx (French)

---
 website/pages/fr/subgraphs/cookbook/arweave.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/cookbook/arweave.mdx b/website/pages/fr/subgraphs/cookbook/arweave.mdx
index e803b644d2cf..d5fa74d1bccf 100644
--- a/website/pages/fr/subgraphs/cookbook/arweave.mdx
+++ b/website/pages/fr/subgraphs/cookbook/arweave.mdx
@@ -15,7 +15,7 @@ Arweave a déjà construit de nombreuses bibliothèques pour intégrer le protoc
 - [Arwiki](https://arwiki.wiki/#/en/main)
 - [Arweave Resources](https://www.arweave.org/build)
 
-## À quoi servent les subgraphes d'Arweave ?
+## À quoi servent les subgraphs d'Arweave ?
 
 The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
 

From 53e7330e42403a64ba1f6f0984a6513cf817ca02 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 11:40:47 -0500
Subject: [PATCH 2671/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index b56c437f2f73..779518c21967 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -123,9 +123,9 @@ Les indexeurs peuvent se différencier en appliquant des techniques avancées po
 
 ### Quelles sont les précautions de sécurité de base qu’un indexeur doit prendre ?
 
-- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+- **Portefeuille de l'opérateur** - La mise en place d'un portefeuille de l'opérateur est une précaution importante car elle permet à un Indexeur de maintenir une séparation entre les clés qui contrôlent le staking et celles qui contrôlent les opérations quotidiennes. Voir [Staking dans le Protocol](/indexing/overview/#stake-in-the-protocol) pour les instructions.
 
-- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+- **Pare-feu** - Seul le service Indexer doit être exposé publiquement et une attention particulière doit être portée au verrouillage des ports d'administration et de l'accès à la base de données : l'endpoint JSON-RPC de Graph Node (port par défaut : 8030), l'endpoint de l'API de gestion de l'Indexer (port par défaut : 18000), et l'endpoint de la base de données Postgres (port par défaut : 5432) ne doivent pas être exposés.
 
 ## Infrastructure
 

From a489eb636386613e2897c5e45cd10eda235cc993 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 11:40:49 -0500
Subject: [PATCH 2672/3820] New translations api.mdx (French)

---
 .../developing/creating/graph-ts/api.mdx      | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx
index 125a4eb976b2..d25de3e931a5 100644
--- a/website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx
@@ -2,7 +2,7 @@
 title: API AssemblyScript
 ---
 
-> Note: If you created a subgraph prior to `graph-cli`/`graph-ts` version `0.22.0`, then you're using an older version of AssemblyScript. It is recommended to review the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/).
+> Note : Si vous avez créé un subgraph avant la version `graph-cli`/`graph-ts` `0.22.0`, alors vous utilisez une ancienne version d'AssemblyScript. Il est recommandé de consulter le [`Guide de Migration`](/resources/release-notes/assemblyscript-migration-guide/).
 
 Découvrez quelles APIs intégrées peuvent être utilisées lors de l'écriture des mappages de subgraph. Il existe deux types d'APIs disponibles par défaut :
 
@@ -29,16 +29,16 @@ La bibliothèque `@graphprotocol/graph-ts` fournit les API suivantes :
 
 La `apiVersion` dans le manifeste du subgraph spécifie la version de l'API de mappage exécutée par Graph Node pour un subgraph donné.
 
-| Version | Notes de version                                                                                                                                                                                                                                         |
-| :-----: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-|  0.0.9  | Ajout de nouvelles fonctions hôtes [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                  |
-|  0.0.8  | Ajout de la validation pour l'existence des champs dans le schéma lors de l'enregistrement d'une entité.                                                                                                                                                 |
-|  0.0.7  | Ajout des classes `TransactionReceipt` et `Log`aux types Ethereum<br />Ajout du champ `receipt` à l'objet Ethereum Event                                                                                                                                 |
-|  0.0.6  | Ajout du champ `nonce` à l'objet Ethereum Transaction<br />Ajout de `baseFeePerGas` à l'objet Ethereum Block                                                                                                                                             |
-|  0.0.5  | AssemblyScript upgraded to version 0.19.10 (this includes breaking changes, please see the [`Migration Guide`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renamed to `ethereum.transaction.gasLimit` |
-|  0.0.4  | Ajout du champ `functionSignature` à l'objet Ethereum SmartContractCall                                                                                                                                                                                  |
-|  0.0.3  | Added `from` field to the Ethereum Call object<br />`ethereum.call.address` renamed to `ethereum.call.to`                                                                                                                                                |
-|  0.0.2  | Ajout du champ `input` à l'objet Ethereum Transaction                                                                                                                                                                                                    |
+| Version | Notes de version                                                                                                                                                                                                                                                                                 |
+| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|  0.0.9  | Ajout de nouvelles fonctions hôtes [`eth_get_balance`](#balance-of-an-address) & [`hasCode`](#check-if-an-address-is-a-contract-or-eoa)                                                                                                                                                          |
+|  0.0.8  | Ajout de la validation pour l'existence des champs dans le schéma lors de l'enregistrement d'une entité.                                                                                                                                                                                         |
+|  0.0.7  | Ajout des classes `TransactionReceipt` et `Log`aux types Ethereum<br />Ajout du champ `receipt` à l'objet Ethereum Event                                                                                                                                                                         |
+|  0.0.6  | Ajout du champ `nonce` à l'objet Ethereum Transaction<br />Ajout de `baseFeePerGas` à l'objet Ethereum Block                                                                                                                                                                                     |
+|  0.0.5  | AssemblyScript a été mis à niveau à niveau vers la version 0.19.10 (cela inclut des changements brusques, veuillez consulter le [`Guide de migration`](/resources/release-notes/assemblyscript-migration-guide/))<br />`ethereum.transaction.gasUsed` renommé en `ethereum.transaction.gasLimit` |
+|  0.0.4  | Ajout du champ `functionSignature` à l'objet Ethereum SmartContractCall                                                                                                                                                                                                                          |
+|  0.0.3  | Ajout du champ `from` à l'objet Ethereum Call<br />`ethereum.call.address` renommé en `ethereum.call.to`                                                                                                                                                                                         |
+|  0.0.2  | Ajout du champ `input` à l'objet Ethereum Transaction                                                                                                                                                                                                                                            |
 
 ### Types intégrés
 
@@ -672,7 +672,7 @@ export function handleSomeEvent(event: SomeEvent): void {
 import { ipfs } from '@graphprotocol/graph-ts'
 ```
 
-Smart contracts occasionally anchor IPFS files onchain. This allows mappings to obtain the IPFS hashes from the contract and read the corresponding files from IPFS. The file data will be returned as `Bytes`, which usually requires further processing, e.g. with the `json` API documented later on this page.
+Les contrats intelligents ancrent parfois des fichiers IPFS onchain. Cela permet aux mappages d'obtenir les hashs IPFS du contrat et de lire les fichiers correspondants depuis IPFS. Les données du fichier seront renvoyées sous forme de `Bytes`, ce qui nécessite généralement un traitement supplémentaire, par exemple avec l'API `json` documentée plus loin sur cette page.
 
 Étant donné un hachage ou un chemin IPFS, la lecture d'un fichier depuis IPFS se fait comme suit :
 

From ebb55c88b6e987e12036f4180fea56fd4e37686f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 11:40:50 -0500
Subject: [PATCH 2673/3820] New translations developer-faq.mdx (French)

---
 website/pages/fr/subgraphs/developing/developer-faq.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/developing/developer-faq.mdx b/website/pages/fr/subgraphs/developing/developer-faq.mdx
index ce99dc6f5cdf..347019ec7532 100644
--- a/website/pages/fr/subgraphs/developing/developer-faq.mdx
+++ b/website/pages/fr/subgraphs/developing/developer-faq.mdx
@@ -129,7 +129,7 @@ Par défaut, les réponses aux requêtes sont limitées à 100 éléments par co
 someCollection(first: 1000, skip: <number>) { ... }
 ```
 
-### 23. If my dapp frontend uses The Graph for querying, do I need to write my API key into the frontend directly? What if we pay query fees for users – will malicious users cause our query fees to be very high?
+### 23. Si mon application décentralisée (dapp) utilise The Graph pour effectuer des requêtes, dois-je écrire ma clé API directement dans le code du frontend ? Et si nous payons les frais de requête pour les utilisateurs – des utilisateurs malveillants pourraient-ils faire augmenter considérablement nos frais de requête ?
 
 Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
 

From 75bb87547f4a24d42a978823d9862211e9420228 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 11:40:51 -0500
Subject: [PATCH 2674/3820] New translations curating.mdx (German)

---
 website/pages/de/resources/roles/curating.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/de/resources/roles/curating.mdx b/website/pages/de/resources/roles/curating.mdx
index 6124386665cf..5cfeae7e7ada 100644
--- a/website/pages/de/resources/roles/curating.mdx
+++ b/website/pages/de/resources/roles/curating.mdx
@@ -2,11 +2,11 @@
 title: Kuratieren
 ---
 
-Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+Kuratoren sind entscheidend für die dezentrale Wirtschaft von The Graph. Sie nutzen ihr Wissen über das web3-Ökosystem, um die Subgraphen zu bewerten und zu signalisieren, die von The Graph Network indiziert werden sollten. Über den Graph Explorer sehen die Kuratoren die Netzwerkdaten, um Signalisierungsentscheidungen zu treffen. Im Gegenzug belohnt The Graph Network Kuratoren, die auf qualitativ hochwertige Subgraphen hinweisen, mit einem Anteil an den Abfragegebühren, die diese Subgraphen generieren. Die Höhe der signalisierten GRT ist eine der wichtigsten Überlegungen für Indexer bei der Entscheidung, welche Subgraphen indiziert werden sollen.
 
-## What Does Signaling Mean for The Graph Network?
+## Was bedeutet Signalisierung für The Graph Network?
 
-Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+Bevor Verbraucher einen Subgraphen abfragen können, muss er indiziert werden. An dieser Stelle kommt die Kuratierung ins Spiel. Damit Indexer erhebliche Abfragegebühren für hochwertige Subgraphen verdienen können, müssen sie wissen, welche Subgraphen indiziert werden sollen. Wenn Kuratoren ein Signal für einen Subgraphen geben, wissen Indexer, dass ein Subgraph gefragt und von ausreichender Qualität ist, so dass er indiziert werden sollte.
 
 Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
 

From bf62f6c55086b389ccd619de02266c8ac32d1b05 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 13:02:43 -0500
Subject: [PATCH 2675/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 46 +++++++++++++-------------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index 779518c21967..1bad37b13970 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -129,25 +129,25 @@ Les indexeurs peuvent se différencier en appliquant des techniques avancées po
 
 ## Infrastructure
 
-At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+Au centre de l'infrastructure d'un Indexeur se trouve Graph Node qui surveille les réseaux indexés, extrait et charge les données en fonction d'une définition de subgraph et les sert en tant qu'[API GraphQL](/about/#how-the-graph-works). Graph Node doit être connecté à un endpoint exposant les données de chaque réseau indexé, à un nœud IPFS pour l'extraction des données, à une base de données PostgreSQL pour son stockage et aux composants de l'Indexeur qui facilitent ses interactions avec le réseau.
 
-- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+- **Base de données PostgreSQL** - La base de données principale de Graph Node, c'est ici que sont stockées les données des subgraphs. Le service d'indexation et l'agent utilisent également la base de données pour stocker les données du canal d'état, les modèles de coûts, les règles d'indexation et les actions d'allocation.
 
-- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+- **Endpoint des données** - Pour les réseaux compatibles avec l'EVM, Graph Node doit être connecté à un endpoint qui expose une API JSON-RPC compatible avec l'EVM. Il peut s'agir d'un seul client ou d'une configuration plus complexe qui répartit la charge entre plusieurs clients. Il est important de savoir que certains subgraphs nécessitent des capacités client particulières, telles que le mode archive et/ou l'API de traçage de la parité.
 
-- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+- **Nœud IPFS (version inférieure à 5)** - Les métadonnées de déploiement de subgraph sont stockées sur le réseau IPFS. Graph Node accède principalement au nœud IPFS pendant le déploiement du subgraph pour récupérer le manifeste du subgraph et tous les fichiers liés. Les indexeurs du réseau n'ont pas besoin d'héberger leur propre nœud IPFS, un nœud IPFS pour le réseau est hébergé à l'adresse https://ipfs.network.thegraph.com.
 
-- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+- **Service d'indexation** - Gère toutes les communications externes requises avec le réseau. Il partage les modèles de coûts et les états d'indexation, transmet les requêtes des passerelles à un Graph Node et gère les paiements des requêtes via des canaux d'état avec la passerelle.
 
-- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Agent Indexeur** - Facilite les interactions des Indexeurs sur la on-chain, notamment l'enregistrement sur le réseau, la gestion des déploiements de subgraph vers leur(s) Graph Node/s, et la gestion des allocations.
 
-- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+- **Serveur de métriques Prometheus** - Les composants Graph Node et Indexer enregistrent leurs métriques sur le serveur de métriques.
 
 Remarque : Pour prendre en charge la mise à l'échelle agile, il est recommandé de séparer les problèmes de requête et d'indexation entre différents ensembles de nœuds : nœuds de requête et nœuds d'index.
 
 ### Aperçu des ports
 
-> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+> **Important** : Attention à ne pas exposer les ports publiquement - les **ports d'administration** doivent être verrouillés. Cela inclut les endpoints JSON-RPC de Graph Node et les endpoints de gestion de l'indexeur détaillés ci-dessous.
 
 #### Nœud de The Graph
 
@@ -224,12 +224,12 @@ gcloud services enable sqladmin.googleapis.com
 - Créez un compte de service.
 
 ```sh
-svc_name=<SERVICE_ACCOUNT_NAME>
+svc_name=<NOM_DU_COMPTE_SERVICE>
 gcloud iam service-accounts create $svc_name \
-  --description="Service account for Terraform" \
+  --description="Compte de service pour Terraform" \
   --display-name="$svc_name"
 gcloud iam service-accounts list
-# Get the email of the service account from the list
+# Obtenir l'e-mail du compte de service à partir de la liste
 svc=$(gcloud iam service-accounts list --format='get(email)'
 --filter="displayName=$svc_name")
 gcloud iam service-accounts keys create .gcloud-credentials.json \
@@ -256,17 +256,17 @@ gcloud services vpc-peerings connect \
 - Créez un fichier de configuration Terraform minimal (mettez à jour si nécessaire).
 
 ```sh
-indexer=<INDEXER_NAME>
+indexer=<NOM_DE _L_INDEXEUR>
 cat > terraform.tfvars <<EOF
 project = "$proj_id"
 indexer = "$indexer"
-database_password = "<database password>"
+database_password = "<mot de passe de la base de données>"
 EOF
 ```
 
 #### Utiliser Terraform pour créer une infrastructure
 
-Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+Avant d'exécuter une commande, lisez [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) et créez un fichier `terraform.tfvars` dans ce répertoire (ou modifiez celui que nous avons créé à l'étape précédente). Pour chaque variable pour laquelle vous souhaitez remplacer la valeur par défaut ou pour laquelle vous devez définir une valeur, saisissez un paramètre dans `terraform.tfvars`.
 
 - Exécutez les commandes suivantes pour créer l'infrastructure.
 
@@ -281,7 +281,7 @@ terraform plan
 terraform apply
 ```
 
-Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+Téléchargez les informations d’identification du nouveau cluster dans `~/.kube/config` et définissez-le comme contexte par défaut.
 
 ```sh
 gcloud container clusters get-credentials $indexer
@@ -291,15 +291,15 @@ kubectl config use-context $(kubectl config get-contexts --output='name'
 
 #### Création des composants Kubernetes pour l'indexeur
 
-- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+- Copiez le répertoire `k8s/overlays` dans un nouveau répertoire `$dir` et ajustez l'entrée `bases` dans `$dir/kustomization.yaml` afin qu'elle pointe vers le répertoire `k8s/base`.
 
-- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+- Lisez tous les fichiers de `$dir` et ajustez les valeurs indiquées dans les commentaires.
 
 Déployer toutes les ressources avec `kubectl apply -k $dir`.
 
 ### Nœud de The Graph
 
-[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+[Graph Node](https://github.com/graphprotocol/graph-node) est une implémentation Rust open source qui utilise la blockchain Ethereum pour mettre à jour de manière déterministe un store de données qui peut être interrogé via l'endpoint GraphQL. Les développeurs utilisent des subgraphs pour définir leur schéma et un ensemble de mappages pour transformer les données provenant de la blockchain. Graph Node gère la synchronisation de l'ensemble de la chaîne, la surveillance des nouveaux blocs et le service via un endpoint GraphQL.
 
 #### Commencer à partir des sources
 
@@ -311,7 +311,7 @@ Déployer toutes les ressources avec `kubectl apply -k $dir`.
 
 - **IPFS**
 
-- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+- **Exigences supplémentaires pour les utilisateurs d'Ubuntu** - Pour faire fonctionner Graph Node sur Ubuntu, quelques paquets supplémentaires peuvent être nécessaires.
 
 ```sh
 sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
@@ -342,7 +342,7 @@ cargo run -p graph-node --release -- \
 
 #### Conditions préalables
 
-- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+- **Nœud Ethereum** - Par défaut, l'installation de docker compose utilisera mainnet : [http://host.docker.internal:8545](http://host.docker.internal:8545) pour se connecter au nœud Ethereum sur votre machine hôte. Vous pouvez remplacer ce nom de réseau et cette url en mettant à jour `docker-compose.yaml`.
 
 #### Installation
 
@@ -353,7 +353,7 @@ git clone https://github.com/graphprotocol/graph-node
 cd graph-node/docker
 ```
 
-2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+2. Pour les utilisateurs linux uniquement - Utilisez l'adresse IP de l'hôte au lieu de `host.docker.internal` dans le `docker-compose.yaml ` en utilisant le script inclus :
 
 ```sh
 ./setup.sh
@@ -369,9 +369,9 @@ docker-compose up
 
 Pour participer avec succès au réseau, il faut une surveillance et une interaction presque constantes. Nous avons donc créé une suite d'applications Typescript pour faciliter la participation au réseau des indexeurs. Il existe trois composants d'indexeur :
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+- **Agent d'indexation** - L'agent surveille le réseau et l'infrastructure de l'Indexeur et gère les déploiements de subgraphs qui sont indexés et alloués onchain, ainsi que la quantité allouée à chacun d'entre eux.
 
-- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+- **Service d'indexation** - Le seul composant qui doit être exposé à l'extérieur, le service transmet les requêtes de subgraphs à Graph Node, gère les canaux d'état pour les paiements de requêtes, partage les informations importantes de prise de décision avec les clients tels que les passerelles.
 
 - **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
 

From 28dc6d638da5ad7e17a9a9b33f14997890a477b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 13:02:45 -0500
Subject: [PATCH 2676/3820] New translations curating.mdx (German)

---
 website/pages/de/resources/roles/curating.mdx | 26 +++++++++----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/website/pages/de/resources/roles/curating.mdx b/website/pages/de/resources/roles/curating.mdx
index 5cfeae7e7ada..6e58078ee266 100644
--- a/website/pages/de/resources/roles/curating.mdx
+++ b/website/pages/de/resources/roles/curating.mdx
@@ -10,41 +10,41 @@ Bevor Verbraucher einen Subgraphen abfragen können, muss er indiziert werden. A
 
 Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
 
-Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+Die Signale der Kuratoren werden als ERC20-Token dargestellt, die Graph Curation Shares (GCS) genannt werden. Diejenigen, die mehr Abfragegebühren verdienen wollen, sollten ihre GRT an Subgraphen signalisieren, von denen sie vorhersagen, dass sie einen starken Gebührenfluss an das Netzwerk generieren werden. Kuratoren können nicht für schlechtes Verhalten bestraft werden, aber es gibt eine Einlagensteuer für Kuratoren, um von schlechten Entscheidungen abzuschrecken, die der Integrität des Netzwerks schaden könnten. Kuratoren werden auch weniger Abfragegebühren verdienen, wenn sie einen Subgraphen von geringer Qualität kuratieren, weil es weniger Abfragen zu bearbeiten gibt oder weniger Indexer, die sie bearbeiten.
 
 The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
 
-When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+Bei der Signalisierung können Kuratoren entscheiden, ob sie für eine bestimmte Version des Subgraphen signalisieren wollen oder ob sie die automatische Migration verwenden wollen. Bei der automatischen Migration werden die Freigaben eines Kurators immer auf die neueste vom Entwickler veröffentlichte Version aktualisiert. Wenn sie sich stattdessen für eine bestimmte Version entscheiden, bleiben die Freigaben immer auf dieser spezifischen Version.
 
 If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
 
-Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+Indexer können Subgraphen für die Indizierung auf der Grundlage von Kurationssignalen finden, die sie im Graph Explorer sehen (siehe Screenshot unten).
 
-![Explorer subgraphs](/img/explorer-subgraphs.png)
+![Explorer-Subgrafen](/img/explorer-subgraphs.png)
 
-## How to Signal
+## Wie man signalisiert
 
 Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
 
-A curator can choose to signal on a specific subgraph version, or they can choose to have their signal automatically migrate to the newest production build of that subgraph. Both are valid strategies and come with their own pros and cons.
+Ein Kurator kann sich dafür entscheiden, ein Signal für eine bestimmte Subgraph-Version abzugeben, oder er kann sein Signal automatisch auf die neueste Produktionsversion dieses Subgraphen migrieren lassen. Beides sind gültige Strategien und haben ihre eigenen Vor- und Nachteile.
 
 Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
 
-Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares.
+Die automatische Migration Ihres Signals zum neuesten Produktions-Build kann sich als nützlich erweisen, um sicherzustellen, dass Sie weiterhin Abfragegebühren anfallen. Jedes Mal, wenn Sie kuratieren, fällt eine Kuratierungssteuer von 1 % an. Außerdem zahlen Sie bei jeder Migration eine Kuratierungssteuer von 0,5 %. Subgraph-Entwickler werden davon abgehalten, häufig neue Versionen zu veröffentlichen - sie müssen eine Kurationssteuer von 0,5 % auf alle automatisch migrierten Kurationsanteile zahlen.
 
 > **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
 
-## Withdrawing your GRT
+## Abhebung Ihrer GRT
 
-Curators have the option to withdraw their signaled GRT at any time.
+Die Kuratoren haben jederzeit die Möglichkeit, ihre signalisierten GRT zurückzuziehen.
 
-Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+Anders als beim Delegieren müssen Sie, wenn Sie sich entscheiden, Ihr signalisiertes GRT abzuheben, keine Abkühlungsphase abwarten und erhalten den gesamten Betrag (abzüglich der 1 % Kurationssteuer).
 
-Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+Sobald ein Kurator sein Signal zurückzieht, können die Indexer den Subgraphen weiter indizieren, auch wenn derzeit kein aktives GRT signalisiert wird.
 
-However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+Es wird jedoch empfohlen, dass Kuratoren ihr signalisiertes GRT bestehen lassen, nicht nur um einen Teil der Abfragegebühren zu erhalten, sondern auch um die Zuverlässigkeit und Betriebszeit des Subgraphen zu gewährleisten.
 
-## Risks
+## Risiken
 
 1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.

From b812df613c240c292cc32daac4e7fcd0653eb0ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 13:02:46 -0500
Subject: [PATCH 2677/3820] New translations publishing-a-subgraph.mdx (German)

---
 .../subgraphs/developing/publishing/publishing-a-subgraph.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx
index bc605e4e3705..a9975ad0f7b1 100644
--- a/website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx
+++ b/website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -77,11 +77,11 @@ Developers can add GRT signal to their subgraphs to incentivize Indexers to quer
 
 The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
 
-When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+Bei der Signalisierung können Kuratoren entscheiden, ob sie für eine bestimmte Version des Subgraphen signalisieren wollen oder ob sie die automatische Migration verwenden wollen. Bei der automatischen Migration werden die Freigaben eines Kurators immer auf die neueste vom Entwickler veröffentlichte Version aktualisiert. Wenn sie sich stattdessen für eine bestimmte Version entscheiden, bleiben die Freigaben immer auf dieser spezifischen Version.
 
 Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
 
-![Explorer subgraphs](/img/explorer-subgraphs.png)
+![Explorer-Subgrafen](/img/explorer-subgraphs.png)
 
 Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
 

From b88c536380b64a97845956599519f7ca479c6713 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 14:13:53 -0500
Subject: [PATCH 2678/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index 1bad37b13970..66c515ff811d 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -373,11 +373,11 @@ Pour participer avec succès au réseau, il faut une surveillance et une interac
 
 - **Service d'indexation** - Le seul composant qui doit être exposé à l'extérieur, le service transmet les requêtes de subgraphs à Graph Node, gère les canaux d'état pour les paiements de requêtes, partage les informations importantes de prise de décision avec les clients tels que les passerelles.
 
-- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+- **CLI de l'Indexeur** - L'interface de ligne de commande pour la gestion de l'agent d'Indexeur. Elle permet aux Indexeurs de gérer les modèles de coûts, les allocations manuelles, la file d'attente des actions et les règles d'indexation.
 
 #### Commencer
 
-The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+L'agent d'Indexeur et le service d'Indexeur doivent être situés au même endroit que votre infrastructure Graph Node. Il existe de nombreuses façons de mettre en place des environnements d'exécution virtuels pour vos composants d'Indexeurs ; nous expliquerons ici comment les exécuter sur baremetal en utilisant les packages NPM ou les sources, ou via kubernetes et docker sur Google Cloud Kubernetes Engine. Si ces exemples de configuration ne s'appliquent pas à votre infrastructure, il y aura probablement un guide communautaire à consulter, venez nous dire bonjour sur [Discord](https://discord.gg/graphprotocol) ! N'oubliez pas de [staker sur le protocole](/indexing/overview/#stake-in-the-protocol) avant de démarrer vos composants d'Indexeur !
 
 #### À partir des packages NPM
 
@@ -434,12 +434,12 @@ docker pull ghcr.io/graphprotocol/indexer-agent:latest
 Ou créez des images localement à partir de la source
 
 ```sh
-# Indexer service
+# service d'Indexeur
 docker build \
   --build-arg NPM_TOKEN=<npm-token> \
   -f Dockerfile.indexer-service \
   -t indexer-service:latest \
-# Indexer agent
+# service d'agent
 docker build \
   --build-arg NPM_TOKEN=<npm-token> \
   -f Dockerfile.indexer-agent \
@@ -457,7 +457,7 @@ docker run -p 18000:8000 -it indexer-agent:latest ...
 
 #### Utilisation de K8s et Terraform
 
-See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+Voir la section [Configuration de l'infrastructure du serveur à l'aide de Terraform sur Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud)
 
 #### Usage
 

From 959a18d49559f8925598c2a03589011866aab182 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 19 Jan 2025 15:14:39 -0500
Subject: [PATCH 2679/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index 66c515ff811d..64929e99fd7a 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -453,7 +453,7 @@ docker run -p 7600:7600 -it indexer-service:latest ...
 docker run -p 18000:8000 -it indexer-agent:latest ...
 ```
 
-**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+**NOTE** : Après le démarrage des conteneurs, le service d'Indexeurs doit être accessible à l'adresse [http://localhost:7600](http://localhost:7600) et l'agent d'Indexeur doit exposer l'API de gestion de l'Indexeur à l'adresse [http://localhost:18000/](http://localhost:18000/).
 
 #### Utilisation de K8s et Terraform
 
@@ -461,7 +461,7 @@ Voir la section [Configuration de l'infrastructure du serveur à l'aide de Terra
 
 #### Usage
 
-> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+> **NOTE** : Toutes les variables de configuration peuvent être appliquées soit en tant que paramètres de la commande au démarrage, soit en utilisant des variables d'environnement du format `COMPONENT_NAME_VARIABLE_NAME` (ex. `INDEXER_AGENT_ETHEREUM`).
 
 #### Indexer agent
 
@@ -520,7 +520,7 @@ graph-indexer-service start \
 
 #### Indexer CLI
 
-The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+Le CLI d'Indexeur est un plugin pour [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible via la commande `graph indexer`.
 
 ```sh
 graph indexer connect http://localhost:18000

From be1b4e9d294a634b786f51fe8c1b2bc2348c7fc9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 11:34:37 -0500
Subject: [PATCH 2680/3820] New translations explorer.mdx (Russian)

---
 website/pages/ru/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/explorer.mdx b/website/pages/ru/subgraphs/explorer.mdx
index cf6588410a77..3f1189b2dcf0 100644
--- a/website/pages/ru/subgraphs/explorer.mdx
+++ b/website/pages/ru/subgraphs/explorer.mdx
@@ -249,7 +249,7 @@ As your official portal into the world of decentralized data, Graph Explorer all
 
 ## Дополнительные ресурсы
 
-### Video Guide
+### Видео руководство
 
 For a general overview of Graph Explorer, check out the video below:
 

From 1e53d80b09b317e23ef6453b77cfa34531ce242d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 11:34:38 -0500
Subject: [PATCH 2681/3820] New translations delegating.mdx (Russian)

---
 .../pages/ru/resources/roles/delegating.mdx   | 120 +++++++++---------
 1 file changed, 59 insertions(+), 61 deletions(-)

diff --git a/website/pages/ru/resources/roles/delegating.mdx b/website/pages/ru/resources/roles/delegating.mdx
index ec31c0cd9420..c987ca0ab621 100644
--- a/website/pages/ru/resources/roles/delegating.mdx
+++ b/website/pages/ru/resources/roles/delegating.mdx
@@ -2,140 +2,138 @@
 title: Делегирование
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+Делегаторы — это участники сети, которые делегируют (то есть "стейкают") GRT одному или нескольким индексаторам.
 
-- They help secure the network without running a Graph Node themselves.
+- Они помогают обеспечивать безопасность сети, не запуская собственную Graph Node.
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+- Они зарабатывают часть комиссий за запросы и вознаграждений индексатора, делегируя им свои средства.
 
-## How does this work?
+## Как это работает?
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+Количество запросов, которые индексатор может обработать, зависит от его собственного стейка, **делегированного стейка** и цены, которую индексатор взимает за каждый запрос. Следовательно, чем больше стейк, выделенный индексатору, тем больше запросов он может обработать.
 
-## Delegator Guide
+## Руководство для Делегаторов
 
-Learn how to be an effective Delegator in The Graph Network.
+Узнайте, как стать эффективным делегатом в The Graph Network.
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Делегаторы делят доходы от протокола со всеми Индексаторами на основе своего делегированного стейка. Следовательно, они должны принимать взвешенные решения при выборе Индексаторов, основываясь на множестве факторов.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+> Пожалуйста, обратите внимание, что это руководство не охватывает такие шаги, как правильная настройка MetaMask. Сообщество Ethereum предоставляет исчерпывающий ресурс по кошелькам по следующей ссылке ([источник](https://ethereum.org/en/wallets/)).
 
-There are three sections in this guide:
+Данное руководство состоит из трех разделов:
 
 - Риски связанные с делегацией в сети The Graph
 - Как расчитать примерный доход
-- A video guide showing the steps to delegate in the Graph Network UI
+- Видео руководство, показывающее шаги для делегирования в пользовательском интерфейсе сети The Graph
 
 ## Риски делегации
 
 Ниже указаны основные риски Делегатора.
 
-### The delegation tax
+### Комиссия за делегирование
 
 Делегаторы не могут быть наказаны за некорректное поведение, но они уплачивают комиссию на делегацию, который должен стимулировать обдуманный выбор Индексатора для делегации.
 
-As a Delegator, it's important to understand the following:
+Делегатору важно понимать следующее:
 
-- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+- За каждое делегирование с Вас будет взиматься плата в размере 0,5%. Это значит, что если Вы делегируете 1000 GRT, Вы автоматически сожжете 5 GRT.
 
-- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+- В целях безопасности Вам следует рассчитать потенциальную прибыль при делегировании Индексатору. Например, Вы можете подсчитать, сколько дней пройдет, прежде чем Вы вернете налог в размере 0,5% за своё делегирование.
 
-### The delegation unbonding period
+### Период разблокировки делегирования
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+Когда делегатор хочет отменить делегирование, его токены подлежат 28-дневному периоду разблокировки. Это означает, что в течение 28 дней он не может передавать свои токены или получать вознаграждения.
 
-### Why is this important?
+### Почему это важно?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+Если Вы выберете Индексатора, которому нельзя доверять или который плохо выполняет свою работу, Вам захочется отозвать делегирование. Это приведёт к тому, что Вы упустите множество возможностей для получения наград, что может быть так же плохо, как сжигание GRT. Поэтому рекомендуется тщательно выбирать Индексатора.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
-  unbonding period._
+  ![Период разблокировки делегирования](/img/Delegation-Unbonding.png) _Обратите внимание на комиссию в 0,5% в интерфейсе делегирования, а также на 28-дневный период разблокировки._
 </div>
 
 ### Выбор надежного Индексатора со справедливым распределением вознаграждений для Делегаторов
 
-In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+Чтобы понять, как выбрать надежного Индексатора, Вам необходимо разобраться в параметрах делегирования.
 
-#### Delegation Parameters
+#### Параметры делегирования
 
-- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
-  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
-  - If it is set to 80%, as a Delegator, you will receive 20%.
+- **Часть вознаграждения за индексацию** — доля вознаграждений, которую индексатор оставляет себе.
+  - Если доля вознаграждения индексатора установлена на 100%, как делегатор, как Делегатор, Вы получите 0 вознаграждений за индексацию.
+  - Если установлено значение 80%, то как Делегатор Вы получите 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
-  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+  ![Часть вознаграждения за индексирование](/img/Indexing-Reward-Cut.png) *Верхний индексатор отдает делегаторам 90% вознаграждений. Средний — 20%. Нижний — около 83%.*
 </div>
 
-- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+- **Часть комиссии за запросы** — это то же самое, что и часть вознаграждения за индексирование, но она применяется к доходам от комиссий за запросы, которые индексатор собирает.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+Как видите, чтобы выбрать правильного Индексатора, необходимо учитывать множество факторов.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Настоятельно рекомендуется посетить [Discord The Graph](https://discord.gg/graphprotocol), чтобы узнать, какие индексаторы имеют лучшую социальную и техническую репутацию, а также какие из них регулярно вознаграждают делегаторов.
+- Многие Индексаторы активно участвуют в Discord и будут рады ответить на Ваши вопросы.
+- Многие из них занимаются индексированием уже несколько месяцев и делают все возможное, чтобы помочь Делегаторам получить хорошую прибыль, поскольку это улучшает здоровье и успех сети.
 
-## Calculating Delegators Expected Return
+## Расчет ожидаемой доходности Делегаторов
 
-A Delegator must consider the following factors to determine a return:
+Делегатор должен учитывать следующие факторы для определения доходности:
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+- Учитывайте способность Индексатора использовать доступные ему делегированные токены.
+  - Если Индексатор не распределяет все доступные токены, он не получает максимальной прибыли, которую мог бы получить для себя или своих Делегаторов.
+- Обратите внимание на первые дни делегирования.
+  - Индексатор может закрыть распределение и получить вознаграждение в любой момент между 1 и 28 днями. Вполне возможно, что Индексатору еще предстоит собрать много наград, поэтому общее количество вознаграждений невелико.
 
-### Учёт среза комиссии за запросы и срез вознаграждения за индексацию
+### Учёт части комиссии за запросы и части комиссии за индексирование
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+Вам следует выбрать индексатора, который прозрачен и честен при установке части комиссии за запросы и части комиссии за индексирование. Также стоит обратить внимание на время ожидания параметров (Cooldown time), чтобы понять, сколько времени у вас есть на принятие решения. После этого легко рассчитать сумму вознаграждений, которые вы получаете.
 
-The formula is:
+Формула следующая:
 
-![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+![Изображение делегирования 3](/img/Delegation-Reward-Formula.png)
 
 ### Осмотр пула делегирования индексатора
 
-Delegators should consider the proportion of the Delegation Pool they own.
+Делегаторам следует учитывать долю пула делегаций, которым они владеют.
 
-All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+Все вознаграждения за делегирование распределяются поровну, при этом баланс пула перераспределяется в зависимости от суммы, внесенной Делегатором в пул.
 
-This gives the Delegator a share of the pool:
+Это дает Делегатору долю в пуле:
 
-![Share formula](/img/Share-Forumla.png)
+![Формула доли](/img/Share-Forumla.png)
 
-> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+> Приведенная выше формула показывает, что Индексатор, предлагающий Делегаторам только 20%, может обеспечить лучшее вознаграждение, чем Индексатор, предоставляющий 90%. Просто посчитайте, чтобы определить лучшие условия вознаграждения.
 
 ### Учёт возможности делегирования
 
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
+И, наконец, рассмотрим возможности делегирования. В настоящее время коэффициент делегирования установлен на уровне 16.
 
-#### Why does this matter?
+#### Почему это важно?
 
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+Это означает, что если у Индексатора есть 1,000,000 застейканых GRT, объём его делегирования составляет 16,000,000 GRT делегированных токенов, которые он может использовать в протоколе. Любые делегированные токены сверх этого объёма уменьшат вознаграждения всех Делегаторов.
 
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
+Представьте себе Индексатора, которому делегировано 100,000,000 GRT, а его объём составляет всего 16,000,000 GRT. Это означает, что фактически 84,000,000 GRT токенов не используются для получения токенов. Таким образом, и Делегаторы, и Индексаторы получают меньше вознаграждений, чем могли бы.
 
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+Поэтому Делегатор всегда должен обращать внимание на возможности делегирования Индексатора и учитывать их при принятии решений.
 
 ## Частые вопросы и баги
 
 ### Ошибка Метамаска "Pending Transaction"
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
+1. Когда я пытаюсь делегировать свою транзакцию в MetaMask, она отображается как «В ожидании» или «В очереди» дольше, чем ожидалось. Что мне делать?
 
-At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+Иногда попытки делегировать Индексаторам через MetaMask могут завершаться неудачей, что приводит к длительным периодам транзакций со статусом «В ожидании» или «В очереди».
 
 #### Пример
 
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
+Предположим, вы пытаетесь делегировать с недостаточной комиссией за газ относительно текущих цен.
 
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
+- Это действие может привести к тому, что попытка транзакции будет отображаться как "В ожидании" в вашем кошельке MetaMask в течение более 15 минут. Когда это происходит, вы можете попытаться выполнить последующие транзакции, но они будут обработаны только после того, как будет завершена первоначальная транзакция, поскольку транзакции для одного адреса должны обрабатываться по порядку.
+- В таких случаях эти транзакции можно отменить в MetaMask, но попытки транзакций будут накапливать комиссии за газ без какой-либо гарантии, что последующие попытки будут успешными.
 
-A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+Простым решением этой ошибки является перезапуск браузера (например, с помощью "abort:restart" в адресной строке), что отменит все предыдущие попытки без взимания газа из кошелька. Некоторые пользователи, столкнувшиеся с этой проблемой, сообщили об успешных транзакциях после перезапуска браузера и попытки делегирования.
 
-## Video Guide
+## Видео руководство
 
-This video guide reviews this page while interacting with the UI.
+В этом видеоруководстве рассматривается данная страница при взаимодействии с пользовательским интерфейсом.
 
 <VideoEmbed youtube="2G7S2gdURdc" />

From 16dd7bfed8db902a451172dc9a044b4d2c76f85e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 13:10:44 -0500
Subject: [PATCH 2682/3820] New translations firehose.mdx (Russian)

---
 website/pages/ru/indexing/tooling/firehose.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/indexing/tooling/firehose.mdx b/website/pages/ru/indexing/tooling/firehose.mdx
index 1986d99aa807..c99908796f86 100644
--- a/website/pages/ru/indexing/tooling/firehose.mdx
+++ b/website/pages/ru/indexing/tooling/firehose.mdx
@@ -4,7 +4,7 @@ title: Firehose
 
 ![Firehose Logo](/img/firehose-logo.png)
 
-Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+Firehose — это новая технология, разработанная StreamingFast в сотрудничестве с The Graph Foundation. Продукт предоставляет **ранее невиданные возможности и скорости для индексации данных блокчейна** с использованием подхода на основе файлов и потоковой передачи.
 
 The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
 

From 6d7759296135152a6e85f08ff89214420794699c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 13:10:45 -0500
Subject: [PATCH 2683/3820] New translations quick-start.mdx (Russian)

---
 website/pages/ru/subgraphs/quick-start.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ru/subgraphs/quick-start.mdx b/website/pages/ru/subgraphs/quick-start.mdx
index e029315a3adf..858d68603f44 100644
--- a/website/pages/ru/subgraphs/quick-start.mdx
+++ b/website/pages/ru/subgraphs/quick-start.mdx
@@ -137,7 +137,7 @@ When your subgraph is ready for a production environment, you can publish it to
 
 Выберите сеть, в которую хотите опубликовать свой субграф.
 
-#### Publishing from the CLI
+#### Публикация с помощью CLI
 
 Начиная с версии 0.73.0, Вы также можете публиковать свой субграф с помощью Graph CLI.
 
@@ -157,13 +157,13 @@ graph publish
 ```
 ````
 
-3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+3. Откроется окно, где Вы сможете подключить свой кошелек, добавить метаданные и развернуть финализированный субграф в выбранной Вами сети.
 
 ![cli-ui](/img/cli-ui.png)
 
 To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
 
-#### Adding signal to your subgraph
+#### Добавление сигнала к Вашему субграфу
 
 1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
 

From 512ad36ad061bf4d0a3b107aa18a1625b44ead6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 13:10:46 -0500
Subject: [PATCH 2684/3820] New translations graphql-api.mdx (Russian)

---
 website/pages/ru/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/querying/graphql-api.mdx b/website/pages/ru/subgraphs/querying/graphql-api.mdx
index a47052ee06bb..e66e95936fa8 100644
--- a/website/pages/ru/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/ru/subgraphs/querying/graphql-api.mdx
@@ -4,7 +4,7 @@ title: API GraphQL
 
 Learn about the GraphQL Query API used in The Graph.
 
-## What is GraphQL?
+## Что такое GraphQL?
 
 [GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
 

From 2312e6bf43610cfdb0144022e03ffecafba0ebd1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 13:10:47 -0500
Subject: [PATCH 2685/3820] New translations curating.mdx (Russian)

---
 website/pages/ru/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/resources/roles/curating.mdx b/website/pages/ru/resources/roles/curating.mdx
index 85c4540d96e3..efb7d64887c0 100644
--- a/website/pages/ru/resources/roles/curating.mdx
+++ b/website/pages/ru/resources/roles/curating.mdx
@@ -14,7 +14,7 @@ Curator signals are represented as ERC20 tokens called Graph Curation Shares (GC
 
 The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
 
-When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+При подаче сигнала Кураторы могут решить подать сигнал на определенную версию субграфа или использовать автомиграцию. Если они подают сигнал с помощью автомиграции, доли куратора всегда будут обновляться до последней версии, опубликованной разработчиком. Если же они решат подать сигнал на определенную версию, доли всегда будут оставаться на этой конкретной версии.
 
 If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
 

From 2a3639a75410a352264e7f94e2a319cf03a3b776 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 13:10:48 -0500
Subject: [PATCH 2686/3820] New translations introduction.mdx (Russian)

---
 .../ru/subgraphs/developing/introduction.mdx   | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/ru/subgraphs/developing/introduction.mdx b/website/pages/ru/subgraphs/developing/introduction.mdx
index 0171f49bfb8b..d311d77494a8 100644
--- a/website/pages/ru/subgraphs/developing/introduction.mdx
+++ b/website/pages/ru/subgraphs/developing/introduction.mdx
@@ -6,25 +6,25 @@ To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start
 
 ## Обзор
 
-As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
+Как разработчику, Вам нужны данные для создания и поддержки Вашего децентрализованного приложения. Запрос и индексация данных блокчейна — сложная задача, но The Graph предлагает решение этой проблемы.
 
-On The Graph, you can:
+На The Graph Вы можете:
 
 1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
-2. Use GraphQL to query existing subgraphs.
+2. Использовать GraphQL для запроса существующих субграфов.
 
-### What is GraphQL?
+### Что такое GraphQL?
 
 - [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
 
-### Developer Actions
+### Действия разработчика
 
 - Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
-- Create custom subgraphs to fulfill specific data needs, allowing improved scalability and flexibility for other developers.
-- Deploy, publish and signal your subgraphs within The Graph Network.
+- Создавайте собственные субграфы для удовлетворения конкретных потребностей в данных, обеспечивая улучшенную масштабируемость и гибкость для других разработчиков.
+- Развертывайте, публикуйте и сигнализируйте о своих субграфах в The Graph Network.
 
-### What are subgraphs?
+### Что такое субграфы?
 
-A subgraph is a custom API built on blockchain data. It extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL.
+Субграф — это пользовательский API, созданный на основе данных блокчейна. Он извлекает данные из блокчейна, обрабатывает их и сохраняет так, чтобы их можно было легко запросить через GraphQL.
 
 Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.

From cd2bb49eabbecbb534be02a0db56ac6812da5a5a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 13:10:49 -0500
Subject: [PATCH 2687/3820] New translations publishing-a-subgraph.mdx
 (Russian)

---
 .../publishing/publishing-a-subgraph.mdx      | 40 +++++++++----------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/website/pages/ru/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/ru/subgraphs/developing/publishing/publishing-a-subgraph.mdx
index e3b0ed81b9f9..7549b0e13684 100644
--- a/website/pages/ru/subgraphs/developing/publishing/publishing-a-subgraph.mdx
+++ b/website/pages/ru/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -4,7 +4,7 @@ title: Публикация подграфа в децентрализованн
 
 Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
 
-When you publish a subgraph to the decentralized network, you make it available for:
+Публикуя субграф в децентрализованной сети, Вы делаете его доступным для:
 
 - [Curators](/resources/roles/curating/) to begin curating it.
 - [Indexers](/indexing/overview/) to begin indexing it.
@@ -13,37 +13,37 @@ When you publish a subgraph to the decentralized network, you make it available
 
 Check out the list of [supported networks](/supported-networks/).
 
-## Publishing from Subgraph Studio
+## Публикация с помощью Subgraph Studio
 
 1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
 2. Click on the **Publish** button
 3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
 
-All published versions of an existing subgraph can:
+Все опубликованные версии существующего субграфа могут:
 
 - Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
 
 - Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
 
-### Updating metadata for a published subgraph
+### Обновление метаданных опубликованного субграфа
 
-- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
-- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
-- It's important to note that this process will not create a new version since your deployment has not changed.
+- После публикации своего субграфа в децентрализованной сети Вы можете в любое время обновить метаданные в Subgraph Studio.
+- После сохранения изменений и публикации обновлений они появятся в Graph Explorer.
+- Важно отметить, что этот процесс не приведет к созданию новой версии, поскольку Ваше развертывание не изменилось.
 
-## Publishing from the CLI
+## Публикация с помощью CLI
 
 As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
 
 1. Откройте `graph-cli`.
 2. Use the following commands: `graph codegen && graph build` then `graph publish`.
-3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+3. Откроется окно, где Вы сможете подключить свой кошелек, добавить метаданные и развернуть финализированный субграф в выбранной Вами сети.
 
 ![cli-ui](/img/cli-ui.png)
 
-### Customizing your deployment
+### Настройка Вашего развертывания
 
-You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+Вы можете загрузить сборку своего субграфа на конкретную ноду IPFS и дополнительно настроить развертывание с помощью следующих флагов:
 
 ```
 USAGE
@@ -61,33 +61,33 @@ FLAGS
 
 ```
 
-## Adding signal to your subgraph
+## Добавление сигнала к Вашему субграфу
 
-Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+Разработчики могут добавлять сигнал GRT в свои субграфы, чтобы стимулировать Индексаторов запрашивать субграф.
 
-- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+- Если субграф имеет право на вознаграждение за индексирование, Индексаторы, предоставившие «доказательство индексирования», получат вознаграждение GRT в зависимости от заявленной суммы GRT.
 
 - You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
 
 - Specific supported networks can be checked [here](/supported-networks/).
 
-> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+> Добавление сигнала в субграф, который не имеет права на получение вознаграждения, не привлечет дополнительных Индексаторов.
 >
-> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+> Если Ваш субграф имеет право на получение вознаграждения, рекомендуется курировать собственный субграф, добавив как минимум 3,000 GRT, чтобы привлечь дополнительных Индексаторов для индексирования Вашего субграфа.
 
 The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
 
-When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+При подаче сигнала Кураторы могут решить подать сигнал на определенную версию субграфа или использовать автомиграцию. Если они подают сигнал с помощью автомиграции, доли куратора всегда будут обновляться до последней версии, опубликованной разработчиком. Если же они решат подать сигнал на определенную версию, доли всегда будут оставаться на этой конкретной версии.
 
-Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+Индексаторы могут находить субграфы для индексирования на основе сигналов курирования, которые они видят в Graph Explorer.
 
 ![Explorer subgraphs](/img/explorer-subgraphs.png)
 
-Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+Subgraph Studio позволяет Вам добавлять сигнал в Ваш субграф, добавляя GRT в пул курирования Вашего субграфа в той же транзакции, в которой он публикуется.
 
 ![Curation Pool](/img/curate-own-subgraph-tx.png)
 
-Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+Кроме того, Вы можете добавить сигнал GRT к опубликованному субграфу из Graph Explorer.
 
 ![Signal from Explorer](/img/signal-from-explorer.png)
 

From 6384e1e0d6666b313cc8671b69858d6add084710 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 13:10:50 -0500
Subject: [PATCH 2688/3820] New translations subgraphs.mdx (Russian)

---
 website/pages/ru/subgraphs/developing/subgraphs.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ru/subgraphs/developing/subgraphs.mdx b/website/pages/ru/subgraphs/developing/subgraphs.mdx
index c998d7b4b13d..62134b0551ae 100644
--- a/website/pages/ru/subgraphs/developing/subgraphs.mdx
+++ b/website/pages/ru/subgraphs/developing/subgraphs.mdx
@@ -1,5 +1,5 @@
 ---
-title: Подграфы
+title: Субграфы
 ---
 
 ## What is a Subgraph?
@@ -28,7 +28,7 @@ To learn more about each subgraph component, check out [creating a subgraph](/de
 
 ## Жизненный цикл подграфа
 
-Here is a general overview of a subgraph’s lifecycle:
+Ниже представлен общий обзор жизненного цикла субграфа:
 
 ![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
 

From aff85a872944570b17603c18a0f93cc6e2f996bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 15:13:21 -0500
Subject: [PATCH 2689/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index 64929e99fd7a..54df069e6f33 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -529,7 +529,7 @@ graph indexer status
 
 #### Gestion de l'indexeur à l'aide de l'indexeur CLI
 
-The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+L'outil suggéré pour interagir avec l'**API de gestion de l'Indexeur** est la **CLI d'Indexeur**, une extension de **Graph CLI**. L'agent d'Indexeur a besoin de l'apport d'un Indexeur pour interagir de manière autonome avec le réseau au nom de l'Indexeur. Les mécanismes permettant de définir le comportement de l'agent Indexeur sont le mode **gestion de l'allocation** et les **règles d'indexation**. En mode automatique, un Indexeur peut utiliser des **règles d'indexation** pour appliquer sa stratégie spécifique de sélection des subgraphs à indexer et à servir des requêtes. Les règles sont gérées via une API GraphQL servie par l'agent et connue sous le nom d'API de gestion de l'Indexeur. En mode manuel, un Indexeur peut créer des actions d'allocation en utilisant la **file d'attente des actions** et les approuver explicitement avant qu'elles ne soient exécutées. En mode supervision, les **règles d'indexation** sont utilisées pour alimenter la **file d'attente des actions** et nécessitent également une approbation explicite avant d'être exécutées.
 
 #### Usage
 

From 83bc6aaedd592ad240106074ae2eb4bd76678b37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 16:33:17 -0500
Subject: [PATCH 2690/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 32 +++++++++++++-------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index 54df069e6f33..e6581ab40d3a 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -533,39 +533,39 @@ L'outil suggéré pour interagir avec l'**API de gestion de l'Indexeur** est la
 
 #### Usage
 
-The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+La **CLI d'Indexeur** se connecte à l'agent d'Indexeur, généralement par le biais d'une redirection de port, de sorte que le CLI n'a pas besoin d'être exécuté sur le même serveur ou cluster. Pour vous aider à démarrer, et pour vous donner un peu de contexte, nous allons décrire brièvement la CLI.
 
-- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+- `graph indexer connect <url>` - Se connecter à l'API de gestion de l'Indexeur. Généralement, la connexion au serveur est ouverte via une redirection de port, afin que la CLI puisse être facilement utilisée à distance. (Exemple : `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
 
-- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Pour obtenir une ou plusieurs règles d'indexation en utilisant `all` comme `<deployment-id>` pour obtenir toutes les règles, ou `global` pour obtenir les valeurs par défaut globales. Un argument supplémentaire `--merged` peut être utilisé pour spécifier que les règles spécifiques au déploiement sont fusionnées avec la règle globale. C'est ainsi qu'elles sont appliquées dans l'agent d'Indexeur.
 
-- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Pour définir une ou plusieurs règles d'indexation.
 
-- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+- `graph indexer rules start [options] <deployment-id>` - Commence à indexer un déploiement de subgraphs s'il est disponible et définit sa `decisionBasis` à `always`, de sorte que l'agent d'Indexeur choisira toujours de l'indexer. Si la règle globale est définie sur always, tous les subgraphs disponibles sur le réseau seront indexés.
 
-- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+- `graph indexer rules stop [options] <deployment-id>` - Arrête l'indexation d'un déploiement et met sa `decisionBasis` à never, de sorte qu'il ignorera ce déploiement lorsqu'il décidera des déploiements à indexer.
 
-- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+- `graph indexer rules maybe [options] <deployment-id>` - Définit la `decisionBasis` pour un déploiement à `rules`, afin que l'agent d'Indexeur utilise les règles d'indexation pour décider d'indexer ou non ce déploiement.
 
-- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+- `graph indexer actions get [options] <action-id>` - Récupère une ou plusieurs actions en utilisant `all` ou laisse `action-id` vide pour obtenir toutes les actions. Un argument supplémentaire `--status` peut être utilisé pour afficher toutes les actions d'un certain statut.
 
-- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Met en file d'attente une action de réallocation
 
-- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Met en file d'attente une action de désallocation
 
-- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Met en file d'attente une action de désallocation
 
-- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+- `graph indexer actions cancel [<action-id> ...]` - Annule toutes les actions de la file d'attente si id n'est pas spécifié, sinon annule un tableau d'id avec l'espace comme séparateur
 
-- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+- `graph indexer actions approve [<action-id> ...]` - Approuve l'exécution de plusieurs actions
 
-- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+- `graph indexer actions execute approve` - Force le worker à exécuter immédiatement les actions approuvées
 
-All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+Toutes les commandes qui affichent des règles dans la sortie peuvent choisir entre les formats de sortie pris en charge(`table`, `yaml`, et `json`) en utilisant l'argument `-output`.
 
 #### Règles d'indexation
 
-Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+Les règles d'indexation peuvent être appliquées par défaut au niveau global ou pour des déploiements de subgraphs spécifiques en utilisant leurs identifiants. Les champs `deployment` et `decisionBasis` sont obligatoires, tandis que tous les autres champs sont optionnels. Lorsqu'une règle d'indexation a `rules` comme `decisionBasis`, l'agent d'Indexeur compare les valeurs de seuil non nulles de cette règle avec les valeurs extraites du réseau pour le déploiement correspondant. Si le déploiement du subgraph a des valeurs supérieures (ou inférieures) à l'un des seuils, il sera choisi pour l'indexation.
 
 For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
 

From 9396fdab56ea3be6f678b3121428c1ca0409bdfe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 18:57:04 -0500
Subject: [PATCH 2691/3820] New translations explorer.mdx (Russian)

---
 website/pages/ru/subgraphs/explorer.mdx | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/ru/subgraphs/explorer.mdx b/website/pages/ru/subgraphs/explorer.mdx
index 3f1189b2dcf0..b1882575f782 100644
--- a/website/pages/ru/subgraphs/explorer.mdx
+++ b/website/pages/ru/subgraphs/explorer.mdx
@@ -16,22 +16,22 @@ The following is a breakdown of all the key features of Graph Explorer. For addi
 
 After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
 
-- Your own finished subgraphs
-- Subgraphs published by others
-- The exact subgraph you want (based on the date created, signal amount, or name).
+- Ваши готовые субграфы
+- Субграфы, опубликованные другими
+- Конкретный скбграф, который Вам нужен (в зависимости от даты создания, количества сигналов или имени).
 
 ![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
 
-When you click into a subgraph, you will be able to do the following:
+Нажав на субграф, Вы сможете сделать следующее:
 
-- Test queries in the playground and be able to leverage network details to make informed decisions.
-- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- Протестировать запросы на тестовой площадке и использовать данные сети для принятия обоснованных решений.
+- Подать сигнал GRT на свой собственный субграф или субграфы других, чтобы обратить внимание индексаторов на их значимость и качество.
 
   - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
 
 ![Explorer Image 2](/img/Subgraph-Details.png)
 
-On each subgraph’s dedicated page, you can do the following:
+На специальной странице каждого субграфа Вы можете выполнить следующие действия:
 
 - Сигнал/снятие сигнала на субграфах
 - Просмотр дополнительных сведений, таких как диаграммы, текущий идентификатор развертывания и другие метаданные
@@ -63,15 +63,15 @@ This page provides a bird's-eye view of all "participants," which includes every
 
 ![Explorer Image 4](/img/Indexer-Pane.png)
 
-Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+Индексаторы являются основой протокола. Они стейкают на субграфы, индексируют их и обслуживают запросы всех, кто использует субграфы.
 
-In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+В таблице Индексаторов Вы можете увидеть параметры делегирования Индексаторов, их стейк, сумму стейка, которую они поставили на каждый субграф, а также размер дохода, который они получили от комиссий за запросы и вознаграждений за индексирование.
 
 **Specifics**
 
-- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
-- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
-- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
+- Часть комиссии за запросы — это процент от возвратов комиссии за запросы, который Индексатор оставляет себе при распределении с Делегаторами.
+- Эффективная часть вознаграждения — это доля вознаграждения за индексирование, применяемая к пулу делегирования. Если она отрицательная, это означает, что Индексатор отдаёт часть своих вознаграждений. Если она положительная, это означает, что Индексатор сохраняет часть своих вознаграждений.
+- Оставшееся время восстановления — время, оставшееся до того, как Индексатор сможет изменить вышеуказанные параметры делегирования. Периоды восстановления устанавливаются Индексаторами при обновлении параметров делегирования.
 - Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
 - Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
 - Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.

From 8dd0a1004318ff08d3543840248b22583fd632dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 18:57:05 -0500
Subject: [PATCH 2692/3820] New translations firehose.mdx (Russian)

---
 website/pages/ru/indexing/tooling/firehose.mdx | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/ru/indexing/tooling/firehose.mdx b/website/pages/ru/indexing/tooling/firehose.mdx
index c99908796f86..b8859a10682f 100644
--- a/website/pages/ru/indexing/tooling/firehose.mdx
+++ b/website/pages/ru/indexing/tooling/firehose.mdx
@@ -6,19 +6,19 @@ title: Firehose
 
 Firehose — это новая технология, разработанная StreamingFast в сотрудничестве с The Graph Foundation. Продукт предоставляет **ранее невиданные возможности и скорости для индексации данных блокчейна** с использованием подхода на основе файлов и потоковой передачи.
 
-The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+The Graph объединяется с Go Ethereum/geth с появлением [Live Tracer с версией v1.14.0] (https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
 
-Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+Firehose извлекает, преобразует и сохраняет данные блокчейна с помощью высокопроизводительной файловой стратегии. Разработчики блокчейна могут затем получить доступ к данным, извлеченным Firehose, через потоки двоичных данных. Firehose призван заменить исходный уровень извлечения данных блокчейна The Graph.
 
-## Firehose Documentation
+## Документация Firehose
 
-The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+Документация Firehose в настоящее время поддерживается командой StreamingFast [на веб-сайте StreamingFast[ (https://firehose.streamingfast.io/).
 
 ### Начало работы
 
-- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
-- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+- Прочтите [Введение в Firehose](https://firehose.streamingfast.io/introduction/firehose-overview), чтобы получить общее представление о том, что это такое и почему было создано.
+- Узнайте о [предварительных условиях](https://firehose.streamingfast.io/introduction/prequires) для установки и развертывания Firehose.
 
-### Expand Your Knowledge
+### Расширьте свои знания
 
-- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.
+- Узнайте о различных доступных [компонентах Firehose](https://firehose.streamingfast.io/architecture/components).

From fb78be48537a167218f4c0aee2f90d80500ade59 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 18:57:06 -0500
Subject: [PATCH 2693/3820] New translations tap.mdx (Spanish)

---
 website/pages/es/indexing/tap.mdx | 120 +++++++++++++++++++++++++++++-
 1 file changed, 119 insertions(+), 1 deletion(-)

diff --git a/website/pages/es/indexing/tap.mdx b/website/pages/es/indexing/tap.mdx
index 50cb4c91638a..9d5f769f14f3 100644
--- a/website/pages/es/indexing/tap.mdx
+++ b/website/pages/es/indexing/tap.mdx
@@ -1,5 +1,123 @@
 ---
-title: TAP Migration Guide
+title: |+
+  Guía de Migración TAP
+  Aprende sobre el nuevo sistema de pagos de The Graph, el Protocolo de Agregación de Línea de Tiempo (TAP). Este sistema ofrece microtransacciones rápidas y eficientes con una confianza minimizada.
+
+  Descripción General
+  TAP es un reemplazo directo del sistema de pagos Scalar actualmente en uso. Ofrece las siguientes características clave:
+
+  Manejo eficiente de micropagos.
+  Agrega una capa de consolidación a las transacciones y costos en la cadena.
+  Permite a los Indexadores controlar los recibos y pagos, garantizando el pago por consultas.
+  Facilita puertas de enlace descentralizadas y sin confianza, mejorando el  indexer-service para múltiples remitentes.
+
+  Especificaciones
+  TAP permite que un remitente realice múltiples pagos a un receptor a través de TAP Receipts, los cuales agrupan estos pagos en un único pago denominado Receipt Aggregate Voucher (RAV). Este pago consolidado puede verificarse en la blockchain, reduciendo la cantidad de transacciones y simplificando el proceso de pago.
+
+  Para cada consulta, la puerta de enlace te enviará un recibo firmado (signed receipt) que se almacenará en tu base de datos. Luego, estas consultas serán agrupadas por un tap-agent mediante una solicitud. Posteriormente, recibirás un RAV. Puedes actualizar un RAV enviándolo con recibos más recientes, lo que generará un nuevo RAV con un valor incrementado.
+
+  Detalles del RAV
+  Es dinero que está pendiente de ser enviado a la blockchain.
+  Continuará enviando solicitudes para agrupar recibos y garantizar que el valor total de los recibos no agregados no supere la cantidad dispuesta a perder.
+  Cada RAV puede ser canjeado una sola vez en los contratos, por lo que se envían después de que la asignación se haya cerrado.
+
+  Canjeo de RAV
+  Mientras ejecutes tap-agent e indexer-agent, todo el proceso se ejecutará automáticamente. A continuación, se presenta un desglose detallado del proceso:
+
+  Proceso de Canjeo de RAV
+  1. Un Indexador cierra la asignación.
+  2. Durante el período <recently-closed-allocation-buffer>, tap-agent toma todos los recibos pendientes de esa asignación específica y solicita su agregación en un RAV, marcándolo como el último.
+  3. Indexer-agent toma todos los últimos RAVs y envía solicitudes de canje a la blockchain, lo que actualizará el valor de redeem_at.
+  4. Durante el período <finality-time>, indexer-agent monitorea si la blockchain experimenta alguna reorganización que revierta la transacción.
+  Si la transacción es revertida, el RAV se reenvía a la blockchain. Si no es revertida, se marca como final.
+
+  Blockchain Addresses
+  Contracts
+  Contract	Arbitrum Mainnet (42161)	Arbitrum Sepolia (421614)
+  TAP Verifier	0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a	0xfC24cE7a4428A6B89B52645243662A02BA734ECF
+  AllocationIDTracker	0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c	0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11
+  Escrow	0x8f477709eF277d4A880801D01A140a9CF88bA0d3	0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02
+  Gateway
+  Component	Edge and Node Mainnet (Arbitrum Mainnet)	Edge and Node Testnet (Arbitrum Sepolia)
+  Sender	0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467	0xC3dDf37906724732FfD748057FEBe23379b0710D
+  Signers	0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211	0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE
+  Aggregator	https://tap-aggregator.network.thegraph.com	https://tap-aggregator.testnet.thegraph.com
+
+  Requisitos
+  Además de los requisitos habituales para ejecutar un indexador, necesitarás un endpoint tap-escrow-subgraph para consultar actualizaciones de TAP. Puedes utilizar The Graph Network para hacer consultas o alojarlo en tu propio graph-node.
+
+  Subgrafo Graph TAP Arbitrum Sepolia (para la testnet de The Graph).
+  Subgrafo Graph TAP Arbitrum One (para la mainnet de The Graph).
+
+  Nota: Actualmente, indexer-agent no gestiona la indexación de este subgrafo como lo hace con la implementación del subgrafo de la red. Por lo tanto, debes indexarlo manualmente.
+
+  Guía de Migración
+  Versiones de Software
+  La versión requerida del software se puede encontrar aquí.
+
+  Pasos
+  1. Indexer Agent
+  Sigue el mismo proceso de configuración.
+  Agrega el nuevo argumento --tap-subgraph-endpoint para activar las rutas de código de TAP y habilitar el canje de RAVs de TAP.
+  2. Indexer Service
+  Reemplaza completamente tu configuración actual con la nueva versión de Indexer Service rs. Se recomienda usar la imagen del contenedor.
+  Como en la versión anterior, puedes escalar Indexer Service horizontalmente con facilidad. Sigue siendo stateless.
+  3. TAP Agent
+  Ejecuta una única instancia de TAP Agent en todo momento. Se recomienda usar la imagen del contenedor.
+  4. Configura Indexer Service y TAP Agent mediante un archivo TOML compartido, suministrado con el argumento --config /path/to/config.toml.
+  Consulta la configuración completa y los valores predeterminados.
+  Para una configuración mínima, usa la siguiente plantilla:
+
+  toml
+  Copy
+  Edit
+  [indexer]
+  indexer_address = "0x1111111111111111111111111111111111111111"
+  operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+
+  [database]
+  postgres_url = "postgres://postgres@postgres:5432/postgres"
+
+  [graph_node]
+  query_url = "http://graph-node:8000"
+  status_url = "http://graph-node:8000/graphql"
+
+  [subgraphs.network]
+  query_url = "http://example.com/network-subgraph"
+  deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+  [subgraphs.escrow]
+  query_url = "http://example.com/network-subgraph"
+  deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+
+  [blockchain]
+  chain_id = 1337
+  receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+
+  [tap]
+  max_amount_willing_to_lose_grt = 20
+
+  [tap.sender_aggregator_endpoints]
+  0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+  Notas Importantes
+  Los valores de tap.sender_aggregator_endpoints se encuentran en la sección de gateway.
+  El valor de blockchain.receipts_verifier_address debe coincidir con la sección de direcciones de Blockchain según el chain ID apropiado.
+  Nivel de Registro (Log Level)
+  Puedes establecer el nivel de registro con la variable de entorno RUST_LOG. Se recomienda:
+
+  bash
+  Copy
+  Edit
+  RUST_LOG=indexer_tap_agent=debug,info
+  Monitoreo
+  Métricas
+  Todos los componentes exponen el puerto 7300, que puede ser consultado por Prometheus.
+
+  Grafana Dashboard
+  Puedes descargar el Dashboard de Grafana e importarlo.
+
+  Launchpad
+  Actualmente, hay una versión en desarrollo de indexer-rs y tap-agent, que puedes encontrar aquí.
 ---
 
 Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.

From 4eb6a68ff7a8022c046782a050047c75ac6e1381 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 20 Jan 2025 18:57:08 -0500
Subject: [PATCH 2694/3820] New translations introduction.mdx (Russian)

---
 website/pages/ru/substreams/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/substreams/introduction.mdx b/website/pages/ru/substreams/introduction.mdx
index 4ab50472e4f0..d865b64fe1b1 100644
--- a/website/pages/ru/substreams/introduction.mdx
+++ b/website/pages/ru/substreams/introduction.mdx
@@ -43,7 +43,7 @@ To learn about the latest version of Substreams CLI, which enables developers to
 - In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
 - Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
 
-### Expand Your Knowledge
+### Расширьте свои знания
 
 - Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
 

From 9cca97077f379e5530d3aa6c391f866d7a726bdd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 05:30:52 -0500
Subject: [PATCH 2695/3820] New translations curating.mdx (German)

---
 website/pages/de/resources/roles/curating.mdx | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/de/resources/roles/curating.mdx b/website/pages/de/resources/roles/curating.mdx
index 6e58078ee266..e0f81d940640 100644
--- a/website/pages/de/resources/roles/curating.mdx
+++ b/website/pages/de/resources/roles/curating.mdx
@@ -8,11 +8,11 @@ Kuratoren sind entscheidend für die dezentrale Wirtschaft von The Graph. Sie nu
 
 Bevor Verbraucher einen Subgraphen abfragen können, muss er indiziert werden. An dieser Stelle kommt die Kuratierung ins Spiel. Damit Indexer erhebliche Abfragegebühren für hochwertige Subgraphen verdienen können, müssen sie wissen, welche Subgraphen indiziert werden sollen. Wenn Kuratoren ein Signal für einen Subgraphen geben, wissen Indexer, dass ein Subgraph gefragt und von ausreichender Qualität ist, so dass er indiziert werden sollte.
 
-Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+Kuratoren machen das The Graph Netzwerk effizient und [signaling](#how-to-signal) ist der Prozess, den Kuratoren verwenden, um Indexer wissen zu lassen, dass ein Subgraph gut zu indizieren ist. Indexer können dem Signal eines Kurators vertrauen, da Kuratoren nach dem Signalisieren einen Kurationsanteil für den Subgraphen prägen, der sie zu einem Teil der zukünftigen Abfragegebühren berechtigt, die der Subgraph verursacht.
 
 Die Signale der Kuratoren werden als ERC20-Token dargestellt, die Graph Curation Shares (GCS) genannt werden. Diejenigen, die mehr Abfragegebühren verdienen wollen, sollten ihre GRT an Subgraphen signalisieren, von denen sie vorhersagen, dass sie einen starken Gebührenfluss an das Netzwerk generieren werden. Kuratoren können nicht für schlechtes Verhalten bestraft werden, aber es gibt eine Einlagensteuer für Kuratoren, um von schlechten Entscheidungen abzuschrecken, die der Integrität des Netzwerks schaden könnten. Kuratoren werden auch weniger Abfragegebühren verdienen, wenn sie einen Subgraphen von geringer Qualität kuratieren, weil es weniger Abfragen zu bearbeiten gibt oder weniger Indexer, die sie bearbeiten.
 
-The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+Der [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) stellt die Indizierung aller Subgraphen sicher und signalisiert, dass GRT auf einem bestimmten Subgraphen mehr Indexer anzieht. Dieser Anreiz für zusätzliche Indexer durch Kuration zielt darauf ab, die Servicequalität für Abfragen zu verbessern, indem die Latenzzeit verringert und die Netzwerkverfügbarkeit erhöht wird.
 
 Bei der Signalisierung können Kuratoren entscheiden, ob sie für eine bestimmte Version des Subgraphen signalisieren wollen oder ob sie die automatische Migration verwenden wollen. Bei der automatischen Migration werden die Freigaben eines Kurators immer auf die neueste vom Entwickler veröffentlichte Version aktualisiert. Wenn sie sich stattdessen für eine bestimmte Version entscheiden, bleiben die Freigaben immer auf dieser spezifischen Version.
 
@@ -46,16 +46,16 @@ Es wird jedoch empfohlen, dass Kuratoren ihr signalisiertes GRT bestehen lassen,
 
 ## Risiken
 
-1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
-2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+1. Der Abfragemarkt ist bei The Graph noch sehr jung, und es besteht das Risiko, dass Ihr %APY aufgrund der noch jungen Marktdynamik niedriger ist als Sie erwarten.
+2. Kurationsgebühr - wenn ein Kurator GRT auf einem Subgraphen meldet, fällt eine Kurationsgebühr von 1% an. Diese Gebühr wird verbrannt.
 3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
-4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
-   - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
-   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+4. Ein Subgraph kann aufgrund eines Fehlers fehlschlagen. Für einen fehlgeschlagenen Subgraph fallen keine Abfragegebühren an. Daher müssen Sie warten, bis der Entwickler den Fehler behebt und eine neue Version bereitstellt.
+   - Wenn Sie die neueste Version eines Subgraphen abonniert haben, werden Ihre Anteile automatisch zu dieser neuen Version migriert. Dabei fällt eine Kurationsgebühr von 0,5 % an.
+   - Wenn Sie für eine bestimmte Version eines Subgraphen ein Signal gegeben haben und dieses fehlschlägt, müssen Sie Ihre Kurationsanteile manuell verbrennen. Sie können dann ein Signal für die neue Subgraph-Version geben, wodurch eine Kurationssteuer von 1 % anfällt.
 
-## Curation FAQs
+## FAQs zur Kuration
 
-### 1. What % of query fees do Curators earn?
+### 1. Wie viel Prozent der Abfragegebühren verdienen die Kuratoren?
 
 By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
 

From eaacce77f655a76b0926f503ebf9d6667215e92a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 07:02:18 -0500
Subject: [PATCH 2696/3820] New translations curating.mdx (German)

---
 website/pages/de/resources/roles/curating.mdx | 26 +++++++++----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/website/pages/de/resources/roles/curating.mdx b/website/pages/de/resources/roles/curating.mdx
index e0f81d940640..d6aa6a55acdb 100644
--- a/website/pages/de/resources/roles/curating.mdx
+++ b/website/pages/de/resources/roles/curating.mdx
@@ -57,33 +57,33 @@ Es wird jedoch empfohlen, dass Kuratoren ihr signalisiertes GRT bestehen lassen,
 
 ### 1. Wie viel Prozent der Abfragegebühren verdienen die Kuratoren?
 
-By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+Durch das Signalisieren auf einem Subgraphen erhalten Sie einen Anteil an allen Abfragegebühren, die der Subgraph generiert. 10 % aller Abfragegebühren gehen an die Kuratoren im Verhältnis zu ihren Kurationsanteilen. Diese 10 % unterliegen der Governance.
 
-### 2. How do I decide which subgraphs are high quality to signal on?
+### 2. Wie entscheide ich, welche Subgraphen qualitativ hochwertig sind, um sie zu signalisieren?
 
 Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
 
-- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
-- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+- Kuratoren können ihr Verständnis eines Netzwerks nutzen, um vorherzusagen, wie ein einzelner Subgraph in der Zukunft ein höheres oder niedrigeres Suchvolumen generieren könnte
+- Kuratoren sollten auch die Metriken verstehen, die über den Graph Explorer verfügbar sind. Metriken wie das vergangene Abfragevolumen und die Person des Subgraph-Entwicklers können dabei helfen, festzustellen, ob ein Subgraph eine Meldung wert ist oder nicht.
 
-### 3. What’s the cost of updating a subgraph?
+### 3. Wie hoch sind die Kosten für die Aktualisierung eines Subgraphen?
 
 Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
 
-### 4. How often can I update my subgraph?
+### 4. Wie oft kann ich meinen Subgraphen aktualisieren?
 
-It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+Es wird empfohlen, dass Sie Ihre Subgraphen nicht zu häufig aktualisieren. Sehen Sie die obige Frage für weitere Details.
 
-### 5. Can I sell my curation shares?
+### 5. Kann ich meine Kurationsanteile verkaufen?
 
-Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+Kurationsanteile können nicht „gekauft“ oder „verkauft“ werden wie andere ERC20-Token, mit denen Sie vielleicht vertraut sind. Sie können nur geprägt (erstellt) oder verbrannt (vernichtet) werden.
 
-As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+Als Kurator auf Arbitrum bekommen Sie garantiert die GRT zurück, die Sie ursprünglich eingezahlt haben (abzüglich der Steuer).
 
-### 6. Am I eligible for a curation grant?
+### 6. Bin ich für eine Kuratorenförderung berechtigt?
 
-Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+Zuschüsse für die Kuration werden von Fall zu Fall entschieden. Wenn Sie Unterstützung bei der Kuratierung benötigen, senden Sie bitte eine Anfrage an support@thegraph.zendesk.com.
 
-Still confused? Check out our Curation video guide below:
+Sind Sie immer noch verwirrt? Sehen Sie sich unten unseren Video-Leitfaden zur Kuration an:
 
 <VideoEmbed youtube="VytTEcf0dxQ" />

From 96e69b354dc62242df3cff575d189e90b8b14fa4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 07:02:20 -0500
Subject: [PATCH 2697/3820] New translations using-subgraph-studio.mdx (German)

---
 .../deploying/using-subgraph-studio.mdx       | 70 +++++++++----------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx
index 6bc3ea433d1f..8a6057026a99 100644
--- a/website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx
+++ b/website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -2,88 +2,88 @@
 title: Deploying Using Subgraph Studio
 ---
 
-Erfahren Sie, wie Sie Ihren Subgraph in Subgraph Studio bereitstellen können.
+Learn how to deploy your subgraph to Subgraph Studio.
 
 > Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
 
-## Subgraph Studio Überblick
+## Subgraph Studio Overview
 
-In [Subgraph Studio] (https://thegraph.com/studio/) können Sie Folgendes tun:
+In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
 
-- Eine Liste der von Ihnen erstellten Subgraphs anzeigen
-- Verwalten, Anzeigen von Details und Visualisieren des Status eines bestimmten Subgraphen
-- Erstellen und verwalten Sie Ihre API-Schlüssel für bestimmte Subgraphen
-- Schränken Sie Ihre API-Schlüssel auf bestimmte Domains ein und erlauben Sie nur bestimmten Indexern die Abfrage mit diesen Schlüsseln
-- Erstellen Sie Ihren Subgraph
-- Verteilen Sie Ihren Subgraph mit The Graph CLI
-- Testen Sie Ihren Subgraph in der „Playground“-Umgebung
-- Integrieren Sie Ihren Subgraph in Staging unter Verwendung der Entwicklungsabfrage-URL
-- Veröffentlichen Sie Ihren Subgraph auf The Graph Network
-- Verwalten Sie Ihre Rechnungen
+- View a list of subgraphs you've created
+- Manage, view details, and visualize the status of a specific subgraph
+- Create and manage your API keys for specific subgraphs
+- Restrict your API keys to specific domains and allow only certain Indexers to query with them
+- Create your subgraph
+- Deploy your subgraph using The Graph CLI
+- Test your subgraph in the playground environment
+- Integrate your subgraph in staging using the development query URL
+- Publish your subgraph to The Graph Network
+- Manage your billing
 
-## Installieren der Graph-CLI
+## Install The Graph CLI
 
-Vor der Bereitstellung müssen Sie The Graph CLI installieren.
+Before deploying, you must install The Graph CLI.
 
-Sie müssen [Node.js](https://nodejs.org/) und einen Paketmanager Ihrer Wahl (`npm`, `yarn` oder `pnpm`) installiert haben, um The Graph CLI zu verwenden. Prüfen Sie, ob die [aktuellste](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI-Version installiert ist.
+You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
 
-### Installieren mit yarn
+### Install with yarn
 
 ```bash
 yarn global add @graphprotocol/graph-cli
 ```
 
-### Installieren mit npm
+### Install with npm
 
 ```bash
 npm install -g @graphprotocol/graph-cli
 ```
 
-## Los geht’s
+## Get Started
 
-1. Öffnen Sie [Subgraph Studio] (https://thegraph.com/studio/).
-2. Verbinden Sie Ihre Wallet, um sich anzumelden.
-   - Sie können dies über MetaMask, Coinbase Wallet, WalletConnect oder Safe tun.
-3. Nachdem Sie sich angemeldet haben, wird Ihr eindeutiger Verteilungsschlüssel auf der Detailseite Ihres Subgraphen angezeigt.
-   - Mit dem Bereitstellungsschlüssel können Sie Ihre Subgraphs veröffentlichen oder Ihre API-Schlüssel und Abrechnungen verwalten. Er ist einmalig, kann aber neu generiert werden, wenn Sie glauben, dass er kompromittiert wurde.
+1. Open [Subgraph Studio](https://thegraph.com/studio/).
+2. Connect your wallet to sign in.
+   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
+3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
+   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
 
-> Wichtig: Sie benötigen einen API-Schlüssel, um Subgraphs abzufragen
+> Important: You need an API key to query subgraphs
 
-### So erstellen Sie einen Subgraph in Subgraph Studio
+### How to Create a Subgraph in Subgraph Studio
 
 <VideoEmbed youtube="nGIFuC69bSA" />
 
 > For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
 
-### Kompatibilität von Subgraphs mit dem The Graph Network
+### Subgraph Compatibility with The Graph Network
 
-Um von Indexern auf The Graph Network unterstützt zu werden, müssen Subgraphen:
+In order to be supported by Indexers on The Graph Network, subgraphs must:
 
 - Index a [supported network](/supported-networks/)
-- Sie dürfen keine der folgenden Funktionen verwenden:
+- Must not use any of the following features:
   - ipfs.cat & ipfs.map
   - Non-fatal errors
   - Grafting
 
-## Initialisieren Ihres Subgraphen
+## Initialize Your Subgraph
 
-Sobald Ihr Subgraph in Subgraph Studio erstellt wurde, können Sie seinen Code über die CLI mit diesem Befehl initialisieren:
+Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
 
 ```bash
 graph init <SUBGRAPH_SLUG>
 ```
 
-Sie finden den Wert `<SUBGRAPH_SLUG>` auf der Detailseite Ihres Subgraphs in Subgraph Studio, siehe Abbildung unten:
+You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
 
 ![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
 
-Nachdem Sie `graph init` ausgeführt haben, werden Sie aufgefordert, die Vertragsadresse, das Netzwerk und eine ABI einzugeben, die Sie abfragen möchten. Daraufhin wird ein neuer Ordner auf Ihrem lokalen Rechner erstellt, der einige grundlegende Codes enthält, um mit der Arbeit an Ihrem Subgraph zu beginnen. Anschließend können Sie Ihren Subgraph fertigstellen, um sicherzustellen, dass er wie erwartet funktioniert.
+After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
 
 ## Graph Auth
 
-Bevor Sie Ihren Subgraph in Subgraph Studio bereitstellen können, müssen Sie sich bei Ihrem Konto in der CLI anmelden. Dazu benötigen Sie Ihren Bereitstellungsschlüssel, den Sie auf der Seite mit den Details Ihres Subgraphen finden.
+Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
 
-Verwenden Sie dann den folgenden Befehl, um sich über die CLI zu authentifizieren:
+Then, use the following command to authenticate from the CLI:
 
 ```bash
 graph auth <DEPLOY KEY>

From 6494e87f36f8d9b5de886a5aaaf21f711543bcd1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:11:46 -0500
Subject: [PATCH 2698/3820] New translations unit-testing-framework.mdx
 (German)

---
 .../creating/unit-testing-framework.mdx       | 34 +++++++++----------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx
index f929197ebe84..0bfec04ba128 100644
--- a/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -1,5 +1,5 @@
 ---
-title: Unit Testing Framework
+title: Rahmen für Einheitstests
 ---
 
 Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
@@ -9,7 +9,7 @@ Learn how to use Matchstick, a unit testing framework developed by [LimeChain](h
 - It's written in Rust and optimized for high performance.
 - It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
 
-## Getting Started
+## Erste Schritte
 
 ### Install Dependencies
 
@@ -49,7 +49,7 @@ sudo apt install postgresql
 
 ### Using WSL (Windows Subsystem for Linux)
 
-You can use Matchstick on WSL both using the Docker approach and the binary approach. As WSL can be a bit tricky, here's a few tips in case you encounter issues like
+Sie können Matchstick auf WSL sowohl mit dem Docker-Ansatz als auch mit dem binären Ansatz verwenden. Da WSL ein wenig knifflig sein kann, hier ein paar Tipps, falls Sie auf Probleme stoßen wie
 
 ```
 static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
@@ -89,21 +89,21 @@ And finally, do not use `graph test` (which uses your global installation of gra
 
 To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
 
-### CLI options
+### CLI-Optionen
 
-This will run all tests in the test folder:
+Dadurch werden alle Tests im Testordner ausgeführt:
 
 ```sh
 graph test
 ```
 
-This will run a test named gravity.test.ts and/or all test inside of a folder named gravity:
+Dies führt einen Test namens gravity.test.ts und/oder alle Tests in einem Ordner namens gravity aus:
 
 ```sh
 graph test gravity
 ```
 
-This will run only that specific test file:
+Dadurch wird nur diese spezielle Testdatei ausgeführt:
 
 ```sh
 graph test path/to/file.test.ts
@@ -135,7 +135,7 @@ From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick`
 
 In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
 
-### Configuration
+### Konfiguration
 
 Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
 
@@ -145,15 +145,15 @@ libsFolder: path/to/libs
 manifestPath: path/to/subgraph.yaml
 ```
 
-### Demo subgraph
+### Demo-Subgraph
 
 You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
 
-### Video tutorials
+### Video-Tutorials
 
 Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
 
-## Tests structure
+## Struktur der Tests
 
 _**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
 
@@ -234,7 +234,7 @@ test("handleNewGravatar() should create a new entity", () => {
 
 Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
 
-Examples:
+Beispiele:
 
 Code inside `beforeAll` will execute once before _all_ tests in the file.
 
@@ -418,7 +418,7 @@ describe('handleUpdatedGravatars', () => {
 
 Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
 
-Examples:
+Beispiele:
 
 Code inside `afterEach` will execute after every test.
 
@@ -921,7 +921,7 @@ test(
 
 If the test is marked with shouldFail = true but DOES NOT fail, that will show up as an error in the logs and the test block will fail. Also, if it's marked with shouldFail = false (the default state), the test executor will crash.
 
-### Logging
+### Protokollierung
 
 Having custom logs in the unit tests is exactly the same as logging in the mappings. The difference is that the log object needs to be imported from matchstick-as rather than graph-ts. Here's a simple example with all non-critical log types:
 
@@ -1293,7 +1293,7 @@ Using **Matchstick**, subgraph developers are able to run a script that will cal
 
 The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
 
-### Prerequisites
+### Vorbedingungen
 
 To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
 
@@ -1311,7 +1311,7 @@ In order for that function to be visible (for it to be included in the `wat` fil
 export { handleNewGravatar }
 ```
 
-### Usage
+### Verwendung
 
 Once that's all set up, to run the test coverage tool, simply run:
 
@@ -1393,7 +1393,7 @@ This means you have used `console.log` in your code, which is not supported by A
 
 The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
 
-## Additional Resources
+## Zusätzliche Ressourcen
 
 For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
 

From 80f4ac7703790f5482e67d98ba36e86c61125547 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:11:48 -0500
Subject: [PATCH 2699/3820] New translations explorer.mdx (German)

---
 website/pages/de/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/explorer.mdx b/website/pages/de/subgraphs/explorer.mdx
index 94bf8f0c481d..0489b8960c62 100644
--- a/website/pages/de/subgraphs/explorer.mdx
+++ b/website/pages/de/subgraphs/explorer.mdx
@@ -247,7 +247,7 @@ As your official portal into the world of decentralized data, Graph Explorer all
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
 
-## Additional Resources
+## Zusätzliche Ressourcen
 
 ### Video Guide
 

From 634681072898288d64a7f835da4355d4aaae4b6b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:11:49 -0500
Subject: [PATCH 2700/3820] New translations introduction.mdx (German)

---
 website/pages/de/subgraphs/querying/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/querying/introduction.mdx b/website/pages/de/subgraphs/querying/introduction.mdx
index 2d9bd76f182f..2a195dc3da33 100644
--- a/website/pages/de/subgraphs/querying/introduction.mdx
+++ b/website/pages/de/subgraphs/querying/introduction.mdx
@@ -24,7 +24,7 @@ Subgraph Studio users start on a Free Plan, which allows them to make 100,000 qu
 >
 > Note: If you encounter 405 errors with a GET request to the Graph Explorer URL, please switch to a POST request instead.
 
-### Additional Resources
+### Zusätzliche Ressourcen
 
 - Use [GraphQL querying best practices](/subgraphs/querying/best-practices/).
 - To query from an application, click [here](/subgraphs/querying/from-an-application/).

From 474973f86255c893a670bc4a4339dbfda37e0875 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:11:50 -0500
Subject: [PATCH 2701/3820] New translations quick-start.mdx (German)

---
 website/pages/de/subgraphs/quick-start.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/quick-start.mdx b/website/pages/de/subgraphs/quick-start.mdx
index b392bb1149c1..01ed82182519 100644
--- a/website/pages/de/subgraphs/quick-start.mdx
+++ b/website/pages/de/subgraphs/quick-start.mdx
@@ -4,7 +4,7 @@ title: Schnellstart
 
 Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
 
-## Prerequisites
+## Vorbedingungen
 
 - Eine Krypto-Wallet
 - A smart contract address on a [supported network](/supported-networks/)

From 255eae18867ce27c0c2c25a6ff5c9871a4e59e4f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:11:55 -0500
Subject: [PATCH 2702/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
index 93512fa83f89..52f206c295a5 100644
--- a/website/pages/de/indexing/overview.mdx
+++ b/website/pages/de/indexing/overview.mdx
@@ -340,7 +340,7 @@ cargo run -p graph-node --release -- \
 
 #### Erste Schritte mit Docker
 
-#### Prerequisites
+#### Vorbedingungen
 
 - **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
 
@@ -459,7 +459,7 @@ docker run -p 18000:8000 -it indexer-agent:latest ...
 
 See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
 
-#### Usage
+#### Verwendung
 
 > **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
 
@@ -531,7 +531,7 @@ graph indexer status
 
 The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
 
-#### Usage
+#### Verwendung
 
 The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
 

From 1b0dcd48bdbccd19f70367410641609f6693722f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:11:57 -0500
Subject: [PATCH 2703/3820] New translations graph-node.mdx (German)

---
 website/pages/de/indexing/tooling/graph-node.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/indexing/tooling/graph-node.mdx b/website/pages/de/indexing/tooling/graph-node.mdx
index 80b73f102d83..24cae95c9a9b 100644
--- a/website/pages/de/indexing/tooling/graph-node.mdx
+++ b/website/pages/de/indexing/tooling/graph-node.mdx
@@ -227,7 +227,7 @@ Benutzer, die ein skaliertes Indizierungs-Setup mit erweiterter Konfiguration be
 
 Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
 
-#### Logging
+#### Protokollierung
 
 Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
 

From b010c24c63324e0ac8e338df015d86dd060d1b59 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:11:59 -0500
Subject: [PATCH 2704/3820] New translations python.mdx (German)

---
 website/pages/de/subgraphs/querying/python.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/querying/python.mdx b/website/pages/de/subgraphs/querying/python.mdx
index c10d7a0e57ab..3c2789b12a61 100644
--- a/website/pages/de/subgraphs/querying/python.mdx
+++ b/website/pages/de/subgraphs/querying/python.mdx
@@ -6,7 +6,7 @@ Subgrounds is an intuitive Python library for querying subgraphs, built by [Play
 
 Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
 
-## Getting Started
+## Erste Schritte
 
 Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
 

From abea144baa2140c289d78bd9014d44e47ac1886e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:00 -0500
Subject: [PATCH 2705/3820] New translations firehose.mdx (German)

---
 website/pages/de/indexing/tooling/firehose.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/indexing/tooling/firehose.mdx b/website/pages/de/indexing/tooling/firehose.mdx
index 0f0fdebbafd0..381fc0f4c091 100644
--- a/website/pages/de/indexing/tooling/firehose.mdx
+++ b/website/pages/de/indexing/tooling/firehose.mdx
@@ -14,7 +14,7 @@ Firehose extracts, transforms and saves blockchain data in a highly performant f
 
 The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
 
-### Getting Started
+### Erste Schritte
 
 - Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
 - Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.

From cea654ae2f298dc78f67e143d186d954cd7e492f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:01 -0500
Subject: [PATCH 2706/3820] New translations assemblyscript-migration-guide.mdx
 (German)

---
 .../resources/release-notes/assemblyscript-migration-guide.mdx  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
index fb1ad8beb382..20063f593224 100644
--- a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -167,7 +167,7 @@ However this only works in two scenarios:
 - Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
 - Upcasting on class inheritance (subclass → superclass)
 
-Examples:
+Beispiele:
 
 ```typescript
 // primitive casting

From e68a65bf977d77baa8438ca30ee995236475819c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:02 -0500
Subject: [PATCH 2707/3820] New translations enums.mdx (German)

---
 website/pages/de/subgraphs/cookbook/enums.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/cookbook/enums.mdx b/website/pages/de/subgraphs/cookbook/enums.mdx
index 8db81193d949..0b2fe58b4e34 100644
--- a/website/pages/de/subgraphs/cookbook/enums.mdx
+++ b/website/pages/de/subgraphs/cookbook/enums.mdx
@@ -269,6 +269,6 @@ Expected output includes the marketplaces that meet the criteria, each represent
 }
 ```
 
-## Additional Resources
+## Zusätzliche Ressourcen
 
 For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From d1ebed4f792a08d308d6a146ae2c5ae9d587667d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:04 -0500
Subject: [PATCH 2708/3820] New translations grafting-hotfix.mdx (German)

---
 website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx
index a0bd3f4ab1c2..96c0b5369ecb 100644
--- a/website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx
@@ -164,7 +164,7 @@ Grafting is an effective strategy for deploying hotfixes in subgraph development
 
 However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
 
-## Additional Resources
+## Zusätzliche Ressourcen
 
 - **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
 - **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.

From 9f0aebefdc6fcff7e9e315817469fb183ac0c222 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:05 -0500
Subject: [PATCH 2709/3820] New translations grafting.mdx (German)

---
 website/pages/de/subgraphs/cookbook/grafting.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/cookbook/grafting.mdx b/website/pages/de/subgraphs/cookbook/grafting.mdx
index 593ab8880977..ee92710b3059 100644
--- a/website/pages/de/subgraphs/cookbook/grafting.mdx
+++ b/website/pages/de/subgraphs/cookbook/grafting.mdx
@@ -189,7 +189,7 @@ You can see that the `graft-replacement` subgraph is indexing from older `graph-
 
 Congrats! You have successfully grafted a subgraph onto another subgraph.
 
-## Additional Resources
+## Zusätzliche Ressourcen
 
 If you want more experience with grafting, here are a few examples for popular contracts:
 

From e26c3c543ab16ff13e2a8842cae97af6bdf5ae85 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:06 -0500
Subject: [PATCH 2710/3820] New translations secure-api-keys-nextjs.mdx
 (German)

---
 website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index fc7e0ff52eb4..2f3973811197 100644
--- a/website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -22,7 +22,7 @@ In a standard React application, API keys included in the frontend code can be e
 
 ![Client-side rendering](/img/api-key-client-side-rendering.png)
 
-### Prerequisites
+### Vorbedingungen
 
 - An API key from [Subgraph Studio](https://thegraph.com/studio)
 - Basic knowledge of Next.js and React.

From c443f9925b83d17e4b5fdefb743189effdbbda87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:07 -0500
Subject: [PATCH 2711/3820] New translations transfer-to-the-graph.mdx (German)

---
 website/pages/de/subgraphs/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/de/subgraphs/cookbook/transfer-to-the-graph.mdx
index dc39d7be27b7..a97a3c618c03 100644
--- a/website/pages/de/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/de/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -98,7 +98,7 @@ You can create API Keys in Subgraph Studio under the “API Keys” menu at the
 
 Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
 
-### Additional Resources
+### Zusätzliche Ressourcen
 
 - To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
 - To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 9706cc88ca560ffee8a9cb31d7d4ff735bf10831 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:09 -0500
Subject: [PATCH 2712/3820] New translations install-the-cli.mdx (German)

---
 .../pages/de/subgraphs/developing/creating/install-the-cli.mdx  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/de/subgraphs/developing/creating/install-the-cli.mdx
index 174686f9672f..d10486b1d5a0 100644
--- a/website/pages/de/subgraphs/developing/creating/install-the-cli.mdx
+++ b/website/pages/de/subgraphs/developing/creating/install-the-cli.mdx
@@ -8,7 +8,7 @@ title: Install the Graph CLI
 
 The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
 
-## Getting Started
+## Erste Schritte
 
 ### Install the Graph CLI
 

From 095ee743a3491c5e267902c78790637e31acfb2d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:10 -0500
Subject: [PATCH 2713/3820] New translations using-subgraph-studio.mdx (German)

---
 .../deploying/using-subgraph-studio.mdx       | 122 +++++++++---------
 1 file changed, 61 insertions(+), 61 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx
index 8a6057026a99..66ec3422ca0a 100644
--- a/website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx
+++ b/website/pages/de/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -1,137 +1,137 @@
 ---
-title: Deploying Using Subgraph Studio
+title: Bereitstellung mit Subgraph Studio
 ---
 
-Learn how to deploy your subgraph to Subgraph Studio.
+Erfahren Sie, wie Sie Ihren Subgraphen in Subgraph Studio bereitstellen können.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+> Hinweis: Wenn Sie einen Subgraphen bereitstellen, schieben Sie ihn zu Subgraph Studio, wo Sie ihn testen können. Es ist wichtig, daran zu denken, dass Bereitstellen nicht dasselbe ist wie Veröffentlichen. Wenn Sie einen Subgraphen veröffentlichen, dann veröffentlichen Sie ihn onchain.
 
-## Subgraph Studio Overview
+## Subgraph Studio Überblick
 
-In [Subgraph Studio](https://thegraph.com/studio/), you can do the following:
+In [Subgraph Studio] (https://thegraph.com/studio/) können Sie Folgendes tun:
 
-- View a list of subgraphs you've created
-- Manage, view details, and visualize the status of a specific subgraph
-- Create and manage your API keys for specific subgraphs
-- Restrict your API keys to specific domains and allow only certain Indexers to query with them
-- Create your subgraph
-- Deploy your subgraph using The Graph CLI
-- Test your subgraph in the playground environment
-- Integrate your subgraph in staging using the development query URL
-- Publish your subgraph to The Graph Network
-- Manage your billing
+- Eine Liste der von Ihnen erstellten Subgraphen anzeigen
+- Verwalten, Details anzeigen und den Status eines bestimmten Subgraphen visualisieren
+- Ihre API-Schlüssel für bestimmte Subgraphen erstellen und verwalten
+- Ihre API-Schlüssel auf bestimmte Domains einschränken und nur bestimmten Indexern die Abfrage mit diesen Schlüsseln erlauben
+- Ihren Subgraphen erstellen
+- Ihren Subgraphen mit The Graph CLI verteilen
+- Ihren Subgraphen in der „Playground“-Umgebung testen
+- Ihren Subgraphen in Staging unter Verwendung der Entwicklungsabfrage-URL integrieren
+- Ihren Subgraphen auf The Graph Network veröffentlichen
+- Ihre Rechnungen verwalten
 
-## Install The Graph CLI
+## Installieren der The Graph-CLI
 
-Before deploying, you must install The Graph CLI.
+Vor der Bereitstellung müssen Sie The Graph CLI installieren.
 
-You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm`, `yarn` or `pnpm`) installed to use The Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+Sie müssen [Node.js](https://nodejs.org/) und einen Paketmanager Ihrer Wahl (`npm`, `yarn` oder `pnpm`) installiert haben, um The Graph-CLI zu verwenden. Prüfen Sie, ob die [aktuellste](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI-Version installiert ist.
 
-### Install with yarn
+### Installieren mit yarn
 
 ```bash
 yarn global add @graphprotocol/graph-cli
 ```
 
-### Install with npm
+### Installieren mit npm
 
 ```bash
 npm install -g @graphprotocol/graph-cli
 ```
 
-## Get Started
+## Erste Schritte
 
-1. Open [Subgraph Studio](https://thegraph.com/studio/).
-2. Connect your wallet to sign in.
-   - You can do this via MetaMask, Coinbase Wallet, WalletConnect, or Safe.
-3. After you sign in, your unique deploy key will be displayed on your subgraph details page.
-   - The deploy key allows you to publish your subgraphs or manage your API keys and billing. It is unique but can be regenerated if you think it has been compromised.
+1. Öffnen Sie [Subgraph Studio] (https://thegraph.com/studio/).
+2. Verbinden Sie Ihre Wallet, um sich anzumelden.
+   - Sie können dies über MetaMask, Coinbase Wallet, WalletConnect oder Safe tun.
+3. Nachdem Sie sich angemeldet haben, wird Ihr eindeutiger Verteilungsschlüssel auf der Detailseite Ihres Subgraphen angezeigt.
+   - Mit dem Bereitstellungsschlüssel können Sie Ihre Subgraphen veröffentlichen oder Ihre API-Schlüssel und Abrechnungen verwalten. Er ist einmalig, kann aber neu generiert werden, wenn Sie glauben, dass er kompromittiert wurde.
 
-> Important: You need an API key to query subgraphs
+> Wichtig: Sie benötigen einen API-Schlüssel, um Subgraphen abzufragen
 
-### How to Create a Subgraph in Subgraph Studio
+### So erstellen Sie einen Subgraphen in Subgraph Studio
 
 <VideoEmbed youtube="nGIFuC69bSA" />
 
-> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+> Weitere schriftliche Details finden Sie im [Quick Start](/subgraphs/quick-start/).
 
-### Subgraph Compatibility with The Graph Network
+### Kompatibilität von Subgraphen mit dem The Graph Network
 
-In order to be supported by Indexers on The Graph Network, subgraphs must:
+Um von Indexern auf The Graph Network unterstützt zu werden, müssen Subgraphen:
 
-- Index a [supported network](/supported-networks/)
-- Must not use any of the following features:
+- Ein [unterstütztes Netzwerk](/supported-networks/) indizieren
+- Keine der folgenden Funktionen verwenden:
   - ipfs.cat & ipfs.map
   - Non-fatal errors
   - Grafting
 
-## Initialize Your Subgraph
+## Initialisieren Ihres Subgraphen
 
-Once your subgraph has been created in Subgraph Studio, you can initialize its code through the CLI using this command:
+Sobald Ihr Subgraph in Subgraph Studio erstellt wurde, können Sie seinen Code über die CLI mit diesem Befehl initialisieren:
 
 ```bash
 graph init <SUBGRAPH_SLUG>
 ```
 
-You can find the `<SUBGRAPH_SLUG>` value on your subgraph details page in Subgraph Studio, see image below:
+Sie finden den Wert `<SUBGRAPH_SLUG>` auf der Detailseite Ihres Subgraphen in Subgraph Studio, siehe Abbildung unten:
 
 ![Subgraph Studio - Slug](/img/doc-subgraph-slug.png)
 
-After running `graph init`, you will be asked to input the contract address, network, and an ABI that you want to query. This will generate a new folder on your local machine with some basic code to start working on your subgraph. You can then finalize your subgraph to make sure it works as expected.
+Nachdem Sie `graph init` ausgeführt haben, werden Sie aufgefordert, die Vertragsadresse, das Netzwerk und eine ABI einzugeben, die Sie abfragen möchten. Daraufhin wird ein neuer Ordner auf Ihrem lokalen Computer erstellt, der einige grundlegende Code enthält, um mit der Arbeit an Ihrem Subgraphen zu beginnen. Anschließend können Sie Ihren Subgraphen fertigstellen, um sicherzustellen, dass er wie erwartet funktioniert.
 
 ## Graph Auth
 
-Before you can deploy your subgraph to Subgraph Studio, you need to log into your account within the CLI. To do this, you will need your deploy key, which you can find under your subgraph details page.
+Bevor Sie Ihren Subgraphen in Subgraph Studio bereitstellen können, müssen Sie sich bei Ihrem Konto in der CLI anmelden. Dazu benötigen Sie Ihren Bereitstellungsschlüssel, den Sie auf der Seite mit den Details Ihres Subgraphen finden.
 
-Then, use the following command to authenticate from the CLI:
+Verwenden Sie dann den folgenden Befehl, um sich über die CLI zu authentifizieren:
 
 ```bash
 graph auth <DEPLOY KEY>
 ```
 
-## Bereitstellen eines Subgraphs
+## Bereitstellen eines Subgraphen
 
-Once you are ready, you can deploy your subgraph to Subgraph Studio.
+Sobald Sie fertig sind, können Sie Ihren Subgraphen an Subgraph Studio übergeben.
 
-> Deploying a subgraph with the CLI pushes it to the Studio, where you can test it and update the metadata. This action won't publish your subgraph to the decentralized network.
+> Wenn Sie einen Subgraphen über die Befehlszeilenschnittstelle bereitstellen, wird er in das Studio übertragen, wo Sie ihn testen und die Metadaten aktualisieren können. Bei dieser Aktion wird Ihr Subgraph nicht im dezentralen Netzwerk veröffentlicht.
 
-Use the following CLI command to deploy your subgraph:
+Verwenden Sie den folgenden CLI-Befehl, um Ihren Subgraphen bereitzustellen:
 
 ```bash
 graph deploy <SUBGRAPH_SLUG>
 ```
 
-After running this command, the CLI will ask for a version label.
+Nach der Ausführung dieses Befehls wird die CLI nach einer Versionsbezeichnung fragen.
 
-- It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as `v1`, `version1`, or `asdf`.
-- The labels you create will be visible in Graph Explorer and can be used by curators to decide if they want to signal on a specific version or not, so choose them wisely.
+- Es wird dringend empfohlen, [semver](https://semver.org/) für die Versionierung wie `0.0.1` zu verwenden. Es steht Ihnen jedoch frei, eine beliebige Zeichenkette als Version zu verwenden, z. B. `v1`, `version1` oder `asdf`.
+- Die von Ihnen erstellten Labels sind im Graph Explorer sichtbar und können von den Kuratoren verwendet werden, um zu entscheiden, ob sie eine bestimmte Version signalisieren wollen oder nicht, also wählen Sie sie mit Bedacht.
 
-## Testing Your Subgraph
+## Testen Ihres Subgraphen
 
-After deploying, you can test your subgraph (either in Subgraph Studio or in your own app, with the deployment query URL), deploy another version, update the metadata, and publish to [Graph Explorer](https://thegraph.com/explorer) when you are ready.
+Nach der Bereitstellung können Sie Ihren Subgraphen testen (entweder in Subgraph Studio oder in Ihrer eigenen Anwendung, mit der Bereitstellungsabfrage-URL), eine weitere Version bereitstellen, die Metadaten aktualisieren und im [Graph Explorer](https://thegraph.com/explorer) veröffentlichen, wenn Sie bereit sind.
 
-Use Subgraph Studio to check the logs on the dashboard and look for any errors with your subgraph.
+Verwenden Sie Subgraph Studio, um die Protokolle auf dem Dashboard zu überprüfen und nach Fehlern in Ihrem Subgraphen zu suchen.
 
-## Publish Your Subgraph
+## Veröffentlichung Ihres Subgraphen
 
-In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+Um Ihren Subgraphen erfolgreich zu veröffentlichen, lesen Sie [Veröffentlichen eines Subgraphen](/subgraphs/developing/publishing/publishing-a-subgraph/).
 
-## Versioning Your Subgraph with the CLI
+## Versionierung Ihres Subgraphen mit der CLI
 
-If you want to update your subgraph, you can do the following:
+Wenn Sie Ihren Subgraphen aktualisieren möchten, können Sie wie folgt vorgehen:
 
-- You can deploy a new version to Studio using the CLI (it will only be private at this point).
-- Once you're happy with it, you can publish your new deployment to [Graph Explorer](https://thegraph.com/explorer).
-- This action will create a new version of your subgraph that Curators can start signaling on and Indexers can index.
+- Sie können eine neue Version über die Befehlszeilenschnittstelle (CLI) in Studio bereitstellen (zu diesem Zeitpunkt ist sie nur privat).
+- Wenn Sie damit zufrieden sind, können Sie Ihre neue Bereitstellung im [Graph Explorer] (https://thegraph.com/explorer) veröffentlichen.
+- Mit dieser Aktion wird eine neue Version Ihres Subgraphen erstellt, die von Kuratoren mit Signalen versehen und von Indexern indiziert werden kann.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+Sie können auch die Metadaten Ihres Subgraphen aktualisieren, ohne eine neue Version zu veröffentlichen. Sie können Ihre Subgraph-Details in Studio (unter dem Profilbild, dem Namen, der Beschreibung usw.) aktualisieren, indem Sie eine Option namens **Details aktualisieren** im [Graph Explorer] (https://thegraph.com/explorer) aktivieren. Wenn diese Option aktiviert ist, wird eine Onchain-Transaktion generiert, die die Subgraph-Details im Explorer aktualisiert, ohne dass eine neue Version mit einer neuen Bereitstellung veröffentlicht werden muss.
 
-> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+> Hinweis: Die Veröffentlichung einer neuen Version eines Subgraphen im Netz ist mit Kosten verbunden. Zusätzlich zu den Transaktionsgebühren müssen Sie auch einen Teil der Kurationssteuer für das Auto-Migrations-Signal finanzieren. Sie können keine neue Version Ihres Subgraphen veröffentlichen, wenn Kuratoren nicht darauf signalisiert haben. Für weitere Informationen, lesen Sie bitte [hier](/resources/roles/curating/).
 
-## Automatic Archiving of Subgraph Versions
+## Automatische Archivierung von Subgraph-Versionen
 
-Whenever you deploy a new subgraph version in Subgraph Studio, the previous version will be archived. Archived versions won't be indexed/synced and therefore cannot be queried. You can unarchive an archived version of your subgraph in Subgraph Studio.
+Immer wenn Sie eine neue Subgraph-Version in Subgraph Studio bereitstellen, wird die vorherige Version archiviert. Archivierte Versionen werden nicht indiziert/synchronisiert und können daher nicht abgefragt werden. Sie können die Archivierung einer archivierten Version Ihres Subgraphen in Subgraph Studio dearchivieren.
 
-> Note: Previous versions of non-published subgraphs deployed to Studio will be automatically archived.
+> Hinweis: Frühere Versionen von nicht veröffentlichten Subgraphen, die in Studio bereitgestellt wurden, werden automatisch archiviert.
 
 ![Subgraph Studio - Unarchive](/img/Unarchive.png)

From 7916b0a5fc2c4df63d4020eb49283e1a97f0b82d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:12 -0500
Subject: [PATCH 2714/3820] New translations introduction.mdx (German)

---
 website/pages/de/substreams/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/substreams/introduction.mdx b/website/pages/de/substreams/introduction.mdx
index 4fd0efb697aa..15cdbe92cea7 100644
--- a/website/pages/de/substreams/introduction.mdx
+++ b/website/pages/de/substreams/introduction.mdx
@@ -38,7 +38,7 @@ The official Substreams documentation is currently maintained by the StreamingFa
 
 To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
 
-### Getting Started
+### Erste Schritte
 
 - In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
 - Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).

From 10e702bcb5e4f34b87f71812a12db7b54d846d86 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:13 -0500
Subject: [PATCH 2715/3820] New translations tutorial.mdx (German)

---
 website/pages/de/substreams/sps/tutorial.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/substreams/sps/tutorial.mdx b/website/pages/de/substreams/sps/tutorial.mdx
index 495298871a22..c5fd5e79823e 100644
--- a/website/pages/de/substreams/sps/tutorial.mdx
+++ b/website/pages/de/substreams/sps/tutorial.mdx
@@ -2,7 +2,7 @@
 title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
 ---
 
-## Prerequisites
+## Vorbedingungen
 
 Before starting, make sure to:
 

From 19f4452d04dab5b7796d12f2590d40bbe7837c38 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 10:12:15 -0500
Subject: [PATCH 2716/3820] New translations billing.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/billing.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/zh/subgraphs/billing.mdx b/website/pages/zh/subgraphs/billing.mdx
index 76a949784a34..3b8ed06032a7 100644
--- a/website/pages/zh/subgraphs/billing.mdx
+++ b/website/pages/zh/subgraphs/billing.mdx
@@ -131,7 +131,7 @@ This will be a step by step guide for purchasing GRT on Binance.
    - [To withdraw](https://www.binance.com/en/blog/ecosystem/how-to-transfer-crypto-from-binance-to-trust-wallet-8305050796630181570) the GRT to your wallet, add your wallet's address to the withdrawal whitelist.
    - Click on the "wallet" button, click withdraw, and select GRT.
    - Enter the amount of GRT you want to send and the whitelisted wallet address you want to send it to.
-   - Click "Continue" and confirm your transaction.
+   - 单击“继续”并确认您的交易。
 
 You can learn more about getting GRT on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
 
@@ -158,9 +158,9 @@ This section will show you how to get Ether (ETH) to pay for transaction fees or
 This will be a step by step guide for purchasing ETH on Coinbase.
 
 1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
-2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+2. 创建账户后，您需要通过KYC（或了解您的客户）流程验证您的身份。这是所有中心化或托管加密交易所的标准程序。
 3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
-4. Select the currency you want to purchase. Select ETH.
+4. 选择要购买的货币。选择ETH。
 5. Select your preferred payment method.
 6. Enter the amount of ETH you want to purchase.
 7. Review your purchase and click "Buy ETH".
@@ -170,7 +170,7 @@ This will be a step by step guide for purchasing ETH on Coinbase.
    - Click on the "Send" button next to the ETH account.
    - Enter the amount of ETH you want to send and the wallet address you want to send it to.
    - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
-   - Click "Continue" and confirm your transaction.
+   - 单击“继续”并确认您的交易。
 
 You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
 
@@ -179,9 +179,9 @@ You can learn more about getting ETH on Coinbase [here](https://help.coinbase.co
 This will be a step by step guide for purchasing ETH on Binance.
 
 1. Go to [Binance](https://www.binance.com/en) and create an account.
-2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+2. 创建账户后，您需要通过KYC（或了解您的客户）流程验证您的身份。这是所有中心化或托管加密交易所的标准程序。
 3. 一旦您完成了身份验证，您可以通过在首页横幅上点击“立即购买”按钮来购买ETH。
-4. Select the currency you want to purchase. Select ETH.
+4. 选择要购买的货币。选择ETH。
 5. Select your preferred payment method.
 6. Enter the amount of ETH you want to purchase.
 7. Review your purchase and click "Buy ETH".
@@ -191,7 +191,7 @@ This will be a step by step guide for purchasing ETH on Binance.
    - 单击“钱包”按钮，单击提取，然后选择ETH。
    - 输入您要发送的ETH金额和您要发送到的白名单钱包地址。
    - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
-   - Click "Continue" and confirm your transaction.
+   - 单击“继续”并确认您的交易。
 
 You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
 

From 41e95304f3041f1978e85fe903f7f642d6610910 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 15:08:21 -0500
Subject: [PATCH 2717/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 78 +++++++++++++-------------
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index e6581ab40d3a..6dfc489f0e9a 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -567,7 +567,7 @@ Toutes les commandes qui affichent des règles dans la sortie peuvent choisir en
 
 Les règles d'indexation peuvent être appliquées par défaut au niveau global ou pour des déploiements de subgraphs spécifiques en utilisant leurs identifiants. Les champs `deployment` et `decisionBasis` sont obligatoires, tandis que tous les autres champs sont optionnels. Lorsqu'une règle d'indexation a `rules` comme `decisionBasis`, l'agent d'Indexeur compare les valeurs de seuil non nulles de cette règle avec les valeurs extraites du réseau pour le déploiement correspondant. Si le déploiement du subgraph a des valeurs supérieures (ou inférieures) à l'un des seuils, il sera choisi pour l'indexation.
 
-For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+Par exemple, si la règle globale a un `minStake` de **5** (GRT), tout déploiement de subgraph qui a plus de 5 (GRT) de staking alloué à lui sera indexé. Les règles de seuil incluent `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, et `minAverageQueryFees`.
 
 Modèle de données:
 
@@ -617,15 +617,15 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 #### CLI de la file des actions
 
-The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+L'indexer-cli fournit un module `actions` pour travailler manuellement avec la file d'attente des actions. Il utilise l'**API Graphql** hébergée par le serveur de gestion de l'Indexeur pour interagir avec la file d'attente des actions.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+L'agent d'exécution des actions ne récupère les éléments de la file d'attente pour les exécuter que s'ils ont un `ActionStatus = approved`. Dans le chemin recommandé, les actions sont ajoutées à la file d'attente avec ActionStatus = queued, elles doivent donc être approuvées pour être exécutées on-chain. Le flux général se présente comme suit :
 
 - Action ajoutée à la file d'attente par l'outil d'optimisation tiers ou l'utilisateur indexeur-cli
-- Indexer can use the `indexer-cli` to view all queued actions
-- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
-- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
-- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- L'Indexeur peut utiliser `indexer-cli` pour visualiser toutes les actions en file d'attente
+- L'Indexeur (ou un autre logiciel) peut approuver ou annuler des actions dans la file d'attente en utilisant l'`indexer-cli`. Les commandes approve et cancel prennent en entrée un tableau d'IDs d'actions.
+- Le worker d'exécution interroge régulièrement la file d'attente pour les actions approuvées. Il récupère les actions `approuvées` de la file d'attente, tente de les exécuter, et met à jour les valeurs dans la base de données en fonction du statut de l'exécution, `succès` ou `échec`.
+- Si une action est réussie, le worker s'assurera qu'il y a une règle d'indexation présente qui indique à l'agent comment gérer l'allocation à l'avenir, ce qui est utile pour prendre des actions manuelles lorsque l'agent est en mode `auto` ou `oversight`.
 - L'indexeur peut surveiller la file d'attente des actions pour consulter un historique de l'exécution des actions et, si nécessaire, réapprouver et mettre à jour les éléments d'action en cas d'échec de leur exécution. La file d'attente des actions fournit un historique de toutes les actions mises en file d'attente et entreprises.
 
 Modèle de données:
@@ -683,13 +683,13 @@ graph indexer actions execute approve
 
 Notez que les types d'actions pris en charge pour la gestion des allocations ont des exigences d'entrée différentes :
 
-- `Allocate` - allocate stake to a specific subgraph deployment
+- `Allocate` - alloue un staking à un déploiement spécifique de subgraph
 
   - paramètres d'action requis :
     - deploymentID
     - amount
 
-- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+- `Unallocate` - ferme l'allocation, libérant le staking pour le réallouer ailleurs
 
   - paramètres d'action requis :
     - ID d'allocation
@@ -698,7 +698,7 @@ Notez que les types d'actions pris en charge pour la gestion des allocations ont
     - poi
     - force (force l'utilisation du POI fourni même s'il ne correspond pas à ce que fournit le nœud graph)
 
-- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+- `Reallocate` - ferme atomiquement l'allocation et ouvre une nouvelle allocation pour le même déploiement de subgraph
 
   - paramètres d'action requis :
     - ID d'allocation
@@ -721,14 +721,14 @@ Une instruction est composée d'un prédicat, qui est utilisé pour faire corres
 Exemple de modèle de coût :
 
 ```
-# This statement captures the skip value,
-# uses a boolean expression in the predicate to match specific queries that use `skip`
-# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
-query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
+# Cette instruction capture la valeur du saut,
+# utilise une expression booléenne dans le prédicat pour faire correspondre les requêtes spécifiques qui utilisent `skip`
+# et une expression de coût pour calculer le coût en fonction de la valeur `skip` et de la valeur globale SYSTEM_LOAD
+query { pairs(skip : $skip) { id } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD ;
 
-# This default will match any GraphQL expression.
-# It uses a Global substituted into the expression to calculate cost
-default => 0.1 * $SYSTEM_LOAD;
+# Cette valeur par défaut correspondra à n'importe quelle expression GraphQL.
+# Il utilise un Global substitué dans l'expression pour calculer le coût
+default => 0.1 * $SYSTEM_LOAD ;
 ```
 
 Exemple de calcul des coûts de requête utilisant le modèle ci-dessus :
@@ -754,41 +754,41 @@ indexer cost set model my_model.agora
 
 Les premières étapes pour participer au réseau en tant qu'Indexeur sont d'approuver le protocole, de staker des fonds et (facultativement) de configurer une adresse opérateur pour les interactions quotidiennes avec le protocole.
 
-> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+> Note : Pour les besoins de ces instructions, Remix sera utilisé pour l'interaction avec le contrat, mais vous pouvez utiliser l'outil de votre choix ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), et [MyCrypto](https://www.mycrypto.com/account) sont quelques autres outils connus).
 
-Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+Une fois qu'un indexeur a staké des GRT dans le protocole, les [composants de l'indexeur](/indexing/overview/#indexer-components) peuvent être démarrés et commencer leurs interactions avec le réseau.
 
 #### Approuver les jetons
 
-1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+1. Ouvrir l'[application Remix](https://remix.ethereum.org/) dans un navigateur
 
-2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+2. Dans l'explorateur de fichiers, créez un fichier nommé **GraphToken.abi** avec le [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
 
-3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+3. Avec `GraphToken.abi` sélectionné et ouvert dans l'éditeur, passez à la section `Deploy and run transactions` dans l'interface Remix.
 
-4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+4. Sous environnement, sélectionnez `Injected Web3` et sous `Account` sélectionnez votre adresse d'Indexeur.
 
-5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+5. Définir l'adresse du contrat GraphToken - Collez l'adresse du contrat GraphToken (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) à côté de `At address` et cliquez sur le bouton `At address` pour l'appliquer.
 
-6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+6. Appeler la fonction `approve(spender, amount)` pour approuver le contrat de Staking. Remplissez `spender` avec l'adresse du contrat de staking (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) et `amount` avec les tokens à staker (en wei).
 
 #### Jetons de mise
 
-1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+1. Ouvrir l'[application Remix](https://remix.ethereum.org/) dans un navigateur
 
-2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+2. Dans l'explorateur de fichiers, créez un fichier nommé **Staking.abi** avec l'ABI de staking.
 
-3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+3. Avec `Staking.abi` sélectionné et ouvert dans l'éditeur, passez à la section `Deploy and run transactions` dans l'interface Remix.
 
-4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+4. Sous environnement, sélectionnez `Injected Web3` et sous `Account` sélectionnez votre adresse d'Indexeur.
 
-5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+5. Définir l'adresse du contrat de staking - Collez l'adresse du contrat de staking (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) à côté de `At Address` et cliquez sur le bouton `At address` pour l'appliquer.
 
-6. Call `stake()` to stake GRT in the protocol.
+6. Appeler `stake()` pour staker des GRT dans le protocole.
 
-7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+7. (Facultatif) Les indexeurs peuvent approuver une autre adresse pour être l'opérateur de leur infrastructure d'indexation afin de séparer les clés qui contrôlent les fonds de celles qui effectuent les actions quotidiennes telles que l'allocation sur les subgraphs et le service des requêtes (payées). Pour définir l'opérateur, il faut appeler `setOperator()` avec l'adresse de l'opérateur.
 
-8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+8. (Facultatif) Afin de contrôler la distribution des récompenses et d'attirer stratégiquement les Déléguateurs, les Indexeurs peuvent mettre à jour leurs paramètres de délégation en mettant à jour leur indexingRewardCut (parts par million), queryFeeCut (parts par million), et cooldownBlocks (nombre de blocs). Pour ce faire, appelez `setDelegationParameters()`. L'exemple suivant définit le queryFeeCut pour distribuer 95% des remises de requêtes à l'indexeur et 5% aux Déléguateurs, définit l'indexingRewardCut pour distribuer 60% des récompenses d'indexation à l'indexeur et 40% aux Déléguateurs, et définit la période `thecooldownBlocks` à 500 blocs.
 
 ```
 setDelegationParameters(950000, 600000, 500)
@@ -796,13 +796,13 @@ setDelegationParameters(950000, 600000, 500)
 
 ### Définition des paramètres de délégation
 
-The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+La fonction `setDelegationParameters()` du [contrat de staking](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) est essentielle pour les Indexeurs, car elle leur permet de définir les paramètres qui définissent leurs interactions avec les Déléguateurs, en influençant le partage des récompenses et la capacité de délégation.
 
 ### Comment définir les paramètres de délégation
 
 Pour définir les paramètres de délégation à l'aide de l'interface Graph Explorer, suivez ces étapes :
 
-1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+1. Naviguez jusqu'à [Graph Explorer](https://thegraph.com/explorer/).
 2. Connectez votre portefeuille. Choisissez multisig (comme Gnosis Safe) puis sélectionnez mainnet. Note : Vous devrez répéter ce processus pour Arbitrum One.
 3. Connectez le portefeuille que vous avez en tant que signataire.
 4. Accédez à la section "Settings" puis sélectionnez "Delegation Parameters". Ces paramètres doivent être configurés afin d’obtenir un taux effectif dans la fourchette souhaitée. Une fois les valeurs saisies dans les champs prévus, l’interface calcule automatiquement ce taux effectif. Ajustez les valeurs selon vos besoins pour atteindre le pourcentage effectif désiré.
@@ -812,10 +812,10 @@ Pour définir les paramètres de délégation à l'aide de l'interface Graph Exp
 
 ### La durée de vie d'une allocation
 
-After being created by an Indexer a healthy allocation goes through two states.
+Après avoir été créée par un Indexeur, une allocation saine passe par deux états.
 
-- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Active** - Une fois qu'une allocation est créée onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)), elle est considérée comme **active**. Une partie de la participation propre et/ou déléguée de l'Indexeur est allouée au déploiement d'un subgraph, ce qui lui permet de réclamer des récompenses d'indexation et de servir des requêtes pour ce déploiement de subgraphs. L'agent de l'indexeur gère la création des allocations sur la base des règles de l'Indexeur.
 
-- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+- **Closed** - Un Indexeur est libre de clôturer une allocation une fois qu'une époque s'est écoulée ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) ou son agent indexeur clôturera automatiquement l'allocation après le **maxAllocationEpochs** (actuellement 28 jours). Lorsqu'une allocation est clôturée avec une preuve d'indexation (POI) valide, les récompenses d'indexation sont distribuées à l'Indexeur et à ses Déléguateurs ([en savoir plus](/indexing/overview/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Il est recommandé aux Indexeurs d'utiliser la fonctionnalité de synchronisation offchain pour synchroniser les déploiements de subgraphs jusqu'à la tête de chaîne avant de créer l'allocation sur la onchain. Cette fonctionnalité est particulièrement utile pour les subgraphs dont la synchronisation peut prendre plus de 28 époques ou qui sont susceptibles d'échouer de manière indéterminée.

From c1373a01a847c940548f0b4698a0fdde8ea824f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 15:08:23 -0500
Subject: [PATCH 2718/3820] New translations tap.mdx (French)

---
 website/pages/fr/indexing/tap.mdx | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/fr/indexing/tap.mdx b/website/pages/fr/indexing/tap.mdx
index fd4c8b214b2f..00e31fb7b931 100644
--- a/website/pages/fr/indexing/tap.mdx
+++ b/website/pages/fr/indexing/tap.mdx
@@ -2,36 +2,36 @@
 title: Guide de migration TAP
 ---
 
-Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+Découvrez le nouveau système de paiement de The Graph, le **Timeline Aggregation Protocol, TAP**. Ce système permet des microtransactions rapides et efficaces avec une confiance minimale.
 
 ## Aperçu
 
-[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) est un remplacement direct du système de paiement Scalar actuellement en place. Il offre les fonctionnalités clés suivantes :
 
-- Efficiently handles micropayments.
-- Adds a layer of consolidations to onchain transactions and costs.
-- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
-- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+- Gère efficacement les micropaiements.
+- Ajoute une couche de consolidations aux transactions et aux coûts onchain.
+- Permet aux Indexeurs de contrôler les recettes et les paiements, garantissant ainsi le paiement des requêtes.
+- Il permet des passerelles décentralisées, sans confiance, et améliore les performances du service d'indexation pour les expéditeurs multiples.
 
 ## Spécificités⁠
 
-TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+Le TAP permet à un expéditeur d'effectuer plusieurs paiements à un destinataire, **TAP Receipts**, qui regroupe ces paiements en un seul paiement, un **Receipt Aggregate Voucher**, également connu sous le nom de **RAV**. Ce paiement regroupé peut ensuite être vérifié sur la blockchain, ce qui réduit le nombre de transactions et simplifie le processus de paiement.
 
-For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+Pour chaque requête, la passerelle vous enverra un `reçu signé` qui sera stocké dans votre base de données. Ensuite, ces requêtes seront agrégées par un `tap-agent` par le biais d'une demande. Vous recevrez ensuite un RAV. Vous pouvez mettre à jour un RAV en l'envoyant avec des reçus plus récents, ce qui générera un nouveau RAV avec une valeur plus élevée.
 
-### RAV Details
+### À propos des RAV
 
-- It’s money that is waiting to be sent to the blockchain.
+- C'est de l'argent qui attend d'être envoyé à la blockchain.
 
-- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+- Il continuera à envoyer des demandes d'agrégation et veillera à ce que la valeur totale des recettes non agrégées ne dépasse pas le « montant que vous êtes prêt à risquer de perdre ».
 
-- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+- Chaque RAV ne peut être racheté qu'une seule fois dans les contrats, c'est pourquoi ils sont envoyés après la clôture de l'allocation.
 
-### Redeeming RAV
+### Rachat de RAV
 
-As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+Tant que vous exécutez `tap-agent` et `indexer-agent`, tout sera exécuté automatiquement. Voici une description détaillée du processus :
 
-1. An Indexer closes allocation.
+1. Un Indexeur clôture l'allocation.
 
 2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
 

From 12be23584ec2b1cc75672fd5b7dc8f5d86365301 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:44:33 -0500
Subject: [PATCH 2719/3820] New translations glossary.mdx (Portuguese)

---
 website/pages/pt/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/pt/resources/glossary.mdx b/website/pages/pt/resources/glossary.mdx
index 1f4454d73975..92b6d4912f0e 100644
--- a/website/pages/pt/resources/glossary.mdx
+++ b/website/pages/pt/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossário
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From c247f7d2e987b0a33881b66ba75f6464cfe3abae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:44:34 -0500
Subject: [PATCH 2720/3820] New translations delegating.mdx (Portuguese)

---
 .../pages/pt/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/pt/resources/roles/delegating.mdx b/website/pages/pt/resources/roles/delegating.mdx
index 3bc11efac570..357a600ee8b0 100644
--- a/website/pages/pt/resources/roles/delegating.mdx
+++ b/website/pages/pt/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegação
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Visão geral
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Aprenda como ser um Delegante eficiente na The Graph Network.
+## How Does Delegation Work?
 
-Os Delegantes dividem as receitas do protocolo junto a todos os Indexadores, com base no stake delegado — portanto, eles devem usar do melhor julgamento para escolher Indexadores.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Este guia não cobre passos como a configuração do MetaMask. A comunidade do Ethereum fornece um recurso compreensivo sobre carteiras [neste link](https://ethereum.org/en/wallets/).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-Há três secções neste guia:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - Os riscos de delegar tokens na Graph Network
 - Como calcular retornos esperados como um Delegante
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Riscos de Delegação
 
 Veja abaixo os riscos principais de ser um Delegante no protocolo.
 
-### The delegation tax
+### The Delegation Tax
 
 Os Delegantes não podem ser punidos por mau comportamento, mas há uma taxa sobre Delegantes, para desencorajar más decisões que possam ferir a integridade da rede.
 
@@ -40,24 +68,28 @@ Como Delegante, é importante entender que:
 
 - Por segurança, calcule o seu retorno potencial quando delegar para um Indexador. Por exemplo, pode-se calcular o número de dias até que tenha recuperado a taxa de 0,5% da sua delegação.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Qual a Importância Disto?
 
-Se escolher um Indexador que não é confiável ou não está a fazer um bom trabalho, a melhor opção é retirar a delegação. Ou seja, perderá muitas oportunidades de recompensa, o que pode ser tão duro quanto queimar GRT — portanto, recomendamos que escolha os seus Indexadores com cuidado.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Unbonding de delegação](/img/Delegation-Unbonding.png) _Perceba a taxa de 0,5% na Interface de Delegação, assim como o período de unbonding de 28 dias._
 </div>
 
-### Como escolher um Indexador de confiança, com um pagamento justo para Delegantes
+#### Parâmetros de Delegação
 
 Para entender como escolher um Indexador confiável, entenda os Parâmetros de Delegação.
 
-#### Parâmetros de Delegação
-
 - **Porção da Recompensa de Indexação** — A porção da recompensa que vai para o Indexador.
   - Se a porção for configurada para 100%, como Delegante, você receberá 0 recompensas de indexação.
   - Se for configurada para 80%, o Delegante receberá 20%.
@@ -68,24 +100,25 @@ Para entender como escolher um Indexador confiável, entenda os Parâmetros de D
 
 - **Porção da Taxa de Query** — Parecido com a Porção da Recompensa de Indexação, mas se aplica aos retornos nas taxas de query coletadas pelo Indexador.
 
-Para escolher o Indexador certo, considere:
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- Recomendamos altamente que explore o [Discord do The Graph](https://discord.gg/graphprotocol) para determinar quais Indexadores tem as melhores reputações sociais e técnicas, e quais recompensam os Delegantes consistentemente.
-- Muitos Indexadores estão ativos no Discord, e estão dispostos a responder as suas perguntas.
-- Muitos deles já indexam há meses, e fazem o melhor para ajudar os Delegantes a ganharem um bom retorno, já que isto melhora a saúde e o sucesso da rede.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Como calcular o retorno esperado dos Delegantes
 
-Um Delegante deve considerar os seguintes fatores para determinar retorno:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- A habilidade de um Indexador em usar os tokens delegados a ele.
-  - Se um Indexador não estiver a alocar todos os tokens disponíveis, ele não está ganhando o retorno máximo que poderia receber, para si mesmo ou para os seus Delegantes.
-- Preste atenção nos primeiros dias da delegação.
-  - Um Indexador pode escolher fechar uma alocação e recolher recompensas entre 1 e 28 dias. Um Indexador também pode ter muitas recompensas que ainda precisa resgatar, deixando o seu total de recompensas baixo.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Como considerar as porções das taxas de query e de indexação
 
-Escolha um Indexador com transparência e honestidade sobre as suas configurações de Taxa de Query e Porção de Taxa de Indexação. Também observe o Tempo de Espera de Parâmetros para ver quanto buffer de tempo tens. Feito tudo isso, será fácil calcular a quantidade de recompensas que receberá.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 A fórmula é:
 
@@ -93,6 +126,8 @@ A fórmula é:
 
 ### Como considerar o pool de delegação do Indexador
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Os Delegantes devem considerar a proporção do Fundo (Pool) de Delegação que possuem.
 
 Todas as recompensas de delegação são divididas igualmente, com um reequilíbrio do pool baseado na quantia depositada no pool pelo Delegante.
@@ -103,37 +138,10 @@ Isto dá ao Delegante uma porção do pool:
 
 > A fórmula acima prova que um Indexador que oferece apenas 20% aos Delegantes fornece uma recompensa melhor que um Indexador que dá 90%. Basta fazer as contas para determinar a melhor recompensa.
 
-### Como considerar a capacidade de delegação
-
-Por fim, considere a capacidade da delegação. Atualmente, a Proporção de Delegação está em 16.
-
-#### Qual a importância disso?
-
-Se um Indexador stakeou 1.000.000 GRT, sua Capacidade de Delegação é 16.000.000 GRT de tokens delegados que pode usar no protocolo. Quaisquer tokens delegados acima desta quantia irão diluir todas as recompensas de Delegante.
-
-Imagine que um Indexador tem 100.000.000 GRT delegados a ele, e a sua capacidade é de apenas 16.000.000 GRT. Efetivamente, 84.000.000 tokens GRT não estão em uso para ganhar tokens. E tanto os Delegantes quanto os Indexadores ganham muito menos recompensas do que deveriam.
-
-Assim, um Delegante deve sempre considerar a Capacidade de Delegação de um Indexador, e levá-la em conta ao tomar decisões.
-
 ## Erros e Perguntas Frequentes sobre Delegação
 
 ### Erro de "Transação Pendente" no MetaMask
 
-1. Quando eu tento delegar a minha transação no MetaMask, ela aparece como "Pendente" ou "Na Fila" por mais tempo que o esperado. O que devo fazer?
-
 Às vezes, tentativas de delegar a Indexadores via MetaMask podem falhar e deixar tentativas de transação "Pendentes" ou "Em Fila" por períodos prolongados.
 
-#### Exemplo
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 Uma solução mais simples para este bug é a reinicialização do navegador (por ex., "abort:restart" na barra de endereço), o que cancelará todas as tentativas anteriores sem subtrair gas da carteira. Vários utilizadores que encontraram este problema relataram sucesso nas transações após reiniciar o seu navegador e tentar delegar.
-
-## Guia em Vídeo
-
-Esse guia em vídeo recapitula esta página ao mesmo tempo em que interage com a interface.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 32a48c02c7beb626d08d799e03213cf17a9f7637 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:44:57 -0500
Subject: [PATCH 2721/3820] New translations glossary.mdx (Romanian)

---
 website/pages/ro/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ro/resources/glossary.mdx b/website/pages/ro/resources/glossary.mdx
index fa813b659730..ffcd4bca2eed 100644
--- a/website/pages/ro/resources/glossary.mdx
+++ b/website/pages/ro/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From ddeeb5d59dd2ed8ea7665b9d3db9f7dd87eea529 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:44:59 -0500
Subject: [PATCH 2722/3820] New translations delegating.mdx (Romanian)

---
 .../pages/ro/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/ro/resources/roles/delegating.mdx b/website/pages/ro/resources/roles/delegating.mdx
index eda60369e00a..55ad58331559 100644
--- a/website/pages/ro/resources/roles/delegating.mdx
+++ b/website/pages/ro/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Overview
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Considering the query fee cut and indexing fee cut
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Considering the Indexer's delegation pool
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Considering the delegation capacity
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Delegator FAQs and Bugs
 
 ### MetaMask "Pending Transaction" Bug
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From e68b19153d88de13bb2e2bbf860b09b57c0f9b87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:00 -0500
Subject: [PATCH 2723/3820] New translations glossary.mdx (French)

---
 website/pages/fr/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/fr/resources/glossary.mdx b/website/pages/fr/resources/glossary.mdx
index 359c0cb2aee2..acfffb785b5a 100644
--- a/website/pages/fr/resources/glossary.mdx
+++ b/website/pages/fr/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossaire
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 1f357f23aa45d72405984de1499e2f430a899724 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:01 -0500
Subject: [PATCH 2724/3820] New translations delegating.mdx (French)

---
 .../pages/fr/resources/roles/delegating.mdx   | 119 +++++++++---------
 1 file changed, 63 insertions(+), 56 deletions(-)

diff --git a/website/pages/fr/resources/roles/delegating.mdx b/website/pages/fr/resources/roles/delegating.mdx
index 6db9cdee4dd3..0cca71ae43e1 100644
--- a/website/pages/fr/resources/roles/delegating.mdx
+++ b/website/pages/fr/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Délégation
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Aperçu
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Apprenez comment être un délégateur efficace dans The Graph Network.
+## How Does Delegation Work?
 
-Les Délégateurs partagent les gains du protocole aux côtés de tous les indexeurs en fonction de leur participation déléguée. Par conséquent, ils doivent faire preuve de discernement pour choisir les indexeurs en fonction de plusieurs facteurs.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-Ce guide comporte trois sections:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - Les risques de la délégation de jetons dans The Graph Network
 - Comment calculer les rendements escomptés en tant que délégué
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Risques de délégation
 
 Les principaux risques liés à la fonction de délégué dans le protocole sont transmis ci-dessous.
 
-### The delegation tax
+### The Delegation Tax
 
 Les délégués ne peuvent pas être licenciés en cas de mauvais comportement, mais ils sont soumis à une taxe visant à décourager les mauvaises décisions susceptibles de nuire à l'intégrité du réseau.
 
@@ -40,25 +68,29 @@ En tant que Délégateur, il est important de comprendre ce qui suit :
 
 - Pour être en sécurité, vous devriez calculer votre retour potentiel lorsque vous déléguez à un Indexeur. Par exemple, vous pourriez calculer combien de jours il faudra avant d'avoir récupéré la taxe de 0,5% sur votre délégation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Pourquoi ceci est t-il important?
 
-Si vous choisissez un Indexeur qui n'est pas fiable ou qui ne fait pas du bon travail, vous voudrez vous désengager. Cela signifie que vous perdrez beaucoup d'opportunités de gagner des récompenses, ce qui peut être aussi mauvais que de brûler des GRT. Par conséquent, il est recommandé de choisir judicieusement un Indexeur.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Choisir un indexeur digne de confiance avec une rémunération équitable pour les délégués
+#### Paramètres de Délégation
 
 Pour comprendre comment choisir un Indexeur fiable, vous devez comprendre les paramètres de Délégation.
 
-#### Paramètres de Délégation
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - Si la part de récompense d'un indexeur est fixée à 100%, en tant que délégateur, vous recevrez 0 récompense d'indexation.
   - Si elle est fixée à 80%, en tant que Délégateur, vous recevrez 20%.
@@ -70,24 +102,25 @@ Pour comprendre comment choisir un Indexeur fiable, vous devez comprendre les pa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-Comme vous pouvez le voir, pour choisir le bon Indexeur, vous devez prendre en compte plusieurs éléments.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Beaucoup d'Indexeurs sont très actifs sur Discord et seront heureux de répondre à vos questions.
-- Beaucoup d'entre eux indexent depuis des mois et font de leur mieux pour aider les Délégateurs à obtenir un bon retour, car cela améliore la santé et le succès du réseau.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calcul du rendement attendu par les Délégateurs
 
-Un Délégateur doit considérer les facteurs suivants pour déterminer un rendement :
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Considérer la capacité d'un Indexeur à utiliser les jetons délégués dont il dispose.
-  - Si un Indexeur n'alloue pas tous les jetons disponibles, ils ne gagnent pas le maximum de profit qu'ils pourraient obtenir pour lui même ou ses Déléguateurs.
-- Soyez attentif aux premiers jours de la délégation.
-  - Un Indexeur peut choisir de fermer une allocation et de collecter des récompenses à tout moment entre 1 et 28 jours. Il est possible qu'un indexeur ait encore beaucoup de récompenses à collecter, de sorte que le total de ses récompenses est faible.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Considérant la réduction des frais d'interrogation et la réduction des frais d'indexation
 
-Vous devriez choisir un Indexeur qui est transparent et honnête dans la fixation de ses frais de requête et de ses réductions de frais d'indexation. Vous devez également examiner le Paramètre délai de récupérations pour voir de combien de temps vous disposez. Une fois cela fait, il est facile de calculer le montant des récompenses que vous obtenez.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 La formule est :
 
@@ -95,6 +128,8 @@ La formule est :
 
 ### Compte tenu du pool de délégation de l'indexeur
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Les Déléguateurs doivent considérer la proportion du Pool de Délégation qu'ils possèdent.
 
 Toutes les récompenses de délégation sont partagées de manière égale, avec un rééquilibrage du pool basé sur le montant que le Déléguateur a déposé dans le pool.
@@ -105,38 +140,10 @@ Cela donne au Déléguateur une part du pool :
 
 > La formule ci-dessus montre qu'il est possible pour un Indexeur offrant seulement 20% aux Déléguateurs de fournir une meilleure récompense qu'un Indexeur donnant 90%. Il suffit de faire les calculs pour déterminer la meilleure récompense.
 
-### Compte tenu de la capacité de délégation
-
-Enfin, considérez la capacité de délégation. Actuellement, le Ratio de Délégation est fixé à 16.
-
-#### Pourquoi est-ce important?
-
-Cela signifie que si un Indexeur a staké 1 000 000 GRT, sa Capacité de Délégation est de 16 000 000 GRT de tokens délégués qu'ils peuvent utiliser dans le protocole. Tous les tokens délégués au-delà de ce montant dilueront toutes les récompenses des Déléguateurs.
-
-Imaginez un Indexeur avec 100 000 000 GRT délégués à lui, mais sa capacité est seulement de 16 000 000 GRT. Cela signifie effectivement que 84 000 000 de GRT ne sont pas utilisés pour gagner des tokens. Ainsi, les Déléguateurs et les Indexeurs gagnent moins de récompenses qu'ils pourraient.
-
-Par conséquent, un Déléguateur doit toujours considérer la Capacité de Délégation d'un Indexeur et en tenir compte dans leur prise de décision.
-
 ## FAQ et bugs pour les délégants
 
 ### Bug MetaMask « Transaction en attente »
 
-1. Lorsque j'essaie de déléguer ma transaction dans MetaMask, elle apparaît comme « En attente » ( "Pending") ou « En file d'attente » ( "Queued")
-    plus longtemps que prévu. Que devrais-je faire?
-
 Parfois, les tentatives de déléguer aux Indexeurs via MetaMask peuvent échouer et entraîner des périodes prolongées de tentatives de transaction "Pending" ou "Queued".
 
-#### Exemple
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 Une solution simple à ce problème consiste à redémarrer le navigateur (par exemple, en utilisant "abort:restart" dans la barre d'adresse), ce qui annulera toutes les tentatives précédentes sans que le gaz ne soit soustrait du portefeuille. Plusieurs utilisateurs ayant rencontré ce problème ont signalé des transactions réussies après avoir redémarré leur navigateur et tenté de déléguer.
-
-## Guide Vidéo
-
-Ce guide vidéo passe en revue cette page tout en interagissant avec l'interface utilisateur.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 27a4b64ddeaeb44c99d9478741c468fb3f4e223a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:02 -0500
Subject: [PATCH 2725/3820] New translations glossary.mdx (Spanish)

---
 website/pages/es/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/es/resources/glossary.mdx b/website/pages/es/resources/glossary.mdx
index fdca3b093220..a3614062a63a 100644
--- a/website/pages/es/resources/glossary.mdx
+++ b/website/pages/es/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glosario
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From c3abf3c68e2b19a6164d5e81b99341ec5855b4d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:03 -0500
Subject: [PATCH 2726/3820] New translations delegating.mdx (Spanish)

---
 .../pages/es/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/es/resources/roles/delegating.mdx b/website/pages/es/resources/roles/delegating.mdx
index 1470e14f300b..3c6ff9d5b931 100644
--- a/website/pages/es/resources/roles/delegating.mdx
+++ b/website/pages/es/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegar
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Descripción
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - Los riesgos de delegar tokens en la red de The Graph
 - Cómo calcular los rendimientos que te esperan siendo Delegador
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Riesgos de la Delegación
 
 A continuación se enumeran los principales riesgos de ser un Delegador en el protocolo.
 
-### The delegation tax
+### The Delegation Tax
 
 Los Delegadores no pueden ser recortados por mal comportamiento, pero existe un impuesto sobre los Delegadores para desincentivar la toma de malas decisiones que puedan perjudicar la integridad de la red.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Elige un Indexador fiable, que pague recompensas justas a sus Delegadores
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Siempre ten en cuenta la tarifa por consulta y el recorte de recompensas para el Indexador
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Tener en cuenta el pool de delegación de cada Indexador
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Considerar la capacidad de delegación
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Preguntas Frecuentes del Delegador y Errores
 
 ### Error de "Transacción Pendiente" en MetaMask
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Ejemplo
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 29e9df66232fd339371602f77212f8c5492a2a7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:04 -0500
Subject: [PATCH 2727/3820] New translations glossary.mdx (Arabic)

---
 website/pages/ar/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ar/resources/glossary.mdx b/website/pages/ar/resources/glossary.mdx
index dde52c37403a..f922950390a6 100644
--- a/website/pages/ar/resources/glossary.mdx
+++ b/website/pages/ar/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: قائمة المصطلحات
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 28c24919e8752e5c5e617023d26e45251be4af95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:05 -0500
Subject: [PATCH 2728/3820] New translations delegating.mdx (Arabic)

---
 .../pages/ar/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/ar/resources/roles/delegating.mdx b/website/pages/ar/resources/roles/delegating.mdx
index 59f79e78bcf2..81095fcca05d 100644
--- a/website/pages/ar/resources/roles/delegating.mdx
+++ b/website/pages/ar/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## نظره عامة
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - مخاطر تفويض التوكن في شبكة The Graph
 - كيفية حساب العوائد المتوقعة كمفوض
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 القائمة أدناه هي المخاطر الرئيسية لكونك مفوضا في البروتوكول.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### اختيار مفهرس جدير بالثقة مع عائد جيد للمفوضين
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### النظر في اقتطاع رسوم الاستعلام query fee cut واقتطاع رسوم الفهرسة indexing fee cut
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### النظر في أسهم تفويض المفهرس
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### النظر في سعة التفويض (delegation capacity)
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Delegator FAQs and Bugs
 
 ### MetaMask "Pending Transaction" Bug
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 311078f2867613745a96e761c4335bbe2d2a5318 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:06 -0500
Subject: [PATCH 2729/3820] New translations glossary.mdx (Czech)

---
 website/pages/cs/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/cs/resources/glossary.mdx b/website/pages/cs/resources/glossary.mdx
index ead2fbb3e17b..70161f581585 100644
--- a/website/pages/cs/resources/glossary.mdx
+++ b/website/pages/cs/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glosář
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 7c796043f597847ff93729117a9eb8c2995e37ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:08 -0500
Subject: [PATCH 2730/3820] New translations delegating.mdx (Czech)

---
 .../pages/cs/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/cs/resources/roles/delegating.mdx b/website/pages/cs/resources/roles/delegating.mdx
index 3d3ad1dfc5e8..a3854aba3e49 100644
--- a/website/pages/cs/resources/roles/delegating.mdx
+++ b/website/pages/cs/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegování
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Přehled
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - Rizika delegování tokenů v síti Graf
 - Jak vypočítat očekávané výnosy jako delegát
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Rizika delegování
 
 Níže jsou uvedena hlavní rizika plynoucí z delegáta v protokolu.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegáti nemohou být za špatné chování kráceni, ale existuje daň pro delegáty, která má odradit od špatného rozhodování, jež by mohlo poškodit integritu sítě.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Výběr důvěryhodného indexátora se spravedlivou odměnou pro delegáty
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### S ohledem na snížení poplatků za dotaz a indexaci
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Zohlednění fondu delegování indexátoru
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Vzhledem ke kapacitě delegace
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## FAQ a chyby delegáta
 
 ### Chyba MetaMask "Čekající transakce"
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Příklad
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From a30caca8623d9b41c10a14a48b6a03751b2a175a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:09 -0500
Subject: [PATCH 2731/3820] New translations glossary.mdx (German)

---
 website/pages/de/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/de/resources/glossary.mdx b/website/pages/de/resources/glossary.mdx
index fa813b659730..ffcd4bca2eed 100644
--- a/website/pages/de/resources/glossary.mdx
+++ b/website/pages/de/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 0b4b35ed6641edfaba38d8648f68249c86f1af8b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:10 -0500
Subject: [PATCH 2732/3820] New translations delegating.mdx (German)

---
 .../pages/de/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/de/resources/roles/delegating.mdx b/website/pages/de/resources/roles/delegating.mdx
index c67be429d140..a439332176eb 100644
--- a/website/pages/de/resources/roles/delegating.mdx
+++ b/website/pages/de/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegieren
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Overview
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Erfahren Sie im The Graph Netzwerk, wie Sie ein effektiver Delegator sein können.
+## How Does Delegation Work?
 
-Die Delegatoren teilen die Erträge des Protokolls mit allen Indexern auf der Grundlage ihres delegierten Einsatzes. Daher müssen sie nach bestem Wissen und Gewissen Indexer auf der Grundlage mehrerer Faktoren auswählen.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-Dieser Leitfaden besteht aus drei Abschnitten:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - Die Risiken der Übertragung von Token in The Graph Network
 - Wie man als Delegator die erwarteten Erträge berechnet
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Risiken bei der Delegation
 
 Nachfolgend sind die wichtigsten Risiken aufgeführt, die mit der Tätigkeit eines Delegators im Protokoll verbunden sind.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegatoren können nicht für schlechtes Verhalten bestraft werden, aber es gibt eine Steuer für Delegatoren, um von schlechten Entscheidungen abzuschrecken, die die Integrität des Netzes beeinträchtigen könnten.
 
@@ -40,25 +68,29 @@ Als Delegator ist es wichtig, die folgenden Punkte zu verstehen:
 
 - Um auf Nummer sicher zu gehen, sollten Sie Ihre potenzielle Rendite berechnen, wenn Sie einen Indexer beauftragen. Als Beispiel könnten Sie berechnen, wie viele Tage es dauern wird, bis Sie die 0,5 % Steuer auf Ihre Delegation zurückverdient haben.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Warum ist das wichtig?
 
-Wenn Sie sich für einen Indexer entscheiden, der nicht vertrauenswürdig ist oder keine gute Arbeit leistet, werden Sie die Abtretung rückgängig machen wollen. Das bedeutet, dass Sie viele Möglichkeiten verlieren, Rewards zu verdienen, was genauso schlimm sein kann wie das Verbrennen von GRT. Daher sollten Sie einen Indexer mit Bedacht auswählen.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Auswahl eines vertrauenswürdigen Indexers mit einer fairen Reward-Ausschüttung für Delegatoren
+#### Parameter der Delegation
 
 Um zu verstehen, wie man einen vertrauenswürdigen Indexer auswählt, müssen Sie die Delegationsparameter verstehen.
 
-#### Parameter der Delegation
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ Um zu verstehen, wie man einen vertrauenswürdigen Indexer auswählt, müssen Si
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Considering the query fee cut and indexing fee cut
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Considering the Indexer's delegation pool
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Berücksichtigung der Delegationskapazität
-
-Schließlich ist noch die Delegationskapazität zu berücksichtigen. Derzeit ist die Delegationsquote auf 16 festgelegt.
-
-#### Warum ist das wichtig?
-
-Das bedeutet, wenn ein Indexer 1.000.000 GRT eingesetzt hat, beträgt seine Delegationskapazität 16.000.000 GRT an delegierten Token, die er im Protokoll verwenden kann. Alle delegierten Token, die diesen Betrag überschreiten, verwässern alle Rewards des Delegators.
-
-Stellen Sie sich einen Indexer vor, dem 100.000.000 GRT übertragen wurden, der aber nur über eine Kapazität von 16.000.000 GRT verfügt. Das bedeutet, dass 84.000.000 GRT-Tokens nicht genutzt werden, um Tokens zu verdienen. Sowohl die Delegatoren als auch die Indexer verdienen also weniger Rewards als sie könnten.
-
-Daher sollte ein Delegator immer die Delegationskapazität eines Indexers in Betracht ziehen und diese in seine Entscheidungsfindung einbeziehen.
-
 ## Delegator FAQs und Bugs
 
 ### MetaMask-Fehler „Ausstehende Transaktion“
 
-1. Wenn ich versuche, meine Transaktion in MetaMask zu delegieren, erscheint sie als „Pending“ ("Ausstehend") oder „Queued“ ("In der Warteschlange") länger als erwartet. Was sollte ich tun?
-
 Gelegentlich können Versuche, Indexer über MetaMask zu delegieren, fehlschlagen und zu längeren Zeiträumen mit „Pending“ oder „Queued“ Transaktionsversuchen führen.
 
-#### Beispiel
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 506542dd24d4eaff5e0cde9165c300f313f25875 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:11 -0500
Subject: [PATCH 2733/3820] New translations glossary.mdx (Italian)

---
 website/pages/it/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/it/resources/glossary.mdx b/website/pages/it/resources/glossary.mdx
index fa813b659730..ffcd4bca2eed 100644
--- a/website/pages/it/resources/glossary.mdx
+++ b/website/pages/it/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From e9c325b8acba7f7744b270e28340275f8996d5ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:12 -0500
Subject: [PATCH 2734/3820] New translations delegating.mdx (Italian)

---
 .../pages/it/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/it/resources/roles/delegating.mdx b/website/pages/it/resources/roles/delegating.mdx
index ba6e0319839b..8210a92c969d 100644
--- a/website/pages/it/resources/roles/delegating.mdx
+++ b/website/pages/it/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegazione
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Panoramica
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - I rischi della delegazione dei token in The Graph Network
 - Come calcolare i rendimenti previsti come Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Rischi di delegazione
 
 Di seguito sono elencati i principali rischi essere il Delegator nel protocollo.
 
-### The delegation tax
+### The Delegation Tax
 
 I delegator non possono essere penalizzati per un comportamento scorretto, ma c'è una tassa sui delegator per disincentivare un processo decisionale insufficiente che potrebbero danneggiare l'integrità della rete.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Scegliere un Indexer affidabile con una giusta ricompensa per i Delegator
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Considerando la riduzione delle tariffe di query e la riduzione delle tariffe di indicizzazione
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Considerando il delegation pool del Indexer
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Considerando la capacità di delegazione
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## FAQ e bug dei Delegator
 
 ### MetaMask "Transazione in sospeso" Bug
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Esempio
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 3d8a301e991b37fa348b72722e56667658e6b86c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:13 -0500
Subject: [PATCH 2735/3820] New translations glossary.mdx (Japanese)

---
 website/pages/ja/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ja/resources/glossary.mdx b/website/pages/ja/resources/glossary.mdx
index baab87472fce..c71697a009cf 100644
--- a/website/pages/ja/resources/glossary.mdx
+++ b/website/pages/ja/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: 用語集
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 5ef8b6e3b85de05b23e7375c709a1ed1accd5e14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:15 -0500
Subject: [PATCH 2736/3820] New translations delegating.mdx (Japanese)

---
 .../pages/ja/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/ja/resources/roles/delegating.mdx b/website/pages/ja/resources/roles/delegating.mdx
index 604233139afd..8a3782527843 100644
--- a/website/pages/ja/resources/roles/delegating.mdx
+++ b/website/pages/ja/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: 委任
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## 概要
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - グラフネットワークでトークンをデリゲートすることのリスク
 - デリゲーターとしての期待リターンの計算方法
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## デリゲーションリスク
 
 以下にリストされているのは、プロトコルで委任者になることの主なリスクです。
 
-### The delegation tax
+### The Delegation Tax
 
 デリゲーターは悪意の行動をしてもスラッシュされないが、デリゲーターにはデポジット税が課せられ、ネットワークの整合性を損なう可能性のある悪い意思決定を抑止します。
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### デリゲーターに公平な報酬を支払う信頼できるインデクサーの選択
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### クエリフィーのカットとインデックスフィーのカットの検討
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### インデクサーのデリゲーションプールを考慮する
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### デリゲーションの容量を考慮する
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## デリゲーターに関するFAQと不具合
 
 ### MetaMask "Pending Transaction "バグ
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### 例
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 3fc981eacd1a8c7a522a1dcfae7c6787c6b0a2b0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:16 -0500
Subject: [PATCH 2737/3820] New translations glossary.mdx (Korean)

---
 website/pages/ko/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ko/resources/glossary.mdx b/website/pages/ko/resources/glossary.mdx
index fa813b659730..ffcd4bca2eed 100644
--- a/website/pages/ko/resources/glossary.mdx
+++ b/website/pages/ko/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From b1289edd928df1b4ba52c10039cb9a2c9636327c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:17 -0500
Subject: [PATCH 2738/3820] New translations delegating.mdx (Korean)

---
 .../pages/ko/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/ko/resources/roles/delegating.mdx b/website/pages/ko/resources/roles/delegating.mdx
index eda60369e00a..55ad58331559 100644
--- a/website/pages/ko/resources/roles/delegating.mdx
+++ b/website/pages/ko/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Overview
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Considering the query fee cut and indexing fee cut
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Considering the Indexer's delegation pool
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Considering the delegation capacity
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Delegator FAQs and Bugs
 
 ### MetaMask "Pending Transaction" Bug
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From b79fb43adebd0944073729f08646714b13f92e25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:18 -0500
Subject: [PATCH 2739/3820] New translations glossary.mdx (Dutch)

---
 website/pages/nl/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/nl/resources/glossary.mdx b/website/pages/nl/resources/glossary.mdx
index fa813b659730..ffcd4bca2eed 100644
--- a/website/pages/nl/resources/glossary.mdx
+++ b/website/pages/nl/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From eab366efeb9759bc8384d019081129e1c3718ec8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:19 -0500
Subject: [PATCH 2740/3820] New translations delegating.mdx (Dutch)

---
 .../pages/nl/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/nl/resources/roles/delegating.mdx b/website/pages/nl/resources/roles/delegating.mdx
index 99bd3b78d432..557e7565d957 100644
--- a/website/pages/nl/resources/roles/delegating.mdx
+++ b/website/pages/nl/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegeren
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Overview
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - De risico's van het delegeren van tokens in het Graph Netwerk
 - Hoe je verwachte opbrengsten als Delegeerder berekent
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegatie Risico's
 
 Hieronder staan de belangrijkste risico's van het zijn van een Delegeerder in het protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegeerders kunnen niet worden gestraft voor slecht gedrag, maar er is een belasting voor Delegeerders om slechte besluitvorming die de integriteit van het netwerk kan schaden te ontmoedigen.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Het kiezen van een betrouwbare Indexeerder met een eerlijke beloningsuitbetaling voor Delegeerders
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Rekening houden met de query fee aandeel en indexing fee aandeel
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Rekening houden met de delegatie pool van een Indexeerder
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Rekening houden met de delegatiecapaciteit
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Veelgestelde vragen van Delegeerders en Bugs
 
 ### MetaMask "Pending Transaction" Bug
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 32ff55dc80b4a43b41fd1d5887752715a7b19fd6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:20 -0500
Subject: [PATCH 2741/3820] New translations glossary.mdx (Polish)

---
 website/pages/pl/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/pl/resources/glossary.mdx b/website/pages/pl/resources/glossary.mdx
index fa813b659730..ffcd4bca2eed 100644
--- a/website/pages/pl/resources/glossary.mdx
+++ b/website/pages/pl/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From c56a04b8a4a3bb8ff742696ce50c4ed432bb68ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:21 -0500
Subject: [PATCH 2742/3820] New translations delegating.mdx (Polish)

---
 .../pages/pl/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/pl/resources/roles/delegating.mdx b/website/pages/pl/resources/roles/delegating.mdx
index eda60369e00a..55ad58331559 100644
--- a/website/pages/pl/resources/roles/delegating.mdx
+++ b/website/pages/pl/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Overview
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Considering the query fee cut and indexing fee cut
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Considering the Indexer's delegation pool
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Considering the delegation capacity
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Delegator FAQs and Bugs
 
 ### MetaMask "Pending Transaction" Bug
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 6d29e916791a42fe6357d0ad344db5367adf56c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:22 -0500
Subject: [PATCH 2743/3820] New translations glossary.mdx (Russian)

---
 website/pages/ru/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ru/resources/glossary.mdx b/website/pages/ru/resources/glossary.mdx
index fa813b659730..ffcd4bca2eed 100644
--- a/website/pages/ru/resources/glossary.mdx
+++ b/website/pages/ru/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 67afac3dc4bb5bc360a7cf906513ec48e3b538d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:23 -0500
Subject: [PATCH 2744/3820] New translations delegating.mdx (Russian)

---
 .../pages/ru/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/ru/resources/roles/delegating.mdx b/website/pages/ru/resources/roles/delegating.mdx
index c987ca0ab621..9f23ac4c669e 100644
--- a/website/pages/ru/resources/roles/delegating.mdx
+++ b/website/pages/ru/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Делегирование
 ---
 
-Делегаторы — это участники сети, которые делегируют (то есть "стейкают") GRT одному или нескольким индексаторам.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- Они помогают обеспечивать безопасность сети, не запуская собственную Graph Node.
+## Обзор
 
-- Они зарабатывают часть комиссий за запросы и вознаграждений индексатора, делегируя им свои средства.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## Как это работает?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-Количество запросов, которые индексатор может обработать, зависит от его собственного стейка, **делегированного стейка** и цены, которую индексатор взимает за каждый запрос. Следовательно, чем больше стейк, выделенный индексатору, тем больше запросов он может обработать.
+## Benefits of Delegating
 
-## Руководство для Делегаторов
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Узнайте, как стать эффективным делегатом в The Graph Network.
+## How Does Delegation Work?
 
-Делегаторы делят доходы от протокола со всеми Индексаторами на основе своего делегированного стейка. Следовательно, они должны принимать взвешенные решения при выборе Индексаторов, основываясь на множестве факторов.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Пожалуйста, обратите внимание, что это руководство не охватывает такие шаги, как правильная настройка MetaMask. Сообщество Ethereum предоставляет исчерпывающий ресурс по кошелькам по следующей ссылке ([источник](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-Данное руководство состоит из трех разделов:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - Риски связанные с делегацией в сети The Graph
 - Как расчитать примерный доход
-- Видео руководство, показывающее шаги для делегирования в пользовательском интерфейсе сети The Graph
 
 ## Риски делегации
 
 Ниже указаны основные риски Делегатора.
 
-### Комиссия за делегирование
+### The Delegation Tax
 
 Делегаторы не могут быть наказаны за некорректное поведение, но они уплачивают комиссию на делегацию, который должен стимулировать обдуманный выбор Индексатора для делегации.
 
@@ -40,24 +68,28 @@ title: Делегирование
 
 - В целях безопасности Вам следует рассчитать потенциальную прибыль при делегировании Индексатору. Например, Вы можете подсчитать, сколько дней пройдет, прежде чем Вы вернете налог в размере 0,5% за своё делегирование.
 
-### Период разблокировки делегирования
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Когда делегатор хочет отменить делегирование, его токены подлежат 28-дневному периоду разблокировки. Это означает, что в течение 28 дней он не может передавать свои токены или получать вознаграждения.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Почему это важно?
 
-Если Вы выберете Индексатора, которому нельзя доверять или который плохо выполняет свою работу, Вам захочется отозвать делегирование. Это приведёт к тому, что Вы упустите множество возможностей для получения наград, что может быть так же плохо, как сжигание GRT. Поэтому рекомендуется тщательно выбирать Индексатора.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Период разблокировки делегирования](/img/Delegation-Unbonding.png) _Обратите внимание на комиссию в 0,5% в интерфейсе делегирования, а также на 28-дневный период разблокировки._
 </div>
 
-### Выбор надежного Индексатора со справедливым распределением вознаграждений для Делегаторов
+#### Параметры делегирования
 
 Чтобы понять, как выбрать надежного Индексатора, Вам необходимо разобраться в параметрах делегирования.
 
-#### Параметры делегирования
-
 - **Часть вознаграждения за индексацию** — доля вознаграждений, которую индексатор оставляет себе.
   - Если доля вознаграждения индексатора установлена на 100%, как делегатор, как Делегатор, Вы получите 0 вознаграждений за индексацию.
   - Если установлено значение 80%, то как Делегатор Вы получите 20%.
@@ -68,24 +100,25 @@ title: Делегирование
 
 - **Часть комиссии за запросы** — это то же самое, что и часть вознаграждения за индексирование, но она применяется к доходам от комиссий за запросы, которые индексатор собирает.
 
-Как видите, чтобы выбрать правильного Индексатора, необходимо учитывать множество факторов.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- Настоятельно рекомендуется посетить [Discord The Graph](https://discord.gg/graphprotocol), чтобы узнать, какие индексаторы имеют лучшую социальную и техническую репутацию, а также какие из них регулярно вознаграждают делегаторов.
-- Многие Индексаторы активно участвуют в Discord и будут рады ответить на Ваши вопросы.
-- Многие из них занимаются индексированием уже несколько месяцев и делают все возможное, чтобы помочь Делегаторам получить хорошую прибыль, поскольку это улучшает здоровье и успех сети.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Расчет ожидаемой доходности Делегаторов
 
-Делегатор должен учитывать следующие факторы для определения доходности:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Учитывайте способность Индексатора использовать доступные ему делегированные токены.
-  - Если Индексатор не распределяет все доступные токены, он не получает максимальной прибыли, которую мог бы получить для себя или своих Делегаторов.
-- Обратите внимание на первые дни делегирования.
-  - Индексатор может закрыть распределение и получить вознаграждение в любой момент между 1 и 28 днями. Вполне возможно, что Индексатору еще предстоит собрать много наград, поэтому общее количество вознаграждений невелико.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Учёт части комиссии за запросы и части комиссии за индексирование
 
-Вам следует выбрать индексатора, который прозрачен и честен при установке части комиссии за запросы и части комиссии за индексирование. Также стоит обратить внимание на время ожидания параметров (Cooldown time), чтобы понять, сколько времени у вас есть на принятие решения. После этого легко рассчитать сумму вознаграждений, которые вы получаете.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 Формула следующая:
 
@@ -93,6 +126,8 @@ title: Делегирование
 
 ### Осмотр пула делегирования индексатора
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Делегаторам следует учитывать долю пула делегаций, которым они владеют.
 
 Все вознаграждения за делегирование распределяются поровну, при этом баланс пула перераспределяется в зависимости от суммы, внесенной Делегатором в пул.
@@ -103,37 +138,10 @@ title: Делегирование
 
 > Приведенная выше формула показывает, что Индексатор, предлагающий Делегаторам только 20%, может обеспечить лучшее вознаграждение, чем Индексатор, предоставляющий 90%. Просто посчитайте, чтобы определить лучшие условия вознаграждения.
 
-### Учёт возможности делегирования
-
-И, наконец, рассмотрим возможности делегирования. В настоящее время коэффициент делегирования установлен на уровне 16.
-
-#### Почему это важно?
-
-Это означает, что если у Индексатора есть 1,000,000 застейканых GRT, объём его делегирования составляет 16,000,000 GRT делегированных токенов, которые он может использовать в протоколе. Любые делегированные токены сверх этого объёма уменьшат вознаграждения всех Делегаторов.
-
-Представьте себе Индексатора, которому делегировано 100,000,000 GRT, а его объём составляет всего 16,000,000 GRT. Это означает, что фактически 84,000,000 GRT токенов не используются для получения токенов. Таким образом, и Делегаторы, и Индексаторы получают меньше вознаграждений, чем могли бы.
-
-Поэтому Делегатор всегда должен обращать внимание на возможности делегирования Индексатора и учитывать их при принятии решений.
-
 ## Частые вопросы и баги
 
 ### Ошибка Метамаска "Pending Transaction"
 
-1. Когда я пытаюсь делегировать свою транзакцию в MetaMask, она отображается как «В ожидании» или «В очереди» дольше, чем ожидалось. Что мне делать?
-
 Иногда попытки делегировать Индексаторам через MetaMask могут завершаться неудачей, что приводит к длительным периодам транзакций со статусом «В ожидании» или «В очереди».
 
-#### Пример
-
-Предположим, вы пытаетесь делегировать с недостаточной комиссией за газ относительно текущих цен.
-
-- Это действие может привести к тому, что попытка транзакции будет отображаться как "В ожидании" в вашем кошельке MetaMask в течение более 15 минут. Когда это происходит, вы можете попытаться выполнить последующие транзакции, но они будут обработаны только после того, как будет завершена первоначальная транзакция, поскольку транзакции для одного адреса должны обрабатываться по порядку.
-- В таких случаях эти транзакции можно отменить в MetaMask, но попытки транзакций будут накапливать комиссии за газ без какой-либо гарантии, что последующие попытки будут успешными.
-
 Простым решением этой ошибки является перезапуск браузера (например, с помощью "abort:restart" в адресной строке), что отменит все предыдущие попытки без взимания газа из кошелька. Некоторые пользователи, столкнувшиеся с этой проблемой, сообщили об успешных транзакциях после перезапуска браузера и попытки делегирования.
-
-## Видео руководство
-
-В этом видеоруководстве рассматривается данная страница при взаимодействии с пользовательским интерфейсом.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From d72cdaa8cd0721d5f828aaa7309211b14691d7df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:24 -0500
Subject: [PATCH 2745/3820] New translations glossary.mdx (Swedish)

---
 website/pages/sv/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/sv/resources/glossary.mdx b/website/pages/sv/resources/glossary.mdx
index b6cf29493dc3..dd930819456b 100644
--- a/website/pages/sv/resources/glossary.mdx
+++ b/website/pages/sv/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Ordlista
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 8005790e79de5f1af80cd008d0e448cfde499d7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:26 -0500
Subject: [PATCH 2746/3820] New translations delegating.mdx (Swedish)

---
 .../pages/sv/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/sv/resources/roles/delegating.mdx b/website/pages/sv/resources/roles/delegating.mdx
index c024c25aee54..b9ae4c858aa9 100644
--- a/website/pages/sv/resources/roles/delegating.mdx
+++ b/website/pages/sv/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegera
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Översikt
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - Riskerna med att delegera tokens i The Graph-nätverket
 - Hur man beräknar förväntad avkastning som Delegater
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegationsrisker
 
 Här nedan listas huvudriskerna med att vara en Delegater i protokollet.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegater kan inte "slashas" för dåligt beteende, men det finns en avgift för Delegater för att avskräcka dåligt beslutsfattande som kan skada nätverkets integritet.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Att välja en pålitlig Indexer med en rättvis belöningsutbetalning till Delegater
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Att överväga frågebetalningsavgiften och indexeringsavgiften
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Att överväga Indexer's delegeringspool
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Att överväga delegeringskapaciteten
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Delegaters FAQ och buggar
 
 ### Metamask "Väntande transaktion" bugg
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Exempel
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 8eefef7d990a574f9c1ec951527804a09addd557 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:27 -0500
Subject: [PATCH 2747/3820] New translations glossary.mdx (Turkish)

---
 website/pages/tr/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/tr/resources/glossary.mdx b/website/pages/tr/resources/glossary.mdx
index fa813b659730..ffcd4bca2eed 100644
--- a/website/pages/tr/resources/glossary.mdx
+++ b/website/pages/tr/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From e84bb97d92e7f300f584042b9c7a6150f66c1044 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:28 -0500
Subject: [PATCH 2748/3820] New translations delegating.mdx (Turkish)

---
 .../pages/tr/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/tr/resources/roles/delegating.mdx b/website/pages/tr/resources/roles/delegating.mdx
index a7be05b9f698..7b2b6bca2f17 100644
--- a/website/pages/tr/resources/roles/delegating.mdx
+++ b/website/pages/tr/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Genel Bakış
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Considering the query fee cut and indexing fee cut
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Considering the Indexer's delegation pool
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Considering the delegation capacity
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Delegator FAQs and Bugs
 
 ### MetaMask "Pending Transaction" Bug
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Örnek
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 01222a4dbbdaff57fe19588ef2feb183ffa52e87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:29 -0500
Subject: [PATCH 2749/3820] New translations glossary.mdx (Ukrainian)

---
 website/pages/uk/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/uk/resources/glossary.mdx b/website/pages/uk/resources/glossary.mdx
index 96e2835ae2aa..1338f2ba16ba 100644
--- a/website/pages/uk/resources/glossary.mdx
+++ b/website/pages/uk/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Глосарій
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From db4f5c5042058c92f80548d3ee9764d1519fb318 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:30 -0500
Subject: [PATCH 2750/3820] New translations delegating.mdx (Ukrainian)

---
 .../pages/uk/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/uk/resources/roles/delegating.mdx b/website/pages/uk/resources/roles/delegating.mdx
index 48541d9117ed..e7c13c83ff66 100644
--- a/website/pages/uk/resources/roles/delegating.mdx
+++ b/website/pages/uk/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Делегування
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Overview
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - Ризики делегування токенів в мережі Graph
 - Як розрахувати можливі прибутки як делегат
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Ризики, пов'язані з делегуванням
 
 Нижче перераховані основні ризики, пов'язані з участю делегата в протоколі.
 
-### The delegation tax
+### The Delegation Tax
 
 Делегати не можуть бути виключені за погану поведінку, але існує певний штраф для них, щоб позбавити стимулу щодо прийняття поганих рішень, які можуть зашкодити цілісності мережі.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Вибір надійного індексатора зі справедливою винагородою для делегатів
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Розглянемо питання про отримання частини винагороди за індексацію та за запити
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Розглянемо пул делегацій індексатора
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Розглянемо ліміт делегування
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Поширені запитання та баги
 
 ### Баг в гаманці MetaMask "Pending Transaction"
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From da178635d689b9d7290b9731b3b19569f87853c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:32 -0500
Subject: [PATCH 2751/3820] New translations glossary.mdx (Chinese Simplified)

---
 website/pages/zh/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/zh/resources/glossary.mdx b/website/pages/zh/resources/glossary.mdx
index 987d665b3c69..271ecb32734e 100644
--- a/website/pages/zh/resources/glossary.mdx
+++ b/website/pages/zh/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: 术语汇编
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 7efe17069041a993f5684949e9eb21d35db1b970 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:33 -0500
Subject: [PATCH 2752/3820] New translations delegating.mdx (Chinese
 Simplified)

---
 .../pages/zh/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/zh/resources/roles/delegating.mdx b/website/pages/zh/resources/roles/delegating.mdx
index 1f0d2a45d054..174cd5251221 100644
--- a/website/pages/zh/resources/roles/delegating.mdx
+++ b/website/pages/zh/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: 委托
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## 概述
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - 在 Graph 网络中委托代币的风险
 - 如何计算作为委托人的预期回报
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## 委托风险
 
 下面列出了作为协议中的委托人的主要风险。
 
-### The delegation tax
+### The Delegation Tax
 
 委托人不能因为不良行为而被取消，但对委托有税，以抑制可能损害网络完整性的不良决策。
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### 选择一个为委托人提供公平的奖励分配的值得信赖的索引人
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### 考虑到查询费用的分成和索引费用的分成
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### 考虑索引人委托池
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### 考虑委托容量
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## 委托人常见问题和错误
 
 ### MetaMask“待定交易”错误
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### 示例
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 98c347c3cb8d7d0e016dd003d89739db9c1aee0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:34 -0500
Subject: [PATCH 2753/3820] New translations glossary.mdx (Urdu (Pakistan))

---
 website/pages/ur/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/ur/resources/glossary.mdx b/website/pages/ur/resources/glossary.mdx
index 79b2da2f0e65..bece9e2db4ea 100644
--- a/website/pages/ur/resources/glossary.mdx
+++ b/website/pages/ur/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: لغت
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 9d0442e4ec2975fbece536ca8db5411c85d4b246 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:35 -0500
Subject: [PATCH 2754/3820] New translations delegating.mdx (Urdu (Pakistan))

---
 .../pages/ur/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/ur/resources/roles/delegating.mdx b/website/pages/ur/resources/roles/delegating.mdx
index 274d03e80ef0..b04567a39c2b 100644
--- a/website/pages/ur/resources/roles/delegating.mdx
+++ b/website/pages/ur/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: ڈیلیگیٹنگ
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## جائزہ
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - گراف نیٹ ورک میں ٹوکن ڈیلیگ کرنے کے خطرات
 - بطور ڈیلیگیٹر متوقع واپسی کا حساب کیسے لگائیں
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## ڈیلیگیشن کے خطرات
 
 پروٹوکول میں ڈیلیگیٹر ہونےکے اہم خطرات مندرجہ ذیل ہیں.
 
-### The delegation tax
+### The Delegation Tax
 
 برے رویۓ پر ڈیلیگیٹرز کو نہیں چھوڑا جا سکتا، لیکن ناقص فیصلہ سازی کی حوصلہ شکنی کے لیے ڈیلیگیٹرز پر ٹیکس ہے جو نیٹ ورک کی سالمیت کو نقصان پہنچا سکتا ہے.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### ڈیلیگیٹرز کے لیے منصفانہ انعامی ادائیگی کے ساتھ ایک قابل اعتماد انڈیکسر کا انتخاب کرنا
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### کیوری فیس میں کمی اور انڈیکسنگ کی فیس میں کمی پر غور کرنا
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### انڈیکسر کے ڈیلیگیشن پول پر غور کرنا
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### ڈیلیگیشن کی صلاحیت کو مدنظر رکھتے ہوئے
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## ڈیلیگیٹر کے اکثر پوچھے گئے سوالات اور بگز
 
 ### میٹا ماسک "پینڈنگ ٹرانزیکشن" بگ
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### مثال
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From ff792c5f5dfb8f34c015e15ad5e6fee68eab0486 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:36 -0500
Subject: [PATCH 2755/3820] New translations glossary.mdx (Vietnamese)

---
 website/pages/vi/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/vi/resources/glossary.mdx b/website/pages/vi/resources/glossary.mdx
index fa813b659730..ffcd4bca2eed 100644
--- a/website/pages/vi/resources/glossary.mdx
+++ b/website/pages/vi/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From f0883b38682eb52c57cb5601b52d4ec485c38b3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:37 -0500
Subject: [PATCH 2756/3820] New translations delegating.mdx (Vietnamese)

---
 .../pages/vi/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/vi/resources/roles/delegating.mdx b/website/pages/vi/resources/roles/delegating.mdx
index 977224430174..0746ae38171f 100644
--- a/website/pages/vi/resources/roles/delegating.mdx
+++ b/website/pages/vi/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Tổng quan
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - Rủi ro của việc ủy quyền token trong Mạng The Graph
 - Cách tính lợi nhuận kỳ vọng với tư cách là delegator
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Rủi ro Ủy quyền
 
 Lưu ý quan trọng là mỗi lần bạn ủy quyền, bạn sẽ bị tính phí 0.5%. Nghĩa là nếu bạn đang ủy quyền 1000 GRT, bạn sẽ tự động đốt 5 GRT.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Chọn một indexer đáng tin cậy với phần thưởng hợp lý cho delegator
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Xem xét Phần cắt Phí Truy vấn và Phần cắt Phí indexing
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Xem xét Delegation pool của Indexer
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Xem xét Delegation Capacity (Năng lực Ủy quyền)
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Delegator FAQs and Bugs
 
 ### MetaMask "Pending Transaction" Bug
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Ví dụ
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 3c927cb245181bc17ef6f1d2cf4918d64e3e9a7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:38 -0500
Subject: [PATCH 2757/3820] New translations glossary.mdx (Marathi)

---
 website/pages/mr/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/mr/resources/glossary.mdx b/website/pages/mr/resources/glossary.mdx
index fa813b659730..ffcd4bca2eed 100644
--- a/website/pages/mr/resources/glossary.mdx
+++ b/website/pages/mr/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 73a5788358b6847a150a004fca3afea404837d95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:39 -0500
Subject: [PATCH 2758/3820] New translations delegating.mdx (Marathi)

---
 .../pages/mr/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/mr/resources/roles/delegating.mdx b/website/pages/mr/resources/roles/delegating.mdx
index 694c6c52a9a7..f53ed8a6db03 100644
--- a/website/pages/mr/resources/roles/delegating.mdx
+++ b/website/pages/mr/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## सविश्लेषण
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 वाईट वर्तनासाठी प्रतिनिधींना कमी केले जाऊ शकत नाही, परंतु नेटवर्कच्या अखंडतेला हानी पोहोचवणाऱ्या खराब निर्णयक्षमतेला प्रोत्साहन देण्यासाठी प्रतिनिधींवर कर लावला जातो.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Considering the query fee cut and indexing fee cut
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Considering the Indexer's delegation pool
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Considering the delegation capacity
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Delegator FAQs and Bugs
 
 ### MetaMask "Pending Transaction" Bug
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### उदाहरण
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 5bbd21cf6088e7360588c1863827fe91fee89830 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:40 -0500
Subject: [PATCH 2759/3820] New translations glossary.mdx (Hindi)

---
 website/pages/hi/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/hi/resources/glossary.mdx b/website/pages/hi/resources/glossary.mdx
index ceec54c67cbe..d7c1fd85df2b 100644
--- a/website/pages/hi/resources/glossary.mdx
+++ b/website/pages/hi/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: शब्दकोष
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From 776e0276b28c1918688b55aa33dfdafe6265e5e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:41 -0500
Subject: [PATCH 2760/3820] New translations delegating.mdx (Hindi)

---
 .../pages/hi/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/hi/resources/roles/delegating.mdx b/website/pages/hi/resources/roles/delegating.mdx
index 1334fea687a8..6674e1bae3c2 100644
--- a/website/pages/hi/resources/roles/delegating.mdx
+++ b/website/pages/hi/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## अवलोकन
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-The Graph Network में एक प्रभावशाली Delegator बनने के लिए सीखें।
+## How Does Delegation Work?
 
-Delegator अपने डेलीगेटेड स्टेक के आधार पर सभी Indexer के साथ प्रोटोकॉल की कमाई साझा करते हैं। इसलिए, उन्हें कई कारकों के आधार पर Indexer का चयन करने के लिए अपने सर्वोत्तम विवेक का उपयोग करना चाहिए।
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - ग्राफ़ नेटवर्क में टोकन सौंपने का जोखिम
 - प्रतिनिधि के रूप में अपेक्षित रिटर्न की गणना कैसे करें
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 प्रोटोकॉल में प्रतिनिधि होने के मुख्य जोखिमों की सूची नीचे दी गई है।
 
-### The delegation tax
+### The Delegation Tax
 
 प्रतिनिधियों को खराब व्यवहार के लिए कम नहीं किया जा सकता है, लेकिन खराब निर्णय लेने को हतोत्साहित करने के लिए प्रतिनिधियों पर एक कर है जो नेटवर्क की अखंडता को नुकसान पहुंचा सकता है।
 
@@ -40,25 +68,29 @@ There are three sections in this guide:
 
 - सुरक्षित रहने के लिए, आपको Indexer को डेलीगेट करते समय अपने संभावित रिटर्न की गणना करनी चाहिए। उदाहरण के लिए, आप यह गणना कर सकते हैं कि आपके डेलीगेशन पर 0.5% कर वापस कमाने में कितने दिन लगेंगे।
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### यह क्यों महत्वपूर्ण है?
 
-यदि आप किसी ऐसे Indexer का चयन करते हैं जो विश्वसनीय नहीं है या अच्छा काम नहीं कर रहा है, तो आप डेलीगेट को रद्द करना चाहेंगे। इसका मतलब है कि आप पुरस्कार कमाने के कई अवसर खो देंगे, जो GRT को जलाने के समान बुरा हो सकता है। परिणामस्वरूप, यह अनुशंसा की जाती है कि आप एक Indexer का चयन समझदारी से करें।
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### डेलीगेटर्स के लिए उचित इनाम भुगतान के साथ एक भरोसेमंद इंडेक्सर चुनना
+#### डेलीगेशन पैरामीटर
 
 एक विश्वसनीय Indexer को चुनने के लिए आपको डेलीगेशन पैरामीटर्स को समझना आवश्यक है।
 
-#### डेलीगेशन पैरामीटर
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - यदि किसी Indexer का पुरस्कार कट 100% पर सेट है, तो एक Delegator के रूप में, आपको 0 इंडेक्सिंग पुरस्कार मिलेंगे।
   - यदि इसे 80% पर सेट किया गया है, तो एक Delegator के रूप में, आप 20% प्राप्त करेंगे।
@@ -70,24 +102,25 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-यहाँ आप देख सकते हैं, सही Indexer चुनने के लिए, आपको कई चीजों पर विचार करना होगा।
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- बहुत से Indexers डिस्कॉर्ड में बहुत सक्रिय हैं और आपकी पूछताछ का जवाब देने में खुश होंगे।
-- उनमें से कई महीनों से इंडेक्सिंग कर रहे हैं, और वे Delegators को अच्छा लाभ कमाने में मदद करने के लिए अपना सर्वश्रेष्ठ कर रहे हैं, क्योंकि इससे नेटवर्क की स्वास्थ्य और सफलता में सुधार होता है।
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## यहाँ पर 'Delegators' की अपेक्षित लाभ की गणना की जा रही है।
 
-एक Delegator को एक वापसी निर्धारित करने के लिए निम्नलिखित कारकों पर विचार करना चाहिए:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- एक Indexer की यह क्षमता है कि वह अपने पास उपलब्ध Delegated टोकन का उपयोग कर सके।
-  - यदि एक Indexer सभी उपलब्ध टोकन आवंटित नहीं कर रहा है, तो वे अपने लिए या अपने Delegators के लिए अधिकतम लाभ अर्जित नहीं कर रहे हैं।
-- पहले कुछ दिनों में डेलिगेटिंग पर ध्यान दें।
-  - एक Indexer किसी भी समय 1 से 28 दिनों के बीच एक आवंटन बंद करने और पुरस्कार एकत्र करने का विकल्प चुन सकता है। यह संभव है कि एक Indexer के पास अभी भी बहुत सारे पुरस्कार हों जिन्हें उन्हें एकत्र करना है, इसलिए उनके कुल पुरस्कार कम हो सकते हैं।
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### प्रश्न शुल्क में कटौती और अनुक्रमण शुल्क में कटौती को ध्यान में रखते हुए
 
-आपको एक ऐसा Indexer चुनना चाहिए जो अपनी क्वेरी शुल्क और इंडेक्सिंग शुल्क कटौती को निर्धारित करने में पारदर्शी और ईमानदार हो। इसके बाद, आप पैरामीटर्स कूलडाउन समय को देखना चाहिए कि आपके पास कितना समय बफर है। इसके बाद, अपने प्राप्त पुरस्कारों की गणना करना सरल है।
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 सूत्र है:
 
@@ -95,6 +128,8 @@ Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day u
 
 ### अनुक्रमणिका के प्रतिनिधिमंडल पूल को ध्यान में रखते हुए
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators को प्रतिनिधि पूल में उनके स्वामित्व के अनुपात पर विचार करना चाहिए।
 
 सभी 'प्रतिनिधि पुरस्कार' समान रूप से साझा किए जाते हैं, और पूल में पुनर्संतुलन उस राशि के आधार पर होता है जो Delegator ने पूल में जमा की होती है।
@@ -105,38 +140,11 @@ Delegators को प्रतिनिधि पूल में उनके 
 
 > उपरोक्त सूत्र यह दर्शाता है कि एक Indexer जो केवल 20% को Delegators को प्रदान कर रहा है, एक Indexer की तुलना में बेहतर पुरस्कार प्रदान कर सकता है जो 90% दे रहा है। बस गणना करें ताकि सर्वश्रेष्ठ पुरस्कार निर्धारित हो सके।
 
-### प्रतिनिधिमंडल की क्षमता को ध्यान में रखते हुए
-
-अंत में, प्राधिकरण क्षमता पर विचार करें। वर्तमान में, प्राधिकरण अनुपात 16 पर सेट है।
-
-#### यह क्यों मायने रखता है?
-
-यह मतलब है कि यदि एक Indexer ने 1,000,000 GRT स्टेक किया है, तो उनकी Delegation Capacity 16,000,000 GRT के अधिग्रहित टोकनों की है जिसका वे प्रोटोकॉल में उपयोग कर सकते हैं। इस मात्रा से अधिक कोई भी अधिग्रहित टोकन सभी Delegator पुरस्कारों को पतला कर देगा।
-
-एक Indexer के पास 100,000,000 GRT उनके लिए नामांकित हैं, लेकिन उनकी क्षमता केवल 16,000,000 GRT है। इसका मतलब है कि प्रभावी रूप से, 84,000,000 GRT टोकन उपयोग में नहीं हैं जिससे टोकन कमाई नहीं हो रही है। इसलिए, दोनों Delegators और Indexers उन पुरस्कारों को कम कमा रहे हैं जो वे कमा सकते थे।
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## प्रतिनिधि अक्सर पूछे जाने वाले प्रश्न और बग
 
 ### मेटामास्क "लंबित लेन-देन" बग
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 MetaMask के माध्यम से Indexers को प्रतिनिधित्व देने के प्रयास कभी-कभी विफल हो सकते हैं और इसके परिणामस्वरूप "Pending" या "Queued" लेनदेन के प्रयासों के लिए लंबे समय तक रुकावट हो सकती है।
 
-#### उदाहरण
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 इस बग का एक सरल समाधान ब्राउज़र को पुनः प्रारंभ करना है (उदाहरण के लिए, पता बार में "abort
 " का उपयोग करना), जो सभी पिछले प्रयासों को रद्द कर देगा बिना गैस को वॉलेट से घटाए। कई उपयोगकर्ताओं ने जिन्होंने इस समस्या का सामना किया है, उन्होंने अपने ब्राउज़र को पुनः प्रारंभ करने और 'delegation' करने का प्रयास करने के बाद सफल लेनदेन की रिपोर्ट की है।
-
-## वीडियो गाइड
-
-इस वीडियो गाइड इस पृष्ठ की समीक्षा करता है जबकि UI के साथ बातचीत करता है।
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From b5cf75a60835529e48a7b306180c323e6ec3b556 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:42 -0500
Subject: [PATCH 2761/3820] New translations glossary.mdx (Swahili)

---
 website/pages/sw/resources/glossary.mdx | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/website/pages/sw/resources/glossary.mdx b/website/pages/sw/resources/glossary.mdx
index fa813b659730..ffcd4bca2eed 100644
--- a/website/pages/sw/resources/glossary.mdx
+++ b/website/pages/sw/resources/glossary.mdx
@@ -22,6 +22,8 @@ title: Glossary
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+
 - **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
 - **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.

From f531bd5b1de662dccf333dc474e7728f12f7aba5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 17:45:43 -0500
Subject: [PATCH 2762/3820] New translations delegating.mdx (Swahili)

---
 .../pages/sw/resources/roles/delegating.mdx   | 118 ++++++++++--------
 1 file changed, 63 insertions(+), 55 deletions(-)

diff --git a/website/pages/sw/resources/roles/delegating.mdx b/website/pages/sw/resources/roles/delegating.mdx
index eda60369e00a..55ad58331559 100644
--- a/website/pages/sw/resources/roles/delegating.mdx
+++ b/website/pages/sw/resources/roles/delegating.mdx
@@ -2,35 +2,63 @@
 title: Delegating
 ---
 
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-- They help secure the network without running a Graph Node themselves.
+## Overview
 
-- They earn a portion of an Indexer's query fees and rewards by delegating to them.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
-## How does this work?
+<VideoEmbed youtube="VACg8bitnVc" />
 
-The number of queries an Indexer can process depends on their own stake, **the delegated stake**, and the price the Indexer charges for each query. Therefore, the more stake allocated to an Indexer, the more potential queries an Indexer can process.
+## Benefits of Delegating
 
-## Delegator Guide
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-Learn how to be an effective Delegator in The Graph Network.
+## How Does Delegation Work?
 
-Delegators share the earnings of the protocol alongside all Indexers based on their delegated stake. Therefore, they must use their best judgment to choose Indexers based on multiple factors.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-> Please note this guide does not cover steps such as setting up MetaMask properly. The Ethereum community provides a comprehensive resource regarding wallets through the following link ([source](https://ethereum.org/en/wallets/)).
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-There are three sections in this guide:
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
 
 - The risks of delegating tokens in The Graph Network
 - How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
 
 ## Delegation Risks
 
 Listed below are the main risks of being a Delegator in the protocol.
 
-### The delegation tax
+### The Delegation Tax
 
 Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
 
@@ -40,25 +68,29 @@ As a Delegator, it's important to understand the following:
 
 - In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
 
-### The delegation unbonding period
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens or earn any rewards for 28 days.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Why is this important?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT. As a result, it’s recommended that you choose an Indexer wisely.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
   unbonding period._
 </div>
 
-### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+#### Delegation Parameters
 
 In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
 
-#### Delegation Parameters
-
 - **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
   - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
   - If it is set to 80%, as a Delegator, you will receive 20%.
@@ -70,24 +102,25 @@ In order to understand how to choose a trustworthy Indexer, you need to understa
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
 
-As you can see, in order to choose the right Indexer, you must consider multiple things.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- It is highly recommend that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations and which ones reward Delegators consistently.
-- Many Indexers are very active in Discord and will be happy to answer your questions.
-- Many of them have been Indexing for months, and they are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Calculating Delegators Expected Return
 
-A Delegator must consider the following factors to determine a return:
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-- Consider an Indexer's ability to use the Delegated tokens available to them.
-  - If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Pay attention to the first few days of delegating.
-  - An Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. It is possible that an Indexer might have a lot of rewards they still need to collect, so their total rewards are low.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Considering the query fee cut and indexing fee cut
 
-You should choose an Indexer that is transparent and honest about setting their Query Fee and Indexing Fee Cuts. You should also look at the Parameters Cooldown time to see how much of a time buffer you have. After that is done, it is simple to calculate the amount of rewards you are getting.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 The formula is:
 
@@ -95,6 +128,8 @@ The formula is:
 
 ### Considering the Indexer's delegation pool
 
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
 Delegators should consider the proportion of the Delegation Pool they own.
 
 All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
@@ -105,37 +140,10 @@ This gives the Delegator a share of the pool:
 
 > The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
 
-### Considering the delegation capacity
-
-Finally, consider the delegation capacity. Currently, the Delegation Ratio is set to 16.
-
-#### Why does this matter?
-
-This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
-
-Imagine an Indexer with 100,000,000 GRT delegated to them, but their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. So, both the Delegators and the Indexers are earning less rewards than they could be.
-
-Therefore, a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
-
 ## Delegator FAQs and Bugs
 
 ### MetaMask "Pending Transaction" Bug
 
-1. When I try to delegate my transaction in MetaMask, it appears as "Pending" or "Queued" for longer than expected. What should I do?
-
 At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
 
-#### Example
-
-Let's say you attempt to delegate with an insufficient gas fee relative to the current prices.
-
-- This action can cause the transaction attempt to display as "Pending" in your MetaMask wallet for 15+ minutes. When this happens, you can attempt subsequent transactions, but these will only be processed until the initial transaction is mined because transactions for an address must be processed in order.
-- In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful.
-
 A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
-
-## Video Guide
-
-This video guide reviews this page while interacting with the UI.
-
-<VideoEmbed youtube="2G7S2gdURdc" />

From 55277a4dfd733738a14d116b5a4bb80d72fb2548 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 20:35:03 -0500
Subject: [PATCH 2763/3820] New translations triggers.mdx (Spanish)

---
 website/pages/es/substreams/sps/triggers.mdx | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/es/substreams/sps/triggers.mdx b/website/pages/es/substreams/sps/triggers.mdx
index a923fe40ec78..06b491af3b9d 100644
--- a/website/pages/es/substreams/sps/triggers.mdx
+++ b/website/pages/es/substreams/sps/triggers.mdx
@@ -1,12 +1,12 @@
 ---
-title: Substreams Triggers
+title: Disparadores de Substreams
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Los disparadores personalizados te permiten enviar datos directamente a tu archivo de mapeo del subgrafo y a sus entidades (similares a tablas y campos), permitiendo el uso completo de la capa GraphQL. Al importar las definiciones de Protobuf emitidas por tu módulo de Substreams, puedes recibir y procesar estos datos dentro del manejador de tu subgrafo, garantizando una gestión de datos eficiente y optimizada dentro del marco del subgrafo.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](/substreams/sps/introduction/) to scaffold your first project in the Development Container.
+> Nota: Si aún no lo has hecho, visita una de las guías prácticas que encontrarás aquí (/substreams/sps/introduction/) para estructurar tu primer proyecto en el Contenedor de Desarrollo.
 
-The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+El siguiente código demuestra cómo definir una función 'handleTransactions' en un controlador de subgraph. Esta función recibe bytes sin procesar de Substreams como parámetro y los decodifica en un objeto 'Transactions'. Para cada transacción, se crea una nueva entidad en el subgrafo.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
@@ -28,10 +28,10 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Esto es lo que ves en el archivo mappings.ts:
 
-1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
-2. Looping over the transactions
-3. Create a new subgraph entity for every transaction
+1. Los bytes que contienen los datos de Substreams se decodifican en el objeto 'Transactions' generado, y este objeto se utiliza como cualquier otro objeto de AssemblyScript.
+2. Iterando sobre las transacciones
+3. Crear una nueva entidad de subgrafo para cada transacción.
 
 To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).

From 19e62d3bc0deef4461f9b5763cbc07c9b4383573 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 21 Jan 2025 20:35:05 -0500
Subject: [PATCH 2764/3820] New translations overview.mdx (Chinese Simplified)

---
 website/pages/zh/indexing/overview.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/indexing/overview.mdx b/website/pages/zh/indexing/overview.mdx
index fe2db7b5ddd2..c2a34294f827 100644
--- a/website/pages/zh/indexing/overview.mdx
+++ b/website/pages/zh/indexing/overview.mdx
@@ -2,7 +2,7 @@
 title: Indexing Overview
 ---
 
-索引人是Graph 网络中的节点运营商，他们质押 Graph 通证 (GRT) 以提供索引和查询处理服务。 索引人通过他们的服务赚取查询费和索引奖励。 他们还根据 Cobbs-Douglas 回扣函数从回扣池中赚取收益，该回扣池与所有网络贡献者按他们的工作成比例共享。
+索引人是The Graph 网络中的节点运营商，他们质押 Graph代币(GRT) 以提供索引和查询处理服务。 索引人通过他们的服务赚取查询费和索引奖励。 他们还根据 Cobbs-Douglas 回扣函数从回扣池中赚取收益，该回扣池与所有网络贡献者按他们的工作成比例共享。
 
 抵押在协议中的 GRT 会受到解冻期的影响，如果索引人是恶意的并向应用程序提供不正确的数据或索引不正确，则可能会被削减。 索引人也可以从委托人那里获得委托，为网络做出贡献。
 

From 7226d9b20446135e3ceb71fefb389bfad125cc5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 06:21:25 -0500
Subject: [PATCH 2765/3820] New translations explorer.mdx (Russian)

---
 website/pages/ru/subgraphs/explorer.mdx | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/ru/subgraphs/explorer.mdx b/website/pages/ru/subgraphs/explorer.mdx
index b1882575f782..f5ca733ca11a 100644
--- a/website/pages/ru/subgraphs/explorer.mdx
+++ b/website/pages/ru/subgraphs/explorer.mdx
@@ -72,17 +72,17 @@ This page provides a bird's-eye view of all "participants," which includes every
 - Часть комиссии за запросы — это процент от возвратов комиссии за запросы, который Индексатор оставляет себе при распределении с Делегаторами.
 - Эффективная часть вознаграждения — это доля вознаграждения за индексирование, применяемая к пулу делегирования. Если она отрицательная, это означает, что Индексатор отдаёт часть своих вознаграждений. Если она положительная, это означает, что Индексатор сохраняет часть своих вознаграждений.
 - Оставшееся время восстановления — время, оставшееся до того, как Индексатор сможет изменить вышеуказанные параметры делегирования. Периоды восстановления устанавливаются Индексаторами при обновлении параметров делегирования.
-- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
-- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
-- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
-- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Собственность — это депозитная доля Индексатора, которая может быть урезана за злонамеренное или некорректное поведение.
+- Делегированный стейк — доля Делегаторов, которая может быть распределена Индексатором, но не может быть сокращена.
+- Распределенный стейк — доля, которую Индексаторы активно распределяют между индексируемыми субграфами.
+- Доступная емкость делегирования — объем делегированной доли, которую Индексаторы всё ещё могут получить, прежде чем они будут перераспределены.
 - Максимальная емкость делегирования — максимальная сумма делегированной доли, которую Индексатор может продуктивно принять. Избыточная делегированная ставка не может быть использована для распределения или расчета вознаграждений.
-- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Плата за запросы — это общая сумма комиссий, которую конечные пользователи заплатили за запросы Индексатора за все время.
 - Вознаграждения Индексатора — это общая сумма вознаграждений Индексатора, полученная им и его Делегаторами за все время. Вознаграждения Индексаторов выплачиваются посредством выпуска GRT.
 
-Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+Индексаторы могут получать как комиссии за запросы, так и вознаграждения за индексацию. Фактически это происходит, когда участники сети делегируют GRT Индексатору. Это позволяет Индексаторам получать комиссионные и вознаграждения в зависимости от параметров самого Индексатора.
 
-- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+- Параметры индексирования можно задать, щелкнув мышью в правой части таблицы или перейдя в профиль Индексатора и нажав кнопку «Делегировать».
 
 To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
 
@@ -90,13 +90,13 @@ To learn more about how to become an Indexer, you can take a look at the [offici
 
 #### 2. Кураторы
 
-Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+Кураторы анализируют субграфы, чтобы определить, какие из них имеют наивысшее качество. Найдя потенциально привлекательный субграф, Куратор может курировать его, отправляя сигнал на его кривую связывания. Таким образом, Кураторы сообщают Индексаторам, какие субграфы имеют высокое качество и должны быть проиндексированы.
 
-- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
-  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
-  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+- Кураторами могут быть члены сообщества, потребители данных или даже разработчики субграфов, которые сигнализируют о своих собственных субграфах, внося токены GRT в кривую связывания.
+  - Внося GRT, Кураторы чеканят кураторские акции субграфа. В результате они могут заработать часть комиссий за запросы, сгенерированных субграфом, на который они подали сигнал.
+  - Кривая связывания стимулирует Кураторов отбирать источники данных самого высокого качества.
 
-In the The Curator table listed below you can see:
+В приведенной ниже таблице «Куратор» вы можете увидеть:
 
 - Дату начала курирования
 - Количество GRT, которое было внесено

From c9769e1ca6b8fb60478c34d6e652cd263ca84923 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 07:19:34 -0500
Subject: [PATCH 2766/3820] New translations explorer.mdx (Russian)

---
 website/pages/ru/subgraphs/explorer.mdx | 38 ++++++++++++-------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/website/pages/ru/subgraphs/explorer.mdx b/website/pages/ru/subgraphs/explorer.mdx
index f5ca733ca11a..55b8baf59331 100644
--- a/website/pages/ru/subgraphs/explorer.mdx
+++ b/website/pages/ru/subgraphs/explorer.mdx
@@ -108,22 +108,22 @@ If you want to learn more about the Curator role, you can do so by visiting [off
 
 #### 3. Делегаторы
 
-Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+Делегаторы играют ключевую роль в поддержании безопасности и децентрализации The Graph Network. Они участвуют в сети, делегируя (т. е. «стейкая») токены GRT одному или нескольким индексаторам.
 
-- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
-- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
+- Без Делегаторов Индексаторы с меньшей долей вероятности получат значительные вознаграждения и сборы. Таким образом, Индексаторы привлекают Делегаторов, предлагая им часть вознаграждения за индексацию и комиссию за запросы.
+- Делегаторы выбирают Индексаторов на основе ряда различных переменных, таких как прошлые результаты, ставки вознаграждения за индексирование и снижение платы за запросы.
 - Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
 
 ![Explorer Image 7](/img/Delegation-Overview.png)
 
-In the Delegators table you can see the active Delegators in the community and important metrics:
+В таблице «Делегаторы» Вы можете увидеть активных в сообществе Делегаторов и важные показатели:
 
 - Количество Индексаторов, к которым делегирует Делегатор
 - A Delegator's original delegation
 - Накопленные ими вознаграждения, которые они не вывели из протокола
 - Реализованные вознаграждения, которые они сняли с протокола
 - Общее количество GRT, которое у них имеется в настоящее время в протоколе
-- The date they last delegated
+- Дата, когда они в последний раз делегировали
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
@@ -133,7 +133,7 @@ On this page, you can see global KPIs and have the ability to switch to a per-ep
 
 #### Обзор
 
-The overview section has both all the current network metrics and some cumulative metrics over time:
+В обзорном разделе представлены как все текущие метрики сети, так и некоторые совокупные метрики за определенный период времени:
 
 - Текущая общая доля сети
 - Доля распределяется между Индексаторами и их Делегаторами
@@ -142,7 +142,7 @@ The overview section has both all the current network metrics and some cumulativ
 - Параметры протокола, такие как вознаграждение за курирование, уровень инфляции и т. д
 - Награды и сборы текущей эпохи
 
-A few key details to note:
+Несколько важных деталей, на которые следует обратить внимание:
 
 - **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
 - **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
@@ -159,34 +159,34 @@ A few key details to note:
   - Активная эпоха - это та, в которой Индексаторы в настоящее время выделяют ставки и собирают комиссионные за запросы
   - Эпохи урегулирования — это эпохи, в которых используются государственные каналы. Это означает, что Индексаторы могут столкнуться с сокращением своих GRT, если потребители откроют против них споры.
   - Эпохи распределения - это эпохи, в которых состояния каналов для эпох регулируются, и Индексаторы могут требовать скидки на комиссию за запросы.
-  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+  - Завершенные эпохи — это эпохи, в которых Индексаторы больше не могут заявить возврат комиссии за запросы.
 
 ![Explorer Image 9](/img/Epoch-Stats.png)
 
 ## Ваш профиль пользователя
 
-Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+Ваш личный профиль — это место, где Вы можете видеть свою сетевую активность, независимо от своей роли в сети. Ваш криптокошелек будет действовать как Ваш профиль пользователя, а на панели управления пользователя Вы сможете увидеть следующие вкладки:
 
 ### Обзор профиля
 
-In this section, you can view the following:
+В этом разделе Вы можете увидеть следующее:
 
-- Any of your current actions you've done.
-- Your profile information, description, and website (if you added one).
+- Любое из текущих действий, которые Вы совершили.
+- Данные своего профиля, описание и веб-сайт (если Вы его добавили).
 
 ![Explorer Image 10](/img/Profile-Overview.png)
 
 ### Вкладка "Субграфы"
 
-In the Subgraphs tab, you’ll see your published subgraphs.
+На вкладке «Субграфы» Вы увидите опубликованные вами субграфы.
 
-> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+> Сюда не будут включены субграфы, развернутые с помощью CLI в целях тестирования. Субграфы будут отображаться только после публикации в децентрализованной сети.
 
 ![Explorer Image 11](/img/Subgraphs-Overview.png)
 
 ### Вкладка "Индексирование"
 
-In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+На вкладке «Индексирование» Вы найдете таблицу со всеми активными и прежними распределениями по субграфам. Вы также найдете диаграммы, на которых сможете увидеть и проанализировать свои прошлые результаты в качестве Индексатора.
 
 Этот раздел также будет содержать подробную информацию о Ваших чистых вознаграждениях Индексатора и чистой комиссии за запросы. Вы увидите следующие показатели:
 
@@ -201,9 +201,9 @@ In the Indexing tab, you’ll find a table with all the active and historical al
 
 ### Вкладка "Делегирование"
 
-Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+Делегаторы важны для the Graph Network. Они должны использовать свои знания, чтобы выбрать Индексатора, который обеспечит хороший доход от вознаграждений.
 
-In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+На вкладке «Делегаторы» Вы можете найти подробную информацию о своих активных и прошлых делегированиях, а также показатели Индексаторов, которым Вы делегировали полномочия.
 
 В первой половине страницы Вы можете увидеть диаграмму делегирования, а также диаграмму только вознаграждений. Слева Вы можете увидеть ключевые показатели эффективности, которые отражают Ваши текущие показатели делегирования.
 
@@ -243,7 +243,7 @@ In the Delegators tab, you can find the details of your active and historical de
 
 ![Explorer Image 15](/img/Profile-Settings.png)
 
-As your official portal into the world of decentralized data, Graph Explorer allows you to take a variety of actions, no matter your role in the network. You can get to your profile settings by opening the dropdown menu next to your address, then clicking on the Settings button.
+Являясь Вашим официальным порталом в мир децентрализованных данных, Graph Explorer позволяет Вам выполнять самые разные действия, независимо от Вашей роли в сети. Вы можете перейти к настройкам своего профиля, открыв выпадающее меню рядом со своим адресом и нажав кнопку «Настройки».
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
 
@@ -251,6 +251,6 @@ As your official portal into the world of decentralized data, Graph Explorer all
 
 ### Видео руководство
 
-For a general overview of Graph Explorer, check out the video below:
+Для общего обзора Graph Explorer посмотрите видео ниже:
 
 <VideoEmbed youtube="u224xf7rEBY" />

From e4653e2c040945b66b0a2719a769e7fbbaf28524 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 07:19:35 -0500
Subject: [PATCH 2767/3820] New translations chain-integration-overview.mdx
 (Russian)

---
 website/pages/ru/indexing/chain-integration-overview.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/ru/indexing/chain-integration-overview.mdx b/website/pages/ru/indexing/chain-integration-overview.mdx
index cb7944b336ae..3ee1ef3bc4bc 100644
--- a/website/pages/ru/indexing/chain-integration-overview.mdx
+++ b/website/pages/ru/indexing/chain-integration-overview.mdx
@@ -6,12 +6,12 @@ title: Chain Integration Process Overview
 
 ## Stage 1. Technical Integration
 
-- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Информацию о поддержке `graph-node` для новых чейнов см. на странице [Интеграция новых чейнов](/indexing/new-chain-integration/).
 - Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
 
 ## Stage 2. Integration Validation
 
-- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Команды сотрудничают с разработчиками ядра, Graph Foundation и операторами графических интерфейсов и сетевых шлюзов, такими как [Subgraph Studio](https://thegraph.com/studio/), чтобы обеспечить плавный процесс интеграции. Это предполагает предоставление необходимой серверной инфраструктуры, такой как конечные точки JSON-RPC, Firehose или Substreams, интегрирующей чейны. Команды, желающие избежать самостоятельного размещения такой инфраструктуры, могут использовать для этого сообщество операторов нод (индексаторов) The Graph, в чем может помочь Foundation.
 - Graph Indexers test the integration on The Graph's testnet.
 - Core developers and Indexers monitor stability, performance, and data determinism.
 
@@ -38,7 +38,7 @@ This process is related to the Subgraph Data Service, applicable only to new Sub
 
 This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
 
-### 3. How much time will the process of reaching full protocol support take?
+### 3. Сколько времени займет процесс достижения полной поддержки протокола?
 
 The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
 
@@ -46,4 +46,4 @@ Protocol support for indexing rewards depends on the stakeholders' bandwidth to
 
 ### 4. How will priorities be handled?
 
-Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.
+Подобно пункту #3, это будет зависеть от общей готовности и пропускной способности заинтересованных сторон. Например, новый чейн с совершенно новой реализацией Firehose может занять больше времени, чем интеграции, которые уже прошли испытания или находятся на более поздней стадии процесса управления.

From 8600b85a130b2545d986614a931ef86d6ac14133 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 07:19:36 -0500
Subject: [PATCH 2768/3820] New translations new-chain-integration.mdx
 (Russian)

---
 .../ru/indexing/new-chain-integration.mdx     | 80 +++++++++----------
 1 file changed, 40 insertions(+), 40 deletions(-)

diff --git a/website/pages/ru/indexing/new-chain-integration.mdx b/website/pages/ru/indexing/new-chain-integration.mdx
index 695f07957a69..51afe29b5784 100644
--- a/website/pages/ru/indexing/new-chain-integration.mdx
+++ b/website/pages/ru/indexing/new-chain-integration.mdx
@@ -1,80 +1,80 @@
 ---
-title: New Chain Integration
+title: Интеграция новых чейнов
 ---
 
-Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+Чейны могут обеспечить поддержку субграфов в своей экосистеме, начав новую интеграцию `graph-node`. Субграфы — это мощный инструмент индексирования, открывающий перед разработчиками целый мир возможностей. Graph Node уже индексирует данные из перечисленных здесь чейнов. Если Вы заинтересованы в новой интеграции, для этого существуют 2 стратегии:
 
 1. **EVM JSON-RPC**
-2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+2. **Firehose**: все решения по интеграции Firehose включают Substreams, крупномасштабный механизм потоковой передачи на базе Firehose со встроенной поддержкой `graph-node`, позволяющий выполнять распараллеленные преобразования.
 
-> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+> Обратите внимание на то, что хотя рекомендуемый подход заключается в разработке нового Firehose для всех новых чейнов, он требуется только для чейнов, не поддерживающих EVM.
 
-## Integration Strategies
+## Интеграционные стратегии
 
 ### 1. EVM JSON-RPC
 
-If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+Если блокчейн эквивалентен EVM и клиент/нода предоставляет стандартный API EVM JSON-RPC, Graph Node должен иметь возможность индексировать новый чейн.
 
-#### Testing an EVM JSON-RPC
+#### Тестирование EVM JSON-RPC
 
-For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+Чтобы Graph Node мог принимать данные из чейна EVM, нода RPC должна предоставлять следующие методы EVM JSON-RPC:
 
 - `eth_getLogs`
-- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_call` (для исторических блоков, с EIP-1898 - требуется архивная нода)
 - `eth_getBlockByNumber`
 - `eth_getBlockByHash`
 - `net_version`
-- `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `eth_getTransactionReceipt` в пакетном запросе JSON-RPC
+- `trace_filter` _(необязателен для Graph Node для поддержки обработчиков вызовов)_
 
-### 2. Firehose Integration
+### 2. Интеграция Firehose
 
-[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) — это слой извлечения нового поколения. Он собирает историю в плоских файлах и передает ее в реальном времени. Технология Firehose заменяет эти вызовы API опросов потоком данных с использованием модели push, которая быстрее отправляет данные на ноду индексирования. Это помогает увеличить скорость синхронизации и индексирования.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+Основной метод интеграции Firehose в чейны — использование стратегии опроса RPC. Наш алгоритм опроса предсказывает, когда поступит новый блок, и увеличивает скорость проверки наличия нового блока в ближайшее время, что делает его эффективным решением с очень низкой задержкой. За помощью по интеграции и обслуживанию Firehose обращайтесь к [команде StreamingFast] (https://www.streamingfast.io/firehose-integration-program). Новые чейны и их интеграторы по достоинству оценят [осведомленность о форках](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) и огромные возможности параллельного индексирования, которые Firehose и Substreams привносят в их экосистему.
 
-> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+> ПРИМЕЧАНИЕ: Все интеграции, выполненные командой StreamingFast, включают обслуживание протокола репликации Firehose в кодовой базе чейна. StreamingFast отслеживает любые изменения и выпускает двоичные файлы, когда Вы изменяете код и когда StreamingFast изменяет код. Сюда входит выпуск двоичных файлов Firehose/Substreams для протокола, поддержка модулей Substreams для блочной модели чейна и выпуск двоичных файлов для ноды блокчейна с оснащением инструментами, если это необходимо.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Специальное оснащение Firehose для чейнов EVM (`geth`)
 
-For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+Для чейнов EVM существует более глубокий уровень данных, который может быть достигнут с помощью `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), сотрудничества между Go-Ethereum и StreamingFast, для создания высокопроизводительной и богатой системы отслеживания транзакций. Live Tracer — наиболее комплексное решение, позволяющее получать [Расширенные](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) детали блоков. Это позволяет использовать новые парадигмы индексирования, такие как сопоставление шаблонов событий на основе изменений состояния, вызовов, деревьев вызовов более высокого уровня или запуск событий на основе изменений фактических переменных в смарт-контракте.
 
-![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+![Базовый блок vs Расширенный блок](/img/extended-vs-base-substreams-blocks.png)
 
-> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+> ПРИМЕЧАНИЕ: Для этого улучшения Firehose требуется, чтобы в чейнах использовался движок EVM `geth version 1.13.0` и выше.
 
-## EVM considerations - Difference between JSON-RPC & Firehose
+## Рекомендации по EVM — разница между JSON-RPC & Firehose
 
-While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+Хотя как JSON-RPC, так и Firehose оба подходят для субграфов, Firehose всегда востребован разработчиками, желающими создавать с помощью [Substreams](https://substreams.streamingfast.io). Поддержка Substreams позволяет разработчикам создавать [субграфы на основе субпотоков](/subgraphs/cookbook/substreams-powered-subgraphs/) для нового чейна и потенциально может повысить производительность Ваших субграфов. Кроме того, Firehose — в качестве замены уровня извлечения JSON-RPC `graph-node` — сокращает на 90 % количество вызовов RPC, необходимых для общего индексирования.
 
-- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+- Все эти вызовы `getLogs` и циклические передачи заменяются единым потоком, поступающим в сердце `graph-node`; единой блочной моделью для всех обрабатываемых ею субграфов.
 
-> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+> ПРИМЕЧАНИЕ: Интеграция на основе Firehose для чейнов EVM по-прежнему будет требовать от Индексаторов запуска ноды архива RPC чейна для правильного индексирования субрафов. Это происходит из-за неспособности Firehose предоставить состояние смарт-контракта, обычно доступное с помощью метода RPC `eth_call`. (Стоит напомнить, что `eth_calls` не является хорошей практикой для разработчиков)
 
-## Graph Node Configuration
+## Конфигурация Graph Node
 
-Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+Настроить Graph Node так же просто, как подготовить локальную среду. После того, как Ваша локальная среда настроена, Вы можете протестировать интеграцию, локально развернув субграф.
 
-1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+1. [Клонировать Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Измените [эту строку](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22), включив в неё новое имя сети и URL-адрес, совместимый с EVM JSON-RPC
 
-   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+   > Не меняйте само имя переменной env. Оно должно оставаться `ethereum`, даже если имя сети отличается.
 
-3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+3. Запустите ноду IPFS или используйте ту, которая используется The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
+### Тестирование EVM JSON-RPC посредством локального развертывания субграфа
 
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+1. Установите [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Создайте простой пример субграфа. Несколько вариантов приведены ниже:
+   1. Предварительно упакованные смарт-контракт [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) и субграф являются хорошей отправной точкой
+   2. Загрузите локальный субграф из любого существующего смарт-контракта или среды разработки Solidity [используя Hardhat с плагином Graph](https://github.com/graphprotocol/hardhat-graph)
+3. Адаптируйте полученный `subgraph.yaml`, изменив `dataSources.network` на то же имя, которое ранее было передано в Graph Node.
+4. Создайте свой субграф в Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Опубликуйте свой субграф в Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
 
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
+Graph нода должна синхронизировать развернутый субграф, если нет ошибок. Дайте ему время на синхронизацию, затем отправьте несколько запросов GraphQL на API-эндпоинт, указанный в логах.
 
-## Substreams-powered Subgraphs
+## Субграфы, работающие на основе субпотоков (Substreams)
 
-For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.
+Для интеграции Firehose/Substreams под управлением StreamingFast включена базовая поддержка фундаментальных модулей Substreams (например, декодированные транзакции, логи и события смарт-контрактов) и инструментов генерации кодов Substreams. Эти инструменты позволяют включать [субграфы на базе субпотоков](/substreams/sps/introduction/). Следуйте [Практическому руководству] (https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) и запустите `substreams codegen subgraph`, чтобы самостоятельно испробовать инструменты кодирования.

From e31a5b5babffcb5326006240595043649700ce3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 07:19:38 -0500
Subject: [PATCH 2769/3820] New translations supported-network-requirements.mdx
 (Russian)

---
 .../supported-network-requirements.mdx        | 30 +++++++++----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/ru/indexing/supported-network-requirements.mdx b/website/pages/ru/indexing/supported-network-requirements.mdx
index 21a6f62ebb20..719759b1c8f1 100644
--- a/website/pages/ru/indexing/supported-network-requirements.mdx
+++ b/website/pages/ru/indexing/supported-network-requirements.mdx
@@ -1,18 +1,18 @@
 ---
-title: Supported Network Requirements
+title: Требования к поддерживаемым сетям
 ---
 
-| Сеть      | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
-| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
-| Арбитрум  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
-| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
-| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
-| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
-| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
-| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
-| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
-| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |
+| Сеть      | Гайды                                                                                                                                                                                                                                                                                                     | Системные требования                                                                                                                                                         | Награды за индексирование |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-----------------------: |
+| Арбитрум  | [Гайд по Baremetal](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Гайд по Docker](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                   | 4+ ядраа CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _последнее обновление в августе 2023_                                                          |             ✅             |
+| Avalanche | [Гайд по Docker](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                            | 4 ядра / 8 потоков CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br />_последнее обновление в августе 2023_                                                 |             ✅             |
+| Base      | [Гайд по Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [Гайд по GETH Baremetal](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [Гайд по GETH Docker](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ ядер CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _последнее обновление 14 мая 2024_                                            |             ✅             |
+| Binance   | [Гайд по Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                          | 8 ядер / 16 потоков CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _последнее обновление 22 июня 2024_                                              |             ✅             |
+| Celo      | [Гайд по Docker](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                                 | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br />_последнее обновление в августе 2023_                                                 |             ✅             |
+| Ethereum  | [Гайд по Docker](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                      | Более высокая тактовая частота по сравнению с количеством ядер<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _последнее обновление в августе 2023_ |             ✅             |
+| Fantom    | [Гайд по Docker](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                               | 4 ядра / 8 потоков CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br />_последнее обновление в августе 2023_                                                |             ✅             |
+| Gnosis    | [Гайд по Baremetal](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                                  | 6 ядер / 12 потоков CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br />_последнее обновление в августе 2023_                                                |             ✅             |
+| Linea     | [Гайд по Baremetal](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                          | 4+ ядра CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _последнее обновление 2 апреля 2024_                                                            |             ✅             |
+| Optimism  | [Гайд по Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [Гайд по GETH Baremetal](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [Гайд по GETH Docker](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 ядра / 8 потоков CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br />_последнее обновление в августе 2023_                                                 |             ✅             |
+| Polygon   | [Гайд по Docker](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                              | 16 ядра CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _последнее обновление в августе 2023_                                                          |             ✅             |
+| Scroll    | [Гайд по Baremetal](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Гайд по Docker](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                       | 4 ядра / 8 потоков CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _последнее обновление 3 апреля 2024_                                                    |             ✅             |

From 2992a82eb8f3ff0d8fe519acd759d663e31034bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 07:19:39 -0500
Subject: [PATCH 2770/3820] New translations graphcast.mdx (Russian)

---
 website/pages/ru/indexing/tooling/graphcast.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/indexing/tooling/graphcast.mdx b/website/pages/ru/indexing/tooling/graphcast.mdx
index a49399997208..a3c391cf3e4f 100644
--- a/website/pages/ru/indexing/tooling/graphcast.mdx
+++ b/website/pages/ru/indexing/tooling/graphcast.mdx
@@ -10,7 +10,7 @@ Currently, the cost to broadcast information to other network participants is de
 
 The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
 
-- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Перекрестная проверка целостности данных субграфа в режиме реального времени (Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
 - Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
 - Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
 - Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.

From 84ac745857abb537799e8b54086947865a3c8f0f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 07:19:40 -0500
Subject: [PATCH 2771/3820] New translations tap.mdx (Russian)

---
 website/pages/ru/indexing/tap.mdx | 152 +++++++++++++++---------------
 1 file changed, 76 insertions(+), 76 deletions(-)

diff --git a/website/pages/ru/indexing/tap.mdx b/website/pages/ru/indexing/tap.mdx
index 62ca0e8c561c..fe08a450535a 100644
--- a/website/pages/ru/indexing/tap.mdx
+++ b/website/pages/ru/indexing/tap.mdx
@@ -1,5 +1,5 @@
 ---
-title: TAP Migration Guide
+title: Руководство по миграции TAP
 ---
 
 Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
@@ -27,13 +27,13 @@ For each query, the gateway will send you a `signed receipt` that is stored on y
 
 - Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
 
-### Redeeming RAV
+### Выкуп RAV
 
-As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+При запуске `tap-agent` и `indexer-agent` все будет выполняться автоматически. Ниже приводится подробное описание процесса:
 
-1. An Indexer closes allocation.
+1. Индексатор закрывает аллокацию.
 
-2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+2. `<recently-closed-allocation-buffer> period, tap-agent` принимает все ожидающие поступления для этой конкретной аллокации и запрашивает агрегацию в RAV, помечая её как `last`.
 
 3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
 
@@ -41,72 +41,72 @@ As long as you run `tap-agent` and `indexer-agent`, everything will be executed
 
    - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
 
-## Blockchain Addresses
+## Адреса блокчейна
 
-### Contracts
+### Контракты
 
-| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
-| ------------------- | -------------------------------------------- | -------------------------------------------- |
-| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
-| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
-| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+| Контракт               | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| ---------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP-верификатор        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker    | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Escrow                 | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
 
-### Gateway
+### Шлюз
 
-| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
-| ---------- | --------------------------------------------- | --------------------------------------------- |
-| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
-| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
-| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+| Компонент       | Edge и Node Mainnet (Arbitrum Mainnet)        | Edge и Node Testnet (Arbitrum Sepolia)        |
+| --------------- | --------------------------------------------- | --------------------------------------------- |
+| Отправитель     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Подписанты      | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Агрегатор       | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
 
 ### Требования
 
-In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+Помимо типичных требований для запуска индексатора Вам понадобится конечная точка `tap-escrow-subgraph` для запроса обновлений TAP. Вы можете использовать The Graph Network для запроса или размещения себя на своей `graph-node`.
 
-- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
-- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+- [Субграф Graph TAP Arbitrum Sepolia (для тестовой сети The Graph)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Субграф Graph TAP Arbitrum One (для основной сети The Graph)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
 
-> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+> Примечание: `indexer-agent` в настоящее время не обрабатывает индексирование этого субграфа, как это происходит при развертывании сетевого субграфа. В итоге Вам придется индексировать его вручную.
 
-## Migration Guide
+## Руководство по миграции
 
-### Software versions
+### Версии программного обеспечения
 
-The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+Требуемую версию программного обеспечения можно найти [здесь] (https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitum-one.md#latest-releases).
 
-### Steps
+### Шаги
 
 1. **Indexer Agent**
 
-   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
-   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+   - Следуйте [этому же процессу] (https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-compents).
+   - Укажите новый аргумент `--tap-subgraph-endpoint`, чтобы активировать новые кодовые пути TAP и разрешить выкуп TAP RAV.
 
 2. **Indexer Service**
 
-   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
-   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+   - Полностью замените текущую конфигурацию на [новую службу Индексатора rs](https://github.com/graphprotocol/indexer-rs). Рекомендуется использовать [образ контейнера](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Как и в старой версии, Вы можете легко расположить Indexer Service горизонтально. Он по-прежнему не закреплен.
 
 3. **TAP Agent**
 
-   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Всегда запускайте _один_ единственный экземпляр [TAP Agent](https://github.com/graphprotocol/indexer-rs). Рекомендуется использовать [образ контейнера](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
 
-4. **Configure Indexer Service and TAP Agent**
+4. **Настройка Indexer Service и TAP Agent**
 
-   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+   Конфигурация представляет собой файл TOML, совместно используемый `indexer-service` и `tap-agent`, снабженный аргументом `--config /path/to/config.toml`.
 
-   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+   Ознакомьтесь с полной [конфигурацией](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) и [значениями по умолчанию](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
 
-For minimal configuration, use the following template:
+Для минимальной конфигурации используйте следующий шаблон:
 
 ```bash
-# You will have to change *all* the values below to match your setup.
+# Вам придется изменить *все* приведенные ниже значения, чтобы они соответствовали вашим настройкам.
 #
-# Some of the config below are global graph network values, which you can find here:
+# Некоторые из приведенных ниже конфигураций представляют собой глобальные значения graph network, которые Вы можете найти здесь:
 # <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
 #
-# Pro tip: if you need to load some values from the environment into this config, you
-# can overwrite with environment variables. For example, the following can be replaced
-# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+# Совет профессионала: если Вам нужно загрузить некоторые значения из среды в эту конфигурацию, Вы
+# можете перезаписать их переменными среды. Например, следующее можно заменить
+# на [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
 #
 # [database]
 # postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
@@ -116,78 +116,78 @@ indexer_address = "0x1111111111111111111111111111111111111111"
 operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
 
 [database]
-# The URL of the Postgres database used for the indexer components. The same database
-# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
-# the necessary tables.
+# URL-адрес базы данных Postgres, используемой для компонентов индексатора. Та же база данных,
+# которая используется `indexer-agent`. Ожидается, что `indexer-agent` создаст
+# необходимые таблицы.
 postgres_url = "postgres://postgres@postgres:5432/postgres"
 
 [graph_node]
-# URL to your graph-node's query endpoint
+# URL-адрес конечной точки запроса Вашей graph-node
 query_url = "<http://graph-node:8000>"
-# URL to your graph-node's status endpoint
+# URL-адрес конечной точки статуса Вашей graph-node
 status_url = "<http://graph-node:8000/graphql>"
 
 [subgraphs.network]
-# Query URL for the Graph Network subgraph.
+# URL-адрес запроса для субграфа Graph Network.
 query_url = "<http://example.com/network-subgraph>"
-# Optional, deployment to look for in the local `graph-node`, if locally indexed.
-# Locally indexing the subgraph is recommended.
-# NOTE: Use `query_url` or `deployment_id` only
+# Необязательно, развертывание нужно искать в локальной `graph-node`, если оно локально проиндексировано.
+# Рекомендуется индексировать субграф локально.
+# ПРИМЕЧАНИЕ: используйте только `query_url` или `deployment_id`
 deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
 
 [subgraphs.escrow]
-# Query URL for the Escrow subgraph.
+# URL-адрес запроса для субграфа Escrow.
 query_url = "<http://example.com/network-subgraph>"
-# Optional, deployment to look for in the local `graph-node`, if locally indexed.
-# Locally indexing the subgraph is recommended.
-# NOTE: Use `query_url` or `deployment_id` only
+# Необязательно, развертывание нужно искать в локальной `graph-node`, если оно локально проиндексировано.
+# Рекомендуется индексировать субграф локально.
+# ПРИМЕЧАНИЕ: используйте только `query_url` или `deployment_id`
 deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
 
 [blockchain]
-# The chain ID of the network that the graph network is running on
+# Идентификатор чейна сети, в которой работает the graph network работает на
 chain_id = 1337
-# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+# Контрактный адрес верификатора receipt aggregate voucher (RAV) TAP
 receipts_verifier_address = "0x2222222222222222222222222222222222222222"
 
 ########################################
-# Specific configurations to tap-agent #
+# Специальные настройки для tap-agent #
 ########################################
 [tap]
-# This is the amount of fees you are willing to risk at any given time. For ex.
-# if the sender stops supplying RAVs for long enough and the fees exceed this
-# amount, the indexer-service will stop accepting queries from the sender
-# until the fees are aggregated.
-# NOTE: Use strings for decimal values to prevent rounding errors
-# e.g:
+# Это сумма комиссий, которой вы готовы рискнуть в любой момент времени. Например,
+# если отправитель не совершает поставку RAV достаточно длительное время, и комиссии превышают это значение
+# суммарно, служба-индексатор перестанет принимать запросы от отправителя
+# до тех пор, пока комиссии не будут суммированы.
+# ПРИМЕЧАНИЕ: Используйте строки для десятичных значений, чтобы избежать ошибок округления
+# например:
 # max_amount_willing_to_lose_grt = "0.1"
 max_amount_willing_to_lose_grt = 20
 
 [tap.sender_aggregator_endpoints]
-# Key-Value of all senders and their aggregator endpoints
-# This one below is for the E&N testnet gateway for example.
+# Ключ-значение всех отправителей и их конечных точек агрегатора
+# Ниже приведен пример шлюза тестовой сети E&N.
 0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
 ```
 
 Примечания:
 
-- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
-- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+- Значения для `tap.sender_aggregator_endpoints` можно найти в [разделе шлюза](/indexing/tap/#gateway).
+- Значения для `blockchain.receipts_verifier_address` должны использоваться в соответствии с [разделом Адреса блокчейна](/indexing/tap/#contracts) с использованием соответствующего идентификатора чейна.
 
-**Log Level**
+**Уровень лога**
 
-- You can set the log level by using the `RUST_LOG` environment variable.
-- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+- Вы можете установить уровень лога, используя переменную среды RUST_LOG.
+- Рекомендуется установить для него значение `RUST_LOG=indexer_tap_agent=debug,info`.
 
-## Monitoring
+## Мониторинг
 
-### Metrics
+### Метрики
 
-All components expose the port 7300 to be queried by prometheus.
+Все компоненты предоставляют порт 7300 для запроса Prometheus.
 
-### Grafana Dashboard
+### Графический интерфейс Grafana
 
-You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+Вы можете скачать [Графический интерфейс Grafana](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) и импортировать.
 
-### Launchpad
+### Панель запуска
 
-Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)
+В настоящее время существует WIP-версия `indexer-rs` и `tap-agent`, которую можно найти [здесь](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From fe119c1edf3085990c05d88082cdec570a751cbd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 07:19:42 -0500
Subject: [PATCH 2772/3820] New translations overview.mdx (Russian)

---
 website/pages/ru/indexing/overview.mdx | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/website/pages/ru/indexing/overview.mdx b/website/pages/ru/indexing/overview.mdx
index c6255dfc3d1c..24d129f62360 100644
--- a/website/pages/ru/indexing/overview.mdx
+++ b/website/pages/ru/indexing/overview.mdx
@@ -2,7 +2,7 @@
 title: Indexing Overview
 ---
 
-Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+Индексаторы — это операторы нод в сети The Graph, которые стейкают токены Graph (GRT) для предоставления услуг индексирования и обработки запросов. Индексаторы получают оплату за запросы и вознаграждение за свои услуги индексирования. Они также получают комиссию за запросы, которая возвращаются в соответствии с экспоненциальной функцией возврата.
 
 Токены GRT, которые застейканы в протоколе, подлежат периоду "оттаивания" и могут быть срезаны, если индексаторы являются вредоносными и передают неверные данные приложениям или если они некорректно осуществляют индексирование. Индексаторы также получают вознаграждение за делегированный стейк от делегаторов, внося свой вклад в работу сети.
 
@@ -85,7 +85,7 @@ Disputes can be viewed in the UI in an Indexer's profile page under the `Dispute
 
 Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
 
-Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+После закрытия аллокации Индексатор может потребовать возврат. После клейма возмещение комиссии за запрос распределяются между Индексатором и его Делегаторами на основе снижения платы за запрос и экспоненциальной функции возмещения.
 
 ### Что такое query fee cut и indexing reward cut?
 
@@ -127,7 +127,7 @@ The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that
 
 - **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
 
-## Infrastructure
+## Инфраструктура
 
 At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
 
@@ -349,7 +349,7 @@ cargo run -p graph-node --release -- \
 1. Клонируйте Graph Node и перейдите в директорию Docker:
 
 ```sh
-git clone https://github.com/graphprotocol/graph-node
+git clone http://github.com/graphprotocol/graph-node
 cd graph-node/docker
 ```
 
@@ -752,7 +752,7 @@ indexer cost set model my_model.agora
 
 ### Стейкинг в протоколе
 
-The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+Первыми шагами для участия в сети в качестве Индексатора являются утверждение протокола, размещение средств и (по желанию) настройка адреса оператора для повседневного взаимодействия с протоколом.
 
 > Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
 
@@ -794,21 +794,21 @@ Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexi
 setDelegationParameters(950000, 600000, 500)
 ```
 
-### Setting delegation parameters
+### Настройка параметров делегирования
 
 The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
 
-### How to set delegation parameters
+### Как настроить параметры делегирования
 
-To set the delegation parameters using Graph Explorer interface, follow these steps:
+Чтобы задать параметры делегирования с помощью интерфейса Graph Explorer, выполните следующие действия:
 
 1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
-2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
-3. Connect the wallet you have as a signer.
-4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
-5. Submit the transaction to the network.
+2. Подключите свой кошелек. Выберите мультиподпись (например, Gnosis Safe), а затем выберите майннет. Примечание: Вам нужно будет повторить этот процесс для Arbitrum One.
+3. Подключите кошелек, который используется для подписания транзакций.
+4. Перейдите в раздел «Настройки» и выберите «Параметры делегирования». Эти параметры должны быть настроены так, чтобы достичь эффективного процента комиссии в желаемом диапазоне. После ввода значений в предоставленные поля интерфейс автоматически рассчитает эффективную комиссию. При необходимости скорректируйте эти значения, чтобы достичь желаемого процента.
+5. Отправьте транзакцию в сеть.
 
-> Note: This transaction will need to be confirmed by the multisig wallet signers.
+> Примечание: эта транзакция должна быть подтверждена подписантами кошелька с мультиподписью.
 
 ### Срок существования аллокации
 

From aa1f6a340b2e6f9934b05aba50d7b72a80046161 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 07:19:43 -0500
Subject: [PATCH 2773/3820] New translations benefits.mdx (Russian)

---
 website/pages/ru/resources/benefits.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ru/resources/benefits.mdx b/website/pages/ru/resources/benefits.mdx
index 07788994cd81..11a74345eaf1 100644
--- a/website/pages/ru/resources/benefits.mdx
+++ b/website/pages/ru/resources/benefits.mdx
@@ -34,7 +34,7 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 |   Время разработки<sup>†</sup>  |               $400 в месяц              | Никто, встроен в сеть с глобально распределенными индексаторами |
 |         Запросы в месяц         |  Ограничен возможностями инфраструктуры |                       100,000 (Free Plan)                       |
 |     Стоимость одного запроса    |                    $0                   |                          $0<sup>‡</sup>                         |
-|          Infrastructure         |             Централизованная            |                        Децентрализованная                       |
+|          Инфраструктура         |             Централизованная            |                        Децентрализованная                       |
 |   Географическая избыточность   |   $750+ за каждую дополнительную ноду   |                             Включено                            |
 |     Время безотказной работы    |               Варьируется               |                              99.9%+                             |
 |    Общие ежемесячные расходы    | <span className="highlight-row" />$750+ |                                $0                               |
@@ -48,7 +48,7 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 |   Время разработки<sup>†</sup>  |                          $800 в месяц                         | Никто, встроен в сеть с глобально распределенными индексаторами |
 |         Запросы в месяц         |             Ограничен возможностями инфраструктуры            |                            ~3,000,000                           |
 |     Стоимость одного запроса    |                               $0                              |                             $0.00004                            |
-|          Infrastructure         |                        Централизованная                       |                        Децентрализованная                       |
+|          Инфраструктура         |                        Централизованная                       |                        Децентрализованная                       |
 |        Инженерные расходы       |                           $200 в час                          |                             Включено                            |
 |   Географическая избыточность   | общие затраты на каждую дополнительную ноду составляют $1,200 |                             Включено                            |
 |     Время безотказной работы    |                          Варьируется                          |                              99.9%+                             |
@@ -64,7 +64,7 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 |   Время разработки<sup>†</sup>  |                   $6,000 или больше в месяц                   | Никто, встроен в сеть с глобально распределенными индексаторами |
 |         Запросы в месяц         |             Ограничен возможностями инфраструктуры            |                           ~30,000,000                           |
 |     Стоимость одного запроса    |                               $0                              |                             $0.00004                            |
-|          Infrastructure         |                        Централизованная                       |                        Децентрализованная                       |
+|          Инфраструктура         |                        Централизованная                       |                        Децентрализованная                       |
 |   Географическая избыточность   | общие затраты на каждую дополнительную ноду составляют $1,200 |                             Включено                            |
 |     Время безотказной работы    |                          Варьируется                          |                              99.9%+                             |
 |    Общие ежемесячные расходы    |          <span className="highlight-row" /> $11,000+          |                              $1,200                             |

From 2a9d9cf2fdc8bcd417aef06239f00c64906df3ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 08:33:08 -0500
Subject: [PATCH 2774/3820] New translations unit-testing-framework.mdx
 (German)

---
 .../de/subgraphs/developing/creating/unit-testing-framework.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx
index 0bfec04ba128..326dfb01edf0 100644
--- a/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/de/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -52,7 +52,7 @@ sudo apt install postgresql
 Sie können Matchstick auf WSL sowohl mit dem Docker-Ansatz als auch mit dem binären Ansatz verwenden. Da WSL ein wenig knifflig sein kann, hier ein paar Tipps, falls Sie auf Probleme stoßen wie
 
 ```
-static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
+static BYTES = Symbol(„Bytes“) SyntaxError: Unerwartetes Token =
 ```
 
 oder

From fbb7eb42a01fe7a67d44b247eb890c462cc80dee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 08:33:09 -0500
Subject: [PATCH 2775/3820] New translations tap.mdx (Russian)

---
 website/pages/ru/indexing/tap.mdx | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/ru/indexing/tap.mdx b/website/pages/ru/indexing/tap.mdx
index fe08a450535a..754c916ca348 100644
--- a/website/pages/ru/indexing/tap.mdx
+++ b/website/pages/ru/indexing/tap.mdx
@@ -2,30 +2,30 @@
 title: Руководство по миграции TAP
 ---
 
-Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+Узнайте о новой платежной системе The Graph, **Timeline Aggregation Protocol, TAP**. Эта система обеспечивает быстрые и эффективные микротранзакции с минимальным уровнем доверия.
 
 ## Обзор
 
-[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) — это полная замена существующей в настоящее время платежной системы Scalar. Она предоставляет следующие ключевые функции:
 
-- Efficiently handles micropayments.
-- Adds a layer of consolidations to onchain transactions and costs.
-- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
-- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+- Эффективно обрабатывает микроплатежи.
+- Добавляет уровень консолидации к транзакциям и затратам ончейна.
+- Позволяет Индексаторам управлять поступлениями и платежами, гарантируя оплату запросов.
+- Обеспечивает децентрализованные, не требующие доверия шлюзы и повышает производительность `indexer-service` для нескольких отправителей.
 
 ## Специфические особенности
 
-TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+TAP позволяет отправителю совершать несколько платежей получателю, **TAP Receipts**, который объединяет эти платежи в один платеж, **Receipt Aggregate Voucher**, также известный как **RAV**. Затем этот агрегированный платеж можно проверить в блокчейне, что сокращает количество транзакций и упрощает процесс оплаты.
 
-For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+Для каждого запроса шлюз отправит вам `signed receipt`, который будет сохранен в Вашей базе данных. Затем эти запросы будут агрегированы `tap-agent` через запрос. После этого Вы получите RAV. Вы можете обновить RAV, отправив ему новые квитанции, что приведет к генерации нового RAV с увеличенным значением.
 
-### RAV Details
+### Подробнее о RAV
 
-- It’s money that is waiting to be sent to the blockchain.
+- Это денежные средства, которые ждут отправки в блокчейн.
 
-- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+- Он будет продолжать отправлять запросы на агрегирование и гарантировать, что общая стоимость неагрегированных поступлений не превысит `amount willing to lose` (сумму, которую мы готовы потерять).
 
-- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+- Каждый RAV можно выкупить один раз в контрактах, поэтому они отправляются после закрытия аллокации.
 
 ### Выкуп RAV
 
@@ -35,11 +35,11 @@ For each query, the gateway will send you a `signed receipt` that is stored on y
 
 2. `<recently-closed-allocation-buffer> period, tap-agent` принимает все ожидающие поступления для этой конкретной аллокации и запрашивает агрегацию в RAV, помечая её как `last`.
 
-3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+3. `indexer-agent` берет все последние RAVS и отправляет запросы на выкуп в блокчейн, который обновит значение `redeem_at`.
 
-4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+4. В течение периода `<finality-time>` `indexer-agent` отслеживает, происходят ли в блокчейне какие-либо реорганизации, которые отменяют транзакцию.
 
-   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+   - Если он был отменён, RAV повторно отправляется в блокчейн. Если он не был отменён, он помечается как `final`.
 
 ## Адреса блокчейна
 

From 9805058e178458760a36d4d49d7880d4162e0487 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 08:33:10 -0500
Subject: [PATCH 2776/3820] New translations multiple-networks.mdx (German)

---
 .../developing/deploying/multiple-networks.mdx       | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx
index 4f7dcd3864e8..b466597d05ec 100644
--- a/website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx
+++ b/website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx
@@ -1,16 +1,16 @@
 ---
-title: Deploying a Subgraph to Multiple Networks
+title: Bereitstellen eines Subgraphen in mehreren Netzen
 ---
 
-This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+Auf dieser Seite wird erklärt, wie man einen Subgraphen in mehreren Netzwerken bereitstellt. Um einen Subgraphen bereitzustellen, müssen Sie zunächst die [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) installieren. Wenn Sie noch keinen Subgraphen erstellt haben, lesen Sie [Erstellen eines Subgraphen](/developing/creating-a-subgraph/).
 
-## Deploying the subgraph to multiple networks
+## Breitstellen des Subgraphen in mehreren Netzen
 
-In some cases, you will want to deploy the same subgraph to multiple networks without duplicating all of its code. The main challenge that comes with this is that the contract addresses on these networks are different.
+In manchen Fällen möchten Sie denselben Subgraph in mehreren Netzen bereitstellen, ohne den gesamten Code zu duplizieren. Die größte Herausforderung dabei ist, dass die Vertragsadressen in diesen Netzen unterschiedlich sind.
 
-### Using `graph-cli`
+### Verwendung von `graph-cli`
 
-Both `graph build` (since `v0.29.0`) and `graph deploy` (since `v0.32.0`) accept two new options:
+Sowohl `graph build` (seit `v0.29.0`) als auch `graph deploy` (seit `v0.32.0`) akzeptieren zwei neue Optionen:
 
 ```sh
 Options:

From 40aa8e53beeb49c40e2dc5c05eac5f4902204301 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 08:33:16 -0500
Subject: [PATCH 2777/3820] New translations overview.mdx (Chinese Simplified)

---
 website/pages/zh/indexing/overview.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/zh/indexing/overview.mdx b/website/pages/zh/indexing/overview.mdx
index c2a34294f827..f7bde98097b4 100644
--- a/website/pages/zh/indexing/overview.mdx
+++ b/website/pages/zh/indexing/overview.mdx
@@ -1,5 +1,5 @@
 ---
-title: Indexing Overview
+title: 索引概述
 ---
 
 索引人是The Graph 网络中的节点运营商，他们质押 Graph代币(GRT) 以提供索引和查询处理服务。 索引人通过他们的服务赚取查询费和索引奖励。 他们还根据 Cobbs-Douglas 回扣函数从回扣池中赚取收益，该回扣池与所有网络贡献者按他们的工作成比例共享。
@@ -20,7 +20,7 @@ title: Indexing Overview
 
 **Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
 
-**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+**索引奖励** - 通过 3% 的年度协议范围通货膨胀生成，索引奖励分配给为网络索引子图部署的索引人。
 
 ### 索引奖励如何分配？
 
@@ -735,9 +735,9 @@ default => 0.1 * $SYSTEM_LOAD;
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### 应用成本模式
 

From da6dda8f90e8a92450aa0f4c39a7632b6390df87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 10:11:52 -0500
Subject: [PATCH 2778/3820] New translations multiple-networks.mdx (German)

---
 .../deploying/multiple-networks.mdx           | 84 +++++++++----------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx
index b466597d05ec..7bc4c42301c5 100644
--- a/website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx
+++ b/website/pages/de/subgraphs/developing/deploying/multiple-networks.mdx
@@ -13,25 +13,25 @@ In manchen Fällen möchten Sie denselben Subgraph in mehreren Netzen bereitstel
 Sowohl `graph build` (seit `v0.29.0`) als auch `graph deploy` (seit `v0.32.0`) akzeptieren zwei neue Optionen:
 
 ```sh
-Options:
+Optionen:
 
       ...
-      --network <name>          Network configuration to use from the networks config file
-      --network-file <path>     Networks config file path (default: "./networks.json")
+      --network <name>          Netzwerkkonfiguration, die aus der Netzwerkkonfigurationsdatei verwendet werden soll
+      --network-file <path>     Netzwerkkonfigurationsdateipfad (Standard: „./networks.json“)
 ```
 
-You can use the `--network` option to specify a network configuration from a `json` standard file (defaults to `networks.json`) to easily update your subgraph during development.
+Sie können die Option `--network` verwenden, um eine Netzwerkkonfiguration aus einer `json`-Standarddatei (standardmäßig `networks.json`) anzugeben, um Ihren Subgraphen während der Entwicklung einfach zu aktualisieren.
 
-> Note: The `init` command will now auto-generate a `networks.json` based on the provided information. You will then be able to update existing or add additional networks.
+> Hinweis: Der Befehl `init` generiert nun automatisch eine `networks.json` auf der Grundlage der angegebenen Informationen. Sie können dann bestehende Netzwerke aktualisieren oder zusätzliche Netzwerke hinzufügen.
 
-If you don't have a `networks.json` file, you'll need to manually create one with the following structure:
+Wenn Sie keine \`networks.json'-Datei haben, müssen Sie manuell eine Datei mit der folgenden Struktur erstellen:
 
 ```json
 {
-    "network1": { // the network name
-        "dataSource1": { // the dataSource name
-            "address": "0xabc...", // the contract address (optional)
-            "startBlock": 123456 // the startBlock (optional)
+    "network1": { // der Netzwerkname
+        "dataSource1": { // der dataSource-Name
+            "address": "0xabc...", // die Vertragsadresse (optional)
+            "startBlock": 123456 // der startBlock (optional)
         },
         "dataSource2": {
             "address": "0x123...",
@@ -52,9 +52,9 @@ If you don't have a `networks.json` file, you'll need to manually create one wit
 }
 ```
 
-> Note: You don't have to specify any of the `templates` (if you have any) in the config file, only the `dataSources`. If there are any `templates` declared in the `subgraph.yaml` file, their network will be automatically updated to the one specified with the `--network` option.
+> Hinweis: Sie müssen keine `templates` (falls Sie welche haben) in der Konfigurationsdatei angeben, nur die `dataSources`. Wenn in der Datei `subgraph.yaml` irgendwelche `templates` deklariert sind, wird ihr Netzwerk automatisch auf das mit der Option `--network` angegebene aktualisiert.
 
-Now, let's assume you want to be able to deploy your subgraph to the `mainnet` and `sepolia` networks, and this is your `subgraph.yaml`:
+Nehmen wir an, Sie möchten Ihren Subgraphen in den Netzwerken `mainnet` und `sepolia` einsetzen, und dies ist Ihre `subgraph.yaml`:
 
 ```yaml
 # ...
@@ -69,7 +69,7 @@ dataSources:
       kind: ethereum/events
 ```
 
-This is what your networks config file should look like:
+So sollte Ihre Netzwerkkonfigurationsdatei aussehen:
 
 ```json
 {
@@ -86,17 +86,17 @@ This is what your networks config file should look like:
 }
 ```
 
-Now we can run one of the following commands:
+Jetzt können wir einen der folgenden Befehle ausführen:
 
 ```sh
-# Using default networks.json file
+# Verwendung der Standarddatei networks.json
 yarn build --network sepolia
 
-# Using custom named file
+# Verwendung einer benutzerdefinierten Datei
 yarn build --network sepolia --network-file path/to/config
 ```
 
-The `build` command will update your `subgraph.yaml` with the `sepolia` configuration and then re-compile the subgraph. Your `subgraph.yaml` file now should look like this:
+Der Befehl `build` aktualisiert die Datei `subgraph.yaml` mit der `sepolia`-Konfiguration und kompiliert den Subgraphen neu. Ihre `subgraph.yaml` Datei sollte nun wie folgt aussehen:
 
 ```yaml
 # ...
@@ -111,23 +111,23 @@ dataSources:
       kind: ethereum/events
 ```
 
-Now you are ready to `yarn deploy`.
+Jetzt sind Sie bereit für `yarn deploy`.
 
-> Note: As mentioned earlier, since `graph-cli 0.32.0` you can directly run `yarn deploy` with the `--network` option:
+> Anmerkung: Wie bereits erwähnt, können Sie seit `graph-cli 0.32.0` direkt `yarn deploy` mit der Option `--network` ausführen:
 
 ```sh
-# Using default networks.json file
+# Verwendung der Standarddatei networks.json
 yarn deploy --network sepolia
 
-# Using custom named file
+# Verwendung einer benutzerdefinierten Datei
 yarn deploy --network sepolia --network-file path/to/config
 ```
 
-### Using subgraph.yaml template
+### Verwendung der Vorlage subgraph.yaml
 
-One way to parameterize aspects like contract addresses using older `graph-cli` versions is to generate parts of it with a templating system like [Mustache](https://mustache.github.io/) or [Handlebars](https://handlebarsjs.com/).
+Eine Möglichkeit, Aspekte wie Vertragsadressen mit älteren `graph-cli` Versionen zu parametrisieren, besteht darin, Teile davon mit einem Templating-System wie [Mustache](https://mustache.github.io/) oder [Handlebars](https://handlebarsjs.com/) zu generieren.
 
-To illustrate this approach, let's assume a subgraph should be deployed to mainnet and Sepolia using different contract addresses. You could then define two config files providing the addresses for each network:
+Zur Veranschaulichung dieses Ansatzes nehmen wir an, dass ein Subgraph im Mainnet und in Sepolia mit unterschiedlichen Vertragsadressen bereitgestellt werden soll. Sie könnten dann zwei Konfigurationsdateien definieren, die die Adressen für jedes Netz bereitstellen:
 
 ```json
 {
@@ -136,7 +136,7 @@ To illustrate this approach, let's assume a subgraph should be deployed to mainn
 }
 ```
 
-and
+und
 
 ```json
 {
@@ -145,7 +145,7 @@ and
 }
 ```
 
-Along with that, you would substitute the network name and addresses in the manifest with variable placeholders `{{network}}` and `{{address}}` and rename the manifest to e.g. `subgraph.template.yaml`:
+Dazu ersetzen Sie den Netzwerknamen und die Adressen im Manifest durch die variablen Platzhalter `{{network}}` und `{{address}}` und benennen Sie das Manifest z.B. in `subgraph.template.yaml` um:
 
 ```yaml
 # ...
@@ -162,7 +162,7 @@ dataSources:
       kind: ethereum/events
 ```
 
-In order to generate a manifest to either network, you could add two additional commands to `package.json` along with a dependency on `mustache`:
+Um ein Manifest für eines der beiden Netzwerke zu erstellen, können Sie zwei zusätzliche Befehle in die `package.json` einfügen, zusammen mit einer Abhängigkeit von `mustache`:
 
 ```json
 {
@@ -179,7 +179,7 @@ In order to generate a manifest to either network, you could add two additional
 }
 ```
 
-To deploy this subgraph for mainnet or Sepolia you would now simply run one of the two following commands:
+Um diesen Subgraphen für Mainnet oder Sepolia einzusetzen, führen Sie nun einfach einen der beiden folgenden Befehle aus:
 
 ```sh
 # Mainnet:
@@ -189,29 +189,29 @@ yarn prepare:mainnet && yarn deploy
 yarn prepare:sepolia && yarn deploy
 ```
 
-A working example of this can be found [here](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
+Ein funktionierendes Datenbeispiel hierfür finden Sie [hier](https://github.com/graphprotocol/example-subgraph/tree/371232cf68e6d814facf5e5413ad0fef65144759).
 
-**Note:** This approach can also be applied to more complex situations, where it is necessary to substitute more than contract addresses and network names or where generating mappings or ABIs from templates as well.
+**Hinweis:** Dieser Ansatz kann auch auf komplexere Situationen angewandt werden, in denen es notwendig ist, mehr als nur Vertragsadressen und Netzwerknamen zu ersetzen, oder in denen auch Mappings oder ABIs aus Vorlagen erzeugt werden.
 
-This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+Dies gibt Ihnen den `chainHeadBlock`, den Sie mit dem `latestBlock` Ihres Subgraphen vergleichen können, um zu prüfen, ob er im Rückstand ist. `synced` gibt Auskunft darüber, ob der Subgraph jemals zur Kette aufgeschlossen hat. `health` kann derzeit die Werte `healthy` annehmen, wenn keine Fehler aufgetreten sind, oder `failed`, wenn es einen Fehler gab, der den Fortschritt des Subgraphen aufgehalten hat. In diesem Fall können Sie das Feld `fatalError` auf Details zu diesem Fehler überprüfen.
 
-## Subgraph Studio subgraph archive policy
+## Subgraph Studio Subgraphen-Archivierungsrichtlinie
 
-A subgraph version in Studio is archived if and only if it meets the following criteria:
+Eine Subgraph-Version in Studio wird nur dann archiviert, wenn sie die folgenden Kriterien erfüllt:
 
-- The version is not published to the network (or pending publish)
-- The version was created 45 or more days ago
-- The subgraph hasn't been queried in 30 days
+- Die Version ist nicht im Netz veröffentlicht (oder steht zur Veröffentlichung an)
+- Die Version wurde vor 45 oder mehr Tagen erstellt
+- Der Subgraph ist seit 30 Tagen nicht mehr abgefragt worden
 
-In addition, when a new version is deployed, if the subgraph has not been published, then the N-2 version of the subgraph is archived.
+Wenn eine neue Version bereitgestellt wird und der Subgraph noch nicht veröffentlicht wurde, wird außerdem die Version N-2 des Subgraphen archiviert.
 
-Every subgraph affected with this policy has an option to bring the version in question back.
+Jeder Subgraph, der von dieser Richtlinie betroffen ist, hat die Möglichkeit, die betreffende Version zurückzubringen.
 
-## Checking subgraph health
+## Überprüfung des Zustands eines Subgraphen
 
-If a subgraph syncs successfully, that is a good sign that it will continue to run well forever. However, new triggers on the network might cause your subgraph to hit an untested error condition or it may start to fall behind due to performance issues or issues with the node operators.
+Wenn ein Subgraph erfolgreich synchronisiert wird, ist das ein gutes Zeichen dafür, dass er für immer gut laufen wird. Neue Auslöser im Netzwerk könnten jedoch dazu führen, dass Ihr Subgraph auf eine ungetestete Fehlerbedingung stößt, oder er könnte aufgrund von Leistungsproblemen oder Problemen mit den Knotenbetreibern ins Hintertreffen geraten.
 
-Graph Node exposes a GraphQL endpoint which you can query to check the status of your subgraph. On the hosted service, it is available at `https://api.thegraph.com/index-node/graphql`. On a local node, it is available on port `8030/graphql` by default. The full schema for this endpoint can be found [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Here is an example query that checks the status of the current version of a subgraph:
+Graph Node stellt einen GraphQL-Endpunkt zur Verfügung, den Sie abfragen können, um den Status Ihres Subgraphen zu überprüfen. Auf dem gehosteten Dienst ist er unter `https://api.thegraph.com/index-node/graphql` verfügbar. Auf einem lokalen Knoten ist er standardmäßig auf Port `8030/graphql` verfügbar. Das vollständige Schema für diesen Endpunkt finden Sie [hier](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql). Hier ist ein Datenbeispiel für eine Abfrage, die den Status der aktuellen Version eines Subgraphen überprüft:
 
 ```graphql
 {
@@ -238,4 +238,4 @@ Graph Node exposes a GraphQL endpoint which you can query to check the status of
 }
 ```
 
-This will give you the `chainHeadBlock` which you can compare with the `latestBlock` on your subgraph to check if it is running behind. `synced` informs if the subgraph has ever caught up to the chain. `health` can currently take the values of `healthy` if no errors occurred, or `failed` if there was an error which halted the progress of the subgraph. In this case, you can check the `fatalError` field for details on this error.
+Dies gibt Ihnen den `chainHeadBlock`, den Sie mit dem `latestBlock` Ihres Subgraphen vergleichen können, um zu prüfen, ob er im Rückstand ist. `synced` gibt Auskunft darüber, ob der Subgraph jemals zur Kette aufgeschlossen hat. `health` kann derzeit die Werte `healthy` annehmen, wenn keine Fehler aufgetreten sind, oder `failed`, wenn es einen Fehler gab, der den Fortschritt des Subgraphen aufgehalten hat. In diesem Fall können Sie das Feld `fatalError` auf Details zu diesem Fehler überprüfen.

From b4f0cac0736a5349694e5d57f485a00e8fa6b5ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 10:11:56 -0500
Subject: [PATCH 2779/3820] New translations overview.mdx (Chinese Simplified)

---
 website/pages/zh/indexing/overview.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/zh/indexing/overview.mdx b/website/pages/zh/indexing/overview.mdx
index f7bde98097b4..9e54f5e3fa4c 100644
--- a/website/pages/zh/indexing/overview.mdx
+++ b/website/pages/zh/indexing/overview.mdx
@@ -40,7 +40,7 @@ Numerous tools have been created by the community for calculating rewards; you'l
 
 The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
 
-许多社区制作的仪表板包含悬而未决的奖励值，通过以下步骤可以很容易地手动检查这些值:
+许多社区制作的控制板包含悬而未决的奖励值，通过以下步骤可以很容易地手动检查这些值:
 
 1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
 
@@ -71,7 +71,7 @@ Use Etherscan to call `getRewards()`:
 
 ### 争议是什么？ 在哪里可以查看？
 
-在争议期间，索引人的查询和分配都可以在Graph上进行争论。 争议期限因争议类型而异。 查询/证明有 7 个时期的争议窗口，而分配有 56 个时期。 在这些期限过后，不能对分配或查询提出争议。 当争议开始时，Fishermen需要至少 10000 GRT 的押金，押金将被锁定，直到争议结束并给出解决方案。 Fishermen是任何引发争议的网络参与者。
+在争议期间，索引人的查询和分配都可以在The Graph上进行争论。 争议期限因争议类型而异。 查询/证明有 7 个时期的争议窗口，而分配有 56 个时期。 在这些期限过后，不能对分配或查询提出争议。 当争议开始时，Fishermen需要至少 10000 GRT 的押金，押金将被锁定，直到争议结束并给出解决方案。 Fishermen是任何引发争议的网络参与者。
 
 Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
 
@@ -563,7 +563,7 @@ The **Indexer CLI** connects to the Indexer agent, typically through port-forwar
 
 All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
 
-#### 索引规则
+#### Indexing rules
 
 Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
 
@@ -621,7 +621,7 @@ The indexer-cli provides an `actions` module for manually working with the actio
 
 The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
 
-- 第三方优化器工具或indexer-cli用户添加到队列的操作
+- 第三方优化器工具或indexer-cli用户添加到队列的操作。
 - Indexer can use the `indexer-cli` to view all queued actions
 - Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
 - The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.

From db3d3d122378e4f03da616b1bdf244fbe1cac7d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 14:17:40 -0500
Subject: [PATCH 2780/3820] New translations tap.mdx (French)

---
 website/pages/fr/indexing/tap.mdx | 140 +++++++++++++++---------------
 1 file changed, 70 insertions(+), 70 deletions(-)

diff --git a/website/pages/fr/indexing/tap.mdx b/website/pages/fr/indexing/tap.mdx
index 00e31fb7b931..bd6f29f30d27 100644
--- a/website/pages/fr/indexing/tap.mdx
+++ b/website/pages/fr/indexing/tap.mdx
@@ -33,144 +33,144 @@ Tant que vous exécutez `tap-agent` et `indexer-agent`, tout sera exécuté auto
 
 1. Un Indexeur clôture l'allocation.
 
-2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+2. Pendant la période `<recently-closed-allocation-buffer>, tap-agent` regroupe tous les reçus (receipts) en attente pour cette allocation particulière et demande leur agrégation dans un RAV, en le marquant comme « dernier » (last).
 
-3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+3. `indexer-agent` récupère tous les derniers RAVS et envoie des demandes de rachat à la blockchain, qui mettra à jour la valeur de `redeem_at`.
 
-4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+4. Pendant la période `<finality-time>`, `indexer-agent` surveille si la blockchain a des réorganisations qui annulent la transaction.
 
-   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+   - Si elle a été annulée, la RAV est renvoyée à la blockchain. S'il n'a pas été modifié, il est marqué comme `final`.
 
-## Blockchain Addresses
+## Adresses sur la blockchain
 
 ### Contrats
 
-| Contrat             | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
-| ------------------- | -------------------------------------------- | -------------------------------------------- |
-| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
-| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
-| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+| Contrat                                  | Mainnet Arbitrum (42161)                     | Arbitrum Sepolia (421614)                    |
+| ---------------------------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP Verifier                             | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker                      | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Tiers de confiance (Escrow)              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
 
-### Gateway
+### Passerelle (Gateway)
 
-| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
-| ---------- | --------------------------------------------- | --------------------------------------------- |
-| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
-| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
-| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+| Composant      | Mainnet Node et Edge (Arbitrum Mainnet)       | Testnet Node et Edge (Arbitrum Mainnet)       |
+| -------------- | --------------------------------------------- | --------------------------------------------- |
+| Sender         | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Signataires    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregateur    | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
 
 ### Exigences
 
-In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+En plus des conditions typiques pour faire fonctionner un Indexeur, vous aurez besoin d'un Endpoint `tap-escrow-subgraph` pour interroger les mises à jour de TAP. Vous pouvez utiliser The Graph Network pour interroger ou vous héberger vous-même sur votre `graph-node`.
 
-- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
-- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+- [Subgraph Graph TAP Arbitrum Sepolia (pour le testnet The Graph )](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Subgraph Graph TAP Arbitrum One (Pour le mainnet The Graph )](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
 
-> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+> Note : `indexer-agent` ne gère pas actuellement l'indexation de ce subgraph comme il le fait pour le déploiement du subgraph réseau. Par conséquent, vous devez l'indexer manuellement.
 
-## Migration Guide
+## Guide De Migration
 
-### Software versions
+### Versions du logiciel
 
-The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+La version requise du logiciel peut être trouvée [ici](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
 
-### Steps
+### Étapes
 
-1. **Indexer Agent**
+1. **Agent d'indexeur**
 
-   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
-   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+   - Suivez le [même processus](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Donnez le nouvel argument `--tap-subgraph-endpoint` pour activer les nouveaux chemins de code TAP et permettre l'échange de RAVs TAP.
 
 2. **Indexer Service**
 
-   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
-   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+   - Remplacez complètement votre configuration actuelle par le [nouveau service d'Indexeur rs](https://github.com/graphprotocol/indexer-rs). Il est recommandé d'utiliser l'[image du conteneur](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Comme dans la version précédente, vous pouvez facilement faire monter Indexer Service en charge (scaling horizontal) car il reste sans état (stateless).
 
 3. **TAP Agent**
 
-   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Exécutez _une_ seule instance de [Agent TAP](https://github.com/graphprotocol/indexer-rs) à tout moment. Il est recommandé d'utiliser l'[image de conteneur](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
 
-4. **Configure Indexer Service and TAP Agent**
+4. **Configuration de l’Indexer Service et du TAP Agent**
 
-   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+   La configuration se fait via un fichier TOML partagé entre `indexer-service` et `tap-agent`, passé en paramètre par `--config /path/to/config.toml`.
 
-   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+   Consultez la [configuration complète](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) et les [valeurs par défaut](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
 
-For minimal configuration, use the following template:
+Pour une configuration minimale, utilisez le modèle suivant :
 
 ```bash
-# You will have to change *all* the values below to match your setup.
+# Vous devrez modifier *toutes* les valeurs ci-dessous pour qu'elles correspondent à votre configuration.
 #
-# Some of the config below are global graph network values, which you can find here:
+# Certaines des configurations ci-dessous sont des valeurs globales de graph network, que vous pouvez trouver ici :
 # <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
 #
-# Pro tip: if you need to load some values from the environment into this config, you
-# can overwrite with environment variables. For example, the following can be replaced
-# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+# Astuce de pro : si vous devez charger certaines valeurs de l'environnement dans cette configuration, vous
+# pouvez les écraser avec des variables d'environnement. Par exemple, ce qui suit peut être remplacé
+# par [PREFIX]_DATABASE_POSTGRESURL, où PREFIX peut être `INDEXER_SERVICE` ou `TAP_AGENT` :
 #
 # [database]
 # postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
 
 [indexer]
-indexer_address = "0x1111111111111111111111111111111111111111"
+indexer_address = "0x111111111111111111111111111111111111111111"
 operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
 
 [database]
-# The URL of the Postgres database used for the indexer components. The same database
-# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
-# the necessary tables.
+# L'URL de la base de données Postgres utilisée pour les composants de l'Indexeur. La même base de données
+# qui est utilisée par `indexer-agent`. Il est prévu que `indexer-agent` crée
+# les tables nécessaires.
 postgres_url = "postgres://postgres@postgres:5432/postgres"
 
 [graph_node]
-# URL to your graph-node's query endpoint
+# URL vers l'endpoint de requête de votre graph-node
 query_url = "<http://graph-node:8000>"
-# URL to your graph-node's status endpoint
+# URL vers l'endpoint d'état de votre graph-node
 status_url = "<http://graph-node:8000/graphql>"
 
 [subgraphs.network]
-# Query URL for the Graph Network subgraph.
+# URL de requête pour le subgraph Graph Network.
 query_url = "<http://example.com/network-subgraph>"
-# Optional, deployment to look for in the local `graph-node`, if locally indexed.
-# Locally indexing the subgraph is recommended.
-# NOTE: Use `query_url` or `deployment_id` only
-deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+# Facultatif, déploiement à rechercher dans le `graph-node` local, s'il est indexé localement.
+# L'indexation locale du subgraph est recommandée.
+# REMARQUE : utilisez uniquement `query_url` ou `deployment_id`
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
 
 [subgraphs.escrow]
-# Query URL for the Escrow subgraph.
+# URL de requête pour le subgraph Escrow.
 query_url = "<http://example.com/network-subgraph>"
-# Optional, deployment to look for in the local `graph-node`, if locally indexed.
-# Locally indexing the subgraph is recommended.
-# NOTE: Use `query_url` or `deployment_id` only
-deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+# Facultatif, déploiement à rechercher dans le `graph-node` local, s'il est indexé localement.
+# Il est recommandé d'indexer localement le subgraph.
+# REMARQUE : utilisez uniquement `query_url` ou `deployment_id`
+deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
 
 [blockchain]
-# The chain ID of the network that the graph network is running on
+# Le chain ID du réseau sur lequel The Graph Network s'exécute
 chain_id = 1337
-# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
-receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+# Adresse du contrat du vérificateur de bon de réception agrégé (RAV) de TAP.
+receives_verifier_address = "0x222222222222222222222222222222222222222222222"
 
-########################################
-# Specific configurations to tap-agent #
-########################################
+############################################
+# Configurations spécifiques à tap-agent #
+##########################################
 [tap]
-# This is the amount of fees you are willing to risk at any given time. For ex.
-# if the sender stops supplying RAVs for long enough and the fees exceed this
-# amount, the indexer-service will stop accepting queries from the sender
-# until the fees are aggregated.
-# NOTE: Use strings for decimal values to prevent rounding errors
-# e.g:
+# Il s'agit du montant des frais que vous êtes prêt à risquer à un moment donné. Par exemple,
+# si l'expéditeur cesse de fournir des RAV pendant suffisamment longtemps et que les frais dépassent ce
+# montant, le service d'indexation cessera d'accepter les requêtes de l'expéditeur
+# jusqu'à ce que les frais soient agrégés.
+# REMARQUE : utilisez des chaînes de caractère pour les valeurs décimales afin d'éviter les erreurs d'arrondi
+# p. ex. :
 # max_amount_willing_to_lose_grt = "0.1"
 max_amount_willing_to_lose_grt = 20
 
 [tap.sender_aggregator_endpoints]
-# Key-Value of all senders and their aggregator endpoints
-# This one below is for the E&N testnet gateway for example.
+# Clé-valeur de tous les expéditeurs et de leurs endpoint d'agrégation
+# Celle-ci ci-dessous concerne par exemple la passerelle de testnet E&N.
 0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
 ```
 
 Notez :
 
-- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- Les valeurs de `tap.sender_aggregator_endpoints` peuvent être trouvées dans la section [passerelle](/indexing/tap/#gateway).
 - Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
 
 **Log Level**

From 9c2ab8b9e4ec1ccd6d1345453d1074e9a1e2add0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 14:17:41 -0500
Subject: [PATCH 2781/3820] New translations graph-node.mdx (French)

---
 .../pages/fr/indexing/tooling/graph-node.mdx  | 34 +++++++++----------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/fr/indexing/tooling/graph-node.mdx b/website/pages/fr/indexing/tooling/graph-node.mdx
index 1078990e9f46..f8c94edd667c 100644
--- a/website/pages/fr/indexing/tooling/graph-node.mdx
+++ b/website/pages/fr/indexing/tooling/graph-node.mdx
@@ -42,7 +42,7 @@ Pour activer la surveillance et la création de rapports, Graph Node peut évent
 
 - **IPFS**
 
-- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+- **Exigences supplémentaires pour les utilisateurs d'Ubuntu** - Pour faire fonctionner Graph Node sur Ubuntu, quelques paquets supplémentaires peuvent être nécessaires.
 
 ```sh
 sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
@@ -267,8 +267,8 @@ Ces étapes sont pipeline (c’est-à-dire qu’elles peuvent être exécutées
 
 Causes courantes de lenteur d’indexation :
 
-- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
-- Making large numbers of `eth_calls` as part of handlers
+- Temps nécessaire pour trouver les événements pertinents à partir de la chaîne (les gestionnaires d'appels en particulier peuvent être lents, étant donné la dépendance à `trace_filter`)
+- Faire un grand nombre d'appels `eth_call` dans les gestionnaires
 - Une grande quantité d'interactions avec le magasin pendant l'exécution
 - Une grande quantité de données à sauvegarder dans le magasin
 - Un grand nombre d'événements à traiter
@@ -287,19 +287,19 @@ Lors de l'indexation, les subgraphs peuvent échouer s'ils rencontrent des donn
 
 Dans certains cas, un échec peut être résolu par l'indexeur (par exemple, si l'erreur est due au fait de ne pas disposer du bon type de fournisseur, l'ajout du fournisseur requis permettra de poursuivre l'indexation). Cependant, dans d'autres cas, une modification du code du subgraph est requise.
 
-> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+> Les défaillances déterministes sont considérés comme "final" (définitifs), avec une preuve d'indexation générée pour le bloc défaillant, alors que les défaillances non déterministes ne le sont pas, car le subgraph pourait "se rétablir " et poursuivre l'indexation. Dans certains cas, l'étiquette non déterministe est incorrecte et le subgraph ne surmontera jamais l'erreur ; de tels défaillances doivent être signalés en tant que problèmes sur le dépôt de Graph Node.
 
 #### Bloquer et appeler le cache
 
-Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+Graph Node met en cache certaines données dans le store afin d'éviter de les récupérer auprès du fournisseur. Les blocs sont mis en cache, ainsi que les résultats des `eth_calls` (ces derniers étant mis en cache à partir d'un bloc spécifique). Cette mise en cache peut augmenter considérablement la vitesse d'indexation lors de la « resynchronisation » d'un subgraph légèrement modifié.
 
-However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+Cependant, dans certains cas, si un nœud Ethereum a fourni des données incorrectes pendant une certaine période, cela peut se retrouver dans le cache, conduisant à des données incorrectes ou à des subgraphs défaillants. Dans ce cas, les Indexeurs peuvent utiliser `graphman` pour effacer le cache empoisonné, puis rembobiner les subgraph affectés, ce qui permettra de récupérer des données fraîches auprès du fournisseur (que l'on espère sain).
 
 Si une incohérence du cache de blocs est suspectée, telle qu'un événement de réception de transmission manquant :
 
-1. `graphman chain list` to find the chain name.
-2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
-   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+1. `graphman chain list` pour trouver le nom de la chaîne.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` vérifiera si le bloc mis en cache correspond au fournisseur, et supprimera le bloc du cache si ce n'est pas le cas.
+   1. S'il y a une différence, il peut être plus sûr de tronquer tout le cache avec `graphman chain truncate <CHAIN>`.
    2. Si le bloc correspond au fournisseur, le problème peut être débogué directement auprès du fournisseur.
 
 #### Interroger les problèmes et les erreurs
@@ -312,7 +312,7 @@ Il n'existe pas de solution miracle, mais une gamme d'outils permettant de prév
 
 ##### Mise en cache des requêtes
 
-Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+Graph Node met en cache les requêtes GraphQL par défaut, ce qui peut réduire de manière significative la charge de la base de données. Ceci peut être configuré avec les paramètres `GRAPH_QUERY_CACHE_BLOCKS` et `GRAPH_QUERY_CACHE_MAX_MEM` - en savoir plus [ici](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
 
 ##### Analyser les requêtes
 
@@ -320,7 +320,7 @@ Les requêtes problématiques apparaissent le plus souvent de deux manières. Da
 
 Dans d'autres cas, le déclencheur peut être une utilisation élevée de la mémoire sur un nœud de requête, auquel cas le défi consiste d'abord à identifier la requête à l'origine du problème.
 
-Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+Les Indexeurs peuvent utiliser [qlog](https://github.com/graphprotocol/qlog/) pour traiter et résumer les logs de requêtes de Graph Node. `GRAPH_LOG_QUERY_TIMING` peut également être activé pour aider à identifier et déboguer les requêtes lentes.
 
 Étant donné une requête lente, les indexeurs disposent de quelques options. Bien entendu, ils peuvent modifier leur modèle de coûts pour augmenter considérablement le coût d’envoi de la requête problématique. Cela peut entraîner une réduction de la fréquence de cette requête. Cependant, cela ne résout souvent pas la cause première du problème.
 
@@ -328,18 +328,18 @@ Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and s
 
 Les tables de base de données qui stockent les entités semblent généralement se décliner en deux variétés : les tables de type « transaction », où les entités, une fois créées, ne sont jamais mises à jour, c'est-à-dire qu'elles stockent quelque chose qui s'apparente à une liste de transactions financières, et les « de type compte », où les entités sont mis à jour très souvent, c'est-à-dire qu'ils stockent quelque chose comme des comptes financiers qui sont modifiés à chaque fois qu'une transaction est enregistrée. Les tables de type compte se caractérisent par le fait qu'elles contiennent un grand nombre de versions d'entités, mais relativement peu d'entités distinctes. Souvent, dans de tels tableaux, le nombre d'entités distinctes représente 1 % du nombre total de lignes (versions d'entités)
 
-For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+Pour les tables de type compte, `graph-node` peut générer des requêtes qui tirent parti des détails de la façon dont Postgres stocke les données avec un taux de changement aussi élevé, à savoir que toutes les versions des blocs récents se trouvent dans une petite sous-section du stockage global d'une telle table.
 
-The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+La commande `graphman stats show <sgdNNNN`> montre, pour chaque type/table d'entité dans un déploiement, combien d'entités distinctes, et combien de versions d'entités chaque table contient. Ces données sont basées sur des estimations internes à Postgres, et sont donc nécessairement imprécises, et peuvent être erronées d'un ordre de grandeur. Un `-1` dans la colonne `entités` signifie que Postgres pense que toutes les lignes contiennent une entité distincte.
 
-In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+En général, les tables où le nombre d'entités distinctes est inférieur à 1% du nombre total de versions de lignes/d'entités sont de bons candidats pour l'optimisation de type compte. Lorsque la sortie de `graphman stats show` indique qu'une table pourrait bénéficier de cette optimisation, l'exécution de `graphman stats show <sgdNNN> <table>` effectuera un comptage complet de la table - ce qui peut être lent, mais donne une mesure précise du ratio d'entités distinctes par rapport au nombre total de versions d'entités.
 
-Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+Une fois qu'une table a été déterminée comme étant de type compte, l'exécution de `graphman stats account-like <sgdNNN>.<table>` activera l'optimisation de type compte pour les requêtes sur cette table. L'optimisation peut être désactivée à nouveau avec `graphman stats account-like --clear <sgdNNN>.<table>` Il faut compter jusqu'à 5 minutes pour que les noeuds de requêtes remarquent que l'optimisation a été activée ou désactivée. Après avoir activé l'optimisation, il est nécessaire de vérifier que le changement ne ralentit pas les requêtes pour cette table. Si vous avez configuré Grafana pour surveiller Postgres, les requêtes lentes apparaîtront dans `pg_stat_activity` en grand nombre, prenant plusieurs secondes. Dans ce cas, l'optimisation doit être désactivée à nouveau.
 
-For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+Pour les subgraphs de type Uniswap, les tables `pair` et `token` sont les meilleurs candidats pour cette optimisation, et peuvent avoir un effet considérable sur la charge de la base de données.
 
 #### Supprimer des subgraphs
 
 > Il s'agit d'une nouvelle fonctionnalité qui sera disponible dans Graph Node 0.29.x
 
-At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).
+A un moment donné, un Indexeur peut vouloir supprimer un subgraph donné. Cela peut être facilement fait via `graphman drop`, qui supprime un déploiement et toutes ses données indexées. Le déploiement peut être spécifié soit comme un nom de subgraph, soit comme un hash IPFS `Qm..`, ou alors comme le namespace `sgdNN` de la base de données . Une documentation plus détaillée est disponible [ici](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From e5532597985220a5665c2dcb911f496dc60cde6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 14:17:43 -0500
Subject: [PATCH 2782/3820] New translations chain-integration-overview.mdx
 (French)

---
 website/pages/fr/indexing/chain-integration-overview.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/indexing/chain-integration-overview.mdx b/website/pages/fr/indexing/chain-integration-overview.mdx
index 7f31c5af51aa..dc508e2083af 100644
--- a/website/pages/fr/indexing/chain-integration-overview.mdx
+++ b/website/pages/fr/indexing/chain-integration-overview.mdx
@@ -6,7 +6,7 @@ Un processus d'intégration transparent et basé sur la gouvernance a été con
 
 ## Étape 1. Intégration technique
 
-- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Veuillez consulter [Intégration de nouvelle chaîne](/indexing/new-chain-integration/) pour plus d'informations sur le support `graph-node` pour les nouvelles chaînes.
 - Les équipes lancent le processus d'intégration du protocole en créant un fil de discussion sur le forum [ici](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (sous-catégorie Nouvelles sources de données sous Gouvernance et GIPs ). L'utilisation du modèle de forum par défaut est obligatoire.
 
 ## Étape 2. Validation de l'intégration

From a8044c4e4b7bc17e77bb185207df8fe24a19d868 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 14:17:44 -0500
Subject: [PATCH 2783/3820] New translations new-chain-integration.mdx (French)

---
 website/pages/fr/indexing/new-chain-integration.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/indexing/new-chain-integration.mdx b/website/pages/fr/indexing/new-chain-integration.mdx
index c1a8c1952bbb..2b3717f5030c 100644
--- a/website/pages/fr/indexing/new-chain-integration.mdx
+++ b/website/pages/fr/indexing/new-chain-integration.mdx
@@ -45,7 +45,7 @@ For EVM chains, there exists a deeper level of data that can be achieved through
 
 ## EVM considerations - Difference between JSON-RPC & Firehose
 
-While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+Bien que le JSON-RPC et le Firehose soient tous deux adaptés aux subgraphs, un Firehose est toujours nécessaire pour les développeurs qui souhaitent construire avec [Substreams](https://substreams.streamingfast.io). La prise en charge de Substreams permet aux développeurs de construire des [subgraphs alimentés par Substreams](/subgraphs/cookbook/substreams-powered-subgraphs/) pour la nouvelle chaîne, et a le potentiel d'améliorer les performances de vos subgraphs. De plus, Firehose - en tant que remplacement direct de la couche d'extraction JSON-RPC de `graph-node` - réduit de 90% le nombre d'appels RPC requis pour l'indexation générale.
 
 - All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
 
@@ -77,4 +77,4 @@ Graph Node devrait synchroniser le subgraph déployé s'il n'y a pas d'erreurs.
 
 ## Substreams-powered Subgraphs
 
-For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.
+Pour les intégrations Firehose/Substreams pilotées par StreamingFast, la prise en charge de base des modules Substreams fondamentaux (par exemple, les transactions décodées, les logs et les événements smart-contract) et les outils codegen Substreams sont inclus. Ces outils permettent d'activer des [subgraphs alimentés par Substreams](/substreams/sps/introduction/). Suivez le [Guide pratique](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) et exécutez `substreams codegen subgraph` pour expérimenter les outils codegen par vous-même.

From 011ac30deae7d73cd2a0dd3cc8e42325c10f80c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 14:17:45 -0500
Subject: [PATCH 2784/3820] New translations supported-network-requirements.mdx
 (French)

---
 .../supported-network-requirements.mdx        | 30 +++++++++----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/fr/indexing/supported-network-requirements.mdx b/website/pages/fr/indexing/supported-network-requirements.mdx
index 8df2bb4bc660..088592beee58 100644
--- a/website/pages/fr/indexing/supported-network-requirements.mdx
+++ b/website/pages/fr/indexing/supported-network-requirements.mdx
@@ -1,18 +1,18 @@
 ---
-title: Supported Network Requirements
+title: Exigences du réseau pris en charge
 ---
 
-| Réseau    | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
-| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
-| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
-| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
-| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
-| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
-| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
-| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
-| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
-| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |
+| Réseau    | Guides                                                                                                                                                                                                                                                                                              | Configuration requise                                                                                                                   | Récompenses d'indexation |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | :----------------------: |
+| Arbitrum  | [Guide Baremetal ](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Guide Docker ](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                               | CPU 4+ coeurs <br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _dernière mise à jour août 2023_                        |             ✅            |
+| Avalanche | [Guide Docker](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | CPU 4 cœurs / 8 threads <br /> Ubuntu 22.04<br /> 16Go+ RAM<br /> >= 5 Tio NVMe SSD<br /> _dernière mise à jour août 2023_              |             ✅            |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | CPU 8+ cœurs <br /> Debian 12/Ubuntu 22.04<br /> 16 Go RAM<br /> >= 4.5To (NVME recommandé)<br /> _Dernière mise à jour le 14 mai 2024_ |             ✅            |
+| Binance   | [Guide Erigon Baremetal ](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                     | CPU 8 cœurs / 16 threads <br /> Ubuntu 22.04<br /> >=32 Go RAM<br /> >= 14 Tio NVMe SSD<br /> _Dernière mise à jour le 22 juin 2024_    |             ✅            |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                      |             ✅            |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_   |             ✅            |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                     |             ✅            |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                     |             ✅            |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                              |             ✅            |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                      |             ✅            |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                                |             ✅            |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                      |             ✅            |

From fdab59ee4597c6e3a6b0ed9950d34c2c0d5daba5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 15:14:59 -0500
Subject: [PATCH 2785/3820] New translations overview.mdx (French)

---
 website/pages/fr/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/indexing/overview.mdx b/website/pages/fr/indexing/overview.mdx
index 6dfc489f0e9a..d83fc5ad66f8 100644
--- a/website/pages/fr/indexing/overview.mdx
+++ b/website/pages/fr/indexing/overview.mdx
@@ -735,9 +735,9 @@ Exemple de calcul des coûts de requête utilisant le modèle ci-dessus :
 
 | Requête                                                                        | Prix    |
 | ------------------------------------------------------------------------------ | ------- |
-| { pairs(skip: 5000) { id } }                                                   | 0.5 GRT |
-| { tokens { symbol } }                                                          | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                                 | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                               | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                      | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125;   | 0.6 GRT |
 
 #### Application du modèle de coût
 

From eba3a8cee55539669bf2916ecf28f0903591b887 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 15:15:00 -0500
Subject: [PATCH 2786/3820] New translations tap.mdx (French)

---
 website/pages/fr/indexing/tap.mdx | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/fr/indexing/tap.mdx b/website/pages/fr/indexing/tap.mdx
index bd6f29f30d27..92fdd02e2082 100644
--- a/website/pages/fr/indexing/tap.mdx
+++ b/website/pages/fr/indexing/tap.mdx
@@ -171,23 +171,23 @@ max_amount_willing_to_lose_grt = 20
 Notez :
 
 - Les valeurs de `tap.sender_aggregator_endpoints` peuvent être trouvées dans la section [passerelle](/indexing/tap/#gateway).
-- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+- Les valeurs de `blockchain.receipts_verifier_address` doivent être utilisées conformément à la [Section des adresses Blockchain](/indexing/tap/#contracts) en utilisant le chain id approprié.
 
-**Log Level**
+**Niveau de journalisation**
 
-- You can set the log level by using the `RUST_LOG` environment variable.
-- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+- Vous pouvez définir le niveau de journalisation en utilisant la variable d'environnement `RUST_LOG`.
+- Il est recommandé de le mettre à `RUST_LOG=indexer_tap_agent=debug,info`.
 
 ## Monitoring
 
-### Metrics
+### Métriques
 
-All components expose the port 7300 to be queried by prometheus.
+Tous les composants exposent le port 7300 qui peut être interrogé par prometheus.
 
-### Grafana Dashboard
+### Tableau de bord Grafana
 
-You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+Vous pouvez télécharger le [Tableau de bord Grafana](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) et l'importer.
 
 ### Launchpad
 
-Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)
+Actuellement, il existe une version WIP de `indexer-rs` et de `tap-agent` qui peut être trouvée [ici](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)

From b4311cc7b5a139475d5b383a33f4e87a62802974 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 15:15:01 -0500
Subject: [PATCH 2787/3820] New translations graph-node.mdx (French)

---
 .../pages/fr/indexing/tooling/graph-node.mdx  | 42 +++++++++----------
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/website/pages/fr/indexing/tooling/graph-node.mdx b/website/pages/fr/indexing/tooling/graph-node.mdx
index f8c94edd667c..66beb0dc1a19 100644
--- a/website/pages/fr/indexing/tooling/graph-node.mdx
+++ b/website/pages/fr/indexing/tooling/graph-node.mdx
@@ -4,13 +4,13 @@ title: Nœud de The Graph
 
 Graph Node est le composant qui indexe les subgraphs et rend les données résultantes disponibles pour interrogation via une API GraphQL. En tant que tel, il est au cœur de la pile de l’indexeur, et le bon fonctionnement de Graph Node est crucial pour exécuter un indexeur réussi.
 
-This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+Ceci fournit un aperçu contextuel de Graph Node et de certaines des options les plus avancées disponibles pour les Indexeurs. Une documentation et des instructions détaillées peuvent être trouvées dans le dépôt [Graph Node ](https://github.com/graphprotocol/graph-node).
 
 ## Nœud de The Graph
 
-[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+[Graph Node](https://github.com/graphprotocol/graph-node) est l'implémentation de référence pour l'indexation des subgraphs sur The Graph Network, la connexion aux clients de la blockchain, l'indexation des subgraphs et la mise à disposition des données indexées pour les requêtes.
 
-Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+Graph Node (et l'ensemble de la pile de l’indexeur) peut être exécuté sur serveur dédié (bare metal) ou dans un environnement cloud. Cette souplesse du composant central d'indexation est essentielle à la solidité du protocole The Graph. De même, Graph Node peut être [compilé à partir du code source](https://github.com/graphprotocol/graph-node), ou les Indexeurs peuvent utiliser l'une des [images Docker fournies](https://hub.docker.com/r/graphprotocol/graph-node).
 
 ### PostgreSQL database
 
@@ -20,9 +20,9 @@ Le magasin principal du nœud de graph, c'est là que les données des sous-grap
 
 Pour indexer un réseau, Graph Node doit avoir accès à un client réseau via une API JSON-RPC compatible avec EVM. Cette RPC peut se connecter à un seul client ou à une configuration plus complexe qui équilibre la charge entre plusieurs clients.
 
-While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+Alors que certains subgraphs peuvent ne nécessiter qu'un nœud complet, d'autres peuvent avoir des caractéristiques d'indexation qui nécessitent des fonctionnalités RPC supplémentaires. En particulier, les subgraphs qui font des `eth_calls` dans le cadre de l'indexation nécessiteront un noeud d'archive qui supporte [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), et les subgraphs avec des `callHandlers`, ou des `blockHandlers` avec un filtre `call`, nécessitent le support de `trace_filter` ([voir la documentation du module trace ici](https://openethereum.github.io/JSONRPC-trace-module)).
 
-**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+\*\*Network Firehoses : un Firehose est un service gRPC fournissant un flux de blocs ordonné, mais compatible avec les fork, développé par les principaux développeurs de The Graph pour mieux prendre en charge une indexation performante à l'échelle. Il ne s'agit pas actuellement d'une exigence de l'Indexeur, mais les Indexeurs sont encouragés à se familiariser avec la technologie, en avance sur la prise en charge complète du réseau. Pour en savoir plus sur le Firehose [ici](https://firehose.streamingfast.io/).
 
 ### Nœuds IPFS
 
@@ -42,7 +42,7 @@ Pour activer la surveillance et la création de rapports, Graph Node peut évent
 
 - **IPFS**
 
-- **Exigences supplémentaires pour les utilisateurs d'Ubuntu** - Pour faire fonctionner Graph Node sur Ubuntu, quelques paquets supplémentaires peuvent être nécessaires.
+- **Exigences supplémentaires pour les utilisateurs d'Ubuntu** - Pour faire fonctionner un Graph Node sur Ubuntu, quelques packages supplémentaires peuvent être nécessaires.
 
 ```sh
 sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
@@ -71,7 +71,7 @@ cargo run -p graph-node --release -- \
 
 ### Bien démarrer avec Kubernetes
 
-A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+Un exemple complet de configuration Kubernetes se trouve dans le [dépôt d'Indexeur](https://github.com/graphprotocol/indexer/tree/main/k8s).
 
 ### Ports
 
@@ -85,42 +85,42 @@ Lorsqu'il est en cours d'exécution, Graph Node expose les ports suivants :
 | 8030 | API de statut d'indexation des subgraphs                   | /graphq                                        | \--index-node-port | -                        |
 | 8040 | Métriques Prometheus                                       | /metrics                                       | \--metrics-port    | -                        |
 
-> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+> **Important** : Soyez prudent lorsque vous exposez des ports publiquement - les **ports d'administration** doivent être verrouillés. Ceci inclut l'endpoint JSON-RPC de Graph Node.
 
 ## Configuration avancée du nœud graph
 
 Dans sa forme la plus simple, Graph Node peut être utilisé avec une seule instance de Graph Node, une seule base de données PostgreSQL, un nœud IPFS et les clients réseau selon les besoins des subgraphs à indexer.
 
-This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+Cette configuration peut être mise à l'échelle horizontalement, en ajoutant plusieurs Graph Nodes, et plusieurs bases de données pour supporter ces Graph Nodes. Les utilisateurs avancés voudront peut-être profiter de certaines des capacités de mise à l'échelle horizontale de Graph Node, ainsi que de certaines des options de configuration les plus avancées, via le fichier `config.toml` et les variables d'environnement de Graph Node.
 
 ### `config.toml`
 
-A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+Un fichier de configuration [TOML](https://toml.io/en/) peut être utilisé pour définir des configurations plus complexes que celles exposées dans la CLI. L'emplacement du fichier est transmis avec via l’option de ligne de commande --config.
 
 > Lors de l'utilisation d'un fichier de configuration, il n'est pas possible d'utiliser les options --postgres-url, --postgres-secondary-hosts et --postgres-host-weights.
 
-A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+Un fichier `config.toml` minimal peut être fourni ; le fichier suivant équivaut à l'utilisation de l'option --postgres-url en ligne de commande :
 
 ```toml
 [store]
 [store.primary]
-connection="<.. postgres-url argument ..>"
+connection="<..argument postgres-url ..>"
 [deployment]
 [[deployment.rule]]
-indexers = [ "<.. list of all indexing nodes ..>" ]
+indexers = [ "<.. liste de tous les nœuds d'indexation ..>" ]
 ```
 
-Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+La documentation complète de `config.toml` peut être trouvée dans la [documentation de Graph Node](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
 
 #### Multiple Graph Nodes
 
-Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+L'indexation Graph Node peut être mise à l'échelle horizontalement, en exécutant plusieurs instances de Graph Node pour répartir l'indexation et l'interrogation sur différents nœuds. Cela peut être fait simplement en exécutant des Graph Nodes configurés avec un `node_id` différent au démarrage (par exemple dans le fichier Docker Compose), qui peut ensuite être utilisé dans le fichier `config.toml` pour spécifier les [nœuds de requête dédiés](#dedicated-query-nodes), les [ingesteurs de blocs](#dedicated-block-ingestion) et en répartissant les subgraphs sur les nœuds avec des [règles de déploiement](#deployment-rules).
 
 > Notez que plusieurs nœuds de graph peuvent tous être configurés pour utiliser la même base de données, qui elle-même peut être mise à l'échelle horizontalement via le partitionnement.
 
 #### Règles de déploiement
 
-Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+Étant donné plusieurs Graph Node, il est nécessaire de gérer le déploiement de nouveaux subgraphs afin que le même subgraph ne soit pas indexé par deux nœuds différents, ce qui entraînerait des collisions. Cela peut être fait en utilisant des règles de déploiement, qui peuvent également spécifier dans quel `shard` les données d'un subgraph doivent être stockées, si le partitionnement de base de données est utilisé. Les règles de déploiement peuvent correspondre au nom du subgraph et au réseau que le déploiement indexe afin de prendre une décision.
 
 Exemple de configuration de règle de déploiement :
 
@@ -150,7 +150,7 @@ indexers = [
   ]
 ```
 
-Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+En savoir plus sur les règles de déploiement [ici](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
 
 #### Nœuds de requête dédiés
 
@@ -158,7 +158,7 @@ Les nœuds peuvent être configurés pour être explicitement des nœuds de requ
 
 ```toml
 [general]
-query = "<regular expression>"
+query = "<expression regulière>"
 ```
 
 Tout nœud dont --node-id correspond à l'expression régulière sera configuré pour répondre uniquement aux requêtes.
@@ -167,7 +167,7 @@ Tout nœud dont --node-id correspond à l'expression régulière sera configuré
 
 Pour la plupart des cas d'utilisation, une seule base de données Postgres suffit pour prendre en charge une instance de nœud graph. Lorsqu'une instance de nœud graph dépasse une seule base de données Postgres, il est possible de diviser le stockage des données de nœud graph sur plusieurs bases de données Postgres. Toutes les bases de données forment ensemble le magasin de l’instance de nœud graph. Chaque base de données individuelle est appelée une partition.
 
-Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+Les fragments peuvent être utilisés pour diviser les déploiements de subgraph sur plusieurs bases de données et peuvent également être utilisés pour faire intervenir des réplicas afin de répartir la charge de requête sur plusieurs bases de données. Cela inclut la configuration du nombre de connexions de base de données disponibles que chaque `graph-node` doit conserver dans son pool de connexions pour chaque base de données, ce qui devient de plus en plus important à mesure que davantage de subgraph sont indexés.
 
 Le partage devient utile lorsque votre base de données existante ne peut pas suivre la charge que Graph Node lui impose et lorsqu'il n'est plus possible d'augmenter la taille de la base de données.
 
@@ -175,11 +175,11 @@ Le partage devient utile lorsque votre base de données existante ne peut pas su
 
 En termes de configuration des connexions, commencez par max_connections dans postgresql.conf défini sur 400 (ou peut-être même 200) et regardez les métriques store_connection_wait_time_ms et store_connection_checkout_count Prometheus. Des temps d'attente notables (tout ce qui dépasse 5 ms) indiquent qu'il y a trop peu de connexions disponibles ; des temps d'attente élevés seront également dus au fait que la base de données est très occupée (comme une charge CPU élevée). Cependant, si la base de données semble par ailleurs stable, des temps d'attente élevés indiquent la nécessité d'augmenter le nombre de connexions. Dans la configuration, le nombre de connexions que chaque instance de nœud graph peut utiliser constitue une limite supérieure, et Graph Node ne maintiendra pas les connexions ouvertes s'il n'en a pas besoin.
 
-Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+En savoir plus sur la configuration du store [ici](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
 
 #### Ingestion de blocs dédiés
 
-If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+Si plusieurs nœuds sont configurés, il sera nécessaire de spécifier un nœud responsable de l'ingestion de nouveaux blocs, afin que tous les nœuds d’indexation ne sondent pas simultanément le head de la chaîne. Cela s’effectue dans la section `chains` du fichier de configuration, en spécifiant le `node_id` à utiliser pour l'ingestion de blocs :
 
 ```toml
 [chains]

From 998e44b65c2c676364a2d439d77361849aeebef6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 15:15:03 -0500
Subject: [PATCH 2788/3820] New translations supported-network-requirements.mdx
 (French)

---
 .../supported-network-requirements.mdx        | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/fr/indexing/supported-network-requirements.mdx b/website/pages/fr/indexing/supported-network-requirements.mdx
index 088592beee58..70bc33a8e9ca 100644
--- a/website/pages/fr/indexing/supported-network-requirements.mdx
+++ b/website/pages/fr/indexing/supported-network-requirements.mdx
@@ -2,17 +2,17 @@
 title: Exigences du réseau pris en charge
 ---
 
-| Réseau    | Guides                                                                                                                                                                                                                                                                                              | Configuration requise                                                                                                                   | Récompenses d'indexation |
-| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | :----------------------: |
-| Arbitrum  | [Guide Baremetal ](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Guide Docker ](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                               | CPU 4+ coeurs <br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _dernière mise à jour août 2023_                        |             ✅            |
-| Avalanche | [Guide Docker](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | CPU 4 cœurs / 8 threads <br /> Ubuntu 22.04<br /> 16Go+ RAM<br /> >= 5 Tio NVMe SSD<br /> _dernière mise à jour août 2023_              |             ✅            |
-| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | CPU 8+ cœurs <br /> Debian 12/Ubuntu 22.04<br /> 16 Go RAM<br /> >= 4.5To (NVME recommandé)<br /> _Dernière mise à jour le 14 mai 2024_ |             ✅            |
-| Binance   | [Guide Erigon Baremetal ](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                     | CPU 8 cœurs / 16 threads <br /> Ubuntu 22.04<br /> >=32 Go RAM<br /> >= 14 Tio NVMe SSD<br /> _Dernière mise à jour le 22 juin 2024_    |             ✅            |
-| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                      |             ✅            |
-| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_   |             ✅            |
-| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                     |             ✅            |
-| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                     |             ✅            |
-| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                              |             ✅            |
-| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                      |             ✅            |
-| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                                |             ✅            |
-| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                      |             ✅            |
+| Réseau    | Guides                                                                                                                                                                                                                                                                                              | Configuration requise                                                                                                                                                 | Récompenses d'indexation |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------: |
+| Arbitrum  | [Guide Baremetal ](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Guide Docker ](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                               | CPU 4+ coeurs <br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _dernière mise à jour août 2023_                                                      |             ✅            |
+| Avalanche | [Guide Docker](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | CPU 4 cœurs / 8 threads <br /> Ubuntu 22.04<br /> 16Go+ RAM<br /> >= 5 Tio NVMe SSD<br /> _dernière mise à jour août 2023_                                            |             ✅            |
+| Base      | [Guide Erigon Baremetal ](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [Guide GETH Baremetal ](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [Guide GETH Docker ](https://docs.infradao.com/archive-nodes-101/base/geth/docker)          | CPU 8+ cœurs <br /> Debian 12/Ubuntu 22.04<br /> 16 Go RAM<br /> >= 4.5To (NVME recommandé)<br /> _Dernière mise à jour le 14 mai 2024_                               |             ✅            |
+| Binance   | [Guide Erigon Baremetal ](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                     | CPU 8 cœurs / 16 threads <br /> Ubuntu 22.04<br /> >=32 Go RAM<br /> >= 14 Tio NVMe SSD<br /> _Dernière mise à jour le 22 juin 2024_                                  |             ✅            |
+| Celo      | [Guide Docker](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | CPU 4 cœurs / 8 threads <br /> Ubuntu 22.04<br /> 16Go+ RAM<br /> >= 2 Tio NVMe SSD<br /> _Dernière mise à jour en août 2023_                                         |             ✅            |
+| Ethereum  | [Guide Docker](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Vitesse d'horloge supérieure par rapport au nombre de cœurs<br /> Ubuntu 22.04<br /> 16 Go+ RAM<br /> >=3 To (NVMe recommandé)<br /> _dernière mise à jour août 2023_ |             ✅            |
+| Fantom    | [Guide Docker](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | CPU 4 cœurs / 8 threads<br /> Ubuntu 22.04<br /> 16 Go + RAM<br /> >= 13 Tio SSD NVMe<br /> _dernière mise à jour août 2023_                                          |             ✅            |
+| Gnosis    | [Guide Baremetal](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | CPU 6 cœurs / 12 threads<br /> Ubuntu 22.04<br /> 16 Go+ RAM<br /> >= 3 To SSD NVMe<br /> _dernière mise à jour août 2023_                                            |             ✅            |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                                                            |             ✅            |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                                                    |             ✅            |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                                                              |             ✅            |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                                                    |             ✅            |

From 1fffd76a38676a9157b685ca1e0b9e64a3ccbd8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 15:15:17 -0500
Subject: [PATCH 2789/3820] New translations graphql-api.mdx (French)

---
 website/pages/fr/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/querying/graphql-api.mdx b/website/pages/fr/subgraphs/querying/graphql-api.mdx
index 40f107eface9..876361e47e79 100644
--- a/website/pages/fr/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/fr/subgraphs/querying/graphql-api.mdx
@@ -340,7 +340,7 @@ Opérateurs de recherche en texte intégral :
 | Symbole | Opérateur   | Description                                                                                                                                            |
 | ------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`     | `And`       | Pour combiner plusieurs termes de recherche dans un filtre pour les entités incluant tous les termes fournis                                           |
-| |       | `Or`        | Les requêtes comportant plusieurs termes de recherche séparés par l'opérateur ou renverront toutes les entités correspondant à l'un des termes fournis |
+| &#x7c;  | `Or`        | Les requêtes comportant plusieurs termes de recherche séparés par l'opérateur ou renverront toutes les entités correspondant à l'un des termes fournis |
 | `<->`   | `Follow by` | Spécifiez la distance entre deux mots.                                                                                                                 |
 | `:*`    | `Prefix`    | Utilisez le terme de recherche de préfixe pour trouver les mots dont le préfixe correspond (2 caractères requis.)                                      |
 

From be301bf78dd8ac492cce89de354735cf86d769cf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 15:15:45 -0500
Subject: [PATCH 2790/3820] New translations supported-networks.mdx (French)

---
 website/pages/fr/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/supported-networks.mdx b/website/pages/fr/supported-networks.mdx
index 906f9bd2d87f..be1a17d72c97 100644
--- a/website/pages/fr/supported-networks.mdx
+++ b/website/pages/fr/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio repose sur la stabilité et la fiabilité des technologies sous-jacentes, comme les endpoints JSON-RPC, Firehose et Substreams.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 2c9559510b9d3311d3be88601bfc444d904a5389 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 16:41:56 -0500
Subject: [PATCH 2791/3820] New translations graph-node.mdx (French)

---
 .../pages/fr/indexing/tooling/graph-node.mdx  | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/fr/indexing/tooling/graph-node.mdx b/website/pages/fr/indexing/tooling/graph-node.mdx
index 66beb0dc1a19..295020ada1be 100644
--- a/website/pages/fr/indexing/tooling/graph-node.mdx
+++ b/website/pages/fr/indexing/tooling/graph-node.mdx
@@ -188,13 +188,13 @@ ingestor = "block_ingestor_node"
 
 #### Prise en charge de plusieurs réseaux
 
-The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+The Graph Protocol augmente le nombre de réseaux pris en charge pour l'indexation des récompenses, et il existe de nombreux subgraphs indexant des réseaux non pris en charge. Un indexeur peut choisir de les indexer malgré tout. Le fichier `config.toml` permet une configuration riche et flexible :
 
 - Plusieurs réseaux
 - Plusieurs fournisseurs par réseau (cela peut permettre de répartir la charge entre les fournisseurs, et peut également permettre la configuration de nœuds complets ainsi que de nœuds d'archives, Graph Node préférant les fournisseurs moins chers si une charge de travail donnée le permet).
 - Détails supplémentaires sur le fournisseur, tels que les fonctionnalités, l'authentification et le type de fournisseur (pour la prise en charge expérimentale de Firehose)
 
-The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+La section `[chains]` contrôle les fournisseurs ethereum auxquels graph-node se connecte, et où les blocs et autres métadonnées pour chaque chaîne sont stockés. L'exemple suivant configure deux chaînes, mainnet et kovan, où les blocs pour mainnet sont stockés dans le shard vip et les blocs pour kovan sont stockés dans le shard primaire. La chaîne mainnet peut utiliser deux fournisseurs différents, alors que kovan n'a qu'un seul fournisseur.
 
 ```toml
 [chains]
@@ -210,18 +210,18 @@ shard = "primary"
 provider = [ { label = "kovan", url = "http://..", features = [] } ]
 ```
 
-Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+Consultez les informations sur la configuration des fournisseurs [ici](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
 
 ### Variables d'environnement
 
-Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+Graph Node supporte une série de variables d'environnement qui peuvent activer des fonctionnalités ou modifier le comportement de Graph Node. Elles sont documentées [ici](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
 
 ### Déploiement continu
 
 Les utilisateurs qui utilisent une configuration d'indexation à grande échelle avec une configuration avancée peuvent bénéficier de la gestion de leurs nœuds graph avec Kubernetes.
 
-- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
-- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+- Le dépot de l'Indexeur a un [exemple de référence Kubernetes](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) est une boîte à outils pour l'exécution d'un Graph Protocol Indexer sur Kubernetes maintenue par GraphOps. Il fournit un ensemble de graphiques Helm et une CLI pour gérer le déploiement Graph Node.
 
 ### Gestion du nœud de graph
 
@@ -229,23 +229,23 @@ Les utilisateurs qui utilisent une configuration d'indexation à grande échelle
 
 #### Journal de bord
 
-Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+Les logs de Graph Node peuvent fournir des informations utiles pour le débogage et l'optimisation de Graph Node et de subgraphs spécifiques. Graph Node supporte différents niveaux de logs via la variable d'environnement `GRAPH_LOG`, avec les niveaux suivants : error, warn, info, debug ou trace.
 
-In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+De plus, fixer `GRAPH_LOG_QUERY_TIMING` à `gql` fournit plus de détails sur la façon dont les requêtes GraphQL s'exécutent (bien que cela génère un grand volume de logs).
 
-#### Monitoring & alerting
+#### Supervision & alertes
 
 Graph Node fournit les métriques via le point de terminaison Prometheus sur le port 8040 par défaut. Grafana peut ensuite être utilisé pour visualiser ces métriques.
 
-The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+Le dépôt indexer propose un [exemple de configuration Grafana] (https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
 
 #### Graphman
 
-`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+`graphman` est un outil de maintenance pour Graph Node, aidant au diagnostic et à la résolution de différentes tâches quotidiennes et exceptionnelles.
 
-The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+La commande graphman est incluse dans les conteneurs officiels, et vous pouvez docker exec dans votre conteneur graph-node pour l'exécuter. Elle nécessite un fichier `config.toml`.
 
-Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+La documentation complète des commandes `graphman` est disponible dans le dépôt Graph Node. Voir [/docs/graphman.md](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) dans le dépôt Graph Node `/docs`
 
 ### Travailler avec des subgraphs
 
@@ -253,7 +253,7 @@ Full documentation of `graphman` commands is available in the Graph Node reposit
 
 Disponible sur le port 8030/graphql par défaut, l'API d'état d'indexation expose une gamme de méthodes pour vérifier l'état d'indexation de différents subgraphs, vérifier les preuves d'indexation, inspecter les fonctionnalités des subgraphs et bien plus encore.
 
-The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+Le schéma complet est disponible [ici](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
 
 #### Performances d'indexation
 

From 68887da08242fbe4a882bd8038bd6dc95804481a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 16:41:57 -0500
Subject: [PATCH 2792/3820] New translations supported-network-requirements.mdx
 (French)

---
 .../pages/fr/indexing/supported-network-requirements.mdx  | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/fr/indexing/supported-network-requirements.mdx b/website/pages/fr/indexing/supported-network-requirements.mdx
index 70bc33a8e9ca..e22b3896b253 100644
--- a/website/pages/fr/indexing/supported-network-requirements.mdx
+++ b/website/pages/fr/indexing/supported-network-requirements.mdx
@@ -12,7 +12,7 @@ title: Exigences du réseau pris en charge
 | Ethereum  | [Guide Docker](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Vitesse d'horloge supérieure par rapport au nombre de cœurs<br /> Ubuntu 22.04<br /> 16 Go+ RAM<br /> >=3 To (NVMe recommandé)<br /> _dernière mise à jour août 2023_ |             ✅            |
 | Fantom    | [Guide Docker](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | CPU 4 cœurs / 8 threads<br /> Ubuntu 22.04<br /> 16 Go + RAM<br /> >= 13 Tio SSD NVMe<br /> _dernière mise à jour août 2023_                                          |             ✅            |
 | Gnosis    | [Guide Baremetal](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | CPU 6 cœurs / 12 threads<br /> Ubuntu 22.04<br /> 16 Go+ RAM<br /> >= 3 To SSD NVMe<br /> _dernière mise à jour août 2023_                                            |             ✅            |
-| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                                                            |             ✅            |
-| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                                                    |             ✅            |
-| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                                                              |             ✅            |
-| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                                                    |             ✅            |
+| Linea     | [Guide Baremetal ](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                     | CPU 4+ cœurs<br /> Ubuntu 22.04<br /> 16 Go+ RAM<br /> >= 1 To SSD NVMe<br /> _dernière mise à jour le 2 avril 2024_                                                  |             ✅            |
+| Optimism  | [Guide Erigon Baremetal](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [Guide GETH Baremetal](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [Guide GETH Docker](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | CPU 4 cœurs / 8 threads<br /> Ubuntu 22.04<br /> 16 Go + RAM<br /> >= SSD NVMe 8 Tio<br /> _dernière mise à jour août 2023_                                           |             ✅            |
+| Polygon   | [Guide Docker](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | CPU 16 cœurs<br /> Ubuntu 22.04<br /> 32 Go+ RAM<br /> >= 10 Tio NVMe SSD<br /> _dernière mise à jour août 2023_                                                      |             ✅            |
+| Scroll    | [Guide Baremetal](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Guide Docker](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | CPU 4 cœurs / 8 threads<br /> Debian 12<br /> 16 Go + RAM<br /> >= 1 Tio NVMe SSD<br /> _dernière mise à jour le 3 avril 2024_                                        |             ✅            |

From 8c58b7a711d4175ce38c2060f5dea8ee2dce89b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 22 Jan 2025 16:41:58 -0500
Subject: [PATCH 2793/3820] New translations firehose.mdx (French)

---
 website/pages/fr/indexing/tooling/firehose.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/fr/indexing/tooling/firehose.mdx b/website/pages/fr/indexing/tooling/firehose.mdx
index 5eabbd66a503..9efc6479075d 100644
--- a/website/pages/fr/indexing/tooling/firehose.mdx
+++ b/website/pages/fr/indexing/tooling/firehose.mdx
@@ -4,21 +4,21 @@ title: Firehose
 
 ![Firehose Logo](/img/firehose-logo.png)
 
-Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+Firehose est une nouvelle technologie développée par StreamingFast en collaboration avec The Graph Foundation. Le produit offre **des capacités et des vitesses inédites pour l'indexation des données de la blockchain** en utilisant une approche basée sur les fichiers et le streaming-first.
 
-The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+The Graph fusionne avec Go Ethereum/geth avec l'adoption de [Live Tracer avec la version v1.14.0](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
 
 Firehose extrait, transforme et enregistre les données de la blockchain dans une stratégie très performante basée sur des fichiers. Les développeurs de blockchain peuvent ensuite accéder aux données extraites par Firehose par le biais de flux de données binaires. Firehose est destiné à remplacer la couche d'extraction de données blockchain originale de The Graph.
 
 ## Documentation Firehose
 
-The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+La documentation Firehose est actuellement maintenue par l'équipe StreamingFast [sur le site web de StreamingFast](https://firehose.streamingfast.io/).
 
 ### Introduction
 
-- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
-- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+- Lisez cette [Introduction à Firehose](https://firehose.streamingfast.io/introduction/firehose-overview) pour avoir une vue d'ensemble de ce qu'il est et pourquoi il a été construit.
+- Découvrez les [conditions préalables](https://firehose.streamingfast.io/introduction/prerequisites) nécessaires à l'installation et au déploiement de Firehose.
 
 ### Élargissez vos connaissances
 
-- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.
+- Découvrez les différents [composants Firehose](https://firehose.streamingfast.io/architecture/components) disponibles.

From e493fef86c5dbc979ca2d97d9828bf9513641f19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 04:36:54 -0500
Subject: [PATCH 2794/3820] New translations about.mdx (German)

---
 website/pages/de/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/about.mdx b/website/pages/de/about.mdx
index 1104aba75925..61dbccdd5c84 100644
--- a/website/pages/de/about.mdx
+++ b/website/pages/de/about.mdx
@@ -24,7 +24,7 @@ Im Fall des oben aufgeführten konkreten Beispiels, Bored Ape Yacht Club, könne
 
 Es würde **Stunden oder sogar Tage** dauern, bis eine dezentrale Anwendung (dapp), die in einem Browser läuft, eine Antwort auf diese einfachen Fragen erhält.
 
-Alternatively, you have the option to set up your own server, process the transactions, store them in a database, and create an API endpoint to query the data. However, this option is [resource intensive](/resources/benefits/), needs maintenance, presents a single point of failure, and breaks important security properties required for decentralization.
+Alternativ können Sie einen eigenen Server einrichten, die Transaktionen verarbeiten, sie in einer Datenbank speichern und einen API-Endpunkt zur Abfrage der Daten erstellen. Diese Option ist jedoch [Ressourcen-intensiv](/resources/benefits/), muss gewartet werden, stellt einen Single Point of Failure dar und bricht wichtige Sicherheitseigenschaften, die für die Dezentralisierung erforderlich sind.
 
 Blockchain-Eigenschaften wie Endgültigkeit, Umstrukturierung der Kette und nicht gesperrte Blöcke erhöhen die Komplexität des Prozesses und machen es zeitaufwändig und konzeptionell schwierig, genaue Abfrageergebnisse aus Blockchain-Daten zu erhalten.
 

From 966a1d114cde84ca736491eca7246498a5376ec3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 04:36:55 -0500
Subject: [PATCH 2795/3820] New translations arbitrum-faq.mdx (German)

---
 website/pages/de/archived/arbitrum/arbitrum-faq.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/archived/arbitrum/arbitrum-faq.mdx b/website/pages/de/archived/arbitrum/arbitrum-faq.mdx
index 9ed1396ab31a..54809f94fd9c 100644
--- a/website/pages/de/archived/arbitrum/arbitrum-faq.mdx
+++ b/website/pages/de/archived/arbitrum/arbitrum-faq.mdx
@@ -41,7 +41,7 @@ Um die Vorteile von The Graph auf L2 zu nutzen, verwenden Sie diesen Dropdown-Sc
 
 ## Was muss ich als Entwickler von Subgraphen, Datenkonsument, Indexer, Kurator oder Delegator jetzt tun?
 
-Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+Netzwerk-Teilnehmer müssen zu Arbitrum wechseln, um weiterhin am The Graph Network teilnehmen zu können. Weitere Unterstützung finden Sie im [Leitfaden zum L2 Transfer Tool](/archived/arbitrum/l2-transfer-tools-guide/).
 
 Alle Indexierungsprämien sind jetzt vollständig auf Arbitrum.
 
@@ -53,7 +53,7 @@ Alles wurde gründlich getestet, und es gibt einen Notfallplan, um einen sichere
 
 ## Funktionieren die vorhandenen Subgraphen auf Ethereum?
 
-All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+Alle Subgraphen sind jetzt auf Arbitrum. Bitte lesen Sie den [Leitfaden zum L2 Transfer Tool](/archived/arbitrum/l2-transfer-tools-guide/), um sicherzustellen, dass Ihre Subgraphen reibungslos funktionieren.
 
 ## Verfügt GRT über einen neuen Smart Contract, der auf Arbitrum eingesetzt wird?
 

From 28e46557e709e72c8708dde0857594684401f591 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 07:11:46 -0500
Subject: [PATCH 2796/3820] New translations starting-your-subgraph.mdx
 (French)

---
 .../developing/creating/starting-your-subgraph.mdx          | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx
index bd3e033c26d6..a7ec522f9476 100644
--- a/website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -1,12 +1,12 @@
 ---
-title: Starting Your Subgraph
+title: Démarrer votre subgraph
 ---
 
 ## Aperçu
 
-The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+The Graph contient des milliers de subgraphs déjà disponibles pour des requêtes. Consultez [The Graph Explorer](https://thegraph.com/explorer) et trouvez-en un qui correspond déjà à vos besoins.
 
-When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+Lorsque vous créez un [subgraph](/subgraphs/developing/subgraphs/), vous créez une API ouverte personnalisée qui extrait des données d'une blockchain, les traite, les stocke et les rend faciles à interroger via GraphQL.
 
 Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
 

From 1e9adeaca9783a7804b65c703ad601beebd45780 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 07:11:48 -0500
Subject: [PATCH 2797/3820] New translations l2-transfer-tools-faq.mdx (German)

---
 website/pages/de/archived/arbitrum/l2-transfer-tools-faq.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/de/archived/arbitrum/l2-transfer-tools-faq.mdx
index d5b536456532..424dc0abc1d9 100644
--- a/website/pages/de/archived/arbitrum/l2-transfer-tools-faq.mdx
+++ b/website/pages/de/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -14,7 +14,7 @@ Für diese Tools müssen Sie eine Reihe von Schritten befolgen, je nachdem, welc
 
 ### Kann ich dieselbe Wallet verwenden, die ich im Ethereum Mainnet benutze?
 
-If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+Wenn Sie eine [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account)-Wallet verwenden, können Sie dieselbe Adresse verwenden. Wenn Ihre Ethereum Mainnet Wallet ein Vertrag ist (z.B. eine Multisig), dann müssen Sie eine [Arbitrum Wallet Adresse](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) angeben, an die Ihr Transfer gesendet wird. Bitte überprüfen Sie die Adresse sorgfältig, da Überweisungen an eine falsche Adresse zu einem dauerhaften Verlust führen können. Wenn Sie einen Multisig auf L2 verwenden möchten, stellen Sie sicher, dass Sie einen Multisig-Vertrag auf Arbitrum One einsetzen.
 
 Wallets auf EVM-Blockchains wie Ethereum und Arbitrum bestehen aus einem Paar von Schlüsseln (öffentlich und privat), die Sie erstellen, ohne mit der Blockchain interagieren zu müssen. Jede Wallet, die für Ethereum erstellt wurde, funktioniert also auch auf Arbitrum, ohne dass Sie etwas anderes tun müssen.
 

From ced24f56d5854769692ab5fe301e80c6c47b4b1e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 07:11:50 -0500
Subject: [PATCH 2798/3820] New translations l2-transfer-tools-guide.mdx
 (German)

---
 .../pages/de/archived/arbitrum/l2-transfer-tools-guide.mdx    | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/de/archived/arbitrum/l2-transfer-tools-guide.mdx
index 9df828a8b1fa..873a65844c82 100644
--- a/website/pages/de/archived/arbitrum/l2-transfer-tools-guide.mdx
+++ b/website/pages/de/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -4,9 +4,9 @@ title: L2 Transfer Tools Guide
 
 The Graph hat den Wechsel zu L2 auf Arbitrum One leicht gemacht. Für jeden Protokollteilnehmer gibt es eine Reihe von L2-Transfer-Tools, um den Transfer zu L2 für alle Netzwerkteilnehmer nahtlos zu gestalten. Je nachdem, was Sie übertragen möchten, müssen Sie eine bestimmte Anzahl von Schritten befolgen.
 
-Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+Einige häufig gestellte Fragen zu diesen Tools werden in den [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/) beantwortet. Die FAQs enthalten ausführliche Erklärungen zur Verwendung der Tools, zu ihrer Funktionsweise und zu den Dingen, die bei ihrer Verwendung zu beachten sind.
 
-## So übertragen Sie Ihren Untergraphen auf Arbitrum (L2)
+## So übertragen Sie Ihren Subgraphen auf Arbitrum (L2)
 
 <VideoEmbed youtube="R8_vz4lx2Co" />
 

From 9d2646a3cf94f68921a7813c2c13fab1c089fd88 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 07:11:51 -0500
Subject: [PATCH 2799/3820] New translations sunrise.mdx (German)

---
 website/pages/de/archived/sunrise.mdx | 44 +++++++++++++--------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/website/pages/de/archived/sunrise.mdx b/website/pages/de/archived/sunrise.mdx
index f9419c36d642..0c8253ba2b2c 100644
--- a/website/pages/de/archived/sunrise.mdx
+++ b/website/pages/de/archived/sunrise.mdx
@@ -1,46 +1,46 @@
 ---
-title: Post-Sunrise + Upgrading to The Graph Network FAQ
+title: Post-Sunrise + Upgrade auf The Graph Network FAQ
 ---
 
-> Note: The Sunrise of Decentralized Data ended June 12th, 2024.
+> Hinweis: Die Sunrise der dezentralisierten Daten endete am 12. Juni 2024.
 
-## What was the Sunrise of Decentralized Data?
+## Was war die Sunrise der dezentralisierten Daten?
 
-The Sunrise of Decentralized Data was an initiative spearheaded by Edge & Node. This initiative enabled subgraph developers to upgrade to The Graph’s decentralized network seamlessly.
+Die Sunrise of Decentralized Data war eine Initiative, die von Edge & Node angeführt wurde. Diese Initiative ermöglichte es Subgraph-Entwicklern, nahtlos auf das dezentrale Netzwerk von The Graph zu wechseln.
 
-This plan drew on previous developments from The Graph ecosystem, including an upgrade Indexer to serve queries on newly published subgraphs.
+Dieser Plan stützt sich auf frühere Entwicklungen des Graph-Ökosystems, einschließlich eines aktualisierten Indexers, der Abfragen auf neu veröffentlichte Subgraphen ermöglicht.
 
-### What happened to the hosted service?
+### Was ist mit dem gehosteten Dienst passiert?
 
-The hosted service query endpoints are no longer available, and developers cannot deploy new subgraphs on the hosted service.
+Die Query-Endpunkte des gehosteten Dienstes sind nicht mehr verfügbar, und Entwickler können keine neuen Subgraphen für den gehosteten Dienst bereitstellen.
 
-During the upgrade process, owners of hosted service subgraphs could upgrade their subgraphs to The Graph Network. Additionally, developers were able to claim auto-upgraded subgraphs.
+Während des Upgrade-Prozesses konnten die Besitzer von gehosteten Service-Subgraphen ihre Subgraphen auf The Graph Network aktualisieren. Außerdem konnten Entwickler automatisch aktualisierte Subgraphen beanspruchen.
 
-### Was Subgraph Studio impacted by this upgrade?
+### Wurde Subgraph Studio durch dieses Upgrade beeinträchtigt?
 
-No, Subgraph Studio was not impacted by Sunrise. Subgraphs were immediately available for querying, powered by the upgrade Indexer, which uses the same infrastructure as the hosted service.
+Nein, Subgraph Studio wurde durch Sunrise nicht beeinträchtigt. Subgraphen standen sofort für Abfragen zur Verfügung, angetrieben durch den Upgrade Indexer, der die gleiche Infrastruktur wie der gehostete Dienst nutzt.
 
-### Why were subgraphs published to Arbitrum, did it start indexing a different network?
+### Warum wurden Subgraphen auf Arbitrum veröffentlicht, hat es begonnen, ein anderes Netzwerk zu indizieren?
 
-The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+Das Graph Network wurde zunächst auf dem Ethereum Mainnet eingesetzt, wurde aber später auf Arbitrum One verschoben, um die Gaskosten für alle Nutzer zu senken. Infolgedessen werden alle neuen Subgraphen im Graph Network auf Arbitrum veröffentlicht, damit Indexer sie unterstützen können. Arbitrum ist das Netzwerk, in dem Subgraphen veröffentlicht werden, aber Subgraphen können jedes der [unterstützten Netzwerke](/supported-networks/) indizieren.
 
-## About the Upgrade Indexer
+## Über den Upgrade Indexer
 
-> The upgrade Indexer is currently active.
+> Der Upgrade Indexer ist derzeit aktiv.
 
-The upgrade Indexer was implemented to improve the experience of upgrading subgraphs from the hosted service to The Graph Network and support new versions of existing subgraphs that had not yet been indexed.
+Der Upgrade Indexer wurde implementiert, um das Upgrade von Subgraphen vom gehosteten Dienst zu The Graph Network zu verbessern und neue Versionen von bestehenden Subgraphen, die noch nicht indiziert wurden, zu unterstützen.
 
-### What does the upgrade Indexer do?
+### Was macht der Upgrade Indexer?
 
-- It bootstraps chains that have yet to receive indexing rewards on The Graph Network and ensures that an Indexer is available to serve queries as quickly as possible after a subgraph is published.
-- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
-- Indexers that operate an upgrade Indexer do so as a public service to support new subgraphs and additional chains that lack indexing rewards before The Graph Council approves them.
+- Er bootet Ketten, die noch keinen Reward für die Indizierung im The Graph Network erhalten haben, und stellt sicher, dass ein Indexer zur Verfügung steht, um Anfragen so schnell wie möglich zu bedienen, nachdem ein Subgraph veröffentlicht wurde.
+- Er unterstützt Ketten, die bisher nur über den gehosteten Dienst verfügbar waren. Eine umfassende Liste der unterstützten Ketten finden Sie [hier](/supported-networks/).
+- Indexer, die einen Upgrade Indexer betreiben, tun dies als öffentlichen Dienst, um neue Subgraphen und zusätzliche Ketten zu unterstützen, für die es noch keine Rewards gibt, bevor sie vom The Graph Council genehmigt werden.
 
-### Why is Edge & Node running the upgrade Indexer?
+### Warum führen Edge & Node den Upgrade Indexer aus?
 
-Edge & Node historically maintained the hosted service and, as a result, already have synced data for hosted service subgraphs.
+Edge & Node haben in der Vergangenheit den gehosteten Dienst gewartet und verfügen daher bereits über synchronisierte Daten für Subgraphen des gehosteten Dienstes.
 
-### What does the upgrade indexer mean for existing Indexers?
+### Was bedeutet der Upgrade Indexer für bestehende Indexer?
 
 Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
 

From 0e4d769bdb6cc5495b3c7c2f979448a992d75e6a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 09:10:21 -0500
Subject: [PATCH 2800/3820] New translations starting-your-subgraph.mdx
 (French)

---
 .../creating/starting-your-subgraph.mdx        | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx
index a7ec522f9476..4030093310a4 100644
--- a/website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -8,16 +8,16 @@ The Graph contient des milliers de subgraphs déjà disponibles pour des requêt
 
 Lorsque vous créez un [subgraph](/subgraphs/developing/subgraphs/), vous créez une API ouverte personnalisée qui extrait des données d'une blockchain, les traite, les stocke et les rend faciles à interroger via GraphQL.
 
-Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+Le développement de subgraphs peut aller de simples modèles « scaffold » à des subgraphs avancés, spécialement adaptés à vos besoins.
 
-### Start Building
+### Commencez à développer
 
-Start the process and build a subgraph that matches your needs:
+Lancez le processus et construisez un subgraph qui correspond à vos besoins :
 
-1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
-2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
-3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
-4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
-5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+1. [Installer la CLI](/subgraphs/developing/creating/install-the-cli/) - Configurez votre infrastructure
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Comprenez le composant clé d'un subgraph
+3. [Le schéma GraphQL](/subgraphs/developing/creating/ql-schema/) - Écrivez votre schéma
+4. [Écrire les mappings AssemblyScript](/subgraphs/developing/creating/assemblyscript-mappings/) - Rédigez vos mappings
+5. [Fonctionnalités avancées](/subgraphs/developing/creating/advanced/) - Personnalisez votre subgraphs avec des fonctionnalités avancées
 
-Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).
+Explorez d'autres [ressources pour les API](/subgraphs/developing/creating/graph-ts/README/) et effectuez des tests en local avec [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).

From 212f44fafa3d0490f817a670834c0db133841652 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 09:10:22 -0500
Subject: [PATCH 2801/3820] New translations advanced.mdx (French)

---
 .../developing/creating/advanced.mdx          | 58 +++++++++----------
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/advanced.mdx b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
index 04392cf899e6..98b8d589ff84 100644
--- a/website/pages/fr/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
@@ -1,5 +1,5 @@
 ---
-title: Advanced Subgraph Features
+title: Fonctionnalités avancées des subgraphs
 ---
 
 ## Aperçu
@@ -67,7 +67,7 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 - `min`: Minimum value.
 - `max`: Maximum value.
 - `first`: First value in the period.
-- `last`: Last value in the period.
+- `last` : Dernière valeur de la période.
 
 #### Exemple de requête d'Agrégations
 
@@ -147,13 +147,13 @@ Plutôt que de récupérer les fichiers "ligne par ligne" pendant l'exécution d
 
 This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
 
-> This replaces the existing `ipfs.cat` API
+> Cela remplace l'API `ipfs.cat` existante
 
 ### Guide de mise à niveau
 
-#### Update `graph-ts` and `graph-cli`
+#### Mise à jour de `graph-ts` et `graph-cli`
 
-File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+Les fichiers sources de données requièrent graph-ts >=0.29.0 et graph-cli >=0.33.1
 
 #### Ajouter un nouveau type d'entité qui sera mis à jour lorsque des fichiers seront trouvés
 
@@ -202,9 +202,9 @@ type TokenMetadata @entity {
 
 Si la relation est 1:1 entre l'entité parent et l'entité de source de données de fichier résultante, le modèle le plus simple consiste à lier l'entité parent à une entité de fichier résultante en utilisant le CID IPFS comme recherche. Contactez Discord si vous rencontrez des difficultés pour modéliser vos nouvelles entités basées sur des fichiers !
 
-> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+> Vous pouvez utiliser [les filtres imbriqués](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) pour filtrer les entités parents sur la base de ces entités imbriquées.
 
-#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+#### Ajouter une nouvelle source de données modélisée avec `kind : file/ipfs` ou `kind : file/arweave`
 
 Il s'agit de la source de données qui sera générée lorsqu'un fichier d'intérêt est identifié.
 
@@ -224,15 +224,15 @@ templates:
           file: ./abis/Token.json
 ```
 
-> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+> Actuellement, les `abis` sont nécessaires, bien qu'il ne soit pas possible d'appeler des contrats à partir de fichiers sources de données
 
-The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+Le fichier source de données doit mentionner spécifiquement tous les types d'entités avec lesquels elle interagira sous `entities`. Voir [limitations](#limitations) pour plus de détails.
 
 #### Créer un nouveau gestionnaire pour traiter les fichiers
 
-This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+Ce gestionnaire devrait accepter un paramètre `Bytes`, qui sera le contenu du fichier, lorsqu'il sera trouvé, il pourra alors être traité. Il s'agira souvent d'un fichier JSON, qui peut être traité à l'aide des utilitaires de `graph-ts` ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
 
-The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+Le CID du fichier sous forme de chaîne de caractères lisible est accessible via `dataSource` de la manière suivante :
 
 ```typescript
 const cid = dataSource.stringParam()
@@ -269,12 +269,12 @@ export function handleMetadata(content: Bytes): void {
 
 Vous pouvez désormais créer des sources de données de fichiers lors de l'exécution de gestionnaires basés sur une chaîne :
 
-- Import the template from the auto-generated `templates`
-- call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
+- Importer le modèle à partir du fichier `templates` généré automatiquement
+- appeler `TemplateName.create(cid : string)` à partir d'un mappage, où le cid est un identifiant de contenu valide pour IPFS ou Arweave
 
-For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
+Pour IPFS, Graph Node prend en charge [les identifiants de contenu v0 et v1](https://docs.ipfs.tech/concepts/content-addressing/), et les identifiants de contenu avec des répertoires (par exemple, `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).
 
-For Arweave, as of version 0.33.0 Graph Node can fetch files stored on Arweave based on their [transaction ID](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) from an Arweave gateway ([example file](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave supports transactions uploaded via Irys (previously Bundlr), and Graph Node can also fetch files based on [Irys manifests](https://docs.irys.xyz/overview/gateways#indexing).
+Pour Arweave, à partir de la version 0.33.0, Graph Node peut récupérer des fichiers stockés sur Arweave sur la base de leur [identifiant de transaction](https://docs.arweave.org/developers/arweave-node-server/http-api#transactions) à partir d'une passerelle Arweave ([exemple de fichier](https://bdxujjl5ev5eerd5ouhhs6o4kjrs4g6hqstzlci5pf6vhxezkgaa.arweave.net/CO9EpX0lekJEfXUOeXncUmMuG8eEp5WJHXl9U9yZUYA)). Arweave prend en charge les transactions téléchargées via Irys (anciennement Bundlr), et Graph Node peut également récupérer des fichiers sur la base les [manifestes Irys](https://docs.irys.xyz/overview/gateways#indexing).
 
 L'exemple:
 
@@ -307,15 +307,15 @@ export function handleTransfer(event : TransferEvent) : void {
 
 Cela créera une nouvelle source de données de fichier, qui interrogera le point d'extrémité IPFS ou Arweave configuré du nœud de graphique, en réessayant si elle n'est pas trouvée. Lorsque le fichier est trouvé, le gestionnaire de la source de données de fichier est exécuté.
 
-This example is using the CID as the lookup between the parent `Token` entity and the resulting `TokenMetadata` entity.
+Cet exemple utilise le CID comme référence entre l'entité parent `Token` et l'entité résultante `TokenMetadata`.
 
-> Previously, this is the point at which a subgraph developer would have called `ipfs.cat(CID)` to fetch the file
+> Auparavant, c'est à ce stade qu'un développeur de subgraphs aurait appelé `ipfs.cat(CID)` pour récupérer le fichier
 
 Félicitations, vous utilisez des sources de données de fichiers !
 
 #### Déployer vos subgraphs
 
-You can now `build` and `deploy` your subgraph to any Graph Node >=v0.30.0-rc.0.
+Vous pouvez maintenant `construire` et `déployer` votre subgraph sur n'importe quel Graph Node >=v0.30.0-rc.0.
 
 #### Limitations
 
@@ -333,29 +333,29 @@ En outre, il n'est pas possible de créer des sources de données à partir d'un
 
 Si vous liez des métadonnées NFT aux jetons correspondants, utilisez le hachage IPFS des métadonnées pour référencer une entité Metadata à partir de l'entité Token. Enregistrez l'entité Metadata en utilisant le hachage IPFS comme identifiant.
 
-You can use [DataSource context](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) when creating File Data Sources to pass extra information which will be available to the File Data Source handler.
+Vous pouvez utiliser [Le contexte de DataSource](/subgraphs/developing/creating/graph-ts/api/#entity-and-datasourcecontext) lors de la création de fichiers sources de données(File Data Sources) pour transmettre des informations supplémentaires qui seront disponibles pour le gestionnaire de la File Data Source.
 
-If you have entities which are refreshed multiple times, create unique file-based entities using the IPFS hash & the entity ID, and reference them using a derived field in the chain-based entity.
+Si vous avez des entités qui sont actualisées plusieurs fois, créez des entités uniques basées sur des fichiers en utilisant le hash IPFS & l'ID de l'entité, puis référencez-les en utilisant un champ dérivé dans l'entité basée sur la chaîne.
 
 > Nous travaillons à l'amélioration de la recommandation ci-dessus, afin que les requêtes ne renvoient que la version "la plus récente"
 
 #### Problèmes connus
 
-File data sources currently require ABIs, even though ABIs are not used ([issue](https://github.com/graphprotocol/graph-cli/issues/961)). Workaround is to add any ABI.
+Les fichiers sources de données nécessitent actuellement des ABI, même si les ABI ne sont pas utilisées ([problème](https://github.com/graphprotocol/graph-cli/issues/961)). La solution consiste à ajouter n'importe quel ABI.
 
-Handlers for File Data Sources cannot be in files which import `eth_call` contract bindings, failing with "unknown import: `ethereum::ethereum.call` has not been defined" ([issue](https://github.com/graphprotocol/graph-node/issues/4309)). Workaround is to create file data source handlers in a dedicated file.
+Les gestionnaires pour les fichiers sources de données ne peuvent pas être dans des fichiers qui importent des liaisons de contrat `eth_call`, échouant avec "unknown import : `ethereum::ethereum.call` n'a pas été défini" ([problème](https://github.com/graphprotocol/graph-node/issues/4309)). La solution consiste à créer des gestionnaires de fichiers de sources de données dans un fichier dédié.
 
 #### Exemples
 
-[Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
+[migration de subgraph Crypto Coven ](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
 
 #### Les Références
 
-[GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
+[fichier sources de données GIP](https://forum.thegraph.com/t/gip-file-data-sources/2721)
 
 ## Filtres d'Arguments indexés / Filtres de Topics
 
-> **Requires**: [SpecVersion](#specversion-releases) >= `1.2.0`
+> **Nécessite** : [SpecVersion](#specversion-releases) >= `1.2.0`
 
 Les filtres de topics, également connus sous le nom de filtres d'arguments indexés, sont une fonctionnalité puissante dans les subgraphs qui permettent aux utilisateurs de filtrer précisément les événements de la blockchain en fonction des valeurs de leurs arguments indexés.
 
@@ -367,7 +367,7 @@ Les filtres de topics, également connus sous le nom de filtres d'arguments inde
 
 Lorsqu'un contrat intelligent émet un événement, tous les arguments marqués comme indexés peuvent être utilisés comme filtres dans le manifeste d'un subgraph. Ceci permet au subgraph d'écouter de façon sélective les événements qui correspondent à ces arguments indexés.
 
-- The event's first indexed argument corresponds to `topic1`, the second to `topic2`, and so on, up to `topic3`, since the Ethereum Virtual Machine (EVM) allows up to three indexed arguments per event.
+- Le premier argument indexé de l'événement correspond à `topic1`, le second à `topic2`, et ainsi de suite, jusqu'à `topic3`, puisque la machine virtuelle Ethereum (EVM) autorise jusqu'à trois arguments indexés par événement.
 
 ```solidity
 // SPDX-License-Identifier: MIT
@@ -387,9 +387,9 @@ contract Token {
 
 Dans cet exemple:
 
-- The `Transfer` event is used to log transactions of tokens between addresses.
-- The `from` and `to` parameters are indexed, allowing event listeners to filter and monitor transfers involving specific addresses.
-- The `transfer` function is a simple representation of a token transfer action, emitting the Transfer event whenever it is called.
+- L'événement `Transfer` est utilisé pour enregistrer les transactions de jetons entre adresses.
+- Les paramètres `from` et `to` sont indexés, ce qui permet aux auditeurs d'événements de filtrer et de surveiller les transferts impliquant des adresses spécifiques.
+- La fonction `transfer` est une représentation simple d'une action de transfert de jeton, émettant l'événement Transfer à chaque fois qu'elle est appelée.
 
 #### Configuration dans les subgraphs
 

From d6d63678749700b52b390537d54bea3a639d20ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 10:21:08 -0500
Subject: [PATCH 2802/3820] New translations advanced.mdx (French)

---
 .../developing/creating/advanced.mdx          | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/advanced.mdx b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
index 98b8d589ff84..6da004f8feb1 100644
--- a/website/pages/fr/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
@@ -406,7 +406,7 @@ eventHandlers:
 
 Dans cette configuration :
 
-- `topic1` corresponds to the first indexed argument of the event, `topic2` to the second, and `topic3` to the third.
+- `topic1` correspond au premier argument indexé de l'événement, `topic2` au deuxième et `topic3` au troisième.
 - Chaque topic peut avoir une ou plusieurs valeurs, et un événement n'est traité que s'il correspond à l'une des valeurs de chaque rubrique spécifiée.
 
 #### Logique des Filtres
@@ -426,9 +426,9 @@ eventHandlers:
 
 Dans cette configuration:
 
-- `topic1` is configured to filter `Transfer` events where `0xAddressA` is the sender.
-- `topic2` is configured to filter `Transfer` events where `0xAddressB` is the receiver.
-- The subgraph will only index transactions that occur directly from `0xAddressA` to `0xAddressB`.
+- `topic1` est configuré pour filtrer les événements `Transfer` dont l'expéditeur est `0xAddressA`.
+- `topic2` est configuré pour filtrer les événements `Transfer` dont `0xAddressB` est le destinataire.
+- Le subgraph n'indexera que les transactions qui se produisent directement de `0xAddressA` à `0xAddressB`.
 
 #### Exemple 2 : Suivi des transactions dans les deux sens entre deux ou plusieurs adresses
 
@@ -442,15 +442,15 @@ eventHandlers:
 
 Dans cette configuration:
 
-- `topic1` is configured to filter `Transfer` events where `0xAddressA`, `0xAddressB`, `0xAddressC` is the sender.
-- `topic2` is configured to filter `Transfer` events where `0xAddressB` and `0xAddressC` is the receiver.
+- `topic1` est configuré pour filtrer les événements `Transfer` dont l'expéditeur est `0xAddressA`, `0xAddressB`, `0xAddressC`.
+- `topic2` est configuré pour filtrer les événements `Transfer` où `0xAddressB` et `0xAddressC` sont les destinataires.
 - Le subgraph indexera les transactions qui se produisent dans les deux sens entre plusieurs adresses, permettant une surveillance complète des interactions impliquant toutes les adresses.
 
 ## Déclaration eth_call
 
 > Remarque : Il s'agit d'une fonctionnalité expérimentale qui n'est pas encore disponible dans une version stable de Graph Node. Vous ne pouvez l'utiliser que dans Subgraph Studio ou sur votre nœud auto-hébergé.
 
-Declarative `eth_calls` are a valuable subgraph feature that allows `eth_calls` to be executed ahead of time, enabling `graph-node` to execute them in parallel.
+Les `eth_calls' déclaratifs sont une caractéristique précieuse des subgraphs qui permet aux `eth_calls' d'être exécutés à l'avance, ce qui permet à `graph-node` de les exécuter en parallèle.
 
 Cette fonctionnalité permet de :
 
@@ -460,11 +460,11 @@ Cette fonctionnalité permet de :
 
 ### Concepts clés
 
-- Declarative `eth_calls`: Ethereum calls that are defined to be executed in parallel rather than sequentially.
+- Les `eth_calls` déclaratifs : Appels Ethereum qui sont définis pour être exécutés en parallèle plutôt que séquentiellement.
 - Exécution en parallèle : Au lieu d'attendre la fin d'un appel avant de commencer le suivant, plusieurs appels peuvent être initiés simultanément.
 - Efficacité temporelle : Le temps total nécessaire pour tous les appels passe de la somme des temps d'appel individuels (séquentiels) au temps pris par l'appel le plus long (parallèle).
 
-#### Scenario without Declarative `eth_calls`
+#### Scénario sans `eth_calls` déclaratifs
 
 Imaginez que vous ayez un subgraph qui doit effectuer trois appels Ethereum pour récupérer des données sur les transactions, le solde et les avoirs en jetons d'un utilisateur.
 
@@ -476,7 +476,7 @@ Traditionnellement, ces appels pourraient être effectués de manière séquenti
 
 Temps total pris = 3 + 2 + 4 = 9 secondes
 
-#### Scenario with Declarative `eth_calls`
+#### Scénario avec `eth_calls` déclaratif
 
 Avec cette fonctionnalité, vous pouvez déclarer que ces appels soient exécutés en parallèle :
 
@@ -496,7 +496,7 @@ Temps total pris = max (3, 2, 4) = 4 secondes
 
 #### Exemple de configuration dans le manifeste du subgraph
 
-Declared `eth_calls` can access the `event.address` of the underlying event as well as all the `event.params`.
+Les `eth_calls` déclarés peuvent accéder à l'adresse `event.address` de l'événement sous-jacent ainsi qu'à tous les paramètres `event.params`.
 
 `Subgraph.yaml` using `event.address`:
 

From d27fe018b05602acb61041e7a22012b76bce255c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 10:21:10 -0500
Subject: [PATCH 2803/3820] New translations unit-testing-framework.mdx
 (French)

---
 .../developing/creating/unit-testing-framework.mdx     | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
index 8966cd432eaa..48999feb2122 100644
--- a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -378,7 +378,7 @@ describe("handleNewGravatars, () => {
  ...
 ```
 
-Code inside `beforeEach` will execute only before each test in the that describe
+Le code contenu dans `beforeEach` ne s'exécutera qu'avant chaque test de la description
 
 ```typescript
 import { describe, test, beforeEach } from 'matchstick-as/assembly/index'
@@ -392,19 +392,19 @@ describe('handleUpdatedGravatars', () => {
     gravatar.save()
   })
 
-  test('Updates the displayName', () => {
+  test('Met à jour le nom d'affichage (displayName)', () => {
     assert.fieldEquals('Gravatar', '0x0', 'displayName', 'First Gravatar')
 
-    // code that should update the displayName to 1st Gravatar
+    // code qui devrait mettre à jour le nom d'affichage (displayName) pour le 1er Gravatar
 
     assert.fieldEquals('Gravatar', '0x0', 'displayName', '1st Gravatar')
     store.remove('Gravatar', '0x0')
   })
 
-  test('Updates the imageUrl', () => {
+  test('Met à jour l'imageUrl', () => {
     assert.fieldEquals('Gravatar', '0x0', 'imageUrl', '')
 
-    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+    // code qui devrait changer l'imageUrl en https://www.gravatar.com/avatar/0x0
 
     assert.fieldEquals('Gravatar', '0x0', 'imageUrl', 'https://www.gravatar.com/avatar/0x0')
     store.remove('Gravatar', '0x0')

From 7391ae98a2cc589981951ff616ba2ca45617defa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 12:34:17 -0500
Subject: [PATCH 2804/3820] New translations advanced.mdx (French)

---
 .../subgraphs/developing/creating/advanced.mdx | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/advanced.mdx b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
index 6da004f8feb1..f45731b2168d 100644
--- a/website/pages/fr/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
@@ -498,7 +498,7 @@ Temps total pris = max (3, 2, 4) = 4 secondes
 
 Les `eth_calls` déclarés peuvent accéder à l'adresse `event.address` de l'événement sous-jacent ainsi qu'à tous les paramètres `event.params`.
 
-`Subgraph.yaml` using `event.address`:
+`Subgraph.yaml` utilisant `event.address` :
 
 ```yaml
 eventHandlers:
@@ -511,12 +511,12 @@ calls:
 
 Détails pour l'exemple ci-dessus :
 
-- `global0X128` is the declared `eth_call`.
-- The text (`global0X128`) is the label for this `eth_call` which is used when logging errors.
-- The text (`Pool[event.address].feeGrowthGlobal0X128()`) is the actual `eth_call` that will be executed, which is in the form of `Contract[address].function(arguments)`
-- The `address` and `arguments` can be replaced with variables that will be available when the handler is executed.
+- `global0X128` est le nom déclaré de `eth_call`.
+- Le texte (`global0X128`) est le label de ce `eth_call` qui est utilisé lors de la journalisation des erreurs.
+- Le texte (`Pool[event.address].feeGrowthGlobal0X128()`) est le `eth_call` réel qui sera exécuté, et est sous la forme de `Contract[address].function(arguments)`
+- L'adresse et les arguments peuvent être remplacés par des variables qui seront disponibles lorsque le gestionnaire sera exécuté.
 
-`Subgraph.yaml` using `event.params`
+`Subgraph.yaml` utilisant `event.params`
 
 ```yaml
 calls:
@@ -525,11 +525,11 @@ calls:
 
 ### Greffe sur des subgraphs existants
 
-> **Note:** it is not recommended to use grafting when initially upgrading to The Graph Network. Learn more [here](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
+> **Note:** il n'est pas recommandé d'utiliser le greffage lors de l'upgrade initial vers The Graph Network. Pour en savoir plus [ici](/subgraphs/cookbook/grafting/#important-note-on-grafting-when-upgrading-to-the-network).
 
-When a subgraph is first deployed, it starts indexing events at the genesis block of the corresponding chain (or at the `startBlock` defined with each data source) In some circumstances; it is beneficial to reuse the data from an existing subgraph and start indexing at a much later block. This mode of indexing is called _Grafting_. Grafting is, for example, useful during development to get past simple errors in the mappings quickly or to temporarily get an existing subgraph working again after it has failed.
+Lorsqu'un subgraph est déployé pour la première fois, il commence à indexer les événements au bloc de initial de la blockchain correspondante (ou au `startBlock` défini avec chaque source de données). Dans certaines circonstances, il est avantageux de réutiliser les données d'un subgraph existant et de commencer l'indexation à un bloc beaucoup plus tardif. Ce mode d'indexation est appelé _Grafting_. Le greffage (grafting) est, par exemple, utile pendant le développement pour surmonter rapidement de simples erreurs dans les mappages ou pour faire fonctionner temporairement un subgraph existant après qu'il ait échoué.
 
-A subgraph is grafted onto a base subgraph when the subgraph manifest in `subgraph.yaml` contains a `graft` block at the top-level:
+Un subgraph est greffé sur un subgraph de base lorsque le manifeste du subgraph dans `subgraph.yaml` contient un bloc `graft` au niveau supérieur :
 
 ```yaml
 description: ...

From da145b27217d9c671e85c31962d978eed0f40264 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 12:34:19 -0500
Subject: [PATCH 2805/3820] New translations unit-testing-framework.mdx
 (French)

---
 .../creating/unit-testing-framework.mdx       | 161 +++++++++---------
 1 file changed, 81 insertions(+), 80 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
index 48999feb2122..85280f81b258 100644
--- a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -2,7 +2,7 @@
 title: Cadre pour les tests unitaires
 ---
 
-Learn how to use Matchstick, a unit testing framework developed by [LimeChain](https://limechain.tech/). Matchstick enables subgraph developers to test their mapping logic in a sandboxed environment and successfully deploy their subgraphs.
+Apprenez à utiliser Matchstick, un framework de test unitaire développé par [LimeChain](https://limechain.tech/). Matchstick permet aux développeurs de subgraphs de tester leur logique de mappages dans un environnement sandbox et de déployer avec succès leurs subgraphs.
 
 ## Benefits of Using Matchstick
 
@@ -21,7 +21,7 @@ yarn add --dev matchstick-as
 
 ### Install PostgreSQL
 
-`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+`graph-node` dépend de PostgreSQL, donc si vous ne l'avez pas déjà, vous devrez l'installer.
 
 > Note: It's highly recommended to use the commands below to avoid unexpected errors.
 
@@ -33,7 +33,7 @@ Installation command:
 brew install postgresql
 ```
 
-Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+Créez un lien symbolique vers la dernière version de libpq.5.lib _Vous devrez peut-être créer ce répertoire d'abord_ `/usr/local/opt/postgresql/lib/`
 
 ```sh
 ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
@@ -61,13 +61,13 @@ ou bien
 <PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
 ```
 
-Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+Veuillez vous assurer que vous êtes sur une version plus récente de Node.js graph-cli ne prend plus en charge **v10.19.0**, et c'est toujours la version par défaut pour les nouvelles images Ubuntu sur le WSL. Par exemple, il est confirmé que Matchstick fonctionne sur WSL avec **v18.1.0**, vous pouvez passer à cette version via **nvm** ou si vous mettez à jour votre Node.js global. N'oubliez pas de supprimer `node_modules` et de relancer `npm install` après avoir mis à jour votre nodejs ! Ensuite, assurez-vous que **libpq** est installé, vous pouvez le faire en exécutant
 
 ```
 sudo apt-get install libpq-dev
 ```
 
-And finally, do not use `graph test` (which uses your global installation of graph-cli and for some reason that looks like it's broken on WSL currently), instead use `yarn test` or `npm run test` (that will use the local, project-level instance of graph-cli, which works like a charm). For that you would of course need to have a `"test"` script in your `package.json` file which can be something as simple as
+Et enfin, n'utilisez pas `graph test` (qui utilise votre installation globale de graph-cli et pour une raison quelconque, il semble qu'il soit cassé sur WSL actuellement), utilisez plutôt `yarn test` ou `npm run test` (qui utilisera l'instance locale, au niveau du projet, de graph-cli, ce qui fonctionne comme un charme). Pour cela, vous devez bien sûr avoir un script `" test "` dans votre fichier `package.json` qui peut être quelque chose d'aussi simple que
 
 ```json
 {
@@ -87,7 +87,7 @@ And finally, do not use `graph test` (which uses your global installation of gra
 
 ### Using Matchstick
 
-To use **Matchstick** in your subgraph project just open up a terminal, navigate to the root folder of your project and simply run `graph test [options] <datasource>` - it downloads the latest **Matchstick** binary and runs the specified test or all tests in a test folder (or all existing tests if no datasource flag is specified).
+Pour utiliser **Matchstick** dans votre projet de ssubgraph, ouvrez un terminal, naviguez jusqu'au dossier racine de votre projet et exécutez simplement `graph test [options] <datasource>` - il télécharge le dernier binaire **Matchstick** et exécute le test spécifié ou tous les tests dans un dossier de test (ou tous les tests existants si aucun flag de source de données n'est spécifié).
 
 ### CLI options
 
@@ -112,32 +112,32 @@ graph test path/to/file.test.ts
 **Options:**
 
 ```sh
--c, --coverage                Run the tests in coverage mode
--d, --docker                  Run the tests in a docker container (Note: Please execute from the root folder of the subgraph)
--f, --force                   Binary: Redownloads the binary. Docker: Redownloads the Dockerfile and rebuilds the docker image.
--h, --help                    Show usage information
--l, --logs                    Logs to the console information about the OS, CPU model and download url (debugging purposes)
--r, --recompile               Forces tests to be recompiled
--v, --version <tag>           Choose the version of the rust binary that you want to be downloaded/used
+-c, --coverage                Exécuter les tests en mode couverture
+-d, --docker                  Exécuter les tests dans un conteneur docker (Note : Veuillez exécuter à partir du dossier racine du subgraph)
+-f, --force                   Binaire : Retélécharge le binaire. Docker : Retélécharge le fichier Docker et reconstruit l'image Docker.
+-h, --help                    Affiche les informations d'utilisation
+-l, --logs                    Enregistre dans la console des informations sur le système d'exploitation, le modèle de processeur et l'URL de téléchargement (à des fins de débogage).
+-r, --recompile               Force les tests à être recompilés
+-v, --version <tag>           Choisissez la version du binaire rust que vous souhaitez télécharger/utiliser
 ```
 
 ### Docker
 
-From `graph-cli 0.25.2`, the `graph test` command supports running `matchstick` in a docker container with the `-d` flag. The docker implementation uses [bind mount](https://docs.docker.com/storage/bind-mounts/) so it does not have to rebuild the docker image every time the `graph test -d` command is executed. Alternatively you can follow the instructions from the [matchstick](https://github.com/LimeChain/matchstick#docker-) repository to run docker manually.
+Depuis `graph-cli 0.25.2`, la commande `graph test` supporte l'exécution de `matchstick` dans un conteneur docker avec l'option `-d`. L'implémentation de docker utilise [bind mount](https://docs.docker.com/storage/bind-mounts/) pour ne pas avoir à reconstruire l'image de docker à chaque fois que la commande `graph test -d` est exécutée. Vous pouvez également suivre les instructions du dépôt [matchstick](https://github.com/LimeChain/matchstick#docker-) pour exécuter docker manuellement.
 
-❗ `graph test -d` forces `docker run` to run with flag `-t`. This must be removed to run inside non-interactive environments (like GitHub CI).
+❗ `graph test -d` force `docker run` à s'exécuter avec le flag `-t`. Ceci doit être supprimé pour fonctionner dans des environnements non-interactifs (comme GitHub CI).
 
-❗ If you have previously ran `graph test` you may encounter the following error during docker build:
+❗ Si vous avez précédemment exécuté `graph test`, vous pouvez rencontrer l'erreur suivante lors du build de docker :
 
 ```sh
   error from sender: failed to xattr node_modules/binary-install-raw/bin/binary-<platform>: permission denied
 ```
 
-In this case create a `.dockerignore` in the root folder and add `node_modules/binary-install-raw/bin`
+Dans ce cas, créez un `.dockerignore` dans le dossier racine et ajoutez `node_modules/binary-install-raw/bin`
 
 ### La Configuration
 
-Matchstick can be configured to use a custom tests, libs and manifest path via `matchstick.yaml` config file:
+Matchstick peut être configuré pour utiliser un chemin personnalisé pour les tests, les librairies et les manifestes via le fichier de configuration `matchstick.yaml` :
 
 ```yaml
 testsFolder: path/to/tests
@@ -147,23 +147,23 @@ manifestPath: path/to/subgraph.yaml
 
 ### Subgraph démonstration
 
-You can try out and play around with the examples from this guide by cloning the [Demo Subgraph repo](https://github.com/LimeChain/demo-subgraph)
+Vous pouvez essayer et jouer avec les exemples de ce guide en clonant le [dépôt du Demo Subgraph.](https://github.com/LimeChain/demo-subgraph)
 
 ### Tutoriels vidéos
 
-Also you can check out the video series on ["How to use Matchstick to write unit tests for your subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
+Vous pouvez également consulter la série de vidéos sur [" Comment utiliser Matchstick pour écrire des tests unitaires pour vos subgraphs"](https://www.youtube.com/playlist?list=PLTqyKgxaGF3SNakGQwczpSGVjS_xvOv3h)
 
 ## Structure des tests
 
-_**IMPORTANT: The test structure described below depens on `matchstick-as` version >=0.5.0**_
+_**IMPORTANT : La structure de test décrite ci-dessous dépend de la version de `matchstick-as` >=0.5.0**_
 
 ### décrivez()
 
-`describe(name: String , () => {})` - Defines a test group.
+`describe(name : String , () => {})` - Définit un groupe de test.
 
 **_Notes:_**
 
-- _Describes are not mandatory. You can still use test() the old way, outside of the describe() blocks_
+- _Les descriptions ne sont pas obligatoires. Vous pouvez toujours utiliser test() à l'ancienne, en dehors des blocs describe()_
 
 L'exemple:
 
@@ -172,27 +172,27 @@ import { describe, test } from "matchstick-as/assembly/index"
 import { handleNewGravatar } from "../../src/gravity"
 
 describe("handleNewGravatar()", () => {
-  test("Should create a new Gravatar entity", () => {
+  test("Il faut créer une nouvelle entité Gravatar", () => {
     ...
   })
 })
 ```
 
-Nested `describe()` example:
+Exemple imbriqué de `describe()` :
 
 ```typescript
 import { describe, test } from "matchstick-as/assembly/index"
 import { handleUpdatedGravatar } from "../../src/gravity"
 
 describe("handleUpdatedGravatar()", () => {
-  describe("When entity exists", () => {
-    test("updates the entity", () => {
+  describe("Lorsque l'entité existe", () => {
+    test("met à jour l'entité", () => {
       ...
     })
   })
 
-  describe("When entity does not exists", () => {
-    test("it creates a new entity", () => {
+  describe("Lorsque l'entité n'existe pas", () => {
+    test("il crée une nouvelle entité", () => {
       ...
     })
   })
@@ -203,7 +203,7 @@ describe("handleUpdatedGravatar()", () => {
 
 ### tester ()
 
-`test(name: String, () =>, should_fail: bool)` - Defines a test case. You can use test() inside of describe() blocks or independently.
+`test(name : String, () =>, should_fail : bool)` - Définit un cas de test. Vous pouvez utiliser test() à l'intérieur des blocs describe() ou indépendamment.
 
 L'exemple:
 
@@ -212,7 +212,7 @@ import { describe, test } from "matchstick-as/assembly/index"
 import { handleNewGravatar } from "../../src/gravity"
 
 describe("handleNewGravatar()", () => {
-  test("Should create a new Entity", () => {
+  test("Doit créer une nouvelle entité", () => {
     ...
   })
 })
@@ -221,7 +221,7 @@ describe("handleNewGravatar()", () => {
 ou bien
 
 ```typescript
-test("handleNewGravatar() should create a new entity", () => {
+test("handleNewGravatar() devrait créer une nouvelle entité", () => {
   ...
 })
 
@@ -232,11 +232,11 @@ test("handleNewGravatar() should create a new entity", () => {
 
 ### avantTout()
 
-Runs a code block before any of the tests in the file. If `beforeAll` is declared inside of a `describe` block, it runs at the beginning of that `describe` block.
+Exécute un bloc de code avant tous les tests du fichier. Si `beforeAll` est déclaré à l'intérieur d'un bloc `describe`, il s'exécute au début de ce bloc `describe`.
 
 Les Exemples:
 
-Code inside `beforeAll` will execute once before _all_ tests in the file.
+Le code contenu dans `beforeAll` s'exécutera une fois avant _tous_ les tests du fichier.
 
 ```typescript
 import { describe, test, beforeAll } from "matchstick-as/assembly/index"
@@ -250,20 +250,20 @@ beforeAll(() => {
   ...
 })
 
-describe("When the entity does not exist", () => {
-  test("it should create a new Gravatar with id 0x1", () => {
+describe("Lorsque l'entité n'existe pas", () => {
+  test("il devrait créer un nouveau Gravatar avec l'identifiant 0x1", () => {
     ...
   })
 })
 
-describe("When entity already exists", () => {
-  test("it should update the Gravatar with id 0x0", () => {
+describe("Lorsque l'entité existe déjà", () => {
+  test("il devrait mettre à jour le Gravatar avec l'identifiant 0x0", () => {
     ...
   })
 })
 ```
 
-Code inside `beforeAll` will execute once before all tests in the first describe block
+Le code contenu dans `beforeAll` sera exécuté une fois avant tous les tests du premier bloc de description
 
 ```typescript
 import { describe, test, beforeAll } from "matchstick-as/assembly/index"
@@ -278,11 +278,11 @@ describe("handleUpdatedGravatar()", () => {
     ...
   })
 
-  test("updates Gravatar with id 0x0", () => {
+  test("met à jour le Gravatar avec l'identifiant 0x0", () => {
     ...
   })
 
-  test("creates new Gravatar with id 0x1", () => {
+  test("crée un nouveau Gravatar avec l'identifiant 0x1", () => {
     ...
   })
 })
@@ -292,11 +292,11 @@ describe("handleUpdatedGravatar()", () => {
 
 ### afterAll()
 
-Runs a code block after all of the tests in the file. If `afterAll` is declared inside of a `describe` block, it runs at the end of that `describe` block.
+Exécute un bloc de code après tous les tests du fichier. Si `afterAll` est déclaré à l'intérieur d'un bloc `describe`, il s'exécute à la fin de ce bloc `describe`.
 
 L'exemple:
 
-Code inside `afterAll` will execute once after _all_ tests in the file.
+Le code contenu dans `afterAll` sera exécuté une fois après _tous_ les tests du fichier.
 
 ```typescript
 import { describe, test, afterAll } from "matchstick-as/assembly/index"
@@ -321,7 +321,7 @@ describe("handleUpdatedGravatar", () => {
 })
 ```
 
-Code inside `afterAll` will execute once after all tests in the first describe block
+Le code contenu dans `afterAll` sera exécuté une fois après tous les tests du premier bloc de description
 
 ```typescript
 import { describe, test, afterAll, clearStore } from "matchstick-as/assembly/index"
@@ -333,11 +333,11 @@ describe("handleNewGravatar", () => {
     ...
 	})
 
-  test("It creates a new entity with Id 0x0", () => {
+  test("Il crée une nouvelle entité avec l'identifiant 0x0.", () => {
     ...
   })
 
-  test("It creates a new entity with Id 0x1", () => {
+  test("Il crée une nouvelle entité avec l'identifiant 0x1", () => {
     ...
   })
 })
@@ -353,24 +353,24 @@ describe("handleUpdatedGravatar", () => {
 
 ### beforeEach()
 
-Runs a code block before every test. If `beforeEach` is declared inside of a `describe` block, it runs before each test in that `describe` block.
+Exécute un bloc de code avant chaque test. Si `beforeEach` est déclaré à l'intérieur d'un bloc `describe`, il s'exécute avant chaque test dans ce bloc `describe`.
 
-Examples: Code inside `beforeEach` will execute before each tests.
+Exemples : Le code contenu dans `beforeEach` sera exécuté avant chaque test.
 
 ```typescript
 import { describe, test, beforeEach, clearStore } from "matchstick-as/assembly/index"
 import { handleNewGravatars } from "./utils"
 
 beforeEach(() => {
-  clearStore() // <-- clear the store before each test in the file
+  clearStore() // <-- nettoye le store avant chaque test dans le fichier
 })
 
 describe("handleNewGravatars, () => {
-  test("A test that requires a clean store", () => {
+  test("Un test qui nécessite un store propre", () => {
     ...
   })
 
-  test("Second that requires a clean store", () => {
+  test("Second, qui nécessite un store propre", () => {
     ...
   })
 })
@@ -1202,7 +1202,7 @@ type TokenLockMetadata @entity {
 }
 ```
 
-##### Example `metadata.json`
+##### Exemple `metadata.json`
 
 ```json
 {
@@ -1216,10 +1216,10 @@ type TokenLockMetadata @entity {
 ##### Exemple de gestionnaire
 
 ```typescript
-export function handleMetadata(content: Bytes): void {
-  // dataSource.stringParams() returns the File DataSource CID
-  // stringParam() will be mocked in the handler test
-  // for more info https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
+export function handleMetadata(content : Bytes) : void {
+  // dataSource.stringParams() renvoie le CID du fichier de la source de données 
+  // stringParam() sera simulé dans le test du gestionnaire
+  // pour plus d'informations https://thegraph.com/docs/en/developing/creating-a-subgraph/#create-a-new-handler-to-process-files
   let tokenMetadata = new TokenLockMetadata(dataSource.stringParam())
   const value = json.fromBytes(content).toObject()
 
@@ -1251,60 +1251,61 @@ import { handleMetadata } from '../../src/token-lock-wallet'
 import { TokenLockMetadata } from '../../generated/schema'
 import { GraphTokenLockMetadata } from '../../generated/templates'
 
-test('file/ipfs dataSource creation example', () => {
-  // Generate the dataSource CID from the ipfsHash + ipfs path file
-  // For example QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
+test('exemple de création d'une dataSource file/ipfs', () => {
+  // Générer le CID de la source de données à partir du fichier ipfsHash + chemin ipfs
+  // Par exemple QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm/example.json
   const ipfshash = 'QmaXzZhcYnsisuue5WRdQDH6FDvqkLQX1NckLqBYeYYEfm'
   const CID = `${ipfshash}/example.json`
 
-  // Create a new dataSource using the generated CID
+  // Créer une nouvelle dataSource en utilisant le CID généré
   GraphTokenLockMetadata.create(CID)
 
-  // Assert the dataSource has been created
+  // Affirmer que la dataSource a été créée
   assert.dataSourceCount('GraphTokenLockMetadata', 1)
   assert.dataSourceExists('GraphTokenLockMetadata', CID)
   logDataSources('GraphTokenLockMetadata')
 
-  // Now we have to mock the dataSource metadata and specifically dataSource.stringParam()
-  // dataSource.stringParams actually uses the value of dataSource.address(), so we will mock the address using dataSourceMock from  matchstick-as
-  // First we will reset the values and then use dataSourceMock.setAddress() to set the CID
+  // Nous devons maintenant simuler les métadonnées de la dataSource et plus particulièrement dataSource.stringParam()
+  // dataSource.stringParams utilise en fait la valeur de dataSource.address(), nous allons donc simuler l'adresse en utilisant dataSourceMock de matchstick-as
+  // Nous allons d'abord réinitialiser les valeurs, puis utiliser dataSourceMock.setAddress() pour définir le CID.
   dataSourceMock.resetValues()
   dataSourceMock.setAddress(CID)
 
-  // Now we need to generate the Bytes to pass to the dataSource handler
-  // For this case we introduced a new function readFile, that reads a local json and returns the content as Bytes
+
+  // Nous devons maintenant générer les octets à transmettre au gestionnaire de la dataSource.
+  // Pour ce cas, nous avons introduit une nouvelle fonction readFile, qui lit un json local et renvoie le contenu sous forme d'octets
   const content = readFile(`path/to/metadata.json`)
   handleMetadata(content)
 
-  // Now we will test if a TokenLockMetadata was created
+  // Maintenant nous allons tester si un TokenLockMetadata a été créé
   const metadata = TokenLockMetadata.load(CID)
 
-  assert.bigIntEquals(metadata!.endTime, BigInt.fromI32(1))
-  assert.bigIntEquals(metadata!.periods, BigInt.fromI32(1))
-  assert.bigIntEquals(metadata!.releaseStartTime, BigInt.fromI32(1))
-  assert.bigIntEquals(metadata!.startTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata !.endTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata !.periods, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata !.releaseStartTime, BigInt.fromI32(1))
+  assert.bigIntEquals(metadata !.startTime, BigInt.fromI32(1))
 })
 ```
 
 ## Couverture de test
 
-Using **Matchstick**, subgraph developers are able to run a script that will calculate the test coverage of the written unit tests.
+En utilisant **Matchstick**, les développeurs de subgraphs peuvent exécuter un script qui calculera la couverture des tests unitaires écrits.
 
-The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
+L'outil de couverture des tests prend les binaires de test compilés `wasm` et les convertit en fichiers `wat`, qui peuvent alors être facilement inspectés pour voir si les gestionnaires définis dans `subgraph.yaml` ont été appelés ou non. Comme la couverture du code (et les tests dans leur ensemble) n'en est qu'à ses débuts en AssemblyScript et WebAssembly, **Matchstick** ne peut pas vérifier la couverture des branches. Au lieu de cela, nous nous appuyons sur l'affirmation que si un gestionnaire donné a été appelé, l'événement/la fonction correspondant(e) a été correctement simulé(e).
 
 ### Conditions préalables
 
-To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
+Pour utiliser la fonctionnalité de couverture des tests fournie dans **Matchstick**, il y a quelques éléments à préparer à l'avance :
 
 #### Exportez vos gestionnaires
 
-In order for **Matchstick** to check which handlers are being run, those handlers need to be exported from the **test file**. So for instance in our example, in our gravity.test.ts file we have the following handler being imported:
+Pour que **Matchstick** puisse vérifier quels handlers sont exécutés, ces handlers doivent être exportés depuis le **fichier de test**. Ainsi, dans notre exemple, dans notre fichier gravity.test.ts, nous avons importé le gestionnaire suivant :
 
 ```typescript
 importez { handleNewGravatar } from '../../src/gravity'
 ```
 
-In order for that function to be visible (for it to be included in the `wat` file **by name**) we need to also export it, like this:
+Pour que cette fonction soit visible (pour qu'elle soit incluse dans le fichier `wat` **par nom**), nous devons également l'exporter, comme ceci :
 
 ```typescript
 exportez { handleNewGravatar }
@@ -1318,7 +1319,7 @@ Une fois tout configuré, pour exécuter l'outil de couverture de test, exécute
 graph test -- -c
 ```
 
-You could also add a custom `coverage` command to your `package.json` file, like so:
+Vous pouvez également ajouter une commande `coverage` personnalisée à votre fichier `package.json`, comme ceci :
 
 ```typescript
  "scripts": {
@@ -1376,7 +1377,7 @@ La sortie du journal inclut la durée de l’exécution du test. Voici un exempl
 
 > Critique : impossible de créer WasmInstance à partir d'un module valide avec un contexte : importation inconnue : wasi_snapshot_preview1::fd_write n'a pas été défini
 
-This means you have used `console.log` in your code, which is not supported by AssemblyScript. Please consider using the [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
+Ceci signifie que vous avez utilisé `console.log` dans votre code, qui n'est pas pris en charge par AssemblyScript. Veuillez considérer l'utilisation de [Logging API](/subgraphs/developing/creating/graph-ts/api/#logging-api)
 
 > ERREUR TS2554 : attendu ? arguments, mais j'ai eu ?.
 >
@@ -1390,11 +1391,11 @@ This means you have used `console.log` in your code, which is not supported by A
 >
 > dans ~lib/matchstick-as/assembly/defaults.ts(24,12)
 
-The mismatch in arguments is caused by mismatch in `graph-ts` and `matchstick-as`. The best way to fix issues like this one is to update everything to the latest released version.
+La non-concordance des arguments est causée par la non-concordance de `graph-ts` et de `matchstick-as`. La meilleure façon de résoudre des problèmes comme celui-ci est de tout mettre à jour vers la dernière version publiée.
 
 ## Ressources supplémentaires
 
-For any additional support, check out this [demo subgraph repo using Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
+Pour toute aide supplémentaire, consultez cette [démo de subgraph utilisant Matchstick](https://github.com/LimeChain/demo-subgraph#readme_).
 
 ## Réaction
 

From 2a925f703b1c612b380a33bd88d4f1ed0a21014c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 12:34:20 -0500
Subject: [PATCH 2806/3820] New translations common-issues.mdx (French)

---
 .../fr/subgraphs/developing/creating/graph-ts/common-issues.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/graph-ts/common-issues.mdx b/website/pages/fr/subgraphs/developing/creating/graph-ts/common-issues.mdx
index 37d2e382794e..a946b30a71b1 100644
--- a/website/pages/fr/subgraphs/developing/creating/graph-ts/common-issues.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/graph-ts/common-issues.mdx
@@ -4,5 +4,5 @@ title: Common AssemblyScript Issues
 
 Il existe certains problèmes courants avec [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) lors du développement de subgraph. Ces problèmes varient en termes de difficulté de débogage, mais les connaître peut être utile. Voici une liste non exhaustive de ces problèmes :
 
-- `Private` class variables are not enforced in [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). There is no way to protect class variables from being directly changed from the class object.
+- Les variables de classe `Private` ne sont pas appliquées dans [AssemblyScript](https://www.assemblyscript.org/status.html#language-features). Il n'y a aucun moyen de protéger les variables de classe d'une modification directe à partir de l'objet de la classe.
 - La portée n'est pas héritée dans les [fonctions de fermeture] (https://www.assemblyscript.org/status.html#on-closures), c'est-à-dire que les variables déclarées en dehors des fonctions de fermeture ne peuvent pas être utilisées. Explication dans les [Developer Highlights #3](https://www.youtube.com/watch?v=1-8AW-lVfrA&t=3243s).

From 607ed64f966719ee4832177e8013e1bf42efff66 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 12:34:21 -0500
Subject: [PATCH 2807/3820] New translations assemblyscript-mappings.mdx
 (French)

---
 .../creating/assemblyscript-mappings.mdx         | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx
index 22d69907dbd2..fe393f319bf5 100644
--- a/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -39,28 +39,28 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void {
 
 The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
 
-The second handler tries to load the existing `Gravatar` from the Graph Node store. If it does not exist yet, it is created on-demand. The entity is then updated to match the new event parameters before it is saved back to the store using `gravatar.save()`.
+Le deuxième gestionnaire tente de charger le `Gravatar` existant à partir du store Graph Node. S'il n'existe pas encore, il est créé à la demande. L'entité est ensuite mise à jour pour correspondre aux nouveaux paramètres de l'événement avant d'être sauvegardée dans le store à l'aide de `gravatar.save()`.
 
 ### ID recommandés pour la création de nouvelles entités
 
-It is highly recommended to use `Bytes` as the type for `id` fields, and only use `String` for attributes that truly contain human-readable text, like the name of a token. Below are some recommended `id` values to consider when creating new entities.
+Il est fortement recommandé d'utiliser `Bytes` comme type pour les champs `id`, et de n'utiliser `String` que pour les attributs qui contiennent vraiment du texte lisible par l'homme, comme le nom d'un jeton. Voici quelques valeurs d'`id` recommandées à prendre en compte lors de la création de nouvelles entités.
 
 - `transfer.id = event.transaction.hash`
 
 - `let id = event.transaction.hash.concatI32(event.logIndex.toI32())`
 
-- For entities that store aggregated data, for e.g, daily trade volumes, the `id` usually contains the day number. Here, using a `Bytes` as the `id` is beneficial. Determining the `id` would look like
+- Pour les entités qui stockent des données agrégées, par exemple les volumes d'échanges quotidiens, l'`id` contient généralement le numéro du jour. Dans ce cas, l'utilisation d'un `Bytes` comme `id` est bénéfique. La détermination de l'`id` se fait de la manière suivante
 
 ```typescript
 let dayID = event.block.timestamp.toI32() / 86400
 let id = Bytes.fromI32(dayID)
 ```
 
-- Convert constant addresses to `Bytes`.
+- Convertir les adresses constantes en `Bytes`.
 
 `const id = Bytes.fromHexString('0xdead...beef')`
 
-There is a [Graph Typescript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) which contains utilities for interacting with the Graph Node store and conveniences for handling smart contract data and entities. It can be imported into `mapping.ts` from `@graphprotocol/graph-ts`.
+Il existe une [Library Graph Typescript ](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) qui contient des utilitaires pour interagir avec le store Graph Node et des commodités pour gérer les données et les entités des contrats intelligents. Elle peut être importée dans `mapping.ts` depuis `@graphprotocol/graph-ts`.
 
 ### Traitement des entités ayant des identifiants identiques
 
@@ -77,10 +77,10 @@ Afin de faciliter et de sécuriser le travail avec les contrats intelligents, le
 Cela se fait avec
 
 ```sh
-graph codegen [--output-dir <OUTPUT_DIR>] [<MANIFEST>]
+graph codegen [--output-dir <Repertoire_D_Sortie>] [<MANIFESTE>]
 ```
 
-but in most cases, subgraphs are already preconfigured via `package.json` to allow you to simply run one of the following to achieve the same:
+mais dans la plupart des cas, les subgraphs sont déjà préconfigurés via `package.json` pour vous permettre d'exécuter simplement l'un des éléments suivants pour obtenir le même résultat :
 
 ```sh
 # Yarn
@@ -90,7 +90,7 @@ yarn codegen
 npm run codegen
 ```
 
-This will generate an AssemblyScript class for every smart contract in the ABI files mentioned in `subgraph.yaml`, allowing you to bind these contracts to specific addresses in the mappings and call read-only contract methods against the block being processed. It will also generate a class for every contract event to provide easy access to event parameters, as well as the block and transaction the event originated from. All of these types are written to `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. In the example subgraph, this would be `generated/Gravity/Gravity.ts`, allowing mappings to import these types with.
+Cela va générer une classe AssemblyScript pour chaque contrat intelligent dans les fichiers ABI mentionnés dans `subgraph.yaml`, vous permettant de lier ces contrats à des adresses spécifiques dans les mappagess et d'appeler des méthodes de contrat en lecture seule sur le bloc en cours de traitement. Il génère également une classe pour chaque événement de contrat afin de fournir un accès facile aux paramètres de l'événement, ainsi qu'au bloc et à la transaction d'où provient l'événement. Tous ces types sont écrits dans `<OUTPUT_DIR>/<DATA_SOURCE_NAME>/<ABI_NAME>.ts`. Dans l'exemple du subgraph, ce serait `generated/Gravity/Gravity.ts`, permettant aux mappages d'importer ces types avec.
 
 ```javascript
 import {

From bbd3d150aedee4ea4054806f3399b6918b429549 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 12:34:22 -0500
Subject: [PATCH 2808/3820] New translations transferring-a-subgraph.mdx
 (French)

---
 .../subgraphs/developing/managing/transferring-a-subgraph.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/managing/transferring-a-subgraph.mdx b/website/pages/fr/subgraphs/developing/managing/transferring-a-subgraph.mdx
index 0dcb040eb00d..fe386614b198 100644
--- a/website/pages/fr/subgraphs/developing/managing/transferring-a-subgraph.mdx
+++ b/website/pages/fr/subgraphs/developing/managing/transferring-a-subgraph.mdx
@@ -1,5 +1,5 @@
 ---
-title: Transferring a Subgraph
+title: Transfer d'un Subgraph
 ---
 
 Les subgraphs publiés sur le réseau décentralisé possèdent un NFT minté à l'adresse qui a publié le subgraph. Le NFT est basé sur la norme ERC721, ce qui facilite les transferts entre comptes sur The Graph Network.
@@ -35,7 +35,7 @@ Pour transférer la propriété d'un subgraph, procédez comme suit :
 
 2. Choisissez l'adresse vers laquelle vous souhaitez transférer le subgraph :
 
-   ![Subgraph Ownership Transfer](/img/subgraph-ownership-transfer-2.png)
+   ![Transfert de propriété d'un subgraph](/img/subgraph-ownership-transfer-2.png)
 
 Optionnellement, vous pouvez également utiliser l'interface utilisateur intégrée dans les marketplaces NFT comme OpenSea :
 

From a876e958cb60d993464d061cc5e30d6842df3003 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:08 -0500
Subject: [PATCH 2809/3820] New translations unit-testing-framework.mdx
 (French)

---
 .../creating/unit-testing-framework.mdx       | 164 +++++++++---------
 1 file changed, 82 insertions(+), 82 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
index 85280f81b258..14af32b2a5c5 100644
--- a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -416,11 +416,11 @@ describe('handleUpdatedGravatars', () => {
 
 ### afterEach()
 
-Runs a code block after every test. If `afterEach` is declared inside of a `describe` block, it runs after each test in that `describe` block.
+Exécute un bloc de code après chaque test. Si `afterEach` est déclaré à l'intérieur d'un bloc `describe`, il s'exécute après chaque test dans ce bloc `describe`.
 
 Les Exemples:
 
-Code inside `afterEach` will execute after every test.
+Le code contenu dans `afterEach` sera exécuté après chaque test.
 
 ```typescript
 import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
@@ -441,25 +441,25 @@ describe("handleNewGravatar", () => {
 })
 
 describe("handleUpdatedGravatar", () => {
-  test("Updates the displayName", () => {
+  test("Met à jour le nom d'affichage (displayName)", () => {
      assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
 
-    // code that should update the displayName to 1st Gravatar
+    // code qui devrait mettre à jour le nom d'affichage (displayName) pour le 1er Gravatar
 
     assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
   })
 
-  test("Updates the imageUrl", () => {
+  test("Met à jour l'imageUrl", () => {
     assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
 
-    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+    // code qui devrait changer l'imageUrl en https://www.gravatar.com/avatar/0x0
 
     assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
   })
 })
 ```
 
-Code inside `afterEach` will execute after each test in that describe
+Le code contenu dans `afterEach` sera exécuté après chaque test de cette description
 
 ```typescript
 import { describe, test, beforeEach, afterEach } from "matchstick-as/assembly/index"
@@ -481,18 +481,18 @@ describe("handleUpdatedGravatar", () => {
     store.remove("Gravatar", "0x0")
   })
 
-  test("Updates the displayName", () => {
+  test("Met à jour le nom d'affichage (displayName)", () => {
      assert.fieldEquals("Gravatar", "0x0", "displayName", "First Gravatar")
 
-    // code that should update the displayName to 1st Gravatar
+    // code qui devrait mettre à jour le nom d'affichage (displayName) pour le 1er Gravatar
 
     assert.fieldEquals("Gravatar", "0x0", "displayName", "1st Gravatar")
   })
 
-  test("Updates the imageUrl", () => {
+  test("Met à jour l'imageUrl", () => {
     assert.fieldEquals("Gravatar", "0x0", "imageUrl", "")
 
-    // code that should changes the imageUrl to https://www.gravatar.com/avatar/0x0
+    // code qui devrait changer l'imageUrl en https://www.gravatar.com/avatar/0x0
 
     assert.fieldEquals("Gravatar", "0x0", "imageUrl", "https://www.gravatar.com/avatar/0x0")
   })
@@ -536,36 +536,36 @@ entityCount(entityType: string, expectedCount: i32)
 À partir de la version 0.6.0, les assertions supportent également les messages d'erreur personnalisés
 
 ```typescript
-assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id should be 0x123')
-assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'Value should equal 1')
-assert.notInStore('Gravatar', '0x124', 'Gravatar should not be in store')
-assert.addressEquals(Address.zero(), Address.zero(), 'Address should be zero')
-assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Bytes should be equal')
-assert.i32Equals(2, 2, 'I32 should equal 2')
-assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt should equal 1')
-assert.booleanEquals(true, true, 'Boolean should be true')
-assert.stringEquals('1', '1', 'String should equal 1')
-assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Arrays should be equal')
+assert.fieldEquals('Gravatar', '0x123', 'id', '0x123', 'Id doit être 0x123')
+assert.equals(ethereum.Value.fromI32(1), ethereum.Value.fromI32(1), 'La valeur doit être égale à 1')
+assert.notInStore('Gravatar', '0x124', 'Gravatar ne devrait pas être dans le store')
+assert.addressEquals(Address.zero(), Address.zero(), 'L'adresse doit être zéro')
+assert.bytesEquals(Bytes.fromUTF8('0x123'), Bytes.fromUTF8('0x123'), 'Les Bytes doivent être égaux')
+assert.i32Equals(2, 2, 'I32 doit être égal à 2')
+assert.bigIntEquals(BigInt.fromI32(1), BigInt.fromI32(1), 'BigInt doit être égal à 1')
+assert.booleanEquals(true, true, 'Le booléen doit être vrai')
+assert.stringEquals('1', '1', 'La Chaîne de caractère doit être égale à 1')
+assert.arrayEquals([ethereum.Value.fromI32(1)], [ethereum.Value.fromI32(1)], 'Les tableaux doivent être égaux')
 assert.tupleEquals(
   changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
   changetype<ethereum.Tuple>([ethereum.Value.fromI32(1)]),
-  'Tuples should be equal',
+  'Les tuples doivent être égaux',
 )
-assert.assertTrue(true, 'Should be true')
-assert.assertNull(null, 'Should be null')
-assert.assertNotNull('not null', 'Should be not null')
-assert.entityCount('Gravatar', 1, 'There should be 2 gravatars')
-assert.dataSourceCount('GraphTokenLockWallet', 1, 'GraphTokenLockWallet template should have one data source')
+assert.assertTrue(true, 'Devrait être vrai')
+assert.assertNull(null, 'Devrait être null')
+assert.assertNotNull('not null', 'Doit être non null')
+assert.entityCount('Gravatar', 1, 'Il devrait y avoir 2 gravatars')
+assert.dataSourceCount('GraphTokenLockWallet', 1, 'Le modèle GraphTokenLockWallet doit avoir une source de données')
 assert.dataSourceExists(
   'GraphTokenLockWallet',
-  Address.zero().toHexString(),
-  'GraphTokenLockWallet should have a data source for zero address',
+  Adresse.zero().toHexString(),
+  'GraphTokenLockWallet doit avoir une source de données pour zéro adresse',
 )
 ```
 
 ## Écrire un test unitaire
 
-Let's see how a simple unit test would look like using the Gravatar examples in the [Demo Subgraph](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
+Voyons à quoi ressemblerait un test unitaire simple en utilisant les exemples de Gravatar dans le [Subgraph de Démo](https://github.com/LimeChain/demo-subgraph/blob/main/src/gravity.ts).
 
 En supposant que nous disposions de la fonction de traitement suivante (ainsi que de deux fonctions d'aide pour nous faciliter la vie) :
 
@@ -626,24 +626,24 @@ import { Gravatar } from '../../generated/schema'
 import { NewGravatar } from '../../generated/Gravity/Gravity'
 import { createNewGravatarEvent, handleNewGravatars } from '../mappings/gravity'
 
-test('Can call mappings with custom events', () => {
-  // Create a test entity and save it in the store as initial state (optional)
+test('Possibilité d'appeler des mappages avec des événements personnalisés', () => {
+  // Créer une entité de test et la sauvegarder dans le store en tant qu'état initial (optionnel)
   let gravatar = new Gravatar('gravatarId0')
   gravatar.save()
 
-  // Create mock events
+  // Créer des événements fictifs
   let newGravatarEvent = createNewGravatarEvent(12345, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
   let anotherGravatarEvent = createNewGravatarEvent(3546, '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7', 'cap', 'pac')
 
-  // Call mapping functions passing the events we just created
+  // Appeler les fonctions de mappage en passant par les événements que nous venons de créer
   handleNewGravatars([newGravatarEvent, anotherGravatarEvent])
 
-  // Assert the state of the store
+  // Affirmer l'état du store
   assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
   assert.fieldEquals('Gravatar', '12345', 'owner', '0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7')
   assert.fieldEquals('Gravatar', '3546', 'displayName', 'cap')
 
-  // Clear the store in order to start the next test off on a clean slate
+  // Effacer le store afin de commencer le prochain test sur une ardoise propre
   clearStore()
 })
 
@@ -652,13 +652,13 @@ test('Next test', () => {
 })
 ```
 
-That's a lot to unpack! First off, an important thing to notice is that we're importing things from `matchstick-as`, our AssemblyScript helper library (distributed as an npm module). You can find the repository [here](https://github.com/LimeChain/matchstick-as). `matchstick-as` provides us with useful testing methods and also defines the `test()` function which we will use to build our test blocks. The rest of it is pretty straightforward - here's what happens:
+Cela fait beaucoup à décortiquer ! Tout d'abord, une chose importante à noter est que nous importons des choses à partir de `matchstick-as`, notre bibliothèque d'aide AssemblyScript (distribuée comme un module npm). Vous pouvez trouver le dépôt [ici](https://github.com/LimeChain/matchstick-as). `matchstick-as` nous fournit des méthodes de test utiles et définit également la fonction `test()` que nous utiliserons pour construire nos blocs de test. Le reste est assez simple - voici ce qui se passe :
 
 - Mettons en place notre état initial et ajoutons une entité Gravatar personnalisée ;
-- We define two `NewGravatar` event objects along with their data, using the `createNewGravatarEvent()` function;
-- We're calling out handler methods for those events - `handleNewGravatars()` and passing in the list of our custom events;
+- Nous définissons deux objets d'événement `NewGravatar` avec leurs données, en utilisant la fonction `createNewGravatarEvent()` ;
+- Nous appelons les méthodes de gestion de ces événements - `handleNewGravatars()` et nous passons la liste de nos événements personnalisés ;
 - Affirmons l'état du magasin. Comment cela fonctionne-t-il ? - Nous passons une combinaison unique de type d'entité et d'identifiant. Ensuite, nous vérifions un champ spécifique de cette entité et affirmons qu'il a la valeur que nous attendons. Nous faisons cela à la fois pour l'entité Gravatar initiale que nous avons ajoutée au magasin, ainsi que pour les deux entités Gravatar qui sont ajoutées lorsque la fonction de gestion est appelée ;
-- And lastly - we're cleaning the store using `clearStore()` so that our next test can start with a fresh and empty store object. We can define as many test blocks as we want.
+- Enfin, nous nettoyons le store en utilisant `clearStore()` afin que notre prochain test puisse commencer avec un objet de store frais et vide. Nous pouvons définir autant de blocs de test que nous le souhaitons.
 
 Et voilà, nous avons formulé notre premier test ! 👏
 
@@ -668,7 +668,7 @@ Maintenant, afin d'exécuter nos tests, il suffit d'exécuter ce qui suit dans l
 
 Et si tout se passe bien, vous devriez être accueilli par ce qui suit :
 
-![Matchstick saying “All tests passed!”](/img/matchstick-tests-passed.png)
+![Matchstick avec le message “Tous les tests sont réussis!”](/img/matchstick-tests-passed.png)
 
 ## Scénarios de tests actuels
 
@@ -754,18 +754,18 @@ createMockedFunction(contractAddress, 'getGravatar', 'getGravatar(address):(stri
 
 ### Se moquer des fichiers IPFS (à partir de Matchstick 0.4.1)
 
-Users can mock IPFS files by using `mockIpfsFile(hash, filePath)` function. The function accepts two arguments, the first one is the IPFS file hash/path and the second one is the path to a local file.
+Les utilisateurs peuvent simuler des fichiers IPFS en utilisant la fonction `mockIpfsFile(hash, filePath)`. La fonction accepte deux arguments, le premier étant le hash/chemin du fichier IPFS et le second le chemin d'un fichier local.
 
-NOTE: When testing `ipfs.map/ipfs.mapJSON`, the callback function must be exported from the test file in order for matchstck to detect it, like the `processGravatar()` function in the test example bellow:
+NOTE : Lorsque l'on teste `ipfs.map/ipfs.mapJSON`, la fonction callback doit être exportée depuis le fichier de test afin que matchstck la détecte, comme la fonction `processGravatar()` dans l'exemple de test ci-dessous :
 
-`.test.ts` file:
+Ficher `.test.ts` :
 
 ```typescript
 import { assert, test, mockIpfsFile } from 'matchstick-as/assembly/index'
 import { ipfs } from '@graphprotocol/graph-ts'
 import { gravatarFromIpfs } from './utils'
 
-// Export ipfs.map() callback in order for matchstck to detect it
+// Exporter le callback ipfs.map() pour que matchstck le détecte
 export { processGravatar } from './utils'
 
 test('ipfs.cat', () => {
@@ -795,7 +795,7 @@ test('ipfs.map', () => {
 })
 ```
 
-`utils.ts` file:
+Fichier `utils.ts` :
 
 ```typescript
 import { Address, ethereum, JSONValue, Value, ipfs, json, Bytes } from "@graphprotocol/graph-ts"
@@ -857,11 +857,11 @@ gravatar.save()
 assert.fieldEquals('Gravatar', 'gravatarId0', 'id', 'gravatarId0')
 ```
 
-Running the assert.fieldEquals() function will check for equality of the given field against the given expected value. The test will fail and an error message will be outputted if the values are **NOT** equal. Otherwise the test will pass successfully.
+L'exécution de la fonction assert.fieldEquals() permet de vérifier l'égalité du champ donné par rapport à la valeur attendue donnée. Le test échouera et un message d'erreur sera affiché si les valeurs **NE SONT PAS** égales. Dans le cas contraire, le test passera avec succès.
 
 ### Interagir avec les métadonnées d'événement
 
-Users can use default transaction metadata, which could be returned as an ethereum.Event by using the `newMockEvent()` function. The following example shows how you can read/write to those fields on the Event object:
+Les utilisateurs peuvent utiliser les métadonnées de transaction par défaut, qui peuvent être reenvoyées comme un ethereum.Event en utilisant la fonction `newMockEvent()`. L'exemple suivant montre comment vous pouvez lire/écrire dans ces champs de l'objet Event :
 
 ```typescript
 // Lisez
@@ -878,7 +878,7 @@ newGravatarEvent.address = Address.fromString(UPDATED_ADDRESS)
 assert.equals(ethereum.Value.fromString("bonjour"); ethereum.Value.fromString("bonjour"));
 ```
 
-### Asserting that an Entity is **not** in the store
+### Affirmer qu'une entité n'est **PAS** dans le store
 
 Les utilisateurs peuvent affirmer qu'une entité n'existe pas dans le magasin. La fonction prend un type d'entité et un identifiant. Si l'entité se trouve effectivement dans le magasin, le test échouera avec un message d'erreur pertinent. Voici un exemple rapide de la façon d'utiliser cette fonctionnalité :
 
@@ -896,7 +896,7 @@ import { logStore } from 'matchstick-as/assembly/store'
 logStore()
 ```
 
-As of version 0.6.0, `logStore` no longer prints derived fields, instead users can use the new `logEntity` function. Of course `logEntity` can be used to print any entity, not just ones that have derived fields. `logEntity` takes the entity type, entity id and a `showRelated` flag to indicate if users want to print the related derived entities.
+Depuis la version 0.6.0, `logStore` n'affiche plus les champs dérivés, au lieu de celà les utilisateurs peuvent utiliser la nouvelle fonction `logEntity`. Bien sûr, `logEntity` peut être utilisée pour afficher n'importe quelle entité, pas seulement celles qui ont des champs dérivés. `logEntity` prend le type d'entité, l'identifiant de l'entité et un flag `showRelated` pour indiquer si les utilisateurs veulent afficher les entités dérivées associées.
 
 ```
 import { logEntity } from 'matchstick-as/assembly/store'
@@ -911,7 +911,7 @@ Les utilisateurs peuvent s'attendre à des échecs de test, en utilisant l'indic
 
 ```typescript
 test(
-  'Should throw an error',
+  'Devrait générer une erreur',
   () => {
     throw new Error()
   },
@@ -930,26 +930,26 @@ import { test } from "matchstick-as/assembly/index";
 import { log } from "matchstick-as/assembly/log";
 
 test("Success", () => {
-    log.success("Success!". []);
+    log.success("Succès!". []);
 });
 test("Error", () => {
-    log.error("Error :( ", []);
+    log.error("Erreur :( ", []);
 });
 test("Debug", () => {
-    log.debug("Debugging...", []);
+    log.debug("Deboggage...", []);
 });
 test("Info", () => {
     log.info("Info!", []);
 });
 test("Warning", () => {
-    log.warning("Warning!", []);
+    log.warning("Avertissement!", []);
 });
 ```
 
 Les utilisateurs peuvent également simuler une panne critique, comme ceci :
 
 ```typescript
-test('Blow everything up', () => {
+test('Tout faire exploser', () => {
   log.critical('Boom!')
 })
 ```
@@ -960,14 +960,14 @@ La journalisation des erreurs critiques arrêtera l’exécution des tests et fe
 
 Tester les champs dérivés est une fonctionnalité qui permet aux utilisateurs de définir un champ sur une certaine entité et de faire en sorte qu'une autre entité soit automatiquement mise à jour si elle dérive l'un de ses champs de la première entité.
 
-Before version `0.6.0` it was possible to get the derived entities by accessing them as entity fields/properties, like so:
+Avant la version `0.6.0`, il était possible d'obtenir les entités dérivées en y accédant en tant que champs/propriétés d'entité, comme suit :
 
 ```typescript
 let entity = ExampleEntity.load('id')
 let derivedEntity = entity.derived_entity
 ```
 
-As of version `0.6.0`, this is done by using the `loadRelated` function of graph-node, the derived entities can be accessed the same way as in the handlers.
+A partir de la version `0.6.0`, ceci est fait en utilisant la fonction `loadRelated` de graph-node, les entités dérivées peuvent être accédées de la même manière que dans les gestionnaires.
 
 ```typescript
 test('Derived fields example test', () => {
@@ -1009,9 +1009,9 @@ test('Derived fields example test', () => {
 })
 ```
 
-### Testing `loadInBlock`
+### Test de `loadInBlock`
 
-As of version `0.6.0`, users can test `loadInBlock` by using the `mockInBlockStore`, it allows mocking entities in the block cache.
+Depuis la version `0.6.0`, les utilisateurs peuvent tester `loadInBlock` en utilisant le `mockInBlockStore`, qui permet de simuler des entités dans le cache du bloc.
 
 ```typescript
 import { afterAll, beforeAll, describe, mockInBlockStore, test } from 'matchstick-as'
@@ -1026,12 +1026,12 @@ describe('loadInBlock', () => {
     clearInBlockStore()
   })
 
-  test('Can use entity.loadInBlock() to retrieve entity from cache store in the current block', () => {
+  test('Peut utiliser entity.loadInBlock() pour récupérer l'entité dans le sore du cache du bloc actuel', () => {
     let retrievedGravatar = Gravatar.loadInBlock('gravatarId0')
     assert.stringEquals('gravatarId0', retrievedGravatar!.get('id')!.toString())
   })
 
-  test("Returns null when calling entity.loadInBlock() if an entity doesn't exist in the current block", () => {
+  test("Renvoit null lors de l'appel à entity.loadInBlock() si une entité n'existe pas dans le bloc actuel", () => {
     let retrievedGravatar = Gravatar.loadInBlock('IDoNotExist')
     assert.assertNull(retrievedGravatar)
   })
@@ -1040,7 +1040,7 @@ describe('loadInBlock', () => {
 
 ### Tester les sources de données dynamiques
 
-Testing dynamic data sources can be be done by mocking the return value of the `context()`, `address()` and `network()` functions of the dataSource namespace. These functions currently return the following: `context()` - returns an empty entity (DataSourceContext), `address()` - returns `0x0000000000000000000000000000000000000000`, `network()` - returns `mainnet`. The `create(...)` and `createWithContext(...)` functions are mocked to do nothing so they don't need to be called in the tests at all. Changes to the return values can be done through the functions of the `dataSourceMock` namespace in `matchstick-as` (version 0.3.0+).
+Le test des sources de données dynamiques peut être effectué en simulant la valeur de retour des fonctions `context()`, `address()` et `network()` du namespace dataSource. Ces fonctions renvoient actuellement les valeurs suivantes `context()` - renvoit une entité vide (DataSourceContext), `address()` - renvoit `0x00000000000000000000000000000000`, `network()` - renvoit `mainnet`. Les fonctions `create(...)` et `createWithContext(...)` sont simulées pour ne rien faire, donc elles n'ont pas besoin d'être appelées dans les tests. Les modifications des valeurs de retour peuvent être faites à travers les fonctions du namespace`dataSourceMock` dans `matchstick-as` (version 0.3.0+).
 
 L'exemple ci-dessous :
 
@@ -1070,7 +1070,7 @@ import { handleApproveTokenDestinations } from '../../src/token-lock-wallet'
 import { ApproveTokenDestinations } from '../../generated/templates/GraphTokenLockWallet/GraphTokenLockWallet'
 import { TokenLockWallet } from '../../generated/schema'
 
-test('Data source simple mocking example', () => {
+test('Source de données : simple exemple de simulation ', () => {
   let addressString = '0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'
   let address = Address.fromString(addressString)
 
@@ -1097,44 +1097,44 @@ Notez que dataSourceMock.resetValues() est appelé à la fin. C'est parce que le
 
 ### Test de la création dynamique de sources de données
 
-As of version `0.6.0`, it is possible to test if a new data source has been created from a template. This feature supports both ethereum/contract and file/ipfs templates. There are four functions for this:
+Depuis la version `0.6.0`, il est possible de tester si une nouvelle source de données a été créée à partir d'un modèle. Cette fonctionnalité prend en charge à la fois les modèles ethereum/contract et file/ipfs. Il y a quatre fonctions pour cela :
 
-- `assert.dataSourceCount(templateName, expectedCount)` can be used to assert the expected count of data sources from the specified template
-- `assert.dataSourceExists(templateName, address/ipfsHash)` asserts that a data source with the specified identifier (could be a contract address or IPFS file hash) from a specified template was created
-- `logDataSources(templateName)` prints all data sources from the specified template to the console for debugging purposes
-- `readFile(path)` reads a JSON file that represents an IPFS file and returns the content as Bytes
+- `assert.dataSourceCount(templateName, expectedCount)` peut être utilisé pour affirmer le nombre attendu de sources de données à partir du modèle spécifié
+- `assert.dataSourceExists(templateName, address/ipfsHash)` affirme qu'une source de données avec l'identifiant spécifié (qui peut être une adresse de contrat ou un hash de fichier IPFS) a été créée à partir d'un modèle spécifié
+- `logDataSources(templateName)` affiche toutes les sources de données du modèle spécifié sur la console à des fins de débogage
+- `readFile(path)` lit un fichier JSON qui représente un fichier IPFS et renvoie le contenu sous forme d'octets
 
-#### Testing `ethereum/contract` templates
+#### Test des modèles `ethereum/contrat`
 
 ```typescript
 test('ethereum/contract dataSource creation example', () => {
-  // Assert there are no dataSources created from GraphTokenLockWallet template
+  // Affirmer qu'il n'y a pas de dataSources créées à partir du modèle GraphTokenLockWallet
   assert.dataSourceCount('GraphTokenLockWallet', 0)
 
-  // Create a new GraphTokenLockWallet datasource with address 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
+  // Créer une nouvelle source de données GraphTokenLockWallet avec l'adresse 0xA16081F360e3847006dB660bae1c6d1b2e17eC2A
   GraphTokenLockWallet.create(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2A'))
 
-  // Assert the dataSource has been created
+  // Affirmer que la source de données a été créée
   assert.dataSourceCount('GraphTokenLockWallet', 1)
 
-  // Add a second dataSource with context
+  // Ajouter une deuxième source de données avec le contexte
   let context = new DataSourceContext()
   context.set('contextVal', Value.fromI32(325))
 
   GraphTokenLockWallet.createWithContext(Address.fromString('0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'), context)
 
-  // Assert there are now 2 dataSources
+  // Affirmer qu'il y a maintenant 2 sources de données
   assert.dataSourceCount('GraphTokenLockWallet', 2)
 
-  // Assert that a dataSource with address "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" was created
-  // Keep in mind that `Address` type is transformed to lower case when decoded, so you have to pass the address as all lower case when asserting if it exists
+  // Affirme qu'une source de données avec l'adresse "0xA16081F360e3847006dB660bae1c6d1b2e17eC2B" a été créée.
+  // Gardez à l'esprit que le type `Address` est transformé en minuscules lorsqu'il est décodé, vous devez donc passer l'adresse en minuscules lorsque vous affirmez qu'elle existe.
   assert.dataSourceExists('GraphTokenLockWallet', '0xA16081F360e3847006dB660bae1c6d1b2e17eC2B'.toLowerCase())
 
   logDataSources('GraphTokenLockWallet')
 })
 ```
 
-##### Example `logDataSource` output
+##### Exemple de sortie `logDataSource`
 
 ```bash
 🛠  {
@@ -1157,11 +1157,11 @@ test('ethereum/contract dataSource creation example', () => {
   }
 ```
 
-#### Testing `file/ipfs` templates
+#### Test des modèles `file/ipfs`
 
-Similarly to contract dynamic data sources, users can test test file data sources and their handlers
+De même que pour les sources de données dynamiques de contrat, les utilisateurs peuvent tester les fichiers sources de données et leurs gestionnaires
 
-##### Example `subgraph.yaml`
+##### Exemple `subgraph.yaml`
 
 ```yaml
 ...
@@ -1182,7 +1182,7 @@ templates:
           file: ./abis/GraphTokenLockWallet.json
 ```
 
-##### Example `schema.graphql`
+##### Exemple `schema.graphql`
 
 ```graphql
 """

From 4f18ec73b527c34351e0f449c62ea6203d88b158 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:09 -0500
Subject: [PATCH 2810/3820] New translations install-the-cli.mdx (French)

---
 .../developing/creating/install-the-cli.mdx   | 78 +++++++++----------
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx
index 7f8b17eaceb3..108969ebd67d 100644
--- a/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx
@@ -2,33 +2,33 @@
 title: Installation du Graph CLI
 ---
 
-> In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
+> Pour utiliser votre subgraph sur le réseau décentralisé de The Graph, vous devrez [créer une clé API](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) dans [Subgraph Studio](https://thegraph.com/studio/apikeys/). Il est recommandé d'ajouter un signal à votre subgraph avec au moins 3 000 GRT pour attirer 2 à 3 Indexeurs. Pour en savoir plus sur la signalisation, consultez [curation](/resources/roles/curating/).
 
 ## Aperçu
 
-The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
+[Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) est une interface de ligne de commande qui facilite les commandes des développeurs pour The Graph. Il traite un [manifeste de subgraph](/subgraphs/developing/creating/subgraph-manifest/) et compile les [mappages](/subgraphs/developing/creating/assemblyscript-mappings/) pour créer les fichiers dont vous aurez besoin pour déployer le subgraph sur [Subgraph Studio](https://thegraph.com/studio/) et le réseau.
 
 ## Introduction
 
 ### Installation du Graph CLI
 
-The Graph CLI is written in TypeScript, and you must have `node` and either `npm` or `yarn` installed to use it. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+L'interface de ligne de commande Graph est écrite en TypeScript et vous devez avoir installé `node` et soit `npm` soit `yarn` pour l'utiliser. Recherchez la version [la plus récente](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) de l'interface de ligne de commande.
 
 Sur votre machine locale, exécutez l'une des commandes suivantes :
 
-#### Using [npm](https://www.npmjs.com/)
+#### En utilisant [npm](https://www.npmjs.com/)
 
 ```bash
 npm install -g @graphprotocol/graph-cli@latest
 ```
 
-#### Using [yarn](https://yarnpkg.com/)
+#### En utilisant [yarn](https://yarnpkg.com/)
 
 ```bash
 yarn global add @graphprotocol/graph-cli
 ```
 
-The `graph init` command can be used to set up a new subgraph project, either from an existing contract or from an example subgraph. If you already have a smart contract deployed to your preferred network, you can bootstrap a new subgraph from that contract to get started.
+La commande `graph init` peut être utilisée pour configurer un nouveau projet de subgraph, soit à partir d'un contrat existant, soit à partir d'un exemple de subgraph. Si vous avez déjà déployé un contrat intelligent sur votre réseau préféré, vous pouvez démarrer un nouveau subgraph à partir de ce contrat pour commencer.
 
 ## Créer un subgraph
 
@@ -39,10 +39,10 @@ La commande suivante crée un subgraph qui indexe tous les événements d'un con
 ```sh
 graph init \
   --product subgraph-studio
-  --from-contract <CONTRACT_ADDRESS> \
-  [--network <ETHEREUM_NETWORK>] \
-  [--abi <FILE>] \
-  <SUBGRAPH_SLUG> [<DIRECTORY>]
+  --from-contract <ADRESSE_DU_CONTRAT> \
+  [--network <RESEAU_ETHEREUM>] \
+  [--abi <FICHIER>] \
+  <SUBGRAPH_SLUG> [<REPERTOIRE>]
 ```
 
 - La commande tente de récupérer l'ABI du contrat depuis Etherscan.
@@ -51,7 +51,7 @@ graph init \
 
 - Si certains arguments optionnels manquent, il vous guide à travers un formulaire interactif.
 
-- The `<SUBGRAPH_SLUG>` is the ID of your subgraph in [Subgraph Studio](https://thegraph.com/studio/). It can be found on your subgraph details page.
+- Le `<SUBGRAPH_SLUG>` est l'ID de votre subgraph dans [Subgraph Studio](https://thegraph.com/studio/). Il se trouve sur la page de détails de votre subgraph.
 
 ### À partir d'un exemple de subgraph
 
@@ -61,59 +61,59 @@ La commande suivante initialise un nouveau projet à partir d'un exemple de subg
 graph init <SUBGRAPH_SLUG> --from-example=example-subgraph
 ```
 
-- The [example subgraph](https://github.com/graphprotocol/example-subgraph) is based on the Gravity contract by Dani Grant, which manages user avatars and emits `NewGravatar` or `UpdateGravatar` events whenever avatars are created or updated.
+- Le [subgraph d'exemple](https://github.com/graphprotocol/example-subgraph) est basé sur le contrat Gravity de Dani Grant, qui gère les avatars des utilisateurs et émet des événements `NewGravatar` ou `UpdateGravatar` chaque fois que des avatars sont créés ou mis à jour.
 
-- The subgraph handles these events by writing `Gravatar` entities to the Graph Node store and ensuring these are updated according to the events.
+- Le subgraph gère ces événements en écrivant des entités `Gravatar` dans le store de Graph Node et en veillant à ce qu'elles soient mises à jour en fonction des événements.
 
-### Add New `dataSources` to an Existing Subgraph
+### Ajouter de nouvelles `sources de données` à un subgraph existant
 
-`dataSources` are key components of subgraphs. They define the sources of data that the subgraph indexes and processes. A `dataSource` specifies which smart contract to listen to, which events to process, and how to handle them.
+Les `dataSources` sont des composants clés des subgraphs. Ils définissent les sources de données que le subgraphs indexe et traite. Une `dataSource` spécifie quel smart contract doit être écouté, quels événements doivent être traités et comment les traiter.
 
-Recent versions of the Graph CLI supports adding new `dataSources` to an existing subgraph through the `graph add` command:
+Les versions récentes de Graph CLI permettent d'ajouter de nouvelles `dataSources` à un subgraph existant grâce à la commande `graph add` :
 
 ```sh
 graph add <address> [<subgraph-manifest default: "./subgraph.yaml">]
 
 Options:
 
-      --abi <path>              Path to the contract ABI (default: download from Etherscan)
-      --contract-name           Name of the contract (default: Contract)
-      --merge-entities          Whether to merge entities with the same name (default: false)
-      --network-file <path>     Networks config file path (default: "./networks.json")
+      --abi <path>              Chemin d'accès à l'ABI du contrat (par défaut : téléchargement à partir d'Etherscan)
+      --contract-name           Nom du contrat (par défaut : Contrat)
+      --merge-entities          Fusionner ou non les entités portant le même nom (par défaut : false)
+      --network-file <path>     Chemin du fichier de configuration du réseau (par défaut: "./networks.json")
 ```
 
 #### Spécificités⁠
 
-The `graph add` command will fetch the ABI from Etherscan (unless an ABI path is specified with the `--abi` option) and creates a new `dataSource`, similar to how the `graph init` command creates a `dataSource` `--from-contract`, updating the schema and mappings accordingly. This allows you to index implementation contracts from their proxy contracts.
+La commande `graph add` récupère l'ABI depuis Etherscan (à moins qu'un chemin ABI ne soit spécifié avec l'option `--abi`) et crée une nouvelle `dataSource`, de la même manière que la commande `graph init` crée une `dataSource` `--from-contract`, en mettant à jour le schéma et les mappages en conséquence. Cela vous permet d'indexer les contrats d'implémentation à partir de leurs contrats proxy.
 
-- The `--merge-entities` option identifies how the developer would like to handle `entity` and `event` name conflicts:
+- L'option `--merge-entities` identifie comment le développeur souhaite gérer les conflits de noms entre `entity` et `event` :
 
-  - If `true`: the new `dataSource` should use existing `eventHandlers` & `entities`.
+  - Si `true` : la nouvelle `dataSource` doit utiliser les `eventHandlers` et `entities` existants.
 
-  - If `false`: a new `entity` & `event` handler should be created with `${dataSourceName}{EventName}`.
+  - Si `false` : un nouveau gestionnaire `entity` & `event` doit être créé avec `${dataSourceName}{EventName}`.
 
-- The contract `address` will be written to the `networks.json` for the relevant network.
+- L'adresse du contrat sera écrite dans le fichier `networks.json` pour le réseau concerné.
 
-> Note: When using the interactive CLI, after successfully running `graph init`, you'll be prompted to add a new `dataSource`.
+> Note : Lorsque vous utilisez la CLI interactive, après avoir exécuté `graph init` avec succès, vous serez invité à ajouter une nouvelle `dataSource`.
 
 ### Récupération des ABIs
 
 Le(s) fichier(s) ABI doivent correspondre à votre(vos) contrat(s). Il existe plusieurs façons d'obtenir des fichiers ABI :
 
 - Si vous construisez votre propre projet, vous aurez probablement accès à vos ABI les plus récents.
-- If you are building a subgraph for a public project, you can download that project to your computer and get the ABI by using [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) or using `solc` to compile.
-- You can also find the ABI on [Etherscan](https://etherscan.io/), but this isn't always reliable, as the ABI that is uploaded there may be out of date. Make sure you have the right ABI, otherwise running your subgraph will fail.
+- Si vous construisez un subgraph pour un projet public, vous pouvez télécharger ce projet sur votre ordinateur et obtenir l'ABI en utilisant [`npx hardhat compile`](https://hardhat.org/hardhat-runner/docs/guides/compile-contracts#compiling-your-contracts) ou en utilisant `solc` pour compiler.
+- Vous pouvez également trouver l'ABI sur [Etherscan](https://etherscan.io/), mais ce n'est pas toujours fiable, car l'ABI qui y est téléchargé peut être obsolète. Assurez-vous d'avoir le bon ABI, sinon l'exécution de votre subgraph échouera.
 
 ## Versions disponibles de SpecVersion
 
-| Version | Notes de version                                                                                                                                                         |
-| :-----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-|  1.2.0  | Added support for [Indexed Argument Filtering](/#indexed-argument-filters--topic-filters) & declared `eth_call`                                                          |
-|  1.1.0  | Supports [Timeseries & Aggregations](#timeseries-and-aggregations). Added support for type `Int8` for `id`.                                                              |
-|  1.0.0  | Supports [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) feature to prune subgraphs                                                                     |
-|  0.0.9  | Supports `endBlock` feature                                                                                                                                              |
-|  0.0.8  | Added support for polling [Block Handlers](/developing/creating-a-subgraph/#polling-filter) and [Initialisation Handlers](/developing/creating-a-subgraph/#once-filter). |
-|  0.0.7  | Added support for [File Data Sources](/developing/creating-a-subgraph/#file-data-sources).                                                                               |
-|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                              |
-|  0.0.5  | Ajout de la prise en charge des gestionnaires d'événement ayant accès aux reçus de transactions.                                                                         |
-|  0.0.4  | Ajout de la prise en charge du management des fonctionnalités de subgraph.                                                                                               |
+| Version | Notes de version                                                                                                                                                                                                 |
+| :-----: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+|  1.2.0  | Ajout de la prise en charge du [filtrage des arguments indexés](/#indexed-argument-filters--topic-filters) et de la déclaration `eth_call`                                                                       |
+|  1.1.0  | Prend en charge [Timeseries & Aggregations](#timeseries-and-aggregations). Ajout de la prise en charge du type `Int8` pour `id`.                                                                                 |
+|  1.0.0  | Prend en charge la fonctionnalité [`indexerHints`](/developing/creating-a-subgraph/#indexer-hints) pour élaguer les subgraphs                                                                                    |
+|  0.0.9  | Prend en charge la fonctionnalité `endBlock`                                                                                                                                                                     |
+|  0.0.8  | Ajout de la prise en charge des [gestionnaires de blocs](/developing/creating-a-subgraph/#polling-filter) et des [gestionnaires d'initialisation](/developing/creating-a-subgraph/#once-filter) d'interrogation. |
+|  0.0.7  | Ajout de la prise en charge des [fichiers sources de données](/developing/creating-a-subgraph/#file-data-sources).                                                                                               |
+|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                                                                      |
+|  0.0.5  | Ajout de la prise en charge des gestionnaires d'événement ayant accès aux reçus de transactions.                                                                                                                 |
+|  0.0.4  | Ajout de la prise en charge du management des fonctionnalités de subgraph.                                                                                                                                       |

From 530ae98affa2ade665b32d69e30f66a4efd293ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:10 -0500
Subject: [PATCH 2811/3820] New translations assemblyscript-mappings.mdx
 (French)

---
 .../developing/creating/assemblyscript-mappings.mdx         | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx
index fe393f319bf5..8d8b02c138e4 100644
--- a/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -102,12 +102,12 @@ import {
 } from '../generated/Gravity/Gravity'
 ```
 
-In addition to this, one class is generated for each entity type in the subgraph's GraphQL schema. These classes provide type-safe entity loading, read and write access to entity fields as well as a `save()` method to write entities to store. All entity classes are written to `<OUTPUT_DIR>/schema.ts`, allowing mappings to import them with
+En outre, une classe est générée pour chaque type d'entité dans le schéma GraphQL du subgraph. Ces classes fournissent un chargement sécurisé des entités, un accès en lecture et en écriture aux champs des entités ainsi qu'une méthode `save()` pour écrire les entités dans le store. Toutes les classes d'entités sont écrites dans le fichier `<OUTPUT_DIR>/schema.ts`, ce qui permet aux mappages de les importer avec la commande
 
 ```javascript
 import { Gravatar } from '../generated/schema'
 ```
 
-> **Note:** The code generation must be performed again after every change to the GraphQL schema or the ABIs included in the manifest. It must also be performed at least once before building or deploying the subgraph.
+> **Note:** La génération de code doit être exécutée à nouveau après chaque modification du schéma GraphQL ou des ABIs incluses dans le manifeste. Elle doit également être effectuée au moins une fois avant de construire ou de déployer le subgraphs.
 
-Code generation does not check your mapping code in `src/mapping.ts`. If you want to check that before trying to deploy your subgraph to Graph Explorer, you can run `yarn build` and fix any syntax errors that the TypeScript compiler might find.
+La génération de code ne vérifie pas votre code de mappage dans `src/mapping.ts`. Si vous souhaitez vérifier cela avant d'essayer de déployer votre subgraph sur Graph Explorer, vous pouvez exécuter `yarn build` et corriger les erreurs de syntaxe que le compilateur TypeScript pourrait trouver.

From 697af12155c1de5b1b71ff810e6328fc63c2ed5e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:12 -0500
Subject: [PATCH 2812/3820] New translations ql-schema.mdx (French)

---
 .../developing/creating/ql-schema.mdx         | 46 +++++++++----------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx b/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx
index 4f107ff5f682..f18ed6f7c382 100644
--- a/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx
@@ -275,7 +275,7 @@ query {
 }
 ```
 
-> **[Feature Management](#experimental-features):** From `specVersion` `0.0.4` and onwards, `fullTextSearch` must be declared under the `features` section in the subgraph manifest.
+> **[Gestion des fonctionnalités](#experimental-features):** A partir de `specVersion` `0.0.4`, `fullTextSearch` doit être déclaré dans la section `features` du manifeste du subgraph.
 
 ## Langues prises en charge
 
@@ -283,30 +283,30 @@ Le choix d'une langue différente aura un effet définitif, bien que parfois sub
 
 Dictionnaires de langues pris en charge :
 
-| Code   | Dictionnaire |
-| ------ | ------------ |
-| simple | General      |
-| da     | Danish       |
-| nl     | Dutch        |
-| en     | English      |
-| fi     | Finnish      |
-| fr     | French       |
-| de     | German       |
-| hu     | Hungarian    |
-| it     | Italian      |
-| no     | Norwegian    |
-| pt     | Portugais    |
-| ro     | Romanian     |
-| ru     | Russian      |
-| es     | Spanish      |
-| sv     | Swedish      |
-| tr     | Turkish      |
+| Code   | Dictionnaire     |
+| ------ | ---------------- |
+| simple | Général          |
+| da     | Danois           |
+| nl     | Néerlandais      |
+| en     | Anglais          |
+| fi     | Finlandais       |
+| fr     | Français         |
+| de     | Allemand         |
+| hu     | Hongrois         |
+| it     | Italien          |
+| no     | Norvégien        |
+| pt     | Portugais        |
+| ro     | Roumain          |
+| ru     | Russe            |
+| es     | Espagnol         |
+| sv     | Suédois          |
+| tr     | Turc             |
 
 ### Algorithmes de classement
 
 Algorithmes de classement:
 
-| Algorithm     | Description                                                                                           |
-| ------------- | ----------------------------------------------------------------------------------------------------- |
-| rank          | Utilisez la qualité de correspondance (0-1) de la requête en texte intégral pour trier les résultats. |
-| proximitéRang | Similar to rank but also includes the proximity of the matches.                                       |
+| Algorithme     | Description                                                                                           |
+| -------------- | ----------------------------------------------------------------------------------------------------- |
+| rank           | Utilisez la qualité de correspondance (0-1) de la requête en texte intégral pour trier les résultats. |
+| proximitéRang  | Similaire au classement, mais inclut également la proximité des correspondances.                      |

From 719ef295ac846618d284fb402e88960cd34a8573 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:13 -0500
Subject: [PATCH 2813/3820] New translations subgraph-manifest.mdx (French)

---
 .../developing/creating/subgraph-manifest.mdx | 134 +++++++++---------
 1 file changed, 67 insertions(+), 67 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/fr/subgraphs/developing/creating/subgraph-manifest.mdx
index 3edebaf3385e..f3b29bd0de75 100644
--- a/website/pages/fr/subgraphs/developing/creating/subgraph-manifest.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -1,20 +1,20 @@
 ---
-title: Subgraph Manifest
+title: Manifeste de Subgraph
 ---
 
 ## Aperçu
 
-The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+Le manifeste du subgraph, `subgraph.yaml`, définit les contrats intelligents et le réseau que votre subgraph va indexer, les événements de ces contrats auxquels il faut prêter attention, et comment faire correspondre les données d'événements aux entités que Graph Node stocke et permet d'interroger.
 
-The **subgraph definition** consists of the following files:
+La **définition du subgraph** se compose des fichiers suivants :
 
-- `subgraph.yaml`: Contains the subgraph manifest
+- `subgraph.yaml` : Contient le manifeste du subgraph
 
-- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+- `schema.graphql` : Un schéma GraphQL définissant les données stockées pour votre subgraph et comment les interroger via GraphQL
 
-- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema (e.g. `mapping.ts` in this guide)
+- `mapping.ts` : [Mappage AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code qui traduit les données d'événements en entités définies dans votre schéma (par exemple `mapping.ts` dans ce guide)
 
-### Subgraph Capabilities
+### Capacités des subgraphs
 
 Un seul subgraph peut :
 
@@ -22,11 +22,11 @@ Un seul subgraph peut :
 
 - Indexer des données de fichiers IPFS en utilisant des File Data Sources.
 
-- Add an entry for each contract that requires indexing to the `dataSources` array.
+- Ajouter une entrée pour chaque contrat nécessitant une indexation dans le tableau `dataSources`.
 
-The full specification for subgraph manifests can be found [here](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
+La spécification complète des manifestes de subgraphs est disponible [ici](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md).
 
-For the example subgraph listed above, `subgraph.yaml` is:
+Pour l'exemple de subgraph cité ci-dessus, `subgraph.yaml` est :
 
 ```yaml
 version spec : 0.0.4
@@ -77,41 +77,41 @@ les sources de données:
        fichier : ./src/mapping.ts
 ```
 
-## Subgraph Entries
+## Entrées de subgraphs
 
-> Important Note: Be sure you populate your subgraph manifest with all handlers and [entities](/subgraphs/developing/creating/ql-schema/).
+> Remarque importante : veillez à remplir le manifeste de votre subgraph avec tous les gestionnaires et [entités](/subgraphs/developing/creating/ql-schema/).
 
 Les entrées importantes à mettre à jour pour le manifeste sont :
 
-- `specVersion`: a semver version that identifies the supported manifest structure and functionality for the subgraph. The latest version is `1.2.0`. See [specVersion releases](#specversion-releases) section to see more details on features & releases.
+- `specVersion` : une version de semver qui identifie la structure du manifeste et les fonctionnalités supportées pour le subgraph. La dernière version est `1.2.0`. Voir la section [versions de specVersion](#specversion-releases) pour plus de détails sur les fonctionnalités et les versions.
 
-- `description`: a human-readable description of what the subgraph is. This description is displayed in Graph Explorer when the subgraph is deployed to Subgraph Studio.
+- `description` : une description lisible par l'homme de ce qu'est le subgraph. Cette description est affichée dans Graph Explorer lorsque le subgraph est déployé dans Subgraph Studio.
 
-- `repository`: the URL of the repository where the subgraph manifest can be found. This is also displayed in Graph Explorer.
+- `repository` : l'URL du dépôt où le manifeste du subgraph peut être trouvé. Cette URL est également affichée dans Graph Explorer.
 
-- `features`: a list of all used [feature](#experimental-features) names.
+- `features` : une liste de tous les noms de [fonctionnalités](#experimental-features) utilisés.
 
-- `indexerHints.prune`: Defines the retention of historical block data for a subgraph. See [prune](#prune) in [indexerHints](#indexer-hints) section.
+- `indexerHints.prune` : Définit la conservation des données de blocs historiques pour un subgraph. Voir [prune](#prune) dans la section [indexerHints](#indexer-hints).
 
-- `dataSources.source`: the address of the smart contract the subgraph sources, and the ABI of the smart contract to use. The address is optional; omitting it allows to index matching events from all contracts.
+- `dataSources.source` : l'adresse du contrat intelligent dont le subgraph est issu, et l'ABI du contrat intelligent à utiliser. L'adresse est optionnelle ; l'omettre permet d'indexer les événements correspondants de tous les contrats.
 
-- `dataSources.source.startBlock`: the optional number of the block that the data source starts indexing from. In most cases, we suggest using the block in which the contract was created.
+- `dataSources.source.startBlock` : le numéro optionnel du bloc à partir duquel la source de données commence l'indexation. Dans la plupart des cas, nous suggérons d'utiliser le bloc dans lequel le contrat a été créé.
 
-- `dataSources.source.endBlock`: The optional number of the block that the data source stops indexing at, including that block. Minimum spec version required: `0.0.9`.
+- `dataSources.source.endBlock` : Le numéro optionnel du bloc sur lequel la source de données arrête l'indexation, y compris ce bloc. Version minimale de la spécification requise : `0.0.9`.
 
-- `dataSources.context`: key-value pairs that can be used within subgraph mappings. Supports various data types like `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, and `BigInt`. Each variable needs to specify its `type` and `data`. These context variables are then accessible in the mapping files, offering more configurable options for subgraph development.
+- `dataSources.context` : paires clé-valeur qui peuvent être utilisées dans les mappages de subgraphs. Supporte différents types de données comme `Bool`, `String`, `Int`, `Int8`, `BigDecimal`, `Bytes`, `List`, et `BigInt`. Chaque variable doit spécifier son `type` et ses `données`. Ces variables de contexte sont ensuite accessibles dans les fichiers de mappage, offrant plus d'options configurables pour le développement de subgraphs.
 
-- `dataSources.mapping.entities`: the entities that the data source writes to the store. The schema for each entity is defined in the schema.graphql file.
+- `dataSources.mapping.entities` : les entités que la source de données écrit dans le store. Le schéma de chaque entité est défini dans le fichier schema.graphql.
 
-- `dataSources.mapping.abis`: one or more named ABI files for the source contract as well as any other smart contracts that you interact with from within the mappings.
+- `dataSources.mapping.abis` : un ou plusieurs fichiers ABI nommés pour le contrat source ainsi que pour tous les autres contrats intelligents avec lesquels vous interagissez à partir des mappages.
 
-- `dataSources.mapping.eventHandlers`: lists the smart contract events this subgraph reacts to and the handlers in the mapping—./src/mapping.ts in the example—that transform these events into entities in the store.
+- `dataSources.mapping.eventHandlers` : liste les événements du contrat intelligent auxquels ce subgraph réagit et les gestionnaires dans le mappage - ./src/mapping.ts dans l'exemple - qui transforment ces événements en entités dans le store.
 
-- `dataSources.mapping.callHandlers`: lists the smart contract functions this subgraph reacts to and handlers in the mapping that transform the inputs and outputs to function calls into entities in the store.
+- `dataSources.mapping.callHandlers` : liste les fonctions de contrat intelligent auxquelles ce subgraph réagit et les handlers dans le mappage qui transforment les entrées et sorties des appels de fonction en entités dans le store.
 
-- `dataSources.mapping.blockHandlers`: lists the blocks this subgraph reacts to and handlers in the mapping to run when a block is appended to the chain. Without a filter, the block handler will be run every block. An optional call-filter can be provided by adding a `filter` field with `kind: call` to the handler. This will only run the handler if the block contains at least one call to the data source contract.
+- `dataSources.mapping.blockHandlers` : liste les blocs auxquels ce subgraph réagit et les gestionnaires du mappage à exécuter lorsqu'un bloc est ajouté à la blockchain. Sans filtre, le gestionnaire de bloc sera exécuté à chaque bloc. Un filtre d'appel optionnel peut être fourni en ajoutant un champ `filter` avec `kind : call` au gestionnaire. Ceci ne lancera le gestionnaire que si le bloc contient au moins un appel au contrat de la source de données.
 
-A single subgraph can index data from multiple smart contracts. Add an entry for each contract from which data needs to be indexed to the `dataSources` array.
+Un seul subgraph peut indexer des données provenant de plusieurs contrats intelligents. Ajoutez une entrée pour chaque contrat dont les données doivent être indexées dans le tableau `dataSources`.
 
 ## Gestionnaires d'événements
 
@@ -149,15 +149,15 @@ dataSources:
 
 ## Gestionnaires d'appels
 
-While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an `ethereum.Call` as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.
+Si les événements constituent un moyen efficace de collecter les modifications pertinentes de l'état d'un contrat, de nombreux contrats évitent de générer des logs afin d'optimiser les coûts de gaz. Dans ce cas, un subgraph peut s'abonner aux appels faits au contrat de source de données. Pour ce faire, il suffit de définir des gestionnaires d'appels faisant référence à la signature de la fonction et au gestionnaire de mappage qui traitera les appels à cette fonction. Pour traiter ces appels, le gestionnaire de mappage recevra un `ethereum.Call` comme argument avec les entrées et sorties typées de l'appel. Les appels effectués à n'importe quel niveau de la blockchain d'appels d'une transaction déclencheront le mappage, ce qui permettra de capturer l'activité avec le contrat de source de données par le biais de contrats proxy.
 
 Les gestionnaires d'appels ne se déclencheront que dans l'un des deux cas suivants : lorsque la fonction spécifiée est appelée par un compte autre que le contrat lui-même ou lorsqu'elle est marquée comme externe dans Solidity et appelée dans le cadre d'une autre fonction du même contrat.
 
-> **Note:** Call handlers currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more call handlers, it will not start syncing. Subgraph developers should instead use event handlers. These are far more performant than call handlers, and are supported on every evm network.
+> **Note:** Les gestionnaires d'appels dépendent actuellement de l'API de traçage de Parité. Certains réseaux, tels que BNB chain et Arbitrum, ne supportent pas cette API. Si un subgraph indexant l'un de ces réseaux contient un ou plusieurs gestionnaires d'appels, il ne commencera pas à se synchroniser. Les développeurs de subgraphs devraient plutôt utiliser des gestionnaires d'événements. Ceux-ci sont bien plus performants que les gestionnaires d'appels et sont pris en charge par tous les réseaux evm.
 
 ### Définir un gestionnaire d'appels
 
-To define a call handler in your manifest, simply add a `callHandlers` array under the data source you would like to subscribe to.
+Pour définir un gestionnaire d'appel dans votre manifeste, ajoutez simplement un tableau `callHandlers` sous la source de données à laquelle vous souhaitez vous abonner.
 
 ```yaml
 dataSources:
@@ -182,11 +182,11 @@ dataSources:
           handler: handleCreateGravatar
 ```
 
-The `function` is the normalized function signature to filter calls by. The `handler` property is the name of the function in your mapping you would like to execute when the target function is called in the data source contract.
+La propriété `function` est la signature de la fonction normalisée pour filtrer les appels. La propriété `handler` est le nom de la fonction dans votre mappage que vous souhaitez exécuter lorsque la fonction cible est appelée dans le contrat de la source de données.
 
 ### Fonction de cartographie
 
-Each call handler takes a single parameter that has a type corresponding to the name of the called function. In the example subgraph above, the mapping contains a handler for when the `createGravatar` function is called and receives a `CreateGravatarCall` parameter as an argument:
+Chaque gestionnaire d'appel prend un seul paramètre qui a un type correspondant au nom de la fonction appelée. Dans l'exemple du subgraph ci-dessus, le mapping contient un gestionnaire d'appel lorsque la fonction `createGravatar` est appelée et reçoit un paramètre `CreateGravatarCall` en tant qu'argument :
 
 ```typescript
 import { CreateGravatarCall } from '../generated/Gravity/Gravity'
@@ -201,7 +201,7 @@ export function handleCreateGravatar(call: CreateGravatarCall): void {
 }
 ```
 
-The `handleCreateGravatar` function takes a new `CreateGravatarCall` which is a subclass of `ethereum.Call`, provided by `@graphprotocol/graph-ts`, that includes the typed inputs and outputs of the call. The `CreateGravatarCall` type is generated for you when you run `graph codegen`.
+La fonction `handleCreateGravatar` prend un nouveau `CreateGravatarCall` qui est une sous-classe de `ethereum.Call`, fournie par `@graphprotocol/graph-ts`, qui inclut les entrées et sorties typées de l'appel. Le type `CreateGravatarCall` est généré pour vous lorsque vous lancez `graph codegen`.
 
 ## Block Handlers
 
@@ -216,9 +216,9 @@ filter:
   kind: call
 ```
 
-_The defined handler will be called once for every block which contains a call to the contract (data source) the handler is defined under._
+_Le gestionnaire défini sera appelé une fois pour chaque bloc qui contient un appel au contrat (source de données) sous lequel le gestionnaire est défini._
 
-> **Note:** The `call` filter currently depend on the Parity tracing API. Certain networks, such as BNB chain and Arbitrum, does not support this API. If a subgraph indexing one of these networks contain one or more block handlers with a `call` filter, it will not start syncing.
+> **Note:** Le filtre `call` dépend actuellement de l'API de traçage de Parité. Certains réseaux, tels que BNB chain et Arbitrum, ne supportent pas cette API. Si un subgraph indexant un de ces réseaux contient un ou plusieurs gestionnaire de bloc avec un filtre `call`, il ne commencera pas à se synchroniser.
 
 L'absence de filtre pour un gestionnaire de bloc garantira que le gestionnaire est appelé à chaque bloc. Une source de données ne peut contenir qu'un seul gestionnaire de bloc pour chaque type de filtre.
 
@@ -249,9 +249,9 @@ dataSources:
 
 #### Filtre d'interrogation
 
-> **Requires `specVersion` >= 0.0.8**
+> **Nécessite `specVersion` >= 0.0.8**
 >
-> **Note:** Polling filters are only available on dataSources of `kind: ethereum`.
+> **Note:** Les filtres d'interrogation ne sont disponibles que sur les dataSources de `kind : ethereum`.
 
 ```yaml
 blockHandlers:
@@ -261,13 +261,13 @@ blockHandlers:
       every: 10
 ```
 
-The defined handler will be called once for every `n` blocks, where `n` is the value provided in the `every` field. This configuration allows the subgraph to perform specific operations at regular block intervals.
+Le gestionnaire défini sera appelé une fois tous les `n` blocs, où `n` est la valeur fournie dans le champ `every`. Cette configuration permet au subgraph d'effectuer des opérations spécifiques à intervalles réguliers.
 
 #### Le filtre Once
 
-> **Requires `specVersion` >= 0.0.8**
+> **Nécessite `specVersion` >= 0.0.8**
 >
-> **Note:** Once filters are only available on dataSources of `kind: ethereum`.
+> **Note:** Les filtres Once ne sont disponibles que sur les dataSources de `kind : ethereum`.
 
 ```yaml
 blockHandlers:
@@ -288,7 +288,7 @@ export function handleOnce(block: ethereum.Block): void {
 
 ### Fonction de cartographie
 
-The mapping function will receive an `ethereum.Block` as its only argument. Like mapping functions for events, this function can access existing subgraph entities in the store, call smart contracts and create or update entities.
+La fonction de mappage recevra une `ethereum.Block` comme seul argument. Comme les fonctions de mappage pour les événements, cette fonction peut accéder aux entités de subgraphs existantes dans le store, appeler des contrats intelligents et créer ou mettre à jour des entités.
 
 ```typescript
 import { ethereum } from '@graphprotocol/graph-ts'
@@ -311,13 +311,13 @@ eventHandlers:
     handler: handleGive
 ```
 
-An event will only be triggered when both the signature and topic 0 match. By default, `topic0` is equal to the hash of the event signature.
+Un événement ne sera déclenché que si la signature et le sujet 0 correspondent. Par défaut, `topic0` est égal au hash de la signature de l'événement.
 
 ## Reçus de transaction dans les gestionnaires d'événements
 
-Starting from `specVersion` `0.0.5` and `apiVersion` `0.0.7`, event handlers can have access to the receipt for the transaction which emitted them.
+A partir de `specVersion` `0.0.5` et `apiVersion` `0.0.7`, les gestionnaires d'événements peuvent avoir accès au reçu de la transaction qui les a émis.
 
-To do so, event handlers must be declared in the subgraph manifest with the new `receipt: true` key, which is optional and defaults to false.
+Pour ce faire, les gestionnaires d'événements doivent être déclarés dans le manifeste du subgraph avec la nouvelle clé `receipt : true`, qui est facultative et prend par défaut la valeur false.
 
 ```yaml
 eventHandlers:
@@ -326,7 +326,7 @@ eventHandlers:
     receipt: true
 ```
 
-Inside the handler function, the receipt can be accessed in the `Event.receipt` field. When the `receipt` key is set to `false` or omitted in the manifest, a `null` value will be returned instead.
+Dans la fonction handler, le reçu peut être accédé dans le champ `Event.receipt`. Si la clé `receipt` est fixée à `false` ou omise dans le manifeste, une valeur `null` sera renvoyée à la place.
 
 ## Ordre de déclenchement des gestionnaires
 
@@ -338,17 +338,17 @@ Les déclencheurs d'une source de données au sein d'un bloc sont classés à l'
 
 Ces règles de commande sont susceptibles de changer.
 
-> **Note:** When new [dynamic data source](#data-source-templates-for-dynamically-created-contracts) are created, the handlers defined for dynamic data sources will only start processing after all existing data source handlers are processed, and will repeat in the same sequence whenever triggered.
+> **Note:** Lorsque de nouvelles [sources de données dynamiques] (#data-source-templates-for-dynamically-created-contracts) sont créées, les gestionnaires définis pour les sources de données dynamiques ne commenceront à être traités qu'une fois que tous les gestionnaires de sources de données existants auront été traités, et se répéteront dans la même séquence chaque fois qu'ils seront déclenchés.
 
 ## Modèles de sources de données
 
 Un modèle courant dans les contrats intelligents compatibles EVM est l'utilisation de contrats de registre ou d'usine, dans lesquels un contrat crée, gère ou référence un nombre arbitraire d'autres contrats qui ont chacun leur propre état et leurs propres événements.
 
-The addresses of these sub-contracts may or may not be known upfront and many of these contracts may be created and/or added over time. This is why, in such cases, defining a single data source or a fixed number of data sources is impossible and a more dynamic approach is needed: _data source templates_.
+Les adresses de ces sous-contrats peuvent ou non être connues à l'avance et nombre de ces contrats peuvent être créés et/ou ajoutés au fil du temps. C'est pourquoi, dans de tels cas, la définition d'une source de données unique ou d'un nombre fixe de sources de données est impossible et une approche plus dynamique est nécessaire : les _modèles de sources de données_.
 
 ### Source de données pour le contrat principal
 
-First, you define a regular data source for the main contract. The snippet below shows a simplified example data source for the [Uniswap](https://uniswap.org) exchange factory contract. Note the `NewExchange(address,address)` event handler. This is emitted when a new exchange contract is created onchain by the factory contract.
+Tout d'abord, vous devez définir une source de données régulière pour le contrat principal. L'extrait ci-dessous montre un exemple simplifié de source de données pour le contrat factory de l'exchange [Uniswap](https://uniswap.org). Notez le gestionnaire d'événement `NewExchange(address,address)`. Il est émis lorsqu'un nouveau contrat d'exchange est créé onchain par le contrat factory.
 
 ```yaml
 dataSources:
@@ -375,7 +375,7 @@ dataSources:
 
 ### Modèles de source de données pour les contrats créés dynamiquement
 
-Then, you add _data source templates_ to the manifest. These are identical to regular data sources, except that they lack a pre-defined contract address under `source`. Typically, you would define one template for each type of sub-contract managed or referenced by the parent contract.
+Ensuite, vous ajoutez des _modèles de sources de données_ au manifeste. Ceux-ci sont identiques aux sources de données classiques, sauf qu'ils n'ont pas d'adresse de contrat prédéfinie sous `source`. Typiquement, vous devriez définir un modèle pour chaque type de sous-contrat géré ou référencé par le contrat parent.
 
 ```yaml
 dataSources:
@@ -411,7 +411,7 @@ templates:
 
 ### Instanciation d'un modèle de source de données
 
-In the final step, you update your main contract mapping to create a dynamic data source instance from one of the templates. In this example, you would change the main contract mapping to import the `Exchange` template and call the `Exchange.create(address)` method on it to start indexing the new exchange contract.
+Dans la dernière étape, vous mettez à jour votre mappage du contrat principal pour créer une instance de source de données dynamique à partir de l'un des modèles. Dans cet exemple, vous modifiez le mappage du contrat principal pour importer le modèle `Exchange` et appeler la méthode `Exchange.create(address)` pour commencer à indexer le nouveau contrat d'exchange.
 
 ```typescript
 import { Exchange } from '../generated/templates'
@@ -423,13 +423,13 @@ export function handleNewExchange(event: NewExchange): void {
 }
 ```
 
-> **Note:** A new data source will only process the calls and events for the block in which it was created and all following blocks, but will not process historical data, i.e., data that is contained in prior blocks.
+> **Note:** Une nouvelle source de données ne traitera que les appels et les événements du bloc dans lequel elle a été créée et de tous les blocs suivants, mais ne traitera pas les données historiques, c'est-à-dire les données contenues dans les blocs précédents.
 >
 > Si les blocs précédents contiennent des données pertinentes pour la nouvelle source de données, il est préférable d'indexer ces données en lisant l'état actuel du contrat et en créant des entités représentant cet état au moment de la création de la nouvelle source de données.
 
 ### Data Source Context
 
-Data source contexts allow passing extra configuration when instantiating a template. In our example, let's say exchanges are associated with a particular trading pair, which is included in the `NewExchange` event. That information can be passed into the instantiated data source, like so:
+Les contextes de source de données permettent de passer une configuration supplémentaire lors de l'instanciation d'un modèle. Dans notre exemple, disons que les éxchanges sont associés à une paire de trading particulière, qui est incluse dans l'événement `NewExchange`. Cette information peut être passée dans la source de données instanciée, comme suit :
 
 ```typescript
 import { Exchange } from '../generated/templates'
@@ -441,7 +441,7 @@ export function handleNewExchange(event: NewExchange): void {
 }
 ```
 
-Inside a mapping of the `Exchange` template, the context can then be accessed:
+A l'intérieur d'un mappage du modèle `Exchange`, il est possible d'accéder au contexte :
 
 ```typescript
 import { dataSource } from '@graphprotocol/graph-ts'
@@ -450,11 +450,11 @@ let context = dataSource.context()
 let tradingPair = context.getString('tradingPair')
 ```
 
-There are setters and getters like `setString` and `getString` for all value types.
+Il existe des setters et getters comme `setString` et `getString` pour tous les types de valeurs.
 
 ## Blocs de démarrage
 
-The `startBlock` is an optional setting that allows you to define from which block in the chain the data source will start indexing. Setting the start block allows the data source to skip potentially millions of blocks that are irrelevant. Typically, a subgraph developer will set `startBlock` to the block in which the smart contract of the data source was created.
+Le `startBlock` est un paramètre optionnel qui vous permet de définir à partir de quel bloc de la chaîne la source de données commencera l'indexation. Définir le bloc de départ permet à la source de données de sauter potentiellement des millions de blocs qui ne sont pas pertinents. En règle générale, un développeur de subgraphs définira `startBlock` au bloc dans lequel le contrat intelligent de la source de données a été créé.
 
 ```yaml
 dataSources:
@@ -480,24 +480,24 @@ dataSources:
           handler: handleNewEvent
 ```
 
-> **Note:** The contract creation block can be quickly looked up on Etherscan:
+> **Note:** Le bloc de création du contrat peut être consulté rapidement sur Etherscan :
 >
 > 1. Recherchez le contrat en saisissant son adresse dans la barre de recherche.
-> 2. Click on the creation transaction hash in the `Contract Creator` section.
+> 2. Cliquez sur le hash de la transaction de création dans la section `Contract Creator`.
 > 3. Chargez la page des détails de la transaction où vous trouverez le bloc de départ de ce contrat.
 
 ## Conseils pour l'indexeur
 
-The `indexerHints` setting in a subgraph's manifest provides directives for indexers on processing and managing a subgraph. It influences operational decisions across data handling, indexing strategies, and optimizations. Presently, it features the `prune` option for managing historical data retention or pruning.
+Le paramètre `indexerHints` dans le manifeste d'un subgraph fournit des directives aux Indexeurs sur le traitement et la gestion d'un subgraph. Il influence les décisions opérationnelles concernant le traitement des données, les stratégies d'indexation et les optimisations. Actuellement, il propose l'option `prune` pour gérer la rétention ou suppression des données historiques.
 
-> This feature is available from `specVersion: 1.0.0`
+> Cette fonctionnalité est disponible à partir de `specVersion : 1.0.0`
 
 ### Prune
 
-`indexerHints.prune`: Defines the retention of historical block data for a subgraph. Options include:
+`indexerHints.prune` : Définit la rétention des données de blocs historiques pour un subgraph. Les options sont les suivantes :
 
-1. `"never"`: No pruning of historical data; retains the entire history.
-2. `"auto"`: Retains the minimum necessary history as set by the indexer, optimizing query performance.
+1. `"never"`: Aucune suppression des données historiques ; conserve l'ensemble de l'historique.
+2. `"auto"`: Conserve l'historique minimum nécessaire tel que défini par l'Indexeur, optimisant ainsi les performances de la requête.
 3. Un nombre spécifique : Fixe une limite personnalisée au nombre de blocs historiques à conserver.
 
 ```
@@ -509,21 +509,21 @@ The `indexerHints` setting in a subgraph's manifest provides directives for inde
 
 L'historique à partir d'un bloc donné est requis pour :
 
-- [Time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), which enable querying the past states of these entities at specific blocks throughout the subgraph's history
-- Using the subgraph as a [graft base](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) in another subgraph, at that block
+- Les [requêtes chronologiques](/subgraphs/querying/graphql-api/#time-travel-queries), qui permettent d'interroger les états passés de ces entités à des moments précis de l'histoire du subgraph
+- Utilisation du subgraph comme [base de greffage](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs) dans un autre subgraph, à ce bloc
 - Rembobiner le subgraph jusqu'à ce bloc
 
 Si les données historiques à partir du bloc ont été purgées, les capacités ci-dessus ne seront pas disponibles.
 
-> Using `"auto"` is generally recommended as it maximizes query performance and is sufficient for most users who do not require access to extensive historical data.
+> L'utilisation de `"auto"` est généralement recommandée car elle maximise les performances des requêtes et est suffisante pour la plupart des utilisateurs qui n'ont pas besoin d'accéder à des données historiques étendues.
 
-For subgraphs leveraging [time travel queries](/subgraphs/querying/graphql-api/#time-travel-queries), it's advisable to either set a specific number of blocks for historical data retention or use `prune: never` to keep all historical entity states. Below are examples of how to configure both options in your subgraph's settings:
+Pour les subgraphs exploitant les [requêtes chronologiques](/subgraphs/querying/graphql-api/#time-travel-queries), il est conseillé de définir un nombre spécifique de blocs pour la conservation des données historiques ou d'utiliser `prune: never` pour conserver tous les états d'entité historiques. Vous trouverez ci-dessous des exemples de configuration des deux options dans les paramètres de votre subgraphs :
 
 Pour conserver une quantité spécifique de données historiques :
 
 ```
  indexerHints:
-  prune: 1000 # Replace 1000 with the desired number of blocks to retain
+  prune: 1000 # Remplacez 1000 par le nombre de blocs souhaité à conserver
 ```
 
 Préserver l'histoire complète des États de l'entité :

From 796d75cd40378e8d69ecbd6f3f545e01771f7f33 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:14 -0500
Subject: [PATCH 2814/3820] New translations multiple-networks.mdx (French)

---
 .../fr/subgraphs/developing/deploying/multiple-networks.mdx     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/developing/deploying/multiple-networks.mdx b/website/pages/fr/subgraphs/developing/deploying/multiple-networks.mdx
index ad2fc10ea4c6..a72771045069 100644
--- a/website/pages/fr/subgraphs/developing/deploying/multiple-networks.mdx
+++ b/website/pages/fr/subgraphs/developing/deploying/multiple-networks.mdx
@@ -2,7 +2,7 @@
 title: Déploiement d'un subgraph sur plusieurs réseaux
 ---
 
-This page explains how to deploy a subgraph to multiple networks. To deploy a subgraph you need to first install the [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). If you have not created a subgraph already, see [Creating a subgraph](/developing/creating-a-subgraph/).
+Cette page explique comment déployer un subgraph sur plusieurs réseaux. Pour déployer un subgraph, vous devez d'abord installer [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). Si vous n'avez pas encore créé de subgraph, consultez [Créer un subgraph](/developing/creating-a-subgraph/).
 
 ## Déploiement du subgraph sur plusieurs réseaux
 

From 986952bee6398bc3c99f26f051ec24089105ccae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:15 -0500
Subject: [PATCH 2815/3820] New translations subgraph-studio-faq.mdx (French)

---
 .../subgraphs/developing/deploying/subgraph-studio-faq.mdx  | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/fr/subgraphs/developing/deploying/subgraph-studio-faq.mdx
index 1d4c32ccc75e..10300b3d9ada 100644
--- a/website/pages/fr/subgraphs/developing/deploying/subgraph-studio-faq.mdx
+++ b/website/pages/fr/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -4,7 +4,7 @@ title: Subgraph Studio FAQ
 
 ## 1. Qu'est-ce que Subgraph Studio ?
 
-[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+[Subgraph Studio](https://thegraph.com/studio/) est une dapp permettant de créer, gérer et publier des subgraphs et des clés API.
 
 ## 2. Comment créer une clé API ?
 
@@ -12,7 +12,7 @@ Pour créer une API, allez dans Subgraph Studio et connectez votre portefeuille.
 
 ## 3. Puis-je créer plusieurs clés API ?
 
-Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+Oui ! Vous pouvez créer plusieurs clés API à utiliser dans différents projets. Consultez le lien [ici](https://thegraph.com/studio/apikeys/).
 
 ## 4. Comment limiter un domaine pour une clé API ? ?
 
@@ -26,6 +26,6 @@ Notez que vous ne pourrez plus voir ou modifier le subgraph dans Studio une fois
 
 ## Comment trouver les URL de requête pour les sugraphs si je ne suis pas le développeur du subgraph que je veux utiliser ?
 
-You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+Vous pouvez trouver l'URL de requête de chaque subgraph dans la section Détails du subgraph de Graph Explorer. Lorsque vous cliquez sur le bouton “Requête”, vous serez redirigé vers un volet dans lequel vous pourrez afficher l'URL de requête du subgraph qui vous intéresse. Vous pouvez ensuite remplacer le placeholder `<api_key>` par la clé API que vous souhaitez exploiter dans Subgraph Studio.
 
 N'oubliez pas que vous pouvez créer une clé API et interroger n'importe quel subgraph publié sur le réseau, même si vous créez vous-même un subgraph. Ces requêtes via la nouvelle clé API, sont des requêtes payantes comme n'importe quelle autre sur le réseau.

From 5a460e6627b5d7ac1f3b1c5de7591859a268ed96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:16 -0500
Subject: [PATCH 2816/3820] New translations using-subgraph-studio.mdx (French)

---
 .../deploying/using-subgraph-studio.mdx          | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx
index 65d07476f124..7f70f9772371 100644
--- a/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx
+++ b/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -1,10 +1,10 @@
 ---
-title: Deploying Using Subgraph Studio
+title: Déploiement en utilisant Subgraph Studio
 ---
 
 Apprenez à déployer votre subgraph sur Subgraph Studio.
 
-> Note: When you deploy a subgraph, you push it to Subgraph Studio, where you'll be able to test it. It's important to remember that deploying is not the same as publishing. When you publish a subgraph, you're publishing it onchain.
+> Remarque : lorsque vous déployez un subgraph, vous le transférez vers Subgraph Studio, où vous pourrez le tester. Il est important de se rappeler que le déploiement n'est pas la même chose que la publication. Lorsque vous publiez un subgraph, vous le publiez onchain.
 
 ## Présentation de Subgraph Studio
 
@@ -53,13 +53,13 @@ npm install -g @graphprotocol/graph-cli
 
 <VideoEmbed youtube="nGIFuC69bSA" />
 
-> For additional written detail, review the [Quick Start](/subgraphs/quick-start/).
+> Pour plus de détails écrits, consultez le [Démarrage rapide](/subgraphs/quick-start/).
 
 ### Compatibilité des subgraphs avec le réseau de The Graph
 
 Pour être pris en charge par les Indexeurs sur The Graph Network, les subgraphs doivent :
 
-- Index a [supported network](/supported-networks/)
+- Indexer un [réseau pris en charge](/supported-networks/)
 - Ne doit utiliser aucune des fonctionnalités suivantes :
   - ipfs.cat & ipfs.map
   - Erreurs non fatales
@@ -86,7 +86,7 @@ Avant de pouvoir déployer votre subgraph sur Subgraph Studio, vous devez vous c
 Ensuite, utilisez la commande suivante pour vous authentifier depuis la CLI :
 
 ```bash
-graph auth <DEPLOY KEY>
+graph auth <CLE_DE_DEPLOIEMENT>
 ```
 
 ## Déploiement d'un Subgraph
@@ -114,7 +114,7 @@ Utilisez Subgraph Studio pour vérifier les journaux (logs) sur le tableau de bo
 
 ## Publiez votre subgraph
 
-In order to publish your subgraph successfully, review [publishing a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
+Afin de publier votre subgraph avec succès, consultez [publier un subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
 
 ## Versionning de votre subgraph avec le CLI
 
@@ -124,9 +124,9 @@ Si vous souhaitez mettre à jour votre subgraph, vous pouvez faire ce qui suit :
 - Une fois que vous en êtes satisfait, vous pouvez publier votre nouveau déploiement sur [Graph Explorer](https://thegraph.com/explorer).
 - Cette action créera une nouvelle version de votre subgraph sur laquelle les Curateurs pourront commencer à signaler et que les Indexeurs pourront indexer.
 
-You can also update your subgraph's metadata without publishing a new version. You can update your subgraph details in Studio (under the profile picture, name, description, etc.) by checking an option called **Update Details** in [Graph Explorer](https://thegraph.com/explorer). If this is checked, an onchain transaction will be generated that updates subgraph details in Explorer without having to publish a new version with a new deployment.
+Vous pouvez également mettre à jour les métadonnées de votre subgraph sans publier de nouvelle version. Vous pouvez mettre à jour les détails de votre subgraph dans Studio (sous la photo de profil, le nom, la description, etc.) en cochant une option appelée **Mettre à jour les détails** dans [Graph Explorer](https://thegraph.com/explorer). Si cette option est cochée, une transaction onchain sera générée qui mettra à jour les détails du subgraph dans Explorer sans avoir à publier une nouvelle version avec un nouveau déploiement.
 
-> Note: There are costs associated with publishing a new version of a subgraph to the network. In addition to the transaction fees, you must also fund a part of the curation tax on the auto-migrating signal. You cannot publish a new version of your subgraph if Curators have not signaled on it. For more information, please read more [here](/resources/roles/curating/).
+> Remarque : la publication d'une nouvelle version d'un subgraph sur le réseau entraîne des coûts. En plus des frais de transaction, vous devez également financer une partie de la taxe de curation sur le signal de migration automatique. Vous ne pouvez pas publier une nouvelle version de votre subgraph si les Curateurs ne l'ont pas signalé. Pour plus d'informations, veuillez lire la suite [ici](/resources/roles/curating/).
 
 ## Archivage automatique des versions de subgraphs
 

From 2fd71609b7401bb42606ab4a23d08b7574867730 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:17 -0500
Subject: [PATCH 2817/3820] New translations developer-faq.mdx (French)

---
 .../fr/subgraphs/developing/developer-faq.mdx | 32 +++++++++----------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/developer-faq.mdx b/website/pages/fr/subgraphs/developing/developer-faq.mdx
index 347019ec7532..2c260b8dd04d 100644
--- a/website/pages/fr/subgraphs/developing/developer-faq.mdx
+++ b/website/pages/fr/subgraphs/developing/developer-faq.mdx
@@ -1,5 +1,5 @@
 ---
-title: Developer FAQ
+title: FAQ pour les développeurs
 ---
 
 Cette page résume certaines des questions les plus courantes pour les développeurs construisant sur The Graph.
@@ -12,7 +12,7 @@ Un subgraph est une API personnalisée construite sur des données blockchain. L
 
 ### 2. Quelle est la première étape pour créer un subgraph ?
 
-To successfully create a subgraph, you will need to install The Graph CLI. Review the [Quick Start](/subgraphs/quick-start/) to get started. For detailed information, see [Creating a Subgraph](/developing/creating-a-subgraph/).
+Pour créer un subgraph avec succès, vous devez installer Graph CLI. Consultez le [Démarrage rapide](/subgraphs/quick-start/) pour commencer. Pour des informations détaillées, consultez [Création d'un subgraph](/developing/creating-a-subgraph/).
 
 ### 3. Suis-je toujours en mesure de créer un subgraph si mes smart contracts n'ont pas d'événements ?
 
@@ -34,9 +34,9 @@ Vous devez redéployer le subgraph, mais si l'ID de subgraph (hachage IPFS) ne c
 
 ### 7. Comment puis-je appeler une fonction d'un contrat ou accéder à une variable d'état publique depuis mes mappages de subgraph ?
 
-Take a look at `Access to smart contract` state inside the section [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
+Jetez un œil à l’état `Accès au contrat intelligent` dans la section [API AssemblyScript](/subgraphs/developing/creating/graph-ts/api/#access-to-smart-contract-state).
 
-### 8. Can I import `ethers.js` or other JS libraries into my subgraph mappings?
+### 8. Puis-je importer `ethers.js` ou d'autres bibliothèques JS dans mes mappages de subgraphs ?
 
 Actuellement non, car les mappages sont écrits en AssemblyScript.
 
@@ -50,13 +50,13 @@ Dans un subgraph, les événements sont toujours traités dans l'ordre dans lequ
 
 Les modèles vous permettent de créer rapidement des sources de données , pendant que votre subgraph est en cours d'indexation. Votre contrat peut générer de nouveaux contrats à mesure que les gens interagissent avec lui. Étant donné que vous connaissez la structure de ces contrats (ABI, événements, etc.) à l'avance, vous pouvez définir comment vous souhaitez les indexer dans un modèle. Lorsqu'ils sont générés, votre subgraph créera une source de données dynamique en fournissant l'adresse du contrat.
 
-Check out the "Instantiating a data source template" section on: [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates).
+Consultez la section "Instanciation d'un modèle de source de données" sur : [Modèles de sources de données](/developing/creating-a-subgraph/#data-source-templates).
 
-### 11. Is it possible to set up a subgraph using `graph init` from `graph-cli` with two contracts? Or should I manually add another dataSource in `subgraph.yaml` after running `graph init`?
+### 11. Est-il possible de configurer un subgraph en utilisant `graph init` à partir de `graph-cli` avec deux contrats ? Ou dois-je ajouter manuellement une autre source de données dans `subgraph.yaml` après avoir lancé `graph init` ?
 
-Yes. On `graph init` command itself you can add multiple dataSources by entering contracts one after the other.
+Oui. Dans la commande `graph init` elle-même, vous pouvez ajouter plusieurs sources de données en entrant des contrats l'un après l'autre.
 
-You can also use `graph add` command to add a new dataSource.
+Vous pouvez également utiliser la commande `graph add` pour ajouter une nouvelle source de données.
 
 ### 12. Dans quel ordre les gestionnaires d'événements, de blocs et d'appels sont-ils déclenchés pour une source de données ?
 
@@ -76,21 +76,21 @@ docker pull graphprotocol/graph-node:dernier
 
 ### 14. Quelle est la méthode recommandée pour créer des Ids "autogénérés" pour une entité pendant la gestion des événements ?
 
-If only one entity is created during the event and if there's nothing better available, then the transaction hash + log index would be unique. You can obfuscate these by converting that to Bytes and then piping it through `crypto.keccak256` but this won't make it more unique.
+Si une seule entité est créée pendant l'événement et s'il n'y a rien de mieux disponible, alors le hash de la transaction + l'index du journal seront uniques. Vous pouvez les obscurcir en les convertissant en Bytes et en les faisant passer par `crypto.keccak256`, mais cela ne les rendra pas plus uniques.
 
 ### 15. Puis-je supprimer mon subgraph ?
 
-Yes, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) and [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) your subgraph.
+Oui, vous pouvez [supprimer](/subgraphs/developing/managing/deleting-a-subgraph/) et [transférer](/subgraphs/developing/managing/transferring-a-subgraph/) votre subgraph.
 
 ## Relatif au Réseau
 
 ### 16. Quels réseaux sont supportés par The Graph?
 
-You can find the list of the supported networks [here](/supported-networks/).
+Vous pouvez trouver la liste des réseaux pris en charge [ici](/supported-networks/).
 
 ### 17. Est-il possible de faire la différence entre les réseaux (mainnet, Sepolia, local) dans les gestionnaires d'événements?
 
-Yes. You can do this by importing `graph-ts` as per the example below:
+Oui, vous pouvez le faire en important `graph-ts` comme dans l'exemple ci-dessous :
 
 ```javascript
 importez { dataSource } de '@graphprotocol/graph-ts'
@@ -103,15 +103,15 @@ dataSource.address()
 
 Oui. Sepolia prend en charge les gestionnaires de blocs, les gestionnaires d'appels et les gestionnaires d'événements. Il convient de noter que les gestionnaires d'événements sont beaucoup plus performants que les deux autres gestionnaires, et ils sont pris en charge sur tous les réseaux compatibles EVM.
 
-## Indexing & Querying Related
+## En rapport avec L'Indexation & L'interrogation
 
 ### 19. Est-il possible de spécifier à partir de quel bloc commencer l'indexation?
 
-Yes. `dataSources.source.startBlock` in the `subgraph.yaml` file specifies the number of the block that the dataSource starts indexing from. In most cases, we suggest using the block where the contract was created: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+Oui. `dataSources.source.startBlock` dans le fichier `subgraph.yaml` spécifie le numéro du bloc à partir duquel la source de données commence l'indexation. Dans la plupart des cas, nous suggérons d'utiliser le bloc où le contrat a été créé : [Start blocks](/developing/creating-a-subgraph/#start-blocks)
 
 ### 20. Quels sont quelques conseils pour augmenter les performances d'indexation? Mon subgraph prend beaucoup de temps à se synchroniser
 
-Yes, you should take a look at the optional start block feature to start indexing from the block where the contract was deployed: [Start blocks](/developing/creating-a-subgraph/#start-blocks)
+Oui, vous devriez jeter un coup d'œil à la fonctionnalité optionnelle de bloc de démarrage pour commencer l'indexation à partir du bloc où le contrat a été déployé : [Start blocks](/developing/creating-a-subgraph/#start-blocks)
 
 ### 21. Existe-t-il un moyen d'interroger directement le subgraph pour déterminer le dernier numéro de bloc qu'il a indexé?
 
@@ -131,7 +131,7 @@ someCollection(first: 1000, skip: <number>) { ... }
 
 ### 23. Si mon application décentralisée (dapp) utilise The Graph pour effectuer des requêtes, dois-je écrire ma clé API directement dans le code du frontend ? Et si nous payons les frais de requête pour les utilisateurs – des utilisateurs malveillants pourraient-ils faire augmenter considérablement nos frais de requête ?
 
-Currently, the recommended approach for a dapp is to add the key to the frontend and expose it to end users. That said, you can limit that key to a hostname, like _yourdapp.io_ and subgraph. The gateway is currently being run by Edge & Node. Part of the responsibility of a gateway is to monitor for abusive behavior and block traffic from malicious clients.
+Actuellement, l'approche recommandée pour une dapp est d'ajouter la clé au frontend et de l'exposer aux utilisateurs finaux. Cela dit, vous pouvez limiter cette clé à un nom d'hôte, comme _yourdapp.io_ et subgraph. La passerelle est actuellement gérée par Edge & Node. Une partie de la responsabilité d'une passerelle est de surveiller les comportements abusifs et de bloquer le trafic des clients malveillants.
 
 ## Divers
 

From bbcb20e28865aa5679943dd91b1ee2dddd440095 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:19 -0500
Subject: [PATCH 2818/3820] New translations introduction.mdx (French)

---
 .../pages/fr/subgraphs/developing/introduction.mdx   | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/introduction.mdx b/website/pages/fr/subgraphs/developing/introduction.mdx
index c9a871b50377..778ed8882543 100644
--- a/website/pages/fr/subgraphs/developing/introduction.mdx
+++ b/website/pages/fr/subgraphs/developing/introduction.mdx
@@ -1,8 +1,8 @@
 ---
-title: Introduction to Subgraph Development
+title: Introduction au développement de subgraphs
 ---
 
-To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
+Pour commencer à coder immédiatement, rendez-vous sur [Démarrage rapide pour les développeurs](/subgraphs/quick-start/).
 
 ## Aperçu
 
@@ -10,16 +10,16 @@ En tant que développeur, vous avez besoin de données pour construire et alimen
 
 Sur The Graph, vous pouvez :
 
-1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
+1. Créer, déployer et publier des subgraphs sur The Graph à l'aide de Graph CLI et de [Subgraph Studio](https://thegraph.com/studio/).
 2. Utiliser GraphQL pour interroger des subgraphs existants.
 
 ### Qu'est-ce que GraphQL ?
 
-- [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+- [GraphQL](https://graphql.org/learn/) est un langage de requête pour les API et un moteur d'exécution permettant d'exécuter ces requêtes avec vos données existantes. The Graph utilise GraphQL pour interroger les subgraphs.
 
 ### Actions des Développeurs
 
-- Query subgraphs built by other developers in [The Graph Network](https://thegraph.com/explorer) and integrate them into your own dapps.
+- Interrogez les subgraphs construits par d'autres développeurs dans [The Graph Network](https://thegraph.com/explorer) et intégrez-les dans vos propres dapps.
 - Créer des subgraphs personnalisés pour répondre à des besoins de données spécifiques, permettant une meilleure évolutivité et flexibilité pour les autres développeurs.
 - Déployer, publier et signaler vos subgraphs au sein de The Graph Network.
 
@@ -27,4 +27,4 @@ Sur The Graph, vous pouvez :
 
 Un subgraph est une API personnalisée construite sur des données blockchain. Il extrait des données d'une blockchain, les traite et les stocke afin qu'elles puissent être facilement interrogées via GraphQL.
 
-Check out the documentation on [subgraphs](/subgraphs/developing/subgraphs/) to learn specifics.
+Consultez la documentation sur les [subgraphs](/subgraphs/developing/subgraphs/) pour en savoir plus.

From 755decc4ff3a85eeb426cb73e1e23a64f1cf4b77 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:20 -0500
Subject: [PATCH 2819/3820] New translations deleting-a-subgraph.mdx (French)

---
 .../developing/managing/deleting-a-subgraph.mdx        | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx
index b9c7f99a89a7..4ccca71fd7f4 100644
--- a/website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx
+++ b/website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -1,16 +1,16 @@
 ---
-title: Deleting a Subgraph
+title: Suppression d'un Subgraph
 ---
 
-Delete your subgraph using [Subgraph Studio](https://thegraph.com/studio/).
+Supprimez votre subgraph en utilisant [Subgraph Studio](https://thegraph.com/studio/).
 
-> Deleting your subgraph will remove all published versions from The Graph Network, but it will remain visible on Graph Explorer and Subgraph Studio for users who have signaled on it.
+> En supprimant votre subgraph, vous supprimez toutes les versions publiées de The Graph Network, mais il restera visible sur Graph Explorer et Subgraph Studio pour les utilisateurs qui l'ont signalé.
 
 ## Étape par Étape
 
-1. Visit the subgraph's page on [Subgraph Studio](https://thegraph.com/studio/).
+1. Visitez la page du subgraph sur [Subgraph Studio](https://thegraph.com/studio/).
 
-2. Click on the three-dots to the right of the "publish" button.
+2. Cliquez sur les trois points à droite du bouton "publier".
 
 3. Click on the option to "delete this subgraph":
 

From bf7dfd039eb82b2a4904734fc8093ef6371fd467 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 13:41:21 -0500
Subject: [PATCH 2820/3820] New translations subgraphs.mdx (French)

---
 .../fr/subgraphs/developing/subgraphs.mdx     | 48 +++++++++----------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/subgraphs.mdx b/website/pages/fr/subgraphs/developing/subgraphs.mdx
index 2328038d075f..f979420b2d4a 100644
--- a/website/pages/fr/subgraphs/developing/subgraphs.mdx
+++ b/website/pages/fr/subgraphs/developing/subgraphs.mdx
@@ -6,7 +6,7 @@ title: Subgraphs
 
 A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
 
-### Subgraph Capabilities
+### Capacités des subgraphs
 
 - **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
 - **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
@@ -14,13 +14,13 @@ A subgraph is a custom, open API that extracts data from a blockchain, processes
 
 ## Inside a Subgraph
 
-The subgraph manifest, `subgraph.yaml`, defines the smart contracts & network your subgraph will index, the events from these contracts to pay attention to, and how to map event data to entities that Graph Node stores and allows to query.
+Le manifeste du subgraph, `subgraph.yaml`, définit les contrats intelligents et le réseau que votre subgraph va indexer, les événements de ces contrats auxquels il faut prêter attention, et comment faire correspondre les données d'événements aux entités que Graph Node stocke et permet d'interroger.
 
-The **subgraph definition** consists of the following files:
+La **définition du subgraph** se compose des fichiers suivants :
 
-- `subgraph.yaml`: Contains the subgraph manifest
+- `subgraph.yaml` : Contient le manifeste du subgraph
 
-- `schema.graphql`: A GraphQL schema defining the data stored for your subgraph and how to query it via GraphQL
+- `schema.graphql` : Un schéma GraphQL définissant les données stockées pour votre subgraph et comment les interroger via GraphQL
 
 - `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
 
@@ -51,36 +51,36 @@ Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deployi
 - Use its staging environment to index the deployed subgraph and make it available for review.
 - Verify that your subgraph doesn't have any indexing errors and works as expected.
 
-### Publish to the Network
+### Publier sur le réseau
 
-When you're happy with your subgraph, you can [publish it](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph Network.
+Lorsque vous êtes satisfait de votre subgraph, vous pouvez le [publier](/subgraphs/developing/publishing/publishing-a-subgraph/) sur The Graph Network.
 
-- This is an onchain action, which registers the subgraph and makes it discoverable by Indexers.
-- Published subgraphs have a corresponding NFT, which defines the ownership of the subgraph. You can [transfer the subgraph's ownership](/subgraphs/developing/managing/transferring-a-subgraph/) by sending the NFT.
-- Published subgraphs have associated metadata, which provides other network participants with useful context and information.
+- Il s'agit d'une action onchain, qui enregistre le subgraph et le rend accessible aux Indexeurs.
+- Les subgraphs publiés ont un NFT correspondant, qui définit la propriété du subgraph. Vous pouvez [transférer la propriété du subgraph](/subgraphes/developing/managing/transferring-a-subgraph/) en envoyant le NFT.
+- Les subgraphs publiés sont associés à des métadonnées qui fournissent aux autres participants du réseau un contexte et des informations utiles.
 
-### Add Curation Signal for Indexing
+### Ajouter un signal de curation pour l'indexation
 
-Published subgraphs are unlikely to be picked up by Indexers without curation signal. To encourage indexing you should add signal to your subgraph. Learn more about signaling and [curating](/resources/roles/curating/) on The Graph.
+Les subgraphs publiés ont peu de chances d'être repérés par les Indexeurs s'ils ne sont pas accompagnés d'un signal de curation. Pour encourager l'indexation, vous devez ajouter un signal à votre subgraph. Consultez la signalisation et la [curation](/resources/roles/curating/) sur The Graph.
 
-#### What is signal?
+#### Qu'est-ce qu'un signal ?
 
-- Signal is locked GRT associated with a given subgraph. It indicates to Indexers that a given subgraph will receive query volume and it contributes to the indexing rewards available for processing it.
-- Third-party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+- Le signal correspond aux GRT verrouillés associé à un subgraph donné. Il indique aux Indexeurs qu'un subgraph donné recevra un volume de requêtes et contribue aux récompenses d'indexation disponibles pour le traiter.
+- Les Curateurs tiers peuvent également signaler un subgraph donné s'ils estiment que ce subgraph est susceptible de générer un volume de requêtes.
 
-### Querying & Application Development
+### Intérrogation & Développement d'applications
 
-Subgraphs on The Graph Network receive 100,000 free queries per month, after which point developers can either [pay for queries with GRT or a credit card](/subgraphs/billing/).
+Les subgraphs sur The Graph Network reçoivent 100 000 requêtes gratuites par mois, après quoi les développeurs peuvent soit [payer les requêtes avec GRT ou une carte de crédit](/subgraphs/billing/).
 
-Learn more about [querying subgraphs](/subgraphs/querying/introduction/).
+En savoir plus sur [l'interrogation des subgraphs](/subgraphs/querying/introduction/).
 
-### Updating Subgraphs
+### Mise à jour des subgraphs
 
-To update your subgraph with bug fixes or new functionalities, initiate a transaction to point it to the new version. You can deploy new versions of your subgraphs to [Subgraph Studio](https://thegraph.com/studio/) for development and testing.
+Pour mettre à jour votre subgraph avec des corrections de bug ou de nouvelles fonctionnalités, lancez une transaction pour le faire pointer vers la nouvelle version. Vous pouvez déployer les nouvelles versions de vos subgraphs dans le [Subgraph Studio](https://thegraph.com/studio/) à des fins de développement et de test.
 
-- If you selected "auto-migrate" when you applied the signal, updating the subgraph will migrate any signal to the new version and incur a migration tax.
-- This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+- Si vous avez sélectionné "migration automatique" lorsque vous avez appliqué le signal, la mise à jour du subgraph migrera tout signal vers la nouvelle version et entraînera une taxe de migration.
+- Ce signal de migration devrait inciter les Indexeurs à commencer à indexer la nouvelle version du subgraph, qui devrait donc bientôt pouvoir être consultée.
 
-### Deleting & Transferring Subgraphs
+### Suppression et Transfert de Subgraphs
 
-If you no longer need a published subgraph, you can [delete](/subgraphs/developing/managing/deleting-a-subgraph/) or [transfer](/subgraphs/developing/managing/transferring-a-subgraph/) it. Deleting a subgraph returns any signaled GRT to [Curators](/resources/roles/curating/).
+Si vous n'avez plus besoin d'un subgraph publié, vous pouvez le [supprimer](/subgraphs/developing/managing/deleting-a-subgraph/) ou le [transférer](/subgraphs/developing/managing/transferring-a-subgraph/). La suppression d'un subgraph renvoie tout les GRT signalés aux [Curateurs](/resources/roles/curating/).

From 1d8726685e1975686542224714444388edcf9064 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 14:38:55 -0500
Subject: [PATCH 2821/3820] New translations install-the-cli.mdx (French)

---
 .../pages/fr/subgraphs/developing/creating/install-the-cli.mdx  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx
index 108969ebd67d..78f830c17c18 100644
--- a/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/install-the-cli.mdx
@@ -114,6 +114,6 @@ Le(s) fichier(s) ABI doivent correspondre à votre(vos) contrat(s). Il existe pl
 |  0.0.9  | Prend en charge la fonctionnalité `endBlock`                                                                                                                                                                     |
 |  0.0.8  | Ajout de la prise en charge des [gestionnaires de blocs](/developing/creating-a-subgraph/#polling-filter) et des [gestionnaires d'initialisation](/developing/creating-a-subgraph/#once-filter) d'interrogation. |
 |  0.0.7  | Ajout de la prise en charge des [fichiers sources de données](/developing/creating-a-subgraph/#file-data-sources).                                                                                               |
-|  0.0.6  | Supports fast [Proof of Indexing](/indexing/overview/#what-is-a-proof-of-indexing-poi) calculation variant.                                                                                                      |
+|  0.0.6  | Prend en charge la variante de calcul rapide de la [Preuve d'indexation](/indexing/overview/#what-is-a-proof-of-indexing-poi).                                                                                   |
 |  0.0.5  | Ajout de la prise en charge des gestionnaires d'événement ayant accès aux reçus de transactions.                                                                                                                 |
 |  0.0.4  | Ajout de la prise en charge du management des fonctionnalités de subgraph.                                                                                                                                       |

From b4ff8438b46117456b783e066257ce8841cd444f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 14:38:56 -0500
Subject: [PATCH 2822/3820] New translations ql-schema.mdx (French)

---
 .../developing/creating/ql-schema.mdx         | 66 +++++++++----------
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx b/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx
index f18ed6f7c382..efe6a52fb931 100644
--- a/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx
@@ -1,28 +1,28 @@
 ---
-title: The Graph QL Schema
+title: Schema The Graph QL
 ---
 
 ## Aperçu
 
-The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
+Le schéma de votre subgraph se trouve dans le fichier `schema.graphql`. Les schémas GraphQL sont définis à l'aide du langage de définition d'interface GraphQL.
 
-> Note: If you've never written a GraphQL schema, it is recommended that you check out this primer on the GraphQL type system. Reference documentation for GraphQL schemas can be found in the [GraphQL API](/subgraphs/querying/graphql-api/) section.
+> Remarque : si vous n'avez jamais écrit de schéma GraphQL, il est recommandé de consulter ce guide sur le système de types GraphQL. La documentation de référence pour les schémas GraphQL est disponible dans la section [API GraphQL](/subgraphs/querying/graphql-api/).
 
 ### Définition des entités
 
 Avant de définir des entités, il est important de prendre du recul et de réfléchir à la manière dont vos données sont structurées et liées.
 
-- All queries will be made against the data model defined in the subgraph schema. As a result, the design of the subgraph schema should be informed by the queries that your application will need to perform.
+- Toutes les requêtes seront effectuées sur le modèle de données défini dans le schéma de subgraph. Par conséquent, la conception du schéma de subgraph doit être informée par les requêtes que votre application devra exécuter.
 - Il peut être utile d'imaginer les entités comme des "objets contenant des données", plutôt que comme des événements ou des fonctions.
-- You define entity types in `schema.graphql`, and Graph Node will generate top-level fields for querying single instances and collections of that entity type.
-- Each type that should be an entity is required to be annotated with an `@entity` directive.
+- Vous définissez les types d'entités dans `schema.graphql`, et Graph Node générera des champs de premier niveau pour interroger des instances uniques et des collections de ce type d'entité.
+- Chaque type qui doit être une entité doit être annoté avec une directive `@entity`.
 - Par défaut, les entités sont mutables, ce qui signifie que les mappages peuvent charger des entités existantes, les modifier et stocker une nouvelle version de cette entité.
-  - Mutability comes at a price, so for entity types that will never be modified, such as those containing data extracted verbatim from the chain, it is recommended to mark them as immutable with `@entity(immutable: true)`.
+  - La mutabilité a un prix, donc pour les types d'entités qui ne seront jamais modifiés, comme ceux contenant des données extraites textuellement de la blockchain, il est recommandé de les marquer comme immuables avec `@entity(immutable: true)`.
   - Si des changements se produisent dans le même bloc où l'entité a été créée, alors les mappages peuvent effectuer des changements sur les entités immuables. Les entités immuables sont beaucoup plus rapides à écrire et à interroger, donc elles devraient être utilisées chaque fois que c'est possible.
 
 #### Bon exemple
 
-The following `Gravatar` entity is structured around a Gravatar object and is a good example of how an entity could be defined.
+L'entité `Gravatar` suivante est structurée autour d'un objet Gravatar et constitue un bon exemple de la manière dont une entité pourrait être définie.
 
 ```graphql
 type Gravatar @entity(immutable: true) {
@@ -36,7 +36,7 @@ type Gravatar @entity(immutable: true) {
 
 #### Mauvais exemple
 
-The following example `GravatarAccepted` and `GravatarDeclined` entities are based around events. It is not recommended to map events or function calls to entities 1:1.
+Les exemples d'entités `GravatarAccepted` et `GravatarDeclined` suivants sont basés sur des événements. Il n'est pas recommandé de mapper des événements ou des appels de fonction à des entités 1:1.
 
 ```graphql
 type GravatarAccepted @entity {
@@ -56,15 +56,15 @@ type GravatarDeclined @entity {
 
 #### Champs facultatifs et obligatoires
 
-Entity fields can be defined as required or optional. Required fields are indicated by the `!` in the schema. If the field is a scalar field, you get an error when you try to store the entity. If the field references another entity then you get this error:
+Les champs d'entité peuvent être définis comme obligatoires ou facultatifs. Les champs obligatoires sont indiqués par le `!` dans le schéma. Si le champ est un champ scalaire, vous obtenez une erreur lorsque vous essayez de stocker l'entité. Si le champ fait référence à une autre entité, vous obtenez cette erreur :
 
 ```
 Null value resolved for non-null field 'name'
 ```
 
-Each entity must have an `id` field, which must be of type `Bytes!` or `String!`. It is generally recommended to use `Bytes!`, unless the `id` contains human-readable text, since entities with `Bytes!` id's will be faster to write and query as those with a `String!` `id`. The `id` field serves as the primary key, and needs to be unique among all entities of the same type. For historical reasons, the type `ID!` is also accepted and is a synonym for `String!`.
+Chaque entité doit avoir un champ `id`, qui doit être de type `Bytes!` ou `String!`. Il est généralement recommandé d'utiliser `Bytes!`, à moins que l'`id` ne contienne du texte lisible par l'homme, car les entités avec des identifiants `Bytes!` seront plus rapides à écrire et à interroger que celles avec un `id` `String!`. Le champ `id` sert de clé primaire et doit être unique parmi toutes les entités du même type. Pour des raisons historiques, le type `ID!` est également accepté et est un synonyme de `String!`.
 
-For some entity types the `id` for `Bytes!` is constructed from the id's of two other entities; that is possible using `concat`, e.g., `let id = left.id.concat(right.id) ` to form the id from the id's of `left` and `right`. Similarly, to construct an id from the id of an existing entity and a counter `count`, `let id = left.id.concatI32(count)` can be used. The concatenation is guaranteed to produce unique id's as long as the length of `left` is the same for all such entities, for example, because `left.id` is an `Address`.
+Pour certains types d'entités, l'`id` de `Bytes!` est construit à partir des id de deux autres entités ; cela est possible en utilisant `concat`, par exemple, `let id = left.id.concat(right.id) ` pour former l'id à partir des id de `left` et `right`. De même, pour construire un identifiant à partir de l'identifiant d'une entité existante et d'un compteur `count`, `let id = left.id.concatI32(count)` peut être utilisé. La concaténation est garantie pour produire des identifiants uniques tant que la longueur de `left` est la même pour toutes ces entités, par exemple, parce que `left.id` est une `Address`.
 
 ### Types scalaires intégrés
 
@@ -72,16 +72,16 @@ For some entity types the `id` for `Bytes!` is constructed from the id's of two
 
 Les scalaires suivants sont supportés dans l'API GraphQL :
 
-| Type         | Description                                                                                                                                                                                                      |
-| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `Bytes`      | Tableau d'octets, représenté sous forme de chaîne hexadécimale. Couramment utilisé pour les hachages et adresses Ethereum.                                                                                       |
-| `String`     | Scalar for `string` values. Null characters are not supported and are automatically removed.                                                                                                                     |
-| `Boolean`    | Scalar for `boolean` values.                                                                                                                                                                                     |
-| `Int`        | The GraphQL spec defines `Int` to be a signed 32-bit integer.                                                                                                                                                    |
-| `Int8`       | An 8-byte signed integer, also known as a 64-bit signed integer, can store values in the range from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. Prefer using this to represent `i64` from ethereum. |
-| `BigInt`     | Large integers. Used for Ethereum's `uint32`, `int64`, `uint64`, ..., `uint256` types. Note: Everything below `uint32`, such as `int32`, `uint24` or `int8` is represented as `i32`.                             |
-| `BigDecimal` | `BigDecimal` High precision decimals represented as a significand and an exponent. The exponent range is from −6143 to +6144. Rounded to 34 significant digits.                                                  |
-| `Timestamp`  | It is an `i64` value in microseconds. Commonly used for `timestamp` fields for timeseries and aggregations.                                                                                                      |
+| Type         | Description                                                                                                                                                                                                                                                 |
+| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Bytes`      | Tableau d'octets, représenté sous forme de chaîne hexadécimale. Couramment utilisé pour les hachages et adresses Ethereum.                                                                                                                                  |
+| `String`     | Scalaire pour les valeurs de type `string`. Les caractères nuls ne sont pas pris en charge et sont automatiquement supprimés.                                                                                                                               |
+| `Boolean`    | Scalaire pour les valeurs de type `boolean` (booléennes).                                                                                                                                                                                                   |
+| `Int`        | La spécification GraphQL définit `Int` comme un entier signé de 32 bits.                                                                                                                                                                                    |
+| `Int8`       | Un entier signé de 8 octets, également connu sous le nom d'entier signé de 64 bits, peut stocker des valeurs comprises entre -9 223 372 036 854 775 808 et 9 223 372 036 854 775 807. Il est préférable de l'utiliser pour représenter `i64` de l'ethereum. |
+| `BigInt`     | Grands entiers. Utilisé pour les types Ethereum `uint32`, `int64`, `uint64`, ..., `uint256`. Note : Tout ce qui est inférieur à `uint32`, comme `int32`, `uint24` ou `int8` est représenté par `i32`.                                                       |
+| `BigDecimal` | `BigDecimal` Décimales de haute précision représentées par un significatif et un exposant. L'exposant est compris entre -6143 et +6144. Arrondi à 34 chiffres significatifs.                                                                                |
+| `Timestamp`  | Il s'agit d'une valeur `i64` en microsecondes. Couramment utilisé pour les champs `timestamp` des séries chronologiques et des agrégations.                                                                                                                 |
 
 ### Enums
 
@@ -95,9 +95,9 @@ enum TokenStatus {
 }
 ```
 
-Once the enum is defined in the schema, you can use the string representation of the enum value to set an enum field on an entity. For example, you can set the `tokenStatus` to `SecondOwner` by first defining your entity and subsequently setting the field with `entity.tokenStatus = "SecondOwner"`. The example below demonstrates what the Token entity would look like with an enum field:
+Une fois que l'enum est défini dans le schéma, vous pouvez utiliser la représentation en chaîne de caractère de la valeur de l'enum pour définir un champ de l'enum sur une entité. Par exemple, vous pouvez fixer le `tokenStatus` à `SecondOwner` en définissant d'abord votre entité et en fixant ensuite le champ avec `entity.tokenStatus = "SecondOwner"`. L'exemple ci-dessous montre à quoi ressemblerait l'entité Token avec un champ enum :
 
-More detail on writing enums can be found in the [GraphQL documentation](https://graphql.org/learn/schema/).
+Pour plus de détails sur l'écriture des énumérations, voir la [documentation GraphQL](https://graphql.org/learn/schema/).
 
 ### Relations entre entités
 
@@ -107,7 +107,7 @@ Les relations sont définies sur les entités comme n'importe quel autre champ s
 
 #### Relations individuelles
 
-Define a `Transaction` entity type with an optional one-to-one relationship with a `TransactionReceipt` entity type:
+Définir un type d'entité `Transaction` avec une relation optionnelle de type un-à-un avec un type d'entité `TransactionReceipt` :
 
 ```graphql
 type Transaction @entity(immutable: true) {
@@ -123,7 +123,7 @@ type TransactionReceipt @entity(immutable: true) {
 
 #### Relations un-à-plusieurs
 
-Define a `TokenBalance` entity type with a required one-to-many relationship with a Token entity type:
+Définir un type d'entité `TokenBalance` avec une relation obligatoire de type un-à-plusieurs avec un type d'entité Token :
 
 ```graphql
 type Token @entity(immutable: true) {
@@ -139,13 +139,13 @@ type TokenBalance @entity {
 
 ### Recherches inversées
 
-Reverse lookups can be defined on an entity through the `@derivedFrom` field. This creates a virtual field on the entity that may be queried but cannot be set manually through the mappings API. Rather, it is derived from the relationship defined on the other entity. For such relationships, it rarely makes sense to store both sides of the relationship, and both indexing and query performance will be better when only one side is stored and the other is derived.
+Les recherches inversées peuvent être définies sur une entité à travers le champ `@derivedFrom`. Cela crée un champ virtuel sur l'entité qui peut être interrogé mais qui ne peut pas être défini manuellement par l'intermédiaire de l'API des correspondances. Il est plutôt dérivé de la relation définie sur l'autre entité. Pour de telles relations, il est rarement utile de stocker les deux côtés de la relation, et l'indexation et les performances des requêtes seront meilleures si un seul côté est stocké et que l'autre est dérivé.
 
 Pour les relations un-à-plusieurs, la relation doit toujours être stockée du côté « un » et le côté « plusieurs » doit toujours être dérivé. Stocker la relation de cette façon, plutôt que de stocker un tableau d'entités du côté « plusieurs », entraînera des performances considérablement meilleures pour l'indexation et l'interrogation du sous-graphe. En général, le stockage de tableaux d’entités doit être évité autant que possible.
 
 #### Exemple
 
-We can make the balances for a token accessible from the token by deriving a `tokenBalances` field:
+Nous pouvons rendre les soldes d'un token accessibles à partir du token en dérivant un champ `tokenBalances` :
 
 ```graphql
 type Token @entity(immutable: true) {
@@ -166,7 +166,7 @@ Pour les relations plusieurs-à-plusieurs, telles que les utilisateurs pouvant a
 
 #### Exemple
 
-Define a reverse lookup from a `User` entity type to an `Organization` entity type. In the example below, this is achieved by looking up the `members` attribute from within the `Organization` entity. In queries, the `organizations` field on `User` will be resolved by finding all `Organization` entities that include the user's ID.
+Définir une recherche inversée d'un type d'entité `User` vers un type d'entité `Organization`. Dans l'exemple ci-dessous, ceci est réalisé en recherchant l'attribut `members` à l'intérieur de l'entité `Organization`. Dans les requêtes, le champ `organizations` de `User` sera résolu en trouvant toutes les entités `Organization` qui incluent l'ID de l'user.
 
 ```graphql
 type Organization @entity {
@@ -182,7 +182,7 @@ type User @entity {
 }
 ```
 
-A more performant way to store this relationship is through a mapping table that has one entry for each `User` / `Organization` pair with a schema like
+Une façon plus performante de stocker cette relation est d'utiliser une table de correspondance qui a une entrée pour chaque paire `User` / `Organization` avec un schéma tel que
 
 ```graphql
 type Organization @entity {
@@ -223,7 +223,7 @@ Cette manière plus élaborée de stocker des relations plusieurs-à-plusieurs e
 
 ### Ajouter des commentaires au schéma
 
-As per GraphQL spec, comments can be added above schema entity attributes using the hash symbol `#`. This is illustrated in the example below:
+Conformément à la spécification GraphQL, des commentaires peuvent être ajoutés au-dessus des attributs des entités du schéma en utilisant le symbole dièse `#`. Ceci est illustré dans l'exemple ci-dessous :
 
 ```graphql
 type MyFirstEntity @entity {
@@ -239,7 +239,7 @@ Les requêtes de recherche en texte intégral filtrent et classent les entités
 
 Une définition de requête en texte intégrale inclut le nom de la requête, le dictionnaire de langue utilisé pour traiter les champs de texte, l'algorithme de classement utilisé pour classer les résultats et les champs inclus dans la recherche. Chaque requête en texte intégral peut s'étendre sur plusieurs champs, mais tous les champs inclus doivent provenir d'un seul type d'entité.
 
-To add a fulltext query, include a `_Schema_` type with a fulltext directive in the GraphQL schema.
+Pour ajouter une requête fulltext, incluez un type `_Schema_` avec une directive fulltext dans le schéma GraphQL.
 
 ```graphql
 type _Schema_
@@ -262,7 +262,7 @@ type Band @entity {
 }
 ```
 
-The example `bandSearch` field can be used in queries to filter `Band` entities based on the text documents in the `name`, `description`, and `bio` fields. Jump to [GraphQL API - Queries](/subgraphs/querying/graphql-api/#queries) for a description of the fulltext search API and more example usage.
+Le champ d'exemple `bandSearch` peut être utilisé dans des requêtes pour filtrer les entités `Band` sur la base des documents texte dans les champs `name`, `description` et `bio`. Allez à [Requêtes - API GraphQL API ](/subgraphs/querying/graphql-api/#queries) pour une description de l'API de recherche plein texte et d'autres exemples d'utilisation.
 
 ```graphql
 query {

From c9ce8a9d63a5672937bb39634a4e7ba51bca06fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 14:38:57 -0500
Subject: [PATCH 2823/3820] New translations deleting-a-subgraph.mdx (French)

---
 .../developing/managing/deleting-a-subgraph.mdx  | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx b/website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx
index 4ccca71fd7f4..c74be2b234dd 100644
--- a/website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx
+++ b/website/pages/fr/subgraphs/developing/managing/deleting-a-subgraph.mdx
@@ -12,20 +12,20 @@ Supprimez votre subgraph en utilisant [Subgraph Studio](https://thegraph.com/stu
 
 2. Cliquez sur les trois points à droite du bouton "publier".
 
-3. Click on the option to "delete this subgraph":
+3. Cliquez sur l'option "delete this subgraph":
 
    ![Delete-subgraph](/img/Delete-subgraph.png)
 
-4. Depending on the subgraph's status, you will be prompted with various options.
+4. En fonction de l'état du subgraph, différentes options vous seront proposées.
 
-   - If the subgraph is not published, simply click “delete” and confirm.
-   - If the subgraph is published, you will need to confirm on your wallet before the subgraph can be deleted from Studio. If a subgraph is published to multiple networks, such as testnet and mainnet, additional steps may be required.
+   - Si le subgraph n'est pas publié, il suffit de cliquer sur “delete“ et de confirmer.
+   - Si le subgraph est publié, vous devrez le confirmer sur votre portefeuille avant de pouvoir le supprimer de Studio. Si un subgraph est publié sur plusieurs réseaux, tels que testnet et mainnet, des étapes supplémentaires peuvent être nécessaires.
 
-> If the owner of the subgraph has signal on it, the signaled GRT will be returned to the owner.
+> Si le propriétaire du subgraph l'a signalé, les GRT signalés seront renvoyés au propriétaire.
 
-### Important Reminders
+### Rappels importants
 
-- Once you delete a subgraph, it will **not** appear on Graph Explorer's homepage. However, users who have signaled on it will still be able to view it on their profile pages and remove their signal.
+- Une fois que vous avez supprimé un subgraph, il **n'apparaîtra plus** sur la page d'accueil de Graph Explorer. Toutefois, les utilisateurs qui ont signalé sur ce subgraph pourront toujours le voir sur leurs pages de profil et supprimer leur signal.
 - Les curateurs ne seront plus en mesure de signaler le subgraph.
 - Les Curateurs qui ont déjà signalé sur le subgraph peuvent retirer leur signal à un prix moyen par action.
-- Deleted subgraphs will show an error message.
+- Les subgraphs supprimés afficheront un message d'erreur.

From a10f87e5cab1d657d04de0770b7b46569b3c0941 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 14:38:58 -0500
Subject: [PATCH 2824/3820] New translations publishing-a-subgraph.mdx (French)

---
 .../publishing/publishing-a-subgraph.mdx      | 46 +++++++++----------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/fr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
index 25e96d09f14c..a836335a3a07 100644
--- a/website/pages/fr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
+++ b/website/pages/fr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -2,28 +2,28 @@
 title: Publication d'un subgraph sur le réseau décentralisé
 ---
 
-Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+Une fois que vous avez [déployé votre sous-graphe dans Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) et qu'il est prêt à être mis en production, vous pouvez le publier sur le réseau décentralisé.
 
 Lorsque vous publiez un subgraph sur le réseau décentralisé, vous le rendez disponible pour :
 
-- [Curators](/resources/roles/curating/) to begin curating it.
-- [Indexers](/indexing/overview/) to begin indexing it.
+- [Curateurs](/resources/roles/curating/) pour commencer la curation.
+- [Indexeurs](/indexing/overview/) pour commencer à l'indexer.
 
 <VideoEmbed youtube="satdwdbvzAQ" />
 
-Check out the list of [supported networks](/supported-networks/).
+Consultez la liste des [réseaux pris en charge](/supported-networks/).
 
 ## Publication à partir de Subgraph Studio
 
-1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
-2. Click on the **Publish** button
-3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+1. Accédez au tableau de bord de [Subgraph Studio](https://thegraph.com/studio/)
+2. Cliquez sur le bouton **Publish**
+3. Votre subgraph est désormais visible dans [Graph Explorer](https://thegraph.com/explorer/).
 
 Toutes les versions publiées d'un subgraph existant peuvent :
 
-- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+- Être publié sur Arbitrum One. [En savoir plus sur The Graph Network sur Arbitrum](/archived/arbitrum/arbitrum-faq/).
 
-- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+- Indexer les données sur n'importe lequel des [réseaux pris en charge](/supported-networks/), quel que soit le réseau sur lequel le subgraph a été publié.
 
 ### Mise à jour des métadonnées d'un subgraph publié
 
@@ -33,10 +33,10 @@ Toutes les versions publiées d'un subgraph existant peuvent :
 
 ## Publication à partir de la CLI
 
-As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+Depuis la version 0.73.0, vous pouvez également publier votre subgraph avec [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
 
 1. Ouvrez le `graph-cli`.
-2. Use the following commands: `graph codegen && graph build` then `graph publish`.
+2. Utilisez les commandes suivantes : `graph codegen && graph build` puis `graph publish`.
 3. Une fenêtre s'ouvrira, vous permettant de connecter votre portefeuille, d'ajouter des métadonnées et de déployer votre subgraph finalisé sur le réseau de votre choix.
 
 ![cli-ui](/img/cli-ui.png)
@@ -46,18 +46,18 @@ As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](
 Vous pouvez uploader votre build de subgraph sur un nœud IPFS spécifique et personnaliser davantage votre déploiement avec les options suivantes :
 
 ```
-USAGE
+UTILISATION
   $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
     <value>]
 
 FLAGS
-  -h, --help                   Show CLI help.
-  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
-  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
-  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+  -h, --help                   Affiche l'aide CLI.
+  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Charge les résultats du build sur un noeud IPFS.
+  --ipfs-hash=<value>          hash IPFS du manifeste du subgraph à déployer.
+  --protocol-network=<option>  [default: arbitrum-one] Le réseau à utiliser pour le déploiement du subgraph.
                                <options: arbitrum-one|arbitrum-sepolia>
-  --subgraph-id=<value>        Subgraph ID to publish to.
-  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+  --subgraph-id=<value>        ID du subgraph vers lequel publier.
+  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL de l'interface web que vous souhaitez utiliser pour le déploiement.
 
 ```
 
@@ -67,15 +67,15 @@ Les développeurs peuvent ajouter des signaux GRT à leurs subgraphs pour incite
 
 - Si un subgraph est éligible aux récompenses d'indexation, les Indexeurs qui fournissent une "preuve d'indexation" recevront une récompense en GRT, basée sur la quantité de GRT signalée.
 
-- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+- Vous pouvez vérifier l'éligibilité de la récompense d'indexation en fonction de l'utilisation des caractéristiques du subgraph [ici](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
 
-- Specific supported networks can be checked [here](/supported-networks/).
+- Les réseaux spécifiques pris en charge peuvent être vérifiés [ici](/supported-networks/).
 
 > Ajouter un signal à un subgraph non éligible aux récompenses n'attirera pas d'Indexeurs supplémentaires.
 >
 > Si votre subgraph est éligible aux récompenses, il est recommandé de curer votre propre subgraph avec au moins 3 000 GRT afin d'attirer des indexeurs supplémentaires pour indexer votre subgraph.
 
-The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+Le [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) assure l'indexation de tous les subgraphs. Cependant, le fait de signaler un GRT sur un subgraph particulier attirera plus d'Indexeurs vers celui-ci. Cette incitation à la création d'Indexeurs supplémentaires par le biais de la curation vise à améliorer la qualité de service pour les requêtes en réduisant la latence et en améliorant la disponibilité du réseau.
 
 Lors du signalement, les Curateurs peuvent décider de signaler une version spécifique du subgraph ou de signaler en utilisant l'auto-migration. S'ils signalent en utilisant l'auto-migration, les parts d'un Curateur seront toujours mises à jour vers la dernière version publiée par le développeur. S'ils décident de signaler une version spécifique, les parts resteront toujours sur cette version spécifique.
 
@@ -89,6 +89,6 @@ Subgraph Studio vous permet d'ajouter des signaux à votre subgraph en ajoutant
 
 Alternativement, vous pouvez ajouter des signaux GRT à un subgraph publié à partir de Graph Explorer.
 
-![Signal from Explorer](/img/signal-from-explorer.png)
+![Signal provenant de l'Explorer](/img/signal-from-explorer.png)
 
-Learn more about [Curating](/resources/roles/curating/) on The Graph Network.
+En savoir plus sur [La Curation] (/resources/roles/curating/) sur The Graph Network.

From 127dcad0e0af5ee6e40a5c61a6da8278f3bfc657 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 14:38:59 -0500
Subject: [PATCH 2825/3820] New translations subgraphs.mdx (French)

---
 .../fr/subgraphs/developing/subgraphs.mdx     | 42 +++++++++----------
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/subgraphs.mdx b/website/pages/fr/subgraphs/developing/subgraphs.mdx
index f979420b2d4a..d042af3b7930 100644
--- a/website/pages/fr/subgraphs/developing/subgraphs.mdx
+++ b/website/pages/fr/subgraphs/developing/subgraphs.mdx
@@ -2,17 +2,17 @@
 title: Subgraphs
 ---
 
-## What is a Subgraph?
+## Qu'est-ce qu'un subgraph ?
 
-A subgraph is a custom, open API that extracts data from a blockchain, processes it, and stores it so it can be easily queried via GraphQL.
+Un subgraph est une API ouverte et personnalisée qui extrait des données d'une blockchain, les traite et les stocke de manière à ce qu'elles puissent être facilement interrogées via GraphQL.
 
 ### Capacités des subgraphs
 
-- **Access Data:** Subgraphs enable the querying and indexing of blockchain data for web3.
-- **Build:** Developers can build, deploy, and publish subgraphs to The Graph Network. To get started, check out the subgraph developer [Quick Start](quick-start/).
-- **Index & Query:** Once a subgraph is indexed, anyone can query it. Explore and query all subgraphs published to the network in [Graph Explorer](https://thegraph.com/explorer).
+- **Accès aux données:** Les subgraphs permettent d'interroger et d'indexer les données de la blockchain pour le web3.
+- \*\*Les développeurs peuvent créer, déployer et publier des subgraphs sur The Graph Network. Pour commencer, consultez le [Démarrage Rapide](quick-start/) du développeur de subgraphs.
+- **Indexation et interrogation:** Une fois qu'un subgraph est indexé, tout le monde peut l'interroger. Explorez et interrogez tous les subgraphs publiés sur le réseau dans [Graph Explorer](https://thegraph.com/explorer).
 
-## Inside a Subgraph
+## À l'intérieur d'un subgraph
 
 Le manifeste du subgraph, `subgraph.yaml`, définit les contrats intelligents et le réseau que votre subgraph va indexer, les événements de ces contrats auxquels il faut prêter attention, et comment faire correspondre les données d'événements aux entités que Graph Node stocke et permet d'interroger.
 
@@ -22,34 +22,34 @@ La **définition du subgraph** se compose des fichiers suivants :
 
 - `schema.graphql` : Un schéma GraphQL définissant les données stockées pour votre subgraph et comment les interroger via GraphQL
 
-- `mapping.ts`: [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code that translates event data into entities defined in your schema
+- `mapping.ts` : [AssemblyScript Mappings](https://github.com/AssemblyScript/assemblyscript) code qui traduit les données d'événements en entités définies dans votre schéma
 
-To learn more about each subgraph component, check out [creating a subgraph](/developing/creating-a-subgraph/).
+Pour en savoir plus sur chaque composant d'un subgraph, consultez [créer un subgraph](/developing/creating-a-subgraph/).
 
 ## Flux du cycle de vie des subgraphes
 
 Voici un aperçu général du cycle de vie d'un subgraph :
 
-![Subgraph Lifecycle](/img/subgraph-lifecycle.png)
+![Cycle de vie d'un Subgraph](/img/subgraph-lifecycle.png)
 
-## Subgraph Development
+## Développement de subgraphs
 
-1. [Create a subgraph](/developing/creating-a-subgraph/)
-2. [Deploy a subgraph](/deploying/deploying-a-subgraph-to-studio/)
-3. [Test a subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
-4. [Publish a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
-5. [Signal on a subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
+1. [Créer un subgraph](/developing/creating-a-subgraph/)
+2. [Déployer un subgraph](/deploying/deploying-a-subgraph-to-studio/)
+3. [Tester un subgraph](/deploying/subgraph-studio/#testing-your-subgraph-in-subgraph-studio)
+4. [Publier un subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/)
+5. [Signaler sur un subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/#adding-signal-to-your-subgraph)
 
-### Build locally
+### Développement en local
 
-Great subgraphs start with a local development environment and unit tests. Developers use [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), a command-line interface tool for building and deploying subgraphs on The Graph. They can also use [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) and [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) to create robust subgraphs.
+Les meilleurs subgraphs commencent par un environnement de développement local et des tests unitaires. Les développeurs utilisent [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), un outil d'interface de ligne de commande pour construire et déployer des subgraphs sur The Graph. Ils peuvent également utiliser [Graph TypeScript](/subgraphs/developing/creating/graph-ts/README/) et [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) pour créer des subgraphs robustes.
 
-### Deploy to Subgraph Studio
+### Déployer sur Subgraph Studio
 
-Once defined, a subgraph can be [deployed to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). In Subgraph Studio, you can do the following:
+Une fois défini, un subgraph peut être [déployé dans Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/). Dans Subgraph Studio, vous pouvez effectuer les opérations suivantes :
 
-- Use its staging environment to index the deployed subgraph and make it available for review.
-- Verify that your subgraph doesn't have any indexing errors and works as expected.
+- Utiliser son environnement de test pour indexer le subgraph déployé et le mettre à disposition pour évaluation.
+- Vérifiez que votre subgraph ne présente aucune erreur d'indexation et qu'il fonctionne comme prévu.
 
 ### Publier sur le réseau
 

From 1a1cb31ca70c7583e75fe32384011b9ae32166ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 18:14:27 -0500
Subject: [PATCH 2826/3820] New translations advanced.mdx (French)

---
 .../developing/creating/advanced.mdx          | 50 +++++++++----------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/advanced.mdx b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
index f45731b2168d..4b61a7512866 100644
--- a/website/pages/fr/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
@@ -4,17 +4,17 @@ title: Fonctionnalités avancées des subgraphs
 
 ## Aperçu
 
-Add and implement advanced subgraph features to enhanced your subgraph's built.
+Ajoutez et implémentez des fonctionnalités avancées de subgraph pour améliorer la construction de votre subgraph.
 
-Starting from `specVersion` `0.0.4`, subgraph features must be explicitly declared in the `features` section at the top level of the manifest file, using their `camelCase` name, as listed in the table below:
+À partir de `specVersion` `0.0.4`, les fonctionnalités de subgraph doivent être explicitement déclarées dans la section `features` au niveau supérieur du fichier de manifeste, en utilisant leur nom en `camelCase` comme indiqué dans le tableau ci-dessous :
 
-| Feature                                              | Name             |
-| ---------------------------------------------------- | ---------------- |
-| [Non-fatal errors](#non-fatal-errors)                | `nonFatalErrors` |
-| [Full-text Search](#defining-fulltext-search-fields) | `fullTextSearch` |
-| [Grafting](#grafting-onto-existing-subgraphs)        | `grafting`       |
+| Fonctionnalité                                              | Nom              |
+| ----------------------------------------------------------- | ---------------- |
+| [Erreurs non fatales](#non-fatal-errors)                    | `nonFatalErrors` |
+| [Recherche plein texte](#defining-fulltext-search-fields)   | `fullTextSearch` |
+| [Greffage](#grafting-onto-existing-subgraphs)               | `grafting`       |
 
-For instance, if a subgraph uses the **Full-Text Search** and the **Non-fatal Errors** features, the `features` field in the manifest should be:
+Par exemple, si un subgraph utilise les fonctionnalités **Full-Text Search** et **Non-fatal Errors**, le champ `features` dans le manifeste devrait être :
 
 ```yaml
 specVersion: 0.0.4
@@ -25,7 +25,7 @@ features:
 dataSources: ...
 ```
 
-> Note that using a feature without declaring it will incur a **validation error** during subgraph deployment, but no errors will occur if a feature is declared but not used.
+> Notez que L'utilisation d'une fonctionnalité sans la déclarer entraînera une **validation error** lors du déploiement du subgraph, mais aucune erreur ne se produira si une fonctionnalité est déclarée mais non utilisée.
 
 ## Séries chronologiques et agrégations
 
@@ -51,22 +51,22 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 
 ### Définition des Séries Chronologiques et des Agrégations
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+Les entités de séries chronologiques sont définies avec `@entity(timeseries: true)` dans schema.graphql. Chaque entité de série chronologique doit avoir un ID unique de type int8, une timestamp de type Timestamp et inclure des données qui seront utilisées pour le calcul par des entités d'agrégation. Ces entités de séries chronologique peuvent être enregistrées dans des gestionnaires triggers habituels et agissent comme les "données brutes" pour les entités d'agrégation.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Les entités d'agrégation sont définies avec `@aggregation` dans schema.graphql. Chaque entité d'agrégation définit la source à partir de laquelle elle collectera des données (qui doit être une entité de série chronologique ), définit les intervalles (par exemple, heure, jour) et spécifie la fonction d'agrégation qu'elle utilisera (par exemple, somme, compte, min, max, premier, dernier). Les entités d'agrégation sont automatiquement calculées sur la base de la source spécifiée à la fin de l'intervalle requis.
 
 #### Intervalles d'Agrégation disponibles
 
-- `hour`: sets the timeseries period every hour, on the hour.
-- `day`: sets the timeseries period every day, starting and ending at 00:00.
+- `hour`: définit la période de séries chronologiques toutes les heures, à l'heure pile.
+- `day`: définit la période de séries chronologiques chaque jour, commençant et se terminant à 00:00.
 
 #### Fonctions d'Agrégation disponibles
 
-- `sum`: Total of all values.
-- `count`: Number of values.
-- `min`: Minimum value.
-- `max`: Maximum value.
-- `first`: First value in the period.
+- `sum`: Total de toutes les valeurs.
+- `count`: Nombre de valeurs.
+- `min`: Valeur minimum.
+- `max`: Valeur maximum.
+- `first`: Première valeur de la période.
 - `last` : Dernière valeur de la période.
 
 #### Exemple de requête d'Agrégations
@@ -85,13 +85,13 @@ Remarque:
 
 Pour utiliser les Séries Chronologiques et les Agrégations, un subgraph doit avoir une spec Version ≥1.1.0. Notez que cette fonctionnalité pourrait subir des changements significatifs affectant la compatibilité rétroactive.
 
-[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+[En savoir plus](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) sur les séries chronologiques et Agrégations.
 
 ## Erreurs non fatales
 
 Les erreurs d'indexation sur les subgraphs déjà synchronisés entraîneront, par défaut, l'échec du subgraph et l'arrêt de la synchronisation. Les subgraphs peuvent également être configurés pour continuer la synchronisation en présence d'erreurs, en ignorant les modifications apportées par le gestionnaire qui a provoqué l'erreur. Cela donne aux auteurs de subgraphs le temps de corriger leurs subgraphs pendant que les requêtes continuent d'être traitées sur le dernier bloc, bien que les résultats puissent être incohérents en raison du bogue à l'origine de l'erreur. Notez que certaines erreurs sont toujours fatales. Pour être non fatale, l'erreur doit être connue pour être déterministe.
 
-> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+> **Note:** The Graph Network ne supporte pas encore les erreurs non fatales, et les développeurs ne doivent pas déployer de subgraphs utilisant cette fonctionnalité sur le réseau via le Studio.
 
 L'activation des erreurs non fatales nécessite la définition de l'indicateur de fonctionnalité suivant sur le manifeste du subgraph :
 
@@ -103,7 +103,7 @@ features:
     ...
 ```
 
-The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+La requête doit également opter pour l'interrogation de données avec des incohérences potentielles via l'argument `subgraphError`. Il est également recommandé d'interroger `_meta` pour vérifier si le subgraph a ignoré des erreurs, comme dans l'exemple :
 
 ```graphql
 foos(first: 100, subgraphError: allow) {
@@ -115,7 +115,7 @@ _meta {
 }
 ```
 
-If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+Si le subgraph rencontre une erreur, cette requête renverra à la fois les données et une erreur graphql avec le message `"indexing_error"`, comme dans cet exemple de réponse :
 
 ```graphql
 "data": {
@@ -145,7 +145,7 @@ Les sources de données de fichiers sont une nouvelle fonctionnalité de subgrap
 
 Plutôt que de récupérer les fichiers "ligne par ligne" pendant l'exécution du gestionnaire, ceci introduit des modèles qui peuvent être générés comme nouvelles sources de données pour un identifiant de fichier donné. Ces nouvelles sources de données récupèrent les fichiers, réessayant en cas d'échec, et exécutant un gestionnaire dédié lorsque le fichier est trouvé.
 
-This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+Cela est similaire aux [modèles de source de données existants](/developing/creating-a-subgraph/#data-source-templates), qui sont utilisés pour créer dynamiquement de nouvelles sources de données basées sur la blockchain.
 
 > Cela remplace l'API `ipfs.cat` existante
 
@@ -538,7 +538,7 @@ graft:
   block: 7345624 # Block number
 ```
 
-When a subgraph whose manifest contains a `graft` block is deployed, Graph Node will copy the data of the `base` subgraph up to and including the given `block` and then continue indexing the new subgraph from that block on. The base subgraph must exist on the target Graph Node instance and must have indexed up to at least the given block. Because of this restriction, grafting should only be used during development or during an emergency to speed up producing an equivalent non-grafted subgraph.
+Lorsqu'un subgraph dont le manifeste contient un bloc `graft` est déployé, Graph Node copiera les données du subgraph `de base` jusqu'au bloc spécifié inclus, puis continuera à indexer le nouveau subgraph à partir de ce bloc. Le subgraph de base doit exister sur l'instance cible de Graph Node et doit avoir indexé au moins jusqu'au bloc spécifié. En raison de cette restriction, le greffage ne doit être utilisé que pendant le développement ou en cas d'urgence pour accélérer la production d'un subgraph équivalent non greffé.
 
 Étant donné que le greffage copie plutôt que l'indexation des données de base, il est beaucoup plus rapide d'amener le susgraph dans le bloc souhaité que l'indexation à partir de zéro, bien que la copie initiale des données puisse encore prendre plusieurs heures pour de très gros subgraphs. Pendant l'initialisation du subgraph greffé, le nœud graphique enregistrera des informations sur les types d'entités qui ont déjà été copiés.
 
@@ -552,4 +552,4 @@ Le subgraph greffé peut utiliser un schema GraphQL qui n'est pas identique à c
 - Il ajoute ou supprime des interfaces
 - Cela change pour quels types d'entités une interface est implémentée
 
-> **[Feature Management](#experimental-features):** `grafting` must be declared under `features` in the subgraph manifest.
+> **[Gestion des fonctionnalités](#experimental-features):** `grafting` doit être déclaré sous `features` dans le manifeste du subgraph.

From f74b2b6735c054bb74ada348dace7770783185ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 18:14:28 -0500
Subject: [PATCH 2827/3820] New translations unit-testing-framework.mdx
 (French)

---
 .../creating/unit-testing-framework.mdx       | 26 +++++++++----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
index 14af32b2a5c5..b0fe6e44289f 100644
--- a/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -4,30 +4,30 @@ title: Cadre pour les tests unitaires
 
 Apprenez à utiliser Matchstick, un framework de test unitaire développé par [LimeChain](https://limechain.tech/). Matchstick permet aux développeurs de subgraphs de tester leur logique de mappages dans un environnement sandbox et de déployer avec succès leurs subgraphs.
 
-## Benefits of Using Matchstick
+## Avantages de l'utilisation de Matchstick
 
-- It's written in Rust and optimized for high performance.
-- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+- Il est écrit en Rust et optimisé pour des hautes performances.
+- Il vous donne accès à des fonctionnalités pour développeurs, y compris la possibilité de simuler des appels de contrat, de faire des assertions sur l'état du store, de surveiller les échecs de subgraph, de vérifier les performances des tests, et bien plus encore.
 
 ## Introduction
 
-### Install Dependencies
+### Installation des dépendances
 
-In order to use the test helper methods and run tests, you need to install the following dependencies:
+Pour utiliser les méthodes d'aide aux tests et exécuter les tests, vous devez installer les dépendances suivantes :
 
 ```sh
 yarn add --dev matchstick-as
 ```
 
-### Install PostgreSQL
+### Installer PostgreSQL
 
 `graph-node` dépend de PostgreSQL, donc si vous ne l'avez pas déjà, vous devrez l'installer.
 
-> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+> Remarque : Il est fortement recommandé d'utiliser les commandes ci-dessous pour éviter les erreurs inattendues.
 
-#### Using MacOS
+#### En utilisant MacOS
 
-Installation command:
+Commande d'installation :
 
 ```sh
 brew install postgresql
@@ -39,15 +39,15 @@ Créez un lien symbolique vers la dernière version de libpq.5.lib _Vous devrez
 ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
 ```
 
-#### Using Linux
+#### En utilisant Linux
 
-Installation command (depends on your distro):
+Commande d'installation (dépend de votre distribution) :
 
 ```sh
 sudo apt installer postgresql
 ```
 
-### Using WSL (Windows Subsystem for Linux)
+### En utilisant WSL (Windows Subsystem for Linux)
 
 Vous pouvez utiliser Matchstick sur WSL en utilisant à la fois l'approche Docker et l'approche binaire. Comme WSL peut être un peu délicat, voici quelques conseils au cas où vous rencontreriez des problèmes tels que
 
@@ -85,7 +85,7 @@ Et enfin, n'utilisez pas `graph test` (qui utilise votre installation globale de
 }
 ```
 
-### Using Matchstick
+### En utilisant Matchstick
 
 Pour utiliser **Matchstick** dans votre projet de ssubgraph, ouvrez un terminal, naviguez jusqu'au dossier racine de votre projet et exécutez simplement `graph test [options] <datasource>` - il télécharge le dernier binaire **Matchstick** et exécute le test spécifié ou tous les tests dans un dossier de test (ou tous les tests existants si aucun flag de source de données n'est spécifié).
 

From 55aff8d2a410ffd605284d123056d9699c5a3795 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 18:14:30 -0500
Subject: [PATCH 2828/3820] New translations api.mdx (French)

---
 website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx b/website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx
index d25de3e931a5..d784114e01cc 100644
--- a/website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/graph-ts/api.mdx
@@ -280,7 +280,7 @@ Comme l'entité peut ne pas encore exister dans le magasin, la méthode `load` r
 
 Depuis `graph-node` v0.31.0, `@graphprotocol/graph-ts` v0.30.0 et `@graphprotocol/graph-cli` v0.49.0 la méthode `loadInBlock` est disponible pour tous les types d'entités.
 
-The store API facilitates the retrieval of entities that were created or updated in the current block. A typical situation for this is that one handler creates a transaction from some onchain event, and a later handler wants to access this transaction if it exists.
+L'API de store facilite la récupération des entités créées ou mises à jour dans le bloc actuel. Une situation typique pour cela est qu'un gestionnaire crée une transaction à partir d'un événement onchain et qu'un gestionnaire ultérieur souhaite accéder à cette transaction si elle existe.
 
 - Dans le cas où la transaction n'existe pas, le subgraph devra interroger la base de données pour découvrir que l'entité n'existe pas. Si l'auteur du subgraph sait déjà que l'entité doit avoir été créée dans le même bloc, utiliser `loadInBlock` évite ce détour par la base de données.
 - Pour certains subgraphs, ces recherches infructueuses peuvent contribuer de manière significative au temps d'indexation.

From 58534fa96487474a78c057e0ae0a8ce52491230e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 18:14:31 -0500
Subject: [PATCH 2829/3820] New translations assemblyscript-mappings.mdx
 (French)

---
 .../developing/creating/assemblyscript-mappings.mdx    | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx
index 8d8b02c138e4..7bb87fa69ab6 100644
--- a/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -1,16 +1,16 @@
 ---
-title: Writing AssemblyScript Mappings
+title: Écrire des mappages en AssemblyScript
 ---
 
 ## Aperçu
 
-The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
+Les mappages prennent des données d'une source particulière et les transforment en entités définies dans votre schéma. Les mappages sont écrits dans un sous-ensemble de [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) appelé [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) qui peut être compilé en WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript est plus strict que le TypeScript normal, tout en offrant une syntaxe familière.
 
 ## Écriture de mappages
 
-For each event handler that is defined in `subgraph.yaml` under `mapping.eventHandlers`, create an exported function of the same name. Each handler must accept a single parameter called `event` with a type corresponding to the name of the event which is being handled.
+Pour chaque gestionnaire d'événements défini dans `subgraph.yaml` sous `mapping.eventHandlers`, créez une fonction exportée du même nom. Chaque gestionnaire doit accepter un seul paramètre appelé `event` avec un type correspondant au nom de l'événement traité.
 
-In the example subgraph, `src/mapping.ts` contains handlers for the `NewGravatar` and `UpdatedGravatar` events:
+Dans le subgraph d'exemple, `src/mapping.ts` contient des gestionnaires pour les événements `NewGravatar` et `UpdatedGravatar`:
 
 ```javascript
 import { NewGravatar, UpdatedGravatar } from '../generated/Gravity/Gravity'
@@ -37,7 +37,7 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void {
 }
 ```
 
-The first handler takes a `NewGravatar` event and creates a new `Gravatar` entity with `new Gravatar(event.params.id.toHex())`, populating the entity fields using the corresponding event parameters. This entity instance is represented by the variable `gravatar`, with an id value of `event.params.id.toHex()`.
+Le premier gestionnaire prend un événement `NewGravatar` et crée une nouvelle entité Gravatar avec `new Gravatar(event.params.id.toHex())`, en remplissant les champs de l'entité à l'aide des paramètres de l'événement correspondant. Cette instance d'entité est représentée par la variable `gravatar`, avec une valeur d'id de `event.params.id.toHex()`.
 
 Le deuxième gestionnaire tente de charger le `Gravatar` existant à partir du store Graph Node. S'il n'existe pas encore, il est créé à la demande. L'entité est ensuite mise à jour pour correspondre aux nouveaux paramètres de l'événement avant d'être sauvegardée dans le store à l'aide de `gravatar.save()`.
 

From 730a634a41915433746278393e546614e0514911 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 18:14:32 -0500
Subject: [PATCH 2830/3820] New translations using-subgraph-studio.mdx (French)

---
 .../fr/subgraphs/developing/deploying/using-subgraph-studio.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx
index 7f70f9772371..a9bf86bf974a 100644
--- a/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx
+++ b/website/pages/fr/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -63,7 +63,7 @@ Pour être pris en charge par les Indexeurs sur The Graph Network, les subgraphs
 - Ne doit utiliser aucune des fonctionnalités suivantes :
   - ipfs.cat & ipfs.map
   - Erreurs non fatales
-  - Grafting
+  - La greffe
 
 ## Initialisez votre Subgraph
 

From e7b3422c91dcc2a43decbb5bac28dcbda9a994b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 23 Jan 2025 18:14:33 -0500
Subject: [PATCH 2831/3820] New translations sps-faq.mdx (French)

---
 website/pages/fr/substreams/sps/sps-faq.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/substreams/sps/sps-faq.mdx b/website/pages/fr/substreams/sps/sps-faq.mdx
index 2c25f5608eb4..bde4d95432b9 100644
--- a/website/pages/fr/substreams/sps/sps-faq.mdx
+++ b/website/pages/fr/substreams/sps/sps-faq.mdx
@@ -16,9 +16,9 @@ Si vous êtes déjà familiarisé avec le développement de subgraphs, notez que
 
 ## En quoi les subgraphs alimentés par les courants secondaires sont-ils différents des subgraphs ?
 
-Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+Les subgraphs sont constitués de sources de données qui spécifient des événements onchain et comment ces événements doivent être transformés via des gestionnaires écrits en Assemblyscript. Ces événements sont traités de manière séquentielle, en fonction de l'ordre dans lequel ils se produisent onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+En revanche, les subgraphs alimentés par des substreams ont une seule source de données qui référence un package de substreams, qui est traité par Graph Node. Les substreams ont accès à des données onchain supplémentaires granulaires par rapport aux subgraphs conventionnels et peuvent également bénéficier d'un traitement massivement parallélisé, ce qui peut signifier des temps de traitement beaucoup plus rapides.
 
 ## Quels sont les avantages de l'utilisation de subgraphs alimentés par des courants descendants ?
 

From 181c4fab1cd19e2ef68a3ed74d6acb22a01a95e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 01:29:34 -0500
Subject: [PATCH 2832/3820] New translations sps-faq.mdx (Chinese Simplified)

---
 website/pages/zh/substreams/sps/sps-faq.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/substreams/sps/sps-faq.mdx b/website/pages/zh/substreams/sps/sps-faq.mdx
index 9b8f6b2dd205..1534ccdd2f75 100644
--- a/website/pages/zh/substreams/sps/sps-faq.mdx
+++ b/website/pages/zh/substreams/sps/sps-faq.mdx
@@ -16,7 +16,7 @@ Go to the [Substreams Documentation](/substreams/introduction/) to learn more ab
 
 ## 基于Substreams的子图和普通子图有什么区别？
 
-Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+子图由数据源组成，这些数据源指定了在链上发生的事件以及通过用Assemblyscript编写的处理程序应如何转换这些事件。这些事件按照链上发生事件的顺序依次进行处理。
 
 By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
 

From db2ec9af4762704a4096277272f5783776680ece Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 09:54:57 -0500
Subject: [PATCH 2833/3820] New translations sunrise.mdx (German)

---
 website/pages/de/archived/sunrise.mdx | 36 +++++++++++++--------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/website/pages/de/archived/sunrise.mdx b/website/pages/de/archived/sunrise.mdx
index 0c8253ba2b2c..f719c58dd813 100644
--- a/website/pages/de/archived/sunrise.mdx
+++ b/website/pages/de/archived/sunrise.mdx
@@ -42,38 +42,38 @@ Edge & Node haben in der Vergangenheit den gehosteten Dienst gewartet und verfü
 
 ### Was bedeutet der Upgrade Indexer für bestehende Indexer?
 
-Chains previously only supported on the hosted service were made available to developers on The Graph Network without indexing rewards at first.
+Ketten, die bisher nur vom gehosteten Dienst unterstützt wurden, wurden den Entwicklern auf The Graph Network zunächst ohne Rewards zur Verfügung gestellt.
 
-However, this action unlocked query fees for any interested Indexer and increased the number of subgraphs published on The Graph Network. As a result, Indexers have more opportunities to index and serve these subgraphs in exchange for query fees, even before indexing rewards are enabled for a chain.
+Durch diese Aktion wurden jedoch Abfragegebühren für jeden interessierten Indexer freigeschaltet und die Anzahl der im Graph Network veröffentlichten Subgraphen erhöht. Infolgedessen haben Indexer mehr Möglichkeiten, diese Subgraphen im Austausch gegen Abfragegebühren zu indizieren und zu bedienen, noch bevor Indexing Rewards für eine Kette aktiviert sind.
 
-The upgrade Indexer also provides the Indexer community with information about the potential demand for subgraphs and new chains on The Graph Network.
+Der Upgrade-Indexer versorgt die Indexer-Community auch mit Informationen über die potenzielle Nachfrage nach Subgraphen und neuen Ketten im The Graph Network.
 
-### What does this mean for Delegators?
+### Was bedeutet das für die Delegatoren?
 
-The upgrade Indexer offers a powerful opportunity for Delegators. As it allowed more subgraphs to be upgraded from the hosted service to The Graph Network, Delegators benefit from the increased network activity.
+Der Upgrade-Indexer bietet eine große Chance für Delegatoren. Da mehr Subgraphen vom gehosteten Dienst auf The Graph Network umgestellt werden können, profitieren die Delegatoren von der erhöhten Netzwerkaktivität.
 
-### Did the upgrade Indexer compete with existing Indexers for rewards?
+### Konkurriert der aktualisierte Indexer mit bestehenden Indexern um Rewards?
 
-No, the upgrade Indexer only allocates the minimum amount per subgraph and does not collect indexing rewards.
+Nein, der Upgrade-Indexer weist nur den Mindestbetrag pro Subgraph zu und sammelt keine Rewards für die Indizierung.
 
-It operates on an “as needed” basis, serving as a fallback until sufficient service quality is achieved by at least three other Indexers in the network for respective chains and subgraphs.
+Er arbeitet "nach Bedarf" und dient als Ausweichlösung, bis mindestens drei andere Indexer im Netz für die jeweiligen Ketten und Subgraphen eine ausreichende Dienstqualität erreicht haben.
 
-### How does this affect subgraph developers?
+### Wie wirkt sich das für die Entwickler von Subgraphen aus?
 
-Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+Entwickler von Subgraphen können ihre Subgraphen auf The Graph Network fast sofort nach dem Upgrade vom gehosteten Dienst oder nach dem [Veröffentlichen aus Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/) abfragen, da keine Vorlaufzeit für die Indizierung erforderlich war. Bitte beachten Sie, dass das [Erstellen eines Subgraphen](/developing/creating-a-subgraph/) von diesem Upgrade nicht betroffen ist.
 
-### How does the upgrade Indexer benefit data consumers?
+### Welchen Nutzen hat der Upgrade-Indexer für die Datenkonsumenten?
 
-The upgrade Indexer enables chains on the network that were previously only supported on the hosted service. Therefore, it widens the scope and availability of data that can be queried on the network.
+Der Upgrade-Indexer ermöglicht Verkettungen im Netz, die bisher nur vom gehosteten Dienst unterstützt wurden. Daher erweitert er den Umfang und die Verfügbarkeit von Daten, die im Netzwerk abgefragt werden können.
 
-### How does the upgrade Indexer price queries?
+### Wie bewertet der Upgrade-Indexer Abfragen?
 
-The upgrade Indexer prices queries at the market rate to avoid influencing the query fee market.
+Der Upgrade-Indexer berechnet Abfragen zum Marktpreis, um den Markt für Abfragegebühren nicht zu beeinflussen.
 
-### When will the upgrade Indexer stop supporting a subgraph?
+### Wann wird der Upgrade-Indexer aufhören, einen Subgraphen zu unterstützen?
 
-The upgrade Indexer supports a subgraph until at least 3 other Indexers successfully and consistently serve queries made to it.
+Der Upgrade-Indexer unterstützt einen Subgraphen so lange, bis mindestens 3 andere Indexer erfolgreich und konsistent die an ihn gerichteten Abfragen bedienen.
 
-Furthermore, the upgrade Indexer stops supporting a subgraph if it has not been queried in the last 30 days.
+Außerdem unterstützt der Upgrade-Indexer einen Subgraphen nicht mehr, wenn er in den letzten 30 Tagen nicht abgefragt wurde.
 
-Other Indexers are incentivized to support subgraphs with ongoing query volume. The query volume to the upgrade Indexer should trend towards zero, as it has a small allocation size, and other Indexers should be chosen for queries ahead of it.
+Für andere Indexer besteht ein Anreiz, Subgraphen mit laufendem Abfragevolumen zu unterstützen. Das Anfragevolumen an den Upgrade-Indexer sollte gegen Null tendieren, da er eine kleine Zuweisungsgröße hat, und andere Indexer sollten für Anfragen vor ihm ausgewählt werden.

From 338682481ce3d8a2884de42842238d92d6326cff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 09:54:58 -0500
Subject: [PATCH 2834/3820] New translations contracts.mdx (German)

---
 website/pages/de/contracts.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/de/contracts.mdx b/website/pages/de/contracts.mdx
index d2255f3af336..64dbf977ff29 100644
--- a/website/pages/de/contracts.mdx
+++ b/website/pages/de/contracts.mdx
@@ -1,26 +1,26 @@
 ---
-title: Protocol Contracts
+title: Protokoll-Verträge
 ---
 
 import { ProtocolContractsTable } from '@/src/contracts'
 
-Below are the deployed contracts which power The Graph Network. Visit the official [contracts repository](https://github.com/graphprotocol/contracts) to learn more.
+Nachstehend finden Sie die bereitgestellten Verträge, die das The Graph Network antreiben. Besuchen Sie das offizielle [Vertragsrepository] (https://github.com/graphprotocol/contracts), um mehr zu erfahren.
 
 ## Arbitrum
 
-This is the principal deployment of The Graph Network.
+Dies ist der Haupteinsatzbereich von The Graph Network.
 
 <ProtocolContractsTable networkId={42161} />
 
 ## Mainnet
 
-This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+Dies war die ursprüngliche Bereitstellung von The Graph Network. [Erfahren Sie mehr](/archived/arbitrum/arbitrum-faq/) über die Skalierung von The Graph mit Arbitrum.
 
 <ProtocolContractsTable networkId={1} />
 
 ## Arbitrum Sepolia
 
-This is the primary testnet for The Graph Network. Testnet is predominantly used by core developers and ecosystem participants for testing purposes. There are no guarantees of service or availability on The Graph's testnets.
+Dies ist das primäre Testnetz für The Graph Network. Das Testnet wird vor allem von Kernentwicklern und Teilnehmern des Ökosystems zu Testzwecken genutzt. Es gibt keine Garantien für den Service oder die Verfügbarkeit der Testnetze von The Graph.
 
 <ProtocolContractsTable networkId={421614} />
 

From fcb7d55723ee36905070a5fcd229fe4f9ea8e8ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 09:54:59 -0500
Subject: [PATCH 2835/3820] New translations subgraph-studio-faq.mdx (German)

---
 .../subgraphs/developing/deploying/subgraph-studio-faq.mdx  | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx
index 7006d1662338..ff4518a02b9a 100644
--- a/website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx
+++ b/website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -4,15 +4,15 @@ title: Subgraph Studio-FAQs
 
 ## 1. Was ist Subgraph Studio?
 
-[Subgraph Studio](https://thegraph.com/studio/) is a dapp for creating, managing, and publishing subgraphs and API keys.
+[Subgraph Studio] (https://thegraph.com/studio/) ist eine App zur Erstellung, Verwaltung und Veröffentlichung von Subgraphen und API-Schlüsseln.
 
 ## 2. Wie erstelle ich einen API-Schlüssel?
 
-To create an API, navigate to Subgraph Studio and connect your wallet. You will be able to click the API keys tab at the top. There, you will be able to create an API key.
+Um eine API zu erstellen, navigieren Sie zu Subgraph Studio und verbinden Sie Ihre Wallet. Oben können Sie auf die Registerkarte API-Schlüssel klicken. Dort können Sie einen API-Schlüssel erstellen.
 
 ## 3. Kann ich mehrere API-Schlüssel erstellen?
 
-Yes! You can create multiple API Keys to use in different projects. Check out the link [here](https://thegraph.com/studio/apikeys/).
+Ja! Sie können mehrere API-Schlüssel zur Verwendung in verschiedenen Projekten erstellen. Sehen Sie sich den Link [hier] an (https://thegraph.com/studio/apikeys/).
 
 ## 4. How do I restrict a domain for an API Key?
 

From 49fa329349fd8c17fb29ec3d806fc1e068fd8250 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 09:55:01 -0500
Subject: [PATCH 2836/3820] New translations sps-faq.mdx (Chinese Simplified)

---
 website/pages/zh/substreams/sps/sps-faq.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/substreams/sps/sps-faq.mdx b/website/pages/zh/substreams/sps/sps-faq.mdx
index 1534ccdd2f75..2bd25ccf9991 100644
--- a/website/pages/zh/substreams/sps/sps-faq.mdx
+++ b/website/pages/zh/substreams/sps/sps-faq.mdx
@@ -62,7 +62,7 @@ Firehose是由[StreamingFast](https://www.streamingfast.io/)开发的区块链
 
 ## 开发人员在哪里可以获得关于Substreams-powered子图和Substreams的更多信息？
 
-The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+[Substreams文档](/substreams/introduction/)将教您如何构建Substreams模块。
 
 The [Substreams-powered subgraphs documentation](/subgraphs/cookbook/substreams-powered-subgraphs/) will show you how to package them for deployment on The Graph.
 

From e81c955d382408c640edcf4a60f4c7987db64ea1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 11:17:44 -0500
Subject: [PATCH 2837/3820] New translations subgraph-studio-faq.mdx (German)

---
 .../developing/deploying/subgraph-studio-faq.mdx          | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx b/website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx
index ff4518a02b9a..4acae90a1f10 100644
--- a/website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx
+++ b/website/pages/de/subgraphs/developing/deploying/subgraph-studio-faq.mdx
@@ -14,18 +14,18 @@ Um eine API zu erstellen, navigieren Sie zu Subgraph Studio und verbinden Sie Ih
 
 Ja! Sie können mehrere API-Schlüssel zur Verwendung in verschiedenen Projekten erstellen. Sehen Sie sich den Link [hier] an (https://thegraph.com/studio/apikeys/).
 
-## 4. How do I restrict a domain for an API Key?
+## 4. Wie beschränke ich einen API Key auf eine Domain ein?
 
 Nachdem Sie einen API-Schlüssel erstellt haben, können Sie im Abschnitt Sicherheit die Domänen definieren, die einen bestimmten API-Schlüssel abfragen können.
 
 ## 5. Kann ich meinen Subgrafen an einen anderen Eigentümer übertragen?
 
-Yes, subgraphs that have been published to Arbitrum One can be transferred to a new wallet or a Multisig. You can do so by clicking the three dots next to the 'Publish' button on the subgraph's details page and selecting 'Transfer ownership'.
+Ja, Subgraphen, die auf Arbitrum One veröffentlicht wurden, können auf eine neue Wallet oder eine Multisig übertragen werden. Klicken Sie dazu auf die drei Punkte neben der Schaltfläche „Veröffentlichen“ auf der Detailseite des Subgraphen und wählen Sie „Eigentum übertragen“.
 
 Beachten Sie, dass Sie den Subgrafen nach der Übertragung nicht mehr in Studio sehen oder bearbeiten können.
 
-## 6. How do I find query URLs for subgraphs if I’m not the developer of the subgraph I want to use?
+## 6. Wie finde ich Abfrage-URLs für Subgraphen, wenn ich kein Entwickler des Subgraphen bin, den ich verwenden möchte?
 
-You can find the query URL of each subgraph in the Subgraph Details section of Graph Explorer. When you click on the “Query” button, you will be directed to a pane wherein you can view the query URL of the subgraph you’re interested in. You can then replace the `<api_key>` placeholder with the API key you wish to leverage in Subgraph Studio.
+Die Abfrage-URL eines jeden Subgraphen finden Sie im Abschnitt Subgraph Details des Graph Explorers.Wenn Sie auf die Schaltfläche „Abfrage“ klicken, werden Sie zu einem Fenster weitergeleitet, in dem Sie die Abfrage-URL des gewünschten Subgraphen sehen können. Sie können dann den <api_key>-Platzhalter durch den API-Schlüssel ersetzen, den Sie in Subgraph Studio verwenden möchten.
 
 Denken Sie daran, dass Sie einen API-Schlüssel erstellen und jeden im Netzwerk veröffentlichten Subgrafen abfragen können, auch wenn Sie selbst einen Subgrafen erstellen. Diese Abfragen über den neuen API-Schlüssel sind wie alle anderen im Netzwerk kostenpflichtige Abfragen.

From df7576a4e60212fe0cef532cf5a7fc497785e9c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 14:55:57 -0500
Subject: [PATCH 2838/3820] New translations overview.mdx (Portuguese)

---
 website/pages/pt/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/pt/indexing/overview.mdx b/website/pages/pt/indexing/overview.mdx
index a9b2bc304e84..e3202f60fe2a 100644
--- a/website/pages/pt/indexing/overview.mdx
+++ b/website/pages/pt/indexing/overview.mdx
@@ -735,9 +735,9 @@ Exemplo de custo de query usando o modelo acima:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Aplicação do modelo de custo
 

From 27bc1787d1618695a0738c0d717d80e6d6837577 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 14:56:02 -0500
Subject: [PATCH 2839/3820] New translations graphql-api.mdx (Portuguese)

---
 website/pages/pt/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs/querying/graphql-api.mdx b/website/pages/pt/subgraphs/querying/graphql-api.mdx
index 58f928ebbaed..ae724618544e 100644
--- a/website/pages/pt/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/pt/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Operadores de busca fulltext:
 | Símbolo | Operador    | Descrição                                                                                                                                                          |
 | ------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`     | `And`       | Para combinar múltiplos termos de busca num filtro para entidades que incluem todos os termos fornecidos                                                           |
-| |       | `Or`        | Consultas com vários termos de busca separados pelo operador <code>or</code> retornarão todas as entidades com uma correspondência de qualquer termo providenciado |
+| &#x7c;  | `Or`        | Consultas com vários termos de busca separados pelo operador <code>or</code> retornarão todas as entidades com uma correspondência de qualquer termo providenciado |
 | `<->`   | `Follow by` | Especifica a distância entre duas palavras.                                                                                                                        |
 | `:*`    | `Prefix`    | Use o prefixo para encontrar palavras que correspondem a tal prefixo (2 caracteres necessários.)                                                                   |
 

From 449938e7fe3ad51d27de2b5dd51b6bd388f9834e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 14:56:16 -0500
Subject: [PATCH 2840/3820] New translations overview.mdx (Hindi)

---
 website/pages/hi/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/hi/indexing/overview.mdx b/website/pages/hi/indexing/overview.mdx
index 9dc77212b462..abcb7c18263c 100644
--- a/website/pages/hi/indexing/overview.mdx
+++ b/website/pages/hi/indexing/overview.mdx
@@ -735,9 +735,9 @@ default => 0.1 * $SYSTEM_LOAD;
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### लागत मॉडल लागू करना
 

From 29a3efb23395f82de59cddae0c3b06b76743f2cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 14:56:45 -0500
Subject: [PATCH 2841/3820] New translations supported-networks.mdx
 (Portuguese)

---
 website/pages/pt/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/supported-networks.mdx b/website/pages/pt/supported-networks.mdx
index 32ef975a6537..7eca2705248f 100644
--- a/website/pages/pt/supported-networks.mdx
+++ b/website/pages/pt/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - O Subgraph Studio depende da estabilidade e da confiança das tecnologias subjacentes, por exemplo, JSON-RPC, Firehose e endpoints dos Substreams.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From b4275e1096ae00e5ee7df844408be42e845cbdfb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 14:58:38 -0500
Subject: [PATCH 2842/3820] New translations overview.mdx (Romanian)

---
 website/pages/ro/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ro/indexing/overview.mdx b/website/pages/ro/indexing/overview.mdx
index ced5ed20026b..bf8b9aa8e3ca 100644
--- a/website/pages/ro/indexing/overview.mdx
+++ b/website/pages/ro/indexing/overview.mdx
@@ -735,9 +735,9 @@ Example query costing using the above model:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Applying the cost model
 

From db33302603ff09f7f893368e21c9f590f9cd24aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 14:58:42 -0500
Subject: [PATCH 2843/3820] New translations graphql-api.mdx (Romanian)

---
 website/pages/ro/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/subgraphs/querying/graphql-api.mdx b/website/pages/ro/subgraphs/querying/graphql-api.mdx
index 2ffcb85e4019..5d05eadeeb84 100644
--- a/website/pages/ro/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/ro/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltext search operators:
 | Symbol | Operator    | Description                                                                                                                          |
 | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
-| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| &#x7c; | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
 | `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
 | `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 

From d826eedc1b3ba3f174e363ae2e856caac658aa04 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 14:59:28 -0500
Subject: [PATCH 2844/3820] New translations supported-networks.mdx (Romanian)

---
 website/pages/ro/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/supported-networks.mdx b/website/pages/ro/supported-networks.mdx
index ccdebbd3ea16..f77b19356ab0 100644
--- a/website/pages/ro/supported-networks.mdx
+++ b/website/pages/ro/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 9d35578e5ddbad0fff8a5891c978a08608b96c0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:00:00 -0500
Subject: [PATCH 2845/3820] New translations overview.mdx (Spanish)

---
 website/pages/es/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/es/indexing/overview.mdx b/website/pages/es/indexing/overview.mdx
index 0c27c37d6d31..8b22828d01bf 100644
--- a/website/pages/es/indexing/overview.mdx
+++ b/website/pages/es/indexing/overview.mdx
@@ -735,9 +735,9 @@ Ejemplo de modelo de costo usando el modelo anterior:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0,5 GRT |
-| { tokens { symbol } }                                                        | 0,1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0,6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0,5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0,1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0,6 GRT |
 
 #### Aplicación del modelo de costos
 

From e0ecef0f8fa7a718afc65ddbbfe5daf7b03f8f7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:00:07 -0500
Subject: [PATCH 2846/3820] New translations graphql-api.mdx (Spanish)

---
 website/pages/es/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/subgraphs/querying/graphql-api.mdx b/website/pages/es/subgraphs/querying/graphql-api.mdx
index cb3df62fee73..6d55379b3d08 100644
--- a/website/pages/es/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/es/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Operadores de búsqueda de texto completo:
 | Símbolo | Operador    | Descripción                                                                                                                                                         |
 | ------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `&`     | `And`       | Para combinar varios términos de búsqueda en un filtro para entidades que incluyen todos los términos proporcionados                                                |
-| |       | `Or`        | Las consultas con varios términos de búsqueda separados por o el operador devolverá todas las entidades que coincidan con cualquiera de los términos proporcionados |
+| &#x7c;  | `Or`        | Las consultas con varios términos de búsqueda separados por o el operador devolverá todas las entidades que coincidan con cualquiera de los términos proporcionados |
 | `<->`   | `Follow by` | Especifica la distancia entre dos palabras.                                                                                                                         |
 | `:*`    | `Prefix`    | Utilice el término de búsqueda del prefijo para encontrar palabras cuyo prefijo coincida (se requieren 2 caracteres.)                                               |
 

From 52b00c53b8ee40c7fb05e530d908d71c83d99229 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:00:46 -0500
Subject: [PATCH 2847/3820] New translations supported-networks.mdx (Spanish)

---
 website/pages/es/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/supported-networks.mdx b/website/pages/es/supported-networks.mdx
index 7fa33f237309..edb1f88033f8 100644
--- a/website/pages/es/supported-networks.mdx
+++ b/website/pages/es/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 11b96c67dfbbec57338124c2b8b42d695f4d1d85 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:00:49 -0500
Subject: [PATCH 2848/3820] New translations overview.mdx (Arabic)

---
 website/pages/ar/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ar/indexing/overview.mdx b/website/pages/ar/indexing/overview.mdx
index b896de2f4d64..29aac4514ffb 100644
--- a/website/pages/ar/indexing/overview.mdx
+++ b/website/pages/ar/indexing/overview.mdx
@@ -735,9 +735,9 @@ default => 0.1 * $SYSTEM_LOAD;
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### تطبيق نموذج التكلفة
 

From b351abd2032d004b7e75258f8128643db1842c45 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:00:54 -0500
Subject: [PATCH 2849/3820] New translations graphql-api.mdx (Arabic)

---
 website/pages/ar/subgraphs/querying/graphql-api.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/ar/subgraphs/querying/graphql-api.mdx b/website/pages/ar/subgraphs/querying/graphql-api.mdx
index b93b5b717f96..87134c9cfeff 100644
--- a/website/pages/ar/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/ar/subgraphs/querying/graphql-api.mdx
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 Fulltext search operators:
 
-| رمز   | عامل التشغيل | الوصف                                                                                                                       |
-| ----- | ------------ | --------------------------------------------------------------------------------------------------------------------------- |
-| `&`   | `And`        | لدمج عبارات بحث متعددة في فلتر للكيانات التي تتضمن جميع العبارات المتوفرة                                                   |
-| |     | `Or`         | الاستعلامات التي تحتوي على عبارات بحث متعددة مفصولة بواسطة عامل التشغيل or ستعيد جميع الكيانات المتطابقة من أي عبارة متوفرة |
-| `<->` | `Follow by`  | يحدد المسافة بين كلمتين.                                                                                                    |
-| `:*`  | `Prefix`     | يستخدم عبارة البحث prefix للعثور على الكلمات التي تتطابق بادئتها (مطلوب حرفان.)                                             |
+| رمز    | عامل التشغيل | الوصف                                                                                                                       |
+| ------ | ------------ | --------------------------------------------------------------------------------------------------------------------------- |
+| `&`    | `And`        | لدمج عبارات بحث متعددة في فلتر للكيانات التي تتضمن جميع العبارات المتوفرة                                                   |
+| &#x7c; | `Or`         | الاستعلامات التي تحتوي على عبارات بحث متعددة مفصولة بواسطة عامل التشغيل or ستعيد جميع الكيانات المتطابقة من أي عبارة متوفرة |
+| `<->`  | `Follow by`  | يحدد المسافة بين كلمتين.                                                                                                    |
+| `:*`   | `Prefix`     | يستخدم عبارة البحث prefix للعثور على الكلمات التي تتطابق بادئتها (مطلوب حرفان.)                                             |
 
 #### Examples
 

From 630676e6ca84f490a989f415dd9c9c670609a57d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:01:25 -0500
Subject: [PATCH 2850/3820] New translations supported-networks.mdx (Arabic)

---
 website/pages/ar/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/supported-networks.mdx b/website/pages/ar/supported-networks.mdx
index f334e4d10143..ef8f1ad42132 100644
--- a/website/pages/ar/supported-networks.mdx
+++ b/website/pages/ar/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From d89a2af85d8ed8d59a8a1234bbce24cc61a7c54e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:01:28 -0500
Subject: [PATCH 2851/3820] New translations overview.mdx (Czech)

---
 website/pages/cs/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/cs/indexing/overview.mdx b/website/pages/cs/indexing/overview.mdx
index 0a053109d883..030320368edc 100644
--- a/website/pages/cs/indexing/overview.mdx
+++ b/website/pages/cs/indexing/overview.mdx
@@ -735,9 +735,9 @@ Příklad výpočtu nákladů na dotaz pomocí výše uvedeného modelu:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Použití nákladového modelu
 

From 1c6cdbf7595d2e0f8884a519da35caad3f944f6f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:01:33 -0500
Subject: [PATCH 2852/3820] New translations graphql-api.mdx (Czech)

---
 website/pages/cs/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/subgraphs/querying/graphql-api.mdx b/website/pages/cs/subgraphs/querying/graphql-api.mdx
index a02cf74a0854..b7094c0ffe49 100644
--- a/website/pages/cs/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/cs/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Operátory fulltextového vyhledávání:
 | Symbol | Operátor    | Popis                                                                                                                         |
 | ------ | ----------- | ----------------------------------------------------------------------------------------------------------------------------- |
 | `&`    | `And`       | Pro kombinaci více vyhledávacích výrazů do filtru pro entity, které obsahují všechny zadané výrazy                            |
-| |      | `Or`        | Dotazy s více hledanými výrazy oddělenými operátorem nebo vrátí všechny entity, které odpovídají některému z uvedených výrazů |
+| &#x7c; | `Or`        | Dotazy s více hledanými výrazy oddělenými operátorem nebo vrátí všechny entity, které odpovídají některému z uvedených výrazů |
 | `<->`  | `Follow by` | Zadejte vzdálenost mezi dvěma slovy.                                                                                          |
 | `:*`   | `Prefix`    | Pomocí předponového výrazu vyhledejte slova, jejichž předpona se shoduje (vyžadovány 2 znaky)                                 |
 

From 320cb836133cb3c85e21cafd732786a5bfae93e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:02:04 -0500
Subject: [PATCH 2853/3820] New translations supported-networks.mdx (Czech)

---
 website/pages/cs/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/supported-networks.mdx b/website/pages/cs/supported-networks.mdx
index 138af9a2c8b8..3bf1d3af3844 100644
--- a/website/pages/cs/supported-networks.mdx
+++ b/website/pages/cs/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From ad492065f8428f438b2d99846bac91ffd1258cc7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:02:07 -0500
Subject: [PATCH 2854/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
index 52f206c295a5..c960c41ac917 100644
--- a/website/pages/de/indexing/overview.mdx
+++ b/website/pages/de/indexing/overview.mdx
@@ -735,9 +735,9 @@ Example query costing using the above model:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Anwendung des Kostenmodells
 

From 394f8790a2b4b55c5fb7273e5a3546a143d430e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:02:12 -0500
Subject: [PATCH 2855/3820] New translations graphql-api.mdx (German)

---
 website/pages/de/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/querying/graphql-api.mdx b/website/pages/de/subgraphs/querying/graphql-api.mdx
index cef9143e85af..1e5fd0bed902 100644
--- a/website/pages/de/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/de/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltext search operators:
 | Symbol | Operator    | Beschreibung                                                                                                                         |
 | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
-| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| &#x7c; | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
 | `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
 | `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 

From 6afdfa756746701ae662b924ef38fab6e666cd1b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:02:42 -0500
Subject: [PATCH 2856/3820] New translations supported-networks.mdx (German)

---
 website/pages/de/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/supported-networks.mdx b/website/pages/de/supported-networks.mdx
index d2f36138a178..b4e30306d439 100644
--- a/website/pages/de/supported-networks.mdx
+++ b/website/pages/de/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 1288d7690d55366af01daa9aeff220bdfc34dff2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:02:46 -0500
Subject: [PATCH 2857/3820] New translations overview.mdx (Italian)

---
 website/pages/it/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/it/indexing/overview.mdx b/website/pages/it/indexing/overview.mdx
index 171e836778d6..40ed32b5eda3 100644
--- a/website/pages/it/indexing/overview.mdx
+++ b/website/pages/it/indexing/overview.mdx
@@ -735,9 +735,9 @@ Esempio di query di costo utilizzando il modello di cui sopra:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Applicazione del modello di costo
 

From 4a4418ab66b57638e884d7be779303ffc2d06660 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:02:50 -0500
Subject: [PATCH 2858/3820] New translations graphql-api.mdx (Italian)

---
 website/pages/it/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/subgraphs/querying/graphql-api.mdx b/website/pages/it/subgraphs/querying/graphql-api.mdx
index 52fbb7200072..6ef60b10c912 100644
--- a/website/pages/it/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/it/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Operatori di ricerca fulltext:
 | Simbolo | Operatore   | Descrizione                                                                                                                               |
 | ------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
 | `&`     | `And`       | Per combinare più termini di ricerca in un filtro per le entità che includono tutti i termini forniti                                     |
-| |       | `Or`        | Le query con più termini di ricerca separati dall'operatore Or restituiranno tutte le entità con una corrispondenza tra i termini forniti |
+| &#x7c;  | `Or`        | Le query con più termini di ricerca separati dall'operatore Or restituiranno tutte le entità con una corrispondenza tra i termini forniti |
 | `<->`   | `Follow by` | Specifica la distanza tra due parole.                                                                                                     |
 | `:*`    | `Prefix`    | Utilizzare il termine di ricerca del prefisso per trovare le parole il cui prefisso corrisponde (sono richiesti 2 caratteri.)             |
 

From 780d55ae9ae48c07c030b2dc297c777aa13164a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:03:21 -0500
Subject: [PATCH 2859/3820] New translations supported-networks.mdx (Italian)

---
 website/pages/it/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/supported-networks.mdx b/website/pages/it/supported-networks.mdx
index d2f36138a178..b4e30306d439 100644
--- a/website/pages/it/supported-networks.mdx
+++ b/website/pages/it/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From d935689031dd94be2afb02bbc1a85fa9377a882b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:03:24 -0500
Subject: [PATCH 2860/3820] New translations overview.mdx (Japanese)

---
 website/pages/ja/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ja/indexing/overview.mdx b/website/pages/ja/indexing/overview.mdx
index aed98f39d428..e28066be145d 100644
--- a/website/pages/ja/indexing/overview.mdx
+++ b/website/pages/ja/indexing/overview.mdx
@@ -734,9 +734,9 @@ default => 0.1 * $SYSTEM_LOAD;
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### コストモデルの適用
 

From 1601ade7ab514e2079418b9f901df3379f82c8c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:03:29 -0500
Subject: [PATCH 2861/3820] New translations graphql-api.mdx (Japanese)

---
 website/pages/ja/subgraphs/querying/graphql-api.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/ja/subgraphs/querying/graphql-api.mdx b/website/pages/ja/subgraphs/querying/graphql-api.mdx
index b0708c414106..ecefb9a6bf9b 100644
--- a/website/pages/ja/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/ja/subgraphs/querying/graphql-api.mdx
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 全文検索演算子:
 
-| シンボル  | オペレーター      | 説明書き                                                      |
-| ----- | ----------- | --------------------------------------------------------- |
-| `&`   | `And`       | 複数の検索語を組み合わせて、指定したすべての検索語を含むエンティティをフィルタリングします。            |
-| |     | `Or`        | 複数の検索語をオペレーターで区切って検索すると、指定した語のいずれかにマッチするすべてのエンティティが返されます。 |
-| `<->` | `Follow by` | 2 つの単語の間の距離を指定します。                                        |
-| `:*`  | `Prefix`    | プレフィックス検索語を使って、プレフィックスが一致する単語を検索します（2 文字必要）               |
+| シンボル   | オペレーター      | 説明書き                                                      |
+| ------ | ----------- | --------------------------------------------------------- |
+| `&`    | `And`       | 複数の検索語を組み合わせて、指定したすべての検索語を含むエンティティをフィルタリングします。            |
+| &#x7c; | `Or`        | 複数の検索語をオペレーターで区切って検索すると、指定した語のいずれかにマッチするすべてのエンティティが返されます。 |
+| `<->`  | `Follow by` | 2 つの単語の間の距離を指定します。                                        |
+| `:*`   | `Prefix`    | プレフィックス検索語を使って、プレフィックスが一致する単語を検索します（2 文字必要）               |
 
 #### 例
 

From ca286626ff5eef995b7f4fef70a9a21ab8262ce4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:03:59 -0500
Subject: [PATCH 2862/3820] New translations supported-networks.mdx (Japanese)

---
 website/pages/ja/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/supported-networks.mdx b/website/pages/ja/supported-networks.mdx
index dd3f51c77baf..f34a6442d225 100644
--- a/website/pages/ja/supported-networks.mdx
+++ b/website/pages/ja/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From d549c384d34254f95314f9778c2644f6223bc4ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:04:02 -0500
Subject: [PATCH 2863/3820] New translations overview.mdx (Korean)

---
 website/pages/ko/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ko/indexing/overview.mdx b/website/pages/ko/indexing/overview.mdx
index ced5ed20026b..bf8b9aa8e3ca 100644
--- a/website/pages/ko/indexing/overview.mdx
+++ b/website/pages/ko/indexing/overview.mdx
@@ -735,9 +735,9 @@ Example query costing using the above model:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Applying the cost model
 

From d177cc9c6a94e2b306e90d9a714b3cbc51d26077 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:04:07 -0500
Subject: [PATCH 2864/3820] New translations graphql-api.mdx (Korean)

---
 website/pages/ko/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/subgraphs/querying/graphql-api.mdx b/website/pages/ko/subgraphs/querying/graphql-api.mdx
index 2ffcb85e4019..5d05eadeeb84 100644
--- a/website/pages/ko/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/ko/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltext search operators:
 | Symbol | Operator    | Description                                                                                                                          |
 | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
-| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| &#x7c; | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
 | `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
 | `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 

From bfab649b970221b5c5ec2773ede2b4b0ed03dc50 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:04:36 -0500
Subject: [PATCH 2865/3820] New translations supported-networks.mdx (Korean)

---
 website/pages/ko/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/supported-networks.mdx b/website/pages/ko/supported-networks.mdx
index d2f36138a178..b4e30306d439 100644
--- a/website/pages/ko/supported-networks.mdx
+++ b/website/pages/ko/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 3fb4e3ebfe8020b5a8eaf6a9b7c891882fea7b86 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:04:40 -0500
Subject: [PATCH 2866/3820] New translations overview.mdx (Dutch)

---
 website/pages/nl/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/nl/indexing/overview.mdx b/website/pages/nl/indexing/overview.mdx
index 3659d48ee94f..54e1465f61f0 100644
--- a/website/pages/nl/indexing/overview.mdx
+++ b/website/pages/nl/indexing/overview.mdx
@@ -735,9 +735,9 @@ Example query costing using the above model:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Applying the cost model
 

From 582ec05a2871b2a4fa4ac02831f57f254db29ea8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:04:44 -0500
Subject: [PATCH 2867/3820] New translations graphql-api.mdx (Dutch)

---
 website/pages/nl/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/subgraphs/querying/graphql-api.mdx b/website/pages/nl/subgraphs/querying/graphql-api.mdx
index 2ffcb85e4019..5d05eadeeb84 100644
--- a/website/pages/nl/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/nl/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltext search operators:
 | Symbol | Operator    | Description                                                                                                                          |
 | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
-| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| &#x7c; | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
 | `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
 | `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 

From 9f3109b63780224908fe5d16696e3509c7f0d1b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:05:15 -0500
Subject: [PATCH 2868/3820] New translations supported-networks.mdx (Dutch)

---
 website/pages/nl/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/supported-networks.mdx b/website/pages/nl/supported-networks.mdx
index 088e27acc68a..68bcc2bf8d78 100644
--- a/website/pages/nl/supported-networks.mdx
+++ b/website/pages/nl/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From cebb20b434b32757b06c2bf1b5a63f4ebf251a38 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:05:19 -0500
Subject: [PATCH 2869/3820] New translations overview.mdx (Polish)

---
 website/pages/pl/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/pl/indexing/overview.mdx b/website/pages/pl/indexing/overview.mdx
index ced5ed20026b..bf8b9aa8e3ca 100644
--- a/website/pages/pl/indexing/overview.mdx
+++ b/website/pages/pl/indexing/overview.mdx
@@ -735,9 +735,9 @@ Example query costing using the above model:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Applying the cost model
 

From ebc4f205d516087b71ef140e8a46e41fd697b63a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:05:24 -0500
Subject: [PATCH 2870/3820] New translations graphql-api.mdx (Polish)

---
 website/pages/pl/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/subgraphs/querying/graphql-api.mdx b/website/pages/pl/subgraphs/querying/graphql-api.mdx
index 2ffcb85e4019..5d05eadeeb84 100644
--- a/website/pages/pl/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/pl/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltext search operators:
 | Symbol | Operator    | Description                                                                                                                          |
 | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
-| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| &#x7c; | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
 | `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
 | `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 

From cfa552bf257253adcc93c848803eff7cefc2e0dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:05:54 -0500
Subject: [PATCH 2871/3820] New translations supported-networks.mdx (Polish)

---
 website/pages/pl/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/supported-networks.mdx b/website/pages/pl/supported-networks.mdx
index b93eb3b51f21..8b8ed4b132a0 100644
--- a/website/pages/pl/supported-networks.mdx
+++ b/website/pages/pl/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 6b49286e6f2e87eca90a8b31d8a7776e22c24228 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:05:57 -0500
Subject: [PATCH 2872/3820] New translations overview.mdx (Russian)

---
 website/pages/ru/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ru/indexing/overview.mdx b/website/pages/ru/indexing/overview.mdx
index 24d129f62360..212d822f65e4 100644
--- a/website/pages/ru/indexing/overview.mdx
+++ b/website/pages/ru/indexing/overview.mdx
@@ -735,9 +735,9 @@ default => 0.1 * $SYSTEM_LOAD;
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Применение модели затрат
 

From a0acc1502fb8037d5a85654ea3a046d97936c825 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:06:01 -0500
Subject: [PATCH 2873/3820] New translations graphql-api.mdx (Russian)

---
 website/pages/ru/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/querying/graphql-api.mdx b/website/pages/ru/subgraphs/querying/graphql-api.mdx
index e66e95936fa8..e8172fae7aab 100644
--- a/website/pages/ru/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/ru/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltext search queries have one required field, `text`, for supplying search te
 | Символ | Оператор    | Описание                                                                                                                                       |
 | ------ | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
 | `&`    | `And`       | Для объединения нескольких условий поиска в фильтр для объектов, которые включают все указанные условия                                        |
-| |      | `Or`        | Запросы с несколькими условиями поиска, разделенные оператором or, вернут все объекты, которые соответствуют любому из предоставленных условий |
+| &#x7c; | `Or`        | Запросы с несколькими условиями поиска, разделенные оператором or, вернут все объекты, которые соответствуют любому из предоставленных условий |
 | `<->`  | `Follow by` | Укажите расстояние между двумя словами.                                                                                                        |
 | `:*`   | `Prefix`    | Используйте поисковый запрос по префиксу, чтобы найти слова с соответствующим префиксом (необходимо 2 символа)                                 |
 

From 938f892c8b51103c9ac0a7fe1efad4f2d5000d04 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:06:33 -0500
Subject: [PATCH 2874/3820] New translations supported-networks.mdx (Russian)

---
 website/pages/ru/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/supported-networks.mdx b/website/pages/ru/supported-networks.mdx
index 49fdf4f940f6..50016fc0ecbf 100644
--- a/website/pages/ru/supported-networks.mdx
+++ b/website/pages/ru/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio полагается на стабильность и надежность базовых технологий, например, таких, как JSON-RPC, Firehose и конечных точек Substreams.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From ac8b1d2fdbe152ad6f3bc38b319c25847f0cc17e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:06:36 -0500
Subject: [PATCH 2875/3820] New translations overview.mdx (Swedish)

---
 website/pages/sv/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/sv/indexing/overview.mdx b/website/pages/sv/indexing/overview.mdx
index 909be6a56069..efac780ecab6 100644
--- a/website/pages/sv/indexing/overview.mdx
+++ b/website/pages/sv/indexing/overview.mdx
@@ -735,9 +735,9 @@ Exempel på kostnadskalkyl enligt ovanstående modell:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Tillämpning av kostnadsmodellen
 

From 1d7eec9e76fde729b579f81e32027e40489795c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:06:41 -0500
Subject: [PATCH 2876/3820] New translations graphql-api.mdx (Swedish)

---
 website/pages/sv/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/subgraphs/querying/graphql-api.mdx b/website/pages/sv/subgraphs/querying/graphql-api.mdx
index 0a5704e2eecf..360dbc78d42d 100644
--- a/website/pages/sv/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/sv/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltextsökoperatorer:
 | Symbol | Operatör    | Beskrivning                                                                                                                                     |
 | ------ | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
 | `&`    | `And`       | För att kombinera flera söktermer till ett filter för entiteter som inkluderar alla de angivna termerna                                         |
-| |      | `Or`        | Förfrågningar med flera söktermer separerade av ellipsen kommer att returnera alla entiteter med en matchning från någon av de angivna termerna |
+| &#x7c; | `Or`        | Förfrågningar med flera söktermer separerade av ellipsen kommer att returnera alla entiteter med en matchning från någon av de angivna termerna |
 | `<->`  | `Follow by` | Ange avståndet mellan två ord.                                                                                                                  |
 | `:*`   | `Prefix`    | Använd prefixsöktermen för att hitta ord vars prefix matchar (2 tecken krävs.)                                                                  |
 

From 58f4a1d78743ffa0a6ae776d748e5a26631951ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:07:11 -0500
Subject: [PATCH 2877/3820] New translations supported-networks.mdx (Swedish)

---
 website/pages/sv/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/supported-networks.mdx b/website/pages/sv/supported-networks.mdx
index bcd81ae81313..e20745df9b0b 100644
--- a/website/pages/sv/supported-networks.mdx
+++ b/website/pages/sv/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 4cb65b5e23ca056872465b15be653a5b74e6f877 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:07:15 -0500
Subject: [PATCH 2878/3820] New translations overview.mdx (Turkish)

---
 website/pages/tr/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/tr/indexing/overview.mdx b/website/pages/tr/indexing/overview.mdx
index 403b5e2f1abb..8ea35b7a5322 100644
--- a/website/pages/tr/indexing/overview.mdx
+++ b/website/pages/tr/indexing/overview.mdx
@@ -735,9 +735,9 @@ Yukarıdaki modeli kullanarak örnek sorgu maliyetlendirmesi:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Maliyet modelinin uygulanması
 

From e9f84375a003cc18164132300e6d07e3d1ca3ef2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:07:19 -0500
Subject: [PATCH 2879/3820] New translations graphql-api.mdx (Turkish)

---
 website/pages/tr/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/querying/graphql-api.mdx b/website/pages/tr/subgraphs/querying/graphql-api.mdx
index 95fb439ed2c3..b230ac10f794 100644
--- a/website/pages/tr/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/tr/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Tam metin arama operatörleri:
 | Symbol | Operator    | Tanım                                                                                                                                |
 | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
-| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| &#x7c; | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
 | `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
 | `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 

From b50518d9d5d76f96eae5483b1893654eb82fe80d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:07:43 -0500
Subject: [PATCH 2880/3820] New translations supported-networks.mdx (Turkish)

---
 website/pages/tr/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/supported-networks.mdx b/website/pages/tr/supported-networks.mdx
index 32151f660dec..b68a3f430b06 100644
--- a/website/pages/tr/supported-networks.mdx
+++ b/website/pages/tr/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio, örneğin JSON-RPC, Firehose ve Substreams uç noktaları gibi temel teknolojilerin istikrarlılığına ve güvenilirliğine bel bağlar.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 79e1238da3f306ba105765ce78797974f9de7fc1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:07:46 -0500
Subject: [PATCH 2881/3820] New translations overview.mdx (Ukrainian)

---
 website/pages/uk/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/uk/indexing/overview.mdx b/website/pages/uk/indexing/overview.mdx
index 3b3e09df18c7..b1f50b90ac23 100644
--- a/website/pages/uk/indexing/overview.mdx
+++ b/website/pages/uk/indexing/overview.mdx
@@ -735,9 +735,9 @@ default => 0.1 * $SYSTEM_LOAD;
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Застосування вартісної моделі
 

From bc10734e133e73692511155003765869e6a19ddf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:07:51 -0500
Subject: [PATCH 2882/3820] New translations graphql-api.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/subgraphs/querying/graphql-api.mdx b/website/pages/uk/subgraphs/querying/graphql-api.mdx
index 2ffcb85e4019..5d05eadeeb84 100644
--- a/website/pages/uk/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/uk/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltext search operators:
 | Symbol | Operator    | Description                                                                                                                          |
 | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
-| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| &#x7c; | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
 | `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
 | `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 

From b97323445cf4539fd913b486f33d7528b455fbd5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:08:20 -0500
Subject: [PATCH 2883/3820] New translations supported-networks.mdx (Ukrainian)

---
 website/pages/uk/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/supported-networks.mdx b/website/pages/uk/supported-networks.mdx
index a17adec8c4b1..8a619b76b8c4 100644
--- a/website/pages/uk/supported-networks.mdx
+++ b/website/pages/uk/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 68a9600d7a8ddd16ee725d61c114ee6ed2074400 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:08:26 -0500
Subject: [PATCH 2884/3820] New translations graphql-api.mdx (Chinese
 Simplified)

---
 website/pages/zh/subgraphs/querying/graphql-api.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/zh/subgraphs/querying/graphql-api.mdx b/website/pages/zh/subgraphs/querying/graphql-api.mdx
index dfea78d5e6ef..25e939f7d6ea 100644
--- a/website/pages/zh/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/zh/subgraphs/querying/graphql-api.mdx
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 全文搜索运算符：
 
-| 符号    | 运算符         | 描述                                    |
-| ----- | ----------- | ------------------------------------- |
-| `&`   | `And`       | 用于将多个搜索词组合到包含所有提供词条的实体的过滤器中           |
-| |     | `Or`        | 由 or 运算符分隔的多个搜索词的查询，将返回与任何提供的词匹配的所有实体 |
-| `<->` | `Follow by` | 指定两个单词之间的距离。                          |
-| `:*`  | `Prefix`    | 使用前缀搜索词查找前缀匹配的单词（需要 2 个字符）            |
+| 符号     | 运算符         | 描述                                    |
+| ------ | ----------- | ------------------------------------- |
+| `&`    | `And`       | 用于将多个搜索词组合到包含所有提供词条的实体的过滤器中           |
+| &#x7c; | `Or`        | 由 or 运算符分隔的多个搜索词的查询，将返回与任何提供的词匹配的所有实体 |
+| `<->`  | `Follow by` | 指定两个单词之间的距离。                          |
+| `:*`   | `Prefix`    | 使用前缀搜索词查找前缀匹配的单词（需要 2 个字符）            |
 
 #### 例子
 

From 1c2ccff66f54dae88790677888e39c9db1a123f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:08:51 -0500
Subject: [PATCH 2885/3820] New translations supported-networks.mdx (Chinese
 Simplified)

---
 website/pages/zh/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/supported-networks.mdx b/website/pages/zh/supported-networks.mdx
index 5607a08de64c..41fe184776a6 100644
--- a/website/pages/zh/supported-networks.mdx
+++ b/website/pages/zh/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 48caaa0bc5e68d569536fe6f84ac247e3ebe5d41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:08:54 -0500
Subject: [PATCH 2886/3820] New translations overview.mdx (Urdu (Pakistan))

---
 website/pages/ur/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ur/indexing/overview.mdx b/website/pages/ur/indexing/overview.mdx
index 68171eb27f5e..a59397a87e32 100644
--- a/website/pages/ur/indexing/overview.mdx
+++ b/website/pages/ur/indexing/overview.mdx
@@ -735,9 +735,9 @@ default => 0.1 * $SYSTEM_LOAD;
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Cost ماڈل لاگو کرنا
 

From 87f0d2ad39081988c911ac1b7539879478463617 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:08:59 -0500
Subject: [PATCH 2887/3820] New translations graphql-api.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/querying/graphql-api.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/ur/subgraphs/querying/graphql-api.mdx b/website/pages/ur/subgraphs/querying/graphql-api.mdx
index de7aa00b9d61..eb8c12cdcff3 100644
--- a/website/pages/ur/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/ur/subgraphs/querying/graphql-api.mdx
@@ -335,12 +335,12 @@ Fulltext search queries have one required field, `text`, for supplying search te
 
 فل ٹیکسٹ سرچ آپریٹرز:
 
-| علامت | آپریٹر      | تفصیل                                                                                                                                           |
-| ----- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
-| `&`   | `And`       | ایک سے زیادہ تلاش کی اصطلاحات کو ایک فلٹر میں یکجا کرنے کے لیے ان ہستیوں کے لیے جس میں فراہم کردہ تمام اصطلاحات شامل ہوں                        |
-| |     | `Or`        | Or آپریٹر کے ذریعہ الگ کردہ متعدد تلاش کی اصطلاحات کے ساتھ کیوریز فراہم کردہ شرائط میں سے کسی سے بھی مماثلت کے ساتھ تمام ہستیوں کو واپس کریں گے |
-| `<->` | `Follow by` | دو الفاظ کے درمیان فاصلہ بتائیں.                                                                                                                |
-| `:*`  | `Prefix`    | ایسے الفاظ تلاش کرنے کے لیے پریفکس ​​تلاش کی اصطلاح استعمال کریں جن کا سابقہ ​​مماثل ہو (۲ حروف درکار ہیں.)                                     |
+| علامت  | آپریٹر      | تفصیل                                                                                                                                           |
+| ------ | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
+| `&`    | `And`       | ایک سے زیادہ تلاش کی اصطلاحات کو ایک فلٹر میں یکجا کرنے کے لیے ان ہستیوں کے لیے جس میں فراہم کردہ تمام اصطلاحات شامل ہوں                        |
+| &#x7c; | `Or`        | Or آپریٹر کے ذریعہ الگ کردہ متعدد تلاش کی اصطلاحات کے ساتھ کیوریز فراہم کردہ شرائط میں سے کسی سے بھی مماثلت کے ساتھ تمام ہستیوں کو واپس کریں گے |
+| `<->`  | `Follow by` | دو الفاظ کے درمیان فاصلہ بتائیں.                                                                                                                |
+| `:*`   | `Prefix`    | ایسے الفاظ تلاش کرنے کے لیے پریفکس ​​تلاش کی اصطلاح استعمال کریں جن کا سابقہ ​​مماثل ہو (۲ حروف درکار ہیں.)                                     |
 
 #### مثالیں
 

From 726a4b4cb032cae0b07e1b56ee0e7c947bcd60ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:09:29 -0500
Subject: [PATCH 2888/3820] New translations supported-networks.mdx (Urdu
 (Pakistan))

---
 website/pages/ur/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/supported-networks.mdx b/website/pages/ur/supported-networks.mdx
index 1e3c4aba1f58..d6c795fbdf90 100644
--- a/website/pages/ur/supported-networks.mdx
+++ b/website/pages/ur/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 42792ca02c7441e8bfc6b4ee51552ec7f23b55bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:09:32 -0500
Subject: [PATCH 2889/3820] New translations overview.mdx (Vietnamese)

---
 website/pages/vi/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/vi/indexing/overview.mdx b/website/pages/vi/indexing/overview.mdx
index 91584928878f..4000be879155 100644
--- a/website/pages/vi/indexing/overview.mdx
+++ b/website/pages/vi/indexing/overview.mdx
@@ -735,9 +735,9 @@ Example query costing using the above model:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Áp dụng mô hình chi phí
 

From cacb2b34d44a1753235a4b3d025a8c0bd6834353 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:09:36 -0500
Subject: [PATCH 2890/3820] New translations graphql-api.mdx (Vietnamese)

---
 website/pages/vi/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/subgraphs/querying/graphql-api.mdx b/website/pages/vi/subgraphs/querying/graphql-api.mdx
index 380c4abb48be..13879d3e1dec 100644
--- a/website/pages/vi/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/vi/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltext search operators:
 | Biểu tượng | Toán tử     | Miêu tả                                                                                                                                                  |
 | ---------- | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `&`        | `And`       | Để kết hợp nhiều cụm từ tìm kiếm thành một bộ lọc cho các thực thể bao gồm tất cả các cụm từ được cung cấp                                               |
-| |          | `Or`        | Các truy vấn có nhiều cụm từ tìm kiếm được phân tách bằng toán tử hoặc sẽ trả về tất cả các thực thể có kết quả khớp với bất kỳ cụm từ nào được cung cấp |
+| &#x7c;     | `Or`        | Các truy vấn có nhiều cụm từ tìm kiếm được phân tách bằng toán tử hoặc sẽ trả về tất cả các thực thể có kết quả khớp với bất kỳ cụm từ nào được cung cấp |
 | `<->`      | `Follow by` | Chỉ định khoảng cách giữa hai từ.                                                                                                                        |
 | `:*`       | `Prefix`    | Sử dụng cụm từ tìm kiếm tiền tố để tìm các từ có tiền tố khớp với nhau (yêu cầu 2 ký tự.)                                                                |
 

From 3b3d3b6fe0f97a04f114ad2018a486dd1c17d315 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:10:05 -0500
Subject: [PATCH 2891/3820] New translations supported-networks.mdx
 (Vietnamese)

---
 website/pages/vi/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/supported-networks.mdx b/website/pages/vi/supported-networks.mdx
index 719fa4376efd..22b22a409b76 100644
--- a/website/pages/vi/supported-networks.mdx
+++ b/website/pages/vi/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 9f6e958ba92e39b8bbaf80e1bc16ab53efccc128 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:10:08 -0500
Subject: [PATCH 2892/3820] New translations overview.mdx (Marathi)

---
 website/pages/mr/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/mr/indexing/overview.mdx b/website/pages/mr/indexing/overview.mdx
index 929bdf624e9d..ae0557f0cbe3 100644
--- a/website/pages/mr/indexing/overview.mdx
+++ b/website/pages/mr/indexing/overview.mdx
@@ -735,9 +735,9 @@ Example query costing using the above model:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Applying the cost model
 

From 7f80122fa9d5182528d72c262691441bdfd8d391 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:10:13 -0500
Subject: [PATCH 2893/3820] New translations graphql-api.mdx (Marathi)

---
 website/pages/mr/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/subgraphs/querying/graphql-api.mdx b/website/pages/mr/subgraphs/querying/graphql-api.mdx
index e78c16e9f438..bc270a4c183a 100644
--- a/website/pages/mr/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/mr/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltext search operators:
 | Symbol | Operator    | वर्णन                                                                                                                                |
 | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
-| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| &#x7c; | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
 | `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
 | `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 

From 3d2ab5fbf10f268b2722b3f9fdc1a0bb5ef61227 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:10:42 -0500
Subject: [PATCH 2894/3820] New translations supported-networks.mdx (Marathi)

---
 website/pages/mr/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/supported-networks.mdx b/website/pages/mr/supported-networks.mdx
index d2f36138a178..b4e30306d439 100644
--- a/website/pages/mr/supported-networks.mdx
+++ b/website/pages/mr/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From f49c0d12fb03fbc40dd51ea2a0dfb203329c140a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:10:47 -0500
Subject: [PATCH 2895/3820] New translations graphql-api.mdx (Hindi)

---
 website/pages/hi/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/querying/graphql-api.mdx b/website/pages/hi/subgraphs/querying/graphql-api.mdx
index f1d417589f6b..d5242c331c1a 100644
--- a/website/pages/hi/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/hi/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltext search queries have one required field, `text`, for supplying search te
 | प्रतीक | ऑपरेटर      | Description                                                                                                                          |
 | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`    | `And`       | सभी प्रदान किए गए शब्दों को शामिल करने वाली संस्थाओं के लिए एक से अधिक खोज शब्दों को फ़िल्टर में संयोजित करने के लिए                 |
-| |      | `Or`        | या ऑपरेटर द्वारा अलग किए गए एकाधिक खोज शब्दों वाली क्वेरी सभी संस्थाओं को प्रदान की गई शर्तों में से किसी से मेल के साथ वापस कर देगी |
+| &#x7c; | `Or`        | या ऑपरेटर द्वारा अलग किए गए एकाधिक खोज शब्दों वाली क्वेरी सभी संस्थाओं को प्रदान की गई शर्तों में से किसी से मेल के साथ वापस कर देगी |
 | `<->`  | `Follow by` | दो शब्दों के बीच की दूरी निर्दिष्ट करें।                                                                                             |
 | `:*`   | `Prefix`    | उन शब्दों को खोजने के लिए उपसर्ग खोज शब्द का उपयोग करें जिनके उपसर्ग मेल खाते हैं (2 वर्ण आवश्यक हैं।)                               |
 

From 9fe8f9324686f12e98a7aff11ba265ca29f2664f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:11:17 -0500
Subject: [PATCH 2896/3820] New translations supported-networks.mdx (Hindi)

---
 website/pages/hi/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/supported-networks.mdx b/website/pages/hi/supported-networks.mdx
index 9a980a506766..c4c73324cd45 100644
--- a/website/pages/hi/supported-networks.mdx
+++ b/website/pages/hi/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - सबग्राफ स्टूडियो निर्भर करता है अंतर्निहित प्रौद्योगिकियों की स्थिरता और विश्वसनीयता पर, जैसे JSON-RPC, फायरहोस और सबस्ट्रीम्स एंडपॉइंट्स।
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From 8a84113a66ac3cb8c2bab4cb4fcbb8fc1c35fd80 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:11:20 -0500
Subject: [PATCH 2897/3820] New translations overview.mdx (Swahili)

---
 website/pages/sw/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/sw/indexing/overview.mdx b/website/pages/sw/indexing/overview.mdx
index ced5ed20026b..bf8b9aa8e3ca 100644
--- a/website/pages/sw/indexing/overview.mdx
+++ b/website/pages/sw/indexing/overview.mdx
@@ -735,9 +735,9 @@ Example query costing using the above model:
 
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
-| { pairs(skip: 5000) { id } }                                                 | 0.5 GRT |
-| { tokens { symbol } }                                                        | 0.1 GRT |
-| { pairs(skip: 5000) { id } tokens { symbol } }                               | 0.6 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### Applying the cost model
 

From 4806673cb053bb3f48009b7a25f9b51830739153 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:11:25 -0500
Subject: [PATCH 2898/3820] New translations graphql-api.mdx (Swahili)

---
 website/pages/sw/subgraphs/querying/graphql-api.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/subgraphs/querying/graphql-api.mdx b/website/pages/sw/subgraphs/querying/graphql-api.mdx
index 2ffcb85e4019..5d05eadeeb84 100644
--- a/website/pages/sw/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/sw/subgraphs/querying/graphql-api.mdx
@@ -338,7 +338,7 @@ Fulltext search operators:
 | Symbol | Operator    | Description                                                                                                                          |
 | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------ |
 | `&`    | `And`       | For combining multiple search terms into a filter for entities that include all of the provided terms                                |
-| |      | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
+| &#x7c; | `Or`        | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
 | `<->`  | `Follow by` | Specify the distance between two words.                                                                                              |
 | `:*`   | `Prefix`    | Use the prefix search term to find words whose prefix match (2 characters required.)                                                 |
 

From 42312f6508c9e93da5a40cdb751a19fb2837af8b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 24 Jan 2025 15:11:54 -0500
Subject: [PATCH 2899/3820] New translations supported-networks.mdx (Swahili)

---
 website/pages/sw/supported-networks.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/supported-networks.mdx b/website/pages/sw/supported-networks.mdx
index d2f36138a178..b4e30306d439 100644
--- a/website/pages/sw/supported-networks.mdx
+++ b/website/pages/sw/supported-networks.mdx
@@ -10,7 +10,7 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 <SupportedNetworksTable networks={props.networks} />
 
 \* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). ⁠<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
 
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.

From b0cd753ea90147f33d509c4a8269ebbf66ec05b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 25 Jan 2025 05:55:01 -0500
Subject: [PATCH 2900/3820] New translations benefits.mdx (Hindi)

---
 website/pages/hi/resources/benefits.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/hi/resources/benefits.mdx b/website/pages/hi/resources/benefits.mdx
index 282eed66eab5..6e641cf6c733 100644
--- a/website/pages/hi/resources/benefits.mdx
+++ b/website/pages/hi/resources/benefits.mdx
@@ -1,11 +1,11 @@
 ---
-title: The Graph vs. Self Hosting
+title: The Graph बनाम स्वयं होस्टिंग
 socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
 ---
 
 ग्राफ़ के विकेन्द्रीकृत नेटवर्क को एक मजबूत अनुक्रमण और क्वेरी अनुभव बनाने के लिए इंजीनियर और परिष्कृत किया गया है - और यह दुनिया भर के हजारों योगदानकर्ताओं के लिए हर दिन बेहतर हो रहा है।
 
-The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+इस विकेंद्रीकृत प्रोटोकॉल के लाभों की नकल `ग्राफ-नोड`को लोकल रूप से चलाकर नहीं की जा सकती। The Graph Network अधिक विश्वसनीय, अधिक प्रभावी, और कम महंगा है।
 
 यहाँ एक विश्लेषण है:
 
@@ -19,7 +19,7 @@ The benefits of this decentralized protocol cannot be replicated by running a `g
 
 ## लाभ समझाया
 
-### Lower & more Flexible Cost Structure
+### कम और अधिक लचीला लागत संरचना
 
 No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
 

From c63647d2c24bb5ca6a19ac37d5c883b716613e4e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 01:43:15 -0500
Subject: [PATCH 2901/3820] New translations explorer.mdx (Hindi)

---
 website/pages/hi/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/explorer.mdx b/website/pages/hi/subgraphs/explorer.mdx
index 0fb509865a69..61b2046cefb0 100644
--- a/website/pages/hi/subgraphs/explorer.mdx
+++ b/website/pages/hi/subgraphs/explorer.mdx
@@ -67,7 +67,7 @@ Indexer प्रोटोकॉल की रीढ़ हैं। वे स
 
 Indexers तालिका में, आप Indexers के डेलीगेशन पैरामीटर, उनकी स्टेक, प्रत्येक subgraph के लिए उन्होंने कितना स्टेक किया है, और उन्होंने प्रश्न शुल्क और इंडेक्सिंग पुरस्कारों से कितना राजस्व प्राप्त किया है, देख सकते हैं।
 
-**Specifics**
+**विशिष्टताएँ**
 
 - क्वेरी फ़ी कट - वह % जो क्वेरी फ़ी रिबेट्स का हिस्सा है जो Indexer, Delegators के साथ बाँटते समय रखता है।
 - प्रभावी पुरस्कार कट - वह इंडेक्सिंग पुरस्कार कट जो डेलीगेशन पूल पर लागू होता है। यदि यह नकारात्मक है, तो इसका मतलब है कि इंडेक्सर अपने पुरस्कारों का एक हिस्सा दे रहा है। यदि यह सकारात्मक है, तो इसका मतलब है कि Indexer अपने कुछ पुरस्कार रख रहा है।

From 2dd48be0658360b2ce1118c8d1edceadf4b6f706 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 01:43:17 -0500
Subject: [PATCH 2902/3820] New translations enums.mdx (Hindi)

---
 website/pages/hi/subgraphs/cookbook/enums.mdx | 48 +++++++++----------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/website/pages/hi/subgraphs/cookbook/enums.mdx b/website/pages/hi/subgraphs/cookbook/enums.mdx
index c542f7d54f90..37910ff3a152 100644
--- a/website/pages/hi/subgraphs/cookbook/enums.mdx
+++ b/website/pages/hi/subgraphs/cookbook/enums.mdx
@@ -2,19 +2,19 @@
 title: Categorize NFT Marketplaces Using Enums
 ---
 
-Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+Enams का उपयोग करके अपने कोड को साफ और कम त्रुटिपूर्ण बनाएं। यहां NFT मार्केटप्लेस पर Enams के उपयोग का एक पूरा उदाहरण है।
 
-## What are Enums?
+## Enums क्या हैं?
 
-Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+Enums, या enumeration types, एक विशिष्ट डेटा प्रकार होते हैं जो आपको विशिष्ट, अनुमत मानों का एक सेट परिभाषित करने की अनुमति देते हैं।
 
-### Example of Enums in Your Schema
+### अपने Schema में Enums का उदाहरण
 
 If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
 
 You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
 
-Here's what an enum definition might look like in your schema, based on the example above:
+यहां आपके स्कीमा में एक enum परिभाषा इस प्रकार हो सकती है, उपरोक्त उदाहरण के आधार पर:
 
 ```graphql
 enum TokenStatus {
@@ -24,11 +24,11 @@ enum TokenStatus {
 }
 ```
 
-This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+यह इसका मतलब है कि जब आप अपने स्कीमा में TokenStatus प्रकार का उपयोग करते हैं, तो आप इसकी अपेक्षा करते हैं कि यह पहले से परिभाषित मानों में से एक हो: OriginalOwner, SecondOwner, या ThirdOwner, जिससे निरंतरता और वैधता सुनिश्चित होती है।
 
-To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+इस बारे में अधिक जानने के लिए Creating a Subgraph(/developing/creating-a-subgraph/#enums) और GraphQL documentation(https://graphql.org/learn/schema/#enumeration-types) देखें।
 
-## Benefits of Using Enums
+## Enums का उपयोग करने के लाभ
 
 - **Clarity:** Enums provide meaningful names for values, making data easier to understand.
 - **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
@@ -55,13 +55,13 @@ In this schema, `TokenStatus` is a simple string with no specific, allowed value
 - There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
 - It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
 
-### With Enums
+### Enums के साथ
 
-Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+इसके बजाय कि आप फ्री-फॉर्म स्ट्रिंग्स असाइन करें, आप TokenStatus के लिए एक enum परिभाषित कर सकते हैं जिसमें विशिष्ट मान हों: OriginalOwner, SecondOwner, या ThirdOwner। enum का उपयोग करने से यह सुनिश्चित होता है कि केवल अनुमत मान ही उपयोग किए जाएं।
 
-Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+Enums प्रकार सुरक्षा प्रदान करते हैं, टाइपो के जोखिम को कम करते हैं, और सुनिश्चित करते हैं कि परिणाम लगातार और विश्वसनीय हों।
 
-## Defining Enums for NFT Marketplaces
+## NFT मार्केटप्लेस के लिए एन्उम्स को परिभाषित करना
 
 > Note: The following guide uses the CryptoCoven NFT smart contract.
 
@@ -78,15 +78,15 @@ enum Marketplace {
 }
 ```
 
-## Using Enums for NFT Marketplaces
+## NFT Marketplaces के लिए Enums का उपयोग
 
 Once defined, enums can be used throughout your subgraph to categorize transactions or events.
 
 For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
 
-### Implementing a Function for NFT Marketplaces
+### NFT मार्केटप्लेस के लिए एक फंक्शन लागू करना
 
-Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+यहाँ बताया गया है कि आप एक फ़ंक्शन को कैसे लागू कर सकते हैं जो enum से मार्केटप्लेस का नाम एक स्ट्रिंग के रूप में प्राप्त करता है:
 
 ```ts
 export function getMarketplaceName(marketplace: Marketplace): string {
@@ -104,22 +104,22 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 }
 ```
 
-## Best Practices for Using Enums
+## Enums का उपयोग करने के लिए सर्वोत्तम प्रथाएँ
 
-- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
+- सुसंगत नामकरण: पठनीयता को बेहतर बनाने के लिए enum मानों के लिए स्पष्ट, वर्णनात्मक नामों का उपयोग करें।
 - **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
-- **Documentation:** Add comments to enum to clarify their purpose and usage.
+- दस्तावेज़ीकरण: एनम में उनकी उद्देश्य और उपयोग को स्पष्ट करने के लिए टिप्पणियाँ जोड़ें।
 
-## Using Enums in Queries
+## क्वेरी में एन्नम्स का उपयोग करना
 
-Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+क्वेरी में Enums आपके डेटा की गुणवत्ता में सुधार करने और आपके परिणामों को समझने में आसान बनाने में मदद करते हैं। ये फ़िल्टर और प्रतिक्रिया तत्व के रूप में कार्य करते हैं, बाज़ार के मूल्यों में स्थिरता सुनिश्चित करते हैं और त्रुटियों को कम करते हैं।
 
-**Specifics**
+**विशिष्टताएँ**
 
-- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
-- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+- **Enums के साथ फ़िल्टरिंग:** Enums स्पष्ट फ़िल्टर प्रदान करते हैं, जिससे आप निश्चित रूप से विशिष्ट मार्केटप्लेस को शामिल या बाहर कर सकते हैं।
+- **प्रतिसादों में Enums:** एन्‍यम्‍स यह सुनिश्चित करते हैं कि केवल मान्यता प्राप्त मार्केटप्लेस नाम ही वापस आएं, जिससे परिणाम मानकीकृत और सटीक हों।
 
-### Sample Queries
+### नमूना क्वेरीज़
 
 #### Query 1: Account With The Highest NFT Marketplace Interactions
 

From ba2b774d1c461cc2331d17abfcf9a3aee5907dfb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 02:51:06 -0500
Subject: [PATCH 2903/3820] New translations overview.mdx (Hindi)

---
 website/pages/hi/indexing/overview.mdx | 113 +++++++++++++------------
 1 file changed, 58 insertions(+), 55 deletions(-)

diff --git a/website/pages/hi/indexing/overview.mdx b/website/pages/hi/indexing/overview.mdx
index abcb7c18263c..907605c5b10f 100644
--- a/website/pages/hi/indexing/overview.mdx
+++ b/website/pages/hi/indexing/overview.mdx
@@ -1,5 +1,5 @@
 ---
-title: Indexing Overview
+title: Indexing का अवलोकन
 ---
 
 Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
@@ -24,9 +24,10 @@ Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) i
 
 ### इंडेक्सिंग पुरस्कार कैसे वितरित किए जाते हैं?
 
-Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+प्रोटोकॉल मुद्रास्फीति से मिलने वाले indexing पुरस्कार 3% वार्षिक निर्गमन पर सेट किए गए हैं। इन्हें प्रत्येक subgraph पर कुल क्यूरेशन सिग्नल के अनुपात के आधार पर वितरित किया जाता है, और फिर Indexers को उनके उस subgraph पर आवंटित हिस्सेदारी के अनुपात में वितरित किया जाता है। पुरस्कार के लिए पात्र होने के लिए, एक आवंटन को 'proof of indexing (POI)' के साथ बंद किया जाना चाहिए जो कि 'arbitration charter' द्वारा निर्धारित मानकों को पूरा करता हो।
 
-Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+समुदाय द्वारा इनामों की गणना के लिए कई उपकरण बनाए गए हैं; आपको इनका संग्रह Community Guides
+collection(https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c) में संगठित रूप से मिलेगा। आप इन उपकरणों की एक अद्यतन सूची #Delegators और #Indexers चैनलों में Discord server(https://discord.gg/graphprotocol) पर भी पा सकते हैं। यहाँ हम एक recommended allocation optimiser(https://github.com/graphprotocol/allocation-optimizer) का लिंक देते हैं, जो indexer software stack के साथ एकीकृत है।
 
 ### इंडेक्सिंग (पीओआई) का सबूत क्या है?
 
@@ -58,28 +59,28 @@ query indexerAllocations {
 }
 ```
 
-Use Etherscan to call `getRewards()`:
+Etherscan का उपयोग करके getRewards() कॉल करें:
 
 - Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
 
 <!---->
 
-- To call `getRewards()`:
-  - Expand the **9. getRewards** dropdown.
-  - Enter the **allocationID** in the input.
-  - Click the **Query** button.
+- getRewards() को कॉल करने के लिए:
+  - **9. getRewards** ड्रॉपडाउन को विस्तार से खोलें।
+  - **allocationID** को इनपुट में दर्ज करें।
+  - **Query** बटन पर क्लिक करें।
 
 ### विवाद क्या हैं और मैं उन्हें कहां देख सकता हूं?
 
 विवाद की अवधि के दौरान इंडेक्सर की पूछताछ और आवंटन दोनों को ग्राफ़ पर विवादित किया जा सकता है। विवाद के प्रकार के आधार पर विवाद की अवधि अलग-अलग होती है। प्रश्न/सत्यापन में 7 युग विवाद विंडो हैं, जबकि आवंटन में 56 युग हैं। इन अवधियों के बीत जाने के बाद, आवंटन या प्रश्नों में से किसी के विरुद्ध विवाद नहीं खोला जा सकता है। जब कोई विवाद खोला जाता है, तो मछुआरों द्वारा न्यूनतम 10,000 जीआरटी की जमा राशि की आवश्यकता होती है, जो विवाद को अंतिम रूप देने और समाधान दिए जाने तक बंद रहेगा। मछुआरे कोई भी नेटवर्क प्रतिभागी हैं जो विवाद खोलते हैं।
 
-Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+विवादों के **तीन** संभावित परिणाम होते हैं, वैसे ही मछुआरों का जमा भी होता है।
 
 - यदि विवाद को खारिज कर दिया जाता है, तो मछुआरों द्वारा जमा किए गए जीआरटी को जला दिया जाएगा और विवादित इंडेक्सर को नहीं काटा जाएगा।
 - यदि विवाद ड्रा के रूप में सुलझाया जाता है, तो मछुआरों की जमा राशि वापस कर दी जाएगी, और विवादित इंडेक्सर को नहीं काटा जाएगा।
 - यदि विवाद स्वीकार किया जाता है, तो मछुआरों द्वारा जमा किया गया जीआरटी वापस कर दिया जाएगा, विवादित इंडेक्सर को घटा दिया जाएगा और मछुआरे घटे हुए जीआरटी का 50% अर्जित करेंगे।
 
-Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+विवादों को UI में एक Indexer के प्रोफ़ाइल पृष्ठ पर Disputes टैब के तहत देखा जा सकता है।
 
 ### प्रश्न शुल्क छूट क्या हैं और वे कब वितरित की जाती हैं?
 
@@ -91,9 +92,9 @@ Once an allocation has been closed the rebates are available to be claimed by th
 
 The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
 
-- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+- queryFeeCut - वह % जो query fee rebates का वितरण Indexer को किया जाएगा। अगर इसे 95% पर सेट किया जाता है, तो Indexer को वह query fees का 95% मिलेगा जो allocation बंद होने पर अर्जित होती है, जबकि बाकी का 5% Delegators को मिलेगा।
 
-- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+- **indexingRewardCut** - वह प्रतिशत जो indexing पुरस्कारों का होगा जिसे Indexer को वितरित किया जाएगा। यदि इसे 95% पर सेट किया गया है, तो Indexer को जब एक आवंटन बंद होगा, तो वह 95% indexing पुरस्कार प्राप्त करेगा और बाकी 5% को Delegators आपस में बांट लेंगे।
 
 ### इंडेक्सर्स कैसे जानते हैं कि इंडेक्स करने के लिए कौन से सबग्राफ हैं?
 
@@ -103,14 +104,14 @@ The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that
 
 - **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
 
-- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+- **Amount staked** - अन्य Indexers के व्यवहार की निगरानी करना या विशिष्ट subgraphs के लिए कुल स्टेक में आवंटित अनुपात को देखना एक Indexer को subgraph क्वेरीज़ के लिए आपूर्ति पक्ष की निगरानी करने की अनुमति दे सकता है, ताकि वे subgraphs की पहचान कर सकें जिनमें नेटवर्क विश्वास दिखा रहा है या ऐसे subgraphs जिन्हें अधिक आपूर्ति की आवश्यकता हो सकती है।
 
-- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+- **Subgraphs with no indexing rewards** - कुछ subgraphs में indexing rewards नहीं होते, मुख्य रूप से क्योंकि वे ऐसे unsupported features का उपयोग कर रहे होते हैं जैसे IPFS या क्योंकि वे mainnet के बाहर किसी अन्य नेटवर्क से query कर रहे होते हैं। यदि कोई subgraph indexing rewards नहीं जनरेट कर रहा है, तो आपको उस पर एक संदेश दिखाई देगा।
 
 ### हार्डवेयर आवश्यकताएँ क्या हैं?
 
 - **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
-- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
+- **मानक** - डिफ़ॉल्ट सेटअप, यही है जो उदाहरण k8s/terraform डिप्लॉयमेंट मैनिफेस्ट्स में उपयोग किया जाता है।
 - **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
 - **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
 
@@ -125,7 +126,7 @@ The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that
 
 - **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
 
-- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+- **फायरवॉल** - केवल Indexer सेवा को सार्वजनिक रूप से एक्सपोज़ किया जाना चाहिए और विशेष ध्यान प्रशासनिक पोर्ट्स और डेटाबेस एक्सेस को लॉक करने पर दिया जाना चाहिए: Graph Node JSON-RPC एंडपॉइंट (डिफ़ॉल्ट पोर्ट: 8030), Indexer प्रबंधन API एंडपॉइंट (डिफ़ॉल्ट पोर्ट: 18000), और Postgres डेटाबेस एंडपॉइंट (डिफ़ॉल्ट पोर्ट: 5432) को एक्सपोज़ नहीं किया जाना चाहिए।
 
 ## आधारभूत संरचना
 
@@ -141,7 +142,7 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 - **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
 
-- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+- **प्रोमेथियस मेट्रिक्स सर्वर** - The Graph Node और Indexer कंपोनेंट्स अपने मेट्रिक्स को मेट्रिक्स सर्वर पर लॉग करते हैं।
 
 नोट: फुर्तीली स्केलिंग का समर्थन करने के लिए, यह अनुशंसा की जाती है कि क्वेरी और इंडेक्सिंग चिंताओं को नोड्स के विभिन्न सेटों के बीच अलग किया जाए: क्वेरी नोड्स और इंडेक्स नोड्स।
 
@@ -168,9 +169,9 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 #### Indexer Agent
 
-| Port | Purpose                | Routes | CLI Argument               | Environment Variable                    |
-| ---- | ---------------------- | ------ | -------------------------- | --------------------------------------- |
-| 8000 | Indexer management API | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+| Port | उद्देश्य                | Routes | CLI आर्ग्युमेंट              | एनवायरनमेंट वेरिएबल                     |
+| ---- | ----------------------- | ------ | ---------------------------- | --------------------------------------- |
+| 8000 | Indexer management API  | /      | \--indexer-management-port   | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
 
 ### Google क्लाउड पर टेराफॉर्म का उपयोग करके सर्वर इंफ्रास्ट्रक्चर सेटअप करें
 
@@ -184,9 +185,9 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 #### एक Google क्लाउड प्रोजेक्ट बनाएं
 
-- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+- [Indexer repository](https://github.com/graphprotocol/indexer). को क्लोन करें या नेविगेट करें।
 
-- Navigate to the `./terraform` directory, this is where all commands should be executed.
+- `./terraform` निर्देशिका पर जाएं, यहीं पर सभी कमांड्स को निष्पादित किया जाना चाहिए।
 
 ```sh
 cd terraform
@@ -226,10 +227,10 @@ gcloud services enable sqladmin.googleapis.com
 ```sh
 svc_name=<SERVICE_ACCOUNT_NAME>
 gcloud iam service-accounts create $svc_name \
-  --description="Service account for Terraform" \
+  --description="Terraform के लिए सेवा खाता" \
   --display-name="$svc_name"
 gcloud iam service-accounts list
-# Get the email of the service account from the list
+#सूची से सेवा खाते का ईमेल प्राप्त करें
 svc=$(gcloud iam service-accounts list --format='get(email)'
 --filter="displayName=$svc_name")
 gcloud iam service-accounts keys create .gcloud-credentials.json \
@@ -266,7 +267,7 @@ EOF
 
 #### इंफ्रास्ट्रक्चर बनाने के लिए टेराफॉर्म का इस्तेमाल करें
 
-Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+किसी भी कमांड को चलाने से पहले, [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) को पढ़ें और इस डायरेक्टरी में एक फाइल terraform.tfvars बनाएं (या उस फाइल को संशोधित करें जो हमने पिछले चरण में बनाई थी)। प्रत्येक वेरिएबल के लिए, जहाँ आप डिफ़ॉल्ट को ओवरराइड करना चाहते हैं, या जहाँ आपको एक मान सेट करना है, terraform.tfvars में एक सेटिंग दर्ज करें।
 
 - इन्फ्रास्ट्रक्चर बनाने के लिए निम्नलिखित कमांड चलाएँ।
 
@@ -281,7 +282,7 @@ terraform plan
 terraform apply
 ```
 
-Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+नए क्लस्टर के लिए क्रेडेंशियल्स को `~/.kube/config` में डाउनलोड करें और इसे अपना डिफ़ॉल्ट कॉन्टेक्स्ट सेट करें।
 
 ```sh
 gcloud container clusters get-credentials $indexer
@@ -291,11 +292,11 @@ kubectl config use-context $(kubectl config get-contexts --output='name'
 
 #### इंडेक्सर के लिए कुबेरनेट्स घटक बनाना
 
-- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+- `k8s/overlays` डायरेक्टरी को एक नई डायरेक्टरी `$dir` में कॉपी करें, और `$dir/kustomization.yaml` में `bases` एंट्री को इस तरह से एडजस्ट करें कि वह `k8s/base` डायरेक्टरी की ओर पॉइंट करे।
 
-- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+- `$dir` में सभी फाइलों को पढ़ें और किसी भी मान को उन टिप्पणियों में दिए गए निर्देशों के अनुसार समायोजित करें।
 
-Deploy all resources with `kubectl apply -k $dir`.
+सभी संसाधनों को $dir के साथ kubectl apply -k का उपयोग करके डिप्लॉय करें।
 
 ### ग्राफ-नोड
 
@@ -342,7 +343,8 @@ cargo run -p graph-node --release -- \
 
 #### आवश्यक शर्तें
 
-- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+- **Ethereum नोड**-डिफ़ॉल्ट रूप से, डॉकर-कंपोज़ सेटअप मुख्यनेट का उपयोग करेगा: [http://host.docker.internal:8545] 
+  (http://host.docker.internal:8545)आपके होस्ट मशीन पर Ethereum नोड से कनेक्ट होने के लिए। आप `docker-compose.yaml` को अपडेट करके इस नेटवर्क नाम और URL को बदल सकते हैं।
 
 #### Setup
 
@@ -353,7 +355,7 @@ git clone https://github.com/graphprotocol/graph-node
 cd graph-node/docker
 ```
 
-2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+2. केवल Linux उपयोगकर्ताओं के लिए - `docker-compose.yaml` में `host.docker.internal` की बजाय होस्ट IP एड्रेस का उपयोग करें, दिए गए स्क्रिप्ट का उपयोग करते हुए।
 
 ```sh
 ./setup.sh
@@ -434,12 +436,12 @@ docker pull ghcr.io/graphprotocol/indexer-agent:latest
 या स्रोत से स्थानीय रूप से छवियां बनाएं
 
 ```sh
-# Indexer service
+#इंडेक्सर सेवा
 docker build \
   --build-arg NPM_TOKEN=<npm-token> \
   -f Dockerfile.indexer-service \
   -t indexer-service:latest \
-# Indexer agent
+इंडेक्सर एजेंट
 docker build \
   --build-arg NPM_TOKEN=<npm-token> \
   -f Dockerfile.indexer-agent \
@@ -453,15 +455,15 @@ docker run -p 7600:7600 -it indexer-service:latest ...
 docker run -p 18000:8000 -it indexer-agent:latest ...
 ```
 
-**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+**नोट**: कंटेनरों को शुरू करने के बाद, Indexer सेवा [http://localhost:7600](http://localhost:7600) पर उपलब्ध होगी और Indexer एजेंट [http://localhost:18000/](http://localhost:18000/) पर Indexer प्रबंधन API को एक्सपोज़ करेगा।
 
 #### K8s और टेराफॉर्म का उपयोग करना
 
-See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+[Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) अनुभाग देखें।
 
 #### Usage
 
-> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+> **नोट**: सभी रनटाइम कॉन्फ़िगरेशन वेरिएबल्स को या तो स्टार्टअप पर कमांड के पैरामीटर के रूप में लागू किया जा सकता है या `COMPONENT_NAME_VARIABLE_NAME `(जैसे, `INDEXER_AGENT_ETHEREUM`) प्रारूप के पर्यावरण वेरिएबल्स का उपयोग करके।
 
 #### इंडेक्सर एजेंट
 
@@ -520,7 +522,7 @@ graph-indexer-service start \
 
 #### Indexer CLI
 
-The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+Indexer CLI [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli)  का एक प्लगइन है जो टर्मिनल में `graph indexer` के रूप में एक्सेस किया जा सकता है।
 
 ```sh
 graph indexer connect http://localhost:18000
@@ -529,45 +531,46 @@ graph indexer status
 
 #### इंडेक्सर सीएलआई का उपयोग कर इंडेक्सर प्रबंधन
 
-The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+**Indexer Management API** के साथ इंटरैक्ट करने के लिए सुझाया गया टूल **Indexer CLI** है, जो कि **Graph CLI** का एक विस्तार है। Indexer agent को नेटवर्क के साथ स्वतःसंपर्क स्थापित करने के लिए एक Indexer से इनपुट की आवश्यकता होती है। Indexer agent के व्यवहार को परिभाषित करने के लिए मुख्य तंत्र **allocation management** मोड और **indexing rules** हैं।ऑटो मोड में, एक Indexer अपने विशिष्ट रणनीति का उपयोग करके उन सबग्राफ को चुनने और क्वेरी सर्व करने के लिए **indexing rules** का उपयोग कर सकता है। इन नियमों को एक GraphQL API के माध्यम से प्रबंधित किया जाता है जिसे एजेंट द्वारा सर्व किया जाता है और जिसे Indexer Management API के रूप में जाना जाता है।मैनुअल मोड में, एक Indexer **actions queue** का उपयोग करके allocation actions बना सकता है और उनके निष्पादन से पहले उन्हें स्पष्ट रूप से स्वीकृत कर सकता है।ऑवरसाइट मोड में, **indexing rules** का उपयोग **actions queue** को भरने के लिए किया जाता है और उनके निष्पादन के लिए भी स्पष्ट स्वीकृति की आवश्यकता होती है।
 
 #### Usage
 
-The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+**Indexer CLI** Indexer agent से जुड़ता है, आमतौर पर पोर्ट-फॉरवर्डिंग के माध्यम से, इसलिए CLI को उसी सर्वर या क्लस्टर पर चलाने की आवश्यकता नहीं होती। आपको आरंभ करने में सहायता करने और कुछ संदर्भ प्रदान करने के लिए, CLI का संक्षिप्त विवरण यहां दिया जाएगा।
 
-- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+- `graph indexer connect <url>` - Indexer प्रबंधन API से कनेक्ट करें। आमतौर पर, सर्वर से कनेक्शन पोर्ट फॉरवर्डिंग के माध्यम से खोला जाता है, जिससे CLI को आसानी से रिमोटली ऑपरेट किया जा सके। (उदाहरण: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
 
-- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - एक या एक से अधिक indexing rules प्राप्त करें, `<deployment-id>` के रूप में all का उपयोग करके सभी rules प्राप्त करें, या `global` का उपयोग करके global defaults प्राप्त करें। एक अतिरिक्त argument --`merged` का उपयोग किया जा सकता है यह निर्दिष्ट करने के लिए कि deployment-specific rules को global rule के साथ merge किया गया है। इसी तरह से इन्हें Indexer agent में लागू किया जाता है।
 
-- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - एक या अधिक indexing नियम सेट करें।
 
 - `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
 
-- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+- `graph indexer rules stop [options] <deployment-id>` - किसी परिनियोजन की indexing रोकें और इसके `decisionBasis` को कभी नहीं पर सेट करें, ताकि यह deployment को index करने के निर्णय लेते समय इसे छोड़ दे।
 
-- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+- `graph indexer rules maybe [options] <deployment-id>` — किसी डिप्लॉयमेंट के लिए `decisionBasis` को rules पर सेट करें, ताकि Indexer agent इस डिप्लॉयमेंट को इंडेक्स करने का निर्णय लेने के लिए indexing rules का उपयोग कर सके।
 
-- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+- `graph indexer actions get [options] <action-id>` - `all` का उपयोग करके एक या अधिक कार्यवाही को प्राप्त करें या सभी कार्यवाही प्राप्त करने के लिए `action-id` खाली छोड़ दें। एक अतिरिक्त argument --`status` का उपयोग किसी विशेष स्थिति के सभी कार्यवाही को प्रिंट करने के लिए किया जा सकता है।
 
-- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - आवंटन क्रिया को कतार में डालें
 
-- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - पुनः आवंटन क्रिया को कतार में जोड़ें
 
-- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - अनवेलोकेट कार्रवाई को कतार में लगाएं
 
-- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+- `graph indexer actions cancel [<action-id> ...]` - यदि आईडी निर्दिष्ट नहीं है, तो कतार में सभी कार्रवाई रद्द करें, अन्यथा आईडी की सूची को स्पेस द्वारा अलग करके रद्द करें।
 
-- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+- `graph indexer actions approve [<action-id> ...]` - एक से अधिक क्रियाओं को निष्पादन के लिए अनुमोदित करें
 
-- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+- `graph indexer actions execute approve` - वर्कर को स्वीकृत क्रियाओं को तुरंत निष्पादित करने के लिए मजबूर करें।
 
 All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
 
 #### Indexing rules
 
-Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+Indexing नियम या तो वैश्विक डिफ़ॉल्ट के रूप में लागू किए जा सकते हैं या विशिष्ट subgraph डिप्लॉयमेंट्स के लिए उनके ID का उपयोग करके। `deployment` और `decisionBasis` फ़ील्ड्स अनिवार्य हैं, जबकि अन्य सभी फ़ील्ड्स वैकल्पिक हैं। जब एक इंडेक्सिंग नियम में rules को `decisionBasis` के रूप में सेट किया जाता है, तो Indexer एजेंट उस नियम पर गैर-नल थ्रेशहोल्ड मानों की तुलना करेगा, जो नेटवर्क से संबंधित डिप्लॉयमेंट के लिए प्राप्त मानों से की जाएगी। यदि subgraph डिप्लॉयमेंट के मान किसी भी थ्रेशहोल्ड से ऊपर (या नीचे) होते हैं, तो उसे indexing के लिए चुना जाएगा।
 
-For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+उदाहरण के लिए, यदि वैश्विक नियम का `minStake` **5** (GRT) है, तो कोई भी subgraph डिप्लॉयमेंट जिसमें 5 (GRT) से अधिक staking आवंटित किया गया हो, उसे इंडेक्स किया जाएगा। थ्रेशोल्ड नियमों में 
+`maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, और `minAverageQueryFees` शामिल हैं।
 
 डेटा मॉडल:
 
@@ -617,9 +620,9 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 #### Actions queue CLI
 
-The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+indexer-cli एक `actions` मॉड्यूल प्रदान करता है जो एक्शन क्यू के साथ मैन्युअल रूप से काम करने के लिए उपयोग किया जाता है। यह **Graphql API** का उपयोग करता है जो एक्शन क्यू के साथ इंटरैक्ट करने के लिए indexer प्रबंधन सर्वर द्वारा होस्ट किया जाता है।
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+यह क्रिया निष्पादन कार्यकर्ता केवल उन आइटमों को कतार से निष्पादित करेगा जिनका `ActionStatus = approved` है। अनुशंसित मार्ग में क्रियाएँ कतार में ActionStatus = queued के साथ जोड़ी जाती हैं, इसलिए उन्हें फिर से स्वीकृत करना होता है ताकि उन्हें ऑनचेन पर निष्पादित किया जा सके। सामान्य प्रवाह इस प्रकार होगा:
 
 - तृतीय पक्ष ऑप्टिमाइज़र टूल या इंडेक्सर-क्ली उपयोगकर्ता द्वारा कतार में जोड़ी गई कार्रवाई
 - Indexer can use the `indexer-cli` to view all queued actions

From 6c9124494a8159ae4df7a2b7d6fc04ac8c8203f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 02:51:08 -0500
Subject: [PATCH 2904/3820] New translations enums.mdx (Hindi)

---
 website/pages/hi/subgraphs/cookbook/enums.mdx | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/hi/subgraphs/cookbook/enums.mdx b/website/pages/hi/subgraphs/cookbook/enums.mdx
index 37910ff3a152..3acf87d26b28 100644
--- a/website/pages/hi/subgraphs/cookbook/enums.mdx
+++ b/website/pages/hi/subgraphs/cookbook/enums.mdx
@@ -110,7 +110,7 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 - **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
 - दस्तावेज़ीकरण: एनम में उनकी उद्देश्य और उपयोग को स्पष्ट करने के लिए टिप्पणियाँ जोड़ें।
 
-## क्वेरी में एन्नम्स का उपयोग करना
+## Using Enums in Queries
 
 क्वेरी में Enums आपके डेटा की गुणवत्ता में सुधार करने और आपके परिणामों को समझने में आसान बनाने में मदद करते हैं। ये फ़िल्टर और प्रतिक्रिया तत्व के रूप में कार्य करते हैं, बाज़ार के मूल्यों में स्थिरता सुनिश्चित करते हैं और त्रुटियों को कम करते हैं।
 
@@ -119,14 +119,14 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 - **Enums के साथ फ़िल्टरिंग:** Enums स्पष्ट फ़िल्टर प्रदान करते हैं, जिससे आप निश्चित रूप से विशिष्ट मार्केटप्लेस को शामिल या बाहर कर सकते हैं।
 - **प्रतिसादों में Enums:** एन्‍यम्‍स यह सुनिश्चित करते हैं कि केवल मान्यता प्राप्त मार्केटप्लेस नाम ही वापस आएं, जिससे परिणाम मानकीकृत और सटीक हों।
 
-### नमूना क्वेरीज़
+### Sample Queries
 
-#### Query 1: Account With The Highest NFT Marketplace Interactions
+#### Query 1: सबसे अधिक NFT मार्केटप्लेस इंटरएक्शन वाला खाता
 
 This query does the following:
 
-- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
-- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+- यह खाते को खोजता है जिसमें सबसे अधिक अनूठे NFT मार्केटप्लेस इंटरैक्शन होते हैं, जो क्रॉस-मार्केटप्लेस गतिविधि का विश्लेषण करने के लिए बेहतरीन है।
+- मार्केटप्लेस फील्ड marketplace एनम का उपयोग करता है, जो प्रतिक्रिया में सुसंगत और मान्य मार्केटप्लेस मान सुनिश्चित करता है।
 
 ```gql
 {
@@ -143,9 +143,9 @@ This query does the following:
 }
 ```
 
-#### Returns
+#### रिटर्न्स
 
-This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+यह प्रतिक्रिया खाता विवरण और मानकीकृत स्पष्टता के लिए एनम मानों के साथ अद्वितीय मार्केटप्लेस इंटरैक्शन्स की सूची प्रदान करती है:
 
 ```gql
 {
@@ -191,7 +191,7 @@ This response provides account details and a list of unique marketplace interact
 This query does the following:
 
 - It identifies the marketplace with the highest volume of CryptoCoven transactions.
-- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+- यह मार्केटप्लेस enum का उपयोग करता है ताकि प्रतिक्रिया में केवल मान्य मार्केटप्लेस प्रकार ही दिखाई दें, जिससे आपके डेटा में विश्वसनीयता और स्थिरता बनी रहती है।
 
 ```gql
 {
@@ -202,7 +202,7 @@ This query does the following:
 }
 ```
 
-#### Result 2
+#### परिणाम 2
 
 The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
 
@@ -224,7 +224,7 @@ The expected response includes the marketplace and the corresponding transaction
 This query does the following:
 
 - It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
-- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+- यह केवल वैध मार्केटप्लेस प्रकारों को शामिल करने के लिए फ़िल्टर के रूप में एंनम का उपयोग करता है, जिससे सटीकता बढ़ती है।
 
 ```gql
 {
@@ -240,9 +240,9 @@ This query does the following:
 }
 ```
 
-#### Result 3
+#### परिणाम 3
 
-Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+अपेक्षित आउटपुट में उन मार्केटप्लेस का समावेश है जो मानदंडों को पूरा करते हैं, प्रत्येक को एक enum मान द्वारा प्रदर्शित किया जाता है:
 
 ```gql
 {

From 761101313040e9f0b1f19044a248979ccd9765cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 02:51:09 -0500
Subject: [PATCH 2905/3820] New translations transfer-to-the-graph.mdx (Hindi)

---
 .../cookbook/transfer-to-the-graph.mdx        | 48 +++++++++----------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx
index cf3381b17419..a750211bfa2b 100644
--- a/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -1,22 +1,22 @@
 ---
-title: Tranfer to The Graph
+title: The Graph पर ट्रांसफर करें
 ---
 
-Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+अपने subgraphs को किसी भी प्लेटफ़ॉर्म से The Graph's decentralized network(https://thegraph.com/networks/) में जल्दी से अपग्रेड करें।
 
-## Benefits of Switching to The Graph
+## The Graph पर स्विच करने के लाभ
 
-- Use the same subgraph that your apps already use with zero-downtime migration.
-- Increase reliability from a global network supported by 100+ Indexers.
+- आपके ऐप्स द्वारा पहले से उपयोग किए जा रहे वही subgraph को बिना किसी डाउनटाइम के माइग्रेशन के लिए उपयोग करें।
+- 100+ Indexers द्वारा समर्थित एक वैश्विक नेटवर्क से विश्वसनीयता बढ़ाएं।
 - Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
 
-## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+## अपने Subgraph को The Graph में 3 आसान कदमों में अपग्रेड करें
 
 1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
 2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
 3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
 
-## 1. Set Up Your Studio Environment
+## 1. अपने स्टूडियो वातावरण को सेट करें
 
 ### Create a Subgraph in Subgraph Studio
 
@@ -25,11 +25,11 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 
 > Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
 
-### Install the Graph CLI⁠
+### Graph CLI स्थापित करें
 
-You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+आपको Node.js(https://nodejs.org/) और अपनी पसंद का पैकेज मैनेजर (npm या pnpm) इंस्टॉल करना होगा ताकि आप Graph CLI का उपयोग कर सकें। सबसे हालिया(https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI संस्करण चेक करें।
 
-On your local machine, run the following command:
+अपने लोकल मशीन पर, निम्नलिखित कमांड चलाएँ:
 
 Using [npm](https://www.npmjs.com/):
 
@@ -37,36 +37,36 @@ Using [npm](https://www.npmjs.com/):
 npm install -g @graphprotocol/graph-cli@latest
 ```
 
-Use the following command to create a subgraph in Studio using the CLI:
+इस कमांड का उपयोग करें और CLI का उपयोग करके Studio में एक subgraph बनाएँ:
 
 ```sh
 graph init --product subgraph-studio
 ```
 
-### Authenticate Your Subgraph
+### अपने Subgraph को प्रमाणित करें
 
-In The Graph CLI, use the auth command seen in Subgraph Studio:
+The Graph CLI में, 'auth' कमांड का उपयोग करें जो Subgraph Studio में देखा गया है:
 
 ```sh
 graph auth <your-auth-code>
 ```
 
-## 2. Deploy Your Subgraph to Studio
+## 2. अपने Subgraph को Studio पर डिप्लॉय करें
 
-If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+यदि आपके पास अपना सोर्स कोड है, तो आप इसे आसानी से Studio में डिप्लॉय कर सकते हैं। यदि आपके पास यह नहीं है, तो यहां एक त्वरित तरीका है अपनी subgraph को डिप्लॉय करने का।
 
-In The Graph CLI, run the following command:
+The Graph CLI में, निम्नलिखित कमांड चलाएँ:
 
 ```sh
 graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
 
 ```
 
-> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+> नोट: प्रत्येक subgraph का एक IPFS हैश (Deployment ID) होता है, जो इस प्रकार दिखता है: "Qmasdfad...". बस इसे deploy करने के लिए इस IPFS हैश का उपयोग करें। आपको एक संस्करण दर्ज करने के लिए कहा जाएगा (जैसे, v0.0.1)।
 
-## 3. Publish Your Subgraph to The Graph Network
+## 3. अपने Subgraph को The Graph Network पर प्रकाशित करें
 
-![publish button](/img/publish-sub-transfer.png)
+![पब्लिश बटन](/img/publish-sub-transfer.png)
 
 ### Query Your Subgraph
 
@@ -86,19 +86,19 @@ The query URL for this subgraph is:
 https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
 ```
 
-Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+अब, आपको केवल अपना API Key भरने की आवश्यकता है ताकि आप इस endpoint पर GraphQL queries भेज सकें।
 
-### Getting your own API Key
+### अपनी खुद की API Key प्राप्त करना
 
-You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+आप Subgraph Studio में पृष्ठ के शीर्ष पर “API Keys” मेनू के तहत API Keys बना सकते हैं:
 
 ![API keys](/img/Api-keys-screenshot.png)
 
 ### Monitor Subgraph Status
 
-Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+एक बार जब आप अपग्रेड करते हैं, तो आप Subgraph Studio(https://thegraph.com/studio/) में अपने सबग्राफ्स को एक्सेस और प्रबंधित कर सकते हैं और The Graph Explorer(https://thegraph.com/networks/) में सभी सबग्राफ्स को एक्सप्लोर कर सकते हैं।
 
 ### Additional Resources
 
 - To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
-- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).
+- आप अपने subgraph के प्रदर्शन को बेहतर बनाने के लिए इसे अनुकूलित और कस्टमाइज़ करने के सभी तरीकों का पता लगाने के लिए, creating a subgraph here(/developing/creating-a-subgraph/) पर और पढ़ें।

From 5b0f77b783a29a66df3f747d7aa02530e0b05ef5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 02:51:11 -0500
Subject: [PATCH 2906/3820] New translations best-practices.mdx (Hindi)

---
 website/pages/hi/subgraphs/querying/best-practices.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/subgraphs/querying/best-practices.mdx b/website/pages/hi/subgraphs/querying/best-practices.mdx
index 0a3110ebff92..f70313fa64e4 100644
--- a/website/pages/hi/subgraphs/querying/best-practices.mdx
+++ b/website/pages/hi/subgraphs/querying/best-practices.mdx
@@ -189,9 +189,9 @@ const result = await execute(query, {
 
 ### आप जो चाहते हैं वह मांगें
 
-GraphQL became famous for its "Ask for what you want" tagline.
+GraphQL अपने “Ask for what you want” टैगलाइन के लिए प्रसिद्ध हुआ।
 
-For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+इस कारण, GraphQL में सभी उपलब्ध फ़ील्ड्स को बिना उन्हें व्यक्तिगत रूप से सूचीबद्ध किए प्राप्त करने का कोई तरीका नहीं है।
 
 - When querying GraphQL APIs, always think of querying only the fields that will be actually used.
 - सुनिश्चित करें कि क्वेरीज़ केवल उतने ही एंटिटीज़ लाएँ जितनी आपको वास्तव में आवश्यकता है। डिफ़ॉल्ट रूप से, क्वेरीज़ एक संग्रह में 100 एंटिटीज़ लाएँगी, जो आमतौर पर उपयोग में लाई जाने वाली मात्रा से अधिक होती है, जैसे कि उपयोगकर्ता को प्रदर्शित करने के लिए। यह न केवल एक क्वेरी में शीर्ष-स्तरीय संग्रहों पर लागू होता है, बल्कि एंटिटीज़ के नेस्टेड संग्रहों पर भी अधिक लागू होता है।

From 96e71d09da8facd783a56a89c867ead4b0b2acf5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 05:10:48 -0500
Subject: [PATCH 2907/3820] New translations overview.mdx (Hindi)

---
 website/pages/hi/indexing/overview.mdx | 46 +++++++++++++-------------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/website/pages/hi/indexing/overview.mdx b/website/pages/hi/indexing/overview.mdx
index 907605c5b10f..6b13a24d9537 100644
--- a/website/pages/hi/indexing/overview.mdx
+++ b/website/pages/hi/indexing/overview.mdx
@@ -625,10 +625,10 @@ indexer-cli एक `actions` मॉड्यूल प्रदान करत
 यह क्रिया निष्पादन कार्यकर्ता केवल उन आइटमों को कतार से निष्पादित करेगा जिनका `ActionStatus = approved` है। अनुशंसित मार्ग में क्रियाएँ कतार में ActionStatus = queued के साथ जोड़ी जाती हैं, इसलिए उन्हें फिर से स्वीकृत करना होता है ताकि उन्हें ऑनचेन पर निष्पादित किया जा सके। सामान्य प्रवाह इस प्रकार होगा:
 
 - तृतीय पक्ष ऑप्टिमाइज़र टूल या इंडेक्सर-क्ली उपयोगकर्ता द्वारा कतार में जोड़ी गई कार्रवाई
-- Indexer can use the `indexer-cli` to view all queued actions
-- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
-- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
-- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- Indexer `indexer-cli` का उपयोग करके सभी कतारबद्ध क्रियाएं देख सकता है।
+- Indexer (या अन्य सॉफ़्टवेयर) `indexer-cli` का उपयोग करके क्यू में क्रियाओं को स्वीकृत या रद्द कर सकता है। स्वीकृत और रद्द करने के आदेश एक्शन आईडी की एक सूची को इनपुट के रूप में लेते हैं।
+- निष्पादन कार्यकर्ता नियमित रूप से स्वीकृत क्रियाओं के लिए कतार को पोल करता है। यह कतार से `approved` क्रियाओं को उठाएगा, उन्हें निष्पादित करने का प्रयास करेगा, और निष्पादन की स्थिति के आधार पर db में मानों को `success` या `failed` के रूप में अपडेट करेगा।
+- अगर कोई क्रिया सफल होती है, तो कार्यकर्ता यह सुनिश्चित करेगा कि एक indexing नियम मौजूद हो जो एजेंट को आगे बढ़ने के लिए आवंटन को कैसे प्रबंधित करना है, यह तब उपयोगी होता है जब एजेंट `auto` या `oversight` मोड में होते हुए मैन्युअल क्रियाएँ करता है।
 - अनुक्रमणक क्रिया निष्पादन के इतिहास को देखने के लिए क्रिया कतार की निगरानी कर सकता है और यदि आवश्यक हो तो निष्पादन विफल होने पर क्रिया आइटम को पुन: अनुमोदित और अद्यतन कर सकता है। क्रिया कतार पंक्तिबद्ध और की गई सभी कार्रवाइयों का इतिहास प्रदान करती है।
 
 डेटा मॉडल:
@@ -686,13 +686,13 @@ graph indexer actions execute approve
 
 ध्यान दें कि आवंटन प्रबंधन के लिए समर्थित क्रिया प्रकारों की अलग-अलग इनपुट आवश्यकताएं होती हैं:
 
-- `Allocate` - allocate stake to a specific subgraph deployment
+- `Allocate` - विशिष्ट subgraph deployment को staking आवंटित करें
 
   - आवश्यक क्रिया पैरामीटर:
     - deploymentID
     - amount
 
-- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+- `Unallocate` - आवंटन बंद करना, फिर से कहीं और पुनः आवंटित करने के लिए दांव को मुक्त करना
 
   - आवश्यक क्रिया पैरामीटर:
     - allocationID
@@ -701,7 +701,7 @@ graph indexer actions execute approve
     - poi
     - बल (प्रदान किए गए POI का उपयोग करने पर बल देता है, भले ही वह ग्राफ़-नोड द्वारा प्रदान किए गए मेल से मेल न खाता हो)
 
-- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+- `Reallocate` - परमाणु रूप से आवंटन को बंद करें और उसी subgraph परिनियोजन के लिए एक नया आवंटन खोलें।
 
   - आवश्यक क्रिया पैरामीटर:
     - allocationID
@@ -739,7 +739,7 @@ default => 0.1 * $SYSTEM_LOAD;
 | Query                                                                        | Price   |
 | ---------------------------------------------------------------------------- | ------- |
 | &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
-| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
+| &#123; टोकन &#123; symbol &#125; &#125;                                      | 0.1 GRT |
 | &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
 
 #### लागत मॉडल लागू करना
@@ -759,39 +759,39 @@ The first steps to participating in the network as an Indexer are to approve the
 
 > Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
 
-Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+एक बार जब Indexer ने प्रोटोकॉल में GRT को staked कर दिया है, तो [Indexer components](/indexing/overview/#indexer-components) को शुरू किया जा सकता है और वे नेटवर्क के साथ अपनी बातचीत शुरू कर सकते हैं।
 
 #### टोकन स्वीकृत करें
 
-1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+1. [Remix app](https://remix.ethereum.org/) को ब्राउज़र में खोलें।
 
-2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+2. `File Explorer` में एक फाइल बनाएँ जिसका नाम **GraphToken.abi** हो, और उसमें [टोकनABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json) का उपयोग करें।
 
 3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
 
-4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+4. पर्यावरण के अंतर्गत `Injected Web3` चुनें और `Account` के अंतर्गत अपना Indexer पता चुनें।
 
-5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+5. GraphToken contract address सेट करें - GraphToken contract address (0xc944E90C64B2c07662A292be6244BDf05Cda44a7) को `At Address` के पास पेस्ट करें और इसे लागू करने के लिए `At address` बटन पर क्लिक करें।
 
-6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+6. `approve(spender, amount)` फ़ंक्शन को कॉल करें ताकि Staking contract को अप्रूव किया जा सके। `spender` में Staking contract address (0xF55041E37E12cD407ad00CE2910B8269B01263b9) भरें और `amount` में staking करने वाले टोकन की मात्रा (wei में) भरें।
 
 #### स्टेक टोकन
 
-1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+1. [Remix app](https://remix.ethereum.org/) को ब्राउज़र में खोलें।
 
-2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+2. `File Explorer` में एक फाइल बनाएं जिसका नाम **Staking.abi** हो और इसमें staking ABI हो।
 
 3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
 
-4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+4. पर्यावरण के तहत `Injected Web3` का चयन करें और `Account` के तहत अपने Indexer पते का चयन करें।
 
-5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+5. Staking contract address सेट करें - Staking contract address (0xF55041E37E12cD407ad00CE2910B8269B01263b9) को `At Address` के पास पेस्ट करें और `At address` बटन पर क्लिक करें ताकि इसे लागू किया जा सके।
 
 6. Call `stake()` to stake GRT in the protocol.
 
-7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+7. (ऐच्छिक) Indexer अपने Indexer इंफ्रास्ट्रक्चर के लिए किसी अन्य पते को ऑपरेटर के रूप में अनुमोदित कर सकते हैं, ताकि वे फंड्स को नियंत्रित करने वाली चाबियों को उन चाबियों से अलग कर सकें जो रोज़मर्रा के कार्यों को अंजाम देती हैं जैसे कि सबग्राफ पर आवंटन और (भुगतान) queries सर्व करना। ऑपरेटर सेट करने के लिए `setOperator()` को ऑपरेटर पते के साथ कॉल करें।
 
-8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+8. (वैकल्पिक) इनामों के वितरण को नियंत्रित करने और रणनीतिक रूप से Delegators को आकर्षित करने के लिए Indexers अपनी delegation parameters को अपडेट कर सकते हैं, जैसे कि indexingRewardCut (भाग प्रति मिलियन), queryFeeCut (भाग प्रति मिलियन), और cooldownBlocks (ब्लॉकों की संख्या)। ऐसा करने के लिए `setDelegationParameters()` को कॉल करें। निम्नलिखित उदाहरण में queryFeeCut को सेट किया गया है ताकि query rebates का 95% Indexer को और 5% Delegators को वितरित किया जाए, indexingRewardCut को सेट किया गया है ताकि indexing rewards का 60% Indexer को और 40% Delegators को वितरित किया जाए, और `thecooldownBlocks` अवधि को 500 ब्लॉकों पर सेट किया गया है।
 
 ```
 setDelegationParameters(950000, 600000, 500)
@@ -799,13 +799,13 @@ setDelegationParameters(950000, 600000, 500)
 
 ### Setting delegation parameters
 
-The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+`setDelegationParameters()` फ़ंक्शन [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) में Indexers के लिए महत्वपूर्ण है, क्योंकि यह उन्हें ऐसे पैरामीटर सेट करने की अनुमति देता है जो उनके Delegators के साथ इंटरएक्शन को परिभाषित करते हैं, जिससे उनके पुरस्कार वितरण और डेलीगेशन क्षमता पर प्रभाव पड़ता है।
 
 ### How to set delegation parameters
 
 To set the delegation parameters using Graph Explorer interface, follow these steps:
 
-1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+1. [Graph Explorer](https://thegraph.com/explorer/) पर जाएं।
 2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
 3. Connect the wallet you have as a signer.
 4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
@@ -815,7 +815,7 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 ### आवंटन का जीवन
 
-After being created by an Indexer a healthy allocation goes through two states.
+एक Indexer द्वारा बनाए जाने के बाद, एक स्वस्थ आवंटन दो स्थितियों से गुजरता है।
 
 - **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
 

From a1fc3b224cd8a7d9cfdf977941619589011d3e53 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 05:10:50 -0500
Subject: [PATCH 2908/3820] New translations graph-node.mdx (Hindi)

---
 .../pages/hi/indexing/tooling/graph-node.mdx  | 32 +++++++++----------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/hi/indexing/tooling/graph-node.mdx b/website/pages/hi/indexing/tooling/graph-node.mdx
index 3ee68e49d3a0..57148adf7586 100644
--- a/website/pages/hi/indexing/tooling/graph-node.mdx
+++ b/website/pages/hi/indexing/tooling/graph-node.mdx
@@ -71,7 +71,7 @@ cargo run -p graph-node --release -- \
 
 ### Getting started with Kubernetes
 
-A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+Kubernetes का एक पूर्ण उदाहरण कॉन्फ़िगरेशन [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s) में पाया जा सकता है।
 
 ### Ports
 
@@ -95,11 +95,11 @@ This setup can be scaled horizontally, by adding multiple Graph Nodes, and multi
 
 ### `config.toml`
 
-A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+A [TOML](https://toml.io/en/) कॉन्फ़िगरेशन फ़ाइल का उपयोग CLI में उजागर किए गए अधिक जटिल कॉन्फ़िगरेशन सेट करने के लिए किया जा सकता है। फ़ाइल का स्थान --config कमांड लाइन स्विच के साथ पास किया जाता है।
 
 > कॉन्फ़िगरेशन फ़ाइल का उपयोग करते समय, --postgres-url, --postgres-secondary-hosts, और --postgres-host-weights विकल्पों का उपयोग करना संभव नहीं है।
 
-A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+एक न्यूनतम `config.toml` फ़ाइल प्रदान की जा सकती है; निम्नलिखित फ़ाइल का उपयोग --postgres-url कमांड लाइन विकल्प के समान है:
 
 ```toml
 [store]
@@ -110,7 +110,7 @@ connection="<.. postgres-url argument ..>"
 indexers = [ "<.. list of all indexing nodes ..>" ]
 ```
 
-Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+`config.toml` की पूरी डॉक्यूमेंटेशन [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md) में मिल सकती है।
 
 #### Multiple Graph Nodes
 
@@ -150,7 +150,7 @@ indexers = [
   ]
 ```
 
-Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+डिप्लॉयमेंट नियमों के बारे में अधिक पढ़ें [यहां](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment)।
 
 #### Dedicated query nodes
 
@@ -175,7 +175,7 @@ Shards can be used to split subgraph deployments across multiple databases, and
 
 In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
 
-Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+[यहाँ](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases) स्टोर कॉन्फ़िगरेशन के बारे में और पढ़ें।
 
 #### Dedicated block ingestion
 
@@ -210,7 +210,7 @@ shard = "primary"
 provider = [ { label = "kovan", url = "http://..", features = [] } ]
 ```
 
-Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+एथेरियम प्रदाताओं की कॉन्फ़िगरेशन के बारे में अधिक जानकारी [यहाँ](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers) पढ़ें।
 
 ### Environment variables
 
@@ -220,7 +220,7 @@ Graph Node supports a range of environment variables which can enable features,
 
 जो उपयोगकर्ता उन्नत कॉन्फ़िगरेशन के साथ एक स्केल्ड इंडेक्सिंग सेटअप का संचालन कर रहे हैं, वे कुबेरनेट्स के साथ अपने ग्राफ़ नोड्स को प्रबंधित करने से लाभान्वित हो सकते हैं।
 
-- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- Indexer रिपॉजिटरी में एक [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s) उपलब्ध है।
 - [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
 
 ### Managing Graph Node
@@ -233,7 +233,7 @@ Graph Node's logs can provide useful information for debugging and optimisation
 
 In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
 
-#### Monitoring & alerting
+#### निगरानी और सतर्कता
 
 ग्राफ़ नोड डिफ़ॉल्ट रूप से 8040 पोर्ट पर प्रोमेथियस एंडपॉइंट के माध्यम से मेट्रिक्स प्रदान करता है। इन मेट्रिक्स की कल्पना करने के लिए ग्राफाना का उपयोग किया जा सकता है।
 
@@ -253,7 +253,7 @@ Full documentation of `graphman` commands is available in the Graph Node reposit
 
 Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
 
-The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+पूर्ण स्कीमा [यहां](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql) उपलब्ध है।
 
 #### Indexing performance
 
@@ -297,9 +297,9 @@ However, in some instances, if an Ethereum node has provided incorrect data for
 
 If a block cache inconsistency is suspected, such as a tx receipt missing event:
 
-1. `graphman chain list` to find the chain name.
-2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
-   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+1. `graphman chain list` का उपयोग करके chain का नाम पता करें।
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` यह जांच करेगा कि क्या कैश किया हुआ ब्लॉक प्रदाता से मेल खाता है, और यदि यह मेल नहीं खाता है तो ब्लॉक को कैश से हटा देगा।
+   1. यदि कोई अंतर है, तो पूरे कैश को `graphman chain truncate <CHAIN>` के साथ हटाना अधिक सुरक्षित हो सकता है।
    2. यदि ब्लॉक प्रदाता से मेल खाता है, तो समस्या को सीधे प्रदाता के विरुद्ध डिबग किया जा सकता है।
 
 #### Querying issues and errors
@@ -328,13 +328,13 @@ Given a slow query, indexers have a few options. Of course they can alter their
 
 Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
 
-For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+अकाउंट-जैसी तालिकाओं के लिए, `ग्राफ-नोड` ऐसे queries जनरेट कर सकता है जो इस विवरण का लाभ उठाते हैं कि Postgres इतनी तेज़ दर पर डेटा स्टोर करते समय इसे कैसे प्रबंधित करता है। खासतौर पर, हाल के ब्लॉक्स के सभी संस्करण ऐसी तालिका के कुल स्टोरेज के एक छोटे से हिस्से में होते हैं।
 
 The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
 
 In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
 
-Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+एक बार जब यह तय कर लिया जाता है कि एक तालिका खाता जैसी है, तो `graphman stats account-like <sgdNNN>.<table>` चलाने से उस तालिका के खिलाफ queries के लिए खाता जैसी अनुकूलन सक्षम हो जाएगा। इस अनुकूलन को फिर से बंद किया जा सकता है `graphman stats account-like --clear <sgdNNN>.<table>` के साथ। queries नोड्स को यह नोटिस करने में 5 मिनट तक का समय लग सकता है कि अनुकूलन को चालू या बंद किया गया है। अनुकूलन को चालू करने के बाद, यह सत्यापित करना आवश्यक है कि बदलाव वास्तव में उस तालिका के लिए queries को धीमा नहीं कर रहा है। यदि आपने Grafana को Postgres की निगरानी के लिए कॉन्फ़िगर किया है, तो धीमी queries `pg_stat_activity` में बड़ी संख्या में दिखाई देंगी, जो कई सेकंड ले रही हैं। ऐसे में, अनुकूलन को फिर से बंद करने की आवश्यकता होती है।
 
 For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
 
@@ -342,4 +342,4 @@ For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates f
 
 > This is new functionality, which will be available in Graph Node 0.29.x
 
-At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).
+किसी बिंदु पर एक indexer एक दिए गए subgraph को हटाना चाहता है। इसे आसानी से `graphman drop` के माध्यम से किया जा सकता है, जो एक deployment और उसके सभी indexed डेटा को हटा देता है। डिप्लॉयमेंट को subgraph नाम, एक IPFS हैश `Qm..`, या डेटाबेस नामस्थान `sgdNNN` के रूप में निर्दिष्ट किया जा सकता है। आगे की दस्तावेज़ीकरण यहां उपलब्ध है [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop)।

From 1040408d5d1d3bf43da0948d1841f800895c6ae9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 05:10:51 -0500
Subject: [PATCH 2909/3820] New translations tap.mdx (Hindi)

---
 website/pages/hi/indexing/tap.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/hi/indexing/tap.mdx b/website/pages/hi/indexing/tap.mdx
index cf7aa1d24159..0e06f8995a3e 100644
--- a/website/pages/hi/indexing/tap.mdx
+++ b/website/pages/hi/indexing/tap.mdx
@@ -63,16 +63,16 @@ TAP एक प्रेषक को एक प्राप्तकर्ता
 
 एक Indexer चलाने की सामान्य आवश्यकताओं के अलावा, आपको TAP अपडेट को क्वेरी करने के लिए एक tap-escrow-subgraph एंडपॉइंट की आवश्यकता होगी। आप TAP को क्वेरी करने के लिए The Graph Network का उपयोग कर सकते हैं या अपने graph-node पर स्वयं होस्ट कर सकते हैं।
 
-- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum Sepolia subgraph (The Graph टेस्टनेट के लिए)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
 - [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
 
-> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+> नोट: `indexer-agent` वर्तमान में इस subgraph का indexing नेटवर्क subgraph डिप्लॉयमेंट की तरह नहीं करता है। इसके परिणामस्वरूप, आपको इसे मैन्युअल रूप से इंडेक्स करना होगा।
 
 ## माइग्रेशन गाइड
 
 ### सॉफ़्टवेयर संस्करण
 
-The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+आवश्यक सॉफ़्टवेयर संस्करण [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases) पाया जा सकता है।
 
 ### कदम
 
@@ -170,7 +170,7 @@ max_amount_willing_to_lose_grt = 20
 
 टिप्पणियाँ:
 
-- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
+- tap.sender_aggregator_endpoints के लिए मान gateway section(/indexing/tap/#gateway) में पाए जा सकते हैं।
 - Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
 
 **लॉग स्तर**

From 28914b82ea0823001cccf7b6f00ee0a19ac104f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 05:10:52 -0500
Subject: [PATCH 2910/3820] New translations triggers.mdx (Hindi)

---
 website/pages/hi/substreams/sps/triggers.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/substreams/sps/triggers.mdx b/website/pages/hi/substreams/sps/triggers.mdx
index a5d1d32e1b95..2e9b7fa7206f 100644
--- a/website/pages/hi/substreams/sps/triggers.mdx
+++ b/website/pages/hi/substreams/sps/triggers.mdx
@@ -34,4 +34,4 @@ export function handleTransactions(bytes: Uint8Array): void {
 2. लेनदेन पर लूप करना
 3. प्रत्येक लेनदेन के लिए एक नया subgraph entity बनाएं
 
-To go through a detailed example of a trigger-based subgraph, [click here](/substreams/sps/tutorial/).
+एक ट्रिगर-आधारित subgraph के विस्तृत उदाहरण को देखने के लिए, [यहाँ क्लिक](/substreams/sps/tutorial/) करें।

From 936ecec7bd5c1aa17b3bcbb174aaa43cf624e4a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 05:10:54 -0500
Subject: [PATCH 2911/3820] New translations l2-transfer-tools-guide.mdx
 (Hindi)

---
 website/pages/hi/archived/arbitrum/l2-transfer-tools-guide.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/hi/archived/arbitrum/l2-transfer-tools-guide.mdx
index 21ee64e62ac4..a1820970ae5c 100644
--- a/website/pages/hi/archived/arbitrum/l2-transfer-tools-guide.mdx
+++ b/website/pages/hi/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -4,7 +4,7 @@ title: L2 Transfer Tools Guide
 
 The Graph has made it easy to move to L2 on Arbitrum One. For each protocol participant, there are a set of L2 Transfer Tools to make transferring to L2 seamless for all network participants. These tools will require you to follow a specific set of steps depending on what you are transferring.
 
-Some frequent questions about these tools are answered in the [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/). The FAQs contain in-depth explanations of how to use the tools, how they work, and things to keep in mind when using them.
+इन टूल्स के बारे में कुछ सामान्य प्रश्नों के उत्तर [L2 Transfer Tools FAQ](/archived/arbitrum/l2-transfer-tools-faq/) में दिए गए हैं। FAQs में इन टूल्स का उपयोग कैसे करें, वे कैसे काम करते हैं, और उनका उपयोग करते समय ध्यान में रखने वाली बातें विस्तृत रूप से समझाई गई हैं।
 
 ## अपने सबग्राफ को आर्बिट्रम (L2) में कैसे स्थानांतरित करें
 

From 845049eae8a6656c7149cb4f18dc8206fe855524 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 05:10:56 -0500
Subject: [PATCH 2912/3820] New translations firehose.mdx (Hindi)

---
 website/pages/hi/indexing/tooling/firehose.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/hi/indexing/tooling/firehose.mdx b/website/pages/hi/indexing/tooling/firehose.mdx
index 199ab7661bb4..2678f5b3eb73 100644
--- a/website/pages/hi/indexing/tooling/firehose.mdx
+++ b/website/pages/hi/indexing/tooling/firehose.mdx
@@ -6,19 +6,19 @@ title: Firehose
 
 Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
 
-The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+The Graph ने Go Ethereum/geth में विलय कर लिया है और [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0) को अपनाया है।
 
 Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
 
 ## Firehose Documentation
 
-The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+Firehose का दस्तावेज़ वर्तमान में StreamingFast टीम द्वारा [StreamingFast वेबसाइट पर](https://firehose.streamingfast.io/) प्रबंधित किया जाता है।
 
 ### शुरू करना
 
-- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
-- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+- Firehose का परिचय पढ़ें [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) यह जानने के लिए कि यह क्या है और इसे क्यों बनाया गया।
+- [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) के बारे में जानें ताकि Firehose को इंस्टॉल और डिप्लॉय किया जा सके।
 
 ### Expand Your Knowledge
 
-- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.
+- विभिन्न [Firehose components](https://firehose.streamingfast.io/architecture/components) के बारे में जानें।

From 48849a8a1800bf56d1267fda34b0c978976c0087 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 05:10:57 -0500
Subject: [PATCH 2913/3820] New translations benefits.mdx (Hindi)

---
 website/pages/hi/resources/benefits.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/resources/benefits.mdx b/website/pages/hi/resources/benefits.mdx
index 6e641cf6c733..5e834d724d55 100644
--- a/website/pages/hi/resources/benefits.mdx
+++ b/website/pages/hi/resources/benefits.mdx
@@ -79,11 +79,11 @@ Estimated costs are only for Ethereum Mainnet subgraphs — costs are even highe
 
 एक सबग्राफ पर क्यूरेटिंग सिग्नल एक वैकल्पिक वन-टाइम, नेट-जीरो कॉस्ट है (उदाहरण के लिए, सिग्नल में $1k को सबग्राफ पर क्यूरेट किया जा सकता है, और बाद में वापस ले लिया जाता है - प्रक्रिया में रिटर्न अर्जित करने की क्षमता के साथ)।
 
-## No Setup Costs & Greater Operational Efficiency
+## कोई सेटअप लागत नहीं और अधिक परिचालन दक्षता
 
 शून्य सेटअप शुल्क। बिना किसी सेटअप या ओवरहेड लागत के तुरंत आरंभ करें। कोई हार्डवेयर आवश्यकताएँ नहीं। केंद्रीकृत बुनियादी ढांचे के कारण कोई आउटेज नहीं, और अपने मूल उत्पाद पर ध्यान केंद्रित करने के लिए अधिक समय। बैकअप सर्वर, समस्या निवारण या महंगे इंजीनियरिंग संसाधनों की कोई आवश्यकता नहीं है।
 
-## Reliability & Resiliency
+## विश्वसनीयता और लचीलापन
 
 The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
 

From 81cd062c48d5b6f4075e60b37c30aca00a92f52d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 06:18:25 -0500
Subject: [PATCH 2914/3820] New translations delegating.mdx (Hindi)

---
 website/pages/hi/resources/roles/delegating.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/hi/resources/roles/delegating.mdx b/website/pages/hi/resources/roles/delegating.mdx
index 6674e1bae3c2..9e5eda876cde 100644
--- a/website/pages/hi/resources/roles/delegating.mdx
+++ b/website/pages/hi/resources/roles/delegating.mdx
@@ -82,22 +82,22 @@ If you choose an Indexer that is not trustworthy or not doing a good job, you wi
 
 As a result, it’s recommended that you choose an Indexer wisely.
 
-<div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
-  unbonding period._
+<div sx={{ mx: 'auto', maxWidth: '400px' }}> 
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Delegation UI में 0.5% शुल्क और 28 दिनों की 
+  unbonding अवधि को ध्यान दें।_ 
 </div>
 
 #### डेलीगेशन पैरामीटर
 
 एक विश्वसनीय Indexer को चुनने के लिए आपको डेलीगेशन पैरामीटर्स को समझना आवश्यक है।
 
-- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+- **Indexing Reward Cut** - वह हिस्सा जो Indexer अपने लिए इनाम के रूप में रखेगा।
   - यदि किसी Indexer का पुरस्कार कट 100% पर सेट है, तो एक Delegator के रूप में, आपको 0 इंडेक्सिंग पुरस्कार मिलेंगे।
   - यदि इसे 80% पर सेट किया गया है, तो एक Delegator के रूप में, आप 20% प्राप्त करेंगे।
 
-<div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
-  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+<div sx={{ mx: 'auto', maxWidth: '700px' }}> 
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *सबसे ऊपर वाला Indexer Delegators को 90% इनाम दे रहा है। 
+  बीच वाला Delegators को 20% दे रहा है। सबसे नीचे वाला Delegators को लगभग 83% दे रहा है।* 
 </div>
 
 - **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.

From 1ee1049712947ff84284a2ecdd655d11984c5777 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 06:18:26 -0500
Subject: [PATCH 2915/3820] New translations benefits.mdx (Hindi)

---
 website/pages/hi/resources/benefits.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/resources/benefits.mdx b/website/pages/hi/resources/benefits.mdx
index 5e834d724d55..8c9c361318d6 100644
--- a/website/pages/hi/resources/benefits.mdx
+++ b/website/pages/hi/resources/benefits.mdx
@@ -87,6 +87,6 @@ Estimated costs are only for Ethereum Mainnet subgraphs — costs are even highe
 
 The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
 
-Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+The Graph Network कम खर्चीला, उपयोग में आसान और बेहतर परिणाम प्रदान करता है, जब की graph-node को लोकल पर चलाने के मुकाबले।
 
 Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From 170851f2981d8df7a4fb4ce7f3565752d647a762 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 06:18:27 -0500
Subject: [PATCH 2916/3820] New translations assemblyscript-migration-guide.mdx
 (Hindi)

---
 .../assemblyscript-migration-guide.mdx        | 111 +++++++++---------
 1 file changed, 56 insertions(+), 55 deletions(-)

diff --git a/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx
index dd7cfd2e6444..a57b61c8e2ae 100644
--- a/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -8,39 +8,40 @@ Up until now, subgraphs have been using one of the [first versions of AssemblySc
 
 This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
 
-> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+> `0.24.0` संस्करण से, `graph-node` दोनों संस्करणों का समर्थन कर सकता है, यह इस पर निर्भर करता है कि subgraph manifest में कौन सा `apiVersion` निर्दिष्ट किया गया है।
 
 ## विशेषताएँ
 
 ### नई कार्यक्षमता
 
-- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
-- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
-- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
-- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
-- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
-- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
-- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
-- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
-- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
-- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
-- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
-- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
-- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+- `TypedArray` को अब `ArrayBuffer` से बनाया जा सकता है[ नए `wrap` static method ](https://www.assemblyscript.org/stdlib/typedarray.html#static-members)का उपयोग करके ([v0.8.1]
+  (https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))।
+- नई मानक लाइब्रेरी फ़ंक्शन: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare` और `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- GenericClass के लिए x instanceof समर्थन जोड़ा गया ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- `StaticArray<T>` जो एक अधिक कुशल array प्रकार है, जोड़ा गया ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- `Array<T>#flat` जोड़ा गया ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- `Number#toString` पर `radix` आर्गुमेंट लागू किया ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- फ्लोटिंग पॉइंट लिटरल्स में सेपरेटर्स के लिए समर्थन जोड़ा गया ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- पहली श्रेणी के फ़ंक्शन्स के लिए समर्थन जोड़ा गया ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- बिल्ट-इन जोड़ें: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- `Array/TypedArray/String#at` को लागू करें ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- टेम्पलेट लिटरल स्ट्रिंग्स के लिए सपोर्ट जोड़ा गया ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- `encodeURI(Component)` और `decodeURI(Component)` को जोड़ा गया ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- `toString`, `toDateString` और `toTimeString` को `Date` में जोड़ें ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- `toUTCString` के लिए `Date` में जोड़ें ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- `nonnull/NonNullable` बिल्ट-इन टाइप जोड़ा गया ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
 
 ### अनुकूलन
 
-- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
-- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
-- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- `Math` फ़ंक्शंस जैसे कि `exp`, `exp2`, `log`, `log2` और `pow` को तेज़ वेरिएंट्स से बदल दिया गया है ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- थोड़ा ऑप्टिमाइज़ करें `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- स्टैंडर्ड मैप और सेट में अधिक फ़ील्ड एक्सेस कैश करें ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- `ipow32/64`([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2)) में दो के शक्तियों के लिए अनुकूलित करें
 
 ### अन्य
 
-- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- एक एरे लिटरल के प्रकार को अब इसकी सामग्री से अनुमानित किया जा सकता है ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib को Unicode 13.0.0 में अपडेट किया गया ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
 
 ## कैसे करें अपग्रेड?
 
@@ -56,7 +57,7 @@ dataSources:
       ...
 ```
 
-2. Update the `graph-cli` you're using to the `latest` version by running:
+2. आप जो `graph-cli` उपयोग कर रहे हैं, उसे `latest` संस्करण में अपडेट करने के लिए यह चलाएँ:
 
 ```bash
 # if you have it globally installed
@@ -66,14 +67,14 @@ npm install --global @graphprotocol/graph-cli@latest
 npm install --save-dev @graphprotocol/graph-cli@latest
 ```
 
-3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+3. यह वही करें `graph-ts`, लेकिन इसे ग्लोबली इंस्टॉल करने के बजाय, इसे अपनी मुख्य निर्भरताओं में सेव करें:
 
 ```bash
 npm install --save @graphprotocol/graph-ts@latest
 ```
 
 4. भाषा संबंधी परिवर्तनों को ठीक करने के लिए शेष मार्गदर्शिका का पालन करें।
-5. Run `codegen` and `deploy` again.
+5. `codegen` और `deploy` को फिर से चलाएं।
 
 ## ब्रेकिंग परिवर्तन
 
@@ -110,7 +111,7 @@ maybeValue.aMethod()
 
 ### Variable Shadowing
 
-Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+पहले आप [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) कर सकते थे और कोड इस तरह काम करता था:
 
 ```typescript
 let a = 10
@@ -141,7 +142,7 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
  in src/mappings/file.ts(41,21)
 ```
 
-To solve you can simply change the `if` statement to something like this:
+समस्या को हल करने के लिए आप बस `if` स्टेटमेंट को इस प्रकार बदल सकते हैं:
 
 ```typescript
   if (!decimals) {
@@ -155,7 +156,7 @@ To solve you can simply change the `if` statement to something like this:
 
 ### कास्टिंग
 
-The common way to do casting before was to just use the `as` keyword, like this:
+पहले कास्टिंग करने का सामान्य तरीका `as` कीवर्ड का उपयोग करना था, जैसे कि इस प्रकार:
 
 ```typescript
 let byteArray = new ByteArray(10)
@@ -177,24 +178,24 @@ let c: usize = a + (b as usize)
 ```
 
 ```typescript
-// upcasting on class inheritance
+// क्लास इनहेरिटेंस पर उपकास्टिंग
 class Bytes extends Uint8Array {}
 
 let bytes = new Bytes(2)
-// <Uint8Array>bytes // same as: bytes as Uint8Array
+// <Uint8Array>bytes // यह समान है: bytes as Uint8Array
 ```
 
-There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+यहां दो परिदृश्य हैं जहाँ आप कास्ट करना चाह सकते हैं, लेकिन `as`/`<T>var` का उपयोग **सुरक्षित नहीं है**:
 
 - क्लास इनहेरिटेंस (सुपरक्लास → सबक्लास) पर डाउनकास्टिंग
 - एक सुपरक्लास साझा करने वाले दो प्रकारों के बीच
 
 ```typescript
-// downcasting on class inheritance
+// क्लास इनहेरिटेंस में डाउनकास्टिंग
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-// <Bytes>uint8Array // breaks in runtime :(
+// <Bytes>uint8Array // रनटाइम में ब्रेक हो जाता है :(
 ```
 
 ```typescript
@@ -206,14 +207,14 @@ let bytes = new Bytes(2)
 // <ByteArray>bytes // breaks in runtime :(
 ```
 
-For those cases, you can use the `changetype<T>` function:
+ऐसे मामलों के लिए, आप `changetype<T>` फ़ंक्शन का उपयोग कर सकते हैं:
 
 ```typescript
-// downcasting on class inheritance
+// क्लास इनहेरिटेंस पर डाउनकास्टिंग
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-changetype<Bytes>(uint8Array) // works :)
+changetype<Bytes>(uint8Array) // काम करता है :)
 ```
 
 ```typescript
@@ -225,7 +226,7 @@ let bytes = new Bytes(2)
 changetype<ByteArray>(bytes) // works :)
 ```
 
-If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+यदि आप केवल nullability को हटाना चाहते हैं, तो आप `as` ऑपरेटर (या `<T>variable`) का उपयोग जारी रख सकते हैं, लेकिन यह सुनिश्चित करें कि आपको पता है कि वह मान null नहीं हो सकता है, अन्यथा यह टूट जाएगा।
 
 ```typescript
 // remove nullability
@@ -238,7 +239,7 @@ if (previousBalance != null) {
 let newBalance = new AccountBalance(balanceId)
 ```
 
-For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+nullability के मामले में, हम सुझाव देते हैं कि आप [nullability check विशेषता](https://www.assemblyscript.org/basics.html#nullability-checks) पर एक नज़र डालें, यह आपकी कोड को अधिक साफ-सुथरा बना देगा 🙂
 
 साथ ही, हमने कास्टिंग को आसान बनाने के लिए कुछ प्रकारों में कुछ और स्थैतिक विधियाँ जोड़ी हैं, वे हैं:
 
@@ -249,7 +250,7 @@ For the nullability case we recommend taking a look at the [nullability check fe
 
 ### Nullability check with property access
 
-To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+[nullability check विशेषता](https://www.assemblyscript.org/basics.html#nullability-checks) का उपयोग करने के लिए, आप या तो `if` स्टेटमेंट्स का उपयोग कर सकते हैं या टर्नरी ऑपरेटर (`?` और `:`) का उपयोग कर सकते हैं, इस प्रकार:
 
 ```typescript
 let something: string | null = 'data'
@@ -267,7 +268,7 @@ if (something) {
 }
 ```
 
-However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+हालांकि, यह केवल तब काम करता है जब आप किसी वेरिएबल पर `if` / टर्नरी का उपयोग कर रहे हों, न कि किसी प्रॉपर्टी एक्सेस पर, जैसे:
 
 ```typescript
 class Container {
@@ -380,7 +381,7 @@ if (total === null) {
 total.amount = total.amount + BigInt.fromI32(1)
 ```
 
-You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+आपको यह सुनिश्चित करना होगा कि `total.amount` मान को प्रारंभिक रूप से सेट किया जाए, क्योंकि यदि आप इसे अंतिम पंक्ति में जोड़ने के लिए एक्सेस करने का प्रयास करेंगे, तो यह क्रैश हो जाएगा। तो आपको इसे पहले प्रारंभिक रूप से सेट करना होगा।
 
 ```typescript
 let total = Total.load('latest')
@@ -393,7 +394,7 @@ if (total === null) {
 total.tokens = total.tokens + BigInt.fromI32(1)
 ```
 
-Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+या आप अपनी GraphQL स्कीमा को इस प्रॉपर्टी के लिए nullable टाइप का उपयोग न करने के लिए बदल सकते हैं, फिर हम इसे `codegen` स्टेप में शून्य के रूप में इनिशियलाइज करेंगे 😉
 
 ```graphql
 type Total @entity {
@@ -424,7 +425,7 @@ export class Something {
 }
 ```
 
-The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+कंपाइलर में त्रुटि होगी क्योंकि आपको उन गुणों के लिए या तो एक प्रारंभिक मान जोड़ने की आवश्यकता है जो कक्षाएँ हैं, या `!` ऑपरेटर जोड़ने की आवश्यकता है।
 
 ```typescript
 export class Something {
@@ -450,12 +451,12 @@ export class Something {
 
 ### सरणी आरंभीकरण
 
-The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+`Array` क्लास अभी भी एक नंबर स्वीकार करता है जिससे सूची की लंबाई को प्रारंभिक रूप से सेट किया जा सकता है, हालांकि आपको सावधानी बरतनी चाहिए क्योंकि .`push` जैसी ऑपरेशन्स वास्तव में आकार बढ़ा देंगी बजाय इसके कि वे शुरुआत में जोड़ें, उदाहरण के लिए:
 
 ```typescript
 let arr = new Array<string>(5) // ["", "", "", "", ""]
 
-arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+arr.push('something') // ["", "", "", "", "", "something"] // आकार 6 :(
 ```
 
 आपके द्वारा उपयोग किए जा रहे प्रकारों के आधार पर, उदाहरण के लिए अशक्त वाले, और आप उन्हें कैसे एक्सेस कर रहे हैं, आपको इस तरह की रनटाइम त्रुटि का सामना करना पड़ सकता है:
@@ -464,7 +465,7 @@ arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
 ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
 ```
 
-To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+शुरुआत में वास्तव में पुश करने के लिए, आपको `Array` को शून्य आकार के साथ इस प्रकार प्रारंभ करना चाहिए:
 
 ```typescript
 let arr = new Array<string>(0) // []
@@ -482,7 +483,7 @@ arr[0] = 'something' // ["something", "", "", "", ""]
 
 ### ग्राफक्यूएल स्कीमा
 
-This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+यह एक सीधे `AssemblyScript` में परिवर्तन नहीं है, लेकिन आपको अपनी `schema.graphql` फ़ाइल को अपडेट करना पड़ सकता है।
 
 अब आप अपने प्रकारों में उन क्षेत्रों को परिभाषित नहीं कर सकते हैं जो गैर-शून्य सूची हैं। यदि आपके पास ऐसा स्कीमा है:
 
@@ -497,7 +498,7 @@ type MyEntity @entity {
 }
 ```
 
-You'll have to add an `!` to the member of the List type, like this:
+आपको List प्रकार के सदस्य में ! जोड़ना होगा, इस तरह:
 
 ```graphql
 type Something @entity {
@@ -514,10 +515,10 @@ This changed because of nullability differences between AssemblyScript versions,
 
 ### अन्य
 
-- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
-- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
-- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
-- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
-- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- स्पेसिफिकेशन के साथ `Map#set` और `Set#add` को संरेखित किया गया, जो `this` को लौटाता है ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- ऐरे अब ArrayBufferView से विरासत में नहीं मिलते हैं, बल्कि अब वे अलग हैं ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- वस्तु साहित्य से प्रारंभ की गई कक्षाएँ अब एक निर्माता (constructor) परिभाषित नहीं कर सकतीं ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- `**` बाइनरी ऑपरेशन का परिणाम अब सामान्य हरियाली पूर्णांक होता है यदि दोनों ऑपरेन्ड पूर्णांक होते हैं। पहले, परिणाम एक फ्लोट होता था जैसे कि `Math/f.pow` को कॉल करते समय ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- `NaN` को `false` में बदलें जब `bool` में कास्ट किया जाए ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- जब एक छोटे पूर्णांक मान को `i8`/`u8` या `i16`/`u16` प्रकार में शिफ्ट किया जाता है, तो केवल RHS मान के 3 या 4 सबसे कम महत्वपूर्ण बिट्स परिणाम को प्रभावित करते हैं, जैसे कि `i32.shl` के परिणाम को केवल RHS मान के 5 सबसे कम महत्वपूर्ण बिट्स द्वारा प्रभावित किया जाता है। उदाहरण: `someI8 << 8` पहले `0` मान उत्पन्न करता था, लेकिन अब `someI8` उत्पन्न करता है क्योंकि RHS को मास्क किया गया है जैसा कि `8 & 7 = 0` (3 बिट्स) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- वर्शन ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8)) में आकारों के भिन्न होने पर संबंधी स्ट्रिंग तुलना में बग सुधार

From 1aeefa542fad2b33da562d6e715b902d000e3219 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 06:18:29 -0500
Subject: [PATCH 2917/3820] New translations curating.mdx (Hindi)

---
 website/pages/hi/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/resources/roles/curating.mdx b/website/pages/hi/resources/roles/curating.mdx
index e54b89d37803..8fa7994fde95 100644
--- a/website/pages/hi/resources/roles/curating.mdx
+++ b/website/pages/hi/resources/roles/curating.mdx
@@ -12,7 +12,7 @@ Curators make The Graph network efficient and [signaling](#how-to-signal) is the
 
 Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
 
-The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+[Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) यह सुनिश्चित करता है कि सभी सबग्राफ को index किया जाए। किसी विशेष subgraph पर GRT को संकेत करने से अधिक indexers उस पर आकर्षित होते हैं। curation के माध्यम से अतिरिक्त Indexers को प्रोत्साहित करना queries की सेवा की गुणवत्ता को बढ़ाने के लिए है, जिससे latency कम हो और नेटवर्क उपलब्धता में सुधार हो।
 
 When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
 

From ea5efbfda069e43347657be61d7002a8046309aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 07:24:20 -0500
Subject: [PATCH 2918/3820] New translations benefits.mdx (French)

---
 website/pages/fr/resources/benefits.mdx | 81 +++++++++++++------------
 1 file changed, 41 insertions(+), 40 deletions(-)

diff --git a/website/pages/fr/resources/benefits.mdx b/website/pages/fr/resources/benefits.mdx
index b233bb058c89..08906cb6ab65 100644
--- a/website/pages/fr/resources/benefits.mdx
+++ b/website/pages/fr/resources/benefits.mdx
@@ -1,11 +1,11 @@
 ---
-title: The Graph vs. Self Hosting
+title: The Graph vs. l’auto-hébergement
 socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
 ---
 
 Le réseau décentralisé de The Graph a été conçu et affiné pour créer une expérience d'indexation et d'interrogation robuste, et il s'améliore chaque jour grâce à des milliers de contributeurs à travers le monde.
 
-The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+Les avantages de ce protocole décentralisé ne peuvent pas être reproduits en exécutant un `graph-node` localement. The Graph Network est plus fiable, plus efficace et moins coûteux.
 
 Voici une analyse :
 
@@ -19,7 +19,7 @@ Voici une analyse :
 
 ## Les avantages expliqués
 
-### Lower & more Flexible Cost Structure
+### Structure de coûts plus faible et plus flexible
 
 Pas de contrat. Pas de frais mensuels. Vous ne payez que pour les requêtes que vous utilisez, avec un coût moyen par requête de 40 $ par million de requêtes (~0,00004 $ par requête). Les requêtes sont facturées en USD et payées en GRT ou par carte de crédit.
 
@@ -27,47 +27,47 @@ Les coûts d'interrogation peuvent varier ; le coût indiqué est la moyenne au
 
 ## Utilisateur à faible volume (moins de 100 000 requêtes par mois)
 
-|         Cost Comparison        |               Auto-hébergé              |                              The Graph Network                              |
-| :----------------------------: | :-------------------------------------: | :-------------------------------------------------------------------------: |
-|    Coût mensuel du serveur\*   |              350 $ au mois              |                                     0 $                                     |
-|        Frais de requête        |                  - 0 $                  |                                 0$ par mois                                 |
-| Temps d'ingénierie<sup>†</sup> |              400 $ au mois              | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
-|        Requêtes au mois        |        Limité aux capacités infra       |                            100 000 (Plan Gratuit)                           |
-|        Tarif par requête       |                   0 $                   |                                0$<sup>‡</sup>                               |
-|         Infrastructure         |               Centralisée               |                                Décentralisée                                |
-|   La redondance géographique   |      750$+ par nœud complémentaire      |                                   Compris                                   |
-|     Temps de disponibilité     |                 Variable                |                                   - 99.9%                                   |
-|    Total des coûts mensuels    | <span className="highlight-row" />$750+ |                                     0 $                                     |
+|         Cost Comparison        |               Auto-hébergé               |                              The Graph Network                              |
+| :----------------------------: | :--------------------------------------: | :-------------------------------------------------------------------------: |
+|    Coût mensuel du serveur\*   |               350 $ au mois              |                                     0 $                                     |
+|        Frais de requête        |                   - 0 $                  |                                 0$ par mois                                 |
+| Temps d'ingénierie<sup>†</sup> |               400 $ au mois              | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
+|        Requêtes au mois        |        Limité aux capacités infra        |                            100 000 (Plan Gratuit)                           |
+|        Tarif par requête       |                    0 $                   |                                0$<sup>‡</sup>                               |
+|         Infrastructure         |                Centralisée               |                                Décentralisée                                |
+|   La redondance géographique   |       750$+ par nœud complémentaire      |                                   Compris                                   |
+|     Temps de disponibilité     |                 Variable                 |                                   - 99.9%                                   |
+|    Total des coûts mensuels    | <span className="highlight-row" />750 $+ |                                     0 $                                     |
 
 ## Utilisateur à volume moyen (~3M requêtes par mois)
 
-|         Cost Comparison        |                Auto-hébergé                |                              The Graph Network                              |
-| :----------------------------: | :----------------------------------------: | :-------------------------------------------------------------------------: |
-|    Coût mensuel du serveur\*   |                350 $ au mois               |                                     0 $                                     |
-|        Frais de requête        |                500 $ au mois               |                                120$ par mois                                |
-| Temps d'ingénierie<sup>†</sup> |                800 $ au mois               | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
-|        Requêtes au mois        |         Limité aux capacités infra         |                                  ~3,000,000                                 |
-|        Tarif par requête       |                     0 $                    |                                   $0.00004                                  |
-|         Infrastructure         |                 Centralisée                |                                Décentralisée                                |
-|       Frais d'ingénierie       |                200 $ au mois               |                                   Compris                                   |
-|   La redondance géographique   | 1 200 $ coût total par nœud supplémentaire |                                   Compris                                   |
-|     Temps de disponibilité     |                  Variable                  |                                   - 99.9%                                   |
-|    Total des coûts mensuels    | <span className="highlight-row" /> $1,650+ |                                     120$                                    |
-
-## Utilisateur à volume élevé (~30M requêtes par mois)
-
 |         Cost Comparison        |                 Auto-hébergé                |                              The Graph Network                              |
 | :----------------------------: | :-----------------------------------------: | :-------------------------------------------------------------------------: |
-|    Coût mensuel du serveur\*   |           1100 $ au mois, par nœud          |                                     0 $                                     |
-|        Frais de requête        |                    4000 $                   |                               1 200 $ par mois                              |
-|  Nombre de nœuds obligatoires  |                      10                     |                                  Sans objet                                 |
-| Temps d'ingénierie<sup>†</sup> |            6000 $ ou plus au mois           | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
-|        Requêtes au mois        |          Limité aux capacités infra         |                                 ~30,000,000                                 |
+|    Coût mensuel du serveur\*   |                350 $ au mois                |                                     0 $                                     |
+|        Frais de requête        |                500 $ au mois                |                                120$ par mois                                |
+| Temps d'ingénierie<sup>†</sup> |                800 $ au mois                | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
+|        Requêtes au mois        |          Limité aux capacités infra         |                                  ~3,000,000                                 |
 |        Tarif par requête       |                     0 $                     |                                   $0.00004                                  |
 |         Infrastructure         |                 Centralisée                 |                                Décentralisée                                |
+|       Frais d'ingénierie       |                200 $ au mois                |                                   Compris                                   |
 |   La redondance géographique   |  1 200 $ coût total par nœud supplémentaire |                                   Compris                                   |
 |     Temps de disponibilité     |                   Variable                  |                                   - 99.9%                                   |
-|    Total des coûts mensuels    | <span className="highlight-row" /> $11,000+ |                                    1,200$                                   |
+|    Total des coûts mensuels    | <span className="highlight-row" /> 1 650 $+ |                                     120$                                    |
+
+## Utilisateur à volume élevé (~30M requêtes par mois)
+
+|         Cost Comparison        |                 Auto-hébergé                 |                              The Graph Network                              |
+| :----------------------------: | :------------------------------------------: | :-------------------------------------------------------------------------: |
+|    Coût mensuel du serveur\*   |           1100 $ au mois, par nœud           |                                     0 $                                     |
+|        Frais de requête        |                    4000 $                    |                               1 200 $ par mois                              |
+|  Nombre de nœuds obligatoires  |                      10                      |                                  Sans objet                                 |
+| Temps d'ingénierie<sup>†</sup> |            6000 $ ou plus au mois            | Aucun, intégré au réseau avec des indexeurs distribués à l'échelle mondiale |
+|        Requêtes au mois        |          Limité aux capacités infra          |                                 ~30,000,000                                 |
+|        Tarif par requête       |                      0 $                     |                                   $0.00004                                  |
+|         Infrastructure         |                  Centralisée                 |                                Décentralisée                                |
+|   La redondance géographique   |  1 200 $ coût total par nœud supplémentaire  |                                   Compris                                   |
+|     Temps de disponibilité     |                   Variable                   |                                   - 99.9%                                   |
+|    Total des coûts mensuels    | <span className="highlight-row" /> 11 000 $+ |                                    1,200$                                   |
 
 \*y compris les coûts de sauvegarde : $50-$ à 100 dollars au mois
 
@@ -75,18 +75,19 @@ Les coûts d'interrogation peuvent varier ; le coût indiqué est la moyenne au
 
 <sup>‡</sup>Reflète le coût pour le consommateur de données. Les frais de requête sont toujours payés aux Indexeurs pour les requêtes du Plan Gratuit.
 
-Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+Les coûts estimés concernent uniquement les subgraphs sur le Mainnet d'Ethereum — les coûts sont encore plus élevés lorsqu’un `graph-node` est auto-hébergé sur d’autres réseaux. Certains utilisateurs peuvent avoir besoin de mettre à jour leur subgraph vers une nouvelle version. En raison des frais de gas sur Ethereum, une mise à jour coûte environ 50 $ au moment de la rédaction. Notez que les frais de gas sur [Arbitrum](/archived/arbitrum/arbitrum-faq/) sont nettement inférieurs à ceux du
+ Mainnet d'Ethereum.
 
 Émettre un signal sur un subgraph est un cout net, nul optionnel et unique (par exemple, 1 000 $ de signal peuvent être conservés sur un subgraph, puis retirés - avec la possibilité de gagner des revenus au cours du processus).
 
-## No Setup Costs & Greater Operational Efficiency
+## Pas de Coûts d’Installation & Plus grande Efficacité Opérationnelle
 
 Commencez tout de suite, sans installation, sans frais généraux et sans matériel. De plus, vous n'avez pas à vous soucier des temps d'arrêt dus à une infrastructure centralisée, ce qui vous laisse plus de temps pour vous concentrer sur votre produit principal. Vous n'avez pas non plus besoin de serveurs de secours, de dépannage ou d'autres ressources techniques coûteuses.
 
-## Reliability & Resiliency
+## Fiabilité & Résilience
 
 The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
 
-Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+En résumé : The Graph Network est moins cher, plus facile à utiliser et produit des résultats supérieurs à ceux obtenus par l'exécution locale d'un `graph-node`.
 
-Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).
+Commencez à utiliser The Graph Network dès aujourd’hui et découvrez comment [publier votre subgraph sur le réseau décentralisé de The Graph](/subgraphs/quick-start/).

From 0095d3be511447e5ffe6f36c3d54663daa4b1c14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 08:50:41 -0500
Subject: [PATCH 2919/3820] New translations benefits.mdx (French)

---
 website/pages/fr/resources/benefits.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/resources/benefits.mdx b/website/pages/fr/resources/benefits.mdx
index 08906cb6ab65..e44fe8788e98 100644
--- a/website/pages/fr/resources/benefits.mdx
+++ b/website/pages/fr/resources/benefits.mdx
@@ -86,7 +86,7 @@ Commencez tout de suite, sans installation, sans frais généraux et sans matér
 
 ## Fiabilité & Résilience
 
-The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+Le réseau décentralisé de The Graph offre aux utilisateurs une redondance géographique qui n'existe pas en auto-hébergeant un `graph-node`. Les requêtes sont servies de manière fiable grâce à une disponibilité de plus de 99,9 %, assurée par des centaines d’Indexers indépendants qui sécurisent le réseau à l’échelle mondiale.
 
 En résumé : The Graph Network est moins cher, plus facile à utiliser et produit des résultats supérieurs à ceux obtenus par l'exécution locale d'un `graph-node`.
 

From 9184df04900fbda74f1f8557bcc3f72dd5305d73 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:01 -0500
Subject: [PATCH 2920/3820] New translations explorer.mdx (German)

---
 website/pages/de/subgraphs/explorer.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/subgraphs/explorer.mdx b/website/pages/de/subgraphs/explorer.mdx
index 0489b8960c62..b6d4be6ff79e 100644
--- a/website/pages/de/subgraphs/explorer.mdx
+++ b/website/pages/de/subgraphs/explorer.mdx
@@ -4,7 +4,7 @@ title: Graph Explorer
 
 Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
 
-## Overview
+## Überblick
 
 Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
 
@@ -131,7 +131,7 @@ If you want to learn more about how to become a Delegator, check out the [offici
 
 On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
 
-#### Overview
+#### Überblick
 
 The overview section has both all the current network metrics and some cumulative metrics over time:
 

From 6936394b43c26f40f4b24d49ca28c0e6f1e6e3ca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:02 -0500
Subject: [PATCH 2921/3820] New translations starting-your-subgraph.mdx
 (German)

---
 .../developing/creating/starting-your-subgraph.mdx     | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx
index 4823231d9a40..9288ed04e2ba 100644
--- a/website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx
+++ b/website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -1,14 +1,14 @@
 ---
-title: Starting Your Subgraph
+title: Starten Ihres Subgraphen
 ---
 
-## Overview
+## Überblick
 
-The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+The Graph beherbergt Tausende von Subgraphen, die bereits für Abfragen zur Verfügung stehen. Schauen Sie also in [The Graph Explorer] (https://thegraph.com/explorer) nach und finden Sie einen, der Ihren Anforderungen entspricht.
 
-When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+Wenn Sie einen [Subgraphen](/subgraphs/developing/subgraphs/) erstellen, erstellen Sie eine benutzerdefinierte offene API, die Daten aus einer Blockchain extrahiert, verarbeitet, speichert und über GraphQL einfach abfragen lässt.
 
-Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
+Die Entwicklung von Subgraphen reicht von einfachen Gerüst-Subgraphen bis hin zu fortgeschrittenen, speziell zugeschnittenen Subgraphen.
 
 ### Start Building
 

From d31704530400c5d734f8aed89f806f0625db3137 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:03 -0500
Subject: [PATCH 2922/3820] New translations introduction.mdx (German)

---
 website/pages/de/subgraphs/querying/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/querying/introduction.mdx b/website/pages/de/subgraphs/querying/introduction.mdx
index 2a195dc3da33..f1dff1d80e12 100644
--- a/website/pages/de/subgraphs/querying/introduction.mdx
+++ b/website/pages/de/subgraphs/querying/introduction.mdx
@@ -4,7 +4,7 @@ title: Querying The Graph
 
 To start querying right away, visit [The Graph Explorer](https://thegraph.com/explorer).
 
-## Overview
+## Überblick
 
 When a subgraph is published to The Graph Network, you can visit its subgraph details page on Graph Explorer and use the "Query" tab to explore the deployed GraphQL API for each subgraph.
 

From 62946d28bc8696a4379b28dd001bac110624d96a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:04 -0500
Subject: [PATCH 2923/3820] New translations delegating.mdx (German)

---
 website/pages/de/resources/roles/delegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/resources/roles/delegating.mdx b/website/pages/de/resources/roles/delegating.mdx
index a439332176eb..f0edb3551937 100644
--- a/website/pages/de/resources/roles/delegating.mdx
+++ b/website/pages/de/resources/roles/delegating.mdx
@@ -4,7 +4,7 @@ title: Delegieren
 
 To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-## Overview
+## Überblick
 
 Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 

From c2f3b192ea5e56290e25e06c94ea97581123b2c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:05 -0500
Subject: [PATCH 2924/3820] New translations tap.mdx (German)

---
 website/pages/de/indexing/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/indexing/tap.mdx b/website/pages/de/indexing/tap.mdx
index d2d87874bdbf..7044da441b95 100644
--- a/website/pages/de/indexing/tap.mdx
+++ b/website/pages/de/indexing/tap.mdx
@@ -4,7 +4,7 @@ title: TAP Migration Guide
 
 Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
 
-## Overview
+## Überblick
 
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
 

From 73404d896fc145c0b4ba4f825f11a59a21743bb8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:06 -0500
Subject: [PATCH 2925/3820] New translations advanced.mdx (German)

---
 website/pages/de/subgraphs/developing/creating/advanced.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/creating/advanced.mdx b/website/pages/de/subgraphs/developing/creating/advanced.mdx
index aa21fd14c492..0db68b112f5f 100644
--- a/website/pages/de/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/de/subgraphs/developing/creating/advanced.mdx
@@ -2,7 +2,7 @@
 title: Advanced Subgraph Features
 ---
 
-## Overview
+## Überblick
 
 Add and implement advanced subgraph features to enhanced your subgraph's built.
 
@@ -141,7 +141,7 @@ File data sources are a new subgraph functionality for accessing off-chain data
 
 > This also lays the groundwork for deterministic indexing of off-chain data, as well as the potential introduction of arbitrary HTTP-sourced data.
 
-### Overview
+### Überblick
 
 Rather than fetching files "in line" during handler execution, this introduces templates which can be spawned as new data sources for a given file identifier. These new data sources fetch the files, retrying if they are unsuccessful, running a dedicated handler when the file is found.
 

From 53d221cc6974509224fa3336485275b2e91cc701 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:07 -0500
Subject: [PATCH 2926/3820] New translations tokenomics.mdx (German)

---
 website/pages/de/resources/tokenomics.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/resources/tokenomics.mdx b/website/pages/de/resources/tokenomics.mdx
index ad73a800a803..210c1a2ecacf 100644
--- a/website/pages/de/resources/tokenomics.mdx
+++ b/website/pages/de/resources/tokenomics.mdx
@@ -3,7 +3,7 @@ title: Tokenomics des The Graph Netzwerks
 description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
 ---
 
-## Overview
+## Überblick
 
 The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
 

From cd6e6ed02bee2c03b082467f0263b97d19488447 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:08 -0500
Subject: [PATCH 2927/3820] New translations grafting-hotfix.mdx (German)

---
 website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx
index 96c0b5369ecb..5d783cc9703d 100644
--- a/website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/de/subgraphs/cookbook/grafting-hotfix.mdx
@@ -6,7 +6,7 @@ title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
 
 Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
 
-### Overview
+### Überblick
 
 This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
 

From 0a2c1bfaf8118ecb8c15e6af02b7f52ce163953d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:09 -0500
Subject: [PATCH 2928/3820] New translations secure-api-keys-nextjs.mdx
 (German)

---
 website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index 2f3973811197..0f18354ed9fc 100644
--- a/website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/de/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -2,7 +2,7 @@
 title: How to Secure API Keys Using Next.js Server Components
 ---
 
-## Overview
+## Überblick
 
 We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
 

From 0503c1f75444f381da028760c218b68750f5ddeb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:10 -0500
Subject: [PATCH 2929/3820] New translations timeseries.mdx (German)

---
 website/pages/de/subgraphs/cookbook/timeseries.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/cookbook/timeseries.mdx b/website/pages/de/subgraphs/cookbook/timeseries.mdx
index 0168be53d7ed..cb23f097e103 100644
--- a/website/pages/de/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/de/subgraphs/cookbook/timeseries.mdx
@@ -6,7 +6,7 @@ title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggr
 
 Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
 
-## Overview
+## Überblick
 
 Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
 

From a33a843b6e760dd4a79eafc85f9192acfcad051c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:11 -0500
Subject: [PATCH 2930/3820] New translations assemblyscript-mappings.mdx
 (German)

---
 .../subgraphs/developing/creating/assemblyscript-mappings.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/developing/creating/assemblyscript-mappings.mdx b/website/pages/de/subgraphs/developing/creating/assemblyscript-mappings.mdx
index 2ac894695fe1..4354181a33df 100644
--- a/website/pages/de/subgraphs/developing/creating/assemblyscript-mappings.mdx
+++ b/website/pages/de/subgraphs/developing/creating/assemblyscript-mappings.mdx
@@ -2,7 +2,7 @@
 title: Writing AssemblyScript Mappings
 ---
 
-## Overview
+## Überblick
 
 The mappings take data from a particular source and transform it into entities that are defined within your schema. Mappings are written in a subset of [TypeScript](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html) called [AssemblyScript](https://github.com/AssemblyScript/assemblyscript/wiki) which can be compiled to WASM ([WebAssembly](https://webassembly.org/)). AssemblyScript is stricter than normal TypeScript, yet provides a familiar syntax.
 

From 28b539acc237712efa5cafbad82389e294909545 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:12 -0500
Subject: [PATCH 2931/3820] New translations install-the-cli.mdx (German)

---
 .../pages/de/subgraphs/developing/creating/install-the-cli.mdx  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/developing/creating/install-the-cli.mdx b/website/pages/de/subgraphs/developing/creating/install-the-cli.mdx
index d10486b1d5a0..aae556a7c090 100644
--- a/website/pages/de/subgraphs/developing/creating/install-the-cli.mdx
+++ b/website/pages/de/subgraphs/developing/creating/install-the-cli.mdx
@@ -4,7 +4,7 @@ title: Install the Graph CLI
 
 > In order to use your subgraph on The Graph's decentralized network, you will need to [create an API key](/subgraphs/developing/deploying/subgraph-studio-faq/#2-how-do-i-create-an-api-key) in [Subgraph Studio](https://thegraph.com/studio/apikeys/). It is recommended that you add signal to your subgraph with at least 3,000 GRT to attract 2-3 Indexers. To learn more about signaling, check out [curating](/resources/roles/curating/).
 
-## Overview
+## Überblick
 
 The [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a command-line interface that facilitates developers' commands for The Graph. It processes a [subgraph manifest](/subgraphs/developing/creating/subgraph-manifest/) and compiles the [mappings](/subgraphs/developing/creating/assemblyscript-mappings/) to create the files you will need to deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) and the network.
 

From 0d5b885ba9508e8ef605f15c194830e2d63fb180 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:13 -0500
Subject: [PATCH 2932/3820] New translations ql-schema.mdx (German)

---
 website/pages/de/subgraphs/developing/creating/ql-schema.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/developing/creating/ql-schema.mdx b/website/pages/de/subgraphs/developing/creating/ql-schema.mdx
index c4543695571c..3648340f055d 100644
--- a/website/pages/de/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/de/subgraphs/developing/creating/ql-schema.mdx
@@ -2,7 +2,7 @@
 title: The Graph QL Schema
 ---
 
-## Overview
+## Überblick
 
 The schema for your subgraph is in the file `schema.graphql`. GraphQL schemas are defined using the GraphQL interface definition language.
 

From 90d90e9470dde4f9743e4e6b584b084cae07b160 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:14 -0500
Subject: [PATCH 2933/3820] New translations subgraph-manifest.mdx (German)

---
 .../de/subgraphs/developing/creating/subgraph-manifest.mdx      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/developing/creating/subgraph-manifest.mdx b/website/pages/de/subgraphs/developing/creating/subgraph-manifest.mdx
index caeba44d5358..a3959f1f4d57 100644
--- a/website/pages/de/subgraphs/developing/creating/subgraph-manifest.mdx
+++ b/website/pages/de/subgraphs/developing/creating/subgraph-manifest.mdx
@@ -2,7 +2,7 @@
 title: Subgraph Manifest
 ---
 
-## Overview
+## Überblick
 
 Das Subgraph-Manifest, `subgraph.yaml`, definiert die Smart Contracts und das Netzwerk, die Ihr Subgraph indizieren wird, die Ereignisse aus diesen Verträgen, auf die geachtet werden soll, und wie die Ereignisdaten auf Entitäten abgebildet werden, die Graph Node speichert und abfragen kann.
 

From b025300088aff890c0545aab8ccb08521152ad60 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:15 -0500
Subject: [PATCH 2934/3820] New translations introduction.mdx (German)

---
 website/pages/de/subgraphs/developing/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/developing/introduction.mdx b/website/pages/de/subgraphs/developing/introduction.mdx
index a3dea2c9a29d..2cd6b9029170 100644
--- a/website/pages/de/subgraphs/developing/introduction.mdx
+++ b/website/pages/de/subgraphs/developing/introduction.mdx
@@ -4,7 +4,7 @@ title: Introduction to Subgraph Development
 
 To start coding right away, go to [Developer Quick Start](/subgraphs/quick-start/).
 
-## Overview
+## Überblick
 
 As a developer, you need data to build and power your dapp. Querying and indexing blockchain data is challenging, but The Graph provides a solution to this issue.
 

From 15a90b6e3ee79e35ef5d162c62f531bcb90c97ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 10:22:16 -0500
Subject: [PATCH 2935/3820] New translations managing-api-keys.mdx (German)

---
 website/pages/de/subgraphs/querying/managing-api-keys.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/querying/managing-api-keys.mdx b/website/pages/de/subgraphs/querying/managing-api-keys.mdx
index f7aff33ea926..2a4d92726084 100644
--- a/website/pages/de/subgraphs/querying/managing-api-keys.mdx
+++ b/website/pages/de/subgraphs/querying/managing-api-keys.mdx
@@ -2,7 +2,7 @@
 title: Managing your API keys
 ---
 
-## Overview
+## Überblick
 
 API keys are needed to query subgraphs. They ensure that the connections between application services are valid and authorized, including authenticating the end user and the device using the application.
 

From 59ef3e0ffeffbf130866abc44c3f4a1c64d4a4be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 11:23:31 -0500
Subject: [PATCH 2936/3820] New translations starting-your-subgraph.mdx
 (German)

---
 .../creating/starting-your-subgraph.mdx          | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx
index 9288ed04e2ba..dbffb92cfc5e 100644
--- a/website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx
+++ b/website/pages/de/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -10,14 +10,14 @@ Wenn Sie einen [Subgraphen](/subgraphs/developing/subgraphs/) erstellen, erstell
 
 Die Entwicklung von Subgraphen reicht von einfachen Gerüst-Subgraphen bis hin zu fortgeschrittenen, speziell zugeschnittenen Subgraphen.
 
-### Start Building
+### Start des Erstellens
 
-Start the process and build a subgraph that matches your needs:
+Starten Sie den Prozess und erstellen Sie einen Subgraphen, der Ihren Anforderungen entspricht:
 
-1. [Install the CLI](/subgraphs/developing/creating/install-the-cli/) - Set up your infrastructure
-2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Understand a subgraph's key component
-3. [The GraphQL Schema](/subgraphs/developing/creating/ql-schema/) - Write your schema
-4. [Writing AssemblyScript Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Write your mappings
-5. [Advanced Features](/subgraphs/developing/creating/advanced/) - Customize your subgraph with advanced features
+1. [Installieren der CLI](/subgraphs/developing/creating/install-the-cli/) - Richten Sie Ihre Infrastruktur ein
+2. [Subgraph Manifest](/subgraphs/developing/creating/subgraph-manifest/) - Verstehen der wichtigsten Komponenten eines Subgraphen
+3. [Das GraphQL-Schema](/subgraphs/developing/creating/ql-schema/) - Schreiben Sie Ihr Schema
+4. [Schreiben von AssemblyScript-Mappings](/subgraphs/developing/creating/assemblyscript-mappings/) - Schreiben Sie Ihre Mappings
+5. [Erweiterte Funktionen](/subgraphs/developing/creating/advanced/) - Passen Sie Ihren Subgraph mit erweiterten Funktionen an
 
-Explore additional [resources for APIs](/subgraphs/developing/creating/graph-ts/README/) and conduct local testing with [Matchstick](/subgraphs/developing/creating/unit-testing-framework/).
+Erkunden Sie zusätzliche [Ressourcen für APIs](/subgraphs/developing/creating/graph-ts/README/) und führen Sie lokale Tests mit [Matchstick](/subgraphs/developing/creating/unit-testing-framework/) durch.

From 44a7e6da4f561ca3b61768329c7d1c8b27c2f2ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 11:23:32 -0500
Subject: [PATCH 2937/3820] New translations delegating.mdx (German)

---
 .../pages/de/resources/roles/delegating.mdx   | 34 +++++++++----------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/de/resources/roles/delegating.mdx b/website/pages/de/resources/roles/delegating.mdx
index f0edb3551937..d6dedfac53ca 100644
--- a/website/pages/de/resources/roles/delegating.mdx
+++ b/website/pages/de/resources/roles/delegating.mdx
@@ -91,22 +91,22 @@ As a result, it’s recommended that you choose an Indexer wisely.
 
 Um zu verstehen, wie man einen vertrauenswürdigen Indexer auswählt, müssen Sie die Delegationsparameter verstehen.
 
-- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
-  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
-  - If it is set to 80%, as a Delegator, you will receive 20%.
+- **Indizierung der Rewardkürzung** - Der Teil der Rewards, den der Indexer für sich selbst behält.
+  - Wenn die Rewardkürzung eines Indexers auf 100% eingestellt ist, erhalten Sie als Delegator 0 Rewards für die Indexierung.
+  - Wenn er auf 80 % eingestellt ist, erhalten Sie als Delegator 20 %.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
-  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+![Indizierung der Rewardkürzung](/img/Indexing-Reward-Cut.png) *Der oberste Indexer gibt den Delegatoren 90 % der Rewards. Der
+mittlere gibt den Delegatoren 20 %. Der untere gibt den Delegatoren ~83 %.*
 </div>
 
-- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+- **Kürzung der Abfragegebühren** - Dies ist genau wie die Indizierung der Rewardkürzung, aber es gilt für die Renditen der Abfragegebühren, die der Indexer einnimmt.
 
 - It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
 - Many Indexers are active in Discord and will be happy to answer your questions.
 
-## Calculating Delegators Expected Return
+## Berechnung der erwarteten Rendite der Delegatoren
 
 > Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
@@ -118,27 +118,27 @@ If an Indexer does not allocate all the GRT at their disposal, they may miss out
 
 Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
-### Considering the query fee cut and indexing fee cut
+### Berücksichtigung der Senkung der Abfrage- und Indizierungsgebühren
 
 You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
-The formula is:
+Die Formel lautet:
 
-![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+![Delegationsbild 3](/img/Delegation-Reward-Formula.png)
 
-### Considering the Indexer's delegation pool
+### Berücksichtigung des Delegationspools des Indexers
 
 <VideoEmbed youtube="G0HyUZ0m_Q8" />
 
-Delegators should consider the proportion of the Delegation Pool they own.
+Die Delegatoren sollten sich überlegen, welchen Anteil am Delegationspool sie besitzen.
 
-All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+Alle Rewards der Delegatoren werden gleichmäßig aufgeteilt, wobei sich der Pool nach dem Betrag richtet, den der Delegator in den Pool eingezahlt hat.
 
-This gives the Delegator a share of the pool:
+Dadurch erhält der Delegator einen Anteil am Pool:
 
-![Share formula](/img/Share-Forumla.png)
+![Formel teilen](/img/Share-Forumla.png)
 
-> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+> Die obige Formel zeigt, dass es möglich ist, dass ein Indexer, der den Delegatoren nur 20 % anbietet, einen besseren Reward erzielt als ein Indexer, der 90 % bietet. Rechnen Sie einfach nach, um die beste Reward zu ermitteln.
 
 ## Delegator FAQs und Bugs
 
@@ -146,4 +146,4 @@ This gives the Delegator a share of the pool:
 
 Gelegentlich können Versuche, Indexer über MetaMask zu delegieren, fehlschlagen und zu längeren Zeiträumen mit „Pending“ oder „Queued“ Transaktionsversuchen führen.
 
-A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+Eine einfache Lösung für diesen Fehler ist der Neustart des Browsers (z. B. mit „abort:restart“ in der Adressleiste), wodurch alle vorherigen Versuche abgebrochen werden, ohne dass Gas von der Wallet abgezogen wird. Mehrere Benutzer, die auf dieses Problem gestoßen sind, haben von erfolgreichen Transaktionen berichtet, nachdem sie ihren Browser neu gestartet und versucht haben, zu delegieren.

From c21a1d651fe6c6f244cbdd6e6a76b9a1289d4c25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 11:23:33 -0500
Subject: [PATCH 2938/3820] New translations graphcast.mdx (German)

---
 website/pages/de/indexing/tooling/graphcast.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/indexing/tooling/graphcast.mdx b/website/pages/de/indexing/tooling/graphcast.mdx
index 4072877a1257..1ecf1637c9fc 100644
--- a/website/pages/de/indexing/tooling/graphcast.mdx
+++ b/website/pages/de/indexing/tooling/graphcast.mdx
@@ -2,9 +2,9 @@
 title: Graphcast
 ---
 
-## Introduction
+## Einführung
 
-Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+Gibt es etwas, von dem Sie gerne lernen würden oder das Sie gerne mit anderen Indexern teilen würden, aber das ist Ihnen zu mühsam oder kostet zu viel Gas?
 
 Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
 

From 1dbbf5c8f4f5d39bd32a71b43a495a16a225dfd3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 13:05:35 -0500
Subject: [PATCH 2939/3820] New translations supported-network-requirements.mdx
 (German)

---
 .../supported-network-requirements.mdx        | 30 +++++++++----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/de/indexing/supported-network-requirements.mdx b/website/pages/de/indexing/supported-network-requirements.mdx
index afbf755c0a5a..7bbfce189885 100644
--- a/website/pages/de/indexing/supported-network-requirements.mdx
+++ b/website/pages/de/indexing/supported-network-requirements.mdx
@@ -1,18 +1,18 @@
 ---
-title: Supported Network Requirements
+title: Unterstützte Netzwerkanforderungen
 ---
 
-| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
-| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
-| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
-| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
-| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
-| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
-| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
-| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
-| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
-| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |
+| Netzwerk  | Guides                                                                                                                                                                                                                                                                                              | Systemanforderungen                                                                                                                                | Indexing Rewards |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
+| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                                            |         ✅        |
+| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                                 |         ✅        |
+| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_                        |         ✅        |
+| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_                          |         ✅        |
+| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                                 |         ✅        |
+| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Höhere Taktfrequenz im Vergleich zur Kernanzahl<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
+| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                                |         ✅        |
+| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                                |         ✅        |
+| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                                         |         ✅        |
+| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                                 |         ✅        |
+| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                                           |         ✅        |
+| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                                 |         ✅        |

From 09a41fcf7bfcc50560e3ca0645721ee35f78c621 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 13:05:37 -0500
Subject: [PATCH 2940/3820] New translations firehose.mdx (German)

---
 website/pages/de/indexing/tooling/firehose.mdx | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/de/indexing/tooling/firehose.mdx b/website/pages/de/indexing/tooling/firehose.mdx
index 381fc0f4c091..9ec4cc3c1908 100644
--- a/website/pages/de/indexing/tooling/firehose.mdx
+++ b/website/pages/de/indexing/tooling/firehose.mdx
@@ -4,21 +4,21 @@ title: Firehose
 
 ![Firehose Logo](/img/firehose-logo.png)
 
-Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+Firehose ist eine neue Technologie, die von StreamingFast in Zusammenarbeit mit The Graph Foundation entwickelt wurde. Das Produkt bietet **noch nie dagewesene Fähigkeiten und Geschwindigkeiten für die Indizierung von Blockchain-Daten** mit einem dateibasierten und Streaming-first-Ansatz.
 
-The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+The Graph geht mit der Einführung von [Live Tracer mit Version v1.14.0] (https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0) in Go Ethereum/geth auf.
 
-Firehose extracts, transforms and saves blockchain data in a highly performant file-based strategy. Blockchain developers can then access data extracted by Firehose through binary data streams. Firehose is intended to stand as a replacement for The Graph’s original blockchain data extraction layer.
+Firehose extrahiert, transformiert und speichert Blockchain-Daten in einer hochleistungsfähigen dateibasierten Strategie. Blockchain-Entwickler können dann auf die von Firehose extrahierten Daten über binäre Datenströme zugreifen. Firehose soll als Ersatz für die ursprüngliche Blockchain-Datenextraktionsschicht von The Graph dienen.
 
-## Firehose Documentation
+## Firehose-Dokumentation
 
-The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+Die Firehose-Dokumentation wird derzeit vom StreamingFast-Team [auf der StreamingFast-Website] (https://firehose.streamingfast.io/) gepflegt.
 
 ### Erste Schritte
 
-- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
-- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+- Lesen Sie diese [Firehose-Einführung] (https://firehose.streamingfast.io/introduction/firehose-overview), um einen Überblick darüber zu erhalten, was es ist und warum es entwickelt wurde.
+- Informieren Sie sich über die [Voraussetzungen](https://firehose.streamingfast.io/introduction/prerequisites) zur Installation und Bereitstellung von Firehose.
 
-### Expand Your Knowledge
+### Erweitern Sie Ihr Wissen
 
-- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.
+- Erfahren Sie mehr über die verschiedenen [Firehose-Komponenten](https://firehose.streamingfast.io/architecture/components), die verfügbar sind.

From 7a149ab1bd86f0b0ca63a9db17e1463085039840 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 13:05:38 -0500
Subject: [PATCH 2941/3820] New translations graphcast.mdx (German)

---
 .../pages/de/indexing/tooling/graphcast.mdx    | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/de/indexing/tooling/graphcast.mdx b/website/pages/de/indexing/tooling/graphcast.mdx
index 1ecf1637c9fc..ed3f8db0e9d8 100644
--- a/website/pages/de/indexing/tooling/graphcast.mdx
+++ b/website/pages/de/indexing/tooling/graphcast.mdx
@@ -6,16 +6,16 @@ title: Graphcast
 
 Gibt es etwas, von dem Sie gerne lernen würden oder das Sie gerne mit anderen Indexern teilen würden, aber das ist Ihnen zu mühsam oder kostet zu viel Gas?
 
-Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+Derzeit werden die Kosten für die Übertragung von Informationen an andere Netzwerkteilnehmer durch Gasgebühren auf der Ethereum-Blockchain bestimmt. Graphcast löst dieses Problem, indem es als optionales dezentrales, verteiltes Peer-to-Peer (P2P)-Kommunikationstool fungiert, das es Indexern im gesamten Netzwerk ermöglicht, Informationen in Echtzeit auszutauschen. Die Kosten für den Austausch von P2P-Nachrichten sind nahezu gleich Null, wobei die Integrität der Daten nicht garantiert ist. Nichtsdestotrotz zielt Graphcast darauf ab, Garantien für die Gültigkeit von Nachrichten (d.h. dass die Nachricht gültig und von einem bekannten Protokollteilnehmer signiert ist) mit einem offenen Designraum von Reputationsmodellen zu bieten.
 
-The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+Das Graphcast SDK (Software Development Kit) ermöglicht es Entwicklern, Radios zu erstellen, d.h. klatschgesteuerte Anwendungen, die Indexer ausführen können, um einen bestimmten Zweck zu erfüllen. Wir beabsichtigen auch, einige Radios für die folgenden Anwendungsfälle zu erstellen (oder anderen Entwicklern/Teams, die Radios erstellen möchten, Unterstützung zu bieten):
 
-- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
-- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
-- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
-- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
-- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+- Echtzeit-Überprüfung der Integrität von Subgraph-Daten ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio/intro)).
+- Durchführung von Auktionen und Koordination für die Warp-Synchronisierung von Subgraphen, Substreams und Firehose-Daten von anderen Indexern.
+- Selbstauskunft über die Analyse aktiver Abfragen, einschließlich Subgraph-Anfragevolumen, Gebührenvolumen usw.
+- Selbstauskunft über die Indizierungsanalyse, einschließlich der Zeit für die Indizierung von Subgraphen, Gaskosten für die Bearbeitung, aufgetretene Indexierungsfehler usw.
+- Selbstauskunft über Stack-Informationen, einschließlich Graph-Node-Version, Postgres-Version, Ethereum-Client-Version, usw.
 
-### Learn More
+### Weitere Informationen
 
-If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)
+Wenn Sie mehr über Graphcast erfahren möchten, schauen Sie sich die Dokumentation an (https://docs.graphops.xyz/graphcast/intro)

From 746be08e699a6370a81ca850210c8fe8001857f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 13:05:39 -0500
Subject: [PATCH 2942/3820] New translations introduction.mdx (German)

---
 website/pages/de/substreams/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/substreams/introduction.mdx b/website/pages/de/substreams/introduction.mdx
index 15cdbe92cea7..2b2dcc762cb4 100644
--- a/website/pages/de/substreams/introduction.mdx
+++ b/website/pages/de/substreams/introduction.mdx
@@ -43,7 +43,7 @@ To learn about the latest version of Substreams CLI, which enables developers to
 - In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
 - Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
 
-### Expand Your Knowledge
+### Erweitern Sie Ihr Wissen
 
 - Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
 

From bea90fb1efffd34bd94cf8fef8f06b2dc0e2ea57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 13:05:40 -0500
Subject: [PATCH 2943/3820] New translations supported-networks.json (German)

---
 website/pages/de/supported-networks.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/supported-networks.json b/website/pages/de/supported-networks.json
index 9ae5a4b5aae8..f03e5820151a 100644
--- a/website/pages/de/supported-networks.json
+++ b/website/pages/de/supported-networks.json
@@ -1,5 +1,5 @@
 {
-  "network": "Network",
+  "network": "Netzwerk",
   "cliName": "CLI Name",
   "chainId": "Chain ID",
   "hostedService": "Hosted Service",

From 59cd83d602960bebe47af01c915a1ebd790b5aaa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:23:11 -0500
Subject: [PATCH 2944/3820] New translations new-chain-integration.mdx (French)

---
 .../fr/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/fr/indexing/new-chain-integration.mdx b/website/pages/fr/indexing/new-chain-integration.mdx
index 2b3717f5030c..c2e13431e110 100644
--- a/website/pages/fr/indexing/new-chain-integration.mdx
+++ b/website/pages/fr/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Créez un exemple de subgraph simple. Certaines options sont ci-dessous :
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node devrait synchroniser le subgraph déployé s'il n'y a pas d'erreurs. Laissez-lui le temps de se synchroniser, puis envoyez des requêtes GraphQL au point de terminaison de l'API indiqué dans les journaux.
-
 ## Substreams-powered Subgraphs
 
 Pour les intégrations Firehose/Substreams pilotées par StreamingFast, la prise en charge de base des modules Substreams fondamentaux (par exemple, les transactions décodées, les logs et les événements smart-contract) et les outils codegen Substreams sont inclus. Ces outils permettent d'activer des [subgraphs alimentés par Substreams](/substreams/sps/introduction/). Suivez le [Guide pratique](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) et exécutez `substreams codegen subgraph` pour expérimenter les outils codegen par vous-même.

From 656b8742b955d0787d4abc376523da7e0870ca31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:23:21 -0500
Subject: [PATCH 2945/3820] New translations new-chain-integration.mdx
 (Portuguese)

---
 .../pt/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/pt/indexing/new-chain-integration.mdx b/website/pages/pt/indexing/new-chain-integration.mdx
index 2d86905acd7f..1c4ecd22c293 100644
--- a/website/pages/pt/indexing/new-chain-integration.mdx
+++ b/website/pages/pt/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ Para que o Graph Node possa ingerir dados de uma chain EVM, o node RPC deve expo
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, em um pedido conjunto em JSON-RPC
-- `trace_filter` (opcional, para que o Graph Node tenha apoio a handlers de chamada)\*
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Integração do Firehose
 
 O [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) é uma camada de extração de última geração, que coleta históricos em streams e arquivos planos em tempo real. A tecnologia do Firehose substitui estas chamadas de API com um fluxo de dados que utilizam um modelo de empurrão que envia dados ao node de indexação mais rapidamente. Isto ajuda a aumentar a velocidade da sincronização e da indexação.
 
-O método principal de integrar o Firehose a chains é uma estratégia de polling de RPC. O nosso algoritmo de polling preverá quando um bloco novo irá chegar, e aumentará o ritmo em que ele verifica por um novo bloco quando se aproximar daquela hora, o que o faz uma solução de baixa latência muito eficiente. Para ajuda com a integração e a manutenção do Firehose, contacte a [equipa do StreamingFast](https://www.streamingfast.io/firehose-integration-program). Novas chains e os seus integrantes apreciarão a [consciência de fork](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) e as capacidades imensas de indexação paralelizada que o Firehose e os Substreams trazem ao seu ecossistema.
-
 > NOTA: Todas as integrações feitas pela equipa da StreamingFast incluem manutenção para o protocolo de réplica do Firehose no banco de código da chain. O StreamingFast rastreia todas as mudanças e lança binários quando o código é mudado, pelo programador ou pela StreamingFast. Isto inclui o lançamento de binários do Firehose/Substreams para o protocolo, a manutenção dos módulos de Substreams para o modelo de bloco da chain, e o lançamento de binários para o node da blockchain com a instrumentação, caso necessária.
 
-#### Instrumentação Específica do Firehose para chains EVM (`geth`)
+#### Integration for Non-EVM chains
+
+O método principal de integrar o Firehose a chains é uma estratégia de polling de RPC. O nosso algoritmo de polling preverá quando um bloco novo irá chegar, e aumentará o ritmo em que ele verifica por um novo bloco quando se aproximar daquela hora, o que o faz uma solução de baixa latência muito eficiente. Para ajuda com a integração e a manutenção do Firehose, contacte a [equipa do StreamingFast](https://www.streamingfast.io/firehose-integration-program). Novas chains e os seus integrantes apreciarão a [consciência de fork](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) e as capacidades imensas de indexação paralelizada que o Firehose e os Substreams trazem ao seu ecossistema.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 Para chains EVM, há um nível mais profundo de dados que podem ser alcançados através do [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0) `geth`, uma colaboração entre a Go-Ethereum e a StreamingFast, na construção de um sistema de traços rico e de alto throughput. O Live Tracer é a solução mais compreensiva, o que resulta em detalhes de blocos [Estendidos](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425). Isto permite novos paradigmas de indexação, como correspondência de padrões de eventos com base em mudanças no estado, chamadas, árvores de chamadas de parentes, ou o acionamento de eventos com base nas mudanças nas próprias variáveis em um contrato inteligente.
 
@@ -57,24 +59,12 @@ Configurar um Graph Node é tão fácil quanto preparar o seu ambiente local. Qu
 
 1. [Clone o Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modifique [esta linha](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) para ela incluir o nome da nova rede e a URL do EVM JSON-RPC
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Não mude o nome do env var. Ele deve permanecer como `ethereum` mesmo se o nome da rede for diferente.
 
 3. Execute um node IPFS ou use aquele usado pelo The Graph: https://api.thegraph.com/ipfs/
 
-### Como testar um JSON-RPC com a edição local de um subgraph
-
-1. Instale a [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Crie um subgraph de exemplo simples. Aqui estão algumas opções:
-   1. O contrato inteligente e o subgraph [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) pré-inclusos são bons pontos de partida
-   2. Inicie um subgraph local a partir de qualquer contrato inteligente existente ou de um ambiente de programação em solidity [com o uso do Hardhat com um plugin do Graph](https://github.com/graphprotocol/hardhat-graph)
-3. Adapte o `subgraph.yaml` resultante com a mudança do  `dataSources.network` para o mesmo nome passado anteriormente ao Graph Node.
-4. Crie o seu subgraph no Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Edite o seu subgraph no Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-O Graph Node deve então sincronizar o subgraph lançado caso não haja erros. Deixe-o sincronizar por um tempo, e depois envie alguns queries em GraphQL ao endpoint da API produzido pelos logs.
-
 ## Subgraphs movidos por Substreams
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From f892927c6570d965d8d2d923e931b8f1d193015e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:23:23 -0500
Subject: [PATCH 2946/3820] New translations introduction.mdx (Portuguese)

---
 website/pages/pt/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/pt/substreams/introduction.mdx b/website/pages/pt/substreams/introduction.mdx
index 6436b653cd96..08ac132ff32b 100644
--- a/website/pages/pt/substreams/introduction.mdx
+++ b/website/pages/pt/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Visão geral
 
-## Como o Substreams funciona em 4 passos
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Documentação do Substreams
+## Como o Substreams funciona em 4 passos
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Como Começar
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expanda o Seu Conhecimento
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Outros Recursos
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 97bd55868307b9ed72e1f3cb3c2bb8c078cac7b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:23:43 -0500
Subject: [PATCH 2947/3820] New translations new-chain-integration.mdx
 (Romanian)

---
 .../ro/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/ro/indexing/new-chain-integration.mdx b/website/pages/ro/indexing/new-chain-integration.mdx
index 695f07957a69..7c9f8a5c65c4 100644
--- a/website/pages/ro/indexing/new-chain-integration.mdx
+++ b/website/pages/ro/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From fcb06076ddc2acfb24773bbf9510b051ac7b710f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:23:45 -0500
Subject: [PATCH 2948/3820] New translations introduction.mdx (Romanian)

---
 website/pages/ro/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/ro/substreams/introduction.mdx b/website/pages/ro/substreams/introduction.mdx
index 4fd0efb697aa..25fcfa5a5c2c 100644
--- a/website/pages/ro/substreams/introduction.mdx
+++ b/website/pages/ro/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Overview
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Getting Started
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Additional Resources
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 9b6fbef3d38151fb3b602e576a7084a05fb95a62 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:23:47 -0500
Subject: [PATCH 2949/3820] New translations introduction.mdx (French)

---
 website/pages/fr/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/fr/substreams/introduction.mdx b/website/pages/fr/substreams/introduction.mdx
index 975805709e67..2025456bb1ff 100644
--- a/website/pages/fr/substreams/introduction.mdx
+++ b/website/pages/fr/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Aperçu
 
-## Le fonctionnement de Substreams en 4 étapes
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Documentation des Substreams
+## Le fonctionnement de Substreams en 4 étapes
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Introduction
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Élargissez vos connaissances
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Ressources supplémentaires
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From cbb08aabb1bda69a52ac99570d9c144f2ef4e597 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:02 -0500
Subject: [PATCH 2950/3820] New translations new-chain-integration.mdx
 (Russian)

---
 .../ru/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/ru/indexing/new-chain-integration.mdx b/website/pages/ru/indexing/new-chain-integration.mdx
index 51afe29b5784..95e8621267d8 100644
--- a/website/pages/ru/indexing/new-chain-integration.mdx
+++ b/website/pages/ru/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ title: Интеграция новых чейнов
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt` в пакетном запросе JSON-RPC
-- `trace_filter` _(необязателен для Graph Node для поддержки обработчиков вызовов)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Интеграция Firehose
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) — это слой извлечения нового поколения. Он собирает историю в плоских файлах и передает ее в реальном времени. Технология Firehose заменяет эти вызовы API опросов потоком данных с использованием модели push, которая быстрее отправляет данные на ноду индексирования. Это помогает увеличить скорость синхронизации и индексирования.
 
-Основной метод интеграции Firehose в чейны — использование стратегии опроса RPC. Наш алгоритм опроса предсказывает, когда поступит новый блок, и увеличивает скорость проверки наличия нового блока в ближайшее время, что делает его эффективным решением с очень низкой задержкой. За помощью по интеграции и обслуживанию Firehose обращайтесь к [команде StreamingFast] (https://www.streamingfast.io/firehose-integration-program). Новые чейны и их интеграторы по достоинству оценят [осведомленность о форках](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) и огромные возможности параллельного индексирования, которые Firehose и Substreams привносят в их экосистему.
-
 > ПРИМЕЧАНИЕ: Все интеграции, выполненные командой StreamingFast, включают обслуживание протокола репликации Firehose в кодовой базе чейна. StreamingFast отслеживает любые изменения и выпускает двоичные файлы, когда Вы изменяете код и когда StreamingFast изменяет код. Сюда входит выпуск двоичных файлов Firehose/Substreams для протокола, поддержка модулей Substreams для блочной модели чейна и выпуск двоичных файлов для ноды блокчейна с оснащением инструментами, если это необходимо.
 
-#### Специальное оснащение Firehose для чейнов EVM (`geth`)
+#### Integration for Non-EVM chains
+
+Основной метод интеграции Firehose в чейны — использование стратегии опроса RPC. Наш алгоритм опроса предсказывает, когда поступит новый блок, и увеличивает скорость проверки наличия нового блока в ближайшее время, что делает его эффективным решением с очень низкой задержкой. За помощью по интеграции и обслуживанию Firehose обращайтесь к [команде StreamingFast] (https://www.streamingfast.io/firehose-integration-program). Новые чейны и их интеграторы по достоинству оценят [осведомленность о форках](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) и огромные возможности параллельного индексирования, которые Firehose и Substreams привносят в их экосистему.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 Для чейнов EVM существует более глубокий уровень данных, который может быть достигнут с помощью `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), сотрудничества между Go-Ethereum и StreamingFast, для создания высокопроизводительной и богатой системы отслеживания транзакций. Live Tracer — наиболее комплексное решение, позволяющее получать [Расширенные](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) детали блоков. Это позволяет использовать новые парадигмы индексирования, такие как сопоставление шаблонов событий на основе изменений состояния, вызовов, деревьев вызовов более высокого уровня или запуск событий на основе изменений фактических переменных в смарт-контракте.
 
@@ -57,24 +59,12 @@ title: Интеграция новых чейнов
 
 1. [Клонировать Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Измените [эту строку](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22), включив в неё новое имя сети и URL-адрес, совместимый с EVM JSON-RPC
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Не меняйте само имя переменной env. Оно должно оставаться `ethereum`, даже если имя сети отличается.
 
 3. Запустите ноду IPFS или используйте ту, которая используется The Graph: https://api.thegraph.com/ipfs/
 
-### Тестирование EVM JSON-RPC посредством локального развертывания субграфа
-
-1. Установите [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Создайте простой пример субграфа. Несколько вариантов приведены ниже:
-   1. Предварительно упакованные смарт-контракт [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) и субграф являются хорошей отправной точкой
-   2. Загрузите локальный субграф из любого существующего смарт-контракта или среды разработки Solidity [используя Hardhat с плагином Graph](https://github.com/graphprotocol/hardhat-graph)
-3. Адаптируйте полученный `subgraph.yaml`, изменив `dataSources.network` на то же имя, которое ранее было передано в Graph Node.
-4. Создайте свой субграф в Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Опубликуйте свой субграф в Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph нода должна синхронизировать развернутый субграф, если нет ошибок. Дайте ему время на синхронизацию, затем отправьте несколько запросов GraphQL на API-эндпоинт, указанный в логах.
-
 ## Субграфы, работающие на основе субпотоков (Substreams)
 
 Для интеграции Firehose/Substreams под управлением StreamingFast включена базовая поддержка фундаментальных модулей Substreams (например, декодированные транзакции, логи и события смарт-контрактов) и инструментов генерации кодов Substreams. Эти инструменты позволяют включать [субграфы на базе субпотоков](/substreams/sps/introduction/). Следуйте [Практическому руководству] (https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) и запустите `substreams codegen subgraph`, чтобы самостоятельно испробовать инструменты кодирования.

From bd06a7df1bdde6f91db83a44506dad113a903dd2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:04 -0500
Subject: [PATCH 2951/3820] New translations new-chain-integration.mdx (Chinese
 Simplified)

---
 .../zh/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/zh/indexing/new-chain-integration.mdx b/website/pages/zh/indexing/new-chain-integration.mdx
index 08629901b7d9..8c2ecddb63ef 100644
--- a/website/pages/zh/indexing/new-chain-integration.mdx
+++ b/website/pages/zh/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [克隆Graph节点](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. 创建一个简单的示例子图。以下是一些选项：
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-如果没有错误，Graph节点应该正在同步部署的子图。给它一些时间来同步，然后向API端点发送一些GraphQL查询。
-
 ## Substreams驱动的子图
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 2cd9ef1cc2daed125351f4efdc745cda801c37a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:05 -0500
Subject: [PATCH 2952/3820] New translations new-chain-integration.mdx
 (Spanish)

---
 .../es/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/es/indexing/new-chain-integration.mdx b/website/pages/es/indexing/new-chain-integration.mdx
index 4d4a51ff22b6..070442ca3a6e 100644
--- a/website/pages/es/indexing/new-chain-integration.mdx
+++ b/website/pages/es/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, en una solicitud por lotes JSON-RPC
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Crea un subgrafo simple de prueba. Algunas opciones están a continuación:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node debería sincronizar el subgrafo implementado si no hay errores. Dale tiempo para que se sincronice y luego envíe algunas queries GraphQL al punto final de la API impreso en los registros.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From c0319cad74d5b8b1456793706a5aee2aa3f563fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:06 -0500
Subject: [PATCH 2953/3820] New translations introduction.mdx (Spanish)

---
 website/pages/es/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/es/substreams/introduction.mdx b/website/pages/es/substreams/introduction.mdx
index aca614fd3de9..37e38a41fa3d 100644
--- a/website/pages/es/substreams/introduction.mdx
+++ b/website/pages/es/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Descripción
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Empezando
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Recursos Adicionales
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From d37c80a23f1763d4c32c741534553a245058fb13 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:08 -0500
Subject: [PATCH 2954/3820] New translations new-chain-integration.mdx (Arabic)

---
 .../ar/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/ar/indexing/new-chain-integration.mdx b/website/pages/ar/indexing/new-chain-integration.mdx
index c75ec800a485..60ac68afc55f 100644
--- a/website/pages/ar/indexing/new-chain-integration.mdx
+++ b/website/pages/ar/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`، ضمن طلب دفعة استدعاء الإجراء عن بُعد باستخدام تمثيل كائنات جافا سكريبت
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [استنسخ عقدة الغراف](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. قم بإنشاء مثالًا بسيطًا للغراف الفرعي. بعض الخيارات المتاحة هي كالتالي:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-إذا لم تكن هناك أخطاء يجب أن يقوم عقدة الغراف بمزامنة الغراف الفرعي المنشور. قم بمنحه بعض الوقت لإتمام عملية المزامنة، ثم قم بإرسال بعض استعلامات لغة الإستعلام للغراف (GraphQL) إلى نقطة نهاية واجهة برمجة التطبيقات الموجودة في السجلات.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 1246f853ba26ef71d1a3d0ecca0732678c452f92 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:10 -0500
Subject: [PATCH 2955/3820] New translations introduction.mdx (Arabic)

---
 website/pages/ar/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/ar/substreams/introduction.mdx b/website/pages/ar/substreams/introduction.mdx
index 4fd0efb697aa..67932e66d726 100644
--- a/website/pages/ar/substreams/introduction.mdx
+++ b/website/pages/ar/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## نظره عامة
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Getting Started
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## مصادر إضافية
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 809eb4a218a4d26f796deaf17a6dc77516025b3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:12 -0500
Subject: [PATCH 2956/3820] New translations new-chain-integration.mdx (Czech)

---
 .../cs/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/cs/indexing/new-chain-integration.mdx b/website/pages/cs/indexing/new-chain-integration.mdx
index b5a8b76ebf06..9745156c2c00 100644
--- a/website/pages/cs/indexing/new-chain-integration.mdx
+++ b/website/pages/cs/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Vytvořte jednoduchý příklad podgrafu. Některé možnosti jsou uvedeny níže:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Pokud nedošlo k chybám, měl by uzel Graf synchronizovat nasazený podgraf. Dejte mu čas na synchronizaci a poté odešlete několik dotazů GraphQL na koncový bod API vypsaný v protokolech.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From f8d7e54202002e96f6a5c01f4b79a3cf7b2c8a57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:14 -0500
Subject: [PATCH 2957/3820] New translations introduction.mdx (Czech)

---
 website/pages/cs/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/cs/substreams/introduction.mdx b/website/pages/cs/substreams/introduction.mdx
index 8a6fd77d4e05..eaffe489153b 100644
--- a/website/pages/cs/substreams/introduction.mdx
+++ b/website/pages/cs/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Přehled
 
-## Jak funguje Substreams ve 4 krocích
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Dokumentace Substreams
+## Jak funguje Substreams ve 4 krocích
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Začínáme
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Rozšiřte své znalosti
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Další zdroje
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 4166badef12d6686c2274dd671d626289eaeab95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:15 -0500
Subject: [PATCH 2958/3820] New translations new-chain-integration.mdx (German)

---
 .../de/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/de/indexing/new-chain-integration.mdx b/website/pages/de/indexing/new-chain-integration.mdx
index 695f07957a69..7c9f8a5c65c4 100644
--- a/website/pages/de/indexing/new-chain-integration.mdx
+++ b/website/pages/de/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 23bcd6272d889faad99669a4fb1a6aeb9e67939a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:17 -0500
Subject: [PATCH 2959/3820] New translations introduction.mdx (German)

---
 website/pages/de/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/de/substreams/introduction.mdx b/website/pages/de/substreams/introduction.mdx
index 2b2dcc762cb4..e4fba67fe1b1 100644
--- a/website/pages/de/substreams/introduction.mdx
+++ b/website/pages/de/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Überblick
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Erste Schritte
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Erweitern Sie Ihr Wissen
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Zusätzliche Ressourcen
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 52e3ea535f49ade0332ab36170342b120e8d5ae1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:19 -0500
Subject: [PATCH 2960/3820] New translations new-chain-integration.mdx
 (Italian)

---
 .../it/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/it/indexing/new-chain-integration.mdx b/website/pages/it/indexing/new-chain-integration.mdx
index 695f07957a69..7c9f8a5c65c4 100644
--- a/website/pages/it/indexing/new-chain-integration.mdx
+++ b/website/pages/it/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 046b7d2b8db53667b514cbf3968dddefaafc5774 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:21 -0500
Subject: [PATCH 2961/3820] New translations introduction.mdx (Italian)

---
 website/pages/it/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/it/substreams/introduction.mdx b/website/pages/it/substreams/introduction.mdx
index 52e584dc7947..5340ce571a9c 100644
--- a/website/pages/it/substreams/introduction.mdx
+++ b/website/pages/it/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Panoramica
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Per cominciare
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Additional Resources
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 2dc15a9f200407e136ed0ce7d01ea0a252b5b390 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:22 -0500
Subject: [PATCH 2962/3820] New translations new-chain-integration.mdx
 (Japanese)

---
 .../ja/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/ja/indexing/new-chain-integration.mdx b/website/pages/ja/indexing/new-chain-integration.mdx
index d53ed7dd1147..d71692271261 100644
--- a/website/pages/ja/indexing/new-chain-integration.mdx
+++ b/website/pages/ja/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. 簡単なサブグラフの例を作成します。 いくつかのオプションを以下に示します。
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Nodeはエラーがない場合、デプロイされたサブグラフを同期するはずです。同期が完了するのを待ってから、ログに表示されたAPIエンドポイントに対していくつかのGraphQLクエリを送信してください。
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From f4b1fb1661e85b8860b54a0055d7d485dffde860 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:24 -0500
Subject: [PATCH 2963/3820] New translations introduction.mdx (Japanese)

---
 website/pages/ja/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/ja/substreams/introduction.mdx b/website/pages/ja/substreams/introduction.mdx
index f614c157879d..d5db32bdae51 100644
--- a/website/pages/ja/substreams/introduction.mdx
+++ b/website/pages/ja/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## 概要
 
-## サブストリームの4つのステップ
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams ドキュメンテーション
+## サブストリームの4つのステップ
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### はじめに
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### 知識を広げよう
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## その他のリソース
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 4be9abfcf03235e5145844fc3eed39283f0276ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:27 -0500
Subject: [PATCH 2964/3820] New translations new-chain-integration.mdx (Korean)

---
 .../ko/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/ko/indexing/new-chain-integration.mdx b/website/pages/ko/indexing/new-chain-integration.mdx
index 695f07957a69..7c9f8a5c65c4 100644
--- a/website/pages/ko/indexing/new-chain-integration.mdx
+++ b/website/pages/ko/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 1ded9b7cd538cb335b8002a62d36bf61bc167801 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:29 -0500
Subject: [PATCH 2965/3820] New translations introduction.mdx (Korean)

---
 website/pages/ko/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/ko/substreams/introduction.mdx b/website/pages/ko/substreams/introduction.mdx
index 4fd0efb697aa..25fcfa5a5c2c 100644
--- a/website/pages/ko/substreams/introduction.mdx
+++ b/website/pages/ko/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Overview
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Getting Started
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Additional Resources
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 5641a8f2edebafadbe8b1873fe011d3d6fb2c4d6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:31 -0500
Subject: [PATCH 2966/3820] New translations new-chain-integration.mdx (Dutch)

---
 .../nl/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/nl/indexing/new-chain-integration.mdx b/website/pages/nl/indexing/new-chain-integration.mdx
index 695f07957a69..7c9f8a5c65c4 100644
--- a/website/pages/nl/indexing/new-chain-integration.mdx
+++ b/website/pages/nl/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 135dffacec798898dd10a3d5d806fb264dd7b4a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:33 -0500
Subject: [PATCH 2967/3820] New translations introduction.mdx (Dutch)

---
 website/pages/nl/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/nl/substreams/introduction.mdx b/website/pages/nl/substreams/introduction.mdx
index 4fd0efb697aa..25fcfa5a5c2c 100644
--- a/website/pages/nl/substreams/introduction.mdx
+++ b/website/pages/nl/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Overview
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Getting Started
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Additional Resources
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 1987fa61b9696cdb4f403cf4a40c2411290f7802 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:34 -0500
Subject: [PATCH 2968/3820] New translations new-chain-integration.mdx (Polish)

---
 .../pl/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/pl/indexing/new-chain-integration.mdx b/website/pages/pl/indexing/new-chain-integration.mdx
index 695f07957a69..7c9f8a5c65c4 100644
--- a/website/pages/pl/indexing/new-chain-integration.mdx
+++ b/website/pages/pl/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 36353a1b75513dccc894451bf5ba454eca51523d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:37 -0500
Subject: [PATCH 2969/3820] New translations introduction.mdx (Polish)

---
 website/pages/pl/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/pl/substreams/introduction.mdx b/website/pages/pl/substreams/introduction.mdx
index 4fd0efb697aa..25fcfa5a5c2c 100644
--- a/website/pages/pl/substreams/introduction.mdx
+++ b/website/pages/pl/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Overview
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Getting Started
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Additional Resources
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 834ad683db6add3f5f8f361caf3f1783eab6d88b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:39 -0500
Subject: [PATCH 2970/3820] New translations introduction.mdx (Russian)

---
 website/pages/ru/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/ru/substreams/introduction.mdx b/website/pages/ru/substreams/introduction.mdx
index d865b64fe1b1..c19c366b6968 100644
--- a/website/pages/ru/substreams/introduction.mdx
+++ b/website/pages/ru/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Обзор
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Начало работы
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Расширьте свои знания
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Дополнительные ресурсы
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 17fcd36b2a9c49fa98da69d064af1d37863c6b34 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:40 -0500
Subject: [PATCH 2971/3820] New translations new-chain-integration.mdx
 (Swedish)

---
 .../sv/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/sv/indexing/new-chain-integration.mdx b/website/pages/sv/indexing/new-chain-integration.mdx
index 9e35237d4922..5f1a82a49794 100644
--- a/website/pages/sv/indexing/new-chain-integration.mdx
+++ b/website/pages/sv/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, i en JSON-RPC batch-begäran
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Klona Graf Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Skapa en enkel exempelsubgraf. Några alternativ är nedan:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graf Node bör synkronisera den distribuerade subgrafen om det inte finns några fel. Ge det tid att synkronisera, och skicka sedan några GraphQL-begäranden till API-slutpunkten som skrivs ut i loggarna.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 06893794835716202097d8aa5bd2011fa8498cb9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:42 -0500
Subject: [PATCH 2972/3820] New translations introduction.mdx (Swedish)

---
 website/pages/sv/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/sv/substreams/introduction.mdx b/website/pages/sv/substreams/introduction.mdx
index 21bf04c38eb0..61fd25dca16b 100644
--- a/website/pages/sv/substreams/introduction.mdx
+++ b/website/pages/sv/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Översikt
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Komma igång
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Ytterligare resurser
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 0c5e98721389298a55e6fa05dd1ab8aa968e0ac1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:44 -0500
Subject: [PATCH 2973/3820] New translations new-chain-integration.mdx
 (Turkish)

---
 .../tr/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/tr/indexing/new-chain-integration.mdx b/website/pages/tr/indexing/new-chain-integration.mdx
index 1fff8115bab0..e5a2124dc950 100644
--- a/website/pages/tr/indexing/new-chain-integration.mdx
+++ b/website/pages/tr/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, bir JSON-RPC toplu talebinde
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Graph Düğümü'nü Klonlayın](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Basit bir örnek subgraph oluşturun. Bazı seçenekler aşağıdadır:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Herhangi bir hata olmadığı takdirde Graph Düğü'mü dağıtılan subgraph'ı senkronize ediyor olmalıdır. Senkronizasyon için zaman tanıyın, ardından kayıtlarla yazdırılan API uç noktasına bazı GraphQL sorguları gönderin.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From a029387447384434945443880b2c5d6bec7374dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:45 -0500
Subject: [PATCH 2974/3820] New translations introduction.mdx (Turkish)

---
 website/pages/tr/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/tr/substreams/introduction.mdx b/website/pages/tr/substreams/introduction.mdx
index b9a4ce5b3203..17a39ca7ed7f 100644
--- a/website/pages/tr/substreams/introduction.mdx
+++ b/website/pages/tr/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Genel Bakış
 
-## Substreams Nasıl Çalışır - 4 Adımda
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Dökümantasyonu
+## Substreams Nasıl Çalışır - 4 Adımda
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Buradan Başlayın
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Bilgi Dağarcığınızı Genişletin
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Ek Kaynaklar
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 9a5536684d877f8ed0bcc2499c6689a721fe0b04 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:46 -0500
Subject: [PATCH 2975/3820] New translations new-chain-integration.mdx
 (Ukrainian)

---
 .../uk/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/uk/indexing/new-chain-integration.mdx b/website/pages/uk/indexing/new-chain-integration.mdx
index 695f07957a69..7c9f8a5c65c4 100644
--- a/website/pages/uk/indexing/new-chain-integration.mdx
+++ b/website/pages/uk/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 94c1135e361928f67c887cafb593a7de4456e2da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:48 -0500
Subject: [PATCH 2976/3820] New translations introduction.mdx (Ukrainian)

---
 website/pages/uk/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/uk/substreams/introduction.mdx b/website/pages/uk/substreams/introduction.mdx
index 4fd0efb697aa..f5985fb8bd6d 100644
--- a/website/pages/uk/substreams/introduction.mdx
+++ b/website/pages/uk/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Overview
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Getting Started
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Додаткові матеріали
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 88c6e276b5d27ccd5ef842b6e5ad61593a39e8c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:50 -0500
Subject: [PATCH 2977/3820] New translations introduction.mdx (Romanian)

---
 website/pages/ro/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/ro/sps/introduction.mdx b/website/pages/ro/sps/introduction.mdx
index 12e3f81c6d53..aa44f605ce65 100644
--- a/website/pages/ro/sps/introduction.mdx
+++ b/website/pages/ro/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Overview
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Additional Resources
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From 072ac20ad3d0ddcf0505adaa50a31849e2269bf6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:51 -0500
Subject: [PATCH 2978/3820] New translations sps-faq.mdx (Romanian)

---
 website/pages/ro/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/ro/sps/sps-faq.mdx

diff --git a/website/pages/ro/sps/sps-faq.mdx b/website/pages/ro/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dc99e916ed7a
--- /dev/null
+++ b/website/pages/ro/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 417ef493c632daf2112e2028392f319fbe4bb48b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:52 -0500
Subject: [PATCH 2979/3820] New translations triggers.mdx (Romanian)

---
 website/pages/ro/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/ro/sps/triggers.mdx b/website/pages/ro/sps/triggers.mdx
index ed19635d4768..b346119555c1 100644
--- a/website/pages/ro/sps/triggers.mdx
+++ b/website/pages/ro/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Overview
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Additional Resources
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 1c1f37c75c9eb2554e0050a4eaef86ab99c13664 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:53 -0500
Subject: [PATCH 2980/3820] New translations devcontainer.mdx (Romanian)

---
 .../ro/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/ro/substreams/developing/devcontainer.mdx

diff --git a/website/pages/ro/substreams/developing/devcontainer.mdx b/website/pages/ro/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..cd65c8d046f8
--- /dev/null
+++ b/website/pages/ro/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Prerequisites
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 3d81212474c543b2908f0e1638a5352dc7ff126f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:54 -0500
Subject: [PATCH 2981/3820] New translations sinks.mdx (Romanian)

---
 .../ro/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/ro/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/ro/substreams/developing/sinks/sinks.mdx b/website/pages/ro/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..3f761c18f0a8
--- /dev/null
+++ b/website/pages/ro/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Overview
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From c84834a63235be3a4330f2eccb923f1246bd9b1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:55 -0500
Subject: [PATCH 2982/3820] New translations accountchanges.mdx (Romanian)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/ro/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/ro/substreams/developing/solana/accountchanges.mdx b/website/pages/ro/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..53ab95612a29
--- /dev/null
+++ b/website/pages/ro/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introduction
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Getting Started
+
+### Prerequisites
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 8f8d18dbd2cc65a4e237d73bd5ce6b6957217f5f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:56 -0500
Subject: [PATCH 2983/3820] New translations transactions.mdx (Romanian)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/ro/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/ro/substreams/developing/solana/transactions.mdx b/website/pages/ro/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..8e5d7c35d4e7
--- /dev/null
+++ b/website/pages/ro/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Additional Resources
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 0bccc0dd818d742f7ff9bc7a0c5d4831fce87497 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:57 -0500
Subject: [PATCH 2984/3820] New translations getting-started-substreams.mdx
 (Romanian)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/ro/substreams/getting-started-substreams.mdx

diff --git a/website/pages/ro/substreams/getting-started-substreams.mdx b/website/pages/ro/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..5541cc56d347
--- /dev/null
+++ b/website/pages/ro/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Overview
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Additional Resources
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 56c6b5de66b7d52786365d3c9120fa2fae6c0807 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:58 -0500
Subject: [PATCH 2985/3820] New translations pubsubstreams.mdx (Romanian)

---
 website/pages/ro/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ro/substreams/pubsubstreams.mdx

diff --git a/website/pages/ro/substreams/pubsubstreams.mdx b/website/pages/ro/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..3c02d60f9ffd
--- /dev/null
+++ b/website/pages/ro/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Overview
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Prerequisites
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Additional Resources
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From c9a7b84b39e300861ef1c4a642ab3618384dd7a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:24:59 -0500
Subject: [PATCH 2986/3820] New translations tutorial.mdx (Romanian)

---
 website/pages/ro/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/ro/sps/tutorial.mdx

diff --git a/website/pages/ro/sps/tutorial.mdx b/website/pages/ro/sps/tutorial.mdx
new file mode 100644
index 000000000000..b17e5d9ff491
--- /dev/null
+++ b/website/pages/ro/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Get Started
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Additional Resources
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 3d6a057eadc311607e5196c21b6ba7c52dfd478f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:00 -0500
Subject: [PATCH 2987/3820] New translations introduction.mdx (French)

---
 website/pages/fr/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/fr/sps/introduction.mdx b/website/pages/fr/sps/introduction.mdx
index 12e3f81c6d53..b6a92d7ba866 100644
--- a/website/pages/fr/sps/introduction.mdx
+++ b/website/pages/fr/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Aperçu
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Spécificités⁠
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Ressources supplémentaires
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From d56738a373d8bd04c3b4a994b7448505f0c8db1e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:01 -0500
Subject: [PATCH 2988/3820] New translations sps-faq.mdx (French)

---
 website/pages/fr/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/fr/sps/sps-faq.mdx

diff --git a/website/pages/fr/sps/sps-faq.mdx b/website/pages/fr/sps/sps-faq.mdx
new file mode 100644
index 000000000000..2452ac57e7cc
--- /dev/null
+++ b/website/pages/fr/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## Que sont les sous-flux ?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## Qu'est-ce qu'un subgraph alimenté par des courants de fond ?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## En quoi les subgraphs alimentés par les courants secondaires sont-ils différents des subgraphs ?
+
+Les subgraphs sont constitués de sources de données qui spécifient des événements onchain et comment ces événements doivent être transformés via des gestionnaires écrits en Assemblyscript. Ces événements sont traités de manière séquentielle, en fonction de l'ordre dans lequel ils se produisent onchain.
+
+En revanche, les subgraphs alimentés par des substreams ont une seule source de données qui référence un package de substreams, qui est traité par Graph Node. Les substreams ont accès à des données onchain supplémentaires granulaires par rapport aux subgraphs conventionnels et peuvent également bénéficier d'un traitement massivement parallélisé, ce qui peut signifier des temps de traitement beaucoup plus rapides.
+
+## Quels sont les avantages de l'utilisation de subgraphs alimentés par des courants descendants ?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## Quels sont les avantages de Substreams ?
+
+L'utilisation de Substreams présente de nombreux avantages, notamment:
+
+- Composable : Vous pouvez empiler les modules Substreams comme des blocs LEGO et construire des modules communautaires pour affiner les données publiques.
+
+- Indexation haute performance : Indexation plus rapide d'un ordre de grandeur grâce à des grappes d'opérations parallèles à grande échelle (comme BigQuery).
+
+- Sortez vos données n'importe où : Transférez vos données où vous le souhaitez : PostgreSQL, MongoDB, Kafka, subgraphs, fichiers plats, Google Sheets.
+
+- Programmable : Utilisez du code pour personnaliser l'extraction, effectuer des agrégations au moment de la transformation et modéliser vos résultats pour plusieurs puits.
+
+- Accès à des données supplémentaires qui ne sont pas disponibles dans le cadre de la RPC JSON
+
+- Tous les avantages du Firehose.
+
+## Tous les avantages du Firehose?
+
+Développé par [StreamingFast] (https://www.streamingfast.io/), le Firehose est une couche d'extraction de données de blockchain conçue à partir de zéro pour traiter l'historique complet des blockchains à des vitesses jusqu'alors inconnues . Obtenez une approche basée sur les fichiers et le streaming, il s'agit d'un composant essentiel de la suite de technologies open-source de StreamingFast et de la base de Substreams.
+
+Consultez la [documentation] (https://firehose.streamingfast.io/) pour en savoir plus sur le Firehose.
+
+## Quels sont les avantages du Firehose ?
+
+L'utilisation de Firehose présente de nombreux avantages, notamment:
+
+- Temps de latence le plus faible et pas d'interrogation : Les nœuds Firehose sont conçus pour faire la course afin de diffuser les données en bloc en premier, selon le principe "streaming-first".
+
+- Prévient les temps d'arrêt : Conçu dès le départ pour une haute disponibilité.
+
+- Ne manquez jamais le rythme : Le curseur du flux Firehose est conçu pour gérer les bifurcations et pour reprendre là où vous vous êtes arrêté dans n'importe quelle condition.
+
+- Modèle de données le plus riche :   Meilleur modèle de données qui inclut les changements de solde, l'arbre d'appel complet, les transactions internes, les journaux, les changements de stockage, les coûts du gaz, etc.
+
+- Exploite les fichiers plats : Les données de la blockchain sont extraites dans des fichiers plats, la ressource informatique la moins chère et la plus optimisée disponible.
+
+## Où les développeurs peuvent-ils trouver plus d'informations sur les subgraphs alimentés par Substreams et sur Substreams ?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+Le [dernier outil Substreams Codegen ](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) vous permettra de lancer un projet Substreams sans aucun code.
+
+## Quel est le rôle des modules Rust dans Substreams ?
+
+Les modules Rust sont l'équivalent des mappeurs AssemblyScript dans les subgraphs. Ils sont compilés dans WASM de la même manière, mais le modèle de programmation permet une exécution parallèle. Ils définissent le type de transformations et d'agrégations que vous souhaitez appliquer aux données brutes de la blockchain.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## Qu'est-ce qui rend Substreams composable ?
+
+Lors de l'utilisation de Substreams, la composition a lieu au niveau de la couche de transformation, ce qui permet de réutiliser les modules mis en cache.
+
+Par exemple, Alice peut créer un module de prix DEX, Bob peut l'utiliser pour créer un agrégateur de volume pour certains jetons qui l'intéressent, et Lisa peut combiner quatre modules de prix DEX individuels pour créer un oracle de prix. Une seule requête Substreams regroupera tous ces modules individuels, les reliera entre eux, pour offrir un flux de données beaucoup plus raffiné. Ce flux peut ensuite être utilisé pour alimenter un subgraph et être interrogé par les consommateurs.
+
+## Comment pouvez-vous créer et déployer un Subgraph basé sur Substreams ?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Où puis-je trouver des exemples de subgraphs et de subgraphs alimentés par des substreams ?
+
+Vous pouvez visiter [ce repo Github] (https://github.com/pinax-network/awesome-substreams) pour trouver des exemples de Substreams et de subgraphs alimentés par Substreams.
+
+## Que signifient les subgraphs et les subgraphs alimentés par des substreams pour le réseau graph ?
+
+L'intégration promet de nombreux avantages, notamment une indexation extrêmement performante et une plus grande composabilité grâce à l'exploitation des modules de la communauté et à leur développement.

From d9d441ba75a72ec2059f0ae9701985f3602297e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:02 -0500
Subject: [PATCH 2989/3820] New translations triggers.mdx (French)

---
 website/pages/fr/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/fr/sps/triggers.mdx b/website/pages/fr/sps/triggers.mdx
index ed19635d4768..45ecc6030d82 100644
--- a/website/pages/fr/sps/triggers.mdx
+++ b/website/pages/fr/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Aperçu
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Ressources supplémentaires
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 6fbb87905065dbe3b058e7a66b3c1f12e09e9757 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:03 -0500
Subject: [PATCH 2990/3820] New translations devcontainer.mdx (French)

---
 .../fr/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/fr/substreams/developing/devcontainer.mdx

diff --git a/website/pages/fr/substreams/developing/devcontainer.mdx b/website/pages/fr/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..0d97d3749b25
--- /dev/null
+++ b/website/pages/fr/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Conditions préalables
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From b8d44f226472ecf1ac0b434df5dc60936072c849 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:04 -0500
Subject: [PATCH 2991/3820] New translations sinks.mdx (French)

---
 .../fr/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/fr/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/fr/substreams/developing/sinks/sinks.mdx b/website/pages/fr/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..75a9652b1a89
--- /dev/null
+++ b/website/pages/fr/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Aperçu
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 64259dc8fb70c69584a46491363730408cfc7f6a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:05 -0500
Subject: [PATCH 2992/3820] New translations accountchanges.mdx (French)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/fr/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/fr/substreams/developing/solana/accountchanges.mdx b/website/pages/fr/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..33d8a7a170b1
--- /dev/null
+++ b/website/pages/fr/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Présentation
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Introduction
+
+### Conditions préalables
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 98836ec1418ba090cb3c6e7c127610396d53473b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:06 -0500
Subject: [PATCH 2993/3820] New translations transactions.mdx (French)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/fr/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/fr/substreams/developing/solana/transactions.mdx b/website/pages/fr/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..f59b30586a24
--- /dev/null
+++ b/website/pages/fr/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraphe
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Ressources supplémentaires
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From bb401db7ffef28d9eda6002a205773fe236c6f5b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:07 -0500
Subject: [PATCH 2994/3820] New translations getting-started-substreams.mdx
 (French)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/fr/substreams/getting-started-substreams.mdx

diff --git a/website/pages/fr/substreams/getting-started-substreams.mdx b/website/pages/fr/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..2b2b1f1e0b5f
--- /dev/null
+++ b/website/pages/fr/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Aperçu
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Commencez à développer
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Ressources supplémentaires
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 22dc11ee556817ba90da3802093740a8073ccd94 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:08 -0500
Subject: [PATCH 2995/3820] New translations pubsubstreams.mdx (French)

---
 website/pages/fr/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/fr/substreams/pubsubstreams.mdx

diff --git a/website/pages/fr/substreams/pubsubstreams.mdx b/website/pages/fr/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..c925c39cedb1
--- /dev/null
+++ b/website/pages/fr/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Aperçu
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Conditions préalables
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Ressources supplémentaires
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 940b9d62ba16d41d91daa81024ec12c3481d00bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:09 -0500
Subject: [PATCH 2996/3820] New translations tutorial.mdx (French)

---
 website/pages/fr/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/fr/sps/tutorial.mdx

diff --git a/website/pages/fr/sps/tutorial.mdx b/website/pages/fr/sps/tutorial.mdx
new file mode 100644
index 000000000000..31ae39376a85
--- /dev/null
+++ b/website/pages/fr/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Commencer
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Conditions préalables
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Ressources supplémentaires
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From da6c5f69660f3720b27b30a8244b9bc17ca3adb0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:10 -0500
Subject: [PATCH 2997/3820] New translations introduction.mdx (Chinese
 Simplified)

---
 website/pages/zh/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/zh/substreams/introduction.mdx b/website/pages/zh/substreams/introduction.mdx
index 204b62272f81..c8b0d42fd85c 100644
--- a/website/pages/zh/substreams/introduction.mdx
+++ b/website/pages/zh/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## 概述
 
-## 子流的工作原理分为四个步骤
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## 子流文档
+## 子流的工作原理分为四个步骤
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### 开始
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### 知识拓展
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## 其他资源
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 07ac1b7922cd15d7aa4441351c17b33b0194c000 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:14 -0500
Subject: [PATCH 2998/3820] New translations new-chain-integration.mdx (Urdu
 (Pakistan))

---
 .../ur/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/ur/indexing/new-chain-integration.mdx b/website/pages/ur/indexing/new-chain-integration.mdx
index f92f8ce2a25f..c8b7aa53ea5d 100644
--- a/website/pages/ur/indexing/new-chain-integration.mdx
+++ b/website/pages/ur/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [گراف نوڈ کی نقل بنائیں](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. ایک سادہ مثالی سب گراف بنائیں۔ کچھ آپشنز ذیل میں ہیں:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-اگر کوئی خرابی نہیں ہے تو گراف نوڈ کو تعینات سب گراف کو ہم آہنگ کرنا چاہیے۔ اسے مطابقت پذیری کے لیے وقت دیں، پھر لاگز میں پرنٹ کردہ API اینڈ پوائنٹ پر کچھ GraphQL کیوریز بھیجیں۔
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 97f6e9d0c5a6930cf80b658994debdb8bd6d1710 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:16 -0500
Subject: [PATCH 2999/3820] New translations introduction.mdx (Urdu (Pakistan))

---
 website/pages/ur/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/ur/substreams/introduction.mdx b/website/pages/ur/substreams/introduction.mdx
index 1995c2feae36..ad59d9b1145e 100644
--- a/website/pages/ur/substreams/introduction.mdx
+++ b/website/pages/ur/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## جائزہ
 
-## سب سٹریمز 4 مراحل میں کیسے کام کرتا ہے۔
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## سب سٹریمز دستاویزات
+## سب سٹریمز 4 مراحل میں کیسے کام کرتا ہے۔
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### شروع ہوا چاہتا ہے
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### اپنے علم کو وسعت دیں
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## اضافی وسائل
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From fc6112508cec45058b4f106cfd2a56a2ebed84b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:18 -0500
Subject: [PATCH 3000/3820] New translations new-chain-integration.mdx
 (Vietnamese)

---
 .../vi/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/vi/indexing/new-chain-integration.mdx b/website/pages/vi/indexing/new-chain-integration.mdx
index 695f07957a69..7c9f8a5c65c4 100644
--- a/website/pages/vi/indexing/new-chain-integration.mdx
+++ b/website/pages/vi/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 461cfd4b3dabfab0bc9399a0cf62098500bf081a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:20 -0500
Subject: [PATCH 3001/3820] New translations introduction.mdx (Vietnamese)

---
 website/pages/vi/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/vi/substreams/introduction.mdx b/website/pages/vi/substreams/introduction.mdx
index 4fd0efb697aa..24da40248562 100644
--- a/website/pages/vi/substreams/introduction.mdx
+++ b/website/pages/vi/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Tổng quan
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Getting Started
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Additional Resources
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From fb685dcc7f2c728f8726d95b81e1595756f4c317 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:21 -0500
Subject: [PATCH 3002/3820] New translations new-chain-integration.mdx
 (Marathi)

---
 .../mr/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/mr/indexing/new-chain-integration.mdx b/website/pages/mr/indexing/new-chain-integration.mdx
index 695f07957a69..7c9f8a5c65c4 100644
--- a/website/pages/mr/indexing/new-chain-integration.mdx
+++ b/website/pages/mr/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From eebaa7215d026514835923a20dd00aebc9636bac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:23 -0500
Subject: [PATCH 3003/3820] New translations introduction.mdx (Marathi)

---
 website/pages/mr/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/mr/substreams/introduction.mdx b/website/pages/mr/substreams/introduction.mdx
index 8ea62ed22e98..23f4ecf0937a 100644
--- a/website/pages/mr/substreams/introduction.mdx
+++ b/website/pages/mr/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## सविश्लेषण
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### प्रारंभ करणे
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## अतिरिक्त संसाधने
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 086c02ae734bc0badff36bb0cdd490b468c1537e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:24 -0500
Subject: [PATCH 3004/3820] New translations new-chain-integration.mdx (Hindi)

---
 .../hi/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/hi/indexing/new-chain-integration.mdx b/website/pages/hi/indexing/new-chain-integration.mdx
index 411961c10f5d..328bd44037b8 100644
--- a/website/pages/hi/indexing/new-chain-integration.mdx
+++ b/website/pages/hi/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ Graph Node को EVM चेन से डेटा इन्गेस्ट क
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- trace_filter (वैकल्पिक रूप से Graph Node को कॉल हैंडलर्स का समर्थन करने के लिए आवश्यक)
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose एकीकरण
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) एक अगली पीढ़ी की निष्कर्षण परत है। यह फ्लैट फ़ाइलों में इतिहास एकत्र करता है और वास्तविक समय में स्ट्रीम करता है। Firehose तकनीक उन पॉलिंग API कॉल्स को एक डेटा स्ट्रीम से बदल देती है, जो एक पुश मॉडल का उपयोग करती है, जिससे डेटा को इंडेक्सिंग नोड तक तेजी से भेजा जा सके। यह सिंकिंग और इंडेक्सिंग की गति बढ़ाने में मदद करता है।
 
-फायरहोज़ को चेन में एकीकृत करने का प्राथमिक तरीका RPC पॉलिंग रणनीति का उपयोग करना है। हमारी पॉलिंग एल्गोरिदम नए ब्लॉक के आने का पूर्वानुमान लगाएगी और उस समय के करीब नए ब्लॉक के लिए जाँच करने की दर बढ़ा देगी, जिससे यह एक बहुत कम लेटेंसी और प्रभावी समाधान बन जाता है। फायरहोज़ के एकीकरण और रखरखाव में मदद के लिए, [स्ट्रीमिंगफास्ट टीम](https://www.streamingfast.io/firehose-integration-program) से संपर्क करें। नए चेन और उनके एकीकृतकर्ताओं को फायरहोज़ और सबस्ट्रीम द्वारा उनके पारिस्थितिकी तंत्र में लाए गए [फोर्क जागरूकता](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) और विशाल समानांतर इंडेक्सिंग क्षमताओं की सराहना होगी।
-
 > नोट: StreamingFast टीम द्वारा की गई सभी एकीकरणों में श्रृंखला के कोडबेस में Firehose प्रतिकृति प्रोटोकॉल के लिए रखरखाव शामिल है।StreamingFast किसी भी परिवर्तन को ट्रैक करता है और जब आप कोड बदलते हैं और जब StreamingFastकोड बदलता है, तो बाइनरी जारी करता है। इसमें प्रोटोकॉल के लिए Firehose/Substreamsबाइनरी जारी करना, श्रृंखला के ब्लॉक मॉडल के लिए Substreamsमॉड्यूल को बनाए रखना, और आवश्यकता होने पर ब्लॉकचेन नोड के लिए इंस्ट्रुमेंटेशन के साथ बाइनरी जारी करना शामिल है।
 
-#### ईवीएम (`geth`) चेन के लिए विशिष्ट फायरहोज़ इंस्ट्रूमेंटेशन
+#### Integration for Non-EVM chains
+
+फायरहोज़ को चेन में एकीकृत करने का प्राथमिक तरीका RPC पॉलिंग रणनीति का उपयोग करना है। हमारी पॉलिंग एल्गोरिदम नए ब्लॉक के आने का पूर्वानुमान लगाएगी और उस समय के करीब नए ब्लॉक के लिए जाँच करने की दर बढ़ा देगी, जिससे यह एक बहुत कम लेटेंसी और प्रभावी समाधान बन जाता है। फायरहोज़ के एकीकरण और रखरखाव में मदद के लिए, [स्ट्रीमिंगफास्ट टीम](https://www.streamingfast.io/firehose-integration-program) से संपर्क करें। नए चेन और उनके एकीकृतकर्ताओं को फायरहोज़ और सबस्ट्रीम द्वारा उनके पारिस्थितिकी तंत्र में लाए गए [फोर्क जागरूकता](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) और विशाल समानांतर इंडेक्सिंग क्षमताओं की सराहना होगी।
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 EVM चेन के लिए, एक गहरे स्तर के डेटा को प्राप्त करने के लिए `geth` [लाइव-ट्रेसर](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0) का उपयोग किया जाता है, जो गो-एथेरियम और स्ट्रीमिंगफास्ट के बीच सहयोग है, जो उच्च थ्रूपुट और समृद्ध लेनदेन ट्रेसिंग प्रणाली बनाने के लिए है। लाइव ट्रेसर सबसे व्यापक समाधान है, जो [विस्तारित](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) ब्लॉक विवरण का परिणाम है। यह नए इंडेक्सिंग पैरेडाइम्स की अनुमति देता है, जैसे राज्य परिवर्तनों, कॉल्स, पैरेंट कॉल ट्रीज़ के आधार पर घटनाओं का पैटर्न मिलाना, या स्मार्ट कॉन्ट्रैक्ट में वास्तविक वेरिएबल्स में बदलाव के आधार पर घटनाओं को ट्रिगर करना।
 
@@ -57,24 +59,12 @@ While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is a
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. नए network नाम और EVM JSON RPC अनुरूप URL को शामिल करने के लिए [this line] (https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) को संशोधित करें
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > कृपया पर्यावरण चर ethereum को खुद नाम में बदलें नहीं। यही रहना चाहिए, चाहे network का नाम भिन्न हो।
 
 3. एक IPFS node चलाएं या उसे The Graph द्वारा उपयोग किया जाने वाले node का उपयोग करें: https://api.thegraph.com/ipfs/
 
-### EVM JSON-RPC का परीक्षण करने के लिए स्थानीय रूप से एक Subgraph तैनात करना
-
-1. [graph-cli] स्थापित करें(https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. Pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract और subgraph एक अच्छा शुरुआती बिंदु है
-   2. किसी भी मौजूदा smart contract या solidity dev वातावरण से एक local subgraph को Bootstrap करें [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. परिणामी `subgraph.yaml` को [`dataSources.network`](http://dataSources.network) को उसी नाम में बदलकर अनुकूलित करें जो पहले Graph Node पर दिया गया था।
-4. अपने subgraph को Graph Node में बनाएँ: graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT
-5. अपने 'subgraph' को Graph Node पर प्रकाशित करें: graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT
-
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
-
 ## सबस्ट्रीम-संचालित सबग्राफ की सेवा
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 487c15e124e8e37123a3a6e18da15985bdb13f3d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:26 -0500
Subject: [PATCH 3005/3820] New translations introduction.mdx (Hindi)

---
 website/pages/hi/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/hi/substreams/introduction.mdx b/website/pages/hi/substreams/introduction.mdx
index 1931389e00f5..172f43ebfed2 100644
--- a/website/pages/hi/substreams/introduction.mdx
+++ b/website/pages/hi/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams एक शक्तिशाली ब्लॉकचेन indexing तकनीक है जो The Graph Network में प्रदर्शन और स्केलेबिलिटी को बढ़ाने के लिए डिज़ाइन की गई है। यह निम्नलिखित सुविधाएँ प्रदान करती है:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## अवलोकन
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### शुरू करना
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams रजिस्ट्र्री
+## Additional Resources
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From 374139de17e5ac220398ea865192b604119604f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:28 -0500
Subject: [PATCH 3006/3820] New translations new-chain-integration.mdx
 (Swahili)

---
 .../sw/indexing/new-chain-integration.mdx     | 24 ++++++-------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/website/pages/sw/indexing/new-chain-integration.mdx b/website/pages/sw/indexing/new-chain-integration.mdx
index 695f07957a69..7c9f8a5c65c4 100644
--- a/website/pages/sw/indexing/new-chain-integration.mdx
+++ b/website/pages/sw/indexing/new-chain-integration.mdx
@@ -25,17 +25,19 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(optionally required for Graph Node to support call handlers)_
+- `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
 [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
-
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Specific Firehose Instrumentation for EVM (`geth`) chains
+#### Integration for Non-EVM chains
+
+The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+
+#### Specific Instrumentation for EVM (`geth`) chains
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -57,24 +59,12 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC compliant URL
+2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 
 3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
 
-### Testing an EVM JSON-RPC by locally deploying a subgraph
-
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
-   1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
-   2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing `dataSources.network` to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
-
-Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
-
 ## Substreams-powered Subgraphs
 
 For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.

From 402dc283d5e88f31b96e4da6f044aced4af5c7e5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:30 -0500
Subject: [PATCH 3007/3820] New translations introduction.mdx (Swahili)

---
 website/pages/sw/substreams/introduction.mdx | 58 +++++++++-----------
 1 file changed, 25 insertions(+), 33 deletions(-)

diff --git a/website/pages/sw/substreams/introduction.mdx b/website/pages/sw/substreams/introduction.mdx
index 4fd0efb697aa..25fcfa5a5c2c 100644
--- a/website/pages/sw/substreams/introduction.mdx
+++ b/website/pages/sw/substreams/introduction.mdx
@@ -4,49 +4,41 @@ title: Introduction to Substreams
 
 ![Substreams Logo](/img/substreams-logo.png)
 
-Substreams is a powerful blockchain indexing technology designed to enhance performance and scalability within The Graph Network. It offers the following features:
+To start coding right away, check out the [Substreams Quick Start](/substreams/getting-started-substreams/).
 
-- **Accelerated Indexing**: Substreams reduce subgraph indexing time thanks to a parallelized engine, enabling faster data retrieval and processing.
-- **Multi-Chain Support**: Substreams expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
-- **Multi-Sink Support:** Subgraph, Postgres database, Clickhouse, Mongo database
+## Overview
 
-## How Substreams Works in 4 Steps
-
-1. **You write a Rust program, which defines the transformations that you want to apply to the blockchain data.** For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
-
-   ```rust
-   fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
-       let header = blk.header.as_ref().unwrap();
+Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-       Ok(MyBlock {
-           number: blk.number,
-           hash: Hex::encode(&blk.hash),
-           parent_hash: Hex::encode(&header.parent_hash),
-       })
-   }
-   ```
+## Substreams Capabilities
 
-2. **You wrap up your Rust program into a WASM module just by running a single CLI command.**
+- **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
+- **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
+- **Enhanced Data Model**: Access comprehensive data, including the `trace` level data on EVM or account changes on Solana, while efficiently managing forks/disconnections.
+- **Multi-Sink Support:** For Subgraph, Postgres database, Clickhouse, and Mongo database.
 
-3. **The WASM container is sent to a Substreams endpoint for execution.** The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
-
-4. **You select a [sink](https://substreams.streamingfast.io/documentation/consume/other-sinks), a place where you want to send the transformed data** (a Postgres database or a Subgraph, for example).
-
-## Substreams Documentation
+## How Substreams Works in 4 Steps
 
-The official Substreams documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://substreams.streamingfast.io/).
+1. You write a Rust program, which defines the transformations that you want to apply to the blockchain data. For example, the following Rust function extracts relevant information from an Ethereum block (number, hash, and parent hash).
 
-To learn about the latest version of Substreams CLI, which enables developers to bootstrap a Substreams project without any code, please check [Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6).
+```rust
+fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
+    let header = blk.header.as_ref().unwrap();
 
-### Getting Started
+    Ok(MyBlock {
+        number: blk.number,
+        hash: Hex::encode(&blk.hash),
+        parent_hash: Hex::encode(&header.parent_hash),
+    })
+}
+```
 
-- In order to develop and deploy a Substreams, [you must install the Substreams CLI](https://substreams.streamingfast.io/documentation/consume/installing-the-cli).
-- Then, run your first Substreams by following the [Quickstart Tutorial](https://substreams.streamingfast.io/documentation/develop/init-project).
+2. You wrap up your Rust program into a WASM module just by running a single CLI command.
 
-### Expand Your Knowledge
+3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-- Take a look at the [Ethereum Explorer Tutorial](https://substreams.streamingfast.io/tutorials/evm) to learn about the basic transformations you can create with Substreams.
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
 
-### Substreams Registry
+## Additional Resources
 
-A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs. Visit [substreams.dev](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.
+All Substreams developer documentation is maintained by the StreamingFast core development team on the [Substreams registry](https://docs.substreams.dev).

From cebd07207bfb13df84745965e99a82caa8aeb33a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:30 -0500
Subject: [PATCH 3008/3820] New translations introduction.mdx (Spanish)

---
 website/pages/es/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/es/sps/introduction.mdx b/website/pages/es/sps/introduction.mdx
index 12e3f81c6d53..50f4dd00d584 100644
--- a/website/pages/es/sps/introduction.mdx
+++ b/website/pages/es/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Descripción
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Recursos Adicionales
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From 26bf70aab26f647b5ffac121f2fdcb708ef45d41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:31 -0500
Subject: [PATCH 3009/3820] New translations sps-faq.mdx (Spanish)

---
 website/pages/es/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/es/sps/sps-faq.mdx

diff --git a/website/pages/es/sps/sps-faq.mdx b/website/pages/es/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dc99e916ed7a
--- /dev/null
+++ b/website/pages/es/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From daced79657bf1493a6a372840f72bb437213c85c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:32 -0500
Subject: [PATCH 3010/3820] New translations triggers.mdx (Spanish)

---
 website/pages/es/sps/triggers.mdx | 30 ++++++++++++++++++++----------
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/website/pages/es/sps/triggers.mdx b/website/pages/es/sps/triggers.mdx
index ed19635d4768..b667f7e92b12 100644
--- a/website/pages/es/sps/triggers.mdx
+++ b/website/pages/es/sps/triggers.mdx
@@ -1,16 +1,22 @@
 ---
-title: Substreams Triggers
+title: Disparadores de Substreams
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Descripción
 
-The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
+
+El siguiente código demuestra cómo definir una función 'handleTransactions' en un controlador de subgraph. Esta función recibe bytes sin procesar de Substreams como parámetro y los decodifica en un objeto 'Transactions'. Para cada transacción, se crea una nueva entidad en el subgrafo.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
+
+1. Los bytes que contienen los datos de Substreams se decodifican en el objeto 'Transactions' generado, y este objeto se utiliza como cualquier otro objeto de AssemblyScript.
+2. Iterando sobre las transacciones
+3. Crear una nueva entidad de subgrafo para cada transacción.
+
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
 
-1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
-2. Looping over the transactions
-3. Create a new subgraph entity for every transaction
+### Recursos Adicionales
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 244b66c03896f82c20ea56bd6a3e6bfc35230d0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:33 -0500
Subject: [PATCH 3011/3820] New translations devcontainer.mdx (Spanish)

---
 .../es/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/es/substreams/developing/devcontainer.mdx

diff --git a/website/pages/es/substreams/developing/devcontainer.mdx b/website/pages/es/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..a074eeec7a5d
--- /dev/null
+++ b/website/pages/es/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Prerrequisitos
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 9cde24aee3dbb3fa0350e0c6c1e1955c996c3595 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:34 -0500
Subject: [PATCH 3012/3820] New translations sinks.mdx (Spanish)

---
 .../es/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/es/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/es/substreams/developing/sinks/sinks.mdx b/website/pages/es/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..5c5c2e0ca670
--- /dev/null
+++ b/website/pages/es/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Descripción
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 18144e81d52a4ec1e91262d8a5c2aec52440ba4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:35 -0500
Subject: [PATCH 3013/3820] New translations accountchanges.mdx (Spanish)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/es/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/es/substreams/developing/solana/accountchanges.mdx b/website/pages/es/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..d892424e15e6
--- /dev/null
+++ b/website/pages/es/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introducción
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Empezando
+
+### Prerrequisitos
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 8cd48d7d86666ac5712f75f08d29a4d6444b2f49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:36 -0500
Subject: [PATCH 3014/3820] New translations transactions.mdx (Spanish)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/es/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/es/substreams/developing/solana/transactions.mdx b/website/pages/es/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..5fe868394cd4
--- /dev/null
+++ b/website/pages/es/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgrafo
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Recursos Adicionales
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 0677f48ec048c2dce039d3b04e1a7b5458544891 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:37 -0500
Subject: [PATCH 3015/3820] New translations getting-started-substreams.mdx
 (Spanish)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/es/substreams/getting-started-substreams.mdx

diff --git a/website/pages/es/substreams/getting-started-substreams.mdx b/website/pages/es/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..388ddcb29d23
--- /dev/null
+++ b/website/pages/es/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Descripción
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Recursos Adicionales
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From fa0892bfb35cf96d6a0672ffdacdec7fd2096c3f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:38 -0500
Subject: [PATCH 3016/3820] New translations pubsubstreams.mdx (Spanish)

---
 website/pages/es/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/es/substreams/pubsubstreams.mdx

diff --git a/website/pages/es/substreams/pubsubstreams.mdx b/website/pages/es/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..03ae9ca123c2
--- /dev/null
+++ b/website/pages/es/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Descripción
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Prerrequisitos
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Recursos Adicionales
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 087e4af20597fbc0bbb0b84f1523740be41c3629 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:39 -0500
Subject: [PATCH 3017/3820] New translations tutorial.mdx (Spanish)

---
 website/pages/es/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/es/sps/tutorial.mdx

diff --git a/website/pages/es/sps/tutorial.mdx b/website/pages/es/sps/tutorial.mdx
new file mode 100644
index 000000000000..7eae131c7647
--- /dev/null
+++ b/website/pages/es/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Comenzar
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Prerrequisitos
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Recursos Adicionales
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 1cd4a707c0eb518cb81941f044ccd3926ed6074f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:40 -0500
Subject: [PATCH 3018/3820] New translations introduction.mdx (Arabic)

---
 website/pages/ar/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/ar/sps/introduction.mdx b/website/pages/ar/sps/introduction.mdx
index 12e3f81c6d53..a3dc1a8131e2 100644
--- a/website/pages/ar/sps/introduction.mdx
+++ b/website/pages/ar/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## نظره عامة
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### مصادر إضافية
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From a5ddb9af7a8c662857170646ed039f2a4c007ce3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:41 -0500
Subject: [PATCH 3019/3820] New translations sps-faq.mdx (Arabic)

---
 website/pages/ar/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/ar/sps/sps-faq.mdx

diff --git a/website/pages/ar/sps/sps-faq.mdx b/website/pages/ar/sps/sps-faq.mdx
new file mode 100644
index 000000000000..0bd76ebb777e
--- /dev/null
+++ b/website/pages/ar/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## ما هي الغرافات الفرعية المدعومة بسبستريمز؟
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## كيف تختلف الغرافات الفرعية التي تعمل بسبستريمز عن الغرافات الفرعية؟
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## ما هي فوائد استخدام الغرافات الفرعية المدعومة بسبستريمز؟
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## ماهي فوائد سبستريمز؟
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- التوجيه لأي مكان: يمكنك توجيه بياناتك لأي مكان ترغب فيه: بوستجريسكيو، مونغو دي بي، كافكا، الغرافات الفرعية، الملفات المسطحة، جداول جوجل.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- الوصول إلى بيانات إضافية غير متاحة كجزء من إجراء الإستدعاء عن بعد للترميز الكائني لجافاسكريبت
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+تم تطوير فايرهوز بواسطة [StreamingFast] (https://www.streamingfast.io/) وهو طبقة استخراج بيانات سلاسل الكتل مصممة من الصفر لمعالجة كامل تاريخ سلاسل الكتل بسرعات لم يشهدها من قبل. يوفر نهجاً قائماً على الملفات وأولوية-التدفق، وهو مكون أساسي في مجموعة تقنيات ستريمنج فاست مفتوحة المصدر والأساس لسبستريمز.
+
+انتقل إلى [الوثائق](https://firehose.streamingfast.io/) لمعرفة المزيد حول فايرهوز.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- أقل تأخير وعدم الاستقصاء: بطريقة قائمة على أولوية-التدفق، تم تصميم نقاط فايرهوز للتسابق لدفع بيانات الكتلة أولاً.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- يستفيد من الملفات المسطحة: يتم استخراج بيانات سلسلة الكتل إلى ملفات مسطحة، وهي أرخص وأكثر موارد الحوسبة تحسيناً.
+
+## أين يمكن للمطورين الوصول إلى مزيد من المعلومات حول الغرافات الفرعية المدعومة بسبستريمز و سبستريمز؟
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+تعتبر وحدات رست مكافئة لمعينات أسمبلي اسكريبت في الغرافات الفرعية. يتم ترجمتها إلى ويب أسيمبلي بنفس الطريقة، ولكن النموذج البرمجي يسمح بالتنفيذ الموازي. تحدد وحدات رست نوع التحويلات والتجميعات التي ترغب في تطبيقها على بيانات سلاسل الكتل الخام.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+على سبيل المثال، يمكن لأحمد بناء وحدة أسعار اسواق الصرف اللامركزية، ويمكن لإبراهيم استخدامها لبناء مجمِّع حجم للتوكن المهتم بها، ويمكن لآدم دمج أربع وحدات أسعار ديكس فردية لإنشاء مورد أسعار. سيقوم طلب واحد من سبستريمز بتجميع جميع هذه الوحدات الفردية، وربطها معًا لتقديم تدفق بيانات أكثر تطوراً ودقة. يمكن استخدام هذا التدفق لملءغراف فرعي ويمكن الاستعلام عنه من قبل المستخدمين.
+
+## كيف يمكنك إنشاء ونشر غراف فرعي مدعوم بسبستريمز؟
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## أين يمكنني العثور على أمثلة على سبستريمز والغرافات الفرعية المدعومة بسبستريمز؟
+
+يمكنك زيارة [جيت هب](https://github.com/pinax-network/awesome-substreams) للعثور على أمثلة للسبستريمز والغرافات الفرعية المدعومة بسبستريمز.
+
+## ماذا تعني السبستريمز والغرافات الفرعية المدعومة بسبستريمز بالنسبة لشبكة الغراف؟
+
+إن التكامل مع سبستريمز والغرافات الفرعية المدعومة بسبستريمز واعدة بالعديد من الفوائد، بما في ذلك عمليات فهرسة عالية الأداء وقابلية أكبر للتركيبية من خلال استخدام وحدات المجتمع والبناء عليها.

From b7878cae140db41100a135d914f1ef3c654e600e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:42 -0500
Subject: [PATCH 3020/3820] New translations triggers.mdx (Arabic)

---
 website/pages/ar/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/ar/sps/triggers.mdx b/website/pages/ar/sps/triggers.mdx
index ed19635d4768..3fa4f17d25ad 100644
--- a/website/pages/ar/sps/triggers.mdx
+++ b/website/pages/ar/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## نظره عامة
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### مصادر إضافية
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From ce48b03f7c32084ddc8cc72e46ddeb614d5420d4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:43 -0500
Subject: [PATCH 3021/3820] New translations devcontainer.mdx (Arabic)

---
 .../ar/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/ar/substreams/developing/devcontainer.mdx

diff --git a/website/pages/ar/substreams/developing/devcontainer.mdx b/website/pages/ar/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..63a0dd1dae28
--- /dev/null
+++ b/website/pages/ar/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## المتطلبات الأساسية
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From a9904c95b13218c4b365904c3a322c94bb6ba3bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:44 -0500
Subject: [PATCH 3022/3820] New translations sinks.mdx (Arabic)

---
 .../ar/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/ar/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/ar/substreams/developing/sinks/sinks.mdx b/website/pages/ar/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..067d85b4a45b
--- /dev/null
+++ b/website/pages/ar/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## نظره عامة
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 74f03d84b1b093000a633c57d130a0ea3a81c8c6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:45 -0500
Subject: [PATCH 3023/3820] New translations accountchanges.mdx (Arabic)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/ar/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/ar/substreams/developing/solana/accountchanges.mdx b/website/pages/ar/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..30a3bb194040
--- /dev/null
+++ b/website/pages/ar/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## مقدمة
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Getting Started
+
+### المتطلبات الأساسية
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From e08c8bcdccc76fcda45ea548db3bc71c119b77a8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:46 -0500
Subject: [PATCH 3024/3820] New translations transactions.mdx (Arabic)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/ar/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/ar/substreams/developing/solana/transactions.mdx b/website/pages/ar/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..f77cddb40e68
--- /dev/null
+++ b/website/pages/ar/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## مصادر إضافية
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 68a60f1243646e88f9ab6cfdd3a73d5336b9115d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:47 -0500
Subject: [PATCH 3025/3820] New translations getting-started-substreams.mdx
 (Arabic)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/ar/substreams/getting-started-substreams.mdx

diff --git a/website/pages/ar/substreams/getting-started-substreams.mdx b/website/pages/ar/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..dcfb1c6f17b7
--- /dev/null
+++ b/website/pages/ar/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## نظره عامة
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## مصادر إضافية
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 40524d57a8af9bfea21801cfdc0ebf752fa19861 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:48 -0500
Subject: [PATCH 3026/3820] New translations pubsubstreams.mdx (Arabic)

---
 website/pages/ar/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ar/substreams/pubsubstreams.mdx

diff --git a/website/pages/ar/substreams/pubsubstreams.mdx b/website/pages/ar/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..221fa92fa5a4
--- /dev/null
+++ b/website/pages/ar/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## نظره عامة
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### المتطلبات الأساسية
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## مصادر إضافية
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 42d949f8188ae1fa255d6928c1d888c42965ca3b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:49 -0500
Subject: [PATCH 3027/3820] New translations tutorial.mdx (Arabic)

---
 website/pages/ar/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/ar/sps/tutorial.mdx

diff --git a/website/pages/ar/sps/tutorial.mdx b/website/pages/ar/sps/tutorial.mdx
new file mode 100644
index 000000000000..1c3e299bfd19
--- /dev/null
+++ b/website/pages/ar/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Get Started
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### المتطلبات الأساسية
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### مصادر إضافية
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 8180091e10d081c965f8e466ba1e04f4f7c4de5e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:50 -0500
Subject: [PATCH 3028/3820] New translations introduction.mdx (Czech)

---
 website/pages/cs/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/cs/sps/introduction.mdx b/website/pages/cs/sps/introduction.mdx
index 12e3f81c6d53..e3b6a68ddfa3 100644
--- a/website/pages/cs/sps/introduction.mdx
+++ b/website/pages/cs/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Přehled
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Další zdroje
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From a43b793f78170b2b7a0409338e2858fee46479e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:51 -0500
Subject: [PATCH 3029/3820] New translations sps-faq.mdx (Czech)

---
 website/pages/cs/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/cs/sps/sps-faq.mdx

diff --git a/website/pages/cs/sps/sps-faq.mdx b/website/pages/cs/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dd1b882d03f3
--- /dev/null
+++ b/website/pages/cs/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## Co jsou substreamu?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## Co jsou substreamu napájen podgrafy?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## Jak se liší substream, které jsou napájeny podgrafy, od podgrafů?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## Jaké jsou výhody používání substreamu, které jsou založeny na podgraf?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## Jaké jsou výhody Substreams?
+
+Používání ubstreams má mnoho výhod, mimo jiné:
+
+- Složitelný: Moduly Substreams můžete skládat na sebe jako kostky LEGO, stavět na komunitních moduly a dále vylepšovat veřejná data.
+
+- Vysoce výkonné indexování: Řádově rychlejší indexování prostřednictvím rozsáhlých klastrů paralelních operací (viz BigQuery).
+
+- Umyvadlo kdekoli: Data můžete ukládat kamkoli chcete: Vložte data do PostgreSQL, MongoDB, Kafka, podgrafy, ploché soubory, tabulky Google.
+
+- Programovatelné: Pomocí kódu můžete přizpůsobit extrakci, provádět agregace v čase transformace a modelovat výstup pro více zdrojů.
+
+- Přístup k dalším údajům, které nejsou k dispozici jako součást JSON RPC
+
+- Všechny výhody Firehose.
+
+## Co je Firehose?
+
+Firehose, vyvinutý společností [StreamingFast](https://www.streamingfast.io/), je vrstva pro extrakci dat z blockchainu, která byla od základu navržena tak, aby zpracovávala celou historii blockchainu dosud nevídanou rychlostí. Poskytuje přístup založený na souborech a streamování v první řadě a je klíčovou součástí sady open-source technologií StreamingFast a základem pro Substreams.
+
+Další informace o Firehose najdete v [dokumentaci](https://firehose.streamingfast.io/).
+
+## Jaké jsou výhody Firehose?
+
+Používání Firehose přináší mnoho výhod, včetně:
+
+- Nejnižší latence a žádné dotazování: Uzly Firehose jsou navrženy tak, aby se předháněly v odesílání blokových dat jako první.
+
+- Předchází výpadkům: Navrženo od základu pro vysokou dostupnost.
+
+- Nikdy nezmeškáte ani minutu: Proudový kurzor Firehose je navržen tak, aby si poradil s rozcestími a pokračoval tam, kde jste skončili, za jakýchkoli podmínek.
+
+- Nejbohatší datový model:  Nejlepší datový model, který zahrnuje změny zůstatku, celý strom volání, interní transakce, protokoly, změny v úložišti, náklady na plyn a další.
+
+- Využívá ploché soubory: Blockchain data jsou extrahována do plochých souborů, což je nejlevnější a nejoptimálnější dostupný výpočetní zdroj.
+
+## Kde mohou vývojáři získat více informací o substreamu, které jsou založeny na podgraf a substreamu?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## Jaká je role modulů Rust v Substreamu?
+
+Moduly Rust jsou ekvivalentem mapovačů AssemblyScript v podgraf. Jsou kompilovány do WASM podobným způsobem, ale programovací model umožňuje paralelní provádění. Definují druh transformací a agregací, které chcete aplikovat na surová data blockchainu.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## Co dělá Substreamy složitelnými?
+
+Při použití substreamů probíhá kompozice na transformační vrstvě, což umožňuje opakované použití modulů uložených v mezipaměti.
+
+Jako příklad může Alice vytvořit cenový modul DEX, Bob jej může použít k vytvoření agregátoru objemu pro některé tokeny, které ho zajímají, a Lisa může zkombinovat čtyři jednotlivé cenové moduly DEX a vytvořit cenové orákulum. Jediný požadavek Substreams zabalí všechny moduly těchto jednotlivců, propojí je dohromady a nabídne mnohem sofistikovanější tok dat. Tento proud pak může být použit k naplnění podgrafu a může být dotazován spotřebiteli.
+
+## Jak můžete vytvořit a nasadit Substreams využívající podgraf?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Kde najdu příklady podgrafů Substreams a Substreams-powered?
+
+Příklady podgrafů Substreams a Substreams-powered najdete na [tomto repozitáři Github](https://github.com/pinax-network/awesome-substreams).
+
+## Co znamenají substreams a podgrafy napájené substreams pro síť grafů?
+
+Integrace slibuje mnoho výhod, včetně extrémně výkonného indexování a větší složitelnosti díky využití komunitních modulů a stavění na nich.

From 05ad1ae65baab0541a56b6ac77aad5a146b3b264 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:52 -0500
Subject: [PATCH 3030/3820] New translations triggers.mdx (Czech)

---
 website/pages/cs/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/cs/sps/triggers.mdx b/website/pages/cs/sps/triggers.mdx
index ed19635d4768..00650d6ab1ad 100644
--- a/website/pages/cs/sps/triggers.mdx
+++ b/website/pages/cs/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Přehled
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Další zdroje
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From aa5bfc1d644dd9a3e676a9e111a45f2d8f70d96f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:52 -0500
Subject: [PATCH 3031/3820] New translations devcontainer.mdx (Czech)

---
 .../cs/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/cs/substreams/developing/devcontainer.mdx

diff --git a/website/pages/cs/substreams/developing/devcontainer.mdx b/website/pages/cs/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..cfa4c45db531
--- /dev/null
+++ b/website/pages/cs/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Požadavky
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From b484b2df6a2ca4847395833763cfc0afc7a1baf6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:53 -0500
Subject: [PATCH 3032/3820] New translations sinks.mdx (Czech)

---
 .../cs/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/cs/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/cs/substreams/developing/sinks/sinks.mdx b/website/pages/cs/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..f3e7f342c08f
--- /dev/null
+++ b/website/pages/cs/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Přehled
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 08d93f99181803e9714ff3d3759b40d25b2c5b3f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:54 -0500
Subject: [PATCH 3033/3820] New translations accountchanges.mdx (Czech)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/cs/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/cs/substreams/developing/solana/accountchanges.mdx b/website/pages/cs/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..398f80bb3068
--- /dev/null
+++ b/website/pages/cs/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Úvod
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Začínáme
+
+### Požadavky
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 31c8f44c94a85e6df6c5674e92538af1e255f56c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:56 -0500
Subject: [PATCH 3034/3820] New translations transactions.mdx (Czech)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/cs/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/cs/substreams/developing/solana/transactions.mdx b/website/pages/cs/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..fecc546a2fe6
--- /dev/null
+++ b/website/pages/cs/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Podgrafy
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Další zdroje
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 1f297985654eb030153d7ff210e84121fbd0f653 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:57 -0500
Subject: [PATCH 3035/3820] New translations getting-started-substreams.mdx
 (Czech)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/cs/substreams/getting-started-substreams.mdx

diff --git a/website/pages/cs/substreams/getting-started-substreams.mdx b/website/pages/cs/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..c63d499900c3
--- /dev/null
+++ b/website/pages/cs/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Přehled
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Další zdroje
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 169eea527e74d05a9644aff6b73cf0be54e892f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:57 -0500
Subject: [PATCH 3036/3820] New translations pubsubstreams.mdx (Czech)

---
 website/pages/cs/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/cs/substreams/pubsubstreams.mdx

diff --git a/website/pages/cs/substreams/pubsubstreams.mdx b/website/pages/cs/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..6ab6a8919a74
--- /dev/null
+++ b/website/pages/cs/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Přehled
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Požadavky
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Další zdroje
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From a906edfad61b344d9f863ae39a3cf2f53b111fd9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:25:58 -0500
Subject: [PATCH 3037/3820] New translations tutorial.mdx (Czech)

---
 website/pages/cs/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/cs/sps/tutorial.mdx

diff --git a/website/pages/cs/sps/tutorial.mdx b/website/pages/cs/sps/tutorial.mdx
new file mode 100644
index 000000000000..d6c4763d7da7
--- /dev/null
+++ b/website/pages/cs/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Začněte
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Požadavky
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Závěr
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Další zdroje
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 3c5d85a6540d9ddd9338cab18bf0011b3ea7bbf5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:01 -0500
Subject: [PATCH 3038/3820] New translations introduction.mdx (German)

---
 website/pages/de/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/de/sps/introduction.mdx b/website/pages/de/sps/introduction.mdx
index 12e3f81c6d53..238ebe105bf4 100644
--- a/website/pages/de/sps/introduction.mdx
+++ b/website/pages/de/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Überblick
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Besonderheiten
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Zusätzliche Ressourcen
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From ae96e1707dd6653e02199370f8955aac4a705843 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:02 -0500
Subject: [PATCH 3039/3820] New translations sps-faq.mdx (German)

---
 website/pages/de/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/de/sps/sps-faq.mdx

diff --git a/website/pages/de/sps/sps-faq.mdx b/website/pages/de/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dc99e916ed7a
--- /dev/null
+++ b/website/pages/de/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From ad527fdf9d64b02efb5385d1ff23670f5f168da9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:03 -0500
Subject: [PATCH 3040/3820] New translations triggers.mdx (German)

---
 website/pages/de/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/de/sps/triggers.mdx b/website/pages/de/sps/triggers.mdx
index ed19635d4768..ab9828bc0427 100644
--- a/website/pages/de/sps/triggers.mdx
+++ b/website/pages/de/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Überblick
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Zusätzliche Ressourcen
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 1c0ae841f4f433101c2e4fbc5e9b3aeb9c3374f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:04 -0500
Subject: [PATCH 3041/3820] New translations devcontainer.mdx (German)

---
 .../de/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/de/substreams/developing/devcontainer.mdx

diff --git a/website/pages/de/substreams/developing/devcontainer.mdx b/website/pages/de/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..3a965b879168
--- /dev/null
+++ b/website/pages/de/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Vorbedingungen
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 5a26d91568dc6c10ea4a710a16fbd39b98e06f79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:05 -0500
Subject: [PATCH 3042/3820] New translations sinks.mdx (German)

---
 .../de/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/de/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/de/substreams/developing/sinks/sinks.mdx b/website/pages/de/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..307868fd6cc7
--- /dev/null
+++ b/website/pages/de/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Überblick
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 2856c8a9da7161fe174b610718c430f758381952 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:06 -0500
Subject: [PATCH 3043/3820] New translations accountchanges.mdx (German)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/de/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/de/substreams/developing/solana/accountchanges.mdx b/website/pages/de/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..715f781e5c92
--- /dev/null
+++ b/website/pages/de/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Einführung
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Erste Schritte
+
+### Vorbedingungen
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From de501deeabdcdc26f5696e8a83250126da22417d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:07 -0500
Subject: [PATCH 3044/3820] New translations transactions.mdx (German)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/de/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/de/substreams/developing/solana/transactions.mdx b/website/pages/de/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..c260ac6acb13
--- /dev/null
+++ b/website/pages/de/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Zusätzliche Ressourcen
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 553b5187f36ff584efb242453d2094fd65d8ef62 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:08 -0500
Subject: [PATCH 3045/3820] New translations getting-started-substreams.mdx
 (German)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/de/substreams/getting-started-substreams.mdx

diff --git a/website/pages/de/substreams/getting-started-substreams.mdx b/website/pages/de/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..3720eac03d47
--- /dev/null
+++ b/website/pages/de/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Überblick
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start des Erstellens
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Zusätzliche Ressourcen
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 3732601b7e5b242f7d36bddd739b4bc876034874 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:09 -0500
Subject: [PATCH 3046/3820] New translations pubsubstreams.mdx (German)

---
 website/pages/de/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/de/substreams/pubsubstreams.mdx

diff --git a/website/pages/de/substreams/pubsubstreams.mdx b/website/pages/de/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..f32113216d9d
--- /dev/null
+++ b/website/pages/de/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Überblick
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Vorbedingungen
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Zusätzliche Ressourcen
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 56ffee25ae46c2c7b2456163e7e1820ff20e3268 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:10 -0500
Subject: [PATCH 3047/3820] New translations tutorial.mdx (German)

---
 website/pages/de/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/de/sps/tutorial.mdx

diff --git a/website/pages/de/sps/tutorial.mdx b/website/pages/de/sps/tutorial.mdx
new file mode 100644
index 000000000000..216df687b3f7
--- /dev/null
+++ b/website/pages/de/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Los geht’s
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Vorbedingungen
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Zusätzliche Ressourcen
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 9436b554d8315518558b8ae1f6214ee20f68262b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:11 -0500
Subject: [PATCH 3048/3820] New translations introduction.mdx (Italian)

---
 website/pages/it/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/it/sps/introduction.mdx b/website/pages/it/sps/introduction.mdx
index 12e3f81c6d53..ded4abf2de07 100644
--- a/website/pages/it/sps/introduction.mdx
+++ b/website/pages/it/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Panoramica
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Additional Resources
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From 3f05b54d313e8f0574c6d26b7a48be836936a7fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:12 -0500
Subject: [PATCH 3049/3820] New translations sps-faq.mdx (Italian)

---
 website/pages/it/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/it/sps/sps-faq.mdx

diff --git a/website/pages/it/sps/sps-faq.mdx b/website/pages/it/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dc99e916ed7a
--- /dev/null
+++ b/website/pages/it/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 22f3d3e803ac59f9f8b7d857f1fc9d0376864633 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:13 -0500
Subject: [PATCH 3050/3820] New translations triggers.mdx (Italian)

---
 website/pages/it/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/it/sps/triggers.mdx b/website/pages/it/sps/triggers.mdx
index ed19635d4768..be8b1c798e5c 100644
--- a/website/pages/it/sps/triggers.mdx
+++ b/website/pages/it/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Panoramica
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Additional Resources
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From e28945af0744c29651a5d7caaba51961f91968da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:14 -0500
Subject: [PATCH 3051/3820] New translations devcontainer.mdx (Italian)

---
 .../it/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/it/substreams/developing/devcontainer.mdx

diff --git a/website/pages/it/substreams/developing/devcontainer.mdx b/website/pages/it/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..ac79e64539a9
--- /dev/null
+++ b/website/pages/it/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Prerequisiti
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From e0b82bcda16eecddf7ed1c7e3ddb4f30bd5202ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:15 -0500
Subject: [PATCH 3052/3820] New translations sinks.mdx (Italian)

---
 .../it/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/it/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/it/substreams/developing/sinks/sinks.mdx b/website/pages/it/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..6fe4c873ecac
--- /dev/null
+++ b/website/pages/it/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Panoramica
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From dc1e1dc386739ff0fe287cb8fef119c746778340 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:16 -0500
Subject: [PATCH 3053/3820] New translations accountchanges.mdx (Italian)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/it/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/it/substreams/developing/solana/accountchanges.mdx b/website/pages/it/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..ef5a358858eb
--- /dev/null
+++ b/website/pages/it/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introduzione
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Per cominciare
+
+### Prerequisiti
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From aa20866cd668bcb1834ac482e35eae59e34fbc20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:17 -0500
Subject: [PATCH 3054/3820] New translations transactions.mdx (Italian)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/it/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/it/substreams/developing/solana/transactions.mdx b/website/pages/it/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..8e5d7c35d4e7
--- /dev/null
+++ b/website/pages/it/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Additional Resources
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From ca306bd651a7e094fd4d29f430e6171848db39a2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:18 -0500
Subject: [PATCH 3055/3820] New translations getting-started-substreams.mdx
 (Italian)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/it/substreams/getting-started-substreams.mdx

diff --git a/website/pages/it/substreams/getting-started-substreams.mdx b/website/pages/it/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..1fa25378ace1
--- /dev/null
+++ b/website/pages/it/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Panoramica
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Additional Resources
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 6513903fbbe44c08bae76c9f8cd34c994e64ad6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:19 -0500
Subject: [PATCH 3056/3820] New translations pubsubstreams.mdx (Italian)

---
 website/pages/it/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/it/substreams/pubsubstreams.mdx

diff --git a/website/pages/it/substreams/pubsubstreams.mdx b/website/pages/it/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..b581ade70fa7
--- /dev/null
+++ b/website/pages/it/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Panoramica
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Prerequisiti
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Additional Resources
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 9bdb95f3dc486b9dfcbeb62375f1f2f63a11e31f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:20 -0500
Subject: [PATCH 3057/3820] New translations tutorial.mdx (Italian)

---
 website/pages/it/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/it/sps/tutorial.mdx

diff --git a/website/pages/it/sps/tutorial.mdx b/website/pages/it/sps/tutorial.mdx
new file mode 100644
index 000000000000..ffea198c6f7c
--- /dev/null
+++ b/website/pages/it/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Iniziare
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Prerequisiti
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Additional Resources
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 8e560b8af1b99c17971099ba9ef35bb1d0aa475e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:21 -0500
Subject: [PATCH 3058/3820] New translations introduction.mdx (Japanese)

---
 website/pages/ja/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/ja/sps/introduction.mdx b/website/pages/ja/sps/introduction.mdx
index 12e3f81c6d53..3d3b505658a3 100644
--- a/website/pages/ja/sps/introduction.mdx
+++ b/website/pages/ja/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## 概要
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### その他のリソース
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From 68989077a23dca088afb0245b292b833b634f049 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:22 -0500
Subject: [PATCH 3059/3820] New translations sps-faq.mdx (Japanese)

---
 website/pages/ja/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/ja/sps/sps-faq.mdx

diff --git a/website/pages/ja/sps/sps-faq.mdx b/website/pages/ja/sps/sps-faq.mdx
new file mode 100644
index 000000000000..d9f7b8dd8d5c
--- /dev/null
+++ b/website/pages/ja/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## サブストリームとは何ですか?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## サブストリームによって動作するサブグラフは何ですか？
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## サブストリームを利用したサブグラフはサブグラフとどう違うのでしょうか?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## サブストリームを利用したサブグラフを使用する利点は何ですか?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## サブストリームの利点は何ですか?
+
+サブストリームを使用すると、次のような多くの利点があります。
+
+- コンポーザブル: レゴ ブロックのようなサブストリーム モジュールを積み重ね、コミュニティ モジュールを基にして公開データをさらに洗練させることができます。
+
+- 高パフォーマンスのインデックス作成: 並列操作の大規模なクラスター (BigQuery を考えてください) を通じて、桁違いに高速なインデックス作成を実現します。
+
+- 場所を選ばずにデータをどこにでも沈める: PostgreSQL、MongoDB、Kafka、サブグラフ、フラットファイル、Googleシート。
+
+- プログラム可能: コードを使用して抽出をカスタマイズし、変換時の集計を実行し、複数のシンクの出力をモデル化します。
+
+- JSON RPC の一部として利用できない追加データへのアクセス
+
+- Firehose のすべての利点。
+
+## 消防ホースとは何ですか?
+
+[StreamingFast](https://www.streamingfast.io/) によって開発された Firehose は、ブロックチェーンの全履歴をこれまで見たことのない速度で処理するためにゼロから設計されたブロックチェーン データ抽出レイヤーです。ファイルベースでストリーミングファーストのアプローチを提供するこれは、StreamingFast のオープンソース テクノロジ スイートの中核コンポーネントであり、サブストリームの基盤です。
+
+Firehose の詳細については、[documentation](https://firehose.streamingfast.io/) にアクセスしてください。
+
+## 消防ホースの利点は何ですか?
+
+Firehose を使用すると、次のような多くの利点があります。
+
+- 最低のレイテンシーとポーリングなし: ストリーミングファーストの方式で、Firehose ノードはブロック データを最初にプッシュするために競合するように設計されています。
+
+- ダウンタイムの防止: 高可用性を実現するためにゼロから設計されています。
+
+- ビートを見逃すことはありません: Firehose ストリーム カーソルは、フォークを処理し、どのような状況でも中断したところから続行するように設計されています。
+
+- 最も豊富なデータ モデル: 残高の変更、完全なコール ツリー、内部トランザクション、ログ、ストレージの変更、ガス料金などが含まれる最適なデータ モデル。
+
+- フラット ファイルの活用: ブロックチェーン データは、利用可能な最も安価で最適化されたコンピューティング リソースであるフラット ファイルに抽出されます。
+
+## 開発者は、サブストリームを利用したサブグラフとサブストリームに関する詳細情報にどこでアクセスできますか?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## サブストリームにおけるRustモジュールの役割は何ですか?
+
+Rust モジュールは、サブグラフの AssemblyScript マッパーに相当します。これらは同様の方法で WASM にコンパイルされますが、プログラミング モデルにより並列実行が可能になります。これらは、生のブロックチェーン データに適用する変換と集計の種類を定義します。
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## サブストリームを構成可能にするものは何ですか?
+
+サブストリームを使用すると、変換レイヤーで合成が行われ、キャッシュされたモジュールを再利用できるようになります。
+
+例として、AliceはDEX価格モジュールを構築し、Bobはそれを使用して興味のあるいくつかのトークンのボリューム集計モジュールを構築し、Lisaは4つの個々のDEX価格モジュールを組み合わせて価格オラクルを作成することができます。単一のSubstreamsリクエストは、これらの個々のモジュールをまとめ、リンクしてより洗練されたデータのストリームを提供します。そのストリームはその後、サブグラフを作成し、消費者によってクエリされることができます。
+
+## サブストリームを利用したサブグラフを構築してデプロイするにはどうすればよいでしょうか?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## サブストリームおよびサブストリームを利用したサブグラフの例はどこで見つけることができますか?
+
+[この Github リポジトリ](https://github.com/pinax-network/awesome-substreams) にアクセスして、サブストリームとサブストリームを利用したサブグラフの例を見つけることができます。
+
+## SubstreamsとSubstreamsを活用したサブグラフがThe Graph Networkにとってどのような意味を持つのでしょうか？
+
+この統合は、非常に高いパフォーマンスのインデクシングと、コミュニティモジュールを活用し、それらを基に構築することによる大きな組み合わせ可能性を含む多くの利点を約束しています。

From 80bc7be52376b91139da5a20ff82c04d3533f0d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:23 -0500
Subject: [PATCH 3060/3820] New translations triggers.mdx (Japanese)

---
 website/pages/ja/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/ja/sps/triggers.mdx b/website/pages/ja/sps/triggers.mdx
index ed19635d4768..702c3dab5b36 100644
--- a/website/pages/ja/sps/triggers.mdx
+++ b/website/pages/ja/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## 概要
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### その他のリソース
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From cd1a03e444182322a2eeb56d53f7478e4d50edf5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:24 -0500
Subject: [PATCH 3061/3820] New translations devcontainer.mdx (Japanese)

---
 .../ja/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/ja/substreams/developing/devcontainer.mdx

diff --git a/website/pages/ja/substreams/developing/devcontainer.mdx b/website/pages/ja/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..15b75ad6e38b
--- /dev/null
+++ b/website/pages/ja/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## 前提条件
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 568bf5e34119e8078f609e2340876986ebaf0277 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:25 -0500
Subject: [PATCH 3062/3820] New translations sinks.mdx (Japanese)

---
 .../ja/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/ja/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/ja/substreams/developing/sinks/sinks.mdx b/website/pages/ja/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..c05383c3f363
--- /dev/null
+++ b/website/pages/ja/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## 概要
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 1f31aa4cdd2931dc6296e38db8153678a93d279f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:26 -0500
Subject: [PATCH 3063/3820] New translations accountchanges.mdx (Japanese)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/ja/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/ja/substreams/developing/solana/accountchanges.mdx b/website/pages/ja/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..0aaba30a3d53
--- /dev/null
+++ b/website/pages/ja/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## イントロダクション
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## はじめに
+
+### 前提条件
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 258ca50700b406c5f9cc45a391cad747b06441a2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:27 -0500
Subject: [PATCH 3064/3820] New translations transactions.mdx (Japanese)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/ja/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/ja/substreams/developing/solana/transactions.mdx b/website/pages/ja/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..493aaed91265
--- /dev/null
+++ b/website/pages/ja/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### サブグラフ
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## その他のリソース
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 4ad392b18e97e3c3782c641a3fbed937850ca501 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:28 -0500
Subject: [PATCH 3065/3820] New translations getting-started-substreams.mdx
 (Japanese)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/ja/substreams/getting-started-substreams.mdx

diff --git a/website/pages/ja/substreams/getting-started-substreams.mdx b/website/pages/ja/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..11933c4eae2e
--- /dev/null
+++ b/website/pages/ja/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## 概要
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## その他のリソース
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 812e1e3e22785c9faa2f645ed2618337e66f186e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:29 -0500
Subject: [PATCH 3066/3820] New translations pubsubstreams.mdx (Japanese)

---
 website/pages/ja/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ja/substreams/pubsubstreams.mdx

diff --git a/website/pages/ja/substreams/pubsubstreams.mdx b/website/pages/ja/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..71e467bb275a
--- /dev/null
+++ b/website/pages/ja/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## 概要
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### 前提条件
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## その他のリソース
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 57de53e170061106d57fc12ba8b20f0956fb32ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:30 -0500
Subject: [PATCH 3067/3820] New translations tutorial.mdx (Japanese)

---
 website/pages/ja/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/ja/sps/tutorial.mdx

diff --git a/website/pages/ja/sps/tutorial.mdx b/website/pages/ja/sps/tutorial.mdx
new file mode 100644
index 000000000000..9757100186fe
--- /dev/null
+++ b/website/pages/ja/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## 始めましょう
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### 前提条件
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### その他のリソース
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 2f4c755e463134431ec8da61dee42d382f38d676 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:31 -0500
Subject: [PATCH 3068/3820] New translations introduction.mdx (Korean)

---
 website/pages/ko/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/ko/sps/introduction.mdx b/website/pages/ko/sps/introduction.mdx
index 12e3f81c6d53..aa44f605ce65 100644
--- a/website/pages/ko/sps/introduction.mdx
+++ b/website/pages/ko/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Overview
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Additional Resources
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From e56fc2409d6dcccb53f242b4e27b69553375d609 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:31 -0500
Subject: [PATCH 3069/3820] New translations sps-faq.mdx (Korean)

---
 website/pages/ko/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/ko/sps/sps-faq.mdx

diff --git a/website/pages/ko/sps/sps-faq.mdx b/website/pages/ko/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dc99e916ed7a
--- /dev/null
+++ b/website/pages/ko/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 45e92c4450a204b37e66fee47a01c4f89b0f4c99 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:32 -0500
Subject: [PATCH 3070/3820] New translations triggers.mdx (Korean)

---
 website/pages/ko/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/ko/sps/triggers.mdx b/website/pages/ko/sps/triggers.mdx
index ed19635d4768..b346119555c1 100644
--- a/website/pages/ko/sps/triggers.mdx
+++ b/website/pages/ko/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Overview
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Additional Resources
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 601b4e795b059abb659d472ea7ee4a0ae979870c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:34 -0500
Subject: [PATCH 3071/3820] New translations devcontainer.mdx (Korean)

---
 .../ko/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/ko/substreams/developing/devcontainer.mdx

diff --git a/website/pages/ko/substreams/developing/devcontainer.mdx b/website/pages/ko/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..cd65c8d046f8
--- /dev/null
+++ b/website/pages/ko/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Prerequisites
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From d5c6e2ef93987f531fefd9ef4264aa290c752923 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:35 -0500
Subject: [PATCH 3072/3820] New translations sinks.mdx (Korean)

---
 .../ko/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/ko/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/ko/substreams/developing/sinks/sinks.mdx b/website/pages/ko/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..3f761c18f0a8
--- /dev/null
+++ b/website/pages/ko/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Overview
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From a85f1704154dae21a88fa10e4866b151034aa52f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:35 -0500
Subject: [PATCH 3073/3820] New translations accountchanges.mdx (Korean)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/ko/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/ko/substreams/developing/solana/accountchanges.mdx b/website/pages/ko/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..53ab95612a29
--- /dev/null
+++ b/website/pages/ko/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introduction
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Getting Started
+
+### Prerequisites
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 56029995fbea54b47e79274590bb334e28d2445f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:36 -0500
Subject: [PATCH 3074/3820] New translations transactions.mdx (Korean)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/ko/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/ko/substreams/developing/solana/transactions.mdx b/website/pages/ko/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..8e5d7c35d4e7
--- /dev/null
+++ b/website/pages/ko/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Additional Resources
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 18ec0a1a20744e12566cfeb6a4e3b4e99b420d5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:37 -0500
Subject: [PATCH 3075/3820] New translations getting-started-substreams.mdx
 (Korean)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/ko/substreams/getting-started-substreams.mdx

diff --git a/website/pages/ko/substreams/getting-started-substreams.mdx b/website/pages/ko/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..5541cc56d347
--- /dev/null
+++ b/website/pages/ko/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Overview
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Additional Resources
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From d97f9c10d7e2544767539689244e363b0a96d0d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:38 -0500
Subject: [PATCH 3076/3820] New translations pubsubstreams.mdx (Korean)

---
 website/pages/ko/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ko/substreams/pubsubstreams.mdx

diff --git a/website/pages/ko/substreams/pubsubstreams.mdx b/website/pages/ko/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..3c02d60f9ffd
--- /dev/null
+++ b/website/pages/ko/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Overview
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Prerequisites
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Additional Resources
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 54c64a097d7c5dd2b2018fadbe2ceb099ac1416c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:39 -0500
Subject: [PATCH 3077/3820] New translations tutorial.mdx (Korean)

---
 website/pages/ko/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/ko/sps/tutorial.mdx

diff --git a/website/pages/ko/sps/tutorial.mdx b/website/pages/ko/sps/tutorial.mdx
new file mode 100644
index 000000000000..b17e5d9ff491
--- /dev/null
+++ b/website/pages/ko/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Get Started
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Additional Resources
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 6f1e66121561bbda4c72810aa565ba1f8a3978e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:40 -0500
Subject: [PATCH 3078/3820] New translations introduction.mdx (Dutch)

---
 website/pages/nl/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/nl/sps/introduction.mdx b/website/pages/nl/sps/introduction.mdx
index 12e3f81c6d53..aa44f605ce65 100644
--- a/website/pages/nl/sps/introduction.mdx
+++ b/website/pages/nl/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Overview
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Additional Resources
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From 7e59d70a57e237cf3f6913ea234b58df4cc15c34 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:41 -0500
Subject: [PATCH 3079/3820] New translations sps-faq.mdx (Dutch)

---
 website/pages/nl/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/nl/sps/sps-faq.mdx

diff --git a/website/pages/nl/sps/sps-faq.mdx b/website/pages/nl/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dc99e916ed7a
--- /dev/null
+++ b/website/pages/nl/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From c0048e6060c86401851ba0651639e7d768b6dd1d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:42 -0500
Subject: [PATCH 3080/3820] New translations triggers.mdx (Dutch)

---
 website/pages/nl/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/nl/sps/triggers.mdx b/website/pages/nl/sps/triggers.mdx
index ed19635d4768..b346119555c1 100644
--- a/website/pages/nl/sps/triggers.mdx
+++ b/website/pages/nl/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Overview
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Additional Resources
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 2f501b8e0f3f6a7799dd6306ebac53b56ade2dc8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:43 -0500
Subject: [PATCH 3081/3820] New translations devcontainer.mdx (Dutch)

---
 .../nl/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/nl/substreams/developing/devcontainer.mdx

diff --git a/website/pages/nl/substreams/developing/devcontainer.mdx b/website/pages/nl/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..831ca36c6b65
--- /dev/null
+++ b/website/pages/nl/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Vereisten
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From c99c1102f08244a8222d4c633be63cd8221753d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:44 -0500
Subject: [PATCH 3082/3820] New translations sinks.mdx (Dutch)

---
 .../nl/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/nl/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/nl/substreams/developing/sinks/sinks.mdx b/website/pages/nl/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..3f761c18f0a8
--- /dev/null
+++ b/website/pages/nl/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Overview
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From e4df8e5aaeac164a308b9c9b1e1164b3850554ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:45 -0500
Subject: [PATCH 3083/3820] New translations accountchanges.mdx (Dutch)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/nl/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/nl/substreams/developing/solana/accountchanges.mdx b/website/pages/nl/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..d02872da0c93
--- /dev/null
+++ b/website/pages/nl/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introduction
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Getting Started
+
+### Vereisten
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 749ba31679e1e0a2b55236e868a299475e6f9b00 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:46 -0500
Subject: [PATCH 3084/3820] New translations transactions.mdx (Dutch)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/nl/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/nl/substreams/developing/solana/transactions.mdx b/website/pages/nl/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..8e5d7c35d4e7
--- /dev/null
+++ b/website/pages/nl/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Additional Resources
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 1ada885dad18cc5eebdf1bf702048b8da9892e48 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:49 -0500
Subject: [PATCH 3085/3820] New translations getting-started-substreams.mdx
 (Dutch)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/nl/substreams/getting-started-substreams.mdx

diff --git a/website/pages/nl/substreams/getting-started-substreams.mdx b/website/pages/nl/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..5541cc56d347
--- /dev/null
+++ b/website/pages/nl/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Overview
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Additional Resources
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 452dc95ff613fecf21d998872229e904b4f0b816 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:50 -0500
Subject: [PATCH 3086/3820] New translations pubsubstreams.mdx (Dutch)

---
 website/pages/nl/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/nl/substreams/pubsubstreams.mdx

diff --git a/website/pages/nl/substreams/pubsubstreams.mdx b/website/pages/nl/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..962d7d664b9b
--- /dev/null
+++ b/website/pages/nl/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Overview
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Vereisten
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Additional Resources
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From d0540dba1e1ec58b4a85dd1bf01175348b2518e2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:51 -0500
Subject: [PATCH 3087/3820] New translations tutorial.mdx (Dutch)

---
 website/pages/nl/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/nl/sps/tutorial.mdx

diff --git a/website/pages/nl/sps/tutorial.mdx b/website/pages/nl/sps/tutorial.mdx
new file mode 100644
index 000000000000..641baea4938d
--- /dev/null
+++ b/website/pages/nl/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Begin
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Vereisten
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Additional Resources
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From aa4478be53d81ed777b1952ee8db61824c1ae878 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:52 -0500
Subject: [PATCH 3088/3820] New translations introduction.mdx (Polish)

---
 website/pages/pl/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/pl/sps/introduction.mdx b/website/pages/pl/sps/introduction.mdx
index 12e3f81c6d53..aa44f605ce65 100644
--- a/website/pages/pl/sps/introduction.mdx
+++ b/website/pages/pl/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Overview
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Additional Resources
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From 82c4858073938b91cbfbe43e9226782bd7125eef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:53 -0500
Subject: [PATCH 3089/3820] New translations sps-faq.mdx (Polish)

---
 website/pages/pl/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/pl/sps/sps-faq.mdx

diff --git a/website/pages/pl/sps/sps-faq.mdx b/website/pages/pl/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dc99e916ed7a
--- /dev/null
+++ b/website/pages/pl/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From db72d9e1040d11c817261be4ef73dd0bb0b43689 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:54 -0500
Subject: [PATCH 3090/3820] New translations triggers.mdx (Polish)

---
 website/pages/pl/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/pl/sps/triggers.mdx b/website/pages/pl/sps/triggers.mdx
index ed19635d4768..b346119555c1 100644
--- a/website/pages/pl/sps/triggers.mdx
+++ b/website/pages/pl/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Overview
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Additional Resources
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 8409589dfd15ca9b660ddb8cb27ad8353c149677 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:55 -0500
Subject: [PATCH 3091/3820] New translations devcontainer.mdx (Polish)

---
 .../pl/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/pl/substreams/developing/devcontainer.mdx

diff --git a/website/pages/pl/substreams/developing/devcontainer.mdx b/website/pages/pl/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..cd65c8d046f8
--- /dev/null
+++ b/website/pages/pl/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Prerequisites
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 17414c756c5623c6a7c1be74a509214797567a4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:56 -0500
Subject: [PATCH 3092/3820] New translations sinks.mdx (Polish)

---
 .../pl/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/pl/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/pl/substreams/developing/sinks/sinks.mdx b/website/pages/pl/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..3f761c18f0a8
--- /dev/null
+++ b/website/pages/pl/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Overview
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From d41a14c9171acc002d90e075655aa10002cac5e1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:56 -0500
Subject: [PATCH 3093/3820] New translations accountchanges.mdx (Polish)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/pl/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/pl/substreams/developing/solana/accountchanges.mdx b/website/pages/pl/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..d2a34dbe8fc6
--- /dev/null
+++ b/website/pages/pl/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Wstęp
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Getting Started
+
+### Prerequisites
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 0678fd85b0786bcaedb987e8dc5ca363d48b2e8d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:58 -0500
Subject: [PATCH 3094/3820] New translations transactions.mdx (Polish)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/pl/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/pl/substreams/developing/solana/transactions.mdx b/website/pages/pl/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..8e5d7c35d4e7
--- /dev/null
+++ b/website/pages/pl/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Additional Resources
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From f1893df37269f275c7b41813433a82d781adf1bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:26:59 -0500
Subject: [PATCH 3095/3820] New translations getting-started-substreams.mdx
 (Polish)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/pl/substreams/getting-started-substreams.mdx

diff --git a/website/pages/pl/substreams/getting-started-substreams.mdx b/website/pages/pl/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..5541cc56d347
--- /dev/null
+++ b/website/pages/pl/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Overview
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Additional Resources
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 458bccd008b82e36d7c0158340ea3e3285013c75 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:00 -0500
Subject: [PATCH 3096/3820] New translations pubsubstreams.mdx (Polish)

---
 website/pages/pl/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/pl/substreams/pubsubstreams.mdx

diff --git a/website/pages/pl/substreams/pubsubstreams.mdx b/website/pages/pl/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..3c02d60f9ffd
--- /dev/null
+++ b/website/pages/pl/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Overview
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Prerequisites
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Additional Resources
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 53898e0c3159f45d96f4b9c171ab717c0468a17e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:01 -0500
Subject: [PATCH 3097/3820] New translations tutorial.mdx (Polish)

---
 website/pages/pl/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/pl/sps/tutorial.mdx

diff --git a/website/pages/pl/sps/tutorial.mdx b/website/pages/pl/sps/tutorial.mdx
new file mode 100644
index 000000000000..e5300375d4f8
--- /dev/null
+++ b/website/pages/pl/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Jak zacząć?
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Additional Resources
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 0e07daf4e39a915a51a9715a0b36d388f3c3997c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:02 -0500
Subject: [PATCH 3098/3820] New translations introduction.mdx (Portuguese)

---
 website/pages/pt/sps/introduction.mdx | 30 ++++++++++++++++++---------
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/website/pages/pt/sps/introduction.mdx b/website/pages/pt/sps/introduction.mdx
index 12e3f81c6d53..f7c25a77aa9c 100644
--- a/website/pages/pt/sps/introduction.mdx
+++ b/website/pages/pt/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introudução a Subgraphs Movidos pelo Substreams
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
-There are two methods of enabling this technology:
+## Visão geral
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+### Especificações
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+Há dois metodos de ativar esta tecnologia:
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
+
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
+
+### Outros Recursos
+
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
+
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From d2ad07e65c5e75c878a19895538916c0b9578861 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:03 -0500
Subject: [PATCH 3099/3820] New translations sps-faq.mdx (Portuguese)

---
 website/pages/pt/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/pt/sps/sps-faq.mdx

diff --git a/website/pages/pt/sps/sps-faq.mdx b/website/pages/pt/sps/sps-faq.mdx
new file mode 100644
index 000000000000..88cb1adea92d
--- /dev/null
+++ b/website/pages/pt/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: "Perguntas Frequentes: Subgraphs Movidos pelo Substreams"
+---
+
+## O que são Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## O que são subgraphs movidos por substreams?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## Como subgraphs movidos a Substreams são diferentes de subgraphs?
+
+Os subgraphs são compostos de fontes de dados que especificam eventos on-chain, e como transformar estes eventos através de handlers escritos em AssemblyScript. Estes eventos são processados em sequência, com base na ordem em que acontecem na chain.
+
+Por outro lado, subgraphs movidos a substreams têm uma única fonte de dados que referencia um pacote de substreams, processado pelo Graph Node. Substreams têm acesso a mais dados granulares on-chain em comparação a subgraphs convencionais, e também podem se beneficiar de um processamento paralelizado em massa, o que pode diminuir a espera do processamento.
+
+## Quais os benefícios do uso de subgraphs movidos a Substreams?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## Quais os benefícios do Substreams?
+
+Usar o Substreams incorre muitos benefícios, que incluem:
+
+- Compostável: Você pode empilhar módulos de Substreams como se fossem blocos de LEGO, e construir em cima de módulos da comunidade, para refinar dados públicos.
+
+- Indexação de alto desempenho: Indexação muito mais rápida através de clusters de larga escala de operações paralelas (como o BigQuery).
+
+- Mergulho em qualquer lugar: Mergulhe seus dados onde quiser: PostgreSQL, MongoDB, Kafka, subgraphs, arquivos planos, Google Sheets.
+
+- Programável: Use códigos para personalizar a extração, realizar agregações de tempo de transformação, e modelar o seu resultado para vários sinks.
+
+- Acesso a dados tradicionais que não são disponíveis como parte do RPC em JSON
+
+- Todos os benefícios do Firehose.
+
+## O que é o Firehose?
+
+Desenvolvido pela [StreamingFast](https://www.streamingfast.io/), o Firehose é uma camada de extração de dados em blockchain desenhada do zero para processar o histórico completo de blockchains em velocidades nunca antes vistas. Com uma abordagem baseada em arquivos e que dá prioridade a transmissões, ele é um componente central do conjunto de tecnologias de código aberto da StreamingFast, e a fundação do Substreams.
+
+Confira a [documentação](https://firehose.streamingfast.io/) para aprender mais sobre o Firehose.
+
+## Quais os benefícios do Firehose?
+
+Há muitos benefícios do uso do Firehose, que incluem:
+
+- Latência menor: De forma que prioriza as transmissões, os nodes do Firehouse são desenhados para correrem para revelar os dados do bloco em primeiro lugar.
+
+- Evita downtimes: Desenhado do zero para Alta Disponibilidade.
+
+- Não perde nada: O cursor de transmissões do Firehose é desenhado para lidar com forks e continuar de onde você parou em qualquer condição.
+
+- Modelo rico de dados:  O melhor modelo de dados, que inclui as mudanças de saldo, a árvore de chamadas completa, transações internas, logs, mudanças de armazenamento, custos de gas, e mais.
+
+- Uso de arquivos planos: Dados de blockchain são extraídos em arquivos planos, o recurso de computação mais barato e otimizado disponível.
+
+## Onde programadores podem acessar mais informações sobre Substreams e subgraphs movidos a Substreams?
+
+Para aprender como construir módulos do Substreams, leia a [documentação do Substreams](/substreams/introduction/).
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+A [ferramenta de Codegen no Substreams mais recente](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) permitirá ao programador inicializar um projeto no Substreams sem a necessidade de código.
+
+## Qual é o papel de módulos em Rust no Substreams?
+
+Módulos de Rust são o equivalente aos mapeadores em AssemblyScript em subgraphs. Eles são compilados em WASM de forma parecida, mas o modelo de programação permite execuções paralelas. Eles definem a categoria de transformações e agregações que você quer aplicar aos dados de blockchain crus.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## O que faz o Substreams compostável?
+
+Ao usar o Substreams, a composição é realizada na camada de transformação, permitindo o uso de módulos em cache.
+
+Como exemplo, Fulana pode construir um módulo de preço de DEX, Sicrano pode usá-lo para construir um agregador de volume para alguns tokens do seu interesse, e Beltrana pode combinar quatro módulos de preço de DEX individuais para criar um oráculo de preço. Um único pedido do Substreams empacotará todos estes módulos e os interligará para oferecer uma transmissão de dados muito mais refinada. Aquela transmissão pode então ser usada para popular um subgraph, e ser consultada pelos consumidores.
+
+## Como construir e publicar um Subgraph movido a Substreams?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Onde posso encontrar exemplos de Substreams e subgraphs movidos a Substreams?
+
+Você pode visitar [este repo do Github](https://github.com/pinax-network/awesome-substreams) para encontrar exemplos de Substreams e subgraphs movidos a Substreams.
+
+## O que Substreams e subgraphs movidos a Substreams significam para a Graph Network?
+
+A integração promete vários benefícios, incluindo indexações de altíssimo desempenho e mais composabilidade com o uso de módulos de comunidade e construção por cima deles.

From 0f5991d4be155d544244386e36408d1545d10234 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:04 -0500
Subject: [PATCH 3100/3820] New translations triggers.mdx (Portuguese)

---
 website/pages/pt/sps/triggers.mdx | 30 ++++++++++++++++++++----------
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/website/pages/pt/sps/triggers.mdx b/website/pages/pt/sps/triggers.mdx
index ed19635d4768..ee6321403e5d 100644
--- a/website/pages/pt/sps/triggers.mdx
+++ b/website/pages/pt/sps/triggers.mdx
@@ -1,16 +1,22 @@
 ---
-title: Substreams Triggers
+title: Gatilhos do Substreams
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Visão geral
 
-The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
+
+O código a seguir demonstra como definir uma função `handleTransactions` num handler de subgraph. Esta função recebe bytes brutos do Substreams como um parâmetro e os decodifica num objeto `Transactions`. Uma nova entidade de subgraph é criada para cada transação.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
+
+1. Os bytes contendo dados do Substreams são descodificados no objeto `Transactions` gerado; este é usado como qualquer outro objeto AssemblyScript
+2. Um loop sobre as transações
+3. Uma nova entidade de subgraph é criada para cada transação
+
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
 
-1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
-2. Looping over the transactions
-3. Create a new subgraph entity for every transaction
+### Outros Recursos
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From b385de32556718e9fed32271d01ff1b1f127e4bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:05 -0500
Subject: [PATCH 3101/3820] New translations devcontainer.mdx (Portuguese)

---
 .../pt/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/pt/substreams/developing/devcontainer.mdx

diff --git a/website/pages/pt/substreams/developing/devcontainer.mdx b/website/pages/pt/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..f7e056d95884
--- /dev/null
+++ b/website/pages/pt/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Pré-requisitos
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 54f8d8fb7c3835436ace8511c696012a01c1b11d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:06 -0500
Subject: [PATCH 3102/3820] New translations sinks.mdx (Portuguese)

---
 .../pt/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/pt/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/pt/substreams/developing/sinks/sinks.mdx b/website/pages/pt/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..c5559221e980
--- /dev/null
+++ b/website/pages/pt/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Visão geral
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 487800fa224c448eb7cb1521cbce00c78ccbd4cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:07 -0500
Subject: [PATCH 3103/3820] New translations accountchanges.mdx (Portuguese)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/pt/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/pt/substreams/developing/solana/accountchanges.mdx b/website/pages/pt/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..2ea322a10a7a
--- /dev/null
+++ b/website/pages/pt/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introdução
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Como Começar
+
+### Pré-requisitos
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From f4a5c19e9770e7e4564fa35625b91d306ece3301 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:08 -0500
Subject: [PATCH 3104/3820] New translations transactions.mdx (Portuguese)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/pt/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/pt/substreams/developing/solana/transactions.mdx b/website/pages/pt/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..8032f21a77e0
--- /dev/null
+++ b/website/pages/pt/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Outros Recursos
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From ccefd6b5ba95d82fb34bcfbbdfffecf0971fedaa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:09 -0500
Subject: [PATCH 3105/3820] New translations getting-started-substreams.mdx
 (Portuguese)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/pt/substreams/getting-started-substreams.mdx

diff --git a/website/pages/pt/substreams/getting-started-substreams.mdx b/website/pages/pt/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..cb4e0df5d24d
--- /dev/null
+++ b/website/pages/pt/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Visão geral
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Outros Recursos
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From cabb6e59ee24206c7af98b8cdac7b477dc8fdcf8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:10 -0500
Subject: [PATCH 3106/3820] New translations pubsubstreams.mdx (Portuguese)

---
 website/pages/pt/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/pt/substreams/pubsubstreams.mdx

diff --git a/website/pages/pt/substreams/pubsubstreams.mdx b/website/pages/pt/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..29e485349350
--- /dev/null
+++ b/website/pages/pt/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Visão geral
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Pré-requisitos
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Outros Recursos
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 6a6761e4d0045a1d734f232e6bf878db6ed6fc06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:11 -0500
Subject: [PATCH 3107/3820] New translations tutorial.mdx (Portuguese)

---
 website/pages/pt/sps/tutorial.mdx | 136 ++++++++++++++++++++++++++++++
 1 file changed, 136 insertions(+)
 create mode 100644 website/pages/pt/sps/tutorial.mdx

diff --git a/website/pages/pt/sps/tutorial.mdx b/website/pages/pt/sps/tutorial.mdx
new file mode 100644
index 000000000000..bb6f05f1bb83
--- /dev/null
+++ b/website/pages/pt/sps/tutorial.mdx
@@ -0,0 +1,136 @@
+---
+title: "Tutorial: Como Montar um Subgraph Movido a Substreams na Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Como Começar
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Pré-requisitos
+
+Antes de começar:
+
+- Complete o [Guia de Introdução](https://github.com/streamingfast/substreams-starter) para montar o seu ambiente de programação com um Recipiente de Programação.
+- Familiarize-se com o The Graph e conceitos básicos de blockchain, como transações e Protobufs.
+
+### Passo 1: Inicialize o Seu Projeto
+
+1. Para inicializar o seu projeto, abra o seu Recipiente e execute o seguinte comando:
+
+   ```bash
+   substreams init
+   ```
+
+2. Selecione a opção de projeto "minimal" (mínimo).
+
+3. Troque os conteúdos do arquivo `substreams.yaml` gerado com a seguinte configuração, que filtra transações para a conta do Orca no ID de programa do token da SPL:
+
+```yaml
+params: # Modifique os parâmetros a seu gosto
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Passo 2: Crie o Manifest do Subgraph
+
+Com o projeto inicializado, gere um manifest de subgraph com o seguinte comando no Recipiente de Programação:
+
+```bash
+substreams codegen subgraph
+```
+
+Será gerado um manifest `subgraph.yaml` que importa o pacote do Substreams como uma fonte de dados:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Módulo definido em substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Passo 3: Defina as Entidades em `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+Este schema define uma entidade `MyTransfer` com campos como `id`, `amount`, `source`, `designation`, e `signers`.
+
+### Passo 4: Controle Dados do Substreams no `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Passo 5: Crie Arquivos de Protobuf
+
+Para gerar objetos do Protobuf no AssemblyScript, execute:
+
+```bash
+npm run protogen
+```
+
+Este comando converte as definições do Protobuf em AssemblyScript, permitindo o uso destas no handler do subgraph.
+
+### Conclusão
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Outros Recursos
+
+Para otimizações e personalizações mais avançadas, veja a [documentação oficial do Substreams](https://substreams.streamingfast.io/tutorials/solana).

From 4c19b88c6d1dbe03d31e42e3834aebd2e7fb0538 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:12 -0500
Subject: [PATCH 3108/3820] New translations introduction.mdx (Russian)

---
 website/pages/ru/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/ru/sps/introduction.mdx b/website/pages/ru/sps/introduction.mdx
index 12e3f81c6d53..9082acadcad8 100644
--- a/website/pages/ru/sps/introduction.mdx
+++ b/website/pages/ru/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Обзор
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Специфические особенности
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Дополнительные ресурсы
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From cf1b36c3640eb74013895d8073e7da70f50e7752 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:13 -0500
Subject: [PATCH 3109/3820] New translations sps-faq.mdx (Russian)

---
 website/pages/ru/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/ru/sps/sps-faq.mdx

diff --git a/website/pages/ru/sps/sps-faq.mdx b/website/pages/ru/sps/sps-faq.mdx
new file mode 100644
index 000000000000..d9b93373fc5a
--- /dev/null
+++ b/website/pages/ru/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## Что такое субпотоки?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## Что такое субграфы, работающие на основе Субпотоков?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## Чем субграфы, работающие на основе Субпотоков, отличаются от субграфов?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## Каковы преимущества использования субграфов, работающих на основе Субпотоков?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## В чем преимущества Субпотоков?
+
+Использование Субпотоков имеет много преимуществ, в том числе:
+
+- Компонуемость: Вы можете объединять модули Субпотоков, как блоки LEGO, и опираться на модули сообщества, дополнительно уточняя общедоступные данные.
+
+- Высокопроизводительное индексирование: индексирование на порядки быстрее благодаря крупномасштабным кластерам параллельных операций (как пример, BigQuery).
+
+- Возможность загружать куда угодно: Загружайте Ваши данные в любое удобное для Вас место: PostgreSQL, MongoDB, Kafka, субграфы, плоские файлы, Google Sheets.
+
+- Программируемость: Используйте код для настройки извлечения, выполнения агрегирования во время преобразования и моделирования выходных данных для нескольких приемников.
+
+- Доступ к дополнительным данным, недоступным в составе JSON RPC
+
+- Все преимущества Firehose.
+
+## Что такое Firehose?
+
+Firehose, разработанный [StreamingFast](https://www.streamingfast.io/), представляет собой уровень извлечения данных блокчейна, разработанный с нуля для обработки полной истории блокчейнов на ранее невиданных скоростях. Обеспечивая подход, основанный на файлах и потоковой передаче, он является основным компонентом пакета технологий Streamingfast с открытым исходным кодом и основой для Субпотоков.
+
+Перейдите к [documentation](https://firehose.streamingfast.io/), чтобы узнать больше о Firehose.
+
+## В чем преимущества Firehose?
+
+Использование Firehose имеет много преимуществ, в том числе:
+
+- Наименьшая задержка и отсутствие опроса: В режиме потоковой передачи узлы Firehose спроектированы таким образом, чтобы первыми передавать данные блока.
+
+- Предотвращает простои: Разработан с нуля для обеспечения высокой доступности.
+
+- Никогда не пропустите ни одного момента: Курсор потока Firehose предназначен для обработки форков и продолжения работы с того места, где Вы остановились, в любых условиях.
+
+- Богатейшая модель данных:  Лучшая модель данных, которая включает изменения баланса, полное дерево вызовов, внутренние транзакции, логи, изменения в хранилище, затраты на газ и многое другое.
+
+- Использует плоские файлы: Данные блокчейна извлекаются в плоские файлы — самый дешевый и наиболее оптимизированный доступный вычислительный ресурс.
+
+## Где разработчики могут получить доступ к дополнительной информации о субграфах работающих на основе Субпотоков и о Субпотоках?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+[Новейший инструмент Substreams Codegen](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) позволит Вам загрузить проект Substreams без использования какого-либо кода.
+
+## Какова роль модулей Rust в Субпотоках?
+
+Модули Rust - это эквивалент мапперов AssemblyScript в субграфах. Они компилируются в WASM аналогичным образом, но модель программирования допускает параллельное выполнение. Они определяют, какие преобразования и агрегации необходимо применить к необработанным данным блокчейна.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## Что делает Субпотоки компонуемыми?
+
+При использовании Субпотоков компоновка происходит на уровне преобразования, что позволяет повторно использовать кэшированные модули.
+
+Например, Алиса может создать ценовой модуль DEX, Боб может использовать его для создания агрегатора объемов для некоторых интересующих его токенов, а Лиза может объединить четыре отдельных ценовых модуля DEX, чтобы создать ценовой оракул. Один запрос Субпотоков упакует все эти отдельные модули, свяжет их вместе, чтобы предложить гораздо более уточненный поток данных. Затем этот поток может быть использован для заполнения субграфа и запрашиваться потребителями.
+
+## Как Вы можете создать и развернуть субграф, работающий на основе Субпотоков?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Где я могу найти примеры Субпотоков и субграфов, работающих на основе Субпотоков?
+
+Вы можете посетить [этот репозиторий на Github](https://github.com/pinax-network/awesome-substreams), чтобы найти примеры Субпотоков и субграфов, работающих на основе Субпотоков.
+
+## Что означают Субпотоки и субграфы, работающие на основе Субпотоков, для сети The Graph?
+
+Интеграция обещает множество преимуществ, включая чрезвычайно высокопроизводительную индексацию и большую компонуемость за счет использования модулей сообщества и развития на их основе.

From 4b7fcc56a5b3e616a020e5368f48d4716ef9ea1f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:14 -0500
Subject: [PATCH 3110/3820] New translations triggers.mdx (Russian)

---
 website/pages/ru/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/ru/sps/triggers.mdx b/website/pages/ru/sps/triggers.mdx
index ed19635d4768..3d462a97fb91 100644
--- a/website/pages/ru/sps/triggers.mdx
+++ b/website/pages/ru/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Обзор
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Дополнительные ресурсы
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From fe8ecc8d6c8eaff71c2e9e9a8967f00c5e8a26b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:15 -0500
Subject: [PATCH 3111/3820] New translations devcontainer.mdx (Russian)

---
 .../ru/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/ru/substreams/developing/devcontainer.mdx

diff --git a/website/pages/ru/substreams/developing/devcontainer.mdx b/website/pages/ru/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..578627b34934
--- /dev/null
+++ b/website/pages/ru/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Предварительные требования
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From cae31aa6e8fd08674762a5f6c40bf435a7dd1cf2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:16 -0500
Subject: [PATCH 3112/3820] New translations sinks.mdx (Russian)

---
 .../ru/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/ru/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/ru/substreams/developing/sinks/sinks.mdx b/website/pages/ru/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..7af697cbc237
--- /dev/null
+++ b/website/pages/ru/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Обзор
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From caaac2e96ae4a94dcaec7bfee036d53e43bdc99a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:17 -0500
Subject: [PATCH 3113/3820] New translations accountchanges.mdx (Russian)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/ru/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/ru/substreams/developing/solana/accountchanges.mdx b/website/pages/ru/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..313a09aff573
--- /dev/null
+++ b/website/pages/ru/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introduction
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Начало работы
+
+### Предварительные требования
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From ce54154414696966587a7705f058441e4a011d0a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:18 -0500
Subject: [PATCH 3114/3820] New translations transactions.mdx (Russian)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/ru/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/ru/substreams/developing/solana/transactions.mdx b/website/pages/ru/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..94126d4bf31a
--- /dev/null
+++ b/website/pages/ru/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Дополнительные ресурсы
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 4ba42e386c0a077665c91a19087f15d2da8c4a29 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:19 -0500
Subject: [PATCH 3115/3820] New translations getting-started-substreams.mdx
 (Russian)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/ru/substreams/getting-started-substreams.mdx

diff --git a/website/pages/ru/substreams/getting-started-substreams.mdx b/website/pages/ru/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..61b930e9dae5
--- /dev/null
+++ b/website/pages/ru/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Обзор
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Дополнительные ресурсы
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From cf38c89c035ebd4bab8b4c205b4efc3a4b97b8c6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:20 -0500
Subject: [PATCH 3116/3820] New translations pubsubstreams.mdx (Russian)

---
 website/pages/ru/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ru/substreams/pubsubstreams.mdx

diff --git a/website/pages/ru/substreams/pubsubstreams.mdx b/website/pages/ru/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..12aaa3c1ba40
--- /dev/null
+++ b/website/pages/ru/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Обзор
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Предварительные требования
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Дополнительные ресурсы
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 8f23bf2b985bc711e29b7a310b6496ae592d535e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:21 -0500
Subject: [PATCH 3117/3820] New translations tutorial.mdx (Russian)

---
 website/pages/ru/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/ru/sps/tutorial.mdx

diff --git a/website/pages/ru/sps/tutorial.mdx b/website/pages/ru/sps/tutorial.mdx
new file mode 100644
index 000000000000..765fab57af42
--- /dev/null
+++ b/website/pages/ru/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Начнем
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Предварительные требования
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Заключение
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Дополнительные ресурсы
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 5ccf9cd1e726787bfd4acac72d5b3065652d85cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:22 -0500
Subject: [PATCH 3118/3820] New translations introduction.mdx (Swedish)

---
 website/pages/sv/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/sv/sps/introduction.mdx b/website/pages/sv/sps/introduction.mdx
index 12e3f81c6d53..cddf33d6b2f6 100644
--- a/website/pages/sv/sps/introduction.mdx
+++ b/website/pages/sv/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Översikt
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Ytterligare resurser
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From 9f8b7632e5bd32f714eca285c5ac6c636ce85d0a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:23 -0500
Subject: [PATCH 3119/3820] New translations sps-faq.mdx (Swedish)

---
 website/pages/sv/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/sv/sps/sps-faq.mdx

diff --git a/website/pages/sv/sps/sps-faq.mdx b/website/pages/sv/sps/sps-faq.mdx
new file mode 100644
index 000000000000..525aab4c3e19
--- /dev/null
+++ b/website/pages/sv/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## Vad är Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## Vad är Substreams-drivna subgrafer?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## Hur skiljer sig Substreams-drivna subgrafer från subgrafer?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## Vilka fördelar har användning av Substreams-drivna subgrafer?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## Vilka fördelar har Substreams?
+
+Det finns många fördelar med att använda Substreams, inklusive:
+
+- Sammansättbarhet: Du kan stapla Substreams-moduler som LEGO-block och bygga på gemenskapsmoduler för att ytterligare förädla offentliga data.
+
+- Högpresterande indexering: Ordervärden snabbare indexering genom storskaliga kluster av parallella operationer (tänk BigQuery).
+
+- Utdata var som helst: Du kan sänka dina data var som helst du vill: PostgreSQL, MongoDB, Kafka, subgrafer, platta filer, Google Sheets.
+
+- Programmerbarhet: Använd kod för att anpassa extrahering, utföra transformationsbaserade aggregeringar och modellera din utdata för flera sänkar.
+
+- Tillgång till ytterligare data som inte är tillgänglig som en del av JSON RPC
+
+- Alla fördelar med Firehose.
+
+## Vad är Firehose?
+
+Utvecklat av [StreamingFast](https://www.streamingfast.io/), är Firehose ett blockkedjedata-extraktionslager som är utformat från grunden för att bearbeta blockkedjans fullständiga historik med hastigheter som tidigare inte var skådade. Genom att erbjuda en filbaserad och strömningsorienterad metod är det en kärnkomponent i StreamingFasts svit med öppen källkodstekniker och grunden för Substreams.
+
+Gå till [documentation](https://firehose.streamingfast.io/) för att lära dig mer om Firehose.
+
+## Vilka fördelar har Firehose?
+
+Det finns många fördelar med att använda Firehose, inklusive:
+
+- Lägsta latens och ingen avfrågning: I en strömningsorienterad stil är Firehose-noderna utformade för att snabbt skicka ut blockdata.
+
+- Förebygger driftstopp: Designat från grunden för hög tillgänglighet.
+
+- Missa aldrig en händelse: Firehose-strömmens markör är utformad för att hantera gafflar och att fortsätta där du avslutade under alla förhållanden.
+
+- Rikaste datamodell:  Bästa datamodell som inkluderar balansändringar, hela anropsträdet, interna transaktioner, loggar, lagringsändringar, gasavgifter och mer.
+
+- Använder platta filer: Blockkedjedata extraheras till platta filer, den billigaste och mest optimerade datorkällan som finns tillgänglig.
+
+## Var kan utvecklare få mer information om Substreams-drivna subgrafer och Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## Vad är rollen för Rust-moduler i Substreams?
+
+Rust-moduler är motsvarigheten till AssemblyScript-mappers i subgrafer. De kompileras till WASM på ett liknande sätt, men programmeringsmodellen tillåter parallell körning. De definierar vilken typ av omvandlingar och aggregeringar du vill tillämpa på råblockkedjedata.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## Vad gör Substreams sammansättbart?
+
+Vid användning av Substreams sker sammansättningen på omvandlingsnivån, vilket gör att cachade moduler kan återanvändas.
+
+Som exempel kan Alice bygga en DEX-prismodul, Bob kan använda den för att bygga en volymaggregator för vissa intressanta tokens, och Lisa kan kombinera fyra individuella DEX-prismoduler för att skapa en prisoracle. En enda Substreams-begäran kommer att paketera alla dessa individuella moduler, länka dem samman, för att erbjuda en mycket mer förädlad dataström. Den strömmen kan sedan användas för att fylla i en subgraf och frågas av användare.
+
+## Hur kan man bygga och distribuera en Substreams-drivna subgraf?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Var kan jag hitta exempel på Substreams och Substreams-drivna subgrafer?
+
+Du kan besöka [detta Github-repo](https://github.com/pinax-network/awesome-substreams) för att hitta exempel på Substreams och Substreams-drivna subgrafer.
+
+## Vad innebär Substreams och Substreams-drivna subgrafer för The Graph Network?
+
+Integrationen lovar många fördelar, inklusive extremt högpresterande indexering och ökad sammansättbarhet genom att dra nytta av gemenskapsmoduler och bygga vidare på dem.

From 0b2579f8a3dea0979c168bfe625ffed398dbac7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:24 -0500
Subject: [PATCH 3120/3820] New translations triggers.mdx (Swedish)

---
 website/pages/sv/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/sv/sps/triggers.mdx b/website/pages/sv/sps/triggers.mdx
index ed19635d4768..c3896a0b12a9 100644
--- a/website/pages/sv/sps/triggers.mdx
+++ b/website/pages/sv/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Översikt
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Ytterligare resurser
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From bbb785f5b8ab94d785fb1ced2eee20c817074481 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:25 -0500
Subject: [PATCH 3121/3820] New translations devcontainer.mdx (Swedish)

---
 .../sv/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/sv/substreams/developing/devcontainer.mdx

diff --git a/website/pages/sv/substreams/developing/devcontainer.mdx b/website/pages/sv/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..22bb76d5aa0d
--- /dev/null
+++ b/website/pages/sv/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Förutsättningar
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From fdbb578d900213f39b94762acf22e5d9894f7977 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:26 -0500
Subject: [PATCH 3122/3820] New translations sinks.mdx (Swedish)

---
 .../sv/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/sv/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/sv/substreams/developing/sinks/sinks.mdx b/website/pages/sv/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..4a3524cc10fc
--- /dev/null
+++ b/website/pages/sv/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Översikt
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 8218d0d05faad86c54acc9dca922a541f1beee98 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:27 -0500
Subject: [PATCH 3123/3820] New translations accountchanges.mdx (Swedish)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/sv/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/sv/substreams/developing/solana/accountchanges.mdx b/website/pages/sv/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..11de4db72423
--- /dev/null
+++ b/website/pages/sv/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introduktion
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Komma igång
+
+### Förutsättningar
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 156cf42b0d8226751716e60e6397fc8a434e4a89 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:28 -0500
Subject: [PATCH 3124/3820] New translations transactions.mdx (Swedish)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/sv/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/sv/substreams/developing/solana/transactions.mdx b/website/pages/sv/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..013ccd16d076
--- /dev/null
+++ b/website/pages/sv/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraf
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Ytterligare resurser
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 9a4c1738f90b30a381a6e1ea6bbf6932d0bc4d5f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:29 -0500
Subject: [PATCH 3125/3820] New translations getting-started-substreams.mdx
 (Swedish)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/sv/substreams/getting-started-substreams.mdx

diff --git a/website/pages/sv/substreams/getting-started-substreams.mdx b/website/pages/sv/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..5a27feadbd57
--- /dev/null
+++ b/website/pages/sv/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Översikt
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Ytterligare resurser
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 2b2038d8caaf37414aeb45f10238c8ea5d148fa6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:29 -0500
Subject: [PATCH 3126/3820] New translations pubsubstreams.mdx (Swedish)

---
 website/pages/sv/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/sv/substreams/pubsubstreams.mdx

diff --git a/website/pages/sv/substreams/pubsubstreams.mdx b/website/pages/sv/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..0935260fe683
--- /dev/null
+++ b/website/pages/sv/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Översikt
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Förutsättningar
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Ytterligare resurser
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From b2d1e434ed0a207033ba5a057d29dfdce71c5869 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:30 -0500
Subject: [PATCH 3127/3820] New translations tutorial.mdx (Swedish)

---
 website/pages/sv/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/sv/sps/tutorial.mdx

diff --git a/website/pages/sv/sps/tutorial.mdx b/website/pages/sv/sps/tutorial.mdx
new file mode 100644
index 000000000000..4773330c2d13
--- /dev/null
+++ b/website/pages/sv/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Komma igång
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Förutsättningar
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Ytterligare resurser
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 4d6c4d756e40f2c4828663049e0b3d57ff19ae1e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:31 -0500
Subject: [PATCH 3128/3820] New translations introduction.mdx (Turkish)

---
 website/pages/tr/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/tr/sps/introduction.mdx b/website/pages/tr/sps/introduction.mdx
index 12e3f81c6d53..c899d004a469 100644
--- a/website/pages/tr/sps/introduction.mdx
+++ b/website/pages/tr/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Genel Bakış
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Ayrıntılar
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Ek Kaynaklar
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From a37338c8081d8263f4e08d0f458ff23f7857d692 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:32 -0500
Subject: [PATCH 3129/3820] New translations sps-faq.mdx (Turkish)

---
 website/pages/tr/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/tr/sps/sps-faq.mdx

diff --git a/website/pages/tr/sps/sps-faq.mdx b/website/pages/tr/sps/sps-faq.mdx
new file mode 100644
index 000000000000..8d9c8ac475a5
--- /dev/null
+++ b/website/pages/tr/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## Substreams nedir?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## Substreams destekli subgraphlar nelerdir?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## Substreams destekli subgraphlar'ın normal subgraphlar'dan farkı nedir?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## Substreams destekli subgraphlar kullanmanın avantajları nelerdir?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## Substreams'in faydaları nelerdir?
+
+Substreams kullanmanın birçok faydası vardır, bunlar şunlardır:
+
+- Birleştirilebilir: Substreams modüllerini LEGO blokları gibi birleştirebilir ve topluluk modüllerine dayanarak açık verileri daha da ayrıntılayabilirsiniz.
+
+- Yüksek performanslı indeksleme: Büyük ölçekli paralel işlemler sayesinde sıradan işlemlere göre onlarca kat daha hızlı indeksleme sağlar (BigQuery gibi).
+
+- Her yere veri gönderme: Verilerinizi PostgreSQL, MongoDB, Kafka, subgraphlar, düz dosyalar, Google Sheets gibi herhangi bir yere gönderebilirsiniz.
+
+- Programlanabilir: Kod kullanarak çıkarma işlemlerini özelleştirmek, dönüşüm zamanında toplamalar yapmak ve çıktınızı birden çok hedef için modelleyebilirsiniz.
+
+- JSON RPC'nin parçası olmayan ek verilere erişim sağlar
+
+- Firehose'un tüm faydalarından yararlanır.
+
+## Firehose nedir?
+
+[StreamingFast](https://www.streamingfast.io/) tarafından geliştirilen Firehose, daha önce görülmemiş hızlarda blok zincirinin baştan sona, tam geçmişini işlemek için tasarlanmış bir blok zinciri veri çıkarma katmanıdır. Dosya tabanlı ve akışa odaklı bir yaklaşım sunarak, StreamingFast'in açık kaynaklı teknolojilerinin temel bileşenlerinden biridir ve Substreamler'in temelini oluşturur.
+
+Firehose hakkında daha fazla bilgi için [documentation](https://firehose.streamingfast.io/) gidin.
+
+## Firehose'un faydaları nelerdir?
+
+Firehose kullanmanın birçok faydası vardır, bunlar şunlardır:
+
+- En düşük gecikme ve sorgulama yok: Akışa odaklı bir şekilde, Firehose düğümleri blok verilerini ilk olarak dışarıya göndermek üzere tasarlanmıştır.
+
+- Kesintisiz çalışma: Yüksek Erişilebilirlik için baştan sona tasarlanmıştır.
+
+- Hiçbir şeyi kaçırmaz: Firehose akış imleci, fork durumlarını ele almak ve herhangi bir durumda kaldığınız yerden devam etmek için tasarlanmıştır.
+
+- En zengin veri modeli: Bakiye değişikliklerini, tam çağrı ağacını, dahili işlemleri, kayıtları, depolama değişikliklerini, gaz maliyetlerini ve daha fazlasını içeren en iyi veri modeli.
+
+- Düz dosyalardan yararlanma: Blok zinciri verileri düz dosyalara çıkarılır, en ucuz ve en optimize hesaplama kaynağı kullanılır.
+
+## Geliştiriciler, Substreams destekli subgraphlar ve Substreams hakkında daha fazla bilgiye nereden erişebilir geliştiriciler?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+[En son sürüm Substreams Codegen aracı](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6), hiç kod yazmadan bir Substreams projesi başlatmanıza olanak tanır.
+
+## Rust modüllerinin Substreams içindeki rolü nedir?
+
+Rust modülleri, Subgraphs'teki AssemblyScript eşleştiricilerinin karşılığıdır. WASM'ye benzer şekilde derlenirler, ancak programlama modelleri paralel yürütme için olanak sağlar. Rust modülleri, ham blok zinciri verilerine uygulamak istediğiniz dönüşümleri ve birleştirmeleri tanımlar.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## Substreams'i birleştirilebilir yapan nedir?
+
+Substream kullanırken, kompozisyon dönüşüm katmanında gerçekleşir ve önbelleğe alınmış modüllerin tekrar kullanılmasına olanak sağlar.
+
+Örnek olarak, Alice bir merkeziyetsiz borsa fiyat modülü oluşturabilir, Bob ilgisini çeken bazı tokenler için bir hacim aggregator inşa edebilir ve Lisa dört bireysel merkeziyetsiz borsa fiyat modülünü bir araya getirerek bir fiyat oracle'ı oluşturabilir. Tek bir Substreams talebi, tüm bu bireylerin modüllerini bir araya getirir, birleştirir ve çok daha sofistike bir veri akışı sunar. Bu akış daha sonra bir subgraph'ı doldurmak ve tüketiciler tarafından sorgulanmak için kullanılabilir.
+
+## Bir Substreams destekli Subgraph nasıl oluşturulur ve dağıtılır?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Substreams ve Substreams destekli subgraphlar ile ilgili örnekleri nerede bulubilirim?
+
+Substreams ve Substreams destekli subgraphlar ile ilgili örnekleri bulmak için [bu Github deposunu](https://github.com/pinax-network/awesome-substreams) ziyaret edebilirsiniz.
+
+## Substreams ve Substreams destekli subgraphlar, Graph Ağı için ne anlam ifade etmektedir?
+
+Bu entegrasyon, topluluk modüllerinden yararlanarak son derece yüksek performanslı indeksleme ve daha fazla birleştirme yapma avantajları sunar.

From fcccf2f0712b0cacd7c7b7f90b81c0ebc2dcad4d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:33 -0500
Subject: [PATCH 3130/3820] New translations triggers.mdx (Turkish)

---
 website/pages/tr/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/tr/sps/triggers.mdx b/website/pages/tr/sps/triggers.mdx
index ed19635d4768..f36bac0bf8ea 100644
--- a/website/pages/tr/sps/triggers.mdx
+++ b/website/pages/tr/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Genel Bakış
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Ek Kaynaklar
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 09494e3672a3772a9925b7446fa20188bd189d19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:36 -0500
Subject: [PATCH 3131/3820] New translations devcontainer.mdx (Turkish)

---
 .../tr/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/tr/substreams/developing/devcontainer.mdx

diff --git a/website/pages/tr/substreams/developing/devcontainer.mdx b/website/pages/tr/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..b600994dae5f
--- /dev/null
+++ b/website/pages/tr/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Ön Koşullar
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 6851006a494fd9cb8cd5404117da402a3b1dbcf9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:37 -0500
Subject: [PATCH 3132/3820] New translations sinks.mdx (Turkish)

---
 .../tr/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/tr/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/tr/substreams/developing/sinks/sinks.mdx b/website/pages/tr/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..86ffafd7fa8a
--- /dev/null
+++ b/website/pages/tr/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Genel Bakış
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From c0e5c5f93e84581c9d72a7a13563217b058c5c62 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:38 -0500
Subject: [PATCH 3133/3820] New translations accountchanges.mdx (Turkish)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/tr/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/tr/substreams/developing/solana/accountchanges.mdx b/website/pages/tr/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..a61c51d0500e
--- /dev/null
+++ b/website/pages/tr/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Giriş
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Buradan Başlayın
+
+### Ön Koşullar
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 0f16d125498a9784b9d67190a55cc17ff6ddd457 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:39 -0500
Subject: [PATCH 3134/3820] New translations transactions.mdx (Turkish)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/tr/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/tr/substreams/developing/solana/transactions.mdx b/website/pages/tr/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..362b0358e9a6
--- /dev/null
+++ b/website/pages/tr/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Ek Kaynaklar
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 0fd709b52811b576dcb4805cb980f672e1280602 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:40 -0500
Subject: [PATCH 3135/3820] New translations getting-started-substreams.mdx
 (Turkish)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/tr/substreams/getting-started-substreams.mdx

diff --git a/website/pages/tr/substreams/getting-started-substreams.mdx b/website/pages/tr/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..0e3ce17996df
--- /dev/null
+++ b/website/pages/tr/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Genel Bakış
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Ek Kaynaklar
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From a6b788613b5ae1b1504b711eb4782f755f731dc3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:41 -0500
Subject: [PATCH 3136/3820] New translations pubsubstreams.mdx (Turkish)

---
 website/pages/tr/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/tr/substreams/pubsubstreams.mdx

diff --git a/website/pages/tr/substreams/pubsubstreams.mdx b/website/pages/tr/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..b8ec292004ad
--- /dev/null
+++ b/website/pages/tr/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Genel Bakış
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Ön Koşullar
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Ek Kaynaklar
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 0d671da3b72caa734daf9a8e4f3b0679cbdf8450 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:42 -0500
Subject: [PATCH 3137/3820] New translations tutorial.mdx (Turkish)

---
 website/pages/tr/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/tr/sps/tutorial.mdx

diff --git a/website/pages/tr/sps/tutorial.mdx b/website/pages/tr/sps/tutorial.mdx
new file mode 100644
index 000000000000..e9652491c255
--- /dev/null
+++ b/website/pages/tr/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Başlayalım
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Ön Koşullar
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Ek Kaynaklar
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 2506d39954f188049976ace27b3196441ee3f31d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:43 -0500
Subject: [PATCH 3138/3820] New translations introduction.mdx (Ukrainian)

---
 website/pages/uk/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/uk/sps/introduction.mdx b/website/pages/uk/sps/introduction.mdx
index 12e3f81c6d53..43f6b77fea0b 100644
--- a/website/pages/uk/sps/introduction.mdx
+++ b/website/pages/uk/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Overview
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Додаткові матеріали
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From debd0cc91861fd490a4efe9bbdfa99c6f4985b15 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:44 -0500
Subject: [PATCH 3139/3820] New translations sps-faq.mdx (Ukrainian)

---
 website/pages/uk/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/uk/sps/sps-faq.mdx

diff --git a/website/pages/uk/sps/sps-faq.mdx b/website/pages/uk/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dc99e916ed7a
--- /dev/null
+++ b/website/pages/uk/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From f8133f98d684f5fb56ca76c2c0a556554e255df2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:45 -0500
Subject: [PATCH 3140/3820] New translations triggers.mdx (Ukrainian)

---
 website/pages/uk/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/uk/sps/triggers.mdx b/website/pages/uk/sps/triggers.mdx
index ed19635d4768..761e6ed7ace7 100644
--- a/website/pages/uk/sps/triggers.mdx
+++ b/website/pages/uk/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Overview
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Додаткові матеріали
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 8e1a196ed87fed33b81850878973774ecbdb4ac9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:46 -0500
Subject: [PATCH 3141/3820] New translations devcontainer.mdx (Ukrainian)

---
 .../uk/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/uk/substreams/developing/devcontainer.mdx

diff --git a/website/pages/uk/substreams/developing/devcontainer.mdx b/website/pages/uk/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..83f756d6a072
--- /dev/null
+++ b/website/pages/uk/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Передумови
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 09ce2486cbca2d80b4c30b3da058afb81a1f278c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:47 -0500
Subject: [PATCH 3142/3820] New translations sinks.mdx (Ukrainian)

---
 .../uk/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/uk/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/uk/substreams/developing/sinks/sinks.mdx b/website/pages/uk/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..3f761c18f0a8
--- /dev/null
+++ b/website/pages/uk/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Overview
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 17ce2c9978106178dcda88f5eca7c02f06102a4d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:48 -0500
Subject: [PATCH 3143/3820] New translations accountchanges.mdx (Ukrainian)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/uk/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/uk/substreams/developing/solana/accountchanges.mdx b/website/pages/uk/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..bba78d664db9
--- /dev/null
+++ b/website/pages/uk/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introduction
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Getting Started
+
+### Передумови
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 798cd3f2a266dd16bca5cd102f1cd744ffdb4e6b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:49 -0500
Subject: [PATCH 3144/3820] New translations transactions.mdx (Ukrainian)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/uk/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/uk/substreams/developing/solana/transactions.mdx b/website/pages/uk/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..4e75ac0ca360
--- /dev/null
+++ b/website/pages/uk/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Додаткові матеріали
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From c7c9c4d56998bedb1d7eab57c4bbdb1d76c6195a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:50 -0500
Subject: [PATCH 3145/3820] New translations getting-started-substreams.mdx
 (Ukrainian)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/uk/substreams/getting-started-substreams.mdx

diff --git a/website/pages/uk/substreams/getting-started-substreams.mdx b/website/pages/uk/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..fd326acb288e
--- /dev/null
+++ b/website/pages/uk/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Overview
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Додаткові матеріали
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From b1a7fd7363d9614479350a43329a7715cad1c890 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:51 -0500
Subject: [PATCH 3146/3820] New translations pubsubstreams.mdx (Ukrainian)

---
 website/pages/uk/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/uk/substreams/pubsubstreams.mdx

diff --git a/website/pages/uk/substreams/pubsubstreams.mdx b/website/pages/uk/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..603f4354ba9d
--- /dev/null
+++ b/website/pages/uk/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Overview
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Передумови
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Додаткові матеріали
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 94ab3abc9fcbcea583e94e637146d460608f6249 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:52 -0500
Subject: [PATCH 3147/3820] New translations tutorial.mdx (Ukrainian)

---
 website/pages/uk/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/uk/sps/tutorial.mdx

diff --git a/website/pages/uk/sps/tutorial.mdx b/website/pages/uk/sps/tutorial.mdx
new file mode 100644
index 000000000000..75b22c428bc9
--- /dev/null
+++ b/website/pages/uk/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Розпочати роботу
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Передумови
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Додаткові матеріали
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From ccebfb7f6b4cbb546901a08d8b9f6a603bab1f3e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:53 -0500
Subject: [PATCH 3148/3820] New translations introduction.mdx (Chinese
 Simplified)

---
 website/pages/zh/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/zh/sps/introduction.mdx b/website/pages/zh/sps/introduction.mdx
index 12e3f81c6d53..bfa03da84e41 100644
--- a/website/pages/zh/sps/introduction.mdx
+++ b/website/pages/zh/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## 概述
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### 其他资源
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From 4ac785110dfec0808d47fd040cfab40018c55210 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:54 -0500
Subject: [PATCH 3149/3820] New translations sps-faq.mdx (Chinese Simplified)

---
 website/pages/zh/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/zh/sps/sps-faq.mdx

diff --git a/website/pages/zh/sps/sps-faq.mdx b/website/pages/zh/sps/sps-faq.mdx
new file mode 100644
index 000000000000..1e9132677d36
--- /dev/null
+++ b/website/pages/zh/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## 什么是Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## 什么是基于Substreams的子图？
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## 基于Substreams的子图和普通子图有什么区别？
+
+子图由数据源组成，这些数据源指定了在链上发生的事件以及通过用Assemblyscript编写的处理程序应如何转换这些事件。这些事件按照链上发生事件的顺序依次进行处理。
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## 使用基于Substeams的子图的优势是什么？
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## Substreams的优势是什么？
+
+使用Substreams有许多好处，包括：
+
+- 可组合的: Substreams模块具有可组合性，就像乐高积木一样，您可以将它们堆叠起来，并在社区模块的基础上构建，进一步细化公共数据。
+
+- 高性能索引：大规模并行操作（类似于BigQuery）能够使索引速度提升数个数量级。
+
+- 任意传输：将您的数据传输到您想要的任何地方：PostgreSQL、MongoDB、Kafka、子图、平面文件、Google Sheets等。
+
+- 可编程：使用代码自定义提取、进行转换时聚合，并为多个传输目标建模输出。
+
+- 访问不作为JSON RPC的一部分的附加数据。
+
+- Firehose的全部好处。
+
+## 什么是Firehose?
+
+Firehose是由[StreamingFast](https://www.streamingfast.io/)开发的区块链数据提取层，从零开始设计，以前所未有的速度处理区块链的完整历史。它提供基于文件和流式优先的方法，是StreamingFast开源技术套件的核心组件，也是Substreams的基础。
+
+请访问[documentation](https://firehose.streamingfast.io/)，了解更多关于Firehose的信息。
+
+## Firehose的优势是什么？
+
+使用Firehose有许多好处，包括：
+
+- 最低延迟和无需轮询：Firehose节点以流优先的方式设计，竞相将块数据推送出去。
+
+- 防止宕机：从头开始为高可用性而设计。
+
+- 不会错过任何数据：Firehose流游标设计用于处理分叉，并在任何情况下都可以继续从上次离开的地方开始。
+
+- 最丰富的数据模型：包含余额变化、完整的调用树、内部交易、日志、存储变更、燃气费用等最佳数据模型。
+
+- 利用平面文件：将区块链数据提取到平面文件中，这是目前最便宜、最优化的计算资源。
+
+## 开发人员在哪里可以获得关于Substreams-powered子图和Substreams的更多信息？
+
+[Substreams文档](/substreams/introduction/)将教您如何构建Substreams模块。
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## Rust模块在Substreams中扮演什么角色？
+
+Rust模块相当于子图中的AssemblyScript mappers。它们以类似的方式编译为WASM，但编程模型允许并行执行。它们定义了您想要对原始区块链数据应用的转换和聚合类型。
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## 什么使Substreams具有组合性？
+
+在使用Substreams时，组合发生在转换层，从而使得缓存模块可以被重复使用。
+
+举例来说，Alice可以构建一个DEX价格模块，Bob可以使用它来构建一种感兴趣的代币的交易量聚合器，Lisa可以将四个单独的DEX价格模块组合起来创建一个价格预言机。一个单独的Substreams请求将打包所有这些个人模块，并将它们链接在一起，提供一个更加精细的数据流。然后可以使用该数据流填充子图，并由消费者查询。
+
+## 如何构建和部署Substreams-powered子图？
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## 在哪里可以找到Substreams和Substreams-powered子图的示例？
+
+您可以访问此 [this Github repo](https://github.com/pinax-network/awesome-substreams) 以找到Substreams和Substreams-powered子图的示例。
+
+## Substreams和Substreams-powered子图对于The Graph Network意味着什么？
+
+这种集成带来许多好处，包括通过利用社区模块和在其上构建的组合性来实现极高性能的索引。

From c436922d7a48a6f3c98fede7245493d65f33a574 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:55 -0500
Subject: [PATCH 3150/3820] New translations triggers.mdx (Chinese Simplified)

---
 website/pages/zh/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/zh/sps/triggers.mdx b/website/pages/zh/sps/triggers.mdx
index ed19635d4768..1c4e84de37bf 100644
--- a/website/pages/zh/sps/triggers.mdx
+++ b/website/pages/zh/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## 概述
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### 其他资源
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From fc51c4f5157f7239cf7459b6b9220df6c1e249ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:56 -0500
Subject: [PATCH 3151/3820] New translations devcontainer.mdx (Chinese
 Simplified)

---
 .../zh/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/zh/substreams/developing/devcontainer.mdx

diff --git a/website/pages/zh/substreams/developing/devcontainer.mdx b/website/pages/zh/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..6e91f0478261
--- /dev/null
+++ b/website/pages/zh/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## 先决条件
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 025bf35e91f47aa644af8efa817d6b5abd0920ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:57 -0500
Subject: [PATCH 3152/3820] New translations sinks.mdx (Chinese Simplified)

---
 .../zh/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/zh/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/zh/substreams/developing/sinks/sinks.mdx b/website/pages/zh/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..d5342fca741e
--- /dev/null
+++ b/website/pages/zh/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## 概述
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 4f8c82f1cde39e4e238f6cfdba5f43b83c229b0b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:58 -0500
Subject: [PATCH 3153/3820] New translations accountchanges.mdx (Chinese
 Simplified)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/zh/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/zh/substreams/developing/solana/accountchanges.mdx b/website/pages/zh/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..5c972d0b39cb
--- /dev/null
+++ b/website/pages/zh/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## 介绍
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## 开始
+
+### 先决条件
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From b8e0fa2d4ef38f5ec0891936b87eab8c4c623f98 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:59 -0500
Subject: [PATCH 3154/3820] New translations transactions.mdx (Chinese
 Simplified)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/zh/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/zh/substreams/developing/solana/transactions.mdx b/website/pages/zh/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..5a33fc1db75e
--- /dev/null
+++ b/website/pages/zh/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### 子图
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## 其他资源
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From cea1ac665afc10b7591121ef25c8d57e16bf5572 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:27:59 -0500
Subject: [PATCH 3155/3820] New translations getting-started-substreams.mdx
 (Chinese Simplified)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/zh/substreams/getting-started-substreams.mdx

diff --git a/website/pages/zh/substreams/getting-started-substreams.mdx b/website/pages/zh/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..d5996075d7c8
--- /dev/null
+++ b/website/pages/zh/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## 概述
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## 其他资源
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From fd5226c963256c7c3cfac18459015c626b0d26f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:00 -0500
Subject: [PATCH 3156/3820] New translations pubsubstreams.mdx (Chinese
 Simplified)

---
 website/pages/zh/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/zh/substreams/pubsubstreams.mdx

diff --git a/website/pages/zh/substreams/pubsubstreams.mdx b/website/pages/zh/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..b81e3804ca9d
--- /dev/null
+++ b/website/pages/zh/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## 概述
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### 先决条件
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## 其他资源
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From df4715670d3d6497a9653bb775f96ca3ac2efba7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:01 -0500
Subject: [PATCH 3157/3820] New translations tutorial.mdx (Chinese Simplified)

---
 website/pages/zh/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/zh/sps/tutorial.mdx

diff --git a/website/pages/zh/sps/tutorial.mdx b/website/pages/zh/sps/tutorial.mdx
new file mode 100644
index 000000000000..2d91bedf1046
--- /dev/null
+++ b/website/pages/zh/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## 开始
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### 先决条件
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### 其他资源
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 18e06de5bf849cd867a415f1e8cea41f1ba56953 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:02 -0500
Subject: [PATCH 3158/3820] New translations introduction.mdx (Urdu (Pakistan))

---
 website/pages/ur/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/ur/sps/introduction.mdx b/website/pages/ur/sps/introduction.mdx
index 12e3f81c6d53..e4bef68a6f9b 100644
--- a/website/pages/ur/sps/introduction.mdx
+++ b/website/pages/ur/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## جائزہ
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### اضافی وسائل
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From 90feccee120e1100a8241628401c7f521744196e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:03 -0500
Subject: [PATCH 3159/3820] New translations sps-faq.mdx (Urdu (Pakistan))

---
 website/pages/ur/sps/sps-faq.mdx | 96 ++++++++++++++++++++++++++++++++
 1 file changed, 96 insertions(+)
 create mode 100644 website/pages/ur/sps/sps-faq.mdx

diff --git a/website/pages/ur/sps/sps-faq.mdx b/website/pages/ur/sps/sps-faq.mdx
new file mode 100644
index 000000000000..970756b07cb4
--- /dev/null
+++ b/website/pages/ur/sps/sps-faq.mdx
@@ -0,0 +1,96 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## سب اسٹریمز کیا ہیں؟
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## سب سٹریمز سے چلنے والے سب گرافس کیا ہیں؟
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## سب سٹریمز سے چلنے والے سب گرافس سب گراف سے کیسے مختلف ہیں؟
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## سب سٹریمز سے چلنے والے سب گرافس استعمال کرنے کے کیا فوائد ہیں؟
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## سب سٹریمز کے فوائد کہاں ہیں؟
+
+سب سٹریمز کو استعمال کرنے کے بہت سے فوائد ہیں، بشمول:
+
+- کمپوز ایبل: آپ سب سٹریمز ماڈیولز جیسے LEGO بلاکس کو اسٹیک کر سکتے ہیں، اور عوامی ڈیٹا کو مزید بہتر کرتے ہوئے کمیونٹی ماڈیول بنا سکتے ہیں.
+
+- اعلی کارکردگی کی انڈیکسنگ: متوازی کارروائیوں کے بڑے پیمانے پر کلسٹرز کے ذریعے تیز تر انڈیکسنگ کے آرڈرز (سوچیں BigQuery).
+
+- کہیں بھی سینک: اپنے ڈیٹا کو جہاں چاہیں سینک: PostgreSQL، MongoDB، Kafka، سب گرافس، فلیٹ فائلز، Google Sheets.
+
+- قابل پروگرام: اسے اپنی مرضی کے مطابق بنانے کے لیے کوڈ کریں، دو ٹرانسفارم ٹائم ایگریگیشنز، اور متعدد حواس کے لیے اپنے آؤٹ پٹ کو ماڈل کریں.
+
+- اضافی ڈیٹا تک رسائی جو JSON RPC کے حصے کے طور پر دستیاب نہیں ہے
+
+- Firehose کے تمام فوائد.
+
+## Firehose کیا ہے؟
+
+[StreamingFast](https://www.streamingfast.io/) کے ذریعے تیار کردہ، Firehose ایک بلاکچین ڈیٹا نکالنے کی پرت ہے جسے شروع سے بلاکچینز کی مکمل تاریخ کو اس رفتار سے پروسیس کرنے کے لیے ڈیزائن کیا گیا ہے جو پہلے نظر نہیں آتی تھیں۔ فائلوں پر مبنی اور سٹریمنگ فرسٹ اپروچ فراہم کرنا، یہ سٹریمنگ فاسٹ کے اوپن سورس ٹیکنالوجیز کے سوٹ کا بنیادی جزو اور سب اسٹریمز کی بنیاد ہے.
+
+Firehose کے بارے میں مزید جاننے کے لیے[documentation]
+(https://firehose.streamingfast.io/) پر جائیں.
+
+## Firehose کے کیا فوائد ہیں؟
+
+Firehose استعمال کرنے کے بہت سے فوائد ہیں، بشمول:
+
+- سب سے کم تاخیر اور کوئی پولنگ نہیں: اسٹریمنگ کے پہلے انداز میں، Firehose نوڈس کو پہلے بلاک ڈیٹا کو آگے بڑھانے کی دوڑ کے لیے ڈیزائن کیا گیا ہے.
+
+- ڈاؤن ٹائمز کو روکتا ہے: اعلی دستیابی کے لیے زمین سے ڈیزائن کیا گیا ہے.
+
+- کبھی بھی بیٹ مت چھوڑیں: Firehose سٹریم کرسر کو فورکس ہینڈل کرنے اور کسی بھی حالت میں وہیں سے جاری رکھنے کے لیے بنایا گیا ہے جہاں آپ نے چھوڑا تھا.
+
+- امیرترین ڈیٹا ماڈل: بہترین ڈیٹا ماڈل جس میں بیلنس کی تبدیلیاں، مکمل کال ٹری، اندرونی ٹرانزیکشن، لاگز، اسٹوریج کی تبدیلیاں، گیس کی قیمتیں اور بہت کچھ شامل ہے.
+
+- فلیٹ فائلوں کا فائدہ اٹھاتا ہے: بلاکچین ڈیٹا کو فلیٹ فائلوں میں نکالا جاتا ہے، جو دستیاب سب سے سستا اور بہترین کمپیوٹنگ وسیلہ ہے.
+
+## ڈویلپرز سب سٹریمز سے چلنے والے سب گرافس اور سب سٹریمز کے بارے میں مزید معلومات کہاں تک رسائی حاصل کرسکتے ہیں؟
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## سب سٹریمز میں Rust ماڈیولز کا کیا کردار ہے؟
+
+زنگ ماڈیول سب گراف میں اسمبلی اسکرپٹ میپرز کے مساوی ہیں۔ وہ اسی طرح WASM پر مرتب کیے گئے ہیں، لیکن پروگرامنگ ماڈل متوازی عمل درآمد کی اجازت دیتا ہے۔ وہ اس قسم کی تبدیلیوں اور مجموعوں کی وضاحت کرتے ہیں جسے آپ خام بلاکچین ڈیٹا پر لاگو کرنا چاہتے ہیں.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## سب سٹریمز کو کمپوز ایبل کیا بناتا ہے؟
+
+سب سٹریمز کا استعمال کرتے وقت، کمپوزیشن ٹرانسفارمیشن لیئر پر ہوتی ہے جو کیشڈ ماڈیولز کو دوبارہ استعمال کرنے کے قابل بناتی ہے.
+
+مثال کے طور پر، ایلس DEX پرائس ماڈیول بنا سکتی ہے، باب اپنی دلچسپی کے کچھ ٹوکنز کے لیے حجم ایگریگیٹر بنانے کے لیے اسے استعمال کر سکتا ہے، اور لیزا قیمت اوریکل بنانے کے لیے چار انفرادی DEX قیمت ماڈیول کو جوڑ سکتی ہے۔ ایک واحد سب سٹریمز کی درخواست ان تمام افراد کے ماڈیولز کو پیک کرے گی، ان کو آپس میں جوڑ دے گی، تاکہ ڈیٹا کا بہت زیادہ بہتر سلسلہ پیش کیا جا سکے۔ اس سلسلے کو پھر سب گراف کو آباد کرنے کے لیے استعمال کیا جا سکتا ہے، اور صارفین اس سے کیوریز کر سکتے ہیں.
+
+## آپ سب سٹریمز سے چلنے والے سب گراف کو کیسے بنا اور تعینات کر سکتے ہیں؟
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## مجھے سب سٹریمز اور سب سٹریمز سے چلنے والے سب گرافس کی مثالیں کہاں مل سکتی ہیں؟
+
+آپ سب سٹریمز اور سب سٹریم سے چلنے والے سب گرافس کی مثالیں تلاش کرنے کے لیے [یہ گٹ ہب ریپو](https://github.com/pinax-network/awesome-substreams) ملاحظہ کر سکتے ہیں.
+
+## گراف نیٹ ورک کے لیے سب سٹریمز اور سب سٹریمز سے چلنے والے سب گرافس کا کیا مطلب ہے؟
+
+انضمام بہت سے فوائد کا وعدہ کرتا ہے، بشمول انتہائی اعلی کارکردگی کی انڈیکسنگ اور کمیونٹی ماڈیولز کا فائدہ اٹھا کر اور ان پر تعمیر کرنے کے ذریعے زیادہ کمپوز ایبلٹی.

From 3f3cf6d1a6b0534b14cc38b9bd13c5148a1ce5b9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:04 -0500
Subject: [PATCH 3160/3820] New translations triggers.mdx (Urdu (Pakistan))

---
 website/pages/ur/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/ur/sps/triggers.mdx b/website/pages/ur/sps/triggers.mdx
index ed19635d4768..be4878bf532a 100644
--- a/website/pages/ur/sps/triggers.mdx
+++ b/website/pages/ur/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## جائزہ
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### اضافی وسائل
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From eb5bc51554f19e34844ad9dd5db876d460f755a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:06 -0500
Subject: [PATCH 3161/3820] New translations devcontainer.mdx (Urdu (Pakistan))

---
 .../ur/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/ur/substreams/developing/devcontainer.mdx

diff --git a/website/pages/ur/substreams/developing/devcontainer.mdx b/website/pages/ur/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..18906ee8ecdc
--- /dev/null
+++ b/website/pages/ur/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## اولین ضروریات
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 3e1d2c024681f166a529e3b2b1f44170315c6bc1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:07 -0500
Subject: [PATCH 3162/3820] New translations sinks.mdx (Urdu (Pakistan))

---
 .../ur/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/ur/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/ur/substreams/developing/sinks/sinks.mdx b/website/pages/ur/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..55c1894d242a
--- /dev/null
+++ b/website/pages/ur/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## جائزہ
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 88c2306cc1384752b0a6fc2f16d57723c44843ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:08 -0500
Subject: [PATCH 3163/3820] New translations accountchanges.mdx (Urdu
 (Pakistan))

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/ur/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/ur/substreams/developing/solana/accountchanges.mdx b/website/pages/ur/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..b670f5a592b1
--- /dev/null
+++ b/website/pages/ur/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## تعارف
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## شروع ہوا چاہتا ہے
+
+### اولین ضروریات
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 3649a464802538cebb2068f1ca8da4e30e712627 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:09 -0500
Subject: [PATCH 3164/3820] New translations transactions.mdx (Urdu (Pakistan))

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/ur/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/ur/substreams/developing/solana/transactions.mdx b/website/pages/ur/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..2b0ce6966d0c
--- /dev/null
+++ b/website/pages/ur/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### سب گراف
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## اضافی وسائل
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 1762c56545a9bf1d04d7ce4dd6fbc0f90288bb35 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:10 -0500
Subject: [PATCH 3165/3820] New translations getting-started-substreams.mdx
 (Urdu (Pakistan))

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/ur/substreams/getting-started-substreams.mdx

diff --git a/website/pages/ur/substreams/getting-started-substreams.mdx b/website/pages/ur/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..02e877f50563
--- /dev/null
+++ b/website/pages/ur/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## جائزہ
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## اضافی وسائل
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 5c9fea2fe0005709ec8aacbf84da2d8f253a79d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:11 -0500
Subject: [PATCH 3166/3820] New translations pubsubstreams.mdx (Urdu
 (Pakistan))

---
 website/pages/ur/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/ur/substreams/pubsubstreams.mdx

diff --git a/website/pages/ur/substreams/pubsubstreams.mdx b/website/pages/ur/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..5a7d64a8d141
--- /dev/null
+++ b/website/pages/ur/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## جائزہ
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### اولین ضروریات
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## اضافی وسائل
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From be635cbf764e3a0584869b27a0a701a8fceac83e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:12 -0500
Subject: [PATCH 3167/3820] New translations tutorial.mdx (Urdu (Pakistan))

---
 website/pages/ur/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/ur/sps/tutorial.mdx

diff --git a/website/pages/ur/sps/tutorial.mdx b/website/pages/ur/sps/tutorial.mdx
new file mode 100644
index 000000000000..2973b857e891
--- /dev/null
+++ b/website/pages/ur/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## شروع کریں
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### اولین ضروریات
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### اضافی وسائل
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From ac4b7330b9dc832e93e15f8ad0e3a5d1a5e23ec7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:13 -0500
Subject: [PATCH 3168/3820] New translations introduction.mdx (Vietnamese)

---
 website/pages/vi/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/vi/sps/introduction.mdx b/website/pages/vi/sps/introduction.mdx
index 12e3f81c6d53..aae378c1097c 100644
--- a/website/pages/vi/sps/introduction.mdx
+++ b/website/pages/vi/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Tổng quan
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Additional Resources
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From 4530e1f93ede618f104da8b07ac5494a115d24f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:13 -0500
Subject: [PATCH 3169/3820] New translations sps-faq.mdx (Vietnamese)

---
 website/pages/vi/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/vi/sps/sps-faq.mdx

diff --git a/website/pages/vi/sps/sps-faq.mdx b/website/pages/vi/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dc99e916ed7a
--- /dev/null
+++ b/website/pages/vi/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 46c4349662d6bd192c2700e36240450305890d61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:14 -0500
Subject: [PATCH 3170/3820] New translations triggers.mdx (Vietnamese)

---
 website/pages/vi/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/vi/sps/triggers.mdx b/website/pages/vi/sps/triggers.mdx
index ed19635d4768..a99caed7572b 100644
--- a/website/pages/vi/sps/triggers.mdx
+++ b/website/pages/vi/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Tổng quan
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Additional Resources
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 6ab44cfd709f880710a1fee2c625c8acff7399dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:15 -0500
Subject: [PATCH 3171/3820] New translations devcontainer.mdx (Vietnamese)

---
 .../vi/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/vi/substreams/developing/devcontainer.mdx

diff --git a/website/pages/vi/substreams/developing/devcontainer.mdx b/website/pages/vi/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..8b74ed7a23ac
--- /dev/null
+++ b/website/pages/vi/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Điều kiện tiên quyết
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 4a7ede8c4439bf803b845a141cb0c5a12c825f54 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:16 -0500
Subject: [PATCH 3172/3820] New translations sinks.mdx (Vietnamese)

---
 .../vi/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/vi/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/vi/substreams/developing/sinks/sinks.mdx b/website/pages/vi/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..996c45d657fc
--- /dev/null
+++ b/website/pages/vi/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Tổng quan
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 06ab734cba2a86ae60bbc651c52d180317a1071e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:17 -0500
Subject: [PATCH 3173/3820] New translations accountchanges.mdx (Vietnamese)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/vi/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/vi/substreams/developing/solana/accountchanges.mdx b/website/pages/vi/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..0f0900f6c462
--- /dev/null
+++ b/website/pages/vi/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Giới thiệu
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Getting Started
+
+### Điều kiện tiên quyết
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 53e0b0abcf6058122208193bf47354d339150c43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:18 -0500
Subject: [PATCH 3174/3820] New translations transactions.mdx (Vietnamese)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/vi/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/vi/substreams/developing/solana/transactions.mdx b/website/pages/vi/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..8e5d7c35d4e7
--- /dev/null
+++ b/website/pages/vi/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Additional Resources
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From e42d67447564ed365ed409d25d884bb51ad4ceb9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:19 -0500
Subject: [PATCH 3175/3820] New translations getting-started-substreams.mdx
 (Vietnamese)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/vi/substreams/getting-started-substreams.mdx

diff --git a/website/pages/vi/substreams/getting-started-substreams.mdx b/website/pages/vi/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..a5fb1c0959dc
--- /dev/null
+++ b/website/pages/vi/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Tổng quan
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Additional Resources
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From e42cc60d0e2dae0336a6d5ee05ab7e5a90a526c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:20 -0500
Subject: [PATCH 3176/3820] New translations pubsubstreams.mdx (Vietnamese)

---
 website/pages/vi/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/vi/substreams/pubsubstreams.mdx

diff --git a/website/pages/vi/substreams/pubsubstreams.mdx b/website/pages/vi/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..b73c656b53f3
--- /dev/null
+++ b/website/pages/vi/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Tổng quan
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Điều kiện tiên quyết
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Additional Resources
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 34595109fa36b99f7067632330f026a9380a96e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:21 -0500
Subject: [PATCH 3177/3820] New translations tutorial.mdx (Vietnamese)

---
 website/pages/vi/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/vi/sps/tutorial.mdx

diff --git a/website/pages/vi/sps/tutorial.mdx b/website/pages/vi/sps/tutorial.mdx
new file mode 100644
index 000000000000..0b44abfa1a9b
--- /dev/null
+++ b/website/pages/vi/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Bắt đầu
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Điều kiện tiên quyết
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Additional Resources
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 579bb9dd78a3917fc093f5afbdc6435902d08447 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:24 -0500
Subject: [PATCH 3178/3820] New translations introduction.mdx (Marathi)

---
 website/pages/mr/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/mr/sps/introduction.mdx b/website/pages/mr/sps/introduction.mdx
index 12e3f81c6d53..3b1c9984591d 100644
--- a/website/pages/mr/sps/introduction.mdx
+++ b/website/pages/mr/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## सविश्लेषण
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### अतिरिक्त संसाधने
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From 3dd043ce31945456a2b04f270d621b600f57c0a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:25 -0500
Subject: [PATCH 3179/3820] New translations sps-faq.mdx (Marathi)

---
 website/pages/mr/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/mr/sps/sps-faq.mdx

diff --git a/website/pages/mr/sps/sps-faq.mdx b/website/pages/mr/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dc99e916ed7a
--- /dev/null
+++ b/website/pages/mr/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From a0a2b417e53a8207d5219dd51ffd53cc1fa6d6f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:26 -0500
Subject: [PATCH 3180/3820] New translations triggers.mdx (Marathi)

---
 website/pages/mr/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/mr/sps/triggers.mdx b/website/pages/mr/sps/triggers.mdx
index ed19635d4768..710fa3e462d1 100644
--- a/website/pages/mr/sps/triggers.mdx
+++ b/website/pages/mr/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## सविश्लेषण
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### अतिरिक्त संसाधने
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 1c79dda0a432b90deee5d41f73f995d34382cd00 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:27 -0500
Subject: [PATCH 3181/3820] New translations devcontainer.mdx (Marathi)

---
 .../mr/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/mr/substreams/developing/devcontainer.mdx

diff --git a/website/pages/mr/substreams/developing/devcontainer.mdx b/website/pages/mr/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..d96285ea2b16
--- /dev/null
+++ b/website/pages/mr/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## पूर्वतयारी
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From 55794655a6cc7b03e1c404dd9f9cbc0849f34daa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:28 -0500
Subject: [PATCH 3182/3820] New translations sinks.mdx (Marathi)

---
 .../mr/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/mr/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/mr/substreams/developing/sinks/sinks.mdx b/website/pages/mr/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..f4cb92de409b
--- /dev/null
+++ b/website/pages/mr/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## सविश्लेषण
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 5132432ed9638dde7ccd0358117209e0ecb8a7a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:29 -0500
Subject: [PATCH 3183/3820] New translations accountchanges.mdx (Marathi)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/mr/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/mr/substreams/developing/solana/accountchanges.mdx b/website/pages/mr/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..3e318c081e70
--- /dev/null
+++ b/website/pages/mr/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introduction
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## प्रारंभ करणे
+
+### पूर्वतयारी
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From e8a70c67f5aec48bf1bc11ede0e85e96ec538640 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:30 -0500
Subject: [PATCH 3184/3820] New translations transactions.mdx (Marathi)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/mr/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/mr/substreams/developing/solana/transactions.mdx b/website/pages/mr/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..be277b949142
--- /dev/null
+++ b/website/pages/mr/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### सबग्राफ
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## अतिरिक्त संसाधने
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From bf5dd7343feed7fe7072d02924c1b0bf464795f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:30 -0500
Subject: [PATCH 3185/3820] New translations getting-started-substreams.mdx
 (Marathi)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/mr/substreams/getting-started-substreams.mdx

diff --git a/website/pages/mr/substreams/getting-started-substreams.mdx b/website/pages/mr/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..d2da98eb0e2b
--- /dev/null
+++ b/website/pages/mr/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## सविश्लेषण
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## अतिरिक्त संसाधने
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From 000f49a92cc2bed6818fe781c76596c58af222bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:31 -0500
Subject: [PATCH 3186/3820] New translations pubsubstreams.mdx (Marathi)

---
 website/pages/mr/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/mr/substreams/pubsubstreams.mdx

diff --git a/website/pages/mr/substreams/pubsubstreams.mdx b/website/pages/mr/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..8bb8738e0470
--- /dev/null
+++ b/website/pages/mr/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## सविश्लेषण
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### पूर्वतयारी
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## अतिरिक्त संसाधने
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 98ab5952f50995b301ac46b9f09c36d6728320f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:32 -0500
Subject: [PATCH 3187/3820] New translations tutorial.mdx (Marathi)

---
 website/pages/mr/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/mr/sps/tutorial.mdx

diff --git a/website/pages/mr/sps/tutorial.mdx b/website/pages/mr/sps/tutorial.mdx
new file mode 100644
index 000000000000..15993807a96f
--- /dev/null
+++ b/website/pages/mr/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## सुरु करूया
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### पूर्वतयारी
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### अतिरिक्त संसाधने
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 5711dc9f0579d7abcf36c572ce86fcd6b6e99951 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:33 -0500
Subject: [PATCH 3188/3820] New translations introduction.mdx (Hindi)

---
 website/pages/hi/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/hi/sps/introduction.mdx b/website/pages/hi/sps/introduction.mdx
index d2e1f0179d40..3b13147fe447 100644
--- a/website/pages/hi/sps/introduction.mdx
+++ b/website/pages/hi/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Substreams-संचालित Subgraphs का परिचय
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Substreams पैकेज (.spkg) का उपयोग करके, आपका subgraph पूर्व-सूचीबद्ध ब्लॉकचेन डेटा के एक स्ट्रीम तक पहुंच प्राप्त करता है। यह विशेष रूप से बड़े या जटिल ब्लॉकचेन नेटवर्क के साथ डेटा हैंडलिंग को अधिक कुशल और स्केलेबल बनाता है।
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## अवलोकन
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### विशिष्टताएँ
 
 इस तकनीक को सक्षम करने के दो तरीके हैं:
 
-Using Substreams triggers(./triggers): किसी भी Substreams मॉड्यूल से उपभोग करें, Protobuf मॉडल को एक subgraph हैंडलर के माध्यम से आयात करके और सभी लॉजिक को एक subgraph में स्थानांतरित करें। यह विधि subgraph संस्थाओं को सीधे subgraph में बनाती है।
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Entity Changes (https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out) का उपयोग करके: Substreams में अधिक लॉजिक लिखने से, आप सीधे graph-node में मॉड्यूल का आउटपुट प्राप्त कर सकते हैं। graph-node में, आप Substreams डेटा का उपयोग करके अपने उपग्रह संस्थाएं बना सकते हैं।
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-यह वास्तव में इस पर निर्भर करता है कि आप अपनी लॉजिक को कहाँ रखते हैं, subgraph या Substreams में। ध्यान रखें कि यदि आपकी लॉजिक अधिकतर Substreams में है, तो इससे एक पैरेललाइज़्ड मॉडल का लाभ मिलता है, जबकि ट्रिगर्स graph-node में लाइनर रूप से उपभोग किए जाएंगे।
+### Additional Resources
 
-नीचे दिए गए लिंक पर जाएं How-To गाइड्स के लिए जो आपको कोड-जनरेशन टूलिंग का उपयोग करके अपना पहला एंड-टू-एंड प्रोजेक्ट तेजी से बनाने में मदद करेंगे:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From aa3b8c7b0f815e0ae7ed9c912203c2032c5f107f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:34 -0500
Subject: [PATCH 3189/3820] New translations sps-faq.mdx (Hindi)

---
 website/pages/hi/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/hi/sps/sps-faq.mdx

diff --git a/website/pages/hi/sps/sps-faq.mdx b/website/pages/hi/sps/sps-faq.mdx
new file mode 100644
index 000000000000..3f9158706485
--- /dev/null
+++ b/website/pages/hi/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+[नवीनतम Substreams Codegen टूल](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) आपको बिना किसी कोड के एक Substreams प्रोजेक्ट शुरू करने की अनुमति देगा।
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From ecce0e6ff146cea30868d2c377c01f1306783a1b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:35 -0500
Subject: [PATCH 3190/3820] New translations triggers.mdx (Hindi)

---
 website/pages/hi/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/hi/sps/triggers.mdx b/website/pages/hi/sps/triggers.mdx
index 2d5a8db77b60..0577a495f11a 100644
--- a/website/pages/hi/sps/triggers.mdx
+++ b/website/pages/hi/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: सबस्ट्रीम्स ट्रिगर्स
 ---
 
-कस्टम ट्रिगर्स आपको अपने subgraph मैपिंग फ़ाइल और इकाइयों (टेबल और फ़ील्ड के समान) में डेटा सीधे भेजने की अनुमति देते हैं, जो GraphQL परत का पूरा उपयोग करने में सक्षम बनाते हैं। अपने Substreams मॉड्यूल द्वारा उत्पन्न Protobuf परिभाषाओं को आयात करके, आप अपने subgraph के हैंडलर के भीतर इस डेटा को प्राप्त और प्रोसेस कर सकते हैं, जो subgraph ढांचे के भीतर कुशल और सुव्यवस्थित डेटा प्रबंधन सुनिश्चित करता है।
+Use Custom Triggers and enable the full use GraphQL.
 
-> नोट: यदि आपने पहले से ऐसा नहीं किया है, तो अपने पहले प्रोजेक्ट को Development Container में स्कैफोल्ड करने के लिए यहाँ (./introduction) पाए जाने वाले How-To Guides में से एक पर जाएं।
+## अवलोकन
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 निम्नलिखित कोड यह दर्शाता है कि कैसे एक handleTransactions फ़ंक्शन को एक subgraph हैंडलर में परिभाषित किया जा सकता है। यह फ़ंक्शन कच्चे Substreams बाइट्स को एक पैरामीटर के रूप में प्राप्त करता है और उन्हें एक Transactions ऑब्जेक्ट में डिकोड करता है। प्रत्येक लेनदेन के लिए, एक नई subgraph एंटिटी बनाई जाती है।
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-यहां वह है जो आप mappings.ts फ़ाइल में देख रहे हैं:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. Substreams डेटा को जनरेट किए गए Transactions ऑब्जेक्ट में डिकोड किया जाता है, यह ऑब्जेक्ट किसी अन्य AssemblyScript ऑब्जेक्ट की तरह उपयोग किया जाता है।
 2. लेनदेन पर लूप करना
 3. प्रत्येक लेनदेन के लिए एक नया subgraph entity बनाएं
 
-ड्रैगर-आधारित एक उपग्राफ के विस्तृत उदाहरण के लिए, यहां क्लिक करें(./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Additional Resources
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From 5bd276a0a157337a979e78b125fe9b8fb62014e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:36 -0500
Subject: [PATCH 3191/3820] New translations devcontainer.mdx (Hindi)

---
 .../hi/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/hi/substreams/developing/devcontainer.mdx

diff --git a/website/pages/hi/substreams/developing/devcontainer.mdx b/website/pages/hi/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..750ab6df0ce9
--- /dev/null
+++ b/website/pages/hi/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## आवश्यक शर्तें
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From e5134b294b4b4dc5745a96276f9eccac61fae61c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:37 -0500
Subject: [PATCH 3192/3820] New translations sinks.mdx (Hindi)

---
 .../hi/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/hi/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/hi/substreams/developing/sinks/sinks.mdx b/website/pages/hi/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..60248ced58fa
--- /dev/null
+++ b/website/pages/hi/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## अवलोकन
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From 77fac42f555bf7828d10ff39d3212df58f1b5abb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:38 -0500
Subject: [PATCH 3193/3820] New translations accountchanges.mdx (Hindi)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/hi/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/hi/substreams/developing/solana/accountchanges.mdx b/website/pages/hi/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..170705a5a96b
--- /dev/null
+++ b/website/pages/hi/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introduction
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## शुरू करना
+
+### आवश्यक शर्तें
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From 43c5a72de90e9b4f91571520787f971393e8c1a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:39 -0500
Subject: [PATCH 3194/3820] New translations transactions.mdx (Hindi)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/hi/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/hi/substreams/developing/solana/transactions.mdx b/website/pages/hi/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..0900e409f9af
--- /dev/null
+++ b/website/pages/hi/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### सबग्राफ
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Additional Resources
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From 9fb6170a89563b9167ca937a96639cd9338aa2d6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:40 -0500
Subject: [PATCH 3195/3820] New translations getting-started-substreams.mdx
 (Hindi)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/hi/substreams/getting-started-substreams.mdx

diff --git a/website/pages/hi/substreams/getting-started-substreams.mdx b/website/pages/hi/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..f18132825fc8
--- /dev/null
+++ b/website/pages/hi/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## अवलोकन
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Additional Resources
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From d754fc01f5ff5a75b59a1c572f01f5ef2f3cfdfe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:41 -0500
Subject: [PATCH 3196/3820] New translations pubsubstreams.mdx (Hindi)

---
 website/pages/hi/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/hi/substreams/pubsubstreams.mdx

diff --git a/website/pages/hi/substreams/pubsubstreams.mdx b/website/pages/hi/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..f17dd1cbefd2
--- /dev/null
+++ b/website/pages/hi/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## अवलोकन
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### आवश्यक शर्तें
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Additional Resources
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From 96cbda006f6a6befe710c66f180b3ed76a0b51ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:42 -0500
Subject: [PATCH 3197/3820] New translations tutorial.mdx (Hindi)

---
 website/pages/hi/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/hi/sps/tutorial.mdx

diff --git a/website/pages/hi/sps/tutorial.mdx b/website/pages/hi/sps/tutorial.mdx
new file mode 100644
index 000000000000..0f01c720c7e9
--- /dev/null
+++ b/website/pages/hi/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "ट्यूटोरियल: Solana पर एक Substreams-शक्ति वाले Subgraph सेट करें"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Get Started
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### आवश्यक शर्तें
+
+'शुरू करने से पहले, सुनिश्चित करें कि:'
+
+- अपने विकास पर्यावरण को सेट अप करने के लिए Getting Started Guide(https://github.com/streamingfast/substreams-starter) को पूरा करें, एक Dev Container का उपयोग करके।
+- The Graph और मूल ब्लॉकचेन अवधारणाओं जैसे कि लेनदेन और Protobufs से परिचित रहें।
+
+### चरण 1: अपने प्रोजेक्ट को प्रारंभ करें
+
+1. अपने Dev Container को खोलें और अपने प्रोजेक्ट को शुरू करने के लिए निम्नलिखित कमांड चलाएं:
+
+   ```bash
+   substreams प्रारंभ करें
+   ```
+
+2. "Minimal" प्रोजेक्ट विकल्प चुनें।
+
+3. substreams.yaml फ़ाइल की सामग्री को निम्नलिखित कॉन्फ़िगरेशन से बदलें, जो SPL टोकन प्रोग्राम आईडी पर Orca अकाउंट के लेनदेन को फ़िल्टर करता है:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### चरण 2: Subgraph Manifest उत्पन्न करें
+
+एक बार जब प्रोजेक्ट इनिशियलाइज़ हो जाए, Dev Container में निम्नलिखित कमांड चलाकर subgraph मैनिफेस्ट जेनरेट करें: 
+
+```bash
+'सबस्ट्रीम्स कोडजेन' subgraph
+```
+
+आप subgraph.yaml मैनिफेस्ट बनाएंगे जो डेटा स्रोत के रूप में Substreams पैकेज को इम्पोर्ट करता है:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### चरण 3: schema.graphql में संस्थाएँ परिभाषित करें
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+यह स्कीमा एक MyTransfer एंटिटी को परिभाषित करता है जिसमें फ़ील्ड्स जैसे कि id, amount, source, designation, और signers शामिल हैं।
+
+### चरण 4: mappings.ts में Substreams डेटा को संभालें
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### चरण 5: Protobuf फ़ाइलें उत्पन्न करें
+
+AssemblyScript में Protobuf ऑब्जेक्ट बनाने के लिए, निम्नलिखित कमांड चलाएँ:
+
+```bash
+npm चलाएँ protogen
+```
+
+यह कमांड Protobuf परिभाषाओं को AssemblyScript में परिवर्तित करता है, जिससे आप उन्हें हैंडलर में उपयोग कर सकते हैं।
+
+### निष्कर्ष
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Additional Resources
+
+अधिक उन्नत अनुकूलन और ऑप्टिमाइजेशन के लिए, आधिकारिक Substreams documentation(https://substreams.streamingfast.io/tutorials/solana) देखें।

From 45f0ac8f108d758c8e474b27395f35bd22f0186f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:43 -0500
Subject: [PATCH 3198/3820] New translations introduction.mdx (Swahili)

---
 website/pages/sw/sps/introduction.mdx | 28 ++++++++++++++++++---------
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/website/pages/sw/sps/introduction.mdx b/website/pages/sw/sps/introduction.mdx
index 12e3f81c6d53..aa44f605ce65 100644
--- a/website/pages/sw/sps/introduction.mdx
+++ b/website/pages/sw/sps/introduction.mdx
@@ -1,19 +1,29 @@
 ---
-title: Introduction to Substreams-powered Subgraphs
+title: Introduction to Substreams-Powered Subgraphs
 ---
 
-By using a Substreams package (`.spkg`) as a data source, your subgraph gains access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+
+## Overview
+
+Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+
+### Specifics
 
 There are two methods of enabling this technology:
 
-Using Substreams [triggers](./triggers): Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
+
+2. **Using [Entity Changes](https://docs.substreams.dev/how-to-guides/sinks/subgraph/graph-out)**: By writing more of the logic into Substreams, you can consume the module's output directly into [graph-node](/indexing/tooling/graph-node/). In graph-node, you can use the Substreams data to create your subgraph entities.
 
-Using [Entity Changes](https://substreams.streamingfast.io/documentation/consume/subgraph/graph-out): By writing more of the logic into Substreams, you can consume the module's output directly into graph-node. In graph-node, you can use the Substreams data to create your subgraph entities.
+You can choose where to place your logic, either in the subgraph or Substreams. However, consider what aligns with your data needs, as Substreams has a parallelized model, and triggers are consumed linearly in the graph node.
 
-It is really a matter of where you put your logic, in the subgraph or the Substreams. Keep in mind that having more of your logic in Substreams benefits from a parallelized model, whereas triggers will be linearly consumed in graph-node.
+### Additional Resources
 
-Visit the following links for How-To Guides on using code-generation tooling to build your first end-to-end project quickly:
+Visit the following links for tutorials on using code-generation tooling to build your first end-to-end Substreams project quickly:
 
-- [Solana](https://substreams.streamingfast.io/documentation/how-to-guides/solana)
-- [EVM](https://substreams.streamingfast.io/documentation/how-to-guides/evm)
-- [Injective](https://substreams.streamingfast.io/documentation/how-to-guides/injective)
+- [Solana](/substreams/developing/solana/transactions/)
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)

From db6f6f7e44ed56f6c49cda236d3d500aec366e75 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:44 -0500
Subject: [PATCH 3199/3820] New translations sps-faq.mdx (Swahili)

---
 website/pages/sw/sps/sps-faq.mdx | 95 ++++++++++++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 website/pages/sw/sps/sps-faq.mdx

diff --git a/website/pages/sw/sps/sps-faq.mdx b/website/pages/sw/sps/sps-faq.mdx
new file mode 100644
index 000000000000..dc99e916ed7a
--- /dev/null
+++ b/website/pages/sw/sps/sps-faq.mdx
@@ -0,0 +1,95 @@
+---
+title: Substreams-Powered Subgraphs FAQ
+---
+
+## What are Substreams?
+
+Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
+
+Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engine that serves as a blockchain data transformation layer. It's powered by [Firehose](https://firehose.streamingfast.io/), and enables developers to write Rust modules, build upon community modules, provide extremely high-performance indexing, and [sink](/substreams/developing/sinks/sinks/) their data anywhere.
+
+Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
+
+## What are Substreams-powered subgraphs?
+
+[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+
+If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
+
+## How are Substreams-powered subgraphs different from subgraphs?
+
+Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+
+By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+
+## What are the benefits of using Substreams-powered subgraphs?
+
+Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
+
+## What are the benefits of Substreams?
+
+There are many benefits to using Substreams, including:
+
+- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+
+- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+
+- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+
+- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+
+- Access to additional data which is not available as part of the JSON RPC
+
+- All the benefits of the Firehose.
+
+## What is the Firehose?
+
+Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+
+Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+
+## What are the benefits of the Firehose?
+
+There are many benefits to using Firehose, including:
+
+- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+
+- Prevents downtimes: Designed from the ground up for High Availability.
+
+- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+
+- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+
+- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+
+## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+
+The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+
+The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+
+The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+
+## What is the role of Rust modules in Substreams?
+
+Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+
+See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
+
+## What makes Substreams composable?
+
+When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+
+As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+
+## How can you build and deploy a Substreams-powered Subgraph?
+
+After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
+
+## Where can I find examples of Substreams and Substreams-powered subgraphs?
+
+You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+
+## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 25c4c66c771b958dc1b01c7e25f2ad7062d4475f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:45 -0500
Subject: [PATCH 3200/3820] New translations triggers.mdx (Swahili)

---
 website/pages/sw/sps/triggers.mdx | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/website/pages/sw/sps/triggers.mdx b/website/pages/sw/sps/triggers.mdx
index ed19635d4768..b346119555c1 100644
--- a/website/pages/sw/sps/triggers.mdx
+++ b/website/pages/sw/sps/triggers.mdx
@@ -2,15 +2,21 @@
 title: Substreams Triggers
 ---
 
-Custom triggers allow you to send data directly into your subgraph mappings file and entities (similar to tables and fields), enabling full use of the GraphQL layer. By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data within your subgraph’s handler, ensuring efficient and streamlined data management within the subgraph framework.
+Use Custom Triggers and enable the full use GraphQL.
 
-> Note: If you haven’t already, visit one of the How-To Guides found [here](./introduction) to scaffold your first project in the Development Container.
+## Overview
+
+Custom Triggers allow you to send data directly into your subgraph mappings file and entities, which are similar to tables and fields. This enables you to fully use the GraphQL layer.
+
+By importing the Protobuf definitions emitted by your Substreams module, you can receive and process this data in your subgraph's handler. This ensures efficient and streamlined data management within the subgraph framework.
+
+### Defining `handleTransactions`
 
 The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
-  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).trasanctions // 1.
+  let transactions = assembly.eth.transaction.v1.Transactions.decode(bytes.buffer).transactions // 1.
   if (transactions.length == 0) {
     log.info('No transactions found', [])
     return
@@ -28,10 +34,14 @@ export function handleTransactions(bytes: Uint8Array): void {
 }
 ```
 
-Here's what you’re seeing in the `mappings.ts` file:
+Here's what you're seeing in the `mappings.ts` file:
 
 1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
 2. Looping over the transactions
 3. Create a new subgraph entity for every transaction
 
-To go through a detailed example of a trigger-based subgraph, [click here](./triggers-example).
+To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
+
+### Additional Resources
+
+To scaffold your first project in the Development Container, check out one of the [How-To Guide](/substreams/developing/devcontainer/).

From c0507233960cf05b79a744300a31db9c869b3bb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:46 -0500
Subject: [PATCH 3201/3820] New translations devcontainer.mdx (Swahili)

---
 .../sw/substreams/developing/devcontainer.mdx | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 website/pages/sw/substreams/developing/devcontainer.mdx

diff --git a/website/pages/sw/substreams/developing/devcontainer.mdx b/website/pages/sw/substreams/developing/devcontainer.mdx
new file mode 100644
index 000000000000..cd65c8d046f8
--- /dev/null
+++ b/website/pages/sw/substreams/developing/devcontainer.mdx
@@ -0,0 +1,47 @@
+---
+title: Substreams Dev Container
+---
+
+Develop your first project with Substreams Dev Container.
+
+## What is a Dev Container?
+
+It's a tool to help you build your first project. You can either run it remotely through Github codespaces or locally by cloning the [substreams starter repository](https://github.com/streamingfast/substreams-starter?tab=readme-ov-file).
+
+Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
+
+## Prerequisites
+
+- Ensure Docker and VS Code are up-to-date.
+
+## Navigating the Dev Container
+
+In the Dev Container, you can either build or import your own `substreams.yaml` and associate modules within the minimal path or opt for the automatically generated Substreams paths. Then, when you run the `Substreams Build` it will generate the Protobuf files.
+
+### Options
+
+- **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
+- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+
+To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
+
+- `substreams registry login`
+- `substreams registry publish`
+
+> Note: If you run into any problems within the Dev Container, use the `help` command to access trouble shooting tools.
+
+## Building a Sink for Your Project
+
+You can configure your project to query data either through a Subgraph or directly from an SQL database:
+
+- **Subgraph**: Run `substreams codegen subgraph`. This generates a project with a basic `schema.graphql` and `mappings.ts` file. You can customize these to define entities based on the data extracted by Substreams. For more configurations, see [subgraph sink documentation](https://docs.substreams.dev/how-to-guides/sinks/subgraph).
+- **SQL**: Run `substreams codegen sql` for SQL-based queries. For more information on configuring a SQL sink, refer to the [SQL documentation](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+## Deployment Options
+
+To deploy a Subgraph, you can either run the `graph-node` locally using the `deploy-local` command or deploy to Subgraph Studio by using the `deploy` command found in the `package.json` file.
+
+## Common Errors
+
+- When running locally, make sure to verify that all Docker containers are healthy by running the `dev-status` command.
+- If you put the wrong start-block while generating your project, navigate to the `substreams.yaml` to change the block number, then re-run `substreams build`.

From e3e5a68d03ff5d9a122329040ea0ac68e9330372 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:47 -0500
Subject: [PATCH 3202/3820] New translations sinks.mdx (Swahili)

---
 .../sw/substreams/developing/sinks/sinks.mdx  | 51 +++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 website/pages/sw/substreams/developing/sinks/sinks.mdx

diff --git a/website/pages/sw/substreams/developing/sinks/sinks.mdx b/website/pages/sw/substreams/developing/sinks/sinks.mdx
new file mode 100644
index 000000000000..3f761c18f0a8
--- /dev/null
+++ b/website/pages/sw/substreams/developing/sinks/sinks.mdx
@@ -0,0 +1,51 @@
+---
+title: Official Sinks
+---
+
+Choose a sink that meets your project's needs.
+
+## Overview
+
+Once you find a package that fits your needs, you can choose how you want to consume the data.
+
+Sinks are integrations that allow you to send the extracted data to different destinations, such as a SQL database, a file or a subgraph.
+
+## Sinks
+
+> Note: Some of the sinks are officially supported by the StreamingFast core development team (i.e. active support is provided), but other sinks are community-driven and support can't be guaranteed.
+
+- [SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink): Send the data to a database.
+- [Subgraph](../../../sps/introduction.mdx): Configure an API to meet your data needs and host it on The Graph Network.
+- [Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream): Stream data directly from your application.
+- [PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub): Send data to a PubSub topic.
+- [Community Sinks](https://docs.substreams.dev/how-to-guides/sinks/community-sinks): Explore quality community maintained sinks.
+
+> Important: If you’d like your sink (e.g., SQL or PubSub) hosted for you, reach out to the StreamingFast team [here](mailto:sales@streamingfast.io).
+
+## Navigating Sink Repos
+
+### Official
+
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+
+### Community
+
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+
+- O = Official Support (by one of the main Substreams providers)
+- C = Community Support

From ec5b7bb5d07f087376b61f1573a3b2826a093bcd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:48 -0500
Subject: [PATCH 3203/3820] New translations accountchanges.mdx (Swahili)

---
 .../developing/solana/accountchanges.mdx      | 62 +++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 website/pages/sw/substreams/developing/solana/accountchanges.mdx

diff --git a/website/pages/sw/substreams/developing/solana/accountchanges.mdx b/website/pages/sw/substreams/developing/solana/accountchanges.mdx
new file mode 100644
index 000000000000..53ab95612a29
--- /dev/null
+++ b/website/pages/sw/substreams/developing/solana/accountchanges.mdx
@@ -0,0 +1,62 @@
+---
+title: Solana Account Changes
+---
+
+Learn how to consume Solana account change data using Substreams.
+
+## Introduction
+
+This guide walks you through the process of setting up your environment, configuring your first Substreams stream, and consuming account changes efficiently. By the end of this guide, you will have a working Substreams feed that allows you to track real-time account changes on the Solana blockchain, as well as historical account change data.
+
+> NOTE: History for the Solana Account Changes dates as of 2025, block 310629601.
+
+For each Substreams Solana account block, only the latest update per account is recorded, see the [Protobuf Referece](https://buf.build/streamingfast/firehose-solana/file/main:sf/solana/type/v1/account.proto). If an account is deleted, a payload with `deleted == True` is provided. Additionally, events of low importance ware omitted, such as those with the special owner “Vote11111111…” account or changes that do not affect the account data (ex: lamport changes).
+
+> NOTE: To test Substreams latency for Solana accounts, measured as block-head drift, install the [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) and running `substreams run solana-common blocks_without_votes -s -1 -o clock`.
+
+## Getting Started
+
+### Prerequisites
+
+Before you begin, ensure that you have the following:
+
+1. [Substreams CLI](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli) installed.
+2. A [Substreams key](https://docs.substreams.dev/reference-material/substreams-cli/authentication) for access to the Solana Account Change data.
+3. Basic knowledge of [how to use](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) the command line interface (CLI).
+
+### Step 1: Set Up a Connection to Solana Account Change Substreams
+
+Now that you have Substreams CLI installed, you can set up a connection to the Solana Account Change Substreams feed.
+
+- Using the [Solana Accounts Foundational Module](https://substreams.dev/packages/solana-accounts-foundational/latest), you can choose to stream data directly or use the GUI for a more visual experience. The following `gui` example filters for Honey Token account data.
+
+```bash
+ substreams gui  solana-accounts-foundational filtered_accounts -t +10 -p filtered_accounts="owner:TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA || account:4vMsoUT2BWatFweudnQM1xedRLfJgJ7hswhcpz4xgBTy"
+```
+
+- This command will stream account changes directly to your terminal.
+
+```bash
+substreams run  solana-accounts-foundational filtered_accounts -s -1 -o clock
+```
+
+The Foundational Module has support for filtering on specific accounts and/or owners. You can adjust the query based on your needs.
+
+### Step 2: Sink the Substreams
+
+Consume the account stream [directly in your application](https://docs.substreams.dev/how-to-guides/sinks/stream) using a callback or make it queryable by using the [SQL-DB sink](https://docs.substreams.dev/how-to-guides/sinks/sql-sink).
+
+### Step 3: Setting up a Reconnection Policy
+
+[Cursor Management](https://docs.substreams.dev/reference-material/reliability-guarantees) ensures seamless continuity and retraceability by allowing you to resume from the last consumed block if the connection is interrupted. This functionality prevents data loss and maintains a persistent stream.
+
+When creating or using a sink, the user's primary responsibility is to provide implementations of BlockScopedDataHandler and a BlockUndoSignalHandler implementation(s) which has the following interface:
+
+```go
+import (
+	pbsubstreamsrpc "github.com/streamingfast/substreams/pb/sf/substreams/rpc/v2"
+)
+
+type BlockScopedDataHandler = func(ctx context.Context, cursor *Cursor, data *pbsubstreamsrpc.BlockScopedData) error
+type BlockUndoSignalHandler = func(ctx context.Context, cursor *Cursor, undoSignal *pbsubstreamsrpc.BlockUndoSignal) error
+```

From d971ef7642e584261644866699d3ef69fceac99d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:49 -0500
Subject: [PATCH 3204/3820] New translations transactions.mdx (Swahili)

---
 .../developing/solana/transactions.mdx        | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)
 create mode 100644 website/pages/sw/substreams/developing/solana/transactions.mdx

diff --git a/website/pages/sw/substreams/developing/solana/transactions.mdx b/website/pages/sw/substreams/developing/solana/transactions.mdx
new file mode 100644
index 000000000000..8e5d7c35d4e7
--- /dev/null
+++ b/website/pages/sw/substreams/developing/solana/transactions.mdx
@@ -0,0 +1,60 @@
+---
+title: Solana Transactions
+---
+
+Learn how to initialize a Solana-based Substreams project within the Dev Container.
+
+> Note: This guide excludes [Account Changes](/substreams/developing/solana/accountchanges/).
+
+## Options
+
+If you prefer to begin locally within your terminal rather than through the Dev Container (VS Code required), refer to the [Substreams CLI installation guide](https://docs.substreams.dev/reference-material/substreams-cli/installing-the-cli).
+
+## Step 1: Initialize Your Solana Substreams Project
+
+1. Open the [Dev Container](https://github.com/streamingfast/substreams-starter) and follow the on-screen steps to initialize your project.
+
+2. Running `substreams init` will give you the option to choose between two Solana project options. Select the best option for your project:
+   - **sol-minimal**: This creates a simple Substreams that extracts raw Solana block data and generates corresponding Rust code. This path will start you with the full raw block, and you can navigate to the `substreams.yaml` (the manifest) to modify the input.
+   - **sol-transactions**: This creates a Substreams that filters Solana transactions based on one or more Program IDs and/or Account IDs, using the cached [Solana Foundational Module](https://substreams.dev/streamingfast/solana-common/v0.3.0).
+   - **sol-anchor-beta**: This creates a Substreams that decodes instructions and events with an Anchor IDL. If an IDL isn’t available (reference [Anchor CLI](https://www.anchor-lang.com/docs/cli)), then you’ll need to provide it yourself.
+
+The modules within Solana Common do not include voting transactions. To gain a 75% reduction in data processing size and costs, delay your stream by over 1000 blocks from the head. This can be done using the [`sleep`](https://doc.rust-lang.org/std/thread/fn.sleep.html) function in Rust.
+
+To access voting transactions, use the full Solana block, `sf.solana.type.v1.Block`, as input.
+
+## Step 2: Visualize the Data
+
+1. Run `substreams auth` to create your [account](https://thegraph.market/) and generate an authentication token (JWT), then pass this token back as input.
+
+2. Now you can freely use the `substreams gui` to visualize and iterate on your extracted data.
+
+## Step 2.5: (Optionally) Transform the Data
+
+Within the generated directories, modify your Substreams modules to include additional filters, aggregations, and transformations, then update the manifest accordingly.
+
+## Step 3: Load the Data
+
+To make your Substreams queryable (as opposed to [direct streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)), you can automatically generate a [Substreams-powered subgraph](../../../sps/introduction.mdx) or SQL-DB sink.
+
+### Subgraph
+
+1. Run `substreams codegen subgraph` to initialize the sink, producing the necessary files and function definitions.
+2. Create your [subgraph mappings](../../../sps/triggers.mdx) within the `mappings.ts` and associated entities within the `schema.graphql`.
+3. Build and deploy locally or to [Subgraph Studio](https://thegraph.com/studio-pricing/) by running `deploy-studio`.
+
+### SQL
+
+1. Run `substreams codegen sql` and choose from either ClickHouse or Postgres to initialize the sink, producing the necessary files.
+2. Run `substreams build` build the [Substream SQL](https://docs.substreams.dev/how-to-guides/sinks/sql-sink) sink.
+3. Run `substreams-sink-sql` to sink the data into your selected SQL DB.
+
+> Note: Run `help` to better navigate the development environment and check the health of containers.
+
+## Additional Resources
+
+You may find these additional resources helpful for developing your first Solana application.
+
+- The [Dev Container Reference](../devcontainer.mdx) helps you navigate the container and its common errors.
+- The [CLI reference](https://docs.substreams.dev/reference-material/substreams-cli/command-line-interface) lets you explore all the tools available in the Substreams CLI.
+- The [Components Reference](https://docs.substreams.dev/reference-material/substreams-components/packages) dives deeper into navigating the `substreams.yaml`.

From e4ebe5ac144736fe3cf9d919987d56b67b548881 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:50 -0500
Subject: [PATCH 3205/3820] New translations getting-started-substreams.mdx
 (Swahili)

---
 .../substreams/getting-started-substreams.mdx | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 website/pages/sw/substreams/getting-started-substreams.mdx

diff --git a/website/pages/sw/substreams/getting-started-substreams.mdx b/website/pages/sw/substreams/getting-started-substreams.mdx
new file mode 100644
index 000000000000..5541cc56d347
--- /dev/null
+++ b/website/pages/sw/substreams/getting-started-substreams.mdx
@@ -0,0 +1,41 @@
+---
+title: Substreams Quick Start
+---
+
+Discover how to utilize ready-to-use substream packages or develop your own.
+
+## Overview
+
+Integrating Substreams can be quick and easy. They are permissionless, and you can [obtain a key here](https://thegraph.market/) without providing personal information to start streaming on-chain data.
+
+## Start Building
+
+### Use Substreams Packages
+
+There are many ready-to-use Substreams packages available. You can explore these packages by visiting the [Substreams Registry](https://substreams.dev) and [sinking them](/substreams/developing/sinks/sinks/). The registry lets you search for and find any package that meets your needs.
+
+Once you find a package that fits your needs, you can choose how you want to consume the data:
+
+- **[Subgraph](/sps/introduction/)**: Configure an API to meet your data needs and host it on The Graph Network.
+- **[SQL Database](https://docs.substreams.dev/how-to-guides/sinks/sql-sink)**: Send the data to a database.
+- **[Direct Streaming](https://docs.substreams.dev/how-to-guides/sinks/stream)**: Stream data directly to your application.
+- **[PubSub](https://docs.substreams.dev/how-to-guides/sinks/pubsub)**: Send data to a PubSub topic.
+
+### Develop Your Own
+
+If you can't find a Substreams package that meets your specific needs, you can develop your own. Substreams are built with Rust, so you'll write functions that extract and filter the data you need from the blockchain. To get started, check out the following tutorials:
+
+- [EVM](https://docs.substreams.dev/tutorials/intro-to-tutorials/evm)
+- [Solana](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-solana)
+- [Starknet](https://docs.substreams.dev/tutorials/intro-to-tutorials/starknet)
+- [Injective](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/injective)
+- [MANTRA](https://docs.substreams.dev/tutorials/intro-to-tutorials/on-cosmos/mantra)
+
+To build and optimize your Substreams from zero, use the minimal path within the [Dev Container](/substreams/developing/devcontainer/).
+
+> Note: Substreams guarantees that you'll [never miss data](https://docs.substreams.dev/reference-material/reliability-guarantees) with a simple reconnection policy.
+
+## Additional Resources
+
+- For additional guidance, reference the [Tutorials](https://docs.substreams.dev/tutorials/intro-to-tutorials) and follow the [How-To Guides](https://docs.substreams.dev/how-to-guides/develop-your-own-substreams) on Streaming Fast docs.
+- For a deeper understanding of how Substreams works, explore the [architectural overview](https://docs.substreams.dev/reference-material/architecture) of the data service.

From eda394b79834230cf261baffd23c6151fb14cd45 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:51 -0500
Subject: [PATCH 3206/3820] New translations pubsubstreams.mdx (Swahili)

---
 website/pages/sw/substreams/pubsubstreams.mdx | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 website/pages/sw/substreams/pubsubstreams.mdx

diff --git a/website/pages/sw/substreams/pubsubstreams.mdx b/website/pages/sw/substreams/pubsubstreams.mdx
new file mode 100644
index 000000000000..3c02d60f9ffd
--- /dev/null
+++ b/website/pages/sw/substreams/pubsubstreams.mdx
@@ -0,0 +1,52 @@
+---
+title: Publishing a Substreams Package
+---
+
+Learn how to publish a Substreams package to the [Substreams Registry](https://substreams.dev).
+
+## Overview
+
+### What is a package?
+
+A Substreams package is a precompiled binary file that defines the specific data you want to extract from the blockchain, similar to the `mapping.ts` file in traditional subgraphs.
+
+## Publish a Package
+
+### Prerequisites
+
+- You must have the Substreams CLI installed.
+- You must have a Substreams package (`.spkg`) that you want to publish.
+
+### Step 1: Run the `substreams publish` Command
+
+1. In a command-line terminal, run `substreams publish <YOUR-PACKAGE>.spkg`.
+
+2. If you do not have a token set in your computer, navigate to `https://substreams.dev/me`.
+
+![get token](/img/1_get-token.png)
+
+### Step 2: Get a Token in the Substreams Registry
+
+1. In the Substreams Registry, log in with your GitHub account.
+
+2. Create a new token and copy it in a safe location.
+
+![new token](/img/2_new_token.png)
+
+### Step 3: Authenticate in the Substreams CLI
+
+1. Back in the Substreams CLI, paste the previously generated token.
+
+![paste token](/img/3_paste_token.png)
+
+2. Lastly, confirm that you want to publish the package.
+
+![confirm](/img/4_confirm.png)
+
+That's it! You have succesfully published a package in the Substreams registry.
+
+![success](/img/5_success.png)
+
+## Additional Resources
+
+Visit [Substreams](https://substreams.dev/) to explore a growing collection of ready-to-use Substreams packages across various blockchain networks.

From e9a621a7495eb3a1b997e6c86f1c308a0a9d1eb0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 20:28:52 -0500
Subject: [PATCH 3207/3820] New translations tutorial.mdx (Swahili)

---
 website/pages/sw/sps/tutorial.mdx | 154 ++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 website/pages/sw/sps/tutorial.mdx

diff --git a/website/pages/sw/sps/tutorial.mdx b/website/pages/sw/sps/tutorial.mdx
new file mode 100644
index 000000000000..b17e5d9ff491
--- /dev/null
+++ b/website/pages/sw/sps/tutorial.mdx
@@ -0,0 +1,154 @@
+---
+title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+---
+
+Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
+
+## Get Started
+
+For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
+
+### Prerequisites
+
+Before starting, make sure to:
+
+- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
+- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+
+### Step 1: Initialize Your Project
+
+1. Open your Dev Container and run the following command to initialize your project:
+
+   ```bash
+   substreams init
+   ```
+
+2. Select the "minimal" project option.
+
+3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+
+```yaml
+specVersion: v0.1.0
+package:
+  name: my_project_sol
+  version: v0.1.0
+
+imports: # Pass your spkg of interest
+  solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
+
+modules:
+  - name: map_spl_transfers
+    use: solana:map_block # Select corresponding modules available within your spkg
+    initialBlock: 260000082
+
+  - name: map_transactions_by_programid
+    use: solana:solana:transactions_by_programid_without_votes
+
+network: solana-mainnet-beta
+
+params: # Modify the param fields to meet your needs
+  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+  map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
+```
+
+### Step 2: Generate the Subgraph Manifest
+
+Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+
+```bash
+substreams codegen subgraph
+```
+
+You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+
+```yaml
+---
+dataSources:
+  - kind: substreams
+    name: my_project_sol
+    network: solana-mainnet-beta
+    source:
+      package:
+        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        file: ./my-project-sol-v0.1.0.spkg
+    mapping:
+      apiVersion: 0.0.7
+      kind: substreams/graph-entities
+      file: ./src/mappings.ts
+      handler: handleTriggers
+```
+
+### Step 3: Define Entities in `schema.graphql`
+
+Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
+
+Here is an example:
+
+```graphql
+type MyTransfer @entity {
+  id: ID!
+  amount: String!
+  source: String!
+  designation: String!
+  signers: [String!]!
+}
+```
+
+This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+
+### Step 4: Handle Substreams Data in `mappings.ts`
+
+With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
+
+The example below demonstrates how to extract to subgraph entities the non-derived transfers associated to the Orca account id:
+
+```ts
+import { Protobuf } from 'as-proto/assembly'
+import { Events as protoEvents } from './pb/sf/solana/spl/token/v1/Events'
+import { MyTransfer } from '../generated/schema'
+
+export function handleTriggers(bytes: Uint8Array): void {
+  const input: protoEvents = Protobuf.decode<protoEvents>(bytes, protoEvents.decode)
+
+  for (let i = 0; i < input.data.length; i++) {
+    const event = input.data[i]
+
+    if (event.transfer != null) {
+      let entity_id: string = `${event.txnId}-${i}`
+      const entity = new MyTransfer(entity_id)
+      entity.amount = event.transfer!.instruction!.amount.toString()
+      entity.source = event.transfer!.accounts!.source
+      entity.designation = event.transfer!.accounts!.destination
+
+      if (event.transfer!.accounts!.signer!.single != null) {
+        entity.signers = [event.transfer!.accounts!.signer!.single!.signer]
+      } else if (event.transfer!.accounts!.signer!.multisig != null) {
+        entity.signers = event.transfer!.accounts!.signer!.multisig!.signers
+      }
+      entity.save()
+    }
+  }
+}
+```
+
+### Step 5: Generate Protobuf Files
+
+To generate Protobuf objects in AssemblyScript, run the following command:
+
+```bash
+npm run protogen
+```
+
+This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+
+### Conclusion
+
+Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
+
+### Video Tutorial
+
+<VideoEmbed youtube="RmKi-Nq9E_A" />
+
+### Additional Resources
+
+For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).

From 1ae7ce9563603ebf28381205b7cae8ec855ea643 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 21:26:32 -0500
Subject: [PATCH 3208/3820] New translations enums.mdx (Hindi)

---
 website/pages/hi/subgraphs/cookbook/enums.mdx | 46 +++++++++----------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/website/pages/hi/subgraphs/cookbook/enums.mdx b/website/pages/hi/subgraphs/cookbook/enums.mdx
index 3acf87d26b28..4b183b10f207 100644
--- a/website/pages/hi/subgraphs/cookbook/enums.mdx
+++ b/website/pages/hi/subgraphs/cookbook/enums.mdx
@@ -10,7 +10,7 @@ Enums, या enumeration types, एक विशिष्ट डेटा प
 
 ### अपने Schema में Enums का उदाहरण
 
-If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+यदि आप एक subgraph बना रहे हैं जो एक मार्केटप्लेस पर टोकन के स्वामित्व इतिहास को ट्रैक करता है, तो प्रत्येक टोकन विभिन्न स्वामित्वों से गुजर सकता है, जैसे कि OriginalOwner, SecondOwner, और ThirdOwner। enums का उपयोग करके, आप इन विशिष्ट स्वामित्वों को परिभाषित कर सकते हैं, यह सुनिश्चित करते हुए कि केवल पूर्वनिर्धारित मान ही सौंपे जाएं।
 
 You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
 
@@ -31,12 +31,12 @@ enum TokenStatus {
 ## Enums का उपयोग करने के लाभ
 
 - **Clarity:** Enums provide meaningful names for values, making data easier to understand.
-- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
-- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+- सत्यापन: Enums कड़े मान मान्यताएँ लागू करते हैं, जो अवैध डेटा प्रविष्टियों को रोकते हैं।
+- रखरखाव: जब आपको नए श्रेणियाँ या ईनम्स (enums) जोड़ने या बदलने की आवश्यकता हो, तो आप इसे एक केंद्रित तरीके से कर सकते हैं।
 
-### Without Enums
+### बिना Enums
 
-If you choose to define the type as a string instead of using an Enum, your code might look like this:
+यदि आप Enum का उपयोग करने के बजाय प्रकार को एक स्ट्रिंग के रूप में परिभाषित करते हैं, तो आपका कोड इस प्रकार दिख सकता है:
 
 ```graphql
 type Token @entity {
@@ -48,11 +48,11 @@ type Token @entity {
 }
 ```
 
-In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+इस स्कीमा में, TokenStatus एक साधारण स्ट्रिंग है जिसमें कोई विशिष्ट, अनुमत मान नहीं होते हैं।
 
 #### यह एक समस्या क्यों है?
 
-- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
+- TokenStatus मानों की कोई सीमा नहीं है, इसलिए कोई भी स्ट्रिंग गलती से असाइन की जा सकती है। इससे यह सुनिश्चित करना कठिन हो जाता है कि केवल वैध स्टेटस जैसे OriginalOwner, SecondOwner, या ThirdOwner सेट किए जाएं।
 - It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
 
 ### Enums के साथ
@@ -63,26 +63,26 @@ Enums प्रकार सुरक्षा प्रदान करते 
 
 ## NFT मार्केटप्लेस के लिए एन्उम्स को परिभाषित करना
 
-> Note: The following guide uses the CryptoCoven NFT smart contract.
+> नोट: निम्नलिखित guide CryptoCoven NFT स्मार्ट कॉन्ट्रैक्ट का उपयोग करती है।
 
 To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
 
 ```gql
-# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+#मार्केटप्लेस के लिए Enum जो CryptoCoven कॉन्ट्रैक्ट के साथ इंटरएक्टेड हैं (संभवत: ट्रेड/मिंट) 
 enum Marketplace {
-  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
-  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
-  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
-  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
-  # ...and other marketplaces
+  OpenSeaV1 # जब CryptoCoven NFT को इस बाजार में व्यापार किया जाता है
+  OpenSeaV2 # जब CryptoCoven NFT को OpenSeaV2 बाजार में व्यापार किया जाता है
+  SeaPort # जब CryptoCoven NFT को SeaPort बाजार में व्यापार किया जाता है
+  LooksRare # जब CryptoCoven NFT को LooksRare बाजार में व्यापार किया जाता है
+  # ...और अन्य बाजार
 }
 ```
 
 ## NFT Marketplaces के लिए Enums का उपयोग
 
-Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+एक बार परिभाषित होने पर, enums का उपयोग आपके subgraph में transactions या events को श्रेणीबद्ध करने के लिए किया जा सकता है।
 
-For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+उदाहरण के लिए, जब logging NFT बिक्री लॉग करते हैं, तो आप ट्रेड में शामिल मार्केटप्लेस को enum का उपयोग करके निर्दिष्ट कर सकते हैं।
 
 ### NFT मार्केटप्लेस के लिए एक फंक्शन लागू करना
 
@@ -107,7 +107,7 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 ## Enums का उपयोग करने के लिए सर्वोत्तम प्रथाएँ
 
 - सुसंगत नामकरण: पठनीयता को बेहतर बनाने के लिए enum मानों के लिए स्पष्ट, वर्णनात्मक नामों का उपयोग करें।
-- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
+- केंद्रीकृत प्रबंधन: एकल फ़ाइल में enums रखें ताकि सुसंगतता बनी रहे। इससे enums को अपडेट करना आसान हो जाता है और यह सत्य का एकमात्र source बनता है।
 - दस्तावेज़ीकरण: एनम में उनकी उद्देश्य और उपयोग को स्पष्ट करने के लिए टिप्पणियाँ जोड़ें।
 
 ## Using Enums in Queries
@@ -123,7 +123,7 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 
 #### Query 1: सबसे अधिक NFT मार्केटप्लेस इंटरएक्शन वाला खाता
 
-This query does the following:
+यह क्वेरी निम्नलिखित कार्य करती है:
 
 - यह खाते को खोजता है जिसमें सबसे अधिक अनूठे NFT मार्केटप्लेस इंटरैक्शन होते हैं, जो क्रॉस-मार्केटप्लेस गतिविधि का विश्लेषण करने के लिए बेहतरीन है।
 - मार्केटप्लेस फील्ड marketplace एनम का उपयोग करता है, जो प्रतिक्रिया में सुसंगत और मान्य मार्केटप्लेस मान सुनिश्चित करता है।
@@ -186,9 +186,9 @@ This query does the following:
 }
 ```
 
-#### Query 2: Most Active Marketplace for CryptoCoven transactions
+#### Query 2: CryptoCoven transactions के लिए सबसे सक्रिय बाज़ार
 
-This query does the following:
+यह क्वेरी निम्नलिखित कार्य करती है:
 
 - It identifies the marketplace with the highest volume of CryptoCoven transactions.
 - यह मार्केटप्लेस enum का उपयोग करता है ताकि प्रतिक्रिया में केवल मान्य मार्केटप्लेस प्रकार ही दिखाई दें, जिससे आपके डेटा में विश्वसनीयता और स्थिरता बनी रहती है।
@@ -204,7 +204,7 @@ This query does the following:
 
 #### परिणाम 2
 
-The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+अपेक्षित प्रतिक्रिया में मार्केटप्लेस और संबंधित transaction संख्या शामिल है, जो मार्केटप्लेस प्रकार को संकेत करने के लिए enum का उपयोग करती है:
 
 ```gql
 {
@@ -221,7 +221,7 @@ The expected response includes the marketplace and the corresponding transaction
 
 #### Query 3: Marketplace Interactions with High Transaction Counts
 
-This query does the following:
+यह क्वेरी निम्नलिखित कार्य करती है:
 
 - It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
 - यह केवल वैध मार्केटप्लेस प्रकारों को शामिल करने के लिए फ़िल्टर के रूप में एंनम का उपयोग करता है, जिससे सटीकता बढ़ती है।
@@ -271,4 +271,4 @@ This query does the following:
 
 ## Additional Resources
 
-For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).
+अधिक जानकारी के लिए, इस guide's के [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums) को देखें।

From 0296d0bf0c365c621845dc24a2bb6b6c24bee193 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 26 Jan 2025 21:26:33 -0500
Subject: [PATCH 3209/3820] New translations transfer-to-the-graph.mdx (Hindi)

---
 .../pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx
index a750211bfa2b..e112cc76a16d 100644
--- a/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -18,7 +18,7 @@ title: The Graph पर ट्रांसफर करें
 
 ## 1. अपने स्टूडियो वातावरण को सेट करें
 
-### Create a Subgraph in Subgraph Studio
+### सबग्राफ बनाएँ Subgraph Studio में
 
 - [Subgraph Studio](https://thegraph.com/studio/) पर जाएँ और अपने वॉलेट को कनेक्ट करें।
 - "एक सबग्राफ बनाएं" पर क्लिक करें। सबग्राफ का नाम टाइटल केस में रखनाrecommended है: "सबग्राफ नाम चेन नाम"।
@@ -68,7 +68,7 @@ graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
 
 ![पब्लिश बटन](/img/publish-sub-transfer.png)
 
-### Query Your Subgraph
+### अपने Subgraph को क्वेरी करें
 
 > To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
 
@@ -80,7 +80,7 @@ You can start [querying](/subgraphs/querying/introduction/) any subgraph by send
 
 ![Query URL](/img/cryptopunks-screenshot-transfer.png)
 
-The query URL for this subgraph is:
+इस subgraph का क्वेरी URL है:
 
 ```sh
 https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
@@ -94,7 +94,7 @@ https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgrap
 
 ![API keys](/img/Api-keys-screenshot.png)
 
-### Monitor Subgraph Status
+### सबग्राफ की स्थिति की निगरानी करें
 
 एक बार जब आप अपग्रेड करते हैं, तो आप Subgraph Studio(https://thegraph.com/studio/) में अपने सबग्राफ्स को एक्सेस और प्रबंधित कर सकते हैं और The Graph Explorer(https://thegraph.com/networks/) में सभी सबग्राफ्स को एक्सप्लोर कर सकते हैं।
 

From f2e922b59f0e18e8c1c58b979c6d86466a5bd02a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 09:11:19 -0500
Subject: [PATCH 3210/3820] New translations billing.mdx (Spanish)

---
 website/pages/es/subgraphs/billing.mdx | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/es/subgraphs/billing.mdx b/website/pages/es/subgraphs/billing.mdx
index a88cb8dae63c..bc6df180342a 100644
--- a/website/pages/es/subgraphs/billing.mdx
+++ b/website/pages/es/subgraphs/billing.mdx
@@ -53,12 +53,12 @@ Once you bridge GRT, you can add it to your billing balance.
 
 1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
 2. Haz clic en el botón "Conectar wallet" en la esquina superior derecha de la página. Serás redirigido a la página de selección de wallet. Selecciona tu wallet y haz clic en "Conectar".
-3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
-4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
-   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
-5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
-6. Select the number of months you would like to prepay.
-   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+3. Selecciona el botón "Gestionar" en la esquina superior derecha. Los usuarios que acceden por primera vez verán la opción "Mejorar al Plan de Expansión", mientras que los usuarios recurrentes deberán hacer clic en "Depositar desde la wallet".
+4. Utiliza la barra deslizante para estimar la cantidad de consultas que esperas realizar mensualmente.
+   - Para obtener sugerencias sobre la cantidad de consultas que podrías usar, consulta nuestra página de Preguntas Frecuentes.
+5. Selecciona "Cripto". Actualmente, GRT es la única criptomoneda aceptada en The Graph Network.
+6. Selecciona la cantidad de meses que deseas pagar por adelantado.
+   - Pagar por adelantado no te compromete a un uso futuro. Solo se te cobrará por lo que utilices, y puedes retirar tu saldo en cualquier momento.
 7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
    - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
@@ -79,12 +79,12 @@ Once you bridge GRT, you can add it to your billing balance.
 
 1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
 2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
-3. Select the "Manage" button near the top right corner. First time users will see an option to "Upgrade to Growth plan" while returning users will click "Deposit from wallet".
-4. Use the slider to estimate the number of queries you expect to make on a monthly basis.
-   - For suggestions on the number of queries you may use, see our **Frequently Asked Questions** page.
-5. Choose "Cryptocurrency". GRT is currently the only cryptocurrency accepted on The Graph Network.
-6. Select the number of months you would like to prepay.
-   - Paying in advance does not commit you to future usage. You will only be charged for what you use and you can withdraw your balance at any time.
+3. Selecciona el botón "Gestionar" en la esquina superior derecha. Los usuarios que acceden por primera vez verán la opción "Mejorar al Plan de Expansión", mientras que los usuarios recurrentes deberán hacer clic en "Depositar desde la wallet".
+4. Utiliza la barra deslizante para estimar la cantidad de consultas que esperas realizar mensualmente.
+   - Para obtener sugerencias sobre la cantidad de consultas que podrías usar, consulta nuestra página de Preguntas Frecuentes.
+5. Selecciona "Cripto". Actualmente, GRT es la única criptomoneda aceptada en The Graph Network.
+6. Selecciona la cantidad de meses que deseas pagar por adelantado.
+   - Pagar por adelantado no te compromete a un uso futuro. Solo se te cobrará por lo que utilices, y puedes retirar tu saldo en cualquier momento.
 7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
    - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
 8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.

From 4b785709d80c0817222f2ca53e2421d8bc7b8b7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 10:08:42 -0500
Subject: [PATCH 3211/3820] New translations enums.mdx (Hindi)

---
 website/pages/hi/subgraphs/cookbook/enums.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/hi/subgraphs/cookbook/enums.mdx b/website/pages/hi/subgraphs/cookbook/enums.mdx
index 4b183b10f207..c6c2a2dfc188 100644
--- a/website/pages/hi/subgraphs/cookbook/enums.mdx
+++ b/website/pages/hi/subgraphs/cookbook/enums.mdx
@@ -90,16 +90,16 @@ enum Marketplace {
 
 ```ts
 export function getMarketplaceName(marketplace: Marketplace): string {
-  // Using if-else statements to map the enum value to a string
+  // यदि-और-else कथनों का उपयोग करके enum मान को एक स्ट्रिंग में मैप करें
   if (marketplace === Marketplace.OpenSeaV1) {
-    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+    return 'OpenSeaV1' // यदि बाज़ार OpenSea है, तो इसकी स्ट्रिंग प्रतिनिधित्व लौटाएँ
   } else if (marketplace === Marketplace.OpenSeaV2) {
     return 'OpenSeaV2'
   } else if (marketplace === Marketplace.SeaPort) {
-    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+    return 'SeaPort' // यदि बाज़ार SeaPort है, तो इसकी स्ट्रिंग प्रतिनिधित्व लौटाएँ
   } else if (marketplace === Marketplace.LooksRare) {
-    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
-    // ... and other market places
+    return 'LooksRare' // यदि बाज़ार LooksRare है, तो इसकी स्ट्रिंग प्रतिनिधित्व लौटाएँ
+    // ... और अन्य बाज़ार
   }
 }
 ```

From f65e6616645002ee17dfd8e35ded6e8e5e997fe2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 11:29:05 -0500
Subject: [PATCH 3212/3820] New translations assemblyscript-migration-guide.mdx
 (Hindi)

---
 .../release-notes/assemblyscript-migration-guide.mdx          | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx
index a57b61c8e2ae..e992941445be 100644
--- a/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -160,12 +160,12 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
 
 ```typescript
 let byteArray = new ByteArray(10)
-let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+let uint8Array = byteArray as Uint8Array // इसका समकक्ष: <Uint8Array>byteArray
 ```
 
 However this only works in two scenarios:
 
-- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- प्रिमिटिव कास्टिंग (जैसे `u8`, `i32`, `bool` प्रकारों के बीच; उदाहरण के लिए: `let b: isize = 10; b as usize`);
 - क्लास इनहेरिटेंस (सबक्लास → सुपरक्लास) पर अपकास्टिंग
 
 उदाहरण:

From d6166612215160557436db0dccf52875d4f1e899 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 12:33:36 -0500
Subject: [PATCH 3213/3820] New translations overview.mdx (Hindi)

---
 website/pages/hi/indexing/overview.mdx | 70 +++++++++++++-------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/hi/indexing/overview.mdx b/website/pages/hi/indexing/overview.mdx
index 6b13a24d9537..0a3082bef375 100644
--- a/website/pages/hi/indexing/overview.mdx
+++ b/website/pages/hi/indexing/overview.mdx
@@ -18,9 +18,9 @@ Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) i
 
 ### एक इंडेक्सर के लिए राजस्व धाराएं क्या हैं?
 
-**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+**क्वेरी शुल्क छूट** - नेटवर्क पर क्वेरी सेवाओं के लिए किए गए भुगतान। ये भुगतान 'state channels' के माध्यम से एक Indexer और एक 'gateway' के बीच नियंत्रित किए जाते हैं। 'gateway' से प्रत्येक क्वेरी अनुरोध में एक भुगतान और संबंधित प्रतिक्रिया में क्वेरी परिणाम की वैधता का प्रमाण शामिल होता है।
 
-**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+indexing रिवॉर्ड्स - 3% वार्षिक प्रोटोकॉल वाइड इन्फ्लेशन के माध्यम से उत्पन्न, indexing रिवॉर्ड्स उन Indexers को वितरित किए जाते हैं जो नेटवर्क के indexing subgraph डिप्लॉयमेंट्स को इंडेक्स कर रहे हैं।
 
 ### इंडेक्सिंग पुरस्कार कैसे वितरित किए जाते हैं?
 
@@ -39,7 +39,7 @@ collection(https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e7
 
 ### क्या लंबित अनुक्रमण पुरस्कारों की निगरानी की जा सकती है?
 
-The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+RewardsManager कॉन्ट्रैक्ट में एक read-only getRewards(https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) फ़ंक्शन है, जिसे किसी विशेष allocation के लिए लंबित rewards की जांच करने के लिए उपयोग किया जा सकता है।
 
 कई समुदाय-निर्मित डैशबोर्ड में लंबित पुरस्कार मान शामिल हैं और इन चरणों का पालन करके उन्हें आसानी से मैन्युअल रूप से चेक किया जा सकता है:
 
@@ -61,7 +61,7 @@ query indexerAllocations {
 
 Etherscan का उपयोग करके getRewards() कॉल करें:
 
-- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+- Etherscan इंटरफेस पर 'Rewards' कॉन्ट्रैक्ट(https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract) को नेविगेट करें
 
 <!---->
 
@@ -84,13 +84,13 @@ Etherscan का उपयोग करके getRewards() कॉल करे
 
 ### प्रश्न शुल्क छूट क्या हैं और वे कब वितरित की जाती हैं?
 
-Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+क्वेरी शुल्क गेटवे द्वारा एकत्र किए जाते हैं और Indexer को प्रक्षिप्त छूट फ़ंक्शन के अनुसार वितरित किए जाते हैं (यहां GIP देखें here(https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162))। प्रक्षिप्त छूट फ़ंक्शन को Indexer को सबसे अच्छा परिणाम प्राप्त करने के लिए प्रोत्साहित करने का एक तरीका प्रस्तावित किया गया है, ताकि वे queries की सेवा faithfully करें। यह Indexer को एक बड़ी मात्रा में स्टेक आवंटित करने के लिए प्रोत्साहित करता है (जो एक क्वेरी की सेवा करते समय गलती करने पर स्लैश किया जा सकता है), जो कि वे जो क्वेरी शुल्क एकत्र कर सकते हैं, उसके मुकाबले अधिक है।
 
 Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
 
 ### क्वेरी फी कट और इंडेक्सिंग रिवॉर्ड कट क्या है?
 
-The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+The 'queryFeeCut' और 'indexingRewardCut' मान delegation पैरामीटर हैं जिन्हें Indexer अपने Delegators के बीच GRT के वितरण को नियंत्रित करने के लिए cooldownBlocks के साथ सेट कर सकता है। delegation पैरामीटर सेट करने के लिए Staking in the Protocol(/indexing/overview/#stake-in-the-protocol) में अंतिम कदम देखें।
 
 - queryFeeCut - वह % जो query fee rebates का वितरण Indexer को किया जाएगा। अगर इसे 95% पर सेट किया जाता है, तो Indexer को वह query fees का 95% मिलेगा जो allocation बंद होने पर अर्जित होती है, जबकि बाकी का 5% Delegators को मिलेगा।
 
@@ -100,9 +100,9 @@ The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that
 
 इंडेक्सर्स सबग्राफ इंडेक्सिंग निर्णय लेने के लिए उन्नत तकनीकों को लागू करके खुद को अलग कर सकते हैं लेकिन एक सामान्य विचार देने के लिए हम नेटवर्क में सबग्राफ का मूल्यांकन करने के लिए उपयोग की जाने वाली कई प्रमुख मीट्रिक पर चर्चा करेंगे:
 
-- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+- **Curation signal** - किसी विशेष subgraph पर लागू नेटवर्क क्यूरेशन सिग्नल का अनुपात उस subgraph में रुचि का अच्छा संकेतक होता है, खासकर बूटस्ट्रैप चरण के दौरान जब क्वेरी वॉल्यूम बढ़ रहा होता है।
 
-- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+- **क्वेरी शुल्क एकत्रित किए गए** - एक विशिष्ट Subgraph के लिए एकत्रित किए गए क्वेरी शुल्क के वॉल्यूम का ऐतिहासिक डेटा भविष्य की मांग का एक अच्छा संकेतक होता है।
 
 - **Amount staked** - अन्य Indexers के व्यवहार की निगरानी करना या विशिष्ट subgraphs के लिए कुल स्टेक में आवंटित अनुपात को देखना एक Indexer को subgraph क्वेरीज़ के लिए आपूर्ति पक्ष की निगरानी करने की अनुमति दे सकता है, ताकि वे subgraphs की पहचान कर सकें जिनमें नेटवर्क विश्वास दिखा रहा है या ऐसे subgraphs जिन्हें अधिक आपूर्ति की आवश्यकता हो सकती है।
 
@@ -110,10 +110,10 @@ The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that
 
 ### हार्डवेयर आवश्यकताएँ क्या हैं?
 
-- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
+- **छोटा** - शुरू करने के लिए पर्याप्त है, कुछ subgraphs को इंडेक्स करने के लिए, संभवतः इसे बढ़ाने की आवश्यकता होगी।
 - **मानक** - डिफ़ॉल्ट सेटअप, यही है जो उदाहरण k8s/terraform डिप्लॉयमेंट मैनिफेस्ट्स में उपयोग किया जाता है।
-- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
-- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+- मध्यम - प्रोडक्शन Indexer जो 100 subgraphs और 200-500 रिक्वेस्ट प्रति सेकंड का समर्थन करता है।
+- **बड़ा**- सभी वर्तमान में उपयोग किए जा रहे सबग्राफ़ को अनुक्रमित करने और संबंधित ट्रैफ़िक के लिए अनुरोधों को सेवा देने के लिए तैयार।
 
 | Setup    | Postgres<br />(CPUs) | Postgres<br />(memory in GBs) | Postgres<br />(disk in TBs) | VMs<br />(CPUs) | VMs<br />(memory in GBs) |
 | -------- | :------------------: | :---------------------------: | :-------------------------: | :-------------: | :----------------------: |
@@ -124,23 +124,23 @@ The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that
 
 ### एक इंडेक्सर को कौन सी बुनियादी सुरक्षा सावधानियां बरतनी चाहिए?
 
-- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+- ऑपरेटर वॉलेट - एक ऑपरेटर वॉलेट सेट करना एक महत्वपूर्ण सुरक्षा उपाय है क्योंकि इससे एक Indexer को अपने स्टेक को नियंत्रित करने वाली कुंजियों और दिन-प्रतिदिन के संचालन को नियंत्रित करने वाली कुंजियों के बीच अलगाव बनाए रखने में मदद मिलती है। निर्देशों के लिए Stake in Protocol(/indexing/overview/#stake-in-the-protocol) for instructions. देखें।
 
 - **फायरवॉल** - केवल Indexer सेवा को सार्वजनिक रूप से एक्सपोज़ किया जाना चाहिए और विशेष ध्यान प्रशासनिक पोर्ट्स और डेटाबेस एक्सेस को लॉक करने पर दिया जाना चाहिए: Graph Node JSON-RPC एंडपॉइंट (डिफ़ॉल्ट पोर्ट: 8030), Indexer प्रबंधन API एंडपॉइंट (डिफ़ॉल्ट पोर्ट: 18000), और Postgres डेटाबेस एंडपॉइंट (डिफ़ॉल्ट पोर्ट: 5432) को एक्सपोज़ नहीं किया जाना चाहिए।
 
 ## आधारभूत संरचना
 
-At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+An Indexer की इंफ्रास्ट्रक्चर के केंद्र में the Graph Node होता है जो इंडेक्स किए गए नेटवर्क्स की निगरानी करता है, एक subgraph परिभाषा के अनुसार डेटा निकालता और लोड करता है और इसे एक GraphQL API(/about/#how-the-graph-works) के रूप में प्रदान करता है। The Graph Node को प्रत्येक इंडेक्स किए गए नेटवर्क से डेटा को एक्सपोज़ करने वाले एक endpoint से जोड़ा जाना चाहिए; डेटा स्रोत के लिए एक IPFS node; इसके स्टोर के लिए एक PostgreSQL डेटाबेस; और Indexer घटक जो इसके नेटवर्क के साथ इंटरएक्शन को सुविधाजनक बनाते हैं।
 
-- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+- PostgreSQL डेटाबेस - यह Graph Node के लिए मुख्य स्टोर है, जहां subgraph डेटा संग्रहीत किया जाता है। Indexer सेवा और एजेंट भी डेटाबेस का उपयोग state channel डेटा, लागत मॉडल, indexing नियम, और आवंटन क्रियाओं को संग्रहीत करने के लिए करते हैं।
 
 - **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
 
-- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+- IPFS नोड (संस्करण 5 से कम) - सबग्राफ डिप्लॉयमेंट मेटाडेटा IPFS नेटवर्क पर संग्रहीत होता है। The Graph Node मुख्य रूप से सबग्राफ डिप्लॉयमेंट के दौरान IPFS नोड का उपयोग करता है ताकि सबग्राफ मैनिफेस्ट और सभी लिंक की गई फाइल्स को प्राप्त किया जा सके। नेटवर्क Indexers को अपना स्वयं का IPFS नोड होस्ट करने की आवश्यकता नहीं होती है, नेटवर्क के लिए एक IPFS नोड https://ipfs.network.thegraph.com पर होस्ट किया गया है।
 
-- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+- **Indexer सेवा** - नेटवर्क के साथ आवश्यक सभी बाहरी संचार को संभालती है। लागत मॉडलों और indexing स्थितियों को साझा करती है, गेटवे से आने वाले क्वेरी अनुरोधों को Graph Node तक पहुंचाती है, और गेटवे के साथ राज्य चैनलों के माध्यम से क्वेरी भुगतानों का प्रबंधन करती है।
 
-- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Indexer एजेंट** - ऑनचेन पर Indexers की इंटरैक्शन को सुविधाजनक बनाता है, जिसमें नेटवर्क पर रजिस्ट्रेशन करना, अपने ग्राफ नोड/स पर Subgraph डिप्लॉयमेंट्स को मैनेज करना और आवंटनों (allocations) को प्रबंधित करना शामिल है।
 
 - **प्रोमेथियस मेट्रिक्स सर्वर** - The Graph Node और Indexer कंपोनेंट्स अपने मेट्रिक्स को मेट्रिक्स सर्वर पर लॉग करते हैं।
 
@@ -148,7 +148,7 @@ At the center of an Indexer's infrastructure is the Graph Node which monitors th
 
 ### Ports overview
 
-> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+> **महत्वपूर्ण** पोर्ट्स को सार्वजनिक रूप से एक्सपोज़ करने में सतर्क रहें - **प्रशासनिक पोर्ट्स** को सुरक्षित रखना चाहिए। इसमें नीचे बताए गए Graph Node JSON-RPC और Indexer प्रबंधन एंडपॉइंट्स शामिल हैं।
 
 #### ग्राफ-नोड
 
@@ -300,7 +300,7 @@ kubectl config use-context $(kubectl config get-contexts --output='name'
 
 ### ग्राफ-नोड
 
-[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+[Graph Node](https://github.com/graphprotocol/graph-node) एक ओपन-सोर्स रस्ट इंप्लीमेंटेशन है जो Ethereum ब्लॉकचेन को इवेंट सोर्सिंग करता है ताकि एक डेटा स्टोर को डिटर्मिनिस्टिक तरीके से अपडेट किया जा सके, जिसे GraphQL endpoint के माध्यम से क्वेरी किया जा सकता है। डेवलपर्स सबग्राफ का उपयोग करके अपनी स्कीमा को परिभाषित करते हैं और ब्लॉकचेन से प्राप्त डेटा को ट्रांसफॉर्म करने के लिए एक सेट ऑफ मैपिंग्स बनाते हैं। Graph Node संपूर्ण चेन को सिंक करता है, नए ब्लॉक्स की मॉनिटरिंग करता है और इसे GraphQL endpoint के माध्यम से सर्व करता है।
 
 #### स्रोत से प्रारंभ करना
 
@@ -312,7 +312,7 @@ kubectl config use-context $(kubectl config get-contexts --output='name'
 
 - **IPFS**
 
-- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+- **उबंटू उपयोगकर्ताओं के लिए अतिरिक्त आवश्यकताएँ** - उबंटू पर ग्राफ़ नोड चलाने के लिए कुछ अतिरिक्त पैकेजों की आवश्यकता हो सकती है।
 
 ```sh
 sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
@@ -328,7 +328,7 @@ pg_ctl -D .postgres -l logfile start
 createdb graph-node
 ```
 
-2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+2. [Graph Node](https://github.com/graphprotocol/graph-node) रिपोज़िटरी को क्लोन करें और स्रोत को बिल्ड करने के लिए `cargo build` कमांड चलाएं।
 
 3. अब जब सभी निर्भरताएँ स्थापित हो गई हैं, तो ग्राफ़ नोड प्रारंभ करें:
 
@@ -371,15 +371,15 @@ docker-compose up
 
 नेटवर्क में सफलतापूर्वक भाग लेने के लिए लगभग निरंतर निगरानी और सहभागिता की आवश्यकता होती है, इसलिए हमने इंडेक्सर्स नेटवर्क भागीदारी को सुविधाजनक बनाने के लिए टाइपस्क्रिप्ट एप्लिकेशन का एक सूट बनाया है। तीन इंडेक्सर घटक हैं:
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+- **Indexer एजेंट** - यह एजेंट नेटवर्क और इंडेक्सर के अपने इंफ्रास्ट्रक्चर की निगरानी करता है और यह प्रबंधित करता है कि कौन से subgraph deployments को ऑनचेन इंडेक्स और अलोकेट किया जाए और प्रत्येक पर कितना अलोकेशन किया जाए।
 
-- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+- **Indexer सेवा** - केवल एकमात्र घटक जिसे बाहरी रूप से एक्सपोज़ किया जाना आवश्यक है, यह सेवा Subgraph queries को ग्राफ नोड पर भेजती है, क्वेरी भुगतान के लिए स्टेट चैनल्स को प्रबंधित करती है, और क्लाइंट्स जैसे गेटवे को महत्वपूर्ण निर्णय लेने की जानकारी साझा करती है।
 
-- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+- **Indexer CLI** - Indexer एजेंट को प्रबंधित करने के लिए कमांड लाइन इंटरफ़ेस। यह इंडेक्सर्स को लागत मॉडल्स, मैनुअल आवंटन, कार्यों की कतार, और इंडेक्सिंग नियमों को प्रबंधित करने की अनुमति देता है।
 
 #### शुरू करना
 
-The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+आपके Graph Node इंफ्रास्ट्रक्चर के साथ Indexer एजेंट और Indexer सेवा को सह-स्थित किया जाना चाहिए। Indexer कंपोनेंट्स के लिए वर्चुअल निष्पादन वातावरण सेटअप करने के कई तरीके हैं; यहां हम समझाएंगे कि उन्हें baremetal  पर NPM पैकेज या स्रोत का उपयोग करके कैसे चलाया जाए, या Google Cloud Kubernetes Engine पर Kubernetes और Docker के माध्यम से। यदि ये सेटअप उदाहरण आपकी इंफ्रास्ट्रक्चर पर लागू नहीं होते हैं, तो शायद एक समुदाय गाइड उपलब्ध होगा, [Discord](https://discord.gg/graphprotocol) पर आकर हमें हैलो कहें! अपने Indexer कंपोनेंट्स शुरू करने से पहले [stake in the protocol](/indexing/overview/#stake-in-the-protocol) करना न भूलें!
 
 #### From NPM packages
 
@@ -543,7 +543,7 @@ graph indexer status
 
 - `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - एक या अधिक indexing नियम सेट करें।
 
-- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+- `graph indexer rules start [options] <deployment-id>` - यदि उपलब्ध हो, तो किसी subgraph deployment को इंडेक्सिंग करना शुरू करें और इसका `decisionBasis` `always` पर सेट करें, ताकि Indexer agent हमेशा इसे इंडेक्स करने का चयन करे। यदि ग्लोबल नियम always पर सेट है, तो नेटवर्क पर सभी उपलब्ध सबग्राफ को इंडेक्स किया जाएगा।
 
 - `graph indexer rules stop [options] <deployment-id>` - किसी परिनियोजन की indexing रोकें और इसके `decisionBasis` को कभी नहीं पर सेट करें, ताकि यह deployment को index करने के निर्णय लेते समय इसे छोड़ दे।
 
@@ -563,7 +563,7 @@ graph indexer status
 
 - `graph indexer actions execute approve` - वर्कर को स्वीकृत क्रियाओं को तुरंत निष्पादित करने के लिए मजबूर करें।
 
-All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+सभी आदेश जो आउटपुट में नियम प्रदर्शित करते हैं, वे -`output` तर्क का उपयोग करके समर्थित आउटपुट प्रारूपों (`table`, `yaml`, और `json`) में से किसी एक का चयन कर सकते हैं।
 
 #### Indexing rules
 
@@ -724,13 +724,13 @@ graph indexer actions execute approve
 उदाहरण लागत मॉडल:
 
 ```
-# This statement captures the skip value,
-# uses a boolean expression in the predicate to match specific queries that use `skip`
-# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+#यह कथन skip मान को कैप्चर करता है,
+#एक बूलियन अभिव्यक्ति का उपयोग करते हुए प्रीडिकेट में उन विशिष्ट क्वेरीज़ को मिलाने के लिए जो skip का उपयोग करती हैं,
+और skip मान और SYSTEM_LOAD ग्लोबल के आधार पर लागत की गणना के लिए एक लागत अभिव्यक्ति का उपयोग करती है।
 query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
 
-# This default will match any GraphQL expression.
-# It uses a Global substituted into the expression to calculate cost
+#यह डिफ़ॉल्ट किसी भी GraphQL अभिव्यक्ति से मेल खाएगा।
+#यह लागत की गणना के लिए एक ग्लोबल का उपयोग करता है जिसे अभिव्यक्ति में प्रतिस्थापित किया गया है।
 default => 0.1 * $SYSTEM_LOAD;
 ```
 
@@ -757,7 +757,7 @@ indexer cost set model my_model.agora
 
 The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
 
-> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+> नोट: इन निर्देशों के लिए Remix का उपयोग कॉन्ट्रैक्ट इंटरैक्शन के लिए किया जाएगा, लेकिन आप अपनी पसंद के टूल का उपयोग करने के लिए स्वतंत्र हैं ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), और [MyCrypto](https://www.mycrypto.com/account) कुछ अन्य ज्ञात टूल्स हैं)।
 
 एक बार जब Indexer ने प्रोटोकॉल में GRT को staked कर दिया है, तो [Indexer components](/indexing/overview/#indexer-components) को शुरू किया जा सकता है और वे नेटवर्क के साथ अपनी बातचीत शुरू कर सकते हैं।
 
@@ -767,7 +767,7 @@ The first steps to participating in the network as an Indexer are to approve the
 
 2. `File Explorer` में एक फाइल बनाएँ जिसका नाम **GraphToken.abi** हो, और उसमें [टोकनABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json) का उपयोग करें।
 
-3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+3. `GraphToken.abi` को चुनें और इसे संपादक में खोलें, फिर Remix इंटरफ़ेस के `Deploy and run transaction` सेक्शन पर स्विच करें।
 
 4. पर्यावरण के अंतर्गत `Injected Web3` चुनें और `Account` के अंतर्गत अपना Indexer पता चुनें।
 
@@ -781,7 +781,7 @@ The first steps to participating in the network as an Indexer are to approve the
 
 2. `File Explorer` में एक फाइल बनाएं जिसका नाम **Staking.abi** हो और इसमें staking ABI हो।
 
-3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+3. `Staking.abi` को चुनकर और एडिटर में खोलने के बाद, Remix इंटरफेस में `Deploy and run transaction` सेक्शन पर स्विच करें।
 
 4. पर्यावरण के तहत `Injected Web3` का चयन करें और `Account` के तहत अपने Indexer पते का चयन करें।
 

From a9fdf5dabe5414bcaf70618d8ed5be5c9ea3f342 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 12:33:37 -0500
Subject: [PATCH 3214/3820] New translations graph-node.mdx (Hindi)

---
 website/pages/hi/indexing/tooling/graph-node.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/indexing/tooling/graph-node.mdx b/website/pages/hi/indexing/tooling/graph-node.mdx
index 57148adf7586..4af3255d314f 100644
--- a/website/pages/hi/indexing/tooling/graph-node.mdx
+++ b/website/pages/hi/indexing/tooling/graph-node.mdx
@@ -42,7 +42,7 @@ To enable monitoring and reporting, Graph Node can optionally log metrics to a P
 
 - **IPFS**
 
-- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+- **उबंटू उपयोगकर्ताओं के लिए अतिरिक्त आवश्यकताएँ** - उबंटू पर ग्राफ़ नोड चलाने के लिए कुछ अतिरिक्त पैकेजों की आवश्यकता हो सकती है।
 
 ```sh
 sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
@@ -58,7 +58,7 @@ pg_ctl -D .postgres -l logfile start
 createdb graph-node
 ```
 
-2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+2. [Graph Node](https://github.com/graphprotocol/graph-node) रिपोज़िटरी को क्लोन करें और स्रोत को बिल्ड करने के लिए `cargo build` कमांड चलाएं।
 
 3. अब जब सभी निर्भरताएँ स्थापित हो गई हैं, तो ग्राफ़ नोड प्रारंभ करें:
 

From f70676d064ace08542d1b42e03fa7eaa9ce4b336 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:34 -0500
Subject: [PATCH 3215/3820] New translations overview.mdx (Hindi)

---
 website/pages/hi/indexing/overview.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/hi/indexing/overview.mdx b/website/pages/hi/indexing/overview.mdx
index 0a3082bef375..d9b3eb6b8680 100644
--- a/website/pages/hi/indexing/overview.mdx
+++ b/website/pages/hi/indexing/overview.mdx
@@ -43,7 +43,7 @@ RewardsManager कॉन्ट्रैक्ट में एक read-only getR
 
 कई समुदाय-निर्मित डैशबोर्ड में लंबित पुरस्कार मान शामिल हैं और इन चरणों का पालन करके उन्हें आसानी से मैन्युअल रूप से चेक किया जा सकता है:
 
-1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+1. [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) को क्वेरी करें ताकि सभी 'active allocations' के लिए IDs प्राप्त की जा सकें।
 
 ```graphql
 query indexerAllocations {
@@ -134,7 +134,7 @@ An Indexer की इंफ्रास्ट्रक्चर के कें
 
 - PostgreSQL डेटाबेस - यह Graph Node के लिए मुख्य स्टोर है, जहां subgraph डेटा संग्रहीत किया जाता है। Indexer सेवा और एजेंट भी डेटाबेस का उपयोग state channel डेटा, लागत मॉडल, indexing नियम, और आवंटन क्रियाओं को संग्रहीत करने के लिए करते हैं।
 
-- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+- डेटा एंडपॉइंट -EVM-संगत नेटवर्क्स के लिए, Graph Node को एक ऐसे एन्डपॉइंट से कनेक्ट होना चाहिए जो EVM-संगत JSON-RPC API प्रदान करता हो। यह एक सिंगल क्लाइंट के रूप में हो सकता है या एक अधिक जटिल सेटअप हो सकता है जो कई क्लाइंट्स के बीच लोड को बैलेंस करता है। यह जानना महत्वपूर्ण है कि कुछ subgraphs को विशेष क्लाइंट क्षमताओं की आवश्यकता हो सकती है, जैसे कि आर्काइव मोड और/या parity tracing API।
 
 - IPFS नोड (संस्करण 5 से कम) - सबग्राफ डिप्लॉयमेंट मेटाडेटा IPFS नेटवर्क पर संग्रहीत होता है। The Graph Node मुख्य रूप से सबग्राफ डिप्लॉयमेंट के दौरान IPFS नोड का उपयोग करता है ताकि सबग्राफ मैनिफेस्ट और सभी लिंक की गई फाइल्स को प्राप्त किया जा सके। नेटवर्क Indexers को अपना स्वयं का IPFS नोड होस्ट करने की आवश्यकता नहीं होती है, नेटवर्क के लिए एक IPFS नोड https://ipfs.network.thegraph.com पर होस्ट किया गया है।
 
@@ -787,7 +787,7 @@ The first steps to participating in the network as an Indexer are to approve the
 
 5. Staking contract address सेट करें - Staking contract address (0xF55041E37E12cD407ad00CE2910B8269B01263b9) को `At Address` के पास पेस्ट करें और `At address` बटन पर क्लिक करें ताकि इसे लागू किया जा सके।
 
-6. Call `stake()` to stake GRT in the protocol.
+6. `stake()` को कॉल करें ताकि प्रोटोकॉल में GRT staking किया जा सके।
 
 7. (ऐच्छिक) Indexer अपने Indexer इंफ्रास्ट्रक्चर के लिए किसी अन्य पते को ऑपरेटर के रूप में अनुमोदित कर सकते हैं, ताकि वे फंड्स को नियंत्रित करने वाली चाबियों को उन चाबियों से अलग कर सकें जो रोज़मर्रा के कार्यों को अंजाम देती हैं जैसे कि सबग्राफ पर आवंटन और (भुगतान) queries सर्व करना। ऑपरेटर सेट करने के लिए `setOperator()` को ऑपरेटर पते के साथ कॉल करें।
 
@@ -817,8 +817,8 @@ To set the delegation parameters using Graph Explorer interface, follow these st
 
 एक Indexer द्वारा बनाए जाने के बाद, एक स्वस्थ आवंटन दो स्थितियों से गुजरता है।
 
-- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **सक्रिय** - जब एक आवंटन ऑनचेन [(allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) बनाया जाता है, तो इसे **सक्रिय** माना जाता है। Indexer की अपनी और/या प्रत्यायोजित स्टेक का एक हिस्सा एक subgraph डिप्लॉयमेंट के लिए आवंटित किया जाता है, जिससे उन्हें उस subgraph डिप्लॉयमेंट के लिए indexing पुरस्कार प्राप्त करने और प्रश्नों की सेवा करने की अनुमति मिलती है। Indexer एजेंट Indexer नियमों के आधार पर आवंटन बनाने का प्रबंधन करता है।
 
-- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+- **Closed** - एक Indexer 1 अवधियों को के बाद एक allocation को बंद करने के लिए स्वतंत्र है (closeAllocation()(https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) या उनका Indexer एजेंट स्वतः **maxAllocationEpochs** (वर्तमान में 28 दिन) के बाद allocation को बंद कर देगा। जब एक allocation को एक वैध proof of indexing (POI) के साथ बंद किया जाता है, तो उनके indexing पुरस्कार Indexer और उसके Delegators को वितरित किए जाते हैं [(learn more)](/indexing/overview/#how-are-indexing-rewards-distributed))।
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Indexer को अनुशंसा की जाती है कि वे ऑनचेन पर आवंटन बनाने से पहले चेनहेड तक Subgraph डिप्लॉयमेंट को सिंक करने के लिए ऑफचेन सिंकिंग फ़ंक्शनलिटी का उपयोग करें। यह विशेषता उन सबग्राफ़्स के लिए विशेष रूप से उपयोगी है जिन्हें सिंक होने में 28 अवधियों को अधिक समय लग सकता है या जिनमें अव्यक्त रूप से विफल होने की संभावना हो सकती है।

From fbbdb875cc281519a2391a6db2715066d6673de5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:35 -0500
Subject: [PATCH 3216/3820] New translations graph-node.mdx (Hindi)

---
 .../pages/hi/indexing/tooling/graph-node.mdx  | 62 +++++++++----------
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/website/pages/hi/indexing/tooling/graph-node.mdx b/website/pages/hi/indexing/tooling/graph-node.mdx
index 4af3255d314f..37ed3a04a2fc 100644
--- a/website/pages/hi/indexing/tooling/graph-node.mdx
+++ b/website/pages/hi/indexing/tooling/graph-node.mdx
@@ -4,13 +4,13 @@ title: ग्राफ-नोड
 
 Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
 
-This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+ग्राफ-नोड का संदर्भ और indexers के लिए उपलब्ध कुछ उन्नत विकल्पों का परिचय प्रदान करता है। विस्तृत दस्तावेज़ और निर्देश [Graph Node repository](https://github.com/graphprotocol/graph-node) में पाए जा सकते हैं।
 
 ## ग्राफ-नोड
 
-[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+[Graph Node](https://github.com/graphprotocol/graph-node) The Graph Network पर सबग्राफ को indexing करने के लिए रेफरेंस इंप्लीमेंटेशन है, जो ब्लॉकचेन क्लाइंट्स से जुड़ता है, सबग्राफ को indexing करता है और इंडेक्स किए गए डेटा को queries के लिए उपलब्ध कराता है।
 
-Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+Graph Node (और पूरा indexer stack) को bare metal पर या एक cloud environment में चलाया जा सकता है। The Graph Protocol की मजबूती के लिए केंद्रीय indexing घटक की यह लचीलापन बहुत महत्वपूर्ण है। इसी तरह, ग्राफ-नोड को [साधन से बनाया जा सकता](https://github.com/graphprotocol/graph-node) है, या indexers [प्रदत्त Docker Images](https://hub.docker.com/r/graphprotocol/graph-node) में से एक का उपयोग कर सकते हैं।
 
 ### पोस्टग्रेएसक्यूएल डेटाबेस
 
@@ -20,9 +20,9 @@ The main store for the Graph Node, this is where subgraph data is stored, as wel
 
 किसी नेटवर्क को इंडेक्स करने के लिए, ग्राफ़ नोड को एथेरियम-संगत JSON-RPC के माध्यम से नेटवर्क क्लाइंट तक पहुंच की आवश्यकता होती है। यह आरपीसी एक एथेरियम क्लाइंट से जुड़ सकता है या यह एक अधिक जटिल सेटअप हो सकता है जो कई में संतुलन लोड करता है।
 
-While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+कुछ सबग्राफ को केवल एक पूर्ण नोड की आवश्यकता हो सकती है, लेकिन कुछ में indexing फीचर्स होते हैं, जिनके लिए अतिरिक्त RPC कार्यक्षमता की आवश्यकता होती है। विशेष रूप से, ऐसे सबग्राफ जो indexing के हिस्से के रूप में `eth_calls` करते हैं, उन्हें एक आर्काइव नोड की आवश्यकता होगी जो [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898) को सपोर्ट करता हो। साथ ही, ऐसे सबग्राफ जिनमें `callHandlers` या `blockHandlers` के साथ एक `call` फ़िल्टर हो, उन्हें `trace_filter` सपोर्ट की आवश्यकता होती है ([trace module documentation यहां देखें](https://openethereum.github.io/JSONRPC-trace-module))।
 
-**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+**नेटवर्क फायरहोज़** - फायरहोज़ एक gRPC सेवा है जो ब्लॉक्स का क्रमबद्ध, फिर भी फोर्क-अवेयर स्ट्रीम प्रदान करती है। इसे The Graph के कोर डेवलपर्स द्वारा बड़े पैमाने पर प्रभावी indexing का समर्थन करने के लिए विकसित किया गया है। यह वर्तमान में Indexer के लिए अनिवार्य नहीं है, लेकिन Indexers को इस तकनीक से परिचित होने के लिए प्रोत्साहित किया जाता है ताकि वे नेटवर्क के पूर्ण समर्थन के लिए तैयार रहें। फायरहोज़ के बारे में अधिक जानें [यहां](https://firehose.streamingfast.io/)।
 
 ### आईपीएफएस नोड्स
 
@@ -85,13 +85,13 @@ When it is running Graph Node exposes the following ports:
 | 8030 | Subgraph indexing status API                       | /graphql                                       | \--index-node-port | -                    |
 | 8040 | Prometheus metrics                                 | /metrics                                       | \--metrics-port    | -                    |
 
-> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+> **प्रमुख बात**: सार्वजनिक रूप से पोर्ट्स को एक्सपोज़ करने में सावधानी बरतें - \*\*प्रशासनिक पोर्ट्स को लॉक रखना चाहिए। इसमें ग्राफ नोड JSON-RPC एंडपॉइंट भी शामिल है।
 
 ## Advanced Graph Node configuration
 
 At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
 
-This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+इस सेटअप को क्षैतिज रूप से स्केल किया जा सकता है, कई Graph नोड और उन Graph नोड को समर्थन देने के लिए कई डेटाबेस जोड़कर। उन्नत उपयोगकर्ता ग्राफ-नोड की कुछ क्षैतिज स्केलिंग क्षमताओं का लाभ उठाना चाह सकते हैं, साथ ही कुछ अधिक उन्नत कॉन्फ़िगरेशन विकल्पों का भी, `config.toml` फ़ाइल और ग्राफ-नोड के पर्यावरण वेरिएबल्स के माध्यम से।
 
 ### `config.toml`
 
@@ -114,13 +114,13 @@ indexers = [ "<.. list of all indexing nodes ..>" ]
 
 #### Multiple Graph Nodes
 
-Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+ग्राफ-नोड indexing को क्षैतिज रूप से स्केल किया जा सकता है, कई ग्राफ-नोड instances चलाकर indexing और queries को विभिन्न नोड्स पर विभाजित किया जा सकता है। यह सरलता से किया जा सकता है, जब Graph नोड को एक अलग `node_id` के साथ शुरू किया जाता है (जैसे कि Docker Compose फ़ाइल में), जिसे फिर `config.toml` फ़ाइल में [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion) को निर्दिष्ट करने के लिए और [deployment rules](#deployment-rules) के साथ सबग्राफ को नोड्स के बीच विभाजित करने के लिए इस्तेमाल किया जा सकता है।
 
 > ध्यान दें कि एक ही डेटाबेस का उपयोग करने के लिए कई ग्राफ़ नोड्स को कॉन्फ़िगर किया जा सकता है, जिसे स्वयं शार्डिंग के माध्यम से क्षैतिज रूप से बढ़ाया जा सकता है।
 
 #### Deployment rules
 
-Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+यहां कई Graph नोड दिए गए हैं, इसलिए नए सबग्राफ की तैनाती का प्रबंधन करना आवश्यक है ताकि एक ही subgraph को दो विभिन्न नोड द्वारा इंडेक्स न किया जाए, क्योंकि इससे टकराव हो सकता है। यह deployment नियमों का उपयोग करके किया जा सकता है, जो यह भी निर्दिष्ट कर सकते हैं कि यदि डेटाबेस sharding का उपयोग किया जा रहा है, तो subgraph का डेटा किस `shard` में स्टोर किया जाना चाहिए। Deployment नियम subgraph के नाम और उस नेटवर्क पर मिलान कर सकते हैं जिसमें तैनाती indexing हो रही है, ताकि निर्णय लिया जा सके।
 
 Example deployment rule configuration:
 
@@ -167,7 +167,7 @@ Any node whose --node-id matches the regular expression will be set up to only r
 
 For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
 
-Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+Shard का उपयोग subgraph deployments को कई डेटाबेस में विभाजित करने के लिए किया जा सकता है, और प्रतिकृति का उपयोग करके query लोड को डेटाबेस में फैलाने के लिए भी किया जा सकता है। इसमें यह कॉन्फ़िगर करना शामिल है कि प्रत्येक डेटाबेस के लिए प्रत्येक `ग्राफ-नोड` को अपने कनेक्शन पूल में कितने उपलब्ध डेटाबेस कनेक्शन रखने चाहिए। जैसे-जैसे अधिक सबग्राफ को index किया जा रहा है, यह अधिक महत्वपूर्ण होता जा रहा है।
 
 शेयरिंग तब उपयोगी हो जाती है जब आपका मौजूदा डेटाबेस ग्राफ़ नोड द्वारा डाले गए भार के साथ नहीं रह सकता है, और जब डेटाबेस का आकार बढ़ाना संभव नहीं होता है।
 
@@ -179,7 +179,7 @@ In terms of configuring connections, start with max_connections in postgresql.co
 
 #### Dedicated block ingestion
 
-If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+यदि कई नोड्स कॉन्फ़िगर किए गए हैं, तो यह आवश्यक होगा कि एक नोड निर्दिष्ट किया जाए जो नए ब्लॉक्स के इनजेशन के लिए जिम्मेदार हो, ताकि सभी कॉन्फ़िगर किए गए इंडेक्स नोड्स chain हेड को बार-बार पूछताछ न करें। इसे `chains` नेमस्पेस के हिस्से के रूप में किया जाता है, जहां ब्लॉक इनजेशन के लिए उपयोग किए जाने वाले `node_id` को निर्दिष्ट किया जाता है:
 
 ```toml
 [chains]
@@ -188,13 +188,13 @@ ingestor = "block_ingestor_node"
 
 #### Supporting multiple networks
 
-The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+The Graph Protocol उन नेटवर्क्स की संख्या बढ़ा रहा है जो indexing रिवार्ड्स के लिए सपोर्टेड हैं, और ऐसे कई सबग्राफ हैं जो अनसपोर्टेड नेटवर्क्स को indexing कर रहे हैं जिन्हें एक indexer प्रोसेस करना चाहेगा। `config.toml` फ़ाइल अभिव्यक्त और लचीली कॉन्फ़िगरेशन की अनुमति देती है:
 
 - Multiple networks
 - Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
 - Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
 
-The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+`[chains]` अनुभाग उन Ethereum प्रदाताओं को नियंत्रित करता है जिनसे ग्राफ-नोड कनेक्ट होता है और जहाँ प्रत्येक chain के लिए ब्लॉक और अन्य मेटाडेटा संग्रहीत होते हैं। निम्नलिखित उदाहरण दो chain, mainnet और kovan को कॉन्फ़िगर करता है, जहाँ mainnet के लिए ब्लॉक vip shard में संग्रहीत होते हैं और kovan के लिए ब्लॉक primary shard में संग्रहीत होते हैं। mainnet chain दो अलग-अलग प्रदाताओं का उपयोग कर सकती है, जबकि kovan के पास केवल एक प्रदाता है।
 
 ```toml
 [chains]
@@ -214,14 +214,14 @@ provider = [ { label = "kovan", url = "http://..", features = [] } ]
 
 ### Environment variables
 
-Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+ग्राफ-नोड कई environment variables का समर्थन करता है, जो सुविधाओं को सक्षम कर सकते हैं या ग्राफ-नोड के व्यवहार को बदल सकते हैं। इन्हें [यहाँ](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md) प्रलेखित किया गया है।
 
 ### Continuous deployment
 
 जो उपयोगकर्ता उन्नत कॉन्फ़िगरेशन के साथ एक स्केल्ड इंडेक्सिंग सेटअप का संचालन कर रहे हैं, वे कुबेरनेट्स के साथ अपने ग्राफ़ नोड्स को प्रबंधित करने से लाभान्वित हो सकते हैं।
 
 - Indexer रिपॉजिटरी में एक [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s) उपलब्ध है।
-- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) एक टूलकिट है जो Kubernetes पर Graph Protocol Indexer को चलाने के लिए GraphOps द्वारा मेंटेन किया जाता है। यह Helm चार्ट्स और एक CLI का सेट प्रदान करता है जो ग्राफ-नोड डिप्लॉयमेंट को प्रबंधित करने के लिए उपयोग किया जाता है।
 
 ### Managing Graph Node
 
@@ -229,23 +229,23 @@ Given a running Graph Node (or Graph Nodes!), the challenge is then to manage de
 
 #### लॉगिंग
 
-Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+ग्राफ-नोड के log डिबगिंग और ग्राफ-नोड और विशिष्ट सबग्राफ के ऑप्टिमाइजेशन के लिए उपयोगी जानकारी प्रदान कर सकते हैं। ग्राफ-नोड विभिन्न log स्तरों का समर्थन करता है via `GRAPH_LOG` पर्यावरण चर, जिनमें निम्नलिखित स्तर होते हैं: error, warn, info, debug या trace।
 
-In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+GraphQL queries कैसे चल रही हैं, इस बारे में अधिक विवरण प्राप्त करने के लिए `GRAPH_LOG_QUERY_TIMING` को `gql` पर सेट करना उपयोगी हो सकता है (हालांकि इससे बड़ी मात्रा में लॉग उत्पन्न होंगे)।
 
 #### निगरानी और सतर्कता
 
 ग्राफ़ नोड डिफ़ॉल्ट रूप से 8040 पोर्ट पर प्रोमेथियस एंडपॉइंट के माध्यम से मेट्रिक्स प्रदान करता है। इन मेट्रिक्स की कल्पना करने के लिए ग्राफाना का उपयोग किया जा सकता है।
 
-The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+Indexer रिपॉजिटरी एक [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml) प्रदान करती है।
 
 #### Graphman
 
-`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+`graphman` एक maintenance टूल है ग्राफ-नोड के लिए, जो विभिन्न दैनिक और असाधारण कार्यों के निदान और समाधान में मदद करता है।
 
-The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+The graphman कमांड आधिकारिक कंटेनरों में शामिल है, और आप अपने ग्राफ-नोड कंटेनर में docker exec कमांड का उपयोग करके इसे चला सकते हैं। इसके लिए एक `config.toml` फ़ाइल की आवश्यकता होती है।
 
-Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+`graphman` कमांड्स का पूरा दस्तावेज़ ग्राफ नोड रिपॉजिटरी में उपलब्ध है।  ग्राफ नोड `/docs` में [/docs/graphman.md](https://github.com/graphprotocol/ग्राफ-नोड/blob/master/docs/graphman.md) देखें।
 
 ### सबग्राफ के साथ काम करना
 
@@ -267,8 +267,8 @@ These stages are pipelined (i.e. they can be executed in parallel), but they are
 
 Common causes of indexing slowness:
 
-- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
-- Making large numbers of `eth_calls` as part of handlers
+- Chain से प्रासंगिक आयोजन खोजने में लगने वाला समय (विशेष रूप से कॉल handler धीमे हो सकते हैं, क्योंकि ये `trace_filter` पर निर्भर करते हैं)।
+- Handler के हिस्से के रूप में बड़ी संख्या में `eth_calls` करना।
 - A large amount of store interaction during execution
 - A large amount of data to save to the store
 - A large number of events to process
@@ -287,13 +287,13 @@ During indexing subgraphs might fail, if they encounter data that is unexpected,
 
 In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
 
-> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+> निश्चितात्मक विफलताएँ "अंतिम" मानी जाती हैं, जिनके लिए विफल ब्लॉक के लिए एक Proof of Indexing उत्पन्न किया जाता है, जबकि अनिर्णायक विफलताएँ नहीं होतीं, क्योंकि Subgraph "अविफल" हो सकता है और indexing जारी रख सकता है। कुछ मामलों में, अनिर्णायक लेबल गलत होता है, और Subgraph कभी भी त्रुटि को पार नहीं कर पाएगा; ऐसी विफलताओं को ग्राफ नोड रिपॉजिटरी पर मुद्दों के रूप में रिपोर्ट किया जाना चाहिए।
 
 #### कैश को ब्लॉक और कॉल करें
 
-Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+ग्राफ-नोड कुछ डेटा को स्टोर में कैश करता है ताकि प्रोवाइडर से फिर से प्राप्त करने की आवश्यकता न हो। ब्लॉक्स को कैश किया जाता है, साथ ही `eth_calls` के परिणाम (जो कि एक विशिष्ट ब्लॉक से कैश किए जाते हैं)। यह कैशिंग "थोड़े बदले हुए subgraph" के दौरान indexing की गति को नाटकीय रूप से बढ़ा सकती है।
 
-However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+यदि कभी Ethereum नोड ने किसी समय अवधि के लिए गलत डेटा प्रदान किया है, तो वह कैश में जा सकता है, जिसके परिणामस्वरूप गलत डेटा या विफल सबग्राफ हो सकते हैं। इस स्थिति में, Indexer `graphman` का उपयोग करके ज़हरीले कैश को हटा सकते हैं, और फिर प्रभावित सबग्राफ को रीवाइंड कर सकते हैं, जो फिर (आशा है) स्वस्थ प्रदाता से ताज़ा डेटा प्राप्त करेंगे।
 
 If a block cache inconsistency is suspected, such as a tx receipt missing event:
 
@@ -312,7 +312,7 @@ Once a subgraph has been indexed, indexers can expect to serve queries via the s
 
 ##### क्वेरी कैशिंग
 
-Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+ग्राफ-नोड डिफ़ॉल्ट रूप से GraphQL queries को कैश करता है, जिससे डेटाबेस लोड को काफी हद तक कम किया जा सकता है। इसे `GRAPH_QUERY_CACHE_BLOCKS` और `GRAPH_QUERY_CACHE_MAX_MEM` सेटिंग्स के साथ और अधिक कॉन्फ़िगर किया जा सकता है - अधिक पढ़ें [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching)।
 
 ##### Analysing queries
 
@@ -320,7 +320,7 @@ Problematic queries most often surface in one of two ways. In some cases, users
 
 अन्य मामलों में, क्वेरी नोड पर ट्रिगर उच्च मेमोरी उपयोग हो सकता है, इस मामले में सबसे पहले समस्या उत्पन्न करने वाली क्वेरी की पहचान करना चुनौती है।
 
-Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+Indexers [qlog](https://github.com/graphprotocol/qlog/) का उपयोग करके ग्राफ-नोड के query logs को प्रोसेस और सारांशित कर सकते हैं। धीमे queries की पहचान और डिबग करने में मदद के लिए `GRAPH_LOG_QUERY_TIMING` को भी सक्षम किया जा सकता है।
 
 Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
 
@@ -330,13 +330,13 @@ Database tables that store entities seem to generally come in two varieties: 'tr
 
 अकाउंट-जैसी तालिकाओं के लिए, `ग्राफ-नोड` ऐसे queries जनरेट कर सकता है जो इस विवरण का लाभ उठाते हैं कि Postgres इतनी तेज़ दर पर डेटा स्टोर करते समय इसे कैसे प्रबंधित करता है। खासतौर पर, हाल के ब्लॉक्स के सभी संस्करण ऐसी तालिका के कुल स्टोरेज के एक छोटे से हिस्से में होते हैं।
 
-The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+कमांड `graphman stats show <sgdNNNN`> प्रत्येक डिप्लॉयमेंट में मौजूद entities प्रकार/टेबल के लिए यह दिखाता है कि प्रत्येक टेबल में कितनी अलग-अलग entities और कितने entities वर्ज़न हैं। यह डेटा Postgres के आंतरिक अनुमानों पर आधारित होता है, और इसलिए यह अनिवार्य रूप से सटीक नहीं होता है और इसमें एक ऑर्डर ऑफ मैग्निट्यूड तक का अंतर हो सकता है। `entities` कॉलम में `-1` का मतलब है कि Postgres मानता है कि सभी पंक्तियां एक अलग entities को शामिल करती हैं।
 
-In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+सामान्यतः, वे तालिकाएँ जहाँ विशिष्ट entities की संख्या कुल पंक्तियों/entities संस्करणों की संख्या का 1% से कम हो, वे खाता-जैसा अनुकूलन के लिए अच्छे उम्मीदवार होती हैं। जब `graphman stats show` का आउटपुट यह दर्शाता है कि कोई तालिका इस optimization से लाभ उठा सकती है, तो `graphman stats show <sgdNNN> <table>` चलाने पर तालिका की पूरी गणना की जाती है - यह धीमा हो सकता है, लेकिन विशिष्ट entities और कुल entities संस्करणों के अनुपात का सटीक माप प्रदान करता है।
 
 एक बार जब यह तय कर लिया जाता है कि एक तालिका खाता जैसी है, तो `graphman stats account-like <sgdNNN>.<table>` चलाने से उस तालिका के खिलाफ queries के लिए खाता जैसी अनुकूलन सक्षम हो जाएगा। इस अनुकूलन को फिर से बंद किया जा सकता है `graphman stats account-like --clear <sgdNNN>.<table>` के साथ। queries नोड्स को यह नोटिस करने में 5 मिनट तक का समय लग सकता है कि अनुकूलन को चालू या बंद किया गया है। अनुकूलन को चालू करने के बाद, यह सत्यापित करना आवश्यक है कि बदलाव वास्तव में उस तालिका के लिए queries को धीमा नहीं कर रहा है। यदि आपने Grafana को Postgres की निगरानी के लिए कॉन्फ़िगर किया है, तो धीमी queries `pg_stat_activity` में बड़ी संख्या में दिखाई देंगी, जो कई सेकंड ले रही हैं। ऐसे में, अनुकूलन को फिर से बंद करने की आवश्यकता होती है।
 
-For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+Uniswap- जैसे सबग्राफ़ के लिए, `pair` और `token` तालिकाएँ इस अनुकूलन के प्रमुख उम्मीदवार हैं, और ये डेटाबेस लोड पर नाटकीय प्रभाव डाल सकते हैं।
 
 #### सबग्राफ हटाना
 

From a8ed774ba885712932c4373e95bb41ca1e94b6b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:36 -0500
Subject: [PATCH 3217/3820] New translations tap.mdx (Hindi)

---
 website/pages/hi/indexing/tap.mdx | 75 ++++++++++++++++---------------
 1 file changed, 38 insertions(+), 37 deletions(-)

diff --git a/website/pages/hi/indexing/tap.mdx b/website/pages/hi/indexing/tap.mdx
index 0e06f8995a3e..68567f92acc5 100644
--- a/website/pages/hi/indexing/tap.mdx
+++ b/website/pages/hi/indexing/tap.mdx
@@ -9,7 +9,7 @@ The Graph के नए भुगतान प्रणाली, Timeline Aggre
 [TAP](https://docs.rs/tap_core/latest/tap_core/index.html) मौजूदा Scalar भुगतान प्रणाली का एक ड्रॉप-इन प्रतिस्थापन है। यह निम्नलिखित प्रमुख सुविधाएँ प्रदान करता है:
 
 - सूक्ष्म भुगतानों को कुशलता से संभालता है।
-- Adds a layer of consolidations to onchain transactions and costs.
+- ऑनचेन लेनदेन और लागतों में समेकन की एक परत जोड़ता है।
 - प्राप्तियों और भुगतान पर Indexers को नियंत्रण की अनुमति देता है, प्रश्नों के लिए भुगतान की गारंटी देता है।
 - यह विकेन्द्रीकृत, विश्वास रहित गेटवे को सक्षम बनाता है और कई भेजने वालों के लिए indexer-service के प्रदर्शन में सुधार करता है।
 
@@ -99,79 +99,80 @@ TAP एक प्रेषक को एक प्राप्तकर्ता
 "कम से कम कॉन्फ़िगरेशन के लिए, निम्नलिखित टेम्पलेट का उपयोग करें:"
 
 ```bash
-# You will have to change *all* the values below to match your setup.
+#आपको नीचे दिए गए *सभी* मान अपनी सेटअप के अनुसार बदलने होंगे।
+*नीचे दिए गए कुछ कॉन्फ़िग वैल्यू ग्लोबल ग्राफ नेटवर्क वैल्यू हैं, जिन्हें आप यहां पा सकते हैं:
 #
-# Some of the config below are global graph network values, which you can find here:
-# <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
+<https://github.com/graphprotocol/indexer/tree/main/docs/networks>
 #
-# Pro tip: if you need to load some values from the environment into this config, you
-# can overwrite with environment variables. For example, the following can be replaced
-# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
-#
-# [database]
-# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
-
+#प्रो टिप: यदि आपको इस कॉन्फ़िग में कुछ मान environment से लोड करने की आवश्यकता है, तो आप environment वेरिएबल्स का उपयोग करके ओवरराइट कर सकते हैं। उदाहरण के लिए, निम्नलिखित को [PREFIX]_DATABASE_POSTGRESURL से बदला जा सकता है, जहां PREFIX `INDEXER_SERVICE` या `TAP_AGENT` हो सकता है:
+[database]
+#postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
 [indexer]
 indexer_address = "0x1111111111111111111111111111111111111111"
 operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
 
 [database]
-# The URL of the Postgres database used for the indexer components. The same database
-# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
-# the necessary tables.
+
+Postgres डेटाबेस का URL जो indexer components के लिए उपयोग किया जाता है। वही डेटाबेस
+जो indexer-agent द्वारा उपयोग किया जाता है। यह अपेक्षित है कि indexer-agent आवश्यक तालिकाएं बनाएगा।
 postgres_url = "postgres://postgres@postgres:5432/postgres"
 
 [graph_node]
-# URL to your graph-node's query endpoint
+आपके graph-node के क्वेरी एंडपॉइंट का URL
 query_url = "<http://graph-node:8000>"
-# URL to your graph-node's status endpoint
+
+आपके graph-node के स्टेटस एंडपॉइंट का URL
 status_url = "<http://graph-node:8000/graphql>"
 
 [subgraphs.network]
-# Query URL for the Graph Network subgraph.
+Graph Network subgraph के लिए क्वेरी URL।
 query_url = "<http://example.com/network-subgraph>"
-# Optional, deployment to look for in the local `graph-node`, if locally indexed.
-# Locally indexing the subgraph is recommended.
-# NOTE: Use `query_url` or `deployment_id` only
+
+वैकल्पिक, local graph-node में देखने के लिए deployment, यदि स्थानीय रूप से इंडेक्स किया गया है।
+subgraph को स्थानीय रूप से इंडेक्स करना अनुशंसित है।
+नोट: केवल query_url या deployment_id का उपयोग करें
 deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
 
 [subgraphs.escrow]
-# Query URL for the Escrow subgraph.
+Escrow subgraph के लिए क्वेरी URL।
 query_url = "<http://example.com/network-subgraph>"
-# Optional, deployment to look for in the local `graph-node`, if locally indexed.
-# Locally indexing the subgraph is recommended.
-# NOTE: Use `query_url` or `deployment_id` only
+
+वैकल्पिक, local graph-node में देखने के लिए deployment, यदि स्थानीय रूप से इंडेक्स किया गया है।
+subgraph को स्थानीय रूप से इंडेक्स करना अनुशंसित है।
+नोट: केवल query_url या deployment_id का उपयोग करें
 deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
 
 [blockchain]
-# The chain ID of the network that the graph network is running on
+
+उस नेटवर्क का chain ID जिस पर graph network चल रहा है
 chain_id = 1337
-# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
+
+TAP के receipt aggregate voucher (RAV) verifier का कॉन्ट्रैक्ट एड्रेस।
 receipts_verifier_address = "0x2222222222222222222222222222222222222222"
 
 ########################################
-# Specific configurations to tap-agent #
+#tap-agent के लिए विशिष्ट कॉन्फ़िगरेशन#
 ########################################
 [tap]
-# This is the amount of fees you are willing to risk at any given time. For ex.
-# if the sender stops supplying RAVs for long enough and the fees exceed this
-# amount, the indexer-service will stop accepting queries from the sender
-# until the fees are aggregated.
-# NOTE: Use strings for decimal values to prevent rounding errors
-# e.g:
-# max_amount_willing_to_lose_grt = "0.1"
+#यह वह फीस की मात्रा है जिसे आप किसी भी समय जोखिम में डालने के लिए तैयार हैं। उदाहरण के लिए,
+#यदि sender लंबे समय तक RAVs प्रदान करना बंद कर देता है और फीस इस
+#राशि से अधिक हो जाती है, तो indexer-service sender से क्वेरी स्वीकार करना बंद कर देगा
+#जब तक कि फीस को समेकित नहीं किया जाता।
+#नोट: राउंडिंग त्रुटियों से बचने के लिए दशमलव मानों के लिए strings का उपयोग करें
+#जैसे:
+#max_amount_willing_to_lose_grt = "0.1"
 max_amount_willing_to_lose_grt = 20
 
 [tap.sender_aggregator_endpoints]
-# Key-Value of all senders and their aggregator endpoints
-# This one below is for the E&N testnet gateway for example.
+सभी senders और उनके aggregator endpoints के key-value
+नीचे दिया गया यह उदाहरण E&N टेस्टनेट गेटवे के लिए है।
 0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
 ```
 
 टिप्पणियाँ:
 
 - tap.sender_aggregator_endpoints के लिए मान gateway section(/indexing/tap/#gateway) में पाए जा सकते हैं।
-- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+- Blockchain.receipts_verifier_address के लिए मानों का उपयोग ब्लॉकचेन एड्रेस सेक्शन(/indexing/tap/#contracts) के अनुसार सही चेन आईडी का उपयोग करते हुए किया जाना चाहिए।
 
 **लॉग स्तर**
 

From 8ba2c16a43e85cb0b4442999eb01febfcd32dc7d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:37 -0500
Subject: [PATCH 3218/3820] New translations about.mdx (Hindi)

---
 website/pages/hi/about.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/about.mdx b/website/pages/hi/about.mdx
index 1e99e4584845..6dc30fe86bb9 100644
--- a/website/pages/hi/about.mdx
+++ b/website/pages/hi/about.mdx
@@ -2,7 +2,7 @@
 title: The Graph के बारे में
 ---
 
-## What is The Graph?
+## The Graph क्या है?
 
 The Graph एक शक्तिशाली विकेंद्रीकृत प्रोटोकॉल है जो ब्लॉकचेन डेटा को आसानी से क्वेरी और इंडेक्स करने में सक्षम बनाता है। यह ब्लॉकचेन डेटा को क्वेरी करने की जटिल प्रक्रिया को सरल बनाता है, जिससे डैप विकास तेज और आसान हो जाता है।
 

From 4a8abe91f0b155c4d748340e0416925920d49ffc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:39 -0500
Subject: [PATCH 3219/3820] New translations delegating.mdx (Hindi)

---
 website/pages/hi/resources/roles/delegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/resources/roles/delegating.mdx b/website/pages/hi/resources/roles/delegating.mdx
index 9e5eda876cde..f7b30c6fff84 100644
--- a/website/pages/hi/resources/roles/delegating.mdx
+++ b/website/pages/hi/resources/roles/delegating.mdx
@@ -100,7 +100,7 @@ As a result, it’s recommended that you choose an Indexer wisely.
   बीच वाला Delegators को 20% दे रहा है। सबसे नीचे वाला Delegators को लगभग 83% दे रहा है।* 
 </div>
 
-- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+- \*\*पूछताछ शुल्क कटौती - यह बिल्कुल Indexing Reward Cut की तरह है, लेकिन यह उन पूछताछ शुल्क पर लागू होता है जो Indexer एकत्र करता है।
 
 - It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 

From 8eab1edb8e129ad98fe7d4bea4427ad165a7f50e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:40 -0500
Subject: [PATCH 3220/3820] New translations advanced.mdx (Hindi)

---
 .../developing/creating/advanced.mdx          | 30 +++++++++----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/hi/subgraphs/developing/creating/advanced.mdx b/website/pages/hi/subgraphs/developing/creating/advanced.mdx
index f6e33f4d3b44..769cdb5a3253 100644
--- a/website/pages/hi/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/hi/subgraphs/developing/creating/advanced.mdx
@@ -85,13 +85,13 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 
 Timeseries और Aggregations का उपयोग करने के लिए, एक subgraph का spec version ≥1.1.0 होना चाहिए। ध्यान दें कि यह सुविधा महत्वपूर्ण परिवर्तनों का सामना कर सकती है जो पीछे की संगतता को प्रभावित कर सकती है।
 
-[Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
+[और पढ़ें](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) समय श्रृंखला और संक्षेपण के बारे में।
 
 ## गैर-घातक त्रुटियाँ
 
 पहले से सिंक किए गए सबग्राफ पर इंडेक्सिंग त्रुटियां, डिफ़ॉल्ट रूप से, सबग्राफ को विफल कर देंगी और सिंक करना बंद कर देंगी। सबग्राफ को वैकल्पिक रूप से त्रुटियों की उपस्थिति में समन्वयन जारी रखने के लिए कॉन्फ़िगर किया जा सकता है, हैंडलर द्वारा किए गए परिवर्तनों को अनदेखा करके त्रुटि उत्पन्न हुई। यह सबग्राफ लेखकों को अपने सबग्राफ को ठीक करने का समय देता है, जबकि नवीनतम ब्लॉक के विरुद्ध प्रश्नों को जारी रखा जाता है, हालांकि त्रुटि के कारण बग के कारण परिणाम असंगत हो सकते हैं। ध्यान दें कि कुछ त्रुटियाँ अभी भी हमेशा घातक होती हैं। गैर-घातक होने के लिए, त्रुटि नियतात्मक होने के लिए जानी जानी चाहिए।
 
-> **Note:** The Graph Network does not yet support non-fatal errors, and developers should not deploy subgraphs using that functionality to the network via the Studio.
+> **ध्यान दें:** The Graph Network अभी तक गैर-घातक त्रुटियों non-fatal errors का समर्थन नहीं करता है, और डेवलपर्स को Studio के माध्यम से उस कार्यक्षमता का उपयोग करके सबग्राफ को नेटवर्क पर परिनियोजित (deploy) नहीं करना चाहिए।
 
 गैर-घातक त्रुटियों को सक्षम करने के लिए सबग्राफ मेनिफ़ेस्ट पर निम्न फ़ीचर फ़्लैग सेट करने की आवश्यकता होती है:
 
@@ -103,7 +103,7 @@ features:
     ...
 ```
 
-The query must also opt-in to querying data with potential inconsistencies through the `subgraphError` argument. It is also recommended to query `_meta` to check if the subgraph has skipped over errors, as in the example:
+Queries को संभावित असंगतियों वाले डेटा को queries करने के लिए `subgraphError` आर्ग्यूमेंट के माध्यम से ऑप्ट-इन करना होगा। यह भी अनुशंसा की जाती है कि `_meta` को queries करें यह जांचने के लिए कि subgraph ने त्रुटियों को स्किप किया है या नहीं, जैसे इस उदाहरण में:
 
 ```graphql
 foos(first: 100, subgraphError: allow) {
@@ -115,7 +115,7 @@ _meta {
 }
 ```
 
-If the subgraph encounters an error, that query will return both the data and a graphql error with the message `"indexing_error"`, as in this example response:
+यदि subgraph में कोई त्रुटि आती है, तो वह queries डेटा और एक graphql त्रुटि के साथ `"indexing_error"` संदेश लौटाएगी, जैसा कि इस उदाहरण उत्तर में दिखाया गया है:
 
 ```graphql
 "data": {
@@ -145,15 +145,15 @@ If the subgraph encounters an error, that query will return both the data and a
 
 "लाइन" में हैंडलर कार्यान्वयन के दौरान फ़ाइलों को लाने के बजाय, यह टेम्पलेट्स को पेश करता है जिन्हें एक दिए गए फ़ाइल पहचानकर्ता के लिए नए डेटा स्रोतों के रूप में उत्पन्न किया जा सकता है। ये नए डेटा स्रोत फ़ाइलों को लाते हैं, यदि वे असफल होते हैं तो पुनः प्रयास करते हैं, और जब फ़ाइल मिलती है तो एक समर्पित हैंडलर चलाते हैं।
 
-This is similar to the [existing data source templates](/developing/creating-a-subgraph/#data-source-templates), which are used to dynamically create new chain-based data sources.
+यह [ existing data साधन templates](/developing/creating-a-subgraph/#data-source-templates) के समान है, जिन्हें नए chain-based data साधन को डायनामिक रूप से बनाने के लिए उपयोग किया जाता है।
 
-> This replaces the existing `ipfs.cat` API
+> यह मौजूदा `ipfs.cat` API को प्रतिस्थापित करता है।
 
 ### अपग्रेड गाइड
 
-#### Update `graph-ts` and `graph-cli`
+#### `graph-ts` और `graph-cli` को अपडेट करें
 
-File data sources requires graph-ts >=0.29.0 and graph-cli >=0.33.1
+फ़ाइल डेटा साधन के लिए graph-ts >=0.29.0 और graph-cli >=0.33.1 की आवश्यकता होती है।
 
 #### एक नया इकाई प्रकार जोड़ें जो फ़ाइलें मिलने पर अपडेट किया जाएगा
 
@@ -202,9 +202,9 @@ type TokenMetadata @entity {
 
 यदि पैरेंट इकाई और परिणामी फ़ाइल डेटा स्रोत इकाई के बीच संबंध 1:1 है, तो सबसे सरल पैटर्न मूल इकाई को लुकअप के रूप में IPFS CID का उपयोग करके परिणामी फ़ाइल इकाई से लिंक करना है। यदि आपको अपनी नई फ़ाइल-आधारित संस्थाओं को मॉडलिंग करने में कठिनाई हो रही है, तो डिस्कॉर्ड पर संपर्क करें!
 
-> You can use [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) to filter parent entities on the basis of these nested entities.
+> आप [nested filters](/subgraphs/querying/graphql-api/#example-for-nested-entity-filtering) का उपयोग करके parent entities को इन nested entities के आधार पर फ़िल्टर कर सकते हैं।
 
-#### Add a new templated data source with `kind: file/ipfs` or `kind: file/arweave`
+#### एक नया टेम्पलेटेड डेटा साधन स्रोत जोड़ें जिसमें `kind: file/ipfs` या `kind: file/arweave` हो।
 
 यह वह डेटा स्रोत है जो ब्याज की फ़ाइल की पहचान होने पर उत्पन्न होगा।
 
@@ -224,15 +224,15 @@ templates:
           file: ./abis/Token.json
 ```
 
-> Currently `abis` are required, though it is not possible to call contracts from within file data sources
+> वर्तमान में `abis` की आवश्यकता होती है, हालांकि फ़ाइल डेटा साधन के भीतर से अनुबंधों को कॉल contract करना संभव नहीं है।
 
-The file data source must specifically mention all the entity types which it will interact with under `entities`. See [limitations](#limitations) for more details.
+फाइल डेटा साधन को विशेष रूप से उन सभी entities प्रकारों का उल्लेख करना चाहिए जिनके साथ यह `entities`. के तहत इंटरएक्ट करेगा। अधिक विवरण के लिए [ limitations] (#limitations) देखें।
 
 #### फ़ाइलों को संसाधित करने के लिए एक नया हैंडलर बनाएँ
 
-This handler should accept one `Bytes` parameter, which will be the contents of the file, when it is found, which can then be processed. This will often be a JSON file, which can be processed with `graph-ts` helpers ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
+यह handler एक `Bytes` पैरामीटर स्वीकार करना चाहिए, जो उस फ़ाइल की सामग्री होगी, जब यह पाई जाएगी, जिसे फिर से प्रोसेस किया जा सकेगा। यह अक्सर एक JSON फ़ाइल होगी, जिसे `graph-ts` हेल्पर्स के साथ प्रोसेस किया जा सकता है ([documentation](/subgraphs/developing/creating/graph-ts/api/#json-api)).
 
-The CID of the file as a readable string can be accessed via the `dataSource` as follows:
+फ़ाइल का CID एक पठनीय स्ट्रिंग के रूप में `dataSource` के माध्यम से निम्नलिखित तरीके से प्राप्त किया जा सकता है:
 
 ```typescript
 const cid = dataSource.stringParam()
@@ -269,7 +269,7 @@ export function handleMetadata(content: Bytes): void {
 
 अब आप चेन-आधारित हैंडलर के निष्पादन के दौरान फ़ाइल डेटा स्रोत बना सकते हैं:
 
-- Import the template from the auto-generated `templates`
+- ऑटो-जनरेटेड `templates` से टेम्पलेट आयात करें।
 - call `TemplateName.create(cid: string)` from within a mapping, where the cid is a valid content identifier for IPFS or Arweave
 
 For IPFS, Graph Node supports [v0 and v1 content identifiers](https://docs.ipfs.tech/concepts/content-addressing/), and content identifiers with directories (e.g. `bafyreighykzv2we26wfrbzkcdw37sbrby4upq7ae3aqobbq7i4er3tnxci/metadata.json`).

From 30bfba40b6db17da38f7d2e1e074adc970d19351 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:41 -0500
Subject: [PATCH 3221/3820] New translations arbitrum-faq.mdx (Hindi)

---
 website/pages/hi/archived/arbitrum/arbitrum-faq.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/hi/archived/arbitrum/arbitrum-faq.mdx b/website/pages/hi/archived/arbitrum/arbitrum-faq.mdx
index 17a0fc9ca167..8f2c53011c62 100644
--- a/website/pages/hi/archived/arbitrum/arbitrum-faq.mdx
+++ b/website/pages/hi/archived/arbitrum/arbitrum-faq.mdx
@@ -41,7 +41,7 @@ To take advantage of using The Graph on L2, use this dropdown switcher to toggle
 
 ## Subgraph developer, data consumer, Indexer, Curator, or Delegator, के रूप में, मुझे अब क्या करने की आवश्यकता है?
 
-Network participants must move to Arbitrum to continue participating in The Graph Network. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) for additional support.
+The Graph Network में भाग लेने के लिए नेटवर्क प्रतिभागियों को Arbitrum पर स्थानांतरित होना आवश्यक है। अतिरिक्त सहायता के लिए कृपया [L2 Transfer Tool मार्गदर्शक](/archived/arbitrum/l2-transfer-tools-guide/) देखें।
 
 अब सभी इंडेक्सिंग पुरस्कार पूरी तरह से Arbitrum पर हैं।
 
@@ -54,7 +54,7 @@ Network participants must move to Arbitrum to continue participating in The Grap
 
 ## क्या Ethereum पर मौजूद सबग्राफ़ काम कर रहे हैं?
 
-All subgraphs are now on Arbitrum. Please refer to [L2 Transfer Tool Guide](/archived/arbitrum/l2-transfer-tools-guide/) to ensure your subgraphs operate seamlessly.
+सभी सबग्राफ अब Arbitrum पर हैं। कृपया [ L2 Transfer Tool मार्गदर्शक](/archived/arbitrum/l2-transfer-tools-guide/) का संदर्भ लें ताकि आपके सबग्राफ बिना किसी समस्या के कार्य करें।
 
 ## क्या GRT का एक नया स्मार्ट कॉन्ट्रैक्ट Arbitrum पर तैनात किया गया है?
 
@@ -78,4 +78,4 @@ The bridge has been [heavily audited](https://code4rena.com/contests/2022-10-the
 
 आपके आर्बिट्रम बिलिंग बैलेंस में जीआरटी जोड़ना [सबग्राफ स्टूडियो] (https://thegraph.com/studio/) में एक-क्लिक अनुभव के साथ किया जा सकता है। आप आसानी से अपने जीआरटी को आर्बिट्रम से जोड़ सकेंगे और एक लेनदेन में अपनी एपीआई कुंजी भर सकेंगे।
 
-Visit the [Billing page](/subgraphs/billing/) for more detailed instructions on adding, withdrawing, or acquiring GRT.
+अधिक विस्तृत निर्देशों के लिए [ बिलिंग पेज](/subgraphs/billing/) पर जाएं कि GRT जोड़ने, निकालने या प्राप्त करने के लिए क्या करना है।

From e7cccfbeaa3e88cf8a361c92f8a16cd9cab3b7d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:42 -0500
Subject: [PATCH 3222/3820] New translations l2-transfer-tools-faq.mdx (Hindi)

---
 website/pages/hi/archived/arbitrum/l2-transfer-tools-faq.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/archived/arbitrum/l2-transfer-tools-faq.mdx b/website/pages/hi/archived/arbitrum/l2-transfer-tools-faq.mdx
index 8a09613e27f6..2b94a6a42d8c 100644
--- a/website/pages/hi/archived/arbitrum/l2-transfer-tools-faq.mdx
+++ b/website/pages/hi/archived/arbitrum/l2-transfer-tools-faq.mdx
@@ -14,7 +14,7 @@ These tools will require you to follow a specific set of steps depending on what
 
 ### Can I use the same wallet I use on Ethereum mainnet?
 
-If you are using an [EOA](https://ethereum.org/en/developers/docs/accounts/#types-of-account) wallet you can use the same address. If your Ethereum mainnet wallet is a contract (e.g. a multisig) then you must specify an [Arbitrum wallet address](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) where your transfer will be sent. Please check the address carefully as any transfers to an incorrect address can result in permanent loss. If you'd like to use a multisig on L2, make sure you deploy a multisig contract on Arbitrum One.
+यदि आप [ EOA ] (https://ethereum.org/en/developers/docs/accounts/#types-of-account) वॉलेट का उपयोग कर रहे हैं, तो आप उसी पते का उपयोग कर सकते हैं। यदि आपका Ethereum mainnet वॉलेट एक contract है (जैसे कि एक multisig), तो आपको एक [Arbitrum बटुआ पता ](/archived/arbitrum/arbitrum-faq/#what-do-i-need-to-do-to-use-the-graph-on-l2) निर्दिष्ट करना होगा जहाँ आपका ट्रांसफर भेजा जाएगा। कृपया पते को ध्यानपूर्वक जांचें, क्योंकि गलत पते पर ट्रांसफर करने से स्थायी हानि हो सकती है। यदि आप L2 पर multisig का उपयोग करना चाहते हैं, तो सुनिश्चित करें कि आपने Arbitrum One पर एक multisig contract तैनात किया हो।
 
 Wallets on EVM blockchains like Ethereum and Arbitrum are a pair of keys (public and private), that you create without any need to interact with the blockchain. So any wallet that was created for Ethereum will also work on Arbitrum without having to do anything else.
 

From 0ac4e36c7a069743acab7bb8420ecbbc59c8b7a8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:43 -0500
Subject: [PATCH 3223/3820] New translations sunrise.mdx (Hindi)

---
 website/pages/hi/archived/sunrise.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/archived/sunrise.mdx b/website/pages/hi/archived/sunrise.mdx
index 3d0b56717d5f..059c432ef629 100644
--- a/website/pages/hi/archived/sunrise.mdx
+++ b/website/pages/hi/archived/sunrise.mdx
@@ -22,7 +22,7 @@ title: पोस्ट-सनराइज + The Graph Network में अप
 
 ### सबग्राफ्स को Arbitrum पर क्यों प्रकाशित किया गया, क्या इसने एक अलग नेटवर्क को इंडेक्स करना शुरू किया?
 
-The Graph Network was initially deployed on Ethereum mainnet but was later moved to Arbitrum One in order to lower gas costs for all users. As a result, all new subgraphs are published to The Graph Network on Arbitrum so that Indexers can support them. Arbitrum is the network that subgraphs are published to, but subgraphs can index any of the [supported networks](/supported-networks/)
+The Graph Network को पहले Ethereum mainnet पर डिप्लॉय किया गया था, लेकिन गैस लागत को कम करने के लिए इसे बाद में Arbitrum One पर स्थानांतरित कर दिया गया। परिणामस्वरूप, सभी नए सबग्राफ को Arbitrum पर The Graph Network में प्रकाशित किया जाता है ताकि Indexers उन्हें सपोर्ट कर सकें। Arbitrum वह नेटवर्क है जिस पर सबग्राफ को प्रकाशित किया जाता है, लेकिन सबग्राफ [supported networks](/supported-networks/) में से किसी पर भी index कर सकते हैं
 
 ## About the Upgrade Indexer
 
@@ -33,7 +33,7 @@ The Graph Network was initially deployed on Ethereum mainnet but was later moved
 ### अपग्रेड Indexer क्या करता है?
 
 - यह उन चेन को बूटस्ट्रैप करता है जिन्हें अभी तक The Graph Network पर इंडेक्सिंग पुरस्कार नहीं मिले हैं और यह सुनिश्चित करता है कि एक Indexer उपलब्ध हो ताकि एक Subgraph प्रकाशित होने के तुरंत बाद क्वेरी को यथाशीघ्र सेवा दी जा सके।
-- It supports chains that were previously only available on the hosted service. Find a comprehensive list of supported chains [here](/supported-networks/).
+- यह उन chain को भी सपोर्ट करता है जो पहले केवल Hosted Service पर उपलब्ध थीं। सपोर्टेड chain की व्यापक सूची [यहां](/supported-networks/) देखें।
 - जो Indexer अपग्रेड इंडेक्सर का संचालन करते हैं, वे नए सबग्राफ़ और अतिरिक्त चेन का समर्थन करने के लिए एक सार्वजनिक सेवा के रूप में ऐसा करते हैं जो इंडेक्सिंग पुरस्कारों की कमी का सामना कर रहे हैं, जब तक कि The Graph काउंसिल उन्हें मंजूरी नहीं देती।
 
 ### Why is Edge & Node running the upgrade Indexer?

From d7c6d97b51fc6cea7a4ccfc03feb6cce5c65738e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:45 -0500
Subject: [PATCH 3224/3820] New translations chain-integration-overview.mdx
 (Hindi)

---
 website/pages/hi/indexing/chain-integration-overview.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/indexing/chain-integration-overview.mdx b/website/pages/hi/indexing/chain-integration-overview.mdx
index 5c770235ff7c..6a7c06a71a07 100644
--- a/website/pages/hi/indexing/chain-integration-overview.mdx
+++ b/website/pages/hi/indexing/chain-integration-overview.mdx
@@ -6,7 +6,7 @@ A transparent and governance-based integration process was designed for blockcha
 
 ## Stage 1. Technical Integration
 
-- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- कृपया `ग्राफ-नोड` द्वारा नए chain समर्थन के लिए [New Chain इंटीग्रेशन](/indexing/new-chain-integration/) पर जाएं।
 - Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
 
 ## Stage 2. Integration Validation

From 6a48b9e8fefe4c1e48efcc85f95a40c5ec858914 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:46 -0500
Subject: [PATCH 3225/3820] New translations new-chain-integration.mdx (Hindi)

---
 website/pages/hi/indexing/new-chain-integration.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/indexing/new-chain-integration.mdx b/website/pages/hi/indexing/new-chain-integration.mdx
index 328bd44037b8..ea0daac8d64f 100644
--- a/website/pages/hi/indexing/new-chain-integration.mdx
+++ b/website/pages/hi/indexing/new-chain-integration.mdx
@@ -47,7 +47,7 @@ EVM चेन के लिए, एक गहरे स्तर के डे
 
 ## EVM विचार - JSON-RPC और Firehose के बीच का अंतर
 
-While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+JSON-RPC और Firehose दोनों ही सबग्राफ के लिए उपयुक्त हैं, लेकिन एक Firehose हमेशा आवश्यक होता है यदि डेवलपर्स [सबस्ट्रीम](https://substreams.streamingfast.io) के साथ निर्माण करना चाहते हैं। सबस्ट्रीम का समर्थन करने से डेवलपर्स को नए chain के लिए [सबस्ट्रीम-powered सबग्राफ](/subgraphs/cookbook/substreams-powered-subgraphs/) बनाने की अनुमति मिलती है, और इसके परिणामस्वरूप आपके सबग्राफ की प्रदर्शन क्षमता में सुधार हो सकता है। इसके अतिरिक्त, Firehose — जो कि `ग्राफ-नोड` के JSON-RPC extraction layer का एक drop-in replacement है — सामान्य indexing के लिए आवश्यक RPC कॉल्स की संख्या को 90% तक घटा देता है।
 
 - सभी `getLogs` कॉल्स और राउंडट्रिप्स को एकल स्ट्रीम द्वारा प्रतिस्थापित किया जाता है, जो सीधे `graph-node` के केंद्र में पहुंचती है; यह एकल ब्लॉक मॉडल सभी सबग्राफ्स के लिए काम करता है जिन्हें यह प्रोसेस करता है।
 
@@ -67,4 +67,4 @@ While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is a
 
 ## सबस्ट्रीम-संचालित सबग्राफ की सेवा
 
-For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.
+StreamingFast द्वारा संचालित Firehose/सबस्ट्रीम इंटीग्रेशन के लिए, बुनियादी सबस्ट्रीम मॉड्यूल (जैसे डिकोड किए गए लेनदेन, log और स्मार्ट-contract आयोजन) और सबस्ट्रीम कोडजेन टूल्स का बेसिक सपोर्ट शामिल है। ये टूल्स [सबस्ट्रीम-powered सबग्राफ](/substreams/sps/introduction/) को सक्षम बनाने की क्षमता प्रदान करते हैं। [ मार्गदर्शक](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) का अनुसरण करें और `सबस्ट्रीम codegen सबग्राफ` चलाकर कोडजेन टूल्स का अनुभव लें।

From 6445c8d8402d92d8df8405dafa6d54477241b8d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:47 -0500
Subject: [PATCH 3226/3820] New translations firehose.mdx (Hindi)

---
 website/pages/hi/indexing/tooling/firehose.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/indexing/tooling/firehose.mdx b/website/pages/hi/indexing/tooling/firehose.mdx
index 2678f5b3eb73..d2a13417500b 100644
--- a/website/pages/hi/indexing/tooling/firehose.mdx
+++ b/website/pages/hi/indexing/tooling/firehose.mdx
@@ -4,7 +4,7 @@ title: Firehose
 
 ![Firehose Logo](/img/firehose-logo.png)
 
-Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+Firehose एक नई तकनीक है जिसे StreamingFast ने The Graph Foundation के साथ मिलकर विकसित किया है। यह **उत्पाद ब्लॉकचेन डेटा को indexing करने के लिए पहले कभी नहीं देखी गई क्षमताएँ और गति प्रदान** करता है, जो कि एक फ़ाइल-आधारित और स्ट्रीमिंग-प्रथम दृष्टिकोण का उपयोग करता है।
 
 The Graph ने Go Ethereum/geth में विलय कर लिया है और [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0) को अपनाया है।
 

From 05747f87069a584d3a679a22fa075f6c5b66d385 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:49 -0500
Subject: [PATCH 3227/3820] New translations benefits.mdx (Hindi)

---
 website/pages/hi/resources/benefits.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/hi/resources/benefits.mdx b/website/pages/hi/resources/benefits.mdx
index 8c9c361318d6..fc923c6ac9e9 100644
--- a/website/pages/hi/resources/benefits.mdx
+++ b/website/pages/hi/resources/benefits.mdx
@@ -75,7 +75,7 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 <sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
 
-Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+एस्टिमेटेड लागत केवल Ethereum Mainnet सबग्राफ़ के लिए है — अन्य नेटवर्कों पर `ग्राफ-नोड` को स्वयं होस्ट करने पर लागत और भी अधिक होती है। कुछ उपयोगकर्ताओं को अपने Subgraph को एक नई संस्करण में अपडेट करने की आवश्यकता हो सकती है। Ethereum गैस शुल्क के कारण, एक अपडेट की लागत लगभग ~$50 है जब लेख लिखा गया था। ध्यान दें कि [Arbitrum](/archived/arbitrum/arbitrum-faq/) पर गैस शुल्क Ethereum mainnet से काफी कम हैं।
 
 एक सबग्राफ पर क्यूरेटिंग सिग्नल एक वैकल्पिक वन-टाइम, नेट-जीरो कॉस्ट है (उदाहरण के लिए, सिग्नल में $1k को सबग्राफ पर क्यूरेट किया जा सकता है, और बाद में वापस ले लिया जाता है - प्रक्रिया में रिटर्न अर्जित करने की क्षमता के साथ)।
 
@@ -85,8 +85,8 @@ Estimated costs are only for Ethereum Mainnet subgraphs — costs are even highe
 
 ## विश्वसनीयता और लचीलापन
 
-The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+The Graph का विकेन्द्रीकृत नेटवर्क उपयोगकर्ताओं को भौगोलिक रेडंडेंसी तक पहुंच प्रदान करता है, जो कि जब आप `ग्राफ-नोड` को स्वयं होस्ट करते हैं तो मौजूद नहीं होता। 99.9%+ अपटाइम के साथ queries को विश्वसनीय रूप से सेवा प्रदान की जाती है, जो कि सैकड़ों स्वतंत्र Indexers द्वारा नेटवर्क को वैश्विक स्तर पर सुरक्षित किए जाने से प्राप्त होती है।
 
 The Graph Network कम खर्चीला, उपयोग में आसान और बेहतर परिणाम प्रदान करता है, जब की graph-node को लोकल पर चलाने के मुकाबले।
 
-Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).
+आज ही The Graph Network का उपयोग शुरू करें, और सीखें कि कैसे [अपने subgraph को The Graph के विकेंद्रीकृत नेटवर्क पर प्रकाशित](/subgraphs/quick-start/) करें।

From 69a0d9abbd4fb97d7a2e8872b416f61e77614119 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:50 -0500
Subject: [PATCH 3228/3820] New translations assemblyscript-migration-guide.mdx
 (Hindi)

---
 .../assemblyscript-migration-guide.mdx        | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx
index e992941445be..2917ae036756 100644
--- a/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/hi/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -2,11 +2,11 @@
 title: असेंबलीस्क्रिप्ट माइग्रेशन गाइड
 ---
 
-Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+अब तक, सबग्राफ [AssemblyScript के शुरुआती संस्करणों](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) में से एक का उपयोग कर रहे थे (v0.6)। अंततः हमने सबसे [नए उपलब्ध संस्करण](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10) के लिए समर्थन जोड़ दिया है! 🎉
 
 यह सबग्राफ डेवलपर्स को एएस भाषा और मानक पुस्तकालय की नई सुविधाओं का उपयोग करने में सक्षम करेगा।
 
-This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+यह मार्गदर्शक उन सभी लोगों के लिए लागू है जो `graph-cli`/`graph-ts` का संस्करण `0.22.0` से कम उपयोग कर रहे हैं। यदि आप पहले से ही इस संस्करण (या उससे उच्च) पर हैं, तो आप पहले से ही AssemblyScript के संस्करण `0.19.10` का उपयोग कर रहे हैं 🙂
 
 > `0.24.0` संस्करण से, `graph-node` दोनों संस्करणों का समर्थन कर सकता है, यह इस पर निर्भर करता है कि subgraph manifest में कौन सा `apiVersion` निर्दिष्ट किया गया है।
 
@@ -45,7 +45,7 @@ This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `
 
 ## कैसे करें अपग्रेड?
 
-1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+1. अपने मानचित्रण `सबग्राफ.yaml` में `apiVersion` को `0.0.6` में बदलें:
 
 ```yaml
 ...
@@ -199,12 +199,12 @@ let uint8Array = new Uint8Array(2)
 ```
 
 ```typescript
-// between two types that share a superclass
+// दो प्रकारों के बीच जो एक superclass साझा करते हैं
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
 let bytes = new Bytes(2)
-// <ByteArray>bytes // breaks in runtime :(
+// <ByteArray>bytes // रनटाइम में टूट जाता है :(
 ```
 
 ऐसे मामलों के लिए, आप `changetype<T>` फ़ंक्शन का उपयोग कर सकते हैं:
@@ -218,12 +218,12 @@ changetype<Bytes>(uint8Array) // काम करता है :)
 ```
 
 ```typescript
-// between two types that share a superclass
+// दो प्रकारों के बीच जो एक सुपरक्लास साझा करते हैं
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
-let bytes = new Bytes(2)
-changetype<ByteArray>(bytes) // works :)
+let bytes = new Bytes(2);
+changetype<ByteArray>(bytes); // काम करता है :)
 ```
 
 यदि आप केवल nullability को हटाना चाहते हैं, तो आप `as` ऑपरेटर (या `<T>variable`) का उपयोग जारी रख सकते हैं, लेकिन यह सुनिश्चित करें कि आपको पता है कि वह मान null नहीं हो सकता है, अन्यथा यह टूट जाएगा।
@@ -462,7 +462,7 @@ arr.push('something') // ["", "", "", "", "", "something"] // आकार 6 :(
 आपके द्वारा उपयोग किए जा रहे प्रकारों के आधार पर, उदाहरण के लिए अशक्त वाले, और आप उन्हें कैसे एक्सेस कर रहे हैं, आपको इस तरह की रनटाइम त्रुटि का सामना करना पड़ सकता है:
 
 ```
-ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+ERRO handler निष्पादन विफलता के कारण छोड़ दिया गया, त्रुटि: ~lib/array.ts, पंक्ति 110, कॉलम 40 पर मानचित्रण बंद कर दी गई, संदेश के साथ: यदि एरे में छेद हो तो तत्व प्रकार को नल होना चाहिए wasm बैकट्रेस: 0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format 1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor 2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
 ```
 
 शुरुआत में वास्तव में पुश करने के लिए, आपको `Array` को शून्य आकार के साथ इस प्रकार प्रारंभ करना चाहिए:
@@ -511,7 +511,7 @@ type MyEntity @entity {
 }
 ```
 
-This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+यह AssemblyScript संस्करणों के बीच nullability अंतर के कारण बदला, और यह `src/generated/schema.ts` फ़ाइल से संबंधित है (डिफ़ॉल्ट पथ, आप इसे बदल सकते हैं)।
 
 ### अन्य
 

From 22c2cf6fc9386a9abb5c330ba787d4e298103c7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:51 -0500
Subject: [PATCH 3229/3820] New translations curating.mdx (Hindi)

---
 website/pages/hi/resources/roles/curating.mdx | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/hi/resources/roles/curating.mdx b/website/pages/hi/resources/roles/curating.mdx
index 8fa7994fde95..496532260336 100644
--- a/website/pages/hi/resources/roles/curating.mdx
+++ b/website/pages/hi/resources/roles/curating.mdx
@@ -8,7 +8,7 @@ Curators are critical to The Graph's decentralized economy. They use their knowl
 
 Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
 
-Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+Curators The Graph network को कुशल बनाते हैं और [संकेत देना](#how-to-signal) वह प्रक्रिया है जिसका उपयोग Curators यह बताने के लिए करते हैं कि कौन सा subgraph Indexer के लिए अच्छा है। Indexers Curator से आने वाले संकेत पर भरोसा कर सकते हैं क्योंकि संकेत देना के दौरान, Curators subgraph के लिए एक curation share मिंट करते हैं, जो उन्हें उस subgraph द्वारा उत्पन्न भविष्य के पूछताछ शुल्क के एक हिस्से का हकदार बनाता है।
 
 Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
 
@@ -16,23 +16,23 @@ Curator signals are represented as ERC20 tokens called Graph Curation Shares (GC
 
 When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
 
-If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+यदि आपको सेवा की गुणवत्ता बढ़ाने के लिए curation में सहायता की आवश्यकता हो, तो कृपया एज और नोड टीम को support@thegraph.zendesk.com पर अनुरोध भेजें और उन सबग्राफ को निर्दिष्ट करें जिनमें आपको सहायता चाहिए।
 
 Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
 
-![Explorer subgraphs](/img/explorer-subgraphs.png)
+![Explorer सबग्राफ](/img/explorer-subgraphs.png)
 
 ## सिग्नल कैसे करें
 
-Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+Graph Explorer के Curator टैब में, curators नेटवर्क स्टैट्स के आधार पर कुछ सबग्राफ पर signal और unsignal कर सकेंगे। Graph Explorer में यह कैसे करना है, इसका चरण-दर-चरण अवलोकन पाने के लिए [यहाँ क्लिक करें](/subgraphs/explorer/)।
 
 एक क्यूरेटर एक विशिष्ट सबग्राफ संस्करण पर संकेत देना चुन सकता है, या वे अपने सिग्नल को स्वचालित रूप से उस सबग्राफ के नवीनतम उत्पादन निर्माण में माइग्रेट करना चुन सकते हैं। दोनों मान्य रणनीतियाँ हैं और अपने स्वयं के पेशेवरों और विपक्षों के साथ आती हैं।
 
-Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+विशेष संस्करण पर संकेत देना विशेष रूप से उपयोगी होता है जब एक subgraph को कई dapp द्वारा उपयोग किया जाता है। एक dapp को नियमित रूप से subgraph को नई विशेषता के साथ अपडेट करने की आवश्यकता हो सकती है। दूसरी dapp एक पुराना, अच्छी तरह से परीक्षण किया हुआ उपग्राफ subgraph संस्करण उपयोग करना पसंद कर सकती है। प्रारंभिक क्यूरेशन curation पर, 1% मानक कर tax लिया जाता है।
 
 अपने सिग्नल को स्वचालित रूप से नवीनतम उत्पादन बिल्ड में माइग्रेट करना यह सुनिश्चित करने के लिए मूल्यवान हो सकता है कि आप क्वेरी शुल्क अर्जित करते रहें। हर बार जब आप क्यूरेट करते हैं, तो 1% क्यूरेशन टैक्स लगता है। आप हर माइग्रेशन पर 0.5% क्यूरेशन टैक्स भी देंगे। सबग्राफ डेवलपर्स को बार-बार नए संस्करण प्रकाशित करने से हतोत्साहित किया जाता है - उन्हें सभी ऑटो-माइग्रेटेड क्यूरेशन शेयरों पर 0.5% क्यूरेशन टैक्स देना पड़ता है।
 
-> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+> **नोट**पहला पता जो किसी विशेष subgraph को सिग्नल करता है, उसे पहला curator माना जाएगा और उसे बाकी आने वाले curators की तुलना में अधिक गैस-इंटेंसिव कार्य करना होगा क्योंकि पहला curator curation share टोकन को इनिशियलाइज़ करता है और टोकन को The Graph प्रॉक्सी में ट्रांसफर करता है।
 
 ## Withdrawing your GRT
 
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. क्वेरी बाजार द ग्राफ में स्वाभाविक रूप से युवा है और इसमें जोखिम है कि नवजात बाजार की गतिशीलता के कारण आपका %APY आपकी अपेक्षा से कम हो सकता है।
 2. क्यूरेशन शुल्क  - जब कोई क्यूरेटर किसी सबग्राफ़ पर GRT सिग्नल करता है, तो उसे 1% क्यूरेशन टैक्स देना होता है। यह शुल्क जला दिया जाता है।
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) जब curators अपने शेयर जलाकर GRT निकालते हैं, तो बची हुई शेयरों की GRT वैल्यूएशन घट जाएगी। ध्यान दें कि कुछ मामलों में, curators अपने शेयर एक बार में जला सकते हैं। यह स्थिति आम हो सकती है यदि कोई dapp डेवलपर अपने subgraph का वर्शनिंग/इंप्रूविंग और queries करना बंद कर देता है या यदि कोई subgraph फेल हो जाता है। नतीजतन, बचे हुए curators केवल अपने प्रारंभिक GRT का एक हिस्सा निकालने में सक्षम हो सकते हैं। एक कम जोखिम वाले नेटवर्क रोल के लिए, देखें [Delegators](/resources/roles/delegating/)।
 4. बग के कारण सबग्राफ विफल हो सकता है। एक विफल सबग्राफ क्वेरी शुल्क अर्जित नहीं करता है। नतीजतन, आपको तब तक इंतजार करना होगा जब तक कि डेवलपर बग को ठीक नहीं करता है और एक नया संस्करण तैनात करता है।
    - यदि आपने सबग्राफ के नवीनतम संस्करण की सदस्यता ली है, तो आपके शेयर उस नए संस्करण में स्वत: माइग्रेट हो जाएंगे। इस पर 0.5% क्यूरेशन टैक्स लगेगा।
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
@@ -61,14 +61,14 @@ By signalling on a subgraph, you will earn a share of all the query fees that th
 
 ### 2. मैं यह कैसे तय करूं कि कौन से सबग्राफ सिग्नल देने के लिए उच्च गुणवत्ता वाले हैं?
 
-Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+उच्च-गुणवत्ता वाले सबग्राफ खोजना एक जटिल कार्य है, लेकिन इसे कई अलग-अलग तरीकों से किया जा सकता है। एक Curator के रूप में, आपको उन भरोसेमंद सबग्राफ को देखना चाहिए जो query volume को बढ़ा रहे हैं। एक भरोसेमंद subgraph मूल्यवान हो सकता है यदि वह पूर्ण, सटीक हो और किसी dapp की डेटा आवश्यकताओं को पूरा करता हो। एक खराब डिज़ाइन किया गया subgraph संशोधित या पुनः प्रकाशित करने की आवश्यकता हो सकती है और अंततः असफल भी हो सकता है। यह Curators के लिए अत्यंत महत्वपूर्ण है कि वे किसी subgraph की संरचना या कोड की समीक्षा करें ताकि यह आकलन कर सकें कि subgraph मूल्यवान है या नहीं।
 
 - क्यूरेटर नेटवर्क की अपनी समझ का उपयोग करके यह अनुमान लगाने की कोशिश कर सकते हैं कि भविष्य में कोई विशेष सबग्राफ़ अधिक या कम क्वेरी वॉल्यूम कैसे उत्पन्न कर सकता है।
 - क्यूरेटर को Graph Explorer के माध्यम से उपलब्ध मेट्रिक्स को भी समझना चाहिए। जैसे कि पिछले क्वेरी वॉल्यूम और सबग्राफ़ डेवलपर कौन है, ये मेट्रिक्स यह तय करने में मदद कर सकते हैं कि किसी सबग्राफ़ पर सिग्नलिंग करना उचित है या नहीं।
 
 ### 3. What’s the cost of updating a subgraph?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+नए subgraph संस्करण में अपनी curation shares को माइग्रेट करने पर 1% curation टैक्स लगता है। Curators नए subgraph संस्करण को सब्सक्राइब करने का विकल्प चुन सकते हैं। जब curator shares अपने आप नए संस्करण में माइग्रेट होती हैं, तो Curators को आधा curation टैक्स, यानी 0.5%, देना पड़ता है क्योंकि सबग्राफ को अपग्रेड करना एक ऑनचेन क्रिया है जो गैस खर्च करती है।
 
 ### 4. How often can I update my subgraph?
 

From a33763e4431e6e72f5fb5d14d79791fc6b8a6028 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:52 -0500
Subject: [PATCH 3230/3820] New translations enums.mdx (Hindi)

---
 website/pages/hi/subgraphs/cookbook/enums.mdx | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/hi/subgraphs/cookbook/enums.mdx b/website/pages/hi/subgraphs/cookbook/enums.mdx
index c6c2a2dfc188..28fc4517ca23 100644
--- a/website/pages/hi/subgraphs/cookbook/enums.mdx
+++ b/website/pages/hi/subgraphs/cookbook/enums.mdx
@@ -1,5 +1,5 @@
 ---
-title: Categorize NFT Marketplaces Using Enums
+title: NFT मार्केटप्लेस को Enums का उपयोग करके श्रेणीबद्ध करें
 ---
 
 Enams का उपयोग करके अपने कोड को साफ और कम त्रुटिपूर्ण बनाएं। यहां NFT मार्केटप्लेस पर Enams के उपयोग का एक पूरा उदाहरण है।
@@ -12,7 +12,7 @@ Enums, या enumeration types, एक विशिष्ट डेटा प
 
 यदि आप एक subgraph बना रहे हैं जो एक मार्केटप्लेस पर टोकन के स्वामित्व इतिहास को ट्रैक करता है, तो प्रत्येक टोकन विभिन्न स्वामित्वों से गुजर सकता है, जैसे कि OriginalOwner, SecondOwner, और ThirdOwner। enums का उपयोग करके, आप इन विशिष्ट स्वामित्वों को परिभाषित कर सकते हैं, यह सुनिश्चित करते हुए कि केवल पूर्वनिर्धारित मान ही सौंपे जाएं।
 
-You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+आप अपनी स्कीमा में एन्सम्स (enums) को परिभाषित कर सकते हैं, और एक बार परिभाषित हो जाने के बाद, आप एन्सम के मानों की स्ट्रिंग प्रस्तुति का उपयोग करके एक एन्सम फ़ील्ड को एक entities पर सेट कर सकते हैं।
 
 यहां आपके स्कीमा में एक enum परिभाषा इस प्रकार हो सकती है, उपरोक्त उदाहरण के आधार पर:
 
@@ -30,7 +30,7 @@ enum TokenStatus {
 
 ## Enums का उपयोग करने के लाभ
 
-- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
+- स्पष्टता: Enums एन्उम्स मानों के लिए सार्थक नाम प्रदान करते हैं, जिससे डेटा को समझना आसान होता है।
 - सत्यापन: Enums कड़े मान मान्यताएँ लागू करते हैं, जो अवैध डेटा प्रविष्टियों को रोकते हैं।
 - रखरखाव: जब आपको नए श्रेणियाँ या ईनम्स (enums) जोड़ने या बदलने की आवश्यकता हो, तो आप इसे एक केंद्रित तरीके से कर सकते हैं।
 
@@ -53,7 +53,7 @@ type Token @entity {
 #### यह एक समस्या क्यों है?
 
 - TokenStatus मानों की कोई सीमा नहीं है, इसलिए कोई भी स्ट्रिंग गलती से असाइन की जा सकती है। इससे यह सुनिश्चित करना कठिन हो जाता है कि केवल वैध स्टेटस जैसे OriginalOwner, SecondOwner, या ThirdOwner सेट किए जाएं।
-- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+- यह टाइपो करना आसान है जैसे Orgnalowner को OriginalOwner के बजाय, जिससे डेटा और संभावित queries अप्रतिबद्ध हो सकती हैं।
 
 ### Enums के साथ
 
@@ -65,7 +65,7 @@ Enums प्रकार सुरक्षा प्रदान करते 
 
 > नोट: निम्नलिखित guide CryptoCoven NFT स्मार्ट कॉन्ट्रैक्ट का उपयोग करती है।
 
-To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+NFTs जहां ट्रेड होते हैं, उन विभिन्न मार्केटप्लेस के लिए enums को परिभाषित करने के लिए, अपने Subgraph स्कीमा में निम्नलिखित का उपयोग करें:
 
 ```gql
 #मार्केटप्लेस के लिए Enum जो CryptoCoven कॉन्ट्रैक्ट के साथ इंटरएक्टेड हैं (संभवत: ट्रेड/मिंट) 
@@ -110,7 +110,7 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 - केंद्रीकृत प्रबंधन: एकल फ़ाइल में enums रखें ताकि सुसंगतता बनी रहे। इससे enums को अपडेट करना आसान हो जाता है और यह सत्य का एकमात्र source बनता है।
 - दस्तावेज़ीकरण: एनम में उनकी उद्देश्य और उपयोग को स्पष्ट करने के लिए टिप्पणियाँ जोड़ें।
 
-## Using Enums in Queries
+## queries में Enums का उपयोग करना
 
 क्वेरी में Enums आपके डेटा की गुणवत्ता में सुधार करने और आपके परिणामों को समझने में आसान बनाने में मदद करते हैं। ये फ़िल्टर और प्रतिक्रिया तत्व के रूप में कार्य करते हैं, बाज़ार के मूल्यों में स्थिरता सुनिश्चित करते हैं और त्रुटियों को कम करते हैं।
 
@@ -119,7 +119,7 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 - **Enums के साथ फ़िल्टरिंग:** Enums स्पष्ट फ़िल्टर प्रदान करते हैं, जिससे आप निश्चित रूप से विशिष्ट मार्केटप्लेस को शामिल या बाहर कर सकते हैं।
 - **प्रतिसादों में Enums:** एन्‍यम्‍स यह सुनिश्चित करते हैं कि केवल मान्यता प्राप्त मार्केटप्लेस नाम ही वापस आएं, जिससे परिणाम मानकीकृत और सटीक हों।
 
-### Sample Queries
+### नमूना queries
 
 #### Query 1: सबसे अधिक NFT मार्केटप्लेस इंटरएक्शन वाला खाता
 
@@ -190,7 +190,7 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 
 यह क्वेरी निम्नलिखित कार्य करती है:
 
-- It identifies the marketplace with the highest volume of CryptoCoven transactions.
+- यह उस मार्केटप्लेस की पहचान करता है जहां CryptoCoven लेनदेन का सबसे अधिक वॉल्यूम होता है।
 - यह मार्केटप्लेस enum का उपयोग करता है ताकि प्रतिक्रिया में केवल मान्य मार्केटप्लेस प्रकार ही दिखाई दें, जिससे आपके डेटा में विश्वसनीयता और स्थिरता बनी रहती है।
 
 ```gql
@@ -219,11 +219,11 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 }
 ```
 
-#### Query 3: Marketplace Interactions with High Transaction Counts
+#### प्रश्न 3: उच्च लेन-देन गणना के साथ बाज़ार परस्पर क्रियाएँ
 
 यह क्वेरी निम्नलिखित कार्य करती है:
 
-- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
+- यह 100 से अधिक transactions वाले शीर्ष चार बाजारों को पुनः प्राप्त करता है, "Unknown" बाजारों को छोड़कर।
 - यह केवल वैध मार्केटप्लेस प्रकारों को शामिल करने के लिए फ़िल्टर के रूप में एंनम का उपयोग करता है, जिससे सटीकता बढ़ती है।
 
 ```gql

From 5df3c201a445e0c6e2037afa4d29e21e81a9846d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:53 -0500
Subject: [PATCH 3231/3820] New translations transfer-to-the-graph.mdx (Hindi)

---
 website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx
index e112cc76a16d..ae5023b492a4 100644
--- a/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/hi/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -8,7 +8,7 @@ title: The Graph पर ट्रांसफर करें
 
 - आपके ऐप्स द्वारा पहले से उपयोग किए जा रहे वही subgraph को बिना किसी डाउनटाइम के माइग्रेशन के लिए उपयोग करें।
 - 100+ Indexers द्वारा समर्थित एक वैश्विक नेटवर्क से विश्वसनीयता बढ़ाएं।
-- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+- सबग्राफ के लिए 24/7 तेज़ और तुरंत समर्थन प्राप्त करें, एक ऑन-कॉल इंजीनियरिंग टीम के साथ।
 
 ## अपने Subgraph को The Graph में 3 आसान कदमों में अपग्रेड करें
 

From 50e137873a97dc0053784928838ddb808f689fda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:54 -0500
Subject: [PATCH 3232/3820] New translations using-subgraph-studio.mdx (Hindi)

---
 .../hi/subgraphs/developing/deploying/using-subgraph-studio.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/developing/deploying/using-subgraph-studio.mdx b/website/pages/hi/subgraphs/developing/deploying/using-subgraph-studio.mdx
index 729136d7d90e..2341d6777f15 100644
--- a/website/pages/hi/subgraphs/developing/deploying/using-subgraph-studio.mdx
+++ b/website/pages/hi/subgraphs/developing/deploying/using-subgraph-studio.mdx
@@ -39,7 +39,7 @@ yarn global add @graphprotocol/graph-cli
 npm install -g @graphprotocol/graph-cli
 ```
 
-## Get Started
+## शुरू करिये
 
 1. खोलें [Subgraph Studio](https://thegraph.com/studio/).
 2. अपने वॉलेट से साइन इन करें।

From 154c594c00bde5d3a0cd1ff1f31104f7cfc1979f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:55 -0500
Subject: [PATCH 3233/3820] New translations publishing-a-subgraph.mdx (Hindi)

---
 .../subgraphs/developing/publishing/publishing-a-subgraph.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/hi/subgraphs/developing/publishing/publishing-a-subgraph.mdx
index 60a448149d22..2d557e5810ea 100644
--- a/website/pages/hi/subgraphs/developing/publishing/publishing-a-subgraph.mdx
+++ b/website/pages/hi/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -81,7 +81,7 @@ When signaling, Curators can decide to signal on a specific version of the subgr
 
 Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
 
-![Explorer subgraphs](/img/explorer-subgraphs.png)
+![Explorer सबग्राफ](/img/explorer-subgraphs.png)
 
 Subgraph Studio आपको अपने सबग्राफ़ में सिग्नल जोड़ने की सुविधा देता है, जिसमें आप अपने सबग्राफ़ के क्यूरेशन पूल में उसी लेन-देन के साथ GRT जोड़ सकते हैं, जब इसे प्रकाशित किया जाता है.
 

From ea64b11f99bdd410c48b9655bbd36ad3851dec7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:56 -0500
Subject: [PATCH 3234/3820] New translations subgraphs.mdx (Hindi)

---
 website/pages/hi/subgraphs/developing/subgraphs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/developing/subgraphs.mdx b/website/pages/hi/subgraphs/developing/subgraphs.mdx
index 88938cf949f2..153754823989 100644
--- a/website/pages/hi/subgraphs/developing/subgraphs.mdx
+++ b/website/pages/hi/subgraphs/developing/subgraphs.mdx
@@ -1,5 +1,5 @@
 ---
-title: Subgraphs
+title: सबग्राफ
 ---
 
 ## Subgraph क्या है?

From eeca6f417830e726d350285504e1a5e8efeaa611 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:57 -0500
Subject: [PATCH 3235/3820] New translations introduction.mdx (Hindi)

---
 website/pages/hi/sps/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/sps/introduction.mdx b/website/pages/hi/sps/introduction.mdx
index 3b13147fe447..1867d6e05f01 100644
--- a/website/pages/hi/sps/introduction.mdx
+++ b/website/pages/hi/sps/introduction.mdx
@@ -1,5 +1,5 @@
 ---
-title: Introduction to Substreams-Powered Subgraphs
+title: सबस्ट्रीम-पावर्ड सबग्राफ का परिचय
 ---
 
 Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.

From 2060b8e3a6fca7eb11854f8807c4d242ae398f17 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:58 -0500
Subject: [PATCH 3236/3820] New translations sps-faq.mdx (Hindi)

---
 website/pages/hi/sps/sps-faq.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/hi/sps/sps-faq.mdx b/website/pages/hi/sps/sps-faq.mdx
index 3f9158706485..50c94794f115 100644
--- a/website/pages/hi/sps/sps-faq.mdx
+++ b/website/pages/hi/sps/sps-faq.mdx
@@ -1,5 +1,5 @@
 ---
-title: Substreams-Powered Subgraphs FAQ
+title: सबस्ट्रीम्स-पावर्ड सबग्राफ FAQ
 ---
 
 ## What are Substreams?
@@ -18,9 +18,9 @@ If you are already familiar with subgraph development, note that Substreams-powe
 
 ## How are Substreams-powered subgraphs different from subgraphs?
 
-Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+सबग्राफ डेटा सोर्सेस से बने होते हैं, जो ऑनचेन आयोजन को निर्धारित करते हैं और उन आयोजन को Assemblyscript में लिखे handler के माध्यम से कैसे ट्रांसफॉर्म करना चाहिए। ये आयोजन क्रमवार तरीके से प्रोसेस किए जाते हैं, जिस क्रम में ये आयोजन ऑनचेन होते हैं।
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+सबस्ट्रीम-सक्षम सबग्राफ के पास एक ही datasource होता है जो सबस्ट्रीम पैकेज को संदर्भित करता है, जिसे ग्राफ नोड द्वारा प्रोसेस किया जाता है। सबस्ट्रीम को पारंपरिक सबग्राफ की तुलना में अतिरिक्त सटीक ऑनचेन डेटा तक पहुंच होती है, और यह बड़े पैमाने पर समानांतर प्रोसेसिंग का लाभ भी ले सकते हैं, जिससे प्रोसेसिंग समय काफी तेज हो सकता है।
 
 ## What are the benefits of using Substreams-powered subgraphs?
 
@@ -64,7 +64,7 @@ There are many benefits to using Firehose, including:
 
 ## Where can developers access more information about Substreams-powered subgraphs and Substreams?
 
-The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+[सबस्ट्रीम documentation](/substreams/introduction/) आपको सबस्ट्रीम modules बनाने का तरीका सिखाएगी।
 
 The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
 

From 7862b655e3c1b3a1d4aec94308af19c78c9e2cc9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 13:41:59 -0500
Subject: [PATCH 3237/3820] New translations tutorial.mdx (Hindi)

---
 website/pages/hi/sps/tutorial.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/sps/tutorial.mdx b/website/pages/hi/sps/tutorial.mdx
index 0f01c720c7e9..ce7aeab4f64f 100644
--- a/website/pages/hi/sps/tutorial.mdx
+++ b/website/pages/hi/sps/tutorial.mdx
@@ -4,7 +4,7 @@ title: "ट्यूटोरियल: Solana पर एक Substreams-शक
 
 Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
 
-## Get Started
+## शुरू करिये
 
 For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
 

From 99a34406a58810e7891a943f63d95e5ebc03e02d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:07:58 -0500
Subject: [PATCH 3238/3820] New translations polymarket.mdx (Romanian)

---
 .../ro/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ro/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/ro/subgraphs/cookbook/polymarket.mdx b/website/pages/ro/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/ro/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 4724ddf9399376e6487395140d177801d953e75d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:07:59 -0500
Subject: [PATCH 3239/3820] New translations polymarket.mdx (French)

---
 .../fr/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/fr/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/fr/subgraphs/cookbook/polymarket.mdx b/website/pages/fr/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/fr/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From f6dd654963de20dae8efb612e4903f287d75b73f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:00 -0500
Subject: [PATCH 3240/3820] New translations polymarket.mdx (Spanish)

---
 .../es/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/es/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/es/subgraphs/cookbook/polymarket.mdx b/website/pages/es/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/es/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 01401c581d6052a93f34533ac324704df52113e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:01 -0500
Subject: [PATCH 3241/3820] New translations polymarket.mdx (Arabic)

---
 .../ar/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ar/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/ar/subgraphs/cookbook/polymarket.mdx b/website/pages/ar/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/ar/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 02eb60d26b21233ac94f88771b4a0fa60173c586 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:02 -0500
Subject: [PATCH 3242/3820] New translations polymarket.mdx (Czech)

---
 .../cs/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/cs/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/cs/subgraphs/cookbook/polymarket.mdx b/website/pages/cs/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/cs/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 64d54014350f8f82cfdb8e2bb2e085f42460cd02 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:03 -0500
Subject: [PATCH 3243/3820] New translations polymarket.mdx (German)

---
 .../de/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/de/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/de/subgraphs/cookbook/polymarket.mdx b/website/pages/de/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/de/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 9120bdc9834ab6513876dc50101b8fb1f3dafdbf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:04 -0500
Subject: [PATCH 3244/3820] New translations polymarket.mdx (Italian)

---
 .../it/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/it/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/it/subgraphs/cookbook/polymarket.mdx b/website/pages/it/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/it/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 32b27ca7f10deeb9e19064eb70907ae7e416325b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:06 -0500
Subject: [PATCH 3245/3820] New translations polymarket.mdx (Japanese)

---
 .../ja/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ja/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/ja/subgraphs/cookbook/polymarket.mdx b/website/pages/ja/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/ja/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 1f7da9fe701240dbf10b41510f67b645fa305a4e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:07 -0500
Subject: [PATCH 3246/3820] New translations polymarket.mdx (Korean)

---
 .../ko/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ko/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/ko/subgraphs/cookbook/polymarket.mdx b/website/pages/ko/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/ko/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 8763d9d81dd0e39feb06505ce94274ab12395e2f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:08 -0500
Subject: [PATCH 3247/3820] New translations polymarket.mdx (Dutch)

---
 .../nl/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/nl/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/nl/subgraphs/cookbook/polymarket.mdx b/website/pages/nl/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/nl/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 77401b8d5ca77a817b4def24d35ee494c73affd8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:09 -0500
Subject: [PATCH 3248/3820] New translations polymarket.mdx (Polish)

---
 .../pl/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/pl/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/pl/subgraphs/cookbook/polymarket.mdx b/website/pages/pl/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/pl/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From e5710f6e5786ec0380e2284e314784e590e90502 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:10 -0500
Subject: [PATCH 3249/3820] New translations polymarket.mdx (Portuguese)

---
 .../pt/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/pt/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/pt/subgraphs/cookbook/polymarket.mdx b/website/pages/pt/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/pt/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From a01f6e1150731830d646a85ba1e2c31500fef190 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:11 -0500
Subject: [PATCH 3250/3820] New translations polymarket.mdx (Russian)

---
 .../ru/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ru/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/ru/subgraphs/cookbook/polymarket.mdx b/website/pages/ru/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/ru/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 1e6f2926c92204f6ef0e8428dd3d68e16a8d4e5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:12 -0500
Subject: [PATCH 3251/3820] New translations polymarket.mdx (Swedish)

---
 .../sv/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/sv/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/sv/subgraphs/cookbook/polymarket.mdx b/website/pages/sv/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/sv/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From f43e18082d06fc7dd540393d5ec8bf3087c0bb0d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:13 -0500
Subject: [PATCH 3252/3820] New translations polymarket.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/tr/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/tr/subgraphs/cookbook/polymarket.mdx b/website/pages/tr/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/tr/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 189df8bba4c11753d9b80ce5ad062da38417ea95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:14 -0500
Subject: [PATCH 3253/3820] New translations polymarket.mdx (Ukrainian)

---
 .../uk/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/uk/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/uk/subgraphs/cookbook/polymarket.mdx b/website/pages/uk/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/uk/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From d0d16b082e2ac3a993ea4e4fb7faba937de1b3b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:15 -0500
Subject: [PATCH 3254/3820] New translations polymarket.mdx (Chinese
 Simplified)

---
 .../zh/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/zh/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/zh/subgraphs/cookbook/polymarket.mdx b/website/pages/zh/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/zh/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From a568521183fe5fd4f73bdfe86af305e5467db070 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:16 -0500
Subject: [PATCH 3255/3820] New translations polymarket.mdx (Urdu (Pakistan))

---
 .../ur/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ur/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/ur/subgraphs/cookbook/polymarket.mdx b/website/pages/ur/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/ur/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From ac5a2848086d4d51b02ecba68f06d3e22ed2c7fb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:17 -0500
Subject: [PATCH 3256/3820] New translations polymarket.mdx (Vietnamese)

---
 .../vi/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/vi/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/vi/subgraphs/cookbook/polymarket.mdx b/website/pages/vi/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/vi/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From a96ddcd60e4197264fb398d8c874062a9fd03729 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:18 -0500
Subject: [PATCH 3257/3820] New translations polymarket.mdx (Marathi)

---
 .../mr/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/mr/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/mr/subgraphs/cookbook/polymarket.mdx b/website/pages/mr/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/mr/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From a4005347d099fd78db7c6b2517b76c288c88af9f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:19 -0500
Subject: [PATCH 3258/3820] New translations polymarket.mdx (Hindi)

---
 .../hi/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/hi/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/hi/subgraphs/cookbook/polymarket.mdx b/website/pages/hi/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/hi/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 4b7432d9e396c4513d2f0d6adc883d9e7cc4d997 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 17:08:20 -0500
Subject: [PATCH 3259/3820] New translations polymarket.mdx (Swahili)

---
 .../sw/subgraphs/cookbook/polymarket.mdx      | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/sw/subgraphs/cookbook/polymarket.mdx

diff --git a/website/pages/sw/subgraphs/cookbook/polymarket.mdx b/website/pages/sw/subgraphs/cookbook/polymarket.mdx
new file mode 100644
index 000000000000..982bae6c05bc
--- /dev/null
+++ b/website/pages/sw/subgraphs/cookbook/polymarket.mdx
@@ -0,0 +1,147 @@
+---
+title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+---
+
+Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+
+## Polymarket Subgraph on Graph Explorer
+
+You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+
+![Polymarket Playground](/img/Polymarket-playground.png)
+
+## How to use the Visual Query Editor
+
+The visual query editor helps you test sample queries from your subgraph.
+
+You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+
+### Example Query: Get the top 5 highest payouts from Polymarket
+
+```
+{
+  redemptions(orderBy: payout, orderDirection: desc, first: 5) {
+    payout
+    redeemer
+    id
+    timestamp
+  }
+}
+```
+
+### Example output
+
+```
+{
+  "data": {
+    "redemptions": [
+      {
+        "id": "0x8fbb68b7c0cbe9aca6024d063a843a23d046b5522270fd25c6a81c511cf517d1_0x3b",
+        "payout": "6274509531681",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929672"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0x7",
+        "payout": "2246253575996",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0x983b71c64b5075fc1179f4e03849af9c727be60de71c9e86e37ad0b3e43f9db9_0x26",
+        "payout": "2135448291991",
+        "redeemer": "0x5a181dcf3eb53a09fb32b20a5a9312fb8d26f689",
+        "timestamp": "1704932625"
+      },
+      {
+        "id": "0x2b2826448fcacde7931828cfcd3cc4aaeac8080fdff1e91363f0589c9b503eca_0xa",
+        "payout": "1917395333835",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1726701528"
+      },
+      {
+        "id": "0xfe82e117201f5169abc822281ccf0469e6b3740fcb4e799d1b599f83b8f11656_0x30",
+        "payout": "1862505580000",
+        "redeemer": "0xfffe4013adfe325c6e02d36dc66e091f5476f52c",
+        "timestamp": "1722929866"
+      }
+    ]
+  }
+}
+```
+
+## Polymarket's GraphQL Schema
+
+The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+
+### Polymarket Subgraph Endpoint
+
+https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
+
+The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+
+![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+
+## How to Get your own API Key
+
+1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
+2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+
+You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+
+100k queries per month are free which is perfect for your side project!
+
+## Additional Polymarket Subgraphs
+
+- [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
+- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+
+## How to Query with the API
+
+You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+
+This following code example will return the exact same output as above.
+
+### Sample Code from node.js
+
+```
+const axios = require('axios');
+
+const graphqlQuery = `{
+  positions(first: 5) {
+    condition
+    outcomeIndex
+  }
+};
+
+const queryUrl = 'https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp'
+
+const graphQLRequest = {
+  method: 'post',
+  url: queryUrl,
+  data: {
+    query: graphqlQuery,
+  },
+};
+
+// Send the GraphQL query
+axios(graphQLRequest)
+  .then((response) => {
+    // Handle the response here
+    const data = response.data.data
+    console.log(data)
+
+  })
+  .catch((error) => {
+    // Handle any errors
+    console.error(error);
+  });
+```
+
+### Additional resources
+
+For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+
+To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From 091997b8b50687065376f1d59b0e10413fbaa4d8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:00 -0500
Subject: [PATCH 3260/3820] New translations introduction.mdx (Portuguese)

---
 website/pages/pt/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pt/substreams/introduction.mdx b/website/pages/pt/substreams/introduction.mdx
index 08ac132ff32b..fcd6309d1334 100644
--- a/website/pages/pt/substreams/introduction.mdx
+++ b/website/pages/pt/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Outros Recursos
 

From 20b394fc60004e5adf2d0be1f9bf1837282802f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:00 -0500
Subject: [PATCH 3261/3820] New translations introduction.mdx (Romanian)

---
 website/pages/ro/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ro/substreams/introduction.mdx b/website/pages/ro/substreams/introduction.mdx
index 25fcfa5a5c2c..088188773a08 100644
--- a/website/pages/ro/substreams/introduction.mdx
+++ b/website/pages/ro/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Additional Resources
 

From 066afd7c2c241d79a4010d8b29b939d8aa0f4d30 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:01 -0500
Subject: [PATCH 3262/3820] New translations introduction.mdx (French)

---
 website/pages/fr/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/substreams/introduction.mdx b/website/pages/fr/substreams/introduction.mdx
index 2025456bb1ff..9ab7b5d091fe 100644
--- a/website/pages/fr/substreams/introduction.mdx
+++ b/website/pages/fr/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Ressources supplémentaires
 

From 70ff7f1bf4c6deb5a1e45a996cf27e983e63592c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:02 -0500
Subject: [PATCH 3263/3820] New translations introduction.mdx (Spanish)

---
 website/pages/es/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/es/substreams/introduction.mdx b/website/pages/es/substreams/introduction.mdx
index 37e38a41fa3d..badfa58521ca 100644
--- a/website/pages/es/substreams/introduction.mdx
+++ b/website/pages/es/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Recursos Adicionales
 

From 1864792f91e8598daaebcd3b52a8281a2a4eaab2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:03 -0500
Subject: [PATCH 3264/3820] New translations introduction.mdx (Arabic)

---
 website/pages/ar/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ar/substreams/introduction.mdx b/website/pages/ar/substreams/introduction.mdx
index 67932e66d726..7e26bf53da36 100644
--- a/website/pages/ar/substreams/introduction.mdx
+++ b/website/pages/ar/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## مصادر إضافية
 

From 55ec0f665d8ccb751a217aaf1a77c9cc868b9c2d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:05 -0500
Subject: [PATCH 3265/3820] New translations introduction.mdx (Czech)

---
 website/pages/cs/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/cs/substreams/introduction.mdx b/website/pages/cs/substreams/introduction.mdx
index eaffe489153b..011e3d7a84fe 100644
--- a/website/pages/cs/substreams/introduction.mdx
+++ b/website/pages/cs/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Další zdroje
 

From c04ed8d4073b0af5ad9e2e78f4110c985cfa77b2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:06 -0500
Subject: [PATCH 3266/3820] New translations introduction.mdx (German)

---
 website/pages/de/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/substreams/introduction.mdx b/website/pages/de/substreams/introduction.mdx
index e4fba67fe1b1..488fd7cba728 100644
--- a/website/pages/de/substreams/introduction.mdx
+++ b/website/pages/de/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Zusätzliche Ressourcen
 

From 66d2cb970ed5d86080c7a84b6c580976a4569932 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:07 -0500
Subject: [PATCH 3267/3820] New translations introduction.mdx (Italian)

---
 website/pages/it/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/it/substreams/introduction.mdx b/website/pages/it/substreams/introduction.mdx
index 5340ce571a9c..8e235ec48ffc 100644
--- a/website/pages/it/substreams/introduction.mdx
+++ b/website/pages/it/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Additional Resources
 

From 26c53c38e4e45c29f31b6b4f015064056e2b2fda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:08 -0500
Subject: [PATCH 3268/3820] New translations introduction.mdx (Japanese)

---
 website/pages/ja/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ja/substreams/introduction.mdx b/website/pages/ja/substreams/introduction.mdx
index d5db32bdae51..e964cbb22b28 100644
--- a/website/pages/ja/substreams/introduction.mdx
+++ b/website/pages/ja/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## その他のリソース
 

From 8653cf2bbd58a6318426eb678b00105d50b1806f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:09 -0500
Subject: [PATCH 3269/3820] New translations introduction.mdx (Korean)

---
 website/pages/ko/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ko/substreams/introduction.mdx b/website/pages/ko/substreams/introduction.mdx
index 25fcfa5a5c2c..088188773a08 100644
--- a/website/pages/ko/substreams/introduction.mdx
+++ b/website/pages/ko/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Additional Resources
 

From 470879160118eb7627e09f62d72be263a179e116 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:10 -0500
Subject: [PATCH 3270/3820] New translations introduction.mdx (Dutch)

---
 website/pages/nl/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/nl/substreams/introduction.mdx b/website/pages/nl/substreams/introduction.mdx
index 25fcfa5a5c2c..088188773a08 100644
--- a/website/pages/nl/substreams/introduction.mdx
+++ b/website/pages/nl/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Additional Resources
 

From e4c543a3669cec20798f3f80c49c2bacd8ce65bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:11 -0500
Subject: [PATCH 3271/3820] New translations introduction.mdx (Polish)

---
 website/pages/pl/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pl/substreams/introduction.mdx b/website/pages/pl/substreams/introduction.mdx
index 25fcfa5a5c2c..088188773a08 100644
--- a/website/pages/pl/substreams/introduction.mdx
+++ b/website/pages/pl/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Additional Resources
 

From cb0b1c237770110d5deda9014a11db4a5d122dfe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:12 -0500
Subject: [PATCH 3272/3820] New translations introduction.mdx (Russian)

---
 website/pages/ru/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ru/substreams/introduction.mdx b/website/pages/ru/substreams/introduction.mdx
index c19c366b6968..de63a2c3e127 100644
--- a/website/pages/ru/substreams/introduction.mdx
+++ b/website/pages/ru/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Дополнительные ресурсы
 

From 943d28b18ed12690ce57f1fc87e239ad07aabfa9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:13 -0500
Subject: [PATCH 3273/3820] New translations introduction.mdx (Swedish)

---
 website/pages/sv/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sv/substreams/introduction.mdx b/website/pages/sv/substreams/introduction.mdx
index 61fd25dca16b..905da35440a1 100644
--- a/website/pages/sv/substreams/introduction.mdx
+++ b/website/pages/sv/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Ytterligare resurser
 

From c3a8abace15cf61f6e9f786b35583d85b17cc8da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:14 -0500
Subject: [PATCH 3274/3820] New translations introduction.mdx (Turkish)

---
 website/pages/tr/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/substreams/introduction.mdx b/website/pages/tr/substreams/introduction.mdx
index 17a39ca7ed7f..c8b3ecd48052 100644
--- a/website/pages/tr/substreams/introduction.mdx
+++ b/website/pages/tr/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Ek Kaynaklar
 

From 34eb0775b3c120c608d60a54d7c73169d2c8e36f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:15 -0500
Subject: [PATCH 3275/3820] New translations introduction.mdx (Ukrainian)

---
 website/pages/uk/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/uk/substreams/introduction.mdx b/website/pages/uk/substreams/introduction.mdx
index f5985fb8bd6d..3bf3b434111d 100644
--- a/website/pages/uk/substreams/introduction.mdx
+++ b/website/pages/uk/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Додаткові матеріали
 

From 07e8d9ab2735da8eba0c75373da2b943888d579e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:16 -0500
Subject: [PATCH 3276/3820] New translations introduction.mdx (Chinese
 Simplified)

---
 website/pages/zh/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/substreams/introduction.mdx b/website/pages/zh/substreams/introduction.mdx
index c8b0d42fd85c..697e4df246be 100644
--- a/website/pages/zh/substreams/introduction.mdx
+++ b/website/pages/zh/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## 其他资源
 

From 2288422a4c1cf6b5cbd6d97377f3b1406bb7bb7f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:17 -0500
Subject: [PATCH 3277/3820] New translations introduction.mdx (Urdu (Pakistan))

---
 website/pages/ur/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ur/substreams/introduction.mdx b/website/pages/ur/substreams/introduction.mdx
index ad59d9b1145e..32a947e6822f 100644
--- a/website/pages/ur/substreams/introduction.mdx
+++ b/website/pages/ur/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## اضافی وسائل
 

From f4b145a103ddf152825d2788bfd903326ef83ad7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:18 -0500
Subject: [PATCH 3278/3820] New translations introduction.mdx (Vietnamese)

---
 website/pages/vi/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/vi/substreams/introduction.mdx b/website/pages/vi/substreams/introduction.mdx
index 24da40248562..bba7e92c4490 100644
--- a/website/pages/vi/substreams/introduction.mdx
+++ b/website/pages/vi/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Additional Resources
 

From 198dfe36037766449fd697d742e26cc71b955f1d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:19 -0500
Subject: [PATCH 3279/3820] New translations introduction.mdx (Marathi)

---
 website/pages/mr/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/mr/substreams/introduction.mdx b/website/pages/mr/substreams/introduction.mdx
index 23f4ecf0937a..10c8560bd46d 100644
--- a/website/pages/mr/substreams/introduction.mdx
+++ b/website/pages/mr/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## अतिरिक्त संसाधने
 

From 4db31082a56de534af132b50a56cbebbe60e5633 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:20 -0500
Subject: [PATCH 3280/3820] New translations introduction.mdx (Hindi)

---
 website/pages/hi/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/substreams/introduction.mdx b/website/pages/hi/substreams/introduction.mdx
index 172f43ebfed2..4f8291d63760 100644
--- a/website/pages/hi/substreams/introduction.mdx
+++ b/website/pages/hi/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Additional Resources
 

From ff9f51c9212035df8c399ed7a496b33a2d5d67e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:21 -0500
Subject: [PATCH 3281/3820] New translations introduction.mdx (Swahili)

---
 website/pages/sw/substreams/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sw/substreams/introduction.mdx b/website/pages/sw/substreams/introduction.mdx
index 25fcfa5a5c2c..088188773a08 100644
--- a/website/pages/sw/substreams/introduction.mdx
+++ b/website/pages/sw/substreams/introduction.mdx
@@ -10,7 +10,7 @@ To start coding right away, check out the [Substreams Quick Start](/substreams/g
 
 Substreams is a powerful parallel blockchain indexing technology designed to enhance performance and scalability within The Graph Network.
 
-## Substreams Capabilities
+## Substreams Benefits
 
 - **Accelerated Indexing**: Boost subgraph indexing time with a parallelized engine for quicker data retrieval and processing.
 - **Multi-Chain Support**: Expand indexing capabilities beyond EVM-based chains, supporting ecosystems like Solana, Injective, Starknet, and Vara.
@@ -37,7 +37,7 @@ fn get_my_block(blk: Block) -> Result<MyBlock, substreams::errors::Error> {
 
 3. The WASM container is sent to a Substreams endpoint for execution. The Substreams provider feeds the WASM container with the blockchain data and the transformations are applied.
 
-4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (for example a SQL database or a Subgraph).
+4. You select a [sink](https://docs.substreams.dev/how-to-guides/sinks), a place where you want to send the transformed data (such as a SQL database or a Subgraph).
 
 ## Additional Resources
 

From 8a0f7b7ec2967f0d94be74a20b937909291f0f4c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:24 -0500
Subject: [PATCH 3282/3820] New translations introduction.mdx (Romanian)

---
 website/pages/ro/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ro/sps/introduction.mdx b/website/pages/ro/sps/introduction.mdx
index aa44f605ce65..a4959772e560 100644
--- a/website/pages/ro/sps/introduction.mdx
+++ b/website/pages/ro/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Overview
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From 5df0d72dc10d790056cb2582cbc69d0977fbce9c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:25 -0500
Subject: [PATCH 3283/3820] New translations devcontainer.mdx (Romanian)

---
 website/pages/ro/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/substreams/developing/devcontainer.mdx b/website/pages/ro/substreams/developing/devcontainer.mdx
index cd65c8d046f8..5b07c96c97ae 100644
--- a/website/pages/ro/substreams/developing/devcontainer.mdx
+++ b/website/pages/ro/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 2d5fd3a6c980fbe6e8712f8d99ce1937201f2ea1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:26 -0500
Subject: [PATCH 3284/3820] New translations introduction.mdx (French)

---
 website/pages/fr/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/sps/introduction.mdx b/website/pages/fr/sps/introduction.mdx
index b6a92d7ba866..62d698fb566d 100644
--- a/website/pages/fr/sps/introduction.mdx
+++ b/website/pages/fr/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Aperçu
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Spécificités⁠
 

From f3ab7dd95e9d31ee378742ad144da99166c6d75b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:27 -0500
Subject: [PATCH 3285/3820] New translations devcontainer.mdx (French)

---
 website/pages/fr/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/substreams/developing/devcontainer.mdx b/website/pages/fr/substreams/developing/devcontainer.mdx
index 0d97d3749b25..f367d9bf0b84 100644
--- a/website/pages/fr/substreams/developing/devcontainer.mdx
+++ b/website/pages/fr/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 7ecb05149fae42fdb02645be3893b77a5e6d1a49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:27 -0500
Subject: [PATCH 3286/3820] New translations introduction.mdx (Spanish)

---
 website/pages/es/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/es/sps/introduction.mdx b/website/pages/es/sps/introduction.mdx
index 50f4dd00d584..634c23f2f009 100644
--- a/website/pages/es/sps/introduction.mdx
+++ b/website/pages/es/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Descripción
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From e9731bb0aed8853f407a4356fbf80804f086556f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:28 -0500
Subject: [PATCH 3287/3820] New translations devcontainer.mdx (Spanish)

---
 website/pages/es/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/substreams/developing/devcontainer.mdx b/website/pages/es/substreams/developing/devcontainer.mdx
index a074eeec7a5d..b57b722919ff 100644
--- a/website/pages/es/substreams/developing/devcontainer.mdx
+++ b/website/pages/es/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 22480ec955bc793911e3505052d648af0e27117c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:30 -0500
Subject: [PATCH 3288/3820] New translations introduction.mdx (Arabic)

---
 website/pages/ar/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ar/sps/introduction.mdx b/website/pages/ar/sps/introduction.mdx
index a3dc1a8131e2..be2346c7f8a6 100644
--- a/website/pages/ar/sps/introduction.mdx
+++ b/website/pages/ar/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## نظره عامة
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From 799e273952e9238876dd942542612f15563ede43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:31 -0500
Subject: [PATCH 3289/3820] New translations devcontainer.mdx (Arabic)

---
 website/pages/ar/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/substreams/developing/devcontainer.mdx b/website/pages/ar/substreams/developing/devcontainer.mdx
index 63a0dd1dae28..fe304438933f 100644
--- a/website/pages/ar/substreams/developing/devcontainer.mdx
+++ b/website/pages/ar/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 1e7b41da78787a399fd1ca5868db213373657d13 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:32 -0500
Subject: [PATCH 3290/3820] New translations introduction.mdx (Czech)

---
 website/pages/cs/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/cs/sps/introduction.mdx b/website/pages/cs/sps/introduction.mdx
index e3b6a68ddfa3..c375b0044d20 100644
--- a/website/pages/cs/sps/introduction.mdx
+++ b/website/pages/cs/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Přehled
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From 90c7b444f76b6631a98944ff8fdd4c4caee8cb44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:33 -0500
Subject: [PATCH 3291/3820] New translations devcontainer.mdx (Czech)

---
 website/pages/cs/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/substreams/developing/devcontainer.mdx b/website/pages/cs/substreams/developing/devcontainer.mdx
index cfa4c45db531..d5d3ae6c9115 100644
--- a/website/pages/cs/substreams/developing/devcontainer.mdx
+++ b/website/pages/cs/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 26abba01c1d533d2bdb5e7b847092615ab03ff81 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:33 -0500
Subject: [PATCH 3292/3820] New translations introduction.mdx (German)

---
 website/pages/de/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/sps/introduction.mdx b/website/pages/de/sps/introduction.mdx
index 238ebe105bf4..1f9e05ca1702 100644
--- a/website/pages/de/sps/introduction.mdx
+++ b/website/pages/de/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Überblick
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Besonderheiten
 

From c89ac5f286710f26d064ece9c8a2aab032895a61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:34 -0500
Subject: [PATCH 3293/3820] New translations devcontainer.mdx (German)

---
 website/pages/de/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/substreams/developing/devcontainer.mdx b/website/pages/de/substreams/developing/devcontainer.mdx
index 3a965b879168..01c436b3a83c 100644
--- a/website/pages/de/substreams/developing/devcontainer.mdx
+++ b/website/pages/de/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 10db3028454246c8fa8b1eff4b608b7e65d2dac9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:35 -0500
Subject: [PATCH 3294/3820] New translations introduction.mdx (Italian)

---
 website/pages/it/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/it/sps/introduction.mdx b/website/pages/it/sps/introduction.mdx
index ded4abf2de07..4b037cfa1a5f 100644
--- a/website/pages/it/sps/introduction.mdx
+++ b/website/pages/it/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Panoramica
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From 382fdcda4e50a9a05460068c9e22ce094b0b0576 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:36 -0500
Subject: [PATCH 3295/3820] New translations devcontainer.mdx (Italian)

---
 website/pages/it/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/substreams/developing/devcontainer.mdx b/website/pages/it/substreams/developing/devcontainer.mdx
index ac79e64539a9..dce31e7aaea9 100644
--- a/website/pages/it/substreams/developing/devcontainer.mdx
+++ b/website/pages/it/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 2617b9067f70d8f9680b8f70ac83c33733766859 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:37 -0500
Subject: [PATCH 3296/3820] New translations introduction.mdx (Japanese)

---
 website/pages/ja/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ja/sps/introduction.mdx b/website/pages/ja/sps/introduction.mdx
index 3d3b505658a3..f7e40c6c4f45 100644
--- a/website/pages/ja/sps/introduction.mdx
+++ b/website/pages/ja/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## 概要
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From da2c0d868da93689ee7a0392ba5857765e838636 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:39 -0500
Subject: [PATCH 3297/3820] New translations devcontainer.mdx (Japanese)

---
 website/pages/ja/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/substreams/developing/devcontainer.mdx b/website/pages/ja/substreams/developing/devcontainer.mdx
index 15b75ad6e38b..2effdd7ed673 100644
--- a/website/pages/ja/substreams/developing/devcontainer.mdx
+++ b/website/pages/ja/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From fae1dbf599a4542bf576f012cae7fd91cf51c87b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:39 -0500
Subject: [PATCH 3298/3820] New translations introduction.mdx (Korean)

---
 website/pages/ko/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ko/sps/introduction.mdx b/website/pages/ko/sps/introduction.mdx
index aa44f605ce65..a4959772e560 100644
--- a/website/pages/ko/sps/introduction.mdx
+++ b/website/pages/ko/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Overview
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From dea6fe3e48a0103ef6c2574d7653f2e0640fb8b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:41 -0500
Subject: [PATCH 3299/3820] New translations devcontainer.mdx (Korean)

---
 website/pages/ko/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/substreams/developing/devcontainer.mdx b/website/pages/ko/substreams/developing/devcontainer.mdx
index cd65c8d046f8..5b07c96c97ae 100644
--- a/website/pages/ko/substreams/developing/devcontainer.mdx
+++ b/website/pages/ko/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From d9c0d9a901f19215e90001d2b6139c0f4b37c66e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:42 -0500
Subject: [PATCH 3300/3820] New translations introduction.mdx (Dutch)

---
 website/pages/nl/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/nl/sps/introduction.mdx b/website/pages/nl/sps/introduction.mdx
index aa44f605ce65..a4959772e560 100644
--- a/website/pages/nl/sps/introduction.mdx
+++ b/website/pages/nl/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Overview
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From f42b426a6ee3209c130c038c9aecec91ca019b95 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:43 -0500
Subject: [PATCH 3301/3820] New translations devcontainer.mdx (Dutch)

---
 website/pages/nl/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/substreams/developing/devcontainer.mdx b/website/pages/nl/substreams/developing/devcontainer.mdx
index 831ca36c6b65..449856e9f38b 100644
--- a/website/pages/nl/substreams/developing/devcontainer.mdx
+++ b/website/pages/nl/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From f45eb7ec852bfb81db838d19a96c519c0cd5d340 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:43 -0500
Subject: [PATCH 3302/3820] New translations introduction.mdx (Polish)

---
 website/pages/pl/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pl/sps/introduction.mdx b/website/pages/pl/sps/introduction.mdx
index aa44f605ce65..a4959772e560 100644
--- a/website/pages/pl/sps/introduction.mdx
+++ b/website/pages/pl/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Overview
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From 0222a0b598075b35de806269ab782373de048208 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:44 -0500
Subject: [PATCH 3303/3820] New translations devcontainer.mdx (Polish)

---
 website/pages/pl/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/substreams/developing/devcontainer.mdx b/website/pages/pl/substreams/developing/devcontainer.mdx
index cd65c8d046f8..5b07c96c97ae 100644
--- a/website/pages/pl/substreams/developing/devcontainer.mdx
+++ b/website/pages/pl/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 40d62017aff57b78a92c2e1405b577c9c4eab1ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:45 -0500
Subject: [PATCH 3304/3820] New translations introduction.mdx (Portuguese)

---
 website/pages/pt/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pt/sps/introduction.mdx b/website/pages/pt/sps/introduction.mdx
index f7c25a77aa9c..5a54f1aa9682 100644
--- a/website/pages/pt/sps/introduction.mdx
+++ b/website/pages/pt/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introudução a Subgraphs Movidos pelo Substreams
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Visão geral
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Especificações
 

From c770d6771146f288b99d2c035ff1057cc1f994ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:46 -0500
Subject: [PATCH 3305/3820] New translations devcontainer.mdx (Portuguese)

---
 website/pages/pt/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/substreams/developing/devcontainer.mdx b/website/pages/pt/substreams/developing/devcontainer.mdx
index f7e056d95884..ce65b8e75917 100644
--- a/website/pages/pt/substreams/developing/devcontainer.mdx
+++ b/website/pages/pt/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 1a70a79a87a840f39a627b0a4c1d0fb208da588d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:48 -0500
Subject: [PATCH 3306/3820] New translations introduction.mdx (Russian)

---
 website/pages/ru/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ru/sps/introduction.mdx b/website/pages/ru/sps/introduction.mdx
index 9082acadcad8..7cf6d5d36096 100644
--- a/website/pages/ru/sps/introduction.mdx
+++ b/website/pages/ru/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Обзор
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Специфические особенности
 

From 8c32b0e04210b38ee5e646d288e039e1d7a414cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:49 -0500
Subject: [PATCH 3307/3820] New translations devcontainer.mdx (Russian)

---
 website/pages/ru/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/substreams/developing/devcontainer.mdx b/website/pages/ru/substreams/developing/devcontainer.mdx
index 578627b34934..1bacfdafa94e 100644
--- a/website/pages/ru/substreams/developing/devcontainer.mdx
+++ b/website/pages/ru/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 54d55d68254a2c4b0db09fd97d57ee570c2102ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:50 -0500
Subject: [PATCH 3308/3820] New translations introduction.mdx (Swedish)

---
 website/pages/sv/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sv/sps/introduction.mdx b/website/pages/sv/sps/introduction.mdx
index cddf33d6b2f6..f57c30edd98a 100644
--- a/website/pages/sv/sps/introduction.mdx
+++ b/website/pages/sv/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Översikt
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From 258ac6c5b9d41c5702257849738a8ad697c3f491 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:51 -0500
Subject: [PATCH 3309/3820] New translations devcontainer.mdx (Swedish)

---
 website/pages/sv/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/substreams/developing/devcontainer.mdx b/website/pages/sv/substreams/developing/devcontainer.mdx
index 22bb76d5aa0d..c30d8bf26912 100644
--- a/website/pages/sv/substreams/developing/devcontainer.mdx
+++ b/website/pages/sv/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 2b9d2b91237d823660f50f470aa746f7bbad3ca5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:52 -0500
Subject: [PATCH 3310/3820] New translations introduction.mdx (Turkish)

---
 website/pages/tr/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/sps/introduction.mdx b/website/pages/tr/sps/introduction.mdx
index c899d004a469..6ba2fac60cc3 100644
--- a/website/pages/tr/sps/introduction.mdx
+++ b/website/pages/tr/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Genel Bakış
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Ayrıntılar
 

From c0a614a08654cec45ef604a7b0baaf0e97418ce8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:53 -0500
Subject: [PATCH 3311/3820] New translations devcontainer.mdx (Turkish)

---
 website/pages/tr/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/substreams/developing/devcontainer.mdx b/website/pages/tr/substreams/developing/devcontainer.mdx
index b600994dae5f..8ea9c7214472 100644
--- a/website/pages/tr/substreams/developing/devcontainer.mdx
+++ b/website/pages/tr/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From d2c91b5dca49f3a5e7ca2a115a95eee74db12189 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:54 -0500
Subject: [PATCH 3312/3820] New translations introduction.mdx (Ukrainian)

---
 website/pages/uk/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/uk/sps/introduction.mdx b/website/pages/uk/sps/introduction.mdx
index 43f6b77fea0b..ecb29b6ea339 100644
--- a/website/pages/uk/sps/introduction.mdx
+++ b/website/pages/uk/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Overview
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From 87b18f2ee122ad0adecb2da2c5484f4045d2bafa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:55 -0500
Subject: [PATCH 3313/3820] New translations devcontainer.mdx (Ukrainian)

---
 website/pages/uk/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/substreams/developing/devcontainer.mdx b/website/pages/uk/substreams/developing/devcontainer.mdx
index 83f756d6a072..1e66c8315aa9 100644
--- a/website/pages/uk/substreams/developing/devcontainer.mdx
+++ b/website/pages/uk/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 29ff3bc0109e43f521ca11b87a5bdc4be5dac7c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:56 -0500
Subject: [PATCH 3314/3820] New translations introduction.mdx (Chinese
 Simplified)

---
 website/pages/zh/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/sps/introduction.mdx b/website/pages/zh/sps/introduction.mdx
index bfa03da84e41..31fc05587825 100644
--- a/website/pages/zh/sps/introduction.mdx
+++ b/website/pages/zh/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## 概述
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From 49b156caf0d85820578403cc807d0c6da69254b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:57 -0500
Subject: [PATCH 3315/3820] New translations devcontainer.mdx (Chinese
 Simplified)

---
 website/pages/zh/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/substreams/developing/devcontainer.mdx b/website/pages/zh/substreams/developing/devcontainer.mdx
index 6e91f0478261..33e466b35f14 100644
--- a/website/pages/zh/substreams/developing/devcontainer.mdx
+++ b/website/pages/zh/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 7b3e12ac6720e54845034f946ae4222c2a6ec55c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:57 -0500
Subject: [PATCH 3316/3820] New translations introduction.mdx (Urdu (Pakistan))

---
 website/pages/ur/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ur/sps/introduction.mdx b/website/pages/ur/sps/introduction.mdx
index e4bef68a6f9b..0ef9d249a293 100644
--- a/website/pages/ur/sps/introduction.mdx
+++ b/website/pages/ur/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## جائزہ
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From cf4be20783450375bb0274e1af21d6c6f0db0b0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:59 -0500
Subject: [PATCH 3317/3820] New translations devcontainer.mdx (Urdu (Pakistan))

---
 website/pages/ur/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/substreams/developing/devcontainer.mdx b/website/pages/ur/substreams/developing/devcontainer.mdx
index 18906ee8ecdc..5b145e7be7d4 100644
--- a/website/pages/ur/substreams/developing/devcontainer.mdx
+++ b/website/pages/ur/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From a1e0b93cabffd57e1c9910e1b86c4041408a2480 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:50:59 -0500
Subject: [PATCH 3318/3820] New translations introduction.mdx (Vietnamese)

---
 website/pages/vi/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/vi/sps/introduction.mdx b/website/pages/vi/sps/introduction.mdx
index aae378c1097c..6b6a4e485c2b 100644
--- a/website/pages/vi/sps/introduction.mdx
+++ b/website/pages/vi/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Tổng quan
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From dff3238438548bf748fc318cec0f4f5ab920182c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:51:00 -0500
Subject: [PATCH 3319/3820] New translations devcontainer.mdx (Vietnamese)

---
 website/pages/vi/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/substreams/developing/devcontainer.mdx b/website/pages/vi/substreams/developing/devcontainer.mdx
index 8b74ed7a23ac..fbb4ae4fae27 100644
--- a/website/pages/vi/substreams/developing/devcontainer.mdx
+++ b/website/pages/vi/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 9a4544d246a3adaf651113c06bf6e348b8d2da11 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:51:02 -0500
Subject: [PATCH 3320/3820] New translations introduction.mdx (Marathi)

---
 website/pages/mr/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/mr/sps/introduction.mdx b/website/pages/mr/sps/introduction.mdx
index 3b1c9984591d..0c3244040894 100644
--- a/website/pages/mr/sps/introduction.mdx
+++ b/website/pages/mr/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## सविश्लेषण
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From 7acc01eae4946ebe40ede7c112f088fb2c8798d0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:51:03 -0500
Subject: [PATCH 3321/3820] New translations devcontainer.mdx (Marathi)

---
 website/pages/mr/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/substreams/developing/devcontainer.mdx b/website/pages/mr/substreams/developing/devcontainer.mdx
index d96285ea2b16..c22258476f4f 100644
--- a/website/pages/mr/substreams/developing/devcontainer.mdx
+++ b/website/pages/mr/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 839f05f19c1d4f7fbf6d18e121a51ea3755f4b52 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:51:04 -0500
Subject: [PATCH 3322/3820] New translations introduction.mdx (Hindi)

---
 website/pages/hi/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/sps/introduction.mdx b/website/pages/hi/sps/introduction.mdx
index 1867d6e05f01..6ec6c3a178ed 100644
--- a/website/pages/hi/sps/introduction.mdx
+++ b/website/pages/hi/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: सबस्ट्रीम-पावर्ड सबग्राफ का परिचय
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## अवलोकन
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### विशिष्टताएँ
 

From 6c065ca7489b74811494f4a4efeed40d5d375d86 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:51:05 -0500
Subject: [PATCH 3323/3820] New translations devcontainer.mdx (Hindi)

---
 website/pages/hi/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/substreams/developing/devcontainer.mdx b/website/pages/hi/substreams/developing/devcontainer.mdx
index 750ab6df0ce9..b7eec38ff0c4 100644
--- a/website/pages/hi/substreams/developing/devcontainer.mdx
+++ b/website/pages/hi/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From eacd431a88c5057ba8b1a43feefe1b690a63b913 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:51:06 -0500
Subject: [PATCH 3324/3820] New translations introduction.mdx (Swahili)

---
 website/pages/sw/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/sw/sps/introduction.mdx b/website/pages/sw/sps/introduction.mdx
index aa44f605ce65..a4959772e560 100644
--- a/website/pages/sw/sps/introduction.mdx
+++ b/website/pages/sw/sps/introduction.mdx
@@ -2,11 +2,11 @@
 title: Introduction to Substreams-Powered Subgraphs
 ---
 
-Boost your subgraph’s efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
+Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
 
 ## Overview
 
-Use a Substreams package (`.spkg`) as a data source, to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
+Use a Substreams package (`.spkg`) as a data source to give your subgraph access to a stream of pre-indexed blockchain data. This enables more efficient and scalable data handling, especially with large or complex blockchain networks.
 
 ### Specifics
 

From 1045aa7ce2d56d980c5fd7fd4de706ac855871c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 27 Jan 2025 19:51:07 -0500
Subject: [PATCH 3325/3820] New translations devcontainer.mdx (Swahili)

---
 website/pages/sw/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/substreams/developing/devcontainer.mdx b/website/pages/sw/substreams/developing/devcontainer.mdx
index cd65c8d046f8..5b07c96c97ae 100644
--- a/website/pages/sw/substreams/developing/devcontainer.mdx
+++ b/website/pages/sw/substreams/developing/devcontainer.mdx
@@ -21,7 +21,7 @@ In the Dev Container, you can either build or import your own `substreams.yaml`
 ### Options
 
 - **Minimal**: Starts you with the raw block `.proto` and requires development. This path is intended for experienced users.
-- **Non-Minimal**: Extracts filtered data using network-specific cache and Protobufs from the corresponding Foundational Modules that are built and maintained by the StreamingFast team.
+- **Non-Minimal**: Extracts filtered data using network-specific caches and Protobufs taken from corresponding foundational modules (maintained by the StreamingFast team). This path generates a working Substreams out of the box.
 
 To share your work with the broader community, publish your `.spkg` to [Substreams registry](https://substreams.dev/) using:
 

From 60d87e71ec765c9854ee99ef24bd419f8dfb26ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 28 Jan 2025 11:01:14 -0500
Subject: [PATCH 3326/3820] New translations glossary.mdx (Portuguese)

---
 website/pages/pt/resources/glossary.mdx | 80 ++++++++++++-------------
 1 file changed, 40 insertions(+), 40 deletions(-)

diff --git a/website/pages/pt/resources/glossary.mdx b/website/pages/pt/resources/glossary.mdx
index 92b6d4912f0e..a8d1056835d0 100644
--- a/website/pages/pt/resources/glossary.mdx
+++ b/website/pages/pt/resources/glossary.mdx
@@ -2,82 +2,82 @@
 title: Glossário
 ---
 
-- **The Graph**: A decentralized protocol for indexing and querying data.
+- **The Graph:** Um protocolo descentralizado para indexação e query de dados.
 
-- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+- **Query:** Uma solicitação de dados. No The Graph, um query é uma solicitação por dados de um subgraph que será respondida por um Indexador.
 
-- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+- **GraphQL:** Uma linguagem de queries para APIs e um runtime (programa de execução) para realizar esses queries com os dados existentes. O The Graph usa a GraphQL para fazer queries de subgraphs.
 
-- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+- **Ponto de Execução**: Um URL que pode ser usado para fazer queries. O ponto final de execução para o Subgraph Studio é `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>`, e o do Graph Explorer é `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. O ponto final do Graph Explorer é usado para fazer queries de subgraphs na rede descentralizada do The Graph.
 
-- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+- **Subgraph:** Uma API aberta que extrai, processa, e guarda dados de uma blockchain para facilitar queries via a GraphQL. Os programadores podem construir, lançar, e editar subgraphs na The Graph Network. Indexado, o subgraph está sujeito a queries por quem quiser solicitar.
 
-- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+- **Indexador**: Um participante da rede que executa nodes de indexação para indexar dados de blockchains e servir queries da GraphQL.
 
-- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+- **Fluxos de Receita de Indexadores:** Os Indexadores são recompensados em GRT com dois componentes: Rebates de taxa de query e recompensas de indexação.
 
-  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+  1. **Rebates de Taxa de Query**: Pagamentos de consumidores de subgraphs por servir queries na rede.
 
-  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+  2. **Recompensas de Indexação**: São recebidas por Indexadores por indexar subgraphs, e geradas via a emissão anual de 3% de GRT.
 
-- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+- \*\*Auto-Stake (Stake Próprio) do Indexador: A quantia de GRT que os Indexadores usam para participar na rede descentralizada. A quantia mínima é 100.000 GRT, e não há limite máximo.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+- **Capacidade de Delegação**: A quantia máxima de GRT que um Indexador pode aceitar dos Delegantes. Os Indexadores só podem aceitar até 16 vezes o seu Auto-Stake, e mais delegações resultam em recompensas diluídas. Por exemplo: se um Indexador tem um Auto-Stake de 1 milhão de GRT, a capacidade de delegação é 16 milhões. Porém, os Indexadores só podem aumentar a sua Capacidade de Delegação se aumentarem também o seu Auto-Stake.
 
-- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+- **Indexador de Atualizações**: Um Indexador de reserva para queries não servidos por outros Indexadores na rede. Este Indexador não compete com outros Indexadores.
 
-- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+- **Delegante:** Um participante da rede que possui GRT e delega uma quantia para Indexadores, permitindo que esses aumentem o seu stake em subgraphs. Em retorno, os Delegantes recebem uma porção das Recompensas de Indexação recebidas pelos Indexadores por processar subgraphs.
 
-- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+- **Taxa de Delegação**: Uma taxa de 0,5% paga por Delegantes quando delegam GRT a Indexadores. O GRT usado para pagar a taxa é queimado.
 
-- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+- **Curador:** Um participante da rede que identifica subgraphs de qualidade e sinaliza GRT para eles em troca de ações de curadoria. Quando os Indexadores resgatam as taxas de query em um subgraph, 10% é distribuído para os Curadores desse subgraph. Há uma correlação positiva entre a quantia de GRT sinalizada e o número de Indexadores a indexar um subgraph.
 
-- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+- \*\*Taxa de Curadoria: Uma taxa de 1% paga pelos Curadores quando sinalizam GRT em subgraphs. O GRT usado para pagar a taxa é queimado.
 
-- **Data Consumer**: Any application or user that queries a subgraph.
+- Consumidor de Dados: Qualquer aplicativo ou utilizador que faz queries para um subgraph.
 
-- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+- \*\*Programador de Subgraph: Um programador que constrói e lança um subgraph à rede descentralizada do The Graph.
 
-- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+- **Manifest de Subgraph:** Um arquivo YAML que descreve o schema, fontes de dados, e outros metadados de um subgraph. [Veja um exemplo](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml).
 
-- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+- **Epoch:** Uma unidade de tempo na rede. Um epoch atualmente dura 6.646 blocos, ou cerca de um dia.
 
-- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+- \*\*Alocação: Um Indexador pode alocar o seu stake total em GRT (incluindo o stake dos Delegantes) em subgraphs editados na rede descentralizada do The Graph. As alocações podem ter estados diferentes:
 
-  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Ativa:** Uma alocação é considerada ativa quando é criada on-chain. Isto se chama abrir uma alocação, e indica à rede que o Indexador está a indexar e servir consultas ativamente para um subgraph particular. Alocações ativas acumulam recompensas de indexação proporcionais ao sinal no subgraph, e à quantidade de GRT alocada.
 
-  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+  2. **Fechada**: Um Indexador pode resgatar as recompensas acumuladas em um subgraph selecionado ao enviar uma Prova de Indexação (POI) recente e válida. Isto se chama "fechar uma alocação". Uma alocação deve ter ficado aberta por, no mínimo, um epoch antes que possa ser fechada. O período máximo de alocação é de 28 epochs; se um indexador deixar uma alocação aberta por mais que isso, ela se torna uma alocação obsoleta. Quando uma alocação está **Fechada**, um Pescador ainda pode abrir uma disputa contra um Indexador por servir dados falsos.
 
-- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+- **Subgraph Studio**: um dApp (aplicativo descentralizado) poderoso para a construção, lançamento e edição de subgraphs.
 
-- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+- **Pescadores**: Um papel na Graph Network cumprido por participantes que monitoram a precisão e integridade dos dados servidos pelos Indexadores. Quando um Pescador identifica uma resposta de query ou uma POI que acreditam ser incorreta, ele pode iniciar uma disputa contra o Indexador. Se a disputa der um veredito a favor do Pescador, o Indexador é cortado, ou seja, perderá 2.5% do seu auto-stake de GRT. Desta quantidade, 50% é dado ao Pescador como recompensa pela sua vigilância, e os 50% restantes são retirados da circulação (queimados). Este mecanismo é desenhado para encorajar Pescadores a ajudar a manter a confiança na rede ao garantir que Indexadores sejam responsabilizados pelos dados que providenciam.
 
-- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+- **Árbitros**: Participantes da rede apontados por um processo de governança. O Árbitro decide o resultado de disputas de indexação e consultas, e a sua meta é maximizar a utilidade e confiança da Graph Network.
 
-- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+- Corte: Os Indexadores podem tomar cortes no seu self-stake de GRT por fornecer uma prova de indexação (POI) incorreta ou servir dados imprecisos. A percentagem de corte é um parâmetro do protocolo, atualmente configurado em 2,5% do auto-stake de um Indexador. 50% do GRT cortado vai ao Pescador que disputou os dados ou POI incorretos. Os outros 50% são queimados.
 
-- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+- **Recompensas de Indexação**: As recompensas que os Indexadores recebem por indexar subgraphs, distribuídas em GRT.
 
-- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+- **Recompensas de Delegação**: As recompensas que os Delegantes recebem por delegar GRT a Indexadores, distribuídas em GRT.
 
-- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+- **GRT**: O token de utilidade do The Graph, que oferece incentivos económicos a participantes da rede por contribuir.
 
-- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+- **POI (Prova de Indexação)**: Quando um Indexador fecha a sua alocação e quer resgatar as suas recompensas de indexação acumuladas em um certo subgraph, ele deve apresentar uma Prova de Indexação (POI) válida e recente. Os Pescadores podem disputar a POI providenciada por um Indexador; disputas resolvidas a favor do Pescador causam um corte para o Indexador.
 
-- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+- **Graph Node**: O componente que indexa subgraphs e disponibiliza os dados resultantes abertos a queries através de uma API GraphQL. Assim, ele é essencial ao stack de indexadores, e operações corretas de um Graph Node são cruciais para executar um indexador com êxito.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Agente de Indexador**: Parte do stack do indexador. Ele facilita as interações do Indexer on-chain, inclusive registos na rede, gestão de lançamentos de Subgraph ao(s) seu(s) Graph Node(s), e gestão de alocações.
 
-- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+- **The Graph Client**: Uma biblioteca para construir dApps baseados em GraphQL de maneira descentralizada.
 
-- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+- **Graph Explorer**: Um dApp desenhado para que participantes da rede explorem subgraphs e interajam com o protocolo.
 
-- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+- **Graph CLI**: Uma ferramenta de interface de comando de linha para construções e lançamentos no The Graph.
 
-- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+- **Período de Recarga**: O tempo restante até que um Indexador que mudou os seus parâmetros de delegação possa fazê-lo novamente.
 
-- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+- Ferramentas de Transferência para L2: Contratos inteligentes e interfaces que permitem que os participantes na rede transfiram ativos relacionados à rede da mainnet da Ethereum ao Arbitrum One. Os participantes podem transferir GRT delegado, subgraphs, ações de curadoria, e o Auto-Stake do Indexador.
 
-- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+- **Atualização de um subgraph**: O processo de lançar uma nova versão de subgraph com atualizações ao manifest, schema e mapeamentos do subgraph.
 
-- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).
+- **Migração**: O processo de movimentar ações de curadoria da versão antiga de um subgraph à versão nova do mesmo (por ex., quando a v.0.0.1 é atualizada à v.0.0.2).

From 12f1bb9fb26f31ec1dfe01d399663cfeba238980 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 28 Jan 2025 11:01:15 -0500
Subject: [PATCH 3327/3820] New translations delegating.mdx (Portuguese)

---
 .../pages/pt/resources/roles/delegating.mdx   | 74 +++++++++----------
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/website/pages/pt/resources/roles/delegating.mdx b/website/pages/pt/resources/roles/delegating.mdx
index 357a600ee8b0..345e74d71b71 100644
--- a/website/pages/pt/resources/roles/delegating.mdx
+++ b/website/pages/pt/resources/roles/delegating.mdx
@@ -2,54 +2,54 @@
 title: Delegação
 ---
 
-To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+Para começar a delegar, veja [esta página](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
 ## Visão geral
 
-Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+Os Delegantes ganham GRT com a delegação de GRT a Indexadores, o que ajuda com a segurança e estabilidade da rede.
 
 <VideoEmbed youtube="VACg8bitnVc" />
 
-## Benefits of Delegating
+## As Vantagens de Delegar
 
-- Strengthen the network’s security and scalability by supporting Indexers.
-- Earn a portion of rewards generated by the Indexers.
+- O apoio a Indexadores aumenta a segurança e escalabilidade da rede.
+- Rende uma porção das recompensas geradas pelos Indexadores.
 
-## How Does Delegation Work?
+## Como Funciona a Delegação?
 
-Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+Os Delegantes ganham recompensas em GRT do(s) Indexador(es) a quem escolhem delegar.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:
+A habilidade de um Indexador em processar queries e ganhar recompensas depende de três fatores importantes:
 
-1. The Indexer's Self-Stake (GRT staked by the Indexer).
-2. The total GRT delegated to them by Delegators.
-3. The price the Indexer sets for queries.
+1. O Auto-Stake do Indexador (GRT investido pelo Indexador).
+2. O total de GRT delegado a ele por Delegantes.
+3. O preço por queries determinado pelo Indexador.
 
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+Quanto mais GRT for investido e delegado a um Indexador, mais queries ele pode servir, o que leva potencialmente a mais recompensas tanto para o Delegante quanto o Indexador.
 
-### What is Delegation Capacity?
+### O Que É Capacidade de Delegação?
 
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+É a quantia máxima de GRT que um Indexador pode aceitar dos Delegantes, baseado no Auto-Stake do Indexador.
 
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+A The Graph Network inclui uma proporção de delegação de 16; ou seja, um indexador pode aceitar até 16 vezes o seu Auto-Stake em GRT delegado.
 
-For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+Por exemplo, se um Indexador tem um Auto-Stake de 1 mihão de GRT, a sua Capacidade de Delegação é de 16 milhões.
 
-### Why Does Delegation Capacity Matter?
+### Por Que a Capacidade de Delegação Importa?
 
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+Se um Indexador passar da sua Capacidade de Delegação, as recompensas para todos os Delegantes são diluídas, porque o excesso do GRT delegado não pode ser usado efetivamente dentro do protocolo.
 
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+Ou seja, é importante que os Delegantes avaliem a Capacidade de Delegação atual dos Indexadores antes de selecionar um.
 
-Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+Para aumentar a sua Capacidade de Delegação, os Indexadores podem aumentar o seu Auto-Stake, assim levantando o limite de tokens delegados.
 
-## Delegation on The Graph
+## Delegação no The Graph
 
 <VideoEmbed youtube="HVyIrMcNu7I" />
 
-> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+> Este guia não cobre passos como a configuração do MetaMask. A comunidade do Ethereum fornece um recurso compreensivo sobre carteiras [neste link](https://ethereum.org/en/wallets/).
 
-There are two sections in this guide:
+Há duas secções neste guia:
 
 - Os riscos de delegar tokens na Graph Network
 - Como calcular retornos esperados como um Delegante
@@ -58,7 +58,7 @@ There are two sections in this guide:
 
 Veja abaixo os riscos principais de ser um Delegante no protocolo.
 
-### The Delegation Tax
+### Taxa de Delegação
 
 Os Delegantes não podem ser punidos por mau comportamento, mas há uma taxa sobre Delegantes, para desencorajar más decisões que possam ferir a integridade da rede.
 
@@ -68,19 +68,19 @@ Como Delegante, é importante entender que:
 
 - Por segurança, calcule o seu retorno potencial quando delegar para um Indexador. Por exemplo, pode-se calcular o número de dias até que tenha recuperado a taxa de 0,5% da sua delegação.
 
-### The Undelegation Period
+### Período de Retirada de Delegação
 
-When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+Quando um Delegante escolhe retirar a sua Delegação, os seus tokens estão sujeitos a um período de retirada de 28 dias.
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
+Ou seja, ele não pode transferir os seus tokens ou ganhar recompensas por 28 dias.
 
-After the undelegation period, GRT will return to your crypto wallet.
+Após o período de retirada, o GRT será devolvido à sua carteira de criptomoedas.
 
 ### Qual a Importância Disto?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+Se escolher um Indexador que não é de confiança, ou não fez um bom trabalho, talvez queira cancelar a sua delegação, o que implica em sacrificar muitas oportunidades de recompensa. Isto pode ser tão lamentável quanto queimar GRT.
 
-As a result, it’s recommended that you choose an Indexer wisely.
+Por isso, recomendamos que tenha cuidado ao escolher um Indexador.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Unbonding de delegação](/img/Delegation-Unbonding.png) _Perceba a taxa de 0,5% na Interface de Delegação, assim como o período de unbonding de 28 dias._
@@ -100,21 +100,21 @@ Para entender como escolher um Indexador confiável, entenda os Parâmetros de D
 
 - **Porção da Taxa de Query** — Parecido com a Porção da Recompensa de Indexação, mas se aplica aos retornos nas taxas de query coletadas pelo Indexador.
 
-- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+- Recomendamos altamente que explore o [Discord do The Graph](https://discord.gg/graphprotocol) para determinar quais Indexadores tem as melhores reputações sociais e técnicas, e quais recompensam os Delegantes consistentemente.
 
-- Many Indexers are active in Discord and will be happy to answer your questions.
+- Muitos Indexadores estão ativos no Discord, e estão dispostos a responder as suas perguntas.
 
 ## Como calcular o retorno esperado dos Delegantes
 
-> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+> Calcule o retorno sobre a sua delegação [aqui](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-A Delegator must consider a variety of factors to determine a return:
+Um Delegante deve considerar os seguintes fatores para determinar um retorno:
 
-An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+A habilidade de um Indexador de usar o GRT disponível a ele impacta as suas recompensas.
 
-If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+Se um Indexador não alocar todo o GRT ao seu dispor, ele pode não maximizar os ganhos potenciais tanto para si mesmo quanto para os seus Delegantes.
 
-Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+Os Indexadores podem fechar uma alocação e resgatar recompensas a qualquer momento entre o período de 1 a 28 dias. Porém, se as recompensas não forem resgatadas, as recompensas totais podem parecer menores, mesmo se uma percentagem não tiver sido resgatada ainda.
 
 ### Como considerar as porções das taxas de query e de indexação
 

From 6ba341846f636a643d9613a06b611d4349522b48 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 28 Jan 2025 11:01:17 -0500
Subject: [PATCH 3328/3820] New translations tokenomics.mdx (Portuguese)

---
 website/pages/pt/resources/tokenomics.mdx | 50 +++++++++++------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/website/pages/pt/resources/tokenomics.mdx b/website/pages/pt/resources/tokenomics.mdx
index 53ffc18bfee5..8dd6b1dd31ff 100644
--- a/website/pages/pt/resources/tokenomics.mdx
+++ b/website/pages/pt/resources/tokenomics.mdx
@@ -47,56 +47,56 @@ If you're reading this, you're capable of becoming a Delegator right now by head
 
 Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
 
-Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+Desde 11 de abril de 2024, os programadores de subgraphs podem curar o seu subgraph com, no mínimo, 3.000 GRT. Porém, este número pode ser impactado pela atividade na rede e participação na comunidade.
 
-Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+Os Curadores pagam uma taxa de curadoria de 1% ao curar um subgraph novo. Esta taxa de curadoria é queimada, de modo a reduzir a reserva de GRT.
 
-## Developers
+## Programadores
 
-Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+Os programadores constroem e fazem queries em subgraphs para retirar dados da blockchain. Como os subgraphs têm o código aberto, os programadores podem carregar dados da blockchain em seus dApps com queries nos subgraphs existentes. Os programadores pagam por queries feitos em GRT, que é distribuído aos participantes da rede.
 
 ### Como criar um Subgraph
 
-Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+Para indexar dados na blockchain, os programadores podem [criar um subgraph](]/developing/creating-a-subgraph/) — um conjunto de instruções para Indexadores sobre quais dados devem ser servidos aos consumidores.
 
-Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+Depois que os programadores tiverem criado e testado o seu subgraph, eles poderão [editá-lo](/subgraphs/developing/publishing/publishing-a-subgraph/) na rede descentralizada do The Graph.
 
 ### Como fazer queries um Subgraph existente
 
-Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+Depois que um subgraph for [editado](/subgraphs/developing/publishing/publishing-a-subgraph/) na rede descentralizada do The Graph, qualquer um poderá criar uma chave API, depositar GRT no seu saldo de cobrança, e consultar o subgraph em um query.
 
-Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+Os Subgraphs [recebem queries pelo GraphQL](/subgraphs/querying/introduction/), e as taxas de query são pagas em GRT no [Subgraph Studio](https://thegraph.com/studio/). As taxas de query são distribuídas a participantes da rede com base nas suas contribuições ao protocolo.
 
-1% of the query fees paid to the network are burned.
+1% das taxas de query pagas à rede é queimado.
 
-## Indexers (Earn GRT)
+## Indexadores (Ganham GRT)
 
-Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+Os Indexadores são o núcleo do The Graph: operam o equipamento e o software independentes que movem a rede descentralizada do The Graph. Eles servem dados a consumidores baseado em instruções de subgraphs.
 
-Indexers can earn GRT rewards in two ways:
+Os Indexadores podem ganhar recompensas em GRT de duas maneiras:
 
-1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+1. **Taxas de query**: GRT pago, por programadores ou utilizadores, para queries de dados de subgraph. Taxas de query são distribuídas diretamente a Indexadores conforme a função de rebate exponencial (veja o GIP [aqui](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
 
-2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+2. **Recompensas de indexação**: a emissão anual de 3% é distribuída aos Indexadores com base no número de subgraphs que indexam. Estas recompensas os incentivam a indexar subgraphs, às vezes antes das taxas de query começarem, de modo a acumular e enviar Provas de Indexação (POIs) que verificam que indexaram dados corretamente.
 
-Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+Cada subgraph recebe uma porção da emissão total do token na rede, com base na quantia do sinal de curadoria do subgraph. Essa quantia é então recompensada aos Indexadores com base no seu stake alocado no subgraph.
 
-In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+Para executar um node de indexação, os Indexadores devem fazer um stake de 100.000 GRT ou mais com a rede. Os mesmos são incentivados a fazer um stake de GRT, proporcional à quantidade de queries que servem.
 
-Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+Os Indexadores podem aumentar suas alocações de GRT nos subgraphs ao aceitar delegações de GRT de Delegantes; também podem aceitar até 16 vezes a quantia do seu stake inicial. Se um Indexador se tornar "excessivamente delegado" (por ex., com seu stake inicial multiplicado mais de 16 vezes), ele não poderá usar o GRT adicional dos Delegantes até aumentar o seu próprio stake na rede.
 
-The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+A quantidade de recompensas recebidas por um Indexador pode variar com base no seu auto-stake, delegação aceita, qualidade de serviço, e muito mais fatores.
 
-## Token Supply: Burning & Issuance
+## Reserva de Tokens: Queima e Emissão
 
-The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+A reserva inicial de tokens é de 10 bilhões de GRT, com um alvo de emissão de 3% novos ao ano para recompensar os Indexadores por alocar stake em subgraphs. Portanto, a reserva total de tokens GRT aumentará por 3% a cada ano à medida que tokens novos são emitidos para Indexadores, pela sua contribuição à rede.
 
-The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+O The Graph é projetado com vários mecanismos de queima para compensar pela emissão de novos tokens. Aproximadamente 1% da reserva de GRT é queimado todo ano, através de várias atividades na rede, e este número só aumenta conforme a atividade na rede cresce. Estas atividades de queima incluem: uma taxa de delegação de 0,5% sempre que um Delegante delega GRT a um Indexador; uma taxa de curadoria de 1% quando Curadores sinalizam em um subgraph; e 1% de taxas de query por dados de blockchain.
 
-![Total burned GRT](/img/total-burned-grt.jpeg)
+[Total de GRT Queimado](/img/total-burned-grt.jpeg)
 
-In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+Além destas atividades recorrentes de queima, o token GRT também tem um mecanismo de corte para penalizar comportamentos maliciosos ou irresponsáveis pelos Indexadores. Se um Indexador for cortado, é queimado 50% das suas recompensas de indexação no epoch (e a outra metade vai ao pescador); e o seu auto-stake é cortado em 2.5%, com metade desta quantidade queimada. Isto ajuda a garantir que os Indexadores tenham um forte incentivo a agir nos melhores interesses da rede e contribuir à sua segurança e estabilidade.
 
-## Improving the Protocol
+## Como Aprimorar o Protocolo
 
-The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).
+A Graph Network está sempre a evoluir, e o projeto económico do protocolo está sempre a melhorar, de modo a entregar a melhor experiência para todos os participantes da rede. O Graph Council (Conselho do Graph) supervisa as mudanças no protocolo e os membros da comunidade estão convidados para participar. Ajude a melhorar o protocolo no Fórum do The Graph.

From 50e1367043936772b03ff825441bfa4800024335 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 28 Jan 2025 12:50:38 -0500
Subject: [PATCH 3329/3820] New translations delegating.mdx (Portuguese)

---
 website/pages/pt/resources/roles/delegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/resources/roles/delegating.mdx b/website/pages/pt/resources/roles/delegating.mdx
index 345e74d71b71..7e5c9b26b6bc 100644
--- a/website/pages/pt/resources/roles/delegating.mdx
+++ b/website/pages/pt/resources/roles/delegating.mdx
@@ -118,7 +118,7 @@ Os Indexadores podem fechar uma alocação e resgatar recompensas a qualquer mom
 
 ### Como considerar as porções das taxas de query e de indexação
 
-You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+Escolha um Indexador transparente sobre as suas Taxas de Query e Porções de Taxa de Indexação.
 
 A fórmula é:
 

From 01478cab05187c15ddf752684cb9e7ce76e3985e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 28 Jan 2025 12:50:39 -0500
Subject: [PATCH 3330/3820] New translations tokenomics.mdx (Portuguese)

---
 website/pages/pt/resources/tokenomics.mdx | 38 +++++++++++------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/website/pages/pt/resources/tokenomics.mdx b/website/pages/pt/resources/tokenomics.mdx
index 8dd6b1dd31ff..ee6bdd21db6f 100644
--- a/website/pages/pt/resources/tokenomics.mdx
+++ b/website/pages/pt/resources/tokenomics.mdx
@@ -1,51 +1,51 @@
 ---
 title: Tokenomia da Graph Network
-description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+description: A Graph Network é incentivada por uma tokenomia (economia de token) poderosa. Veja como funciona o GRT, o token nativo de utilidades de trabalho no The Graph.
 ---
 
 ## Visão geral
 
-The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+O The Graph é um protocolo descentralizado que permite acesso fácil a dados de blockchain. Ele indexa dados de blockchain da mesma forma que o Google indexa a web; se já usou um dApp (aplicativo descentralizado) que resgata dados de um subgraph, você provavelmente já interagiu com o The Graph. Hoje, milhares de [dApps populares](https://thegraph.com/explorer) no ecossistema da Web3 usam o The Graph.
 
 ## Especificações
 
-The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+O modelo do The Graph é parecido com um modelo B2B2C, mas é movido por uma rede descentralizada onde os participantes colaboram para fornecer dados a utilizadores finais em troca de recompensas em GRT. Ele coordena e incentiva a interação entre provedores de dados e consumidores dentro da rede.
 
-The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+O The Graph tem um papel principal na acessibilidade de dados de blockchain, e apoia um mercado para o seu comércio. Para saber mais sobre o modelo de "pague pelo necessário" do The Graph, [clique aqui](/subgraphs/billing/).
 
-- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+- Endereço do Token GRT na Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
 
-- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+- Endereço do Token GRT na Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
 
-## The Roles of Network Participants
+## Os Papeis dos Participantes na Rede
 
-There are four primary network participants:
+Há quatro participantes primários na rede:
 
-1. Delegators - Delegate GRT to Indexers & secure the network
+1. Delegantes — Delegam GRT aos Indexadores e protegem a rede
 
 2. Curadores — Encontram os melhores subgraphs para Indexadores
 
-3. Developers - Build & query subgraphs
+3. Programadores — Constroem e consultam subgraphs em queries
 
 4. Indexadores — Rede de transporte de dados em blockchain
 
-Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+Pescadores e Árbitros também são integrais ao êxito da rede através de outras contribuições, com o seu apoio ao trabalho dos outros papéis participantes primários. Para saber mais sobre papéis na rede, [leia este artigo](https://thegraph.com/blog/the-graph-grt-token-economics/).
 
-![Tokenomics diagram](/img/updated-tokenomics-image.png)
+![Diagrama de tokenomia](/img/updated-tokenomics-image.png)
 
-## Delegators (Passively earn GRT)
+## Delegantes (Ganham GRT passivamente)
 
-Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+Os Delegantes delegam GRT a Indexadores, aumentando o stake do Indexador em subgraphs na rede. Em troca, os Delegantes ganham uma porcentagem de todas as taxas de query e recompensas de indexação do Indexador. Cada Indexador determina a porção que será recompensada aos Delegantes de forma independente, criando competição entre Indexadores para atrair Delegantes. Muitos Indexadores oferecem entre 9 e 12% ao ano.
 
-For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+Por exemplo, se um Delegante delegasse 15.000 GRT a um Indexador que oferecesse 10%, o Delegante receberia cerca de 1.500 GRT em recompensas por ano.
 
-There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+Há uma taxa de 0.5% de delegação, queimada quando um Delegante delega GRT na rede. Se um Delegante escolher sacar o GRT que delegou, o Delegante deve esperar o período de desligamento de 28 epochs. Cada epoch dura 6.646 blocos, o que significa que 28 blocos duram, em média, 26 dias.
 
-If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+Quem ler isto pode tornar-se um Delegante agora mesmo na [página de participantes da rede](https://thegraph.com/explorer/participants/indexers), e começar a delegar GRT a um Indexador da sua escolha.
 
-## Curators (Earn GRT)
+## Curadores (Ganham GRT)
 
-Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+Os Curadores identificam subgraphs de alta qualidade e os "curam" (por ex., sinalizam GRT neles) para ganhar ações de curadoria, que garantem uma porção de todas as taxas de query futuras geradas pelo subgraph. Enquanto qualquer participante independente da rede pode ser um Curador, os programadores de subgraphs tendem a ser os primeiros Curadores dos seus próprios subgraphs, pois querem garantir que o seu subgraph seja indexado.
 
 Desde 11 de abril de 2024, os programadores de subgraphs podem curar o seu subgraph com, no mínimo, 3.000 GRT. Porém, este número pode ser impactado pela atividade na rede e participação na comunidade.
 

From edfde5f3b216df6edc8b1e5672a60b769eb7784e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 28 Jan 2025 12:50:40 -0500
Subject: [PATCH 3331/3820] New translations quick-start.mdx (German)

---
 website/pages/de/subgraphs/quick-start.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/de/subgraphs/quick-start.mdx b/website/pages/de/subgraphs/quick-start.mdx
index 01ed82182519..875f3d509f3d 100644
--- a/website/pages/de/subgraphs/quick-start.mdx
+++ b/website/pages/de/subgraphs/quick-start.mdx
@@ -137,7 +137,7 @@ To publish your subgraph, click the Publish button in the dashboard.
 
 Select the network to which you would like to publish your subgraph.
 
-#### Publishing from the CLI
+#### Veröffentlichen über die CLI
 
 As of version 0.73.0, you can also publish your subgraph with the Graph CLI.
 
@@ -157,13 +157,13 @@ graph publish
 ```
 ````
 
-3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+3. Es öffnet sich ein Fenster, in dem Sie Ihre Wallet verbinden, Metadaten hinzufügen und Ihren fertigen Subgraphen in einem Netzwerk Ihrer Wahl bereitstellen können.
 
 ![cli-ui](/img/cli-ui.png)
 
 To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
 
-#### Adding signal to your subgraph
+#### Hinzufügen von Signalen zu Ihrem Subgraphen
 
 1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
 

From de77d2a63c03fdf58415e46e04fa67cf99af1123 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 28 Jan 2025 12:50:41 -0500
Subject: [PATCH 3332/3820] New translations publishing-a-subgraph.mdx (German)

---
 .../publishing/publishing-a-subgraph.mdx      | 42 +++++++++----------
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx
index a9975ad0f7b1..4946d7acae1d 100644
--- a/website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx
+++ b/website/pages/de/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -1,10 +1,10 @@
 ---
-title: Publishing a Subgraph to the Decentralized Network
+title: Veröffentlichung eines Subgraphen im dezentralen Netzwerk
 ---
 
 Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
 
-When you publish a subgraph to the decentralized network, you make it available for:
+Wenn Sie einen Subgraphen im dezentralen Netzwerk veröffentlichen, stellen Sie ihn für andere zur Verfügung:
 
 - [Curators](/resources/roles/curating/) to begin curating it.
 - [Indexers](/indexing/overview/) to begin indexing it.
@@ -13,37 +13,37 @@ When you publish a subgraph to the decentralized network, you make it available
 
 Check out the list of [supported networks](/supported-networks/).
 
-## Publishing from Subgraph Studio
+## Veröffentlichen aus Subgraph Studio
 
 1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
 2. Click on the **Publish** button
 3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
 
-All published versions of an existing subgraph can:
+Alle veröffentlichten Versionen eines bestehenden Subgraphen können:
 
 - Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
 
 - Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
 
-### Updating metadata for a published subgraph
+### Aktualisierung der Metadaten für einen veröffentlichten Subgraphen
 
-- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
-- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
-- It's important to note that this process will not create a new version since your deployment has not changed.
+- Nachdem Sie Ihren Subgraphen im dezentralen Netzwerk veröffentlicht haben, können Sie die Metadaten jederzeit in Subgraph Studio aktualisieren.
+- Sobald Sie Ihre Änderungen gespeichert und die Aktualisierungen veröffentlicht haben, werden sie im Graph Explorer angezeigt.
+- Es ist wichtig zu beachten, dass bei diesem Vorgang keine neue Version erstellt wird, da sich Ihre Bereitstellung nicht geändert hat.
 
-## Publishing from the CLI
+## Veröffentlichen über die CLI
 
 As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
 
 1. Öffnen Sie den `graph-cli`.
 2. Use the following commands: `graph codegen && graph build` then `graph publish`.
-3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+3. Es öffnet sich ein Fenster, in dem Sie Ihre Wallet verbinden, Metadaten hinzufügen und Ihren fertigen Subgraphen in einem Netzwerk Ihrer Wahl bereitstellen können.
 
 ![cli-ui](/img/cli-ui.png)
 
-### Customizing your deployment
+### Anpassen Ihrer Bereitstellung
 
-You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+Sie können Ihre Subgraph-Erstellung auf einen bestimmten IPFS-Knoten hochladen und Ihre Bereitstellung mit den folgenden Flags weiter anpassen:
 
 ```
 USAGE
@@ -61,34 +61,34 @@ FLAGS
 
 ```
 
-## Adding signal to your subgraph
+## Hinzufügen von Signalen zu Ihrem Subgraphen
 
-Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+Entwickler können ihren Subgraphen ein GRT-Signal hinzufügen, um Indexer zur Abfrage des Subgraphen zu veranlassen.
 
-- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+- Wenn ein Subgraph für Indexing Rewards in Frage kommt, erhalten Indexer, die einen „Beweis für die Indizierung“ erbringen, einen GRT Reward, der sich nach der Menge der signalisierten GRT richtet.
 
 - You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
 
 - Specific supported networks can be checked [here](/supported-networks/).
 
-> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+> Das Hinzufügen von Signalen zu einem Subgraphen, der nicht für Rewards in Frage kommt, zieht keine weiteren Indexer an.
 >
-> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+> Wenn Ihr Subgraph für Rewards in Frage kommt, wird empfohlen, dass Sie Ihren eigenen Subgraphen mit mindestens 3.000 GRT kuratieren, um zusätzliche Indexer für die Indizierung Ihres Subgraphen zu gewinnen.
 
 The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
 
 Bei der Signalisierung können Kuratoren entscheiden, ob sie für eine bestimmte Version des Subgraphen signalisieren wollen oder ob sie die automatische Migration verwenden wollen. Bei der automatischen Migration werden die Freigaben eines Kurators immer auf die neueste vom Entwickler veröffentlichte Version aktualisiert. Wenn sie sich stattdessen für eine bestimmte Version entscheiden, bleiben die Freigaben immer auf dieser spezifischen Version.
 
-Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+Indexer können Subgraphen für die Indizierung auf der Grundlage von Kurationssignalen finden, die sie im Graph Explorer sehen.
 
 ![Explorer-Subgrafen](/img/explorer-subgraphs.png)
 
-Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+Mit Subgraph Studio können Sie Ihrem Subgraphen ein Signal hinzufügen, indem Sie GRT in der gleichen Transaktion, in der es veröffentlicht wird, zum Kurationspool Ihres Subgraphen hinzufügen.
 
 ![Curation Pool](/img/curate-own-subgraph-tx.png)
 
-Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+Alternativ können Sie ein GRT-Signal zu einem veröffentlichten Subgraphen aus dem Graph Explorer hinzufügen.
 
-![Signal from Explorer](/img/signal-from-explorer.png)
+![Signal provenant de l'Explorer](/img/signal-from-explorer.png)
 
 Learn more about [Curating](/resources/roles/curating/) on The Graph Network.

From 40d6eacca6e765732fea4836c4b7852f1e4502a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 28 Jan 2025 12:50:43 -0500
Subject: [PATCH 3333/3820] New translations sinks.mdx (Portuguese)

---
 website/pages/pt/substreams/developing/sinks/sinks.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pt/substreams/developing/sinks/sinks.mdx b/website/pages/pt/substreams/developing/sinks/sinks.mdx
index c5559221e980..85280614ef67 100644
--- a/website/pages/pt/substreams/developing/sinks/sinks.mdx
+++ b/website/pages/pt/substreams/developing/sinks/sinks.mdx
@@ -26,7 +26,7 @@ Sinks are integrations that allow you to send the extracted data to different de
 
 ### Official
 
-| Name       | Support | Maintainer    | Source Code                                                                               |
+| Name       | Suporte | Maintainer    | Source Code                                                                               |
 | ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
 | SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
 | Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
@@ -40,7 +40,7 @@ Sinks are integrations that allow you to send the extracted data to different de
 
 ### Community
 
-| Name       | Support | Maintainer | Source Code                                                                               |
+| Name       | Suporte | Maintainer | Source Code                                                                               |
 | ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
 | MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
 | Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |

From cab8dff222d6f30c95802284b45874162bf59496 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 28 Jan 2025 12:50:44 -0500
Subject: [PATCH 3334/3820] New translations getting-started-substreams.mdx
 (Portuguese)

---
 website/pages/pt/substreams/getting-started-substreams.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/substreams/getting-started-substreams.mdx b/website/pages/pt/substreams/getting-started-substreams.mdx
index cb4e0df5d24d..56615c3ecedb 100644
--- a/website/pages/pt/substreams/getting-started-substreams.mdx
+++ b/website/pages/pt/substreams/getting-started-substreams.mdx
@@ -1,5 +1,5 @@
 ---
-title: Substreams Quick Start
+title: Início Rápido no Substreams
 ---
 
 Discover how to utilize ready-to-use substream packages or develop your own.

From 91760d3c783a75b226e36672d06ff2b6c38472f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 28 Jan 2025 16:56:18 -0500
Subject: [PATCH 3335/3820] New translations glossary.mdx (Portuguese)

---
 website/pages/pt/resources/glossary.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/resources/glossary.mdx b/website/pages/pt/resources/glossary.mdx
index a8d1056835d0..4660c4d00ecf 100644
--- a/website/pages/pt/resources/glossary.mdx
+++ b/website/pages/pt/resources/glossary.mdx
@@ -8,7 +8,7 @@ title: Glossário
 
 - **GraphQL:** Uma linguagem de queries para APIs e um runtime (programa de execução) para realizar esses queries com os dados existentes. O The Graph usa a GraphQL para fazer queries de subgraphs.
 
-- **Ponto de Execução**: Um URL que pode ser usado para fazer queries. O ponto final de execução para o Subgraph Studio é `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>`, e o do Graph Explorer é `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. O ponto final do Graph Explorer é usado para fazer queries de subgraphs na rede descentralizada do The Graph.
+- **Endpoint**: Um URL que pode ser usado para fazer queries. O ponto final de execução para o Subgraph Studio é `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>`, e o do Graph Explorer é `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. O ponto final do Graph Explorer é usado para fazer queries de subgraphs na rede descentralizada do The Graph.
 
 - **Subgraph:** Uma API aberta que extrai, processa, e guarda dados de uma blockchain para facilitar queries via a GraphQL. Os programadores podem construir, lançar, e editar subgraphs na The Graph Network. Indexado, o subgraph está sujeito a queries por quem quiser solicitar.
 

From f9071b0f89cacfae4e8df30789bfd0cd414c7569 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 04:00:17 -0500
Subject: [PATCH 3336/3820] New translations chain-integration-overview.mdx
 (German)

---
 .../indexing/chain-integration-overview.mdx   | 40 +++++++++----------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/website/pages/de/indexing/chain-integration-overview.mdx b/website/pages/de/indexing/chain-integration-overview.mdx
index 77141e82b34a..43ce1d4b84c1 100644
--- a/website/pages/de/indexing/chain-integration-overview.mdx
+++ b/website/pages/de/indexing/chain-integration-overview.mdx
@@ -1,44 +1,44 @@
 ---
-title: Chain Integration Process Overview
+title: Übersicht über den Prozess der Kettenintegration
 ---
 
-A transparent and governance-based integration process was designed for blockchain teams seeking [integration with The Graph protocol](https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468). It is a 3-phase process, as summarised below.
+Für Blockchain-Teams, die eine [Integration mit dem The Graph-Protokoll] (https://forum.thegraph.com/t/gip-0057-chain-integration-process/4468) anstreben, wurde ein transparenter und auf Governance basierender Integrationsprozess entwickelt. Es handelt sich um einen 3-Phasen-Prozess, der im Folgenden zusammengefasst wird.
 
-## Stage 1. Technical Integration
+## Stufe1. Technische Integration
 
-- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
-- Teams initiate the protocol integration process by creating a Forum thread [here](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (New Data Sources sub-category under Governance & GIPs). Using the default Forum template is mandatory.
+- Bitte besuchen Sie [Neue Kettenintegration](/indexing/new-chain-integration/), um Informationen zur `graph-node`-Unterstützung für neue Ketten zu erhalten.
+- Teams leiten den Prozess der Protokollintegration ein, indem sie ein Forumsthema [hier](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) erstellen (Unterkategorie Neue Datenquellen unter Governance & GIPs). Die Verwendung der Standardvorlage für das Forum ist obligatorisch.
 
-## Stage 2. Integration Validation
+## Stufe 2. Validierung der Integration
 
-- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
-- Graph Indexers test the integration on The Graph's testnet.
-- Core developers and Indexers monitor stability, performance, and data determinism.
+- Die Teams arbeiten mit den Kernentwicklern, Graph Foundation und den Betreibern von GUIs und Netzwerk-Gateways wie [Subgraph Studio] (https://thegraph.com/studio/) zusammen, um einen reibungslosen Integrationsprozess zu gewährleisten. Dazu gehört die Bereitstellung der notwendigen Backend-Infrastruktur, wie z.B. die JSON-RPC-, Firehose- oder Substreams-Endpunkte der integrierenden Kette. Teams, die eine solche Infrastruktur nicht selbst hosten wollen, können die Community der Knotenbetreiber (Indexer) von The Graph nutzen, um dies zu tun, wobei die Foundation helfen kann.
+- Graph Indexer testen die Integration im Testnetz von The Graph.
+- Kernentwickler und Indexer überwachen Stabilität, Leistung und Datendeterminismus.
 
-## Stage 3. Mainnet Integration
+## Stufe 3. Mainnet-Integration
 
-- Teams propose mainnet integration by submitting a Graph Improvement Proposal (GIP) and initiating a pull request (PR) on the [feature support matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) (more details on the link).
-- The Graph Council reviews the request and approves mainnet support, providing a successful Stage 2 and positive community feedback.
+- Teams schlagen die Mainnet-Integration vor, indem sie einen Vorschlag zur Verbesserung des Graphen (Graph Improvement Proposal, GIP) einreichen und einen Pull-Request (PR) auf der [Funktionsunterstützungsmatrix] (https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) initiieren (weitere Details unter dem Link).
+- The Graph Council prüft den Antrag und genehmigt die Mainnet-Unterstützung, was zu einer erfolgreichen Stufe 2 und einem positiven Feedback der Community führt.
 
 ---
 
-If the process looks daunting, don't worry! The Graph Foundation is committed to supporting integrators by fostering collaboration, offering essential information, and guiding them through various stages, including navigating governance processes such as Graph Improvement Proposals (GIPs) and pull requests. If you have questions, please reach out to [info@thegraph.foundation](mailto:info@thegraph.foundation) or through Discord (either Pedro, The Graph Foundation member, IndexerDAO, or other core developers).
+Wenn der Prozess entmutigend erscheint, machen Sie sich keine Sorgen! Die The Graph Foundation ist bestrebt, Integratoren zu unterstützen, indem sie die Zusammenarbeit fördert, ihnen wichtige Informationen zur Verfügung stellt und sie durch verschiedene Phasen führt, einschließlich der Navigation durch Governance-Prozesse wie Graph Improvement Proposals (GIPs) und Pull Requests. Wenn Sie Fragen haben, wenden Sie sich bitte an [info@thegraph.foundation] (mailto:info@thegraph.foundation) oder über Discord (entweder an Pedro, ein Mitglied der The Graph Foundation, IndexerDAO oder andere Kernentwickler).
 
-Ready to shape the future of The Graph Network? [Start your proposal](https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) now and be a part of the web3 revolution!
+Sind Sie bereit, die Zukunft von The Graph Network zu gestalten? [Starten Sie jetzt Ihren Vorschlag] (https://github.com/graphprotocol/graph-improvement-proposals/blob/main/gips/0057-chain-integration-process.md) und werden Sie Teil der web3-Revolution!
 
 ---
 
-## Frequently Asked Questions
+## Häufig gestellte Fragen
 
-### 1. How does this relate to the [World of Data Services GIP](https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
+### 1. In welchem Zusammenhang steht dies mit der [World of Data Services GIP] (https://forum.thegraph.com/t/gip-0042-a-world-of-data-services/3761)?
 
-This process is related to the Subgraph Data Service, applicable only to new Subgraph `Data Sources`.
+Dieser Prozess bezieht sich auf den Subgraph Data Service, der nur für neue Subgraph-`Data Sources` gilt.
 
-### 2. What happens if Firehose & Substreams support comes after the network is supported on mainnet?
+### 2. Was geschieht, wenn die Unterstützung für Firehose & Substreams erst nach der Unterstützung des Netzes im Mainnet erfolgt?
 
-This would only impact protocol support for indexing rewards on Substreams-powered subgraphs. The new Firehose implementation would need testing on testnet, following the methodology outlined for Stage 2 in this GIP. Similarly, assuming the implementation is performant and reliable, a PR on the [Feature Support Matrix](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) would be required (`Substreams data sources` Subgraph Feature), as well as a new GIP for protocol support for indexing rewards. Anyone can create the PR and GIP; the Foundation would help with Council approval.
+Dies würde sich nur auf die Protokollunterstützung für die Indizierung von Rewards auf Subgraphen mit Substreams auswirken. Die neue Firehose-Implementierung müsste im Testnet getestet werden, wobei die für Stufe 2 in diesem GIP beschriebene Methodik anzuwenden wäre. Unter der Annahme, dass die Implementierung performant und zuverlässig ist, wäre ein PR für die [Funktionsunterstützungsmatrix] (https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) erforderlich (`Substreams data sources`-Subgraph-Funktion), sowie eine neue GIP für die Protokollunterstützung für die Indizierung von Rewards. Jeder kann die PR und GIP erstellen; die Foundation würde bei der Genehmigung durch den Rat helfen.
 
-### 3. How much time will the process of reaching full protocol support take?
+### 3. Wie viel Zeit wird der Prozess bis zur vollständigen Unterstützung des Protokolls in Anspruch nehmen?
 
 The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
 

From 9f760d8d840fbfd8a8694157fa05e1a354600d2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 06:02:46 -0500
Subject: [PATCH 3337/3820] New translations chain-integration-overview.mdx
 (German)

---
 website/pages/de/indexing/chain-integration-overview.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/de/indexing/chain-integration-overview.mdx b/website/pages/de/indexing/chain-integration-overview.mdx
index 43ce1d4b84c1..5f867a52ca5b 100644
--- a/website/pages/de/indexing/chain-integration-overview.mdx
+++ b/website/pages/de/indexing/chain-integration-overview.mdx
@@ -40,10 +40,10 @@ Dies würde sich nur auf die Protokollunterstützung für die Indizierung von Re
 
 ### 3. Wie viel Zeit wird der Prozess bis zur vollständigen Unterstützung des Protokolls in Anspruch nehmen?
 
-The time to mainnet is expected to be several weeks, varying based on the time of integration development, whether additional research is required, testing and bug fixes, and, as always, the timing of the governance process that requires community feedback.
+Es wird erwartet, dass die Zeit bis zum Mainnet mehrere Wochen betragen wird, je nachdem, wann die Integration entwickelt wird, ob zusätzliche Forschung erforderlich ist, ob Tests und Fehlerkorrekturen durchgeführt werden müssen und, wie immer, je nach dem Zeitpunkt des Governance-Prozesses, der ein Feedback der Community erfordert.
 
-Protocol support for indexing rewards depends on the stakeholders' bandwidth to proceed with testing, feedback gathering, and handling contributions to the core codebase, if applicable. This is directly tied to the integration's maturity and how responsive the integration team is (who may or may not be the team behind the RPC/Firehose implementation). The Foundation is here to help support throughout the whole process.
+Die Unterstützung des Protokolls für die Indexer Rewards hängt von der Bandbreite der Beteiligten ab, um mit dem Testen, dem Sammeln von Feedback und der Bearbeitung von Beiträgen zur Kern-Codebasis fortzufahren, falls zutreffend. Dies steht in direktem Zusammenhang mit der Reife der Integration und der Reaktionsfähigkeit des Integrationsteams (bei dem es sich um das Team hinter der RPC/Firehose-Implementierung handeln kann oder auch nicht). Die Foundation steht während des gesamten Prozesses unterstützend zur Seite.
 
-### 4. How will priorities be handled?
+### 4. Wie werden die Prioritäten gehandhabt?
 
-Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.
+Ähnlich wie bei Punkt 3 hängt dies von der allgemeinen Bereitschaft und der Bandbreite der beteiligten Akteure ab. Ein Datenbeispiel: Eine neue Kette mit einer brandneuen Firehose-Implementierung kann länger dauern als Integrationen, die bereits erprobt wurden oder im Governance-Prozess weiter fortgeschritten sind.

From af4a2254acd2c7c88f1e04e2da4b43113183059f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 06:02:48 -0500
Subject: [PATCH 3338/3820] New translations new-chain-integration.mdx (German)

---
 .../de/indexing/new-chain-integration.mdx     | 54 +++++++++----------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/website/pages/de/indexing/new-chain-integration.mdx b/website/pages/de/indexing/new-chain-integration.mdx
index 7c9f8a5c65c4..55cec71fd3fc 100644
--- a/website/pages/de/indexing/new-chain-integration.mdx
+++ b/website/pages/de/indexing/new-chain-integration.mdx
@@ -1,70 +1,70 @@
 ---
-title: New Chain Integration
+title: Integration neuer Ketten
 ---
 
-Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+Ketten können die Unterstützung von Subgraphen in ihr Ökosystem einbringen, indem sie eine neue `graph-node` Integration starten. Subgraphen sind ein leistungsfähiges Indizierungswerkzeug, das Entwicklern eine Welt voller Möglichkeiten eröffnet. Graph Node indiziert bereits Daten von den hier aufgeführten Ketten. Wenn Sie an einer neuen Integration interessiert sind, gibt es 2 Integrationsstrategien:
 
 1. **EVM JSON-RPC**
-2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+2. **Firehose**: Alle Firehose-Integrationslösungen umfassen Substreams, eine groß angelegte Streaming-Engine auf der Grundlage von Firehose mit nativer `graph-node`-Unterstützung, die parallelisierte Transformationen ermöglicht.
 
-> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+> Beachten Sie, dass es zwar empfohlen wird, einen neuen Firehose für alle neuen Ketten zu entwickeln, dies aber nur für Nicht-EVM-Ketten erforderlich ist.
 
-## Integration Strategies
+## Strategien zur Integration
 
 ### 1. EVM JSON-RPC
 
-If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+Wenn die Blockchain EVM-äquivalent ist und der Client/Knoten die standardmäßige EVM-JSON-RPC-API bereitstellt, sollte Graph Node in der Lage sein, die neue Kette zu indizieren.
 
-#### Testing an EVM JSON-RPC
+#### Testen eines EVM JSON-RPC
 
-For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+Damit Graph Node Daten aus einer EVM-Kette aufnehmen kann, muss der RPC-Knoten die folgenden EVM JSON-RPC-Methoden bereitstellen:
 
 - `eth_getLogs`
-- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_call` (für historische Blöcke, mit EIP-1898 - erfordert Archivknoten)
 - `eth_getBlockByNumber`
 - `eth_getBlockByHash`
 - `net_version`
-- `eth_getTransactionReceipt`, in a JSON-RPC batch request
+- `eth_getTransactionReceipt`, in einem JSON-RPC-Batch-Antrag
 - `trace_filter` _(limited tracing and optionally required for Graph Node)_
 
 ### 2. Firehose Integration
 
-[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+[Firehose] (https://firehose.streamingfast.io/firehose-setup/overview) ist eine Extraktionsschicht der nächsten Generation. Sie sammelt den Verlauf in Flat Files und Streams in Echtzeit. Die Firehose-Technologie ersetzt die abfragenden API-Aufrufe durch einen Datenstrom, der ein Push-Modell verwendet, das Daten schneller an den Indexer-Knoten sendet. Dies trägt dazu bei, die Geschwindigkeit der Synchronisierung und Indizierung zu erhöhen.
 
-> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+> HINWEIS: Alle vom StreamingFast-Team durchgeführten Integrationen beinhalten die Wartung des Firehose-Replikationsprotokolls in der Codebasis der Kette. StreamingFast verfolgt alle Änderungen und gibt Binärdateien frei, wenn Sie den Code ändern und wenn StreamingFast den Code ändert. Dies umfasst die Freigabe von Firehose/Substreams-Binärdateien für das Protokoll, die Wartung von Substreams-Modulen für das Blockmodell der Kette und die Freigabe von Binärdateien für den Blockchain-Knoten mit Instrumentierung, falls erforderlich.
 
 #### Integration for Non-EVM chains
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+Die primäre Methode zur Integration des Firehose in Ketten besteht in der Verwendung einer RPC-Polling-Strategie. Unser Polling-Algorithmus sagt voraus, wann ein neuer Block eintreffen wird und erhöht die Rate, mit der er nach einem neuen Block in der Nähe dieses Zeitpunkts sucht, was eine sehr effiziente Lösung mit geringer Latenz darstellt. Wenn Sie Hilfe bei der Integration und Wartung von Firehose benötigen, wenden Sie sich an das [StreamingFast-Team] (https://www.streamingfast.io/firehose-integration-program). Neue Ketten und ihre Integratoren werden die [Fork-Bewusstsein](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) und die massiv parallelisierten Indexierungsfähigkeiten zu schätzen wissen, die Firehose und Substreams in ihr Ökosystem einbringen.
 
 #### Specific Instrumentation for EVM (`geth`) chains
 
-For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+Für EVM-Ketten gibt es eine tiefere Ebene von Daten, die durch den `geth` [Live-Tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), eine Zusammenarbeit zwischen Go-Ethereum und StreamingFast, beim Aufbau eines durchsatzstarken und umfangreichen Transaktionsverfolgungssystems erreicht werden kann. Der Live-Tracer ist die umfassendste Lösung, die zu [erweiterten](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) Blockdetails führt. Dies ermöglicht neue Indizierungsparadigmen, wie den Musterabgleich von Ereignissen auf der Grundlage von Zustandsänderungen, Aufrufen, übergeordneten Aufrufbäumen oder das Auslösen von Ereignissen auf der Grundlage von Änderungen der tatsächlichen Variablen in einem Smart Contract.
 
-![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
+![Basisblock vs. Erweiterter Block](/img/extended-vs-base-substreams-blocks.png)
 
-> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+> HINWEIS: Diese Verbesserung des Firehose erfordert, dass die Ketten die EVM-Engine `geth Version 1.13.0` und höher verwenden.
 
-## EVM considerations - Difference between JSON-RPC & Firehose
+## EVM-Überlegungen - Unterschied zwischen JSON-RPC und Firehose
 
-While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+Während JSON-RPC und Firehose beide für Subgraphen geeignet sind, ist für Entwickler, die mit [Substreams](https://substreams.streamingfast.io) bauen wollen, immer ein Firehose erforderlich. Die Unterstützung von Substreams ermöglicht es Entwicklern, [Substreams-betriebene Subgraphen](/subgraphs/cookbook/substreams-powered-subgraphs/) für die neue Kette zu bauen, und hat das Potenzial, die Leistung Ihrer Subgraphen zu verbessern. Darüber hinaus reduziert Firehose - als Ersatz für die JSON-RPC-Extraktionsschicht von `graph-node` - die Anzahl der RPC-Aufrufe, die für die allgemeine Indizierung erforderlich sind, um 90%.
 
-- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+- All diese `getLogs`-Aufrufe und Roundtrips werden durch einen einzigen Stream ersetzt, der im Herzen von `graph-node` ankommt; ein einziges Blockmodell für alle Subgraphen, die es verarbeitet.
 
-> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+> HINWEIS: Bei einer Firehose-basierten Integration für EVM-Ketten müssen Indexer weiterhin den Archiv-RPC-Knoten der Kette ausführen, um Subgraphen ordnungsgemäß zu indizieren. Dies liegt daran, dass der Firehose nicht in der Lage ist, den Smart-Contract-Status bereitzustellen, der normalerweise über die RPC-Methode „eth_call“ zugänglich ist. (Es ist erwähnenswert, dass `eth_calls` keine gute Praxis für Entwickler sind)
 
-## Graph Node Configuration
+## Graph-Node Konfiguration
 
-Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+Die Konfiguration von Graph Node ist so einfach wie die Vorbereitung Ihrer lokalen Umgebung. Sobald Ihre lokale Umgebung eingerichtet ist, können Sie die Integration testen, indem Sie einen Subgraphen lokal bereitstellen.
 
-1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+1. [Graph Node klonen](https://github.com/graphprotocol/graph-node)
 
 2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
 
-   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+   > Ändern Sie nicht den Namen der Env-Variable selbst. Er muss `ethereum` bleiben, auch wenn der Netzwerkname anders lautet.
 
-3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+3. Führen Sie einen IPFS-Knoten aus oder verwenden Sie den von The Graph verwendeten: https://api.thegraph.com/ipfs/
 
-## Substreams-powered Subgraphs
+## Substreams-getriebene Subgraphen
 
-For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.
+Für StreamingFast-geführte Firehose/Substreams-Integrationen sind grundlegende Unterstützung für grundlegende Substreams-Module (z. B. entschlüsselte Transaktionen, Protokolle und Smart-Contract-Ereignisse) und Substreams-Codegen-Tools enthalten. Mit diesen Tools können Sie [Substreams-getriebene Subgraphen](/substreams/sps/introduction/) aktivieren. Folgen Sie dem [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) und führen Sie `substreams codegen subgraph` aus, um die codegen-Tools selbst zu erleben.

From 167c48064e929c0c20555a632a10ba82ad1bdae6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 07:17:08 -0500
Subject: [PATCH 3339/3820] New translations curating.mdx (French)

---
 website/pages/fr/resources/roles/curating.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/fr/resources/roles/curating.mdx b/website/pages/fr/resources/roles/curating.mdx
index bd3b64ba0d3e..cfee836ca03b 100644
--- a/website/pages/fr/resources/roles/curating.mdx
+++ b/website/pages/fr/resources/roles/curating.mdx
@@ -8,31 +8,31 @@ Les Curateurs jouent un rôle essentiel dans l'économie décentralisée de The
 
 Avant que les consommateurs ne puissent interroger un subgraphs, celui-ci doit être indexé. C'est ici que la curation entre en jeu. Afin que les Indexeurs puissent gagner des frais de requête substantiels sur des subgraphs de qualité, ils doivent savoir quels subgraphs indexer. Lorsque les Curateurs signalent un subgraphs , ils indiquent aux Indexeurs qu'un subgraphs est demandé et de qualité suffisante pour être indexé.
 
-Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+Les Curateurs rendent le réseau The Graph efficace et le [signalement](#how-to-signal) est le processus que les Curateurs utilisent pour informer les Indexeurs qu'un subgraph est bon à indexer. Les Indexeurs peuvent se fier au signal d’un Curateur car, en signalant, les Curateurs mintent une part de curation (curation share) pour le subgraph, leur donnant droit à une partie des futurs frais de requête générés par ce subgraph.
 
 Les signaux des Curateurs sont représentés par des jetons ERC20 appelés Graph Curation Shares (GCS). Ceux qui veulent gagner plus de frais de requête doivent signaler leurs GRT aux subgraphs qui, selon eux, généreront un flux important de frais pour le réseau. Les Curateurs ne peuvent pas être réduits pour mauvais comportement, mais il y a une taxe de dépôt sur les Curateurs pour dissuader les mauvaises décisions pouvant nuire à l'intégrité du réseau. Les Curateurs gagneront également moins de frais de requête s'ils sélectionnent un subgraph de mauvaise qualité car il y aura moins de requêtes à traiter ou moins d'Indexeurs pour les traiter.
 
-The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+L’[Indexer Sunrise Upgrade](/archived/sunrise/#what-is-the-upgrade-indexer) assure l'indexation de tous les subgraphs, toutefois, signaler des GRT sur un subgraph spécifique attirera davantage d’Indexeurs vers ce dernier. Cette incitation supplémentaire a pour but d’améliorer la qualité de service pour les requêtes en réduisant la latence et en améliorant la disponibilité du réseau.
 
 Lors du signalement, les Curateurs peuvent décider de signaler une version spécifique du subgraph ou de signaler en utilisant l'auto-migration. S'ils signalent en utilisant l'auto-migration, les parts d'un Curateur seront toujours mises à jour vers la dernière version publiée par le développeur. S'ils décident de signaler une version spécifique, les parts resteront toujours sur cette version spécifique.
 
-If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+Si vous avez besoin d’aide pour la curation afin d’améliorer la qualité de service, envoyez une demande à l’équipe Edge & Node à l’adresse support@thegraph.zendesk.com en précisant les subgraphs pour lesquels vous avez besoin d’assistance.
 
 Les Indexeurs peuvent trouver des subgraphs à indexer en fonction des signaux de curation qu'ils voient dans Graph Explorer (capture d'écran ci-dessous).
 
-![Explorer subgraphs](/img/explorer-subgraphs.png)
+![Subgraphs de l'Explorer](/img/explorer-subgraphs.png)
 
 ## Comment signaler
 
-Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+Dans l'onglet Curateur de Graph Explorer, les curateurs pourront signaler et retirer leur signal sur certains subgraphs en fonction des statistiques du réseau. Pour un guide pas à pas expliquant comment procéder dans Graph Explorer, [cliquez ici.](/subgraphs/explorer/)
 
 Un curateur peut choisir de signaler une version spécifique d'un sugraph ou de faire migrer automatiquement son signal vers la version de production la plus récente de ce subgraph. Ces deux stratégies sont valables et comportent leurs propres avantages et inconvénients.
 
-Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+Le signalement sur une version spécifique est particulièrement utile lorsqu'un subgraph est utilisé par plusieurs dapps. Une dapp pourrait avoir besoin de mettre à jour régulièrement le subgraph avec de nouvelles fonctionnalités, tandis qu’une autre dapp pourrait préférer utiliser une version plus ancienne et bien testée du subgraph. Lors de la curation initiale, une taxe standard de 1 % est prélevée.
 
 La migration automatique de votre signal vers la version de production la plus récente peut s'avérer utile pour vous assurer que vous continuez à accumuler des frais de requête. Chaque fois que vous effectuez une curation, une taxe de curation de 1 % est appliquée. Vous paierez également une taxe de curation de 0,5 % à chaque migration. Les développeurs de subgraphs sont découragés de publier fréquemment de nouvelles versions - ils doivent payer une taxe de curation de 0,5 % sur toutes les parts de curation migrées automatiquement.
 
-> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+> **Remarque**: La première adresse à signaler un subgraph donné est considérée comme le premier curateur et devra effectuer un travail bien plus coûteux en gas que les curateurs suivants, car le premier curateur doit initialiser les tokens de part de curation et transférer les tokens dans le proxy de The Graph.
 
 ## Retrait de vos GRT
 

From f0a5d1bdd4ff87aaed3ac609c64993e15544de5a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 08:23:50 -0500
Subject: [PATCH 3340/3820] New translations graph-node.mdx (French)

---
 website/pages/fr/indexing/tooling/graph-node.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/indexing/tooling/graph-node.mdx b/website/pages/fr/indexing/tooling/graph-node.mdx
index 295020ada1be..4ddb05dcaa15 100644
--- a/website/pages/fr/indexing/tooling/graph-node.mdx
+++ b/website/pages/fr/indexing/tooling/graph-node.mdx
@@ -306,7 +306,7 @@ Si une incohérence du cache de blocs est suspectée, telle qu'un événement de
 
 Une fois qu'un subgraph a été indexé, les indexeurs peuvent s'attendre à traiter les requêtes via le point de terminaison de requête dédié du subgraph. Si l'indexeur espère traiter un volume de requêtes important, un nœud de requête dédié est recommandé, et en cas de volumes de requêtes très élevés, les indexeurs peuvent souhaiter configurer des fragments de réplique afin que les requêtes n'aient pas d'impact sur le processus d'indexation.
 
-However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+Cependant, même avec un nœud de requête et des répliques dédiés, certaines requêtes peuvent prendre beaucoup de temps à exécuter et, dans certains cas, augmenter l'utilisation de la mémoire et avoir un impact négatif sur le temps de requête des autres utilisateurs.
 
 Il n'existe pas de solution miracle, mais une gamme d'outils permettant de prévenir, de diagnostiquer et de traiter les requêtes lentes.
 

From 695f4478a1e0ee806eb000df76fef8dc207ca7d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 08:23:51 -0500
Subject: [PATCH 3341/3820] New translations delegating.mdx (French)

---
 website/pages/fr/resources/roles/delegating.mdx | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/fr/resources/roles/delegating.mdx b/website/pages/fr/resources/roles/delegating.mdx
index 0cca71ae43e1..99fe60359d38 100644
--- a/website/pages/fr/resources/roles/delegating.mdx
+++ b/website/pages/fr/resources/roles/delegating.mdx
@@ -83,24 +83,22 @@ If you choose an Indexer that is not trustworthy or not doing a good job, you wi
 As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
-  unbonding period._
+  ![Délégation en cours de désengagement](/img/Delegation-Unbonding.png) _Notez les frais de 0,5 % dans l’interface de Délégation, ainsi que la période de désengagement de 28 jours._
 </div>
 
 #### Paramètres de Délégation
 
 Pour comprendre comment choisir un Indexeur fiable, vous devez comprendre les paramètres de Délégation.
 
-- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+- **Indexing Reward Cut** - La portion des récompenses que l'Indexeur conserve pour lui-même.
   - Si la part de récompense d'un indexeur est fixée à 100%, en tant que délégateur, vous recevrez 0 récompense d'indexation.
   - Si elle est fixée à 80%, en tant que Délégateur, vous recevrez 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
-  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *L’indexeur du haut donne 90 % des récompenses aux Délégateurs. Celui du milieu donne 20 %. Celui du bas donne environ 83 %.*
 </div>
 
-- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+- **Query Fee Cut** - C’est la même chose que l’Indexing Reward Cut, mais cela s’applique aux revenus des frais de requête que l’Indexeur perçoit.
 
 - It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
@@ -136,7 +134,7 @@ Toutes les récompenses de délégation sont partagées de manière égale, avec
 
 Cela donne au Déléguateur une part du pool :
 
-![Share formula](/img/Share-Forumla.png)
+![Formule de calcul de chaque part](/img/Share-Forumla.png)
 
 > La formule ci-dessus montre qu'il est possible pour un Indexeur offrant seulement 20% aux Déléguateurs de fournir une meilleure récompense qu'un Indexeur donnant 90%. Il suffit de faire les calculs pour déterminer la meilleure récompense.
 

From f89d46a9d29170d5bf8352ce5fd1b4ac49db9a34 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 08:23:52 -0500
Subject: [PATCH 3342/3820] New translations curating.mdx (French)

---
 website/pages/fr/resources/roles/curating.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/resources/roles/curating.mdx b/website/pages/fr/resources/roles/curating.mdx
index cfee836ca03b..1d60a7cb1f1e 100644
--- a/website/pages/fr/resources/roles/curating.mdx
+++ b/website/pages/fr/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ Cependant, il est recommandé que les Curateurs laissent leur GRT signalé en pl
 
 1. Le marché des requêtes est intrinsèquement jeune chez The Graph et il y a un risque que votre %APY soit inférieur à vos attentes en raison de la dynamique naissante du marché.
 2. Frais de curation - lorsqu'un Curateur signale des GRT sur un subgraph, il doit s'acquitter d'une taxe de curation de 1%. Cette taxe est brûlée.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Sur Ethereum uniquement) Lorsque les curateurs brûlent leurs parts pour retirer leurs GRT, la valeur en GRT des parts restantes est réduite. Sachez que, dans certains cas, les curateurs peuvent décider de brûler leurs parts en une seule fois. Cette situation peut se produire si un développeur de dapp cesse de versionner/de faire évoluer et d'interroger son subgraph, ou si un subgraph échoue. Par conséquent, les curateurs restants pourraient ne récupérer qu’une partie de leur GRT initial. Pour un rôle réseau avec un profil de risque plus faible, regardez la section sur les [Délégateurs](/resources/roles/delegating/).
 4. Un subgraph peut échouer à cause d'un bug. Un subgraph qui échoue n'accumule pas de frais de requête. Par conséquent, vous devrez attendre que le développeur corrige le bogue et déploie une nouvelle version.
    - Si vous êtes abonné à la version la plus récente d'un subgraph, vos parts migreront automatiquement vers cette nouvelle version. Cela entraînera une taxe de curation de 0,5 %.
    - Si vous avez signalé sur une version spécifique d'un subgraph et qu'elle échoue, vous devrez brûler manuellement vos parts de curation. Vous pouvez alors signaler sur la nouvelle version du subgraph, encourant ainsi une taxe de curation de 1%.
@@ -61,14 +61,14 @@ En signalant sur un subgraph, vous gagnerez une part de tous les frais de requê
 
 ### 2. Comment décider quels sont les subgraphs de haute qualité sur lesquels on peut émettre un signal ?
 
-Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+Identifier des subgraphs de haute qualité est une tâche complexe, mais il existe de multiples approches.. En tant que Curateur, vous souhaitez trouver des subgraphs fiables qui génèrent un volume de requêtes élevé. Un subgraph fiable peut être précieux s’il est complet, précis et s’il répond aux besoins en données d’une dapp. Un subgraph mal conçu pourrait avoir besoin d'être révisé ou republié, et peut aussi finir par échouer. Il est crucial pour les Curateurs d'examiner l'architecture ou le code d'un subgraph afin d'évaluer sa valeur. Ainsi :
 
 - Les Curateurs peuvent utiliser leur compréhension d'un réseau pour essayer de prédire comment un subgraph individuel peut générer un volume de requêtes plus élevé ou plus faible à l'avenir
 - Les Curateurs doivent également comprendre les métriques disponibles via Graph Explorer. Des métriques telles que le volume de requêtes passées et l'identité du développeur du subgraph peuvent aider à déterminer si un subgraph mérite ou non d'être signalé.
 
 ### 3. Quel est le coût de la mise à jour d'un subgraph ?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+La migration de vos parts de curation (curation shares) vers une nouvelle version de subgraph entraîne une taxe de curation de 1 %. Les Curateurs peuvent choisir de s'abonner à la dernière version d'un subgraph. Lorsque les parts de Curateurs sont automatiquement migrées vers une nouvelle version, les Curateurs paieront également une demi-taxe de curation, soit 0,5 %, car la mise à niveau (upgrade) des subgraphs est une action onchain qui coûte du gas.
 
 ### 4. À quelle fréquence puis-je mettre à jour mon subgraph ?
 

From d8b71ecf8aaa199cfe53016ce3b41bdfd2dedd03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:33:55 -0500
Subject: [PATCH 3343/3820] New translations advanced.mdx (Portuguese)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/pt/subgraphs/developing/creating/advanced.mdx b/website/pages/pt/subgraphs/developing/creating/advanced.mdx
index 6355d3026aee..5dfeb1034a5f 100644
--- a/website/pages/pt/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/pt/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Séries de Tempo e Agregações
 
-Séries de tempo e agregações permitem que o seu subgraph registre estatísticas como médias diárias de preço, total de transferências por hora, etc.
+Prerequisites:
 
-Este recurso introduz dois novos tipos de entidade de subgraph. Entidades de série de tempo registram pontos de dados com marcações de tempo. Entidades de agregação realizam cálculos pré-declarados nos pontos de dados de Séries de Tempo numa base por hora ou diária, e depois armazenam os resultados para acesso fácil via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Exemplo de Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Definição de Série de Tempo e Agregações
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Intervalos de Agregação Disponíveis
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Nota:
-
-Para utilizar Séries de Tempo e Agregações, um subgraph deve ter uma versão de especificação maior que 1.1.0. Note que este recurso pode passar por mudanças significativas que podem afetar a retrocompatibilidade.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Erros não-fatais

From e5ece16c335ff72554883a3b3af240a2e2d01b3b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:33:56 -0500
Subject: [PATCH 3344/3820] New translations advanced.mdx (French)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/fr/subgraphs/developing/creating/advanced.mdx b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
index 4b61a7512866..0cbda1512748 100644
--- a/website/pages/fr/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Séries chronologiques et agrégations
 
-Les séries chronologiques et les agrégations permettent à votre subgraph de suivre des statistiques telles que le prix moyen journalier, le total des transferts par heure, etc.
+Prerequisites:
 
-Cette fonctionnalité introduit deux nouveaux types d'entités de subgraph. Les entités de séries chronologiques enregistrent des points de données avec des horodatages. Les entités d'agrégation effectuent des calculs pré-déclarés sur les points de données des séries chronologiques sur une base horaire ou quotidienne, puis stockent les résultats pour un accès facile via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Exemple de schéma
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Définition des Séries Chronologiques et des Agrégations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Les entités de séries chronologiques sont définies avec `@entity(timeseries: true)` dans schema.graphql. Chaque entité de série chronologique doit avoir un ID unique de type int8, une timestamp de type Timestamp et inclure des données qui seront utilisées pour le calcul par des entités d'agrégation. Ces entités de séries chronologique peuvent être enregistrées dans des gestionnaires triggers habituels et agissent comme les "données brutes" pour les entités d'agrégation.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Les entités d'agrégation sont définies avec `@aggregation` dans schema.graphql. Chaque entité d'agrégation définit la source à partir de laquelle elle collectera des données (qui doit être une entité de série chronologique ), définit les intervalles (par exemple, heure, jour) et spécifie la fonction d'agrégation qu'elle utilisera (par exemple, somme, compte, min, max, premier, dernier). Les entités d'agrégation sont automatiquement calculées sur la base de la source spécifiée à la fin de l'intervalle requis.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Intervalles d'Agrégation disponibles
 
@@ -81,10 +93,6 @@ Les entités d'agrégation sont définies avec `@aggregation` dans schema.graphq
 }
 ```
 
-Remarque:
-
-Pour utiliser les Séries Chronologiques et les Agrégations, un subgraph doit avoir une spec Version ≥1.1.0. Notez que cette fonctionnalité pourrait subir des changements significatifs affectant la compatibilité rétroactive.
-
 [En savoir plus](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) sur les séries chronologiques et Agrégations.
 
 ## Erreurs non fatales

From 463c1a588c8f38c8dae8db7f8e64293ddd42649c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:33:57 -0500
Subject: [PATCH 3345/3820] New translations advanced.mdx (Romanian)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/ro/subgraphs/developing/creating/advanced.mdx b/website/pages/ro/subgraphs/developing/creating/advanced.mdx
index a6a4b224bc3e..ee9918f5f254 100644
--- a/website/pages/ro/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/ro/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Non-fatal errors

From 94d756b2160045f85d9afb28239961c46c2b0807 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:33:59 -0500
Subject: [PATCH 3346/3820] New translations advanced.mdx (Spanish)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/es/subgraphs/developing/creating/advanced.mdx b/website/pages/es/subgraphs/developing/creating/advanced.mdx
index 93a6a6241618..63cf8f312906 100644
--- a/website/pages/es/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/es/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Errores no fatales

From 75aeceaf58538bfac5ef7c3154b74d28a4db34bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:00 -0500
Subject: [PATCH 3347/3820] New translations advanced.mdx (Arabic)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/ar/subgraphs/developing/creating/advanced.mdx b/website/pages/ar/subgraphs/developing/creating/advanced.mdx
index 8c097d25ff62..d0f9bb2cc348 100644
--- a/website/pages/ar/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/ar/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## أخطاء غير فادحة

From f72fb67018ed3c6bcd37ade867816567bb67b95f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:01 -0500
Subject: [PATCH 3348/3820] New translations advanced.mdx (Czech)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/cs/subgraphs/developing/creating/advanced.mdx b/website/pages/cs/subgraphs/developing/creating/advanced.mdx
index aea6ad357dd8..a8641a40068b 100644
--- a/website/pages/cs/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/cs/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Nefatální

From 00d9fca374c231a89021a6c8d2832439b7479968 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:02 -0500
Subject: [PATCH 3349/3820] New translations advanced.mdx (German)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/de/subgraphs/developing/creating/advanced.mdx b/website/pages/de/subgraphs/developing/creating/advanced.mdx
index 0db68b112f5f..1a8debdf98c5 100644
--- a/website/pages/de/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/de/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Non-fatal errors

From 4823078e653ded01ab29a24bef2389ee6ecda670 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:03 -0500
Subject: [PATCH 3350/3820] New translations advanced.mdx (Italian)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/it/subgraphs/developing/creating/advanced.mdx b/website/pages/it/subgraphs/developing/creating/advanced.mdx
index 3e7a7f2f6c4f..94c7d1f0d42d 100644
--- a/website/pages/it/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/it/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Errori non fatali

From f75b47bda4233970ddfe7996644aa90eec1c60e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:05 -0500
Subject: [PATCH 3351/3820] New translations advanced.mdx (Japanese)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/ja/subgraphs/developing/creating/advanced.mdx b/website/pages/ja/subgraphs/developing/creating/advanced.mdx
index a53e473f71ba..b6269f49fcf5 100644
--- a/website/pages/ja/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/ja/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## 致命的でないエラー

From e14023d48af75be94310fa7a5a125007732e954c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:06 -0500
Subject: [PATCH 3352/3820] New translations advanced.mdx (Korean)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/ko/subgraphs/developing/creating/advanced.mdx b/website/pages/ko/subgraphs/developing/creating/advanced.mdx
index a6a4b224bc3e..ee9918f5f254 100644
--- a/website/pages/ko/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/ko/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Non-fatal errors

From 319a18312afb11145db0d41ec4267060429592e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:07 -0500
Subject: [PATCH 3353/3820] New translations advanced.mdx (Dutch)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/nl/subgraphs/developing/creating/advanced.mdx b/website/pages/nl/subgraphs/developing/creating/advanced.mdx
index a6a4b224bc3e..ee9918f5f254 100644
--- a/website/pages/nl/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/nl/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Non-fatal errors

From a153f4e1d0bf730a68616ed5aea611f132e4c81d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:08 -0500
Subject: [PATCH 3354/3820] New translations advanced.mdx (Polish)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/pl/subgraphs/developing/creating/advanced.mdx b/website/pages/pl/subgraphs/developing/creating/advanced.mdx
index a6a4b224bc3e..ee9918f5f254 100644
--- a/website/pages/pl/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/pl/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Non-fatal errors

From 46cdbe54df1ca8c1dffa4ed7d224359c1f6c227f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:09 -0500
Subject: [PATCH 3355/3820] New translations advanced.mdx (Russian)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/ru/subgraphs/developing/creating/advanced.mdx b/website/pages/ru/subgraphs/developing/creating/advanced.mdx
index edf4e8358bd9..a264671c393e 100644
--- a/website/pages/ru/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/ru/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Тайм-серии и агрегации
 
-Тайм-серии и агрегации позволяют Вашему субграфу отслеживать такие статистические данные, как средняя цена за день, общий объем переводов за час и т. д.
+Prerequisites:
 
-Эта функция представляет два новых типа объектов субграфов. Объекты тайм-серий записывают точки данных с временными метками. Объекты агрегирования выполняют заранее объявленные вычисления над точками данных тайм-серий ежечасно или ежедневно, а затем сохраняют результаты для быстрого доступа через GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Пример схемы
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Определение тайм-серий и агрегаций
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Доступные интервалы агрегации
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Примечание:
-
-Чтобы использовать тайм-серии и агрегации, субграф должен иметь версию спецификации ≥1.1.0. Обратите внимание, что эта функция может претерпеть значительные изменения, которые могут повлиять на обратную совместимость.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Нефатальные ошибки

From 0f49f84cdf0819a4975b8e4a3727bcb4613a9627 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:11 -0500
Subject: [PATCH 3356/3820] New translations advanced.mdx (Swedish)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/sv/subgraphs/developing/creating/advanced.mdx b/website/pages/sv/subgraphs/developing/creating/advanced.mdx
index b23b5a9bb7a6..11a2aa1e6a73 100644
--- a/website/pages/sv/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/sv/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Icke dödliga fel

From d82ae2306fa1830db72ab1214b46f41c38eb6efa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:12 -0500
Subject: [PATCH 3357/3820] New translations advanced.mdx (Turkish)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/tr/subgraphs/developing/creating/advanced.mdx b/website/pages/tr/subgraphs/developing/creating/advanced.mdx
index cb3b29560228..980b0069c3e9 100644
--- a/website/pages/tr/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/tr/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Zaman Serileri ve Toplulaştırmalar
 
-Zaman serileri ve toplulaştırmalar, subgraph'inizin günlük ortalama fiyat, saatlik toplam transferler gibi istatistikleri takip etmesini sağlar.
+Prerequisites:
 
-Bu özellik, iki yeni subgraph varlık türünü tanıtır. Zaman Serisi varlıkları, zaman damgaları ile veri noktalarını kaydeder. Toplulaştırma varlıkları ise saatlik veya günlük bazda Zaman Serisi veri noktaları üzerinde önceden belirlenmiş hesaplamalar yapar ve sonuçları GraphQL üzerinden kolay erişim için saklar.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Örnek Şema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Zaman Serileri ve Toplulaştırmaları Tanımlama
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Mevcut Toplulaştırma Aralıkları
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Not:
-
-Zaman Serisi ve Toplulaştırmalar özelliklerini kullanmak için, subgraph’inizin spec sürümü ≥1.1.0 olmalıdır. Bu özelliğin, geriye dönük uyumluluğu etkileyebilecek önemli değişikliklerden geçebileceğini unutmayın.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Ölümcül Olmayan Hatalar

From eb94ba560988b1b2d72efdc5434b7fcc3e76399a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:13 -0500
Subject: [PATCH 3358/3820] New translations advanced.mdx (Ukrainian)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/uk/subgraphs/developing/creating/advanced.mdx b/website/pages/uk/subgraphs/developing/creating/advanced.mdx
index c35f84285c78..7614511a5617 100644
--- a/website/pages/uk/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/uk/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Non-fatal errors

From 5da9ad8588830620cecb6ea1e383eaf025745be5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:14 -0500
Subject: [PATCH 3359/3820] New translations advanced.mdx (Chinese Simplified)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/zh/subgraphs/developing/creating/advanced.mdx b/website/pages/zh/subgraphs/developing/creating/advanced.mdx
index c45246f33212..f7faa479f873 100644
--- a/website/pages/zh/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/zh/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## 非致命错误

From 809a9a75ea34a05d24aab9dab43be421b1dd6d29 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:15 -0500
Subject: [PATCH 3360/3820] New translations advanced.mdx (Urdu (Pakistan))

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/ur/subgraphs/developing/creating/advanced.mdx b/website/pages/ur/subgraphs/developing/creating/advanced.mdx
index 3d47fb8364cd..6d3c40d1e663 100644
--- a/website/pages/ur/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/ur/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Non-fatal errors

From 9e7c848af7f4e5657f704ede5bd30bdaefdacfc4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:16 -0500
Subject: [PATCH 3361/3820] New translations advanced.mdx (Vietnamese)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/vi/subgraphs/developing/creating/advanced.mdx b/website/pages/vi/subgraphs/developing/creating/advanced.mdx
index 757cec73a8fa..82d7dd120a70 100644
--- a/website/pages/vi/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/vi/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Lỗi không nghiêm trọng

From 06d44cab45af0e0ce7d21c7f3e3cfc8b6cda9c2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:18 -0500
Subject: [PATCH 3362/3820] New translations advanced.mdx (Marathi)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/mr/subgraphs/developing/creating/advanced.mdx b/website/pages/mr/subgraphs/developing/creating/advanced.mdx
index 5dc2a473ef77..c24f72030078 100644
--- a/website/pages/mr/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/mr/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## गैर-घातक त्रुटी

From 2fe36fce6eab64a98c3eeb0eaaf63e286b28cd4f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:19 -0500
Subject: [PATCH 3363/3820] New translations advanced.mdx (Hindi)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/hi/subgraphs/developing/creating/advanced.mdx b/website/pages/hi/subgraphs/developing/creating/advanced.mdx
index 769cdb5a3253..631278ebe555 100644
--- a/website/pages/hi/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/hi/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries और Aggregations
 
-Timeseries और aggregations आपके subgraph को दैनिक औसत मूल्य, घंटेवारी कुल स्थानांतरण आदि जैसे आंकड़े ट्रैक करने में सक्षम बनाते हैं।
+Prerequisites:
 
-यह विशेषता दो नए प्रकार की 'subgraph' इकाई पेश करती है। 'Timeseries' इकाइयाँ डेटा बिंदुओं को समय की छाप के साथ रिकॉर्ड करती हैं। 'Aggregation' इकाइयाँ 'Timeseries' डेटा बिंदुओं पर पूर्व-घोषित गणनाएँ करती हैं, जो प्रति घंटे या प्रति दिन होती हैं, फिर परिणामों को GraphQL के माध्यम से आसान पहुँच के लिए संग्रहीत करती हैं।
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### उदाहरण स्कीमा
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### टाइमसीरीज और एग्रीगेशन्स को परिभाषित करना
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### उपलब्ध Aggregation अंतराल
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-नोट:
-
-Timeseries और Aggregations का उपयोग करने के लिए, एक subgraph का spec version ≥1.1.0 होना चाहिए। ध्यान दें कि यह सुविधा महत्वपूर्ण परिवर्तनों का सामना कर सकती है जो पीछे की संगतता को प्रभावित कर सकती है।
-
 [और पढ़ें](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) समय श्रृंखला और संक्षेपण के बारे में।
 
 ## गैर-घातक त्रुटियाँ

From e8f9bb5b16857828f9d53ed40f83caecc8fc88f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 18:34:20 -0500
Subject: [PATCH 3364/3820] New translations advanced.mdx (Swahili)

---
 .../developing/creating/advanced.mdx          | 26 ++++++++++++-------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/website/pages/sw/subgraphs/developing/creating/advanced.mdx b/website/pages/sw/subgraphs/developing/creating/advanced.mdx
index a6a4b224bc3e..ee9918f5f254 100644
--- a/website/pages/sw/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/sw/subgraphs/developing/creating/advanced.mdx
@@ -29,9 +29,13 @@ dataSources: ...
 
 ## Timeseries and Aggregations
 
-Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, etc.
+Prerequisites:
 
-This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the Timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
+- Subgraph specVersion must be ≥1.1.0.
+
+Timeseries and aggregations enable your subgraph to track statistics like daily average price, hourly total transfers, and more.
+
+This feature introduces two new types of subgraph entity. Timeseries entities record data points with timestamps. Aggregation entities perform pre-declared calculations on the timeseries data points on an hourly or daily basis, then store the results for easy access via GraphQL.
 
 ### Example Schema
 
@@ -49,11 +53,19 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-### Defining Timeseries and Aggregations
+### How to Define Timeseries and Aggregations
+
+Timeseries entities are defined with `@entity(timeseries: true)` in the GraphQL schema. Every timeseries entity must:
+
+- have a unique ID of the int8 type
+- have a timestamp of the Timestamp type
+- include data that will be used for calculation by aggregation entities.
 
-Timeseries entities are defined with `@entity(timeseries: true)` in schema.graphql. Every timeseries entity must have a unique ID of the int8 type, a timestamp of the Timestamp type, and include data that will be used for calculation by aggregation entities. These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the Aggregation entities.
+These Timeseries entities can be saved in regular trigger handlers, and act as the “raw data” for the aggregation entities.
 
-Aggregation entities are defined with `@aggregation` in schema.graphql. Every aggregation entity defines the source from which it will gather data (which must be a Timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last). Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
+Aggregation entities are defined with `@aggregation` in the GraphQL schema. Every aggregation entity defines the source from which it will gather data (which must be a timeseries entity), sets the intervals (e.g., hour, day), and specifies the aggregation function it will use (e.g., sum, count, min, max, first, last).
+
+Aggregation entities are automatically calculated on the basis of the specified source at the end of the required interval.
 
 #### Available Aggregation Intervals
 
@@ -81,10 +93,6 @@ Aggregation entities are defined with `@aggregation` in schema.graphql. Every ag
 }
 ```
 
-Note:
-
-To use Timeseries and Aggregations, a subgraph must have a spec version ≥1.1.0. Note that this feature might undergo significant changes that could affect backward compatibility.
-
 [Read more](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) about Timeseries and Aggregations.
 
 ## Non-fatal errors

From 9bb5ca5927cd492a863aa22bb76fcc9653b05993 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 21:17:38 -0500
Subject: [PATCH 3365/3820] New translations overview.mdx (Portuguese)

---
 website/pages/pt/indexing/overview.mdx | 237 +++++++++++++------------
 1 file changed, 119 insertions(+), 118 deletions(-)

diff --git a/website/pages/pt/indexing/overview.mdx b/website/pages/pt/indexing/overview.mdx
index e3202f60fe2a..ff60f54a0e03 100644
--- a/website/pages/pt/indexing/overview.mdx
+++ b/website/pages/pt/indexing/overview.mdx
@@ -1,5 +1,5 @@
 ---
-title: Indexing Overview
+title: Visão Geral sobre a Indexação
 ---
 
 Indexadores são operadores de nodes na Graph Network que fazem staking em Graph Tokens (GRT) para prover serviços de indexação e processamento de consultas em query (queries). Os indexadores ganham taxas de consulta e recompensas de indexação pelos seus serviços. Eles também ganham taxas de query que são rebatadas de acordo com uma função de rebate exponencial.
@@ -18,15 +18,15 @@ O stake mínimo atual para um Indexador é de 100 mil GRT.
 
 ### Quais são as fontes de renda para um Indexador?
 
-**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+**Rebates de taxas de query** - Pagamentos por serviço de queries na rede. Estes pagamentos são mediados por canais de estado entre um Indexador e um gateway. Cada pedido de query de um gateway contém um pagamento e a resposta correspondente: uma prova de validade de resultado de query.
 
-**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+**Recompensas de indexação** — são distribuídas a Indexadores que indexam lançamentos de subgraph para a rede. São geradas através de uma inflação de 3% para todo o protocolo.
 
 ### Como são distribuídas as recompensas de indexação?
 
-Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+As recompensas de indexação vêm da inflação do protocolo, que é configurada em 3% da emissão anual. Elas são distribuídas em subgraphs, com base na proporção de todos os sinais de curadoria em cada um, e depois distribuídos proporcionalmente a Indexadores baseado no stake que alocaram naquele subgraph. Para ser elegível a recompensas, uma alocação deve ser fechada com uma prova de indexação válida (POI) que atende aos padrões determinados pela carta de arbitragem.
 
-Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+A comunidade criou várias ferramentas para calcular recompensas, organizadas na [coleção de guias da comunidade](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). Há também uma lista atualizada de ferramentas nos canais #Delegators e #Indexers no [servidor do Discord](https://discord.gg/graphprotocol). No próximo link, temos um [otimizador de alocações recomendadas](https://github.com/graphprotocol/allocation-optimizer) integrado com o stack de software de indexador.
 
 ### O que é uma prova de indexação (POI)?
 
@@ -38,11 +38,11 @@ As alocações continuamente acumulam recompensas enquanto permanecerem ativas e
 
 ### É possível monitorar recompensas de indexação pendentes?
 
-The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+O contrato RewardsManager tem uma função de apenas-leitura — [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) — que pode ser usada para verificar as recompensas pendentes para uma alocação específica.
 
 Muitos dos painéis feitos pela comunidade incluem valores pendentes de recompensas, que podem facilmente ser conferidos de forma manual ao seguir os seguintes passos:
 
-1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+1. Faça um query do [subgraph da mainnet](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) para buscar as IDs para todas as alocações ativas:
 
 ```graphql
 query indexerAllocations {
@@ -58,61 +58,61 @@ query indexerAllocations {
 }
 ```
 
-Use Etherscan to call `getRewards()`:
+Use o Etherscan para chamar o `getRewards()`:
 
-- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+- Navegue, na [interface do Etherscan, para o contrato Rewards](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract):
 
 <!---->
 
-- To call `getRewards()`:
-  - Expand the **9. getRewards** dropdown.
-  - Enter the **allocationID** in the input.
-  - Click the **Query** button.
+- Para chamar o `getRewards()`:
+  - Abra o dropdown **9. getRewards**.
+  - Insira a **allocationID**.
+  - Clique no botão **Query**.
 
 ### O que são disputas e onde posso vê-las?
 
 As consultas em query e alocações de Indexadores podem ser disputadas no The Graph durante o período de disputa. O período de disputa varia dependendo do tipo de disputa. Consultas/atestações têm uma janela de disputa de 7 epochs, enquanto alocações duram até 56 epochs. Após o vencimento destes períodos, não se pode abrir disputas contra alocações ou consultas. Quando uma disputa é aberta, um depósito mínimo de 10.000 GRT é exigido pelos Pescadores, que será trancado até ser finalizada a disputa e servida uma resolução. Pescadores são quaisquer participantes de rede que abrem disputas.
 
-Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+Há **três** possíveis resultados para disputas, assim como o depósito dos Pescadores.
 
 - Se a disputa for rejeitada, o GRT depositado pelo Pescador será queimado, e o Indexador disputado não será penalizado.
 - Se a disputa terminar em empate, o depósito do Pescador será retornado, e o Indexador disputado não será penalizado.
 - Caso aceita a disputa, o GRT depositado pelo Pescador será retornado, o Indexador disputado será penalizado, e o(s) Pescador(es) ganhará(ão) 50% do GRT cortado.
 
-Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+As disputas podem ser visualizadas na interface na página de perfil de um Indexador, sob a aba `Disputes` (Disputas).
 
 ### O que são rebates de taxas de consulta e quando eles são distribuídos?
 
-Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+As taxas de query são coletadas pelo gateway e distribuídas aos Indexadores de acordo com a função de rebate exponencial (veja o GIP [aqui](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162). A tal função é proposta como uma maneira de garantir que indexadores alcancem o melhor resultado ao servir queries fieis. Ela funciona com o incentivo de Indexadores para alocarem uma grande quantia de stake (que pode ser cortada por errar ao servir um query) relativa à quantidade de taxas de query que possam colecionar.
 
 Quando uma alocação é fechada, os rebates podem ser reivindicados pelo Indexador. Ao reivindicar, os rebates de taxa de consulta são distribuídos ao Indexador e os seus Delegantes com base na porção de taxas de consulta e na função de rebate exponencial.
 
 ### O que são porção de taxa de consulta e porção de recompensa de indexação?
 
-The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+Os valores `queryFeeCut` e `indexingRewardCut` são parâmetros de delegação que o Indexador pode configurar, junto do `cooldownBlocks`, para controlar a distribuição de GRT entre o Indexador e os seus Delegantes. Veja os últimos passos em [Staking no Protocolo](/indexing/overview/#stake-in-the-protocol) para instruções sobre como configurar os parâmetros de delegação.
 
-- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+- **queryFeeCut** — a % de rebates de taxas de query a ser distribuída ao Indexador. Se isto for configurado em 95%, o Indexador receberá 95% das taxas de query ganhas quando uma alocação for fechada, com os outros 5% destinados aos Delegantes.
 
-- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+- **indexingRewardCut** — a % de recompensas de indexação a ser distribuída ao Indexador. Se isto for configurado em 95%, o Indexador receberá 95% do pool de recompensas de indexação ao fechamento de uma alocação e os Delegantes dividirão os outros 5%.
 
 ### Como os Indexadores podem saber quais subgraphs indexar?
 
 Os Indexadores podem se diferenciar ao aplicar técnicas avançadas para decidir indexações de subgraph, mas para dar uma ideia geral, vamos discutir várias métricas importantes usadas para avaliar subgraphs na rede:
 
-- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+- **Sinal de curadoria** — A proporção do sinal de curadoria na rede aplicado a um subgraph particular mede bem o interesse naquele subgraph; especialmente durante a fase de inicialização, quando o volume de queries começa a subir.
 
-- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+- **Taxas de query coletadas** — Os dados históricos para o volume de taxas de query coletadas para um subgraph específico indicam bem a demanda futura.
 
-- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+- **Quantidade em staking** — Ao monitorizar o comportamento de outros Indexadores ou inspecionar proporções de stake total alocados a subgraphs específicos, um Indexador pode monitorizar a reserva para queries nos subgraphs, para identificar subgraphs nos quais a rede mostra confiança ou subgraphs que podem necessitar de mais reservas.
 
-- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+- **Subgraphs sem recompensas de indexação** — Alguns subgraphs não geram recompensas de indexação, principalmente por usarem recursos não apoiados — como o IPFS — ou porque consultam outra rede fora da mainnet. Se um subgraph não estiver a gerar recompensas de indexação, o Indexador será notificado a respeito.
 
 ### Quais são os requisitos de hardware?
 
-- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
-- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
-- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
-- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+- **Pequeno** — O suficiente para começar a indexar vários subgraphs. Provavelmente precisará de expansões.
+- **Normal** — Setup normal. Este é o usado nos exemplos de manifests de lançamento k8s/terraform.
+- **Médio** — Indexador de Produção. Apoia 100 subgraphs e 200–500 pedidos por segundo.
+- **Grande** — Preparado para indexar todos os subgraphs usados atualmente e servir pedidos para o tráfego relacionado.
 
 | Setup   | Postgres<br />(CPUs) | Postgres<br />(memória em GBs) | Postgres<br />(disco em TBs) | VMs<br />(CPUs) | VMs<br />(memória em GBs) |
 | ------- | :------------------: | :----------------------------: | :--------------------------: | :-------------: | :-----------------------: |
@@ -123,31 +123,31 @@ Os Indexadores podem se diferenciar ao aplicar técnicas avançadas para decidir
 
 ### Há alguma precaução básica de segurança que um Indexador deve tomar?
 
-- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+- **Carteira de operador** — Configurar uma carteira de operador é importante, pois permite a um Indexador manter a separação entre as suas chaves que controlam o stake e aquelas no controlo das operações diárias. Mais informações em [Staking no Protocolo](/indexing/overview/#stake-in-the-protocol).
 
-- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+- **Firewall** — O serviço de Indexadores é o único que precisa ser exposto publicamente. O trancamento de portas de admin, e o acesso ao banco de dados, exigem muito mais atenção: o endpoint JSON-RPC do Graph Node (porta padrão: 8030), o endpoint da API de gestão do Indexador (porta padrão: 18000), e o endpoint do banco de dados Postgres (porta padrão: 5432) não devem ser expostos.
 
 ## Infraestutura
 
-At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+O núcleo da infraestrutura de um Indexador é o Graph Node, que monitora as redes indexadas, extrai e carrega dados por uma definição de um subgraph, e o serve como uma [API GraphQL](/about/#how-the-graph-works). O Graph Node deve estar conectado a endpoints que expõem dados de cada rede indexada; um node IPFS para abastecer os dados; um banco de dados PostgreSQL para o seu armazenamento; e componentes de Indexador que facilitem as suas interações com a rede.
 
-- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+- **Banco de dados PostgreSQL** — O armazenamento principal para o Graph Node, onde dados de subgraph são armazenados. O serviço e o agente indexador também usam o banco de dados para armazenar dados de canal de estado, modelos de custo, regras de indexação, e ações de alocação.
 
-- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+- **Endpoint de dados** — Para redes compatíveis com EVMs, o Graph Node deve estar conectado a um endpoint que expõe uma API JSON-RPC compatível com EVMs. Isto pode ser um único cliente, ou um setup mais complexo que carrega saldos em várias redes. É importante saber que certos subgraphs exigirão capacidades particulares de clientes, como um modo de arquivo e uma API de rastreamento.
 
-- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+- **Node IPFS (versão menor que 5)** — Os metadados de lançamento de subgraph são armazenados na rede IPFS. O Graph Node acessa primariamente o node IPFS durante o lançamento do subgraph, para retirar o manifest e todos os arquivos ligados. Indexadores de rede não precisam hospedar o seu próprio node IPFS, pois já há um hospedado para a rede em https://ipfs.network.thegraph.com.
 
-- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+- **Serviço de Indexador** — Cuida de todas as comunicações externas com a rede necessárias. Divide modelos de custo e estados de indexação, passa pedidos de consulta de gateways para um Graph Node, e monitora os pagamentos de consulta via canais de estado com o gateway.
 
-- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Agente Indexador** — Facilita as interações de Indexadores on-chain, incluindo cadastros na rede, gestão de lançamentos de Subgraph ao(s) seu(s) Graph Node(s), e gestão de alocações.
 
-- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+- **Servidor de métricas Prometheus** — O Graph Node e os componentes de Indexador logam suas métricas ao servidor de métricas.
 
 Nota: Para apoiar o escalamento ágil, recomendamos que assuntos de consulta e indexação sejam separados entre conjuntos diferentes de nodes: nodes de consulta e nodes de indexação.
 
 ### Resumo das portas
 
-> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+> **Importante:** Cuidado ao expor portas publicamente — as **portas de administração** devem ser trancadas a sete chaves. Isto inclui o endpoint JSON-RPC do Graph Node e os pontos finais de gestão de Indexador detalhados abaixo.
 
 #### Graph Node
 
@@ -168,9 +168,9 @@ Nota: Para apoiar o escalamento ágil, recomendamos que assuntos de consulta e i
 
 #### Agente Indexador
 
-| Porta | Purpose                    | Rotas  | CLI Argument               | Environment Variable                    |
-| ----- | -------------------------- | ------ | -------------------------- | --------------------------------------- |
-| 8000  | API de gestão de Indexador | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+| Porta | Propósito                  | Rotas  | Argumento na CLI              | Variáveis de ambiente                    |
+| ----- | -------------------------- | ------ | ----------------------------- | ---------------------------------------- |
+| 8000  | API de gestão de Indexador | /      | \--indexer-management-port    | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT`  |
 
 ### Preparando uma infraestrutura de servidor usando o Terraform no Google Cloud
 
@@ -184,9 +184,9 @@ Nota: Para apoiar o escalamento ágil, recomendamos que assuntos de consulta e i
 
 #### Como criar um projeto no Google Cloud
 
-- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+- Clone, ou navegue para, o [repositório do Indexer](https://github.com/graphprotocol/indexer).
 
-- Navigate to the `./terraform` directory, this is where all commands should be executed.
+- Navegue ao diretório `./terraform`, que é onde todos os comandos devem ser executados.
 
 ```sh
 cd terraform
@@ -229,7 +229,7 @@ gcloud iam service-accounts create $svc_name \
   --description="Service account for Terraform" \
   --display-name="$svc_name"
 gcloud iam service-accounts list
-# Get the email of the service account from the list
+# Isto resgata o e-mail da conta de serviço da lista
 svc=$(gcloud iam service-accounts list --format='get(email)'
 --filter="displayName=$svc_name")
 gcloud iam service-accounts keys create .gcloud-credentials.json \
@@ -266,7 +266,7 @@ EOF
 
 #### Usando o Terraform para criar infraestrutura
 
-Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+Antes de executar quaisquer comandos, leia o [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) e crie um arquivo `terraform.tfvars` neste diretório (ou modifique o que criamos no último passo). Para cada variável onde queira substituir o padrão, ou onde precisar configurar um valor, insira uma configuração no `terraform.tfvars`.
 
 - Execute os seguintes comandos para criar a infraestrutura.
 
@@ -281,7 +281,7 @@ terraform plan
 terraform apply
 ```
 
-Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+Baixe credenciais para o novo cluster no `~/.kube/config` e configure-o como o seu contexto padrão.
 
 ```sh
 gcloud container clusters get-credentials $indexer
@@ -291,15 +291,15 @@ kubectl config use-context $(kubectl config get-contexts --output='name'
 
 #### Criando os componentes do Kubernetes para o Indexador
 
-- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+- Copie o diretório `k8s/overlays` a um novo diretório `$dir`, e ajuste a entrada `bases` no `$dir/kustomization.yaml`, para apontar para o `k8s/base`.
 
-- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+- Leia todos os arquivos no `$dir` e ajuste quaisquer valores conforme indicado nos comentários.
 
-Deploy all resources with `kubectl apply -k $dir`.
+Lance todos os recursos com `kubectl apply -k $dir`.
 
 ### Graph Node
 
-[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+O [Graph Node](https://github.com/graphprotocol/graph-node) é uma implementação em Rust de código aberto que faz event sources na blockchain Ethereum, para atualizar deterministicamente um armazenamento de dados que pode ser consultado através do endpoint GraphQL. Os programadores usam subgraphs para definir o seu schema e um conjunto de mapeamentos para transformar os dados da blockchain; e o Graph Node sincroniza toda a chain, monitora blocos novos, e serve-a através de um endpoint GraphQL.
 
 #### Começando da fonte
 
@@ -311,7 +311,7 @@ Deploy all resources with `kubectl apply -k $dir`.
 
 - **IPFS**
 
-- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+- **Requisitos Adicionais para utilizadores de Ubuntu** — A execução de um Graph Node no Ubuntu pode exigir pacotes adicionais.
 
 ```sh
 sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
@@ -327,7 +327,7 @@ pg_ctl -D .postgres -l logfile start
 createdb graph-node
 ```
 
-2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+2. Clone o repositório do [Graph Node](https://github.com/graphprotocol/graph-node) e execute `cargo build` para construir a fonte 
 
 3. Agora que todas as dependências estão prontas, inicie o Graph Node:
 
@@ -342,7 +342,7 @@ cargo run -p graph-node --release -- \
 
 #### Pré-requisitos
 
-- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+- **Node Ethereum** — Por padrão, o setup do docker utilizará a mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) para se conectar ao node Ethereum na sua máquina de hospedagem. Este nome e url podem ser substituídos com uma atualização no `docker-compose.yaml`.
 
 #### Setup
 
@@ -353,7 +353,7 @@ git clone https://github.com/graphprotocol/graph-node
 cd graph-node/docker
 ```
 
-2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml `using the included script:
+2. Para utilizadores de Linux — use o endereço de IP do servidor em vez do `host.docker.internal` no `docker-compose.yaml` usando o script incluído:
 
 ```sh
 ./setup.sh
@@ -369,15 +369,15 @@ docker-compose up
 
 Para participar com êxito na rede, são necessários monitorados e interações quase constantes, portanto, construímos uma suite de aplicativos Typescript para facilitar a participação de um Indexador na rede. Há três componentes de Indexador:
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+- **Agente indexador** — O agente monitora a rede e a própria infraestrutura do Indexador, e administra quais lançamentos de subgraph são indexados e alocados on-chain; e a quantia a ser alocada para cada um.
 
-- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+- **Serviço indexador** — O único componente que deve ser exposto externamente, o serviço passa queries de subgraph ao graph node, cuida de canais de estado para pagamentos de consulta, e compartilha informações importantes de decisões para clientes, como os gateways.
 
-- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+- **Indexer CLI** — A interface de comando de linha para manusear o agente indexador. Ela permite que Indexadores cuidem de modelos de custo, alocações manuais, filas de ações e regras de indexação.
 
 #### Começando
 
-The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+O agente indexador e o serviço indexador devem ser co-localizados com a sua infraestrutura de Graph Node. Há várias maneiras de preparar ambientes de execução virtual para os seus componentes de Indexador. Aqui, veja como executá-los em um bare-metal (servidor dedicado) com pacotes NPM ou código fonte, ou através do Kubernetes e o docker no Engine Kubernetes do Google Cloud. Se estes exemplos de setup não batem bem com a sua infraestrutura, provavelmente deverá consultar um guia de comunidade no nosso [Discord](https://discord.gg/graphprotocol). Lembre-se de [fazer staking no protocolo](/indexing/overview/#stake-in-the-protocol) antes de iniciar os seus componentes de Indexador!
 
 #### De pacotes NPM
 
@@ -439,7 +439,7 @@ docker build \
   --build-arg NPM_TOKEN=<npm-token> \
   -f Dockerfile.indexer-service \
   -t indexer-service:latest \
-# Indexer agent
+# Agente indexador
 docker build \
   --build-arg NPM_TOKEN=<npm-token> \
   -f Dockerfile.indexer-agent \
@@ -453,15 +453,15 @@ docker run -p 7600:7600 -it indexer-service:latest ...
 docker run -p 18000:8000 -it indexer-agent:latest ...
 ```
 
-**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+\*\*NOTA: Após iniciar os containers, o serviço Indexador deve ser acessível no [http://localhost:7600](http://localhost:7600) e o agente indexador deve expor a API de gestão no [http://localhost:18000/](http://localhost:18000/).
 
 #### Usando K8s e Terraform
 
-See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+Veja a secção [Como Organizar a Infraestrutura de um Servidor com o Terraform na Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud)
 
 #### Uso
 
-> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+> **NOTA:** Todas as variáveis de configuração de runtime (tempo de execução) podem ser aplicadas ao comando como parâmetros, na inicialização, ou usando variáveis de ambiente do formato `COMPONENT_NAME_VARIABLE_NAME` (por ex. `INDEXER_AGENT_ETHEREUM`).
 
 #### Agente Indexador
 
@@ -520,7 +520,7 @@ graph-indexer-service start \
 
 #### Indexer CLI
 
-The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+O Indexer CLI é um plugin para [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli), acessível pelo terminal em `graph indexer`.
 
 ```sh
 graph indexer connect http://localhost:18000
@@ -529,45 +529,45 @@ graph indexer status
 
 #### Gestão de Indexador usando o Indexer CLI
 
-The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+O programa recomendado para interagir com a **API de Gestão de Indexador é o **Indexer CLI**, uma extensão para o **Graph CLI**. O agente precisa de comandos de um Indexador para poder interagir de forma autônoma com a rede em nome do Indexer. Os mecanismos que definem o comportamento de um agente indexador são **gestão de alocações** e **regras de indexamento**. No modo automático, um Indexador pode usar **regras de indexamento** para aplicar estratégias específicas para a escolha de subgraphs para indexar e servir consultas. Regras são gerenciadas através de uma API GraphQL servida pelo agente, e conhecida como a API de Gestão de Indexador. No modo manual, um Indexador pode criar ações de alocação usando a **fila de ações**, além de aprová-las explicitamente antes de serem executadas. Sob o modo de supervisão, as **regras de indexação** são usadas para popular a **fila de ações\*\* e também exigem aprovação explícita para executar.
 
 #### Uso
 
-The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+O **Indexer CLI** se conecta ao agente indexador, normalmente através do redirecionamento de portas, para que a CLI não precise ser executada no mesmo servidor ou cluster. Para começar mais facilmente, e para fins de contexto, a CLI será descrita brevemente aqui.
 
-- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+- `graph indexer connect <indexer-agent-pod>` — Conecta à API de gestão de Indexador. Tipicamente, a conexão ao servidor é aberta através do redirecionamento de portas, para que a CLI possa ser operada remotamente com facilidade. (Exemplo: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
 
-- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+- `graph indexer rules get [options] <deployment-id> [<key1>...]` — Mostra uma ou mais regras de indexação usando `all` como o `<deployment-id>` para mostrar todas as regras, ou global para exibit os padrões globais. Um argumento adicional `--merged` pode ser usado para especificar que regras específicas ao lançamento serão fundidas com a regra global. É assim que elas são aplicadas no agente de Indexador.
 
-- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` — Configura uma ou mais regras de indexação.
 
-- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+- `graph indexer rules start [options] <deployment-id>` — Começa a indexar um lançamento de subgraph, se disponível, e configura a sua `decisionBasis` para `always`, fazendo que o agente indexador sempre escolha indexá-lo. Caso a regra global seja configurada para `always`, todos os subgraphs disponíveis na rede serão indexados.
 
-- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+- `graph indexer rules stop [options] <deployment-id>` — Para de indexar um lançamento e configura a sua `decisionBasis` para `never`, com o fim de pular este lançamento ao decidir quais lançamentos indexar.
 
-- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+- `graph indexer rules maybe [options] <deployment-id>` — Configura a `decisionBasis` de um lançamento para `rules`, comandando o agente indexador a usar regras de indexação para decidir se este lançamento será ou não indexado.
 
-- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+- `graph indexer actions get [options] <action-id>` — Retira uma ou mais ações usando o `all`, ou deixa o `action-id` vazio para mostrar todas as ações. Um argumento adicional — `--status` — pode ser usado para imprimir todas as ações de um certo status.
 
-- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+- `graph indexer action queue reallocate <deployment-id> <allocation-amount>` — Programa uma ação de realocação
 
-- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` — Programa uma ação de realocação
 
-- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` — Programa uma retirada de alocação
 
-- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+- `graph indexer actions cancel [<action-id> ...]` — Cancela todas as ações na fila se a id não for especificada; caso contrário, cancela o arranjo do id com espaço como separador
 
-- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+- `graph indexer actions approve [<action-id> ...]` — Aprova múltiplas ações para execução
 
-- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+- `graph indexer actions execute approve` — Força a execução imediata de ações aprovadas
 
-All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+Todos os comandos que mostram regras no resultado podem escolher entre os formatos de resultado (`table`, `yaml`, e `json`) com o argumento `-output`.
 
 #### Regras de indexação
 
-Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+As regras de indexação podem ser aplicadas como padrões globais ou para lançamentos de subgraph específicos com o uso das suas IDs. Os campos `deployment` e `decisionBasis` são obrigatórios, enquanto todos os outros campos são opcionais. Quando uma regra de indexação tem `rules` como a `decisionBasis`, então o agente de Indexador comparará valores de limiar não-nulos naquela regra com valores retirados da rede para o lançamento correspondente. Se o lançamento do subgraph tiver valores acima (ou abaixo) de todos os limiares, ele será escolhido para a indexação.
 
-For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+Por exemplo: se a regra global tem um `minStake` de **5** (GRT), qualquer lançamento de subgraph que tiver mais de 5 (GRT) de stake alocado nele será indexado. As regras de limiar incluem `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, e `minAverageQueryFees`.
 
 Modelo de dados:
 
@@ -617,15 +617,15 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 #### CLI de fila de ações
 
-The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+O indexer-cli fornece um módulo `actions` para trabalhar manualmente com a fila de ações. Ele interage com a fila de ações através do **API GraphQL** hospedado pelo servidor de gestão de indexador.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+O programa de execução de ações só retirará itens da fila para execução se esses tiverem o `ActionStatus = approved`. No local recomendado, as ações são adicionadas à fila com `ActionStatus = queued`; depois, serão aprovadas para serem executadas on-chain. O fluxo geral ficará assim:
 
 - Ação adicionada à fila por ferramenta de otimização de terceiros ou utilizador do indexer-cli
-- Indexer can use the `indexer-cli` to view all queued actions
-- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
-- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
-- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- O Indexador pode usar o `indexer-cli` para visualizar todas as ações enfileiradas
+- O Indexador (ou outro software) pode aprovar ou cancelar ações na fila usando o `indexer-cli`. Os comandos de aprovação e cancelamento aceitam um arranjo de Ids de ação como comando.
+- O programa de execução consulta a fila regularmente para verificar as ações aprovadas. Ele tomará as ações `approved` da fila, tentará executá-las, e atualizará os valores no banco de dados a depender do estado da execução, sendo `success` ou `failed`.
+- Se uma ação tiver êxito, o programa garantirá a presença de uma regra de indexação que diga ao agente como administrar a alocação dali em diante. Isto será mais conveniente para executar ações manuais enquanto o agente está no modo `auto` ou `oversight`.
 - O indexador pode monitorizar a fila de ações para ver um histórico de execuções de ação, e se necessário, aprovar novamente e atualizar itens de ação caso a sua execução falhe. A fila de ações provém um histórico de todas as ações agendadas e tomadas.
 
 Modelo de dados:
@@ -683,13 +683,13 @@ graph indexer actions execute approve
 
 Note que os tipos apoiados de ações para gestão de alocação têm requisitos diferentes de entrada:
 
-- `Allocate` - allocate stake to a specific subgraph deployment
+- `Allocate` — aloca stakes a um lançamento de subgraph específico
 
   - parâmetros de ação exigidos:
     - deploymentID
     - amount
 
-- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+- `Unallocate` — fecha uma alocação, liberando o stake para ser realocado em outro lugar
 
   - parâmetros de ação exigidos:
     - allocationID
@@ -698,7 +698,7 @@ Note que os tipos apoiados de ações para gestão de alocação têm requisitos
     - poi
     - force (força o uso do POI providenciado, mesmo se ele não corresponder ao providenciado pelo graph-node)
 
-- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+- `Reallocate` — fecha a alocação automaticamente e abre uma alocação nova para o mesmo lançamento de subgraph
 
   - parâmetros de ação exigidos:
     - allocationID
@@ -721,19 +721,20 @@ Uma declaração consiste de um predicado, que é usado para corresponder a busc
 Exemplo de modelo de custo:
 
 ```
-# This statement captures the skip value,
-# uses a boolean expression in the predicate to match specific queries that use `skip`
-# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+# Esta instrução captura o valor de skip,
+# usa uma expressão boolean no predicado para corresponder a consultas específicas que usam 'skip'
+# e uma expressão de custo para calcular o custo baseado no valor `skip` e no global SYSTEM_LOAD
+SYSTEM_LOAD global
 query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
 
-# This default will match any GraphQL expression.
-# It uses a Global substituted into the expression to calculate cost
-default => 0.1 * $SYSTEM_LOAD;
+# Este padrão será igualado a qualquer expressão na GraphQL.
+# Ele usa um Global, inserido na expressão para calcular o custo
+default = 0.1 * $SYSTEM_LOAD;
 ```
 
 Exemplo de custo de query usando o modelo acima:
 
-| Query                                                                        | Price   |
+| Query                                                                        | Preço   |
 | ---------------------------------------------------------------------------- | ------- |
 | &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
 | &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
@@ -754,41 +755,41 @@ indexer cost set model my_model.agora
 
 Os primeiros passos para participar como Indexador consistem em aprovar o protocolo, fazer staking de fundos, e (opcionalmente) preparar um endereço de operador para interações ordinárias do protocolo.
 
-> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+> Nota: Para os fins destas instruções, o Remix será usado para interação com contratos, mas é possível escolher a sua ferramenta preferida (Por exemplo: [OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/) e [MyCrypto](https://www.mycrypto.com/account)).
 
-Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+Quando um Indexador faz stake de GRT no protocolo, será possível iniciar os [seus componentes](/indexing/overview/#indexer-components) e começar as suas interações com a rede.
 
 #### Aprovação de tokens
 
-1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+1. Abra o [aplicativo Remix](https://remix.ethereum.org/) em um navegador de Internet
 
-2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+2. Em `File Explorer`, crie um arquivo chamado **GraphToken.abi** com o [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
 
-3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+3. Com `GraphToken.abi` selecionado e aberto no editor, abra a seção `Deploy and Run Transactions` (Lançar e Executar Transações) na interface do Remix.
 
-4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+4. Na opção **Environment** (ambiente), selecione `Injected Web3`, e sob `Account`, selecione o seu endereço de Indexador.
 
-5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+5. Selecione o endereço de contrato do GraphToken, e cole este endereço (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) próximo do botão `At Address`; clique neste botão para aplicar.
 
-6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+6. Chame a função `approve(spender, amount)` para aprovar o contrato de Staking. Preencha a lacuna `spender` com o endereço de contrato de Staking (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`), e `amount` com os tokens a serem colocados (em wei).
 
 #### Staking de tokens
 
-1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+1. Abra o [aplicativo Remix](https://remix.ethereum.org/) em um navegador de Internet
 
-2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+2. No `File Explorer`, crie um arquivo chamado **Staking.abi** com a ABI de staking.
 
-3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+3. Com o `Staking.abi` selecionado e aberto no editor, abra a seção `Deploy and Run Transactions` na interface do Remix.
 
-4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+4. Na opção **Environment** (ambiente), selecione `Injected Web3`, e sob `Account`, selecione o seu endereço de Indexador.
 
-5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+5. Selecione o endereço de contrato de Staking e cole este endereço (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) próximo do botão `At Address`; clique neste botão para aplicar.
 
-6. Call `stake()` to stake GRT in the protocol.
+6. Chame `stake()` para fazer stake de GRT no protocolo.
 
-7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+7. (Opcional) Os Indexadores podem aprovar outro endereço para operar sua infraestrutura de Indexador, a fim de poder separar as chaves que controlam os fundos daquelas que realizam ações rotineiras; por exemplo, alocar em subgraphs e servir queries (pagos). Para configurar o operador, chame `setOperator()` com o endereço do operador.
 
-8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+8. (Opcional) Para controlar a distribuição de recompensas e atrair Delegantes estrategicamente, os Indexadores podem atualizar os seus parâmetros de delegação atualizando o seu indexingRewardCut (partes por milhão); queryFeeCut (partes por milhão); e cooldownBlocks (número de blocos). Para fazer isto, chame o `setDelegationParameters()`. O seguinte exemplo configura o queryFeeCut para distribuir 95% de rebates de query ao Indexador e 5% aos Delegantes; configura o indexingRewardCutto para distribuir 60% de recompensas de indexação ao Indexador e 40% aos Delegantes; e configura o período do `thecooldownBlocks` para 500 blocos.
 
 ```
 setDelegationParameters(950000, 600000, 500)
@@ -796,13 +797,13 @@ setDelegationParameters(950000, 600000, 500)
 
 ### Configuração de parâmetros de delegação
 
-The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+A função `setDelegationParameters()` no [contrato de staking](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) é essencial para Indexadores; esta permite configurar parâmetros que definem as suas interações com Delegantes, o que influencia a sua capacidade de delegação e divisa de recompensas.
 
 ### Como configurar parâmetros de delegação
 
 Para configurar os parâmetros de delegação com a interface do Graph Explorer, siga os seguintes passos:
 
-1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
+1. Navegue para o [Graph Explorer](https://thegraph.com/explorer/).
 2. Conecte a sua carteira. Escolha a multisig (por ex., Gnosis Safe) e depois selecione a mainnet. Nota: Será necessário repetir este processo para o Arbitrum One.
 3. Conecte a sua carteira como signatário.
 4. Navegue até a seção 'Settings' (Configurações) e selecione 'Delegation Parameters' (Parâmetros de Delegação). Estes parâmetros devem ser configurados para alcançar uma parte efetiva dentro do alcance desejado. Após preencher os campos com valores, a interface calculará automaticamente a parte efetiva. Ajuste estes valores como necessário para obter a percentagem de parte efetiva desejada.
@@ -812,10 +813,10 @@ Para configurar os parâmetros de delegação com a interface do Graph Explorer,
 
 ### A vida de uma alocação
 
-After being created by an Indexer a healthy allocation goes through two states.
+Após criada por um Indexador, uma alocação sadia passa por quatro estados:
 
-- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Ativa** - Quando uma alocação é criada on-chain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)), ela é considerada **ativa**. Uma porção do stake próprio e/ou delegado do Indexador é alocada a um lançamento de subgraph, que lhe permite resgatar recompensas de indexação e servir queries para aquele lançamento de subgraph. O agente indexador cria alocações baseada nas regras do Indexador.
 
-- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+- **Fechada** - Um Indexador pode fechar uma alocação após a passagem de 1 epoch ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335), ou o seu agente indexador a fechará automaticamente após o **maxAllocationEpochs** (atualmente, 28 dias). Quando uma alocação é fechada com uma prova de indexação (POI) válida, as suas recompensas de indexação são distribuídas ao Indexador e aos seus Delegantes ([veja mais aqui](/indexing/overview/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+É ideal que os Indexadores utilizem a função de sincronização off-chain para sincronizar lançamentos de subgraph à chainhead antes de criar a alocação on-chain. Esta ferramenta é especialmente útil para subgraphs que demorem mais de 28 epochs para sincronizar, ou que têm chances de falhar não-deterministicamente.

From d41f99927f3d084a643f437392167860134669aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 21:17:39 -0500
Subject: [PATCH 3366/3820] New translations graph-node.mdx (Portuguese)

---
 .../pages/pt/indexing/tooling/graph-node.mdx  | 102 +++++++++---------
 1 file changed, 51 insertions(+), 51 deletions(-)

diff --git a/website/pages/pt/indexing/tooling/graph-node.mdx b/website/pages/pt/indexing/tooling/graph-node.mdx
index bac51d4c0ac8..4a1b6137a7d0 100644
--- a/website/pages/pt/indexing/tooling/graph-node.mdx
+++ b/website/pages/pt/indexing/tooling/graph-node.mdx
@@ -4,13 +4,13 @@ title: Graph Node
 
 O Node do The Graph (Graph Node) é o componente que indexa subgraphs e disponibiliza os dados resultantes a queries (consultas de dados) através de uma API GraphQL. Assim, ele é central ao stack dos indexers, e é crucial fazer operações corretas com um node Graph para executar um indexer com êxito.
 
-This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+Isto fornece um resumo contextual do Graph Node e algumas das opções mais avançadas disponíveis para indexadores. Para mais instruções e documentação, veja o [repositório do Graph Node](https://github.com/graphprotocol/graph-node).
 
 ## Graph Node
 
-[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+O [Graph Node](https://github.com/graphprotocol/graph-node) é a implementação de referência para indexar Subgraphs na The Graph Network (rede do The Graph); fazer conexões com clientes de blockchain; indexar subgraphs; e disponibilizar dados indexados para queries.
 
-Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+O Graph Node (e todo o stack dos indexadores) pode ser executado em um sistema bare-metal ou num ambiente na nuvem. Esta flexibilidade do componente central de indexing é importante para a robustez do Protocolo The Graph. Da mesma forma, um Graph Node pode ser [construído do código fonte](https://github.com/graphprotocol/graph-node) ou os indexadores podem usar uma das [imagens disponíveis no Docker](https://hub.docker.com/r/graphprotocol/graph-node).
 
 ### Banco de dados PostgreSQL
 
@@ -20,9 +20,9 @@ O armazenamento principal para o Graph Node. É aqui que são guardados dados de
 
 Para indexar uma rede, o Graph Node precisa de acesso a um cliente de rede através de uma API JSON-RPC compatível com EVM. Esta RPC (chamada de processamento remoto) pode se conectar a um único cliente de Ethereum; ou o setup pode ser mais complexo, de modo a carregar saldos em múltiplos clientes.
 
-While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+Enquanto alguns subgraphs exigem apenas um node completo, alguns podem ter recursos de indexação que precisem de funções adicionais de RPC (chamadas de procedimento remoto). Especificamente, subgraphs que usam o `eth_calls` como parte da indexação exigirão um node de arquivo que apoie o [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898); e subgraphs com `callHandlers`, ou `blockHandlers` com um filtro `call`, exigem apoio ao `trace_filter` (veja a documentação sobre o trace module (módulo de rastreio) [aqui](https://openethereum.github.io/JSONRPC-trace-module)).
 
-**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+**Firehoses de Rede** - um Firehose é um serviço de gRPC (chamadas de procedimento remoto - Google) que fornece uma transmissão ordenada — mas consciente de forks — de blocos, feito pelos programadores centrais do The Graph para permitir indexação em escala mais eficiente. Isto não é um requisito atual para Indexadores, mas é ideal que os mesmos experimentem a tecnologia, antes do apoio total à rede. Leia mais sobre o Firehose [aqui](https://firehose.streamingfast.io/).
 
 ### Nodes IPFS
 
@@ -42,7 +42,7 @@ O Graph Node pode, opcionalmente, logar métricas a um servidor de métricas Pro
 
 - **IPFS**
 
-- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+- **Requisitos Adicionais para utilizadores de Ubuntu** — A execução de um Graph Node no Ubuntu pode exigir pacotes adicionais.
 
 ```sh
 sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
@@ -58,7 +58,7 @@ pg_ctl -D .postgres -l logfile start
 createdb graph-node
 ```
 
-2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+2. Clone o repositório do [Graph Node](https://github.com/graphprotocol/graph-node) e execute `cargo build` para construir a fonte 
 
 3. Agora que todas as dependências estão prontas, inicie o Graph Node:
 
@@ -71,7 +71,7 @@ cargo run -p graph-node --release -- \
 
 ### Como começar com Kubernetes
 
-A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+Veja um exemplo completo de configuração do Kubernetes no [repositório do indexer](https://github.com/graphprotocol/indexer/tree/main/k8s).
 
 ### Os básicos do Kubernetes
 
@@ -85,42 +85,42 @@ Durante a execução, o Graph Node expõe as seguintes portas:
 | 8030  | API de status de indexamento do subgraph                | /graphql                                       | \--index-node-port | -                    |
 | 8040  | Métricas Prometheus                                     | /metrics                                       | \--metrics-port    | -                    |
 
-> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+> **Importante**: Cuidado ao expor portas publicamente — **portas de administração** devem ser trancadas a sete chaves. Isto inclui o endpoint JSON-RPC do Graph Node.
 
 ## Configurações avançadas do Graph Node
 
 Basicamente, o Graph Node pode ser operado com uma única instância de Graph Node, um único banco de dados PostgreSQP, e os clientes de rede como exigidos pelos subgraphs a serem indexados.
 
-This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+Este setup pode ser escalado horizontalmente, com a adição de vários Graph Nodes e bancos de dados para apoiá-los. Utilizadores mais avançados podem tomar vantagem de algumas das capacidades de escala horizontal do Graph Node, assim como algumas das opções de configuração mais avançadas, através do arquivo `config.toml` e as variáveis de ambiente do Graph Node.
 
 ### `config.toml`
 
-A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+Um arquivo de configuração [TOML](https://toml.io/en/) pode ser usado para fazer configurações mais complexas do que as expostas na CLI. O local do arquivo é passado com a linha de comando --config.
 
 > Ao usar um arquivo de configuração, não é possível usar as opções --postgres-url, --postgres-secondary-hosts, e --postgres-host-weights.
 
-A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+É possível fornecer um arquivo mínimo `config.toml`; o seguinte arquivo é o equivalente à opção de linha de comando --postgres-url:
 
 ```toml
 [store]
 [store.primary]
-connection="<.. postgres-url argument ..>"
+connection="<.. argumento postgres-url ..>"
 [deployment]
 [[deployment.rule]]
-indexers = [ "<.. list of all indexing nodes ..>" ]
+indexers = [ "<.. lista de todos os nodes de indexação ..>" ]
 ```
 
-Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+A documentação completa do `config.toml` pode ser encontrada nos [documentos do Graph Node](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
 
 #### Múltiplos Graph Nodes
 
-Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestion), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+A indexação de Graph Nodes pode ser escalada horizontalmente, com a execução de várias instâncias de Graph Node para separar indexação de queries em nodes diferentes. Isto é possível só com a execução de Graph Nodes, configurados com um `node_id` diferente na inicialização (por ex. no arquivo Docker Compose), que pode então ser usado no arquivo `config.toml` para especificar [nodes dedicados de query](#dedicated-query-nodes), [ingestores de blocos](#dedicated-block-ingestion") e separar subgraphs entre nódulos com [regras de lançamento](#deployment-rules).
 
 > Note que vários Graph Nodes podem ser configurados para usar o mesmo banco de dados — que, por conta própria, pode ser escalado horizontalmente através do sharding.
 
 #### Regras de lançamento
 
-Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+Levando em conta vários Graph Nodes, é necessário gerir o lançamento de novos subgraphs para que o mesmo subgraph não seja indexado por dois nodes diferentes, o que levaria a colisões. Isto é possível regras de lançamento, que também podem especificar em qual `shard` os dados de um subgraph devem ser armazenados, caso seja usado o sharding de bancos de dados. As regras de lançamento podem combinar com o nome do subgraph e com a rede que o lançamento indexa para fazer uma decisão.
 
 Exemplo de configuração de regra de lançamento:
 
@@ -150,7 +150,7 @@ indexers = [
   ]
 ```
 
-Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+Saiba mais sobre regras de lançamento [aqui](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
 
 #### Nodes dedicados de query
 
@@ -167,7 +167,7 @@ Qualquer node cujo --node-id combina com a expressão regular será programado p
 
 Para a maioria dos casos de uso, um único banco de dados Postgres é suficiente para apoiar uma instância de graph-node. Quando uma instância de graph-node cresce mais que um único banco Postgres, é possível dividir o armazenamento dos dados do graph-node entre múltiplos bancos Postgres. Todos os bancos de dados, juntos, formam o armazenamento da instância do graph-node. Cada banco de dados individual é chamado de shard.
 
-Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+Os shards servem para dividir lançamentos de subgraph em múltiplos bancos de dados, e podem também ser configurados para usar réplicas a fim de dividir a carga de query entre bancos de dados. Isto inclui a configuração do número de conexões disponíveis do banco que cada `graph-node` deve manter em seu pool de conexão para cada banco, o que fica cada vez mais importante conforme são indexados mais subgraphs.
 
 O sharding torna-se útil quando o seu banco de dados existente não aguenta o peso do Graph Node, e quando não é mais possível aumentar o tamanho do banco.
 
@@ -175,11 +175,11 @@ O sharding torna-se útil quando o seu banco de dados existente não aguenta o p
 
 Em termos de configuração de conexões, comece com o max_connections no postgresql.conf configurado em 400 (ou talvez até 200) e preste atenção nas métricas do Prometheus store_connection_wait_time_ms e store_connection_checkout_count. Tempos de espera óbvios (acima de 5ms) indicam que há poucas conexões disponíveis; também podem ser causados por atividade excessiva no banco de dados (como uso alto de CPU). Mas caso o banco de dados pareça estável fora isto, os tempos de espera longos indicam uma necessidade de aumento no número de conexões. Na configuração, há um limite máximo de conexões que cada instância graph-node pode usar, e o Graph Node não manterá conexões abertas caso não sejam necessárias.
 
-Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+Veja mais sobre configurações de armazenamento [aqui](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
 
 #### Ingestão dedicada de blocos
 
-If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+Caso hajam múltiplos nodes configurados, especifique um node a ser responsável pela ingestão de novos blocos, para que todos os nodes de indexação configurados não consultem o topo da cadeia. Isto é feito como parte do namespace `chains`, a especificar o `node_id` usado para ingestão de blocos:
 
 ```toml
 [chains]
@@ -188,13 +188,13 @@ ingestor = "block_ingestor_node"
 
 #### Apoio a múltiplas redes
 
-The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+O Graph Protocol só aumenta o número de redes, com apoio a recompensas de indexação, e existem muitos subgraphs a indexarem redes não apoiadas que um indexador gostaria de processar. O arquivo config.toml permite a configuração expressiva e flexível de:
 
 - Múltiplas redes
 - Múltiplos provedores por rede (isto pode permitir a separação de peso entre eles, e pode permitir a configuração de nodes completos além de nodes de arquivo; o Graph Node prefere provedores mais baratos, caso permita uma carga de trabalho).
 - Detalhes adicionais de provedor, como recursos, autenticação e tipo (para apoio experimental ao Firehose)
 
-The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+A seção `[chains]` controla os provedores de ethereum a que o graph-node se conecta, e o local de armazenamento de blocos e outros metadados para cada chain. O seguinte exemplo configura duas chains, mainnet e kovan, onde blocos para a mainnet são armazenados no shard vip e blocos para kovan vão para o shard primário. A chain da mainnet pode usar dois provedores diferentes, sendo que o kovan só tem um provedor.
 
 ```toml
 [chains]
@@ -210,18 +210,18 @@ shard = "primary"
 provider = [ { label = "kovan", url = "http://..", features = [] } ]
 ```
 
-Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+Veja mais sobre configurações de provedor [aqui](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
 
 ### Variáveis de ambiente
 
-Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+O Graph Node apoia vários variáveis de ambiente que podem ativar funções ou mudar o seu comportamento. Mais informações [aqui](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
 
 ### Lançamento contínuo
 
 Os utilizadores a operar um setup de indexing escalado, com configurações avançadas, podem ganhar mais ao gerir os seus Graph Nodes com o Kubernetes.
 
-- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
-- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+- O repositório do indexer tem um [exemplo de referência de Kubernetes](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- O [Launchpad](https://docs.graphops.xyz/launchpad/intro) é um conjunto kit de ferramentas para executar um Indexer do Graph Protocol no Kubernetes, mantido pelo GraphOps. Ele fornece um conjunto de charts Helm e uma CLI para administrar um lançamento de Graph Node.
 
 ### Como gerir o Graph Node
 
@@ -229,23 +229,23 @@ Dado um Graph Node (ou Nodes!) em execução, o desafio torna-se gerir subgraphs
 
 #### Logging
 
-Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+Os logs do Graph Node podem fornecer informações úteis, para debug e otimização — do Graph Node e de subgraphs específicos. O Graph Node apoia níveis diferentes de logs através da variável de ambiente `GRAPH_LOG`, com os seguintes níveis: `error`, `warn`, `info`, `debug` ou `trace`.
 
-In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+Além disto, configurar o `GRAPH_LOG_QUERY_TIMING` para `gql` fornece mais detalhes sobre o processo de queries no GraphQL (porém, isto criará um grande volume de logs).
 
-#### Monitoring & alerting
+#### Monitoração e alertas
 
 Naturalmente, o Graph Node fornece as métricas através do endpoint Prometheus na porta 8040. Estas métricas podem ser visualizadas no Grafana.
 
-The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+O repositório do indexer fornece um [exemplo de configuração do Grafana](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
 
 #### Graphman
 
-`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+O `graphman` é uma ferramenta de manutenção para o Graph Node, que ajuda com o diagnóstico e a resolução de tarefas diferentes, sejam excecionais ou no dia a dia.
 
-The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+O comando `graphman` é incluído nos containers oficiais, e pode ser executado com o docker `exec` no seu container de `graph-node`. Ele exige um arquivo `config.toml`.
 
-Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+A documentação completa dos comandos do `graphman` está no repositório do Graph Node. Veja o [/docs/graphman.md](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) no `/docs` do Graph Node
 
 ### Como trabalhar com subgraphs
 
@@ -253,7 +253,7 @@ Full documentation of `graphman` commands is available in the Graph Node reposit
 
 Inicialmente disponível na porta 8030/graphql, a API de estado de indexação expõe uma gama de métodos para conferir o estado da indexação para subgraphs diferentes, conferir provas de indexação, inspecionar características de subgraphs, e mais.
 
-The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+Veja o schema completo [aqui](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
 
 #### Desempenho da indexação
 
@@ -267,8 +267,8 @@ Estes estágios são segmentados (por ex., podem ser executados em paralelo), ma
 
 Causas comuns de lentidão na indexação:
 
-- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
-- Making large numbers of `eth_calls` as part of handlers
+- Tempo para encontrar eventos relevantes na chain (handlers de chamada em particular podem demorar mais, dada a dependência no `trace_filter`)
+- Fazer muitos `eth_calls` como parte de handlers
 - Excesso de interações no armazenamento durante a execução
 - Muitos dados para guardar no armazenamento
 - Muitos eventos a serem processados
@@ -287,19 +287,19 @@ As métricas de indexação de subgraph podem ajudar a diagnosticar a causa raiz
 
 Em alguns casos, uma falha pode ser resolvida pelo indexador (por ex. a indexação falhou por ter o tipo errado de provedor, e necessita do correto para continuar). Porém, em outros, é necessária uma alteração no código do subgraph.
 
-> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+> Falhas determinísticas são consideradas "finais", com uma Prova de Indexação (POI) gerada para o bloco falho; falhas não determinísticas não são finais, como há chances do subgraph superar a falha e continuar a indexar. Às vezes, o rótulo de "não determinístico" é incorreto e o subgraph não tem como melhorar do erro; estas falhas devem ser relatadas como problemas no repositório do Graph Node.
 
 #### Cache de blocos e chamadas
 
-Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+O Graph Node cacheia certos dados no armazenamento para poupar um refetching do provedor. São cacheados os blocos e os resultados do `eth_calls` (este último, cacheado a partir de um bloco específico). Este caching pode aumentar dramaticamente a velocidade de indexação durante a "ressincronização" de um subgraph levemente alterado.
 
-However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+Porém, em algumas instâncias, se um node Ethereum tiver fornecido dados incorretos em algum período, isto pode entrar no cache, o que causa dados incorretos ou subgraphs falhos. Neste caso, os indexadores podem usar o `graphman` para limpar o cache envenenado e rebobinar os subgraphs afetados, que retirarão dados frescos do provedor (idealmente) saudável.
 
 Caso haja uma suspeita de inconsistência no cache de blocos, como a falta de um evento <code>tx receipt missing</code>:
 
-1. `graphman chain list` to find the chain name.
-2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
-   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+1. Digite `graphman chain list` para buscar o nome da chain.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` verificará se o bloco no cache corresponde ao provedor; se não for o caso, o bloco será apagado do cache.
+   1. Se houver uma diferença, pode ser mais seguro truncar o cache inteiro com `graphman chain truncate <CHAIN>`.
    2. Caso o bloco corresponda ao provedor, então o problema pode ser debugado em frente ao provedor.
 
 #### Erros e problemas de query
@@ -312,7 +312,7 @@ Não há uma "bala de prata", mas sim uma gama de ferramentas para prevenir, dia
 
 ##### Caching de query
 
-Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+O Graph Node naturalmente cacheia queries no GraphQL, o que pode reduzir muito a carga no banco de dados. Isto pode ser configurado mais profundamente com `GRAPH_QUERY_CACHE_BLOCKS` e `GRAPH_QUERY_CACHE_MAX_MEM` — leia mais [aqui](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
 
 ##### Análise de queries
 
@@ -320,7 +320,7 @@ Queries problemáticos tendem a surgir em uma de duas maneiras. Em alguns casos,
 
 Em outros casos, o gatilho pode ser o excesso de uso de memória em um node de query; no caso, o primeiro desafio é identificar a consulta que causou este problema.
 
-Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+Os indexadores podem processar e resumir os logs de consulta do Graph Node com o comando [qlog](https://github.com/graphprotocol/qlog/). Ativar `GRAPH_LOG_QUERY_TIMING` também ajuda a identificar e debugar consultas lentas.
 
 Considerando um query lento, os indexadores têm algumas opções. Claro que podem alterar o seu modelo de custo, para aumentar o custo de enviar o query problemático. A frequência dessa query pode diminuir, mas isto não costuma resolver a raiz do problema.
 
@@ -328,18 +328,18 @@ Considerando um query lento, os indexadores têm algumas opções. Claro que pod
 
 Tábuas de base de dados que armazenam entidades geralmente vêm em duas variedades: 'tipo-transação', em que as entidades nunca são atualizadas depois da criação (por ex., armazenam algo como uma lista de transações financeiras); e 'tipo-conta', em que as entidades atualizam com frequência (ex.: armazenam algo como contas financeiras, que são modificadas sempre que uma transação é gravada). Tábuas tipo-contas são caracterizadas por ter muitas versões de entidade, mas poucas entidades distintas. O número de entidades distintas nessas tábuas costuma ser 1% do total de linhas (versões de entidade)
 
-For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+Para tábuas tipo-conta, o `graph-node` pode gerar consultas que aproveitam detalhes de como o Postgres armazena dados tão frequentemente alterados — em particular, que todas as versões para blocos recentes estão numa pequena subsecção do armazenamento total para uma tábua do tipo.
 
-The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+O comando `graphman stats show <sgdNNNN`> mostra, para cada tipo/tábua de entidade em um lançamento, quantas entidades distintas e versões de entidades estão em cada tábua. Esses dados são baseados em estimativas internas do Postgres e são necessariamente imprecisos, com uma grande margem de erro. Um `-1` na coluna `entities` significa que o Postgres acredita que todas as linhas contém uma entidade distinta.
 
-In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+Em geral, tábuas em que o número de entidades distintas é menos de 1% do total de linhas/versões de entidade são boas candidatas para a otimização tipo-conta. Quando o resultado do `graphman stats show` indica que uma tábua pode se beneficiar desta otimização, ativar o `graphman stats show <sgdNNN> <table>` fará uma contagem completa da tábua - que pode ser lenta, mas dá uma medida precisa da proporção entre entidades distintas e total de versões.
 
-Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+Quando uma tábua for determinada como "tipo-conta", executar o `graphman stats account-like <sgdNNN>.<table>` ativará a otimização tipo-conta para queries frente àquela tábua. A otimização pode ser desativada novamente com `graphman stats account-like --clear <sgdNNN>.<table>`. Os nodes de consulta levam até 5 minutos para perceber que a otimização foi ligada ou desligada. Após ativar a otimização, verifique se a mudança não desacelera os queries para aquela tábua. Caso tenha configurado o Grafana para monitorar o Postgres, muitos queries lentos podem aparecer no `pg_stat_activity`, com demora de vários segundos. Neste caso, a otimização precisa ser desativada novamente.
 
-For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+Para subgraphs parecidos com o Uniswap, as tábuas `pair` e `token` são ótimas para esta otimização, e podem ter efeitos surpreendentes na carga do banco de dados.
 
 #### Como remover subgraphs
 
 > Esta é uma funcionalidade nova, que estará disponível no Graph Node 0.29.x
 
-At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).
+Em certo ponto, o indexador pode querer remover um subgraph. É só usar o `graphman drop`, que apaga um lançamento e todos os seus dados indexados. O lançamento pode ser especificado como o nome de um subgraph, um hash IPFS `Qm..`, ou o namespace de banco de dados `sgdNNN`. Mais documentos sobre o processo [aqui](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).

From be966dd0d8f6d9ac763cdfbad339298026d7db0b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 21:17:40 -0500
Subject: [PATCH 3367/3820] New translations chain-integration-overview.mdx
 (Portuguese)

---
 website/pages/pt/indexing/chain-integration-overview.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/indexing/chain-integration-overview.mdx b/website/pages/pt/indexing/chain-integration-overview.mdx
index 21b1b2d99b14..ba7e92f6032b 100644
--- a/website/pages/pt/indexing/chain-integration-overview.mdx
+++ b/website/pages/pt/indexing/chain-integration-overview.mdx
@@ -6,7 +6,7 @@ Um processo de integração transparente e baseado em governança foi desenhado
 
 ## Fase 1. Integração Técnica
 
-- Please visit [New Chain Integration](/indexing/new-chain-integration/) for information on `graph-node` support for new chains.
+- Por favor, visite a página de [Integração de Novas Chains](/indexing/new-chain-integration/) para informações sobre o apoio do `graph-node` para chains novas.
 - Equipas iniciam o processo de integração de protocolo com a criação de um tópico de Fórum [aqui](https://forum.thegraph.com/c/governance-gips/new-chain-support/71) (Nova subcategoria de Fontes de Dados sob Governança e GIPs). O uso do modelo padrão do Fórum é obrigatório.
 
 ## Fase 2. Validação de Integração

From 48ea5112a3b3c5f7d7480283827acdb06e0fb422 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 21:17:41 -0500
Subject: [PATCH 3368/3820] New translations new-chain-integration.mdx
 (Portuguese)

---
 website/pages/pt/indexing/new-chain-integration.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/pt/indexing/new-chain-integration.mdx b/website/pages/pt/indexing/new-chain-integration.mdx
index 1c4ecd22c293..f988d296e3f1 100644
--- a/website/pages/pt/indexing/new-chain-integration.mdx
+++ b/website/pages/pt/indexing/new-chain-integration.mdx
@@ -25,7 +25,7 @@ Para que o Graph Node possa ingerir dados de uma chain EVM, o node RPC deve expo
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, em um pedido conjunto em JSON-RPC
-- `trace_filter` _(limited tracing and optionally required for Graph Node)_
+- `trace_filter` _(tracing limitado, e opcionalmente necessário, para o Graph Node)_
 
 ### 2. Integração do Firehose
 
@@ -33,11 +33,11 @@ O [Firehose](https://firehose.streamingfast.io/firehose-setup/overview) é uma c
 
 > NOTA: Todas as integrações feitas pela equipa da StreamingFast incluem manutenção para o protocolo de réplica do Firehose no banco de código da chain. O StreamingFast rastreia todas as mudanças e lança binários quando o código é mudado, pelo programador ou pela StreamingFast. Isto inclui o lançamento de binários do Firehose/Substreams para o protocolo, a manutenção dos módulos de Substreams para o modelo de bloco da chain, e o lançamento de binários para o node da blockchain com a instrumentação, caso necessária.
 
-#### Integration for Non-EVM chains
+#### Integração para Chains sem ser EVM (Máquina Virtual de Ethereum)
 
 O método principal de integrar o Firehose a chains é uma estratégia de polling de RPC. O nosso algoritmo de polling preverá quando um bloco novo irá chegar, e aumentará o ritmo em que ele verifica por um novo bloco quando se aproximar daquela hora, o que o faz uma solução de baixa latência muito eficiente. Para ajuda com a integração e a manutenção do Firehose, contacte a [equipa do StreamingFast](https://www.streamingfast.io/firehose-integration-program). Novas chains e os seus integrantes apreciarão a [consciência de fork](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) e as capacidades imensas de indexação paralelizada que o Firehose e os Substreams trazem ao seu ecossistema.
 
-#### Specific Instrumentation for EVM (`geth`) chains
+#### Instrumentação Específica do Firehose para chains EVM (`geth`)
 
 Para chains EVM, há um nível mais profundo de dados que podem ser alcançados através do [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0) `geth`, uma colaboração entre a Go-Ethereum e a StreamingFast, na construção de um sistema de traços rico e de alto throughput. O Live Tracer é a solução mais compreensiva, o que resulta em detalhes de blocos [Estendidos](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425). Isto permite novos paradigmas de indexação, como correspondência de padrões de eventos com base em mudanças no estado, chamadas, árvores de chamadas de parentes, ou o acionamento de eventos com base nas mudanças nas próprias variáveis em um contrato inteligente.
 
@@ -47,7 +47,7 @@ Para chains EVM, há um nível mais profundo de dados que podem ser alcançados
 
 ## Considerações de EVM - Diferença entre JSON-RPC e Firehose
 
-While the JSON-RPC and Firehose are both suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](https://substreams.streamingfast.io). Supporting Substreams allows developers to build [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/) for the new chain, and has the potential to improve the performance of your subgraphs. Additionally, Firehose — as a drop-in replacement for the JSON-RPC extraction layer of `graph-node` — reduces by 90% the number of RPC calls required for general indexing.
+Enquanto ambos o JSON-RPC e o Firehose são próprios para subgraphs, um Firehose é sempre necessário para programadores que querem construir com [Substreams](https://substreams.streamingfast.io). Apoiar o Substreams permite que programadores construam [subgraphs movidos a Substreams](/subgraphs/cookbook/substreams-powered-subgraphs/) para a nova chain, e tem o potencial de melhorar o desempenho dos seus subgraphs. Além disto, o Firehose — como um substituto pronto para a camada de extração JSON-RPC do `graph-node` — reduz em 90% o número de RPCs (chamadas de procedimento remoto) exigidas para indexação geral.
 
 - Todas essas chamadas `getLogs` e roundtrips são substituídas por um único fluxo que chega no coração do `graph-node`, um modelo de bloco único para todos os subgraphs que processa.
 
@@ -59,7 +59,7 @@ Configurar um Graph Node é tão fácil quanto preparar o seu ambiente local. Qu
 
 1. [Clone o Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
+2. Modifique [esta linha](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) para incluir o nome da nova rede e a URL do JSON-RPC da EVM; ou uma compatível com o Firehose
 
    > Não mude o nome do env var. Ele deve permanecer como `ethereum` mesmo se o nome da rede for diferente.
 
@@ -67,4 +67,4 @@ Configurar um Graph Node é tão fácil quanto preparar o seu ambiente local. Qu
 
 ## Subgraphs movidos por Substreams
 
-For StreamingFast-led Firehose/Substreams integrations, basic support for foundational Substreams modules (e.g. decoded transactions, logs and smart-contract events) and Substreams codegen tools are included. These tools enable the ability to enable [Substreams-powered subgraphs](/substreams/sps/introduction/). Follow the [How-To Guide](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) and run `substreams codegen subgraph` to experience the codegen tools for yourself.
+Para integrações do Substreams ou Firehose movidas ao StreamingFast, são inclusos: apoio básico a módulos do Substreams (por exemplo: transações, logs, e eventos de contrato inteligente decodificados); e ferramentas de geração de código do Substreams. Estas ferramentas permitem a habilidade de ativar [subgraphs movidos pelo Substreams](/substreams/sps/introduction/). Siga o [Passo-a-Passo](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) e execute `substreams codegen subgraph` para sentir um gostinho das ferramentas.

From 8706200055db8e2c8b5699c9ad370252325c99c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 29 Jan 2025 21:17:42 -0500
Subject: [PATCH 3369/3820] New translations firehose.mdx (Portuguese)

---
 website/pages/pt/indexing/tooling/firehose.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/pt/indexing/tooling/firehose.mdx b/website/pages/pt/indexing/tooling/firehose.mdx
index 4ab94a3ff649..3b2cd8bd07c5 100644
--- a/website/pages/pt/indexing/tooling/firehose.mdx
+++ b/website/pages/pt/indexing/tooling/firehose.mdx
@@ -2,23 +2,23 @@
 title: Firehose
 ---
 
-![Firehose Logo](/img/firehose-logo.png)
+![Logo do Firehose](/img/firehose-logo.png)
 
-Firehose is a new technology developed by StreamingFast working with The Graph Foundation. The product provides **previously unseen capabilities and speeds for indexing blockchain data** using a files-based and streaming-first approach.
+O Firehose é uma nova tecnologia desenvolvida pelo StreamingFast em colaboração com a Graph Foundation. O produto providencia **capacidades e velocidades sem precedentes de indexação de dados em blockchain** com um processo baseado em arquivos e focado no streaming em primeiro lugar.
 
-The Graph merges into Go Ethereum/geth with the adoption of [Live Tracer with v1.14.0 release](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
+O The Graph se junta ao Go Ethereum/geth com a adoção do [Live Tracer com a versão 1.14.0](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0).
 
 O Firehose extrai, transforma e salva dados de blockchain em uma estratégia baseada em arquivos e de alto desempenho. Os programadores de blockchain podem então acessar dados extraídos pelo Firehose através de streams de dados binários. A intenção do Firehose é substituir a camada original de extração de dados de blockchain do The Graph.
 
 ## Documentação do Firehose
 
-The Firehose documentation is currently maintained by the StreamingFast team [on the StreamingFast website](https://firehose.streamingfast.io/).
+A documentação do Firehose é atualmente mantida pela equipa do StreamingFast no seu [site oficial](https://firehose.streamingfast.io/).
 
 ### Como Começar
 
-- Read this [Firehose introduction](https://firehose.streamingfast.io/introduction/firehose-overview) to get an overview of what it is and why it was built.
-- Learn about the [Prerequisites](https://firehose.streamingfast.io/introduction/prerequisites) to install and deploy Firehose.
+- Leia esta [introdução ao Firehose](https://firehose.streamingfast.io/introduction/firehose-overview) para saber o que ele é e por que foi construído.
+- Veja os [Prerrequisitos](https://firehose.streamingfast.io/introduction/prerequisites) para a instalação e execução do Firehose.
 
 ### Expanda o Seu Conhecimento
 
-- Learn about the different [Firehose components](https://firehose.streamingfast.io/architecture/components) available.
+- Aprenda sobre os vários componentes disponíveis do Firehose [aqui](https://firehose.streamingfast.io/architecture/components).

From 0f80d7a8766ca13ff9d505fea161ccb3358964be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 30 Jan 2025 02:12:38 -0500
Subject: [PATCH 3370/3820] New translations tap.mdx (German)

---
 website/pages/de/indexing/tap.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/indexing/tap.mdx b/website/pages/de/indexing/tap.mdx
index 7044da441b95..c6c6c5e5c4f0 100644
--- a/website/pages/de/indexing/tap.mdx
+++ b/website/pages/de/indexing/tap.mdx
@@ -1,5 +1,5 @@
 ---
-title: TAP Migration Guide
+title: TAP-Migrationsleitfaden
 ---
 
 Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.

From 77c7dcb946a0b192a4c50cd6ebebad480612a229 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 30 Jan 2025 03:41:20 -0500
Subject: [PATCH 3371/3820] New translations tap.mdx (German)

---
 website/pages/de/indexing/tap.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/de/indexing/tap.mdx b/website/pages/de/indexing/tap.mdx
index c6c6c5e5c4f0..d2a42296066a 100644
--- a/website/pages/de/indexing/tap.mdx
+++ b/website/pages/de/indexing/tap.mdx
@@ -2,16 +2,16 @@
 title: TAP-Migrationsleitfaden
 ---
 
-Learn about The Graph’s new payment system, **Timeline Aggregation Protocol, TAP**. This system provides fast, efficient microtransactions with minimized trust.
+Erfahren Sie mehr über das neue Zahlungssystem von The Graph, **Timeline Aggregation Protocol, TAP**. Dieses System bietet schnelle, effiziente Mikrotransaktionen mit minimiertem Vertrauen.
 
 ## Überblick
 
-[TAP](https://docs.rs/tap_core/latest/tap_core/index.html) is a drop-in replacement to the Scalar payment system currently in place. It provides the following key features:
+[TAP] (https://docs.rs/tap_core/latest/tap_core/index.html) ist ein direkter Ersatz für das derzeitige Scalar-Zahlungssystem. Es bietet die folgenden Hauptfunktionen:
 
-- Efficiently handles micropayments.
-- Adds a layer of consolidations to onchain transactions and costs.
-- Allows Indexers control of receipts and payments, guaranteeing payment for queries.
-- It enables decentralized, trustless gateways and improves `indexer-service` performance for multiple senders.
+- Effiziente Abwicklung von Mikrozahlungen.
+- Fügt den Onchain-Transaktionen und -Kosten eine weitere Ebene der Konsolidierung hinzu.
+- Ermöglicht den Indexern die Kontrolle über Eingänge und Zahlungen und garantiert die Bezahlung von Abfragen.
+- Es ermöglicht dezentralisierte, vertrauenslose Gateways und verbessert die Leistung des `indexer-service` für mehrere Absender.
 
 ## Besonderheiten
 

From 143d5d382d8a8b777434e656b2b699f8deb1e21a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 30 Jan 2025 06:32:44 -0500
Subject: [PATCH 3372/3820] New translations tap.mdx (German)

---
 website/pages/de/indexing/tap.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/de/indexing/tap.mdx b/website/pages/de/indexing/tap.mdx
index d2a42296066a..3f6e47de8e6e 100644
--- a/website/pages/de/indexing/tap.mdx
+++ b/website/pages/de/indexing/tap.mdx
@@ -15,15 +15,15 @@ Erfahren Sie mehr über das neue Zahlungssystem von The Graph, **Timeline Aggreg
 
 ## Besonderheiten
 
-TAP allows a sender to make multiple payments to a receiver, **TAP Receipts**, which aggregates these payments into a single payment, a **Receipt Aggregate Voucher**, also known as a **RAV**. This aggregated payment can then be verified on the blockchain, reducing the number of transactions and simplifying the payment process.
+TAP ermöglicht es einem Sender, mehrere Zahlungen an einen Empfänger zu leisten, **TAP Receipts**, der diese Zahlungen zu einer einzigen Zahlung zusammenfasst, einem **Receipt Aggregate Voucher**, auch bekannt als **RAV**. Diese aggregierte Zahlung kann dann auf der Blockchain verifiziert werden, wodurch sich die Anzahl der Transaktionen verringert und der Zahlungsvorgang vereinfacht wird.
 
-For each query, the gateway will send you a `signed receipt` that is stored on your database. Then, these queries will be aggregated by a `tap-agent` through a request. Afterwards, you’ll receive a RAV. You can update a RAV by sending it with newer receipts and this will generate a new RAV with an increased value.
+Für jede Abfrage sendet Ihnen das Gateway eine „signierte Quittung“, die in Ihrer Datenbank gespeichert wird. Dann werden diese Abfragen von einem „Tap-Agent“ durch eine Anfrage aggregiert. Anschließend erhalten Sie ein RAV. Sie können ein RAV aktualisieren, indem Sie es mit neueren Quittungen senden, wodurch ein neues RAV mit einem höheren Wert erzeugt wird.
 
 ### RAV Details
 
-- It’s money that is waiting to be sent to the blockchain.
+- Es ist Geld, das darauf wartet, an die Blockchain gesendet zu werden.
 
-- It will continue to send requests to aggregate and ensure that the total value of non-aggregated receipts does not exceed the `amount willing to lose`.
+- Es werden weiterhin Anträge auf Zusammenlegung stellen und sicherstellen, dass der Gesamtwert der nicht zusammengefassten Einnahmen `amount willing to lose` (den „Betrag, den man zu verlieren bereit ist“), nicht übersteigt.
 
 - Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
 

From 030eee0739d84d301ba138c64f9f75e252ca6cfe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 30 Jan 2025 07:55:02 -0500
Subject: [PATCH 3373/3820] New translations tap.mdx (German)

---
 website/pages/de/indexing/tap.mdx | 102 +++++++++++++++---------------
 1 file changed, 51 insertions(+), 51 deletions(-)

diff --git a/website/pages/de/indexing/tap.mdx b/website/pages/de/indexing/tap.mdx
index 3f6e47de8e6e..c73570315b39 100644
--- a/website/pages/de/indexing/tap.mdx
+++ b/website/pages/de/indexing/tap.mdx
@@ -19,84 +19,84 @@ TAP ermöglicht es einem Sender, mehrere Zahlungen an einen Empfänger zu leiste
 
 Für jede Abfrage sendet Ihnen das Gateway eine „signierte Quittung“, die in Ihrer Datenbank gespeichert wird. Dann werden diese Abfragen von einem „Tap-Agent“ durch eine Anfrage aggregiert. Anschließend erhalten Sie ein RAV. Sie können ein RAV aktualisieren, indem Sie es mit neueren Quittungen senden, wodurch ein neues RAV mit einem höheren Wert erzeugt wird.
 
-### RAV Details
+### RAV-Details
 
 - Es ist Geld, das darauf wartet, an die Blockchain gesendet zu werden.
 
 - Es werden weiterhin Anträge auf Zusammenlegung stellen und sicherstellen, dass der Gesamtwert der nicht zusammengefassten Einnahmen `amount willing to lose` (den „Betrag, den man zu verlieren bereit ist“), nicht übersteigt.
 
-- Each RAV can be redeemed once in the contracts, which is why they are sent after the allocation is closed.
+- Jedes RAV kann einmal in den Verträgen eingelöst werden, weshalb sie nach Abschluss der Zuteilung versandt werden.
 
-### Redeeming RAV
+### Einlösen des RAV
 
-As long as you run `tap-agent` and `indexer-agent`, everything will be executed automatically. The following provides a detailed breakdown of the process:
+Solange Sie `tap-agent` und `indexer-agent` ausführen, wird alles automatisch ausgeführt. Im Folgenden finden Sie eine detaillierte Aufschlüsselung des Prozesses:
 
-1. An Indexer closes allocation.
+1. Ein Indexer schließt die Zuteilung ab.
 
-2. `<recently-closed-allocation-buffer> period, tap-agent` takes all pending receipts for that specific allocation and requests an aggregation into a RAV, marking it as `last`.
+2. `<recently-closed-allocation-buffer> period, tap-agent` nimmt alle ausstehenden Quittungen für diese spezifische Zuteilung und fordert eine Aggregation in einem RAV an, wobei es als `last` gekennzeichnet wird.
 
-3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
+3. `indexer-agent` nimmt alle letzten RAVS und sendet Einlöseanforderungen an die Blockchain, die den Wert von ‚redeem_at‘ aktualisiert.
 
-4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
+4. Während der `<finality-time>`-Periode überwacht der `indexer-agent`, ob es in der Blockchain irgendwelche Reorganisationen gibt, die die Transaktion rückgängig machen.
 
-   - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
+   - Wurde es rückgängig gemacht, wird das RAV erneut an die Blockchain gesendet. Wenn es nicht rückgängig gemacht wurde, wird es als `final` markiert.
 
-## Blockchain Addresses
+## Blockchain-Adressen
 
-### Contracts
+### Verträge
 
-| Contract            | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
-| ------------------- | -------------------------------------------- | -------------------------------------------- |
-| TAP Verifier        | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
-| AllocationIDTracker | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
-| Escrow              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
+| Vertrag                    | Arbitrum Mainnet (42161)                     | Arbitrum Sepolia (421614)                    |
+| -------------------------- | -------------------------------------------- | -------------------------------------------- |
+| TAP-Prüfer                 | `0x33f9E93266ce0E108fc85DdE2f71dab555A0F05a` | `0xfC24cE7a4428A6B89B52645243662A02BA734ECF` |
+| AllocationIDTracker        | `0x5B2F33d7Ca6Ec88f5586f2528f58c20843D9FE7c` | `0xAaC28a10d707bbc6e02029f1bfDAEB5084b2aD11` |
+| Treuhandkonto              | `0x8f477709eF277d4A880801D01A140a9CF88bA0d3` | `0x1e4dC4f9F95E102635D8F7ED71c5CdbFa20e2d02` |
 
 ### Gateway
 
-| Component  | Edge and Node Mainnet (Arbitrum Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
-| ---------- | --------------------------------------------- | --------------------------------------------- |
-| Sender     | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`  | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
-| Signers    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`  | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
-| Aggregator | `https://tap-aggregator.network.thegraph.com` | `https://tap-aggregator.testnet.thegraph.com` |
+| Komponente       | Edge- und Node-Mainnet (Arbitrum-Mainnet)      | Edge and Node Testnet (Arbitrum Sepolia)      |
+| ---------------- | ---------------------------------------------- | --------------------------------------------- |
+| Sender           | `0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467`   | `0xC3dDf37906724732FfD748057FEBe23379b0710D`  |
+| Unterzeichner    | `0xfF4B7A5EfD00Ff2EC3518D4F250A27e4c29A2211`   | `0xFb142dE83E261e43a81e9ACEADd1c66A0DB121FE`  |
+| Aggregator       | `https://tap-aggregator.network.thegraph.com`  | `https://tap-aggregator.testnet.thegraph.com` |
 
-### Requirements
+### Anforderungen
 
-In addition to the typical requirements to run an indexer, you’ll need a `tap-escrow-subgraph` endpoint to query TAP updates. You can use The Graph Network to query or host yourself on your `graph-node`.
+Zusätzlich zu den typischen Anforderungen für den Betrieb eines Indexers benötigen Sie einen `tap-escrow-subgraph`-Endpunkt, um TAP-Aktualisierungen abzufragen. Sie können The Graph Network zur Abfrage verwenden oder sich selbst auf Ihrem `graph-node` hosten.
 
-- [Graph TAP Arbitrum Sepolia subgraph (for The Graph testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
-- [Graph TAP Arbitrum One subgraph (for The Graph mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
+- [Graph TAP Arbitrum Sepolia subgraph (für The Graph Testnet)](https://thegraph.com/explorer/subgraphs/7ubx365MiqBH5iUz6XWXWT8PTof5BVAyEzdb8m17RvbD)
+- [Graph TAP Arbitrum One subgraph (für The Graph Mainnet)](https://thegraph.com/explorer/subgraphs/4sukbNVTzGELnhdnpyPqsf1QqtzNHEYKKmJkgaT8z6M1)
 
-> Note: `indexer-agent` does not currently handle the indexing of this subgraph like it does for the network subgraph deployment. As a result, you have to index it manually.
+> Hinweis: `indexer-agent` übernimmt derzeit nicht die Indizierung dieses Subgraphen, wie es bei der Bereitstellung von Netzwerk-Subgraphen der Fall ist. Daher müssen Sie ihn manuell indizieren.
 
-## Migration Guide
+## Migrationsleitfaden
 
-### Software versions
+### Software-Versionen
 
-The required software version can be found [here](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
+Die erforderliche Softwareversion finden Sie [hier](https://github.com/graphprotocol/indexer/blob/main/docs/networks/arbitrum-one.md#latest-releases).
 
-### Steps
+### Schritte
 
-1. **Indexer Agent**
+1. **Indexer-Agent**
 
-   - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
-   - Give the new argument `--tap-subgraph-endpoint` to activate the new TAP codepaths and enable redeeming of TAP RAVs.
+   - Folgen Sie dem [gleichen Prozess](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
+   - Geben Sie das neue Argument `--tap-subgraph-endpoint` an, um die neuen TAP-Codepfade zu aktivieren und die Einlösung von TAP-RAVs zu ermöglichen.
 
-2. **Indexer Service**
+2. **Indexer-Service**
 
-   - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
-   - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
+   - Ersetzen Sie Ihre aktuelle Konfiguration vollständig durch den [neuen Indexer-Service rs](https://github.com/graphprotocol/indexer-rs). Es wird empfohlen, dass Sie das [Containerbild](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs) verwenden.
+   - Wie bei der älteren Version können Sie den Indexer-Service problemlos horizontal skalieren. Er ist immer noch zustandslos.
 
 3. **TAP Agent**
 
-   - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
+   - Führen Sie immer _eine_ einzelne Instanz von [TAP Agent](https://github.com/graphprotocol/indexer-rs) aus. Es wird empfohlen, dass Sie das [Container-Image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs) verwenden.
 
-4. **Configure Indexer Service and TAP Agent**
+4. **Indexer-Service und TAP-Agent konfigurieren**
 
-   Configuration is a TOML file shared between `indexer-service` and `tap-agent`, supplied with the argument `--config /path/to/config.toml`.
+   Die Konfiguration ist eine TOML-Datei, die von `indexer-service` und `tap-agent` gemeinsam genutzt wird und mit dem Argument `--config /path/to/config.toml` übergeben wird.
 
-   Check out the full [configuration](https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) and the [default values](https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml)
+   Sehen Sie sich die vollständige [Konfiguration] (https://github.com/graphprotocol/indexer-rs/blob/main/config/maximal-config-example.toml) und die [Standardwerte] (https://github.com/graphprotocol/indexer-rs/blob/main/config/default_values.toml) an.
 
-For minimal configuration, use the following template:
+Für eine minimale Konfiguration verwenden Sie die folgende Vorlage:
 
 ```bash
 # You will have to change *all* the values below to match your setup.
@@ -168,26 +168,26 @@ max_amount_willing_to_lose_grt = 20
 0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
 ```
 
-Notes:
+Anmerkungen:
 
-- Values for `tap.sender_aggregator_endpoints` can be found in the [gateway section](/indexing/tap/#gateway).
-- Values for `blockchain.receipts_verifier_address` must be used accordingly to the [Blockchain addresses section](/indexing/tap/#contracts) using the appropriate chain id.
+- Die Werte für `tap.sender_aggregator_endpoints` finden Sie im Abschnitt [gateway](/indexing/tap/#gateway).
+- Die Werte für `blockchain.receipts_verifier_address` müssen entsprechend dem Abschnitt [Blockchain-Adressen] (/indexing/tap/#contracts) unter Verwendung der entsprechenden Ketten-ID verwendet werden.
 
 **Log Level**
 
-- You can set the log level by using the `RUST_LOG` environment variable.
-- It’s recommended that you set it to `RUST_LOG=indexer_tap_agent=debug,info`.
+- Sie können die Protokollstufe mit der Umgebungsvariablen `RUST_LOG` einstellen.
+- Es wird empfohlen, die Einstellung `RUST_LOG=indexer_tap_agent=debug,info` zu verwenden.
 
 ## Monitoring
 
-### Metrics
+### Metriken
 
-All components expose the port 7300 to be queried by prometheus.
+Alle Komponenten stellen den Port 7300 zur Abfrage durch prometheus zur Verfügung.
 
-### Grafana Dashboard
+### Grafana-Dashboard
 
-You can download [Grafana Dashboard](https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) and import.
+Sie können [Grafana-Dashboard] (https://github.com/graphprotocol/indexer-rs/blob/main/docs/dashboard.json) herunterladen und importieren.
 
 ### Launchpad
 
-Currently, there is a WIP version of `indexer-rs` and `tap-agent` that can be found [here](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer)
+Derzeit gibt es eine WIP-Version von `indexer-rs` und `tap-agent`, die [hier](https://github.com/graphops/launchpad-charts/tree/main/charts/graph-network-indexer) zu finden ist.

From 5e68fba2dd7aebe1c8ccceaf147cbb5adb6e5742 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 30 Jan 2025 11:54:27 -0500
Subject: [PATCH 3374/3820] New translations glossary.mdx (Chinese Simplified)

---
 website/pages/zh/resources/glossary.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/resources/glossary.mdx b/website/pages/zh/resources/glossary.mdx
index 271ecb32734e..98e473e0a8ae 100644
--- a/website/pages/zh/resources/glossary.mdx
+++ b/website/pages/zh/resources/glossary.mdx
@@ -80,4 +80,4 @@ title: 术语汇编
 
 - **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
 
-- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).
+- **Migrating**: 策展份额从子图的旧版本移动到子图的新版本的过程（例如，从 v0.0.1 更新到 v0.0.2）。

From dcdd7c6503772dc772fd68c0e3a74a90be077c46 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 30 Jan 2025 11:54:29 -0500
Subject: [PATCH 3375/3820] New translations assemblyscript-migration-guide.mdx
 (German)

---
 .../release-notes/assemblyscript-migration-guide.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
index 20063f593224..c3c0e884817a 100644
--- a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -2,21 +2,21 @@
 title: AssemblyScript Migration Guide
 ---
 
-Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+Bis jetzt haben Subgraphen eine der [ersten Versionen von AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6) verwendet. Endlich haben wir Unterstützung für die [neueste verfügbare Version](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10) hinzugefügt! 🎉
 
 That will enable subgraph developers to use newer features of the AS language and standard library.
 
-This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+Diese Anleitung gilt für alle, die `graph-cli`/`graph-ts` unter Version `0.22.0` verwenden. Wenn Sie bereits eine höhere (oder gleiche) Version als diese haben, haben Sie bereits Version `0.19.10` von AssemblyScript verwendet 🙂
 
-> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+> Anmerkung: Ab `0.24.0` kann `graph-node` beide Versionen unterstützen, abhängig von der im Subgraph-Manifest angegebenen `apiVersion`.
 
 ## Features
 
 ### New functionality
 
-- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
-- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- `TypedArray` kann nun aus `ArrayBuffer` mit Hilfe der [neuen statischen Methode `wrap`](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1)) erstellt werden
+- Neue Standard-Bibliotheksfunktionen: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`und `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Unterstützung für x instanceof GenericClass hinzugefügt ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
 - Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
 - Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
 - Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))

From 8ff00ceb8450238ae767b8eb96edcee4798e7e9e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 30 Jan 2025 14:01:06 -0500
Subject: [PATCH 3376/3820] New translations graph-node.mdx (German)

---
 website/pages/de/indexing/tooling/graph-node.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/indexing/tooling/graph-node.mdx b/website/pages/de/indexing/tooling/graph-node.mdx
index 24cae95c9a9b..dffe5a138af4 100644
--- a/website/pages/de/indexing/tooling/graph-node.mdx
+++ b/website/pages/de/indexing/tooling/graph-node.mdx
@@ -175,7 +175,7 @@ Sharding wird nützlich, wenn Ihre vorhandene Datenbank nicht mit der Last Schri
 
 Was das Konfigurieren von Verbindungen betrifft, beginnen Sie mit max_connections in postgresql.conf, das auf 400 (oder vielleicht sogar 200) eingestellt ist, und sehen Sie sich die Prometheus-Metriken store_connection_wait_time_ms und store_connection_checkout_count an. Spürbare Wartezeiten (alles über 5 ms) sind ein Hinweis darauf, dass zu wenige Verbindungen verfügbar sind; hohe Wartezeiten werden auch dadurch verursacht, dass die Datenbank sehr ausgelastet ist (z. B. hohe CPU-Last). Wenn die Datenbank jedoch ansonsten stabil erscheint, weisen hohe Wartezeiten darauf hin, dass die Anzahl der Verbindungen erhöht werden muss. In der Konfiguration ist die Anzahl der Verbindungen, die jede Graph-Knoten-Instanz verwenden kann, eine Obergrenze, und der Graph-Knoten hält Verbindungen nicht offen, wenn er sie nicht benötigt.
 
-Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+Lesen Sie mehr über Lesen Sie [hier] mehr über die Store-Konfiguration [hier] (https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
 
 #### Dedizierte Blockaufnahme
 

From 3a1f6b3e2fc6855e7667ec9c2c08fe4efa6250a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 07:11:22 -0500
Subject: [PATCH 3377/3820] New translations graph-node.mdx (German)

---
 website/pages/de/indexing/tooling/graph-node.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/indexing/tooling/graph-node.mdx b/website/pages/de/indexing/tooling/graph-node.mdx
index dffe5a138af4..1df0dc9b943a 100644
--- a/website/pages/de/indexing/tooling/graph-node.mdx
+++ b/website/pages/de/indexing/tooling/graph-node.mdx
@@ -179,7 +179,7 @@ Lesen Sie mehr über Lesen Sie [hier] mehr über die Store-Konfiguration [hier]
 
 #### Dedizierte Blockaufnahme
 
-If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+Wenn mehrere Knoten konfiguriert sind, muss ein Knoten angegeben werden, der für die Aufnahme neuer Blöcke verantwortlich ist, damit nicht alle konfigurierten Indexer-Knoten den Kettenkopf abfragen. Dies geschieht als Teil des `chains`-Namensraumes, indem die `node_id` angegeben wird, die für die Aufnahme von Blöcken verwendet werden soll:
 
 ```toml
 [chains]
@@ -188,7 +188,7 @@ ingestor = "block_ingestor_node"
 
 #### Unterstützung mehrerer Netzwerke
 
-The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+Das Graph-Protokoll erhöht die Anzahl der Netzwerke, die für die Indizierung von Belohnungen unterstützt werden, und es gibt viele Subgraphen, die nicht unterstützte Netzwerke indizieren, die ein Indexer verarbeiten möchte. Die Datei `config.toml` ermöglicht eine ausdrucksstarke und flexible Konfiguration von:
 
 - Mehrere Netzwerke
 - Mehrere Anbieter pro Netzwerk (dies kann eine Aufteilung der Last auf Anbieter ermöglichen und kann auch die Konfiguration von vollständigen Knoten sowie Archivknoten ermöglichen, wobei Graph Node günstigere Anbieter bevorzugt, wenn eine bestimmte Arbeitslast dies zulässt).

From 8e5585d65ac84abb7413d3d3c8c34f8e21149d38 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 07:11:23 -0500
Subject: [PATCH 3378/3820] New translations assemblyscript-migration-guide.mdx
 (German)

---
 .../assemblyscript-migration-guide.mdx        | 96 +++++++++----------
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
index c3c0e884817a..3593edab965c 100644
--- a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -17,34 +17,34 @@ Diese Anleitung gilt für alle, die `graph-cli`/`graph-ts` unter Version `0.22.0
 - `TypedArray` kann nun aus `ArrayBuffer` mit Hilfe der [neuen statischen Methode `wrap`](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1)) erstellt werden
 - Neue Standard-Bibliotheksfunktionen: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`und `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
 - Unterstützung für x instanceof GenericClass hinzugefügt ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
-- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
-- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
-- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
-- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
-- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
-- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
-- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
-- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
-- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
-- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
-- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+- StaticArray<T>“ hinzugefügt, eine effizientere Array-Variante ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Array<T>#flat“ hinzugefügt ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Radix"-Argument bei `Number#toString` implementiert ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Unterstützung für Trennzeichen in Fließkomma-Literalen hinzugefügt ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Unterstützung für Funktionen erster Klasse hinzugefügt ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Buildins hinzufügen: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implementiere `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Unterstützung für Template-Literal-Strings hinzugefügt ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Hinzufügen von „encodeURI(Komponente)“ und „decodeURI(Komponente)“ ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Hinzufügen von `toString`, `toDateString` und `toTimeString` zu `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Hinzufügen von `toUTCString` für `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Hinzufügen von `nonnull/NonNullable` builtin Typ ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
 
 ### Optimizations
 
-- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
-- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
-- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Mathefunktionen wie `exp`, `exp2`, `log`, `log2` und `pow` wurden durch schnellere Varianten ersetzt ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Leicht optimierte `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Mehr Feldzugriffe in std Map und Set zwischenspeichern ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimieren für Zweierpotenzen in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
 
 ### Other
 
-- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Der Typ eines Array-Literal kann nun aus seinem Inhalt abgeleitet werden ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Aktualisierte stdlib auf Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
 
 ## How to upgrade?
 
-1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+1. Ändern Sie Ihre Mappings `apiVersion` in `subgraph.yaml` auf `0.0.6`:
 
 ```yaml
 ...
@@ -56,7 +56,7 @@ dataSources:
       ...
 ```
 
-2. Update the `graph-cli` you're using to the `latest` version by running:
+2. Aktualisieren Sie die `graph-cli`, die Sie verwenden, auf die `aktuelle` Version, indem Sie sie ausführen:
 
 ```bash
 # if you have it globally installed
@@ -66,14 +66,14 @@ npm install --global @graphprotocol/graph-cli@latest
 npm install --save-dev @graphprotocol/graph-cli@latest
 ```
 
-3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+3. Machen Sie dasselbe für `graph-ts`, aber anstatt es global zu installieren, speichern Sie es in Ihren Hauptabhängigkeiten:
 
 ```bash
 npm install --save @graphprotocol/graph-ts@latest
 ```
 
 4. Follow the rest of the guide to fix the language breaking changes.
-5. Run `codegen` and `deploy` again.
+5. Führen Sie `codegen` und `deploy` erneut aus.
 
 ## Breaking changes
 
@@ -110,7 +110,7 @@ If you are unsure which to choose, we recommend always using the safe version. I
 
 ### Variable Shadowing
 
-Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+Früher konnte man [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) machen und Code wie dieser würde funktionieren:
 
 ```typescript
 let a = 10
@@ -141,7 +141,7 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
  in src/mappings/file.ts(41,21)
 ```
 
-To solve you can simply change the `if` statement to something like this:
+Zur Lösung des Problems können Sie die „if“-Anweisung einfach wie folgt ändern:
 
 ```typescript
   if (!decimals) {
@@ -155,7 +155,7 @@ The same applies if you're doing != instead of ==.
 
 ### Casting
 
-The common way to do casting before was to just use the `as` keyword, like this:
+Früher war es üblich, das Schlüsselwort „as“ für das Casting zu verwenden, etwa so:
 
 ```typescript
 let byteArray = new ByteArray(10)
@@ -164,7 +164,7 @@ let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
 
 However this only works in two scenarios:
 
-- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Primitives Casting (zwischen Typen wie `u8`, `i32`, `bool`; z.B.: `let b: isize = 10; b als usize`);
 - Upcasting on class inheritance (subclass → superclass)
 
 Beispiele:
@@ -184,48 +184,48 @@ let bytes = new Bytes(2)
 // <Uint8Array>bytes // same as: bytes as Uint8Array
 ```
 
-There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+Es gibt zwei Szenarien, in denen man casten möchte, aber die Verwendung von `as`/`<T>var` **ist nicht sicher**:
 
 - Downcasting on class inheritance (superclass → subclass)
 - Between two types that share a superclass
 
 ```typescript
-// downcasting on class inheritance
+// Downcasting bei Klassenvererbung
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-// <Bytes>uint8Array // breaks in runtime :(
+// <Bytes>uint8Array // bricht zur Laufzeit ab :(
 ```
 
 ```typescript
-// between two types that share a superclass
+// zwischen zwei Typen, die sich eine Oberklasse teilen
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
 let bytes = new Bytes(2)
-// <ByteArray>bytes // breaks in runtime :(
+// <ByteArray>bytes // bricht zur Laufzeit ab :(
 ```
 
-For those cases, you can use the `changetype<T>` function:
+Für diese Fälle können Sie die Funktion „changetype<T>“ verwenden:
 
 ```typescript
-// downcasting on class inheritance
+// Downcasting bei Klassenvererbung
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-changetype<Bytes>(uint8Array) // works :)
+changetype<Bytes>(uint8Array) // funktioniert :)
 ```
 
 ```typescript
-// between two types that share a superclass
+// zwischen zwei Typen, die sich eine Oberklasse teilen
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
 let bytes = new Bytes(2)
-changetype<ByteArray>(bytes) // works :)
+changetype<ByteArray>(bytes) // funktioniert :)
 ```
 
-If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+Wenn Sie nur die Nullbarkeit entfernen wollen, können Sie weiterhin den „as“-Operator (oder „<T>Variable“) verwenden, aber stellen Sie sicher, dass Sie wissen, dass der Wert nicht null sein kann, sonst bricht es.
 
 ```typescript
 // remove nullability
@@ -238,7 +238,7 @@ if (previousBalance != null) {
 let newBalance = new AccountBalance(balanceId)
 ```
 
-For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+Für den Fall der Nichtigkeit empfehlen wir, einen Blick auf das [nullability check feature] (https://www.assemblyscript.org/basics.html#nullability-checks) zu werfen, es wird Ihren Code sauberer machen 🙂
 
 Also we've added a few more static methods in some types to ease casting, they are:
 
@@ -249,7 +249,7 @@ Also we've added a few more static methods in some types to ease casting, they a
 
 ### Nullability check with property access
 
-To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+Um das [nullability check feature] (https://www.assemblyscript.org/basics.html#nullability-checks) zu verwenden, können Sie entweder `if`-Anweisungen oder den ternären Operator (`?` und `:`) wie folgt verwenden:
 
 ```typescript
 let something: string | null = 'data'
@@ -267,7 +267,7 @@ if (something) {
 }
 ```
 
-However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+Das funktioniert jedoch nur, wenn Sie das „wenn“ / ternär auf eine Variable anwenden, nicht auf einen Eigenschaftszugriff, wie hier:
 
 ```typescript
 class Container {
@@ -381,7 +381,7 @@ if (total === null) {
 total.amount = total.amount + BigInt.fromI32(1)
 ```
 
-You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+Sie müssen sicherstellen, dass Sie den Wert „total.amount“ initialisieren, denn wenn Sie versuchen, wie in der letzten Zeile auf die Summe zuzugreifen, wird das Programm abstürzen. Sie müssen ihn also entweder zuerst initialisieren:
 
 ```typescript
 let total = Total.load('latest')
@@ -394,7 +394,7 @@ if (total === null) {
 total.tokens = total.tokens + BigInt.fromI32(1)
 ```
 
-Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+Oder Sie können einfach Ihr GraphQL-Schema so ändern, dass Sie keinen nullbaren Typ für diese Eigenschaft verwenden, dann werden wir sie im Schritt „Codegen“ mit Null initialisieren 😉
 
 ```graphql
 type Total @entity {
@@ -425,7 +425,7 @@ export class Something {
 }
 ```
 
-The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+Der Compiler wird einen Fehler machen, weil Sie entweder einen Initialisierer für die Eigenschaften hinzufügen müssen, die Klassen sind, oder den Operator `!` hinzufügen müssen:
 
 ```typescript
 export class Something {
@@ -451,7 +451,7 @@ export class Something {
 
 ### Array initialization
 
-The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+Die Klasse `Array` akzeptiert immer noch eine Zahl, um die Länge der Liste zu initialisieren, aber Sie sollten vorsichtig sein, weil Operationen wie `.push` die Größe tatsächlich erhöhen, anstatt z.B. zum Anfang hinzuzufügen:
 
 ```typescript
 let arr = new Array<string>(5) // ["", "", "", "", ""]
@@ -462,10 +462,10 @@ arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
 Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
 
 ```
-ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+ERRO Handler wurde aufgrund eines Ausführungsfehlers übersprungen, Fehler: Mapping abgebrochen bei ~lib/array.ts, Zeile 110, Spalte 40, mit Meldung: Element type must be nullable if array is holey wasm backtrace: 0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format 1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor 2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
 ```
 
-To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+Um tatsächlich am Anfang zu pushen, sollte man entweder das `Array` mit der Größe Null initialisieren, wie hier:
 
 ```typescript
 let arr = new Array<string>(0) // []
@@ -483,7 +483,7 @@ arr[0] = 'something' // ["something", "", "", "", ""]
 
 ### GraphQL schema
 
-This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+Dies ist keine direkte AssemblyScript-Änderung, aber Sie müssen möglicherweise Ihre Datei „schema.graphql“ aktualisieren.
 
 Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
 
@@ -498,7 +498,7 @@ type MyEntity @entity {
 }
 ```
 
-You'll have to add an `!` to the member of the List type, like this:
+Sie müssen ein `!` an das Mitglied des Typs List anhängen, etwa so:
 
 ```graphql
 type Something @entity {

From c3f336fd5c57183ded7c0df39a66eae0c456d9bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 07:11:26 -0500
Subject: [PATCH 3379/3820] New translations getting-started-substreams.mdx
 (German)

---
 website/pages/de/substreams/getting-started-substreams.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/substreams/getting-started-substreams.mdx b/website/pages/de/substreams/getting-started-substreams.mdx
index 3720eac03d47..3f29173dc3ba 100644
--- a/website/pages/de/substreams/getting-started-substreams.mdx
+++ b/website/pages/de/substreams/getting-started-substreams.mdx
@@ -1,5 +1,5 @@
 ---
-title: Substreams Quick Start
+title: Substreams Kurzanleitung
 ---
 
 Discover how to utilize ready-to-use substream packages or develop your own.

From df4dd807f0c98e2a5ef09100180976c1fda591d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 08:09:00 -0500
Subject: [PATCH 3380/3820] New translations graph-node.mdx (German)

---
 website/pages/de/indexing/tooling/graph-node.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/indexing/tooling/graph-node.mdx b/website/pages/de/indexing/tooling/graph-node.mdx
index 1df0dc9b943a..db36df62b03f 100644
--- a/website/pages/de/indexing/tooling/graph-node.mdx
+++ b/website/pages/de/indexing/tooling/graph-node.mdx
@@ -194,7 +194,7 @@ Das Graph-Protokoll erhöht die Anzahl der Netzwerke, die für die Indizierung v
 - Mehrere Anbieter pro Netzwerk (dies kann eine Aufteilung der Last auf Anbieter ermöglichen und kann auch die Konfiguration von vollständigen Knoten sowie Archivknoten ermöglichen, wobei Graph Node günstigere Anbieter bevorzugt, wenn eine bestimmte Arbeitslast dies zulässt).
 - Zusätzliche Anbieterdetails, wie Funktionen, Authentifizierung und Anbietertyp (für experimentelle Firehose-Unterstützung)
 
-The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+Der Abschnitt `[chains]` steuert die Ethereum-Provider, mit denen sich graph-node verbindet, und wo Blöcke und andere Metadaten für jede Kette gespeichert werden. Das folgende Datenbeispiel konfiguriert zwei Ketten, Mainnet und Kovan, wobei die Blöcke für mainnet im vip-Shard und die Blöcke für kovan im primary-Shard gespeichert werden. Die Mainnet-Kette kann zwei verschiedene Anbieter verwenden, während Kovan nur einen Anbieter hat.
 
 ```toml
 [chains]
@@ -210,7 +210,7 @@ shard = "primary"
 provider = [ { label = "kovan", url = "http://..", features = [] } ]
 ```
 
-Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+Lesen Sie mehr über die Providerkonfiguration [hier] (https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
 
 ### Umgebungsvariablen
 

From 5de6ae9877eabe8a4559a0657d21095d8516cd31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 09:15:11 -0500
Subject: [PATCH 3381/3820] New translations graph-node.mdx (German)

---
 .../pages/de/indexing/tooling/graph-node.mdx   | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/de/indexing/tooling/graph-node.mdx b/website/pages/de/indexing/tooling/graph-node.mdx
index db36df62b03f..3ecedb43a350 100644
--- a/website/pages/de/indexing/tooling/graph-node.mdx
+++ b/website/pages/de/indexing/tooling/graph-node.mdx
@@ -214,14 +214,14 @@ Lesen Sie mehr über die Providerkonfiguration [hier] (https://github.com/graphp
 
 ### Umgebungsvariablen
 
-Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+Graph Node unterstützt eine Reihe von Umgebungsvariablen, die Funktionen aktivieren oder das Verhalten von Graph Node ändern können. Diese sind [hier] dokumentiert (https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
 
 ### Kontinuierlicher Einsatz
 
 Benutzer, die ein skaliertes Indizierungs-Setup mit erweiterter Konfiguration betreiben, können von der Verwaltung ihrer Graph-Knoten mit Kubernetes profitieren.
 
-- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
-- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+- Das Indexer-Repository hat eine [Beispiel-Kubernetes-Referenz](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad] (https://docs.graphops.xyz/launchpad/intro) ist ein Toolkit für den Betrieb eines Graph Protocol Indexer auf Kubernetes, das von GraphOps gepflegt wird. Es bietet eine Reihe von Helm-Diagrammen und eine CLI zur Verwaltung eines Graph Node- Deployments.
 
 ### Managing Graph Node
 
@@ -229,21 +229,21 @@ Given a running Graph Node (or Graph Nodes!), the challenge is then to manage de
 
 #### Protokollierung
 
-Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+Die Protokolle von Graph Node können nützliche Informationen für die Debuggen und Optimierung von Graph Node und bestimmten Subgraphen liefern. Graph Node unterstützt verschiedene Log-Ebenen über die Umgebungsvariable `GRAPH_LOG`, mit den folgenden Ebenen: Fehler, Warnung, Info, Debug oder Trace.
 
-In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+Wenn Sie außerdem `GRAPH_LOG_QUERY_TIMING` auf `gql` setzen, erhalten Sie mehr Details darüber, wie GraphQL-Abfragen ausgeführt werden (allerdings wird dadurch eine große Menge an Protokollen erzeugt).
 
-#### Monitoring & alerting
+#### Überwachung und Alarmierung
 
 Graph Node stellt die Metriken standardmäßig durch den Prometheus-Endpunkt am Port 8040 bereit. Grafana kann dann zur Visualisierung dieser Metriken verwendet werden.
 
-The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+Das Indexer Repository bietet eine [Beispiel-Grafana-Konfiguration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
 
 #### Graphman
 
-`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+`graphman` ist ein Wartungswerkzeug für Graph Node, das bei der Diagnose und Lösung verschiedener alltäglicher und außergewöhnlicher Aufgaben hilft.
 
-The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+Der Befehl graphman ist in den offiziellen Containern enthalten, und Sie können ihn mit docker exec in Ihrem graph-node-Container ausführen. Er erfordert eine Datei `config.toml`.
 
 Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
 

From 92beff0831c4bc1e5c50b5a4cf9ad956b112001e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 09:15:13 -0500
Subject: [PATCH 3382/3820] New translations introduction.mdx (Spanish)

---
 website/pages/es/sps/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/sps/introduction.mdx b/website/pages/es/sps/introduction.mdx
index 634c23f2f009..b248e97ee2ca 100644
--- a/website/pages/es/sps/introduction.mdx
+++ b/website/pages/es/sps/introduction.mdx
@@ -1,5 +1,5 @@
 ---
-title: Introduction to Substreams-Powered Subgraphs
+title: Introducción a los Subgrafos Impulsados por Substreams
 ---
 
 Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.

From b78a656d0fe00c1a157ec6539354847097c7d414 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 12:43:13 -0500
Subject: [PATCH 3383/3820] New translations arweave.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/arweave.mdx   | 32 +++++++++----------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/arweave.mdx b/website/pages/tr/subgraphs/cookbook/arweave.mdx
index d3eedc2a7dda..b6b6b7c7a1fd 100644
--- a/website/pages/tr/subgraphs/cookbook/arweave.mdx
+++ b/website/pages/tr/subgraphs/cookbook/arweave.mdx
@@ -2,7 +2,7 @@
 title: Arweave Üzerinde Subgraphlar Oluşturma
 ---
 
-> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+> Graph Düğümü ve Subgraph Studio'daki Arweave desteği beta aşamasındadır: Arweave subgraph'ları oluşturma konusunda herhangi bir sorunuz varsa lütfen [Discord](https://discord.gg/graphprotocol) üzerinden bizimle iletişime geçin!
 
 Bu rehberde, Arweave blok zincirini indekslemek için nasıl Subgraphs oluşturacağınızı ve dağıtacağınızı öğreneceksiniz.
 
@@ -13,36 +13,36 @@ Arweave protokolü geliştiricilere verileri kalıcı olarak depolama imkanı sa
 Arweave, protokolü farklı programlama dillerine entegre etmek için halihazırda çok sayıda kütüphane oluşturmuştur. Daha fazla bilgi için şurayı kontrol edebilirsiniz:
 
 - [Arwiki](https://arwiki.wiki/#/en/main)
-- [Arweave Resources](https://www.arweave.org/build)
+- [Arweave Kaynakları](https://www.arweave.org/build)
 
 ## Arweave Subgraphları Nedir?
 
-The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+The Graph, "Subgraph" adı verilen özel açık API'ler oluşturmanıza olanak tanır. Subgraph'ler, endeksleyicilere (sunucu operatörleri) bir blokzincirinde hangi verilerin endeksleneceğini ve sunucularında saklanacağını belirtmek için kullanılır. Böylece [GraphQL](https://graphql.org/) kullanarak bu verilere istediğiniz zaman sorgu yapabilirsiniz.
 
-[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+[Graph Düğümü](https://github.com/graphprotocol/graph-node) artık Arweave protokolündeki verileri endeksleyebiliyor. Mevcut entegrasyon yalnızca Arweave'i bir blokzinciri olarak (bloklar ve işlemler) endekslemekte olup, henüz depolanan dosyaları endekslememektedir.
 
 ## Bir Arweave Subgraph'ı Oluşturma
 
 Arweave Subgraphları oluşturabilmek ve dağıtabilmek için iki pakete ihtiyacınız vardır:
 
-1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
-2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+1. `@graphprotocol/graph-cli` 0.30.2 sürümünün üzerinde - Bu, subgraph'ler oluşturmak ve dağıtmak için kullanılan bir komut satırı aracıdır. [Buraya] (https://www.npmjs.com/package/@graphprotocol/graph-cli) tıklayarak npm kullanarak indirebilirsiniz.
+2. `@graphprotocol/graph-ts` 0.27.0 sürümünün üzerinde - Bu, subgraph'e özgü türler içeren bir kütüphanedir. [Buraya] (https://www.npmjs.com/package/@graphprotocol/graph-ts) tıklayarak npm kullanarak indirebilirsiniz.
 
 ## Subgraph'ın bileşenleri
 
 Bir subgraph'ın üç bileşeni vardır:
 
-### 1. Manifest - `subgraph.yaml`
+### 1. Manifesto - `subgraph.yaml`
 
 İlgilenilen veri kaynaklarını ve bunların nasıl işlenmesi gerektiğini tanımlar. Arweave yeni bir veri kaynağı türüdür.
 
-### 2. Schema - `schema.graphql`
+### 2. Şema - `schema.graphql`
 
 Burada, GraphQL kullanarak Subgraph'ınızı indeksledikten sonra hangi verileri sorgulayabilmek istediğinizi tanımlarsınız. Bu aslında, modelin bir istek gövdesinin yapısını tanımladığı bir API modeline benzer.
 
-The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+Arweave subgraph'leri için gereksinimler [mevcut dokümanlarda](/developing/creating-a-subgraph/#the-graphql-schema) ele alınmıştır.
 
-### 3. AssemblyScript Mappings - `mapping.ts`
+### 3. AssemblyScript Eşlemeleri - `mapping.ts`
 
 Bu, birisi sizin etkinliklerini gözlemlediğiniz veri kaynaklarıyla etkileşimde bulunduğunda verinin nasıl alınması ve depolanması gerektiğini belirleyen mantıktır. Veri çevrilir ve belirttiğiniz şemaya göre depolanır.
 
@@ -55,7 +55,7 @@ $ graph build # AssemblyScript dosyalarından Web Assembly oluşturur ve tüm su
 
 ## Subgraph Manifest Tanımı
 
-The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+Subgraph manifestosu subgraph.yaml; subgraph'in veri kaynaklarını, ilgili tetikleyicileri ve bu tetikleyicilere yanıt olarak çalıştırılması gereken fonksiyonları tanımlar. Aşağıda, bir Arweave subgraph'i için örnek bir subgraph manifestosu bulunmaktadır:
 
 ```yaml
 specVersion: 0.0.5
@@ -82,20 +82,20 @@ dataSources:
         - handler: handleTx # eşleştirme dosyasındaki fonksiyon adı
 ```
 
-- Arweave subgraphs introduce a new kind of data source (`arweave`)
-- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Arweave subgraph'leri, yeni bir veri kaynağı türü (`arweave`) sunar
+- Ağ, sağlayıcı Graph Düğümü üzerindeki bir ağa karşılık gelmelidir. Subgraph Studio'da, Arweave'in ana ağı `arweave-mainnet` olarak tanımlanır
 - Arweave veri kaynakları, bir Arweave cüzdanının genel anahtarı olan opsiyonel bir source.owner alanı sunar
 
 Arweave veri kaynakları iki tür işleyiciyi destekler:
 
-- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
-- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+- `blockHandlers` - Her yeni Arweave blokunda çalıştırılır. source.owner belirtilmesi gerekmez.
+- `transactionHandlers` - Veri kaynağının sahibinin source.owner olduğu her işlemde çalıştırılır. Şu anda ` transactionHandlers` için bir sahip (owner) gereklidir. Kullanıcılar tüm işlemleri gerçekleştirmek istiyorlarsa `source.owner` olarak boş dize "" sağlamalıdırlar
 
 > source.owner, sahibin adresi veya Genel Anahtarı olabilir.
 >
 > İşlemler Arweave permaweb'in yapı taşlarıdır ve son kullanıcılar tarafından oluşturulan nesnelerdir.
 >
-> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+> Not: [Irys (önceden Bundlr)](https://irys.xyz/) işlemleri henüz desteklenmemektedir.
 
 ## Şema Tanımı
 

From c44222ede59ae60b57cd7db10670e17e920aed03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 12:43:15 -0500
Subject: [PATCH 3384/3820] New translations introduction.mdx (Spanish)

---
 website/pages/es/sps/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/sps/introduction.mdx b/website/pages/es/sps/introduction.mdx
index b248e97ee2ca..c383536a2860 100644
--- a/website/pages/es/sps/introduction.mdx
+++ b/website/pages/es/sps/introduction.mdx
@@ -10,7 +10,7 @@ Use a Substreams package (`.spkg`) as a data source to give your subgraph access
 
 ### Specifics
 
-There are two methods of enabling this technology:
+Existen dos métodos para habilitar esta tecnología:
 
 1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
 

From abe7fda96a5272e9419d00ac3f5b1feef7a831e3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 12:43:16 -0500
Subject: [PATCH 3385/3820] New translations sps-faq.mdx (Spanish)

---
 website/pages/es/sps/sps-faq.mdx | 56 ++++++++++++++++----------------
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/website/pages/es/sps/sps-faq.mdx b/website/pages/es/sps/sps-faq.mdx
index dc99e916ed7a..6a2edb29ded6 100644
--- a/website/pages/es/sps/sps-faq.mdx
+++ b/website/pages/es/sps/sps-faq.mdx
@@ -1,8 +1,8 @@
 ---
-title: Substreams-Powered Subgraphs FAQ
+title: Preguntas frecuentes sobre Subgrafos impulsados por Substreams - FAQ
 ---
 
-## What are Substreams?
+## ¿Qué son los Substreams?
 
 Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
 
@@ -10,45 +10,45 @@ Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engi
 
 Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
 
-## What are Substreams-powered subgraphs?
+## ¿Qué son los subgrafos impulsados por Substreams?
 
 [Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
 
 If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
 
-## How are Substreams-powered subgraphs different from subgraphs?
+## ¿Cómo se diferencian los subgrafos impulsados por Substreams de los subgrafos tradicionales?
 
-Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+Los subgrafos están compuestos por fuentes de datos que especifican eventos en la cadena de bloques, y cómo esos eventos deben ser transformados mediante controladores escritos en AssemblyScript. Estos eventos se procesan de manera secuencial, según el orden en el que ocurren los eventos onchain.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+En cambio, los subgrafos potenciados por Substreams tienen una única fuente de datos que hace referencia a un paquete de Substreams, que es procesado por Graph Node. Los Substreams tienen acceso a datos más granulares onchain en comparación con los subgrafos convencionales, y también pueden beneficiarse de un procesamiento masivamente paralelizado, lo que puede significar tiempos de procesamiento mucho más rápidos.
 
-## What are the benefits of using Substreams-powered subgraphs?
+## ¿Cuáles son los beneficios de usar subgrafos potenciados por Substreams?
 
 Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
 
-## What are the benefits of Substreams?
+## ¿Cuáles son los beneficios de Substreams?
 
-There are many benefits to using Substreams, including:
+Hay muchos beneficios al usar Substreams, incluyendo:
 
-- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+- Componible: Puedes apilar módulos de Substreams como bloques de LEGO y construir sobre módulos de la comunidad, refinando aún más los datos públicos.
 
-- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+- Indexación de alto rendimiento: Indexación mucho más rápida mediante grandes clústeres de operaciones en paralelo (piensa en BigQuery).
 
-- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+- Almacenamiento en cualquier lugar: Envía tus datos a donde quieras: PostgreSQL, MongoDB, Kafka, subgrafos, archivos planos, Google Sheets.
 
-- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+- Programable: Usa código para personalizar la extracción, realizar agregaciones en tiempo de transformación y modelar tu salida para múltiples destinos.
 
-- Access to additional data which is not available as part of the JSON RPC
+- Acceso a datos adicionales que no están disponibles como parte del JSON RPC
 
-- All the benefits of the Firehose.
+- Todos los beneficios de Firehose.
 
-## What is the Firehose?
+## ¿Qué es el Firehose?
 
-Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+Desarrollado por StreamingFast (https://www.streamingfast.io/), Firehose es una capa de extracción de datos blockchain diseñada desde cero para procesar el historial completo de las blockchains a velocidades nunca antes vistas. Proporcionando un enfoque basado en archivos y priorizando la transmisión de datos, es un componente clave del conjunto de tecnologías de código abierto de StreamingFast y la base de Substreams.
 
-Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+Visita la [documentación] (https://firehose.streamingfast.io/) para obtener más información sobre Firehose.
 
-## What are the benefits of the Firehose?
+## ¿Cuáles son los beneficios de Firehose?
 
 There are many benefits to using Firehose, including:
 
@@ -62,23 +62,23 @@ There are many benefits to using Firehose, including:
 
 - Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
 
-## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+## ¿Dónde pueden los desarrolladores acceder a más información sobre los subgrafos potenciados por Substreams y Substreams?
 
-The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+La [documentación de Substreams] (/substreams/introduction/) te enseñará cómo construir módulos de Substreams.
 
 The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
 
-The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+La [última herramienta de Substreams Codegen] (https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) te permitirá iniciar un proyecto de Substreams sin necesidad de escribir código.
 
-## What is the role of Rust modules in Substreams?
+## ¿Cuál es el papel de los módulos de Rust en Substreams?
 
 Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
 
 See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
 
-## What makes Substreams composable?
+## ¿Qué hace que Substreams sea componible?
 
-When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+Cuando se usa Substreams, la composición ocurre en la capa de transformación, lo que permite que los módulos en caché sean reutilizados.
 
 As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
 
@@ -86,10 +86,10 @@ As an example, Alice can build a DEX price module, Bob can use it to build a vol
 
 After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
 
-## Where can I find examples of Substreams and Substreams-powered subgraphs?
+## ¿Dónde puedo encontrar ejemplos de Substreams y Subgrafos potenciados por Substreams?
 
-You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+Puedes visitar [este repositorio de Github] (https://github.com/pinax-network/awesome-substreams) para encontrar ejemplos de Substreams y Subgrafos potenciados por Substreams.
 
-## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+## ¿Qué significan los Substreams y los subgrafos impulsados por Substreams para The Graph Network?
 
 The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From 875d8a0bda2379cb7481e6f4170d8ef96676d500 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 12:43:17 -0500
Subject: [PATCH 3386/3820] New translations tutorial.mdx (Spanish)

---
 website/pages/es/sps/tutorial.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/es/sps/tutorial.mdx b/website/pages/es/sps/tutorial.mdx
index 7eae131c7647..406843bcdefe 100644
--- a/website/pages/es/sps/tutorial.mdx
+++ b/website/pages/es/sps/tutorial.mdx
@@ -1,5 +1,5 @@
 ---
-title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+title: "Tutorial: Configurar un Subgrafo Potenciado por Substreams en Solana"
 ---
 
 Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
@@ -10,12 +10,12 @@ For a video tutorial, check out [How to Index Solana with a Substreams-powered S
 
 ### Prerrequisitos
 
-Before starting, make sure to:
+Antes de comenzar, asegúrate de:
 
 - Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
-- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+- Estar familiarizado con The Graph y conceptos básicos de blockchain, como transacciones y Protobufs.
 
-### Step 1: Initialize Your Project
+### Paso 1: Inicializa tu proyecto
 
 1. Open your Dev Container and run the following command to initialize your project:
 

From 1ea17accea277d7f355c8ccb70823e404e5d966a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:31:57 -0500
Subject: [PATCH 3387/3820] New translations arweave.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/arweave.mdx   | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/arweave.mdx b/website/pages/tr/subgraphs/cookbook/arweave.mdx
index b6b6b7c7a1fd..7f5b237f39b0 100644
--- a/website/pages/tr/subgraphs/cookbook/arweave.mdx
+++ b/website/pages/tr/subgraphs/cookbook/arweave.mdx
@@ -99,13 +99,13 @@ Arweave veri kaynakları iki tür işleyiciyi destekler:
 
 ## Şema Tanımı
 
-Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+Şema tanımı, oluşan subgraph veritabanının yapısını ve varlıklar arasındaki ilişkileri tanımlar. Bu ilişki orijinal veri kaynağından bağımsızdır. Subgraph şema tanımı hakkında daha fazla detay [burada](/developing/creating-a-subgraph/#the-graphql-schema) bulunmaktadır.
 
 ## AssemblyScript Eşlemeleri
 
-The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+Olayları işlemek için kullanılan işleyiciler [AssemblyScript](https://www.assemblyscript.org/) ile yazılmıştır.
 
-Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+Arweave endeksleme, [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) için Arweave'e özgü veri türlerini tanıtır.
 
 ```tsx
 class Block {
@@ -146,27 +146,27 @@ class Transaction {
 }
 ```
 
-Block handlers receive a `Block`, while transactions receive a `Transaction`.
+Blok işleyiciler bir `Block` alırken, işlemler bir `Transaction` alır.
 
-Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+Arweave Subgraph'inin eşleştirmelerini yazmak, bir Ethereum Subgraph'inin eşleştirmelerini yazmaya oldukça benzerdir. Daha fazla bilgi için [buraya](/developing/creating-a-subgraph/#writing-mappings) tıklayın.
 
-## Deploying an Arweave Subgraph in Subgraph Studio
+## Subgraph Studio'da Arweave Subgraph'i Dağıtma
 
-Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+Subgraph Studio panelinizde subgraph'iniz oluşturulduktan sonra onu `graph deploy` CLI komutunu kullanarak dağıtabilirsiniz.
 
 ```bash
-graph deploy --access-token <your-access-token>
+graph deploy --access-token <erişim-jetonunuz>
 ```
 
 ## Arweave Subgraph'ını Sorgulama
 
-The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+Arweave subgraph'leri için GraphQL endpoint'i, mevcut API arayüzüyle şema tanımına göre belirlenir. Daha fazla bilgi için [GraphQL API dokümantasyonuna](/subgraphs/querying/graphql-api/) göz atın.
 
 ## Örnek Subgraph'ler
 
 İşte referans olması için örnek bir subgraph:
 
-- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+- [Arweave için örnek subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
 
 ## SSS
 
@@ -188,9 +188,9 @@ source.owner kullanıcının genel anahtarı veya hesap adresi olabilir.
 
 ### Mevcut şifreleme formatı nedir?
 
-Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+Veriler genellikle Bytes olarak eşleştirmelere aktarılır ve doğrudan kaydedilirse subgraph'te hex formatında (ör. blok ve işlem hash'leri) döner. [Arweave Explorer](https://viewblock.io/arweave/) gibi blok gezginlerinde görüntülenenlerle denkleştirmek için eşlemelerinizi `base64` veya `base64 URL`-safe biçimine dönüştürmek isteyebilirsiniz.
 
-The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+Aşağıdaki `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` yardımcı fonksiyonu kullanılabilir. Bu fonksiyon, `graph-ts`'e eklenecektir:
 
 ```
 const base64Alphabet = [

From db96d362dccd094aa82974d4aed88d36cc6eae5c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:31:58 -0500
Subject: [PATCH 3388/3820] New translations cosmos.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/cosmos.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/cosmos.mdx b/website/pages/tr/subgraphs/cookbook/cosmos.mdx
index 0416f80e3f8b..d369a2c91592 100644
--- a/website/pages/tr/subgraphs/cookbook/cosmos.mdx
+++ b/website/pages/tr/subgraphs/cookbook/cosmos.mdx
@@ -2,18 +2,18 @@
 title: Cosmos'ta Subgraph'ler Oluşturma
 ---
 
-This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+Bu rehber, [Cosmos](https://cosmos.network/) tabanlı blokzincirleri endeksleyen subgraph'ler oluşturma konusunda bir giriş niteliğindedir.
 
 ## Cosmos subgraph'leri nelerdir?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+The Graph, geliştiricilerin blokzinciri olaylarını işlemesine ve sonuçta ortaya çıkan veriyi açık bir GraphQL API'ı (subgraph olarak bilinir) üzerinden kolayca erişilebilir hale getirmesine olanak tanır. [Graph Düğümü](https://github.com/graphprotocol/graph-node), artık Cosmos olaylarını işleyebiliyor. Bu da Cosmos geliştiricilerinin zincir üzerindeki olayları kolayca endekslemek için subgraph'ler oluşturabileceği anlamına geliyor.
 
 Cosmos subgraph'lerinde desteklenen dört tür işleyici vardır:
 
-- **Block handlers** run whenever a new block is appended to the chain.
-- **Event handlers** run when a specific event is emitted.
-- **Transaction handlers** run when a transaction occurs.
-- **Message handlers** run when a specific message occurs.
+- **Blok işleyicileri** zincire yeni bir blok eklendiğinde çalışır.
+- **Olay işleyicileri** belirli bir olay yayıldığında çalışır.
+- **İşlem işleyicileri** bir işlem gerçekleştiğinde çalışır.
+- **Mesaj işleyicileri** belirli bir mesaj oluştuğunda çalışır.
 
 Based on the [official Cosmos documentation](https://docs.cosmos.network/):
 
@@ -83,7 +83,7 @@ Schema definition describes the structure of the resulting subgraph database and
 
 ### AssemblyScript Eşlemeleri
 
-The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+Olayları işlemek için kullanılan işleyiciler [AssemblyScript](https://www.assemblyscript.org/) ile yazılmıştır.
 
 Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
 

From 37688041ff4423722ac51ee30cfc549150d0f940 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:31:59 -0500
Subject: [PATCH 3389/3820] New translations near.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/near.mdx b/website/pages/tr/subgraphs/cookbook/near.mdx
index 3d6114dbb11b..fdac2e1c4f77 100644
--- a/website/pages/tr/subgraphs/cookbook/near.mdx
+++ b/website/pages/tr/subgraphs/cookbook/near.mdx
@@ -96,7 +96,7 @@ Schema definition describes the structure of the resulting subgraph database and
 
 ### AssemblyScript Eşlemeleri
 
-The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+Olayları işlemek için kullanılan işleyiciler [AssemblyScript](https://www.assemblyscript.org/) ile yazılmıştır.
 
 NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
 

From 1890c634dfffd5fb9368ee304bc58e0b94f53ae9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:32:00 -0500
Subject: [PATCH 3390/3820] New translations avoid-eth-calls.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/avoid-eth-calls.mdx | 58 +++++++++----------
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx
index a0613bf2b69f..81ebba92b943 100644
--- a/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx
+++ b/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -1,24 +1,24 @@
 ---
-title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+title: Subgraph Örnek Uygulamalar 4 - eth_calls Kullanımından Kaçınarak Endeksleme Hızını Artırma
 ---
 
-## TLDR
+## Özet
 
-`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+`eth_calls`, bir subgraph'ten bir Ethereum düğümüne yapılan çağrılardır. Bu çağrıların veri döndürmesi ciddi miktarda zaman alır ve endekslemeyi yavaşlatır. Mümkünse akıllı sözleşmelerinizi ihtiyacınız olan tüm verileri yayacak şekilde tasarlayın. Böylece eth_calls kullanmanız gerekmez.
 
-## Why Avoiding `eth_calls` Is a Best Practice
+## `eth_calls` Kullanımından Kaçınmanın Önemi
 
-Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+Subgraph'ler, akıllı sözleşmelerden yayılan olay verilerini endekslemek için optimize edilmiştir. Subgraph'ler bir `eth_call` üzerinden gelen verileri de endeksleyebilir. Ancak, `eth_calls`'ın akıllı sözleşmelere harici çağrılar gerektirmesi nedeniyle, bu durum endekslemeyi önemli ölçüde yavaşlatabilir. Bu çağrıların yanıt verme süresi, subgraph'ten ziyade sorgulanan Ethereum düğümünün bağlantısına ve yanıt hızına bağlıdır. Subgraph'lerimizde `eth_calls`ı en aza indirerek veya ortadan kaldırarak, endeksleme hızımızı önemli ölçüde artırabiliriz.
 
-### What Does an eth_call Look Like?
+### Bir `eth_call` Nasıl Görünür?
 
-`eth_calls` are often necessary when the data required for a subgraph is not available through emitted events. For example, consider a scenario where a subgraph needs to identify whether ERC20 tokens are part of a specific pool, but the contract only emits a basic `Transfer` event and does not emit an event that contains the data that we need:
+`eth_calls`, gerekli veriler olaylar aracılığıyla sağlanmadığında durumlarda genellikle gereklidir. Örneğin, bir subgraph'in ERC20 token'larının belirli bir havuza ait olup olmadığını belirlemesi gerektiğini, ancak sözleşmenin yalnızca temel bir `Transfer` olayı yaydığını ve ihtiyacımız olan verileri içeren bir olay yaymadığını varsayalım:
 
 ```yaml
 event Transfer(address indexed from, address indexed to, uint256 value);
 ```
 
-Suppose the tokens' pool membership is determined by a state variable named `getPoolInfo`. In this case, we would need to use an `eth_call` to query this data:
+Diyelim ki token'ların havuz üyeliği, `getPoolInfo` adlı bir durum değişkeni ile belirleniyor. Bu verileri sorgulamak için şu tarz bir `eth_call` kullanmamız gerekir:
 
 ```typescript
 import { Address } from '@graphprotocol/graph-ts'
@@ -43,17 +43,17 @@ export function handleTransfer(event: Transfer): void {
 }
 ```
 
-This is functional, however is not ideal as it slows down our subgraph’s indexing.
+Bu kod işlevsel olacaktır; ancak subgraph'imizin endekslenmesini yavaşlattığı için ideal değildir.
 
-## How to Eliminate `eth_calls`
+## `eth_calls`'ı Ortadan Kaldırma
 
-Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+İdeal olarak, akıllı sözleşme gerekli tüm verileri olaylar içinde yayacak şekilde güncellenmelidir. Örneğin, havuz bilgilerini olaya dahil edecek şekilde akıllı sözleşmeyi değiştirmek, `eth_calls` ihtiyacını ortadan kaldırabilir:
 
 ```
 event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
 ```
 
-With this update, the subgraph can directly index the required data without external calls:
+Bu güncellemeyle, subgraph harici çağrılara ihtiyaç duymadan gerekli verileri doğrudan endeksleyebilir:
 
 ```typescript
 import { Address } from '@graphprotocol/graph-ts'
@@ -72,17 +72,17 @@ export function handleTransferWithPool(event: TransferWithPool): void {
 }
 ```
 
-This is much more performant as it has eliminated the need for `eth_calls`.
+Bu metot `eth_calls` ihtiyacını ortadan kaldırdığı için çok daha verimlidir.
 
-## How to Optimize `eth_calls`
+## `eth_calls`'ı Optimize Etme
 
-If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+Eğer akıllı sözleşmeyi değiştirmek mümkün değilse ve `eth_calls` kullanmak gerekli ise, Simon Emanuel Schmid tarafından yazılan “[Subgraph Endeksleme Performansını Kolayca İyileştirin: eth_calls'ı Azaltın](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” makalesini okuyarak eth_calls'i optimize etmenin çeşitli stratejilerini öğrenebilirsiniz.
 
 ## Reducing the Runtime Overhead of `eth_calls`
 
-For the `eth_calls` that can not be eliminated, the runtime overhead they introduce can be minimized by declaring them in the manifest. When `graph-node` processes a block it performs all declared `eth_calls` in parallel before handlers are run. Calls that are not declared are executed sequentially when handlers run. The runtime improvement comes from performing calls in parallel rather than sequentially - that helps reduce the total time spent in calls but does not eliminate it completely.
+Kaldırılamayan `eth_calls`'lar manifesto içinde deklare edilerek sebep oldukları çalışma zamanı yükü en aza indirilebilir. `graph-node` bir bloğu işlerken, belirtilen tüm eth_calls'ı işleyiciler çalıştırılmadan önce paralel olarak gerçekleştirir. Deklare edilmeyen çağrılar ise işleyiciler çalıştırıldığında sıralı olarak yürütülür. Paralel çağrılar, çağrılara harcanan toplam süreyi azaltmaya yardımcı olur; ancak bu süreyi tamamen ortadan kaldıramaz.
 
-Currently, `eth_calls` can only be declared for event handlers. In the manifest, write
+Şu anda `eth_calls` yalnızca olay işleyicileri için deklare edilebilir. Manifesto içerisinde şu şekilde yazılabilir:
 
 ```yaml
 event: TransferWithPool(address indexed, address indexed, uint256, bytes32 indexed)
@@ -91,26 +91,26 @@ calls:
   ERC20.poolInfo: ERC20[event.address].getPoolInfo(event.params.to)
 ```
 
-The portion highlighted in yellow is the call declaration. The part before the colon is simply a text label that is only used for error messages. The part after the colon has the form `Contract[address].function(params)`. Permissible values for address and params are `event.address` and `event.params.<name>`.
+Sarıyla vurgulanan bölüm çağrı deklarasyonudur. İki nokta üst üste öncesindeki kısım yalnızca hata mesajları için kullanılan bir metin etiketidir. İki noktadan sonraki kısım ise `Contract[address].function(params)` formundadır. Adres ve parametreler için izin verilen değerler `event.address` ve `event.params.<name>` şeklindedir.
 
-The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+İşleyici, bu `eth_call` sonucuna bir önceki bölümde olduğu gibi sözleşmeye bağlanarak ve çağrıyı yaparak erişir. graph-node, deklare edilen `eth_calls` sonuçlarını bellekte önbelleğe alır. İşleyiciden yapılan çağrı, sonuçları gerçek bir RPC çağrısı yapıp almak yerine, önbellekten alır.
 
-Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
+Not: Deklare edilen `eth_calls`, yalnızca specVersion >= 1.2.0 olan subgraph'lerde kullanılabilir.
 
-## Conclusion
+## Sonuç
 
-You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+Subgraph'lerinizde `eth_calls`'ı en aza indirerek endeksleme performansını önemli ölçüde artırabilirsiniz.
 
-## Subgraph Best Practices 1-6
+## Subgraph Örnek Uygulamalar 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Subgraph Budama ile Sorgu Hızını İyileştirin](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [@derivedFrom Kullanarak Endeksleme ve Sorgu Yanıt Hızını Artırın](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Değişmez Varlıklar ve Bytes ID'ler Kullanarak Endeksleme ve Sorgu Performansını Artırın](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Endeksleme Hızını `eth_calls`'den Kaçınarak İyileştirin](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From 827ec0eec2e1e300f0f820a73b4eb4ccd9d8f522 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:32:01 -0500
Subject: [PATCH 3391/3820] New translations derivedfrom.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/derivedfrom.mdx      | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
index 22845a8d7dd2..76bb28ece499 100644
--- a/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
@@ -2,7 +2,7 @@
 title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
 ---
 
-## TLDR
+## Özet
 
 Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
 
@@ -67,22 +67,22 @@ This will not only make our subgraph more efficient, but it will also unlock thr
 
 3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
 
-## Conclusion
+## Sonuç
 
 Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
 
 For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
 
-## Subgraph Best Practices 1-6
+## Subgraph Örnek Uygulamalar 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Subgraph Budama ile Sorgu Hızını İyileştirin](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [@derivedFrom Kullanarak Endeksleme ve Sorgu Yanıt Hızını Artırın](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Değişmez Varlıklar ve Bytes ID'ler Kullanarak Endeksleme ve Sorgu Performansını Artırın](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Endeksleme Hızını `eth_calls`'den Kaçınarak İyileştirin](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From f0b7b385d009df6fd533a7bece924e5192094b27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:32:03 -0500
Subject: [PATCH 3392/3820] New translations grafting-hotfix.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/grafting-hotfix.mdx  | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
index 1169b1e2b4eb..8b98e58f511e 100644
--- a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
@@ -2,7 +2,7 @@
 title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
 ---
 
-## TLDR
+## Özet
 
 Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
 
@@ -154,7 +154,7 @@ While grafting is a powerful tool for deploying hotfixes quickly, there are spec
 - **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
 - **Testing**: Always test grafting in a development environment before deploying to production.
 
-## Conclusion
+## Sonuç
 
 Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
 
@@ -171,16 +171,16 @@ However, it’s important to use grafting judiciously and follow best practices
 
 By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
 
-## Subgraph Best Practices 1-6
+## Subgraph Örnek Uygulamalar 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Subgraph Budama ile Sorgu Hızını İyileştirin](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [@derivedFrom Kullanarak Endeksleme ve Sorgu Yanıt Hızını Artırın](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Değişmez Varlıklar ve Bytes ID'ler Kullanarak Endeksleme ve Sorgu Performansını Artırın](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Endeksleme Hızını `eth_calls`'den Kaçınarak İyileştirin](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From 55536fcdd2525ab9bb60d2fc505f2e97ceafb6ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:32:04 -0500
Subject: [PATCH 3393/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Turkish)

---
 .../immutable-entities-bytes-as-ids.mdx        | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
index 3a9ba309dd27..d1ee0402fe6b 100644
--- a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -2,7 +2,7 @@
 title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
 ---
 
-## TLDR
+## Özet
 
 Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
 
@@ -169,22 +169,22 @@ Query Response:
 }
 ```
 
-## Conclusion
+## Sonuç
 
 Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
 
 Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
 
-## Subgraph Best Practices 1-6
+## Subgraph Örnek Uygulamalar 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Subgraph Budama ile Sorgu Hızını İyileştirin](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [@derivedFrom Kullanarak Endeksleme ve Sorgu Yanıt Hızını Artırın](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Değişmez Varlıklar ve Bytes ID'ler Kullanarak Endeksleme ve Sorgu Performansını Artırın](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Endeksleme Hızını `eth_calls`'den Kaçınarak İyileştirin](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From 836347644d3d248411fbfc23a92580d994f64a9c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:32:05 -0500
Subject: [PATCH 3394/3820] New translations pruning.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/pruning.mdx    | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/pruning.mdx b/website/pages/tr/subgraphs/cookbook/pruning.mdx
index c6b1217db9a5..47449b6437a3 100644
--- a/website/pages/tr/subgraphs/cookbook/pruning.mdx
+++ b/website/pages/tr/subgraphs/cookbook/pruning.mdx
@@ -2,7 +2,7 @@
 title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
 ---
 
-## TLDR
+## Özet
 
 [Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
 
@@ -36,20 +36,20 @@ dataSources:
 
 - It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
 
-## Conclusion
+## Sonuç
 
 Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
 
-## Subgraph Best Practices 1-6
+## Subgraph Örnek Uygulamalar 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Subgraph Budama ile Sorgu Hızını İyileştirin](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [@derivedFrom Kullanarak Endeksleme ve Sorgu Yanıt Hızını Artırın](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Değişmez Varlıklar ve Bytes ID'ler Kullanarak Endeksleme ve Sorgu Performansını Artırın](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Endeksleme Hızını `eth_calls`'den Kaçınarak İyileştirin](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From f1465eb8ba97e2f85016d2ae591b461f6a4f6bea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:32:06 -0500
Subject: [PATCH 3395/3820] New translations secure-api-keys-nextjs.mdx
 (Turkish)

---
 website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index d258a3d2bd1c..37e0846da826 100644
--- a/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -118,6 +118,6 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ![Server-side rendering](/img/api-key-server-side-rendering.png)
 
-### Conclusion
+### Sonuç
 
 By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From f6921602f80c83f08817ffa5f2c8251d7585db7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:32:07 -0500
Subject: [PATCH 3396/3820] New translations timeseries.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/timeseries.mdx | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/timeseries.mdx b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
index e7b242bfa2f3..83ccc8cacfa8 100644
--- a/website/pages/tr/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
@@ -2,7 +2,7 @@
 title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
 ---
 
-## TLDR
+## Özet
 
 Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
 
@@ -169,7 +169,7 @@ Supported operators and functions include basic arithmetic (+, -, \_, /), compar
 - Sorting: Results are automatically sorted by timestamp and id in descending order.
 - Current Data: An optional current argument can include the current, partially filled interval.
 
-### Conclusion
+### Sonuç
 
 Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
 
@@ -179,16 +179,16 @@ Implementing timeseries and aggregations in subgraphs is a best practice for pro
 
 By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
 
-## Subgraph Best Practices 1-6
+## Subgraph Örnek Uygulamalar 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Subgraph Budama ile Sorgu Hızını İyileştirin](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [@derivedFrom Kullanarak Endeksleme ve Sorgu Yanıt Hızını Artırın](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Değişmez Varlıklar ve Bytes ID'ler Kullanarak Endeksleme ve Sorgu Performansını Artırın](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Endeksleme Hızını `eth_calls`'den Kaçınarak İyileştirin](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From 4ffcf9e69dbf497f087c50b308216adb5f0a2b90 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:32:10 -0500
Subject: [PATCH 3397/3820] New translations tutorial.mdx (Spanish)

---
 website/pages/es/sps/tutorial.mdx | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/es/sps/tutorial.mdx b/website/pages/es/sps/tutorial.mdx
index 406843bcdefe..c54f8c51ff0c 100644
--- a/website/pages/es/sps/tutorial.mdx
+++ b/website/pages/es/sps/tutorial.mdx
@@ -17,15 +17,15 @@ Antes de comenzar, asegúrate de:
 
 ### Paso 1: Inicializa tu proyecto
 
-1. Open your Dev Container and run the following command to initialize your project:
+1. Abre tu Dev Container y ejecuta el siguiente comando para inicializar tu proyecto:
 
    ```bash
    substreams init
    ```
 
-2. Select the "minimal" project option.
+2. Selecciona la opción de proyecto "mínimo".
 
-3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+3. Reemplaza el contenido del archivo 'substreams.yam'l generado con la siguiente configuración, que filtra las transacciones para la cuenta de Orca en el ID del programa SPL token:
 
 ```yaml
 specVersion: v0.1.0
@@ -51,15 +51,15 @@ params: # Modify the param fields to meet your needs
   map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
 ```
 
-### Step 2: Generate the Subgraph Manifest
+### Paso 2: Generar el Manifiesto del Subgrafo
 
-Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+Una vez que el proyecto esté inicializado, genera un manifiesto de subgraph ejecutando el siguiente comando en el Dev Container:
 
 ```bash
-substreams codegen subgraph
+substreams codegen subgrafo
 ```
 
-You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+Generarás un manifiesto subgraph.yaml que importa el paquete de Substreams como una fuente de datos:
 
 ```yaml
 ---
@@ -78,7 +78,7 @@ dataSources:
       handler: handleTriggers
 ```
 
-### Step 3: Define Entities in `schema.graphql`
+### Paso 3: Definir Entidades en schema.graphql
 
 Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
 
@@ -94,9 +94,9 @@ type MyTransfer @entity {
 }
 ```
 
-This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+Este esquema define una entidad 'MyTransfer' con campos como 'id', 'amount', 'source', 'designation' y 'signers'.
 
-### Step 4: Handle Substreams Data in `mappings.ts`
+### Paso 4: Manejar los datos de Substreams en 'mappings.ts'
 
 With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
 
@@ -131,15 +131,15 @@ export function handleTriggers(bytes: Uint8Array): void {
 }
 ```
 
-### Step 5: Generate Protobuf Files
+### Paso 5: Generar Archivos Protobuf
 
-To generate Protobuf objects in AssemblyScript, run the following command:
+Para generar objetos Protobuf en AssemblyScript, ejecuta el siguiente comando:
 
 ```bash
 npm run protogen
 ```
 
-This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+Este comando convierte las definiciones de Protobuf en AssemblyScript, lo que te permite usarlas en el controlador del subgrafo.
 
 ### Conclusion
 
@@ -151,4 +151,4 @@ Congratulations! You've successfully set up a trigger-based Substreams-powered s
 
 ### Recursos Adicionales
 
-For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).
+Para una personalización y optimización más avanzada, consulta la [documentación oficial de Substreams] (https://substreams.streamingfast.io/tutorials/solana).

From a34e56597124beac28e6cc26458c1c2c40f6e7ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 14:32:11 -0500
Subject: [PATCH 3398/3820] New translations tutorial.mdx (Turkish)

---
 website/pages/tr/sps/tutorial.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/sps/tutorial.mdx b/website/pages/tr/sps/tutorial.mdx
index e9652491c255..7dbb83514bb7 100644
--- a/website/pages/tr/sps/tutorial.mdx
+++ b/website/pages/tr/sps/tutorial.mdx
@@ -141,7 +141,7 @@ npm run protogen
 
 This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
 
-### Conclusion
+### Sonuç
 
 Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
 

From 3aebcd08d7799b19fd8b102907fc7aa6cabbfce4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 16:05:46 -0500
Subject: [PATCH 3399/3820] New translations cosmos.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/cosmos.mdx    | 44 +++++++++----------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/cosmos.mdx b/website/pages/tr/subgraphs/cookbook/cosmos.mdx
index d369a2c91592..06cf4177c0e2 100644
--- a/website/pages/tr/subgraphs/cookbook/cosmos.mdx
+++ b/website/pages/tr/subgraphs/cookbook/cosmos.mdx
@@ -15,13 +15,13 @@ Cosmos subgraph'lerinde desteklenen dört tür işleyici vardır:
 - **İşlem işleyicileri** bir işlem gerçekleştiğinde çalışır.
 - **Mesaj işleyicileri** belirli bir mesaj oluştuğunda çalışır.
 
-Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+[Cosmos'un resmi dokümantasyonuna](https://docs.cosmos.network/) dayalı olarak:
 
-> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+> [Olaylar](https://docs.cosmos.network/main/learn/advanced/events), uygulamanın yürütülmesi hakkında bilgi içeren nesnelerdir. Genellikle blok gezginleri ve cüzdanlar gibi hizmet sağlayıcılar tarafından çeşitli mesajların yürütülmesini izlemek ve işlemleri endekslemek için kullanılırlar.
 >
-> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+> [İşlemler](https://docs.cosmos.network/main/learn/advanced/transactions), uygulamada durum değişikliklerini tetiklemek için son kullanıcılar tarafından oluşturulan nesnelerdir.
 >
-> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+> [Mesajlar](https://docs.cosmos.network/main/learn/advanced/transactions#messages), ait oldukları modül kapsamındaki durum geçişlerini tetikleyen modüle özel nesnelerdir.
 
 Tüm verilere bir blok işleyici ile erişilebilmesine rağmen, diğer işleyiciler, subgraph geliştiricilerin verileri çok daha ayrıntılı bir şekilde işlemesine olanak tanır.
 
@@ -29,23 +29,23 @@ Tüm verilere bir blok işleyici ile erişilebilmesine rağmen, diğer işleyici
 
 ### Subgraph Gereksinimleri
 
-[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), subgraph'leri oluşturmak ve dağıtmak için bir CLI aracıdır. Cosmos subgraph'leri ile çalışabilmek için `>=0.30.0` sürümü gereklidir.
 
-[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts), subgraph'e özel türlerden oluşan bir kütüphanedir ve Cosmos subgraph'leri ile çalışabilmek için `>=0.27.0` sürümü gereklidir.
 
 ### Subgraph Ana Bileşenleri
 
 Bir subgraph'i tanımlama noktasında üç anahtar kısım vardır:
 
-**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+**subgraph.yaml**: hangi olayıların takip edileceğini ve bunların nasıl işleneceğini tanımlayan subgraph manifestosunu içeren bir YAML dosyası.
 
-**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+**schema.graphql**: Subgraph'iniz için hangi verilerin saklanacağını ve bu verilerin GraphQL aracılığıyla nasıl sorgulanabileceğini tanımlayan bir GraphQL şemasıdır.
 
-**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+**AssemblyScript Eşlemeleri:** blokzinciri verilerini şemanızda tanımlanan varlıklara dönüştüren [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) kodu.
 
 ### Subgraph Manifest Tanımı
 
-The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+Subgraph manifestosu (`subgraph.yaml`), subgraph için veri kaynaklarını, ilgili tetikleyicileri ve bu tetikleyicilere yanıt olarak çalıştırılması gereken fonksiyonları (`handlers`) tanımlar. Aşağıda bir Cosmos subgraph manifestosu örneği bulunmaktadır:
 
 ```yaml
 specVersion: 0.0.5
@@ -74,18 +74,18 @@ dataSources:
       file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
 ```
 
-- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
-- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+- Cosmos subgraph'leri, yeni bir veri kaynağı `türü` (`kind`) tanıtır (`cosmos`).
+- `network` (ağ), Cosmos ekosistemindeki bir zinciri belirtmelidir. Örnekte, Cosmos Hub ana ağı kullanılmıştır.
 
 ### Şema Tanımı
 
-Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+Şema tanımı, ortaya çıkan subgraph veritabanının yapısını ve varlıklar arasındaki ilişkileri açıklar. Bu, orijinal veri kaynağından bağımsızdır. Subgraph şema tanımı hakkında daha fazla detay [burada](/developing/creating-a-subgraph/#the-graphql-schema) bulunabilir.
 
 ### AssemblyScript Eşlemeleri
 
 Olayları işlemek için kullanılan işleyiciler [AssemblyScript](https://www.assemblyscript.org/) ile yazılmıştır.
 
-Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+Cosmos endeksleme, [AssemblyScript API'ına](/subgraphs/developing/creating/graph-ts/api/) Cosmos'a özgü veri türlerini tanıtır.
 
 ```tsx
 class Block {
@@ -165,20 +165,20 @@ class Any {
 
 Her işleyici türü, bir eşleme işlevine bağımsız değişken olarak iletilen kendi veri yapısıyla birlikte gelir.
 
-- Block handlers receive the `Block` type.
-- Event handlers receive the `EventData` type.
-- Transaction handlers receive the `TransactionData` type.
-- Message handlers receive the `MessageData` type.
+- Blok işleyiciler `Block` türünü alır.
+- Olay işleyiciler `EventData` türünü alır.
+- İşlem işleyiciler `TransactionData` türünü alır.
+- Mesaj işleyiciler `MessageData` türünü alır.
 
-As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+`MessageData`'nın bir parçası olarak mesaj işleyici, bir mesajı kapsayan işlemle ilgili en önemli bilgileri içeren bir işlem bağlamı alır. İşlem bağlamı, yalnızca ilgili olay bir işlemle ilişkili olduğunda `EventData` türünde de mevcuttur. Ek olarak, tüm işleyiciler bir bloka (`HeaderOnlyBlock`) referans alır.
 
-You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+Cosmos entegrasyonun tüm türlerinin listesine [buradan](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts) ulaşabilirsiniz.
 
 ### Mesaj çözme
 
-It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+Cosmos mesajlarının zincir-spesifik olduğunu ve bir subgraph'e [Protocol Buffers](https://protobuf.dev/) yükü olarak serileştirilmiş biçimde iletildiğini unutmamak önemlidir. Sonuç olarak, mesaj verileri işlenmeden önce bir eşleme fonksiyonunda çözülmelidir.
 
-An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+Subgraph içinde mesaj verilerinin nasıl çözüleceğine dair bir örneğe [buradan](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts) ulaşabilirsiniz.
 
 ## Bir Cosmos subgraph'i inşa etme ve oluşturma
 

From f416432a51cb4c6d12fd064fee1b7eeafdf77a32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 16:05:47 -0500
Subject: [PATCH 3400/3820] New translations near.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/near.mdx b/website/pages/tr/subgraphs/cookbook/near.mdx
index fdac2e1c4f77..cac762613932 100644
--- a/website/pages/tr/subgraphs/cookbook/near.mdx
+++ b/website/pages/tr/subgraphs/cookbook/near.mdx
@@ -92,7 +92,7 @@ NEAR veri kaynakları iki tür işleyiciyi destekler:
 
 ### Şema Tanımı
 
-Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+Şema tanımı, ortaya çıkan subgraph veritabanının yapısını ve varlıklar arasındaki ilişkileri açıklar. Bu, orijinal veri kaynağından bağımsızdır. Subgraph şema tanımı hakkında daha fazla detay [burada](/developing/creating-a-subgraph/#the-graphql-schema) bulunabilir.
 
 ### AssemblyScript Eşlemeleri
 

From 955f4dc09d87cbd07eefe310529037c43333ecea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 17:31:29 -0500
Subject: [PATCH 3401/3820] New translations cosmos.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/cosmos.mdx    | 32 +++++++++----------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/cosmos.mdx b/website/pages/tr/subgraphs/cookbook/cosmos.mdx
index 06cf4177c0e2..507bc7acb87d 100644
--- a/website/pages/tr/subgraphs/cookbook/cosmos.mdx
+++ b/website/pages/tr/subgraphs/cookbook/cosmos.mdx
@@ -182,13 +182,13 @@ Subgraph içinde mesaj verilerinin nasıl çözüleceğine dair bir örneğe [bu
 
 ## Bir Cosmos subgraph'i inşa etme ve oluşturma
 
-The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+Subgraph eşlemelerini yazmaya başlamadan önceki ilk adım, `schema.graphql` dosyasında tanımlanan varlıklar temelinde tür bağlamalarını oluşturmaktır. Bu, eşleme fonksiyonlarının bu türlerden yeni nesneler oluşturmasına ve bunları mağazaya kaydetmesine olanak tanır. Bu işlem, `codegen` CLI komutuyla gerçekleştirilir:
 
 ```bash
 $ graph codegen
 ```
 
-Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+Eşlemeler hazır olduğunda, subgraph derlenmelidir. Bu adım, manifestoda veya eşlemelerde herhangi bir hata olup olmadığını gösterir. Bir subgraph, Graph Düğümü'ne dağıtılabilmesi için başarıyla derlenmelidir. Bu işlem, `build` CLI komutuyla gerçekleştirilebilir:
 
 ```bash
 $ graph build
@@ -196,17 +196,17 @@ $ graph build
 
 ## Bir Cosmos subgraph'ini deploy etme
 
-Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+Subgraph oluşturulduktan sonra, `graph deploy` CLI komutunu kullanarak subgraph'inizi dağıtabilirsiniz:
 
 **Subgraph Studio**
 
-Visit the Subgraph Studio to create a new subgraph.
+Yeni bir subgraph oluşturmak için Subgraph Studio'yu ziyaret edin.
 
 ```bash
 graph deploy subgraph-name
 ```
 
-**Local Graph Node (based on default configuration):**
+**Yerel Graph Düğümü (varsayılan yapılandırma temel alınarak):**
 
 ```bash
 graph create subgraph-name --node http://localhost:8020
@@ -218,7 +218,7 @@ graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost
 
 ## Bir Cosmos subgraph'ini sorgulama
 
-The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+Cosmos subgraphleri için GraphQL uç noktası, mevcut API arayüzü ile şema tanımına göre belirlenir. Daha fazla bilgi için [GraphQL API dokümantasyonuna](/subgraphs/querying/graphql-api/) göz atabilirsiniz.
 
 ## Desteklenen Cosmos Blok Zincirleri
 
@@ -226,32 +226,32 @@ The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition
 
 #### Cosmos Hub Nedir?
 
-The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+[Cosmos Hub blokzinciri](https://hub.cosmos.network/), [Cosmos](https://cosmos.network/) ekosistemindeki ilk blokzinciridir. Daha fazla bilgi için [resmi dokümantasyonu] (https://docs.cosmos.network/) ziyaret edebilirsiniz.
 
 #### Ağlar
 
-Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+Cosmos Hub ana ağı `cosmoshub-4` olarak geçer. Cosmos Hub mevcut test ağı ise `theta-testnet-001` olarak geçer. <br/>`cosmoshub-3` gibi diğer Cosmos Hub ağları durdurulmuş olduğundan, bu ağlara veri sağlanmamaktadır.
 
 ### Osmosis
 
-> Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
+> Graph Düğümü ve Subgraph Studio'daki Osmosis desteği beta aşamasındadır: Osmosis subgraphleri oluşturmayla ilgili sorularınız için The Graph ekibiyle iletişime geçebilirsiniz!
 
 #### Osmosis Nedir?
 
-[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+[Osmosis](https://osmosis.zone/), Cosmos SDK üzerinde inşa edilmiş merkeziyetsiz, zincirler arası bir otomatik piyasa yapıcı (AMM) protokolüdür. Kullanıcıların özel likidite havuzları oluşturmasına ve IBC-uyumlu token'ları alıp satmasına olanak tanır. Daha fazla bilgi için [resmi dokümantasyonu](https://docs.osmosis.zone/) inceleyebilirsiniz.
 
 #### Ağlar
 
-Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+Osmosis ana ağı `osmosis-1` olarak geçer. Osmosis mevcut test ağı ise `osmo-test-4` olarak geçer.
 
 ## Örnek Subgraph'ler
 
-Here are some example subgraphs for reference:
+Aşağıda bazı örnek subgraph'leri bulabilirsiniz:
 
-[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+[Blok Filtreleme Örneği](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
 
-[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+[Validator Ödülleri Örneği](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
 
-[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+[Validator Delegasyonları Örneği](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
 
-[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)
+[Osmosis Token Takasları Örneği](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 17737a2d08627b0437b47f670cb46036d25eaf06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 17:31:30 -0500
Subject: [PATCH 3402/3820] New translations near.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/near.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/near.mdx b/website/pages/tr/subgraphs/cookbook/near.mdx
index cac762613932..05b7d76468b2 100644
--- a/website/pages/tr/subgraphs/cookbook/near.mdx
+++ b/website/pages/tr/subgraphs/cookbook/near.mdx
@@ -182,7 +182,7 @@ More information on creating and deploying subgraphs on Subgraph Studio can be f
 
 As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
 
-Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+Subgraph oluşturulduktan sonra, `graph deploy` CLI komutunu kullanarak subgraph'inizi dağıtabilirsiniz:
 
 ```sh
 $ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
@@ -232,7 +232,7 @@ The GraphQL endpoint for NEAR subgraphs is determined by the schema definition,
 
 ## Örnek Subgraph'ler
 
-Here are some example subgraphs for reference:
+Aşağıda bazı örnek subgraph'leri bulabilirsiniz:
 
 [NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
 

From 917d8527696dfa90058831eadea7ec4c81d79dfc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 17:31:31 -0500
Subject: [PATCH 3403/3820] New translations avoid-eth-calls.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx
index 81ebba92b943..b6a79c5ae608 100644
--- a/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx
+++ b/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -28,10 +28,10 @@ import { TokenTransaction } from '../generated/schema'
 export function handleTransfer(event: Transfer): void {
   let transaction = new TokenTransaction(event.transaction.hash.toHex())
 
-  // Bind the ERC20 contract instance to the given address:
+  // Belirtilen adrese ERC20 sözleşme örneğini bağla:
   let instance = ERC20.bind(event.address)
 
-  // Retrieve pool information via eth_call
+  // eth_call aracılığıyla havuz bilgilerini al
   let poolInfo = instance.getPoolInfo(event.params.to)
 
   transaction.pool = poolInfo.toHexString()
@@ -78,7 +78,7 @@ Bu metot `eth_calls` ihtiyacını ortadan kaldırdığı için çok daha verimli
 
 Eğer akıllı sözleşmeyi değiştirmek mümkün değilse ve `eth_calls` kullanmak gerekli ise, Simon Emanuel Schmid tarafından yazılan “[Subgraph Endeksleme Performansını Kolayca İyileştirin: eth_calls'ı Azaltın](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” makalesini okuyarak eth_calls'i optimize etmenin çeşitli stratejilerini öğrenebilirsiniz.
 
-## Reducing the Runtime Overhead of `eth_calls`
+## `eth_call` Çağrılarının Fazla Çalışma Yükünü Azaltma
 
 Kaldırılamayan `eth_calls`'lar manifesto içinde deklare edilerek sebep oldukları çalışma zamanı yükü en aza indirilebilir. `graph-node` bir bloğu işlerken, belirtilen tüm eth_calls'ı işleyiciler çalıştırılmadan önce paralel olarak gerçekleştirir. Deklare edilmeyen çağrılar ise işleyiciler çalıştırıldığında sıralı olarak yürütülür. Paralel çağrılar, çağrılara harcanan toplam süreyi azaltmaya yardımcı olur; ancak bu süreyi tamamen ortadan kaldıramaz.
 

From edf219694a3dc37bd292e7a9710eec2f199b5671 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 17:31:32 -0500
Subject: [PATCH 3404/3820] New translations derivedfrom.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/derivedfrom.mdx     | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
index 76bb28ece499..89c3683e137e 100644
--- a/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
@@ -1,28 +1,28 @@
 ---
-title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+title: Subgraph Örnek Uygulamalar 2 - @derivedFrom Kullanarak Endeksleme ve Sorgu Performansını İyileştirin
 ---
 
 ## Özet
 
-Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+Şemanızdaki diziler, binlerce girişin ötesine geçtiğinde subgraph performansını ciddi şekilde yavaşlatabilir. Mümkünse `@derivedFrom` yönergesi kullanılmalıdır. Bu yaklaşım; büyük dizilerin oluşmasını önler, işleyicileri basitleştirir ve bireysel varlıkların boyutunu küçülterek endeksleme hızını ve sorgu performansını önemli ölçüde artırır.
 
-## How to Use the `@derivedFrom` Directive
+## `@derivedFrom` Yönergesi Nasıl Kullanılır
 
-You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+Şemanızdaki dizinin ardına @derivedFrom yönergesini eklemeniz yeterlidir. Örnek:
 
 ```graphql
 comments: [Comment!]! @derivedFrom(field: "post")
 ```
 
-`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+`@derivedFrom`, verimli bir şekilde birden çoka ilişkiler oluşturur. Böylece bir varlığın, ilgili alan temelinde birden fazla ilişkili varlıklarla dinamik olarak ilişkilendirilmesini sağlar. Bu yaklaşım, ilişkinin her iki tarafının da yinelenen verileri saklama gerekliliğini ortadan kaldırarak subgraph'i daha verimli hale getirir.
 
-### Example Use Case for `@derivedFrom`
+### `@derivedFrom`'ın Örnek Kullanımı
 
-An example of a dynamically growing array is a blogging platform where a “Post” can have many “Comments”.
+Dinamik olarak büyüyen dizilere örnek olarak, bir "Post"un (gönderinin) birçok "Comment" (yorum) içerebileceği bir blog platformu verilebilir.
 
-Let’s start with our two entities, `Post` and `Comment`
+`Post` ve `Comment` olmak üzere iki varlıkla başlayalım
 
-Without optimization, you could implement it like this with an array:
+Optimizasyon olmadan, bunu bir dizi ile şu şekilde uygulayabilirsiniz:
 
 ```graphql
 type Post @entity {
@@ -38,9 +38,9 @@ type Comment @entity {
 }
 ```
 
-Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+Bu tür diziler, fiilen, ilişkinin "Post" tarafında fazladan "Comments" verisi depolar.
 
-Here’s what an optimized version looks like using `@derivedFrom`:
+`@derivedFrom` kullanarak optimize edilmiş bir sürüm şu şekilde görünür:
 
 ```graphql
 type Post @entity {

From f883b2e2016debfe67e61f2b7a1c34ceeb1176f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 17:31:35 -0500
Subject: [PATCH 3405/3820] New translations quick-start.mdx (Turkish)

---
 website/pages/tr/subgraphs/quick-start.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/tr/subgraphs/quick-start.mdx b/website/pages/tr/subgraphs/quick-start.mdx
index f168fa1d9e55..f7515351ce23 100644
--- a/website/pages/tr/subgraphs/quick-start.mdx
+++ b/website/pages/tr/subgraphs/quick-start.mdx
@@ -137,7 +137,7 @@ Subgraph'inizi yayımlamak için, kontrol panelindeki Yayımla düğmesine tıkl
 
 Subgraph'inizi yayımlamak istediğiniz ağı seçin.
 
-#### Publishing from the CLI
+#### CLI'den Yayımlama
 
 Sürüm 0.73.0 itibarıyla, subgraph'inizi Graph CLI ile de yayımlayabilirsiniz.
 
@@ -157,13 +157,13 @@ graph publish
 ```
 ````
 
-3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+3. Bir pencere açılır ve cüzdanınızı bağlamanıza, metaveri eklemenize ve tamamlanmış subgraph'inizi tercih ettiğiniz bir ağa dağıtmanıza olanak tanır.
 
 ![cli-ui](/img/cli-ui.png)
 
 To customize your deployment, see [Publishing a Subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/).
 
-#### Adding signal to your subgraph
+#### Subgraph'inize sinyal ekleme
 
 1. To attract Indexers to query your subgraph, you should add GRT curation signal to it.
 

From 6f6ed730efbd1307b9cbabdd59f5236b8cae0556 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 17:31:36 -0500
Subject: [PATCH 3406/3820] New translations supported-network-requirements.mdx
 (Turkish)

---
 .../supported-network-requirements.mdx        | 30 +++++++++----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/tr/indexing/supported-network-requirements.mdx b/website/pages/tr/indexing/supported-network-requirements.mdx
index 73adcca0dded..85eaad3b00c4 100644
--- a/website/pages/tr/indexing/supported-network-requirements.mdx
+++ b/website/pages/tr/indexing/supported-network-requirements.mdx
@@ -1,18 +1,18 @@
 ---
-title: Supported Network Requirements
+title: Desteklenen Ağ Gereksinimleri
 ---
 
-| Ağ        | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
-| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
-| Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
-| Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Base      | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ core CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME preffered)<br /> _last updated 14th May 2024_           |         ✅        |
-| Binance   | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                      | 8 core / 16 threads CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _last updated 22nd June 2024_             |         ✅        |
-| Celo      | [Docker Guide](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                             | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Ethereum  | [Docker Guide](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                  | Higher clock speed over core count<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe recommended)<br /> _last updated August 2023_ |         ✅        |
-| Fantom    | [Docker Guide](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                           | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
-| Gnosis    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                              | 6 core / 12 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _last updated August 2023_                   |         ✅        |
-| Linea     | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                      | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 2nd April 2024_                            |         ✅        |
-| Optimism  | [Erigon Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Guide](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |
-| Polygon   | [Docker Guide](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                          | 16 core CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _last updated August 2023_                              |         ✅        |
-| Scroll    | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                     | 4 core / 8 threads CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _last updated 3rd April 2024_                    |         ✅        |
+| Ağ        | Rehberler                                                                                                                                                                                                                                                                                                 | Sistem Gereksinimleri                                                                                                                                   | Endeksleme Ödülleri |
+| --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | :-----------------: |
+| Arbitrum  | [Baremetal Rehberi](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Rehberi](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                   | 4+ çekirdekli CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _son güncelleme Ağustos 2023_                                        |          ✅          |
+| Avalanche | [Docker Rehberi](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                            | 4 çekirdekli / 8 iş parçacıklı CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _son güncelleme Ağustos 2023_                       |          ✅          |
+| Base      | [Erigon Baremetal Rehberi](https://docs.infradao.com/archive-nodes-101/base/erigon/baremetal)<br /><br /> [GETH Baremetal Rehberi](https://docs.infradao.com/archive-nodes-101/base/geth/baremetal)<br /> [GETH Docker Rehberi](https://docs.infradao.com/archive-nodes-101/base/geth/docker)             | 8+ çekirdekli CPU<br /> Debian 12/Ubuntu 22.04<br /> 16 GB RAM<br /> >= 4.5TB (NVME tercih edilir)<br /> _son güncelleme 14 Mayıs 2024_                 |          ✅          |
+| Binance   | [Erigon Baremetal Rehberi](https://docs.infradao.com/archive-nodes-101/binance/erigon/baremetal)                                                                                                                                                                                                          | 8 çekirdekli / 16 iş parçacıklı CPU<br /> Ubuntu 22.04<br /> >=32 GB RAM<br /> >= 14 TiB NVMe SSD<br /> _son güncelleme 22 Haziran 2024_                |          ✅          |
+| Celo      | [Docker Rehberi](https://docs.infradao.com/archive-nodes-101/celo/docker)                                                                                                                                                                                                                                 | 4 çekirdekli / 8 iş parçacıklı CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 2 TiB NVMe SSD<br /> _son güncelleme Ağustos 2023_                       |          ✅          |
+| Ethereum  | [Docker Rehberi](https://docs.infradao.com/archive-nodes-101/ethereum/erigon/docker)                                                                                                                                                                                                                      | Yüksek saat hızı, çekirdek sayısından daha önemlidir<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >=3TB (NVMe önerilir)<br /> _son güncelleme Ağustos 2023_ |          ✅          |
+| Fantom    | [Docker Rehberi](https://docs.infradao.com/archive-nodes-101/fantom/docker)                                                                                                                                                                                                                               | 4 çekirdekli / 8 iş parçacıklı CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 13 TiB NVMe SSD<br /> _son güncelleme Ağustos 2023_                      |          ✅          |
+| Gnosis    | [Baremetal Rehberi](https://docs.infradao.com/archive-nodes-101/gnosis/erigon/baremetal)                                                                                                                                                                                                                  | 6 çekirdekli / 12 iş parçacıklı CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 3 TiB NVMe SSD<br /> _son güncelleme Ağustos 2023_                      |          ✅          |
+| Linea     | [Baremetal Rehberi](https://docs.infradao.com/archive-nodes-101/linea/baremetal)                                                                                                                                                                                                                          | 4+ çekirdekli CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _son güncelleme 2 Nisan 2024_                                        |          ✅          |
+| Optimism  | [Erigon Baremetal Rehberi](https://docs.infradao.com/archive-nodes-101/optimism/erigon/baremetal)<br /><br /> [GETH Baremetal Rehberi](https://docs.infradao.com/archive-nodes-101/optimism/geth/baremetal)<br /> [GETH Docker Rehberi](https://docs.infradao.com/archive-nodes-101/optimism/geth/docker) | 4 çekirdekli / 8 iş parçacıklı CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _son güncelleme Ağustos 2023_                       |          ✅          |
+| Polygon   | [Docker Rehberi](https://docs.infradao.com/archive-nodes-101/polygon/docker)                                                                                                                                                                                                                              | 16 çekirdekli CPU<br /> Ubuntu 22.04<br /> 32GB+ RAM<br /> >= 10 TiB NVMe SSD<br /> _son güncelleme Ağustos 2023_                                       |          ✅          |
+| Scroll    | [Baremetal Rehberi](https://docs.infradao.com/archive-nodes-101/scroll/baremetal)<br /> [Docker Rehberi](https://docs.infradao.com/archive-nodes-101/scroll/docker)                                                                                                                                       | 4 çekirdekli / 8 iş parçacıklı CPU<br /> Debian 12<br /> 16GB+ RAM<br /> >= 1 TiB NVMe SSD<br /> _son güncelleme 3 Nisan 2024_                          |          ✅          |

From 6685a6a468d991b03eec3dbae6ec586f7dfd7a4e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 17:31:37 -0500
Subject: [PATCH 3407/3820] New translations publishing-a-subgraph.mdx
 (Turkish)

---
 .../publishing/publishing-a-subgraph.mdx      | 90 +++++++++----------
 1 file changed, 45 insertions(+), 45 deletions(-)

diff --git a/website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
index fae52524322d..153932540a56 100644
--- a/website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
+++ b/website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -1,94 +1,94 @@
 ---
-title: Publishing a Subgraph to the Decentralized Network
+title: Bir Subgraph'i Merkeziyetsiz Ağda Yayımlamak
 ---
 
-Once you have [deployed your subgraph to Subgraph Studio](/deploying/deploying-a-subgraph-to-studio/) and it's ready to go into production, you can publish it to the decentralized network.
+[Subgraph'inizi Subgraph Studio'ya dağıttıktan](/deploying/deploying-a-subgraph-to-studio/) ve üretime hazır hale getirdikten sonra, merkeziyetsiz ağda yayımlayabilirsiniz.
 
-When you publish a subgraph to the decentralized network, you make it available for:
+Bir subgraph'i merkeziyetsiz ağda yayımladığınızda, onu şu amaçlarla kullanılabilir hale getirirsiniz:
 
-- [Curators](/resources/roles/curating/) to begin curating it.
-- [Indexers](/indexing/overview/) to begin indexing it.
+- [Küratörler](/resources/roles/curating/) tarafından kürasyona başlanması.
+- [Endeksleyiciler](/indexing/overview/) tarafından endekslenmeye başlanması.
 
 <VideoEmbed youtube="satdwdbvzAQ" />
 
-Check out the list of [supported networks](/supported-networks/).
+[Desteklenen ağlar](/supported-networks/) listesini inceleyin.
 
-## Publishing from Subgraph Studio
+## Subgraph Studio'dan Yayımlama
 
-1. Go to the [Subgraph Studio](https://thegraph.com/studio/) dashboard
-2. Click on the **Publish** button
-3. Your subgraph will now be visible in [Graph Explorer](https://thegraph.com/explorer/).
+1. [Subgraph Studio](https://thegraph.com/studio/) paneline gidin
+2. **Publish** düğmesine tıklayın
+3. Subgraph'iniz artık [Graph Gezgini](https://thegraph.com/explorer/) içinde görünür olacak.
 
-All published versions of an existing subgraph can:
+Mevcut bir subgraph'in yayımlanmış tüm sürümleri şunları yapabilir:
 
-- Be published to Arbitrum One. [Learn more about The Graph Network on Arbitrum](/archived/arbitrum/arbitrum-faq/).
+- Arbitrum One'da yayımlanabilir. [The Graph Ağı'nın Arbitrum üzerindeki durumu hakkında daha fazla bilgi edinin](/archived/arbitrum/arbitrum-faq/).
 
-- Index data on any of the [supported networks](/supported-networks/), regardless of the network on which the subgraph was published.
+- Subgraph'in yayımlandığı ağdan bağımsız olarak, [desteklenen ağlar](/supported-networks/) üzerindeki herhangi bir ağda veri endeksleyebilir.
 
 ### Yayınlanan bir subgraph için üst veri güncelleme
 
-- After publishing your subgraph to the decentralized network, you can update the metadata anytime in Subgraph Studio.
-- Once you’ve saved your changes and published the updates, they will appear in Graph Explorer.
-- It's important to note that this process will not create a new version since your deployment has not changed.
+- Merkeziyetsiz ağda subgraph'inizi yayımladıktan sonra, Subgraph Studio'da metaveriyi istediğiniz zaman güncelleyebilirsiniz.
+- Yaptığınız değişiklikleri kaydedip güncellemeleri yayımladığınızda, bu güncellemeler Graph Gezgini'nde görünecektir.
+- Dağıtımınız değişmediği için bu işlemin yeni bir sürüm oluşturmayacağını unutmamak önemlidir.
 
-## Publishing from the CLI
+## CLI'den Yayımlama
 
-As of version 0.73.0, you can also publish your subgraph with the [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
+0.73.0 sürümünden itibaren subgraph'inizi [`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) ile de yayımlayabilirsiniz.
 
 1. `graph-cli`yi açın.
-2. Use the following commands: `graph codegen && graph build` then `graph publish`.
-3. A window will open, allowing you to connect your wallet, add metadata, and deploy your finalized subgraph to a network of your choice.
+2. Aşağıdaki komutları kullanın: `graph codegen && graph build` ardından `graph publish`.
+3. Bir pencere açılır ve cüzdanınızı bağlamanıza, metaveri eklemenize ve tamamlanmış subgraph'inizi tercih ettiğiniz bir ağa dağıtmanıza olanak tanır.
 
 ![cli-ui](/img/cli-ui.png)
 
-### Customizing your deployment
+### Dağıtımınızı özelleştirme
 
-You can upload your subgraph build to a specific IPFS node and further customize your deployment with the following flags:
+Aşağıdaki bayraklarla subgraph derlemenizi belirli bir IPFS düğümüne yükleyebilir ve dağıtımınızı daha fazla özelleştirebilirsiniz:
 
 ```
-USAGE
+KULLANIM
   $ graph publish [SUBGRAPH-MANIFEST] [-h] [--protocol-network arbitrum-one|arbitrum-sepolia --subgraph-id <value>] [-i <value>] [--ipfs-hash <value>] [--webapp-url
     <value>]
 
-FLAGS
-  -h, --help                   Show CLI help.
-  -i, --ipfs=<value>           [default: https://api.thegraph.com/ipfs/api/v0] Upload build results to an IPFS node.
-  --ipfs-hash=<value>          IPFS hash of the subgraph manifest to deploy.
-  --protocol-network=<option>  [default: arbitrum-one] The network to use for the subgraph deployment.
+BAYRAKLAR
+  -h, --help                   CLI yardımını gösterir.
+  -i, --ipfs=<value>           [varsayılan: https://api.thegraph.com/ipfs/api/v0] Derleme sonuçlarını bir IPFS düğümüne yükler.
+  --ipfs-hash=<value>          Dağıtılacak subgraph manifestosunun IPFS hash değeri.
+  --protocol-network=<option>  [varsayılan: arbitrum-one] Subgraph dağıtımı için kullanılacak ağı belirtir.
                                <options: arbitrum-one|arbitrum-sepolia>
-  --subgraph-id=<value>        Subgraph ID to publish to.
-  --webapp-url=<value>         [default: https://cli.thegraph.com/publish] URL of the web UI you want to use to deploy.
+  --subgraph-id=<value>        Yayımlanacak subgraph kimliği.
+  --webapp-url=<value>         [varsayılan: https://cli.thegraph.com/publish] Dağıtım için kullanmak istediğiniz web arayüzünün URL'si.
 
 ```
 
-## Adding signal to your subgraph
+## Subgraph'inize sinyal ekleme
 
-Developers can add GRT signal to their subgraphs to incentivize Indexers to query the subgraph.
+Geliştiriciler, Endeksleyicileri bir subgraph'i sorgulamaya teşvik etmek için subgraph'lerine GRT sinyali ekleyebilirler.
 
-- If a subgraph is eligible for indexing rewards, Indexers who provide a "proof of indexing" will receive a GRT reward, based on the amount of GRT signalled.
+- Bir subgraph endeksleme ödüllerine uygun ise, "endeksleme ispatı" sağlayan Endeksleyiciler, sinyallenen GRT miktarına bağlı olarak GRT ödülü alır.
 
-- You can check indexing reward eligibility based on subgraph feature usage [here](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+- Subgraph'inizin endeksleme ödüllerine uygunluğunu (bu, subgraph özellik kullanımına bağlıdır) [buradan](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) kontrol edebilirsiniz.
 
-- Specific supported networks can be checked [here](/supported-networks/).
+- Desteklenen spesifik ağları [buradan](/supported-networks/) inceleyebilirsiniz.
 
-> Adding signal to a subgraph which is not eligible for rewards will not attract additional Indexers.
+> Eğer bir subgraph ödüllere uygun değilse, bu subgraph'e sinyal eklemek ek Endeksleyicileri çekmeyecektir.
 >
-> If your subgraph is eligible for rewards, it is recommended that you curate your own subgraph with at least 3,000 GRT in order to attract additional indexers to index your subgraph.
+> Subgraph'iniz ödüllere uygunsa, subgraph'inizi en az 3.000 GRT ile küratörlüğünü yapmanız, ek Endeksleyicilerin subgraph'inizi endekslemesini sağlamak için önerilir.
 
-The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs. However, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+[Sunrise Yükseltmesi Endeksleyicisi](/archived/sunrise/#what-is-the-upgrade-indexer), tüm subgraph'lerin endekslenmesini sağlar. Ancak, belirli bir subgraph'e GRT sinyali eklemek, daha fazla Endeksleyiciyi bu subgraph'e çekecektir. Küratörlük yoluyla ek Endeksleyicilerin teşvik edilmesi, sorgular için hizmet kalitesini artırmayı, gecikmeyi azaltmayı ve ağ kullanılabilirliğini iyileştirmeyi amaçlar.
 
 When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
 
-Indexers can find subgraphs to index based on curation signals they see in Graph Explorer.
+Endeksleyiciler, Graph Gezgini'nde gördükleri küratörlük sinyallerine göre endeksleyecekleri subgraph'leri bulabilirler.
 
-![Explorer subgraphs](/img/explorer-subgraphs.png)
+![Gezgin subgraph'leri](/img/explorer-subgraphs.png)
 
-Subgraph Studio enables you to add signal to your subgraph by adding GRT to your subgraph's curation pool in the same transaction it is published.
+Subgraph Studio; subgraph'inizi yayımladığınız işlemde, subgraph'inizin küratörlük havuzuna GRT ekleyerek subgraph'inize sinyal eklemenize olanak tanır.
 
-![Curation Pool](/img/curate-own-subgraph-tx.png)
+![Kürasyon Havuzu](/img/curate-own-subgraph-tx.png)
 
-Alternatively, you can add GRT signal to a published subgraph from Graph Explorer.
+Alternatif olarak, yayımlanmış bir subgraph'e Graph Gezgini üzerinden GRT sinyali ekleyebilirsiniz.
 
-![Signal from Explorer](/img/signal-from-explorer.png)
+![Gezgin'den sinyal ekleme](/img/signal-from-explorer.png)
 
-Learn more about [Curating](/resources/roles/curating/) on The Graph Network.
+The Graph Ağı'nda [Küratörlük](/resources/roles/curating/) hakkında daha fazla bilgi edinin.

From be1311563aafd257f3ef898e8808906e7922ea68 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 17:31:38 -0500
Subject: [PATCH 3408/3820] New translations supported-networks.mdx (Turkish)

---
 website/pages/tr/supported-networks.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/tr/supported-networks.mdx b/website/pages/tr/supported-networks.mdx
index b68a3f430b06..073b99982cf5 100644
--- a/website/pages/tr/supported-networks.mdx
+++ b/website/pages/tr/supported-networks.mdx
@@ -9,16 +9,16 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
+\* Temel ağ desteği [yükseltme Endeksleyicisi](https://thegraph.com/blog/upgrade-indexer/) tarafından sağlanmaktadır.\
+\*\* Graph Düğümü ile entegrasyon: `evm`, `near`, `cosmos`, `osmosis` ve `ar`, Graph Düğümü'nde yerel işleyici ve tür desteğine sahiptir. Firehose ve Substreams ile uyumlu zincirler, genelleştirilmiş [Substreams destekli subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) entegrasyonundan yararlanabilir (bu, `evm` ve `near` ağlarını içerir). &#8288;<sup>†</sup> [Substreams destekli subgraph'lerin](/subgraphs/cookbook/substreams-powered-subgraphs/) yayına alınmasını destekler.
 
 - Subgraph Studio, örneğin JSON-RPC, Firehose ve Substreams uç noktaları gibi temel teknolojilerin istikrarlılığına ve güvenilirliğine bel bağlar.
-- Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
+- Gnosis Chain'i endeksleyen subgraph'ler artık `gnosis` ağ tanımlayıcısı ile dağıtılabilir.
 - Bir subgraph CLI aracılığıyla yayımlandıysa ve bir Endeksleyici tarafından algılandıysa, teknik olarak, desteklenmeden de sorgulanabilir. Yeni ağların entegrasyonunu daha da kolaylaştırmak için çalışmalar devam etmektedir.
-- For a full list of which features are supported on the decentralized network, see [this page](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md).
+- Merkeziyetsiz ağda hangi özelliklerin desteklendiğinin tam listesi için [bu sayfayı](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) inceleyin.
 
 ## Graph Düğümünü yerel olarak çalıştırma
 
-If your preferred network isn't supported on The Graph's decentralized network, you can run your own [Graph Node](https://github.com/graphprotocol/graph-node) to index any EVM-compatible network. Make sure that the [version](https://github.com/graphprotocol/graph-node/releases) you are using supports the network and you have the needed configuration.
+Tercih ettiğiniz ağ The Graph'ın merkeziyetsiz ağında desteklenmiyorsa, kendi [Graph Düğümünüzü](https://github.com/graphprotocol/graph-node) çalıştırarak herhangi bir EVM uyumlu ağı endeksleyebilirsiniz. Kullandığınız [sürümün](https://github.com/graphprotocol/graph-node/releases) ağı desteklediğinden ve gerekli yapılandırmaya sahip olduğunuzdan emin olun.
 
 Graph Düğümü, Firehose entegrasyonu aracılığıyla diğer protokolleri de endeksleyebilir. NEAR, Arweave ve Cosmos tabanlı ağlar için Firehose entegrasyonları oluşturulmuştur. Ayrıca, Graph Düğümü, Substreams desteğine sahip herhangi bir ağ için Substreams destekli subgraph'leri de destekleyebilir.

From 073c7a7ec4f49464cf0a3975f4657c967c68bbae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 18:47:39 -0500
Subject: [PATCH 3409/3820] New translations derivedfrom.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/derivedfrom.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
index 89c3683e137e..9de67dadeae6 100644
--- a/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
@@ -57,21 +57,21 @@ type Comment @entity {
 }
 ```
 
-Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+Sadece `@derivedFrom` yönergesini ekleyerek bu şema, ilişkinin “Post” tarafında değil, yalnızca “Comments” tarafında “Comments” verilerini depolamış olur. Diziler bireysel satırlara yayıldığı için önemli ölçüde genişleyebilir. Bu durum, büyüme sınırsız olduğunda büyük boyutlara yol açabilir.
 
-This will not only make our subgraph more efficient, but it will also unlock three features:
+Bu yalnızca subgraph'imizi daha verimli hale getirmekle kalmayacak, aynı zamanda şu üç özelliği de kullanmamıza olanak tanıyacaktır:
 
-1. We can query the `Post` and see all of its comments.
+1. `Post`'u sorgulayarak tüm yorumlarını görebiliriz.
 
-2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+2. Herhangi bir `Comment`'te tersine arama yapabilir ve hangi gönderiden geldiğini sorgulayabiliriz.
 
 3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
 
 ## Sonuç
 
-Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+`@derivedFrom` direktifini subgraph'lerde dinamik olarak büyüyen dizileri etkili bir şekilde yönetmek için kullanın. Bu direktif endeksleme verimliliğini ve veri alımını artırır.
 
-For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+Büyük dizilerden kaçınma stratejilerinin daha ayrıntılı bir açıklaması için Kevin Jones'un blog yazısına göz atın: [Subgraph Geliştiriminde Örnek Uygulamalar: Büyük Dize Kümelerinden Kaçınmak](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
 
 ## Subgraph Örnek Uygulamalar 1-6
 

From f9619bb2f338f65b140d96bf0e21d3a796cb18ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 18:47:40 -0500
Subject: [PATCH 3410/3820] New translations enums.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/enums.mdx | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/enums.mdx b/website/pages/tr/subgraphs/cookbook/enums.mdx
index 99d1a01a02c0..36260c8a299f 100644
--- a/website/pages/tr/subgraphs/cookbook/enums.mdx
+++ b/website/pages/tr/subgraphs/cookbook/enums.mdx
@@ -1,20 +1,20 @@
 ---
-title: Categorize NFT Marketplaces Using Enums
+title: NFT Pazar Yerlerini Enums Kullanarak Kategorize Etme
 ---
 
-Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+Kodu daha temiz yapmak ve hata yapma riskini azaltmak için Enums kullanın. İşte NFT pazar yerlerinde Enums kullanımına bir örnek.
 
-## What are Enums?
+## Enum'lar Nedir?
 
-Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+Enum'lar veya numaralandırma türleri, bir dizi izin verilen değeri tanımlamanıza olanak tanıyan belirli bir veri türüdür.
 
-### Example of Enums in Your Schema
+### Şemanızda Enum Örnekleri
 
-If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+Bir pazar yerinde token sahiplik geçmişini izlemek için bir subgraph oluşturuyorsanız, her token `OriginalOwner`, `SecondOwner` ve `ThirdOwner` gibi farklı sahipliklerden geçebilir. Enum'ları kullanarak, bu belirli sahiplikleri tanımlayabilir ve yalnızca önceden tanımlanmış değerlerin atanmasını sağlayabilirsiniz.
 
-You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+Şemanızda enum tanımlayabilir ve bir kez tanımlandığında, bir varlık üzerinde bir enum alanı ayarlamak için enum değerlerinin dizi (string) gösterimini kullanabilirsiniz.
 
-Here's what an enum definition might look like in your schema, based on the example above:
+İşte yukarıdaki örneğe dayanarak, şemanızda bir enum tanımı şöyle görünebilir:
 
 ```graphql
 enum TokenStatus {

From 1576f3a98350d6c2d4351a1251aa01e3af8bd5db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:16:16 -0500
Subject: [PATCH 3411/3820] New translations supported-networks.mdx
 (Portuguese)

---
 website/pages/pt/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/pt/supported-networks.mdx b/website/pages/pt/supported-networks.mdx
index 7eca2705248f..64beb3dae27e 100644
--- a/website/pages/pt/supported-networks.mdx
+++ b/website/pages/pt/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - O Subgraph Studio depende da estabilidade e da confiança das tecnologias subjacentes, por exemplo, JSON-RPC, Firehose e endpoints dos Substreams.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - Se um subgraph foi publicado via a CLI e visto por um Indexador, ele pode tecnicamente ser consultado mesmo sem apoio, e esforços estão a ser feitos para simplificar ainda mais a integração de novas redes.

From be64d49668329d09e48b52627a95aad94d0cc606 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:16:17 -0500
Subject: [PATCH 3412/3820] New translations supported-networks.json
 (Portuguese)

---
 website/pages/pt/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/pt/supported-networks.json b/website/pages/pt/supported-networks.json
index c491ed0859d2..e2dea040d6f6 100644
--- a/website/pages/pt/supported-networks.json
+++ b/website/pages/pt/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Rede",
-  "cliName": "Nome na CLI",
-  "chainId": "ID da Chain",
-  "hostedService": "Serviço Hospedado",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Rede Descentralizada",
-  "integrationType": "Tipo de Integração"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgraphs",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From 67a9f14f2196c44b345d4d3660224db2e6e7392b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:17:35 -0500
Subject: [PATCH 3413/3820] New translations supported-networks.json (Chinese
 Simplified)

---
 website/pages/zh/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/zh/supported-networks.json b/website/pages/zh/supported-networks.json
index 1c262b09c338..46d5ed32a086 100644
--- a/website/pages/zh/supported-networks.json
+++ b/website/pages/zh/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "网络",
-  "cliName": "CLI名字",
-  "chainId": "链id",
-  "hostedService": "托管服务",
-  "subgraphStudio": "子图工作室",
-  "decentralizedNetwork": "去中心化网络",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "子图",
+  "substreams": "子流",
+  "firehose": "Firehose"
 }

From 8fe5cdcf7d99d98897842ca45f09d3afc9007eff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:18:44 -0500
Subject: [PATCH 3414/3820] New translations supported-networks.mdx (Romanian)

---
 website/pages/ro/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/ro/supported-networks.mdx b/website/pages/ro/supported-networks.mdx
index f77b19356ab0..fa09b75ff95e 100644
--- a/website/pages/ro/supported-networks.mdx
+++ b/website/pages/ro/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From 01f0d7232065fa233a9deb585465715a8c3f50d9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:18:45 -0500
Subject: [PATCH 3415/3820] New translations supported-networks.json (Romanian)

---
 website/pages/ro/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/ro/supported-networks.json b/website/pages/ro/supported-networks.json
index 7b7376b2fbd7..bb0668c977c5 100644
--- a/website/pages/ro/supported-networks.json
+++ b/website/pages/ro/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Network",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Serviciu găzduit",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgrafuri",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From b1503e3c808bf627a0259702ab48a4535787d550 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:19:12 -0500
Subject: [PATCH 3416/3820] New translations supported-networks.mdx (French)

---
 website/pages/fr/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/fr/supported-networks.mdx b/website/pages/fr/supported-networks.mdx
index be1a17d72c97..3daed2bd998d 100644
--- a/website/pages/fr/supported-networks.mdx
+++ b/website/pages/fr/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio repose sur la stabilité et la fiabilité des technologies sous-jacentes, comme les endpoints JSON-RPC, Firehose et Substreams.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - Si un subgraph a été publié via la CLI et repris par un Indexer, il pourrait techniquement être interrogé même sans support, et des efforts sont en cours pour simplifier davantage l'intégration de nouveaux réseaux.

From d9774dc9d6dc51c0b00299d5fea02f4bab1767b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:19:13 -0500
Subject: [PATCH 3417/3820] New translations supported-networks.json (French)

---
 website/pages/fr/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/fr/supported-networks.json b/website/pages/fr/supported-networks.json
index dd6bbee71dc6..e2dea040d6f6 100644
--- a/website/pages/fr/supported-networks.json
+++ b/website/pages/fr/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Réseau",
-  "cliName": "Nom du CLI",
-  "chainId": "ID de la chaîne",
-  "hostedService": "Service hébergé",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Réseau décentralisé",
-  "integrationType": "Type d'intégration"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgraphs",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From 9e8c6dc706eb12d4a31ffc1c538ce1ebda6cbcfe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:19:46 -0500
Subject: [PATCH 3418/3820] New translations supported-networks.mdx (Spanish)

---
 website/pages/es/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/es/supported-networks.mdx b/website/pages/es/supported-networks.mdx
index edb1f88033f8..801ebe960fcc 100644
--- a/website/pages/es/supported-networks.mdx
+++ b/website/pages/es/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From efc6a189bf3e2c0070b4efd773f931b442ca7743 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:19:47 -0500
Subject: [PATCH 3419/3820] New translations supported-networks.json (Spanish)

---
 website/pages/es/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/es/supported-networks.json b/website/pages/es/supported-networks.json
index 2fc7f4852383..2a2714cf9f30 100644
--- a/website/pages/es/supported-networks.json
+++ b/website/pages/es/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Red",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Servicio Alojado",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgrafos",
+  "substreams": "Corrientes secundarias",
+  "firehose": "Firehose"
 }

From df109ff13d1d190a8a222613472b4adc88e68e6a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:20:23 -0500
Subject: [PATCH 3420/3820] New translations supported-networks.mdx (Arabic)

---
 website/pages/ar/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/ar/supported-networks.mdx b/website/pages/ar/supported-networks.mdx
index ef8f1ad42132..8e9ca0691488 100644
--- a/website/pages/ar/supported-networks.mdx
+++ b/website/pages/ar/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From d98ad3fbbd46cc22c09161dba64106e0127fb9f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:20:24 -0500
Subject: [PATCH 3421/3820] New translations supported-networks.json (Arabic)

---
 website/pages/ar/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/ar/supported-networks.json b/website/pages/ar/supported-networks.json
index 3ef903c77b7c..20bad6b5fa26 100644
--- a/website/pages/ar/supported-networks.json
+++ b/website/pages/ar/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Network",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "الخدمة المستضافة (Hosted Service)",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgraphs",
+  "substreams": "متعدد-السلاسل",
+  "firehose": "Firehose"
 }

From b6bbfe4b6b8ca7b75be9543783b848e3690e10d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:20:58 -0500
Subject: [PATCH 3422/3820] New translations supported-networks.mdx (Czech)

---
 website/pages/cs/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/cs/supported-networks.mdx b/website/pages/cs/supported-networks.mdx
index 3bf1d3af3844..0f9f90e7fdb1 100644
--- a/website/pages/cs/supported-networks.mdx
+++ b/website/pages/cs/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From 70afaf5d99d609a305aca198f9ff876f5db4173d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:20:59 -0500
Subject: [PATCH 3423/3820] New translations supported-networks.json (Czech)

---
 website/pages/cs/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/cs/supported-networks.json b/website/pages/cs/supported-networks.json
index 2cda540608cf..ae82e7b0fcbb 100644
--- a/website/pages/cs/supported-networks.json
+++ b/website/pages/cs/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Síť",
-  "cliName": "Název CLI",
-  "chainId": "ID řetězce",
-  "hostedService": "Hostovaná služba",
-  "subgraphStudio": "Podgraf Studio",
-  "decentralizedNetwork": "Decentralizovaná síť",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Podgrafy",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From 41495c1c129c067b337719152a7af0e3d207edcc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:21:35 -0500
Subject: [PATCH 3424/3820] New translations supported-networks.mdx (German)

---
 website/pages/de/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/de/supported-networks.mdx b/website/pages/de/supported-networks.mdx
index b4e30306d439..93fe0654bcae 100644
--- a/website/pages/de/supported-networks.mdx
+++ b/website/pages/de/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From ace6117120e808e0c079d139c520ca23fbf70027 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:21:36 -0500
Subject: [PATCH 3425/3820] New translations supported-networks.json (German)

---
 website/pages/de/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/de/supported-networks.json b/website/pages/de/supported-networks.json
index f03e5820151a..e2dea040d6f6 100644
--- a/website/pages/de/supported-networks.json
+++ b/website/pages/de/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Netzwerk",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Hosted Service",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgraphs",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From 3c9ce2d9397631ffe205856c81894516936b36db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:22:11 -0500
Subject: [PATCH 3426/3820] New translations supported-networks.mdx (Italian)

---
 website/pages/it/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/it/supported-networks.mdx b/website/pages/it/supported-networks.mdx
index b4e30306d439..93fe0654bcae 100644
--- a/website/pages/it/supported-networks.mdx
+++ b/website/pages/it/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From f32fedf4c646310110c0db5fd2ba68c17af6aca1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:22:12 -0500
Subject: [PATCH 3427/3820] New translations supported-networks.json (Italian)

---
 website/pages/it/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/it/supported-networks.json b/website/pages/it/supported-networks.json
index 6fe6b7a50217..e2dea040d6f6 100644
--- a/website/pages/it/supported-networks.json
+++ b/website/pages/it/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "La rete",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Hosted Service",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgraphs",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From c8b9a3068573af9edb6e6b330560473b39aca30f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:22:47 -0500
Subject: [PATCH 3428/3820] New translations supported-networks.mdx (Japanese)

---
 website/pages/ja/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/ja/supported-networks.mdx b/website/pages/ja/supported-networks.mdx
index f34a6442d225..24013f8e828b 100644
--- a/website/pages/ja/supported-networks.mdx
+++ b/website/pages/ja/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From 064182d274fd73cbdf2df97e7af6a352f98a2cb8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:22:48 -0500
Subject: [PATCH 3429/3820] New translations supported-networks.json (Japanese)

---
 website/pages/ja/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/ja/supported-networks.json b/website/pages/ja/supported-networks.json
index 97aca55c7ea5..b545e3d4f916 100644
--- a/website/pages/ja/supported-networks.json
+++ b/website/pages/ja/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "ネットワーク",
-  "cliName": "CLI名",
-  "chainId": "チェーンID",
-  "hostedService": "ホステッド サービス",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "分散型ネットワーク",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "サブグラフ",
+  "substreams": "サブストリーム",
+  "firehose": "Firehose"
 }

From 66449d725413f6836ef4ea375c97dbc8c2d25edd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:23:25 -0500
Subject: [PATCH 3430/3820] New translations supported-networks.mdx (Korean)

---
 website/pages/ko/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/ko/supported-networks.mdx b/website/pages/ko/supported-networks.mdx
index b4e30306d439..93fe0654bcae 100644
--- a/website/pages/ko/supported-networks.mdx
+++ b/website/pages/ko/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From 6505eccfe05060112f2ba3a73a09279c315bb6d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:23:26 -0500
Subject: [PATCH 3431/3820] New translations supported-networks.json (Korean)

---
 website/pages/ko/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/ko/supported-networks.json b/website/pages/ko/supported-networks.json
index 9ae5a4b5aae8..e2dea040d6f6 100644
--- a/website/pages/ko/supported-networks.json
+++ b/website/pages/ko/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Network",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Hosted Service",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgraphs",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From b8863b93a5e5bc1443a0390a44183ae53702abe8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:24:07 -0500
Subject: [PATCH 3432/3820] New translations supported-networks.mdx (Dutch)

---
 website/pages/nl/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/nl/supported-networks.mdx b/website/pages/nl/supported-networks.mdx
index 68bcc2bf8d78..8935a9f46d05 100644
--- a/website/pages/nl/supported-networks.mdx
+++ b/website/pages/nl/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From bb70d29d0e9ee74491bb16bac3c6cf4b57fe878a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:24:08 -0500
Subject: [PATCH 3433/3820] New translations supported-networks.json (Dutch)

---
 website/pages/nl/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/nl/supported-networks.json b/website/pages/nl/supported-networks.json
index 659095d1b81d..e2dea040d6f6 100644
--- a/website/pages/nl/supported-networks.json
+++ b/website/pages/nl/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Netwerk",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Gehoste Dienst",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgraphs",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From ec2ff445a0a6ce39828b4a9e9f46de2981ee6973 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:24:42 -0500
Subject: [PATCH 3434/3820] New translations supported-networks.mdx (Polish)

---
 website/pages/pl/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/pl/supported-networks.mdx b/website/pages/pl/supported-networks.mdx
index 8b8ed4b132a0..c181685a1533 100644
--- a/website/pages/pl/supported-networks.mdx
+++ b/website/pages/pl/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From 8380b5645d88008a7d949be4a0740dbc804fdef0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:24:43 -0500
Subject: [PATCH 3435/3820] New translations supported-networks.json (Polish)

---
 website/pages/pl/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/pl/supported-networks.json b/website/pages/pl/supported-networks.json
index 9ae5a4b5aae8..6201797ba8cd 100644
--- a/website/pages/pl/supported-networks.json
+++ b/website/pages/pl/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Network",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Hosted Service",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgrafy",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From 56eedbcc7cead4c1a4c8a1b1ce5d186b0212facf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:25:14 -0500
Subject: [PATCH 3436/3820] New translations supported-networks.mdx (Russian)

---
 website/pages/ru/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/ru/supported-networks.mdx b/website/pages/ru/supported-networks.mdx
index 50016fc0ecbf..882ca68a80e7 100644
--- a/website/pages/ru/supported-networks.mdx
+++ b/website/pages/ru/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio полагается на стабильность и надежность базовых технологий, например, таких, как JSON-RPC, Firehose и конечных точек Substreams.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - Если субграф был опубликован через CLI и выбран индексатором, технически его можно было бы запросить даже без поддержки, и в настоящее время предпринимаются усилия для упрощения интеграции новых сетей.

From 308779ab4ee6dda302d7952fee0d122564155cd3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:25:15 -0500
Subject: [PATCH 3437/3820] New translations supported-networks.json (Russian)

---
 website/pages/ru/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/ru/supported-networks.json b/website/pages/ru/supported-networks.json
index 452617529078..2a11f68ef9a8 100644
--- a/website/pages/ru/supported-networks.json
+++ b/website/pages/ru/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Сеть",
-  "cliName": "Название CLI",
-  "chainId": "ID чейна",
-  "hostedService": "Hosted Service",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Децентрализованная сеть",
-  "integrationType": "Тип интеграции"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Субграфы",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From af2ad22afcfa3f234a91c0c9156d974e34618629 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:25:48 -0500
Subject: [PATCH 3438/3820] New translations supported-networks.mdx (Swedish)

---
 website/pages/sv/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/sv/supported-networks.mdx b/website/pages/sv/supported-networks.mdx
index e20745df9b0b..d541fffb17f8 100644
--- a/website/pages/sv/supported-networks.mdx
+++ b/website/pages/sv/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From 8c185cb65d8aea478782469907d6f743a8f47a19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:25:49 -0500
Subject: [PATCH 3439/3820] New translations supported-networks.json (Swedish)

---
 website/pages/sv/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/sv/supported-networks.json b/website/pages/sv/supported-networks.json
index 37c7894ca8a0..1c79e2f2a36b 100644
--- a/website/pages/sv/supported-networks.json
+++ b/website/pages/sv/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Nätverk",
-  "cliName": "Kommandoradsgränssnitt namn",
-  "chainId": "Kedje-ID",
-  "hostedService": "Värdtjänster",
-  "subgraphStudio": "Subgraf Studion",
-  "decentralizedNetwork": "Decentraliserat Nätverk",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgrafer",
+  "substreams": "Underströmmar",
+  "firehose": "Firehose"
 }

From 08713632a50475401c3c22da2cd3b5251e2ef8d0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:26:17 -0500
Subject: [PATCH 3440/3820] New translations supported-networks.mdx (Turkish)

---
 website/pages/tr/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/tr/supported-networks.mdx b/website/pages/tr/supported-networks.mdx
index 073b99982cf5..f6c7652eaba5 100644
--- a/website/pages/tr/supported-networks.mdx
+++ b/website/pages/tr/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Temel ağ desteği [yükseltme Endeksleyicisi](https://thegraph.com/blog/upgrade-indexer/) tarafından sağlanmaktadır.\
-\*\* Graph Düğümü ile entegrasyon: `evm`, `near`, `cosmos`, `osmosis` ve `ar`, Graph Düğümü'nde yerel işleyici ve tür desteğine sahiptir. Firehose ve Substreams ile uyumlu zincirler, genelleştirilmiş [Substreams destekli subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) entegrasyonundan yararlanabilir (bu, `evm` ve `near` ağlarını içerir). &#8288;<sup>†</sup> [Substreams destekli subgraph'lerin](/subgraphs/cookbook/substreams-powered-subgraphs/) yayına alınmasını destekler.
-
 - Subgraph Studio, örneğin JSON-RPC, Firehose ve Substreams uç noktaları gibi temel teknolojilerin istikrarlılığına ve güvenilirliğine bel bağlar.
 - Gnosis Chain'i endeksleyen subgraph'ler artık `gnosis` ağ tanımlayıcısı ile dağıtılabilir.
 - Bir subgraph CLI aracılığıyla yayımlandıysa ve bir Endeksleyici tarafından algılandıysa, teknik olarak, desteklenmeden de sorgulanabilir. Yeni ağların entegrasyonunu daha da kolaylaştırmak için çalışmalar devam etmektedir.

From 8797cf52632655eb8898b7073f55a7891aed11a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:26:18 -0500
Subject: [PATCH 3441/3820] New translations supported-networks.json (Turkish)

---
 website/pages/tr/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/tr/supported-networks.json b/website/pages/tr/supported-networks.json
index 12a54cd5f729..f25e3d970245 100644
--- a/website/pages/tr/supported-networks.json
+++ b/website/pages/tr/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Ağ",
-  "cliName": "CLI Adı",
-  "chainId": "Zincir Kimliği",
-  "hostedService": "Barındırılan hizmet",
-  "subgraphStudio": "Subgraph Stüdyosu",
-  "decentralizedNetwork": "Merkeziyetsiz Ağ",
-  "integrationType": "Entegrasyon Türü"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgraph'ler",
+  "substreams": "Substream'ler",
+  "firehose": "Firehose"
 }

From ca45b66464477224f0cb430e17a8406bf8fa8fd5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:26:52 -0500
Subject: [PATCH 3442/3820] New translations supported-networks.mdx (Ukrainian)

---
 website/pages/uk/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/uk/supported-networks.mdx b/website/pages/uk/supported-networks.mdx
index 8a619b76b8c4..74acf18eb6fd 100644
--- a/website/pages/uk/supported-networks.mdx
+++ b/website/pages/uk/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From d54ba3c9784486c6624eb2b46363f4a8d4a31e15 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:26:53 -0500
Subject: [PATCH 3443/3820] New translations supported-networks.json
 (Ukrainian)

---
 website/pages/uk/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/uk/supported-networks.json b/website/pages/uk/supported-networks.json
index db061a68623a..bfc32265e049 100644
--- a/website/pages/uk/supported-networks.json
+++ b/website/pages/uk/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Network",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Хостинговий сервіс",
-  "subgraphStudio": "Субграф Студія",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Підграфи",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From c1a0443a576fff0d1746f9b6ba92b575e0d54ec3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:27:20 -0500
Subject: [PATCH 3444/3820] New translations supported-networks.mdx (Chinese
 Simplified)

---
 website/pages/zh/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/zh/supported-networks.mdx b/website/pages/zh/supported-networks.mdx
index 41fe184776a6..a0456d08fdd7 100644
--- a/website/pages/zh/supported-networks.mdx
+++ b/website/pages/zh/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From 23a8feeec1c3f092ef9431444a9247eedddf8385 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:27:54 -0500
Subject: [PATCH 3445/3820] New translations supported-networks.mdx (Urdu
 (Pakistan))

---
 website/pages/ur/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/ur/supported-networks.mdx b/website/pages/ur/supported-networks.mdx
index d6c795fbdf90..d6b3d2b0f981 100644
--- a/website/pages/ur/supported-networks.mdx
+++ b/website/pages/ur/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From bdaef735228cb59835c3adbbc125b34bf9824962 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:27:55 -0500
Subject: [PATCH 3446/3820] New translations supported-networks.json (Urdu
 (Pakistan))

---
 website/pages/ur/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/ur/supported-networks.json b/website/pages/ur/supported-networks.json
index 1db47456c314..2f53351f7719 100644
--- a/website/pages/ur/supported-networks.json
+++ b/website/pages/ur/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "نیٹ ورک",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Hosted Service",
-  "subgraphStudio": "سب گراف سٹوڈیو",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "سب گراف",
+  "substreams": "سب سٹریمز",
+  "firehose": "Firehose"
 }

From 3ee6cdbf5d4cb9ec5f369511adf8a70d5288dcc3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:28:28 -0500
Subject: [PATCH 3447/3820] New translations supported-networks.mdx
 (Vietnamese)

---
 website/pages/vi/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/vi/supported-networks.mdx b/website/pages/vi/supported-networks.mdx
index 22b22a409b76..6aa70cac698b 100644
--- a/website/pages/vi/supported-networks.mdx
+++ b/website/pages/vi/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From ee3462c3e44013b1761dd8f62c23825d735927cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:28:29 -0500
Subject: [PATCH 3448/3820] New translations supported-networks.json
 (Vietnamese)

---
 website/pages/vi/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/vi/supported-networks.json b/website/pages/vi/supported-networks.json
index 1f754354dd99..e2dea040d6f6 100644
--- a/website/pages/vi/supported-networks.json
+++ b/website/pages/vi/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Mạng lưới",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Dịch vụ được lưu trữ",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgraphs",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From 471cf91ef07ae683c2a2c0989e70af11dc09c694 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:29:02 -0500
Subject: [PATCH 3449/3820] New translations supported-networks.mdx (Marathi)

---
 website/pages/mr/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/mr/supported-networks.mdx b/website/pages/mr/supported-networks.mdx
index b4e30306d439..93fe0654bcae 100644
--- a/website/pages/mr/supported-networks.mdx
+++ b/website/pages/mr/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From 3b8bbc040a68068fdccc4160fcc685cf70b5ecae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:29:03 -0500
Subject: [PATCH 3450/3820] New translations supported-networks.json (Marathi)

---
 website/pages/mr/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/mr/supported-networks.json b/website/pages/mr/supported-networks.json
index 9ae5a4b5aae8..b94e91f6a050 100644
--- a/website/pages/mr/supported-networks.json
+++ b/website/pages/mr/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Network",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Hosted Service",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "सबग्राफ",
+  "substreams": "उपप्रवाह",
+  "firehose": "फायरहोस"
 }

From 05357c78cc178ff0061a089dad27c408af281452 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:29:36 -0500
Subject: [PATCH 3451/3820] New translations supported-networks.mdx (Hindi)

---
 website/pages/hi/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/hi/supported-networks.mdx b/website/pages/hi/supported-networks.mdx
index c4c73324cd45..1b86b678648c 100644
--- a/website/pages/hi/supported-networks.mdx
+++ b/website/pages/hi/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - सबग्राफ स्टूडियो निर्भर करता है अंतर्निहित प्रौद्योगिकियों की स्थिरता और विश्वसनीयता पर, जैसे JSON-RPC, फायरहोस और सबस्ट्रीम्स एंडपॉइंट्स।
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From 3a51dc4484f60fa33aa01759afa022bcc78d7b40 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:29:37 -0500
Subject: [PATCH 3452/3820] New translations supported-networks.json (Hindi)

---
 website/pages/hi/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/hi/supported-networks.json b/website/pages/hi/supported-networks.json
index ac3bb6f048e9..ccbcdaebb037 100644
--- a/website/pages/hi/supported-networks.json
+++ b/website/pages/hi/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "नेटवर्क",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Hosted Service",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "सबग्राफ",
+  "substreams": "सबस्ट्रीम",
+  "firehose": "Firehose"
 }

From 3d031dd265a78281afca1bf780e231a0e5514ce4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:30:32 -0500
Subject: [PATCH 3453/3820] New translations supported-networks.mdx (Swahili)

---
 website/pages/sw/supported-networks.mdx | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/website/pages/sw/supported-networks.mdx b/website/pages/sw/supported-networks.mdx
index b4e30306d439..93fe0654bcae 100644
--- a/website/pages/sw/supported-networks.mdx
+++ b/website/pages/sw/supported-networks.mdx
@@ -9,9 +9,6 @@ export const getStaticProps = getStaticPropsForSupportedNetworks(__filename)
 
 <SupportedNetworksTable networks={props.networks} />
 
-\* Baseline network support provided by the [upgrade Indexer](https://thegraph.com/blog/upgrade-indexer/).\
-\*\* Integration with Graph Node: `evm`, `near`, `cosmos`, `osmosis` and `ar` have native handler and type support in Graph Node. Chains which are Firehose- and Substreams-compatible can leverage the generalised [Substreams-powered subgraph](/subgraphs/cookbook/substreams-powered-subgraphs/) integration (this includes `evm` and `near` networks). &#8288;<sup>†</sup> Supports deployment of [Substreams-powered subgraphs](/subgraphs/cookbook/substreams-powered-subgraphs/).
-
 - Subgraph Studio relies on the stability and reliability of the underlying technologies, for example JSON-RPC, Firehose and Substreams endpoints.
 - Subgraphs indexing Gnosis Chain can now be deployed with the `gnosis` network identifier.
 - If a subgraph was published via the CLI and picked up by an Indexer, it could technically be queried even without support, and efforts are underway to further streamline integration of new networks.

From 3ce28501a217c9b087b81644447c62542c425527 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 31 Jan 2025 20:30:33 -0500
Subject: [PATCH 3454/3820] New translations supported-networks.json (Swahili)

---
 website/pages/sw/supported-networks.json | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/website/pages/sw/supported-networks.json b/website/pages/sw/supported-networks.json
index 9ae5a4b5aae8..e2dea040d6f6 100644
--- a/website/pages/sw/supported-networks.json
+++ b/website/pages/sw/supported-networks.json
@@ -1,9 +1,7 @@
 {
-  "network": "Network",
-  "cliName": "CLI Name",
-  "chainId": "Chain ID",
-  "hostedService": "Hosted Service",
-  "subgraphStudio": "Subgraph Studio",
-  "decentralizedNetwork": "Decentralized Network",
-  "integrationType": "Integration Type"
+  "name": "Name",
+  "id": "ID",
+  "subgraphs": "Subgraphs",
+  "substreams": "Substreams",
+  "firehose": "Firehose"
 }

From 994d0e00cfac65f092522d01ddbfdd8a0254e756 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 05:33:06 -0500
Subject: [PATCH 3455/3820] New translations graph-node.mdx (German)

---
 .../pages/de/indexing/tooling/graph-node.mdx  | 30 +++++++++----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/de/indexing/tooling/graph-node.mdx b/website/pages/de/indexing/tooling/graph-node.mdx
index 3ecedb43a350..24d95037bbe7 100644
--- a/website/pages/de/indexing/tooling/graph-node.mdx
+++ b/website/pages/de/indexing/tooling/graph-node.mdx
@@ -245,7 +245,7 @@ Das Indexer Repository bietet eine [Beispiel-Grafana-Konfiguration](https://gith
 
 Der Befehl graphman ist in den offiziellen Containern enthalten, und Sie können ihn mit docker exec in Ihrem graph-node-Container ausführen. Er erfordert eine Datei `config.toml`.
 
-Full documentation of `graphman` commands is available in the Graph Node repository. See [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+Eine vollständige Dokumentation der `graphman`-Befehle ist im Graph Node Repository verfügbar. Siehe [/docs/graphman.md] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) im Graph Node `/docs`
 
 ### Working with subgraphs
 
@@ -253,7 +253,7 @@ Full documentation of `graphman` commands is available in the Graph Node reposit
 
 Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
 
-The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+Das vollständige Schema ist [hier] verfügbar (https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
 
 #### Indexing performance
 
@@ -267,8 +267,8 @@ These stages are pipelined (i.e. they can be executed in parallel), but they are
 
 Common causes of indexing slowness:
 
-- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
-- Making large numbers of `eth_calls` as part of handlers
+- Zeit, die benötigt wird, um relevante Ereignisse aus der Kette zu finden (insbesondere Call-Handler können langsam sein, da sie auf `trace_filter` angewiesen sind)
+- Durchführen einer großen Anzahl von „eth_calls“ als Teil von Handlern
 - A large amount of store interaction during execution
 - A large amount of data to save to the store
 - A large number of events to process
@@ -287,19 +287,19 @@ During indexing subgraphs might fail, if they encounter data that is unexpected,
 
 In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
 
-> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-deterministic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+> Deterministische Fehler werden als „endgültig“ betrachtet, wobei für den fehlgeschlagenen Block ein Indizierungsnachweis generiert wird, während nicht-deterministische Fehler nicht als solche betrachtet werden, da es dem Subgraph gelingen kann, „auszufallen“ und die Indizierung fortzusetzen. In einigen Fällen ist das nicht-deterministische Label falsch und der Subgraph wird den Fehler nie überwinden; solche Fehler sollten als Probleme im Graph Node Repository gemeldet werden.
 
 #### Block and call cache
 
-Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+Graph Node speichert bestimmte Daten im Zwischenspeicher, um ein erneutes Abrufen vom Anbieter zu vermeiden. Blöcke werden zwischengespeichert, ebenso wie die Ergebnisse von `eth_calls` (letztere werden ab einem bestimmten Block zwischengespeichert). Diese Zwischenspeicherung kann die Indizierungsgeschwindigkeit bei der „Neusynchronisierung“ eines geringfügig veränderten Subgraphen drastisch erhöhen.
 
-However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+Wenn jedoch ein Ethereum-Knoten über einen bestimmten Zeitraum falsche Daten geliefert hat, können diese in den Cache gelangen und zu falschen Daten oder fehlgeschlagenen Subgraphen führen. In diesem Fall können Indexer `graphman` verwenden, um den vergifteten Cache zu löschen und dann die betroffenen Subgraphen zurückzuspulen, die dann frische Daten von dem (hoffentlich) gesunden Anbieter abrufen.
 
 If a block cache inconsistency is suspected, such as a tx receipt missing event:
 
-1. `graphman chain list` to find the chain name.
-2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
-   1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate <CHAIN>`.
+1. `graphman chain list`, um den Namen der Kette zu finden.
+2. `graphman chain check-blocks <CHAIN> by-number <NUMBER>` prüft, ob der zwischengespeicherte Block mit dem Anbieter übereinstimmt, und löscht den Block aus dem Cache, wenn dies nicht der Fall ist.
+   1. Wenn es einen Unterschied gibt, kann es sicherer sein, den gesamten Cache mit `graphman chain truncate <CHAIN>` abzuschneiden.
    2. If the block matches the provider, then the issue can be debugged directly against the provider.
 
 #### Querying issues and errors
@@ -312,7 +312,7 @@ There is not one "silver bullet", but a range of tools for preventing, diagnosin
 
 ##### Query caching
 
-Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+Graph Node zwischenspeichert GraphQL-Abfragen standardmäßig, was die Datenbanklast erheblich reduzieren kann. Dies kann mit den Einstellungen `GRAPH_QUERY_CACHE_BLOCKS` und `GRAPH_QUERY_CACHE_MAX_MEM` weiter konfiguriert werden - lesen Sie mehr [hier](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
 
 ##### Analysing queries
 
@@ -320,7 +320,7 @@ Problematic queries most often surface in one of two ways. In some cases, users
 
 In other cases, the trigger might be high memory usage on a query node, in which case the challenge is first to identify the query causing the issue.
 
-Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
+Indexer können [qlog](https://github.com/graphprotocol/qlog/) verwenden, um die Abfrageprotokolle von Graph Node zu verarbeiten und zusammenzufassen. `GRAPH_LOG_QUERY_TIMING` kann auch aktiviert werden, um langsame Abfragen zu identifizieren und zu debuggen.
 
 Given a slow query, indexers have a few options. Of course they can alter their cost model, to significantly increase the cost of sending the problematic query. This may result in a reduction in the frequency of that query. However this often doesn't resolve the root cause of the issue.
 
@@ -328,11 +328,11 @@ Given a slow query, indexers have a few options. Of course they can alter their
 
 Database tables that store entities seem to generally come in two varieties: 'transaction-like', where entities, once created, are never updated, i.e., they store something akin to a list of financial transactions, and 'account-like' where entities are updated very often, i.e., they store something like financial accounts that get modified every time a transaction is recorded. Account-like tables are characterized by the fact that they contain a large number of entity versions, but relatively few distinct entities. Often, in such tables the number of distinct entities is 1% of the total number of rows (entity versions)
 
-For account-like tables, `graph-node` can generate queries that take advantage of details of how Postgres ends up storing data with such a high rate of change, namely that all of the versions for recent blocks are in a small subsection of the overall storage for such a table.
+Für kontoähnliche Tabellen kann `graph-node` Abfragen generieren, die sich die Details zunutze machen, wie Postgres Daten mit einer so hohen Änderungsrate speichert, nämlich dass alle Versionen für die jüngsten Blöcke in einem kleinen Teil des Gesamtspeichers für eine solche Tabelle liegen.
 
-The command `graphman stats show <sgdNNNN`> shows, for each entity type/table in a deployment, how many distinct entities, and how many entity versions each table contains. That data is based on Postgres-internal estimates, and is therefore necessarily imprecise, and can be off by an order of magnitude. A `-1` in the `entities` column means that Postgres believes that all rows contain a distinct entity.
+Der Befehl `graphman stats show <sgdNNNN>` zeigt für jeden Entitätstyp/jede Tabelle in einem Einsatz an, wie viele unterschiedliche Entitäten und wie viele Entitätsversionen jede Tabelle enthält. Diese Daten beruhen auf Postgres-internen Schätzungen und sind daher notwendigerweise ungenau und können um eine Größenordnung abweichen. Ein `-1` in der Spalte `entities` bedeutet, dass Postgres davon ausgeht, dass alle Zeilen eine eindeutige Entität enthalten.
 
-In general, tables where the number of distinct entities are less than 1% of the total number of rows/entity versions are good candidates for the account-like optimization. When the output of `graphman stats show` indicates that a table might benefit from this optimization, running `graphman stats show <sgdNNN> <table>` will perform a full count of the table - that can be slow, but gives a precise measure of the ratio of distinct entities to overall entity versions.
+Im Allgemeinen sind Tabellen, bei denen die Anzahl der unterschiedlichen Entitäten weniger als 1 % der Gesamtzahl der Zeilen/Entitätsversionen beträgt, gute Kandidaten für die kontoähnliche Optimierung. Wenn die Ausgabe von `graphman stats show` darauf hindeutet, dass eine Tabelle von dieser Optimierung profitieren könnte, führt `graphman stats show <sgdNNN> <table>` eine vollständige Zählung der Tabelle durch - das kann langsam sein, liefert aber ein genaues Maß für das Verhältnis von eindeutigen Entitäten zu den gesamten Entitätsversionen.
 
 Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
 

From c31a5a9087c3cf577b3407e5eef88abf60ccece3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 05:33:07 -0500
Subject: [PATCH 3456/3820] New translations triggers.mdx (French)

---
 website/pages/fr/sps/triggers.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/sps/triggers.mdx b/website/pages/fr/sps/triggers.mdx
index 45ecc6030d82..b315f8e3d371 100644
--- a/website/pages/fr/sps/triggers.mdx
+++ b/website/pages/fr/sps/triggers.mdx
@@ -1,5 +1,5 @@
 ---
-title: Substreams Triggers
+title: Déclencheurs de Substreams
 ---
 
 Use Custom Triggers and enable the full use GraphQL.

From 729e4e07639fb6c307a452f9fd5a5ac0e67f69b5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 06:28:48 -0500
Subject: [PATCH 3457/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
index c960c41ac917..c9f26beae41f 100644
--- a/website/pages/de/indexing/overview.mdx
+++ b/website/pages/de/indexing/overview.mdx
@@ -1,5 +1,5 @@
 ---
-title: Indexing Overview
+title: Indizierung Überblick
 ---
 
 Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.

From 9aae72a5a3a954fca828d377adc33ce69d3c6470 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 06:28:49 -0500
Subject: [PATCH 3458/3820] New translations graph-node.mdx (German)

---
 website/pages/de/indexing/tooling/graph-node.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/de/indexing/tooling/graph-node.mdx b/website/pages/de/indexing/tooling/graph-node.mdx
index 24d95037bbe7..313878e00384 100644
--- a/website/pages/de/indexing/tooling/graph-node.mdx
+++ b/website/pages/de/indexing/tooling/graph-node.mdx
@@ -334,12 +334,12 @@ Der Befehl `graphman stats show <sgdNNNN>` zeigt für jeden Entitätstyp/jede Ta
 
 Im Allgemeinen sind Tabellen, bei denen die Anzahl der unterschiedlichen Entitäten weniger als 1 % der Gesamtzahl der Zeilen/Entitätsversionen beträgt, gute Kandidaten für die kontoähnliche Optimierung. Wenn die Ausgabe von `graphman stats show` darauf hindeutet, dass eine Tabelle von dieser Optimierung profitieren könnte, führt `graphman stats show <sgdNNN> <table>` eine vollständige Zählung der Tabelle durch - das kann langsam sein, liefert aber ein genaues Maß für das Verhältnis von eindeutigen Entitäten zu den gesamten Entitätsversionen.
 
-Once a table has been determined to be account-like, running `graphman stats account-like <sgdNNN>.<table>` will turn on the account-like optimization for queries against that table. The optimization can be turned off again with `graphman stats account-like --clear <sgdNNN>.<table>` It takes up to 5 minutes for query nodes to notice that the optimization has been turned on or off. After turning the optimization on, it is necessary to verify that the change does not in fact make queries slower for that table. If you have configured Grafana to monitor Postgres, slow queries would show up in `pg_stat_activity`in large numbers, taking several seconds. In that case, the optimization needs to be turned off again.
+Sobald eine Tabelle als „kontoähnlich“ eingestuft wurde, wird durch die Ausführung von `graphman stats account-like <sgdNNN>.<table>` die kontoähnliche Optimierung für Abfragen auf diese Tabelle aktiviert. Die Optimierung kann mit `graphman stats account-like --clear <sgdNNN>.<table>` wieder ausgeschaltet werden. Es dauert bis zu 5 Minuten, bis die Abfrageknoten merken, dass die Optimierung ein- oder ausgeschaltet wurde. Nach dem Einschalten der Optimierung muss überprüft werden, ob die Abfragen für diese Tabelle durch die Änderung nicht tatsächlich langsamer werden. Wenn Sie Grafana für die Überwachung von Postgres konfiguriert haben, würden langsame Abfragen in `pg_stat_activity` in großer Zahl angezeigt werden und mehrere Sekunden dauern. In diesem Fall muss die Optimierung wieder abgeschaltet werden.
 
-For Uniswap-like subgraphs, the `pair` and `token` tables are prime candidates for this optimization, and can have a dramatic effect on database load.
+Bei Uniswap-ähnlichen Subgraphen sind die `pair`- und `token`-Tabellen die Hauptkandidaten für diese Optimierung und können die Datenbankauslastung erheblich beeinflussen.
 
 #### Removing subgraphs
 
 > This is new functionality, which will be available in Graph Node 0.29.x
 
-At some point an indexer might want to remove a given subgraph. This can be easily done via `graphman drop`, which deletes a deployment and all it's indexed data. The deployment can be specified as either a subgraph name, an IPFS hash `Qm..`, or the database namespace `sgdNNN`. Further documentation is available [here](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop).
+Irgendwann möchte ein Indexer vielleicht einen bestimmten Subgraph entfernen. Das kann einfach mit `graphman drop` gemacht werden, das einen Einsatz und alle indizierten Daten löscht. Der Einsatz kann entweder als Subgraph-Name, als IPFS-Hash `Qm..` oder als Datenbank-Namensraum `sgdNNN` angegeben werden. Weitere Dokumentation ist [hier](https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md#-drop) verfügbar.

From feb94cdf4f5b1529d9cf2e59f48a9c57770cf52d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 06:28:51 -0500
Subject: [PATCH 3459/3820] New translations introduction.mdx (French)

---
 website/pages/fr/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/sps/introduction.mdx b/website/pages/fr/sps/introduction.mdx
index 62d698fb566d..b952fc5a22c2 100644
--- a/website/pages/fr/sps/introduction.mdx
+++ b/website/pages/fr/sps/introduction.mdx
@@ -1,5 +1,5 @@
 ---
-title: Introduction to Substreams-Powered Subgraphs
+title: Introduction aux Subgraphs alimentés par Substreams
 ---
 
 Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
@@ -10,7 +10,7 @@ Use a Substreams package (`.spkg`) as a data source to give your subgraph access
 
 ### Spécificités⁠
 
-There are two methods of enabling this technology:
+Il existe deux méthodes pour activer cette technologie :
 
 1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
 

From 9384df1f9f1c79dd1fffde8dcbaf7d4ea6faf704 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 06:28:52 -0500
Subject: [PATCH 3460/3820] New translations sps-faq.mdx (French)

---
 website/pages/fr/sps/sps-faq.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/sps/sps-faq.mdx b/website/pages/fr/sps/sps-faq.mdx
index 2452ac57e7cc..07c977621e1b 100644
--- a/website/pages/fr/sps/sps-faq.mdx
+++ b/website/pages/fr/sps/sps-faq.mdx
@@ -1,5 +1,5 @@
 ---
-title: Substreams-Powered Subgraphs FAQ
+title: FAQ sur les Subgraphs alimentés par Substreams
 ---
 
 ## Que sont les sous-flux ?
@@ -64,7 +64,7 @@ L'utilisation de Firehose présente de nombreux avantages, notamment:
 
 ## Où les développeurs peuvent-ils trouver plus d'informations sur les subgraphs alimentés par Substreams et sur Substreams ?
 
-The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+La [documentation Substreams ](/substreams/introduction/) vous explique comment construire des modules Substreams.
 
 The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
 

From d492f8d659e856591ce22b0ec582944382f24375 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 06:28:53 -0500
Subject: [PATCH 3461/3820] New translations triggers.mdx (French)

---
 website/pages/fr/sps/triggers.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/fr/sps/triggers.mdx b/website/pages/fr/sps/triggers.mdx
index b315f8e3d371..0e190c8d2c00 100644
--- a/website/pages/fr/sps/triggers.mdx
+++ b/website/pages/fr/sps/triggers.mdx
@@ -12,7 +12,7 @@ By importing the Protobuf definitions emitted by your Substreams module, you can
 
 ### Defining `handleTransactions`
 
-The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+Le code suivant montre comment définir une fonction `handleTransactions` dans un gestionnaire de subgraph. Cette fonction reçoit des données brutes (bytes) Substreams en paramètre et les décode en un objet Transactions. Pour chaque transaction, une nouvelle entité de subgraph est créée.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
@@ -36,9 +36,9 @@ export function handleTransactions(bytes: Uint8Array): void {
 
 Here's what you're seeing in the `mappings.ts` file:
 
-1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
-2. Looping over the transactions
-3. Create a new subgraph entity for every transaction
+1. Les bytes contenant les données Substreams sont décodés en un objet `Transactions` généré, qui est utilisé comme n’importe quel autre objet AssemblyScript
+2. Boucle sur les transactions
+3. Création d’une nouvelle entité de subgraph pour chaque transaction
 
 To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
 

From 62da6f11a40e79e257e03b32625feb71804f7834 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 06:28:54 -0500
Subject: [PATCH 3462/3820] New translations tutorial.mdx (French)

---
 website/pages/fr/sps/tutorial.mdx | 38 +++++++++++++++----------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/website/pages/fr/sps/tutorial.mdx b/website/pages/fr/sps/tutorial.mdx
index 31ae39376a85..f7ebf17395d6 100644
--- a/website/pages/fr/sps/tutorial.mdx
+++ b/website/pages/fr/sps/tutorial.mdx
@@ -1,5 +1,5 @@
 ---
-title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+title: "Tutoriel : Configurer un Subgraph alimenté par Substreams sur Solana"
 ---
 
 Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
@@ -10,22 +10,22 @@ For a video tutorial, check out [How to Index Solana with a Substreams-powered S
 
 ### Conditions préalables
 
-Before starting, make sure to:
+Avant de commencer, assurez-vous de :
 
-- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
-- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+- Avoir suivi le Guide [Getting Started](https://github.com/streamingfast/substreams-starter) pour configurer votre environnement de développement à l’aide d’un Dev Container.
+- Être familier avec The Graph et des concepts de base de la blockchain tels que les transactions et les Protobufs.
 
-### Step 1: Initialize Your Project
+### Étape 1 : Initialiser votre projet
 
-1. Open your Dev Container and run the following command to initialize your project:
+1. Ouvrez votre Dev Container et exécutez la commande suivante pour initialiser votre projet :
 
    ```bash
    substreams init
    ```
 
-2. Select the "minimal" project option.
+2. Sélectionnez l'option de projet "minimal".
 
-3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+3. Remplacez le contenu du fichier généré `substreams.yaml` par la configuration suivante, qui filtre les transactions du compte Orca sur l’ID du programme SPL token :
 
 ```yaml
 specVersion: v0.1.0
@@ -33,12 +33,12 @@ package:
   name: my_project_sol
   version: v0.1.0
 
-imports: # Pass your spkg of interest
+imports: # Passez le spkg qui vous intéresse
   solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
 
 modules:
   - name: map_spl_transfers
-    use: solana:map_block # Select corresponding modules available within your spkg
+    use: solana:map_block # Sélectionnez les modules disponibles dans votre spkg
     initialBlock: 260000082
 
   - name: map_transactions_by_programid
@@ -46,20 +46,20 @@ modules:
 
 network: solana-mainnet-beta
 
-params: # Modify the param fields to meet your needs
-  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+params: # Modifiez les champs param pour répondre à vos besoins
+  # Pour program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
   map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
 ```
 
-### Step 2: Generate the Subgraph Manifest
+### Étape 2 : Générer le Manifeste du Subgraph
 
-Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+Une fois le projet initialisé, générez un manifeste de subgraph en exécutant la commande suivante dans le Dev Container:
 
 ```bash
 substreams codegen subgraph
 ```
 
-You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+Cette commande génère un fichier `subgraph.yaml` qui importe le package Substreams comme source de données:
 
 ```yaml
 ---
@@ -69,7 +69,7 @@ dataSources:
     network: solana-mainnet-beta
     source:
       package:
-        moduleName: map_spl_transfers # Module defined in the substreams.yaml
+        moduleName: map_spl_transfers # Module défini dans le substreams.yaml
         file: ./my-project-sol-v0.1.0.spkg
     mapping:
       apiVersion: 0.0.7
@@ -78,7 +78,7 @@ dataSources:
       handler: handleTriggers
 ```
 
-### Step 3: Define Entities in `schema.graphql`
+### Étape 3 : Définir les Entités dans `schema.graphql`
 
 Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
 
@@ -94,9 +94,9 @@ type MyTransfer @entity {
 }
 ```
 
-This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+Ce schéma définit une entité `MyTransfer` avec des champs tels que `id`, `amount`, `source`, `designation` et `signers`.
 
-### Step 4: Handle Substreams Data in `mappings.ts`
+### Étape 4 : Gérer les Données Substreams dans `mappings.ts`
 
 With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
 

From bba758b7b48b50ba36cfe94a53c5856dd7476f54 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 07:38:20 -0500
Subject: [PATCH 3463/3820] New translations tutorial.mdx (French)

---
 website/pages/fr/sps/tutorial.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/fr/sps/tutorial.mdx b/website/pages/fr/sps/tutorial.mdx
index f7ebf17395d6..4a7327e38560 100644
--- a/website/pages/fr/sps/tutorial.mdx
+++ b/website/pages/fr/sps/tutorial.mdx
@@ -131,15 +131,15 @@ export function handleTriggers(bytes: Uint8Array): void {
 }
 ```
 
-### Step 5: Generate Protobuf Files
+### Étape 5 : Générer les Fichiers Protobuf
 
-To generate Protobuf objects in AssemblyScript, run the following command:
+Pour générer les objets Protobuf en AssemblyScript, exécutez la commande suivante :
 
 ```bash
 npm run protogen
 ```
 
-This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+Cette commande convertit les définitions Protobuf en AssemblyScript, vous permettant de les utiliser dans le gestionnaire de votre subgraph.
 
 ### Conclusion
 
@@ -151,4 +151,4 @@ Congratulations! You've successfully set up a trigger-based Substreams-powered s
 
 ### Ressources supplémentaires
 
-For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).
+Pour aller plus loin en matière de personnalisation et d’optimisation, consultez la [documentation officielle de Substreams](https://substreams.streamingfast.io/tutorials/solana).

From a222f983d474ccd694ac14eaee94d71539ba868e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 12:14:08 -0500
Subject: [PATCH 3464/3820] New translations enums.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/enums.mdx | 64 +++++++++----------
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/enums.mdx b/website/pages/tr/subgraphs/cookbook/enums.mdx
index 36260c8a299f..273aaefc05a6 100644
--- a/website/pages/tr/subgraphs/cookbook/enums.mdx
+++ b/website/pages/tr/subgraphs/cookbook/enums.mdx
@@ -26,46 +26,46 @@ enum TokenStatus {
 
 This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
 
-To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+Enum'lar hakkında daha fazla bilgi edinmek için [Subgraph Oluşturma](/developing/creating-a-subgraph/#enums) ve [GraphQL dokümantasyonu](https://graphql.org/learn/schema/#enumeration-types) kaynaklarına göz atın.
 
-## Benefits of Using Enums
+## Enum Kullanmanın Faydaları
 
-- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
-- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
-- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+- **Anlaşılırlık:** Enum'lar değerlere anlamlı isimler verir, veriyi daha anlaşılır hale getirir.
+- **Doğrulama:** Enum'lar katı değer tanımlamaları uygulayarak geçersiz veri girişlerini önler.
+- **Bakım Kolaylığı:** Yeni kategoriler eklemek veya mevcut olanları değiştirmek gerektiğinde, enum'lar bunu odaklı bir şekilde yapmanıza olanak tanır.
 
-### Without Enums
+### Enum'lar Olmadan
 
-If you choose to define the type as a string instead of using an Enum, your code might look like this:
+Türü Enum kullanmak yerine bir dize olarak tanımlamayı seçerseniz, kodunuz şöyle görünebilir:
 
 ```graphql
 type Token @entity {
   id: ID!
   tokenId: BigInt!
-  owner: Bytes! # Owner of the token
-  tokenStatus: String! # String field to track token status
+  owner: Bytes! # Token Sahibi
+  tokenStatus: String! # Token Durumunu Takip Eden Dize Alanı
   timestamp: BigInt!
 }
 ```
 
-In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+Bu şemada, `TokenStatus` belirli, alabileceği değerler sınırlandırılmış olmayan basit bir dizedir.
 
 #### Bu neden bir sorun?
 
-- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
-- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+- `TokenStatus` değerleri için bir kısıtlama yoktur. Bu yüzden yanlışlıkla herhangi bir dize atanabilir. Bu, yalnızca `OriginalOwner`, `SecondOwner` veya `ThirdOwner` gibi geçerli durumların ayarlandığını sağlamayı zorlaştırır.
+- `OriginalOwner` yerine `Orgnalowner` gibi yazım hataları yaparak verilerin ve potansiyel sorguların güvenilmez hale gelmesine sebep olmak kolaydır.
 
-### With Enums
+### Enum Kullanımıyla
 
-Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+Serbest formda dizeler atamak yerine, `TokenStatus` için `OriginalOwner`, `SecondOwner` veya `ThirdOwner` gibi belirli değerlerle bir enum tanımlanabilir. Bir enum kullanmak, yalnızca izin verilen değerlerin kullanılmasını sağlar.
 
-Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+Enumlar; tür güvenliği sağlar, yazım hatası riskini en aza indirir ve tutarlı ve güvenilir sonuçlar sağlar.
 
-## Defining Enums for NFT Marketplaces
+## NFT Pazar Yerleri için Enum Tanımlama
 
-> Note: The following guide uses the CryptoCoven NFT smart contract.
+> Not: Aşağıdaki kılavuz CryptoCoven NFT akıllı sözleşmesini kullanmaktadır.
 
-To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+NFT'lerin ticaretinin yapıldığı çeşitli pazar yerleri için enum tanımlamak için subgraph şemanızda aşağıdakini kullanın:
 
 ```gql
 # Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
@@ -78,39 +78,39 @@ enum Marketplace {
 }
 ```
 
-## Using Enums for NFT Marketplaces
+## NFT Pazar Yerleri için Enum Kullanımı
 
-Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+Tanımlandıktan sonra, enum'lar işlemleri veya olayları kategorize etmek için subgraph'inizde kullanılabilir.
 
-For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+Örneğin, NFT satışlarını kaydederken takasta yer alan pazar yerini enum kullanarak belirleyebilirsiniz.
 
-### Implementing a Function for NFT Marketplaces
+### NFT Pazar Yerleri için Bir Fonksiyon İmplementasyonu
 
 Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
 
 ```ts
 export function getMarketplaceName(marketplace: Marketplace): string {
-  // Using if-else statements to map the enum value to a string
+  // Enum değerini bir dizeye eşlemek için if-else ifadelerini kullanma
   if (marketplace === Marketplace.OpenSeaV1) {
-    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+    return 'OpenSeaV1' // I Eğer pazar yeri OpenSea ise, onun dize temsilini döndür 
   } else if (marketplace === Marketplace.OpenSeaV2) {
     return 'OpenSeaV2'
   } else if (marketplace === Marketplace.SeaPort) {
-    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+    return 'SeaPort' // Eğer pazar yeri SeaPort ise, onun dize temsilini döndür
   } else if (marketplace === Marketplace.LooksRare) {
-    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
-    // ... and other market places
+    return 'LooksRare' // Eğer pazar yeri LooksRare ise, onun dize temsilini döndür
+    // ... ve diğer pazar yerleri
   }
 }
 ```
 
-## Best Practices for Using Enums
+## Enum Kullanımı için En İyi Uygulamalar
 
-- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
-- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
-- **Documentation:** Add comments to enum to clarify their purpose and usage.
+- **Tutarlı İsimlendirme:** Okunabilirliği artırmak için enum değerleri için net, açıklayıcı isimler kullanın.
+- **Merkezi Yönetim:** Tutarlılık için enum'ları tek bir dosyada tutun. Böylece enum'ların güncellenmesi kolaylaşmış olur ve onların tek bir doğru bilgi kaynağı olmasını sağlar.
+- **Dokümantasyon:** Amaçlarını ve kullanımını açıklamak için enum'a yorumlar ekleyin.
 
-## Using Enums in Queries
+## Sorgularda Enum Kullanımı
 
 Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
 

From 3523b07c3742fb658acf4363053f69ae4943c1f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 13:13:38 -0500
Subject: [PATCH 3465/3820] New translations grafting-hotfix.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/grafting-hotfix.mdx      | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
index 8b98e58f511e..9ec55c3d900c 100644
--- a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
@@ -4,20 +4,20 @@ title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
 
 ## Özet
 
-Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+Graftlama, mevcut endekslenmiş verileri yeniden kullanarak yeni subgraph'ler oluşturmanıza ve dağıtmanıza olanak tanıyan güçlü bir özelliktir.
 
 ### Genel Bakış
 
-This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+Bu özellik, kritik sorunlar için hızlı bir şekilde düzeltmelerin dağıtılmasını sağlar ve tüm subgraph'i baştan endeksleme ihtiyacını ortadan kaldırır. Graftlama, tarihsel verileri koruyarak kesinti sürelerini en aza indirir ve veri hizmetlerinde süreklilik sağlar.
 
-## Benefits of Grafting for Hotfixes
+## Hızlı Düzeltmelerde Graftlamanın Avantajları
 
-1. **Rapid Deployment**
+1. **Hızlı Dağıtım**
 
-   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
-   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+   - **Kesinti Süresini En Aza İndirme**: Bir subgraph kritik bir hata ile karşılaştığında ve endekslemeyi durdurduğunda, graftlama sayesinde yeniden endekslemeyi beklemeden hemen bir düzeltme dağıtabilirsiniz.
+   - **Hızlıca Kurtarma**: Yeni subgraph, son endekslenmiş bloktan devam eder ve veri hizmetlerinin kesintisiz olmasını sağlar.
 
-2. **Data Preservation**
+2. **Veri Koruma**
 
    - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
    - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.

From af2767525264267dc4e91e56a8eaef161de4be2c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 13:13:39 -0500
Subject: [PATCH 3466/3820] New translations explorer.mdx (Turkish)

---
 website/pages/tr/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/explorer.mdx b/website/pages/tr/subgraphs/explorer.mdx
index ea5de668e6a2..add2cf20cfa2 100644
--- a/website/pages/tr/subgraphs/explorer.mdx
+++ b/website/pages/tr/subgraphs/explorer.mdx
@@ -67,7 +67,7 @@ Indexers are the backbone of the protocol. They stake on subgraphs, index them,
 
 In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
 
-**Specifics**
+**Ayrıntılar**
 
 - Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
 - Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.

From 1cb0d885fd909b2ee30f8b0046a5806cf0c8948b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 13:13:40 -0500
Subject: [PATCH 3467/3820] New translations enums.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/enums.mdx | 44 +++++++++----------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/enums.mdx b/website/pages/tr/subgraphs/cookbook/enums.mdx
index 273aaefc05a6..100efa7f2880 100644
--- a/website/pages/tr/subgraphs/cookbook/enums.mdx
+++ b/website/pages/tr/subgraphs/cookbook/enums.mdx
@@ -114,19 +114,19 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 
 Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
 
-**Specifics**
+**Ayrıntılar**
 
-- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
-- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+- **Enum ile Filtreleme:** Enum'lar net filtreler sağlar, belirli pazarları güvenle dahil etmenizi veya hariç tutmanızı mümkün kılar.
+- **Yanıtlarda Enum'lar:** Enum'lar yalnızca tanınan pazar adlarının döndürülmesini garanti eder, bu da sonuçları standart ve isabetli hale getirir.
 
-### Sample Queries
+### Örnek Sorgular
 
-#### Query 1: Account With The Highest NFT Marketplace Interactions
+#### Sorgu 1: En Yüksek NFT Pazar Yeri Etkileşimine Sahip Hesap
 
-This query does the following:
+Bu sorgu şunları yapar:
 
-- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
-- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+- Farklı pazar yerlerinde en yüksek benzersiz NFT etkileşimlerine sahip hesabı bulur. Bu da çapraz pazar yeri aktivitelerini analiz etmek için mükemmeldir.
+- Pazar yerleri alanı, yanıt içerisindeki pazar yeri değerlerini tutarlı ve doğrulanmış hale getiren pazar yeri enum'ını kullanır.
 
 ```gql
 {
@@ -143,7 +143,7 @@ This query does the following:
 }
 ```
 
-#### Returns
+#### Dönüşler
 
 This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
 
@@ -186,12 +186,12 @@ This response provides account details and a list of unique marketplace interact
 }
 ```
 
-#### Query 2: Most Active Marketplace for CryptoCoven transactions
+#### Sorgu 2: CryptoCoven İşlemleri için En Aktif Pazar Yeri
 
-This query does the following:
+Bu sorgu şunları yapar:
 
-- It identifies the marketplace with the highest volume of CryptoCoven transactions.
-- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+- CryptoCoven işlemlerinin en yüksek hacimli olduğu pazar yerini belirler.
+- Yalnızca geçerli pazar yeri türlerinin yanıt olarak görünmesini sağlamak için pazar yeri enum'ını kullanarak verilerinize güvenilirlik ve tutarlılık katar.
 
 ```gql
 {
@@ -202,9 +202,9 @@ This query does the following:
 }
 ```
 
-#### Result 2
+#### Sonuç 2
 
-The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+Beklenen yanıt, pazar yerini ve ilgili işlem sayısını içerir; pazar yeri türünü belirtmek için enum kullanır:
 
 ```gql
 {
@@ -219,12 +219,12 @@ The expected response includes the marketplace and the corresponding transaction
 }
 ```
 
-#### Query 3: Marketplace Interactions with High Transaction Counts
+#### Sorgu 3: Yüksek İşlem Sayısına Sahip Pazar Etkileşimleri
 
-This query does the following:
+Bu sorgu şunları yapar:
 
-- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
-- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+- "Unknown" pazarlarını hariç tutarak, 100'den fazla işlemi olan ilk dört pazarı getirir.
+- Yalnızca geçerli pazar türlerinin dahil edilmesini sağlamak için filtre olarak enum'lar kullanır. Böylece doğruluk oranı arttırılmış olur.
 
 ```gql
 {
@@ -240,9 +240,9 @@ This query does the following:
 }
 ```
 
-#### Result 3
+#### Sonuç 3
 
-Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+Beklenen çıktı, her biri bir enum değeri ile temsil edilen, kriterleri karşılayan pazarları içerir:
 
 ```gql
 {
@@ -271,4 +271,4 @@ Expected output includes the marketplaces that meet the criteria, each represent
 
 ## Ek Kaynaklar
 
-For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).
+Ek bilgi için bu rehberin [deposuna](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums) göz atın.

From 6f1dd48f29e489a01fdcc8ca509fff88f97f0383 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 14:27:15 -0500
Subject: [PATCH 3468/3820] New translations grafting-hotfix.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/grafting-hotfix.mdx | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
index 9ec55c3d900c..fb16051501ae 100644
--- a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
@@ -20,11 +20,11 @@ Bu özellik, kritik sorunlar için hızlı bir şekilde düzeltmelerin dağıtı
 2. **Veri Koruma**
 
    - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
-   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+   - **Tutarlılık**: Tutarlı tarihsel verilere bağımlı uygulamalar için veri sürekliliğini sağlar.
 
-3. **Efficiency**
-   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
-   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+3. **Verimlilik**
+   - **Zaman ve Kaynak Tasarrufu**: Büyük veri kümelerinin yeniden endekslenmesinden kaynaklı hesaplama yükünü önler.
+   - **Hatalara Odaklanma**: Geliştiricilerin veri kurtarma yönetimi yerine sorunları çözmeye odaklanmalarını sağlar.
 
 ## Best Practices When Using Grafting for Hotfixes
 
@@ -47,10 +47,10 @@ Bu özellik, kritik sorunlar için hızlı bir şekilde düzeltmelerin dağıtı
      > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
    - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
 
-4. **Important Considerations**
+4. **Önemli Hususlar**
    - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
-   - **Tip**: Use the block number of the last correctly processed event.
-   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
+   - **İpucu**: Doğru işlenmiş son olayın blok numarasını kullanın.
+   - **Dağıtım ID'sini Kullanın**: Subgraph ID'si yerine temel subgraph'in Dağıtım ID'sine referans verdiğinizden emin olun.
    - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
    - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
 
@@ -149,18 +149,18 @@ While grafting is a powerful tool for deploying hotfixes quickly, there are spec
 - **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
 - **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
 
-### Risk Management
+### Risk Yönetimi
 
-- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
+- **Veri Bütünlüğü**: Yanlış blok numaraları veri kaybına veya yinelenmelere yol açabilir.
 - **Testing**: Always test grafting in a development environment before deploying to production.
 
 ## Sonuç
 
 Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
 
-- **Quickly Recover** from critical errors without re-indexing.
-- **Preserve Historical Data**, maintaining continuity for applications and users.
-- **Ensure Service Availability** by minimizing downtime during critical fixes.
+- Yeniden endeksleme yapmadan kritik hatalardan **Hızla Kurtulun**.
+- Uygulamalar ve kullanıcılar için sürekliliği koruyarak **Tarihsel Verileri Koruyun**.
+- Kritik düzeltmeler sırasında kesinti sürelerini en aza indirerek **Hizmet Erişilebilirliğini Sağlayın**.
 
 However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
 

From b6d45a233b8a92d33fff8774c813c7a1ae09ae59 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 14:27:16 -0500
Subject: [PATCH 3469/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
index d1ee0402fe6b..dacc003d2a2c 100644
--- a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -1,12 +1,12 @@
 ---
-title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+title: Subgraph Örnek Uygulama 3 - Değişmez Varlıklar ve Byte'ları Kimlik Olarak Kullanarak Endeksleme ve Sorgu Performansını İyileştirin
 ---
 
 ## Özet
 
 Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
 
-## Immutable Entities
+## Değişmez Varlıklar
 
 To make an entity immutable, we simply add `(immutable: true)` to an entity.
 

From f57ac6ec6b667c0993c81202eba825046c7941f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 14:27:17 -0500
Subject: [PATCH 3470/3820] New translations grafting.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/grafting.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/grafting.mdx b/website/pages/tr/subgraphs/cookbook/grafting.mdx
index 27e55907955a..910787eb371e 100644
--- a/website/pages/tr/subgraphs/cookbook/grafting.mdx
+++ b/website/pages/tr/subgraphs/cookbook/grafting.mdx
@@ -44,7 +44,7 @@ Bu yönergelere uyarak riskleri en aza indirebilir ve daha sorunsuz bir taşıma
 
 Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
 
-- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+- [Subgraph örnek deposu](https://github.com/Shiyasmohd/grafting-tutorial)
 
 > Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
 
@@ -199,4 +199,4 @@ If you want more experience with grafting, here are a few examples for popular c
 
 To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
 
-> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)
+> Not: Bu makaledeki materyalin büyük bir kısmı, daha önce yayımlanmış olan [Arweave makalesinden](/subgraphs/cookbook/arweave/) alınmıştır

From db4ed6c36d90cdd1edcd66178296a5df7fe01c24 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 15:29:49 -0500
Subject: [PATCH 3471/3820] New translations derivedfrom.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/derivedfrom.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
index 9de67dadeae6..ca0c60f7679d 100644
--- a/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
@@ -65,7 +65,7 @@ Bu yalnızca subgraph'imizi daha verimli hale getirmekle kalmayacak, aynı zaman
 
 2. Herhangi bir `Comment`'te tersine arama yapabilir ve hangi gönderiden geldiğini sorgulayabiliriz.
 
-3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+3. [Türetilmiş Alan Yükleyicileri](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) kullanarak, sanal ilişkilerden gelen verilere doğrudan erişim ve manipülasyon yapma yeteneğini subgraph eşlemelerinde etkinleştirebiliriz.
 
 ## Sonuç
 

From 9c4bb4ece720d180021c8fecfc6f2c63b4c417a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 1 Feb 2025 15:29:50 -0500
Subject: [PATCH 3472/3820] New translations enums.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/enums.mdx | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/enums.mdx b/website/pages/tr/subgraphs/cookbook/enums.mdx
index 100efa7f2880..6ec3ee35af1b 100644
--- a/website/pages/tr/subgraphs/cookbook/enums.mdx
+++ b/website/pages/tr/subgraphs/cookbook/enums.mdx
@@ -24,7 +24,7 @@ enum TokenStatus {
 }
 ```
 
-This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+Bu, şemanızda `TokenStatus` türünü kullandığınızda, bunun tanımlı değerlerden tam olarak biri olmasını beklediğiniz anlamına gelir: `OriginalOwner`, `SecondOwner` veya `ThirdOwner`. Böylece tutarlılık ve geçerlilik sağlanmış olur.
 
 Enum'lar hakkında daha fazla bilgi edinmek için [Subgraph Oluşturma](/developing/creating-a-subgraph/#enums) ve [GraphQL dokümantasyonu](https://graphql.org/learn/schema/#enumeration-types) kaynaklarına göz atın.
 
@@ -68,13 +68,13 @@ Enumlar; tür güvenliği sağlar, yazım hatası riskini en aza indirir ve tuta
 NFT'lerin ticaretinin yapıldığı çeşitli pazar yerleri için enum tanımlamak için subgraph şemanızda aşağıdakini kullanın:
 
 ```gql
-# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+# CryptoCoven sözleşmesinin etkileşimde bulunduğu pazar yerleri için Enum (muhtemel bir Takas/Basım)
 enum Marketplace {
-  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
-  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
-  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
-  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
-  # ...and other marketplaces
+  OpenSeaV1 # CryptoCoven NFT'sinin bu pazar yerinde takas yapılmasını temsil eder
+  OpenSeaV2 # CryptoCoven NFT'si ninOpenSeaV2 pazar yerinde takas yapılmasını temsil eder
+  SeaPort # CryptoCoven NFT'sinin SeaPort pazar yerinde takas yapılmasını temsil eder
+  LooksRare # CryptoCoven NFT'sinin LookRare pazar yerinde takas yapılmasını temsil eder
+  # ...ve diğer pazar yerleri
 }
 ```
 
@@ -86,7 +86,7 @@ Tanımlandıktan sonra, enum'lar işlemleri veya olayları kategorize etmek içi
 
 ### NFT Pazar Yerleri için Bir Fonksiyon İmplementasyonu
 
-Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+Enum'dan pazar yeri adını bir dize olarak almak için bir fonksiyonu şöyle uygulayabilirsiniz:
 
 ```ts
 export function getMarketplaceName(marketplace: Marketplace): string {
@@ -112,7 +112,7 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 
 ## Sorgularda Enum Kullanımı
 
-Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+Sorgulardaki enum'lar verilerin kalitesini artırmanıza ve sonuçları daha kolay yorumlamanıza yardımcı olur. Enumlar filtreleme ve yanıt ögeleri olarak işlev görürler, tutarlılığı sağlarlar ve pazar yerlerindeki hataları azaltırlar.
 
 **Ayrıntılar**
 
@@ -137,7 +137,7 @@ Bu sorgu şunları yapar:
     totalSpent
     uniqueMarketplacesCount
     marketplaces {
-      marketplace # This field returns the enum value representing the marketplace
+      marketplace # Bu alan, pazar yerini temsil eden enum değerini döndürür.
     }
   }
 }
@@ -145,7 +145,7 @@ Bu sorgu şunları yapar:
 
 #### Dönüşler
 
-This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+Bu yanıt; hesap detaylarını, ve netlik sağlamak amacıyla enum değerlerine sahip benzersiz pazar yeri etkileşimlerinin listesini sağlar:
 
 ```gql
 {

From 4c1b073a34d7af1190b8476036acd34cdd14013e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 2 Feb 2025 05:33:39 -0500
Subject: [PATCH 3473/3820] New translations tap.mdx (German)

---
 website/pages/de/indexing/tap.mdx | 88 +++++++++++++++----------------
 1 file changed, 44 insertions(+), 44 deletions(-)

diff --git a/website/pages/de/indexing/tap.mdx b/website/pages/de/indexing/tap.mdx
index c73570315b39..126228396278 100644
--- a/website/pages/de/indexing/tap.mdx
+++ b/website/pages/de/indexing/tap.mdx
@@ -99,73 +99,73 @@ Die erforderliche Softwareversion finden Sie [hier](https://github.com/graphprot
 Für eine minimale Konfiguration verwenden Sie die folgende Vorlage:
 
 ```bash
-# You will have to change *all* the values below to match your setup.
+# Sie müssen *alle* nachstehenden Werte ändern, um sie an Ihre Einrichtung anzupassen.
 #
-# Some of the config below are global graph network values, which you can find here:
+# Einige der nachstehenden Konfigurationswerte sind globale Graphnetzwerkwerte, die Sie hier finden können:
 # <https://github.com/graphprotocol/indexer/tree/main/docs/networks>
 #
-# Pro tip: if you need to load some values from the environment into this config, you
-# can overwrite with environment variables. For example, the following can be replaced
-# by [PREFIX]_DATABASE_POSTGRESURL, where PREFIX can be `INDEXER_SERVICE` or `TAP_AGENT`:
+# Pro-Tipp: Wenn Sie einige Werte aus der Umgebung in diese Konfiguration laden müssen,
+# können Sie sie mit Umgebungsvariablen überschreiben. Als Datenbeispiel kann folgendes ersetzt werden
+# durch [PREFIX]_DATABASE_POSTGRESURL, wobei PREFIX `INDEXER_SERVICE` oder `TAP_AGENT` sein kann:
 #
-# [database]
-# postgres_url = "postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0"
+# [Datenbank]
+# postgres_url = „postgresql://indexer:${POSTGRES_PASSWORD}@postgres:5432/indexer_components_0“
 
 [indexer]
-indexer_address = "0x1111111111111111111111111111111111111111"
-operator_mnemonic = "celery smart tip orange scare van steel radio dragon joy alarm crane"
+indexer_address = „0x1111111111111111111111111111111111111111“
+operator_mnemonic = „celery smart tip orange scare van steel radio dragon joy alarm crane“
 
 [database]
-# The URL of the Postgres database used for the indexer components. The same database
-# that is used by the `indexer-agent`. It is expected that `indexer-agent` will create
-# the necessary tables.
-postgres_url = "postgres://postgres@postgres:5432/postgres"
+# Die URL der Postgres-Datenbank, die für die Indexer-Komponenten verwendet wird. Die gleiche Datenbank,
+# die auch vom `indexer-agent` verwendet wird. Es wird erwartet, dass `indexer-agent`
+# die notwendigen Tabellen erstellt.
+postgres_url = „postgres://postgres@postgres:5432/postgres“
 
 [graph_node]
-# URL to your graph-node's query endpoint
-query_url = "<http://graph-node:8000>"
-# URL to your graph-node's status endpoint
-status_url = "<http://graph-node:8000/graphql>"
+# URL zum Abfrageendpunkt Ihres Graph-Knotens
+query_url = „<http://graph-node:8000>“
+# URL zum Status-Endpunkt Ihres Graph-Knotens
+status_url = „<http://graph-node:8000/graphql>“
 
 [subgraphs.network]
-# Query URL for the Graph Network subgraph.
-query_url = "<http://example.com/network-subgraph>"
-# Optional, deployment to look for in the local `graph-node`, if locally indexed.
-# Locally indexing the subgraph is recommended.
-# NOTE: Use `query_url` or `deployment_id` only
-deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+# Abfrage-URL für den Graph Network Subgraph.
+query_url = „<http://example.com/network-subgraph>“
+# Optional, Einsatz, nach dem im lokalen `graph-node` gesucht wird, falls er lokal indiziert ist.
+# Es wird empfohlen, den Subgraphen lokal zu indizieren.
+# HINWEIS: Verwenden Sie nur `query_url` oder `deployment_id`.
+deployment_id = „Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa“
 
 [subgraphs.escrow]
-# Query URL for the Escrow subgraph.
-query_url = "<http://example.com/network-subgraph>"
-# Optional, deployment to look for in the local `graph-node`, if locally indexed.
-# Locally indexing the subgraph is recommended.
-# NOTE: Use `query_url` or `deployment_id` only
-deployment_id = "Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+# Abfrage-URL für den Subgraphen „Escrow“.
+query_url = „<http://example.com/network-subgraph>“
+# Optional, Einsatz, nach dem im lokalen `graph-node` gesucht wird, falls er lokal indiziert ist.
+# Es wird empfohlen, den Subgraphen lokal zu indizieren.
+# HINWEIS: Verwenden Sie nur `query_url` oder `deployment_id`.
+deployment_id = „Qmaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa“
 
 [blockchain]
-# The chain ID of the network that the graph network is running on
+# Die Ketten-ID des Netzwerks, auf dem das Graph-Netzwerk läuft
 chain_id = 1337
-# Contract address of TAP's receipt aggregate voucher (RAV) verifier.
-receipts_verifier_address = "0x2222222222222222222222222222222222222222"
+# Vertragsadresse des RAV-Prüfers (receipt aggregate voucher) von TAP.
+receipts_verifier_address = „0x2222222222222222222222222222222222222222“
 
 ########################################
-# Specific configurations to tap-agent #
+# Spezifische Konfigurationen für tap-agent #
 ########################################
 [tap]
-# This is the amount of fees you are willing to risk at any given time. For ex.
-# if the sender stops supplying RAVs for long enough and the fees exceed this
-# amount, the indexer-service will stop accepting queries from the sender
-# until the fees are aggregated.
-# NOTE: Use strings for decimal values to prevent rounding errors
-# e.g:
-# max_amount_willing_to_lose_grt = "0.1"
-max_amount_willing_to_lose_grt = 20
+# Dies ist die Höhe der Gebühren, die Sie bereit sind, zu einem bestimmten Zeitpunkt zu riskieren. Zum Beispiel,
+# wenn der Sender lange genug keine RAVs mehr liefert und die Gebühren diesen Betrag
+# übersteigt, wird der Indexer-Service keine Anfragen mehr vom Absender annehmen
+# bis die Gebühren aggregiert sind.
+# HINWEIS: Verwenden Sie Strings für dezimale Werte, um Rundungsfehler zu vermeiden.
+# z.B.:
+# max_amount_willing_to_lose_grt = „0.1“
+max_Betrag_willig_zu_verlieren_grt = 20
 
 [tap.sender_aggregator_endpoints]
-# Key-Value of all senders and their aggregator endpoints
-# This one below is for the E&N testnet gateway for example.
-0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = "https://tap-aggregator.network.thegraph.com"
+# Key-Value aller Absender und ihrer Aggregator-Endpunkte
+# Das folgende Datenbeispiel gilt für das E&N Testnet-Gateway.
+0xDDE4cfFd3D9052A9cb618fC05a1Cd02be1f2F467 = „https://tap-aggregator.network.thegraph.com“
 ```
 
 Anmerkungen:

From 6932fbed9005b1fb4c2a299c614bf07fccd6273f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 2 Feb 2025 11:00:06 -0500
Subject: [PATCH 3474/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
index c9f26beae41f..564995653986 100644
--- a/website/pages/de/indexing/overview.mdx
+++ b/website/pages/de/indexing/overview.mdx
@@ -2,7 +2,7 @@
 title: Indizierung Überblick
 ---
 
-Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+Indexer sind Knotenbetreiber im Graph Network, die Graph Tokens (GRT) einsetzen, um Indizierungs- und Abfrageverarbeitungsdienste anzubieten. Indexer verdienen Abfragegebühren und Indexing Rewards für ihre Dienste. Sie verdienen auch Abfragegebühren, die gemäß einer exponentiellen Rabattfunktion zurückerstattet werden.
 
 GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.
 
@@ -18,13 +18,13 @@ The minimum stake for an Indexer is currently set to 100K GRT.
 
 ### What are the revenue streams for an Indexer?
 
-**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+**Abfragegebühren-Rabatte** - Zahlungen für die Bedienung von Abfragen im Netz. Diese Zahlungen werden über Statuskanäle zwischen einem Indexer und einem Gateway vermittelt. Jede Abfrageanfrage eines Gateways enthält eine Zahlung und die entsprechende Antwort einen Nachweis für die Gültigkeit des Abfrageergebnisses.
 
-**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+**Rewards für die Indizierung** - Die Rewards für die Indizierung werden über eine jährliche protokollweite Inflation von 3% an Indexer verteilt, die Subgraphen für das Netzwerk indizieren.
 
 ### How are indexing rewards distributed?
 
-Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+Die Rewards für die Indizierung stammen aus der Protokollinflation, die auf 3 % pro Jahr festgelegt ist. Sie werden auf Subgraphen verteilt, basierend auf dem Anteil aller Kurationssignale auf jedem Subgraphen, und dann anteilig an Indexer verteilt, basierend auf ihrem zugewiesenen Anteil auf diesem Subgraphen. **Eine Zuteilung muss mit einem gültigen Indizierungsnachweis (proof of indexing - POI) abgeschlossen werden, der die in der Schlichtungscharta festgelegten Standards erfüllt, um für Rewards in Frage zu kommen.**
 
 Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
 

From 9e0197fa632f0fb9cdc5186b20371fb15665c810 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 2 Feb 2025 12:01:22 -0500
Subject: [PATCH 3475/3820] New translations l2-transfer-tools-guide.mdx
 (Chinese Simplified)

---
 website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
index c05e4d150d42..a88b88d8fcbf 100644
--- a/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
+++ b/website/pages/zh/archived/arbitrum/l2-transfer-tools-guide.mdx
@@ -1,5 +1,5 @@
 ---
-title: L2转移工具指南
+title: L2 Transfer Tools Guide
 ---
 
 The Graph has made it easy to move to L2 on Arbitrum One. For each protocol participant, there are a set of L2 Transfer Tools to make transferring to L2 seamless for all network participants. These tools will require you to follow a specific set of steps depending on what you are transferring.

From c5408d1cabed50e584a77dd12da42838f3458472 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 2 Feb 2025 12:01:23 -0500
Subject: [PATCH 3476/3820] New translations graph-node.mdx (Chinese
 Simplified)

---
 website/pages/zh/indexing/tooling/graph-node.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/indexing/tooling/graph-node.mdx b/website/pages/zh/indexing/tooling/graph-node.mdx
index 590e4ed9be88..fb8b60baf25a 100644
--- a/website/pages/zh/indexing/tooling/graph-node.mdx
+++ b/website/pages/zh/indexing/tooling/graph-node.mdx
@@ -322,7 +322,7 @@ Graph Node caches GraphQL queries by default, which can significantly reduce dat
 
 Indexers can use [qlog](https://github.com/graphprotocol/qlog/) to process and summarize Graph Node's query logs. `GRAPH_LOG_QUERY_TIMING` can also be enabled to help identify and debug slow queries.
 
-针对慢查询，索引器有几个选项。当然，他们可以改变成本模型，显著增加发送有问题查询的成本。这可能导致该查询的频率降低。然而，这通常并不能解决问题的根本原因。
+针对慢查询，索引人有几个选项。当然，他们可以改变成本模型，显著增加发送有问题查询的成本。这可能导致该查询的频率降低。然而，这通常并不能解决问题的根本原因。
 
 ##### 账户式优化
 

From 87caec41c33352a6be7995cb0ba22b7dbc9e1142 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 2 Feb 2025 12:01:25 -0500
Subject: [PATCH 3477/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
index 564995653986..4b750f58707d 100644
--- a/website/pages/de/indexing/overview.mdx
+++ b/website/pages/de/indexing/overview.mdx
@@ -38,11 +38,11 @@ Allocations are continuously accruing rewards while they're active and allocated
 
 ### Can pending indexing rewards be monitored?
 
-The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+Der RewardsManager-Vertrag verfügt über eine schreibgeschützte Funktion [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316), mit der die ausstehenden Rewards für eine bestimmte Zuweisung überprüft werden können.
 
 Many of the community-made dashboards include pending rewards values and they can be easily checked manually by following these steps:
 
-1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+1. Fragen Sie den [Mainnet-Subgraphen](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) ab, um die IDs für alle aktiven Zuweisungen zu erhalten:
 
 ```graphql
 query indexerAllocations {
@@ -58,13 +58,13 @@ query indexerAllocations {
 }
 ```
 
-Use Etherscan to call `getRewards()`:
+Verwenden Sie Etherscan, um `getRewards()` aufzurufen:
 
-- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+- Navigieren Sie zu [Etherscan-Schnittstelle zu Rewards-Vertrag](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
 
 <!---->
 
-- To call `getRewards()`:
+- Um `getRewards()` aufzurufen:
   - Expand the **9. getRewards** dropdown.
   - Enter the **allocationID** in the input.
   - Click the **Query** button.

From 2d1544d5512c5a961eac088c6ef7b96e57036897 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 2 Feb 2025 13:13:10 -0500
Subject: [PATCH 3478/3820] New translations assemblyscript-migration-guide.mdx
 (French)

---
 .../assemblyscript-migration-guide.mdx             | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx
index 48954cbf16cd..eecebd16ba8c 100644
--- a/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -469,7 +469,7 @@ To actually push at the beginning you should either, initialize the `Array` with
 ```typescript
 let arr = new Array<string>(0) // []
 
-arr.push('something') // ["something"]
+arr.push('something') // ["quelque chose"]
 ```
 
 Ou vous devriez le muter via index :
@@ -477,12 +477,12 @@ Ou vous devriez le muter via index :
 ```typescript
 let arr = new Array<string>(5) // ["", "", "", "", ""]
 
-arr[0] = 'something' // ["something", "", "", "", ""]
+arr[0] = 'something' // ["quelque chose", "", "", "", ""]
 ```
 
 ### Schéma GraphQL
 
-This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+Il ne s'agit pas d'un changement direct d'AssemblyScript, mais vous devrez peut-être mettre à jour votre fichier `schema.graphql`.
 
 Vous ne pouvez désormais plus définir de champs dans vos types qui sont des listes non nullables. Si vous avez un schéma comme celui-ci :
 
@@ -497,7 +497,7 @@ type MyEntity @entity {
 }
 ```
 
-You'll have to add an `!` to the member of the List type, like this:
+Vous devrez ajouter un `!` au membre du type List, comme ceci :
 
 ```graphql
 type Something @entity {
@@ -514,10 +514,10 @@ This changed because of nullability differences between AssemblyScript versions,
 
 ### Autre
 
-- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Alignement de `Map#set` et `Set#add` avec la spécification, retournant `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
 - Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
 - Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
-- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- Le résultat d'une opération binaire `**` est maintenant l'entier de dénominateur commun si les deux opérandes sont des entiers. Auparavant, le résultat était un flottant comme si l'on appelait `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Contraindre `NaN` à `false` lors d'une conversion de type vers `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
 - When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
 - Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From d653124370b383edf7408ea718e9d06851741998 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 2 Feb 2025 13:13:12 -0500
Subject: [PATCH 3479/3820] New translations getting-started-substreams.mdx
 (French)

---
 website/pages/fr/substreams/getting-started-substreams.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/substreams/getting-started-substreams.mdx b/website/pages/fr/substreams/getting-started-substreams.mdx
index 2b2b1f1e0b5f..a1f1bd872fc0 100644
--- a/website/pages/fr/substreams/getting-started-substreams.mdx
+++ b/website/pages/fr/substreams/getting-started-substreams.mdx
@@ -1,5 +1,5 @@
 ---
-title: Substreams Quick Start
+title: Démarrage rapide des Substreams
 ---
 
 Discover how to utilize ready-to-use substream packages or develop your own.

From 89ec7560b321c3a29b19534b92ff28c6127a0339 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 02:23:11 -0500
Subject: [PATCH 3480/3820] New translations assemblyscript-migration-guide.mdx
 (French)

---
 .../assemblyscript-migration-guide.mdx        | 44 +++++++++----------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx
index eecebd16ba8c..58c18e390690 100644
--- a/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -2,40 +2,40 @@
 title: Guide de migration de l'AssemblyScript
 ---
 
-Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+Jusqu'à présent, les subgraphs utilisaient l'une des [premières versions d'AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Nous avons enfin ajouté la prise en charge de la [dernière version disponible](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10) ! 🎉
 
 Cela permettra aux développeurs de subgraph d'utiliser les nouvelles fonctionnalités du langage AS et de la bibliothèque standard.
 
-This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+Ce guide s'applique à tous ceux qui utilisent `graph-cli`/`graph-ts` en dessous de la version `0.22.0`. Si vous êtes déjà à une version supérieure (ou égale) à celle-ci, vous avez déjà utilisé la version `0.19.10` d'AssemblyScript 🙂
 
-> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+> Note : A partir de `0.24.0`, `graph-node` peut supporter les deux versions, en fonction de la `apiVersion` spécifiée dans le manifeste du subgraph.
 
 ## Fonctionnalités
 
 ### Nouvelle fonctionnalité
 
-- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
-- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
-- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
-- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
-- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
-- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
-- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
-- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
-- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
-- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
-- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
-- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
-- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+- Les `TypedArray`s peuvent maintenant être construits à partir des `ArrayBuffer`s en utilisant la [nouvelle méthode statique `wrap`](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- Nouvelles fonctions de la bibliothèque standard : `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare` et `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Ajout de la prise en charge de x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Ajout de `StaticArray<T>`, une variante de tableau plus efficace ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Ajout de `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implémentation de l'argument `radix` sur `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Ajout de la prise en charge des séparateurs dans les nombres à virgule flottante ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Prise en charge des fonctions de première classe ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Ajouter des éléments intégrés suivants: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implémentation de `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Ajout de la prise en charge des modèles de chaînes de caractères ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Ajout de `encodeURI(Component)` et `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Ajout de `toString`, `toDateString` et `toTimeString` à `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Ajout de `toUTCString` pour `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Ajout du type intégré `nonnull/NonNullable` ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
 
 ### Optimizations
 
-- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
-- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
-- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Les fonctions mathématiques telles que `exp`, `exp2`, `log`, `log2` et `pow` ont été remplacées par des variantes plus rapides ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Optimisation légère de `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Mise en cache de plus d'accès aux champs dans std Map et Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimisation pour les puissances de deux dans `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
 
 ### Autre
 

From 5badcf025b7bf83615046c3aba85fa2e9acbda3b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 03:32:47 -0500
Subject: [PATCH 3481/3820] New translations assemblyscript-migration-guide.mdx
 (French)

---
 .../assemblyscript-migration-guide.mdx        | 78 +++++++++----------
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx
index 58c18e390690..768459fdb8d3 100644
--- a/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/fr/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -39,12 +39,12 @@ Ce guide s'applique à tous ceux qui utilisent `graph-cli`/`graph-ts` en dessous
 
 ### Autre
 
-- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Le type d'un de tableau d'éléments peut maintenant être déduit de son contenu ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Mise à jour de la stdlib vers Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
 
 ## Comment mettre à niveau ?
 
-1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+1. Changez vos mappages `apiVersion` dans `subgraph.yaml` en `0.0.6` :
 
 ```yaml
 ...
@@ -56,7 +56,7 @@ dataSources:
       ...
 ```
 
-2. Update the `graph-cli` you're using to the `latest` version by running:
+2. Mettez à jour le `graph-cli` que vous utilisez avec la version la plus récente en exécutant :
 
 ```bash
 # si vous l'avez installé globalement
@@ -66,14 +66,14 @@ npm install --global @graphprotocol/graph-cli@latest
 npm install --save-dev @graphprotocol/graph-cli@latest
 ```
 
-3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+3. Faites la même chose pour `graph-ts`, mais au lieu de l'installer globalement, sauvegardez-le dans vos dépendances principales :
 
 ```bash
 npm install --save @graphprotocol/graph-ts@latest
 ```
 
 4. Suivez le reste du guide pour corriger les changements de langue.
-5. Run `codegen` and `deploy` again.
+5. Exécutez `codegen` et `deploy` à nouveau.
 
 ## Modifications radicales
 
@@ -110,7 +110,7 @@ Si vous ne savez pas lequel choisir, nous vous recommandons de toujours utiliser
 
 ### Ombrage variable
 
-Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+Auparavant, vous pouviez faire un [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) et un code comme celui-ci fonctionnait :
 
 ```typescript
 let a = 10
@@ -141,12 +141,12 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
  in src/mappings/file.ts(41,21)
 ```
 
-To solve you can simply change the `if` statement to something like this:
+Pour résoudre ce problème, il suffit de modifier l'instruction `if` en quelque chose comme ceci :
 
 ```typescript
   if (!decimals) {
 
-  // or
+  // ou
 
   if (decimals === null) {
 ```
@@ -155,16 +155,16 @@ La même chose s'applique si vous faites != au lieu de ==.
 
 ### Casting
 
-The common way to do casting before was to just use the `as` keyword, like this:
+Auparavant, la façon la plus courante d'effectuer une conversion de type était d'utiliser le mot-clé `as`, comme ceci :
 
 ```typescript
 let byteArray = new ByteArray(10)
-let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
+let uint8Array = byteArray as Uint8Array // équivalent à : <Uint8Array>byteArray
 ```
 
 Cependant, cela ne fonctionne que dans deux scénarios :
 
-- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Conversion des types primitifs (entre des types tels que `u8`, `i32`, `bool` ; ex : `let b : isize = 10 ; b as usize`) ;
 - Upcasting sur l'héritage de classe (sous-classe → superclasse)
 
 Les Exemples:
@@ -177,55 +177,55 @@ let c: usize = a + (b as usize)
 ```
 
 ```typescript
-// upcasting on class inheritance
+// conversion vers le type parent dans l'héritage des classes
 class Bytes extends Uint8Array {}
 
 let bytes = new Bytes(2)
-// <Uint8Array>bytes // same as: bytes as Uint8Array
+// <Uint8Array>bytes // idem que: bytes as Uint8Array
 ```
 
-There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+Il y a deux cas de figure où l'on peut vouloir faire une conversion de type, mais l'utilisation de `as`/`<T>var` **n'est pas sûre** :
 
 - Downcasting sur l'héritage de classe (superclasse → sous-classe)
 - Entre deux types qui partagent une superclasse
 
 ```typescript
-// downcasting on class inheritance
+// conversion vers le type enfant dans l'héritage des classes
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-// <Bytes>uint8Array // breaks in runtime :(
+// <Bytes>uint8Array // crash l'exécution :(
 ```
 
 ```typescript
-// between two types that share a superclass
+// entre deux types qui partagent la même superclasse
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
 let bytes = new Bytes(2)
-// <ByteArray>bytes // breaks in runtime :(
+// <ByteArray>bytes // crash à l'exécution :(
 ```
 
-For those cases, you can use the `changetype<T>` function:
+Dans ce cas, vous pouvez utiliser la fonction `changetype<T>` :
 
 ```typescript
-// downcasting on class inheritance
+// conversion vers le type enfant dans l'héritage des classes
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-changetype<Bytes>(uint8Array) // works :)
+changetype<Bytes>(uint8Array) // fonctionne :)
 ```
 
 ```typescript
-// between two types that share a superclass
+// entre deux types qui partagent une même superclasse
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
 let bytes = new Bytes(2)
-changetype<ByteArray>(bytes) // works :)
+changetype<ByteArray>(bytes) // fonctionne :)
 ```
 
-If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+Si vous voulez juste supprimer la nullité, vous pouvez continuer à utiliser l'opérateur `as` (ou `<T>variable`), mais assurez-vous que vous savez que la valeur ne peut pas être nulle, sinon cela causera un crash.
 
 ```typescript
 // supprimer la possibilité de valeur nulle (nullability)
@@ -238,7 +238,7 @@ if (previousBalance != null) {
 let newBalance = new AccountBalance(balanceId)
 ```
 
-For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+Pour le cas de la nullité, nous recommandons de jeter un coup d'œil à la [fonction de vérification de la nullité](https://www.assemblyscript.org/basics.html#nullability-checks), cela rendra votre code plus propre 🙂
 
 Nous avons également ajouté quelques méthodes statiques supplémentaires dans certains types pour faciliter la diffusion, à savoir :
 
@@ -249,7 +249,7 @@ Nous avons également ajouté quelques méthodes statiques supplémentaires dans
 
 ### Vérification de nullité avec accès à la propriété
 
-To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+Pour utiliser la [fonction de vérification de la nullité](https://www.assemblyscript.org/basics.html#nullability-checks), vous pouvez utiliser les instructions `if` ou l'opérateur ternaire (`?` et `:`) comme suit :
 
 ```typescript
 let something: string | null = 'data'
@@ -267,7 +267,7 @@ if (something) {
 }
 ```
 
-However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+Cependant, cela ne fonctionne que lorsque vous faites le `if` / ternaire sur une variable, et non sur l'accès à une propriété, comme ceci :
 
 ```typescript
 class Container {
@@ -380,7 +380,7 @@ if (total === null) {
 total.amount = total.amount + BigInt.fromI32(1)
 ```
 
-You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+Vous devez vous assurer d'initialiser la valeur `total.amount`, car si vous essayez d'y accéder comme dans la dernière ligne pour la somme, cela va planter. Il faut donc d'abord l'initialiser :
 
 ```typescript
 let total = Total.load('latest')
@@ -393,7 +393,7 @@ if (total === null) {
 total.tokens = total.tokens + BigInt.fromI32(1)
 ```
 
-Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+Ou vous pouvez simplement changer votre schéma GraphQL pour ne pas utiliser un type nullable pour cette propriété, puis nous l'initialiserons à zéro à l'étape `codegen` 😉
 
 ```graphql
 type Total @entity {
@@ -424,7 +424,7 @@ export class Something {
 }
 ```
 
-The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+Le compilateur génèrera une erreur car vous devez soit ajouter un initialisateur pour les propriétés qui sont des classes, soit ajouter l'opérateur `!` :
 
 ```typescript
 export class Something {
@@ -450,12 +450,12 @@ export class Something {
 
 ### Initialisation du tableau
 
-The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+La classe `Array` accepte toujours un nombre pour initialiser la longueur de la liste, cependant vous devez faire attention car des opérations comme `.push` vont en fait augmenter la taille au lieu d'ajouter au début, par exemple :
 
 ```typescript
 let arr = new Array<string>(5) // ["", "", "", "", ""]
 
-arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+arr.push('something') // ["", "", "", "", "", "something"] // taille 6 :(
 ```
 
 En fonction des types que vous utilisez, par exemple les types nullables, et de la manière dont vous y accédez, vous pourriez rencontrer une erreur d'exécution comme celle-ci :
@@ -464,7 +464,7 @@ En fonction des types que vous utilisez, par exemple les types nullables, et de
 ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
 ```
 
-To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+Pour pousser au début, vous devez soit initialiser le `Tableau` avec une taille de zéro, comme ceci :
 
 ```typescript
 let arr = new Array<string>(0) // []
@@ -510,14 +510,14 @@ type MyEntity @entity {
 }
 ```
 
-This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+Cela a changé à cause des différences de nullité entre les versions d'AssemblyScript, et c'est lié au fichier `src/generated/schema.ts` (chemin par défaut, vous pouvez l'avoir changé).
 
 ### Autre
 
 - Alignement de `Map#set` et `Set#add` avec la spécification, retournant `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
-- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Les tableaux n'héritent plus de ArrayBufferView, mais sont désormais distincts ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Les classes initialisées à partir d'objets littéraux ne peuvent plus définir de constructeur ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
 - Le résultat d'une opération binaire `**` est maintenant l'entier de dénominateur commun si les deux opérandes sont des entiers. Auparavant, le résultat était un flottant comme si l'on appelait `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
 - Contraindre `NaN` à `false` lors d'une conversion de type vers `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
-- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
-- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Lors du déplacement d'une petite valeur entière de type `i8`/`u8` ou `i16`/`u16`, seuls les 3 ou 4 bits les moins significatifs de la valeur RHS affectent le résultat, de manière analogue au résultat d'un `i32.shl` qui n'est affecté que par les 5 bits les moins significatifs de la valeur RHS. Exemple : `someI8 << 8` produisait auparavant la valeur `0`, mais produit maintenant `someI8` à cause du masquage de la valeur RHS comme `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- Correction d'un bug dans les comparaisons de chaînes de caractères relationnelles lorsque les tailles sont différentes ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 42be69ee2f785a7b33eb83b2fd33e088824909a0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 04:34:02 -0500
Subject: [PATCH 3482/3820] New translations new-chain-integration.mdx (French)

---
 website/pages/fr/indexing/new-chain-integration.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/fr/indexing/new-chain-integration.mdx b/website/pages/fr/indexing/new-chain-integration.mdx
index c2e13431e110..3972e7bc5ef5 100644
--- a/website/pages/fr/indexing/new-chain-integration.mdx
+++ b/website/pages/fr/indexing/new-chain-integration.mdx
@@ -25,7 +25,7 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(limited tracing and optionally required for Graph Node)_
+- `trace_filter` _(traçage limité et optionnellement requis pour Graph Node)_
 
 ### 2. Firehose Integration
 
@@ -33,11 +33,11 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 
 > NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
 
-#### Integration for Non-EVM chains
+#### Intégration pour les Blockchains non EVM
 
 The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
 
-#### Specific Instrumentation for EVM (`geth`) chains
+#### Instrumentation spécifique pour les Blockchains EVM (`geth`)
 
 For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
 
@@ -59,7 +59,7 @@ Configuring Graph Node is as easy as preparing your local environment. Once your
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
+2. Modifier [cette ligne] (https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) pour inclure le nouveau nom du réseau et l'URL JSON-RPC ou Firehose de l'EVM.
 
    > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
 

From 31fa69c672f9b72ca5e78549fdf349f4b59b767e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 05:44:31 -0500
Subject: [PATCH 3483/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 46 +++++++++++++-------------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
index 4b750f58707d..322fb559f434 100644
--- a/website/pages/de/indexing/overview.mdx
+++ b/website/pages/de/indexing/overview.mdx
@@ -65,15 +65,15 @@ Verwenden Sie Etherscan, um `getRewards()` aufzurufen:
 <!---->
 
 - Um `getRewards()` aufzurufen:
-  - Expand the **9. getRewards** dropdown.
-  - Enter the **allocationID** in the input.
-  - Click the **Query** button.
+  - Erweitern Sie das Dropdown-Menü **9. getRewards**.
+  - Geben Sie die **allocationID** in die Eingabe ein.
+  - Klicken Sie auf die Schaltfläche **Abfrage**.
 
-### What are disputes and where can I view them?
+### Was sind Streitigkeiten und wo kann ich sie einsehen?
 
 Indexer's queries and allocations can both be disputed on The Graph during the dispute period. The dispute period varies, depending on the type of dispute. Queries/attestations have 7 epochs dispute window, whereas allocations have 56 epochs. After these periods pass, disputes cannot be opened against either of allocations or queries. When a dispute is opened, a deposit of a minimum of 10,000 GRT is required by the Fishermen, which will be locked until the dispute is finalized and a resolution has been given. Fisherman are any network participants that open disputes.
 
-Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+Bei Streitigkeiten gibt es **drei** mögliche Ergebnisse, so auch bei der Kaution der Fischer.
 
 - If the dispute is rejected, the GRT deposited by the Fishermen will be burned, and the disputed Indexer will not be slashed.
 - If the dispute is settled as a draw, the Fishermen's deposit will be returned, and the disputed Indexer will not be slashed.
@@ -83,49 +83,49 @@ Disputes can be viewed in the UI in an Indexer's profile page under the `Dispute
 
 ### What are query fee rebates and when are they distributed?
 
-Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+Die Abfragegebühren werden vom Gateway eingezogen und gemäß der exponentiellen Rabattfunktion an die Indexer verteilt (siehe GIP [hier](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). Die exponentielle Rabattfunktion wird vorgeschlagen, um sicherzustellen, dass Indexer das beste Ergebnis erzielen, indem sie Abfragen treu bedienen. Sie schafft Anreize für Indexer, einen hohen Einsatz (der bei Fehlern bei der Bedienung einer Anfrage gekürzt werden kann) im Verhältnis zur Höhe der Abfragegebühren, die sie einnehmen können, bereitzustellen.
 
-Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+Sobald eine Zuteilung abgeschlossen ist, können die Rabatte vom Indexer beansprucht werden. Nach der Beantragung werden die Abfragegebührenrabatte auf der Grundlage der Abfragegebührenkürzung und der exponentiellen Rabattfunktion an den Indexer und seine Delegatoren verteilt.
 
 ### What is query fee cut and indexing reward cut?
 
-The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/indexing/overview/#stake-in-the-protocol) for instructions on setting the delegation parameters.
+Die Werte `queryFeeCut` und `indexingRewardCut` sind Delegationsparameter, die der Indexer zusammen mit cooldownBlocks setzen kann, um die Verteilung von GRT zwischen dem Indexer und seinen Delegatoren zu kontrollieren. Siehe die letzten Schritte in [Staking im Protokoll](/indexing/overview/#stake-in-the-protocol) für Anweisungen zur Einstellung der Delegationsparameter.
 
-- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+- **queryFeeCut** - der Prozentsatz der Rückerstattungen von Abfragegebühren, der an den Indexer verteilt wird. Wenn dieser Wert auf 95 % gesetzt ist, erhält der Indexer 95 % der Abfragegebühren, die beim Abschluss einer Zuteilung anfallen, während die restlichen 5 % an die Delegatoren gehen.
 
-- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+- **indexingRewardCut** - der Prozentsatz der Indizierung Rewards, der an den Indexer verteilt wird. Wenn dieser Wert auf 95 % gesetzt ist, erhält der Indexer 95 % der Rewards für die Indizierung, wenn eine Zuweisung abgeschlossen wird, und die Delegatoren teilen sich die restlichen 5 %.
 
 ### How do Indexers know which subgraphs to index?
 
 Indexers may differentiate themselves by applying advanced techniques for making subgraph indexing decisions but to give a general idea we'll discuss several key metrics used to evaluate subgraphs in the network:
 
-- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+- **Kurationssignal** - Der Anteil des Netzwerkkurationssignals, der auf einen bestimmten Subgraphen angewandt wird, ist ein guter Indikator für das Interesse an diesem Subgraphen, insbesondere während der Bootstrap-Phase, wenn das Abfragevolumen ansteigt.
 
-- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+- **Eingezogene Abfragegebühren** - Die historischen Daten zum Volumen der eingezogenen Abfragegebühren für einen bestimmten Subgraphen sind ein guter Indikator für die künftige Nachfrage.
 
-- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+- **Einsatzhöhe** - Die Beobachtung des Verhaltens anderer Indexer oder die Betrachtung des Anteils am Gesamteinsatz, der bestimmten Subgraphen zugewiesen wird, kann es einem Indexer ermöglichen, die Angebotsseite für Subgraphenabfragen zu überwachen, um Subgraphen zu identifizieren, in die das Netzwerk Vertrauen zeigt, oder Subgraphen, die möglicherweise einen Bedarf an mehr Angebot aufweisen.
 
-- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+- **Subgraphen ohne Indexer Rewards** - Einige Subgraphen erzeugen keine Indexer Rewards, hauptsächlich weil sie nicht unterstützte Funktionen wie IPFS verwenden oder weil sie ein anderes Netzwerk außerhalb des Hauptnetzes abfragen. Wenn ein Subgraph keine Indexing Rewards generiert, wird eine entsprechende Meldung angezeigt.
 
 ### What are the hardware requirements?
 
-- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
-- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
-- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
-- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+- **Small** - Ausreichend, um mit der Indizierung mehrerer Subgraphen zu beginnen, wird wahrscheinlich erweitert werden müssen.
+- **Standard** - Standardeinstellung, die in den Datenbeispielen für die k8s/terraform-Bereitstellungsmanifeste verwendet wird.
+- **Medium** - Produktions-Indexer, der 100 Subgraphen und 200-500 Anfragen pro Sekunde unterstützt.
+- **Large** - Vorbereitet, um alle derzeit verwendeten Subgraphen zu indizieren und Anfragen für den entsprechenden Verkehr zu bedienen.
 
 | Konfiguration | Postgres<br />(CPUs) | Postgres<br />(Speicher in GB) | Postgres<br />(Festplatte in TB) | VMs<br />(CPUs) | VMs<br />(Speicher in GB) |
 | ------------- | :------------------: | :----------------------------: | :------------------------------: | :-------------: | :-----------------------: |
-| Klein         |           4          |                8               |                 1                |        4        |             16            |
+| Small         |           4          |                8               |                 1                |        4        |             16            |
 | Standard      |           8          |               30               |                 1                |        12       |             48            |
-| Mittel        |          16          |               64               |                 2                |        32       |             64            |
-| Groß          |          72          |               468              |                3.5               |        48       |            184            |
+| Medium        |          16          |               64               |                 2                |        32       |             64            |
+| Large         |          72          |               468              |                3.5               |        48       |            184            |
 
 ### What are some basic security precautions an Indexer should take?
 
-- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/indexing/overview/#stake-in-the-protocol) for instructions.
+- **Operator Wallet** - Die Einrichtung einer Operator Wallet ist eine wichtige Vorsichtsmaßnahme, da sie es einem Indexer ermöglicht, eine Trennung zwischen seinen Schlüsseln, die den Einsatz kontrollieren, und den Schlüsseln, die für den täglichen Betrieb zuständig sind, aufrechtzuerhalten. Siehe [Stake im Protocol](/indexing/overview/#stake-in-the-protocol) für Anweisungen.
 
-- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+- **Firewall** - Nur der Indexer-Dienst muss öffentlich zugänglich gemacht werden, und es sollte besonders darauf geachtet werden, die Admin-Ports und den Datenbankzugriff zu sperren: The Graph Node JSON-RPC-Endpunkt (Standard-Port: 8030), der Indexer-Management-API-Endpunkt (Standard-Port: 18000) und der Postgres-Datenbank-Endpunkt (Standard-Port: 5432) sollten nicht öffentlich zugänglich sein.
 
 ## Infrastruktur
 

From ff5fa62e81caa282b196978d07195a11bf62a7af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 07:28:10 -0500
Subject: [PATCH 3484/3820] New translations chain-integration-overview.mdx
 (French)

---
 website/pages/fr/indexing/chain-integration-overview.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/fr/indexing/chain-integration-overview.mdx b/website/pages/fr/indexing/chain-integration-overview.mdx
index dc508e2083af..f4a3aba25717 100644
--- a/website/pages/fr/indexing/chain-integration-overview.mdx
+++ b/website/pages/fr/indexing/chain-integration-overview.mdx
@@ -11,7 +11,7 @@ Un processus d'intégration transparent et basé sur la gouvernance a été con
 
 ## Étape 2. Validation de l'intégration
 
-- Teams collaborate with core developers, Graph Foundation and operators of GUIs and network gateways, such as [Subgraph Studio](https://thegraph.com/studio/), to ensure a smooth integration process. This involves providing the necessary backend infrastructure, such as the integrating chain's JSON-RPC, Firehose or Substreams endpoints. Teams wanting to avoid self-hosting such infrastructure can leverage The Graph's community of node operators (Indexers) to do so, which the Foundation can help with.
+- Les équipes collaborent avec les développeurs principaux, Graph Foundation et les opérateurs de GUIs et de passerelles réseau, tels que [Subgraph Studio](https://thegraph.com/studio/), pour assurer un processus d'intégration fluide. Cela implique de fournir l'infrastructure back-end nécessaire, comme les points de terminaison JSON-RPC, Firehose ou Substreams de la chaîne d'intégration. Les équipes souhaitant éviter d'héberger elles-mêmes une telle infrastructure peuvent s'appuyer sur la communauté d'opérateurs de nœuds (indexeurs) de The Graph pour ce faire, avec l'aide de la Fondation.
 - Les Graph Indexeurs testent l'intégration sur le réseau de testnet du graph.
 - Les développeurs principaux et les indexeurs surveillent la stabilité, les performances et le déterminisme des données.
 
@@ -38,7 +38,7 @@ Ce processus est lié au service de données Subgraph, applicable uniquement aux
 
 Cela n’aurait un impact que sur la prise en charge du protocole pour l’indexation des récompenses sur les subgraphs alimentés par Substreams. La nouvelle implémentation de Firehose nécessiterait des tests sur testnet, en suivant la méthodologie décrite pour l'étape 2 de ce GIP. De même, en supposant que l'implémentation soit performante et fiable, un PR sur la [Matrice de support des fonctionnalités](https://github.com/graphprotocol/indexer/blob/main/docs/feature-support-matrix.md) serait requis ( Fonctionnalité de sous-graphe « Sous-flux de sources de données »), ainsi qu'un nouveau GIP pour la prise en charge du protocole pour l'indexation des récompenses. N'importe qui peut créer le PR et le GIP ; la Fondation aiderait à obtenir l'approbation du Conseil.
 
-### 3. How much time will the process of reaching full protocol support take?
+### 3. Combien de temps faudra-t-il pour parvenir à la prise en charge complète du protocole ?
 
 Le temps nécessaire à la mise en réseau principal devrait être de plusieurs semaines, variant en fonction du temps de développement de l'intégration, de la nécessité ou non de recherches supplémentaires, de tests et de corrections de bugs et, comme toujours, du calendrier du processus de gouvernance qui nécessite les commentaires de la communauté.
 

From 4b43da499d1cdfa17bfc30c1c9895086bd316da0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 07:28:12 -0500
Subject: [PATCH 3485/3820] New translations new-chain-integration.mdx (French)

---
 website/pages/fr/indexing/new-chain-integration.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/fr/indexing/new-chain-integration.mdx b/website/pages/fr/indexing/new-chain-integration.mdx
index 3972e7bc5ef5..7dbe897084be 100644
--- a/website/pages/fr/indexing/new-chain-integration.mdx
+++ b/website/pages/fr/indexing/new-chain-integration.mdx
@@ -1,8 +1,8 @@
 ---
-title: New Chain Integration
+title: Intégration d'une Nouvelle Chaîne
 ---
 
-Chains can bring subgraph support to their ecosystem by starting a new `graph-node` integration. Subgraphs are a powerful indexing tool opening a world of possibilities for developers. Graph Node already indexes data from the chains listed here. If you are interested in a new integration, there are 2 integration strategies:
+Les chaînes peuvent apporter le support des subgraphs à leur écosystème en démarrant une nouvelle intégration `graph-node`. Les subgraphs sont un outil d'indexation puissant qui ouvre un monde de possibilités pour les développeurs. Graph Node indexe déjà les données des chaînes listées ici. Si vous êtes intéressé par une nouvelle intégration, il existe 2 stratégies d'intégration :
 
 1. **EVM JSON-RPC**
 2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
@@ -20,7 +20,7 @@ If the blockchain is EVM equivalent and the client/node exposes the standard EVM
 For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
 
 - `eth_getLogs`
-- `eth_call` (for historical blocks, with EIP-1898 - requires archive node)
+- `eth_call` (pour les blocs historiques, avec EIP-1898 - nécessite un nœud d'archivage)
 - `eth_getBlockByNumber`
 - `eth_getBlockByHash`
 - `net_version`

From e98b7b727547011dd87bb806dcde16a6d8f2bc2c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 07:28:13 -0500
Subject: [PATCH 3486/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 68 +++++++++++++-------------
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
index 322fb559f434..35b72e33a1c0 100644
--- a/website/pages/de/indexing/overview.mdx
+++ b/website/pages/de/indexing/overview.mdx
@@ -129,29 +129,29 @@ Indexers may differentiate themselves by applying advanced techniques for making
 
 ## Infrastruktur
 
-At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+Im Zentrum der Infrastruktur eines Indexers steht der Graph Node, der die indizierten Netzwerke überwacht, Daten gemäß einer Subgraph-Definition extrahiert und lädt und sie als [GraphQL API](/about/#how-the-graph-works) bereitstellt. Der Graph Node muss mit einem Endpunkt verbunden sein, der Daten aus jedem indizierten Netzwerk ausgibt; einem IPFS-Knoten für die Datenbeschaffung; einer PostgreSQL-Datenbank für ihre Speicherung; und Indexer-Komponenten, die seine Interaktionen mit dem Netzwerk erleichtern.
 
-- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+- **PostgreSQL-Datenbank** - Der Hauptspeicher für den Graph Node, in dem die Subgraph-Daten gespeichert werden. Der Indexer-Dienst und der Agent nutzen die Datenbank auch zum Speichern von Statuskanaldaten, Kostenmodellen, Indizierungsregeln und Zuordnungsaktionen.
 
-- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+- **Datenendpunkt** - Bei EVM-kompatiblen Netzwerken muss der Graph Node mit einem Endpunkt verbunden sein, der eine EVM-kompatible JSON-RPC-API bereitstellt. Dabei kann es sich um einen einzelnen Client handeln oder um ein komplexeres Setup, das die Last auf mehrere Clients verteilt. Es ist wichtig, sich darüber im Klaren zu sein, dass bestimmte Subgraphen bestimmte Client-Funktionen erfordern, wie z. B. den Archivmodus und/oder die Paritätsverfolgungs-API.
 
-- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+- **IPFS-Knoten (Version kleiner als 5)** - Die Metadaten für die Bereitstellung von Subgraphen werden im IPFS-Netzwerk gespeichert. Der Graph Node greift während der Subgraph-Bereitstellung hauptsächlich auf den IPFS-Knoten zu, um das Subgraph-Manifest und alle verknüpften Dateien zu holen. Netzwerk-Indexer brauchen keinen eigenen IPFS-Knoten zu hosten, ein IPFS-Knoten für das Netzwerk wird unter https://ipfs.network.thegraph.com gehostet.
 
-- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+- **Indexer-Dienst** - Erledigt alle erforderlichen externen Kommunikationen mit dem Netz. Teilt Kostenmodelle und Indizierungsstatus, leitet Abfrageanfragen von Gateways an einen Graph Node weiter und verwaltet die Abfragezahlungen über Statuskanäle mit dem Gateway.
 
-- **Indexer agent** - Facilitates the Indexers interactions onchain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Indexer-Agent** - Erleichtert die Interaktionen des Indexers in der Kette, einschließlich der Registrierung im Netzwerk, der Verwaltung von Subgraph-Bereitstellungen an seine(n) Graph-Knoten und der Verwaltung von Zuweisungen.
 
-- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+- **Prometheus Metrics Server** - Die Komponenten Graph Node und Indexer protokollieren ihre Metriken auf dem Metrics Server.
 
-Note: To support agile scaling, it is recommended that query and indexing concerns are separated between different sets of nodes: query nodes and index nodes.
+Hinweis: Um eine agile Skalierung zu unterstützen, wird empfohlen, Abfrage- und Indizierungsbelange zwischen verschiedenen Gruppen von Knoten zu trennen: Abfrageknoten und Indexknoten.
 
 ### Ports overview
 
-> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+> **Wichtig**: Seien Sie vorsichtig damit, Ports öffentlich zugänglich zu machen - **Verwaltungsports** sollten unter Verschluss gehalten werden. Dies gilt auch für den Graph Node JSON-RPC und die Indexer-Verwaltungsendpunkte, die im Folgenden beschrieben werden.
 
 #### Graph Node
 
-| Port | Zweck                                           | Routen                                         | CLI-Argument       | Umgebungsvariable |
+| Port | Verwendungszweck                                | Routen                                         | CLI-Argument       | Umgebungsvariable |
 | ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | ----------------- |
 | 8000 | GraphQL HTTP-Server<br />(für Subgraf-Abfragen) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                 |
 | 8001 | GraphQL WS<br />(für Subgraf-Abonnements)       | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                 |
@@ -161,38 +161,38 @@ Note: To support agile scaling, it is recommended that query and indexing concer
 
 #### Indexer Service
 
-| Port | Zweck                                                            | Routen                                                      | CLI-Argument    | Umgebungsvariable      |
+| Port | Verwendungszweck                                                 | Routen                                                      | CLI-Argument    | Umgebungsvariable      |
 | ---- | ---------------------------------------------------------------- | ----------------------------------------------------------- | --------------- | ---------------------- |
 | 7600 | GraphQL-HTTP-Server<br />(für kostenpflichtige Subgraf-Abfragen) | /subgraphs/id/...<br />/status<br />/channel-messages-inbox | \--port         | `INDEXER_SERVICE_PORT` |
 | 7300 | Prometheus-Metriken                                              | /metrics                                                    | \--metrics-port | -                      |
 
 #### Indexer Agent
 
-| Port | Purpose                 | Routen | CLI Argument               | Environment Variable                    |
-| ---- | ----------------------- | ------ | -------------------------- | --------------------------------------- |
-| 8000 | Indexer-Verwaltungs-API | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+| Port | Verwendungszweck                | Routen | CLI Argument               | Umgebungsvariable                       |
+| ---- | ------------------------------- | ------ | -------------------------- | --------------------------------------- |
+| 8000 | Indexer-Verwaltungs-API         | /      | \--indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
 
 ### Setup server infrastructure using Terraform on Google Cloud
 
 > Note: Indexers can alternatively use AWS, Microsoft Azure, or Alibaba.
 
-#### Installieren Sie die Voraussetzungen
+#### Install prerequisites
 
-- Google Cloud-SDK
-- Kubectl-Befehlszeilentool
+- Google Cloud SDK
+- Kubectl command line tool
 - Terraform
 
 #### Create a Google Cloud Project
 
-- Clone or navigate to the [Indexer repository](https://github.com/graphprotocol/indexer).
+- Klonen oder navigieren Sie zum [Indexer-Repository] (https://github.com/graphprotocol/indexer).
 
-- Navigate to the `./terraform` directory, this is where all commands should be executed.
+- Navigieren Sie zum Verzeichnis `./terraform`, in dem alle Befehle ausgeführt werden sollen.
 
 ```sh
 cd terraform
 ```
 
-- Authentifizieren Sie sich bei Google Cloud und erstellen Sie ein neues Projekt.
+- Authenticate with Google Cloud and create a new project.
 
 ```sh
 gcloud auth login
@@ -200,9 +200,9 @@ project=<PROJECT_NAME>
 gcloud projects create --enable-cloud-apis $project
 ```
 
-- Aktivieren Sie die Abrechnung für das neue Projekt auf der Abrechnungsseite der Google Cloud Console.
+- Use the Google Cloud Console's billing page to enable billing for the new project.
 
-- Erstellen Sie eine Google Cloud-Konfiguration.
+- Create a Google Cloud configuration.
 
 ```sh
 proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
@@ -212,7 +212,7 @@ gcloud config set compute/region us-central1
 gcloud config set compute/zone us-central1-a
 ```
 
-- Aktivieren Sie die erforderlichen Google Cloud-APIs.
+- Enable required Google Cloud APIs.
 
 ```sh
 gcloud services enable compute.googleapis.com
@@ -264,9 +264,9 @@ database_password = "<database password>"
 EOF
 ```
 
-#### Verwenden Sie Terraform zum Erstellen einer Infrastruktur
+#### Use Terraform to create infrastructure
 
-Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+Bevor Sie irgendwelche Befehle ausführen, lesen Sie [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) und erstellen Sie eine Datei `terraform.tfvars` in diesem Verzeichnis (oder ändern Sie die im letzten Schritt erstellte Datei). Für jede Variable, bei der Sie die Standardeinstellung überschreiben oder einen Wert festlegen möchten, geben Sie eine Einstellung in `terraform.tfvars` ein.
 
 - Run the following commands to create the infrastructure.
 
@@ -281,7 +281,7 @@ terraform plan
 terraform apply
 ```
 
-Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+Laden Sie die Anmeldedaten für den neuen Cluster in `~/.kube/config` herunter und setzen Sie ihn als Standardkontext.
 
 ```sh
 gcloud container clusters get-credentials $indexer
@@ -291,19 +291,19 @@ kubectl config use-context $(kubectl config get-contexts --output='name'
 
 #### Creating the Kubernetes components for the Indexer
 
-- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+- Kopieren Sie das Verzeichnis `k8s/overlays` in ein neues Verzeichnis `$dir,` und passen Sie den Eintrag `bases` in `$dir/kustomization.yaml` so an, dass er auf das Verzeichnis `k8s/base` zeigt.
 
-- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+- Lesen Sie alle Dateien in `$dir` durch und passen Sie alle Werte wie in den Kommentaren angegeben an.
 
-Deploy all resources with `kubectl apply -k $dir`.
+Stellen Sie alle Ressourcen mit `kubectl apply -k $dir` bereit.
 
 ### Graph Node
 
-[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the blockchain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+[Graph Node] (https://github.com/graphprotocol/graph-node) ist eine quelloffene Rust-Implementierung, die die Ethereum-Blockchain mit Ereignisquellen versorgt, um einen Datenspeicher deterministisch zu aktualisieren, der über den GraphQL-Endpunkt abgefragt werden kann. Entwickler verwenden Subgraphen, um ihr Schema zu definieren, sowie eine Reihe von Mappings zur Umwandlung der von der Blockchain bezogenen Daten. Der Graph Node übernimmt die Synchronisierung der gesamten Kette, die Überwachung auf neue Blöcke und die Bereitstellung über einen GraphQL-Endpunkt.
 
 #### Einstieg in den Sourcecode
 
-#### Installieren Sie die Voraussetzungen
+#### Install prerequisites
 
 - **Rust**
 
@@ -311,7 +311,7 @@ Deploy all resources with `kubectl apply -k $dir`.
 
 - **IPFS**
 
-- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+- **Zusätzliche Anforderungen für Ubuntu-Benutzer** - Um einen Graph Node unter Ubuntu zu betreiben, sind möglicherweise einige zusätzliche Pakete erforderlich.
 
 ```sh
 sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
@@ -327,9 +327,9 @@ pg_ctl -D .postgres -l logfile start
 createdb graph-node
 ```
 
-2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+2. Klonen Sie das [Graph Node](https://github.com/graphprotocol/graph-node)-Repository und erstellen Sie den Quellcode, indem Sie `cargo build` ausführen
 
-3. Nachdem alle Abhängigkeiten eingerichtet sind, starten Sie den Graph-Knoten:
+3. Now that all the dependencies are setup, start the Graph Node:
 
 ```sh
 cargo run -p graph-node --release -- \

From d6ba5dd43637154e07607162884597d3395200b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 07:28:14 -0500
Subject: [PATCH 3487/3820] New translations graph-node.mdx (German)

---
 website/pages/de/indexing/tooling/graph-node.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/de/indexing/tooling/graph-node.mdx b/website/pages/de/indexing/tooling/graph-node.mdx
index 313878e00384..3ef04a0af3c2 100644
--- a/website/pages/de/indexing/tooling/graph-node.mdx
+++ b/website/pages/de/indexing/tooling/graph-node.mdx
@@ -34,7 +34,7 @@ Um Überwachung und Berichterstellung zu ermöglichen, kann Graph Node optional
 
 ### Einstieg in den Sourcecode
 
-#### Installieren Sie die Voraussetzungen
+#### Install prerequisites
 
 - **Rust**
 
@@ -42,7 +42,7 @@ Um Überwachung und Berichterstellung zu ermöglichen, kann Graph Node optional
 
 - **IPFS**
 
-- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+- **Zusätzliche Anforderungen für Ubuntu-Benutzer** - Um einen Graph Node unter Ubuntu zu betreiben, sind möglicherweise einige zusätzliche Pakete erforderlich.
 
 ```sh
 sudo apt-get install -y clang libpq-dev libssl-dev pkg-config
@@ -58,9 +58,9 @@ pg_ctl -D .postgres -l logfile start
 createdb graph-node
 ```
 
-2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+2. Klonen Sie das [Graph Node](https://github.com/graphprotocol/graph-node)-Repository und erstellen Sie den Quellcode, indem Sie `cargo build` ausführen
 
-3. Nachdem alle Abhängigkeiten eingerichtet sind, starten Sie den Graph-Knoten:
+3. Now that all the dependencies are setup, start the Graph Node:
 
 ```sh
 cargo run -p graph-node --release -- \
@@ -77,7 +77,7 @@ A complete Kubernetes example configuration can be found in the [indexer reposit
 
 Wenn es ausgeführt wird, stellt Graph Node die folgenden Ports zur Verfügung:
 
-| Port | Zweck                                           | Routen                                         | CLI-Argument       | Umgebungsvariable |
+| Port | Verwendungszweck                                | Routen                                         | CLI-Argument       | Umgebungsvariable |
 | ---- | ----------------------------------------------- | ---------------------------------------------- | ------------------ | ----------------- |
 | 8000 | GraphQL HTTP-Server<br />(für Subgraf-Abfragen) | /subgraphs/id/...<br />/subgraphs/name/.../... | \--http-port       | -                 |
 | 8001 | GraphQL WS<br />(für Subgraf-Abonnements)       | /subgraphs/id/...<br />/subgraphs/name/.../... | \--ws-port         | -                 |

From 523c21054aaa3a7e530ea34ec37f76e80febfad0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 08:25:45 -0500
Subject: [PATCH 3488/3820] New translations chain-integration-overview.mdx
 (French)

---
 website/pages/fr/indexing/chain-integration-overview.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/indexing/chain-integration-overview.mdx b/website/pages/fr/indexing/chain-integration-overview.mdx
index f4a3aba25717..4bbb83bdc4a9 100644
--- a/website/pages/fr/indexing/chain-integration-overview.mdx
+++ b/website/pages/fr/indexing/chain-integration-overview.mdx
@@ -46,4 +46,4 @@ La prise en charge du protocole pour l'indexation des récompenses dépend de la
 
 ### 4. Comment les priorités seront-elles gérées ?
 
-Similar to #3, it will depend on overall readiness and involved stakeholders' bandwidth. For example, a new chain with a brand new Firehose implementation may take longer than integrations that have already been battle-tested or are farther along in the governance process.
+Comme pour le point #3, cela dépendra de l'état de préparation général et de la capacité des parties prenantes impliquées. Par exemple, une nouvelle chaîne avec une toute nouvelle implémentation de Firehose peut prendre plus de temps que des intégrations qui ont déjà été testées sur le terrain ou qui sont plus avancées dans le processus de gouvernance.

From da377e53838377ab55f74add78481c2337eaf46c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 08:25:46 -0500
Subject: [PATCH 3489/3820] New translations new-chain-integration.mdx (French)

---
 .../fr/indexing/new-chain-integration.mdx     | 38 +++++++++----------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/website/pages/fr/indexing/new-chain-integration.mdx b/website/pages/fr/indexing/new-chain-integration.mdx
index 7dbe897084be..9ac16c2a71e9 100644
--- a/website/pages/fr/indexing/new-chain-integration.mdx
+++ b/website/pages/fr/indexing/new-chain-integration.mdx
@@ -5,19 +5,19 @@ title: Intégration d'une Nouvelle Chaîne
 Les chaînes peuvent apporter le support des subgraphs à leur écosystème en démarrant une nouvelle intégration `graph-node`. Les subgraphs sont un outil d'indexation puissant qui ouvre un monde de possibilités pour les développeurs. Graph Node indexe déjà les données des chaînes listées ici. Si vous êtes intéressé par une nouvelle intégration, il existe 2 stratégies d'intégration :
 
 1. **EVM JSON-RPC**
-2. **Firehose**: All Firehose integration solutions include Substreams, a large-scale streaming engine based off Firehose with native `graph-node` support, allowing for parallelized transforms.
+2. **Firehose** : toutes les solutions d'intégration Firehose incluent Substreams, un moteur de streaming à grande échelle basé sur Firehose avec prise en charge native de `graph-node`, permettant des transformations parallélisées.
 
-> Note that while the recommended approach is to develop a new Firehose for all new chains, it is only required for non-EVM chains.
+> Notez que même si l’approche recommandée consiste à développer un nouveau Firehose pour toutes les nouvelles chaînes, elle n’est requise que pour les chaînes non EVM.
 
-## Integration Strategies
+## Stratégies d'intégration
 
 ### 1. EVM JSON-RPC
 
-If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain.
+Si la blockchain est équivalente à EVM et que le client/nœud expose l'API JSON-RPC EVM standard, Graph Node devrait pouvoir indexer la nouvelle chaîne.
 
 #### Tester un EVM JSON-RPC
 
-For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON-RPC methods:
+Afin que Graph Node puisse ingérer des données provenant d'une chaîne EVM, le nœud RPC doit exposer les méthodes JSON-RPC EVM suivantes :
 
 - `eth_getLogs`
 - `eth_call` (pour les blocs historiques, avec EIP-1898 - nécessite un nœud d'archivage)
@@ -27,44 +27,44 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
 - `trace_filter` _(traçage limité et optionnellement requis pour Graph Node)_
 
-### 2. Firehose Integration
+### 2. Intégration Firehose
 
-[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) is a next-generation extraction layer. It collects history in flat files and streams in real time. Firehose technology replaces those polling API calls with a stream of data utilizing a push model that sends data to the indexing node faster. This helps increase the speed of syncing and indexing.
+[Firehose](https://firehose.streamingfast.io/firehose-setup/overview) est une couche d'extraction de nouvelle génération. Elle collecte l'historique dans des fichiers plats et des flux en temps réel. La technologie Firehose remplace ces appels d'API d'interrogation par un flux de données utilisant un modèle push qui envoie les données au nœud d'indexation plus rapidement. Cela permet d'augmenter la vitesse de synchronisation et d'indexation.
 
-> NOTE: All integrations done by the StreamingFast team include maintenance for the Firehose replication protocol into the chain's codebase. StreamingFast tracks any changes and releases binaries when you change code and when StreamingFast changes code. This includes releasing Firehose/Substreams binaries for the protocol, maintaining Substreams modules for the block model of the chain, and releasing binaries for the blockchain node with instrumentation if need be.
+> REMARQUE : toutes les intégrations effectuées par l'équipe StreamingFast incluent la maintenance du protocole de réplication Firehose dans la base de code de la chaîne. StreamingFast suit toutes les modifications et publie les binaires lorsque vous modifiez le code et lorsque StreamingFast modifie le code. Cela comprend la publication des binaires Firehose/Substreams pour le protocole, la maintenance des modules Substreams pour le modèle de bloc de la chaîne et la publication des binaires pour le nœud de blockchain avec instrumentation si nécessaire.
 
-#### Intégration pour les Blockchains non EVM
+#### Intégration des Chaînes Non-EVM
 
-The primary method to integrate the Firehose into chains is to use an RPC polling strategy. Our polling algorithm will predict when a new block will arrive and increase the rate at which it checks for a new block near that time, making it a very low-latency and efficient solution. For help with the integration and maintenance of the Firehose, contact the [StreamingFast team](https://www.streamingfast.io/firehose-integration-program). New chains and their integrators will appreciate the [fork awareness](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) and massive parallelized indexing capabilities that Firehose and Substreams bring to their ecosystem.
+L’approche principale pour intégrer Firehose dans ces chaînes repose sur une stratégie de polling RPC. L'algorithme de polling prédit l’arrivée des nouveaux blocs et ajuste dynamiquement le taux d’interrogation, ce qui garantit une solution à très faible latence et efficace. Pour obtenir de l'aide concernant l'intégration et la maintenance du Firehose, contactez [l'équipe StreamingFast ](https://www.streamingfast.io/firehose-integration-program). Les nouvelles chaînes et leurs intégrateurs apprécieront [la gestion des forks](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) et les capacités massives d'indexation parallélisée que Firehose et Substreams apportent à leur écosystème.
 
 #### Instrumentation spécifique pour les Blockchains EVM (`geth`)
 
-For EVM chains, there exists a deeper level of data that can be achieved through the `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), a collaboration between Go-Ethereum and StreamingFast, in building a high-throughput and rich transaction tracing system. The Live Tracer is the most comprehensive solution, resulting in [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) block details. This enables new indexing paradigms, like pattern matching of events based on state changes, calls, parent call trees, or triggering of events based on changes to the actual variables in a smart contract.
+Pour les chaînes EVM, il existe un niveau de données plus approfondi qui peut être atteint grâce à `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), une collaboration entre Go-Ethereum et StreamingFast, dans la construction d'un système de traçage de transaction riche et à haut débit. Le Live Tracer est la solution la plus complète, qui permet d'obtenir des détails sur les blocs [Extended](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425). Cela permet de nouveaux paradigmes d'indexation, comme la recherche de modèles d'événements basés sur des changements d'état, des appels, des arbres d'appels parents, ou le déclenchement d'événements basés sur des changements de variables réelles dans un contrat intelligent.
 
 ![Base block vs Extended block](/img/extended-vs-base-substreams-blocks.png)
 
-> NOTE: This improvement upon the Firehose requires chains make use of the EVM engine `geth version 1.13.0` and up.
+> REMARQUE : cette amélioration du Firehose nécessite que les chaînes utilisent le moteur EVM `geth version 1.13.0` et supérieur.
 
-## EVM considerations - Difference between JSON-RPC & Firehose
+## Considérations sur EVM - Différence entre JSON-RPC et Firehose
 
 Bien que le JSON-RPC et le Firehose soient tous deux adaptés aux subgraphs, un Firehose est toujours nécessaire pour les développeurs qui souhaitent construire avec [Substreams](https://substreams.streamingfast.io). La prise en charge de Substreams permet aux développeurs de construire des [subgraphs alimentés par Substreams](/subgraphs/cookbook/substreams-powered-subgraphs/) pour la nouvelle chaîne, et a le potentiel d'améliorer les performances de vos subgraphs. De plus, Firehose - en tant que remplacement direct de la couche d'extraction JSON-RPC de `graph-node` - réduit de 90% le nombre d'appels RPC requis pour l'indexation générale.
 
-- All those `getLogs` calls and roundtrips get replaced by a single stream arriving into the heart of `graph-node`; a single block model for all subgraphs it processes.
+- Tous ces appels et allers-retours `getLogs` sont remplacés par un seul flux arrivant au cœur de `graph-node` ; un modèle de bloc unique pour tous les subgraphs qu'il traite.
 
-> NOTE: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that `eth_calls` are not a good practice for developers)
+> NOTEZ: une intégration basée sur Firehose pour les chaînes EVM nécessitera toujours que les indexeurs exécutent le nœud RPC d'archivage de la chaîne pour indexer correctement les subgraphs. Cela est dû à l'incapacité de Firehose à fournir un état de contrat intelligent généralement accessible par la méthode RPC `eth_calls`. (Il convient de rappeler que les `eth_call` ne sont pas une bonne pratique pour les développeurs)
 
 ## Configuration Graph Node
 
-Configuring Graph Node is as easy as preparing your local environment. Once your local environment is set, you can test the integration by locally deploying a subgraph.
+La configuration de Graph Node est aussi simple que la préparation de votre environnement local. Une fois votre environnement local défini, vous pouvez tester l'intégration en déployant localement un subgraph.
 
 1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
 
 2. Modifier [cette ligne] (https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) pour inclure le nouveau nom du réseau et l'URL JSON-RPC ou Firehose de l'EVM.
 
-   > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
+   > Ne changez pas le nom de la var env elle-même. Il doit rester `ethereum`  même si le nom du réseau est différent.
 
-3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+3. Exécutez un nœud IPFS ou utilisez celui utilisé par The Graph : https://api.thegraph.com/ipfs/
 
-## Substreams-powered Subgraphs
+## Subgraphs alimentés par des substreams
 
 Pour les intégrations Firehose/Substreams pilotées par StreamingFast, la prise en charge de base des modules Substreams fondamentaux (par exemple, les transactions décodées, les logs et les événements smart-contract) et les outils codegen Substreams sont inclus. Ces outils permettent d'activer des [subgraphs alimentés par Substreams](/substreams/sps/introduction/). Suivez le [Guide pratique](https://substreams.streamingfast.io/documentation/how-to-guides/intro-your-first-application) et exécutez `substreams codegen subgraph` pour expérimenter les outils codegen par vous-même.

From 4f4f76304d097889405e1cab3e482ae6f7967b20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 09:51:40 -0500
Subject: [PATCH 3490/3820] New translations starting-your-subgraph.mdx (Hindi)

---
 .../subgraphs/developing/creating/starting-your-subgraph.mdx  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/subgraphs/developing/creating/starting-your-subgraph.mdx b/website/pages/hi/subgraphs/developing/creating/starting-your-subgraph.mdx
index 8770e21dd651..a162f802cf9c 100644
--- a/website/pages/hi/subgraphs/developing/creating/starting-your-subgraph.mdx
+++ b/website/pages/hi/subgraphs/developing/creating/starting-your-subgraph.mdx
@@ -4,9 +4,9 @@ title: Starting Your Subgraph
 
 ## अवलोकन
 
-The Graph is home to thousands of subgraphs already available for query, so check [The Graph Explorer](https://thegraph.com/explorer) and find one that already matches your needs.
+ग्राफ़ में पहले से ही हजारों सबग्राफ उपलब्ध हैं, जिन्हें क्वेरी के लिए उपयोग किया जा सकता है, तो The Graph Explorer(https://thegraph.com/explorer) को चेक करें और ऐसा कोई Subgraph ढूंढें जो पहले से आपकी ज़रूरतों से मेल खाता हो।
 
-When you create a [subgraph](/subgraphs/developing/subgraphs/), you create a custom open API that extracts data from a blockchain, processes it, stores it, and makes it easy to query via GraphQL.
+जब आप एक [सबग्राफ](/subgraphs/developing/subgraphs/)बनाते हैं, तो आप एक कस्टम ओपन API बनाते हैं जो ब्लॉकचेन से डेटा निकालता है, उसे प्रोसेस करता है, स्टोर करता है और इसे GraphQL के माध्यम से क्वेरी करना आसान बनाता है।
 
 Subgraph development ranges from simple scaffold subgraphs to advanced, specifically tailored subgraphs.
 

From 0e0cfb1bf0ca8e9d7e0692c8327f4612b99de02c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 11:15:19 -0500
Subject: [PATCH 3491/3820] New translations delegating.mdx (French)

---
 website/pages/fr/resources/roles/delegating.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/fr/resources/roles/delegating.mdx b/website/pages/fr/resources/roles/delegating.mdx
index 99fe60359d38..1f2cd5cb6399 100644
--- a/website/pages/fr/resources/roles/delegating.mdx
+++ b/website/pages/fr/resources/roles/delegating.mdx
@@ -10,12 +10,12 @@ Delegators earn GRT by delegating GRT to Indexers, which helps network security
 
 <VideoEmbed youtube="VACg8bitnVc" />
 
-## Benefits of Delegating
+## Avantages de la délégation
 
 - Strengthen the network’s security and scalability by supporting Indexers.
 - Earn a portion of rewards generated by the Indexers.
 
-## How Does Delegation Work?
+## Comment fonctionne la délégation ?
 
 Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
@@ -58,7 +58,7 @@ There are two sections in this guide:
 
 Les principaux risques liés à la fonction de délégué dans le protocole sont transmis ci-dessous.
 
-### The Delegation Tax
+### La taxe de délégation
 
 Les délégués ne peuvent pas être licenciés en cas de mauvais comportement, mais ils sont soumis à une taxe visant à décourager les mauvaises décisions susceptibles de nuire à l'intégrité du réseau.
 
@@ -68,7 +68,7 @@ En tant que Délégateur, il est important de comprendre ce qui suit :
 
 - Pour être en sécurité, vous devriez calculer votre retour potentiel lorsque vous déléguez à un Indexeur. Par exemple, vous pourriez calculer combien de jours il faudra avant d'avoir récupéré la taxe de 0,5% sur votre délégation.
 
-### The Undelegation Period
+### La période de retrait de délégation
 
 When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 

From 160a62e41e07d492bed60704279ea629286c5516 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 11:15:20 -0500
Subject: [PATCH 3492/3820] New translations tokenomics.mdx (French)

---
 website/pages/fr/resources/tokenomics.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/fr/resources/tokenomics.mdx b/website/pages/fr/resources/tokenomics.mdx
index 8b52c831c858..51c10131e590 100644
--- a/website/pages/fr/resources/tokenomics.mdx
+++ b/website/pages/fr/resources/tokenomics.mdx
@@ -17,7 +17,7 @@ The Graph plays a vital role in making blockchain data more accessible and suppo
 
 - GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
 
-## The Roles of Network Participants
+## Les rôles des participants au réseau
 
 There are four primary network participants:
 
@@ -43,7 +43,7 @@ There is a 0.5% delegation tax which is burned whenever a Delegator delegates GR
 
 If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
 
-## Curators (Earn GRT)
+## Curateurs (Gagnez des GRT)
 
 Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
 
@@ -73,7 +73,7 @@ Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and th
 
 Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
 
-Indexers can earn GRT rewards in two ways:
+Les Indexeurs peuvent gagner des récompenses en GRT de deux façons :
 
 1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
 
@@ -87,7 +87,7 @@ Indexers can increase their GRT allocations on subgraphs by accepting GRT delega
 
 The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
 
-## Token Supply: Burning & Issuance
+## Token Supply : Incinération & Emission
 
 The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
 
@@ -97,6 +97,6 @@ The Graph is designed with multiple burning mechanisms to offset new token issua
 
 In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
 
-## Improving the Protocol
+## Amélioration du protocole
 
 The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 2bf0a0576356e9dddb7e41e33f6a8699f925743a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 11:15:23 -0500
Subject: [PATCH 3493/3820] New translations supported-network-requirements.mdx
 (Chinese Simplified)

---
 website/pages/zh/indexing/supported-network-requirements.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/indexing/supported-network-requirements.mdx b/website/pages/zh/indexing/supported-network-requirements.mdx
index d9e844cbbe43..72c9bba12a39 100644
--- a/website/pages/zh/indexing/supported-network-requirements.mdx
+++ b/website/pages/zh/indexing/supported-network-requirements.mdx
@@ -2,7 +2,7 @@
 title: Supported Network Requirements
 ---
 
-| 网络        | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
+| Network   | Guides                                                                                                                                                                                                                                                                                              | System Requirements                                                                                                                   | Indexing Rewards |
 | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | :--------------: |
 | Arbitrum  | [Baremetal Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/baremetal)<br /> [Docker Guide](https://docs.infradao.com/archive-nodes-101/arbitrum/docker)                                                                                                                                 | 4+ core CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 8 TiB NVMe SSD<br /> _last updated August 2023_                               |         ✅        |
 | Avalanche | [Docker Guide](https://docs.infradao.com/archive-nodes-101/avalanche/docker)                                                                                                                                                                                                                        | 4 core / 8 threads CPU<br /> Ubuntu 22.04<br /> 16GB+ RAM<br /> >= 5 TiB NVMe SSD<br /> _last updated August 2023_                    |         ✅        |

From d1671593f13379e40638043007a626768af6f41d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 12:16:21 -0500
Subject: [PATCH 3494/3820] New translations assemblyscript-migration-guide.mdx
 (Chinese Simplified)

---
 .../resources/release-notes/assemblyscript-migration-guide.mdx  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx
index 77c37c29dd7d..ad1c51816321 100644
--- a/website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -4,7 +4,7 @@ title: AssemblyScript 迁移指南
 
 Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
 
-这将使子图开发人员能够使用 AS 语言和标准库的更新特性。
+That will enable subgraph developers to use newer features of the AS language and standard library.
 
 This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
 

From e5d538de113e3a23420ef540d2b3cbb3f6f1d860 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 3 Feb 2025 17:33:11 -0500
Subject: [PATCH 3495/3820] New translations overview.mdx (Russian)

---
 website/pages/ru/indexing/overview.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ru/indexing/overview.mdx b/website/pages/ru/indexing/overview.mdx
index 212d822f65e4..695415b60b01 100644
--- a/website/pages/ru/indexing/overview.mdx
+++ b/website/pages/ru/indexing/overview.mdx
@@ -1,5 +1,5 @@
 ---
-title: Indexing Overview
+title: Обзор индексирования
 ---
 
 Индексаторы — это операторы нод в сети The Graph, которые стейкают токены Graph (GRT) для предоставления услуг индексирования и обработки запросов. Индексаторы получают оплату за запросы и вознаграждение за свои услуги индексирования. Они также получают комиссию за запросы, которая возвращаются в соответствии с экспоненциальной функцией возврата.
@@ -18,9 +18,9 @@ title: Indexing Overview
 
 ### Каковы источники доходов индексатора?
 
-**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+**Возвраты комиссий за запросы** – Платежи за обработку запросов в сети. Эти платежи осуществляются через каналы состояния между Индексатором и шлюзом. Каждый запрос от шлюза включает в себя платеж, а соответствующий ответ содержит доказательство корректности результата запроса.
 
-**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+**Награды за индексирование** – Генерируются за счет ежегодной инфляции протокола в размере 3%. Награды за индексирование распределяются между Индексаторами, которые выполняют индексирование развертываний субграфов для сети.
 
 ### Как распределяются вознаграждения за индексацию?
 

From 2cbe81998bcc2283a7df69e3d94a99e40bdcb353 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 4 Feb 2025 02:00:28 -0500
Subject: [PATCH 3496/3820] New translations index.json (Chinese Simplified)

---
 website/pages/zh/index.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/index.json b/website/pages/zh/index.json
index b3c96de26337..b4f0b678d34d 100644
--- a/website/pages/zh/index.json
+++ b/website/pages/zh/index.json
@@ -1,5 +1,5 @@
 {
-  "title": "Home",
+  "title": "主页",
   "intro": "了解Graph，一个用于索引和查询区块链数据的去中心化的协议。",
   "shortcuts": {
     "aboutTheGraph": {

From ab34120f931ef37433f6db32da1dea222680d9de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 4 Feb 2025 02:00:30 -0500
Subject: [PATCH 3497/3820] New translations tokenomics.mdx (Chinese
 Simplified)

---
 website/pages/zh/resources/tokenomics.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/resources/tokenomics.mdx b/website/pages/zh/resources/tokenomics.mdx
index f9977252fef3..205d85919996 100644
--- a/website/pages/zh/resources/tokenomics.mdx
+++ b/website/pages/zh/resources/tokenomics.mdx
@@ -51,7 +51,7 @@ Subgraph developers are encouraged to curate their subgraph with at least 3,000
 
 Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
 
-## Developers
+## 开发人员
 
 Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
 

From f36d135e779237a50923560e3bad920b4102a054 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 4 Feb 2025 02:00:31 -0500
Subject: [PATCH 3498/3820] New translations sinks.mdx (Chinese Simplified)

---
 .../zh/substreams/developing/sinks/sinks.mdx  | 34 +++++++++----------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/zh/substreams/developing/sinks/sinks.mdx b/website/pages/zh/substreams/developing/sinks/sinks.mdx
index d5342fca741e..6cb08aca4c17 100644
--- a/website/pages/zh/substreams/developing/sinks/sinks.mdx
+++ b/website/pages/zh/substreams/developing/sinks/sinks.mdx
@@ -26,26 +26,26 @@ Sinks are integrations that allow you to send the extracted data to different de
 
 ### Official
 
-| Name       | Support | Maintainer    | Source Code                                                                               |
-| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
-| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
-| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
-| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
-| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
-| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
-| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
-| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
-| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
-| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+| Name       | 支持 | Maintainer    | Source Code                                                                               |
+| ---------- | -- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O  | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O  | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O  | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O  | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O  | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O  | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O  | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O  | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O  | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
 
 ### Community
 
-| Name       | Support | Maintainer | Source Code                                                                               |
-| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
-| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
-| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
-| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
-| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Name       | 支持 | Maintainer | Source Code                                                                               |
+| ---------- | -- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C  | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C  | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C  | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C  | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
 
 - O = Official Support (by one of the main Substreams providers)
 - C = Community Support

From f5d9969746049e45b8b08924d3185eee3d9708aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 4 Feb 2025 11:23:17 -0500
Subject: [PATCH 3499/3820] New translations unit-testing-framework.mdx (Hindi)

---
 .../creating/unit-testing-framework.mdx       | 26 +++++++++----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx
index ac80402ff9fa..d3489159523f 100644
--- a/website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/hi/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -8,34 +8,34 @@ Learn how to use Matchstick, a unit testing framework developed by [LimeChain](h
 
 ## Benefits of Using Matchstick
 
-- It's written in Rust and optimized for high performance.
-- It gives you access to developer features, including the ability to mock contract calls, make assertions about the store state, monitor subgraph failures, check test performance, and many more.
+- यह Rust में लिखा गया है और उच्च प्रदर्शन के लिए अनुकूलित है।
+- यह आपको डेवलपर विशेषता तक पहुंच प्रदान करता है, जिसमें contract कॉल्स को मॉक करने, स्टोर स्टेट के बारे में एसेर्शन करने, सबग्राफ विफलताओं की निगरानी करने, टेस्ट परफॉर्मेंस जांचने और बहुत कुछ करने की क्षमता शामिल है।
 
 ## शुरू करना
 
-### Install Dependencies
+### डिपेंडेंसीज़ इंस्टॉल करें
 
-In order to use the test helper methods and run tests, you need to install the following dependencies:
+टेस्ट हेल्पर मेथड का उपयोग करने और टेस्ट चलाने के लिए, आपको निम्नलिखित डिपेंडेंसीज़ इंस्टॉल करनी होंगी:
 
 ```sh
 yarn add --dev matchstick-as
 ```
 
-### Install PostgreSQL
+### PostgreSQL स्थापित करें
 
-`graph-node` depends on PostgreSQL, so if you don't already have it, then you will need to install it.
+`ग्राफ-नोड` PostgreSQL पर निर्भर करता है, इसलिए यदि यह पहले से आपके पास नहीं है, तो आपको इसे इंस्टॉल करने की आवश्यकता होगी।
 
-> Note: It's highly recommended to use the commands below to avoid unexpected errors.
+> नोट: अनपेक्षित त्रुटियों से बचने के लिए नीचे दिए गए कमांड्स का उपयोग करना अत्यधिक अनुशंसित है।
 
-#### Using MacOS
+#### MacOS का उपयोग करना
 
-Installation command:
+स्थापना आदेश:
 
 ```sh
 brew install postgresql
 ```
 
-Create a symlink to the latest libpq.5.lib _You may need to create this dir first_ `/usr/local/opt/postgresql/lib/`
+यहां तक कि नवीनतम libpq.5.lib_ का एक symlink बनाएं। आपको पहले यह dir बनाने की आवश्यकता हो सकती है: `/usr/local/opt/postgresql/lib/`
 
 ```sh
 ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/opt/postgresql/lib/libpq.5.dylib
@@ -43,13 +43,13 @@ ln -sf /usr/local/opt/postgresql@14/lib/postgresql@14/libpq.5.dylib /usr/local/o
 
 #### Using Linux
 
-Installation command (depends on your distro):
+इंस्टॉलेशन कमांड (आपके डिस्ट्रीब्यूशन पर निर्भर करता है):
 
 ```sh
 sudo apt install postgresql
 ```
 
-### Using WSL (Windows Subsystem for Linux)
+### WSL (Windows Subsystem for Linux) का उपयोग करते हुए
 
 कृपया ध्यान दें, आर्बिट्रम माइग्रेशन पूरा होने पर इसमें सुधार होगा, जिससे नेटवर्क पर भाग लेने के लिए गैस की लागत काफी कम हो जाएगी।...
 
@@ -63,7 +63,7 @@ static BYTES = Symbol("Bytes") SyntaxError: Unexpected token =
 <PROJECT_PATH>/node_modules/gluegun/build/index.js:13 throw up;
 ```
 
-Please make sure you're on a newer version of Node.js graph-cli doesn't support **v10.19.0** anymore, and that is still the default version for new Ubuntu images on WSL. For instance Matchstick is confirmed to be working on WSL with **v18.1.0**, you can switch to it either via **nvm** or if you update your global Node.js. Don't forget to delete `node_modules` and to run `npm install` again after updating you nodejs! Then, make sure you have **libpq** installed, you can do that by running
+कृपया सुनिश्चित करें कि आप नोड.js के नए वर्जन पर हैं, क्योंकि** v10.19.0** अब graph-cli द्वारा समर्थित नहीं है, और यह अभी भी WSL पर नए Ubuntu इमेज के लिए डिफ़ॉल्ट वर्जन है। उदाहरण के लिए,instances Matchstick की पुष्टि हो चुकी है कि यह WSL पर **v18.1.0** के साथ काम कर रहा है। आप इसे **nvm** के माध्यम से या अपने ग्लोबल नोड.js को अपडेट करके स्विच कर सकते हैं।अपडेट के बाद, `नोड_modules` को डिलीट करना न भूलें और \`npm install दोबारा चलाएँ। फिर, सुनिश्चित करें कि आपके पास **libpq** इंस्टॉल है। आप इसे निम्नलिखित कमांड चलाकर कर सकते हैं:
 
 ```
 sudo apt-get install libpq-dev

From b1841d209ea8c7691ff097be2df98848707b8445 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 04:13:14 -0500
Subject: [PATCH 3500/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 28 +++++++++++++-------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
index 35b72e33a1c0..87ef13fb0de1 100644
--- a/website/pages/de/indexing/overview.mdx
+++ b/website/pages/de/indexing/overview.mdx
@@ -369,15 +369,15 @@ docker-compose up
 
 To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
 
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards onchain and how much is allocated towards each.
+- **Indexer-Agent** - Der Agent überwacht das Netzwerk und die eigene Infrastruktur des Indexers und verwaltet, welche Subgraph-Einsätze indiziert und der Onchain zugewiesen werden und wie viel davon jeweils zugewiesen wird.
 
-- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+- **Indexer-Dienst** - Die einzige Komponente, die nach außen hin offengelegt werden muss. Der Dienst leitet Subgraph-Abfragen an den Graph-Knoten weiter, verwaltet Statuskanäle für Abfragezahlungen und gibt wichtige Entscheidungsinformationen an Clients wie die Gateways weiter.
 
-- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+- **Indexer CLI** - Die Befehlszeilenschnittstelle zur Verwaltung des Indexer-Agenten. Sie ermöglicht Indexern die Verwaltung von Kostenmodellen, manuellen Zuweisungen, Aktionswarteschlangen und Indizierungsregeln.
 
 #### Getting started
 
-The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/indexing/overview/#stake-in-the-protocol) before starting up your Indexer components!
+Der Indexer-Agent und der Indexer-Service sollten sich in Ihrer Graph Node-Infrastruktur befinden. Es gibt viele Möglichkeiten, virtuelle Ausführungsumgebungen für Ihre Indexer-Komponenten einzurichten; hier erklären wir, wie Sie sie auf Baremetal mit NPM-Paketen oder Source oder über Kubernetes und Docker auf der Google Cloud Kubernetes Engine ausführen. Wenn sich diese Datenbeispiele nicht gut auf Ihre Infrastruktur übertragen lassen, wird es wahrscheinlich einen Community-Leitfaden geben, auf den Sie sich beziehen können. Kommen Sie auf [Discord] (https://discord.gg/graphprotocol) vorbei! Vergessen Sie nicht, [stake in the protocol](/indexing/overview/#stake-in-the-protocol), bevor Sie Ihre Indexer-Komponenten starten!
 
 #### From NPM packages
 
@@ -453,15 +453,15 @@ docker run -p 7600:7600 -it indexer-service:latest ...
 docker run -p 18000:8000 -it indexer-agent:latest ...
 ```
 
-**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+**HINWEIS**: Nach dem Start der Container sollte der Indexer-Dienst unter [http://localhost:7600](http://localhost:7600) erreichbar sein und der Indexer-Agent sollte die Indexer-Verwaltungs-API unter [http://localhost:18000/](http://localhost:18000/) zur Verfügung stellen.
 
 #### Using K8s and Terraform
 
-See the [Setup Server Infrastructure Using Terraform on Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud) section
+Sehen Sie den Abschnitt [Einrichten der Serverinfrastruktur mit Terraform in Google Cloud](/indexing/overview/#setup-server-infrastructure-using-terraform-on-google-cloud)
 
 #### Verwendung
 
-> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+> HINWEIS: Alle Laufzeit-Konfigurationsvariablen können entweder als Parameter auf den Befehl beim Start oder mithilfe von Umgebungsvariablen im Format `COMPONENT_NAME_VARIABLE_NAME`(z. B. `INDEXER_AGENT_ETHEREUM`) angewandt werden.
 
 #### Indexer-Agent
 
@@ -520,7 +520,7 @@ graph-indexer-service start \
 
 #### Indexer-CLI
 
-The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+Das Indexer CLI ist ein Plugin für [`@graphprotocol/graph-cli`] (https://www.npmjs.com/package/@graphprotocol/graph-cli), das im Terminal unter `graph indexer` erreichbar ist.
 
 ```sh
 graph indexer connect http://localhost:18000
@@ -529,19 +529,19 @@ graph indexer status
 
 #### Indexer management using Indexer CLI
 
-The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+Das vorgeschlagene Tool für die Interaktion mit der **Indexer-Verwaltungs-API** ist die **Indexer CLI**, eine Erweiterung der **Graph CLI**. Der Indexer-Agent benötigt Eingaben von einem Indexer, um im Namen des Indexers autonom mit dem Netzwerk zu interagieren. Die Mechanismen zur Definition des Verhaltens des Indexer-Agenten sind der **Zuweisungsmanagement**-Modus und die **Indizierungsregeln**. Im Auto-Modus kann ein Indexer **Indizierungsregeln** verwenden, um seine spezifische Strategie für die Auswahl von Subgraphen anzuwenden, die er indizieren und für die er Abfragen liefern soll. Die Regeln werden über eine GraphQL-API verwaltet, die vom Agenten bereitgestellt wird und als IIndexer-Verwaltungs-API bekannt ist. Im manuellen Modus kann ein Indexer Zuordnungsaktionen über die **Aktionswarteschlange** erstellen und sie explizit genehmigen, bevor sie ausgeführt werden. Im Überwachungsmodus werden **Indizierungsregeln** verwendet, um die **Aktionswarteschlange** zu füllen, und erfordern ebenfalls eine ausdrückliche Genehmigung für die Ausführung.
 
 #### Verwendung
 
-The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+Die **Indexer CLI** verbindet sich mit dem Indexer-Agenten, in der Regel über Port-Forwarding, so dass die CLI nicht auf demselben Server oder Cluster laufen muss. Um Ihnen den Einstieg zu erleichtern und etwas Kontext zu liefern, wird die CLI hier kurz beschrieben.
 
-- `graph indexer connect <url>` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
+- `graph indexer connect <url>` - Verbindet mit der Indexer-Verwaltungs-API. Typischerweise wird die Verbindung zum Server über Port-Forwarding geöffnet, so dass die CLI einfach aus der Ferne bedient werden kann. (Datenbeispiel: `kubectl port-forward pod/<indexer-agent-pod> 8000:8000`)
 
-- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Get one or more indexing rules using `all` as the `<deployment-id>` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+- `graph indexer rules get [options] <deployment-id> [<key1> ...]` - Holt eine oder mehrere Indizierungsregeln unter Verwendung von `all` als `<deployment-id>`, um alle Regeln zu erhalten, oder `global`, um die globalen Standardwerte zu erhalten. Ein zusätzliches Argument `--merged` kann verwendet werden, um anzugeben, dass einsatzspezifische Regeln mit der globalen Regel zusammengeführt werden. Auf diese Weise werden sie im Indexer-Agent angewendet.
 
-- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Set one or more indexing rules.
+- `graph indexer rules set [options] <deployment-id> <key1> <value1> ...` - Eine oder mehrere Indizierungsregeln setzen.
 
-- `graph indexer rules start [options] <deployment-id>` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+- `graph indexer rules start [options] <deployment-id>` - Startet die Indizierung eines Subgraph-Einsatzes, wenn dieser verfügbar ist, und setzt seine `decisionBasis` auf `always`, so dass der Indexer-Agent sich immer für die Indizierung entscheidet. Wenn die globale Regel auf „always“ gesetzt ist, werden alle verfügbaren Subgraphen im Netzwerk indiziert.
 
 - `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
 

From e27f20305c6285306c2650b50890a317831eb40c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 04:13:16 -0500
Subject: [PATCH 3501/3820] New translations assemblyscript-migration-guide.mdx
 (Chinese Simplified)

---
 .../release-notes/assemblyscript-migration-guide.mdx      | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx
index ad1c51816321..45d64ae2ead8 100644
--- a/website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/zh/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -72,7 +72,7 @@ npm install --save-dev @graphprotocol/graph-cli@latest
 npm install --save @graphprotocol/graph-ts@latest
 ```
 
-4. 参考指南的其余部分修复语言更改带来的问题。
+4. Follow the rest of the guide to fix the language breaking changes.
 5. Run `codegen` and `deploy` again.
 
 ## 重大变化
@@ -225,7 +225,7 @@ let bytes = new Bytes(2)
 changetype<ByteArray>(bytes) // works :)
 ```
 
-If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+如果您只想去掉可空性，您可以继续使用 `as` 运算符（或 `<T>variable`），但请确保您知道该值不会为空, 否则程序会出现问题。
 
 ```typescript
 // remove nullability
@@ -459,7 +459,7 @@ let arr = new Array<string>(5) // ["", "", "", "", ""]
 arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
 ```
 
-根据您使用的类型，例如可以为空的类型，以及访问它们的方式，您可能会遇到类似下面这样的运行时错误:
+Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
 
 ```
 ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
@@ -521,4 +521,4 @@ This changed because of nullability differences between AssemblyScript versions,
 - The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
 - Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
 - When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
-- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- 修复了大小不同时关系字符串比较的错误 ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 9c0886ddcd3455fc46b1d2283b31ddb5a1ecb49d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 04:13:18 -0500
Subject: [PATCH 3502/3820] New translations
 graphql-validations-migration-guide.mdx (Chinese Simplified)

---
 .../release-notes/graphql-validations-migration-guide.mdx   | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/zh/resources/release-notes/graphql-validations-migration-guide.mdx b/website/pages/zh/resources/release-notes/graphql-validations-migration-guide.mdx
index 8c4d5c52d93a..1493a96c8f55 100644
--- a/website/pages/zh/resources/release-notes/graphql-validations-migration-guide.mdx
+++ b/website/pages/zh/resources/release-notes/graphql-validations-migration-guide.mdx
@@ -6,9 +6,9 @@ title: GraphQL验证迁移指南
 
 “graph-节点”的早期版本不支持所有验证，并提供了更优雅的响应——因此，在出现歧义的情况下，“graph-节点”会忽略无效的GraphQL操作组件。
 
-GraphQL验证支持是即将推出的新功能和Graph网络规模性能的支柱。
+GraphQL验证支持是即将推出的新功能和The Graph网络规模性能的支柱。
 
-它还将确保查询响应的确定性，这是Graph网络的一个关键要求。
+它还将确保查询响应的确定性，这是The Graph网络的一个关键要求。
 
 **启用GraphQL验证将中断发送到Graph API的一些现有查询**。
 
@@ -58,7 +58,7 @@ npx@graphql验证/cli-shttps://api-npx @graphql-validate/cli -s https://api-next
 
 您可以尝试将查询发送到：
 
-- `https://api-next.thegraph.com/subgraphs/id/<Qm...>`
+- `https://api-next.thegraph.com/subgraphs/id<Qm...>`
 
 或者
 

From 916d45cd0f80e04edb306c639ff22e70d0959ec8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 04:13:19 -0500
Subject: [PATCH 3503/3820] New translations sps-faq.mdx (Chinese Simplified)

---
 website/pages/zh/sps/sps-faq.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/zh/sps/sps-faq.mdx b/website/pages/zh/sps/sps-faq.mdx
index 1e9132677d36..8553d3e677f8 100644
--- a/website/pages/zh/sps/sps-faq.mdx
+++ b/website/pages/zh/sps/sps-faq.mdx
@@ -12,7 +12,7 @@ Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit
 
 ## 什么是基于Substreams的子图？
 
-[Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
+[Substreams驱动的子图](/sps/introduction/)结合了Substreams的强大功能和子图的可查询性。发布基于Substreams的子图时，Substreams转换生成的数据可以输出与子图实体兼容的[实体更改](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs)。
 
 If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
 
@@ -66,7 +66,7 @@ Firehose是由[StreamingFast](https://www.streamingfast.io/)开发的区块链
 
 [Substreams文档](/substreams/introduction/)将教您如何构建Substreams模块。
 
-The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
+[Substreams驱动的子图文档](/sps/introduction/)将向您展示如何将它们打包部署在The Graph上。
 
 The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
 
@@ -92,4 +92,4 @@ After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use
 
 ## Substreams和Substreams-powered子图对于The Graph Network意味着什么？
 
-这种集成带来许多好处，包括通过利用社区模块和在其上构建的组合性来实现极高性能的索引。
+The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.

From ad5248aba6566c2b5e64f8bd3d9ec284716e4efb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 06:02:51 -0500
Subject: [PATCH 3504/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 116 ++++++++++++-------------
 1 file changed, 58 insertions(+), 58 deletions(-)

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
index 87ef13fb0de1..602a5b5460c0 100644
--- a/website/pages/de/indexing/overview.mdx
+++ b/website/pages/de/indexing/overview.mdx
@@ -543,31 +543,31 @@ Die **Indexer CLI** verbindet sich mit dem Indexer-Agenten, in der Regel über P
 
 - `graph indexer rules start [options] <deployment-id>` - Startet die Indizierung eines Subgraph-Einsatzes, wenn dieser verfügbar ist, und setzt seine `decisionBasis` auf `always`, so dass der Indexer-Agent sich immer für die Indizierung entscheidet. Wenn die globale Regel auf „always“ gesetzt ist, werden alle verfügbaren Subgraphen im Netzwerk indiziert.
 
-- `graph indexer rules stop [options] <deployment-id>` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+- `graph indexer rules stop [options] <deployment-id->` - Stoppt die Indizierung eines Einsatzes und setzt seine `decisionBasis` auf never, so dass er diesen Einsatz bei der Entscheidung über die zu indizierenden Einsätze überspringt.
 
-- `graph indexer rules maybe [options] <deployment-id>` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+- `graph indexer rules maybe [options] <deployment-id>` - Setzt die `decisionBasis` für ein Deployment auf `rules`, so dass der Indexer Agent Indizierungsregeln verwendet, um zu entscheiden, ob dieses Deployment indiziert werden soll.
 
-- `graph indexer actions get [options] <action-id>` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additional argument `--status` can be used to print out all actions of a certain status.
+- `graph indexer actions get [options] <action-id>` - Holt eine oder mehrere Aktionen mit `all` oder lässt `action-id` leer, um alle Aktionen zu erhalten. Ein zusätzliches Argument `--status` kann verwendet werden, um alle Aktionen mit einem bestimmten Status auszugeben.
 
-- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Queue allocation action
+- `graph indexer action queue allocate <deployment-id> <allocation-amount>` - Aktion zur Warteschlangenzuordnung
 
-- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Queue reallocate action
+- `graph indexer action queue reallocate <deployment-id> <allocation-id> <allocationAmount>` - Aktion zur Neuzuweisung der Warteschlange
 
-- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Queue unallocate action
+- `graph indexer action queue unallocate <deployment-id> <allocation-id>` - Aktion zum Aufheben der Warteschlangenzuordnung
 
-- `graph indexer actions cancel [<action-id> ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+- `graph indexer actions cancel [<action-id> ...]` - Abbrechen aller Aktionen in der Warteschlange, wenn id nicht angegeben ist, sonst Abbrechen eines Arrays von id mit Leerzeichen als Trennzeichen
 
-- `graph indexer actions approve [<action-id> ...]` - Approve multiple actions for execution
+- `graph indexer actions approve [<action-id> ...]` - Mehrere Aktionen zur Ausführung freigeben
 
-- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+- `graph indexer actions execute approve` - Erzwingt die sofortige Ausführung genehmigter Aktionen durch den Worker
 
-All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+Alle Befehle, die Regeln in der Ausgabe anzeigen, können zwischen den unterstützten Ausgabeformaten (`table`, `yaml` und `json`) mit dem Argument `-output` wählen.
 
 #### Indexing rules
 
-Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+Indizierungsregeln können entweder als globale Standardwerte oder für bestimmte Subgraph-Einsätze unter Verwendung ihrer IDs angewendet werden. Die Felder `deployment` und `decisionBasis` sind obligatorisch, während alle anderen Felder optional sind. Wenn eine Indizierungsregel `rules` als `decisionBasis` hat, dann vergleicht der Indexer-Agent Nicht-Null-Schwellenwerte dieser Regel mit Werten, die aus dem Netzwerk für den entsprechenden Einsatz geholt wurden. Wenn der Subgraph-Einsatz Werte über (oder unter) einem der Schwellenwerte aufweist, wird er für die Indizierung ausgewählt.
 
-For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+Wenn die globale Regel beispielsweise einen Wert von **5** (GRT) hat, werden alle Subgraph-Einsätze, denen mehr als 5 (GRT) zugewiesen wurden, indiziert. Zu den Schwellenwertregeln gehören `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, und `minAverageQueryFees`.
 
 Data model:
 
@@ -617,15 +617,15 @@ graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
 
 #### Actions queue CLI
 
-The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+Das indexer-cli bietet ein `actions`-Modul für die manuelle Arbeit mit der Aktionswarteschlange. Es verwendet die **Graphql-API**, die vom Indexer-Verwaltungsserver gehostet wird, um mit der Aktions-Warteschlange zu interagieren.
 
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed onchain. The general flow will look like:
+Der Action Execution Worker holt sich nur dann Elemente aus der Warteschlange, um sie auszuführen, wenn sie den Status `ActionStatus = approved` haben. Im empfohlenen Pfad werden Aktionen der Warteschlange mit ActionStatus = queued hinzugefügt, so dass sie dann genehmigt werden müssen, um in der Kette ausgeführt zu werden. Der allgemeine Ablauf sieht dann wie folgt aus:
 
 - Action added to the queue by the 3rd party optimizer tool or indexer-cli user
-- Indexer can use the `indexer-cli` to view all queued actions
-- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
-- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
-- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
+- Indexer kann die `indexer-cli` verwenden, um alle in der Warteschlange stehenden Aktionen zu sehen
+- Indexer (oder andere Software) kann Aktionen in der Warteschlange mit Hilfe des `indexer-cli` genehmigen oder abbrechen. Die Befehle approve und cancel nehmen ein Array von Aktions-IDs als Eingabe.
+- Der Ausführungsworker fragt die Warteschlange regelmäßig nach genehmigten Aktionen ab. Er holt die `approved` Aktionen aus der Warteschlange, versucht, sie auszuführen, und aktualisiert die Werte in der Datenbank je nach Ausführungsstatus auf `success` oder `failed`.
+- Ist eine Aktion erfolgreich, stellt der Worker sicher, dass eine Indizierungsregel vorhanden ist, die dem Agenten mitteilt, wie er die Zuweisung in Zukunft verwalten soll. Dies ist nützlich, wenn manuelle Aktionen durchgeführt werden, während sich der Agent im `auto`- oder `oversight`-Modus befindet.
 - The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken.
 
 Data model:
@@ -683,13 +683,13 @@ graph indexer actions execute approve
 
 Note that supported action types for allocation management have different input requirements:
 
-- `Allocate` - allocate stake to a specific subgraph deployment
+- `Allocate` - Zuweisung eines Anteils an einen bestimmten Subgraph-Einsatz
 
   - required action params:
     - deploymentID
     - amount
 
-- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+- `Unallocate` - Beendigung der Zuweisung, wodurch der Einsatz für eine andere Zuweisung frei wird
 
   - required action params:
     - allocationID
@@ -698,7 +698,7 @@ Note that supported action types for allocation management have different input
     - poi
     - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
 
-- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+- `Reallocate` - Zuweisung atomar schließen und eine neue Zuweisung für denselben Subgraph-Einsatz öffnen
 
   - required action params:
     - allocationID
@@ -733,13 +733,13 @@ default => 0.1 * $SYSTEM_LOAD;
 
 Example query costing using the above model:
 
-| Query                                                                        | Price   |
-| ---------------------------------------------------------------------------- | ------- |
-| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                             | 0.5 GRT |
-| &#123; tokens &#123; symbol &#125; &#125;                                    | 0.1 GRT |
-| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125; | 0.6 GRT |
+| Abfrage                                                                        | Preis   |
+| ------------------------------------------------------------------------------ | ------- |
+| &#123; pairs(skip: 5000) &#123; id &#125; &#125;                               | 0.5 GRT |
+| &#123; tokens &#123; symbol &#125; &#125;                                      | 0.1 GRT |
+| &#123; pairs(skip: 5000) &#123; id &#125; tokens &#123; symbol &#125; &#125;   | 0.6 GRT |
 
-#### Anwendung des Kostenmodells
+#### Applying the cost model
 
 Cost models are applied via the Indexer CLI, which passes them to the Indexer Management API of the Indexer agent for storing in the database. The Indexer Service will then pick them up and serve the cost models to gateways whenever they ask for them.
 
@@ -752,70 +752,70 @@ indexer cost set model my_model.agora
 
 ### Stake in the protocol
 
-The first steps to participating in the network as an Indexer are to approve the protocol, stake funds, and (optionally) set up an operator address for day-to-day protocol interactions.
+Die ersten Schritte zur Teilnahme am Netzwerk als Indexer sind die Genehmigung des Protokolls, der Einsatz von Geldern und (optional) die Einrichtung einer Betreiberadresse für die täglichen Interaktionen mit dem Protokoll.
 
-> Note: For the purposes of these instructions Remix will be used for contract interaction, but feel free to use your tool of choice ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/), and [MyCrypto](https://www.mycrypto.com/account) are a few other known tools).
+> Hinweis: In dieser Anleitung wird Remix für die Interaktion mit dem Vertrag verwendet, aber Sie können auch das Tool Ihrer Wahl verwenden ([OneClickDapp](https://oneclickdapp.com/), [ABItopic](https://abitopic.io/) und [MyCrypto](https://www.mycrypto.com/account) sind einige andere bekannte Tools).
 
-Once an Indexer has staked GRT in the protocol, the [Indexer components](/indexing/overview/#indexer-components) can be started up and begin their interactions with the network.
+Sobald ein Indexer GRT im Protokoll verankert hat, können die [Indexer-Komponenten](/indexing/overview/#indexer-components) gestartet werden und ihre Interaktionen mit dem Netzwerk beginnen.
 
 #### Approve tokens
 
-1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+1. Öffnen Sie die [Remix-App] (https://remix.ethereum.org/) in einem Browser
 
-2. In the `File Explorer` create a file named **GraphToken.abi** with the [token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
+2. Erstellen Sie im `File Explorer` eine Datei mit dem Namen **GraphToken.abi** mit dem [Token ABI](https://raw.githubusercontent.com/graphprotocol/contracts/mainnet-deploy-build/build/abis/GraphToken.json).
 
-3. With `GraphToken.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+3. Wählen Sie die Datei `GraphToken.abi` aus und öffnen Sie sie im Editor. Wechseln Sie in der Remix-Benutzeroberfläche zum Abschnitt `Deploy and run transactions`.
 
-4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+4. Wählen Sie unter environment die Option `Injected Web3` und unter `Account` die Adresse Ihres Indexers aus.
 
-5. Set the GraphToken contract address - Paste the GraphToken contract address (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) next to `At Address` and click the `At address` button to apply.
+5. Legen Sie die GraphToken-Vertragsadresse fest - Fügen Sie die GraphToken-Vertragsadresse (`0xc944E90C64B2c07662A292be6244BDf05Cda44a7`) neben `At Address` ein und klicken Sie zum Anwenden auf die Schaltfläche `At address`.
 
-6. Call the `approve(spender, amount)` function to approve the Staking contract. Fill in `spender` with the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) and `amount` with the tokens to stake (in wei).
+6. Rufen Sie die Funktion `approve(spender, amount)` auf, um den Einsatzvertrag zu genehmigen. Geben Sie in `spender` die Adresse des Einsatzvertrags (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) und in `amount` die zu setzenden Token (in wei) ein.
 
 #### Stake tokens
 
-1. Open the [Remix app](https://remix.ethereum.org/) in a browser
+1. Öffnen Sie die [Remix-App] (https://remix.ethereum.org/) in einem Browser
 
-2. In the `File Explorer` create a file named **Staking.abi** with the staking ABI.
+2. Erstellen Sie im `File Explorer` eine Datei mit dem Namen **Staking.abi** mit dem Staking-ABI.
 
-3. With `Staking.abi` selected and open in the editor, switch to the `Deploy and run transactions` section in the Remix interface.
+3. Wählen Sie die Datei `Staking.abi` aus und öffnen Sie sie im Editor. Wechseln Sie in der Remix-Benutzeroberfläche zum Abschnitt `Deploy and run transactions`.
 
-4. Under environment select `Injected Web3` and under `Account` select your Indexer address.
+4. Wählen Sie unter environment die Option `Injected Web3` und unter `Account` die Adresse Ihres Indexers aus.
 
-5. Set the Staking contract address - Paste the Staking contract address (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) next to `At Address` and click the `At address` button to apply.
+5. Legen Sie die Adresse des Abtretungsvertrags fest - Fügen Sie die Adresse des Abtretungsvertrags (`0xF55041E37E12cD407ad00CE2910B8269B01263b9`) neben `At Address` ein und klicken Sie auf die Schaltfläche `At address`, um sie anzuwenden.
 
-6. Call `stake()` to stake GRT in the protocol.
+6. Rufen Sie `stake()` auf, um GRT in das Protokoll aufzunehmen.
 
-7. (Optional) Indexers may approve another address to be the operator for their Indexer infrastructure in order to separate the keys that control the funds from those that are performing day to day actions such as allocating on subgraphs and serving (paid) queries. In order to set the operator call `setOperator()` with the operator address.
+7. (Optional) Indexer können eine andere Adresse als Operator für ihre Indexer-Infrastruktur genehmigen, um die Schlüssel, die die Fonds kontrollieren, von denen zu trennen, die alltägliche Aktionen wie die Zuweisung auf Subgraphen und die Bedienung (bezahlter) Abfragen durchführen. Um den Betreiber zu setzen, rufen Sie `setOperator()` mit der Betreiberadresse auf.
 
-8. (Optional) In order to control the distribution of rewards and strategically attract Delegators Indexers can update their delegation parameters by updating their indexingRewardCut (parts per million), queryFeeCut (parts per million), and cooldownBlocks (number of blocks). To do so call `setDelegationParameters()`. The following example sets the queryFeeCut to distribute 95% of query rebates to the Indexer and 5% to Delegators, set the indexingRewardCutto distribute 60% of indexing rewards to the Indexer and 40% to Delegators, and set `thecooldownBlocks` period to 500 blocks.
+8. (Optional) Um die Verteilung von Rewards zu steuern und Delegatoren strategisch anzuziehen, können Indexer ihre Delegationsparameter aktualisieren, indem sie ihren indexingRewardCut (Teile pro Million), queryFeeCut (Teile pro Million) und cooldownBlocks (Anzahl der Blöcke) aktualisieren. Dazu rufen Sie `setDelegationParameters()` auf. Im folgenden Datenbeispiel wird der queryFeeCut so eingestellt, dass 95 % der Abfragerabatte an den Indexer und 5 % an die Delegatoren verteilt werden, der indexingRewardCut so, dass 60 % der Rewards für die Indizierung an den Indexer und 40 % an die Delegatoren verteilt werden, und der Zeitraum `thecooldownBlocks` wird auf 500 Blöcke festgelegt.
 
 ```
 setDelegationParameters(950000, 600000, 500)
 ```
 
-### Setting delegation parameters
+### Einstellung der Delegationsparameter
 
-The `setDelegationParameters()` function in the [staking contract](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) is essential for Indexers, allowing them to set parameters that define their interactions with Delegators, influencing their reward sharing and delegation capacity.
+Die Funktion `setDelegationParameters()` im [Staking Contract] (https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol) ist für Indexer von entscheidender Bedeutung, da sie es ihnen ermöglicht, Parameter zu setzen, die ihre Interaktion mit Delegatoren definieren und ihre Reward-Aufteilung und Delegationskapazität beeinflussen.
 
-### How to set delegation parameters
+### Festlegen der Delegationsparameter
 
-To set the delegation parameters using Graph Explorer interface, follow these steps:
+Gehen Sie wie folgt vor, um die Delegationsparameter über die Graph Explorer-Schnittstelle einzustellen:
 
-1. Navigate to [Graph Explorer](https://thegraph.com/explorer/).
-2. Connect your wallet. Choose multisig (such as Gnosis Safe) and then select mainnet. Note: You will need to repeat this process for Arbitrum One.
-3. Connect the wallet you have as a signer.
-4. Navigate to the 'Settings' section and select 'Delegation Parameters'. These parameters should be configured to achieve an effective cut within the desired range. Upon entering values in the provided input fields, the interface will automatically calculate the effective cut. Adjust these values as necessary to attain the desired effective cut percentage.
-5. Submit the transaction to the network.
+1. Navigieren Sie zu [Graph Explorer] (https://thegraph.com/explorer/).
+2. Verbinden Sie Ihre Wallet. Wählen Sie Multisig (z. B. Gnosis Safe) und dann Mainnet aus. Hinweis: Sie müssen diesen Vorgang für Arbitrum One wiederholen.
+3. Verbinden Sie die Wallet, die Sie als Unterzeichner haben.
+4. Navigieren Sie zum Abschnitt 'Settings' und wählen Sie 'Delegation Parameters'. Diese Parameter sollten so konfiguriert werden, dass eine effektive Kürzung innerhalb des gewünschten Bereichs erreicht wird. Nach Eingabe der Werte in die vorgesehenen Eingabefelder berechnet die Schnittstelle automatisch den effektiven Anteil. Passen Sie diese Werte nach Bedarf an, um den gewünschten Prozentsatz der effektiven Kürzung zu erreichen.
+5. Übermitteln Sie die Transaktion an das Netz.
 
-> Note: This transaction will need to be confirmed by the multisig wallet signers.
+> Hinweis: Diese Transaktion muss von den Unterzeichnern der Multisig-Wallets bestätigt werden.
 
 ### The life of an allocation
 
-After being created by an Indexer a healthy allocation goes through two states.
+Nachdem sie von einem Indexer erstellt wurde, durchläuft eine ordnungsgemäße Zuordnung zwei Zustände.
 
-- **Active** - Once an allocation is created onchain ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)) it is considered **active**. A portion of the Indexer's own and/or delegated stake is allocated towards a subgraph deployment, which allows them to claim indexing rewards and serve queries for that subgraph deployment. The Indexer agent manages creating allocations based on the Indexer rules.
+- **Aktiv** - Sobald eine Zuweisung in der Kette erstellt wurde ([allocateFrom()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L316)), wird sie als **aktiv** betrachtet. Ein Teil des eigenen und/oder delegierten Einsatzes des Indexers wird einem Subgraph-Einsatz zugewiesen, was ihm erlaubt, Rewards für die Indizierung zu beanspruchen und Abfragen für diesen Subgraph-Einsatz zu bedienen. Der Indexer-Agent verwaltet die Erstellung von Zuweisungen basierend auf den Indexer-Regeln.
 
-- **Closed** - An Indexer is free to close an allocation once 1 epoch has passed ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) or their Indexer agent will automatically close the allocation after the **maxAllocationEpochs** (currently 28 days). When an allocation is closed with a valid proof of indexing (POI) their indexing rewards are distributed to the Indexer and its Delegators ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
+- **Geschlossen** - Ein Indexer kann eine Zuweisung schließen, sobald 1 Epoche vergangen ist ([closeAllocation()](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/staking/Staking.sol#L335)) oder sein Indexer-Agent schließt die Zuweisung automatisch nach der **maxAllocationEpochs** (derzeit 28 Tage). Wenn eine Zuweisung mit einem gültigen Indizierungsnachweis (POI) geschlossen wird, werden die Rewards für die Indizierung an den Indexer und seine Delegatoren verteilt ([learn more](/indexing/overview/#how-are-indexing-rewards-distributed)).
 
-Indexers are recommended to utilize offchain syncing functionality to sync subgraph deployments to chainhead before creating the allocation onchain. This feature is especially useful for subgraphs that may take longer than 28 epochs to sync or have some chances of failing undeterministically.
+Indexern wird empfohlen, die Offchain-Synchronisierungsfunktion zu nutzen, um Subgraph-Einsätze mit dem Chainhead zu synchronisieren, bevor die Zuordnung Onchain erstellt wird. Diese Funktion ist besonders nützlich für Subgraphen, bei denen die Synchronisierung länger als 28 Epochen dauert oder die Gefahr eines unbestimmten Fehlers besteht.

From d29ad657f90d3f7a1be23772081569d0b524993b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 06:02:53 -0500
Subject: [PATCH 3505/3820] New translations overview.mdx (Russian)

---
 website/pages/ru/indexing/overview.mdx | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/ru/indexing/overview.mdx b/website/pages/ru/indexing/overview.mdx
index 695415b60b01..42b5c9cac8b8 100644
--- a/website/pages/ru/indexing/overview.mdx
+++ b/website/pages/ru/indexing/overview.mdx
@@ -24,9 +24,9 @@ title: Обзор индексирования
 
 ### Как распределяются вознаграждения за индексацию?
 
-Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+Награды за индексирование поступают из инфляции протокола, которая установлена на уровне 3% годового выпуска. Эти награды распределяются между субграфами пропорционально сигналу кураторства на каждом из них, а затем пропорционально распределяются между Индексаторами в зависимости от их выделенной доли в этом субграфе. **Чтобы получить право на награду, распределение должно быть завершено с предоставлением действительного доказательства индексирования (proof of indexing - POI), которое соответствует стандартам, установленным арбитражной хартией.**
 
-Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/allocation-optimizer) integrated with the indexer software stack.
+Сообществом создано множество инструментов для расчета наград; их коллекция организована в разделе [Сборник руководств сообщества](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). Также Вы можете найти актуальный список инструментов в каналах **#Delegators** и **#Indexers** на [Discord-сервере](https://discord.gg/graphprotocol). Здесь мы предоставляем ссылку на [рекомендуемый оптимизатор распределения](https://github.com/graphprotocol/allocation-optimizer), интегрированный со стеком программного обеспечения для индексаторов.
 
 ### Что такое подтверждение индексации (proof of indexing - POI)?
 
@@ -38,11 +38,11 @@ POI (подтверждение индексации) используются 
 
 ### Каким образом можно отслеживать ожидаемые вознаграждения за индексацию?
 
-The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316) function that can be used to check the pending rewards for a specific allocation.
+Контракт RewardsManager содержит функцию только для чтения [getRewards](https://github.com/graphprotocol/contracts/blob/main/packages/contracts/contracts/rewards/RewardsManager.sol#L316), которая позволяет проверить ожидаемые награды для конкретного распределения.
 
 Многие панели мониторинга, созданные сообществом, содержат ожидающие значения вознаграждений, и их можно легко проверить вручную, выполнив следующие действия:
 
-1. Query the [mainnet subgraph](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one) to get the IDs for all active allocations:
+1. Выполните запрос к [субграфу майннета](https://thegraph.com/explorer/subgraphs/9Co7EQe5PgW3ugCUJrJgRv4u9zdEuDJf8NvMWftNsBH8?view=Query&chain=arbitrum-one), чтобы получить идентификаторы всех активных распределений:
 
 ```graphql
 query indexerAllocations {
@@ -58,28 +58,28 @@ query indexerAllocations {
 }
 ```
 
-Use Etherscan to call `getRewards()`:
+Используйте Etherscan для вызова `getRewards()`:
 
-- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+- Перейдите к [интерфейсу Etherscan для контракта Rewards](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
 
 <!---->
 
-- To call `getRewards()`:
-  - Expand the **9. getRewards** dropdown.
-  - Enter the **allocationID** in the input.
-  - Click the **Query** button.
+- Чтобы вызвать `getRewards()`:
+  - Разверните выпадающее меню **9. getRewards**.
+  - Введите **allocationID** в поле ввода.
+  - Нажмите кнопку **Запрос**.
 
 ### Что такое споры и где их можно просмотреть?
 
 Запросы и распределения индексатора могут быть оспорены на The Graph в течение периода спора. Срок спора варьируется в зависимости от типа спора. Запросы/аттестации имеют 7 эпох спорного окна, тогда как распределения имеют 56 эпох. По истечении этих периодов споры не могут быть открыты ни в отношении выделений, ни в отношении запросов. При открытии спора от Рыбаков требуется депозит в размере не менее 10 000 GRT, который будет заблокирован до завершения спора и принятия решения. Рыбаки — это любые участники сети, которые открывают споры.
 
-Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+У споров есть **три** возможных исхода, так же как и у депозита Рыбаков.
 
 - Если спор отклонен, то GRT, внесенные рыбаками, будут сожжены, а оспариваемый индексатор не будет урезан.
 - Если спор будет решен в виде ничьей, депозит рыбака будет возвращен, а спорный индексатор не будет урезан.
 - Если спор будет принят, GRT, внесенные рыбаками, будут возвращены, спорный индексатор будет урезан, а рыбаки получат 50% от урезанных GRT.
 
-Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+Споры можно просматривать в интерфейсе на странице профиля Индексатора во вкладке `Disputes`.
 
 ### Что такое query fee rebates и когда они распределяются?
 

From ddd9d1ccc4de481a65f06077553d5ad3f648744a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 06:02:54 -0500
Subject: [PATCH 3506/3820] New translations arweave.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/arweave.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/arweave.mdx b/website/pages/ru/subgraphs/cookbook/arweave.mdx
index dea4407166df..dcd97fb5f5dc 100644
--- a/website/pages/ru/subgraphs/cookbook/arweave.mdx
+++ b/website/pages/ru/subgraphs/cookbook/arweave.mdx
@@ -2,7 +2,7 @@
 title: Создание Субграфов на Arweave
 ---
 
-> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+> Поддержка Arweave в Graph Node и Subgraph Studio находится на стадии бета-тестирования. Если у Вас есть вопросы о создании субграфов Arweave, свяжитесь с нами в [Discord](https://discord.gg/graphprotocol)!
 
 Из этого руководства Вы узнаете, как создавать и развертывать субграфы для индексации блокчейна Arweave.
 
@@ -13,7 +13,7 @@ title: Создание Субграфов на Arweave
 Arweave уже создала множество библиотек для интеграции протокола на нескольких различных языках программирования. С дополнительной информацией Вы можете ознакомиться:
 
 - [Arwiki](https://arwiki.wiki/#/en/main)
-- [Arweave Resources](https://www.arweave.org/build)
+- [Ресурсы Arweave](https://www.arweave.org/build)
 
 ## Что такое субграфы Arweave?
 

From d78da913bb0c88a701b6ce7d40c6194cfe13ee19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 07:07:47 -0500
Subject: [PATCH 3507/3820] New translations arweave.mdx (Russian)

---
 .../pages/ru/subgraphs/cookbook/arweave.mdx   | 48 +++++++++----------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/arweave.mdx b/website/pages/ru/subgraphs/cookbook/arweave.mdx
index dcd97fb5f5dc..8dc25a0e2780 100644
--- a/website/pages/ru/subgraphs/cookbook/arweave.mdx
+++ b/website/pages/ru/subgraphs/cookbook/arweave.mdx
@@ -17,32 +17,32 @@ Arweave уже создала множество библиотек для ин
 
 ## Что такое субграфы Arweave?
 
-The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+The Graph позволяет создавать собственные открытые API, называемые "Субграфами". Субграфы используются для указания индексаторам (операторам серверов), какие данные индексировать на блокчейне и сохранять на их серверах, чтобы Вы могли запрашивать эти данные в любое время используя [GraphQL](https://graphql.org/).
 
-[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+[Graph Node](https://github.com/graphprotocol/graph-node) теперь может индексировать данные на протоколе Arweave. Текущая интеграция индексирует только Arweave как блокчейн (блоки и транзакции), она еще не индексирует сохраненные файлы.
 
 ## Построение Субграфа на Arweave
 
 Чтобы иметь возможность создавать и развертывать Субграфы на Arweave, Вам понадобятся два пакета:
 
-1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
-2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+1. `@graphprotocol/graph-cli` версии выше 0.30.2 — это инструмент командной строки для создания и развертывания субграфов. [Нажмите здесь](https://www.npmjs.com/package/@graphprotocol/graph-cli), чтобы скачать с помощью `npm`.
+2. `@graphprotocol/graph-ts` версии выше 0.27.0 — это библиотека типов, специфичных для субграфов. [Нажмите здесь](https://www.npmjs.com/package/@graphprotocol/graph-ts), чтобы скачать с помощью `npm`.
 
 ## Составляющие Субграфов
 
 Существует 3 компонента субграфа:
 
-### 1. Manifest - `subgraph.yaml`
+### 1. Манифест - `subgraph.yaml`
 
 Определяет источники данных, представляющие интерес, и то, как они должны обрабатываться. Arweave - это новый вид источника данных.
 
-### 2. Schema - `schema.graphql`
+### 2. Схема - `schema.graphql`
 
 Здесь Вы определяете, какие данные хотите иметь возможность запрашивать после индексации своего субграфа с помощью GraphQL. На самом деле это похоже на модель для API, где модель определяет структуру тела запроса.
 
-The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+Требования для субграфов Arweave описаны в [имеющейся документации](/developing/creating-a-subgraph/#the-graphql-schema).
 
-### 3. AssemblyScript Mappings - `mapping.ts`
+### 3. Мэппинги на AssemblyScript - `mapping.ts`
 
 Это логика, которая определяет, как данные должны извлекаться и храниться, когда кто-то взаимодействует с источниками данных, которые Вы отслеживаете. Данные переводятся и сохраняются в соответствии с указанной Вами схемой.
 
@@ -55,7 +55,7 @@ $ graph build # генерирует Web Assembly из файлов AssemblyScri
 
 ## Определение манифеста субграфа
 
-The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+Манифест субграфа `subgraph.yaml` определяет источники данных для субграфа, триггеры, представляющие интерес, и функции, которые должны выполняться в ответ на эти триггеры. Ниже приведён пример манифеста субграфа для Arweave:
 
 ```yaml
 specVersion: 0.0.5
@@ -82,30 +82,30 @@ dataSources:
         - handler: handleTx # имя функции в файле мэппинга
 ```
 
-- Arweave subgraphs introduce a new kind of data source (`arweave`)
-- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Субграфы Arweave вводят новый тип источника данных (`arweave`)
+- Сеть должна соответствовать сети на размещенной Graph Node. В Subgraph Studio мейннет Arweave обозначается как `arweave-mainnet`
 - Источники данных Arweave содержат необязательное поле source.owner, которое является открытым ключом кошелька Arweave
 
 Источники данных Arweave поддерживают два типа обработчиков:
 
-- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
-- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+- `blockHandlers` — выполняется при каждом новом блоке Arweave. source.owner не требуется.
+- `transactionHandlers` — выполняется при каждой транзакции, где `source.owner` является владельцем источника данных. На данный момент для `transactionHandlers` требуется указать владельца. Если пользователи хотят обрабатывать все транзакции, они должны указать `""` в качестве `source.owner`
 
 > Source.owner может быть адресом владельца или его Публичным ключом.
 >
 > Транзакции являются строительными блоками Arweave permaweb, и они представляют собой объекты, созданные конечными пользователями.
 >
-> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+> Примечание: транзакции [Irys (ранее Bundlr)](https://irys.xyz/) пока не поддерживаются.
 
 ## Определение схемы
 
-Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+Определение схемы описывает структуру базы данных итогового субграфа и взаимосвязи между объектами. Это не зависит от исходного источника данных. Более подробную информацию об определении схемы субграфа можно найти [здесь](/developing/creating-a-subgraph/#the-graphql-schema).
 
 ## Мэппинги AssemblyScript
 
-The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+Обработчики для обработки событий написаны на [AssemblyScript](https://www.assemblyscript.org/).
 
-Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+Индексирование Arweave вводит специфичные для Arweave типы данных в [API AssemblyScript](https://thegraph. com/docs/using-graph-ts).
 
 ```tsx
 class Block {
@@ -146,13 +146,13 @@ class Transaction {
 }
 ```
 
-Block handlers receive a `Block`, while transactions receive a `Transaction`.
+Обработчики блоков получают `Block`, в то время как обработчики транзакций получают `Transaction`.
 
-Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+Написание мэппингов для субграфа Arweave очень похоже на написание мэппингов для субграфа Ethereum. Для получения дополнительной информации нажмите [сюда](/developing/creating-a-subgraph/#writing-mappings).
 
 ## Развертывание субграфа Arweave в Subgraph Studio
 
-Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+Как только Ваш субграф будет создан на панели управления Subgraph Studio, Вы можете развернуть его с помощью команды CLI `graph deploy`.
 
 ```bash
 graph deploy --access-token <your-access-token>
@@ -160,13 +160,13 @@ graph deploy --access-token <your-access-token>
 
 ## Запрос субграфа Arweave
 
-The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+Конечная точка GraphQL для субграфов Arweave определяется схемой и существующим интерфейсом API. Для получения дополнительной информации ознакомьтесь с [документацией по API GraphQL](/subgraphs/querying/graphql-api/).
 
 ## Примеры субграфов
 
 Ниже приведен пример субграфа для справки:
 
-- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+- [Пример субграфа для Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
 
 ## Часто задаваемые вопросы
 
@@ -188,9 +188,9 @@ Source.owner может быть открытым ключом пользова
 
 ### Каков текущий формат шифрования?
 
-Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+Данные обычно передаются в мэппингах в виде байтов (Bytes), которые, если хранятся напрямую, возвращаются в субграф в формате `hex` (например, хэши блоков и транзакций). Вы можете захотеть преобразовать их в формат `base64` или `base64 URL`-безопасный в Ваших мэппингах, чтобы они соответствовали тому, что отображается в блок-обозревателях, таких как [Arweave Explorer](https://viewblock.io/arweave/).
 
-The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+Следующая вспомогательная функция `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` может быть использована и будет добавлена в `graph-ts`:
 
 ```
 const base64Alphabet = [

From 4d62f1cddbe4a3c5a04413a1e98825cf16856dab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 07:07:48 -0500
Subject: [PATCH 3508/3820] New translations avoid-eth-calls.mdx (Russian)

---
 .../ru/subgraphs/cookbook/avoid-eth-calls.mdx    | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx
index 80ecc6482f4b..0c55df6e4852 100644
--- a/website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx
+++ b/website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -99,18 +99,18 @@ The handler itself accesses the result of this `eth_call` exactly as in the prev
 
 ## Заключение
 
-You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+Вы можете значительно улучшить производительность индексирования, минимизируя или исключая `eth_calls` в своих субграфах.
 
-## Subgraph Best Practices 1-6
+## Лучшие практики для субграфов 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Увеличение скорости запросов с помощью обрезки субграфов](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Улучшение индексирования и отклика запросов с использованием @derivedFrom](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Улучшение индексирования и производительности запросов с использованием неизменяемых объектов и байтов в качестве идентификаторов](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Увеличение скорости индексирования путем избегания `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Упрощение и оптимизация с помощью временных рядов и агрегаций](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Использование переноса (графтинга) для быстрого развертывания исправлений](/subgraphs/cookbook/grafting-hotfix/)

From 789062f4bbab036d794f67b21e042acf74cac2e7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 07:07:49 -0500
Subject: [PATCH 3509/3820] New translations cosmos.mdx (Russian)

---
 .../pages/ru/subgraphs/cookbook/cosmos.mdx    | 84 +++++++++----------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/cosmos.mdx b/website/pages/ru/subgraphs/cookbook/cosmos.mdx
index 01fa7ffd710f..cfa4b94b970f 100644
--- a/website/pages/ru/subgraphs/cookbook/cosmos.mdx
+++ b/website/pages/ru/subgraphs/cookbook/cosmos.mdx
@@ -2,26 +2,26 @@
 title: Создание субграфов на Cosmos
 ---
 
-This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+Это руководство служит введением в создание субграфов для индексирования блокчейнов, основанных на экосистеме [Cosmos](https://cosmos.network/).
 
 ## Что такое субграфы на Cosmos?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+The Graph позволяет разработчикам обрабатывать события блокчейна и предоставлять полученные данные через открытый GraphQL API, называемый субграфом. [Graph Node](https://github.com/graphprotocol/graph-node) теперь способен обрабатывать события Cosmos, что означает, что разработчики Cosmos могут создавать субграфы для удобного индексирования событий на чейне.
 
 Существует четыре типа обработчиков, поддерживаемых в субграфах Cosmos:
 
-- **Block handlers** run whenever a new block is appended to the chain.
-- **Event handlers** run when a specific event is emitted.
-- **Transaction handlers** run when a transaction occurs.
-- **Message handlers** run when a specific message occurs.
+- **Обработчики блоков** запускаются каждый раз, когда новый блок добавляется в чейн.
+- **Обработчики событий** запускаются, когда происходит определённое событие.
+- **Обработчики транзакций** запускаются при выполнении транзакции.
+- **Обработчики сообщений** запускаются при появлении определённого сообщения.
 
-Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+На основе [официальной документации Cosmos](https://docs.cosmos.network/):
 
-> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+> [События](https://docs.cosmos.network/main/learn/advanced/events) — это объекты, содержащие информацию о выполнении приложения. Они используются в основном сервисами, такими как сервисы для отслеживания блоков и кошельки, для отслеживания выполнения различных сообщений и индексирования транзакций.
 >
-> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+> [Транзакции](https://docs.cosmos.network/main/learn/advanced/transactions) — это объекты, создаваемые конечными пользователями для инициирования изменений состояния в приложении.
 >
-> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+> [Сообщения](https://docs.cosmos.network/main/learn/advanced/transactions#messages) — это специфичные для модулей объекты, которые инициируют переходы состояния в рамках модуля, к которому они относятся.
 
 Хотя доступ ко всем данным можно получить с помощью обработчика блоков, другие обработчики позволяют разработчикам субграфов обрабатывать данные гораздо более детально.
 
@@ -29,23 +29,23 @@ Based on the [official Cosmos documentation](https://docs.cosmos.network/):
 
 ### Зависимости субграфа
 
-[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) — это инструмент командной строки для создания и развертывания субграфов. Для работы с субграфами Cosmos требуется версия `>=0.30.0`.
 
-[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) — это библиотека типов, специфичных для субграфов, для работы с субграфами Cosmos требуется версия `>=0.27.0`.
 
 ### Основные компоненты субграфа
 
 Когда дело доходит до определения субграфа, имеется три ключевых момента:
 
-**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+**subgraph.yaml**: файл YAML, содержащий манифест субграфа, который определяет, какие события отслеживать и как их обрабатывать.
 
-**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+**schema.graphql**: схема GraphQL, которая определяет, какие данные хранятся для Вашего субграфа и как их можно запрашивать через GraphQL.
 
-**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+**Мэппинги на AssemblyScript**: код на [AssemblyScript](https://github.com/AssemblyScript/assemblyscript), который преобразует данные блокчейна в объекты, определенные в Вашей схеме.
 
 ### Определение манифеста субграфа
 
-The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+Манифест субграфа (`subgraph.yaml`) идентифицирует источники данных для субграфа, триггеры, представляющие интерес, и функции (`handlers`), которые должны быть выполнены в ответ на эти триггеры. Ниже приведен пример манифеста субграфа для субграфа Cosmos:
 
 ```yaml
 specVersion: 0.0.5
@@ -74,18 +74,18 @@ dataSources:
       file: ./src/mapping.ts # ссылка на мэппинг-файл скрипта сборки
 ```
 
-- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
-- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+- Субграфы Cosmos вводят новый `kind` (тип) источника данных (`cosmos`).
+- `network` (сеть) должна соответствовать чейну в экосистеме Cosmos. В этом примере используется майннет Cosmos Hub.
 
 ### Определение схемы
 
-Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+Определение схемы описывает структуру итоговой базы данных субграфа и отношения между объектами. Это не зависит от исходного источника данных. Более подробную информацию об определении схемы субграфа можно найти [здесь](/developing/creating-a-subgraph/#the-graphql-schema).
 
 ### Мэппинги AssemblyScript
 
-The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+Обработчики для обработки событий написаны на [AssemblyScript](https://www.assemblyscript.org/).
 
-Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+Индексирование Cosmos вводит специфичные для Cosmos типы данных в [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
 
 ```tsx
 class Block {
@@ -165,30 +165,30 @@ class Any {
 
 Каждый тип обработчика имеет свою собственную структуру данных, которая передается в качестве аргумента функции мэппинга.
 
-- Block handlers receive the `Block` type.
-- Event handlers receive the `EventData` type.
-- Transaction handlers receive the `TransactionData` type.
-- Message handlers receive the `MessageData` type.
+- Обработчики блоков получают тип `Block`.
+- Обработчики событий получают тип `EventData`.
+- Обработчики транзакций получают тип `TransactionData`.
+- Обработчики сообщений получают тип `MessageData`.
 
-As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+Как часть `MessageData`, обработчик сообщений получает контекст транзакции, который содержит наиболее важную информацию о транзакции, в рамках которой было выполнено сообщение. Контекст транзакции также доступен в типе `EventData`, но только когда соответствующее событие связано с транзакцией. Кроме того, все обработчики получают ссылку на блок (`HeaderOnlyBlock`).
 
-You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+Полный список типов для интеграции с Cosmos можно найти [здесь](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
 
 ### Расшифровка сообщений
 
-It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+Важно отметить, что сообщения Cosmos специфичны для каждого чейна и передаются в субграф в виде сериализованного полезного груза [Protocol Buffers](https://protobuf.dev/). В результате, данные сообщения необходимо декодировать в функции мэппинга, прежде чем они смогут быть обработаны.
 
-An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+Пример того, как декодировать данные сообщений в субграфе, можно найти [здесь](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
 
 ## Создание и построение субграфа на Cosmos
 
-The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+Первым шагом перед написанием мэппингов субграфа является генерация привязок типов на основе объектов, определённых в файле схемы субграфа (`schema.graphql`). Это позволит функциям мэппинга создавать новые объекты этих типов и сохранять их в хранилище. Это делается с помощью команды CLI `codegen`:
 
 ```bash
 $ graph codegen
 ```
 
-Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+Как только мэппинги будут готовы, нужно построить субграф. Этот шаг выявит все ошибки, которые могут быть в манифесте или мэппингах. Субграф должен успешно построиться, чтобы его можно было развернуть на Graph Node. Это делается с помощью команды CLI `build`:
 
 ```bash
 $ graph build
@@ -196,7 +196,7 @@ $ graph build
 
 ## Развертывание субграфа на Cosmos
 
-Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+После того как субграф создан, его можно развернуть с помощью команды `graph deploy` в CLI:
 
 **Subgraph Studio**
 
@@ -206,7 +206,7 @@ Once your subgraph has been created, you can deploy your subgraph by using the `
 graph deploy subgraph-name
 ```
 
-**Local Graph Node (based on default configuration):**
+**Локальный Graph Node (на основе конфигурации по умолчанию):**
 
 ```bash
 graph create subgraph-name --node http://localhost:8020
@@ -218,7 +218,7 @@ graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost
 
 ## Запрос субграфа на Cosmos
 
-The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+Конечная точка GraphQL для субграфов Cosmos определяется схемой, с использованием существующего интерфейса API. Пожалуйста, изучите [документацию по GraphQL API](/subgraphs/querying/graphql-api/) для получения дополнительной информации.
 
 ## Поддерживаемые блокчейны Cosmos
 
@@ -226,11 +226,11 @@ The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition
 
 #### Что такое Cosmos Hub?
 
-The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+[Блокчейн Cosmos Hub](https://hub.cosmos.network/) — это первый блокчейн в экосистеме [Cosmos](https://cosmos.network/). Для получения дополнительной информации Вы можете ознакомиться с [официальной документацией](https://docs.cosmos.network/).
 
 #### Сети
 
-Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+Майннет Cosmos Hub называется `cosmoshub-4`. Текущий тестнет Cosmos Hub — `theta-testnet-001`. <br/>Другие сети Cosmos Hub, такие как `cosmoshub-3`, приостановлены, поэтому данные для них не предоставляются.
 
 ### Osmosis
 
@@ -238,20 +238,20 @@ Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testne
 
 #### Что такое Osmosis?
 
-[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+[Osmosis](https://osmosis.zone/) — это децентрализованный протокол автоматизированного маркет-мейкера (AMM), построенный на основе Cosmos SDK. Он позволяет пользователям создавать собственные пулы ликвидности и торговать токенами, поддерживающими IBC. Для получения дополнительной информации, Вы можете ознакомиться с [официальной документацией](https://docs.osmosis.zone/).
 
 #### Сети
 
-Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+Майннет Osmosis — это `osmosis-1`. Текущий тестнет Osmosis — это `osmo-test-4`.
 
 ## Примеры субграфов
 
 Вот несколько примеров субграфов для справки:
 
-[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+[Пример фильтрации блоков](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
 
-[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+[Пример вознаграждений валидатора](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
 
-[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+[Пример делегирования валидатора](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
 
-[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)
+[Пример обмена токенов Osmosis](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 5d47a9b4eaf409a265d85fc67ee6ecede0877954 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 07:07:50 -0500
Subject: [PATCH 3510/3820] New translations derivedfrom.mdx (Russian)

---
 .../pages/ru/subgraphs/cookbook/derivedfrom.mdx    | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx b/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
index 52a99ea31495..3873a0450aa5 100644
--- a/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
@@ -73,16 +73,16 @@ Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically
 
 For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
 
-## Subgraph Best Practices 1-6
+## Лучшие практики для субграфов 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Увеличение скорости запросов с помощью обрезки субграфов](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Улучшение индексирования и отклика запросов с использованием @derivedFrom](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Улучшение индексирования и производительности запросов с использованием неизменяемых объектов и байтов в качестве идентификаторов](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Увеличение скорости индексирования путем избегания `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Упрощение и оптимизация с помощью временных рядов и агрегаций](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Использование переноса (графтинга) для быстрого развертывания исправлений](/subgraphs/cookbook/grafting-hotfix/)

From 4b6d456104699cb78148beee32d8cae9da6e927a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 07:07:51 -0500
Subject: [PATCH 3511/3820] New translations grafting-hotfix.mdx (Russian)

---
 .../ru/subgraphs/cookbook/grafting-hotfix.mdx      | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
index 37a0180f89e1..2c9fcb2c8067 100644
--- a/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
@@ -171,16 +171,16 @@ However, it’s important to use grafting judiciously and follow best practices
 
 By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
 
-## Subgraph Best Practices 1-6
+## Лучшие практики для субграфов 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Увеличение скорости запросов с помощью обрезки субграфов](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Улучшение индексирования и отклика запросов с использованием @derivedFrom](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Улучшение индексирования и производительности запросов с использованием неизменяемых объектов и байтов в качестве идентификаторов](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Увеличение скорости индексирования путем избегания `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Упрощение и оптимизация с помощью временных рядов и агрегаций](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Использование переноса (графтинга) для быстрого развертывания исправлений](/subgraphs/cookbook/grafting-hotfix/)

From 5479d66532e88b38172a7a1db573a8d2da7e0840 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 07:07:52 -0500
Subject: [PATCH 3512/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Russian)

---
 .../cookbook/immutable-entities-bytes-as-ids.mdx   | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
index ebe5e47b36e9..4c0710ecbe66 100644
--- a/website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -175,16 +175,16 @@ Using both Immutable Entities and Bytes as IDs has been shown to markedly improv
 
 Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
 
-## Subgraph Best Practices 1-6
+## Лучшие практики для субграфов 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Увеличение скорости запросов с помощью обрезки субграфов](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Улучшение индексирования и отклика запросов с использованием @derivedFrom](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Улучшение индексирования и производительности запросов с использованием неизменяемых объектов и байтов в качестве идентификаторов](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Увеличение скорости индексирования путем избегания `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Упрощение и оптимизация с помощью временных рядов и агрегаций](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Использование переноса (графтинга) для быстрого развертывания исправлений](/subgraphs/cookbook/grafting-hotfix/)

From 8b366a72074a44486023b260ffae71ede0f46716 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 07:07:54 -0500
Subject: [PATCH 3513/3820] New translations near.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/near.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/near.mdx b/website/pages/ru/subgraphs/cookbook/near.mdx
index 6956ccaa3c4c..df004acc3124 100644
--- a/website/pages/ru/subgraphs/cookbook/near.mdx
+++ b/website/pages/ru/subgraphs/cookbook/near.mdx
@@ -92,11 +92,11 @@ accounts:
 
 ### Определение схемы
 
-Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+Определение схемы описывает структуру итоговой базы данных субграфа и отношения между объектами. Это не зависит от исходного источника данных. Более подробную информацию об определении схемы субграфа можно найти [здесь](/developing/creating-a-subgraph/#the-graphql-schema).
 
 ### Мэппинги AssemblyScript
 
-The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+Обработчики для обработки событий написаны на [AssemblyScript](https://www.assemblyscript.org/).
 
 NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
 
@@ -182,7 +182,7 @@ More information on creating and deploying subgraphs on Subgraph Studio can be f
 
 As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
 
-Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+После того как субграф создан, его можно развернуть с помощью команды `graph deploy` в CLI:
 
 ```sh
 $ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)

From 06f7af3c26a56175a2b135c6078a5cf17dc57ed4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 07:07:55 -0500
Subject: [PATCH 3514/3820] New translations pruning.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/pruning.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/pruning.mdx b/website/pages/ru/subgraphs/cookbook/pruning.mdx
index 42775eb9f7fe..4690f9bcd48d 100644
--- a/website/pages/ru/subgraphs/cookbook/pruning.mdx
+++ b/website/pages/ru/subgraphs/cookbook/pruning.mdx
@@ -40,16 +40,16 @@ dataSources:
 
 Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
 
-## Subgraph Best Practices 1-6
+## Лучшие практики для субграфов 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Увеличение скорости запросов с помощью обрезки субграфов](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Улучшение индексирования и отклика запросов с использованием @derivedFrom](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Улучшение индексирования и производительности запросов с использованием неизменяемых объектов и байтов в качестве идентификаторов](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Увеличение скорости индексирования путем избегания `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Упрощение и оптимизация с помощью временных рядов и агрегаций](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Использование переноса (графтинга) для быстрого развертывания исправлений](/subgraphs/cookbook/grafting-hotfix/)

From 7bcc797b1aa988355478be14ffa55022b006431a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 07:07:56 -0500
Subject: [PATCH 3515/3820] New translations timeseries.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/timeseries.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/timeseries.mdx b/website/pages/ru/subgraphs/cookbook/timeseries.mdx
index 99228ae7d56d..ad43578c6277 100644
--- a/website/pages/ru/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/ru/subgraphs/cookbook/timeseries.mdx
@@ -179,16 +179,16 @@ Implementing timeseries and aggregations in subgraphs is a best practice for pro
 
 By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
 
-## Subgraph Best Practices 1-6
+## Лучшие практики для субграфов 1-6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Увеличение скорости запросов с помощью обрезки субграфов](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Улучшение индексирования и отклика запросов с использованием @derivedFrom](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Улучшение индексирования и производительности запросов с использованием неизменяемых объектов и байтов в качестве идентификаторов](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Увеличение скорости индексирования путем избегания `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Упрощение и оптимизация с помощью временных рядов и агрегаций](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Использование переноса (графтинга) для быстрого развертывания исправлений](/subgraphs/cookbook/grafting-hotfix/)

From c7f367dd6d1d5e05b0982a7b381b4a1d9256c4b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 08:05:08 -0500
Subject: [PATCH 3516/3820] New translations derivedfrom.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/derivedfrom.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx b/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
index 3873a0450aa5..b567d0d0c03d 100644
--- a/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
@@ -65,13 +65,13 @@ Just by adding the `@derivedFrom` directive, this schema will only store the “
 
 2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
 
-3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+3. Мы можем использовать [Загрузчики производных полей](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities), чтобы получить возможность напрямую обращаться и манипулировать данными из виртуальных отношений в наших мэппингах субграфа.
 
 ## Заключение
 
-Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+Используйте директиву `@derivedFrom` в субграфах для эффективного управления динамически растущими массивами, улучшая эффективность индексирования и извлечения данных.
 
-For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+Для более подробного объяснения стратегий, которые помогут избежать использования больших массивов, ознакомьтесь с блогом Кевина Джонса: [Лучшие практики разработки субграфов: как избежать больших массивов](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
 
 ## Лучшие практики для субграфов 1-6
 

From 3b8ed93be166ad075a8efefa7af2588ff867eeb3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 08:05:09 -0500
Subject: [PATCH 3517/3820] New translations enums.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/enums.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/enums.mdx b/website/pages/ru/subgraphs/cookbook/enums.mdx
index bf4f37f4152a..98f2f429b18c 100644
--- a/website/pages/ru/subgraphs/cookbook/enums.mdx
+++ b/website/pages/ru/subgraphs/cookbook/enums.mdx
@@ -1,8 +1,8 @@
 ---
-title: Categorize NFT Marketplaces Using Enums
+title: Категоризация маркетплейсов NFT с использованием Enum (перечислений)
 ---
 
-Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+Используйте перечисления (Enums), чтобы сделать Ваш код чище и уменьшить вероятность ошибок. Вот полный пример использования перечислений для маркетплейсов NFT.
 
 ## What are Enums?
 

From b7254e35e7208717cd401adb4df88ce70ef09231 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 09:13:00 -0500
Subject: [PATCH 3518/3820] New translations explorer.mdx (Russian)

---
 website/pages/ru/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/explorer.mdx b/website/pages/ru/subgraphs/explorer.mdx
index 55b8baf59331..5530853a770e 100644
--- a/website/pages/ru/subgraphs/explorer.mdx
+++ b/website/pages/ru/subgraphs/explorer.mdx
@@ -67,7 +67,7 @@ This page provides a bird's-eye view of all "participants," which includes every
 
 В таблице Индексаторов Вы можете увидеть параметры делегирования Индексаторов, их стейк, сумму стейка, которую они поставили на каждый субграф, а также размер дохода, который они получили от комиссий за запросы и вознаграждений за индексирование.
 
-**Specifics**
+**Особенности**
 
 - Часть комиссии за запросы — это процент от возвратов комиссии за запросы, который Индексатор оставляет себе при распределении с Делегаторами.
 - Эффективная часть вознаграждения — это доля вознаграждения за индексирование, применяемая к пулу делегирования. Если она отрицательная, это означает, что Индексатор отдаёт часть своих вознаграждений. Если она положительная, это означает, что Индексатор сохраняет часть своих вознаграждений.

From 0163fae4957310a4dd2af6d3774d81242ec643d2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 09:13:03 -0500
Subject: [PATCH 3519/3820] New translations enums.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/enums.mdx | 115 +++++++++---------
 1 file changed, 58 insertions(+), 57 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/enums.mdx b/website/pages/ru/subgraphs/cookbook/enums.mdx
index 98f2f429b18c..bb21ea1609b2 100644
--- a/website/pages/ru/subgraphs/cookbook/enums.mdx
+++ b/website/pages/ru/subgraphs/cookbook/enums.mdx
@@ -1,20 +1,21 @@
 ---
-title: Категоризация маркетплейсов NFT с использованием Enum (перечислений)
+title: Категоризация маркетплейсов NFT с использованием Enums (перечислений)
 ---
 
-Используйте перечисления (Enums), чтобы сделать Ваш код чище и уменьшить вероятность ошибок. Вот полный пример использования перечислений для маркетплейсов NFT.
+Используйте Enums (перечисления), чтобы сделать Ваш код чище и уменьшить вероятность ошибок. Вот полный пример использования перечислений для маркетплейсов NFT.
 
-## What are Enums?
+## Что такое Enums (перечисления)?
 
-Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+Перечисления (или типы перечислений) — это особый тип данных, который позволяет определить набор конкретных допустимых значений.
 
-### Example of Enums in Your Schema
+### Пример использования Enums (перечислений) в Вашей схеме
 
-If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+Если вы создаете субграф для отслеживания истории владения токенами на рынке, каждый токен может переходить через разные стадии владения, такие как `OriginalOwner` (Первоначальный Владелец), `SecondOwner` (Второй Владелец) и `ThirdOwner` (Третий 
+Владелец). Используя перечисления (enums), Вы можете определить эти конкретные стадии владения, обеспечивая присвоение только заранее определенных значений.
 
-You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+Вы можете определить перечисления (enums) в своей схеме, и после их определения Вы можете использовать строковое представление значений перечислений для установки значения поля перечисления в объекты.
 
-Here's what an enum definition might look like in your schema, based on the example above:
+Вот как может выглядеть определение перечисления (enum) в Вашей схеме, исходя из приведенного выше примера:
 
 ```graphql
 enum TokenStatus {
@@ -24,19 +25,19 @@ enum TokenStatus {
 }
 ```
 
-This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+Это означает, что когда Вы используете тип `TokenStatus` в своей схеме, Вы ожидаете, что он будет иметь одно из заранее определенных значений: `OriginalOwner` (Первоначальный Владелец), `SecondOwner` (Второй Владелец) или `ThirdOwner` (Третий Владелец), что обеспечивает согласованность и корректность данных.
 
-To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+Чтобы узнать больше о перечислениях (Enums), ознакомьтесь с разделом [Создание субграфа](/developing/creating-a-subgraph/#enums) и с [документацией GraphQL](https://graphql.org/learn/schema/#enumeration-types).
 
-## Benefits of Using Enums
+## Преимущества использования перечислений (Enums)
 
-- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
-- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
-- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+- **Ясность:** Перечисления предоставляют значимые имена для значений, что делает данные более понятными.
+- **Валидация:** Перечисления обеспечивают строгие определения значений, предотвращая ввод недопустимых данных.
+- **Поддерживаемость:** Когда Вам нужно изменить или добавить новые категории, перечисления позволяют сделать это целенаправленно и удобно.
 
-### Without Enums
+### Без перечислений (Enums)
 
-If you choose to define the type as a string instead of using an Enum, your code might look like this:
+Если Вы решите определить тип как строку вместо использования перечисления (Enum), Ваш код может выглядеть следующим образом:
 
 ```graphql
 type Token @entity {
@@ -48,85 +49,85 @@ type Token @entity {
 }
 ```
 
-In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+В этой схеме `TokenStatus` является простой строкой без конкретных и допустимых значений.
 
 #### Почему это является проблемой?
 
-- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
-- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+- Нет никаких ограничений на значения `TokenStatus`, поэтому любое строковое значение может быть назначено случайно. Это усложняет обеспечение того, что устанавливаются только допустимые статусы, такие как `OriginalOwner` (Первоначальный Владелец), `SecondOwner` (Второй Владелец) или `ThirdOwner` (Третий Владелец).
+- Легко допустить опечатку, например, `Orgnalowner` вместо `OriginalOwner`, что делает данные и потенциальные запросы ненадежными.
 
-### With Enums
+### С перечислениями (Enums)
 
-Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+Вместо присвоения строк произвольной формы Вы можете определить перечисление (Enum) для `TokenStatus` с конкретными значениями: `OriginalOwner`, `SecondOwner` или `ThirdOwner`. Использование перечисления гарантирует, что используются только допустимые значения.
 
-Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+Перечисления обеспечивают безопасность типов, минимизируют риск опечаток и гарантируют согласованные и надежные результаты.
 
-## Defining Enums for NFT Marketplaces
+## Определение перечислений (Enums) для Маркетплейсов NFT
 
-> Note: The following guide uses the CryptoCoven NFT smart contract.
+> Примечание: Следующее руководство использует смарт-контракт NFT CryptoCoven.
 
-To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+Чтобы определить перечисления для различных маркетплейсов, на которых торгуются NFT, используйте следующее в своей схеме субграфа:
 
 ```gql
-# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+# Перечисление для маркетплейсов, с которыми взаимодействовал смарт-контракт CryptoCoven (вероятно, торговля или минт)
 enum Marketplace {
-  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
-  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
-  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
-  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
-  # ...and other marketplaces
+  OpenSeaV1 # Представляет случай, когда NFT CryptoCoven торгуется на маркетплейсе OpenSeaV1
+  OpenSeaV2 # Представляет случай, когда NFT CryptoCoven торгуется на маркетплейсе OpenSeaV2
+  SeaPort   # Представляет случай, когда NFT CryptoCoven торгуется на маркетплейсе SeaPort
+  LooksRare # Представляет случай, когда NFT CryptoCoven торгуется на маркетплейсе LooksRare
+  # ...и другие рынки
 }
 ```
 
-## Using Enums for NFT Marketplaces
+## Использование перечислений (Enums) для Маркетплейсов NFT
 
-Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+После определения перечисления (enums) могут использоваться в Вашем субграфе для категоризации транзакций или событий.
 
-For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+Например, при регистрации продаж NFT можно указать маркетплейс, на котором произошла сделка, используя перечисление.
 
-### Implementing a Function for NFT Marketplaces
+### Реализация функции для маркетплейсов NFT
 
-Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+Вот как можно реализовать функцию для получения названия маркетплейса из перечисления (enum) в виде строки:
 
 ```ts
 export function getMarketplaceName(marketplace: Marketplace): string {
-  // Using if-else statements to map the enum value to a string
+  // Используем операторы if-else для сопоставления значения перечисления со строкой
   if (marketplace === Marketplace.OpenSeaV1) {
-    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+    return 'OpenSeaV1' // Если маркетплейс OpenSea, возвращаем его строковое представление
   } else if (marketplace === Marketplace.OpenSeaV2) {
     return 'OpenSeaV2'
   } else if (marketplace === Marketplace.SeaPort) {
-    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+    return 'SeaPort' // Если маркетплейс SeaPort, возвращаем его строковое представление
   } else if (marketplace === Marketplace.LooksRare) {
-    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
-    // ... and other market places
+    return 'LooksRare' // Если маркетплейс LooksRare, возвращаем его строковое представление
+    // ... и другие маркетплейсы
   }
 }
 ```
 
-## Best Practices for Using Enums
+## Лучшие практики использования перечислений (Enums)
 
-- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
-- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
-- **Documentation:** Add comments to enum to clarify their purpose and usage.
+- **Согласованность в наименованиях:** Используйте четкие, описательные названия для значений перечислений, чтобы улучшить читаемость кода.
+- **Централизованное управление:** Храните перечисления в одном файле для обеспечения согласованности. Это облегчает обновление перечислений и гарантирует, что они являются единственным источником достоверной информации.
+- **Документация:** Добавляйте комментарии к перечислениям, чтобы прояснить их назначение и использование.
 
-## Using Enums in Queries
+## Использование перечислений (Enums) в запросах
 
-Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+Перечисления в запросах помогают улучшить качество данных и делают результаты более понятными. Они функционируют как фильтры и элементы ответа, обеспечивая согласованность и уменьшая ошибки в значениях маркетплейса.
 
-**Specifics**
+**Особенности**
 
-- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
-- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+- **Фильтрация с помощью перечислений:** Перечисления предоставляют четкие фильтры, позволяя уверенно включать или исключать конкретные маркетплейсы.
+- **Перечисления в ответах:** Перечисления гарантируют, что возвращаются только признанные названия маркетплейсов, делая результаты стандартизированными и точными.
 
-### Sample Queries
+### Пример запросов
 
-#### Query 1: Account With The Highest NFT Marketplace Interactions
+#### Запрос 1: Аккаунт с наибольшим количеством взаимодействий на маркетплейсе NFT
 
-This query does the following:
+Этот запрос выполняет следующие действия:
 
-- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
-- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+- Он находит аккаунт с наибольшим количеством уникальных взаимодействий с маркетплейсами NFT, что полезно для анализа активности на разных маркетплейсах.
+- Поле маркетплейсов использует перечисление маркетплейс, что обеспечивает согласованность и валидацию значений маркетплейсов в ответе.
 
 ```gql
 {
@@ -188,7 +189,7 @@ This response provides account details and a list of unique marketplace interact
 
 #### Query 2: Most Active Marketplace for CryptoCoven transactions
 
-This query does the following:
+Этот запрос выполняет следующие действия:
 
 - It identifies the marketplace with the highest volume of CryptoCoven transactions.
 - It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
@@ -221,7 +222,7 @@ The expected response includes the marketplace and the corresponding transaction
 
 #### Query 3: Marketplace Interactions with High Transaction Counts
 
-This query does the following:
+Этот запрос выполняет следующие действия:
 
 - It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
 - It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.

From 7c339121dcbe0799a65e8100493c924bede9f613 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 09:13:05 -0500
Subject: [PATCH 3520/3820] New translations graphql-api.mdx (Hindi)

---
 .../hi/subgraphs/querying/graphql-api.mdx      | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/hi/subgraphs/querying/graphql-api.mdx b/website/pages/hi/subgraphs/querying/graphql-api.mdx
index d5242c331c1a..93096ea996aa 100644
--- a/website/pages/hi/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/hi/subgraphs/querying/graphql-api.mdx
@@ -385,25 +385,25 @@ Combine fulltext operators to make more complex filters. With a pretext search o
 
 ### मान्यकरण
 
-Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+Graph Node अपने द्वारा प्राप्त GraphQL क्वेरी की स्पेसिफिकेशन-आधारित(https://spec.graphql.org/October2021/#sec-Validation) वैलिडेशन करता है, जो graphql-tools-rs(https://github.com/dotansimha/graphql-tools-rs#validation-rules) पर आधारित है, जो graphql-js संदर्भ कार्यान्वयन(https://github.com/graphql/graphql-js/tree/main/src/validation) पर आधारित है। क्वेरी जो वैलिडेशन नियम में विफल होती हैं, वे एक मानक त्रुटि के साथ विफल होती हैं - अधिक जानने के लिए GraphQL स्पेसिफिकेशन(https://spec.graphql.org/October2021/#sec-Validation) पर जाएं।
 
 ## योजना
 
-The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+आपके डेटा स्रोतों का स्कीमा, अर्थात् उपलब्ध प्रश्न करने के लिए संस्थाओं की प्रकार, मान और उनके बीच के संबंध, GraphQL Interface Definition Language (IDL)(https://facebook.github.io/graphql/draft/#sec-Type-System) के माध्यम से परिभाषित किए गए हैं।
 
-GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+GraphQL स्कीमा आम तौर पर queries, subscriptions और mutations के लिए रूट प्रकार परिभाषित करते हैं। The Graph केवल queries का समर्थन करता है। आपके सबग्राफ के लिए रूट Query प्रकार स्वचालित रूप से उस GraphQL स्कीमा से उत्पन्न होता है जो आपके सबग्राफ manifest(/developing/creating-a-subgraph/#components-of-a-subgraph) में शामिल होता है।
 
 > ध्यान दें: हमारा एपीआई म्यूटेशन को उजागर नहीं करता है क्योंकि डेवलपर्स से उम्मीद की जाती है कि वे अपने एप्लिकेशन से अंतर्निहित ब्लॉकचेन के खिलाफ सीधे लेन-देन(transaction) जारी करेंगे।
 
 ### Entities
 
-All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+आपके स्कीमा में जिन भी GraphQL प्रकारों में @entity निर्देश होते हैं, उन्हें संस्थाएँ (entities) माना जाएगा और उनमें एक ID फ़ील्ड होना चाहिए।
 
-> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+> नोट: वर्तमान में, आपकी स्कीमा में सभी प्रकारों में @entity निर्देश होना चाहिए। भविष्य में, हम उन प्रकारों को मूल्य वस्तुएं मानेंगे जिनमें @entity निर्देश नहीं होगा, लेकिन यह अभी तक समर्थित नहीं है।
 
 ### सबग्राफ मेटाडेटा
 
-All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+सभी सबग्राफमें एक स्वचालित रूप से जनरेट किया गया _Meta_ ऑब्जेक्ट होता है, जो Subgraph मेटाडेटा तक पहुँच प्रदान करता है। इसे इस प्रकार क्वेरी किया जा सकता है:
 
 ```graphQL
 {
@@ -421,12 +421,12 @@ All subgraphs have an auto-generated `_Meta_` object, which provides access to s
 
 If a block is provided, the metadata is as of that block, if not the latest indexed block is used. If provided, the block must be after the subgraph's start block, and less than or equal to the most recently indexed block.
 
-`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+deployment एक विशिष्ट ID है, जो subgraph.yaml फ़ाइल के IPFS CID के अनुरूप है।
 
-`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+block नवीनतम ब्लॉक के बारे में जानकारी प्रदान करता है (किसी भी ब्लॉक सीमाओं को ध्यान में रखते हुए जो कि _meta में पास की जाती हैं):
 
 - हैश: ब्लॉक का हैश
 - नंबर: ब्लॉक नंबर
 - टाइमस्टैम्प: ब्लॉक का टाइमस्टैम्प, यदि उपलब्ध हो (यह वर्तमान में केवल ईवीएम नेटवर्क को इंडेक्स करने वाले सबग्राफ के लिए उपलब्ध है)
 
-`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block
+hasIndexingErrors एक बूलियन है जो यह पहचानता है कि क्या सबग्राफ ने किसी पिछले ब्लॉक पर इंडेक्सिंग त्रुटियों का सामना किया था।

From f9e1298d3887ecd502f2e417379153b5cbef80e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 09:13:06 -0500
Subject: [PATCH 3521/3820] New translations python.mdx (Hindi)

---
 website/pages/hi/subgraphs/querying/python.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/querying/python.mdx b/website/pages/hi/subgraphs/querying/python.mdx
index 4d1bbb06dde9..e4a101ed5156 100644
--- a/website/pages/hi/subgraphs/querying/python.mdx
+++ b/website/pages/hi/subgraphs/querying/python.mdx
@@ -53,4 +53,4 @@ Since subgrounds has a large feature set to explore, here are some helpful start
 - [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
   - Learn how to level up your queries by parallelizing them.
 - [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
-  - A quick article on how to seamlessly save your data as CSVs for further analysis.
+  - कैसे अपने डेटा को CSVs के रूप में सहजता से सहेजें ताकि आगे के विश्लेषण के लिए इसका उपयोग किया जा सके।

From f3a9d72ca81bd934d0ff98ef977ebb366f102adf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 09:13:07 -0500
Subject: [PATCH 3522/3820] New translations sunrise.mdx (Hindi)

---
 website/pages/hi/archived/sunrise.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/archived/sunrise.mdx b/website/pages/hi/archived/sunrise.mdx
index 059c432ef629..dddef1f79696 100644
--- a/website/pages/hi/archived/sunrise.mdx
+++ b/website/pages/hi/archived/sunrise.mdx
@@ -60,7 +60,7 @@ Edge & Node ने ऐतिहासिक रूप से होस्टे
 
 ### यह Subgraph डेवलपर्स को कैसे प्रभावित करता है?
 
-Subgraph developers can query their subgraphs on The Graph Network almost immediately after upgrading from the hosted service or [publishing from Subgraph Studio](/subgraphs/developing/publishing/publishing-a-subgraph/), as no lead time was required for indexing. Please note that [creating a subgraph](/developing/creating-a-subgraph/) was not impacted by this upgrade.
+सबग्राफ डेवलपर्स अपने सबग्राफ को The Graph Network पर लगभग तुरंत क्वेरी कर सकते हैं, जब वे होस्टेड सेवा से या Subgraph Studio()/subgraphs/developing/publishing/publishing-a-subgraph/ से प्रकाशित करते हैं, क्योंकि इंडेक्सिंग के लिए कोई लीड टाइम आवश्यक नहीं है। कृपया ध्यान दें कि सबग्राफ बनाना(/developing/creating-a-subgraph/) इस अपग्रेड से प्रभावित नहीं हुआ था।
 
 ### अपग्रेड Indexer डेटा उपभोक्ताओं को कैसे लाभ पहुंचाता है?
 

From 1447b2c46ddc8b5b076089486461041a486e0ec2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 09:13:09 -0500
Subject: [PATCH 3523/3820] New translations contracts.mdx (Hindi)

---
 website/pages/hi/contracts.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/contracts.mdx b/website/pages/hi/contracts.mdx
index d2255f3af336..65ff9167cf59 100644
--- a/website/pages/hi/contracts.mdx
+++ b/website/pages/hi/contracts.mdx
@@ -14,7 +14,7 @@ This is the principal deployment of The Graph Network.
 
 ## Mainnet
 
-This was the original deployment of The Graph Network. [Learn more](/archived/arbitrum/arbitrum-faq/) about The Graph's scaling with Arbitrum.
+यह The Graph Network का मूल डिप्लॉयमेंट था। Learn more()/archived/arbitrum/arbitrum-faq/ Arbitrum के साथ The Graph के स्केलिंग के बारे में अधिक जानें।
 
 <ProtocolContractsTable networkId={1} />
 

From 566081a7c52ce4f29475607cac8e4c7a04345ee8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 09:13:10 -0500
Subject: [PATCH 3524/3820] New translations new-chain-integration.mdx (Hindi)

---
 website/pages/hi/indexing/new-chain-integration.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/indexing/new-chain-integration.mdx b/website/pages/hi/indexing/new-chain-integration.mdx
index ea0daac8d64f..e5730b5c07ed 100644
--- a/website/pages/hi/indexing/new-chain-integration.mdx
+++ b/website/pages/hi/indexing/new-chain-integration.mdx
@@ -25,7 +25,7 @@ Graph Node को EVM चेन से डेटा इन्गेस्ट क
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- `trace_filter` _(limited tracing and optionally required for Graph Node)_
+- `trace_filter` _(सीमित ट्रेसिंग और विकल्पतः Graph Node के लिए आवश्यक)_
 
 ### 2. Firehose एकीकरण
 

From 33c16c9bd4f0882f2a07a39156ae8e83ad88c867 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 10:18:53 -0500
Subject: [PATCH 3525/3820] New translations enums.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/enums.mdx | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/enums.mdx b/website/pages/ru/subgraphs/cookbook/enums.mdx
index bb21ea1609b2..1801024c159b 100644
--- a/website/pages/ru/subgraphs/cookbook/enums.mdx
+++ b/website/pages/ru/subgraphs/cookbook/enums.mdx
@@ -127,7 +127,7 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 Этот запрос выполняет следующие действия:
 
 - Он находит аккаунт с наибольшим количеством уникальных взаимодействий с маркетплейсами NFT, что полезно для анализа активности на разных маркетплейсах.
-- Поле маркетплейсов использует перечисление маркетплейс, что обеспечивает согласованность и валидацию значений маркетплейсов в ответе.
+- Поле маркетплейсов использует перечисление marketplace, что обеспечивает согласованность и валидацию значений маркетплейсов в ответе.
 
 ```gql
 {
@@ -144,9 +144,9 @@ export function getMarketplaceName(marketplace: Marketplace): string {
 }
 ```
 
-#### Returns
+#### Результаты
 
-This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+Данный ответ включает информацию об аккаунте и перечень уникальных взаимодействий с маркетплейсом, где используются значения перечислений (enum) для обеспечения единообразной ясности:
 
 ```gql
 {
@@ -187,12 +187,12 @@ This response provides account details and a list of unique marketplace interact
 }
 ```
 
-#### Query 2: Most Active Marketplace for CryptoCoven transactions
+#### Запрос 2: Наиболее активный маркетплейс для транзакций CryptoCoven
 
 Этот запрос выполняет следующие действия:
 
-- It identifies the marketplace with the highest volume of CryptoCoven transactions.
-- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+- Он определяет маркетплейс с наибольшим объемом транзакций CryptoCoven.
+- Он использует перечисление marketplace, чтобы гарантировать, что в ответе будут только допустимые типы маркетплейсов, что повышает надежность и согласованность ваших данных.
 
 ```gql
 {
@@ -203,9 +203,9 @@ This response provides account details and a list of unique marketplace interact
 }
 ```
 
-#### Result 2
+#### Результат 2
 
-The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+Ожидаемый ответ включает маркетплейс и соответствующее количество транзакций, используя перечисление для указания типа маркетплейса:
 
 ```gql
 {
@@ -220,12 +220,12 @@ The expected response includes the marketplace and the corresponding transaction
 }
 ```
 
-#### Query 3: Marketplace Interactions with High Transaction Counts
+#### Запрос 3: Взаимодействия на маркетплейсе с высоким количеством транзакций
 
 Этот запрос выполняет следующие действия:
 
-- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
-- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+- Он извлекает четыре самых активных маркетплейса с более чем 100 транзакциями, исключая маркетплейсы с типом "Unknown".
+- Он использует перечисления в качестве фильтров, чтобы гарантировать, что включены только допустимые типы маркетплейсов, что повышает точность выполнения запроса.
 
 ```gql
 {
@@ -241,9 +241,9 @@ The expected response includes the marketplace and the corresponding transaction
 }
 ```
 
-#### Result 3
+#### Результат 3
 
-Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+Ожидаемый вывод включает маркетплейсы, которые соответствуют критериям, каждый из которых представлен значением перечисления:
 
 ```gql
 {
@@ -272,4 +272,4 @@ Expected output includes the marketplaces that meet the criteria, each represent
 
 ## Дополнительные ресурсы
 
-For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).
+Дополнительную информацию можно найти в [репозитории] этого руководства (https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).

From e63a588dd851dcee5153ed7be3c394e23bde3560 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 10:18:54 -0500
Subject: [PATCH 3526/3820] New translations tokenomics.mdx (Hindi)

---
 website/pages/hi/resources/tokenomics.mdx | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/hi/resources/tokenomics.mdx b/website/pages/hi/resources/tokenomics.mdx
index 4a0b60ee9ad9..474009fd67e2 100644
--- a/website/pages/hi/resources/tokenomics.mdx
+++ b/website/pages/hi/resources/tokenomics.mdx
@@ -5,13 +5,13 @@ description: The Graph Network को शक्तिशाली टोकन
 
 ## अवलोकन
 
-The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+The Graph एक विकेन्द्रीकृत प्रोटोकॉल है जो ब्लॉकचेन डेटा तक आसान पहुंच सक्षम करता है। यह ब्लॉकचेन डेटा को उसी तरह से अनुक्रमित करता है जैसे Google वेब को अनुक्रमित करता है। यदि आपने किसी dapp का उपयोग किया है जो किसी Subgraph से डेटा पुनर्प्राप्त करता है, तो संभवतः आपने The Graph के साथ इंटरैक्ट किया है। आज, वेब3 इकोसिस्टम में हजारों [popular dapps](https://thegraph.com/explorer) The Graph का उपयोग कर रहे हैं।
 
 ## विशिष्टताएँ
 
-The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+The Graph का मॉडल एक B2B2C मॉडल के समान है, लेकिन यह एक विकेंद्रीकृत नेटवर्क द्वारा संचालित होता है जहां प्रतिभागी एंड यूजर्स को डेटा प्रदान करने के लिए सहयोग करते हैं और इसके बदले में उन्हें GRT इनाम के रूप में मिलता है। GRT The Graph का यूटिलिटी टोकन है। यह नेटवर्क के भीतर डेटा प्रोवाइडर्स और कंज्यूमर्स के बीच इंटरैक्शन को समन्वित और प्रोत्साहित करता है।
 
-The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+The Graph ब्लॉकचेन डेटा को अधिक सुलभ बनाने में महत्वपूर्ण भूमिका निभाता है और इसके आदान-प्रदान के लिए एक मार्केटप्लेस का समर्थन करता है। The Graph के पे-फॉर-व्हाट-यू-नीड मॉडल के बारे में अधिक जानने के लिए, इसके [free and growth plans](/subgraphs/billing/) देखें।
 
 - GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
 
@@ -65,19 +65,19 @@ Once developers have built and tested their subgraph, they can [publish their su
 
 Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
 
-Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+सबग्राफ़ को GraphQL का उपयोग करके क्वेरी किया जाता है()/subgraphs/querying/introduction/, और क्वेरी शुल्क को Subgraph Studio()https://thegraph.com/studio/ में GRT के साथ भुगतान किया जाता है। क्वेरी शुल्क को नेटवर्क प्रतिभागियों में उनके प्रोटोकॉल में योगदान के आधार पर वितरित किया जाता है।
 
 1% of the query fees paid to the network are burned.
 
 ## Indexers (Earn GRT)
 
-Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+Indexers The Graph की रीढ़ हैं। वे स्वतंत्र हार्डवेयर और सॉफ़्टवेयर संचालित करते हैं जो The Graph के विकेन्द्रीकृत नेटवर्क को शक्ति प्रदान करता है। Indexers, सबग्राफ से निर्देशों के आधार पर उपभोक्ताओं को डेटा प्रदान करते हैं।
 
-Indexers can earn GRT rewards in two ways:
+Indexers दो तरीकों से GRT रिवार्ड्स कमा सकते हैं:
 
-1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+1. **क्वेरी शुल्क:** डेवलपर्स या उपयोगकर्ताओं द्वारा Subgraph डेटा क्वेरी के लिए भुगतान किया गया GRT। क्वेरी शुल्क सीधे Indexers को एक्सपोनेंशियल रिबेट फ़ंक्शन के अनुसार वितरित किया जाता है (देखें GIP [यहाँ](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162))।
 
-2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+2. **Indexing रिवार्ड्स**: 3% की वार्षिक जारी राशि Indexers को उनके द्वारा indexed किए गए सबग्राफकी संख्या के आधार पर वितरित की जाती है। ये पुरस्कार Indexers को सबग्राफको index करने के लिए प्रेरित करते हैं, कभी-कभी query fees शुरू होने से पहले भी, ताकि वे Proofs of Indexing (POIs) को एकत्रित और प्रस्तुत कर सकें, यह सत्यापित करने के लिए कि उन्होंने डेटा को सटीक रूप से index किया है।
 
 Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
 

From c1accf0af93dcf04d5e5be43b48098176f8fb3d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 10:18:56 -0500
Subject: [PATCH 3527/3820] New translations grafting-hotfix.mdx (Hindi)

---
 website/pages/hi/subgraphs/cookbook/grafting-hotfix.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/hi/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/hi/subgraphs/cookbook/grafting-hotfix.mdx
index 6758fbeb327e..7097928262f7 100644
--- a/website/pages/hi/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/hi/subgraphs/cookbook/grafting-hotfix.mdx
@@ -17,14 +17,14 @@ This feature enables quick deployment of hotfixes for critical issues, eliminati
    - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
    - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
 
-2. **Data Preservation**
+2. **डेटा प्रिजर्वेशन**
 
    - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
    - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
 
 3. **Efficiency**
    - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
-   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+   - **कृपया सुधारों पर ध्यान दें**: डेवलपर्स को डेटा रिकवरी प्रबंधन करने के बजाय समस्याओं को हल करने पर ध्यान केंद्रित करने की अनुमति देता है।"
 
 ## Best Practices When Using Grafting for Hotfixes
 

From 312bde3d7aa7d09c8628d09bfb8e6f31aecb4090 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:33 -0500
Subject: [PATCH 3528/3820] New translations undelegating.mdx (Romanian)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/ro/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/ro/resources/roles/delegating/undelegating.mdx b/website/pages/ro/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..f363d7449bb5
--- /dev/null
+++ b/website/pages/ro/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Additional Resources
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From eb375839b212de04b40809d5deeab990641d02c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:34 -0500
Subject: [PATCH 3529/3820] New translations delegating.mdx (Romanian)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/ro/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/ro/resources/roles/delegating/delegating.mdx b/website/pages/ro/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..55ad58331559
--- /dev/null
+++ b/website/pages/ro/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegating
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Overview
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The Delegation Tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From a4af9512d56d5abcece71f5ad38cd01dc9fd09b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:35 -0500
Subject: [PATCH 3530/3820] New translations undelegating.mdx (French)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/fr/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/fr/resources/roles/delegating/undelegating.mdx b/website/pages/fr/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..7f3fc5acbc71
--- /dev/null
+++ b/website/pages/fr/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Étape par Étape
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Étape par Étape
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Ressources supplémentaires
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 35386b472c10f1eb163c759e3f0091d9e16b231a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:37 -0500
Subject: [PATCH 3531/3820] New translations delegating.mdx (French)

---
 .../resources/roles/delegating/delegating.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/fr/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/fr/resources/roles/delegating/delegating.mdx b/website/pages/fr/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..1f2cd5cb6399
--- /dev/null
+++ b/website/pages/fr/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,147 @@
+---
+title: Délégation
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Aperçu
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Avantages de la délégation
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## Comment fonctionne la délégation ?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- Les risques de la délégation de jetons dans The Graph Network
+- Comment calculer les rendements escomptés en tant que délégué
+
+## Risques de délégation
+
+Les principaux risques liés à la fonction de délégué dans le protocole sont transmis ci-dessous.
+
+### La taxe de délégation
+
+Les délégués ne peuvent pas être licenciés en cas de mauvais comportement, mais ils sont soumis à une taxe visant à décourager les mauvaises décisions susceptibles de nuire à l'intégrité du réseau.
+
+En tant que Délégateur, il est important de comprendre ce qui suit :
+
+- Vous serez facturé 0,5% chaque fois que vous déléguez. Cela signifie que si vous déléguez 1,000 GRT, vous brûlerez automatiquement 5 GRT.
+
+- Pour être en sécurité, vous devriez calculer votre retour potentiel lorsque vous déléguez à un Indexeur. Par exemple, vous pourriez calculer combien de jours il faudra avant d'avoir récupéré la taxe de 0,5% sur votre délégation.
+
+### La période de retrait de délégation
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Pourquoi ceci est t-il important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Délégation en cours de désengagement](/img/Delegation-Unbonding.png) _Notez les frais de 0,5 % dans l’interface de Délégation, ainsi que la période de désengagement de 28 jours._
+</div>
+
+#### Paramètres de Délégation
+
+Pour comprendre comment choisir un Indexeur fiable, vous devez comprendre les paramètres de Délégation.
+
+- **Indexing Reward Cut** - La portion des récompenses que l'Indexeur conserve pour lui-même.
+  - Si la part de récompense d'un indexeur est fixée à 100%, en tant que délégateur, vous recevrez 0 récompense d'indexation.
+  - Si elle est fixée à 80%, en tant que Délégateur, vous recevrez 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *L’indexeur du haut donne 90 % des récompenses aux Délégateurs. Celui du milieu donne 20 %. Celui du bas donne environ 83 %.*
+</div>
+
+- **Query Fee Cut** - C’est la même chose que l’Indexing Reward Cut, mais cela s’applique aux revenus des frais de requête que l’Indexeur perçoit.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calcul du rendement attendu par les Délégateurs
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Considérant la réduction des frais d'interrogation et la réduction des frais d'indexation
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+La formule est :
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Compte tenu du pool de délégation de l'indexeur
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Les Déléguateurs doivent considérer la proportion du Pool de Délégation qu'ils possèdent.
+
+Toutes les récompenses de délégation sont partagées de manière égale, avec un rééquilibrage du pool basé sur le montant que le Déléguateur a déposé dans le pool.
+
+Cela donne au Déléguateur une part du pool :
+
+![Formule de calcul de chaque part](/img/Share-Forumla.png)
+
+> La formule ci-dessus montre qu'il est possible pour un Indexeur offrant seulement 20% aux Déléguateurs de fournir une meilleure récompense qu'un Indexeur donnant 90%. Il suffit de faire les calculs pour déterminer la meilleure récompense.
+
+## FAQ et bugs pour les délégants
+
+### Bug MetaMask « Transaction en attente »
+
+Parfois, les tentatives de déléguer aux Indexeurs via MetaMask peuvent échouer et entraîner des périodes prolongées de tentatives de transaction "Pending" ou "Queued".
+
+Une solution simple à ce problème consiste à redémarrer le navigateur (par exemple, en utilisant "abort:restart" dans la barre d'adresse), ce qui annulera toutes les tentatives précédentes sans que le gaz ne soit soustrait du portefeuille. Plusieurs utilisateurs ayant rencontré ce problème ont signalé des transactions réussies après avoir redémarré leur navigateur et tenté de déléguer.

From 3b62a7bf0de5994c944b828145a5e21d2f91e965 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:38 -0500
Subject: [PATCH 3532/3820] New translations undelegating.mdx (Spanish)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/es/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/es/resources/roles/delegating/undelegating.mdx b/website/pages/es/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..128da3825fd4
--- /dev/null
+++ b/website/pages/es/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Recursos Adicionales
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 7e2d146198086b8ac20e68e66c195d150e46195e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:39 -0500
Subject: [PATCH 3533/3820] New translations delegating.mdx (Spanish)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/es/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/es/resources/roles/delegating/delegating.mdx b/website/pages/es/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..3c6ff9d5b931
--- /dev/null
+++ b/website/pages/es/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegar
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Descripción
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- Los riesgos de delegar tokens en la red de The Graph
+- Cómo calcular los rendimientos que te esperan siendo Delegador
+
+## Riesgos de la Delegación
+
+A continuación se enumeran los principales riesgos de ser un Delegador en el protocolo.
+
+### The Delegation Tax
+
+Los Delegadores no pueden ser recortados por mal comportamiento, pero existe un impuesto sobre los Delegadores para desincentivar la toma de malas decisiones que puedan perjudicar la integridad de la red.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Siempre ten en cuenta la tarifa por consulta y el recorte de recompensas para el Indexador
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Tener en cuenta el pool de delegación de cada Indexador
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Preguntas Frecuentes del Delegador y Errores
+
+### Error de "Transacción Pendiente" en MetaMask
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From 2340c400594a6f16450ad3a5323ef92e0b64e9cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:40 -0500
Subject: [PATCH 3534/3820] New translations undelegating.mdx (Arabic)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/ar/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/ar/resources/roles/delegating/undelegating.mdx b/website/pages/ar/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..41482fef671d
--- /dev/null
+++ b/website/pages/ar/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## مصادر إضافية
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 6d8c287f8b4f182afc138bd257ab311ff4e310d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:41 -0500
Subject: [PATCH 3535/3820] New translations delegating.mdx (Arabic)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/ar/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/ar/resources/roles/delegating/delegating.mdx b/website/pages/ar/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..81095fcca05d
--- /dev/null
+++ b/website/pages/ar/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegating
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## نظره عامة
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- مخاطر تفويض التوكن في شبكة The Graph
+- كيفية حساب العوائد المتوقعة كمفوض
+
+## Delegation Risks
+
+القائمة أدناه هي المخاطر الرئيسية لكونك مفوضا في البروتوكول.
+
+### The Delegation Tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### النظر في اقتطاع رسوم الاستعلام query fee cut واقتطاع رسوم الفهرسة indexing fee cut
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### النظر في أسهم تفويض المفهرس
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From 5ef1b31d02b8779d792e8ae0cb7c86ca4a889ee4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:42 -0500
Subject: [PATCH 3536/3820] New translations undelegating.mdx (Czech)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/cs/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/cs/resources/roles/delegating/undelegating.mdx b/website/pages/cs/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..d14e35049efe
--- /dev/null
+++ b/website/pages/cs/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Další zdroje
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From cb677402e5f3b036d8a62fbf97d53385f1c08678 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:43 -0500
Subject: [PATCH 3537/3820] New translations delegating.mdx (Czech)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/cs/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/cs/resources/roles/delegating/delegating.mdx b/website/pages/cs/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..a3854aba3e49
--- /dev/null
+++ b/website/pages/cs/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegování
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Přehled
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- Rizika delegování tokenů v síti Graf
+- Jak vypočítat očekávané výnosy jako delegát
+
+## Rizika delegování
+
+Níže jsou uvedena hlavní rizika plynoucí z delegáta v protokolu.
+
+### The Delegation Tax
+
+Delegáti nemohou být za špatné chování kráceni, ale existuje daň pro delegáty, která má odradit od špatného rozhodování, jež by mohlo poškodit integritu sítě.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### S ohledem na snížení poplatků za dotaz a indexaci
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Zohlednění fondu delegování indexátoru
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## FAQ a chyby delegáta
+
+### Chyba MetaMask "Čekající transakce"
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From 76985524cc8c6eb48cd0dcf825a9ab4644fb8540 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:44 -0500
Subject: [PATCH 3538/3820] New translations undelegating.mdx (German)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/de/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/de/resources/roles/delegating/undelegating.mdx b/website/pages/de/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..f4fda7c28412
--- /dev/null
+++ b/website/pages/de/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Schritt für Schritt
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Schritt für Schritt
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Zusätzliche Ressourcen
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 5141c9e26071834eb01c5900c92af499185aad15 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:45 -0500
Subject: [PATCH 3539/3820] New translations delegating.mdx (German)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/de/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/de/resources/roles/delegating/delegating.mdx b/website/pages/de/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..d6dedfac53ca
--- /dev/null
+++ b/website/pages/de/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegieren
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Überblick
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- Die Risiken der Übertragung von Token in The Graph Network
+- Wie man als Delegator die erwarteten Erträge berechnet
+
+## Risiken bei der Delegation
+
+Nachfolgend sind die wichtigsten Risiken aufgeführt, die mit der Tätigkeit eines Delegators im Protokoll verbunden sind.
+
+### The Delegation Tax
+
+Delegatoren können nicht für schlechtes Verhalten bestraft werden, aber es gibt eine Steuer für Delegatoren, um von schlechten Entscheidungen abzuschrecken, die die Integrität des Netzes beeinträchtigen könnten.
+
+Als Delegator ist es wichtig, die folgenden Punkte zu verstehen:
+
+- Bei jeder Delegation werden Ihnen 0,5 % berechnet. Das heißt, wenn Sie 1.000 GRT delegieren, verbrauchen Sie automatisch 5 GRT.
+
+- Um auf Nummer sicher zu gehen, sollten Sie Ihre potenzielle Rendite berechnen, wenn Sie einen Indexer beauftragen. Als Beispiel könnten Sie berechnen, wie viele Tage es dauern wird, bis Sie die 0,5 % Steuer auf Ihre Delegation zurückverdient haben.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Warum ist das wichtig?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Parameter der Delegation
+
+Um zu verstehen, wie man einen vertrauenswürdigen Indexer auswählt, müssen Sie die Delegationsparameter verstehen.
+
+- **Indizierung der Rewardkürzung** - Der Teil der Rewards, den der Indexer für sich selbst behält.
+  - Wenn die Rewardkürzung eines Indexers auf 100% eingestellt ist, erhalten Sie als Delegator 0 Rewards für die Indexierung.
+  - Wenn er auf 80 % eingestellt ist, erhalten Sie als Delegator 20 %.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+![Indizierung der Rewardkürzung](/img/Indexing-Reward-Cut.png) *Der oberste Indexer gibt den Delegatoren 90 % der Rewards. Der
+mittlere gibt den Delegatoren 20 %. Der untere gibt den Delegatoren ~83 %.*
+</div>
+
+- **Kürzung der Abfragegebühren** - Dies ist genau wie die Indizierung der Rewardkürzung, aber es gilt für die Renditen der Abfragegebühren, die der Indexer einnimmt.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Berechnung der erwarteten Rendite der Delegatoren
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Berücksichtigung der Senkung der Abfrage- und Indizierungsgebühren
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+Die Formel lautet:
+
+![Delegationsbild 3](/img/Delegation-Reward-Formula.png)
+
+### Berücksichtigung des Delegationspools des Indexers
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Die Delegatoren sollten sich überlegen, welchen Anteil am Delegationspool sie besitzen.
+
+Alle Rewards der Delegatoren werden gleichmäßig aufgeteilt, wobei sich der Pool nach dem Betrag richtet, den der Delegator in den Pool eingezahlt hat.
+
+Dadurch erhält der Delegator einen Anteil am Pool:
+
+![Formel teilen](/img/Share-Forumla.png)
+
+> Die obige Formel zeigt, dass es möglich ist, dass ein Indexer, der den Delegatoren nur 20 % anbietet, einen besseren Reward erzielt als ein Indexer, der 90 % bietet. Rechnen Sie einfach nach, um die beste Reward zu ermitteln.
+
+## Delegator FAQs und Bugs
+
+### MetaMask-Fehler „Ausstehende Transaktion“
+
+Gelegentlich können Versuche, Indexer über MetaMask zu delegieren, fehlschlagen und zu längeren Zeiträumen mit „Pending“ oder „Queued“ Transaktionsversuchen führen.
+
+Eine einfache Lösung für diesen Fehler ist der Neustart des Browsers (z. B. mit „abort:restart“ in der Adressleiste), wodurch alle vorherigen Versuche abgebrochen werden, ohne dass Gas von der Wallet abgezogen wird. Mehrere Benutzer, die auf dieses Problem gestoßen sind, haben von erfolgreichen Transaktionen berichtet, nachdem sie ihren Browser neu gestartet und versucht haben, zu delegieren.

From 4ee7ef00f81854244f416680f5927ad3f8f1a695 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:46 -0500
Subject: [PATCH 3540/3820] New translations undelegating.mdx (Italian)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/it/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/it/resources/roles/delegating/undelegating.mdx b/website/pages/it/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..f363d7449bb5
--- /dev/null
+++ b/website/pages/it/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Additional Resources
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 5222a8ee77816be1055283e0385974d03038bcb2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:47 -0500
Subject: [PATCH 3541/3820] New translations delegating.mdx (Italian)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/it/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/it/resources/roles/delegating/delegating.mdx b/website/pages/it/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..8210a92c969d
--- /dev/null
+++ b/website/pages/it/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegazione
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Panoramica
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- I rischi della delegazione dei token in The Graph Network
+- Come calcolare i rendimenti previsti come Delegator
+
+## Rischi di delegazione
+
+Di seguito sono elencati i principali rischi essere il Delegator nel protocollo.
+
+### The Delegation Tax
+
+I delegator non possono essere penalizzati per un comportamento scorretto, ma c'è una tassa sui delegator per disincentivare un processo decisionale insufficiente che potrebbero danneggiare l'integrità della rete.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Considerando la riduzione delle tariffe di query e la riduzione delle tariffe di indicizzazione
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considerando il delegation pool del Indexer
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## FAQ e bug dei Delegator
+
+### MetaMask "Transazione in sospeso" Bug
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From b79e3e2c23f767cf281829de3677a300525a2d33 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:48 -0500
Subject: [PATCH 3542/3820] New translations undelegating.mdx (Japanese)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/ja/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/ja/resources/roles/delegating/undelegating.mdx b/website/pages/ja/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..e89841170428
--- /dev/null
+++ b/website/pages/ja/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## その他のリソース
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 51c75d0f60ebff1bf827be2616602f3beba1c2b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:50 -0500
Subject: [PATCH 3543/3820] New translations delegating.mdx (Japanese)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/ja/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/ja/resources/roles/delegating/delegating.mdx b/website/pages/ja/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..8a3782527843
--- /dev/null
+++ b/website/pages/ja/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: 委任
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## 概要
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- グラフネットワークでトークンをデリゲートすることのリスク
+- デリゲーターとしての期待リターンの計算方法
+
+## デリゲーションリスク
+
+以下にリストされているのは、プロトコルで委任者になることの主なリスクです。
+
+### The Delegation Tax
+
+デリゲーターは悪意の行動をしてもスラッシュされないが、デリゲーターにはデポジット税が課せられ、ネットワークの整合性を損なう可能性のある悪い意思決定を抑止します。
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### クエリフィーのカットとインデックスフィーのカットの検討
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### インデクサーのデリゲーションプールを考慮する
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## デリゲーターに関するFAQと不具合
+
+### MetaMask "Pending Transaction "バグ
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From 0c35fa94b9c864782e311dd92166f2c152e30ac1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:51 -0500
Subject: [PATCH 3544/3820] New translations undelegating.mdx (Korean)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/ko/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/ko/resources/roles/delegating/undelegating.mdx b/website/pages/ko/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..f363d7449bb5
--- /dev/null
+++ b/website/pages/ko/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Additional Resources
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From fd098bceed549ed34a3fdb95d2e652d9e016067f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:52 -0500
Subject: [PATCH 3545/3820] New translations delegating.mdx (Korean)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/ko/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/ko/resources/roles/delegating/delegating.mdx b/website/pages/ko/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..55ad58331559
--- /dev/null
+++ b/website/pages/ko/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegating
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Overview
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The Delegation Tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From 3a9699597a9a7bb86fdfbb79808663e8fbd2189f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:52 -0500
Subject: [PATCH 3546/3820] New translations undelegating.mdx (Dutch)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/nl/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/nl/resources/roles/delegating/undelegating.mdx b/website/pages/nl/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..f363d7449bb5
--- /dev/null
+++ b/website/pages/nl/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Additional Resources
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From b95a51835eb31813c72bfe1b0d1ef2671440f214 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:54 -0500
Subject: [PATCH 3547/3820] New translations delegating.mdx (Dutch)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/nl/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/nl/resources/roles/delegating/delegating.mdx b/website/pages/nl/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..557e7565d957
--- /dev/null
+++ b/website/pages/nl/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegeren
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Overview
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- De risico's van het delegeren van tokens in het Graph Netwerk
+- Hoe je verwachte opbrengsten als Delegeerder berekent
+
+## Delegatie Risico's
+
+Hieronder staan de belangrijkste risico's van het zijn van een Delegeerder in het protocol.
+
+### The Delegation Tax
+
+Delegeerders kunnen niet worden gestraft voor slecht gedrag, maar er is een belasting voor Delegeerders om slechte besluitvorming die de integriteit van het netwerk kan schaden te ontmoedigen.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Rekening houden met de query fee aandeel en indexing fee aandeel
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Rekening houden met de delegatie pool van een Indexeerder
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Veelgestelde vragen van Delegeerders en Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From d1122fa8769e0fc4c86c17d1a105999620250a2d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:55 -0500
Subject: [PATCH 3548/3820] New translations undelegating.mdx (Polish)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/pl/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/pl/resources/roles/delegating/undelegating.mdx b/website/pages/pl/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..f363d7449bb5
--- /dev/null
+++ b/website/pages/pl/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Additional Resources
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From b8eb70c7d8fb30e9eca7fb2c51de80cb04aa341d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:56 -0500
Subject: [PATCH 3549/3820] New translations delegating.mdx (Polish)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/pl/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/pl/resources/roles/delegating/delegating.mdx b/website/pages/pl/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..55ad58331559
--- /dev/null
+++ b/website/pages/pl/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegating
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Overview
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The Delegation Tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From 1179b27925b8ce702b00c414f9b91e6114efb183 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:57 -0500
Subject: [PATCH 3550/3820] New translations undelegating.mdx (Portuguese)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/pt/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/pt/resources/roles/delegating/undelegating.mdx b/website/pages/pt/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..baba45591a95
--- /dev/null
+++ b/website/pages/pt/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Passo a Passo
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Passo a Passo
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Outros Recursos
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 9104c3ae9323d44b43a626d76c608e1d1979bf21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:58 -0500
Subject: [PATCH 3551/3820] New translations delegating.mdx (Portuguese)

---
 .../resources/roles/delegating/delegating.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/pt/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/pt/resources/roles/delegating/delegating.mdx b/website/pages/pt/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..7e5c9b26b6bc
--- /dev/null
+++ b/website/pages/pt/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,147 @@
+---
+title: Delegação
+---
+
+Para começar a delegar, veja [esta página](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Visão geral
+
+Os Delegantes ganham GRT com a delegação de GRT a Indexadores, o que ajuda com a segurança e estabilidade da rede.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## As Vantagens de Delegar
+
+- O apoio a Indexadores aumenta a segurança e escalabilidade da rede.
+- Rende uma porção das recompensas geradas pelos Indexadores.
+
+## Como Funciona a Delegação?
+
+Os Delegantes ganham recompensas em GRT do(s) Indexador(es) a quem escolhem delegar.
+
+A habilidade de um Indexador em processar queries e ganhar recompensas depende de três fatores importantes:
+
+1. O Auto-Stake do Indexador (GRT investido pelo Indexador).
+2. O total de GRT delegado a ele por Delegantes.
+3. O preço por queries determinado pelo Indexador.
+
+Quanto mais GRT for investido e delegado a um Indexador, mais queries ele pode servir, o que leva potencialmente a mais recompensas tanto para o Delegante quanto o Indexador.
+
+### O Que É Capacidade de Delegação?
+
+É a quantia máxima de GRT que um Indexador pode aceitar dos Delegantes, baseado no Auto-Stake do Indexador.
+
+A The Graph Network inclui uma proporção de delegação de 16; ou seja, um indexador pode aceitar até 16 vezes o seu Auto-Stake em GRT delegado.
+
+Por exemplo, se um Indexador tem um Auto-Stake de 1 mihão de GRT, a sua Capacidade de Delegação é de 16 milhões.
+
+### Por Que a Capacidade de Delegação Importa?
+
+Se um Indexador passar da sua Capacidade de Delegação, as recompensas para todos os Delegantes são diluídas, porque o excesso do GRT delegado não pode ser usado efetivamente dentro do protocolo.
+
+Ou seja, é importante que os Delegantes avaliem a Capacidade de Delegação atual dos Indexadores antes de selecionar um.
+
+Para aumentar a sua Capacidade de Delegação, os Indexadores podem aumentar o seu Auto-Stake, assim levantando o limite de tokens delegados.
+
+## Delegação no The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Este guia não cobre passos como a configuração do MetaMask. A comunidade do Ethereum fornece um recurso compreensivo sobre carteiras [neste link](https://ethereum.org/en/wallets/).
+
+Há duas secções neste guia:
+
+- Os riscos de delegar tokens na Graph Network
+- Como calcular retornos esperados como um Delegante
+
+## Riscos de Delegação
+
+Veja abaixo os riscos principais de ser um Delegante no protocolo.
+
+### Taxa de Delegação
+
+Os Delegantes não podem ser punidos por mau comportamento, mas há uma taxa sobre Delegantes, para desencorajar más decisões que possam ferir a integridade da rede.
+
+Como Delegante, é importante entender que:
+
+- Haverá uma cobrança de 0,5% sempre que delegar. Ou seja, ao delegar 1000 GRT, 5 GRT serão queimados automaticamente.
+
+- Por segurança, calcule o seu retorno potencial quando delegar para um Indexador. Por exemplo, pode-se calcular o número de dias até que tenha recuperado a taxa de 0,5% da sua delegação.
+
+### Período de Retirada de Delegação
+
+Quando um Delegante escolhe retirar a sua Delegação, os seus tokens estão sujeitos a um período de retirada de 28 dias.
+
+Ou seja, ele não pode transferir os seus tokens ou ganhar recompensas por 28 dias.
+
+Após o período de retirada, o GRT será devolvido à sua carteira de criptomoedas.
+
+### Qual a Importância Disto?
+
+Se escolher um Indexador que não é de confiança, ou não fez um bom trabalho, talvez queira cancelar a sua delegação, o que implica em sacrificar muitas oportunidades de recompensa. Isto pode ser tão lamentável quanto queimar GRT.
+
+Por isso, recomendamos que tenha cuidado ao escolher um Indexador.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Unbonding de delegação](/img/Delegation-Unbonding.png) _Perceba a taxa de 0,5% na Interface de Delegação, assim como o período de unbonding de 28 dias._
+</div>
+
+#### Parâmetros de Delegação
+
+Para entender como escolher um Indexador confiável, entenda os Parâmetros de Delegação.
+
+- **Porção da Recompensa de Indexação** — A porção da recompensa que vai para o Indexador.
+  - Se a porção for configurada para 100%, como Delegante, você receberá 0 recompensas de indexação.
+  - Se for configurada para 80%, o Delegante receberá 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Porção da Recompensa de Indexação](/img/Indexing-Reward-Cut.png) *O Indexador no topo está a dar 90% das recompensas aos Delegantes. O do meio dá 20%. O mais baixo dá ~83% aos Delegantes.*
+</div>
+
+- **Porção da Taxa de Query** — Parecido com a Porção da Recompensa de Indexação, mas se aplica aos retornos nas taxas de query coletadas pelo Indexador.
+
+- Recomendamos altamente que explore o [Discord do The Graph](https://discord.gg/graphprotocol) para determinar quais Indexadores tem as melhores reputações sociais e técnicas, e quais recompensam os Delegantes consistentemente.
+
+- Muitos Indexadores estão ativos no Discord, e estão dispostos a responder as suas perguntas.
+
+## Como calcular o retorno esperado dos Delegantes
+
+> Calcule o retorno sobre a sua delegação [aqui](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+Um Delegante deve considerar os seguintes fatores para determinar um retorno:
+
+A habilidade de um Indexador de usar o GRT disponível a ele impacta as suas recompensas.
+
+Se um Indexador não alocar todo o GRT ao seu dispor, ele pode não maximizar os ganhos potenciais tanto para si mesmo quanto para os seus Delegantes.
+
+Os Indexadores podem fechar uma alocação e resgatar recompensas a qualquer momento entre o período de 1 a 28 dias. Porém, se as recompensas não forem resgatadas, as recompensas totais podem parecer menores, mesmo se uma percentagem não tiver sido resgatada ainda.
+
+### Como considerar as porções das taxas de query e de indexação
+
+Escolha um Indexador transparente sobre as suas Taxas de Query e Porções de Taxa de Indexação.
+
+A fórmula é:
+
+![Imagem de Delegação 3](/img/Delegation-Reward-Formula.png)
+
+### Como considerar o pool de delegação do Indexador
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Os Delegantes devem considerar a proporção do Fundo (Pool) de Delegação que possuem.
+
+Todas as recompensas de delegação são divididas igualmente, com um reequilíbrio do pool baseado na quantia depositada no pool pelo Delegante.
+
+Isto dá ao Delegante uma porção do pool:
+
+![Fórmula de ações](/img/Share-Forumla.png)
+
+> A fórmula acima prova que um Indexador que oferece apenas 20% aos Delegantes fornece uma recompensa melhor que um Indexador que dá 90%. Basta fazer as contas para determinar a melhor recompensa.
+
+## Erros e Perguntas Frequentes sobre Delegação
+
+### Erro de "Transação Pendente" no MetaMask
+
+Às vezes, tentativas de delegar a Indexadores via MetaMask podem falhar e deixar tentativas de transação "Pendentes" ou "Em Fila" por períodos prolongados.
+
+Uma solução mais simples para este bug é a reinicialização do navegador (por ex., "abort:restart" na barra de endereço), o que cancelará todas as tentativas anteriores sem subtrair gas da carteira. Vários utilizadores que encontraram este problema relataram sucesso nas transações após reiniciar o seu navegador e tentar delegar.

From 7ff6444a719bcf2104d50e3be6cc14f3ad80c7c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:38:59 -0500
Subject: [PATCH 3552/3820] New translations undelegating.mdx (Russian)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/ru/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/ru/resources/roles/delegating/undelegating.mdx b/website/pages/ru/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..c9fd2c7b2da4
--- /dev/null
+++ b/website/pages/ru/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Пошаговое руководство
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Пошаговое руководство
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Дополнительные ресурсы
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 37f3385edecb86a0d197548dba99338a16fe82ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:00 -0500
Subject: [PATCH 3553/3820] New translations delegating.mdx (Russian)

---
 .../resources/roles/delegating/delegating.mdx | 147 ++++++++++++++++++
 1 file changed, 147 insertions(+)
 create mode 100644 website/pages/ru/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/ru/resources/roles/delegating/delegating.mdx b/website/pages/ru/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..9f23ac4c669e
--- /dev/null
+++ b/website/pages/ru/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,147 @@
+---
+title: Делегирование
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Обзор
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- Риски связанные с делегацией в сети The Graph
+- Как расчитать примерный доход
+
+## Риски делегации
+
+Ниже указаны основные риски Делегатора.
+
+### The Delegation Tax
+
+Делегаторы не могут быть наказаны за некорректное поведение, но они уплачивают комиссию на делегацию, который должен стимулировать обдуманный выбор Индексатора для делегации.
+
+Делегатору важно понимать следующее:
+
+- За каждое делегирование с Вас будет взиматься плата в размере 0,5%. Это значит, что если Вы делегируете 1000 GRT, Вы автоматически сожжете 5 GRT.
+
+- В целях безопасности Вам следует рассчитать потенциальную прибыль при делегировании Индексатору. Например, Вы можете подсчитать, сколько дней пройдет, прежде чем Вы вернете налог в размере 0,5% за своё делегирование.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Почему это важно?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Период разблокировки делегирования](/img/Delegation-Unbonding.png) _Обратите внимание на комиссию в 0,5% в интерфейсе делегирования, а также на 28-дневный период разблокировки._
+</div>
+
+#### Параметры делегирования
+
+Чтобы понять, как выбрать надежного Индексатора, Вам необходимо разобраться в параметрах делегирования.
+
+- **Часть вознаграждения за индексацию** — доля вознаграждений, которую индексатор оставляет себе.
+  - Если доля вознаграждения индексатора установлена на 100%, как делегатор, как Делегатор, Вы получите 0 вознаграждений за индексацию.
+  - Если установлено значение 80%, то как Делегатор Вы получите 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Часть вознаграждения за индексирование](/img/Indexing-Reward-Cut.png) *Верхний индексатор отдает делегаторам 90% вознаграждений. Средний — 20%. Нижний — около 83%.*
+</div>
+
+- **Часть комиссии за запросы** — это то же самое, что и часть вознаграждения за индексирование, но она применяется к доходам от комиссий за запросы, которые индексатор собирает.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Расчет ожидаемой доходности Делегаторов
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Учёт части комиссии за запросы и части комиссии за индексирование
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+Формула следующая:
+
+![Изображение делегирования 3](/img/Delegation-Reward-Formula.png)
+
+### Осмотр пула делегирования индексатора
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Делегаторам следует учитывать долю пула делегаций, которым они владеют.
+
+Все вознаграждения за делегирование распределяются поровну, при этом баланс пула перераспределяется в зависимости от суммы, внесенной Делегатором в пул.
+
+Это дает Делегатору долю в пуле:
+
+![Формула доли](/img/Share-Forumla.png)
+
+> Приведенная выше формула показывает, что Индексатор, предлагающий Делегаторам только 20%, может обеспечить лучшее вознаграждение, чем Индексатор, предоставляющий 90%. Просто посчитайте, чтобы определить лучшие условия вознаграждения.
+
+## Частые вопросы и баги
+
+### Ошибка Метамаска "Pending Transaction"
+
+Иногда попытки делегировать Индексаторам через MetaMask могут завершаться неудачей, что приводит к длительным периодам транзакций со статусом «В ожидании» или «В очереди».
+
+Простым решением этой ошибки является перезапуск браузера (например, с помощью "abort:restart" в адресной строке), что отменит все предыдущие попытки без взимания газа из кошелька. Некоторые пользователи, столкнувшиеся с этой проблемой, сообщили об успешных транзакциях после перезапуска браузера и попытки делегирования.

From 59bbfc148cc2a381f765cd4bec67856660019219 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:01 -0500
Subject: [PATCH 3554/3820] New translations undelegating.mdx (Swedish)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/sv/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/sv/resources/roles/delegating/undelegating.mdx b/website/pages/sv/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..ec3a561ec4aa
--- /dev/null
+++ b/website/pages/sv/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Ytterligare resurser
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 772c04c1ec33757cf5ffcd0b709564f11c82daab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:02 -0500
Subject: [PATCH 3555/3820] New translations delegating.mdx (Swedish)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/sv/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/sv/resources/roles/delegating/delegating.mdx b/website/pages/sv/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..b9ae4c858aa9
--- /dev/null
+++ b/website/pages/sv/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegera
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Översikt
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- Riskerna med att delegera tokens i The Graph-nätverket
+- Hur man beräknar förväntad avkastning som Delegater
+
+## Delegationsrisker
+
+Här nedan listas huvudriskerna med att vara en Delegater i protokollet.
+
+### The Delegation Tax
+
+Delegater kan inte "slashas" för dåligt beteende, men det finns en avgift för Delegater för att avskräcka dåligt beslutsfattande som kan skada nätverkets integritet.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Att överväga frågebetalningsavgiften och indexeringsavgiften
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Att överväga Indexer's delegeringspool
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Delegaters FAQ och buggar
+
+### Metamask "Väntande transaktion" bugg
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From 0e50e1516a0f06b61c71d4db4220714381b01fce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:03 -0500
Subject: [PATCH 3556/3820] New translations undelegating.mdx (Turkish)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/tr/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/tr/resources/roles/delegating/undelegating.mdx b/website/pages/tr/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..14fde5daae0a
--- /dev/null
+++ b/website/pages/tr/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Adım Adım
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Adım Adım
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Ek Kaynaklar
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 4f146d915f604e6a6b5f78a6a9b98171dcb16e11 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:04 -0500
Subject: [PATCH 3557/3820] New translations delegating.mdx (Turkish)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/tr/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/tr/resources/roles/delegating/delegating.mdx b/website/pages/tr/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..7b2b6bca2f17
--- /dev/null
+++ b/website/pages/tr/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegating
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Genel Bakış
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The Delegation Tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From a790b0012a7b3219009ee23ce8e404c87f3b4c19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:05 -0500
Subject: [PATCH 3558/3820] New translations undelegating.mdx (Ukrainian)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/uk/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/uk/resources/roles/delegating/undelegating.mdx b/website/pages/uk/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..b357c3a2da3d
--- /dev/null
+++ b/website/pages/uk/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Додаткові матеріали
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 37a769cd1a7a129e33a9017149f9ee26d651a5fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:08 -0500
Subject: [PATCH 3559/3820] New translations delegating.mdx (Ukrainian)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/uk/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/uk/resources/roles/delegating/delegating.mdx b/website/pages/uk/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..e7c13c83ff66
--- /dev/null
+++ b/website/pages/uk/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Делегування
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Overview
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- Ризики делегування токенів в мережі Graph
+- Як розрахувати можливі прибутки як делегат
+
+## Ризики, пов'язані з делегуванням
+
+Нижче перераховані основні ризики, пов'язані з участю делегата в протоколі.
+
+### The Delegation Tax
+
+Делегати не можуть бути виключені за погану поведінку, але існує певний штраф для них, щоб позбавити стимулу щодо прийняття поганих рішень, які можуть зашкодити цілісності мережі.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Розглянемо питання про отримання частини винагороди за індексацію та за запити
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Розглянемо пул делегацій індексатора
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Поширені запитання та баги
+
+### Баг в гаманці MetaMask "Pending Transaction"
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From e18b2706ec6c27b312df25a74a037da59a57ac42 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:09 -0500
Subject: [PATCH 3560/3820] New translations undelegating.mdx (Chinese
 Simplified)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/zh/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/zh/resources/roles/delegating/undelegating.mdx b/website/pages/zh/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..283a74782381
--- /dev/null
+++ b/website/pages/zh/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## 其他资源
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 85eb63dcb0fda51b3610a43fff9efb5157e5a7f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:10 -0500
Subject: [PATCH 3561/3820] New translations delegating.mdx (Chinese
 Simplified)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/zh/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/zh/resources/roles/delegating/delegating.mdx b/website/pages/zh/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..174cd5251221
--- /dev/null
+++ b/website/pages/zh/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: 委托
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## 概述
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- 在 Graph 网络中委托代币的风险
+- 如何计算作为委托人的预期回报
+
+## 委托风险
+
+下面列出了作为协议中的委托人的主要风险。
+
+### The Delegation Tax
+
+委托人不能因为不良行为而被取消，但对委托有税，以抑制可能损害网络完整性的不良决策。
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### 考虑到查询费用的分成和索引费用的分成
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### 考虑索引人委托池
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## 委托人常见问题和错误
+
+### MetaMask“待定交易”错误
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From 01ba44de401363e6dc9a4e27a175891cbc5def19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:11 -0500
Subject: [PATCH 3562/3820] New translations undelegating.mdx (Urdu (Pakistan))

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/ur/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/ur/resources/roles/delegating/undelegating.mdx b/website/pages/ur/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..1cf6d59f7b0f
--- /dev/null
+++ b/website/pages/ur/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## اضافی وسائل
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From a1ed773884889855e7adf27684bea4d0d89c2090 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:12 -0500
Subject: [PATCH 3563/3820] New translations delegating.mdx (Urdu (Pakistan))

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/ur/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/ur/resources/roles/delegating/delegating.mdx b/website/pages/ur/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..b04567a39c2b
--- /dev/null
+++ b/website/pages/ur/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: ڈیلیگیٹنگ
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## جائزہ
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- گراف نیٹ ورک میں ٹوکن ڈیلیگ کرنے کے خطرات
+- بطور ڈیلیگیٹر متوقع واپسی کا حساب کیسے لگائیں
+
+## ڈیلیگیشن کے خطرات
+
+پروٹوکول میں ڈیلیگیٹر ہونےکے اہم خطرات مندرجہ ذیل ہیں.
+
+### The Delegation Tax
+
+برے رویۓ پر ڈیلیگیٹرز کو نہیں چھوڑا جا سکتا، لیکن ناقص فیصلہ سازی کی حوصلہ شکنی کے لیے ڈیلیگیٹرز پر ٹیکس ہے جو نیٹ ورک کی سالمیت کو نقصان پہنچا سکتا ہے.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### کیوری فیس میں کمی اور انڈیکسنگ کی فیس میں کمی پر غور کرنا
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### انڈیکسر کے ڈیلیگیشن پول پر غور کرنا
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## ڈیلیگیٹر کے اکثر پوچھے گئے سوالات اور بگز
+
+### میٹا ماسک "پینڈنگ ٹرانزیکشن" بگ
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From c3f14e9d9bd51da29fa79723b8ef6838fca018d6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:13 -0500
Subject: [PATCH 3564/3820] New translations undelegating.mdx (Vietnamese)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/vi/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/vi/resources/roles/delegating/undelegating.mdx b/website/pages/vi/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..f363d7449bb5
--- /dev/null
+++ b/website/pages/vi/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Additional Resources
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From 10ea6680dc3509ef43005cb56ac912fa9144c6da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:15 -0500
Subject: [PATCH 3565/3820] New translations delegating.mdx (Vietnamese)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/vi/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/vi/resources/roles/delegating/delegating.mdx b/website/pages/vi/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..0746ae38171f
--- /dev/null
+++ b/website/pages/vi/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegating
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Tổng quan
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- Rủi ro của việc ủy quyền token trong Mạng The Graph
+- Cách tính lợi nhuận kỳ vọng với tư cách là delegator
+
+## Rủi ro Ủy quyền
+
+Lưu ý quan trọng là mỗi lần bạn ủy quyền, bạn sẽ bị tính phí 0.5%. Nghĩa là nếu bạn đang ủy quyền 1000 GRT, bạn sẽ tự động đốt 5 GRT.
+
+### The Delegation Tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Xem xét Phần cắt Phí Truy vấn và Phần cắt Phí indexing
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Xem xét Delegation pool của Indexer
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From 535d5163d590579c7f3f8007e37f6c1742e335a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:16 -0500
Subject: [PATCH 3566/3820] New translations undelegating.mdx (Marathi)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/mr/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/mr/resources/roles/delegating/undelegating.mdx b/website/pages/mr/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..82219c3da93c
--- /dev/null
+++ b/website/pages/mr/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## अतिरिक्त संसाधने
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From acbb98255aa70d34d5c2c6172076427310a5b836 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:17 -0500
Subject: [PATCH 3567/3820] New translations delegating.mdx (Marathi)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/mr/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/mr/resources/roles/delegating/delegating.mdx b/website/pages/mr/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..f53ed8a6db03
--- /dev/null
+++ b/website/pages/mr/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegating
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## सविश्लेषण
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The Delegation Tax
+
+वाईट वर्तनासाठी प्रतिनिधींना कमी केले जाऊ शकत नाही, परंतु नेटवर्कच्या अखंडतेला हानी पोहोचवणाऱ्या खराब निर्णयक्षमतेला प्रोत्साहन देण्यासाठी प्रतिनिधींवर कर लावला जातो.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From 85b59404529a34364201bac7f66a0aef1b92b62f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:18 -0500
Subject: [PATCH 3568/3820] New translations undelegating.mdx (Hindi)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/hi/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/hi/resources/roles/delegating/undelegating.mdx b/website/pages/hi/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..6b6177b83faf
--- /dev/null
+++ b/website/pages/hi/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### चरण-दर-चरण
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### चरण-दर-चरण
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Additional Resources
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From b759680338bdb3bcc9c7a481d74fef1247714f21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:19 -0500
Subject: [PATCH 3569/3820] New translations delegating.mdx (Hindi)

---
 .../resources/roles/delegating/delegating.mdx | 150 ++++++++++++++++++
 1 file changed, 150 insertions(+)
 create mode 100644 website/pages/hi/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/hi/resources/roles/delegating/delegating.mdx b/website/pages/hi/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..f7b30c6fff84
--- /dev/null
+++ b/website/pages/hi/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,150 @@
+---
+title: Delegating
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## अवलोकन
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- ग्राफ़ नेटवर्क में टोकन सौंपने का जोखिम
+- प्रतिनिधि के रूप में अपेक्षित रिटर्न की गणना कैसे करें
+
+## Delegation Risks
+
+प्रोटोकॉल में प्रतिनिधि होने के मुख्य जोखिमों की सूची नीचे दी गई है।
+
+### The Delegation Tax
+
+प्रतिनिधियों को खराब व्यवहार के लिए कम नहीं किया जा सकता है, लेकिन खराब निर्णय लेने को हतोत्साहित करने के लिए प्रतिनिधियों पर एक कर है जो नेटवर्क की अखंडता को नुकसान पहुंचा सकता है।
+
+एक Delegator के रूप में, निम्नलिखित बातों को समझना महत्वपूर्ण है:
+
+- आपसे हर बार डेलीगेट करने पर 0.5% चार्ज किया जाएगा। इसका मतलब है कि यदि आप 1,000 GRT डेलीगेट करते हैं, तो आप स्वचालित रूप से 5 GRT बर्न कर देंगे।
+
+- सुरक्षित रहने के लिए, आपको Indexer को डेलीगेट करते समय अपने संभावित रिटर्न की गणना करनी चाहिए। उदाहरण के लिए, आप यह गणना कर सकते हैं कि आपके डेलीगेशन पर 0.5% कर वापस कमाने में कितने दिन लगेंगे।
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### यह क्यों महत्वपूर्ण है?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}> 
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Delegation UI में 0.5% शुल्क और 28 दिनों की 
+  unbonding अवधि को ध्यान दें।_ 
+</div>
+
+#### डेलीगेशन पैरामीटर
+
+एक विश्वसनीय Indexer को चुनने के लिए आपको डेलीगेशन पैरामीटर्स को समझना आवश्यक है।
+
+- **Indexing Reward Cut** - वह हिस्सा जो Indexer अपने लिए इनाम के रूप में रखेगा।
+  - यदि किसी Indexer का पुरस्कार कट 100% पर सेट है, तो एक Delegator के रूप में, आपको 0 इंडेक्सिंग पुरस्कार मिलेंगे।
+  - यदि इसे 80% पर सेट किया गया है, तो एक Delegator के रूप में, आप 20% प्राप्त करेंगे।
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}> 
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *सबसे ऊपर वाला Indexer Delegators को 90% इनाम दे रहा है। 
+  बीच वाला Delegators को 20% दे रहा है। सबसे नीचे वाला Delegators को लगभग 83% दे रहा है।* 
+</div>
+
+- \*\*पूछताछ शुल्क कटौती - यह बिल्कुल Indexing Reward Cut की तरह है, लेकिन यह उन पूछताछ शुल्क पर लागू होता है जो Indexer एकत्र करता है।
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## यहाँ पर 'Delegators' की अपेक्षित लाभ की गणना की जा रही है।
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### प्रश्न शुल्क में कटौती और अनुक्रमण शुल्क में कटौती को ध्यान में रखते हुए
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+सूत्र है:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### अनुक्रमणिका के प्रतिनिधिमंडल पूल को ध्यान में रखते हुए
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators को प्रतिनिधि पूल में उनके स्वामित्व के अनुपात पर विचार करना चाहिए।
+
+सभी 'प्रतिनिधि पुरस्कार' समान रूप से साझा किए जाते हैं, और पूल में पुनर्संतुलन उस राशि के आधार पर होता है जो Delegator ने पूल में जमा की होती है।
+
+यह Delegator को पूल का हिस्सा देता है:
+
+![Share formula](/img/Share-Forumla.png)
+
+> उपरोक्त सूत्र यह दर्शाता है कि एक Indexer जो केवल 20% को Delegators को प्रदान कर रहा है, एक Indexer की तुलना में बेहतर पुरस्कार प्रदान कर सकता है जो 90% दे रहा है। बस गणना करें ताकि सर्वश्रेष्ठ पुरस्कार निर्धारित हो सके।
+
+## प्रतिनिधि अक्सर पूछे जाने वाले प्रश्न और बग
+
+### मेटामास्क "लंबित लेन-देन" बग
+
+MetaMask के माध्यम से Indexers को प्रतिनिधित्व देने के प्रयास कभी-कभी विफल हो सकते हैं और इसके परिणामस्वरूप "Pending" या "Queued" लेनदेन के प्रयासों के लिए लंबे समय तक रुकावट हो सकती है।
+
+इस बग का एक सरल समाधान ब्राउज़र को पुनः प्रारंभ करना है (उदाहरण के लिए, पता बार में "abort
+" का उपयोग करना), जो सभी पिछले प्रयासों को रद्द कर देगा बिना गैस को वॉलेट से घटाए। कई उपयोगकर्ताओं ने जिन्होंने इस समस्या का सामना किया है, उन्होंने अपने ब्राउज़र को पुनः प्रारंभ करने और 'delegation' करने का प्रयास करने के बाद सफल लेनदेन की रिपोर्ट की है।

From c6a05c4dc8bc608fbd985121b5e119b4b4b75b14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:20 -0500
Subject: [PATCH 3570/3820] New translations undelegating.mdx (Swahili)

---
 .../roles/delegating/undelegating.mdx         | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100644 website/pages/sw/resources/roles/delegating/undelegating.mdx

diff --git a/website/pages/sw/resources/roles/delegating/undelegating.mdx b/website/pages/sw/resources/roles/delegating/undelegating.mdx
new file mode 100644
index 000000000000..f363d7449bb5
--- /dev/null
+++ b/website/pages/sw/resources/roles/delegating/undelegating.mdx
@@ -0,0 +1,69 @@
+---
+title: Undelegating
+---
+
+Learn how to withdraw your delegated tokens through [Graph Explorer](https://thegraph.com/explorer) or [Arbiscan](https://arbiscan.io/).
+
+> To avoid this in the future, it's recommended that you select an Indexer wisely. To learn how to select and Indexer, check out the Delegate section in Graph Explorer.
+
+## How to Withdraw Using Graph Explorer
+
+### Step-by-Step
+
+1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
+
+2. Click on your profile. You can find it on the top right corner of the page.
+   - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
+
+3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
+
+4. Click on the Indexer from which you wish to withdraw your tokens.
+   - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
+
+5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
+
+   ![Undelegate button](/img/undelegate-button.png)
+
+6. After approximately [28 epochs](https://thegraph.com/explorer/network/epochs?chain=arbitrum-one) (28 days), return to the Delegate section and locate the specific Indexer you undelegated from.
+
+7. Once you find the Indexer, click on the three dots next to them and proceed to withdraw all your tokens.
+
+## How to Withdraw Using Arbiscan
+
+> This process is primarily useful if the UI in Graph Explorer experiences issues.
+
+### Step-by-Step
+
+1. Find your delegation transaction on Arbiscan.
+   - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
+
+2. Navigate to "Transaction Action" where you can find the staking extension contract:
+   - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
+
+3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
+
+4. Scroll to the bottom and copy the Contract ABI. There should be a small button next to it that allows you to copy everything.
+
+5. Click on your profile button in the top right corner of the page. If you haven't created an account yet, please do so.
+
+6. Once you're in your profile, click on "Custom ABI”.
+
+7. Paste the custom ABI you copied from the staking extension contract, and add the custom ABI for the address: 0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03 (**sample address**)
+
+8. Go back to the [staking extension contract](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract). Now, call the `unstake` function in the [Write as Proxy tab](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03#writeProxyContract), which has been added thanks to the custom ABI, with the number of tokens that you delegated.
+
+9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
+
+   ![Both of the addresses needed](/img/get-delegate.png)
+
+   - This will return three numbers. The first number is the amount you can unstake.
+
+10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.
+
+11. You can see how much you will have available to withdraw by calling the `getWithdrawableDelegatedTokens` on Read Custom and passing it your delegation tuple. See screenshot below:
+
+    ![Call \`getWithdrawableDelegatedTokens\` to see amount of tokens that can be withdrawn](/img/withdraw-available.png)
+
+## Additional Resources
+
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.

From afb1c16f423d797668a771a82dbf68ff452ee792 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 20:39:21 -0500
Subject: [PATCH 3571/3820] New translations delegating.mdx (Swahili)

---
 .../resources/roles/delegating/delegating.mdx | 149 ++++++++++++++++++
 1 file changed, 149 insertions(+)
 create mode 100644 website/pages/sw/resources/roles/delegating/delegating.mdx

diff --git a/website/pages/sw/resources/roles/delegating/delegating.mdx b/website/pages/sw/resources/roles/delegating/delegating.mdx
new file mode 100644
index 000000000000..55ad58331559
--- /dev/null
+++ b/website/pages/sw/resources/roles/delegating/delegating.mdx
@@ -0,0 +1,149 @@
+---
+title: Delegating
+---
+
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+## Overview
+
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+
+<VideoEmbed youtube="VACg8bitnVc" />
+
+## Benefits of Delegating
+
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
+
+## How Does Delegation Work?
+
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+
+An Indexer's ability to process queries and earn rewards depends on three key factors:
+
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
+
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+
+### What is Delegation Capacity?
+
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+
+### Why Does Delegation Capacity Matter?
+
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+
+## Delegation on The Graph
+
+<VideoEmbed youtube="HVyIrMcNu7I" />
+
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+
+There are two sections in this guide:
+
+- The risks of delegating tokens in The Graph Network
+- How to calculate expected returns as a Delegator
+
+## Delegation Risks
+
+Listed below are the main risks of being a Delegator in the protocol.
+
+### The Delegation Tax
+
+Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+
+As a Delegator, it's important to understand the following:
+
+- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+
+- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+
+### The Undelegation Period
+
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+
+This means they cannot transfer their tokens or earn any rewards for 28 days.
+
+After the undelegation period, GRT will return to your crypto wallet.
+
+### Why is this important?
+
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+
+As a result, it’s recommended that you choose an Indexer wisely.
+
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>
+  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
+  unbonding period._
+</div>
+
+#### Delegation Parameters
+
+In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+
+- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
+  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
+  - If it is set to 80%, as a Delegator, you will receive 20%.
+
+<div sx={{ mx: 'auto', maxWidth: '700px' }}>
+  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
+  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+</div>
+
+- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+
+- Many Indexers are active in Discord and will be happy to answer your questions.
+
+## Calculating Delegators Expected Return
+
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+
+A Delegator must consider a variety of factors to determine a return:
+
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+
+### Considering the query fee cut and indexing fee cut
+
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+
+The formula is:
+
+![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+
+### Considering the Indexer's delegation pool
+
+<VideoEmbed youtube="G0HyUZ0m_Q8" />
+
+Delegators should consider the proportion of the Delegation Pool they own.
+
+All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+
+This gives the Delegator a share of the pool:
+
+![Share formula](/img/Share-Forumla.png)
+
+> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+
+## Delegator FAQs and Bugs
+
+### MetaMask "Pending Transaction" Bug
+
+At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+
+A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.

From 942085a4b9bd154146cbdf2a6bf9377fc1b58554 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 5 Feb 2025 23:21:12 -0500
Subject: [PATCH 3572/3820] New translations sinks.mdx (Chinese Simplified)

---
 .../zh/substreams/developing/sinks/sinks.mdx  | 34 +++++++++----------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/website/pages/zh/substreams/developing/sinks/sinks.mdx b/website/pages/zh/substreams/developing/sinks/sinks.mdx
index 6cb08aca4c17..d5342fca741e 100644
--- a/website/pages/zh/substreams/developing/sinks/sinks.mdx
+++ b/website/pages/zh/substreams/developing/sinks/sinks.mdx
@@ -26,26 +26,26 @@ Sinks are integrations that allow you to send the extracted data to different de
 
 ### Official
 
-| Name       | 支持 | Maintainer    | Source Code                                                                               |
-| ---------- | -- | ------------- | ----------------------------------------------------------------------------------------- |
-| SQL        | O  | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
-| Go SDK     | O  | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
-| Rust SDK   | O  | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
-| JS SDK     | O  | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
-| KV Store   | O  | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
-| Prometheus | O  | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
-| Webhook    | O  | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
-| CSV        | O  | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
-| PubSub     | O  | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
+| Name       | Support | Maintainer    | Source Code                                                                               |
+| ---------- | ------- | ------------- | ----------------------------------------------------------------------------------------- |
+| SQL        | O       | StreamingFast | [substreams-sink-sql](https://github.com/streamingfast/substreams-sink-sql)               |
+| Go SDK     | O       | StreamingFast | [substreams-sink](https://github.com/streamingfast/substreams-sink)                       |
+| Rust SDK   | O       | StreamingFast | [substreams-sink-rust](https://github.com/streamingfast/substreams-sink-rust)             |
+| JS SDK     | O       | StreamingFast | [substreams-js](https://github.com/substreams-js/substreams-js)                           |
+| KV Store   | O       | StreamingFast | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | O       | Pinax         | [substreams-sink-prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Webhook    | O       | Pinax         | [substreams-sink-webhook](https://github.com/pinax-network/substreams-sink-webhook)       |
+| CSV        | O       | Pinax         | [substreams-sink-csv](https://github.com/pinax-network/substreams-sink-csv)               |
+| PubSub     | O       | StreamingFast | [substreams-sink-pubsub](https://github.com/streamingfast/substreams-sink-pubsub)         |
 
 ### Community
 
-| Name       | 支持 | Maintainer | Source Code                                                                               |
-| ---------- | -- | ---------- | ----------------------------------------------------------------------------------------- |
-| MongoDB    | C  | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
-| Files      | C  | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
-| KV Store   | C  | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
-| Prometheus | C  | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
+| Name       | Support | Maintainer | Source Code                                                                               |
+| ---------- | ------- | ---------- | ----------------------------------------------------------------------------------------- |
+| MongoDB    | C       | Community  | [substreams-sink-mongodb](https://github.com/streamingfast/substreams-sink-mongodb)       |
+| Files      | C       | Community  | [substreams-sink-files](https://github.com/streamingfast/substreams-sink-files)           |
+| KV Store   | C       | Community  | [substreams-sink-kv](https://github.com/streamingfast/substreams-sink-kv)                 |
+| Prometheus | C       | Community  | [substreams-sink-Prometheus](https://github.com/pinax-network/substreams-sink-prometheus) |
 
 - O = Official Support (by one of the main Substreams providers)
 - C = Community Support

From 8507aedbfceb80822e2db8693e541f84bfd20907 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 6 Feb 2025 03:22:14 -0500
Subject: [PATCH 3573/3820] New translations glossary.mdx (French)

---
 website/pages/fr/resources/glossary.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/resources/glossary.mdx b/website/pages/fr/resources/glossary.mdx
index acfffb785b5a..0e6fceb15c85 100644
--- a/website/pages/fr/resources/glossary.mdx
+++ b/website/pages/fr/resources/glossary.mdx
@@ -2,7 +2,7 @@
 title: Glossaire
 ---
 
-- **The Graph**: A decentralized protocol for indexing and querying data.
+- **The Graph** : Un protocole décentralisé pour l'indexation et l'interrogation des données.
 
 - **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
 

From 87cbf8eaaff2485f65ae3a90809b259c30f67a75 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 6 Feb 2025 06:22:04 -0500
Subject: [PATCH 3574/3820] New translations curating.mdx (German)

---
 website/pages/de/resources/roles/curating.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/de/resources/roles/curating.mdx b/website/pages/de/resources/roles/curating.mdx
index d6aa6a55acdb..083a279cad3d 100644
--- a/website/pages/de/resources/roles/curating.mdx
+++ b/website/pages/de/resources/roles/curating.mdx
@@ -16,7 +16,7 @@ Der [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) st
 
 Bei der Signalisierung können Kuratoren entscheiden, ob sie für eine bestimmte Version des Subgraphen signalisieren wollen oder ob sie die automatische Migration verwenden wollen. Bei der automatischen Migration werden die Freigaben eines Kurators immer auf die neueste vom Entwickler veröffentlichte Version aktualisiert. Wenn sie sich stattdessen für eine bestimmte Version entscheiden, bleiben die Freigaben immer auf dieser spezifischen Version.
 
-If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+Wenn Sie Unterstützung bei der Kuratierung benötigen, um die Qualität des Dienstes zu verbessern, senden Sie bitte eine Anfrage an das Edge & Node-Team unter support@thegraph.zendesk.com und geben Sie die Subgraphen an, für die Sie Unterstützung benötigen.
 
 Indexer können Subgraphen für die Indizierung auf der Grundlage von Kurationssignalen finden, die sie im Graph Explorer sehen (siehe Screenshot unten).
 
@@ -24,15 +24,15 @@ Indexer können Subgraphen für die Indizierung auf der Grundlage von Kurationss
 
 ## Wie man signalisiert
 
-Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+Auf der Registerkarte Kurator im Graph Explorer können Kuratoren bestimmte Subgraphen auf der Grundlage von Netzwerkstatistiken an- und abmelden. Einen schrittweisen Überblick über die Vorgehensweise im Graph Explorer finden Sie [hier](/subgraphs/explorer/)
 
 Ein Kurator kann sich dafür entscheiden, ein Signal für eine bestimmte Subgraph-Version abzugeben, oder er kann sein Signal automatisch auf die neueste Produktionsversion dieses Subgraphen migrieren lassen. Beides sind gültige Strategien und haben ihre eigenen Vor- und Nachteile.
 
-Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+Die Signalisierung einer bestimmten Version ist besonders nützlich, wenn ein Subgraph von mehreren Dapps verwendet wird. Eine Dapp muss den Subgraph vielleicht regelmäßig mit neuen Funktionen aktualisieren. Eine andere Dapp zieht es vielleicht vor, eine ältere, gut getestete Version des Subgraphs zu verwenden. Bei der ersten Kuration fällt eine Standardsteuer von 1% an.
 
 Die automatische Migration Ihres Signals zum neuesten Produktions-Build kann sich als nützlich erweisen, um sicherzustellen, dass Sie weiterhin Abfragegebühren anfallen. Jedes Mal, wenn Sie kuratieren, fällt eine Kuratierungssteuer von 1 % an. Außerdem zahlen Sie bei jeder Migration eine Kuratierungssteuer von 0,5 %. Subgraph-Entwickler werden davon abgehalten, häufig neue Versionen zu veröffentlichen - sie müssen eine Kurationssteuer von 0,5 % auf alle automatisch migrierten Kurationsanteile zahlen.
 
-> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+> **Anmerkung**: Die erste Adresse, die einen bestimmten Subgraph signalisiert, wird als erster Kurator betrachtet und muss viel mehr Arbeit leisten als die übrigen folgenden Kuratoren, da der erste Kurator die Kurationsaktien-Token initialisiert und außerdem Token in den Graph-Proxy überträgt.
 
 ## Abhebung Ihrer GRT
 
@@ -48,7 +48,7 @@ Es wird jedoch empfohlen, dass Kuratoren ihr signalisiertes GRT bestehen lassen,
 
 1. Der Abfragemarkt ist bei The Graph noch sehr jung, und es besteht das Risiko, dass Ihr %APY aufgrund der noch jungen Marktdynamik niedriger ist als Sie erwarten.
 2. Kurationsgebühr - wenn ein Kurator GRT auf einem Subgraphen meldet, fällt eine Kurationsgebühr von 1% an. Diese Gebühr wird verbrannt.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Nur Ethereum) Wenn Kuratoren ihre Anteile verbrennen, um GRT abzuziehen, wird die GRT-Bewertung der verbleibenden Anteile reduziert. Bitte beachten Sie, dass Kuratoren in manchen Fällen beschließen können, ihre Anteile **alle auf einmal** zu verbrennen. Dies kann der Fall sein, wenn ein Dapp-Entwickler die Versionierung/Verbesserung und Abfrage seines Subgraphen einstellt oder wenn ein Subgraph ausfällt. Infolgedessen können die verbleibenden Kuratoren möglicherweise nur einen Bruchteil ihres ursprünglichen GRT abheben. Für eine Netzwerkrolle mit einem geringeren Risikoprofil siehe [Delegators](/resources/roles/delegating/).
 4. Ein Subgraph kann aufgrund eines Fehlers fehlschlagen. Für einen fehlgeschlagenen Subgraph fallen keine Abfragegebühren an. Daher müssen Sie warten, bis der Entwickler den Fehler behebt und eine neue Version bereitstellt.
    - Wenn Sie die neueste Version eines Subgraphen abonniert haben, werden Ihre Anteile automatisch zu dieser neuen Version migriert. Dabei fällt eine Kurationsgebühr von 0,5 % an.
    - Wenn Sie für eine bestimmte Version eines Subgraphen ein Signal gegeben haben und dieses fehlschlägt, müssen Sie Ihre Kurationsanteile manuell verbrennen. Sie können dann ein Signal für die neue Subgraph-Version geben, wodurch eine Kurationssteuer von 1 % anfällt.
@@ -61,14 +61,14 @@ Durch das Signalisieren auf einem Subgraphen erhalten Sie einen Anteil an allen
 
 ### 2. Wie entscheide ich, welche Subgraphen qualitativ hochwertig sind, um sie zu signalisieren?
 
-Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+Die Suche nach qualitativ hochwertigen Subgraphen ist eine komplexe Aufgabe, die auf viele verschiedene Arten angegangen werden kann. Als Kurator möchten Sie nach vertrauenswürdigen Subgraphen suchen, die das Abfragevolumen erhöhen. Ein vertrauenswürdiger Subgraph kann wertvoll sein, wenn er vollständig und genau ist und die Datenanforderungen einer App unterstützt. Ein schlecht entworfener Subgraph muss möglicherweise überarbeitet oder neu veröffentlicht werden und kann auch scheitern. Es ist wichtig, dass die Kuratoren die Architektur oder den Code eines Subgraphen überprüfen, um zu beurteilen, ob ein Subgraph wertvoll ist. Daraus folgt:
 
 - Kuratoren können ihr Verständnis eines Netzwerks nutzen, um vorherzusagen, wie ein einzelner Subgraph in der Zukunft ein höheres oder niedrigeres Suchvolumen generieren könnte
 - Kuratoren sollten auch die Metriken verstehen, die über den Graph Explorer verfügbar sind. Metriken wie das vergangene Abfragevolumen und die Person des Subgraph-Entwicklers können dabei helfen, festzustellen, ob ein Subgraph eine Meldung wert ist oder nicht.
 
 ### 3. Wie hoch sind die Kosten für die Aktualisierung eines Subgraphen?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+Wenn Sie Ihre Kuratorenanteile auf eine neue Subgraph-Version migrieren, fällt eine Kuratorensteuer von 1 % an. Kuratoren können sich dafür entscheiden, die neueste Version eines Subgraphen zu abonnieren. Wenn Kuratorenanteile automatisch auf eine neue Version migriert werden, zahlen Kuratoren ebenfalls die Hälfte der Kurationssteuer, d. h. 0,5 %, da die Aktualisierung von Subgraphen eine Onchain-Aktion ist, die Gas kostet.
 
 ### 4. Wie oft kann ich meinen Subgraphen aktualisieren?
 

From b37195d2cc139d777b69548edeb98b15ebb10623 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 6 Feb 2025 06:22:06 -0500
Subject: [PATCH 3575/3820] New translations grafting.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/grafting.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/cookbook/grafting.mdx b/website/pages/ru/subgraphs/cookbook/grafting.mdx
index b78dd3b31720..5a1ef9628e94 100644
--- a/website/pages/ru/subgraphs/cookbook/grafting.mdx
+++ b/website/pages/ru/subgraphs/cookbook/grafting.mdx
@@ -20,7 +20,7 @@ title: Замените контракт и сохраните его истор
 
 Для получения дополнительной информации Вы можете перейти:
 
-- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+- [Графтинг](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
 
 В этом руководстве мы рассмотрим базовый случай использования. Мы заменим существующий контракт идентичным (с новым адресом, но с тем же кодом). Затем подключим существующий субграф к "базовому" субграфу, который отслеживает новый контракт.
 

From 3222c44559e05c3098f15babd33967b4d5d12efc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 6 Feb 2025 07:33:01 -0500
Subject: [PATCH 3576/3820] New translations new-chain-integration.mdx
 (Russian)

---
 website/pages/ru/indexing/new-chain-integration.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/ru/indexing/new-chain-integration.mdx b/website/pages/ru/indexing/new-chain-integration.mdx
index 95e8621267d8..427169610d41 100644
--- a/website/pages/ru/indexing/new-chain-integration.mdx
+++ b/website/pages/ru/indexing/new-chain-integration.mdx
@@ -25,7 +25,7 @@ title: Интеграция новых чейнов
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt` в пакетном запросе JSON-RPC
-- `trace_filter` _(limited tracing and optionally required for Graph Node)_
+- `trace_filter` _(ограниченное отслеживание, возможно, требуется для Graph Node)_
 
 ### 2. Интеграция Firehose
 
@@ -33,11 +33,11 @@ title: Интеграция новых чейнов
 
 > ПРИМЕЧАНИЕ: Все интеграции, выполненные командой StreamingFast, включают обслуживание протокола репликации Firehose в кодовой базе чейна. StreamingFast отслеживает любые изменения и выпускает двоичные файлы, когда Вы изменяете код и когда StreamingFast изменяет код. Сюда входит выпуск двоичных файлов Firehose/Substreams для протокола, поддержка модулей Substreams для блочной модели чейна и выпуск двоичных файлов для ноды блокчейна с оснащением инструментами, если это необходимо.
 
-#### Integration for Non-EVM chains
+#### Интеграция для чейнов, не поддерживающих EVM
 
 Основной метод интеграции Firehose в чейны — использование стратегии опроса RPC. Наш алгоритм опроса предсказывает, когда поступит новый блок, и увеличивает скорость проверки наличия нового блока в ближайшее время, что делает его эффективным решением с очень низкой задержкой. За помощью по интеграции и обслуживанию Firehose обращайтесь к [команде StreamingFast] (https://www.streamingfast.io/firehose-integration-program). Новые чейны и их интеграторы по достоинству оценят [осведомленность о форках](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) и огромные возможности параллельного индексирования, которые Firehose и Substreams привносят в их экосистему.
 
-#### Specific Instrumentation for EVM (`geth`) chains
+#### Специальная оборудование для чейнов EVM (`geth`)
 
 Для чейнов EVM существует более глубокий уровень данных, который может быть достигнут с помощью `geth` [live-tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), сотрудничества между Go-Ethereum и StreamingFast, для создания высокопроизводительной и богатой системы отслеживания транзакций. Live Tracer — наиболее комплексное решение, позволяющее получать [Расширенные](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) детали блоков. Это позволяет использовать новые парадигмы индексирования, такие как сопоставление шаблонов событий на основе изменений состояния, вызовов, деревьев вызовов более высокого уровня или запуск событий на основе изменений фактических переменных в смарт-контракте.
 
@@ -59,7 +59,7 @@ title: Интеграция новых чейнов
 
 1. [Клонировать Graph Node](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
+2. Измените [эту строку](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22), чтобы включить новое имя сети и совместимый с EVM JSON-RPC или Firehose URL.
 
    > Не меняйте само имя переменной env. Оно должно оставаться `ethereum`, даже если имя сети отличается.
 

From a58ea7514bb5f2ad2ef4bb469e1ea77554fa645e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 6 Feb 2025 07:33:03 -0500
Subject: [PATCH 3577/3820] New translations grafting.mdx (Russian)

---
 .../pages/ru/subgraphs/cookbook/grafting.mdx  | 36 +++++++++----------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/grafting.mdx b/website/pages/ru/subgraphs/cookbook/grafting.mdx
index 5a1ef9628e94..23624fa4ec04 100644
--- a/website/pages/ru/subgraphs/cookbook/grafting.mdx
+++ b/website/pages/ru/subgraphs/cookbook/grafting.mdx
@@ -26,7 +26,7 @@ title: Замените контракт и сохраните его истор
 
 ## Важное примечание о Grafting при обновлении до сети
 
-> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+> **Предупреждение**: Рекомендуется не использовать графтинг для субграфов, опубликованных в сети The Graph
 
 ### Почему это важно?
 
@@ -34,23 +34,23 @@ Grafting is a powerful feature that allows you to "graft" one subgraph onto anot
 
 ### Лучшие практики
 
-**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+**Первоначальная миграция**: при первом развертывании субграфа в децентрализованной сети рекомендуется не использовать графтинг. Убедитесь, что субграф стабилен и работает должным образом.
 
-**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+**Последующие обновления**: когда Ваш субграф будет развернут и стабилен в децентрализованной сети, Вы можете использовать графтинг для будущих версий, чтобы облегчить переход и сохранить исторические данные.
 
 Соблюдая эти рекомендации, Вы минимизируете риски и обеспечите более плавный процесс миграции.
 
 ## Создание существующего субграфа
 
-Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+Создание субграфов — это важная часть работы с The Graph, более подробно описанная [здесь](/subgraphs/quick-start/). Для того чтобы иметь возможность создать и развернуть существующий субграф, используемый в этом руководстве, предоставлен следующий репозиторий:
 
-- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+- [Пример репозитория субграфа](https://github.com/Shiyasmohd/grafting-tutorial)
 
-> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+> Примечание: Контракт, используемый в субграфе, был взят из следующего [стартового набора Hackathon](https://github.com/schmidsi/hackathon-starterkit).
 
 ## Определение манифеста субграфа
 
-The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+Манифест субграфа `subgraph.yaml` определяет источники данных для субграфа, триггеры, которые представляют интерес, и функции, которые должны быть выполнены в ответ на эти триггеры. Ниже приведен пример манифеста субграфа, который Вы будете использовать:
 
 ```yaml
 specVersion: 0.0.4
@@ -79,9 +79,9 @@ dataSources:
       file: ./src/lock.ts
 ```
 
-- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
-- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
-- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+- Источник данных `Lock` — это ABI и адрес контракта, которые мы получим при компиляции и развертывании контракта
+- Сеть должна соответствовать индексируемой сети, к которой выполняется запрос. Поскольку мы работаем в тестнете Sepolia, сеть будет `sepolia`.
+- Раздел `mapping` определяет триггеры, которые представляют интерес, и функции, которые должны быть выполнены в ответ на эти триггеры. В данном случае мы слушаем событие `Withdrawal` и вызываем функцию `handleWithdrawal`, когда оно срабатывает.
 
 ## Определение Манифеста Grafting
 
@@ -96,15 +96,15 @@ graft:
   block: 5956000 # block number
 ```
 
-- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
-- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+- `features:` — это список всех используемых [имен функций](/developing/creating-a-subgraph/#experimental-features).
+- `graft:` — это отображение базового субграфа и блока, к которому применяется графтинг (перенос). `block` — это номер блока, с которого нужно начать индексирование. The Graph скопирует данные из базового субграфа до указанного блока включительно, а затем продолжит индексирование нового субграфа с этого блока.
 
-The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+Значения `base` и `block` можно найти, развернув два субграфа: один для базового индексирования и один с графтингом
 
 ## Развертывание базового субграфа
 
-1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
-2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+1. Перейдите в [Subgraph Studio](https://thegraph.com/studio/) и создайте субграф в тестнете Sepolia с названием `graft-example`
+2. Следуйте инструкциям в разделе `AUTH & DEPLOY` на странице своего субграфа в папке `graft-example` репозитория
 3. После завершения убедитесь, что субграф правильно индексируется. Если Вы запустите следующую команду в The Graph Playground
 
 ```graphql
@@ -144,9 +144,9 @@ The `base` and `block` values can be found by deploying two subgraphs: one for t
 
 Замененный subgraph.yaml будет иметь новый адрес контракта. Это может произойти, когда Вы обновите свое децентрализованное приложение, повторно развернете контракт и т. д.
 
-1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
-2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
-3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+1. Перейдите в [Subgraph Studio](https://thegraph.com/studio/) и создайте субграф в тестнете Sepolia с названием `graft-replacement`
+2. Создайте новый манифест. `subgraph.yaml` для `graph-replacement` содержит другой адрес контракта и новую информацию о том, как он должен быть присоединен. Это `block` [последнего сгенерированного события], которое Вас интересует, вызванного старым контрактом, и `base` старого субграфа. Идентификатор субграфа `base` — это `Deployment ID` Вашего исходного субграфа `graph-example`. Вы можете найти его в Subgraph Studio.
+3. Следуйте инструкциям в разделе `AUTH & DEPLOY` на странице своего субграфа в папке `graft-replacement` репозитория
 4. После завершения убедитесь, что субграф правильно индексируется. Если Вы запустите следующую команду в The Graph Playground
 
 ```graphql

From 3705fdca0884906c9ebc54f2031985a8e490c12c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 6 Feb 2025 08:52:54 -0500
Subject: [PATCH 3578/3820] New translations grafting.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/grafting.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/grafting.mdx b/website/pages/ru/subgraphs/cookbook/grafting.mdx
index 23624fa4ec04..27afce69ccd6 100644
--- a/website/pages/ru/subgraphs/cookbook/grafting.mdx
+++ b/website/pages/ru/subgraphs/cookbook/grafting.mdx
@@ -185,7 +185,7 @@ graft:
 }
 ```
 
-You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+Вы можете увидеть, что субграф `graft-replacement` индексирует данные как из старого субграфа `graph-example`, так и из новых данных из нового адреса контракта. Исходный контракт сгенерировал два события `Withdrawal`, [Событие 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) и [Событие 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). Новый контракт сгенерировал одно событие `Withdrawal` после этого, [Событие 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). Две ранее индексируемые транзакции (События 1 и 2) и новая транзакция (Событие 3) были объединены в субграфе `graft-replacement`.
 
 Поздравляем! Вы успешно перенесли один субграф в другой.
 
@@ -197,6 +197,6 @@ If you want more experience with grafting, here are a few examples for popular c
 - [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
 - [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
 
-To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+Чтобы стать еще большим экспертом в области Graph, рассмотрите возможность изучения других способов обработки изменений в исходных данных. Альтернативы, такие как [Шаблоны источников данных](/developing/creating-a-subgraph/#data-source-templates), могут привести к аналогичным результатам
 
-> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)
+> Примечание: Многие материалы из этой статьи были взяты из ранее опубликованной статьи об [Arweave](/subgraphs/cookbook/arweave/)

From 285da5bacdc99f80e9aa9f534e15b6b9e661b7d0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 6 Feb 2025 10:03:10 -0500
Subject: [PATCH 3579/3820] New translations grafting-hotfix.mdx (Russian)

---
 .../ru/subgraphs/cookbook/grafting-hotfix.mdx  | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
index 2c9fcb2c8067..ba9713bc44b8 100644
--- a/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
@@ -1,25 +1,25 @@
 ---
-title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+title: Лучшая практика субграфов 6 — используйте графтинг для быстрого развертывания исправлений
 ---
 
 ## Краткое содержание
 
-Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+Графтинг — это мощная функция в разработке субграфов, которая позволяет создавать и разворачивать новые субграфы, повторно используя индексированные данные из существующих.
 
 ### Обзор
 
-This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+Эта функция позволяет быстро развертывать исправления для критических ошибок, устраняя необходимость повторного индексирования всего субграфа с нуля. Сохраняя исторические данные, графтинг минимизирует время простоя и обеспечивает непрерывность работы сервисов данных.
 
-## Benefits of Grafting for Hotfixes
+## Преимущества графтинга для оперативных исправлений
 
-1. **Rapid Deployment**
+1. **Быстрое развертывание**
 
-   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
-   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+   - **Минимизация времени простоя**: когда субграф сталкивается с критической ошибкой и перестает индексировать данные, графтинг позволяет немедленно развернуть исправление без необходимости ждать повторного индексирования.
+   - **Немедленное восстановление**: новый субграф продолжается с последнего индексированного блока, обеспечивая бесперебойную работу служб передачи данных.
 
-2. **Data Preservation**
+2. **Сохранение данных**
 
-   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Повторное использование исторических данных**: графтинг копирует существующие данные из базового субграфа, что позволяет сохранить важные исторические записи.
    - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
 
 3. **Efficiency**

From 86be9dfd2ed250485fa424e51ee500406e8ef76e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 6 Feb 2025 11:24:13 -0500
Subject: [PATCH 3580/3820] New translations grafting-hotfix.mdx (Russian)

---
 .../ru/subgraphs/cookbook/grafting-hotfix.mdx | 96 +++++++++----------
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
index ba9713bc44b8..42ff7255b1e3 100644
--- a/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
@@ -20,45 +20,45 @@ title: Лучшая практика субграфов 6 — используй
 2. **Сохранение данных**
 
    - **Повторное использование исторических данных**: графтинг копирует существующие данные из базового субграфа, что позволяет сохранить важные исторические записи.
-   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+   - **Консистентность**: поддерживает непрерывность данных, что имеет решающее значение для приложений, полагающихся на согласованные исторические данные.
 
-3. **Efficiency**
-   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
-   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+3. **Эффективность**
+   - **Экономия времени и ресурсов**: избегает вычислительных затрат на повторное индексирование больших объемов данных.
+   - **Фокус на исправлениях**: позволяет разработчикам сосредоточиться на решении проблем, а не на восстановлении данных.
 
-## Best Practices When Using Grafting for Hotfixes
+## Лучшие практики при использовании графтинга для оперативных исправлений
 
-1. **Initial Deployment Without Grafting**
+1. **Первоначальное развертывание без графтинга**
 
-   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
-   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+   - **Начните с чистого листа**: Всегда разворчивайте первоначальный субграф без использования графтинга, чтобы убедиться в его стабильности и корректной работе.
+   - **Тщательно тестируйте**: проверьте производительность субграфа, чтобы свести к минимуму необходимость в будущих исправлениях.
 
-2. **Implementing the Hotfix with Grafting**
+2. **Реализация исправления с использованием графтинга**
 
-   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
-   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
-   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
-   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+   - **Определите проблему**: при возникновении критической ошибки определите номер блока последнего успешно проиндексированного события.
+   - **Создайте новый субграф**: разработайте новый субграф, включающий оперативное исправление.
+   - **Настройте графтинг**: используйте графтинг для копирования данных до определенного номера блока из неисправного субграфа.
+   - **Быстро разверните**: опубликуйте графтинговый (перенесенный) субграф, чтобы как можно скорее восстановить работу сервиса.
 
-3. **Post-Hotfix Actions**
+3. **Действия после оперативного исправления**
 
-   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
-   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
-     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
-   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+   - **Мониторинг производительности**: убедитесь, что графтинговый (перенесенный) субграф индексируется правильно и исправление решает проблему.
+   - **Публикация без графтинга**: как только субграф стабилизируется, разверните его новую версию без использования графтинга для долгосрочного обслуживания.
+     > Примечание: Не рекомендуется использовать графтинг бесконечно, так как это может усложнить будущие обновления и обслуживание.
+   - **Обновите ссылки**: перенаправьте все сервисы или приложения на новый субграф без использования графтинга.
 
-4. **Important Considerations**
-   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
-   - **Tip**: Use the block number of the last correctly processed event.
-   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
-   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
-   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+4. **Важные замечания**
+   - **Тщательный выбор блока**: тщательно выбирайте номер блока графтинга, чтобы избежать потери данных.
+   - **Совет**: используйте номер блока последнего корректно обработанного события.
+   - **Используйте идентификатор развертывания**: убедитесь, что Вы ссылаетесь на идентификатор развертывания базового субграфа, а не на идентификатор субграфа.
+   - **Примечание**: идентификатор развертывания — это уникальный идентификатор для конкретного развертывания субграфа.
+   - **Объявление функции**: не забудьте указать использование графтинга в манифесте субграфа в разделе функций.
 
-## Example: Deploying a Hotfix with Grafting
+## Пример: развертывание оперативного исправления с использованием графтинга
 
-Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+Предположим, у вас есть субграф, отслеживающий смарт-контракт, который перестал индексироваться из-за критической ошибки. Вот как Вы можете использовать графтинг для развертывания оперативного исправления.
 
-1. **Failed Subgraph Manifest (subgraph.yaml)**
+1. **Манифест неудачного субграфа (subgraph.yaml)**
 
    ```yaml
    specVersion: 1.0.0
@@ -87,7 +87,7 @@ Suppose you have a subgraph tracking a smart contract that has stopped indexing
          file: ./src/old-lock.ts
    ```
 
-2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+2. **Манифест нового субграфа с графтингом (subgraph.yaml)**
    ```yaml
    specVersion: 1.0.0
    schema:
@@ -99,7 +99,7 @@ Suppose you have a subgraph tracking a smart contract that has stopped indexing
        source:
          address: '0xNewContractAddress'
          abi: Lock
-         startBlock: 6000001 # Block after the last indexed block
+         startBlock: 6000001 # Блок после последнего индексированного блока
        mapping:
          kind: ethereum/events
          apiVersion: 0.0.7
@@ -116,32 +116,32 @@ Suppose you have a subgraph tracking a smart contract that has stopped indexing
    features:
      - grafting
    graft:
-     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
-     block: 6000000 # Last successfully indexed block
+     base: QmBaseDeploymentID # ID развертывания неудачного субграфа
+     block: 6000000 # Последний успешно индексированный блок
    ```
 
-**Explanation:**
+**Пояснение:**
 
-- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
-- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
-- **Grafting Configuration**:
-  - **base**: Deployment ID of the failed subgraph.
-  - **block**: Block number where grafting should begin.
+- **Обновление источника данных**: новый субграф указывает на 0xNewContractAddress, который может быть исправленной версией смарт-контракта.
+- **Начальный блок**: устанавливается на один блок после последнего успешно индексированного блока, чтобы избежать повторной обработки ошибки.
+- **Конфигурация графтинга**:
+  - **base**: идентификатор развертывания неудачного субграфа.
+  - **block**: номер блока, с которого должен начаться графтинг.
 
-3. **Deployment Steps**
+3. **Шаги развертывания**
 
-   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
-   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
-   - **Deploy the Subgraph**:
-     - Authenticate with the Graph CLI.
-     - Deploy the new subgraph using `graph deploy`.
+   - **Обновите код**: внедрите исправление в свои скрипты мэппинга (например, handleWithdrawal).
+   - **Отредактируйте манифест**: как показано выше, обновите файл `subgraph.yaml` с конфигурациями для графтинга.
+   - **Разверните субграф**:
+     - Аутентифицируйтесь с помощью Graph CLI.
+     - Разверните новый субграф используя `graph deploy`.
 
-4. **Post-Deployment**
-   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
-   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
-   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+4. **После развертывания**
+   - **Проверьте индексирование**: убедитесь, что субграф корректно индексирует данные с точки графтинга.
+   - **Следите за данными**: убедитесь, что новые данные индексируются и что исправление работает эффективно.
+   - **Запланируйте повторную публикацию**: запланируйте развертывание версии без графтинга для обеспечения долгосрочной стабильности.
 
-## Warnings and Cautions
+## Предупреждения и предостережения
 
 While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
 

From ae233b0dc42856ac7ad84418c4a3e7d3d781805a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 03:14:20 -0500
Subject: [PATCH 3581/3820] New translations grafting-hotfix.mdx (Russian)

---
 .../ru/subgraphs/cookbook/grafting-hotfix.mdx | 30 +++++++++----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
index 42ff7255b1e3..92ef1b16754e 100644
--- a/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/ru/subgraphs/cookbook/grafting-hotfix.mdx
@@ -143,33 +143,33 @@ title: Лучшая практика субграфов 6 — используй
 
 ## Предупреждения и предостережения
 
-While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+Хотя графтинг является мощным инструментом для быстрого развертывания исправлений, существуют конкретные сценарии, когда его следует избегать для поддержания целостности данных и обеспечения оптимальной производительности.
 
-- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
-- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
-- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+- **Несовместимые изменения схемы**: если ваше исправление требует изменения типа существующих полей или удаления полей из схемы, графтинг не подходит. Графтинг предусматривает, что схема нового субграфа будет совместима со схемой базового субграфа. Несовместимые изменения могут привести к несоответствиям данных и ошибкам, так как существующие данные не будут соответствовать новой схеме.
+- **Значительные изменения логики мэппинга**: когда исправление включает существенные изменения в вашей логике мэппинга, такие как изменение обработки событий или изменение функций обработчиков, графтинг может работать некорректно. Новая логика может быть несовместима с данными, обработанными по старой логике, что приведет к некорректным данным или сбоям в индексировании.
+- **Развертывания в сеть The Graph**: графтинг не рекомендуется для субграфов, предназначенных для децентрализованной сети The Graph (майннет). Это может усложнить индексирование и не поддерживаться всеми Индексаторами, что может привести к непредсказуемому поведению или увеличению затрат. Для развертываний в майннете безопаснее перезапустить индексирование субграфа с нуля, чтобы обеспечить полную совместимость и надежность.
 
-### Risk Management
+### Управление рисками
 
-- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
-- **Testing**: Always test grafting in a development environment before deploying to production.
+- **Целостность данных**: неверно указанные номера блоков могут привести к потере данных или их дублированию.
+- **Тестирование**: всегда тестируйте графтинг в среде разработки перед развертыванием в рабочей среде.
 
 ## Заключение
 
-Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+Графтинг — это эффективная стратегия для развертывания оперативных исправлений в разработке субграфов, позволяющая Вам:
 
-- **Quickly Recover** from critical errors without re-indexing.
-- **Preserve Historical Data**, maintaining continuity for applications and users.
-- **Ensure Service Availability** by minimizing downtime during critical fixes.
+- **Быстро восстанавливаться** после критических ошибок без повторного индексирования.
+- **Сохранять исторические данные**, поддерживая непрерывности работы для приложений и пользователей.
+- **Обеспечить доступность сервиса**, минимизируя время простоя при критических исправлениях.
 
-However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+Однако важно использовать графтинг разумно и следовать лучшим практикам для снижения рисков. После стабилизации своего субграфа с помощью оперативных исправлений, спланируйте развертывание версии без графтинга для обеспечения долгосрочного обслуживания.
 
 ## Дополнительные ресурсы
 
-- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
-- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+- **[Документация графтинга](/subgraphs/cookbook/grafting/)**: замените контракт и сохраните его историю с помощью графтинга
+- **[Понимание идентификаторов развертывания](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: ознакомьтесь с разницей между идентификатором развертывания и идентификатором субграфа.
 
-By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+Включив графтинг в процесс разработки субграфов, Вы сможете быстрее реагировать на проблемы, обеспечивая стабильность и надежность Ваших сервисов данных.
 
 ## Лучшие практики для субграфов 1-6
 

From 332d0fe5f181ffb59746b10f78ee43f5bb86349b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 03:14:21 -0500
Subject: [PATCH 3582/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Russian)

---
 .../immutable-entities-bytes-as-ids.mdx       | 62 +++++++++----------
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
index 4c0710ecbe66..ee3a6cb6ad56 100644
--- a/website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/ru/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -1,14 +1,14 @@
 ---
-title: Subgraph Best Practice 3 - Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs
+title: Лучшие практики для субграфов №3 – Улучшение индексирования и производительности запросов с использованием неизменяемых объектов и байтов в качестве идентификаторов
 ---
 
 ## Краткое содержание
 
-Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+Использование неизменяемых объектов и байтов в качестве идентификаторов в файле `schema.graphql` [значительно улучшает](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) скорость индексирования и производительность запросов.
 
-## Immutable Entities
+## Неизменяемые объекты
 
-To make an entity immutable, we simply add `(immutable: true)` to an entity.
+Чтобы сделать объект неизменяемым, просто добавьте `(immutable: true)` к объекту.
 
 ```graphql
 type Transfer @entity(immutable: true) {
@@ -19,21 +19,21 @@ type Transfer @entity(immutable: true) {
 }
 ```
 
-By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+Сделав объект `Transfer` неизменяемым, graph-node сможет обрабатывать его более эффективно, что улучшит скорость индексирования и отклик на запросы.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Структуры неизменяемых объектов не будут изменяться в будущем. Идеальным кандидатом для превращения в неизменяемый объект может быть объект, который напрямую фиксирует данные событий в блокчейне, например, событие `Transfer`, записываемое как объект `Transfer`.
 
-### Under the hood
+### Под капотом
 
-Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+Изменяемые объекты имеют «диапазон блоков», указывающий их актуальность. Обновление таких объектов требует от graph node корректировки диапазона блоков для предыдущих версий, что увеличивает нагрузку на базу данных. Запросы также должны фильтровать данные, чтобы находить только актуальные объекты. Неизменяемые объекты работают быстрее, поскольку все они актуальны, и, так как они не изменяются, не требуется никаких проверок или обновлений при записи, а также фильтрации во время выполнения запросов.
 
-### When not to use Immutable Entities
+### Когда не следует использовать неизменяемые объекты
 
-If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+Если у Вас есть поле, такое как `status`, которое необходимо изменять с течением времени, то не следует делать объект неизменяемым. В противном случае, используйте неизменяемые объекты, когда это возможно.
 
-## Bytes as IDs
+## Использование Bytes в качестве идентификаторов
 
-Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+Каждый объект требует уникального идентификатора. В предыдущем примере мы видим, что идентификатор уже имеет тип Bytes.
 
 ```graphql
 type Transfer @entity(immutable: true) {
@@ -44,19 +44,19 @@ type Transfer @entity(immutable: true) {
 }
 ```
 
-While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+Хотя для идентификаторов возможны и другие типы, такие как String и Int8, рекомендуется использовать тип Bytes для всех идентификаторов. Это связано с тем, что строковые данные занимают в два раза больше места, чем строковые данные в формате Byte, а сравнение строк в кодировке UTF-8 требует учета локали, что намного более затратно по сравнению с побайтовым сравнением, используемым для строк типа Byte.
 
-### Reasons to Not Use Bytes as IDs
+### Причины, по которым не стоит использовать Bytes как идентификаторы
 
-1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
-2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
-3. Indexing and querying performance improvements are not desired.
+1. Если идентификаторы объектов должны быть читаемыми для человека, например, автоинкрементированные числовые идентификаторы или читаемые строки, то не следует использовать тип Bytes для идентификаторов.
+2. Если данные субграфа интегрируются с другой моделью данных, которая не использует тип Bytes для идентификаторов, то не следует использовать Bytes для идентификаторов в субграфе.
+3. Если улучшения производительности индексирования и запросов не являются приоритетом.
 
-### Concatenating With Bytes as IDs
+### Конкатенация (объединение) с использованием Bytes как идентификаторов
 
-It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+Это распространенная практика во многих субграфах — использовать конкатенацию строк для объединения двух свойств события в единый идентификатор, например, используя `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. Однако поскольку это возвращает строку, такой подход значительно ухудшает производительность индексирования и запросов в субграфах.
 
-Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+Вместо этого следует использовать метод `concatI32()` для конкатенации свойств события. Эта стратегия приводит к созданию идентификатора типа `Bytes`, который гораздо более производителен.
 
 ```typescript
 export function handleTransfer(event: TransferEvent): void {
@@ -73,11 +73,11 @@ export function handleTransfer(event: TransferEvent): void {
 }
 ```
 
-### Sorting With Bytes as IDs
+### Сортировка с использованием идентификаторов Bytes
 
-Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+Сортировка с использованием идентификаторов Bytes не является оптимальной, как это видно из примера запроса и ответа.
 
-Query:
+Запрос:
 
 ```graphql
 {
@@ -90,7 +90,7 @@ Query:
 }
 ```
 
-Query response:
+Ответ на запрос:
 
 ```json
 {
@@ -119,9 +119,9 @@ Query response:
 }
 ```
 
-The IDs are returned as hex.
+Идентификаторы возвращаются в виде шестнадцатеричной строки.
 
-To improve sorting, we should create another field on the entity that is a BigInt.
+Чтобы улучшить сортировку, мы должны создать другое поле в объекте, которое будет иметь тип BigInt.
 
 ```graphql
 type Transfer @entity {
@@ -133,9 +133,9 @@ type Transfer @entity {
 }
 ```
 
-This will allow for sorting to be optimized sequentially.
+Это позволит оптимизировать сортировку в последовательном порядке.
 
-Query:
+Запрос:
 
 ```graphql
 {
@@ -146,7 +146,7 @@ Query:
 }
 ```
 
-Query Response:
+Ответ на запрос:
 
 ```json
 {
@@ -171,9 +171,9 @@ Query Response:
 
 ## Заключение
 
-Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+Использование как неизменяемых объектов, так и Bytes как идентификаторов значительно улучшает эффективность субграфов. В частности, тесты показали увеличение производительности запросов до 28% и ускорение индексирования до 48%.
 
-Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+Читайте больше о применении неизменяемых объектов и Bytes как идентификаторов в этом блоге от Дэвида Луттеркорта, инженера-программиста в Edge & Node: [Два простых способа улучшить производительность субграфов](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
 
 ## Лучшие практики для субграфов 1-6
 

From 618a7f6b4be9671d96a3763254b98649b3ade463 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 03:14:22 -0500
Subject: [PATCH 3583/3820] New translations near.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/near.mdx | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/near.mdx b/website/pages/ru/subgraphs/cookbook/near.mdx
index df004acc3124..94d9fe384eff 100644
--- a/website/pages/ru/subgraphs/cookbook/near.mdx
+++ b/website/pages/ru/subgraphs/cookbook/near.mdx
@@ -2,32 +2,32 @@
 title: Создание субграфов на NEAR
 ---
 
-This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+Это руководство является введением в создание субграфов для индексирования смарт-контрактов на [блокчейне NEAR](https://docs.near.org/).
 
 ## Что такое NEAR?
 
-[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+[NEAR](https://near.org/) — это платформа для смарт-контрактов, предназначенная для создания децентрализованных приложений. Для получения дополнительной информации ознакомьтесь с [официальной документацией](https://docs.near.org/concepts/basics/protocol).
 
 ## Что такое NEAR подграфы?
 
-The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+The Graph предоставляет разработчикам инструменты для обработки событий блокчейна и упрощает доступ к полученным данным через API GraphQL, известный также как субграф. [Graph Node](https://github.com/graphprotocol/graph-node) теперь способен обрабатывать события NEAR, что позволяет разработчикам NEAR создавать субграфы для индексирования своих смарт-контрактов.
 
-Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+Субграфы основаны на событиях, что означает, что они отслеживают и обрабатывают события в блокчейне. В настоящее время для субграфов NEAR поддерживаются два типа обработчиков:
 
 - Обработчики блоков: они запускаются для каждого нового блока
 - Обработчики квитанций: запускаются каждый раз, когда сообщение выполняется в указанной учетной записи
 
-[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+[Из документации NEAR](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
 
 > Квитанция - это единственный объект, к которому можно применить действие в системе. Когда мы говорим об "обработке транзакции" на платформе NEAR, это в конечном итоге означает "применение квитанций" в какой-то момент.
 
 ## Создание NEAR подграфа
 
-`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+`@graphprotocol/graph-cli` — это инструмент командной строки для создания и развертывания субграфов.
 
-`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+`@graphprotocol/graph-ts` — это библиотека типов, специфичных для субграфов.
 
-NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+Для разработки субграфов на платформе NEAR требуется `graph-cli` версии выше `0.23.0` и `graph-ts` версии выше `0.23.0`.
 
 > Построение NEAR сабграфа очень похоже на построение сабграфа, индексирующего Ethereum.
 

From c739ac6d13ad9a80b051092e980ed9a69e8a4607 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 04:27:03 -0500
Subject: [PATCH 3584/3820] New translations near.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/near.mdx | 56 ++++++++++----------
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/near.mdx b/website/pages/ru/subgraphs/cookbook/near.mdx
index 94d9fe384eff..7b1f02bf4449 100644
--- a/website/pages/ru/subgraphs/cookbook/near.mdx
+++ b/website/pages/ru/subgraphs/cookbook/near.mdx
@@ -33,11 +33,11 @@ The Graph предоставляет разработчикам инструме
 
 Существует три аспекта определения подграфа:
 
-**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+**subgraph.yaml:** манифест субграфа, определяющий источники данных и способы их обработки. NEAR является новым `kind` (типом) источника данных.
 
-**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+**schema.graphql:** файл схемы, который определяет, какие данные хранятся в Вашем субграфе и как к ним можно обращаться через GraphQL. Требования для субграфов NEAR описаны в [существующей документации](/developing/creating-a-subgraph/#the-graphql-schema).
 
-**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+**Мэппинги на AssemblyScript:** [код на AssemblyScript](/subgraphs/developing/creating/graph-ts/api/), который преобразует данные событий в элементы, определенные в Вашей схеме. Поддержка NEAR вводит специфичные для NEAR типы данных и новую функциональность для парсинга JSON.
 
 Во время разработки субграфа есть две ключевые команды:
 
@@ -48,7 +48,7 @@ $ graph build # генерирует Web Assembly из файлов AssemblyScri
 
 ### Определение манифеста субграфа
 
-The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+Манифест субграфа (`subgraph.yaml`) определяет источники данных для субграфа, интересующие триггеры и функции, которые должны быть выполнены в ответ на эти триггеры. Пример манифеста субграфа для NEAR представлен ниже:
 
 ```yaml
 specVersion: 0.0.2
@@ -70,10 +70,10 @@ dataSources:
       file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
 ```
 
-- NEAR subgraphs introduce a new `kind` of data source (`near`)
-- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
-- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
-- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+- Субграфы NEAR вводят новый тип источника данных (`near`)
+- `network` должен соответствовать сети на хостинговой Graph Node. В Subgraph Studio майннет NEAR называется `near-mainnet`, а теснет NEAR — `near-testnet`
+- Источники данных NEAR содержат необязательное поле `source.account`, которое представляет собой удобочитаемый идентификатор, соответствующий [учетной записи NEAR] (https://docs.near.org/concepts/protocol/account-model). Это может быть как основной аккаунт, так и суб-аккаунт.
+- Источники данных NEAR вводят альтернативное необязательное поле `source.accounts`, которое содержит необязательные префиксы и суффиксы. Необходимо указать хотя бы один префикс или суффикс, они будут соответствовать любому аккаунту, начинающемуся или заканчивающемуся на значения из списка соответственно. Приведенный ниже пример будет совпадать с: `[app|good].*[morning.near|morning.testnet]`. Если необходим только список префиксов или суффиксов, другое поле можно опустить.
 
 ```yaml
 accounts:
@@ -87,8 +87,8 @@ accounts:
 
 Источники данных NEAR поддерживают два типа обработчиков:
 
-- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
-- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+- `blockHandlers`: выполняется для каждого нового блока NEAR. `source.account` не требуется.
+- `receiptHandlers`: выполняется при каждом получении, где `source.account` источника данных является получателем. Обратите внимание, что обрабатываются только точные совпадения ([субаккаунты](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) должны быть добавлены как независимые источники данных).
 
 ### Определение схемы
 
@@ -98,7 +98,7 @@ accounts:
 
 Обработчики для обработки событий написаны на [AssemblyScript](https://www.assemblyscript.org/).
 
-NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+Индексирование NEAR вводит специфичные для NEAR типы данных в [API AssemblyScript](/subgraphs/developing/creating/graph-ts/api/).
 
 ```typescript
 
@@ -125,7 +125,7 @@ class ActionReceipt {
 
 class BlockHeader {
       height: u64,
-      prevHeight: u64,// Always zero when version < V3
+      prevHeight: u64,// Всегда 0 для версии < V3
       epochId: Bytes,
       nextEpochId: Bytes,
       chunksIncluded: u64,
@@ -160,33 +160,33 @@ class ReceiptWithOutcome {
   }
 ```
 
-These types are passed to block & receipt handlers:
+Эти типы передаются в обработчики блоков и поступлений:
 
-- Block handlers will receive a `Block`
-- Receipt handlers will receive a `ReceiptWithOutcome`
+- Обработчики блоков получат `Block`
+- Обработчики поступлений получат `ReceiptWithOutcome`
 
-Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+В остальном, весь [API для AssemblyScript](/subgraphs/developing/creating/graph-ts/api/) доступен разработчикам субграфов для NEAR во время выполнения мэппинга.
 
-This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+Это включает в себя новую функцию для парсинга JSON — логи в NEAR часто выводятся как строковые JSON. Новая функция `json.fromString(...)` доступна в рамках [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api), что позволяет разработчикам легко обрабатывать эти логи.
 
 ## Развертывание NEAR субграфа
 
-Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+Как только Ваш субграф будет создан, наступает время развернуть его на Graph Node для индексирования. Субграфы NEAR можно развернуть на любом Graph Node версии `>=v0.26.x` (эта версия еще не отмечена и не выпущена).
 
 Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
 
 - `near-mainnet`
 - `near-testnet`
 
-More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+Дополнительную информацию о создании и развертывании субграфов в Subgraph Studio можно найти [здесь](/deploying/deploying-a-subgraph-to-studio/).
 
-As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+В качестве краткого примера — первый шаг заключается в "создании" Вашего субграфа — это нужно сделать только один раз. В Subgraph Studio это можно сделать на Вашей [панели управления](https://thegraph.com/studio/), выбрав опцию "Создать субграф".
 
 После того как субграф создан, его можно развернуть с помощью команды `graph deploy` в CLI:
 
 ```sh
-$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
-$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+$ graph create --node <graph-node-url> <subgraph-name> # создает субграф на локальной Graph Node (в Subgraph Studio это делается через UI)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # загружает файлы сборки на указанную конечную точку IPFS, а затем разворачивает субграф на указанной Graph Node на основе хеша манифеста IPFS
 ```
 
 Конфигурация ноды будет зависеть от того, где развертывается подграф.
@@ -228,15 +228,15 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgrap
 
 ## Запрос NEAR подграфа
 
-The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+Конечная точка GraphQL для субграфов NEAR определяется в соответствии с определением схемы и существующим интерфейсом API. Для получения дополнительной информации изучите [документацию по GraphQL API](/subgraphs/querying/graphql-api/).
 
 ## Примеры субграфов
 
 Вот несколько примеров субграфов для справки:
 
-[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+[Блоки NEAR](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
 
-[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+[Подтверждения NEAR](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
 
 ## Часто задаваемые вопросы
 
@@ -254,7 +254,7 @@ The GraphQL endpoint for NEAR subgraphs is determined by the schema definition,
 
 ### Will receipt handlers trigger for accounts and their sub-accounts?
 
-If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+Если указано `account`, это будет соответствовать только точному имени аккаунта. Для того чтобы соответствовать субаккаунтам, можно указать поле `accounts`, с `suffixes` и `prefixes`, которые будут соответствовать аккаунтам и субаккаунтам. Например, следующее выражение будет соответствовать всем субаккаунтам `mintbase1.near`:
 
 ```yaml
 accounts:
@@ -276,8 +276,8 @@ accounts:
 
 ### My question hasn't been answered, where can I get more help building NEAR subgraphs?
 
-If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+Если это общий вопрос о разработке субграфов, дополнительную информацию можно найти в остальной части [документации для разработчиков](/subgraphs/quick-start/). В других случаях присоединяйтесь к [Discord-каналу The Graph Protocol](https://discord.gg/graphprotocol) и задавайте вопросы в канале #near или отправьте email на адрес near@thegraph.com.
 
 ## Ссылки
 
-- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)
+- [Документация для разработчиков NEAR](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 030f3c3eb8e7b4f7801ee614d20b591c5577d11a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 04:27:04 -0500
Subject: [PATCH 3585/3820] New translations pruning.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/pruning.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/pruning.mdx b/website/pages/ru/subgraphs/cookbook/pruning.mdx
index 4690f9bcd48d..584c03742702 100644
--- a/website/pages/ru/subgraphs/cookbook/pruning.mdx
+++ b/website/pages/ru/subgraphs/cookbook/pruning.mdx
@@ -14,7 +14,7 @@ Add a section called `indexerHints` in the manifest.
 
 - `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
 - `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
-- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+- `prune: never`: без сокращения исторических данных; сохраняет всю историю и является значением по умолчанию, если раздел `indexerHints` отсутствует. `prune: never` следует выбрать, если требуются [Запросы на путешествия во времени](/subgraphs/querying/graphql-api/#time-travel-queries).
 
 We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
 
@@ -32,7 +32,7 @@ dataSources:
 
 ## Important Considerations
 
-- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+- Если требуются [Запросы на путешествия во времени](/subgraphs/querying/graphql-api/#time-travel-queries) и при этом нужно выполнить сокращение данных, сокращение необходимо выполнить точно, чтобы сохранить функциональность запросов на путешествия во времени. По этой причине обычно не рекомендуется использовать `indexerHints: prune: auto` с запросами на путешествия во времени. Вместо этого следует выполнить сокращение, используя `indexerHints: prune: <Number of blocks to retain>`, чтобы выполнить точное сокращение до высоты блока, которое сохранит исторические данные, необходимые для запросов на путешествия во времени, или использовать `prune: never`, чтобы сохранить все данные.
 
 - It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
 

From 431070dfee7ce293ae9328f49ce5d9ef7c6bbe01 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 05:28:35 -0500
Subject: [PATCH 3586/3820] New translations pruning.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/pruning.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/cookbook/pruning.mdx b/website/pages/ru/subgraphs/cookbook/pruning.mdx
index 584c03742702..eeb7b7859665 100644
--- a/website/pages/ru/subgraphs/cookbook/pruning.mdx
+++ b/website/pages/ru/subgraphs/cookbook/pruning.mdx
@@ -34,7 +34,7 @@ dataSources:
 
 - Если требуются [Запросы на путешествия во времени](/subgraphs/querying/graphql-api/#time-travel-queries) и при этом нужно выполнить сокращение данных, сокращение необходимо выполнить точно, чтобы сохранить функциональность запросов на путешествия во времени. По этой причине обычно не рекомендуется использовать `indexerHints: prune: auto` с запросами на путешествия во времени. Вместо этого следует выполнить сокращение, используя `indexerHints: prune: <Number of blocks to retain>`, чтобы выполнить точное сокращение до высоты блока, которое сохранит исторические данные, необходимые для запросов на путешествия во времени, или использовать `prune: never`, чтобы сохранить все данные.
 
-- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+- Невозможно выполнить [графтинг](/subgraphs/cookbook/grafting/) на высоте блока, который был сокращен. Если графтинг выполняется регулярно и требуется сокращение данных, рекомендуется использовать `indexerHints: prune: <Number of blocks to retain>`, чтобы точно сохранить необходимое количество блоков (например, достаточное для шести месяцев).
 
 ## Заключение
 

From 99013e3f3aed4bcc0d0f8fa28ef4fa10d1d95f7d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 05:28:37 -0500
Subject: [PATCH 3587/3820] New translations secure-api-keys-nextjs.mdx
 (Russian)

---
 website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index 5dbc5989e24b..f7bb830755fa 100644
--- a/website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -120,4 +120,4 @@ export default function Home() {
 
 ### Заключение
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.
+Используя серверные компоненты Next.js, мы эффективно скрыли ключ API от клиентской стороны, улучшив безопасность нашего приложения. Этот метод гарантирует, что чувствительные операции обрабатываются на сервере, вдали от потенциальных уязвимостей на стороне клиента. В заключение, не забудьте ознакомиться с [другими мерами безопасности для ключей API](/subgraphs/querying/managing-api-keys/), чтобы повысить уровень безопасности своего ключа API.

From dbdec69bdf59697f2ec19de24f7745174476a720 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 05:28:38 -0500
Subject: [PATCH 3588/3820] New translations subgraph-debug-forking.mdx
 (Russian)

---
 .../cookbook/subgraph-debug-forking.mdx       | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
index c39cddd8250d..1f845f2093c5 100644
--- a/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -2,25 +2,25 @@
 title: Быстрая и простая отладка подграфа с использованием форков
 ---
 
-As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+Как и многие системы, обрабатывающие большие объемы данных, Индексаторы The Graph (Graph Nodes) могут занять достаточно много времени для синхронизации Вашего субграфа с целевым блокчейном. Несоответствие между быстрыми изменениями, направленными на отладку, и долгим временем ожидания, необходимым для индексирования, является крайне непродуктивным, и мы прекрасно осознаем эту проблему. Поэтому мы представляем **форкинг субграфа**, разработанный [LimeChain](https://limechain.tech/), и в этой статье я покажу, как эту функцию можно использовать для значительного ускорения отладки субграфов!
 
 ## И так, что это?
 
-**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+**Форкинг субграфа** — это процесс ленивой загрузки объектов из _другого_ хранилища субграфа (обычно удалённого).
 
-In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+В контексте отладки **форкинг субграфа** позволяет Вам отлаживать Ваш неудавшийся субграф на блоке _X_, не дожидаясь синхронизации с блоком _X_.
 
 ## Что? Как?
 
-When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+Когда Вы развертываете субграф на удалённой Graph Node для индексирования, и он терпит неудачу на блоке _X_, хорошая новость заключается в том, что Graph Node всё равно будет обслуживать запросы GraphQL, используя своё хранилище, которое синхронизировано с блоком _X_. Это здорово! Таким образом, мы можем воспользоваться этим "актуальным" хранилищем, чтобы исправить ошибки, возникающие при индексировании блока _X_.
 
-In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+Короче говоря, мы собираемся _форкать неработающий субграф_ с удалённой Graph Node, которая гарантированно имеет индексированный субграф до блока _X_, чтобы предоставить локально развернутому субграфу, который отлаживается на блоке _X_, актуальное состояние индексирования.
 
 ## Пожалуйста, покажите мне какой-нибудь код!
 
-To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+Чтобы сосредоточиться на отладке субграфа, давайте упростим задачу и продолжим с [примером субграфа](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar), который индексирует смарт-контракт Ethereum Gravity.
 
-Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+Вот обработчики, определённые для индексирования `Gravatar`, без каких-либо ошибок:
 
 ```tsx
 export function handleNewGravatar(event: NewGravatar): void {
@@ -44,22 +44,22 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void {
 }
 ```
 
-Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+Ой, как неприятно! Когда я развертываю свой идеально выглядящий субграф в [Subgraph Studio](https://thegraph.com/studio/), он выдаёт ошибку _"Gravatar not found!"_.
 
 Обычный способ попытаться исправить это:
 
 1. Внести изменения в источник сопоставлений, которые, по вашему мнению, решат проблему (в то время как я знаю, что это не так).
-2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+2. Перезапустите развертывание своего субграфа в [Subgraph Studio](https://thegraph.com/studio/) (или на другую удалённую Graph Node).
 3. Подождать, пока он синхронизируется.
 4. Если он снова сломается, вернуться к пункту 1, в противном случае: Ура!
 
-It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+Действительно, это похоже на обычный процесс отладки, но есть один шаг, который ужасно замедляет процесс: _3. Ждите, пока завершится синхронизация._
 
-Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+Используя **форк субграфа**, мы можем фактически устранить этот шаг. Вот как это выглядит:
 
-0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+0. Запустите локальную Graph Node с помощью **_соответстсвующего набора fork-base_**.
 1. Внесите изменения в источник сопоставлений, которые, по вашему мнению, решат проблему.
-2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+2. Произведите развертывание на локальной Graph Node, **_форкнув неудачно развернутый субграф_** и **_начав с проблемного блока_**.
 3. Если он снова сломается, вернитесь к пункту 1, в противном случае: Ура!
 
 Сейчас у вас может появиться 2 вопроса:
@@ -69,7 +69,7 @@ Using **subgraph forking** we can essentially eliminate this step. Here is how i
 
 И я вам отвечаю:
 
-1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+1. `fork-base` - это «базовый» URL, при добавлении которого к _subgraph id_ результирующий URL (`<fork-base>/<subgraph-id>`) является действительной конечной точкой GraphQL для хранилища субграфа.
 2. Форк - это просто, особо не нужно потеть:
 
 ```bash

From f31719a536fbef200d76f05edb2b8e59b8f5db64 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 07:46:45 -0500
Subject: [PATCH 3589/3820] New translations subgraph-debug-forking.mdx
 (Russian)

---
 .../pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx  | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
index 1f845f2093c5..ac7c59c92eda 100644
--- a/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -76,11 +76,11 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void {
 $ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
 ```
 
-Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+Также не забудьте установить поле `dataSources.source.startBlock` в манифесте субграфа на номер проблемного блока, чтобы пропустить индексирование ненужных блоков и воспользоваться преимуществами форка!
 
 Итак, вот что я делаю:
 
-1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+1. Я запускаю локальную Graph Node ([вот как это сделать](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) с опцией `fork-base`, установленной в: `https://api.thegraph.com/subgraphs/id/`, поскольку я буду форкать субграф, тот самый, который я ранее развертывал, с [Subgraph Studio](https://thegraph.com/studio/).
 
 ```
 $ cargo run -p graph-node --release -- \
@@ -91,7 +91,7 @@ $ cargo run -p graph-node --release -- \
 ```
 
 2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
-3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+3. После внесения изменений я развертываю свой субграф на локальной Graph Node, **выполняя форк неудавшегося субграфа** и устанавливаю значение `dataSources.source.startBlock` равным `6190343` в файле `subgraph.yaml`:
 
 ```bash
 $ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020

From 38e102c7b6646daa12d89099c193e2e170299a5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 07:46:46 -0500
Subject: [PATCH 3590/3820] New translations subgraph-uncrashable.mdx (Russian)

---
 .../ru/subgraphs/cookbook/subgraph-uncrashable.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx
index 508f2e66bfd8..dd8dbb170530 100644
--- a/website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx
+++ b/website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -2,19 +2,19 @@
 title: Генератор кода безопасного подграфа
 ---
 
-[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) — это инструмент для генерации кода, который создает набор вспомогательных функций из схемы GraphQL проекта. Он гарантирует, что все взаимодействия с объектами в Вашем субграфе будут полностью безопасными и последовательными.
 
 ## Why integrate with Subgraph Uncrashable?
 
-- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+- **Непрерывная работа**. Ошибки в обработке объектов могут привести к сбоям субграфов, что нарушит работу проектов, зависящих от The Graph. Настройте вспомогательные функции, чтобы Ваши субграфы оставались «непотопляемыми» и обеспечивали стабильную работу.
 
-- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+- **Полная безопасность**. Обычные проблемы при разработке субграфов — это ошибки загрузки неопределенных элементов, неинициализированные или неустановленные значения элементов, а также гонки при загрузке и сохранении элементов. Убедитесь, что все взаимодействия с объектами полностью атомарны.
 
-- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+- **Настройка пользователем**. Установите значения по умолчанию и настройте уровень проверок безопасности, который соответствует потребностям Вашего индивидуального проекта. Записываются предупреждающие логи, указывающие на то, где произходит нарушение логики субграфа, что помогает исправить проблему и обеспечить точность данных.
 
-**Key Features**
+**Ключевые особенности**
 
-- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+- Инструмент генерации кода поддерживает **все** типы субграфов и настраивается таким образом, чтобы пользователи могли задать разумные значения по умолчанию. Генерация кода будет использовать эту настройку для создания вспомогательных функций в соответствии с требованиями пользователей.
 
 - Фреймворк также включает способ (через config-файл) создания пользовательских, но безопасных функций установки для групп переменных объектов. Таким образом, пользователь не сможет загрузить/использовать устаревшую graph entity, и также невозможно забыть о сохранении или установке переменной, которая требуется функцией.
 
@@ -26,4 +26,4 @@ Subgraph Uncrashable можно запустить как необязатель
 graph codegen -u [options] [<subgraph-manifest>]
 ```
 
-Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.
+Ознакомьтесь с [документацией по subgraph uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/docs/) или посмотрите этот [видеоруководство](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial), чтобы узнать больше и начать разрабатывать более безопасные субграфы.

From a621ec4e0cb1810964362fb63aebea0027baa122 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 07:46:47 -0500
Subject: [PATCH 3591/3820] New translations transfer-to-the-graph.mdx
 (Russian)

---
 .../subgraphs/cookbook/transfer-to-the-graph.mdx   | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx
index a6af8dbadb20..848c94ce4c6c 100644
--- a/website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -12,9 +12,9 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 
 ## Upgrade Your Subgraph to The Graph in 3 Easy Steps
 
-1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
-2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
-3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+1. [Настройте свою среду Studio](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Разверните свой субграф в Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Опубликуйте в сети The Graph](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
 
 ## 1. Set Up Your Studio Environment
 
@@ -23,7 +23,7 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 - Перейдите в [Subgraph Studio](https://thegraph.com/studio/) и подключите свой кошелек.
 - Нажмите "Создать субграф". Рекомендуется называть субграф с использованием Заглавного регистра: "Subgraph Name Chain Name".
 
-> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+> Примечание: после публикации имя субграфа будет доступно для редактирования, но для этого каждый раз потребуется действие на он-чейне, поэтому выберите подходящее имя сразу.
 
 ### Install the Graph CLI⁠
 
@@ -70,9 +70,9 @@ graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
 
 ### Query Your Subgraph
 
-> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+> Для того чтобы привлечь около 3 индексаторов для запроса Вашего субграфа, рекомендуется зафиксировать как минимум 3000 GRT. Чтобы узнать больше о кураторстве, ознакомьтесь с разделом [Кураторство](/resources/roles/curating/) на платформе The Graph.
 
-You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+Вы можете начать [запрашивать](/subgraphs/querying/introduction/) любой субграф, отправив запрос GraphQL на конечную точку URL-адреса его запроса, которая расположена в верхней части страницы его эксплорера в Subgraph Studio.
 
 #### Пример
 
@@ -100,5 +100,5 @@ Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](
 
 ### Дополнительные ресурсы
 
-- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
+- Чтобы быстро создать и опубликовать новый субграф, ознакомьтесь с [Руководством по быстрому старту](/subgraphs/quick-start/).
 - To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).

From fcb0c59f7e0d092afa56376eb9da9036286869d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 09:55:28 -0500
Subject: [PATCH 3592/3820] New translations subgraph-debug-forking.mdx
 (Russian)

---
 website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
index ac7c59c92eda..24264f320a05 100644
--- a/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -90,7 +90,7 @@ $ cargo run -p graph-node --release -- \
     --fork-base https://api.thegraph.com/subgraphs/id/
 ```
 
-2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+2. После тщательной проверки я замечаю, что существует несоответствие в представлениях `id`, используемых при индексировании `Gravatar` в двух моих обработчиках. В то время как `handleNewGravatar` конвертирует его в hex (`event.params.id.toHex()`), `handleUpdatedGravatar` использует int32 (`event.params.id.toI32()`), что приводит к тому, что `handleUpdatedGravatar` завершается ошибкой и появляется сообщение "Gravatar not found!". Я заставляю оба обработчика конвертировать `id` в hex.
 3. После внесения изменений я развертываю свой субграф на локальной Graph Node, **выполняя форк неудавшегося субграфа** и устанавливаю значение `dataSources.source.startBlock` равным `6190343` в файле `subgraph.yaml`:
 
 ```bash

From 678b902fc7769842fbc8fbf5ddf2889631ec0014 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 09:55:29 -0500
Subject: [PATCH 3593/3820] New translations timeseries.mdx (Russian)

---
 .../ru/subgraphs/cookbook/timeseries.mdx      | 122 +++++++++---------
 1 file changed, 61 insertions(+), 61 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/timeseries.mdx b/website/pages/ru/subgraphs/cookbook/timeseries.mdx
index ad43578c6277..dd367a112e7a 100644
--- a/website/pages/ru/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/ru/subgraphs/cookbook/timeseries.mdx
@@ -1,48 +1,48 @@
 ---
-title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+title: Лучшие практики субграфов №5 — Упрощение и оптимизация с помощью временных рядов и агрегаций
 ---
 
 ## Краткое содержание
 
-Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+Использование новой функции временных рядов и агрегаций в субграфах может значительно улучшить как скорость индексирования, так и производительность запросов.
 
 ## Обзор
 
-Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+Временные ряды и агрегации снижают накладные расходы на обработку данных и ускоряют запросы, перенося вычисления агрегаций на базу данных и упрощая код отображений. Этот подход особенно эффективен при обработке больших объемов данных, основанных на времени.
 
-## Benefits of Timeseries and Aggregations
+## Преимущества временных рядов и агрегаций
 
-1. Improved Indexing Time
+1. Улучшенное время индексирования
 
-- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
-- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+- Меньше данных для загрузки: мэппинги обрабатывают меньше данных, поскольку необработанные данные хранятся в виде неизменяемых объектов временных рядов.
+- Агрегации, управляемые базой данных: агрегации вычисляются автоматически базой данных, что снижает нагрузку на мэппинги.
 
-2. Simplified Mapping Code
+2. Упрощённый код мэппинга
 
-- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
-- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+- Отсутствие ручных вычислений: разработчикам больше не нужно писать сложную логику агрегации в мэппингах.
+- Снижение сложности: упрощает обслуживание кода и минимизирует вероятность ошибок.
 
-3. Dramatically Faster Queries
+3. Существенное ускорение запросов
 
-- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
-- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+- Неизменяемые данные: все данные временных рядов неизменяемы, что обеспечивает эффективное хранение и извлечение.
+- Эффективное разделение данных: агрегаты хранятся отдельно от необработанных данных временных рядов, что позволяет запросам обрабатывать значительно меньше данных — часто на несколько порядков меньше.
 
 ### Important Considerations
 
-- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
-- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
-- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+- Незаменяемость данных: данные временных рядов не могут быть изменены после записи, что обеспечивает целостность данных и упрощает индексирование.
+- Автоматическое управление ID и метками времени: поля id и timestamp автоматически управляются graph-node, что снижает вероятность ошибок.
+- Эффективное хранение данных: разделение необработанных данных и агрегатов оптимизирует хранилище и ускоряет выполнение запросов.
 
-## How to Implement Timeseries and Aggregations
+## Как внедрить временные ряды и агрегации
 
-### Defining Timeseries Entities
+### Определение объектов временных рядов
 
-A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+Объект временного ряда представляет собой необработанные данные, собранные с течением времени. Он определяется с помощью аннотации `@entity(timeseries: true)`. Ключевые требования:
 
-- Immutable: Timeseries entities are always immutable.
-- Mandatory Fields:
-  - `id`: Must be of type `Int8!` and is auto-incremented.
-  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+- Неизменяемость: объекты временного ряда всегда неизменяемы.
+- Обязательные поля:
+  - `id`: должен быть типа `Int8!` и автоматически увеличиваться.
+  - `timestamp`: должен быть типа `Timestamp!` и автоматически устанавливаться в соответствии с временной меткой блока.
 
 Пример:
 
@@ -54,12 +54,12 @@ type Data @entity(timeseries: true) {
 }
 ```
 
-### Defining Aggregation Entities
+### Определение объектов агрегаций
 
-An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+Объект агрегации вычисляет агрегированные значения из источника данных временного ряда. Он определяется с помощью аннотации `@aggregation`. Ключевые компоненты:
 
-- Annotation Arguments:
-  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+- Аргументы аннотации:
+  - `intervals`: указывает временные интервалы (например, `["hour", "day"]`).
 
 Пример:
 
@@ -71,11 +71,11 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+В этом примере статистика агрегирует поле цены из данных за часовые и дневные интервалы, вычисляя сумму.
 
-### Querying Aggregated Data
+### Запрос агрегированных данных
 
-Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+Агрегации предоставляются через поля запросов, которые позволяют фильтровать и извлекать данные на основе измерений и временных интервалов.
 
 Пример:
 
@@ -97,13 +97,13 @@ Aggregations are exposed via query fields that allow filtering and retrieval bas
 }
 ```
 
-### Using Dimensions in Aggregations
+### Использование измерений в агрегациях
 
-Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+Измерения — это неагрегированные поля, которые используются для группировки точек данных. Они позволяют выполнять агрегации на основе определённых критериев, таких как токен в финансовом приложении.
 
 Пример:
 
-### Timeseries Entity
+### Объект временного ряда
 
 ```graphql
 type TokenData @entity(timeseries: true) {
@@ -115,7 +115,7 @@ type TokenData @entity(timeseries: true) {
 }
 ```
 
-### Aggregation Entity with Dimension
+### Объект агрегации с измерением
 
 ```graphql
 type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
@@ -128,15 +128,15 @@ type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
 }
 ```
 
-- Dimension Field: token groups the data, so aggregates are computed per token.
-- Aggregates:
-  - totalVolume: Sum of amount.
-  - priceUSD: Last recorded priceUSD.
-  - count: Cumulative count of records.
+- Поле измерения: `token` группирует данные, так что агрегированные значения вычисляются для каждого токена.
+- Агрегаты:
+  - totalVolume: сумма количества.
+  - priceUSD: последняя зафиксированная цена в USD.
+  - count: кумулятивное количество записей.
 
-### Aggregation Functions and Expressions
+### Функции агрегации и выражения
 
-Supported aggregation functions:
+Поддерживаемые функции агрегации:
 
 - sum
 - count
@@ -145,39 +145,39 @@ Supported aggregation functions:
 - first
 - last
 
-### The arg in @aggregate can be
+### Аргумент в `@aggregate` может быть
 
-- A field name from the timeseries entity.
-- An expression using fields and constants.
+- Названием поля из объекта временных рядов.
+- Выражением, использующим поля и константы.
 
-### Examples of Aggregation Expressions
+### Примеры выражений агрегации
 
-- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
-- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
-- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+- Сумма стоимости токена: @aggregate(fn: "sum", arg: "priceUSD \* amount")
+- Максимальное положительное значение суммы: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Условная сумма: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
 
-Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+Поддерживаемые операторы и функции включают базовую арифметику (+, -, \*, /), операторы сравнения, логические операторы (and, or, not), а также SQL-функции, такие как greatest, least, coalesce и другие.
 
-### Query Parameters
+### Параметры запроса
 
-- interval: Specifies the time interval (e.g., "hour").
-- where: Filters based on dimensions and timestamp ranges.
-- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+- interval: указывает временной интервал (например, "час").
+- where: фильтрует данные по измерениям и диапазонам временных меток.
+- timestamp_gte / timestamp_lt: фильтрует по времени начала и окончания (микросекунды с эпохи).
 
-### Notes
+### Примечания
 
-- Sorting: Results are automatically sorted by timestamp and id in descending order.
-- Current Data: An optional current argument can include the current, partially filled interval.
+- Сортировка: результаты автоматически сортируются по временным меткам и идентификатору в порядке убывания.
+- Текущие данные: опциональный текущий аргумент может включать текущий, частично заполненный интервал.
 
 ### Заключение
 
-Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+Внедрение временных рядов и агрегаций в субграфы является лучшей практикой для проектов, работающих с данными, зависящими от времени. Этот подход:
 
-- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
-- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
-- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+- Улучшает производительность: ускоряет индексирование и запросы, снижая нагрузку на обработку данных.
+- Упрощает разработку: устраняет необходимость в ручном написании логики агрегации в мэппингах.
+- Эффективно масштабируется: обрабатывает большие объемы данных, не ухудшая скорость и отзывчивость.
 
-By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+Применяя этот шаблон, разработчики могут создавать более эффективные и масштабируемые субграфы, обеспечивая более быстрый и надежный доступ к данным для конечных пользователей. Чтобы узнать больше о внедрении временных рядов и агрегаций, обратитесь к [Руководству по временным рядам и агрегациям](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) и рассмотрите возможность использования этой функции в своих субграфах.
 
 ## Лучшие практики для субграфов 1-6
 

From b95da897841a3ff81850cbef5d5d4453c79874b4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 09:55:32 -0500
Subject: [PATCH 3594/3820] New translations cosmos.mdx (Chinese Simplified)

---
 .../pages/zh/subgraphs/cookbook/cosmos.mdx    | 28 +++++++++----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/website/pages/zh/subgraphs/cookbook/cosmos.mdx b/website/pages/zh/subgraphs/cookbook/cosmos.mdx
index 125dac19a9ef..3958b67df717 100644
--- a/website/pages/zh/subgraphs/cookbook/cosmos.mdx
+++ b/website/pages/zh/subgraphs/cookbook/cosmos.mdx
@@ -51,7 +51,7 @@ The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subg
 specVersion: 0.0.5
 description: Cosmos Subgraph Example
 schema:
-  file: ./schema.graphql #指向模式文件的链接
+  file: ./schema.graphql # link to the schema file
 dataSources:
   - kind: cosmos
     name: CosmosHub
@@ -62,16 +62,16 @@ dataSources:
       apiVersion: 0.0.7
       language: wasm/assemblyscript
       blockHandlers:
-        - handler: handleNewBlock # 映射文件中的函数名称
+        - handler: handleNewBlock # the function name in the mapping file
       eventHandlers:
-        - event: rewards #将要处理的事件类型
-          handler: handleReward # 映射文件中的函数名称
+        - event: rewards # the type of the event that will be handled
+          handler: handleReward # the function name in the mapping file
       transactionHandlers:
-        - handler: handleTransaction # 映射文件中的函数名称
+        - handler: handleTransaction # the function name in the mapping file
       messageHandlers:
-        - message: /cosmos.staking.v1beta1.MsgDelegate # 消息的类型
-          handler: handleMsgDelegate #映射文件中的函数名称
-      file: ./src/mapping.ts #指向包含Assemblyscript映射的文件的链接
+        - message: /cosmos.staking.v1beta1.MsgDelegate # the type of a message
+          handler: handleMsgDelegate # the function name in the mapping file
+      file: ./src/mapping.ts # link to the file with the Assemblyscript mappings
 ```
 
 - Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
@@ -163,7 +163,7 @@ class Any {
 }
 ```
 
-每个处理程序类型都有自己的数据结构，这些数据结构作为参数传递给映射函数。
+Each handler type comes with its own data structure that is passed as an argument to a mapping function.
 
 - Block handlers receive the `Block` type.
 - Event handlers receive the `EventData` type.
@@ -194,7 +194,7 @@ Once the mappings are ready, the subgraph needs to be built. This step will high
 $ graph build
 ```
 
-## 部署 Cosmos 子图
+## Deploying a Cosmos subgraph
 
 Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
 
@@ -216,15 +216,15 @@ graph create subgraph-name --node http://localhost:8020
 graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost:5001
 ```
 
-## 查询 Cosmos 子图
+## Querying a Cosmos subgraph
 
 The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
 
-## 受支持的Cosmos区块链
+## Supported Cosmos Blockchains
 
 ### Cosmos Hub
 
-#### 什么是Cosmos Hub？
+#### What is Cosmos Hub?
 
 The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
 
@@ -236,7 +236,7 @@ Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testne
 
 > Osmosis support in Graph Node and on Subgraph Studio is in beta: please contact the graph team with any questions about building Osmosis subgraphs!
 
-#### Osmosis是什么？
+#### What is Osmosis?
 
 [Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
 

From 3fe2200e9b094dcd60e6f6c3ec4d831c6bc9b58b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 12:28:04 -0500
Subject: [PATCH 3595/3820] New translations avoid-eth-calls.mdx (Russian)

---
 .../ru/subgraphs/cookbook/avoid-eth-calls.mdx | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx
index 0c55df6e4852..02bbb2fe0938 100644
--- a/website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx
+++ b/website/pages/ru/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -1,16 +1,16 @@
 ---
-title: Subgraph Best Practice 4 - Improve Indexing Speed by Avoiding eth_calls
+title: Лучшая практика субграфа 4 — увеличение скорости индексирования за счет избегания eth_calls
 ---
 
 ## Краткое содержание
 
-`eth_calls` are calls that can be made from a subgraph to an Ethereum node. These calls take a significant amount of time to return data, slowing down indexing. If possible, design smart contracts to emit all the data you need so you don’t need to use `eth_calls`.
+`eth_calls` — это вызовы, которые могут выполняться из субграфа к ноде Ethereum. Эти вызовы требуют значительного количества времени для возврата данных, что замедляет индексирование. По возможности, проектируйте смарт-контракты так, чтобы они отправляли все необходимые Вам данные, чтобы избежать использования `eth_calls`.
 
-## Why Avoiding `eth_calls` Is a Best Practice
+## Почему избегание `eth_calls` является наилучшей практикой
 
-Subgraphs are optimized to index event data emitted from smart contracts. A subgraph can also index the data coming from an `eth_call`, however, this can significantly slow down subgraph indexing as `eth_calls` require making external calls to smart contracts. The responsiveness of these calls relies not on the subgraph but on the connectivity and responsiveness of the Ethereum node being queried. By minimizing or eliminating eth_calls in our subgraphs, we can significantly improve our indexing speed.
+Субграфы оптимизированы для индексирования данных событий, которые исходят из смарт-контрактов. Субграф также может индексировать данные из `eth_call`, однако это значительно замедляет процесс индексирования, так как `eth_calls` требуют выполнения внешних вызовов к смарт-контрактам. Скорость реагирования этих вызовов зависит не от субграфа, а от подключения и скорости ответа ноды Ethereum, к которой отправлен запрос. Минимизируя или полностью исключая `eth_calls` в наших субграфах, мы можем значительно повысить скорость индексирования.
 
-### What Does an eth_call Look Like?
+### Что из себя представляет eth_call?
 
 `eth_calls` часто необходимы, когда данные, требуемые для субграфа, недоступны через сгенерированные события. Например, рассмотрим ситуацию, когда субграфу нужно определить, являются ли токены ERC20 частью определенного пула, но контракт генерирует только базовое событие `Transfer` и не создает событие, содержащее нужные нам данные:
 
@@ -43,11 +43,11 @@ export function handleTransfer(event: Transfer): void {
 }
 ```
 
-This is functional, however is not ideal as it slows down our subgraph’s indexing.
+Это функционально, однако не идеально, так как замедляет индексирование нашего субграфа.
 
-## How to Eliminate `eth_calls`
+## Как устранить `eth_calls`
 
-Ideally, the smart contract should be updated to emit all necessary data within events. For instance, modifying the smart contract to include pool information in the event could eliminate the need for `eth_calls`:
+В идеале смарт-контракт должен быть обновлён, чтобы эмитировать все необходимые данные внутри событий. Например, модификация смарт-контракта для включения информации о пуле в событие может устранить необходимость в `eth_calls`:
 
 ```
 event TransferWithPool(address indexed from, address indexed to, uint256 value, bytes32 indexed poolInfo);
@@ -72,13 +72,13 @@ export function handleTransferWithPool(event: TransferWithPool): void {
 }
 ```
 
-This is much more performant as it has eliminated the need for `eth_calls`.
+Это значительно повышает производительность, так как устраняет потребность в `eth_calls`.
 
 ## Как оптимизировать `eth_calls`
 
-If modifying the smart contract is not possible and `eth_calls` are required, read “[Improve Subgraph Indexing Performance Easily: Reduce eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)” by Simon Emanuel Schmid to learn various strategies on how to optimize `eth_calls`.
+Если изменение смарт-контракта невозможно, и `eth_calls` необходимы, прочитайте статью "[Как легко улучшить производительность индексирования субграфа: сокращение eth_calls](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/)" Саймона Эмануэля Шмида, чтобы изучить различные стратегии оптимизации `eth_calls`.
 
-## Reducing the Runtime Overhead of `eth_calls`
+## Сокращение времени выполнения `eth_calls`
 
 Для тех `eth_calls`, которые нельзя устранить, накладные расходы на их выполнение можно минимизировать, объявив их в манифесте. Когда `graph-node` обрабатывает блок, все объявленные `eth_calls` выполняются параллельно до запуска обработчиков. Вызовы, не объявленные в манифесте, выполняются последовательно во время работы обработчиков. Улучшение производительности достигается за счет параллельного выполнения вызовов, а не последовательного, что помогает сократить общее время, затраченное на вызовы, но не устраняет его полностью.
 
@@ -93,7 +93,7 @@ calls:
 
 Часть, выделенная желтым, — это объявление вызова. Часть до двоеточия — это текстовая метка, которая используется только в сообщениях об ошибках. Часть после двоеточия имеет форму `Contract[address].function(params)`. Допустимыми значениями для адреса и параметров являются `event.address` и `event.params.<name>`.
 
-The handler itself accesses the result of this `eth_call` exactly as in the previous section by binding to the contract and making the call. graph-node caches the results of declared `eth_calls` in memory and the call from the handler will retrieve the result from this in memory cache instead of making an actual RPC call.
+Обработчик сам получает результат этого `eth_call`, как и в предыдущем разделе, привязываясь к контракту и выполняя вызов. `graph-node` кеширует результаты объявленных `eth_calls` в памяти, а вызов из обработчика будет извлекать результат из этого кеша в памяти, вместо того чтобы выполнять фактический RPC-вызов.
 
 Примечание: Объявленные `eth_calls` могут быть выполнены только в субграфах с версией спецификации >= 1.2.0.
 

From f66ff6d6fecfd3a899604b0afdeb2dd6c4a63ae0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 12:28:06 -0500
Subject: [PATCH 3596/3820] New translations derivedfrom.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/derivedfrom.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx b/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
index b567d0d0c03d..5f41c2f41bc0 100644
--- a/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
@@ -1,5 +1,5 @@
 ---
-title: Subgraph Best Practice 2 - Improve Indexing and Query Responsiveness By Using @derivedFrom
+title: Лучшая практика для субграфов 2 — улучшение индексирования и отклика на запросы с помощью @derivedFrom
 ---
 
 ## Краткое содержание

From 3f6f252373487431c365f4e1f037457a569b3a5f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Fri, 7 Feb 2025 14:48:19 -0500
Subject: [PATCH 3597/3820] New translations billing.mdx (Spanish)

---
 website/pages/es/subgraphs/billing.mdx | 158 ++++++++++++-------------
 1 file changed, 79 insertions(+), 79 deletions(-)

diff --git a/website/pages/es/subgraphs/billing.mdx b/website/pages/es/subgraphs/billing.mdx
index bc6df180342a..df1b324f5010 100644
--- a/website/pages/es/subgraphs/billing.mdx
+++ b/website/pages/es/subgraphs/billing.mdx
@@ -2,56 +2,56 @@
 title: Facturación
 ---
 
-## Querying Plans
+## Planes de consultas
 
-There are two plans to use when querying subgraphs on The Graph Network.
+Existen dos planes para usar al consultar subgrafos en The Graph Network.
 
-- **Free Plan**: The Free Plan includes 100,000 free monthly queries with full access to the Subgraph Studio testing environment. This plan is designed for hobbyists, hackathoners, and those with side projects to try out The Graph before scaling their dapp.
+- **Plan Gratuito**: El Plan Gratuito incluye 100.000 consultas mensuales gratuitas con acceso completo al entorno de pruebas de Subgraph Studio. Este plan está diseñado para aficionados, participantes de hackatones y aquellos con proyectos paralelos que deseen probar The Graph antes de escalar su dapp.
 
-- **Growth Plan**: The Growth Plan includes everything in the Free Plan with all queries after 100,000 monthly queries requiring payments with GRT or credit card. The Growth Plan is flexible enough to cover teams that have established dapps across a variety of use cases.
+- Plan de Expansión: El Plan de Expansión incluye todo lo que ofrece el Plan Gratuito, pero todas las consultas que excedan las 100.000 consultas mensuales requieren pagos con GRT o tarjeta de crédito. El Plan de Expansión es lo suficientemente flexible como para cubrir las necesidades de equipos con dapps consolidadas en una variedad de casos de uso.
 
 <VideoEmbed youtube="Nn771WagX2I" />
 
-## Query Payments with credit card
+## Pagos de consultas con tarjeta de crédito
 
-- To set up billing with credit/debit cards, users should access Subgraph Studio (https://thegraph.com/studio/)
-  1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+- Para configurar la facturación con tarjetas de crédito/débito, los usuarios deben acceder a Subgraph Studio (https://thegraph.com/studio/)
+  1. Ve a la [página de facturación de Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
   2. Haz clic en el botón "Conectar wallet" en la esquina superior derecha de la página. Serás redirigido a la página de selección de wallet. Selecciona tu wallet y haz clic en "Conectar".
-  3. Choose “Upgrade plan” if you are upgrading from the Free Plan or choose “Manage Plan” if you have already added GRT to your billing balance in the past. Next, you can estimate the number of queries to get a pricing estimate, but this is not a required step.
-  4. To choose a credit card payment, choose “Credit card” as the payment method and fill out your credit card information. Those who have used Stripe before can use the Link feature to autofill their details.
-- Invoices will be processed at the end of each month and require an active credit card on file for all queries beyond the free plan quota.
+  3. Elige "Mejorar plan" si estás actualizando desde el Plan Gratuito, o selecciona "Gestionar plan" si ya has agregado GRT a tu saldo de facturación anteriormente. A continuación, puedes estimar la cantidad de consultas para obtener una estimación de precios, aunque este paso no es obligatorio.
+  4. Para elegir el pago con tarjeta de crédito, selecciona "Tarjeta de crédito" como método de pago y completa la información de tu tarjeta. Aquellos que hayan utilizado Stripe anteriormente pueden usar la función Link para completar sus datos automáticamente.
+- Las facturas se procesarán al final de cada mes y requieren una tarjeta de crédito activa registrada para todas las consultas que excedan la cuota del plan gratuito.
 
-## Query Payments with GRT
+## Pago de consultas con GRT
 
-Subgraph users can use The Graph Token (or GRT) to pay for queries on The Graph Network. With GRT, invoices will be processed at the end of each month and require a sufficient balance of GRT to make queries beyond the Free Plan quota of 100,000 monthly queries. You'll be required to pay fees generated from your API keys. Using the billing contract, you'll be able to:
+Los usuarios de subgrafos pueden usar The Graph Token (GRT) para pagar las consultas en The Graph Network. Con GRT, las facturas se procesarán al final de cada mes y será necesario contar con un saldo suficiente de GRT para realizar consultas que excedan la cuota del Plan Gratuito de 100.000 consultas mensuales. También deberás cubrir las tarifas generadas por tus claves de API. A través del contrato de facturación, podrás:
 
 - Agregar y retirar GRT de tu saldo de cuenta.
 - Llevar un registro de tus saldos en función de la cantidad de GRT que hayas agregado a tu saldo de cuenta, la cantidad que hayas retirado y tus facturas.
 - Paga automáticamente las facturas basadas en las tarifas de consulta generadas, siempre y cuando haya suficiente GRT en tu saldo de cuenta.
 
-### GRT on Arbitrum or Ethereum
+### GRT en Arbitrum o Ethereum
 
-The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on Arbitrum to pay their gas. While The Graph protocol started on Ethereum Mainnet, all activity, including the billing contracts, is now on Arbitrum One.
+El sistema de facturación de The Graph acepta GRT en Arbitrum, y los usuarios necesitarán ETH en Arbitrum para pagar el gas. Aunque el protocolo de The Graph comenzó en Ethereum Mainnet, toda la actividad, incluidos los contratos de facturación, ahora se realiza en Arbitrum One.
 
-To pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
+Para pagar consultas, necesitas GRT en Arbitrum. Aquí tienes algunas formas de obtenerlo:
 
-- If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
+- Si ya tienes GRT en Ethereum, puedes enviarlo a Arbitrum mediante un puente. Puedes hacerlo a través de la opción de transferencia de GRT proporcionada en Subgraph Studio o utilizando uno de los siguientes puentes:
 
-- [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
+- [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
 
 - [TransferTo](https://transferto.xyz/swap)
 
-- If you already have assets on Arbitrum, you can swap them for GRT via a swapping protocol like Uniswap.
+- Si ya tienes activos en Arbitrum, puedes intercambiarlos por GRT a través de un protocolo de intercambio como Uniswap.
 
-- Alternatively, you acquire GRT directly on Arbitrum through a decentralized exchange.
+- Alternativamente, puedes adquirir GRT directamente en Arbitrum a través de un intercambio descentralizado.
 
-> This section is written assuming you already have GRT in your wallet, and you're on Arbitrum. If you don't have GRT, you can learn how to get GRT [here](#getting-grt).
+> Esta sección está redactada asumiendo que ya tienes GRT en tu wallet y que estás en Arbitrum. Si no tienes GRT, puedes aprender cómo obtenerlo [aquí](#getting-grt).
 
-Once you bridge GRT, you can add it to your billing balance.
+Una vez que transfieras GRT, puedes agregarlo a tu saldo de facturación.
 
-### Adding GRT using a wallet
+### Agregar GRT utilizando una wallet
 
-1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
+1. Ve a la [página de facturación de Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
 2. Haz clic en el botón "Conectar wallet" en la esquina superior derecha de la página. Serás redirigido a la página de selección de wallet. Selecciona tu wallet y haz clic en "Conectar".
 3. Selecciona el botón "Gestionar" en la esquina superior derecha. Los usuarios que acceden por primera vez verán la opción "Mejorar al Plan de Expansión", mientras que los usuarios recurrentes deberán hacer clic en "Depositar desde la wallet".
 4. Utiliza la barra deslizante para estimar la cantidad de consultas que esperas realizar mensualmente.
@@ -60,49 +60,49 @@ Once you bridge GRT, you can add it to your billing balance.
 6. Selecciona la cantidad de meses que deseas pagar por adelantado.
    - Pagar por adelantado no te compromete a un uso futuro. Solo se te cobrará por lo que utilices, y puedes retirar tu saldo en cualquier momento.
 7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable.
-8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
-   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
-9. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+8. Haz clic en "Permitir acceso a GRT" y luego especifica la cantidad de GRT que se puede tomar de tu wallet.
+   - Si estás pagando por adelantado varios meses, debes permitirle acceso a la cantidad que corresponde con ese monto. Esta interacción no tendrá costo de gas.
+9. Por último, haz clic en "Agregar GRT al saldo de facturación". Esta transacción requerirá ETH en Arbitrum para cubrir los costos de gas.
 
-- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+- Ten en cuenta que los depósitos de GRT desde Arbitrum se procesarán en apenas un momento, mientras que los depósitos de GRT desde Ethereum tardarán aproximadamente 15-20 minutos en procesarse. Una vez que la transacción sea confirmada, verás el GRT agregado a tu saldo de cuenta.
 
-### Withdrawing GRT using a wallet
+### Retirar GRT utilizando una wallet
 
-1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
-2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect".
-3. Click the "Manage" button at the top right corner of the page. Select "Withdraw GRT". A side panel will appear.
-4. Enter the amount of GRT you would like to withdraw.
-5. Click 'Withdraw GRT' to withdraw the GRT from your account balance. Sign the associated transaction in your wallet. This will cost gas. The GRT will be sent to your Arbitrum wallet.
-6. Once the transaction is confirmed, you'll see the GRT withdrawn from your account balance in your Arbitrum wallet.
+1. Ve a la [página de facturación de Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
+2. Haz clic en el botón "Conectar Wallet" en la esquina superior derecha de la página. Selecciona tu wallet y luego haz clic en "Conectar".
+3. Haz clic en el botón "Administrar" en la esquina superior derecha de la página. Selecciona "Retirar GRT". Aparecerá un panel lateral.
+4. Ingresa la cantidad de GRT que deseas retirar.
+5. Haz clic en "Retirar GRT" para retirar el GRT de tu saldo de cuenta. Firma la transacción asociada en tu wallet. Esto tendrá un costo de gas. El GRT se enviará a tu wallet en Arbitrum.
+6. Una vez que la transacción sea confirmada, verás el GRT retirado de tu saldo de cuenta en tu wallet de Arbitrum.
 
 ### Añadir GRT utilizando una wallet multisig
 
-1. Go to the [Subgraph Studio Billing page](https://thegraph.com/studio/subgraphs/billing/).
-2. Click on the "Connect Wallet" button on the top right corner of the page. Select your wallet and click on "Connect". If you're using [Gnosis-Safe](https://gnosis-safe.io/), you'll be able to connect your multisig as well as your signing wallet. Then, sign the associated message. This will not cost any gas.
+1. Ve a la [página de facturación de Subgraph Studio](https://thegraph.com/studio/subgraphs/billing/).
+2. Haz clic en el botón "Conectar Wallet" en la esquina superior derecha de la página. Selecciona tu wallet y haz clic en "Conectar". Si estás utilizando [Gnosis-Safe](https://gnosis-safe.io/), podrás conectar tanto tu multisig como tu wallet firmante. Luego, firma el mensaje asociado. Esto no tendrá ningún costo de gas.
 3. Selecciona el botón "Gestionar" en la esquina superior derecha. Los usuarios que acceden por primera vez verán la opción "Mejorar al Plan de Expansión", mientras que los usuarios recurrentes deberán hacer clic en "Depositar desde la wallet".
 4. Utiliza la barra deslizante para estimar la cantidad de consultas que esperas realizar mensualmente.
    - Para obtener sugerencias sobre la cantidad de consultas que podrías usar, consulta nuestra página de Preguntas Frecuentes.
 5. Selecciona "Cripto". Actualmente, GRT es la única criptomoneda aceptada en The Graph Network.
 6. Selecciona la cantidad de meses que deseas pagar por adelantado.
    - Pagar por adelantado no te compromete a un uso futuro. Solo se te cobrará por lo que utilices, y puedes retirar tu saldo en cualquier momento.
-7. Pick the network from which you are depositing your GRT. GRT on Arbitrum or Ethereum are both acceptable. 8. Click "Allow GRT Access" and then specify the amount of GRT that can be taken from you wallet.
-   - If you are prepaying for multiple months, you must allow access to the amount that corresponds with that amount. This interaction will not cost any gas.
-8. Lastly, click on "Add GRT to Billing Balance". This transaction will require ETH on Arbitrum to cover the gas costs.
+7. Selecciona la red desde la cual estás depositando tu GRT. Tanto GRT en Arbitrum como en Ethereum son aceptables. 8. Haz clic en "Permitir acceso a GRT" y luego especifica la cantidad de GRT que se puede tomar de tu billetera.
+   - Si estás pagando por adelantado varios meses, debes permitirle acceso a la cantidad que corresponde con ese monto. Esta interacción no tendrá costo de gas.
+8. Por último, haz clic en "Agregar GRT al saldo de facturación". Esta transacción requerirá ETH en Arbitrum para cubrir los costos de gas.
 
-- Note that GRT deposited from Arbitrum will process within a few moments while GRT deposited from Ethereum will take approximately 15-20 minutes to process. Once the transaction is confirmed, you'll see the GRT added to your account balance.
+- Ten en cuenta que los depósitos de GRT desde Arbitrum se procesarán en apenas un momento, mientras que los depósitos de GRT desde Ethereum tardarán aproximadamente 15-20 minutos en procesarse. Una vez que la transacción sea confirmada, verás el GRT agregado a tu saldo de cuenta.
 
-## Getting GRT
+## Obtener GRT
 
-This section will show you how to get GRT to pay for query fees.
+Esta sección te mostrará cómo obtener GRT para pagar las tarifas de consulta.
 
 ### Coinbase
 
-This will be a step by step guide for purchasing GRT on Coinbase.
+Esta será una guía paso a paso para comprar GRT en Coinbase.
 
-1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
-2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
-3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy/Sell" button on the top right of the page.
-4. Select the currency you want to purchase. Select GRT.
+1. Ve a [Coinbase](https://www.coinbase.com/) y crea una cuenta.
+2. Una vez que hayas creado una cuenta, necesitarás verificar tu identidad a través de un proceso conocido como KYC (o Conoce a tu Cliente). Este es un procedimiento estándar para todos los intercambios de criptomonedas centralizados o con custodia de activos.
+3. Una vez que hayas verificado tu identidad, puedes comprar GRT. Para hacerlo, haz clic en el botón "Comprar/Vender" en la parte superior derecha de la página.
+4. Selecciona la moneda que deseas comprar. Selecciona GRT.
 5. Select the payment method. Select your preferred payment method.
 6. Select the amount of GRT you want to purchase.
 7. Review your purchase. Review your purchase and click "Buy GRT".
@@ -120,7 +120,7 @@ You can learn more about getting GRT on Coinbase [here](https://help.coinbase.co
 This will be a step by step guide for purchasing GRT on Binance.
 
 1. Go to [Binance](https://www.binance.com/en) and create an account.
-2. Once you have created an account, you will need to verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+2. Una vez que hayas creado una cuenta, necesitarás verificar tu identidad a través de un proceso conocido como KYC (o Conoce a tu Cliente). Este es un procedimiento estándar para todos los intercambios de criptomonedas centralizados o con custodia de activos.
 3. Once you have verified your identity, you can purchase GRT. You can do this by clicking on the "Buy Now" button on the homepage banner.
 4. You will be taken to a page where you can select the currency you want to purchase. Select GRT.
 5. Select your preferred payment method. You'll be able to pay with different fiat currencies such as Euros, US Dollars, and more.
@@ -157,58 +157,58 @@ This section will show you how to get Ether (ETH) to pay for transaction fees or
 
 This will be a step by step guide for purchasing ETH on Coinbase.
 
-1. Go to [Coinbase](https://www.coinbase.com/) and create an account.
-2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
+1. Ve a [Coinbase](https://www.coinbase.com/) y crea una cuenta.
+2. Una vez que hayas creado una cuenta, verifica tu identidad a través de un proceso conocido como KYC (o Conoce a tu Cliente). Este es un procedimiento estándar para todos los exchanges centralizados o que mantienen custodia de criptomonedas.
 3. Once you have verified your identity, purchase ETH by clicking on the "Buy/Sell" button on the top right of the page.
-4. Select the currency you want to purchase. Select ETH.
-5. Select your preferred payment method.
-6. Enter the amount of ETH you want to purchase.
-7. Review your purchase and click "Buy ETH".
+4. Selecciona la moneda que deseas comprar. Elige ETH.
+5. Selecciona tu método de pago preferido.
+6. Ingresa la cantidad de ETH que deseas comprar.
+7. Revisa tu compra y haz clic en "Comprar ETH".
 8. Confirm your purchase and you will have successfully purchased ETH.
 9. You can transfer the ETH from your Coinbase account to your wallet such as [MetaMask](https://metamask.io/).
    - To transfer the ETH to your wallet, click on the "Accounts" button on the top right of the page.
-   - Click on the "Send" button next to the ETH account.
-   - Enter the amount of ETH you want to send and the wallet address you want to send it to.
-   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
-   - Click "Continue" and confirm your transaction.
+   - Haz clic en el botón "Enviar" junto a la cuenta de ETH.
+   - Ingresa la cantidad de ETH que deseas enviar y la dirección de la wallet a la que quieres enviarlo.
+   - Asegúrate de que estás enviando a la dirección de tu wallet de Ethereum en Arbitrum One.
+   - Haz clic en "Continuar" y confirma tu transacción.
 
-You can learn more about getting ETH on Coinbase [here](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
+Puedes obtener más información sobre cómo adquirir ETH en Coinbase [aquí](https://help.coinbase.com/en/coinbase/trading-and-funding/buying-selling-or-converting-crypto/how-do-i-buy-digital-currency).
 
 ### Binance
 
-This will be a step by step guide for purchasing ETH on Binance.
+Esta será una guía paso a paso para comprar ETH en Binance.
 
 1. Go to [Binance](https://www.binance.com/en) and create an account.
-2. Once you have created an account, verify your identity through a process known as KYC (or Know Your Customer). This is a standard procedure for all centralized or custodial crypto exchanges.
-3. Once you have verified your identity, purchase ETH by clicking on the "Buy Now" button on the homepage banner.
-4. Select the currency you want to purchase. Select ETH.
-5. Select your preferred payment method.
-6. Enter the amount of ETH you want to purchase.
-7. Review your purchase and click "Buy ETH".
+2. Una vez que hayas creado una cuenta, verifica tu identidad a través de un proceso conocido como KYC (o Conoce a tu Cliente). Este es un procedimiento estándar para todos los exchanges centralizados o que mantienen custodia de criptomonedas.
+3. Una vez que hayas verificado tu identidad, compra ETH haciendo clic en el botón "Comprar ahora" en el banner de la página de inicio.
+4. Selecciona la moneda que deseas comprar. Elige ETH.
+5. Selecciona tu método de pago preferido.
+6. Ingresa la cantidad de ETH que deseas comprar.
+7. Revisa tu compra y haz clic en "Comprar ETH".
 8. Confirm your purchase and you will see your ETH in your Binance Spot Wallet.
 9. You can withdraw the ETH from your account to your wallet such as [MetaMask](https://metamask.io/).
-   - To withdraw the ETH to your wallet, add your wallet's address to the withdrawal whitelist.
+   - Para retirar el ETH a tu wallet, añade la dirección de tu wallet a la lista de direcciones autorizadas para retiros.
    - Click on the "wallet" button, click withdraw, and select ETH.
    - Enter the amount of ETH you want to send and the whitelisted wallet address you want to send it to.
-   - Ensure that you are sending to your Ethereum wallet address on Arbitrum One.
-   - Click "Continue" and confirm your transaction.
+   - Asegúrate de que estás enviando a la dirección de tu wallet de Ethereum en Arbitrum One.
+   - Haz clic en "Continuar" y confirma tu transacción.
 
-You can learn more about getting ETH on Binance [here](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
+Puedes obtener más información sobre cómo adquirir ETH en Binance [aquí](https://www.binance.com/en/support/faq/how-to-buy-cryptocurrency-on-binance-homepage-400c38f5e0cd4b46a1d0805c296b5582).
 
-## Billing FAQs
+## Preguntas Frecuentes sobre Facturación
 
-### How many queries will I need?
+### ¿Cuántas consultas necesitaré?
 
-You don't need to know how many queries you'll need in advance. You will only be charged for what you use and you can withdraw GRT from your account at any time.
+No necesitas saber cuántas consultas necesitarás de antemano. Solo se te cobrará por lo que uses y podrás retirar GRT de tu cuenta en cualquier momento.
 
-We recommend you overestimate the number of queries you will need so that you don’t have to top up your balance frequently. A good estimate for small to medium sized applications is to start with 1M-2M queries per month and monitor usage closely in the first weeks. For larger apps, a good estimate is to use the number of daily visits your site gets multiplied by the number of queries your most active page makes upon opening.
+Te recomendamos sobreestimar la cantidad de consultas que necesitarás para no tener que recargar tu saldo con frecuencia. Una buena estimación para aplicaciones pequeñas a medianas es comenzar con 1M-2M de consultas por mes y monitorear el uso de cerca en las primeras semanas. Para aplicaciones más grandes, una buena estimación es usar el número de visitas diarias que recibe tu sitio multiplicado por el número de consultas que hace la página más activa al abrirse.
 
-Of course, both new and existing users can reach out to Edge & Node's BD team for a consult to learn more about anticipated usage.
+Por supuesto, tanto los usuarios nuevos como los existentes pueden ponerse en contacto con el equipo de BD de Edge & Node para una consulta y aprender más sobre el uso anticipado.
 
-### Can I withdraw GRT from my billing balance?
+### ¿Puedo retirar GRT de mi saldo de facturación?
 
-Yes, you can always withdraw GRT that has not already been used for queries from your billing balance. The billing contract is only designed to bridge GRT from Ethereum mainnet to the Arbitrum network. If you'd like to transfer your GRT from Arbitrum back to Ethereum mainnet, you'll need to use the [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
+Sí, siempre puedes retirar GRT que no haya sido utilizado para consultas de tu saldo de facturación. El contrato de facturación está diseñado únicamente para transferir GRT de la red principal de Ethereum a la red de Arbitrum. Si deseas transferir tu GRT de Arbitrum de vuelta a la red principal de Ethereum, necesitarás utilizar el [Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161).
 
-### What happens when my billing balance runs out? Will I get a warning?
+### ¿Qué sucede cuando se agota mi saldo de facturación? ¿Recibiré una advertencia?
 
-You will receive several email notifications before your billing balance runs out.
+Recibirás varias notificaciones por correo electrónico antes de que se agote tu saldo de facturación.

From 4903d9105e40b652b6378b6bdc8d82fd2fdd467a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 11:01:25 -0500
Subject: [PATCH 3598/3820] New translations grafting.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/cookbook/grafting.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/subgraphs/cookbook/grafting.mdx b/website/pages/zh/subgraphs/cookbook/grafting.mdx
index ac570d8c20d5..321b5b115bec 100644
--- a/website/pages/zh/subgraphs/cookbook/grafting.mdx
+++ b/website/pages/zh/subgraphs/cookbook/grafting.mdx
@@ -40,7 +40,7 @@ Grafting is a powerful feature that allows you to "graft" one subgraph onto anot
 
 By adhering to these guidelines, you minimize risks and ensure a smoother migration process.
 
-## 构建现有子图
+## Building an Existing Subgraph
 
 Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
 
@@ -117,7 +117,7 @@ The `base` and `block` values can be found by deploying two subgraphs: one for t
 }
 ```
 
-它返回的结果是这样的:
+It returns something like this:
 
 ```
 {

From 97f0cd899266f2701a7abe2c9b1254e5e43a9b3b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 12:36:30 -0500
Subject: [PATCH 3599/3820] New translations avoid-eth-calls.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx
index b6a79c5ae608..ee1dae22d6bc 100644
--- a/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx
+++ b/website/pages/tr/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -113,4 +113,4 @@ Subgraph'lerinizde `eth_calls`'ı en aza indirerek endeksleme performansını ö
 
 5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Aşılama Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From 92eb764a306a68f2cf5ea2360b5a70103b564916 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 12:36:31 -0500
Subject: [PATCH 3600/3820] New translations derivedfrom.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/derivedfrom.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
index ca0c60f7679d..65abf1743860 100644
--- a/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/tr/subgraphs/cookbook/derivedfrom.mdx
@@ -85,4 +85,4 @@ Büyük dizilerden kaçınma stratejilerinin daha ayrıntılı bir açıklaması
 
 5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Aşılama Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From 4f314286f00558d589d24d93d0850ff388e2da02 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 12:36:32 -0500
Subject: [PATCH 3601/3820] New translations grafting-hotfix.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/grafting-hotfix.mdx    | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
index fb16051501ae..35e008f80061 100644
--- a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
@@ -4,17 +4,17 @@ title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
 
 ## Özet
 
-Graftlama, mevcut endekslenmiş verileri yeniden kullanarak yeni subgraph'ler oluşturmanıza ve dağıtmanıza olanak tanıyan güçlü bir özelliktir.
+Aşılama, mevcut endekslenmiş verileri yeniden kullanarak yeni subgraph'ler oluşturmanıza ve dağıtmanıza olanak tanıyan güçlü bir özelliktir.
 
 ### Genel Bakış
 
-Bu özellik, kritik sorunlar için hızlı bir şekilde düzeltmelerin dağıtılmasını sağlar ve tüm subgraph'i baştan endeksleme ihtiyacını ortadan kaldırır. Graftlama, tarihsel verileri koruyarak kesinti sürelerini en aza indirir ve veri hizmetlerinde süreklilik sağlar.
+Bu özellik, kritik sorunlar için hızlı bir şekilde düzeltmelerin dağıtılmasını sağlar ve tüm subgraph'i baştan endeksleme ihtiyacını ortadan kaldırır. Aşılama, tarihsel verileri koruyarak kesinti sürelerini en aza indirir ve veri hizmetlerinde süreklilik sağlar.
 
-## Hızlı Düzeltmelerde Graftlamanın Avantajları
+## Benefits of Grafting for Hotfixes
 
 1. **Hızlı Dağıtım**
 
-   - **Kesinti Süresini En Aza İndirme**: Bir subgraph kritik bir hata ile karşılaştığında ve endekslemeyi durdurduğunda, graftlama sayesinde yeniden endekslemeyi beklemeden hemen bir düzeltme dağıtabilirsiniz.
+   - **Kesinti Süresini En Aza İndirme**: Bir subgraph kritik bir hata ile karşılaştığında ve endekslemeyi durdurduğunda, aşılama sayesinde yeniden endekslemeyi beklemeden hemen bir düzeltme dağıtabilirsiniz.
    - **Hızlıca Kurtarma**: Yeni subgraph, son endekslenmiş bloktan devam eder ve veri hizmetlerinin kesintisiz olmasını sağlar.
 
 2. **Veri Koruma**
@@ -183,4 +183,4 @@ By incorporating grafting into your subgraph development workflow, you can enhan
 
 5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Aşılama Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From f35a7216a62764d87f98638b3fc4e2ec020c854c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 12:36:33 -0500
Subject: [PATCH 3602/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
index dacc003d2a2c..d991e70bf956 100644
--- a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -187,4 +187,4 @@ Read more about using Immutable Entities and Bytes as IDs in this blog post by D
 
 5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Aşılama Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From d89fe99ccff5abd8669e13c14858690fc8732fef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 12:36:34 -0500
Subject: [PATCH 3603/3820] New translations pruning.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/pruning.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/pruning.mdx b/website/pages/tr/subgraphs/cookbook/pruning.mdx
index 47449b6437a3..0c3f587adb33 100644
--- a/website/pages/tr/subgraphs/cookbook/pruning.mdx
+++ b/website/pages/tr/subgraphs/cookbook/pruning.mdx
@@ -52,4 +52,4 @@ Pruning using `indexerHints` is a best practice for subgraph development, offeri
 
 5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Aşılama Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From a8e4d3d5a4b52300484bbfdac550709ba1e29f4c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 12:36:35 -0500
Subject: [PATCH 3604/3820] New translations timeseries.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/timeseries.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/timeseries.mdx b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
index 83ccc8cacfa8..0496637dd169 100644
--- a/website/pages/tr/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
@@ -191,4 +191,4 @@ By adopting this pattern, developers can build more efficient and scalable subgr
 
 5. [Zaman Serileri ve Bütünleştirme ile Basitleştirin ve Optimize Edin](/subgraphs/cookbook/timeseries/)
 
-6. [Hızlı Düzeltme Dağıtımı için Grafting Kullanın](/subgraphs/cookbook/grafting-hotfix/)
+6. [Hızlı Düzeltme Dağıtımı için Aşılama Kullanın](/subgraphs/cookbook/grafting-hotfix/)

From fd78a87e4d948493ae44b75d475f7ba6b545b110 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 12:36:36 -0500
Subject: [PATCH 3605/3820] New translations assemblyscript-migration-guide.mdx
 (Turkish)

---
 .../assemblyscript-migration-guide.mdx        | 214 +++++++++---------
 1 file changed, 107 insertions(+), 107 deletions(-)

diff --git a/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx
index a8bb2e376807..7c75050c0696 100644
--- a/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -1,50 +1,50 @@
 ---
-title: AssemblyScript Migration Guide
+title: AssemblyScript Geçiş Rehberi
 ---
 
-Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+Şu ana kadar subgraph'ler, [AssemblyScript'in ilk versiyonlarından birini](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6) kullanıyordu. Nihayet, [en yeni versiyonu](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10) için destek ekledik! 🎉
 
-That will enable subgraph developers to use newer features of the AS language and standard library.
+Bu, subgraph geliştiricilerinin AS dilinin ve standart kütüphanenin daha yeni özelliklerini kullanmasını sağlayacak.
 
-This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+Bu rehber, `graph-cli`/`graph-ts` araçlarının `0.22.0` ve öncesi versiyonlarını kullanan herkes için geçerlidir. Eğer halihazırda bu versiyonun üstünde (veya ona eşit) bir versiyon kullanıyorsanız, zaten AssemblyScript'in `0.19.10` versiyonunu kullanıyorsunuz demektir 🙂
 
-> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+> Not: `0.24.0` itibarıyla, `graph-node`, subgraph manifestosunda belirtilen `apiVersion`'e bağlı olarak her iki versiyonu da destekleyebilir.
 
-## Features
+## Özellikler
 
-### New functionality
+### Yeni işlevsellik
 
-- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
-- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
-- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
-- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
-- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
-- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
-- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
-- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
-- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
-- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
-- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
-- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
-- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+- `TypedArray`'ler artık [`wrap` isimli yeni statik metot](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1)) kullanılarak `ArrayBuffer`'lardan oluşturulabilir
+- Yeni standart kütüphane fonksiyonları: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare` ve `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- GenericClass'in bir örneğini doğrulamak için x instanceof GenericClass desteği eklendi ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Daha verimli bir dizi çeşidi olan `StaticArray<T>` eklendi, ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- `Array<T>#flat` eklendi ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- `Number#toString` fonksiyonunda `radix` argümanı desteklenmeye başlandı ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Kayan nokta literallerinde ayırıcılar için destek eklendi ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- İlk sınıf fonksiyonlar için destek eklendi ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Yerleşikler eklendi: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- `Array/TypedArray/String#at`' fonksiyonu geliştirildi ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Şablon literal dizeleri için destek eklendi ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- `encodeURI(Component)` ve `decodeURI(Component)` eklendi ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- `toString`, `toDateString` ve `toTimeString` metodları `Date`'e eklendi ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- `Date` için `toUTCString` eklendi ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- `nonnull/NonNullable` yerleşik türü eklendi ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
 
-### Optimizations
+### Optimizasyonlar
 
-- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
-- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
-- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- `Math` fonksiyonları olan `exp`, `exp2`, `log`, `log2` ve `pow`, daha hızlı varyantlarla değiştirildi ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- `Math.mod`' fonksiyonu biraz optimize edildi ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- std Map ve Set'te daha fazla alan erişiminin önbelleğe alınması sağlandı ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- İkinin katları için `ipow32/64` optimizasyonu ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
 
-### Other
+### Diğer
 
-- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Bir dizi literalinin türü artık içeriğinden çıkarsanabilir ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- stdlib Unicode 13.0.0'a güncellendi ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
 
-## How to upgrade?
+## Nasıl yükseltilir?
 
-1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+1. Eşlemlerinizdeki `apiVersion` değerini `subgraph.yaml` dosyasında `0.0.6` olarak değiştirin:
 
 ```yaml
 ...
@@ -56,30 +56,30 @@ dataSources:
       ...
 ```
 
-2. Update the `graph-cli` you're using to the `latest` version by running:
+2. Kullanmakta olduğunuz `graph-cli`yi `latest` (en son) sürüme güncellemek için şu komutu çalıştırın:
 
 ```bash
-# if you have it globally installed
-npm install --global @graphprotocol/graph-cli@latest
+# Eğer `graph-cli` global olarak yüklüyse
+npm install --global @graphprotocol/graph-cli@latest 
 
-# or in your subgraph if you have it as a dev dependency
+# veya `subgraph` içinde bir geliştirme gereksinimi olarak yüklüyse
 npm install --save-dev @graphprotocol/graph-cli@latest
 ```
 
-3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+3. Aynısını `graph-ts` için de yapın, ancak global olarak kurmak yerine ana gereksinimlerinizde kaydedin:
 
 ```bash
 npm install --save @graphprotocol/graph-ts@latest
 ```
 
-4. Follow the rest of the guide to fix the language breaking changes.
-5. Run `codegen` and `deploy` again.
+4. Dildeki uyumsuzluk sorunlarını düzeltmek için rehberin geri kalanını takip edin.
+5. `codegen` ve `deploy` komutlarını tekrar çalıştırın.
 
-## Breaking changes
+## Uyumsuz değişiklikler
 
-### Nullability
+### Null olabilme durumu
 
-On the older version of AssemblyScript, you could create code like this:
+AssemblyScript'in eski bir sürümünde şu şekilde kod oluşturabilirdiniz:
 
 ```typescript
 function load(): Value | null { ... }
@@ -88,29 +88,29 @@ let maybeValue = load();
 maybeValue.aMethod();
 ```
 
-However on the newer version, because the value is nullable, it requires you to check, like this:
+Ancak, daha yeni sürümde değer null olabildiği için bunu kontrol etmenizi gerektirir, aşağıdaki gibi:
 
 ```typescript
 let maybeValue = load()
 
 if (maybeValue) {
-  maybeValue.aMethod() // `maybeValue` is not null anymore
+  maybeValue.aMethod() // `maybeValue` artık null değil
 }
 ```
 
-Or force it like this:
+Veya bunu şu şekilde zorlayın:
 
 ```typescript
-let maybeValue = load()! // breaks in runtime if value is null
+let maybeValue = load()! // Değer null ise çalıştırma esnasında hata verir
 
 maybeValue.aMethod()
 ```
 
-If you are unsure which to choose, we recommend always using the safe version. If the value doesn't exist you might want to just do an early if statement with a return in you subgraph handler.
+Emin olamadığınızda daima güvenli sürümü kullanmanızı öneririz. Değer mevcut değilse, subgraph işleyicinizde erken bir if kontrolü yaparak işlemi sonlandırabilirsiniz.
 
-### Variable Shadowing
+### Değişken Gölgeleme
 
-Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+Daha önce [değişken gölgeleme](https://en.wikipedia.org/wiki/Variable_shadowing) yapabiliyordunuz ve aşağıdaki gibi bir kod çalışıyordu:
 
 ```typescript
 let a = 10
@@ -118,7 +118,7 @@ let b = 20
 let a = a + b
 ```
 
-However now this isn't possible anymore, and the compiler returns this error:
+Ancak bu artık mümkün değil ve bu kodu derlemeye çalışırsanız derleyici şu hatayı verir:
 
 ```typescript
 ERROR TS2451: Cannot redeclare block-scoped variable 'a'
@@ -128,11 +128,11 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
 in assembly/index.ts(4,3)
 ```
 
-You'll need to rename your duplicate variables if you had variable shadowing.
+Eğer değişken gölgeleme yapıyorsanız, yinelenen değişkenlerinizi yeniden adlandırmanız gerekecek.
 
-### Null Comparisons
+### Null Karşılaştırmaları
 
-By doing the upgrade on your subgraph, sometimes you might get errors like these:
+Subgraph'inizi yükselttikten sonra bazı noktalarda şu tür hatalar alabilirsiniz:
 
 ```typescript
 ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
@@ -141,122 +141,122 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
  in src/mappings/file.ts(41,21)
 ```
 
-To solve you can simply change the `if` statement to something like this:
+Bu hatayı çözmek için `if` ifadesini şu şekilde değiştirebilirsiniz:
 
 ```typescript
   if (!decimals) {
 
-  // or
+  // veya
 
   if (decimals === null) {
 ```
 
-The same applies if you're doing != instead of ==.
+Aynısı == yerine != kullandığınızda da geçerlidir.
 
-### Casting
+### Dönüştürme
 
-The common way to do casting before was to just use the `as` keyword, like this:
+Önceden dönüştürme yapmanın yaygın yolu, `as` kelimesini şöyle kullanmaktı:
 
 ```typescript
 let byteArray = new ByteArray(10)
 let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
 ```
 
-However this only works in two scenarios:
+Ancak bu sadece iki senaryoda çalışır:
 
-- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
-- Upcasting on class inheritance (subclass → superclass)
+- Temel tür dönüşümü (`u8`, `i32`, `bool` gibi veri türleri arasında; örneğin: `let b: isize = 10; b as usize`);
+- Sınıf kalıtımında yukarı doğru dönüşüm (alt sınıf → üst sınıf)
 
 Örnekler:
 
 ```typescript
-// primitive casting
+// temel tür dönüşümü
 let a: usize = 10
 let b: isize = 5
 let c: usize = a + (b as usize)
 ```
 
 ```typescript
-// upcasting on class inheritance
+// sınıf kalıtımında yukarı doğru dönüşüm
 class Bytes extends Uint8Array {}
 
 let bytes = new Bytes(2)
-// <Uint8Array>bytes // same as: bytes as Uint8Array
+// <Uint8Array>bytes // // aynı şöyle: bytes as Uint8Array
 ```
 
-There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+`as`/`<T>var` kullanmanın **güvenli olmadığı** iki dönüşüm senaryosu vardır:
 
-- Downcasting on class inheritance (superclass → subclass)
-- Between two types that share a superclass
+- Sınıf kalıtımında aşağı doğru dönüşüm (üst sınıf → alt sınıf)
+- Ortak bir üst sınıfa sahip iki tür arasında dönüşüm
 
 ```typescript
-// downcasting on class inheritance
+// sınıf kalıtımında aşağı doğru dönüşüm
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-// <Bytes>uint8Array // breaks in runtime :(
+// <Bytes>uint8Array // çalıştırma esnasında kırılır :(
 ```
 
 ```typescript
-// between two types that share a superclass
+// aynı üst sınıfı paylaşan iki tür arasında
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
 let bytes = new Bytes(2)
-// <ByteArray>bytes // breaks in runtime :(
+// <ByteArray>bytes // çalıştırma esnasında kırılır :(
 ```
 
-For those cases, you can use the `changetype<T>` function:
+Bu durumlar için `changetype<T>` fonksiyonunu kullanabilirsiniz:
 
 ```typescript
-// downcasting on class inheritance
+// sınıf kalıtımında aşağı doğru dönüşüm
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-changetype<Bytes>(uint8Array) // works :)
+changetype<Bytes>(uint8Array) // çalışır :)
 ```
 
 ```typescript
-// between two types that share a superclass
+// Aynı üst sınıfı paylaşan iki tür arasında
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
 let bytes = new Bytes(2)
-changetype<ByteArray>(bytes) // works :)
+changetype<ByteArray>(bytes) // çalışır :)
 ```
 
-If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+Sadece null olabilmeyi kaldırmak istiyorsanız, `as` operatörünü (veya `<T>variable`) kullanmaya devam edebilirsiniz. Ancak değerin null olamayacağını bilmeniz gerekir. Aksi halde bu sorun yaratır.
 
 ```typescript
-// remove nullability
+// null olabilmeyi kaldırma
 let previousBalance = AccountBalance.load(balanceId) // AccountBalance | null
 
 if (previousBalance != null) {
-  return previousBalance as AccountBalance // safe remove null
+  return previousBalance as AccountBalance // güvenli null kaldırma
 }
 
 let newBalance = new AccountBalance(balanceId)
 ```
 
-For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+Null olabilme durumu için [null olabilme kontrolü özelliğine](https://www.assemblyscript.org/basics.html#nullability-checks) göz atmanızı öneririz. Bu özellikleri uygulamak, kodunuzu daha temiz hale getirecektir 🙂
 
-Also we've added a few more static methods in some types to ease casting, they are:
+Ayrıca, dönüştürme işlemlerini kolaylaştırmak için bazı türlere birkaç statik metot daha ekledik, bunlar:
 
 - Bytes.fromByteArray
 - Bytes.fromUint8Array
 - BigInt.fromByteArray
 - ByteArray.fromBigInt
 
-### Nullability check with property access
+### Özellik erişimi ile null olabilme kontrolü
 
-To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+[Null kontrolü özelliğini](https://www.assemblyscript.org/basics.html#nullability-checks) kullanmak için, `if` ifadelerini veya üçlü operatörünü (`?` ve `:`) şu şekilde kullanabilirsiniz:
 
 ```typescript
 let something: string | null = 'data'
 
 let somethingOrElse = something ? something : 'else'
 
-// or
+// veya
 
 let somethingOrElse
 
@@ -267,7 +267,7 @@ if (something) {
 }
 ```
 
-However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+Ancak bu yalnızca bir değişken üzerinde `if` / üçlü operatör kullandığınızda çalışır, bir özellik erişiminde değil:
 
 ```typescript
 class Container {
@@ -277,10 +277,10 @@ class Container {
 let container = new Container()
 container.data = 'data'
 
-let somethingOrElse: string = container.data ? container.data : 'else' // doesn't compile
+let somethingOrElse: string = container.data ? container.data : 'else' // derlemede hata verir
 ```
 
-Which outputs this error:
+Bu hata çıktısını verir:
 
 ```typescript
 ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/string/String'.
@@ -289,7 +289,7 @@ ERROR TS2322: Type '~lib/string/String | null' is not assignable to type '~lib/s
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ```
 
-To fix this issue, you can create a variable for that property access so that the compiler can do the nullability check magic:
+Bu hatayı çözmek için, özellik erişimini bir değişkene atayarak derleyicinin null kontrolünü yapabilmesini sağlayabilirsiniz:
 
 ```typescript
 class Container {
@@ -301,12 +301,12 @@ container.data = 'data'
 
 let data = container.data
 
-let somethingOrElse: string = data ? data : 'else' // compiles just fine :)
+let somethingOrElse: string = data ? data : 'else' // sorunsuz bir şekilde derlenir :)
 ```
 
-### Operator overloading with property access
+### Özellik erişimi ile operatör aşırı yükleme
 
-If you try to sum (for example) a nullable type (from a property access) with a non nullable one, the AssemblyScript compiler instead of giving a compile time error warning that one of the values is nullable, it just compiles silently, giving chance for the code to break at runtime.
+Bir özelliğe erişimden gelen bir null değere izin veren bir türü, null olmayan bir türle toplamaya çalışırsanız AssemblyScript derleyicisi, bu değerlerden birinin null değere izin verdiği konusunda derleme zamanı uyarısı vermez. Bunun yerine, sadece sessiz bir şekilde derlemeye devam eder ve çalışma sırasında kodun kırılmasına yol açar.
 
 ```typescript
 class BigInt extends Uint8Array {
@@ -323,14 +323,14 @@ class Wrapper {
 let x = BigInt.fromI32(2)
 let y: BigInt | null = null
 
-x + y // give compile time error about nullability
+x + y // null değer alabilme hakkında derleme hatası verir
 
 let wrapper = new Wrapper(y)
 
-wrapper.n = wrapper.n + x // doesn't give compile time errors as it should
+wrapper.n = wrapper.n + x // olması gerektiği gibi derleme hatası vermez
 ```
 
-We've opened a issue on the AssemblyScript compiler for this, but for now if you do these kind of operations in your subgraph mappings, you should change them to do a null check before it.
+AssemblyScript derleyicisine bu sorunu bildirdik. Ancak subgraph eşlemlerinizde bu tür işlemleri yapıyorsanız, şimdilik önce bir null değer kontrolü yapacak şekilde kodunuzu değiştirmelisiniz.
 
 ```typescript
 let wrapper = new Wrapper(y)
@@ -339,12 +339,12 @@ if (!wrapper.n) {
   wrapper.n = BigInt.fromI32(0)
 }
 
-wrapper.n = wrapper.n + x // now `n` is guaranteed to be a BigInt
+wrapper.n = wrapper.n + x // şimdi `n`'nin bir BigInt olduğu garanti edilmiştir
 ```
 
-### Value initialization
+### Değer ilklendirme
 
-If you have any code like this:
+Bunun gibi bir koda sahipseniz:
 
 ```typescript
 var value: Type // null
@@ -352,15 +352,15 @@ value.x = 10
 value.y = 'content'
 ```
 
-It will compile but break at runtime, that happens because the value hasn't been initialized, so make sure your subgraph has initialized their values, like this:
+Kod derlenir ancak çalıştırma esnasında kırılır. Bu da değerin ilklendirilmemiş olmasından kaynaklanır. Bu yüzden subgraph'inizin değerlerini aşağıdaki gibi ilklendirdiğinden emin olun:
 
 ```typescript
-var value = new Type() // initialized
+var value = new Type() // ilklendirme
 value.x = 10
 value.y = 'content'
 ```
 
-Also if you have nullable properties in a GraphQL entity, like this:
+Ayrıca, bir GraphQL varlığında şunun gibi null olabilen özellikleriniz varsa:
 
 ```graphql
 type Total @entity {
@@ -369,7 +369,7 @@ type Total @entity {
 }
 ```
 
-And you have code similar to this:
+Ve bu koda benzer bir koda sahipseniz:
 
 ```typescript
 let total = Total.load('latest')
@@ -381,7 +381,7 @@ if (total === null) {
 total.amount = total.amount + BigInt.fromI32(1)
 ```
 
-You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+`total.amount` değerini ilklendirdiğinizden emin olmanız gerekecek, çünkü toplama işlemi için son satırda erişmeye çalışırsanız, uygulama çöker. Bu yüzden ya önce ilklendirin:
 
 ```typescript
 let total = Total.load('latest')
@@ -394,7 +394,7 @@ if (total === null) {
 total.tokens = total.tokens + BigInt.fromI32(1)
 ```
 
-Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+Ya da GraphQL şemanızı bu özellik için null olabilen bir tür kullanmayacak şekilde değiştirin. Böylece `codegen` adımında bu değer sıfır olarak ilklendirilir 😉
 
 ```graphql
 type Total @entity {
@@ -407,15 +407,15 @@ type Total @entity {
 let total = Total.load('latest')
 
 if (total === null) {
-  total = new Total('latest') // already initializes non-nullable properties
+  total = new Total('latest') // null olamayan özellikleri ilklendirir
 }
 
 total.amount = total.amount + BigInt.fromI32(1)
 ```
 
-### Class property initialization
+### Sınıf özelliği ilklendirme
 
-If you export any classes with properties that are other classes (declared by you or by the standard library) like this:
+Eğer (kendi tarafınızdan veya standart kütüphane tarafından bildirilen) başka sınıfları içeren özelliklere sahip sınıfları şu şekilde dışa aktarırsanız:
 
 ```typescript
 class Thing {}
@@ -513,7 +513,7 @@ type MyEntity @entity {
 
 This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
 
-### Other
+### Diğer
 
 - Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
 - Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))

From 077945a45494df500b1ae6eadf7182e287d1ee34 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:32 -0500
Subject: [PATCH 3606/3820] New translations arweave.mdx (Portuguese)

---
 .../pages/pt/subgraphs/cookbook/arweave.mdx   | 48 +++++++++----------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/arweave.mdx b/website/pages/pt/subgraphs/cookbook/arweave.mdx
index 3bc1d017e7e2..4f8961c268ba 100644
--- a/website/pages/pt/subgraphs/cookbook/arweave.mdx
+++ b/website/pages/pt/subgraphs/cookbook/arweave.mdx
@@ -2,7 +2,7 @@
 title: Construindo Subgraphs no Arweave
 ---
 
-> Arweave support in Graph Node and on Subgraph Studio is in beta: please reach us on [Discord](https://discord.gg/graphprotocol) with any questions about building Arweave subgraphs!
+> O apoio ao Arweave no Graph Node, e no Subgraph Studio, está em beta: por favor nos contacte no [Discord](https://discord.gg/graphprotocol) se tiver dúvidas sobre como construir subgraphs no Arweave!
 
 Neste guia, você aprenderá como construir e lançar Subgraphs para indexar a blockchain Arweave.
 
@@ -13,20 +13,20 @@ O protocolo Arweave permite que programadores armazenem dados permanentemente. E
 O Arweave já construiu várias bibliotecas para integrar o protocolo num número de línguas de programação diferentes. Para mais informações, pode-se conferir:
 
 - [Arwiki](https://arwiki.wiki/#/en/main)
-- [Arweave Resources](https://www.arweave.org/build)
+- [Recursos do Arweave](https://www.arweave.org/build)
 
 ## O que são Subgraphs no Arweave?
 
-The Graph allows you to build custom open APIs called "Subgraphs". Subgraphs are used to tell indexers (server operators) which data to index on a blockchain and save on their servers in order for you to be able to query it at any time using [GraphQL](https://graphql.org/).
+The Graph permite a construção de APIs abertas e personalizadas chamadas "Subgraphs", que servem para contar aos indexadores (operadores de servidor) quais dados devem ser indexados em uma blockchain e guardados nos seus servidores para serem consultados a qualquer hora em queries pelo [GraphQL](https://graphql.org/).
 
-[Graph Node](https://github.com/graphprotocol/graph-node) is now able to index data on Arweave protocol. The current integration is only indexing Arweave as a blockchain (blocks and transactions), it is not indexing the stored files yet.
+O [Graph Node](https://github.com/graphprotocol/graph-node) é atualmente capaz de indexar dados no protocolo Arweave. A integração atual indexa apenas o Arweave como uma blockchain (blocos e transações), mas no momento, não indexa os arquivos armazenados.
 
 ## Construindo um Subgraph no Arweave
 
 Para construir e lançar Subgraphs no Arweave, são necessários dois pacotes:
 
-1. `@graphprotocol/graph-cli` above version 0.30.2 - This is a command-line tool for building and deploying subgraphs. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-cli) to download using `npm`.
-2. `@graphprotocol/graph-ts` above version 0.27.0 - This is library of subgraph-specific types. [Click here](https://www.npmjs.com/package/@graphprotocol/graph-ts) to download using `npm`.
+1. `@graphprotocol/graph-cli` acima da versão 0.30.2 — Esta é uma ferramenta de linha de comandos para a construção e implantação de subgraphs. [Clique aqui](https://www.npmjs.com/package/@graphprotocol/graph-cli) para baixá-la usando o `npm`.
+2. `@graphprotocol/graph-ts` acima da versão 0.27.0 — Esta é uma ferramenta de linha de comandos para a construção e implantação de subgraphs. [Clique aqui](https://www.npmjs.com/package/@graphprotocol/graph-ts) para baixá-la usando o `npm`.
 
 ## Os componentes de um subgraph
 
@@ -40,9 +40,9 @@ Define as fontes de dados de interesse, e como elas devem ser processadas. O Arw
 
 Aqui é possível definir quais dados queres consultar após indexar o seu subgraph utilizando o GraphQL. Isto é como um modelo para uma API, onde o modelo define a estrutura de um órgão de requisito.
 
-The requirements for Arweave subgraphs are covered by the [existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+Os requisitos para subgraphs do Arweave estão cobertos pela [documentação](/developing/creating-a-subgraph/#the-graphql-schema).
 
-### 3. AssemblyScript Mappings - `mapping.ts`
+### 3. Mapeamentos de AssemblyScript - `mapping.ts`
 
 Esta é a lógica que determina como os dados devem ser retirados e armazenados quando alguém interage com as fontes de dados que estás a escutar. Os dados são traduzidos e armazenados baseados no schema que listaste.
 
@@ -55,7 +55,7 @@ $ graph build # gera Web Assembly dos arquivos AssemblyScript, e prepara todos o
 
 ## Definição de Manifest de Subgraph
 
-The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for an Arweave subgraph:
+O manifest do subgraph `subgraph.yaml` identifica as fontes de dados para o subgraph, os gatilhos de interesse, e as funções que devem ser executadas em resposta a tais gatilhos. Veja abaixo um exemplo de um manifest de subgraph, para um subgraph no Arweave:
 
 ```yaml
 specVersion: 0.0.5
@@ -82,30 +82,30 @@ dataSources:
         - handler: handleTx # o nome da função no arquivo de mapeamento
 ```
 
-- Arweave subgraphs introduce a new kind of data source (`arweave`)
-- The network should correspond to a network on the hosting Graph Node. In Subgraph Studio, Arweave's mainnet is `arweave-mainnet`
+- Subgraphs no Arweave introduzem uma nova categoria de fonte de dados (`arweave`)
+- A rede deve corresponder a uma rede no Graph Node que a hospeda. No Subgraph Studio, a mainnet do Arweave é `arweave-mainnet`
 - Fontes de dados no Arweave introduzem um campo <code>source.owner</code> opcional, a chave pública de uma carteira no Arweave
 
 Fontes de dados no Arweave apoiam duas categorias de <i>handlers</i>:
 
-- `blockHandlers` - Run on every new Arweave block. No source.owner is required.
-- `transactionHandlers` - Run on every transaction where the data source's `source.owner` is the owner. Currently an owner is required for `transactionHandlers`, if users want to process all transactions they should provide "" as the `source.owner`
+- `blockHandlers` — Executar em cada bloco novo no Arweave. Nenhum `source.owner` necessário.
+- `transactionHandlers` — Executar em todas as transações cujo dono é o source.owner da fonte de dados. Atualmente, é necessário ter um dono para o transactionHandlers; caso um utilizador queira processar todas as transações, ele deve providenciar "" como o `source.owner`
 
 > O <code>source.owner</code> pode ser o endereço do dono, ou sua Chave Pública.
 >
 > Transações são os blocos de construção da permaweb do Arweave, além de serem objetos criados para utilizadores finais.
 >
-> Note: [Irys (previously Bundlr)](https://irys.xyz/) transactions are not supported yet.
+> Nota: No momento, não há apoio para transações no [Irys (antigo Bundlr)](https://irys.xyz/).
 
 ## Definição de Schema
 
-Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on the subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+A definição de Schema descreve a estrutura do banco de dados resultado do subgraph, e os relacionamentos entre entidades. Isto é agnóstico da fonte de dados original. Para mais detalhes na definição de schema de subgraph, [clique aqui](/developing/creating-a-subgraph/#the-graphql-schema).
 
 ## Mapeamentos em AssemblyScript
 
-The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+Os handlers para processamento de eventos estão escritos em [AssemblyScript](https://www.assemblyscript.org/).
 
-Arweave indexing introduces Arweave-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+A indexação do Arweave introduz tipos de dados específicos para esse ecossistema à [API do AssemblyScript](/subgraphs/developing/creating/graph-ts/api/).
 
 ```tsx
 class Block {
@@ -146,13 +146,13 @@ class Transaction {
 }
 ```
 
-Block handlers receive a `Block`, while transactions receive a `Transaction`.
+Handlers de bloco recebem um `Block`, enquanto transações recebem um `Transaction`.
 
-Writing the mappings of an Arweave Subgraph is very similar to writing the mappings of an Ethereum Subgraph. For more information, click [here](/developing/creating-a-subgraph/#writing-mappings).
+Escrever os mapeamentos de um Subgraph no Arweave é parecido com a escrita dos mapeamentos de um Subgraph no Ethereum. Para mais informações, clique [aqui](/developing/creating-a-subgraph/#writing-mappings).
 
 ## Como lançar um Subgraph no Arweave ao Subgraph Studio
 
-Once your subgraph has been created on your Subgraph Studio dashboard, you can deploy by using the `graph deploy` CLI command.
+Após criar o seu Subgraph no painel de controlo do Subgraph Studio, este pode ser implantado com o comando `graph deploy`.
 
 ```bash
 graph deploy --access-token <your-access-token>
@@ -160,13 +160,13 @@ graph deploy --access-token <your-access-token>
 
 ## Consultando um Subgraph no Arweave
 
-The GraphQL endpoint for Arweave subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+O ponto final do GraphQL para subgraphs no Arweave é determinado pela definição do schema, com a interface existente da API. Visite a [documentação da API da GraphQL](/subgraphs/querying/graphql-api/) para mais informações.
 
 ## Exemplos de Subgraphs
 
 Aqui está um exemplo de subgraph para referência:
 
-- [Example subgraph for Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
+- [Exemplo de subgraph para o Arweave](https://github.com/graphprotocol/graph-tooling/tree/main/examples/arweave-blocks-transactions)
 
 ## Perguntas Frequentes
 
@@ -188,9 +188,9 @@ O <code>source.owner</code> pode ser a chave pública ou o endereço da conta do
 
 ### Qual é o formato atual de encriptação?
 
-Data is generally passed into the mappings as Bytes, which if stored directly is returned in the subgraph in a `hex` format (ex. block and transaction hashes). You may want to convert to a `base64` or `base64 URL`-safe format in your mappings, in order to match what is displayed in block explorers like [Arweave Explorer](https://viewblock.io/arweave/).
+Os dados são geralmente passados aos mapeamentos como Bytes, que se armazenados diretamente, são retornados ao subgraph em um formato `hex` (por ex. hashes de transações e blocos). Você pode querer convertê-lo a um formato seguro para `base64` ou `base64 URL` em seus mapeamentos, para combinar com o que é exibido em exploradores de blocos, como o [Arweave Explorer](https://viewblock.io/arweave/).
 
-The following `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` helper function can be used, and will be added to `graph-ts`:
+A seguinte função de helper `bytesToBase64(bytes: Uint8Array, urlSafe: boolean): string` pode ser usada, e será adicionada ao `graph-ts`:
 
 ```
 const base64Alphabet = [

From 5cbe050bf59a154a3dd6a1e90b84cb1b1787d9f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:33 -0500
Subject: [PATCH 3607/3820] New translations avoid-eth-calls.mdx (Portuguese)

---
 .../pt/subgraphs/cookbook/avoid-eth-calls.mdx    | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/pt/subgraphs/cookbook/avoid-eth-calls.mdx
index fd40eb79c13c..e8ccf7501592 100644
--- a/website/pages/pt/subgraphs/cookbook/avoid-eth-calls.mdx
+++ b/website/pages/pt/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -99,18 +99,18 @@ Nota: `eth_calls` declaradas só podem ser feitas em subgraphs com specVersion m
 
 ## Conclusão
 
-You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
+O desempenho da indexação pode melhorar muito ao minimizar ou eliminar `eth_calls` nos nossos subgraphs.
 
-## Subgraph Best Practices 1-6
+## Melhores Práticas para um Subgraph 1 – 6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Pruning: Reduza o Excesso de Dados do Seu Subgraph para Acelerar Queries](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Use o @derivedFrom para Melhorar a Resposta da Indexação e de Queries](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Melhore o Desempenho da Indexação e de Queries com o Uso de Bytes como IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Evite `eth-calls` para Acelerar a Indexação](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Simplifique e Otimize com Séries Temporais e Agregações](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Lance Hotfixes Mais Rápido com Enxertos](/subgraphs/cookbook/grafting-hotfix/)

From b4e9b6ee46bf0c754707b18fb81e08d9f058cf19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:34 -0500
Subject: [PATCH 3608/3820] New translations cosmos.mdx (Portuguese)

---
 .../pages/pt/subgraphs/cookbook/cosmos.mdx    | 84 +++++++++----------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/cosmos.mdx b/website/pages/pt/subgraphs/cookbook/cosmos.mdx
index 928061cc9c7a..106301863698 100644
--- a/website/pages/pt/subgraphs/cookbook/cosmos.mdx
+++ b/website/pages/pt/subgraphs/cookbook/cosmos.mdx
@@ -2,26 +2,26 @@
 title: Construção de Subgraphs no Cosmos
 ---
 
-This guide is an introduction on building subgraphs indexing [Cosmos](https://cosmos.network/) based blockchains.
+Este guia é uma introdução à construção de subgraphs através da indexação de blockchains baseadas no [Cosmos](https://cosmos.network/).
 
 ## O que são subgraphs no Cosmos?
 
-The Graph allows developers to process blockchain events and make the resulting data easily available via an open GraphQL API, known as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process Cosmos events, which means Cosmos developers can now build subgraphs to easily index onchain events.
+The Graph permite que os programadores processem eventos em blockchain e façam dos dados resultantes facilmente disponíveis através de uma API aberta do GraphQL, conhecida como um subgraph. O [Graph Node](https://github.com/graphprotocol/graph-node) agora pode processar eventos no Cosmos, o que significa que programadores no Cosmos agora podem construir subgraphs para indexar com facilidade eventos on-chain.
 
 Existem quatro categorias de handlers apoiados em subgraphs no Cosmos:
 
-- **Block handlers** run whenever a new block is appended to the chain.
-- **Event handlers** run when a specific event is emitted.
-- **Transaction handlers** run when a transaction occurs.
-- **Message handlers** run when a specific message occurs.
+- **Handlers de bloco** são executados quando um novo bloco é anexado à chain.
+- **Handlers de evento** são executados quando um evento específico é emitido.
+- **Handlers de transação** são executados quando ocorre uma transação.
+- **Handlers de mensagem** são executados quando ocorre uma mensagem específica.
 
-Based on the [official Cosmos documentation](https://docs.cosmos.network/):
+Com base na [documentação oficial do Cosmos](https://docs.cosmos.network/):
 
-> [Events](https://docs.cosmos.network/main/learn/advanced/events) are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions.
+> [Eventos](https://docs.cosmos.network/main/learn/advanced/events) são objetos que contém informação sobre a execução do aplicativo. São principalmente usados por provedores de serviço, como exploradores de blocos e carteiras, para rastrear a execução de várias mensagens e transações de índices.
 >
-> [Transactions](https://docs.cosmos.network/main/learn/advanced/transactions) are objects created by end-users to trigger state changes in the application.
+> [Transações](https://docs.cosmos.network/main/learn/advanced/transactions) são objetos criados por utilizadores finais para ativar mudanças de estado no aplicativo.
 >
-> [Messages](https://docs.cosmos.network/main/learn/advanced/transactions#messages) are module-specific objects that trigger state transitions within the scope of the module they belong to.
+> [Mensagens](https://docs.cosmos.network/main/learn/advanced/transactions#messages) são objetos específicos a um módulo que ativam transições de estado, no alcance desse módulo.
 
 Apesar de todos os dados poderem ser acessados com um block handler, outros handlers permitem a programadores de subgraphs processar dados de uma maneira muito mais granular.
 
@@ -29,23 +29,23 @@ Apesar de todos os dados poderem ser acessados com um block handler, outros hand
 
 ### Dependências de Subgraph
 
-[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) is a CLI tool to build and deploy subgraphs, version `>=0.30.0` is required in order to work with Cosmos subgraphs.
+[graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) é uma ferramenta de CLI para construir e lançar subgraphs. A versão `>=0.30.0` é necessária para funcionar com subgraphs do Cosmos.
 
-[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) is a library of subgraph-specific types, version `>=0.27.0` is required in order to work with Cosmos subgraphs.
+[graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) é uma biblioteca de tipos de dados específicos a um subgraph. Subgraphs do Cosmos exigem a versão `>=0.27.0`.
 
 ### Componentes Principais de Subgraph
 
 Quando definir um subgraph, estes três componentes serão muito importantes:
 
-**subgraph.yaml**: a YAML file containing the subgraph manifest, which identifies which events to track and how to process them.
+**subgraph.yaml:** um arquivo YAML que contém o manifest do subgraph, e identifica quais eventos rastrear e como processá-los.
 
-**schema.graphql**: a GraphQL schema that defines what data is stored for your subgraph, and how to query it via GraphQL.
+**schema.graphql:** um schema da GraphQL que define quais dados são armazenados para o seu subgraph, e como consultá-los em query via GraphQL.
 
-**AssemblyScript Mappings**: [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) code that translates from blockchain data to the entities defined in your schema.
+**Mapeamentos do AssemblyScript**: Código do [AssemblyScript](https://github.com/AssemblyScript/assemblyscript) que traduz de dados da blockchain para as entidades definidas no seu schema.
 
 ### Definição de Manifest de Subgraph
 
-The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions (`handlers`) that should be run in response to those triggers. See below for an example subgraph manifest for a Cosmos subgraph:
+O manifest do subgraph (`subgraph.yaml`) identifica as fontes de dados para o subgraph, os gatilhos de interesse, e as funções (`handlers`) a executar em resposta àqueles gatilhos. Veja abaixo um exemplo de um manifest para um subgraph no Cosmos:
 
 ```yaml
 specVersion: 0.0.5
@@ -74,18 +74,18 @@ dataSources:
       file: ./src/mapping.ts # link ao arquivo com os mapeamentos em AssemblyScript
 ```
 
-- Cosmos subgraphs introduce a new `kind` of data source (`cosmos`).
-- The `network` should correspond to a chain in the Cosmos ecosystem. In the example, the Cosmos Hub mainnet is used.
+- Subgraphs no Cosmos introduzem um novo tipo de fonte de dados (`cosmos`).
+- A rede (`network`) deve corresponder a uma chain no ecossistema Cosmos. O exemplo acima usa a mainnet do Cosmos Hub.
 
 ### Definição de Schema
 
-Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+A definição de Schema descreve a estrutura do banco de dados resultado do subgraph, e os relacionamentos entre entidades. Isto é agnóstico da fonte de dados original. Para mais detalhes na definição de schema de subgraph, [clique aqui](/developing/creating-a-subgraph/#the-graphql-schema).
 
 ### Mapeamentos em AssemblyScript
 
-The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+Os handlers para processamento de eventos estão escritos em [AssemblyScript](https://www.assemblyscript.org/).
 
-Cosmos indexing introduces Cosmos-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+A indexação do Cosmos introduz tipos de dados específicos para esse ecossistema à [API do AssemblyScript](/subgraphs/developing/creating/graph-ts/api/).
 
 ```tsx
 class Block {
@@ -165,30 +165,30 @@ class Any {
 
 Cada tipo de handler vem com a sua própria estrutura de dados, a ser passada como argumento a uma função de mapeamento.
 
-- Block handlers receive the `Block` type.
-- Event handlers receive the `EventData` type.
-- Transaction handlers receive the `TransactionData` type.
-- Message handlers receive the `MessageData` type.
+- Handlers de blocos recebem o tipo `Block`.
+- Handlers de eventos recebem o tipo `EventData`.
+- Handlers de transações recebem o tipo `TransactionData`.
+- Handlers de mensagens recebem o tipo `MessageData`.
 
-As a part of `MessageData` the message handler receives a transaction context, which contains the most important information about a transaction that encompasses a message. The transaction context is also available in the `EventData` type, but only when the corresponding event is associated with a transaction. Additionally, all handlers receive a reference to a block (`HeaderOnlyBlock`).
+Como parte do `MessageData`, o handler de mensagens recebe um contexto de transação, que contém as informações mais importantes sobre uma transação a compor uma mensagem. O contexto da transação também está disponível no tipo `EventData`, mas só quando o evento correspondente é associado a uma transação. Além disso, todos os handlers recebem uma referência a um bloco (`HeaderOnlyBlock`).
 
-You can find the full list of types for the Cosmos integration [here](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
+Veja a lista completa de tipos para integração do Cosmos [aqui](https://github.com/graphprotocol/graph-ts/blob/4c064a8118dff43b110de22c7756e5d47fcbc8df/chain/cosmos.ts).
 
 ### Descodificação de mensagens
 
-It's important to note that Cosmos messages are chain-specific and they are passed to a subgraph in the form of a serialized [Protocol Buffers](https://protobuf.dev/) payload. As a result, the message data needs to be decoded in a mapping function before it can be processed.
+Repare que mensagens no Cosmos são específicas a chains, e são passadas a um subgraph na forma de um payload serializado de [Buffers de Protocolo](https://protobuf.dev/). Portanto, os dados das mensagens devem ser decodificados numa função de mapeamento antes que possam ser processados.
 
-An example of how to decode message data in a subgraph can be found [here](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
+Veja um exemplo de como decodificar dados de mensagem em um subgraph [aqui](https://github.com/graphprotocol/graph-tooling/blob/main/examples/cosmos-validator-delegations/src/decoding.ts).
 
 ## Criação e construção de um subgraph no Cosmos
 
-The first step before starting to write the subgraph mappings is to generate the type bindings based on the entities that have been defined in the subgraph schema file (`schema.graphql`). This will allow the mapping functions to create new objects of those types and save them to the store. This is done by using the `codegen` CLI command:
+Antes de começar a escrever os mapeamentos do subgraph, o primeiro passo é gerar os vínculos baseados nas entidades definidas no arquivo de schema do subgraph (`schema.graphql`). Assim, as funções de mapeamento criarão novos objetos destes tipos e os salvarão ao armazenamento. Isto é feito com o seguinte comando de CLI `codegen`:
 
 ```bash
 $ graph codegen
 ```
 
-Once the mappings are ready, the subgraph needs to be built. This step will highlight any errors the manifest or the mappings might have. A subgraph needs to build successfully in order to be deployed to the Graph Node. It can be done using the `build` CLI command:
+Quando os mapeamentos estiverem prontos, o subgraph precisará ser construído. Este passo destacará quaisquer erros possíveis no manifest ou nos mapeamentos. Um subgraph deve ser construído com êxito para ser implantado no Graph Node. Isto é possível com o seguinte comando de CLI `build`:
 
 ```bash
 $ graph build
@@ -196,7 +196,7 @@ $ graph build
 
 ## Lançamento de um subgraph no Cosmos
 
-Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+Quando o seu subgraph estiver pronto, lance o seu subgraph com o comando de CLI `graph deploy`:
 
 **Subgraph Studio**
 
@@ -206,7 +206,7 @@ Crie um novo subgraph no Subgraph Studio.
 graph deploy subgraph-name
 ```
 
-**Local Graph Node (based on default configuration):**
+**Graph Node local (baseado na configuração padrão):**
 
 ```bash
 graph create subgraph-name --node http://localhost:8020
@@ -218,7 +218,7 @@ graph deploy subgraph-name --node http://localhost:8020/ --ipfs http://localhost
 
 ## Consulta a um subgraph no Cosmos
 
-The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+O ponto final do GraphQL para subgraphs no Arweave é determinado pela definição do schema, com a interface existente da API. Visite a [documentação da API da GraphQL](/subgraphs/querying/graphql-api/) para mais informações.
 
 ## Apoio a Blockchains no Cosmos
 
@@ -226,11 +226,11 @@ The GraphQL endpoint for Cosmos subgraphs is determined by the schema definition
 
 #### O que é Cosmos Hub?
 
-The [Cosmos Hub blockchain](https://hub.cosmos.network/) is the first blockchain in the [Cosmos](https://cosmos.network/) ecosystem. You can visit the [official documentation](https://docs.cosmos.network/) for more information.
+A [blockchain Cosmos Hub](https://hub.cosmos.network/) é a primeira blockchain no ecossistema [Cosmos](https://cosmos.network/). Para mais informações, veja a [documentação oficial](https://docs.cosmos.network/).
 
 #### Redes
 
-Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testnet-001`. <br/>Other Cosmos Hub networks, i.e. `cosmoshub-3`, are halted, therefore no data is provided for them.
+A mainnet atual do Cosmos Hub é `cosmoshub-4`, e a testnet atual do Cosmos Hub é `theta-testnet-001`. <br/>Outras redes do Cosmos Hub, por ex. `cosmoshub-3`, estão em hiato; portanto, elas não recebem dados.
 
 ### Osmosis
 
@@ -238,20 +238,20 @@ Cosmos Hub mainnet is `cosmoshub-4`. Cosmos Hub current testnet is `theta-testne
 
 #### O que é Osmosis?
 
-[Osmosis](https://osmosis.zone/) is a decentralized, cross-chain automated market maker (AMM) protocol built on top of the Cosmos SDK. It allows users to create custom liquidity pools and trade IBC-enabled tokens. You can visit the [official documentation](https://docs.osmosis.zone/) for more information.
+O [Osmosis](https://osmosis.zone/) é um protocolo AMM (formador de mercado automatizado) cross-chain, construído sobre o kit de programão Cosmos. Este permite que os utilizadores criem pools customizadas de liquidez e troquem tokens com apoio a protocolos IBC (comunicação inter-blockchain). Para mais informações, veja a [documentação oficial](https://docs.osmosis.zone/).
 
 #### Redes
 
-Osmosis mainnet is `osmosis-1`. Osmosis current testnet is `osmo-test-4`.
+A mainnet do Osmosis é `osmosis-1`, e a testnet atual do Osmosis é `osmo-test-4`.
 
 ## Exemplos de Subgraphs
 
 Aqui estão alguns exemplos de subgraphs para referência:
 
-[Block Filtering Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
+[Exemplo de Filtração de Blocos](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-block-filtering)
 
-[Validator Rewards Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
+[Exemplo de Recompensas de Validador](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-rewards)
 
-[Validator Delegations Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
+[Exemplo de Delegações de Validador](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-validator-delegations)
 
-[Osmosis Token Swaps Example](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)
+[Exemplo de Trocas de Token no Osmosis](https://github.com/graphprotocol/graph-tooling/tree/main/examples/cosmos-osmosis-token-swaps)

From 024e6f57209e93399f268bc59a267e906b8076f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:34 -0500
Subject: [PATCH 3609/3820] New translations derivedfrom.mdx (Portuguese)

---
 .../pt/subgraphs/cookbook/derivedfrom.mdx     | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/derivedfrom.mdx b/website/pages/pt/subgraphs/cookbook/derivedfrom.mdx
index 4e667ee2ecf0..7ff286656b30 100644
--- a/website/pages/pt/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/pt/subgraphs/cookbook/derivedfrom.mdx
@@ -65,24 +65,24 @@ Isto não só aumenta a eficiência do nosso subgraph, mas também desbloqueia t
 
 2. Podemos fazer uma pesquisa reversa e um query sobre qualquer `Comment`, para ver de qual post ele vem.
 
-3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
+3. Podemos usar [Carregadores de Campos Derivados](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) para ativar o acesso e manipulação de dados diretamente de relacionamentos virtuais nos nossos mapeamentos de subgraph.
 
 ## Conclusão
 
-Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+Usar a diretiva `@derivedFrom` nos subgraphs lida eficientemente com arranjos que crescem dinamicamente, o que melhora o desempenho da indexação e o retiro de dados.
 
-For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+Para aprender mais estratégias detalhadas sobre evitar arranjos grandes, leia este blog por Kevin Jones: [Melhores Práticas no Desenvolvimento de Subgraphs: Como Evitar Grandes Arranjos](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
 
-## Subgraph Best Practices 1-6
+## Melhores Práticas para um Subgraph 1 – 6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Pruning: Reduza o Excesso de Dados do Seu Subgraph para Acelerar Queries](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Use o @derivedFrom para Melhorar a Resposta da Indexação e de Queries](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Melhore o Desempenho da Indexação e de Queries com o Uso de Bytes como IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Evite `eth-calls` para Acelerar a Indexação](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Simplifique e Otimize com Séries Temporais e Agregações](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Lance Hotfixes Mais Rápido com Enxertos](/subgraphs/cookbook/grafting-hotfix/)

From cac90cfc4a521ab7a5b62a10104f91d51e58f2a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:36 -0500
Subject: [PATCH 3610/3820] New translations enums.mdx (Portuguese)

---
 website/pages/pt/subgraphs/cookbook/enums.mdx | 146 +++++++++---------
 1 file changed, 73 insertions(+), 73 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/enums.mdx b/website/pages/pt/subgraphs/cookbook/enums.mdx
index ddfda1aae5bd..d76ea4c23c4b 100644
--- a/website/pages/pt/subgraphs/cookbook/enums.mdx
+++ b/website/pages/pt/subgraphs/cookbook/enums.mdx
@@ -1,20 +1,20 @@
 ---
-title: Categorize NFT Marketplaces Using Enums
+title: Categorize Marketplaces de NFT com Enums
 ---
 
-Use Enums to make your code cleaner and less error-prone. Here's a full example of using Enums on NFT marketplaces.
+Use Enums para deixar o seu código mais limpo e menos vulnerável a erros. Veja um exemplo do uso deste em marketplaces de NFT.
 
-## What are Enums?
+## O que são Enums?
 
-Enums, or enumeration types, are a specific data type that allows you to define a set of specific, allowed values.
+Enums, ou tipos de enumeração, são um tipo de dados específico que permite definir um conjunto de valores específicos permitidos.
 
-### Example of Enums in Your Schema
+### Exemplo de Enums no seu Schema
 
-If you're building a subgraph to track the ownership history of tokens on a marketplace, each token might go through different ownerships, such as `OriginalOwner`, `SecondOwner`, and `ThirdOwner`. By using enums, you can define these specific ownerships, ensuring only predefined values are assigned.
+Se estiver a construir um subgraph para rastrear o histórico de posse de tokens em um marketplace, cada token pode passar por posses diferentes, como `OriginalOwner`, `SecondOwner`, e `ThirdOwner`. Ao usar enums, é possível definir essas posses específicas, assim garantindo que só são nomeados valores predefinidos.
 
-You can define enums in your schema, and once defined, you can use the string representation of the enum values to set an enum field on an entity.
+É possível definir enums no seu schema; assim definidos, a representação de string dos valores de enum podem ser usados para configurar um campo de enum numa entidade.
 
-Here's what an enum definition might look like in your schema, based on the example above:
+Com base no exemplo acima, uma definição de enum no seu schema pode ficar assim:
 
 ```graphql
 enum TokenStatus {
@@ -24,109 +24,109 @@ enum TokenStatus {
 }
 ```
 
-This means that when you use the `TokenStatus` type in your schema, you expect it to be exactly one of predefined values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`, ensuring consistency and validity.
+Ou seja, quando usar o tipo `TokenStatus` no seu schema, a expectativa é de que seja exatamente um dos valores predefinidos: `OriginalOwner`, `SecondOwner`, ou `ThirdOwner`, assim garantindo a consistência e validez.
 
-To learn more about enums, check out [Creating a Subgraph](/developing/creating-a-subgraph/#enums) and [GraphQL documentation](https://graphql.org/learn/schema/#enumeration-types).
+Para saber mais sobre enums, veja [Como Criar um Subgraph](/developing/creating-a-subgraph/#enums) e a [documentação da GraphQL](https://graphql.org/learn/schema/#enumeration-types).
 
-## Benefits of Using Enums
+## Vantagens de Usar Enums
 
-- **Clarity:** Enums provide meaningful names for values, making data easier to understand.
-- **Validation:** Enums enforce strict value definitions, preventing invalid data entries.
-- **Maintainability:** When you need to change or add new categories, enums allow you to do this in a focused manner.
+- **Clareza**: Enums dão nomes significativos a valores, facilitando a navegação de dados.
+- **Validação**: Enums aplicam definições rígidas de valor, assim evitando entradas inválidas de dados.
+- **Manutenibilidade:** Enums permitem mudar ou adicionar novas categorias de maneira concentrada.
 
-### Without Enums
+### Sem Enums
 
-If you choose to define the type as a string instead of using an Enum, your code might look like this:
+Se escolher definir o tipo como um string em vez de usar um Enum, seu código poderá ficar assim:
 
 ```graphql
 type Token @entity {
   id: ID!
   tokenId: BigInt!
-  owner: Bytes! # Owner of the token
-  tokenStatus: String! # String field to track token status
+  owner: Bytes! # Proprietário do token
+  tokenStatus: String! # Campo de string para rastrear o estado do token
   timestamp: BigInt!
 }
 ```
 
-In this schema, `TokenStatus` is a simple string with no specific, allowed values.
+Neste schema, `TokenStatus` é um string simples sem valores permitidos específicos.
 
 #### Por que isto é um problema?
 
-- There's no restriction of `TokenStatus` values, so any string can be accidentally assigned. This makes it hard to ensure that only valid statuses like `OriginalOwner`, `SecondOwner`, or `ThirdOwner` are set.
-- It's easy to make typos such as `Orgnalowner` instead of `OriginalOwner`, making the data and potential queries unreliable.
+- Não há restrições sobre valores `TokenStatus`, então qualquer string pode ser nomeado por acidente. Assim, fica difícil garantir que só estados válidos — como `OriginalOwner`, `SecondOwner`, ou `ThirdOwner` — serão configurados.
+- É fácil fazer erros de digitação, como `Orgnalowner` em vez de `OriginalOwner`, o que faria os dados, e queries em potencial, não confiáveis.
 
-### With Enums
+### Com Enums
 
-Instead of assigning free-form strings, you can define an enum for `TokenStatus` with specific values: `OriginalOwner`, `SecondOwner`, or `ThirdOwner`. Using an enum ensures only allowed values are used.
+Em vez de nomear strings livres, é possível definir um enum para `TokenStatus` com valores específicos: `OriginalOwner`, `SecondOwner`, ou `ThirdOwner`. Usar um enum garante o uso de valores permitidos, e mais nenhum.
 
-Enums provide type safety, minimize typo risks, and ensure consistent and reliable results.
+Enums provém segurança de dados, minimizam os riscos de erros de digitação, e garantem resultados consistentes e confiáveis.
 
-## Defining Enums for NFT Marketplaces
+## Como Definir Enums para Marketplaces de NFT
 
-> Note: The following guide uses the CryptoCoven NFT smart contract.
+> Nota: o guia a seguir usa o contrato inteligente de NFTs CryptoCoven.
 
-To define enums for the various marketplaces where NFTs are traded, use the following in your subgraph schema:
+Para definir enums para os vários marketplaces com apoio a troca de NFTs, use o seguinte no seu schema de subgraph:
 
 ```gql
-# Enum for Marketplaces that the CryptoCoven contract interacted with(likely a Trade/Mint)
+# Enum para Marketplaces com que o contrato CryptoCoven interagiu(provavelmente Troca/Mint)
 enum Marketplace {
-  OpenSeaV1 # Represents when a CryptoCoven NFT is traded on the marketplace
-  OpenSeaV2 # Represents when a CryptoCoven NFT is traded on the OpenSeaV2 marketplace
-  SeaPort # Represents when a CryptoCoven NFT is traded on the SeaPort marketplace
-  LooksRare # Represents when a CryptoCoven NFT is traded on the LookRare marketplace
-  # ...and other marketplaces
+  OpenSeaV1 # Representa o comércio de um NFT CryptoCoven no marketplace
+  OpenSeaV2 # Representa o comércio de um NFT CryptoCoven no marketplace OpenSeaV2
+  SeaPort # Representa o comércio de um NFT CryptoCoven no marketplace SeaPort
+  LooksRare # Representa o comércio de um NFT CryptoCoven no marketplace LookRare
+  # ...e outros marketplaces
 }
 ```
 
-## Using Enums for NFT Marketplaces
+## Como Usar Enums para Marketplaces de NFT
 
-Once defined, enums can be used throughout your subgraph to categorize transactions or events.
+Quando definidos, enums podem ser usados no seu subgraph para categorizar transações ou eventos.
 
-For example, when logging NFT sales, you can specify the marketplace involved in the trade using the enum.
+Por exemplo: ao registrar vendas de NFT, é possível usar o enum para especificar o marketplace envolvido na ação.
 
-### Implementing a Function for NFT Marketplaces
+### Como Implementar uma Função para Marketplaces de NFT
 
-Here's how you can implement a function to retrieve the marketplace name from the enum as a string:
+Veja como implementar uma função para resgatar o nome de um marketplace do enum, como string:
 
 ```ts
 export function getMarketplaceName(marketplace: Marketplace): string {
-  // Using if-else statements to map the enum value to a string
+  // Usando comandos if-else para mapear o valor do enum para um string
   if (marketplace === Marketplace.OpenSeaV1) {
-    return 'OpenSeaV1' // If the marketplace is OpenSea, return its string representation
+    return 'OpenSeaV1' // Se o marketplace for OpenSea, retornar sua representação de string
   } else if (marketplace === Marketplace.OpenSeaV2) {
     return 'OpenSeaV2'
   } else if (marketplace === Marketplace.SeaPort) {
-    return 'SeaPort' // If the marketplace is SeaPort, return its string representation
+    return 'SeaPort' // Se o marketplace for SeaPort, retornar sua representação de string
   } else if (marketplace === Marketplace.LooksRare) {
-    return 'LooksRare' // If the marketplace is LooksRare, return its string representation
-    // ... and other market places
+    return 'LooksRare' // Se o marketplace for LooksRare, retornar sua representação de string
+    // ... e outros marketplaces
   }
 }
 ```
 
-## Best Practices for Using Enums
+## Melhores Práticas para o Uso de Enums
 
-- **Consistent Naming:** Use clear, descriptive names for enum values to improve readability.
-- **Centralized Management:** Keep enums in a single file for consistency. This makes enums easier to update and ensures they are the single source of truth.
-- **Documentation:** Add comments to enum to clarify their purpose and usage.
+- **Nomes Consistentes**: Deixe o seu código mais legível; use nomes mais claros e descritivos para valores de enum.
+- **Gestão Centralizada:** Mantenha enums num único arquivo para ficar mais consistente. Assim, os enums ficam mais fáceis de atualizar, garantindo uma fonte única e verdadeira de dados.
+- **Documentação:** Adicione comentários a enums para esclarecer o seu propósito e uso.
 
-## Using Enums in Queries
+## Como Usar Enums em Queries
 
-Enums in queries help you improve data quality and make your results easier to interpret. They function as filters and response elements, ensuring consistency and reducing errors in marketplace values.
+Enums em queries ajudam a melhorar a qualidade de dados e deixam os seus resultados mais fáceis de interpretar. Eles funcionam como filtros e elementos de resposta, assim garantindo a consistência e reduzindo erros em valores de marketplace.
 
-**Specifics**
+**Detalhes**
 
-- **Filtering with Enums:** Enums provide clear filters, allowing you to confidently include or exclude specific marketplaces.
-- **Enums in Responses:** Enums guarantee that only recognized marketplace names are returned, making the results standardized and accurate.
+- **Filtros com Enums:** Enums fornecem filtros claros, permitindo a inclusão ou exclusão clara de marketplaces específicos.
+- **Enums em Respostas:** Enums garantem que só marketplaces reconhecidos sejam retornados, trazendo resultados consistentes e precisos.
 
-### Sample Queries
+### Exemplos de Query
 
-#### Query 1: Account With The Highest NFT Marketplace Interactions
+#### Query 1: Conta com Mais Interações de Marketplace em NFT
 
-This query does the following:
+Este query faz o seguinte:
 
-- It finds the account with the highest unique NFT marketplace interactions, which is great for analyzing cross-marketplace activity.
-- The marketplaces field uses the marketplace enum, ensuring consistent and validated marketplace values in the response.
+- Encontra a conta com mais interações únicas com marketplaces de NFT, ótimo para analisar atividade entre marketplaces.
+- O campo de marketplaces usa o enum de marketplace, garantindo valores consistentes e validados na resposta.
 
 ```gql
 {
@@ -137,15 +137,15 @@ This query does the following:
     totalSpent
     uniqueMarketplacesCount
     marketplaces {
-      marketplace # This field returns the enum value representing the marketplace
+      marketplace # Este campo retorna o valor de enum representando o marketplace
     }
   }
 }
 ```
 
-#### Returns
+#### Respostas
 
-This response provides account details and a list of unique marketplace interactions with enum values for standardized clarity:
+Esta resposta fornece detalhes de conta e uma lista de interações singulares de marketplace com valores de enum, para mais clareza:
 
 ```gql
 {
@@ -186,12 +186,12 @@ This response provides account details and a list of unique marketplace interact
 }
 ```
 
-#### Query 2: Most Active Marketplace for CryptoCoven transactions
+#### Query 2: Marketplace mais ativo para transações do CryptoCoven
 
-This query does the following:
+Este query faz o seguinte:
 
-- It identifies the marketplace with the highest volume of CryptoCoven transactions.
-- It uses the marketplace enum to ensure that only valid marketplace types appear in the response, adding reliability and consistency to your data.
+- Identifica o marketplace com maior volume de transações do CryptoCoven.
+- Usa o enum de marketplace para garantir que só tipos válidos de marketplace apareçam na resposta, deixando os seus dados mais confiáveis e consistentes.
 
 ```gql
 {
@@ -202,9 +202,9 @@ This query does the following:
 }
 ```
 
-#### Result 2
+#### Resultado 2
 
-The expected response includes the marketplace and the corresponding transaction count, using the enum to indicate the marketplace type:
+A resposta esperada inclui o marketplace e a contagem correspondente de transações, usando o enum para indicar o tipo de marketplace:
 
 ```gql
 {
@@ -219,12 +219,12 @@ The expected response includes the marketplace and the corresponding transaction
 }
 ```
 
-#### Query 3: Marketplace Interactions with High Transaction Counts
+#### Query 3: Interações de Marketplace com Altos Números de Transação
 
-This query does the following:
+Este query faz o seguinte:
 
-- It retrieves the top four marketplaces with over 100 transactions, excluding "Unknown" marketplaces.
-- It uses enums as filters to ensure that only valid marketplace types are included, increasing accuracy.
+- Resgata os quatro marketplaces com maior número de transações acima de 100, excluindo marketplaces "desconhecidos".
+- Usa enums como filtros para garantir que só tipos válidos de marketplace sejam incluídos, deixando a resposta mais precisa.
 
 ```gql
 {
@@ -240,9 +240,9 @@ This query does the following:
 }
 ```
 
-#### Result 3
+#### Resultado 3
 
-Expected output includes the marketplaces that meet the criteria, each represented by an enum value:
+O retorno esperado inclui os marketplaces que cumprem os critérios, cada um representado por um valor enum:
 
 ```gql
 {
@@ -271,4 +271,4 @@ Expected output includes the marketplaces that meet the criteria, each represent
 
 ## Outros Recursos
 
-For additional information, check out this guide's [repo](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums).
+Para mais informações, veja o [repositório](https://github.com/chidubemokeke/Subgraph-Tutorial-Enums) deste guia.

From bc6abb109982d05d37dc7f0e385926d8acf6b98c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:36 -0500
Subject: [PATCH 3611/3820] New translations grafting-hotfix.mdx (Portuguese)

---
 .../pt/subgraphs/cookbook/grafting-hotfix.mdx | 152 +++++++++---------
 1 file changed, 76 insertions(+), 76 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/pt/subgraphs/cookbook/grafting-hotfix.mdx
index b09d54c13373..a462e181cbcf 100644
--- a/website/pages/pt/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/pt/subgraphs/cookbook/grafting-hotfix.mdx
@@ -1,64 +1,64 @@
 ---
-title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+title: "Melhores Práticas de Subgraph #6 - Use Enxertos para Implantar Hotfixes Mais Rápido"
 ---
 
 ## TLDR
 
-Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones.
+O enxerto é uma função poderosa na programação de subgraphs, que permite a construção e implantação de novos subgraphs enquanto recicla os dados indexados dos já existentes.
 
 ### Visão geral
 
-This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
+Esta função permite a implantação rápida de hotfixes para problemas críticos, eliminando a necessidade de indexar o subgraph inteiro do zero novamente. Ao preservar dados históricos, enxertar diminui o tempo de espera e garante a continuidade em serviços de dados.
 
-## Benefits of Grafting for Hotfixes
+## Benefícios de Enxertos para Hotfixes
 
-1. **Rapid Deployment**
+1. **Lançamento Rápido**
 
-   - **Minimize Downtime**: When a subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
-   - **Immediate Recovery**: The new subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
+   - **Espera Minimizada**: Quando um subgraph encontra um erro crítico e para de indexar, um enxerto permite que seja lançada uma solução imediata, sem esperar uma nova indexação.
+   - **Recuperação Imediata**: O novo subgraph continua do último bloco indexado, garantindo o funcionamento ininterrupto dos serviços de dados.
 
-2. **Data Preservation**
+2. **Preservação de Dados**
 
-   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
-   - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
+   - **Reaproveitamento de Dados Históricos**: O enxerto copia os dados existentes do subgraph de origem; assim, não há como perder dados históricos valiosos.
+   - **Consistência**: Mantém a continuidade de dados, que é crucial para aplicativos que dependem de dados históricos consistentes.
 
-3. **Efficiency**
-   - **Save Time and Resources**: Avoids the computational overhead of re-indexing large datasets.
-   - **Focus on Fixes**: Allows developers to concentrate on resolving issues rather than managing data recovery.
+3. **Eficiência**
+   - **Economia de Tempo e Recursos**: Evita o fardo computacional de repetir a indexação de grandes conjuntos de dados.
+   - **Foco em Conserto**: Os programadores podem se concentrar na solução de problemas, em vez de controlar a recuperação de dados.
 
-## Best Practices When Using Grafting for Hotfixes
+## Melhores Práticas ao Usar Enxertos para Hotfixes
 
-1. **Initial Deployment Without Grafting**
+1. \*Implantação Inicial sem Enxerto\*\*
 
-   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
-   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+   - **Começar do Zero**: Sempre lance o seu subgraph inicial sem enxertos para que fique estável e funcione como esperado.
+   - **Fazer Testes Minuciosos:** Valide o desempenho do subgraph para minimizar a necessidade de hotfixes futuros.
 
-2. **Implementing the Hotfix with Grafting**
+2. **Implementação do Hotfix com Enxerto**
 
-   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
-   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
-   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
-   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+   - **Identificar o Problema**: Quando ocorrer um erro crítico, determine o número de bloco do último evento indexado com êxito.
+   - **Criar um Novo Subgraph**: Programe um novo subgraph que inclui o hotfix.
+   - **Configure o Enxerto**: Use o enxerto para copiar dados até o número de bloco identificado do subgraph defeituoso.
+   - **Lance Rápido**: Edite o subgraph enxertado para reabrir o serviço o mais rápido possível.
 
-3. **Post-Hotfix Actions**
+3. **Depois do Hotfix**
 
-   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
-   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
-     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
-   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+   - **Monitore o Desempenho**: Tenha certeza que o subgraph enxertado está a indexar corretamente, e que o hotfix pode resolver o problema.
+   - **Reedite Sem Enxertos**: Agora que está estável, lance uma nova versão do subgraph sem enxertos para fins de manutenção a longo prazo.
+     > Nota: Não é recomendado depender de enxertos indefinidamente, pois isto pode complicar a manutenção e implantação de futuras atualizações.
+   - **Atualize as Referências**: Redirecione quaisquer serviços ou aplicativos para que usem o novo subgraph, sem enxertos.
 
-4. **Important Considerations**
-   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
-   - **Tip**: Use the block number of the last correctly processed event.
-   - **Use Deployment ID**: Ensure you reference the Deployment ID of the base subgraph, not the Subgraph ID.
-   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
-   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+4. **Considerações Importantes**
+   - **Selecione Blocos Corretamente**: Escolha o número de bloco do enxerto com cuidado, para evitar perdas de dados.
+   - **Dica**: Use o número de bloco do último evento corretamente processado.
+   - **Use a ID de Implantação**: Referencie a ID de Implantação do subgraph de origem, não a ID do Subgraph.
+   - **Nota**: A ID de Implantação é a identificadora única para uma implantação específica de subgraph.
+   - **Declaração de Funções**: Não se esqueça de declarar enxertos na lista de funções, no manifest do seu subgraph.
 
-## Example: Deploying a Hotfix with Grafting
+## Exemplo: Como Implantar um Subgraph com Enxertos
 
-Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+Vamos supor que tens um subgraph a rastrear um contrato inteligente, que parou de indexar devido a um erro crítico. Veja como usar um enxerto para implementar um hotfix.
 
-1. **Failed Subgraph Manifest (subgraph.yaml)**
+1. **Manifest Falho de Subgraph (subgraph.yaml)**
 
    ```yaml
    specVersion: 1.0.0
@@ -87,7 +87,7 @@ Suppose you have a subgraph tracking a smart contract that has stopped indexing
          file: ./src/old-lock.ts
    ```
 
-2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+2. **Novo Manifest Enxertado de Subgraph (subgraph.yaml)**
    ```yaml
    specVersion: 1.0.0
    schema:
@@ -120,67 +120,67 @@ Suppose you have a subgraph tracking a smart contract that has stopped indexing
      block: 6000000 # Last successfully indexed block
    ```
 
-**Explanation:**
+**Explicação:**
 
-- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
-- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
-- **Grafting Configuration**:
-  - **base**: Deployment ID of the failed subgraph.
-  - **block**: Block number where grafting should begin.
+- **Atualização de Fonte de Dados**: O novo subgraph aponta para 0xNewContractAddress, que pode ser uma versão consertada do contrato inteligente.
+- **Bloco Inicial**: Configure para um bloco após o último indexado com êxito, para evitar processar o erro novamente.
+- **Configuração de Enxerto**:
+  - **base**: ID de Implantação do subgraph falho.
+  - **block**: Número de blocos onde o enxerto deve começar.
 
-3. **Deployment Steps**
+3. **Etapas de Implantação**
 
-   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
-   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
-   - **Deploy the Subgraph**:
-     - Authenticate with the Graph CLI.
-     - Deploy the new subgraph using `graph deploy`.
+   - **Atualize o Código**: Implemente o hotfix nos seus scripts de mapeamento (por exemplo, handleWithdrawal).
+   - **Ajuste o Manifest**: Conforme detalhado acima, atualize o `subgraph.yaml` com configurações de enxerto.
+   - **Lance o Subgraph**:
+     - Autentique com a Graph CLI.
+     - Lance o novo subgraph com `graph deploy`.
 
-4. **Post-Deployment**
-   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
-   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
-   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+4. **Após a Implantação**
+   - **Verifique a Indexação**: Verifique se o subgraph está a indexar corretamente a partir do ponto de enxerto.
+   - **Monitore os Dados**: Verifique se há novos dados sendo capturados, e se o hotfix funciona.
+   - **Planeie Para uma Reedição**: Prepare a implantação de uma versão não enxertada, para mais estabilidade a longo prazo.
 
-## Warnings and Cautions
+## Tome Cuidado
 
-While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+O enxerto é uma ferramenta poderosa para implantar hotfixes rapidamente, mas deve ser evitado em algumas situações específicas — para manter a integridade dos dados e garantir o melhor desempenho.
 
-- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
-- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
-- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+- **Mudanças Incompatíveis de Schema**: Se o seu hotfix exigir a alteração do tipo de campos existentes ou a remoção de campos do seu esquema, não é adequado fazer um enxerto. O enxerto espera que o esquema do novo subgraph seja compatível com o schema do subgráfico base. Alterações incompatíveis podem levar a inconsistências e erros de dados, porque os dados existentes não se alinham com o novo schema.
+- **Mudanças Significantes na Lógica de Mapeamento**: Quando o hotfix envolve modificações substanciais na sua lógica de mapeamento — como alterar o processamento de eventos ​de funções do handler — o enxerto pode não funcionar corretamente. A nova lógica pode não ser compatível com os dados processados ​​sob a lógica antiga, levando a dados incorretos ou indexação com falha.
+- **Implantações na The Graph Network:** Enxertos não são recomendados para subgraphs destinados à rede descentralizada (mainnet) do The Graph. Um enxerto pode complicar a indexação e pode não ser totalmente apoiado por todos os Indexers, o que pode causar comportamento inesperado ou aumento de custos. Para implantações de mainnet, é mais seguro recomeçar a indexação do subgraph do zero, para garantir total compatibilidade e confiabilidade.
 
-### Risk Management
+### **Controle de Riscos**
 
-- **Data Integrity**: Incorrect block numbers can lead to data loss or duplication.
-- **Testing**: Always test grafting in a development environment before deploying to production.
+- **Integridade de Dados**: Números de bloco incorretos podem causar perda ou duplicação de dados.
+- **Testes**: Sempre experimente enxertos num ambiente de testes antes de lançá-los para produção.
 
 ## Conclusão
 
-Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+O enxerto é uma estratégia eficaz para implantar hotfixes no desenvolvimento de subgraphs, e ainda permite:
 
-- **Quickly Recover** from critical errors without re-indexing.
-- **Preserve Historical Data**, maintaining continuity for applications and users.
-- **Ensure Service Availability** by minimizing downtime during critical fixes.
+- **Se recuperar rapidamente** de erros críticos sem recomeçar a indexação.
+- **Preservar dados históricos**, mantendo a continuidade tanto para aplicativos quanto para utilizadores.
+- **Garantir a disponibilidade do serviço** ao minimizar o tempo de espera em períodos importantes de manutenção.
 
-However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+No entanto, é importante usar enxertos com cuidado e seguir as melhores práticas para controlar riscos. Após estabilizar o seu subgraph com o hotfix, planeie a implantação de uma versão não enxertada para garantir a estabilidade a longo prazo.
 
 ## Outros Recursos
 
-- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
-- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+- **[Documentação de Enxertos](/subgraphs/cookbook/grafting/)**: Substitua um Contrato e Mantenha o Seu Histórico com Enxertos
+- **[Como Entender IDs de Implantação](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Aprenda a diferença entre ID de Implantação e ID de Subgraph.
 
-By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+Ao incorporar enxertos ao seu fluxo de programação de subgraphs, é possível melhorar a sua capacidade de responder a problemas, garantindo que os seus serviços de dados permaneçam robustos e confiáveis.
 
-## Subgraph Best Practices 1-6
+## Melhores Práticas para um Subgraph 1 – 6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Pruning: Reduza o Excesso de Dados do Seu Subgraph para Acelerar Queries](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Use o @derivedFrom para Melhorar a Resposta da Indexação e de Queries](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Melhore o Desempenho da Indexação e de Queries com o Uso de Bytes como IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Evite `eth-calls` para Acelerar a Indexação](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Simplifique e Otimize com Séries Temporais e Agregações](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Lance Hotfixes Mais Rápido com Enxertos](/subgraphs/cookbook/grafting-hotfix/)

From 8720cb70cf71b392f29b601336cff9a85e457abc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:37 -0500
Subject: [PATCH 3612/3820] New translations grafting.mdx (Portuguese)

---
 .../pages/pt/subgraphs/cookbook/grafting.mdx  | 44 +++++++++----------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/grafting.mdx b/website/pages/pt/subgraphs/cookbook/grafting.mdx
index 97809af300ce..cbfc42ddc895 100644
--- a/website/pages/pt/subgraphs/cookbook/grafting.mdx
+++ b/website/pages/pt/subgraphs/cookbook/grafting.mdx
@@ -20,13 +20,13 @@ O subgraph enxertado pode usar um schema GraphQL que não é idêntico ao schema
 
 Para mais informações, confira:
 
-- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+- [Enxertos](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
 
 Neste tutorial, cobriremos um caso de uso básico. Substituiremos um contrato existente com um contrato idêntico (com um novo endereço, mas o mesmo código). Depois, enxertaremos o subgraph existente ao subgraph "base" que rastreará o novo contrato.
 
 ## Notas Importantes sobre Enxertos ao Migrar Para a Graph Network
 
-> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+> **Cuidado**: Não é recomendado usar enxertos para subgraphs editados na The Graph Network
 
 ### Qual a Importância Disto?
 
@@ -34,23 +34,23 @@ Isto é um recurso poderoso que permite que os programadores "enxertem" um subgr
 
 ### Boas práticas
 
-**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+**Migração Inicial**: Ao implantar o seu subgraph pela primeira vez na rede descentralizada, faça-o sem enxertos. Verifique se o subgraph está estável e funciona como esperado.
 
-**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+**Atualizações Subsequentes**: quando o seu subgraph estiver ativo e estável na rede descentralizada, será possível usar enxertos para versões futuras, para tornar a transição mais suave e preservar dados históricos.
 
 Ao aderir a estas diretrizes, dá para minimizar riscos e garantir um processo de migração mais suave.
 
 ## Como Construir um Subgraph Existente
 
-Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+Construir subgraphs é uma parte essencial do The Graph, descrita mais profundamente [aqui](/subgraphs/quick-start/). Para poder construir e implementar o subgraph existente usado neste tutorial, veja o seguinte repositório:
 
-- [Subgraph example repo](https://github.com/Shiyasmohd/grafting-tutorial)
+- [Exemplo de repositório de subgraph](https://github.com/Shiyasmohd/grafting-tutorial)
 
-> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+> Nota: O contrato usado no subgraph foi tirado do seguinte [Kit para Iniciantes de Hackathon](https://github.com/schmidsi/hackathon-starterkit).
 
 ## Definição de Manifest de Subgraph
 
-The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+O manifest do subgraph `subgraph.yaml` identifica as fontes de dados para o subgraph, os gatilhos de interesse, e as funções que devem ser executadas em resposta a esses gatilhos. Veja abaixo um exemplo de manifesto de subgraph para usar:
 
 ```yaml
 specVersion: 0.0.4
@@ -79,9 +79,9 @@ dataSources:
       file: ./src/lock.ts
 ```
 
-- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
-- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
-- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+- A fonte de dados `Lock` consiste na ABI (Interface binária de aplicação), e o endereço de contrato que receberemos ao compilar e implantar o contrato
+- A rede deve corresponder a uma rede indexada a ser consultada em query. Como estamos a operar na testnet da Sepolia, a rede é `sepolia`
+- A seção `mapping` define os gatilhos de interesse e as funções a executar em resposta a esses. Neste caso, estamos à espera do evento `Withdrawal`; quando emitido, chamaremos a função `handleWithdrawal`.
 
 ## Definição de Manifest de Enxertos
 
@@ -96,15 +96,15 @@ graft:
   block: 5956000 # block number
 ```
 
-- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
-- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+- `features:` é uma lista de todos os [nomes de função](/developing/creating-a-subgraph/#experimental-features) usados.
+- `graft:` é um mapa do subgraph `base` e ​​do bloco para enxertar. `block` é o número do bloco para começar a indexação. The Graph copiará os dados do subgraph base até, e incluindo, o bloco fornecido, e então continuará a indexar o novo subgraph a partir desse bloco em diante.
 
-The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+Os valores `base` e ​​`block` podem ser encontrados com a implantação de dois subgraphs: um para indexação de base e outro com enxerto
 
 ## Como Lançar o Subgraph Base
 
-1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
-2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+1. Vá para o [Subgraph Studio](https://thegraph.com/studio/) e crie um subgraph na testnet da Sepolia chamado `graft-example`
+2. Siga as direções na seção `AUTH & DEPLOY` na sua página de subgraph, na pasta `graft-example` do repositório
 3. Ao terminar, verifique que o subgraph está a indexar corretamente. Se executar o seguinte comando no The Graph Playground
 
 ```graphql
@@ -144,9 +144,9 @@ Após verificar que o subgraph está a indexar corretamente, será possível atu
 
 O subgraph.yaml do substituto terá um novo endereço de contrato. Isto pode acontecer quando atualizar o seu dapp, relançar um contrato, etc.
 
-1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
-2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
-3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+1. Vá para o [Subgraph Studio](https://thegraph.com/studio/) e crie um subgraph na testnet da Sepolia chamado `graft-replacement`
+2. Crie um novo manifesto. O `subgraph.yaml` para `graph-replacement` contém um endereço de contrato diferente e novas informações sobre como ele deve enxertar. Estes são o `block` do [último evento importante emitido](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) pelo contrato antigo, e o `base` do subgraph antigo. A ID de subgraph `base` é a `Deployment ID` do seu subgraph `graph-example` original. Você pode encontrá-la no Subgraph Studio.
+3. Siga as instruções na seção `AUTH & DEPLOY` da sua página de subgraph, na pasta `graft-replacement` do repositório
 4. Ao terminar, verifique que o subgraph está a indexar corretamente. Se executar o seguinte comando no The Graph Playground
 
 ```graphql
@@ -185,7 +185,7 @@ Ele deve retornar algo como:
 }
 ```
 
-You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+Repare que o subgraph `graft-replacement` está a indexar a partir de dados `graph-example` mais antigos e dados mais novos do novo endereço de contrato. O contrato original emitiu dois eventos `Withdrawal`: [Evento 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) e [Evento 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). O novo contrato emitiu um `Withdrawal` após, [Evento 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). As duas transações indexadas anteriormente (Evento 1 e 2) e a nova transação (Evento 3) foram combinadas no subgraph `graft-replacement`.
 
 Parabéns! Enxertaste um subgraph em outro subgraph.
 
@@ -197,6 +197,6 @@ Caso queira mais experiência com enxertos, veja alguns exemplos de contratos po
 - [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
 - [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
 
-To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+Para se tornar especialista no The Graph, aprenda sobre outras maneiras de cuidar de mudanças em fontes de dados subjacentes. Alternativas como [Modelos de Fontes de Dados](/developing/creating-a-subgraph/#data-source-templates) podem dar resultados parecidos
 
-> Note: A lot of material from this article was taken from the previously published [Arweave article](/subgraphs/cookbook/arweave/)
+> Nota: Grande parte do material deste artigo foi tirado do [artigo anteriormente editado sobre o Arweave](/subgraphs/cookbook/arweave/)

From 1ae38c6f9bac00efacde5357e7785ba4c7056e7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:38 -0500
Subject: [PATCH 3613/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Portuguese)

---
 .../cookbook/immutable-entities-bytes-as-ids.mdx | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/pt/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
index ab5b757ccd84..f3680f9b4610 100644
--- a/website/pages/pt/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/pt/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -21,7 +21,7 @@ type Transfer @entity(immutable: true) {
 
 Ao tornar a entidade `Transfer` imutável, o graph-node pode processá-la com mais eficácia, o que melhora as velocidades de indexação e a capacidade de resposta das queries.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Estruturas de Entidades Imutáveis não mudarão no futuro. Uma entidade ideal para tornar Imutável seria uma que grava diretamente dados de eventos on-chain; por exemplo, um evento `Transfer` registrado como uma entidade `Transfer`.
 
 ### De dentro da casca
 
@@ -175,16 +175,16 @@ Resposta de query:
 
 Leia mais sobre o uso de Entidades Imutáveis e Bytes como IDs nesta publicação por David Lutterkort, Engenheiro de Software na Edge & Node: [Duas Melhorias Simples no Desempenho de Subgraphs](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
 
-## Subgraph Best Practices 1-6
+## Melhores Práticas para um Subgraph 1 – 6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Pruning: Reduza o Excesso de Dados do Seu Subgraph para Acelerar Queries](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Use o @derivedFrom para Melhorar a Resposta da Indexação e de Queries](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Melhore o Desempenho da Indexação e de Queries com o Uso de Bytes como IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Evite `eth-calls` para Acelerar a Indexação](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Simplifique e Otimize com Séries Temporais e Agregações](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Lance Hotfixes Mais Rápido com Enxertos](/subgraphs/cookbook/grafting-hotfix/)

From 7c109164d3eff050679398912bb9cd10b8ce8944 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:39 -0500
Subject: [PATCH 3614/3820] New translations near.mdx (Portuguese)

---
 website/pages/pt/subgraphs/cookbook/near.mdx | 76 ++++++++++----------
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/near.mdx b/website/pages/pt/subgraphs/cookbook/near.mdx
index b9a7d95269f4..46cf4845e448 100644
--- a/website/pages/pt/subgraphs/cookbook/near.mdx
+++ b/website/pages/pt/subgraphs/cookbook/near.mdx
@@ -2,42 +2,42 @@
 title: Construção de Subgraphs na NEAR
 ---
 
-This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+Este guia é uma introdução à construção de subgraphs para indexar contratos inteligentes na blockchain [NEAR](https://docs.near.org/).
 
 ## O que é NEAR?
 
-[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+[NEAR](https://near.org/) é uma plataforma de contrato inteligente para construir aplicativos descentralizados. Visite a [documentação oficial](https://docs.near.org/concepts/basics/protocol) para mais informações.
 
 ## O que são subgraphs na NEAR?
 
-The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+The Graph fornece aos programadores ferramentas para processar eventos de blockchain e tornar os dados resultantes facilmente disponíveis por meio de uma API GraphQL, conhecida individualmente como subgraph. O [Graph Node](https://github.com/graphprotocol/graph-node) agora é capaz de processar eventos NEAR, o que significa que programadores da NEAR agora podem criar subgraphs para indexar seus contratos inteligentes.
 
-Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+Subgraphs são baseados em eventos; ou seja, eles esperam e então processam eventos on-chain. Atualmente há dois tipos de handlers que funcionam para subgraphs na NEAR:
 
 - Handlers de blocos: executados em todos os blocos novos
 - Handlers de recibos: Executados sempre que uma mensagem é executada numa conta especificada
 
-[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+[Da documentação da NEAR](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
 
 > Um Recibo é o único objeto acionável no sistema. Quando falamos de "processar uma transação" na plataforma NEAR, em algum ponto isto eventualmente significa "aplicar recibos".
 
 ## Construindo um Subgraph no NEAR
 
-`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+`@graphprotocol/graph-cli` é uma ferramenta de linha de comando para a construção e implantação de subgraphs.
 
-`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+`@graphprotocol/graph-ts` é uma biblioteca de tipos específicos a subgraphs.
 
-NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+A programação de subgraphs no NEAR exige o `graph-cli` acima da versão `0.23.0`, e o `graph-ts` acima da versão `0.23.0`.
 
 > Construir um subgraph NEAR é um processo muito parecido com a construção de um subgraph que indexa o Ethereum.
 
 Há três aspectos de definição de subgraph:
 
-**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+**subgraph.yaml:** o manifest do subgraph, que define as fontes de dados de interesse e como elas devem ser processadas. A NEAR é uma nova espécie (`kind`) de fonte de dados.
 
-**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+**schema.graphql:** um arquivo de schema que define quais dados são armazenados para o seu subgraph e como consultá-los via GraphQL. Os requisitos para subgraphs NEAR são cobertos pela [documentação existente](/developing/creating-a-subgraph/#the-graphql-schema).
 
-**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+**Mapeamentos de AssemblyScript:** [Código AssemblyScript](/subgraphs/developing/creating/graph-ts/api/) que traduz dos dados do evento para as entidades definidas no seu esquema. O apoio à NEAR introduz tipos de dados específicos da NEAR e novas funções de análise JSON.
 
 Durante o desenvolvimento de um subgraph, existem dois comandos importantes:
 
@@ -48,7 +48,7 @@ $ graph build # gera Web Assembly dos arquivos AssemblyScript, e prepara todos o
 
 ### Definição de Manifest de Subgraph
 
-The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+O manifest do subgraph (`subgraph.yaml`) identifica as fontes de dados para o subgraph, os gatilhos de interesse, e as funções que devem ser executadas em resposta a tais gatilhos. Veja abaixo um exemplo de manifest para um subgraph na NEAR:
 
 ```yaml
 specVersion: 0.0.2
@@ -70,10 +70,10 @@ dataSources:
       file: ./src/mapping.ts # link ao arq. com os mapeamentos de Assemblyscript
 ```
 
-- NEAR subgraphs introduce a new `kind` of data source (`near`)
-- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
-- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
-- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+- Subgraphs na NEAR introduzem um novo tipo (`kind`) de fonte de dados (`near`)
+- O `network` deve corresponder a uma rede no Graph Node hóspede. No Subgraph Studio, a mainnet da NEAR é `near-mainnet`, e a testnet da NEAR é `near-testnet`
+- Fontes de dados na NEAR introduzem um campo `source.account` opcional: uma ID legível a humanos que corresponde a uma [conta na NEAR](https://docs.near.org/concepts/protocol/account-model). Isto pode ser uma conta ou subconta.
+- As fontes de dados da NEAR introduzem um campo alternativo `source.accounts` opcional, que contém sufixos e prefixos opcionais. Pelo menos prefix ou sufixo deve ser especificado, eles corresponderão a qualquer conta que comece ou termine com a lista de valores, respectivamente. O exemplo abaixo corresponderia a: `[app|good].*[morning.near|morning.testnet]`. Se apenas uma lista de prefixos ou sufixos for necessária, o outro campo pode ser omitido.
 
 ```yaml
 accounts:
@@ -87,18 +87,18 @@ accounts:
 
 As fontes de dados na NEAR apoiam duas categorias de handlers:
 
-- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
-- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+- `blockHandlers`: executado em cada novo bloco na NEAR. Não é necessário nenhum `source.account`.
+- `receiptHandlers`: executados em todo recibo onde o `source.account` da fonte de dados é o recipiente. Note que só são processadas combinações exatas ([subcontas](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) devem ser adicionadas como fontes de dados independentes).
 
 ### Definição de Schema
 
-Schema definition describes the structure of the resulting subgraph database and the relationships between entities. This is agnostic of the original data source. There are more details on subgraph schema definition [here](/developing/creating-a-subgraph/#the-graphql-schema).
+A definição de Schema descreve a estrutura do banco de dados resultado do subgraph, e os relacionamentos entre entidades. Isto é agnóstico da fonte de dados original. Para mais detalhes na definição de schema de subgraph, [clique aqui](/developing/creating-a-subgraph/#the-graphql-schema).
 
 ### Mapeamentos em AssemblyScript
 
-The handlers for processing events are written in [AssemblyScript](https://www.assemblyscript.org/).
+Os handlers para processamento de eventos estão escritos em [AssemblyScript](https://www.assemblyscript.org/).
 
-NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+A indexação da NEAR introduz tipos de dados específicos desse ecossistema à [API do AssemblyScript](/subgraphs/developing/creating/graph-ts/api/).
 
 ```typescript
 
@@ -160,33 +160,33 @@ class ReceiptWithOutcome {
   }
 ```
 
-These types are passed to block & receipt handlers:
+Estes tipos são repassados para handlers de blocos e recibos:
 
-- Block handlers will receive a `Block`
-- Receipt handlers will receive a `ReceiptWithOutcome`
+- Handlers de blocos receberão um `Block`
+- Handlers de recibos receberão um `ReceiptWithOutcome`
 
-Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+Caso contrário, o resto da [API do AssemblyScript](/subgraphs/developing/creating/graph-ts/api/) está à disposição dos programadores de subgraph na NEAR, durante a execução dos mapeamentos.
 
-This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+Isto inclui uma nova função de análise em JSON: logs na NEAR são frequentemente emitidos como JSONs em string. A nova função json.fromString(...) está disponível como parte da [API JSON](/subgraphs/developing/creating/graph-ts/api/#json-api) para que programadores processem estes logs com mais facilidade.
 
 ## Lançando um Subgraph na NEAR
 
-Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+Quando tiver um subgraph pronto, chegará a hora de implantá-lo no Graph Node para indexar. Subgraphs na NEAR podem ser implantados em qualquer Graph Node `>=v0.26.x` (esta versão ainda não foi marcada ou liberada).
 
 O Subgraph Studio e o Indexador de atualização na Graph Network apoiam atualmente a indexação da mainnet e da testnet do NEAR em beta, com os seguintes nomes de rede:
 
 - `near-mainnet`
 - `near-testnet`
 
-More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+Para mais informações sobre criar e implantar subgraphs no Subgraph Studio, clique [aqui](/deploying/deploying-a-subgraph-to-studio/).
 
-As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+Para começo de conversa, o primeiro passo consiste em "criar" o seu subgraph - isto só precisa ser feito uma vez. No Subgraph Studio, isto pode ser feito do [seu Painel](https://thegraph.com/studio/): "Criar um subgraph".
 
-Once your subgraph has been created, you can deploy your subgraph by using the `graph deploy` CLI command:
+Quando o seu subgraph estiver pronto, implante o seu subgraph com o comando de CLI `graph deploy`:
 
 ```sh
-$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
-$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+$ graph create --node <graph-node-url> <subgraph-name> # cria um subgraph num Graph Node local (no Subgraph Studio, isto é feito via a interface)
+$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # sobe os arquivos do build a um ponto final IPFS especificado, e implanta o subgraph num Graph Node com base no hash IPFS do manifest
 ```
 
 A configuração do nódulo dependerá de onde o subgraph será lançado.
@@ -228,15 +228,15 @@ Em breve, falaremos mais sobre como executar os componentes acima.
 
 ## Como Consultar um Subgraph na NEAR
 
-The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+O ponto final do GraphQL para subgraphs na NEAR é determinado pela definição do schema, com a interface existente da API. Visite a [documentação da API da GraphQL](/subgraphs/querying/graphql-api/) para mais informações.
 
 ## Exemplos de Subgraphs
 
 Aqui estão alguns exemplos de subgraphs para referência:
 
-[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+[Blocos da NEAR](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
 
-[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+[Recibos da NEAR](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
 
 ## Perguntas Frequentes
 
@@ -254,7 +254,7 @@ Atualmente, só há apoio a gatilhos de Blocos e Recibos. Estamos a investigar g
 
 ### Handlers de recibos ativarão para contas e subcontas?
 
-If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+Se uma conta (`account`) for especificada, ela só combinará com o nome exacto da conta. É possível corresponder subcontas ao especificar um campo `accounts`, com sufixos (`suffixes`) e prefixos (`prefixes`) particularizados para encontrar contas e subcontas. Por exemplo, todas as subcontas `mintbase1.near` seriam encontradas com o seguinte:
 
 ```yaml
 accounts:
@@ -276,8 +276,8 @@ No momento, não há apoio à funcionalidade de pendências para subgraphs na NE
 
 ### A minha pergunta não foi respondida. Onde posso conseguir mais ajuda sobre construir subgraphs na NEAR?
 
-If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+Se esta for uma pergunta geral sobre programação de subgraphs, há mais informações no resto da [documentação para programadores](/subgraphs/quick-start/). Caso contrário, entre no [Discord do Graph Protocol](https://discord.gg/graphprotocol) e pergunte no canal #near, ou mande a sua pergunta para near@thegraph.com.
 
 ## Referências
 
-- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)
+- [Documentação para programadores na NEAR](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From ef17318840cc17022cc439fc4823955a26c05335 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:40 -0500
Subject: [PATCH 3615/3820] New translations pruning.mdx (Portuguese)

---
 .../pages/pt/subgraphs/cookbook/pruning.mdx   | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/pruning.mdx b/website/pages/pt/subgraphs/cookbook/pruning.mdx
index ea95a8663387..630d5cb407fe 100644
--- a/website/pages/pt/subgraphs/cookbook/pruning.mdx
+++ b/website/pages/pt/subgraphs/cookbook/pruning.mdx
@@ -14,7 +14,7 @@ O `indexerHints` tem três opções de `prune`:
 
 - `prune: auto`: Guarda o histórico mínimo necessário, conforme configurado pelo Indexador, para otimizar o desempenho dos queries. Esta é a configuração geralmente recomendada e é padrão para todos os subgraphs criados pela `graph-cli` >= 0.66.0.
 - `prune: <Number of blocks to retain>`: Determina um limite personalizado no número de blocos históricos a serem retidos.
-- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+- `prune: never`: Não será feito pruning de dados históricos; guarda o histórico completo, e é o padrão caso não haja uma secção `indexerHints`. `prune: never` deve ser selecionado caso queira [Queries de Viagem no Tempo](/subgraphs/querying/graphql-api/#time-travel-queries).
 
 Podemos adicionar `indexerHints` aos nossos subgraphs ao atualizar o nosso `subgraph.yaml`:
 
@@ -32,24 +32,24 @@ dataSources:
 
 ## Considerações Importantes
 
-- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+- Se quiser fazer [Queries de Viagem no Tempo](/subgraphs/querying/graphql-api/#time-travel-queries) junto com pruning, o pruning deve ser realizado com precisão para manter a funcionalidade das Queries de Viagem no Tempo. Portanto, não recomendamos usar `indexerHints: prune: auto` com Queries de Viagem no Tempo. Em vez disto, use `indexerHints: prune: <Number of blocks to retain>` para fazer um pruning preciso até uma altura de bloco que preserve os dados históricos requeridos por Queries de Viagem no Tempo, ou use o `prune: never` para manter todos os dados.
 
-- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+- Não é possível criar [enxertos](/subgraphs/cookbook/grafting/) a uma altura de bloco que já tenha passado por pruning. Se enxertos forem realizados com frequência e o pruning for desejado, recomendamos usar `indexerHints: prune: <Number of blocks to retain>` que guardarão com precisão um número determinado de blocos (por ex., o suficiente para seis meses).
 
 ## Conclusão
 
 O pruning com `indexerHints` é uma boa prática para o desenvolvimento de subgraphs que oferece melhorias significativas no desempenho de queries.
 
-## Subgraph Best Practices 1-6
+## Melhores Práticas para um Subgraph 1 – 6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Pruning: Reduza o Excesso de Dados do Seu Subgraph para Acelerar Queries](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Use o @derivedFrom para Melhorar a Resposta da Indexação e de Queries](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Melhore o Desempenho da Indexação e de Queries com o Uso de Bytes como IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Evite `eth-calls` para Acelerar a Indexação](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Simplifique e Otimize com Séries Temporais e Agregações](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Lance Hotfixes Mais Rápido com Enxertos](/subgraphs/cookbook/grafting-hotfix/)

From d7f37fac0fa1b4a41fb270860022dd17ab7ed588 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:41 -0500
Subject: [PATCH 3616/3820] New translations secure-api-keys-nextjs.mdx
 (Portuguese)

---
 website/pages/pt/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/pt/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index 2fefb98cbe36..89af28fae063 100644
--- a/website/pages/pt/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/pt/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -120,4 +120,4 @@ Inicie o nosso aplicativo Next.js com `npm run dev`. Verifique se o componente d
 
 ### Conclusão
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.
+Ao utilizar os Componentes de Servidor Next.js, nós praticamente escondemos a chave API do client-side, o que aumenta a segurança do nosso aplicativo. Com este método, operações sensíveis podem ser executadas server-side, longe de vulnerabilidades em potencial no client-side. E finalmente, orientamos que explore [outras medidas de segurança de chave API](/subgraphs/querying/managing-api-keys/) para aumentar ainda mais a sua segurança de chaves API.

From 5853272617e889237a721b555d7c59d0cc6b41bc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:42 -0500
Subject: [PATCH 3617/3820] New translations subgraph-debug-forking.mdx
 (Portuguese)

---
 .../cookbook/subgraph-debug-forking.mdx       | 36 +++++++++----------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/pt/subgraphs/cookbook/subgraph-debug-forking.mdx
index 04e9a23e9ad7..2182cebcb1ba 100644
--- a/website/pages/pt/subgraphs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/pt/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -2,25 +2,25 @@
 title: Debugging de Subgraphs Rápido e Fácil Com Forks
 ---
 
-As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+Assim como vários sistemas que processam uma abundância de dados, os Indexadores do Graph (Graph Nodes) podem demorar um pouco para sincronizar o seu subgraph com a blockchain de destino. A discrepância entre mudanças rápidas para fins de debugging e os longos tempos de espera necessários para o indexing é extremamente contraprodutiva, e nós sabemos muito bem disso. É por isso que introduzimos o **forking de subgraphs**, programado pela [LimeChain](https://limechain.tech/); neste artigo. Veja como dá para acelerar bastante o debugging de subgraphs!
 
 ## Ok, o que é isso?
 
-**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+**Forking de subgraphs** é o processo de retirar entidades tranquilamente do armazenamento de _outro_ subgraph (normalmente, remoto).
 
-In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+No contexto do debugging, o **forking de subgraphs** permite debugar o seu subgraph falho no bloco _X_ sem precisar esperar que ele sincronize até o bloco _X_.
 
 ## O quê?! Como?!
 
-When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+Quando um subgraph é implementado a um Graph Node remoto para indexação, e ele falha no bloco _X_, a boa notícia é que o Graph Node ainda servirá queries GraphQL com seu armazenamento, que é sincronizado até o bloco _X_. Ótimo! Podemos aproveitar este armazenamento "atualizado" para consertar os bugs que surgem ao indexar o bloco _X_.
 
-In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+Resumindo, faremos um fork do subgraph falho de um Graph Node remoto para garantir que o subgraph seja indexado até o bloco _X_, para fornecer ao subgraph implantado localmente uma visão atualizada do estado da indexação; sendo este debugado no bloco _X_.
 
 ## Por favor, quero ver códigos!
 
-To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+Para manter a concentração no debugging de subgraphs, vamos começar com coisas simples: siga o [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) a indexar o contrato inteligente Ethereum Gravity.
 
-Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+Aqui estão os handlers definidos para a indexação dos `Gravatars`, sem qualquer bug:
 
 ```tsx
 export function handleNewGravatar(event: NewGravatar): void {
@@ -44,22 +44,22 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void {
 }
 ```
 
-Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+Que pena! Quando eu implanto o meu lindo subgraph no Subgraph Studio, ele falha com o erro "Gravatar not found" (Gravatar não encontrado).
 
 A maneira mais comum de tentar consertar este erro é:
 
 1. Fazer uma mudança na fonte dos mapeamentos, que talvez possa resolver o problema (mas é claro que não vai).
-2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+2. Implante o subgraph novamente no [Subgraph Studio](https://thegraph.com/studio/) (ou outro Graph Node remoto).
 3. Esperar que ele se sincronize.
 4. Se quebrar novamente, volte ao passo 1. Se não: Eba!
 
-It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+É um típico processo ordinário de debug, mas há um passo que atrasa muito o processo: _3. Esperar que ele se sincronize._
 
-Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+Com o **forking de subgraphs**, essencialmente, podemos eliminar este passo. É mais ou menos assim:
 
-0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+0. Crie um Graph Node local com o conjunto de **_fork-base apropriado_**.
 1. Faça uma mudança na fonte dos mapeamentos, que talvez possa resolver o problema.
-2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+2. Implante-o no Graph Node local, **faça um fork do subgraph falho**, e **comece do bloco problemático_**.
 3. Se quebrar novamente, volte ao passo 1. Se não: Eba!
 
 Agora, você deve ter duas perguntas:
@@ -69,18 +69,18 @@ Agora, você deve ter duas perguntas:
 
 E eu respondo:
 
-1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+1. `fork-base` é o URL "base", tal que quando a _id de subgraph_ é atrelada, o URL resultante (<fork-base>/<subgraph-id>) se torna um ponto final GraphQL válido para o armazenamento do subgraph.
 2. Forking é fácil, não precisa se preocupar:
 
 ```bash
 $ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
 ```
 
-Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+Aliás, não esqueça de preencher o campo `dataSources.source.startBlock` no manifest do subgraph com o número do bloco problemático, para pular a indexação de blocos desnecessários e tomar vantagem do fork!
 
 Aqui está o que eu faço:
 
-1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+1. Eu crio um Graph Node local ([veja como](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) com a opção `fork-base` de `https://api.thegraph.com/subgraphs/id/`, já que eu vou forkar um subgraph, o bugado que eu lancei anteriormente, do [Subgraph Studio](https://thegraph.com/studio/).
 
 ```
 $ cargo run -p graph-node --release -- \
@@ -90,8 +90,8 @@ $ cargo run -p graph-node --release -- \
     --fork-base https://api.thegraph.com/subgraphs/id/
 ```
 
-2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
-3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+2. Após vistoriar com cuidado, percebo uma discrepância nas representações de `id` usadas ao indexar `Gravatar`s nos meus dois handlers. Enquanto `handleNewGravatar` o converte a um hex (`event.params.id.toHex()`), o `handleUpdatedGravatar` usa um int32 (`event.params.id.toI32()`). Assim, o `handleUpdatedGravatar` entra em pânico com o "Gravatar não encontrado!". Eu faço os dois converterem o `id` em um hex.
+3. Após ter feito as mudanças, implanto o meu subgraph no Graph Node local, **_fazendo um fork do subgraph falho_** e programando o `dataSources.source.startBlock` em `6190343` no `subgraph.yaml`:
 
 ```bash
 $ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020

From 2fa68cbf9be6f61c50593c45468e9c40bdd4ecd6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:43 -0500
Subject: [PATCH 3618/3820] New translations subgraph-uncrashable.mdx
 (Portuguese)

---
 .../pt/subgraphs/cookbook/subgraph-uncrashable.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/pt/subgraphs/cookbook/subgraph-uncrashable.mdx
index 7f0a48eb91ab..522740ee8246 100644
--- a/website/pages/pt/subgraphs/cookbook/subgraph-uncrashable.mdx
+++ b/website/pages/pt/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -2,19 +2,19 @@
 title: Gerador de Código Seguro para Subgraphs
 ---
 
-[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+O [Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) é uma ferramenta geradora de código, que gera um conjunto de funções de helper a partir do schema GraphQL de um projeto. Ela garante total segurança e consistência em todas as interações com entidades no seu subgraph.
 
 ## Por que integrar com a Subgraph Uncrashable?
 
-- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+- **Atividade Contínua**. Entidades mal-cuidadas podem causar panes em subgraphs, o que pode ser perturbador para projetos dependentes no The Graph. Prepare funções de helper para deixar os seus subgraphs "impossíveis de travar" e garantir a continuidade dos negócios.
 
-- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+- **Totalmente Seguro**. Alguns dos problemas comuns vistos na programação de subgraphs são problemas de carregamento de entidades não definidas; o não-preparo ou inicialização de todos os valores de entidades; e condições de corrida sobre carregamento e salvamento de entidades. Garanta que todas as interações com entidades sejam completamente atômicas.
 
-- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+- **Configurável pelo Utilizador**. Determine valores padrão e configure o nível necessário de verificações de segurança para o seu projeto. São gravados registros de aviso que indicam onde há uma brecha de lógica no subgraph, auxiliando o processo de solução de problemas e garantir a precisão dos dados.
 
-**Key Features**
+**Características Importantes**
 
-- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+- A ferramenta de geração de código acomoda **todos** os tipos de subgraph e pode ser configurada para que os utilizadores coloquem padrões razoáveis nos valores. A geração de código usará esta configuração para gerar funções de helper que combinem com a especificação do utilizador.
 
 - A estrutura também inclui uma maneira (através do arquivo de configuração) de criar funções personalizadas, mas seguras, para configurar grupos de variáveis de entidade. Desta maneira, é impossível que o utilizador carregue/use uma entidade de graph obsoleta, e também é impossível esquecer de salvar ou determinar uma variável exigida pela função.
 
@@ -26,4 +26,4 @@ A Subgraph Uncrashable pode ser executada como flag opcional usando o comando co
 graph codegen -u [options] [<subgraph-manifest>]
 ```
 
-Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.
+Visite a [documentação do Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/docs/) ou veja este [tutorial em vídeo](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) para aprender como programar subgraphs mais seguros.

From c96cbb5927092d4225545aba0f680f8fcc2aee55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:44 -0500
Subject: [PATCH 3619/3820] New translations timeseries.mdx (Portuguese)

---
 .../pt/subgraphs/cookbook/timeseries.mdx      | 148 +++++++++---------
 1 file changed, 74 insertions(+), 74 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/timeseries.mdx b/website/pages/pt/subgraphs/cookbook/timeseries.mdx
index 9c2a8632c5b6..3ec998209ca3 100644
--- a/website/pages/pt/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/pt/subgraphs/cookbook/timeseries.mdx
@@ -1,48 +1,48 @@
 ---
-title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+title: "Melhores Práticas para um Subgraph #5 — Simplifique e Otimize com Séries Temporais e Agregações"
 ---
 
 ## TLDR
 
-Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+Tirar vantagem de séries temporais e agregações em subgraphs pode melhorar bastante a velocidade da indexação e o desempenho dos queries.
 
 ## Visão geral
 
-Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+Séries temporais e agregações reduzem a sobrecarga do processamento de dados e aceleram queries, ao descarregar computações de agregação para o banco de dados e simplificar o código de mapeamento. Essa abordagem é particularmente eficaz ao lidar com grandes volumes de dados baseados em tempo.
 
-## Benefits of Timeseries and Aggregations
+## Vantagens de Séries Temporais e Agregações
 
-1. Improved Indexing Time
+1. **Indexação Mais Rápida**
 
-- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
-- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+- Menos Dados para Carregar: Os mapeamentos manuseiam menos dados, pois os pontos de dados brutos são armazenados como entidades imutáveis de séries temporais.
+- Agregações Geridas pelo Banco de Dados: As agregações são computadas automaticamente pelo banco de dados, reduzindo a carga de trabalho nos mapeamentos.
 
-2. Simplified Mapping Code
+2. **Código de Mapeamentos Simplificado**
 
-- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
-- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+- Sem Cálculos Manuais: os programadores não precisam mais escrever lógica complexa de agregação em mapeamentos.
+- Complexidade Reduzida: Simplifica a manutenção de código e minimiza o potencial de erros.
 
-3. Dramatically Faster Queries
+3. **Queries Muito Mais Rápidos**
 
-- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
-- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+- Dados Imutáveis: Todos os dados de séries temporais são imutáveis, deixando o armazenamento e resgate de dados muito mais eficiente.
+- Separação de Dados Eficiente: Os dados agregados são armazenados separadamente dos brutos de séries temporais, permitindo que os queries processem muito menos dados — geralmente várias ordens de magnitude a menos.
 
 ### Considerações Importantes
 
-- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
-- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
-- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+- Dados Imutáveis: os dados de séries temporais não podem ser alterados após gravados, garantindo a integridade e simplificando a indexação.
+- Gestão Automática de ID e Registos de Tempo: os campos de ID, e de registo de data e hora, são administrados automaticamente pelo graph-node, reduzindo possíveis erros.
+- **Armazenamento Eficiente:** ao separar dados brutos dos agregados, o armazenamento é otimizado e queries são executados mais rapidamente.
 
-## How to Implement Timeseries and Aggregations
+## Como Implementar Séries Temporais e Agregações
 
-### Defining Timeseries Entities
+### Como Definir Entidades de Séries Temporais
 
-A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+Uma entidade de série temporal representa pontos de dados brutos coletados gradativamente. Ela é definida com a anotação `@entity(timeseries: true)`. Requisitos principais:
 
-- Immutable: Timeseries entities are always immutable.
-- Mandatory Fields:
-  - `id`: Must be of type `Int8!` and is auto-incremented.
-  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+- Imutável: Entidades de série temporal são sempre imutáveis.
+- Campos Obrigatórios:
+  - `id`: Deve ser do tipo `Int8!` e é automaticamente incrementada.
+  - `timestamp`: Deve ser do tipo `Timestamp!` e é automaticamente configurada no registro de data e hora do bloco.
 
 Exemplo:
 
@@ -54,12 +54,12 @@ type Data @entity(timeseries: true) {
 }
 ```
 
-### Defining Aggregation Entities
+### Como Definir Entidades de Agregação
 
-An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+Uma entidade de agregação calcula valores agregados de uma fonte de série temporal. Ela é definida com a anotação `@aggregation`. Componentes principais:
 
-- Annotation Arguments:
-  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+- Argumentos de Anotação:
+  - `intervals`: Especifica intervalos de tempo (por exemplo: `["hour", "day"]`).
 
 Exemplo:
 
@@ -71,11 +71,11 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+Neste exemplo, o campo `Stats` ("Estatísticas") agrega o campo de preços de Data de hora em hora, diariamente, e computa a soma.
 
-### Querying Aggregated Data
+### Queries de Dados Agregados
 
-Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+As agregações são expostas via campos de query que permitem filtragem e resgate com base em dimensões e intervalos de tempo.
 
 Exemplo:
 
@@ -97,13 +97,13 @@ Exemplo:
 }
 ```
 
-### Using Dimensions in Aggregations
+### Como Usar Dimensões em Agregações
 
-Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+Dimensões são campos não agregados, usados ​​para agrupar pontos de dados. Elas permitem agregações com base em critérios específicos, como um token num aplicativo financeiro.
 
 Exemplo:
 
-### Timeseries Entity
+### Entidade de Série Temporal
 
 ```graphql
 type TokenData @entity(timeseries: true) {
@@ -115,7 +115,7 @@ type TokenData @entity(timeseries: true) {
 }
 ```
 
-### Aggregation Entity with Dimension
+### Entidade de Agregação com Dimensão
 
 ```graphql
 type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
@@ -128,67 +128,67 @@ type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
 }
 ```
 
-- Dimension Field: token groups the data, so aggregates are computed per token.
-- Aggregates:
-  - totalVolume: Sum of amount.
-  - priceUSD: Last recorded priceUSD.
-  - count: Cumulative count of records.
+- Campo de Dimensão: `token` agrupa os dados, então os agregados são computados por token.
+- Dados Agregados:
+  - totalVolume: Soma da quantia.
+  - priceUSD: último `priceUSD` (preço em dólares americanos) registrado.
+  - count: Contagem cumulativa dos registos.
 
-### Aggregation Functions and Expressions
+### Funções e Expressões de Agregação
 
-Supported aggregation functions:
+Funções de agregação apoiadas:
 
-- sum
-- count
-- min
-- max
-- first
-- last
+- sum ("Soma")
+- count ("Contagem")
+- min ("Mínimo")
+- max ("Máximo")
+- first ("Primeiro")
+- last ("Último")
 
-### The arg in @aggregate can be
+### O argumento em @aggregate pode ser
 
-- A field name from the timeseries entity.
-- An expression using fields and constants.
+- Um nome de campo da entidade de série temporal.
+- Uma expressão com campos e constantes.
 
-### Examples of Aggregation Expressions
+### Exemplos de Expressões de Agregação
 
-- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
-- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
-- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+- Soma do Valor do Token: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Quantia Positiva Máxima: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Soma Condicional: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
 
-Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+Os operadores e funções suportados incluem aritmética básica (+, -, \_, /), operadores de comparação, operadores lógicos (`and`, `or`, `not`) e funções SQL como `least`, `greatest`, `coalesce`, etc.
 
-### Query Parameters
+### Parâmetros de Query
 
-- interval: Specifies the time interval (e.g., "hour").
-- where: Filters based on dimensions and timestamp ranges.
-- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+- `interval`: Especifica intervalos de tempo (por exemplo: "hour").
+- `where`: Aplica filtros com base em dimensões e alcance de tempo.
+- `timestamp_gte` / `timestamp_lt: ` Aplica filtros para início e fim de tempo (microssegundos desde o epoch).
 
-### Notes
+### Notas
 
-- Sorting: Results are automatically sorted by timestamp and id in descending order.
-- Current Data: An optional current argument can include the current, partially filled interval.
+- Classificação: Os resultados são automaticamente organizados por data e hora, e id, em ordem descendente.
+- Dados Atuais: Um argumento atual opcional pode incluir o intervalo corrente, parcialmente preenchido.
 
 ### Conclusão
 
-Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+Implementar séries temporais e agregações em subgraphs é recomendado para projetos que lidam com dados baseados em tempo. Esta abordagem:
 
-- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
-- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
-- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+- Melhora o Desempenho: Acelera a indexação e os queries ao reduzir a carga de processamento de dados.
+- Simplifica a Produção: Elimina a necessidade de lógica de agregação manual em mapeamentos.
+- Escala Eficientemente: Manuseia grandes quantias de dados sem comprometer a velocidade ou a capacidade de resposta.
 
-By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+Ao adotar esse padrão, os programadores podem criar subgraphs mais eficientes e escaláveis, fornecendo acesso mais rápido e confiável de dados aos utilizadores finais. Para saber mais sobre como implementar séries temporais e agregações, consulte o [Leia-me sobre Séries Temporais e Agregações](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) e experimente esse recurso nos seus subgraphs.
 
-## Subgraph Best Practices 1-6
+## Melhores Práticas para um Subgraph 1 – 6
 
-1. [Improve Query Speed with Subgraph Pruning](/subgraphs/cookbook/pruning/)
+1. [Pruning: Reduza o Excesso de Dados do Seu Subgraph para Acelerar Queries](/subgraphs/cookbook/pruning/)
 
-2. [Improve Indexing and Query Responsiveness by Using @derivedFrom](/subgraphs/cookbook/derivedfrom/)
+2. [Use o @derivedFrom para Melhorar a Resposta da Indexação e de Queries](/subgraphs/cookbook/derivedfrom/)
 
-3. [Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
+3. [Melhore o Desempenho da Indexação e de Queries com o Uso de Bytes como IDs](/subgraphs/cookbook/immutable-entities-bytes-as-ids/)
 
-4. [Improve Indexing Speed by Avoiding `eth_calls`](/subgraphs/cookbook/avoid-eth-calls/)
+4. [Evite `eth-calls` para Acelerar a Indexação](/subgraphs/cookbook/avoid-eth-calls/)
 
-5. [Simplify and Optimize with Timeseries and Aggregations](/subgraphs/cookbook/timeseries/)
+5. [Simplifique e Otimize com Séries Temporais e Agregações](/subgraphs/cookbook/timeseries/)
 
-6. [Use Grafting for Quick Hotfix Deployment](/subgraphs/cookbook/grafting-hotfix/)
+6. [Lance Hotfixes Mais Rápido com Enxertos](/subgraphs/cookbook/grafting-hotfix/)

From 7bfb6c8a30ebea1c292def5672f2bd41d490e8f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:45 -0500
Subject: [PATCH 3620/3820] New translations transfer-to-the-graph.mdx
 (Portuguese)

---
 .../cookbook/transfer-to-the-graph.mdx        | 84 +++++++++----------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/pt/subgraphs/cookbook/transfer-to-the-graph.mdx
index 292d1f663b2f..e5ad802a2941 100644
--- a/website/pages/pt/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/pt/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -1,35 +1,35 @@
 ---
-title: Tranfer to The Graph
+title: Transfira-se para The Graph
 ---
 
-Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+Migre rapidamente os seus subgraphs, de qualquer plataforma para a [rede descentralizada do The Graph](https://thegraph.com/networks/).
 
-## Benefits of Switching to The Graph
+## Vantagens de Trocar para The Graph
 
-- Use the same subgraph that your apps already use with zero-downtime migration.
-- Increase reliability from a global network supported by 100+ Indexers.
-- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+- Use o mesmo subgraph que os seus aplicativos já usam, com migração sem tempo de ócio.
+- Aumenta a confiabilidade de uma rede global mantida por mais de 100 Indexadores.
+- Receba suporte rápido para subgraphs, com uma equipa de engenharia de plantão disponível a todas as horas.
 
-## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+## Atualize o Seu Subgraph para The Graph em 3 Etapas Fáceis
 
-1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
-2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
-3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+1. [Construa o Seu Ambiente do Studio](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Implante o Seu Subgraph no Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+3. [Edite na The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
 
-## 1. Set Up Your Studio Environment
+## Construa o Seu Ambiente do Studio
 
-### Create a Subgraph in Subgraph Studio
+### Como Criar um Subgraph no Subgraph Studio
 
-- Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
-- Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+- Entre no [Subgraph Studio](https://thegraph.com/studio/) e conecte a sua carteira de criptomoedas.
+- Clique em "Create a Subgraph" ("Criar um Subgraph"). É recomendado nomear o subgraph em caixa de título: por exemplo, "Nome De Subgraph Nome da Chain".
 
-> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+> Observação: após a edição, o nome do subgraph poderá ser editado, mas isto sempre exigirá uma ação on-chain sempre, então pense bem no nome que irá dar.
 
-### Install the Graph CLI⁠
+### Instale a Graph CLI
 
-You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+É necessário ter [Node.js](https://nodejs.org/) e um gerenciador de pacotes da sua escolha (`npm` ou `pnpm`) instalados, para usar a Graph CLI. Verifique a versão [mais recente](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) da CLI.
 
-On your local machine, run the following command:
+Na sua máquina local, execute o seguinte comando:
 
 Uso de [npm](https://www.npmjs.com/):
 
@@ -37,68 +37,68 @@ Uso de [npm](https://www.npmjs.com/):
 npm install -g @graphprotocol/graph-cli@latest
 ```
 
-Use the following command to create a subgraph in Studio using the CLI:
+Use o comando a seguir para criar um subgraph no Studio com a CLI:
 
 ```sh
 graph init --product subgraph-studio
 ```
 
-### Authenticate Your Subgraph
+### Autentique o Seu Subgraph
 
-In The Graph CLI, use the auth command seen in Subgraph Studio:
+Na Graph CLI, use o comando `auth` visto no Subgraph Studio:
 
 ```sh
 graph auth <your-auth-code>
 ```
 
-## 2. Deploy Your Subgraph to Studio
+## 2. Implante o Seu Subgraph no Studio
 
-If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+Se tiver o seu código-fonte, pode facilmente implantá-lo no Studio. Se não o tiver, aqui está uma maneira rápida de implantar o seu subgraph.
 
-In The Graph CLI, run the following command:
+Na The Graph CLI, execute o seguinte comando:
 
 ```sh
 graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
 
 ```
 
-> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+> **Observação:** Cada subgraph tem um hash IPFS (ID de Implantação), que se parece com isto: "Qmasdfad...". Para implantar, basta usar este **hash IPFS**. Aparecerá uma solicitação de versão (por exemplo, v0.0.1).
 
-## 3. Publish Your Subgraph to The Graph Network
+## 3. Edite o Seu Subgraph na The Graph Network
 
-![publish button](/img/publish-sub-transfer.png)
+![Botão de edição](/img/publish-sub-transfer.png)
 
-### Query Your Subgraph
+### Faça um Query
 
-> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+> Para atrair cerca de 3 indexadores para fazer queries no seu subgraph, recomendamos curar pelo menos 3.000 GRT. Para saber mais sobre a curadoria, leia sobre [Curadoria](/resources/roles/curating/) no The Graph.
 
-You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+Dá para começar a [fazer queries](/subgraphs/querying/introduction/) em qualquer subgraph enviando um query GraphQL para o ponto final da URL de query do subgraph, localizado na parte superior da página do Explorer no Subgraph Studio.
 
 #### Exemplo
 
-[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+[Subgraph: CryptoPunks Ethereum](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) por Messari:
 
-![Query URL](/img/cryptopunks-screenshot-transfer.png)
+![URL de Query](/img/cryptopunks-screenshot-transfer.png)
 
-The query URL for this subgraph is:
+A URL de queries para este subgraph é:
 
 ```sh
-https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+https://gateway-arbitrum.network.thegraph.com/api/`**sua-chave-de-api**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
 ```
 
-Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+Agora, você só precisa preencher **sua própria chave de API** para começar a enviar queries GraphQL para este ponto final.
 
-### Getting your own API Key
+### Como adquirir sua própria Chave de API
 
-You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+É possível riar chaves de API no Subgraph Studio na aba “Chaves de API” na parte superior da página:
 
-![API keys](/img/Api-keys-screenshot.png)
+![Chaves de API](/img/Api-keys-screenshot.png)
 
-### Monitor Subgraph Status
+### Como Monitorar o Estado do Seu Subgraph
 
-Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+Após a atualização, poderá acessar e gerir os seus subgraphs no [Subgraph Studio](https://thegraph.com/studio/) e explorar todos os subgraphs no [The Graph Explorer](https://thegraph.com/networks/).
 
 ### Outros Recursos
 
-- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
-- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).
+- Para criar e editar um novo subgraph, veja o [Guia de Início Rápido](/subgraphs/quick-start/).
+- Para explorar todas as maneiras de otimizar e personalizar o seu subgraph para melhor desempenho, leia mais sobre [como criar um subgraph aqui](/developing/creating-a-subgraph/).

From 1433c64da36af526ea981785bf224f15ffabd740 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:46 -0500
Subject: [PATCH 3621/3820] New translations explorer.mdx (Portuguese)

---
 website/pages/pt/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs/explorer.mdx b/website/pages/pt/subgraphs/explorer.mdx
index 29a699d08a95..cf8a73228ef2 100644
--- a/website/pages/pt/subgraphs/explorer.mdx
+++ b/website/pages/pt/subgraphs/explorer.mdx
@@ -67,7 +67,7 @@ Indexers are the backbone of the protocol. They stake on subgraphs, index them,
 
 In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
 
-**Specifics**
+**Detalhes**
 
 - Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
 - Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.

From 0442a338f81b89242fcb42118c3b7bc522c09d90 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:47 -0500
Subject: [PATCH 3622/3820] New translations quick-start.mdx (Portuguese)

---
 website/pages/pt/subgraphs/quick-start.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/pt/subgraphs/quick-start.mdx b/website/pages/pt/subgraphs/quick-start.mdx
index 23980d4e71db..d77673590137 100644
--- a/website/pages/pt/subgraphs/quick-start.mdx
+++ b/website/pages/pt/subgraphs/quick-start.mdx
@@ -15,11 +15,11 @@ Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/
 
 ### 1. Create a subgraph in Subgraph Studio
 
-Go to [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
+Entre no [Subgraph Studio](https://thegraph.com/studio/) e conecte a sua carteira de criptomoedas.
 
 Subgraph Studio lets you create, manage, deploy, and publish subgraphs, as well as create and manage API keys.
 
-Click "Create a Subgraph". It is recommended to name the subgraph in Title Case: "Subgraph Name Chain Name".
+Clique em "Create a Subgraph" ("Criar um Subgraph"). É recomendado nomear o subgraph em caixa de título: por exemplo, "Nome De Subgraph Nome da Chain".
 
 ### 2. Como instalar o Graph CLI
 

From 8dff8cf9b32be396f64ce396f897c6936692b4be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:48 -0500
Subject: [PATCH 3623/3820] New translations assemblyscript-migration-guide.mdx
 (Turkish)

---
 .../assemblyscript-migration-guide.mdx        | 42 +++++++++----------
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx
index 7c75050c0696..820aaf91a967 100644
--- a/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -425,14 +425,14 @@ export class Something {
 }
 ```
 
-The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+Derleyici hata verecektir çünkü sınıf olan özellikler için ya bir ilklendirici eklemeniz ya da `!` operatörünü eklemeniz gerekmektedir:
 
 ```typescript
 export class Something {
   constructor(public value: Thing) {}
 }
 
-// or
+// veya
 
 export class Something {
   value: Thing
@@ -442,30 +442,30 @@ export class Something {
   }
 }
 
-// or
+// veya
 
 export class Something {
   value!: Thing
 }
 ```
 
-### Array initialization
+### Dizi ilklendirmesi
 
-The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+`Array` sınıfı, listenin uzunluğunu ilklendirmek için bir sayı kabul etmeye devam eder. Ancak `.push` gibi işlemler başlangıca eklemek yerine boyutu gerçekten artıracağı için dikkatli olmalısınız, örneğin:
 
 ```typescript
 let arr = new Array<string>(5) // ["", "", "", "", ""]
 
-arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
+arr.push('something') // ["", "", "", "", "", "something"] // uzunluk 6 :(
 ```
 
-Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
+Kullandığınız tiplere bağlı olarak -mesela null olabilen değerler kullanıyorsunuz- ve bu tiplere erişim şeklinize göre, aşağıdaki gibi bir çalıştırma hatasıyla karşılaşabilirsiniz:
 
 ```
 ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
 ```
 
-To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+Listenin başına "push" yapabilmek için, `Array`'i ya şu şekilde sıfır boyutla ilklendirmelisiniz:
 
 ```typescript
 let arr = new Array<string>(0) // []
@@ -473,7 +473,7 @@ let arr = new Array<string>(0) // []
 arr.push('something') // ["something"]
 ```
 
-Or you should mutate it via index:
+Ya da dizin kullanarak değiştirmelisiniz:
 
 ```typescript
 let arr = new Array<string>(5) // ["", "", "", "", ""]
@@ -481,11 +481,11 @@ let arr = new Array<string>(5) // ["", "", "", "", ""]
 arr[0] = 'something' // ["something", "", "", "", ""]
 ```
 
-### GraphQL schema
+### GraphQL şeması
 
-This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+Bu doğrudan bir AssemblyScript değişikliği değildir. Ancak `schema.graphql` dosyanızı güncellemeniz gerekebilir.
 
-Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
+Artık türlerinizde Non-Nullable Lists (Boş Olamayan Listeler) olarak alanlar tanımlayamazsınız. Eğer böyle bir şemanız varsa:
 
 ```graphql
 type Something @entity {
@@ -494,11 +494,11 @@ type Something @entity {
 
 type MyEntity @entity {
   id: Bytes!
-  invalidField: [Something]! # no longer valid
+  invalidField: [Something]! # artık geçerli değil
 }
 ```
 
-You'll have to add an `!` to the member of the List type, like this:
+Listenin tür üyesine şu şekilde `!` eklemeniz gerekecek:
 
 ```graphql
 type Something @entity {
@@ -507,18 +507,18 @@ type Something @entity {
 
 type MyEntity @entity {
   id: Bytes!
-  invalidField: [Something!]! # valid
+  invalidField: [Something!]! # geçerli
 }
 ```
 
-This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+Bu değişiklik, AssemblyScript sürümleri arasındaki null olabilme farklılıklarından dolayı oldu. Ve bu değişiklik `src/generated/schema.ts` dosyasıyla ilgilidir (varsayılan yol, bunu değiştirmiş olabilirsiniz).
 
 ### Diğer
 
-- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
-- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- `Map#set` ve `Set#add` ögelerini, `this` döndürecek şekilde spesifikasyonla uyumlu hale getirdik ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Diziler artık ArrayBufferView'den gelmek yerine artık farklı ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0)) sürümünden geliyorlar
+- Nesne literalinden başlatılan sınıflar artık yapıcı bir metot tanımlayamaz ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
 - The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
-- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- `bool` dönüşümünde `NaN`' değeri `false` değerine zorla dönüştürülür ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
 - When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
-- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Boyutlar farklı olduğunda ilişkisel dize karşılaştırmalarında olan hatanın düzeltmesi ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From f975ccd2eed24b71481cf0708f62da21dae73b2d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 13:39:50 -0500
Subject: [PATCH 3624/3820] New translations polymarket.mdx (Portuguese)

---
 .../pt/subgraphs/cookbook/polymarket.mdx      | 68 +++++++++----------
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/website/pages/pt/subgraphs/cookbook/polymarket.mdx b/website/pages/pt/subgraphs/cookbook/polymarket.mdx
index 982bae6c05bc..e17b4fa17b6d 100644
--- a/website/pages/pt/subgraphs/cookbook/polymarket.mdx
+++ b/website/pages/pt/subgraphs/cookbook/polymarket.mdx
@@ -1,22 +1,22 @@
 ---
-title: Querying Blockchain Data from Polymarket with Subgraphs on The Graph
+title: Como Consultar Dados de Blockchain do Polymarket com Subgraphs no The Graph
 ---
 
-Query Polymarket’s onchain data using GraphQL via subgraphs on The Graph Network. Subgraphs are decentralized APIs powered by The Graph, a protocol for indexing & querying data from blockchains.
+Consulte os dados na chain do Polymarket usando a GraphQL via subgraphs na The Graph Network. Subgraphs são APIs descentralizadas energizadas pelo The Graph, um protocolo para indexação e consulta de dados de blockchains.
 
-## Polymarket Subgraph on Graph Explorer
+## Subgraph do Polymarket no Graph Explorer
 
-You can see an interactive query playground on the [Polymarket subgraph’s page on The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), where you can test any query.
+Dá para ver um playground interativo de queries na [página do subgraph do Polymarket no The Graph Explorer](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one), onde você pode testar qualquer query.
 
-![Polymarket Playground](/img/Polymarket-playground.png)
+![Playground da Polymarket](/img/Polymarket-playground.png)
 
-## How to use the Visual Query Editor
+## Como Usar o Editor Visual de Queries
 
-The visual query editor helps you test sample queries from your subgraph.
+O editor visual de queries permite-te testar exemplos de query do seu subgraph.
 
-You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on the fields you want.
+Você pode usar o GraphiQL Explorer para compor os seus queries da GraphQL clicando nos campos desejados.
 
-### Example Query: Get the top 5 highest payouts from Polymarket
+### Exemplo de Query: 5 maiores pagamentos do Polymarket
 
 ```
 {
@@ -29,7 +29,7 @@ You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on
 }
 ```
 
-### Example output
+### Exemplo de retorno
 
 ```
 {
@@ -70,41 +70,41 @@ You can use the GraphiQL Explorer to compose your GraphQL queries by clicking on
 }
 ```
 
-## Polymarket's GraphQL Schema
+## Schema da GraphQL do Polymarket
 
-The schema for this subgraph is defined [here in Polymarket’s GitHub](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
+O esquema deste subgraph é definido [aqui no GitHub do Polymarket](https://github.com/Polymarket/polymarket-subgraph/blob/main/polymarket-subgraph/schema.graphql).
 
-### Polymarket Subgraph Endpoint
+### Ponto Final do Subgraph do Polymarket
 
 https://gateway.thegraph.com/api/{api-key}/subgraphs/id/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp
 
-The Polymarket Subgraph endpoint is available on [Graph Explorer](https://thegraph.com/explorer).
+O ponto final do subgraph do Polymarket está disponível no [Graph Explorer](https://thegraph.com/explorer).
 
-![Polymarket Endpoint](/img/Polymarket-endpoint.png)
+![Ponto Final do Polymarket](/img/Polymarket-endpoint.png)
 
-## How to Get your own API Key
+## Como Adquirir sua Própria Chave de API
 
-1. Go to [https://thegraph.com/studio](http://thegraph.com/studio) and connect your wallet
-2. Go to https://thegraph.com/studio/apikeys/ to create an API key
+1. Entre em [https://thegraph.com/studio](http://thegraph.com/studio) e conecte a sua carteira de criptomoedas
+2. Crie uma chave de API em https://thegraph.com/studio/apikeys/
 
-You can use this API key on any subgraph in [Graph Explorer](https://thegraph.com/explorer), and it’s not limited to just Polymarket.
+Esta chave de API vale para qualquer subgraph no [Graph Explorer](https://thegraph.com/explorer), não apenas no Polymarket.
 
-100k queries per month are free which is perfect for your side project!
+Cem mil queries por mês de graça, perfeito para um projeto paralelo!
 
-## Additional Polymarket Subgraphs
+## Subgraphs Adicionais do Polymarket
 
 - [Polymarket](https://thegraph.com/explorer/subgraphs/81Dm16JjuFSrqz813HysXoUPvzTwE7fsfPk2RTf66nyC?view=Query&chain=arbitrum-one)
-- [Polymarket Activity Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
-- [Polymarket Profit & Loss](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
-- [Polymarket Open Interest](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
+- [Polymarket — Atividade na Polygon](https://thegraph.com/explorer/subgraphs/Bx1W4S7kDVxs9gC3s2G6DS8kdNBJNVhMviCtin2DiBp?view=Query&chain=arbitrum-one)
+- [Polymarket — Lucro e Prejuízo](https://thegraph.com/explorer/subgraphs/6c58N5U4MtQE2Y8njfVrrAfRykzfqajMGeTMEvMmskVz?view=Query&chain=arbitrum-one)
+- [Polymarket — Contratos em Aberto](https://thegraph.com/explorer/subgraphs/ELaW6RtkbmYNmMMU6hEPsghG9Ko3EXSmiRkH855M4qfF?view=Query&chain=arbitrum-one)
 
-## How to Query with the API
+## Como fazer Queries com a API
 
-You can pass any GraphQL query to the Polymarket endpoint and receive data in json format.
+Qualquer query da GraphQL pode ser passada para o ponto final do Polymarket; os dados serão recebidos no formato json.
 
-This following code example will return the exact same output as above.
+O exemplo de código a seguir retornará exatamente o mesmo resultado que acima.
 
-### Sample Code from node.js
+### Exemplo de Código do node.js
 
 ```
 const axios = require('axios');
@@ -126,22 +126,22 @@ const graphQLRequest = {
   },
 };
 
-// Send the GraphQL query
+// Mandar o query da GraphQL
 axios(graphQLRequest)
   .then((response) => {
-    // Handle the response here
+    // Controlar a resposta aqui
     const data = response.data.data
     console.log(data)
 
   })
   .catch((error) => {
-    // Handle any errors
+    // Controlar quaisquer erros
     console.error(error);
   });
 ```
 
-### Additional resources
+### Outros Recursos
 
-For more information about querying data from your subgraph, read more [here](/subgraphs/querying/introduction/).
+Para mais informações sobre queries de dados do seu subgraph, leia mais [aqui](/subgraphs/querying/introduction/).
 
-To explore all the ways you can optimize & customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).
+Para explorar todas as maneiras de otimizar e personalizar o seu subgraph para melhor desempenho, leia mais sobre [como criar um subgraph aqui](/developing/creating-a-subgraph/).

From 11a851dceee4dd3626fa0fd95e0036922bc0d3a6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 15:59:04 -0500
Subject: [PATCH 3625/3820] New translations assemblyscript-migration-guide.mdx
 (Turkish)

---
 .../release-notes/assemblyscript-migration-guide.mdx          | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx
index 820aaf91a967..acefdc46b80a 100644
--- a/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/tr/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -518,7 +518,7 @@ Bu değişiklik, AssemblyScript sürümleri arasındaki null olabilme farklılı
 - `Map#set` ve `Set#add` ögelerini, `this` döndürecek şekilde spesifikasyonla uyumlu hale getirdik ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
 - Diziler artık ArrayBufferView'den gelmek yerine artık farklı ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0)) sürümünden geliyorlar
 - Nesne literalinden başlatılan sınıflar artık yapıcı bir metot tanımlayamaz ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- Bir `**` ikili işleminin sonucu artık her iki işlenen de tamsayı ise ortak payda tamsayısıdır. Önceden, sonuç `Math/f.pow` çağrılmış gibi bir float'tı ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
 - `bool` dönüşümünde `NaN`' değeri `false` değerine zorla dönüştürülür ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
-- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
+- `i8`/`u8` ya da `i16`/`u16` tipindeki küçük tamsayı değerlerini kaydırırken, RHS değerinin yalnızca sırasıyla en düşük 3 ve 4 anlamlı biti sonucu etkiler. Bu, bir `i32.shl` sonucu yalnızca RHS değerinin 5 en düşük anlamlı bitinden etkilenmesine benzer. Örnek: `someI8 << 8` önceden `0` değerini üretirken, şimdi RHS'ın `8 & 7 = 0` (3 bit) olarak maskelenmesinden dolayı `someI8` değerini üretir ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
 - Boyutlar farklı olduğunda ilişkisel dize karşılaştırmalarında olan hatanın düzeltmesi ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 780cd921db4252fbd9f1702b32758653a4898dfb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sat, 8 Feb 2025 19:57:13 -0500
Subject: [PATCH 3626/3820] New translations glossary.mdx (French)

---
 website/pages/fr/resources/glossary.mdx | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/website/pages/fr/resources/glossary.mdx b/website/pages/fr/resources/glossary.mdx
index 0e6fceb15c85..1b8da433e45b 100644
--- a/website/pages/fr/resources/glossary.mdx
+++ b/website/pages/fr/resources/glossary.mdx
@@ -4,21 +4,21 @@ title: Glossaire
 
 - **The Graph** : Un protocole décentralisé pour l'indexation et l'interrogation des données.
 
-- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+- **Query** : Une requête de données. Dans le cas de The Graph, une requête est une demande de données provenant d'un subgraph à laquelle répondra un Indexeur.
 
-- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+- **GraphQL** : Un langage de requête pour les API et un moteur d'exécution pour répondre à ces requêtes avec vos données existantes. The Graph utilise GraphQL pour interroger les subgraphs.
 
-- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+- **Endpoint** : Une URL qui peut être utilisée pour interroger un subgraph. L'endpoint de test pour Subgraph Studio est `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` et l'endpoint pour Graph Explorer est `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. L'endpoint Graph Explorer est utilisé pour interroger les subgraphs sur le réseau décentralisé de The Graph.
 
-- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+- **Subgraph** : Une API ouverte qui extrait des données d'une blockchain, les traite et les stocke de manière à ce qu'elles puissent être facilement interrogées via GraphQL. Les développeurs peuvent créer, déployer et publier des subgraphs sur The Graph Network. Une fois indexé, le subgraph peut être interrogé par n'importe qui.
 
-- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+- **Indexeur** : Participants au réseau qui gèrent des nœuds d'indexation pour indexer les données des blockchains et répondre aux requêtes GraphQL.
 
-- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+- **Flux de revenus pour les Indexeurs** : Les Indexeurs sont récompensés en GRT par deux éléments : les remises sur les frais de requête et les récompenses pour l'indexation.
 
-  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+  1. **Remboursements de frais de requête** : Paiements effectués par les consommateurs de subgraphs pour avoir servi des requêtes sur le réseau.
 
-  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+  2. **Récompenses d'indexation** : Les récompenses que les Indexeurs reçoivent pour l'indexation des subgraphs. Les récompenses d'indexation sont générées par une nouvelle émission de 3 % de GRT par an.
 
 - **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 

From 9a704c3ed5d248de5ab670e19c99d51834e28fc1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 05:32:18 -0500
Subject: [PATCH 3627/3820] New translations derivedfrom.mdx (Russian)

---
 .../ru/subgraphs/cookbook/derivedfrom.mdx     | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx b/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
index 5f41c2f41bc0..357bf528201c 100644
--- a/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/ru/subgraphs/cookbook/derivedfrom.mdx
@@ -4,25 +4,25 @@ title: Лучшая практика для субграфов 2 — улучш
 
 ## Краткое содержание
 
-Arrays in your schema can really slow down a subgraph's performance as they grow beyond thousands of entries. If possible, the `@derivedFrom` directive should be used when using arrays as it prevents large arrays from forming, simplifies handlers, and reduces the size of individual entities, improving indexing speed and query performance significantly.
+Массивы в Вашей схеме могут значительно замедлить работу субграфа, когда их размер превышает тысячи элементов. Если возможно, следует использовать директиву @derivedFrom при работе с массивами, так как она предотвращает образование больших массивов, упрощает обработчики и уменьшает размер отдельных элементов, что значительно улучшает скорость индексирования и производительность запросов.
 
-## How to Use the `@derivedFrom` Directive
+## Как использовать директиву @derivedFrom
 
-You just need to add a `@derivedFrom` directive after your array in your schema. Like this:
+Вам нужно просто добавить директиву @derivedFrom после массива в своей схеме. Например:
 
 ```graphql
 comments: [Comment!]! @derivedFrom(field: "post")
 ```
 
-`@derivedFrom` creates efficient one-to-many relationships, enabling an entity to dynamically associate with multiple related entities based on a field in the related entity. This approach removes the need for both sides of the relationship to store duplicate data, making the subgraph more efficient.
+@derivedFrom создает эффективные отношения "один ко многим", позволяя объекту динамически ассоциироваться с несколькими связанными объектами на основе поля в связанном объекте. Этот подход исключает необходимость хранения продублированных данных с обеих сторон отношений, что делает субграф более эффективным.
 
 ### Пример использования @derivedFrom
 
 Пример динамически растущего массива — это платформа для блогов, где у "Поста" может быть много "Комментариев".
 
-Let’s start with our two entities, `Post` and `Comment`
+Начнем с наших двух объектов: `Post` и `Comment`
 
-Without optimization, you could implement it like this with an array:
+Без оптимизации Вы могли бы реализовать это следующим образом, используя массив:
 
 ```graphql
 type Post @entity {
@@ -38,7 +38,7 @@ type Comment @entity {
 }
 ```
 
-Arrays like these will effectively store extra Comments data on the Post side of the relationship.
+Подобные массивы будут эффективно хранить дополнительные данные о Comments на стороне отношения Post.
 
 Вот как будет выглядеть оптимизированная версия с использованием @derivedFrom:
 
@@ -57,13 +57,13 @@ type Comment @entity {
 }
 ```
 
-Just by adding the `@derivedFrom` directive, this schema will only store the “Comments” on the “Comments” side of the relationship and not on the “Post” side of the relationship. Arrays are stored across individual rows, which allows them to expand significantly. This can lead to particularly large sizes if their growth is unbounded.
+Именно при добавлении директивы `@derivedFrom`, эта схема будет хранить "Comments" только на стороне отношения "Comments", а не на стороне отношения "Post". Массивы хранятся в отдельных строках, что позволяет им значительно расширяться. Это может привести к очень большим объёмам, поскольку их рост не ограничен.
 
 Это не только сделает наш субграф более эффективным, но и откроет три возможности:
 
-1. We can query the `Post` and see all of its comments.
+1. Мы можем запрашивать `Post` и видеть все его комментарии.
 
-2. We can do a reverse lookup and query any `Comment` and see which post it comes from.
+2. Мы можем выполнить обратный поиск и запросить любой `Comment`, чтобы увидеть, от какого поста он пришел.
 
 3. Мы можем использовать [Загрузчики производных полей](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities), чтобы получить возможность напрямую обращаться и манипулировать данными из виртуальных отношений в наших мэппингах субграфа.
 

From 9c40eb92cbd05b05b86e1728a00657f8f06fa437 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 05:32:19 -0500
Subject: [PATCH 3628/3820] New translations enums.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/enums.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/cookbook/enums.mdx b/website/pages/ru/subgraphs/cookbook/enums.mdx
index 1801024c159b..be99c7607fbc 100644
--- a/website/pages/ru/subgraphs/cookbook/enums.mdx
+++ b/website/pages/ru/subgraphs/cookbook/enums.mdx
@@ -138,7 +138,7 @@ export function getMarketplaceName(marketplace: Marketplace): string {
     totalSpent
     uniqueMarketplacesCount
     marketplaces {
-      marketplace # This field returns the enum value representing the marketplace
+      marketplace # Это поле возвращает значение перечисления, представляющее маркетплейс
     }
   }
 }

From 1016f9fcbfa4cfdd7298fc12f991cd58aab591b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 05:32:20 -0500
Subject: [PATCH 3629/3820] New translations grafting.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/grafting.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/grafting.mdx b/website/pages/ru/subgraphs/cookbook/grafting.mdx
index 27afce69ccd6..8605468ff4e7 100644
--- a/website/pages/ru/subgraphs/cookbook/grafting.mdx
+++ b/website/pages/ru/subgraphs/cookbook/grafting.mdx
@@ -30,7 +30,7 @@ title: Замените контракт и сохраните его истор
 
 ### Почему это важно?
 
-Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+Grafting — это мощная функция, которая позволяет «переносить» один субграф в другой, фактически перенося исторические данные из существующего субграфа в новую версию. Однако перенос субграфа из The Graph Network обратно в Subgraph Studio невозможен.
 
 ### Лучшие практики
 
@@ -90,10 +90,10 @@ Grafting требует добавления двух новых элемент
 ```yaml
 ---
 features:
-  - grafting # feature name
+  - grafting # наименование функции
 graft:
-  base: Qm... # subgraph ID of base subgraph
-  block: 5956000 # block number
+  base: Qm... # идентификатор субграфа базового субграфа
+  block: 5956000 # номер блока
 ```
 
 - `features:` — это список всех используемых [имен функций](/developing/creating-a-subgraph/#experimental-features).
@@ -191,7 +191,7 @@ graft:
 
 ## Дополнительные ресурсы
 
-If you want more experience with grafting, here are a few examples for popular contracts:
+Если Вы хотите получить больше опыта в графтинге (переносе), вот несколько примеров популярных контрактов:
 
 - [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
 - [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)

From 3e9009cad59616d7897f960368a4a8ab3cd5c7ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 05:32:22 -0500
Subject: [PATCH 3630/3820] New translations near.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/near.mdx | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/near.mdx b/website/pages/ru/subgraphs/cookbook/near.mdx
index 7b1f02bf4449..ce50b7f34113 100644
--- a/website/pages/ru/subgraphs/cookbook/near.mdx
+++ b/website/pages/ru/subgraphs/cookbook/near.mdx
@@ -173,7 +173,7 @@ class ReceiptWithOutcome {
 
 Как только Ваш субграф будет создан, наступает время развернуть его на Graph Node для индексирования. Субграфы NEAR можно развернуть на любом Graph Node версии `>=v0.26.x` (эта версия еще не отмечена и не выпущена).
 
-Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+Subgraph Studio и Индексатор обновлений в The Graph Network в настоящее время поддерживают индексирование основной и тестовой сети NEAR в бета-версии со следующими именами сетей:
 
 - `near-mainnet`
 - `near-testnet`
@@ -198,7 +198,7 @@ graph auth
 graph deploy <subgraph-name>
 ```
 
-### Local Graph Node (based on default configuration)
+### Локальная Graph Node (на основе конфигурации по умолчанию)
 
 ```sh
 graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
@@ -216,7 +216,7 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgrap
 }
 ```
 
-### Indexing NEAR with a Local Graph Node
+### Индексирование NEAR с помощью локальной Graph Node
 
 Запуск ноды Graph, который индексирует NEAR, имеет следующие эксплуатационные требования:
 
@@ -240,19 +240,19 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgrap
 
 ## Часто задаваемые вопросы
 
-### How does the beta work?
+### Как работает бета-версия?
 
 Поддержка NEAR находится в стадии бета-тестирования, что означает, что в API могут быть внесены изменения, поскольку мы продолжаем работать над улучшением интеграции. Пожалуйста, напишите по электронной почте near@thegraph.com чтобы мы могли поддержать вас в создании NEAR подграфов и держать вас в курсе последних разработок!
 
-### Can a subgraph index both NEAR and EVM chains?
+### Может ли субграф индексировать чейны NEAR и EVM?
 
 Нет, субграф может поддерживать источники данных только из одного чейна/сети.
 
-### Can subgraphs react to more specific triggers?
+### Могут ли субграфы реагировать на более конкретные триггеры?
 
 В настоящее время поддерживаются только триггеры Block и Receipt. Мы исследуем триггеры для вызовов функций к указанной учетной записи. Мы также заинтересованы в поддержке триггеров событий, когда NEAR обладает собственной поддержкой событий.
 
-### Will receipt handlers trigger for accounts and their sub-accounts?
+### Будут ли срабатывать обработчики поступлений для учетных записей и их дочерних учетных записей?
 
 Если указано `account`, это будет соответствовать только точному имени аккаунта. Для того чтобы соответствовать субаккаунтам, можно указать поле `accounts`, с `suffixes` и `prefixes`, которые будут соответствовать аккаунтам и субаккаунтам. Например, следующее выражение будет соответствовать всем субаккаунтам `mintbase1.near`:
 

From 885bdb91169269c1e43796a05ac17571da4d7bc6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 07:15:09 -0500
Subject: [PATCH 3631/3820] New translations near.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/near.mdx | 36 ++++++++++----------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/near.mdx b/website/pages/ru/subgraphs/cookbook/near.mdx
index ce50b7f34113..67c03e17a8a5 100644
--- a/website/pages/ru/subgraphs/cookbook/near.mdx
+++ b/website/pages/ru/subgraphs/cookbook/near.mdx
@@ -8,20 +8,20 @@ title: Создание субграфов на NEAR
 
 [NEAR](https://near.org/) — это платформа для смарт-контрактов, предназначенная для создания децентрализованных приложений. Для получения дополнительной информации ознакомьтесь с [официальной документацией](https://docs.near.org/concepts/basics/protocol).
 
-## Что такое NEAR подграфы?
+## Что такое NEAR субграфы?
 
 The Graph предоставляет разработчикам инструменты для обработки событий блокчейна и упрощает доступ к полученным данным через API GraphQL, известный также как субграф. [Graph Node](https://github.com/graphprotocol/graph-node) теперь способен обрабатывать события NEAR, что позволяет разработчикам NEAR создавать субграфы для индексирования своих смарт-контрактов.
 
 Субграфы основаны на событиях, что означает, что они отслеживают и обрабатывают события в блокчейне. В настоящее время для субграфов NEAR поддерживаются два типа обработчиков:
 
 - Обработчики блоков: они запускаются для каждого нового блока
-- Обработчики квитанций: запускаются каждый раз, когда сообщение выполняется в указанной учетной записи
+- Обработчики поступлений: запускаются каждый раз, когда сообщение выполняется в указанной учетной записи
 
 [Из документации NEAR](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
 
-> Квитанция - это единственный объект, к которому можно применить действие в системе. Когда мы говорим об "обработке транзакции" на платформе NEAR, это в конечном итоге означает "применение квитанций" в какой-то момент.
+> Поступление - это единственный объект, к которому можно применить действие в системе. Когда мы говорим об "обработке транзакции" на платформе NEAR, это в конечном итоге означает "применение поступлений" в какой-то момент.
 
-## Создание NEAR подграфа
+## Создание NEAR субграфа
 
 `@graphprotocol/graph-cli` — это инструмент командной строки для создания и развертывания субграфов.
 
@@ -29,9 +29,9 @@ The Graph предоставляет разработчикам инструме
 
 Для разработки субграфов на платформе NEAR требуется `graph-cli` версии выше `0.23.0` и `graph-ts` версии выше `0.23.0`.
 
-> Построение NEAR сабграфа очень похоже на построение сабграфа, индексирующего Ethereum.
+> Построение NEAR субграфа очень похоже на построение субграфа, индексирующего Ethereum.
 
-Существует три аспекта определения подграфа:
+Существует три аспекта определения субграфа:
 
 **subgraph.yaml:** манифест субграфа, определяющий источники данных и способы их обработки. NEAR является новым `kind` (типом) источника данных.
 
@@ -189,7 +189,7 @@ $ graph create --node <graph-node-url> <subgraph-name> # создает субг
 $ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # загружает файлы сборки на указанную конечную точку IPFS, а затем разворачивает субграф на указанной Graph Node на основе хеша манифеста IPFS
 ```
 
-Конфигурация ноды будет зависеть от того, где развертывается подграф.
+Конфигурация ноды будет зависеть от того, где развертывается субграф.
 
 ### Subgraph Studio
 
@@ -204,7 +204,7 @@ graph deploy <subgraph-name>
 graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
 ```
 
-Как только ваш подграф будет развернут, он будет проиндексирован Graph Node. Вы можете проверить его прогресс, сделав запрос к самому субграфу:
+Как только Ваш субграф будет развернут, он будет проиндексирован Graph Node. Вы можете проверить его прогресс, сделав запрос к самому субграфу:
 
 ```graphql
 {
@@ -218,7 +218,7 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgrap
 
 ### Индексирование NEAR с помощью локальной Graph Node
 
-Запуск ноды Graph, который индексирует NEAR, имеет следующие эксплуатационные требования:
+Запуск Graph Node, который индексирует NEAR, имеет следующие эксплуатационные требования:
 
 - Фреймворк NEAR Indexer с инструментарием Firehose
 - Компонент(ы) NEAR Firehose
@@ -226,7 +226,7 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgrap
 
 В ближайшее время мы предоставим более подробную информацию о запуске вышеуказанных компонентов.
 
-## Запрос NEAR подграфа
+## Запрос NEAR субграфа
 
 Конечная точка GraphQL для субграфов NEAR определяется в соответствии с определением схемы и существующим интерфейсом API. Для получения дополнительной информации изучите [документацию по GraphQL API](/subgraphs/querying/graphql-api/).
 
@@ -242,7 +242,7 @@ graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgrap
 
 ### Как работает бета-версия?
 
-Поддержка NEAR находится в стадии бета-тестирования, что означает, что в API могут быть внесены изменения, поскольку мы продолжаем работать над улучшением интеграции. Пожалуйста, напишите по электронной почте near@thegraph.com чтобы мы могли поддержать вас в создании NEAR подграфов и держать вас в курсе последних разработок!
+Поддержка NEAR находится в стадии бета-тестирования, что означает, что в API могут быть внесены изменения, поскольку мы продолжаем работать над улучшением интеграции. Пожалуйста, напишите на электронную почту near@thegraph.com чтобы мы могли поддержать Вас в создании NEAR субграфов и держать в курсе последних разработок!
 
 ### Может ли субграф индексировать чейны NEAR и EVM?
 
@@ -262,19 +262,19 @@ accounts:
     - mintbase1.near
 ```
 
-### Can NEAR subgraphs make view calls to NEAR accounts during mappings?
+### Могут ли субграфы NEAR выполнять вызовы просмотра аккаунтов NEAR во время мэппингов?
 
-Это не поддерживается. Мы оцениваем, требуется ли эта функциональность для индексации.
+Это не поддерживается. Мы оцениваем, требуется ли этот функционал для индексирования.
 
-### Can I use data source templates in my NEAR subgraph?
+### Могу ли я использовать шаблоны источников данных в своем субграфе NEAR?
 
-В настоящее время это не поддерживается. Мы оцениваем, требуется ли эта функциональность для индексации.
+В настоящее время это не поддерживается. Мы оцениваем, требуется ли этот функционал для индексирования.
 
-### Ethereum subgraphs support "pending" and "current" versions, how can I deploy a "pending" version of a NEAR subgraph?
+### Субграфы Ethereum поддерживают «ожидающие» и «текущие» версии, как я могу развернуть «ожидающую» версию субграфа NEAR?
 
-Ожидающая функциональность еще не поддерживается для NEAR подграфов. Тем временем вы можете развернуть новую версию на другом "именованном" подграфе, а затем, когда она будет синхронизирована с заголовком чейна, вы можете повторно развернуть ее на свой основной "именованный" подграф, который будет использовать тот же базовый идентификатор развертывания, поэтому основной субграф будет мгновенно синхронизирован.
+Функционал ожидания еще не поддерживается для NEAR субграфов. Тем временем Вы можете развернуть новую версию на другом "именованном" субграфе, а затем, когда она будет синхронизирована с головным чейном, Вы можете повторно развернуть ее на свой основной "именованный" субграф, который будет использовать тот же базовый идентификатор развертывания, поэтому основной субграф будет мгновенно синхронизирован.
 
-### My question hasn't been answered, where can I get more help building NEAR subgraphs?
+### На мой вопрос нет ответа, где я могу получить дополнительную помощь в создании субграфов NEAR?
 
 Если это общий вопрос о разработке субграфов, дополнительную информацию можно найти в остальной части [документации для разработчиков](/subgraphs/quick-start/). В других случаях присоединяйтесь к [Discord-каналу The Graph Protocol](https://discord.gg/graphprotocol) и задавайте вопросы в канале #near или отправьте email на адрес near@thegraph.com.
 

From 6c18b6f1586674ab6dafea00f2a66d4efe6b951e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 07:15:10 -0500
Subject: [PATCH 3632/3820] New translations pruning.mdx (Russian)

---
 .../pages/ru/subgraphs/cookbook/pruning.mdx   | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/pruning.mdx b/website/pages/ru/subgraphs/cookbook/pruning.mdx
index eeb7b7859665..8bc8a023d028 100644
--- a/website/pages/ru/subgraphs/cookbook/pruning.mdx
+++ b/website/pages/ru/subgraphs/cookbook/pruning.mdx
@@ -1,22 +1,22 @@
 ---
-title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+title: Лучшая практика субграфа 1 — Улучшение скорости запросов с помощью сокращения (Pruning) субграфа
 ---
 
 ## Краткое содержание
 
-[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+[Pruning](/developing/creating-a-subgraph/#prune) удаляет архивные элементы из базы данных субграфа до заданного блока, а удаление неиспользуемых элементов из базы данных субграфа улучшает производительность запросов, зачастую значительно. Использование `indexerHints` — это простой способ выполнить сокращение субграфа.
 
-## How to Prune a Subgraph With `indexerHints`
+## Как сократить субграф с помощью `indexerHints`
 
-Add a section called `indexerHints` in the manifest.
+Добавьте раздел с названием 'indexerHints' в манифест.
 
-`indexerHints` has three `prune` options:
+`indexerHints` имеет три опции `prune`:
 
-- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
-- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
+- `prune: auto`: Сохраняет минимально необходимую историю, установленную Индексатором, оптимизируя производительность запросов. Это рекомендуется как основная настройка и является настройкой по умолчанию для всех субграфов, созданных с помощью `graph-cli` версии >= 0.66.0.
+- `prune: <Number of blocks to retain>`: Устанавливает пользовательский предел на количество исторических блоков, которые следует сохранить.
 - `prune: never`: без сокращения исторических данных; сохраняет всю историю и является значением по умолчанию, если раздел `indexerHints` отсутствует. `prune: never` следует выбрать, если требуются [Запросы на путешествия во времени](/subgraphs/querying/graphql-api/#time-travel-queries).
 
-We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+Мы можем добавить `indexerHints` в наши субграфы, обновив наш файл `subgraph.yaml`:
 
 ```yaml
 specVersion: 1.0.0
@@ -30,7 +30,7 @@ dataSources:
     network: mainnet
 ```
 
-## Important Considerations
+## Важные замечания
 
 - Если требуются [Запросы на путешествия во времени](/subgraphs/querying/graphql-api/#time-travel-queries) и при этом нужно выполнить сокращение данных, сокращение необходимо выполнить точно, чтобы сохранить функциональность запросов на путешествия во времени. По этой причине обычно не рекомендуется использовать `indexerHints: prune: auto` с запросами на путешествия во времени. Вместо этого следует выполнить сокращение, используя `indexerHints: prune: <Number of blocks to retain>`, чтобы выполнить точное сокращение до высоты блока, которое сохранит исторические данные, необходимые для запросов на путешествия во времени, или использовать `prune: never`, чтобы сохранить все данные.
 
@@ -38,7 +38,7 @@ dataSources:
 
 ## Заключение
 
-Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+Сокращение с использованием `indexerHints` — это наилучшая практика при разработке субграфов, обеспечивающая значительное улучшение производительности запросов.
 
 ## Лучшие практики для субграфов 1-6
 

From b34a8727baaf4a95a2b086d01a2d5a7c31c71e77 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 07:15:11 -0500
Subject: [PATCH 3633/3820] New translations secure-api-keys-nextjs.mdx
 (Russian)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index f7bb830755fa..f930527a810d 100644
--- a/website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/ru/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -4,19 +4,19 @@ title: Как обезопасить API-ключи с использовани
 
 ## Обзор
 
-We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+Мы можем использовать [серверные компоненты Next.js](https://nextjs.org/docs/app/building-your-application/rendering/server-components), чтобы должным образом защитить наш API-ключ от взлома во внешнем интерфейсе нашего децентрализованного приложения (dapp). Чтобы дополнительно повысить безопасность API-ключа, мы также можем [ограничить доступ к нашему API-ключу для определённых субграфов или доменов в Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
 
 В этом руководстве мы рассмотрим, как создать серверный компонент Next.js, который запрашивает субграф, одновременно скрывая API-ключ от фронтенда.
 
-### Caveats
+### Предостережения
 
-- Next.js server components do not protect API keys from being drained using denial of service attacks.
-- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Серверные компоненты Next.js не защищают API-ключи от утечки при атаках типа "отказ в обслуживании".
+- Шлюзы The Graph Network имеют стратегии обнаружения и смягчения атак типа "отказ в обслуживании", однако использование серверных компонентов может ослабить эти защиты.
 - Серверные компоненты Next.js вносят риски централизации, так как сервер может выйти из строя.
 
 ### Почему это необходимо
 
-In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+В стандартном React-приложении API-ключи, включённые в код внешнего интерфейса, могут быть раскрыты на стороне клиента, что созает угрозу безопасности. Хотя обычно используются файлы `.env`, они не обеспечивают полной защиты ключей, так как код React выполняется на стороне клиента, раскрывая API-ключ в заголовках. Серверные компоненты Next.js решают эту проблему, обрабатывая конфиденциальные операции на сервере.
 
 ### Использование рендеринга на клиентской стороне для запроса к субграфу
 
@@ -25,22 +25,22 @@ In a standard React application, API keys included in the frontend code can be e
 ### Предварительные требования
 
 - API-ключ от [Subgraph Studio](https://thegraph.com/studio)
-- Basic knowledge of Next.js and React.
+- Базовые знания о Next.js и React.
 - Существующий проект Next.js, который использует [App Router](https://nextjs.org/docs/app).
 
 ## Пошаговое руководство
 
-### Step 1: Set Up Environment Variables
+### Шаг 1: Настройка переменных среды
 
 1. В корневой папке нашего проекта Next.js создайте файл `.env.local`.
 2. Добавьте наш API-ключ: `API_KEY=<api_key_here>`.
 
-### Step 2: Create a Server Component
+### Шаг 2: Создание серверного компонента
 
 1. В директории `components` создайте новый файл `ServerComponent.js`.
 2. Используйте приведённый пример кода для настройки серверного компонента.
 
-### Step 3: Implement Server-Side API Request
+### Шаг 3: Реализация API-запроса на стороне сервера
 
 В файл `ServerComponent.js` добавьте следующий код:
 
@@ -95,9 +95,9 @@ export default async function ServerComponent() {
 }
 ```
 
-### Step 4: Use the Server Component
+### Шаг 4: Использование серверного компонента
 
-1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
+1. В файл страницы (например, `pages/index.js`) импортируйте `ServerComponent`.
 2. Отрендерите компонент:
 
 ```javascript
@@ -112,7 +112,7 @@ export default function Home() {
 }
 ```
 
-### Step 5: Run and Test Our Dapp
+### Шаг 5: Запуск и тестирование нашего децентрализованного приложения (Dapp)
 
 Запустите наше приложение Next.js с помощью команды `npm run dev`. Убедитесь, что серверный компонент запрашивает данные, не раскрывая API-ключ.
 

From a71255c91b444b6ee7a2f8c88713912fa5e72775 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 07:15:12 -0500
Subject: [PATCH 3634/3820] New translations subgraph-debug-forking.mdx
 (Russian)

---
 .../ru/subgraphs/cookbook/subgraph-debug-forking.mdx   | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
index 24264f320a05..e0b03fa9e886 100644
--- a/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -1,5 +1,5 @@
 ---
-title: Быстрая и простая отладка подграфа с использованием форков
+title: Быстрая и простая отладка субграфа с использованием форков
 ---
 
 Как и многие системы, обрабатывающие большие объемы данных, Индексаторы The Graph (Graph Nodes) могут занять достаточно много времени для синхронизации Вашего субграфа с целевым блокчейном. Несоответствие между быстрыми изменениями, направленными на отладку, и долгим временем ожидания, необходимым для индексирования, является крайне непродуктивным, и мы прекрасно осознаем эту проблему. Поэтому мы представляем **форкинг субграфа**, разработанный [LimeChain](https://limechain.tech/), и в этой статье я покажу, как эту функцию можно использовать для значительного ускорения отладки субграфов!
@@ -48,8 +48,8 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void {
 
 Обычный способ попытаться исправить это:
 
-1. Внести изменения в источник сопоставлений, которые, по вашему мнению, решат проблему (в то время как я знаю, что это не так).
-2. Перезапустите развертывание своего субграфа в [Subgraph Studio](https://thegraph.com/studio/) (или на другую удалённую Graph Node).
+1. Внести изменения в источник мэппингов, которые, по Вашему мнению, решат проблему (в то время как я знаю, что это не так).
+2. Перезапустить развертывание своего субграфа в [Subgraph Studio](https://thegraph.com/studio/) (или на другую удалённую Graph Node).
 3. Подождать, пока он синхронизируется.
 4. Если он снова сломается, вернуться к пункту 1, в противном случае: Ура!
 
@@ -58,11 +58,11 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void {
 Используя **форк субграфа**, мы можем фактически устранить этот шаг. Вот как это выглядит:
 
 0. Запустите локальную Graph Node с помощью **_соответстсвующего набора fork-base_**.
-1. Внесите изменения в источник сопоставлений, которые, по вашему мнению, решат проблему.
+1. Внесите изменения в источник мэппингов, которые, по Вашему мнению, решат проблему.
 2. Произведите развертывание на локальной Graph Node, **_форкнув неудачно развернутый субграф_** и **_начав с проблемного блока_**.
 3. Если он снова сломается, вернитесь к пункту 1, в противном случае: Ура!
 
-Сейчас у вас может появиться 2 вопроса:
+Сейчас у Вас может появиться 2 вопроса:
 
 1. fork-base что???
 2. Форкнуть кого?!

From 32dbb0168fdeb1a924de57ff35575cd7e53502b5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 07:15:13 -0500
Subject: [PATCH 3635/3820] New translations timeseries.mdx (Russian)

---
 website/pages/ru/subgraphs/cookbook/timeseries.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/cookbook/timeseries.mdx b/website/pages/ru/subgraphs/cookbook/timeseries.mdx
index dd367a112e7a..064947d48bb5 100644
--- a/website/pages/ru/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/ru/subgraphs/cookbook/timeseries.mdx
@@ -27,7 +27,7 @@ title: Лучшие практики субграфов №5 — Упрощен
 - Неизменяемые данные: все данные временных рядов неизменяемы, что обеспечивает эффективное хранение и извлечение.
 - Эффективное разделение данных: агрегаты хранятся отдельно от необработанных данных временных рядов, что позволяет запросам обрабатывать значительно меньше данных — часто на несколько порядков меньше.
 
-### Important Considerations
+### Важные замечания
 
 - Незаменяемость данных: данные временных рядов не могут быть изменены после записи, что обеспечивает целостность данных и упрощает индексирование.
 - Автоматическое управление ID и метками времени: поля id и timestamp автоматически управляются graph-node, что снижает вероятность ошибок.

From b5282b3941a7084ea9a5d803ccb40facbb1f381b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 08:40:50 -0500
Subject: [PATCH 3636/3820] New translations subgraph-debug-forking.mdx
 (Russian)

---
 .../ru/subgraphs/cookbook/subgraph-debug-forking.mdx      | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
index e0b03fa9e886..8f2e67289d77 100644
--- a/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/ru/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -64,13 +64,13 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void {
 
 Сейчас у Вас может появиться 2 вопроса:
 
-1. fork-base что???
+1. fork-base - что это???
 2. Форкнуть кого?!
 
 И я вам отвечаю:
 
 1. `fork-base` - это «базовый» URL, при добавлении которого к _subgraph id_ результирующий URL (`<fork-base>/<subgraph-id>`) является действительной конечной точкой GraphQL для хранилища субграфа.
-2. Форк - это просто, особо не нужно потеть:
+2. Форкнуть легко, не нужно напрягаться:
 
 ```bash
 $ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
@@ -97,5 +97,5 @@ $ cargo run -p graph-node --release -- \
 $ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
 ```
 
-4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
-5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)
+4. Я проверяю логи, созданные локальной Graph Node, и, ура!, кажется, все работает.
+5. Я развертываю свой теперь свободный от ошибок субграф на удаленной Graph Node и живу долго и счастливо! (но без картошки)

From ba6536aed8475d5098f417694345ac0fbc54399e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 08:40:51 -0500
Subject: [PATCH 3637/3820] New translations subgraph-uncrashable.mdx (Russian)

---
 .../pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx  | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx
index dd8dbb170530..f81fe52608e8 100644
--- a/website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx
+++ b/website/pages/ru/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -1,10 +1,10 @@
 ---
-title: Генератор кода безопасного подграфа
+title: Генератор кода безопасного субграфа
 ---
 
 [Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) — это инструмент для генерации кода, который создает набор вспомогательных функций из схемы GraphQL проекта. Он гарантирует, что все взаимодействия с объектами в Вашем субграфе будут полностью безопасными и последовательными.
 
-## Why integrate with Subgraph Uncrashable?
+## Зачем интегрироваться с Subgraph Uncrashable?
 
 - **Непрерывная работа**. Ошибки в обработке объектов могут привести к сбоям субграфов, что нарушит работу проектов, зависящих от The Graph. Настройте вспомогательные функции, чтобы Ваши субграфы оставались «непотопляемыми» и обеспечивали стабильную работу.
 
@@ -16,9 +16,9 @@ title: Генератор кода безопасного подграфа
 
 - Инструмент генерации кода поддерживает **все** типы субграфов и настраивается таким образом, чтобы пользователи могли задать разумные значения по умолчанию. Генерация кода будет использовать эту настройку для создания вспомогательных функций в соответствии с требованиями пользователей.
 
-- Фреймворк также включает способ (через config-файл) создания пользовательских, но безопасных функций установки для групп переменных объектов. Таким образом, пользователь не сможет загрузить/использовать устаревшую graph entity, и также невозможно забыть о сохранении или установке переменной, которая требуется функцией.
+- Фреймворк также включает в себя способ создания пользовательских, но безопасных функций установки для групп переменных объектов (через config-файл). Таким образом, пользователь не сможет загрузить/использовать устаревшую graph entity, и также не сможет забыть о сохранении или установке переменной, которая требуется функцией.
 
-- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+- Предупреждающие логи записываются как логи, указывающие на нарушение логики субграфа, чтобы помочь устранить проблему и обеспечить точность данных.
 
 Subgraph Uncrashable можно запустить как необязательный флаг с помощью команды Graph CLI codegen.
 

From 018af753ca4326061a627ac54cfb25ce778550c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 08:40:52 -0500
Subject: [PATCH 3638/3820] New translations transfer-to-the-graph.mdx
 (Russian)

---
 .../cookbook/transfer-to-the-graph.mdx        | 66 +++++++++----------
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx
index 848c94ce4c6c..570aab81debc 100644
--- a/website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/ru/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -1,35 +1,35 @@
 ---
-title: Tranfer to The Graph
+title: Перенос в The Graph
 ---
 
-Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+Быстро обновите свои субграфы с любой платформы до [децентрализованной сети The Graph](https://thegraph.com/networks/).
 
-## Benefits of Switching to The Graph
+## Преимущества перехода на The Graph
 
-- Use the same subgraph that your apps already use with zero-downtime migration.
-- Increase reliability from a global network supported by 100+ Indexers.
-- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+- Используйте тот же субграф, который уже используют ваши приложения, с миграцией без времени простоя.
+- Повышайте надежность благодаря глобальной сети, поддерживаемой более чем 100 индексаторами.
+- Получайте молниеносную поддержку для субграфов 24/7 от дежурной команды инженеров.
 
-## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+## Обновите свой субграф до The Graph за 3 простых шага
 
 1. [Настройте свою среду Studio](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
 2. [Разверните свой субграф в Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
 3. [Опубликуйте в сети The Graph](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
 
-## 1. Set Up Your Studio Environment
+## 1. Настройте свою среду в Studio
 
-### Create a Subgraph in Subgraph Studio
+### Создайте субграф в Subgraph Studio
 
 - Перейдите в [Subgraph Studio](https://thegraph.com/studio/) и подключите свой кошелек.
 - Нажмите "Создать субграф". Рекомендуется называть субграф с использованием Заглавного регистра: "Subgraph Name Chain Name".
 
 > Примечание: после публикации имя субграфа будет доступно для редактирования, но для этого каждый раз потребуется действие на он-чейне, поэтому выберите подходящее имя сразу.
 
-### Install the Graph CLI⁠
+### Установите Graph CLI
 
-You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+Для использования Graph CLI у Вас должны быть установлены [Node.js](https://nodejs.org/) и выбранный Вами менеджер пакетов (`npm` или `pnpm`). Проверьте [самую последнюю](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) версию CLI.
 
-On your local machine, run the following command:
+Выполните следующую команду на своем локальном компьютере:
 
 Использование [npm](https://www.npmjs.com/):
 
@@ -37,38 +37,38 @@ On your local machine, run the following command:
 npm install -g @graphprotocol/graph-cli@latest
 ```
 
-Use the following command to create a subgraph in Studio using the CLI:
+Используйте следующую команду для создания субграфа в Studio с помощью CLI:
 
 ```sh
 graph init --product subgraph-studio
 ```
 
-### Authenticate Your Subgraph
+### Аутентификация Вашего субграфа
 
-In The Graph CLI, use the auth command seen in Subgraph Studio:
+В Graph CLI используйте команду `auth`, как показано в Subgraph Studio:
 
 ```sh
 graph auth <your-auth-code>
 ```
 
-## 2. Deploy Your Subgraph to Studio
+## 2. Разверните свой субграф в Studio
 
-If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+Если у Вас есть исходный код, Вы можете с легкостью развернуть его в Studio. Если его нет, вот быстрый способ развернуть Ваш субграф.
 
-In The Graph CLI, run the following command:
+В Graph CLI выполните следующую команду:
 
 ```sh
 graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
 
 ```
 
-> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+> **Примечание:** Каждый субграф имеет хэш IPFS (идентификатор развертывания), который выглядит так: "Qmasdfad...". Для развертывания просто используйте этот **IPFS хэш**. Вам будет предложено ввести версию (например, v0.0.1).
 
-## 3. Publish Your Subgraph to The Graph Network
+## 3. Опубликуйте свой субграф в The Graph Network
 
-![publish button](/img/publish-sub-transfer.png)
+![кнопка публикации](/img/publish-sub-transfer.png)
 
-### Query Your Subgraph
+### Запросите Ваш Субграф
 
 > Для того чтобы привлечь около 3 индексаторов для запроса Вашего субграфа, рекомендуется зафиксировать как минимум 3000 GRT. Чтобы узнать больше о кураторстве, ознакомьтесь с разделом [Кураторство](/resources/roles/curating/) на платформе The Graph.
 
@@ -76,29 +76,29 @@ graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
 
 #### Пример
 
-[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+[Субграф CryptoPunks на Ethereum](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) от Messari:
 
-![Query URL](/img/cryptopunks-screenshot-transfer.png)
+![URL запроса](/img/cryptopunks-screenshot-transfer.png)
 
-The query URL for this subgraph is:
+URL запроса для этого субграфа:
 
 ```sh
-https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+https://gateway-arbitrum.network.thegraph.com/api/`**Ваш-api-ключ**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
 ```
 
-Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+Теперь Вам нужно просто вставить **Ваш собственный API-ключ**, чтобы начать отправлять GraphQL-запросы на эту конечную точку.
 
-### Getting your own API Key
+### Получение собственного API-ключа
 
-You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+Вы можете создать API-ключи в Subgraph Studio в меню «API Keys» в верхней части страницы:
 
-![API keys](/img/Api-keys-screenshot.png)
+![API ключи](/img/Api-keys-screenshot.png)
 
-### Monitor Subgraph Status
+### Мониторинг статуса субграфа
 
-Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+После обновления Вы сможете получить доступ к своим субграфам и управлять ими в [Subgraph Studio](https://thegraph.com/studio/) и исследовать все субграфы в [The Graph Explorer](https://thegraph.com/networks/).
 
 ### Дополнительные ресурсы
 
 - Чтобы быстро создать и опубликовать новый субграф, ознакомьтесь с [Руководством по быстрому старту](/subgraphs/quick-start/).
-- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).
+- Чтобы исследовать все способы оптимизации и настройки своего субграфа для улучшения производительности, читайте больше о [создании субграфа здесь](/developing/creating-a-subgraph/).

From 0dd56a7b93d61e9eedba6d5498427b2396f0c652 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Sun, 9 Feb 2025 08:40:55 -0500
Subject: [PATCH 3639/3820] New translations delegating.mdx (Russian)

---
 website/pages/ru/resources/roles/delegating/delegating.mdx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/ru/resources/roles/delegating/delegating.mdx b/website/pages/ru/resources/roles/delegating/delegating.mdx
index 9f23ac4c669e..49c5f12916eb 100644
--- a/website/pages/ru/resources/roles/delegating/delegating.mdx
+++ b/website/pages/ru/resources/roles/delegating/delegating.mdx
@@ -90,15 +90,15 @@ As a result, it’s recommended that you choose an Indexer wisely.
 
 Чтобы понять, как выбрать надежного Индексатора, Вам необходимо разобраться в параметрах делегирования.
 
-- **Часть вознаграждения за индексацию** — доля вознаграждений, которую индексатор оставляет себе.
+- **Часть вознаграждения за индексиндексирование** — доля вознаграждений, которую Индексатор оставляет себе.
   - Если доля вознаграждения индексатора установлена на 100%, как делегатор, как Делегатор, Вы получите 0 вознаграждений за индексацию.
   - Если установлено значение 80%, то как Делегатор Вы получите 20%.
 
 <div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Часть вознаграждения за индексирование](/img/Indexing-Reward-Cut.png) *Верхний индексатор отдает делегаторам 90% вознаграждений. Средний — 20%. Нижний — около 83%.*
+  ![Часть вознаграждения за индексирование](/img/Indexing-Reward-Cut.png) *Верхний Индексатор отдает Делегаторам 90% вознаграждений. Средний — 20%. Нижний — около 83%.*
 </div>
 
-- **Часть комиссии за запросы** — это то же самое, что и часть вознаграждения за индексирование, но она применяется к доходам от комиссий за запросы, которые индексатор собирает.
+- **Снижение комиссии за запросы** — это то же самое, что и снижение вознаграждения за индексирование, но она применяется к доходам от комиссий за запросы, которые собирает Индексатор.
 
 - It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 

From 15b50fbe964ce324005cd1395872d7dce7595e0d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 02:54:39 -0500
Subject: [PATCH 3640/3820] New translations glossary.mdx (French)

---
 website/pages/fr/resources/glossary.mdx | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/fr/resources/glossary.mdx b/website/pages/fr/resources/glossary.mdx
index 1b8da433e45b..7cafe7540148 100644
--- a/website/pages/fr/resources/glossary.mdx
+++ b/website/pages/fr/resources/glossary.mdx
@@ -20,25 +20,25 @@ title: Glossaire
 
   2. **Récompenses d'indexation** : Les récompenses que les Indexeurs reçoivent pour l'indexation des subgraphs. Les récompenses d'indexation sont générées par une nouvelle émission de 3 % de GRT par an.
 
-- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+- **Indexer's Self-Stake** : Le montant de GRT que les Indexeurs stakent pour participer au réseau décentralisé. Le minimum est de 100 000 GRT, et il n'y a pas de limite supérieure.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+- **Delegation Capacity** : C'est le montant maximum de GRT qu'un Indexeur peut accepter de la part des Déléguateurs. Les Indexeurs ne peuvent accepter que jusqu'à 16 fois leur propre Indexer Self-Stake, et toute délégation supplémentaire entraîne une dilution des récompenses. Par exemple, si un Indexeur a une Indexer Self-Stake de 1M GRT, sa capacité de délégation est de 16M. Cependant, les indexeurs peuvent augmenter leur capacité de délégation en augmentant leur Indexer Self-Stake.
 
-- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+- **Upgrade Indexer** : Un Indexeur conçu pour servir de solution de repli pour les requêtes de subgraphs qui ne sont pas traitées par d'autres Indexeurs sur le réseau. L'upgrade Indexer n'est pas compétitif par rapport aux autres Indexeurs.
 
-- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+- **Delegator**(Déléguateurs) : Participants au réseau qui possèdent des GRT et les délèguent à des Indexeurs. Cela permet aux Indexeurs d'augmenter leur participation dans les subgraphs du réseau. En retour, les Déléguateurs reçoivent une partie des récompenses d'indexation que les Indexeurs reçoivent pour le traitement des subgraphs.
 
-- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+- **Taxe de délégation** : Une taxe de 0,5 % payée par les Déléguateurs lorsqu'ils délèguent des GRT aux Indexeurs. Les GRT utilisés pour payer la taxe sont brûlés.
 
-- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+- **Curator**(Curateur) : Participants au réseau qui identifient les subgraphs de haute qualité et signalent les GRT sur ces derniers en échange de parts de curation. Lorsque les Indexeurs réclament des frais de requête pour un subgraph, 10 % sont distribués aux Curateurs de ce subgraph. Il existe une corrélation positive entre la quantité de GRT signalée et le nombre d'Indexeurs indexant un subgraph.
 
-- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+- **Taxe de curation** : Une taxe de 1% payée par les Curateurs lorsqu'ils signalent des GRT sur des subgraphs. Les GRT utiliséa pour payer la taxe sont brûlés.
 
-- **Data Consumer**: Any application or user that queries a subgraph.
+- **Consommateur de données** : Toute application ou utilisateur qui interroge un subgraph.
 
-- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+- **Développeur de subgraphs** : Un développeur qui construit et déploie un subgraph sur le réseau décentralisé de The Graph.
 
-- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+- **Manifeste du subgraph** : Un fichier YAML qui décrit le schéma GraphQL du subgraph, les sources de données et d'autres métadonnées. Vous trouverez [Ici](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) un exemple.
 
 - **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
 

From 1e1597c0be55ef912a333230c45653e30bf8de87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 02:54:40 -0500
Subject: [PATCH 3641/3820] New translations grafting-hotfix.mdx (Chinese
 Simplified)

---
 website/pages/zh/subgraphs/cookbook/grafting-hotfix.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/zh/subgraphs/cookbook/grafting-hotfix.mdx
index 8153e7143816..437c5e486fa9 100644
--- a/website/pages/zh/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/zh/subgraphs/cookbook/grafting-hotfix.mdx
@@ -1,5 +1,5 @@
 ---
-title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+title: 子图最佳实践6-使用嫁接快速部署修补程序
 ---
 
 ## TLDR

From cb97fc7126ac74ef485544b216ba785751015e7a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 06:41:02 -0500
Subject: [PATCH 3642/3820] New translations glossary.mdx (German)

---
 website/pages/de/resources/glossary.mdx | 50 ++++++++++++-------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/website/pages/de/resources/glossary.mdx b/website/pages/de/resources/glossary.mdx
index ffcd4bca2eed..072bb6e60f8d 100644
--- a/website/pages/de/resources/glossary.mdx
+++ b/website/pages/de/resources/glossary.mdx
@@ -32,52 +32,52 @@ title: Glossary
 
 - **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
 
-- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+- **Kurationssteuer**: Eine Gebühr von 1 %, die von Kuratoren gezahlt wird, wenn sie GRT auf Subgraphen melden. Die GRT, die zur Zahlung der Gebühr verwendet wird, wird verbrannt.
 
-- **Data Consumer**: Any application or user that queries a subgraph.
+- **Datenverbraucher**: Jede Anwendung oder jeder Benutzer, der einen Subgraph abfragt.
 
-- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+- **Subgraphen-Entwickler**: Ein Entwickler, der einen Subgraph für das dezentrale Netzwerk von The Graph erstellt und bereitstellt.
 
-- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
+- **Subgraph Manifest**: Eine YAML-Datei, die das GraphQL-Schema, die Datenquellen und andere Metadaten des Subgraphen beschreibt. Ein Beispiel ist [hier](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml).
 
-- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+- **Epoche**: Eine Zeiteinheit innerhalb des Netzes. Derzeit entspricht eine Epoche 6.646 Blöcken oder etwa 1 Tag.
 
-- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+- **Zuteilung**: Ein Indexer kann seinen gesamten GRT-Einsatz (einschließlich des Einsatzes der Delegatoren) Subgraphen zuweisen, die im dezentralen Netzwerk von The Graph veröffentlicht wurden. Zuteilungen können verschiedene Status haben:
 
-  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Aktiv**: Eine Zuordnung gilt als aktiv, wenn sie onchain erstellt wird. Dies wird als Öffnen einer Zuordnung bezeichnet und zeigt dem Netzwerk an, dass der Indexer aktiv indiziert und Abfragen für einen bestimmten Subgraph bedient. Aktive Zuweisungen sammeln Rewards für die Indizierung, die proportional zum Signal auf dem Subgraph und der Menge des zugewiesenen GRT sind.
 
-  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+  2. **Geschlossen**: Ein Indexer kann die aufgelaufenen Rewards für einen bestimmten Subgraph beanspruchen, indem er einen aktuellen und gültigen Proof of Indexing (POI) einreicht. Dies wird als Schließen einer Zuordnung bezeichnet. Eine Zuordnung muss mindestens eine Epoche lang offen gewesen sein, bevor sie geschlossen werden kann. Die maximale Zuordnungsdauer beträgt 28 Epochen. Lässt ein Indexer eine Zuordnung länger als 28 Epochen offen, wird sie als veraltete Zuordnung bezeichnet. Wenn sich eine Zuordnung im Zustand **Geschlossen** befindet, kann ein Fisherman immer noch einen Disput eröffnen, um einen Indexer wegen der Bereitstellung falscher Daten anzufechten.
 
-- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+- **Subgraph Studio**: Eine leistungsstarke App zum Erstellen, Bereitstellen und Veröffentlichen von Subgraphen.
 
-- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+- **Fischer**: Eine Rolle innerhalb des The Graph Network, die von Teilnehmern eingenommen wird, die die Genauigkeit und Integrität der von Indexern gelieferten Daten überwachen. Wenn ein Fisherman eine Abfrage-Antwort oder einen POI identifiziert, den er für falsch hält, kann er einen Disput gegen den Indexer einleiten. Wenn der Streitfall zu Gunsten des Fischers entschieden wird, verliert der Indexer 2,5 % seines Eigenanteils. Von diesem Betrag erhält der Fischer 50 % als Belohnung für seine Wachsamkeit, und die restlichen 50 % werden aus dem Verkehr gezogen (verbrannt). Dieser Mechanismus soll die Fischer dazu ermutigen, die Zuverlässigkeit des Netzwerks aufrechtzuerhalten, indem sichergestellt wird, dass die Indexer für die von ihnen gelieferten Daten verantwortlich gemacht werden.
 
-- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+- **Schlichter**: Schlichter sind Netzwerkteilnehmer, die im Rahmen eines Governance-Prozesses ernannt werden. Die Rolle des Schiedsrichters besteht darin, über den Ausgang von Streitigkeiten bei Indizierungen und Abfragen zu entscheiden. Ihr Ziel ist es, den Nutzen und die Zuverlässigkeit von The Graph Network zu maximieren.
 
-- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+- **Kürzung**: Indexer können für die Bereitstellung eines falschen POI oder für die Bereitstellung ungenauer Daten um ihre selbst gesetzten GRT gekürzt werden. Der Prozentsatz des Slashings ist ein Protokollparameter, der derzeit auf 2,5% des Eigenanteils eines Indexers festgelegt ist. 50 % der gekürzten GRT gehen an den Fischer, der die ungenauen Daten oder den falschen POI bestritten hat. Die anderen 50% werden verbrannt.
 
-- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+- **Indizierungs-Rewards**: Die Rewards, die Indexer für die Indizierung von Subgraphen erhalten. Indexing Rewards werden in GRT verteilt.
 
-- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+- **Delegation Rewards**: Die Rewards, die Delegatoren für die Delegierung von GRT an Indexer erhalten. Delegations-Rewards werden in GRT verteilt.
 
-- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+- **GRT**: The Graph's Work Utility Token. GRT bietet den Netzwerkteilnehmern wirtschaftliche Anreize für ihren Beitrag zum Netzwerk.
 
-- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+- **Nachweis der Indizierung (POI)**: Wenn ein Indexer seine Zuteilung abschließt und seine angesammelten Rewards für einen bestimmten Subgraph beanspruchen möchte, muss er einen gültigen und aktuellen POI vorlegen. Fischer können den von einem Indexer angegebenen POI anfechten. Ein Streit, der zugunsten des Fischers entschieden wird, führt zur Streichung des Indexers.
 
-- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
+- **Graph Node**: Graph Node ist die Komponente, die Subgraphen indiziert und die resultierenden Daten für Abfragen über eine GraphQL-API zur Verfügung stellt. Als solche ist sie von zentraler Bedeutung für den Indexer-Stack, und der korrekte Betrieb von Graph Node ist entscheidend für den erfolgreichen Betrieb eines Indexers.
 
-- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Indexer-Agent**: Der Indexer-Agent ist Teil des Indexer-Stacks. Er erleichtert die Interaktionen des Indexers in der Kette, einschließlich der Registrierung im Netzwerk, der Verwaltung von Subgraph-Bereitstellungen an seine(n) Graph Node(s) und der Verwaltung von Zuweisungen.
 
-- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+- **The Graph Client**: Eine Bibliothek für den Aufbau von GraphQL-basierten Dapps auf dezentralisierte Weise.
 
-- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+- **Graph Explorer**: Eine App, mit der Netzwerkteilnehmer Subgraphen erkunden und mit dem Protokoll interagieren können.
 
-- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+- **Graph CLI**: Ein Befehlszeilenschnittstellen-Tool zum Erstellen und Bereitstellen von The Graph.
 
-- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+- **Abkühlphase**: Die Zeit, die verbleibt, bis ein Indexer, der seine Delegationsparameter geändert hat, dies wieder tun kann.
 
-- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
+- **L2 Transfer Tools**: Smart Contracts und UI, die es Netzwerkteilnehmern ermöglichen, netzwerkbezogene Vermögenswerte vom Ethereum Mainnet auf Arbitrum One zu übertragen. Netzwerkteilnehmer können delegiertes GRT, Subgraphen, Kurationsanteile und den Eigenanteil des Indexers übertragen.
 
-- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+- **Aktualisierung eines Subgraphen**: Der Prozess der Freigabe einer neuen Version eines Subgraphen mit Aktualisierungen des Manifests, des Schemas oder der Mappings des Subgraphen.
 
-- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).
+- **Migrieren**: Der Prozess, bei dem Kurationsanteile von einer alten Version eines Subgraphs auf eine neue Version eines Subgraphs übertragen werden (z. B. wenn v0.0.1 auf v0.0.2 aktualisiert wird).

From 6f6a314d2749695351fe60f640e07106a5c940b1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 06:41:03 -0500
Subject: [PATCH 3643/3820] New translations benefits.mdx (German)

---
 website/pages/de/resources/benefits.mdx | 98 ++++++++++++-------------
 1 file changed, 49 insertions(+), 49 deletions(-)

diff --git a/website/pages/de/resources/benefits.mdx b/website/pages/de/resources/benefits.mdx
index c035f6636b1b..10236e03323b 100644
--- a/website/pages/de/resources/benefits.mdx
+++ b/website/pages/de/resources/benefits.mdx
@@ -3,71 +3,71 @@ title: The Graph vs. Self Hosting
 socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
 ---
 
-The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
+Das dezentralisierte Netzwerk von The Graph wurde entwickelt und verfeinert, um eine robuste Indizierung und Abfrage zu ermöglichen - und es wird dank Tausender Mitwirkender auf der ganzen Welt jeden Tag besser.
 
-The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+Die Vorteile dieses dezentralen Protokolls können nicht durch den lokalen Betrieb eines „Graph-Knotens“ repliziert werden. The Graph Network ist zuverlässiger, effizienter und kostengünstiger.
 
-Here is an analysis:
+Hier ist eine Analyse:
 
-## Why You Should Use The Graph Network
+## Warum Sie das The Graph Network nutzen sollten
 
-- Significantly lower monthly costs
-- $0 infrastructure setup costs
-- Superior uptime
-- Access to hundreds of independent Indexers around the world
-- 24/7 technical support by global community
+- Deutlich niedrigere monatliche Kosten
+- $0 Kosten für die Einrichtung der Infrastruktur
+- Hervorragende Betriebszeiten
+- Zugang zu Hunderten von unabhängigen Indexern auf der ganzen Welt
+- 24/7 technische Unterstützung durch die globale Community
 
-## The Benefits Explained
+## Die Vorteile werden erklärt
 
-### Lower & more Flexible Cost Structure
+### Niedrigere und flexiblere Kostenstruktur
 
-No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+Keine Verträge. Keine monatlichen Gebühren. Sie zahlen nur für die Abfragen, die Sie nutzen - mit durchschnittlichen Kosten pro Abfrage von $40 pro Million Abfragen (~$0,00004 pro Abfrage). Abfragen werden in USD abgerechnet und in GRT oder per Kreditkarte bezahlt.
 
-Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+Die Abfragekosten können variieren; die angegebenen Kosten sind der Durchschnitt zum Zeitpunkt der Veröffentlichung (März 2024).
 
-## Low Volume User (less than 100,000 queries per month)
+## Low Volume User (weniger als 100.000 Abfragen pro Monat)
 
-|        Cost Comparison       |               Self Hosted               |                        The Graph Network                        |
-| :--------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
-|     Monthly server cost\*    |              $350 per month             |                                $0                               |
-|          Query costs         |                   $0+                   |                           $0 per month                          |
-| Engineering time<sup>†</sup> |              $400 per month             | None, built into the network with globally distributed Indexers |
-|       Queries per month      |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
-|        Cost per query        |                    $0                   |                          $0<sup>‡</sup>                         |
-|         Infrastruktur        |               Centralized               |                          Decentralized                          |
-|     Geographic redundancy    |        $750+ per additional node        |                             Included                            |
-|            Uptime            |                  Varies                 |                              99.9%+                             |
-|      Total Monthly Costs     | <span className="highlight-row" />$750+ |                                $0                               |
-
-## Medium Volume User (~3M queries per month)
-
-|        Cost Comparison       |                 Self Hosted                |                        The Graph Network                        |
+|        Kostenvergleich       |               Selbst gehostet              |                        The Graph Network                        |
+| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
+|   Monatliche Serverkosten\*  |               $350 pro Monat               |                                $0                               |
+|         Abfragekosten        |                     $0+                    |                           $0 pro Monat                          |
+| Entwicklungszeit<sup>†</sup> |            400 Dollar pro Monat            | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
+|      Abfragen pro Monat      | Begrenzt auf infrastrukturelle Fähigkeiten |                    100.000 (kostenloser Plan)                   |
+|      Kosten pro Abfrage      |                     $0                     |                          $0<sup>‡</sup>                         |
+|         Infrastruktur        |                Zentralisiert               |                         Dezentralisiert                         |
+|    Geografische Redundanz    |     $750+ pro zusätzlichem Knotenpunkt     |                          Eingeschlossen                         |
+|         Betriebszeit         |                  Variiert                  |                              99.9%+                             |
+|    Monatliche Gesamtkosten   |   <span className="highlight-row" />$750+  |                                $0                               |
+
+## Benutzer mit mittlerem Volumen (~3M Abfragen pro Monat)
+
+|        Kostenvergleich       |               Selbst gehostet              |                        The Graph Network                        |
 | :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
-|     Monthly server cost\*    |               $350 per month               |                                $0                               |
-|          Query costs         |               $500 per month               |                          $120 per month                         |
-| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
-|       Queries per month      |        Limited to infra capabilities       |                            ~3,000,000                           |
-|        Cost per query        |                     $0                     |                             $0.00004                            |
-|         Infrastruktur        |                 Centralized                |                          Decentralized                          |
-|      Engineering expense     |                $200 per hour               |                             Included                            |
-|     Geographic redundancy    |  $1,200 in total costs per additional node |                             Included                            |
-|            Uptime            |                   Varies                   |                              99.9%+                             |
-|      Total Monthly Costs     | <span className="highlight-row" /> $1,650+ |                               $120                              |
+|   Monatliche Serverkosten\*  |               $350 pro Monat               |                                $0                               |
+|         Abfragekosten        |               $500 per month               |                          $120 per month                         |
+| Entwicklungszeit<sup>†</sup> |               $800 per month               | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
+|      Abfragen pro Monat      | Begrenzt auf infrastrukturelle Fähigkeiten |                            ~3,000,000                           |
+|      Kosten pro Abfrage      |                     $0                     |                             $0.00004                            |
+|         Infrastruktur        |                Zentralisiert               |                         Dezentralisiert                         |
+|      Engineering expense     |                $200 per hour               |                          Eingeschlossen                         |
+|    Geografische Redundanz    |  $1,200 in total costs per additional node |                          Eingeschlossen                         |
+|         Betriebszeit         |                  Variiert                  |                              99.9%+                             |
+|    Monatliche Gesamtkosten   | <span className="highlight-row" /> $1,650+ |                               $120                              |
 
 ## High Volume User (~30M queries per month)
 
-|        Cost Comparison       |                 Self Hosted                 |                        The Graph Network                        |
+|        Kostenvergleich       |               Selbst gehostet               |                        The Graph Network                        |
 | :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
-|     Monthly server cost\*    |          $1100 per month, per node          |                                $0                               |
-|          Query costs         |                    $4000                    |                         $1,200 per month                        |
+|   Monatliche Serverkosten\*  |          $1100 per month, per node          |                                $0                               |
+|         Abfragekosten        |                    $4000                    |                         $1,200 per month                        |
 |    Number of nodes needed    |                      10                     |                          Not applicable                         |
-| Engineering time<sup>†</sup> |           $6,000 or more per month          | None, built into the network with globally distributed Indexers |
-|       Queries per month      |        Limited to infra capabilities        |                           ~30,000,000                           |
-|        Cost per query        |                      $0                     |                             $0.00004                            |
-|         Infrastruktur        |                 Centralized                 |                          Decentralized                          |
-|     Geographic redundancy    |  $1,200 in total costs per additional node  |                             Included                            |
-|            Uptime            |                    Varies                   |                              99.9%+                             |
-|      Total Monthly Costs     | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+| Entwicklungszeit<sup>†</sup> |           $6,000 or more per month          | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
+|      Abfragen pro Monat      |  Begrenzt auf infrastrukturelle Fähigkeiten |                           ~30,000,000                           |
+|      Kosten pro Abfrage      |                      $0                     |                             $0.00004                            |
+|         Infrastruktur        |                Zentralisiert                |                         Dezentralisiert                         |
+|    Geografische Redundanz    |  $1,200 in total costs per additional node  |                          Eingeschlossen                         |
+|         Betriebszeit         |                   Variiert                  |                              99.9%+                             |
+|    Monatliche Gesamtkosten   | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
 
 \*including costs for backup: $50-$100 per month
 

From 9aaf2d5b1f9596c9d3630c90aac31c9b05497196 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 06:41:04 -0500
Subject: [PATCH 3644/3820] New translations tokenomics.mdx (German)

---
 website/pages/de/resources/tokenomics.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/de/resources/tokenomics.mdx b/website/pages/de/resources/tokenomics.mdx
index 210c1a2ecacf..e70acd570f21 100644
--- a/website/pages/de/resources/tokenomics.mdx
+++ b/website/pages/de/resources/tokenomics.mdx
@@ -81,15 +81,15 @@ Indexers can earn GRT rewards in two ways:
 
 Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
 
-In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
+Um einen Indexierungsknoten betreiben zu können, müssen Indexer mindestens 100.000 GRT selbst in das Netzwerk einbringen. Für Indexer besteht ein Anreiz, GRT im Verhältnis zur Anzahl der von ihnen bearbeiteten Abfragen selbst einzunehmen.
 
-Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
+Indexer können ihre GRT-Zuteilungen auf Subgraphen erhöhen, indem sie GRT-Delegationen von Delegatoren akzeptieren, und sie können bis zum 16-fachen ihres ursprünglichen Eigenanteils akzeptieren. Wenn ein Indexer „überdelegiert“ wird (d.h. mehr als das 16-fache seines ursprünglichen Eigenanteils), kann er die zusätzlichen GRT von Delegatoren nicht nutzen, bis er seinen Eigenanteil im Netzwerk erhöht.
 
-The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
+Die Höhe der Rewards, die ein Indexer erhält, kann je nach Eigenanteil des Indexers, akzeptierter Delegation, Qualität der Dienstleistung und vielen weiteren Faktoren variieren.
 
-## Token Supply: Burning & Issuance
+## Token-Versorgung: Burning & Emission
 
-The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
+Das anfängliche Token-Angebot beträgt 10 Milliarden GRT, mit einem Ziel von 3 % Neuemissionen pro Jahr, um Indexer für die Zuweisung von Anteilen an Subgraphen zu belohnen. Das bedeutet, dass das Gesamtangebot an GRT-Token jedes Jahr um 3 % steigen wird, da neue Token an Indexer für ihren Beitrag zum Netzwerk ausgegeben werden.
 
 The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
 

From 6212fb87296946a95c90366810f4003f9057df86 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 06:41:06 -0500
Subject: [PATCH 3645/3820] New translations delegating.mdx (German)

---
 .../resources/roles/delegating/delegating.mdx | 46 +++++++++----------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/website/pages/de/resources/roles/delegating/delegating.mdx b/website/pages/de/resources/roles/delegating/delegating.mdx
index d6dedfac53ca..7522a23a0b03 100644
--- a/website/pages/de/resources/roles/delegating/delegating.mdx
+++ b/website/pages/de/resources/roles/delegating/delegating.mdx
@@ -2,54 +2,54 @@
 title: Delegieren
 ---
 
-To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+Wenn Sie sofort mit dem Delegieren beginnen möchten, schauen Sie sich [delegate on the graph] (https://thegraph.com/explorer/delegate?chain=arbitrum-one) an.
 
 ## Überblick
 
-Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
+Delegatoren verdienen GRT, indem sie GRT an Indexer delegieren, was die Sicherheit und Funktionalität des Netzwerks erhöht.
 
 <VideoEmbed youtube="VACg8bitnVc" />
 
-## Benefits of Delegating
+## Vorteile des Delegierens
 
-- Strengthen the network’s security and scalability by supporting Indexers.
-- Earn a portion of rewards generated by the Indexers.
+- Stärkung der Sicherheit und Skalierbarkeit des Netzwerks durch Unterstützung von Indexern.
+- Verdienen Sie einen Teil der Rewards, die von den Indexers generiert werden.
 
-## How Does Delegation Work?
+## Wie funktioniert die Delegation?
 
-Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
+Delegatoren erhalten GRT Rewards von dem/den Indexer(n), an den/die sie ihr GRT delegieren.
 
-An Indexer's ability to process queries and earn rewards depends on three key factors:
+Die Fähigkeit eines Indexers, Abfragen zu verarbeiten und Rewards zu verdienen, hängt von drei Schlüsselfaktoren ab:
 
-1. The Indexer's Self-Stake (GRT staked by the Indexer).
-2. The total GRT delegated to them by Delegators.
-3. The price the Indexer sets for queries.
+1. Die Selbstbeteiligung des Indexers (GRT, die vom Indexer eingesetzt werden).
+2. Die gesamte GRT, die ihnen von den Delegatoren übertragen wurde.
+3. Der Preis, den der Indexer für Abfragen festlegt.
 
-The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
+Je mehr GRT eingesetzt und an einen Indexer delegiert werden, desto mehr Abfragen können bedient werden, was zu höheren potenziellen Rewards sowohl für den Delegator als auch für den Indexer führt.
 
-### What is Delegation Capacity?
+### Was ist Delegationsfähigkeit?
 
-Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
+Die Delegationskapazität bezieht sich auf die maximale Menge an GRT, die ein Indexer von Delegatoren annehmen kann, basierend auf der Selbstbeteiligung des Indexers.
 
-The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
+The Graph Network beinhaltet ein Delegationsverhältnis von 16, d.h. ein Indexer kann bis zum 16-fachen seines Eigenanteils an delegiertem GRT annehmen.
 
-For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
+Ein Beispiel: Wenn ein Indexer eine Selbstabnahme von 1 Mio. GRT hat, beträgt seine Delegationskapazität 16 Mio. GRT.
 
-### Why Does Delegation Capacity Matter?
+### Warum ist die Delegationsfähigkeit so wichtig?
 
-If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
+Wenn ein Indexer seine Delegationskapazität überschreitet, werden die Rewards für alle Delegatoren verwässert, da das überschüssige delegierte GRT innerhalb des Protokolls nicht effektiv genutzt werden kann.
 
-This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
+Daher ist es für die Delegatoren von entscheidender Bedeutung, die aktuelle Delegationskapazität eines Indexers zu bewerten, bevor sie einen Indexer auswählen.
 
-Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
+Indexer können ihre Delegationskapazität erhöhen, indem sie ihre Selbstbeteiligung erhöhen und damit das Limit für delegierte Token anheben.
 
-## Delegation on The Graph
+## Delegation auf The Graph
 
 <VideoEmbed youtube="HVyIrMcNu7I" />
 
-> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
+> Bitte beachten Sie, dass dieser Leitfaden nicht auf Schritte wie die Einrichtung von MetaMask eingeht. Die Ethereum Community bietet eine [umfassende Ressource zu Wallets] (https://ethereum.org/en/wallets/).
 
-There are two sections in this guide:
+Dieser Leitfaden besteht aus zwei Abschnitten:
 
 - Die Risiken der Übertragung von Token in The Graph Network
 - Wie man als Delegator die erwarteten Erträge berechnet

From 423f1bb9acfcf3eba62c6b9e2244df282cdd500d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 09:03:56 -0500
Subject: [PATCH 3646/3820] New translations glossary.mdx (German)

---
 website/pages/de/resources/glossary.mdx | 32 ++++++++++++-------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/website/pages/de/resources/glossary.mdx b/website/pages/de/resources/glossary.mdx
index 072bb6e60f8d..7f7d789a8550 100644
--- a/website/pages/de/resources/glossary.mdx
+++ b/website/pages/de/resources/glossary.mdx
@@ -1,36 +1,36 @@
 ---
-title: Glossary
+title: Glossar
 ---
 
-- **The Graph**: A decentralized protocol for indexing and querying data.
+- **The Graph**: Ein dezentrales Protokoll zur Indizierung und Abfrage von Daten.
 
-- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
+- **Abfrage**: Eine Anfrage nach Daten. Im Fall von The Graph ist eine Abfrage eine Anfrage nach Daten aus einem Subgraph, die von einem Indexer beantwortet wird.
 
-- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+- **GraphQL**: Eine Abfragesprache für APIs und eine Laufzeitumgebung, um diese Abfragen mit Ihren vorhandenen Daten zu erfüllen. The Graph verwendet GraphQL, um Subgraphen abzufragen.
 
-- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
+- **Endpunkt**: Eine URL, die zur Abfrage eines Subgraphen verwendet werden kann. Der Test-Endpunkt für Subgraph Studio ist `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` und der Graph Explorer Endpunkt ist `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. Der The Graph Explorer Endpunkt wird verwendet, um Subgraphen im dezentralen Netzwerk von The Graph abzufragen.
 
-- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
+- **Subgraph**: Eine offene API, die Daten aus einer Blockchain extrahiert, verarbeitet und so speichert, dass sie einfach über GraphQL abgefragt werden können. Entwickler können einen Subgraph erstellen, bereitstellen und auf The Graph Network veröffentlichen. Sobald der Subgraph indiziert ist, kann er von jedem abgefragt werden.
 
-- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+- **Indexer**: Netzwerkteilnehmer, die Indexierungsknoten betreiben, um Daten aus Blockchains zu indexieren und GraphQL-Abfragen zu bedienen.
 
-- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+- **Einkommensströme für Indexer**: Indexer werden in GRT mit zwei Komponenten belohnt: Rabatte auf Abfragegebühren und Rewards für die Indizierung.
 
-  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+  1. **Abfragegebühren-Rabatte**: Zahlungen von Subgraph-Konsumenten für die Bedienung von Anfragen im Netz.
 
-  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+  2. **Indizierungs-Rewards**: Die Rewards, die Indexer für die Indizierung von Subgraphen erhalten. Indexing Rewards werden durch die Neuausgabe von 3% GRT jährlich generiert.
 
-- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+- **Selbstbeteiligung der Indexer**: Der Betrag an GRT, den Indexer einsetzen, um am dezentralen Netzwerk teilzunehmen. Das Minimum beträgt 100.000 GRT, eine Obergrenze gibt es nicht.
 
-- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
+- **Delegationskapazität**: Die maximale Menge an GRT, die ein Indexer von Delegatoren annehmen kann. Indexer können nur bis zum 16-fachen ihres Indexer-Eigenanteils akzeptieren, und zusätzliche Delegationen führen zu verwässerten Rewards. Ein Datenbeispiel: Wenn ein Indexer eine Selbsteinnahme von 1 Mio. GRT hat, beträgt seine Delegationskapazität 16 Mio. GRT. Indexer können jedoch ihre Delegationskapazität erhöhen, indem sie ihre Selbstbeteiligung erhöhen.
 
-- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
+- **Upgrade Indexer**: Ein Indexer, der als Fallback für Subgraph-Abfragen dient, die von anderen Indexern im Netzwerk nicht bedient werden. Der Upgrade Indexer ist nicht konkurrenzfähig zu anderen Indexern.
 
-- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+- **Delegator**: Netzwerkteilnehmer, die GRT besitzen und ihre GRT an Indexer delegieren. Dadurch können Indexer ihren Anteil an Subgraphen im Netzwerk erhöhen. Im Gegenzug erhalten Delegatoren einen Teil der Indexing Rewards, die Indexer für die Bearbeitung von Subgraphen erhalten.
 
-- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+- **Delegationssteuer**: Eine 0,5%ige Gebühr, die von Delegatoren gezahlt wird, wenn sie GRT an Indexer delegieren. Die GRT, die zur Zahlung der Gebühr verwendet werden, werden verbrannt.
 
-- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
+- **Kurator**: Netzwerkteilnehmer, die qualitativ hochwertige Subgraphen identifizieren und GRT für sie im Austausch für Kurationsanteile signalisieren. Wenn Indexer Abfragegebühren für einen Subgraph einfordern, werden 10% an die Kuratoren dieses Subgraphen verteilt. Es besteht eine positive Korrelation zwischen der Höhe der signalisierten GRT und der Anzahl der Indexer, die einen Subgraph indexieren.
 
 - **Kurationssteuer**: Eine Gebühr von 1 %, die von Kuratoren gezahlt wird, wenn sie GRT auf Subgraphen melden. Die GRT, die zur Zahlung der Gebühr verwendet wird, wird verbrannt.
 

From 1f955c2f4c6a1666058573ad89c7e5a4fdc6dcd5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 09:03:57 -0500
Subject: [PATCH 3647/3820] New translations benefits.mdx (German)

---
 website/pages/de/resources/benefits.mdx | 72 ++++++++++++-------------
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/website/pages/de/resources/benefits.mdx b/website/pages/de/resources/benefits.mdx
index 10236e03323b..4c48aa984b61 100644
--- a/website/pages/de/resources/benefits.mdx
+++ b/website/pages/de/resources/benefits.mdx
@@ -41,52 +41,52 @@ Die Abfragekosten können variieren; die angegebenen Kosten sind der Durchschnit
 
 ## Benutzer mit mittlerem Volumen (~3M Abfragen pro Monat)
 
-|        Kostenvergleich       |               Selbst gehostet              |                        The Graph Network                        |
-| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
-|   Monatliche Serverkosten\*  |               $350 pro Monat               |                                $0                               |
-|         Abfragekosten        |               $500 per month               |                          $120 per month                         |
-| Entwicklungszeit<sup>†</sup> |               $800 per month               | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
-|      Abfragen pro Monat      | Begrenzt auf infrastrukturelle Fähigkeiten |                            ~3,000,000                           |
-|      Kosten pro Abfrage      |                     $0                     |                             $0.00004                            |
-|         Infrastruktur        |                Zentralisiert               |                         Dezentralisiert                         |
-|      Engineering expense     |                $200 per hour               |                          Eingeschlossen                         |
-|    Geografische Redundanz    |  $1,200 in total costs per additional node |                          Eingeschlossen                         |
-|         Betriebszeit         |                  Variiert                  |                              99.9%+                             |
-|    Monatliche Gesamtkosten   | <span className="highlight-row" /> $1,650+ |                               $120                              |
+|        Kostenvergleich       |                Selbst gehostet               |                        The Graph Network                        |
+| :--------------------------: | :------------------------------------------: | :-------------------------------------------------------------: |
+|   Monatliche Serverkosten\*  |                $350 pro Monat                |                                $0                               |
+|         Abfragekosten        |             500 Dollar pro Monat             |                       120 Dollar pro Monat                      |
+| Entwicklungszeit<sup>†</sup> |             800 Dollar pro Monat             | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
+|      Abfragen pro Monat      |  Begrenzt auf infrastrukturelle Fähigkeiten  |                            ~3,000,000                           |
+|      Kosten pro Abfrage      |                      $0                      |                             $0.00004                            |
+|         Infrastruktur        |                 Zentralisiert                |                         Dezentralisiert                         |
+|      Entwicklungskosten      |             200 Dollar pro Stunde            |                          Eingeschlossen                         |
+|    Geografische Redundanz    | 1.200 $ Gesamtkosten pro zusätzlichem Knoten |                          Eingeschlossen                         |
+|         Betriebszeit         |                   Variiert                   |                              99.9%+                             |
+|    Monatliche Gesamtkosten   |  <span className=„highlight-row“ /> $1.650+  |                               $120                              |
 
-## High Volume User (~30M queries per month)
+## Nutzer mit hohem Volumen (~30M Abfragen pro Monat)
 
-|        Kostenvergleich       |               Selbst gehostet               |                        The Graph Network                        |
-| :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
-|   Monatliche Serverkosten\*  |          $1100 per month, per node          |                                $0                               |
-|         Abfragekosten        |                    $4000                    |                         $1,200 per month                        |
-|    Number of nodes needed    |                      10                     |                          Not applicable                         |
-| Entwicklungszeit<sup>†</sup> |           $6,000 or more per month          | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
-|      Abfragen pro Monat      |  Begrenzt auf infrastrukturelle Fähigkeiten |                           ~30,000,000                           |
-|      Kosten pro Abfrage      |                      $0                     |                             $0.00004                            |
-|         Infrastruktur        |                Zentralisiert                |                         Dezentralisiert                         |
-|    Geografische Redundanz    |  $1,200 in total costs per additional node  |                          Eingeschlossen                         |
-|         Betriebszeit         |                   Variiert                  |                              99.9%+                             |
-|    Monatliche Gesamtkosten   | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+|           Kostenvergleich          |                Selbst gehostet               |                        The Graph Network                        |
+| :--------------------------------: | :------------------------------------------: | :-------------------------------------------------------------: |
+|      Monatliche Serverkosten\*     |          $1100 pro Monat, pro Knoten         |                                $0                               |
+|            Abfragekosten           |                     $4000                    |                      1.200 Dollar pro Monat                     |
+| Anzahl der benötigten Knotenpunkte |                      10                      |                         Nicht anwendbar                         |
+|    Entwicklungszeit<sup>†</sup>    |       6.000 Dollar oder mehr pro Monat       | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
+|         Abfragen pro Monat         |  Begrenzt auf infrastrukturelle Fähigkeiten  |                           ~30,000,000                           |
+|         Kosten pro Abfrage         |                      $0                      |                             $0.00004                            |
+|            Infrastruktur           |                 Zentralisiert                |                         Dezentralisiert                         |
+|       Geografische Redundanz       | 1.200 $ Gesamtkosten pro zusätzlichem Knoten |                          Eingeschlossen                         |
+|            Betriebszeit            |                   Variiert                   |                              99.9%+                             |
+|       Monatliche Gesamtkosten      |  <span className="highlight-row" /> $11,000+ |                              $1,200                             |
 
-\*including costs for backup: $50-$100 per month
+\*einschließlich der Kosten für die Datensicherung: $50-$100 pro Monat
 
-<sup>†</sup>Engineering time based on $200 per hour assumption
+<sup>†</sup>Engineering-Zeit auf der Grundlage von 200 $ pro Stunde angenommen
 
-<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+<sup>‡</sup>Reflektiert die Kosten für den Datenkonsumenten. Für Abfragen im Rahmen des „Free Plan“ werden nach wie vor Abfragegebühren an Indexer gezahlt.
 
-Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+Die geschätzten Kosten gelten nur für Ethereum Mainnet Subgraphen - die Kosten sind noch höher, wenn man selbst einen „Graph-Knoten“ in anderen Netzwerken hostet. Einige Nutzer müssen ihren Subgraph möglicherweise auf eine neue Version aktualisieren. Aufgrund der Ethereum-Gas-Gebühren kostet ein Update zum Zeitpunkt des Schreibens ~$50. Beachten Sie, dass die Gasgebühren auf [Arbitrum](/archived/arbitrum/arbitrum-faq/) wesentlich niedriger sind als im Ethereum Mainnet.
 
-Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process).
+Das Kuratieren von Signalen auf einem Subgraph ist eine optionale, einmalige Investition mit Netto-Nullkosten (z.B. können Signale im Wert von 1.000 Dollar auf einem Subgraph kuratiert und später wieder abgezogen werden - mit dem Potenzial, dabei Renditen zu erzielen).
 
-## No Setup Costs & Greater Operational Efficiency
+## Keine Einrichtungskosten und größere betriebliche Effizienz
 
-Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources.
+Keine Einrichtungsgebühren. Sie können sofort loslegen, ohne Einrichtungs- oder Gemeinkosten. Keine Hardware-Anforderungen. Keine Ausfälle aufgrund einer zentralisierten Infrastruktur und mehr Zeit, um sich auf Ihr Kernprodukt zu konzentrieren. Kein Bedarf an Backup-Servern, Fehlersuche oder teuren technischen Ressourcen.
 
-## Reliability & Resiliency
+## Zuverlässigkeit und Ausfallsicherheit
 
-The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+Das dezentralisierte Netzwerk von The Graph bietet den Nutzern Zugang zu einer geografischen Redundanz, die beim Selbsthosten eines „Graph-Knotens“ nicht gegeben ist. Abfragen werden dank einer Betriebszeit von über 99,9 %, die durch Hunderte unabhängiger Indexer erreicht wird, die das Netzwerk weltweit sichern, zuverlässig bedient.
 
-Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+Unterm Strich: Das The Graph Network ist kostengünstiger, einfacher zu benutzen und liefert bessere Ergebnisse als ein lokaler Graph-Knoten.
 
-Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).
+Beginnen Sie noch heute mit der Nutzung von The Graph Network und erfahren Sie, wie Sie [Ihren Subgraph im dezentralen Netzwerk von The Graph veröffentlichen](/subgraphs/quick-start/).

From 251aa697ddce723e70e246d5cf4d689b48646d59 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 09:03:58 -0500
Subject: [PATCH 3648/3820] New translations tokenomics.mdx (German)

---
 website/pages/de/resources/tokenomics.mdx | 78 +++++++++++------------
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/website/pages/de/resources/tokenomics.mdx b/website/pages/de/resources/tokenomics.mdx
index e70acd570f21..8637eb5bde73 100644
--- a/website/pages/de/resources/tokenomics.mdx
+++ b/website/pages/de/resources/tokenomics.mdx
@@ -1,85 +1,85 @@
 ---
 title: Tokenomics des The Graph Netzwerks
-description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
+description: The Graph Network wird durch leistungsstarke Tokenomics incentiviert. So funktioniert GRT, der The Graph-eigene Arbeits-Utility-Token.
 ---
 
 ## Überblick
 
-The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
+The Graph ist ein dezentrales Protokoll, das einen einfachen Zugang zu Blockchain-Daten ermöglicht. Es indiziert Blockchain-Daten ähnlich wie Google das Web indiziert. Wenn Sie eine Dapp verwendet haben, die Daten aus einem Subgraph abruft, haben Sie wahrscheinlich mit The Graph interagiert. Heute nutzen Tausende von [beliebten Dapps](https://thegraph.com/explorer) im web3-Ökosystem The Graph.
 
 ## Besonderheiten
 
-The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
+Das Modell von The Graph ähnelt einem B2B2C-Modell, wird aber von einem dezentralen Netzwerk angetrieben, in dem die Teilnehmer zusammenarbeiten, um den Endnutzern Daten im Austausch für GRT Rewards zur Verfügung zu stellen. GRT ist der Utility Token für The Graph. Er koordiniert und fördert die Interaktion zwischen Datenanbietern und Verbrauchern innerhalb des Netzwerks.
 
-The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
+The Graph spielt eine wichtige Rolle dabei, Blockchain-Daten besser zugänglich zu machen und unterstützt einen Marktplatz für deren Austausch. Wenn Sie mehr über das „Pay-for-what-you-need“-Modell von The Graph erfahren möchten, sehen Sie sich die [kostenlosen und Wachstumspläne](/subgraphs/billing/) an.
 
-- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+- GRT Token Adresse im Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
 
-- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+- GRT Token Adresse auf Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
 
-## The Roles of Network Participants
+## Die Rollen der Netzwerkteilnehmer
 
-There are four primary network participants:
+Es gibt vier primäre Netzwerkteilnehmer:
 
-1. Delegators - Delegate GRT to Indexers & secure the network
+1. Delegatoren - Delegieren Sie GRT an Indexer und sichern Sie das Netzwerk
 
 2. Kuratoren - Finden Sie die besten Untergraphen für Indexer
 
-3. Developers - Build & query subgraphs
+3. Entwickler - Subgraphen erstellen und abfragen
 
 4. Indexer - Das Rückgrat der Blockchain-Daten
 
-Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
+Fischer und Schlichter tragen auch durch andere Beiträge zum Erfolg des Netzwerks bei und unterstützen die Arbeit der anderen Hauptbeteiligten. Weitere Informationen über die Rollen des Netzwerks finden Sie in [diesem Artikel] (https://thegraph.com/blog/the-graph-grt-token-economics/).
 
-![Tokenomics diagram](/img/updated-tokenomics-image.png)
+![Tokenomics-Diagramm](/img/aktualisiertes-tokenomics-bild.png)
 
-## Delegators (Passively earn GRT)
+## Delegatoren (verdienen passiv GRT)
 
-Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
+Indexer werden von Delegatoren mit GRT betraut, wodurch sich der Anteil des Indexers an Subgraphen im Netzwerk erhöht. Im Gegenzug erhalten die Delegatoren einen prozentualen Anteil an allen Abfragegebühren und Rewards des Indexers. Jeder Indexer legt den Anteil, den er an die Delegatoren vergütet, selbständig fest, wodurch ein Wettbewerb zwischen den Indexern entsteht, um Delegatoren anzuziehen. Die meisten Indexer bieten zwischen 9-12% jährlich.
 
-For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
+Ein Datenbeispiel: Wenn ein Delegator 15.000 GRT an einen Indexer delegiert, der 10 % anbietet, würde der Delegator jährlich ~ 1.500 GRT an Rewards erhalten.
 
-There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
+Es gibt eine Delegationssteuer von 0,5 %, die jedes Mal erhoben wird, wenn ein Delegator GRT an das Netzwerk delegiert. Wenn ein Delegator beschließt, sein delegiertes GRT zurückzuziehen, muss er die 28-Epochen-Frist abwarten, in der die Bindung aufgehoben wird. Jede Epoche besteht aus 6.646 Blöcken, was bedeutet, dass 28 Epochen ungefähr 26 Tagen entsprechen.
 
-If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
+Wenn Sie dies lesen, können Sie sofort Delegator werden, indem Sie auf die [Netzwerkteilnehmerseite] (https://thegraph.com/explorer/participants/indexers) gehen und GRT an einen Indexer Ihrer Wahl delegieren.
 
-## Curators (Earn GRT)
+## Kuratoren (GRT verdienen)
 
-Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
+Kuratoren identifizieren qualitativ hochwertige Subgraphen und „kuratieren“ sie (d.h. signalisieren GRT auf ihnen), um Kurationsanteile zu verdienen, die einen Prozentsatz aller zukünftigen Abfragegebühren garantieren, die durch den Subgraphen generiert werden. Obwohl jeder unabhängige Netzwerkteilnehmer ein Kurator sein kann, gehören Entwickler von Subgraphen in der Regel zu den ersten Kuratoren für ihre eigenen Subgraphen, da sie sicherstellen wollen, dass ihr Subgraph indiziert wird.
 
-Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
+Die Entwickler von Subgraphen werden ermutigt, ihren Subgraph mit mindestens 3.000 GRT zu kuratieren. Diese Zahl kann jedoch von der Netzwerkaktivität und der Beteiligung der Community beeinflusst werden.
 
-Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
+Kuratoren zahlen eine Kurationssteuer von 1%, wenn sie einen neuen Subgraph kuratieren. Diese Kurationssteuer wird verbrannt, wodurch das Angebot an GRT sinkt.
 
-## Developers
+## Entwickler
 
-Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
+Entwickler erstellen Subgraphen und fragen sie ab, um Blockchain-Daten abzurufen. Da Subgraphen quelloffen sind, können Entwickler bestehende Subgraphen abfragen, um Blockchain-Daten in ihre Dapps zu laden. Entwickler zahlen für ihre Abfragen in GRT, das an die Netzwerkteilnehmer verteilt wird.
 
 ### Erstellung eines Untergraphen
 
-Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
+Entwickler können [einen Subgraph erstellen](/developing/creating-a-subgraph/), um Daten auf der Blockchain zu indizieren. Subgraphen sind Anweisungen für Indexer darüber, welche Daten an Verbraucher geliefert werden sollen.
 
-Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
+Sobald Entwickler ihren Subgraph gebaut und getestet haben, können sie ihn im dezentralen Netzwerk von The Graph veröffentlichen (/subgraphs/developing/publishing/publishing-a-subgraph/).
 
 ### Abfrage eines vorhandenen Untergraphen
 
-Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
+Sobald ein Subgraph im dezentralen Netzwerk von The Graph [veröffentlicht](/subgraphs/developing/publishing/publishing-a-subgraph/) wurde, kann jeder einen API-Schlüssel erstellen, GRT zu seinem Guthaben hinzufügen und den Subgraph abfragen.
 
-Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
+Subgraphen werden [mit GraphQL abgefragt](/subgraphs/querying/introduction/), und die Abfragegebühren werden mit GRT in [Subgraph Studio](https://thegraph.com/studio/) bezahlt. Die Abfragegebühren werden an die Netzwerkteilnehmer auf der Grundlage ihrer Beiträge zum Protokoll verteilt.
 
-1% of the query fees paid to the network are burned.
+1 % der an das Netz gezahlten Abfragegebühren werden verbrannt.
 
-## Indexers (Earn GRT)
+## Indexer (GRT verdienen)
 
-Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
+Indexer sind das Rückgrat von The Graph. Sie betreiben unabhängige Hardware und Software, die das dezentrale Netzwerk von The Graph antreiben. Indexer versorgen die Verbraucher mit Daten, die auf Anweisungen von Subgraphen basieren.
 
-Indexers can earn GRT rewards in two ways:
+Indexer können GRT Rewards auf zwei Arten verdienen:
 
-1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+1. **Abfragegebühren**: GRT, die von Entwicklern oder Nutzern für die Abfrage von Subgraph-Daten gezahlt werden. Abfragegebühren werden gemäß der exponentiellen Rabattfunktion direkt an Indexer verteilt (siehe GIP [hier](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
 
-2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
+2. **Indexing Rewards**: Die jährliche Ausgabe von 3% wird an Indexer verteilt, basierend auf der Anzahl der Subgraphen, die sie indexieren. Diese Rewards sind ein Anreiz für Indexer, Subgraphen zu indizieren, gelegentlich vor Beginn der Abfragegebühren, um Proofs of Indexing (POIs) zu sammeln und einzureichen, die bestätigen, dass sie Daten korrekt indiziert haben.
 
-Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
+Jedem Subgraph wird ein Teil der gesamten Netzwerk-Token-Ausgabe zugeteilt, basierend auf der Höhe des Kurationssignals des Subgraphen. Dieser Betrag wird dann an Indexer auf der Grundlage ihres zugewiesenen Anteils an dem Subgraph belohnt.
 
 Um einen Indexierungsknoten betreiben zu können, müssen Indexer mindestens 100.000 GRT selbst in das Netzwerk einbringen. Für Indexer besteht ein Anreiz, GRT im Verhältnis zur Anzahl der von ihnen bearbeiteten Abfragen selbst einzunehmen.
 
@@ -91,12 +91,12 @@ Die Höhe der Rewards, die ein Indexer erhält, kann je nach Eigenanteil des Ind
 
 Das anfängliche Token-Angebot beträgt 10 Milliarden GRT, mit einem Ziel von 3 % Neuemissionen pro Jahr, um Indexer für die Zuweisung von Anteilen an Subgraphen zu belohnen. Das bedeutet, dass das Gesamtangebot an GRT-Token jedes Jahr um 3 % steigen wird, da neue Token an Indexer für ihren Beitrag zum Netzwerk ausgegeben werden.
 
-The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
+The Graph ist mit mehreren Brennmechanismen ausgestattet, um die Ausgabe neuer Token auszugleichen. Ungefähr 1 % des GRT-Angebots wird jährlich durch verschiedene Aktivitäten im Netzwerk verbrannt, und diese Zahl steigt, da die Netzwerkaktivität weiter zunimmt. Zu diesen Burning-Aktivitäten gehören eine Delegationssteuer von 0,5 %, wenn ein Delegator GRT an einen Indexer delegiert, eine Kurationssteuer von 1 %, wenn Kuratoren ein Signal auf einem Subgraph geben, und 1 % der Abfragegebühren für Blockchain-Daten.
 
-![Total burned GRT](/img/total-burned-grt.jpeg)
+[[Insgesamt verbrannte GRT](/img/total-burned-grt.jpeg)
 
-In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
+Zusätzlich zu diesen regelmäßig stattfindenden Verbrennungsaktivitäten verfügt der GRT-Token auch über einen Slashing-Mechanismus, um böswilliges oder unverantwortliches Verhalten von Indexern zu bestrafen. Wenn ein Indexer geslashed wird, werden 50% seiner Rewards für die Epoche verbrannt (während die andere Hälfte an den Fischer geht), und sein Eigenanteil wird um 2,5% gekürzt, wobei die Hälfte dieses Betrags verbrannt wird. Dies trägt dazu bei, dass Indexer einen starken Anreiz haben, im besten Interesse des Netzwerks zu handeln und zu dessen Sicherheit und Stabilität beizutragen.
 
-## Improving the Protocol
+## Verbesserung des Protokolls
 
-The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).
+The Graph Network entwickelt sich ständig weiter, und es werden laufend Verbesserungen an der wirtschaftlichen Gestaltung des Protokolls vorgenommen, um allen Netzwerkteilnehmern die bestmögliche Erfahrung zu bieten. Der The Graph-Rat überwacht die Protokolländerungen, und die Mitglieder der Community sind aufgerufen, sich daran zu beteiligen. Beteiligen Sie sich an der Verbesserung des Protokolls im [The Graph Forum] (https://forum.thegraph.com/).

From c39695585f499e22a78dff8c4ee358d7c4a9c91d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 09:03:59 -0500
Subject: [PATCH 3649/3820] New translations triggers.mdx (German)

---
 website/pages/de/sps/triggers.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/sps/triggers.mdx b/website/pages/de/sps/triggers.mdx
index ab9828bc0427..1ecbe25b6727 100644
--- a/website/pages/de/sps/triggers.mdx
+++ b/website/pages/de/sps/triggers.mdx
@@ -1,5 +1,5 @@
 ---
-title: Substreams Triggers
+title: Auslöser für Substreams
 ---
 
 Use Custom Triggers and enable the full use GraphQL.

From fb63059ac75ac5edbfb42b3fb784dd7d7607495e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 09:04:01 -0500
Subject: [PATCH 3650/3820] New translations delegating.mdx (German)

---
 .../resources/roles/delegating/delegating.mdx | 30 +++++++++----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/website/pages/de/resources/roles/delegating/delegating.mdx b/website/pages/de/resources/roles/delegating/delegating.mdx
index 7522a23a0b03..a5114e0ac8cf 100644
--- a/website/pages/de/resources/roles/delegating/delegating.mdx
+++ b/website/pages/de/resources/roles/delegating/delegating.mdx
@@ -58,7 +58,7 @@ Dieser Leitfaden besteht aus zwei Abschnitten:
 
 Nachfolgend sind die wichtigsten Risiken aufgeführt, die mit der Tätigkeit eines Delegators im Protokoll verbunden sind.
 
-### The Delegation Tax
+### Die Delegationssteuer
 
 Delegatoren können nicht für schlechtes Verhalten bestraft werden, aber es gibt eine Steuer für Delegatoren, um von schlechten Entscheidungen abzuschrecken, die die Integrität des Netzes beeinträchtigen könnten.
 
@@ -68,19 +68,19 @@ Als Delegator ist es wichtig, die folgenden Punkte zu verstehen:
 
 - Um auf Nummer sicher zu gehen, sollten Sie Ihre potenzielle Rendite berechnen, wenn Sie einen Indexer beauftragen. Als Beispiel könnten Sie berechnen, wie viele Tage es dauern wird, bis Sie die 0,5 % Steuer auf Ihre Delegation zurückverdient haben.
 
-### The Undelegation Period
+### Der Zeitraum der Undelegation
 
-When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
+Wenn ein Delegator die Delegation aufhebt, gilt für seine Token eine Frist von 28 Tagen für die Delegation.
 
-This means they cannot transfer their tokens or earn any rewards for 28 days.
+Das bedeutet, dass sie 28 Tage lang weder ihre Token übertragen noch Rewards verdienen können.
 
-After the undelegation period, GRT will return to your crypto wallet.
+Nach Ablauf der Frist wird GRT in Ihre Wallet zurückgegeben.
 
 ### Warum ist das wichtig?
 
-If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
+Wenn Sie sich für einen Indexer entscheiden, der nicht vertrauenswürdig ist oder keine gute Arbeit leistet, werden Sie die Abtretung rückgängig machen wollen. Das bedeutet, dass Sie die Möglichkeit verlieren, Rewards zu verdienen.
 
-As a result, it’s recommended that you choose an Indexer wisely.
+Es empfiehlt sich daher, einen Indexer mit Bedacht auszuwählen.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
@@ -102,25 +102,25 @@ mittlere gibt den Delegatoren 20 %. Der untere gibt den Delegatoren ~83 %.*
 
 - **Kürzung der Abfragegebühren** - Dies ist genau wie die Indizierung der Rewardkürzung, aber es gilt für die Renditen der Abfragegebühren, die der Indexer einnimmt.
 
-- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
+- Es wird dringend empfohlen, [The Graph Discord] (https://discord.gg/graphprotocol) zu erkunden, um festzustellen, welche Indexer den besten sozialen und technischen Ruf haben.
 
-- Many Indexers are active in Discord and will be happy to answer your questions.
+- Viele Indexer sind in Discord aktiv und beantworten gerne Ihre Fragen.
 
 ## Berechnung der erwarteten Rendite der Delegatoren
 
-> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+> Berechnen Sie den ROI für Ihre Delegation [hier] (https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-A Delegator must consider a variety of factors to determine a return:
+Ein Delegator muss eine Vielzahl von Faktoren berücksichtigen, um eine Rendite zu bestimmen:
 
-An Indexer's ability to use the delegated GRT available to them impacts their rewards.
+Die Fähigkeit eines Indexers, das ihm zur Verfügung stehende delegierte GRT zu nutzen, wirkt sich auf seine Rewards aus.
 
-If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
+Wenn ein Indexer nicht alle ihm zur Verfügung stehenden GRT einsetzt, verpasst er möglicherweise die Maximierung des Ertragspotenzials für sich und seine Delegatoren.
 
-Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
+Indexer können eine Zuteilung schließen und Rewards jederzeit innerhalb des Zeitfensters von 1 bis 28 Tagen abholen. Werden die Rewards jedoch nicht umgehend abgeholt, kann der Gesamtbetrag der Rewards niedriger erscheinen, selbst wenn ein bestimmter Prozentsatz der Rewards nicht abgeholt wird.
 
 ### Berücksichtigung der Senkung der Abfrage- und Indizierungsgebühren
 
-You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
+Sie sollten einen Indexer wählen, der seine Abfrage- und Indizierungsgebühren transparent festlegt.
 
 Die Formel lautet:
 

From 5158ff92dc894446b3e5ce17c451767028767aa8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 11:38:48 -0500
Subject: [PATCH 3651/3820] New translations assemblyscript-migration-guide.mdx
 (German)

---
 .../assemblyscript-migration-guide.mdx        | 108 +++++++++---------
 1 file changed, 54 insertions(+), 54 deletions(-)

diff --git a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
index 3593edab965c..20063f593224 100644
--- a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -2,49 +2,49 @@
 title: AssemblyScript Migration Guide
 ---
 
-Bis jetzt haben Subgraphen eine der [ersten Versionen von AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6) verwendet. Endlich haben wir Unterstützung für die [neueste verfügbare Version](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10) hinzugefügt! 🎉
+Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
 
 That will enable subgraph developers to use newer features of the AS language and standard library.
 
-Diese Anleitung gilt für alle, die `graph-cli`/`graph-ts` unter Version `0.22.0` verwenden. Wenn Sie bereits eine höhere (oder gleiche) Version als diese haben, haben Sie bereits Version `0.19.10` von AssemblyScript verwendet 🙂
+This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
 
-> Anmerkung: Ab `0.24.0` kann `graph-node` beide Versionen unterstützen, abhängig von der im Subgraph-Manifest angegebenen `apiVersion`.
+> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
 
 ## Features
 
 ### New functionality
 
-- `TypedArray` kann nun aus `ArrayBuffer` mit Hilfe der [neuen statischen Methode `wrap`](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1)) erstellt werden
-- Neue Standard-Bibliotheksfunktionen: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`und `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Unterstützung für x instanceof GenericClass hinzugefügt ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
-- StaticArray<T>“ hinzugefügt, eine effizientere Array-Variante ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
-- Array<T>#flat“ hinzugefügt ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- Radix"-Argument bei `Number#toString` implementiert ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
-- Unterstützung für Trennzeichen in Fließkomma-Literalen hinzugefügt ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
-- Unterstützung für Funktionen erster Klasse hinzugefügt ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
-- Buildins hinzufügen: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
-- Implementiere `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
-- Unterstützung für Template-Literal-Strings hinzugefügt ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
-- Hinzufügen von „encodeURI(Komponente)“ und „decodeURI(Komponente)“ ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
-- Hinzufügen von `toString`, `toDateString` und `toTimeString` zu `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
-- Hinzufügen von `toUTCString` für `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
-- Hinzufügen von `nonnull/NonNullable` builtin Typ ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
 
 ### Optimizations
 
-- Mathefunktionen wie `exp`, `exp2`, `log`, `log2` und `pow` wurden durch schnellere Varianten ersetzt ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Leicht optimierte `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
-- Mehr Feldzugriffe in std Map und Set zwischenspeichern ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
-- Optimieren für Zweierpotenzen in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
 
 ### Other
 
-- Der Typ eines Array-Literal kann nun aus seinem Inhalt abgeleitet werden ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Aktualisierte stdlib auf Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
 
 ## How to upgrade?
 
-1. Ändern Sie Ihre Mappings `apiVersion` in `subgraph.yaml` auf `0.0.6`:
+1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
 
 ```yaml
 ...
@@ -56,7 +56,7 @@ dataSources:
       ...
 ```
 
-2. Aktualisieren Sie die `graph-cli`, die Sie verwenden, auf die `aktuelle` Version, indem Sie sie ausführen:
+2. Update the `graph-cli` you're using to the `latest` version by running:
 
 ```bash
 # if you have it globally installed
@@ -66,14 +66,14 @@ npm install --global @graphprotocol/graph-cli@latest
 npm install --save-dev @graphprotocol/graph-cli@latest
 ```
 
-3. Machen Sie dasselbe für `graph-ts`, aber anstatt es global zu installieren, speichern Sie es in Ihren Hauptabhängigkeiten:
+3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
 
 ```bash
 npm install --save @graphprotocol/graph-ts@latest
 ```
 
 4. Follow the rest of the guide to fix the language breaking changes.
-5. Führen Sie `codegen` und `deploy` erneut aus.
+5. Run `codegen` and `deploy` again.
 
 ## Breaking changes
 
@@ -110,7 +110,7 @@ If you are unsure which to choose, we recommend always using the safe version. I
 
 ### Variable Shadowing
 
-Früher konnte man [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) machen und Code wie dieser würde funktionieren:
+Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
 
 ```typescript
 let a = 10
@@ -141,7 +141,7 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
  in src/mappings/file.ts(41,21)
 ```
 
-Zur Lösung des Problems können Sie die „if“-Anweisung einfach wie folgt ändern:
+To solve you can simply change the `if` statement to something like this:
 
 ```typescript
   if (!decimals) {
@@ -155,7 +155,7 @@ The same applies if you're doing != instead of ==.
 
 ### Casting
 
-Früher war es üblich, das Schlüsselwort „as“ für das Casting zu verwenden, etwa so:
+The common way to do casting before was to just use the `as` keyword, like this:
 
 ```typescript
 let byteArray = new ByteArray(10)
@@ -164,7 +164,7 @@ let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
 
 However this only works in two scenarios:
 
-- Primitives Casting (zwischen Typen wie `u8`, `i32`, `bool`; z.B.: `let b: isize = 10; b als usize`);
+- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
 - Upcasting on class inheritance (subclass → superclass)
 
 Beispiele:
@@ -184,48 +184,48 @@ let bytes = new Bytes(2)
 // <Uint8Array>bytes // same as: bytes as Uint8Array
 ```
 
-Es gibt zwei Szenarien, in denen man casten möchte, aber die Verwendung von `as`/`<T>var` **ist nicht sicher**:
+There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
 
 - Downcasting on class inheritance (superclass → subclass)
 - Between two types that share a superclass
 
 ```typescript
-// Downcasting bei Klassenvererbung
+// downcasting on class inheritance
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-// <Bytes>uint8Array // bricht zur Laufzeit ab :(
+// <Bytes>uint8Array // breaks in runtime :(
 ```
 
 ```typescript
-// zwischen zwei Typen, die sich eine Oberklasse teilen
+// between two types that share a superclass
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
 let bytes = new Bytes(2)
-// <ByteArray>bytes // bricht zur Laufzeit ab :(
+// <ByteArray>bytes // breaks in runtime :(
 ```
 
-Für diese Fälle können Sie die Funktion „changetype<T>“ verwenden:
+For those cases, you can use the `changetype<T>` function:
 
 ```typescript
-// Downcasting bei Klassenvererbung
+// downcasting on class inheritance
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-changetype<Bytes>(uint8Array) // funktioniert :)
+changetype<Bytes>(uint8Array) // works :)
 ```
 
 ```typescript
-// zwischen zwei Typen, die sich eine Oberklasse teilen
+// between two types that share a superclass
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
 let bytes = new Bytes(2)
-changetype<ByteArray>(bytes) // funktioniert :)
+changetype<ByteArray>(bytes) // works :)
 ```
 
-Wenn Sie nur die Nullbarkeit entfernen wollen, können Sie weiterhin den „as“-Operator (oder „<T>Variable“) verwenden, aber stellen Sie sicher, dass Sie wissen, dass der Wert nicht null sein kann, sonst bricht es.
+If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
 
 ```typescript
 // remove nullability
@@ -238,7 +238,7 @@ if (previousBalance != null) {
 let newBalance = new AccountBalance(balanceId)
 ```
 
-Für den Fall der Nichtigkeit empfehlen wir, einen Blick auf das [nullability check feature] (https://www.assemblyscript.org/basics.html#nullability-checks) zu werfen, es wird Ihren Code sauberer machen 🙂
+For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
 
 Also we've added a few more static methods in some types to ease casting, they are:
 
@@ -249,7 +249,7 @@ Also we've added a few more static methods in some types to ease casting, they a
 
 ### Nullability check with property access
 
-Um das [nullability check feature] (https://www.assemblyscript.org/basics.html#nullability-checks) zu verwenden, können Sie entweder `if`-Anweisungen oder den ternären Operator (`?` und `:`) wie folgt verwenden:
+To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
 
 ```typescript
 let something: string | null = 'data'
@@ -267,7 +267,7 @@ if (something) {
 }
 ```
 
-Das funktioniert jedoch nur, wenn Sie das „wenn“ / ternär auf eine Variable anwenden, nicht auf einen Eigenschaftszugriff, wie hier:
+However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
 
 ```typescript
 class Container {
@@ -381,7 +381,7 @@ if (total === null) {
 total.amount = total.amount + BigInt.fromI32(1)
 ```
 
-Sie müssen sicherstellen, dass Sie den Wert „total.amount“ initialisieren, denn wenn Sie versuchen, wie in der letzten Zeile auf die Summe zuzugreifen, wird das Programm abstürzen. Sie müssen ihn also entweder zuerst initialisieren:
+You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
 
 ```typescript
 let total = Total.load('latest')
@@ -394,7 +394,7 @@ if (total === null) {
 total.tokens = total.tokens + BigInt.fromI32(1)
 ```
 
-Oder Sie können einfach Ihr GraphQL-Schema so ändern, dass Sie keinen nullbaren Typ für diese Eigenschaft verwenden, dann werden wir sie im Schritt „Codegen“ mit Null initialisieren 😉
+Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
 
 ```graphql
 type Total @entity {
@@ -425,7 +425,7 @@ export class Something {
 }
 ```
 
-Der Compiler wird einen Fehler machen, weil Sie entweder einen Initialisierer für die Eigenschaften hinzufügen müssen, die Klassen sind, oder den Operator `!` hinzufügen müssen:
+The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
 
 ```typescript
 export class Something {
@@ -451,7 +451,7 @@ export class Something {
 
 ### Array initialization
 
-Die Klasse `Array` akzeptiert immer noch eine Zahl, um die Länge der Liste zu initialisieren, aber Sie sollten vorsichtig sein, weil Operationen wie `.push` die Größe tatsächlich erhöhen, anstatt z.B. zum Anfang hinzuzufügen:
+The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
 
 ```typescript
 let arr = new Array<string>(5) // ["", "", "", "", ""]
@@ -462,10 +462,10 @@ arr.push('something') // ["", "", "", "", "", "something"] // size 6 :(
 Depending on the types you're using, eg nullable ones, and how you're accessing them, you might encounter a runtime error like this one:
 
 ```
-ERRO Handler wurde aufgrund eines Ausführungsfehlers übersprungen, Fehler: Mapping abgebrochen bei ~lib/array.ts, Zeile 110, Spalte 40, mit Meldung: Element type must be nullable if array is holey wasm backtrace: 0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format 1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor 2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
+ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
 ```
 
-Um tatsächlich am Anfang zu pushen, sollte man entweder das `Array` mit der Größe Null initialisieren, wie hier:
+To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
 
 ```typescript
 let arr = new Array<string>(0) // []
@@ -483,7 +483,7 @@ arr[0] = 'something' // ["something", "", "", "", ""]
 
 ### GraphQL schema
 
-Dies ist keine direkte AssemblyScript-Änderung, aber Sie müssen möglicherweise Ihre Datei „schema.graphql“ aktualisieren.
+This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
 
 Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
 
@@ -498,7 +498,7 @@ type MyEntity @entity {
 }
 ```
 
-Sie müssen ein `!` an das Mitglied des Typs List anhängen, etwa so:
+You'll have to add an `!` to the member of the List type, like this:
 
 ```graphql
 type Something @entity {

From 090e9a4ea48c09b2abd743a11a7074d7bdb1dd96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:29 -0500
Subject: [PATCH 3652/3820] New translations ql-schema.mdx (Portuguese)

---
 .../pt/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/pt/subgraphs/developing/creating/ql-schema.mdx b/website/pages/pt/subgraphs/developing/creating/ql-schema.mdx
index 68f010a59b9e..6bb4c8e21c9b 100644
--- a/website/pages/pt/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/pt/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Relacionamentos Vários-com-Vários
 
 Para relacionamentos vários-com-vários, como um conjunto de utilizadores em que cada um pertence a qualquer número de organizações, o relacionamento é mais simplesmente — mas não mais eficientemente — modelado como um arranjo em cada uma das duas entidades envolvidas. Se o relacionamento for simétrico, apenas um lado do relacionamento precisa ser armazenado, e o outro lado pode ser derivado.

From 559f2a8ec42788b6b9e84011aa92c9cec2e82b19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:30 -0500
Subject: [PATCH 3653/3820] New translations ql-schema.mdx (Romanian)

---
 .../ro/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/ro/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ro/subgraphs/developing/creating/ql-schema.mdx
index 8e5789d66650..4ecef1f613b3 100644
--- a/website/pages/ro/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/ro/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Many-To-Many Relationships
 
 For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.

From 296f59b86722dd472b3cd99e73b3e3ebc9eb9278 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:31 -0500
Subject: [PATCH 3654/3820] New translations ql-schema.mdx (French)

---
 .../fr/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx b/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx
index efe6a52fb931..a8850ccaee9f 100644
--- a/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/fr/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Relations plusieurs-à-plusieurs
 
 Pour les relations plusieurs-à-plusieurs, telles que les utilisateurs pouvant appartenir à un nombre quelconque d'organisations, la manière la plus simple, mais généralement pas la plus performante, de modéliser la relation consiste à créer un tableau dans chacune des deux entités impliquées. Si la relation est symétrique, un seul côté de la relation doit être stocké et l’autre côté peut être dérivé.

From 1b47e4d868ec4574fe0c6556a7b8d08e471b7743 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:33 -0500
Subject: [PATCH 3655/3820] New translations ql-schema.mdx (Spanish)

---
 .../es/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/es/subgraphs/developing/creating/ql-schema.mdx b/website/pages/es/subgraphs/developing/creating/ql-schema.mdx
index 92e15ea31fe5..eba35650c4ec 100644
--- a/website/pages/es/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/es/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Relaciones de many-to-many
 
 Para las relaciones de many-to-many, como los usuarios pueden pertenecer a cualquier número de organizaciones, la forma más directa, pero generalmente no la más eficaz, de modelar la relación es en un array en cada una de las dos entidades implicadas. Si la relación es simétrica, sólo es necesario almacenar un lado de la relación y el otro puede derivarse.

From 6cf98dbf56eb557e4146853f5f97b4006a474795 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:34 -0500
Subject: [PATCH 3656/3820] New translations ql-schema.mdx (Arabic)

---
 .../ar/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/ar/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ar/subgraphs/developing/creating/ql-schema.mdx
index 922905fc45b2..2098109cb101 100644
--- a/website/pages/ar/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/ar/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### علاقات متعدد_لمتعدد
 
 For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.

From 588267787c4e217168b9ef5206ea8c440c4efb4e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:35 -0500
Subject: [PATCH 3657/3820] New translations ql-schema.mdx (Czech)

---
 .../cs/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/cs/subgraphs/developing/creating/ql-schema.mdx b/website/pages/cs/subgraphs/developing/creating/ql-schema.mdx
index e3cf65716868..9ad84ea2f335 100644
--- a/website/pages/cs/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/cs/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Vztahy mnoho k mnoha
 
 Pro vztahy mnoho-více, jako jsou uživatelé, z nichž každý může patřit do libovolného počtu organizací, je nejjednodušší, ale obecně ne nejvýkonnější, modelovat vztah jako pole v každé z obou zúčastněných entit. Pokud je vztah symetrický, je třeba uložit pouze jednu stranu vztahu a druhou stranu lze odvodit.

From 7b46635e6862e6462ec5840f49a69cce6977be28 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:36 -0500
Subject: [PATCH 3658/3820] New translations ql-schema.mdx (German)

---
 .../de/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/de/subgraphs/developing/creating/ql-schema.mdx b/website/pages/de/subgraphs/developing/creating/ql-schema.mdx
index 3648340f055d..369ccdd4119a 100644
--- a/website/pages/de/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/de/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Many-To-Many Relationships
 
 For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.

From 7124ef9ed9f1729eecef12bc3a6923138e64b151 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:37 -0500
Subject: [PATCH 3659/3820] New translations ql-schema.mdx (Italian)

---
 .../it/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/it/subgraphs/developing/creating/ql-schema.mdx b/website/pages/it/subgraphs/developing/creating/ql-schema.mdx
index 0801ce841eaa..05ab1fe4c590 100644
--- a/website/pages/it/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/it/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Relazioni molti-a-molti
 
 Per le relazioni molti-a-molti, come ad esempio gli utenti che possono appartenere a un numero qualsiasi di organizzazioni, il modo più semplice, ma generalmente non il più performante, di modellare la relazione è come un array in ciascuna delle due entità coinvolte. Se la relazione è simmetrica, è necessario memorizzare solo un lato della relazione e l'altro lato può essere derivato.

From af0cf2f719f64a76bbacc12dc092d12bf15ed347 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:38 -0500
Subject: [PATCH 3660/3820] New translations ql-schema.mdx (Japanese)

---
 .../ja/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/ja/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ja/subgraphs/developing/creating/ql-schema.mdx
index 46cd45e7dc01..0df29684fe76 100644
--- a/website/pages/ja/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/ja/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### 多対多のリレーションシップ
 
 ユーザーがそれぞれ任意の数の組織に所属しているような多対多の関係の場合、関係をモデル化する最も簡単な方法は、関係する 2 つのエンティティのそれぞれに配列として格納することですが、一般的には最もパフォーマンスの高い方法ではありません。対称的な関係であれば、関係の片側のみを保存する必要があり、もう片側は派生させることができます。

From b942e58e1befede04f4e2bd36eac7e4d302c7b3e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:40 -0500
Subject: [PATCH 3661/3820] New translations ql-schema.mdx (Korean)

---
 .../ko/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/ko/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ko/subgraphs/developing/creating/ql-schema.mdx
index 8e5789d66650..4ecef1f613b3 100644
--- a/website/pages/ko/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/ko/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Many-To-Many Relationships
 
 For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.

From 5c37b7ea71603fcca10ead389bb1afef1f292527 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:41 -0500
Subject: [PATCH 3662/3820] New translations ql-schema.mdx (Dutch)

---
 .../nl/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/nl/subgraphs/developing/creating/ql-schema.mdx b/website/pages/nl/subgraphs/developing/creating/ql-schema.mdx
index 8e5789d66650..4ecef1f613b3 100644
--- a/website/pages/nl/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/nl/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Many-To-Many Relationships
 
 For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.

From 512f7f44c51849f838acd0f00ad74f8805109aba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:42 -0500
Subject: [PATCH 3663/3820] New translations ql-schema.mdx (Polish)

---
 .../pl/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/pl/subgraphs/developing/creating/ql-schema.mdx b/website/pages/pl/subgraphs/developing/creating/ql-schema.mdx
index 8e5789d66650..4ecef1f613b3 100644
--- a/website/pages/pl/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/pl/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Many-To-Many Relationships
 
 For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.

From 8c5e2974ea914b84e3afe868348652cb91b91d01 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:43 -0500
Subject: [PATCH 3664/3820] New translations ql-schema.mdx (Russian)

---
 .../ru/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/ru/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ru/subgraphs/developing/creating/ql-schema.mdx
index d5f5ceaf86c8..fbf13c8c1415 100644
--- a/website/pages/ru/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/ru/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Связи "Многие ко многим"
 
 Для связей "многие ко многим", таких, например, как пользователи, каждый из которых может принадлежать к любому числу организаций, наиболее простым, но, как правило, не самым производительным способом моделирования связей является создание массива в каждом из двух задействованных объектов. Если связь симметрична, то необходимо сохранить только одну сторону связи, а другая сторона может быть выведена.

From 48bb2b87647234b511b70499ff824e01328e5470 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:45 -0500
Subject: [PATCH 3665/3820] New translations ql-schema.mdx (Swedish)

---
 .../sv/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/sv/subgraphs/developing/creating/ql-schema.mdx b/website/pages/sv/subgraphs/developing/creating/ql-schema.mdx
index 9d615c96a165..0a4b2f7a4193 100644
--- a/website/pages/sv/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/sv/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Många-till-många-relationer
 
 För många-till-många-relationer, som till exempel användare som var och en kan tillhöra ett antal organisationer, är det mest raka, men generellt sett inte den mest prestanda-optimerade, sättet att modellera relationen som en array i vardera av de två entiteter som är involverade. Om relationen är symmetrisk behöver bara ena sidan av relationen lagras och den andra sidan kan härledas.

From ac32b6277320486cb6388698bbc8a4594790b4a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:46 -0500
Subject: [PATCH 3666/3820] New translations ql-schema.mdx (Turkish)

---
 .../tr/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/tr/subgraphs/developing/creating/ql-schema.mdx b/website/pages/tr/subgraphs/developing/creating/ql-schema.mdx
index ce1cc82dfc1c..97d3b85af90f 100644
--- a/website/pages/tr/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/tr/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Çoktan Çoğa İlişkiler
 
 Kullanıcıların her birinin birden çok kuruluşa mensup olabileceği gibi çoktan çoğa ilişkilerde, ilişkiyi modellemenin en basit fakat pek verimli olmayan yolu, ilişkide yer alan iki varlıkta da bir dizi olarak saklamaktır. İlişki simetrik ise, ilişkinin yalnızca bir tarafının saklanması gerekir ve diğer taraf türetilebilir.

From 57ad4166106b7008b177678555775578638e4942 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:47 -0500
Subject: [PATCH 3667/3820] New translations ql-schema.mdx (Ukrainian)

---
 .../uk/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/uk/subgraphs/developing/creating/ql-schema.mdx b/website/pages/uk/subgraphs/developing/creating/ql-schema.mdx
index 8e5789d66650..4ecef1f613b3 100644
--- a/website/pages/uk/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/uk/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Many-To-Many Relationships
 
 For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.

From c36e2531b563b0d8d605711bf51036da0ed3af0d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:48 -0500
Subject: [PATCH 3668/3820] New translations ql-schema.mdx (Chinese Simplified)

---
 .../zh/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/zh/subgraphs/developing/creating/ql-schema.mdx b/website/pages/zh/subgraphs/developing/creating/ql-schema.mdx
index 0fa078ea48e8..e72f7995eb42 100644
--- a/website/pages/zh/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/zh/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### 多对多关系
 
 对于多对多关系，例如每个可能属于任意数量的组织的用户，对关系建模的最直接，但通常不是最高效的方法，是在所涉及的两个实体中的每一个中定义数组。 如果关系是对称的，则只需要存储关系的一侧联系，就可以导出另一侧。

From fc5cd8d83bac4bc755ab671e087dac4a0f9fd045 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:49 -0500
Subject: [PATCH 3669/3820] New translations ql-schema.mdx (Urdu (Pakistan))

---
 .../ur/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/ur/subgraphs/developing/creating/ql-schema.mdx b/website/pages/ur/subgraphs/developing/creating/ql-schema.mdx
index 96ac1cf2f2ce..7a5155c51cba 100644
--- a/website/pages/ur/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/ur/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### ون-ٹو-مینی تعلقات
 
 مینی-ٹو-مینی تعلقات کے لیے، جیسے کہ صارفین جن میں سے ہر ایک کا تعلق کسی بھی تعداد میں تنظیموں سے ہو سکتا ہے، سب سے سیدھا، لیکن عام طور پر سب سے زیادہ پرفارمنس نہیں، تعلق کو ماڈل کرنے کا طریقہ شامل دونوں ہستیوں میں سے ہر ایک میں ایک ایرے کے طور پر ہے۔ اگر تعلق ہم آہنگ ہے تو، رشتے کے صرف ایک رخ کو ذخیرہ کرنے کی ضرورت ہے اور دوسری طرف اخذ کیا جا سکتا ہے.

From fc69a8cd8bcfea318a0f94d333cd395be91428ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:50 -0500
Subject: [PATCH 3670/3820] New translations ql-schema.mdx (Vietnamese)

---
 .../vi/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/vi/subgraphs/developing/creating/ql-schema.mdx b/website/pages/vi/subgraphs/developing/creating/ql-schema.mdx
index 35b49bcb5f4f..094667a8a1c4 100644
--- a/website/pages/vi/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/vi/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Mối quan hệ nhiều-nhiều
 
 For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.

From ee5d06e28fb2c24d2a4d2a18474e737d760cde8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:51 -0500
Subject: [PATCH 3671/3820] New translations ql-schema.mdx (Marathi)

---
 .../mr/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/mr/subgraphs/developing/creating/ql-schema.mdx b/website/pages/mr/subgraphs/developing/creating/ql-schema.mdx
index 9439044d14b6..c150fd46a8b7 100644
--- a/website/pages/mr/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/mr/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### अनेक-ते-अनेक संबंध
 
 अनेक-ते-अनेक नातेसंबंधांसाठी, जसे की वापरकर्ते जे कोणत्याही संस्थेशी संबंधित असू शकतात, सर्वात सरळ, परंतु सामान्यतः सर्वात कार्यक्षम नसतात, संबंध मॉडेल करण्याचा मार्ग समाविष्ट असलेल्या दोन घटकांपैकी प्रत्येकामध्ये एक अॅरे आहे. नातेसंबंध सममितीय असल्यास, नातेसंबंधाची फक्त एक बाजू संग्रहित करणे आवश्यक आहे आणि दुसरी बाजू मिळवता येते.

From 497c6cb4896e114a3cbea33b03fa6fa7668d6769 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:53 -0500
Subject: [PATCH 3672/3820] New translations ql-schema.mdx (Hindi)

---
 .../hi/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/hi/subgraphs/developing/creating/ql-schema.mdx b/website/pages/hi/subgraphs/developing/creating/ql-schema.mdx
index 86b348a2d8b9..e32b10927b2f 100644
--- a/website/pages/hi/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/hi/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### अनेक-से-अनेक संबंध
 
 मैनी-टू-मैनी संबंधों के लिए, जैसे कि प्रत्येक उपयोगकर्ता किसी भी संख्या में संगठनों से संबंधित हो सकता है, सबसे सरल, लेकिन आम तौर पर सबसे अधिक प्रदर्शनकारी नहीं, संबंध को मॉडल करने का तरीका शामिल दो संस्थाओं में से प्रत्येक में एक सरणी के रूप में है। यदि संबंध सममित है, तो संबंध के केवल एक पक्ष को संग्रहित करने की आवश्यकता है और दूसरे पक्ष को व्युत्पन्न किया जा सकता है।

From 7225022bf4f4e9c67feb37dc446aec89ce4809b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 13:40:54 -0500
Subject: [PATCH 3673/3820] New translations ql-schema.mdx (Swahili)

---
 .../sw/subgraphs/developing/creating/ql-schema.mdx   | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/website/pages/sw/subgraphs/developing/creating/ql-schema.mdx b/website/pages/sw/subgraphs/developing/creating/ql-schema.mdx
index 8e5789d66650..4ecef1f613b3 100644
--- a/website/pages/sw/subgraphs/developing/creating/ql-schema.mdx
+++ b/website/pages/sw/subgraphs/developing/creating/ql-schema.mdx
@@ -160,6 +160,18 @@ type TokenBalance @entity {
 }
 ```
 
+Here is an example of how to write a mapping for a subgraph with reverse lookups:
+
+```typescript
+let token = new Token(event.address) // Create Token
+token.save() // tokenBalances is derived automatically
+
+let tokenBalance = new TokenBalance(event.address)
+tokenBalance.amount = BigInt.fromI32(0)
+tokenBalance.token = token.id // Reference stored here
+tokenBalance.save()
+```
+
 #### Many-To-Many Relationships
 
 For many-to-many relationships, such as users that each may belong to any number of organizations, the most straightforward, but generally not the most performant, way to model the relationship is as an array in each of the two entities involved. If the relationship is symmetric, only one side of the relationship needs to be stored and the other side can be derived.

From c1c545a6729d414a6b6cd08daafe1fe29eb30fdf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 16:15:51 -0500
Subject: [PATCH 3674/3820] New translations grafting-hotfix.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/grafting-hotfix.mdx | 74 +++++++++----------
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
index 35e008f80061..2f901936ae0b 100644
--- a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
@@ -1,5 +1,5 @@
 ---
-title: Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
+title: Subgraph Örnek Uygulama 6 - Acil Güncelleme Dağıtımı için Aşılama Kullanın
 ---
 
 ## Özet
@@ -10,7 +10,7 @@ Aşılama, mevcut endekslenmiş verileri yeniden kullanarak yeni subgraph'ler ol
 
 Bu özellik, kritik sorunlar için hızlı bir şekilde düzeltmelerin dağıtılmasını sağlar ve tüm subgraph'i baştan endeksleme ihtiyacını ortadan kaldırır. Aşılama, tarihsel verileri koruyarak kesinti sürelerini en aza indirir ve veri hizmetlerinde süreklilik sağlar.
 
-## Benefits of Grafting for Hotfixes
+## Acil Güncellemelerde Aşılamanın Avantajları
 
 1. **Hızlı Dağıtım**
 
@@ -19,44 +19,44 @@ Bu özellik, kritik sorunlar için hızlı bir şekilde düzeltmelerin dağıtı
 
 2. **Veri Koruma**
 
-   - **Reuse Historical Data**: Grafting copies the existing data from the base subgraph, so you don’t lose valuable historical records.
+   - **Tarihsel Verileri Yeniden Kullan**: Aşılama, temel subgraph'ten mevcut verileri kopyalar, böylece değerli tarihsel kayıtları kaybetmezsiniz.
    - **Tutarlılık**: Tutarlı tarihsel verilere bağımlı uygulamalar için veri sürekliliğini sağlar.
 
 3. **Verimlilik**
    - **Zaman ve Kaynak Tasarrufu**: Büyük veri kümelerinin yeniden endekslenmesinden kaynaklı hesaplama yükünü önler.
    - **Hatalara Odaklanma**: Geliştiricilerin veri kurtarma yönetimi yerine sorunları çözmeye odaklanmalarını sağlar.
 
-## Best Practices When Using Grafting for Hotfixes
+## Acil Güncellemeler için Aşılama Kullanmak - Örnek Uygulamalar
 
-1. **Initial Deployment Without Grafting**
+1. **Aşılama Olmadan Başlangıç Dağıtımı**
 
-   - **Start Clean**: Always deploy your initial subgraph without grafting to ensure that it’s stable and functions as expected.
-   - **Test Thoroughly**: Validate the subgraph’s performance to minimize the need for future hotfixes.
+   - **Sıfırdan Başlamak**: Subgraph'inizin ilk halini her zaman aşılama olmadan dağıtarak, stabil ve beklendiği gibi çalışmasını sağlayın.
+   - **Detaylı Test**: Gelecekte acil güncelleme yapmayı en aza indirmek için subgraph'in performansını doğrulayın.
 
-2. **Implementing the Hotfix with Grafting**
+2. **Aşılama ile Acil Güncelleme Yapmak**
 
-   - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
-   - **Create a New Subgraph**: Develop a new subgraph that includes the hotfix.
-   - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed subgraph.
-   - **Deploy Quickly**: Publish the grafted subgraph to restore service as soon as possible.
+   - **Sorunu Belirleme**: Kritik bir hata oluştuğunda, son başarılı endekslenmiş olayın blok numarasını belirleyin.
+   - **Yeni Bir Subgraph Oluşturma**: Acil güncellemeyi içeren yeni bir subgraph geliştirin.
+   - **Aşılamayı Yapılandırma**: Dağıtılamamış subgraph'ten belirlenen blok numarasına kadar olan verileri kopyalamak için aşılama kullanın.
+   - **Hızlı Dağıtım**: Hizmeti en kısa sürede yeniden başlatmak için aşılanmış subgraph'i ağda yayımlayın.
 
-3. **Post-Hotfix Actions**
+3. **Acil Güncelleme Sonrasındaki Aksiyonlar**
 
-   - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
-   - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
-     > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
-   - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
+   - **Performansı Takip Etme**: Aşılanmış subgraph'in doğru şekilde endekslendiğinden ve acil güncellemenin sorunu çözdüğünden emin olun.
+   - **Aşılamadan Yeniden Yayımlama**: Stabil olduktan sonra, uzun vadede sürdürülebilirlik için, yeni bir subgraph versiyonunu aşılamadan dağıtın.
+     > Not: Aşılamaya süresiz olarak güvenmek önerilmez. Bu durum gelecekteki güncellemeleri ve bakımı karmaşık hale getirebilir.
+   - **Referansları Güncelleyin**: Bütün hizmetleri ve uygulamaları yeni, aşılanmamış subgraph'i kullanacak şekilde yönlendirin.
 
 4. **Önemli Hususlar**
-   - **Careful Block Selection**: Choose the graft block number carefully to prevent data loss.
+   - **Bloku Dikkatli Seçimek**: Veri kaybını önlemek için aşılama blok numarasını dikkatli seçin.
    - **İpucu**: Doğru işlenmiş son olayın blok numarasını kullanın.
    - **Dağıtım ID'sini Kullanın**: Subgraph ID'si yerine temel subgraph'in Dağıtım ID'sine referans verdiğinizden emin olun.
-   - **Note**: The Deployment ID is the unique identifier for a specific subgraph deployment.
-   - **Feature Declaration**: Remember to declare grafting in the subgraph manifest under features.
+   - **Not**: Dağıtım Kimliği, belirli bir subgraph dağıtımı için benzersiz bir tanımlayıcıdır.
+   - **Özellik Deklarasyonu**: Subgraph manifestosunda özellikler altında aşılamayı deklare etmeyi unutmayın.
 
-## Example: Deploying a Hotfix with Grafting
+## Örnek: Aşılama ile Bir Acil Güncelleme Dağıtmak
 
-Suppose you have a subgraph tracking a smart contract that has stopped indexing due to a critical error. Here’s how you can use grafting to deploy a hotfix.
+Bir akıllı sözleşmeyi takip eden ve kritik bir hata nedeniyle endekslemeyi durdurmuş bir subgraph'e sahip olduğunuzu varsayalım. Bu durumda acil güncelleme dağıtmak için aşılamayı nasıl kullanabileceğiniz aşağıda açıklanmıştır.
 
 1. **Failed Subgraph Manifest (subgraph.yaml)**
 
@@ -99,7 +99,7 @@ Suppose you have a subgraph tracking a smart contract that has stopped indexing
        source:
          address: '0xNewContractAddress'
          abi: Lock
-         startBlock: 6000001 # Block after the last indexed block
+         startBlock: 6000001 # # Son endekslenmiş bloktan sonraki blok
        mapping:
          kind: ethereum/events
          apiVersion: 0.0.7
@@ -116,27 +116,27 @@ Suppose you have a subgraph tracking a smart contract that has stopped indexing
    features:
      - grafting
    graft:
-     base: QmBaseDeploymentID # Deployment ID of the failed subgraph
-     block: 6000000 # Last successfully indexed block
+     base: QmBaseDeploymentID # Başarısız subgraph'in Dağıtım Kimliği
+     block: 6000000 # Başarıyla endekslenmiş son blok
    ```
 
-**Explanation:**
+**Açıklama:**
 
-- **Data Source Update**: The new subgraph points to 0xNewContractAddress, which may be a fixed version of the smart contract.
-- **Start Block**: Set to one block after the last successfully indexed block to avoid reprocessing the error.
-- **Grafting Configuration**:
-  - **base**: Deployment ID of the failed subgraph.
-  - **block**: Block number where grafting should begin.
+- **Veri Kaynağı Güncellemesi**: Yeni subgraph, akıllı sözleşmenin düzeltilmiş bir versiyonu olabilecek 0xNewContractAddress adresine işaret etmektedir.
+- **Başlangıç Bloğu**: Hatanın tekrar işlenmesini önlemek için başarıyla endekslenmiş son bloktan bir blok sonraya ayarlayın.
+- **Aşılama Yapılandırması**:
+  - **base**: Başarısız olan subgraph'in Dağıtım Kimliği.
+  - **block**: Aşılama işleminin başlaması gereken blok numarası.
 
-3. **Deployment Steps**
+3. **Dağıtım Adımları**
 
    - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
-   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
-   - **Deploy the Subgraph**:
-     - Authenticate with the Graph CLI.
-     - Deploy the new subgraph using `graph deploy`.
+   - **Manifestoyu Ayarlayın**: Yukarıda gösterildiği gibi, `subgraph.yaml` dosyasını aşılama yapılandırmalarıyla güncelleyin.
+   - **Subgraph'i Dağıtın**:
+     - Graph CLI ile kimlik doğrulaması yapın.
+     - `graph deploy` komutunu kullanarak yeni subgraph'i dağıtın.
 
-4. **Post-Deployment**
+4. **Dağıtım Sonrası**
    - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
    - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
    - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.

From ed6449372954d4659780c4fab12e02fcf307487e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 18:14:13 -0500
Subject: [PATCH 3675/3820] New translations grafting-hotfix.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/grafting-hotfix.mdx | 26 +++++++++----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
index 2f901936ae0b..f2beff0c3197 100644
--- a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
@@ -138,38 +138,38 @@ Bir akıllı sözleşmeyi takip eden ve kritik bir hata nedeniyle endekslemeyi d
 
 4. **Dağıtım Sonrası**
    - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
-   - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
-   - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
+   - **Veriyi Takip Etme**: Yeni verilerin yakalandığından ve acil güncellemenin etkili olduğundan emin olun.
+   - **Yeniden Yayımlama İçin Planlama**: Uzun süreli istikrar için aşılama yapılmamış sürümün dağıtımını planlayın.
 
-## Warnings and Cautions
+## Uyarılar ve Dikkat Edilmesi Gerekenler
 
-While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
+Aşılama, acil güncellemeleri hızlı bir şekilde dağıtmayı sağlayan güçlü bir araçtır. Fakat veri bütünlüğünü korumak ve ideal performansı sağlamak için aşılanma kullanımından kaçınılması gereken belirli durumlar vardır.
 
-- **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
-- **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
-- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+- **Uyumsuz Şema Değişiklikleri**: Acil güncelleme mevcut alanların türünü değiştirmeyi veya şemanızdan alanları kaldırmayı gerektiriyorsa, bu durumda aşılama uygun değildir. Aşılama, yeni subgraph'in şemasının temel subgraph'in şemasıyla uyumlu olmasını bekler. Uyumsuz değişiklikler, mevcut verilerin yeni şemayla uyumlu olmaması nedeniyle veri tutarsızlıklarına ve hatalara neden olabilir.
+- **Önemli Eşlem Mantığı Revizyonları**: Acil güncelleme olayların işlenme şeklinin değiştirilmesi veya işleyici fonksiyonlarının değiştirilmesi gibi eşlem mantığınızda önemli değişiklikleri içeriyorsa, aşılama doğru çalışmayabilir. Buradaki yeni mantık, eski mantık altında işlenmiş verilerle uyumlu olmayabilir. Bu da hatalı verilere veya başarısız endekslemelere yol açabilir.
+- **The Graph Ağına Dağıtımlar**: Aşılama, The Graph'in merkeziyetsiz ağı (ana ağ) için tasarlanmış subgraph'ler için önerilmez. Aşılama endekslemeyi karmaşıklaştırabilir ve tüm endeksleyiciler tarafından tamamen desteklenmeyebilir. Bu yüzden beklenmedik davranışlara veya artan maliyetlere neden olabilir. Ana ağ dağıtımları için, tam uyumluluk ve güvenilirliği sağlamak amacıyla subgraph'i en baştan, tekrar endekslemek daha güvenlidir.
 
 ### Risk Yönetimi
 
 - **Veri Bütünlüğü**: Yanlış blok numaraları veri kaybına veya yinelenmelere yol açabilir.
-- **Testing**: Always test grafting in a development environment before deploying to production.
+- **Test Etme**: Aşılamayı daima önce geliştirme ortamında test ettikten sonra üretime dağıtın.
 
 ## Sonuç
 
-Grafting is an effective strategy for deploying hotfixes in subgraph development, enabling you to:
+Aşılama, subgraph geliştirme sürecinde acil düzeltmeleri dağıtmak için etkili bir stratejidir. Bu strateji, aşağıdakileri yapmanızı sağlar:
 
 - Yeniden endeksleme yapmadan kritik hatalardan **Hızla Kurtulun**.
 - Uygulamalar ve kullanıcılar için sürekliliği koruyarak **Tarihsel Verileri Koruyun**.
 - Kritik düzeltmeler sırasında kesinti sürelerini en aza indirerek **Hizmet Erişilebilirliğini Sağlayın**.
 
-However, it’s important to use grafting judiciously and follow best practices to mitigate risks. After stabilizing your subgraph with the hotfix, plan to deploy a non-grafted version to ensure long-term maintainability.
+Ancak, aşılamayı tedbirli bir şekilde kullanmak ve riskleri azaltmak için örnek uygulamaları takip etmek önemlidir. Subgraph'inizi acil düzeltmeyle stabilize ettikten sonra, uzun vadede çalışmasını sağlamak için aşılama kullanılmayan bir sürüm dağıtmayı planlayın.
 
 ## Ek Kaynaklar
 
-- **[Grafting Documentation](/subgraphs/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
-- **[Understanding Deployment IDs](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
+- **[Aşılama Dokümantasyonu](/subgraphs/cookbook/grafting/)**: Aşılama ile Bir Sözleşmeyi Değiştirin ve Geçmişini Koruyun
+- **[Dağıtım Kimliklerini Anlamak](/subgraphs/querying/subgraph-id-vs-deployment-id/)**: Dağıtım Kimliği ile Subgraph Kimliği arasındaki farkı öğrenin.
 
-By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
+Subgraph geliştirme iş akışınıza aşılamayı dahil ederek, sorunlara hızla yanıt verme yeteneğinizi artırabilir ve veri hizmetlerinizin sağlam ve güvenilir kalmasını sağlayabilirsiniz.
 
 ## Subgraph Örnek Uygulamalar 1-6
 

From 908e95ccb148b2f53eefa8fe5ed8eae35ced54f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 18:14:14 -0500
Subject: [PATCH 3676/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Turkish)

---
 .../immutable-entities-bytes-as-ids.mdx       | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
index d991e70bf956..e29f417a9a6d 100644
--- a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -4,11 +4,11 @@ title: Subgraph Örnek Uygulama 3 - Değişmez Varlıklar ve Byte'ları Kimlik O
 
 ## Özet
 
-Using Immutable Entities and Bytes for IDs in our `schema.graphql` file [significantly improves ](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) indexing speed and query performance.
+`schema.graphql` dosyamızda Kimlikler için Değişmez Varlıklar ve Byte'lar kullanmak endeksleme hızını ve sorgu performansını [önemli ölçüde](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/) arttırır.
 
 ## Değişmez Varlıklar
 
-To make an entity immutable, we simply add `(immutable: true)` to an entity.
+Bir varlığı değişmez hale getirmek için, varlığa `(immutable: true)` ekleriz.
 
 ```graphql
 type Transfer @entity(immutable: true) {
@@ -19,21 +19,21 @@ type Transfer @entity(immutable: true) {
 }
 ```
 
-By making the `Transfer` entity immutable, graph-node is able to process the entity more efficiently, improving indexing speeds and query responsiveness.
+`Transfer` varlığını değişmez hale getirerek, graph-node'un varlığı daha verimli bir şekilde işlemesini sağlayabiliriz. Bu da endeksleme hızını ve sorgu yanıt verebilirliğini artırır.
 
-Immutable Entities structures will not change in the future. An ideal entity to become an Immutable Entity would be an entity that is directly logging onchain event data, such as a `Transfer` event being logged as a `Transfer` entity.
+Değişmez Varlıkların yapıları gelecekte değişmeyecektir. "Değişmez Varlık" haline getirilecek ideal bir varlık, doğrudan zincir üstü olay verilerini kaydeden bir varlık, (örneğin bir `Transfer` olayının `Transfer` varlığı olarak kaydedilmesi) gibi olabilir.
 
-### Under the hood
+### Detaylı İnceleme
 
-Mutable entities have a 'block range' indicating their validity. Updating these entities requires the graph node to adjust the block range of previous versions, increasing database workload. Queries also need filtering to find only live entities. Immutable entities are faster because they are all live and since they won't change, no checks or updates are required while writing, and no filtering is required during queries.
+Değişebilir varlıkların geçerliliklerini belirten bir 'blok aralığı' bulunur. Bu varlıkları güncellemek, Graph Düğümü'nün önceki versiyonların blok aralığını ayarlamasını gerektirir. Bu da veritabanı iş yükünü artırır. Sorguların da yalnızca canlı ögeleri bulmak için filtrelenmesi gerekir. Değişmez ögeler daha hızlıdır. Çünkü hepsi canlıdır ve değişmeyeceklerinden dolayı, yazma sırasında herhangi bir kontrol veya güncellemeye gerek yoktur. Ayrıca, sorgular sırasında herhangi bir filtrelemeye de gerek kalmaz.
 
-### When not to use Immutable Entities
+### Değişmez Varlıklar ne zaman kullanmamalı
 
-If you have a field like `status` that needs to be modified over time, then you should not make the entity immutable. Otherwise, you should use immutable entities whenever possible.
+Eğer zamanla değiştirilmesi gereken `status` gibi bir alanınız varsa, varlığı değişmez yapmamalısınız. Bunun dışında mümkünse değişmez varlıklar kullanmalısınız.
 
-## Bytes as IDs
+## ID (Kimlik Numarası) Olarak Bytes
 
-Every entity requires an ID. In the previous example, we can see that the ID is already of the Bytes type.
+Her varlığın bir ID'si olmalıdır. Önceki örnekte, ID'nin zaten Bytes türünde olduğunu görebiliriz.
 
 ```graphql
 type Transfer @entity(immutable: true) {

From 66ffa6f76e82ed91aba4663371bc82bb3fe3adae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 18:14:15 -0500
Subject: [PATCH 3677/3820] New translations pruning.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/pruning.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/pruning.mdx b/website/pages/tr/subgraphs/cookbook/pruning.mdx
index 0c3f587adb33..fead925fd28c 100644
--- a/website/pages/tr/subgraphs/cookbook/pruning.mdx
+++ b/website/pages/tr/subgraphs/cookbook/pruning.mdx
@@ -30,7 +30,7 @@ dataSources:
     network: mainnet
 ```
 
-## Important Considerations
+## Önemli Hususlar
 
 - If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
 

From 2812af84738ec21b340628b67dbd2e79472b9ee3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 18:14:17 -0500
Subject: [PATCH 3678/3820] New translations timeseries.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/timeseries.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/timeseries.mdx b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
index 0496637dd169..2f01ff2d896e 100644
--- a/website/pages/tr/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
@@ -27,7 +27,7 @@ Timeseries and aggregations reduce data processing overhead and accelerate queri
 - Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
 - Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
 
-### Important Considerations
+### Önemli Hususlar
 
 - Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
 - Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.

From 27f3e00c1c49920d2da36383f9dbef2cd1124152 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 18:14:18 -0500
Subject: [PATCH 3679/3820] New translations grafting.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/grafting.mdx  | 52 +++++++++----------
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/grafting.mdx b/website/pages/tr/subgraphs/cookbook/grafting.mdx
index 910787eb371e..8afe1f25c68f 100644
--- a/website/pages/tr/subgraphs/cookbook/grafting.mdx
+++ b/website/pages/tr/subgraphs/cookbook/grafting.mdx
@@ -20,37 +20,37 @@ Graftlanan subgraph, temel subgraphla tamamen aynı olmayan, ancak onunla uyumlu
 
 Daha fazla bilgi için kontrol edebilirsiniz:
 
-- [Grafting](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
+- [Aşılama](/developing/creating-a-subgraph/#grafting-onto-existing-subgraphs)
 
-In this tutorial, we will be covering a basic use case. We will replace an existing contract with an identical contract (with a new address, but the same code). Then, graft the existing subgraph onto the "base" subgraph that tracks the new contract.
+Bu eğitimde, temel bir kullanım senaryosunu ele alacağız. Mevcut bir sözleşmeyi özdeş bir sözleşme (aynı koda sahip ancak adresi farklı bir sözleşme) ile değiştireceğiz. Ardından, mevcut subgraph'i yeni sözleşmeyi izleyen "temel" subgraph'e aşılayacağız.
 
 ## Ağa Yükseltme Durumunda Graftlamaya İlişkin Önemli Not
 
-> **Caution**: It is recommended to not use grafting for subgraphs published to The Graph Network
+> **Dikkat**: Aşılamanın The Graph Ağına yayımlanan subgraph'ler için kullanılmaması önerilir
 
 ### Bu Neden Önemli?
 
-Grafting is a powerful feature that allows you to "graft" one subgraph onto another, effectively transferring historical data from the existing subgraph to a new version. It is not possible to graft a subgraph from The Graph Network back to Subgraph Studio.
+Aşılama, bir subgraph'i diğerine "aşılayarak" mevcut subgraph'ten yeni bir versiyona tarihi verileri etkin bir şekilde aktarmanıza olanak tanıyan güçlü bir özelliktir. Bir subgraph'i The Graph Ağından Subgraph Studio'ya geri aşılamak mümkün değildir.
 
 ### En İyi Uygulamalar
 
-**Initial Migration**: when you first deploy your subgraph to the decentralized network, do so without grafting. Ensure that the subgraph is stable and functioning as expected.
+**İlk Geçiş**: Subgraph'inizi ilk kez merkeziyetsiz ağa dağıttığınızda aşılama yapmayın. Subgraph'in stabil ve beklendiği gibi çalıştığından emin olun.
 
-**Subsequent Updates**: once your subgraph is live and stable on the decentralized network, you may use grafting for future versions to make the transition smoother and to preserve historical data.
+**Sonraki Güncellemeler**: Subgraph'iniz merkeziyetsiz ağda canlı ve stabil olduğunda, gelecekteki versiyonlar için aşılama kullanarak geçişi daha sorunsuz hale getirebilir ve tarihi verileri koruyabilirsiniz.
 
 Bu yönergelere uyarak riskleri en aza indirebilir ve daha sorunsuz bir taşıma süreci geçirebilirsiniz.
 
 ## Mevcut Bir Subgraph'ı Oluşturma
 
-Building subgraphs is an essential part of The Graph, described more in depth [here](/subgraphs/quick-start/). To be able to build and deploy the existing subgraph used in this tutorial, the following repo is provided:
+Subgraph oluşturmak, The Graph'in önemli bir parçasıdır. Bu konu daha detaylı olarak [burada](/subgraphs/quick-start/) açıklanmıştır. Bu eğitimde kullanılan mevcut subgraph'i inşa etmek ve dağıtmak için aşağıdaki depo sağlanmıştır:
 
 - [Subgraph örnek deposu](https://github.com/Shiyasmohd/grafting-tutorial)
 
-> Note: The contract used in the subgraph was taken from the following [Hackathon Starterkit](https://github.com/schmidsi/hackathon-starterkit).
+> Not: Subgraph'te kullanılan sözleşme, [Hackathon Başlangıç Kiti](https://github.com/schmidsi/hackathon-starterkit)'nden alınmıştır.
 
 ## Subgraph Manifest Tanımı
 
-The subgraph manifest `subgraph.yaml` identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest that you will use:
+Subgraph manifestosu `subgraph.yaml`, subgraph için veri kaynaklarını, ilgili tetikleyicileri ve bu tetikleyicilere yanıt olarak çalıştırılması gereken fonksiyonları tanımlar. Kullanacağınız bir subgraph manifestosu örneği aşağıda verilmiştir:
 
 ```yaml
 specVersion: 0.0.4
@@ -79,9 +79,9 @@ dataSources:
       file: ./src/lock.ts
 ```
 
-- The `Lock` data source is the abi and contract address we will get when we compile and deploy the contract
-- The network should correspond to an indexed network being queried. Since we're running on Sepolia testnet, the network is `sepolia`
-- The `mapping` section defines the triggers of interest and the functions that should be run in response to those triggers. In this case, we are listening for the `Withdrawal` event and calling the `handleWithdrawal` function when it is emitted.
+- `Lock` veri kaynağı, sözleşmeyi derleyip dağıttığımızda elde edeceğimiz "abi" ve sözleşme adresidir
+- Ağ, sorgulanan endekslenmiş bir ağa karşılık gelmelidir. Sepolia testnet üzerinde çalıştığımız için, ağ `sepolia`'dır
+- `mapping` bölümü, ilgili tetikleyicileri ve bu tetikleyicilere yanıt olarak çalıştırılması gereken fonksiyonları tanımlar. Bu durumda, `Withdrawal` olayını dinliyoruz ve yayarken `handleWithdrawal` fonksiyonunu çağırıyoruz.
 
 ## Graftlama Manifest Tanımı
 
@@ -90,21 +90,21 @@ Graftlama, orijinal subgraph bildirimine iki yeni öğe eklemeyi gerektirir:
 ```yaml
 ---
 features:
-  - grafting # feature name
+  - grafting # özellik adı
 graft:
-  base: Qm... # subgraph ID of base subgraph
-  block: 5956000 # block number
+  base: Qm... # Asıl subgraph'in kimlik numarası
+  block: 5956000 # blok numarası
 ```
 
-- `features:` is a list of all used [feature names](/developing/creating-a-subgraph/#experimental-features).
-- `graft:` is a map of the `base` subgraph and the block to graft on to. The `block` is the block number to start indexing from. The Graph will copy the data of the base subgraph up to and including the given block and then continue indexing the new subgraph from that block on.
+- `features:` tüm kullanılan [özellik adlarının](/developing/creating-a-subgraph/#experimental-features) bir listesidir.
+- `graft:` `base` subgraph ve üzerine bağlanılacak bloktan oluşan bir eşlemedir. `block`, endekslemenin başlanacağı blok numarasıdır. The Graph, belirtilen bloka kadar olan temel subgraph'in verisini kopyalayıp bu bloka kadar olan kısmı dahil edecek ve ardından yeni subgraph'i bu bloktan itibaren endekslemeye devam edecek.
 
-The `base` and `block` values can be found by deploying two subgraphs: one for the base indexing and one with grafting
+`base` ve `block` değerleri, iki subgraph dağıtılarak bulunabilir: Biri temel endeksleme için, diğeri ise aşılama için olan subgraph
 
 ## Temel Subgraph'ı Dağıtma
 
-1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-example`
-2. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-example` folder from the repo
+1. [Subgraph Studio](https://thegraph.com/studio/) adresine gidip Sepolia testnet üzerinde `graft-example` adlı bir subgraph oluşturun
+2. Depodan `graft-example` klasöründeki `AUTH & DEPLOY` bölümündeki yönergeleri izleyin
 3. Tamamlandığında, subgraph'ın doğru bir şekilde indekslendiğinden emin olun. Eğer aşağıdaki komutu Graph Test Alanında(Playground) çalıştırırsanız
 
 ```graphql
@@ -144,9 +144,9 @@ Subgraph'ın düzgün bir şekilde indekslendiğini doğruladıktan sonra, subgr
 
 Graft yerine geçen subgraph.yaml yeni bir sözleşme adresine sahip olacaktır. Bu, merkeziyetsiz uygulamanızı güncellediğinizde, bir sözleşmeyi yeniden dağıttığınızda vb. gerçekleşebilir.
 
-1. Go to [Subgraph Studio](https://thegraph.com/studio/) and create a subgraph on Sepolia testnet called `graft-replacement`
+1. [Subgraph Studio](https://thegraph.com/studio/) adresine gidin ve Sepolia testnet üzerinde `graft-replacement` adlı bir subgraph oluşturun
 2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
-3. Follow the directions in the `AUTH & DEPLOY` section on your subgraph page in the `graft-replacement` folder from the repo
+3. `graft-replacement` klasöründeki subgraph sayfanızda, `AUTH & DEPLOY` bölümündeki talimatları izleyin
 4. Tamamlandığında, subgraph'ın doğru bir şekilde indekslendiğinden emin olun. Eğer aşağıdaki komutu Graph Test Alanında(Playground) çalıştırırsanız
 
 ```graphql
@@ -185,18 +185,18 @@ Aşağıdakileri döndürmelidir:
 }
 ```
 
-You can see that the `graft-replacement` subgraph is indexing from older `graph-example` data and newer data from the new contract address. The original contract emitted two `Withdrawal` events, [Event 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) and [Event 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). The new contract emitted one `Withdrawal` after, [Event 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). The two previously indexed transactions (Event 1 and 2) and the new transaction (Event 3) were combined together in the `graft-replacement` subgraph.
+`graft-replacement` subgraph'inin eski `graph-example` verilerini ve yeni sözleşme adresinden gelen yeni verileri endekslediğini görebilirsiniz. Orijinal sözleşme, iki `Withdrawal` olayı yaydı: [Olay 1](https://sepolia.etherscan.io/tx/0xe8323d21c4f104607b10b0fff9fc24b9612b9488795dea8196b2d5f980d3dc1d) ve [Olay 2](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452). Yeni sözleşme, sonrasında bir `Withdrawal` olayı yaydı, [Olay 3](https://sepolia.etherscan.io/tx/0x2410475f76a44754bae66d293d14eac34f98ec03a3689cbbb56a716d20b209af). Önceden endekslenmiş iki işlem (Olay 1 ve 2) ve yeni işlem (Olay 3), `graft-replacement` subgraph'inde birleştirildi.
 
-Congrats! You have successfully grafted a subgraph onto another subgraph.
+Tebrikler! Bir subgraph'i başka bir subgraph'e başarıyla aşıladınız.
 
 ## Ek Kaynaklar
 
-If you want more experience with grafting, here are a few examples for popular contracts:
+Aşılama konusunda daha fazla deneyim kazanmak istiyorsanız, yaygın kullanılan sözleşmeler için aşağıda birkaç örnek bulunmaktadır:
 
 - [Curve](https://github.com/messari/subgraphs/blob/master/subgraphs/curve-finance/protocols/curve-finance/config/templates/curve.template.yaml)
 - [ERC-721](https://github.com/messari/subgraphs/blob/master/subgraphs/erc721-metadata/subgraph.yaml)
 - [Uniswap](https://github.com/messari/subgraphs/blob/master/subgraphs/uniswap-v3-forks/protocols/uniswap-v3/config/templates/uniswapV3Template.yaml),
 
-To become even more of a Graph expert, consider learning about other ways to handle changes in underlying datasources. Alternatives like [Data Source Templates](/developing/creating-a-subgraph/#data-source-templates) can achieve similar results
+Daha da iyi bir Graph uzmanı olmak için, temel veri kaynaklarındaki değişikliklerle başa çıkmanın diğer yollarını öğrenmeyi değerlendirin. [Veri Kaynağı Şablonları](/developing/creating-a-subgraph/#data-source-templates) gibi alternatifler benzer sonuçlar elde edebilir
 
 > Not: Bu makaledeki materyalin büyük bir kısmı, daha önce yayımlanmış olan [Arweave makalesinden](/subgraphs/cookbook/arweave/) alınmıştır

From b87973d8f8ed08366abc4d6d0360f6ac56ef9141 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 18:14:19 -0500
Subject: [PATCH 3680/3820] New translations transfer-to-the-graph.mdx
 (Turkish)

---
 website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
index 7dab066a6fce..21e1c76fac10 100644
--- a/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -12,8 +12,8 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 
 ## Upgrade Your Subgraph to The Graph in 3 Easy Steps
 
-1. [Set Up Your Studio Environment](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
-2. [Deploy Your Subgraph to Studio](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
+1. [Studio Ortamınızı Kurun](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
+2. [Subgraph'inizi Studio'ya Dağıtın](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
 3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
 
 ## 1. Set Up Your Studio Environment

From 1aa5175dc7bde5ed3c69e3dec3937db0c2aba085 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Mon, 10 Feb 2025 19:18:12 -0500
Subject: [PATCH 3681/3820] New translations transfer-to-the-graph.mdx
 (Turkish)

---
 .../tr/subgraphs/cookbook/transfer-to-the-graph.mdx    | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
index 21e1c76fac10..9bcd190fed1e 100644
--- a/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -14,9 +14,9 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 
 1. [Studio Ortamınızı Kurun](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
 2. [Subgraph'inizi Studio'ya Dağıtın](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
-3. [Publish to The Graph Network](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
+3. [The Graph Ağı'nda Yayımlayın](/subgraphs/cookbook/transfer-to-the-graph/#publish-your-subgraph-to-the-graphs-decentralized-network)
 
-## 1. Set Up Your Studio Environment
+## 1. Stüdyo Ortamınızı Ayarlayın
 
 ### Create a Subgraph in Subgraph Studio
 
@@ -76,9 +76,9 @@ You can start [querying](/subgraphs/querying/introduction/) any subgraph by send
 
 #### Örnek
 
-[CryptoPunks Ethereum subgraph](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK) by Messari:
+Messari tarafından hazırlanmış [CryptoPunks Ethereum subgraph'i](https://thegraph.com/explorer/subgraphs/HdVdERFUe8h61vm2fDyycHgxjsde5PbB832NHgJfZNqK):
 
-![Query URL](/img/cryptopunks-screenshot-transfer.png)
+![Sorgu URL'si](/img/cryptopunks-screenshot-transfer.png)
 
 The query URL for this subgraph is:
 
@@ -92,7 +92,7 @@ Now, you simply need to fill in **your own API Key** to start sending GraphQL qu
 
 You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
 
-![API keys](/img/Api-keys-screenshot.png)
+![API anahtarları](/img/Api-keys-screenshot.png)
 
 ### Monitor Subgraph Status
 

From bc3ae7b123ddc60906759661bd08705ee486b616 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 11:13:11 -0500
Subject: [PATCH 3682/3820] New translations near.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/near.mdx | 38 ++++++++++----------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/near.mdx b/website/pages/tr/subgraphs/cookbook/near.mdx
index 05b7d76468b2..493bd0c44739 100644
--- a/website/pages/tr/subgraphs/cookbook/near.mdx
+++ b/website/pages/tr/subgraphs/cookbook/near.mdx
@@ -2,42 +2,42 @@
 title: NEAR Üzerinde Subgraphlar Oluşturma
 ---
 
-This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
+Bu rehber, [NEAR blokzinciri](https://docs.near.org/) üzerindeki akıllı sözleşmeleri endeksleyen subgraph'ler inşa etmeye giriş niteliğindedir.
 
 ## NEAR Nedir?
 
-[NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
+[NEAR](https://near.org/), merkezi olmayan uygulamalar geliştirmek için kullanılan bir akıllı sözleşme platformudur. Daha fazla bilgi için [resmi dokümantasyona](https://docs.near.org/concepts/basics/protocol) bakabilirsiniz.
 
 ## NEAR subgraphları nedir?
 
 The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
 
-Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
+Subgraph'ler olay tabanlıdır., yani zincir üzerindeki olayları dinler ve sonrasında işlerler. Şu anda NEAR subgraph'leri için desteklenen iki tür işleyici bulunmaktadır:
 
 - Blok işleyicileri: Bunlar her yeni blokta çalışır
 - Makbuz işleyicileri: Belirli bir hesapta her mesaj yürütüldüğünde çalışır
 
-[From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
+[NEAR dokümantasyonundan](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
 
 > Makbuz, sistemdeki eyleme geçirilebilir tek nesnedir. NEAR platformunda "bir işlemin işlenmesinden" bahsettiğimizde, bu nihayetinde bir noktada "makbuzların uygulanması" anlamına gelir.
 
 ## NEAR Subgraph'ı Oluşturma
 
-`@graphprotocol/graph-cli` is a command-line tool for building and deploying subgraphs.
+`@graphprotocol/graph-cli`, subgraph'ler oluşturmak ve dağıtmak için kullanılan bir komut satırı aracıdır.
 
-`@graphprotocol/graph-ts` is a library of subgraph-specific types.
+`@graphprotocol/graph-ts`, subgraph'e özgü türlerden oluşan bir kütüphanedir.
 
-NEAR subgraph development requires `graph-cli` above version `0.23.0`, and `graph-ts` above version `0.23.0`.
+NEAR ağında subgraph geliştirmek, `graph-cli`'nin `0.23.0` üstü sürümünü ve `graph-ts`'nin `0.23.0` üstü sürümünü gerektirir.
 
 > Bir NEAR subgraph'ı oluşturmak, Ethereum'u indeksleyen bir subgraph oluşturmakla çok benzerdir.
 
 Subgraph tanımının üç yönü vardır:
 
-**subgraph.yaml:** the subgraph manifest, defining the data sources of interest, and how they should be processed. NEAR is a new `kind` of data source.
+**subgraph.yaml:** subgraph manifestosudur, ilgi duyulan veri kaynaklarını tanımlar ve bunların nasıl işleneceğini açıklar. NEAR, yeni bir `kind` (tür) veri kaynağıdır.
 
-**schema.graphql:** a schema file that defines what data is stored for your subgraph, and how to query it via GraphQL. The requirements for NEAR subgraphs are covered by [the existing documentation](/developing/creating-a-subgraph/#the-graphql-schema).
+**schema.graphql:** subgraph'iniz için hangi verilerin depolanacağını ve bunların GraphQL kullanılarak nasıl sorgulanacağını tanımlayan şema dosyasıdır. NEAR subgraph'leri için gereksinimler [mevcut dokümantasyon](/developing/creating-a-subgraph/#the-graphql-schema) tarafından kapsanmaktadır.
 
-**AssemblyScript Mappings:** [AssemblyScript code](/subgraphs/developing/creating/graph-ts/api/) that translates from the event data to the entities defined in your schema. NEAR support introduces NEAR-specific data types and new JSON parsing functionality.
+**AssemblyScript Eşlemeleri:** Olay verisini, şemanızda tanımlanan varlıklara dönüştüren [AssemblyScript kodudur](/subgraphs/developing/creating/graph-ts/api/). NEAR desteği, NEAR'a özgü veri türleri ve yeni JSON ayrıştırma işlevi sunar.
 
 Subgraph geliştirme sırasında iki anahtar komut vardır:
 
@@ -48,7 +48,7 @@ $ graph build # AssemblyScript dosyalarından Web Assembly oluşturur ve tüm su
 
 ### Subgraph Manifest Tanımı
 
-The subgraph manifest (`subgraph.yaml`) identifies the data sources for the subgraph, the triggers of interest, and the functions that should be run in response to those triggers. See below for an example subgraph manifest for a NEAR subgraph:
+Subgraph manifestosu (`subgraph.yaml`), subgraph için veri kaynaklarını, ilgili tetikleyicileri ve bu tetikleyicilere yanıt olarak çalıştırılması gereken fonksiyonları tanımlar. Aşağıda bir NEAR subgraph'i için örnek bir subgraph manifestosu bulunmaktadır:
 
 ```yaml
 specVersion: 0.0.2
@@ -72,7 +72,7 @@ dataSources:
 
 - NEAR subgraphs introduce a new `kind` of data source (`near`)
 - The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
-- NEAR data sources introduce an optional `source.account` field, which is a human-readable ID corresponding to a [NEAR account](https://docs.near.org/concepts/protocol/account-model). This can be an account or a sub-account.
+- NEAR veri kaynakları, [NEAR hesabı](https://docs.near.org/concepts/protocol/account-model) ile ilişkili, insan tarafından okunabilir bir kimlik olan isteğe bağlı `source.account` alanını sunar. Bu, bir hesap veya alt hesap olabilir.
 - NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
 
 ```yaml
@@ -87,7 +87,7 @@ accounts:
 
 NEAR veri kaynakları iki tür işleyiciyi destekler:
 
-- `blockHandlers`: run on every new NEAR block. No `source.account` is required.
+- `blockHandlers`: her yeni NEAR blokunda çalıştırılır. `source.account` gerekli değildir.
 - `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
 
 ### Şema Tanımı
@@ -98,7 +98,7 @@ NEAR veri kaynakları iki tür işleyiciyi destekler:
 
 Olayları işlemek için kullanılan işleyiciler [AssemblyScript](https://www.assemblyscript.org/) ile yazılmıştır.
 
-NEAR indexing introduces NEAR-specific data types to the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/).
+NEAR endeksleme, [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) için NEAR'a özgü veri türlerini tanıtır.
 
 ```typescript
 
@@ -162,7 +162,7 @@ class ReceiptWithOutcome {
 
 These types are passed to block & receipt handlers:
 
-- Block handlers will receive a `Block`
+- Blok işleyiciler bir `Block` alacaktır
 - Receipt handlers will receive a `ReceiptWithOutcome`
 
 Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
@@ -228,13 +228,13 @@ Yukarıdaki bileşenlerin çalıştırılması hakkında yakında daha fazla bil
 
 ## NEAR Subgraph'ını Sorgulama
 
-The GraphQL endpoint for NEAR subgraphs is determined by the schema definition, with the existing API interface. Please visit the [GraphQL API documentation](/subgraphs/querying/graphql-api/) for more information.
+NEAR subgraph'leri için GraphQL uç noktası, mevcut API arayüzü ile şema tanımına göre belirlenir. Daha fazla bilgi için [GraphQL API dokümantasyonuna](/subgraphs/querying/graphql-api/) bakabilirsiniz.
 
 ## Örnek Subgraph'ler
 
 Aşağıda bazı örnek subgraph'leri bulabilirsiniz:
 
-[NEAR Blocks](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
+[NEAR Blokları](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
 
 [NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
 
@@ -276,8 +276,8 @@ Bekleme fonksiyonelliği henüz NEAR subgraphları için desteklenmemektedir. Bu
 
 ### Sorum yanıtlanmadı, NEAR subgraphları oluşturma konusunda nereden daha fazla yardım alabilirim?
 
-If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
+Eğer subgraph geliştirme ile ilgili genel bir soru ise, [Geliştirici dokümantasyonunun](/subgraphs/quick-start/) geri kalanında çok daha fazla bilgi bulunmaktadır. Eğer burada aradığınızı bulamazsanız lütfen [The Graph Protocol Discord](https://discord.gg/graphprotocol) sunucusuna katılın ve #near kanalında sorunuzu sorun. Veya near@thegraph.com adresine e-posta gönderin.
 
 ## Referanslar
 
-- [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)
+- [NEAR geliştirici dokümantasyonu](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 06c4916a81cdcfe2f989b5efec790f5d7c7de143 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 11:13:12 -0500
Subject: [PATCH 3683/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Turkish)

---
 .../immutable-entities-bytes-as-ids.mdx       | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
index e29f417a9a6d..e33decda9b58 100644
--- a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -56,7 +56,7 @@ While other types for IDs are possible, such as String and Int8, it is recommend
 
 It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
 
-Instead, we should use the `concatI32()` method to concatenate event properties. This strategy results in a `Bytes` ID that is much more performant.
+Bunun yerine, olay özelliklerini birleştirmek için `concatI32()` metodunu kullanmalıyız. Bu strateji, çok daha iyi çalışan bir `Bytes` ID ile sonuçlanır.
 
 ```typescript
 export function handleTransfer(event: TransferEvent): void {
@@ -77,7 +77,7 @@ export function handleTransfer(event: TransferEvent): void {
 
 Sorting using Bytes as IDs is not optimal as seen in this example query and response.
 
-Query:
+Sorgu:
 
 ```graphql
 {
@@ -90,7 +90,7 @@ Query:
 }
 ```
 
-Query response:
+Sorgu yanıtı:
 
 ```json
 {
@@ -119,9 +119,9 @@ Query response:
 }
 ```
 
-The IDs are returned as hex.
+ID'ler onaltılık (hex) olarak döndürülür.
 
-To improve sorting, we should create another field on the entity that is a BigInt.
+Sıralamayı geliştirmek için varlık üzerinde BigInt türünde başka bir alan oluşturmalıyız.
 
 ```graphql
 type Transfer @entity {
@@ -133,9 +133,9 @@ type Transfer @entity {
 }
 ```
 
-This will allow for sorting to be optimized sequentially.
+Bu alanı oluşturmak, sıralamanın ardışık olarak optimize edilmesine olanak tanıyacaktır.
 
-Query:
+Sorgu:
 
 ```graphql
 {
@@ -146,7 +146,7 @@ Query:
 }
 ```
 
-Query Response:
+Sorgu Yanıtı:
 
 ```json
 {
@@ -171,9 +171,9 @@ Query Response:
 
 ## Sonuç
 
-Using both Immutable Entities and Bytes as IDs has been shown to markedly improve subgraph efficiency. Specifically, tests have highlighted up to a 28% increase in query performance and up to a 48% acceleration in indexing speeds.
+Hem Değişmez Varlıklar hem de ID olarak, Bytes kullanmanın subgraph verimliliğini önemli ölçüde artırdığı gösterilmiştir. Özellikle, testlerde sorgu performansında %28'e kadar artış ve endeksleme hızlarında %48'e kadar hızlanma göze çarpmaktadır.
 
-Read more about using Immutable Entities and Bytes as IDs in this blog post by David Lutterkort, a Software Engineer at Edge & Node: [Two Simple Subgraph Performance Improvements](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
+Değişmez Varlıkları ve ID olarak Bytes kullanmak hakkında daha fazla bilgiyi Edge & Node'da Yazılım Mühendisi olan David Lutterkort'un bu blog yazısında bulabilirsiniz: [İki Basit Subgraph Performans İyileştirmesi](https://thegraph.com/blog/two-simple-subgraph-performance-improvements/).
 
 ## Subgraph Örnek Uygulamalar 1-6
 

From 797cd531400ced0b6cc950775c52c56104971d50 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 11:13:14 -0500
Subject: [PATCH 3684/3820] New translations pruning.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/pruning.mdx   | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/pruning.mdx b/website/pages/tr/subgraphs/cookbook/pruning.mdx
index fead925fd28c..c94aac4d9bcd 100644
--- a/website/pages/tr/subgraphs/cookbook/pruning.mdx
+++ b/website/pages/tr/subgraphs/cookbook/pruning.mdx
@@ -1,22 +1,22 @@
 ---
-title: Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
+title: Subgraph Örnek Uygulama 1 - Subgraph Budama ile Sorgu Hızını Artırın
 ---
 
 ## Özet
 
-[Pruning](/developing/creating-a-subgraph/#prune) removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using `indexerHints` is an easy way to prune a subgraph.
+[Budama](/developing/creating-a-subgraph/#prune), bir subgraph'in veritabanından arşivlenmiş varlıkları istenilen bir bloka kadar kaldırır. Bir subgraph'in veritabanından kullanılmayan varlıkların kaldırılması, subgraph'in sorgu performansını genellikle kayda değer ölçüde artırır. `indexerHints` kullanmak, bir subgraph'i budamayı kolaylaştırır.
 
-## How to Prune a Subgraph With `indexerHints`
+## `indexerHints` ile Bir Subgraph'i Nasıl Budayabilirsiniz
 
-Add a section called `indexerHints` in the manifest.
+Manifestoya `indexerHints` adlı bir bölüm ekleyin.
 
-`indexerHints` has three `prune` options:
+`indexerHints` üç `prune` (budama) seçeneğine sahiptir:
 
-- `prune: auto`: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created by `graph-cli` >= 0.66.0.
-- `prune: <Number of blocks to retain>`: Sets a custom limit on the number of historical blocks to retain.
-- `prune: never`: No pruning of historical data; retains the entire history and is the default if there is no `indexerHints` section. `prune: never` should be selected if [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired.
+- `prune: auto`: Endeksleyici tarafından belirlenen asgari gerekli geçmişi koruyarak sorgu performansını optimize eder. Bu genellikle önerilen ayardır ve `graph-cli` >= 0.66.0 tarafından oluşturulan tüm subgraph'ler için varsayılandır.
+- `prune: <Korunacak blok sayısı>`: Korunacak olan geçmiş blokların sayısı için özel bir limit belirler.
+- `prune: never`: Geçmiş verilerin budanması yoktur; tüm geçmişi korur. `indexerHints` bölümü yoksa `prune: never` varsayılandır. [Zaman Yolculuğu Sorguları](/subgraphs/querying/graphql-api/#time-travel-queries) isteniyorsa `prune: never` seçilmelidir.
 
-We can add `indexerHints` to our subgraphs by updating our `subgraph.yaml`:
+`subgraph.yaml` dosyamızı güncelleyerek subgraph'lerimize `indexerHints` ekleyebiliriz:
 
 ```yaml
 specVersion: 1.0.0
@@ -34,11 +34,11 @@ dataSources:
 
 - If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
 
-- It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
+- Budanan bir blok yüksekliğinde [aşılama](/subgraphs/cookbook/grafting/) yapılamaz. Aşılama rutin olarak yapılıyorsa ve budama isteniyorsa, belirli bir blok sayısını (örneğin, altı ay yetecek kadar) doğru bir şekilde koruyacak `indexerHints: prune: <Korunacak blok sayısı>` ayarı kullanılması önerilir.
 
 ## Sonuç
 
-Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
+`indexerHints` kullanarak budama, subgraph geliştirmesi için örnek uygulamadır ve sorgu performansında önemli iyileştirmeler sunar.
 
 ## Subgraph Örnek Uygulamalar 1-6
 

From 7264ec04247e919f6d2da7322989ee134e4e51ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 11:13:15 -0500
Subject: [PATCH 3685/3820] New translations secure-api-keys-nextjs.mdx
 (Turkish)

---
 .../pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx    | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index 37e0846da826..fd79ba6c13ed 100644
--- a/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -1,10 +1,10 @@
 ---
-title: How to Secure API Keys Using Next.js Server Components
+title: Next.js Sunucu Bileşenlerini Kullanarak API Anahtarları Nasıl Güvenli Bir Şekilde Kullanılır
 ---
 
 ## Genel Bakış
 
-We can use [Next.js server components](https://nextjs.org/docs/app/building-your-application/rendering/server-components) to properly secure our API key from exposure in the frontend of our dapp. To further increase our API key security, we can also [restrict our API key to certain subgraphs or domains in Subgraph Studio](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
+API anahtarımızı dapp'imizin ön yüzünde açığa çıkmasını düzgün bir şekilde engellemek için [Next.js sunucu bileşenlerini](https://nextjs.org/docs/app/building-your-application/rendering/server-components) kullanabiliriz. API anahtarımızın güvenliğini daha da artırmak için, ayrıca [API anahtarımızı belirli subgraph'lar veya Subgraph Studio'daki alanlarla sınırlandırabiliriz](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
 
 In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
 

From 53a986cccdbb1738e1f6ba59081c597ec2e28328 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 11:13:19 -0500
Subject: [PATCH 3686/3820] New translations near.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/cookbook/near.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/zh/subgraphs/cookbook/near.mdx b/website/pages/zh/subgraphs/cookbook/near.mdx
index d4d431b3db37..a1146dbab5e8 100644
--- a/website/pages/zh/subgraphs/cookbook/near.mdx
+++ b/website/pages/zh/subgraphs/cookbook/near.mdx
@@ -4,18 +4,18 @@ title: 在 NEAR 上构建子图
 
 This guide is an introduction to building subgraphs indexing smart contracts on the [NEAR blockchain](https://docs.near.org/).
 
-## NEAR 是什么？
+## What is NEAR?
 
 [NEAR](https://near.org/) is a smart contract platform for building decentralized applications. Visit the [official documentation](https://docs.near.org/concepts/basics/protocol) for more information.
 
-## NEAR 子图是什么？
+## What are NEAR subgraphs?
 
 The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
 
 Subgraphs are event-based, which means that they listen for and then process onchain events. There are currently two types of handlers supported for NEAR subgraphs:
 
-- 区块处理器: 这些处理程序在每个新区块上运行。
-- 收据处理器: 每次在指定账户上一个消息被执行时运行。
+- Block handlers: these are run on every new block
+- Receipt handlers: run every time a message is executed at a specified account
 
 [From the NEAR documentation](https://docs.near.org/build/data-infrastructure/lake-data-structures/receipt):
 
@@ -85,7 +85,7 @@ accounts:
     - morning.testnet
 ```
 
-NEAR 数据源支持两种类型的处理程序：
+NEAR data sources support two types of handlers:
 
 - `blockHandlers`: run on every new NEAR block. No `source.account` is required.
 - `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).

From 87c1e3765a361215ad399e8b691fbe482189ecd4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 12:17:04 -0500
Subject: [PATCH 3687/3820] New translations secure-api-keys-nextjs.mdx
 (Turkish)

---
 .../cookbook/secure-api-keys-nextjs.mdx       | 54 +++++++++----------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index fd79ba6c13ed..70185f3ea9ad 100644
--- a/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -6,43 +6,43 @@ title: Next.js Sunucu Bileşenlerini Kullanarak API Anahtarları Nasıl Güvenli
 
 API anahtarımızı dapp'imizin ön yüzünde açığa çıkmasını düzgün bir şekilde engellemek için [Next.js sunucu bileşenlerini](https://nextjs.org/docs/app/building-your-application/rendering/server-components) kullanabiliriz. API anahtarımızın güvenliğini daha da artırmak için, ayrıca [API anahtarımızı belirli subgraph'lar veya Subgraph Studio'daki alanlarla sınırlandırabiliriz](/cookbook/upgrading-a-subgraph/#securing-your-api-key).
 
-In this cookbook, we will go over how to create a Next.js server component that queries a subgraph while also hiding the API key from the frontend.
+Bu talimatlarda, bir subgraph'i sorgularken aynı zamanda API anahtarını ön yüzden gizleyen bir Next.js sunucu bileşeni oluşturmayı ele alacağız.
 
-### Caveats
+### Kısıtlamalar
 
-- Next.js server components do not protect API keys from being drained using denial of service attacks.
-- The Graph Network gateways have denial of service detection and mitigation strategies in place, however using server components may weaken these protections.
+- Next.js sunucu bileşenleri, servis dışı bırakma saldırıları ile API anahtarlarının boşaltılmasına karşı koruma sağlamaz.
+- The Graph Ağ geçitleri, servis dışı bırakma saldırı tespiti ve saldırıyı hafifletme stratejilerine sahiptir. Ancak sunucu bileşenlerini kullanmak bu korumaları zayıflatabilir.
 - Next.js server components introduce centralization risks as the server can go down.
 
-### Why It's Needed
+### Neden Gerekli
 
-In a standard React application, API keys included in the frontend code can be exposed to the client-side, posing a security risk. While `.env` files are commonly used, they don't fully protect the keys since React's code is executed on the client side, exposing the API key in the headers. Next.js Server Components address this issue by handling sensitive operations server-side.
+Standart bir React uygulamasında, ön yüz koduna dahil edilen API anahtarları istemci tarafında açığa çıkabilir ve güvenlik riski oluşturabilir. `.env` dosyaları yaygın olarak kullanılsa da React kodu istemci tarafında çalıştığı için anahtarları tam olarak korumazlar ve API anahtarı başlıklarda açığa çıkar. Next.js Sunucu Bileşenleri bu sorunu, hassas işlemleri sunucu tarafında yürüterek çözer.
 
-### Using client-side rendering to query a subgraph
+### Bir subgraph'i sorgulamak için istemci tarafında işleme (render)
 
-![Client-side rendering](/img/api-key-client-side-rendering.png)
+![İstemci tarafında işleme](/img/api-key-client-side-rendering.png)
 
 ### Ön Koşullar
 
-- An API key from [Subgraph Studio](https://thegraph.com/studio)
-- Basic knowledge of Next.js and React.
-- An existing Next.js project that uses the [App Router](https://nextjs.org/docs/app).
+- [Subgraph Studio](https://thegraph.com/studio)'dan bir API anahtarı
+- Temel Next.js ve React bilgisi.
+- [Uygulama Yönlendiricisi](https://nextjs.org/docs/app) kullanan mevcut bir Next.js projesi.
 
-## Step-by-Step Cookbook
+## Adım Adım Talimatlar
 
-### Step 1: Set Up Environment Variables
+### Adım 1: Ortam Değişkenlerini Ayarlayın
 
-1. In our Next.js project root, create a `.env.local` file.
-2. Add our API key: `API_KEY=<api_key_here>`.
+1. Next.js projemizin kök dizininde `.env.local` dosyası oluşturun.
+2. API anahtarımızı ekleyin: `API_KEY=<buraya_api_anahtarını_yerleştirin>`.
 
-### Step 2: Create a Server Component
+### Adım 2: Bir Sunucu Bileşeni Oluşturma
 
-1. In our `components` directory, create a new file, `ServerComponent.js`.
-2. Use the provided example code to set up the server component.
+1. `components` dizinimizde "ServerComponent.js" adında yeni bir dosya oluşturun.
+2. Sunucu bileşenini kurmak için sağlanan örnek kodu kullanın.
 
-### Step 3: Implement Server-Side API Request
+### Adım 3: Sunucu Tarafı API İsteğini Gerçekleştirin
 
-In `ServerComponent.js`, add the following code:
+`ServerComponent.js`'e aşağıdaki kodu ekleyin:
 
 ```javascript
 const API_KEY = process.env.API_KEY
@@ -95,10 +95,10 @@ export default async function ServerComponent() {
 }
 ```
 
-### Step 4: Use the Server Component
+### Adım 4: Sunucu Bileşenini Kullanın
 
-1. In our page file (e.g., `pages/index.js`), import `ServerComponent`.
-2. Render the component:
+1. Sayfa dosyamızda (örneğin, `pages/index.js`), `ServerComponent`'ı içe aktarın.
+2. Bileşeni işleyin:
 
 ```javascript
 import ServerComponent from './components/ServerComponent'
@@ -112,12 +112,12 @@ export default function Home() {
 }
 ```
 
-### Step 5: Run and Test Our Dapp
+### Adım 5: Dapp'imizi Çalıştırın ve Test Edin
 
-Start our Next.js application using `npm run dev`. Verify that the server component is fetching data without exposing the API key.
+`npm run dev` komutunu kullanarak Next.js uygulamamızı başlatın. Sunucu bileşeninin API anahtarını açığa çıkarmadan veri çektiğini doğrulayın.
 
-![Server-side rendering](/img/api-key-server-side-rendering.png)
+![Sunucu-taraflı işleme](/img/api-key-server-side-rendering.png)
 
 ### Sonuç
 
-By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.
+Next.js Sunucu Bileşenlerini kullanarak, API anahtarını istemci tarafında gizlemeyi başardık ve bu da uygulamamızın güvenliğini artırdı. Bu yöntem, hassas işlemlerin potansiyel istemci-taraflı güvenlik açıklıklarından uzak bir şekilde sunucu tarafında ele alındığını garanti eder. Son olarak, API anahtar güvenliğinizi daha da artırmak için [diğer API anahtar güvenlik önlemlerini](/subgraphs/querying/managing-api-keys/) incelemeyi unutmayın.

From 5028161060036274cc05d8e72e8e5eb3a8beec8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 12:17:06 -0500
Subject: [PATCH 3688/3820] New translations subgraph-debug-forking.mdx
 (Turkish)

---
 .../cookbook/subgraph-debug-forking.mdx       | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx
index ba011ead30dc..76ed17654120 100644
--- a/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -2,11 +2,11 @@
 title: Fork Kullanarak Hızlı ve Kolay Subgraph Hata Ayıklama
 ---
 
-As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
+Büyük miktarda veri işleyen birçok sistemde olduğu gibi, The Graph'ın Endeksleyicilerinin (Graph Düğümlerinin), subgraph'inizi hedef blokzinciri ile senkronize etmesi ciddi ölçüde uzun sürebilir. Hata ayıklama amacıyla yapılan hızlı değişiklikler ile endeksleme için gereken uzun bekleme süreleri arasındaki uyumsuzluk son derece verimsiz olmaktadır. Bunun kesinlikle farkındayız. Bu yüzden, [LimeChain](https://limechain.tech/) tarafından geliştirilen **subgraph çatallama**yı sunuyoruz. Bu makalede size bu özelliğin subgraph hata ayıklamayı önemli ölçüde hızlandırmak için nasıl kullanılabileceğini göstereceğim!
 
 ## Peki, nedir bu Subgraph Forklama?
 
-**Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
+**Subgraph çatallama**, _başka bir_ subgraph'in mağazasından (genellikle uzak bir mağaza) tembel bir şekilde öge çekme işlemidir.
 
 In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
 
@@ -20,7 +20,7 @@ In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph N
 
 To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
 
-Here are the handlers defined for indexing `Gravatar`s, with no bugs whatsoever:
+`Gravatar`'ları endekslemek için tanımlanan, hiçbir hata içermeyen işleyiciler şunlardır:
 
 ```tsx
 export function handleNewGravatar(event: NewGravatar): void {
@@ -44,22 +44,22 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void {
 }
 ```
 
-Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
+Eyvah, ne talihsiz bir durum, mükemmel görünen subgraph'imi [Subgraph Studio](https://thegraph.com/studio/) üzerinde dağıttığımda _"Gravatar bulunamadı!"_ hatası ile çalışmayı durduruyor.
 
 Genellikle düzeltmeyi denemek için yol şudur:
 
 1. Eşleştirme kaynağında, sorunu çözeceğine inandığınız bir değişiklik yapın (ama ben çözmeyeceğini biliyorum).
-2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
+2. Subgraph'i [Subgraph Studio](https://thegraph.com/studio/) (veya başka bir uzak Graph Düğümü) üzerinde yeniden dağıtın.
 3. Senkronize olması için bekleyin.
 4. Tekrar sorunla karşılaşırsanız 1. aşamaya geri dönün, aksi takdirde: Yaşasın!
 
-It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
+Bu gerçekten sıradan bir hata ayıklama sürecine oldukça benzemektedir, ancak süreci korkunç derecede yavaşlatan bir adım vardır: _3. Senkronize olmasını bekleyin._
 
-Using **subgraph forking** we can essentially eliminate this step. Here is how it looks:
+**Subgraph çatallama** kullanarak bu adımı ortadan kaldırabiliriz. Aşağıda bu işlemi görebilirsiniz:
 
 0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
 1. Eşleştirme kaynağında, sorunu çözeceğine inandığınız bir değişiklik yapın.
-2. Deploy to the local Graph Node, **_forking the failing subgraph_** and **_starting from the problematic block_**.
+2. Çalışmayı durduran subgraph'i **_çatallayarak_** ve **_sorunlu bloktan başlayarak_** yerel Graph Düğümüne dağıtın.
 3. Tekrar sorunla karşılaşırsanız 1. aşamaya geri dönün, aksi takdirde: Yaşasın!
 
 Şimdi, 2 sorunuz olabilir:
@@ -69,18 +69,18 @@ Using **subgraph forking** we can essentially eliminate this step. Here is how i
 
 Ve ben cevap veriyorum:
 
-1. `fork-base` is the "base" URL, such that when the _subgraph id_ is appended the resulting URL (`<fork-base>/<subgraph-id>`) is a valid GraphQL endpoint for the subgraph's store.
+1. `fork-base`, "temel" URL'dir, böylece devamına _subgraph id_ eklendiğinde oluşan URL (`<fork-base>/<subgraph-id>`) subgraph'in depolaması için geçerli bir GraphQL uç noktası olur.
 2. Forklama kolay, ter dökmeye gerek yok:
 
 ```bash
-$ graph deploy <subgraph-name> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
+$ graph deploy <subgraph-ismi> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
 ```
 
 Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
 
 İşte benim ne yaptığım:
 
-1. I spin-up a local Graph Node ([here is how to do it](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) with the `fork-base` option set to: `https://api.thegraph.com/subgraphs/id/`, since I will fork a subgraph, the buggy one I deployed earlier, from [Subgraph Studio](https://thegraph.com/studio/).
+1. Lokal bir Graph Düğümü başlatıyorum ([nasıl yapılacağını buradan öğrenebilirsiniz](https://github.com/graphprotocol/graph-node#running-a-local-graph-node)) ve `fork-base` seçeneğini şu şekilde ayarlıyorum: `https://api.thegraph.com/subgraphs/id/`, çünkü daha önce [Subgraph Studio](https://thegraph.com/studio/)dan dağıttığım hatalı `subgraph`i çatallayacağım.
 
 ```
 $ cargo run -p graph-node --release -- \
@@ -90,7 +90,7 @@ $ cargo run -p graph-node --release -- \
     --fork-base https://api.thegraph.com/subgraphs/id/
 ```
 
-2. After careful inspection I notice that there is a mismatch in the `id` representations used when indexing `Gravatar`s in my two handlers. While `handleNewGravatar` converts it to a hex (`event.params.id.toHex()`), `handleUpdatedGravatar` uses an int32 (`event.params.id.toI32()`) which causes the `handleUpdatedGravatar` to panic with "Gravatar not found!". I make them both convert the `id` to a hex.
+2. Dikkatli bir incelemeden sonra, iki işleyicimde `Gravatar`'ları endekslerken kullanılan `id` temsillerinde bir uyumsuzluk olduğunu fark ettim. `handleNewGravatar` onu bir hex'e dönüştürürken (`event.params.id.toHex()`), `handleUpdatedGravatar` bir int32 (`event.params.id.toI32()`) kullanıyor, bu da `handleUpdatedGravatar`'ın "Gravatar not found!" hatasını vermesine neden oluyor. İkisini de `id`'yi hex'e dönüştürecek şekilde düzenledim.
 3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
 
 ```bash

From 8b049bbd815b055c7c32af7ec805e3ed552b26a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 12:17:08 -0500
Subject: [PATCH 3689/3820] New translations subgraph-uncrashable.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx
index 8b9f4a425710..1a8229e80b08 100644
--- a/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx
+++ b/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -26,4 +26,4 @@ Subgraph Uncrashable, Graph CLI codegen komutu kullanılarak isteğe bağlı bir
 graph codegen -u [options] [<subgraph-manifest>]
 ```
 
-Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.
+Daha fazla bilgi edinmek ve daha güvenli subgraph'ler geliştirmeye başlamak için [çökmeyen subgraph dokümantasyonuna](https://float-capital.github.io/float-subgraph-uncrashable/docs/) göz atın veya bu [video rehberini](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) izleyin.

From df3b82154628e3f5eb3ac15d646659262b29a8c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:23:55 -0500
Subject: [PATCH 3690/3820] New translations explorer.mdx (German)

---
 website/pages/de/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/subgraphs/explorer.mdx b/website/pages/de/subgraphs/explorer.mdx
index b6d4be6ff79e..3ca1e5892076 100644
--- a/website/pages/de/subgraphs/explorer.mdx
+++ b/website/pages/de/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Total amount of GRT they have currently in the protocol
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 29cc6a8ba468e8e73919c712b9b3ef9528e96a96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:23:56 -0500
Subject: [PATCH 3691/3820] New translations timeseries.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/timeseries.mdx      | 114 +++++++++---------
 1 file changed, 57 insertions(+), 57 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/timeseries.mdx b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
index 2f01ff2d896e..9ee204ea48da 100644
--- a/website/pages/tr/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
@@ -1,48 +1,48 @@
 ---
-title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggregations
+title: Subgraph Örnek Uygulama 5 - Zaman serileri ve Toplulaştırma ile Basitleştirip Optimize Edin
 ---
 
 ## Özet
 
-Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance.
+Subgraph'lerdeki yeni zaman serisi ve toplulaştırma özelliğini kullanmak, hem endeksleme hızını hem de sorgu performansını önemli ölçüde artırabilir.
 
 ## Genel Bakış
 
-Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+Zaman serisi ve toplulaştırmalar, toplulaştırma hesaplamalarını veritabanına aktararak ve eşleme kodunu basitleştirerek, veri işleme yükünü azaltır ve sorguları hızlandırır. Bu yaklaşım, özellikle büyük hacimli zamana dayalı verilerle başa çıkarken etkilidir.
 
-## Benefits of Timeseries and Aggregations
+## Zaman Serisi ve Toplulaştırmaların Faydaları
 
 1. Improved Indexing Time
 
 - Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
-- Database-Managed Aggregations: Aggregations are automatically computed by the database, reducing the workload on the mappings.
+- Veritabanı Tarafından Yönetilen Toplulaştırmalar: Toplulaştırmalar otomatik olarak veritabanı tarafından hesaplanır, bu da eşlemeler üzerindeki yükü azaltır.
 
-2. Simplified Mapping Code
+2. Basitleştirilmiş Eşleme Kodu
 
-- No Manual Calculations: Developers no longer need to write complex aggregation logic in mappings.
-- Reduced Complexity: Simplifies code maintenance and minimizes the potential for errors.
+- Manuel Hesaplama Olmaması: Geliştiriciler artık eşlemelerde karmaşık toplulaştırma mantığı yazmak zorunda değildir.
+- Azaltılmış Karmaşıklık: Kod bakımını basitleştirir ve hata olasılığını en aza indirir.
 
-3. Dramatically Faster Queries
+3. Çok Daha Hızlı Sorgular
 
-- Immutable Data: All timeseries data is immutable, enabling efficient storage and retrieval.
+- Değişmez Veri: Tüm zaman serisi verileri değişmezdir. Bu da verimli depolama ve geri çağırmayı mümkün kılar.
 - Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
 
 ### Önemli Hususlar
 
-- Immutable Data: Timeseries data cannot be altered once written, ensuring data integrity and simplifying indexing.
-- Automatic ID and Timestamp Management: id and timestamp fields are automatically managed by graph-node, reducing potential errors.
-- Efficient Data Storage: By separating raw data from aggregates, storage is optimized, and queries run faster.
+- Değişmez Veri: Zaman serisi verileri yazıldıktan sonra değiştirilemez, bu da veri bütünlüğünü sağlar ve endekslemeyi basitleştirir.
+- Otomatik Kimlık Numarası ve Zaman Damgası Yönetimi: id (kimlik numarası) ve timestamp (zaman damgası) alanları graph-node tarafından otomatik olarak yönetilir, potansiyel hataları azaltır.
+- Verimli Veri Depolama: Ham verileri toplulaştırmalardan ayırarak, depolama optimize edilir ve sorgular daha hızlı çalışır.
 
-## How to Implement Timeseries and Aggregations
+## Zaman Serisi ve Toplulaştırmaları Nasıl Uygulanır
 
-### Defining Timeseries Entities
+### Zaman Serisi Varlıklarının Tanımlanması
 
-A timeseries entity represents raw data points collected over time. It is defined with the `@entity(timeseries: true)` annotation. Key requirements:
+Bir zaman serisi varlığı, zaman içinde toplanan ham veri noktalarını temsil eder. `@entity(timeseries: true)` notasyonu ile tanımlanır. Ana gereksinimler:
 
-- Immutable: Timeseries entities are always immutable.
-- Mandatory Fields:
-  - `id`: Must be of type `Int8!` and is auto-incremented.
-  - `timestamp`: Must be of type `Timestamp!` and is automatically set to the block timestamp.
+- Değişmezlik: Zaman serisi varlıkları her zaman değişmezdir.
+- Zorunlu Alanlar:
+  - `id`: `Int8!` türünde olmalı ve otomatik olarak artmalıdır.
+  - `timestamp`: `Timestamp!` türünde olmalı ve blok zaman damgasına otomatik olarak ayarlanmalıdır.
 
 Örnek:
 
@@ -54,12 +54,12 @@ type Data @entity(timeseries: true) {
 }
 ```
 
-### Defining Aggregation Entities
+### Toplulaştırma Varlıklarını Tanımlama
 
-An aggregation entity computes aggregated values from a timeseries source. It is defined with the `@aggregation` annotation. Key components:
+Bir toplulaştırma varlığı, bir zaman serisi kaynağından toplulaştırılmış değerleri hesaplar. `@aggregation` ile tanımlanır. Ana bileşenler:
 
-- Annotation Arguments:
-  - `intervals`: Specifies time intervals (e.g., `["hour", "day"]`).
+- Açıklama Argümanları:
+  - `intervals`: Zaman aralıklarını belirtir (örneğin, `["hour", "day"]`).
 
 Örnek:
 
@@ -71,9 +71,9 @@ type Stats @aggregation(intervals: ["hour", "day"], source: "Data") {
 }
 ```
 
-In this example, Stats aggregates the price field from Data over hourly and daily intervals, computing the sum.
+Bu örnekte Stats, Data'dan fiyat alanını saatlik ve günlük aralıklar üzerinden toplulaştırarak toplamı hesaplar.
 
-### Querying Aggregated Data
+### Toplulaştırılmış Verileri Sorgulama
 
 Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
 
@@ -97,13 +97,13 @@ Aggregations are exposed via query fields that allow filtering and retrieval bas
 }
 ```
 
-### Using Dimensions in Aggregations
+### Toplulaştırmalarda Boyutların Kullanımı
 
 Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
 
 Örnek:
 
-### Timeseries Entity
+### Zaman Serisi Varlığı
 
 ```graphql
 type TokenData @entity(timeseries: true) {
@@ -128,56 +128,56 @@ type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
 }
 ```
 
-- Dimension Field: token groups the data, so aggregates are computed per token.
-- Aggregates:
-  - totalVolume: Sum of amount.
-  - priceUSD: Last recorded priceUSD.
-  - count: Cumulative count of records.
+- Boyut Alanı: Token, verileri gruplar. Bu nedenle toplulaştırmalar her token için hesaplanır.
+- Toplulaştırmalar:
+  - totalVolume: Miktarın (amount alanının) toplamı.
+  - priceUSD: Kayıtlı son priceUSD.
+  - count: Kayıtların kümülatif sayısı.
 
-### Aggregation Functions and Expressions
+### Toplulaştırma Fonksiyonları ve İfadeleri
 
-Supported aggregation functions:
+Desteklenen toplulaştırma fonksiyonları:
 
-- sum
-- count
-- min
-- max
-- first
-- last
+- sum (toplama)
+- count (sayma)
+- min (asgari)
+- max (azami)
+- first (ilk)
+- last (son)
 
 ### The arg in @aggregate can be
 
 - A field name from the timeseries entity.
 - An expression using fields and constants.
 
-### Examples of Aggregation Expressions
+### Toplulaştırma İfadeleri Örnekleri
 
-- Sum Token Value: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
-- Maximum Positive Amount: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
-- Conditional Sum: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
+- Token Değerini Topla: @aggregate(fn: "sum", arg: "priceUSD \_ amount")
+- Azami Pozitif Tutar: @aggregate(fn: "max", arg: "greatest(amount0, amount1, 0)")
+- Koşullu Toplama: @aggregate(fn: "sum", arg: "case when amount0 > amount1 then amount0 else 0 end")
 
-Supported operators and functions include basic arithmetic (+, -, \_, /), comparison operators, logical operators (and, or, not), and SQL functions like greatest, least, coalesce, etc.
+Desteklenen operatörler ve fonksiyonlar arasında temel aritmetik (+, -, \_, /) operatörleri, karşılaştırma operatörleri, mantıksal operatörler (and, or, not) ve SQL fonksiyonları (örneğin greatest, least, coalesce) bulunur.
 
-### Query Parameters
+### Sorgu Parametreleri
 
-- interval: Specifies the time interval (e.g., "hour").
-- where: Filters based on dimensions and timestamp ranges.
+- interval: Zaman aralığını belirtir (ör., "hour").
+- where: Boyutlara ve zaman damgası aralıklarına göre filtreler.
 - timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
 
-### Notes
+### Notlar
 
-- Sorting: Results are automatically sorted by timestamp and id in descending order.
-- Current Data: An optional current argument can include the current, partially filled interval.
+- Sıralama: Sonuçlar otomatik olarak zaman damgası ve id'ye göre azalan sırada sıralanır.
+- Mevcut Veriler: Opsiyonel mevcut argüman, mevcut, kısmen doldurulmuş aralığı içerebilir.
 
 ### Sonuç
 
-Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
+Zaman serileri ve toplulaştırmaların subgraph'lerde uygulanması, zamana dayalı veri ile çalışan projeler için örnek bir uygulamadır. Bu yaklaşım:
 
-- Enhances Performance: Speeds up indexing and querying by reducing data processing overhead.
-- Simplifies Development: Eliminates the need for manual aggregation logic in mappings.
-- Scales Efficiently: Handles large volumes of data without compromising on speed or responsiveness.
+- Performansı Artırır: Veri işleme yükünü azaltarak endeksleme ve sorgulamayı hızlandırır.
+- Geliştirmeyi Basitleştirir: Eşlemelerde manuel toplulaştırma mantığı ihtiyacını ortadan kaldırır.
+- Verimli Ölçeklenir: Hız veya yanıt verme süresinden ödün vermeden büyük hacimli verileri işler.
 
-By adopting this pattern, developers can build more efficient and scalable subgraphs, providing faster and more reliable data access to end-users. To learn more about implementing timeseries and aggregations, refer to the [Timeseries and Aggregations Readme](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) and consider experimenting with this feature in your subgraphs.
+Bu modeli benimseyerek, geliştiriciler daha verimli ve ölçeklenebilir subgraph'ler oluşturabilir ve son kullanıcılara daha hızlı ve güvenilir veri erişimi sağlayabilirler. Zaman serileri ve toplulaştırmaların uygulanması hakkında daha fazla bilgi için [Zaman Serileri ve Toplulaştırmalar](https://github.com/graphprotocol/graph-node/blob/master/docs/aggregations.md) belgesini inceleyin. Bu özelliği subgraph'lerinizde denemeyi de düşünebilirsiniz.
 
 ## Subgraph Örnek Uygulamalar 1-6
 

From ea7cefc6938b282960c969329535fed0b4f72d2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:23:57 -0500
Subject: [PATCH 3692/3820] New translations curating.mdx (Portuguese)

---
 website/pages/pt/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/resources/roles/curating.mdx b/website/pages/pt/resources/roles/curating.mdx
index b92c9cefd7df..75ad819201f3 100644
--- a/website/pages/pt/resources/roles/curating.mdx
+++ b/website/pages/pt/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ Porém, é recomendado que curadores deixem o seu GRT no lugar, não apenas para
 
 1. O mercado de consulta é jovem por natureza no The Graph, e há sempre o risco do seu rendimento anual ser menor que o esperado devido às dinâmicas nascentes do mercado.
 2. Taxa de Curadoria - Quando um curador sinaliza GRT em um subgraph, ele incorre uma taxa de curadoria de 1%, que é queimada.
-3. (Só para o Ethereum) Quando os curadores queimam as suas ações para sacar GRT, o valor das ações restantes em GRT é diminuído. Perceba que, em alguns casos, os curadores podem decidir queimar todas as suas ações <strong x-id="1">de uma vez só</strong>. Isto pode ser comum se um programador de dApp parar de atualizar/melhorar as versões do seu subgraph e fazer queries nele, ou se um subgraph falhar. Portanto, é possível que os curadores restantes só sacarão uma fração do seu GRT inicial. Para um papel de rede com um perfil de risco menor, veja <a href="/network/delegating">Delegantes</a>.
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. Um subgraph pode falhar devido a um erro de código. Um subgraph falho não acumula taxas de consulta. Portanto, espere até o programador consertar o erro e lançar uma nova versão.
    - Caso se inscreva à versão mais recente de um subgraph, suas ações migrarão automaticamente a esta versão nova. Isto incorrerá uma taxa de curadoria de 0.5%.
    - Se sinalizou em um subgraph específico e ele falhou, deverá queimar as suas ações de curadoria manualmente. Será então possível sinalizar na nova versão do subgraph, o que incorre uma taxa de curadoria de 1%.

From faea16075266b647ff924d2b3dbca8461fb963dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:23:59 -0500
Subject: [PATCH 3693/3820] New translations explorer.mdx (Portuguese)

---
 website/pages/pt/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs/explorer.mdx b/website/pages/pt/subgraphs/explorer.mdx
index cf8a73228ef2..ebe605ca1121 100644
--- a/website/pages/pt/subgraphs/explorer.mdx
+++ b/website/pages/pt/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - A quantidade total de GRT que têm no protocolo no momento
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 3b538ba8b601f42d126aff7cd60abec4da25a74c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:00 -0500
Subject: [PATCH 3694/3820] New translations explorer.mdx (Romanian)

---
 website/pages/ro/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/subgraphs/explorer.mdx b/website/pages/ro/subgraphs/explorer.mdx
index 94bf8f0c481d..3fe663ead83e 100644
--- a/website/pages/ro/subgraphs/explorer.mdx
+++ b/website/pages/ro/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Total amount of GRT they have currently in the protocol
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 167e962d3cd1c9c9c2e54a17bac40c3ec3285842 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:01 -0500
Subject: [PATCH 3695/3820] New translations explorer.mdx (French)

---
 website/pages/fr/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/subgraphs/explorer.mdx b/website/pages/fr/subgraphs/explorer.mdx
index e21e0bb08603..c06e4e41cb69 100644
--- a/website/pages/fr/subgraphs/explorer.mdx
+++ b/website/pages/fr/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ Dans le tableau des Délégateurs, vous pouvez voir les Délégateurs actifs dan
 - Quantité totale de GRT qu'ils ont actuellement dans le protocole
 - La date de leur dernière délégation
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 681e03a2b05998991ede724af756357ed7d930a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:02 -0500
Subject: [PATCH 3696/3820] New translations explorer.mdx (Spanish)

---
 website/pages/es/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/subgraphs/explorer.mdx b/website/pages/es/subgraphs/explorer.mdx
index 6980559e8766..f54af60d9c27 100644
--- a/website/pages/es/subgraphs/explorer.mdx
+++ b/website/pages/es/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Cantidad total de GRT que tienen actualmente dentro del protocolo
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From f57b07c0b74872953e7d5f710ed476b9d3aa3eeb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:04 -0500
Subject: [PATCH 3697/3820] New translations explorer.mdx (Arabic)

---
 website/pages/ar/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/subgraphs/explorer.mdx b/website/pages/ar/subgraphs/explorer.mdx
index c272a7678a12..d26db73262e2 100644
--- a/website/pages/ar/subgraphs/explorer.mdx
+++ b/website/pages/ar/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - كمية ال GRT التي يمتلكونها حاليا في البروتوكول
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 192d11155133a790d3ac056acf2b54a127225a66 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:05 -0500
Subject: [PATCH 3698/3820] New translations explorer.mdx (Czech)

---
 website/pages/cs/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/subgraphs/explorer.mdx b/website/pages/cs/subgraphs/explorer.mdx
index 7d1fa5d410e7..954f6b004223 100644
--- a/website/pages/cs/subgraphs/explorer.mdx
+++ b/website/pages/cs/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Celkové množství GRT, které mají v současné době v protokolu
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From e39eb241dab809c1e75e5443a21c9b59af693742 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:06 -0500
Subject: [PATCH 3699/3820] New translations explorer.mdx (Italian)

---
 website/pages/it/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/subgraphs/explorer.mdx b/website/pages/it/subgraphs/explorer.mdx
index e46e4884b488..c47ea37496ee 100644
--- a/website/pages/it/subgraphs/explorer.mdx
+++ b/website/pages/it/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Quantità totale di GRT che hanno attualmente nel protocollo
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 5b4bb20dbb3b116f550fbc55b6b5f237685e7774 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:07 -0500
Subject: [PATCH 3700/3820] New translations explorer.mdx (Japanese)

---
 website/pages/ja/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/subgraphs/explorer.mdx b/website/pages/ja/subgraphs/explorer.mdx
index c0356b47f077..d16091fd97c4 100644
--- a/website/pages/ja/subgraphs/explorer.mdx
+++ b/website/pages/ja/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - 現在プロトコルに保持している GRT 総量
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 72f98eb555edf8afa37e4c7f518ea4b3cba1b673 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:08 -0500
Subject: [PATCH 3701/3820] New translations explorer.mdx (Korean)

---
 website/pages/ko/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/subgraphs/explorer.mdx b/website/pages/ko/subgraphs/explorer.mdx
index 94bf8f0c481d..3fe663ead83e 100644
--- a/website/pages/ko/subgraphs/explorer.mdx
+++ b/website/pages/ko/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Total amount of GRT they have currently in the protocol
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 1f0a4a966ab239687e5d852ca36e671f62896829 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:10 -0500
Subject: [PATCH 3702/3820] New translations explorer.mdx (Dutch)

---
 website/pages/nl/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/subgraphs/explorer.mdx b/website/pages/nl/subgraphs/explorer.mdx
index be421ea28c4c..2bc6b1829191 100644
--- a/website/pages/nl/subgraphs/explorer.mdx
+++ b/website/pages/nl/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Het totale bedrag aan GRT dat ze momenteel in het protocol hebben
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 5ee01cef1130b3b87f63357f569388c2edd256f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:11 -0500
Subject: [PATCH 3703/3820] New translations explorer.mdx (Polish)

---
 website/pages/pl/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/subgraphs/explorer.mdx b/website/pages/pl/subgraphs/explorer.mdx
index 94bf8f0c481d..3fe663ead83e 100644
--- a/website/pages/pl/subgraphs/explorer.mdx
+++ b/website/pages/pl/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Total amount of GRT they have currently in the protocol
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 2c1683aaeab17b109d6ae4eac7a351324757c37d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:13 -0500
Subject: [PATCH 3704/3820] New translations explorer.mdx (Russian)

---
 website/pages/ru/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/subgraphs/explorer.mdx b/website/pages/ru/subgraphs/explorer.mdx
index 5530853a770e..6eef6217db8c 100644
--- a/website/pages/ru/subgraphs/explorer.mdx
+++ b/website/pages/ru/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ If you want to learn more about the Curator role, you can do so by visiting [off
 - Общее количество GRT, которое у них имеется в настоящее время в протоколе
 - Дата, когда они в последний раз делегировали
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 2914bb789843e93ea4af9a1a06e99b729c16684e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:14 -0500
Subject: [PATCH 3705/3820] New translations explorer.mdx (Swedish)

---
 website/pages/sv/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/subgraphs/explorer.mdx b/website/pages/sv/subgraphs/explorer.mdx
index 1d68a1a3e60f..dfc4fd2f1cb7 100644
--- a/website/pages/sv/subgraphs/explorer.mdx
+++ b/website/pages/sv/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Totalt belopp av GRT som de för närvarande har i protokollet
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From ae57c8d6f813c7249f7f3c158e98040021813e67 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:15 -0500
Subject: [PATCH 3706/3820] New translations explorer.mdx (Turkish)

---
 website/pages/tr/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/explorer.mdx b/website/pages/tr/subgraphs/explorer.mdx
index add2cf20cfa2..afcfe517c177 100644
--- a/website/pages/tr/subgraphs/explorer.mdx
+++ b/website/pages/tr/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Şu anda protokolde bulunan sahip oldukları toplam GRT miktarı
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 97a39f7944af18e65f697cbaea264a7e48a7348d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:16 -0500
Subject: [PATCH 3707/3820] New translations explorer.mdx (Ukrainian)

---
 website/pages/uk/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/subgraphs/explorer.mdx b/website/pages/uk/subgraphs/explorer.mdx
index c12d5da4e90a..e32416f7710a 100644
--- a/website/pages/uk/subgraphs/explorer.mdx
+++ b/website/pages/uk/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Total amount of GRT they have currently in the protocol
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 4f3191fd8c6402fe6412ef3e0dd30702b7eaf379 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:18 -0500
Subject: [PATCH 3708/3820] New translations explorer.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/explorer.mdx b/website/pages/zh/subgraphs/explorer.mdx
index 9da28e248eb9..81b7e922f290 100644
--- a/website/pages/zh/subgraphs/explorer.mdx
+++ b/website/pages/zh/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - 目前在协议中的 GRT 总量
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 9c2983d99a545b82469426ff7e03d952d40a1a59 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:19 -0500
Subject: [PATCH 3709/3820] New translations explorer.mdx (Urdu (Pakistan))

---
 website/pages/ur/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/subgraphs/explorer.mdx b/website/pages/ur/subgraphs/explorer.mdx
index 7749bf1814f7..d76fd542c1f3 100644
--- a/website/pages/ur/subgraphs/explorer.mdx
+++ b/website/pages/ur/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - پروٹوکول میں ان کے پاس موجود GRT کی کل رقم
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From cc2cc6e3831b2237ee1b55c5c76e64db75121d9a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:20 -0500
Subject: [PATCH 3710/3820] New translations explorer.mdx (Vietnamese)

---
 website/pages/vi/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/subgraphs/explorer.mdx b/website/pages/vi/subgraphs/explorer.mdx
index 048fa4b29df0..0cf740538aff 100644
--- a/website/pages/vi/subgraphs/explorer.mdx
+++ b/website/pages/vi/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Tổng lượng GRT mà họ hiện có trong giao thức
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 8b1ab70ba2f0d3a42014fff2b03f6f76aff6fd76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:21 -0500
Subject: [PATCH 3711/3820] New translations explorer.mdx (Marathi)

---
 website/pages/mr/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/subgraphs/explorer.mdx b/website/pages/mr/subgraphs/explorer.mdx
index 39ca874493c1..28cb465c5ec6 100644
--- a/website/pages/mr/subgraphs/explorer.mdx
+++ b/website/pages/mr/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Total amount of GRT they have currently in the protocol
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From ded161eef7f7011a3743d98f23bbe738f684d481 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:22 -0500
Subject: [PATCH 3712/3820] New translations explorer.mdx (Hindi)

---
 website/pages/hi/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/subgraphs/explorer.mdx b/website/pages/hi/subgraphs/explorer.mdx
index 61b2046cefb0..f9859d080341 100644
--- a/website/pages/hi/subgraphs/explorer.mdx
+++ b/website/pages/hi/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ Delegators तालिका में आप समुदाय में स
 - वर्तमान में उनके पास प्रोटोकॉल में जीआरटी की कुल राशि है
 - वे आखिरी बार 'delegated' की तारीख
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From 34e5cf89ba8108eccd462fca985e6e2190ef8d19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:24 -0500
Subject: [PATCH 3713/3820] New translations explorer.mdx (Swahili)

---
 website/pages/sw/subgraphs/explorer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/subgraphs/explorer.mdx b/website/pages/sw/subgraphs/explorer.mdx
index 94bf8f0c481d..3fe663ead83e 100644
--- a/website/pages/sw/subgraphs/explorer.mdx
+++ b/website/pages/sw/subgraphs/explorer.mdx
@@ -125,7 +125,7 @@ In the Delegators table you can see the active Delegators in the community and i
 - Total amount of GRT they have currently in the protocol
 - The date they last delegated
 
-If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
 ### Network Page
 

From fe5ae5cdeae73550c87c015dd84005c06057c03d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:25 -0500
Subject: [PATCH 3714/3820] New translations curating.mdx (Romanian)

---
 website/pages/ro/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/resources/roles/curating.mdx b/website/pages/ro/resources/roles/curating.mdx
index 8e6416b6d57e..b9488a834cb5 100644
--- a/website/pages/ro/resources/roles/curating.mdx
+++ b/website/pages/ro/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
    - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 89e631aafb3fb0a58225bebd11761aa1abde2fb1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:26 -0500
Subject: [PATCH 3715/3820] New translations curating.mdx (French)

---
 website/pages/fr/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/resources/roles/curating.mdx b/website/pages/fr/resources/roles/curating.mdx
index 1d60a7cb1f1e..3324aee796a7 100644
--- a/website/pages/fr/resources/roles/curating.mdx
+++ b/website/pages/fr/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ Cependant, il est recommandé que les Curateurs laissent leur GRT signalé en pl
 
 1. Le marché des requêtes est intrinsèquement jeune chez The Graph et il y a un risque que votre %APY soit inférieur à vos attentes en raison de la dynamique naissante du marché.
 2. Frais de curation - lorsqu'un Curateur signale des GRT sur un subgraph, il doit s'acquitter d'une taxe de curation de 1%. Cette taxe est brûlée.
-3. (Sur Ethereum uniquement) Lorsque les curateurs brûlent leurs parts pour retirer leurs GRT, la valeur en GRT des parts restantes est réduite. Sachez que, dans certains cas, les curateurs peuvent décider de brûler leurs parts en une seule fois. Cette situation peut se produire si un développeur de dapp cesse de versionner/de faire évoluer et d'interroger son subgraph, ou si un subgraph échoue. Par conséquent, les curateurs restants pourraient ne récupérer qu’une partie de leur GRT initial. Pour un rôle réseau avec un profil de risque plus faible, regardez la section sur les [Délégateurs](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. Un subgraph peut échouer à cause d'un bug. Un subgraph qui échoue n'accumule pas de frais de requête. Par conséquent, vous devrez attendre que le développeur corrige le bogue et déploie une nouvelle version.
    - Si vous êtes abonné à la version la plus récente d'un subgraph, vos parts migreront automatiquement vers cette nouvelle version. Cela entraînera une taxe de curation de 0,5 %.
    - Si vous avez signalé sur une version spécifique d'un subgraph et qu'elle échoue, vous devrez brûler manuellement vos parts de curation. Vous pouvez alors signaler sur la nouvelle version du subgraph, encourant ainsi une taxe de curation de 1%.

From 8f3ca144b9ea99b2d89aed5b044eaecea2f01256 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:27 -0500
Subject: [PATCH 3716/3820] New translations curating.mdx (Spanish)

---
 website/pages/es/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/resources/roles/curating.mdx b/website/pages/es/resources/roles/curating.mdx
index 892d9ee4d4b2..b7e8bfb1838b 100644
--- a/website/pages/es/resources/roles/curating.mdx
+++ b/website/pages/es/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. El mercado de consultas es inherentemente joven en The Graph y existe el riesgo de que su APY (Rentabilidad anualizada) sea más bajo de lo esperado debido a la dinámica del mercado que recién está empezando.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. Un subgrafo puede fallar debido a un error. Un subgrafo fallido no acumula tarifas de consulta. Como resultado, tendrás que esperar hasta que el desarrollador corrija el error e implemente una nueva versión.
    - Si estás suscrito a la versión más reciente de un subgrafo, tus acciones se migrarán automáticamente a esa nueva versión. Esto incurrirá un impuesto de curación del 0.5%.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From e9ca7bd3d00e2b91657028c882b3ca4466ed60a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:28 -0500
Subject: [PATCH 3717/3820] New translations curating.mdx (Arabic)

---
 website/pages/ar/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/resources/roles/curating.mdx b/website/pages/ar/resources/roles/curating.mdx
index 148a5fcf8f93..8a34a0150773 100644
--- a/website/pages/ar/resources/roles/curating.mdx
+++ b/website/pages/ar/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. سوق الاستعلام يعتبر حديثا في The Graph وهناك خطر من أن يكون٪ APY الخاص بك أقل مما تتوقع بسبب ديناميكيات السوق الناشئة.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. يمكن أن يفشل ال subgraph بسبب خطأ. ال subgraph الفاشل لا يمكنه إنشاء رسوم استعلام. نتيجة لذلك ، سيتعين عليك الانتظار حتى يصلح المطور الخطأ وينشر إصدارا جديدا.
    - إذا كنت مشتركا في أحدث إصدار من subgraph ، فسيتم ترحيل migrate أسهمك تلقائيا إلى هذا الإصدار الجديد. هذا سيتحمل ضريبة تنسيق بنسبة 0.5٪.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From db36f2ebec3e856756fc2f9850bf4effafa33e68 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:29 -0500
Subject: [PATCH 3718/3820] New translations curating.mdx (Czech)

---
 website/pages/cs/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/resources/roles/curating.mdx b/website/pages/cs/resources/roles/curating.mdx
index b66ccf5669ff..f516c3dae913 100644
--- a/website/pages/cs/resources/roles/curating.mdx
+++ b/website/pages/cs/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. Trh s dotazy je v Graf ze své podstaty mladý a existuje riziko, že vaše %APY může být nižší, než očekáváte, v důsledku dynamiky rodícího se trhu.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. Podgraf může selhat kvůli chybě. Za neúspěšný podgraf se neúčtují poplatky za dotaz. V důsledku toho budete muset počkat, až vývojář chybu opraví a nasadí novou verzi.
    - Pokud jste přihlášeni k odběru nejnovější verze podgrafu, vaše sdílené položky se automaticky přemigrují na tuto novou verzi. Při tom bude účtována 0,5% kurátorská daň.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 0231015c1560bd8bd9dba503711f2bf84bd87962 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:31 -0500
Subject: [PATCH 3719/3820] New translations curating.mdx (German)

---
 website/pages/de/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/resources/roles/curating.mdx b/website/pages/de/resources/roles/curating.mdx
index 083a279cad3d..36d3c1f8db3a 100644
--- a/website/pages/de/resources/roles/curating.mdx
+++ b/website/pages/de/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ Es wird jedoch empfohlen, dass Kuratoren ihr signalisiertes GRT bestehen lassen,
 
 1. Der Abfragemarkt ist bei The Graph noch sehr jung, und es besteht das Risiko, dass Ihr %APY aufgrund der noch jungen Marktdynamik niedriger ist als Sie erwarten.
 2. Kurationsgebühr - wenn ein Kurator GRT auf einem Subgraphen meldet, fällt eine Kurationsgebühr von 1% an. Diese Gebühr wird verbrannt.
-3. (Nur Ethereum) Wenn Kuratoren ihre Anteile verbrennen, um GRT abzuziehen, wird die GRT-Bewertung der verbleibenden Anteile reduziert. Bitte beachten Sie, dass Kuratoren in manchen Fällen beschließen können, ihre Anteile **alle auf einmal** zu verbrennen. Dies kann der Fall sein, wenn ein Dapp-Entwickler die Versionierung/Verbesserung und Abfrage seines Subgraphen einstellt oder wenn ein Subgraph ausfällt. Infolgedessen können die verbleibenden Kuratoren möglicherweise nur einen Bruchteil ihres ursprünglichen GRT abheben. Für eine Netzwerkrolle mit einem geringeren Risikoprofil siehe [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. Ein Subgraph kann aufgrund eines Fehlers fehlschlagen. Für einen fehlgeschlagenen Subgraph fallen keine Abfragegebühren an. Daher müssen Sie warten, bis der Entwickler den Fehler behebt und eine neue Version bereitstellt.
    - Wenn Sie die neueste Version eines Subgraphen abonniert haben, werden Ihre Anteile automatisch zu dieser neuen Version migriert. Dabei fällt eine Kurationsgebühr von 0,5 % an.
    - Wenn Sie für eine bestimmte Version eines Subgraphen ein Signal gegeben haben und dieses fehlschlägt, müssen Sie Ihre Kurationsanteile manuell verbrennen. Sie können dann ein Signal für die neue Subgraph-Version geben, wodurch eine Kurationssteuer von 1 % anfällt.

From fff5732ff3cbaa5034a00a8719c6b9018e46c7a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:32 -0500
Subject: [PATCH 3720/3820] New translations curating.mdx (Italian)

---
 website/pages/it/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/resources/roles/curating.mdx b/website/pages/it/resources/roles/curating.mdx
index 14cb8ca81f89..3d6259b5cb85 100644
--- a/website/pages/it/resources/roles/curating.mdx
+++ b/website/pages/it/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. Il mercato delle query è intrinsecamente giovane per The Graph e c'è il rischio che la vostra %APY possa essere inferiore a quella prevista a causa delle dinamiche di mercato nascenti.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. Un subgraph può fallire a causa di un bug. Un subgraph fallito non matura commissioni della query. Di conseguenza, si dovrà attendere che lo sviluppatore risolva il bug e distribuisca una nuova versione.
    - Se siete iscritti alla versione più recente di un subgraph, le vostre quote di partecipazione migreranno automaticamente a quella nuova versione. Questo comporta una tassa di curation di 0,5%.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 62396f7ab8241490afb6e5a23346116c14834a8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:34 -0500
Subject: [PATCH 3721/3820] New translations curating.mdx (Japanese)

---
 website/pages/ja/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/resources/roles/curating.mdx b/website/pages/ja/resources/roles/curating.mdx
index f0e7b5329cb4..085b633b448a 100644
--- a/website/pages/ja/resources/roles/curating.mdx
+++ b/website/pages/ja/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. The Graph では、クエリ市場は本質的に歴史が浅く、初期の市場ダイナミクスのために、あなたの%APY が予想より低くなるリスクがあります。
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. サブグラフはバグで失敗することがあります。 失敗したサブグラフは、クエリフィーが発生しません。 結果的に、開発者がバグを修正して新しいバージョンを展開するまで待たなければならなくなります。
    - サブグラフの最新バージョンに加入している場合、シェアはその新バージョンに自動移行します。 これには 0.5％のキュレーション税がかかります。
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 40f83b34cdd268d40fb97c67c0772d7328b9487d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:34 -0500
Subject: [PATCH 3722/3820] New translations curating.mdx (Korean)

---
 website/pages/ko/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/resources/roles/curating.mdx b/website/pages/ko/resources/roles/curating.mdx
index 8e6416b6d57e..b9488a834cb5 100644
--- a/website/pages/ko/resources/roles/curating.mdx
+++ b/website/pages/ko/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
    - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From bb17ae9a81c964a639fb0b758b6be8ad9c22244c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:36 -0500
Subject: [PATCH 3723/3820] New translations curating.mdx (Dutch)

---
 website/pages/nl/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/resources/roles/curating.mdx b/website/pages/nl/resources/roles/curating.mdx
index e7e30125d8d5..878c082528a5 100644
--- a/website/pages/nl/resources/roles/curating.mdx
+++ b/website/pages/nl/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. De querymarkt is nog jong bij het Graph Netwerk en er bestaat een risico dat je %APY lager kan zijn dan je verwacht door opkomende marktdynamiek.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. Een subgraph kan stuk gaan door een bug. Een subgraph die stuk is gegenereerd geen querykosten. Als gevolg hiervan moet je wachten tot de ontwikkelaar de bug repareert en een nieuwe versie implementeert.
    - Als je bent geabonneerd op de nieuwste versie van een subgraph, worden je curatieaandelen automatisch gemigreerd naar die nieuwe versie. Er is een curatiebelasting van 0,5%.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From e9ee0db4c042867a13f5bbd5b6408cb9d381b128 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:37 -0500
Subject: [PATCH 3724/3820] New translations curating.mdx (Polish)

---
 website/pages/pl/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/resources/roles/curating.mdx b/website/pages/pl/resources/roles/curating.mdx
index 8e6416b6d57e..b9488a834cb5 100644
--- a/website/pages/pl/resources/roles/curating.mdx
+++ b/website/pages/pl/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
    - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 8fc02a7f25ba789a323202f7c22f3ac920284f62 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:38 -0500
Subject: [PATCH 3725/3820] New translations curating.mdx (Russian)

---
 website/pages/ru/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/resources/roles/curating.mdx b/website/pages/ru/resources/roles/curating.mdx
index efb7d64887c0..28a892dc5de8 100644
--- a/website/pages/ru/resources/roles/curating.mdx
+++ b/website/pages/ru/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. Рынок запросов в The Graph по своей сути молод, и существует риск того, что ваш %APY может оказаться ниже, чем вы ожидаете, из-за зарождающейся динамики рынка.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. Подграф может выйти из строя из-за ошибки. За неудавшийся подграф не начисляется плата за запрос. В результате вам придется ждать, пока разработчик исправит ошибку и выложит новую версию.
    - Если вы подписаны на новейшую версию подграфа, ваши общие ресурсы автоматически перейдут на эту новую версию. При этом будет взиматься кураторская комиссия в размере 0,5%.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 3a4a1057e55cac579826273b92e1e0748665225c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:39 -0500
Subject: [PATCH 3726/3820] New translations curating.mdx (Swedish)

---
 website/pages/sv/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/resources/roles/curating.mdx b/website/pages/sv/resources/roles/curating.mdx
index 12561d349d05..29c1091e0b9c 100644
--- a/website/pages/sv/resources/roles/curating.mdx
+++ b/website/pages/sv/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. Frågemarknaden är i grunden ung på The Graph och det finns en risk att din %APY kan vara lägre än du förväntar dig på grund av tidiga marknadsmekanik.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. En subgraf kan misslyckas på grund av en bugg. En misslyckad subgraf genererar inte frågeavgifter. Som ett resultat måste du vänta tills utvecklaren rättar felet och distribuerar en ny version.
    - Om du prenumererar på den nyaste versionen av en subgraf kommer dina andelar automatiskt att migreras till den nya versionen. Detta kommer att medföra en kuratoravgift på 0,5%.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 75529399107fe85119729de985a9b53e7d514cf1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:40 -0500
Subject: [PATCH 3727/3820] New translations curating.mdx (Turkish)

---
 website/pages/tr/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/resources/roles/curating.mdx b/website/pages/tr/resources/roles/curating.mdx
index 7b1be8eea61b..959950f73c00 100644
--- a/website/pages/tr/resources/roles/curating.mdx
+++ b/website/pages/tr/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
    - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 84ebf4b63ce2472276377bc93293b3a53a654ba3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:42 -0500
Subject: [PATCH 3728/3820] New translations subgraph-debug-forking.mdx
 (Turkish)

---
 .../pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx    | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx
index 76ed17654120..edd1f48b90de 100644
--- a/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -97,5 +97,5 @@ $ cargo run -p graph-node --release -- \
 $ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020
 ```
 
-4. I inspect the logs produced by the local Graph Node and, Hooray!, everything seems to be working.
-5. I deploy my now bug-free subgraph to a remote Graph Node and live happily ever after! (no potatoes tho)
+4. Yerel Graph Düğümü tarafından üretilen günlükleri inceliyorum ve yaşasın! Her şey yolunda görünüyor.
+5. Artık hatasız olan `subgraph`imi uzak bir Graph Düğümü'nde dağıtıyorum ve sonsuza kadar mutlu yaşıyorum!

From 38c1793c433c6974d73cb00d52decb1718699c7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:43 -0500
Subject: [PATCH 3729/3820] New translations subgraph-uncrashable.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/subgraph-uncrashable.mdx   | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx
index 1a8229e80b08..eacc8522b564 100644
--- a/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx
+++ b/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -6,19 +6,19 @@ title: Güvenli Subgraph Kod Oluşturucu
 
 ## Neden Subgraph Uncrashable'ı entegre etmelisiniz?
 
-- **Continuous Uptime**. Mishandled entities may cause subgraphs to crash, which can be disruptive for projects that are dependent on The Graph. Set up helper functions to make your subgraphs “uncrashable” and ensure business continuity.
+- **Sürekli Çalışırlık**. Yanlış yönetilen varlıklar subgraph'lerin çökmesine neden olabilir. Bu da The Graph'e bağımlı olan projeler için işleri aksatabilir. Subgraph'lerinizi "çökmez" hale getirmek ve iş sürekliliğini sağlamak için yardımcı fonksiyonları ayarlayın.
 
 - **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
 
-- **User Configurable** Set default values and configure the level of security checks that suits your individual project's needs. Warning logs are recorded indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+- **Kullanıcı Tarafından Yapılandırılabilir** Varsayılan değerleri ayarlayın ve projenizin ihtiyaçlarına uygun güvenlik kontrol seviyesini yapılandırın. `Subgraph` mantığındaki bir ihlali gösteren uyarı günlükleri kaydedilir ve verilerin doğruluğunu sağlamak için sorunun giderilmesine yardımcı olunur.
 
-**Key Features**
+**Ana Özellikler**
 
-- The code generation tool accommodates **all** subgraph types and is configurable for users to set sane defaults on values. The code generation will use this config to generate helper functions that are to the users specification.
+- Kod oluşturma aracı, **tüm** subgraph türlerini destekler ve kullanıcıların değerlerde makul varsayılanlar ayarlamaları için yapılandırılabilir. Kod oluşturma, kullanıcıların belirtimine uygun yardımcı fonksiyonlar oluşturmak için bu yapılandırmayı kullanacaktır.
 
 - Framework ayrıca unsur değişkenleri grupları için özel, ancak güvenli ayarlayıcı fonksiyonları oluşturmanın bir yolunu (yapılandırma dosyası aracılığıyla) içerir. Bu sayede, kullanıcının eski bir graph unsurunu yüklemesi/kullanması ve ayrıca fonksiyonun gerektirdiği bir değişkeni kaydetmeyi veya ayarlamayı unutması imkansız hale gelir.
 
-- Warning logs are recorded as logs indicating where there is a breach of subgraph logic to help patch the issue to ensure data accuracy.
+- Uyarı günlükleri, subgraph mantığında bir ihlalin nerede olduğunu gösteren günlükler olarak kaydedilir ve veri doğruluğunu sağlamak için sorunun düzeltilmesine yardımcı olur.
 
 Subgraph Uncrashable, Graph CLI codegen komutu kullanılarak isteğe bağlı bir bayrak olarak çalıştırılabilir.
 
@@ -26,4 +26,4 @@ Subgraph Uncrashable, Graph CLI codegen komutu kullanılarak isteğe bağlı bir
 graph codegen -u [options] [<subgraph-manifest>]
 ```
 
-Daha fazla bilgi edinmek ve daha güvenli subgraph'ler geliştirmeye başlamak için [çökmeyen subgraph dokümantasyonuna](https://float-capital.github.io/float-subgraph-uncrashable/docs/) göz atın veya bu [video rehberini](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) izleyin.
+Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.

From d3a2c65a825f34d983fc85ff81130220bac59187 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:44 -0500
Subject: [PATCH 3730/3820] New translations transfer-to-the-graph.mdx
 (Turkish)

---
 .../cookbook/transfer-to-the-graph.mdx        | 60 +++++++++----------
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
index 9bcd190fed1e..334a7bef32df 100644
--- a/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -1,16 +1,16 @@
 ---
-title: Tranfer to The Graph
+title: The Graph'e Transfer
 ---
 
-Quickly upgrade your subgraphs from any platform to [The Graph's decentralized network](https://thegraph.com/networks/).
+Subgraph'lerinizi herhangi bir platformdan hızlıca [The Graph'in merkezi olmayan ağına](https://thegraph.com/networks/) yükseltin.
 
-## Benefits of Switching to The Graph
+## The Graph'e Geçmenin Avantajları
 
-- Use the same subgraph that your apps already use with zero-downtime migration.
+- Uygulamalarınızın zaten kullandığı subgraph'i kesinti yaşamadan aynı şekilde kullanabilirsiniz.
 - Increase reliability from a global network supported by 100+ Indexers.
 - Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
 
-## Upgrade Your Subgraph to The Graph in 3 Easy Steps
+## Subgraph'inizi The Graph'e 3 Kolay Adımda Yükseltin
 
 1. [Studio Ortamınızı Kurun](/subgraphs/cookbook/transfer-to-the-graph/#1-set-up-your-studio-environment)
 2. [Subgraph'inizi Studio'ya Dağıtın](/subgraphs/cookbook/transfer-to-the-graph/#2-deploy-your-subgraph-to-studio)
@@ -18,18 +18,18 @@ Quickly upgrade your subgraphs from any platform to [The Graph's decentralized n
 
 ## 1. Stüdyo Ortamınızı Ayarlayın
 
-### Create a Subgraph in Subgraph Studio
+### Subgraph Studio'da Bir Subgraph Oluştur
 
 - [Subgraph Studio](https://thegraph.com/studio/)'ya gidin ve cüzdanınızı bağlayın.
 - "Subgraph Oluştur" düğmesine tıklayın. Subgraph'in adını başlık formunda vermeniz önerilir: "Subgraph Adı Ağ Adı".
 
-> Note: After publishing, the subgraph name will be editable but requires onchain action each time, so name it properly.
+> Not: Yayımladıktan sonra subgraph ismi değiştirilebilir, ancak bunu yapmak her seferinde zincir üzerinde işlem gerektirir. Bu yüzden isim verirken iyi düşünün.
 
-### Install the Graph CLI⁠
+### Graph CLI'ı Yükle
 
-You must have [Node.js](https://nodejs.org/) and a package manager of your choice (`npm` or `pnpm`) installed to use the Graph CLI. Check for the [most recent](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI version.
+Graph CLI'ı kullanmak için [Node.js](https://nodejs.org/) ve tercih ettiğiniz bir paket yöneticisi (`npm` veya `pnpm`) kurulu olmalıdır. [En son](https://github.com/graphprotocol/graph-tooling/releases?q=%40graphprotocol%2Fgraph-cli&expanded=true) CLI sürümünü kontrol edin.
 
-On your local machine, run the following command:
+Yerel makinenizde şu komutu çalıştırın:
 
 [npm](https://www.npmjs.com/) kullanarak:
 
@@ -37,40 +37,40 @@ On your local machine, run the following command:
 npm install -g @graphprotocol/graph-cli@latest
 ```
 
-Use the following command to create a subgraph in Studio using the CLI:
+CLI kullanarak Studio'da subgraph oluşturmak için aşağıdaki komutu kullanın:
 
 ```sh
 graph init --product subgraph-studio
 ```
 
-### Authenticate Your Subgraph
+### Subgraph'inizi Doğrulayın
 
-In The Graph CLI, use the auth command seen in Subgraph Studio:
+The Graph CLI'da, Subgraph Studio'da görülen auth komutunu kullanın:
 
 ```sh
 graph auth <your-auth-code>
 ```
 
-## 2. Deploy Your Subgraph to Studio
+## 2. Subgraph'inizi Studio'ya Dağıtın
 
-If you have your source code, you can easily deploy it to Studio. If you don't have it, here's a quick way to deploy your subgraph.
+Kaynak kodunuz elinizdeyse kodunuzu Studio'ya kolayca dağıtabilirsiniz. Kaynak kodunuza sahip değilseniz, subgraph'inizi dağıtmanın hızlı yolunu aşağıda bulabilirsiniz.
 
-In The Graph CLI, run the following command:
+The Graph CLI'de aşağıdaki komutu çalıştırın:
 
 ```sh
 graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
 
 ```
 
-> **Note:** Every subgraph has an IPFS hash (Deployment ID), which looks like this: "Qmasdfad...". To deploy simply use this **IPFS hash**. You’ll be prompted to enter a version (e.g., v0.0.1).
+> **Not:** Her subgraph'in bir IPFS hash değeri (Dağıtım Kimliği) vardır ve bu şekilde görünür: "Qmasdfad...". Dağıtmak için bu **IPFS hash'ini** kullanmanız yeterlidir. Sizden bir versiyon girmeniz istenecektir (örneğin, v0.0.1).
 
-## 3. Publish Your Subgraph to The Graph Network
+## 3. Subgraph'inizi The Graph Ağı'nda Yayımlayın
 
-![publish button](/img/publish-sub-transfer.png)
+![yayımla butonu](/img/publish-sub-transfer.png)
 
-### Query Your Subgraph
+### Subgraph'inizi Sorgulayın
 
-> To attract about 3 indexers to query your subgraph, it’s recommended to curate at least 3,000 GRT. To learn more about curating, check out [Curating](/resources/roles/curating/) on The Graph.
+> Subgraph'inizi sorgulamak için yaklaşık üç endeksleyici çekmek için, en az 3000 GRT ile kürasyon yapmanız önerilir. Kürasyon hakkında daha fazla bilgi için, The Graph üzerindeki [Kürasyon](/resources/roles/curating/) sayfasına göz atın.
 
 You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
 
@@ -80,25 +80,25 @@ Messari tarafından hazırlanmış [CryptoPunks Ethereum subgraph'i](https://the
 
 ![Sorgu URL'si](/img/cryptopunks-screenshot-transfer.png)
 
-The query URL for this subgraph is:
+Bu subgraph için sorgu URL'si:
 
 ```sh
-https://gateway-arbitrum.network.thegraph.com/api/`**your-own-api-key**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
+https://gateway-arbitrum.network.thegraph.com/api/`**kendi-api-anahtarınız**`/subgraphs/id/HdVdERFUe8h61vm2fDyycgxjsde5PbB832NHgJfZNqK
 ```
 
-Now, you simply need to fill in **your own API Key** to start sending GraphQL queries to this endpoint.
+Artık, bu uç noktaya GraphQL sorguları göndermeye başlamak için **kendi API Anahtarınızı** girmeniz yeterlidir.
 
-### Getting your own API Key
+### Kendi API Anahtarınızı Almak
 
-You can create API Keys in Subgraph Studio under the “API Keys” menu at the top of the page:
+API Anahtarlarını Subgraph Studio'da sayfanın üst kısmındaki “API Anahtarları” menüsünden oluşturabilirsiniz:
 
 ![API anahtarları](/img/Api-keys-screenshot.png)
 
-### Monitor Subgraph Status
+### Subgraph Durumunu İzle
 
-Once you upgrade, you can access and manage your subgraphs in [Subgraph Studio](https://thegraph.com/studio/) and explore all subgraphs in [The Graph Explorer](https://thegraph.com/networks/).
+Yükseltme yaptıktan sonra, [Subgraph Studio](https://thegraph.com/studio/) üzerinde subgraph'lerinize erişip onları yönetebilirsiniz. Ayrıca, [The Graph Gezgini](https://thegraph.com/networks/) içindeki tüm subgraph'leri burada keşfedebilirsiniz.
 
 ### Ek Kaynaklar
 
-- To quickly create and publish a new subgraph, check out the [Quick Start](/subgraphs/quick-start/).
-- To explore all the ways you can optimize and customize your subgraph for a better performance, read more about [creating a subgraph here](/developing/creating-a-subgraph/).
+- Hızlı bir şekilde yeni bir subgraph oluşturmak ve yayımlamak için [Hızlı Başlangıç](/subgraphs/quick-start/) bölümüne göz atın.
+- Daha iyi bir performans için subgraph'inizi optimize etmenin ve özelleştirmenin tüm yollarını keşfetmek için [subgraph oluşturma](/developing/creating-a-subgraph/) hakkında daha fazla okuyun.

From 69f614a990361d61aa6162882b4bf9c0a1323c21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:45 -0500
Subject: [PATCH 3731/3820] New translations curating.mdx (Ukrainian)

---
 website/pages/uk/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/resources/roles/curating.mdx b/website/pages/uk/resources/roles/curating.mdx
index 1b9e3b14f609..d0f3c34a556c 100644
--- a/website/pages/uk/resources/roles/curating.mdx
+++ b/website/pages/uk/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. Ринок запитів за своєю суттю молодий в Graph, і існує ризик того, що ваш %APY може бути нижчим, ніж ви очікуєте, через динаміку ринку, що зароджується.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. Підграф може не працювати через різноманітні помилки (баги). Підграф, що не працює не стягує комісію за запити. В результаті вам доведеться почекати, поки розробник виправить усі помилки й випустить нову версію.
    - Якщо ви підключені до найновішої версії підграфу, ваші частки будуть автоматично перенесені до цієї нової версії. При цьому буде стягуватися податок на в розмірі 0,5%.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 4b8732c587ee116d6dc0247d62df7fb55ac5ec2f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:46 -0500
Subject: [PATCH 3732/3820] New translations curating.mdx (Chinese Simplified)

---
 website/pages/zh/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/resources/roles/curating.mdx b/website/pages/zh/resources/roles/curating.mdx
index 3bb4ed8d4181..b6a3de3cf888 100644
--- a/website/pages/zh/resources/roles/curating.mdx
+++ b/website/pages/zh/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. 在Graph，查询市场本来就很年轻，由于市场动态刚刚开始，你的年收益率可能低于你的预期，这是有风险的。
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. 一个子图可能由于错误而失败。 一个失败的子图不会累积查询费用。 因此，你必须等待，直到开发人员修复错误并部署一个新的版本。
    - 如果你订阅了一个子图的最新版本，你的份额将自动迁移到该新版本。 这将产生 0.5%的策展税。
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From cb7c691d087ac1c552cc3ba11d39758a43eae29c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:47 -0500
Subject: [PATCH 3733/3820] New translations curating.mdx (Urdu (Pakistan))

---
 website/pages/ur/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/resources/roles/curating.mdx b/website/pages/ur/resources/roles/curating.mdx
index 5463a994ebd7..a6218a11dc9b 100644
--- a/website/pages/ur/resources/roles/curating.mdx
+++ b/website/pages/ur/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. گراف میں کیوری کی مارکیٹ فطری طور پر جوان ہے اور اس بات کا خطرہ ہے کہ آپ کا %APY مارکیٹ کی نئی حرکیات کی وجہ سے آپ کی توقع سے کم ہو سکتا ہے.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. ایک سب گراف ایک بگ کی وجہ سے ناکام ہو سکتا ہے. ایک ناکام سب گراف کیوری کی فیس جمع نہیں کرتا ہے. اس کے نتیجے میں،آپ کو انتظار کرنا پڑے گاجب تک کہ ڈویلپر اس بگ کو کو ٹھیک نہیں کرتا اور نیا ورژن تعینات کرتا ہے.
    - اگر آپ نےسب گراف کے نۓ ورژن کو سبسکرائب کیا ہے. آپ کے حصص خود بخود اس نئے ورژن میں منتقل ہو جائیں گے۔ اس پر 0.5% کیوریشن ٹیکس لگے گا.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 3ae5b28a5e47b6213df47d0a51072e6de34f8344 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:49 -0500
Subject: [PATCH 3734/3820] New translations curating.mdx (Vietnamese)

---
 website/pages/vi/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/resources/roles/curating.mdx b/website/pages/vi/resources/roles/curating.mdx
index 4cecc4b549e6..a9b2a5a934d8 100644
--- a/website/pages/vi/resources/roles/curating.mdx
+++ b/website/pages/vi/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. Một subgraph có thể thất bại do một lỗi. Một subgraph thất bại không tích lũy phí truy vấn. Do đó, bạn sẽ phải đợi cho đến khi nhà phát triển sửa lỗi và triển khai phiên bản mới.
    - Nếu bạn đã đăng ký phiên bản mới nhất của một subgraph, các cổ phần của bạn sẽ tự động chuyển sang phiên bản mới đó. Điều này sẽ phát sinh một khoản thuế curation 0.5%.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From c564e7c0ff25c004e33028cca0b5490190e24a76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:50 -0500
Subject: [PATCH 3735/3820] New translations curating.mdx (Marathi)

---
 website/pages/mr/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/resources/roles/curating.mdx b/website/pages/mr/resources/roles/curating.mdx
index bbb551af354d..6414dda6d2ac 100644
--- a/website/pages/mr/resources/roles/curating.mdx
+++ b/website/pages/mr/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. द ग्राफमध्ये क्वेरी मार्केट मूळतः तरुण आहे आणि नवीन मार्केट डायनॅमिक्समुळे तुमचा %APY तुमच्या अपेक्षेपेक्षा कमी असण्याचा धोका आहे.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. बगमुळे सबग्राफ अयशस्वी होऊ शकतो. अयशस्वी सबग्राफ क्वेरी शुल्क जमा करत नाही. परिणामी, विकसक बगचे निराकरण करेपर्यंत आणि नवीन आवृत्ती तैनात करेपर्यंत तुम्हाला प्रतीक्षा करावी लागेल.
    - तुम्ही सबग्राफच्या नवीनतम आवृत्तीचे सदस्यत्व घेतले असल्यास, तुमचे शेअर्स त्या नवीन आवृत्तीमध्ये स्वयंचलितपणे स्थलांतरित होतील. यावर 0.5% क्युरेशन कर लागेल.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 13e70ac4d424d392e1b7e7329d3a245e91543f21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:51 -0500
Subject: [PATCH 3736/3820] New translations curating.mdx (Hindi)

---
 website/pages/hi/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/resources/roles/curating.mdx b/website/pages/hi/resources/roles/curating.mdx
index 496532260336..47c3c0efb658 100644
--- a/website/pages/hi/resources/roles/curating.mdx
+++ b/website/pages/hi/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. क्वेरी बाजार द ग्राफ में स्वाभाविक रूप से युवा है और इसमें जोखिम है कि नवजात बाजार की गतिशीलता के कारण आपका %APY आपकी अपेक्षा से कम हो सकता है।
 2. क्यूरेशन शुल्क  - जब कोई क्यूरेटर किसी सबग्राफ़ पर GRT सिग्नल करता है, तो उसे 1% क्यूरेशन टैक्स देना होता है। यह शुल्क जला दिया जाता है।
-3. (Ethereum only) जब curators अपने शेयर जलाकर GRT निकालते हैं, तो बची हुई शेयरों की GRT वैल्यूएशन घट जाएगी। ध्यान दें कि कुछ मामलों में, curators अपने शेयर एक बार में जला सकते हैं। यह स्थिति आम हो सकती है यदि कोई dapp डेवलपर अपने subgraph का वर्शनिंग/इंप्रूविंग और queries करना बंद कर देता है या यदि कोई subgraph फेल हो जाता है। नतीजतन, बचे हुए curators केवल अपने प्रारंभिक GRT का एक हिस्सा निकालने में सक्षम हो सकते हैं। एक कम जोखिम वाले नेटवर्क रोल के लिए, देखें [Delegators](/resources/roles/delegating/)।
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. बग के कारण सबग्राफ विफल हो सकता है। एक विफल सबग्राफ क्वेरी शुल्क अर्जित नहीं करता है। नतीजतन, आपको तब तक इंतजार करना होगा जब तक कि डेवलपर बग को ठीक नहीं करता है और एक नया संस्करण तैनात करता है।
    - यदि आपने सबग्राफ के नवीनतम संस्करण की सदस्यता ली है, तो आपके शेयर उस नए संस्करण में स्वत: माइग्रेट हो जाएंगे। इस पर 0.5% क्यूरेशन टैक्स लगेगा।
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 155661abebe4236ac005433de4806a6260a86144 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:52 -0500
Subject: [PATCH 3737/3820] New translations curating.mdx (Swahili)

---
 website/pages/sw/resources/roles/curating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/resources/roles/curating.mdx b/website/pages/sw/resources/roles/curating.mdx
index 8e6416b6d57e..b9488a834cb5 100644
--- a/website/pages/sw/resources/roles/curating.mdx
+++ b/website/pages/sw/resources/roles/curating.mdx
@@ -48,7 +48,7 @@ However, it is recommended that curators leave their signaled GRT in place not o
 
 1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
 2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
-3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/).
+3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
 4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
    - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
    - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.

From 6b735033a567818d4cca2c07e152e384eedf02c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:53 -0500
Subject: [PATCH 3738/3820] New translations undelegating.mdx (Romanian)

---
 website/pages/ro/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ro/resources/roles/delegating/undelegating.mdx b/website/pages/ro/resources/roles/delegating/undelegating.mdx
index f363d7449bb5..6a361c508450 100644
--- a/website/pages/ro/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/ro/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Additional Resources
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 37380f53aa23846d8bf0b7f81feeea6fbba2e605 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:54 -0500
Subject: [PATCH 3739/3820] New translations undelegating.mdx (French)

---
 website/pages/fr/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/fr/resources/roles/delegating/undelegating.mdx b/website/pages/fr/resources/roles/delegating/undelegating.mdx
index 7f3fc5acbc71..2fadb116424e 100644
--- a/website/pages/fr/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/fr/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Ressources supplémentaires
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 4ff07947b8c8ae06d540b6fd040c24032a0a38c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:56 -0500
Subject: [PATCH 3740/3820] New translations undelegating.mdx (Spanish)

---
 website/pages/es/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/es/resources/roles/delegating/undelegating.mdx b/website/pages/es/resources/roles/delegating/undelegating.mdx
index 128da3825fd4..4d06fe0e1b37 100644
--- a/website/pages/es/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/es/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Recursos Adicionales
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From eb5473645daa850a0eaf30e11330e3ed7ebc37af Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:57 -0500
Subject: [PATCH 3741/3820] New translations undelegating.mdx (Arabic)

---
 website/pages/ar/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ar/resources/roles/delegating/undelegating.mdx b/website/pages/ar/resources/roles/delegating/undelegating.mdx
index 41482fef671d..0756092ea10e 100644
--- a/website/pages/ar/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/ar/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## مصادر إضافية
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 765c05c875908e2bf10ab2007fdbf6f11178b1db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:58 -0500
Subject: [PATCH 3742/3820] New translations undelegating.mdx (Czech)

---
 website/pages/cs/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/cs/resources/roles/delegating/undelegating.mdx b/website/pages/cs/resources/roles/delegating/undelegating.mdx
index d14e35049efe..bc98d6aeff17 100644
--- a/website/pages/cs/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/cs/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Další zdroje
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From f322c28bb6d6a604ffa8677f518f7b66bc8c756e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:24:59 -0500
Subject: [PATCH 3743/3820] New translations undelegating.mdx (German)

---
 website/pages/de/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/resources/roles/delegating/undelegating.mdx b/website/pages/de/resources/roles/delegating/undelegating.mdx
index f4fda7c28412..2a8db6bdc345 100644
--- a/website/pages/de/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/de/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Zusätzliche Ressourcen
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 328d089785bef0c810ab94f7b86a0b83f783205b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:01 -0500
Subject: [PATCH 3744/3820] New translations undelegating.mdx (Italian)

---
 website/pages/it/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/it/resources/roles/delegating/undelegating.mdx b/website/pages/it/resources/roles/delegating/undelegating.mdx
index f363d7449bb5..6a361c508450 100644
--- a/website/pages/it/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/it/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Additional Resources
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From e4c9e2a240acc3f3597bb4b3046c4059af05a4fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:02 -0500
Subject: [PATCH 3745/3820] New translations undelegating.mdx (Japanese)

---
 website/pages/ja/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ja/resources/roles/delegating/undelegating.mdx b/website/pages/ja/resources/roles/delegating/undelegating.mdx
index e89841170428..ecc6f27f0bb0 100644
--- a/website/pages/ja/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/ja/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## その他のリソース
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 5416bf143effdf5ba8c4bd8aa55b919ea3960068 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:03 -0500
Subject: [PATCH 3746/3820] New translations undelegating.mdx (Korean)

---
 website/pages/ko/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ko/resources/roles/delegating/undelegating.mdx b/website/pages/ko/resources/roles/delegating/undelegating.mdx
index f363d7449bb5..6a361c508450 100644
--- a/website/pages/ko/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/ko/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Additional Resources
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From d8d6958e2a4deeb1f74553733ae47451ddb413ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:05 -0500
Subject: [PATCH 3747/3820] New translations undelegating.mdx (Dutch)

---
 website/pages/nl/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/nl/resources/roles/delegating/undelegating.mdx b/website/pages/nl/resources/roles/delegating/undelegating.mdx
index f363d7449bb5..6a361c508450 100644
--- a/website/pages/nl/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/nl/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Additional Resources
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 598c4e23ae1d94c3a03d7d3c4cdc3b52a557d2a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:06 -0500
Subject: [PATCH 3748/3820] New translations undelegating.mdx (Polish)

---
 website/pages/pl/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pl/resources/roles/delegating/undelegating.mdx b/website/pages/pl/resources/roles/delegating/undelegating.mdx
index f363d7449bb5..6a361c508450 100644
--- a/website/pages/pl/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/pl/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Additional Resources
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 869bcea12840c2227a4402a92fafa9180ce4c734 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:07 -0500
Subject: [PATCH 3749/3820] New translations undelegating.mdx (Portuguese)

---
 website/pages/pt/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/resources/roles/delegating/undelegating.mdx b/website/pages/pt/resources/roles/delegating/undelegating.mdx
index baba45591a95..2a3a68fba452 100644
--- a/website/pages/pt/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/pt/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Outros Recursos
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 60dbef6599060e0b4b83f206f0872862220babeb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:08 -0500
Subject: [PATCH 3750/3820] New translations undelegating.mdx (Russian)

---
 website/pages/ru/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ru/resources/roles/delegating/undelegating.mdx b/website/pages/ru/resources/roles/delegating/undelegating.mdx
index c9fd2c7b2da4..32a98bccc4c4 100644
--- a/website/pages/ru/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/ru/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Дополнительные ресурсы
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 33d3f4c3757da5f1c2b72ad1eedee1426191a872 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:10 -0500
Subject: [PATCH 3751/3820] New translations undelegating.mdx (Swedish)

---
 website/pages/sv/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sv/resources/roles/delegating/undelegating.mdx b/website/pages/sv/resources/roles/delegating/undelegating.mdx
index ec3a561ec4aa..0363867230e5 100644
--- a/website/pages/sv/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/sv/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Ytterligare resurser
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 61a64b3fff9adcf76702f980e484e03f1931be98 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:11 -0500
Subject: [PATCH 3752/3820] New translations undelegating.mdx (Turkish)

---
 website/pages/tr/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/resources/roles/delegating/undelegating.mdx b/website/pages/tr/resources/roles/delegating/undelegating.mdx
index 14fde5daae0a..96d0a9ae5ca1 100644
--- a/website/pages/tr/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/tr/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Ek Kaynaklar
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 2e489b97e43c4bb5c2d7cdbe59d579f4ef94f439 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:13 -0500
Subject: [PATCH 3753/3820] New translations undelegating.mdx (Ukrainian)

---
 website/pages/uk/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/uk/resources/roles/delegating/undelegating.mdx b/website/pages/uk/resources/roles/delegating/undelegating.mdx
index b357c3a2da3d..5a2274dcc122 100644
--- a/website/pages/uk/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/uk/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Додаткові матеріали
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 16cfc7bacd4581db2438998990b7ef85b1608838 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:14 -0500
Subject: [PATCH 3754/3820] New translations undelegating.mdx (Chinese
 Simplified)

---
 website/pages/zh/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/resources/roles/delegating/undelegating.mdx b/website/pages/zh/resources/roles/delegating/undelegating.mdx
index 283a74782381..82bc3e4707d3 100644
--- a/website/pages/zh/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/zh/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## 其他资源
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From b565c5ea63a8f9b40df7e2fc0ea5df915b0c7804 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:15 -0500
Subject: [PATCH 3755/3820] New translations undelegating.mdx (Urdu (Pakistan))

---
 website/pages/ur/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/ur/resources/roles/delegating/undelegating.mdx b/website/pages/ur/resources/roles/delegating/undelegating.mdx
index 1cf6d59f7b0f..f14893b969c1 100644
--- a/website/pages/ur/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/ur/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## اضافی وسائل
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 4be074eb22fcd98c27964dffdd402c370b2a8af2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:17 -0500
Subject: [PATCH 3756/3820] New translations undelegating.mdx (Vietnamese)

---
 website/pages/vi/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/vi/resources/roles/delegating/undelegating.mdx b/website/pages/vi/resources/roles/delegating/undelegating.mdx
index f363d7449bb5..6a361c508450 100644
--- a/website/pages/vi/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/vi/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Additional Resources
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 52530f831ca73e05704d6c8ee7ce244d99743df4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:18 -0500
Subject: [PATCH 3757/3820] New translations undelegating.mdx (Marathi)

---
 website/pages/mr/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/mr/resources/roles/delegating/undelegating.mdx b/website/pages/mr/resources/roles/delegating/undelegating.mdx
index 82219c3da93c..7e73cae007df 100644
--- a/website/pages/mr/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/mr/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## अतिरिक्त संसाधने
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 60e3ca446ccb78fb220d9efe06c7aa552a05b406 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:19 -0500
Subject: [PATCH 3758/3820] New translations undelegating.mdx (Hindi)

---
 website/pages/hi/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/hi/resources/roles/delegating/undelegating.mdx b/website/pages/hi/resources/roles/delegating/undelegating.mdx
index 6b6177b83faf..aa37e2d4bd1c 100644
--- a/website/pages/hi/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/hi/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Additional Resources
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From e34aa159a2b8f384ad18255377bb12d9e97f0a96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 13:25:20 -0500
Subject: [PATCH 3759/3820] New translations undelegating.mdx (Swahili)

---
 website/pages/sw/resources/roles/delegating/undelegating.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/sw/resources/roles/delegating/undelegating.mdx b/website/pages/sw/resources/roles/delegating/undelegating.mdx
index f363d7449bb5..6a361c508450 100644
--- a/website/pages/sw/resources/roles/delegating/undelegating.mdx
+++ b/website/pages/sw/resources/roles/delegating/undelegating.mdx
@@ -66,4 +66,4 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 
 ## Additional Resources
 
-To delegate successfully, review the [delegating documentation](/resources/roles/delegating/) and check out the delegate section in Graph Explorer.
+To delegate successfully, review the [delegating documentation](/resources/roles/delegating/delegating/) and check out the delegate section in Graph Explorer.

From 74a19578cf8660ba06051459454c882cdcff863a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 16:12:49 -0500
Subject: [PATCH 3760/3820] New translations near.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/near.mdx | 38 ++++++++++----------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/near.mdx b/website/pages/tr/subgraphs/cookbook/near.mdx
index 493bd0c44739..bfc00c9b02ce 100644
--- a/website/pages/tr/subgraphs/cookbook/near.mdx
+++ b/website/pages/tr/subgraphs/cookbook/near.mdx
@@ -10,7 +10,7 @@ Bu rehber, [NEAR blokzinciri](https://docs.near.org/) üzerindeki akıllı sözl
 
 ## NEAR subgraphları nedir?
 
-The Graph gives developers tools to process blockchain events and make the resulting data easily available via a GraphQL API, known individually as a subgraph. [Graph Node](https://github.com/graphprotocol/graph-node) is now able to process NEAR events, which means that NEAR developers can now build subgraphs to index their smart contracts.
+The Graph, geliştiricilere blokzinciri olaylarını işleyip, sonuçtaki veriyi bir GraphQL API'ı (subgraph olarak da bilinir) aracılığıyla kolayca erişilebilir kılacak araçlar sunar. [Graph Düğümü](https://github.com/graphprotocol/graph-node) artık NEAR olaylarını işleyebiliyor, bu da NEAR geliştiricilerinin akıllı sözleşmelerini endekslemek için subgraph'ler oluşturabileceği anlamına gelir.
 
 Subgraph'ler olay tabanlıdır., yani zincir üzerindeki olayları dinler ve sonrasında işlerler. Şu anda NEAR subgraph'leri için desteklenen iki tür işleyici bulunmaktadır:
 
@@ -70,10 +70,10 @@ dataSources:
       file: ./src/mapping.ts # Assemblyscript eşleştirmelerinin bulunduğu dosyaya bağlantı
 ```
 
-- NEAR subgraphs introduce a new `kind` of data source (`near`)
-- The `network` should correspond to a network on the hosting Graph Node. On Subgraph Studio, NEAR's mainnet is `near-mainnet`, and NEAR's testnet is `near-testnet`
+- NEAR subgraph'leri yeni bir veri kaynağı `kind`'ı (türü) sunar (`near`)
+- `network`, subgraph'i sunan Graph Düğümü üzerindeki bir ağa karşılık gelmelidir. Subgraph Studio'da, NEAR'ın ana ağı `near-mainnet`, ve NEAR'ın test ağı `near-testnet`'tir
 - NEAR veri kaynakları, [NEAR hesabı](https://docs.near.org/concepts/protocol/account-model) ile ilişkili, insan tarafından okunabilir bir kimlik olan isteğe bağlı `source.account` alanını sunar. Bu, bir hesap veya alt hesap olabilir.
-- NEAR data sources introduce an alternative optional `source.accounts` field, which contains optional suffixes and prefixes. At least prefix or suffix must be specified, they will match the any account starting or ending with the list of values respectively. The example below would match: `[app|good].*[morning.near|morning.testnet]`. If only a list of prefixes or suffixes is necessary the other field can be omitted.
+- NEAR veri kaynakları, isteğe bağlı ek `source.accounts` alanını tanıtır. Bu alan isteğe bağlı sonekler ve önekler içerir. En azından bir önek veya sonek belirtilmelidir. Bu ekler ilgili listedeki değerlerle başlayan veya biten herhangi bir hesabı eşleştirirler. Aşağıdaki örnek şunlarla eşleşecektir: `[app|good].*[morning.near|morning.testnet]`. Sadece önekler veya sonekler listesi gerekiyorsa diğer alan atlanabilir.
 
 ```yaml
 accounts:
@@ -88,7 +88,7 @@ accounts:
 NEAR veri kaynakları iki tür işleyiciyi destekler:
 
 - `blockHandlers`: her yeni NEAR blokunda çalıştırılır. `source.account` gerekli değildir.
-- `receiptHandlers`: run on every receipt where the data source's `source.account` is the recipient. Note that only exact matches are processed ([subaccounts](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) must be added as independent data sources).
+- `receiptHandlers`: veri kaynağının `source.account`'unun alıcı olduğu her makbuzda çalışır. Makbuz (receipt) teknik bir kavramdır, daha detaylı bilgi için NEAR dokümanlarını inceleyebilirsiniz. Bu noktada, yalnızca tam eşleşmelerin işlendiğine dikkat edin. ([Alt hesaplar](https://docs.near.org/tutorials/crosswords/basics/add-functions-call#create-a-subaccount) bağımsız veri kaynakları olarak eklenmelidir).
 
 ### Şema Tanımı
 
@@ -160,33 +160,33 @@ class ReceiptWithOutcome {
   }
 ```
 
-These types are passed to block & receipt handlers:
+Bu türler blok & makbuz işleyicilerine aktarılır:
 
 - Blok işleyiciler bir `Block` alacaktır
-- Receipt handlers will receive a `ReceiptWithOutcome`
+- Makbuz işleyiciler bir `ReceiptWithOutcome` alacaktır
 
-Otherwise, the rest of the [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/) is available to NEAR subgraph developers during mapping execution.
+Aksi takdirde, NEAR subgraph geliştiricileri eşleme yürütme sırasında [AssemblyScript API](/subgraphs/developing/creating/graph-ts/api/)'ının geri kalanını kullanabilir.
 
-This includes a new JSON parsing function - logs on NEAR are frequently emitted as stringified JSONs. A new `json.fromString(...)` function is available as part of the [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) to allow developers to easily process these logs.
+Bu, yeni bir JSON ayrıştırma fonksiyonunu içerir - NEAR üzerindeki günlükler sıklıkla dizeleştirilmiş JSON olarak yayılır. Geliştiricilerin bu günlükleri kolayca işlemelerine olanak tanımak için [JSON API](/subgraphs/developing/creating/graph-ts/api/#json-api) kapsamında yeni bir `json.fromString(...)` fonksiyonu mevcuttur.
 
 ## NEAR Subgraph'ını Dağıtma
 
-Once you have a built subgraph, it is time to deploy it to Graph Node for indexing. NEAR subgraphs can be deployed to any Graph Node `>=v0.26.x` (this version has not yet been tagged & released).
+Bir subgraph'i oluşturduktan sonra sıradaki adım bu subgraph'i endeksleme için Graph Düğümü'ne dağıtmaktır. NEAR subgraph'leri, herhangi bir Graph Düğümü `>=v0.26.x` sürümüne dağıtılabilir (bu sürüm henüz etiketlenmemiş ve yayımlanmamıştır).
 
-Subgraph Studio and the upgrade Indexer on The Graph Network currently supports indexing NEAR mainnet and testnet in beta, with the following network names:
+The Graph Ağı'ndaki Subgraph Studio ve yükseltme Endeksleyicisi şu anda beta olarak NEAR ana ağı ve test ağını endekslemeyi, aşağıdaki ağ isimleriyle desteklemektedir:
 
 - `near-mainnet`
 - `near-testnet`
 
-More information on creating and deploying subgraphs on Subgraph Studio can be found [here](/deploying/deploying-a-subgraph-to-studio/).
+Subgraph Studio'da subgraph'ler oluşturma ve dağıtma hakkında daha fazla bilgi [burada](/deploying/deploying-a-subgraph-to-studio/) bulunabilir.
 
-As a quick primer - the first step is to "create" your subgraph - this only needs to be done once. On Subgraph Studio, this can be done from [your Dashboard](https://thegraph.com/studio/): "Create a subgraph".
+Kısa bir ön bilgi olarak - ilk adım subgraph'inizi "oluşturmak"tır - bu sadece bir kez yapılması gereken bir işlemdir. Subgraph Studio'da, [Gösterge Paneliniz](https://thegraph.com/studio/)'deki "Bir subgraph oluştur" kısmında yapılabilir.
 
 Subgraph oluşturulduktan sonra, `graph deploy` CLI komutunu kullanarak subgraph'inizi dağıtabilirsiniz:
 
 ```sh
-$ graph create --node <graph-node-url> <subgraph-name> # creates a subgraph on a local Graph Node (on Subgraph Studio, this is done via the UI)
-$ graph deploy --node <graph-node-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-name> # uploads the build files to a specified IPFS endpoint, and then deploys the subgraph to a specified Graph Node based on the manifest IPFS hash
+$ graph create --node <graph-düğümü-url> <subgraph-ismi> # yerel bir Graph Düğümünde bir subgraph oluşturur (Subgraph Studio'da, bu işlem UI üzerinden yapılır)
+$ graph deploy --node <graph-düğümü-url> --ipfs https://api.thegraph.com/ipfs/ <subgraph-ismi> # manifesto IPFS hash'ine göre belirtilen bir Graph Düğümü'ne subgraph'i dağıtır ve yapım dosyalarını belirtilen IPFS uç noktasına yükler
 ```
 
 Düğüm yapılandırması, subgraph'ın nerede dağıtıldığına bağlı olacaktır.
@@ -195,13 +195,13 @@ Düğüm yapılandırması, subgraph'ın nerede dağıtıldığına bağlı olac
 
 ```sh
 graph auth
-graph deploy <subgraph-name>
+graph deploy <subgraph-ismi>
 ```
 
 ### Yerel Graph Düğümü (varsayılan yapılandırmaya göre)
 
 ```sh
-graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-name>
+graph deploy --node http://localhost:8020/ --ipfs http://localhost:5001 <subgraph-ismi>
 ```
 
 Subgraph'ınız dağıtıldıktan sonra Graph Düğüme tarafından indekslenecektir. Subgraph'ın kendisini sorgulayarak ilerlemesini kontrol edebilirsiniz:
@@ -236,7 +236,7 @@ Aşağıda bazı örnek subgraph'leri bulabilirsiniz:
 
 [NEAR Blokları](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-blocks)
 
-[NEAR Receipts](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
+[NEAR Makbuzları](https://github.com/graphprotocol/graph-tooling/tree/main/examples/near-receipts)
 
 ## SSS
 
@@ -254,7 +254,7 @@ Hayır, bir subgraph yalnızca bir zincirden/ağdan veri kaynaklarını destekle
 
 ### Makbuz işleyicileri hesaplar ve bunların alt hesapları için tetiklenecek mi?
 
-If an `account` is specified, that will only match the exact account name. It is possible to match sub-accounts by specifying an `accounts` field, with `suffixes` and `prefixes` specified to match accounts and sub-accounts, for example the following would match all `mintbase1.near` sub-accounts:
+Bir `account` belirtildiyse, yalnızca tam hesap adı eşleştirilecektir. `accounts` alanı belirterek alt hesapları eşleştirmek mümkündür. `suffixes` (önekleri) ve `prefixes`'i (sonekleri) ve `accounts` alanını da belirterek, alt hesapları eşleştirmek mümkündür. Örneğin, aşağıdaki `mintbase1.near` alt hesaplarının tümünü eşleştirecektir:
 
 ```yaml
 accounts:

From a76d52bd8418a3567f7799a9353365d954e73999 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 16:12:51 -0500
Subject: [PATCH 3761/3820] New translations grafting-hotfix.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
index f2beff0c3197..2001c7ba19ee 100644
--- a/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
+++ b/website/pages/tr/subgraphs/cookbook/grafting-hotfix.mdx
@@ -58,7 +58,7 @@ Bu özellik, kritik sorunlar için hızlı bir şekilde düzeltmelerin dağıtı
 
 Bir akıllı sözleşmeyi takip eden ve kritik bir hata nedeniyle endekslemeyi durdurmuş bir subgraph'e sahip olduğunuzu varsayalım. Bu durumda acil güncelleme dağıtmak için aşılamayı nasıl kullanabileceğiniz aşağıda açıklanmıştır.
 
-1. **Failed Subgraph Manifest (subgraph.yaml)**
+1. **Hata Veren Subgraph Manifestosu (subgraph.yaml)**
 
    ```yaml
    specVersion: 1.0.0
@@ -87,7 +87,7 @@ Bir akıllı sözleşmeyi takip eden ve kritik bir hata nedeniyle endekslemeyi d
          file: ./src/old-lock.ts
    ```
 
-2. **New Grafted Subgraph Manifest (subgraph.yaml)**
+2. **Yeni Aşılanmış Subgraph Manifestosu (subgraph.yaml)**
    ```yaml
    specVersion: 1.0.0
    schema:
@@ -130,14 +130,14 @@ Bir akıllı sözleşmeyi takip eden ve kritik bir hata nedeniyle endekslemeyi d
 
 3. **Dağıtım Adımları**
 
-   - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
+   - **Kodu Güncelleyin**: eşleme kodlarınıza (örneğin, handleWithdrawal kısmına) acil güncelleme uygulayın.
    - **Manifestoyu Ayarlayın**: Yukarıda gösterildiği gibi, `subgraph.yaml` dosyasını aşılama yapılandırmalarıyla güncelleyin.
    - **Subgraph'i Dağıtın**:
      - Graph CLI ile kimlik doğrulaması yapın.
      - `graph deploy` komutunu kullanarak yeni subgraph'i dağıtın.
 
 4. **Dağıtım Sonrası**
-   - **Verify Indexing**: Check that the subgraph is indexing correctly from the graft point.
+   - **Endekslemeyi Doğrulama**: Subgraph'in aşılanma noktasından itibaren doğru endekslendiğinden emin olun.
    - **Veriyi Takip Etme**: Yeni verilerin yakalandığından ve acil güncellemenin etkili olduğundan emin olun.
    - **Yeniden Yayımlama İçin Planlama**: Uzun süreli istikrar için aşılama yapılmamış sürümün dağıtımını planlayın.
 

From e55739753dbe49e66de3d301d1d71ce9e285f594 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 16:12:52 -0500
Subject: [PATCH 3762/3820] New translations
 immutable-entities-bytes-as-ids.mdx (Turkish)

---
 .../immutable-entities-bytes-as-ids.mdx        | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
index e33decda9b58..fa704e33b10d 100644
--- a/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
+++ b/website/pages/tr/subgraphs/cookbook/immutable-entities-bytes-as-ids.mdx
@@ -44,17 +44,17 @@ type Transfer @entity(immutable: true) {
 }
 ```
 
-While other types for IDs are possible, such as String and Int8, it is recommended to use the Bytes type for all IDs due to character strings taking twice as much space as Byte strings to store binary data, and comparisons of UTF-8 character strings must take the locale into account which is much more expensive than the bytewise comparison used to compare Byte strings.
+ID'ler için String ve Int8 gibi başka türler kullanmak mümkün olsa da, tüm ID'ler için Bytes türünün kullanılması önerilir. Çünkü karakter dizileri ikili (binary) verileri saklamak için Bayt dizilerinden iki kat fazla yer kaplar. Ayrıca, UTF-8 karakter dizilerinin karşılaştırmaları, yerel ayarı hesaba katması gerekliliğinden ötürü, Bayt dizilerinin karşılaştırmalarında kullanılan bayt temelli (bytewise) karşılaştırmalardan çok daha maliyetlidir.
 
-### Reasons to Not Use Bytes as IDs
+### ID Olarak Bytes Kullanmama Nedenleri
 
-1. If entity IDs must be human-readable such as auto-incremented numerical IDs or readable strings, Bytes for IDs should not be used.
-2. If integrating a subgraph’s data with another data model that does not use Bytes as IDs, Bytes as IDs should not be used.
-3. Indexing and querying performance improvements are not desired.
+1. Eğer varlık ID'leri otomatik artırılan sayısal ID'ler veya okunabilir dizeler gibi insan tarafından okunabilir olmalıysa, ID için Bytes kullanılmamalıdır.
+2. Bir subgraph'in verilerini Bytes'ı ID olarak kullanmayan başka bir veri modeliyle entegre ediyorsanız, ID için Bayt kullanılmamalıdır.
+3. Endeksleme ve sorgulama gibi performans iyileştirmeleri istenmiyorsa.
 
-### Concatenating With Bytes as IDs
+### ID Olarak Bytes'ı Başka Bir Özellikle Birleştirme
 
-It is a common practice in many subgraphs to use string concatenation to combine two properties of an event into a single ID, such as using `event.transaction.hash.toHex() + "-" + event.logIndex.toString()`. However, as this returns a string, this significantly impedes subgraph indexing and querying performance.
+Birçok subgraph'te, bir olayın iki özelliğini tek bir ID'de birleştirmek için dizi birleştirme kullanmak yaygın bir uygulamadır: örneğin, `event.transaction.hash.toHex() + "-" + event.logIndex.toString()` gibi. Ancak, bu bir dizi döndürdüğü için, subgraph endeksleme ve sorgulama performansını önemli ölçüde engeller.
 
 Bunun yerine, olay özelliklerini birleştirmek için `concatI32()` metodunu kullanmalıyız. Bu strateji, çok daha iyi çalışan bir `Bytes` ID ile sonuçlanır.
 
@@ -73,9 +73,9 @@ export function handleTransfer(event: TransferEvent): void {
 }
 ```
 
-### Sorting With Bytes as IDs
+### Bytes'ı ID Olarak Kullanarak Sıralama
 
-Sorting using Bytes as IDs is not optimal as seen in this example query and response.
+Bytes'ı ID olarak kullanarak sıralama yapmak, bu örnek sorgu ve yanıtında gördüğümüz gibi ideal değildir.
 
 Sorgu:
 

From 3057b55b342ee7349dad46203f20bfcf40999e1e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 16:12:53 -0500
Subject: [PATCH 3763/3820] New translations pruning.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/pruning.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/pruning.mdx b/website/pages/tr/subgraphs/cookbook/pruning.mdx
index c94aac4d9bcd..ca13065929f2 100644
--- a/website/pages/tr/subgraphs/cookbook/pruning.mdx
+++ b/website/pages/tr/subgraphs/cookbook/pruning.mdx
@@ -32,7 +32,7 @@ dataSources:
 
 ## Önemli Hususlar
 
-- If [Time Travel Queries](/subgraphs/querying/graphql-api/#time-travel-queries) are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use `indexerHints: prune: auto` with Time Travel Queries. Instead, prune using `indexerHints: prune: <Number of blocks to retain>` to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use `prune: never` to maintain all data.
+- [Zaman Yolculuğu Sorguları](/subgraphs/querying/graphql-api/#time-travel-queries) budama ile birlikte isteniyorsa, bu sorgular işlevselliğini korumak için budama doğru bir şekilde gerçekleştirilmelidir. Bu nedenle, genellikle `indexerHints: prune: auto`'yu Zaman Yolculuğu Sorguları ile kullanmak önerilmez. Bunun yerine, Zaman Yolculuğu Sorgularının gerektirdiği tarihsel verileri koruyan bir blok yüksekliğine doğru şekilde budamak için `indexerHints: prune: <Korunacak blok sayısı>` kullanın veya tüm veriyi korumak için `prune: never` kullanarak budama yapmamayı seçin.
 
 - Budanan bir blok yüksekliğinde [aşılama](/subgraphs/cookbook/grafting/) yapılamaz. Aşılama rutin olarak yapılıyorsa ve budama isteniyorsa, belirli bir blok sayısını (örneğin, altı ay yetecek kadar) doğru bir şekilde koruyacak `indexerHints: prune: <Korunacak blok sayısı>` ayarı kullanılması önerilir.
 

From 4978e760d19aae5b3418f0da717950995a59f4e8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 16:12:54 -0500
Subject: [PATCH 3764/3820] New translations secure-api-keys-nextjs.mdx
 (Turkish)

---
 website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index 70185f3ea9ad..b362c00a1231 100644
--- a/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/tr/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -12,7 +12,7 @@ Bu talimatlarda, bir subgraph'i sorgularken aynı zamanda API anahtarını ön y
 
 - Next.js sunucu bileşenleri, servis dışı bırakma saldırıları ile API anahtarlarının boşaltılmasına karşı koruma sağlamaz.
 - The Graph Ağ geçitleri, servis dışı bırakma saldırı tespiti ve saldırıyı hafifletme stratejilerine sahiptir. Ancak sunucu bileşenlerini kullanmak bu korumaları zayıflatabilir.
-- Next.js server components introduce centralization risks as the server can go down.
+- Next.js sunucu bileşenleri, sunucunun çökmesi ihtimali dolayısıyla merkezileşme riskleri taşır.
 
 ### Neden Gerekli
 

From 59e839a7dd1c8f28d9b3e1353ba6850d11586b65 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 16:12:55 -0500
Subject: [PATCH 3765/3820] New translations timeseries.mdx (Turkish)

---
 .../tr/subgraphs/cookbook/timeseries.mdx      | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/timeseries.mdx b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
index 9ee204ea48da..56b1e4c43487 100644
--- a/website/pages/tr/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/tr/subgraphs/cookbook/timeseries.mdx
@@ -12,9 +12,9 @@ Zaman serisi ve toplulaştırmalar, toplulaştırma hesaplamalarını veritaban
 
 ## Zaman Serisi ve Toplulaştırmaların Faydaları
 
-1. Improved Indexing Time
+1. İyileştirilmiş Endeksleme Süresi
 
-- Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.
+- Yüklenmesi Gereken Daha Az Veri: Ham veri noktaları değiştirilemez zaman serisi varlıkları olarak depolandığı için, eşlemeler daha az veri işler.
 - Veritabanı Tarafından Yönetilen Toplulaştırmalar: Toplulaştırmalar otomatik olarak veritabanı tarafından hesaplanır, bu da eşlemeler üzerindeki yükü azaltır.
 
 2. Basitleştirilmiş Eşleme Kodu
@@ -25,7 +25,7 @@ Zaman serisi ve toplulaştırmalar, toplulaştırma hesaplamalarını veritaban
 3. Çok Daha Hızlı Sorgular
 
 - Değişmez Veri: Tüm zaman serisi verileri değişmezdir. Bu da verimli depolama ve geri çağırmayı mümkün kılar.
-- Efficient Data Separation: Aggregates are stored separately from raw timeseries data, allowing queries to process significantly less data—often several orders of magnitude less.
+- Verimli Veri Ayrımı: Toplulaştırmalar, ham zaman serisi verilerinden ayrı olarak depolanır, bu da sorguların önemli ölçüde —genellikle birkaç büyüklük derecesi— daha az veri işlemesine olanak tanır.
 
 ### Önemli Hususlar
 
@@ -75,7 +75,7 @@ Bu örnekte Stats, Data'dan fiyat alanını saatlik ve günlük aralıklar üzer
 
 ### Toplulaştırılmış Verileri Sorgulama
 
-Aggregations are exposed via query fields that allow filtering and retrieval based on dimensions and time intervals.
+Toplulaştırmalar, boyut ve zaman aralıklarına göre filtreleme ve geri alma imkanı sağlayan sorgu alanları aracılığıyla dışarı sunulur.
 
 Örnek:
 
@@ -99,7 +99,7 @@ Aggregations are exposed via query fields that allow filtering and retrieval bas
 
 ### Toplulaştırmalarda Boyutların Kullanımı
 
-Dimensions are non-aggregated fields used to group data points. They enable aggregations based on specific criteria, such as a token in a financial application.
+Boyutlar, veri noktalarını gruplamak için kullanılan toplulaştırılmamış alanlardır. Belirli kriterlere dayalı toplulaştırmalar sağlarlar. Mesela, bir finansal uygulamadaki belirli bir token'a ait toplulaştırmaları elde etmek için kullanılırlar.
 
 Örnek:
 
@@ -115,7 +115,7 @@ type TokenData @entity(timeseries: true) {
 }
 ```
 
-### Aggregation Entity with Dimension
+### Boyut Kullanan Toplulaştırma Varlığı
 
 ```graphql
 type TokenStats @aggregation(intervals: ["hour", "day"], source: "TokenData") {
@@ -145,10 +145,10 @@ Desteklenen toplulaştırma fonksiyonları:
 - first (ilk)
 - last (son)
 
-### The arg in @aggregate can be
+### @aggregate içindeki arg (argüman) şunlar olabilir
 
-- A field name from the timeseries entity.
-- An expression using fields and constants.
+- Zaman serisi varlığındaki bir alan adı.
+- Alanlar ve sabit değerler kullanılarak oluşturulan bir ifade.
 
 ### Toplulaştırma İfadeleri Örnekleri
 
@@ -162,7 +162,7 @@ Desteklenen operatörler ve fonksiyonlar arasında temel aritmetik (+, -, \_, /)
 
 - interval: Zaman aralığını belirtir (ör., "hour").
 - where: Boyutlara ve zaman damgası aralıklarına göre filtreler.
-- timestamp_gte / timestamp_lt: Filters for start and end times (microseconds since epoch).
+- timestamp_gte / timestamp_lt: Başlangıç ve bitiş zamanları için filtreler (dönem başlangıcından itibaren geçen mikrosaniye cinsinden).
 
 ### Notlar
 

From 9ca9af3b6ffaaaff6b7f8260a3f83b6e055049ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 16:12:56 -0500
Subject: [PATCH 3766/3820] New translations grafting.mdx (Turkish)

---
 website/pages/tr/subgraphs/cookbook/grafting.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/cookbook/grafting.mdx b/website/pages/tr/subgraphs/cookbook/grafting.mdx
index 8afe1f25c68f..60855aa97729 100644
--- a/website/pages/tr/subgraphs/cookbook/grafting.mdx
+++ b/website/pages/tr/subgraphs/cookbook/grafting.mdx
@@ -145,7 +145,7 @@ Subgraph'ın düzgün bir şekilde indekslendiğini doğruladıktan sonra, subgr
 Graft yerine geçen subgraph.yaml yeni bir sözleşme adresine sahip olacaktır. Bu, merkeziyetsiz uygulamanızı güncellediğinizde, bir sözleşmeyi yeniden dağıttığınızda vb. gerçekleşebilir.
 
 1. [Subgraph Studio](https://thegraph.com/studio/) adresine gidin ve Sepolia testnet üzerinde `graft-replacement` adlı bir subgraph oluşturun
-2. Create a new manifest. The `subgraph.yaml` for `graph-replacement` contains a different contract address and new information about how it should graft. These are the `block` of the [last event emitted](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) you care about by the old contract and the `base` of the old subgraph. The `base` subgraph ID is the `Deployment ID` of your original `graph-example` subgraph. You can find this in Subgraph Studio.
+2. Yeni bir manifesto dosyası oluşturun. `graph-replacement` subgraph'ine ait `subgraph.yaml` dosyası, farklı bir sözleşme adresi ve nasıl aşılanması gerektiğiyle ilgili yeni bilgiler içermektedir. Bunlar, eski sözleşme tarafından ilgilendiğiniz [son yayılan olayın](https://sepolia.etherscan.io/tx/0xea1cee35036f2cacb72f2a336be3e54ab911f5bebd58f23400ebb8ecc5cfc452) `blok`u ve eski subgraph'in `base`'idir (temelidir). `base` subgraph kimliği, orijinal `graph-example` subgraph'inizin `Deployment ID`'sidir (dağıtım kimliğidir). Bunu Subgraph Studio'da bulabilirsiniz.
 3. `graft-replacement` klasöründeki subgraph sayfanızda, `AUTH & DEPLOY` bölümündeki talimatları izleyin
 4. Tamamlandığında, subgraph'ın doğru bir şekilde indekslendiğinden emin olun. Eğer aşağıdaki komutu Graph Test Alanında(Playground) çalıştırırsanız
 

From 62fe0bf653968c15078cff2ecafba9bbba16487b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 16:12:57 -0500
Subject: [PATCH 3767/3820] New translations subgraph-debug-forking.mdx
 (Turkish)

---
 .../subgraphs/cookbook/subgraph-debug-forking.mdx  | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx
index edd1f48b90de..d739d1aee6d6 100644
--- a/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/tr/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -8,17 +8,17 @@ Büyük miktarda veri işleyen birçok sistemde olduğu gibi, The Graph'ın Ende
 
 **Subgraph çatallama**, _başka bir_ subgraph'in mağazasından (genellikle uzak bir mağaza) tembel bir şekilde öge çekme işlemidir.
 
-In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
+Hata ayıklama bağlamında, **subgraph çatallama** başarısız olmuş subgraph'i, _X_ blokuna kadar senkronize olmasını beklemeden hata ayıklamanıza olanak tanır.
 
 ## Ne?! Nasıl?
 
-When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
+Bir subgraph'i uzaktaki bir Graph Düğümüne endekslemek amacıyla dağıttığınızda subgraph _X_ blokunda çalışmayı durdurabilir. İyi haber ise Graph Düğümü, _X_ blokuna kadar senkronize olmuş deposunu kullanarak GraphQL sorgularını yerine getiriyor olacaktır. Bu harika bir haber! Bu durum, endeksleme sırasında _X_ blokunda ortaya çıkan hataları düzeltmek için bu "güncel" depodan faydalanabileceğimiz anlamına gelir.
 
-In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
+Özetle, _çalışmayı durdurmuş bir subgraph'i_, _X_ blokuna kadar endekslenmesi garanti edilen uzak bir Graph Düğümünden _çatallayacağız_. Böylece _X_ blokunda hatası ayıklanan yerel olarak dağıtılmış subgraph'in endeksleme durumunu gösteren güncel bir görünüm sağlamış olacağız.
 
 ## Lütfen bana biraz kod göster!
 
-To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
+Subgraph hata ayıklamalarına odaklanmak için işleri basitleştirelim ve Ethereum Gravatar akıllı sözleşmesini endeksleyen [örnek-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) üzerinde çalışalım.
 
 `Gravatar`'ları endekslemek için tanımlanan, hiçbir hata içermeyen işleyiciler şunlardır:
 
@@ -57,7 +57,7 @@ Bu gerçekten sıradan bir hata ayıklama sürecine oldukça benzemektedir, anca
 
 **Subgraph çatallama** kullanarak bu adımı ortadan kaldırabiliriz. Aşağıda bu işlemi görebilirsiniz:
 
-0. Spin-up a local Graph Node with the **_appropriate fork-base_** set.
+0. **_Uygun çatal-temeli (fork-base)_** ayarlanmış yerel bir Graph Düğümü başlatın.
 1. Eşleştirme kaynağında, sorunu çözeceğine inandığınız bir değişiklik yapın.
 2. Çalışmayı durduran subgraph'i **_çatallayarak_** ve **_sorunlu bloktan başlayarak_** yerel Graph Düğümüne dağıtın.
 3. Tekrar sorunla karşılaşırsanız 1. aşamaya geri dönün, aksi takdirde: Yaşasın!
@@ -76,7 +76,7 @@ Ve ben cevap veriyorum:
 $ graph deploy <subgraph-ismi> --debug-fork <subgraph-id> --ipfs http://localhost:5001 --node http://localhost:8020
 ```
 
-Also, don't forget to set the `dataSources.source.startBlock` field in the subgraph manifest to the number of the problematic block, so you can skip indexing unnecessary blocks and take advantage of the fork!
+Ayrıca, ihtiyaç olmayan blokları endekslemeyi atlamak ve çatallamanın avantajlarından yararlanmak için `subgraph` manifesto dosyasındaki `dataSources.source.startBlock` alanını sorunlu blokun numarası olarak ayarlamayı unutmayın!
 
 İşte benim ne yaptığım:
 
@@ -91,7 +91,7 @@ $ cargo run -p graph-node --release -- \
 ```
 
 2. Dikkatli bir incelemeden sonra, iki işleyicimde `Gravatar`'ları endekslerken kullanılan `id` temsillerinde bir uyumsuzluk olduğunu fark ettim. `handleNewGravatar` onu bir hex'e dönüştürürken (`event.params.id.toHex()`), `handleUpdatedGravatar` bir int32 (`event.params.id.toI32()`) kullanıyor, bu da `handleUpdatedGravatar`'ın "Gravatar not found!" hatasını vermesine neden oluyor. İkisini de `id`'yi hex'e dönüştürecek şekilde düzenledim.
-3. After I made the changes I deploy my subgraph to the local Graph Node, **_forking the failing subgraph_** and setting `dataSources.source.startBlock` to `6190343` in `subgraph.yaml`:
+3. Değişiklikleri yaptıktan sonra, **_hatalı subgraph'i çatallayarak_** ve `subgraph.yaml` dosyasında `dataSources.source.startBlock` değerini `6190343` olarak ayarlayarak subgraph'imi yerel Graph Düğümü'ne dağıttım:
 
 ```bash
 $ graph deploy gravity --debug-fork QmNp169tKvomnH3cPXTfGg4ZEhAHA6kEq5oy1XDqAxqHmW --ipfs http://localhost:5001 --node http://localhost:8020

From c736b172b394112495977a894139c3304947b363 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 16:12:58 -0500
Subject: [PATCH 3768/3820] New translations subgraph-uncrashable.mdx (Turkish)

---
 .../pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx    | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx b/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx
index eacc8522b564..bd935dd33689 100644
--- a/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx
+++ b/website/pages/tr/subgraphs/cookbook/subgraph-uncrashable.mdx
@@ -2,13 +2,13 @@
 title: Güvenli Subgraph Kod Oluşturucu
 ---
 
-[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) is a code generation tool that generates a set of helper functions from the graphql schema of a project. It ensures that all interactions with entities in your subgraph are completely safe and consistent.
+[Subgraph Uncrashable](https://float-capital.github.io/float-subgraph-uncrashable/) (çökmeyen subgraph), bir projenin graphql şemasından bir dizi yardımcı fonksiyon üreten bir kod oluşturma aracıdır. `subgraph`inizdeki varlıklarla tüm etkileşimlerin tamamen güvenli ve tutarlı olmasını sağlar.
 
 ## Neden Subgraph Uncrashable'ı entegre etmelisiniz?
 
 - **Sürekli Çalışırlık**. Yanlış yönetilen varlıklar subgraph'lerin çökmesine neden olabilir. Bu da The Graph'e bağımlı olan projeler için işleri aksatabilir. Subgraph'lerinizi "çökmez" hale getirmek ve iş sürekliliğini sağlamak için yardımcı fonksiyonları ayarlayın.
 
-- **Completely Safe**. Common problems seen in subgraph development are issues of loading undefined entities, not setting or initializing all values of entities, and race conditions on loading and saving entities. Ensure all interactions with entities are completely atomic.
+- **Tamamen Güvenli**. `subgraph` geliştirme sırasında yaygın görülen sorunlar, tanımsız varlıkların yüklenmesi, varlıkların tüm değerlerinin ayarlanmaması veya ilklendirilmemesi, varlıkların yüklenmemesi ve kaydedilmemesidir. Varlıklarla tüm etkileşimlerin çok az olduğundan emin olun.
 
 - **Kullanıcı Tarafından Yapılandırılabilir** Varsayılan değerleri ayarlayın ve projenizin ihtiyaçlarına uygun güvenlik kontrol seviyesini yapılandırın. `Subgraph` mantığındaki bir ihlali gösteren uyarı günlükleri kaydedilir ve verilerin doğruluğunu sağlamak için sorunun giderilmesine yardımcı olunur.
 
@@ -26,4 +26,4 @@ Subgraph Uncrashable, Graph CLI codegen komutu kullanılarak isteğe bağlı bir
 graph codegen -u [options] [<subgraph-manifest>]
 ```
 
-Visit the [subgraph uncrashable documentation](https://float-capital.github.io/float-subgraph-uncrashable/docs/) or watch this [video tutorial](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) to learn more and to get started with developing safer subgraphs.
+Daha fazla bilgi edinmek ve daha güvenli subgraph'ler geliştirmeye başlamak için [Subgraph Uncrashable dokümantasyonuna](https://float-capital.github.io/float-subgraph-uncrashable/docs/) göz atın veya bu [video rehberini](https://float-capital.github.io/float-subgraph-uncrashable/docs/tutorial) izleyin.

From 6c8f9268032e185564bf9fe5a328f6166c77dd8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 16:12:59 -0500
Subject: [PATCH 3769/3820] New translations transfer-to-the-graph.mdx
 (Turkish)

---
 .../tr/subgraphs/cookbook/transfer-to-the-graph.mdx    | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx b/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
index 334a7bef32df..a02f136958c2 100644
--- a/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
+++ b/website/pages/tr/subgraphs/cookbook/transfer-to-the-graph.mdx
@@ -7,8 +7,8 @@ Subgraph'lerinizi herhangi bir platformdan hızlıca [The Graph'in merkezi olmay
 ## The Graph'e Geçmenin Avantajları
 
 - Uygulamalarınızın zaten kullandığı subgraph'i kesinti yaşamadan aynı şekilde kullanabilirsiniz.
-- Increase reliability from a global network supported by 100+ Indexers.
-- Receive lightning-fast support for subgraphs 24/7, with an on-call engineering team.
+- Yüzden fazla Endeksleyici tarafından desteklenip global bir ağdan gelen güvenilirliği artırabilirsiniz.
+- Subgraph'ler için, her zaman yardıma hazır mühendislik ekibinden 7/24 yıldırım hızında destek alabilirsiniz.
 
 ## Subgraph'inizi The Graph'e 3 Kolay Adımda Yükseltin
 
@@ -48,7 +48,7 @@ graph init --product subgraph-studio
 The Graph CLI'da, Subgraph Studio'da görülen auth komutunu kullanın:
 
 ```sh
-graph auth <your-auth-code>
+graph auth <senin-auth-kodun>
 ```
 
 ## 2. Subgraph'inizi Studio'ya Dağıtın
@@ -58,7 +58,7 @@ Kaynak kodunuz elinizdeyse kodunuzu Studio'ya kolayca dağıtabilirsiniz. Kaynak
 The Graph CLI'de aşağıdaki komutu çalıştırın:
 
 ```sh
-graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
+graph deploy <slug> --ipfs-hash <senin-subgraph-ipfs-hash-in>
 
 ```
 
@@ -72,7 +72,7 @@ graph deploy <slug> --ipfs-hash <your-subgraph-ipfs-hash>
 
 > Subgraph'inizi sorgulamak için yaklaşık üç endeksleyici çekmek için, en az 3000 GRT ile kürasyon yapmanız önerilir. Kürasyon hakkında daha fazla bilgi için, The Graph üzerindeki [Kürasyon](/resources/roles/curating/) sayfasına göz atın.
 
-You can start [querying](/subgraphs/querying/introduction/) any subgraph by sending a GraphQL query into the subgraph’s query URL endpoint, which is located at the top of its Explorer page in Subgraph Studio.
+Herhangi bir subgraph'i [sorgulamaya](/subgraphs/querying/introduction/) başlamak için, bir GraphQL sorgusunu subgraph’in sorgu URL uç noktasına gönderebilirsiniz. Bu uç nokta Subgraph Studio'daki Gezgin sayfasının üst kısmında bulunur.
 
 #### Örnek
 

From 0bd062bcddacaa93b0b0f34be1677e2c163580c4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 21:39:22 -0500
Subject: [PATCH 3770/3820] New translations advanced.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/developing/creating/advanced.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/developing/creating/advanced.mdx b/website/pages/zh/subgraphs/developing/creating/advanced.mdx
index f7faa479f873..2940048138dd 100644
--- a/website/pages/zh/subgraphs/developing/creating/advanced.mdx
+++ b/website/pages/zh/subgraphs/developing/creating/advanced.mdx
@@ -357,7 +357,7 @@ Handlers for File Data Sources cannot be in files which import `eth_call` contra
 
 [Crypto Coven Subgraph migration](https://github.com/azf20/cryptocoven-api/tree/file-data-sources-refactor)
 
-#### 参考
+#### References
 
 [GIP File Data Sources](https://forum.thegraph.com/t/gip-file-data-sources/2721)
 

From f8df1d1baf7472e85ca127f123214628b538040d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Tue, 11 Feb 2025 21:39:23 -0500
Subject: [PATCH 3771/3820] New translations near.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/cookbook/near.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/near.mdx b/website/pages/zh/subgraphs/cookbook/near.mdx
index a1146dbab5e8..c16e67199277 100644
--- a/website/pages/zh/subgraphs/cookbook/near.mdx
+++ b/website/pages/zh/subgraphs/cookbook/near.mdx
@@ -278,6 +278,6 @@ NEAR 子图尚不支持挂起的功能。 在此期间，您可以将新版本
 
 If it is a general question about subgraph development, there is a lot more information in the rest of the [Developer documentation](/subgraphs/quick-start/). Otherwise please join [The Graph Protocol Discord](https://discord.gg/graphprotocol) and ask in the #near channel or email near@thegraph.com.
 
-## 参考
+## References
 
 - [NEAR developer documentation](https://docs.near.org/tutorials/crosswords/basics/set-up-skeleton)

From 62ae4f090c67890772a4f88273b8e0d5002b8150 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 04:00:56 -0500
Subject: [PATCH 3772/3820] New translations glossary.mdx (French)

---
 website/pages/fr/resources/glossary.mdx | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/fr/resources/glossary.mdx b/website/pages/fr/resources/glossary.mdx
index 7cafe7540148..cfaa0beb4c78 100644
--- a/website/pages/fr/resources/glossary.mdx
+++ b/website/pages/fr/resources/glossary.mdx
@@ -40,25 +40,25 @@ title: Glossaire
 
 - **Manifeste du subgraph** : Un fichier YAML qui décrit le schéma GraphQL du subgraph, les sources de données et d'autres métadonnées. Vous trouverez [Ici](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) un exemple.
 
-- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+- **Epoque** : Unité de temps au sein du réseau. Actuellement, une époque correspond à 6 646 blocs, soit environ 1 jour.
 
-- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
+- **Allocation** : Un Indexeur peut allouer l'ensemble de son staking de GRT (y compris le staking des Déléguateurs) à des subgraphs qui ont été publiés sur le réseau décentralisé de The Graph. Les allocations peuvent avoir différents statuts :
 
-  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+  1. **Actif** : Une allocation est considérée comme active lorsqu'elle est créée onchain. C'est ce qu'on appelle ouvrir une allocation, et cela indique au réseau que l'Indexeur est en train d'indexer et de servir des requêtes pour un subgraph particulier. Les allocations actives accumulent des récompenses d'indexation proportionnelles au signal sur le subgraph et à la quantité de GRT allouée.
 
-  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+  2. **Fermé** : Un Indexeur peut réclamer les récompenses d'indexation accumulées sur un subgraph donné en soumettant une preuve d'indexation (POI) récente et valide. C'est ce qu'on appelle la fermeture d'une allocation. Une allocation doit avoir été ouverte pendant au moins une époque avant de pouvoir être fermée. La période d'allocation maximale est de 28 époques. Si un Indexeur laisse une allocation ouverte au-delà de 28 époques, il s'agit d'une allocation périmée. Lorsqu'une allocation est dans l'état **fermé**, un Fisherman peut encore ouvrir un litige pour contester un Indexeur pour avoir servi de fausses données.
 
-- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
+- **Subgraph Studio** : Une dapp puissante pour construire, déployer et publier des subgraphs.
 
 - **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
 
-- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+- **Arbitres** : Les arbitres sont des participants au réseau nommés dans le cadre d'un processus de gouvernance. Le rôle de l'arbitre est de décider de l'issue des litiges relatifs à l'indexation et aux requêtes. Leur objectif est de maximiser l'utilité et la fiabilité de The Graph.
 
-- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+- **Slashing**(Taillade) : Les Indexeurs peuvent se voir retirer leur GRT pour avoir fourni un POI incorrect ou pour avoir diffusé des données inexactes. Le pourcentage de réduction est un paramètre protocolaire actuellement fixé à 2,5 % du staking personnel de l'Indexeur. 50 % des GRT réduit est versé au pêcheur qui a contesté les données inexactes ou le point d'intérêt incorrect. Les 50 % restants sont brûlés.
 
-- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+- **Récompenses d'indexation** : Les récompenses que les Indexeurs reçoivent pour l'indexation des subgraphs. Les récompenses d'indexation sont distribuées en GRT.
 
-- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+- **Récompenses de délégation** : Les récompenses que les Déléguateurs reçoivent pour avoir délégué des GRT aux Indexeurs. Les récompenses de délégation sont distribuées en GRT.
 
 - **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
 

From 3009c8430fdafaf65bb55cb576ef2a4d65b923d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 04:00:59 -0500
Subject: [PATCH 3773/3820] New translations overview.mdx (German)

---
 website/pages/de/indexing/overview.mdx | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/website/pages/de/indexing/overview.mdx b/website/pages/de/indexing/overview.mdx
index 602a5b5460c0..05714a2e42b8 100644
--- a/website/pages/de/indexing/overview.mdx
+++ b/website/pages/de/indexing/overview.mdx
@@ -721,13 +721,13 @@ A statement is comprised of a predicate, which is used for matching GraphQL quer
 Example cost model:
 
 ```
-# This statement captures the skip value,
-# uses a boolean expression in the predicate to match specific queries that use `skip`
-# and a cost expression to calculate the cost based on the `skip` value and the SYSTEM_LOAD global
+# Diese Anweisung erfasst den Wert „skip“,
+# verwendet einen booleschen Ausdruck im Prädikat, um mit bestimmten Abfragen übereinzustimmen, die `skip` verwenden
+# und einen Kostenausdruck, um die Kosten auf der Grundlage des `skip`-Wertes und des globalen SYSTEM_LOAD-Wertes zu berechnen
 query { pairs(skip: $skip) { id } } when $skip > 2000 => 0.0001 * $skip * $SYSTEM_LOAD;
 
-# This default will match any GraphQL expression.
-# It uses a Global substituted into the expression to calculate cost
+# Diese Vorgabe passt auf jeden GraphQL-Ausdruck.
+# Sie verwendet ein Global, das in den Ausdruck eingesetzt wird, um die Kosten zu berechnen
 default => 0.1 * $SYSTEM_LOAD;
 ```
 

From ab59e87c11b1fde17c833b2fa57832dcde30c386 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 04:01:00 -0500
Subject: [PATCH 3774/3820] New translations assemblyscript-migration-guide.mdx
 (German)

---
 .../assemblyscript-migration-guide.mdx        | 72 +++++++++----------
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
index 20063f593224..51f53a6a9a10 100644
--- a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -2,49 +2,49 @@
 title: AssemblyScript Migration Guide
 ---
 
-Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+Bis jetzt haben Subgraphen eine der [ersten Versionen von AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6) verwendet. Endlich haben wir Unterstützung für die [neueste verfügbare Version](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10) hinzugefügt! 🎉
 
 That will enable subgraph developers to use newer features of the AS language and standard library.
 
-This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+Diese Anleitung gilt für alle, die `graph-cli`/`graph-ts` unter Version `0.22.0` verwenden. Wenn Sie bereits eine höhere (oder gleiche) Version als diese haben, haben Sie bereits Version `0.19.10` von AssemblyScript verwendet 🙂
 
-> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+> Anmerkung: Ab `0.24.0` kann `graph-node` beide Versionen unterstützen, abhängig von der im Subgraph-Manifest angegebenen `apiVersion`.
 
 ## Features
 
 ### New functionality
 
-- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
-- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
-- Added `StaticArray<T>`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
-- Added `Array<T>#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
-- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
-- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
-- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
-- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
-- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
-- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
-- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
-- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
-- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+- `TypedArray` kann nun aus `ArrayBuffer` mit Hilfe der [neuen statischen Methode `wrap`](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1)) erstellt werden
+- Neue Standard-Bibliotheksfunktionen: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`und `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Unterstützung für x instanceof GenericClass hinzugefügt ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- `StaticArray<T>`, hinzugefügt, eine effizientere Array-Variante ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- `Array<T>#flat` hinzugefügt ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- `radix`-Argument bei `Number#toString` implementiert ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Unterstützung für Trennzeichen in Fließkomma-Literalen hinzugefügt ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Unterstützung für Funktionen erster Klasse hinzugefügt ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Buildins hinzugefügt: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- `Array/TypedArray/String#at` implementiert ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Unterstützung für Template-Literal-Strings hinzugefügt ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Hinzufügen von `encodeURI(Component)` und `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Hinzufügen von `toString`, `toDateString` und `toTimeString` zu `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Hinzufügen von `toUTCString` für `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Hinzufügen von `nonnull/NonNullable` integrierten Typ ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
 
 ### Optimizations
 
-- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
-- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
-- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- `Math`-Funktionen wie `exp`, `exp2`, `log`, `log2` und `pow` wurden durch schnellere Varianten ersetzt ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Leicht optimierte `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Mehr Feldzugriffe in std Map und Set zwischengespeichert ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimieren für Zweierpotenzen in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
 
 ### Other
 
-- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Der Typ eines Array-Literal kann nun aus seinem Inhalt abgeleitet werden ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- stdlib auf Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0)) aktualisiert
 
 ## How to upgrade?
 
-1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+1. Ändern Sie Ihre Mappings `apiVersion` in `subgraph.yaml` auf `0.0.6`:
 
 ```yaml
 ...
@@ -56,7 +56,7 @@ dataSources:
       ...
 ```
 
-2. Update the `graph-cli` you're using to the `latest` version by running:
+2. Aktualisieren Sie die `graph-cli`, die Sie verwenden, auf die `latest` Version, indem Sie sie ausführen:
 
 ```bash
 # if you have it globally installed
@@ -66,14 +66,14 @@ npm install --global @graphprotocol/graph-cli@latest
 npm install --save-dev @graphprotocol/graph-cli@latest
 ```
 
-3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+3. Machen Sie dasselbe für `graph-ts`, aber anstatt es global zu installieren, speichern Sie es in Ihren Hauptabhängigkeiten:
 
 ```bash
 npm install --save @graphprotocol/graph-ts@latest
 ```
 
 4. Follow the rest of the guide to fix the language breaking changes.
-5. Run `codegen` and `deploy` again.
+5. Führen Sie `codegen` und `deploy` erneut aus.
 
 ## Breaking changes
 
@@ -110,7 +110,7 @@ If you are unsure which to choose, we recommend always using the safe version. I
 
 ### Variable Shadowing
 
-Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+Früher konnte man [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) machen und Code wie dieser würde funktionieren:
 
 ```typescript
 let a = 10
@@ -141,12 +141,12 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
  in src/mappings/file.ts(41,21)
 ```
 
-To solve you can simply change the `if` statement to something like this:
+Zur Lösung des Problems können Sie die `if`-Anweisung einfach wie folgt ändern:
 
 ```typescript
   if (!decimals) {
 
-  // or
+  // oder
 
   if (decimals === null) {
 ```
@@ -155,7 +155,7 @@ The same applies if you're doing != instead of ==.
 
 ### Casting
 
-The common way to do casting before was to just use the `as` keyword, like this:
+Früher war es üblich, das Schlüsselwort `as` für das Casting zu verwenden, etwa so:
 
 ```typescript
 let byteArray = new ByteArray(10)
@@ -164,7 +164,7 @@ let uint8Array = byteArray as Uint8Array // equivalent to: <Uint8Array>byteArray
 
 However this only works in two scenarios:
 
-- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
+- Primitives Casting (zwischen Typen wie `u8`, `i32`, `bool`; z. B.: `let b: isize = 10; b as usize`);
 - Upcasting on class inheritance (subclass → superclass)
 
 Beispiele:
@@ -177,14 +177,14 @@ let c: usize = a + (b as usize)
 ```
 
 ```typescript
-// upcasting on class inheritance
+// upcasting bei Klassenvererbung
 class Bytes extends Uint8Array {}
 
 let bytes = new Bytes(2)
-// <Uint8Array>bytes // same as: bytes as Uint8Array
+// <Uint8Array>bytes // gleich wie: bytes as Uint8Array
 ```
 
-There are two scenarios where you may want to cast, but using `as`/`<T>var` **isn't safe**:
+Es gibt zwei Szenarien, in denen man casten möchte, aber die Verwendung von `as`/`<T>var` **ist nicht sicher**:
 
 - Downcasting on class inheritance (superclass → subclass)
 - Between two types that share a superclass

From 7c1c65554c626288856da40f07ed872d9a03985a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 05:00:26 -0500
Subject: [PATCH 3775/3820] New translations assemblyscript-migration-guide.mdx
 (German)

---
 .../assemblyscript-migration-guide.mdx         | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
index 51f53a6a9a10..241247b0a901 100644
--- a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -190,39 +190,39 @@ Es gibt zwei Szenarien, in denen man casten möchte, aber die Verwendung von `as
 - Between two types that share a superclass
 
 ```typescript
-// downcasting on class inheritance
+// Downcasting bei Klassenvererbung
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-// <Bytes>uint8Array // breaks in runtime :(
+// <Bytes>uint8Array // bricht zur Laufzeit ab :(
 ```
 
 ```typescript
-// between two types that share a superclass
+// zwischen zwei Typen, die sich eine Oberklasse teilen
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
 let bytes = new Bytes(2)
-// <ByteArray>bytes // breaks in runtime :(
+// <ByteArray>bytes // bricht zur Laufzeit ab :(
 ```
 
-For those cases, you can use the `changetype<T>` function:
+Für diese Fälle können Sie die Funktion `changetype<T>` verwenden:
 
 ```typescript
-// downcasting on class inheritance
+// Downcasting bei Klassenvererbung
 class Bytes extends Uint8Array {}
 
 let uint8Array = new Uint8Array(2)
-changetype<Bytes>(uint8Array) // works :)
+changetype<Bytes>(uint8Array) // funktioniert :)
 ```
 
 ```typescript
-// between two types that share a superclass
+// zwischen zwei Typen, die sich eine Oberklasse teilen
 class Bytes extends Uint8Array {}
 class ByteArray extends Uint8Array {}
 
 let bytes = new Bytes(2)
-changetype<ByteArray>(bytes) // works :)
+changetype<ByteArray>(bytes) // funktioniert :)
 ```
 
 If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.

From 1ee90decce8b10e6f5c85af9c0aba5ab334ed3c8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 06:39:50 -0500
Subject: [PATCH 3776/3820] New translations assemblyscript-migration-guide.mdx
 (German)

---
 .../assemblyscript-migration-guide.mdx        | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
index 241247b0a901..3ba8d636f1ef 100644
--- a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -225,7 +225,7 @@ let bytes = new Bytes(2)
 changetype<ByteArray>(bytes) // funktioniert :)
 ```
 
-If you just want to remove nullability, you can keep using the `as` operator (or `<T>variable`), but make sure you know that value can't be null, otherwise it will break.
+Wenn Sie nur die Nullbarkeit entfernen wollen, können Sie weiterhin den `as`-Operator (oder `<T>variable`) verwenden, aber stellen Sie sicher, dass Sie wissen, dass der Wert nicht Null sein kann, sonst bricht es.
 
 ```typescript
 // remove nullability
@@ -238,7 +238,7 @@ if (previousBalance != null) {
 let newBalance = new AccountBalance(balanceId)
 ```
 
-For the nullability case we recommend taking a look at the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks), it will make your code cleaner 🙂
+Für den Fall der Nullbarkeit empfehlen wir, einen Blick auf die [Nullability-Check-Funktion] (https://www.assemblyscript.org/basics.html#nullability-checks) zu werfen, sie wird Ihren Code sauberer machen 🙂
 
 Also we've added a few more static methods in some types to ease casting, they are:
 
@@ -249,7 +249,7 @@ Also we've added a few more static methods in some types to ease casting, they a
 
 ### Nullability check with property access
 
-To use the [nullability check feature](https://www.assemblyscript.org/basics.html#nullability-checks) you can use either `if` statements or the ternary operator (`?` and `:`) like this:
+Um die [Nullability-Check-Funktion] (https://www.assemblyscript.org/basics.html#nullability-checks) zu verwenden, können Sie entweder `if`-Anweisungen oder den ternären Operator (`?` und `:`) wie folgt verwenden:
 
 ```typescript
 let something: string | null = 'data'
@@ -267,7 +267,7 @@ if (something) {
 }
 ```
 
-However that only works when you're doing the `if` / ternary on a variable, not on a property access, like this:
+Das funktioniert jedoch nur, wenn Sie das `if` / ternär auf eine Variable anwenden, nicht auf einen Eigenschaftszugriff, wie hier:
 
 ```typescript
 class Container {
@@ -381,7 +381,7 @@ if (total === null) {
 total.amount = total.amount + BigInt.fromI32(1)
 ```
 
-You'll need to make sure to initialize the `total.amount` value, because if you try to access like in the last line for the sum, it will crash. So you either initialize it first:
+Sie müssen sicherstellen, dass Sie den Wert `total.amount` initialisieren, denn wenn Sie versuchen, wie in der letzten Zeile auf die Summe zuzugreifen, wird das Programm abstürzen. Sie müssen ihn also entweder zuerst initialisieren:
 
 ```typescript
 let total = Total.load('latest')
@@ -394,7 +394,7 @@ if (total === null) {
 total.tokens = total.tokens + BigInt.fromI32(1)
 ```
 
-Or you can just change your GraphQL schema to not use a nullable type for this property, then we'll initialize it as zero on the `codegen` step 😉
+Oder Sie können einfach Ihr GraphQL-Schema so ändern, dass Sie keinen nullbaren Typ für diese Eigenschaft verwenden, dann werden wir sie im Schritt `codegen` mit Null initialisieren 😉
 
 ```graphql
 type Total @entity {
@@ -425,7 +425,7 @@ export class Something {
 }
 ```
 
-The compiler will error because you either need to add an initializer for the properties that are classes, or add the `!` operator:
+Der Compiler wird einen Fehler machen, weil Sie entweder einen Initialisierer für die Eigenschaften hinzufügen müssen, die Klassen sind, oder den Operator `!` hinzufügen müssen:
 
 ```typescript
 export class Something {
@@ -451,7 +451,7 @@ export class Something {
 
 ### Array initialization
 
-The `Array` class still accepts a number to initialize the length of the list, however you should take care because operations like `.push` will actually increase the size instead of adding to the beginning, for example:
+Die Klasse `Array` akzeptiert immer noch eine Zahl, um die Länge der Liste zu initialisieren, aber Sie sollten vorsichtig sein, weil Operationen wie `.push` die Größe tatsächlich erhöhen, anstatt z.B. zum Anfang hinzuzufügen:
 
 ```typescript
 let arr = new Array<string>(5) // ["", "", "", "", ""]
@@ -465,7 +465,7 @@ Depending on the types you're using, eg nullable ones, and how you're accessing
 ERRO Handler skipped due to execution failure, error: Mapping aborted at ~lib/array.ts, line 110, column 40, with message: Element type must be nullable if array is holey  wasm backtrace:     0: 0x19c4 - <unknown>!~lib/@graphprotocol/graph-ts/index/format         1: 0x1e75 - <unknown>!~lib/@graphprotocol/graph-ts/common/collections/Entity#constructor        2: 0x30b9 - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type
 ```
 
-To actually push at the beginning you should either, initialize the `Array` with size zero, like this:
+Um tatsächlich am Anfang zu pushen, sollte man entweder das `Array` mit der Größe Null initialisieren, wie hier:
 
 ```typescript
 let arr = new Array<string>(0) // []
@@ -483,7 +483,7 @@ arr[0] = 'something' // ["something", "", "", "", ""]
 
 ### GraphQL schema
 
-This is not a direct AssemblyScript change, but you may have to update your `schema.graphql` file.
+Dies ist keine direkte AssemblyScript-Änderung, aber Sie müssen möglicherweise Ihre Datei `schema.graphql` aktualisieren.
 
 Now you no longer can define fields in your types that are Non-Nullable Lists. If you have a schema like this:
 

From 9ad7e132ab2e74e29649cf1e3ff55e22fde2b538 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 08:35:38 -0500
Subject: [PATCH 3777/3820] New translations assemblyscript-migration-guide.mdx
 (German)

---
 .../assemblyscript-migration-guide.mdx         | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
index 3ba8d636f1ef..c80ae636b7a8 100644
--- a/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/de/resources/release-notes/assemblyscript-migration-guide.mdx
@@ -498,7 +498,7 @@ type MyEntity @entity {
 }
 ```
 
-You'll have to add an `!` to the member of the List type, like this:
+Sie müssen ein `!` an das Mitglied des Typs List hinzufügen, etwa so:
 
 ```graphql
 type Something @entity {
@@ -511,14 +511,14 @@ type MyEntity @entity {
 }
 ```
 
-This changed because of nullability differences between AssemblyScript versions, and it's related to the `src/generated/schema.ts` file (default path, you might have changed this).
+Dies hat sich aufgrund von Unterschieden in der Nullbarkeit zwischen AssemblyScript-Versionen geändert und hängt mit der Datei `src/generated/schema.ts` (Standardpfad, vielleicht haben Sie diesen geändert) zusammen.
 
 ### Other
 
-- Aligned `Map#set` and `Set#add` with the spec, returning `this` ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
-- Arrays no longer inherit from ArrayBufferView, but are now distinct ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- Classes initialized from object literals can no longer define a constructor ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- The result of a `**` binary operation is now the common denominator integer if both operands are integers. Previously, the result was a float as if calling `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
-- Coerce `NaN` to `false` when casting to `bool` ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
-- When shifting a small integer value of type `i8`/`u8` or `i16`/`u16`, only the 3 respectively 4 least significant bits of the RHS value affect the result, analogous to the result of an `i32.shl` only being affected by the 5 least significant bits of the RHS value. Example: `someI8 << 8` previously produced the value `0`, but now produces `someI8` due to masking the RHS as `8 & 7 = 0` (3 bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0))
-- Bug fix of relational string comparisons when sizes differ ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- `Map#set` und `Set#add` wurden an die Spezifikation angepasst und geben `this` zurück ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Arrays erben nicht mehr von ArrayBufferView, sondern sind jetzt eigenständig ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Klassen, die aus Objektliteralen initialisiert werden, können nicht mehr einen Konstruktor definieren ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Das Ergebnis einer `**`-Binäroperation ist jetzt die Ganzzahl im gemeinsamen Nenner, wenn beide Operanden Ganzzahlen sind. Zuvor war das Ergebnis eine Fließkommazahl, wie beim Aufruf von `Math/f.pow` ([v0.11.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.11.0))
+- `NaN` auf `false` verzerren, wenn nach ‚bool‘ gecastet wird ([v0.14.9](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.9))
+- Beim Verschieben eines kleinen Integer-Wertes vom Typ `i8`/`u8` oder `i16`/`u16` beeinflussen nur die 3 bzw. 4 niedrigstwertigen Bits des RHS-Wertes das Ergebnis, analog zum Ergebnis einer `i32.shl`, das nur von den 5 niedrigstwertigen Bits des RHS-Wertes beeinflusst wird. Beispiel: „someI8 << 8“ erzeugte zuvor den Wert „0“, erzeugt aber jetzt „someI8“, da die RHS als „8 & 7 = 0“ (3 Bits) ([v0.17.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.0)) maskiert wird
+- Fehlerbehebung bei relationalen String-Vergleichen bei unterschiedlichen Größen ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))

From 385f358d3e6341d4377d041f11bc8e2c35f4d94b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 08:35:39 -0500
Subject: [PATCH 3778/3820] New translations curating.mdx (Turkish)

---
 website/pages/tr/resources/roles/curating.mdx | 84 +++++++++----------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/website/pages/tr/resources/roles/curating.mdx b/website/pages/tr/resources/roles/curating.mdx
index 959950f73c00..b732a78feb70 100644
--- a/website/pages/tr/resources/roles/curating.mdx
+++ b/website/pages/tr/resources/roles/curating.mdx
@@ -1,89 +1,89 @@
 ---
-title: Curating
+title: Kürasyon
 ---
 
-Curators are critical to The Graph's decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through Graph Explorer, Curators view network data to make signaling decisions. In turn, The Graph Network rewards Curators who signal on good quality subgraphs with a share of the query fees those subgraphs generate. The amount of GRT signaled is one of the key considerations for indexers when determining which subgraphs to index.
+Küratörler The Graph'in merkeziyetsiz ekonomisi için kritik öneme sahiptir. Web3 ekosistemi hakkındaki bilgilerini kullanarak, The Graph Ağı tarafından endekslenmesi gereken subgraph’leri değerlendirir ve bunlara sinyal verirler. Küratörler Graph Gezgini aracılığıyla ağ verilerini inceleyerek sinyal verip vermeme kararını alır. The Graph Ağı, iyi kaliteye sahip subgraph’lere sinyal veren küratörleri, bu subgraph’lerin ürettiği sorgu ücretlerinden bir pay ile ödüllendirir. Sinyallenen GRT miktarı endeksleyiciler için hangi subgraph'leri endeksleyeceklerini belirlerken önemli bir faktördür.
 
-## What Does Signaling Mean for The Graph Network?
+## Sinyal Verme, The Graph Ağı için Ne Anlama Geliyor?
 
-Before consumers can query a subgraph, it must be indexed. This is where curation comes into play. In order for Indexers to earn substantial query fees on quality subgraphs, they need to know what subgraphs to index. When Curators signal on a subgraph, it lets Indexers know that a subgraph is in demand and of sufficient quality that it should be indexed.
+Bir subgraph'in tüketiciler tarafından sorgulanabilmesi için subgraph önce endekslenmelidir. İşte burada kürasyon devreye girer. Endeksleyicilerin kaliteli subgraph’lerden kayda değer sorgu ücretleri kazanabilmesi için hangi subgraph’leri endeksleyeceklerini bilmeleri gerekir. Küratörler bir subgraph’e sinyal verdiğinde bu, endeksleyicilere o subgraph’in talep gördüğünü ve yeterli kaliteye sahip olduğunu gösterir.
 
-Curators make The Graph network efficient and [signaling](#how-to-signal) is the process that Curators use to let Indexers know that a subgraph is good to index. Indexers can trust the signal from a Curator because upon signaling, Curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives.
+Küratörler, The Graph ağını verimli hale getirirler. [Sinyalleme](#how-to-signal), Küratörlerin Endeksleyicilere hangi subgraph'in endekslenmeye uygun olduğunu bildirmelerini sağlayan süreçtir. Endeksleyiciler, bir Küratörden gelen sinyale güvenebilir çünkü sinyalleme sırasında, Küratörler subgraph için bir kürasyon payı üretir. Bu da onları subgraph'in sağladığı gelecekteki sorgu ücretlerinin bir kısmına hak sahibi kılar.
 
-Curator signals are represented as ERC20 tokens called Graph Curation Shares (GCS). Those that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators will also earn fewer query fees if they curate on a low-quality subgraph because there will be fewer queries to process or fewer Indexers to process them.
+Küratör sinyalleri, Graph Kürasyon Payları (Graph Curation Shares - GCS) olarak adlandırılan ERC20 token ile temsil edilir. Daha fazla sorgu ücreti kazanmak isteyenler, GRT’lerini ağ için güçlü bir ücret akışı yaratacağını öngördükleri subgraph’lere sinyal vermelidir. Küratörler kötü davranışları nedeniyle cezalandırılmaz (slashing uygulanmaz), ancak ağın bütünlüğüne zarar verebilecek kötü kararları caydırmak için bir depozito vergisi bulunur. Düşük kaliteli bir subgraph üzerinde kürasyon yapan Küratörler, daha az sorgu olduğu ya da daha az Endeksleyici tarafından işlendiği için daha az sorgu ücreti kazanır.
 
-The [Sunrise Upgrade Indexer](/archived/sunrise/#what-is-the-upgrade-indexer) ensures the indexing of all subgraphs, signaling GRT on a particular subgraph will draw more indexers to it. This incentivization of additional Indexers through curation aims to enhance the quality of service for queries by reducing latency and enhancing network availability.
+[Sunrise Yükseltme Endeksleyici](/archived/sunrise/#what-is-the-upgrade-indexer) tüm subgraph'lerin endekslenmesini sağlar. Belirli bir subgraph'e GRT sinyallenmesi o subgraph'e daha fazla endeksleyici çeker. Kürasyon yoluyla ek Endeksleyicilerin teşvik edilmesi, sorgu hizmetinin kalitesini artırmayı amaçlar ve ağ erişilebilirliğini artırarak gecikmeyi azaltır.
 
-When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+Sinyal verirken, Küratörler belirli bir subgraph sürümüne sinyal vermeyi veya otomatik geçiş (auto-migrate) özelliğini kullanmayı seçebilirler. Eğer otomatik geçiş özelliğini kullanarak sinyal verirlerse, bir küratörün payları her zaman geliştirici tarafından yayımlanan en son sürüme göre güncellenir. Bunun yerine belirli bir sürüme sinyal vermeyi seçerlerse, paylar her zaman bu belirli sürümdeki haliyle kalır.
 
-If you require assistance with curation to enhance the quality of service, please send a request to the Edge & Node team at support@thegraph.zendesk.com and specify the subgraphs you need assistance with.
+Hizmet kalitenizi artırmak için kürasyon konusunda yardıma ihtiyacınız varsa, lütfen Edge & Node ekibine support@thegraph.zendesk.com adresinden bir talep gönderin ve yardıma ihtiyacınız olan subgraph'leri belirtin.
 
-Indexers can find subgraphs to index based on curation signals they see in Graph Explorer (screenshot below).
+Endeksleyiciler, Graph Gezgini'nde gördükleri kürasyon sinyallerine dayanarak endeksleyecekleri subgraph’leri bulabilirler (aşağıdaki ekran görüntüsüne bakın).
 
-![Explorer subgraphs](/img/explorer-subgraphs.png)
+![Gezgin subgraph'leri](/img/explorer-subgraphs.png)
 
-## How to Signal
+## Nasıl Sinyal Verilir
 
-Within the Curator tab in Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in Graph Explorer, [click here.](/subgraphs/explorer/)
+Graph Gezgini'ndeki Küratör sekmesi içinde, küratörler ağ istatistiklerine dayalı olarak belirli subgraph'lere sinyal verip kaldırabilecekler. Bunu Graph Gezgini'nde nasıl yapacağınıza dair adım adım bir genel bakış için, [buraya tıklayın.](/subgraphs/explorer/)
 
-A curator can choose to signal on a specific subgraph version, or they can choose to have their signal automatically migrate to the newest production build of that subgraph. Both are valid strategies and come with their own pros and cons.
+Bir küratör, belirli bir subgraph sürümü üzerinde sinyal vermeyi seçebilir veya sinyalinin otomatik olarak o subgraph'in en yeni üretim sürümüne taşınmasını tercih edebilir. Her iki strateji de geçerli olup kendi avantaj ve dezavantajlarına sahiptir.
 
-Signaling on a specific version is especially useful when one subgraph is used by multiple dapps. One dapp might need to regularly update the subgraph with new features. Another dapp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+Belirli bir sürüme sinyal vermek, özellikle bir subgraph birden fazla dapp tarafından kullanıldığında faydalıdır. Bir dapp, subgraph'ini yeni özelliklerle düzenli olarak güncellemek isteyebilir. Diğer bir dapp ise daha eski, iyi test edilmiş bir subgraph sürümünü kullanmayı tercih edebilir. İlk kürasyon sırasında, %1'lik standart bir vergi alınır.
 
-Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares.
+Sinyalinizin otomatik olarak en yeni üretim sürümüne geçiş yapması, sorgu ücretlerini biriktirmeye devam etmenizi sağlamak açısından değerli olabilir. Her kürasyon yaptığınızda %1'lik bir kürasyon vergisi uygulanır. Ayrıca her geçişte %0,5'lik bir kürasyon vergisi ödersiniz. Subgraph geliştiricilerinin sık sık yeni sürümler yayımlaması teşvik edilmez - geliştiriciler otomatik olarak taşınan tüm kürasyon payları için %0,5 kürasyon vergisi ödemek zorundadırlar.
 
-> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, and also transfers tokens into The Graph proxy.
+> **Not**: Belirli bir subgraph'e ilk kez sinyal veren adres ilk küratör olarak kabul edilir. Bu ilk sinyal işlemi, sonraki küratörlerinkine kıyasla çok daha fazla gaz tüketen bir işlemdir. Bunun nedeni, ilk küratörün kürasyon payı token'larını ilklendirmesi ve ayrıca token'ları The Graph proxy'sine aktarmasıdır.
 
-## Withdrawing your GRT
+## GRT'nizi Çekme
 
-Curators have the option to withdraw their signaled GRT at any time.
+Küratörler, sinyal verdikleri GRT'yi istedikleri zaman çekme seçeneğine sahiptir.
 
-Unlike the process of delegating, if you decide to withdraw your signaled GRT you will not have to wait for a cooldown period and will receive the entire amount (minus the 1% curation tax).
+Yetkilendirme sürecinden farklı olarak, sinyal verdiğiniz GRT'yi çekmeye karar verirseniz bir bekleme süresiyle karşılaşmazsınız ve (%1 kürasyon vergisi düşüldükten sonra) toplam miktarı alırsınız.
 
-Once a curator withdraws their signal, indexers may choose to keep indexing the subgraph, even if there's currently no active GRT signaled.
+Bir küratör sinyalini çektikten sonra, endeksleyiciler aktif olarak sinyal verilmiş GRT olmasa bile subgraph'i endekslemeye devam etmeyi seçebilirler.
 
-However, it is recommended that curators leave their signaled GRT in place not only to receive a portion of the query fees, but also to ensure reliability and uptime of the subgraph.
+Ancak, küratörlerin sinyal verdikleri GRT'yi yerinde bırakmaları tavsiye edilir; bu yalnızca sorgu ücretlerinden pay almak için değil, aynı zamanda subgraph'in güvenilirliğini ve kesintisiz çalışmasını sağlamak için de önemlidir.
 
-## Risks
+## Riskler
 
-1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
-2. Curation Fee - when a curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned.
+1. The Graph üzerindeki sorgu pazarı henüz nispeten yenidir ve erken aşama piyasa dinamikleri nedeniyle %APY'nin beklediğinizden daha düşük olması riski mevcuttur.
+2. Kürasyon Ücreti - Bir küratör bir subgraph'e GRT ile sinyal verdiğinde, %1'lik bir kürasyon vergisine tabi olur. Bu ücret yakılır.
 3. (Ethereum only) When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dapp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/resources/roles/delegating/delegating/).
-4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
-   - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
-   - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+4. Bir subgraph, bir hata nedeniyle başarısız olabilir. Başarısız subgraph sorgu ücreti biriktirmez. Bu sebeple, geliştiricinin hatayı düzeltip yeni bir sürüm dağıtmasını beklemeniz gerekecektir.
+   - Eğer bir subgraph'in en yeni sürümüne aboneyseniz, paylarınız otomatik olarak o yeni sürüme geçecektir. Bu geçiş sırasında %0,5'lik bir kürasyon vergisi uygulanır.
+   - Belirli bir subgraph sürümüne sinyal verdiyseniz ve bu sürüm başarısız olduysa, kürasyon paylarınızı manuel olarak yakmanız gerekir. Daha sonra yeni subgraph sürümüne sinyal verebilirsiniz; bu işlem sırasında %1'lik bir kürasyon vergisi uygulanır.
 
-## Curation FAQs
+## Kürasyon Hakkında SSS
 
-### 1. What % of query fees do Curators earn?
+### 1. Küratörler, sorgu ücretlerinin yüzde kaçını kazanır?
 
-By signalling on a subgraph, you will earn a share of all the query fees that the subgraph generates. 10% of all query fees go to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+Bir subgraph'e sinyal vererek, subgraph'in ürettiği tüm sorgu ücretlerinden pay alırsınız. Tüm sorgu ücretlerinin %10'u, kürasyon paylarına orantılı olarak Küratörlere gider. Bu %10'luk oran yönetişime tabidir (yani yönetişim kararlarıyla değiştirilebilir).
 
-### 2. How do I decide which subgraphs are high quality to signal on?
+### 2. Sinyal vereceğim subgraph'lerin hangilerinin yüksek kaliteli olduğunu nasıl belirlerim?
 
-Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dapp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+Yüksek kaliteli subgraph'leri bulmak karmaşık bir iştir. Ancak bu duruma farklı şekillerde yaklaşılabilir. Bir Küratör olarak, sorgu hacmi oluşturan güvenilir subgraph'ler aramak istersiniz. Güvenilir bir subgraph; tamamlanmış, doğru ve bir dapp’in veri ihtiyaçlarını destekliyorsa değerli olabilir. Kötü tasarlanmış bir subgraph'in revize edilmesi veya yeniden yayımlanması gerekebilir ve ileride hata alıp çalışmayı durdurabilir. Küratörler için bir subgraph'in değerli olup olmadığını değerlendirmek için subgraph'in mimarisini veya kodunu gözden geçirmesi önemlidir. Sonuç olarak:
 
-- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
-- Curators should also understand the metrics that are available through Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+- Küratörler, bir ağ hakkındaki bilgilerini kullanarak, belirli bir subgraph'in gelecekte daha yüksek veya daha düşük sorgu hacmi oluşturma olasılığını tahmin etmeye çalışabilirler.
+- Küratörler Graph Gezgini üzerinden erişilebilen metrikleri de anlamalıdır. Geçmiş sorgu hacmi ve subgraph geliştiricisinin kim olduğu gibi metrikler, bir subgraph'in sinyal vermeye değer olup olmadığını belirlemekte yardımcı olabilir.
 
 ### 3. Bir subgraph'ı güncellemenin maliyeti nedir?
 
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curator shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because upgrading subgraphs is an onchain action that costs gas.
+Kürasyon paylarınızı yeni bir subgraph sürümüne taşımak %1'lik bir kürasyon vergisine tabidir. Küratörler, bir subgraph'in en yeni sürümüne abone olmayı tercih edebilir. Küratör payları otomatik olarak yeni bir sürüme taşındığında, Küratörler ayrıca kürasyon vergisinin yarısını (yani %0,5) öderler. Çünkü subgraph'lerin yükseltilmesi, zincir üzerinde gerçekleşen ve dolayısıyla gaz harcamayı gerektiren bir eylemdir.
 
 ### 4. Subgraph'ımı ne sıklıkla güncelleyebilirim?
 
 Subgraph'ınızı çok sık güncellememeniz önerilir. Daha fazla ayrıntı için yukarıdaki soruya bakın.
 
-### 5. Can I sell my curation shares?
+### 5. Kürasyon paylarımı satabilir miyim?
 
-Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed).
+Kürasyon payları, tanıdık olabileceğiniz diğer ERC20 token'ları gibi "satın alınamaz" veya "satılamaz." Sadece basılabilir (oluşturulabilir) veya yakılabilir (yok edilebilir).
 
-As a Curator on Arbitrum, you are guaranteed to get back the GRT you initially deposited (minus the tax).
+Arbitrum'da bir Küratör olarak başlangıçta yatırdığınız GRT'yi (vergi düşüldükten sonra) geri almanız garanti edilir.
 
-### 6. Am I eligible for a curation grant?
+### 6. Kürasyon hibesi için uygun muyum?
 
-Curation grants are determined individually on a case-by-case basis. If you need assistance with curation, please send a request to support@thegraph.zendesk.com.
+Kürasyon hibeleri, bireysel olarak vaka bazında değerlendirilir. Kürasyon konusunda yardıma ihtiyacınız varsa, lütfen support@thegraph.zendesk.com adresine bir talep gönderin.
 
-Still confused? Check out our Curation video guide below:
+Kafanız hala karışık mı? Aşağıdaki Kürasyon video rehberimizi inceleyin:
 
 <VideoEmbed youtube="VytTEcf0dxQ" />

From 83a30fa9211920616ab5737f6679277bc5130335 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 08:35:41 -0500
Subject: [PATCH 3779/3820] New translations publishing-a-subgraph.mdx
 (Turkish)

---
 .../subgraphs/developing/publishing/publishing-a-subgraph.mdx   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx b/website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
index 153932540a56..e481d50a966a 100644
--- a/website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
+++ b/website/pages/tr/subgraphs/developing/publishing/publishing-a-subgraph.mdx
@@ -77,7 +77,7 @@ Geliştiriciler, Endeksleyicileri bir subgraph'i sorgulamaya teşvik etmek için
 
 [Sunrise Yükseltmesi Endeksleyicisi](/archived/sunrise/#what-is-the-upgrade-indexer), tüm subgraph'lerin endekslenmesini sağlar. Ancak, belirli bir subgraph'e GRT sinyali eklemek, daha fazla Endeksleyiciyi bu subgraph'e çekecektir. Küratörlük yoluyla ek Endeksleyicilerin teşvik edilmesi, sorgular için hizmet kalitesini artırmayı, gecikmeyi azaltmayı ve ağ kullanılabilirliğini iyileştirmeyi amaçlar.
 
-When signaling, Curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. If they signal using auto-migrate, a curator’s shares will always be updated to the latest version published by the developer. If they decide to signal on a specific version instead, shares will always stay on this specific version.
+Sinyal verirken, Küratörler belirli bir subgraph sürümüne sinyal vermeyi veya otomatik geçiş (auto-migrate) özelliğini kullanmayı seçebilirler. Eğer otomatik geçiş özelliğini kullanarak sinyal verirlerse, bir küratörün payları her zaman geliştirici tarafından yayımlanan en son sürüme göre güncellenir. Bunun yerine belirli bir sürüme sinyal vermeyi seçerlerse, paylar her zaman bu belirli sürümdeki haliyle kalır.
 
 Endeksleyiciler, Graph Gezgini'nde gördükleri küratörlük sinyallerine göre endeksleyecekleri subgraph'leri bulabilirler.
 

From 1a37a264573597d59dc5b82a5e8f521eb00eac25 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 08:35:42 -0500
Subject: [PATCH 3780/3820] New translations introduction.mdx (German)

---
 website/pages/de/sps/introduction.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/de/sps/introduction.mdx b/website/pages/de/sps/introduction.mdx
index 1f9e05ca1702..7ed462bc6efb 100644
--- a/website/pages/de/sps/introduction.mdx
+++ b/website/pages/de/sps/introduction.mdx
@@ -1,5 +1,5 @@
 ---
-title: Introduction to Substreams-Powered Subgraphs
+title: Einführung in Substreams-Powered Subgraphen
 ---
 
 Boost your subgraph's efficiency and scalability by using [Substreams](/substreams/introduction/) to stream pre-indexed blockchain data.
@@ -10,7 +10,7 @@ Use a Substreams package (`.spkg`) as a data source to give your subgraph access
 
 ### Besonderheiten
 
-There are two methods of enabling this technology:
+Es gibt zwei Methoden zur Aktivierung dieser Technologie:
 
 1. **Using Substreams [triggers](/sps/triggers/)**: Consume from any Substreams module by importing the Protobuf model through a subgraph handler and move all your logic into a subgraph. This method creates the subgraph entities directly in the subgraph.
 

From b0aa95adde378b751611122597f177d52c3a858f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 08:35:43 -0500
Subject: [PATCH 3781/3820] New translations triggers.mdx (German)

---
 website/pages/de/sps/triggers.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/sps/triggers.mdx b/website/pages/de/sps/triggers.mdx
index 1ecbe25b6727..ab9828bc0427 100644
--- a/website/pages/de/sps/triggers.mdx
+++ b/website/pages/de/sps/triggers.mdx
@@ -1,5 +1,5 @@
 ---
-title: Auslöser für Substreams
+title: Substreams Triggers
 ---
 
 Use Custom Triggers and enable the full use GraphQL.

From 5626c51bbc51bffb0e330cc7899ad56c4f0b435a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 08:35:44 -0500
Subject: [PATCH 3782/3820] New translations delegating.mdx (Turkish)

---
 .../resources/roles/delegating/delegating.mdx | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/website/pages/tr/resources/roles/delegating/delegating.mdx b/website/pages/tr/resources/roles/delegating/delegating.mdx
index 7b2b6bca2f17..58d92fa29f35 100644
--- a/website/pages/tr/resources/roles/delegating/delegating.mdx
+++ b/website/pages/tr/resources/roles/delegating/delegating.mdx
@@ -1,5 +1,5 @@
 ---
-title: Delegating
+title: Delegasyon
 ---
 
 To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
@@ -51,22 +51,22 @@ Indexers can increase their Delegation Capacity by increasing their Self-Stake,
 
 There are two sections in this guide:
 
-- The risks of delegating tokens in The Graph Network
-- How to calculate expected returns as a Delegator
+- The Graph Ağı'nda token delege etmenin riskleri
+- Bir Delegatör olarak beklenen getirilerin nasıl hesaplandığı
 
-## Delegation Risks
+## Delegasyon Riskleri
 
-Listed below are the main risks of being a Delegator in the protocol.
+Aşağıda, protokolde Delegatör olmanın başlıca riskleri listelenmiştir.
 
 ### The Delegation Tax
 
-Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+Delegatörler kötü davranışları nedeniyle cezalandırılmaz (slashing uygulanmaz), ancak ağın bütünlüğüne zarar verebilecek kötü kararları caydırmak için bir vergi bulunur.
 
-As a Delegator, it's important to understand the following:
+Bir Delegatör olarak aşağıdakileri anlamak önemlidir:
 
-- You will be charged 0.5% every time you delegate. This means that if you delegate 1,000 GRT, you will automatically burn 5 GRT.
+- Her devir işleminizde %0,5 ücret alınır. Bu, 1.000 GRT devrettiğinizde otomatik olarak 5 GRT'nin yakılacağı anlamına gelir.
 
-- In order to be safe, you should calculate your potential return when delegating to an Indexer. For example, you might calculate how many days it will take before you have earned back the 0.5% tax on your delegation.
+- Önlem olarak, bir Endeksleyiciye delege ederken potansiyel getirilerinizi hesaplamalısınız. Örneğin, delegasyon işlemi için ödediğiniz %0,5 vergiyi geri kazanmanızın kaç gün süreceğini hesaplayabilirsiniz.
 
 ### The Undelegation Period
 
@@ -76,7 +76,7 @@ This means they cannot transfer their tokens or earn any rewards for 28 days.
 
 After the undelegation period, GRT will return to your crypto wallet.
 
-### Why is this important?
+### Bu neden önemli?
 
 If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
 

From c69d22da0a880b4679b0df38f8dc4da463f9c1fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 09:52:16 -0500
Subject: [PATCH 3783/3820] New translations avoid-eth-calls.mdx (Chinese
 Simplified)

---
 website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx
index a0613bf2b69f..3649a1b0a4cf 100644
--- a/website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx
+++ b/website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -97,7 +97,7 @@ The handler itself accesses the result of this `eth_call` exactly as in the prev
 
 Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
 
-## Conclusion
+## 结论
 
 You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
 

From 8d6236b2cd47117c627659202fd2439881e8fa71 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 09:52:18 -0500
Subject: [PATCH 3784/3820] New translations derivedfrom.mdx (Chinese
 Simplified)

---
 website/pages/zh/subgraphs/cookbook/derivedfrom.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/derivedfrom.mdx b/website/pages/zh/subgraphs/cookbook/derivedfrom.mdx
index 22845a8d7dd2..e4cad6ef44c0 100644
--- a/website/pages/zh/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/zh/subgraphs/cookbook/derivedfrom.mdx
@@ -67,7 +67,7 @@ This will not only make our subgraph more efficient, but it will also unlock thr
 
 3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
 
-## Conclusion
+## 结论
 
 Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
 

From ef09538b920b6692adb83d8e23c6405063e15511 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 09:52:19 -0500
Subject: [PATCH 3785/3820] New translations pruning.mdx (Chinese Simplified)

---
 website/pages/zh/subgraphs/cookbook/pruning.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/pruning.mdx b/website/pages/zh/subgraphs/cookbook/pruning.mdx
index c6b1217db9a5..f4629fa3556e 100644
--- a/website/pages/zh/subgraphs/cookbook/pruning.mdx
+++ b/website/pages/zh/subgraphs/cookbook/pruning.mdx
@@ -36,7 +36,7 @@ dataSources:
 
 - It is not possible to [graft](/subgraphs/cookbook/grafting/) at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use `indexerHints: prune: <Number of blocks to retain>` that will accurately retain a set number of blocks (e.g., enough for six months).
 
-## Conclusion
+## 结论
 
 Pruning using `indexerHints` is a best practice for subgraph development, offering significant query performance improvements.
 

From a3c01bfaf1fbe12e6c2520a8ecf928bb3d5acdf6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 09:52:20 -0500
Subject: [PATCH 3786/3820] New translations secure-api-keys-nextjs.mdx
 (Chinese Simplified)

---
 website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index ad2aa7315e87..8baf8d065c51 100644
--- a/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -118,6 +118,6 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ![Server-side rendering](/img/api-key-server-side-rendering.png)
 
-### Conclusion
+### 结论
 
 By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From 09493e1c978020e18687d681ce2651da16004319 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 09:52:21 -0500
Subject: [PATCH 3787/3820] New translations timeseries.mdx (Chinese
 Simplified)

---
 website/pages/zh/subgraphs/cookbook/timeseries.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/timeseries.mdx b/website/pages/zh/subgraphs/cookbook/timeseries.mdx
index 7ac1de481272..8ae051e8fb34 100644
--- a/website/pages/zh/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/zh/subgraphs/cookbook/timeseries.mdx
@@ -169,7 +169,7 @@ Supported operators and functions include basic arithmetic (+, -, \_, /), compar
 - Sorting: Results are automatically sorted by timestamp and id in descending order.
 - Current Data: An optional current argument can include the current, partially filled interval.
 
-### Conclusion
+### 结论
 
 Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
 

From e41468f397dd7ad0e121cf5a7a5207f9fa2a0c77 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 09:52:23 -0500
Subject: [PATCH 3788/3820] New translations triggers.mdx (German)

---
 website/pages/de/sps/triggers.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/de/sps/triggers.mdx b/website/pages/de/sps/triggers.mdx
index ab9828bc0427..81a3e546450a 100644
--- a/website/pages/de/sps/triggers.mdx
+++ b/website/pages/de/sps/triggers.mdx
@@ -1,5 +1,5 @@
 ---
-title: Substreams Triggers
+title: Trigger für Substreams
 ---
 
 Use Custom Triggers and enable the full use GraphQL.

From 27c9173b47909ab94ee36c853e4fe43194b4e5cf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 09:52:24 -0500
Subject: [PATCH 3789/3820] New translations delegating.mdx (Turkish)

---
 .../resources/roles/delegating/delegating.mdx | 50 ++++++++-----------
 1 file changed, 22 insertions(+), 28 deletions(-)

diff --git a/website/pages/tr/resources/roles/delegating/delegating.mdx b/website/pages/tr/resources/roles/delegating/delegating.mdx
index 58d92fa29f35..06d54733adf6 100644
--- a/website/pages/tr/resources/roles/delegating/delegating.mdx
+++ b/website/pages/tr/resources/roles/delegating/delegating.mdx
@@ -82,31 +82,25 @@ If you choose an Indexer that is not trustworthy or not doing a good job, you wi
 
 As a result, it’s recommended that you choose an Indexer wisely.
 
-<div sx={{ mx: 'auto', maxWidth: '400px' }}>
-  ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
-  unbonding period._
-</div>
+<div sx={{ mx: 'auto', maxWidth: '400px' }}> ![Delegasyon çözülme süresi](/img/Delegation-Unbonding.png) _Yetkilendirme arayüzündeki %0,5 ücreti ve 28 günlük iptal edilme süresini unutmayın._ </div>
 
-#### Delegation Parameters
+#### Delegasyon Parametreleri
 
-In order to understand how to choose a trustworthy Indexer, you need to understand the Delegation Parameters.
+Güvenilir bir Endeksleyici nasıl seçebileceğinizi anlamak için Delegasyon Parametrelerini anlamanız gerekir.
 
-- **Indexing Reward Cut** - The portion of the rewards the Indexer will keep for themselves.
-  - If an Indexer's reward cut is set to 100%, as a Delegator, you will get 0 indexing rewards.
-  - If it is set to 80%, as a Delegator, you will receive 20%.
+- **Endeksleme Ödülü Kesintisi** - Endeksleyicinin kendisine ayırdığı ödül oranı.
+  - Eğer bir Endeksleyicinin ödül kesintisi %100 olarak ayarlanmışsa, bir Delegatör olarak hiç endeksleme ödülü alamazsınız.
+  - Eğer %80 olarak ayarlanmışsa, bir Delegatör olarak %20 alırsınız.
 
-<div sx={{ mx: 'auto', maxWidth: '700px' }}>
-  ![Indexing Reward Cut](/img/Indexing-Reward-Cut.png) *The top Indexer is giving Delegators 90% of the rewards. The
-  middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
-</div>
+<div sx={{ mx: 'auto', maxWidth: '700px' }}> ![Endeksleme Ödül Kesintisi](/img/Indexing-Reward-Cut.png) *En üstteki Endeksleyici, Delegatörlere ödüllerin %90'ını veriyor. Ortadaki %20'sini veriyor. Alttaki ise yaklaşık %83'ünü veriyor.* </div>
 
-- **Query Fee Cut** - This is just like the Indexing Reward Cut, but it applies to returns on the query fees that the Indexer collects.
+- **Sorgu Ücreti Kesintisi** - Endeksleme Ödülü Kesintisi'ne benzer ancak Endeksleyicinin topladığı, sorgu ücretlerinden elde edilen kazançlara uygulanır.
 
 - It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
 - Many Indexers are active in Discord and will be happy to answer your questions.
 
-## Calculating Delegators Expected Return
+## Delegatörlerin Beklenen Getirisini Hesaplama
 
 > Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
@@ -118,32 +112,32 @@ If an Indexer does not allocate all the GRT at their disposal, they may miss out
 
 Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
-### Considering the query fee cut and indexing fee cut
+### Sorgu ücreti kesintisi ve endeksleme ücreti kesintisini dikkate almak
 
 You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
-The formula is:
+Formül şu şekildedir:
 
-![Delegation Image 3](/img/Delegation-Reward-Formula.png)
+![Delegasyon Resim 3](/img/Delegation-Reward-Formula.png)
 
-### Considering the Indexer's delegation pool
+### Endeksleyicinin delegasyon havuzunu dikkate almak
 
 <VideoEmbed youtube="G0HyUZ0m_Q8" />
 
-Delegators should consider the proportion of the Delegation Pool they own.
+Delegatörler, Delegasyon Havuzu'ndaki paylarının oranını dikkate almalıdır.
 
-All delegation rewards are shared evenly, with a pool rebalancing based on the amount the Delegator deposited into the pool.
+Tüm delegasyon ödülleri eşit olarak paylaşılır ve havuz, Delegatörün havuza yatırdığı miktara göre yeniden dengelenir.
 
-This gives the Delegator a share of the pool:
+Bu, Delegatöre havuzdan bir pay verir:
 
-![Share formula](/img/Share-Forumla.png)
+![Pay formülü](/img/Share-Forumla.png)
 
-> The formula above shows that it is possible for an Indexer offering only 20% to Delegators to provide a better reward than an Indexer giving 90%. Simply do the math to determine the best reward.
+> Yukarıdaki formül, Delegatörlere yalnızca %20 veren bir Endeksleyicinin, %90 veren bir Endeksleyiciden daha iyi ödül sağlayabileceğini göstermektedir. Hesabı yapmak, en iyi ödülü belirlemek için yeterlidir.
 
-## Delegator FAQs and Bugs
+## Delegatör SSS'i ve Sık Karşılaşılan Hatalar
 
-### MetaMask "Pending Transaction" Bug
+### MetaMask "Bekleyen İşlem" Hatası
 
-At times, attempts to delegate to Indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts.
+Bazen MetaMask üzerinden Endeksleyicilere delegasyon yapma girişimleri başarısız olabilir ve bu durum, işlemin uzun süre "Beklemede" veya "Sırada" kalmasına neden olabilir.
 
-A simple resolution to this bug is to restart the browser (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users who have encountered this issue have reported successful transactions after restarting their browser and attempting to delegate.
+Bu hatayı çözmenin basit bir yolu, tarayıcıyı yeniden başlatmaktır (örneğin, adres çubuğuna "abort:restart" yazarak). Bu işlem, cüzdandan gaz ücreti düşmeden tüm önceki girişimleri iptal eder. Bu sorunla karşılaşan birçok kullanıcı, tarayıcıyı yeniden başlattıktan ve delegasyonu tekrar denedikten sonra işlemlerini başarıyla gerçekleştirdiklerini bildirmiştir.

From b53cf6a45dd6f3529cdff901e08305a675ef8c0a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 19:38:04 -0500
Subject: [PATCH 3790/3820] New translations managing-api-keys.mdx (Portuguese)

---
 website/pages/pt/subgraphs/querying/managing-api-keys.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs/querying/managing-api-keys.mdx b/website/pages/pt/subgraphs/querying/managing-api-keys.mdx
index 0592d611312d..e7d1814401bf 100644
--- a/website/pages/pt/subgraphs/querying/managing-api-keys.mdx
+++ b/website/pages/pt/subgraphs/querying/managing-api-keys.mdx
@@ -10,7 +10,7 @@ API keys are needed to query subgraphs. They ensure that the connections between
 
 Go to [Subgraph Studio](https://thegraph.com/studio/) and click the **API Keys** tab to create and manage your API keys for specific subgraphs.
 
-The "API keys" table lists existing API keys and allows you to manage or delete them. For each key, you can see its status, the cost for the current period, the spending limit for the current period, and the total number of queries.
+A tabela "API keys" lista chaves de API existentes, o que lhe dará a habilidade de gestar ou apagá-las. Para cada chave, é possível ver o seu estado, o custo para o período atual, o limite de gastos para o período atual, assim como número total de queries.
 
 You can click the "three dots" menu to the right of a given API key to:
 

From ef341f13ce6c9ca29845e412a3d9a5dfcbcf42ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 21:57:54 -0500
Subject: [PATCH 3791/3820] New translations unit-testing-framework.mdx
 (Chinese Simplified)

---
 .../zh/subgraphs/developing/creating/unit-testing-framework.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/developing/creating/unit-testing-framework.mdx b/website/pages/zh/subgraphs/developing/creating/unit-testing-framework.mdx
index 1f4f9c098742..5bc984a204c0 100644
--- a/website/pages/zh/subgraphs/developing/creating/unit-testing-framework.mdx
+++ b/website/pages/zh/subgraphs/developing/creating/unit-testing-framework.mdx
@@ -1293,7 +1293,7 @@ Using **Matchstick**, subgraph developers are able to run a script that will cal
 
 The test coverage tool takes the compiled test `wasm` binaries and converts them to `wat` files, which can then be easily inspected to see whether or not the handlers defined in `subgraph.yaml` have been called. Since code coverage (and testing as whole) is in very early stages in AssemblyScript and WebAssembly, **Matchstick** cannot check for branch coverage. Instead we rely on the assertion that if a given handler has been called, the event/function for it have been properly mocked.
 
-### 先决条件
+### Prerequisites
 
 To run the test coverage functionality provided in **Matchstick**, there are a few things you need to prepare beforehand:
 

From 91d83a79ecc760b4aed100539b490743a0c4a26a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 21:57:55 -0500
Subject: [PATCH 3792/3820] New translations quick-start.mdx (Chinese
 Simplified)

---
 website/pages/zh/subgraphs/quick-start.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/quick-start.mdx b/website/pages/zh/subgraphs/quick-start.mdx
index cb67c21570dd..3ad430005cff 100644
--- a/website/pages/zh/subgraphs/quick-start.mdx
+++ b/website/pages/zh/subgraphs/quick-start.mdx
@@ -4,7 +4,7 @@ title: 快速开始
 
 Learn how to easily build, publish and query a [subgraph](/subgraphs/developing/developer-faq/#1-what-is-a-subgraph) on The Graph.
 
-## 先决条件
+## Prerequisites
 
 - 一个加密钱包
 - A smart contract address on a [supported network](/supported-networks/)

From 02fd476ec2d5c261d7be16f35e412a93a0b1c959 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 21:57:56 -0500
Subject: [PATCH 3793/3820] New translations overview.mdx (Chinese Simplified)

---
 website/pages/zh/indexing/overview.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/indexing/overview.mdx b/website/pages/zh/indexing/overview.mdx
index 9e54f5e3fa4c..1b31941dba34 100644
--- a/website/pages/zh/indexing/overview.mdx
+++ b/website/pages/zh/indexing/overview.mdx
@@ -340,7 +340,7 @@ cargo run -p graph-node --release -- \
 
 #### 使用 Docker
 
-#### 先决条件
+#### Prerequisites
 
 - **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
 

From bed572cf0757bee86d0b7e79138814b034573c3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 21:57:57 -0500
Subject: [PATCH 3794/3820] New translations secure-api-keys-nextjs.mdx
 (Chinese Simplified)

---
 website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index 8baf8d065c51..6b38ec28489b 100644
--- a/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -22,7 +22,7 @@ In a standard React application, API keys included in the frontend code can be e
 
 ![Client-side rendering](/img/api-key-client-side-rendering.png)
 
-### 先决条件
+### Prerequisites
 
 - An API key from [Subgraph Studio](https://thegraph.com/studio)
 - Basic knowledge of Next.js and React.

From 0b8de6e7c315e9c04035f62ee170747d8ea2e595 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 21:57:58 -0500
Subject: [PATCH 3795/3820] New translations devcontainer.mdx (Chinese
 Simplified)

---
 website/pages/zh/substreams/developing/devcontainer.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/substreams/developing/devcontainer.mdx b/website/pages/zh/substreams/developing/devcontainer.mdx
index 33e466b35f14..5b07c96c97ae 100644
--- a/website/pages/zh/substreams/developing/devcontainer.mdx
+++ b/website/pages/zh/substreams/developing/devcontainer.mdx
@@ -10,7 +10,7 @@ It's a tool to help you build your first project. You can either run it remotely
 
 Inside the Dev Container, the `substreams init` command sets up a code-generated Substreams project, allowing you to easily build a subgraph or an SQL-based solution for data handling.
 
-## 先决条件
+## Prerequisites
 
 - Ensure Docker and VS Code are up-to-date.
 

From abcea9b4d0c1a4dc043984cba622cce48427f4e7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 21:57:59 -0500
Subject: [PATCH 3796/3820] New translations accountchanges.mdx (Chinese
 Simplified)

---
 .../pages/zh/substreams/developing/solana/accountchanges.mdx    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/substreams/developing/solana/accountchanges.mdx b/website/pages/zh/substreams/developing/solana/accountchanges.mdx
index 5c972d0b39cb..8dd581df3761 100644
--- a/website/pages/zh/substreams/developing/solana/accountchanges.mdx
+++ b/website/pages/zh/substreams/developing/solana/accountchanges.mdx
@@ -16,7 +16,7 @@ For each Substreams Solana account block, only the latest update per account is
 
 ## 开始
 
-### 先决条件
+### Prerequisites
 
 Before you begin, ensure that you have the following:
 

From 5a2c00ca229e572c165348bc579fc975a2a9e1a7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 21:58:00 -0500
Subject: [PATCH 3797/3820] New translations pubsubstreams.mdx (Chinese
 Simplified)

---
 website/pages/zh/substreams/pubsubstreams.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/substreams/pubsubstreams.mdx b/website/pages/zh/substreams/pubsubstreams.mdx
index b81e3804ca9d..8faff5b084f7 100644
--- a/website/pages/zh/substreams/pubsubstreams.mdx
+++ b/website/pages/zh/substreams/pubsubstreams.mdx
@@ -12,7 +12,7 @@ A Substreams package is a precompiled binary file that defines the specific data
 
 ## Publish a Package
 
-### 先决条件
+### Prerequisites
 
 - You must have the Substreams CLI installed.
 - You must have a Substreams package (`.spkg`) that you want to publish.

From 7aab581b27ae437242aa801c2efca672088ebe18 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 21:58:01 -0500
Subject: [PATCH 3798/3820] New translations tutorial.mdx (Chinese Simplified)

---
 website/pages/zh/sps/tutorial.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/website/pages/zh/sps/tutorial.mdx b/website/pages/zh/sps/tutorial.mdx
index 2d91bedf1046..d07654ff0dfc 100644
--- a/website/pages/zh/sps/tutorial.mdx
+++ b/website/pages/zh/sps/tutorial.mdx
@@ -8,7 +8,7 @@ Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL
 
 For a video tutorial, check out [How to Index Solana with a Substreams-powered Subgraph](/sps/tutorial/#video-tutorial)
 
-### 先决条件
+### Prerequisites
 
 Before starting, make sure to:
 
@@ -141,7 +141,7 @@ npm run protogen
 
 This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
 
-### Conclusion
+### 结论
 
 Congratulations! You've successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token. You can take the next step by customizing your schema, mappings, and modules to fit your specific use case.
 

From 7bb3c647c0a27a9c7599a74efcb61b7e1e5af72d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 23:08:11 -0500
Subject: [PATCH 3799/3820] New translations avoid-eth-calls.mdx (Chinese
 Simplified)

---
 website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx b/website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx
index 3649a1b0a4cf..a0613bf2b69f 100644
--- a/website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx
+++ b/website/pages/zh/subgraphs/cookbook/avoid-eth-calls.mdx
@@ -97,7 +97,7 @@ The handler itself accesses the result of this `eth_call` exactly as in the prev
 
 Note: Declared eth_calls can only be made in subgraphs with specVersion >= 1.2.0.
 
-## 结论
+## Conclusion
 
 You can significantly improve indexing performance by minimizing or eliminating `eth_calls` in your subgraphs.
 

From 6f62942121029b4d59ec76c74b843cc7a9ae73cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 23:08:12 -0500
Subject: [PATCH 3800/3820] New translations derivedfrom.mdx (Chinese
 Simplified)

---
 website/pages/zh/subgraphs/cookbook/derivedfrom.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/derivedfrom.mdx b/website/pages/zh/subgraphs/cookbook/derivedfrom.mdx
index e4cad6ef44c0..22845a8d7dd2 100644
--- a/website/pages/zh/subgraphs/cookbook/derivedfrom.mdx
+++ b/website/pages/zh/subgraphs/cookbook/derivedfrom.mdx
@@ -67,7 +67,7 @@ This will not only make our subgraph more efficient, but it will also unlock thr
 
 3. We can use [Derived Field Loaders](/subgraphs/developing/creating/graph-ts/api/#looking-up-derived-entities) to unlock the ability to directly access and manipulate data from virtual relationships in our subgraph mappings.
 
-## 结论
+## Conclusion
 
 Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
 

From 5112e49ab26573ce159ff3ed6129936f3e709b75 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 23:08:13 -0500
Subject: [PATCH 3801/3820] New translations secure-api-keys-nextjs.mdx
 (Chinese Simplified)

---
 website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx b/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx
index 6b38ec28489b..ae2201109356 100644
--- a/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx
+++ b/website/pages/zh/subgraphs/cookbook/secure-api-keys-nextjs.mdx
@@ -118,6 +118,6 @@ Start our Next.js application using `npm run dev`. Verify that the server compon
 
 ![Server-side rendering](/img/api-key-server-side-rendering.png)
 
-### 结论
+### Conclusion
 
 By utilizing Next.js Server Components, we've effectively hidden the API key from the client-side, enhancing the security of our application. This method ensures that sensitive operations are handled server-side, away from potential client-side vulnerabilities. Finally, be sure to explore [other API key security measures](/subgraphs/querying/managing-api-keys/) to increase your API key security even further.

From a9898882404b51b7394c95fe9d760483ae5e7eeb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Wed, 12 Feb 2025 23:08:14 -0500
Subject: [PATCH 3802/3820] New translations timeseries.mdx (Chinese
 Simplified)

---
 website/pages/zh/subgraphs/cookbook/timeseries.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/timeseries.mdx b/website/pages/zh/subgraphs/cookbook/timeseries.mdx
index 8ae051e8fb34..7ac1de481272 100644
--- a/website/pages/zh/subgraphs/cookbook/timeseries.mdx
+++ b/website/pages/zh/subgraphs/cookbook/timeseries.mdx
@@ -169,7 +169,7 @@ Supported operators and functions include basic arithmetic (+, -, \_, /), compar
 - Sorting: Results are automatically sorted by timestamp and id in descending order.
 - Current Data: An optional current argument can include the current, partially filled interval.
 
-### 结论
+### Conclusion
 
 Implementing timeseries and aggregations in subgraphs is a best practice for projects dealing with time-based data. This approach:
 

From 8d5740e2e8efb3c0b2f4b2ca6b1be8524d82318d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 05:06:24 -0500
Subject: [PATCH 3803/3820] New translations sps-faq.mdx (German)

---
 website/pages/de/sps/sps-faq.mdx | 52 ++++++++++++++++----------------
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/website/pages/de/sps/sps-faq.mdx b/website/pages/de/sps/sps-faq.mdx
index dc99e916ed7a..15252f60c5ea 100644
--- a/website/pages/de/sps/sps-faq.mdx
+++ b/website/pages/de/sps/sps-faq.mdx
@@ -1,8 +1,8 @@
 ---
-title: Substreams-Powered Subgraphs FAQ
+title: Substreams-basierte Subgraphen FAQ
 ---
 
-## What are Substreams?
+## Was sind Substreams?
 
 Substreams is an exceptionally powerful processing engine capable of consuming rich streams of blockchain data. It allows you to refine and shape blockchain data for fast and seamless digestion by end-user applications.
 
@@ -10,59 +10,59 @@ Specifically, it's a blockchain-agnostic, parallelized, and streaming-first engi
 
 Substreams is developed by [StreamingFast](https://www.streamingfast.io/). Visit the [Substreams Documentation](/substreams/introduction/) to learn more about Substreams.
 
-## What are Substreams-powered subgraphs?
+## Was sind Substreams-basierte Subgraphen?
 
 [Substreams-powered subgraphs](/sps/introduction/) combine the power of Substreams with the queryability of subgraphs. When publishing a Substreams-powered Subgraph, the data produced by the Substreams transformations, can [output entity changes](https://github.com/streamingfast/substreams-sink-entity-changes/blob/develop/substreams-entity-change/src/tables.rs) that are compatible with subgraph entities.
 
 If you are already familiar with subgraph development, note that Substreams-powered subgraphs can then be queried just as if it had been produced by the AssemblyScript transformation layer. This provides all the benefits of subgraphs, including a dynamic and flexible GraphQL API.
 
-## How are Substreams-powered subgraphs different from subgraphs?
+## Wie unterscheiden sich Substreams-basierte Subgraphen von Subgraphen?
 
-Subgraphs are made up of datasources which specify onchain events, and how those events should be transformed via handlers written in Assemblyscript. These events are processed sequentially, based on the order in which events happen onchain.
+Subgraphen bestehen aus Datenquellen, die Onchain-Ereignisse spezifizieren und angeben, wie diese Ereignisse über in Assemblyscript geschriebene Handler umgewandelt werden sollen. Diese Ereignisse werden nacheinander verarbeitet, basierend auf der Reihenfolge, in der die Ereignisse in der Kette auftreten.
 
-By contrast, substreams-powered subgraphs have a single datasource which references a substreams package, which is processed by the Graph Node. Substreams have access to additional granular onchain data compared to conventional subgraphs, and can also benefit from massively parallelised processing, which can mean much faster processing times.
+Im Gegensatz dazu haben Substreams-basierte Subgraphen eine einzige Datenquelle, die auf ein Substreams-Paket verweist, das vom Graph Node verarbeitet wird. Substreams haben im Vergleich zu herkömmlichen Subgraphen Zugriff auf zusätzliche granulare Onchain-Daten und können zudem von einer massiv parallelisierten Verarbeitung profitieren, was zu deutlich schnelleren Verarbeitungszeiten führen kann.
 
-## What are the benefits of using Substreams-powered subgraphs?
+## Was sind die Vorteile der Verwendung von Substreams-basierten Subgraphen?
 
 Substreams-powered subgraphs combine all the benefits of Substreams with the queryability of subgraphs. They bring greater composability and high-performance indexing to The Graph. They also enable new data use cases; for example, once you've built your Substreams-powered Subgraph, you can reuse your [Substreams modules](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) to output to different [sinks](https://substreams.streamingfast.io/reference-and-specs/manifests#sink) such as PostgreSQL, MongoDB, and Kafka.
 
-## What are the benefits of Substreams?
+## Was sind die Vorteile von Substreams?
 
-There are many benefits to using Substreams, including:
+Die Verwendung von Substreams hat viele Vorteile, unter anderem:
 
-- Composable: You can stack Substreams modules like LEGO blocks, and build upon community modules, further refining public data.
+- Zusammensetzbar: Sie können Substreams-Module wie LEGO-Steine stapeln und auf Community-Modulen aufbauen, um öffentliche Daten weiter zu verfeinern.
 
-- High-performance indexing: Orders of magnitude faster indexing through large-scale clusters of parallel operations (think BigQuery).
+- Leistungsstarke Indexierung: Um Größenordnungen schnellere Indizierung durch groß angelegte Cluster paralleler Operationen (siehe BigQuery).
 
-- Sink anywhere: Sink your data to anywhere you want: PostgreSQL, MongoDB, Kafka, subgraphs, flat files, Google Sheets.
+- Versenken Sie überall: Versenken Sie Ihre Daten, wo immer Sie wollen: PostgreSQL, MongoDB, Kafka, Subgraphen, Flat Files, Google Sheets.
 
-- Programmable: Use code to customize extraction, do transformation-time aggregations, and model your output for multiple sinks.
+- Programmierbar: Verwenden Sie Code, um die Extraktion anzupassen, Aggregationen zur Transformationszeit durchzuführen und Ihre Ausgabe für mehrere Sinken zu modellieren.
 
-- Access to additional data which is not available as part of the JSON RPC
+- Zugang zu zusätzlichen Daten, die nicht als Teil des JSON RPC verfügbar sind
 
-- All the benefits of the Firehose.
+- Alle Vorteile von Firehose.
 
-## What is the Firehose?
+## Was ist überhaupt Firehose?
 
-Developed by [StreamingFast](https://www.streamingfast.io/), the Firehose is a blockchain data extraction layer designed from scratch to process the full history of blockchains at speeds that were previously unseen. Providing a files-based and streaming-first approach, it is a core component of StreamingFast's suite of open-source technologies and the foundation for Substreams.
+Der von [StreamingFast] (https://www.streamingfast.io/) entwickelte Firehose ist eine Blockchain-Datenextraktionsschicht, die von Grund auf neu entwickelt wurde, um die gesamte Historie von Blockchains mit bisher nicht gekannter Geschwindigkeit zu verarbeiten. Sie bietet einen dateibasierten und streamingorientierten Ansatz und ist eine Kernkomponente der Open-Source-Technologien von StreamingFast und die Grundlage für Substreams.
 
-Go to the [documentation](https://firehose.streamingfast.io/) to learn more about the Firehose.
+Besuchen Sie die [Dokumentation] (https://firehose.streamingfast.io/), um mehr über Firehose zu erfahren.
 
-## What are the benefits of the Firehose?
+## Was sind die Vorteile von Firehose?
 
-There are many benefits to using Firehose, including:
+Die Verwendung von Firehose bietet viele Vorteile, darunter:
 
-- Lowest latency & no polling: In a streaming-first fashion, the Firehose nodes are designed to race to push out the block data first.
+- Geringste Latenz und kein Polling: Die Firehose-Knoten sind so konstruiert, dass sie die Blockdaten zuerst herausgeben, und zwar nach dem Streaming-Prinzip.
 
-- Prevents downtimes: Designed from the ground up for High Availability.
+- Verhindert Ausfallzeiten: Von Grund auf für Hochverfügbarkeit konzipiert.
 
-- Never miss a beat: The Firehose stream cursor is designed to handle forks and to continue where you left off in any condition.
+- Verpassen Sie nie einen Beat: Der Firehose Stream Cursor ist so konzipiert, dass er mit Forks umgehen kann und in jeder Situation dort weitermacht, wo Sie aufgehört haben.
 
-- Richest data model:  Best data model that includes the balance changes, the full call tree, internal transactions, logs, storage changes, gas costs, and more.
+- Umfangreichstes Datenmodell: Bestes Datenmodell, das die Änderungen des Kontostands, den vollständigen Aufrufbaum, interne Transaktionen, Logs, Speicheränderungen, Gaskosten und mehr enthält.
 
-- Leverages flat files: Blockchain data is extracted into flat files, the cheapest and most optimized computing resource available.
+- Nutzung von Flat Files: Blockchain-Daten werden in Flat Files extrahiert, der billigsten und optimalsten verfügbaren Rechenressource.
 
-## Where can developers access more information about Substreams-powered subgraphs and Substreams?
+## Wo erhalten Entwickler weitere Informationen über Substreams-basieren Subgraphen und Substreams?
 
 The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
 

From fabae4721e40211b28f6df90bdf5f0740e8fa10e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 05:06:26 -0500
Subject: [PATCH 3804/3820] New translations triggers.mdx (German)

---
 website/pages/de/sps/triggers.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/de/sps/triggers.mdx b/website/pages/de/sps/triggers.mdx
index 81a3e546450a..17617c02afa3 100644
--- a/website/pages/de/sps/triggers.mdx
+++ b/website/pages/de/sps/triggers.mdx
@@ -12,7 +12,7 @@ By importing the Protobuf definitions emitted by your Substreams module, you can
 
 ### Defining `handleTransactions`
 
-The following code demonstrates how to define a `handleTransactions` function in a subgraph handler. This function receives raw Substreams bytes as a parameter and decodes them into a `Transactions` object. For each transaction, a new subgraph entity is created.
+Der folgende Code veranschaulicht, wie eine Funktion `handleTransactions` in einem Subgraph-Handler definiert wird. Diese Funktion empfängt rohe Substream-Bytes als Parameter und dekodiert sie in ein `Transactions`-Objekt. Für jede Transaktion wird eine neue Subgraph-Entität erstellt.
 
 ```tsx
 export function handleTransactions(bytes: Uint8Array): void {
@@ -36,9 +36,9 @@ export function handleTransactions(bytes: Uint8Array): void {
 
 Here's what you're seeing in the `mappings.ts` file:
 
-1. The bytes containing Substreams data are decoded into the generated `Transactions` object, this object is used like any other AssemblyScript object
-2. Looping over the transactions
-3. Create a new subgraph entity for every transaction
+1. Die Bytes, die die Substreams enthalten, werden in das generierte `Transactions`-Objekt dekodiert. Dieses Objekt wird wie jedes andere AssemblyScript-Objekt verwendet
+2. Looping über die Transaktionen
+3. Erstellen einer neuen Subgraph-Entität für jede Transaktion
 
 To go through a detailed example of a trigger-based subgraph, [check out the tutorial](/sps/tutorial/).
 

From 7beea4c9b84a3184a205f683174099701d8da62d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 05:06:27 -0500
Subject: [PATCH 3805/3820] New translations tutorial.mdx (German)

---
 website/pages/de/sps/tutorial.mdx | 70 +++++++++++++++----------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/website/pages/de/sps/tutorial.mdx b/website/pages/de/sps/tutorial.mdx
index 216df687b3f7..f0a85cdc8b7b 100644
--- a/website/pages/de/sps/tutorial.mdx
+++ b/website/pages/de/sps/tutorial.mdx
@@ -1,5 +1,5 @@
 ---
-title: "Tutorial: Set Up a Substreams-Powered Subgraph on Solana"
+title: "Tutorial: Einrichten eines Substreams-basierten Subgraphen auf Solana"
 ---
 
 Successfully set up a trigger-based Substreams-powered subgraph for a Solana SPL token.
@@ -10,75 +10,75 @@ For a video tutorial, check out [How to Index Solana with a Substreams-powered S
 
 ### Vorbedingungen
 
-Before starting, make sure to:
+Bevor Sie beginnen, stellen Sie Folgendes sicher:
 
-- Complete the [Getting Started Guide](https://github.com/streamingfast/substreams-starter) to set up your development environment using a Dev Container.
-- Be familiar with The Graph and basic blockchain concepts such as transactions and Protobufs.
+- Vervollständigen Sie das [Erste-Schritte-Guide] (https://github.com/streamingfast/substreams-starter), um Ihre Entwicklungsumgebung mit einem Dev Container einzurichten.
+- Sie sollten mit The Graph und grundlegenden Blockchain-Konzepten wie Transaktionen und Protobufs vertraut sein.
 
-### Step 1: Initialize Your Project
+### Schritt 1: Initialisieren Sie Ihr Projekt
 
-1. Open your Dev Container and run the following command to initialize your project:
+1. Öffnen Sie Ihren Dev Container und führen Sie den folgenden Befehl aus, um Ihr Projekt zu initialisieren:
 
    ```bash
    substreams init
    ```
 
-2. Select the "minimal" project option.
+2. Wählen Sie die Option „Minimalprojekt“.
 
-3. Replace the contents of the generated `substreams.yaml` file with the following configuration, which filters transactions for the Orca account on the SPL token program ID:
+3. Ersetzen Sie den Inhalt der generierten Datei `substreams.yaml` durch die folgende Konfiguration, die Transaktionen für das Orca-Konto nach der SPL-Token-Programm-ID filtert:
 
 ```yaml
 specVersion: v0.1.0
-package:
-  name: my_project_sol
-  version: v0.1.0
+Paket:
+  Name: my_project_sol
+  Version: v0.1.0
 
-imports: # Pass your spkg of interest
+importiert: # Übergeben Sie Ihr spkg von Interesse
   solana: https://github.com/streamingfast/substreams-solana-spl-token/raw/master/tokens/solana-spl-token-v0.1.0.spkg
 
-modules:
+Module:
   - name: map_spl_transfers
-    use: solana:map_block # Select corresponding modules available within your spkg
+    use: solana:map_block # Wählen Sie die entsprechenden Module aus, die in Ihrem spkg verfügbar sind
     initialBlock: 260000082
 
   - name: map_transactions_by_programid
     use: solana:solana:transactions_by_programid_without_votes
 
-network: solana-mainnet-beta
+netzwerk: solana-mainnet-beta
 
-params: # Modify the param fields to meet your needs
-  # For program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
+params: # Passen Sie die param-Felder an Ihre Bedürfnisse an.
+  # Für program_id: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
   map_spl_transfers: token_contract:orcaEKTdK7LKz57vaAYr9QeNsVEPfiu6QeMU1kektZE
 ```
 
-### Step 2: Generate the Subgraph Manifest
+### Schritt 2: Erzeugen des Subgraph-Manifests
 
-Once the project is initialized, generate a subgraph manifest by running the following command in the Dev Container:
+Sobald das Projekt initialisiert ist, erzeugen Sie ein Subgraph-Manifest, indem Sie den folgenden Befehl im Dev Container ausführen:
 
 ```bash
 substreams codegen subgraph
 ```
 
-You will generate a`subgraph.yaml` manifest which imports the Substreams package as a data source:
+Sie erzeugen ein `subgraph.yaml`-Manifest, das das Substreams-Paket als Datenquelle importiert:
 
 ```yaml
 ---
 dataSources:
-  - kind: substreams
-    name: my_project_sol
-    network: solana-mainnet-beta
-    source:
+  - art: substreams
+    Name: mein_Projekt_sol
+    Netzwerk: solana-mainnet-beta
+    Quelle:
       package:
-        moduleName: map_spl_transfers # Module defined in the substreams.yaml
-        file: ./my-project-sol-v0.1.0.spkg
+        moduleName: map_spl_transfers # Modul definiert in der substreams.yaml
+        Datei: ./mein-projekt-sol-v0.1.0.spkg
     mapping:
       apiVersion: 0.0.7
-      kind: substreams/graph-entities
-      file: ./src/mappings.ts
+      Art: substreams/graph-entities
+      Datei: ./src/mappings.ts
       handler: handleTriggers
 ```
 
-### Step 3: Define Entities in `schema.graphql`
+### Schritt 3: Definieren Sie Entitäten in `schema.graphql`
 
 Define the fields you want to save in your subgraph entities by updating the `schema.graphql` file.
 
@@ -94,9 +94,9 @@ type MyTransfer @entity {
 }
 ```
 
-This schema defines a `MyTransfer` entity with fields such as `id`, `amount`, `source`, `designation`, and `signers`.
+Dieses Schema definiert eine `MyTransfer`-Entität mit Feldern wie `id`, `amount`, `source`, `designation` und `signers`.
 
-### Step 4: Handle Substreams Data in `mappings.ts`
+### Schritt 4: Umgang mit Substreams Daten in `mappings.ts`
 
 With the Protobuf objects generated, you can now handle the decoded Substreams data in your `mappings.ts` file found in the `./src` directory.
 
@@ -131,15 +131,15 @@ export function handleTriggers(bytes: Uint8Array): void {
 }
 ```
 
-### Step 5: Generate Protobuf Files
+### Schritt 5: Erzeugen von Protobuf-Dateien
 
-To generate Protobuf objects in AssemblyScript, run the following command:
+Um Protobuf-Objekte in AssemblyScript zu erzeugen, führen Sie den folgenden Befehl aus:
 
 ```bash
 npm run protogen
 ```
 
-This command converts the Protobuf definitions into AssemblyScript, allowing you to use them in the subgraph's handler.
+Dieser Befehl konvertiert die Protobuf-Definitionen in AssemblyScript, so dass Sie sie im Handler des Subgraphen verwenden können.
 
 ### Conclusion
 
@@ -151,4 +151,4 @@ Congratulations! You've successfully set up a trigger-based Substreams-powered s
 
 ### Zusätzliche Ressourcen
 
-For more advanced customization and optimizations, check out the official [Substreams documentation](https://substreams.streamingfast.io/tutorials/solana).
+Für weitergehende Anpassungen und Optimierungen lesen Sie bitte die offizielle [Substreams-Dokumentation] (https://substreams.streamingfast.io/tutorials/solana).

From 6daa3c983aec81632b042aa4567dc8cf9cd3afe2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 07:23:22 -0500
Subject: [PATCH 3806/3820] New translations glossary.mdx (German)

---
 website/pages/de/resources/glossary.mdx | 82 ++++++++++++-------------
 1 file changed, 41 insertions(+), 41 deletions(-)

diff --git a/website/pages/de/resources/glossary.mdx b/website/pages/de/resources/glossary.mdx
index 7f7d789a8550..ffcd4bca2eed 100644
--- a/website/pages/de/resources/glossary.mdx
+++ b/website/pages/de/resources/glossary.mdx
@@ -1,83 +1,83 @@
 ---
-title: Glossar
+title: Glossary
 ---
 
-- **The Graph**: Ein dezentrales Protokoll zur Indizierung und Abfrage von Daten.
+- **The Graph**: A decentralized protocol for indexing and querying data.
 
-- **Abfrage**: Eine Anfrage nach Daten. Im Fall von The Graph ist eine Abfrage eine Anfrage nach Daten aus einem Subgraph, die von einem Indexer beantwortet wird.
+- **Query**: A request for data. In the case of The Graph, a query is a request for data from a subgraph that will be answered by an Indexer.
 
-- **GraphQL**: Eine Abfragesprache für APIs und eine Laufzeitumgebung, um diese Abfragen mit Ihren vorhandenen Daten zu erfüllen. The Graph verwendet GraphQL, um Subgraphen abzufragen.
+- **GraphQL**: A query language for APIs and a runtime for fulfilling those queries with your existing data. The Graph uses GraphQL to query subgraphs.
 
-- **Endpunkt**: Eine URL, die zur Abfrage eines Subgraphen verwendet werden kann. Der Test-Endpunkt für Subgraph Studio ist `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` und der Graph Explorer Endpunkt ist `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. Der The Graph Explorer Endpunkt wird verwendet, um Subgraphen im dezentralen Netzwerk von The Graph abzufragen.
+- **Endpoint**: A URL that can be used to query a subgraph. The testing endpoint for Subgraph Studio is `https://api.studio.thegraph.com/query/<ID>/<SUBGRAPH_NAME>/<VERSION>` and the Graph Explorer endpoint is `https://gateway.thegraph.com/api/<API_KEY>/subgraphs/id/<SUBGRAPH_ID>`. The Graph Explorer endpoint is used to query subgraphs on The Graph's decentralized network.
 
-- **Subgraph**: Eine offene API, die Daten aus einer Blockchain extrahiert, verarbeitet und so speichert, dass sie einfach über GraphQL abgefragt werden können. Entwickler können einen Subgraph erstellen, bereitstellen und auf The Graph Network veröffentlichen. Sobald der Subgraph indiziert ist, kann er von jedem abgefragt werden.
+- **Subgraph**: An open API that extracts data from a blockchain, processes it, and stores it so that it can be easily queried via GraphQL. Developers can build, deploy, and publish subgraphs to The Graph Network. Once it is indexed, the subgraph can be queried by anyone.
 
-- **Indexer**: Netzwerkteilnehmer, die Indexierungsknoten betreiben, um Daten aus Blockchains zu indexieren und GraphQL-Abfragen zu bedienen.
+- **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
 
-- **Einkommensströme für Indexer**: Indexer werden in GRT mit zwei Komponenten belohnt: Rabatte auf Abfragegebühren und Rewards für die Indizierung.
+- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
 
-  1. **Abfragegebühren-Rabatte**: Zahlungen von Subgraph-Konsumenten für die Bedienung von Anfragen im Netz.
+  1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
 
-  2. **Indizierungs-Rewards**: Die Rewards, die Indexer für die Indizierung von Subgraphen erhalten. Indexing Rewards werden durch die Neuausgabe von 3% GRT jährlich generiert.
+  2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
 
-- **Selbstbeteiligung der Indexer**: Der Betrag an GRT, den Indexer einsetzen, um am dezentralen Netzwerk teilzunehmen. Das Minimum beträgt 100.000 GRT, eine Obergrenze gibt es nicht.
+- **Indexer's Self-Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
 
-- **Delegationskapazität**: Die maximale Menge an GRT, die ein Indexer von Delegatoren annehmen kann. Indexer können nur bis zum 16-fachen ihres Indexer-Eigenanteils akzeptieren, und zusätzliche Delegationen führen zu verwässerten Rewards. Ein Datenbeispiel: Wenn ein Indexer eine Selbsteinnahme von 1 Mio. GRT hat, beträgt seine Delegationskapazität 16 Mio. GRT. Indexer können jedoch ihre Delegationskapazität erhöhen, indem sie ihre Selbstbeteiligung erhöhen.
+- **Delegation Capacity**: The maximum amount of GRT an Indexer can accept from Delegators. Indexers can only accept up to 16x their Indexer Self-Stake, and additional delegation results in diluted rewards. For example, if an Indexer has a Self-Stake of 1M GRT, their delegation capacity is 16M. However, Indexers can increase their Delegation Capacity by increasing their Self-Stake.
 
-- **Upgrade Indexer**: Ein Indexer, der als Fallback für Subgraph-Abfragen dient, die von anderen Indexern im Netzwerk nicht bedient werden. Der Upgrade Indexer ist nicht konkurrenzfähig zu anderen Indexern.
+- **Upgrade Indexer**: An Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. The upgrade Indexer is not competitive with other Indexers.
 
-- **Delegator**: Netzwerkteilnehmer, die GRT besitzen und ihre GRT an Indexer delegieren. Dadurch können Indexer ihren Anteil an Subgraphen im Netzwerk erhöhen. Im Gegenzug erhalten Delegatoren einen Teil der Indexing Rewards, die Indexer für die Bearbeitung von Subgraphen erhalten.
+- **Delegator**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
 
-- **Delegationssteuer**: Eine 0,5%ige Gebühr, die von Delegatoren gezahlt wird, wenn sie GRT an Indexer delegieren. Die GRT, die zur Zahlung der Gebühr verwendet werden, werden verbrannt.
+- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
 
-- **Kurator**: Netzwerkteilnehmer, die qualitativ hochwertige Subgraphen identifizieren und GRT für sie im Austausch für Kurationsanteile signalisieren. Wenn Indexer Abfragegebühren für einen Subgraph einfordern, werden 10% an die Kuratoren dieses Subgraphen verteilt. Es besteht eine positive Korrelation zwischen der Höhe der signalisierten GRT und der Anzahl der Indexer, die einen Subgraph indexieren.
+- **Curator**: Network participants that identify high-quality subgraphs, and signal GRT on them in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. There is a positive correlation between the amount of GRT signaled and the number of Indexers indexing a subgraph.
 
-- **Kurationssteuer**: Eine Gebühr von 1 %, die von Kuratoren gezahlt wird, wenn sie GRT auf Subgraphen melden. Die GRT, die zur Zahlung der Gebühr verwendet wird, wird verbrannt.
+- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
 
-- **Datenverbraucher**: Jede Anwendung oder jeder Benutzer, der einen Subgraph abfragt.
+- **Data Consumer**: Any application or user that queries a subgraph.
 
-- **Subgraphen-Entwickler**: Ein Entwickler, der einen Subgraph für das dezentrale Netzwerk von The Graph erstellt und bereitstellt.
+- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
 
-- **Subgraph Manifest**: Eine YAML-Datei, die das GraphQL-Schema, die Datenquellen und andere Metadaten des Subgraphen beschreibt. Ein Beispiel ist [hier](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml).
+- **Subgraph Manifest**: A YAML file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://github.com/graphprotocol/example-subgraph/blob/master/subgraph.yaml) is an example.
 
-- **Epoche**: Eine Zeiteinheit innerhalb des Netzes. Derzeit entspricht eine Epoche 6.646 Blöcken oder etwa 1 Tag.
+- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
 
-- **Zuteilung**: Ein Indexer kann seinen gesamten GRT-Einsatz (einschließlich des Einsatzes der Delegatoren) Subgraphen zuweisen, die im dezentralen Netzwerk von The Graph veröffentlicht wurden. Zuteilungen können verschiedene Status haben:
+- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
 
-  1. **Aktiv**: Eine Zuordnung gilt als aktiv, wenn sie onchain erstellt wird. Dies wird als Öffnen einer Zuordnung bezeichnet und zeigt dem Netzwerk an, dass der Indexer aktiv indiziert und Abfragen für einen bestimmten Subgraph bedient. Aktive Zuweisungen sammeln Rewards für die Indizierung, die proportional zum Signal auf dem Subgraph und der Menge des zugewiesenen GRT sind.
+  1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
 
-  2. **Geschlossen**: Ein Indexer kann die aufgelaufenen Rewards für einen bestimmten Subgraph beanspruchen, indem er einen aktuellen und gültigen Proof of Indexing (POI) einreicht. Dies wird als Schließen einer Zuordnung bezeichnet. Eine Zuordnung muss mindestens eine Epoche lang offen gewesen sein, bevor sie geschlossen werden kann. Die maximale Zuordnungsdauer beträgt 28 Epochen. Lässt ein Indexer eine Zuordnung länger als 28 Epochen offen, wird sie als veraltete Zuordnung bezeichnet. Wenn sich eine Zuordnung im Zustand **Geschlossen** befindet, kann ein Fisherman immer noch einen Disput eröffnen, um einen Indexer wegen der Bereitstellung falscher Daten anzufechten.
+  2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
 
-- **Subgraph Studio**: Eine leistungsstarke App zum Erstellen, Bereitstellen und Veröffentlichen von Subgraphen.
+- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
 
-- **Fischer**: Eine Rolle innerhalb des The Graph Network, die von Teilnehmern eingenommen wird, die die Genauigkeit und Integrität der von Indexern gelieferten Daten überwachen. Wenn ein Fisherman eine Abfrage-Antwort oder einen POI identifiziert, den er für falsch hält, kann er einen Disput gegen den Indexer einleiten. Wenn der Streitfall zu Gunsten des Fischers entschieden wird, verliert der Indexer 2,5 % seines Eigenanteils. Von diesem Betrag erhält der Fischer 50 % als Belohnung für seine Wachsamkeit, und die restlichen 50 % werden aus dem Verkehr gezogen (verbrannt). Dieser Mechanismus soll die Fischer dazu ermutigen, die Zuverlässigkeit des Netzwerks aufrechtzuerhalten, indem sichergestellt wird, dass die Indexer für die von ihnen gelieferten Daten verantwortlich gemacht werden.
+- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed by losing 2.5% of their self-stake. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
 
-- **Schlichter**: Schlichter sind Netzwerkteilnehmer, die im Rahmen eines Governance-Prozesses ernannt werden. Die Rolle des Schiedsrichters besteht darin, über den Ausgang von Streitigkeiten bei Indizierungen und Abfragen zu entscheiden. Ihr Ziel ist es, den Nutzen und die Zuverlässigkeit von The Graph Network zu maximieren.
+- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
 
-- **Kürzung**: Indexer können für die Bereitstellung eines falschen POI oder für die Bereitstellung ungenauer Daten um ihre selbst gesetzten GRT gekürzt werden. Der Prozentsatz des Slashings ist ein Protokollparameter, der derzeit auf 2,5% des Eigenanteils eines Indexers festgelegt ist. 50 % der gekürzten GRT gehen an den Fischer, der die ungenauen Daten oder den falschen POI bestritten hat. Die anderen 50% werden verbrannt.
+- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self-stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
 
-- **Indizierungs-Rewards**: Die Rewards, die Indexer für die Indizierung von Subgraphen erhalten. Indexing Rewards werden in GRT verteilt.
+- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
 
-- **Delegation Rewards**: Die Rewards, die Delegatoren für die Delegierung von GRT an Indexer erhalten. Delegations-Rewards werden in GRT verteilt.
+- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
 
-- **GRT**: The Graph's Work Utility Token. GRT bietet den Netzwerkteilnehmern wirtschaftliche Anreize für ihren Beitrag zum Netzwerk.
+- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
 
-- **Nachweis der Indizierung (POI)**: Wenn ein Indexer seine Zuteilung abschließt und seine angesammelten Rewards für einen bestimmten Subgraph beanspruchen möchte, muss er einen gültigen und aktuellen POI vorlegen. Fischer können den von einem Indexer angegebenen POI anfechten. Ein Streit, der zugunsten des Fischers entschieden wird, führt zur Streichung des Indexers.
+- **Proof of Indexing (POI)**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent POI. Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
 
-- **Graph Node**: Graph Node ist die Komponente, die Subgraphen indiziert und die resultierenden Daten für Abfragen über eine GraphQL-API zur Verfügung stellt. Als solche ist sie von zentraler Bedeutung für den Indexer-Stack, und der korrekte Betrieb von Graph Node ist entscheidend für den erfolgreichen Betrieb eines Indexers.
+- **Graph Node**: Graph Node is the component that indexes subgraphs and makes the resulting data available to query via a GraphQL API. As such it is central to the Indexer stack, and correct operation of Graph Node is crucial to running a successful Indexer.
 
-- **Indexer-Agent**: Der Indexer-Agent ist Teil des Indexer-Stacks. Er erleichtert die Interaktionen des Indexers in der Kette, einschließlich der Registrierung im Netzwerk, der Verwaltung von Subgraph-Bereitstellungen an seine(n) Graph Node(s) und der Verwaltung von Zuweisungen.
+- **Indexer agent**: The Indexer agent is part of the Indexer stack. It facilitates the Indexer's interactions onchain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
 
-- **The Graph Client**: Eine Bibliothek für den Aufbau von GraphQL-basierten Dapps auf dezentralisierte Weise.
+- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
 
-- **Graph Explorer**: Eine App, mit der Netzwerkteilnehmer Subgraphen erkunden und mit dem Protokoll interagieren können.
+- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
 
-- **Graph CLI**: Ein Befehlszeilenschnittstellen-Tool zum Erstellen und Bereitstellen von The Graph.
+- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
 
-- **Abkühlphase**: Die Zeit, die verbleibt, bis ein Indexer, der seine Delegationsparameter geändert hat, dies wieder tun kann.
+- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
 
-- **L2 Transfer Tools**: Smart Contracts und UI, die es Netzwerkteilnehmern ermöglichen, netzwerkbezogene Vermögenswerte vom Ethereum Mainnet auf Arbitrum One zu übertragen. Netzwerkteilnehmer können delegiertes GRT, Subgraphen, Kurationsanteile und den Eigenanteil des Indexers übertragen.
+- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self-stake.
 
-- **Aktualisierung eines Subgraphen**: Der Prozess der Freigabe einer neuen Version eines Subgraphen mit Aktualisierungen des Manifests, des Schemas oder der Mappings des Subgraphen.
+- **Updating a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
 
-- **Migrieren**: Der Prozess, bei dem Kurationsanteile von einer alten Version eines Subgraphs auf eine neue Version eines Subgraphs übertragen werden (z. B. wenn v0.0.1 auf v0.0.2 aktualisiert wird).
+- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).

From 96e3a1ce8ccece7fff509ed6ed8390c6f6487c05 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 07:23:24 -0500
Subject: [PATCH 3807/3820] New translations new-chain-integration.mdx (German)

---
 website/pages/de/indexing/new-chain-integration.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/website/pages/de/indexing/new-chain-integration.mdx b/website/pages/de/indexing/new-chain-integration.mdx
index 55cec71fd3fc..7b577d246783 100644
--- a/website/pages/de/indexing/new-chain-integration.mdx
+++ b/website/pages/de/indexing/new-chain-integration.mdx
@@ -25,7 +25,7 @@ Damit Graph Node Daten aus einer EVM-Kette aufnehmen kann, muss der RPC-Knoten d
 - `eth_getBlockByHash`
 - `net_version`
 - `eth_getTransactionReceipt`, in einem JSON-RPC-Batch-Antrag
-- `trace_filter` _(limited tracing and optionally required for Graph Node)_
+- `trace_filter`  _(begrenztes Tracing und optional erforderlich für Graph Node)_
 
 ### 2. Firehose Integration
 
@@ -33,11 +33,11 @@ Damit Graph Node Daten aus einer EVM-Kette aufnehmen kann, muss der RPC-Knoten d
 
 > HINWEIS: Alle vom StreamingFast-Team durchgeführten Integrationen beinhalten die Wartung des Firehose-Replikationsprotokolls in der Codebasis der Kette. StreamingFast verfolgt alle Änderungen und gibt Binärdateien frei, wenn Sie den Code ändern und wenn StreamingFast den Code ändert. Dies umfasst die Freigabe von Firehose/Substreams-Binärdateien für das Protokoll, die Wartung von Substreams-Modulen für das Blockmodell der Kette und die Freigabe von Binärdateien für den Blockchain-Knoten mit Instrumentierung, falls erforderlich.
 
-#### Integration for Non-EVM chains
+#### Integration für Nicht-EVM-Ketten
 
 Die primäre Methode zur Integration des Firehose in Ketten besteht in der Verwendung einer RPC-Polling-Strategie. Unser Polling-Algorithmus sagt voraus, wann ein neuer Block eintreffen wird und erhöht die Rate, mit der er nach einem neuen Block in der Nähe dieses Zeitpunkts sucht, was eine sehr effiziente Lösung mit geringer Latenz darstellt. Wenn Sie Hilfe bei der Integration und Wartung von Firehose benötigen, wenden Sie sich an das [StreamingFast-Team] (https://www.streamingfast.io/firehose-integration-program). Neue Ketten und ihre Integratoren werden die [Fork-Bewusstsein](https://substreams.streamingfast.io/documentation/consume/reliability-guarantees) und die massiv parallelisierten Indexierungsfähigkeiten zu schätzen wissen, die Firehose und Substreams in ihr Ökosystem einbringen.
 
-#### Specific Instrumentation for EVM (`geth`) chains
+#### Spezifische Instrumentierung für EVM (`geth`) Ketten
 
 Für EVM-Ketten gibt es eine tiefere Ebene von Daten, die durch den `geth` [Live-Tracer](https://github.com/ethereum/go-ethereum/releases/tag/v1.14.0), eine Zusammenarbeit zwischen Go-Ethereum und StreamingFast, beim Aufbau eines durchsatzstarken und umfangreichen Transaktionsverfolgungssystems erreicht werden kann. Der Live-Tracer ist die umfassendste Lösung, die zu [erweiterten](https://streamingfastio.medium.com/new-block-model-to-accelerate-chain-integration-9f65126e5425) Blockdetails führt. Dies ermöglicht neue Indizierungsparadigmen, wie den Musterabgleich von Ereignissen auf der Grundlage von Zustandsänderungen, Aufrufen, übergeordneten Aufrufbäumen oder das Auslösen von Ereignissen auf der Grundlage von Änderungen der tatsächlichen Variablen in einem Smart Contract.
 
@@ -59,7 +59,7 @@ Die Konfiguration von Graph Node ist so einfach wie die Vorbereitung Ihrer lokal
 
 1. [Graph Node klonen](https://github.com/graphprotocol/graph-node)
 
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON-RPC or Firehose compliant URL
+2. Ändern Sie [diese Zeile] (https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22), um den neuen Netzwerknamen und die EVM JSON-RPC- oder Firehose-konforme URL aufzunehmen
 
    > Ändern Sie nicht den Namen der Env-Variable selbst. Er muss `ethereum` bleiben, auch wenn der Netzwerkname anders lautet.
 

From 022fd13e44b8500f0e8c185e2d8c1f4c913a73c2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 07:23:25 -0500
Subject: [PATCH 3808/3820] New translations benefits.mdx (German)

---
 website/pages/de/resources/benefits.mdx | 124 ++++++++++++------------
 1 file changed, 62 insertions(+), 62 deletions(-)

diff --git a/website/pages/de/resources/benefits.mdx b/website/pages/de/resources/benefits.mdx
index 4c48aa984b61..c035f6636b1b 100644
--- a/website/pages/de/resources/benefits.mdx
+++ b/website/pages/de/resources/benefits.mdx
@@ -3,90 +3,90 @@ title: The Graph vs. Self Hosting
 socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
 ---
 
-Das dezentralisierte Netzwerk von The Graph wurde entwickelt und verfeinert, um eine robuste Indizierung und Abfrage zu ermöglichen - und es wird dank Tausender Mitwirkender auf der ganzen Welt jeden Tag besser.
+The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
 
-Die Vorteile dieses dezentralen Protokolls können nicht durch den lokalen Betrieb eines „Graph-Knotens“ repliziert werden. The Graph Network ist zuverlässiger, effizienter und kostengünstiger.
+The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
 
-Hier ist eine Analyse:
+Here is an analysis:
 
-## Warum Sie das The Graph Network nutzen sollten
+## Why You Should Use The Graph Network
 
-- Deutlich niedrigere monatliche Kosten
-- $0 Kosten für die Einrichtung der Infrastruktur
-- Hervorragende Betriebszeiten
-- Zugang zu Hunderten von unabhängigen Indexern auf der ganzen Welt
-- 24/7 technische Unterstützung durch die globale Community
+- Significantly lower monthly costs
+- $0 infrastructure setup costs
+- Superior uptime
+- Access to hundreds of independent Indexers around the world
+- 24/7 technical support by global community
 
-## Die Vorteile werden erklärt
+## The Benefits Explained
 
-### Niedrigere und flexiblere Kostenstruktur
+### Lower & more Flexible Cost Structure
 
-Keine Verträge. Keine monatlichen Gebühren. Sie zahlen nur für die Abfragen, die Sie nutzen - mit durchschnittlichen Kosten pro Abfrage von $40 pro Million Abfragen (~$0,00004 pro Abfrage). Abfragen werden in USD abgerechnet und in GRT oder per Kreditkarte bezahlt.
+No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
 
-Die Abfragekosten können variieren; die angegebenen Kosten sind der Durchschnitt zum Zeitpunkt der Veröffentlichung (März 2024).
+Query costs may vary; the quoted cost is the average at time of publication (March 2024).
 
-## Low Volume User (weniger als 100.000 Abfragen pro Monat)
+## Low Volume User (less than 100,000 queries per month)
 
-|        Kostenvergleich       |               Selbst gehostet              |                        The Graph Network                        |
-| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
-|   Monatliche Serverkosten\*  |               $350 pro Monat               |                                $0                               |
-|         Abfragekosten        |                     $0+                    |                           $0 pro Monat                          |
-| Entwicklungszeit<sup>†</sup> |            400 Dollar pro Monat            | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
-|      Abfragen pro Monat      | Begrenzt auf infrastrukturelle Fähigkeiten |                    100.000 (kostenloser Plan)                   |
-|      Kosten pro Abfrage      |                     $0                     |                          $0<sup>‡</sup>                         |
-|         Infrastruktur        |                Zentralisiert               |                         Dezentralisiert                         |
-|    Geografische Redundanz    |     $750+ pro zusätzlichem Knotenpunkt     |                          Eingeschlossen                         |
-|         Betriebszeit         |                  Variiert                  |                              99.9%+                             |
-|    Monatliche Gesamtkosten   |   <span className="highlight-row" />$750+  |                                $0                               |
+|        Cost Comparison       |               Self Hosted               |                        The Graph Network                        |
+| :--------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |              $350 per month             |                                $0                               |
+|          Query costs         |                   $0+                   |                           $0 per month                          |
+| Engineering time<sup>†</sup> |              $400 per month             | None, built into the network with globally distributed Indexers |
+|       Queries per month      |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
+|        Cost per query        |                    $0                   |                          $0<sup>‡</sup>                         |
+|         Infrastruktur        |               Centralized               |                          Decentralized                          |
+|     Geographic redundancy    |        $750+ per additional node        |                             Included                            |
+|            Uptime            |                  Varies                 |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" />$750+ |                                $0                               |
 
-## Benutzer mit mittlerem Volumen (~3M Abfragen pro Monat)
+## Medium Volume User (~3M queries per month)
 
-|        Kostenvergleich       |                Selbst gehostet               |                        The Graph Network                        |
-| :--------------------------: | :------------------------------------------: | :-------------------------------------------------------------: |
-|   Monatliche Serverkosten\*  |                $350 pro Monat                |                                $0                               |
-|         Abfragekosten        |             500 Dollar pro Monat             |                       120 Dollar pro Monat                      |
-| Entwicklungszeit<sup>†</sup> |             800 Dollar pro Monat             | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
-|      Abfragen pro Monat      |  Begrenzt auf infrastrukturelle Fähigkeiten  |                            ~3,000,000                           |
-|      Kosten pro Abfrage      |                      $0                      |                             $0.00004                            |
-|         Infrastruktur        |                 Zentralisiert                |                         Dezentralisiert                         |
-|      Entwicklungskosten      |             200 Dollar pro Stunde            |                          Eingeschlossen                         |
-|    Geografische Redundanz    | 1.200 $ Gesamtkosten pro zusätzlichem Knoten |                          Eingeschlossen                         |
-|         Betriebszeit         |                   Variiert                   |                              99.9%+                             |
-|    Monatliche Gesamtkosten   |  <span className=„highlight-row“ /> $1.650+  |                               $120                              |
+|        Cost Comparison       |                 Self Hosted                |                        The Graph Network                        |
+| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |               $350 per month               |                                $0                               |
+|          Query costs         |               $500 per month               |                          $120 per month                         |
+| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities       |                            ~3,000,000                           |
+|        Cost per query        |                     $0                     |                             $0.00004                            |
+|         Infrastruktur        |                 Centralized                |                          Decentralized                          |
+|      Engineering expense     |                $200 per hour               |                             Included                            |
+|     Geographic redundancy    |  $1,200 in total costs per additional node |                             Included                            |
+|            Uptime            |                   Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $1,650+ |                               $120                              |
 
-## Nutzer mit hohem Volumen (~30M Abfragen pro Monat)
+## High Volume User (~30M queries per month)
 
-|           Kostenvergleich          |                Selbst gehostet               |                        The Graph Network                        |
-| :--------------------------------: | :------------------------------------------: | :-------------------------------------------------------------: |
-|      Monatliche Serverkosten\*     |          $1100 pro Monat, pro Knoten         |                                $0                               |
-|            Abfragekosten           |                     $4000                    |                      1.200 Dollar pro Monat                     |
-| Anzahl der benötigten Knotenpunkte |                      10                      |                         Nicht anwendbar                         |
-|    Entwicklungszeit<sup>†</sup>    |       6.000 Dollar oder mehr pro Monat       | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
-|         Abfragen pro Monat         |  Begrenzt auf infrastrukturelle Fähigkeiten  |                           ~30,000,000                           |
-|         Kosten pro Abfrage         |                      $0                      |                             $0.00004                            |
-|            Infrastruktur           |                 Zentralisiert                |                         Dezentralisiert                         |
-|       Geografische Redundanz       | 1.200 $ Gesamtkosten pro zusätzlichem Knoten |                          Eingeschlossen                         |
-|            Betriebszeit            |                   Variiert                   |                              99.9%+                             |
-|       Monatliche Gesamtkosten      |  <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+|        Cost Comparison       |                 Self Hosted                 |                        The Graph Network                        |
+| :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
+|     Monthly server cost\*    |          $1100 per month, per node          |                                $0                               |
+|          Query costs         |                    $4000                    |                         $1,200 per month                        |
+|    Number of nodes needed    |                      10                     |                          Not applicable                         |
+| Engineering time<sup>†</sup> |           $6,000 or more per month          | None, built into the network with globally distributed Indexers |
+|       Queries per month      |        Limited to infra capabilities        |                           ~30,000,000                           |
+|        Cost per query        |                      $0                     |                             $0.00004                            |
+|         Infrastruktur        |                 Centralized                 |                          Decentralized                          |
+|     Geographic redundancy    |  $1,200 in total costs per additional node  |                             Included                            |
+|            Uptime            |                    Varies                   |                              99.9%+                             |
+|      Total Monthly Costs     | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
 
-\*einschließlich der Kosten für die Datensicherung: $50-$100 pro Monat
+\*including costs for backup: $50-$100 per month
 
-<sup>†</sup>Engineering-Zeit auf der Grundlage von 200 $ pro Stunde angenommen
+<sup>†</sup>Engineering time based on $200 per hour assumption
 
-<sup>‡</sup>Reflektiert die Kosten für den Datenkonsumenten. Für Abfragen im Rahmen des „Free Plan“ werden nach wie vor Abfragegebühren an Indexer gezahlt.
+<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
 
-Die geschätzten Kosten gelten nur für Ethereum Mainnet Subgraphen - die Kosten sind noch höher, wenn man selbst einen „Graph-Knoten“ in anderen Netzwerken hostet. Einige Nutzer müssen ihren Subgraph möglicherweise auf eine neue Version aktualisieren. Aufgrund der Ethereum-Gas-Gebühren kostet ein Update zum Zeitpunkt des Schreibens ~$50. Beachten Sie, dass die Gasgebühren auf [Arbitrum](/archived/arbitrum/arbitrum-faq/) wesentlich niedriger sind als im Ethereum Mainnet.
+Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
 
-Das Kuratieren von Signalen auf einem Subgraph ist eine optionale, einmalige Investition mit Netto-Nullkosten (z.B. können Signale im Wert von 1.000 Dollar auf einem Subgraph kuratiert und später wieder abgezogen werden - mit dem Potenzial, dabei Renditen zu erzielen).
+Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process).
 
-## Keine Einrichtungskosten und größere betriebliche Effizienz
+## No Setup Costs & Greater Operational Efficiency
 
-Keine Einrichtungsgebühren. Sie können sofort loslegen, ohne Einrichtungs- oder Gemeinkosten. Keine Hardware-Anforderungen. Keine Ausfälle aufgrund einer zentralisierten Infrastruktur und mehr Zeit, um sich auf Ihr Kernprodukt zu konzentrieren. Kein Bedarf an Backup-Servern, Fehlersuche oder teuren technischen Ressourcen.
+Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources.
 
-## Zuverlässigkeit und Ausfallsicherheit
+## Reliability & Resiliency
 
-Das dezentralisierte Netzwerk von The Graph bietet den Nutzern Zugang zu einer geografischen Redundanz, die beim Selbsthosten eines „Graph-Knotens“ nicht gegeben ist. Abfragen werden dank einer Betriebszeit von über 99,9 %, die durch Hunderte unabhängiger Indexer erreicht wird, die das Netzwerk weltweit sichern, zuverlässig bedient.
+The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
 
-Unterm Strich: Das The Graph Network ist kostengünstiger, einfacher zu benutzen und liefert bessere Ergebnisse als ein lokaler Graph-Knoten.
+Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
 
-Beginnen Sie noch heute mit der Nutzung von The Graph Network und erfahren Sie, wie Sie [Ihren Subgraph im dezentralen Netzwerk von The Graph veröffentlichen](/subgraphs/quick-start/).
+Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).

From cc503b39ab5bebc2a78f80b587caa68194a77f06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 07:23:27 -0500
Subject: [PATCH 3809/3820] New translations tokenomics.mdx (German)

---
 website/pages/de/resources/tokenomics.mdx | 88 +++++++++++------------
 1 file changed, 44 insertions(+), 44 deletions(-)

diff --git a/website/pages/de/resources/tokenomics.mdx b/website/pages/de/resources/tokenomics.mdx
index 8637eb5bde73..210c1a2ecacf 100644
--- a/website/pages/de/resources/tokenomics.mdx
+++ b/website/pages/de/resources/tokenomics.mdx
@@ -1,102 +1,102 @@
 ---
 title: Tokenomics des The Graph Netzwerks
-description: The Graph Network wird durch leistungsstarke Tokenomics incentiviert. So funktioniert GRT, der The Graph-eigene Arbeits-Utility-Token.
+description: The Graph Network is incentivized by powerful tokenomics. Here’s how GRT, The Graph’s native work utility token, works.
 ---
 
 ## Überblick
 
-The Graph ist ein dezentrales Protokoll, das einen einfachen Zugang zu Blockchain-Daten ermöglicht. Es indiziert Blockchain-Daten ähnlich wie Google das Web indiziert. Wenn Sie eine Dapp verwendet haben, die Daten aus einem Subgraph abruft, haben Sie wahrscheinlich mit The Graph interagiert. Heute nutzen Tausende von [beliebten Dapps](https://thegraph.com/explorer) im web3-Ökosystem The Graph.
+The Graph is a decentralized protocol that enables easy access to blockchain data. It indexes blockchain data similarly to how Google indexes the web. If you've used a dapp that retrieves data from a subgraph, you've probably interacted with The Graph. Today, thousands of [popular dapps](https://thegraph.com/explorer) in the web3 ecosystem use The Graph.
 
 ## Besonderheiten
 
-Das Modell von The Graph ähnelt einem B2B2C-Modell, wird aber von einem dezentralen Netzwerk angetrieben, in dem die Teilnehmer zusammenarbeiten, um den Endnutzern Daten im Austausch für GRT Rewards zur Verfügung zu stellen. GRT ist der Utility Token für The Graph. Er koordiniert und fördert die Interaktion zwischen Datenanbietern und Verbrauchern innerhalb des Netzwerks.
+The Graph's model is akin to a B2B2C model, but it's driven by a decentralized network where participants collaborate to provide data to end users in exchange for GRT rewards. GRT is the utility token for The Graph. It coordinates and incentivizes the interaction between data providers and consumers within the network.
 
-The Graph spielt eine wichtige Rolle dabei, Blockchain-Daten besser zugänglich zu machen und unterstützt einen Marktplatz für deren Austausch. Wenn Sie mehr über das „Pay-for-what-you-need“-Modell von The Graph erfahren möchten, sehen Sie sich die [kostenlosen und Wachstumspläne](/subgraphs/billing/) an.
+The Graph plays a vital role in making blockchain data more accessible and supports a marketplace for its exchange. To learn more about The Graph's pay-for-what-you-need model, check out its [free and growth plans](/subgraphs/billing/).
 
-- GRT Token Adresse im Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
+- GRT Token Address on Mainnet: [0xc944e90c64b2c07662a292be6244bdf05cda44a7](https://etherscan.io/token/0xc944e90c64b2c07662a292be6244bdf05cda44a7)
 
-- GRT Token Adresse auf Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
+- GRT Token Address on Arbitrum One: [0x9623063377AD1B27544C965cCd7342f7EA7e88C7](https://arbiscan.io/token/0x9623063377ad1b27544c965ccd7342f7ea7e88c7)
 
-## Die Rollen der Netzwerkteilnehmer
+## The Roles of Network Participants
 
-Es gibt vier primäre Netzwerkteilnehmer:
+There are four primary network participants:
 
-1. Delegatoren - Delegieren Sie GRT an Indexer und sichern Sie das Netzwerk
+1. Delegators - Delegate GRT to Indexers & secure the network
 
 2. Kuratoren - Finden Sie die besten Untergraphen für Indexer
 
-3. Entwickler - Subgraphen erstellen und abfragen
+3. Developers - Build & query subgraphs
 
 4. Indexer - Das Rückgrat der Blockchain-Daten
 
-Fischer und Schlichter tragen auch durch andere Beiträge zum Erfolg des Netzwerks bei und unterstützen die Arbeit der anderen Hauptbeteiligten. Weitere Informationen über die Rollen des Netzwerks finden Sie in [diesem Artikel] (https://thegraph.com/blog/the-graph-grt-token-economics/).
+Fishermen and Arbitrators are also integral to the network's success through other contributions, supporting the work of the other primary participant roles. For more information about network roles, [read this article](https://thegraph.com/blog/the-graph-grt-token-economics/).
 
-![Tokenomics-Diagramm](/img/aktualisiertes-tokenomics-bild.png)
+![Tokenomics diagram](/img/updated-tokenomics-image.png)
 
-## Delegatoren (verdienen passiv GRT)
+## Delegators (Passively earn GRT)
 
-Indexer werden von Delegatoren mit GRT betraut, wodurch sich der Anteil des Indexers an Subgraphen im Netzwerk erhöht. Im Gegenzug erhalten die Delegatoren einen prozentualen Anteil an allen Abfragegebühren und Rewards des Indexers. Jeder Indexer legt den Anteil, den er an die Delegatoren vergütet, selbständig fest, wodurch ein Wettbewerb zwischen den Indexern entsteht, um Delegatoren anzuziehen. Die meisten Indexer bieten zwischen 9-12% jährlich.
+Indexers are delegated GRT by Delegators, increasing the Indexer’s stake in subgraphs on the network. In return, Delegators earn a percentage of all query fees and indexing rewards from the Indexer. Each Indexer sets the cut that will be rewarded to Delegators independently, creating competition among Indexers to attract Delegators. Most Indexers offer between 9-12% annually.
 
-Ein Datenbeispiel: Wenn ein Delegator 15.000 GRT an einen Indexer delegiert, der 10 % anbietet, würde der Delegator jährlich ~ 1.500 GRT an Rewards erhalten.
+For example, if a Delegator were to delegate 15k GRT to an Indexer offering 10%, the Delegator would receive ~1,500 GRT in rewards annually.
 
-Es gibt eine Delegationssteuer von 0,5 %, die jedes Mal erhoben wird, wenn ein Delegator GRT an das Netzwerk delegiert. Wenn ein Delegator beschließt, sein delegiertes GRT zurückzuziehen, muss er die 28-Epochen-Frist abwarten, in der die Bindung aufgehoben wird. Jede Epoche besteht aus 6.646 Blöcken, was bedeutet, dass 28 Epochen ungefähr 26 Tagen entsprechen.
+There is a 0.5% delegation tax which is burned whenever a Delegator delegates GRT on the network. If a Delegator chooses to withdraw their delegated GRT, the Delegator must wait for the 28-epoch unbonding period. Each epoch is 6,646 blocks, which means 28 epochs ends up being approximately 26 days.
 
-Wenn Sie dies lesen, können Sie sofort Delegator werden, indem Sie auf die [Netzwerkteilnehmerseite] (https://thegraph.com/explorer/participants/indexers) gehen und GRT an einen Indexer Ihrer Wahl delegieren.
+If you're reading this, you're capable of becoming a Delegator right now by heading to the [network participants page](https://thegraph.com/explorer/participants/indexers), and delegating GRT to an Indexer of your choice.
 
-## Kuratoren (GRT verdienen)
+## Curators (Earn GRT)
 
-Kuratoren identifizieren qualitativ hochwertige Subgraphen und „kuratieren“ sie (d.h. signalisieren GRT auf ihnen), um Kurationsanteile zu verdienen, die einen Prozentsatz aller zukünftigen Abfragegebühren garantieren, die durch den Subgraphen generiert werden. Obwohl jeder unabhängige Netzwerkteilnehmer ein Kurator sein kann, gehören Entwickler von Subgraphen in der Regel zu den ersten Kuratoren für ihre eigenen Subgraphen, da sie sicherstellen wollen, dass ihr Subgraph indiziert wird.
+Curators identify high-quality subgraphs and "curate" them (i.e., signal GRT on them) to earn curation shares, which guarantee a percentage of all future query fees generated by the subgraph. While any independent network participant can be a Curator, typically subgraph developers are among the first Curators for their own subgraphs because they want to ensure their subgraph is indexed.
 
-Die Entwickler von Subgraphen werden ermutigt, ihren Subgraph mit mindestens 3.000 GRT zu kuratieren. Diese Zahl kann jedoch von der Netzwerkaktivität und der Beteiligung der Community beeinflusst werden.
+Subgraph developers are encouraged to curate their subgraph with at least 3,000 GRT. However, this number may be impacted by network activity and community participation.
 
-Kuratoren zahlen eine Kurationssteuer von 1%, wenn sie einen neuen Subgraph kuratieren. Diese Kurationssteuer wird verbrannt, wodurch das Angebot an GRT sinkt.
+Curators pay a 1% curation tax when they curate a new subgraph. This curation tax is burned, decreasing the supply of GRT.
 
-## Entwickler
+## Developers
 
-Entwickler erstellen Subgraphen und fragen sie ab, um Blockchain-Daten abzurufen. Da Subgraphen quelloffen sind, können Entwickler bestehende Subgraphen abfragen, um Blockchain-Daten in ihre Dapps zu laden. Entwickler zahlen für ihre Abfragen in GRT, das an die Netzwerkteilnehmer verteilt wird.
+Developers build and query subgraphs to retrieve blockchain data. Since subgraphs are open source, developers can query existing subgraphs to load blockchain data into their dapps. Developers pay for queries they make in GRT, which is distributed to network participants.
 
 ### Erstellung eines Untergraphen
 
-Entwickler können [einen Subgraph erstellen](/developing/creating-a-subgraph/), um Daten auf der Blockchain zu indizieren. Subgraphen sind Anweisungen für Indexer darüber, welche Daten an Verbraucher geliefert werden sollen.
+Developers can [create a subgraph](/developing/creating-a-subgraph/) to index data on the blockchain. Subgraphs are instructions for Indexers about which data should be served to consumers.
 
-Sobald Entwickler ihren Subgraph gebaut und getestet haben, können sie ihn im dezentralen Netzwerk von The Graph veröffentlichen (/subgraphs/developing/publishing/publishing-a-subgraph/).
+Once developers have built and tested their subgraph, they can [publish their subgraph](/subgraphs/developing/publishing/publishing-a-subgraph/) on The Graph's decentralized network.
 
 ### Abfrage eines vorhandenen Untergraphen
 
-Sobald ein Subgraph im dezentralen Netzwerk von The Graph [veröffentlicht](/subgraphs/developing/publishing/publishing-a-subgraph/) wurde, kann jeder einen API-Schlüssel erstellen, GRT zu seinem Guthaben hinzufügen und den Subgraph abfragen.
+Once a subgraph is [published](/subgraphs/developing/publishing/publishing-a-subgraph/) to The Graph's decentralized network, anyone can create an API key, add GRT to their billing balance, and query the subgraph.
 
-Subgraphen werden [mit GraphQL abgefragt](/subgraphs/querying/introduction/), und die Abfragegebühren werden mit GRT in [Subgraph Studio](https://thegraph.com/studio/) bezahlt. Die Abfragegebühren werden an die Netzwerkteilnehmer auf der Grundlage ihrer Beiträge zum Protokoll verteilt.
+Subgraphs are [queried using GraphQL](/subgraphs/querying/introduction/), and the query fees are paid for with GRT in [Subgraph Studio](https://thegraph.com/studio/). Query fees are distributed to network participants based on their contributions to the protocol.
 
-1 % der an das Netz gezahlten Abfragegebühren werden verbrannt.
+1% of the query fees paid to the network are burned.
 
-## Indexer (GRT verdienen)
+## Indexers (Earn GRT)
 
-Indexer sind das Rückgrat von The Graph. Sie betreiben unabhängige Hardware und Software, die das dezentrale Netzwerk von The Graph antreiben. Indexer versorgen die Verbraucher mit Daten, die auf Anweisungen von Subgraphen basieren.
+Indexers are the backbone of The Graph. They operate independent hardware and software powering The Graph’s decentralized network. Indexers serve data to consumers based on instructions from subgraphs.
 
-Indexer können GRT Rewards auf zwei Arten verdienen:
+Indexers can earn GRT rewards in two ways:
 
-1. **Abfragegebühren**: GRT, die von Entwicklern oder Nutzern für die Abfrage von Subgraph-Daten gezahlt werden. Abfragegebühren werden gemäß der exponentiellen Rabattfunktion direkt an Indexer verteilt (siehe GIP [hier](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
+1. **Query fees**: GRT paid by developers or users for subgraph data queries. Query fees are directly distributed to Indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)).
 
-2. **Indexing Rewards**: Die jährliche Ausgabe von 3% wird an Indexer verteilt, basierend auf der Anzahl der Subgraphen, die sie indexieren. Diese Rewards sind ein Anreiz für Indexer, Subgraphen zu indizieren, gelegentlich vor Beginn der Abfragegebühren, um Proofs of Indexing (POIs) zu sammeln und einzureichen, die bestätigen, dass sie Daten korrekt indiziert haben.
+2. **Indexing rewards**: the 3% annual issuance is distributed to Indexers based on the number of subgraphs they are indexing. These rewards incentivize Indexers to index subgraphs, occasionally before the query fees begin, to accrue and submit Proofs of Indexing (POIs), verifying that they have indexed data accurately.
 
-Jedem Subgraph wird ein Teil der gesamten Netzwerk-Token-Ausgabe zugeteilt, basierend auf der Höhe des Kurationssignals des Subgraphen. Dieser Betrag wird dann an Indexer auf der Grundlage ihres zugewiesenen Anteils an dem Subgraph belohnt.
+Each subgraph is allotted a portion of the total network token issuance, based on the amount of the subgraph’s curation signal. That amount is then rewarded to Indexers based on their allocated stake on the subgraph.
 
-Um einen Indexierungsknoten betreiben zu können, müssen Indexer mindestens 100.000 GRT selbst in das Netzwerk einbringen. Für Indexer besteht ein Anreiz, GRT im Verhältnis zur Anzahl der von ihnen bearbeiteten Abfragen selbst einzunehmen.
+In order to run an indexing node, Indexers must self-stake 100,000 GRT or more with the network. Indexers are incentivized to self-stake GRT in proportion to the amount of queries they serve.
 
-Indexer können ihre GRT-Zuteilungen auf Subgraphen erhöhen, indem sie GRT-Delegationen von Delegatoren akzeptieren, und sie können bis zum 16-fachen ihres ursprünglichen Eigenanteils akzeptieren. Wenn ein Indexer „überdelegiert“ wird (d.h. mehr als das 16-fache seines ursprünglichen Eigenanteils), kann er die zusätzlichen GRT von Delegatoren nicht nutzen, bis er seinen Eigenanteil im Netzwerk erhöht.
+Indexers can increase their GRT allocations on subgraphs by accepting GRT delegation from Delegators, and they can accept up to 16 times their initial self-stake. If an Indexer becomes "over-delegated" (i.e., more than 16 times their initial self-stake), they will not be able to use the additional GRT from Delegators until they increase their self-stake in the network.
 
-Die Höhe der Rewards, die ein Indexer erhält, kann je nach Eigenanteil des Indexers, akzeptierter Delegation, Qualität der Dienstleistung und vielen weiteren Faktoren variieren.
+The amount of rewards an Indexer receives can vary based on the Indexer's self-stake, accepted delegation, quality of service, and many more factors.
 
-## Token-Versorgung: Burning & Emission
+## Token Supply: Burning & Issuance
 
-Das anfängliche Token-Angebot beträgt 10 Milliarden GRT, mit einem Ziel von 3 % Neuemissionen pro Jahr, um Indexer für die Zuweisung von Anteilen an Subgraphen zu belohnen. Das bedeutet, dass das Gesamtangebot an GRT-Token jedes Jahr um 3 % steigen wird, da neue Token an Indexer für ihren Beitrag zum Netzwerk ausgegeben werden.
+The initial token supply is 10 billion GRT, with a target of 3% new issuance annually to reward Indexers for allocating stake on subgraphs. This means that the total supply of GRT tokens will increase by 3% each year as new tokens are issued to Indexers for their contribution to the network.
 
-The Graph ist mit mehreren Brennmechanismen ausgestattet, um die Ausgabe neuer Token auszugleichen. Ungefähr 1 % des GRT-Angebots wird jährlich durch verschiedene Aktivitäten im Netzwerk verbrannt, und diese Zahl steigt, da die Netzwerkaktivität weiter zunimmt. Zu diesen Burning-Aktivitäten gehören eine Delegationssteuer von 0,5 %, wenn ein Delegator GRT an einen Indexer delegiert, eine Kurationssteuer von 1 %, wenn Kuratoren ein Signal auf einem Subgraph geben, und 1 % der Abfragegebühren für Blockchain-Daten.
+The Graph is designed with multiple burning mechanisms to offset new token issuance. Approximately 1% of the GRT supply is burned annually through various activities on the network, and this number has been increasing as network activity continues to grow. These burning activities include a 0.5% delegation tax whenever a Delegator delegates GRT to an Indexer, a 1% curation tax when Curators signal on a subgraph, and a 1% of query fees for blockchain data.
 
-[[Insgesamt verbrannte GRT](/img/total-burned-grt.jpeg)
+![Total burned GRT](/img/total-burned-grt.jpeg)
 
-Zusätzlich zu diesen regelmäßig stattfindenden Verbrennungsaktivitäten verfügt der GRT-Token auch über einen Slashing-Mechanismus, um böswilliges oder unverantwortliches Verhalten von Indexern zu bestrafen. Wenn ein Indexer geslashed wird, werden 50% seiner Rewards für die Epoche verbrannt (während die andere Hälfte an den Fischer geht), und sein Eigenanteil wird um 2,5% gekürzt, wobei die Hälfte dieses Betrags verbrannt wird. Dies trägt dazu bei, dass Indexer einen starken Anreiz haben, im besten Interesse des Netzwerks zu handeln und zu dessen Sicherheit und Stabilität beizutragen.
+In addition to these regularly occurring burning activities, the GRT token also has a slashing mechanism in place to penalize malicious or irresponsible behavior by Indexers. If an Indexer is slashed, 50% of their indexing rewards for the epoch are burned (while the other half goes to the fisherman), and their self-stake is slashed by 2.5%, with half of this amount being burned. This helps to ensure that Indexers have a strong incentive to act in the best interests of the network and to contribute to its security and stability.
 
-## Verbesserung des Protokolls
+## Improving the Protocol
 
-The Graph Network entwickelt sich ständig weiter, und es werden laufend Verbesserungen an der wirtschaftlichen Gestaltung des Protokolls vorgenommen, um allen Netzwerkteilnehmern die bestmögliche Erfahrung zu bieten. Der The Graph-Rat überwacht die Protokolländerungen, und die Mitglieder der Community sind aufgerufen, sich daran zu beteiligen. Beteiligen Sie sich an der Verbesserung des Protokolls im [The Graph Forum] (https://forum.thegraph.com/).
+The Graph Network is ever-evolving and improvements to the economic design of the protocol are constantly being made to provide the best experience for all network participants. The Graph Council oversees protocol changes and community members are encouraged to participate. Get involved with protocol improvements in [The Graph Forum](https://forum.thegraph.com/).

From 0726781bd841945c8fbafadcce6a1052a405e508 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 07:23:28 -0500
Subject: [PATCH 3810/3820] New translations subgraph-debug-forking.mdx
 (Chinese Simplified)

---
 website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx
index 654785ae49dc..565000c96131 100644
--- a/website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -4,7 +4,7 @@ title: 使用分叉快速轻松地调试子图
 
 As with many systems processing large amounts of data, The Graph's Indexers (Graph Nodes) may take quite some time to sync-up your subgraph with the target blockchain. The discrepancy between quick changes with the purpose of debugging and long wait times needed for indexing is extremely counterproductive and we are well aware of that. This is why we are introducing **subgraph forking**, developed by [LimeChain](https://limechain.tech/), and in this article I will show you how this feature can be used to substantially speed-up subgraph debugging!
 
-## 首先，让我们来看什么是子图分叉
+## 好的，那是什么？
 
 **Subgraph forking** is the process of lazily fetching entities from _another_ subgraph's store (usually a remote one).
 

From e7a0bc09bb0eeafdf0c709763e5224d35ddbd9f7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 07:23:29 -0500
Subject: [PATCH 3811/3820] New translations sps-faq.mdx (German)

---
 website/pages/de/sps/sps-faq.mdx | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/website/pages/de/sps/sps-faq.mdx b/website/pages/de/sps/sps-faq.mdx
index 15252f60c5ea..d024285a3b5c 100644
--- a/website/pages/de/sps/sps-faq.mdx
+++ b/website/pages/de/sps/sps-faq.mdx
@@ -64,32 +64,32 @@ Die Verwendung von Firehose bietet viele Vorteile, darunter:
 
 ## Wo erhalten Entwickler weitere Informationen über Substreams-basieren Subgraphen und Substreams?
 
-The [Substreams documentation](/substreams/introduction/) will teach you how to build Substreams modules.
+In der [Substreams-Dokumentation](/substreams/introduction/) erfahren Sie, wie Sie Substreams-Module erstellen können.
 
 The [Substreams-powered subgraphs documentation](/sps/introduction/) will show you how to package them for deployment on The Graph.
 
-The [latest Substreams Codegen tool](https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) will allow you to bootstrap a Substreams project without any code.
+Das [neueste Substreams Codegen-Tool] (https://streamingfastio.medium.com/substreams-codegen-no-code-tool-to-bootstrap-your-project-a11efe0378c6) ermöglicht es Ihnen, ein Substreams-Projekt ohne jeglichen Code zu booten.
 
-## What is the role of Rust modules in Substreams?
+## Welche Rolle spielen die Rust-Module in Substreams?
 
-Rust modules are the equivalent of the AssemblyScript mappers in subgraphs. They are compiled to WASM in a similar way, but the programming model allows for parallel execution. They define the sort of transformations and aggregations you want to apply to the raw blockchain data.
+Rust-Module sind das Äquivalent zu den AssemblyScript-Mappern in Subgraphen. Sie werden auf ähnliche Weise in WASM kompiliert, aber das Programmiermodell ermöglicht eine parallele Ausführung. Sie definieren die Art der Transformationen und Aggregationen, die Sie auf die Blockchain-Rohdaten anwenden möchten.
 
 See [modules documentation](https://docs.substreams.dev/reference-material/substreams-components/modules#modules) for details.
 
-## What makes Substreams composable?
+## Was macht Substreams kompositionsfähig?
 
-When using Substreams, the composition happens at the transformation layer enabling cached modules to be re-used.
+Bei der Verwendung von Substreams erfolgt die Komposition auf der Transformationsschicht, wodurch zwischengespeicherte Module wiederverwendet werden können.
 
-As an example, Alice can build a DEX price module, Bob can use it to build a volume aggregator for some tokens of his interest, and Lisa can combine four individual DEX price modules to create a price oracle. A single Substreams request will package all of these individual's modules, link them together, to offer a much more refined stream of data. That stream can then be used to populate a subgraph, and be queried by consumers.
+Als Datenbeispiel kann Alice ein DEX-Preismodul erstellen, Bob kann damit einen Volumenaggregator für einige Token seines Interesses erstellen, und Lisa kann vier einzelne DEX-Preismodule zu einem Preisorakel kombinieren. Eine einzige Substreams-Anfrage bündelt all diese individuellen Module und verbindet sie miteinander, um einen viel feineren Datenstrom anzubieten. Dieser Datenstrom kann dann verwendet werden, um einen Subgraphen aufzufüllen und von den Verbrauchern abgefragt zu werden.
 
-## How can you build and deploy a Substreams-powered Subgraph?
+## Wie können Sie einen Substreams-basierten Subgraphen erstellen und einsetzen?
 
 After [defining](/sps/introduction/) a Substreams-powered Subgraph, you can use the Graph CLI to deploy it in [Subgraph Studio](https://thegraph.com/studio/).
 
-## Where can I find examples of Substreams and Substreams-powered subgraphs?
+## Wo finde ich Datenbeispiele für Substreams und Substreams-basierte Subgraphen?
 
-You can visit [this Github repo](https://github.com/pinax-network/awesome-substreams) to find examples of Substreams and Substreams-powered subgraphs.
+Sie können [dieses Github Repo] (https://github.com/pinax-network/awesome-substreams) besuchen, um Datenbeispiele für Substreams und Substreams-basierte Subgraphen zu finden.
 
-## What do Substreams and Substreams-powered subgraphs mean for The Graph Network?
+## Was bedeuten Substreams und Substreams-basierte Subgraphen für The Graph Network?
 
-The integration promises many benefits, including extremely high-performance indexing and greater composability by leveraging community modules and building on them.
+Die Integration verspricht viele Vorteile, darunter eine extrem leistungsstarke Indizierung und eine größere Kompositionsfähigkeit durch die Nutzung von Community-Modulen und deren Weiterentwicklung.

From 47fac9c2d6b86c996fe0b56f39d1ea53ee51e90f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 07:23:31 -0500
Subject: [PATCH 3812/3820] New translations delegating.mdx (German)

---
 .../resources/roles/delegating/delegating.mdx | 76 +++++++++----------
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/website/pages/de/resources/roles/delegating/delegating.mdx b/website/pages/de/resources/roles/delegating/delegating.mdx
index a5114e0ac8cf..d6dedfac53ca 100644
--- a/website/pages/de/resources/roles/delegating/delegating.mdx
+++ b/website/pages/de/resources/roles/delegating/delegating.mdx
@@ -2,54 +2,54 @@
 title: Delegieren
 ---
 
-Wenn Sie sofort mit dem Delegieren beginnen möchten, schauen Sie sich [delegate on the graph] (https://thegraph.com/explorer/delegate?chain=arbitrum-one) an.
+To start delegating right away, check out [delegate on the graph](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
 ## Überblick
 
-Delegatoren verdienen GRT, indem sie GRT an Indexer delegieren, was die Sicherheit und Funktionalität des Netzwerks erhöht.
+Delegators earn GRT by delegating GRT to Indexers, which helps network security and functionality.
 
 <VideoEmbed youtube="VACg8bitnVc" />
 
-## Vorteile des Delegierens
+## Benefits of Delegating
 
-- Stärkung der Sicherheit und Skalierbarkeit des Netzwerks durch Unterstützung von Indexern.
-- Verdienen Sie einen Teil der Rewards, die von den Indexers generiert werden.
+- Strengthen the network’s security and scalability by supporting Indexers.
+- Earn a portion of rewards generated by the Indexers.
 
-## Wie funktioniert die Delegation?
+## How Does Delegation Work?
 
-Delegatoren erhalten GRT Rewards von dem/den Indexer(n), an den/die sie ihr GRT delegieren.
+Delegators earn GRT rewards from the Indexer(s) they choose to delegate their GRT to.
 
-Die Fähigkeit eines Indexers, Abfragen zu verarbeiten und Rewards zu verdienen, hängt von drei Schlüsselfaktoren ab:
+An Indexer's ability to process queries and earn rewards depends on three key factors:
 
-1. Die Selbstbeteiligung des Indexers (GRT, die vom Indexer eingesetzt werden).
-2. Die gesamte GRT, die ihnen von den Delegatoren übertragen wurde.
-3. Der Preis, den der Indexer für Abfragen festlegt.
+1. The Indexer's Self-Stake (GRT staked by the Indexer).
+2. The total GRT delegated to them by Delegators.
+3. The price the Indexer sets for queries.
 
-Je mehr GRT eingesetzt und an einen Indexer delegiert werden, desto mehr Abfragen können bedient werden, was zu höheren potenziellen Rewards sowohl für den Delegator als auch für den Indexer führt.
+The more GRT staked and delegated to an Indexer, the more queries they can serve, leading to higher potential rewards for both the Delegator and Indexer.
 
-### Was ist Delegationsfähigkeit?
+### What is Delegation Capacity?
 
-Die Delegationskapazität bezieht sich auf die maximale Menge an GRT, die ein Indexer von Delegatoren annehmen kann, basierend auf der Selbstbeteiligung des Indexers.
+Delegation Capacity refers to the maximum amount of GRT an Indexer can accept from Delegators, based on the Indexer's Self-Stake.
 
-The Graph Network beinhaltet ein Delegationsverhältnis von 16, d.h. ein Indexer kann bis zum 16-fachen seines Eigenanteils an delegiertem GRT annehmen.
+The Graph Network includes a delegation ratio of 16, meaning an Indexer can accept up to 16 times their Self-Stake in delegated GRT.
 
-Ein Beispiel: Wenn ein Indexer eine Selbstabnahme von 1 Mio. GRT hat, beträgt seine Delegationskapazität 16 Mio. GRT.
+For example, if an Indexer has a Self-Stake of 1M GRT, their Delegation Capacity is 16M.
 
-### Warum ist die Delegationsfähigkeit so wichtig?
+### Why Does Delegation Capacity Matter?
 
-Wenn ein Indexer seine Delegationskapazität überschreitet, werden die Rewards für alle Delegatoren verwässert, da das überschüssige delegierte GRT innerhalb des Protokolls nicht effektiv genutzt werden kann.
+If an Indexer exceeds their Delegation Capacity, rewards for all Delegators become diluted because the excess delegated GRT cannot be used effectively within the protocol.
 
-Daher ist es für die Delegatoren von entscheidender Bedeutung, die aktuelle Delegationskapazität eines Indexers zu bewerten, bevor sie einen Indexer auswählen.
+This makes it crucial for Delegators to evaluate an Indexer's current Delegation Capacity before selecting an Indexer.
 
-Indexer können ihre Delegationskapazität erhöhen, indem sie ihre Selbstbeteiligung erhöhen und damit das Limit für delegierte Token anheben.
+Indexers can increase their Delegation Capacity by increasing their Self-Stake, thereby raising the limit for delegated tokens.
 
-## Delegation auf The Graph
+## Delegation on The Graph
 
 <VideoEmbed youtube="HVyIrMcNu7I" />
 
-> Bitte beachten Sie, dass dieser Leitfaden nicht auf Schritte wie die Einrichtung von MetaMask eingeht. Die Ethereum Community bietet eine [umfassende Ressource zu Wallets] (https://ethereum.org/en/wallets/).
+> Please note this guide does not cover steps such as setting up MetaMask. The Ethereum community provides a [comprehensive resource regarding wallets](https://ethereum.org/en/wallets/).
 
-Dieser Leitfaden besteht aus zwei Abschnitten:
+There are two sections in this guide:
 
 - Die Risiken der Übertragung von Token in The Graph Network
 - Wie man als Delegator die erwarteten Erträge berechnet
@@ -58,7 +58,7 @@ Dieser Leitfaden besteht aus zwei Abschnitten:
 
 Nachfolgend sind die wichtigsten Risiken aufgeführt, die mit der Tätigkeit eines Delegators im Protokoll verbunden sind.
 
-### Die Delegationssteuer
+### The Delegation Tax
 
 Delegatoren können nicht für schlechtes Verhalten bestraft werden, aber es gibt eine Steuer für Delegatoren, um von schlechten Entscheidungen abzuschrecken, die die Integrität des Netzes beeinträchtigen könnten.
 
@@ -68,19 +68,19 @@ Als Delegator ist es wichtig, die folgenden Punkte zu verstehen:
 
 - Um auf Nummer sicher zu gehen, sollten Sie Ihre potenzielle Rendite berechnen, wenn Sie einen Indexer beauftragen. Als Beispiel könnten Sie berechnen, wie viele Tage es dauern wird, bis Sie die 0,5 % Steuer auf Ihre Delegation zurückverdient haben.
 
-### Der Zeitraum der Undelegation
+### The Undelegation Period
 
-Wenn ein Delegator die Delegation aufhebt, gilt für seine Token eine Frist von 28 Tagen für die Delegation.
+When a Delegator chooses to undelegate, their tokens are subject to a 28-day undelegation period.
 
-Das bedeutet, dass sie 28 Tage lang weder ihre Token übertragen noch Rewards verdienen können.
+This means they cannot transfer their tokens or earn any rewards for 28 days.
 
-Nach Ablauf der Frist wird GRT in Ihre Wallet zurückgegeben.
+After the undelegation period, GRT will return to your crypto wallet.
 
 ### Warum ist das wichtig?
 
-Wenn Sie sich für einen Indexer entscheiden, der nicht vertrauenswürdig ist oder keine gute Arbeit leistet, werden Sie die Abtretung rückgängig machen wollen. Das bedeutet, dass Sie die Möglichkeit verlieren, Rewards zu verdienen.
+If you choose an Indexer that is not trustworthy or not doing a good job, you will want to undelegate. This means you will be losing opportunities to earn rewards.
 
-Es empfiehlt sich daher, einen Indexer mit Bedacht auszuwählen.
+As a result, it’s recommended that you choose an Indexer wisely.
 
 <div sx={{ mx: 'auto', maxWidth: '400px' }}>
   ![Delegation unbonding](/img/Delegation-Unbonding.png) _Note the 0.5% fee in the Delegation UI, as well as the 28 day
@@ -102,25 +102,25 @@ mittlere gibt den Delegatoren 20 %. Der untere gibt den Delegatoren ~83 %.*
 
 - **Kürzung der Abfragegebühren** - Dies ist genau wie die Indizierung der Rewardkürzung, aber es gilt für die Renditen der Abfragegebühren, die der Indexer einnimmt.
 
-- Es wird dringend empfohlen, [The Graph Discord] (https://discord.gg/graphprotocol) zu erkunden, um festzustellen, welche Indexer den besten sozialen und technischen Ruf haben.
+- It is highly recommended that you explore [The Graph Discord](https://discord.gg/graphprotocol) to determine which Indexers have the best social and technical reputations.
 
-- Viele Indexer sind in Discord aktiv und beantworten gerne Ihre Fragen.
+- Many Indexers are active in Discord and will be happy to answer your questions.
 
 ## Berechnung der erwarteten Rendite der Delegatoren
 
-> Berechnen Sie den ROI für Ihre Delegation [hier] (https://thegraph.com/explorer/delegate?chain=arbitrum-one).
+> Calculate the ROI on your delegation [here](https://thegraph.com/explorer/delegate?chain=arbitrum-one).
 
-Ein Delegator muss eine Vielzahl von Faktoren berücksichtigen, um eine Rendite zu bestimmen:
+A Delegator must consider a variety of factors to determine a return:
 
-Die Fähigkeit eines Indexers, das ihm zur Verfügung stehende delegierte GRT zu nutzen, wirkt sich auf seine Rewards aus.
+An Indexer's ability to use the delegated GRT available to them impacts their rewards.
 
-Wenn ein Indexer nicht alle ihm zur Verfügung stehenden GRT einsetzt, verpasst er möglicherweise die Maximierung des Ertragspotenzials für sich und seine Delegatoren.
+If an Indexer does not allocate all the GRT at their disposal, they may miss out on maximizing potential earnings for both themselves and their Delegators.
 
-Indexer können eine Zuteilung schließen und Rewards jederzeit innerhalb des Zeitfensters von 1 bis 28 Tagen abholen. Werden die Rewards jedoch nicht umgehend abgeholt, kann der Gesamtbetrag der Rewards niedriger erscheinen, selbst wenn ein bestimmter Prozentsatz der Rewards nicht abgeholt wird.
+Indexers can close an allocation and collect rewards at any time within the 1 to 28-day window. However, if rewards are not promptly collected, the total rewards may appear lower, even if a percentage of rewards remain unclaimed.
 
 ### Berücksichtigung der Senkung der Abfrage- und Indizierungsgebühren
 
-Sie sollten einen Indexer wählen, der seine Abfrage- und Indizierungsgebühren transparent festlegt.
+You should choose an Indexer that is transparent about setting their Query Fee and Indexing Fee Cuts.
 
 Die Formel lautet:
 

From 4f4439a267787728f4d4e55f1859f29a5378be4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 11:30:45 -0500
Subject: [PATCH 3813/3820] New translations benefits.mdx (German)

---
 website/pages/de/resources/benefits.mdx | 128 ++++++++++++------------
 1 file changed, 64 insertions(+), 64 deletions(-)

diff --git a/website/pages/de/resources/benefits.mdx b/website/pages/de/resources/benefits.mdx
index c035f6636b1b..18cb9d911d5b 100644
--- a/website/pages/de/resources/benefits.mdx
+++ b/website/pages/de/resources/benefits.mdx
@@ -1,92 +1,92 @@
 ---
-title: The Graph vs. Self Hosting
+title: The Graph vs. Self-Hosting
 socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
 ---
 
-The Graph’s decentralized network has been engineered and refined to create a robust indexing and querying experience—and it’s getting better every day thanks to thousands of contributors around the world.
+Das dezentralisierte Netzwerk von The Graph wurde entwickelt und verfeinert, um eine robuste Indizierung und Abfrage zu ermöglichen - und es wird dank Tausender Mitwirkender auf der ganzen Welt jeden Tag besser.
 
-The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
+Die Vorteile dieses dezentralen Protokolls können nicht durch den lokalen Betrieb eines `graph-node` repliziert werden. The Graph Network ist zuverlässiger, effizienter und kostengünstiger.
 
-Here is an analysis:
+Hier ist eine Analyse:
 
-## Why You Should Use The Graph Network
+## Warum Sie das The Graph Network nutzen sollten
 
-- Significantly lower monthly costs
-- $0 infrastructure setup costs
-- Superior uptime
-- Access to hundreds of independent Indexers around the world
-- 24/7 technical support by global community
+- Deutlich niedrigere monatliche Kosten
+- $0 Kosten für die Einrichtung der Infrastruktur
+- Hervorragende Betriebszeiten
+- Zugang zu Hunderten von unabhängigen Indexern auf der ganzen Welt
+- 24/7 technische Unterstützung durch die globale Community
 
-## The Benefits Explained
+## Die Vorteile werden erklärt
 
-### Lower & more Flexible Cost Structure
+### Niedrigere und flexiblere Kostenstruktur
 
-No contracts. No monthly fees. Only pay for the queries you use—with an average cost-per-query of $40 per million queries (~$0.00004 per query). Queries are priced in USD and paid in GRT or credit card.
+Keine Verträge. Keine monatlichen Gebühren. Sie zahlen nur für die Abfragen, die Sie nutzen - mit durchschnittlichen Kosten pro Abfrage von $40 pro Million Abfragen (~$0,00004 pro Abfrage). Abfragen werden in USD abgerechnet und in GRT oder per Kreditkarte bezahlt.
 
-Query costs may vary; the quoted cost is the average at time of publication (March 2024).
+Die Abfragekosten können variieren; die angegebenen Kosten sind der Durchschnitt zum Zeitpunkt der Veröffentlichung (März 2024).
 
-## Low Volume User (less than 100,000 queries per month)
+## Benutzer mit geringem Volumen (weniger als 100.000 Abfragen pro Monat)
 
-|        Cost Comparison       |               Self Hosted               |                        The Graph Network                        |
-| :--------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
-|     Monthly server cost\*    |              $350 per month             |                                $0                               |
-|          Query costs         |                   $0+                   |                           $0 per month                          |
-| Engineering time<sup>†</sup> |              $400 per month             | None, built into the network with globally distributed Indexers |
-|       Queries per month      |      Limited to infra capabilities      |                       100,000 (Free Plan)                       |
-|        Cost per query        |                    $0                   |                          $0<sup>‡</sup>                         |
-|         Infrastruktur        |               Centralized               |                          Decentralized                          |
-|     Geographic redundancy    |        $750+ per additional node        |                             Included                            |
-|            Uptime            |                  Varies                 |                              99.9%+                             |
-|      Total Monthly Costs     | <span className="highlight-row" />$750+ |                                $0                               |
+|        Kostenvergleich       |              Selbst gehostet              |                        The Graph Network                        |
+| :--------------------------: | :---------------------------------------: | :-------------------------------------------------------------: |
+|   Monatliche Serverkosten\*  |               $350 pro Monat              |                                $0                               |
+|         Abfragekosten        |                    $0+                    |                           $0 pro Monat                          |
+| Entwicklungszeit<sup>†</sup> |               $400 pro Monat              | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
+|      Abfragen pro Monat      | Begrenzt auf infrastrukturelle Funktionen |                    100.000 (kostenloser Plan)                   |
+|      Kosten pro Abfrage      |                     $0                    |                          $0<sup>‡</sup>                         |
+|         Infrastruktur        |               Zentralisiert               |                         Dezentralisiert                         |
+|    Geografische Redundanz    |       $750+ pro zusätzlichem Knoten       |                          Eingeschlossen                         |
+|         Betriebszeit         |                  Variiert                 |                              99.9%+                             |
+|    Monatliche Gesamtkosten   |  <span className="highlight-row" />$750+  |                                $0                               |
 
-## Medium Volume User (~3M queries per month)
+## Benutzer mit mittlerem Volumen (~3M Abfragen pro Monat)
 
-|        Cost Comparison       |                 Self Hosted                |                        The Graph Network                        |
-| :--------------------------: | :----------------------------------------: | :-------------------------------------------------------------: |
-|     Monthly server cost\*    |               $350 per month               |                                $0                               |
-|          Query costs         |               $500 per month               |                          $120 per month                         |
-| Engineering time<sup>†</sup> |               $800 per month               | None, built into the network with globally distributed Indexers |
-|       Queries per month      |        Limited to infra capabilities       |                            ~3,000,000                           |
-|        Cost per query        |                     $0                     |                             $0.00004                            |
-|         Infrastruktur        |                 Centralized                |                          Decentralized                          |
-|      Engineering expense     |                $200 per hour               |                             Included                            |
-|     Geographic redundancy    |  $1,200 in total costs per additional node |                             Included                            |
-|            Uptime            |                   Varies                   |                              99.9%+                             |
-|      Total Monthly Costs     | <span className="highlight-row" /> $1,650+ |                               $120                              |
-
-## High Volume User (~30M queries per month)
-
-|        Cost Comparison       |                 Self Hosted                 |                        The Graph Network                        |
+|        Kostenvergleich       |               Selbst gehostet               |                        The Graph Network                        |
+| :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
+|   Monatliche Serverkosten\*  |                $350 pro Monat               |                                $0                               |
+|         Abfragekosten        |                $500 pro Monat               |                          $120 pro Monat                         |
+| Entwicklungszeit<sup>†</sup> |                $800 pro Monat               | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
+|      Abfragen pro Monat      |  Begrenzt auf infrastrukturelle Funktionen  |                            ~3,000,000                           |
+|      Kosten pro Abfrage      |                      $0                     |                             $0.00004                            |
+|         Infrastruktur        |                Zentralisiert                |                         Dezentralisiert                         |
+|      Engineering-Kosten      |               $200 pro Stunde               |                          Eingeschlossen                         |
+|    Geografische Redundanz    | $1,200 Gesamtkosten pro zusätzlichem Knoten |                          Eingeschlossen                         |
+|         Betriebszeit         |                   Variiert                  |                              99.9%+                             |
+|    Monatliche Gesamtkosten   |  <span className=„highlight-row“ /> $1.650+ |                               $120                              |
+
+## Benutzer mit hohem Volumen (~30M Abfragen pro Monat)
+
+|        Kostenvergleich       |               Selbst gehostet               |                        The Graph Network                        |
 | :--------------------------: | :-----------------------------------------: | :-------------------------------------------------------------: |
-|     Monthly server cost\*    |          $1100 per month, per node          |                                $0                               |
-|          Query costs         |                    $4000                    |                         $1,200 per month                        |
-|    Number of nodes needed    |                      10                     |                          Not applicable                         |
-| Engineering time<sup>†</sup> |           $6,000 or more per month          | None, built into the network with globally distributed Indexers |
-|       Queries per month      |        Limited to infra capabilities        |                           ~30,000,000                           |
-|        Cost per query        |                      $0                     |                             $0.00004                            |
-|         Infrastruktur        |                 Centralized                 |                          Decentralized                          |
-|     Geographic redundancy    |  $1,200 in total costs per additional node  |                             Included                            |
-|            Uptime            |                    Varies                   |                              99.9%+                             |
-|      Total Monthly Costs     | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
+|   Monatliche Serverkosten\*  |         $1100 pro Monat, pro Knoten         |                                $0                               |
+|         Abfragekosten        |                    $4000                    |                         $1,200 pro Monat                        |
+| Anzahl der benötigten Knoten |                      10                     |                         Nicht anwendbar                         |
+| Entwicklungszeit<sup>†</sup> |          $6,000 oder mehr pro Monat         | Keine, eingebaut in das Netzwerk mit global verteilten Indexern |
+|      Abfragen pro Monat      |  Begrenzt auf infrastrukturelle Funktionen  |                           ~30,000,000                           |
+|      Kosten pro Abfrage      |                      $0                     |                             $0.00004                            |
+|         Infrastruktur        |                Zentralisiert                |                         Dezentralisiert                         |
+|    Geografische Redundanz    | $1,200 Gesamtkosten pro zusätzlichem Knoten |                          Eingeschlossen                         |
+|         Betriebszeit         |                   Variiert                  |                              99.9%+                             |
+|    Monatliche Gesamtkosten   | <span className="highlight-row" /> $11,000+ |                              $1,200                             |
 
-\*including costs for backup: $50-$100 per month
+\*einschließlich der Kosten für die Datensicherung: $50-$100 pro Monat
 
-<sup>†</sup>Engineering time based on $200 per hour assumption
+<sup>†</sup>Engineering-Zeit auf der Grundlage von 200 $ pro Stunde angenommen
 
-<sup>‡</sup>Reflects cost for data consumer. Query fees are still paid to Indexers for Free Plan queries.
+<sup>‡</sup>Reflektiert die Kosten für den Datenkonsumenten. Für Abfragen im Rahmen des „Free Plan“ werden nach wie vor Abfragegebühren an Indexer gezahlt.
 
-Estimated costs are only for Ethereum Mainnet subgraphs — costs are even higher when self hosting a `graph-node` on other networks. Some users may need to update their subgraph to a new version. Due to Ethereum gas fees, an update costs ~$50 at time of writing. Note that gas fees on [Arbitrum](/archived/arbitrum/arbitrum-faq/) are substantially lower than Ethereum mainnet.
+Die geschätzten Kosten gelten nur für Ethereum Mainnet Subgraphen - die Kosten sind noch höher, wenn man selbst einen `graph-node` in anderen Netzwerken hostet. Einige Nutzer müssen ihren Subgraphen möglicherweise auf eine neue Version aktualisieren. Aufgrund der Ethereum-Gas-Gebühren kostet ein Update zum Zeitpunkt des Schreibens ~$50. Beachten Sie, dass die Gasgebühren auf [Arbitrum](/archived/arbitrum/arbitrum-faq/) wesentlich niedriger sind als im Ethereum Mainnet.
 
-Curating signal on a subgraph is an optional one-time, net-zero cost (e.g., $1k in signal can be curated on a subgraph, and later withdrawn—with potential to earn returns in the process).
+Das Kuratieren von Signalen auf einem Subgraphen ist eine optionale, einmalige Investition mit Netto-Nullkosten (z.B. können Signale im Wert von 1.000 Dollar auf einem Subgraphen kuratiert und später wieder abgezogen werden - mit dem Potenzial, dabei Renditen zu erzielen).
 
-## No Setup Costs & Greater Operational Efficiency
+## Keine Einrichtungskosten und größere betriebliche Effizienz
 
-Zero setup fees. Get started immediately with no setup or overhead costs. No hardware requirements. No outages due to centralized infrastructure, and more time to concentrate on your core product . No need for backup servers, troubleshooting, or expensive engineering resources.
+Keine Einrichtungsgebühren. Sie können sofort loslegen, ohne Einrichtungs- oder Gemeinkosten. Keine Hardware-Anforderungen. Keine Ausfälle aufgrund einer zentralisierten Infrastruktur und mehr Zeit, um sich auf Ihr Kernprodukt zu konzentrieren. Kein Bedarf an Backup-Servern, Fehlersuche oder teuren technischen Ressourcen.
 
-## Reliability & Resiliency
+## Zuverlässigkeit und Ausfallsicherheit
 
-The Graph’s decentralized network gives users access to geographic redundancy that does not exist when self-hosting a `graph-node`. Queries are served reliably thanks to 99.9%+ uptime, achieved by hundreds of independent Indexers securing the network globally.
+Das dezentralisierte Netzwerk von The Graph bietet den Nutzern Zugang zu einer geografischen Redundanz, die beim Selbsthosten eines `graph-node` nicht gegeben ist. Abfragen werden dank einer Betriebszeit von über 99,9 %, die durch Hunderte unabhängiger Indexer erreicht wird, die das Netzwerk weltweit sichern, zuverlässig bedient.
 
-Bottom line: The Graph Network is less expensive, easier to use, and produces superior results compared to running a `graph-node` locally.
+Unterm Strich: Das The Graph Network ist kostengünstiger, einfacher zu benutzen und liefert bessere Ergebnisse als ein lokaler `graph-node`.
 
-Start using The Graph Network today, and learn how to [publish your subgraph to The Graph's decentralized network](/subgraphs/quick-start/).
+Beginnen Sie noch heute mit der Nutzung von The Graph Network und erfahren Sie, wie Sie [Ihren Subgraphут im dezentralen Netzwerk von The Graph veröffentlichen](/subgraphs/quick-start/).

From e8fa5efe677a4d74551133bfb7a14491a850f861 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 11:30:46 -0500
Subject: [PATCH 3814/3820] New translations benefits.mdx (Russian)

---
 website/pages/ru/resources/benefits.mdx | 82 ++++++++++++-------------
 1 file changed, 41 insertions(+), 41 deletions(-)

diff --git a/website/pages/ru/resources/benefits.mdx b/website/pages/ru/resources/benefits.mdx
index 11a74345eaf1..465586f547c3 100644
--- a/website/pages/ru/resources/benefits.mdx
+++ b/website/pages/ru/resources/benefits.mdx
@@ -3,18 +3,18 @@ title: The Graph vs. Self Hosting
 socialImage: https://thegraph.com/docs/img/seo/benefits.jpg
 ---
 
-Децентрализованная сеть Graph была спроектирована и усовершенствована для создания надежной системы индексации и запросов — и с каждым днем она становится лучше благодаря тысячам участников по всему миру.
+Децентрализованная сеть The Graph была спроектирована и усовершенствована для создания надежной системы индексации и запросов — и с каждым днем она становится лучше благодаря тысячам участников по всему миру.
 
 The benefits of this decentralized protocol cannot be replicated by running a `graph-node` locally. The Graph Network is more reliable, more efficient, and less expensive.
 
 Вот анализ:
 
-## Почему Вы должны использовать сеть The Graph
+## Почему Вы должны использовать The Graph Network
 
 - Significantly lower monthly costs
-- затраты на установку инфраструктуры в размере $0
-- Превосходное время безотказной работы
-- Access to hundreds of independent Indexers around the world
+- Затраты на настройкку инфраструктуры в размере $0
+- Оптимальное время безотказной работы
+- Доступ к сотням независимых Индексаторов по всему миру
 - 24/7 техническая поддержка со стороны глобального сообщества
 
 ## Преимущества
@@ -27,47 +27,47 @@ Query costs may vary; the quoted cost is the average at time of publication (Mar
 
 ## Low Volume User (less than 100,000 queries per month)
 
-|         Сравнение затрат        |         Самостоятельный хостинг         |                          Сеть The Graph                         |
-| :-----------------------------: | :-------------------------------------: | :-------------------------------------------------------------: |
-| Ежемесячная стоимость сервера\* |               $350 в месяц              |                                $0                               |
-|        Стоимость запроса        |                   $0+                   |                           $0 per month                          |
-|   Время разработки<sup>†</sup>  |               $400 в месяц              | Никто, встроен в сеть с глобально распределенными индексаторами |
-|         Запросы в месяц         |  Ограничен возможностями инфраструктуры |                       100,000 (Free Plan)                       |
-|     Стоимость одного запроса    |                    $0                   |                          $0<sup>‡</sup>                         |
-|          Инфраструктура         |             Централизованная            |                        Децентрализованная                       |
-|   Географическая избыточность   |   $750+ за каждую дополнительную ноду   |                             Включено                            |
-|     Время безотказной работы    |               Варьируется               |                              99.9%+                             |
-|    Общие ежемесячные расходы    | <span className="highlight-row" />$750+ |                                $0                               |
+|         Сравнение затрат        |         Самостоятельный хостинг         |                         Сеть The Graph                        |
+| :-----------------------------: | :-------------------------------------: | :-----------------------------------------------------------: |
+| Ежемесячная стоимость сервера\* |               $350 в месяц              |                               $0                              |
+|        Стоимость запроса        |                   $0+                   |                          $0 per month                         |
+|   Время разработки<sup>†</sup>  |               $400 в месяц              | Нет, встроен в сеть с глобально распределенными Индексаторами |
+|         Запросы в месяц         |  Ограничен возможностями инфраструктуры |                      100,000 (Free Plan)                      |
+|     Стоимость одного запроса    |                    $0                   |                         $0<sup>‡</sup>                        |
+|          Инфраструктура         |             Централизованная            |                       Децентрализованная                      |
+|   Географическая избыточность   |   $750+ за каждую дополнительную ноду   |                            Включено                           |
+|     Время безотказной работы    |               Варьируется               |                             99.9%+                            |
+|    Общие ежемесячные расходы    | <span className="highlight-row" />$750+ |                               $0                              |
 
 ## Medium Volume User (~3M queries per month)
 
-|         Сравнение затрат        |                    Самостоятельный хостинг                    |                          Сеть The Graph                         |
-| :-----------------------------: | :-----------------------------------------------------------: | :-------------------------------------------------------------: |
-| Ежемесячная стоимость сервера\* |                          $350 в месяц                         |                                $0                               |
-|        Стоимость запроса        |                          $500 в месяц                         |                          $120 per month                         |
-|   Время разработки<sup>†</sup>  |                          $800 в месяц                         | Никто, встроен в сеть с глобально распределенными индексаторами |
-|         Запросы в месяц         |             Ограничен возможностями инфраструктуры            |                            ~3,000,000                           |
-|     Стоимость одного запроса    |                               $0                              |                             $0.00004                            |
-|          Инфраструктура         |                        Централизованная                       |                        Децентрализованная                       |
-|        Инженерные расходы       |                           $200 в час                          |                             Включено                            |
-|   Географическая избыточность   | общие затраты на каждую дополнительную ноду составляют $1,200 |                             Включено                            |
-|     Время безотказной работы    |                          Варьируется                          |                              99.9%+                             |
-|    Общие ежемесячные расходы    |           <span className="highlight-row" /> $1,650+          |                               $120                              |
+|         Сравнение затрат        |                    Самостоятельный хостинг                    |                         Сеть The Graph                        |
+| :-----------------------------: | :-----------------------------------------------------------: | :-----------------------------------------------------------: |
+| Ежемесячная стоимость сервера\* |                          $350 в месяц                         |                               $0                              |
+|        Стоимость запроса        |                          $500 в месяц                         |                         $120 per month                        |
+|   Время разработки<sup>†</sup>  |                          $800 в месяц                         | Нет, встроен в сеть с глобально распределенными Индексаторами |
+|         Запросы в месяц         |             Ограничен возможностями инфраструктуры            |                           ~3,000,000                          |
+|     Стоимость одного запроса    |                               $0                              |                            $0.00004                           |
+|          Инфраструктура         |                        Централизованная                       |                       Децентрализованная                      |
+|        Инженерные расходы       |                           $200 в час                          |                            Включено                           |
+|   Географическая избыточность   | общие затраты на каждую дополнительную ноду составляют $1,200 |                            Включено                           |
+|     Время безотказной работы    |                          Варьируется                          |                             99.9%+                            |
+|    Общие ежемесячные расходы    |           <span className="highlight-row" /> $1,650+          |                              $120                             |
 
 ## High Volume User (~30M queries per month)
 
-|         Сравнение затрат        |                    Самостоятельный хостинг                    |                          Сеть The Graph                         |
-| :-----------------------------: | :-----------------------------------------------------------: | :-------------------------------------------------------------: |
-| Ежемесячная стоимость сервера\* |                     $1100 в месяц за ноду                     |                                $0                               |
-|        Стоимость запроса        |                             $4000                             |                         $1,200 per month                        |
-|    Необходимое количество нод   |                               10                              |                           Не подходит                           |
-|   Время разработки<sup>†</sup>  |                   $6,000 или больше в месяц                   | Никто, встроен в сеть с глобально распределенными индексаторами |
-|         Запросы в месяц         |             Ограничен возможностями инфраструктуры            |                           ~30,000,000                           |
-|     Стоимость одного запроса    |                               $0                              |                             $0.00004                            |
-|          Инфраструктура         |                        Централизованная                       |                        Децентрализованная                       |
-|   Географическая избыточность   | общие затраты на каждую дополнительную ноду составляют $1,200 |                             Включено                            |
-|     Время безотказной работы    |                          Варьируется                          |                              99.9%+                             |
-|    Общие ежемесячные расходы    |          <span className="highlight-row" /> $11,000+          |                              $1,200                             |
+|         Сравнение затрат        |                    Самостоятельный хостинг                    |                         Сеть The Graph                        |
+| :-----------------------------: | :-----------------------------------------------------------: | :-----------------------------------------------------------: |
+| Ежемесячная стоимость сервера\* |                     $1100 в месяц за ноду                     |                               $0                              |
+|        Стоимость запроса        |                             $4000                             |                        $1,200 per month                       |
+|    Необходимое количество нод   |                               10                              |                          Не подходит                          |
+|   Время разработки<sup>†</sup>  |                   $6,000 или больше в месяц                   | Нет, встроен в сеть с глобально распределенными Индексаторами |
+|         Запросы в месяц         |             Ограничен возможностями инфраструктуры            |                          ~30,000,000                          |
+|     Стоимость одного запроса    |                               $0                              |                            $0.00004                           |
+|          Инфраструктура         |                        Централизованная                       |                       Децентрализованная                      |
+|   Географическая избыточность   | общие затраты на каждую дополнительную ноду составляют $1,200 |                            Включено                           |
+|     Время безотказной работы    |                          Варьируется                          |                             99.9%+                            |
+|    Общие ежемесячные расходы    |          <span className="highlight-row" /> $11,000+          |                             $1,200                            |
 
 \* включая расходы на резервное копирование: $50-$100 в месяц
 
@@ -81,7 +81,7 @@ Estimated costs are only for Ethereum Mainnet subgraphs — costs are even highe
 
 ## No Setup Costs & Greater Operational Efficiency
 
-Нулевая плата за установку. Приступайте к работе немедленно, без каких-либо затрат на настройку или накладные расходы. Никаких требований к оборудованию. Отсутствие перебоев в работе из-за централизованной инфраструктуры и больше времени для концентрации на вашем основном продукте. Нет необходимости в резервных серверах, устранении неполадок или дорогостоящих инженерных ресурсах.
+Нулевая плата за установку. Приступайте к работе немедленно, без каких-либо затрат на настройку или накладные расходы. Никаких требований к оборудованию. Отсутствие перебоев в работе из-за централизованной инфраструктуры и больше времени для концентрации на Вашем основном продукте. Нет необходимости в резервных серверах, устранении неполадок или дорогостоящих инженерных ресурсах.
 
 ## Reliability & Resiliency
 

From 490bb749aa849023f9aa27e478536c1deb8b2fd7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 11:30:47 -0500
Subject: [PATCH 3815/3820] New translations subgraph-debug-forking.mdx
 (Chinese Simplified)

---
 .../zh/subgraphs/cookbook/subgraph-debug-forking.mdx | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx b/website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx
index 565000c96131..7eef54e247ea 100644
--- a/website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx
+++ b/website/pages/zh/subgraphs/cookbook/subgraph-debug-forking.mdx
@@ -10,13 +10,13 @@ As with many systems processing large amounts of data, The Graph's Indexers (Gra
 
 In the context of debugging, **subgraph forking** allows you to debug your failed subgraph at block _X_ without needing to wait to sync-up to block _X_.
 
-## 让我们看看这是如何做到的？
+## 什么？！ 如何处理？
 
 When you deploy a subgraph to a remote Graph Node for indexing and it fails at block _X_, the good news is that the Graph Node will still serve GraphQL queries using its store, which is synced-up to block _X_. That's great! This means we can take advantage of this "up-to-date" store to fix the bugs arising when indexing block _X_.
 
 In a nutshell, we are going to _fork the failing subgraph_ from a remote Graph Node that is guaranteed to have the subgraph indexed up to block _X_ in order to provide the locally deployed subgraph being debugged at block _X_ an up-to-date view of the indexing state.
 
-## 下面让我们看一下代码示例
+## 请给我看一些代码！
 
 To stay focused on subgraph debugging, let's keep things simple and run along with the [example-subgraph](https://github.com/graphprotocol/graph-tooling/tree/main/examples/ethereum-gravatar) indexing the Ethereum Gravity smart contract.
 
@@ -46,12 +46,12 @@ export function handleUpdatedGravatar(event: UpdatedGravatar): void {
 
 Oops, how unfortunate, when I deploy my perfect looking subgraph to [Subgraph Studio](https://thegraph.com/studio/) it fails with the _"Gravatar not found!"_ error.
 
-尝试修复的常用方法是：
+The usual way to attempt a fix is:
 
-1. 在映射源中进行更改，你认为这将解决问题（但我知道它不会）。
+1. Make a change in the mappings source, which you believe will solve the issue (while I know it won't).
 2. Re-deploy the subgraph to [Subgraph Studio](https://thegraph.com/studio/) (or another remote Graph Node).
-3. 等待同步。
-4. 如果它再次中断，则返回 第1步，否则：搞定！
+3. Wait for it to sync-up.
+4. If it breaks again go back to 1, otherwise: Hooray!
 
 It is indeed pretty familiar to an ordinary debug process, but there is one step that horribly slows down the process: _3. Wait for it to sync-up._
 

From 6b3c194bf93d70b143e67a170954fe95054a3f33 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 15:35:57 -0500
Subject: [PATCH 3816/3820] New translations graphql-api.mdx (Portuguese)

---
 .../pt/subgraphs/querying/graphql-api.mdx     | 126 +++++++++---------
 1 file changed, 63 insertions(+), 63 deletions(-)

diff --git a/website/pages/pt/subgraphs/querying/graphql-api.mdx b/website/pages/pt/subgraphs/querying/graphql-api.mdx
index ae724618544e..8899b4c3ffcf 100644
--- a/website/pages/pt/subgraphs/querying/graphql-api.mdx
+++ b/website/pages/pt/subgraphs/querying/graphql-api.mdx
@@ -2,23 +2,23 @@
 title: API GraphQL
 ---
 
-Learn about the GraphQL Query API used in The Graph.
+Aprenda sobre a API de Queries da GraphQL, usada no The Graph.
 
-## What is GraphQL?
+## O Que é a GraphQL?
 
-[GraphQL](https://graphql.org/learn/) is a query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
+A [GraphQL](https://graphql.org/learn/) é uma linguagem de queries para APIs e um sistema de tempo de execução (runtime) para executar esses queries, com os seus dados já existentes. O The Graph usa a GraphQL para fazer queries em subgraphs.
 
-To understand the larger role that GraphQL plays, review [developing](/subgraphs/developing/introduction/) and [creating a subgraph](/developing/creating-a-subgraph/).
+Para entender melhor o papel maior da GraphQL, veja [como desenvolver](/subgraphs/developing/introduction/) e [criar um subgraph](/developing/creating-a-subgraph/).
 
-## Queries with GraphQL
+## Queries com a GraphQL
 
-In your subgraph schema you define types called `Entities`. For each `Entity` type, `entity` and `entities` fields will be generated on the top-level `Query` type.
+No seu schema de subgraph, você definirá tipos chamados `Entities` ("Entidades"). Para cada tipo `Entity`, campos `entity` e `entities` serão gerados no tipo de nível superior `Query`.
 
-> Note: `query` does not need to be included at the top of the `graphql` query when using The Graph.
+> Observação: `query` não precisa ser incluído no topo do query `graphql` enquanto usar o The Graph.
 
 ### Exemplos
 
-Query for a single `Token` entity defined in your schema:
+Query para uma entidade `Token` definida no seu schema:
 
 ```graphql
 {
@@ -29,9 +29,9 @@ Query for a single `Token` entity defined in your schema:
 }
 ```
 
-> Note: When querying for a single entity, the `id` field is required, and it must be written as a string.
+> Nota: Ao fazer um query para uma única entidade, é obrigatório um campo `id`; este deve ser escrito como string.
 
-Query all `Token` entities:
+Faça um query de todas as entidades `Token`:
 
 ```graphql
 {
@@ -44,10 +44,10 @@ Query all `Token` entities:
 
 ### Organização
 
-When querying a collection, you may:
+Quando fizer um query de uma coleção, você poderá:
 
-- Use the `orderBy` parameter to sort by a specific attribute.
-- Use the `orderDirection` to specify the sort direction, `asc` for ascending or `desc` for descending.
+- Use o parâmetro `orderBy` para organizar os resultados por atributos específicos.
+- Use `orderDirection` para especificar a direção da organização; `asc` para ordem crescente ou `desc` para decrescente.
 
 #### Exemplo
 
@@ -62,9 +62,9 @@ When querying a collection, you may:
 
 #### Exemplo para organização de entidade aninhada
 
-As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) entities can be sorted on the basis of nested entities.
+Com o lançamento da versão [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) do Graph Node, as entidades podem ser organizadas com base nas entidades aninhadas.
 
-The following example shows tokens sorted by the name of their owner:
+No seguinte exemplo, organizamos os tokens pelo nome do proprietário:
 
 ```graphql
 {
@@ -77,18 +77,18 @@ The following example shows tokens sorted by the name of their owner:
 }
 ```
 
-> Currently, you can sort by one-level deep `String` or `ID` types on `@entity` and `@derivedFrom` fields. Unfortunately, [sorting by interfaces on one level-deep entities](https://github.com/graphprotocol/graph-node/pull/4058), sorting by fields which are arrays and nested entities is not yet supported.
+> Atualmente, pode-se organizar por tipos `String` or `ID` de nível único em campos `@entity` e `@derivedFrom`. Infelizmente, ainda não há apoio para [organização por interfaces em entidades de nível único](https://github.com/graphprotocol/graph-node/pull/4058), que é a organização por campos que são arranjos e entidades aninhadas.
 
 ### Paginação
 
-When querying a collection, it's best to:
+Quando fizer um query de uma coleção, recomendamos:
 
-- Use the `first` parameter to paginate from the beginning of the collection.
-  - The default sort order is by `ID` in ascending alphanumeric order, **not** by creation time.
-- Use the `skip` parameter to skip entities and paginate. For instance, `first:100` shows the first 100 entities and `first:100, skip:100` shows the next 100 entities.
-- Avoid using `skip` values in queries because they generally perform poorly. To retrieve a large number of items, it's best to page through entities based on an attribute as shown in the previous example above.
+- Usar o parâmetro `first` para paginar a partir do início da coleção.
+  - A ordem padrão de organização é por `ID` em ordem alfanumérica crescente, **não** por data e hora de criação.
+- Usar o parâmetro `skip` para pular entidades e paginar. Por exemplo: `first:100` mostra as primeiras 100 entidades e `first:100, skip:100` mostra as próximas 100.
+- Evitar usar valores `skip` em queries, já que o desempenho destes normalmente não é bom. Para resgatar um grande volume de itens, recomendamos paginar entidades com base num atributo, conforme demonstrado no exemplo acima.
 
-#### Example using `first`
+#### Exemplo com `first`
 
 Consulte os 10 primeiros tokens:
 
@@ -101,11 +101,11 @@ Consulte os 10 primeiros tokens:
 }
 ```
 
-To query for groups of entities in the middle of a collection, the `skip` parameter may be used in conjunction with the `first` parameter to skip a specified number of entities starting at the beginning of the collection.
+Para fazer queries sobre grupos de entidades no meio de uma coleção, o parâmetro `skip` pode ser usado em conjunto com o parâmetro `first` para pular um número especificado de entidades, a começar no início da coleção.
 
-#### Example using `first` and `skip`
+#### Exemplo com `first` e `skip`
 
-Query 10 `Token` entities, offset by 10 places from the beginning of the collection:
+Faça query de 10 entidades Token, deslocadas por 10 posições do começo da coleção:
 
 ```graphql
 {
@@ -116,9 +116,9 @@ Query 10 `Token` entities, offset by 10 places from the beginning of the collect
 }
 ```
 
-#### Example using `first` and `id_ge`
+#### Exemplo com `first` e `id_ge`
 
-If a client needs to retrieve a large number of entities, it's more performant to base queries on an attribute and filter by that attribute. For example, a client could retrieve a large number of tokens using this query:
+Se um cliente precisar retirar um grande volume de entidades, é muito mais eficiente basear queries num atributo e filtrar pelo mesmo. Por exemplo, um cliente retiraria um número grande de tokens com este query:
 
 ```graphql
 query manyTokens($lastID: String) {
@@ -129,16 +129,16 @@ query manyTokens($lastID: String) {
 }
 ```
 
-The first time, it would send the query with `lastID = ""`, and for subsequent requests it would set `lastID` to the `id` attribute of the last entity in the previous request. This approach will perform significantly better than using increasing `skip` values.
+Na primeira vez, ele enviaria o query com `lastID = ""`, e nas solicitações seguintes, configuraria `lastID` no atributo `id` da última entidade no pedido anterior. Este método será mais eficiente do que usar valores `skip` crescentes.
 
 ### Filtragem
 
-- You can use the `where` parameter in your queries to filter for different properties.
-- You can filter on multiple values within the `where` parameter.
+- O parâmetro `where` pode ser usado nos seus queries para filtrar propriedades diferentes.
+- Vários valores podem ser filtrados dentro do parâmetro `where`.
 
-#### Example using `where`
+#### Exemplo com `where`
 
-Query challenges with `failed` outcome:
+Faça um query sobre desafios com o resultado `failed` (falha):
 
 ```graphql
 {
@@ -152,7 +152,7 @@ Query challenges with `failed` outcome:
 }
 ```
 
-You can use suffixes like `_gt`, `_lte` for value comparison:
+É possível usar sufixos como `_gt`, ou `_lte`, para comparar valores:
 
 #### Exemplo para filtragem de alcance
 
@@ -168,7 +168,7 @@ You can use suffixes like `_gt`, `_lte` for value comparison:
 
 #### Exemplo para filtragem de blocos
 
-You can also filter entities that were updated in or after a specified block with `_change_block(number_gte: Int)`.
+Também dá para filtrar entidades atualizadas dentro de, ou depois de, um bloco específico com `_change_block(number_gte: Int)`.
 
 Isto pode servir caso mire retirar apenas entidades que mudaram, por exemplo, desde a última vez que você pesquisou. Também pode ser bom investigar ou debugar como as entidades mudam no seu subgraph (se combinado com um filtro de blocos, pode isolar apenas entidades que mudaram em um bloco específico).
 
@@ -184,7 +184,7 @@ Isto pode servir caso mire retirar apenas entidades que mudaram, por exemplo, de
 
 #### Exemplo para filtragem de entidade ninhada
 
-Filtering on the basis of nested entities is possible in the fields with the `_` suffix.
+É possível usar filtros com base em entidades aninhadas nos campos com o sufixo `_`.
 
 Isto é bom caso mire retirar apenas entidades cujas entidades de nível-filho correspondem às condições requeridas.
 
@@ -202,11 +202,11 @@ Isto é bom caso mire retirar apenas entidades cujas entidades de nível-filho c
 
 #### Operadores lógicos
 
-As of Graph Node [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) you can group multiple parameters in the same `where` argument using the `and` or the `or` operators to filter results based on more than one criteria.
+Com o lançamento da versão [`v0.30.0`](https://github.com/graphprotocol/graph-node/releases/tag/v0.30.0) do Graph Node, é possível agrupar vários parâmetros no mesmo argumento `where`, com os operadores `and` ou `or`, para filtrar resultados com base em mais de um critério.
 
-##### `AND` Operator
+##### Operador `AND`
 
-The following example filters for challenges with `outcome` `succeeded` and `number` greater than or equal to `100`.
+O exemplo a seguir filtra por desafios com o `outcome` ("resultado") `succeeded` ("sucesso"), e `number` ("número") maior que ou igual a `100`.
 
 ```graphql
 {
@@ -220,7 +220,7 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 }
 ```
 
-> **Syntactic sugar:** You can simplify the above query by removing the `and` operator by passing a sub-expression separated by commas.
+> **Açúcar sintático:** O query acima pode ser simplificado ao retirar o operador `and`, com o passe de uma sub-expressão separada por vírgulas.
 >
 > ```graphql
 > {
@@ -234,9 +234,9 @@ The following example filters for challenges with `outcome` `succeeded` and `num
 > }
 > ```
 
-##### `OR` Operator
+##### Operador `OR`
 
-The following example filters for challenges with `outcome` `succeeded` or `number` greater than or equal to `100`.
+O exemplo a seguir filtra desafios com o `outcome` `succeeded`, e o `number` maior que ou igual a `100`.
 
 ```graphql
 {
@@ -250,7 +250,7 @@ The following example filters for challenges with `outcome` `succeeded` or `numb
 }
 ```
 
-> **Note**: When constructing queries, it is important to consider the performance impact of using the `or` operator. While `or` can be a useful tool for broadening search results, it can also have significant costs. One of the main issues with `or` is that it can cause queries to slow down. This is because `or` requires the database to scan through multiple indexes, which can be a time-consuming process. To avoid these issues, it is recommended that developers use and operators instead of or whenever possible. This allows for more precise filtering and can lead to faster, more accurate queries.
+> **Observação**: Ao construir queries, é importante considerar o impacto do desempenho do operador `or`. O `or` pode ser útil para ampliar os resultados da busca, mas também pode ter custos significativos. Um dos maiores problemas com o `or` é que pode desacelerar os queries. Isto é porque o `or` exige que o banco de dados escaneie através de vários índices, o que pode demorar muito. Para evitar estes problemas, recomendamos que os programadores usem operadores `and` em vez de `or` sempre que possível. Isto retorna filtragens mais precisas, e pode levar a queries mais rápidos e confiáveis.
 
 #### Todos os Filtros
 
@@ -279,9 +279,9 @@ _not_ends_with
 _not_ends_with_nocase
 ```
 
-> Please note that some suffixes are only supported for specific types. For example, `Boolean` only supports `_not`, `_in`, and `_not_in`, but `_` is available only for object and interface types.
+> Perceba que alguns sufixos só tem apoio para tipos específicos. Por exemplo, o `Boolean` só apoia `_not`, `_in`, e `_not_in`, mas o `_` só está disponível para tipos de objeto e interface.
 
-In addition, the following global filters are available as part of `where` argument:
+Além disto, os seguintes filtros globais estão disponíveis como parte do argumento `where`:
 
 ```gr
 _change_block(number_gte: Int)
@@ -289,11 +289,11 @@ _change_block(number_gte: Int)
 
 ### Consultas de viagem no tempo
 
-You can query the state of your entities not just for the latest block, which is the default, but also for an arbitrary block in the past. The block at which a query should happen can be specified either by its block number or its block hash by including a `block` argument in the toplevel fields of queries.
+É possível solicitar o estado das suas entidades não só para o bloco mais recente, que é o padrão, mas também para um bloco arbitrário no passado. O bloco em que acontece um query pode ser especificado pelo seu número, ou pelo seu hash, ao incluir um argumento `block` nos campos de nível superior de query.
 
-The result of such a query will not change over time, i.e., querying at a certain past block will return the same result no matter when it is executed, with the exception that if you query at a block very close to the head of the chain, the result might change if that block turns out to **not** be on the main chain and the chain gets reorganized. Once a block can be considered final, the result of the query will not change.
+O resultado de um query assim não mudará com o tempo; por exemplo, queries num certo bloco passado retornarão o mesmo resultado, independente de quando ele for executado. Exceto que, se fizer um query num bloco muito perto do topo da chain, o resultado pode mudar se aquele bloco acabar ausente da chain principal e a chain for reorganizada. Quando um bloco puder ser considerado final, o resultado do query não mudará.
 
-> Note: The current implementation is still subject to certain limitations that might violate these guarantees. The implementation can not always tell that a given block hash is not on the main chain at all, or if a query result by a block hash for a block that is not yet considered final could be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
+> Observação: a implementação atual ainda está sujeita a certas limitações que podem violar estas garantias. A implementação nem sempre percebe que um hash de bloco não está na chain principal, ou que um query por hash de bloco retorna um bloco que não pode ser considerado final, mas que pode ser influenciado por uma reorganização de bloco executada concorrente com a solicitação. Elas não afetam os resultados de queries por hash de bloco quando o bloco é final e tem sua presença conhecida na chain principal. [Este inquérito](https://github.com/graphprotocol/graph-node/issues/1405) explica estas limitações em detalhes.
 
 #### Exemplo
 
@@ -309,7 +309,7 @@ The result of such a query will not change over time, i.e., querying at a certai
 }
 ```
 
-This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
+Este query retornará entidades `Challenge` e as suas entidades `Application` associadas, já que existiram diretamente após processar o bloco de número 8.000.000.
 
 #### Exemplo
 
@@ -325,13 +325,13 @@ This query will return `Challenge` entities, and their associated `Application`
 }
 ```
 
-This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing the block with the given hash.
+Este query retornará entidades `Challenge` e as suas entidades `Application` associadas, já que existiram diretamente após processar o bloco com o hash indicado.
 
 ### Consultas de Busca Fulltext
 
-Fulltext search query fields provide an expressive text search API that can be added to the subgraph schema and customized. Refer to [Defining Fulltext Search Fields](/developing/creating-a-subgraph/#defining-fulltext-search-fields) to add fulltext search to your subgraph.
+Campos de busca em full-text fornecem uma API de busca de texto expressiva, que pode ser adicionada e personalizada ao schema do subgraph. Para adicionar buscas em full-text ao seu subgraph, veja [Como Definir Campos de Busca em Full-Text](/developing/creating-a-subgraph/#defining-fulltext-search-fields).
 
-Fulltext search queries have one required field, `text`, for supplying search terms. Several special fulltext operators are available to be used in this `text` search field.
+Buscas em full-text têm um campo obrigatório, `text`, para ofertar termos de busca. Vários operadores especiais de full-text estão disponíveis para uso neste campo de busca `text`.
 
 Operadores de busca fulltext:
 
@@ -344,7 +344,7 @@ Operadores de busca fulltext:
 
 #### Exemplos
 
-Using the `or` operator, this query will filter to blog entities with variations of either "anarchism" or "crumpet" in their fulltext fields.
+Com o operador `or`, esta consulta filtrará para entidades de blog com variações de "anarchism" ou "crumpet" nos seus campos fulltext.
 
 ```graphql
 {
@@ -357,7 +357,7 @@ Using the `or` operator, this query will filter to blog entities with variations
 }
 ```
 
-The `follow by` operator specifies a words a specific distance apart in the fulltext documents. The following query will return all blogs with variations of "decentralize" followed by "philosophy"
+O operador `follow by` especifica palavras separadas por uma distância específica nos documentos fulltext. A query a seguir retornará todos os blogs com variações de "decentralize" ("descentralizar") seguido por "philosophy" ("filosofia")
 
 ```graphql
 {
@@ -385,25 +385,25 @@ Combine operadores de fulltext para fazer filtros mais complexos. Com um operado
 
 ### Validação
 
-Graph Node implements [specification-based](https://spec.graphql.org/October2021/#sec-Validation) validation of the GraphQL queries it receives using [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules), which is based on the [graphql-js reference implementation](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries which fail a validation rule do so with a standard error - visit the [GraphQL spec](https://spec.graphql.org/October2021/#sec-Validation) to learn more.
+O Graph Node implementa validações [baseadas em especificação](https://spec.graphql.org/October2021/#sec-Validation) dos queries da GraphQL que recebe, através do [graphql-tools-rs](https://github.com/dotansimha/graphql-tools-rs#validation-rules) — que tem base na [referência de implementação graphql-js](https://github.com/graphql/graphql-js/tree/main/src/validation). Queries que não aderem a uma regra de validação fazem isso com um erro comum — para saber mais, visite as [especificações da GraphQL](https://spec.graphql.org/October2021/#sec-Validation).
 
 ## Schema
 
-The schema of your dataSources, i.e. the entity types, values, and relationships that are available to query, are defined through the [GraphQL Interface Definition Language (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
+O schema dos seus dataSources — por exemplo, os tipos de entidade, valores, e conexões que podem ser solicitados num query — é definido através da [Linguagem de Definição de Interface da GraphQL (IDL)](https://facebook.github.io/graphql/draft/#sec-Type-System).
 
-GraphQL schemas generally define root types for `queries`, `subscriptions` and `mutations`. The Graph only supports `queries`. The root `Query` type for your subgraph is automatically generated from the GraphQL schema that's included in your [subgraph manifest](/developing/creating-a-subgraph/#components-of-a-subgraph).
+Os schemas GraphQL geralmente definem tipos de origem para `queries` (solicitações), `subscriptions` (inscrições) e `mutations` (mutações). O The Graph só apoia `queries`. A origem `Query` para o seu subgraph é gerada automaticamente a partir do schema GraphQL incluído no [manifest do seu subgraph](/developing/creating-a-subgraph/#components-of-a-subgraph).
 
-> Note: Our API does not expose mutations because developers are expected to issue transactions directly against the underlying blockchain from their applications.
+> Nota: A nossa API não expõe mutações, porque esperamos que os programadores emitam transações diretamente dos seus aplicativos perante a blockchain subjacente.
 
 ### Entidades
 
-All GraphQL types with `@entity` directives in your schema will be treated as entities and must have an `ID` field.
+Todos os tipos GraphQL com diretivos `@entity` no seu schema serão tratados como entidades, e devem ter um campo `ID`.
 
-> **Note:** Currently, all types in your schema must have an `@entity` directive. In the future, we will treat types without an `@entity` directive as value objects, but this is not yet supported.
+> **Observação:** Atualmente, todos os tipos no seu schema devem ter um diretivo `@entity`. No futuro, trataremos tipos sem um diretivo `@entity` como objetos de valor, mas ainda não há apoio a isto.
 
 ### Metadados de Subgraph
 
-All subgraphs have an auto-generated `_Meta_` object, which provides access to subgraph metadata. This can be queried as follows:
+Todos os subgraphs devem ter um objeto `_Meta_` gerado automaticamente, que permite acesso aos metadados do subgraph. Isto pode ser solicitado num query como o query mostrado a seguir:
 
 ```graphQL
 {
@@ -421,12 +421,12 @@ All subgraphs have an auto-generated `_Meta_` object, which provides access to s
 
 Se um bloco for fornecido, os metadados são desde aquele bloco; e se não, é usado o último indexado. Se providenciado, o bloco deve ser após o inicial do subgraph, e menor ou igual ao bloco indexado mais recentemente.
 
-`deployment` is a unique ID, corresponding to the IPFS CID of the `subgraph.yaml` file.
+`deployment` é uma ID única, correspondente ao CID PIFS do arquivo `subgraph.yaml`.
 
-`block` provides information about the latest block (taking into account any block constraints passed to `_meta`):
+O `block` fornece informações sobre o bloco mais recente (em consideração a quaisquer limites de bloco passados ao `_meta`):
 
 - hash: o hash do bloco
 - number: o número do bloco
 - timestamp: a hora do bloco, se disponível (disponível atualmente apenas para subgraphs que indexam redes EVM)
 
-`hasIndexingErrors` is a boolean identifying whether the subgraph encountered indexing errors at some past block
+`hasIndexingErrors` é um boolean que identifica se o subgraph encontrou erros de indexação em algum bloco passado

From a1d11ff3abea04c41c376de0f2df40d288568809 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 15:35:58 -0500
Subject: [PATCH 3817/3820] New translations python.mdx (Portuguese)

---
 website/pages/pt/subgraphs/querying/python.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs/querying/python.mdx b/website/pages/pt/subgraphs/querying/python.mdx
index 9b789b77fb29..634c4a6e2049 100644
--- a/website/pages/pt/subgraphs/querying/python.mdx
+++ b/website/pages/pt/subgraphs/querying/python.mdx
@@ -53,4 +53,4 @@ Como o subgrounds tem um grande conjunto de recursos para explorar, aqui estão
 - [Queries Concorrentes](https://docs.playgrounds.network/subgrounds/getting_started/async/)
   - Aprenda como subir o nível das suas queries ao paralelizá-las.
 - [Exportação de Dados em CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
-  - A quick article on how to seamlessly save your data as CSVs for further analysis.
+  - Um artigo rápido sobre como salvar os seus dados como arquivos CSV, para análise futura.

From 957b794973c475369537d732b1feba8b243de388 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 15:36:00 -0500
Subject: [PATCH 3818/3820] New translations introduction.mdx (Portuguese)

---
 website/pages/pt/subgraphs/developing/introduction.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/website/pages/pt/subgraphs/developing/introduction.mdx b/website/pages/pt/subgraphs/developing/introduction.mdx
index 1c5b6172fc5c..5501873ce58d 100644
--- a/website/pages/pt/subgraphs/developing/introduction.mdx
+++ b/website/pages/pt/subgraphs/developing/introduction.mdx
@@ -13,7 +13,7 @@ On The Graph, you can:
 1. Create, deploy, and publish subgraphs to The Graph using Graph CLI and [Subgraph Studio](https://thegraph.com/studio/).
 2. Use GraphQL to query existing subgraphs.
 
-### What is GraphQL?
+### O Que é a GraphQL?
 
 - [GraphQL](https://graphql.org/learn/) is the query language for APIs and a runtime for executing those queries with your existing data. The Graph uses GraphQL to query subgraphs.
 

From 0cf3a7b2ca33f0bea4f14d68b55c219add0b5b7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 15:36:01 -0500
Subject: [PATCH 3819/3820] New translations explorer.mdx (Portuguese)

---
 website/pages/pt/subgraphs/explorer.mdx | 52 ++++++++++++-------------
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/website/pages/pt/subgraphs/explorer.mdx b/website/pages/pt/subgraphs/explorer.mdx
index ebe605ca1121..9be328f5624d 100644
--- a/website/pages/pt/subgraphs/explorer.mdx
+++ b/website/pages/pt/subgraphs/explorer.mdx
@@ -2,36 +2,36 @@
 title: Graph Explorer
 ---
 
-Unlock the world of subgraphs and network data with [Graph Explorer](https://thegraph.com/explorer).
+Desbloqueie o mundo dos subgraphs e dos dados de rede com o [Graph Explorer](https://thegraph.com/explorer).
 
 ## Visão geral
 
-Graph Explorer consists of multiple parts where you can interact with [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegate](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engage [participants](https://thegraph.com/explorer/participants?chain=arbitrum-one), view [network information](https://thegraph.com/explorer/network?chain=arbitrum-one), and access your user profile.
+O Graph Explorer consiste de múltiplas partes onde pode-se interagir com [subgraphs](https://thegraph.com/explorer?chain=arbitrum-one), [delegar](https://thegraph.com/explorer/delegate?chain=arbitrum-one), engajar com [participantes](https://thegraph.com/explorer/participants?chain=arbitrum-one), visualizar [informações de rede](https://thegraph.com/explorer/network?chain=arbitrum-one), e acessar o seu perfil de utilizador.
 
-## Inside Explorer
+## Por Dentro do Explorer
 
-The following is a breakdown of all the key features of Graph Explorer. For additional support, you can watch the [Graph Explorer video guide](/subgraphs/explorer/#video-guide).
+A seguir, veja um resumo de todas as funções importantes do Graph Explorer. Para saber mais, veja o [vídeo-guia do Graph Explorer](/subgraphs/explorer/#video-guide).
 
-### Subgraphs Page
+### Página de Subgraphs
 
-After deploying and publishing your subgraph in Subgraph Studio, go to [Graph Explorer](https://thegraph.com/explorer) and click on the "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)" link in the navigation bar to access the following:
+Após implantar e editar o seu subgraph no Subgraph Studio, vá para o [Graph Explorer](https://thegraph.com/explorer) e clique no link "[Subgraphs](https://thegraph.com/explorer?chain=arbitrum-one)", na barra de navegação, para acessar o seguinte:
 
-- Your own finished subgraphs
-- Subgraphs published by others
-- The exact subgraph you want (based on the date created, signal amount, or name).
+- Seus próprios subgraphs completos
+- Subgraphs editados por outros
+- O subgraph exato que quer (com base na data de criação, quantidade de sinalização, ou nome).
 
-![Explorer Image 1](/img/Subgraphs-Explorer-Landing.png)
+![Imagem do Explorer #1](/img/Subgraphs-Explorer-Landing.png)
 
-When you click into a subgraph, you will be able to do the following:
+Quando clicar em um subgraph, será possível:
 
-- Test queries in the playground and be able to leverage network details to make informed decisions.
-- Signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality.
+- Testar queries na área de testes e aproveitar detalhes de rede para fazer decisões informadas.
+- Sinalizar GRT no seu próprio subgraph, ou nos subgraphs de outros, para avisar os indexadores sobre a sua importância e qualidade.
 
-  - This is critical because signaling on a subgraph incentivizes it to be indexed, meaning it’ll eventually surface on the network to serve queries.
+  - Isto é importante, porque sinalizar em um subgraph incentiva a sua indexação; ou seja, ele aparecerá em breve na rede para servir queries.
 
-![Explorer Image 2](/img/Subgraph-Details.png)
+![Imagem do Explorer 2](/img/Subgraph-Details.png)
 
-On each subgraph’s dedicated page, you can do the following:
+Na página dedicada de cada subgraph, é possível:
 
 - Sinalização/cancelamento de sinais em subgraphs
 - Ver mais detalhes como gráficos, ID de lançamento atual, e outros metadados
@@ -42,26 +42,26 @@ On each subgraph’s dedicated page, you can do the following:
 - Estatísticas do subgraph (alocações, Curadores, etc.)
 - Visualizar a entidade que publicou o subgraph
 
-![Explorer Image 3](/img/Explorer-Signal-Unsignal.png)
+![Imagem do Explorer 3](/img/Explorer-Signal-Unsignal.png)
 
-### Delegate Page
+### Página de Delegação
 
-On the [Delegate page](https://thegraph.com/explorer/delegate?chain=arbitrum-one), you can find information about delegating, acquiring GRT, and choosing an Indexer.
+Na [página de Delegação](https://thegraph.com/explorer/delegate?chain=arbitrum-one), é possível encontrar informações sobre como delegar, adquirir GRT, e escolher um Indexador.
 
-On this page, you can see the following:
+Nesta página, pode-se ver:
 
-- Indexers who collected the most query fees
-- Indexers with the highest estimated APR
+- Os Indexadores que coletaram mais taxas de query
+- Indexadores com a maior taxa anual efetiva
 
-Additionally, you can calculate your ROI and search for top Indexers by name, address, or subgraph.
+Também é possível calcular a sua taxa de juros e buscar pelos maiores Indexadores por nome, endereço, ou subgraph.
 
-### Participants Page
+### Participantes
 
-This page provides a bird's-eye view of all "participants," which includes everyone participating in the network, such as Indexers, Delegators, and Curators.
+Esta página providencia um resumo de todos os "participantes", incluindo todos que participam na rede: por exemplo, Indexadores, Delegantes, e Curadores.
 
 #### 1. Indexadores
 
-![Explorer Image 4](/img/Indexer-Pane.png)
+![Imagem do Explorer 4](/img/Indexer-Pane.png)
 
 Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
 

From 30b1dae3e5f8c88c781865ecd5baee7aec21188b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Beno=C3=AEt=20Rouleau?= <benoit.rouleau@icloud.com>
Date: Thu, 13 Feb 2025 17:15:57 -0500
Subject: [PATCH 3820/3820] New translations explorer.mdx (Portuguese)

---
 website/pages/pt/subgraphs/explorer.mdx | 110 ++++++++++++------------
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/website/pages/pt/subgraphs/explorer.mdx b/website/pages/pt/subgraphs/explorer.mdx
index 9be328f5624d..1cfa47a7365d 100644
--- a/website/pages/pt/subgraphs/explorer.mdx
+++ b/website/pages/pt/subgraphs/explorer.mdx
@@ -63,77 +63,77 @@ Esta página providencia um resumo de todos os "participantes", incluindo todos
 
 ![Imagem do Explorer 4](/img/Indexer-Pane.png)
 
-Indexers are the backbone of the protocol. They stake on subgraphs, index them, and serve queries to anyone consuming subgraphs.
+Os Indexadores formam a fundação do protocolo. Eles investem em subgraphs, os indexam, e servem queries a qualquer um que consome os subgraphs.
 
-In the Indexers table, you can see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made from query fees and indexing rewards.
+Na tabela de Indexadores, pode-se ver os parâmetros de delegação de um Indexador; sua participação; quanto eles investiram em cada subgraph; e a receita que obtiveram com taxas de query e recompensas de indexação.
 
 **Detalhes**
 
-- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators.
-- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards.
-- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters.
-- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior.
-- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed.
-- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing.
-- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated.
+- Porção de Taxa de Query — a percentagem dos rebates da taxa de query que o Indexador guarda ao dividir com os Delegantes.
+- Porção de Recompensa Efetiva — a porção de recompensa de indexação, aplicada ao pool de delegação. Se for negativa, ela significa que o Indexador está a distribuir parte das suas recompensas. Se for positiva, significa que o Indexador guarda um pouco das recompensas.
+- Tempo de Recarga — o tempo que resta até o Indexador poder mudar os parâmetros de delegação acima. Os períodos de recarga são configurados pelos Indexadores quando atualizam os seus parâmetros de delegação.
+- Títulos — Os stakes investidos pelo Indexador, que podem ser cortados por comportamento malicioso ou incorreto.
+- Delegado — Stake de Delegantes que pode ser alocado pelo Indexador, mas não pode ser cortado.
+- Alocado — O stake que os Indexadores estão a alocar de forma ativa aos subgraphs que indexam.
+- Capacidade Disponível de Delegação — a quantia de stakes delegados que os Indexadores ainda podem receber, antes que sejam delegados excessivamente.
 - Capacidade Máxima de Delegação — a quantidade máxima de stake delegado que o Indexador pode aceitar produtivamente. Um excesso de stake delegado não pode ser usado para alocações ou cálculos de recompensas.
-- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time.
+- Taxas de Query — as taxas totais que os utilizadores finais pagaram por queries de um Indexador durante todo o seu tempo.
 - Recompensas de Indexador — as recompensas totais recebidas pelo Indexador e pelos Delegantes temporalmente. As recompensas de Indexador são pagas pela emissão de GRT.
 
-Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters.
+Os indexadores podem ganhar taxas de query e recompensas de indexação. Funcionalmente, isto acontece quando participantes da rede delegam GRT a um Indexador. Isto permite que Indexadores recebam taxas e recompensas de queries, a depender dos seus parâmetros de Indexador.
 
-- Indexing parameters can be set by clicking on the right-hand side of the table or by going into an Indexer’s profile and clicking the “Delegate” button.
+- Os parâmetros de indexação são configurados no lado direito da tabela, ou ao entrar no perfil de um Indexador e clicar no botão "Delegate" (Delegar).
 
-To learn more about how to become an Indexer, you can take a look at the [official documentation](/indexing/overview/) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+Para saber mais sobre como se tornar um Indexador, veja a [documentação oficial](/indexing/overview/) ou os [guias de Indexador da The Graph Academy](https://thegraph.academy/delegators/choosing-indexers/)
 
-![Indexing details pane](/img/Indexing-Details-Pane.png)
+![Painel de detalhes de Indexação](/img/Indexing-Details-Pane.png)
 
 #### 2. Curadores
 
-Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially high-quality subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+Os Curadores analisam subgraphs para identificar os de maior qualidade. Quando um Curador achar um subgraph atraente, ele pode curá-lo com sinais na sua bonding curve. Ao fazer isso, os Curadores avisam aos Indexadores quais subgraphs têm qualidade alta e merecem ser indexados.
 
-- Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve.
-  - By depositing GRT, Curators mint curation shares of a subgraph. As a result, they can earn a portion of the query fees generated by the subgraph they have signaled on.
-  - The bonding curve incentivizes Curators to curate the highest quality data sources.
+- Os Curadores podem ser membros da comunidade, consumidores de dados, ou até mesmo programadores de subgraphs que sinalizam nos seus próprios subgraphs depositando tokens GRT numa bonding curve.
+  - Ao depositar GRT, os Curadores mintam ações de curadoria de um subgraph. Como resultado, eles podem ganhar uma parte das taxas de query geradas pelo subgraph que sinalizaram.
+  - A bonding curve incentiva os Curadores a curar as fontes de dados de maior qualidade.
 
-In the The Curator table listed below you can see:
+Na tabela de Curador abaixo, é possível ver:
 
 - A data em que o Curador começou a curar
 - O número de GRT depositado
 - O número de ações que um Curador tem
 
-![Explorer Image 6](/img/Curation-Overview.png)
+![Imagem do Explorer 6](/img/Curation-Overview.png)
 
-If you want to learn more about the Curator role, you can do so by visiting [official documentation.](/resources/roles/curating/) or [The Graph Academy](https://thegraph.academy/curators/).
+Para saber mais sobre a função de Curador, veja a [documentação oficial](/resources/roles/curating/) ou visite a [The Graph Academy](https://thegraph.academy/curators/).
 
 #### 3. Delegantes
 
-Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers.
+Os Delegantes são fundamentais na manutenção da segurança e da descentralização da The Graph Network. Eles participam da rede com a delegação (ou seja, o investimento — ou “staking”) de tokens GRT para um ou mais indexadores.
 
-- Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers attract Delegators by offering them a portion of their indexing rewards and query fees.
-- Delegators select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts.
-- Reputation within the community can also play a factor in the selection process. It's recommended to connect with the selected Indexers via [The Graph's Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/).
+- Sem Delegantes, os Indexadores têm menos oportunidades de ganhar recompensas e taxas significativas. Portanto, os Indexadores atraem Delegantes com ofertas de parte das suas recompensas de indexação e taxas de query.
+- Os Delegantes selecionam Indexadores com base em variáveis diferentes, que incluem: histórico de desempenho, taxas de recompensa por indexação, e porções de taxa de query.
+- A reputação na comunidade também pode ser importante no processo de seleção. É recomendado se conectar com os Indexadores selecionados via [o Discord](https://discord.gg/graphprotocol) ou [o fórum oficial do The Graph](https://forum.thegraph.com/).
 
-![Explorer Image 7](/img/Delegation-Overview.png)
+![Imagem do Explorer 7](/img/Delegation-Overview.png)
 
-In the Delegators table you can see the active Delegators in the community and important metrics:
+A tabela de Delegantes mostra os Delegantes ativos na comunidade e as métricas importantes:
 
 - O número de Indexadores aos quais um Delegante delega
-- A Delegator's original delegation
+- A delegação original de um Delegante
 - As recompensas que acumularam, mas não sacaram, do protocolo
 - As recompensas realizadas que sacaram do protocolo
 - A quantidade total de GRT que têm no protocolo no momento
-- The date they last delegated
+- A última data em que delegaram
 
 If you want to learn more about how to become a Delegator, check out the [official documentation](/resources/roles/delegating/delegating/) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
 
-### Network Page
+### Rede
 
-On this page, you can see global KPIs and have the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+A seção de Rede mostra indicadores-chave de desempenho (KPIs) globais, e permite trocar para uma base por epoch e analisar métricas de rede em mais detalhes. Estes detalhes darão-lhe uma ideia do desempenho gradual da rede.
 
 #### Visão geral
 
-The overview section has both all the current network metrics and some cumulative metrics over time:
+A seção de visão geral tem todas as métricas atuais da rede, e algumas métricas cumulativas com o tempo:
 
 - O stake total atual da rede
 - O stake dividido entre os Indexadores e os seus Delegantes
@@ -142,12 +142,12 @@ The overview section has both all the current network metrics and some cumulativ
 - Parâmetros de protocolo como recompensas de curadoria, ritmo de inflação, e mais
 - Recompensas e taxas na epoch atual
 
-A few key details to note:
+Alguns detalhes importantes:
 
-- **Query fees represent the fees generated by the consumers**. They can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
-- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once Indexers close their allocations towards the subgraphs they’ve been indexing. So, the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+- **As taxas de query representam as taxas geradas pelos consumidores**, e podem ser reivindicadas (ou não) pelos Indexadores após um período de pelo menos 7 epochs (veja abaixo), após as suas alocações aos subgraphs forem fechadas e os dados que serviram forem validados pelos consumidores.
+- **As recompensas de indexação representam a quantidade de recompensas que os Indexadores resgataram da emissão da rede durante a epoch.** Apesar da emissão do protocolo ser fixa, as recompensas só são mintadas quando os Indexadores fecham as suas alocações aos subgraphs que indexaram. Assim, o número de recompensas por epoch varia (por ex., durante algumas epochs, os Indexadores podem ter coletivamente fechado alocações abertas há muitos dias).
 
-![Explorer Image 8](/img/Network-Stats.png)
+![Imagem do Explorer 8](/img/Network-Stats.png)
 
 #### Epochs
 
@@ -159,34 +159,34 @@ Na seção de Epochs, pode analisar, numa base por epoch, métricas como:
   - A epoch ativa é aquela em que os Indexadores atualmente alocam stake e colecionam taxas de query
   - As epochs de estabelecimento são aquelas em que os canais de estado são estabelecidos. Portanto, os Indexadores são sujeitos a cortes caso os consumidores abram disputas contra eles.
   - Nas epochs de distribuição, são estabelecidos os canais de estado para as epochs, e os Indexadores podem reivindicar os seus rebates de taxas de query.
-  - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers.
+  - As epochs finalizadas são aquelas que não têm mais rebates de taxas de query para serem resgatadas pelos Indexadores; portanto, finalizadas.
 
-![Explorer Image 9](/img/Epoch-Stats.png)
+![Imagem do Explorer 9](/img/Epoch-Stats.png)
 
 ## Seu Perfil de Utilizador
 
-Your personal profile is the place where you can see your network activity, regardless of your role on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see the following tabs:
+É no seu perfil pessoal que verás a sua atividade na rede, sem se preocupar com a sua participação nela. A sua carteira de cripto será o seu perfil de utilizador, e com o Painel de Controlo do Utilizador, pode-se ver:
 
 ### Resumo do Perfil
 
-In this section, you can view the following:
+Esta página mostra:
 
-- Any of your current actions you've done.
-- Your profile information, description, and website (if you added one).
+- Quaisquer ações atuais que tenha realizado.
+- As suas informações de perfil, sua descrição, e seu sítio da web (se tiver adicionado um).
 
-![Explorer Image 10](/img/Profile-Overview.png)
+![Imagem do Explorer 10](/img/Profile-Overview.png)
 
 ### Aba de Subgraphs
 
-In the Subgraphs tab, you’ll see your published subgraphs.
+A aba de Subgraphs mostra os subgraphs editados por você.
 
-> This will not include any subgraphs deployed with the CLI for testing purposes. Subgraphs will only show up when they are published to the decentralized network.
+> Isso não inclui nenhum subgraph implantado com a CLI para fins de teste. Os subgraphs só aparecerão quando forem editados na rede descentralizada.
 
-![Explorer Image 11](/img/Subgraphs-Overview.png)
+![Imagem do Explorer 11](/img/Subgraphs-Overview.png)
 
 ### Aba de Indexação
 
-In the Indexing tab, you’ll find a table with all the active and historical allocations towards subgraphs. You will also find charts where you can see and analyze your past performance as an Indexer.
+A aba de Indexação mostrará uma tabela com todas as alocações ativas e históricas aos subgraphs, além de gráficos para analisar e ver o seu histórico de desempenho como um Indexador.
 
 Esta secção também incluirá detalhes sobre as suas recompensas de Indexador e taxas de consulta. Verá as seguintes métricas:
 
@@ -197,13 +197,13 @@ Esta secção também incluirá detalhes sobre as suas recompensas de Indexador
 - Porção de Recompensas — a % dos rebates das recompensas de Indexador que guarda ao dividir com os Delegantes
 - Títulos — o seu stake depositado, que pode ser cortado por comportamento malicioso ou incorreto
 
-![Explorer Image 12](/img/Indexer-Stats.png)
+![Imagem do Explorer 12](/img/Indexer-Stats.png)
 
 ### Aba de Delegação
 
-Delegators are important to the Graph Network. They must use their knowledge to choose an Indexer that will provide a healthy return on rewards.
+Os Delegantes são importantes para a Graph Network. Eles devem usar bem o seu conhecimento para escolher um Indexador que fornecerá um retorno saudável sobre as recompensas.
 
-In the Delegators tab, you can find the details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+A aba de Delegantes exibe os detalhes das suas delegações ativas e históricas, além das métricas dos Indexadores para os quais delegou.
 
 Na primeira metade da página estão o seu gráfico de delegação e um gráfico só de recompensas. Na esquerda, pode ver os KPIs (indicadores de desempenho) que refletem as suas métricas atuais de delegação.
 
@@ -219,7 +219,7 @@ Com os botões no lado direito da tábua, pode gestar a sua delegação — dele
 
 Lembre-se que este gráfico pode ser rolado horizontalmente, então se rolar totalmente à direita, pode ver o estado da sua delegação (a delegar, a cancelar, sacável).
 
-![Explorer Image 13](/img/Delegation-Stats.png)
+![Imagem do Explorer 13](/img/Delegation-Stats.png)
 
 ### Aba de Curadoria
 
@@ -232,7 +232,7 @@ Dentro desta aba está um resumo de:
 - Recompensas de query por subgraph
 - Detalhes de datas de atualização
 
-![Explorer Image 14](/img/Curation-Stats.png)
+![Imagem do Explorer 14](/img/Curation-Stats.png)
 
 ### Configurações do Seu Perfil
 
@@ -241,16 +241,16 @@ Dentro do seu perfil de utilizador, poderá configurar os detalhes do seu perfil
 - Os Operadores tomam ações limitadas no protocolo em nome do Indexador, como abertura e fechamento de alocações. Os operadores tendem a ser outros endereços do Ethereum, separados da sua carteira de staking, com acesso guardado à rede que pode ser configurado pessoalmente pelos Indexadores
 - Parâmetros de delegação que permitem controlar a distribuição de GRT entre você e os seus Delegantes.
 
-![Explorer Image 15](/img/Profile-Settings.png)
+![Imagem do Explorer 15](/img/Profile-Settings.png)
 
 Como o seu portal oficial no mundo dos dados descentralizados, o Graph Explorer permite-lhe tomar uma variedade de ações, independente do seu papel na rede. Pode acessar as suas configurações do perfil ao abrir o menu próximo ao seu endereço, e depois, clicar no botão de Configurações.
 
-<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Wallet details](/img/Wallet-Details.png)</div>
+<div sx={{ mx: 'auto', maxWidth: '400px' }}>![Detalhes da carteira](/img/Wallet-Details.png)</div>
 
 ## Outros Recursos
 
 ### Guia em Vídeo
 
-For a general overview of Graph Explorer, check out the video below:
+Para uma visão geral do Graph Explorer, veja o vídeo abaixo:
 
 <VideoEmbed youtube="u224xf7rEBY" />